Dennis Zimmer, Bertram Wöhrmann, Carsten Schäfer, Günter Baumgart, Sebastian Wischer, Oliver Kügow
VMware vSphere 4
Liebe Leserin, lieber Leser, Servervirtualisierung ist mehr als ein Trend. Dies verwundert nicht angesichts der Vorteile, die sie bei richtiger Anwendung bietet: Durch virtualisierte Server lassen sich mehrere Server physisch zu einem zusammenfassen und so viel Platz, Strom und damit Geld sparen. Deployment-Prozesse werden stark vereinfacht, Backup und Disaster-Recovery werden deutlich flexibler – die Liste der Vorteile ließe sich problemlos erweitern. Tatsache ist, dass VMware diese Potenziale erkannt und mit VMware vSphere 4 das Flaggschiff der Servervirtualisierung auf den Markt gebracht hat. Ein Blick auf die Menge der Möglichkeiten, die Ihnen mit vSphere 4 zur Verfügung stehen, genügt jedoch, um auch die Kehrseite zu verdeutlichen: Effiziente Servervirtualisierung erfordert viel Know-How und Praxiserfahrung. Aus diesem Grund hat Dennis Zimmer, erfolgreicher Unternehmer und bekannter Autor im Bereich der Virtualisierung und Rechenzentrumsverwaltung, ein ausgewähltes Autorenteam zur Servervirtualisierung mit VMware zusammengestellt. Neben ihm haben es sich Bertram Wöhrmann, Carsten Schäfer, Günter Baumgart, Sebastian Wischer und Oliver Kügow zur Aufgabe gemacht, Ihnen alles erforderliche Wissen rund um die Installation, die Konfiguration und die professionelle Administration klar und verständlich zu vermitteln. Ob Sie Administrator, Berater, IT-Architekt oder Entscheider sind: Sie werden mit Sicherheit von den zahlreichen Tipps profitieren, die Ihnen diese Experten aus ihrer langjährigen Berufspraxis und ihrem Umgang mit den Virtualisierungslösungen von VMware geben. So nutzen Sie künftig die oben genannten Vorteile der Virtualisierung mit VMware vSphere 4 für sich! Dieses Buch wurde mit großer Sorgfalt geschrieben, lektoriert und produziert. Sollte dennoch etwas nicht so funktionieren, wie Sie es erwarten, dann scheuen Sie sich nicht, sich mit mir in Verbindung zu setzen. Ihre Anregungen und Fragen sind jederzeit willkommen. Ich wünsche Ihnen viel Erfolg bei Ihrer Arbeit mit diesem Buch und mit VMware vSphere 4.
Ihr Sebastian Kestel Lektorat Galileo Computing
[email protected] www.galileocomputing.de Galileo Press · Rheinwerkallee 4 · 53227 Bonn
Der Name Galileo Press geht auf den italienischen Mathematiker und Philosophen Galileo Galilei (1564–1642) zurück. Er gilt als Gründungsfigur der neuzeitlichen Wissenschaft und wurde berühmt als Verfechter des modernen, heliozentrischen Weltbilds. Legendär ist sein Ausspruch Eppur se muove (Und sie bewegt sich doch). Das Emblem von Galileo Press ist der Jupiter, umkreist von den vier Galileischen Monden. Galilei entdeckte die nach ihm benannten Monde 1610. Gerne stehen wir Ihnen mit Rat und Tat zur Seite:
[email protected] bei Fragen und Anmerkungen zum Inhalt des Buches
[email protected] für versandkostenfreie Bestellungen und Reklamationen
[email protected] für Rezensions- und Schulungsexemplare Lektorat Jan Watermann, Sebastian Kestel Korrektorat Petra Biedermann, Reken Cover Barbara Thoben, Köln Titelbild Barbara Thoben, Köln Typografie und Layout Vera Brauner Herstellung Vera Brauner Satz SatzPro, Krefeld Druck und Bindung Bercker Graphischer Betrieb, Kevelaer Dieses Buch wurde gesetzt aus der Linotype Syntax Serif (9,25/13,25 pt) in FrameMaker. Gedruckt wurde es auf chlorfrei gebleichtem Offsetpapier.
Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. ISBN
978-3-8362-1450-6
© Galileo Press, Bonn 2010 1. Auflage 2010 Das vorliegende Werk ist in all seinen Teilen urheberrechtlich geschützt. Alle Rechte vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion, der Vervielfältigung auf fotomechanischem oder anderen Wegen und der Speicherung in elektronischen Medien. Ungeachtet der Sorgfalt, die auf die Erstellung von Text, Abbildungen und Programmen verwendet wurde, können weder Verlag noch Autor, Herausgeber oder Übersetzer für mögliche Fehler und deren Folgen eine juristische Verantwortung oder irgendeine Haftung übernehmen. Die in diesem Werk wiedergegebenen Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. können auch ohne besondere Kennzeichnung Marken sein und als solche den gesetzlichen Bestimmungen unterliegen.
Inhalt Vorwort .........................................................................................................
1
Einleitung ................................................................................
33
1.1
Server-Virtualisierung ................................................................. 1.1.1 Was ist Server-Virtualisierung? ....................................... 1.1.2 Was ist eine virtuelle Maschine? ..................................... 1.1.3 Warum virtualisiert man? ............................................... 1.1.4 Gibt es auch Nachteile? .................................................. 1.1.5 Welche Arten der Virtualisierung gibt es? ....................... 1.1.6 Der Hypervisor genauer betrachtet ................................. 1.1.7 Die Entwicklungsgeschichte der Virtualisierung .............. Die VMware-Produktfamilie ....................................................... Einführung in VMware vSphere .................................................. 1.3.1 VMware Infrastructure Services ...................................... 1.3.2 VMware Application Services ......................................... 1.3.3 VMware vCenter Server ................................................. 1.3.4 Clients ............................................................................ 1.3.5 VMware Automation Tools und SDKs ............................ 1.3.6 Die verfügbaren VMware-Editionen ...............................
33 33 34 34 36 38 39 40 41 43 43 46 47 49 49 50
vSphere-Architektur ................................................................
55
2.1 2.2
55 56 56 57 57 60 61 69 71 75 75 76 79 80 81 81
1.2 1.3
2
21
2.3 2.4 2.5
2.6
Bestandteile der virtuellen Infrastruktur ...................................... vSphere-Host .............................................................................. 2.2.1 Hardware ....................................................................... 2.2.2 HCL ................................................................................ 2.2.3 Maximale Ausstattung eines ESX-Hosts .......................... 2.2.4 Version ESX vs. ESXi ....................................................... vCenter-Server ............................................................................ Architektur eines vSphere-Hosts ................................................. Grundlagen der CPU-Virtualisierung ........................................... 2.5.1 CPU-Affinity ................................................................... 2.5.2 Hyperthreading .............................................................. 2.5.3 Virtual SMP (vSMP) ....................................................... 2.5.4 Best Practices ................................................................. Grundlagen der Memory-Virtualisierung ..................................... 2.6.1 Virtual Machine Memory ............................................... 2.6.2 Memory-Overhead .........................................................
5
Inhalt
2.6.3 Memory-Overcommitment ............................................ 2.6.4 Content-based Page-Sharing .......................................... 2.6.5 Memory-Ballooning ....................................................... 2.6.6 Memory-Swapping ......................................................... 2.6.7 Best Practices ................................................................. Grundlagen der Hardwarevirtualisierung .....................................
82 82 83 84 84 85
VMotion und Storage VMotion ..............................................
89
2.7
3
3.1
3.2
4
89 90 93 98 100 100 106 106 106 107 109 112 114 117
Cluster ..................................................................................... 119 4.1
4.2
6
VMotion ..................................................................................... 3.1.1 Funktionsweise .............................................................. 3.1.2 Voraussetzung ................................................................ 3.1.3 Bedienung ...................................................................... 3.1.4 Sicherheit ....................................................................... 3.1.5 Problemfälle ................................................................... 3.1.6 Lizenzierung ................................................................... 3.1.7 Zukunftsaussichten ......................................................... Storage VMotion ........................................................................ 3.2.1 Funktionsweise .............................................................. 3.2.2 Voraussetzung ................................................................ 3.2.3 Bedienung ...................................................................... 3.2.4 Problemfälle ................................................................... 3.2.5 Lizenzierung ...................................................................
Cluster-Objekt ............................................................................ 4.1.1 Anlage des Clusters ........................................................ 4.1.2 EVC-(Enhanced VMotion Compatibility-)Mode .............. HA-Cluster .................................................................................. 4.2.1 Technologie-Übersicht ................................................... 4.2.2 Voraussetzungen für HA ................................................. 4.2.3 Lizenzierung von HA ...................................................... 4.2.4 Einrichtung von HA ........................................................ 4.2.5 HA Advanced Options .................................................... 4.2.6 Virtual Machine Options ................................................ 4.2.7 Der HA-Agent oder »Was passiert beim Hinzufügen eines ESX-Hosts zum HA-Cluster?« ................................. 4.2.8 Reconfigure for VMware HA .......................................... 4.2.9 Das Verhalten eines HA-Clusters .................................... 4.2.10 HA-Slot-Berechnung ...................................................... 4.2.11 HA-Primary- und -Secondary-Hosts ................................
119 119 120 123 124 125 126 127 130 133 135 137 137 139 140
Inhalt
4.3
4.4
5
4.2.12 HA Host Isolation ........................................................... 4.2.13 HA-Cluster-Prüfung ........................................................ 4.2.14 HA und der Maintenance-Mode .................................... 4.2.15 HA und getrennte (disconnected) ESX-Server ................. 4.2.16 HA und DNS .................................................................. 4.2.17 HA im vSphere-Client (oder: Der Cluster treibt’s bunt …) 4.2.18 HA-Limitierungen mit vSphere ....................................... 4.2.19 HA Virtual Machine Monitoring ..................................... DRS-Cluster ................................................................................ 4.3.1 Technologie-Übersicht ................................................... 4.3.2 Lizenzierung von DRS ..................................................... 4.3.3 Anlage eines DRS-Clusters .............................................. 4.3.4 Prioritäten-Ranking ........................................................ 4.3.5 DRS-Automation-Level .................................................. 4.3.6 DRS-Affinity-Rules ......................................................... 4.3.7 DRS Virtual Machine Options ........................................ 4.3.8 DRS und Resource-Pools ................................................ 4.3.9 DRS und der Maintenance-Mode ................................... 4.3.10 DRS-Limitierungen mit vSphere ..................................... 4.3.11 DPM (Distributed Power Management) ......................... 4.3.12 HA und DRS in Kombination .......................................... Fault-Tolerance ........................................................................... 4.4.1 Wie funktioniert Fault-Tolerance? .................................. 4.4.2 Technische Voraussetzungen .......................................... 4.4.3 Aktivieren von Fault-Tolerance für eine virtuelle Maschine .......................................................... 4.4.4 Bedienung von Fault-Tolerance für eine virtuelle Maschine .......................................................... 4.4.5 Snapshots und Storage VMotion mit FT ......................... 4.4.6 Was passiert im Fehlerfall? ............................................. 4.4.7 Lizenzierung von FT .......................................................
142 145 146 146 146 147 148 148 151 151 153 153 154 154 157 158 159 160 161 161 164 164 165 166 170 172 173 174 174
Installation .............................................................................. 175 5.1
VMware vSphere 4.0 .................................................................. 5.1.1 VMware-vSphere-Systemvoraussetzungen ...................... 5.1.2 Download der Installationsmedien ................................. 5.1.3 Vor der Installation ........................................................ 5.1.4 Abschalten Host-Bus-Adapter (HBA)-TreiberInstallationsmedium ....................................................... 5.1.5 Lokale Installation ..........................................................
175 175 177 179 180 181
7
Inhalt
5.2 5.3
5.4
5.5 5.6 5.7
5.8
5.9
6
191 192 205 207 216 216 216 219 220 224 226 228 229 239 260 260 261 262 263 264 267 276 276 276 277 279
Verwaltungsmöglichkeiten ..................................................... 283 6.1 6.2
6.3
6.4
8
5.1.6 Installation über das Netzwerk ....................................... 5.1.7 Installation im SAN ........................................................ 5.1.8 Installation in der virtuellen Maschine ............................ Upgrade auf vSphere von ESX 3.x ............................................... VMware vSphere 4i .................................................................... 5.3.1 Download der Installationsmedien ................................. 5.3.2 Installation vSphere 4i .................................................... 5.3.3 Erststart vSphere 4i ........................................................ 5.3.4 vSphere CLI .................................................................... VMware vCenter ......................................................................... 5.4.1 vCenter-Systemvoraussetzungen .................................... 5.4.2 Download der Installationsmedien ................................. 5.4.3 Vorbereitung der Datenbank .......................................... 5.4.4 Installation vCenter und Komponenten .......................... 5.4.5 vCenter-Protokolldateien ............................................... VMware vCenter Converter Standalone ...................................... VMware Consolidated Backup .................................................... Hochverfügbarkeit vCenter-Server .............................................. 5.7.1 Manuelle Hochverfügbarkeit .......................................... 5.7.2 Hochverfügbarkeit mit Microsoft Cluster ........................ 5.7.3 vCenter Server Heartbeat ............................................... 5.7.4 Zusätzliche Software ...................................................... Lizenzierung ............................................................................... 5.8.1 Lizenzierung vSphere ..................................................... 5.8.2 Lizenzen prüfen – VI 3.x ................................................. VMware Data Recovery ..............................................................
Weboberfläche ........................................................................... Service Console .......................................................................... 6.2.1 Aktivierung des SSH-root-Zugriffs ................................... 6.2.2 Verwendung der Service Console ohne root-Zugriff ........ 6.2.3 Absetzen von Befehlen auf der Service Console .............. vSphere-Client ............................................................................ 6.3.1 Download und Installation des vSphere-Clients .............. 6.3.2 Verwenden des vSphere-Clients ..................................... vCenter-Server ............................................................................ 6.4.1 Installation des vCenter-Servers ...................................... 6.4.2 Starten des vCenter-Servers ............................................ 6.4.3 Hinzufügen von ESX-Hosts ins vCenter ........................... 6.4.4 Verwaltung von vSphere-Hosts ......................................
283 286 287 288 289 289 290 290 296 297 298 298 299
Inhalt
6.5
6.6
7
6.4.5 Weitere Funktionen durch vCenter-Server ...................... 6.4.6 Einbindung ins Active Directory ..................................... 6.4.7 Troubleshooting vCenter-Server ..................................... Remote Command-Line Interface ............................................... 6.5.1 Installation ..................................................................... 6.5.2 Ausführen des vSphere CLI ............................................. VMware vSphere PowerCLI (ehemals Virtual Infrastructure Toolkit) .......................................
301 302 303 304 305 306 308
Netzwerk ................................................................................. 311 7.1
7.2
7.3
Netzwerk-Physik ......................................................................... 7.1.1 Gigabit-Ethernet ............................................................ 7.1.2 10-Gigabit-Ethernet ....................................................... 7.1.3 Vom virtuellen zum physischen Port ............................... Virtuelle Netzwerke .................................................................... 7.2.1 Netzwerktypen ............................................................... 7.2.2 Standard-vSwitch ........................................................... 7.2.3 Portgruppen ................................................................... 7.2.4 Erweiterte vSwitch-Konfiguration ................................... 7.2.5 Teaming ......................................................................... 7.2.6 Load-Balancing .............................................................. 7.2.7 Link-State vs. Beaconing (Network Failover Detection) ... 7.2.8 Failover – Switch Notification (Notify Switches) .............. 7.2.9 Traffic Shaping ............................................................... 7.2.10 Sicherheit ....................................................................... 7.2.11 Distributed vSwitch ........................................................ 7.2.12 Erstellen eines distributed vSwitch ................................. 7.2.13 Erstellen einer dvPortGroup ........................................... 7.2.14 Private VLANs ................................................................ 7.2.15 Vorteile von distributed vSwitches ................................. 7.2.16 Cisco Nexus ................................................................... 7.2.17 Netzwerkadapter der VMs ............................................. 7.2.18 VMdirectPath-I/O .......................................................... 7.2.19 MAC-Adressen ............................................................... 7.2.20 Nachträgliche Änderungen und Einstellungen an einem Standard-vSwitch ............................................ 7.2.21 Nachträgliche Änderungen und Einstellungen an einer Port-Group ....................................................... Architektur-Beispiele .................................................................. 7.3.1 Empfehlungen und Best Practice ....................................
311 316 317 317 321 321 323 325 329 329 330 336 337 337 339 340 342 344 349 351 352 357 360 360 362 362 363 363
9
Inhalt
7.3.2 7.3.3 7.3.4 7.3.5
8
368 369 370 371
Storage-Architektur ................................................................ 373 8.1
8.2 8.3 8.4 8.5
8.6
8.7
8.8 8.9
10
Beispiel auf Basis verfügbarer Ports im Server ................. ESX-Hosts mit zwei Netzwerkports ................................. ESX-Hosts mit vier Netzwerkports .................................. ESX-Hosts mit sechs Netzwerkports ...............................
Lokale Medien ............................................................................ 8.1.1 SATA .............................................................................. 8.1.2 SCSI und SAS ................................................................. 8.1.3 Fibre-Channel ................................................................ 8.1.4 IDE ................................................................................ 8.1.5 SSD ................................................................................ 8.1.6 USB ................................................................................ Die Wahl: Block oder File ........................................................... Storage Area Network – Was ist eigentlich ein SAN? ................... Infiniband ................................................................................... Kommunikationsadapter ............................................................. 8.5.1 Initiator .......................................................................... 8.5.2 Target ............................................................................ 8.5.3 Logical Unit Number – LUN ........................................... 8.5.4 Pfadmanagement (active/active, active/passive) ............. FC-Speichernetzwerk .................................................................. 8.6.1 Vorteile und Nachteile ................................................... 8.6.2 Support Matrix ............................................................... 8.6.3 Switch vs. Loop .............................................................. 8.6.4 Fabric ............................................................................. 8.6.5 Verkabelung ................................................................... 8.6.6 Zoning ........................................................................... 8.6.7 Mapping ........................................................................ 8.6.8 NPIV (N-Port ID Virtualization) ...................................... iSCSI-Speichernetzwerk .............................................................. 8.7.1 Vorteile und Nachteile ................................................... 8.7.2 Kommunikation ............................................................. 8.7.3 IP-SAN-Trennung ........................................................... Network-attached Storage .......................................................... VMware-Storage-Architektur ...................................................... 8.9.1 VMkernel-Storage-Stack ................................................ 8.9.2 Festplattendateien ......................................................... 8.9.3 Auslagerungsdateien ...................................................... 8.9.4 VMFS im Detail ..............................................................
373 373 376 377 377 377 380 380 382 384 384 384 389 390 391 395 395 396 397 397 397 398 400 400 401 402 403 403 405 409 409 414 421 424
Inhalt
8.10
9
8.9.5 Virtuelle Maschinen ....................................................... 8.9.6 VMware-Snapshots ........................................................ Best Practices Storage ................................................................. 8.10.1 RAID-Leistungsfähigkeit ................................................. 8.10.2 RAID-Größe ................................................................... 8.10.3 Geschwindigkeit vs. Kapazität ........................................ 8.10.4 LUN-Größe .................................................................... 8.10.5 RAID Rebuild und HP EVA Levelling ..............................
439 443 446 446 447 449 451 451
Storage-Konfiguration unter VMware ................................... 453 9.1 9.2
9.3
9.4
Verwendungszwecke von Storage ............................................... Einrichtung und Konfiguration von Datastores ............................ 9.2.1 Fibre-Channel ................................................................ 9.2.2 iSCSI .............................................................................. 9.2.3 NFS-Datastores .............................................................. Umgang mit Datastores .............................................................. 9.3.1 Rescan SAN .................................................................... 9.3.2 Storage Views ................................................................ 9.3.3 Datastore-Browser ......................................................... 9.3.4 Storage-Alerts ................................................................ 9.3.5 Datastore-Erweiterung ................................................... NetApp-Spezialitäten .................................................................. 9.4.1 Cloning-Technologien .................................................... 9.4.2 Tuning und Optimierung ................................................ 9.4.3 Best Practices .................................................................
454 455 455 471 479 485 486 486 488 489 490 492 492 498 511
10 Hersteller-Best-Practices ........................................................ 523 10.1
10.2
Storage-Produkte ........................................................................ 10.1.1 3PAR ............................................................................. 10.1.2 CoRAID .......................................................................... 10.1.3 EMC ............................................................................... 10.1.4 Hitachi Data Systems ...................................................... 10.1.5 HP ................................................................................. 10.1.6 IBM ............................................................................... 10.1.7 Dell EqualLogic PS-Serie ................................................ 10.1.8 Pillar .............................................................................. 10.1.9 NetApp .......................................................................... Storage-Virtualisierung ............................................................... 10.2.1 Herstellerunabhängige Replikation ................................. 10.2.2 Transparente Ausfallsicherheit ........................................
523 523 531 532 534 539 543 543 568 573 575 575 575
11
Inhalt
10.2.3 10.2.4 10.2.5 10.2.6 10.2.7 10.2.8 10.2.9
Erweiterte Volume-Konfigurationen ............................... Implementierung ........................................................... DataCore ....................................................................... HP LeftHand .................................................................. FalconStor Software ....................................................... Emulex ........................................................................... QLogic ...........................................................................
576 576 577 585 590 596 596
11 Konfiguration von ESX und vCenter ....................................... 599 11.1
Host-Profiles ............................................................................... 11.1.1 Erstellen eines Host-Profiles ........................................... 11.1.2 Anpassen eines Host-Profiles .......................................... 11.1.3 Host/Cluster mit Profil assoziieren .................................. 11.1.4 Anwenden eines Host-Profiles ........................................ 11.2 NTP ............................................................................................ 11.2.1 NTP-Dienst unter vSphere .............................................. 11.2.2 NTP unter ESXi .............................................................. 11.2.3 NTP in der virtuellen Maschine mittels VMware Tools .... 11.2.4 Zeitsynchronisationsprobleme ........................................ 11.3 SNMP ......................................................................................... 11.3.1 SNMP unter ESX ............................................................ 11.3.2 SNMP unter ESXi ........................................................... 11.3.3 SNMP in Gastbetriebssystemen ...................................... 11.4 DNS ............................................................................................ 11.5 Einrichtung von Resource-Pools .................................................. 11.6 VMware vApp ............................................................................ 11.6.1 Erstellen einer vApp ....................................................... 11.6.2 Verknüpfung einer vApp mit virtuellen Servern .............. 11.6.3 vApp – Einstellungen ...................................................... 11.7 Automatisches Starten und Stoppen der VMs mit dem Host ....... 11.8 vSphere-Firewall ......................................................................... 11.8.1 Öffnen und Schließen von Ports über die Service Console ........................................................ 11.8.2 Automatisches Starten und Stoppen ............................... 11.9 Lizenz-Server .............................................................................. 11.9.1 Konfiguration des vCenter-Lizenz-Servers ....................... 11.9.2 Konfiguration des Lizenz-Servers für VI 3.x-Systeme ....... 11.9.3 DNS-Name für Lizenz-Server ........................................ 11.9.4 Umzug eines Lizenz-Servers ......................................... 11.10 Erweiterte Konfiguration .............................................................
12
599 601 602 603 604 605 605 607 608 609 612 612 614 615 615 616 619 619 620 622 626 627 628 630 631 631 634 637 638 638
Inhalt
11.11
11.12 11.13
11.14 11.15
11.10.1 Speicherkonfiguration .................................................. 11.10.2 Ablage der VM-Swapfiles ............................................. 11.10.3 Host-Systemressourcen ................................................ 11.10.4 Erweiterte Einstellungen .............................................. vCenter-Berechtigungen ............................................................. 11.11.1 Rollen .......................................................................... 11.11.2 Benutzer einrichten ...................................................... 11.11.3 Absicherung gegenüber dem Betriebssystem ................ Performance-Daten des Hosts im vCenter ................................... Weitere Funktionen des vCenters ............................................... 11.13.1 Storage Views .............................................................. 11.13.2 Maps ........................................................................... 11.13.3 Events .......................................................................... 11.13.4 Scheduled Tasks ........................................................... 11.13.5 System-Logs ................................................................. 11.13.6 Sessions ....................................................................... 11.13.7 Health Status ............................................................... 11.13.8 Dienste anzeigen .......................................................... vCenter-Konfigurationseinstellungen .......................................... Einrichten von Alarmen ..............................................................
638 639 640 642 643 644 647 651 652 658 658 661 661 663 665 666 667 667 668 676
12 Konfiguration von vCenter-Add-ons ...................................... 681 12.1
12.2
12.3 12.4 12.5
Einsatz des vCenter Update Managers ........................................ 12.1.1 Installation ................................................................... 12.1.2 Konfiguration ............................................................... 12.1.3 Download von Updates ................................................ 12.1.4 Download von Updates auf Offline-Update-Manager ... 12.1.5 Baselines ...................................................................... Einsatz des VMware vCenter Converters ..................................... 12.2.1 VMware vCenter Converter .......................................... 12.2.2 VMware vCenter Converter Standalone ........................ 12.2.3 Nacharbeiten nach der Übernahme .............................. VMware Guided Consolidation ................................................... VMware vCenter Linked Mode ................................................... VMware vCenter Server Heartbeat .............................................. 12.5.1 Heartbeat – System ...................................................... 12.5.2 Heartbeat – Log ........................................................... 12.5.3 Heartbeat – Application ............................................... 12.5.4 Heartbeat – Communication ........................................ 12.5.5 Heartbeat – Data ..........................................................
681 682 683 689 689 693 700 700 709 718 719 719 722 724 726 728 735 738
13
Inhalt
12.6
12.5.6 Heartbeat – Alerts ........................................................ 12.5.7 Heartbeat – Rollback .................................................... 12.5.8 Heartbeat – Hinweise ................................................... VMware Data Recovery ..............................................................
739 741 742 742
13 Virtuelle Maschinen ................................................................ 751 13.1
13.2
13.3
13.4
13.5 13.6 13.7
14
Grundlagen ................................................................................. 13.1.1 Was ist eine virtuelle Maschine? .................................. 13.1.2 Virtuelle Hardware ....................................................... 13.1.3 Bestandteile einer virtuellen Maschine ......................... Erstellung von virtuellen Maschinen ............................................ 13.2.1 Netzwerkkonfiguration ................................................. 13.2.2 Festplattenkonfiguration .............................................. 13.2.3 Aktualisieren der virtuellen Hardware .......................... Eigenschaften einer virtuellen Maschine – Optionen ................... 13.3.1 Änderung des Namens und des Ablageorts der VM ...... 13.3.2 Änderung des Gastbetriebssystems .............................. 13.3.3 Erweiterung der Power-Aktivitäten durch die VMware Tools .............................................................. 13.3.4 Automatische Ausführung der VMware-Tools-Skripte ... 13.3.5 Automatische Aktualisierung der VMware Tools .......... 13.3.6 Zeitsynchronisation der VM mit dem ESX-Server .......... 13.3.7 Power-Management des Gastbetriebssystems .............. 13.3.8 Erweiterte Konfiguration: Logging, Debugging, Acceleration und erweiterte Konfigurationsparameter ............ 13.3.9 Erweiterte Konfiguration: CPU Identification Mask ....... 13.3.10 Erweiterte Konfiguration: Memory/CPU Hotplug .......... 13.3.11 Erweiterte Konfiguration: Boot Options ....................... 13.3.12 Erweiterte Konfiguration: Paravirtualization ................. 13.3.13 Erweiterte Konfiguration: Fibre Channel NPIV .............. 13.3.14 Erweiterte Konfiguration: CPU/MMU Virtualization ..... 13.3.15 Erweiterte Konfiguration: Swapfile Location ................. Ressourcenmanagement einer VM .............................................. 13.4.1 CPU-Ressourcen ........................................................... 13.4.2 Memory-Ressourcen .................................................... 13.4.3 Disk-Ressourcen .......................................................... Starten, Stoppen und weitere Power-Aktivitäten ........................ Installation des Gastbetriebssystems ........................................... Konfiguration und Anpassung von virtuellen Maschinen ............. 13.7.1 Ändern der Hardware ...................................................
751 751 751 758 760 763 764 767 768 769 769 770 771 772 772 773 773 774 775 776 776 776 778 779 780 780 783 787 787 789 791 791
Inhalt
13.7.2
13.8 13.9
13.10
13.11
13.12
13.13
13.14 13.15
Hinzufügen weiterer Hardware im laufenden Betrieb (HotAdd) ..................................................................... 13.7.3 Statische MAC-Adresse über GUI ................................. 13.7.4 Umgang mit Wechselmedien ....................................... Optimierung einer virtuellen Maschine ....................................... VMware Tools ........................................................................... 13.9.1 Zeitsynchronisation ...................................................... 13.9.2 Installation der VMware Tools ..................................... 13.9.3 Manuelle Installation ................................................... 13.9.4 Aktualisierung der VMware Tools ................................. Migration von virtuellen Maschinen ............................................ 13.10.1 Verschiedene Arten der Migration ............................... 13.10.2 Verwendung des Migration-Wizards zur Migration einer VM ..................................................................... Templates und Clones ................................................................. 13.11.1 Was sind Template und welchen Nutzen bringen sie? ... 13.11.2 Templates im vCenter .................................................. 13.11.3 Templates erstellen, bearbeiten und löschen ................ 13.11.4 Virtuelle Maschinen mit Hilfe von Templates erstellen 13.11.5 Was sind Clones, und wir erstellt man sie? ................... Anpassen der Gastbetriebssysteme ............................................. 13.12.1 Voraussetzungen .......................................................... 13.12.2 Bearbeiten von Anpassungsspezifikationen ................... 13.12.3 Anpassung des Gastbetriebssystems ............................. Snapshots ................................................................................... 13.13.1 Funktionsweise ............................................................ 13.13.2 Snapshot-Dateien auf dem Datastore ........................... 13.13.3 Hilfe bei Problemen ..................................................... 13.13.4 Die Snapshot-Hierarchie .............................................. 13.13.5 Das Erstellen eines Snapshots (Take a Snapshot) .......... 13.13.6 Das Persistieren eines Snapshots (Delete a Snapshot) ... 13.13.7 Das Verwerfen des aktuellen Zustands oder die Wiederherstellung eines Snapshots (Revert to Snapshot) Die virtuelle Maschine im vSphere-Client .................................... Erweitertes VM-Management ..................................................... 13.15.1 Killen einer hängenden VM .......................................... 13.15.2 Überwachung der CPU-Performance von virtuellen Maschinen mit ESXTOP ...............................................
792 794 795 796 798 799 799 800 802 804 804 805 805 805 806 807 808 809 809 810 811 814 815 815 817 817 818 820 820 821 821 828 828 829
15
Inhalt
14 Ausfallsicherheit ...................................................................... 831 14.1
14.2
14.3 14.4
Sicherung – Rücksicherung .......................................................... 14.1.1 Sicherung des ESX-Hosts ................................................ 14.1.2 Sicherung der Komponenten .......................................... 14.1.3 Sicherung der virtuellen Maschinen ................................ 14.1.4 Backup von vSphere-Umgebungen mit NetApp-Storage 14.1.5 VMware Data Recovery .................................................. Cluster-Konfiguration ................................................................. 14.2.1 Voraussetzungen für Microsoft Cluster Service ............... 14.2.2 Cluster-Konfiguration auf einem Host ............................. 14.2.3 Cluster-Konfiguration über mehrere Hosts ...................... 14.2.4 Cluster-Konfiguration zwischen physischem und virtuellem Knoten ................................................... Virtual Machine Monitoring ....................................................... Fault-Tolerance ...........................................................................
831 831 832 836 839 852 854 854 856 863 864 866 869
15 Sicherheit ................................................................................ 871 15.1 15.2 15.3
15.4
15.5
15.6 15.7
16
Service-Console-Netzwerk .......................................................... VMware ESX 4i ........................................................................... root-Zugriff ................................................................................. 15.3.1 su, sudo ......................................................................... 15.3.2 wheel-Gruppe ................................................................ 15.3.3 root-Zugriff über die Konsole ......................................... 15.3.4 root-Zugriff über SSH ..................................................... 15.3.5 root-Zugriff über ein SSH-Zertifikat ................................ 15.3.6 root-SSH-Zugriff – Host .................................................. Benutzerverwaltung .................................................................... 15.4.1 Passwortkomplexität ...................................................... 15.4.2 Passwortgültigkeit .......................................................... 15.4.3 Zentrale Benutzerverwaltung .......................................... 15.4.4 Zurücksetzen des root-Passworts .................................... Firewall ....................................................................................... 15.5.1 Firewall-Bedienung ........................................................ 15.5.2 Standardports ................................................................ 15.5.3 Custom Ports ................................................................. 15.5.4 TCP-Wrappers ................................................................ 15.5.5 VMware WebAccess ...................................................... SSL-Zertifikat .............................................................................. Überwachung .............................................................................
872 872 872 873 873 875 876 876 880 881 881 884 886 887 887 889 889 890 892 894 894 895
Inhalt
15.8 15.9
15.10
15.11
15.12
15.13
Protokollierung ........................................................................... Nützliche Zusatzsoftware ............................................................ 15.9.1 Configuresoft Compliance Checker ............................... 15.9.2 Tripwire ConfigCheck ................................................... 15.9.3 SolarWinds VM Monitor .............................................. Virtuelle Maschinen in der DMZ ................................................. 15.10.1 Isolation ....................................................................... 15.10.2 Firewalls und VMs ....................................................... 15.10.3 Best Practices ............................................................... VMware vShield Zones ............................................................... 15.11.1 Installation ................................................................... 15.11.2 VMotion, DRS und HA ................................................. 15.11.3 Ausfall der vShield-VM ................................................ 15.11.4 Regelkonfiguration, die VM-Wall ................................. 15.11.5 Reports – VM-Flow ...................................................... VMs und der Virenschutz ............................................................ 15.12.1 Pattern-Updates ........................................................... 15.12.2 CPU-Last im Host ......................................................... 15.12.3 Antwortzeiten im Gast ................................................. 15.12.4 File-Server mit Virenschutz ........................................... VMware VMsafe API ..................................................................
896 898 899 900 900 901 902 902 903 903 904 910 911 911 912 913 913 914 914 914 915
16 Kapazitätsplanung mit dem VMware Capacity Planner ........ 917 16.1 16.2
16.3 16.4
Erste Vorüberlegungen zu einem Migrationsprojekt .................... Arbeitsweise und Funktion des Capacity Planners ....................... 16.2.1 Data Collector und Information Warehouse ................. 16.2.2 Collector-Modul .......................................................... 16.2.3 Data-Manager-Modul .................................................. 16.2.4 Data Analyzer .............................................................. 16.2.5 Dashboard ................................................................... Der Capacity Planner .................................................................. Die Arbeit mit dem Data Collector .............................................. 16.4.1 Auffinden der Zielsysteme ............................................ 16.4.2 Verbindungsaufbau zu den Zielsystemen ...................... 16.4.3 Manuelle Inventarisierung ............................................ 16.4.4 Manuelle Leistungsdatenermittlung ............................. 16.4.5 Die Datensynchronisationsfunktion des Data Collectors 16.4.6 Automatisierte Ausführung von Jobs ............................ 16.4.7 Registrierung des Data Collectors im Information Warehouse ..................................................................
918 920 920 922 923 924 924 925 925 925 926 927 928 928 929 931
17
Inhalt
16.5 16.6
16.7
Das Dashboard im Detail ............................................................ Ablauf eines Kapazitätsplanungsprojekts ..................................... 16.6.1 Company-ID-Request ................................................... 16.6.2 Vorbereitende Maßnahmen ......................................... 16.6.3 Überwachung der Messung .......................................... 16.6.4 Außerbetriebnahme des Data Collectors ...................... Auswertung ................................................................................ 16.7.1 Phantom-Server ........................................................... 16.7.2 Konsolidierungsszenario ............................................... 16.7.3 Ergebnis ....................................................................... 16.7.4 Was bedeutet Verfügbarkeit? ....................................... 16.7.5 Berücksichtigung von Verfügbarkeit ............................. 16.7.6 Betrachtung der Skalierbarkeit ..................................... 16.7.7 Ermittlung der Konsolidierungsratio bzw. der Grad der Konsolidierung bei der Virtualisierung .................... 16.7.8 Der Weg zum CP-Admin ..............................................
932 947 949 950 952 953 954 954 955 958 958 959 961 962 964
17 Zusatzsoftware von VMware .................................................. 965 17.1
17.2 17.3 17.4
17.5
18
Automatisierung ......................................................................... 17.1.1 VMware vCenter Lab Manager ..................................... 17.1.2 VMware vCenter Orchestrator ..................................... 17.1.3 VMware vCenter Lifecycle Manager ............................. 17.1.4 VMware vCenter CapacityIQ ........................................ Billing: VMware vCenter Chargeback .......................................... Performance: VMware vCenter AppSpeed .................................. Desktop ...................................................................................... 17.4.1 ThinApp 4 .................................................................... 17.4.2 VMware View 4 ........................................................... vCenter Site Recovery Manager .................................................. 17.5.1 Der Katastrophenfall .................................................... 17.5.2 Aufbau und Implementierung ...................................... 17.5.3 Storage-Replication-Modul (SRA) ................................. 17.5.4 Site Recovery Manager Plug-in ..................................... 17.5.5 Protection Groups ........................................................ 17.5.6 Recovery-Plan .............................................................. 17.5.7 Testen des Desasterfalls ............................................... 17.5.8 Der Desasterfall ........................................................... 17.5.9 Neuerungen in SRM 4 .................................................. 17.5.10 Anmerkungen ..............................................................
965 965 970 971 973 975 979 982 982 984 995 996 996 997 998 999 1000 1001 1002 1002 1004
Inhalt
18 Die Lizenzierung von vSphere ................................................. 1005 18.1
18.2
18.3 18.4
Die unterschiedlichen Pakete ...................................................... 18.1.1 vSphere4 – for free ......................................................... 18.1.2 vSphere4 – Small Business .............................................. 18.1.3 vSphere4 – Standard, Advanced, Enterprise und Enterprise Plus ........................................................ 18.1.4 Erweiterung einer Umgebung durch Hinzufügen von Funktionalität. ................................................................ Support und Subscription ........................................................... 18.2.1 Die unterschiedlichen Schweregrade .............................. 18.2.2 Wie wird eine Supportanfrage bei VMware gestellt? ...... Die vSphere 4-Lizenzen .............................................................. Die VI 3-Lizenzierung .................................................................
1006 1006 1007 1008 1009 1010 1011 1012 1019 1024
Die Autoren ................................................................................................ 1031 Index ........................................................................................................... 1033
19
Vorwort
Da wir im Buch die sehr gute Diagram- und Icon-Library von VMware zur Erstellung der Grafiken genutzt haben, sind wir verpflichtet, folgendes Statement abzudrucken: This document was created using the official VMware icon and diagram library. Copyright © 2009 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware does not endorse or make any representations about third party information included in this document, nor does the inclusion of any VMware icon or diagram in this document imply such an endorsement.
Vorwort Florian Benne Haben Sie ein Handy? Haben Sie einen Kühlschrank? Sie werden wahrscheinlich mit »ja« antworten. Jedoch weder ein Handy noch der Kühlschrank funktionieren von sich aus, man benötigt eine passende Infrastruktur dafür. Für die Nutzung eines Handys gibt es den GSM-Standard, der es Ihnen unabhängig vom Endgerät und vom Provider ermöglicht, unter Ihrer Rufnummer erreichbar zu sein. Damit das funktioniert, müssen Sie nicht selbst ein Mobilfunknetz betreiben. Als Benutzer entscheiden Sie sich für ein Endgerät und suchen sich einen Provider, der ein auf Ihr Nutzungsverhalten abgestimmtes Angebot bereithält. Sie beziehen Mobilfunk als Service, ohne aber abhängig von dem einen Anbieter oder dem einen Handy zu sein. Beides können Sie problemlos wechseln, und Sie sind immer noch unter derselben Rufnummer erreichbar. Beim Strom haben Sie die Auswahl zwischen vielen Anbietern, die sich im Preis und in der Leistung, aber nicht in der Qualität und in der Norm des gelieferten Stroms unterscheiden. Ihr Kühlschrank wird gleich gut mit allen Anbietern funktionieren. Sie brauchen kein eigenes Kraftwerk, damit Sie Ihre Lebensmittel kühlen können, denn Sie beziehen Strom als Service. Und wenn Sie neben einem Kühlschrank auch noch eine Mikrowelle mit Strom versorgen wollen, funktioniert das ohne weiteres. Genauso können Sie den Anbieter wechseln, ohne neue
21
Vorwort
Geräte kaufen zu müssen. Natürlich funktioniert das! Aber selbstverständlich nur, weil es Standards und Normen gibt. Es sind also diese Standards, die Produzenten, Anbietern und Konsumenten das Leben einfacher machen. Und was ist mit IT? Gibt es dort einen Standard, der mich unabhängig vom Zusammenspiel von Einzelkomponenten, Standorten und Art des Service macht? Gibt es IT als Service? Nun, üblicherweise nicht. Rechenzentren sind über Jahrzehnte hinweg kontinuierlich wild gewachsen. Ständig wurden neue Komponenten hinzugefügt: neue Server, neuer Storage, neue Applikationen, neue Betriebssysteme. Dieser extreme Komponentenmix ist unter Management- und Wartungsaspekten ein Graus. Alltägliche Anforderungen an die IT, wie Sicherstellung von Verfügbarkeit, Datenkonsistenz und Sicherheit, müssen exakt abgestimmt sein auf die jeweiligen Komponenten: Das Verfügbarkeitskonzept einer Datenbank unterscheidet sich maßgeblich von einem Verfügbarkeitskonzept eines Mailservers. Ein Windows-Server wird anders gesichert als ein Linux-Server. Server-Hersteller A hat andere Managementagenten als Server-Hersteller B – von den weiteren Komponenten wie Netzwerk und Storage ganz zu schweigen. Diese Heterogenität führt zu einem sehr komplexen und somit teuren und fehleranfälligen und dadurch schwerfälligen Management der IT. Doch ohne Zweifel ist die Verfügbarkeit und Agilität der IT eine zwingende Voraussetzung dafür, dass Unternehmen überhaupt erfolgreich und wettbewerbsfähig arbeiten können: Unternehmen gleich welcher Größe sind auf die funktionierende IT angewiesen. VMware vSphere ist angetreten, die Abhängigkeiten im Rechenzentrum aufzulösen. Die Technologie dahinter nennt sich Virtualisierung. Mit vSphere verschmelzen die Eigenschaften individueller Ressourcen einzelner Server in Form von CPU, RAM, Netzwerk und Storage zu einem dynamischen Supercomputer. Oder anders ausgedrückt: vSphere ist der Software-Mainframe des 21. Jahrhunderts. In diesem Software-Mainframe spielt die individuelle Ressource eine untergeordnete Rolle. Die Summe aller Ressourcen wird abstrahiert für das Betreiben von virtuellen Maschinen bereitgestellt. VMs beziehen ihre Ressourcen dynamisch aus den verschmolzenen Ressourcen. Und werden diese knapp, so wird der Mainframe dynamisch und ohne Serviceunterbrechung durch das Hinzufügen neuer Komponenten erweitert. Diese Unabhängigkeit von Komponenten gilt auch für das Betriebssystem und die Applikation in der VM. vSphere ermöglicht es, die Anforderungen an Verfügbarkeit, Datenkonsistenz und Sicherheit losgelöst von dem verwendeten Betriebssystem oder den Applikationen zu erfüllen. Dadurch wird das gesamte IT-Management radikal vereinfacht, was zu einer zurückgewonnenen Agilität
22
Vorwort
führt, die dazu beiträgt, den Unternehmenserfolg sicherzustellen. Und das bezieht sich nicht nur auf Server, sondern im gleichen Maße auf Desktops und sehr bald auch auf Mobilfunkgeräte. Gibt es dort einen Standard, der mich unabhängig vom Zusammenspiel von Einzelkomponenten, Standorten und Art des Service macht? Gibt es also IT als Service? Die Frage können Sie sich spätestens nach dem Lesen dieses Buchs selbst beantworten.
Vorwort und Danksagung Günter Baumgart Ich studierte Elektrotechnik an der Fachhochschule Bochum und absolvierte ein weiterbildendes Studium »IT-Sicherheit – Administration und Sicherheit von ITSystem und -Netzwerken« an der Ruhruniversität Bochum. Seit 1990 bin ich im Bereich der Softwareentwicklung und dem Engineering von IT-Systemen tätig. 1999 setzte ich erstmalig ein Virtualisierungsprodukt aus dem Hause VMware ein und war augenblicklich ein Anhänger von Virtualisierungstechnologien. An dieser Stelle bedanke ich mich bei Dennis Zimmer, der mir die Möglichkeit gegeben hat, in seinem Buch den Capacity Planner und einige damit verbundene Themen zu behandeln sowie die Lizenzierung von vSphere. Es hat wesentlich länger gedauert, die Kapitel 16, »Kapazitätsplanung mit dem VMware Capacity Planner«, und Kapitel 18, »Die Lizenzierung von vSphere«, zu schreiben, als ich mir ursprünglich vorgestellt hatte. Als ich mit Dennis auf der VMworld in Cannes darüber sprach, zu seinem neuen Buch einige Seiten beizusteuern, war mir nicht ganz klar, worauf ich mich da eigentlich einließ. Nun gut, Versprechen, die ich einmal abgegeben habe, halte ich auch. Es hat viele Wochenenden, Feiertage und Nächte gebraucht, um dieses Kapitel fertigzustellen. Meine Frau Annette war immer eine großartige Unterstützung und stand mir jederzeit zur Verfügung, um so zu schreiben, dass es den interessierten Leser auch zum Weiterlesen bewegt. Sie hat mir auch immer den Rücken freigehalten, so dass ich auch die Möglichkeit hatte, die Ruhe zu finden, die man benötigt, um so etwas auf die Beine zu stellen. Alle, die dieses Kapitel lesen und Kinder haben, werden wissen, wovon ich spreche. Ganz besonders bedanke ich mich bei Maxi und Flori, die auf ihren Papa gerade in der schönen Zeit des Jahres oftmals verzichten mussten.
23
Vorwort
Vorwort Oliver Kügow Mein Name ist Oliver Kügow, ich bin 31 Jahre alt und arbeite seit 13 Jahren in der IT-Branche. Begonnen hat mein Bezug zur IT schon in der Jugend, als ich neben der Schule bei diversen Internet-Providern mit Linux und Netzen arbeitete und dort mein Wissen aufbauen konnte. Anschließend studierte ich Wirtschaftsinformatik an der Technischen Fachhochschule in Berlin – als Werksstudent bei der Siemens AG in Form eines berufsbegleitenden Studiums. Bei Siemens arbeitete ich während meines Studiums in der Systemadministration, im Netzwerkbetrieb und in der Systemplanung. Während dieser Zeit lernte ich auch die Firma NetApp und deren beeindruckende Produkte kennen; damals wurde bei Siemens das Produkt »NetCache« als Proxy-Lösung eingesetzt, wenig später kam ich auch mit den NetApp-StorageProdukten in Kontakt. Neben meinem Studium hielt ich bereits Schulungen für Fujitsu-Siemens in Nürnberg ab, ich lernte Kurt-Jürgen Jacobs und Dirk Schmiedt kennen – zwei immer noch sehr geschätzte Geschäftspartner. Vor dem Ende meines Studiums machte ich mich zusammen mit Richard Müller selbstständig, wir gründeten die team(ix) GmbH, ein Systemhaus mit starkem Dienstleistungsfokus. team(ix) wird nun bald 10 Jahre alt – unser Geschäftsfeld konzentriert sich auf die IT-Infrastruktur: Virtualisierung, Speicherlösungen, Netzwerke und Betriebssysteme.
Cloud-Computing – mein Verständnis Wer schon länger in der IT-Branche tätig ist, der weiß sehr genau, dass dort gerne in »Wellen« gedacht wird; verschiedene Trends setzen sich durch und wiederholen sich – manchmal auch in gegenläufigen Zyklen. Wir schwanken von Zentralisierung zu Dezentralisierung, von Outsourcing zu Insourcing. Der aktuelle Trend heißt ganz klar »Cloud-Computing«. Ich bin der Meinung, dass es sich hierbei um mehr als nur einen »Hype« handelt – es ist die Transformation der klassischen IT weg vom Silo-Denken hin zu einer dynamischen IT-Infrastruktur. Das muss nicht gleich »Outsourcing« bedeuten, sondern lediglich die Entwicklung von Rechenzentren hin zu Dienstleistungsfabriken, die es ermöglichen, agilere Geschäftsprozesse abzubilden und somit die
24
Vorwort
Wettbewerbsfähigkeit von Unternehmen zu stärken. IT-Abteilungen werden sich künftig weniger um den Infrastrukturbetrieb kümmern, sondern mehr Zeit in Applikationen und Geschäftsprozesse investieren können. Dennoch: Die Basis-Infrastruktur muss zuverlässig funktionieren, und Virtualisierung ist eine wichtige Komponente dafür. Wie man richtig virtualisiert und welche Hürden im Zusammenhang mit zentralen Speicherlösungen zu nehmen sind, können Sie in meinem Kapitel 9, »Storage-Konfiguration unter VMWare«, nachlesen. Viel Spaß dabei!
Danksagung An dieser Stelle möchte mich ganz herzlich bei Dennis Zimmer bedanken, der mich bat, an diesem Buch mitzuwirken. Es war schon immer mein Wunsch, ein Buch zu schreiben. Deshalb denke ich, dass ein eigenes Kapitel ein guter Anfang ist auf dem Weg zu meinem Ziel. Des weiteren möchte ich meinem team(ix)-Team dafür danken, dass sie immer einen exzellenten Job bei unseren Kunden machen und dafür sorgen, dass die Kunden stets eine solide IT-Infrastruktur betreiben können! Danke auch an Kurt-Jürgen Jacobs und seine Schulungsfirma qSkills aus Nürnberg; ohne dich wären wir, team(ix), heute nicht so weit, wie wir es jetzt sind. Last but not least: Danke auch an Steffi, meine Frau, und Alex, meinen kleinen Sohn, für die Geduld, die ihr aufgebracht habt, während ich an meinem Kapitel geschrieben habe, anstatt euch die Zeit zu widmen!
Vorwort Carsten Schäfer Mein Name ist Carsten Schäfer, und ich bin seit 1990 beruflich in der IT-Welt unterwegs. Hier ist mein Aufgabengebiet breitgefächert und umfasst heute für meine selbständige Beratertätigkeit in der G-TAC IT-Beratung die Technologien Microsoft Active Directory Services und Virtualisierung mit VMware vSphere und Hyper-V, vornehmlich für den Einsatz in Server-Farmen und EnterpriseUmgebungen. Darüber hinaus agiere ich in Projekten auch als GPM-zertifizierter Projektmanager. Eine weitere große Leidenschaft ist die Softwareentwicklung im .NET-Umfeld, die ich zum einen in Projekten zur Betriebsautomatisierung von IT-Landschaften auslebe und zum anderen als geschäftsführender Gesellschafter der G-TAC Software Unternehmergesellschaft – hier mündet diese Leidenschaft in Produkte zur
25
Vorwort
Automatisierung von Virtualisierungs-, Storage- und Printing-Umgebungen. Unsere Arbeit fußt auf dem Clean-Code-Developer-Wertesystem, und mein Partner Matthias Friedrich und ich halten diese Fahne fortwährend nach oben, um qualitativ hochwertige Produkte mit Spaß und Genuss herzustellen.
Danksagung Zuerst möchte ich Dennis Zimmer für sein Vertrauen danken und für die Chance, an diesem Projekt mitzuarbeiten. Ging doch diesem Buch eine lange Zeit mit Vorbereitungen und Änderungen voraus, so dass wir heute froh und stolz sein können, Ihnen dieses Werk zur Verfügung zu stellen. Auch sei hier sein erstklassiger Support während der letzten Jahre erwähnt, für den ich mich gerne zusätzlich bedanken möchte. Ein weiterer Dank geht an Bertram Wöhrmann für seine außerplanmäßige Unterstützung neben der Arbeit an seinen Kapiteln. An unsere Sponsoren richte ich nochmals ein großes Dankeschön. Sie haben es uns ermöglicht, auf einer performanten Umgebung unsere Tests fahren zu können! Natürlich bedanke ich mich auch bei dem gesamten Autorenteam dieses Buches und bei Thomas Weyell – hat doch die Anstrengung aller Mitstreiter ein sehr umfassendes Werk zutage gebracht. Unserem Lektor Jan Watermann gebührt ebenfalls mein Dank für seine Geduld und Unterstützung bei diesem Projekt. Abschließend noch mein herzlichstes Dankeschön an meinen Sohn Tim, der mich nicht immer belagern konnte, wie er wollte, und sicherlich mehr als einmal gedacht hat: »Warum sitzt mein Papa immer vor dem kleinen Fernseher und schaut so ...?«
Vorwort Sebastian Wischer Vermutlich mit einer der jüngsten in diesem Autorenteam, erblickte ich vor 26 Jahren das Licht der Welt und 16 Jahre später die Bits und Bytes in der IT. Im Gegensatz zu vielen IT-Kollegen begann ich meine Ausbildung bei der Siemens Professional Education in Paderborn ganz ohne Vorkenntnisse. Aber anscheinend hatte ich in den drei Jahren genug Wissen aufgebaut, denn Fujitsu Siemens Computers wollte mich im Storage-Bereich weitere Erfahrungen sammeln lassen.
26
Vorwort
Nach einem Jahr wurde mir die Aufgabe übertragen, mich auf die FAS-Systeme von NetApp zu spezialisieren. Dazu gehörte es, die Entwicklungsprojekte innerhalb der Fujitsu Siemens mit NetApp-Wissen zu unterstützen und weiterzuentwickeln. Virtualisierung durfte dabei nicht fehlen. Ich muss noch heute daran denken, wie ich mit Spannung meinen ersten VMotion-Prozess beobachtete. Die Mitarbeit in einem Proof of Concept über VMware in Kombination mit MetroCluster half mir, dank sehr offener Kollegen einen tieferen Einblick zu bekommen. Wie es meistens so ist, junge Menschen werden irgendwann einmal flügge, ich musste etwas von der Welt sehen und wechselte das Unternehmen. Über einen kurzen Umweg bekam ich in Nürnberg die Chance, mein Interesse an Storage und Virtualisierung zu kombinieren. team(ix) brauchte einen neuen Consultant und Trainer. So bin ich heute für team(ix) bei qSkills als Dozent im Bereich VMware tätig. Die notwendige Praxiserfahrung sammele ich fortwährend in Kundenprojekten. Dabei lerne ich die verschiedenen Anforderungen und Gegebenheiten kennen, denen sich Administratoren im täglichen Leben stellen müssen. Virtualisierung umfasst nicht nur ein Thema, wie z. B. Betriebssysteme, Server, Netzwerke oder Storage. Virtualisierung betrifft alle diese Themen, und das ist sicher gerade die Herausforderung, aber auch die Chance. Denn genau diese Themen haben wir in unserer Vorstellung von einer »soliden IT-Infrastruktur« vereint und wollen mit diesem Fachwissen unseren Kunden helfen. Daher bin ich auch sehr stolz darauf, dass wir als ein eher kleineres Unternehmen zu den ersten VMware-Enterprise-Partnern gehören, die mit dem Zusatz »Infrastructure Competency« ausgezeichnet wurden!
Danksagung Mein Dank gilt natürlich in erster Linie Dennis Zimmer. Hätte mir jemand gesagt, dass ich in diesem Jahr ein Buchkapitel schreibe, ich hätte nur herzlich gelacht. Vor allem nicht in dem Nachfolger zu dem Buch, mit dem ich selbst noch einige Lehrstunden verbracht habe. Der zweite Dank geht an meine Kollegen von team(ix). Ihr habt es mir ermöglicht, mich aus dem täglichen Geschäft zurückzuziehen und mich voll auf dieses Buch zu konzentrieren. Zudem stand mir euer Wissen jederzeit zur Verfügung. Dem gesamten Autorenteam danke für die sehr gute Unterstützung. Egal ob es fachliche Fragen, Organisatorisches oder einfach einmal etwas Motivation am Rande waren. Kurzum: Trotz der örtlichen Distanzen fühlte ich mich als Teil dieses Team sehr wohl!
27
Vorwort
Es gibt sicher eine Menge mehr Danksagungen, die ich an dieser Stelle endlich einmal richtig hervorbringen könnte, leider kann man aber nicht ein Fachbuch damit füllen. Viele Menschen wurden in meinem Vorwort zwischen den Zeilen erwähnt – ja, ich meine euch! Aber natürlich braucht jeder sein privates Umfeld, in das er sich einmal zurückziehen kann oder von dem er Rückhalt bekommt. Ich bin sehr froh und stolz, dies behaupten zu können. Danke an meine Familie und Freunde, dass ihr mich stets unterstützt und mir mit Rat und Tat zur Seite gestanden habt! Schade, dass dieser Dank leider nicht mehr jeden erreicht. Bleibt noch eine Person zu erwähnen – diejenige die mir Zeit und Raum gelassen und mich mit Nervennahrung versorgt hat. Danke, Katrin, dass du mich in dieser Zeit unterstützt hast!
Vorwort Bertram Wöhrmann Hätte mir vor einem Jahr jemand gesagt, ich würde einmal an einem Fachbuch mitarbeiten, dann hätte ich nur müde gelächelt. Manchmal kommt es dann doch schneller, als man denkt. Dennis Zimmer suchte im März noch Autoren, um das neue Buch über VMware vSphere zu schreiben. Als ich der Unterstützung meiner Familie sicher war, bin ich auf den Zug aufgesprungen. Das war schon eine erlebnisreiche Fahrt bis zur Fertigstellung des Buchs. Doch nun zu meinem Werdegang: Nach meinem Informatikstudium begann ich als Programmierer und schrieb in Chile eine Teleskopsteuerungssoftware. Nachdem das Projekt abgeschlossen war, wechselte ich in den Bereich WindowsAdministration und Netzwerke. Nach einem Arbeitgeberwechsel konzentrierte ich mich dann ganz auf die Administration von Windows-Servern. Vor fünf Jahren dann wurde bin ich auf das Thema VMware-Virtualisierung aufmerksam. Seitdem gilt diesem Bereich ein großer Teil meiner Aufmerksamkeit. Ich hoffe, dass wir Ihnen das Thema VMware vSphere näherbringen und Sie von dem Buch für Ihre Arbeit profitieren können.
Danksagung Zuallererst möchte ich Dennis Zimmer danken, für das Vertrauen und die Chance der Mitarbeit in diesem Projekt. Ein Dank gilt auch allen Co-Autoren für die gute Zusammenarbeit. Es war eine tolle Erfahrung, ein solches Buch mit Euch zu schreiben.
28
Vorwort
Allen Unterstützern möchte ich hier ausdrücklich danken. Viele haben mir mit Rat und Tat zur Seite gestanden und mich immer wieder motiviert. Den Kollegen, die uns unterstützt haben, die Qualität des Buches zu sichern, gilt ebenfalls mein ausdrücklicher Dank. Ich möchte mich auch bei meinen Eltern bedanken, die mir das Studium und somit die Chance ermöglicht haben, diesen beruflichen Weg einzuschlagen. Letztendlich kann ein solch großer Zeitaufwand nur gestemmt werden, wenn man die Unterstützung der Familie hat. Deshalb gilt der größte Dank meiner Frau Kornelia; sie hat mir oft den Rücken frei gehalten, damit ich mein Schreibpensum schaffen konnte. Auch bei meinen Söhnen Sven und Pit möchte ich mich bedanken. Sie mussten doch oft auf mich verzichten, damit das Buch druckreif werden konnte.
Vorwort Dennis Zimmer Ich arbeite seit mittlerweile über 13 Jahren in der IT-Branche. Mitte 2008 gründete ich gemeinsam mit meinem Geschäftspartner Diego Boscardin (CEO) das Unternehmen icomasoft AG, das sich auf Softwarelösungen im Bereich der Virtualisierung und der Rechenzentrumsautomatisierung spezialisiert hat. Außerdem wurde ich durch VMware zu einem von weltweit 300 vExperts ernannt. Diese Auszeichnung wurde 2009 das erste Mal verliehen. Doch zurück zu meiner Historie: Nach der Ausbildung zum Datenverarbeitungskaufmann war ich lange Jahre in der Systemadministration tätig. Meine Begeisterung für die virtuelle Infrastruktur lenkte meinen Weg in Richtung Beratung. Als Berater für Konsolidierungs- und Infrastrukturlösungen war ich bei einem der ersten deutschen VMware Consulting Partner (VAC), der Mightycare Solutions GmbH, tätig und beriet viele mittlere und große Unternehmen in Virtualisierungsfragen. Danach wollte ich einmal die Seite des Herstellers kennenlernen, und ich startete bei dem Storage-Hersteller Pillar Data Systems als Virtualisation Specialist und Systems Engineer. In dieser Funktion kamen neben der Kundenberatung auch die Aspekte Produktweiterentwicklung und Marketing hinzu. Ich hoffe sehr, Ihnen aufgrund meiner langjährigen Erfahrung auf diesem Gebiet hilfreiche Tipps und Leitfäden zu VMware vSphere geben zu können.
29
Vorwort
Danksagung An dieser Stelle möchte mich ganz herzlich bei allen Personen bedanken, die mich bei der Planung und Durchführung unterstützt haben. Dazu zählt selbstverständlich Jan Watermann, mein Lektor bei Galileo Computing. Natürlich gilt auch besonderer Dank dem Team der Autoren, die sensationell mitgearbeitet und dem Buch zu einem erstaunlichen Tiefgang verholfen haben: Günter Baumgart, Oliver Kügow, Carsten Schäfer, Bertram Wöhrmann und Sebastian Wischer! Vielen Dank für die tolle Zusammenarbeit! Des Weiteren möchte ich mich bei vielen Personen bedanken, die mich sowohl bei der Inhaltserstellung als auch bei der Überprüfung auf Richtigkeit und Lesbarkeit unterstützt haben. Die Reihenfolge sagt nichts über den Einsatz der einzelnen Personen aus: Markus Smieja, Axel Rosenberg, Thomas Gempe, Frank Pütz, Bernd Morbach, Bengt Lassen, Patrick Flückiger, Stefan Ebener, Sven Kempf, Thomas Weyell, Markus Gehm, Fred Lherault, Maneesh Jain und Peter Theile. Außerdem möchte ich mich nochmals gesondert bei allen Sponsoren für dieses Buch bedanken, die durch Teststellungen und Infrastruktur dieses Buch erst in dieser Tiefe möglich machten: 왘
team(ix) GmbH
왘
Thomas-Krenn.AG
왘
d-on-d.com
왘
Consultico GmbH
왘
Emulex Corporation
왘
NetApp Deutschland GmbH
Ein weiteres sehr großes Dankeschön geht an einen langjährigen, sehr guten Kollegen von mir, Urs Alder von Kybernetika, der mir immer tatkräftig als Reviewer und »Sparringspartner« zur Seite steht. Auch die Unterstützung durch ihn mit dem d-on-d (Datacenter on Demand) ist für mich Gold wert, da ich von überall und jederzeit mit einer UMTS-Karte auf eine komplette VMware-Infrastruktur mit zahlreichen Servern Zugriff hatte. Das größte Dankeschön gilt jedoch nach wie vor meiner Freundin Andrea, ohne die ich bisher keines meiner Bücher fertiggestellt hätte, und auch dieses Buch hat wieder Monate Freizeit gekostet. Nur durch ihre Unterstützung konnte ich die Zeit und die Motivation aufbringen, ein weiteres Buch zu schreiben.
30
Vorwort
Widmung Zum ersten Mal in meiner Autorenlaufbahn möchte ich ein Buch einer Person widmen. Leider ist dies ein trauriger Anlass für mich, da ich dieses Buch einem der mit Abstand wichtigsten Menschen in meinem Leben widme – meiner verstorbenen Mutter!
Weitere Unterstützung Vielleicht ergeben sich bei der Lektüre des Buches Fragen, oder Sie benötigen in einer anderen Richtung Unterstützung. Hierfür habe ich die E-Mail-Adresse
[email protected] eingerichtet, über die Sie mich kontaktieren können. Außerdem empfehle ich Ihnen, auf den Websites www.vmachine.de, www.icomasoft.com und http://www.galileocomputing.de/2179 nach Updates zum Buch Ausschau zu halten.
Vielen Dank an unsere Sponsoren
31
Virtualisierung ist nicht bloß ein Hype, es ist fester Bestandteil vieler IT-Landschaften geworden.
1
Einleitung Autor dieses Kapitels ist Carsten Schäfer, G-TAC IT-Beratung,
[email protected]
1.1
Server-Virtualisierung
Zunächst sollten wir die wichtigsten Fragen klären, nach dem Was, Warum und Wie der Virtualisierung.
1.1.1
Was ist Server-Virtualisierung?
Die Virtualisierung abstrahiert die physische Hardware vom Betriebssystem. Die klassische 1:1-Verbindung von Hardware und Betriebssystem, die man vor allem in der PC-Welt kennt, wird aufgehoben; dazwischen wird eine neue Schicht gelegt, die diese Abstraktion vornimmt, die Virtualisierungsschicht. In unserem Falle übernimmt das VMware-Produkt vSphere 4 mit seinem ESX Server 4.0 die Aufgabe des Virtualisierers.
Abbildung 1.1 Ein Virtualisierer hebt die klassische Kopplung von Betriebssystem und Hardware auf.
33
1
Einleitung
1.1.2
Was ist eine virtuelle Maschine?
Da Sie den Begriff »virtuelle Maschine« ab jetzt mit schöner Regelmäßigkeit immer wieder lesen werden, möchten wir ihn kurz beschreiben. Eine virtuelle Maschine, oder auch VM abgekürzt, ist ein Synonym für virtuelle Systeme auf Basis der hier vorgestellten Technologien. Diese virtuelle Maschine besteht in erster Linie aus der virtuellen Hardware, nämlich Grafikkarte, CPUs, Speicher (RAM), Netzwerkkarten und Festplatten an SCSI- oder IDE-Controllern. Die vier zuletzt genannten Grundbestandteile einer virtuellen Maschine werden auch Core Four genannt. Zusätzlich kann die virtuelle Hardware um CD-/DVD-Laufwerke oder USB-Sticks erweitert werden. Wie für ein System üblich, wird auch eine virtuelle Maschine mit einem virtuellen BIOS versehen. In einer virtuellen Maschine läuft ein vollständiges Betriebssystem, Gastbetriebssystem genannt, von verschiedenen Herstellern wie Microsoft (mit Windows XP, Vista, Windows Server 2003, Windows Server 2008) oder verschiedene LinuxDistributionen (wie Suse oder Red Hat, Solaris), Novell NetWare und teilweise auch Exoten wie OS/2. Das Gastbetriebssystem bedarf keinerlei Anpassungen, da es aus seiner Sicht auf einem vollständigen Server aufsetzt. Sogar die im Betriebssystem standardmäßig vorhandenen Treiber würden ausreichen, doch dies ist der erste Ansatzpunkt, um virtuelle Maschinen zu optimieren, indem auf ihnen speziell angepasste Treiber für die virtuelle Hardware installiert werden. Bei VMware befinden sich diese Treiber mitunter in den VMware Tools, die für die gängigen Betriebssysteme zur Verfügung stehen. Eine virtuelle Maschine wird als Dateien auf dem File-System des Virtualisierers abgebildet. Diese sind z. B. eine Konfigurationsdatei, die u. a. beschreibt, aus welchen virtuellen Bestandteilen diese virtuelle Maschine zusammengesetzt ist, oder auch die virtuelle Festplattendatei. Diese virtuelle Festplatte bildet die aus Sicht der virtuellen Maschine real existierende Festplatte ab und enthält alle Inhalte dieser Festplatte in einem spezifischen Format. Zusätzlich können weitere Dateien existieren. Die Bestandteile, also die Dateien, einer virtuellen Maschine unterscheiden zwischen den verschiedenen Virtualisierungslösungen der Hersteller.
1.1.3
Warum virtualisiert man?
Das Schlagwort in der IT ist Consolidation bzw. Konsolidierung. Dieser Begriff bezeichnet die Zusammenführung von vielen einzelnen Server-Systemen auf wenige physische Systeme. Diese wenigen physischen Systeme wiederum sind die Basis für darauf laufende virtuelle Maschinen. Genau genommen beschreibt die Konsolidierung die Zusammenführung der in den letzten Jahren rasant gewachsenen Anzahl von hardwarebasierten Servern.
34
Server-Virtualisierung
Die Virtualisierung bietet uns folgende Vorteile: 왘
Zusammenfassung von Servern Das in der Windows-Welt sehr beliebte »One Service/One Server«-Denken verschlingt Unmengen von Platz und Strom. Es wird für einfache WindowsServer, die einen Dienst bereitstellen, moderne Server-Hardware angeschafft, die mitunter für solche Aufgaben schlichtweg überdimensioniert ist. Mit virtualisierten Systemen partitionieren Sie leistungsstarke Hardware in kleinere Einheiten und betreiben in diesen Einheiten unterschiedliche Systeme für unterschiedlichste Anforderungen.
Abbildung 1.2 Viele physische Server werden auf einem phyischen Server zusammengefasst (konsolidiert).
Auf einem physischen System können verschiedene Betriebssysteme in voneinander getrennten Einheiten parallel existieren. Unterschiedliche Anforderungen verlangen nach unterschiedlicher (virtueller) Hardware. Auch eine nachträgliche Änderung einer Hardwareausstattung ist ohne langwierige Hardware-Beschaffungsprozesse mit Technikertermin und langer Downtime des Servers durch wenige Mausklicks durchführbar – bei
35
1.1
1
Einleitung
entsprechender Unterstützung durch das Betriebssystem können z. B. Speicher oder CPUs hinzugefügt oder auch entfernt werden. 왘
Server-Deployment Die Deployment-Prozesse werden stark vereinfacht und um einiges schneller durchführbar. Nicht nur, dass Sie neue virtuelle Server in wenigen Minuten bereitstellen können, das Betriebssystem wird standardisiert und in ebenso kurzer Zeit installiert und muss lediglich noch vor dem Start angepasst werden.
왘
Testumgebung Eine virtuelle Testumgebung ist die ideale Spielwiese von IT-Administratoren, die gerne viele Systeme bereithalten, sich aber eben entsprechend aufwendig um diese immer kümmern müssen. Nicht nur, dass Sie diese virtuelle Umgebung schnellstmöglich aufsetzen, abbauen und verändern können, durch Technologien wie Snapshots können Sie jeden beliebigen Stand Ihres Servers einfrieren, munter weitertesten und bei Bedarf wieder in kürzester Zeit zum Ursprungszustand zurückspringen.
왘
Backup und Disaster-Recovery Ihre Strategie für Backup und Disaster-Recovery fußt auf komplett anderen Umgebungsvariablen als die einer physischen Umgebung und bringt höhere Flexibilität und erheblich bessere Laufzeiten mit sich. Stellen Sie sich nur vor, wie Sie mit einem Snapshot in Ihrer Storage-Umgebung Dutzende von Servern sichern können.
왘
Vereinheitlichung von Hardware Durch die einheitliche Hardware der virtuellen Systeme haben Sie immer einen Ansprechpartner, wenn es um neue Hardwaretreiber geht. Das Wesentliche hierbei ist, dass es um einen Ansprechpartner geht und alle Ihre Systeme eben auf dieser Hardware basieren. Müssen Sie diese Systeme aktualisieren, so geschieht das über einfachste Wege ohne lästige BIOS-Updates von ServerSystemen oder ähnliche aufwendige Arbeit.
1.1.4
Gibt es auch Nachteile?
Wo Licht ist, ist auch Schatten. Gerne reden die namhaften Hersteller von Virtualisierungslösungen nicht über die Nachteile, da doch ihr Produkt alles kann. Über folgende Punkte sollten Sie genaue Überlegungen anstellen: 왘
36
Know-how Neben dem umfangreichen Wissen über die verschiedenen Betriebssysteme und die Anwendungen gesellt sich jetzt noch ein nicht minder komplexes Thema dazu: Die virtuelle Infrastruktur will geplant, aufgebaut, betrieben und
Server-Virtualisierung
aktualisiert werden – als wenn die IT-Administratoren nicht genügend Themen zu betreuen haben ... 왘
Single Point of Failure Bis vor kurzem war gegen diesen Kritikpunkt noch kein Kraut gewachsen. Aber seit vSphere 4 kann auch ein Ausfall eines physischen Servers, des Virtualisierungs-Hosts, nicht mehr den Lebenswillen der darauf laufenden virtuellen Maschinen auslöschen. VMware Fault Tolerance ermöglicht eine Spiegelung von virtuellen Maschinen, was wir Ihnen im Kapitel 4, »Cluster«, beschreiben.
왘
Server-Auslastung Ein klarer Grund für die Entscheidung gegen eine Virtualisierung wäre eine hohe Auslastung eines physischen Servers. Auch die Art der Auslastung spielt eine Rolle: Ein physischer Server, der seine vier oder acht CPUs dauerhaft über 50 % Auslastung bringt und zudem noch einen hohen dauerhaften Speicherbedarf von z. B. 8 GByte oder mehr hat, ist sicherlich kein optimaler Virtualisierungskandidat. Möglich wäre die Virtualisierung, aber ob sie sinnvoll ist, sei dahingestellt.
Auch I/O-lastige Anwendungen, wie beispielsweise Webserver mit vielen statischen Seiten, generieren sehr viel I/Os, die durch das Nadelöhr der emulierten Festplatten und Netzwerkkarten des Virtualisierers geschickt werden müssen. 왘
Server-Erweiterungen Server mit Erweiterungskarten, wie z. B. zum Anschluss von Steuerungssystemen oder Fax- und ISDN-Karten, können nicht virtualisiert werden. Gleiches gilt für am Server angeschlossene Dongles oder sonstige Geräte, die über den USB-Port oder den seriellen Port mit einer Software auf dem Server kommunizieren. Vielleicht findet sich eine neue Version der Software oder Hardware beim Hersteller, um die starre Verbindung zwischen dem physischen Server und der Anwendung zu lösen. Ebenso gibt es Adapter, um USB-Geräte über zusätzliche Hardware am Netzwerk anzuschließen.
왘
Support und Lizenzen Überprüfen Sie Ihre im Einsatz befindliche Software. Gibt es für alle Produkte Support vom jeweiligen Hersteller, wenn dessen Anwendungen auf virtueller Hardware laufen? Ein Beispiel für solche Fälle wäre Oracle, da dieses Unternehmen jeglichen Support für den Betrieb in einer Virtualisierungslösung, die nicht aus dem Hause SUN stammt, verweigert.
Oder ist die Lizenz einer Applikation mit z. B. der MAC-Adresse oder der CPUID des Servers verdrahtet? Ist der Support dieses Herstellers noch erreichbar oder bereits vom Markt verschwunden? Diese Lizenz wird nach der Umstel-
37
1.1
1
Einleitung
lung des Servers auf eine virtuelle Hardware nicht mehr gültig sein, da sich die komplette Hardware ändert. Selbst wenn die Lizenz nur mit der MAC-Adresse verdrahtet ist, werden Sie nicht diese MAC-Adresse mit Ihrem virtuellen Server ins Netzwerk einbringen, da VMware zwar das manuelle Abändern der MAC-Adresse aller virtuellen Netzwerkkarten zulässt, die Hersteller-Signatur der MAC-Adresse ist und bleibt aber die von VMware.
1.1.5
Welche Arten der Virtualisierung gibt es?
Es existieren mehrere Wege der Virtualisierung, hier eine Übersicht: 왘
Hypervisor-basierte Virtualisierung Ein Hypervisor, auch Virtual Machine Manager (VMM) genannt, ist die Virtualisierungsschicht, die die Aufgabe hat, mehrere virtuelle Server-Systeme zu erzeugen, um darin dem laufenden Betriebssystem eine komplette, aber virtuelle Hardware vorzugaukeln. Sie kümmert sich um die Zuordnung der Hardwareressourcen zu den virtuellen Servern. Die hypervisor-basierte Virtualisierung unterteilt sich wiederum in zwei Varianten: 왘
Hypervisor Typ 1 Der Hypervisor vom Typ 1 wird auch native oder bare-metal-Virtualisierung genannt, läuft direkt auf der Hardware des Trägersystems und hat als Einziger die Kontrolle über die Hardware, um den darauf laufenden virtuellen Systemen die notwendigen Ressourcen zuzuteilen und diese zu kontrollieren. Diese Form ist die schlankste und somit performantere Lösung der hypervisor-basierenden Virtualisierung. Die typischen Vertreter sind VMware Virtual Infrastructure 3.x, VMware vSphere, Citrix XenServer und Microsofts Hyper-V.
왘
Hypervisor Typ 2 Der Hypervisor vom Typ 2 wird auch hosted Virtualisierung genannt. Er setzt im Gegensatz zu Typ 1 auf einem Betriebssystem auf und ist aus Sicht des Träger-Betriebssystems lediglich eine Anwendung. Auch dieser Typ stellt den virtuellen Systemen Ressourcen zur Verfügung, und aus Sicht des Gastbetriebssystems im virtuellen System ist kein Unterschied zwischen Typ 1 oder Typ 2 erkennbar. Diese Form der Virtualisierung stellt im Vergleich zu Typ 1 weniger Ressourcen zur Verteilung an die virtuellen Systeme zur Verfügung, da auch das Träger-Betriebssystem einen gewissen Ressourcenanteil beansprucht. Diese Form war es jedoch, die VMware damals den Siegeszug mit VMware Workstation ermöglichte, da damit jedermann auf seinem PC viele weitere Ser-
38
Server-Virtualisierung
ver- oder PC-Systeme zum Testen oder Entwickeln installieren konnte. Lediglich die Hardwareaustattung des PCs war und ist der limitierende Faktor. VMware ist mit seinem Produkt VMware Workstation also ein Vertreter dieses Hypervisor-Typ-2-Virtualisierers. Ferner gesellt sich der VMware Server in diese Riege ein sowie auch Microsoft Virtual Server 2005 und Microsoft Virtual PC oder auch VirtualBox von Sun. 왘
Hardwarevirtualisierung Die Hardware selbst bietet die Virtualisierungsfunktionen, z. B. die IBMLPAR-Technik in Großrechnern.
왘
Betriebssystem-Virtualisierung Hier ist die Virtualisierungsschicht bereits im Betriebssystem eingebaut und kann so mehrere isoliert voneinander existierende Umgebungen erstellen. Aus Anwendungssicht werden komplette Betriebssysteme zur Verfügung gestellt. VM
...
App OS
Hypervisor Typ 1
VM
...
App OS
Hypervisor Typ 2 Betriebssystem
Hardware
Hardware
Abbildung 1.3 Ein Vergleich der Virtualisierungstypen: Bare-Metal- oder Typ-1-Hypervisor (links) und Hosted oder Typ-2-Hypervisor (rechts)
VM
Partition
App
App
OS
OS
Partition
Partition
Hardware
App
...
App
Virtualisierungs-App Betriebssystem Hardware
Abbildung 1.4 Fortsetzung des Vergleichs der Virtualisierungstypen: Hardware-Virtualisierung (links) und Betriebssystem (rechts)
1.1.6
Der Hypervisor genauer betrachtet
Der Hypervisor (Typ 1) ist das mittlerweile gängige Virtualisierungsmodell, und da auch vSphere von diesem Typ ist, werden wir ihn kurz vorstellen.
39
1.1
1
Einleitung
Der Hypervisor bringt ein eigenes schlankes Betriebssystem mit, das für den Einsatzzweck der Virtualisierungoptimiert wurde. In diesem Betriebssystem werden die Hardwaretreiber eingebunden. VMware geht hier recht restriktiv vor und bietet ein vordefiniertes Paket an Treibern an, die im Betriebssystem installiert werden können. Microsoft hingegen geht einen anderen Weg, den Hypervisor zu implementieren, und im Zuge dessen werden alle Treiber, die für Windows 2008 existieren, für den Einsatz in Microsofts Hypervisor, genannt Hyper-V, einsetzbar.
1.1.7
Die Entwicklungsgeschichte der Virtualisierung
Virtualisierung ist an sich nichts Neues, so ist im Unix- oder Großrechnerbereich dies schon seit Jahren Standard. In der PC-Welt sah es jedoch anders aus – wild wachsende PC- und Server-Umgebungen mit Verschwendung von Hardwareressourcen waren leider normal. In dieser Intel-Welt begann alles im Jahre 1999 mit einem einfachen Produkt, auf das jeder IT-Administrator und Softwareentwickler gewartet hatte: VMware Workstation wurde veröffentlicht. Ursprünglich waren virtualisierte Systeme eher für Test- und Entwicklungsumgebungen gedacht. Doch mit immer leistungsfähigerer Hardware und auch immer besser werdender Virtualisierungssoftware weitete sich das Feld auf Produktionsumgebungen aus. Die VMware Workstation gehörte damals zur ersten Generation der Virtualisierer und stellte lediglich die virtuelle Hardware bereit. Hinzu gesellten sich im Jahre 2001 die ersten Versionen von VMware GSX (später in VMware Server umbenannt), ebenfall ein Vertreter der Hypervisor-Typ-2-Virtualisierer, und VMware ESX Server (heute als vSphere bekannt) als Vertreter des Hypervisors vom Typ 1. Im Jahre 2003 läutete VMware die zweite Generation ein: Features zur zentralen Administration von Virtualisierungsumgebungen hielten Einzug, das VMware Virtual Center wurde geboren, um immer größer werdende Virtualisierungslandschaften zentral zu verwalten. In diesem Jahr kaufte Microsoft den Virtualisierungspionier Connectix auf, der bereits zwei Jahre vor VMware ein Hypervisor-Typ-2-basiertes Produkt für Apple-Produkte auf den Markt gebracht hatte und erst später für die Intel-Welt einen Virtualisierer lieferte. Kurz darauf versuchte Microsoft, in diesem immer größer werdenden Markt mit dem Virtual Server 2005 mitzuspielen. Als direkte Konkurrenz zu VMwares Workstation brachte Microsoft die kleinere Variante Virtual PC ins Rennen.
40
Die VMware-Produktfamilie
Die dritte Generation der Virtualisierungsprodukte hat in den letzten drei Jahren den Anspruch erhoben, die komplette Infrastruktur zu virtualisieren, die Verfügbarkeit der Systeme zu erhöhen und die Automatisierung von Provisioning oder Betriebsprozessen zu ermöglichen. VMware Virtual Infrastructure 3.x war hier der Vorreiter, und Microsoft versuchte im Jahre 2008, mit dem komplett neu entwickelten Produkt Hyper-V – für Microsoft erstmals auch ein Typ 1-Hypervisor – auch in diesen Bereich vorzustoßen. Im Jahre 2009 legte VMware mit vSphere die aktuelle und fortschrittlichste Lösung vor. Microsoft zog zwar im Oktober 2009 mit dem Hyper-V R2 nach, doch vom Funktionsumfang bewegt er sich auf dem Niveau von VMware VI 3.5.
1.2
Die VMware-Produktfamilie
Die Produktfamilie von VMware ist in den letzten Jahren stetig gewachsen. Da wir uns in diesem Buch auf vSphere beschränken möchte ich nur kurz die Hypervisor-Produkte von VMware kurz vorstellen. In Kapitel 17, »Zusatzsoftware von VMware«, finden Sie für vSphere-Umgebungen sinnvolle Erweiterungen aus dem Hause VMware. VMware Workstation VMwares erstes Produkt und Begründer des Siegeszugs von VMware ist VMware Workstation. Dieser Hypervisor vom Typ 2 wurde 1999 auf den Markt gebracht und setzt auf einem Träger-Betriebssystem auf. In der Regel findet sich dieses kostenpflichtige Produkt auf Desktop-PCs wieder; es ist für Windows und Linux verfügbar. Es ist die ideale Anwendung, um Software und Betriebssysteme zu testen. Auch Softwareentwickler setzen es gerne ein, um die Anwendungen auf unterschiedlichen Systemen oder auch nur auf einem Rechner ohne Entwicklungsumgebung zu testen. VMware Workstation ist seit Herbst 2009 in der Version 7 erhältlich. Mit VMware Workstation haben Sie einen Virtualisierer für 32- und 64-Bit-Gastbetriebssysteme von Microsoft inklusive Windows 2008 R2 und Windows 7 sowie für Linux, Solaris x86 oder auch NetWare. Neben der Core-Four-Hardware haben Sie auch Unterstützung für USB-2.0Geräte in der virtuellen Maschine. Ihre virtuellen Netzwerkkarten konfigurieren Sie so, dass diese entweder nur auf dem Host (z. B. Ihrem PC) verfügbar sind, als Netzwerkkarten zum physischen Netzwerkkabel durchgereicht werden (bridged) oder via NAT mit der Physik verbunden werden. Um kurzfristig Ressourcen auf Ihrem PC zu schaffen oder Ihre Arbeit für den Tag zu beenden, können Sie eine
41
1.2
1
Einleitung
virtuelle Maschine anhalten, um diese später wieder in wenigen Sekunden zu aktivieren. Auch die Snapshot-Technologie unterstützt Sie dabei, zu verschiedenen Zeitpunkten den aktuellen Stand Ihres Gastbetriebssystems abzuspeichern, um nach Tests oder im Fehlerfalle im Gast wieder zu einem bestimmten Punkt zurückzuspringen. VMware Workstation erledigt das Erstellen der Snapshots auf Wunsch auch automatisch für Sie. Für Softwareentwickler gibt es eine Integration in Microsofts Visual Studio, in die Eclipse-Entwicklungsumgebung und in die SpringSource Tools. Zum Datenaustausch können Sie über die Shared Folders Laufwerke vom Gast zum Host nutzen oder auch via Drag & Drop Dateien kopieren. Ebenso können Sie durch den integrierten Converter Ihren PC oder ein Betriebssystem-Image der Hersteller Symantec oder Acronis oder eine andere virtuelle Maschine von VMware oder Microsoft in Ihre VMware Workstation übertragen. VMware Player Der kostenfreie VMware Player ist, wie der Name schon sagt, eine reine Laufzeitumgebung für virtuelle Maschinen. Sie können damit virtuelle Maschinen erstellen und betreiben und das Gastbetriebssystem nutzen. Features wie Snapshots, Clones, Integration in Entwicklungsumgebungen u. a. sind nur in VMware Workstation enthalten. VMware Fusion VMware Fusion ist der kostenpflichtige Virtualisierer für Apples Mac-Rechner und in der Version 3 seit Oktober 2009 auf dem Markt. Im Großen und Ganzen entsprechen die Features der Mac-Lösung dem Produkt VMware Workstation. VMware Server VMware Server – ehemals VMware GSX Server – liegt in der Version 2.0 für Windows und Linux vor und ist kostenfrei. Dieses Produkt ist im Vergleich zu VMware Workstation oder VMware Player mehr für den Betrieb in einem Rechenzentrum ausgelegt und wartet daher mit Funktionen wie einer Remote Console für die virtuellen Maschinen auf, mit der Unterstützung von VSS (Volume Shadow Copy Service), VMI (Virtual Machine Interface) zur transparenten Paravirtualisierung sowie VMCI (Virtual Machine Communication Interface) zur optimierten Kommunikation zwischen einer virtuellen Maschine und dem Host-Betriebssystem oder zwischen den virtuellen Maschinen untereinander. Zur Automatisierung von virtuellen Maschinen bringt der VMware Server die VIX
42
Einführung in VMware vSphere
API mit. Zusätzlich können Sie Benutzer und Benutzergruppen einrichten, um den Zugriff auf den VMware Server bzw. seine Bestandteile und die virtuellen Maschinen einzuschränken. Auch die VMware Snapshot-Technologie wird vom VMware Server unterstützt. Im Gegensatz zu VMware vSphere mit dem ESX-Server können Sie mehrere VMware-Server nicht mit einem zentralen Tool (vCenter Server) verwalten. Sie administrieren jeden VMware-Server einzeln über eine Weboberfläche. Zusätzlich können Sie in der virtuellen Maschine am Gastbetriebssystem über eine eigene Anwendung, die VMware Remote Console, arbeiten. Benötigen Sie zum Betrieb Ihrer virtuellen Umgebung weitere Funktionen außer den hier genannten, so müssen Sie den Schritt wagen und zum kostenpflichtigen Produkt VMware vSphere wechseln. Optional schließen Anwender einen Supportvertrag bei VMware ab und stabilisieren den Betrieb von VMware Server in Rechenzentren. VMware vSphere VMware vSphere – das Flaggschiff in der Produktpalette von VMware und zur Zeit am Markt die unangefochtene Nummer eins der Hypervisor-Typ-1-Virtualisierer – besteht aus einer Vielzahl von Komponenten und lässt sich für verschiedene Einsatzgebiete mit weiteren VMware-Produkten erweitern oder kombinieren, um dem Einsatz in Enterprise-Umgebungen gerecht zu werden.
1.3
Einführung in VMware vSphere
VMware vSphere setzt sich aus mehreren Features und Produkten zusammen, die je nach Edition im Paket enthalten sind. VMware unterteilt die Features und Produkte in verschiedene Bereiche, und daher möchten wir im Wesentlichen diese Gruppierung zur besseren Übersichtlichkeit hier ebenso verwenden. Zu allen hier genannten Features finden Sie in nachfolgenden Kapiteln ausführliche Informationen.
1.3.1
VMware Infrastructure Services
vCompute 왘
VMware ESX und ESXi Der VMware ESX Server ist der zentrale Bestandteil der vSphere-Landschaft – nämlich der Hypervisor-Typ-1-basierte (bare-metal-)Virtualisierer. Der ESX Server, genauer der VMkernel, verwaltet die Hardwareressourcen und küm-
43
1.3
1
Einleitung
mert sich um die Verteilung dieser an die virtuellen Maschinen. Ausgereifte Techniken zur Speicherzuweisung mit der Möglichkeit, mehr Speicher an virtuelle Maschinen zu vergeben als physisch vorhanden (Memory-Overcommitment), und zur Zuteilung von CPU-Ressourcen (CPU Scheduler) bieten den virtuellen Maschinen höchstmögliche Performance.
Abbildung 1.5
VMware vSphere 4 besteht aus mehreren Komponenten.
Zur Verwaltung bringt der ESX Server die Service Console mit, ein modifiziertes Red-Hat-Linux, das Sie unter anderem mit weiteren Agenten für z. B. SNMP oder Hardwaremanagement bestücken können. Den ESX Server gibt es in zwei Varianten: den VMware ESX 4.0 mit einer eingebauten Service Console und den frei verfügbaren VMware ESXi 4.0, der ohne diese Service Console zur Verwaltung daherkommt. Ein Vorteil der letztgenannten Variante ist, dass die ESXi-Version in die Firmware der Hardware eingebaut werden und somit ohne Speichermedien gebootet werden kann.
44
Einführung in VMware vSphere
왘
VMware vSMP (Virtual Symmetric Multi Processing) Dieses Feature erlaubt der virtuellen Maschine die Zuweisung von mehr als einer CPU.
왘
VMware DRS (Distributed Resource Scheduler) DRS kann nur in Verbindung mit dem vCenter Server genutzt werden und bietet die Möglichkeit, die virtuellen Maschinen nach verschiedenen Kriterien auf den in einem DRS-Cluster zusammengefassten ESX-Servern zu verteilen. Dies kann vollautomatisiert, halbautomatisiert oder rein administrator-induziert geschehen. VMware erreicht dadurch eine dynamische Lastverteilung auf den ESX-Servern.
왘
VMware DPM (Distributed Power Management) VMware DPM ist seit vSphere 4 ein Bestandteil von VMware DRS und trägt der Green-IT Rechnung da je nach Auslastung der ESX-Server im Cluster-Verbund die virtuellen Maschinen im laufenden Betrieb unterbrechungsfrei so verschoben werden, dass dadurch einzelne ESX-Server komplett lastfrei werden, um diese dann in den Stromsparmodus zu schicken. Fordert die virtuelle Infrastruktur wieder mehr Ressourcen, so können diese ESX-Hosts wieder aus dem Schlaf erweckt und die virtuellen Maschinen vollautomatisiert wieder auf alle ESX-Server im Cluster verteilt werden.
vStorage 왘
VMware Storage VMFS (Virtual Machine File System) Das von VMware entwickelte Festplattenformat ist speziell für den Betrieb in ESX-Umgebungen ausgelegt und bietet bei einer Verzeichnisebene maximale Performance für sehr große Dateien zur Ablage der VM-Dateien.
왘
VMware Storage Thin Provisioning Durch Thin Provisioning können Sie virtuelle Maschinen erstellen, ohne dass diese von Anfang an den konfigurierten Speicherplatz für die virtuellen Festplatten in Anspruch nehmen.
vNetwork 왘
VMware vNetwork Distributed Switch (DVS) Der mit vSphere 4 eingeführte DVS verteilt die Netzwerkkonfiguration eines ESX-Hosts auf mehrere ESX-Hosts im VMware-Datacenter. Dadurch reduziert sich die Verwaltung der Netzwerkkonfiguration erheblich, da diese nur noch einmal erfolgen muss und nicht für jeden ESX-Host einzeln.
Damit weitere Features wie VMotion funktionieren, muss auf jedem ESX-Host eine identische Netzwerkkonfiguration vorliegen, so dass sich die virtuellen Maschinen mit den gleichnamigen virtuellen Switches und Port-Groups ver-
45
1.3
1
Einleitung
binden können, um über die gleichen physischen Netzwerke mit der Außenwelt zu kommunizieren.
1.3.2
VMware Application Services
Der Begriff »Application Services« könnte etwas verwirrend sein, doch hier sind aus Sicht vom Hypervisor die virtuellen Maschinen gemeint. Verfügbarkeit – Geplante Ausfallzeit 왘
VMware VMotion und Storage VMotion Die VMware-VMotion-Technologie ermöglicht das Verschieben von aktiven virtuellen Maschinen von einem ESX-Host auf einen anderen. Die Voraussetzung hierfür ist die Ablage der Dateien einer virtuellen Maschine auf einem Shared Storage (SAN, NAS, NFS), auf den beide ESX-Hosts Zugriff haben. Somit können Sie ESX-Server im laufenden Betrieb aktualisieren und neu starten, indem Sie vorher alle aktiven virtuellen Maschinen auf andere ESX-Hosts verschieben.
Durch Storage VMotion können Sie aktive virtuelle Maschinen ohne Ausfall auch auf einen anderen Datastore, d. h. eine andere Speichereinheit in der vSphere-Umgebung, verschieben. Verfügbarkeit – Ungeplante Ausfallzeit 왘
VMware HA (High Availability) Bei einem Ausfall eines ESX-Servers kann VMware HA die auf diesem ESX-Server aktiv gewesenen virtuellen Maschinen auf anderen ESX-Servern in einem VMware-HA-Cluster-Verbund automatisch neu starten. Die Applikationen innerhalb der virtuellen Maschinen werden ebenso neu gestartet, was Auswirkungen auf die Anwender haben kann.
왘
VMware FT (Fault Tolerance) Hat der Ausfall eines ESX-Servers auch mit VMware HA durch den ungeplanten Ausfall von virtuellen Maschinen die Anwender samt ihren Applikationen verärgert, so können Sie dem mit dem in vSphere neu eingeführten Feature VMware FT Paroli bieten. Hierbei werden virtuelle Maschinen auf ESX-Servern in einem HA-Cluster per Mausklick mit VMware FT abgesichert, und der ESX-Server repliziert ständig die komplette virtuelle Maschine inklusive des Speicherinhalts auf einen anderen ESX-Server. Fällt die primäre virtuelle Maschine aus, so wird die Replik als aktiv markiert, und das Gastbetriebssystem steht ununterbrochen zur Verfügung.
왘
VMware Consolidated Backup (VCB) Durch Consolidated Backup können Sie ohne den Einsatz von Backup-Agen-
46
Einführung in VMware vSphere
ten in virtuellen Maschinen diese sichern und mit Hilfe von Backup-Lösungen von Drittherstellern die Dateien auf den virtuellen Festplatten der virtuellen Maschienen sichern. Dabei wird das Backup-Verfahren auf einen dedizierten Server ausgelagert (Proxy), der Zugriff auf den Shared Storage hat, um mit Hilfe der Snapshot-Technologie Abbilder der virtuellen Festplatten zu erzeugen und diese auf dem VCB-Proxy-Server zu mounten. 왘
VMware Data Recovery VMware Data Recovery bietet Ihnen einen zentralen Ansatz zum Backup oder Restore Ihrer virtuellen Maschinen über den VMware vCenter Server. Dadurch ist der Backup-Lösung auch bekannt, wohin welche virtuellen Maschinen durch vMotion verschoben wurden.
Sicherheit 왘
VMware vShield Zones Die VMware vShield Zones integrieren sich in die vSphere-Netzwerke, um zusätzliche Sicherheit in Form von Firewall-Funktionalität in die virtuelle Infrastruktur zu bringen. Dadurch erhalten die vSphere-Administratoren Einblick und Verwaltungsmöglichkeiten für den Netzwerkverkehr der virtuellen Switches in der vSphere-Umgebung.
왘
VMware VMsafe VMware gibt Drittherstellern eine API in Form von VMware VMsafe an die Hand, um Sicherheitsanwendungen für vSphere-Umgebungen in eigenen virtuellen Maschinen zu entwickeln.
Skalierbarkeit 왘
VMware DRS (Distributed Resource Scheduler)
왘
HotAdd von CPU, Memory sowie HotPlug von Festplatten und Netzwerkkarten
왘
HotExtend zur Vergrößerung von virtuellen Festplatten
1.3.3 왘
VMware vCenter Server
VMware vCenter Server Der vCenter Server ist das Werkzeug, um die virtuelle Infrastruktur von zentraler Stelle aus zu verwalten. Mit diesem Werkzeug arbeiten Sie an den virtuellen Maschinen, verwalten die ESX-Server, überprüfen diese mit Host-Profiles, erstellen Rechtestrukturen, um die Verwaltung der Umgebung an weitere Administratoren zu vergeben, starten VMotion-Vorgänge, konfigurieren HA, FT und DRS und vieles mehr.
47
1.3
1
Einleitung
Den vCenter Server können Sie in drei Editionen beziehen: 왘
vCenter Server Essentials ist Bestandteil von vSphere Essentials und für kleine Umgebungen gedacht.
왘
vCenter Server Standard hat keine Beschränkungen und bietet alle Features.
왘
vCenter Server Foundation hat ebenso wie die Standard-Edition den vollen Funktionsumfang, allerdings auf die Verwaltung von maximal drei ESXServern beschränkt.
왘
VMware vCenter Server Heartbeat Die Erweiterung zum vCenter Server, die auch diesen Teil der virtuellen Infrastruktur hochverfügbar gestaltet, nennt sich vCenter Server Heartbeat und repliziert einen aktiven vCenter-Server, um im Fehlerfalle auf die Replik umzuschalten.
왘
VMware vCenter Update Manager Der VMware vCenter Update Manager ist VMwares Lösung, um die ESX-Server einer vSphere-Umgebung automatisiert mit Patches zu versehen. Dabei überprüft der Update Manager, ob neue Patches verfügbar sind, lädt diese von der VMware-Internetseite und legt diese in einem konfigurierten Verzeichnis ab. Durch Scan-Vorgänge verschafft sich der Update Manager einen Überblick über den Softwarestand aller ESX-Server und vergleicht diesen dann mit den verfügbaren Patches. Per Mausklick können Sie die ESX-Server mit einem von Ihnen definierten Patch-Stand versehen, und der Update Manager instruiert VMware DRS, alle aktiven virtuellen Maschinen eines ESX-Servers auf andere ESX-Server zu verschieben, bevor die Patches auf dem ESX-Server installiert werden.
왘
VMware Converter Der VMware Converter ist in den vCenter Server integriert und bietet Ihnen eine automatisierte Konvertierung von physischen Servern in virtuelle Systeme. Zusätzlich kann der Converter virtuelle Maschinen von anderen VMware-Produkten oder anderen Virtualisierern wie Microsoft oder auch von Image-Sicherungen von Symantec Backup Exec oder Norton Ghost in Ihre vSphere-Umgebungen importieren.
왘
Host-Profiles Mit Hilfe von Host-Profiles standardisieren Sie Ihre ESX-Server, indem Sie bei deren Konfiguration und Verwaltung eine Vorlage mit Ihren Systemen vergleichen und gegebenenfalls die ESX-Server analog zur Vorlage konfigurieren lassen. Diese Vorlage, das Profil, erstellen Sie von einer Standard-ESX-Konfiguration.
48
Einführung in VMware vSphere
왘
VMware Guided Consolidation Die Guided Consolidation ist in den vCenter Server integriert und unterstützt Sie bei der Konsolidierung Ihrer physischen Server: Sie erkennt diese automatisch, protokolliert deren Auslastungen und überführt sie durch Einsatz des VMware Converters in virtuelle Maschinen.
왘
VMware vCenter Orchestrator Der VMware vCenter Orchestrator muss als weiteres Produkt von VMware gekauft werden und unterstützt die Automatisierung von Workflows, d. h. nahezu alle Vorgänge rund um virtuelle Maschinen.
왘
VMware vCenter Server Linked Mode Der Linked Mode ist ein Zusatzprodukt und unterstützt die Skalierbarkeit Ihrer vSphere-Umgebung durch die Verbindung mehrerer vCenter-Server. Dabei werden die Benutzerrollen und Rechte sowie die Lizenzen zwischen den verbundenen vCenter-Servern repliziert, damit Sie in allen vCenter-Servern arbeiten können.
1.3.4
Clients
왘
VMware vSphere Client Der vSphere Client ist eine Windows-Anwendung, die Ihnen den Zugang entweder zum vCenter-Server oder zu einem ESX-Server bietet. Es ist ihr tägliches Werkzeug zur Verwaltung der virtuellen Infrastruktur.
왘
VMware vSphere WebAccess Sie können die virtuellen Maschinen auch ohne einen vSphere-Client verwalten. Dazu bieten der ESX-Server sowie der vCenter-Server über einen Webbrowser Zugang zu grundlegenden Funktionen.
1.3.5
VMware Automation Tools und SDKs
왘
VMware Studio VMware Studio ist als Virtual Appliance erhältlich und dient zum Erstellen, Konfigurieren und Verteilen von vApps und Virtual Appliances.
왘
VMware SDK for Perl Das SDK für Perl bietet ein clientseitiges Scripting-Interface für die vSphere Web Services API.
왘
VMware vSphere Web Services SDK Dieses SDK bietet Ihnen über Web Services eine API, um mit Programmiersprachen wie C# oder Java Anwendungen zu schreiben, die Ihre vSphereUmgebung um Funktionen erweitern und so z. B. auch eigene Plug-ins für den vSphere-Client zu erstellen.
49
1.3
1
Einleitung
왘
VMware vSphere Guest SDK Die vSphere Guest SDK stellt für den Einsatz im Gastbetriebssystem der virtuellen Maschine zur Verfügung eine Read-only-API, mit der Sie z. B. Performance-Werte von CPU oder Speicher lesen können.
왘
VMware vSphere PowerCLI Das PowerCLI ist eine Sammlung von Commandlets für Microsofts PowerShell. Mit Hilfe dieser Erweiterungen können Sie über PowerShell-Skripte eine komplette vSphere-Umgebung in all ihren Aspekten automatisieren.
왘
VMware vSphere CLI Das vSphere CLI ist eine Sammlung von Kommandozeilentools zur Verwaltung von ESX-Servern. Speziell für die Administration von ESXi-Servern sind diese Tools sinnvoll, da der ESXi-Server keine Service Console zum Management des Hosts mitbringt.
왘
VMware vSphere Management Assistant Der vSphere Management Assistant ist eine virtuelle Appliance auf Basis von Linux, die mit dem vSphere CLI, dem vSphere SDK for Perl und einigen weiteren Modulen für Authentication und Logging versehen ist. Mit Hilfe dieser VM können Administratoren ihre vSphere-Umgebung mit Skripten verwalten.
1.3.6
Die verfügbaren VMware-Editionen
VMware bietet vSphere in verschiedenen Editionen an die sich in den enthaltenen Features unterscheiden, in der maximal unterstützten ESX-Hardware, d. h. maximale Cores pro CPU und maximal adressierbarer Speicher im ESX-Host, und von den maximal den virtuellen Maschinen zur Verfügung stehenden virtuellen CPUs. Essential Edition 왘
vCenter Server for Essentials
왘
maximale Hardwareausstattung pro ESX-Server: 왘
6 Cores pro CPU
왘
256 GByte Speicher pro ESX-Server adressierbar
왘
maximal 4 virtuelle CPUs pro virtueller Maschine
왘
Features:
50
왘
Thin Provisioning
왘
Update Manager
왘
VMsafe
왘
vStorage-APIs for Data Protection
Einführung in VMware vSphere
Essential Plus Edition 왘
vCenter Server for Essentials
왘
maximale Hardwareausstattung pro ESX-Server: 왘
6 Cores pro CPU
왘
256 GByte Speicher pro ESX-Server adressierbar
왘
maximal 4 virtuelle CPUs pro virtueller Maschine
왘
Features: 왘
Thin Provisioning
왘
Update Manager
왘
VMsafe
왘
vStorage-APIs for Data Protection
왘
HA (High Availability)
왘
Data Recovery
Standard Edition 왘
vCenter Server Standard
왘
maximale Hardwareausstattung pro ESX-Server: 왘
6 Cores pro CPU
왘
256 GByte Speicher pro ESX-Server adressierbar
왘
maximal 4 virtuelle CPUs pro virtueller Maschine
왘
Features: 왘
Thin Provisioning
왘
Update Manager
왘
VMsafe
왘
vStorage-APIs for Data Protection
왘
HA (High Availability)
Advanced Edition 왘
vCenter Server Standard
왘
maximale Hardwareausstattung pro ESX-Server:
왘
왘
12 Cores pro CPU
왘
256 GByte Speicher pro ESX-Server adressierbar
maximal 4 virtuelle CPUs pro virtueller Maschine
51
1.3
1
Einleitung
왘
Features: 왘
Thin Provisioning
왘
Update Manager
왘
VMsafe
왘
vStorage-APIs for Data Protection
왘
HA (High Availability)
왘
Data Recovery
왘
HotAdd
왘
FT (Fault-Tolerance)
왘
vShield Zones
왘
VMotion
Enterprise Edition 왘
vCenter Server Standard
왘
maximale Hardwareausstattung pro ESX-Server: 왘
6 Cores pro CPU
왘
256 GByte Speicher pro ESX-Server adressierbar
왘
maximal 4 virtuelle CPUs pro virtueller Maschine
왘
Features:
52
왘
Thin Provisioning
왘
Update Manager
왘
VMsafe
왘
vStorage-APIs for Data Protection
왘
HA (High Availability)
왘
Data Recovery
왘
HotAdd
왘
FT (Fault-Tolerance)
왘
vShield Zones
왘
VMotion
왘
Storage VMotion
왘
DRS & DPM (Distributed Resource Scheduler & Distributed Power Management)
Einführung in VMware vSphere
Enterprise Plus Edition 왘
vCenter Server Standard
왘
maximale Hardwareausstattung pro ESX-Server: 왘
12 Cores pro CPU
왘
1 TByte Speicher pro ESX-Server adressierbar (keine Softwarebeschränkung)
왘
maximal 8 virtuelle CPUs pro virtueller Maschine
왘
Features: 왘
Thin Provisioning
왘
Update Manager
왘
VMsafe
왘
vStorage-APIs for Data Protection
왘
HA (High Availability)
왘
Data Recovery
왘
HotAdd
왘
FT (Fault-Tolerance)
왘
vShield Zones
왘
VMotion
왘
Storage VMotion
왘
DRS & DPM (Distributed Resource Scheduler & Distributed Power Management)
왘
vNetwork Distributed Switch
왘
Host-Profiles
왘
Third-Party Multipathing
53
1.3
Das folgende Kapitel beschäftigt sich mit dem strukturellen Aufbau einer virtuellen Infrastruktur. Wir gehen den Fragen nach, welche Elemente dazugehören, wie sie ineinandergreifen und wie sie aufgebaut sind.
2
vSphere-Architektur Autor dieses Kapitels ist Bertram Wöhrmann, Ligarion,
[email protected]
Mit der Einführung der VMware Virtual Infrastructure in der Version 3.x hat VMware einen Strategiewechsel vollzogen. Zusätzlich zu der eigentlichen Virtualisierungsplattform, dem ESX Server, und dem dazugehörigen Management hat VMware begonnen, zusätzlich Produkte um die Virtualisierung zu entwickeln. Es fing an mit der Service-Console-losen Version ESXi und dem Update Manager, VMware HA, VMware DRS und der Plug-in-Schnittstelle. Alles integriert sich nahtlos in das zentrale Management. Mit vSphere 4.0 ist dieser Ansatz konsequent weiterverfolgt worden. Auch der Lizenz-Server ist, nach einer kurzen externen Stippvisite, wieder integraler Bestandteil des vCenter-Servers. Viele Themen reißen wir in diesem Kapitel nur kurz an. Wir sind der Meinung, dass es sinnvoller ist, die ausführlichen Erklärungen direkt in dem entsprechenden Abschnitt zu geben, in dem wir auch die passende Komponente beschreiben.
2.1
Bestandteile der virtuellen Infrastruktur
Die vSphere-Infrastruktur bietet alle Komponenten zum Virtualisieren von Betriebssystemen. Sie umfasst die Verwaltung sowie das Management der Virtualisierungsserver (vSphere-Server). Diese Grundfunktionen hat VMware noch weiter optimiert, um eine Ausfallsicherheit der Virtualisierungsserver zu erreichen (HA) und eine bestmögliche Lastverteilung zwischen den Virtualisierungsservern (DRS) zu ermöglichen. Des Weiteren werden die virtualisierten Systeme optimal mit den Server-Ressourcen (CPU, RAM etc.) versorgt. Damit Sie einen grundlegenden Überblick über die Grundbestandteile der Infrastruktur erhalten, erläutern wir diese nachfolgend.
55
2
vSphere-Architektur
2.2
vSphere-Host
Der physische Server, der seine Ressourcen wie CPU, Hauptspeicher (RAM), Netzwerkkarten und Festplattenspeicher über eine Virtualisierungsschicht (Hypervisor) den virtuellen Maschinen zur Verfügung stellt, ist der vSphere-Host. Viele werden den Vorgängernamen des vSphere-Hosts noch im Kopf haben, nämlich die Bezeichnung ESX-Host (Abbildung 2.1).
Abbildung 2.1
2.2.1
vSphere-Host
Hardware
Als Prozessorbasis für den Einsatz von VMware vSphere kommen nur 64-Bitx86-Prozessoren zum Einsatz. Auf anderen CPUs ist das System nicht lauffähig, da sowohl VMkernel als auch Service Console einen 64-Bit-Kernel besitzen. Für die Installation benötigen Sie mindestens eine CPU und Minimum 2 GB Arbeitsspeicher. Des Weiteren ist ein unterstützter Storage-Kontroller nötig. Möglich sind IDE (lokal), SCSI, SAS, SATA und Fibre-Channel. Abschließend wird noch mindestens eine Netzwerkkarte benötigt, damit Sie auf das System zugreifen können. Im Normalfall werden aber wohl mehr Netzwerkports zum Einsatz kommen. Intel® VT-x/AMD-V™ Alle Prozessoren, für die VMware Support anbietet, müssen eine Erweiterung zur Unterstützung von Virtualisierungstechnologien aufweisen. Durch diese Technologien wird im Wesentlichen der Virtual Machine Monitor (VMM) in seiner Arbeit unterstützt,ermöglicht dadurch wird der Overhead reduziert. Auch der Prozess der Migration einer aktiven virtuellen Maschine zwischen verschiedenen Prozessorgenerationen wird erleichtert.
56
vSphere-Host
Die unterstützten CPUs von beiden Herstellern bringen eine solche Technologie mit. Die folgenden Prozessoren erhalten Support von VMware: 왘
AMD Opteron (mindestens Barcelona für Fault-Tolerance)
왘
Intel Xeon 3000/3200, 3100/3300, 5100/5300, 5200/5400, 7100/7300, 7200/7400
왘
Intel Nehalem
2.2.2
HCL
Wie andere Betriebssystemhersteller bzw. Hersteller von Hypervisoren pflegt die Firma VMware eine Hardware Compatibility List (HCL). Vergewissern Sie sich, dass Ihre Komponenten, die Sie einsetzen wollen, in dieser Liste aufgeführt sind. Sie müssen zwar keine Bedenken haben, dass ein nicht gelistetes System nicht funktionieren kann, aber Sie haben nur Support für Ihre Virtualisierungslandschaft, wenn Sie sich aus der Liste der unterstützten Hardware bedienen. Die HCL finden Sie unter: http://www.vmware.com/resources/compatibility/search.php
2.2.3
Maximale Ausstattung eines ESX-Hosts
Auch wenn Sie sich an die HCL halten, so müssen Sie doch wissen, welche Ausstattung des Hosts mengenmäßig noch unterstützt wird. Diesen Punkt möchten wir in den folgenden Tabellen näher aufschlüsseln. CPUs pro Host logische Prozessoren virtuelle CPUs (vCPUs) maximale Anzahl von virtuellen CPUs, pro Core
Anzahl Bemerkungen 64 512 25
Die Anzahl berechnet sich aus: Sockel × Cores × Threads – Die Anzahl ist abhängig von der Last, die die VMs verursachen. (Gilt für vSphere 4.0 Update 1, bei vSphere 4.0 sind es 20 vCPUs.)
maximale Anzahl von VMs pro Host Tabelle 2.1
320
Die Anzahl ist abhängig von der Last, die die VMs verursachen.
Maximale CPU-Werte
57
2.2
2
vSphere-Architektur
Memory pro Host
Menge
Arbeitsspeicher
1 TB
Arbeitsspeicher Service Console Tabelle 2.2
800 MB
Maximale Memory-Werte
Anhand der Menge der Karten geben wir in den Tabellen für die Netzwerkkarten nur den Treiber und den Chiphersteller an. Netzwerkkarte
Chiphersteller
Speed
Anzahl Bemerkungen
Physische Karten
e1000
Intel
1 GBit
32
Gilt sowohl für PCI-X als auch für PCIe.
igb bnx2
Intel Broadcom
1 GBit
16
–
tg3
Broadcom
1 GBit
32
–
forcedeth
Nvidia
1 GBit
2
–
s2io nx_nic
Neterion NetXen
10 GBit
4
–
ixgbe bnx2x
Intel Broadcom
10 GBit
4
–
Tabelle 2.3
Maximale Anzahl physischer Netzwerkkarten
PCI VMDirectPath
Anzahl
PCI VMDirectPath Devices vNetzwerk-Standard-Switch
8 Anzahl
virtuelle Switch-Ports gesamt
4.096
virtuelle Switch-Ports pro vSwitch
4.088
Portgruppen pro vSwitch
512
vSwitches
248
vNetzwerk Distributed Switch virtuelle Switch-Ports gesamt Hosts pro Switch Tabelle 2.4
58
Maximale Anzahl virtueller Karten/Ports
Anzahl 4.096 64
vSphere-Host
Für den Storage gibt es ebenfalls Einschränkungen. Die Tabelle 2.5 trennt die verschiedenen Anbindungsmöglichkeiten voneinander und beschreibt ebenfalls das File-System VMFS. VMFS allgemein RDM-Größe Volume-Größe VMs pro Volume Extents pro Volume VMFS-3
Maximalwert 2 TB 64 TB 256 32 Maximalwert
Volumes per Hosts Files pro Volume
256 ~30.270
File-Größe
2 TB – 512 MB
Blockgröße
8 MB
Fibre-Channel LUNs pro Host Anzahl Pfade pro LUN maximale Anzahl pro Host HBAs pro Host maximale Anzahl von HBA-Ports NFS
Maximalwert 256 32 1.024 8 16 Maximalwert
Standardanzahl von NFS-Datastores maximale Anzahl von NFS-Datastores Hardware-iSCSI-Initiators LUNs pro Host Initiator-Ports pro Host
8 64 Maximalwert 256 4
Pfade pro Host
1.024
Pfade pro LUN
8
dynamische Targets pro Port
64
statische Targets pro Port
61
Tabelle 2.5
Maximalwerte im Storage-Umfeld
59
2.2
2
vSphere-Architektur
Software-iSCSI-Initiators LUNs pro Host Initiator-Ports pro Host
Maximalwert 256 8
Ziele pro Host
256
Pfade pro LUN
8
Pfade pro Host
1.024
Tabelle 2.5
2.2.4
Maximalwerte im Storage-Umfeld (Forts.)
Version ESX vs. ESXi
VMware stellt zwei Varianten seiner ESX-Server-Software zur Verfügung, den ESX Server 4 und den ESX Server 4i (als embedded oder als installable). Viele reduzieren den Unterschied zwischen den beiden Versionen auf die Service Console, dabei gibt es aber weit mehr Unterschiede. Das beginnt schon bei der Installation der Systeme. Beide Versionen lassen sich auf einer Festplatte installieren. Einen Boot von einer SAN-LUN unterstützt die Embedded-Version nicht. Im Unterschied dazu können Sie die ESXi-Version auch direkt von einem USB-Stick oder einer SD-Karte booten. Eine skriptbasierte Installation z. B. über Kickstart-Mechanismen ist für die ESXi-Variante nicht möglich. Eine ganze Reihe von Unterschieden ergibt sich durch die Möglichkeit der Installation von Tools in der Service Console. So fehlt dem ESXi die Anbindung an ein Active Directory. Eine zentrale Pflege von Benutzern an der Konsole ist somit nicht möglich. Das Patchen bei der abgespeckten Version ist wie ein Firmwareupdate auf einer Hardwarekomponente zu sehen. Eine Anmeldung über ein Webinterface ist auch nicht möglich. Achten Sie bitte darauf, dass Sie manche Funktionen im ESXi nur nutzen können, wenn Sie nicht die Basisversion einsetzen, sondern die erweiterten Lizenzpakete verwenden. Darunter fallen die Nutzung von SNMP und die lesende und schreibende Möglichkeit über das vCLI. Beim vCLI handelt es sich um das vSphere Command Line Interface. Das Interface wird auf einem im Netzwerk befindlichen Computer installiert und ermöglicht das Absetzen von Konfigurationsbefehlen gegen das vCenter beziehungsweise den vSphere Host. Die Software kann sowohl unter Windows als auch unter Linux installiert werden. Analog dazu verhält es sich mit dem PowerCLI und dem vSphere SDK. Alle Kommandozeilentools verwenden dieselbe API, aus diesem Grund verhalten sich alle drei Tools in diesem Punkt identisch. Der Konfigurationsbefehlssatz zwischen der Service Console und dem vCLI ist leider nicht identisch. Nicht alle Befehle sind schon in der API implementiert. Daraus resultiert ein signifikanter Unter-
60
vCenter-Server
schied in den Optionen der Konfiguration über die Befehlszeile. Der Anschluss einer seriellen Konsole ist nur beim ESX Server möglich, ein Zugriff auf den ESXiHost über diesen Weg ist nicht aktivierbar. Es bleibt abzuwarten, wie sich die Unterschiede zwischen den beiden Versionen in Zukunft entwickeln. Es ist ja immer wieder zu lesen, dass VMware in der ESXiVariante die Zukunft sieht. Aus unserer Sicht fehlen aber noch einige wichtige Optionen, die von der Full Version zur ESXi-Version portiert werden müssen.
2.3
vCenter-Server
Der vCenter-Server ist Dreh- und Angelpunkt der VMware Infrastruktur. Mit ihm verwalten Sie das komplette VMware-Datacenter von der Konfiguration der ESXServer über das Erstellen von virtuellen Maschinen bis zum Einrichten der VMware-Features HA (High Availability) und DRS (Distributed Ressource Scheduling) sowie viele andere Funktionen. Des Weiteren bietet das vCenter eine Zugriffskontrolle auf Basis von Benutzern und Gruppen. Performance-Daten der vSphere-Server sowie der virtuellen Maschinen werden ebenfalls gesammelt und in der Datenbank abgelegt.
Abbildung 2.2
Struktur des vCenter-Servers
61
2.3
2
vSphere-Architektur
Der vCenter-Server ist nicht zwingend notwendig zum Betreiben von vSphereESX-Hosts, damit diese die Dienste bereitstellen können, um virtuelle Maschinen zu erstellen. Sie können jeden Host einzeln und unabhängig voneinander verwalten. Einige Dienste aber, wie z. B. DRS, setzen zwingend einen vCenter-Server voraus. Die Software bietet eine zentralisierte Verwaltung aller im VMware-Datacenter zusammengefassten Ressourcen, deren virtueller Maschinen sowie der Benutzer. Die zentralen Dienste des vCenters sind: 왘
Provisionierung von virtuellen Maschinen
왘
Konfiguration von vSphere-Servern (Hosts) und virtuellen Maschinen (VMs)
왘
Konfiguration von Resource-Pools
왘
Inventarisierung von vSphere-Ressourcen und virtuellen Maschinen
왘
Konsolenzugang zu den virtuellen Maschinen
왘
Statistiken und Protokolle zur Ressourcenauslastung
왘
Alarm- und Event-Management, um VI-Administratoren über Events und erhöhter Auslastung zu informieren
왘
rollenbasiertes Rechtemodell, um Objektgruppen zu verwalten
왘
Task-Scheduler, um bestimmte Aktivitäten zu bestimmten Zeiten automatisiert auszuführen
Diese zentralen Dienste des vCenters können um bestimmte Features erweitert werden. Dabei dient das vCenter als zentrale Schnittstelle, um die zusätzlichen Dienste, Distributed Services genannt, zu verwalten. Die erweiterten Dienste sind: 왘
VMware DRS
왘
VMware HA
왘
VMware Fault-Tolerance
왘
VMware VMotion
왘
VMware Storage VMotion
Des Weiteren bieten der Management-Server sowie der vSphere-Client eine Schnittstelle für Plug-ins zur Erweiterung der Funktionalität: 왘
vCenter Converter
왘
vCenter Update Manager
왘
vCenter Orchestrator
왘
Tools von Third–Party-Vendors oder auch Freewaretools (z. B. icomasofts PowerScripter)
62
vCenter-Server
Editionen Es gibt zwei Versionen des vCenter Servers von VMware: 왘
vCenter Server for Essentials (maximal 20 Hosts)
왘
vCenter Server Standard
Beim vCenter Server for Essentials handelt es sich um eine vCenter-Version für kleine Installationen mit maximal 20 Hosts und abgespecktem Funktionsumfang. Diese Version unterstützt nur die folgenden Funktionen: 왘
Thin Provisioning
왘
vCenter Agent
왘
vCenter Update Manager
왘
VMSafe
왘
vStorage-APIs
왘
VMware HA
왘
VMware Data Recovery
Wollen Sie weitergehende Funktionen nutzen, kommt nur der Einsatz der Standard-Version in Frage. Die Version vCenter Server Standard unterstützt zusätzlich zu den oben gelisteten Funktionen: 왘
Hot Add
왘
Fault-Tolerance
왘
vShield Zones
왘
VMotion
왘
Storage VMotion
왘
DRS
왘
vNetwork Distributed Switch
왘
Host-Profiles
왘
Third-Party Multipathing
Maximale Ausstattung Auch das vCenter kann nicht unendlich viele Ressourcen verwalten; es gilt die eine oder andere Einschränkung. Die Angaben beziehen sich auf die StandardVersion des vCenter Servers.
63
2.3
2
vSphere-Architektur
vCenter Server Scalability – 32-Bit-OS-Server
Anzahl
Hosts
200
powered-on VMs
2 000
registered VMs
3 000
concurrent vSphere-Client-Verbindungen Tabelle 2.6
15
Mögliche verwaltbare Infrastruktur für das vCenter mit 32-Bit-OS-Server
vCenter Server Scalability – 64-Bit-OS-Server
Anzahl
Hosts
300
powered-on VMs
3 000
registered VMs
4 500
concurrent vSphere-Client-Verbindungen Tabelle 2.7
30
Mögliche verwaltbare Infrastruktur für das vCenter mit 64-Bit-OS-Server
vCenter Server Scalability – vCenter Linked Node
Anzahl
Linked vCenter Server
10
Hosts im Linked Mode
1 000
powered-on VMs
10 000
registered VMs
15 000
Tabelle 2.8
Mögliche verwaltbare Infrastruktur für das vCenter im Linked Mode
vCenter Server Scalability – allgemein
Anzahl
Hosts pro Datacenter
100
Provisioning pro Host
8
Provisioning pro Datastore
8
VMotion pro Host
2
VMotion pro Datastore
4
Storage VMotion pro Host
2
Storage VMotion pro Datastore
4
gleichzeitige Operationen im vCenter Tabelle 2.9
64
vCenter – allgemeine Einschränkungen
96
vCenter-Server
Die Zahlen, die VMware hier ansetzt, sind an der einen oder anderen Stelle sicherlich sehr optimistisch gewählt. Sie sollen nur als Richtschnur dienen, damit Sie abschätzen können, wie viele Managementsysteme Sie benötigen. Zugriff Damit Sie die virtuelle Infrastruktur auch verwalten können, benötigen Sie ein Werkzeug, um auf die einzelnen Komponenten zuzugreifen. Hier gibt es zwei Möglichkeiten: Eine der Optionen ist die Nutzung eines Webbrowsers. Seien Sie sich dabei im Klaren, dass Sie nicht alle Funktionen mit dem Webclient durchführen können. Außerdem ist der Webzugriff von Haus aus deaktiviert. Die zweite Möglichkeit ist die Nutzung des vSphere-Clients. Mit diesem Client können Sie direkt einen Host administrieren oder sich damit am vCenter-Server anmelden. Lizenzierung Für die Verwaltung der VMware-Lizenzen in einer vSphere-Infrastruktur wird der im vCenter integrierte Lizenz-Server eingesetzt. In dieser Verwaltungskonsole tragen Sie alle VMware-Lizenzen ein und weisen sie den zugehörigen Hardwarekomponenten zu. Dieses gilt aber nicht für Hosts der Vorgängerversion, wie Sie im folgenden Absatz nachlesen können. License Server 3 Soll ein vCenter-Server der aktuellen Version (4.x) auch ESX 3.x-Hosts verwalten, so müssen Sie nach wie vor eine zusätzliche Komponente installieren. Es handelt sich um den alten Lizenz-Server, der schon in der Virtual Infrastructure 3 zum Einsatz kam. Dieser Lizenz-Server wird im Netzwerk bereitgestellt und in den vCenter-Eigenschaften konfiguriert. VMware Infrastructure SDK Es gibt die verschiedensten Möglichkeiten, in der virtuellen Infrastruktur Aufgaben zu automatisieren, auch außerhalb des vCenters und dessen Komponenten. Sie haben als Anwender verschiedene Optionen zur Verfügung, um eigene Anforderungen abzubilden. Dabei ist es egal, ob Sie mit der PowerShell skripten oder mit C programmieren möchten. Es gibt noch viele andere Möglichkeiten, das Management der Infrastruktur zu optimieren. Abbildung 2.3 zeigt nur eine Auswahl von Softwarepaketen, die VMware zur Verfügung stellt, damit Anwender das Management an ihre Bedürfnisse anpassen können.
65
2.3
2
vSphere-Architektur
Abbildung 2.3
Webseite mit Informationen zu APIs und SDKs
Wenn Sie sich für alle Informationen interessieren, finden Sie auf der eigens dafür eingerichteten Webseite Näheres zu dem gewünschten Thema. Die Webseite erreichen Sie unter http://www.vmware.com/support/pubs/sdk_pubs.html, wo Sie auch die Applikationen herunterladen können. Benötigte Netzwerkports – Implementierung Das vCenter kommuniziert über das Netzwerk mit den zu verwaltenden Komponenten. Die Verbindungen werden über einen Windows-Dienst (vpxd.exe) hergestellt. Die folgenden Ports werden für die Kommunikation benötigt.
66
vCenter-Server
vCenter-Server Port
Protokoll
Beschreibung
80
HTTP
Dieser Port wird für den direkten Webzugriff benötigt. Es erfolgt aber nur eine Umleitung auf Port 443.
389
TCP
Für die Kommunikation mit dem Active Directory wird dieser Port benötigt.
443
HTTPS
Port für die initiale Anmeldung über der vSphere-Client
636
SSL-Verbindung zwischen den vCenter-Servern beim Linked Mode
902
UDP
Kommunikation zwischen vCenter und vSphere-Hosts
902/903
TCP
Verbindung zwischen vCenter und vSphere-Client
1433
TCP
Verbindung zum Datenbankserver MS SQL
1521
TCP
Verbindung zum Datenbankserver Oracle
8080
HTTP
Web Services HTTP
8443
HTTPS
Web Services HTTPS
27000/ 27010
TCP
Lizenz-Server für VI 3.x-Umgebungen
Tabelle 2.10
vCenter-Kommunikationsports
Update Manager Port
Protokoll
Beschreibung
9084
TCP
Webserver Update Manager
8084
TCP
SOAP-Server Update Manager
80/443
TCP
Download von Patches aus dem Internet von den Websites: www.vmware.com , www.shavlik.com
Tabelle 2.11
Update-Manager-Kommunikationsports
Beim vCenter Converter werden unterschiedliche Ports genutzt. Dies hängt unter Umständen sogar davon ab, welches Betriebssystem importiert werden soll. In Tabelle 2.12 finden Sie die Ports für die Übernahme eines eingeschalteten Windows-Servers.
67
2.3
2
vSphere-Architektur
vCenter Converter (P2V Windows-Server eingeschaltet) Ports
Quelle
Ziel
Bemerkungen
445
Converter-Server
Quelle
Nutzt die Quelle NetBIOS, dann wird dieser Port nicht benötigt.
137/138 UDP
Converter-Server
Quelle
139
Converter-Server
Quelle
Kommt NetBIOS nicht zum Einsatz, werden diese Ports nicht benötigt.
9089
Converter-Server
Quelle
–
443
Converter-Server
vCenter-Server
Dieser Port wird genutzt, wenn das Ziel ein vCenter-Server ist.
443
Converter-Client
Converter-Server
Liegen der Client und der Converter auf unterschiedlichen Maschinen, dann wird dieser Port genutzt.
443/902
Quelle
vSphere-Host
Ist der vCenter-Server das Ziel, wird nur Port 902 benötigt.
Tabelle 2.12
vCenter-Converter-Kommunikationsports Windows online
Betrachten wir nun die benötigten Ports für die Übernahme eines aktiven LinuxServers. vCenter Converter (P2V Linux-Server eingeschaltet) Ports
Quelle
Ziel
Bemerkungen
22
Converter-Server
Quelle
Der Converter-Server muss eine Verbindung per SSH zur Quelle aufbauen können.
443
Converter-Client
Converter-Server
Ist nur relevant bei einer angepassten Installation und wenn Server und Client nicht auf einem Server liegen.
443
Converter-Server
vCenter-Server
Wird nur benötigt, wenn das Ziel ein vCenter-Server ist.
443/902/ Converter-Server 903
vSphere-Hosts
Ist das Ziel ein vCenter-Server, dann wird Port 443 nicht benötigt.
443
Converter-Server
Helper-VM
–
22
Helper-VM
Quelle
Die Hilfs-VM baut eine SSH-Verbindung zur Quelle auf.
Tabelle 2.13
68
vCenter-Converter-Kommunikationsports Linux online
Architektur eines vSphere-Hosts
Lassen Sie uns als Letztes dokumentieren, welche Freischaltungen Sie benötigen, wenn Sie eine bestehende virtuelle Maschine importieren möchten. vCenter Converter (P2V einer bestehenden VM) Ports
Quelle
Ziel
Bemerkungen
445/139
Converter-Server
Share oder Pfad
Nutzt die Quelle NetBIOS, dann wird dieser Port nicht benötigt.
137/138 UDP
Kommt NetBIOS nicht zum Einsatz, werden diese Ports nicht benötigt.
443
Converter-Client
Converter-Server
Ist nur relevant bei einer angepassten Installation und wenn Server und Client nicht auf einem Server liegen.
443
Converter-Server
vCenter-Server
Wird nur benötigt, wenn das Ziel ein vCenter-Server ist.
443/902
Converter-Server
vSphere-Host
Ist das Ziel ein vCenter-Server, dann wird Port 443 nicht benötigt.
Tabelle 2.14
2.4
vCenter-Converter-Kommunikationsports beim Import einer virtuellen Maschine
Architektur eines vSphere-Hosts
Die Architektur eines vSphere-Hosts definiert sich aus verschiedenen Kernkomponenten. Auf diese wollen wir im Folgenden eingehen.
Abbildung 2.4
Struktur VMware vSphere
69
2.4
2
vSphere-Architektur
VMkernel Der VMkernel ist eine sehr schlanke Implementierung des Hypervisors. Er kontrolliert und verwaltet die meisten Ressourcen eines vSphere ESX-Servers. Die Regelung des Zugriffs auf die Ressourcen CPU, Memory und Disk wird mit Hilfe eines Schedulers erreicht. Der Kernel hat neben einem TCP/IP-Stack zur Netzwerkkommunikation auch einen Storage-Stack für die Kommunikation mit Speichermedien. Der VMkernel ist eine Eigenentwicklung von VMware und nicht, wie viele meinen, ein Linux-Derivat. VMkernel Resource Manager Der Resource Manager partitioniert die Hardware, um den virtuellen Maschinen mit Hilfe eines Share-Mechanismus die Ressourcen zur Verfügung zu stellen. Dabei werden die Einstellungen zur Reservierung und zur Limitierung der Ressourcen CPU und Memory beachtet sowie die Shares aller Core Four (CPU, Memory, Network und Disk) berücksichtigt. Der Resource Manager wird als Teilprozess des VMkernels gestartet. Virtual Machine Monitor (VMM) Der Virtual Machine Monitor ist für die Virtualisierung der CPU zuständig. Er gibt die CPU-Befehle der virtuellen Maschine an die Physik weiter. Außerdem kümmert er sich um die Verwaltung der virtuellen Maschine nach deren Start. VMkernel Hardware Interface Layer Der Hardware Interface Layer setzt die Hardwareanfragen der VM in die physische Adressierung um und ermöglicht so eine Adressierung der Ressourcen. Außerdem koordiniert er die Bereitstellung des VMFS und der spezifischen Gerätetreiber. Service Console Die Service Console ist eine priorisierte virtuelle Maschine zur Verwaltung des vSphere-Servers und läuft mit einer abgespeckten Version des Red Hat Enterprise Linux 5.1. Die Service Console bietet dem VI-Administrator ein kommandozeilen-basiertes Verwaltungs-Interface für alle host-bezogenen Tätigkeiten, speziell für den VMKernel. Die Interaktion mit dem Anwender erfolgt über verschiedene Wege. Lokal am Server selbst erreichen Sie die Service Console über den Konsolenzugang. Dazu steht nach dem Booten des vSphere-Servers ein Linux-Prompt zur Anmeldung bereit. Auch über native Unix-/Linux-Wege etablieren Sie einen SSHZugang zur Service Console. Dazu existieren auf dem Markt verschiedene Tools
70
Grundlagen der CPU-Virtualisierung
(z. B. puTTY). VMware stellt ein Webmanagement-Interface bereit, das heißt, sie können Teile der Verwaltungsaufgaben über einen Webbrowser erledigen. Neben dem administrativen Zugang zur Console dient diese als Plattform für Agenten von Drittherstellern. Hersteller von Backup-Lösungen oder Überwachungssoftware integrieren vSphere-Server, indem Sie einen Agenten auf dem Betriebssystem der Service Console installieren.
2.5
Grundlagen der CPU-Virtualisierung
Bevor wir jetzt näher auf die CPU-Virtualisierung eingehen, möchten wir Ihnen zeigen, wie der logische Aufbau eines Prozessors aussieht. Als Beispiel haben wir das Schema einer Hexa-Core-CPU (6 Kerne) von AMD ausgewählt (Abbildung 2.5).
Core 1 Core 2 Core 3 Core 4 Core 5 Core 6 Level 1 Cache
Level 1 Cache
Level 1 Cache
Level 1 Cache
Level 1 Cache
Level 1 Cache
Level 2 Cache
Level 2 Cache
Level 2 Cache
Level 2 Cache
Level 2 Cache
Level 2 Cache
Level 3 Cache System Request Interface Crossbar Switch
Abbildung 2.5
TM
Link 3
Link 2
HyperTransport Technology
Link 1
72 Bit B us breite
72 Bit B us breite
RAM
Logischer Aufbau einer AMD-CPU
71
2.5
2
vSphere-Architektur
Unterhalb eines jeden Prozessor-Cores liegt der zugehörige Cache. Der Cache bildet das Bindeglied zwischen der CPU und dem Arbeitsspeicher. Der Arbeitsspeicher kann nicht so schnell getaktet werden wie der Cache. Damit aber der Zugriff auf den Speicher nicht das System ausbremst, werden im Cache Daten abgelegt, auf die das System öfter zugreifen muss. Spezielle Mechanismen sorgen dafür, dass die Daten im Cache getauscht werden, wenn das System andere Informationen häufiger benötigt als die derzeit gespeicherten. Der Cache gliedert sich in drei unterschiedliche Ebenen: Der Level-1-Cache ist direkt im Core integriert. Der Level-2-Cache ist ebenfalls dem einzelnen Core direkt zugeordnet. Erst der Level-3-Cache ist übergreifend allen Cores einer CPU zugänglich. Über das System Request Interface (SRI) und den Crossbar Switch kommunizieren die einzelnen Cores untereinander und mit den weiteren Komponenten der CPU, wobei der SRI die Priorisierung der CPU-Anfragen vornimmt. Der Speicher-Kontroller ist direkt auf dem Prozessor integriert, somit kann die CPU direkt mit dem Speicher Daten austauschen, ohne über einen zusätzlichen externen Speicherkontroller die Informationen verschicken zu müssen. Das erhöht zum einen die Performance, und zum anderen findet kein konkurrierender Zugriff der CPUs auf den Arbeitsspeicher statt. Die Hypertransport Technology (HT) bildet das Bindeglied zwischen dem Prozessor und der Peripherie im Server. Sie hat aber auch die Aufgabe, sich um die Kommunikation der einzelnen Prozessoren untereinander zu kümmern. Soll ein Befehl ausgeführt werden, wird eine Broadcast-Meldung an alle Prozessoren geschickt, damit gewährleistet ist, dass wirklich die aktuellsten Daten verarbeitet werden. Pro Core wurden früher mindestens zehn Nachrichten für den Abgleich benötigt. In einem Vier-Sockel-System (das heißt 48 Cores bei Hexa-Core-Systemen) bremsen die Nachrichten unter Umständen das System aus. An dieser Stelle greift die HT ein, koordiniert den Abgleich innerhalb der CPU und reduziert so die Anzahl der Nachrichten auf zwei bis drei für die Verbindung der CPUs untereinander. Nach diesem kurzen, aber wichtigen Ausflug in die Hardware eines Systems kommen wir nun zu dem Unterschied zwischen einer Virtualisierung und einer Emulation. Eine Emulation bildet Prozessoranfragen des Gasts über Software ab. Der Gast hat in diesem Fall keinen direkten Zugriff auf die CPU. Ein Virtualisierer leitet die Prozessoranfragen des Gasts direkt an die Hardware weiter.
72
Grundlagen der CPU-Virtualisierung
VMware vSphere ist ein Virtualisierer. Unter vSphere wird die CPU einer virtuellen Maschine direkt vom Host-System abgeleitet und auch für bestimmte Arten von CPU-Instruktionen teilweise physisch verwendet. Aus diesem Grunde sieht eine VM dieselbe CPU, wie sie im Host vorhanden ist. Die virtuelle CPU einer VM kann CPU-Instruktionen in zwei verschiedenen Modi abarbeiten: im Direct Execution Mode und im Virtualization Mode. In den meisten Fällen werden die CPU-Instruktionen im Direct Execution Mode ausgeführt, der nahe an der Geschwindigkeit der realen CPU liegt. Sollte die Ausführung des Befehls nicht in diesem Modus durchführbar sein, wird der Virtualization Mode verwendet. Eine virtualisierte CPU bedient sich so oft wie möglich der realen physischen CPU-Ressource, und die Virtualisierungsschicht greift nur bei der Ausführung von bestimmten CPU-Instruktionen ein. Durch diese Umsetzung entsteht der oft erwähnte Virtualisierungs-Overhead. Den Virtualisierungs-Overhead beziffern wir näher in Abschnitt 2.6.2, »MemoryOverhead«, im Zusammenhang mit dem Arbeitsspeicher.
virtuelle CPU
CPUCore
CPUSockel
Abbildung 2.6
Zusammenhang zwischen physischen, logischen und virtuellen CPUs
Dazu sei als Hintergrund erwähnt, dass eine CPU grundsätzlich vier Priviligierungsstufen hat, sogenannte Ringe oder auch Domains (Abbildung 2.7). Die höchste Priorität hat Ring 0. Hier liegt der sogenannte Supervisor Mode, der manipulativ auf Hauptspeicher und Interrupts zugreifen darf. In dieser Stufe läuft normalerweise der Kernel des Betriebssystems, im Falle von VMware vSphere also der Hypervisor-VMkernel. In den Ringen 1 bis 3 liegt der User-Mode, wobei normalerweise nur Ring 3 genutzt wird; es gibt nur wenige Applikationen, die direkt auf Ring 1 oder Ring 2 zugreifen.
73
2.5
2
vSphere-Architektur
Bei einer virtuellen Maschine verhält sich das etwas anders: Die eigentlich an Ring 0 gestellten Anfragen des Betriebssystems werden an Ring 3 umgeleitet. Damit die Daten in Ring 1 bis 3 verarbeitet werden können, wird der physische Speicher in virtuelle Speicherseiten aufgeteilt. Der Memory-Controller (Memory Management Unit, MMU) übernimmt an dieser Stelle die Umsetzung von physischen in virtuelle Speicherinhalten. Damit der Programmcode auch richtig ausgeführt werden kann, enthält jede Speicherseite die Information, auf welchem Ring der Code ausgeführt werden muss. Um zu verhindern, dass ein solch komplexes System beeinflusst wird – z. B. durch Schadcode –, wurde das sogenannte NXFlag kreiert (No Execution Flag). Diese Information hilft dem System, Daten von Programmcode zu unterscheiden. Dieser Mechanismus verhindert, dass Programmcode im Bereich der Daten ausgeführt werden kann.
Kernel-Mode User-Mode Ring 0
Ring 1 Ring 2 Ring 3
Abbildung 2.7
Ringstruktur der CPU
Applikationen rufen in der Regel den unprivilegierten Ring einer CPU an, daher laufen diese Befehle im Direct Execution Mode. Wird hingegen eine Instruktion vom Betriebssystem ausgeführt, geschieht dies in der Regel modifizierend auf den privilegierten Ring der CPU. Diese Anfragen werden von der Virtualisierungsschicht, dem VMM, abgefangen. Dieser Managementaufwand wird als der Virtualisierungs-Overhead bezeichnet. Er hängt ab von der Arbeitslast der virtuellen CPU und der Menge der Aufrufe an den privilegierten Ring. Die Auswirkungen zeigen sich in verlängerten Laufzeiten der einzelnen Befehle und durch eine erhöhte CPU-Last.
74
Grundlagen der CPU-Virtualisierung
Die reale CPU wird an das Betriebssystem der VM durchgereicht. Aus diesem Grund sind dem Betriebssystem auch die Besonderheiten der eingesetzten CPU bekannt. Verschiedene Betriebssysteme nutzen diese CPU-spezifischen Befehle. Es kann auch während der Installation der Gast auf diese Besonderheiten hin optimiert worden sein. Ein Verschieben einer solchen speziellen VM auf andere vSphere-Server mit unterschiedlichen CPUs, insbesondere beim Wechsel zwischen Intel- und AMD-Prozessoren, beeinträchtigt unter Umständen die Funktionalität des Betriebssystems beziehungsweise der Applikation.
2.5.1
CPU-Affinity
Die CPU-Affinität bezeichnet eine Konfigurationsoption der virtuellen Maschine, und zwar die direkte Zuweisung einer physischen CPU bzw. eines Kerns. Diese Technik sollten Sie nur in Ausnahmefällen (z. B. Troubleshooting) verwenden, weil sie etliche Auswirkungen auf andere Bereiche der virtuellen Infrastruktur hat. Zum einen wird dadurch die CPU-Lastverteilung des ESX-Servers außer Kraft gesetzt. Zum anderen kollidiert diese CPU-Zuordnung mit eventuell vorgenommenen Einstellungen von CPU-Shares und CPU-Reservierung. Durch das Umgehen der CPU-Lastverteilung kann der Hypervisor den Forderungen seitens der VM eventuell nicht mehr nachkommen. Die mögliche Virtualisierungsquote und die Flexibilität reduzieren sich. Die Nutzung von VMotion ist durch die CPU-Affinität eingeschränkt, und DRS verhindert diese sogar.
2.5.2
Hyperthreading
Der vSphere-Server unterstützt die Hyperthreading-Technologie von Intel. Diese bietet bei Nutzung von Ein-Sockel-Prozessoren der Pentium-4- und der XeonReihe ein auf Hardwareebene realisiertes Multithreading zur Verbesserung der CPU-Performance. Lange Zeit war Pause mit hyperthreading-fähigen CPUs, bis Intel diese in den neuen 5500-Xeon-Prozessoren wieder integrierte. Dabei kann eine physische CPU – im Intel-Wortgebrauch wird sie als Hyperthread bezeichnet – gleichzeitig zwei Threads ausführen. Sie verhält sich mit aktiviertem Hyperthreading ähnlich wie zwei logische CPUs. Sofern ein Betriebssystem und die darauf laufenden Applikationen zwei CPUs nutzen können, sind hierdurch Geschwindigkeitsvorteile möglich. Dabei reicht die Performance nicht an eine Verdoppelung heran, wie sie durch einen Dual-Core-Prozessor erreicht würde, die Leistung einer CPU verbessert sich aber je nach Anwendung auf dem Betriebssystem signifikant. Ungeeignete Applikationen werden durch die Hyperthreading-Technologie unter Umständen auch verlangsamt, wenn sie zu viel der gemeinsam genutzten Ressourcen eines Cores verwenden.
75
2.5
2
vSphere-Architektur
Auf der Hardwareebene muss das Hyperthreading im BIOS aktiviert sein. Im Host ist Hyperthreading per Default aktiv; bei Bedarf deaktivieren Sie es über den vSphere-Client im Tab Configuration eines vSphere-Hosts unter den Eigenschaften der CPU. Bedenken Sie bitte beim Einsatz von Hyperthreading, dass ein vSphere-Host nur eine bestimmte Anzahl von CPUs unterstützt. Der vSphere-Server verteilt die Last zwischen den Cores, um eine ausgewogene Auslastung zu erreichen. Wenn für eine logische CPU keine Last gefordert wird, wird sie in einen speziellen halt state geschaltet. Dabei kann eine andere VM auf dem Core von den zusätzlichen freien Ressourcen dieser CPU profitieren. Um virtuelle Maschinen mit für Hyperthreading problematischen Anwendungen ohne dieses Feature zu betreiben, bietet vSphere auf Ebene der VM drei verschiedene Modi des Verhaltens an, siehe Tabelle 2.15. Parameter
Funktion
any
Dies ist die Standardeinstellung und ermöglicht das Teilen der logischen CPUs eines Cores mit entweder einer weiteren virtuellen CPU der identischen VM oder einer virtuellen CPU einer anderen VM. Diese Einstellung bietet, sofern die Anwendungen dafür ausgelegt sind, die optimale Performance.
none
Diese Einstellung schaltet das Hyperthreading pro virtueller Maschine aus. Eine virtuelle CPU wird einer logischen CPU eines Cores zugeordnet, die zweite logische CPU wird in den halted state geschaltet. Da diese Einstellung eine virtuelle CPU vom restlichen System isoliert, wird diese Konfiguration für hyperthreading-problematische Applikationen verwendet und sollte nur nach Aufforderung durch den VMware-Support oder den Support des Anwendungsherstellers implementiert werden.
internal
Diese Einstellung beschränkt die Nutzung der zwei logischen CPUs auf eine VM und gilt daher nur für VMs mit aktiviertem vSMP. Eine VM teilt sich den Core nicht mit anderen VMs, sondern der Core wird nur für die virtuellen CPUs einer VM verwendet. Haben Sie diese Einstellung für eine Uniprocessor-VM ausgewählt, schaltet vSphere diese Einstellung automatisch auf None.
Tabelle 2.15
Hyperthreading-Parameter
Diese Einstellungen haben keinen Einfluss auf die Verteilung und Priorisierung von CPU-Ressourcen an die virtuelle Maschine.
2.5.3
Virtual SMP (vSMP)
Auch in virtuellen Umgebungen ist es nicht nur möglich, virtuelle Maschinen mit einer vCPU zu erstellen. Die aktuelle Version von VMware vSphere unterstützt
76
Grundlagen der CPU-Virtualisierung
bis zu acht virtuelle CPUs pro VM. VMware nennt diese Funktion Virtual SMP (Symmetric MultiProcessing) oder auch vSMP. Dabei ist einiges zu beachten: Grundsätzlich – das unterscheidet eine virtuelle Maschine nicht von einem physischen Server – ist nicht jede Applikation multiprozessorfähig. Vor der Erzeugung einer vSMP-Maschine sollten Sie dies abklären und dabei nicht nur das Betriebssystem (auf die HAL bzw. den Kernel achten), sondern auch die Anwendung beachten. Schauen wir noch einmal zurück auf den Beginn des Abschnitts 2.5, in dem wir den logischen Aufbau einer CPU erklärt haben. Da es allen CPUs einer VM möglich sein muss, auf identische Speicheradressen zuzugreifen, auch beim Cache, wird sofort klar, dass eine virtuelle Maschine mit mehreren CPUs am leistungsfähigsten arbeiten kann, wenn alle virtuellen Prozessoren auf einer logischen oder physischen CPU liegen. Liegen die Prozessoren auf unterschiedlichen Sockeln, dann können die virtuellen CPUs nicht in optimaler Geschwindigkeit miteinander kommunizieren. Die Ursache dafür ist, dass der Informationsaustausch der CPUs untereinander über den Frontside-Bus erfolgen muss. Auch beim Betriebssystem müssen Sie auf einiges achten. Denken Sie bitte daran, dass Sie bei mehreren CPUs in einer VM einen Multiprozessor-Kernel installieren müssen. Einen Weg zurück, zumindest bei Windows-VMs, unterstützt Microsoft nicht. Lassen Sie uns nun betrachten, wie VMware mit dem Thema vSMP und der Tatsache, dass freie Ressourcen anderen VMs zur Verfügung gestellt werden, umgeht. Während eine CPU im physischen Umfeld exklusiv einem Betriebssystem zur Verfügung steht, teilen sich die virtuellen Maschinen die CPU-Zyklen. Zur optimalen Abarbeitung der Prozesse werden diese in einem SMP- bzw. vSMP-System parallelisiert. Steht eine teilprozessabarbeitende Instanz nicht zur Verfügung, müssen alle anderen Teilprozesse so lange warten, bis auch dieser Prozess parallel zu den anderen abgearbeitet wurde. Diese Art der parallelen Abarbeitung wird auch Co-Scheduling genannt und dient grundsätzlich dazu, die Performance eines Systems zu erhöhen. Es könnte vorkommen, dass ein Watchdog-Timer auf einen Schwesterprozess warten muss. Reagiert dieser Prozess aber nicht in einem passenden Zeitfenster, stirbt er. Zur Messung dieser Varianzen wird der sogenannte Skew herangezogen. Dieser Wert repräsentiert den zeitlichen Unterschied zwischen den Prozessteilen. Überschreitet der Skew einen definierten Schwellenwert, dann wird die CPU der VM mit angehalten (co-stopped). Sie wird erst wieder mitgenutzt (costarted), wenn genügend Ressourcen für die Abarbeitung auf der physischen CPU vorhanden sind. Der Co-Stop verhindert, dass der Skew-Wert sich erhöht, er
77
2.5
2
vSphere-Architektur
kann nur sinken. Mit dem Relaxed Co-Scheduling wurde mit ESX 3 nämlich eine Funktion eingeführt, dass angehaltene vCPUs keine Skew-Wert-Erhöhung mehr erfahren. Somit wird ein zu häufiges Co-Scheduling verhindert.
L2
L2
L2
L2
Hauptspeicher Abbildung 2.8
SMP-Handling unter ESX 3
Der Skew-Wert hat aber noch eine weitere Funktion: Der VMkernel nutzt diesen Wert, um die Arbeitslast auf die physischen CPUs zu verteilen. Eine geskewte CPU hat Rechenzeit übrig, die andere VMs nutzen können.
L2
L2
L2
L2
Hauptspeicher Abbildung 2.9
SMP-Handling unter ESX 4
vSphere bringt wesentliche Änderungen gegenüber ESX 3 mit, da neben der deutlichen Minderung des Co-Stoppings nun auch die Nutzung aller Prozessorkerne ermöglicht wurde. Dadurch wurde ein wesentliches Problem der ESX 3Welt gelöst, da CPU-Anfragen der VMs teilweise unnötig warten mussten, weil nicht genügend Kerne einer physischen CPU verfügbar waren. Somit hat der CPU-Scheduler unter ESX 4 wesentlich mehr Möglichkeiten, CPU-Anfragen zu verteilen. ESX 3.x
ESX 4
V0, V1, V2, V3
V0, V1, V2, V3
V0, V1, V2
V0, V1, V2
V0, V1, V3
V0, V1, V3
Tabelle 2.16
78
SMP-Vergleich zwischen ESX 3 und ESX 4
Grundlagen der CPU-Virtualisierung
ESX 3.x
ESX 4
V0, V1
V0, V1 V0, V2 V1, V2 V0 V1 V2
Tabelle 2.16
SMP-Vergleich zwischen ESX 3 und ESX 4 (Forts.)
Es gilt zwar auch weiterhin unter vSphere vSMP, dass weniger mehr ist, allerdings ist es wesentlich entspannter geworden, Mehrprozessor-VMs zu verwenden. Das Hauptkriterium sollte immer noch die Anforderung der Anwendung und des Systems sein und nicht der Gedanke, dass mehr CPUs auch automatisch mehr Leistung bedeuten.
2.5.4
Best Practices
Nachfolgend finden Sie einige Empfehlungen zum Umgang mit CPU-Reservation, -Limits und -Shares: 왘
Erfahrungsgemäß werden Prozessoren nicht zurückgerüstet, auch wenn sie eigentlich nicht benötigt werden. Bei Mehrprozessor-VMs fangen Sie einfach mit einer Zweiprozessor-Maschine an. Weitere Prozessoren lassen sich immer noch später hinzukonfigurieren. Vergeben Sie niemals mehr Prozessoren, als sich Cores auf der CPU befinden.
왘
Einer virtuellen Maschine sollten Sie zu Beginn grundsätzlich niedrige CPURessourcen zuweisen, um im laufenden Betrieb die Ressourcenauslastung anhand der vCenter-Performance-Messung zu analysieren.
왘
Es ist besser, mit CPU-Shares anstelle von CPU-Reservierungen zu arbeiten.
왘
Beim Einsatz von CPU-Reservierungen sollten Sie das aktuelle Minimum definieren, das eine VM benötigt, nicht aber die gewünschte absolute Menge an CPU in MHz. Wenn eine VM mehr Ressourcen benötigt, so weist der vSphereServer diese, je nach definierten Shares, bis zu einem eventuell definierten CPU-Limit dynamisch zu. Des Weiteren ist zu beachten, dass der Einsatz von CPU-Reservierungen die auf einem Host zur Verfügung stehenden CPU-Ressourcen limitieren und dadurch weniger VMs gestartet werden können. Zu hohe Reservierungen behindern möglicherweise auch Funktionen wie DRS oder HA. Das Verschieben von virtuellen Maschinen kann durch die Ressourcenauslastung der vSphere verhindert werden.
79
2.5
2
vSphere-Architektur
2.6
Grundlagen der Memory-Virtualisierung
Der physische Speicher eines Hosts wird in drei Segmente unterteilt: System, Virtual Machines und Service Console. Der Speicherbereich für System wird vom VMkernel und von den Gerätetreibern verwendet und ist nicht konfigurierbar. Er wird mit einer Größe von mindestens 50 MByte beim Starten des vSphereHosts angelegt und variiert je nach Anzahl und Art der verwendeten PCI-Geräte und deren Treibern. Der Speicherbereich für die Service Console ist konfigurierbar – bis zu einem Maximalwert von 800 MB – und bleibt für die Verwendung innerhalb der Service Console reserviert. Diese benötigt je nach installierten Agenten, z. B. für Backup oder Monitoring, eine gewisse Menge an Speicher. Der Speicherbereich für Virtual Machines ist der Rest des physischen Speichers und wird komplett für die VMs genutzt.
A B A B
A Abbildung 2.10
B B
C B
virtuelle Speicheradressierung im Gast
B C
physikalische Speicheradressierung im Gast
C
physikalischer Hauptspeicher im Host
Speicheradressierung zwischen VM und Host
Zur Verdeutlichung hier zuerst eine Erklärung zur generellen Nutzung von Speicher innerhalb eines Betriebssystems. Dieser wird in einem Betriebssystem über virtuelle Speicheradressen erreicht, die auf physische Adressen verweisen. Ein Zugriff von einer virtuellen Maschine auf den physischen Speicher eines vSphere-Hosts ist nicht erlaubt. Um den virtuellen Maschinen Speicher zur Verfügung zu stellen, bietet vSphere eine weitere, virtuelle Schicht. Diese gaukelt der VM die physischen Speicheradressen vor. Im VMware-Wortgebrauch heißt der physische Speicher im Host Machine Memory Pages, und die der VM virtualisiert vorgegaukelten physischen Speicherseiten nennen sich Physical Memory Pages. Die Physical Memory Pages für eine VM sind, so wie es ein Betriebssystem erwartet, mit durchgängigen Nullen gefüllt. Sie sind durch die Virtualisierungsschicht aus verschiedenen Bereichen, aber nicht zusammenhängend, zusammen-
80
Grundlagen der Memory-Virtualisierung
gefasst. Diese Bereiche sind z. B. normale, physische Speicherbereiche (Machine Memory Pages), von vSphere Shared Pages oder auch Swapped Pages. Das virtuelle Speichermanagement erfolgt durch den Host, unabhängig vom in der VM laufenden Betriebssystem, über den VMkernel. Dieser greift von der VM alle Befehle ab, die auf den Speicherbereich schreibend zugreifen möchten, und leitet diese auf die der VM vorgegaukelten Physical Memory Pages um. Der Speicher wird normalerweise in 4-KB-Blöcke eingeteilt. Es werden aber auch Memory-Blöcke von 2 MB unterstützt. Diese Funktion können Sie nur pro VM konfigurieren. Dazu aktivieren Sie in dem Konfigurations-File die Funktion Mem.AllocGuestLargePage=1. Dies ist empfehlenswert, wenn die VM große Speicherseiten benötigt, wie z. B. ein Datenbank-Server.
2.6.1
Virtual Machine Memory
Der Speicherbereich, der für die VMs zur Verfügung steht, wird Virtual Machine Memory genannt und bietet allen VMs die Speicherressourcen des vSphere-Servers abzüglich eines Virtualisierungs-Overheads. Dem Betriebssystem wird vorgegaukelt, dass der Speicher, der in der Konfiguration festgelegt wurde, auch vorhanden ist. Der physisch zugewiesene Speicher kann aber variieren, bis zum konfigurierten Maximum. Auch hier setzen Sie über die Einstellung der Shares-Werte eine Priorität gegenüber den anderen VMs, die auf demselben Host arbeiten. Eine Reservierung weist den Speicher der virtuellen Maschine fest zu.
2.6.2
Memory-Overhead
Der Memory-Overhead hängt ab von der Anzahl der CPUs, der Art des GastBetriebssystems (32 oder 64 Bit) und natürlich dem der VM zugewiesenen Speicher. Dieser Memory-Overhead stellt einen Speicherbereich zur Verfügung, um VM-Frame-Buffer sowie auch verschiedene Virtualisierungsdatenstrukturen abzulegen. Die Nutznießer dieses Speichers sind zum einen der VMkernel und zum anderen der VMM, die beide für die korrekte Arbeit der virtuellen Maschinen benötigt werden. Der einzukalkulierende Overhead ist in Tabelle 2.17 aufgeführt. Die Aufstellung berücksichtigt die Abhängigkeit zwischen der Anzahl der vCPUs und dem zugewiesenen Arbeitsspeicher. Durch Nutzung eines 64-Bit-Betriebssystems verdoppeln sich die Werte.
81
2.6
2
vSphere-Architektur
Memory (MB) 1 vCPU
2 vCPUs 3 vCPUs 4 vCPUs 5 vCPUs
6 vCPUs
7 vCPUs
8 vCPUs
256
113,17
159,43
200,53
241,62
293,15
334,27
375,38
416,50
512
116,68
164,96
206,07
247,17
302,75
343,88
385,02
426,15
1.024
123,73
176,05
217,18
258,30
322,00
363,17
404,34
445,52
2.048
137,81
198,20
239,37
280,53
360,46
401,70
442,94
484,18
4.096
165,98
242,51
283,75
324,99
437,37
478,75
520,14
561,52
8.192
222,30
331,12
372,52
413,91
591,20
632,86
674,53
716,19
16.384
334,96
508,34
550,05
591,76
900,44
942,98
985,52
1.028,07
32.768
560,27
863,41
906,06
948,71
1.515,75
1.559,42
1.603,09
1.646,76
65.536
1.011,21 1.572,29 1.616,19 1.660,09
2.746,38
2.792,30
2.838,22
2.884,14
131.072
1.912,48 2.990,05 3.036,46 3.082,88
5.220,24
5.273,18
5.326,11
5.379,05
262.144
3.714,99 5.830,60 5.884,53 5.938,46 10.142,83 10.204,79 10.266,74 10.328,69
Tabelle 2.17
Memory-Overhead bei virtuellen Maschinen
2.6.3
Memory-Overcommitment
vSphere bietet die Möglichkeit, mehr RAM an virtuelle Maschinen zu vergeben, als physisch im Host selbst vorhanden sind. Dieses Feature nennt sich MemoryOvercommitment und setzt sich zusammen aus drei verschiedenen Techniken, dem Page-Sharing, dem Memory-Ballooning und dem Memory-Swapping. Das Bestreben aller Techniken ist das Verteilen von ungenutzten Speicherbereichen von einer VM zu anderen Maschinen, die aktuell mehr Speicher benötigen. Die Priorisierung erfolgt auch in diesem Fall über die Eingestellten Share-Werte.
2.6.4
Content-based Page-Sharing
Die Page-Sharing-Technik wird beim Betrieb von mehreren VMs auf einem Host verwendet. Es wird versucht, identische Memory-Pages der VMs zusammenzufassen. Die dabei beobachtete Speicher-Blockgröße ist so klein, dass es vollkommen unerheblich ist, ob auf den virtuellen Servern identische Software installiert ist oder nicht. Trotzdem gelingt dies umso besser, je homogener die verschiedenen Gastbetriebssysteme sind, also wenn mehr identische Server-Applikationen darauf laufen. Ein gutes Beispiel ist eine Server-Farm mit identischen Webservern, die aber alle unterschiedlichen Webcontent hosten. Es ist zu erwarten, dass diese Systeme eine große Anzahl von identischen Speicherblöcken haben, die vom VMM zusammengefasst werden können. So werden redundante Speicherinhalte eliminiert. Will nun eine der virtuellen Maschinen einen solchen Speicherbereich
82
Grundlagen der Memory-Virtualisierung
beschreiben, dann wird für diesen Server eine Kopie des Speicherblocks exklusiv für ihn angelegt, so dass er ihn frei nutzen kann. Bei dieser Technik sind bis zu 30 % Speicherersparnis erreichbar. Bei weniger homogenen Memory-Inhalten reduziert sich die Ersparnis auf ca. 5 %.
2.6.5
Memory-Ballooning
Das in Abschnitt 2.6.3, »Memory-Overkommitment«, beschriebene MemoryOvercommitment kann nur einwandfrei funktionieren, wenn dem Host ein Mechanismus zur Verfügung steht, das das Management des Arbeitsspeichers im virtuellen System übernimmt, und das natürlich im laufenden Betrieb. Dafür ist das sogenannte Memory-Ballooning zuständig. Der Memory-Balloon-Treiber (vmmemctl) kommt ins Spiel, wenn der Speicher eines Hosts zu knapp wird oder wenn eine VM an ihre Speichergrenzen stößt. Braucht der Host Speicher, dann hat Ballooning immer Vorrang vor dem Swappen.
1
2
3
Abbildung 2.11
Darstellung des Memory-Balloonings
Wird Speicher benötigt, dann gibt der VMM dem Ballooning-Treiber das Kommando zur Anforderung von Speicher vom OS (Abbildung 2.11, 1). Ist genug Speicher vorhanden, gibt die VM demjenigen Treiber Speicher, der in der FreeList steht. Ist kein freier Speicher vorhanden, wird dem Gast-OS überlassen, welcher Speicher freigegeben werden kann.
83
2.6
2
vSphere-Architektur
Der vSphere-Kernel gibt im Hintergrund die vom Ballooning-Treiber markierten Speicherseiten frei, bis genug Speicher für den Host akquiriert worden ist (2). Anschließend beginnt der Ballooning-Treiber, den reservierten Speicher wieder freizugeben (3). Das Verhalten des Memory-Balloonings können Sie pro vSphere-Server durch den Parameter sched.mem.maxmemctl festlegen. Dieser Wert bestimmt die maximale durch diese Technik von einer virtuellen Maschine abziehbare Speichermenge und wird in Megabytes angegeben.
2.6.6
Memory-Swapping
Das Memory-Swapping dient ebenso wie das Ballooning zum Zuweisen von mehr Arbeitsspeicher an die VM. Diese Technik ist für den Host die letzte, aber auch langsamste Möglichkeit, Speicher für andere virtuelle Maschinen zur Verfügung zu stellen. Beim Start einer VM wird automatisch ein solches Swapfile angelegt. Swapping tritt zu dem Zeitpunkt in Aktion, wenn der Hypervisor nicht die Möglichkeit hat, über den Ballooning-Treiber festzustellen, welche Speicherseiten zurückgegeben werden können. Die Ursache dafür kann auch sein, dass keine VMware Tools installiert oder kein Ballooning-Treiber vorhanden ist. Bootet die VM (zu diesem Zeitpunkt sind noch keine VMware Tools aktiv), ist der Treiber auch nicht produktiv. Des Weiteren kommt diese Technik auch zum Zuge, wenn das Memory-Ballooning zu langsam ist, um den Speicherbedarf einer VM zu decken. Das Swapping ist generell langsamer als das Ballooning. Es wird eine Swap-Datei pro VM auf dem Volume abgelegt, und zwar im Verzeichnis der virtuellen Maschine. Das Swapping garantiert einer VM einen mindestens verfügbaren Speicherbedarf, damit die VM starten kann. Dieser Speicherbereich, die Swap-Datei, ist der der VM jetzt neu zugewiesene Speicher und wird beim Einschalten einer VM angelegt. Die Größe variiert je VM und ist die Differenz zwischen dem Reservierungswert und dem zugewiesenen Speicher einer VM. Eine Besonderheit bei der Verwendung von Memory-Swapping sollten Sie beachten: Im Falle eines Ausfalls des ESX-Servers werden diese Swap-Dateien nicht mehr automatisch gelöscht. Sie müssen sie dann manuell löschen, wozu das Stoppen und Starten einer VM notwendig wird.
2.6.7
Best Practices
Nachfolgend finden Sie einige Empfehlungen zum Umgang mit Memory-Reservation, Memory-Limits und Memory-Shares:
84
Grundlagen der Hardwarevirtualisierung
왘
Grundsätzlich sollten Sie den Einsatz von Memory-Overcommitment vermeiden. Dies bewirkt auf jeden Fall eine Verlangsamung. Sollte die Überbelegung des Speichers unvermeidbar sein, achten Sie darauf, dass nicht das MemorySwapping genutzt wird, denn dies reduziert die Performance einer VM deutlich.
왘
Sie sollten Memory-Shares gegenüber von Memory-Reservierungen den Vorzug geben.
왘
Beim Einsatz von Memory-Reservierungen sollten Sie ein Minimum an RAM definieren, den die eine VM benötigt. Falls eine VM mehr Ressourcen benötigt, so werden diese vom Host, je nach Shares, bis zum eventuell definierten Memory-Limit dynamisch zugewiesen. Beachten Sie außerdem, dass der Einsatz von Memory-Reservierungen die auf einem vSphere-Server zur Verfügung stehenden Speicherressourcen limitiert. Somit können weniger VMs gestartet werden, selbst dann, wenn andere VMs den reservierten Speicherbereich nicht nutzen. Auch kann DRS in seiner Funktion behindert werden, da hier die Ressourcenauslastung des Hosts ein Verschieben von virtuellen Maschinen verhindert.
왘
Ein Delegieren von Ressourcen-Management erreichen Sie idealerweise durch die Einführung von Resource-Pools. Dabei geben Sie die Grenzen des Resource-Pools an, also die Reservierung und das Limit, um die darin laufenden virtuellen Maschinen von den weiteren Ressourcen eines Hosts zu isolieren.
2.7
Grundlagen der Hardwarevirtualisierung
Wie wir bis jetzt gezeigt haben, wird bei der klassischen Virtualisierung dem Gast eine virtuelle Hardware zur Verfügung gestellt. Das sehen Sie sehr schön, wenn Sie eine virtuelle Maschine booten: Sofort ist der vom Computer bekannte BIOSSchirm sichtbar. Gehen Sie in die Tiefen des BIOS, stellt sich die virtuelle Maschine wie ein ganz normaler Computer dar. Alle Elemente eines Computers werden in der VM emuliert, seien es der Festplatten-Controller, die Netzwerkkarte oder andere Hardwareelemente. Wie schon beschrieben, handelt es sich um einen »normalen« PC, nur eben virtuell. Der Vorteil besteht darin, dass Sie ein Betriebssystem – die passenden Treiber vorausgesetzt – einfach in die virtuelle Hülle bringen können. Anschließend installieren Sie die Applikation, und fertig ist der virtuelle Server. Es gibt aber noch andere Varianten von virtuellen Maschinen, die sogenannten paravirtualisierten VMs.
85
2.7
2
vSphere-Architektur
VM
VM
Applikation
Applikation
Betriebssystem modifiziertes Betriebssystem Virtuelle Hardware
Hypervisor Abbildung 2.12
Unterschied zwischen klassischer und paravirtueller VM
Abbildung 2.12 stellt den Unterschied zwischen beiden Varianten dar. Sie veranschaulicht, dass bei der paravirtuellen Maschine der Layer der virtuellen Hardware fehlt. Dafür existiert eine definierte Schnittstelle. Sie steuert die Ressourcen und den direkten gemeinsamen Zugriff auf die physische Hardware. Ein solcher Mechanismus kann aber nur funktionieren, wenn dem Betriebssystem der Hypervisor »bekannt« ist. Als Ergebnis erhöht sich die Performance der virtuellen Maschine, denn es fehlt die Schicht der virtuellen Hardware. Die direkte Kommunikation zwischen dem Gastsystem und dem Hypervisor wird als Paravirtualisierung bezeichnet. Es gibt aber nur wenige Betriebssysteme, die die Paravirtualisierung unterstützen. Ursache dafür sind die starken Eingriffe, die in dem Kernel erforderlich sind. Einzig einige freie Betriebssysteme unterstützen die Paravirtualisierung. Es handelt sich um verschiedene Linux-Derivate. Der Grund ist relativ logisch, denn der Kernel ist frei, und somit kann, das Wissen vorausgesetzt, der Kernel für die Paravirtualisierung angepasst werden. Im Gegensatz zu dem kompletten Ansatz, dass der Layer der virtuellen Hardware vollständig entfällt, gibt es Teilansätze, auf die wir hier kurz eingehen wollen. Lassen Sie uns zuvor etwas ausholen: Warum geht VMware diesen Weg, und welche Vorteile bringen diese Technologien?
86
Grundlagen der Hardwarevirtualisierung
Der Layer, der Hardwarevirtualisierung, ist eine Softwarekomponente, die die Hülle für die VM simuliert. Das bedeutet aber im Gegenzug, dass alle Aktionen, die über diese Schicht laufen, Last in diesem Layer erzeugen, bevor die Daten an die eigentliche Hardwarekomponenten gelangen, wie z. B. die Netzwerkkarte. Das erzeugt Rechenzeit auf der CPU und bremst die Performance. Der Ansatz, dem nun gefolgt wird, ist, Teilkomponenten zu paravirtualisieren. Der Vorteil dabei ist, dass nicht der gesamte Kernel angepasst werden muss, sondern dass es reicht, passende »Hardwaretreiber« für das Gastbetriebssystem zur Verfügung zu stellen. An zwei Stellen gibt es bereits entsprechende Ansätze: bei der neuen Netzwerkkarte vmxnet3 und bei dem paravirtualisierten SCSI-Adapter (PVSCSI). Auf die Funktionen der beiden Adapter gehen wir an entsprechender Stelle im Kapitel 13, »Virtuelle Maschinen«, im Buch ein. Lassen Sie uns jetzt die allgemeinen Beschreibungen verlassen und direkt in die Materie vSphere 4 einsteigen.
87
2.7
VMotion und das erst mit VI 3.5 hinzugekommene Storage VMotion werden täglich über zehntausend Mal von VMware-Kunden weltweit genutzt und haben sich als zuverlässige und enorm nützliche Funktionen etabliert.
3
VMotion und Storage VMotion Autor dieses Kapitels ist Dennis Zimmer, icomasoft AG,
[email protected]
VMotion und Storage VMotion haben zwar eine unterschiedliche Funktion, allerdings sind Teile der Technologie überlappend, daher passen die beiden vSphere-Funktionen gut in ein Kapitel. Beide Technologien sind reaktiv, das heißt, VMotion wird zum Migrieren einer virtuellen Maschine zwischen funktionierenden ESX-Hosts verwendet, und Storage VMotion migriert die Daten der virtuellen Maschinen zwischen funktionstüchtigen Datastores. Beide vSphereFeatures sind nicht mehr möglich, wenn eine Quelle oder ein Ziel ausgefallen ist, und sind daher nicht proaktiv. Daher dienen VMotion und Storage VMotion der höheren Ausfallsicherheit, da Sie Wartungsfenster an den Hosts und Datastores ohne Ausfall überbrücken können; es sind aber keine Funktionen zur Steigerung der Hochverfügbarkeit, was oft falsch verstanden wird.
3.1
VMotion
Von VMotion, der Live-Migrationsfunktion von VMware, hat mit Sicherheit bereits jeder Leser gehört, daher fasse ich mich kurz: VMotion ist die Funktion, aktive virtuelle Systeme von einem ESX-Host auf einen anderen zu verschieben, ohne dass die virtuelle Maschine oder deren Dienste ausfallen. VMotion, oder auch Hot Migration, steht im Gegensatz zur Cold Migration, die nur bei ausgeschalteter VM möglich ist und eine gleichzeitige Migration zwischen Host-Systemen und Datastores zulässt. Außerdem entfällt bei der Cold Migration die sehr restriktive Notwendigkeit ähnlicher Host-Prozessoren. Zu
89
3
VMotion und Storage VMotion
guter Letzt unterstützt Cold Migration die Migration von VMs zwischen Datacenter-Objekten, während VMotion nur innerhalb eines Datacenters erlaubt ist. Dies ist mittlerweile sogar so ausgefeilt, dass es auch bei Tests auf Messen mit Hunderttausenden von VMotion-Migrationen nie zum Verlust einer VM oder deren Dienste kam. Allerdings ist nicht jede virtuelle Maschine für VMotion geeignet, was im Laufe des Kapitels näher erläutert wird.
3.1.1
Funktionsweise
Denkt man genauer über VMotion nach, so muss man gestehen, dass der Vorgang simpel, aber genial ist, und er stellt die Lösung der Ausfallsicherheit von Systemen während eines regelmäßigen Problems dar – Wartungen am Host. Außerdem erkennt man durch VMotion sehr leicht, wie sinnvoll die Unabhängigkeit und Trennung der Hardware vom Betriebssystem und von der Applikation wirklich ist.
Abbildung 3.1
VMotion-Migration aktiver virtueller Maschinen zwischen ESX-Hosts
Doch schauen wir uns den VMotion-Prozess aus Sicht der virtuellen Maschine im Detail an: 1. Überprüfung, ob die Quell-VM auf dem gewünschten Ziel-Server betrieben werden kann 2. Erstellung einer zweiten VM als Prozess auf dem Zielsystem inklusive der Ressourcenreservierung 3. Anlage eines Hauptspeicher-Checkpoints, das heißt, alle Änderungen der Quell-VM werden in einen zusätzlichen Speicherbereich geschrieben
90
VMotion
Quelle
Ziel Anschalten der Ziel-VM
VM läuft auf dem Quellsystem
~1 Sek.
VM läuft nicht
Pre-Copy VM Memory
VMotion Abbruch möglich
Checkpoint-Save Quell-VM und Übertragungsstatus Übertragung der restlichen Hauptspeicheränderungen Checkpoint-Restore Ziel-VM Send Restore OK, Send RARP
VM läuft auf dem Zielsystem
Abbildung 3.2
Abschalten der Quell-VM
VMotion-Vorgang aus Sicht der virtuellen Maschine
4. Übertragung des Hauptspeicherinhalts des Checkpoints zur Ziel-VM 5. Wiederholung des Checkpoint/Checkpoint-Restore-Vorgangs, bis nur noch kleinste Änderungsmengen im Hauptspeicher der Ziel-VM ausstehen 6. CPU-Stop der Quell-VM 7. Übertragung der letzten Hauptspeicheränderungen zur Ziel-VM innerhalb von Millisekunden 8. Abschluss des VMotion-Vorgangs und Senden des Reverse-ARP-Pakets an die physikalischen Switches (wichtig: Notify Switches muss in den Eigenschaften der virtuellen Switches aktiviert sein). Übernahme des Festplattenzugriffs vom Ziel-ESX. 9. Abschalten der Quell-VM – Löschung des VM-Prozesses auf dem Quell-ESX Noch eine kurze Anmerkung dazu, was die VMotion-Checkpoints überhaupt umfassen bzw. wofür sie stehen: 왘
alle Geräte inklusive Status
왘
CPU-Register
왘
Hauptspeicherinhalt
왘
Serialisierung des Status zur Übertragung über das Netzwerk
Wie Sie sehen, besteht VMotion hauptsächlich aus der Übertragung des Hauptspeichers von einem ESX-Server auf den anderen mit einer anschließenden Benachrichtigung des physikalischen Netzwerks über die neue Schnittstelle, über die die VM neuerdings erreichbar ist. Das Gastsystem bekommt davon natürlich nichts mit.
91
3.1
VMotion und Storage VMotion
Folgend ein Berechnungsbeispiel für die Hauptspeicherübertragung: Pre-Copy Iteration
zu übertragender Hauptspeicher
1
2.048 MB
2
verbrauchte Zeit Hauptspeicheränderung zur Übertragung während der Übertragung 16 Sekunden
512 MB
512 MB
4 Sekunden
128 MB
3
128 MB
1 Sekunde
32 MB
4
32 MB
5
8 MB
Tabelle 3.1
0,25 Sekunden
8 MB
VMotion-Abschluss, da die Restübertragung in ~0,06 Sekunden erfolgt
Hauptspeicherkopie während VMotion
Wie in Tabelle 3.1 zu sehen ist, erfolgt die Kopie des Hauptspeichers sukzessive in mehreren Schritten, bis ein CPU-Stop möglich ist, der nicht zum Ausfall des Systems führt. An VMotion sind mehrere Komponenten beteiligt, die jeweils Teile des Prozesses steuern. vCenter führt dabei die ersten Konfigurationsprüfungen durch und startet den Prozess über die vpxa- und hostd-Komponenten, indem eine Pseudo-VM als Container auf dem Ziel-Host erstellt wird. Das VMotion-Modul startet den eigentlichen VMotion-Vorgang und kontrolliert die Datenübertragung.
vCenter kümmert sich um die korrekte Konfiguration
vCenter Vpxa- und hostd-Schnittstellen werden zur Erstellung der VM durch das vCenter genutzt
VMotion-Module starten und kontrollieren den VMotion-Vorgang
vpxa
hostd
VM
VM
Ziel-ESX
vmx
vmx
vpxa
vmm
hostd
vmm
FC/iSCSI/NFS
Abbildung 3.3
92
VMotionNetzwerk
vmotion
Quell-ESX
vmotion
3
VMFS NFS
Beteiligte Komponenten bei VMotion
FC/iSCSI/NFS
VMotion
Da vCenter nur den Prozess validiert und startet, aber nicht in die Datenübertragung involviert ist, wird ein aktiver VMotion-Prozess zu Ende geführt, selbst wenn das vCenter abstürzen sollte. Es kann allerdings passieren, dass vCenter danach die Quell-VM weiterhin in der Datenbank hat und noch nichts vom neuen Ort der Ziel-VM weiß. In diesem Fall hilft ein Restart des vpxa-Agenten (service mgmt-vmware restart in der Service Console) oder ein Disconnect/Connect des ESX-Hosts im vCenter.
Abbildung 3.4 Ein VMkernel-Adapter muss für VMotion aktiviert werden, damit VMotion funktionieren kann.
Das zu nutzende VMotion-Interface muss vom Administrator angelegt werden und setzt auf dem VMkernel-Port auf, das heißt, in den Eigenschaften des VMkernel-Ports muss VMotion auf Enabled gesetzt werden.
3.1.2
Voraussetzung
Da es sich bei VMotion um einen Eingriff in eine aktive virtuelle Maschine handelt, die ihrerseits davon keine Kenntnis hat, müssen verschiedene Gegebenheiten vorhanden sein, damit der Prozess ohne Ausfall und Probleme ablaufen kann: 왘
CPU-Kompatibilität
왘
VMotion-Interface (mindestens 1-GBit-Adapter)
왘
gemeinsamer, zentraler Massenspeicher
왘
gleich benannte virtuelle Portgruppen
왘
ausreichende Ressourcen auf dem Ziel-Host
왘
mindestens vSphere-Advanced-Edition-Lizenz auf den entsprechenden ESXHosts
Ein richtiges Problem stellt zumeist nur die CPU-Kompatibilität dar, da die Server-Infrastrukturen in vielen Unternehmen nach wie vor organisch wachsen und nicht jegliche Server-Hardware über gleiche Komponenten verfügt. Ob eine virtuelle Maschine zwischen zwei ESX-Servern migriert werden kann, ist leicht fest-
93
3.1
3
VMotion und Storage VMotion
gestellt, da das vCenter gegebenenfalls bereits vor der eigentlichen Migration den Prozess mit einer entsprechenden Fehlermeldung abbricht. CPU-Kompatibilität Das Problem der CPU-Kompatibilität ist ganz leicht zu erklären. Stellen Sie sich vor, eine virtuelle Maschine wird auf einem ESX-Host mit AMD-CPU und SSE3Funktion gestartet. Da VMware ESX ein Virtualisierer ist, sieht das Gastbetriebssystem die CPU-Funktionen im Standard komplett, und das Betriebssystem kann sich den Gegebenheiten anpassen und durch Zusatztreiber die Multimediafunktion gut nutzen. Würde diese virtuelle Maschine nun einfach auf einen Host übertragen, dessen CPU nur SSE2 unterstützt, so würde das Gastbetriebssystem trotzdem weiter die SSE3-Funktion nutzen wollen. Es käme zwangsweise zu Problemen bis hin zum Absturz kommen. Während diese Schwierigkeit durch das sogenannte CPU-Masking in den Griff zu bekommen ist, wäre es bei größeren CPU-Unterschieden ein unlösbares Problem, z. B. der Wechsel von einer AMD- auf eine Intel-CPU oder der Wechsel von einer 64-Bit- auf eine 32-Bit-CPU. Da der ESX-Server nicht voraussagen kann, welche CPU-Instruktion die virtuelle Maschine, oder besser das Gastbetriebssystem, nutzt und noch nutzen wird, muss der Anwender sich darum kümmern, entweder gleiche CPUs zu verwenden oder ein entsprechendes Masking einzurichten. Welche Funktionen die eingebaute CPU hat, finden Sie mit dem VMwareeigenen CPU Identification Utility heraus, das die VMotion-Kompatibilität, EVC und den 64-Bit-Support anzeigt: http://www.vmware.com/download/shared_ utilities.html Welche CPUs miteinander kompatibel sind, erfahren Sie übrigens in den VMware-Knowledge-Base-Artikeln 1991 (Intel) und 1992 (AMD): Intel: http://kb.vmware.com/kb/1991 AMD: http://kb.vmware.com/kb/1992 Es existiert beim Upgrade von VI 3.x auf vSphere leider noch ein sehr ernstes Problem bezüglich des CPU Maskings, welches unter VI 3.x oft automatisch den virtuellen Maschinen gesetzt wird. Nach dem Upgrade lassen sich manche virtuelle Maschinen dann nicht mehr per VMotion migrieren und man erhält eine Fehlermeldung.
94
VMotion
Abbildung 3.5
CPU Masking zurücksetzen in den Eigenschaften der VM
Die Lösung ist recht einfach, da nur das CPU Masking auf Default per Reset All to Default in den CPU Identification Mask Eigenschaften der virtuellen Maschinen ausgewählt werden muss. Ärgerlich ist, dass die VM abgeschaltet werden muss, um diese Einstellung vorzunehmen. Den dazugehörigen Knowledge-Base-Artikel findet man hier: http://kb.vmware.com/kb/1011294
95
3.1
3
VMotion und Storage VMotion
CPU-Masking und EVC
Abbildung 3.6 In den Eigenschaften der virtuellen Maschine beeinflussen Sie das CPU-Masking.
In den Eigenschaften einer virtuellen Maschine finden Sie unter den Optionen den Punkt CPUID Mask, um einer abgeschalteten VM CPU-Funktionen auszublenden. Durch diese Ausblendung von CPU-Features erhöhen Sie die VMotionKompatibilität zwischen ESX-Hosts mit unterschiedlichen CPU-Generationen erhöht. Die Standardmöglichkeit ist das Verstecken des Non-Execution-Bits, das nur von neueren CPUs unterstützt wird (Hide the NX/XD flag from guest). Wird dieses aktiviert, so kann eine virtuellen Maschine zwischen ESX-Servern migriert werden, wobei es egal ist, ob die Prozessoren über die NX-Funktion verfügen oder nicht, es sei denn, es sind noch weitere CPU-Instruktionen auf den CPUs unterschiedlich, die nicht ausgeblendet werden.
Abbildung 3.7 Eine direkte Ausblendung bestimmter Funktionen ist für Intel- und AMD-CPUs möglich.
96
VMotion
Reicht das Non-Execution-Bit nicht aus, so ist es möglich, CPU-Hersteller-spezifisch Anpassungen zu machen, d. h. entweder allgemein, für AMD- oder für IntelProzessoren die Register anzupassen. Möchten Sie z. B. bei den genutzten AMDProzessoren die SSE3-Funktion verstecken, so sähe die Anpassung wie folgt aus: Level 1 – Reihe ecx : ---- ---- ---- ---- ---- ---- ---0 –0-0
Abbildung 3.8
SSE3 wird durch diese Anpassung für die VM ausgeblendet.
Einen sehr guten VMware-Knowledge-Base-Artikel zu den verschiedenen Maskierungen mit den entsprechenden Prozessoren finden Sie hier: http://kb.vmware.com/kb/1993 Möchten Sie die Änderung rückgängig machen, so reicht entweder die Auswahl Reset Row to Default, wenn Sie gerade die angepasste Reihe ausgewählt haben, oder Sie setzen direkt alles zurück, indem Sie Reset All to Default auswählen. Komfort der Geschwindigkeit Sie müssen bei der Anpassung der CPU-Maskierung immer bedenken, dass ein Verstecken bestimmter Funktionen das Gastbetriebssystem ausbremsen kann, falls dieses mit diesen Funktionen schneller betrieben werden könnte. Im Endeffekt entscheiden Sie sich zwischen Komfort und Geschwindigkeit, abhängig vom Gastbetriebssystem.
EVC (Enhanced VMotion Compatibility) Wollen Sie die CPU-Maskierung nicht für jede virtuelle Maschine definieren, bietet der EVC-Cluster (er wird im Kapitel 4, »Cluster«, näher beschrieben) die Möglichkeit, CPU-Funktionen global auszublenden, das heißt, in den Cluster-Eigenschaften wird definiert, welche CPU-Generation von den virtuellen Maschinen innerhalb des Clusters gesehen wird.
97
3.1
3
VMotion und Storage VMotion
Abbildung 3.9 In den Cluster-Eigenschaften können Sie die CPU-Generation global für den gesamten Cluster einrichten.
EVC ermöglicht es seit vSphere auch, die Prozessorgeneration während des Betriebs der virtuellen Maschinen zu erhöhen, z. B. von CPU-Generation 1 auf 2, allerdings nicht umgekehrt. Wird die CPU-Generation erhöht, so erhalten aktive virtuelle Maschinen erst nach einer Abschaltung oder einem Reset die neue Einstellung. Innerhalb des EVC-Clusters garantiert die EVC-Funktion, dass es zu keinen CPUInkompatibilitäten der CPU Generationen bei den VMotion-Vorgängen kommt. Andere Gründe zur Verhinderung von VMotion werden dadurch nicht ausgeschlossen, z. B. Nutzung von lokalen Festplatten.
3.1.3
Bedienung
Die Bedienung von VMotion ist sehr intuitiv und trivial, da eine aktive virtuelle Maschine einfach per Drag & Drop auf einen anderen ESX-Host gezogen werden muss. Da die virtuelle Maschine angeschaltet ist, startet der VMotion-Prozess automatisch mit dem ersten Dialog. Eine andere Variante ist die Auswahl Migrate im Kontextmenü einer virtuellen Maschine. Der Unterschied zwischen diesen beiden Möglichkeiten der Bedienung ist, dass letztere auch für Storage VMotion genutzt werden kann und natürlich eine weitere Abfrage bezüglich des Zielsystems und des Resource-Pools erscheint.
98
VMotion
Abbildung 3.10 Start des VMotion-Vorgangs aus dem Kontextmenü der virtuellen Maschine
Abbildung 3.11 Change host steht für VMotion, Change datastore für Storage VMotion.
Haben Sie sich für die Drag-and-Drop-Variante entschieden, fällt der Dialog deutlich kürzer aus, und Sie haben nur die Wahl der VMotion-Priorität. Übrigens ist es auch möglich, mehrere virtuelle Maschinen gleichzeitig zu markieren und per Drag & Drop oder Kontextmenü zu migrieren.
Abbildung 3.12
Abfrage der VMotion-Priorität
Bei der Auswahl der VMotion-Priorität sollten Sie möglichst immer Reserve CPU for optimal VMotion Performance auswählen, damit eine entsprechende Absicherung der Ressourcen auf dem Zielsystem gewährleistet ist und der VMotion-Prozess möglichst schnell ablaufen kann. Außerdem wird der VMotion-Prozess direkt abgebrochen, falls die Ressourcen auf dem Zielsystem nicht direkt zur Verfügung stehen.
99
3.1
3
VMotion und Storage VMotion
Die Auswahl Perform with available CPU Resources kann den VMotion-Vorgang zeitlich deutlich in die Länge ziehen, da auf die Ressourcen gewartet wird, anstatt sie direkt zu reservieren. Daher werden diese Migrationen auch immer ausgeführt, selbst bei Problemfällen mit zu hohem Hauptspeicherbedarf. Die virtuelle Maschine kann daher auch kurzzeitig nicht zur Verfügung stehen, falls die Ressourcen auf dem Zielsystem nicht rechtzeitig vorhanden sind.
Abbildung 3.13
In der Ereignisanzeige der VM können Sie VMotion direkt nachvollziehen.
Sobald der VMotion-Prozess gestartet wurde, kann der gesamte Prozess in den Events der Host-Systeme und der virtuellen Maschine nachvollzogen werden. Damit können Sie auch die Dauer des gesamten Prozesses im Nachhinein prüfen. Während der Laufzeit lässt sich nicht nachvollziehen, wie lange der Prozess noch dauern wird. In der Standardkonfiguration sind nur zwei VMotion-Migrationen gleichzeitig pro Host und vier VMotion-Migrationen pro VMFS-Datastore zugelassen.
3.1.4
Sicherheit
Die VMotion-Datenübertragung findet im Klartext statt. Daher ist es nicht nur aus Performance-, sondern auch aus Sicherheitsgründen zu empfehlen, ein dediziertes Netzwerk für den VMotion-Verkehr zu betreiben. In keinem Fall sollte der VMotion-Verkehr mit dem Netzwerkverkehr der virtuellen Maschinen vermischt werden, sprich über die gleichen Netzwerkadapter betrieben werden, ohne zumindest eine VLAN-Trennung durchzuführen.
3.1.5
Problemfälle
Neben den vielen möglichen Inkompatibilitäten, die eine Migration verhindern, existieren auch Problemfälle, die nicht einfach zu erkennen oder zu beheben sind.
100
VMotion
Lokale Geräte Viele lokale Geräte verhindern unter Umständen VMotion, und der Prozess bricht bereits bei der ersten Überprüfung mit einer Fehlermeldung ab.
Abbildung 3.14 Problem beim Zugriff auf die Diskette durch den Ziel-ESX-Host, da ein lokales Medium verwendet wurde
Dies ist z. B. bei lokalen Festplatten der Fall. Bei für den VMkernel »weniger wichtiger« Geräten wie beispielsweise lokal verbundenen Wechselmedien erscheint eine Warnmeldung, dass das Gerät auf dem Zielsystem nicht verfügbar ist. Sind Sie damit einverstanden, wird der VMotion-Vorgang ohne den Anschluss der CD oder Diskette fortgesetzt. Dies gilt nicht bei bestehender Verbindung eines Client-Device, da dort eine direkte Verbindung von Client zu ESX Server hergestellt ist. In diesem Fall ist VMotion verboten. Datacenter Es ist nicht möglich, virtuelle Maschinen mit VMotion über Datacenter-Grenzen zu migrieren. Dies ist nur in abgeschaltetem Zustand ausführbar. Allerdings kann zwischen allen anderen kompatiblen ESX-Hosts innerhalb des Datacenters migriert werden. Allerdings sollte der Grund dieser Limitierung immer im Auge behalten werden. Da Datacenter meist räumlich voneinander getrennt sind und über schmalbandige Kommunikationsverbindungen verfügen, ist es äußerst unwahrscheinlich, den gleichen Shared Storage von beiden Rechenzentren erreichen zu können. Aus diesem Grund sollten Sie auch bei der Offline-Migration daran denken, dass eine Datenübertragung einer 50-GB-VM möglicherweise die gesamte Leitungskapazität zwischen den Rechenzentren für eine lange Zeit komplett vereinnahmt, was einer Denial-of-Service-Attacke gleichkäme. Gleiche Portgruppe = gleiches Netzwerk? VMotion achtet bei der Prüfung der Netzwerke nur auf die Portgruppennamen, ohne die physikalische Verbindung prüfen zu können. Existieren zwei ESX-Hosts mit der Portgruppe LAN (der die virtuelle Maschine auch angehört), die aber auf
101
3.1
3
VMotion und Storage VMotion
unterschiedliche physikalische Netzwerke konfiguriert sind, kann der VMotionProzess zwar erfolgreich abgeschlossen werden, der VM allerdings steht kein funktionierendes Netzwerk mehr zur Verfügung. Sie ist in dem Fall zwar noch aktiv, aber die Netzwerkverbindung zur Außenwelt ist gekappt – Sie hätten die VM sozusagen »totmigriert«. Hauptspeicheränderungen Ein sehr typischer Problemfall sind virtuelle Maschinen, die enorm viele Änderungen im Hauptspeicher durchführen. Je größer die Hauptspeichermenge und je mehr Änderungen, desto schwieriger stellt sich die Möglichkeit einer reibungslosen VMotion-Migration dar. Kommt es stetig zu Abbrüchen bei einer VM, sollten Sie sich deren Hauptspeicheraktivitäten näher anschauen. Ein Beispielsystem hierzu wären Webserver, die viele dynamische Webseiten hosten und die Inhalte im Hauptspeicher vorhalten und stetig verändern. Diese problematischen Vorgänge werden aber nach und nach auch durch Unterstützung der Prozessorhersteller behoben, da diese mit Funktionen wie AMDs Nested Page Tables und Tagged TLBs (die zusammen als AMD Rapid Virtualization Index benannt sind) eine deutliche Beschleunigung bringen und den HyperVisor selbst entlasten. Nähere Informationen zu den AMD Technologien finden Sie unter folgender URL: http://www.amd.com/us/products/technologies/virtualization/Pages/ virtualization.aspx SCSI-Reservation-Conflicts Ein weiterer möglicher Grund sind zu hohe SCSI-Reservation-Conflicts, das heißt, die virtuelle Maschine kann nicht migriert werden, da das Zielsystem keinen rechtzeitigen Zugriff auf die SAN-Festplatten erhält. Dieses Problem tritt nur bei IP/FC SAN auf und kommt aufgrund von Treiberfehlern oder deutlich häufiger wegen Überlastung zum Tragen. Informationen über SCSI-Reservations sind in den VMkernel-Protokollen der ESX-Server zu finden. Swapfile Es existiert auf Host-Ebene die Möglichkeit, die Auslagerungsdateien der virtuellen Maschinen auf lokale Festplatten des ESX-Hosts zu legen, anstatt sie im zentralen Speicher vorzuhalten. Das spart auf der einen Seite zwar teuren SAN-/NAS-Plattenplatz, führt aber dazu, dass neben dem Hauptspeicher der virtuellen Maschine auch mit dem Swap-Speicher umgegangen werden muss. Liegen alle Daten im Shared Storage,
102
VMotion
so muss der Swap-Speicher nicht bewegt werden; liegt er jedoch auf dem lokalen ESX-Host, muss er zusätzlich übertragen werden, was einen VMotion deutlich verlängern kann.
Abbildung 3.15
Anpassung des Swapfiles der virtuellen Maschinen im Cluster
Abbildung 3.16 ESX-Hosts
Anpassung des Swapfiles der virtuellen Maschinen in den Eigenschaften des
Video-RAM Auf ein sehr ungewöhnliches Problem stößt man, wenn der Video-RAM der virtuellen Grafikkarte zu stark erhöht ist. Typischerweise bricht VMotion in diesem Fall ab und bringt folgende Meldung: A general system error occurred: Failed to write checkpoint data (offset 33558328, size 16384): Limit exceeded
Hintergrund ist eine VMotion-Limitierung, die keinen Video-RAM größer 30 MB erlaubt. Stellen Sie daher den Video-RAM aufgrund höherer Auflösungen in der virtuellen Maschine auf z. B. 64 MB, so verweigert VMotion mit oben genannter Fehlermeldung den Dienst.
103
3.1
3
VMotion und Storage VMotion
Timeouts und langsame Übertragung Schlägt VMotion bei 10 % fehl, so handelt es sich um ein Problem mit der Verbindung zum Ziel-Host. Sie sollten sich in diesem Fall das VMkernel-Protokoll (/var/log/vmkernel) auf dem Quell-ESX-Server anschauen. Dauert VMotion sehr lange oder bricht ab, kann dies an einem sehr langsamen Netzwerk liegen, in dem keine rechtzeitige Rückmeldung durch den Ziel-ESX gesendet wird. Es existieren Fälle, bei denen das GBit-Netzwerk aufgrund einer Fehleinstellung auf den Ethernet-Switches auf 100 MBit halbduplex heruntergestuft wurde, was zu diesem Problem führte. Hier sollten Sie sich auch die aktuelle Geschwindigkeit der Netzwerkkarten anschauen (esxcfg-nics -l auf der Service Console/RCLI) und das VMkernel-Protokoll des Ziel-Servers einsehen.
Abbildung 3.17 Hosts
Advanced Settings für VMotion-Vorgänge in den Eigenschaften des ESX-
Ist das Netzwerk im Normalzustand sehr langsam, ist es möglich, die SwitchoverTime zu erhöhen, beispielsweise in den Advanced Settings des ESX-Hosts. VMotion funktioniert nach VM-Hardware-Upgrade nicht mehr Ein bekanntes Problem besteht übrigens bei virtuellen Maschinen, deren Hardware von Version 4 (ESX 3) auf Version 7 (vSphere) aktualisiert wurde und die entweder in einem EVC-Cluster waren oder deren CPU-Masking angepasst wurde. Bei diesen VMs bricht VMotion immer direkt mit einer Fehlermeldung ab, die auf eine nicht unterstützte VM-Konfiguration hinweist. Die Lösung in diesem Fall ist das Zurücksetzen des CPU-Maskings in den Eigenschaften der virtuellen Maschine.
104
VMotion
NFS-Storage In den VMware-Foren existieren Beiträge zu VMotion-Abbrüchen bei 78 %, wenn NFS-Datastores genutzt wurden. Das ist definitiv kein allgemeiner Fehler, sondern kommt nur bei vereinzelten manchen Kunden vor. Hintergrund ist die unterschiedliche Einstellung bei der NFS-Freigabe an die verbundenen Host-Systeme. Dies stellen Sie sehr leicht fest, indem Sie die DatastoreUUIDs miteinander vergleichen. Sollten diese unterschiedlich sein, müssen Sie die Konfiguration auf dem Storage für die ESX-Hosts vereinheitlichen und die Datastores neu verbinden. Die UUIDs der Datastores können Sie auf der Kommandozeile mit vdf auslesen: /vmfs/volumes/18341836-debecbc6 50.0G 100k 50.0G
0% /vmfs/volumes/nfs
Dieses Ergebnis muss auf allen ESX-Hosts gleich sein. Ausfälle Jegliche Form von Ausfällen können zu einem Fehlschlagen des VMotion-Vorgangs beitragen, z. B. Netzwerk-, Storage- oder Host-Ausfälle. VMotion ist allerdings so konzipiert, dass keiner dieser Ausfälle zum Totalverlust der virtuellen Maschine führen würde. Ein Ausfall auf dem Quellsystem, während die VM noch dort residiert, wirkt sich daher genau wie ein Ausfall ohne VMotion-Vorgang aus. Ein Ausfall des Zielsystems betrifft die virtuelle Maschine erst nach dem Senden des RARP-Paketes (Reverse ARP) und des VMotion-OK-Signals. Protokolldateien Sämtliche Informationen zu den VMotion-Vorgängen finden sich in den Protokolldateien der virtuellen Maschinen und der beteiligten ESX-Hosts. Dort können Sie nach den Begriffen »Migrate«, »migration id« oder »VMotion« suchen. 왘
Home-Verzeichnis der virtuellen Maschine
vmware.log enthält die Informationen zu der Ziel-VM. vmware-
.log speichert die Informationen der Quell-VM. 왘
Host-Protokolle befinden sich auf Quell- und Ziel-ESX-Host
/var/log/vmkernel /var/log/vmware/hostd*.log Zeitunterschiede Beachten Sie mögliche Zeitunterschiede der ESX-Hosts bei der Protokollanalyse.
105
3.1
3
VMotion und Storage VMotion
3.1.6
Lizenzierung
VMotion ist ab der Advanced Edition und höher integriert und wird aufgrund der vSphere-Lizenzierung der Editionen pro CPU-Sockel lizenziert.
3.1.7
Zukunftsaussichten
VMotion wurde seit der Einführung von Administratoren sehr gerne und häufig genutzt. Daher wird auch die Weiterentwicklung in Bezug auf Prozessorkompatibilität immer weitergehen, allerdings bezweifle ich derzeit, dass irgendwann AMD- mit Intel-Systemen kompatibel sind. Ein weiterer Trend zeichnet sich bei der VMotion-Funktion über große Distanzen ab, das heißt, Quell- und Ziel-ESX stehen Dutzende, Hunderte oder Tausende Kilometer voneinander entfernt. Hier kommen immer mehr Unternehmen auf den Markt, die an Systemen arbeiten, die die Latenz und die Datenübertragung über große Distanzen so optimieren, dass auch zwischen den USA und Europa eine VMotion-Funktion realisiert werden kann. Diese Technologien für den als Long Distance VMotion bezeichneten Migrationsvorgang sind bereits zum großen Teil verfügbar und wurden auf Messen wie beispielsweise der VMworld bereits eindrucksvoll vorgeführt. Ein entsprechendes Whitepaper von EMC, Cisco und VMware ist hier zu finden: http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/ns836/ white_paper_c11-557822.pdf
3.2
Storage VMotion
Das Verschieben einer virtuellen Maschine von einem Datastore auf einen anderen war bis zu VI 3.5 nur im abgeschalteten Zustand erlaubt. Einen Ausblick auf die Storage-VMotion-Funktion bot erstmals die Online-Migration einer VM von ESX 2.5 (VMFS-2) auf ESX 3 (VMFS-3). Mit VI 3.5 wurde erstmals Storage VMotion als Funktion etabliert, war allerdings nur über die VMware SDK und das Remote CLI als Befehl verfügbar, eine grafische Implementierung fehlte gänzlich. Andrew Kutz, ein VMware-Community-Mitglied, entwickelte daher das erste inoffizielle Storage-VMotion-Plug-in, das ein grafisches Frontend als vCenter-2.5Plug-in bereitstellte. vSphere bringt nun von Haus aus die grafische Integration von Storage VMotion mit.
106
Storage VMotion
Abbildung 3.18 Storage VMotion ermöglicht das Verschieben einer kompletten VM auf einen anderen Datastore ohne Ausfall.
Storage VMotion hat sich wie VMotion als sehr zuverlässig und sehr schnell herausgestellt und wird daher von VMware-Kunden sehr gerne verwendet, um ... 왘
virtuelle Maschinen besser auf den Datastores zu verteilen,
왘
Storage-Planungsfehler der Vergangenheit zu beheben,
왘
die Systeme auf neue Datastores (z. B. Wechsel des zentralen Speichersystems, Tiered Storage Modell) zu migrieren,
왘
die VMFS-Version zu aktualisieren und
왘
Storage-Wartungsfenster zu überbrücken.
3.2.1
Funktionsweise
Da von Storage VMotion gesprochen wird, kommt es zeitweise zu einem Missverständnis, dass durch Storage VMotion sowohl der ESX-Host als auch der Datastore gleichzeitig gewechselt werden könne. Dies ist nicht der Fall, allerdings führt Storage VMotion beim Wechsel der Konfiguration der virtuellen Maschine ein sogenanntes Self-VMotion durch, wodurch dieser Begriff wieder gerechtfertigt ist. Storage VMotion kann aus dem vSphere-Client, dem Remote CLI, der PowerCLI oder der VMware SDK gestartet werden. Storage VMotion hat folgende Eigenschaften: 왘
VM verbleibt auf dem gleichen ESX-Host.
왘
VM Festplatten individuell auf Datastores migrierbar.
107
3.2
3
VMotion und Storage VMotion
왘
keine Abhängigkeit vom Massenspeicher (SAN/NAS)
왘
Thick/Thin-Format-Unterstützung und -Konvertierung
왘
RDM-zu-VMDK-Konvertierung
왘
keine Ausfallzeit
왘
komplett transparent für das Gastbetriebssystem
왘
minimale Leistungsaufnahme
Damit Sie die Migration der virtuellen Maschine von einem Datastore auf einen anderen besser verstehen, müssen Sie zuerst darüber nachdenken, aus welchen Dateien die VM normalerweise besteht: 왘
Konfigurationsdatei (.vmx)
왘
Protokolldateien (.log)
왘
Auslagerungsdatei (.vswp)
왘
Snapshots (-delta)
왘
andere Dateien (.nvram etc.)
왘
Festplattendateien
Bis auf die Festplattendateien liegen alle Dateien in der Standardkonfiguration im Home-Verzeichnis der virtuellen Maschine. Die Festplattendateien können entweder ebenfalls im Home-Verzeichnis liegen oder über mehrere Datastores verstreut sein.
4 »Self-VMotion« des VM mit Nutzung des Ziel-Homeverzeichnisses und der Festplatten
4 Übertragung der restlichen Festplattendaten 5 2 Quelle Löschung des FestplattenQuell-VM-HomeSnapshot verzeichnis und der Quell-Festplatten Abbildung 3.19
108
Storage VMotion in Aktion
1
Ziel
3
Kopie des HomeKopie der FestVerzeichnisses in plattendaten Ziel-Datastore (Mehrfach-Iteration)
Storage VMotion
Schauen wir uns die einzelnen Schritte des Storage-VMotion-Prozesses aus Sicht der virtuellen Maschine im Detail an (vgl. Abbildung 3.19): 1. Überprüfung, ob die Quell-VM auf den/die gewünschten Ziel-Datastore(s) verschoben werden kann 2. Kopieren des Home-Verzeichnisses auf den Ziel-Datastore (Ausnahme Festplattendateien) 3. Anlage eines Snapshots auf die Festplattendateien 4. Übertragung der Festplattendateien zum Ziel-Datastore vor dem Snapshot 5. Übertragung der restlichen aufgelaufenen Snapshot-Dateien iterativ, bis nur noch wenige Restdaten vorhanden sind 6. Kopieren aller restlichen Daten mit gleichzeitigem Self-VMotion (Fast Suspend/Resume) 7. Löschen des Quell-Home-Verzeichnisses und der Quell-Festplatten Für die unterschiedlichen Vorgänge sind zwei Komponenten zuständig, der NFC Copier und der Data Mover. Der NFC Copier ist für die »normalen« Dateien im Home-Verzeichnis verantwortlich, der Data Mover kümmert sich um die größeren Festplattendateien, die iterativ (mit Snapshot-Einsatz) kopiert werden müssen. Beide Komponenten arbeiten über dem Dateisystem, das heißt, sie sind unabhängig vom Speichersystem und können mit VMFS und mit NFS arbeiten. Außerdem kann der Aufbau der Festplattendatei durch den Data Mover verändert werden (Thick/Thin).
3.2.2
Voraussetzung
Genau wie für VMotion müssen auch für Storage VMotion bestimmte Voraussetzungen erfüllt werden, damit ein problemloser Ablauf gewährleistet ist: 왘
VMs mit bestehenden Snapshots können nicht migriert werden.
왘
Virtuelle Festplatten müssen im persistenten Modus sein, damit Snapshots möglich sind.
왘
Werden Raw-Device-Mappings im virtual compatibility mode genutzt, sind eine Migration der reinen Mapping-Datei und die Konvertierung des RDMs in eine Thin- oder Thick-Festplattendatei (außer bei NFS) möglich. Bei RDMs im physical mode kann die Mapping-Datei nur migriert, nicht aber in eine vmdk-Datei konvertiert werden.
왘
Migration während der Installation der VMware Tools ist nicht unterstützt.
109
3.2
3
VMotion und Storage VMotion
왘
Der ESX-Host, auf dem die virtuelle Maschine betrieben wird, muss über eine Storage-VMotion-fähige Lizenz verfügen.
왘
ESX/ESXi-3.5-Systeme müssen für VMotion lizenziert und konfiguriert sein.
왘
Ab ESX/ESXi 4.0 ist keine VMotion-Konfiguration mehr notwendig.
왘
Der ESX-Host, auf dem die virtuelle Maschine betrieben wird, muss vollen Zugriff auf Quell- und Ziel-Datastore besitzen.
왘
In der Standardkonfiguration sind nur zwei Storage-VMotion-Migrationen gleichzeitig pro Host und vier Storage-VMotion-Migrationen pro VMFS-Datastore zugelassen.
Vorsicht Vorsicht mit VMware-Backups während Storage-VMotion-Vorgängen. Da beide Prozesse mit Snapshots arbeiten, kann es zu sehr kritischen Storage-VMotion-Problemen kommen, wenn ein zusätzliches Programm auf die Snapshots zugreift.
Abbildung 3.20
Belastung Storage-VMotion-Vorgang
Wie in Abbildung 3.20 zu sehen ist, kommt es zu einem deutlichen Ressourcenanstieg während des gesamten Storage-VMotion-Vorgangs. Allerdings ist Storage VMotion als Prozess so ausgelegt, möglichst wenige von virtuellen Maschinen genutzte Ressourcen zu blockieren. Trotzdem ist eine gewisse Mehrbelastung des ESX-Hosts nicht von der Hand zu weisen, und die Dauer der Storage-VMotionÜbertragung verlängert sich natürlich, je weniger Ressourcen zur Verfügung stehen.
110
Storage VMotion
Abbildung 3.21
Festplattenbedarf während des Storage-VMotion-Vorgangs
Außerdem nicht vernachlässigen sollten Sie den benötigten Festplattenbedarf auf dem Quell- und dem Ziel-Datastore. Sie müssen bedenken, dass auf dem QuellDatastore durch die Snapshots zusätzlich REDO-Logs vorgehalten werden müssen, die die Änderungsdaten während des gesamten Storage-VMotion-Prozesses aufnehmen. Diese Logs wachsen kontinuierlich. Auf dem Ziel-Datastore werden erst die Quell-Festplatten mit den Daten vor der Anlage des Snapshots kopiert, und erst nach der vollständigen Übertragung werden die restlichen REDO-Logs kopiert. Daher benötigen Sie natürlich den gesamten Plattenplatz für die VM mit ihren Daten auf dem Ziel-Datastore und je nach Datenänderungen während der Übertragung noch einen gewissen Spielraum auf dem Quell-Datastore. Je größer die Gesamtdatenmenge der virtuellen Maschine ist und je länger der Übertragungsprozess dauert, desto größer wird die benötigte Zusatzkapazität auf dem Quell-Datastore. Genaue Zahlen können wir hier nicht liefern, aber Sie sollten bei der Berechnung großzügig mit 20 % Zusatzkapazität der zu migrierenden VM auf dem Quell-Datastore kalkulieren. Leistungseinbußen Durch die Datenmenge, die übertragen werden muss, kommt es natürlich zu einer enormen Schreib-/Lese-Belastung des Storage-Systems. Außerdem müssen Sie bedenken, dass Storage VMotion sequentiell mit sehr großen Blöcken arbeitet, während der normale Betrieb virtueller Maschinen eher von kleinen Blöcken und Random-Zugriff geprägt ist. Daher treffen auch zwei verschiedene Zugriffsarten auf den Storage, wobei sequentiell immer bevorzugt wird und daher der Random-Zugriff etwas benachteiligt ist. Gerade bei Einstiegs- und Mittelklasse-Storage-Modellen kann dies zu erheblichen Leistungseinbußen führen.
111
3.2
3
VMotion und Storage VMotion
3.2.3
Bedienung
Da der gleiche Wizard für VMotion und Storage VMotion Verwendung findet, ist auch der Weg zum Aufruf des Wizards der gleiche: über das Kontextmenü der virtuellen Maschine.
Abbildung 3.22 Wie bei VMotion wird der Wizard über das Kontextmenü Migrate auf ein oder mehreren VMs geöffnet.
Alternativ ist auch ein Drag & Drop möglich, allerdings müssen Sie dazu in die Datastore-Ansicht des vSphere-Clients wechseln und die virtuelle Maschine per Drag & Drop von dem aktuellen auf den Ziel-Datastore verschieben. In diesem Fall startet der Wizard bereits mit allen Angaben durch, und Sie müssen nur noch die Ziele des Home-Verzeichnisses und der virtuellen Festplatten angeben.
Abbildung 3.23
Storage VMotion per Drag & Drop im vSphere-Client
Der Wizard im vSphere-Client erlaubt: 왘
das Verschieben von Festplattendateien, ohne das VM-Home-Verzeichnis zu verschieben
왘
die Auswahl unterschiedlicher Datastores für die unterschiedlichen Komponenten (Home-Verzeichnis, einzelne Festplatten)
왘
die Konvertierung des Festplattenformats (Thin/Thick)
왘
das Kopieren von RDM-(Raw Device Mapping-)Festplatten zu virtuellen Festplatten (VMDK) im Thin- oder Thick-Format
112
Storage VMotion
Abbildung 3.24
Change Datastore ist gleichbedeutend mit Storage VMotion.
Der einfachste Storage-VMotion-Vorgang besteht im Verschieben der kompletten virtuellen Maschine. In diesem Fall muss nur der Ziel-Datastore angegeben werden, und es wird direkt angezeigt, ob eine Migration möglich wäre.
Abbildung 3.25
Auswahl des Ziel-Datastores bei Storage VMotion
Wählen Sie den Schalter Advanced, so schaltet die Ansicht direkt um, und Sie können unterschiedliche Datastores für das Home-Verzeichnis und die virtuellen Festplatten auswählen. Auch hier findet direkt eine Prüfung statt, ob die ZielDatastores kompatibel mit dem Storage-VMotion-Vorgang sind.
Abbildung 3.26
Advanced-Auswahl der Ziel-Datastores
113
3.2
3
VMotion und Storage VMotion
Sobald die Ziele bestimmt sind, fragt der Wizard nach dem Typ der virtuellen Festplatte, und es stehen drei Möglichkeiten zur Auswahl: Same, Thin und Thick. Same Format as source ist einfach erklärt und bedeutet keine Änderung am Festplattentyp gegenüber dem derzeitigen Format der virtuellen Festplatten der zu migrierenden VM. Ist das Festplattenformat z. B. Thin, dann bleibt es Thin. Thin Provisioned Format bedeutet, dass die Festplatte ins Thin-Format konvertiert wird, falls sie derzeit im Thick-Format vorliegt. Ansonsten würde keine Anpassung erfolgen. Das Thin-Format ist sehr plattenplatzeffizient, da nur wirklich geschriebene Daten Plattenplatz auf dem Datastore belegen. Existiert eine 20-GB-Festplatte mit 5 GB Belegung, dann schlagen auch nur 5 GB auf dem Datastore zu Buche. Thick Format bedeutet, dass die Festplatte ins Thick-Format (eagerzeroedthick) konvertiert wird. Dabei ist zu bedenken, dass eine normale Anlage einer virtuellen Festplatte mit dem Wizard das zeroedthick-Format verwendet, daher findet meist eine Konvertierung von zeroedthick in eagerzeroedthick statt, was unter Umständen viel Zeit in Anspruch nimmt, da die Festplatte komplett mit Nullen überschrieben wird. Das Thick-Format ist performanter als das Thin-Format, allerdings wird die komplette Plattengröße im Datastore belegt, unabhängig von den wirklich geschriebenen Daten. Existiert eine 20-GB-Festplatte mit 5 GB Belegung, schlagen trotzdem 20 GB zu Buche.
Abbildung 3.27
Storage-VMotion-Task in der Tasks-Ansicht der virtuellen Maschine
Zum Abschluss folgt eine Zusammenfassung des Vorgangs, und nach dessen Bestätigung beginnt die Übertragung der Daten mittels Storage VMotion, was in den Tasks & Events des Host-Systems und der virtuellen Maschine einsehbar ist.
3.2.4
Problemfälle
Es sind derzeit wenige Problemfälle mit Storage VMotion bekannt, und die meisten rühren eher aus der Infrastruktur als aus der Software. So werden natürlich
114
Storage VMotion
leistungsfähige Storage-Systeme und -Anbindungen benötigt, damit Storage VMotion problemlos und schnell durchgeführt werden kann. Zu hohe Latenzzeiten oder Paketverlust bis hin zum Ausfall von Infrastrukturkomponenten bergen eine gewisse Gefahr für den SVMotion-Prozess, da dieser bei sehr großen virtuellen Maschinen mehrere Stunden andauern kann. Generell sollten Sie bei Systemen mit mehr als 20 GB (GBit-basierte StorageAnbindung) bzw. 50 GB (FC-basiert) Daten die Storage-Migration eher in die Zeiten nach Büroschluss verschieben. Große Raw-Device-Mappings Ein sehr gerne übersehenes Problem ist die automatische Migration von RDMs in vmdk -Dateien. Man muss nicht lange nach einem Beispiel suchen – nehmen wir einfach einen File-Server mit einer 1-TB-LUN, die über RDM angebunden ist. Wird diese auf einen Datastore per Storage VMotion verschoben, findet keine Prüfung statt, ob genügend Platz auf dem Datastore verfügbar ist; irgendwann ist der Datastore voll, da die wenigsten ein TB Zusatzkapazität haben. Daher sollten Sie immer vorher kontrollieren, ob ein RDM angeschlossen ist und ob genügend Datastore-Kapazität zur Verfügung steht. Ansonsten besteht natürlich die Möglichkeit, nur die RDM-Mapping-Datei zu kopieren und nicht die Datastores selbst (Same Format as source auswählen). Snapshots Achten Sie darauf, dass niemals Snapshots während des Storage-VMotion-Prozesses für die betroffene virtuelle Maschine angelegt werden. Besonders Aktionen, die direkt auf dem ESX-Server und nicht über das vCenter ausgeführt werden, sind gefährlich und führen im schlimmsten Fall zum Datenverlust. Achten Sie daher auf manuelle Snapshots, Snapshots durch VMware Consolidated Backup oder andere Backupskripte oder -programme. Informationen zu Problemen mit Snapshots und Storage VMotion finden Sie auch in der VMware Knowledgebase http://kb.vmware.com/kb/1003114. Storage-VMotion-Timeout Bei virtuellen Maschinen mit mehreren Festplatten können beim Storage-VMotion-Vorgang Abbrüche vorkommen, entweder bei 5, 10, 90 oder 95 %.
115
3.2
3
VMotion und Storage VMotion
In den Protokolldateien des vCenters sind folgende Einträge zu finden: [2008-07-17 12:29:57.283 02828 error 'App'] [MIGRATE] (1216409209437375) VMotion failed: vmodl.fault.SystemError [2008-07-17 12:29:57.454 02828 verbose 'App'] [VpxVmomi] Throw vmodl.fault.SystemError with: (vmodl.fault.SystemError) { dynamicType = , reason = "Source detected that destination failed to resume.", msg = "A general system error occurred: Source detected that destination failed to resume."
Eine mögliche Lösung ist die Reduzierung gleichzeitiger Migrationsprozesse (Migration, Clonen, VM-Erstellung), eine weitere die Erhöhung der Übertragungs-Timeouts. Dies können Sie in den Eigenschaften (Options 폷 Advanced; Abbildung 3.28) der virtuellen Maschinen oder direkt in der Konfigurationsdatei anpassen. Dazu müssen Sie den Eintrag fsr.maxSwitchoverSeconds hinzufügen. Der Standardwert ist 100, daher sollten Sie den Wert entsprechend erhöhen.
Abbildung 3.28
Erweiterte Konfiguration in den Eigenschaften einer VM
Den zugehörigen Knowledge-Base-Eintrag finden Sie hier: http://kb.vmware .com/kb/1010045
116
Storage VMotion
Zu viele Migrationsprozesse vSphere limitiert die gleichzeitigen Datastore-Zugriffe und damit auch die Aktionen, die zur gleichen Zeit erlaubt sind. vSphere unterstützt maximal acht gleichzeitige VMotion-, Cloning-, Deploy- oder Storage-VMotion-Prozesse auf einem einzelnen VMFS-3-Datastore. Für NFSoder VMFS-2-Datastores gilt ein Maximum von vier gleichzeitigen VMotion-, Cloning-, Deploy- oder Storage-VMotion-Prozessen. Eine einzelne Migration mit VMotion steht dabei für einen Zugriff auf den Datastore, eine Storage-VMotionMigration steht für jeweils einen Zugriff auf dem Quell- und dem Ziel-Datastore.
3.2.5
Lizenzierung
Storage VMotion ist ab der Enterprise Edition und höher integriert und wird aufgrund der vSphere-Lizenzierung der Editionen pro CPU-Sockel lizenziert.
117
3.2
VMware führte bereits mit VI 3.0 die ersten Cluster zur Ausfallsicherheit (HA) und des Lastausgleichs (DRS) ein. Deren Funktionsumfang wurde mit vSphere nochmals erhöht, und die Funktion Fault-Tolerance (FT) basiert ebenfalls auf HA. Dieses Kapitel geht bei der Einrichtung und Konfiguration der Cluster ins Detail.
4
Cluster Autor dieses Kapitels ist Dennis Zimmer, icomasoft AG, [email protected]
VMware versteht unter »Cluster« in erster Linie eine Gruppe von zusammengehörenden Servern, die für Funktionen wie Ausfallsicherheit oder Lastenausgleich füreinander einstehen. Die Funktionen sind rudimentär und nicht mit Applikations-Clustern oder Clustern im Mid-Range- oder High-End-Bereich vergleichbar, aber trotzdem äußerst wirkungsvoll und dadurch auch sehr beliebt bei Kunden. Man kann das Cluster-Objekt grob in EVC-, HA- und DRS-Cluster aufteilen. Da Fault-Tolerance ebenfalls einen HA-Cluster als Basis verwendet, wird in diesem Kapitel auch FT behandelt.
4.1
Cluster-Objekt
Sie müssen nicht zwingend HA und DRS nutzen, sondern können ein ClusterObjekt einfach als organisatorischen Container für ESX-Hosts und virtuelle Maschinen verwenden. Außerdem können Sie den Cluster natürlich per Berechtigung gesondert schützen. Unabhängig von HA oder DRS kann ein ESX-Host zwar aktiv in einen Cluster verschoben werden, muss allerdings zum Entfernen aus dem Cluster in den Maintenance-Modus gesetzt werden.
4.1.1
Anlage des Clusters
Um einen Cluster zu erstellen, treffen Sie einfach im Kontextmenü des Datacenter-Objekts die Auswahl New Cluster.
119
4
Cluster
Abbildung 4.1
Anlage eines neuen Clusters
Nach Angabe des Cluster-Namens und gegebenenfalls der gewünschten Features ist der Cluster erstellt, und Sie können per Drag & Drop ESX-Hosts in den Cluster ziehen. Wählen Sie keine Features aus, so ist die Integration in den Cluster nur aus vCenter-Sicht eine Änderung, es werden keine Komponenten auf dem ESXHost installiert.
Abbildung 4.2
4.1.2
Name und Funktionsumfang des Clusters
EVC-(Enhanced VMotion Compatibility-)Mode
Eine Funktion, die nur im Cluster nutzbar ist, nennt sich EVC, was ausgeschrieben »Enhanced VMotion Compatibility Mode« heißt. Die Bezeichnung deutet es bereits an: Es können ESX-Server mit unterschiedlichen CPU-Generationen in
120
Cluster-Objekt
diesen Cluster integriert werden, und VMotion ist trotzdem möglich. Dies ist vergleichbar mit der Advanced-CPU-Funktion jeder virtuellen Maschine, CPU-Funktionen zu verstecken.
Abbildung 4.3
CPUID-Masking in den Eigenschaften einer VM
Allerdings bietet EVC im Cluster den klaren Vorteil, dass diese Einstellung nicht pro VM getroffen werden muss, sondern cluster-weit gilt, und dass jede VM automatisch konfiguriert wird. Dies bedeutet aber auch, dass VMs abgeschaltet sein müssen, bevor sie den EVCCluster betreten dürfen, und damit betrifft dies natürlich auch die ESX-Hosts, die Sie integrieren möchten.
121
4.1
4
Cluster
Abbildung 4.4
Ändern der EVC-Einstellungen eines bestehenden Clusters
Um die Funktion VMware EVC zu nutzen, können Sie dies entweder direkt bei der Anlage des Clusters angeben oder zu jedem Zeitpunkt nachträglich ändern. Aber auch hier gilt: Die VMs müssen abgeschaltet sein! Auch EVC kann keine Wunder bewirken, und es müssen zumindest gleiche CPUHersteller und ähnliche CPU-Familien in den ESX-Hosts eingebaut sein, damit ein gemeinsamer Nenner gefunden wird und die VMs entsprechend konfiguriert werden können.
Abbildung 4.5 EVC bietet die Möglichkeit, zwischen verschiedenen CPU-Generationen zu wählen.
122
HA-Cluster
Man ist geneigt zu fragen: Hat EVC nur Vorteile? Wie immer ist die klare Antwort: Nein. Werden in einem Cluster zwei Server neuester AMD-Opteron-Generation (3) mit zwei Servern ältester AMD-Opteron-Generation (1) in einem EVC-Cluster kombiniert, so werden alle VMs auf Generation 1 zurückgestuft. Sind in Generation 3 CPU-Funktionen für einzelne Applikationen ideal zum Performance-Gewinn, so sind diese Funktionen für die VM nicht mehr sichtbar. Das Gleiche gilt für virtuelle Maschinen, die auf einer aktuellen CPU gestartet und installiert wurden. Wenn die Applikation entsprechende Programmoptimierungen aufgrund der CPU-Funktionen mitinstalliert, so kann ein Wechsel in einen EVC-Cluster mit älterer CPU-Generation Nachteile in Stabilität und Leistung bringen. Wichtig ist hierbei zu bedenken, dass VMware in der Standardkonfiguration die CPU mit allen Funktionen komplett sichtbar an die virtuelle Maschine durchreicht. Es findet eine Virtualisierung und keine Emulation statt. Sobald EVC genutzt wird, sieht die virtuelle Maschine zwar immer noch die reale CPU, allerdings werden bestimmte Register, die die Prozessorgenerationen ausmachen, weggeblendet. Die VM hat also unter Umständen nicht den vollen Funktionsumfang der aktuell genutzten physikalischen CPU im Zugriff.
4.2
HA-Cluster
Ein vSphere-Cluster kann, wie bereits angekündigt, viel mehr, als nur virtuelle Maschinen zusammenzufassen und eine verbesserte VMotion-Kompatibilität herzustellen. Es ist durch Einsatz des HA möglich, virtuelle Maschinen automatisch neu zu starten, sowohl bei Ausfall des ESX-Servers als auch bei Ausfall des Gastbetriebssystems.
Abbildung 4.6
Übersicht der HA-Funktion von VMware
123
4.2
4
Cluster
4.2.1
Technologie-Übersicht
Die Grundidee hinter VMware High Availability (HA) ist, den Ausfall eines ESXServers zu überwachen und diesen zu kompensieren. Dabei unterscheidet sich der Clustering-Gedanke von VMware komplett von zum Beispiel Microsofts Cluster-Lösung oder von HPs MC/ServiceGuard für HP Unix: Deren Cluster stellt eine virtuelle Einheit basierend auf mindestens zwei physikalischen Servern dar, und Anwendungen laufen auf der virtuellen Einheit, z. B. bei Microsoft einem SQL-Server oder einem DHCP-Server. Dabei ist immer ein physikalischer Server aktiv und verwaltet die virtuelle Einheit. Hier teilt sich der aktive Server mit den passiven Servern des Clusters über eine gemeinsam genutzte Festplatten-Ressource die Informationen über den aktuellen Zustand der virtuellen Einheit und der darauf laufenden Anwendungen. Fällt bei solch einem Cluster-Verbund der aktive physikalische Server aus, so übernimmt ein passiver Server die Verwaltung der virtuellen Einheit, und die darauf laufenden Anwendungen können ohne Unterbrechung weiterlaufen. Diese Anwendungen müssen Cluster-aware sein, um diese Ausfallsicherheit mit der Cluster-Lösung zu nutzen. VMware realisiert mit HA eine andere Art des Clustering, die besser in »VMware Fast Server Recovery« umbenannt werden sollte. Diese Lösung überwacht alle im HA-Verbund befindlichen ESX-Server, und bei Ausfall eines dieser Server wird versucht, die darauf aktiven virtuellen Maschinen auf einem anderen, freien ESXServer wieder neu zu starten. In diesem Fall ist der Neustart der virtuellen Maschinen unumgänglich; ebenso ist die Grundlage hierfür die Verwendung von zentralem Storage für die Ablage der virtuellen Festplatten und der VM-Konfigurationsdateien sowie identische Virtual-Machine-Netzwerkverbindungen auf den ESX-Servern. Seit ESX 3.5 U3 kann HA auch Ausfälle innerhalb der virtuellen Maschinen überwachen. Diese Funktion wird allerdings nicht durch den AAM-Agenten auf den ESX-Hosts, sondern durch das vCenter selbst realisiert. Ein Vorteil dieser Cluster-Lösung ist, dass keine redundante Hardware vorgehalten werden muss. Alle im HA-Verbund definierten ESX-Server sind aktive Server, die eine Anzahl von VMs hosten. Der größte Nachteil dieser Lösung ist jedoch der Ausfall und Neustart aller virtueller Maschinen des ausgefallenen ESX-Servers. Durch die Strict Admission Control besteht beim Failover die Gefahr, dass VMs mangels Ressourcen auf den restlichen ESX-Servern nicht gestartet werden kön-
124
HA-Cluster
nen. Durch eine Priorisierung in den HA-Eigenschaften einer VM können zumindest die wichtigen VMs zuerst gestartet werden und die weniger wichtigen VMs zuletzt, so dass eine eventuelle Ressourcenknappheit nur unwichtige VMs betrifft. Die Berechnung der notwendigen Ressourcen wird auch durch die HAEinstellung »Allowed Host Failures« erreicht, doch dazu später mehr, wenn es um die Slot-Berechnung geht. Auch ohne VL-Server Ein HA-Cluster wird zwar über den vCenter-Server eingerichtet, bleibt aber auch ohne diesen VC-Server lauffähig, da auf jedem ESX-Server lokale HA-Agenten installiert sind, die unter anderen die komplette HA-Konfiguration vorhalten.
Es wird zwischen primären und sekundären HA-Knoten unterschieden, und ein HA-Cluster ist mit DRS kombinierbar: Beim Starten von virtuellen Maschinen wie auch im laufenden Betrieb wird immer die Auslastung der HA-Knoten im Cluster berücksichtigt, und je nach DRS-Konfiguration werden bestimmte VMs entweder automatisch auf freie ESXServer verschoben, oder dies wird nur als Empfehlung ausgesprochen, um eine ausgewogene Lastverteilung zwischen den ESX-Servern zu erreichen.
4.2.2
Voraussetzungen für HA
Die Anforderungen für HA entsprechen zum größten Teil auch denen von VMotion, allerdings ist es keine zwingende Voraussetzung, gleiche Prozessoren in den ESX-Host-Systemen zu nutzen. Dies rührt daher, dass HA die virtuellen Maschinen nicht im aktiven Zustand migriert, sondern einschaltet, nachdem diese bereits durch den Ausfall gestoppt wurden. Daher gilt: »HA setzt voraus, dass jede VM auf jedem ESX-Host neu gestartet werden kann.« Die Empfehlungen zum Betrieb von VMware HA lauten: 왘
vCenter-Integration
왘
zentraler SAN- oder NFS-Speicher, der von allen ESX-Systemen im Zugriff ist
왘
installierte und funktionstüchtige HA-Agenten auf den ESX-Hosts
왘
DNS-Namensauflösung
왘
Service-Console-Verbindung zwischen allen ESX-Hosts im Cluster
왘
gleiche Netzwerkkonfiguration für die VMs auf allen ESX-Hosts im Cluster
왘
keine Service-Console-Verbindung zwischen ESX-Hosts über Router zulässig
왘
mindestens Essentials Plus Edition
125
4.2
4
Cluster
vCenter
Service Console
App
App
App
App
App
App
OS
OS
OS
OS
OS
OS
Storage
Abbildung 4.7
Grundstruktur Anforderungen VMware HA
Tipp Möchten Sie bei virtuellen Maschinen die Erfüllung der Anforderungen testen, so können Sie dafür VMotion Migration nutzen, da deren Voraussetzungen die von HA noch übertreffen. So ist es möglich, ohne Ausfall die HA-Fähigkeit einer VM zu überprüfen.
Aufgrund der Anforderungen an zentralen Shared Storage und direkte Netzwerkverbindungen zwischen den ESX-Hosts ist es oft schwierig, einen HA-Cluster zwischen mehreren Rechenzentren aufzubauen. Hier nutzt auch eine Replikation der Daten zwischen SAN-Systemen in den Rechenzentren nichts, sondern nur ein Zugriff auf die gleichen Daten. Werden die Voraussetzungen für einen RZ-übergreifenden HA-Cluster erfüllt, sollte der Cluster über nicht mehr als acht Knoten verfügen, damit in beiden Rechenzentren ein primärer Knoten garantiert ist. Mehr dazu in Abschnitt 4.2.11, »HA-Primary- und -Secondary-Hosts«.
4.2.3
Lizenzierung von HA
VMware HA ist Bestandteil der vSphere Suite, die auf CPU-Sockel-Basis lizenziert wird und ab der Edition Essentials Plus integriert ist.
126
HA-Cluster
4.2.4
Einrichtung von HA
HA kann schlicht durch Aktivierung des Features HA (Turn on VMware HA) in den Eigenschaften eines Clusters oder bei der Neuerstellung eingerichtet werden.
Abbildung 4.8
Aktivierung des VMware-HA-Features
Danach können Sie HA auf die Bedürfnisse der Infrastruktur anpassen (siehe Abbildung 4.9).
���
���
���
Abbildung 4.9
Konfigurationsübersicht der HA-Funktionen
Enable Host Monitoring Die Option Enable Host Monitoring 1 ist sinnvoll, wenn Sie Wartungsarbeiten an ESX-Hosts innerhalb eines Clusters ausführen, die zum Verlust der HeartbeatPakete führen würden. Ein typischer Fall wäre ein Austausch oder ein FirmwareUpgrade von Ethernet-Switches. Der Schalter ist neu mit vSphere hinzugekommen und sollte vor der eigentlichen Wartung deaktiviert und nach Abschluss der Wartungsarbeiten wieder aktiviert werden.
127
4.2
4
Cluster
HA-Failover-Capacity und Admission Control Die HA-Failover-Capacity 3 (siehe Abbildung 4.9) gibt die Anzahl von ausgefallenen ESX-Servern an, die ein HA-Cluster verkraften soll. Der vCenter-Server errechnet eigenständig, wie viel Ressourcen insgesamt im Cluster verfügbar sein müssen, um den Ausfall der angegebenen Anzahl von ESX-Servern abzufangen. Als Grundlage hierfür dient der ESX-Server mit der stärksten Auslastung, wobei dieser Umstand eine sehr konservative Berechnung ergibt. Optimal wäre hier die Kombination von HA mit DRS, so dass alle ESX-Server im Cluster-Verbund mit einer ausgewogenen Lastverteilung aktiv sind. Der HA-Cluster überwacht dann die Gesamtmenge von startbaren virtuellen Maschinen, um die errechnete Kapazität nicht zu unterschreiten. Diese Funktion wird Admission Control genannt. Das Admission Control 2 (siehe Abbildung 4.9) überwacht die aktuelle Auslastung aller ESX-Server im HA-Cluster und stellt sicher, dass nicht so viele Ressourcen verbraucht werden, dass die HA-Failover-Capacity gefährdet ist. Das Sicherstellen der verfügbaren Ressourcen erfolgt mit der möglichen Sperre folgender Operationen: 왘
Start von virtuellen Maschinen
왘
Migration einer aktiven virtuellen Maschine in einen HA-Cluster
왘
zu einem Snapshot einer ausgeschalteten virtuellen Maschine zurückrollen und diesen aktivieren
왘
Erhöhen von CPU- oder Memory-Resource-Settings einer virtuellen Maschine
Diese Überwachung verringert die Flexibilität der ESX-Server im HA-Cluster und kann mit der Deaktivierung der Admission Controls ausgeschaltet werden. Dadurch können mehr virtuelle Maschinen gestartet werden, als die Admission Control erlauben würde. Dabei signalisiert der vCenter-Client einen HA-Cluster mit niedriger FailoverKapazität nicht mit einem roten Symbol, und virtuelle Maschinen können nach Belieben gestartet werden. Die Folge dieser Aufhebung ist eine reduzierte Kapazität, um die konfigurierte Anzahl von ESX-Server-Ausfällen abzufangen. Werden jetzt bei einem Ausfall die virtuellen Maschinen auf den übrigen ESXServern neu gestartet, entscheidet die HA Restart Priority einer VM, wann diese gestartet wird, um somit die letzten freien Ressourcen des HA-Clusters in Beschlag zu nehmen. VMs mit einer niedrigen Priorität laufen Gefahr, mangels Ressourcen nicht mehr gestartet werden zu können. Dieses Standardverfahren der Admission Control können Sie jedoch in einem eingegrenzten Rahmen konfigurieren. So besteht auch die Möglichkeit, die Ressourcensperre der Admission Control komplett aufzuheben und auch bei erschöpften Ressourcen die VMs immer noch zu starten.
128
HA-Cluster
Abbildung 4.10
Deaktivierung der Ressourcenkontrolle der Admission Control
Die Auswahl treffen Sie mit dem Schalter Allow VMs to be powered on even if they violate availability constraints. In diesem Fall ist es auch nicht mehr möglich, die Admission Control Policy detaillierter zu konfigurieren, und der Bereich wird grau unterlegt.
Abbildung 4.11
Admission Control Policy zur Detaileinstellung der HA-Regeln
Belassen Sie die Admission Control bei Prevent VMs from being powered on if they violate availability constraints, so können Sie die zu nutzenden Regeln weiter konfigurieren, siehe Tabelle 4.1 Option
Beschreibung
Host failures cluster tolerates
Die Anzahl der Hosts, die ausfallen dürfen, bevor der Cluster nicht mehr aktiviert wird. Die Admission Control nimmt dies als Berechnungsgrundlage, um das Starten weiterer Systeme zu prüfen.
Percentage of cluster resources reserved as failover spare capacity
Prozentzahl der Ressourcen, die bei der Laufzeit aller Systeme noch ungenutzt bleiben muss, um Ausfälle abfangen zu können.
Specify a failover host
Angabe des ESX-Hosts, der bei Ausfall eines anderen ESX-Hosts die VMs übernimmt.
Tabelle 4.1
Admission Control Policy-Optionen
Zuletzt ist es auch möglich, die Advanced Options direkt zu beeinflussen.
129
4.2
4
Cluster
4.2.5
HA Advanced Options
Es existiert eine Vielzahl von erweiterten Optionen für den Einsatz des HA-Clusters, um diesen auf die vielfältigen Gegebenheiten der Kunden und der Infrastruktur einzustellen.
Abbildung 4.12
Advanced Options-Einstellungen in den Cluster-Eigenschaften
Die Einstellung der Advanced Options wird in den Eigenschaften des ClusterObjektes durchgeführt. Eine sehr gute Übersicht zu den HA Advanced Options hat Duncan Epping von yellow-bricks.com veröffentlicht; sie ist unter folgendem Link zu finden: http:// www.yellow-bricks.com/ha-advanced-options/ Option
Beschreibung
das.failuredetectiontime
Anzahl Millisekunden des Timeouts für die Isolation Response (Standard 15 000 Millisekunden). Bei Anpassung der das.isolationaddress um weitere Systeme sollte dieser Wert um 5 Sekunden auf 20 000 erhöht werden.
das.isolationaddress[x]
IP-Adressen der Service Console des ESX-Hosts, die für Heartbeat-Tests genutzt werden soll; [x] = 1Ȃ10. Im Standard wird nur das DefaultGateway genutzt.
das.usedefaultisolationaddress
Wert kann true oder false annehmen und gibt an, ob das Default-Gateway als HeartbeatAdresse genutzt werden soll.
Tabelle 4.2
130
Advanced Options für VMware HA
HA-Cluster
Option
Beschreibung
das.poweroffonisolation
Wert kann true oder false annehmen und gibt an, ob die VMs als Isolation Response abgeschaltet werden sollen.
das.vmMemoryMinMB
Hauptspeichermenge für die Slot-Berechnung – Admission Control
das.vmCpuMinMHz
CPU-MHz für die Slot-Berechnung – Admission Control
das.defaultfailoverhost
Angabe, welcher Host im Cluster primärer Failover-Host sein soll. Dies ist interessant bei der Nutzung eines Standby-ESX-Servers.
das.allowNetwork[x]
Dedizierte Eintragung, welche Netzwerke als Heartbeat-Netzwerke verwendet werden dürfen; [x] = 1Ȃ10. Als Wert muss der wirklich genutzte Portname angegeben werden, z. B. Service Console 2.
das.isolationShutdownTimeout
Beim Herunterfahren des Gast-OS ist der Standard-Timeout 300 Sekunden, danach wird der Gast einfach abgeschaltet.
das.bypassNetCompatCheck
Deaktivierung der Netzwerkkompatibilitätsprüfungen von HA, z. B. Prüfung auf gleiche Netzwerkadressen. Standard ist False.
das.ignoreRedundantNetWarning
Entfernen der Warnung, falls keine redundanten Service-Console-Ports existieren. Standardwert ist False, und True verhindert die Warnung.
das.maxvmrestartcount
Anzahl der Versuche, eine ausgefallene VM zu starten. Standardwert ist 5, 0 steht für keine Neustarts und –1 für unendlich viele Neustartversuche.
Tabelle 4.2
Advanced Options für VMware HA (Forts.)
Die drei wichtigsten Advanced Options des HA-Clusters sind das.isolationaddress, das.allowNetwork und das.ignoreRedundantNetWarning. das.isolationaddress Ein Beispiel zur Nutzung dieser Option ist sehr einfach gefunden, da es aus Sicherheitsgründen oft sinnvoll ist, neben dem Default-Gateway weitere Systeme als Heartbeat-Ziel zu nutzen, um eine Isolation auszuschließen. Dies geschieht über einen einfachen Ping.
131
4.2
4
Cluster
Abbildung 4.13
HSRP-ausfallsichere Konfiguration der beiden physikalischen Router
Soll neben dem Default-Gateway, der z. B. ein HSRP (Cisco Hot Standby Router Protocol – eine dynamische Adresse zeigt auf zwei Router) geschützter Router sein könnte, auch auf die beiden physikalischen Adressen der Router und des vCenter-Servers (192.168.199.22) gepingt werden, so sähen die Advanced Options wie folgt aus: das.isolationaddress[1] das.isolationaddress[2] das.isolationaddress[3]
= = =
192.168.199.2 192.168.199.3 192.168.199.22
das.allowNetwork Wann sollte man ein Heartbeat-Netzwerk definieren? Immer dann, wenn die Netze untereinander nicht direkt verbunden sind, sondern z. B. ein Router dazwischen eingesetzt werden muss. Dies kann bei physikalischer Trennung oder bei Nutzung unterschiedlicher IP-Adressen sinnvoll sein. In unserem Beispiel ist es daher notwendig, das SC2-Netzwerk auszuklammern und nur das SC1-Netzwerk zu nutzen. das.allowNetwork[1] = "SC1"
Zusätzlich entsteht das Problem, dass ESX2 keine Redundanz mehr besitzt. Daher wäre auch die Einstellung das.ignoreRedundantNetWarning interessant, zu der wir folgend kommen. Idealer wäre natürlich die Nutzung einer weiteren Netzwerkkarte.
132
HA-Cluster
Abbildung 4.14
HA-Heartbeat-Pakete können nicht über Router weitergeleitet werden.
das.ignoreRedundantNetWarning Zu das.ignoreRedundantNetWarning müssen wir kein ausführliches Beispiel beschreiben. Haben Sie ein Testsystem konfiguriert und verfügen Sie dort nicht über genügend Netzwerkadapter, so werden Sie zwangsweise über Meldung betreffend mangelnder Redundanz stolpern. Sind Sie davon genervt, ändern Sie das.ignoreRedundantNetWarning einfach auf True.
4.2.6
Virtual Machine Options
Da VMware HA in erster Linie die VMs schützen soll und nicht die Host-Systeme, können Sie Regeln für einzelne virtuelle Maschinen aufstellen und auch das allgemeine Verhalten beim Neustart der VMs und sowie das Verhalten bei erkannter Isolation konfigurieren.
Abbildung 4.15 Mittels der Virtual Machine Options können Sie unter anderem die Host Isolation response konfigurieren.
133
4.2
4
Cluster
Schauen Sie sich die Cluster Default Settings, also die Standardeinstellungen für alle virtuellen Maschinen innerhalb des Clusters, an, so stellen Sie fest, dass die Priorität des Neustarts global gesetzt werden kann. Eine Anpassung des Standards Medium ist allerdings nur sinnvoll, wenn Sie einzelnen virtuellen Maschinen andere Werte zuweisen möchten, z. B. High. Ansonsten spielt diese Einstellung keine Rolle, da ja jede VM die gleiche Priorität hat, unabhängig von High, Medium oder Low.
Abbildung 4.16
VM Restart Priority
Die Host Isolation Response ist mit die wichtigste Einstellung des HA-Clusters, da sie die Reaktion des isolierten ESX-Hosts bestimmt. Ist dieser wirklich ausgefallen, sind sowieso alle virtuellen Maschinen offline, und die restlichen ClusterMitglieder können die VMs neu starten. Ein Problem tritt auf, wenn der Host samt virtuellen Maschinen noch läuft, aber das Heartbeat-Netzwerk der Service Console aussetzt.
Abbildung 4.17
Host Isolation response
Hier müssen Sie sich Gedanken machen, ob die virtuellen Maschinen dann wirklich automatisch vom ESX-Host gestoppt werden sollen (und wenn, in welcher Form) oder ob sie weiterhin aktiv bleiben sollen. Entscheiden Sie sich für eine Abschaltung, bedeutet Power off das harte Abschalten der VM, während Shut down die virtuelle Maschine über die VMware Tools aus dem Gast heraus herunterfährt. Die Entscheidung fällt leicht, wenn die physikalischen Switches, auf denen die Service Console liegt, unabhängig von den physikalischen Switches der virtuellen Maschinen betrieben werden. In diesem Fall kann es zu einer Störung des Management-Netzwerks kommen, während die VMs aber normal weiterlaufen. Daher sollten Sie die Host Isolation Response auf Leave powered on einstellen. Hinweis Alle übrigen ESX-Hosts, die den isolierten Host als ausgefallen erkennen, können ihrerseits die VMs nicht neu starten, da die Festplattendateien der virtuellen Maschinen während der Laufzeit gesperrt sind.
134
HA-Cluster
Abbildung 4.18
Einstellungen pro virtueller Maschine
Die Einstellungen zur Restart-Priorität und zur Isolation Response können Sie auch für jede einzelne VM getrennt unter Virtual Machine Settings einrichten, wenn diese Anforderung besteht. Hier ist es beispielsweise sinnvoll, die wichtigsten VMs mit einer hohen Priorität zu versehen, während alle anderen VMs im Standard auf Normal bleiben.
4.2.7
Der HA-Agent oder »Was passiert beim Hinzufügen eines ESX-Hosts zum HA-Cluster?«
VMware HA stammt ursprünglich von Legato und wurde »Automated Availability Manager« genannt. Der HA-Agent setzt sich daher zusammen aus dem AAM (Automated Availability Manager) und dem VMap. Beim Hinzufügen eines ESXServers zum HA-Cluster werden diese HA-Komponenten in die Service Console des neuen HA-Knotens installiert und geladen und vom vCenter-Agent Vpxa mit den notwendigen Informationen über die VMs und über die HA-Konfiguration versorgt.
Abbildung 4.19
Im Event-Log können Sie den HA-Konfigurationsvorgang einsehen.
135
4.2
4
Cluster
Der AAM ist zuständig für den Neustart der virtuellen Maschinen, und VMAP kümmert sich um die Kommunikation zwischen dem AAM und dem VC-Agenten Vpxa.
Abbildung 4.20
HA-Cluster-Prozesse pro ESX-Server
Die HA-Agenten überwachen sich im Verbund gegenseitig durch einen HAHeartbeat über das Netzwerk-Interface der Service Console. Dabei basiert die Kommunikation auf einer zuverlässigen Namensauflösung; weitere Informationen hierzu finden Sie in Abschnitt 4.2.16, »HA und DNS«. Die Datenbank mit den vCenter-Informationen hält der Agent im RAM vor. Der Installationspfad der HA-Komponenten ist /opt/vmware/aam.
Abbildung 4.21
Firewall-Einträge für den HA-Agenten
Außerdem wird in der Firewall des ESX-Hosts der Automated Availability Manager erlaubt, der u. a. für die Heartbeat-Kommunikation zuständig ist. Nicht unter ESXi Diese Firewall-Regel ist übrigens nicht unter ESXi zu finden, da der AAM Manager dort bereits fest integriert ist und nicht wie bei ESX nachträglich als Softwareagent installiert werden muss.
136
HA-Cluster
4.2.8
Reconfigure for VMware HA
Der laufende AAM-Prozess von VMware HA auf dem ESX-Host wird durch einen Watchdog-Prozess überwacht, der den AAM-Prozess bei Ausfall automatisch neu startet. Dies hilft bei versehentlichem Stoppen des AAM oder bei kleineren Problemen. Sollte ein Konfigurationsfehler vorliegen, schafft oft ein Reconfigure for HA im Kontextmenü des ESX-Hosts Abhilfe. Dieser Aufruf rekonfiguriert den HA-Agenten komplett und startet ihn neu.
Abbildung 4.22 Reconfigure for VMware HA kann bei Konfigurationsproblemen des Clusters Wunder bewirken.
4.2.9
Das Verhalten eines HA-Clusters
Die HA-Cluster-Agenten auf den HA-Knoten überwachen die Verfügbarkeit der ESX-Server und starten die virtuellen Maschinen des ausgefallenen HA-Knotens auf den verbleibenden ESX-Servern mit genügend freier Kapazität neu. Allerdings existiert eine Aufteilung zwischen Primary- und Secondary-Knoten. Nur die Primary-Knoten sind in der Lage, den Neustart der VMs zu steuern. Sind keine Primary-Knoten im Netz vorhanden (z. B. RZ-Ausfall), so ist HA nicht betriebsbereit. VMware HA nutzt maximal fünf Primary-Knoten, die auf die ersten ESX-Server, die in den HA-Cluster aufgenommen werden, verteilt werden. Im Nachhinein existiert kein unterstützter Weg, diese Primary-Knoten nochmals neu zu verteilen, außer durch Auflösung und Neukonfiguration des HA-Clusters. Die Heartbeat-Pakete, die zur Funktionsüberprüfung der einzelnen Systeme genutzt werden, werden sekündlich über alle Service-Console-Verbindungen verschickt. Wichtig hierbei ist, dass die Heartbeat-Pakete auch auf allen ServiceConsole-Ports erwartet werden, sofern nichts anderes konfiguriert wurde.
137
4.2
4
Cluster
Router und Gateways Die Heartbeat-Pakete sind nicht in der Lage, Router und Gateways zu passieren, daher müssen alle Service-Console-Ports aller ESX-Hosts innerhalb eines Clusters kommunizieren können, ohne einen Router nutzen zu müssen. Existiert ein Netzwerk, das über einen Router mit den anderen ESX-Hosts verbunden ist, müssen Sie dieses Netz über die Advanced Options ausklammern.
Service Console 1
Service Console 2
Abbildung 4.23 Heartbeat-Pakete werden sowohl über Service Console 1 als auch über Service Console 2 verschickt und erwartet!
Ist die aktuelle Failover-Kapazität des HA-Clusters unter dessen konfigurierte Failover-Kapazität gefallen, zeigt sich das Cluster-Symbol im vCenter-Client bei aktiver Admission Control rot. Das rote Symbol kann zum einen durch Ausfall zu vieler ESX-Server bedingt sein oder zum anderen durch zu hohe Belegung der ESX-Server mit virtuellen Maschinen. Haben Sie bei den virtuellen Maschinen keine HA-Restart-Priorisierung vergeben, werden die ausgefallenen virtuellen Maschinen nacheinander auf den verbleibenden ESX-Servern gestartet, bis die Kapazität der ESX-Server erschöpft ist. Dies kann zur Folge haben, dass wichtige VMs nicht mehr gestartet werden können. Das Vergeben einer HA-Priorität hilft, diese Problematik etwas zu entschärfen, indem ein ESX-Administrator den wichtigeren VMs eine höhere Priorität verleiht, damit diese frühestmöglich gestartet werden, um die freien Ressourcen garantiert zu erhalten. Virtuelle Maschinen mit einer niedrigeren Priorität fallen dann gegebenenfalls der Ressourcenknappheit zum Opfer. Ein Sonderfall stellt der Ausfall eines ESX-Servers während einer VMotion-Operation dar: Fällt der ursprüngliche ESX-Server aus, so versucht HA, die betref-
138
HA-Cluster
fende virtuelle Maschine auf dem vom Administrator vorgesehenen Ziel-Server der VMotion-Operation zu starten. Fällt hingegen der Ziel-Server aus, wird HA versuchen, diese VM auf dem ursprünglichen ESX-Server wieder zu starten. Fallen im Extremfall beide an der VMotion-Operation beteiligten ESX-Server aus, wird HA versuchen, einen dritten ESX-Server mit ausreichend verfügbarer Kapazität zu finden, um die betroffene virtuelle Maschine darauf erneut zu starten. Bei einem HA-Failover werden die virtuellen Maschinen mit der höchsten Priorität zuerst gestartet. Dabei wählt HA, je nach Version des vCenter-Servers, über zwei verschiedene Wege die ESX-Server aus, auf denen die VMs neu gestartet werden: Die Version 2.0 des vCenter-Servers bedient sich der ESX-Hosts anhand der alphabetischen Auflistung der ESX-Knoten mit ausreichenden Ressourcen; ab der Version 2.1 wird der ESX-Knoten mit den meisten nicht reservierten Ressourcen als erster herangezogen.
4.2.10 HA-Slot-Berechnung Nahezu 100 % aller VMware-Kunden, die auf Memory-Reservierungen in virtuellen Maschinen setzen und diese VMs innerhalb eines HA-Clusters betreiben, schalten unbewusst die Cluster-Übernahme ab (Current Failover Capacity = 0). Hintergrund ist die doch etwas eigensinnige Interpretation der Slot-Berechnung, die VMware HA vornimmt. Ein Standard-Slot bewegt sich in folgenden Grenzen: 256 MHz, 256 MB oder maximale Arbeitsspeicherreservierung einer VM im Cluster + Overhead. Dies führte bereits bei vielen Kunden zu Verständnisproblemen und Verstimmung, wenn die Current Failover Capacity automatisch auf 0 ging, obwohl nur eine virtuelle Maschine über eine CPU oder Memory-Reservierung verfügt. Kann der Cluster beispielsweise insgesamt 128 GB RAM bereitstellen, so kann bei einer Gesamtanzahl von 40 VMs bereits eine VM mit 4-GB-RAM-Reservierung die Current Failover Capacity auf 0 herunterbringen. Hier würde man sich wünschen, dass stets mit dem Standard-Slot von 256 MB gerechnet wird und die reservierten Memory-Mengen einfach einzeln summiert würden. Glücklicherweise ist der Cluster immer noch betriebsbereit, auch wenn die Current Failover Capacity auf 0 steht.
Abbildung 4.24
Ressourcenwarnung aufgrund einer Verletzung der HA Admission Control
139
4.2
4
Cluster
Trotzdem ist ab diesem Zeitpunkt ein gewisses Unbehagen beim Administrator vorhanden, und mögliche Fehler oder Probleme werden vielleicht übersehen, da die Admission Control aufgrund dieser seltsamen Berechnung zumeist abgeschaltet wird. Bleibt die Admission Control aktiv, so erhalten Sie direkt beim Starten einer VM eine Fehlermeldung, und der Start wird verhindert. Die aktuellen Slot-Größen lassen sich unter dem Menüpunkt HA Advanced Runtime Info im Summary des Clusters einsehen.
Abbildung 4.25
4.2.11
Advanced Runtime Info eines HA-Clusters
HA-Primary- und -Secondary-Hosts
Ein HA-Cluster funktioniert ohne die Überwachung durch einen vCenter-Server, da auf jedem ESX-Server ein eigenständiger HA-Agent läuft, der die komplette Konfiguration des HA-Cluster sowie sämtliche Informationen über die virtuellen Maschinen und deren aktuellen Zustand hält. Da eben diese zentrale Instanz durch zum Beispiel einen vCenter-Server fehlt, müssen die HA-Agenten untereinander selbst mit Ausfällen und Neustart-Aktivitäten zurechtkommen. Aus diesem Grund gibt es die Unterscheidung zwischen primären und sekundären ESX-Servern im HA-Cluster: Die primären Knoten agieren als Interpreter für die definierten HA-Regeln und Master der verteilten Datenbank. Sie sorgen für die Redundanz der ESX-Server (Konfiguration) untereinander, koordinieren die Neustarts der virtuellen Maschinen bei Ausfall eines HA-Knotens und werten dabei die festgelegten Regeln aus. In einem HA-Cluster können maximal fünf primäre HA-Knoten vorhanden sein, in der Regel liegt die Anzahl zwischen zwei und fünf Knoten. Hält man die Regel mit fünf Primary-Knoten im Hinterkopf, so ergibt sich eine Maximalgröße des HA-Clusters von acht Hosts. Die Überlegung kommt daher,
140
HA-Cluster
dass man versucht, die Knoten eines HA-Clusters auf unterschiedliche BladeCenter, Rechenzentren oder Brandschutzzonen zu verteilen. Geht man von einer 4:4Verteilung aus, so ist bei acht Hosts immer sichergestellt, dass mindestens ein Primary in jeder Location ist. Hätte man einen 10-Knoten-Cluster mit 5:5-Zuordnung, so könnte es durchaus passieren, dass alle fünf Primaries an einem Standort sind, was nicht optimal wäre. Hinweis Die sekundären Knoten senden ihre Heartbeat-Pakete nur an die primären Knoten!
Bei der Erstellung eines HA-Clusters sind die ersten fünf ESX-Hosts automatisch primäre Knoten, die nächsten ESX-Hosts automatisch sekundäre Knoten. Die primären Knoten verteilen die Cluster-Informationen an die sekundären Knoten. Wenn ein primärer Knoten in den Maintenance-Modus versetzt, aus dem HACluster entfernt oder getrennt (Disconnect) wurde, sorgt HA für die Ernennung eines anderen primären Servers an seiner statt. Bei Ausfall Fällt ein primärer Knoten aus, wird er nicht durch einen sekundären ersetzt (Promoting eines Secondarys)! Fallen alle primären Knoten aus, führt HA keinen Neustart der Systeme durch, das heißt, HA ist de facto abgeschaltet. Sie können jederzeit die Liste der Primary- und Secondary-Knoten auf der Service Console des ESX-Hosts auslesen: /var/log/vmware/aam/aam_config_util_listnodes.log
Abbildung 4.26
Ausgabe der Protokolldatei »aam_config_util_listnodes.log«
Alternativ prüfen Sie dies über die Kommandozeile: /opt/vmware/aam/bin/Cli AAM> ln
141
4.2
4
Cluster
Abbildung 4.27
AAM-Kommandozeile zum Auslesen der HA-Cluster-Knoten
Es existiert ein nicht vom Hersteller unterstützter Weg, die primären Knoten nachträglich anzupassen. Heraufstufen eines sekundären Knotens zum Primary: /opt/vmware/aam/bin/Cli AAM> promotenode <ESX Host>
Herabstufen eines primären Knotens zum Secondary: /opt/vmware/aam/bin/Cli AAM> demotenode <ESX Host>
4.2.12 HA Host Isolation Wie bereits erwähnt, werden die Heartbeat-Pakete im Standard sekündlich verschickt und auch erwartet. Verliert die Service Console eines aktiven ESX-Knotens im HA-Cluster die Netzwerkverbindung, ohne aber komplett auszufallen, nennt man diesen ESX-Server isoliert, und alle anderen ESX-Server im HA-Cluster würden – den Regeln von HA folgend – dessen virtuelle Maschinen verteilt auf den übrigen Servern neu starten. Da der ESX-Server aber nur die Netzwerkverbindung verloren hat, die notwendigen Prozesse der virtuellen Maschinen jedoch weiterhin laufen, sind auch diese noch aktiv und können nicht auf anderen ESX-Servern neu gestartet werden – die vmdk-Dateien auf dem vmfs-Volume sind gelockt, und ein versuchter Neustart dieser VMs würde auf einem anderen ESX-Server mit einer Fehlermeldung quittiert. Dieser isolierte ESX-Server mit seinen noch laufenden virtuellen Maschinen muss gesondert behandelt werden, um die virtuellen Maschinen auf einem fehlerfrei laufenden ESX-Server zu verschieben (hier ist nicht die Migration via
142
HA-Cluster
VMotion gemeint), und bedient sich eines speziellen Timers, dem »Host Isolation Timing«. Die Standardeinstellung von »HA Host Isolation« ist, dass die virtuellen Maschinen des ESX-Servers heruntergefahren werden, damit sie vom HA auf anderen ESX-Servern neu gestartet werden können. Das Host Isolation Timing basiert auf den von den ESX-Servern regelmäßig gesendeten Heartbeats. Sendet ein ESX-Server innerhalb von 15 Sekunden keine Antwort, erfolgt die Host Failure Detection: Der ESX-Server fährt die virtuellen Maschinen geregelt herunter, und HA stellt den Neustart dieser sicher; der isolierte ESX-Server markiert sich selbst als isoliert, und alle anderen ESX-Server im HA-Cluster markieren diesen Server als failed (andere ESX-Server erkennen keinen Unterschied zwischen einer Isolierung oder eines Ausfalls eines ESX-Servers). Wird die Netzwerkverbindung des ESX-Servers wiederhergestellt, so gibt es hier zwei unterschiedliche Aktionen, die je nach verstrichener Zeit ausgelöst werden: 왘
Wenn innerhalb von 12 Sekunden die Netzwerkverbindung wiederhergestellt, wird keine Host Failure Detection ausgeführt, und HA tritt nicht in Aktion.
왘
Wird in der Zeit zwischen 12 und 14 Sekunden nach Netzausfall die Verbindung wiederhergestellt, schaltet der betroffene ESX-Server sich selbst in den Isoliert-Status, und seine virtuellen Maschinen werden geregelt heruntergefahren. Die restlichen ESX-Server im HA-Cluster haben ihn noch nicht als failed markiert und unternehmen daher auch keine Anstrengungen, die jetzt gestoppten VMs wieder zu starten. Als Resultat sind alle VMs des ESX-Servers ausgeschaltet.
Split-Brain Jeder, der bereits Cluster betrieben hat, kennt das Problem einer Split-Brain-Situation, das heißt, die Cluster-Knoten sind nicht in der Lage zu bestimmen, welcher Host ausgefallen bzw. noch aktiv ist. Andersherum gesagt, ist jeder Cluster-Knoten der Meinung, dass der oder die anderen Knoten ausgefallen sind und er selbst der einzig aktive ist. Split-Brain-Situationen sind aufgrund der Limitierung des Heartbeats auf die Service-Console-Ports leider nicht zu 100 % abzufangen – ganz im Gegenteil, sie kommen je nach Infrastrukturdesign auch einmal häufiger vor. Vor allem, weil das Management-LAN, in dem auch die Service Console beheimatet ist, im Gegensatz zum Netzwerk der virtuellen Maschinen gerne auch aus Kostengründen ohne Redundanz ausgelegt wird. Allerdings existieren Mittel und Wege, der 100 %-Lösung zumindest nahezukommen.
143
4.2
4
Cluster
Ein sehr typisches Szenario ist dabei ein HA-Cluster mit zwei Knoten. Da jeder HA-Knoten direkt mit dem anderen in Kontakt steht, ist der Ausfall eines der Systeme bereits problematisch, obwohl das Default-Gateway im Standard ebenfalls per Ping geprüft wird. Sehr typisch ist in diesem Fall die nicht redundante physikalische Switch-Konfiguration. Dabei ist es egal, wie viele Netzwerkports an die jeweiligen physikalischen Switches angeschlossen sind, sondern wichtig ist lediglich, ob sie über Kreuz eine Verbindung zu jedem physikalischen Switch besitzen.
Abbildung 4.28 Verwendung von zwei physikalischen Switches für unterschiedliche Dienste, in diesem Fall Service Console und VM-Netzwerk
Fällt der physikalische Switch für das Management-LAN aus, sind die ServiceConsole-Ports beider ESX-Hosts im HA-Cluster tot. Dies führt nach 12 Sekunden zur Isolation Response beider ESX-Hosts! Belassen Sie HA bei der Standardeinstellung, so bedeutet dies den Ausfall aller VMs im HA-Cluster, da beide ESX-Server mit dem Stoppen der virtuellen Maschinen beginnen. Der erste Schritt zur Besserung der Situation wäre, eine zweite Service Console auf dem vSwitch des VM-LANs anzulegen, mit dem Nachteil, dass nun auch die Service Console nun auch aus dem Produktions-LAN und nicht nur aus dem Verwaltungsnetzwerk erreichbar ist. Dies können Sie unter Umständen mittels VLAN-Einsatz umgehen. Der zweite Schritt ist das Abschalten der HA-Option, die VMs direkt herunterzufahren. Hier empfiehlt es sich, die VMs online zu belassen. Durch diesen Schritt versuchen die isolierten ESX-Hosts zwar trotzdem, die virtuellen Maschinen des vermeintlich ausgefallenen ESX-Servers zu starten, können dies jedoch nicht, da
144
HA-Cluster
diese noch aktiv sind (der Start wird durch die exklusive Sperre der virtuellen Festplatte verhindert). Ist ein ESX-Host jedoch wirklich ausgefallen, so ist die Sperre auf den virtuellen Festplatten nicht mehr aktiv, und der verbliebene HAKnoten kann die VMs problemlos starten. Eine weitere Möglichkeit besteht in dem Hinzufügen weiterer IP-Adressen im Netzwerk, um die Erkennung der Isolation Response noch sicherer zu gestalten. In unserem Beispiel würde dies allerdings nur etwas nutzen, wenn eine zweite Service Console oder ein redundantes Netzwerk verfügbar wäre. Ärgerlich ist bei HA die fehlende Funktion, nicht nur das Service-Console-Netzwerk zu überprüfen, sondern auch das Netzwerk der virtuellen Maschinen. Hier bleibt wirklich nur der Schritt, eine zweite Service Console im gleichen physikalischen Netzwerk der VMs anzulegen.
Abbildung 4.29 Verwendung von zwei physikalischen Switches mit zwei Service Consoles und VM-Netzwerk
4.2.13 HA-Cluster-Prüfung HA verfügt über eine direkte Überprüfung der Standardanforderungen an einen Cluster wie beispielsweise die Redundanz des Service-Console-Netzwerks.
Abbildung 4.30
Automatische Überprüfung des Clusters auf Redundanz
145
4.2
4
Cluster
Diese Konfigurationsprüfungen dienen in erster Linie dazu, auffällige Fehler im Design, aber auch kurzfristige Probleme wie z. B. den Ausfall eines Netzwerkadapters direkt sichtbar zu machen. Manche Fehler sind allerdings gewollt, besonders beim Einsatz von Test- oder Entwicklungssystemen, daher können Sie die Tests weitestgehend mittels Advanced Options abschalten und beeinflussen.
4.2.14 HA und der Maintenance-Mode Wenn ein ESX-Server eines HA-Clusters in den Maintenance-Mode geschaltet wird, können keine virtuellen Maschinen auf diesem Server gestartet oder durch VMotion auf diesen Server verschoben werden. Dadurch kann HA diesen Server auch nicht als verfügbaren ESX-Server für Failover-Aktivitäten verwenden und wird auch aus den Berechnungen des Failover-Levels herausgenommen. Nach Beendigung der Wartungsarbeiten und dem Deaktivieren des MaintenanceModes wird er wieder regulär von HA als Teil des HA-Clusters angesehen und gegebenenfalls beansprucht. Die Aktivierung des Maintenance-Modes führt bei Primary-Knoten zur Abgabe dieses Status an einen sekundären Knoten, der nicht im Maintenance-Mode ist.
4.2.15 HA und getrennte (disconnected) ESX-Server Ist ein ESX-Server eines HA-Clusters im vCenter als disconnected markiert, schließt die HA-Logik diesen Server aus ihren Failover-Berechnungen und Failover-Aktivitäten aus. War dieser Server ein primärer Knoten, so wird ein sekundärer ESX-Host zum Primary ernannt. Ein ESX-Server wird durch das explizite Trennen seitens des Administrators vom Cluster getrennt.
Abbildung 4.31 Werden Hosts getrennt, schaltet der HA-Agent ab.
4.2.16 HA und DNS Die korrekte Funktionsweise von VMware HA basiert auf einer einwandfreien Namensauflösung aller Namen der im HA-Verbund involvierten Server. Dabei muss jeder ESX-Knoten sowie der vCenter-Server den FQDN-Namen sowie den Shortname eines jeden anderen ESX-Knotens sowie den des VC-Servers auflösen können. Ebenso müssen die notwendigen PTR-Records aller Beteiligten in den Reverse-Lookup-Zonen vorhanden sein. Bei dem FQDN darf die maximale Länge von 29 Zeichen nicht überschritten werden.
146
HA-Cluster
Viele HA-Probleme beruhen nach eingehender Analyse auf einer fehlerhaften oder unvollständigen Namensauflösung im Verbund. Um zusätzlich DNS-Ausfälle zu überbrücken, bedienen sich manche VMwareKunden auch der Hosts-Datei (/etc/hosts), in der die IPs der Service Consoles samt FQDN und Shortname eingetragen werden, z. B.: 192.168.199.23
ESX3 ESX3.bookshop.test
In jedem Fall sollten die Dateien /etc/hosts und /etc/resolv.conf auf falsche Einträge überprüft werden. Korrekte Namensauflösung Obwohl wir in den Screenshots dieses Buches aufgrund der häufigen Umstrukturierung nicht immer ESX-Namen, sondern IP-Adressen verwenden, ist es eine dringende Empfehlung, beim HA-Einsatz über eine korrekte Namensauflösung zu verfügen und die ESX-Hosts mit ihrem DNS-Namen und nicht mit der IP-Adresse im vCenter aufzunehmen.
4.2.17 HA im vSphere-Client (oder: Der Cluster treibt’s bunt …) Der HA-Cluster zeigt sich im vCenter identisch wie ein DRS-Cluster, da beide VMware-Funktionen gleichzeitig in einem Cluster aktiviert werden können. Das Symbol kann bei der Kombination von HA und DRS insgesamt drei verschiedene Status anzeigen und zwei verschiedene Status, wenn HA allein betrieben wird: Ein normales Symbol informiert, dass der HA-Cluster ohne Einschränkungen lauffähig ist; ein gelbes Symbol bei einem mit DRS kombinierten Cluster signalisiert, dass DRS überbucht (overcommitted) ist (das heißt, es stehen nicht genügend Ressourcen zur Verfügung); ein rotes Symbol signalisiert einen ungültigen HA- oder DRS-Cluster (zum Beispiel im HA-Bereich durch nicht ausreichende Ressourcen zum Erreichen der Failover-Kapazität). Yellow Cluster – overcommitted 왘
Ein DRS-Cluster ist overcommitted, wenn ein ESX-Host ausfällt und somit nicht ausreichend Ressourcen mehr zur Verfügung stehen.
왘
Ein DRS-Cluster hat für einen Child-Resource-Pool oder dessen VMs nicht ausreichend Ressourcen, um dessen Anforderungen zu erfüllen.
Red Cluster – invalid 왘
Ein HA-Cluster ohne ausreichende Kapazitäten (aktuelle Failover-Kapazität), um die konfigurierte Failover-Capacity abzudecken
147
4.2
4
Cluster
4.2.18 HA-Limitierungen mit vSphere VMware tat sich lange Zeit sehr schwer, genaue Angaben zu den Limitierungen von HA zu machen. Meist bekam ein Kunde erst die genauen Angaben, nachdem er einen Support Case eröffnet hatte, da er bereits auf Probleme stieß. Ein weiteres Problem ist, dass die Limitierung sich mit jedem kleineren Release (Minor) ändert. Mit vSphere 4.0 sind folgende Limitierungen in Bezug auf VMware HA bekannt: Beschreibung ESX-Hosts pro HA-Cluster aktive VMs pro ESX-Host in einem HA-Cluster mit 8 und weniger Hosts aktive VMs pro ESX-Host in einem HA-Cluster mit 9 und mehr Hosts Maximale Failover-Hosts pro HA-Cluster Maximale Failover-Ressourcen (%) pro HA-Cluster Tabelle 4.3
Limitierung 32 100 40 4 50 %
HA-Cluster-Limitierung
4.2.19 HA Virtual Machine Monitoring Virtual Machine Monitoring, oft nur VMHA genannt, ist eine seit VI 3.5 U3 bekannte Funktion zur Überwachung von virtuellen Maschinen auf Aktivität. Diese Aktivität wird in Form des Heartbeats gemessen, der über die VMware Tools erzeugt wird. Sobald kein Heartbeat über einen gewissen Zeitraum empfangen wird, führt vCenter einen harten Reset durch. Dieses Vorgehen soll z. B. Kernel-Panics unter Linux und Bluescreens unter Windows erkennen. Ähnlich wie bei VMware HA ist es möglich, VMHA auf der Eigenschaftsseite (Abbildung 4.32) mit einer simplen Checkbox zu aktivieren oder zu deaktivieren – Enable VM Monitoring. In der ersten Version gab es noch einen sehr derben Fehler, der VMHA nach einem VMotion-Vorgang auslöste, da der Heartbeat in diesem Fall für mehr als 30 Sekunden ausfiel. Das Ergebnis war ein harter Reset der virtuellen Maschine nach jedem erfolgreichen VMotion. Aus diesem Grund war die einfachste Lösung, die 30 Sekunden zu erhöhen, was mittels Monitoring sensitivity passiert, die Sie unter der Sektion Default Cluster Settings finden.
148
HA-Cluster
Abbildung 4.32 VM Monitoring-Funktion von VMware HA
Die Standardeinstellungen Low, Medium und High besitzen folgende DefaultWerte: Level
Failure Interval
Minimum Uptime
Maximum Maximum per-VM Resets Resets Time Window
Low
120 Sekunden
480 Sekunden
3
168 Stunden
Medium
60 Sekunden
240 Sekunden
3
24 Stunden
High
30 Sekunden
120 Sekunden
3
1 Stunde
Tabelle 4.4
Standard-Monitoring sensitivity
Vier Werte sind für die Sensitivity interessant: 왘
Failure Interval: Dieser Wert steht für das Prüfintervall auf Ausfall einer VM, d. h. wie lange kein Heartbeat erkannt wurde.
왘
Minimum uptime: Bestimmt die Mindestlaufzeit zwischen einem Fehler mit Neustart und einer erneuten Heartbeat-Überwachung.
149
4.2
4
Cluster
왘
Maximum per-VM resets: maximale Anzahl an Neustarts aufgrund von erkannten VMHA Fehlern. Danach findet kein weiterer Neustart statt, und die VMHA-Erkennung wird für die VM vorübergehen abgeschaltet.
왘
Maximum resets time window: Zeitfenster, in dem die maximale Anzahl der VM-Resets gezählt wird. Ist das Zeitfenster seit dem ersten Ausfall überschritten, startet das Reset-Time-Window von vorn.
Abbildung 4.33
Pro-VM-Einstellungen für das VM Monitoring
Diese Einstellungen können nicht nur allgemein, sondern auch pro virtueller Maschine getroffen werden. Hier ist es möglich, beim Standard (Use Cluster Settings) zu bleiben oder ebenfalls zwischen High, Medium und Low zu wählen. Reicht dies nicht aus, ist auch pro virtueller Maschine eine Custom-Einstellung möglich.
Abbildung 4.34
Custom-Einstellungen VM Monitoring pro virtueller Maschine
Virtual Machine Monitoring: Advanced Options Neben den Advanced Options für die ESX-HA-Funktion existieren auch Optionen für die Überwachung der virtuellen Maschinen. Allerdings sind diese identisch mit den über die grafische Oberfläche verfügbaren Einstellungen.
150
DRS-Cluster
Option
Beschreibung
das.failureInterval
Prüfintervall auf Ausfall der VM. Standard ist 30.
das.maxFailureWindows
Mindestlaufzeit zwischen den Fehlern und der Neustarts. Standard sind 3600 Sekunden. Fällt die Maschine innerhalb von 3 600 Sekunden zweimal aus, wird sie nur beim ersten Mal neu gestartet.
das.maxFailures
Maximalanzahl an Fehlern (Neustarts). Sobald der angegebene Wert erreicht ist, wird die VM nicht mehr automatisch neu gestartet. Standardwert ist 3.
das.minUptime
Angabe der Mindestlaufzeit der virtuellen Maschine, bevor VM HA wieder die Prüfung beginnt. Standard sind 120 Sekunden. Hiermit wird verhindert, das VMs stetig neu gestartet werden, ohne jemals aktiv zu werden.
Tabelle 4.5
4.3
VMware HA Virtual Machine Monitoring Advanced Settings
DRS-Cluster
In den meisten Fällen unterstützen Cluster-Produkte sowohl Ausfallsicherheit als auch Lastverteilung. Dies ist bei VMware vSphere nicht anders, daher ist eine Lastverteilungsfunktion bei den Cluster-Objekten mit an Bord.
Abbildung 4.35
4.3.1
Funktionsübersicht DRS (Distributed Resource Scheduler)
Technologie-Übersicht
Um in einer VMware-Umgebung eine Lastverteilung zwischen den verschiedenen ESX-Hosts zu erreichen, fasst man bestimmte ESX-Hosts zu einem DRS-Cluster zusammen. DRS ist die Abkürzung für »Distributed Resource Scheduling« und kann kurzerhand als ein Load-Balancing-Tool für virtuelle Maschinen gesehen werden. Zwischen diesen ESX-Hosts innerhalb des Clusters werden die virtuellen
151
4.3
4
Cluster
Maschinen verschoben, um unter Betrachtung der CPU- und Speicherauslastung der ESX-Hosts eine ausgeglichene Verteilung der Last zu erhalten. Dabei wird die Netzwerk- und Festplattenauslastung der ESX-Hosts nicht beachtet. Das Verschieben der VMs erfolgt mit Hilfe von VMotion, daher ist die Ablage der VM-Dateien auf einem zentralen Speichermedium die Grundvoraussetzung für DRS. Darum ist darauf zu achten, dass die verschiedenen ESX-Hosts eines DRS-Clusters auch CPU-kompatibel für VMotion-Aktivitäten sein müssen. Das Ziel von DRS kann man also in einen Satz fassen: Durch das Verschieben von virtuellen Maschinen von stark ausgelasteten Servern hin zu weniger ausgelasteten Servern wird versucht, eine ausgewogene Verteilung von virtuellen Maschinen auf der vSphere-Umgebung zu erreichen. DRS kann in verschiedenen Automatisierungsstufen betrieben werden. Diese reichen von reinen Empfehlungen, welche virtuelle Maschinen zu verschieben seien, bis hin zum voll automatisierten DRS-Betrieb, in dem jegliche Empfehlung sofort umgesetzt wird. Des Weiteren können Regeln aufgestellt werden, wie virtuelle Maschinen im gesamten DRS-Regelwerk zu behandeln sind. Diese Regeln bestimmen, dass z. B. virtuelle Maschinen immer gemeinsam auf einem ESX-Host betrieben werden sollen, oder das Gegenstück dazu, dass virtuelle Maschinen niemals gemeinsam auf einem einzigen ESX-Host platziert werden dürfen. Natürlich können bestimmte virtuelle Maschinen aus dem DRS-Cluster ausgeschlossen werden; diese werden bei allen DRS-Aktivitäten nicht berücksichtigt, wohl aber bei der Berechnung der Ressourcenauslastung. Die Architektur von DRS basiert auf dem vCenter und benötigt auf den ESX-Hosts im Gegensatz zu VMware HA keine lokalen Agenten. Der vCenter-Client ist für DRS der Dreh- und Angelpunkt, um die DRS-Konfiguration vorzunehmen und die DRS-Empfehlungen auszuführen. Ein DRS-Cluster kann maximal 32 Knoten umfassen. Das vCenter überprüft in Abständen von fünf Minuten (Standardeinstellung) die CPU- und Speicherauslastung der im DRS-Cluster befindlichen ESX-Hosts. Allerdings können Sie in den Eigenschaften des DRS-Clusters jederzeit auch einen manuellen Scan auslösen.
Abbildung 4.36 Manueller Start der DRS-Überprüfung
152
DRS-Cluster
Bei der Berechnung der Ressourcenauslastung bezieht das vCenter alle virtuellen Maschinen der ESX-Hosts im DRS-Cluster ein, auch die aus der DRS-Funktion ausgegliederten virtuellen Maschinen. Dieser Berechnungsprozess wird auch durch das Hinzufügen oder das Entfernen eines ESX-Hosts aus dem DRS-Cluster gestartet, um schnellstmöglich eine optimale Auslastung von CPU und Speicher der ESX-Hosts zu erlangen.
4.3.2
Lizenzierung von DRS
VMware DRS ist Bestandteil der vSphere Suite, die auf CPU-Sockel-Basis lizenziert und ab der Edition Enterprise integriert ist.
4.3.3
Anlage eines DRS-Clusters
Prinzipiell wird der DRS-Cluster genau gleich dem HA-Cluster angelegt, da DRS auch nur eine Funktion des Cluster-Objekts ist. Daher können Sie DRS direkt bei der Anlage eines Clusters aktivieren oder auch nachträglich. Deaktivierung Ebenso ist es jederzeit möglich, die DRS-Funktion zu deaktivieren, was allerdings direkte Auswirkungen auf die Systeme hat, da alle Resource-Pools entfernt werden!
Abbildung 4.37
Aktivierung der DRS-Funktion im Cluster
Sobald ein DRS-Cluster existiert, können Sie ESX-Hosts inklusive Resource-Pools per Drag & Drop integrieren. Sie müssen lediglich entscheiden, wie die ResourcePools übernommen werden sollen.
153
4.3
4
Cluster
Möglich ist eine Übernahme der Resource-Pools mit gleichem Namen in den Root-Resource-Pool des Clusters (der Cluster selbst ist der Root-Resource-Pool), oder Sie legen neue Resource-Pools an für alle VMs dieses Hosts mit dem zu wählenden Namen-Präfix (Vorgabe Grafted from ESXHost). Ist DRS nicht aktiviert, wird automatisch eine Warnmeldung ausgegeben, da alle Resource-Pools verlorengehen.
Abbildung 4.38 Ist im Cluster DRS nicht aktiviert, wird vor der Integration eines Hosts mit bestehenden Resource-Pools gewarnt.
4.3.4
Prioritäten-Ranking
Die DRS-Prioritäten werden in Werten von 1 bis 5 Sterne angegeben, die Auswirkungen auf eine Migration einer virtuellen Maschine von einem Host auf einen anderen haben sowie auf den Ziel-Host beim Neustart einer VM. Eine Empfehlung mit Priorität 5 hat die größte Auswirkung auf die Performance-Auslastung eines ESX-Hosts und im Gegensatz dazu eine Empfehlung mit einem Stern die geringste. Die Empfehlungen mit Priorität 5 umfasst außerdem die Migrationen, die von den »DRS Affinity Rules« herrühren oder vom Einschalten des Maintenance-Modes auf einem ESX-Host, was eine automatische Evakuierung der Gastsysteme durch DRS auslöst. Des Weiteren versprechen Operationen mit Priorität 5 eine Auflösung von sehr großen Auslastungs-Ungleichgewichten. Die Empfehlungen mit weniger Priorität haben absteigend auch immer einen kleiner werdenden Einfluss auf den Ausgleich von Ungleichgewichten im DRS-Cluster.
4.3.5
DRS-Automation-Level
Der Automatisierungsgrad eines DRS-Clusters ist eine für alle ESX-Hosts des DRSClusters übergreifende Einstellung und umfasst die drei Stufen Manual, Partially automated und Fully automated. Das Automation-Level Manual gibt lediglich Empfehlungen über den vCenterClient an den VMware-Administrator, welche virtuelle Maschine auf welchem ESX-Host zu starten ist, um eine ausgewogene Lastverteilung zu erreichen. Die aktuell existierenden Empfehlungen werden im vCenter-Client nach Auswahl des DRS-Clusters aufgelistet.
154
DRS-Cluster
Abbildung 4.39
Eigenschaften des DRS-Clusters
Abbildung 4.40
Prioritätenanzeige beim Start einer VM beim Automation-Level Manual
Dieses »Priority Ranking« wird vom Automation-Level in der DRS-Automatisierungsstufe Fully automated immer verwendet, bei Partially automated nur beim Einschalten einer VM. Die Empfehlungen enthalten unter anderem den Namen der virtuellen Maschine und das jeweilige Priority Ranking. Diese können dann zu einem beliebigen Zeitpunkt durch Klick des Administrators durchgeführt werden. Hierbei ist eine Auswahl zu treffen, damit die virtuelle Maschine in Betrieb genommen werden kann. Natürlich werden auch hier nur jene ESX-Hosts als Ziel betrachtet, die alle Bedingungen zum Start der VM erfüllen. Das Automation-Level Fully automated ist das Gegenteil der manuellen Methode. Sämtliche Empfehlungen werden vom vCenter automatisch durchgeführt, beim Starten von virtuellen Maschinen (Initial Placement) und im laufenden Betrieb (Virtual Machine Migration). In dieser Stufe kann die Migration von virtuellen Maschinen nochmals in fünf Level unterteilt werden:
155
4.3
4
Cluster
왘
Dabei ist Level 1 das konservativste und Level 5 das aggressivste. Level. 1 »Konservativ« bedeutet, dass nur Empfehlungen mit Priorität 5 automatisiert durchgeführt werden. Alle anderen Empfehlungen, also mit Priorität 1–4, werden dem Administrator als Empfehlung angeboten.
왘
Level 2 führt alle Empfehlungen mit Priorität vier und fünf durch.
왘
Level 3 führt alle Empfehlungen mit Priorität drei oder mehr durch.
왘
Level 4 führt alle Empfehlungen mit Priorität zwei oder mehr durch.
왘
Die am höchsten automatisierte Form des DRS erreichen Sie mit Level 5 »Aggressive«. Hierbei werden grundsätzlich alle Empfehlungen, egal welche Priorität, vom System automatisch durchgeführt.
Im Summary-Tab des DRS-Clusters können Sie alle Empfehlungen und eine Kurzübersicht schnell einsehen.
Abbildung 4.41 VMware-DRS-Kurzübersicht im »Summary«-Tab des DRS-Clusters
Das Automation-Level Partially automated ist eine Mischung aus den beiden Stufen Manual und Fully automated. Beim Starten von virtuellen Maschinen erfolgt deren Initial Placement komplett automatisiert. Je nach Ressourcenauslastung der ESX-Hosts wird die zu startende virtuelle Maschine auf einen freien ESX-Host verschoben und dann gestartet. Dies ist die einzige voll automatisierte Aktion in dieser Stufe. Die regelmäßige Überprüfung der ESX-Auslastung resultiert dann, wie unter der Stufe Manual, lediglich in Empfehlungen zur Migration von VMs. Diese kann der Administrator dann bei Bedarf durchführen. Möchten Sie sich die derzeitige Auslastung genauer anschauen, so bieten sich die Resource-Distribution-Charts im Summary des DRS-Clusters an, die die Auslastung der einzelnen Hosts und eventuelle Ungleichgewichte anzeigen. Vorsicht Sie sollten immer Vorsicht walten lassen und Fully automated nicht zu aggressiv einstellen, da es sonst zu enorm vielen VMotion-Aktivitäten kommen kann, die den Cluster massiv negativ beeinflussen.
156
DRS-Cluster
Abbildung 4.42 DRS-Distribution-Chart
4.3.6
DRS-Affinity-Rules
Die DRS-Affinity-Rules legen fest, ob und welche virtuelle Maschinen bei DRSMigrationen immer gemeinsam oder niemals gemeinsam verschoben werden dürfen. Folgende zwei Regeln stehen zur Verfügung: Keep Virtual Machines Together und Separate Virtual Machines.
Abbildung 4.43
Affinity-Rules = Regelwerk für DRS
157
4.3
4
Cluster
Die Regel Keep Virtual Machines Together stellt sicher, dass bei von DRS empfohlenen oder auch durchgeführten Migrationsvorgängen immer die in dieser Regel definierten virtuellen Maschinen zusammen verschoben werden, das heißt, diese VMs befinden sich immer zusammen auf einem ESX-Host. Um dies sicherzustellen, werden diese Regeln auch in die Berechnungen eingeschlossen so dass die Empfehlung immer den Gesamtzustand berücksichtigt, die aktuelle Auslastung der ESX-Hosts sowie die Möglichkeiten, wenn alle VMs dieser Regel verschoben würden. Ein typischer Fall hierfür wären voneinander abhängige Systeme wie beispielsweise Datenbanksystem und dazugehöriges Applikationssystem. Können beide nicht unabhängig voneinander betrieben werden, ist es sinnvoll, sie immer auf dem gleichen ESX-Host zu betreiben. Das Gegenteil dazu stellt die Regel Separate Virtual Machines dar. Sie stellt sicher, dass die in dieser Regel definierten virtuellen Maschinen niemals auf einem ESX-Host gemeinsam laufen dürfen. Dies ist zum Beispiel für ClusterLösungen innerhalb der virtuellen Welt sinnvoll; ein Ausfall eines ESX-Hosts mit beiden Knoten eines Microsoft-Clusters oder eines NLB-Verbundes umginge die auf der virtuellen Ebene getroffenen Vorsichtsmaßnahmen wieder, und das komplette Cluster-System stünde still. Auch diese Regeln werden bei den Berechnungen der Performance-Auslastung immer berücksichtigt. Nach der Erstellung von neuen Regeln werden diese sofort gegen die aktuelle Verteilung der VMs überprüft, und bei den Modi Manual und Partially automated werden neue Migrationen empfohlen. Diese müssen nicht zwingend durchgeführt werden, aber sie bleiben als Empfehlung bestehen, bis keine Regel mehr verletzt wird.
Abbildung 4.44
Verstoß gegen eine DRS-Affinitätsregel
Wird eine Regel z. B. beim Start einer virtuellen Maschine verletzt, so erscheint eine Fehlermeldung, und der Startvorgang wird gestoppt.
4.3.7
DRS Virtual Machine Options
Die DRS-Regeln betreffen standardmäßig immer alle virtuellen Maschinen aller zum DRS-Cluster hinzugefügten ESX-Hosts. Zeitweise ist es aber möglicherweise
158
DRS-Cluster
notwendig, verschiedene virtuelle Maschinen innerhalb eines DRS-Clusters gesondert zu behandeln. Zum Beispiel sollten bestimmte VMs niemals via VMotion verschoben und somit von der DRS-Automatisierung ausgeschlossen werden. Andere wiederum sollten trotz Teil- oder Vollautomatisierung der DRS-Migration nur nach Zustimmung des Administrators verschoben werden – also entgegen der Cluster-Konfiguration auf Manualkonfiguriert werden.
Abbildung 4.45
DRS-Automation kann auch pro VM gesondert definiert werden.
Diese Einstellungen definieren Sie in den DRS-Eigenschaften im Menü unter DRS Virtual Machine Options. Hier existieren die Einstellungen Disabled, Manual, Fully automated, Partially automated und Default; Letzteres gibt die globale DRS-Cluster-Einstellung wieder und ist auch der Standardwert jeder VM. Durch die Einstellung Disabled wird zwar die virtuelle Maschine von DRS-Migrationen ausgenommen und dafür auch keine Empfehlungen ausgesprochen, aber die Performance-Auslastung durch diese VM wird bei den DRS-Berechnungen dennoch berücksichtigt. Zum Abschluss sei zu diesen Möglichkeiten erwähnt, dass zu viele Ausnahmeregelungen die Möglichkeiten und auch den Sinn von DRS unterwandern. Diese DRS-Optionen sollten Sie nur in Maßen einsetzen!
4.3.8
DRS und Resource-Pools
Die Ressourcen eines jeden ESX-Hosts im DRS-Cluster werden logisch zu einem Resource-Pool zusammengefasst. Wie auch bei Resource-Pools für alleinstehende ESX-Hosts können Resource-Pools einen DRS-Cluster weiter in logische Ressourcengruppen unterteilen. Dabei sind die Grenzen der Pools nicht mehr an einen ESX-Host gebunden, sondern umfassen die gesamten Ressourcen eines DRS-Clusters.
159
4.3
4
Cluster
Abbildung 4.46 Wie soll mit bestehenden Resource-Pools bei der Cluster-Integration umgegangen werden?
Beim Hinzufügen eines neuen ESX-Hosts stehen zwei Möglichkeiten zur Verfügung, wie die neu hinzukommenden Ressourcen eines ESX-Hosts logisch verwaltet werden sollen: Die Option Put this host’s virtual machines in the cluster’s root resource pool fügt den ESX-Host mitsamt seinen virtuellen Maschinen zum Resource-Pool des DRS-Clusters hinzu. Sollten auf dem ESX-Host bereits Resource-Pools existieren, so werden diese ignoriert. Die Option Create a new resource pool for this host’s virtual machines and resource pools fügt den neuen ESX-Hosts in einem neu erstellten Resource-Pool dem DRS-Cluster hinzu. Der neu erstellte Resource-Pool existiert in der Hierarchie auf der obersten Ebene, und alle VMs des ESX-Hosts werden diesem neuen Pool zugeordnet. Dieser neue Pool erhält standardmäßig den Namen »Grafted from servername«, der aber geändert werden kann.
4.3.9
DRS und der Maintenance-Mode
Zum Patchen, Ausschalten oder für andere Administrationsaufgaben auf einem ESX-Host ist es notwendig, alle darauf laufenden VMs zu stoppen. In größeren Umgebungen mit DRS kann dies sehr problematisch werden, denn bei mehreren Administratoren führen Migrationen oder andere Aktivitäten auf dem gewünschten ESX-Host, das Herunterfahren oder das Patchen schnell zu größeren Problemen. Um diese Schwierigkeiten zu umgehen, wurde der Maintenance-Mode von VMware entworfen. Vor diesen Administrationstätigkeiten wird der Maintenance-Mode für einen ESX-Host entweder per vCenter-Client oder über die Kommandozeile aktiviert. In der Zeit, bis ein ESX-Host den Maintenance-Status erreicht hat (zuerst müssen alle darauf laufenden VMs verschoben oder gestoppt werden), und während des Maintenance-Modes werden auf diesem ESX-Server
160
DRS-Cluster
keine Aktionen mit den darauf abgelegten virtuellen Maschinen zugelassen. Dies betrifft auch das Verschieben von VMs mittels VMotion auf diesen Host. Wird der Maintenance-Mode auf einem ESX-Host im DRS-Cluster gestartet, werden im vollautomatischen Betrieb alle VMs auf freie Ressourcen innerhalb des Clusters verschoben. Erst danach ist der Maintenance-Mode aktiv. Manuell eingreifen Bedenken Sie, dass der Maintenance-Modus erst aktiviert wird, wenn die VMs entweder auf andere Hosts migriert, abgeschaltet oder suspendiert wurden. Sind die VMotion-Kriterien nicht erfüllt, kann ein Maintenance-Mode nicht automatisch aktiviert werden, und Sie müssen manuell eingreifen.
4.3.10 DRS-Limitierungen mit vSphere Mit vSphere 4.0 sind folgende Limitierungen in Bezug auf VMware DRS bekannt: Beschreibung ESX-Hosts pro DRS-Cluster aktive VMs in einem DRS-Cluster aktive VMs pro ESX-Host in einem DRS-Cluster Tabelle 4.6
Limitierung 32 1.280 256
DRS-Cluster-Limitierung
4.3.11 DPM (Distributed Power Management) DPM alias Distributed Power Management war lange Zeit nur experimentell verfügbar, hat aber nun die volle VMware-Unterstützung. Dies ist eine der Funktionen, die mit am meisten kontrovers diskutiert werden, da DRS aufgrund der Auslastung versucht, viele VMs auf möglichst wenige ESX-Hosts zu verteilen, um die freiwerdenden Hosts energiesparend in den Standby-Modus zu stellen. Kritiker möchten natürlich nicht, dass Ressourcen künstlich konsolidiert und vorhandene Systeme abgeschaltet werden. Außerdem bestehen Bedenken, dass die abgeschalteten Systeme vielleicht nicht oder zu langsam bei steigenden Anforderungen wieder aktiv werden. Allerdings gibt es genügend Gründe, dieses Risiko einzugehen, wenn es um Energieeffizienz und Kosteneinsparungen geht. Vor allem Provider und große ITUnternehmen, die keine Detailplanung der Hardware machen können, sondern zwangsweise mehr Hardware vorhalten müssen als wirklich nötig, um die Spitzen abzufangen, ziehen großen Nutzen aus DPM.
161
4.3
4
Cluster
Abbildung 4.47 einzusparen.
DPM schaltet nicht benötigte Hosts in einen Standby-Modus, um Energie
DPM erfordert allerdings, dass die ESX-Server-Hardware den Standby-Modus unterstützt und auch wieder »aufgeweckt« werden kann. An Möglichkeiten stehen HP iLO, sämtliche IPMI-Schnittstellen und Wake on LAN auf der Service-ConsoleSchnittstelle als Optionen bereit. Diese Konfiguration müssen Sie manuell in der Configuration des ESX-Hosts unter Power Management durchführen.
Abbildung 4.48
IPMI/iLO-Einstellung für DRS
Nachdem Sie sichergestellt haben, dass die Power-Management-Funktion des ESX-Servers korrekt eingetragen ist, können Sie DPM unter dem Punkt Power Management in den Eigenschaften des DRS-Clusters einrichten. Schalten Sie DPM ein, so können Sie entweder den ESX-Hosts manuell evakuieren, und DRS stellt entsprechende Empfehlungen bereit, oder Sie lassen DPM ähnlich der Fully automated-Einstellung selbstständig agieren und bestimmen nur, anhand welcher Priorität die VMs migriert und die freien Systeme abgeschaltet werden.
162
DRS-Cluster
Abbildung 4.49
DPM-Konfiguration innerhalb des DRS-Clusters
Abbildung 4.50
DPM-Einstellungen pro ESX-Host
Selbstverständlich ist es möglich, einzelne Hosts mit anderen Einstellungen zu versehen und komplett aus DPM zu entfernen. Außerdem können Sie unter Power Management 폷 Host Options den Zeitpunkt des letzten erfolgreichen Standby-Vorgangs einsehen. Derzeit leider nur über eigene Erweiterungen durch Skripte möglich ist eine Zeitsteuerung. Es wäre für viele Unternehmen interessant, zu einer gewissen Abendstunde DPM zu aktivieren, morgens vor den Stoßzeiten wieder zu deaktivieren und alle ESX-Hosts verfügbar zu halten. An dieser Stelle können wir daher nur auf die PowerShell oder Perl verweisen.
163
4.3
4
Cluster
4.3.12 HA und DRS in Kombination HA und DRS werden sehr häufig gleichzeitig in einem Cluster aktiviert, um sämtliche Funktionen nutzen zu können. Die beiden Produkte ergänzen sich auch sehr gut; so kann DRS beispielsweise die virtuellen Maschinen anhand ihrer Last optimal verteilen, nachdem ein ESX-Host ausfiel und die VMs »wahllos« auf den übrigen ESX-Servern neu gestartet wurden. Außerdem bietet DRS einen großen Vorteil bezüglich des Wartungsmodus (Maintenance-Mode), da die virtuellen Maschinen automatisch von dem zu wartenden System evakuiert werden, vorausgesetzt, die virtuellen Maschinen sind korrekt konfiguriert (keine verbundenen Wechselmedien, gleiche Netzwerke, keine lokalen Festplatten). Allerdings sollten Sie beachten, dass eine HA/DRS-Kombination realistisch erst ab drei ESX-Hosts im Cluster sinnvoll genutzt werden kann.
4.4
Fault-Tolerance
Fault-Tolerance (im folgenden FT genannt) ist eine neue Technologie von VMware und wurde mit VMware vSphere 4 eingeführt. Im Gegensatz zu VMware High Availability (VMware HA), bei dem die virtuellen Maschinen auf einem anderen Host neu gestartet werden, sobald ein ClusterKnoten ausfällt, läuft die virtuelle Maschine bei FT nahtlos weiter.
Abbildung 4.51 Fault-Tolerance ermöglicht einen unterbrechungsfreien Betrieb virtueller Maschinen, sogar bei Ausfall des physikalischen ESX-Servers.
164
Fault-Tolerance
Das bedeutet: keine Ausfallzeit beim Absturz einer der durch FT geschützten virtuellen Maschinen. Dabei spielt es keine Rolle, ob nur die primäre VM ausgefallen ist oder das komplette Host-System, auf dem primäre VM lief. Es handelt sich also um eine erweiterte Hochverfügbarkeit, die vor Einführung auch als »Continuous High Availability« bezeichnet wurde. Ein Eingriff in den Gast ist nicht notwendig, allerdings müssen für FT viele Randbedingungen erfüllt sein. Damit ist FT sogar weit mächtiger als die bekannten Cluster-Produkte und bietet den höchsten Grad an Ausfallsicherheit.
4.4.1
Wie funktioniert Fault-Tolerance?
FT funktioniert mit bekannten Methoden. Mittels angepasstem VMotion wird eine sekundäre Maschine auf einem anderen Host des HA-Clusters erstellt und betrieben. Auf den ESX-Hosts läuft ein vmklogger-Prozess, der für die asynchrone Übertragung der Logs zuständig ist. Diese beiden Maschinen, primäre und sekundäre, greifen beide auf dieselben Dateien des Shared Storage zu. Doppelt werden nur die CPU-Befehle und der Inhalt des RAM gehalten, was über die vLockstep-Technologie geschieht. Sekundäre VM
Primäre VM
FT-Logging-Verkehr
Rückmeldung Festplatten-Schreibund -Leseoperationen
Shared Storage (FC/NFS/iSCSI)
RECORD
Client
Abbildung 4.52
• Eingaben (Netzwerk, Benutzer) • asynchrone E/A (Festplatten, Geräte) • CPU-Timer-Interrupts
REPLAY Identische Wiedergabe der aufgenommenen Funktionen • Ergebnis = wiederholbare VM-Instruktionen
Funktionsübersicht von VMware-Fault-Tolerance
Ändert sich zum Beispiel etwas im RAM der virtuellen Maschine, wird diese Änderung in beiden physikalischen Maschinen durchgeführt, bevor ein commit an die virtuelle Maschine gesendet wird. Die Befehle der CPU werden über die bereits bekannte Record- und Replay-Funktion der VMware-Workstation übertragen.
165
4.4
4
Cluster
Wichtig Fällt die primäre virtuelle Maschine aufgrund eines Bluescreens aus, wird dieses Schicksal mit sehr hoher Wahrscheinlichkeit auch die sekundäre VM ereilen. Diese könnte allerdings durch HA Virtual Machine Monitoring neu gestartet werden.
Wird die primäre VM gestartet, startet die sekundäre automatisch mit und wird, falls DRS aktiviert ist, anhand der DRS-Empfehlungen auf den entsprechenden Hosts verteilt. Wird die primäre VM heruntergefahren, wird auch die sekundäre VM heruntergefahren. Sowohl primäre als auch sekundäre VM können mittels VMotion migriert werden, dürfen jedoch nie auf dem gleichen Host-System betrieben werden. Die beiden Primary- und Secondary-VMs unterhalten sich mittels Heartbeat miteinander, und ein Split-Brain wird durch Renaming (Umbenennung einer Datei im Shared Storage) verhindert.
4.4.2
Technische Voraussetzungen
Damit FT funktioniert, werden CPUs in den ESX-Hosts vorausgesetzt, die eine Hardwarevirtualisierung unterstützen. Das bedeutet, dass AMD-CPUs AMD-V und Intel-CPUs INTEL VT unterstützen müssen (Intel 31xx-, 33xx-, 52xx-, 54xx-, 74xx-, Xeon 55xx- oder AMD 13xx-, 23xx-, 83xx-Serie). Abhängig von der CPU existiert übrigens noch eine Liste im Knowledge-Base-Eintrag 1008027 (http:// kb.vmware.com/kb/1008027), welche Prozessoren ein Anschalten von FT bei aktiver oder nur bei abgeschalteter VM ermöglichen. Derzeit wird nur Intel Xeon mit 45nm-Core-2-Architektur unterstützt, um laufende VMs mit FT zu konfigurieren, bei allen anderen CPUs muss die VM vorher abgeschaltet werden. Einen kleinen Überblick über die groben Anforderungen erhalten Sie, wenn Sie im Summary des ESX-Hosts die Sprechblase hinter FaultTolerance Enabled anklicken. Neben der CPU-Kompatibilität müssen folgende Anforderungen erfüllt sein: 왘
Alle Hosts müssen mit derselben VMware ESX-Version installiert sein.
왘
Alle Hosts müssen im gleichen HA-Cluster sein.
왘
Shared Storage, da die Festplatten nicht repliziert, sondern gemeinsam genutzt werden
왘
Mindestens zwei Gigabit-Netzwerkkarten werden benötigt: eine dedizierte Karte für VMotion und eine dedizierte FT-Logging-Karte.
왘
nur eine virtuelle CPU
166
Fault-Tolerance
Abbildung 4.53
Mini-Auskunft über die FT-Anforderungen
왘
Festplatten müssen im Thick-Format sein, ansonsten werden sie konvertiert.
왘
DRS wird für die VM auf manuell umgestellt.
왘
kein Storage VMotion erlaubt
왘
Snapshots sind nicht erlaubt, und eine Anlage ist auch nicht möglich.
왘
keine Wechselmedien mit physikalischer Verbindung (nur ISO oder Client Device)
왘
Paravirtualisierung im Gast ist nicht unterstützt.
왘
Keine USB- oder Soundgeräte werden unterstützt.
왘
keine PCI-Passthrough-Unterstützung
왘
keine Unterstützung für Device-Hot-Plugging
왘
keine vlance-(AMD PCNet-)Netzwerkunterstützung
왘
RDM im virtual mode unterstützt, RDM im physical mode nicht
Abbildung 4.54
Fault-Tolerance-Firewall-Regel
167
4.4
4
Cluster
Sobald eine FT-fähige Netzwerkkarte eingerichtet ist und die CPU passt, wird automatisch eine Firewall-Regel für Fault-Tolerance auf den ESX-Servern aktiviert. Diese sollte auch nicht abgeschaltet werden.
Abbildung 4.55
Aktivierung des FT-Loggings auf einem VMkernel-Port
Neben diesen Voraussetzungen muss eine weitere Einstellung gesetzt werden, die im vCenter konfiguriert wird. Es gibt die Möglichkeit, die ESX-Hosts auf SSLZertifikate überprüfen zu lassen. Diese Einstellung müssen Sie unter der VirtualCenter Management Server Configuration einschalten.
Abbildung 4.56
Die Überprüfung des SSL-Zertifikates muss für FT aktiviert sein.
Eine recht gute Möglichkeit, die FT-Funktionalität zu prüfen, liefert VMware direkt selbst mit dem Site Survey Tool, das auch ohne FT-Lizenz auf der VMwareWebsite zum Download steht: http://www.vmware.com/download/shared_utilities.html.
168
Fault-Tolerance
Abbildung 4.57
Eine sehr ärgerliche Meldung – die CPUs sind nicht FT-kompatibel.
Außerdem ist es mittels der VMware-Maps-Funktion möglich, sich Anhaltspunkte für den FT-Aufbau und mögliche Probleme anzuschauen.
Abbildung 4.58
VMware Maps zur Anzeige vom FT-Aufbau
Berechnung des Fault Tolerance Logging Datenverkehrs Wer an der Berechnung des Fault-Tolerance-Logging-Datenverkehrs interessiert ist, sollte sich die Formel merken, mit der VMware die Datenmenge berechnet: VMware FT logging Bandbreite ~= (durchschnittliche Festplattenzugriffe (lesend) (MB/s) x 8 + durchschnittlicher Netzwerkverkehr (eingehend) (Mbps)) x 1.2 [20 % Puffer]
169
4.4
4
Cluster
4.4.3
Aktivieren von Fault-Tolerance für eine virtuelle Maschine
Sind alle technischen Vorraussetzungen erfüllt, ist das Aktivieren von FT kein großes Problem mehr. Sie müssen nur abhängig von der genutzten CPU die VM gegebenenfalls vorher abschalten.
Abbildung 4.59
Aktivierung von FT über das Kontextmenü
Über das Menü im vCenter wählen Sie eine virtuelle Maschine aus. Nach einem Klick mit der rechten Maustaste öffnet sich das Menü mit den verschiedenen Einstellungen, in dem ein Punkt Fault Tolerance heißt. Über diesen Punkt im Menü aktivieren Sie FT (Turn on Fault Tolerance). Sollte der Menüpunkt ausgegraut sein, dann liegt dies mit hoher Wahrscheinlichkeit an einem der folgenden Punkte: 왘
Die VM wird auf einem Host betrieben, der über keine FT-Lizenz verfügt.
왘
Die VM wird auf einem Host im Maintenance- oder Standby-Zustand betrieben.
왘
Die VM ist vom vCenter getrennt oder verwaist (orphaned) (.vmx-Datei ist nicht im Zugriff).
왘
Der Anwender hat keine Berechtigung, FT zu nutzen.
Abbildung 4.60
Konvertierung der bestehenden Festplatte in ein FT-fähiges Format
Danach findet direkt eine Überprüfung der VM auf Kompatibilität statt, und Thin Provisioned Disks können automatisch konvertiert und DRS kann automatisch abgeschaltet werden.
170
Fault-Tolerance
Abbildung 4.61
Automatische Anpassung der VM an die FT-Anforderungen
Nachdem die Aktivierung bestätigt wurde, erscheint im Recent Tasks-Fenster ein Task für die ausgewählte virtuelle Maschine, der Turn Fault Tolerance On heißt. Ist dieser Task abgeschlossen, wird ein weiterer Task aufgerufen, der FT startet.
Abbildung 4.62
Anzeige des FT-Status in der »Summary«-Page der VM
Im selben Zug wird das Summary-Fenster der virtuellen Maschine um ein Fault Tolerance-Fenster erweitert. Dort finden Sie verschiedene Informationen zum FT-Status dieser virtuellen Maschine. Zum Beispiel werden die Informationen angezeigt, auf welchem Host die sekundäre VM läuft und welche Latenzzeit bei der Log-Übertragung herrscht. Das bekannte Icon der primären virtuellen Maschine im Inventar des vCenters wird außerdem auf blau geändert, so dass eine FT-geschützte VM direkt erkennbar ist.
Abbildung 4.63
Anpassung des VM-Symbols nach erfolgreicher FT-Aktivierung
Schauen Sie sich die virtuellen Maschinen im Cluster an, werden Sie erkennen, dass ein weiterer Eintrag hinzugefügt wurde: Die durch FT geschützte virtuelle Maschine hat nun einen zweiten Eintrag, der durch (secondary) erweitert wird. Dies ist die sekundäre Maschine, die verwendet wird, wenn die primäre Maschine ausfällt. Die sekundäre VM ist nur in der Virtual Machines-Ansicht des Clusters oder des ESX-Hosts oder in der Ansicht VMs & Templates sichtbar.
171
4.4
4
Cluster
Abbildung 4.64
Anzeige der primären und sekundären VM
Ein schöner Test, um zu sehen, ob alles funktioniert, ist das Öffnen der Konsolen der primären und der sekundären virtuellen Maschine. Alles, was auf der Konsole der primären virtuellen Maschine ausgeführt wird, muss genauso auch auf der Konsole der sekundären virtuellen Maschine angezeigt werden. Wird zum Beispiel ein Video abgespielt, ist dies auf beiden Konsolen zu sehen. Sobald FT einwandfrei läuft, kann die primäre VM aus beliebigem Grund (mit Ausnahme des Ausfalls des Shared Storage) ausfallen, und die sekundäre VM springt in der gleichen Sekunde an und übernimmt die Funktionen der primären. Dies geschieht ohne Ausfall und ohne Datenverlust.
4.4.4
Bedienung von Fault-Tolerance für eine virtuelle Maschine
Sobald Fault-Tolerance für eine oder mehrere VMs aktiviert ist, existiert ein neues Kontextmenü mit deutlich mehr Menüpunkten zur Verwaltung von FaultTolerance.
Abbildung 4.65
Kontextmenü bei aktivierter Fault-Tolerance
Option
Beschreibung
Turn Off Fault Tolerance
Abschalten von FT mit Löschung aller FT-Statistikdaten
Disable Fault Tolerance
vorübergehendes Abschalten von FT mit Beibehaltung aller FT-Statistikdaten
Tabelle 4.7
172
Optionen zur Verwaltung von Fault-Tolerance
Fault-Tolerance
Option
Beschreibung
Migrate Secondary
Migration des sekundären Knotens auf einen anderen ESX-Host
Test Failover
FT-Umschaltung vom primären auf den sekundären Knoten testen
Test Restart Secondary
Neustart des sekundären Knotens
Tabelle 4.7
4.4.5
Optionen zur Verwaltung von Fault-Tolerance (Forts.)
Snapshots und Storage VMotion mit FT
Da mit FT geschützte VMs nicht gleichzeitig über Snapshots verfügen dürfen, ist weder eine Sicherung mit VCB (Consolidated Backup) oder anderen Sicherungsprogrammen außerhalb des Gastes möglich noch ein Storage VMotion. Um dies doch zu ermöglichen, ist es notwendig, FT temporär während der Aktivitäten mit Snapshot abzuschalten. Dies führen Sie idealerweise mit dem Menüeintrag Disable Fault Tolerance durch und aktivieren FT wieder, nachdem alle Snapshots gelöscht wurden. Ein PowerShell-Beispiel zur Aktivierung und Deaktivierung von FT: Aktivierung: Get-VM VM1 | Get-View | % { $_.CreateSecondaryVM($null) }
Turn Off: Get-VM VM1 | Select -First 1 | Get-View | % { $_.TurnOffFaultToleranceForVM() }
Disable FT: Get-VM VM1 | Select -First 1 | Get-View | % { $_.DisableSecondaryVM(get-vm "secondary VM") }
Enable FT: Get-VM VM1 | Select -First 1 | Get-View | % { $_.EnableSecondaryVM(get-vm "secondary VM") }
173
4.4
4
Cluster
4.4.6
Was passiert im Fehlerfall?
Ausfall
Aktion
Teilausfall Host (z. B. Fibre-Channel-Ausfall – kein Zugriff auf den Storage) des primären Hosts
Fault-Tolerance schaltet auf sekundäre VM um.
Komplettausfall primärer Host
Fault-Tolerance schaltet auf sekundäre VM um.
Ausfall der Hosts, auf denen primärer und VMware HA startet den primären Knoten, sekundärer Knoten laufen und der sekundäre wird durch VMware FT gestartet. Softwarefehler (Kernel-Panic, Bluescreen) VM Monitoring (VMHA) erkennt den Ausauf primärem Knoten fall aufgrund des fehlenden VMware Tools Heartbeat und startet den primären Knoten neu. Der sekundäre Knoten wird mit dem primären durch FT neu gestartet. Split-Brain-Situation da primärer und Renaming (Umbenennen einer Datei im sekundärer Knoten sich nicht mehr sehen Shared Storage) wird von einer VM (Netzwerkfehler) »gewonnen«, die andere schaltet sich selbst ab. Primäre VM wird suspendiert
Sekundäre VM wird ausgeschaltet.
Reset der primären VM (Hart)
Sekundäre VM wird beim Reset ausgeschaltet und beim Neustart des primären Knotens durch einen angepassten VMotion-Prozess erstellt.
Restart Guest der primären VM (Soft)
Primäre und sekundäre VM führen einen Neustart ohne Abschaltung durch.
Tabelle 4.8
4.4.7
Was passiert im FT-Fehlerfall?
Lizenzierung von FT
VMwares Fault-Tolerance ist Bestandteil der vSphere Suite, die auf CPU-SockelBasis lizenziert wird und ab der Edition Advanced integriert ist.
174
Das folgende Kapitel beschäftigt sich mit der Installation der verschiedenen Softwarekomponenten von VMware vSphere 4.0. Hier wird nicht nur die Standardinstallation erklärt, sondern auch Installationen in DAS- und SAN-Umgebungen.
5
Installation Autor dieses Kapitels ist Betram Wöhrmann, Ligarion, [email protected]
Auch wenn die Installation der einzelnen VMware-Komponenten an sich nicht kompliziert und aufwendig ist, möchten wir doch auf die einzelnen Schritte genauer eingehen, damit Sie wissen, worauf Sie besonders achten müssen. Dabei beginnen wir mit der Vollversion ESX zunächst auf DAS-Systemen und im Anschluss daran beschäftigen wir uns mit Installationen im SAN. Nach der abgespeckten Version, dem ESXi, widmen wir uns dann dem vCenter-Server.
5.1
VMware vSphere 4.0
Die Version VMware vSphere 4.0 ist der Vorgängerversion 3.x immer noch sehr ähnlich, die Service Console ist nach wie vor komplett vorhanden und mit ihr sämtliche bekannten Patch-Orgien und Sicherheitseinstellungen. Die Neuerung an dieser Stelle ist, dass die Service Console nun eine eigene virtuelle Maschine ist, die auch auf einem lokalen VMFS-Datastore liegen muss. Allerdings bedeutet dies auch, dass nach wie vor Backup- und Managementsoftware, die über die Service Console betrieben wird, funktioniert. Die Service Console selbst basiert weiterhin auf einem optimierten Red Hat Enterprise Linux.
5.1.1
VMware-vSphere-Systemvoraussetzungen
Die genauen Systemvoraussetzungen finden Sie in den Hardware Compatibility Guides auf der VMware-Website.
175
5
Installation
VMware vSphere Server 4i Embedded Edition (OEM Edition) and VMware vCenter Server 4.0: http://www.vmware.com/support/pubs/vs_pages/vsp_pubs_ esxi40_e_vc40.html VMware vSphere Server 4i Installable Edition and VMware vCenter Server 4.0: http://www.vmware.com/support/pubs/vs_pages/vsp_pubs_esxi40_i_vc40.html VMware vSphere Server 4.0 and vCenter Server 4.0: http://www.vmware.com/ support/pubs/vs_pages/vsp_pubs_esx40_vc40.html Die Kompatibilitätslisten, d. h. die Auflistungen der durch VMware unterstützten Hardware und Software sind in mehrere Gruppen untergliedert: Systeme, I/OKomponenten und Storage/SAN (Abbildung 5.1).
Abbildung 5.1
176
VMware-VI-Kompatibilitätsguides
VMware vSphere 4.0
VMware hat eine separate Website aufgebaut, um die Überprüfung der Kompatibilität von Komponenten zu ermöglichen. Hier können Sie nach einzelnen Systemen oder Systemkomponenten suchen. Wem es aufgrund der zu suchenden Komponenten zu umständlich ist, in der Webapplikation zu suchen, für den gibt es auch die Möglichkeit, sich entsprechende Dokumente herunterzuladen. Systems Compatibility Guide enthält die unterstützten Server-Komplettsysteme gegliedert nach den Herstellern und den zertifizierten VMware-Versionen. http://www.vmware.com/resources/compatibility/get_pdf.php? deviceCategory=server I/O Compatibility Guide enthält die unterstützten Netzwerk- und Massenspeicher-Adapter, gegliedert nach Netzwerk/Storage, Hersteller und zertifizierter VMware-Version. http://www.vmware.com/resources/compatibility/search.php?action=base& deviceCategory=io Storage/SAN Compatibility Guide enthält die unterstützten Massenspeichersysteme, gegliedert nach Typ (Fibre-Channel, iSCSI, NAS, SAS), Hersteller und zertifizierter VMware-Version. http://www.vmware.com/resources/compatibility/search.php?action=base& deviceCategory=san Guest Operating System Installation Guide enthält die unterstützten Gastbetriebssysteme und Installationsanweisungen, wie die Systeme zu installieren bzw. konfigurieren sind. http://www.vmware.com/pdf/GuestOS_guide.pdf VMware VMotion and CPU Compatibility bietet Informationen über die VMotion-Fähigkeit der unterschiedlichen CPU-Typen. http://www.vmware.com/files/pdf/vmotion_info_guide.pdf vSphere Compatibility Matrixes zeigt eine Tabelle, die beschreibt, welche VMware-Versionen miteinander kompatibel sind. http://www.vmware.com/pdf/vsphere4/r40/vsp_compatibility_matrix.pdf
5.1.2
Download der Installationsmedien
Die Installationsdateien von VMware vSphere 4.0 finden Sie auf der Website www.vmware.com unter dem Link Download.
177
5.1
5
Installation
In der Download-Sektion befinden sich die unterschiedlichen VMware-Produkte inklusive Versionsstände. Hier ist die VMware-Infrastruktur auszuwählen und danach die Version 4.0. Nach erfolgreicher Anmeldung befinden Sie sich auf der eigentlichen DownloadSeite mit den Einzelkomponenten inklusive Download-Link (Abbildung 5.2).
Abbildung 5.2
Download-Sektion Komponenten VMware vSphere 4.0
Auf der Webseite ist nun die Version auszuwählen, die installiert werden soll. Klicken Sie einfach vor der entsprechenden Version auf das Symbol +, und die passenden Download-Links werden angezeigt. Das DVD-Image dient sowohl zum Offline-Upgrade als auch zur Neuinstallation eines vSphere-Servers.
178
VMware vSphere 4.0
Generell sollten Sie jede heruntergeladene Datei auf die MD5-Checksumme prüfen, da es immer wieder zu Übertragungsfehlern kommt, die zu sehr unschönen Effekten wie einer fehlerhaften Installation führen (Abbildung 5.3). Unter jedem Download-Link finden Sie die Checksummen zum Überprüfen der Datei. Seit der neuen Version sehen Sie an dieser Stelle nicht nur eine MD5-, sondern auch eine SHA1-Checksumme. Kostenfreie Programme zum MD5- bzw. SHA1-Checksummen-Test finden Sie mit Google wie Sand am Meer. Zwei recht empfehlenswerte MD5 Programme, die gerne genutzt werden, sind: 왘
Windows Md5 Checksum Tool (http://ferruh.mavituna.com/md5-checksum/ md5checksum-setup.exe)
왘
winMd5Sum (http://www.nullriver.com/index/products/winmd5sum )
Abbildung 5.3
MD5-Checksummen-Vergleich mit winMd5Sum
Nach dem Test auf Integrität des Installationsmediums nutzen Sie das ISO-DVDImage entweder auf eine DVD gebrannt oder über Softwareverteilungstools. DVD-Emulationsprogramme auf Server-Seite (z. B. HP iLO) können zur Anwendung kommen, um die Medien direkt zu nutzen. Alternativ besitzen Sie bereits eine Original-DVD von VMware, die auf dem aktuellsten Stand ist.
5.1.3
Vor der Installation
Vor der Installation sollten Sie unbedingt folgende Hinweise beachten. Einrichten der Hardware Bevor Sie beginnen, die Server aufzusetzen, müssen Sie die Hardware dafür konfigurieren. Die Hardwarehersteller haben Vorgaben, damit der vSphere-Server auch die volle Leistungsfähigkeit ausspielen kann. Dazu sind im BIOS einige Einstellungen vorzunehmen. Auf jeden Fall ist die Prozessorvirtualisierung zu akti-
179
5.1
5
Installation
vieren. Je nach CPU-Typ sehen die Empfehlungen von HP für ihre Server wie folgt aus: AMD-CPU: 왘
Server Availability 폷 ASR Status deaktivieren
왘
Advanced Options 폷 Processor Options 폷 AMD Virtualisation aktivieren
왘
Advanced Options 폷 MPS table mode auf Full table APIC setzen
왘
Advanced Options 폷 Processor Options 폷 no-Execute Page-Protection aktivieren
Intel-CPU: 왘
Server Availability 폷 ASR Status deaktivieren
왘
System Options 폷 Processor Options 폷 Intel® Virtualization Technology aktivieren
왘
Advanced Options 폷 MPS table mode auf Full table APIC setzen
왘
System Options 폷 Processor Options 폷 no-execute memory protection aktivieren
Keine SAN-Verbindung Außer bei Boot-from-SAN sollte der vSphere-Server während der Installation keine Verbindung zum SAN und zum zentralen Speicher haben. Dies ist empfohlene Praxis und dient zur eigenen Sicherheit, damit nicht ungewollt Formatierungen erfolgen. Während der Installationsroutine werden bei der Partitionierung ausgewählte LUNs formatiert, unabhängig von den Daten! Die Auswahl einer falschen LUN ist leider viel zu schnell passiert! Sie müssen allerdings nicht zwingend die FC- oder Ethernet-Kabel ziehen, ein Abschalten der Ports oder Aufheben der Zuordnung am Speichersystem genügt in den meisten Fällen.
5.1.4
Abschalten Host-Bus-Adapter (HBA)-TreiberInstallationsmedium
Die Anaconda-Installationsroutine liest alle eingebauten Geräte aus. Bei positiver Erkennung werden die zugehörigen Gerätetreiber geladen. Während der normalen VMware-vSphere-Installation (Ausnahme Boot-from-SAN oder Boot-fromiSCSI) ist das Laden der HBA-Treiber (Fibre-Channel- und iSCSI-Controller) allerdings eher hinderlich als nützlich, da es sehr schnell zu einer versehentlichen Datenlöschung auf den gefundenen Festplatten kommt. Daher wird auch das
180
VMware vSphere 4.0
Entfernen der Anschlusskabel von den FC- und iSCSI-HBAs während der Installation empfohlen. Alternativ erstellen Sie selbst eine DVD, die die Fibre-Channel-Karten-Treiber im Bereich der Installation deaktiviert. Das Einzige, was Sie benötigen, ist ein Unixoder Linux-System und ein Skript, das für Sie die Treiber aus der Installationsroutine entfernt. Dieses Skript können Sie aus dem Internet herunterladen, und zwar unter der URL: www.vmachine.de/content/vSphere_removehba_V1.1.sh. Wir möchten jetzt nicht auf alle Details eingehen, aber grob gesagt wird die Installationsroutine so geändert, dass die FC-Karten-Treiber während der Installation nicht geladen werden. Erst nach dem abschließenden Reboot werden die Treiber für die installierten FC-Karten geladen, und somit werden auch erst jetzt die gezoneten LUNs für das System sichtbar. Das Skript ist mit der folgenden Syntax aufzurufen: vSphere_removehba_V1.1.sh . Denken Sie daran, dass das Entfernen der FC-Kabel natürlich nur sinnvoll ist, wenn es ein unterstütztes lokales Medium gibt, auf dem die Software installiert werden kann. Wird vom SAN gebootet, ist die selbsterstellte DVD keine Option. Es bleibt dem Installateur natürlich freigestellt, die Kabel während der Installation zu entfernen oder das Zoning während der Installation zu ändern.
5.1.5
Lokale Installation
Zur lokalen Installation müssen Sie entweder die VMware-vSphere-4.0-Installations-DVD im Server-System einlegen oder mittels Emulation (Virtual Media – HP iLO, Dell DRAC …) dem Server bekannt machen. Sehr wichtig ist hier die passende Kombination aus Firmware-, Java- und ActiveX-Version. Die entsprechenden Informationen sind Tabelle 5.1 zu entnehmen. Remote-Controller
Firmware
Java-Version
ActiveX-Version
DRAC 5
1.4
nicht geeignet
1.4.2_19
1.45 (08.10.06)
2.1.0.14
1.6.0.50
1.40 (08.08.22)
2.1.0.14
1.6.0.11
1.20 (07.03.02)
1.4.2_06
2.1.0.13
1.33
1.6.0_07
2.1.0.14
1.32 (07.12.22)
1.4.2_13
2.1.0.13
1.0 (06.05.12)
1.4.2_13
2.1.0.13
1.32
1.6.0_11
2.1.0.14
Tabelle 5.1
Remote-Controller-Firmware-Versionen
181
5.1
5
Installation
Remote-Controller
Firmware
Java-Version
ActiveX-Version
1.2
1.6.0_11
2.1.0.14
1.45 (09.01.16)
1.6.0_11
2.1.0.14
1.3
1.6.0_11
2.1.0.14
1.33
1.6.0_11
2.1.0.13
DRAC 4
1.7
1.4.2_06
2.1.0.14
ILO
1.26
1.6.0_11
2.1.0.14
1.7
1.4.2_19
nicht geeignet
1.91
1.6.0_07
2.1.0.14
1.29
1.4.2_13
nicht geeignet
1.09
1.6.0_11
2.1.0.14
1.09
1.6.0_11
2.1.0.14
ILO2
RSA
Tabelle 5.1
Remote-Controller-Firmware-Versionen (Forts.)
Da während der Installation nach den Netzwerkangaben und der Partitionierung des Servers gefragt wird, sollten diese Informationen bereits vorliegen. Außerdem sollte bekannt sein, welche der internen Netzwerkkarten für die ServiceConsolen-Verbindung verwendet werden soll. Als zusätzliche Voraussetzung muss die Uhr im BIOS auf UTC-Zeit gesetzt werden. Die Anpassung an die entsprechende Zeitzone erfolgt dann während der Installationsprozedur. Zu den Netzwerkangaben zählen: 왘
IP-Adresse (oder DHCP)
왘
Subnetzmaske
왘
Gateway
왘
erster und zweiter DNS-Server
왘
Hostname (inklusive Domänenzusatz, z. B. esx1.intern.test)
왘
VLAN-ID (falls der Service-Console-Port ein Trunk-Port ist)
PCI-ID-Plan Sollte der Server über sehr viele Netzwerkkarten verfügen, ist ein PCI–ID-Plan des Server-Systems (PCI-ID = PCI-Nummer von Geräten in PCI-Slots) sehr hilfreich. Es wird nach einer Netzwerkkarte als Uplink für den virtuellen Switch gefragt, der zur Nutzung durch die Service-Console-Port-Group dient.
182
VMware vSphere 4.0
Dual- oder Quad-Port-Karten identifizieren Sie leicht durch die gleichen Anfangszahlen der PCI-ID (siehe Abbildung 5.4).
Abbildung 5.4
Quad-Port-Netzwerkkarte-PCI-IDs aus der esxcfg-nics –l-Sicht
Natürlich sollten Sie auch ein root-Passwort zur Hand haben. Alle benötigten Angaben sind jetzt vorhanden, und die Installation kann beginnen. Die DVD bootet direkt in ein Grub-Bootmenü, das den Anaconda-Installer startet. Beide Programme sind Linux-Benutzern, vor allem im Red-Hat-Umfeld, sehr geläufig. Vor allem bei der automatisierten Installation können sie daher von diesen Kenntnissen Gebrauch machen. Die meisten Anaconda-/KickstartMöglichkeiten stehen auch bei der VMware-vSphere-Installation bereit. Das Bootmenü bietet sechs verschiedene Auswahlmöglichkeiten (Abbildung 5.5), der erste und der zweite Menüpunkt sind selbsterklärend. Hier nehmen Sie die Installation entweder über ein grafisches Interface oder über die Kommandozeile vor. Der dritte Punkt gibt dem Installateur die Möglichkeit, die Installation mit einem Skript durchzuführen und von einer lokalen oder von einer entfernten Installationsquelle zu starten, wie z. B. FTP, HTTP, HTTPS oder NFS, nicht zu verwechseln mit einer kompletten Installation über das Netzwerk.
Abbildung 5.5
Bootmenü der VMware-vSphere-DVD
Der Menüpunkt ESX Scripted Install to first disk führt eine Installation mit dem vSphere-Standard-Konfigurationsskript ks-first-safe.cfg durch. Der folgende
183
5.1
5
Installation
Menüpunkt, ESX Scripted Install to first disk (overwrite VMFS), nutzt das Skript ks-first.cfg. #root Password rootpw --iscrypted $1$MpéRëÈíÌ$n9sgFQJweS1PeSBpqRRu.. # Authconfig authconfig --enableshadow --enablemd5 # BootLoader (Use grub by default.) bootloader --location=mbr # Timezone timezone America/Los_Angeles --utc #Install install cdrom #Network install type network --device=MAC_address --bootproto=dhcp #Keyboard keyboard us #Reboot after install? reboot # Clear partitions clearpart --firstdisk # Partitioning part /boot --fstype=ext3 --size= --onfirstdisk part storage1 --fstype=vmfs3 --size=10000 --grow --onfirstdisk part None --fstype=vmkcore --size=100 --onfirstdisk # Create the vmdk on the cos vmfs partition. virtualdisk cos --size=5000 --onvmfs=storage1 # Partition the virtual disk. part / --fstype=ext3 --size=0 --grow --onvirtualdisk=cos part swap --fstype=swap --size=256 --onvirtualdisk=cos #VMware Specific Commands accepteula serialnum --esx=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX Listing 5.1
»ks-first.cfg«
Das Passwort wird bei der Installation mit dem Skript auf mypassword gesetzt. Nach erfolgter Installation muss die weitergehende Konfiguration mit dem vSphere-Client vorgenommen werden. Der Unterschied zwischen den beiden Menüpunkten erklärt sich von allein. Während der zuerst beschriebene Aufruf eine Basisinstallation durchführt, ohne eine eventuell vorhandene VMFS-Partition zu formatieren, führt der fünfte
184
VMware vSphere 4.0
Menüpunkt eine Basisinstallation mit Partitionierung vorhandener VMFS-Partitionen durch. Der letzte Menüpunkt bricht die Installation ab und führt einen Systemstart von der Festplatte durch. Gehen wir nun die Standardschritte für die Installation durch: 왘
Die EULA (Lizenzbestimmungen) ist zu akzeptieren
왘
Als Tastaturlayout kommt meist U.S. English oder German (latin1) zum Einsatz
왘
Custom Drivers sind nur an dieser Stelle einzubinden. Später ist das Einbinden von Treibern dieser Art nicht mehr möglich.
왘
Laden der von VMware bereitgestellten Treiber
왘
Eingabe der Seriennummer
왘
Auswahl der Netzwerkkarte für die Service Console
왘
Eintrag Netzwerkparameter Service Console
왘
Auswahl des Installationstyps, Standard oder Advanced. Bei der StandardVariante wird mit einer Festplatte oder einer LUN nach Standardvorgaben partitioniert. Bei der Auswahl Advanced hat der Installateur die Möglichkeit, nach Best Practices die Partitionierung vorzunehmen.
왘
Partitionierung
왘
Zeitzone (meist Europe/Berlin und UTC)
왘
Konfiguration von NTP-Server oder manuelles Einstellen von Datum und Uhrzeit
왘
Einrichtung von root-Passwort und zusätzlichen Accounts
Während die meisten dieser Installationsschritte selbsterklärend sind, möchten wir auf die Punkte Custom Drivers, Netzwerkparameter Service Console und Partitionierung näher eingehen. Custom Drivers Die Auswahl Custom Drivers während der Installation ist neu. Unter den Vorgängerversionen von VMware vSphere existierte dieser Punkt nicht. Hier gibt VMware dem Installateur die Möglichkeit, Treiber einzubinden, die nicht von VMware, sondern vom Hardwarehersteller zur Verfügung gestellt werden (Abbildung 5.6). In diesem Fall ist der Hardwarehersteller dafür verantwortlich, passende Treiber zu liefern. Diese Treiber können nur während der grafischen-, der Textmode- oder der geskripteten Installation eingebunden werden. Führen
185
5.1
5
Installation
Sie die Installation über ein PXE-Environment durch, haben Sie nicht die Möglichkeit, die Treiber einzubinden. Dieser Vorgang unterstützt nur das Einbinden von Storage- oder Netzwerk-Treibern. Wichtig ist an der Stelle, dass Sie den Support für die Umgebung aufsplitten. Sobald Sie Treiber einbinden, für die VMware nicht verantwortlich ist, haben Sie im Fehlerfall unter Umständen mehrere Ansprechpartner.
Abbildung 5.6
Einbinden von Third-Party-Treibern
Netzwerkparameter Ein weiterer wichtiger Installationsschritt ist die Eingabe der Netzwerkparameter. Alle Angaben sollten Sie zum Zeitpunkt der Installation in Händen (oder am Bildschirm zugänglich) haben, um nicht unnötig Zeit zu verlieren. Die Abfrage nach einer Netzwerkkarte betrifft die Uplink-Einstellung des ersten virtuellen Switches vSwitch0, der automatisch bei der Installation angelegt und der Service-Console-Port-Group zugeordnet wird (Abbildung 5.7). Da dieser Anschluss bei vorhandenem Managementnetz auch sehr oft mit diesem verbunden wird, sollten Sie genau wissen, welche Netzwerkkarte der Service Console zugeordnet werden soll. Es ist zwar aus VMware-Sicht relativ problemlos eine spätere Anpassung möglich, allerdings kann dies je nach organisatorischem Ablauf (Netzwerkzugriff, Verantwortungsbereiche …) einen Zeitverzug mit sich bringen.
186
VMware vSphere 4.0
Abbildung 5.7
Auswahl der Service-Console-Netzwerkkarte
Die Netzwerkkarte wählen Sie anhand des Modells und der PCI-ID aus, was vor allem bei gleichen Modellen zum Problem werden kann. Wird an dem ausgewählten Anschluss eine VLAN-ID zur Verfügung gestellt, ist diese ID in das entsprechende Feld einzutragen, nachdem die Auswahl aktiviert worden ist. Nach Abschluss der Konfiguration finden Sie einen Bildschirminhalt wie in Abbildung 5.8 gezeigt vor.
Abbildung 5.8
Beispiel einer ausgefüllten Netzwerkkonfiguration
187
5.1
5
Installation
Partitionierung Die Partitionierung in der neuen Version von VMware vSphere 4.0 unterscheidet sich erheblich von der Vorgängerversion. Ab diesem Release ist es so, dass die Service Console eine komplett eigene virtuelle Maschine ist, die aber weiterhin die bekannten Funktionen zur Verfügung stellt. Daraus ergibt sich eine zweigeteilte Partitionierung. Zum Ersten muss die Partitionierung für den Hypervisor durchgeführt werden und zum Zweiten für die Service Console. Nun wählen Sie den Installationsmodus (Abbildung 5.9).
Abbildung 5.9
Auswahl der Installation, Standard oder Advanced
Entscheiden Sie sich für das Standard-Setup, können Sie nur das Laufwerk auswählen. Weitere Anpassungen an der Unterteilung der Festplatte sind bei dieser Installationsart nicht möglich. Beim Advanced-Modus besteht die Möglichkeit, die Partitionierung der Service Console anzupassen. Eine Manipulation der Partitionen für den Hypervisor ist nicht möglich. Hier werden nur die Partitionen /boot und vmkcore angelegt, und Sie können deren Größe nicht manipulieren, jedenfalls nicht bei der grafischen und der textbasierten Installation. Lediglich bei der skriptbasierten Installation ist eine Manipulation der Hypervisor-Partitionen möglich. Zuerst wählen Sie das Ziellaufwerk für die vSphere-Installation (Abbildung 5.10). Nach erfolgter Auswahl besteht die Möglichkeit, den entsprechenden Storage umzubenennen, was wir auch auf jeden Fall empfehlen. Bewährt hat sich eine Kombination der folgenden Art: <Server-Name>-local (Abbildung 5.12).
188
VMware vSphere 4.0
Abbildung 5.10
Auswahl des Storage für die Installation
Abbildung 5.11
Datastore für die Service Console
Jetzt beginnt die eigentliche logische Partitionierung der Service Console. Fragt man zehn Administratoren nach der empfohlenen Partitionierung, kann man durchaus mit mehreren verschiedenen Antworten rechnen. Daher ist die folgende Partitionierung ein Vorschlag, der sich bei den Kundensystemen der Autoren bewährt hat.
189
5.1
5
Installation
Mountpoint
Datei- Größe MB system
Fixed Type Size
Swap
swap
1.024-1.600
ja
vdisk in a Swap Partition Service VMFS Volume Console. Größe 2 × Service-Console-RAM
/
ext3
5.120
ja
vdisk in a Haupt-BetriebssystemVMFS Volume Partition
/tmp
ext3
5.120
ja
vdisk in a temporäre Dateien, VMFS Volume z. B. Patches
/var/log
ext3
2.048
ja
vdisk in a Protokolldateien allgeVMFS Volume mein; wird automatisch angelegt.
/usr
ext3
2.048
ja
vdisk in a Programmdateien und VMFS Volume Daten
/opt
ext3
2.048
ja
vdisk in a Protokolldateien VMFS Volume VMware-HA-Agent
Tabelle 5.2
Beschreibung
VMware-vSphere-Partitionierung der Service Console
In Abbildung 5.12 ist zu sehen, wie die einzelnen Partitionen gelöscht oder angepasst werden. Achten Sie darauf, dass die Größe der Zielplatte nicht überschritten wird.
Abbildung 5.12
190
Partitionseditor während der Installation
VMware vSphere 4.0
Das Ergebnis unseres Partitionierungsvorschlags sieht in der Realität wie in Abbildung 5.13 aus.
Abbildung 5.13
Abgeschlossene Partitionierung
Korrekturen Physisch durchgeführt werden alle Partitionierungen und Formatierungen erst zu Beginn der Installation, nach der Einstellungszusammenfassung. Wenn Sie einen Fehler gemacht haben oder unsicher sind, können Sie daher zuvor jederzeit abbrechen oder mit dem Back-Knopf zu den vorherigen Installationsschritten zurückwechseln.
Ist die Installation abgeschlossen, finden Sie auf dem Host im Verzeichnis /root/ die Datei ks.cfg. Diese Datei wird automatisch während der Installation erstellt und enthält die gesamte vom Installateur parametrierte Konfiguration. Mit diesem File können Sie den Host identisch und voll skriptgesteuert erneut installieren, oder Sie passen die veränderlichen Parameter an und installieren einen weiteren Host mit dem Skript.
5.1.6
Installation über das Netzwerk
Sie können den vSphere-Server auch über das Netzwerk installieren. Um diese Möglichkeit zu nutzen, benötigen Sie ein Preboot Execution Environment (PXE). Diese Umgebung besteht aus einem DHCP-(Dynamic Host Configuration Proto-
191
5.1
5
Installation
col-)Server einem TFTP-(Trivial File Transfer Protocol-)Server und einem BootEnvironment. Bootet ein Server via PXE, wird ihm eine gültige IP-Adresse zugewiesen; über den TFTP wird das Bootmenü auf den Host transferiert. Ist der Transfervorgang abgeschlossen, wird der Kernel geladen und eine RAM-Disk angelegt. Wählen Sie das Installationsskript, und sprechen Sie das Installationsmedium über das Netzwerk an. Die Installation kann, wie beschrieben, automatisch mit einem Skript laufen, oder Sie führen sie manuell durch. Die Vorgehensweise ist weitestgehend so, wie wir es bereits im vorhergehenden Abschnitt beschrieben haben. Es gibt auch verschiedene Installationstools, die es dem Administrator ermöglichen, eine Konfiguration individuell einzurichten und automatisiert zu starten, so z. B. das Rapid Deployment Pack von HP, der Softservice Installer der Firma Softservice oder die ESX Deployment Appliance (eda).
5.1.7
Installation im SAN
Ein sehr wichtiger Arbeitsschritt vor jeglicher Nutzung von Server-Systemen im SAN ist die Überprüfung des HBA-Controllers auf Firmware- und gegebenenfalls BIOS-Aktualität. Dazu können Sie in den Fällen Emulex und QLogic entweder ein Kommandozeilenprogramm oder ein zentrales grafisches Programm nutzen. Letzteres ist zusätzlich in der Lage, über das Netzwerk auf die HBAs in den Server-Systemen zuzugreifen. In jedem Fall müssen Sie aber eine Software in der Service Console des vSphereServers installieren. Beim Kommandozeilentool beschränkt sich dies auf ein »normales« Programm, das durch den Administrator gestartet und nach getaner Arbeit beendet wird. Bei der Netzwerkverwaltung müssen Sie einen lokalen Dämonprozess starten und alle auf dem Netzwerkweg liegenden Firewalls für die entsprechenden Ports freischalten. Dies ist zum einen ein Sicherheitsrisiko, zum anderen sind jegliche Programme und Tools in der Service Console eine Gefahr, die das Gesamtsystem instabil machen können. Außerdem sind diese Tools für den VMware-Support oft ein Grund, Probleme in dieser Richtung zu suchen oder die Unterstützung abzulehnen, bis das System ohne diese Programme neu installiert wurde. Daher die dringende Empfehlung, die Tools nur dann in der Service Console zu installieren und vor allem zu starten, wenn Sie sie wirklich benötigen. Für die Autoren des Buches sind die Kommandozeilenprogramme aber gegenüber den »dauerhaften« Dämonprozessen zu bevorzugen.
192
VMware vSphere 4.0
Achtung bei Installation und Konfiguration über die Service Console Führen Sie niemals Programminstallationen oder Hardwarekonfigurationen über die Service Console aus, wenn auf den Systemen noch aktive virtuelle Maschinen betrieben werden. Selbst das Anschließen einer fehlerhaft formatierten USB-Festplatte führt im schlimmsten Fall zum Komplettausfall des vSphere-Servers. Aktivieren Sie lieber einmal mehr den Maintenance-Modus, und verschieben Sie dadurch mit VMotion die aktiven virtuellen Maschinen auf andere Hostsysteme, bevor Sie die Arbeiten durchführen.
Einschränkungen Leider bietet eine Systeminstallation im Speichernetzwerk nicht nur Vorteile, sondern auch Einschränkungen. Allerdings werden die Einschränkungen mit jeder VMware-ESX-Version immer geringer. Konnte man unter VMware ESX 2.x keine Raw-Device-Mappings (RDM), also »Direktverbindungen« der VM zu einer LUN, in Verbindung mit SAN-Boot nutzen, ist dies seit der Version 3 kein Problem mehr. Gleiches gilt für die LUNNummerierung. Mittlerweile kann von jeder LUN-Nummer unterhalb 128 gebootet werden. Auch die Einschränkung, dass immer nur von der niedrigsten LUN-ID gestartet werden kann, ist entfallen (bei LUNs 5, 6, 7 konnte nur von 5 gebootet werden). Allerdings sollten Sie im Interesse der Übersichtlichkeit und Verwaltung darauf verzichten, Boot-on-SAN-LUNs bunt zu nummerieren. Aktuell sind jedoch noch Einschränkungen in Verbindung mit Cluster-Programmen wie Microsoft oder Veritas vorhanden, das heißt, bei SAN-Boot wird kein VM-Clustering unterstützt. Zu umgehen ist diese Einschränkung leider nur durch die Nutzung lokaler Festplatten für die virtuellen Maschinen. Soll aus dem SAN gebootet werden, müssen Sie weiterhin darauf achten, dass der vSphere-Server während der Installationsphase nur die ersten 128 LUNs erkennen kann (nach der Installation sind es insgesamt 256 LUNs). Aus Hardwaresicht bestehen derzeit noch Probleme bei manchen Systemen mit internen IDE-Festplatten (z. B. IBM-Blades), die im BIOS deaktiviert werden müssen. Aus Performance-Gründen bietet es sich außerdem an, den HBA, von dem gebootet wird, möglichst hoch am PCI-Bus (PCI-ID) anzusiedeln. Boot-on-SAN Die Möglichkeit der Installation und des Starts des vSphere-Servers im bzw. aus dem SAN wurde hauptsächlich durch die Verbreitung von Blade-Servern forciert,
193
5.1
5
Installation
da diese oft über keine lokalen Festplatten verfügen. Neben der Nutzung plattenloser Systeme bietet die Boot-on-SAN-Alternative einen weiteren Vorteil im Bezug auf Ausfallsicherheit: Blade-Server sind in vielen Fällen modellgleich, das heißt, eine identische Hardwaregrundlage ist vorhanden. Fällt ein Blade aus, können Sie durch einfaches Umsetzen der Boot-LUN im SAN ein anderes Blade mit identischer Konfiguration neu starten. Dadurch wird die Neuinstallation und Konfiguration bei Hardwareausfällen nichtig. Auch Replikationen oder Spiegelung und Sicherung der Systempartition ist somit sehr einfach, da alles im SAN passieren kann. Eine Installation bzw. der Start des vSphere-Servers von zentralem (oder nichtlokalem) Speicherplatz setzt einen bootfähigen und zertifizierten Fibre-Channeloder iSCSI-HBA (Host-Bus-Adapter) voraus. Allerdings sollten Sie im Idealfall die LUN-ID 0 für die Bootfestplattenzuordnung wählen. Wählen Sie eine andere Boot-LUN-ID, sollten Sie sich diesen Bereich gut merken, um später keine versehentlichen Formatierungen durchzuführen. Zugriff beim Mapping der LUN Beim Mapping der LUN (Zuordnung Host WWN/iSCSI Name <-> Storage LUN in der Speicherverwaltung) sollten Sie nur dem einen Host den Zugriff gestatten, der auch von der LUN bootet!
Nach entsprechender LUN-Anlage und dem Mapping können Sie den vSphereServer mit der VMware-vSphere-Installations-DVD starten. Bei der Auswahl von Bootloader und zu partitionierender Festplatte müssen Sie die entsprechende LUN auswählen (im Idealfall LUN 0). Fibre-Channel-HBAs und Boot-on-SAN Bereits vor der Anpassung der Fibre-Channel-HBAs (Firmware Update, Bootkonfiguration) kann die Installation stattfinden. Allerdings ist dies Geschmackssache. Der große Unterschied zwischen dem lokalen Boot und dem SAN-Boot besteht aus Sicht der Installationsroutine nur in der zugeordneten System- und Installationspartition. Daher muss der HBA die LUNs bereits vor dem Boot der vSphereDVD sehen. Bei der Plattenauswahl wird die LUN dann angewählt. Nach erfolgter Installation müssen Sie den Server allerdings vom lokalen Boot auf den Boot mittels HBA umkonfigurieren, was wir in den folgenden Zeilen beschreiben. Bevor Sie über die Einrichtung von Boot-on-SAN nachdenken, sollten Sie auf jeden Fall kontrollieren, ob die aktuelle Firmware auf dem Host-Bus-Adapter ein-
194
VMware vSphere 4.0
gespielt ist. Falls nicht, sollten Sie dies zuerst nachholen. Außerdem bieten die Hersteller Anleitungen an, wie der HBA als Boot eingerichtet wird. In diesem Abschnitt konfigurieren wir als Beispiel einen Emulex-FC- und einen QLogiciSCSI-HBA. Beispiel Emulex LP10000DC Um den aktuellen Firmwarestand des Adapters auszulesen, benötigen Sie die lpfcutil-Software. Zum Ausführen der lpfcutil-Software muss bereits ein laufendes System bereitstehen. Alternativ nutzen Sie das Emulex-Verwaltungsprodukt HBAnyware, das Sie zentral installieren und mit dem Sie die Fibre-ChannelHBAs aus der Ferne konfigurieren können. Auf diese gehen wir nach der Beschreibung der CLI-Version ein. Emulex lpfcutil In unserem Beispiel ist ein System mit VMware vSphere lokal installiert, und wir wollen das lpfcutil-Programm nutzen, um alle Emulex-Adapter nach und nach anzuschließen und mit der aktuellen Firmware zu versorgen.
Welche Firmware aktuell ist, erfahren Sie auf der Herstellerwebsite, in unserem Beispiel Emulex (http://www.emulex.com/vmware/support/index.jsp). Anhand der folgenden Versionen der Emulex-Tools, das lpfcutil in Version 7.3.2.3, das elxvmwarecorekit in Version 2.1.a35 (enthält HBAnyware) und die Firmwareversion 1.92a1, soll die Parametrierung der Karten gezeigt werden. Alle drei Dateien wurden auf den vSphere-Server übertragen und installiert (siehe Abbildung 5.14). Mittels lpfcutil-Programm wurde eine alte Version der Firmware ausgemacht und aktualisiert (Abbildung 5.15).
Abbildung 5.14
Installation der Emulex-Tools »elxvmwarecorekit« und »lpfcutil«
195
5.1
5
Installation
Abbildung 5.15
Emulex »lpfcutil«: Firmware auslesen
Menüschritte Firmware auslesen: 2, 2, Adapternummer Menüschritte Firmware aktualisieren: 3, Adapternummer, 1, Angabe Firmwaredatei
Bevor Sie das System neu starten, dürfen Sie nicht vergessen, das Boot-BIOS zu aktivieren, um den eigentlichen Boot-on-SAN-Vorgang konfigurieren zu können (Abbildung 5.16). Menüschritte Boot-BIOS einrichten: 3, Adapternummer, 6, 1
Während des nächsten Bootvorgangs des Systems sollte nun eine Meldung des Emulex-Controllers erscheinen, die das Drücken von (Alt) + (E) fordert, um in das Konfigurationsmenü zu gelangen – was wir auch tun. Im Emulex-Konfigurationsmenü angelangt, wählen Sie den ersten Adapter aus, da dieser zum Boot genutzt werden soll (Abbildung 5.17).
196
VMware vSphere 4.0
Abbildung 5.16
Emulex »lpfcutil«: Aktivierung des Boot-BIOS
Abbildung 5.17
Emulex-Adapter-Auswahl
Im darauf folgenden Menü (Abbildung 5.18) wählen Sie mit der Option 1 die Boot-LUN (Abbildung 5.19) aus und aktivieren mit Option 2 das BIOS (Abbildung 5.20).
Abbildung 5.18
Emulex-Boot-Device-Konfiguration
Haben Sie die Bootreihenfolge des System-BIOS beachtet, findet der nächste Start des Systems durch den Emulex-Controller statt, und Boot-on-SAN ist eingerichtet.
197
5.1
5
Installation
Abbildung 5.19
Auswahl der Boot-LUN durch Angabe der LUN-ID
Abbildung 5.20
Einschalten des Emulex-BIOS
Emulex HBAnyware (grafisches HBA-Verwaltungsprogramm) Das HBAnyware-Programm zur grafischen Verwaltung der Emulex-HBA-Karten ist in jeder Windows-Treiberversion enthalten. Daher ist der einfachste Weg zum Verwaltungsprogramm die Installation des Emulex-Treiberpaketes.
Danach finden Sie unter %programfiles%\Emulex\AutoPilot Installer\Utilities\ setupapps.exe die Installationsroutine von HBAnyware, die mit wenigen Klicks ausgeführt und gestartet ist. Auf dem vSphere-Server müssen Sie den HBAnyware Remote Management Agent installieren (siehe Abbildung 5.21; Installation elxvmwarecorekit) und den Dämon starten: /usr/sbin/hbanyware/start_rmserver. Falls Sie Fibre-Channel-HBAs konfigurieren müssen und in dem Windows-System selbst ein Fibre-Channel-Anschluss vorhanden ist, können Sie die HBAs direkt über das Fibre-Channel-Protokoll integrieren. Da wir in unserem Beispiel nur über eine Netzwerkverbindung zu den vSphere-Servern verfügen, müssen wir die Systeme als Out-of-Band-Discovery manuell mit ihrer IP-Adresse eintragen (Abbildung 5.22).
198
VMware vSphere 4.0
Abbildung 5.21
Installation von HBAnyware
Abbildung 5.22
Hinzufügen der zu verwaltenden Systeme
Da HBAnyware über TCP/IP kommuniziert, verhindert allerdings die Firewall des vSphere-Servers in der Standardkonfiguration alle eingehenden Pakete des durch Emulex genutzten Ports 23333. Diesen müssen Sie mit dem Kommandozeilenbefehl auf der Service Console mit esxcfg-firewall öffnen: esxcfg-firewall -o 23333,tcp,in,Emulex.
Abbildung 5.23
Hostsystem inklusive der installierten HBAs
199
5.1
5
Installation
Sobald HBAnyware Zugriff auf den Agenten hat, können Sie den Status der Karten einsehen (Abbildung 5.23). Außerdem sind nun ein Update der Firmware sowie die Aktivierung des Boot-BIOS grafisch möglich.
Abbildung 5.24
Parametereinstellung der Emulex-HBAs über HBAnyware
Besonders interessant ist die zentrale Einstellung der HBA-Parameter (Abbildung 5.24), deren Werte vom angeschlossenen Speichersystem anhand von Herstellerempfehlungen vorgegeben werden. iSCSI-HBAs und Boot-on-iSCSI Bei der iSCSI-Variante halten sich die möglichen Beispiele in Grenzen, da VMware vSphere nur wenige QLogic-iSCSI-HBAs unterstützt: QLA4050, QLA4052, QLA4060 und QLA4062. Die letzte Ziffer gibt an, wie viele Ports die jeweilige Karte hat (ein Port oder Dual-Port). Die Adapter der 5x-Serie verfügen über einen PCI-X-Anschluss, die Karten der 6x-Serie sind die Versionen mit PCIExpress-Anschluss. Einrichtung der iSCSI-HBA vor der Installation Anders als die Fibre-Channel-Variante muss der iSCSI-HBA vor der Installation bereits eingerichtet sein, da der HBA bereits das iSCSI-Target kennen muss, um eine iSCSILUN zur Installation zu finden.
Beispiel QLogic QLA4052 Mit welchem Schritt wird begonnen? Richtig, mit der Aktualisierung der Firmware, das heißt, Sie suchen auf der QLogic-Website (http://www.qlogic.com) nach
200
VMware vSphere 4.0
aktualisierter Firmware. Hier gehen wir auf die Version 2.0.0.45 ein. Ein kleiner Tipp: Wählen Sie statt VMware vSphere als Betriebssystem Red Hat Linux aus, da sonst unter Umständen keine Firmware angezeigt wird. QLogic SANsurfer iscli Zusätzlich benötigen Sie das Programm SANsurfer iscli (alternativ greifen Sie über das Netzwerk mit dem QLogic-Programm SANsurfer GUI auf den HBA zu, worauf wir abermals nach der CLI-Version eingehen), um das Firmwareupgrade einzuspielen. Die Installation ist durch tar xzvf und rpm –i sehr schnell bewältigt (Abbildung 5.25).
Abbildung 5.25
Installation QLogic SANsurfer
Nach Kopie der Firmwaredatei auf den Server starten Sie durch Aufruf von iscli das SANsurfer-CLI-Tool. Danach treffen Sie die Auswahlpunkte 3, 2, 2 und geben den Pfad zur Firmwaredatei an. Wichtig: Bei den Dual-Port-Karten muss das Update nur einmal für den gesamten HBA durchgeführt werden (Abbildung 5.26).
Abbildung 5.26
Aktualisierung der QLogic-HBA-Firmware
201
5.1
5
Installation
Außerdem sollten Sie auf eine BIOS-Version 1.13 oder höher aktualisieren, die Sie unter ebenfalls im Red-Hat-32Bit-Unterpunkt auf der QLogic-Website finden. Dieses BIOS-Update kann leider nicht über die vSphere-Kommandozeile erfolgen, allerdings aus einer Windows-Installation heraus oder mittels DOS-Bootdiskette/-DVD (Anleitung: http://www.biosflash.de/bios-boot-cd.htm). Sobald die Firmware- und BIOS-Version auf einem aktuellen Stand sind, können Sie Boot-on-iSCSI auf dem HBA einrichten. Dazu wechseln Sie in das QLogic Fast!UTIL, indem Sie während des Systemstarts (Strg) + (Q) drücken (Abbildung 5.27).
Abbildung 5.27
QLogic Fast!UTIL – (Strg) + (Q) während Systemboot
Falls noch nicht geschehen, muss der erste Schritt die IP-Konfiguration des iSCSIHBA sein (Abbildung 5.28), was in folgender Reihenfolge passiert: 1. Configuration Settings 2. Host Adapter Settings 3. Initiator IP Settings
Abbildung 5.28
HBA-IP-Konfiguration
Der nächste Schritt besteht in der Einrichtung des iSCSI-Boot-Targets, ebenfalls unter Configuration Settings im Menüpunkt iSCSI Boot Settings zu finden.
202
VMware vSphere 4.0
Hier sollten Sie das Primary Boot Device und falls benötigt auch ein Alternate Boot Device eintragen (Abbildung 5.29).
Abbildung 5.29
Einstellung des Primary Boot Device
QLogic SANsurfer GUI Genau wie bei der Emulex-Variante wird zum Netzwerkmanagement ein Agent auf dem System (mit dem eingebauten HBA) und eine Server-Komponente, die in unserem Beispiel unter Windows installiert wird, benötigt. Die SANsurfer-Software befindet sich sowohl auf der Treiber-DVD des Herstellers als auch auf der offiziellen Website (www.qlogic.com). Zuerst installieren Sie den Linux SANsurfer HBA Manager (bei Fibre-Channel-HBAs entsprechend den FC-Treiber) auf dem vSphere-Server: tar xzvf iSCSI_SANsurfer_5_00_32_linux_x86_package.tgz chmod +x iSCSI_SANsurfer_5_00_32_linux_x86.bin ./iSCSI_SANsurfer_5_00_32_linux_x86.bin -i silent -D SILENT_INSTALL_ SET="QMSJ_LA"
Nun starten Sie den Linux-Portmapper sowie den Remote-Management-Agent: service portmap start iqlremote &
Für die Firewall konnten leider keine passenden Ports gefunden werden, ein Sniffing im Netzwerk ergab leider nur wechselnde Ports. Daher müssen Sie in diesem Fall die Firewall komplett öffnen oder mit Sniffern nach den in dieser Sitzung genutzten Ports suchen. esxcfg-firewall --allowIncoming
Laden Sie danach den SANsurfer HBA Manager für Windows herunter und installieren Sie ihn auf einem Windows-System (Abbildung 5.30). Bei der Installation können Sie die Verwaltung und auch die Agenten sowohl für FC- als auch für iSCSI-HBAs auswählen, abhängig von Ihren Anforderungen.
203
5.1
5
Installation
Abbildung 5.30
Installation des QLogic SANsurfer Managers
Hat alles geklappt, sollte eine Verbindung zum vSphere-Server und dessen HBAs durch die Eingabe der Netzwerkadresse (Button Connect) funktionieren, und die HBA-Informationen sollten erscheinen (Abbildung 5.31).
Abbildung 5.31
204
Konfigurationsansicht der HBAs mittels SANsurfer
VMware vSphere 4.0
Soll ein BIOS- oder Firmware-Update erfolgen, führen Sie dies über den zweiten Tab, HBA Options, durch (Abbildung 5.32). Das Passwort für die Aktualisierung der Firmware ist in der Standardkonfiguration »config«.
Abbildung 5.32
Mit dem SANsurfer können Sie die HBAs über das Netzwerk aktualisieren.
Idealerweise starten Sie den vSphere-Server nach erfolgter Verwaltung durch SANsurfer neu. Die Portmapper-Dienste sowie der iqlremote-ManagementAgent sind damit wieder inaktiv. Die Firewall sollten mit esxcfg-firewall --blockIncoming wieder in den richtigen Zustand bringen.
5.1.8
Installation in der virtuellen Maschine
Mit Version 6 der VMware Workstation und einem VT-fähigen (Virtualization Technology) Prozessor genügt ein kleiner manueller Eingriff in der Konfigurationsdatei, um einen VMware-vSphere-Server in der virtuellen Maschine zu betreiben. Dies ist natürlich weder sonderlich schnell noch von VMware unterstützt, bietet jedoch viele Vorteile in Test- und Entwicklungsszenarien. Außerdem half diese Möglichkeit sehr, dieses Buch zu erstellen, da viele Tests und Versuche ansonsten viel zu aufwendig geworden wären.
205
5.1
5
Installation
Die Basis-VM sollten Sie als 64-Bit-Red-Hat-Linux-VM erstellen, wobei auf den Typ des LSI-Logic-SCSI-Controllers zu achten ist. Danach müssen Sie die konfigurierten Netzwerkadapter auf Intel E1000 umkonfigurieren (Änderung .vmx-Datei): ethernet0.virtualDev = "e1000"
Außerdem müssen Sie folgende Zeilen an die Konfigurationsdatei anfügen: monitor_control.restrict_backdoor = "TRUE" monitor_control.vt32 = "TRUE"
Die komplette Konfigurationsdatei könnte z. B. folgendermaßen aussehen: checkpoint.vmState = "" config.version = "8" deploymentPlatform = "windows" displayName = "vSphere" ethernet0.addressType = "generated" ethernet0.connectionType = "hostonly" ethernet0.generatedAddress = "00:0c:29:f3:24:be" ethernet0.generatedAddressOffset = "0" ethernet0.pciSlotNumber = "32" ethernet0.present = "TRUE" ethernet0.virtualDev = "e1000" ethernet0.wakeOnPcktRcv = "FALSE" guestOS = "rhel4-64" ide1:0.autodetect = "TRUE" ide1:0.deviceType = "cdrom-image" ide1:0.fileName = "" ide1:0.present = "TRUE" scsi0.pciSlotNumber = "16" scsi0.present = "TRUE" scsi0.virtualDev = "lsilogic" scsi0:0.fileName = "esx.vmdk" scsi0:0.present = "TRUE" scsi0:0.redo = "" isolation.tools.hgfs.disable = "TRUE" memsize = "2048" mks.keyboardFilter = "allow" monitor_control.restrict_backdoor = "TRUE" monitor_control.vt32 = "TRUE" numvcpus = "1" nvram = "vSphere.nvram" pciBridge0.pciSlotNumber = "17" pciBridge0.present = "TRUE"
206
Upgrade auf vSphere von ESX 3.x
tools.remindInstall = "TRUE" tools.upgrade.policy = "useGlobal" uuid.bios = "56 4d 16 8d f3 2a 11 2e-3d 8e b3 5c 2a f3 24 be" uuid.location = "56 4d 16 8d f3 2a 11 2e-3d 8e b3 5c 2a f3 24 be" virtualHW.productCompatibility = "hosted" virtualHW.version = "7" ide1:0.startConnected = "FALSE" extendedConfigFile = "esx.vmxf" floppy0.present = "FALSE" svga.maxWidth = "1280" svga.maxHeight = "1024" svga.vramSize = "5242880"
Jetzt können Sie den vSphere-Server äquivalent zum physischen System installieren. Nennen Sie eine VMware Workstation in der Version 7 Ihr Eigen, dann brauchen Sie die Anpassungen nicht vorzunehmen. Diese Version unterstützt das Anlegen von virtuellen ESX-Hosts.
5.2
Upgrade auf vSphere von ESX 3.x
Möchten Sie eine bereits bestehende Landschaft auf die neue VMware-Version updaten, müssen Sie grundsätzlich zuerst einen vorhandener vCenter-Server auf die Version 4.0 aktualisieren. Alle Vorgängerversionen des vCenter Servers 4.0 können die neuen vSphere-Hosts nicht managen. Ist die Managementumgebung in der passenden Version vorhanden und betriebsbereit, bleiben mehrere Möglichkeiten, das Update durchzuführen. Wichtig! Alle virtuellen Maschinen müssen auf dem zu aktualisierenden System gestoppt oder mit VMotion auf andere ESX-Server verschoben werden. Außerdem muss es auf dem Server eine lokale VMFS-Partition von mindestens 10 GB geben.
Wird ein Host mit der Version ESX 3.x mit der DVD gebootet, gibt es nicht mehr die Möglichkeit, das System zu aktualisieren (Abbildung 5.33). Ein Update wird nur über den vSphere Update Manager unterstützt, den Sie über das vCenter ansprechen. Alternativ nutzen Sie das vSphere Host Update Utility, wenn Sie es während der Installation des vSphere-Clients mitinstalliert haben.
207
5.2
5
Installation
Abbildung 5.33
Keine Updatemöglichkeit über die DVD
Insgesamt gibt es also drei Möglichkeiten, einen vSphere-Host zu erhalten: die Neuinstallation, ein Update über den vCenter-Server oder durch die Nutzung des Host Update Utilitys. Neuinstallation Aufgrund der schnellen Installation von VMware vSphere ist eine mögliche Wahl, alle Hosts neu zu installieren. Dazu fahren Sie einen Host eines eventuell bestehenden Clusters in den Maintenance-Mode. Dadurch werden alle virtuellen Maschinen vom Server evakuiert. Trennen Sie den Host im vCenter, und installieren Sie ihn neu. Nach erfolgreicher Installation und Aufnahme in den Cluster geben Sie den Host wieder für VMs frei. So können Sie einige der VMs wieder auf den neuen Host migrieren. Wiederholen Sie die Vorgehensweise für alle betroffenen Server, bis alle Systeme aktualisiert worden sind. Der Vorteil dieser Vorgehensweise liegt darin, dass die Möglichkeit besteht, die Systemkonfiguration anzupassen. So können Sie z. B. die Partitionierung ändern. Dieser Weg sollte die erste Wahl sein, wenn die Hostsysteme schon vorher von der Version ESX 2.x aktualisiert wurden. Host Update Utility Das vSphere Host Update Utility sollten Sie nur für das Update von sehr kleinen Landschaften nutzen. Sollen mehrere Server auf die neueste VMware-Version angehoben werden, dann empfiehlt sich die Verwendung des vSphere Update Managers im vCenter-Server. Dieser bietet das übersichtlichere Update-Management in größeren Umgebungen an. Über das Start-Menü rufen Sie das Host Update Utility auf. Es handelt sich um eine komplett unabhängige Software. Ein vCenter wird für die Nutzung nicht benötigt. Nach dem Start versucht die Applikation, sich mit dem SoftwareupdateServer der Firma VMware über das Internet zu verbinden. Über diese Verbin-
208
Upgrade auf vSphere von ESX 3.x
dung werden die Updates und Patches für die unterstützten ESX-/vSphere-Versionen heruntergeladen. Sie können diesen Vorgang auch abbrechen und dem System direkt die Installations-DVD zur Verfügung stellen.
Abbildung 5.34
vSphere Host Update Utility
Über das Menü Host 폷 Host hinzufügen binden Sie einen zu patchenden Host ein. Auch wenn in Abbildung 5.34 gewarnt wird, dass das Patchen dieser Hostversion nicht unterstützt wird, gibt es doch eine Möglichkeit, die Arbeiten durchzuführen. Über den Button Host aktualisieren gelangen Sie in einen Dialog, der es Ihnen ermöglicht, ein vorhandenes ISO-Image zu nutzen (Abbildung 5.35).
Abbildung 5.35
Einbinden der Installations-DVD
Nach der Verifizierung des ISO-Images müssen Sie die EULA bestätigen und anschließend in einem Dialog einen User-Namen nebst Passwort eingeben, mit dem Sie sich mit dem zu aktualisierenden Host verbinden können. Selbstredend benötigen Sie einen User mit administrativen Rechten für die Durchführung der Arbeiten.
209
5.2
5
Installation
Die Routine überprüft nun, ob sich der Host im Maintenance-Modus befindet. Haben Sie die Umschaltung nicht vorgenommen, erscheint eine Fehlermeldung (Abbildung 5.36).
Abbildung 5.36
Eingabe von User und Passwort
Jetzt findet eine Überprüfung des Systems statt. Ist diese abgeschlossen, werden Sie gefragt, auf welchem Storage die Service Console installiert werden soll. Unter vSphere ist die Service Console eine eigene virtuelle Maschine und muss auf einem nicht geshareten VMFS bereitgestellt werden (Abbildung 5.37).
Abbildung 5.37
210
Ziel-Storage der Service Console
Upgrade auf vSphere von ESX 3.x
In dem folgenden Dialog legen Sie das Verhalten fest, wenn das Update fehlschlägt. Standardmäßig ist die Option aktiviert, dass bei einer Fehlfunktion des Updates ein Rollback auf den Ursprungszustand erfolgt. Außerdem haben Sie die Option, nach der Installation automatisch Skripte laufen zu lassen. Auch hier gibt es die Chance auf einen Rollback, wenn bei der Installation Probleme auftauchen (Abbildung 5.38).
Abbildung 5.38
Verhalten beim Rollback
Jetzt läuft der Updateprozess auf dem ausgewählten Host ab. Sollte kein Problem auftauchen, erhalten Sie eine positive Abschlussmeldung (Abbildung 5.39).
Abbildung 5.39
Abschlussmeldung nach erfolgreichem Update
211
5.2
5
Installation
Wie schon erwähnt, bietet sich die beschriebene Vorgehensweise für kleine Landschaften oder Einzelsysteme an. In größeren Landschaften sollten Sie das Update über den vCenter-Server durchführen. vCenter-Server Damit der vCenter-Server die Option für das Updaten von ESX-3.x-Hosts anbietet, muss der vSphere Update Manager installiert sein. Dies kann sowohl auf dem vCenter selbst als auch auf einem anderen, im Netzwerk stehenden System erfolgen. Selbstverständlich müssen Sie den passenden Client installieren. Dieser Client integriert sich in den vSphere-Client und ist auf dem System einzurichten, von dem Sie die Arbeiten durchführen wollen. Detaillierte und weitergehende Informationen zur Konfiguration des Update Managers finden Sie in Abschnitt 12.1, »Einsatz des vCenter Update Managers«. Jetzt soll nur darauf eingegangen werden, wie Sie vorhandene Hosts aktualisieren. Setzen Sie den Update Manager zuerst nur für das Update von ESX-Servern ein, ist initial kein Patch-Repository zu hinterlegen. Über den Reiter Upgrade-Baselines treffen Sie die Auswahl, Hosts zu updaten (Abbildung 5.40).
Abbildung 5.40
vSphere Update Manager
Es folgt die initiale Anlage einer Upgrade-Baseline. Über den entsprechenden Auswahlpunkt oben rechts starten Sie einen Wizard, der die passenden Abfragen stellt, um eine zugehörige Baseline zu erstellen. Das erste Fenster ist an sich selbsterklärend. Wir wünschen eine Baseline, mit der sich existierende Hosts updaten lassen (Abbildung 5.41). Damit die Arbeiten durchgeführt werden können, benötigt der Update-Server das ISO-File mit den vSphere-Installationsdateien oder das Update-ZIP-File für Systeme, die unter ESXi laufen (Abbildung 5.42).
212
Upgrade auf vSphere von ESX 3.x
Abbildung 5.41
Erstellen einer Upgrade-Baseline
Abbildung 5.42
Einbinden der benötigten Medien
Nach der Aktivierung werden die Files in das Update-Repository übernommen. Der Import nimmt ein wenig Zeit in Anspruch, je nachdem, über welches Medium Sie die Daten importieren. Ist der Import erfolgreich abgeschlossen, geben Sie an, auf welche Partition die Service Console installiert werden soll (Abbildung 5.43). Es wird eine VMFS-Partition verlangt, weil es sich bei der Service Console seit vSphere um eine virtuelle Maschine handelt. Entweder lassen Sie einen Automatismus zu, oder Sie geben
213
5.2
5
Installation
die Zielpartition direkt fest an. Der Updatevorgang schlägt fehl, wenn die Partition nicht gefunden wird.
Abbildung 5.43
Auswahl der Zielpartition für die Service Console
Wie auch beim Host Update Utility gibt es den Weg, nach einem fehlerhaften Update ein Rollback durchführen zu lassen. Auch hier ist das Ausführen von PostScripts für weitergehende Konfigurationen möglich. Als Letzteres wird eine Zusammenfassung der konfigurierten Parameter angezeigt, und die Baseline ist erfolgreich erstellt. Jetzt ist eine Baseline-Gruppe zu generieren. Über den Button Neue HostUpgrade-Baseline erstellen in Abbildung 5.40 kreieren Sie nun dieses Konfigurationselement. Es öffnet sich ein Dialog, in dem Sie einen Namen vergeben müssen. Selbstverständlich handelt es sich hier um eine Baseline für Hostsysteme. Es folgt nun die Verbindung der jetzt erstellten Host-Baseline mit der vorher erstellen Patch-Baseline (Abbildung 5.44). Schließen Sie den Dialog nun mit Beenden ab. Wenn Sie jetzt auf die Hosts und dann auf den Reiter Update Manager gehen, befinden Sie sich an der Stelle, wo Sie die Update-Policy mit dem Host verbinden können. Der ausgewählte Host ist zu standardisieren. Dies geschieht über den entsprechenden Button (Abbildung 5.45). Der folgende Dialog erwartet die Auswahl der passenden Baseline und Baseline-Gruppe. Es folgen die Lizenzvereinbarung und eine Zusammenfassung der eingestellten Konfiguration. Abschließend legen Sie die Startzeit des Auftrages fest und geben dem Auftrag einen eindeutigen Namen.
214
Upgrade auf vSphere von ESX 3.x
Abbildung 5.44
Verknüpfung von Patch- und Host-Baseline
Abbildung 5.45
Update Manager für ein Host-Objekt
Stoßen Sie jetzt über den Link Standardisieren den Updatevorgang an. Dieser läuft dann vollkommen automatisch ab; es sind keine manuellen Eingriffe nötig. Zuerst wird der Server automatisch in den Maintenance-Modus gefahren. Anschließend führt der Patch-Manager die Updatearbeiten durch. Nach dem
215
5.2
5
Installation
Abschluss der Arbeiten wird der Host automatisch neu gestartet. Das System ist wieder unter der alten Netzwerkkonfiguration erreichbar und ist nun wieder aus dem Maintenance-Modus zu nehmen.
5.3
VMware vSphere 4i
VMware vSphere 4i ist eine neue Version des vSphere-Servers, die nur aus dem VMkernel besteht, der über ein Mini-Linux namens Busybox bootet. Das ESXi ist in zwei unterschiedlichen Installationsversionen erhältlich: embedded und installable. Embedded ist für die Server-Hersteller konzipiert, die VMware vSphere 4i direkt (OEM) in ihre Server integrieren möchten. Die Installable-Version ist für alle anderen VMware-Kunden gedacht, die ihre Server statt mit der »großen« vSphere 4 mit der »schlanken« Version vSphere 4i ausstatten möchten. Der wichtigste Faktor von vSphere 4i ist allerdings, dass die Embedded-Version des vSphere-Servers nur so groß ist, dass Sie damit problemlos von USB- oder Flashspeicher starten können. Daher ist diese Version mittlerweile auch in Systemen namhafter Server-Hersteller integriert, das heißt, die Server werden direkt mit VMware als »Betriebssystem« ausgeliefert. Allerdings existiert die bekannte Service Console nicht, und es ist nicht möglich, unter vSphere 4i Zusatzsoftware zu installieren. Die Verwaltung wird komplett über die VMware-API realisiert, die Sie aber durch ein vSphere CLI fernsteuern können. Das vSphere CLI können Sie unter Windows oder Linux installieren oder direkt als Virtual Appliance herunterladen.
5.3.1
Download der Installationsmedien
In der gleichen Download-Sektion, in der Sie die Version VMware vSphere 4 finden, ist auch eine Untersektion vSphere Server 4i vorhanden (Abbildung 5.46). Die Sektion finden Sie unter http://downloads.vmware.com/d/info/datacenter_ downloads/vmware_vsphere_4/4. Die Version ist als ISO-Image ladbar, das Sie auf CD brennen oder als virtuelles Medium nutzen.
5.3.2
Installation vSphere 4i
Die Installation von vSphere 4i ist absolut simpel und erfordert keinerlei LinuxKenntnisse, wenn Sie über zertifizierte Hardware verfügen.
216
VMware vSphere 4i
Abbildung 5.46
Download-Bereich VMware vSphere 4i
Abbildung 5.47
ThinvSphere (vSphere 4i) Installer
Nach Starten des ISO-Images oder der DVD wird direkt das Bootmenü mit dem Installer angezeigt (Abbildung 5.47). Mit der (ÿ_)-Taste könnten Sie die Bootparameter ändern, zur Drucklegung des Buches war uns jedoch noch keine sinn-
217
5.3
5
Installation
volle Nutzungsmöglichkeit bekannt. Wie der zweite Menüpunkt schon besagt, können Sie die Installation umgehen, und das System bootet von der Festplatte. Zu Beginn lädt das System nun verschiedene Treiber. Anschließend zeigt sich der Screen aus Abbildung 5.48.
Abbildung 5.48
vSphere 4i Installer Schritt 2
Ist bereits ein vSphere 4i-Server, der nur repariert werden soll, installiert, fahren Sie mit (R) fort, ansonsten mit (¢) (Abbildung 5.48). Danach folgen die üblichen EULA-Bestimmungen, die Sie akzeptieren müssen.
Abbildung 5.49
Auswahl der Zielfestplatte
Die Installationsroutine des vSphere 4i-Servers stellt keine Partitionierungsmöglichkeiten zur Verfügung, stattdessen wird die angegebene Festplatte komplett genutzt (Abbildung 5.49). Das sollten Sie bei der Entscheidung, ob vSphere 4 oder 4i zum Einsatz kommen soll, bedenken. Nach einem Druck auf (F11) (Abbildung 5.50) startet die Installation, die ca. 2–4 Minuten in Anspruch nimmt. Es folgt der Neustart in vSphere 4i, das im Standard eine DHCP-Adresse abgreifen möchte.
218
VMware vSphere 4i
Abbildung 5.50
5.3.3
Los geht’s mit der 4i-Installation!
Erststart vSphere 4i
Zum Starten des vSphere 4i-Servers müssen Sie den USB-Stick am Server einlegen. Achten Sie bitte darauf, dass Sie Support nur dann bekommen, wenn Sie zertifizierte Hardware einsetzen. Danach sollte das BIOS auf den Boot des USBGeräts umgestellt werden. Sobald der vSphere 4i-Server komplett gestartet ist, befinden Sie sich in einem rudimentären Startmenü, das über die Tastatur zu bedienen ist (Abbildung 5.51). Da der vSphere 4i-Server im Standard eine IP-Adresse per DHCP bezieht, kann bei vorhandenem DHCP-Server im Netzwerk auch direkt über den Virtual Infrastructure Client zugegriffen werden. In diesem Fall wäre allerdings das root-Passwort leer.
Abbildung 5.51
Erststart des vSphere 4i-Systems
Daher bietet sich die Taste (F2) an, mit der Sie eine IP-Adresse und ein root-Passwort konfigurieren (Abbildung 5.52). Außerdem können Sie den LockdownMode an- oder ausschalten, um SSH-Zugriffe mit einem root- oder admin-Benutzer auf den vSphere 4i-Server zu sperren.
219
5.3
5
Installation
Abbildung 5.52
5.3.4
Konfigurationsseite des vSphere 4i-Systems
vSphere CLI
Mit dem Weggang von der Service Console musste sich die VMware-Entwicklungsabteilung Gedanken um einen entsprechenden Ersatz machen, da viele Hersteller und Anwender diese Console häufig für Skripte und Konfigurationen nutzten. Aus diesem Grund entstand das vSphere CLI (Command-Line Interface), das im Endeffekt eine Kombination aus Perl-Wrapper und Perl-Skripten ist. Diese Skripte nutzen die VI-API auf einfachem Weg über das Netzwerk und kommunizieren so mit vSphere-Server und vCenter-API. Möchte der Administrator diese Funktionen nutzen, dann gibt es grundsätzlich zwei Möglichkeiten, die Software herunterzuladen. Die Download-Sektion bei VMware stellt die entsprechenden Files zur Verfügung, und zwar unter: http://communities.vmware.com/community/developer/vsphere_cli Zumindest den vSphere-Client können Sie direkt vom ESX 4i-Host herunterladen (Abbildung 5.53). Über den Webbrowser verbinden Sie sich mit der URL des ESX 4i-Servers: http://. Alle anderen Links leiten den Anwender direkt auf die VMware-Website.
220
VMware vSphere 4i
Abbildung 5.53
Zugriff auf ESX 4i via vSphere-Client
Installation unter Linux Kopieren Sie zuerst die Datei VMware-vSphere-CLI-4.0.0-xxxxx.xxxx.tar.gz auf das gewünschte Linux-System, und führen Sie sie mit tar xzvf VMware-vSphereCLI-4.0.0-xxxxx.xxxx.tar.gz aus. Es wird dadurch ein Verzeichnis vmware-vsphere-cli-distrib erstellt, in dem alle Dateien entpackt werden. Die Installation starten Sie z. B. mit /tmp/vmwarevsphere-cli-distrib/vmware-install.pl, wodurch alle Dateien im Standard in /usr/ bin kopiert werden. Eine Deinstallation ist mit /usr/bin/vmware-uninstall-vSphere-CLI durchzuführen. Danach finden sich viele esxcfg-Kommandos auf dem System wieder.
221
5.3
5
Installation
Installation unter Windows Das vSphere CLI kommt als normale Setup-Routine für Windows daher (VMware-vSphere-CLI-4.0.0-161974.exe) und läuft nach dem Start komplett selbständig durch; sollte bereits eine ältere Version installiert sein, wird diese vorher deinstalliert. Nach der Fertigstellung befindet sich eine ActivePerl-Installation im Verzeichnis C:\Programme\VMware\VMware vSphere CLI (oder C:\Program files\VMware\VMware vSphere CLI). Die Perl-Skripte sind ebenfalls hier zu finden. Virtual Appliance Eine weitere Alternative ist der Import der Management-Appliance von VMware, die alle benötigten Remote-CLI-Komponenten samt Gastbetriebssystem enthält (Abbildung 5.54). Die Virtual Appliance laden Sie entweder manuell als OVF (Open Virtual Machine Format) herunter oder importieren sie mit dem OVF-Tool.
Abbildung 5.54
Download der vSphere-CLI-Appliance
Auf der Webseite von VMware unter http://www.vmware.com/appliances/directory/178973 lässt sich die Appliance herunterladen und anschließend im vSphere-Client importieren. Wird die Appliance zum ersten Mal gestartet, sind einige Eingaben zu tätigen, um das System zu nutzen. Es werden der Name der Maschine abgefragt, die Netzwerkparameter und das Passwort des administrativen Users vi-admin. Mit dem root-User können Sie sich nicht direkt an der Konsole anmelden. Sie müssen mit dem Kommando sudo arbeiten, um im root-Kontext Befehle abzusetzen.
222
VMware vSphere 4i
Zusätzlich wird automatisch ein Read-only-Account eingerichtet. Dieser Account vi-user hat standardmäßig kein Passwort. Vor der Vergabe eines Kennworts ist dieser Account nicht nutzbar. Ist die Datei heruntergeladen, entpacken Sie die Datei. Den Import der Appliance stoßen Sie über den vSphere-Client an (Abbildung 5.55).
Abbildung 5.55
Importmenü Virtual Appliance
Über den folgenden Dialog importieren Sie über das File-System die Appliance (Abbildung 5.56).
Abbildung 5.56
Appliance-Import
Ist der Import erfolgreich abgeschlossen, können Sie die virtuelle Maschine zur Administration nutzen.
223
5.3
5
Installation
5.4
VMware vCenter
Wenn es um erweiterte Funktionen wie VMotion, HA, DRS etc. oder zentrale Verwaltung geht, hilft die reine vSphere-Installation wenig weiter, da jeder vSphere-Server nur ein System darstellt, dessen Ressourcen partitioniert werden können, um virtuelle Maschinen zu betreiben. Mit der Version 2.x des VMware ESX-Servers wurde das Verwaltungswerkzeug vCenter in Version 1 eingeführt und stellt seitdem einen immer wichtigeren Bestandteil der VMware-Infrastruktur dar. In der aktuellen Version des vCenter-Servers haben Sie die Möglichkeit, über 300 vSphere-Server und über 3.000 virtuelle Maschinen zentral zu verwalten und durch Cluster, Resource-Pools und VMotion zu einer virtuellen Gesamtheit zu verschmelzen. Nutzen Sie die neue Funktionalität des vCenter-Servers, die Verlinkung von vCenter-Servern, dann sind bis zu 1 000 vSphere-Server und maximal 10 000 virtuelle Maschinen adressierbar. Das vCenter ist sogar der wichtigste Grund, um von einer virtuellen Infrastruktur sprechen zu können. Das vCenter, vormals Virtual Center-Server, hat im Laufe der Zeit, wie fast jede Software, viele Entwicklungsstufen durchgemacht und integriert zur Drucklegung des Buches nun folgende Komponenten: Host-Profiles, VMware vCenter Server, vCenter Server License Manager, vCenter WebAccess, vCenter Update Manager, vCenter Server Heartbeat, vCenter Server Orchestrator und vCenter Server Converter. In den meisten Fällen empfiehlt es sich, alle benötigten (bzw. lizenzierten) Komponenten auf einem einzelnen System zu installieren und zu betreiben. Für Testund Entwicklungsumgebungen können Sie auch direkt eine MS SQL-ExpressDatenbankengine mitinstallieren, ansonsten sollten Sie auf einen MS SQL- oder einen Oracle-Datenbank-Server zurückgreifen. In der aktuellen Version wird zwar die Express-Version des MS SQL Servers mitgeliefert, sie ist aber für produktive Umgebungen nicht zu empfehlen. Handelt es sich um eine recht kleine Installation von 10 und weniger vSphereServern mit 100 und weniger virtuellen Maschinen, kann der SQL- oder OracleServer auch auf der gleichen Maschine wie das vCenter mitlaufen. Ansonsten sollten Sie den Datenbank-Server auf einer getrennten Maschine betreiben, weil die Last und das Datenaufkommen entsprechend der Infrastrukturgröße steigen. Für die Planung des Datenbankwachstums existiert ein VMware-Excel-Dokument, das Ihnen eine ungefähre Größenberechnung für Microsoft SQL ermöglicht: http://www.vmware.com/support/vi3/doc/vc_db_calculator.xls
224
VMware vCenter
Abbildung 5.57 zeigt eine solche Berechnung mit 20 Hosts und 200 VMs, deren Größe bei ca. 1,5 GB liegt, wenn Sie das 2. Protokolllevel einschalten würden. Auch wenn im Kopf der Tabelle noch die alte Bezeichnung des Produktes steht, so gilt der errechnete Wert auch für die aktuelle Version des Managementtools.
Abbildung 5.57
VMware-vCenter-Datenbank-Kalkulation
Mit VMware VI 3.5 wurde der Update Manager eingeführt. Diese Komponente benötigt ebenfalls eine eigene Datenbank. Auch hier gibt es ein Excel-Sheet, das den Administrator bei der Berechnung der benötigten Datenbankgröße unterstützt. Sie finden dieses Dokument (Abbildung 5.58) unter der URL: http://www.vmware.com/support/vsphere4/doc/vsp_vum_40_sizing_estimator.xls Dieses Dokument berechnet Datenbank- und Festplattenbelegung in einem. Während beim Update Manager nicht viel in der Datenbank passiert, ist die Festplattenbelegung durchaus nennenswert und wächst, abhängig von der Anzahl verschiedener Betriebssysteme und -stände, schnell jährlich im zweistelligen GByte-Bereich, da neben VMware- auch Microsoft-Updates verwaltet werden. Auch in diesem Sheet werden analog die Daten der ersten Berechnung zugrunde gelegt. Fazit Um vCenter und den vCenter Update Manager zu nutzen, benötigen Sie zwei unabhängige Datenbanken. Das voraussichtliche Wachstum können Sie mit den vorgestellten Excel-Dokumenten anhand der Infrastrukturdaten selbst berechnen.
225
5.4
5
Installation
Abbildung 5.58
5.4.1
VMware Update Manager – Berechnung Platten- und Datenbankbelegung
vCenter-Systemvoraussetzungen
VMware vCenter Server ist eine reine Microsoft-Windows-Anwendung, daher wird als Basisbetriebssystem auch nur ein Microsoft-Betriebssystem unterstützt. Obwohl Workstation-Betriebssysteme in der Kompatibilitätsliste (Abbildung 5.59) stehen, können wir von einem Produktiveinsatz auf diesen nur abraten.
Abbildung 5.59
226
Auszug VMware Compatibility Guide – unterstützte Betriebssysteme
VMware vCenter
Als Datenbank können verschiedene Programmversionen des Microsoft SQL Servers und des Oracle-Datenbank-Server dienen. Die aus vorherigen vCenterServer-Zeiten bekannten Access- oder MSDE-Installationen für Test- und Entwicklungsumgebungen sind der Microsoft SQL Server 2005 Express Edition gewichen. Die folgenden beiden Abbildungen zeigen die derzeitige Kompatibilität zwischen der vCenter-Applikation und den Datenbanken von Microsoft (Abbildung 5.60) und Oracle (Abbildung 5.61).
Abbildung 5.60
Kompatibilitätsmatrix für MS-Datenbank-Server
Abbildung 5.61
Kompatibilitätsmatrix für Oracle-Datenbank-Server
227
5.4
5
Installation
Die Supportmatrix für den vCenter Server Update Manager sehen Sie in Abbildung 5.62 und Abbildung 5.63.
Abbildung 5.62
Kompatibilitätsmatrix für den vCenter-Server unter MS SQL
Abbildung 5.63
Kompatibilitätsmatrix für den vCenter-Server unter einer Oracle-Datenbank
5.4.2
Download der Installationsmedien
Auf der VMware-vCenter-Download-Seite ist die Companion-DVD zu finden (siehe Abbildung 5.46), die alle notwendigen Komponenten enthält. Außerdem enthält sie den Lizenz-Server für VI 3.x als Einzelinstallation (falls in Mischumgebungen ein alter Lizenz-Server benötigt wird) sowie die Offline-Migrations-DVD und die Linux-Kommandozeilenversion des VMware Converters.
228
VMware vCenter
5.4.3
Vorbereitung der Datenbank
Als Datenbanken werden im produktiven Umfeld verschiedene Versionen von Microsoft SQL Server und Oracles Datenbank-Server unterstützt. In Test- und Entwicklungsumgebungen können Sie die mitgelieferte Version Microsoft SQL Server 2005 Express Version nutzen. Microsoft SQL 2005 Express Diese Datenbanksoftware wird auf der Companion-DVD direkt mitgeliefert und durch die Installationsroutine bei Nichtangabe einer externen Datenbank automatisch installiert. Diese empfiehlt sich jedoch nicht für den produktiven Einsatz. Es sind in diesem Fall keine Vorbereitungen nötig. Microsoft SQL 2005/8 Haben Sie selbst oder der Datenbankadministrator eine vCenter-Datenbank (und zusätzlich eine VMware-Update-Manager-Datenbank) im Microsoft SQL Server eingerichtet, benötigt die vCenter-Installation einen vorbereiteten ODBC-Zugriffsweg. Diesen erstellen Sie in den Administrative Tools 폷 Verwaltung 폷 Data Sources, die innerhalb der Systemsteuerung (Abbildung 5.64) zu finden sind.
Abbildung 5.64
Anlage ODBC-Datenquelle
229
5.4
5
Installation
Wichtig! Diese Vorgehensweise trifft nur bei der Benutzung eines 32-Bit-Betriebssystems zu. Kommt eine 64-Bit System zum Einsatz, ist die Arbeitsweise wie im folgenden Abschnitt beschrieben.
ODBC auf 64-Bit Systemen Auch auf 64-Bit-Systemen müssen Sie mit einer 32-Bit-ODBC-Verbindung arbeiten. Dabei ist es unerheblich, welche Datenbank Sie im Hintergrund verwenden. Kommt der Microsoft SQL Server zum Einsatz, müssen Sie die 64-Bit-ODBC-Treiber installieren. Während der Installation werden auch automatisch die 32-BitTreiber installiert. Die Konfiguration der Verbindung erfolgt dann über das Tool [Windows-Verzeichnis]\SysWOW64\odbcad32.exe. Arbeiten Sie mit einer Oracle-Datenbank, reicht es, die 32-Bit-ODBC-Treiber zu installieren. System-DSN anlegen! Damit alles reibungslos funktioniert, müssen Sie eine System-DSN und keine UserDSN anlegen!
Für den Zugriff auf den SQL 2005/8 Server wird der Native Client benötigt. Bei der Anlage der ODBC-Verbindung sehen Sie sofort, ob der Client schon installiert ist. Stellt die Konfiguration sich wie in Abbildung 5.65 dar, dann ist der Client nicht vorhanden, und Sie müssen ihn erst installieren, bevor Sie fortfahren können.
Abbildung 5.65
230
ODBC-Datenquelle – SQL Server 2000
VMware vCenter
Handelt es sich bei dem Datenbank-Server um einen SQL Server 2005/8 und haben Sie die ODBC-Verbindung mit dem SQL-Server-Treiber eingerichtet, beschwert sich die vCenter-Installationsroutine bereits vor der eigentlichen Installation und zeigt eine Fehlermeldung (Abbildung 5.66), denn, um vCenter auf einer MS-SQL-Server-Version 2005/8 zu betreiben, muss eine ODBC-Datenbankschnittstelle mit dem SQL-Native-Client-Treiber angelegt sein.
Abbildung 5.66 Die Nutzung des Standard-SQL-ODBC-Treibers führt bei Nutzung von SQL Server 2005 zu einem Fehler.
Den SQL Native Client finden Sie z. B. auf der SQL-Server-2005-DVD, und er wird auch direkt bei den Pre-Installation-Tasks (Abbildung 5.67) über das Autostart-Menü mitinstalliert. Ist schon ein älterer Native Client vorhanden, kann dieser bei einer Aktualisierung zu Problemen führen: deinstallieren Sie ihn daher sicherheitshalber vorher. Alternativ finden Sie den Client hier: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID= d09c1d60-a13c-4479-9b91-9e8b9d835cdc
Abbildung 5.67
Installation des Microsoft SQL Native Clients
Nach der Installation des SQL Native Clients steht ein neuer ODBC-Treiber zur Verfügung, der zur Anlage der Datenquelle für vCenter genutzt werden muss
231
5.4
5
Installation
(Abbildung 5.68). Das weitere Vorgehen läuft exakt so ab wie im folgenden Abschnitt beschrieben.
Abbildung 5.68
SQL Native Client für die Verbindung mit MS SQL 2005/8
Der zu vergebende Datenquellenname (Abbildung 5.69) wird später vom vCenter-Server referenziert und genutzt. Außerdem werden Sie nach dem SQL-ServerNamen gefragt. Idealerweise geben Sie hier den DSN-Namen an. Sind Datenbank und vCenter-Server gleich, genügt die Angabe »localhost«.
Abbildung 5.69
Konfiguration ODBC-Datenquelle – SQL-Server- und Quellenname
Der in Abbildung 5.70 vergebene Benutzername wird nur für den Windows-Test der Datenquelle und nicht vom vCenter-Server genutzt. Während der vCenterInstallation werden Sie ebenfalls nach einem Benutzerprofil, das in der Registry abgelegt wird, gefragt. Daher nutzt im Falle einer SQL-Benutzer-Kennwortänderung auch keine Anpassung der ODBC-Datenquelle.
232
VMware vCenter
In den meisten Fällen wird die SQL-Benutzerauthentifizierung genutzt, wenn über das Netzwerk auf die Datenbank zugegriffen wird. Handelt es sich bei vCenter und SQL Server um das gleiche System, ist meist die Windows-Anmeldung erste Wahl. Die Registry-Angaben finden Sie in folgendem Zweig: HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VCenter\DB
Abbildung 5.70 Verbindungsprofil – im Beispiel wird die SQL-ServerAuthentifizierung genutzt.
Bei der Einrichtung des Benutzers und der vCenter-Datenbank auf dem Datenbank-Server ist die klare Empfehlung, einen exklusiven Benutzer für die Datenbank anzulegen. Ist dieses nicht gewollt oder möglich, müssen Sie darauf achten, die vCenter-Datenbank dediziert als Default-Database anzugeben (Abbildung 5.71).
Abbildung 5.71
Die Standarddatenbank wird auf die vCenter-Datenbank umkonfiguriert.
233
5.4
5
Installation
Die weiteren Angaben im folgenden Fenster übernehmen Sie als Default. Ein abschließender Test (Abbildung 5.72) zeigt, ob die ODBC-Datenbankverbindung funktioniert oder noch Fehler auszubügeln sind. Diesen Test sollten Sie immer durchführen, um Fehler bereits frühzeitig zu erkennen.
Abbildung 5.72
Sind alle Angaben korrekt, dann sollte der Test erfolgreich ausfallen.
Bekannte Probleme Microsoft SQL Server Datenbankberechtigung Bei der Anlage der vCenter-Datenbank muss natürlich eine entsprechende Berechtigung vorhanden sein. vCenter erwartet hier nahezu volle Berechtigung an der Datenbank, da außer Löschung der Datenbank und Änderung des Owners fast alles verändert wird. Glücklicherweise kontrolliert die vCenter-Installationsroutine bereits die Berechtigungsstruktur und zeigt eine Warnmeldung (Abbildung 5.73), das erspart Ihnen die spätere Fehlersuche.
Abbildung 5.73
Falsche Berechtigungen auf der vCenter-Datenbank
Recovery-Modell Bei der Anlage der beiden Datenbanken für vCenter und VMware Update Manager sollten Sie außerdem die Einstellung des Recovery-Modells überdenken, da die Full-Recovery-Einstellung schnell die Festplattenpartition des Datenbank-Servers bis an die Kapazitätsgrenze füllt (Abbildung 5.74, Abbildung 5.75). Zumeist reicht die Einstellung Simple-Recovery-Mode.
234
VMware vCenter
Abbildung 5.74
Recovery-Modell bei SQL Server kann zu vollem Dateisystem führen.
VMware hat zu diesem doch recht häufigen Support-Call einen eigenen Knowledge-Base-Artikel mit der Nummer 1001046 verfasst, der unter http://kb. vmware.com zu finden ist.
Abbildung 5.75
Simple-Recovery-Mode-Einstellung an der MS-SQL-Server-Datenbank
Kennwortänderung SQL-Benutzer Bei einer Kennwortänderung ist der empfohlene Weg die Neuinstallation des VMware-vCenter-Servers unter Beibehaltung der bestehenden Datenbank. Können Sie die Kennwortänderung planen, ist es am einfachsten, das Passwort im vCenter-Server zu ändern. Passen Sie dazu wie in Abbildung 5.76 das Datenbank-Passwort an (Administration 폷 vCenter Management Server Configuration 폷 Options), und stoppen Sie den vCenter-Server-Dienst. Ändern Sie danach den SQL-Benutzer auf dem SQL Server, und starten Sie den vCenter-Dienst wieder. Tipp Das Vorgehen ist übrigens unabhängig von der genutzten Datenbanksoftware.
Oracle Nutzen Sie eine Oracle-Datenbank für die vCenter-Komponenten, müssen Sie den Oracle-Client installieren. Dieser bringt auch einen ODBC-Treiber für Windows mit. Im Beispiel arbeiten wir mit einer Oracle-11g-Installation.
235
5.4
5
Installation
Abbildung 5.76
Änderung des Datenbank-Passworts im vCenter
Abbildung 5.77
Oracle-11g-Installationsroutine ODBC-Treiber
236
VMware vCenter
Neben dem Oracle-ODBC-Treiber für Windows muss unter 11g der Connection Manager auf dem vCenter-Server vorhanden sein, um die ODBC-Verbindung zu nutzen (Abbildung 5.77, Abbildung 5.78).
Abbildung 5.78
Oracle-Installationsroutine Listener und Connection Manager
Nach der Installation der Oracle-Komponenten müssen Sie über den Connection Manager ein TNS-Profil einrichten. Im Endeffekt ist der Connection Manager lediglich eine grafische Oberfläche zur Erzeugung der tnsnames.ora, die OracleAdministratoren bekannt sein muss. Die tnsnames.ora enthält neben dem TNSService-Namen die Adresse des Oracle-Datenbank-Servers und den Datenbanknamen. Beispiel »tnsnames.ora«: VCENTER-DB = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = oracle)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = vcenter) ) )
237
5.4
5
Installation
Beschreibung: VCENTER-DB = TNS-Service-Name oracle = Datenbank-Server (IP, Hostname oder DNS-Name möglich) vcenter = Service-Name = Oracle-Datenbank-Listener
Abbildung 5.79
Oracle-ODBC-Treiber
Nach erfolgreicher tnsnames.ora-Erstellung durch den Connection Manager legen Sie eine System-DSN an und wählen während der Konfiguration den Oracle-Treiber (Abbildung 5.79) aus.
Abbildung 5.80
Konfiguration Oracle-ODBC-Treiber
Zum größten Teil ist die Erstellung der Oracle-ODBC-Verbindung mit der SQLServer-Verbindung identisch, daher können Sie bei Bedarf gern in der SQL-Anleitung spicken (vgl. Seite 234). Ein wesentlicher Unterschied ist jedoch die Frage nach dem TNS-Service-Namen (statt des SQL-Server-Namens), der durch die tnsnames.ora vorgegeben wird (Abbildung 5.80).
238
VMware vCenter
Funktioniert die Verbindung nach dem Klick auf Test Connection, ist die Wahrscheinlichkeit groß, dass auch die vCenter-Installation reibungslos durchläuft.
5.4.4
Installation vCenter und Komponenten
Da nun alle Datenbankvorbereitungen getroffen sind, beginnen Sie mit der eigentlichen vCenter-Installation. Allerdings sollten Sie noch den Stand des Microsoft Windows Installers überprüfen und gegebenenfalls auf die Version 3.1 (http://support.microsoft.com/?id=893803) aktualisieren bzw. alle wesentlichen Windows-Patches einspielen. Prinzipiell ist die Installation absolut einfach und intuitiv gehalten, vorausgesetzt, alle Vorgaben sind erfüllt. Im Gegensatz zur Vorversion wurden die Installationen der Komponenten vCenter Server, vCenter Update Manager, vCenter Converter, vCenter Guided Consolidation (es handelt sich um eine abgespeckte Version des VMware Capacity Planners) und vSphere-Client in der aktuellen Version voneinander entkoppelt. Der Grund dafür liegt darin, dass es möglich ist, die vCenter-Komponenten auf verschiedenen Servern zu installieren. Deshalb sind mehrere Installationsschritte durchzuführen. Den Anfang macht der vCenter-Server. Starten Sie die autorun.exe (manuell oder automatisch), erscheint das Begrüßungsfenster mit den verschiedenen Installationsoptionen (Abbildung 5.81).
Abbildung 5.81
Custom-Auswahl vCenter-Installationsroutine
Der Lizenz-Server erscheint nicht als gesonderter Auswahlpunkt, sondern ist wieder Bestandteil des vCenters. Wird der vCenter-Server in einer Landschaft eingesetzt, in der noch ESX-3.x-Systeme administriert werden müssen, müssen Sie
239
5.4
5
Installation
noch separat einen alten Lizenz-Server installieren. Weiteres zu dieser Installation finden sie weiter unten in diesem Kapitel Abschnitt »Einzelinstallation VMware-Lizenz-Server« (S. 260). Bevor wir nun zu der eigentlichen Installation kommen, muss zuvor ein Check durchgeführt werden. Mit der Version vCenter 4.0 Update 1 ist der Agenten Update Check hinzugekommen. Damit der Test durchgeführt werden kann, muss der Server, auf dem das vCenter läuft, zum vCenter 4.0 kompatibel sein. Es wird getestet, ob der vCenter Agent auf den Hosts geupdatet werden kann.
Abbildung 5.82
Verbindungsauswahl des Agenten Testers
Jetzt wählen Sie aus, wie auf die Daten zugegriffen werden soll. Es kann direkt die DSN genutzt werden oder die Verbindung wird über das vCenter geroutet.
Abbildung 5.83
240
Hostauswahl für den Agententest
VMware vCenter
Das Einfachste ist es, über Standard Mode alle vSphere Hosts für den Test zu wählen. Es können aber auch einzelne Hosts über den Custom Mode getestet werden.
Abbildung 5.84
Lauf des Agententests
Abschließend findet sich eine Übersicht aller getesteten Hosts einschließlich des Testergebnisses. Für jeden Host kann man sich das Ergebnis anschauen.
Abbildung 5.85
Host Testergebnis
Es wird das Release und die eventuellen Fehler angezeigt. In diesem Fall sind keine Probleme aufgetreten, und so können wir uns das Update vornehmen. Mit den folgenden Schritten werden erst alle Komponenten auf einem System installiert, um alle Fliegen mit einer Klappe zu schlagen. Die Komponenten
241
5.4
5
Installation
Lizenz-Server, vCenter Server, vCenter Converter und vCenter Update Manager können auf getrennten Systemen installiert werden. In diesem Fall fragt jede Installationsroutine nach der Netzwerkadresse des vCenter-Servers. Nach der Sprachauswahl werden automatisch benötigte Komponenten installiert. Anschließend wird der Registrierungsschlüssel erwartet (Abbildung 5.86). Geben Sie während der Installation keinen Key ein, installiert sich automatisch die Evaluation-Version des vCenter-Servers. Diese erlaubt es, den vCenter-Server für 60 Tage zu nutzen.
Abbildung 5.86
Software-Key für die vCenter-Installation
Anschließend haben Sie die Wahl zwischen der Nutzung einer bestehenden Datenbank und der Installation einer SQL-Server-2005-Express-Instanz mit der automatischen Anlage einer lokalen Datenbank (Abbildung 5.87).
Abbildung 5.87
242
Angabe der vCenter-Datenbank
VMware vCenter
Diese Entscheidung treffen Sie allein durch die Aktivierung Use an existing supported database. Wählen Sie den Punkt Install a MS SQL Server 2005 Express instance, stoßen Sie automatisch die SQL-2005-Express-Installation mit an, ansonsten müssen Sie die während der Vorbereitungen angelegte System-DSN inklusive Benutzername und Passwort angegeben. Geben Sie eine bereits bestehende Datenbank an, die schon vCenter-Informationen enthält, erscheint ein Dialog. Hier haben Sie zwei Möglichkeiten: Entweder ändern Sie die vorhandene Datenbank nicht, oder Sie löschen die existierende Datenbank komplett. Aktivieren Sie die Initialisierung durch Anklicken, werden alle bestehenden vCenter-Konfigurationen (auch alle historischen PerformanceWerte) gelöscht und müssen komplett neu eingerichtet werden. Dies empfiehlt sich meist bei Fehlern in der Datenbank. Wenn Sie das vCenter lediglich neu installieren, die Daten aber weiterhin Bestand haben sollen, müssen Sie immer den oberen Punkt (Abbildung 5.88) auswählen!
Abbildung 5.88
Abfrage bei bestehender vCenter-Datenbank
Als Nächstes folgt die Konfiguration des vCenter-Service. Entweder lassen Sie den Dienst unter einem System-Account laufen, oder Sie geben einen expliziten User-Account für den Dienst an (Abbildung 5.89). Wählen Sie einen dedizierten Account aus, wird diesem automatisch das Recht Log on as a service gewährt. Die Konfiguration einer neuen Funktion des vCenter-Servers erfolgt im nächsten Schritt. Es gibt zwei Möglichkeiten, einen vCenter-Server zu nutzen (Abbildung 5.90): Entweder entscheiden Sie sich für die Variante Create a standalone VMware vCenter Server instance, oder Sie wählen die Variante Join a vCenter Server group using linked mode to share information. Was ist nun der Unterschied? Die erste Auswahl entspricht der Installationsmethode der Vorgän-
243
5.4
5
Installation
Abbildung 5.89
User-Account für den vCenter-Server-Dienst
gerversion des vCenter Servers, dem VMware Virtual Center Server. Bei der zweiten Variante wird das vCenter in eine Gruppe von vCenter-Servern integriert, die über den vSphere-Client direkt angesprochen werden können. Diese Funktion ermöglicht dem Administrator, sich an einem Punkt anzumelden, aber trotzdem die Server-Farmen und virtuellen Maschinen zu administrieren, die von anderen vCenter-Servern verwaltet werden.
Abbildung 5.90
Auswahl des Installationstyps des vCenter-Servers
Die Standard-vCenter-Ports zur Kommunikation mit den vSphere-Servern bzw. dem WebAccess-Dienst sollten Sie wirklich nur in zwingenden Fällen vornehmen (Abbildung 5.91). Ändern Sie den Heartbeat-Port, müssen Sie daran denken,
244
VMware vCenter
die Firewall auf allen zu verwaltenden vSphere-Servern entsprechend freizuschalten. Bei Änderung auf Port 910 würde folgender Befehl notwendig: esxcfg-firewall –o 910,udp,in,vcport
Alternativ stellen Sie den Heartbeat-Eintrag in der services.xml (/etc/vmware/firewall) von 902 auf 910 um.
Abbildung 5.91
vCenter-Ports
Im Gegensatz zur Vorgängerversion des vCenter-Servers müssen Sie bei diesem Release verschiedene Komponenten händisch installieren. Automatisch wird nur der vCenter Orchestrator mitinstalliert. Ein dedizierter Lizenz-Server wird in reinen vSphere-Umgebungen nicht mehr benötigt. Er ist integrativer Bestandteil des vCenter-Servers. Betreiben Sie hingegen eine Mischumgebung, sind zwei Lizenz-Server einzusetzen: zum einen den im vCenter-Server integrierten und zum anderen den aus der Virtual-Infrastructure-3.x-Umgebung bekannten Lizenz-Server. Zur Installation des alten LizenzServers später mehr in diesem Kapitel. Installation vSphere-Client Ist die Installation des Servers abgeschlossen und möchten Sie von diesem Server auf das Management Tool zugreifen, müssen Sie noch den vSphere-Client installieren. Nach dem Aufruf der autostart.exe der vCenter-Server-DVD wählen Sie den Punkt zur Installation des Clients. Soll der Client auf einem anderen System installiert werden, gibt es eine einfache Möglichkeit, sich die Installationsdateien herunterzuladen, ohne dass Sie die
245
5.4
5
Installation
vCenter-DVD benötigen: Verbinden Sie sich über den Webbrowser verbindet mit dem vCenter-Server: https://. Klicken Sie in dem folgenden Fenster auf Herunterladen des vSphere-Clients, liefert der vCenter-Server direkt die Dateien zur Installation des Clients (Abbildung 5.92).
Abbildung 5.92
Download des Clients vom vCenter-Server
Nach dem Download starten Sie die Installation durch den Aufruf der Datei. Damit die Installation nicht fehlschlägt, muss das .NET Framework 3.5 SP1 installiert sein. Sollte noch eine ältere Version des Clients oder der Client-Tools auf dem Computer installiert sein, ist es ratsam, die alten Versionen vorher zu deinstallieren. Andernfalls kann es zu Kompatibilitätsproblemen kommen. Die Dialoge der Installation sind selbsterklärend. Zusätzlich können Sie das Host Update Utility installieren (Abbildung 5.93). Dieses Tool ermöglicht es dem Administrator, unabhängig vom vCenter mit einer eigenen GUI VMware-Hosts zu patchen.
246
VMware vCenter
Abbildung 5.93
Aktivierung der Installation des Host Update Utilitys
Rufen Sie den installierten Client auf, werden Sie, nach der Angabe des Benutzernamens und des zugehörigen Passworts, direkt mit dem vCenter-Server verbunden. Sie können Sich auch direkt mit einem vSphere-Host mit dem Client verbinden (Abbildung 5.94). Zusätzlich zu dem Server-Namen ist eine gültige Kennung mit passendem Passwort einzugeben.
Abbildung 5.94
Client-Anmeldung
Installation vCenter Update Manager Die Installation des vCenter Update Managers gestaltet sich ebenfalls recht unspektakulär. Nach den üblichen Abfragen zu Beginn der Routine werden die
247
5.4
5
Installation
Parameter des vCenter-Servers angefordert, damit sich der Update Manager in das vCenter integrieren kann.
Abbildung 5.95
vCenter-Parametereingabe
Bei dem User-Namen handelt es sich um einen Account des Server-Systems, auf dem der vCenter-Server installiert ist (Abbildung 5.95). Es folgt die Angabe der benutzten Zieldatenbank. Auch hier ist es, wie beim vCenter selbst, möglich, einen Microsoft-SQL-2005-Express-Datenbank-Server lokal zu installieren. Alternativ geben Sie eine gültige DSN-Verbindung zu einer bestehenden Datenbank an (Abbildung 5.96).
Abbildung 5.96
248
Konfiguration der Datenbankverbindung
VMware vCenter
Installieren Sie keine MS-SQL-Express-Datenbank-Version neu, ist im nächsten Schritt die passende Benutzerkennung nebst Passwort für die DSN-Verbindung einzugeben (Abbildung 5.97).
Abbildung 5.97
Accounting-Daten für die DSN Verbindung
Wird eine bereits mit Daten gefüllte Datenbank gefunden, werden Sie gewarnt und gefragt, ob die Daten überschrieben werden sollen. Wünschen Sie, dass mit einer leeren Datenbank angefangen wird, wählen Sie ja aus. Führen Sie ein Update auf einen vorhandenen Update Manager durch und sollen die Daten in der vorhandenen Update-Datenbank erhalten bleiben, wählen Sie nein.
Abbildung 5.98
Portkonfiguration für den Update Manager
249
5.4
5
Installation
Die Identifizierung des vCenter Update Managers und die Konfiguration der IPPorts finden im Folgenden statt (Abbildung 5.98). Auch wenn Sie die Applikation auf einen bereits vorhandenen vCenter-Server installieren, müssen Sie die IPPorts nicht ändern. Mit den Default-Werten gibt es keine Kollision. Der Update Manager hat ein Interface, das dafür zuständig ist, die Patches für die zu patchenden Applikationen aus dem Internet zyklisch und automatisch herunterzuladen. Sollte in Ihrem Netzwerk ein Proxy-Server stehen, der das verhindert, dann können Sie während der Installation die Proxy-Konfiguration mit User und Passwort hinterlegen (Abbildung 5.99). So ist gewährleistet, dass die PatchDatenbank immer auf dem aktuellen Stand ist.
Abbildung 5.99
Proxy-Konfiguration für den Update Manager
Im folgenden Schritt sollten Sie den Pfad für das Zielverzeichnis der Patches anpassen. Nach unserer Ansicht gehören die Patches in ein separates Verzeichnis und nicht in den Profile-Ordner. Optimal ist ein eigenes Verzeichnis auf der Festplatte. Für die Berechnung des Plattenbedarfs können Sie nun auf das bereits in Abschnitt 5.4, »VMware vCenter«, erklärte Excel-Sheet zurückgreifen. Die Applikation bindet sich nahtlos in den vCenter-Server ein. Starten Sie jetzt den vSphere-Client, finden Sie an dieser Stelle zuerst einmal keine zusätzlichen Funktionen. Über den Menüpunkt Plug-ins 폷 Plug-ins verwalten müssen Sie zuerst die Client-Komponente für den Update Manager installieren. Sie haben nun eine weitere Komponente, den Update Manager. Nach dem Aufruf können Sie die Applikation weitergehend administrieren und konfigurieren (Abbildung 5.100).
250
VMware vCenter
Abbildung 5.100
Update-Manager-Applikation
Installation Stand-alone-Download-Manager ohne Update Manager Es ist nicht immer möglich, sich mit einer Maschine, die im Firmennetzwerk steht, ins Internet zu verbinden. Aus diesem Grund können Sie die Updates für den Update Manager mit dem Stand-alone-Download-Manager-Server herunterladen und per DVD auf den vCenter-Server übertragen. Diese Möglichkeit eignet sich auch, wenn Sie häufig Installationen durchführen. Die Inbetriebnahme gestaltet sich dadurch einfacher, weil der initiale Download durch den Import von der DVD ersetzt wird. Dadurch müssen Sie nicht immer das Herunterladen der vielen Patches abwarten. Bevor Sie mit der Installation beginnen, ist es wichtig zu wissen, dass auch diese Komponente eine Datenbank benötigt. Die Auswahl ist Ihnen bereits bekannt: Entweder nutzen Sie die mitgelieferte MS-SQL-Express-Version, oder Sie verbinden sich via ODBC mit einer existierenden Datenbank. Die zugehörigen ODBCEinstellungen finden Sie in Abschnitt 5.4.3, »Vorbereitung der Datenbank«.
251
5.4
5
Installation
Die Installation des Download Managers wird mit einer eigenen Installationsroutine gestartet. Sie finden sie auf dem Installationsmedium der vCenter-DVD unter [DVD]\umds\VMware-UMDS.exe. Ist die Installationsroutine gestartet und die entsprechende Sprachversion ausgewählt, müssen Sie die EULA bestätigen. Im folgenden Dialog geben Sie an, ob eine vorhandene Datenbank genutzt werden soll oder ob die Installationsroutine automatisch einen Microsoft SQL Express 2005 Server mitinstallieren soll. In diesem Fall arbeiten wir mit der Express-Version des Microsoft SQL Servers. Es ist nämlich sehr unwahrscheinlich, dass auf der einen Seite die Zugriffe ins Internet nicht erlaubt sind, es andererseits aber möglich ist, aus der DMZ (Demilitarisierte Zone) auf ein zentrales Datenbanksystem zuzugreifen.
Abbildung 5.101
Proxy-Einstellungen für den Download Manager
Sollte der Zugriff auf das Internet nur über einen Proxy-Server möglich sein, sind in dem passenden Dialog die Einstellungen vorzunehmen (Abbildung 5.101). Jetzt benötigt die Routine die Angabe der Installationspfade. Auch hier ist es nicht sinnvoll, die Patches in das Profilverzeichnis kopieren zu lassen, deshalb empfehlen wir die Nutzung eines Verzeichnisses auf der Festplatte. Nach der Festlegung des Pfades wird überprüft, ob mindestens 20 GB Plattenplatz frei sind. Ist das nicht der Fall, erhalten Sie eine Warnmeldung (Abbildung 5.102).
Abbildung 5.102
252
Plattenplatzwarnung der Installationsroutine
VMware vCenter
Bitte lassen Sie sich nicht dadurch irritieren, dass der angegebene Pfad in der Fehlermeldung auf ein VI 3.x-Dokument verweist. Bei der Freigabe der neuen Software lag die neue Version des Excel-Sheets noch nicht vor. Mittlerweile gibt es aber ein Pendant für die Version vSphere 4.0. Es ist zu finden unter http:// www.vmware.com/support/vsphere4/doc/vsp_vum_40_sizing_estimator.xls. Sollte die Prüfung ergeben, dass Softwarevoraussetzungen fehlen, erscheint ein Hinweis, und das Defizit wird behoben. Ein Reboot ist erforderlich nach dem Abschluss der Installationsroutine. Nach der Installation findet sich das Tool im Installationsverzeichnis. Sie kommen bei der Nutzung des Tools an der Kommandozeile nicht vorbei; eine GUI gibt es für diese Softwarekomponente nicht. Installation vCenter Converter Auch der vCenter Converter wird über eine eigene Installationsroutine bereitgestellt. Dieses Tool wird genutzt, um Computersysteme in die virtuelle Infrastruktur zu importieren, wobei Sie die Parameter der zu importierenden Maschine während des Vorgangs anpassen können. Für die Installation wählen Sie im Normalfall den typischen Weg. Auch dieses Tool benötigt für die Verbindung zum vCenter-Server die Angabe von UserName, Passwort und einem IP-Port (Abbildung 5.103).
Abbildung 5.103
User und Kommunikationsport zum vCenter
Damit die Applikation im Netzwerk kommunizieren kann, werden weitere Netzwerkports benötigt. Die Konfiguration nehmen Sie in dem folgenden Abschnitt vor (Abbildung 5.104). Auch hier kollidiert der Standard nicht mit den anderen Ports, die im virtuellen Umfeld genutzt werden.
253
5.4
5
Installation
Abbildung 5.104
Portkonfiguration vCenter Converter
Für die Identifizierung im Netz lässt sich im Folgenden auswählen, ob Sie den Namen bevorzugen, oder ob der Verbindungsaufbau über die IP-Adresse erfolgt. Auch der Converter benötigt eine Client-Komponente, die Sie noch über den vSphere-Client installieren und aktivieren müssen (Abbildung 5.105).
Abbildung 5.105
Installation des Converter-Clients
Sind die Arbeiten abgeschlossen, können Sie über einen zusätzlichen Menüpunkt im Kontextmenü des Hosts Server importieren und individuell einrichten. Sobald die Installation fehlerfrei durchgelaufen ist, können Sie den erfolgreichen Start der Dienste in der Windows-Ansicht (Abbildung 5.106). Nun benötigen Sie lediglich eine Verbindung mit dem vSphere-Client zum vCenter-Server und können loslegen. Vom vCenter Converter gibt es auch eine Stand-alone-Version. Auf die Installation dieser Version gehen wir in Abschnitt 5.5, »VMware vCenter Converter Standalone«, ein.
254
VMware vCenter
Abbildung 5.106
Dienste VMware vCenter und Komponenten
Installation vCenter Guided Consolidation Auch in der aktuellen Version gibt es weiterhin ein Tool zur Vermessung von physischen Servern als Grundlage zur Virtualisierung. Das in den Vorversionen unter dem Namen »VMware Capacity Planner« bekannte Tool liegt nun in einer abgespeckten Version vor. Diese Light-Version hört nun auf den Namen »vCenter Guided Consolidation«. Die Installation wird gestartet über das Startfenster der Installations-DVD (Abbildung 5.81). Nach dem Aufruf der Installationsroutine und der Beantwortung der Sprachauswahl ist die EULA zu bestätigen. Als Nächstes können Sie den Installationspfad anpassen. Der folgende Eingabedialog fordert die Angabe eines Accounts, der in der zu scannenden Area lokaler Administrator auf allen Maschinen ist (Abbildung 5.107).
Abbildung 5.107
Angabe des Scan-Accounts für den Datensammler
255
5.4
5
Installation
Die Ports, über die die Applikation kommuniziert, sind im nächsten Eingabefenster zu konfigurieren.
Abbildung 5.108
Guided-Consolidation-Portkonfiguration
Wie auch bei allen anderen Produkten können Sie die vCenter Guided Consolidation ohne Portkollision auf dem vCenter-Server installieren. Aus diesem Grund empfehlen wir die Übernahme der Standardeinstellungen (Abbildung 5.108).
Abbildung 5.109
Verbindung zum vCenter-Server
Jetzt wird eine Eingabe verlangt (Abbildung 5.109), wie der vCenter-GuidedConsolidation-Server sich im Netzwerk meldet. Es gibt grundsätzlich zwei Möglichkeiten: entweder über die IP-Adresse oder über den FQDN. Jetzt findet die
256
VMware vCenter
eigentliche Installation statt. Mit dem Abschluss der Installation finden Sie im vSphere-Client einen neuen Punkt: Auf der Startseite des vCenters ist unter dem Punkt Solutions & Applications ein Icon für die neu installierte Applikation hinzugekommen. Mit dem Aufruf lassen sich die Konfigurationsparameter für den Service anpassen. Nähere Informationen zu dem Tool lesen Sie in Kapitel 16, »Kapazitätsplanung mit dem VMware Capacity Planner«. Installation in einer virtuellen Maschine Wurde seitens VMware die Sinnhaftigkeit eines vCenter-Servers in einer virtuellen Maschine zu Zeiten einer Version 1.x noch beharrlich bestritten, wird seit Version 2.x diese Lösung als sehr vorteilhaft angepriesen. Die Vorteile liegen wirklich auf der Hand, da das System in der virtuellen Maschine auch deren Eigenschaften unabhängiger Hardware und schneller Wiederherstellbarkeit genießt. Zusätzlich fördert die VMware HA-Funktion die Ausfallsicherheit. Allerdings bestehen auch folgende zwei Nachteile, die Sie bei Ihrer Entscheidung, ob Sie die virtuelle oder die physische Variante wählen, im Vorfeld berücksichtigen sollten. 1. Verwaltungssicherheit: Unabhängig von HA besteht bei einem Ausfall der virtuellen Infrastruktur die Gefahr, dass das betreuende Betriebsteam sich ohne den vCenter-Zugriff nicht zu helfen weiß und so der Wiederanlauf erschwert wird. Daher sollten Sie auf jeden Fall immer wissen, auf welchem Server die vCenter-VM läuft, und dem Betrieb den direkten vSphere-ClientZugriff auf diesen vSphere-Server erklären. Alternativ bieten sich kleine Programme an, die automatisch die vCenter-VM (und gegebenenfalls DatenbankServer) gezielt neu starten. 2. Performance: Die Leistungsfähigkeit einer VM wird vor allem durch die Konsolidierung mehrerer Systeme auf eine Hardware eventuell eingeschränkt. Wird die virtuelle Infrastruktur zu groß und umfasst mehrere Hundert virtuelle Maschinen, ist womöglich die komplette Leistungsfähigkeit eines physischen Systems nötig, um schnelle Antwortzeiten zu gewährleisten. Was ist nun zu beachten, wenn Sie den vCenter-Server auf einer virtuellen Maschine installieren, und wie viele Ressourcen werden für die VM benötigt? Auch wenn VMware mindestens zwei CPUs für einen vCenter-Server fordert, so zeigt doch die Praxis, dass in kleinen Umgebungen auch eine CPU ausreichend ist. In Tabelle 5.3 haben wir einmal eine Auflistung zusammengestellt, wann wie viele Ressourcen für den vCenter-Server nötig sind.
257
5.4
5
Installation
Anzahl ESX-Hosts
CPUs
Memory
Betriebssystem
10
1
3 GB
Windows 64-Bit (bevorzugt) Windows 32-Bit
> 10 bis 50
2
4 GB
Windows 64-Bit (bevorzugt) Windows 32-Bit
> 50 bis 200
4
4 GB
Windows 64-Bit (bevorzugt) Windows 32-Bit
> 200 Tabelle 5.3
4
8 GB
Windows 64-Bit (Vorgabe)
Ressourcenbedarf des vCenters
Damit Sie den vCenter-Server in der virtuellen Umgebung auch wiederfinden, sollten Sie die entsprechende VM fest auf einem Host »verankern«. Dazu bietet sich entweder der erste oder der letzte Host in einer Farm an. Deaktivieren Sie das DRS für die virtuelle Maschine auf welcher der vCenter Server aktiv ist. Bei den HA-Einstellungen für den virtuellen Server ist das Startup-Level auf high zu setzen. Vernachlässigen Sie dabei nicht die virtuellen Server, die weitere wichtige Dienste für den vCenter-Server zur Verfügung stellen, wie z. B. ADS, DNS und den zugehörigen Datenbank-Server. Der virtuelle vCenter-Server startet nur einwandfrei, wenn die oben beschriebenen Dienste zur Verfügung stehen. Aus diesem Grund sollten Sie bei den Systemen, die ebenfalls virtuell sind, die Startpriorität heraufsetzen. Zu guter Letzt sollten Sie die Shares der vCenter-VM auf high setzen, damit immer genug Ressourcen für das Management der virtuellen Infrastruktur zur Verfügung stehen. Einzelinstallation VMware-Lizenz-Server In bestimmten Fällen, z. B. aufgrund von Unternehmensvorgaben, ist es notwendig, den Lizenz-Server des vCenters unabhängig von diesem auf einem anderen System zu installieren. Diese Vorgehensweise ist aber nur für einen Lizenz-Server möglich, der zusätzlich in einer Mischumgebung benötigt wird. Der Server für die noch vorhandenen VI 3.x-Systeme kann separiert werden. Der Lizenz-Server für vSphere ist integraler Bestandteil des vCenters und kann nicht getrennt werden. Den getrennten VI 3.x-Lizenz-Server können Sie mittels Download-Paket oder über die Installations-DVD (VI 3.x) (Verzeichnis VMware-VIMSetup-2.5.0#####\vpx\VMware-licenseserver.exe) installieren.
258
VMware vCenter
Die Installation erfordert nur die Angabe eines Ports, den Sie bei Abweichung von 27000 dem vCenter-Server und den betroffenen VMware-vSphere-Servern mitteilen müssen. In jedem Fall müssen Sie die Netzwerkverbindung und die Portfreigabe (Firewall) gewährleisten. Würde die Verbindung zwischen vSphere/VC-Server und dem Lizenz-Server für mehr als 14 Tage unterbrochen, wäre danach kein Neustart der virtuellen Maschinen mehr möglich. Plug-ins Mit der Version 3.5 wurde eine neue Schnittstelle im Virtual Center eingeführt. Diese sogenannte Plug-in-Schnittstelle hat auch in der neuen Version 4.0 des vCenters weiterhin Bestand. Sowohl der Update Manager als auch der Converter sind die beiden Standard-Plug-ins.
Abbildung 5.110
Verwaltung der Plug-ins
Die Plug-ins erreichen und verwalten Sie nach der erfolgreichen Verbindung mit einem vCenter-Server über Plug-Ins 폷 Plug-Ins verwalten (Abbildung 5.110).
Abbildung 5.111
Verfügbare und bereits installierte Plug-ins
Innerhalb des Plug-in-Managers (Abbildung 5.111) sehen Sie verfügbare und bereits installierte Plug-ins. Die Plug-ins werden auf dem Client-PC installiert und kommunizieren von dort mit dem vCenter. Über das Kontextmenü aktivieren oder deaktivieren Sie die Plug-ins. In Abbildung 5.111 sind zwei Plug-ins zu sehen, die noch nicht installiert und aktiviert sind. Ein Klick auf Herunterladen und installieren führt genau die beschriebene Aktion durch.
259
5.4
5
Installation
5.4.5
vCenter-Protokolldateien
Damit eine erfolgreiche Analyse von möglicherweise auftretenden Problemen durchgeführt werden kann, sollten Sie wissen, wo die Dateien liegen, denen Sie nähere Informationen entlocken können. Die Dateien finden Sie in den folgenden Verzeichnissen. Protokoll
Pfad
Installationsprotokoll
%tmp%\vim*.log
vCenter-Server- und Datenbankzugriff
%ALLUSERSPROFILE%\Application Data\VMware\ VMware VCenter\Logs
vCenter Converter Enterprise
%ALLUSERSPROFILE%\Application Data\VMware\ VMware Converter Enterprise\Logs
vCenter-Update-Manager- und Datenbankzugriff
%ALLUSERSPROFILE%\Application Data\VMware\ VMware Update Manager\Logs
Tabelle 5.4
5.5
Pfade zu den Protokolldateien der vCenter-Komponenten
VMware vCenter Converter Standalone
Der VMware vCenter Converter ist auch in einer Version erhältlich, die ohne vCenter-Server lauffähig ist. Hier gehen wir kurz auf die Installation des Produktes. Ist das Installationsprogramm gestartet worden, erscheint, nach der Bestätigung der EULA, das Fenster für die Angabe des Installationspfades. Hier fällt schon auf, dass es sich um ein eigenes Produkt handelt, es installiert sich nämlich in einen anderen Pfad als der vCenter Converter. Es folgt die Auswahl des Installationstyps (Abbildung 5.112).
Abbildung 5.112
260
Installationsauswahl vCenter Converter Standalone
VMware Consolidated Backup
Der obere Punkt führt einfach eine Installation durch. Konvertierungen können von hier aus verwaltet werden. Keine weiteren Einstellmöglichkeiten trennen den Anwender von der endgültigen Installation. Beim zweiten Punkt besteht die Möglichkeit, Teile der Client-Server-Applikation vCenter Server Standalone zu installieren. Insgesamt ist es möglich, einen Agenten, einen Client oder den Server selbst zu installieren. Beim Server handelt es sich um den Server-Applikation-Teil. Der Client wird benötigt, um auf den Server-Teil zuzugreifen. Der Agent wird auf den Systemen installiert, die übernommen werden sollen. Bei der Standardinstallation werden alle drei Komponenten zusammen installiert. Im folgenden Dialog können Sie die Auswahl der Komponenten aber noch anpassen. Auch diese Applikation benötigt Ports für die Kommunikation, diese sind jetzt einstellbar (Abbildung 5.113).
Abbildung 5.113
Portkonfiguration vCenter Converter Standalone
Auch hier gilt, dass Sie die Ports nur ändern sollten, wenn es zwingende Gründe dafür gibt. Sobald Sie die Eingabe bestätigen, beginnt die eigentliche Installation der Softwarekomponenten. Sie können die Installation mit dem automatischen Start des Clients abschließen. Jetzt steht das Tool für den Import von Computern in die virtuelle Infrastruktur bereit.
5.6
VMware Consolidated Backup
VMware Consolidated Backup (VCB) besteht aus einer Installationsdatei und ist in der VMware-vSphere-Sektion auf der Download-Webseite (Abbildung 5.1,
261
5.6
5
Installation
Seite 176) als VMware-vcb-#####.exe zu finden. Außerdem existieren für manche Backup-Softwareprodukte weitere Integrationsmodule, die zur besseren Zusammenarbeit zwischen Backup-Software und Consolidated-Backup-Schnittstelle dienen.
Abbildung 5.114
Windows-Automount abschalten
Ein sehr wichtiger Schritt vor der Installation von VCB ist die Deaktivierung des Windows-Automounter. Dieser sorgt nämlich im schlimmsten Fall für das Markieren neuer Partitionen durch NTFS-Signaturen und kann besonders bei NTFSformatierten Raw-Device-Mappings für Ärger sorgen. Bei VMFS-Partitionen ist sogar Datenverlust möglich. Rufen Sie daher wie in Abbildung 5.114 diskpart auf, und schalten Sie mit automount disable den Automounter ab. Dieser ist dann auch nach einem Neustart deaktiviert! Die Installationsroutine läuft sehr einfach und ohne viele Einstellungsmöglichkeiten ab. Allerdings installiert VCB einen zusätzlichen VMware-Virtual-VolumeStorage-Bus-Treiber. Dieser Treiber ist für die spätere Verbindung einer VMFSPartition durch Windows verantwortlich, die ohne diesen Treiber niemals möglich wäre.
5.7
Hochverfügbarkeit vCenter-Server
Der vCenter-Server von VMware ist, genauso wie der Virtual Center-Server für die früheren Versionen, extrem wichtig für das Management von virtuellen Infrastrukturen. Grundlegende Funktionen stehen nicht mehr zur Verfügung, wenn der Management-Server ausfällt. Diesen Aspekt sollten Sie bei der Planung von virtuellen Infrastrukturen berücksichtigen. In die Planung fließen die folgenden Faktoren ein: Welche Funktionen des vCenter-Servers werden genutzt, ist die Datenbank auf dem vCenter-Server installiert, und wie lange kann ein Ausfall verkraftet werden?
262
Hochverfügbarkeit vCenter-Server
5.7.1
Manuelle Hochverfügbarkeit
Eine manuelle Hochverfügbarkeit setzt im Problem- oder Fehlerfall den Eingriff eines Administrators voraus. Es sind aber weitere Voraussetzungen zu erfüllen, damit ein solches Konstrukt funktioniert. Aber von Anfang an. Wir haben bereits beschrieben, dass der vCenter-Server aus drei Komponenten besteht: zum Ersten die benötigte Datenbank, zum Zweiten die vCenter-Applikation selbst und zum Dritten die zusätzlichen Software-Komponenten. Die manuelle Hochverfügbarkeit arbeitet mit einem sogenannten Cold-Standby-Server. Das bedeutet nichts weiter, als dass ein identischer vCenter-Server parat steht und aktiviert wird, wenn das produktive System ausgefallen ist oder Probleme bereitet. Diese Ausfallsicherheit kann aber nur funktionieren, wenn das abzubildende System ein statisches ist, also keine beweglichen Daten enthält. Für den vCenter-Server würde das bedeuten, dass die Datenbank auf einem separaten Server zur Verfügung gestellt werden muss. Ist der Management-Server mit allen Komponenten fertig installiert, wie bereits beschrieben ohne Datenbank, erstellen Sie von ihm ein Duplikat. Es ist unerheblich, ob Sie den Server physisch oder virtuell aufbauen. Nutzen Sie ein virtuelles System, können Sie zur Erstellung des Standby-Servers einfach den VMware Converter einsetzen. Wichtig ist nur, dass Name und IP-Adresse der Server identisch sind. Beide Systeme dürfen aber nicht gleichzeitig am Netz hängen, das würde zu Problemen führen. Die komplett identische Identität der Systeme ist wichtig, damit nach der Inbetriebnahme des Standby-Systems der Management Server unter identischem Namen erreichbar ist. Andernfalls müssten bei einem Ausfall nicht nur der Server, sondern auch die Clients angepasst werden. Im Fehlerfall schließen Sie einfach den Netzwerkport des produktiven Servers und öffnen den Port des Standby-Systems. Der Weg zurück läuft genauso ab. Selbstverständlich müssen Sie sich für den Datenbank-Server ähnliche Gedanken machen. Schwierig ist in diesem Fall, das alle Konfigurationsdaten des vCenterServers in der Datenbank abgespeichert werden. Auch hier könnte ein ColdStandby-System zum Einsatz kommen. Wichtig ist an der Stelle, dass Sie regelmäßig Sicherungen der Datenbank durchführen. Vor der Produktivsetzung des Cold-Standby-Datenbanksystems müssten Sie den Datenbankbestand auf den letztmöglichen Stand bringen. Es sollte Ihnen klar sein, dass ein Teil der Performance-Daten verlorengeht, wenn der Ausfall des Datenbank-Servers auf diese Art und Weise abgefangen werden soll.
263
5.7
5
Installation
5.7.2
Hochverfügbarkeit mit Microsoft Cluster
Darf die Ausfallzeit des Management-Systems nur so kurz wie möglich sein, dann ist es möglich, den vCenter-Server zu verclustern. Zum Einsatz kommt in diesem Fall der Microsoft-Cluster-Server. Als Erstes installieren Sie den Microsoft-Cluster-Server nach den Vorgaben des Herstellers und konfigurieren ihn. Es folgt das Anlegen einer Ressourcengruppe für den vCenter-Server. Zu Beginn richten Sie aber nur das Laufwerk, der Netzwerkname und die IP-Adresse ein. Im nächsten Schritt installieren Sie den vCenter-Server und seine Komponenten auf dem ersten Cluster-Knoten. Bitte bedenken Sie, dass Sie in Mischumgebungen jetzt auch den Lizenz-Server für die ESX-3.x-Hosts mitinstalliert müssen. Bei einer solchen Mischumgebung sollten Sie darauf achten, dass der Ablageort für die Lizenzdateien auf einem gemeinsam nutzbaren (shared) Laufwerk liegt. Genauso sollten Sie mit den Files verfahren, die anfallen, wenn der vCenter Update Manager zum Einsatz kommt. Sind die Arbeiten auf dem ersten Knoten abgeschlossen, testen Sie mit dem vSphere-Client, ob die Applikationen ordnungsgemäß funktionieren. Ist der Test erfolgreich abgeschlossen worden, setzen Sie die Startart der VMware-Dienste auf manuell. Jetzt installieren Sie in exakt der gleichen Art und Weise die Applikationen auf dem zweiten Knoten. Wichtig für Sie ist zu wissen, dass die Applikation nicht von Haus aus cluster-fähig ist. Das liegt zum Teil auch daran, dass applikationsrelevante Daten in Verzeichnissen liegen, die nicht auf ein gemeinsam nutzbares Laufwerk installiert werden können. Auch in der neuen Version hat sich das nicht geändert; unverständlicherweise werden immer noch Dateien im Profilpfad abgelegt. Die Konfigurations- und Log-Files liegen unter C:\Documents and Settings\All Users\Application Data\VMware\. Aus diesem Grund hat der Installateur dafür zu sorgen, dass dieses Verzeichnis automatisch repliziert wird. Auch jetzt ist die Installation auf dem zweiten Knoten mit dem vSphere-Client zu erproben. Sind diese ersten Tests erfolgreich, können Sie mit den weitergehenden Arbeiten beginnen. Als Erstes stellen Sie die Startart der Dienste auf manuell. Richten Sie nun mit dem Cluster-Management-Tool von Microsoft die in Tabelle 5.5 gelisteten Ressourcen ein. Bei der Einrichtung sind die Abhängigkeiten einzuhalten, damit die Dienste auch einwandfrei starten. Abbildung 5.115 zeigt die einzuhaltenden Abhängigkeiten.
264
Hochverfügbarkeit vCenter-Server
Dienst
Typ
vCenter Storage
gemeinsam genutzter Plattenplatz
vCenter-IP-Adresse
IP-Adresse
vCenter-Name
Netzwerkname
vCenter-Server
generischer Dienst
Vpxd
vCenter Server WebAccess
generischer Dienst
Vctomcat
Lizenz-Server VI 3
generischer Dienst
VMware License Manager
vCenter Mountservice
generischer Dienst
vmountVpx
vCenter Orchestrator
generischer Dienst
VMOConfiguration
vCenter Converter
generischer Dienst
vmware-converter
vCenter Update Manager
generischer Dienst
vmware-ufad-vci
VMware-Upgrade-Hilfsdienst
generischer Dienst
VMUpgradeHelper
vCenter Collector Provider Service
generischer Dienst
VmwCpProviderServerForVC
vCenter Collector Service
generischer Dienst
VmwCpCollectorServerForVC
vCenter VCMSDS
darf nicht verclustert werden
Tabelle 5.5
Service-Name
Dienste des vCenter-Servers im Cluster
Abbildung 5.115
Abhängigkeiten Cluster-Ressourcen
265
5.7
5
Installation
Alle generischen Dienste müssen in einem separaten Ressourcenmonitor laufen. Das Feld für die Startparameter muss frei bleiben, hier erfolgt kein Eintrag. Sollte der Wunsch bestehen, die IP-Adresse des vCenter-Servers fest zu hinterlegen, sollten Sie sie nicht in der Registry, sondern im Konfigurations-File eintragen; es ist dann nicht notwendig, einen Wert der Registrierung zu spiegeln. Sind die Arbeiten abgeschlossen, sollten Sie die gesamte Konfiguration testen. Beginnen Sie mit einem Knoten, und prüfen sie den Zugriff auf sämtliche Dienste. Bei erfolgreichem Abschluss verschieben Sie die Ressourcen auf den zweiten Knoten und wiederholen die zuvor auf dem ersten Knoten durchgeführten Arbeiten auch auf dem zweiten Knoten. Sollten keine Probleme auftreten, haben Sie eine funktionierende Failover-Lösung für den vCenter-Server von VMware. Wichtig bei der Fehlerbehebung ist, dass Sie wissen, wann welcher Knoten aktiv ist oder war, denn in diesem Pfad liegen auch die Log-Dateien des vCenter-Servers. Bei der Replikation ist also darauf zu achten, dass die Richtung stimmt, sonst gehen Log-Files verloren, oder die Fehlerbehebung gelingt nicht. Wem der Konstrukt der Replikation zu unsicher ist, dem sei eine weitere Möglichkeit an die Hand gegeben, die diesen Makel ausbügelt. Es gibt eine Option, um dieses Defizit auszumerzen. Nachträglich ist das nicht möglich, Sie müssen diese Arbeiten durchführen, bevor Sie die vCenter-Applikationen installieren. Zusätzlich zu den Ressourcen, die schon in der zuerst beschriebenen Variante benötigt werden, benötigen Sie ein gemeinsam nutzbares Laufwerk, das Sie ebenfalls in die Cluster-Gruppe des vCenters aufnehmen. Natürlich können Sie auch das bereits vorhandene Laufwerk einfach vergrößern. Hilfen zur Festlegung der Plattengröße finden Sie in Abschnitt 5.4.4, »Installation vCenter und Komponenten«, für den Update Manager. Dieser nimmt den mit Abstand größten Teil der Platte in Anspruch. Im Internet finden sich Tools, die es ermöglichen, bootresistent eine Festplatte, für den Cluster als Laufwerk sichtbar, als Verzeichnis unter einem Laufwerksbuchstaben zur Verfügung zu stellen. Bevor Sie nun mit der Installation auf dem ersten Knoten beginnen, erstellen Sie händisch das Verzeichnis C:\Documents and Settings\All Users\Application Data\VMware\. Nun hängen Sie die neue gemeinsam nutzbare Festplatte an das neu erstellte Verzeichnis. Wie oben beschrieben stellen Sie nun den ersten Knoten fertig, das heißt, Sie installieren jetzt alle benötigten Komponenten. Achten Sie darauf, dass alle relevanten Daten auf dieses Laufwerk installiert werden. Vergessen Sie auch hier nicht den VI 3.x-Lizenz-Server, wenn Sie eine Mischumgebung haben.
266
Hochverfügbarkeit vCenter-Server
Ist ein erfolgreicher Test abgeschlossen, ändern Sie die Startart aller betroffenen VMware-Dienste auf manuell. Jetzt verschieben Sie die vCenter-Ressourcengruppe auf den zweiten Knoten und wiederholen das Ganze noch einmal. Orientieren Sie sich an der Reihenfolge der Installations- und Konfigurationsarbeiten des ersten Knotens. Auch hier sollten Sie abschließend einen Test durchführen. Ist dieser ebenfalls positiv, können Sie mit der Einrichtung der generischen Dienste beginnen, wie bereits oben beschrieben. Mit dieser Konfiguration haben Sie einen geclusterten vCenter-Server, in dem alle relevanten Daten auf einer gemeinsam nutzbaren Festplatte liegen. Hinweis zur Verclusterung von vCenter-Servern Die Verclusterung von vCenter-Servern, die verknüpft sind, wird nicht unterstützt. Nennen Sie eine solche Konfiguration Ihr Eigen, haben Sie keinen Support.
5.7.3
vCenter Server Heartbeat
Kurz vor der Vorstellung der neuen Version mit Namen vSphere hat VMware eine für den vCenter-Server vorgesehene Komponente für den damals noch aktuellen Virtual Center Server 2.5 vorgestellt. Es handelt sich um den vCenter Server Heartbeat. Diese Softwarekomponente ermöglicht es dem Administrator, mit relativ einfachen Mitteln einen automatischen Failover auf einen zweiten vCenter-Server durchzuführen, wenn es zu Fehlern auf dem Hauptsystem kommt. In diesen Failover sind alle Komponenten eingeschlossen, also kümmert sich die Applikation nicht nur um das vCenter, sondern auch um die Datenbank. Bevor wir auf die Installation eingehen, möchten wir kurz beschreiben, wie die Applikation arbeitet. Es handelt sich nicht um eine Cold-Standby-Lösung, sondern um eine sogenannte Hot-Standby-Variante. Welche Randbedingungen waren für VMware bei der Entscheidung für den Einsatz dieses Produkts wichtig? Es war von entscheidender Bedeutung, dass das Hot-Standby-System mit identischem Namen und identischer IP-Adresse im Netz erreichbar ist, wenn es zum Einsatz kommt. Außerdem ist es wichtig, eine einfache Bedienoberfläche für das Management der Funktion zu haben. Wie funktioniert das nun? Sie stellen ein Mastersystem bereit, das eine zweite Netzwerkkarte erhält. Hier richten Sie ein privates Netz ein. Mit einem Tool Ihrer Wahl duplizieren Sie die Mastermaschine auf eine zweite Hardware oder auf eine virtuelle Maschine. Bei diesem zweiten Server ist nur das private Netzwerk aktiv. Über dieses private Netzwerk werden alle Änderungen repliziert, die auf dem Master-Server passieren. Fällt nun der Master-Server aus, wird dessen produktives Netzwerk deaktiviert, und anschließend wird das produktive Netz auf der
267
5.7
5
Installation
Backup-Maschine aktiviert. Nun erfolgt der Zugriff mit identischem Namen und identischer IP-Adresse auf die Backup-Maschine, ohne Änderungen am Client vornehmen zu müssen. Achten Sie bei der Einrichtung der Netzwerkkarten auf die Reihenfolge. Die Karte für den Clientzugriff muss an erster Stelle stehen (Abbildung 5.116).
Abbildung 5.116
Reihenfolge der Netzwerkkarten
Wir können Ihnen nur empfehlen, die Netzwerkkarten sprechend zu benennen, damit Sie sie immer einfach auseinanderhalten können. Die Software kann nur auf vCenter-Servern installiert werden, die weder Domain-Controller sind bzw. den GlobalCatalog halten noch DNS-Server sind. Eine installierte SQL-Datenbank wird mit geschützt. Die Softwarekomponente, die hier zum Einsatz kommt, entstand in Zusammenarbeit mit der Firma Neverfail. Im Folgenden beschreiben wir den Installationsweg mit geclontem Master-Server. Die andere, nämlich die zweite Maschine über andere Mechanismen bereitzustellen, ist detailliert im Handbuch beschrieben. Würden wir hier alle Optionen beschreiben, würde das den Umfang des Buches sprengen. So möchten wir nun als Beispiel nur auf den Weg mit geclontem Master-Server eingehen. Aber nun zur Installation: Als Erstes duplizieren Sie den bestehenden und voll funktionsfähigen vCenter-Server. An dem geclonten System dürfen Sie keine Änderungen vornehmen, alle Einstellungen müssen so bleiben, wie sie sind. Achten Sie darauf, dass bei einem Start des geclonten Systems die Netzwerkports deaktiviert sind. Andernfalls wären zwei Computer mit identischem Namen, IP
268
Hochverfügbarkeit vCenter-Server
und SID im Netzwerk, was die Funktion des Managementsystems beeinträchtigen kann. Soll für das Backup vCenter eine virtuelle Maschine genutzt werden, erstellen Sie einfach mit der Cloning-Funktion des vCenters oder dem vCenter Converter ein Duplikat des vorhandenen Servers. Ist der Clone erstellt, sind die Optionen Connect at power on und Connected beider Netzwerkkarten zu deaktivieren. Den zweiten Server können Sie nun, ohne Probleme zu verursachen, starten. Danach melden Sie sich mit administrativen Rechten am System an und passen die IP-Adresse des Heartbeat-Netzwerks an. Auf diesem Netzwerkbein darf kein Gateway und kein DNS oder WINS eingetragen sein. Die Funktionen Register this connection’s addresses in DNS und Use this connection’s DNS suffix in DNS registration sind zu deaktivieren, genau wie die Option NetBIOS over TCP/IP. Sind diese vorbereitenden Arbeiten abgeschlossen, können Sie die Optionen Connect at power on und Connected der Heartbeat-Netzwerkkarte wieder aktivieren. Jetzt sind die Vorbereitungen für die eigentliche Installation abgeschlossen. Die Softwareinstallation startet über den Aufruf der setup.exe-Datei. Nach dem Aufruf wird abgefragt, welche Komponenten installiert oder deinstalliert werden sollen. Bei der Installation ist es nicht möglich, mehrere Komponenten auf einmal zu installieren. Berücksichtigen Sie, dass Sie die Komponenten auf beiden Servern einzeln installieren müssen. Wählen Sie zuerst den produktiven Server aus, und installieren Sie hier die Heartbeat-Komponente (Abbildung 5.117). Es wird Ihnen, genauso wie uns, positiv auffallen, dass auf der linken Seite des Installationsfensters eine recht ausführliche Installationshilfe zu finden ist.
Abbildung 5.117
Festlegung der Installationsoptionen
269
5.7
5
Installation
In der folgenden Abfrage geben Sie an, auf welchem Knoten die Installation durchgeführt werden soll (Abbildung 5.118).
Abbildung 5.118
Angabe, auf welchem System die Software installiert wird
Für die Installationsroutine ist es wichtig zu wissen, wie der zweite Server erstellt wurde. Wählen Sie die entsprechende Option (Abbildung 5.119).
Abbildung 5.119
270
Auswahl des zweiten Systems
Hochverfügbarkeit vCenter-Server
Bestätigen Sie die Lizenzbestimmungen. Es folgt die Angabe des Zielpfades. Ein Desktop-Icon wird automatisch erstellt. Im nächsten Dialog bestimmen Sie, über welchen Netzwerkpfad der Channelbzw. Heartbeat-Traffic läuft (Abbildung 5.120).
Abbildung 5.120
Auswahl des Channel- bzw. Heartbeat-Netzwerks
Für eine einwandfreie Funktion der Applikation ist zu konfigurieren, welche IPAdressen für den Heartbeat genutzt werden. Diese Auswahl treffen Sie über den Add-Button. Die IP-Adressen des Servers, auf dem installiert wird, wählen Sie links in der Dropdown-Box aus. Die IP des zweiten Servers ist händisch einzutragen. Wenn möglich, sollten Sie auch hier die Portkonfiguration nicht ändern (Abbildung 5.121). Tragen Sie im Folgenden das Client-Zugriffs-Netzwerk ein. Wird der Channel über ein LAN oder ein WAN betrieben? Treffen Sie hier die Auswahl WAN, benötigen Sie neben den beiden Heartbeat-Adressen einen Account, der administrative Rechte auf dem zweiten System besitzt. Die produktive IP-Adresse ist ebenfalls notwendig. Die Auswahlbox stellt Ihnen die noch nicht »verbrauchten« Adressen zur Auswahl. Wieder fügen Sie über Add den Parameter hinzu.
271
5.7
5
Installation
Abbildung 5.121
Channel-Adressen und Portkonfiguration
Bestimmen Sie, welche Applikation geschützt werden soll, und noch einmal wird erfragt, ob der Channel über WAN erstellt worden ist. In unserem Beispiel sind der vCenter- und der SQL-Server auf einem System installiert, deshalb sehen Sie bei uns die entsprechende Auswahl (Abbildung 5.122).
Abbildung 5.122
272
Auswahl der zu schützenden Komponenten
Hochverfügbarkeit vCenter-Server
Damit die Installation auf dem zweiten Server erfolgen kann, wird ein Verzeichnis benötigt, in dem die Installationsroutine Backup-Daten ablegen kann. Dies kann sowohl auf einem lokalen Pfad als auch auf einem Share erfolgen (Abbildung 5.123).
Abbildung 5.123
Pfadangabe für Backup-Dateien
Nach der Anzeige der Installationszusammenfassung wird überprüft, ob alle Voraussetzungen für eine erfolgreiche Installation erfüllt sind. Wird keine Fehlermeldung angezeigt, können Sie mit der eigentlichen Installation beginnen. Erschrecken Sie nicht – es wird noch ein Packet-Filter installiert, so dass – je nachdem, wie Sie auf dem Server angemeldet sind – die Verbindung kurz unterbrochen sein kann. Nach dem Abschluss der Installation stehen Ihnen einige Icons auf dem Desktop zur Verfügung, mit denen Sie die Applikation konfigurieren und betreiben können (Abbildung 5.124).
Abbildung 5.124
Icons für den Applikationsbetrieb
273
5.7
5
Installation
Bevor Sie jetzt mit der Installation auf dem zweiten Server beginnen, kopieren Sie bitte den Backup-Ordner von dem primären Server in ein entsprechendes Verzeichnis auf dem zweiten Computer. Die enthaltenen Dateien werden während der Installation auf dem zweiten Server benötigt. Nach dem Start der Installationsroutine auf dem zweiten Server und der Auswahl, dass die Installation jetzt auf dem zweiten Knoten stattfindet, geben Sie das zuvor kopierte Backup-Verzeichnis an. Auch nun werden wieder die Voraussetzungen getestet. Nach positivem Abschluss der Tests erfolgt wieder die eigentliche Installation der Software. Ist der Packet-Filter ebenfalls installiert, wird die Eingabe erwartet, welches Netzwerk das Heartbeat-Netz ist. Wählen Sie bei der Abfrage des produktiven Netzes direkt das passende Netzwerk, erscheint sofort eine Fehlermeldung (Abbildung 5.125).
Abbildung 5.125
Die Netzwerkkarte des produktiven Netzwerks hat keinen Link.
Bevor Sie das produktive Netz wählen, ist das Netzwerk zu aktivieren. Durch den installierten Packet-Filter treten keine Konflikte im Netzwerk auf. Ehe mit dem Abschluss der Installation der Dienst gestartet wird, sollten Sie abschließend noch die Zeitsynchronisation der beiden Systeme prüfen. Die geschieht mit dem Befehl net time \\ /set (Abbildung 5.126).
Abbildung 5.126
Synchronisation der Uhrzeit
Starten Sie über das Icon im System-Tray den Dienst auf dem ersten System (Abbildung 5.127), bevor Sie die Installation mit dem Start des Dienstes auf dem zweiten Knoten beenden.
274
Hochverfügbarkeit vCenter-Server
Abbildung 5.127
Start des Server Heartbeats
Sollten Sie bei der Implementierung des vCenter-Servers die Datenbank und die vCenter-Applikation getrennt haben, dann ist der gesamte Installationsvorgang für den Datenbank-Server zu wiederholen. Natürlich nur, wenn Sie keine anderen Ausfallsicherungsmechanismen für das Datenbanksystem einsetzen, wie z. B. Clustering. Damit die neue Softwarekomponente administriert werden kann, sind einige kleine Konfigurationen vorzunehmen. Über den Punkt Manage Server (Abbildung 5.127) rufen Sie den entsprechenden Dialog auf (Abbildung 5.128).
Abbildung 5.128
Konfiguration Management-Interface
Über den Button Servers erscheint ein Dialog für das Hinzufügen von zu verwaltenden Computern. Die Auswahl Add Pair öffnet den eigentlichen Dialog (Abbildung 5.129).
Abbildung 5.129
Angabe des zu verwaltenden Systems
275
5.7
5
Installation
Jetzt lässt sich das Server-Paar über die Managementkonsole administrieren. Es werden nur bestimmte Kombinationen von physischen oder virtuellen vCenter-Servern unterstützt. Tabelle 5.6 listet Ihnen die unterstützten Kombinationen auf. Master-Server
Backup-Server
Unterstützung
physisch
physisch
ja
physisch
virtuell
ja
virtuell
virtuell
ja
virtuell
physisch
nein
Tabelle 5.6
Kombinationen Server-Typen vCenter Server Heartbeat
Kommt als Grundinstallation eine Kombination physisch/virtuell zum Einsatz und findet eine Umschaltung statt, dann ist in diesem Fall die Kombination virtuell/physisch temporär unterstützt, aber nur auf dem Weg zurück zur einstigen Grundkonfiguration.
5.7.4
Zusätzliche Software
Möchten Sie, aus welchen Gründen auch immer, das Produkt VMware Heartbeat nicht einsetzen, so gibt es auch andere Produkte, die ähnliche Funktionen abbilden. Wichtig ist dabei, ob die gesamte Applikation einschließlich Datenbank auf einem Server läuft oder ob Datenbank und vCenter-Komponenten voneinander getrennt sind. Mögliche Programme sind in diesem Fall DoubleTake, Neverfail, Marathon und Ähnliche.
5.8
Lizenzierung
In diesem Abschnitt werden wir auf den aktuellen und den neuen im vCenter integrierten Lizenz-Server eingehen. In einer reinen vSphere-Umgebung wird nur der integrierte Lizenz-Server benötigt. Betreiben Sie Mischumgebungen, dann ist zusätzlich der Lizenz-Server der Vorgängerversion zu installieren.
5.8.1
Lizenzierung vSphere
Der vSphere-Lizenz-Server findet sich unter Administration 폷 vCenter Server konfiguration 폷 Licensing. Hier pflegen Sie die Lizenzen ein (Abbildung 5.130).
276
Lizenzierung
Abbildung 5.130
Lizenzen einpflegen
Gehören Sie zu den Administratoren einer Mischumgebung, dann müssen Sie zusätzlich den Lizenz-Server für die VI 3.x-Umgebung angeben. Soll eine sanfte Migration von einer bestehenden Landschaft in eine vSphere-Farm erfolgen, dann ist nach dem Umzug eines VI 3.x-Hosts die Lizenz im alten Lizenz-Server abzumelden. Anschließend pflegen Sie den vSphere-Lizenz-Key im vCenter ein. Die neue VMware-vSphere-Version läuft ohne Angabe einer Lizenz 60 Tage als Evaluation – mit vollem Funktionsumfang. Besitzen Sie bereits Lizenzen oder haben Sie Lizenzen bestellt, sind diese im VMware-Lizenzportal jederzeit abrufbar. Für weitere Informationen schlagen Sie bitte in Kapitel 18, »Die Lizenzierung von vSphere«, nach.
5.8.2
Lizenzen prüfen – VI 3.x
Wenn die Lizenzen in das Lizenz-Server-Verzeichnis kopiert sind, müssen Sie in jedem Fall den Lizenz-Server daraufhin überprüfen, ob er die Lizenzen auslesen und dementsprechend an vCenter- und VMware-vSphere-Server weitergeben
277
5.8
5
Installation
kann. Dazu wurde auf dem System, auf dem der Lizenz-Server läuft, ein LizenzServer-Tool mitinstalliert, das Sie im Start-Menü unter VMware 폷 VMware License Server 폷 VMware License Server Tools finden.
Abbildung 5.131
Diagnose des Lizenz-Servers
Dieses Tool besitzt zwei interessante Reiter zum Debuggen des Lizenz-Servers: Server Diag und Start/Stop/Reread. Der erste Weg sollte immer zum Server Diag mit anschließendem Perform Diagnostics führen. Wird in dem unteren Feld keine Lizenz angezeigt, liegt definitiv ein Fehler vor. In diesem und in dem Fall fehlender Lizenzen sollten Sie zuerst auf einen richtigen Pfad (Abbildung 5.132) prüfen und anschließend die Lizenzdatei neu einlesen.
Abbildung 5.132
278
Verwaltung des Lizenz-Server-Dienst
VMware Data Recovery
Hilft dies nichts, starten Sie erst den Lizenz-Server-Dienst neu und führen danach wieder einen Diagnoselauf durch. Der letzte Weg wäre ein Neustart des gesamten Systems. Dies ist zwar äußerst selten notwendig, es kann aber passieren, wenn der Lizenz-Server komplett abstürzt. Erkennt der Lizenz-Server alle Lizenzen korrekt, ist in vielen Fällen auch ein Neustart des vCenter-Diensts notwendig, um alle Lizenzen korrekt im Zugriff zu halten.
5.9
VMware Data Recovery
VMware Data Recovery ist die erste Datensicherungslösung von VMware. Mit dem VCB wurde zwar den Drittsoftwareherstellern ein Mittel an die Hand gegeben, Daten über das SAN zu sichern, aber das Framework ist nicht in jedem Fall einfach zu handhaben, und es kann doch recht komplexe Strukturen annehmen. Bevor wir nun auf die Installation der VMware Data Recovery eingehen, möchten wir darstellen, wie das Ganze funktioniert. Das gesamte Konglomerat besteht aus mehreren Teilen, die ineinandergreifen. Zuallererst benötigen Sie eine virtuelle Maschine. Diese liegt im OVF-Format vor und verwaltet den Datensicherungsstrom. Es wird ein Plug-in genutzt, das sich in den vSphere-Client einbindet. An dieser Stelle administrieren Sie Backups und Restores. Sehr wichtig ist, dass Sie die Daten auch sichern, wenn Sie die VM mit VMotion oder über DRS im Cluster verschieben! Als Ablageort für Daten sind alle Medien zugelassen, die als virtuelle Disk genutzt werden können, als da wären SAN, NAS und CIFS. Es lassen sich aber nur zwei Laufwerke parallel nutzen. Ist es notwendig, mehr als zwei Ziele zu verwenden, müssen Sie die Backups zeitlich so entzerren, dass nie mehr als zwei Ziele genutzt werden. Die Daten werden dedupliziert, was das Datenaufkommen um ein Vielfaches reduziert. Es gibt eine Einschränkung: Sie können nicht mehr als 100 virtuelle Maschinen gleichzeitig mit einer Backup-Appliance sichern. Bevor die Datensicherung über die Sicherungsapplikation angestoßen wird, erzeugt das Data Recovery einen Snapshot. Unter Zuhilfenahme des MicrosoftDienstes Volume Shadow Copy Service wird dafür gesorgt, dass dieser Snapshot auch konsistent ist. Wäre das nicht der Fall, könnte man mit den Daten in der Sicherung nichts anfangen. Bevor die Installation beginnen kann, müssen Voraussetzungen erfüllt sein. Es muss ein vCenter-Server in der aktuellen Version vorhanden sein. Die Appliance
279
5.9
5
Installation
ist aber auch auf Host-Systemen mit der Version ESX 3.5 lauffähig, wir sehen das später an der Hardware-Version 4 nach der Installation. Im Vorfeld ist es sehr schwierig, festzustellen, wie viel Plattenplatz für die Sicherung benötigt wird. Die Größe wird im Wesentlichen davon beeinflusst, wie viele unterschiedliche Systeme gesichert werden sollen, wie oft sie gesichert werden sollen und wie lange die Daten vorgehalten werden müssen. Zur Optimierung des Plattenplatzbedarfs fassen Sie identische oder ähnliche Systeme auf ein und derselben Zielplatte zusammen. So optimieren Sie die Deduplizierungsrate. Die Installation erfolgt in zwei recht einfachen Schritten: Zu Beginn laden Sie das ISO-File für das VMware Data Recovery bei VMware herunter. Binden Sie das ISO-Image ein, erscheint über die Autostart-Funktion das Startfenster für den ersten Teil der Installation (Abbildung 5.133).
Abbildung 5.133
Installation Client VMware Data Recovery
Über den ersten Menüpunkt richten Sie den Client der VMware Data Recovery ein. Diese Komponente gliedert sich in den vSphere-Client und ermöglicht das Management der Backup-Appliance. Bei der Installation des Clients gibt es keine Möglichkeit, die Konfiguration anzupassen. Es ist nur der EULA zuzustimmen, und der Rest läuft automatisch ab. Im zweiten Schritt wird die Appliance zur Verfügung gestellt. Das gemountete ISO-File enthält den Pfad DataRecovery\VmwareDataRecovery-ovf. Darin befinden sich zwei Dateien: zum einen die Beschreibungsdatei mit der Endung .ovf und die Festplattendatei mit der Endung .vmdk. Kopieren Sie diese beiden Files in ein Verzeichnis, auf das der vCenter-Server Zugriff hat. Über das vCenter und den Menüpunkt File 폷 Deploy OVF Template importieren Sie jetzt die Appliance. Der Import from file ist an sich selbsterklärend. Mit dem Befehl Finish erzeugen Sie die Data-Recovery-Maschine in der virtuellen Infrastruktur. Jetzt können
280
VMware Data Recovery
Sie die VM starten. Standardmäßig hat die VM zwei CPUs und 2 GB Arbeitsspeicher; je nachdem, wie viele VMs gesichert werden sollen, ist es erforderlich, den Hauptspeicher des Systems aufzurüsten. An der virtuellen Hardwareversion (es handelt sich um die Version 4) erkennen Sie, dass der virtuelle Data-Recovery-Server auch unter der Version VI 3.5 eingesetzt werden kann. Nachdem Sie die VM gestartet heben, können Sie sie weitergehend konfigurieren. Diese Arbeiten werden, wie bei den anderen in diesem Kapitel beschriebenen Funktionen auch, in Kapitel 12, »Konfiguration von vCenter-Add-Ons«, näher dargestellt.
281
5.9
In diesem Kapitel erfahren Sie, wie Sie Ihre VMware Virtual Infrastructure verwalten. Wir werden auf alle Möglichkeiten der Verwaltung eingehen, die Sie in der VMware Virtual Infrastructure nutzen können.
6
Verwaltungsmöglichkeiten Autor dieses Kapitels ist Betram Wöhrmann, Ligarion, [email protected]
Nachdem Sie dieses Kapitel gelesen haben, werden Sie alle Möglichkeiten kennen, die Ihnen die Firma VMware zur Verfügung stellt, um Ihre virtuelle Infrastruktur zu administrieren. Dabei werden wir näher beleuchten, wann welches Tool verwendet werden sollte. Durch den richtigen Einsatz des richtigen Tools ist es möglich, die Landschaft effektiv zu administrieren.
6.1
Weboberfläche
Eine der ersten Möglichkeiten, sich mit dem vSphere-Server oder dem vCenterServer zu verbinden, ist der Weg über die Weboberfläche. Der Zugriff auf die Weboberfläche ermöglicht einige grundlegende Möglichkeiten der Administration. Die Weboberfläche ist allerdings der Teil der Administration, der am wenigsten verwendet wird, da einfach viele Möglichkeiten und Funktionen fehlen. Die Weboberfläche ist direkt nach der Installation des vSphere-Hosts oder vCenter-Servers erreichbar. Wenn Sie in Ihrem Browser http://SERVER-IP eingeben, werden Sie auf die Startseite weitergeleitet. Auf dieser Seite finden Sie auf der linken Seite einen Link An Webaccess anmelden; wählen Sie diesen aus, dann gelangen Sie direkt auf den Webservice des vSphere-Servers. Allerdings müssen Sie diese Möglichkeit des Zugriffs zuvor über den vSphereClient in der Firewall freischalten (Abbildung 6.1). Im Gegensatz zu den Vorgängerversionen ist der Webzugriff nicht direkt nach der Installation aktiviert. Für den Zugriff auf den vCenter-Server muss der Webdienst gestartet sein.
283
6
Verwaltungsmöglichkeiten
Abbildung 6.1
Aktivierung Host Webaccess
Ist die Funktion freigeschaltet, dann erhalten Sie eine rudimentäre Oberfläche, die es dem angemeldeten Benutzer erlaubt, die auf dem Host liegenden virtuellen Maschinen zu administrieren. Mehr bietet die Oberfläche nicht (Abbildung 6.2).
Abbildung 6.2
Weboberfläche für Host-Administration
Die Weboberfläche beschränkt sich hauptsächlich auf die Administration von virtuellen Maschinen.
284
Weboberfläche
Abbildung 6.3 zeigt die Konfiguration einer virtuellen Maschine in der Weboberfläche eines ESX-Hosts. Wie zu erkennen ist, gibt es hier sehr viele Funktionen und Möglichkeiten, die virtuelle Maschine zu konfigurieren. Diese Oberfläche steht im Umfang und in den Funktionen für virtuelle Maschinen der Oberfläche im vSphere-Client in nichts nach.
Abbildung 6.3
Konfiguration einer virtuellen Maschine
Wie anfangs erwähnt, ist es ähnlich wie beim ESX-Host möglich, sich auf den vCenter-Server via Webbrowser zu verbinden. Die Bedienung und die Masken sind absolut identisch mit denen eines ESX-Hosts. Der Vorteil der Verwendung des vCenters ist, dass dort alle virtuellen Maschinen angezeigt werden, die registriert sind. Solange diese virtuellen Maschinen im VMware vCenter registriert sind, ist es möglich, sie zu konfigurieren, zu starten oder zum Beispiel zu stoppen. Dabei ist es egal, auf welchem ESX-Host die virtuelle Maschine konfiguriert bzw. aktiv ist. Wer jetzt erwartet hat, dass das Ganze beim Webzugriff auf den vCenter-Server wesentlich anders aussieht, der sieht sich getäuscht. Der einzige Unterschied zum direkten Zugriff auf einen Host ist, dass nicht nur die VMs eines Hosts, sondern alle VMs angezeigt werden. Es gibt aber nicht mehr Möglichkeiten der Konfiguration. Die Weboberfläche des vSphere ESXi unterscheidet sich von denen der anderen vSphere-Produkte. vSphere ESXi bietet in der Weboberfläche keine Administrationsmöglichkeit. Es besteht nur die Option, sich den Datastore anzuschauen. Mehr Punkte gibt es nicht.
285
6.1
6
Verwaltungsmöglichkeiten
Auf der Startseite des Webzugriffs ist es möglich, das Remote-Administrationstool für ESXi herunterzuladen. Entweder als Virtual Appliance, als WindowsInstallationsdatei oder als Linux-Paket steht die Remote CLI zur Verfügung.
6.2
Service Console
Eine weitere Möglichkeit der Verwaltung ist die Service Console. Diese Service Console finden Sie allerdings nur unter der vSphere-Version ESX und nicht unter ESXi oder vCenter Server. Als Service Console wird die Konsole eines vSphere-Hosts bezeichnet. Es handelt sich um eine 64-Bit-Red-Hat–Linux-Version 5, die speziell von VMware abgesichert und zugeschnitten wurde, um nur zur Verwaltung des VirtualisierungsHost zu dienen. Oft wird fälschlicherweise behauptet, dieses Red-Hat sei der eigentliche Hypervisor. Der Hypervisor ist der VMkernel, während die Service Console eine reine Administration darstellt. Die Installation von Drittherstellersoftware ist nur in Ausnahmefällen in der Service Console unterstützt (Verwaltungs- oder Backupprodukte). Dabei ist zu beachten, dass die Installation von zusätzlicher Software nicht komplett für ESXi-Hosts zur Verfügung steht; darauf sind wir bereits im Abschnitt 2.2.4 genauer eingegangen. Wenn Sie sich die Console eines vSphere-Hosts nach dem Booten anschauen, sehen Sie eine Übersicht über die Version des Hosts und dessen IP-Adresse (Abbildung 6.4). Die dort angezeigte IP-Adresse ist die des Management-Interfaces. Über diese Adresse kommuniziert der Host mit der Außenwelt. Einen Login erhalten Sie als Administrator, indem Sie (Alt) + (F1) beim ESX-Host drücken. Im folgenden Fenster können Sie sich anschließend anmelden.
Abbildung 6.4
Anmeldebildschirm des ESX-Hosts
Nachdem Sie sich am System angemeldet haben, stehen Ihnen alle bekannten Linux-Befehle zur Verfügung sowie weitere VMware-spezifische Befehle.
286
Service Console
Beim ESXi-Host stellt sich die Oberfläche anders dar. Sie gelangen über die Taste (F2) zum Management (Abbildung 6.5).
Abbildung 6.5
Managementoberfläche bei VMware ESXi
Hier lassen sich das Passwort, die Netzwerkeinstellungen und die Tastatur konfigurieren. Des Weiteren können Sie hier die Log-Dateien einsehen. Viel mehr als diese rudimentären Funktionen stehen in der Console des ESXi Servers nicht zur Verfügung. Unter ESXi können Sie außerdem den Lockdown Mode einstellen. Wird dieser aktiviert, ist es nicht mehr möglich, sich remote auf der Maschine mit typischen Administrator-Accounts anzumelden, z. B. root oder admin. Eine Konfiguration müssen Sie dann mit dem vCenter oder lokal an der Konsole durchführen.
6.2.1
Aktivierung des SSH-root-Zugriffs
Damit es möglich wird, sich über SSH am vSphere-Host anzumelden, müssen Sie dafür einen Benutzer einrichten oder den root-Account für den SSH-Zugriff freischalten. Nötig ist dies aber nur, wenn nicht bereits ein Benutzer bei der Installation des vSphere-Hosts angelegt wurde. Falls kein Benutzer eingerichtet wurde oder unbedingt mit dem root-User gearbeitet werden soll, müssen Sie die folgenden Schritte durchführen: Zur Freischaltung des root-Log-ins müssen Sie die Datei /etc/ssh/sshd_config anpassen. Öffnen Sie diese Datei mit vi oder einem anderen Editor, mit dem Sie sicher arbeiten können (z. B. pico, joe, nano), und editieren Sie die folgende Zeile:
287
6.2
6
Verwaltungsmöglichkeiten
Originalzeile: PermitRootLogin no
Ändern Sie diese Zeile in: PermitRootLogin yes
oder: #PermitRootLogin no
Nachdem Sie die Datei mit :wq! (bei Nutzung des vi-Editors) gespeichert haben, müssen Sie den SSH-Dienst mit service sshd restart neu starten. Jetzt ist es möglich, sich über SSH mit dem root-Zugang zu verbinden.
6.2.2
Verwendung der Service Console ohne root-Zugriff
Aus Sicherheitsgründen ist es sinnvoll, die Service Console ohne root-Zugriff zu verwenden. In vielen Firmen gibt es IT-Sicherheitsrichtlinien, die eine Verwendung von root strengstens untersagen. In diesem Fall sollten Sie sich als Standardbenutzer anmelden und anschließend mit su – in die root-Shell wechseln. Entweder ist ein zusätzlicher Benutzer direkt bei der Installation angelegt worden, oder der Benutzer ist direkt auf der Konsole anzulegen. Alternativ richten Sie den User über den vSphere-Client ein (Abbildung 6.6). Hier können Sie den User nicht nur anlegen, sondern ihn auch mit den entsprechenden Rechten versehen.
Abbildung 6.6
288
Anlegen eines Users über den vSphere-Client
vSphere-Client
Im Falle des direkten Zugriffs über die Konsole der Maschine ist es möglich, mit dem Befehl adduser einen Benutzer anzulegen. Nachdem der Benutzer eingerichtet wurde, kann eine Anmeldung per ssh mit dem Host erfolgen. Nach der Anmeldung ist es mit dem Befehl su – und der Angabe des root-Passwortes möglich, sich root-Rechte zu verschaffen.
6.2.3
Absetzen von Befehlen auf der Service Console
Nach einer erfolgreichen Anmeldung an der Service Console können Sie Befehle absetzen, um den vSphere-Host zu administrieren, virtuelle Maschinen zu erstellen, virtuelle Maschinen zu starten und vieles mehr. Haben Sie sich mit der Service Console und ihren Befehlen vertraut gemacht, sehen Sie schnell die Vorteile, die die Kommandozeile bietet. Die Befehle lassen sich in Skripten zusammenfassen, und so können Sie auch komplexe Aufgaben abbilden. Mit ein wenig Erfahrung sind komplexere Arbeiten an der Service Console schneller erledigt als über die GUI. Die Befehle unterteilen sich in zwei verschiedene Gruppen: Zum einen gibt es die normalen Linux-Befehle, die Sie von vielen Linux-Systemen her kennen, wie diff, ls, less, man, mv oder mkdir; zum anderen gibt es eine Reihe weiterer Befehle, die speziell von VMware erstellt wurden. Hierzu gehören beispielsweise esxtop, esxcfg-advcfg oder vmware-cmd. Eine Beschreibung der einzelnen Befehle würde den Rahmen dieses Buches sprengen. Wir möchten hier nur darauf hinweisen, dass es diese Möglichkeit gibt.
6.3
vSphere-Client
Der vSphere-Client bietet eine komfortablere und ergonomische Oberfläche, um vSphere-Server zu administrieren. Diese GUI bietet mehr Komfort als die Weboberfläche oder die Service Console. Der Client kann von jeder vSphere- oder vCenter-Server-Weboberfläche heruntergeladen und unter Microsoft Windows installiert werden. Der Client ist auch kompatibel mit den Vorgängerversionen der aktuellen virtuellen Infrastruktur. Kommt bei Ihnen eine Mischumgebung zum Einsatz – bei der Migration von der Version ESX 3.x nach vSphere ist das temporär auf jeden Fall so –, dann können Sie mit dem neuen Client auf alle Systeme zugreifen. Auf den folgenden Seiten lesen Sie, wie Sie den vSphere-Client installieren und ihn bedienen.
289
6.3
6
Verwaltungsmöglichkeiten
6.3.1
Download und Installation des vSphere-Clients
Um den vSphere-Client herunterzuladen, verbinden Sie sich einfach mit der Weboberfläche eines vSphere-Hosts oder des vCenters. Dort finden Sie einen Link, über den Sie den Client herunterladen können. Nachdem Sie den Client heruntergeladen haben, installieren Sie ihn wie jedes andere Windows Programm auch. Die Installation ist nach ein paar Klicks abgeschlossen, und es wird automatisch ein Icon auf dem Desktop angelegt. Näheres zur Installation des vSphere-Clients finden Sie in Abschnitt 5.4.4.
6.3.2
Verwenden des vSphere-Clients
Nachdem Sie den Client gestartet haben, können Sie sich mit Host-Name, Benutzername und Passwort an einem vSphere- oder vCenter-Server anmelden (Abbildung 6.7). Alternativ zu einem Host-Namen können Sie auch die IP-Adresse des Hosts verwenden.
Abbildung 6.7
Die Anmeldung am vSphere-Client
Je nachdem, ob Sie sich mit einem Host oder mit einem vCenter-Server verbunden haben, werden in der Oberfläche verschiedene Informationen angezeigt. Nach dem Laden des Inventorys und dem Aufbau der Oberfläche sehen Sie einen Bildschirm mit zwei verschiedenen Fenstern. Auf der linken Seite der Oberfläche finden Sie bei der Anmeldung an einen Host den vSphere-Host wieder, mit dem Sie sich verbunden haben (Abbildung 6.8). Auf der rechten Seite der Oberfläche finden sich verschiedene Informationen und Reiter zur Administration des auf der linken Seite aktivierten Objekts.
290
vSphere-Client
Abbildung 6.8
vCenter-Oberfläche
Tabelle 6.1 listet die verschiedenen Reiter auf, die Ihnen angeboten werden, mit einer Erklärung, welche administrativen Möglichkeiten sich dahinter verbergen. Wundern Sie sich nicht, wenn sich der vSphere-Client auf verschiedenen Systemen in unterschiedlichen Sprachen darstellt. Das hängt mit der aktivierten Localen zusammen, auf dem der Client installiert ist; das System sucht sich automatisch die Informationen aus dem Betriebssystem. Reiter
Beschreibung
Summary
Unter dem Reiter Summary finden Sie eine Zusammenfassung über das gerade ausgewählte Objekt. Wählen Sie zum Beispiel einen vSphere-Host aus, sehen Sie allgemeine Informationen zum Host wie zum Beispiel Hersteller, CPUs oder RAM. Außerdem werden Informationen über die Ressourcen des Hosts angezeigt, zum Beispiel die verwendeten Datastores, die angelegten virtuellen Netzwerke und die Auslastung von RAM und CPU.
Virtual Machines
Den Reiter Virtual Machines finden Sie nur bei Objekten wie dem vSphere-Host oder einem Resource-Pool. Dort wird eine Liste aller virtuellen Maschinen angezeigt sowie deren Status bezüglich Ressourcen, Alarme und Power. Möglicherweise werden weitere Daten aufgelistet, abhängig davon, welche Ausgabefelder Sie in der Kopfzeile des Ausgabefensters aktiviert haben.
Tabelle 6.1
Reiter des vSphere-Clients
291
6.3
6
Verwaltungsmöglichkeiten
Reiter
Beschreibung
Resource Allocation
Resource Allocation wird ebenfalls nicht bei virtuellen Maschinen angezeigt. Hier erhalten Sie eine komplette Übersicht über alle Ressourcen hinsichtlich CPU und RAM. Reservierungen, Shares usw. können Sie hier einsehen und verändern.
Performance
Unter Performance wird ein Diagramm dargestellt, das die Auslastung der verschiedenen Objekte illustriert. Die Ausgabewerte lassen sich den Erfordernissen des Administrators anpassen.
Configuration
Unter dem Tab Configuration können alle Einstellungen eines vSphere-Hosts vorgenommen werden. Dort ist es möglich, unter anderem das Netzwerk zu konfigurieren, Datastores zu verwalten oder weitere Konfiguration vorzunehmen. Im weiteren Verlauf dieses Kapitels gehen wir noch einmal näher darauf ein.
Tasks & Events
Unter dem Reiter Tasks & Events werden alle protokollierten Tasks bzw Events aufgeführt.
Alarms
An dieser Stelle werden zum einen die Alarmdefinitionen angezeigt und zum anderen die aufgetretenen Alarme. Hier können Sie auch eine Quittierung der Alarme durchführen.
Console
Unter den Eigenschaften der virtuellen Maschine ist dieser Reiter zu finden. Hinter ihm verbirgt sich der Bildschirm der VM.
Permissions
Unter dem Reiter Permissions können Sie den Benutzern und Gruppen, die unter dem Reiter Users & Groups erstellt wurden, bestimmte Berechtigungen geben. Sie können mit vorgefertigten Benutzerrollen arbeiten, oder Sie legen eigene Rollen an, die die Arbeitsprozesse im Unternehmen widerspiegeln.
Maps
Eine grafische Darstellung der Infrastruktur der VM wird hier angezeigt.
HardwareStatus
Dieser Reiter ist hostspezifisch. Der Status der einzelnen Hardwarekomponenten wird an dieser Stelle dokumentiert und grafisch dargestellt.
PowerScripter
Dieser Reiter erscheint nur, wenn Sie den PowerScripter der Firma icomasoft installiert haben.
Storage Views
Ähnlich wie bei dem Reiter Maps wird eine grafische Ausgabe erzeugt, die darstellt, wie welche Komponenten miteinander verbunden sind. Es ist ebenfalls möglich, die Ausgabe als Report anzeigen zu lassen.
UpdateManager
Sollten Sie Host und/oder VMs mit dem VMware UpdateManager patchen, dann werden hier die Informationen zum PatchStatus des Objekts angezeigt.
Tabelle 6.1
292
Reiter des vSphere-Clients (Forts.)
vSphere-Client
Sie konfigurieren und verwalten einen vSphere-Host unter dem Reiter Configuration vorgenommen. Wie bereits in Tabelle 6.1 erwähnt, können Sie dort alle wichtigen Einstellungen vornehmen (Abbildung 6.9).
Abbildung 6.9
Reiter vSphere Client
Da es hierzu viele Fragen geben kann und eine falsche Konfiguration schnell zu Problemen führt, werden die einzelnen Punkte des Reiters in Tabelle 6.2 näher erläutert. Im Client stellt sich das dar wie in Abbildung 6.10.
Abbildung 6.10
Host-Konfiguration
Option
Beschreibung
Health Status
Unter dem Punkt Health Status finden Sie Informationen zu den einzelnen Hardwarekomponenten des Hosts. Es ist zum Beispiel möglich, die Temperatur zu überwachen. Über die Status-Funktion können entsprechende Alarme ausgelöst werden. Bitte beachten Sie: Der Health Status wird nur bei direkter Verbindung zu einem Host angezeigt, nicht aber bei einer Verbindung über den vCenter-Server.
Tabelle 6.2
Optionen des Reiters Configuration
293
6.3
6
Verwaltungsmöglichkeiten
Option
Beschreibung
Processors
Die Option Processors zeigt alle vorhandenen Informationen zur verwendeten CPU im Server an. Außerdem werden allgemeine Informationen zum System wie zum Beispiel Hersteller, Modell und BIOS dargestellt. Über die Properties ist es möglich, Hyperthreading zu aktivieren oder zu deaktivieren.
Memory
Memory zeigt den physikalisch vorhandenen RAM an und wie viel Speicher der Service Console zugeordnet ist.
Storage
Die Option Storage ist eine der wichtigsten und gefährlichen Optionen. Hier gibt es die Möglichkeit, Datastores zu erstellen, zu löschen, zu formatieren und viele weitere Optionen. Die vorhandenen Datastores werden im oberen Fenster angezeigt. Wählen Sie einen solchen Datastore aus, sehen Sie im unteren Fenster die Details zu diesem Datastore. Bei ausgewähltem Datastore können Sie diesen über den Button Properties umbenennen und erweitern. Über den Button Add Storage erstellen Sie einen weiteren Datastore. Darauf wird in Kapitel 8 näher eingegangen.
Networking
Networking bietet die Möglichkeit, das Netzwerk des vSphere-Hosts zu konfigurieren. Dieser Teil ist sehr entscheidend bei der korrekten Konfiguration des Hosts. Ausführlich wird dieser Teil der Konfiguration in Kapitel 7 erläutert.
Storage Adapter
Storage Adapter zeigt alle vorhandenen Storage-Adapter im System an. Dazu zählen zum Beispiel Fibre-Channel-Host-BusAdapter, lokale SCSI-Adapter oder iSCSI-Adapter. Bei der Auswahl eines solchen Gerätes werden im unteren Fenster die Targets angezeigt, die dieser Adapter sieht. Über den Button Rescan scannt der Adapter einmal nach neuen LUNs. Wird zum Beispiel eine neue LUN präsentiert, müssen Sie erst einen Rescan durchführen, bevor diese sichtbar ist und damit Sie konfigurieren können. Wird eine LUN im unteren Fenster ausgewählt, gibt es die Möglichkeit, die Pfade dieser LUN zu verwalten. Dafür aktivieren Sie mit der rechten Maustaste die LUN und wählen Manage Path aus. Darauf wird ebenfalls detailliert in Kapitel 8 eingegangen.
Network Adapter
Die Option Network Adapter zeigt alle installierten und verwendeten Netzwerkkarten des Hosts an.
Advanced Settings
An dieser Stelle wird die Funktion VMDirectPath parametriert. Diese Funktion erlaubt es, unterstützte Hardwarekomponenten direkt an eine virtuelle Maschine zu binden. Hier werden die Karten aufgelistet.
Tabelle 6.2
294
Optionen des Reiters Configuration (Forts.)
vSphere-Client
Option
Beschreibung
Licensed Features
Der Reiter Licensed Features zeigt die Lizenzierung des Hosts an. Über die Edit-Buttons passen Sie diese bei Bedarf an. Nähere Informationen zum Thema Lizenzen finden Sie in Kapitel 18.
Time Configuration Der Menüpunkt Time Configuration ermöglicht die Konfiguration der Uhrzeit sowie die Angabe von Time-Servern. DNS and Routing zeigt alle Informationen über den HostNamen und die DNS-Domäne an und ermöglicht die Bekanntgabe von DNS-Servern.
DNS and Routing
Power Management Hier geben Sie die Parameter an, die benötigt werden, um einen Host aus- oder einzuschalten. Virtual Machine Startup/Shutdown
Es gibt die Option, die konfigurierten virtuellen Maschinen automatisch beim Starten oder Stoppen des vSphere-Hosts zu booten oder herunterzufahren. Dies können Sie hier über den Properties-Button konfigurieren.
Virtual Machine Swapfile Location
Das Swapfile, in das die virtuelle Maschine schreibt, kann im Ordner der virtuellen Maschine selbst oder in einem zentralen Ordner gespeichert werden. Dies konfigurieren Sie hier.
Security Profile
Hinter diesem Reiter versteckt sich die host-interne Firewall des vSphere-Servers. Eine Portfreischaltung erfolgt an dieser Stelle.
System Resource Allocation
Der Reiter System Resource Allocation bietet die Möglichkeit, die Ressourcen des Host-Systems einzustellen. So können Sie zum Beispiel dem Host einen garantierten Wert an CPU und Memory zuweisen.
Advanced Settings
Die Advanced Settings bieten eine große Zahl von Einstellmöglichkeiten. Bei den wenigsten ist genau bekannt, welche Folgen eine Änderung hat. Änderungen der Einstellungen sollten Sie mit VMware absprechen und intensiv testen. Es kann erforderlich sein, Anpassungen vorzunehmen, wenn der Hardwarehersteller es erfordert.
Tabelle 6.2
Optionen des Reiters Configuration (Forts.)
Tipp: Sprachenmix auf dem Client verhindern Es hängt davon ab, wie man den Client installiert bzw. welche Sprachversion das Betriebssystem hat. Da kann es schon passieren, dass man einen Sprachenmix im vSphere Client vorfindet. Mit einem Startparameter kann ein sprach einheitlicher Client forciert werden. 왘
locale en_US: englisch
왘
locale de:
deutsch
왘
locale ja:
japanisch
왘
locale zh_CN: traditionell chinesisch
295
6.3
6
Verwaltungsmöglichkeiten
6.4
vCenter-Server
Das vCenter ist, im Gegensatz zu den bisher vorgestellten Möglichkeiten der Administration, ein komplett eigenes Produkt. Das vCenter fasst die Administration von Hosts und virtuellen Maschinen in einem Tool zusammen. Des Weiteren stellt das Tool zusätzliche Funktionen zur Verfügung, die die Funktionalität der virtuellen Infrastruktur ausbauen, so dass Sie die Verfügbarkeit weiter erhöhen können. Für die Anmeldung am vCenter-Server wird der schon bekannte vSphere-Client eingesetzt. Statt des Host-Namens nutzen Sie zur Anmeldung den DNS-Namen des vCenters. Ist die Anmeldung an einem vCenter-Server erfolgt, wird ein zweigeteiltes Fenster angezeigt (Abbildung 6.11). Auf der linken Seite finden Sie die Objekte der virtuellen Infrastruktur, wie Datacenter, Cluster, Hosts und VMs. Auf der rechten Seite sind die dem markierten Objekt zugeordneten Anzeige- und Konfigurationsparameter zu sehen.
Abbildung 6.11
Startfenster des vCenter-Servers
Eine Übersicht über die einzelnen administrierbaren Funktionen wird beim Aufruf der Startseite sichtbar (Abbildung 6.12).
296
vCenter-Server
Abbildung 6.12
Homepage des vCenter-Servers
Die verwaltbaren Punkte sind nach Funktion gegliedert und übersichtlich angeordnet. Zu den Punkten Bestandsliste, Verwaltung und Management kann noch der Abschnitt Lösungen und Anwendungen angezeigt werden, wenn z. B. der vCenter Converter, der vCenter Update Manager oder andere Zusatzsoftware installiert ist.
6.4.1
Installation des vCenter-Servers
Das vCenter kann unter Microsoft Windows installiert werden. Auch wenn es eine Unterstützung für Client-Betriebssysteme gibt, ist dies für den produktiven Einsatz nicht zu empfehlen. Für einen produktiven Einsatz ist eines der unterstützten Server-Betriebsysteme unbedingt zu verwenden (siehe Abschnitt 5.4.1), um Support von VMware zu erhalten. Das vCenter legt alle Daten in einer Datenbank ab, die lokal auf dem System des vCenter-Servers oder auf einem im Netzwerk befindlichen Datenbanksystem zur Verfügung gestellt wird. Übrigens müssen Sie nicht zwingend eine Datenbank vorinstallieren, da die Installationsroutine des vCenters eine MS SQL 2005 Express-Datenbank mitinstallieren kann. Diese ist allerdings auf den Einsatz von wenigen vSphere-Hosts
297
6.4
6
Verwaltungsmöglichkeiten
und einigen virtuellen Maschinen beschränkt. Eine genaue Anleitung zur Installation sowie alle weiteren wichtigen Randbedingungen sind in Abschnitt 5.4, »VMware vCenter«, zu finden.
6.4.2
Starten des vCenter-Servers
Nach der Installation des vCenters und einem Neustart des Systems können Sie auf das vCenter zugreifen. Zur Verbindung mit dem vCenter-Server benötigen Sie den vSphere-Client, der bereits in Abschnitt 6.3, »vSphere-Client«, beschrieben wurde. Nachdem Sie diesen Client auf dem Administrations-PC oder einem beliebigen anderen PC, der das vCenter erreichen soll, installiert haben, kann er gestartet werden. Bei einer Installation auf derselben Maschine, auf der der vCenter-Server läuft, kann unter Host: »localhost« eingegeben werden. Als Benutzername ist ein WindowsBenutzer mit den entsprechenden Rechten auszuwählen; es kann sich um einen lokalen oder einen Domänenbenutzer handeln. Im Standard sind allerdings nur Benutzer mit lokalen Administratorrechten in den vCenter-Berechtigungen hinterlegt. Um einem »normalen« Benutzer Zugriff zu gewähren, müssen Sie für diesen zuerst in den vCenter-Berechtigungen ein Zugriffsrecht hinterlegen.
6.4.3
Hinzufügen von ESX-Hosts ins vCenter
Ist die Oberfläche des Managementtools geladen, sehen Sie sofort die Ähnlichkeit zur direkten Verbindung des vSphere-Clients mit einem vSphere-Host. Beim erstmaligen Aufruf des nicht konfigurierten vCenter-Servers sieht der Anwender nur eine leere Oberfläche. Im ersten Schritt sind einige Konfigurationsschritte vorzunehmen, um das vCenter mit Leben zu füllen. Es gibt eine Reihe von Möglichkeiten der Gruppierung von Servern. Es empfiehlt sich, zuerst ein Datacenter anzulegen. Unter dieser Struktur können Sie dann Hosts in Clustern zusammenfassen. Um ein neues Datacenter anzulegen, klicken Sie mit der rechten Maustaste auf Host & Clusters und wählen aus dem Kontextmenü den Punkt New Datacenter. Nach der Anlage vergeben Sie für das Objekt einen passenden Namen, und damit ist die Arbeit abgeschlossen. Jetzt haben Sie zwei Optionen: Entweder hängen Sie die Hosts direkt unter dem Datacenterein, oder Sie fassen sie in sogenannten Clustern zusammen. Darauf wird in Abschnitt 6.4.5, »Weitere Funktionen durch vCenter-Server«, eingegangen. Ein Host fügt sich ebenfalls über das Kontextmenü ein, wenn es auf dem Datacenter geöffnet wird. Es startet ein Dialog, der dazu auffordert, host-spezifische Daten einzugeben (Abbildung 6.13).
298
vCenter-Server
Abbildung 6.13
Einbinden eines Hosts ins vCenter-Management
Nach der Prüfung von Benutzername und Passwort wird eine Zusammenfassung des Hosts angezeigt, in der Sie u. a. den Namen des Hosts, den Server-Hersteller, die installierte vSphere-Version und bereits registrierte virtuelle Maschinen finden. Allerdings sollten Sie sich genau überlegen, ob Sie den Host mittels DNSName oder IP-Adresse hinzufügen. Gerade für spätere HA-Cluster und natürlich für die bessere Übersicht ist es sinnvoller, mit DNS-Namen zu arbeiten. Selbstverständlich können Sie auch im Nachhinein die Zuordnung des Hosts zur Organisationsgruppe ändern. Gehen Sie von einer Erstbenutzung des vCenters aus, müssen Sie erst ein Datacenter anlegen, bevor Sie einen Host ins Management aufnehmen können. Jetzt wird der Host dem vCenter hinzugefügt. Nach ein paar Sekunden im Status Disconnected und dem Abschluss des Tasks Add Standalone Host ist der vSphere-Host über den vCenter-Server verwaltbar.
6.4.4
Verwaltung von vSphere-Hosts
Nachdem die vSphere-Hosts hinzugefügt worden sind, ist es möglich, sie ähnlich wie bei der direkten Verbindung mit dem vSphere-Client auf einen Host zu verwalten. Wählen Sie im linken Fenster einen Host aus, werden im rechten Fenster verschiedene Informationen und Reiter angezeigt. Über diese Reiter ist verwalten
299
6.4
6
Verwaltungsmöglichkeiten
Sie den Host und legen zum Beispiel ein virtuelles Netzwerk an. Die Reiter unterscheiden sich etwas von denen, die Sie sehen, wenn Sie sich direkt mit einem Host verbinden. Zur besseren Übersicht fügen wir noch einmal die gesamte Tabelle ein: Reiter
Beschreibung
Summary
Unter dem Reiter Summary finden Sie eine Zusammenfassung über das gerade ausgewählte Objekt. Wählen Sie zum Beispiel einen vSphere-Host aus, sehen Sie allgemeine Informationen zum Host wie zum Beispiel Hersteller, CPUs oder RAM. Außerdem werden Informationen über die Ressourcen des Hosts angezeigt, zum Beispiel die verwendeten Datastores, die angelegten virtuellen Netzwerke und die Auslastung von RAM und CPU.
Virtual Machines
Den Reiter Virtual Machines finden Sie nur bei Objekten wie dem vSphere-Host oder einem Resource-Pool. Dort wird eine Liste aller virtuellen Maschinen angezeigt sowie deren Status bezüglich Ressourcen, Alarme und Power. Möglicherweise werden weitere Daten aufgelistet, abhängig davon, welche Ausgabefelder Sie in der Kopfzeile des Ausgabefensters aktiviert haben.
Performance
Unter Performance wird ein Diagramm dargestellt, das die Auslastung der verschiedenen Objekte illustriert. Die Ausgabewerte lassen sich den Erfordernissen des Administrators anpassen.
Configuration
Unter dem Tab Configuration können alle Einstellungen eines vSphere-Hosts vorgenommen werden. Dort ist es möglich, unter anderem das Netzwerk zu konfigurieren, Datastores zu verwalten oder weitere Konfiguration vorzunehmen. Im weiteren Verlauf dieses Kapitels gehen wir noch einmal näher darauf ein.
Tasks & Events
Unter dem Reiter Tasks & Events werden alle protokollierten Tasks bzw Events aufgeführt.
Alarms
An dieser Stelle werden zum einen die Alarmdefinitionen angezeigt und zum anderen die aufgetretenen Alarme. Hier können Sie auch eine Quittierung der Alarme durchführen.
Permissions
Unter dem Reiter Permissions können Sie den Benutzern und Gruppen, die unter dem Reiter Users & Groups erstellt wurden, bestimmte Berechtigungen geben. Sie können mit vorgefertigten Benutzerrollen arbeiten, oder Sie legen eigene Rollen an, die die Arbeitsprozesse im Unternehmen widerspiegeln.
Maps
Eine grafische Darstellung der Infrastruktur der VM wird hier angezeigt.
HardwareStatus
Dieser Reiter ist hostspezifisch. Der Status der einzelnen Hardwarekomponenten wird an dieser Stelle dokumentiert und grafisch dargestellt.
Tabelle 6.3
300
Reiter des vSphere-Clients
vCenter-Server
Reiter
Beschreibung
PowerScripter
Dieser Reiter erscheint nur, wenn Sie den PowerScripter der Firma icomasoft installiert haben.
Storage Views
Ähnlich wie bei dem Reiter Maps wird eine grafische Ausgabe erzeugt, die darstellt, wie welche Komponenten miteinander verbunden sind. Es ist ebenfalls möglich, die Ausgabe als Report anzeigen zu lassen.
UpdateManager
Sollten Sie Host und/oder VMs mit dem VMware UpdateManager patchen, dann werden hier die Informationen zum PatchStatus des Objekts angezeigt.
Tabelle 6.3
Reiter des vSphere-Clients (Forts.)
Der Reiter Configuration stellt sich so dar, wie bereits in Tabelle 6.2 gelistet.
6.4.5
Weitere Funktionen durch vCenter-Server
Durch den Einsatz des vCenter-Servers ist es nicht nur möglich, mehrere vSphere-Hosts gleichzeitig zu verwalten. Es kommen viele Funktionen hinzu, die erst durch n + 1 Hosts und vCenter möglich werden. Einen Teil dieser Funktionen und Möglichkeiten werden wir in diesem Kapitel kurz erläutern. HA-Cluster Durch einen Cluster erhalten Sie die Möglichkeit, einige neue Features zu verwenden, die ohne vCenter und ohne den Cluster so nicht möglich wären. So können Sie zum Beispiel VMware HA (High Availability) verwenden. Dies bietet die Möglichkeit, eine virtuelle Maschine hochverfügbar zu machen. Hosts, die in einem Cluster zusammengefasst sind, prüfen untereinander gegenseitig die Verfügbarkeit der restlichen Hosts im Cluster. Beim Ausfall eines physikalischen Hosts werden die virtuellen Maschinen, die auf diesem System betrieben wurden, automatisch auf den verbleibenden Hosts neu gestartet. DRS-Cluster VMware DRS (Distributed Resource Scheduling) bietet eine automatische Lastverteilung der virtuellen Maschinen über alle Hosts in einem Cluster. Erreicht wird diese Funktion durch die Unterstützung von VMotion. VMotion verschiebt virtuelle Maschinen ohne spürbare Unterbrechung von einem Host auf einen anderen. Eine Unterfunktion des DRS ist das Power-Management. Diese Option gibt dem Administrator ein Mittel an die Hand, zu lastarmen Zeiten vSphereHosts auszuschalten oder automatisiert ausschalten zu lassen. Steigt der Ressourcenbedarf wieder an, werden die vSphere-Hosts automatisch wieder gestartet.
301
6.4
6
Verwaltungsmöglichkeiten
Virtual Machine Monitoring kommuniziert ständig mit den VMware Tools der virtuellen Maschine. Sollten diese in einem frei konfigurierbaren Zeitfenster nicht antworten, wird die virtuelle Maschine automatisch neu gestartet. All diese Funktionen sind nur durch die Verwendung des VMware vCenter-Servers möglich. Sie sehen also, dass das VMware vCenter nicht nur eine leichtere und komfortablere Administration mehrerer vSphere-Hosts ermöglicht, sondern dass auch viele weitere Funktionen hinzukommen.
6.4.6
Einbindung ins Active Directory
Auch wenn die Möglichkeit besteht, sich am vCenter-Server mit lokalen Accounts anzumelden, ist das sicherlich nicht immer das Mittel der Wahl. Viele Unternehmen haben bereits ein Active Directory, in dem User gepflegt werden, und da ist es nicht sehr sinnvoll, zusätzlich lokale User für einen vCenter-Server zu pflegen oder dort neue Benutzer einzurichten. Das hat auch VMware erkannt und deshalb die Möglichkeit geschaffen, den vCenter-Server in ein vorhandenes Active Directory einzubinden. Dort haben Sie die Option, Gruppen für den Zugriff auf das vCenter anzulegen und diese dann im vCenter zu berechtigen. Als Ergebnis werden die User nur noch an einer Stelle gepflegt, was den administrativen Aufwand stark reduziert. Für diese AD-Integration sind keine aufwendigen Arbeiten notwendig. Es genügt, den vCenter-Server in die Domäne aufzunehmen, in der die User-Konten liegen. Nach der Berechtigungserteilung an die User bzw. Gruppen im vCenter ist der Zugriff mit Domänen-Accounts möglich (Abbildung 6.14).
Abbildung 6.14
302
Dialog zum Hinzufügen von Benutzern
vCenter-Server
Über Add fügen Sie einen Benutzer hinzu, indem Sie im Folgedialog die Domäne als Basis der Benutzerauswahl angeben. Mit Assign Role weisen Sie dem entsprechenden Benutzer passende Rechte zu. Neue Rollen lassen sich über Home 폷 Administration 폷 Role anlegen (Abbildung 6.15). Empfehlenswert ist es, an der Stelle vorhandene Rollen so zu belassen, wie sie sind, und nicht zu manipulieren. Sollen ähnliche Rollen erstellt werden, dann besteht die Möglichkeit, eine vorhandene Rolle zu kopieren und entsprechend anzupassen. Näheres dazu finden Sie in Kapitel 11, »Konfiguration von ESX und vCenter«.
Abbildung 6.15
6.4.7
Anlegen von neuen Rollen
Troubleshooting vCenter-Server
Sollte der Dienst des vCenters nicht starten, können Sie den Vorgang auch über die Kommandozeile initiieren. In diesem Fall ist besser sichtbar, welche Probleme den Start des Dienstes verhindern. Auf diese Art sehen Sie genau, bei welcher Aktion das Starten des vCenters abgebrochen wurde. Dazu führen Sie einfach den Befehl C:\Program Files\VMware\VirtualCenter Server\vpxd.exe –s aus. Nachdem das vCenter mit dem Parameter -s aufgerufen wurde, erscheint ein DOS-Fenster, das die verschiedenen Arbeitsschritte beim Starten des vCenters anzeigt. Bleibt beim Start die Ausgabe bei einem Fehler hängen, können Sie diesen schnell und einfach analysieren. Des Weiteren lassen sich die vCenter-Log-Dateien für die Fehleranalyse exportieren. Auch die Tiefe des Log-Levels lässt sich genau einstellen (Abbildung 6.16).
303
6.4
6
Verwaltungsmöglichkeiten
Abbildung 6.16
Einstellen des Log-Levels im vSphere-Client
Ändern Sie das Log-Level nur, wenn Sie Probleme haben und die Ursachen erforschen wollen. Sind die entsprechenden Arbeiten abgeschlossen, setzen Sie das Level, im eigenen Interesse, wieder auf den Standard (Information) zurück. Möchten Sie ein Log der gesamten Infrastruktur oder von Teilen der Infrastruktur haben, dann lässt sich das über das Menü bewerkstelligen (Abbildung 6.17).
Abbildung 6.17
Export von Log-Dateien
Erschrecken Sie nicht – das kann durchaus einige Zeit in Anspruch nehmen. Die Granularität des Exports lässt sich parametrieren.
6.5
Remote Command-Line Interface
Das Remote Command-Line Interface (folgend Remote CLI genannt) wird hauptsächlich bei VMware ESXi-Hosts eingesetzt, da diese keine Service Console nut-
304
Remote Command-Line Interface
zen. Um weiterhin Skripte und Anwendungen ausführen und Konfigurationen vorzunehmen zu können, ohne den vSphere-Client nutzen zu müssen, wird das Remote CLI verwendet.
6.5.1
Installation
Alle Installationsdateien des Remote CLI sind auf der Webstartseite des Hosts herunterladbar. Verbinden sie sich einfach mit dem Browser auf die Startseite des ESXi-Hosts, und laden Sie dort die nötigen Tools herunter (Abbildung 6.18). Die Links routen den Administrator auf die Webseite von VMware, wo Sie die gewünschte Software zum Download finden.
Abbildung 6.18
Download des vSphere CLI
Die Namen der vSphere-CLI-Befehle entsprechen denen der Befehle auf der Service Console. Hier sehen wir einen großen Vorteil: So muss der Administrator sich für eine Funktion nicht unterschiedliche Befehle merken und kann so auf einfachem Wege seine Arbeiten durchführen.
305
6.5
6
Verwaltungsmöglichkeiten
Installation unter Linux Für eine Installation unter Linux ist zuerst zu untersuchen, ob das Zielsystem eine 32-Bit- oder eine 64-Bit-Plattform ist. Die entsprechende Version ist dann herunterzuladen. Zuerst kopieren Sie die Datei VMware-vSphere-CLI-4.0.0-#####.i386.tar.gz auf das gewünschte Linux-System in den Ordner /tmp und entpacken Sie mit tar xzvf VMware-vSphere-CLI-4.0.0-#####.i386.tar.gz. Es wird dadurch ein Verzeichnis vmware-vsphere-cli-distrib erstellt, in dem alle entpackten Dateien gespeichert werden. Die Installation wird mit /tmp/vmwarevsphere-cli-distrib/vmware-install.pl ausgeführt, wodurch alle Dateien im Standard nach /usr/bin kopiert werden. Eine Deinstallation ist mit /usr/bin/vmware-uninstall-vSphere-CLI.pl durchzuführen. Nach der erfolgreichen Installation finden sich viele vicfg- und esxcfg- Kommandos auf dem System wieder, die dem Administrator nicht fremd sein sollten. Windows-Installation Das Remote CLI für die Installation unter Windows kommt als normale SetupRoutine daher und läuft nach dem Start komplett selbständig durch. Nach Fertigstellung befindet sich eine ActivePerl-Installation auf dem Endgerät. Im Verzeichnis %Programfiles%\VMware\VMware vSphere CLI\bin befinden sich die PerlSkripte. vSphere Management Assistant (vMA 4.0) Eine weitere Alternative ist der Import der Management-Appliance von VMware, die alle benötigten vSphere-CLI-Komponenten samt Gastbetriebssystem enthält. Die Virtual Appliance importieren Sie idealerweise mit dem vSphere-Client über File 폷 Virtual Appliance 폷 Import.
6.5.2
Ausführen des vSphere CLI
Nach der Installation des vSphere CLI können Sie die mitgelieferten vSphere-Befehle ohne Probleme in der Kommandozeile ausführen. Für die Syntax der Befehle ist eine passende Hilfe in der Kommandozeile selbstverständlich enthalten. Ausführen auf Linux-Systemen Um auf einem Linux-System die Remote-CLI-Befehle auszuführen, müssen Sie als erstes ein Command-Prompt öffnen.
306
Remote Command-Line Interface
In diesem Fenster setzen Sie den gewünschten Befehl ab. Als Beispiel soll hier mit dem folgenden Kommando ein Storage VMotion durchgeführt werden: svmotion --server --username <user> --password <user_password> --help
Ausführen auf Windows-Systemen Das Ausführen unter Windows ist ähnlich wie unter dem Betriebsystem Linux. Öffnen Sie auch hier ein Command-Prompt. Das Wechseln in das Installationsverzeichnis des vSphere CLI ist nicht notwendig, weil der Pfad mit in die entsprechende Environment-Variable aufgenommen wird. Auch hier können Sie anschließend den gewünschten Befehl absetzen. Wie auch unter Linux nehmen wir dafür als Beispiel den Storage-VMotion-Befehl: svmotion --server --username <user> --password <user_password> --help
Ausführen auf der Virtual Appliance Die Installation der vMA 4.0 wurde bereits in Abschnitt 6.5.1, »Installation«, beschrieben. Zwei Optionen stehen Ihnen bei der Nutzung der vMA zur Verfügung: Entweder stellen Sie direkt eine Verbindung zu einem ESX-/ESXi-Host her, oder Sie initiieren die Verbindung zu einem vCenter-Server. Bei einer Verbindung zu einem vCenter-Server ist es nicht mehr notwendig, sich zusätzlich mit den einzelnen Hosts zu konnektieren. Diese Verbindungen sind über das vCenter automatisch vorhanden. Auf der Appliance werden unterschiedliche Schnittstellen zur Verfügung gestellt. Tabelle 6.4 listet die Schnittstellen mit ihren Funktionen auf. Schnittstelle
Typ
vifpinit vifp
Kommando
Funktion
vifpinit
Administrative Interface
addserver
Hinzufügen eines Hosts oder vCenter-Servers
listservers
Listet alle Target-Systeme auf.
removeserver
Entfernen eines Hosts oder vCenter-Servers.
rotatepassword
Lebensdauer des Passworts für des gemanagte System (nicht für vCenter-Server)
Tabelle 6.4
Schnittstellen der vMA 4.0
307
6.5
6
Verwaltungsmöglichkeiten
Schnittstelle
Typ
Kommando
Funktion
vilogger
Logging Interface
enable
Aktivierung des Loggings Deaktivierung des Loggings Auflistung vorhandener Logs Aktualisierung der definierten Log-Einstellung
disable list updatepolicy
Library
vifplib
Tabelle 6.4
enumerate_ targets
Auflistung der mit vMA gemanagten Systeme
login_by_ fastpass
Verbindung zum Ziel-Server herstellen
query_target
Anzeigen der Verbindungsinformationen zu den ZielServern
Schnittstellen der vMA 4.0 (Forts.)
Findet die Verbindung der Zielsysteme mit vi-fastpass statt, werden die Passwörter nicht verschlüsselt! vi-fastpass managt die Accounts für die Verbindung zwischen vMA und den Zielsystemen. So ist es nicht erforderlich, jedes Mal beim Absetzen eines Befehls die Accounting-Daten erneut einzugeben. Ist alles eingerichtet, stehen dem Administrator die Befehle der vSphere CLI und die vSphere-SDK-Perl-Skripte zur Verfügung.
6.6
VMware vSphere PowerCLI (ehemals Virtual Infrastructure Toolkit)
Das VMware vSphere PowerCLI (im folgenden PowerCLI genannt) setzt auf die Microsoft Windows PowerShell auf und ermöglicht eine sehr schnelle, einfache und unkomplizierte Administration der VMware Virtual Infrastructure. Die Basis bildet an dieser Stelle die PowerShell von Microsoft. Microsoft hat mit diesem Kommandozeilentool, das Schnittstellen in viele bekannte Systeme, wie z. B. dem .net-Framework hat, eine übergreifende Shell programmiert, die sich an bereits bekannten Systemen orientiert. Das PowerCLI gliedert sich in diese Shell ein und stellt dem Administrator eine große Anzahl von Befehlen zur Administration von vSphere-Umgebungen zur Verfügung. So reichen zum Teil nur wenige Zeichen Code zur Abarbeitung von Aufgaben in der virtuellen Infrastruktur. Die erstellten Skripte können Sie an einzelnen oder mehreren Objekten gleichzeitig ausführen. Damit Sie ein Gefühl für die geringe Komplexität der Skripte
308
VMware vSphere PowerCLI (ehemals Virtual Infrastructure Toolkit)
bekommen, sei hier ein Beispielskript aufgeführt, das einen Rescan aller HostBus-Adapter der angewählten Hosts durchführt: $_ | Get-VMHostStorage –RescanAllHBA $_ | Get-VMHostStorage -Refresh
Mit etwas Einarbeitung ist es schnell möglich, komplexe Skripte zu erstellen, mit denen der Administrator die Aufgaben erfüllen kann, die ihm im Tagesgeschäft begegnen. Die Möglichkeiten, die sich dem Administrator hier eröffnen, werden jedem sofort bewusst, wenn er sich seine täglichen administrativen Aufgaben anschaut. Nun ist es nicht jedermanns Sache, auf der Kommandozeile herum zu zaubern. Das hat auch die Firma icomasoft gesehen. Mit dem viPowerScripter Pro integriert sie die Powershell in den vCenter Server. Die Integration erfolgt über die Plug-in Schnittstelle des vCenters. Die Vorteile liegen auf der Hand. Mit der Integration in das vCenter bekommt der Administrator die Option, Powershell Skripte an einem oder mehreren Objekten in der virtuellen Infrastruktur auszuführen. Bleiben wir einmal bei dem oben gelisteten Beispielskript zum Rescan der Host-Bus-Adapter. Einmal auf der Wurzel des vCenters ausgeführt, wird auf allen Hostsystemen ein Rescan angestoßen. Eine Reihe von Skripten findet sich nach der Installation im Installationsverzeichnis und erleichtert sofort die Arbeit. Selbsterstellte Skripte werden einfach in den passenden Menüpfad gestellt und schon erweitert sich das Kontextmenü um ein weiteres ausführbares Skript. Dabei findet eine Unterscheidung von hostbasierten bzw. VM-basierten statt. Für zyklische Aufgaben ist die Integration in den Scheduler des vCenters gedacht. Benötigen Sie wöchentlich eine Liste aller virtuellen Maschinen mit ihren Hardwaredaten? Erstellen Sie ein passendes Skript und legen Sie die Laufzeiten im Scheduler fest: Schon erhalten Sie einmal wöchentlich per Mail eine entsprechende Liste. Eine der Standardaufgaben ist das Anlegen von Portgruppen. Jeder weiß, was bei einem Schreibfehler passiert: Ein VMotion kann nicht funktionieren, weil dem Host das VLAN unbekannt ist. Auch hier wird die Mächtigkeit des Tools deutlich! Sie brauchen nur ein Skript zur Erstellung des VLANs auf dem Cluster auszuführen und schon ist auf allen Hosts das VLAN in identischer Schreibweise angelegt.
Abbildung 6.19
Erstellen eines VLANs
309
6.6
6
Verwaltungsmöglichkeiten
Welche Wichtigkeit die Powershell Schnittstelle für VMware hat und wie VMware diese Schnittstelle den Administratoren noch näherbringen möchte, zeigt die Software Onyx. Es handelt sich derzeit noch um eine Alpha Version. Die Software zeichnet Aktionen auf, die Sie im vCenter durchführen und erzeugt im Anschluss daran ein lauffähiges Powershell Skript. Man darf gespannt sein, wie sich das Thema noch weiterentwickelt.
310
Was ist ein vSwitch? Eine ganz grundlegende Frage für Einsteiger in die Virtualisierung. Wie sollte ich mein virtuelles Netzwerk aufbauen? Welche neuen Möglichkeiten gibt es mit vSphere? Kann ich im laufenden Betrieb mein Netz optimieren? Diese sicher typischen Fragen beantworten wir in diesem Kapitel.
7
Netzwerk Autor dieses Kapitels ist Sebastian Wischer, team(ix) GmbH, [email protected]
vSphere 4.0 brachte einige Neuerungen und Optimierungen für virtuelle Netze. Ein besonderer Schritt sind die distributed vSwitches. Sie vereinfachen die Konfiguration virtueller Netze. Vor allem kann aber auch die Betreuung virtueller Netze an die Netzwerkadministration übergeben werden. Damit die Administratoren physischer Netze sich nicht umgewöhnen müssen, können die distributed vSwitches z. B. als Cisco Nexus dargestellt werden. Auf der Seite der virtuellen Maschinen wurde mit dem vmxnet3 ein weiterer Netzwerk-Adapter bereitgestellt. Die Anzahl der virtuellen Netzwerkkarten wurde von vier auf maximal zehn Adapter pro virtuelle Maschine erhöht.
7.1
Netzwerk-Physik
Bei Netzwerken in VMware-Umgebungen wird zwischen zwei Schichten unterschieden: der physischen und der virtuellen Schicht. Die physische Schicht umfasst die externen Switches, Server und Clients und reicht bis zum vSwitch. Der vSwitch ist die erste Komponente in der virtuellen Schicht, diese beinhaltet weiterhin die Port-Groups und die virtuellen Netzwerkkarten der VMs. In diesem Teil geht es zunächst um die physische Netzwerkschicht und ihren Einfluss auf die virtuelle Netzwerkschicht. Für VMware-Umgebungen gibt es auch hier viele entscheidende Themen: Wie kann ich meinen ESX-Server hochverfügbar anbinden? Wie bekomme ich eine möglichst optimale Performance für meine virtuellen Maschinen? Gerade in diesem Bereich liegen häufige Ursachen für Performance-Probleme in virtuellen Infrastrukturen. Ist in dieser Ebene etwas nicht
311
Netzwerk
VMs, Service Console, VMkernel
VM-Netzwerk
Port-Groups
Service Console
VMkernel
virtuelles Netzwerk
optimal konfiguriert, dauert die Suche nach den Ursachen in der virtuellen Schicht lange.
vSwitches ESXNetzwerkports Switches
Server-Netz
Management-Netz
Storage-Netz
physisches Netzwerk
7
Server, Clients, Storage, ...
Abbildung 7.1
Aufbau physisches und virtuelles Netzwerk
Bleibt man bei der Netzwerkphysik, so muss man sich bei der Planung mit den Möglichkeiten der virtuellen Umgebung und den entsprechenden Anforderungen an diese beschäftigen. Dazu gehört neben der Anzahl der physischen Switches und der Größenordnung der Switches auch die Anzahl der Netzwerkports der ESX-. Denn die beste Planung nutzt nichts, wenn die Anzahl der Netzwerkports an den Host-Systemen nicht ausreicht, weil man beispielsweise bei Blades limitiert ist. Als Grundlagen müssen Sie den Unterschied zwischen vSwitch, Uplink und Portgruppe kennen. Der vSwitch ist der eigentliche Switch, der aus einer gewissen Anzahl Ports besteht und mehrere Uplinks und Portgruppen besitzen kann. Uplinks sind die physischen Netzwerkkarten des ESX-Hosts, die dem vSwitch zugeordnet werden, um einen Weg ins physische Netzwerk zu finden (kein Uplink = kein physisches Netzwerk). Die Portgruppen sind die logischen Einheiten, die die Verbindung zwischen vSwitch und virtuellen Netzwerkkarten und Ports (Service Console, VMkernel) schaffen.
312
Netzwerk-Physik
Die Anzahl der benötigten physischen Netzwerkports in einem ESX-Server steigt, je mehr der folgenden Fragen Sie für sich mit »ja« beantworten: 왘
Wird ein getrenntes Verwaltungsnetzwerk benötigt?
왘
Wird ein getrenntes VMotion- und Fault-Tolerance-Netzwerk benötigt?
왘
Wird mit IP-Storage gearbeitet (iSCSI, NFS)?
왘
Herrschen große Sicherheitsanforderungen, die eine Netzwerktrennung beim Betrieb der virtuellen Maschinen bedingen?
왘
Können Sie VLANs nutzen?
왘
Wie hoch ist die Anforderung nach Hochverfügbarkeit der Netzwerke?
Außerdem müssen Sie sich von dem Gedanken frei machen, der virtuelle Switch wäre 1:1 mit dem physischen Switch vergleichbar. Generell gilt, dass bis auf die günstigsten Switches im Markt die Verwaltungsmöglichkeiten der physischen Switches wesentlich höher sind als die der virtuellen. Im Gegensatz dazu sind die virtuellen Switches außerordentlich flexibel, so dass es auch kein Problem ist, einen vSwitch um knapp 500 Ports zu erweitern – ein Neustart des Hosts vorausgesetzt. Die Zuordnung der Ports ist allerdings bei beiden Switches wieder gleich, das heißt, jeweils ein Port wird einer Netzwerkkarte zugeordnet. Zu den Netzwerkkarten in der virtuellen Umgebung zählen Service-Console-Ports, VMkernelPorts und virtuelle Netzwerkkarten; eine VM mit zwei virtuellen Netzwerkkarten verbraucht also zwei Ports auf dem vSwitch. Außerdem nutzen auch die Verbindungen von vSwitches ins physische Netzwerk, die Uplinks (physische Netzwerkkarten – vmnic#), jeweils einen Port am vSwitch. Eine physische Netzwerkkarte kann nur einen einzigen Uplink stellen, das heißt, Sie können sie nicht als Uplink für mehrere vSwitches konfigurierten.
Abbildung 7.2
Anpassung der Portanzahl eines virtuellen Switches
313
7.1
7
Netzwerk
Der Standard-vSwitch verfügt über 64 Ports; da aber immer 8 Ports für die Verwaltung vom VMkernel für eigene Aktivitäten abgezogen werden, liegen die nutzbaren Ports bei 56. Anzahl Ports
Nutzbare Ports
16
8
32
24
64
56
128
120
256
248
512
504
1.024
1.016
2.048
2.040
4.096
4.088
Tabelle 7.1
Konfigurierbare Portanzahl vSwitch
Auf Layer-2-Schicht gesehen, verhält sich ein vSwitch ähnlich dem physischen Switch, das heißt, es wird eine MAC-Address-Tabelle vorgehalten, der vSwitch stellt die Frames anhand der MAC-Adressen-Zuordnung anderen Ports zu, unterstützt VLANs (über Port-Groups) und beherrscht Trunking basierend auf IEEE802.1q-VLAN-Tagging Basis. Die MAC-Adressen muss ein vSwitch nicht erst lernen, da er sie bereits durch den VMkernel kennt, der sie vergibt. Was der vSwitch nicht beherrscht, sind die Nutzung von dynamischem 802.1qTrunk (DTP) oder Port-Aggregation (PAgP) und die Verbindung mit anderen vSwitches. Ein vSwitch leitet eingehenden Netzwerkverkehr über einen Uplink niemals über einen anderen Uplink weiter. Dadurch steht ein vSwitch immer allein auf weiter Flur und kann daher auch keine Loops erzeugen. Deshalb unterstützt ein vSwitch auch nicht das Spanning-Tree-Protokoll, das zur Vermeidung von Ethernet-Loops entwickelt wurde. Sobald eine zweite physische Netzwerkkarte als Uplink dem virtuellen Switch hinzukonfiguriert wird, verfügt dieser vSwitch automatisch über Lastverteilung und Ausfallsicherheit. Dies ist eine Standardfunktion des VMkernels und kann nur manuell über die Konfiguration der Failover-Policies abgeschaltet werden. vSwitches müssen aber nicht zwingend über Uplinks verfügen. Sind keine Uplinks vorhanden, können alle angeschlossenen virtuellen Netzwerkkarten miteinander kommunizieren, nur die Physik bleibt außen vor. Dies ist sehr nützlich,
314
Netzwerk-Physik
um abgeschottete Test- oder Entwicklungsumgebungen zu bauen. Außerdem nutzen Produkte wie vShield Zones und Lab Manager diese Funktion. Da die vSwitches ohne Uplinks (Host-only vSwitch) nur für den jeweiligen ESX-Host gelten, ist VMotion für die an dem vSwitch angeschlossenen VMs nicht unterstützt.
Abbildung 7.3 Kommunikation zwischen VMs auf dem gleichen vSwitch verlässt den vSwitch nicht.
Unterhalten sich zwei virtuelle Netzwerkkarten, die an dem gleichen vSwitch angeschlossen sind, können sie ohne die Nutzung von Uplinks kommunizieren, vorausgesetzt, die zugeordneten Portgruppen erlauben dies. Kommunizieren virtuelle Netzwerkkarten miteinander, die auf unterschiedlichen vSwitches angeschlossen sind, werden die Uplinks genutzt.
Abbildung 7.4 Kommunikation zwischen zwei VMs auf dem gleichen ESX-Host, aber unterschiedlichen vSwitches
315
7.1
7
Netzwerk
Diese Tatsache müssen Sie auch immer im Hinterkopf behalten, wenn der Netzwerkverkehr den vSwitch verlässt und natürlich auch wenn er einen physischen Switch verlässt. Denn in letzterem Fall geht der Netzwerkverkehr über die Verbindung zwischen den beiden physischen Switches.
Abbildung 7.5
Switch-Interlink-Nutzung führt zu Nadelöhr.
So stellen Sie sich sehr leicht ein Bein, wenn zusammengehörende virtuelle Maschinen oder auch VMotion-Vorgänge über mehrere physische Switches laufen, obwohl sie eigentlich problemlos auf der Backplane eines physischen Switches bleiben könnten. Dieses Problem kann zu VMotion-Vorgängen von 10 Minuten und länger führen statt der gewohnten Minute. Haben Sie Cisco CDP (Cisco Discovery Protocol) im Einsatz, können Sie sehr schnell orten, welcher vmnic-Uplink über welchen physischen Switch läuft; ansonsten hilft das Switch-Management oder der Weg ins Rechenzentrum. Um solche Probleme zu vermeiden, arbeitet man mit aktiven und Standby-Adaptern in den Portgruppen, worauf wir in den Abschnitten 7.2.5 und 7.2.6 noch eingehen.
7.1.1
Gigabit-Ethernet
Gigabit-Ethernet ist immer noch der Standard im Netzwerksegment und reicht auch für viele Infrastrukturen aus. Ist mehr Leistung gefragt, bietet VMware die Möglichkeit, mehrere GBit-Ports miteinander zu verbinden (Lastverteilung, Aggregation). Dies passiert immer über die Anzahl der Uplinks im vSwitch. Ein Nachteil von Gigabit-Ethernet in komplexen oder leistungshungrigen Umgebungen ist die benötigte Anzahl der Ports (auf Host- und Switch-Seite) und damit auch die Verkabelung. Aus diesem Grund existieren Verfahren in Blade-Systemen, um zumindest die Verkabelung ab dem Blade-Chassis zu verringern, und Technologien wie Infiniband (I/O-Virtualisierung) und 10-Gigabit-Ethernet.
316
Netzwerk-Physik
7.1.2
10-Gigabit-Ethernet
Mit der Freigabe von VMware ESX 3.5 im Dezember 2007 wurden zunächst zwei unterschiedliche 10-Gigabit-Netzwerkadapter unterstützt. Dieses waren die Neterion- und NetXen-Adapter. Inzwischen sind weitere Karten von Intel, Broadcom und vielen anderen Herstellern hinzugekommen. Die aktuellsten Informationen finden Sie immer im Compatibility Guide: http://www.vmware.com/go/hcl Seit einiger Zeit ist 10-Gigabit-Ethernet auch aus Kostensicht interessanter geworden. Bleibt nur noch die Frage: Wie sehr benötigt man 10-Gigabit-Ethernet in VMware-Umgebungen? Für VMware Fault-Tolerance ist es bereits eine Empfehlung von VMware, auf 10-Gigabit-Ethernet zu setzen, wenn auch keine Minimumanforderung. Die Anbindung eines NFS-Datastores über 10-Gigabit-Ethernet oder ein VMotion-Netz auf dieser Basis bringt entscheidende Performance-Vorteile. Gerade bei der hohen Anzahl von virtuellen Maschinen auf einem Host lässt sich so ein Host schneller in den Wartungsmodus bringen. Beim Einsatz von VLANs können mehr Netze über einen Port angebunden werden, ohne dass direkt ein Performance-Engpass entsteht. 10-Gigabit-Ethernet senkt entscheidend den Bedarf an Ports und Leitungen und spart viel Zeit. Redundanzen dürfen Sie dabei aber nicht vergessen. So reicht vielleicht die Leistung eines Ports anstelle von sonst 6–8 Gigabit-Ports aus. Jedoch benötigen Sie auch weiterhin mindestens einen zweiten Port für die Ausfallsicherheit. So könnten Sie aber für den Normalbetrieb einen 10-GigabitEthernet-Port nutzen. Für den Fehlerfall müssen Sie auf ein oder mehrere Gigabit-Ethernet-Ports umschwenken. Für viele Umgebungen gilt im Fehlerfall in erster Linie, dass der Betrieb weiterlaufen muss; Leistungseinbußen werden dafür auch mal in Kauf genommen. Beim Aufrüsten auf 10-Gigabit-Ethernet müssen Sie so nicht gleich alle Komponenten austauschen, sie können Kosten durch Nutzung der bestehenden GigabitInfrastruktur sparen und 10GE zum Beispiel nur für die Anbindung von IP-Storage wie NFS oder iSCSI einsetzen. Gerade in virtuellen Infrastrukturen ist 10-Gigabit-Ethernet bereits heute zu finden. Die Konsolidierung vieler Systeme erfordert eine Leistungsstarke Plattform und damit auch eine sehr gute Netzwerkanbindung.
7.1.3
Vom virtuellen zum physischen Port
Die Virtualisierung schafft definitiv nicht nur Vorteile bei Verwaltung und Übersicht, was Sie in Bezug auf die Netzwerkzuordnung sehr leicht feststellen können.
317
7.1
7
Netzwerk
Ein grundsätzliches Problem besteht z. B. in der Zuordnung zwischen dem Uplink vmnic und dem physischen Switch-Port, auf dem er angeschlossen ist. Derzeit sind zwei Anbieter bekannt, die sich diesem Problem angenommen haben: Cisco und Enterasys. Cisco Discovery Protocol Das Cisco Discovery Protocol (CDP) ist sehr hilfreich im Problemfall, um zum Beispiel zu identifizieren, mit welchem externen Cisco-Switch ein vSwitch verbunden ist. Es werden Informationen zu Switch-Typ, Host-Name, Port-ID, Firmware und Administrationskontakt angezeigt. Klicken Sie dazu einfach auf das Sprechblasensymbol hinter dem entsprechenden Uplink, um diese Vielzahl von Informationen einzusehen.
Abbildung 7.6
Cisco-Discovery-Protocol-Informationen unter VMware
Sind Sie sich unsicher, ob CDP aktiviert ist und in welchem Modus sich CDP befindet, so müssen Sie bei der Verwendung von Standard-vSwitches auf die Kommandozeile wechseln. Der Befehl esxcfg-vswitch hat zwei CDP-bezogene Parameter:
318
Netzwerk-Physik
왘
-b | --get-cdp liest den derzeitigen Status von CDP aus.
왘
-B | --set-cdp setzt den Status auf down (inaktiv), listen (empfängt CDP-
Informationen), advertise (sendet CDP-Informationen) oder both (sendet und empfängt CDP-Informationen). Sind die Einstellungen advertise oder both gesetzt, so können Sie auch auf dem Cisco-Switch die Informationen über den angeschlossenen ESX-Host und dessen Uplink-Bezeichnung auslesen (siehe Abbildung 7.6). Sollten trotz aktiviertem CDP im VMware-Umfeld keine Daten angezeigt werden, unterstützt entweder der genutzte physische Switch kein CDP, oder es wurde deaktiviert. In letzterem Fall kann die Netzwerkabteilung mit Sicherheit weiterhelfen. Enterasys Networks Ein weiterer Netzwerkanbieter, Enterasys, hat eine eigene Implementierung zur Weitergabe von Informationen in die bzw. aus der VMware-Welt für ihre Netzwerkkomponenten entwickelt. Enterasys bietet neben der Ansicht, welcher Uplink auf welchem physischen Switch-Port steckt, auch direkt Informationen zu den auf dem Port erkannten virtuellen Maschinen, was über die CDP-Informationen weit hinausgeht (siehe Abbildung 7.7).
Abbildung 7.7
Informationsspeicherung in den Eigenschaften der VMs
319
7.1
7
Netzwerk
So werden beispielsweise die Portgruppennamen in die Verwaltung der Netzwerkkomponenten übernommen, um eine direkte Zuordnung zu schaffen.
Abbildung 7.8 Übernahme der Portgruppennamen in die Verwaltung der EnterasysKomponenten
Außerdem werden die anhand der virtuellen MAC-Adressen erkannten virtuellen Maschinen automatisch den entsprechenden Endsystemgruppen zugeordnet, auf die man Sicherheitsregeln anwenden kann.
Abbildung 7.9
Direkte Systemzuordnung anhand der erkannten MAC-Adressen
Enterasys bietet hier die Möglichkeit, Sicherheitsregeln mit Service-Profilen zu bilden, so dass einem File-Server nur der Netzwerkverkehr eines File-Servers erlaubt wird. Versehen Sie eine Endsystemgruppe auf Basis der virtuellen Portgruppe mit einem NAC-Regelwerk versehen, dann greift dieses automatisch auch bei jeder der Portgruppe neu zugeordneten virtuellen Maschine. Dabei funktioniert die Nutzungszuordnung in Echtzeit, so dass auch VMotionMigrationen keinen Einfluss auf die zugeordneten Nutzungsprofile haben, da der Switch automatisch den Umzug erkennt.
320
Virtuelle Netzwerke
Abbildung 7.10
7.2
Nutzungsprofilzuordnung für die Endsysteme
Virtuelle Netzwerke
Ein virtuelles Netz besteht aus vielen unterschiedlichen Komponenten. Einige sind für den Einsteiger auf den ersten Blick vielleicht nicht gleich richtig einzuordnen, zum Beispiel die Portgruppen. Viele Komponenten kann man physischen Netzwerkkomponenten gegenüberstellen und so einfacher erklären. Die Verwaltung der virtuellen Netze fiel bisher in den meisten Unternehmen in die Verantwortung der VMware-Administratoren. Ein Grund war sicher, dass die vSwitches nicht über die gleichen Schnittstellen wie physische Switches zu verwalten waren. Dieses ändert sich mit vSphere und den distributed vSwitches.
7.2.1
Netzwerktypen
Bei virtuellen Netzen gibt es drei definierte Netzwerktypen: das Service-Console-, das Virtual-Machine- und das VMkernel-Netz. Je nachdem, welche virtuelle Komponente Sie mit dem vSwitch verbinden möchten, müssen Sie einen anderen Typ von Port-Group wählen. Eine andere entscheidende Frage bei der Erstellung eines Netzwerkes ist der Einsatzzweck des gewünschten Netzes.
321
7.2
7
Netzwerk
Abbildung 7.11
Erstellung eines Netzwerkes – Auswahl des Netzwerktyps
Service-Console-Netz Das Service-Console-Netz ist vor allem für Verwaltung der ESX-Server zuständig: 왘
Verbindungen über den vSphere-Client
왘
Kommunikation vCenter zum ESX
왘
Zugriff auf die Weboberfläche des ESX
왘
SSH Verbindungen zu den ESX Servern
왘
Kommunikation der HA Agenten
Richten Sie ein Service-Console-Netz ein, wird der vSwitch mit der Service Console verbunden. Diese kann dann über einen Uplink überhaupt erst nach außen kommunizieren. Beim Einsatz von ESXi entfällt dieses Netzwerk, bzw. es ist bereits als Management-Network im VMkernel-Port integriert.
Abbildung 7.12
Schematische Darstellung Service-Console-Netz
Virtual-Machine-Netzwerk Ein Virtual-Machine-Netzwerk verbindet die virtuellen Maschinen mit dem physischen Netzwerk, zum Beispiel dem Server-LAN. Somit wird bei einem VirtualMachine-Netzwerk ein Uplink für die VMs erstellt. Natürlich können Sie auch ohne Uplink ein ESX-internes Netz für die virtuellen Maschinen einrichten.
322
Virtuelle Netzwerke
Dabei sollten Sie aber daran denken, welche Einschränkungen bei VMotion und vor allem bei einem DRS-Cluster damit verbunden sind.
Abbildung 7.13
Schematische Darstellung Virtual-Machine-Netz
VMkernel-Netz Für die Verbindung zu einem iSCSI- oder NFS-Speicher benötigen Sie den Netzwerktyp VMkernel. Für VMotion und Fault-Tolerance müssen Sie neben der Auswahl VMkernel auch den entsprechenden Haken für VMotion bzw. FT aktivieren. Seit vSphere wird für eine iSCSI-Verbindung nur noch ein VMkernel-Netz, kein Service-Console-Netz mehr benötigt. Bildlich gesehen wird bei einem VMkernel-Netz eine Verbindung des VMkernels über den vSwitch nach außen erstellt.
Abbildung 7.14
7.2.2
Schematische Darstellung VMkernel-Netz
Standard-vSwitch
Ein Standard-vSwitch ist kurz erklärt ein in Software gegossener Layer-2-Switch. Das bedeutet: Von den Funktionen unterscheidet sich ein vSwitch nicht von einem physischen Switch. Der vSwitch unterstützt keinerlei Layer-3-Funktionen. Verwaltet wird ein vSwitch über den vSphere-Client oder auf der Service Console eines ESX. Die Erstellung eines vSwitches erfolgt automatisch bei Verwendung des Netzwerk-Wizards (Configuration 폷 Network 폷 Add Network). Wann wird ein neuer vSwitch erstellt? Wählen Sie im Netzwerk-Wizard bisher unbenutzte
323
7.2
7
Netzwerk
Uplink-Ports aus, wird ein neuer vSwitch erstellt. Sofern Sie das neue Netz über bereits verwendete Uplinks nach außen verbinden möchten, wird nur eine neue Port-Group auf dem bereits bestehenden vSwitch angelegt. Dieses wird übrigens im Wizard direkt über eine Vorschaugrafik verdeutlicht.
Abbildung 7.15
Hinzufügen eines neuen Netzwerkes – Auswahl der Uplinks
Wie physische Switches hat auch ein vSwitch eine feste Anzahl Ports. Bei der Erstellung eines Standard-vSwitches liegt diese bei 56. Die Anzahl können Sie aber jederzeit in den Eigenschaften eines Switches erhöhen. Dabei ist aber zu beachten, dass die Änderungen erst nach Neustart des entsprechenden ESX-Hosts übernommen werden. Ports werden wie in realen Netzen durch Teilnehmer (Server, Clients …) belegt. In VMware-Umgebungen sind das die virtuellen Maschinen, der VMkernel und die Service Console. Eine virtuelle Maschine im eingeschalteten Zustand belegt einen Port. Wird sie ausgeschaltet, wird der Port wieder frei. Existiert ein VMkernel- xoder Service-Console-Netz auf dem vSwitch, wird jeweils ein Port belegt. Kontrollieren lässt sich die Anzahl der aktuell belegten Ports nur über die Service Console mit Hilfe des Befehls esxcfg-vswitch –l. Schauen sie sich den vSwitch über die Console an, stellen Sie fest, dass ein vSwitch tatsächlich 64 Ports hat. Das hängt damit zusammen, dass der Hypervisor immer acht Ports für die Verwaltung reserviert. Es werden aber nicht alle dieser acht Ports immer verwendet. Dies lässt sich mithilfe der Anleitung im folgenden Kasten errechnen: Berechnung der vom Hypervisor verwendeten Ports Gesamtanzahl verwendeter Ports auf dem vSwitch abzüglich Service-Console-Ports, VMkernel-Port und der Anzahl Ports der virtuellen Maschinen.
324
Virtuelle Netzwerke
Das ergibt die Menge der aktuell vom Hypervisor verwendeten Ports auf dem entsprechenden vSwitch. Beispiel: [root@esxprot01 root]# esxcfg-vswitch -l Switch Name Num Ports Used Ports Configured Ports MTU vSwitch0 64 7 64 1500 PortGroup Name VLAN ID Used Ports Uplinks VM Network 0 1 vmnic0,vmnic1 Service Console 0 1 vmnic0,vmnic1 VMkernel 0 1 vmnic0,vmnic1
Uplinks vmnic1,vmnic0
vSwitch0 verwendet aktuell 7 Ports, abgezogen werden 1 Port für die Service Console, 1 Port für den VMkernel und 1 Port für eine virtuelle Maschine. Bleiben 4 Ports, die im Moment noch belegt sind. Das bedeutet: Von den 8 reservierten Ports benutzt der Hypervisor zurzeit 4. Im Übrigen ist es vollkommen richtig und auch üblich, bei einem vSwitch von z. B. 56 Ports zu sprechen; die 8 Ports für den Hypervisor werden nicht mit eingerechnet. Grenzwerte eines Standard-vSwitches Auf einem ESX-Host können maximal 248 Switches erstellt werden. Ein Standard-vSwitch unterstützt bis zu 4 088 virtuelle Ports, dabei dürfen in Summe auf einem Host nicht mehr als 4 096 virtuelle Ports existieren.
7.2.3
Portgruppen
Eine Portgruppe ist eine Komponente, die eine Besonderheit in virtuellen Netzen darstellt und die es in ihrer Art und Weise nicht in physischen Netzen gibt. Kurz erklärt ist eine Portgruppe eine logische Einheit auf einem vSwitch. Auf der Ebene einer Portgruppe können Sie Netzwerktyp, VLAN-Tagging, Traffic Shaping, Security, Teaming und Load-Balancing einstellen. Würde man sich virtuelle Netze in Schichten vorstellen so wären auf der untersten Ebene in einem ESX-Server die physischen Netzwerkports zu finden, eine Ebene weiter oben die vSwitches, dann die Portgruppen bis zu den Netzwerkadaptern der virtuellen Maschinen sowie die Netzwerkschnittstelle des VMkernels und der Service Console. Wie bei den vSwitches wird eine Portgruppe immer automatisch durch den Wizard zur Erstellung von Netzwerken angelegt. Hierbei gilt allerdings, dass pro Netzwerk immer eine Portgruppe erstellt wird.
325
7.2
7
Netzwerk
Abbildung 7.16 Grafische Netzwerkdarstellung im vSphere-Client – Unterscheidung von Port-Group, vSwitch und Uplink
Teaming und Load-Balancing auf Portgruppen-Ebene Bisher wurde das Thema Teaming und Load-Balancing auf der physischen Netzwerkseite betrachtet. Eine nette Erweiterung und Optimierung kann aber in diesem Bereich mit Hilfe der Port-Groups erfolgen. Als Beispiel könnte ein vSwitch mit zwei Uplinks dienen. Die beiden Uplinks sind mit zwei getrennten Switches verbunden. In den meisten Fällen müssen Sie jetzt mit einem aktiven und einem Standby-Uplink arbeiten; das wäre keine optimale Auslastung der vorhandenen Hardware.
Abbildung 7.17
Überschreiben der vSwitch-Einstellungen in der Port-Group
Würde man nun aber beide Ports aktiv am vSwitch konfigurieren, könnte eine Port-Group den ersten Uplink aktiv und den zweiten Uplink im Standby-Modus verwenden. Eine zweite Port-Group könnte aktiv über den zweiten Uplink arbeiten und als Standby-Adapter den ersten Uplink verwenden. Auf diese Wiese wür-
326
Virtuelle Netzwerke
den die beiden externen Switch aktiv genutzt ohne eine Verbindung zwischen den beiden Switches oder einem switch-übergreifenden Etherchannel (oder LACP). Dieser Ansatz ist vor allem für Umgebungen gedacht, die aus technischen oder finanziellen Gründen nicht die Möglichkeit haben, switch-übergreifend ein LoadBalancing einzurichten. VLAN VLANs ist eine logische Trennung von Netzwerkpaketen, das heißt, EthernetPakete werden aufgrund einer Anpassung im Header (VLAN-Tagging) zugeordnet. Die meisten physischen Switches unterstützen VLAN-Tagging, um eine zusätzliche Unterteilung der Ports zu erreichen. Somit könnten Sie auf einem 24Port-Switch jeweils 8 Ports durch unterschiedliche VLAN-Zuordnung gruppieren. Systeme, die an Ports mit VLAN-ID 3 angeschlossen sind, können so nicht mit Systemen an Ports mit VLAN-ID 5 kommunizieren. Soll dies trotzdem passieren, müssten Sie mit einem Router oder Gateway arbeiten. Es gibt allerdings die Möglichkeit, einzelne Ports eines Switches mehreren oder allen VLAN-IDs zuzuordnen, das heißt, diese Ports erhalten sämtliche Pakete und nicht nur die eines bestimmten VLANs. Diese Ports werden VLAN Trunk Port genannt und werden sehr häufig im ESX-Umfeld eingesetzt. Die Portgruppen sind der einzige Konfigurationspunkt, der für den Umgang mit VLANs verantwortlich ist. Für jedes zu nutzende VLAN müssen Sie eine entsprechende Portgruppe anlegen. Der ESX-Server geht dabei im Standard mit VLANPaketen so um, dass deren VLAN-Tagging für die virtuellen Maschinen entfernt wird.
Abbildung 7.18
Portgruppe, die nur Pakete des VLANs 13 bedient
Die Konfiguration, welche Portgruppe für welche VLAN-Pakete zuständig ist, treffen Sie bei der Anlage oder in den Eigenschaften der Portgruppe. Die Werte für normale VLANs reichen von 1 bis 4094 sowie 0, was für kein VLAN steht. Es muss nun zwischen drei unterschiedlichen Portgruppentypen in Bezug auf VLANs unterschieden werden, die sich anhand der Konfiguration des physischen Switches bestimmen.
327
7.2
7
Netzwerk
Abbildung 7.19
Umgang mit VLAN-Tagging
Der einfachste Fall ist eine Portgruppe ohne VLAN-ID, das heißt, hier kommen nur nicht-getaggte Pakete an. Dies ist der Fall, wenn entweder keine VLAN-ID auf dem physischen Switch-Port konfiguriert oder wenn eine Default-VLAN-ID eingestellt ist. In letzterem Fall entfernt bereits der Switch das VLAN-Tagging. Möchten Sie auf einem vSwitch mehrere VLANs mit der Portgruppe trennen, so müssen die Uplinks des vSwitches an VLAN Trunk Ports auf dem physischen Switch angeschlossen sein. Somit bleiben die VLAN-Tags erhalten, und der virtuelle Switch erhält viele Pakete mit unterschiedlichsten VLAN-IDs. Durch die Portgruppen wird mittels VLAN-ID dann zwischen den Paketen unterschieden, das heißt, der VMkernel sortiert die Pakete anhand der jeweiligen VLAN-ID der Portgruppe zu. Da die Portgruppe nur Pakete einer VLAN-ID sehen darf, entfernt der VMkernel bei Dateneingang die VLAN-Tagging-Information aus den Ethernet-Paketen und fügt sie bei Datenausgang wieder automatisch hinzu. Dann müssen Sie die Gäste nicht anpassen, für das Gastbetriebssystem kommen nämlich nur nicht-getaggte Pakete ohne VLAN-Informationen an, ein Standard-Ethernet-Frame also. Es existiert noch eine weitere Ausnahme, und zwar VLAN-ID 4095, die für VLAN-Pass-through steht, das heißt, die Netzwerkpakete werden nicht angepasst und gehen samt VLAN-Tagging zur Gastnetzwerkkarte durch. In diesem Fall muss sich ebenfalls das Gastbetriebssystem um die VLANs kümmern.
328
Virtuelle Netzwerke
Abbildung 7.20
7.2.4
VLAN 4095 steht für VLAN-Pass-through
Erweiterte vSwitch-Konfiguration
In physischen Netzen findet man zum Beispiel Management-, Client-, Server-, Storage- und Backup-Netze. Die Liste ließe sich beliebig verlängern. Der wesentliche Unterschied sind aber der Einsatzzweck und die damit verbundenen technischen Anforderungen. So muss ein Server- und Storage-Netz meist durchgehend redundant und mit hoher Bandbreite ausgelegt sein. Dagegen ist ein Client-LAN vielleicht nicht komplett redundant, die Geschwindigkeit hängt ab von den Anforderungen der Applikationen, die auf den Clients eingesetzt werden. Ein weiteres Merkmal sind die Lastzeiten. Ein typisches Beispiel für ein solches Netz mit definierten Hochlastzeiten ist ein Backup-Netz. Dieses wird häufig vor allem in der Nacht belastet, da dann alle Server und Clients über dieses Netz gesichert werden.
7.2.5
Teaming
Bei den unterschiedlichen Netzwerktypen haben wir bereits einige Anforderungen an ein Netz aufgeführt: Verfügbarkeit und Geschwindigkeit. Was wird dafür überhaupt benötigt? Angefangen beim Server kann dies bedeuten: mehr als ein Netzwerkport, und mehr als ein Netzwerkadapter. Im weiteren Verlauf mehr als ein Switch-Port, mehr als ein Switch. Für eine hohe Verfügbarkeit im Netz brauchen Sie redundante Komponenten, die im Fehlerfall (Linkabbruch) transparentes Umschalten ermöglichen. Bei einem Server, natürlich auch bei einem Client, kann dies mit Hilfe eines Teamings erfolgen. Hierbei werden mehr als ein physischer Port zu einem logischen Port zusammengefasst. Kommt es zum Ausfall eines Ports, kann der andere Port die Verbindung übernehmen. Klassischerweise wird in diesem Fall von einem active/passive-Team gesprochen. ESX-Server unterstützen das Zusammenfassen physischer Netzwerkports, um die Verfügbarkeit zu erhöhen. Zur Konfiguration eines solchen Teams müssen Sie einen vSwitch mit mehr als einem Netzwerkport erstellen. Per Default werden
329
7.2
7
Netzwerk
beide Netzwerkports aktiv gesetzt, somit wird ein Load-Balancing konfiguriert. Für ein klassisches Teaming müssen Sie einen der beiden Ports in den SwitchEigenschaften auf Standby setzen.
Abbildung 7.21
vSwitch Übersicht – vSwitch mit einem Standby-Port
Vorteile und Nachteile eines Netzwerk-Teamings Mit Hilfe eines Teamings schaffen Sie vor allem eine erhöhte Verfügbarkeit. Dabei ist zu beachten, dass ein Teaming adapterübergreifend erfolgen sollte. Ein Zusammenfassen von zwei Ports auf einem Adapter schützt nicht bei Ausfall der Karte oder des PCI-Slots. Im Netz sollte ein Team auch auf unterschiedliche Switches verbunden sein, um den Ausfall eines Switches zu überstehen. Dabei ist auf den Switches keine Konfiguration nötig, da immer nur über einen Adapter gearbeitet wird. Ein Nachteil für ein klassisches Teaming ist das Bereitstellen der reinen Standby-Komponenten (z. B. zweiter Netzwerkadapter). Dieses lässt sich aber durch ein gutes Design optimieren! Mehr dazu im weiteren Verlauf dieses Kapitels (vgl. Abschnitt 7.3, »Architektur-Beispiele«).
7.2.6
Load-Balancing
Für eine höhere Geschwindigkeit im Netz ist ein Load-Balancing nötig. Wie zuvor beim Teaming wird mehr als ein Netzwerkport zu einem logischen Port zusammengefasst. Jedoch werden jetzt z. B. zwei Ports aktiv genutzt. Das bedeutet: Die Netzwerkpakete werden über die beiden Netzwerkports verteilt. Geht man von der Standardkonfiguration aus, so würde eine Verteilung der Netzwerkpfade durch den VMkernel im einmaligen Round-Robin-Verfahren stattfinden, das heißt, beim Starten der virtuellen Maschine wird ein Uplink für die gesamte Laufzeit konfiguriert. Falls dieser Standardpfad ausfällt, wird der nächstfolgende aktive Uplink genutzt.
330
Virtuelle Netzwerke
Abbildung 7.22 Standardverteilung der Uplinks bei zwei VMs – jedem virtuellen Netzwerkadapter wird ein physisches Gegenstück zugewiesen.
Da nicht die virtuelle Maschine, sondern der virtuelle Netzwerkadapter zählt, wird auch jedem vNIC-Port ein physischer Uplink zugewiesen. Je mehr Uplinks zur Verfügung stehen, desto geringer muss die Mehrfachbelegung stattfinden. Daher erhält eine Ein-vNIC-VM einen Uplink und eine Zwei-vNIC-VM zwei Uplinks.
Abbildung 7.23
VMkernel und Service Console nutzen einen Port.
Jeder VMkernel- und Service-Console-Port nutzt nur einen Uplink, das heißt, um mehrere GBit-Adapter zu nutzen, müssen Sie auch mehrere VMkernel-Ports anlegen. So trivial ist es allerdings nicht, da natürlich auch die Zielsysteme passen müssen, es muss also ein weiteres iSCSI-Target oder NFS-Target mit zweiter IP existieren. Sie können bis zu 16 Service-Console-Ports erstellen.
331
7.2
7
Netzwerk
Dabei gibt es unterschiedlichen Methoden zur Verteilung der Pakete.
Abbildung 7.24
vSwitch-Eigenschaften – Einstellung der Paketverteilung
Route based on the originating virtual port ID Bei der Option Route based on the originating virtual port ID wird anhand des Ports, über den die Pakete in den Switch gelangen, entschieden, welcher Uplink die Weiterleitung übernimmt. Stellt man sich einen vSwitch mit zwei Uplinks und vier virtuellen Maschinen vor, könnte dies bedeuten, dass die Daten der ersten und der dritten virtuellen Maschine über Uplink 1 weitergeleitet werden, Daten der zweiten und vierten VM über Uplink 2. Sofern Uplink 1 mit einem externen Switch und Uplink 2 mit einem anderen Switch verbunden ist, werden beide Switches aktiv genutzt. Daten einer virtuellen Maschine bzw. eines virtuellen Netzwerkadapters werden aber immer an den gleichen externen Switch gesendet. Ist anstatt des Netzwerks mit virtuellen Maschinen ein VMkernel- oder ein Service-Console-Port konfiguriert, würde sämtlicher Netzwerkverkehr über einen Uplink verschickt. Es fände keine Verteilung statt, da pro Port jeweils nur ein Uplink verbunden wird. Bei Ausfall eines Uplinks wird der gesamte Traffic auf den noch bestehenden Uplink umgelenkt. Route based on ip hash Wählen Sie Route based on ip hash, wird eine Prüfsumme aus der IP-Adresse des Senders und der des Empfängers gebildet und dann entschieden, über wel-
332
Virtuelle Netzwerke
chen Uplink die Pakete verschickt werden. Es handelt sich dabei um IEEE802.3 ad, »Link-Aggregation«, daher müssen die beteiligten physischen Switches dies auch unterstützen. Im zuvor genannten Beispiel mit den vier virtuellen Maschinen bedeutet dies, dass jeder NIC jeder virtuellen Maschine jeden Uplink nutzen kann. Sendet die erste virtuelle Maschine Pakete an einen Teilnehmer; wird eventuell Uplink 1 verwendet, für den Versand an einen anderen Teilnehmer vielleicht Uplink 2. Das Gleiche gilt für die anderen virtuellen Maschinen. Die externen Switches müssten Sie mit einem übergreifenden Etherchannel/LACP konfigurieren. Dadurch wird der Switch-Port, auf den Uplink 1 verbunden ist, und der Port des zweiten Uplinks zu einem logischen Port auf den externen Switches zusammengefasst. Der Grund dafür ist, dass sowohl Switch 1 als auch Switch 2 unter Umständen Pakete von derselben virtuellen Maschine bekommen und nur so ARP-Tabellen (Adress Resolution Table) entsprechend gepflegt werden können. Im Fall eines VMkernel- oder Service-Console-Netzwerkes würden jetzt auch beide Uplinks aktiv genutzt. Der Verkehr würde über beide Switches verteilt. Voraussetzung ist natürlich, dass VMkernel oder Service Console Daten an mehr als einen Empfänger und damit an mehrere IP-Adressen versenden. Sollte ein Uplink ausfallen, wird über den noch verfügbaren Link die Verbindung aufrechterhalten. Besitzt eine virtuelle Maschine mehrere Netzwerkadapter. über die kommuniziert werden soll, so erreichen Sie mit IP-based Load-Balancing das beste Ergebnis. Nur bei großen Datenmengen über die gleiche IP-Verbindung bringt dieses Verfahren keine Vorteile. Route based on source MAC hash Mit Route based on source MAC hash wird anhand der MAC-Adresse des Senders entschieden, über welchen Port die Daten verschickt werden. Der Sender kann in dem Fall eine VM, der VMkernel oder die Service Console sein. Das Verhalten ist sehr ähnlich der Verteilung auf Basis der originating virtual Port-ID. Als Entscheidungskriterium dient nicht der Port, auf dem eine virtuelle Maschine, ein VMkernel oder eine Service Console mit dem vSwitch verbunden ist, sondern die MAC-Adresse, von der aus ein Paket gesendet wird. Dies kann zum Beispiel die MAC-Adresse einer virtuellen Maschine sein. Eine Etherchannel-Konfiguration auf den physischen Switch ist hierbei nicht nötig. Der Verkehr einer virtuellen Maschine wird immer über den gleichen Uplink an denselben Switch gesendet.
333
7.2
7
Netzwerk
Wie bei den anderen Regelungen wird ein Ausfall eines Uplinks abgefangen und sämtlicher Netzwerkverkehr über den noch verfügbaren Port fortgesetzt. Use explicit failover order Bei der Auswahl Use explicit failover order wird immer der erste Adapter aus der Liste der aktiven Uplinks verwendet. Failover-Regelungen werden dabei unterstützt! Eine Verteilung über mehrere Uplinks erfolgt nicht! Sind zwei Adapter aktiv konfiguriert, wird der Verkehr nur über Uplink 1 erfolgen, bis dieser nicht mehr verfügbar ist. In dem Fall wird auf Uplink 2 umgeschaltet. Ein typischer Fall, Explicit Failover zu nutzen, ist zur Steuerung des Netzwerkverkehrs. Möchten Sie beispielsweise den Netzwerkverkehr des VMotion-VMkernel-Adapters auf einen Uplink beschränken, so verändern Sie die Failover-Order, indem nur der zu nutzende Uplink aktiv ist, alle anderen Adapter des vSwitches würden Sie auf Standby konfigurieren. Somit ist es z. B. möglich, den VMotion-Datenverkehr zwischen den ESX-Hosts immer auf dem gleichen physischen Switch zu übertragen und so die Backplane des Switches zu nutzen. Darauf sollten Sie auch immer achten, da ansonsten der VMotion-Verkehr über die physischen Verbindungen der physischen Switches liefe, was zumeist wesentlich langsamer ist als die Backplane. Dies fällt besonders schnell auf, wenn jegliche VMotion-Vorgänge fünf Minuten und länger dauern. Voraussetzung für den Einsatz eines Load-Balancings Für ein Load-Balancing werden vor allem an den externen Switch Anforderungen gestellt. So kann meist kein Load-Balancing mittels IP-Hash über zwei getrennte Switches erfolgen. Ausnahme sind Switches, die Multichassis-Link-Aggregation unterstützen, zum Beispiel Nortel Networks, Extreme Networks und Arista Networks. Bei einem einzigen Switch oder zwei miteinander verbundenen Switches gibt es in der Regel keine Einschränkungen, allerdings ist wie immer im LAN-Umfeld auf die Vermeidung von Loops und den Einsatz von Spanning Tree zu achten. Es bewährt sich, nach der Einrichtung eines Load-Balancings die Verteilung der Pakete mit Hilfe der Port-Statistik langfristig zu verfolgen. Es ist keine genaue Verteilung, bei zwei Ports zum Beispiel von 50 %, zu erwarten, sie sollte aber erkennbar sein. Auch ein esxtop ist sehr hilfreich sein, um zu sehen, über welche vmnic-Adapter überwiegend gesendet wird. Eine mittlerweile interessante Alternative zu Link-Aggregation mit mehreren 1-GBit/s-Verbindungen ist der Umstieg auf 10-GBit-Ethernet-Technologie.
334
Virtuelle Netzwerke
Die Wahl der passenden Paketverteilung VMware hat als Default-Einstellung Route based on the originating virtual port ID gewählt. Diese ist aber nicht immer die optimale Wahl. Der grundsätzliche Vorteil für die Verteilung auf Basis von Port-ID und Source-MAC ist, dass Sie an externen Switches keine Einstellungen vornehmen müssen. Bei der Verteilung mit Hilfe des IP-Hashes müssen Sie immer einen Etherchannel auf den externen Switches konfigurieren. Der erste Entscheidungsfaktor ist sicher daher auch der physische Switch und die Netzwerkinfrastruktur. Ein weiterer Faktor ist die Anzahl der Netzwerk-Clients. So befinden sich in einem VM-Netzwerk vielleicht viele Clients, und eine Verteilung auf Basis von Source-MAC und Port-ID ist eventuell sehr effizient. Dagegen sind in einem VMkernel-Netz eher wenige Clients vorhanden. Es kann sich sogar um eine 1:1Verbindung zwischen VMkernel und Storage-System handeln. Eine Verteilung auf Basis-Source-MAC und Port ID ist dann möglicherweise auch weniger effizient, eine Verteilung mittels IP-Hash bei entsprechender Infrastruktur eventuell von Vorteil. Obwohl IP-hash-basiertes Load-Balancing auch den Netzwerkverkehr von einzelnen VMs (bei Kommunikation zu mehreren IPs) besser verteilen kann, sinken die Vorteile bei steigendem Datenvolumen, da der IP-Hash aus Quelle und Ziel-IP immer gleich ist. Maximale Anzahl Netzwerkports Eine harte Grenze ist sicher die Anzahl freier Slots im Server. VMware selbst hat eine Beschränkung auf Basis der Netzwerkports festgelegt. Dabei werden aktuell bis zu 32 Ports pro ESX-Server unterstützt, das aber nur beim Einsatz von bestimmten Intel- (e1000) oder Broadcom-Adaptern (tg3). Detaillierte und aktuelle Informationen können Sie dem Dokument »Maximalwerte für die Konfiguration« entnehmen: http://www.vmware.com/files/de/pdf/vsp_40_config_max_de.pdf Kombination von Teaming und Load-Balancing Natürlich können Sie die genannten Methoden im Bereich Teaming und LoadBalancing kombinieren. Ein mögliches Beispiel wäre ein vSwitch mit vier Uplinks. Zwei Uplinks sind mit einem lokalen Switch verbunden und sind die aktiven Ports. Ein weiterer Uplink ist mit einem entfernten Switch, vielleicht über Lichtwellenleiter, in einem anderen Brandabschnitt oder Gebäude verbunden. Der Uplink wäre als Standby konfiguriert und übernähme bei Ausfall des lokalen Switches. Zudem könnte die gleiche Konfiguration, nur umgekehrt, nochmals im anderen Brandabschnitt vorliegen.
335
7.2
7
Netzwerk
Bei zwei Standby-Adaptern würde bei Ausfall eines aktiven Ports nur ein Standby-Port aktiviert. Dies kann zu Problemen bei der Verteilung der Pakete mittels IP-Hash führen, da vielleicht auf jedem Switch ein separater Etherchannel konfiguriert ist. Sie können im ESX-Server nicht konfigurieren, dass auch der noch bestehende Uplink auf den zweiten Switch umgeschaltet wird. Bei Ausfall des kompletten Switches oder beider Uplinks würde dagegen komplett umgeschaltet. Daher sollten Sie überprüfen, ob bei Ausfall nur eines Ports eine ordentliche Paketverteilung gewährleistet ist. Weitere Beispiele, die Load-Balancing und Teaming kombinieren, finden Sie am Ende des Kapitels.
7.2.7
Link-State vs. Beaconing (Network Failover Detection)
Der Option, einen Netzwerkausfall – besser: den Ausfalls eines Uplinks – zu erkennen, wird oft wenig Aufmerksamkeit geschenkt, obwohl sie enorm wichtig ist. Der Standard Link State only erkennt nämlich nur wirkliche physische Ausfälle der Netzwerkkarten, z. B. wenn ein Switch ausfällt oder die Netzwerkkarte oder das Kabel defekt oder ausgesteckt ist. Mit Link State only wird daher nur die elektronische Übertragungsmöglichkeit zwischen Netzwerkkartenport und physischem Switch-Port überwacht.
Abbildung 7.25
vSwitch-Eigenschaften – Einstellung von Beacon Probing
Allerdings kann es durch fehlende VLAN-Konfiguration oder logisches Blocken eines Switch-Ports, z. B. durch Spanning Tree, dazu kommen, dass der Link nach wie vor verfügbar ist, die Pakete allerdings trotzdem nicht den Empfänger erreichen, da ein logischer Fehler vorliegt. An dieser Stelle kommt die Beaconing Probing-Funktion ins Spiel, die kleine Beacon-Pakete über die Uplinks an die jeweiligen Partner-Uplinks des vSwitches oder der Portgruppe sendet. Kommen die Pakete an, ist alles in Ordnung; gehen sie aber auf dem Weg zum Ziel verloren, wird der Uplink als ausgefallen markiert und nicht mehr weiter genutzt. Stattdessen kommt die Failover-Policy zum Tragen.
336
Virtuelle Netzwerke
Service Console
BeaconPaket
vSwitch0
vmnic0
VMotion
BeaconPaket vmnic1
Switch0 BeaconPaket
vmnic2
Virtual Machine
Abbildung 7.26
vSwitch-Eigenschaften – Beacon Probing
Damit Beaconing sauber funktioniert, sind allerdings mindestens drei Netzwerkkarten als Uplink in einem vSwitch notwendig, da bei zweien nicht festgestellt werden kann, welcher ausgefallen ist.
7.2.8
Failover – Switch Notification (Notify Switches)
Bei Ausfall eines Uplinks kann ein spezielles ARP-Paket an den externen Switch gesendet werden. Dadurch wird erreicht, dass ein Switch aktiv über einen Failover vom ESX-Server informiert wird. So kann der ESX-Server seine ARP-Tabellen aktualisieren und eintragen, dass Teilnehmer, die zuvor über den ausgefallenen Uplink zu erreichen waren, nun über einen anderen Weg verbunden sind. Dies ist in jedem Fall zu empfehlen, da es sonst zu Verbindungsproblemen der Clients zu den virtuellen Maschinen nach einem VMotion-Vorgang kommen kann, da virtuellen Maschinen den Weg immer noch über den alten Switch suchen.
7.2.9
Traffic Shaping
Die Funktion Traffic Shaping, zu finden in den vSwitch- oder Port-Group-Eigenschaften, reguliert die Netzwerkbandbreite. Bei Standard-vSwitches kann dies für die Senderichtung erfolgen, bei distributed vSwitches auch für die Empfangsrichtung. Dabei können Sie drei Faktoren einstellen.
337
7.2
Netzwerk
Abbildung 7.27
vSwitch-Eigenschaften – Einstellungen Traffic Shaping
Average Bandwidth Mit der Option Average Bandwidth stellen Sie die zulässige Bandbreite für eine Port-Group oder einen gesamten vSwitch ein. Die Angabe erfolgt in Kbits/sec und gilt bei einem Standard-vSwitch für den ausgehenden Verkehr. Bei einem distributed vSwitch können Sie darüber auch den eingehenden Verkehr regulieren. Peak Bandwidth Die Einstellung Peak Bandwidth ist per Default gleich der Average Bandwidth. Sie gibt die kurzzeitige maximale Bandbreite für eine Port-Group oder einen vSwitch an. Voraussetzung ist, dass noch entsprechende Netzwerkbandbreite verfügbar ist. Ist dies der Fall, kann über einen Port mit einem höheren Durchsatz als in der Average Bandwidth angegeben gesendet werden. Dabei gibt die Peak Bandwidth die harte Grenze an. Burst Size Die Burst Size begrenzt die Dauer für die Nutzung der Peak Bandwidth durch einen Port. Die Burst Size definiert also die maximale Menge an Daten, die mit der Peak Bandwidth verschickt werden dürfen. Kbit/sec.
7
BurstSize
Average Bandwidth
Peak Bandwidth
t
Abbildung 7.28
338
Schematische Darstellung der Traffic Shaping-Faktoren
Virtuelle Netzwerke
7.2.10 Sicherheit Im Bereich Security haben Sie drei wesentliche Einstellungsmöglichkeiten, die unter gewissen Umständen oder bei einigen Anforderungen benötigt werden.
Abbildung 7.29
Switch-Einstellungen im Security-Bereich
Promiscuous Mode Der Promiscuous Mode ist per Default deaktiviert. Bei seiner Aktivierung besteht die Möglichkeit, den Netzwerkverkehr auf dem vSwitch aus einer virtuellen Maschine heraus mitzuschneiden. Dafür müssen Sie nur noch eine Netzwerk-Analyzer-Software innerhalb des Gastbetriebssystems installieren. Ein Beispiel wäre Wireshark. Durch die Aktivierung des Promiscuous Mode wird der vSwitch in eine Art Hub-Funktion umkonfiguriert, das heißt, alle Pakete werden auf allen Ports dieser Portgruppe ausgegeben. Daher können Sie den gesamten Netzwerkverkehr des vSwitches auf einem Port verfolgen. Netze, die mit Hilfe von VLANs getrennt sind, bleiben getrennt, was bedeutet, dass nur die Pakete innerhalb desselben VLANs gelesen werden können. Wichtig ist aber, zu bedenken, dass es bei Aktivierung des Promiscuous Mode zu vermehrten Kollisionen im Netz kommen kann; aktivieren Sie ihn daher nur, wenn wirklich der Bedarf besteht! MAC Address Changes Aktivieren Sie MAC Adressänderungen, werden eingehende Frames verworfen, wenn innerhalb eines Gastbetriebssystems die MAC-Adresse verändert wurde. Dafür vergleicht der vSwitch die in der vmx-Datei eingetragene MAC mit der aktuell von der virtuellen Maschine verwendeten Adresse. Sobald im Gastbetriebssystem wieder auf die Original-MAC-Adresse umgestellt wird, leitet der vSwitch die eingehenden Frames wieder weiter. Per Default ist die Einstellung ausgeschaltet, und eingehende Frames werden bei veränderter MAC einfach an die neue Adresse zugestellt.
339
7.2
7
Netzwerk
Forged Transmits Mit gefälschte Übertragungen werden ausgehende Frames bei veränderter MAC-Adresse verworfen. Standardmäßig ist diese Funktion deaktiviert, und somit werden alle Frames gesendet, auch bei veränderter MAC-Adresse.
7.2.11
Distributed vSwitch
Der distributed vSwitch ist die nächste Generation der virtuellen Switches. Mit vSphere zum ersten Mal verfügbar, soll er den administrativen Aufwand reduzieren und viele neue Funktionen und Möglichkeiten bieten, vor allem, um die Verwaltung der virtuellen Netze an die Netzwerkadministration zu übergeben. Einer der Vorteile besteht darin, dass dvSwitches ESX-host-übergreifend sind und dementsprechend auch die in den dvSwitches angelegten Port-Groups. Das verhindert die bisherigen Probleme bei der unterschiedlichen Namensvergabe von Portgruppen und der damit verbundenen VMotion- und HA-Thematik. Dafür ist vor allem die Integration von Third-Party-Switches in der virtuellen Welt interessant.
Abbildung 7.30
Grobdarstellung distributed vSwitch
Die dvSwitches werden über das vCenter gesteuert, und dieses muss zur Konfiguration auch verfügbar sein. Allerdings läuft der Betrieb der dvSwitches auch ohne eine vCenter-Verbindung ähnlich VMware HA weiter.
340
Virtuelle Netzwerke
distributed ports und Port-groups
VMkernel Port
Virtual Machine Port-Group
Service Console Port
distributed Switch (control plane)
vCenter Server
COS vNICs hidden vSwitches (I/O plane) virtuell physikalische NICs (Uplinks)
physikalisch
physikalische Switches
ESX 1
Abbildung 7.31
ESX 2
Schematische Darstellung eines distributed vSwitch
Technische Integration Ein Beispiel im weiteren Verlauf des Kapitels wird der Cisco Nexus 1000v sein. Die dazugehörigen Komponenten sind die I/O Plane (Forwarding, Filtering und Teaming der Kommunikation), die Control Plane (Port-Konfiguration, Koordination der I/O Plane ESX-host-übergreifend) und der I/O Agent (VMkernel-Prozess auf jedem ESX-Host, Koordination der Kommunikation zwischen Control Plane und I/O Plane).
Dritthersteller vSphere Client Plugin
DB
vCenter
vCenter Extension
Control Plane
Control Plane Appliance
Abbildung 7.32
ESX 4
ESX 4
ESX 4
dvSwitch I/O Agent
I/O Plane
vSwitch
vSwitch
Integration von Dritthersteller-vSwitches
341
7.2
7
Netzwerk
Standard-vSwitch
distributed vSwitch
vNetwork-Standard-Switch (vSwitch)
vNetwork distributed Switch (dvSwitch oder DVS)
Einrichtung pro ESX-Host
Einrichtung pro vCenter
Geltungsbereich ESX-Host.
Geltungsbereich vCenter-Server
Konfiguration und Unterteilung mittels Port-Groups, VLAN, Typ
gleiche Funktionalität wie StandardvSwitch.
Konsistenz zwischen ESX-Hosts manuell zu konfigurieren
nur bei Enterprise-Plus-Lizenz
in jeder Lizenzstufe des ESX Servers enthalten
automatisch konsistente Konfiguration in der virtuellen Umgebung Nutzung von Private VLANs möglich Nutzung von Third-Party-vNetworkSwitches möglich, z. B. Nexus 1000v Netzwerkstatistiken und Regelwerke hostübergreifend, z. B. bei VMotion
Tabelle 7.2
7.2.12
Unterschiede Standard-vSwitch und distributed vSwitch
Erstellen eines distributed vSwitch
Für die Erstellung eines dvSwitches wechseln Sie in den Bereich Networking (Home 폷 Inventory 폷 Networking). Nach Auswahl des gewünschten Datacenters können Sie über die rechte Maustaste auf dem gewünschten Datacenter einen neuen dvSwitch i erstellen. Voraussetzung für die Erstellung von dvSwitches ist ein funktionierender Update Manager. Zudem muss in dem vSphere-Client, mit dem Sie den dvSwitch anlegen wollen, das Plug-in für den Update Manager installiert und aktiviert sein! Zur Erstellung eines dvSwitches öffnet sich ein Wizard. Dieser fragt zunächst den Namen des dvSwitches und die maximale Anzahl der Uplinks pro Hosts ab. Ein Uplink entspricht hier einem physischen Netzwerkport eines ESX-Hosts. Es können bis zu 32 Uplinks pro ESX-Host eingebunden werden. Allerdings müssen diese Uplinks nicht alle gefüllt werden, das heißt, Hosts können unterschiedlich viele Uplinks dem dvSwitch zuordnen. Im zweiten Schritt werden die ESX-Hosts im zugehörigen Datacenter angezeigt, und Sie können die noch freien Ports als Uplinks hinzufügen. Im dritten Schritt wird per Default eine erste dvPortGroup angelegt.
342
Virtuelle Netzwerke
Abbildung 7.33
Erstellen eines neuen distributed vSwitch
Abbildung 7.34
Uplinks dem dvSwitch zuordnen
Abbildung 7.35 Nach der Zuordnung des ESX-Hosts zum dvSwitch erscheint der dvSwitch auch in der Konfiguration des ESX-Systems.
343
7.2
7
Netzwerk
Fügen Sie einen ESX-Host zu einem distributed vSwitch hinzu, wird im Hintergrund ein sogenannter versteckter vSwitch auf dem ESX angelegt. Sie können sich also vorstellen, dass ein distributed vSwitch eine Zusammenfassung mehrerer einzelner host-basierter Switches ist. Dadurch ist sichergestellt, dass auch bei Ausfall des vCenters das Netzwerk kann nicht unterbrochen werden kann.
7.2.13 Erstellen einer dvPortGroup Auf einem distributed vSwitch gibt es wie bei den Standard-vSwitches auch Portgruppen. Diese müssen Sie jedoch immer selbst anlegen. Wechseln Sie dafür in die Networking-Ansicht, in der Sie zuvor auch den distributed vSwitch erstellt haben. Nach Auswahl des Switches wählen Sie rechts im Summary des Switches den Punkt Add new Port Group. Es startet ein Wizard, der Namen, Portanzahl und VLAN-Konfiguration für die Portgruppe abfragt. Sie müssen nicht definieren, ob diese Portgruppe für Service Console, VMkernel oder die Verbindung von virtuellen Maschinen dienen soll.
Abbildung 7.36
Erstellen einer neuen dvPortGroup
Beim VLAN-Typ können Sie zwischen vier Methoden auswählen: 1. None: Die neue Portgruppe wird nicht mit einem VLAN verbunden. 2. VLAN: Die Portgruppe wird mit einem speziellen VLAN verbunden; Sie müssen eine VLAN-ID angeben. 3. VLAN Trunking: Die Portgruppe soll mit mehr als einem VLAN verbunden werden. Sie können mehrere VLAN-IDs und Bereiche angeben. 4. Private VLAN: Die Portgruppe soll mit einem Private VLAN verbunden werden. Dafür müssen Sie zuvor auf dem dvSwitch die Konfiguration der Private VLANs abschließen. Private VLANs sind eine Erweiterung der bekannten VLANs und können kurzgefasst als VLANs innerhalb VLANs beschrieben werden. Daher entsteht vor allem für Provider oder Betreiber größerer Infrastrukturen eine Möglichkeit, weitere Verwaltung und Sicherheiten einzubauen.
344
Virtuelle Netzwerke
keine VLAN-Unterstützung
VLAN-1-Pakete werden angenommen und untagged an die VMs übergeben VLAN-Trunking ist erlaubt, d.h. mehrere VLAN-Tags werden angenommen
private VLAN-Nutzung
Abbildung 7.37
Einstellungen für Private VLANs
Einbinden von virtuellen Maschinen in dvPortGroups Um neue virtuelle Maschinen in die gewünschte Portgruppe einzubinden, wählen Sie beim Erstellen oder Ausrollen des Systems einfach das entsprechende Netzwerk aus. Gerade in größeren Umgebungen ist es daher sinnvoll, sprechende Namen für die Netzwerklabel und die Portgruppen zu vergeben.
Abbildung 7.38
Umstellung einer VM auf dvSwitch
345
7.2
7
Netzwerk
Erstellen von Service-Console- und VMkernel-Ports in dvPortGroups Neue Service-Console- oder VMkernel-Ports müssen Sie auf Host-Ebene erstellen. Wechseln Sie dafür in die Ansicht Hosts und Cluster. Wählen Sie den gewünschten Host, und gehen Sie in den Bereich Configuration. Klicken Sie unter Networking auf den Schalter distributed vSwitch.
Abbildung 7.39
Migration des VMkernel-Ports zu einer dvSwitch Portgruppe
Den Wizard zur Erstellung eines Service-Console- oder VMkernel-Ports rufen Sie über Manage existing virtual adapters auf. Mit Add erstellen Sie dann einen neuen Adapter. Dazu müssen Sie zwischen VMkernel- oder Service ConsoleTyp auswählen. Geben Sie anschließend die Port group an, über die der neue Port nach außen verbunden werden soll. Stellen Sie noch die IP ein, und fertig ist der neue Service-Console- oder VMkernel-Port auf dem distributed vSwitch.
Abbildung 7.40
346
Neuer dvSwitch mit VM-, Service-Console- und VMotion-Netzwerk
Virtuelle Netzwerke
Umzug bestehender VM-Netzwerke auf dvSwitches Nach dem erfolgreichen Abschließen des Wizards zur Erstellung eines dvSwitches können Sie bestehende VM-Netzwerke von den Standard-vSwitches auf den neuen dvSwitch migrieren.
Abbildung 7.41
Migration von VM-Netzwerken
Im Migration-Wizard wählen Sie dann Quell- und Zielnetzwerk aus. Das Quellnetzwerk wäre zum Beispiel eine Port-Group auf einem Standard-vSwitch mit dem Typ VM Network. Als Zielnetzwerk geben Sie die gewünschte dvPortGroup an. Über den Schalter Show Virtual Machines lassen Sie sich die virtuellen Maschinen im Quellnetzwerk anzeigen. Diese können Sie dann zum Teil oder komplett für die Migration auswählen. Das vCenter zieht nach Beendigung des Wizards eine Maschine nach der anderen auf den neuen dvSwitch um. Die Portgruppe des Quellnetzwerkes wird nicht automatisch gelöscht. Alle virtuellen Maschinen bleiben eingeschaltet und laufen auf dem gleichen Host-System weiter.
Abbildung 7.42
Migration von VM-Netzwerken
Umzug von Service-Console- und VMkernel-Netzen auf dvSwitches Ähnlich wie die VM-Netzwerke lassen sich auch Service Console und VMkernel auf dvSwitches umziehen. Da es sich dabei um host-basierte Netze handelt, müssen Sie in die Ansicht Host und Cluster wechseln. Nach Auswahl eines Hosts gehen Sie in den Bereich Configuration, klicken auf den Punkt Networking und Drücken den Schalter distributed vSwitch. Da es sich bei Service Console und VMkernel um virtuelle Netzwerkadapter handelt, rufen Sie Manage Virtual Adapters auf. Über den Punkt Add im neu geöffneten Fenster beginnen Sie die Migration eines bestehenden Adapters.
347
7.2
7
Netzwerk
Im nächsten Schritt werden die auf dem Host bestehenden Service Console und VMkernel-Netze aufgelistet. Hierbei handelt es sich um Portgruppen auf Basis von Standard-vSwitches. In der Spalte Port Group muss das Ziel Netzwerk, die Portgruppe auf dem dvSwitch ausgewählt werden.
Abbildung 7.43
Migration von Service Console und VMotion-Netzwerk
Es ist wichtig, dass die Portgruppe zuvor angelegt wurde und eine Verbindung besteht. Ansonsten kann die Migration der Service Console und des VMkernels zum Beispiel für die iSCSI- oder NFS-Anbindung schwere Folgen mit sich ziehen. Sofern auf der neuen dvPortGroup jedoch das richtige Netz bereitgestellt wird, kann die Migration im laufenden Betrieb erfolgen. Die einzige Empfehlung wäre, eine Migration nicht während Lastspitzen durchzuführen. Konfiguration und Einstellungen Die Einstellmöglichkeiten sind bei einem distributed vSwitch denen auf einem Standard-vSwitch sehr ähnlich. Einstellungen zum Teaming und Failover nehmen Sie auf der Ebene der Portgruppen vor. In der Ansicht Host und Cluster erkennen Sie im Configuration-Bereich der Netzwerke durch Auswahl einer virtuellen Maschine, Service-Console- oder VMkernel-Portgruppe anhand der gelb markierten Pfade, welche Uplinks aktiv genutzt werden.
Abbildung 7.44
348
Security- und Traffic Shaping-Einstellungen eines dvSwitch
Virtuelle Netzwerke
Traffic Shaping richten Sie ebenfalls in den Portgruppen ein, bei distributed Switches sogar für Sende- und Empfangsrichtung, während Standard-vSwitches nur die Senderichtung einschränken können.
Abbildung 7.45
Sperren aller dvSwitch-Ports auf Knopfdruck durch Konfiguration auf Yes
Der Bereich Security bietet die gleichen Einstellungen wie bei den StandardvSwitches, allerdings unterstützt ein dvSwitch Private VLANs, und Sie können einzelne Ports einsehen und auch blocken. Vor allem das Blocken der Ports kann im Falle eines Wurmbefalls sehr schnelle Hilfe bieten, da die VMs sofort ohne Netzwerkkommunikation sind. Der Hauptunterschied ist, dass die meisten Einstellungen auf der Ebene der Portgruppen erfolgen. Zudem sieht die Ansicht für die Optionen etwas anders aus. Neu sind die Einstellungen für das Port-Binding. Hiermit legen Sie fest, ob Sie der virtuellen Maschine einen festen Port auf dem Switch zuweisen. Außerdem bestimmen Sie, wann diese Zuweisung erfolgt, z. B. wenn die Maschine mit einer Portgruppe verbunden wird oder sobald die Maschine zum ersten Mal an dem Switch eingeschaltet wird. Als dritte Option können Sie bestimmen, dass keine feste Bindung erfolgt – die Maschine kann also die Ports wechseln. Cisco Discovery Protocol Sie können einstellen, ob im vCenter die Informationen der externen Switches angezeigt werden sollen (listen mode). Sie können die externen Switches festlegen, die Informationen von den vSwitches erhalten sollen (advertise mode); oder dass sowohl im vCenter die Informationen angezeigt als auch noch ausgegeben werden (both mode). Eine generelle Abschaltung ist auch möglich. Standardmäßig ist das CDP auf den Listen Mode eingestellt. Sofern die Daten nach außen gesendet werden sollen, ist es sinnvoll, die E-Mail-Adresse des VMware-Administrators oder der -Administratorengruppe einzutragen.
7.2.14 Private VLANs Private VLANs (PVLANs) sind eine Erweiterung durch vSphere und deren distributed vSwitches. Sie geben den Netzwerkabteilungen neue Möglichkeiten der
349
7.2
7
Netzwerk
Trennung von Systemen im Netzwerk geben. Im Grunde ist PVLAN ein Mechanismus zur Trennung einer physischen Broadcast-Domäne in logische BroadcastDomänen auf einem Switch. Secondary PVLAN 11 (Community) A
B
Secondary PVLAN 21 (Isolated) C
Secondary PVLAN 114 (Promiscuous) D
E
F
Distributed Switch
Primary PVLAN 114
Abbildung 7.46
Schematische Darstellung der Private-VLAN-Konfiguration
Dabei weisen PVLANs folgende Unterschiede zu Standard-VLANs auf: 왘
Erweiterung des VLAN-Standards durch erneute Trennung der VLAN-Broadcast-Domänen in weitere Broadcast-Domänen
왘
Unterstützung durch viele moderne physische Ethernet-Switches
왘
VLAN = Primary PVLAN; Untergruppen = Secondary PVLANs; Secondary PVLANs existieren nur im Primary PVLAN.
왘
»Private« bedeutet, dass Systeme je nach Typ der Port-Group nicht miteinander kommunizieren können, sogar wenn sie zur gleichen Gruppe gehören.
왘
Secondary PVLANs besitzen ebenfalls VLAN-Ids, und der physische Switch passt sein Verhalten je nach Type an (Isolated, Community oder Promiscuous).
Der Typen der PVLANs – Community, Isolated und Promiscuous – stehen für die Erhöhung der Sicherheit in virtuellen Umgebungen und bieten sich besonders für DMZ-Umgebungen an, da beispielsweise Isolated-Systeme nicht miteinander oder mit Community-Systemen kommunizieren können.
350
Virtuelle Netzwerke
Abbildung 7.47
Konfiguration der verschiedenen PVLAN-Eigenschaften
7.2.15 Vorteile von distributed vSwitches Es ist möglich, alle Standard-vSwitches durch dvSwitches abzulösen, allerdings können Sie beide Switch-Typen auch problemlos miteinander mischen. Aber welchen Vorteil haben Sie dadurch? Vor allem bei den Netzwerken für die virtuellen Maschinen müssen Sie nicht mehr auf jedem Host immer wieder dieselbe Portgruppe anlegen. Häufig kommt es dabei auch zu Tippfehlern, die zu negativen Erlebnissen bei VMotion- und DRS-Aktivitäten führen. Neue Hosts können Sie einfach an bestehende dvSwitches anhängen und haben so direkt alle Netzwerke mit den entsprechenden Einstellungen parat. In Kombination mit den Host-Profiles lassen sich auch die Service-Console- und VMkernel-Netze schnell und immer gleich auf dem Host anlegen. Dies ist wieder sehr interessant für den Fall, dass ein Host neu aufgesetzt oder ausgerollt wird. Im täglichen Betrieb ist es sehr angenehm, dass Netzwerkstatistiken einer virtuellen Maschine bei einem VMotion-Vorgang mit auf den neuen Host übernommen werden. Über die Ansicht Netzwerke und Auswahl des dvSwitches können Sie im Register Ports eine Vielzahl an Statistiken zu den Uplinks und virtuellen Maschinen auslesen. Virtuelle Maschinen ziehen Sie per Migration-Wizard von einer bestehenden Portgruppe in eine neue um. So können Sie ein oder mehrere virtuelle Maschinen z. B. von einem Testnetzwerk in ein Produktiv-LAN migrieren.
351
7.2
7
Netzwerk
Teaming-Einstellungen erfolgen in den Portgruppen der dvSwitches und gelten für alle Hosts. Dabei ist es egal, ob es sich um ein VM-Netzwerk, ein Service-Console- oder ein VMkernel-Netz handelt. In den Portgruppen-Einstellungen können Sie definieren, welche Uplink-Portgruppe active, Standby oder unused ist. So müssen Sie auch dies nicht mehr auf jedem Host einzeln durchführen. Sehr hilfreich ist dafür, die Uplink-Portgruppen entsprechend umzubenennen, z. B. in »Uplink_1-vmnic0«. Darin zu finden wären dann alle vmnic0-Adapter der angeschlossenen Hosts. Allerdings tauchen leider immer noch kleinere Probleme bei der Nutzung von dvSwitches auf: So kann der Import-Wizard (Deploy OVF) oft nur auf StandardvSwitches prüfen, und Tools wie vShield Zones müssen manuell installiert werden, da derzeit kein Automatismus für dvSwitches existiert. Daher empfiehlt es sich, aus Kompatibilitätsgründen immer einen Standard-vSwitch beizubehalten. Da dvSwitches erst ab der höchsten Edition (Enterprise Plus) verfügbar sind, müssen Sie natürlich auch finanziell prüfen, ob die Vorteile die Kosten rechtfertigen.
7.2.16 Cisco Nexus Der Cisco Nexus 1000v ist die erste Third-Party-Implementierung eines distributed Switches. Bereits im Sommer 2009 bot Cisco den Nexus 1000v an. In diesem Bereich möchten wir vor allem die Bereitstellung des Cisco Nexus 1000v erläutern. In vielen Umgebungen wird ab der Bereitstellung des Cisco Nexus die Einrichtung des dvSwitches in die Verantwortung der Netzwerkadministration fallen. Administratoren können sich zum Beispiel für die Einrichtung über SSH auf dem Nexus Supervisor-Modul einloggen. Das Supervisor-Modul, oder in der virtuellen Welt kurz VSM (Virtual Supervisor-Modul), ist eine virtuelle Appliance, die fertig installiert von Cisco bereitgestellt wird. Im VSM ist ein Cisco-IOS installiert, über Sie Portgruppen einrichten und administrieren. Zum StandardIOS sind natürlich einige spezielle Kommandos hinzugekommen, um zum Beispiel die Verbindung zwischen vCenter und VSM zu konfigurieren. Eine weitere entscheidende Komponente bei der Bereitstellung des Nexus ist das VEM (Virtual Ethernet Module). Dieses müssen Sie als Updatepaket auf den ESXServern installieren. Dadurch wird der host-basierte versteckte vSwitch für den Cisco Nexus bereitgestellt. Über den Befehl vem status können Sie jederzeit in der Service Console prüfen, ob das Modul bereits installiert ist.
352
Virtuelle Netzwerke
Abbildung 7.48
Übersicht Cisco-Nexus-Lösung
Importieren der VSM-Appliance Für die Installation des Nexus laden sie von Cisco die VSM-Appliance herunter. Alternativ erstellen Sie eine virtuelle Maschine und installieren sie mit der entsprechenden Software. Es empfiehlt sich aber der Weg über die bereits fertig installierte Appliance; das spart Zeit und Aufwand. Zudem ist Appliance auch gleich mit den notwendigen Ressourcen konfiguriert. 1 vCPU, 2 GByte RAM, 3 GByte Festplattenplatz und drei virtuelle E1000-Netzwerkadapter sind die Anforderung. In der Appliance sind 1.500 MHz und 2 GByte in den Ressourceneinstellungen der virtuellen Maschine garantiert. Unter http://www.cisco.com/go/ nexus1000v finden Sie die VSM-Appliance zum Download.
Abbildung 7.49
Import der VSM-Appliance – Appliance-Übersicht
353
7.2
7
Netzwerk
Nach dem Herunterladen importieren Sie sie in das vCenter. Über File 폷 Deploy OVF Template erfolgt ein Import über eine Datei. Wählen Sie dazu die .ovf-Datei der zuvor heruntergeladenen Appliance aus. Mit Hilfe des Import-Wizards legen Sie den Cluster oder ESX-Host fest, auf dem die Appliance später ausgeführt werden soll. Als vorletzter Punkt vor dem eigentlichen Import müssen drei Netze ausgewählt werden: 왘
Control LAN: Stellt eine Verbindung zwischen VSMs und VEMs zur Überwachung bereit.
왘
Packet LAN: Dieses Netzwerk dient zur Übertragung der Netzwerkpakete zwischen VSM-Appliance und VEMs
왘
Management LAN: Für die SSH- oder Telnet-Verbindung zum VSM. Über dieses Netzwerk können Sie den Nexus administrieren und konfigurieren.
Alle drei Netze können Sie bei der Einrichtung des VSM auch mit Hilfe von VLANs trennen. Für die Anbindung dieser Netze muss ein Standard-vSwitch auf dem Cluster oder Host bestehen. Sofern dies der Fall ist, können Sie aber trotzdem dvPortGroups auf dvSwitches auswählen. Es ist im ersten Moment etwas verwirrend, dass für die Einrichtung eines Netzwerk-Switches ein bestehender Switch benötigt wird. Erklären könnte sich dies aber dadurch, dass der Nexus ausschließlich über das VSM administriert werden kann. Sofern der VMwareAdministrator die Aufgabe hat, den Cisco Nexus für die Netzwerkadministration bereitzustellen, muss er sich so nicht mit dem Cisco-IOS auseinandersetzen. Konfiguration Supervisor-Module Im nächsten Schritt muss die VSM-Appliance eingeschaltet werden. Über die Konsole der virtuellen Maschine nehmen Sie dann die Einrichtung vor: 왘
Vergabe des admin-Passwortes
왘
Einrichtung Switch-Domain-ID
왘
Switch-Rolle (Standalone/Primary/Secondary)
왘
SNMP-Einstellungen
왘
Switch-Name
왘
IP-Adresse, Subnet-Mask und Default-Gateway
왘
Telnet- und SSH-Einstellungen
왘
VLAN-Einstellungen für Control- und Packet-LAN
Sie können bis zu zwei VSMs für einen Cisco Nexus einrichten, dann müssen Sie das erste VSM als primär und das zweite als sekundär konfigurieren. Sofern Sie nur ein VSM verwenden möchten, wählen Sie die Rolle Standalone aus. Jedoch wird die Verfügbarkeit durch zwei VSMs wesentlich erhöht.
354
1450.book Seite 355 Freitag, 5. Februar 2010 12:11 12
Virtuelle Netzwerke
Abbildung 7.50
VSM-Appliance – Vergabe admin-Passwort
Hinzufügen des Cisco-Nexus-Plug-ins Nachdem das VSM eingerichtet ist, müssen Sie im vCenter ein Plug-in für den Nexus installieren. Dafür laden Sie von der Weboberfläche des VSM die Datei cisco_nexus_1000v_ extension.xml herunter.
Abbildung 7.51
VSM-Appliance – Weboberfläche
Integrieren Sie das Plug-in dann im vCenter über Plug-ins 폷 Manage Plug-ins. Klicken Sie dazu einfach in einem freien Bereich mit der rechten Maustaste, und wählen Sie den Punkt New Plug-in aus. Es öffnet sich ein neues Fenster. Rufen Sie über den Browse-Button das zuvor heruntergeladene .xml-File auf. Durch Auswahl Register Plug-in ignorieren Sie eine Zertifikatswarnung. Sie müssen nicht auf view klicken, und eine dadurch mögliche Installation des Zertifikates ist auch nicht notwendig. Im Plug-in Manager wird nun das Cisco-Nexus-1000vPlug-in angezeigt. Es macht den Anschein, als ob es nun herunterladen und
355
7.2
7
Netzwerk
installieren müsse. Dies ist aber auf keinen Fall notwendig; durch Registrierung des Plug-ins ist dieser Teil bereits erledigt. Das vCenter hat über das Zertifikat die Information über das VSM erhalten. Verbindung des VSM mit dem vCenter Damit das VSM nun den Cisco Nexus in das vCenter einbindet, müssen Sie noch die Verbindung vom VSM zum vCenter aufbauen. Wechseln Sie dafür auf die Konsole des Cisco Nexus. Alternativ arbeiten Sie über eine SSH-Verbindung mit dem Nexus. Der Reihe nach sind folgende Kommandos abzusetzen: config svs connection vc protocol vmware-vim remote ip address vmware dvs datacenter-name connect
Sofern Sie zuvor alles richtig vorbereitet haben, sollte nach dem connect-Befehl keine Konsolenausgabe erfolgen. Bei Schwierigkeiten wird in der Regel eine Fehlermeldung gefolgt von der vCenter-Version und dem Build-Stand ausgegeben. Dies kommt zum Beispiel vor, falls das Plug-in im vCenter nicht richtig installiert wurde. Wechseln Sie nun in die Ansicht der Netzwerke, sehen Sie bereits den Cisco Nexus 1000v. Auf den ersten Blick sieht er aus wie ein Standard-distributedvSwitch. Über die Summary-Page des vSwitches erkennen Sie aber, dass es sich um einen Nexus handelt. Hosts zum Nexus hinzufügen – Installation VEM Wählen Sie man den Punkt Host hinzufügen aus, um ESX-Hosts mit freien Uplinks zum Nexus hinzuzufügen. Für diesen Prozess muss der Update Manager installiert sein, der im Hintergrund dann das VEM-Paket auf dem jeweiligen Host installiert. Für eine proaktive Verteilung des VEM können Sie im Update Manager eine Baseline einrichten. Die Baseline muss vom Typ Fixed sein, um das Repository nach Patches vom Hersteller Cisco filtern zu können. Beim Hinzufügen eines Hosts zum dvSwitch können Probleme auftreten. Mögliche Gründe dafür sind: 왘
Der Update Manager kann nicht mit dem VSM kommunizieren.
왘
Der Update Manager ist nicht mit dem Internet verbunden oder über einen Proxy angebunden.
356
Virtuelle Netzwerke
왘
Der ESX-Host hat einen gepatchten Build-Stand, den das VEM nicht unterstützt.
왘
Die VEM-Version im Patch-Repository ist veraltet.
Eine einfache Lösung des Problems ist die manuelle Installation des VEM. Leider ist dies gerade für große Umgebungen sehr zeitaufwendig, kann aber mit Hilfe eines Skripts automatisiert werden. Für die manuelle Installation wird das Installationspaket benötigt, das Sie entweder von VMware oder von der Weboberfläche des VSM herunterladen. Das Paket heißt zum Beispiel cross_cisco-vem-100v-4.0.4.1.1.27-0.4.2-release.vib. Dieses kopieren Sie am einfachsten auf einen zentralen Datastore und installieren es dann in jedem ESX-Host, den Sie mit dem Nexus verbinden wollen. Die Installation erfolgt über das Kommando esxupdate –b update. Zum Abschluss müssen Sie dann noch jeden entsprechenden ESX-Host zum Cisco Nexus hinzufügen. In manchen Fällen hilft es auch, einfach im Update Manager eine weitere PatchQuelle hinzuzufügen. Diese sollte auf die index.html des VSM verweisen. Dadurch kann der Update Manager das VEM vom VSM importieren und verteilen.
7.2.17 Netzwerkadapter der VMs Auf der Ebene der virtuellen Maschinen sind die virtuellen Netzwerkadapter eine weitere zu betrachtende Komponente. Die Netzwerkadapter verbinden die virtuellen Maschinen mit einem Standard- oder distributed vSwitch. Aktuell gibt es sechs unterschiedliche Netzwerkadapter für virtuelle Maschinen. Die Auswahl des Adaptertyps erfolgt zum Beispiel bei der Erstellung einer virtuellen Maschine.
Abbildung 7.52
Erstellung einer neuen virtuellen Maschine – Auswahl des Netzwerkadapters
Der Wizard zur Erstellung einer neuen virtuellen Maschine schlägt immer den empfohlenen Adapter auf Basis des zuvor gewählten Gastbetriebssystems aus.
357
7.2
7
Netzwerk
Vlance-Adapter Der Vlance-Adapter ist eine Portierung der AMD-PCnet32-Netzwerkkarte aus der physischen Welt. Daher wird auch häufig vom »PCnet32« und nicht vom »Vlance-Adapter« gesprochen. Der Vorteil dieses Adapters: Die meisten 32-BitGastbetriebssysteme liefern bereits einen Treiber im Installationspaket mit. Nachteile sind sicher die Performance und die wenigen verfügbaren Funktionen des Adapters. vmxnet-Adapter Beim vmxnet-Adapter handelt es sich um einen reinen virtuellen Adapter. Zudem ist der er ein paravirtualisierter Netzwerkadapter. Der vmxnet-Adapter ist nicht auf Basis einer physisch bereits vorhandenen Netzwerkkarte entstanden. Gegenüber dem Vlance- bietet der vmxnet-Adapter eine bessere Performance. Treiber für die Unterstützung dieses Adapters sind aber nicht in den Gastbetriebssystemen enthalten. Sie werden durch die Installation der VMware Tools bereitgestellt. Flexibler Adapter Die Kombination aus dem Vlance- und dem vmxnet-Adapter ist der flexible Adapter. Dieser Adapter war auch die Default-Einstellung für virtuelle 32-BitMaschinen in Kombination mit der Version VMware ESX 3.x. Der Adapter stellt sich als AMD PCnet32 dar und kann mit den im Gastbetriebssystem enthaltenen Standardtreibern arbeiten. Nach der Installation der VMware Tools wird der vmxnet-Treiber verwendet. Der Adapter stellt sich aber weiterhin als AMD PCnet32 dar, verwendet jedoch den vmxnet-Treiber. Unter Windows ist dies im Gerätemanager der virtuellen Maschine zu sehen. In der Geräteliste wird der AMD PCnet32 aufgeführt, in den Details des Gerätes wird der geladene Treiber vmxnet.sys angezeigt. Vorteile dieses Adaptertyps: einfacher Einsatz durch verfügbare Treiber im Gastbetriebssystem und die Performance des vmxnet-Adapters. Ein Nachteil ist sicher, dass die bessere Performance nur in Verbindung mit dem vmxnet-Treiber der VMware Tools gegeben ist. Zu bemängeln ist auch, dass der tatsächlich geladene Treiber nur in den Detailinformationen des Adapters ersichtlich ist.
358
Virtuelle Netzwerke
Intel-e1000-Adapter Wie auch beim Vlance-Adapter handelt es sich beim Intel e1000 um eine Portierung eines physischen Adapters, in diesem Fall, wie der Name es bereits verrät, von Intel. Eingeführt wurde der Adapter für 64-Bit-Gäste, er wird aber unter anderem auch für Windows Vista 32 Bit als Default-Adapter verwendet. Aus Performance-Sicht ist dieser Adapter zwischen dem Vlance- und dem vmxnet-Adapter einzustufen. Vor- und Nachteil sind demnach gute Implementierung im Gast gegen eine nicht ganz optimale Performance. vmxnet2-Adapter (enhanced) Der vmxnet2-Adapter ist eine Weiterentwicklung des vmxnet-Adapters, die Jumbo-Frames und TSO (TCP Segmentation Offload) unterstützt. Verfügbar wurde der Adapter mit VMware ESX 3.5. Ein Nachteil dieses Adapters ist, dass er nicht von allen Gastbetriebssystemen unterstützt wird. Der Vorteil ist aber die bessere Performance gegenüber dem vmxnet-Adapter in der ersten Version. vmxnet3-Adapter Die dritte Version des vmxnet-Adapters wurde mit vSphere 4.0 verfügbar. Dieser Adapter unterstützt folgende weitere Funktionen gegenüber der zweiten Generation: 왘
MSI/MSI-X
왘
Receive Side Scaling
왘
IPv6-Checksum und TSO über IPv6
왘
VLAN-Offloading
왘
große TX/RX-Ring-Größen
Für den Einsatz des vmxnet3-Adapters ist es wichtig, dass die virtuellen Maschinen auf dem Hardwarestand Generation 7 sind. Bei virtuellen Maschinen, die bei einem Upgrade übernommen werden, wird gerne die Aktualisierung der virtuellen Hardware aufgeschoben und dann vergessen. Auswahl des virtuellen Netzwerkadapters Sicher das erste Entscheidungskriterium ist das Gastbetriebssystem. 32- oder 64Bit-Variante? Eher neuere oder ältere Version? So können Sie z. B. einen Vlanceoder flexibler Adapter nicht unter 64-Bit-Betriebssystemen Varianten einsetzen. Die vmxnet-Adapter empfehlen sich vor allem durch benötigte Funktionen wie Jumbo-Frames – dann mindestens der vmxnet2 – oder IPv6-Unterstützung, wofür Sie mindestens den vmxnet3-Adapter benötigen. VMware selbst empfiehlt
359
7.2
7
Netzwerk
den Einsatz des Adaptertyps, der bei der Erstellung der virtuellen Maschinen unter Angabe des Gastbetriebssystems automatisch ausgewählt wurde. Eine weitere Quelle mit einer Auflistung der unterstützten Gastbetriebssysteme ist der VMware-Knowledge-Base-Artikel 1001805 »Choosing a network adapter for your virtual machine«: http://kb.vmware.com/kb/1001805.
7.2.18 VMdirectPath-I/O Mit Hilfe von VMdirectPath-I/O können Sie bis zu zwei neuere Netzwerk- oder experimentell Storage-Controller in die virtuelle Maschine durchreichen. Dafür muss jedoch der gesamte Adapter exklusiv für die virtuelle Maschine zur Verfügung stehen. Ein Verschieben des Systems mit Hilfe von VMotion ist dann nicht mehr möglich. Für die Einrichtung konfigurieren Sie zunächst auf dem ESX-Host im Bereich Configuration den gewünschten Adapter über die erweiterten Einstellungen für VMdirectPath-I/O. Im Anschluss dazu ist ein Neustart des ESX-Host notwendig. Eine wichtige Voraussetzung ist die Host-Hardware. Neben den Controllern muss auch die CPU diese Funktion unterstützen. Das bedeutet: Die CPU muss mindestens eine Intel XEON 5500 mit VT-D-Technologie sein. Adapterseitig werden aktuell 10-Gigabit-Netzwerkkarten von Intel und Broadcom unterstützt. Speicheradapter werden nur experimentell von Emulex, QLogic und LSI angeboten. Der Einsatzzweck für diese Funktion ist im Netzwerkumfeld sicherlich sehr fraglich, vor allem unter dem Aspekt, dass kein VMotion mehr möglich ist. Zudem werden nur 10-Gigabit-Ethernet-Adapter unterstützt; diese müssen überhaupt erst einmal in einem Server vorhanden sein. Falls die Voraussetzungen gegeben sind, muss erst einmal eine virtuelle Maschine den Bedarf für einen exklusiven 10 Gigabit Port stellen. Im folgenden Knowledge-Base-Eintrag finden Sie detailliertere Informationen: http://kb.vmware.com/kb/1010789.
7.2.19 MAC-Adressen Eine MAC-Adresse ist eine eindeutige ID eines Netzwerkgeräts. Diese IDs sind fest zum Beispiel in Netzwerk-Controllern eingebrannt und dienen zur Identifizierung von Geräten im Netzwerk.
360
Virtuelle Netzwerke
Aufbau einer MAC-Adresse Eine MAC-Adresse besteht aus 48 Bit. In der Regel werden MAC-Adressen im hexadezimalen Format wie zum Beispiel 00:07:E9:73:05:6f oder 00-07-E9-73-056f angegeben. Die ersten 24 Bit einer MAC-Adresse bilden die Hersteller-ID. In diesem Beispiel ist das der Bereich 00:07:E9, nämlich die ID für Intel-Geräte. Mit Hilfe des zweiten Teils der MAC-Adresse wird das Gerät eindeutig identifizierbar. Die MACAdresse ist also einmalig. MAC-Adressen bei virtuellen Maschinen Virtuelle Maschinen kommunizieren wie physische Systeme im Netzwerk und benötigen daher auch MAC-Adressen. Natürlich muss auch eine MAC-Adresse einer virtuellen Maschine eindeutig sein. Daher hat auch VMware eine eigene Hersteller-ID (00:0C:29 und 00:50:56) und generiert auf Basis der UUID und des Pfads zur Konfigurationsdatei eine eindeutige MAC-Adresse. Es ist aber möglich, im Bereich von 00:50:56:00:00:00 bis 00:50:56:3F:FF:FF selbst eine MAC-Adresse zu vergeben. Gehen Sie dazu in die Einstellungen der virtuellen Maschine, wählen Sie den Netzwerkadapter aus, und setzen Sie rechts die MAC-Adresse manuell.
Abbildung 7.53
Einstellungen einer virtuellen Maschine – Setzen MAC-Adresse
Natürlich können Sie eine MAC-Adresse auch in der Konfigurationsdatei der virtuellen Maschine vergeben. Aber hier muss die MAC-Adresse ebenfalls dem oben genannten Bereich entsprechen. Wann muss eine MAC-Adresse manuell gesetzt werden? Generell wird die MAC-Adresse automatisch bei der Erstellung einer virtuellen Maschine oder beim Hinzufügen eines neuen Netzwerkadapters generiert. Wirklich notwendig ist eine manuelle MAC-Adresse meist bei der Konvertierung einer
361
7.2
7
Netzwerk
physischen Maschine in eine virtuelle, sofern eine Software auf Basis einer MACAdresse lizenziert wurde. Ein Ummelden der MAC-Adressen ist in diesem Fall sehr aufwendige Bürokratie und meist sogar mit hohen Kosten verbunden. Leider führt um das Ummelden aber kein Weg herum, jedoch können Sie so bereits vor der eigentlichen Virtualisierung eine MAC-Adresse definieren. Sofern der Ummeldeprozess sehr lange dauert, können Sie ihn vor Beginn des Konvertierens anstoßen.
7.2.20 Nachträgliche Änderungen und Einstellungen an einem Standard-vSwitch Ein Hinzufügen oder Entfernen von Netzwerkports ist im laufenden Betrieb möglich. Vor dem Entfernen eines Netzwerkports von einem vSwitch sollten Sie aber sicherstellen, dass noch ein weiterer Port am vSwitch verfügbar ist und dass dieser eventuell noch einzige Port in allen Portgruppen als aktiv konfiguriert ist und definitiv nicht als nicht zu verwendender Port. Ansonsten werden eventuell Verbindungen getrennt. Eine Erhöhung der vSwitch-Ports ist nur nach Neustart eines ESX-Hosts wirksam. Reichen die Ports eines vSwitches nicht mehr, müssen Sie in der Planung der Erweiterung des vSwitches einen Neustart bedenken.
7.2.21
Nachträgliche Änderungen und Einstellungen an einer Port-Group
Das Ändern eines Netzwerklabels, während Maschinen mit diesem Netz verbunden sind, bedeutet den sofortigen Verbindungsverlust! Das passiert, weil virtuelle Maschinen sich immer auf den Namen des Netzwerks berufen und nicht auf eine ID. Sollte es einmal versehentlich zu einer Umbenennung kommen: Alle virtuellen Maschinen sind sofort wieder mit dem Netz verbunden, sobald Sie die Namensänderung zurücksetzen oder eine neue Portgruppe mit dem alten Namen erstellen. Dies gilt sowohl für Portgruppen auf Standard- als auch auf distributed vSwitches. Sofern Netzwerklabel umbenannt werden sollen, empfiehlt es sich, eine neue Portgruppe mit dem gewünschten Namen und den gewünschten Einstellungen zu erstellen. Anschließend müssen Sie die virtuellen Maschinen von der alten auf die neue Portgruppe migrieren! Ein Umzug ist allerdings nur möglich, sofern die neue Portgruppe auf einem distributed vSwitch liegt.
362
Architektur-Beispiele
7.3
Architektur-Beispiele
7.3.1
Empfehlungen und Best Practice
Für die Umsetzung von Netzwerkkonzepten in der Praxis gibt es einige Empfehlungen und Anmerkungen. Diese sollen helfen, eine hohe Verfügbarkeit sowie ausreichende Performance und Sicherheit zu gewährleisten. Da die Anforderungen und Gegebenheiten aber sehr unterschiedlich sein können, ist es sehr schwer, einen goldenen Regelsatz zu entwerfen. Die folgenden Empfehlungen und Anmerkungen sind also immer für die eigene Umgebung entsprechend einzuschätzen und eventuell auch anzupassen. Verwaltungsnetz – Service Console Für die Verbindung der Service Console sind vor allem Verfügbarkeit und Sicherheit entscheidend. Die Performance im Verhältnis zu Netzen für die Storageoder VM-Anbindung spielt eher eine geringere Rolle. Im Schnitt hat die Service Console eine Auslastung von ca. 100 Mbit/s. Dabei ist zu bedenken, dass dieser Durchschnitt sich aus sehr hohen Lastspitzen, aber auch längeren Zeitfenstern mit geringer Last errechnet. Eine Kombination mit anderen Netzen, zum Beispiel VMkernel, ist zu überlegen, aber generell nicht abzulehnen. Aus Sicherheitsgründen sollte die Service Console in einem separaten Verwaltungsnetzwerk eingebunden sein. Das kann bedeuten: physische Trennung oder mit Segmentierung mit Hilfe von VLANs. Letztere Lösung bietet dabei eine viel höhere Flexibilität im Design. Es sollte sichergestellt sein, dass die Service Console vom vCenter und den anderen ESX-Hosts im Cluster erreichbar ist. Der Zugriff sollte aber nur möglich sein für Administratoren oder von Systemen aus, die den direkten Zugriff auch wirklich benötigen. Die Verfügbarkeit der Service Console ist vor allem beim Einsatz eines VMwareHA-Clusters wichtig. Sofern die Service Console eines ESX-Hosts nicht von den anderen Hosts erreicht werden kann, wird von einer Isolation oder gar einem Ausfall ausgegangen. Daher sollten Sie beim Design überlegen, ob bei Ausfall eines Netzwerkports im Server oder bei Ausfall eines Switches die Verfügbarkeit gegeben ist. Sofern das vCenter die Service Console eines ESX-Hosts nicht mehr erreicht, wird der Server als »disconnected« angezeigt. Die Verfügbarkeit der virtuellen Maschinen muss damit aber nicht direkt in Bezug stehen. Die Service Console sollten Sie also immer in einem möglichst kleinen, abgeschlossenen Verwaltungsnetzwerk einbinden. Eine Verfügbarkeit muss auch bei
363
7.3
7
Netzwerk
Ausfall eines Netzwerkadapters oder Switches gegeben sein. Eine Gigabit-Verbindung ist aus Sicht der Performance definitiv ausreichend. NFS-Netz – VMkernel Für die Anbindung eines NFS-Datastores ist sicher das größte Thema die Performance gefolgt von der Verfügbarkeit und Sicherheit. Sofern die Verbindung zum NFS-Datastore nicht den Durchsatz ermöglicht, den die virtuellen Maschinen zum Lesen und Schreiben auf ihren virtuellen Disks benötigen, sind direkt mehrere Systeme betroffen. In vielen Umgebungen reicht daher eine einfache Gigabit-Verbindung nicht aus. Es müssen mehrere Netzwerkports im ESX aktiv verwendet werden. Das bedeutet: Abhängig von den externen Switches müssen Sie ein Teaming mit entsprechender Paketverteilung einrichten. Sinnvoll ist es, auch eine Skalierbarkeit nach oben einzuplanen. Dies gewährleisten Sie durch freibleibende Netzwerkports im Server oder Switch. Im Server lässt sich natürlich auch nachträglich ein freier Slot mit einem zusätzlichen Netzwerkadapter bestücken. VMotion ermöglicht dies zudem, ohne die Verfügbarkeit der virtuellen Maschinen zu beeinflussen. Durch das Zusammenfassen von Ports erreichen Sie auch gleich eine ausreichende Verfügbarkeit der Netzwerkports. Achten Sie jedoch darauf, Ports auf unterschiedlichen Adaptern zu kombinieren, sonst würde der Ausfall einer einzelnen Karte eine Trennung der Netze bedeuten. Sofern die externen Switches keinen Etherchannel über mehrere getrennte Systeme unterstützen, müssen Sie zusätzlich mit mindestens einem Standby-Port arbeiten. Für ausreichend Sicherheit können Sie den NFS-Export nur für bestimmte Server freigeben. Zudem ist der Einsatz von VLANs wieder eine gute Trennung des NFSNetzes von zum Beispiel dem Verwaltungsnetzwerk. Natürlich können Sie auch auf physischer Ebene trennen, der Einsatz separater Switches und Leitungen ist aber immer mit Kosten verbunden, nicht nur wegen des erhöhten Hardwarebedarfs, sondern auch aufgrund des Verwaltungsaufwandes. Für ein NFS-Netz sollten Sie demnach von Beginn an für eine gute Bandbreite mit Erweiterungsmöglichkeit sorgen. Die Verfügbarkeit gewährleisten Sie dadurch direkt mit, Sie müssen Sie aber unbedingt überprüfen. Da ein Storage-Netz meist separiert ist, gleich ob physisch oder per VLAN, können Sie dadurch eine grundlegende Sicherheit schaffen. Optional erweitern Sie dies noch auf dem StorageSystem durch gezielte Freigaben.
364
Architektur-Beispiele
iSCSI-Netz – VMkernel Für ein iSCSI-Netz gilt ziemlich das Gleiche in Bezug auf Performance, Verfügbarkeit und Sicherheit. Ein wesentlicher Unterschied: Sie können nicht nur Ports durch ein Teaming zusammenpassen, sondern auch Multipathing einsetzen. Erstellen Sie zum Beispiel zwei VMkernel-Ports für die iSCSI-Anbindung in unterschiedlichen Netzen auf dem ESX und Storage-System, können Sie die Last mit Hilfe von Multipathing wie bei einer Fibre-Channel-Anbindung verteilen. Die iSCSI-LUN wird einmal über das erste VMkernel-Netz in Netz A erkannt, ein weiteres Mal über den zweiten VMkernel-Port in Netz B. Dadurch können Sie zum Beispiel auf Etherchannels komplett verzichten. Selbst bei zwei getrennten physischen Switches, die keine systemübergreifenden Etherchannels unterstützen, erreichen Sie so aktiv über beide Switches mit Hilfe des Round-Robin-Verfahrens eine Lastverteilung. Seit vSphere ist es übrigens nicht mehr notwendig, für eine iSCSI-Verbindung zu einem Datastore sowohl ein VMkernel- als auch ein Service-Console-Interface im Storage-Netzwerk zu haben. Für die Anbindung von iSCSI- und NFS-Datastores auf einem NetApp-System empfiehlt sich ein Blick in den Technical Report 3749; dieser enthält eine Menge Tipps und Tricks für die Optimierung des Storage-Netzwerkes: http:// media.netapp.com/documents/tr-3749.pdf. Für iSCSI-Netze muss eine gute Performance und Verfügbarkeit gewährleistet werden! Eine Erhöhung der Sicherheit erreichen Sie durch Separieren des Netzes und gezielte Zugriffssteuerung auf dem Storage-System. Der wesentliche Unterschied zum NFS-Netz ist: Sie haben mehr Möglichkeiten beim Zusammenfassen von Ports durch Multipathing-Technologie. VMotion-Netzwerk – VMkernel Bei VMotion-Netzwerken gilt als Erstes immer noch die Empfehlung: ein dediziertes Gigabit-Netzwerk. Fällt ein VMotion-Netz einmal aus, bedeutet das nicht einen direkten Ausfall der virtuellen Maschinen. Es nimmt Ihnen aber die Flexibilität, virtuelle Maschinen zu verschieben, um zum Beispiel eine defekte Netzwerkkarte auszutauschen. Die Last auf einem VMotion-Netz ist vor allem hoch, wenn Sie viele virtuelle Maschinen verschieben müssen, zum Beispiel während eines Patch-Vorganges mit Hilfe des Update Managers. Wie bei der Service Console gibt es also Spitzenzeiten mit hohen Anforderungen und Phasen, in denen kaum Last erzeugt wird.
365
7.3
7
Netzwerk
Eine gute Konfiguration für ein VMotion-Netzwerk wären dedizierte Ports pro ESX-Server, die vielleicht auf einen dedizierten unmanaged Switch zusammengeführt werden. Dieses wäre eine Möglichkeit, nicht zu kostenintensiv ein dediziertes physisches Netz aufzubauen. Natürlich erreichen Sie eine Trennung auch über VLANs, um nicht in einen zusätzlichen Switch investieren zu müssen. Ein Ausbau auf mehrere Ports pro ESX oder gar 10-Gigabit-Ethernet beschleunigt den VMotion-Prozess erheblich! Die Verfügbarkeit wird durch einen weiteren Port erhöht, ist aber kein Muss. Sofern es sich um ein dediziertes Netz zwischen den ESX-Hosts oder ein definitiv abgeschottetes Netzwerk handelt, ist für ausreichend Sicherheit gesorgt! Bei VMotion-Netzen in erster Linie immer zu gewährleisten, dass das Netz exklusiv für VMotion und nur für die notwendigen ESX-Hosts zugänglich ist. Dadurch ist eine ausreichende Sicherheit gleich mit gegeben, und die Verfügbarkeit lässt sich durch mehr Ports und Switches erhöhen. Letzteres bietet damit auch gleich mehr Performance, ausgenommen bei active/Standby-Konfigurationen. Fault-Tolerance – VMkernel Für Fault-Tolerance ist die Mindestanforderung ein Gigabit-Netzwerk, VMware empfiehlt sogar ein 10-Gigabit-Netzwerk. Letzteres gilt sicher nur dann, wenn auch viele virtuelle Maschinen über Fault-Tolerance abgesichert werden sollen. Die Belastung dieses Netzwerktyps hängt stark von der Auslastung der virtuellen Maschinen und, wie zuvor erwähnt, von der Anzahl abgesicherter Systeme ab. Im Gegensatz zu VMotion-Netzen sind enorme Lastspitzen und lange Phasen mit wenig Last eher die Ausnahme. Für den Performance-Aspekt bietet es sich an, auch hier zukunftsorientiert zu denken. Fault-Tolerance ist eine sehr neue Funktion mit aktuell noch vielen Einschränkungen, die sich aber hoffentlich in Zukunft verringern. Damit steigt voraussichtlich auch die Anzahl der abgesicherten virtuellen Maschinen über diese Funktion. Freie Ports und Steckplätze für eine optionale Erweiterung und damit Erhöhung des Durchsatzes sind auch hier sicher interessant. Im Gegensatz zu VMotion ist die Verfügbarkeit dieses Netzwerktyps jedoch kritischer. Fällt ein Fault-Tolerance-Netzwerk aus, ist kein Schutz für die virtuellen Maschinen mehr gegeben. Eine Trennung des Netzwerkes von den anderen Netzen ist auch hier wieder sehr sinnvoll. Dies erhöht zudem die Sicherheit und reduziert die Systeme in diesem Netzwerk auf die Anzahl der ESX-Hosts.
366
Architektur-Beispiele
Ein Fault-Tolerance-Netzwerk stellt eventuell sehr hohe Anforderungen an die Performance, die unbedingt erfüllt werden sollten, in manchen Fällen sogar bis zu 10 Gigabit – eine Skalierbarkeit sollte möglich sein! Die Verfügbarkeit sollten Sie dabei nicht außer Acht lassen, und auch im Fehlerfall muss ausreichend Performance gegeben sein. Ansonsten gewährleistet Fault-Tolerance keinen Schutz für die virtuellen Maschinen. Sicherheitstechnisch reduziert sich das Netz auch hier auf die ESX-Hosts selbst, und es sollte in der Regel ein getrenntes Netz sein. Virtual-Machine-Netzwerke Netzwerke virtueller Maschinen sind sehr variabel, hier müssen Sie also wirklich genau auf die eigene Umgebung und damit verbundene Anforderungen schauen. Handelt es sich um ein Produktivnetz mit hohen Durchsätzen und großen Anforderungen an Verfügbarkeit und Sicherheit? Oder ist es ein Testnetzwerk, das vielleicht auch einmal ausfallen darf und nicht die durchgehend hohen Durchsätze benötigt? Genauso kann es ein Netzwerk sein, über das Anwender sich auf virtuelle Desktops verbinden. Grundsätzlich sollten Sie wie zuvor darauf schauen, welche Anforderungen es in Richtung Performance, Verfügbarkeit und Sicherheit gibt. In den meisten Fällen wird mit mindestens zwei Ports gearbeitet, um Ausfälle abzufangen. Zur Sicherheit sollten Sie darauf achten, dass unterschiedliche Netze voneinander mit Hilfe von VLANs abgeschottet sind. Es gelten hier schon fast die gleichen Regeln wie bei der Anbindung physischer Server. Eine häufige Frage während des Designs ist die Kombination unterschiedlicher Netze auf einem vSwitch. Dies lässt sich nach den Anforderungen von Performance und Verfügbarkeit gut einstufen. Die Sicherheit kann auf Basis von VLANs in den meisten Fällen außer Acht gelassen werden. Beim Konzeptionieren von Lösungen für Netze von virtuellen Maschinen sollten Sie immer möglichst viele Informationen zum Verhalten der Netze sammeln. Bei mehreren Netzen sollte über die Kombination lastintensiver mit weniger lastintensiven Netzen nachgedacht werden. Weiterhin sollten Sie bedenken, einen vSwitch mit mehreren aktiven Ports zu erstellen. Die aktiven Ports können dann auf der Portgruppeneben für jede Portgruppe individuell in den Modus »aktiv«, »Standby« oder »nicht zu verwenden« umgeschaltet werden. So kann eine erste Portgruppe Uplink 1 und 2 aktiv, Uplink 3 als Standby verwenden. Die zweite Portgruppe könnte Uplink 3 und 4 aktiv, Uplink2 jedoch als Standby verwenden. Dadurch lässt sich noch genauer die Verteilung der Netzlast der einzelnen Portgruppen auf einem gemeinsamen vSwitch konfigurieren.
367
7.3
7
Netzwerk
Server-Management-Karten Die Vernetzung von Server-Management-Controllern (iLOM, iRMC …) kann auch, gerade beim Einsatz von DPM, für das Netzwerkdesign des ESX-Hosts interessant werden. Für die Anbindung der Server-Verwaltungs-Schnittstellen ist keine enorm performante Verbindung notwendig. Daher können Sie diesen Aspekt getrost vernachlässigen. Verfügbarkeit ist gerade im Fehlerfall sehr wichtig. Fällt zum Beispiel die Verbindung zur Service Console aus, kann dies die letzte Möglichkeit sein, irgendwie den Server zum Beispiel per Remote-KVM zu verwalten. Oder einfach um einen Server-Status zu bekommen: eingeschaltet oder ausgeschaltet? Da aber über diese Verbindung unter anderem auch Server ein- und ausgeschaltet werden können, sollte die Sicherheit ein große Rolle spielen. Kurzum: Es gilt das Gleiche wie für die Service Console. Es handelt sich um eine Verwaltungsschnittstelle, die leider häufig in Konzepten vergessen wird!
7.3.2
Beispiel auf Basis verfügbarer Ports im Server
Es ist nicht einfach, eine optimale Konfiguration seines Netzwerkes zu finden. Die folgenden drei Beispiele sollen Ihnen helfen, eine Vorstellung davon zu bekommen, wie eine mögliche Konfiguration aussehen könnte. Für die eigene Umgebung sollten Sie aber zwingend zunächst die Bedingungen und den Bedarf ermitteln, bevor Sie eines dieser Beispiele übernehmen. Vor allem sind in den meisten Fällen Anpassungen nötig und gegebenenfalls sogar eine bessere Konfiguration. Für die Beispiele sind wir davon ausgegangen, dass VLANs eingesetzt werden. Geben wir in den folgenden Beispielen für eine Port-Group keinen Uplink mit A für »aktiv« oder S für »Standby« an, wird dieser nicht für die Portgruppe verwendet und muss also auch als nicht zu verwenden in der Port-Group konfiguriert werden. Grundlegend gilt natürlich: Je mehr Ports zur Verfügung stehen, umso mehr Konfigurationen sind möglich, und Sie können wesentlich besser optimieren. Wir haben auch immer nur einen Standby-Adapter konfiguriert, da bei Ausfall eines Ports immer nur ein Standby-Adapter aktiviert wird. Es gibt keine Möglichkeit, Uplink-Portgruppen zu definieren. Haben Sie also zwei aktive Uplinks auf Switch0 und zwei Standby-Adapter auf Switch1 verbunden, kann es bei Ausfall nur eines aktiven Adapters dazu kommen, dass die Performance sinkt, Da ein Etherchannel/LACP auf Switch1 und einer auf Switch0 konfiguriert wurde. Der ESX-Server wird daher nicht auch noch den zweiten Uplink umschalten. Fällt
368
Architektur-Beispiele
auch der zweite Link aus oder der komplette Switch, würden beide StandbyUplinks aktiviert und komplett auf den anderen Switch umgeschaltet.
7.3.3
ESX-Hosts mit zwei Netzwerkports
Die wohl kleinste sinnvolle Konfiguration sind zwei Ports in einem ESX-Server. Theoretisch könnten Sie auch mit nur einem Port arbeiten, dabei dürfen Sie aber keine Verfügbarkeit oder hohe Performance erwarten. Service Console vmnic0 – A vmnic1 – S
VMkernel_iSCSI1 vmnic0 – A
VMkernel_iSCSI2 vmnic1 – A
vSwitch0
VMotion vmnic0 – S Vmnic1 – A
vmnic0
Switch0
vmnic1 Switch1
Virtual Machine vmnic0 – A vmnic1 – A
Abbildung 7.54
Beispielkonfiguration mit zwei Uplink-Ports
Bei der Aufteilung der Ports an die unterschiedlichen Portgruppen wurde versucht, eine möglichst gleiche Auslastung der Ports bei ausreichender Verfügbarkeit zu erhalten. Im normalen Zustand werden über vmnic1 die Service Console, VMkernel_ iSCSI1 und ein Teil des Virtual-Machine-Netzwerkes kommunizieren, über vmnic2 der VMkernel_iSCSI2, VMotion und der andere Teil des VirtualMachine-Netzwerkes. Die Aufteilung des Virtual-Machine-Netzwerkes auf beide Uplinks ist nur möglich, sofern ein switch-übergreifender Etherchannel unterstützt wird oder mit einer Paketverteilung auf Basis der Source-MAC oder des vSwitch-Ports eingerichtet ist. Für die Anbindung eines iSCSI-Datastores wurden zwei VMkernel-Netze zum Storage gewählt, eine Verteilung der Last erfolgt durch das Multipathing des ESX-
369
7.3
Netzwerk
Servers. Dabei wurde für jeden VMkernel ein anderer Uplink festgelegt. Warum iSCSI als Beispiel? Bei einer Zwei-Port-Konfiguration handelt es sich meist um eine günstige Lösung, und sie ist daher meist in Verbindung mit iSCSI-Storage zu finden. Service Console und VMotion sind auf unterschiedlichen Uplinks, der zweite Uplink ist aber jeweils als Standby-Adapter für den Fehlerfall konfiguriert.
7.3.4
ESX-Hosts mit vier Netzwerkports
Gegenüber dem Beispiel mit zwei Ports arbeiten wir in diesem Beispiel mit NFS. Für NFS müssen Sie immer im Netzwerk für die Performance und Verfügbarkeit sorgen. Sie können kein Host-Multipathing verwenden. Service Console vmnic0 – A vmnic2 – S vmnic0 VMotion vmnic0 – S vmnic2 – A VMkernel_NFS vmnic0 – A vmnic1 – A vmnic2 – S
Switch0 vSwitch0
7
vmnic1
vmnic2 Virtual Machine vmnic1 – S vmnic2 – A vmnic3 – A
Switch1 vmnic3
Abbildung 7.55
Beispielkonfiguration mit vier Uplink-Ports
Aus Sicht der Uplinks sind vmnic0 und vmnic1 auf Switch0 verbunden. Über diese Ports wird der VMkernel verbunden. Um einen Switch-Ausfall abzufangen, konfigurieren wir noch vmnic2 als Standby. Die Service Console ist mit vmnic0 verbunden und für den Ausfall des Ports oder Switchs zusätzlich über vmnic2 als Standby-Adapter abgesichert. Über Switch1 kommunizieren vmnic2 und vmnic3. Das Virtual-Machine-Netzwerk verwendet diese beiden Ports aktiv und ist über vmnic1 gegen den Ausfall von Switch1 abgesichert. Das VMotion-Netzwerk ist im Normalzustand über vmnic2 verbunden und bei Ausfall des Ports oder Switchs mit vmnic0 als Standby-Adapter konfiguriert.
370
Architektur-Beispiele
Für Netzwerke mit mehr als einem aktiven Port muss eine Paketverteilung eingerichtet werden, die wie bei der Zwei-Port-Konfiguration von den externen Switches abhängig ist. Bei einem switch-übergreifenden Etherchannel muss IP-Hash oder LACP eingestellt werden, ansonsten entweder MAC-Source oder Originating Port-ID als Paketverteilung ausgewählt werden.
7.3.5
ESX-Hosts mit sechs Netzwerkports
Für die Sechs-Port-Konfiguration haben wir das vorherige Beispiel um wesentliche Best-Practice-Empfehlungen erweitert. So stehen pro Netzwerk im Normalfall dedizierte Ports zur Verfügung. Bei Ausfall eines Ports oder Switches kann es aber auch wieder dazu kommen, dass zwei Netzwerke über einen Port verbunden sind. Bei der Einstellung der Paketverteilung gilt das Gleiche wie in den beiden Beispielen zuvor.
Service Console vmnic0 – A vmnic2 – S
vmnic0
vmnic1
vSwitch0
VMotion vmnic0 – S vmnic3 – A
VMkernel_NFS vmnic1 – A vmnic2 – A vmnic5 – S
Switch0
vmnic2
vmnic3
Virtual Machine vmnic2 – S vmnic4 – A vmnic5 – A
vmnic4 Switch 1
vmnic5
Abbildung 7.56
Beispielkonfiguration mit sechs Uplink-Ports
Natürlich ist es auch möglich, eine Konfiguration mit mehr als einem vSwitch zu erstellen. Die bisherigen Empfehlungen gelten dabei genauso. Eine Konfiguration mit mehr als einem vSwitch kann helfen, klarer abzugrenzen und Konfigurationen nicht zu komplex werden zu lassen. In diesem Beispiel wurde so das VMkernel- und das Virtual-Machine-Netzwerk getrennt. Der Netzwerkverkehr für NFS-Datastores wird über vmnic1 und vmnic2 verteilt, die beide an Switch0 verbunden sind.
371
7.3
Netzwerk
Service Console vmnic0 – A vmnic2 – S vSwitch0
vmnic0
VMkernel_NFS vmnic0 – S vmnic1 – A vmnic2 – A
vmnic1
Switch0
Virtual Machine vmnic3 – S vmnic4 – A vmnic5 – A
VMotion vmnic3 – A vmnic4 – S
vSwitch0
vmnic2
vmnic3
vmnic4 Switch 1
vmnic5 Virtual Machine Test (kein Uplink)
Abbildung 7.57
vSwitch0
7
Weitere Beispielkonfiguration mit sechs Uplink-Ports
Die virtuellen Maschinen sind im Normalfall über vmnic4 und vmnic5 angebunden. Sollte ein Link oder Switch ausfallen, können beide Portgruppen auf einen Standby-Adapter zurückgreifen, der mit dem jeweils anderen physischen Switch verbunden ist. Damit diese Konfiguration bei Ausfall nur eines Ports ordnungsgemäß funktioniert, müssen Sie entweder mit der Paketverteilung auf Basis der Source MAC Address oder der Originating Port ID arbeiten. Alternativ, sofern die physischen Switches einen übergreifenden Channel unterstützen, nutzen Sie IPHash. Für die Service Console wurde wieder vmnic0 im Normalfall exklusiv reserviert. VMotion auf dem zweiten vSwitch arbeitet über vmnic3. Beiden Portgruppen haben wir wieder einen Standby-Port zugewiesen. Der Ausfall eines Ports oder Switches ist damit berücksichtigt. Für eventuelle Tests haben wir einen internen vSwitch für virtuelle Maschinen eingerichtet. In manchen Umgebungen wird ein solcher vSwitch ohne externen Uplink auch für den Aufbau einer DMZ-Umgebung genutzt. Wichtig ist aber, die Einschränkungen der angebundenen virtuellen Maschinen für VMotion zu berücksichtigen.
372
VMware vSphere bringt wesentliche Neuerungen und Verbesserungen in Bezug auf die Speicherunterstützung mit. Außerdem können viele Funktionen der virtuellen Infrastruktur nur mit zentralem Massenspeicher genutzt werden. Das folgende Kapitel schafft Grundlagen und gibt Anhaltspunkte zu Performance und Ausfallsicherheit.
8
Storage-Architektur Autor dieses Kapitels ist Dennis Zimmer, icomasoft AG, [email protected]
Die korrekte Planung der Storage-Architektur ist einer der wichtigsten Faktoren für eine erfolgreiche Virtualisierungslösung. Laut VMware sind fast 90 % der Supportanfragen auf Storage-Probleme zurückzuführen. Dabei sind mit StorageProblemen weniger physische Störungen, sondern vielmehr Planungsfehler gemeint, die z. B. zu Zugriffs- oder Leistungsproblemen führen. Es ist allerdings zu leicht, einfach alles auf die anfängliche Planung zu schieben, da viele der Schwierigkeiten erst auftreten, nachdem die virtuelle Infrastruktur über eine längere Zeit betrieben wurde und über gewisse Grenzwerte wuchs. Das folgende Kapitel soll helfen, sowohl eine korrekte Planung für jetzt als auch für das kommende Wachstum zu finden. Außerdem werden Hilfestellungen aufgezeigt, wie Sie derzeitige und zu erwartende Engpässe adressieren können.
8.1
Lokale Medien
VMware ESX unterstützt die Installation und den Start des Systems auf bestimmten Typen lokaler Festplatten. Dabei bieten die unterschiedlichen Festplattentypen auch unterschiedliche Eigenschaften; z. B. ist der Betrieb virtueller Maschinen nicht von jedem Medium möglich oder empfohlen. Allerdings ist es möglich, beispielsweise über externe USB-Festplatten Sicherungen durchzuführen.
8.1.1
SATA
Die offizielle Unterstützung von SATA-Festplatten kam relativ spät mit Erscheinen der VMware-Version 3.5. Vorher war der SATA-Einsatz nur im SAN, NAS
373
8
Storage-Architektur
durch zertifizierte Storage-Anbieter oder an »zufällig« unterstützten SATA-Controllern möglich. »Zufällig« bedeutet in diesem Fall, dass der gleiche Treiber für SCSI- und SATA-Controller verwendet werden konnte, wodurch verschiedene Intel- und LSI-Controller »versehentlich« wurden. Allerdings gab es nie einen offiziellen Herstellersupport. Seit VI 3.5 und damit auch mit vSphere kann nun problemlos auf SATA Festplatten zugegriffen werden, vorausgesetzt, der SATA-Controller besitzt offiziellen Support (http://www.vmware.com/go/hcl). Eine Installation auf SATA-Festplatten ist uneingeschränkt möglich, allerdings sollten Sie immer eine ausfallsichere RAID-Variante, z. B. RAID 1 oder RAID 5, wählen. Der Betrieb virtueller Maschinen auf lokalen SATA-Festplatten ist allerdings nicht zu empfehlen, wenn die VMs produktiv eingesetzt werden und entsprechend Leistung benötigt wird. Die Leistungsfähigkeit bei Random-Zugriff von SATA- gegenüber Fibre-Channeloder SAS-Festplatten kann mit weniger als 50 % angegeben werden. Da beim Betrieb mehrerer VMs auf dem gleichen VMFS nahezu ausschließlich RandomZugriff herrscht, entsteht mit SATA leicht ein Performance-Engpass. Hintergrund ist hier u. a. die Datendichte, also reine Physik. Vergleicht man 1 TB SATA mit 300 GB SAS, so sind auf ungefähr gleicher Fläche dreimal mehr Daten abgelegt.
Abbildung 8.1 Aus sequentiell wird dank mehrerer virtueller Festplatten und LUNs reiner Random-Zugriff.
374
Lokale Medien
Dies ist im beim sequentiellen Lesen und Schreiben von Vorteil, allerdings nicht bei Random-Zugriff, wo der Schreib-Lese-Kopf sich stetig bewegen muss, um die Daten auszulesen. Random-Zugriffe auf einer LUN Sie müssen immer bedenken, dass die Random- oder sequentiellen Zugriffe nicht pro LUN, sondern pro RAID-Gruppe stattfinden. Daher ist es nahezu unmöglich, dass sequentiell Zugriffe vorkommen, wenn mehrere VMs über mehrere LUNs auf einer RAID-Gruppe liegen. Daher ist sequentiell nur zu gewährleisten, wenn eine VM oder ein RDM auf einer LUN liegt, welche wiederum alleine auf einer RAID-Gruppe liegt.
SATA-Festplatten sind zumeist mit 5 400 oder 7 200 Umdrehungen (RPM) erhältlich und wesentlich billiger als die FC-Typen. Mittlerweile verfügen die SATAPlatten über bis zu 32 MB Cache, was deutliche Leistungsvorteile bringt. Allerdings kann die einzelne SATA-Festplatte nicht mit einer FC-/SAS-Platte mithalten. Es kann davon ausgegangen werden, dass eine SATA-Platte zwischen 70 und 90 IOPS je nach Umdrehungen erreicht. Dagegen hilft nur das Bündeln mehrerer SATA-Festplatten zu einem großen RAID-Verbund, allerdings führen Sie dies besser im SAN (Storage Area Network) oder NAS (Network-attached Storage) als im DAS (Direct-attached Storage) durch. Hier sollten Sie noch einen wesentlichen Punkt bedenken, und zwar die Limitierung von VMware auf zwei TB-LUNs. Je nach Storage-System und der Umrechnung von 2 TB in Byte sollten Sie nur mit 1,99 TB formatieren, um VMFS-Probleme zu vermeiden. Das Limit von 2 TB pro LUN ist auch mit vSphere noch akut, da VMware nach wie vor auf das SCSI2-Protokoll setzt. Würden Sie fünf 1-TB-SATA-Festplatten in einem RAID 5 bündeln, so kämen Sie auf eine Nutzkapazität von etwa 4 TB. Existieren keine Möglichkeiten des lokalen RAID-Controllers oder des Storage-Systems, diese RAID-Gruppe nochmals logisch zu unterteilen, z. B. 2 × 2 TB, dann ist diese RAID-Gruppe nicht mit VMware nutzbar. Mit ein wenig Glück erkennt VMware dieses RAID als 1,6-TBPlatte, allerdings ist es nicht empfehlenswert, in einem solchen Zustand produktiv zu arbeiten. Außerdem müssen Sie daran denken, dass SATA-Festplatten ursprünglich aus dem Desktop-Bereich kommen und dort MTBF (Mean Time between Failure) nicht wirklich ein wichtiges Kriterium ist. Momentan beginnt zwar ein Trend, SATA im professionellen Umfeld einzusetzen und die Festplatten als »RAIDready« oder »Enterprise-ready« zu kennzeichnen, allerdings sind die Ausfallraten derzeit noch höher als im SCSI-, SAS- oder Fibre-Channel-Umfeld.
375
8.1
8
Storage-Architektur
Kommt es nicht auf Festplattenleistung an und ist nur Festplattenkapazität von Bedeutung, ist SATA eine erstklassige Wahl. Übrigens sind SATA-Festplatten aufgrund ihrer sehr guten sequentiellen Leistung sehr gut im Backup-/Restore-Umfeld einsetzbar.
8.1.2
SCSI und SAS
SAS (Serial-attached SCSI) hat das parallele SCSI (finaler Standard Ultra-320) in rasanter Geschwindigkeit abgelöst. Die parallele SCSI-Anbindung hatte die physischen Belastungsgrenzen erreicht, da die Signallaufzeit der einzelnen Bits auf dem Bus zu sehr abwich. SAS überträgt das traditionelle SCSI seriell und ermöglicht damit höhere Übertragungsraten, nämlich bis zu 3 GBit/s. Die nächsten Stufen sehen 6 GBit/s (2009) und 12 GBit/s (2013) vor. Außerdem nutzt SAS Punktzu-Punkt-Verbindungen, wodurch ein SCSI-Terminator überflüssig wird. SAS hat aber noch zwei weitere Vorteile: Expander SAS unterstützt die Erweiterung durch Expander, um Domänen von SAS-Geräten aufzubauen, was mit Netzwerk-Switches vergleichbar ist. Damit ist es möglich, bis zu 128 Endgeräte über ein SAS-Kabel zu betreiben. Real existieren derzeit 36er-Anschlüsse. Dual Porting SAS bietet die Möglichkeit, Festplatten mit einem oder mit zwei Ports zu nutzen, entweder gebündelt (Performance) oder zur Ausfallsicherheit. Eine Dual-PortSAS-Platte kann somit an zwei unterschiedliche SAS-Controller angeschlossen werden, womit eine Ausfallsicherheit sehr einfach realisierbar ist. Kein Hersteller verbaut noch SCSI-Festplatten in den Servern; SAS- und SSD-Festplatten sind in diesem Feld mittlerweile gesetzt. Auch im Storage-Bereich ist immer öfter SAS zu finden, z. B. bei Dell-EqualLogic- oder HDS-Systemen. Da SAS eine Weiterentwicklung von SCSI darstellt, besitzt SAS die gleichen positiven Eigenschaften: sehr gute Zugriffs- und Übertragungswerte. Hier ist von 120 IOPS (10.000 Umdrehungen) und 180 IOPS (15.000 Umdrehungen) auszugehen. SCSI und SAS Platten sind ideale Kandidaten zur Verwendung als lokaler Speicher mit VMware ESX. Auch bei SCSI und SAS gilt, lokal ein ausfallsicheres RAID 1 oder RAID 5 aufzubauen, bevor Sie den ESX-Server installieren.
376
Lokale Medien
Beide Plattentypen eignen sich zudem bei entsprechender Festplattenanzahl und entsprechendem RAID-Level (1, 10 oder 5, 50) zum Betrieb virtueller Maschinen auf lokalem Speicher. SAS-Festplatten werden inzwischen auch sehr oft im kleinen 2,5"-Faktor ausgeliefert und sind damit echte Allrounder.
8.1.3
Fibre-Channel
Fibre-Channel-Festplatten gehören (abgesehen von Solid-State-Festplatten) definitiv zu den schnellsten Festplattentypen im Storage-Bereich. Aufgrund des teuren FC-Anschlusses sind diese Festplatten im Server-Bereich sehr selten zu finden, dafür im Storage-Bereich umso öfter. Wegen der guten Zugriffsgeschwindigkeit und der hohen Datenübertragungsraten wird FC meist in Bereichen eingesetzt, in denen Geschwindigkeit und Zuverlässigkeit gefragt sind. Die Spindeln der FC-Platten drehen 10.000 oder 15.000 Mal die Minute (RPM), und man kann von den minimal höheren IOPS-Raten wie bei SAS-Festplatten ausgehen. FC ist trotz des Aufholens von SAS nach wie vor die schnellste Festplattenvariante.
8.1.4
IDE
Aus der Not geboren, integrierte VMware auch eine IDE-Unterstützung, nicht nur für Wechselmedien (CD/DVD), sondern auch für lokale Festplatten zur Installation unterstützt. Die Not wurde durch die ersten Blade-Server ausgelöst, die mit 2,5"-IDE-Festplatten ausgestattet waren. Allerdings ist nur die Installation des ESX-Servers auf diesem Medium unterstützt, VMFS-Unterstützung besteht nicht! Dies hat auch einen guten Grund, denn IDE-Festplatten bieten weder die Verfügbarkeit noch die Leistungsfähigkeit, die man sich zum Betrieb virtueller Infrastrukturen wünscht. Bei IDE-Nutzung gilt genau wie bei anderen Festplattentypen, dass zumindest ein RAID 1 über zwei Festplatten erstellt werden sollte, um den Defekt einer Festplatte ohne Datenverlust und Ausfall zu überstehen.
8.1.5
SSD
SSD steht für »Solid State Disk« und bezeichnet Festplatten, die aus Speicherchips und nicht aus den in der traditionellen Festplattenwelt bekannten Magnetscheiben bestehen. Als Speicherchips dienen entweder Flash oder SDRAM. Die beiden
377
8.1
8
Storage-Architektur
Speichertypen unterscheiden sich hauptsächlich in Geschwindigkeit und Flüchtigkeit, wie Tabelle 8.1 zeigt. SSD Flash
SSD SDRAM
Festplatte
Geschwindigkeit
mittel – hoch
sehr hoch
hoch
Zugriffszeit
gut
sehr gut
mittel – schlecht
Datenflüchtigkeit
nicht flüchtig
flüchtig
nicht flüchtig
Robustheit
hoch
hoch
niedrig
Leistungsaufnahme
niedrig
niedrig
hoch
Lautstärke
lautlos
lautlos
mittel – hoch
Preis
mittel – hoch
sehr hoch
günstig – hoch
Tabelle 8.1
Vergleich SSD-Typen zu herkömmlicher Festplatte
SSD-Festplatten dienen z. B. auch als Installationsbasis für die Embedded-Version des VMware ESXi, die bei Server-Auslieferung bereits vorinstalliert ist. Dort werden entweder SSD-Festplatten oder USB-Memory-Sticks genutzt.
Abbildung 8.2 Deutliche Vorteile bei Random-Write durch die Verwendung von SSD gegenüber den letzten beiden Magnetplatten
Der Test der verschiedenen SSDs und die Gegenüberstellung mit den beiden Magnetfestplatten von Western Digital und Seagate zeigen sehr deutlich die Vorteile für die Solid-State-Laufwerke. Dieser Test und auch die Grafiken sind auf AnandTech (http://www.anandtech.com/storage/showdoc.aspx?i=3667&p=6) zu finden.
378
Lokale Medien
Abbildung 8.3 Noch deutlichere Vorteile bei Random-Read durch die Verwendung von SSD gegenüber den letzten beiden Magnetplatten
Derzeit sind die Preise von SSD-Platten noch sehr hoch, und die Flüchtigkeit des Speichers ist noch ein Problem. Allerdings ist es sehr sicher, dass SSD-Festplatten die Zukunft sind und in den nächsten Jahren herkömmliche Festplatten zum großen Teil ersetzen werden. Diese Aussage soll für den Desktop-, Notebook- und Server-Markt gelten. Außerdem werden sie aufgrund der enormen Leistungsmöglichkeiten im Random-Zugriff sehr schnell im Storage-Markt Einzug erhalten (HDS, EMC und NetApp haben bereits Module im Programm, Texas Memory hat mit den RAMSAN-Modellen seit Längerem enorm schnelle Speichersysteme im Portfolio). Aber auch wenn man mit den hohen Preisen kalkuliert, so sind diese nur auf die Kapazität bezogen hoch – auf die I/O und damit die Leistungsfähigkeit gerechnet sind die SSD-Laufwerke deutlich günstiger als die SAS- oder SATA-Festplatten, da man von diesen die 30- bis 50fache Menge benötigen würde. Gerade im VMware-, aber auch im Datenbank- und Exchange-Umfeld sind die Kapazitäten der Festplatten zumeist wesentlich uninteressanter als die Leitungsfähigkeit, daher ist der Erfolg der SSD-Laufwerke nur eine Frage der Zeit. Eine sehr interessante SSD-PCIe-Karte, die enorme Geschwindigkeiten bietet, wurde von dem Unternehmen Fusion-I/O entwickelt (www.fusionio.com). Derzeit sind maximal 360-GB-Karten erhältlich, aber dies ist erst der Anfang dieser neuen zukunftsträchtigen Technologie. In die gleiche Richtung entwickelt mittlerweile auch Texas Memory und bietet eine 450-GB-Flash-Storage-Karte an, die mit 120.000 IOPS und 700 MB/s Random-Durchsatz enorme Performance aufweist.
379
8.1
8
Storage-Architektur
SSD-Karten werden besonders gerne in Storage-Systemen zur Cache-Erweiterung eingesetzt.
8.1.6
USB
USB-Festplatten bieten aufgrund der guten Geschwindigkeit und des guten Preises eine schöne Möglichkeit, virtuelle Maschinen zu sichern und wiederherzustellen. Nachweislich kommt es allerdings bei einer Vielzahl von Server-Systemen zu Leistungseinbußen, wenn der USB-Anschluss aktiviert ist. Daher sollten Sie dies bei den Server-Systemen vorher prüfen! Falls es zu Leistungsproblemen kommt (im schlimmsten Fall Absturz des Systems), empfiehlt es sich, den On-Board-USB-Controller abzuschalten. Wenn Sie dennoch USB einsetzen möchten, ist eine USB-Zusatzsteckkarte die bessere Wahl. Beim Anschluss eines USB-Mediums wird dies in der Protokolldatei der Service Console angezeigt (/var/log/messages). Anhand des Gerätepfades können Sie das Gerät mit dem mount-Befehl verbinden. Dabei sollten Sie allerdings bedenken, dass die Service Console nur FAT und EXT3 unterstützt und kein NTFS! Wer sich für den Boot eines ESXi mittels USB Stick interessiert und dies gerne testen möchte, findet unter diesen beiden Links hilfreiche Informationen: http://blog.consol.de/cm/2009/04/vmware-esxi-vom-usbstick-booten.html http://vmware-forum.de/viewtopic.php?t=16462 Tipp Trotz der Möglichkeit, virtuelle USB-Controller in den virtuellen Maschinen zu konfigurieren, können Sie keine USB-Sticks oder USB-Festplatten an den ESX-Host anschließen und diese Geräte an die virtuelle Maschine weiterreichen.
8.2
Die Wahl: Block oder File
Grundlegend sei vorweg gesagt, dass bei vSphere alle Dateien, aus denen virtuelle Maschinen bestehen, zusammen in einem Unterverzeichnis oder mehreren Unterverzeichnissen (je nach Verteilung der virtuellen Festplatten) liegen. Dieses
380
Die Wahl: Block oder File
Verzeichnis liegt wiederum in einem sogenannten Datastore – einem Ablageort für virtuelle Maschinen. Dabei ist es für die virtuellen Maschinen im Alltagsbetrieb völlig transparent, um welche Art von Datastore es sich handelt, das heißt, eine VM kann nicht unterscheiden, ob sie auf einem VMFS3 formatierten – somit blockbasierten – Datastore gespeichert ist, oder ob sie auf einem NFS Datastore liegt. Beide Arten von Datastores haben ihre Vor- und Nachteile. Die Entscheidung ist hier sicherlich nicht trivial und auch nicht durch ein »gut« oder »schlecht« zu beantworten. Es kommt hier immer auf die eigenen Anforderungen und Voraussetzungen an, um die Entscheidung zu vereinfachen. Klassisch wurden von ESX in Version 2 ausschließlich Fibrechannel Datastores unterstützt. Daher war zu diesem Zeitpunkt die Wahl sehr einfach. Doch VMware hat mit Version 3.0 auch begonnen iSCSI und NFS Datastores zu erlauben. Dem Leser sei selbst überlassen, die für sich richtige Wahl zu treffen. Als Entscheidungshilfe kann die folgende Tabelle herangezogen werden.
Durchsatz
FCP
iSCSI
NFS
Hoch (100 %)
Niedriger (92 %)
Mittel (95 %)
Evtl. besser bei 10GE Evtl. besser bei 10GE Latenz
Sehr niedrig
Mittel
Kosten
Hoch, neue HBAs und evtl Switches nötig
Sehr niedrig, alles in Niedrig, Infrastrukkostenloser SW tur und Wissen meist vorhanden
Redundanz
Sehr gut und einfach Gut, abhängig von LAN Switches, mittelschwer
Gegeben, aber relativ komplex zu konfigurieren
Komplexität
Hoch, oft neues Know-How nötig
Niedrig, NFS KnowHow meist vorhanden
Skalierbarkeit
Gut, aber Beschrän- Mittel, aber kungen von VMFS Beschränkungen von VMFS
Sehr gut, keine VMFS Limits
Management
Komplex
Mittelschwer
Einfach
Platzverbrauch
Normal, nur mit Thinprovisioning niedrig
Normal, nur mit Thinprovisioning niedrig
Niedrig, Thinprovisioning per Default
Tabelle 8.2
Mittel, iSCSI Knowhow schnell lernbar
Mittel
Vergleich der Datastore-Protokolle
381
8.2
8
Storage-Architektur
Neben diesen Kriterien spielt bei der Wahl auch oft die bereits im Einsatz befindlichen Technologien eine ausschlaggebende Rolle: 왘
Ist bereits eine FCP Infrastruktur und Know-How vorhanden?
왘
Ist eine 10 GBit Ethernet Infrastruktur vorhanden?
왘
Womit hat der Administrator am meisten Erfahrung, insbesondere beim Troubleshooting und Design der Infrastruktur?
왘
Welche Protokolle sind auf dem Storagesystem lizensiert?
Um weitere Vorteile und Nachteile der entsprechenden Anbindungsarten kennenzulernen, haben wir die Storage-Themen auf insgesamt drei Kapitel verteilt, um Ihnen die bestmöglichen Angaben zu bieten.
8.3
Storage Area Network – Was ist eigentlich ein SAN?
Zu dieser kurzen Frage könnte man mit einem oder mehreren Büchern antworten, allerdings fassen wir uns kurz und gehen nur auf das im VMware-Umfeld Wesentliche ein. Ein Storage Area Network ist ein eigenes Netzwerk, in dem Massenspeichersysteme mit Server-Systemen verbunden sind. Man unterscheidet mittlerweile FC SAN (Fibre-Channel) und IP SAN (iSCSI), allerdings stammen die Basiskonzepte aus der Fibre-Channel-Welt. Traditionell wird ein SAN mit Fibre-Channel verbunden und in einer Switched Fabric betrieben. Die Switched Fabric ist eine Sternvernetzung, die durch FibreChannel-Switches realisiert wird. Um die Ausfallsicherheit zu gewährleisten und auch Wartungen zu vereinfachen, werden meist mehrere Switched Fabrics aufgebaut, die komplett voneinander unabhängig sind, aber trotzdem die gleichen Endgeräte an anderen Ports miteinander verbinden. Neben der Switched Fabric existiert der Arbitrated Loop, der für Speichernetze allerdings veraltet ist und von VMware auch keine Unterstützung findet. Er ist wie ein Ring aufgebaut und kann durch die Nutzung von FC-Hubs vereinfacht verkabelt werden. Eine enorme Einschränkung bei der Verwendung des Arbitrated Loop ist, dass die Gesamtbandbreite zwischen allen Teilnehmern aufgeteilt wird, da immer nur zwei Teilnehmer gleichzeitig miteinander kommunizieren können. Stehen 2 GBit in einem Ring mit 8 Knoten zur Verfügung, kann im Durchschnitt nur mit 256 MBit pro Knoten kalkuliert werden. Arbitrated Loop wird jedoch nach wie vor oft intern in Storage-Systemen verwendet, was allerdings für die VMware -Infrastruktur nicht sichtbar ist.
382
Storage Area Network – Was ist eigentlich ein SAN?
Abbildung 8.4
Switched Fabric
Abbildung 8.5
Arbitrated Loop im SAN
Mit der Einführung von iSCSI wurde auch Ethernet als Basis für Speichernetze populär, und man spricht hier von IP SAN. Ein wesentliches Unterscheidungsmerkmal zwischen SAN und LAN ist aber in jedem Fall, dass nur Speichergeräte und Server miteinander verbunden sein sollten und nur mit Speicherprotokollen kommuniziert wird (iSCSI, FCP). Diese Trennung ist unabhängig von der physischen Basis sinnvoll und sehr zu empfehlen.
383
8.3
8
Storage-Architektur
Im aktuellen Fibre-Channel-Umfeld fällt die Trennung zum LAN leicht, da FibreChannel nicht zur »normalen« Netzwerkkommunikation genutzt wird. So ist es unwahrscheinlich, jemanden mit einem mit FC-Adapter bestückten Notebook im Rechenzentrum beim Datenschnüffeln zu erwischen. Bei iSCSI können jedoch Standard-Ethernet-Switches und Netzwerkkarten verwendet werden. In diesem Fall können wir nur dringend anraten, entweder das IP SAN vom LAN mit separaten Switches komplett zu trennen oder zumindest mit einer Trennung mittels VLAN zu arbeiten.
8.4
Infiniband
Eine nicht ganz neue, aber wiederentdeckte Technologie ist Infiniband. Infiniband ist ein Hochgeschwindigkeitsnetz mit sehr geringen Latenzzeiten, das auch im VMware-Umfeld mit vielen Vorteilen glänzt. Ursprünglich wurde Infiniband für High-Performance-Computing-Umgebungen entwickelt, allerdings stellt sich Infiniband nach und nach als sehr gute Lösung für konsolidierte Umgebungen heraus, da neben der hohen Leistungsfähigkeit eine Konsolidierung der I/OAdapter stattfinden kann. Ein Infiniband-HCA (Host Channel Adapter) kann derzeit 20 GBit Durchsatz erzielen und damit etliche GB-Ethernet und FC-Adapter ersetzen. Gerade Heartbeat-Netze und VMotion-/FT-Netzwerke profitieren sehr von Infiniband. Allerdings wird sich diese Technologie sehr schwer gegen die 10GBit-Konkurrenz durchsetzen können.
8.5
Kommunikationsadapter
Unabhängig von iSCSI-, SCSI- oder Fibre-Channel-Netzwerken wird immer von Initiator und Target gesprochen. Dieser Ausdruck hat seinen Ursprung im SCSIProtokoll und bezeichnet den hostseitigen Endpunkt einer SCSI-Verbindung.
8.5.1
Initiator
Der Initiator stellt die Datenverbindung zum Speicherendpunkt (Target) her. Es gibt zwei Arten von Adaptern, die im VMware-Umfeld als Initiatoren genutzt werden können: Hardware-HBA und Software-Initiator. Host-Bus-Adapter (FC, iSCSI) Sowohl Fibre-Channel- als auch iSCSI-Verbindungen können mittels physischem Host-Bus-Adapter (HBA) zum Speichersystem hergestellt werden. Diese Adapter
384
Kommunikationsadapter
müssen über einen schnellen Bus zum Server-System verfügen, daher sind sie zumeist als PCI-X- oder PCI-Express-Karten erhältlich.
VMkernel HBA-Treiber
FC HBA (Qlogic, Emulex)
FC-Frame
Abbildung 8.6
Fibre-Channel-HBA mit VMware-Treiber
Ein großer Vorteil von HBAs ist die eingebaute CPU, die die FC- oder iSCSIPakete empfängt, bearbeitet oder verschickt. Dadurch werden die Prozessoren des Host-Systems nicht belastet. In Abbildung 8.6 ist klar zu sehen, dass der HBA die FC-Frames verwaltet und der VMkernel nur den Treiber zur Nutzung stellen muss. Im iSCSI-Fall dient die HBA-CPU zum Entpacken und Verpacken der SCSI-Kommandos in das TCP/IP-Protokoll.
VMkernel HBA-Treiber iSCSIHBA (QLogicQLA4050/ QLA4052)
iSCSI-Init. ToE
Abbildung 8.7
iSCSI-HBA mit VMware-Treiber
385
8.5
8
Storage-Architektur
Die meisten HBAs verfügen außerdem über ein BIOS, das auch den Systemstart über den HBA ermöglicht. Durch diese Funktion ist die Nutzung von festplattenlosen Systemen möglich, deren Systempartitionen im SAN liegen. Auch diese Funktion entstand wie die IDE-Unterstützung aufgrund Anforderungen aus den Blade-Systemen. Bei der Verwendung von HBAs in der gleichen Broadcast-Domäne sollten Sie immer die Firmware-Versionen identisch halten, um Inkompatibilitäten zu vermeiden. VMware-HBA und Software-Initiator VMware unterscheidet bei der Unterstützung von Storage-Systemen zwischen der Zertifizierung für HBAs und Software-Initiator, worauf Sie in jedem Fall achten sollten.
Software-Initiator Software-Initiatoren bzw. emulierte Controller, die als Initiator dienen, kommen unter VMware ESX nur im iSCSI-Umfeld vor. Der große Vorteil der Software-Initiatoren ist die Verwendbarkeit von herkömmlichen Netzwerkkarten zur iSCSIKommunikation, was einen erheblichen Kostenvorteil bringt.
VMkernel SWInititiator TCP/IPStack NIC-Treiber
Abbildung 8.8 Der Software-iSCSI-Initiator wird komplett vom Kernel gestellt, basierend auf dem Netzwerkkartentreiber.
Unter VMware ESXi besteht nur der Nachteil der Belastung der Host-CPU; bei VMware ESX kommt hinzu, dass Service Console und VMkernel-Port Netzwerkzugriff auf den iSCSI-Speicher benötigen.
386
Kommunikationsadapter
Die Host-CPU-Belastung wird mit neueren VMware-ESX-Versionen nach und nach durch TOE-fähige (TCP/IP Offload Engine) Netzwerkkarten und die Verteilung der VMkernel-Last auf unterschiedliche CPU-Kerne minimiert oder gar komplett wegfallen. Bei Verwendung moderner Server-Systeme ist der Geschwindigkeitsunterschied zwischen Software- und Hardware-Initiatoren kaum spürbar. Allerdings ist es mit Software-Initiatoren nicht möglich, das System über SAN zu booten, das heißt, es werden zwingend lokale Systemfestplatten benötigt. iSCSI und Gateways Obwohl es möglich ist, die iSCSI-Anbindung über Router und Gateways zu betreiben, sollten Sie dies unter allen Umständen vermeiden. Hier ist besonders auf eine performante Verbindung zwischen dem VMkernel-Port und dem Storage-Target zu achten. Die Service-Console-Verbindung, die für die Metadaten zuständig ist, ist nicht minder wichtig, aber etwas anspruchsloser als der Datenkanal.
Software-Initiator im Gastbetriebssystem Neben der Möglichkeit der Software iSCSI-HBA-Nutzung im VMkernel bringen sowohl Linux als auch Windows eigene iSCSI-Initiator-Treiber mit, die über das Netzwerk der virtuellen Maschine die Verbindung mit dem Target aufnehmen. Diese Variante ist die schnellstmögliche iSCSI-Nutzung, da die Software-iSCSIInitiatoren der Gastbetriebssysteme MPIO-Multipathing unterstützen, wodurch gleichzeitig mehrere Verbindungen (Netzwerkkarten) zum Storage-System hergestellt und genutzt werden können. Ansonsten ist dieses Verfahren mit Raw-Device-Mapping vergleichbar, da die LUN nur der einzelnen VM, also dem einzelnen Software-iSCSI-Initiator, zur Verfügung steht. In diesem Fall benötigt der ESX-Host keinerlei Zugriff auf den iSCSI-Storage. Da kein Booten von iSCSI mittels Gastbetriebssystem möglich ist, müssen Sie diese Technik allerdings mit lokalen VMFS-Partitionen, NFS oder iSCSI über VMKernel kombinieren, z. B. Boot-Platte über VMkernel und Datenplatte über Software-iSCSI im Gast. Der größte Nachteil besteht in der recht hohen CPU-Belastung für das Gastsystem und damit den VMware ESX-Host, da die komplette iSCSI-Berechnung im Gastsystem stattfindet. Abhilfe schaffen hier aber vmxnet3-Adapter oder sogar VMdirectpath-I/O-Adapter.
387
8.5
8
Storage-Architektur
SWInititiator TCP/IPStack NIC-Treiber
VMkernel NIC-Treiber
Abbildung 8.9 Der Software-iSCSI-Adapter im Gast (oberer Bereich) wird komplett vom Gastbetriebssystem betrieben, die Netzwerkverbindung basiert auf dem Netzwerkkartentreiber des VMkernels (vSwitch + Uplink).
Host-Channel-Adapter (Infiniband) Im Infiniband Umfeld spricht man nicht von Host-Bus-Adaptern, sondern von Host-Channel-Adaptern. Diese sind die Initiatoren und dienen zum Zugriff auf die Storage-Systeme. Infiniband hat wesentliche Vorteile bei Latenzzeiten, Konsolidierung und Gesamtgeschwindigkeiten. Seit Version 3.5 des ESX-Servers werden HCAs der Firma Mellanox als Community-Support unterstützt, das heißt, der Hersteller übernimmt den Support für die VMware-Komponenten. Die Infiniband-Technik ist im hochpreisigen Segment angesiedelt und ist mit FC vergleichbar. AoE-(ATA over Ethernet-)Adapter ATA over Ethernet (AoE) ist definitiv der Außenseiter unter den Möglichkeiten einer Storage-Anbindung und wird nur vom Unternehmen CoRAID angeboten. ATA over Ethernet ist ein Storage-Protokoll auf Layer 2 (Ethernet-Frames) und wurde ursprünglich von dem Unternehmen Brantley Coile entwickelt. Da keine Protokolle höherer Layer wie IP, UDP oder TCP verwendet werden, ist AoE schlanker als iSCSI. Um AoE unter VMware ESX zu nutzen, müssen Sie spezielle Ethernet-Adapter der Firma CoRAID einsetzen und entsprechende Treiber im VMkernel einbinden.
388
Kommunikationsadapter
AoE ist im Niedrigpreissegment anzusiedeln und sogar günstiger als iSCSI und vom technischen Aufbau schneller. Außerdem dürfen Sie einen unfreiwilligen Sicherheitsaspekt nicht vergessen: Da AoE auf Ethernet-Frames basiert, sind die Pakete nicht routing-fähig, wodurch sie ein physischen Ethernet-Segment nicht verlassen können. FCoE-(Fibre-Channel over Ethernet-)Adapter Fibre-Channel over Ethernet (FCoE) ist ein Protokoll, das Fibre-Channel-Frames über den Standard-Ethernet-Bus transportiert. So kann trotz Nutzung von FibreChannel die 10-GBit–Ethernet-Technologie eingesetzt werden. Somit ist es dank FCoE auch möglich, existierende FC-Architekturen zu nutzen und gleichzeitig Teile von FC über die Ethernet-Komponenten zu betreiben. Dazu müssen Sie z. B. die Fibre-Channel-N_Port-IDs und die Ethernet-MAC-Adressen miteinander verbinden, was FCoE als Funktion liefert. Dies bietet den Vorteil eines sanften Übergangs oder Wechsels von FC nach Ethernet bei weiterer Nutzung von »Altlasten« im FC-Umfeld. Weitere Vorteile sind: 왘
Reduzierung der Anzahl von Anschlusskarten, die sich gegen Storage und Netzwerk verbinden müssen
왘
Reduzierung von Kabeln und Switches
왘
Reduzierung von Energiebedarf und Kühlungskosten
FCoE wurde schon sehr früh von NetApp und Cisco in Angriff genommen, daher sind deren Integrationen derzeit technologisch führend.
8.5.2
Target
Initiatoren nützen nichts, wenn kein Target zur Verfügung steht, um an der Kommunikation teilzunehmen. Als Target wird allgemein das Storage-System bezeichnet, allerdings ist technisch jeder Storage-Prozessor, eigentlich sogar jeder Storage-Prozessor-Port, für den Initiator ein gültiges Target. Schauen wir uns den Aufbau eines Storage genauer an. Systemaufbau (Storage-Prozessor) Als Storage-Prozessor wird allgemein die Intelligenz des Storage-Systems bezeichnet. Andere Begriffe hierfür sind Head (Kopf), Controller oder herstellerspezifische Angaben wie Slammer (Pillar Data Systems). Jeder Storage-Prozessor, kurz SP, kann über einzelne oder viele Ports verfügen, die entweder als Target zum
389
8.5
8
Storage-Architektur
Frontend (z. B. ESX-Server) oder selbst als Initiator ins Backend (weitere StorageSysteme – typischerweise bei Verwendung von Storage-Virtualisierung) dienen. Außerdem besitzen die SPs individuelle Technologien zur Leistungssteigerung, die auch speziell auf die Eigenschaften des Herstellers abgestimmt sind (z. B. Steigerung der Double-Parity-Geschwindigkeit). Dazu gehören auch leichter verständliche Konfigurationen wie die Anzahl des verfügbaren Lese- und Schreibcache. Abhängig von Hersteller, Modell und Typ verfügen die SPs über eine unterschiedliche Anzahl unterschiedlicher Technologien (FC, Ethernet (iSCSI, AoE, NFS ...), die die Leistungsfähigkeit und die Ausfallsicherheit für die angeschlossenen Server-Systeme bestimmen. Im Normalfall sind alle Anschlüsse eines SPs immer im active/active-Zustand, das heißt, jegliche Speicheranbindung ist gleichwertig und gleich performant. Sind mehrere SPs miteinander verbunden (interne Cluster), so ist die Architektur des Herstellers dafür ausschlaggebend, ob weiterhin alle Pfade aktiv sind oder manche passiv oder langsamer. Anschlüsse (FC, iSCSI, Infiniband etc.) Natürlich verfügt auch das Target über entsprechende Host-Bus-Adapter, die die entsprechenden Speicherprotokolle unterstützen müssen. Daher kommt es auch auf das jeweilige Speichersystem an, ob Fibre-Channel, iSCSI, Infiniband, FCoE oder AoE unterstützt wird. Die Anzahl der HBA-Ports bestimmt die Designmöglichkeiten und die Punkte Ausfallsicherheit und Lastverteilung. Die StorageAnschlüsse oder -Ports sind der sichtbare Storage-Teil aus VMware-ESX-Sicht, das heißt, die Pfade werden über Intitiator:Target-Portverbindungen dargestellt.
8.5.3
Logical Unit Number – LUN
Die Logical Unit Number oder kurz LUN ist das eigentliche Medium, das vom Initiator erkannt und genutzt wird. Statt einer physischen Festplatte kann dies auch eine logische Festplatte oder ein Bandlaufwerk sein. Grob ausgedrückt, spiegelt die LUN für den ESX die Festplatte im SCSI-Bus wieder, die entweder mit VMFS formatiert oder als Raw-Device-Mapping genutzt werden kann. Allerdings geht die LUN keine zwingende 1:1-Beziehung mit den physischen Festplatten ein, sondern kann auch eine logische Aufteilung darstellen. Legen Sie beispielsweise ein RAID-Set mit fünf Platten im RAID 5 an, können Sie dieses RAID je nach Speichersystem problemlos als zehn LUNs, auch mit unterschiedlicher Größe, herausgeben. Für das Initiator-System stellt sich diese LUN immer wie ein einzelnes nutzbares Medium zum Zugriff dar.
390
Kommunikationsadapter
Durch die Nutzung von LUN-IDs statt fester SCSI-IDs ist es möglich, weit mehr Geräte nach außen zu geben bzw. aus Initiatorsicht zu unterscheiden. LUNs werden durch eine ID von 0 bis 255 gekennzeichnet und bilden in Verbindung mit HBA und Target den Pfad im SCSI-Umfeld. Die LUN-ID spielte unter ESX 3 eine wesentliche Rolle, da sie bei der Erstellung der VMFS-Metadaten einbezogen wurde, um Snapshots von Original-Volumes zu unterscheiden. Mit ESX 3.5 Update 4 wurde die LUN-ID-Abhängigkeit bereits aufgebrochen, und seit vSphere wird der NAA-(Network Address Authority-) Namespace () oder, wenn das Storage-System die LU-WWN (World Wide Number) nicht liefert, der T10-Namespace genutzt.
8.5.4
Pfadmanagement (active/active, active/passive)
Die Verwaltung und Nutzungsmöglichkeiten der verschiedenen Pfade zur Kommunikation und Datenübertragung zwischen Server-System und Storage-System sind ein wesentliches Leistungsmerkmal in der Virtualisierung. Pfade sind alle Wege, die zwischen Initiator und Target möglich sind. Erfolgt keine Aufteilung (Zoning), so wären bei einem ESX-Host mit zwei Anschlüssen, der mit einem Storage-System mit zwei Anschlüssen über eine Fabric kommuniziert, vier Pfade sichtbar. Es wird grob zwischen active/active-, asymmetric active/active- und active/passive- sowie active/standby-Systemen unterschieden. Active/active Ein active/active-System bietet die Möglichkeit, auf allen Anschlussports des Storage Area Networks mit gleicher Geschwindigkeit und zur gleichen Zeit auf die vom Storage-System bereitgestellten Ressourcen zuzugreifen. Dies ermöglicht zum einen die Ausfallsicherheit über die Controller, zum anderen aber auch die gleichzeitige Nutzung mehrerer Pfade zu den LUNs, was eine höhere Leistung und Lastverteilung bedeutet. Beim Pfadmanagement beginnen viele Hersteller, die Tatsachen etwas zu beschönigen, da Mischvarianten existieren, die zwar das beste Preis-Leistungs-Verhältnis bieten, allerdings nicht dem entsprechen, was man erwarten würde. Wer sich mit den verschiedenen Speichersystemen und Controller-Architekturen auskennt, weiß mit Sicherheit bereits, wovon ich rede: asymmetric active/active oder pseudo-active/active.
391
8.5
8
Storage-Architektur
Abbildung 8.10
Active/active-Speichersystem
FCSwitches
VMware ESX H1 P0
FC-Storage C1 P0
F1 H2 P0
C2 P0
H1 P1
C1 P1
H2 P1
Abbildung 8.11
F2
C1
C2
C2 P1
active/active-Anbindung in der Praxis
Die meisten vollwertigen active/active-Systeme sind im High-End- und damit auch Höchstpreissegment zu finden, wie HDS USP, EMC DMX, 3PAR oder IBM DS8000. Eine Ausnahme existiert mit der Hitachi-AMS2000-Reihe (Hitachi Adaptable Modular Storage 2000 Family), die im Mid-Range-Bereich ebenfalls ein vollwertiges active/active liefert. active/passive Im Gegensatz zu active/active-Systemen können die Storage-Prozessoren der active/passive-Systeme nicht gleichzeitig auf eine RAID-Gruppe und deren LUNs zugreifen und diese im SAN bereitstellen. Der aktive Storage-Prozessor ist der Eigner (Owner) der LUN und steuert alle Zugriffe. Allerdings übernimmt der pas-
392
Kommunikationsadapter
sive Storage-Prozessor bei Ausfall des aktiven Storage-Prozessors dessen Funktion (Trespassing) und dessen RAID-/LUN-Zugriff. Dieser Trespassing-Vorgang kann mehrere Sekunden dauern.
Abbildung 8.12
Active/passive-Speichersystem
Daher ist nur ein manuelles Load-Balancing möglich, aber die Ausfallsicherheit ist gewährleistet. Normalerweise existieren Path-Management-Anwendungen wie EMC PowerPath/VE, um die Pfadnutzung zu optimieren und ein sogenanntes Path-Trashing zu verhindern. FCSwitches
VMware ESX H1 P0
FC-Storage C1 P0
F1 H2 P0
C2 P0
H1 P1
C1 P1
H2 P1
Abbildung 8.13 beachten
F2
C1
C2
C2 P1
active/active-Anbindung in der Praxis – Anbindung innerhalb des Storage
Path-Trashing bedeutet, dass auf eine LUN über den Pfad des passiven StorageProzessors zugegriffen wird. Dieser Zugriff kann allerdings nicht direkt an die
393
8.5
8
Storage-Architektur
LUN erfolgen, sondern entweder einen internen Umweg über den LUN-Eigner machen oder ist schlichtweg nicht möglich. Um dieses Path-Trashing zu verhindern, schalten viele Storage-Systeme den Eigner auf den zugreifenden Storage-Prozessor um, damit der Host bedient werden kann. Diese Schutzfunktion steht bei ESX-Hosts jedoch unter keinem guten Stern, da der gleichzeitige Zugriff vieler Hosts über verschiedene Pfade auf eine LUN möglich und realistisch ist. Dadurch schwenkt das Storage-System stetig den Eigner in Richtung Pfadnutzung, was die Leistung des Storage-Systems enorm senkt. Daher ist es sehr wichtig, die vorgeschriebenen Multipathing-Einstellungen und das Zoning im SAN zu beachten, um das Path-Trashing zu verhindern. Zumeist ist die Empfehlung bei active/passive-Systemen, MRU (Most Recently Used) zu nutzen. Pseudo-active/active Pseudo-active/active oder active/active asymmetric ist eine Zwitterform zwischen active/active und active/passive. Zwar bieten alle Frontend-Anschlüsse (in Richtung ESX-Host) die Möglichkeit, gleichzeitig auf die vom Storage-System bereitgestellten Ressourcen zuzugreifen, allerdings ist die Geschwindigkeit der einzelnen Anschlüsse unterschiedlich. Dies kommt daher, dass wie beim active/passive-System Ressourceneigner (= LUN-Owner) existieren, womit nur einer von zwei Storage-Prozessoren die volle Geschwindigkeit erreichen kann, während der zweite immer über den Eigner auf die LUNs zugreifen muss, was zu teilweise sehr deutlichen Leistungsengpässen führt. ESX 3.x hat keinerlei Möglichkeiten, die vom Storage kommenden Pfade zu klassifizieren und der Geschwindigkeit nach einzuordnen. vSphere geht dieses Problem mit 3rd-Party-Multipathing und ALUA an. Pseudo-active/active-Systeme sind im Entry- als auch im Mid-Range-Level zu finden. Ein kleiner Auszug, es sind wesentlich mehr: 왘
EMC CLARiiON (nur bei entsprechender Konfiguration, ansonsten active/ passive)
왘
HP EVA
왘
NetApp
왘
LSI und IBM DS (Ausnahme 8000er-Serie)
왘
Pillar Data Systems AXIOM
394
FC-Speichernetzwerk
Bei all diesen Systemen sollten Sie beim Einsatz von VMware ESX die Nutzung des langsameren (nicht-optimalen) Pfads möglichst vermeiden, entweder durch entsprechendes SAN-Design und Hilfsprogramme oder durch die Integration von 3rd-Party-Multipathing-Module (EMC PowerPath/VE). Außerdem bringt VMware vSphere das ALUA (Asymmetric LUN Unit Access) Path Management mit, das u. a. von NetApp-Systemen unterstützt wird. ALUA ermöglicht die Kommunikation zwischen Storage und ESX-Server, indem der Status der Pfade (active-optimized, active-unoptimized, unavailable, standby) übermittelt wird. Damit kann der ESX-Server die optimierten Pfade bevorzugt behandeln.
8.6
FC-Speichernetzwerk
Schauen wir uns den Aufbau des Fibre-Channel-Netzwerks einmal aus 10 000 Meter Höhe an, das heißt, wir kratzen nur die Oberfläche der Technologie und des Designs an. Ein sehr gutes tiefgehendes Buch zum Thema Storage nennt sich »Speichernetze« und ist beim dpunkt.verlag erschienen (ISBN: 978-3-89864-393-1).
HBA, vmhba33 10:00:00:00:c9:71:16:db
SP, 0 LUN, 5
SP
HBA
HBA
HBA
SP
10:00:00:00:c9:51:c1:ad
HBA
Part., 1
Abbildung 8.14
8.6.1 왘
ESXServer
ESXServer
Beispiel eines Fibre-Channel-Netzes mit den einzelnen Komponenten
Vorteile und Nachteile
Vorteile von FCP 왘
Hohe Geschwindigkeiten möglich
왘
Niedrige Latenzen
395
8.6
8
Storage-Architektur
왘
왘
Niedrige CPU Belastung am Host
왘
Loadbalancing und Failover einfach realisierbar
왘
Raw Device Mappings sind möglich
Nachteile von FCP 왘
Relativ hohe Kosten durch Infrastruktur
왘
Eventuell fehlendes Know-how
왘
Skalierbarkeitsprobleme mit LUN SCSI Locking bei VMFS (viele VMs pro Datastore)
왘
Umgang mit LUN Clones teilweise komplizierter als NFS (Resignatur)
왘
VMFS Datastores nicht verkleinerbar
왘
Thin Provisioning nicht per Default
8.6.2
Support Matrix
Gerade im Zusammenhang mit Fibrechannel sei ausdrücklich darauf hingewiesen, dass man sich unbedingt an die Supportmatrix aller beteiligten Hersteller halten sollte. Besonders zu berücksichtigen sind dabei folgende Hersteller: 왘
Serverhersteller
왘
HBA Hersteller
왘
Switch Hersteller
왘
Storage System Hersteller
Alle Komponenten müssen füreinander zertifiziert und freigegeben sein und auch auf die eingesetzten Software- und Firmware-Stände muss geachtet werden. Obwohl Fibrechannel seit vielen Jahren auf dem Markt etabliert ist, hat der Standard in Punkto Interoperabilität noch nicht ganz das Niveau von LAN Komponenten erreicht. Beim LAN geht man meist davon aus, dass jede LAN-Karte mit jedem Switch funktioniert, doch diese Selbstverständlichkeit ist im SAN noch nicht gegeben. Selbst zertifizierte HBA Karten können – je nach Firmware-Version – im einen Fall funktionieren, im anderen jedoch nicht. Wichtige Datenbank zu Herstellerfreigaben Es muss daher zwingend auf die Freigaben der Hersteller geachtet werden. VMware hat für vSphere eine eigene Datenbank für die Freigabe von Speichersystemen und I/ O Karten (SAN und LAN) im Internet bereitgestellt. Zu finden ist diese Freigabematrix unter: http://www.vmware.com/go/hcl
396
FC-Speichernetzwerk
Zusätzlich zur Freigabe der Hersteller sollte man darauf achten, dass die Anbindung des Storage-Systems zwingend redundant erfolgt (z. B. durch Multipath IO), und das Speichersystem selbst auch redundant ausgelegt ist (z. B. Clustering). Der Redundanzaspekt ist bei virtueller Infrastruktur genauso hoch oder noch höher als bei normaler Speicherzentralisierung – die Verfügbarkeit aller VMs hängt direkt von der Verfügbarkeit des Speichersystems ab.
8.6.3
Switch vs. Loop
VMware ESX unterstützt bis auf wenige Ausnahmen nur Switched-Fabric-Umgebungen im FC-Umfeld. Manche Systeme wie z. B. HP MSA können auch direkt an die FC-Adapter des ESX-Servers angeschlossen werden. Ein Arbitrated Loop, also die »Hub«-Version von Fibre-Channel, ist durch VMware nicht unterstützt, da es im FC-Umfeld als veraltet gilt.
8.6.4
Fabric
Fabric wird ein abgegrenztes Netzwerk genannt, das Intitiatoren (Hosts, Workstations) mit Targets (Storage-Systeme, Tape-Library) verbindet. Eine Fabric kann über mehrere FC-Switches verbunden sein. Zumeist werden zwei oder mehr Fabrics im FC-Umfeld eingerichtet, um die FC»Broadcasts« im kleinsten Rahmen zu halten (ähnlich Ethernet) und außerdem eine klare Trennung für Wartungsfenster herzustellen. Ein besonderer Vorteil der FC-Fabric ist, dass alle Geräte mit voller Bandbreite senden und empfangen können. Die HBAs der ESX-Server sind in diesem Fall mit einem oder mehreren Pfaden zu Fabric1 und Fabric2 verbunden, so dass im Wartungsfall einer Fabric die Verbindung zum Storage-System immer noch über die verbleibende Fabric zur Verfügung steht.
8.6.5
Verkabelung
Prinzipiell versucht man immer, über Kreuz zu verkabeln, was besonders bei active/passive- und asymmetric active/active-Systemen sehr sinnvoll ist, um die Zuordnung von aktiven Ports über die Fabrics zu verteilen. In Abbildung 8.15 ist dies bei der Verbindung zur EMC CX zu sehen. Setzt man ein vollwertiges active/ active-System, wie im Beispiel die HDS AMS2000, ein, so ist die Verkabelung eher Geschmackssache als wirklich notwendig.
397
8.6
8
Storage-Architektur
ESX
0
ESX
1
0
Fabric 1
0
1
0
EMC CX
Abbildung 8.15
8.6.6
1
Fabric 2
1
0
1
0
1
HDS AMS
Verkabelungsmöglichkeiten
Zoning
Zoning nennt sich die Aufteilung der FC-Ports eines FC-Switches, ähnlich der VLANs im Ethernet-Segment. Mittels Zoning erstellen Sie Gruppen, die eine Kommunikation zwischen den enthaltenen Ports oder WWNs ermöglichen. Das Erstellen von Zonen, die auf Ports basieren, nennt sich Port-Zoning, das heißt, man fasst FC-Ports zur Kommunikation zusammen. Damit können Sie auch einen Systemwechsel oder Hardwaretausch ohne erneute Änderung an den SAN-Zonen durchführen. Dies steht im Gegensatz zum WWN-Zoning, wo die WWN, also die eindeutige Identifikationsnummer des Ports oder des Systems, in Gruppen zusammengefasst wird. Dies hat den Vorteil, dass der HBA mit einer erlaubten WWN auf einem beliebigen Port auf dem FC-Switch angeschlossen werden kann. Kommt es jedoch zu einem Hardwareaustausch, müssen Sie auch das Zoning anpassen.
398
FC-Speichernetzwerk
Zumeist ist Port-Zoning wegen der vereinfachten Verwaltung bei Hardwareaustausch beliebter. Storage SPA 0
SPB
1
0
1
FC-Switch 1
HBA 1
FC-Switch 2
HBA 2
HBA 1
Server B
Server A Abbildung 8.16
HBA 2
Zoning-Beispiel
Abbildung 8.16 zeigt, dass jeweils zwei Zonen auf jedem FC-Switch angelegt werden müssen. Dies wäre bei Single-Initiator-Zoning wie in Tabelle 8.3 zu konfigurieren. FC-Switch
Zonenbeschreibung
FC-Switch 1
Server A, HBA 1 <-> Storage SPA Port 0 Server A, HBA 1 <-> Storage SPB Port 1
FC-Switch 1
Server B, HBA 1 <-> Storage SPA Port 0 Server B, HBA 1 <-> Storage SPB Port 1
FC-Switch 2
Server A, HBA 2 <-> Storage SPA Port 1 Server A, HBA 2 <-> Storage SPB Port 0
FC-Switch 2
Server B, HBA 2 <-> Storage SPA Port 1 Server B, HBA 2 <-> Storage SPB Port 0
Tabelle 8.3
Single-Initiator-Zoning
VMware empfiehlt übrigens mindestens vier Pfade zu einem Storage-System. Single-Initiator-Zoning Beim Single-Initiator-Zoning wird pro Zone immer nur ein Initiator mit einem oder mehreren Targets verbunden. Das heißt, ein ESX-Server mit zwei FCAnschlüssen muss in wenigstens zwei Zonen mit dem oder den Targets verbunden werden.
399
8.6
8
Storage-Architektur
Diese Form des Zonings ist beim Einsatz von VMware äußerst empfehlenswert, um FC-Broadcasts zu limitieren. Außerdem ist es nie sinnvoll, dass sich mehrere Initiatoren »sehen« und miteinander kommunizieren können. Ignorieren Sie das Single-Initiator-Zoning und erstellen Sie eine Zone mit vielen Initiators und Targets, so stört möglicherweise nur eine fehlerhafte Komponente jegliche Kommunikation in der Zone, was zum Ausfall der Storage-Verbindung führen kann.
8.6.7
Mapping
Unter dem Begriff Mapping versteht man die Zuordnung von Initiator-WWNs zu LUNs des Targets. Beim Mapping wird übrigens auch die LUN-ID festgelegt. Nur wenige StorageSysteme wie beispielsweise Dell Equalogic verwenden immer die LUN-ID0 (dafür verschiedene Targets). Das Mapping wird im Storage-System durchgeführt und sähe zum Beispiel wie in Tabelle 8.4 aus. Initiator
Target
LUN
LUN-ID
Zugriff
WWN ESX1
WWN Target
400 GB LUN
10
R/W
WWN ESX2
WWN Target
400 GB LUN
10
R/W
Tabelle 8.4
Mapping im Storage
Da viele Funktionen der virtuellen Infrastruktur nur bei gemeinsamem Zugriff mehrerer ESX-Server auf die gleichen LUNs möglich sind, ist es sinnvoll, die entsprechenden ESX-Server einer Gruppe zuzuordnen und diese beim Mapping zu verwenden. Damit ist gewährleistet, dass keine unterschiedlichen LUN-IDs für die gleiche LUN verwendet werden, was in VI3-Umgebungen schnell zum Chaos führt.
8.6.8
NPIV (N-Port ID Virtualization)
In der Historie des Fibre-Channel-Protokolls existierten immer Punkt-zu-PunktVerbindungen zwischen HBA und Switch (Netzwerk). Ein FC-Port hatte eine eindeutige WWPN (World Wide Port Number) und ein FC-Host eine eindeutige WWN (World Wide Number), über welche die Kommunikation adressiert wurde. Das Konzept war bis zur Einführung der Virtualisierung auch für die meisten Installationen absolut ausreichend.
400
iSCSI-Speichernetzwerk
Durch die Virtualisierung und die Mehrfachbelegung der FC-Ports durch virtuelle Maschinen wurde eine entsprechende Technologie gesucht und mit NPIV entwickelt. Somit war es auch problemlos möglich, einer virtuellen Maschine die Festplatten einer anderen virtuellen Maschine zuzuordnen. Aus Sicherheitsaspekten ist NPIV daher sinnvoll, da einer virtuellen Maschine eine LUN direkt zugeordnet werden kann. Nur der ESX-Host muss noch Read-only-Berechtigung besitzen. Dies verhindert Fehlkonfiguration oder nicht autorisierte Zugriffe auf die LUNs. Als Nachteil muss ganz klar aufgezeigt werden, dass die virtuelle Maschine »direkten« Zugriff auf den Storage bekommt und daher theoretisch per Schadsoftware Schäden anrichten könnte. NPIV bedeutet, dass, wenn HBA und Switch diese Technik unterstützen, mehrere WWPNs auf einem HBA-/Switch-Port genutzt werden können. VMware ESX unterstützt seit Version 3.5 die NPIV-Funktion, mit der Sie virtuellen Maschinen bis zu vier virtuelle WWNs zuweisen können. Allerdings ist die Funktion noch nicht komplett implementiert, das heißt, die virtuellen WWNs werden nach wie vor vom VMkernel verwaltet, da noch keine virtuellen FibreChannel-Karten im Gast möglich sind. Bis dahin hat die NPIV-Nutzung hauptsächlich Sicherheitsvorteile, Path-Management-Tools im Gast können nach wie vor nicht genutzt werden.
8.7
iSCSI-Speichernetzwerk
Das iSCSI-Speichernetzwerk, oder auch IP SAN genannt, ist neben dem FC SAN die beliebteste Methode, zentralen Speicher an die ESX-Server zu koppeln. Statt WWN-/WWPN-Adressen zur eindeutigen Identifizierung im Fibre-ChannelUmfeld werden MAC-Adressen, IP-Adressen und iNames genutzt. Während MAC-Adressen eher auf Ethernet-Level Verwendung finden, sind IP-Adresse und iName zum Mapping des Storage notwendig. Zur Absicherung der Netzwerke kann mit eigenen physischen Switches oder VLANs gearbeitet werden. Zur Authentifizierung wurde CHAP als Protokoll integriert, was eine erste Sicherheitshürde bietet, da nur Systeme mit dem gleichen Schlüssel miteinander kommunizieren können. Die Integration einer Gesamtverschlüsselung mit IPSEC ist jedoch nicht möglich. Das sehr oft gewählte Argument, die Ethernet-Technologie sei im Gegensatz zu Fibre-Channel bereits bekannt und damit sei auch die iSCSI-Einführung in jedem Fall kostengünstiger, kann nicht immer bestätigt werden.
401
8.7
Storage-Architektur
HBA, vmhba33 SP, 0
192.168.121.127
LUN, 5
192.168.121.151 iqn.1998-01.com.vmware:entity51-…
Abbildung 8.17
HBA
SP iName
iName
HBA
SP iName
iName
iName
HBA
Part., 1
iName
HBA
8
ESXServer
ESXServer
Komponenten im iSCSI-Netzwerk
Zuallererst ist es wichtig, sich mit der iSCSI-Technologie auseinanderzusetzen, mit ihren Anforderungen, Stärken und Schwächen. Zweitrangig ist die Verwaltbarkeit des Ethernet-Switches oder der IP-Adressen. Im direkten Vergleich halten sich die Neuerungen von Standard-Ethernet nach IP SAN oder FC SAN eigentlich die Waage, da in beiden Technologien viele neue Themen beachtet werden müssen. Setzen Sie bereits FC SAN ein, entfällt das Argument komplett. Die Aussage »kostengünstiger« hängt sehr stark von den Anforderungen des Unternehmens an Leistungsfähigkeit und Ausfallsicherheit ab. Dazu sollten Sie sich Abschnitt 8.7.3, »IP-SAN-Trennung«, näher anschauen.
8.7.1 왘
왘
Vorteile und Nachteile
Vorteile von iSCSI 왘
Mittlere bis hohe Geschwindigkeiten möglich, je nach 1GBit/s oder 10Gbit/s
왘
Mittelgute Latenzen
왘
Loadbalancing und Failover einfach realisierbar
왘
Raw Device Mappings sind möglich
왘
Sehr niedrige Einstiegskosten
왘
Relativ wenig Know How erforderlich
Nachteile von iSCSI 왘
402
höchste CPU Belastung am Host
iSCSI-Speichernetzwerk
왘
Skalierbarkeitsprobleme mit LUN Locking bei VMFS (viele VMs pro Datastore)
왘
Umgang mit LUN Clones teilweise komplizierter als NFS (Resignature)
왘
VMFS Datastores nicht verkleinerbar
왘
Thin Provisioning nicht per Default
8.7.2
Kommunikation
Die Kommunikation läuft aufgrund der SCSI-Verwandtschaft auch über Initiator und Target ab. Der Initiator kann entweder ein iSCSI-HBA, der Software-iSCSIInitiator des VMKernels oder der Software-iSCSI-Initiator im Gastbetriebssystem sein. In jedem Fall empfiehlt es sich, über den Einsatz von Jumbo-Frames (MTU bis 9 000 statt Standard MTU 1 500) nachzudenken, da dies eine Beschleunigung des Datenverkehrs aufgrund der größeren Netzwerkpakete und der sich damit verringernden Header-Informationen zur Folge hat. Generell wurde die iSCSI-Implementierung in vSphere gegenüber ESX 3.x wesentlich beschleunigt, was in Abbildung 8.18 sehr gut zu erkennen ist. iSCSI Max Gbps 9.1
.9 ESX 3.5
Abbildung 8.18
ESX 4.0
Verbesserungen mit ESX 4.0 im iSCSI-Netzwerk
In Kapitel 7, »Netzwerk«, finden sich weitere Informationen, wie die entsprechende Netzwerkkonfiguration aussehen kann.
8.7.3
IP-SAN-Trennung
Selbst kleine Umgebungen von 20 VMs bekommen bei entsprechendem Leistungsbedarf schnell große Probleme bei der Performance, das iSCSI-Netzwerk nicht physisch vom produktiven IP-Netzwerk (LAN) getrennt ist.
403
8.7
8
Storage-Architektur
In den meisten Fällen nützt auch keine Auftrennung mittels VLANs. Damit wäre zwar die Sicherheit der Pakete gewährleistet, aber nicht die Leistungsfähigkeit pro Port. Je nach eingesetzten Ethernet-Switches im LAN müssen Sie zusätzlich ein eigenes physisches Netzwerk mit eigenen Switches nur als Storage-Netzwerk aufbauen. Sie sollten unbedingt auf eine entsprechend leistungsfähige Switch-Architektur achten, damit die Backplanes der Switches nicht an ihre Grenzen stößt und es nicht zu Leistungsengpässen beim Betrieb der Netzwerkinfrastruktur. Dieses Thema sollten Sie auch sehr ernst nehmen, da es auch mit höherwertigen Switches im Preissegment von mehreren Tausend Euro zu erheblichen Problemen kommen kann. Zwei solcher Fälle sind bekannt: 1. Überbuchung Der sehr einfach zu erklärende Fall ist das Overbooking von Switch-Ports, das heißt, die Backplane des Switches verfügt nicht über ausreichend Leistung, um alle Frontports mit voller Bandbreite gleichzeitig zu bedienen. Schauen Sie sich beispielsweise einen 24-Port-Switch an, der nur mit 12-GBit-Backplane ausgestattet ist, entsteht ein Problem bei Volllast. 24 Ports Full Duplex bedeuten maximal 48 GBit Last, was auf der 12-GBit-Backplane nur zu einem Viertel abgedeckt wird. Daher ist jeder Port dreimal überbucht. 2. Lastverteilung Ein sehr unschönes und nur schwierig festzustellendes Problem ist die mangelhafte Lastverteilung mancher Ethernet-Switches, die bei Volllast mehrerer Ports nicht anteilig verteilen, sondern wahllos auf Ports Last zulassen und verteilen. Dies führt im schlimmsten Fall dazu, dass Anwendungen nicht genügend Bandbreite zur Verfügung haben und es zu Applikationsabbrüchen im Sekundenbereich kommt. Auch hier ein kleines Beispiel: Es ist ein iSCSI-Storage-System mit einem GBitPort auf einem Switch mit vier iSCSI Initiatoren (ESX-Server) angeschlossen, die miteinander kommunizieren. Der Port des Storage-Systems erhält 90 % Last (Utilization), allerdings schwankt die Kommunikation der vier Initiatorenports aufgrund der Lastverteilungsprobleme des Switches zwischen 20 und 80 %. Im Ergebnis kommt es zu Applikationsproblemen auf den virtuellen Maschinen des ESX-Servers mit der geringsten zugeordneten Priorität, da Pakete zu langsam verteilt oder sogar verworfen werden. Die Backplanes kostengünstigerer Switches sind einfach nicht auf die Volllast aller Ports, sondern nur eines Bruchteils der Portvolllast ausgelegt. Damit wür-
404
Network-attached Storage
den das LAN und das IP SAN sich gegenseitig stören, da die Switch-Backplane diese Leistung nicht erbringen kann. Selbst bei der Trennung der physischen Netzwerke mit eigenen Switches differenzieren die Leistungsanforderung und die Switch-Leistung stark voneinander. Nicht selten müssen daher Backbone-Switches angeschafft werden, um das iSCSI-Netzwerk, das zumeist höhere Anforderungen als die LAN-Kommunikation hat, vernünftig zu betreiben. Solche Leistungsprobleme sind nicht immer leicht erkennbar, stellen sich aber oft durch »Hänger« in virtuellen Maschinen dar. Diese Stopps der Applikation in einer VM führen von der Verlangsamung der Anwendung für den Benutzer bis hin zum sporadischen Absturz der VM, da die iSCSI-Informationen nicht schnell genug umgesetzt werden können. Daher ist es sehr wichtig, die Leistungsanforderungen genau zu bestimmen und ein entsprechendes Design der Ethernet-Infrastruktur aufzubauen. Sehr oft stellt sich heraus, dass sich Planungsschwächen viel schlimmer darstellen als bei Nutzung von FC SAN. Durch die Einführung von 10-GBit-Ethernet wird sich das Performance-Problem nochmals relativieren, wenn die Backplane der Ethernet-Switches entsprechende Leistung vorhält – wird empfehlen an dieser Stelle einen Blick auf die Switches von Arista Networks (http://www.aristanetworks.com). Übrigens findet sich eine sehr gute Abhandlung über die Möglichkeiten des iSCSI Netzwerkes und deren Implementierung auf dem Blog von Chad Sakac (Virtual Geek): http://virtualgeek.typepad.com/virtual_geek/2009/09/a-multivendor-post-onusing-iscsi-with-vmware-vsphere.html
8.8
Network-attached Storage
Vom notwendigen Aufbau des Netzwerks unterscheidet sich NFS nur unwesentlich von iSCSI, das heißt, auch hier sollte ein Speichernetzwerk dediziert genutzt werden, und der VMkernel stellt die Verbindung zum NFS-Storage her. Allerdings arbeitet NFS nicht blockorientiert, sondern dateiorientiert, NFS nutzt also kein VMFS im Backend. Die Erklärung liegt schon im Namen, »Network File System« (NFS). Im Endeffekt ist es dem Storage-System überlassen, welches Dateisystem im Hintergrund die Dateien verarbeitet und organisiert, für den ESX-Server ist nur interessant, dass über NFS-Version 3 mit ihm kommuniziert wird.
405
8.8
8
Storage-Architektur
NFS arbeitet im Gegensatz zu den blockorientierten VMFS-Datastores immer im Thin-Provisioning-Modus, das heißt, nur die real abgespeicherten Daten verbrauchen im NFS wirklich Festplattenplatz, unabhängig von der angegebenen vmdkFestplattendatei der virtuellen Maschine. Darüber hinaus ist es bei der Nutzung des standardisierten NFS-Protokolls möglich, von jedem anderen NFS-Client auf die NFS-Freigaben zuzugreifen, was Sicherungen sehr flexibel und einfach macht. Da auch das NAS Storage-System selbst in der Lage ist, die Daten einzusehen, existieren auch dort sehr mächtige Sicherungsmöglichkeiten (z. B. NetApp Filer). Ein weiterer Vorteil von NFS besteht darin, dass keine SCSI-Reservations auf dem kompletten Datastore (LUN) ausgeführt, sondern nur sogenannte File-Locks angewendet werden. Dadurch werden nur die im Zugriff befindlichen Dateien gesperrt und nicht die komplette LUN, was NFS eine sehr gute Flexibilität und Skalierbarkeit einbringt. Diese Vorteile werden besonders in großen VDI-(Virtual Desktop Infrastructure-) Umgebungen geschätzt, wodurch sich NFS in diesem Anwendungsbereich auch durchsetzt. Kommunikation Schaut man sich die Kommunikation von NFS an, so handelt es sich um ein Client-Server-Protokoll, das heißt, der NFS-Client verbindet (authentifiziert) sich mit dem NFS-Server und beginnt eine Standardkommunikation, die für NFS-Version 3 vordefiniert ist. Ein sehr wichtiger Aspekt ist dabei die Nutzung von IPAdressen oder DNS-Namen, wobei IP-Adressen meist bevorzugt werden, um die Abhängigkeit vom DNS-Server zu minimieren. Da es bei NFS kein Multipathing gibt, sind Sie auf die Möglichkeiten des StorageSystems angewiesen, intern Cluster abzubilden. Dies ist meist über Round-RobinMechanismen MAC-Adressen-basiert oder IP-basiert möglich. Das Gleiche gilt für die Load-Balancing-Möglichkeiten. Ein großes Problem ist hierbei, Ausfallsicherheit und Lastverteilung abzuwägen, wie es bei den blockbasierten Protokollen durch Multipathing möglich ist. Hier entscheiden die Anzahl der Netzwerkports und die Möglichkeiten der EthernetSwitches darüber, wie weit Sie gehen können. Auch hier brilliert Arista Networks mit ihren kostengünstigen 10-GBit-Switches, die eine Port-Aggregation über Switch-Grenzen erlauben. Dies ist bei anderen Herstellern nur mit vielfach teureren Switches möglich. In jedem Fall empfiehlt es sich, über den Einsatz von Jumbo-Frames (MTU bis 9 000, statt Standard MTU 1 500) nachzudenken, da dies aufgrund der größeren Netzwerkpakete und der sich damit verringernden Header-Informationen eine Beschleunigung des Datenverkehrs zur Folge hat.
406
Network-attached Storage
192.168.121.220
NIC
192.168.121.10
SP
NIC
NIC
NIC
SP
Abbildung 8.19
ESXServer
ESXServer
Komponenten bei NFS-Nutzung
VMkernel NFS-Client TCP/IPStack NIC-Treiber
Abbildung 8.20
NFS-Modul VMkernel
Die Kommunikation findet über den VMkernel statt, der über das IP-Hashbasierte Load-Balancing-Verfahren die Last verteilen kann. Lastverteilung unter NFS Eine Lastverteilung mit NFS ist auch bei IP-Hash-basiertem Load Balancing nur möglich, wenn dem ESX-Server mehrere IP-Adressen auf NFS-Server-Seite angeboten werden. Ansonsten würde der VMkernel-Port immer nur einen Adapter nutzen, da immer die gleiche Netzwerkkarte pro IP-Verbindung verwendet würde.
407
8.8
8
Storage-Architektur
Durch die Nutzung von 10-GBit-Netzwerkkarten sind mit NFS enorme Geschwindigkeiten bei Datendurchsatz und Latenzzeiten möglich. Dies bringt weitere Marktdurchdringung für NFS und Entspannung, was die Verwendung von Load-Balancing auf ESX-Seite angeht.
NFS-Client TCP/IPStack NIC-Treiber
VMkernel NIC Treiber
Abbildung 8.21
NFS im Gastbetriebssystem
Selbstverständlich ist es auch möglich, NFS-Systeme aus dem Gastbetriebssystem anzubinden und nur für eine dedizierte virtuelle Maschine zu nutzen. Der Netzwerkverkehr liefe in diesem Fall über die Portgruppe der virtuellen Netzwerkkarte ab. Um mehr Performance im Gast zu erreichen, müssten Sie mit mehreren virtuellen Netzwerkkarten und mehreren NFS-Servern arbeiten. Vorteile und Nachteile 왘
Vorteile von NFS 왘
Mittlere bis hohe Geschwindigkeiten möglich, je nach 1GBit/s oder 10Gbit/s
왘
Mittelgute Latenzen
왘
Sehr niedrige Einstiegskosten
왘
Relativ wenig Know-how erforderlich
왘
VMFS Datastores sehr einfach verkleinerbar
왘
Thin Provisioning per Default
왘
Sehr einfaches Management
408
VMware-Storage-Architektur
왘
왘
Zugriff auf die VMs von jedem NFS möglich
왘
Keine VMFS Skalierungsprobleme
Nachteile von NFS 왘
Raw Device Mappings sind nicht auf NFS möglich
왘
Loadbalancing und Failover schwieriger realisierbar, je nach eingesetzter LAN-Infrastruktur
왘
Wenige Sicherheitsfunktionen im Protokoll
왘
Bei Nutzung von 1 GBit geringere Geschwindigkeit als FC
8.9
VMware-Storage-Architektur
VMware besitzt seit der ersten Version des ESX-Servers eine eigene StorageArchitektur und -Implementierung. Diese besteht aus den verschiedenen Storage- und Netzwerkstacks sowie eigenen Multipathing-Möglichkeiten. Außerdem wird das Dateisystem VMFS stetig weiterentwickelt und ist seit dem ersten vSphere-Release in Version 3.33 verfügbar. Wer sich für eine Performance-Studie zwischen VMware ESX 3.5 und ESX 4 bzw. zwischen FC, iSCSI und NFS unter VMware interessiert, sollte sich dieses Whitepaper einmal näher anschauen: http://www.vmware.com/files/pdf/perf_vsphere_storage_protocols.pdf
8.9.1
VMkernel-Storage-Stack
Der VMware-Storage ist zuständig für die Anbindung der verschiedenen Datenträger, die Verwendung von SCSI-Protokollen und NFS sowie das Multipathing. Service Console Während unter ESX 3.x die Service Console benötigt wurde, damit der SoftwareiSCSI-Initiator korrekt funktionierte, entfällt diese Notwendigkeit mit ESX 4. Damit wurde die Technik, die bei ESXi von Beginn an eingeführt wurde, nun auch auf den ESX-Server übertragen. Dies vereinfacht viele virtuelle Infrastrukturen, da es zuvor immer ein Problem war, ein ordentliches Netzwerkdesign zu erstellen, weil die Service Console für die iSCSI-Authentifizierung und -Steuerung zuständig war und der VMkernel die iSCSI-Datenpakete übernahm. Deshalb mussten sowohl VMkernel als auch Service Console auf den Storage Netzwerkzugriff besitzen. Aus diesem Grund wurden entweder mehrere Service-
409
8.9
8
Storage-Architektur
Console-Ports angelegt (eine im Storage-Netzwerk) oder man arbeitete über Router, was auch unschön war, da solch ein Weg aus einem Managementnetzwerk in ein Storage-Netzwerk führte. Diese Probleme gehören nun der Vergangenheit an, und der VMkernel allein ist für die Kommunikation mit dem iSCSI-Storage zuständig. Speicherstack VMKernel VMware ESX besitzt einen eigenen SCSI-Stack, der die Nutzung von lokalem und entferntem Storage (iSCSI, FC) möglich macht. Dieser Stack verfügt auch über eigene Queuing-Mechanismen und eigene Multipathing-Funktionen. Seit vSphere ist es allerdings auch für Dritthersteller möglich, eigene MultipathingFunktionen in den VMkernel zu integrieren. Dazu wird die PSA (Pluggable Storage Architecture) genutzt. TCP/IP-Protokoll VMKernel (VMotion, iSCSI) Der VMkernel enthält neben dem Storage-Stack auch einen Netzwerkstack, der das TCP/IP-Protokoll unterstützt. Unter diesem VMkernel-Stack kommunizieren unter ESX VMotion Fault-Tolerance, NFS und die Software-iSCSI-Funktion, unter ESXi zusätzlich das Management (unter ESX übernimmt dies der Service-ConsolePort). Da es sich bei TCP/IP um ein Standardprotokoll handelt, funktionieren auch Teile der Denial-of-Service-Attacken gegen dieses Protokoll. Daher sollten Sie diese Ports immer vom Netzwerk der virtuellen Maschinen und des produktiven LANs trennen. Dies ist z. B. mit VLANs für VMotion, iSCSI und Fault-Tolerance möglich, ohne an Flexibilität bei den physischen Adaptern zu verlieren. Multipathing VMware setzte bis vSphere komplett auf die eigenen Multipathing-Möglichkeiten, das heißt, wenn mehrere Pfade zum Storage erkannt wurden, entschied VMware durch eigene Komponenten, wie damit umzugehen war. Zu den Multipathing-Komponenten gehören MPP (Multi-Path-Plug-in, VMwareeigene und 3rd-Party-Plug-in-Kontrolle), NMP (Native-Multipathing-Plug-in, VMware-eigene Pfadkontrolle), SATP (Storage-Array-Type-Plug-in, Failover-Kontrolle und Überwachung) und PSP (Path-Selection-Plug-in, Lastverteilung, Pfadauswahl anhand Fixed, MRU oder RoundRobin).
410
VMware-Storage-Architektur
Abbildung 8.22
Multipathing unter vSphere
Multipathing-Vorgang (Weg der I/Os) 1. NMP-Modul ruft das entsprechende PSP-Modul auf (Fixed, MRU oder RR). 2. PSP wählt den optimalen physischen Pfad aus, um die I/O zu versenden. 3. Wenn die I/O-Operation erfolgreich ist, gibt NMP dies zurück. 4. Wenn die I/O-Operation fehlschlug, wird ein SATP ausgewählt. 5. Wenn SATP den I/O-Fehler erkennt, wird bei Notwendigkeit ein inaktiver Pfad aktiviert. 6. PSP sendet die I/O über den neuen Pfad. Multipathing-Module Führen Sie auf der Service Console (oder im Remote CLI) des ESX-Hosts den Befehl esxcli nmp satp list aus, so erhalten Sie eine Übersicht über die verschiedenen integrierten Module und deren Funktion. Modulname
Standard-PSP
VMW_SATP_ALUA_CX
VMW_PSP_FIXED Supports EMC CX that use the ALUA protocol
VMW_SATP_SVC
VMW_PSP_FIXED Supports IBM SVC
VMW_SATP_MSA
VMW_PSP_MRU
VMW_SATP_EQL
VMW_PSP_FIXED Supports EqualLogic arrays
VMW_SATP_INV
VMW_PSP_FIXED Supports EMC Invista
VMW_SATP_SYMM
VMW_PSP_FIXED Supports EMC Symmetrix
VMW_SATP_LSI
VMW_PSP_MRU
VMW_SATP_EVA
VMW_PSP_FIXED Supports HP EVA
Tabelle 8.5
Beschreibung
Supports HP MSA
Supports LSI and other arrays compatible with the SIS 6.10 in non-AVT mode
VMware-Multipathing-Module
411
8.9
8
Storage-Architektur
Modulname
Standard-PSP
Beschreibung
VMW_SATP_DEFAULT_AP VMW_PSP_MRU
Supports non-specific active/passive arrays
VMW_SATP_CX
VMW_PSP_MRU
Supports EMC CX that do not use the ALUA protocol
VMW_SATP_ALUA
VMW_PSP_MRU
Supports non-specific arrays that use the ALUA protocol
VMW_SATP_DEFAULT_AA VMW_PSP_FIXED Supports non-specific active/active arrays VMW_SATP_LOCAL Tabelle 8.5
VMW_PSP_FIXED Supports direct attached devices
VMware-Multipathing-Module (Forts.)
Die Multipathing-Policies Fixed und Most Recently Used (MRU) existierten schon seit vielen Versionen, während Round-Robin mit VMware ESX 3.5 experimentell Einzug erhielt. Seit vSphere ist Round-Robin offiziell unterstützt. Abhängig vom Storage-Hersteller ist die entsprechende Policy auszuwählen, allerdings hat VMware auch eigene Tabellen hinterlegt, so dass bei vielen Storage-Systemen automatisch das korrekte Multipathing genutzt wird.
Abbildung 8.23
Multipathing von VMware
Fixed Der angegebene bevorzugte Pfad wird immer genutzt, bis er ausfällt. Dann wird auf einen noch verfügbaren Pfad gewechselt. Ist der bevorzugte Pfad allerdings wieder online, so wird er direkt wieder genutzt. Fixed empfiehlt sich für manuelle Lastverteilung zwischen den Pfaden, birgt aber die Gefahr des »Ping-Pongs«, wenn der bevorzugte Pfad immer einmal wieder ausfällt, z. B. aufgrund eines Portproblems. Fixed Multipathing ignoriert ALUA (Asymmetric Logical Unit Access). MRU Most Recently Used empfiehlt sich bei den meisten active/passive-Storage-Systemen. Der große Nachteil an MRU ist, dass immer nur ein Pfad genutzt wird und Sie somit kein manuelles Load-Balancing einstellen können. MRU hat jedoch den Vorteil, dass immer nur beim Ausfall eines Pfades auf einen noch aktiven Pfad gewechselt und dort geblieben wird. Dadurch sind fehlerhafte Ports nicht so dra-
412
VMware-Storage-Architektur
matisch wie bei Fixed. MRU ist ALUA-fähig und ist damit Fixed Multipathing bei asymmetric active/active-Systemen vorzuziehen. Round-Robin Die neueste Form der Pfadverwaltung ist Round-Robin, das auf den Möglichkeiten eines active/active-Arrays aufsetzt. Der Pfad wird anhand der Anzahl von durchgeführten I/O-Operationen oder Datendurchsatz stetig gewechselt, wodurch eine sehr effektive Lastverteilung entsteht. Round-Robin ist bei active/ passive nicht sinnvoll einsetzbar und wird daher nicht empfohlen. Handelt es sich um einen asymmetric active/active-Storage, so erkennt RoundRobin die optimalen Pfade mittels ALUA und benutzt die nicht-optimalen nur im Notfall. 3rd-Party-Multipathing vSphere bringt eine komplett neue Storage-Architektur mit, die es Drittherstellern erlaubt, eigene Multipathing-Plug-ins zu integrieren. Dies ist aufgrund auch von großem Vorteil, da der Storage-Hersteller seine eigenen Produkte am besten kennt. So können Sie mittels Hersteller-Multipathing-Plug-ins ein Storage-System wesentlich performanter und optimaler anbinden. Zur Drucklegung des Buches war PowerPath/VE vom Hersteller EMC verfügbar. Außerdem hat VMware den Standard ALUA als Multipathing-Möglichkeit implementiert, auf den beispielsweise NetApp setzt. SCSI-Timeout Aufgrund des möglichen Zeitverzugs beim Ausfall des aktiven Pfades und des damit verbundenen Wechsels auf einen neuen Pfad wird empfohlen, die SCSITimeout-Zeiten in Windows-Gastbetriebssystemen zu kontrollieren und gegebenenfalls neu zu setzen. Dies ist im VMware-Knowledge-Base-Artikel 1014 beschrieben: http://kb.vmware.com/kb/1014 Der folgende Registry-Wert wird bei der Installation der VMware Tools automatisch auf 60 gesetzt und ist im Standard 30: HKLM/System/CurrentControlSet/Services/Disk/TimeOutValue (REG_ DWORD /180 decimal)
Unter Linux müsssen Sie nach der VMware-Tools-Installation eine udev-Datei manuell umkonfigurieren. VMware ESX 4 setzt den Wert direkt auf 180, was im Normalfall ausreicht. Möchten Sie man den Wert ändern, ist die Datei /etc/udev/
413
8.9
8
Storage-Architektur
rules.d/99-vmware-scsi-udev.rules anzupassen, indem Sie den echo-Wert in den RUN-Zeilen manipulieren: RUN+="/bin/sh -c 'echo 180 >/sys$DEVPATH/device/timeout'"
Alternativ kann man die Timeouts auch bei RedHat basierten Systemen unter /sys/block//device/timeout finden.
8.9.2
Festplattendateien
Virtuelle Maschinen ohne Daten sind selten, daher sind die genutzten Festplattendateien natürlich äußerst wichtig, und Sie müssen wissen, wie diese angebunden werden und funktionieren. Die Standardfestplatten unter vSphere sind im VMFS-Umfeld vom Typ Thick und im NFS-Umfeld vom Typ Thin. Allerdings sind die Thin-Festplatten seit vSphere auch auf VMFS-Partitionen unterstützt. 2gbsparse 2gbsparse-Festplattendateien sind aus den VMware-Versionen Workstation und Server bekannt. Die Festplatte ist in maximal 2 GB große Stücke eingeteilt und wächst mit ansteigendem Datenvolumen in der Festplattendatei mit, das heißt, eine virtuelle 40-GB-Festplatte benötigt als 2gbsparse nicht zwingend reale 40 GB auf dem Datenspeicher, sondern nur die wirklich verbrauchten Daten. monolithic sparse Eine Monolithic-sparse-Festplatte wächst wie 2gbsparse dynamisch, ist allerdings die Festplatte nicht in 2-GB-Dateien aufgeteilt, sondern existiert als eine einzelne Datendatei. Dieses Format hat Nachteile in Sachen Mobilität, da bei 2gbsparse beispielsweise eine DVD als Backup-Medium genutzt werden könnte. Eine Monolithic-sparse-Platte hingegen kann sehr groß werden und müsste demnach umkonvertiert werden. Unter VMware ESX nennen sich diese Festplatten Thin. monolithic flat Monolithic-flat-Festplattendateien sind leistungsfähiger als die Monolithicsparse-Festplatten. Sie werden bei dem Anlegen in voller Größe erstellt, das heißt, eine 40-GB-Festplattendatei verbraucht 40 GB auf dem Datenspeicher. Außerdem ist die Datei nicht aufgeteilt, sondern als eine Datei vorhanden. Des Weiteren existieren Festplattentypen, die nicht als Datei auf einem VMFS oder NFS angelegt werden, sondern als Verlinkung zu einer LUN über den direkten SCSI-Weg dienen. Das heißt, die LUN steht roh (Raw-Device-Mapping) der virtuellen Maschine zur Verfügung und kann nach Belieben genutzt werden (z. B.
414
VMware-Storage-Architektur
mit NTFS-Formatierung bei einer Windows-VM). Bei diesen Festplattentypen wird zwischen Physical und Virtual Compatibility Mode unterschieden. Physical wird nur gebraucht, wenn Cluster zwischen virtuellen und physischen Systemen benötigt werden. Zu jeder Festplattendatei existiert seit Version 3.x des VMware ESX-Servers eine Beschreibungsdatei, die folgende Informationen enthält (Auszug): # Disk DescriptorFile version=1 CID=6a5e7aa0 parentCID=ffffffff createType="vmfs" # Extent description RW 8388608 FLAT "test4mig2-flat.vmdk" 0 # The Disk Data Base #DDB ddb.adapterType = "lsilogic" ddb.geometry.sectors = "63" ddb.geometry.heads = "255" ddb.geometry.cylinders = "522" ddb.virtualHWVersion = "3"
Die Einträge haben folgende Bedeutung: 왘
version version gibt die Version der Beschreibungsdatei an. Derzeit verwendet
VMware immer die Version 1. 왘
CID
Einmalig berechneter Zufallswert, den VMware als ID zur internen Zuordnung nutzt. 왘
parentCID
Anhand dieser Identifikation wird bei Snapshots die Eltern-Festplatte erkannt. Existiert kein Snapshot oder ist es die Eltern-Festplatte, enthält parentCID immer den Wert ffffffff. 왘
createType
Dieser Parameter beschreibt den Dateityp. Es existiert knapp ein Dutzend verschiedener Werte, wenn man alle VMware-Produkte betrachtet. Im VMwareESX-Umfeld ist dieser Wert meist vmfs. Versuchen Sie bitte nicht, manuelle Änderungen am createType vorzunehmen, da dies die Festplatte unbenutzbar machen kann.
415
8.9
8
Storage-Architektur
Datentypen VMware ESX unterscheidet beim Anlegen zwischen vier Typen: 왘
thick
왘
zeroedthick
왘
eagerzeroedthick
Diese drei Dateitypen sind nicht durch die Konfigurationsdatei voneinander zu unterscheiden. Alle drei Typen sind monolithic flat, das heißt, auf der Festplatte wird die volle Dateigröße verbraucht. 왘
thin
Dieser Dateityp ist ein Monolithic-sparse-Typ und wächst daher beim Beschreiben dynamisch. Thin-Festplatten-Dateien erkennen Sie an zwei Eigenschaften erkennen: 왘
Der Wert ddb.thinProvisioned = "1" steht in der Konfigurationsdatei.
왘
Die Dateigröße durch Anzeige mit ls -sh "disk-flat.vmdk" oder stat "diskflat.vmdk" ist kleiner als die angelegte Größe. Ein ls -lah bringt die angelegte Maximalgröße und nicht die reale Größe auf der Festplatte zum Vorschein.
왘
Extent description
Der verwendete Festplattentyp hat direkte Auswirkungen auf die Extent description-Passage. 왘
Die Zeilen sind nach dem folgenden Schema aufgebaut: Zugriffsmodus, Festplattengröße in Sektoren, Typ des Extents, Ort der Festplattendatei.
왘
Die Festplattengröße in Sektoren wird bei der Verwendung der Festplattendateien durch das VMware-Server-Produkt benötigt. Diese Information ist vor allem dann wichtig, wenn der VMware-Server ESX-2-Festplattendateien mit nutzen soll oder die Beschreibungsdatei verlorenging. Dieser Wert wird folgendermaßen berechnet:
왘
Größe in Sektoren = (VMDK-Größe in Bytes) / Bytes pro Sektor (immer 512) Bei einer 2,7-GB-Festplatte wäre das beispielsweise: (2902327296 – 512) / 512 = 5668607 Im Folgenden werden Beispiele für zwei Arten von Festplatten gezeigt:
왘
monolithicFlat RW 8388608 FLAT "test4mig2-flat.vmdk" 0
왘
2gbMaxExtendSparse RW 4192256 SPARSE "sol10-hdd1-s001.vmdk" RW 4192256 SPARSE "sol10-hdd1-s002.vmdk" RW 4192256 SPARSE "sol10-hdd1-s003.vmdk" RW 4192256 SPARSE "sol10-hdd1-s004.vmdk" RW 8192 SPARSE "sol10-hdd1-s005.vmdk"
416
VMware-Storage-Architektur
왘
Disk Data Base
Der Disk Data Base-Abschnitt beschreibt die Festplattengeometrie, die Hardwareversion und den Festplattenadaptertyp. 왘
ddb.adapterType: Festplattenadapter, kann buslogic, lsilogic etc. sein.
왘
Die weiteren Geometriedaten können Sie sehr leicht anhand von Tabelle 8.6 und der folgenden Formel berechnen (Bytes pro Sektor ist immer gleich 512): Cylinders = (VMDK-Größe in Bytes) / (Heads * Sectors * Bytes pro Sektor)
왘
Der Parameter ddb.virtualHWVersion beschreibt die Version der VMwarePlattform, unter der die Festplatte genutzt wird.
Format
Vorteile
Thin
왘
왘
Effektive Speicherplatznutzung schnelle Erstellung der Festplattendateien
Nachteile 왘
왘 왘
Thick
왘
왘
왘
zeroedthick
왘 왘
왘
eagerzeroedthick
왘
왘
왘
Tabelle 8.6
Speicherplatz im Datastore zu überwachen, da dieser leicht überläuft Belastung des Host-System häufige SCSI-Reservierungen bei Datenwachstum im Gast
keine Überprovisionierung des Datastore möglich keine SCSI-Reservierungen bei Datenwachstum im Gast schnelle Erstellung der Festplattendateien
왘
Teurer Speicherplatz geht verloren, bei geringem Füllgrad der Gast-Festplatten Daten gefüllt sind.
gleiche Vorteile wie thick Überschreiben eventuell vorhandener Altdaten beim ersten Blockzugriff Standardformat für thick
왘
gleiche Nachteile wie thick Theoretisch ist ein Data-Leaking möglich, das heißt, Altdaten könnten gelesen werden. Derzeit sind allerdings keine Fälle bekannt.
gleiche Vorteile wie thick, bis auf die Geschwindigkeit der Plattenerstellung Überschreiben der kompletten Festplatte mit Nullen kein Data-Leaking möglich
왘
왘
왘
왘
gleiche Nachteile wie thick Erstellung der Festplattendatei dauert sehr lange. Thin-Provisioning-Effizienz im Storage kann deutlich gestört werden.
Festplattenformate im Vergleich
Thin Provisioning und Thin Provisioning Man muss genau wie bei den Snapshots ganz klar zwischen Thin Provisioning im VMware-Umfeld und Thin Provisioning im Storage-Umfeld unterscheiden. Aus
417
8.9
8
Storage-Architektur
Performance-Gründen sind zweifellos die Thin-Provisioning-Möglichkeiten des Storage-Systems (falls vorhanden) vorzuziehen.
Abbildung 8.24
Thin Provisioning unter VMware
Thin Provisioning ist allerdings unabhängig von der ausführenden Komponente (VMkernel, Storage) schnell erklärt: Legen Sie eine Festplatte von 40 GB an und werden nur 20 GB Daten im Gast generiert, so sorgt Thin Provisioning dafür, dass die 40-GB-Festplatte physisch nur 20 GB belegt. Damit können Sie die Storage-Effizienz deutlich steigern, da eine einfachere Vergabe von Storage möglich ist und sogar eine Überbelegung, das heißt, es wird mehr Storage verwendet als physisch vorhanden. Letzteres birgt natürlich auch die Gefahr, dass der Datastore (VMware) oder die physischen Kapazitäten (Storage-System) überlaufen und es zu massiven Problemen kommt. Dies kann bis zu Datenverlust und Systemausfällen führen, weswegen es äußerst wichtig ist, die Plattenkapazitäten zu überwachen, wo Thin Provisioning aktiviert ist. In diesem Moment sollte auch direkt klar werden, warum es sehr problematisch wäre, Thin Provisioning auf zwei Ebenen (VMware und Storage) gleichzeitig zu nutzen.
418
VMware-Storage-Architektur
Es gibt allerdings mehr zu beachten als nur die Verwaltung. Thin Provisioning belastet zwangsweise das ESX-Host-System mehr als Thick-Festplatten, da diese Festplattendateien mit den Daten wachsen, das heißt, das ESX-System muss sich neben dem Schreiben der Daten auch um das Wachstum kümmern. Dieses Wachstum führt auch zu SCSI-Reservations, was vor allem bei der Verwendung älterer VMFS-Versionen sehr problematisch wird, wenn diese zu oft vorkommen. Mit VMFS Version 3.31 zeigt ein Dokument von VMware, dass die SCSI Reservations nur zu einer minimalen Beeinträchtigung nahe 0 % führen. Weiterhin kommt es bei der Nutzung von Thin Provisioning zur Fragmentierung im VMFS. Auch hier hat VMware in einem internen Test angegeben, dass die Fragmentierung nur in seltenen Fällen zum Leistungsverlust führen kann. Im Normalfall, fangen Storage System (Cache) und die VMFS Blockgröße (1 MB und höher) die zumeist kleinen I/O (4 – 64 KB) Anfragen ab. Damit geht VMware nicht davon aus, der Fragmentierung entgegen wirken zu müssen. Formatierung mit Nullen Ein Problem, das jede Thin-Provisioning-Implementierung betrifft, sind Formatierungsvorgänge, bei denen Nullen geschrieben werden, das heißt, obwohl keine Nutzdaten geschrieben werden, entstehen trotzdem Daten. Bei VMwareThin-Provisioning-Festplatten führt dies direkt zur enormen Ineffizienz, da die Festplatte nach einiger Zeit in voller Größe auf dem Datastore liegt, weil ja alle Daten mit Nullen geschrieben wurden. Durch Thin Provisioning wird das Problem noch schlimmer, da die Festplatte langsam wächst (MB-Bereich) und bei jedem Wachstum eine SCSI-Reservation ausführt. Dies führt zur Verlangsamung des Formatvorgangs und zur Belastung aufgrund der vielen SCSI-Reservations. Dies ist mit dem Wachstum von Snapshot-Dateien zu vergleichen. Viele Storage-Systeme beginnen damit, genau diese Nullen zu erkennen, und begegnen dem Problem auch, indem sie die unnötig verbrauchten Kapazitäten nachträglich wieder freigeben (z. B. 3PAR, HDS) oder schon direkt beim Schreiben erkennen und ignorieren (z. B. 3PAR, IBM SVC, Datacore). Datenwachstum Findet ein Datenwachstum durch Generierung neuer Daten im Gast statt, so wächst die Thin-Festplatten-Datei mit an. Werden Daten gelöscht, so schrumpft sie allerdings nicht automatisch. Das gleiche Problem findet sich auch bei der Verwendung von VCB oder den Kopiervorgängen mit Storage VMotion. Geschriebene Daten müssen kopiert werden. Da viele Dateisysteme die Daten nicht wirklich löschen, sondern nur als gelöscht markieren, befindet sich die Festplattendatei immer nur im Wachstum. Das Gleiche gilt übrigens auch für die Formatierung.
419
8.9
8
Storage-Architektur
VMware hat von außerhalb des Gastes keine Möglichkeit zu erkennen, welche Daten gelöscht wurden. Dies ist nur im Gast über die VMware Tools möglich.
Abbildung 8.25
Shrink/Verkleinerung mittels VMware Tools im Gast
In den Eigenschaften der VMware Tools befindet sich allerdings ein Reiter Verkleinern oder Shrink, der es ermöglicht, die nicht genutzten Datenbereiche so zu bearbeiten, dass die vmdk-Datei mittels Storage VMotion oder auch VCB wieder kleiner wird, da die vormals als gelöscht markierten Daten nun wirklich gelöscht sind. In diesem Zusammenhang ist auch Defragmentierung im Gast sehr interessant. VMware-Tools-Shrink-Funktion und Thin-Festplatten Die VMware-Tools-Shrink-Funktion kann leider nicht auf Thin-Festplatten ausgeführt werden. Möchten Sie diese Funktion nutzen, um ungenutzten Plattenplatz nochmals freizugeben, müssen Sie auf die Festplatte erst ein Inflate über den Datastore-Browser durchführen oder per Storage VMotion auf thick migrieren. Danach funktioniert die Shrink-Funktion, und sie können den Plattenplatz optimieren. Ab jetzt sind VCBSicherungen wieder optimiert. Stellen Sie wieder auf thin um, so wird die Festplatte nur mit den realen Daten und ohne Altlasten (Dateilöschungen, SDelete etc.) angelegt. Dies ist zwar umständlich, und Sie benötigen Plattenplatz, aber es ist derzeit die einzig mitgelieferte Möglichkeit.
SDelete Anders verhält es sich bei Tools wie SDelete von Microsoft, die die gelöschten Daten nochmals mit Nullen überschreiben, um diese nichtwiederherstellbar zu machen. Je nach Parameternutzung wird keine Basis für die Festplattenoptimierung wie bei dem VMware-Tools-Shrink-Verfahren ermöglicht. Ganz im Gegenteil, die Parameter -z (Zero Free Space) und -c (Clear Free Space) beispielsweise
420
VMware-Storage-Architektur
führen zu einem Wachstum der Thin-Festplatten-Datei bis zur Maximalgröße oder natürlich auch eines Snapshots bis zur Maximalgröße der Ursprungsdatei. Dies kann äußerst ärgerlich sein, wenn Plattenplatz stark überbucht wurde und jemand einen SDelete- oder einen SDelete-ähnlichen Befehl auf einer großen Festplatte ausführt, z. B. einem 500-GB-File-Server, um auf Nummer sicher zu gehen.
8.9.3
Auslagerungsdateien
Schauen Sie sich das Gesamtkonstrukt VMware ESX inklusive der virtuellen Maschinen an, stellen Sie drei Orte fest, an denen Auslagerungsdateien genutzt werden: Service Console, VMkernel und im Gastbetriebssystem der virtuellen Maschine. Jede dieser Auslagerungsdateien hat ihre Daseinsberechtigung. Allerdings müssen Sie immer bedenken, dass die Auslagerungsdatei virtuellen Hauptspeicher auf den lokalen oder entfernten Datenträgern abbildet. Da die Zugriffs- und Durchsatzzeiten von Datenträgern wesentlich langsamer sind als die von physischem Hauptspeicher, bedeutet ausgiebiges Auslagern immer auch verlangsamten Systemzugriff. Service Console Da die Service Console ein getuntes Red-Hat-Linux ist, gelten auch alle Regeln für Red-Hat-Linux. Diese besagen unter anderem, dass man die doppelte Hauptspeichergröße für die Swap-Partition (Auslagerungsdatei) verwenden sollte. Dies sollten Sie bei der Installation des ESX-Servers bedenken, da spätere Partitionsänderungen so mühsam sind, dass meist eine Neuinstallation schneller wäre. Diese Swap-Partition dient dem Red-Hat-Betriebssystem als Puffer für kurzzeitige Spitzen bei der Hauptspeicherverwendung. Möchten Sie die derzeitige Hauptspeichernutzung inklusive Swap-Nutzung auslesen, sollten Sie auf den Befehl free zurückgreifen. VMkernel Warum benötigt der VMkernel Swapspace? – Der VMkernel benutzt den Swapspace zum sogenannten Memory-Overcommitment, also der Überprovisionierung von Hauptspeicher. Bei Standardkonfiguration würde dies bedeuten, dass auf 14 GB verfügbaren Hauptspeicher für virtuelle Maschinen 14 GB weiterer Hauptspeicher als Swapspace hinzukäme, es wären also maximal 28 GB RAM für virtuelle Maschinen nutzbar. Auch hier gilt: Swapping macht die Systeme nicht schneller, sondern langsamer. Allerdings ist die Nutzung der Auslagerungsdatei für die Abdeckung kurzer Spitzen ideal.
421
8.9
8
Storage-Architektur
Außerdem verbrauchen die Gastbetriebssysteme in den seltensten Fällen den konfigurierten Hauptspeicher. Gäbe es kein Overcommitment, könnten nur so viele virtuelle Maschinen betrieben werden, wie physisch Hauptspeicher verfügbar ist, selbst wenn dieser nicht durch die VMs genutzt würde – den Hypervisor interessiert nur der konfigurierte Speicher der aktiven VMs. Die Auslagerungsdatei selbst wird bei Standardkonfiguration pro virtueller Maschine im gleichen Heimatverzeichnis der VM bei Start jener angelegt. Die Größe der Swap-Datei entspricht der Größe des VM-Hauptspeichers. Daher müssen Sie bei der Planung der richtigen LUN-Größe die Swap-Datei jeder virtuellen Maschine mit einrechnen.
Abbildung 8.26
Anpassung des Speicherorts der Swap-Datei
Zwar ist es möglich, die Auslagerungsdateien auf den lokalen Storage der ESXServer zu legen, dies bringt aber Nachteile mit sich, da bei VMotion und damit auch bei DRS zusätzlich die Swap-Datei auf das Zielsystem übertragen werden muss. Des Weiteren besteht die Möglichkeit, alle Auslagerungsdateien auf einer einzigen LUN zu betreiben, die im Zugriff aller von VMotion betroffenen Server ist. Damit schaffen Sie sich allerdings bei schlechter Planung ein potentielles Nadelöhr bei der Leistung.
422
VMware-Storage-Architektur
Eine Alternative außerhalb der GUI ist die Einstellung der Swap-Datei in der VMX-Datei der virtuellen Maschine (sched.swap.dir= "/vmfs/volumes/ /"). Damit verteilen Sie die Swap-Dateien auf wenige LUNs, womit Sie eine gute Performance erreichen können. So könnten Sie beispielsweise die Swap-Dateien auf günstigerem Speicher als die VMs ablegen.
Abbildung 8.27
Die Memory-Reservierung beeinflusst die Erstellung der Swap-Datei.
Diese Größe können Sie durch Anpassung der Hauptspeicherreservierung in den Eigenschaften der virtuellen Maschine heruntersetzen. Wählen Sie eine Reservierung von 100 %, entsteht beim Start der virtuellen Maschine keine Auslagerungsdatei. Gastbetriebssystem In den Foren liest man viel zum Thema Auslagerungsdateien. Fragen wie »Warum noch eine Auslagerungsdatei im Gast-OS, der VMkernel swappt doch bereits?« oder »Wie groß soll die Auslagerungsdatei im Gast-OS geplant werden?« sind dort zu finden. Generell gilt, dass eine Auslagerungsdatei den meisten Nutzen bringt, wo die Daten entstehen, die ausgelagert werden können. Da der ESX-Server keinen Einblick in die Aktivitäten der jeweiligen Betriebssysteme hat, ist der VM-Swap nur als »Notnagel« bei physischen Hauptspeicherengpässen und natürlich für Peaks gedacht. Einen Ersatz für die Auslagerungsdatei im Gast stellt dies nicht dar,
423
8.9
8
Storage-Architektur
daher sollten Sie alle Empfehlungen der Gastbetriebssysteme betreffend der Auslagerungsdateien weiterhin annehmen.
8.9.4
VMFS im Detail
VMFS, das VMware-proprietäre Virtual Machine File System, ist ein auf den Betrieb virtueller Infrastrukturen ausgelegtes und optimiertes Dateisystem. »Optimiert« bedeutet genauer: 왘
Cluster-fähig: Mehrere ESX-Server können zeitgleich auf die VMFS-Partitionen zugreifen, ohne Daten zu beschädigen.
왘
Dateioptimiert: Sehr große und sehr kleine Dateien werden unterstützt, womit die kleinen Konfigurationsdateien sowie große CD-/DVD-Images und sehr große Festplattendateien schnell und zuverlässig im Zugriff sind. Es wird offiziell nur eine Verzeichnisebene unterstützt.
Außerdem ist VMFS ein journalisiertes Dateisystem, was die Fehlersuche und die Fehlerbehandlung wesentlich erleichtert, und arbeitet mit einem LVM (Logical Volume Manager), der für Funktionen wie Extents oder VMFS-Vergrößerung zuständig ist. Mit Version 3 des VMFS sind viele Änderungen eingeflossen, die zum Teil bis heute bei Administratoren, Trainern und Beratern für Verwirrung sorgen. Dabei steht der Umgang mit den UUIDs an erster Stelle. VMFS-Aufbau VMFS hat mit Version 3 viele Änderungen erlebt, die sichtbar vor allem den Strukturaufbau der VMFS-Partitionsinformationen betreffen. VMFS 2 (ESX 2.x)
VMFS 3 (ESX 3.x)
Disk Offset
Disk Offset
Partition Offset
Partition Offset
Volume Header Offset Physical Extend Offset
LVM Offset Volume Metadata Heartbeat Region
Volume Data Volume Data Abbildung 8.28
424
VMFS-Aufbau – Unterschied Version 2/Version 3
VMware-Storage-Architektur
Die neu eingeführten LVM-Offsets enthalten folgende Informationen: 왘
Volume-ID (Signatur)
왘
Anzahl Extents (Spanning mehrerer VMFS-Volumes)
왘
Anzahl der Geräte
왘
Volume-Größe
Außerdem dienen die LVM-Offset-Informationen zum Erkennen eines SnapshotVolumes. In den Volume-Metadaten sind folgende Informationen zu finden: 왘
Eigenschaften aller Dateien inklusive 왘
Name
왘
Größe
왘
letzte Zugriffszeit
왘
Änderungszeit
왘
Berechtigungen
왘
Eigner
왘
Gruppennamen
Sicherung VMFS-3-Metadaten Eine sehr wichtige Information ist die erhöhte Menge an Partitionsinformationen zwischen VMFS-2 und VMFS-3, die von 1 MB auf 20 MB eingestiegen ist. Wenn Sie jetzt denken: »Was interessiert mich diese Größe?«, dann ist Ihnen noch kein Verlust der Header-Informationen und damit kein Verlust der kompletten VMFSPartition vorgekommen. Dies kann durch die Signatur der LUN mittels Windows (z. B. fehlerhaft genutzter VCB-Proxy) oder die Nutzung von Replikationslösungen (manueller oder Softwarefehler) passieren. Berechnung der Größe der Metadaten Die Berechnung der Größe der Metadaten wird folgendermaßen angegeben: 500 MB + ((LUN Size in GB – 1) x 0,016KB) = ca. Metadaten in MB Bei einer 400 GB LUN wäre dies: 500 + ((400 –1) x 0,016) = 506,39 MB = ~ 1 % der Gesamtkapazität Dies bedeutet, dass die Metadaten bei größeren LUNs zu vernachlässigen sind, allerdings bei kleineren LUNs (50 GB ...) doch einen erheblichen Prozentsatz an Kapazität ausmachen. Eine Partition muss mindestens 1200 MB groß sein, um diese mit VMFS formatieren zu können.
425
8.9
8
Storage-Architektur
Um diesem Fall aus dem Weg zu gehen, empfiehlt sich die regelmäßige Sicherung der Metadaten der VMFS-Partitionen. Dies können Sie bei VMFS-3-Partitionen wie folgt durchführen: 1. Sicherung der Systemdateien der VMFS-Partition: cp /vmfs/volumes//.*.sf /tmp/backup
2. Sicherung der Metadaten (Zielgröße muss bei Count in Byte angegeben werden): dd if=/dev/<device> of=/tmp/.bin bs=1024 count=20480
Um das zu sichernde Gerät ausfindig zu machen, nutzen Sie den Befehl vmkfstools –P /vmfs/volumes/: Ausgabe: Partitions spanned:vmhba0:0:1:1 <- Partitionsnummer esxcfg-vmhbadevs –q
Ausgabe: vmhba0:0:1 /dev/sdd <- Device-Name Mit fdisk –lu /tmp/.bin lesen Sie die Partitionstabelle aus. Diese Sicherung ist dem VMware Support sehr hilfreich, wenn Datastores nicht mehr sichtbar sind (als leer erkannt werden, obwohl es sich nicht um einen Snapshot handelt). Wiederherstellung VMFS-3-Metadaten Zur Wiederherstellung besteht der wichtigste Schritt im Herausfinden des richtigen Linux-Device-Namens. Danach stellen Sie die gesicherte Metadatendatei .bin mit dem dd-Befehl wieder her (Zielgröße muss bei Count in Byte angegeben werden): dd if=/tmp/.bin of=/dev/<device> bs=1024 count=20480
Schieben Sie anschließend die Kopien der einzelnen .sf-Dateien wieder auf den Datastore: cp /tmp/backup/.*.sf /vmfs/volumes/
VMFS-UUID Die VMware-Foren wimmeln von Einträgen verloren geglaubter Datastores, und kaum ein Administrator oder Berater von VMware-ESX-Umgebungen war noch nicht mit »falsch« erkannten Snapshot-LUNs konfrontiert. Dieser Aspekt ist den neu eingeführten LVM-Offset- und Volume-Metadaten zu verdanken.
426
VMware-Storage-Architektur
Schauen wir uns die Details an. Snapshots Neben Snapshots virtueller Maschinen auf VMware-Host-Ebene existieren Snapshots auf Storage-Ebene. Abhängig vom Storage-Hersteller handelt es sich entweder um einen Snapshot (das heißt, Änderungen werden in einen weiteren Speicherbereich geschrieben – ähnlich ESX-Snapshot) oder einen Snapshot-Clone oder Clone (1:1-Kopie einer LUN, also doppelte Plattenbelegung). Dabei ist zu bedenken, dass LUN-Serials vom Storage bei der Anlage einer LUN automatisch vergeben werden und nicht mehr nachträglich zu ändern sind. Beim Formatieren einer LUN mit dem VMFS wird automatisch der LVM-Header eingerichtet, in dem eine SCSI-Disk-ID anhand der LUN-Seriennummer (Serial) eingetragen wird (Abbildung 8.29). Sobald es zu Änderungen in der Konfiguration kommt, die die Seriennummer betreffen, wird die LUN automatisch als Snapshot erkannt. LVM Header
VMFS Datastore Inhalt LVM Header SCSI Inquiry String (256byte) Inhalt:
HBA LUN 5
SCSI_DISKID (78b) mit LUN#(HBA LUN Nummer) + LUN Serial (16b) (LUN Serial Storage)
VMware VMkernel
HBA LUN 5
Storage Array LUN ID 5 LUN Serial 123456
Abbildung 8.29
LVM-Header-Informationen zum Volume
Dieses Vorgehen schützt die LUNs vor Dateninkonsistenz oder Datenverlust, falls durch Konfigurationsfehler im SAN oder bei Nutzung von Snapshots oder bei einem Umschalten einer Spiegelung (Sicherung) eine LUN doppelt oder eine falsche LUN in der virtuellen Infrastruktur sichtbar wird. Sie sollten bedenken, dass zumeist nicht nur ein ESX-Server, sondern viele ESXServer auf die gleichen LUNs zugreifen. Mit dem LVM-Header werden LUNs für alle Server der Infrastruktur eindeutig gekennzeichnet. Sobald eine neue LUN mit VMFS-Partition auf einem ESX-Server erkannt wird, findet ein Vergleich der SCSI-Inquiry-Daten (u. a. LUN-Serial) mit den geschriebe-
427
8.9
8
Storage-Architektur
nen Daten des LVM-Headers statt. Damit sind auch neu in die Infrastruktur integrierte ESX-Server direkt in der Lage, zwischen korrekten Konfigurationen und möglichen Fehlkonfigurationen oder Snapshots zu unterscheiden. Beispiel: Erkennung Snapshot LUN Anlage LUN ID: 5 LUN Serial: 30303042303830303030303031383830 VMFS UUID: 47f77067-244ed1d5-bde0-0015173f9345 ESX-Server: esx1 LUN-Kopie auf ESX-Server ESX2 LUN ID: 5 LUN Serial: 30303042303830303030303031383850
Durch die Erkennung der Snapshot-LUN anhand der veränderten Seriennummer herrscht auf dem System kein direkter Zugriff mehr auf die trotzdem noch vorhandene VMFS-Partition. Die LUN ist jedoch nach wie vor physisch zu sehen (esxcfg-mpath -l oder über VI-Client). Die Informationen zur LUN-ID und LUN-Serial lassen sich sehr gut mit dem Befehl esxcfg-mpath -l -v auslesen. Mit esxcfg-volume können Sie die Volumes auch wieder anzeigen und integrieren. Einen erkannten Snapshots machen Sie sehr leicht in der /var/log/vmkwarningProtokolldatei ausfindig: ALERT: LVM: 4475: vml.0100060000303030423038303030303030313838304178 696f6d20:1 may be snapshot: disabling access. See resignaturing sect ion in SAN config guide.
Folgende Fälle, die zum Erkennen eines Snapshots führen, kommen sehr häufig vor: 왘
LUN-Snapshot im Storage wird auf einen ESX-Server gemappt (LUN-Serial).
왘
LUN-Spiegel wird auf einen ESX-Server gemappt (LUN-Serial).
esxcfg-volume -l sollten Sie daher immer auf der Service Console bereithalten.
VMFS-Partition-Alignment Als hätte man mit dem Thema Storage unter VMware nicht schon genug Sorgen, so muss man sich auch noch um die Partitionen und deren Zuordnung kümmern … Ganz so schlimm ist es nicht, allerdings kann es bei einer inkonsistenten Zuordnung zu merklichen Leistungsverlusten beim Zugriff auf den Storage kommen.
428
VMware-Storage-Architektur
Aber eines vorweg: Wenn Sie LUNs mittels VI-Client (über die API) formatieren, wird bei Sektor 128 gestartet, was zu einer optimalen Leistung führt (minimale Latency, hohe Leistung). Es ist zumeist nicht interessant, welches Alignment genau eingetragen wird, – d. h. 64, 128 ... –, sondern eher, dass auf Basis 64 überhaupt ein durchgehendes Alignment sowohl im VMFS als auch im Gastbetriebssystem erfolgt. Probleme existieren nur bei der Formatierung über die Kommandozeile, da in diesem Fall das Alignment nicht mit dem des Storage übereinstimmen muss. Hintergrund ist die Reservierung der ersten 63 Sektoren für den MBR (Master Boot Record), was direkt zur inkonsistenten Zuordnung führt. In Abbildung 8.30 ist der Unterschied zwischen konsistenten und inkonsistenten Zuordnungen gut zu erkennen. konsistente Zuordnung VMFS-Partition
Storage-Partition
inkonsistente Zuordnung VMFS-Partition
Storage-Partition
Abbildung 8.30
VMFS-Partition-Alignment
Durch eine ungleiche Zuordnung kommt es zu Umrechnungen auf dem Storage, was zu Verzögerung sowie Leistungsverlust führt. VMFS Achtung: Datenverlust! Anpassungen an der Zuordnung können immer nur beim Anlegen einer Partition erfolgen und nicht nachträglich. Sollten Sie die folgenden Befehle auf produktive LUNs anwenden, ist ein Datenverlust sehr sicher.
Um eine Partition manuell mittels Service Console und empfohlener Zuordnung anzulegen, existieren zwei Möglichkeiten (wir bleiben bei /dev/sdc):
429
8.9
8
Storage-Architektur
Alternative 1 왘
fdisk -u /dev/sdc
왘
n (Erstellen einer neuen Partition)
왘
p (als Primary anlegen)
왘
1 (erste Partition anlegen)
왘
128 (Partition-Offset des ersten Sektors setzen)
왘
(¢)
왘
(¢), um die Default-Einstellungen zu übernehmen
왘
t (Partitionstyp anpassen)
왘
fb (»fb« = VMFS-Datenpartition)
왘
w (zum Schreiben der Änderungen)
Alternative 2 왘
fdisk /dev/sdc
왘
n (Erstellen einer neuen Partition)
왘
p (als Primary anlegen)
왘
1 (erste Partition anlegen)
왘
(¢), um die Default-Einstellungen zu übernehmen
왘
t (Partitionstyp anpassen)
왘
fb (»fb« = VMFS-Datenpartition)
왘
x (um in den Expertenmodus zu wechseln)
왘
b (Anpassung des Startblocks)
왘
1 (Partition 1 auswählen)
왘
128 (Partition-Offset des ersten Sektors setzen (¢))
왘
w (zum Schreiben der Änderungen)
왘
Danach können Sie die Partition mit VMFS formatieren: vmkfstools -C vmfs3 -b 1m -S VMFS-1 /vmfs/devices/disks/ vmhba#\:#\:#\:1
왘
Zum Überprüfen der richtigen Offsets ist fdisk wieder richtige Befehl: fdisk -lu /dev/sdc
Gastsystem Allerdings ist dies noch nicht alles, da in der virtuellen Maschine ebenfalls mit Zuordnungen im Dateisystem gearbeitet wird. Wie im Beispiel in Abbildung 8.31
430
VMware-Storage-Architektur
zu sehen, kann eine falsche Zuordnung den Storage dazu veranlassen, drei Chunks einzulesen, obwohl nur eine Cluster-Abfrage im Gast stattfand. inkonsistente Zuordnung VM-NTFS-Partition
VMFS-Partition
Storage-Partition
Abbildung 8.31
Partition-Alignment/Storage, VMFS, Gast
Daher ist anzuraten, auch die Partitionen des Gastbetriebssystems anzupassen, um die bestmögliche Leistung zu erreichen. Die Windows-Versionen 7 und 2008 passen das Alignment bereits automatisch an. Achtung: Datenverlust! Anpassungen an der Zuordnung können immer nur beim Anlegen einer Partition erfolgen und nicht nachträglich. Sollten Sie die folgenden Befehle auf produktive LUNs anwenden, ist ein Datenverlust sehr sicher.
Unter Linux geschieht dies exakt wie bei der vorher beschriebenen Partitionierung des VMFS, außer dass statt des Partitiontyps fb ein anderer Typ, z. B. 83 (Linux), ausgewählt werden muss. Unter Windows muss das Programm diskpart bemüht werden, das seit der Version 2003 zur Standardausrüstung von Windows gehört. Unter Windows XP und Windows 2000 müssen Sie es mit den Support Tools installieren. Da es sich um eine nicht formatierte Festplatte handeln muss, um das Alignment anzupassen, ist die Systempartition entweder so zu belassen, wie sie ist, oder zuvor mit einem anderen System zu partitionieren (oder Nutzung von WinPE) und zu formatieren und dann nachträglich an das neu zu installierende System anzuschließen: 왘
diskpart.exe
왘
list disk (Anzeigen der verfügbaren Festplatten)
왘
select disk 1 (Auswahl der Festplatte – im Beispiel Disk 1)
왘
create partition primary align=64 (Partition mit 64-KB-Offset anlegen)
왘
exit
431
8.9
8
Storage-Architektur
Danach können Sie die Festplatte mit dem Disk Manager formatieren – allerdings sollten Sie als Allocation unit size 32K auswählen.
Abbildung 8.32
NTFS-Formatierung mit 32K
Nach dem korrekten Alignment sieht die Zuordnung aus wie in Abbildung 8.33. konsistente Zuordnung VM-NTFS-Partition
Cluster
VMFS-Partition
Blocks
Storage-Partition
Chunks
Abbildung 8.33
Konsistente Zuordnung vom Storage bis zum Gast
VMFS-Versionen Mit VMware ESX 4.0 wurde die VMFS-Version 3.33 veröffentlicht. Ein klares Highlight der Version 3.33 ist das optimierte Metadata-Layout, das zu einer deutlichen Minimierung der SCSI-Reservierungen und damit auch möglicher Konflikte führt. Diese Änderungen sind allerdings bereits größtenteils in die Version 3.31 eingeflossen, die seit ESX 3.5 mit dabei ist. Welche Version verwendet wird, können Sie in den Details des Datastores ablesen.
432
VMware-Storage-Architektur
Abbildung 8.34
VMFS-Version
Leider ist es nicht möglich, die VMFS-Version 3.31 auf 3.33 zu aktualisieren, ohne die LUN neu zu formatieren. Daher müssen Sie mit Storage VMotion arbeiten, damit das Upgrade möglichst unterbrechungsfrei über die Bühne geht. Eine klare Empfehlung ist, die Version 3.31 zu nutzen; Version 3.33 ist nicht zwingend notwendig, daher müssen Sie nicht um jeden Preis ein Upgrade durchführen. SCSI-Reservation SCSI-Reservierungen sind SCSI2-Sperrmechanismen, um Datenverlust durch gleichzeitigen Zugriff mehrerer Systeme auf gleiche Daten zu verhindern. VMware ESX nutzt sie zur Änderung der Metadaten einer LUN. Wichtig: Der ESX-Server sperrt die komplette LUN, um exklusiven Schreibzugriff auf die Metadaten zu erhalten. Sämtlicher I/O der VMs des reservierenden Hosts ist nach wie vor auf die LUN zugelassen, außer weitere Metadaten-Updates. Dazu muss ein erneuter SCSI-Lock stattfinden. Lesezugriffe der anderen ESX-Hosts sind während der Reservierung weiterhin erlaubt, allerdings keine schreibenden I/Os (weder Host noch VM). SCSI-Reservierungen kommen nur bei blockorientiertem Zugriff über das SCSIProtokoll vor. Somit sind Fibre-Channel, iSCSI, FCoE und AoE betroffen. Getrieben durch Aktivitäten wie Snapshots oder Thin Provisioning verschiedener virtueller Maschinen auf der gleichen LUN treten Metadatenänderungen relativ
433
8.9
8
Storage-Architektur
häufig und zu beliebigen Zeiten auf. Finden die Änderungen gleichzeitig statt, kommt es zu einem SCSI-Reservation-Conflict. Reservierungen dauern zwischen 1 und 12 Millisekunden an, bei einer Standarddauer von ca. 7 Millisekunden. Sehr kleine Änderungen, z. B. an Berechtigungen, Zugriffszeiten oder Eignern, dauern in der Regel nur 1 bis 2 Millisekunden. Allerdings liegt das zeitliche Problem nicht an den SCSI-Reservation-Requests selbst, sondern an der Statusmeldung des Targets über das Fibre-Channel-Netz. Obwohl die SAN-Storage-Systeme SCSI-Reservations direkt bearbeiten, kann es bis zu 200 ms dauern, bis der ESX-Server eine Antwort erhält. Folgende Aktionen führen zu SCSI-Reservations: 왘
Erstellung einer Datei (auch bei Erstellung eines Snapshots)
왘
Löschung einer Datei (auch bei Löschung eines Snapshots)
왘
Wechsel der vmdk-Datei in den REDO-Modus (Update alle 15 MB)
왘
Bei der Vergrößerung von 2GB-Sparse- oder -Thin-Festplatten (Update alle 15 MB). Bei der Verwendung von NFS werden NFS-Locks statt SCSI-Reservations genutzt.
왘
Bei der Migration von vmdk-Dateien (je eine Reservierung bei Quelle und Ziel). VMotion kann bei Konflikten fehlschlagen.
왘
Suspend der virtuellen Maschine (Suspend-Datei wird erstellt)
왘
VMDK im Persistent Mode (aufgrund des Erstellens und Löschens des REDOLogs – und alle 16 MB Update)
왘
VM-Erstellung mittels Template (wenn das Template auch auf einem VMFS liegt, werden Reservations auf Quelle und Ziel gesetzt)
왘
Template-Erstellung aus VM (wenn Quelle und Ziel im VMFS liegen, wird neben der Standardreservierung auch alle 16 MB eine SCSI-Reservierung im Target durchgeführt)
왘
Export einer vmdk-Datei
왘
Dateisystemanpassung via fdisk etc.
왘
bei Ausführung von vm-support auf der Service Console
왘
Änderung von Berechtigungen, Eigner, Zugriffs-/Änderungszeiten
왘
Größenänderung einer Festplattendatei
왘
beim ersten Hinzufügen einer LUN an einen ESX-Server
Wird eine SCSI-Reservierung fehlerhaft aufrechterhalten, ist dieser Befehl nützlich, um sie wieder aufzuheben: vmkfstools -L lunreset /vmfs/devices/disks/vmhba#\:#\:#\:0
434
VMware-Storage-Architektur
VMFS-Extents Eine sehr häufig gestellte Frage ist, ob VMFS-Partitionen problemlos erweitert werden können, wie es bei vielen modernen Dateisystemen der Fall ist. Dies wünschen sich z. B. Administratoren, wenn sie eine stark gefüllte LUN auf dem Storage-System vergrößert haben. Die Antwort ist seit vSphere: Ja! Es ist möglich, die VMFS-Partition online zu vergrößern, ohne Extents zu nutzen. Daher werden Extents nur noch über die Kommandozeile oder bei einer Verbindung von zwei oder mehr LUNs miteinander verbunden. Befinden sich die zu verknüpfenden Partitionen auf der gleichen LUN, wird die VMFS-Partition einfach vergrößert. Ein großes Problem besteht bei Extents, dass sie per Concat an bestehende Partitionen geknüpft werden und nicht per Stripe. Hat dies Nachteile? Auch hier ist die Antwort definitiv: Ja! Da beim Concat einfach mehrere Partitionen logisch verbunden werden, werden die Daten nicht gleichmäßig über alle Partitionen verteilt wie beim Striping. Der ESX-Server legt die Daten schlicht, wie sie entstehen, nacheinander über die Partitionen ab, als wäre es eine einzige. Das heißt, zuerst wird das erste Extent mit Daten gefüllt, dann das zweite etc. bis zum letzten Extent. Sind die Daten größer als ein Extent, z. B. 60-GB-vmdk-Datei bei 5 × 50 GB Extents, wird zwangsweise über zwei LUNs geschrieben. Fällt eine der beiden genutzten LUNs aus, wird die vmdk-Datei entweder verschwinden, da der Header fehlt, oder beschädigt, da Datenteile fehlen. Allerdings versucht der ESX-Server, falls vom Plattenplatz möglich, vmdk-Dateien komplett auf ein Extent zu legen, um zumindest einen Teil der Ausfallsicherheit zu wahren. Sobald nicht mehr genügend Plattenplatz für eine vmdk-Datei auf einem der Extents ist, beginnt der ESX-Server, die Lücken zu füllen, was entfernt mit einer Fragmentierung vergleichbar ist. Ist nicht mehr genügend Platz auf einem der Extents für eine Festplatte frei, so kann die Festplattendatei oder VM nicht mehr angelegt werden! Das Gemeine hierbei ist, dass Sie nicht sehen, wie stark die Extents belegt sind, sondern nur, wie stark der Datastore belegt ist. Besteht ein Datastore aus vier Extents à 74 GB und sind noch insgesamt 100 GB auf dem Datastore frei, können Sie trotzdem niemals eine Festplattendatei größer als 74 GB anlegen.
435
8.9
8
Storage-Architektur
Thin Provisioning und Extents Dieses Problem verschlimmert sich mit Thin Provisioning, da die Festplattendatei dann zwar angelegt werden kann, allerdings wird die Festplatte spätestens bei 74 GB nicht mehr weiter beschrieben werden können. Das Gleiche gilt bei Snapshots, welche zwar immer angelegt werden können, aber unter Umständen irgendwann aufgrund der Größenbeschränkung eines Extents nicht mehr wachsen können.
Entgegen der Meinung, bei Extents würden die vmdk-Dateien sinnvoll verteilt, wird sogar bei gleichzeitiger Anlage mehrerer VMs auf dem gleichen ExtentDatastore die gleiche LUN genutzt, falls genügend freier Platz vorhanden ist. Daher ist eine Erhöhung der Leistung durch Zugriff auf mehrere Partitionen nicht steuerbar, sondern rein zufällig, abhängig vom Füllgrad. Wie erwähnt ist es ganz fatal, Extents in Verbindung mit Linked Clones (Lab Manager) oder Thin-vmdkDateien zu nutzen, da im schlimmsten Fall alle VMs auf der ersten Festplatte des Extents angelegt würden und dieses irgendwann vollaufen würde, ohne dass es am Füllgrad des Datastores erkennbar wäre. Der Vorteil an der Konkatenation ist, dass bei Ausfall eines Extents im besten Falle nur die VMs nicht mehr im Zugriff sind, die auf genau dieser LUN lagen.
Abbildung 8.35 Kopierprozess auf Datastore, bestehend aus vier Extents – nur Volume3 wird genutzt (Storage wurde in einer VM auf lokalen Festplatten mit DataCore SANSymphony virtualisiert, was zu den schlechten Performance-Werten führt).
436
VMware-Storage-Architektur
Beim Striping (wird allerdings von VMware nicht verwendet) werden alle Partitionen logisch miteinander verknüpft, und die Daten werden beim Schreiben nahezu gleichmäßig über alle Partitionen oder Festplatten verteilt. Das führt wirklich zu mehr Performance, da eine bessere Verteilung herrscht. Striping hätte allerdings bei Ausfall eines der Extents den Ausfall des kompletten Datastores zur Folge. Bevor Sie Extents verwenden, sollten Sie erst alle Möglichkeiten durch Erstellen einer größeren LUN mit VMFS-Formatierung ausschöpfen. Die VMs verschieben Sie dann mit Storage VMotion. Extents wären nur im äußersten Notfall sinnvoll.
Abbildung 8.36 Ansicht eines Datastores mit vier Extents (Grafik noch mit VMware ESX 3.5 – unter vSphere jedoch ähnlich)
Nutzung von Extents Neben der Vergrößerung von bestehenden Datastores durch Anlegen weiterer Partitionen per Concat auf der gleichen LUN können Sie Extents auch auf beliebige Raw LUNs anwenden, sogar solche, die von unterschiedlichen Storage-Systemen kommen. Dabei sollten Sie aber mehrere Aspekte bedenken: 왘
Datensicherheit, da bei Ausfall einer der LUNs beliebige Zugriffe auf den Datastore versagen.
왘
Datensicherheit, die Zweite – verteilen Sie Extents über mehrere Storage-Systeme, entstehen mehrere potentielle Ausfallpunkte, die sehr schwer adressierbar sind.
왘
QoS (Quality of Service) - bei Verteilung auf mehrere LUNs müssen Sie sehr darauf achten, dass diese immer gleicher Natur sind, also keine unterschiedlichen Performance, RAID- oder QoS- Einstellungen besitzen. Dies würde zu unvorhersehbaren Problemen führen.
437
8.9
8
Storage-Architektur
VMFS-Blockgröße Die VMFS-Blockgröße bezieht sich auf das VMFS und ist daher unabhängig von der Blockgröße des Storage. Wichtig ist allerdings, dass die VMFS-Partitionen aligned sind und damit vom Multiplikator mit den Blöcken des Storage genau übereinstimmen. Haben Sie eine Blockgröße von 64 KB im Storage und von 1 024 KB im VMFS, so wird pro 1 024 KB nur ein I/O ausgelöst, der 16 Blöcke im Storage am Stück liest.
Abbildung 8.37
VMFS-Blockgröße beim Erstellen eines Datastores
Allerdings unterstützt VMware das Auslesen von Subsets von VMFS-Blöcken, damit ein 64-KB-Cluster im NTFS keine Abfrage von 1.024 KB auf dem VMFS auslöst. Jedoch ist es sehr fraglich, ob wirklich Leistungsvorteile bei der Erhöhung der Blockgrößen feststellbar wären – es ist eher unwahrscheinlich. Daher sollten Sie die Blockgrößen nur verändern, wenn Sie wirklich sehr große vmdkDateien anlegen müssen. Generell ist es wichtig zu verstehen, dass eine Abfrage aus der Applikation im Gast nichts mit der Blockgröße des VMFS und auch nichts mit der Blockgröße im Storage zu tun hat. Erstens ist es so, dass sowohl NTFS unter Windows als auch VMFS unter VMware Dateisysteme sind und die Block- bzw. Cluster-Größe hier für die Zuordnungen in der Dateiallokationstabelle eine Rolle spielt. Zweitens hat beides nichts mit der blockorientierten Welt des Storage-Systems zu tun. 8-MB-Blockgröße im VMFS bedeuten, dass jede Datei mindestens 8 MB belegt, unabhängig davon, ob sie kleiner ist. vmdk-Dateien betrifft dies nie, sondern nur vmx-, log- und andere Dateien. Kleinstdateien wie zum Beispiel vmx- oder logDateien existieren aber nicht millionenfach auf dem Datastore, sondern eher im Dutzend oder wenige Hundert, daher ist die Verschwendung uninteressant. Werden aus dem Windows-Gast 4 KB angefordert, so weiß das Dateisystem aus der File Allocation Table, wo diese 4 KB auf der Festplatte stehen, und gibt die
438
VMware-Storage-Architektur
Anfrage an den SCSI-Treiber weiter. Dies betrifft den VMkernel, der die Zuordnung zwischen dem angefragten Datenblock und der Ablage auf dem Storage kennt. Daher werden auch bei einer Blockgröße des VMFS von 8 MB bei einer 4-KB-Abfrage die 64 KB (bzw. was im Storage eingestellt ist) des Storage zählen und nicht die 8 MB des VMFS. Fazit: Alignment ist wichtig, Blockgröße und Alignment-Wert sind für die Leistungsfähigkeit zweitrangig. VMFS-SCSI-Errorcodes Alle Fehler, die beim Betrieb von VMFS-Partitionen auftreten, sind in der Protokolldatei /var/log/vmkwarning zu finden, unterscheiden sich jedoch zwischen VMware ESX 3.x und 4.x. Ein sehr hilfreiches Knowledge-Base-Dokument (289902) ist hier zu finden: http://kb.vmware.com/kb/289902 Ein Beispielaufbau einer SCSI-Fehlermeldung sieht wie folgt aus: H:0x8 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0
Tabelle 8.7 stellt die generelle Syntax für ESX 4.0 dar. Code
Eigenschaft
A
Host-Status (Initiator)
B
Gerätestatus (Target)
C
Plug-in (VMware-spezifisch)
D
Fehlercode
E
erweiterter Fehlercode
F
Kennzeichner des erweiterten Fehlercodes
Tabelle 8.7
8.9.5
SCSI-Fehlercode-Aufbau
Virtuelle Maschinen
Die virtuellen Maschinen haben zwar technisch nicht allzu viel mit Storage zu tun, allerdings sind sie der erste Ansatzpunkt, an dem die Leistungsengpässe als Erstes bemerkt und gespürt werden. vSphere bringt für die virtuellen Maschinen mittlerweile fünf verschiedene Adapter mit und unterstützt Raw-Device-Mappings und NPIV. Nach wie vor können die VMware-Snapshots die Speicherleistung doch deutlich verschlechtern.
439
8.9
8
Storage-Architektur
IDE-Adapter Für ältere Gastbetriebssysteme hat VMware nun auch den IDE-Adapter, der bei den VMware-Workstation-Produkten schon seit jeher verfügbar ist, ins Enterprise-Segment mit vSphere gebracht. Während der Anlage einer virtuellen Festplatte müssten Sie statt SCSI den IDE-Controller wählen. Diesen Adapter sollten Sie wirklich nur im Notfall verwenden, da er keinerlei Leistungsvorteile bringt, sondern nur Kompatibilitätsvorteile.
Abbildung 8.38
IDE-Adapter unter VMware vSphere
Standard-SCSI-Adapter An Standard-SCSI-Adaptern sind die bereits bekannten BusLogic-Parallel- und LSI-Logic-Parallel-Emulationen wieder mit dabei. BusLogic sollte nur bei älteren Systemen ausgewählt und LSI Logic immer vorgezogen werden. Reichen Sie notfalls während der Installation den LSI-Treiber per Diskette nach (F6) unter Windows). LSI Logic Parallel ist optimiert für SAN-Umgebungen, dank der besseren Busbandbreite und den besseren Cache- und Queue-Möglichkeiten. Um den neuen LSI-Logic-SAS-Controller zu verwenden, muss die virtuelle Maschine über die neue Hardware-Version 7 verfügen, und er ist als Adapter für geclusterte Windows-2008-Gastsysteme gedacht. Paravirtualized SCSI Mit vSphere kam ein neuer SCSI-Adapter für die virtuellen Maschinen hinzu, der paravirtualisiert läuft. Dies bedeutet, dass der Treiber dieses Gerätes ähnlich der vmxnet-Netzwerkkarte über seine Virtualisierung »Bescheid weiß«. Dies ermöglicht eine optimierte Kommunikation zwischen Gastkomponente und VMkernel und bietet daher erhebliche Leistungsvorteile. Der paravirtualisierte SCSI-Adapter kann mit ESX 4.0 nur als Datenfestplatte und nicht als Bootfestplatte verwendet werden. Des Weiteren werden nur die
440
VMware-Storage-Architektur
Betriebssysteme Windows 2003, 2008 und Red Hat Enterprise Linux 5 unterstützt.
Abbildung 8.39
Paravirtueller SCSI-Adapter unter VMware vSphere
Außerdem existieren Limitierungen bei den HotAdd- und HotRemove-Funktionen, und Sie sollten bedenken, dass paravirtualisierte CSI-Platten mit Snapshots keine Leistungsvorteile mehr besitzen. Weitere Informationen erhalten Sie in der VMware Knowledge Base unter: http://kb.vmware.com/kb/1010398. RDM Bei Raw-Device-Mappings handelt es sich um 1:1-Zuordnungen zwischen virtueller Festplatte und physischer LUN. Daher funktionieren RDMs auch nur mit blockorientierten Systemen und nicht mit NFS. VMware nutzt zur Zuordnung ein Mapping-File, das als Proxy für die SCSI Befehle dient. Man unterscheidet zwischen physical und virtual mode, wobei der physical mode für Cluster zwischen virtuellen und physischen Systemen eingesetzt wird und der virtual mode Funktionen wie Snapshots unterstützt. Sie sollten bei der Verwendung von RDMs sehr vorsichtig agieren, da das Betriebssystem im Gast die Festplatten mit eigenen Daten und Dateisystemen beschreibt. Während VMware NTFS und EXT3 als Daten erkennt, was beim Überschreiben von RDM-LUNs mit VMFS zumindest eine Hürde darstellt, sind z. B. Oracle-Raw-Daten nicht erkennbar. Daher sollten Sie die LUN-IDs für RDMs in einem bestimmten Bereich, z. B. größer 100, halten, um Missverständnisse und Datenverlust zu vermeiden.
441
8.9
8
Storage-Architektur
Vorteile von RDMs sind die bessere Unterstützung von Storage-Snaphots, die Lesbarkeit der Daten von anderen Systemen (z. B. NTFS statt VMFS) und die effektive Einzelnutzung durch die VM oder den VM-Cluster. Nachteile liegen in der Verwaltung, da Sie für jede virtuelle Festplattendatei einen RDM und eine LUN anlegen und verwalten müssen.
öffnet
Schreiben Lesen
Mapping File
VMFS volume
Abbildung 8.40
RAW Device (mapped Device)
Raw-Device-Mapping-Zuordnung
Die LUNs müssen bei der RDM-Verwendung mit dem ESX-Server verbunden werden. Dies unterscheidet sich nicht von VMFS-Datastores. VMotion, HA und DRS funktionieren in diesem Fall dann auch wie normal. Setzen Sie Storage VMotion ein, sollten Sie unbedingt beachten, dass aus der RDM-LUN eine vmdk-Datei erzeugt wird, wenn Sie diese nicht dediziert ausschließen. Dies hat zur Folge, dass eine 1-TB-RDM-LUN urplötzlich als 1-TBvmdk-Datei auf dem Ziel-Datastore erstellt wird. NPIV ist nur bei der Verwendung von RDMs möglich und erlaubt eine direkte Zuordnung der virtuellen Festplatte der virtuellen Maschine zu einer LUN, da auf den virtuellen Maschinen zusätzliche virtuelle WWPNs konfiguriert werden. Diesen virtuellen WWPNs, die der ESX-Server an die FC-Ports weitergibt (daher müssen Sie die Funktion auf den FC-Switches freischalten), können Sie auf die LUNs schreibenden Zugriff erlauben, während der ESX-Host nur lesenden Zugriff erhält. Damit sichern Sie ab, dass die entsprechende LUN nicht aus Versehen oder absichtlich einer anderen, nicht autorisierten VM zugeordnet wird. VMDirectPath-I/O Der I/O-Zugriff von VMDirectPath belastet die CPU beim Verarbeiten von Storage-Last weniger, wenn dauerhaft und regelmäßig auf die Speichersysteme zugegriffen wird, indem er der VM ermöglicht, direkt auf die physische Hardware zuzugreifen.
442
VMware-Storage-Architektur
Dies führt allerdings dazu, dass andere Virtualisierungsfunktionen, wie z. B. VMotion, nicht mehr zur Verfügung stehen, da die Virtualisierungsschicht ausgeklammert wird. Mit Verwendung von VMDirectPath-I/O sind die folgenden Funktionen nicht mehr möglich: 왘
VMotion
왘
HotAdd/HotRemove von virtuellen Festplatten
왘
Suspend und Resume
왘
Fault-Tolerance
왘
VMware HA
왘
Memory-Overcommitment und Transparent Page-Sharing
Um VMDirectPath-I/O für Netzwerkkarten zu nutzen, werden 10-Gigabit-Ethernet-Controller Intel 82598 oder Broadcom 57710 oder 57711 im ESX-Server benötigt. Experimentelle Unterstützung wird bei HBAs von QLogic (QLogic QLA25xx 8GB Fibre-Channel), Emulex (LPe12000 8GB Fibre-Channel) sowie LSI3GB-SAS-Adaptern (3442e-R und 3801e – basierend auf dem 1068-Chip) angeboten.
8.9.6
VMware-Snapshots
Erstellen Sie einen Snapshot auf einer virtuellen Maschine, so wird ein bestimmter Zeitpunkt festgehalten, das heißt, ab dem Zeitpunkt des Snapshots bleiben die Ursprungsdateien der VM unangetastet, und alle Änderungen werden in neue Dateien geschrieben. Dies kann im laufenden Betrieb der virtuellen Maschinen geschehen. Ebenfalls ist es möglich, die aktuellen Daten mit den Daten des Snapshots zusammenzuführen, was auch keine Ausfallzeiten mit sich bringt. Nur wenn Sie die Daten seit dem Snapshot verwerfen möchten, wird die virtuelle Maschine gestoppt, auf den alten Stand gebracht und nochmals aktiviert. Theoretisch können Sie beliebig viele Snapshots anlegen, allerdings ist dies natürlich aufgrund der fehlenden Transparenz bei der Snapshot-Verwaltung und dem aufwendigen Management wenig sinnvoll. Sobald ein Snapshot angelegt wurde, wachsen die neu erstellten Deltadateien dynamisch mit der Aktivität im Gast, jede Änderung auf den Festplatten führt also zum Wachstum der Delta-Festplattendatei. Damit ist jede Änderung gemeint, vom Kopieren einer Datei über sicheres Formatieren der Festplatte mit Nullen bis zum Löschen von Dateien. Es findet niemals eine Reduzierung des Plattenbedarfs statt. Allerdings kann eine Deltadatei niemals größer werden als
443
8.9
8
Storage-Architektur
die Originaldatei, von der sie abstammt, da alle Speicher-Blöcke 1:1 abgebildet wurden. Wird der gleiche Block hundert Mal überschrieben, ändert dies nichts an der Größe der Deltadatei. Sobald ein neuer Block geschrieben wird, wächst die Deltadatei mindestens 15 MB Schritten mit. Daher ist es wichtig zu verstehen, dass zwar nach Anlage des Snapshots der zusätzliche Speicherbedarf maximal verdoppelt werden kann, dies gilt aber für jeden Snapshot; das heißt, wenn die Deltadatei nach dem ersten Snapshot 5 GB groß ist und ein zweiter Snapshot angelegt wird, so summieren sich die Deltadateien insgesamt auf dem Datastore. Somit gilt es, sowohl die Anzahl der Snapshots als auch deren Größe im Auge zu behalten. Snapshots werden übrigens fast immer von Backup-Produkten genutzt, um virtuelle Maschinen im aktiven Zustand von außen zu sichern (nicht mittels Agent im Gast, sondern VCB). Dies hat als Hintergrund, dass die Festplattendateien einer VM im exklusiven Lese-/Schreibzugriff durch den VMkernel sind, bis ein Snapshot angelegt wird. Ab diesem Zeitpunkt können die Ursprungsfestplattendateien gelesen werden, und die letzte Deltadatei ist im exklusiven Schreib-/Lesezugriff durch den VMkernel. Tabelle 8.8 zeigt den technischen Ablauf eines Snapshots. Aktion/Dateien der VM
VMDKGröße
NTFSGröße
freie Kapazität NTFS
Anlage der VM mit Thick-Platte
Vm1.vmdk (c:\)
10,2 GB
Kapazitätsnutzung im VMFS durch VM
10,2 GB
10 GB
5 GB
10,2 GB
10 GB
4 GB
10,2 GB
10 GB
4 GB
> 1 MB
10 GB
4GB
Vm1.vmdk (c:\)
10,2 GB
10 GB
4 GB
Vm1-000001.vmdk
~500MB
10 GB
3,5 GB
10,2 GB
10 GB
4 GB
Kopieren einer DVD im Gast (1GB)
Vm1.vmdk (c:\) Anlage von Snapshot 1
Vm1.vmdk (c:\) Vm1-000001.vmdk Kopieren einer Datei im Gast (500 MB)
Anlage von Snapshot 2
Vm1.vmdk (c:\) Tabelle 8.8
444
Snapshot - Entwicklung in der Übersicht
VMware-Storage-Architektur
Aktion/Dateien der VM
VMDKGröße
NTFSGröße
freie Kapazität NTFS
Vm1-000001.vmdk
~500MB
10 GB
3,5 GB
Vm1-000002.vmdk
> 1 MB
10 GB
3,5 GB
10,2 GB
10 GB
4 GB
Vm1-000001.vmdk
~500 MB
10 GB
3,5 GB
Vm1-000002.vmdk
~2 GB
10 GB
1,5 GB
10 GB
1,5 GB
Kopieren einer DVD im Gast (2 GB)
Vm1.vmdk (c:\)
Kapazitätsnutzung im VMFS durch VM
12,5 GB
Entfernen der beiden Snapshots
Vm1.vmdk (c:\)
10,2 GB
Kapazitätsnutzung im VMFS durch VM
10,2 GB
Tabelle 8.8
Snapshot - Entwicklung in der Übersicht (Forts.)
Wie Sie in der Tabelle sehen, sind Deltadateien leicht an der Nummerierung -######.vmdk zu erkennen und wachsen mit den Daten im Gast mit. Die Plattenbelegung im Gastdateisystem wird mit Anlage des Snapshots konserviert und auf den Deltadateien mitgepflegt. Sobald die Snapshots entfernt werden, werden alle Änderungen in die Originalfestplattendateien geschrieben. Die Deltadateien werden gelöscht und belegen keinen zusätzlichen Plattenplatz mehr. Jedes Wachstum der Deltadateien und das Anlegen und Entfernen der Snapshots führt übrigens im FC-Umfeld zu SCSI-Reservations, wodurch exzessiver Gebrauch von Snapshots auch schnell zu Leistungsengpässen führt. Snapshots sind keine Backups Snapshots werden zwar zur Sicherung von außen durch Software oder Skripte genutzt, dienen aber selbst nicht als Ersatz für Backup-Lösungen. Snapshots sind, wenn überhaupt, kurzzeitig einzusetzen bei Anpassungen im Gast (Aktualisierung des Gastbetriebssystem oder der Applikation) oder eben durch die Backup-Software, die die Snapshots direkt wieder löscht, sobald die Sicherung abgeschlossen wurde.
Wie bereits in der Erklärung zu verstehen war, bauen die Snapshots per Copy-onWrite-Verfahren aufeinander auf. Daher dürfen Sie niemals die Snapshot-Kette unterbrechen, indem Sie beispielsweise Snapshot-Dateien manuell entfernen. Dies führt im schlimmsten Fall zu massivem Datenverlust.
445
8.9
8
Storage-Architektur
8.10
Best Practices Storage
Neben den Best Practices der Hersteller existieren natürlich ein paar mehr oder weniger allgemeingültige Ansätze. Die folgenden Informationen sind nur ein Auszug und keine vollständige Liste. Die bereits in diesem Kapitel erwähnten Themen Single-Initiator-Zoning, Partition-Alignment und SCSI-Reservations sollten Sie in jedem Fall beachten.
8.10.1 RAID-Leistungsfähigkeit Auf den RAID-Typ gehen wir hier nicht detailliert ein, dafür kann die WikipediaWebsite sehr gut dienen: http://de.wikipedia.org/wiki/RAID Allerdings möchten wir an dieser Stelle gerne die oft gehört oder gelesenen Fragen zur RAID-Leistung für die bekanntesten RAID-Level beantworten, siehe Tabelle 8.9. RAID-Level
1 Frontend-Schreib-I/O = # Backend-I/O
RAID 0
1
RAID 1
2
RAID 5
4
RAID 6
6
Tabelle 8.9
Frontend-I/O vs. Backend-I/O im RAID-Vergleich
In Tabelle 8.9 erkennen Sie, dass ein I/O, das auf die RAID-Gruppe geschrieben wird, im Backend wesentlich mehr I/O-Operationen auslöst. Bei RAID 5 wären dies vier I/Os (Block lesen, Parity lesen, Block schreiben, Parity schreiben). Lesend sind die meisten RAID-Typen zumindest ähnlich, das heißt, bei RAID 0 kann beispielsweise gleichzeitig von beiden Platten gelesen werden, da diese die gleichen Daten enthalten. RAID 0, RAID 10 und RAID 50 erreichen lesend noch höhere Raten als RAID 1 oder RAID 5 bzw. RAID 6. Dies muss man ins Verhältnis mit den I/Os der Festplatten stellen: SATA ~70–90 I/Os, SCSI ~120–150 I/Os, SAS/FC 150–180 I/Os. Die Umdrehungsgeschwindigkeit hat natürlich ebenfalls Auswirkungen auf die I/O-Raten. Möchten Sie daher eine mögliche I/O-Geschwindigkeit in einem RAID 5 mit drei FC-Festplatten errechnen, so könnte dies so aussehen: 150 × 3 = 450 I/Os maximal lesen pro Sekunde 450 /4 = 112,5 I/Os maximal schreiben pro Sekunde
446
Best Practices Storage
Ginge man von 4-KB-Blöcken wie bei Exchange aus, so wäre der Durchsatz: 450 × 4 = 1.800 KB Durchsatz pro Sekunde 112,5 × 4 = 450 KB Durchsatz pro Sekunde Dies hört sich alles nicht so berauschend an, allerdings sind wir nun auf der reinen Physik, ohne Tuning. Dies wäre beispielsweise bei einem Direct-attached Storage (DAS = lokaler Speicher) der Fall, da dort kaum Caching ins Spiel kommt. Ginge man den Weg ins SAN, dann könnte man nicht mehr einfach sagen, was die zu erwartende Performance der Platten wäre, da neue Faktoren hinzukämen. Einer der besten Beschleuniger ist zweifelsfrei der Cache und natürlich auch die Anzahl der Festplatten im RAID. Außerdem verfügen die Hersteller über die verschiedensten Ansätze, Zugriffsprofile der Anwendungen zu erkennen und diese zu optimieren. Daher ist es unmöglich, ohne Messungen und weitreichende Kenntnisse der verwendeten Applikationen eine Aussage zu treffen. Im VMware-Umfeld wird dies noch schwieriger, da über die einzelnen Datastores die unterschiedlichsten I/O-Abfragen eingehen, weil viele virtuelle Systeme mit unterschiedlichen Anwendungen gleichzeitig auf dem gleichen gemeinsamen RAID arbeiten. Dadurch entsteht auch ein hoher Anteil an Random-I/O, weswegen die Treffer im Cache abnehmen. Dies bedeutet, dass kleine Caches unter Umständen nutzlos werden. Als Fazit sind RAID 1, 10 und 50 sehr gut, um hohe Performance zu erreichen, RAID 5 und 6 liefern schlechtere Performance bei höheren Kapazitäten. Daher sollten Sie sich die durch die virtuellen Maschinen zu erwartenden Speicherprofile gut anschauen und nach benötigter Leistung oder Kapazität entscheiden. Außerdem ist das Storage-System mit seiner Architektur gegebenenfalls ideal für die angestrebte Anwendung.
8.10.2 RAID-Größe Neben der natürlich am häufigsten gestellten Frage nach der richtigen LUNGröße ist auch immer wieder die Anzahl der Festplatten im einem RAID-Verbund eine spannendes Thema, das gerne angefragt wird. Generell gilt natürlich: Je mehr Leistung in den Systemen benötigt wird, desto mehr Festplatten sind sinnvoll. Allerdings muss man bei dieser Behauptung immer beachten, dass die Ausfallsicherheit nicht vernachlässigt werden darf. Würde man eine RAID-5-Gruppe mit 100 Festplatten erstellen (vorausgesetzt, es ist technisch möglich), so nähme die Berechnung der Parität wesentlich mehr Zeit in Anspruch nehmen als bei einer kleineren RAID-Gruppe.
447
8.10
8
Storage-Architektur
Des Weiteren skaliert eine RAID-Gruppe nicht unendlich, so dass ein RAID 5 mit 4 Platten bei einer Vergrößerung auf 6 Platten noch linear skaliert, eine Erhöhung auf 12 und mehr mit sehr großer Wahrscheinlichkeit nicht mehr. Wie weit technisch skaliert werden kann, hängt auch vom Design der RAID-Lösung des Storage-Anbieters ab. Außerdem ist es vom Leistungsaspekt her egal, ob auf einem RAID 5 mit 4 Platten 10 VMs gut performen oder auf einem RAID 5 mit 16 Platten 40 VMs. Ganz im Gegenteil, die kleinere RAID-Gruppe könnte sogar wesentlich bessere Leistung bringen, da weniger SCSI-Reservations und natürlich Random-I/O passiert. Daher ist es hier sinnvoll, nach einer optimalen RAID-Konfiguration zwischen Leistung und Ausfallsicherheit zu schauen. Idealerweise testen Sie daher verschiedene RAID-Konfigurationen und schauen, ob ein Engpass bei Kapazität oder Leistung besteht, und passen dementsprechend die RAID-Sets an. Oft hilft hier auch die Arraybelegung der Storage-Hersteller, da sich bei einem Array mit 14 Festplatten z. B. entweder 2 RAID-5-Gruppen à 6 Platten (Benennung 5 + 1 = 5 * Datenkapazität + 1 * Parity-Kapazität) mit 2 Hot-Spare-Platten oder 13 Platten (12 + 1) mit einer Hot-Spare-Platte. Diese Zuordnung unterscheidet sich natürlich bei der Nutzung von RAID 1, RAID 6, RAID 10 bzw. RAID 50 und sollte mit dem Storage-Hersteller hinsichtlich der benötigten Leistung und Ausfallsicherheit abgesprochen werden. Abhängig von Typ und Leistungsfähigkeit der Festplatte können Sie unterschiedlich viele LUNs auf diesem RAID-Set anlegen und mit virtuellen Maschinen befüllen. Generell müssen Sie immer beachten, dass jede LUN und jede virtuelle Maschine auf einer RAID-Gruppe zur Mehrbelastung des Systems mit RandomZugriffen führt. Daher sind in diesem Fall SCSI-, FC- oder SAS-Platten gegenüber SATA-Festplatten im Vorteil. Manche Systeme unterstützen die Möglichkeit, RAID-Gruppen miteinander zu vermischen, z. B. über mehrere RAID-5-Gruppen eine RAID-0-Gruppe zu legen. Damit erhöhen Sie die Anzahl der Festplatten eines RAID-Sets und damit die möglichen Datendurchsatzraten. Pillar Data Systems verfolgt z. B. ein solches Konzept. HP bietet mit der EVA ein Konzept, die RAID-Level generell über alle verfügbaren Festplatten zu verteilen, das heißt, ein RAID besteht nicht aus beispielsweise 6 Festplatten, sondern nur aus Segmenten von 100 Festplatten, bei gleicher Datenmenge. Dies führt zwar zu sehr hoher Performance, ist aber bei der Bedienung und Planung sehr fehleranfällig. Daher sollten Sie bei diesem Storage-System immer sehr professionell arbeiten und genau wissen, was Sie machen.
448
Best Practices Storage
8.10.3 Geschwindigkeit vs. Kapazität Das Thema Geschwindigkeit vs. Kapazität wird seit der Einführung von SATAFestplatten und den damit verbundenen enormen Festplattenkapazitäten leider immer mehr vernachlässigt, und es kommt stetig zu Leistungsproblemen im SAN oder zu Diskussionen über den Preis der Storage-Systeme. Aber warum muss dieses Thema so genau angeschaut werden? Dazu müssen Sie sich wieder ins Gedächtnis rufen, was vor der Virtualisierung war: Man hatte zumeist zwei SCSI- oder FC-Festplatten im RAID 1 in jedem Server, das allerdings mit System, Auslagerungsdatei und seinen Applikationen alleinig auf diesem RAID lief. Sobald dieses physische System virtualisiert wird, sinkt der Plattenbedarf nicht, das heißt, wenn früher 25 % der Festplattenleistung ausgeschöpft wurde, so besteht diese Notwendigkeit auch nach der Virtualisierung. Schaut man sich die virtuelle Infrastruktur genauer an, so sind viele virtuelle Maschinen auf einer oder mehreren LUNs gebündelt, die wiederum auf einer oder mehreren RAID-Gruppen abgelegt sind. Hinzu kommt, dass beim Betrieb mehrerer VMs auf dem gleichen VMFS nahezu ausschließlich Random-Zugriff herrscht, was bei größerer Datendichte automatisch zu mehr Bewegung des Schreib- Lese-Kopfes führt.
Abbildung 8.41 Sequentielle Zugriffe durch virtuelle Maschinen auf das gleiche RAID Set führen zu Random-Zugriffen.
449
8.10
8
Storage-Architektur
Würde man nun fünf 1-TB-SATA-Festplatten in einem RAID 5 bündeln, so käme man auf eine Nutzkapazität von etwa 4 TB, die man in vier LUNs à 1 TB aufteilen würde. Damit stehen 4 TB Nutzkapazität aufgeteilt auf vier LUNs, die mit VMFS formatiert werden, zur Verfügung. Ginge man im einfachsten Fall von virtuellen Maschinen mit einer Plattennutzung von 40 GB aus, so fänden knapp 25 VMs auf einer LUN Platz. Zieht man noch ein wenig Puffer für Snapshots und SwapDateien ab, wären es noch 24 VMs. Auf allen LUNs wären es 96 virtuelle Maschinen. Vergleichen wir dies mit der Physik von früher. Vorher:
96 Systeme à 2 Festplatten = 192 SCSI Festplatten (pro Platte 72 GB, d. h. eine theoretische Nutzkapazität = 6,75 TB) Nachher:
96 Systeme = 5 SATA-Festplatten Aber – haben diese Festplatten jetzt auch die Leistungsfähigkeit der 192 SCSIFestplatten? Selbst wenn wir davon ausgingen, dass die heutigen SATA-Platten mit den früheren SCSI Festplatten vergleichbar wären (was bei der Performance nicht der Fall ist), dann wäre der Leistungsnachteil der SATA-Lösung immer noch enorm. Geht man von 70 IOPS aus, so wäre die SCSI-Lösung gebündelt 38,4 Mal schneller, was 13.090 IOPS mehr entspricht. Diese Rechnung ist natürlich nicht genau und betrachtet auch nicht die Unterschiede zwischen den RAID-Gruppen, allerdings spiegelt sie den Leistungsunterschied ziemlich gut wider. Somit können Sie sich sehr einfach überlegen, wie leistungsfähig diese RAIDGruppe mit den fünf SATA-Festplatten wirklich ist und dass man die zur Verfügung stehenden Kapazitäten nur ausnutzen könnte, wenn man die virtuellen Maschinen immer abgeschaltet ließe. Bedenken Sie daher immer, dass die Leistungsfähigkeit in IOPS eine viel wichtigere Maßgabe ist als die Kapazitätsmöglichkeiten. Somit ist es auch keine Seltenheit, dass zwar 4 TB zur Verfügung stehen, allerdings nur 1 TB sinnvoll genutzt werden kann, da somit die Performance für die virtuellen Maschinen gewährleistet ist. Es kommt auch immer wieder vor, dass aufgrund der Performance auf einer VMFS-Partition nur fünf virtuelle Maschinen betrieben werden können, ganz unabhängig von weiteren Aspekten wie SCSI-Reservation-Conflicts.
450
Best Practices Storage
8.10.4 LUN-Größe Wenn Sie die beiden vorherigen Abschnitte, »RAID-Größe« und »Geschwindigkeit vs. Kapazität«, bereits gelesen haben, sollte Ihnen bereits der ein oder andere Gedanke zu der richtigen LUN-Größe gekommen sein. Idealerweise versuchen Sie, die LUN-Größe auf einen gemeinsamen Nenner zu bringen, um möglichst gleiche LUNs zu erstellen. Das erleichtert die Verwaltung und die Verteilung. Geht man von VMs mit 40 GB Festplattenkapazität aus, so landet man meist bei acht bis zehn VMs, basierend auf den dahinterliegenden IOPS-Möglichkeiten und den davon abhängigen Lastbedarf der virtuellen Maschinen. In einem solchen Fall wären 400-GB-LUNs bei einer Planung optimal. Haben Sie weniger leistungsfressende VMs, so können Sie natürlich mehr Systeme auf einer LUN unterbringen. Arbeiten Sie mit Thin Provisioning auf dem VMFS oder mit Snapshots, so sollte die Anzahl der VMs auf einer LUN aufgrund der SCSI-Reservations kleiner ausfallen. Dort können Sie auf maximal 1,99 TB LUN-Größe gehen. Die Limitierungen beim ESX-Host-Zugriff können Sie durch die sehr hohen Grenzwerte von vSphere mittlerweile vernachlässigen. Umgekehrt gilt bei sehr leistungsintensiven Systemen wie Datenbanken oder Exchange-/SAP-Systemen, dass weniger VMs pro LUN besser pro RAID-Gruppe betrieben werden. Existieren Ausreißer, z. B. ein System mit 1,5 TB statt der üblichen 40 GB, so sollten Sie die VM entweder mit Raw-Device-Mappings oder einer großen LUN versorgen, auf der Sie die VM alleinig betreiben.
8.10.5 RAID Rebuild und HP EVA Levelling Immer wieder haben Kunden während des laufenden Betriebs das Problem, dass die I/O-Leistung der virtuellen Maschinen sich für einen gewissen Zeitraum deutlich verringert und plötzlich wieder normal ist. Daran ist nicht selten eine Überlastung des Storage-Prozessors in den StorageSystemen schuld, die z. B. durch RAID Rebuild, Deduplizierung, Datenmigrationen oder Levelling ausgelöst wird. Fällt beispielsweise eine Festplatte in einer RAID-5-Gruppe aus, so muss diese Festplatte ersetzt werden, und die verlorenen Daten werden anhand der Parity berechnet und wiederhergestellt. Es kommt hierbei zu keinem Datenverlust, allerdings wird das RAID-System dadurch belastet, was Geschwindigkeitsnachteile für alle an diesem RAID-Controller angeschlossenen Platten bedeutet. Intelligente Storage-Systeme (EMC, HDS ...) erkennen bereits im Vorfeld, wenn sich
451
8.10
8
Storage-Architektur
bei Festplatten Abnutzungserscheinungen aufbauen, und füllen die Hot-SparePlatte schon mit den Daten der entsprechenden Festplatte, bevor diese wirklich ausfällt. In diesem Fall wird der RAID-Rebuild-Prozess minimiert. Ist dies nicht der Fall, so kann ein RAID Rebuild auch weit über 24 Stunden dauern, in denen ein RAID-5-Set natürlich stark durch Ausfall der nächsten Festplatte gefährdet ist, und es kommt zur Leistungsverringerung. Ein äußerst problematischer Fall ist das Levelling, wie es beispielsweise die HP EVA ausführt. Da das EVA-System die RAID-Informationen nicht mittels kompletter Festplatten, sondern Festplattenfragmenten über alle zugeteilten Festplatten verteilt, ist die Performance zwar sehr hoch, allerdings müssen die Daten notfalls neu organisiert (verschoben, migriert) werden. Dies ist zum Beispiel der Fall, wenn neue Festplatten dem EVA Pool zugewiesen werden und die Daten auch mit auf die neuen Festplatten verteilt werden müssen. Dieser Vorgang kann die Speicherleistung enorm verschlechtern, daher sollten Sie einen solchen Schritt auch zeitlich gut überdenken und niemals während der Produktionszeiten ausführen.
452
Nach den theoretischen Grundlagen aus dem vorherigen Kapitel, soll das Buch auch eine praktische Anleitung anhand echter Beispiele liefern. An dieser Stelle erhalten Sie neben den eigentlichen Erläuterungen für die Umsetzung der verschiedenen Speicheranbindungen von vSphere auch nützliche Tuning- und Optimierungstipps.
9
Storage-Konfiguration unter VMware Autor dieses Kapitels ist Oliver Kügow, team(ix) GmbH, [email protected]
Wer die Wahl hat, der hat bekanntlich auch die Qual. Dies gilt umso mehr bei der Auswahl der »richtigen« Speicherumgebung, wenn es um die die Virtualisierung geht. Ohne ein zentrales Storage-System sind viele interessante Funktionen von ESX/ vSphere nicht verfügbar, genau genommen alle Features, die auf sogenannten Shared Storage aufsetzen. Dazu zählen alle Cluster-Funktionen, u. a. VMotion, DRS, HA und FT. Neben den von VMware mitgelieferten Funktionen bieten die meisten Enterprise-Storage-Hersteller auch Mehrwerte gegenüber lokalem Direct-attached Storage (kurz DAS), die auf den ersten Blick nicht ersichtlich sind. Folgende interessante Features auf einem Storage-Array können den Wert einer VMwareUmgebung deutlich erhöhen: 왘
Snapshots
왘
Thin Provisioning
왘
Deduplizierung
왘
Replikation
VMware bietet uns seit der Version 3.0 von ESX die Auswahl für verschiedene Speicheranbindungen, aktuell stehen Fibre-Channel (kurz FCP), iSCSI und NFS zur Verfügung – in der vorherigen Version 2.5 von ESX gab es nur FCP, dadurch stand damals die Wahl der Storage-Anbindung automatisch fest. Die Auswahl wird ganz klar auch durch den Kauf oder den Besitz einer zentralen Speicherlösung beeinflusst. In vielen Fällen muss gar nicht gewählt werden, da verschiedene Hersteller gerne auf festgelegte Technologien setzen. So verwenden
453
9
Storage-Konfiguration unter VMware
EqualLogic/Dell und HP/Lefthand ausschließlich iSCSI, die Firmen Hitachi Data Systems und HP/EVA zum Beispiel hingegen ausschließlich Fibre-Channel-Konnektivität. Um einen einfachen und direkten Vergleich zwischen den verschiedenen Technologien zur Speicheranbindung zu liefern, fiel die Wahl für dieses Kapitel auf den Hersteller NetApp, da dieser als Vorreiter im Unified-Storage-Umfeld gilt. Unified Storage bedeutet, dass der Kunde mit einem einzigen Speicher-Controller alle Storage-Protokolle gleichzeitig anbieten und verwenden kann. Daher sprechen wir in diesem Kapitel auch gelegentlich von »Filer«, der offiziellen Bezeichnung von NetApp für die Storage-Systeme. Es handelt sich allerdings nach wie vor um ein Storage-System, das heißt, wenn Sie IBM, HP, EMC oder andere Systeme einsetzen, können Sie die Erläuterungen dieses Kapitels größtenteils 1:1 nutzen. Im Block-Storage-Umfeld ist das neben dem klassischen FCP und iSCSI neuerdings auch das Protokoll Fibre-Channel over Ethernet (kurz FCoE). Für den Zugriff auf file-basierten Storage stehen bei NetApp die beiden bekannten Protokolle CIFS und NFS zur Verfügung. CIFS ist in vSphere/ESX nicht unterstützt, deshalb wird es keine Beachtung finden. Auch auf FCoE können wir leider nicht eingehen, da die dafür notwendige Infrastruktur momentan noch nicht zur Verfügung steht – die Technologie ist schlichtweg zu neu. Im Laufe dieses Kapitels werden wir die Anbindungen über FCP, iSCSI und NFS konfigurieren und verwenden. Außerdem erklären wir Ihnen den Umgang mit Datastores, Pfaden und den neuen Storage Views. Es wird der gesamte Weg aufgezeigt, vom Storage-Array über die verschiedenen Switches hin zum ESX-Host und die Verwendung des Speicherplatzes als VMware Datastore. Da dieser Vorgang nicht beim Mapping der LUNs an den ESX-Hosts beginnt, geht dieses Kapitel in der richtigen Reihenfolge vor und beginnt beim Einrichten der Switches und des Storage.
9.1
Verwendungszwecke von Storage
Bei der Verwendung von Storage im Zusammenhang mit vSphere denkt man zuerst daran, wie die virtuellen Maschinen und ihre (vmdk-)Files abgelegt werden, bzw. daran, über welche Technologie der zentrale Massenspeicher angebunden wird. Mit anderen Worten: Storage in Form eines Datastores, egal ob blockoder file-basiert.
454
Einrichtung und Konfiguration von Datastores
Jedoch gibt es auch einige andere interessante Aspekte zu beachten: dazu gehört die Verwendung von Storage für die Service Console (dem sogenannten Console Operating System, COS), aber auch der Anwendungsfall Speicherplatz innerhalb der virtuellen Maschine.
9.2
Einrichtung und Konfiguration von Datastores
Im Folgenden gehen wir die Konfiguration von Datastores Schritt für Schritt durch, beginnend bei der Storage-/Netzwerkinfrastruktur bis zur eigentlichen Erstellung der Datastores.
9.2.1
Fibre-Channel
Notwendige Infrastruktur Um eine Fibre-Channel-Infrastruktur zu realisieren, benötigen Sie einige Komponenten. Auf der Seite der ESX-Hosts wird im FCP-Umfeld von den sogenannten Initiators gesprochen, die Seite des Speichersystems wird meist als »Target« bezeichnet. Die Initiators stellen sich in Form von HBAs (Host-Bus-Adapter) dar, also FCPKarten. Pro ESX-Host sollten mindestens zwei FCP-Ports zur Verfügung stehen, am besten in Form von zwei Karten mit mindestens einem Port. Eine Dual-PortKarte funktioniert zwar auch, ist aber weniger redundant. Zwischen den Initiatoren (ESX-Hosts) und dem Target (Speichersystem) wird als Transportweg die Fabric verwendet, meist ein Verbund aus einem oder mehreren Fibre-Channel-Switches. Für eine echte Redundanz benötigen Sie mindestens zwei unabhängige Switches: jeder dieser Switches stellt eine eigene Fabric dar. Auf der Target-Seite findet man in der Regel geclusterte Controller vor, die über mehrere Target-Ports verfügen, einen Target-Port für jede Fabric. Wenn Sie also z. B. pro Cluster-Knoten des Speichersystems zwei Target-Ports haben (einen für jede Fabric), so stehen insgesamt vier Target-Ports zur Verfügung, über die Sie LUNs ansprechen können. Je nachdem, ob es sich um einen aktiv/aktiv-Cluster oder um einen aktiv/standby-Cluster handelt, stehen möglicherweise nur zwei aktive Target-Ports zur Verfügung. Das Schaubild in Abbildung 9.1 zeigt einen NetApp-aktiv/aktiv-Cluster mit einem ESX-Host und zwei Fibre-Channel-Switches.
455
9.2
Storage-Konfiguration unter VMware
HBA 2
ESX-Host HBA 1
9
Switch
Switch
Target-HBAs
0b
0a
0b
0a
Target-HBAs
vtic Filer X
lun_1
Filer Y (partner)
lun_2
Abbildung 9.1 Blaupause einer Infrastruktur vom ESX-Host mit den entsprechenden HBAs bis zum redundanten Storage
Arbeiten an der Infrastruktur Bevor Sie das Speichersystem oder den ESX-Host konfigurieren, müssen Sie zuerst die Infrastruktur aufbauen, verkabeln und konfigurieren. Bei Fibre-Channel sind damit konkret die Switches gemeint. Über das sogenannte Zoning werden Kommunikationswege im Fibre-ChannelNetzwerk festgelegt, also »welcher Host darf mit welchem Storage sprechen«. Das Zoning dient neben den offensichtlichen Sicherheitsgründen auch dem Ausschluss von Fehlern – Rechner, die nicht miteinander kommunizieren sollen, können sich dank des Zonings nicht stören. Das Zoning zeigen wir hier kurz anhand von Brocade-FCP-Switches: br2003:admin> switchName: switchType: switchState: switchMode: switchRole: switchDomain:
456
switchshow br2003 34.0 Online Native Principal 1
Einrichtung und Konfiguration von Datastores
switchId: switchWwn: zoning: switchBeacon:
fffc01 10:00:00:05:1e:04:54:09 ON (c_vSphere) OFF
Area Port Media Speed State Proto ===================================== 0 0 id N2 Online F-Port 1 1 id N2 Online F-Port 2 2 id N4 Online F-Port
50:0a:09:81:96:68:33:2c 50:0a:09:81:86:68:33:2c 10:00:00:00:c9:89:2c:e1
Es handelt sich bei br2003 um einen der beiden Brocade-Switches aus der 200erSerie. Auf den Ports 0 und 1 sind die beiden Target-Ports (0a) der NetApp-Controller na3021 und na3022, auf Port 2 ist ein ESX-Host angeschlossen. In der Praxis sähe man von allen ESX-Hosts jeweils einen Initiator-Port, hier haben wir lediglich ein einziges System zur Verfügung. Wichtig ist, dass Sie auch für die Initiatoren jedes ESX-Hosts eine eigene Zone anlegen, um spätere Probleme zu vermeiden. Sie sollten nie eine einzige Zone, die alle ESX-Host-Initiatoren und Target-Ports enthält, nutzen. Nun vergeben Sie für die nur schwer lesbaren WWPNs (World-Wide-PortNames) sprechende Namen, die »Aliasse«: br2003:admin> alicreate "na1_p1","50:0a:09:81:96:68:33:2c" br2003:admin> alicreate "na2_p1","50:0a:09:81:86:68:33:2c” br2003:admin> alicreate "esx_p1","10:00:00:00:c9:89:2c:e1“
Bei jeglicher Art von Zoning ist es übrigens sehr empfehlenswert, immer nur per Cut & Paste zu arbeiten und sich niemals dazu hinreißen zu lassen, die WWPNs per Hand einzugeben – das ist schlichtweg zu fehleranfällig. Anschließend erstellen Sie eine Zone, die Sie sich am einfachsten als eine Art »Kommunikationszone« vorstellen. Alle Geräte (genauer: alle Ports), die sich in dieser Zone befinden, dürfen miteinander kommunizieren: br2003:admin> zonecreate "z_vSphere_Fabric1","na1_p1; na2_p1; esx1_p1"
Schließlich müssen Sie die gerade erstellte Zone noch zur laufenden Konfiguration hinzufügen oder wie hier– falls noch keine Konfiguration vorhanden ist – eine solche erstellen: br2003:admin> cfgcreate “c_vSphere","z_vSphere_Fabric1"
Nun aktivieren Sie die eben erstellte Konfiguration des Switches – gespeichert wird anschließend immer automatisch:
457
9.2
9
Storage-Konfiguration unter VMware
br2003:admin> cfgenable "c_vSphere" This action will replace the old zoning configuration with the current configuration selected. Do you want to enable 'c_ vSphere' configuration (yes, y, no, n): [no] y zone config "c_vSphere" is in effect Updating flash ...
Das Ergebnis des Zonings und die fertige Konfiguration für unsere Testumgebung mit einem ESX-Host und einem NetApp-Cluster (zwei Knoten) schaut auf dem Brocade-Switch wie folgt aus: br2003:admin> cfgshow Defined configuration: cfg: c_vSphere z_vSphere_Fabric1 zone: z_vSphere_Fabric1 na1_p1; na2_p1; esx1_p1 alias: esx1_p1 10:00:00:00:c9:89:2c:e1 alias: na1_p1 50:0a:09:81:96:68:33:2c alias: na2_p1 50:0a:09:81:86:68:33:2c Effective configuration: cfg: c_vSphere zone: z_vSphere_Fabric1 50:0a:09:81:96:68:33:2c 50:0a:09:81:86:68:33:2c 10:00:00:00:c9:89:2c:e1
Die entsprechende Konfiguration müssen Sie anschließend auch noch in der anderen Fabric durchführen – quasi die gleiche Arbeit noch einmal machen, nur mit den anderen WWPNs der restlichen Initiator-Ports (auf ESX-Seite) und Target-Ports (auf NetApp-Seite). Hier nur zum Nachvollziehen die Befehle, ohne den gesamten Output zu wiederholen: br2004:admin> br2004:admin> br2004:admin> br2004:admin> br2003:admin> br2003:admin>
alicreate "esx1_p2","10:00:00:00:c9:89:2c:e0" alicreate "na1_p2","50:0a:09:82:86:68:33:2c" alicreate "na2_p2","50:0a:09:82:96:68:33:2c" zonecreate "z_vSphere_f2","esx1_p2;na1_p2;na2_p2" cfgcreate “c_vSphere","z_vSphere_Fabric2" cfgenable "c_vSphere"
Ist auch dies geschafft, so ist die grundsätzliche Kommunikation hergestellt, und Sie stellen im nächsten Schritt auf dem Storage-System eine gewisse Menge Speicher für unser VMware-Datastore zur Verfügung (Provisionierung).
458
Einrichtung und Konfiguration von Datastores
Arbeiten am Storage-System Um dem ESX-Host eine gewisse Menge Speicherplatz zur Verfügung zu stellen, müssen Sie zuerst auf der NetApp eine LUN anlegen. Diese LUN wird später vom ESX mit VMFS-3 formatiert und somit zu einem nutzbaren Datastore, auf dem die Files für virtuelle Maschinen abgelegt werden. Auf dem NetApp-Storage-System werden – anders als bei den meisten Herstellern – die LUNs nicht direkt auf einer RAID-Gruppe eingerichtet. LUNs sind bei NetApp immer in einem Container abgelegt, dem sogenannten Volume. Bildlich können Sie sich vorstellen, dass eine LUN nur eine sehr große Datei in einem Volume ist – ähnlich wie ein vmdk-Disk-Image auch nur eine sehr große Datei in einem normalen Dateisystem ist (z. B. in einem NTFS-File-System im Falle von VMware Workstation). Deshalb müssen Sie zuerst ein Volume anlegen. Dieses Volume ist wiederum ein Bestandteil eines sogenannten Aggregats, das – vereinfacht gesprochen – ein großer RAID-Verbund auf einer NetApp ist. Wir gehen davon aus, dass ein Aggregat bereits vorhanden ist. Das Volume erstellen Sie wie folgt: na3021> vol create esxfcp aggr0 500g Creation of volume 'esxfcp' with size 500g on containing aggregate 'aggr0' has completed.
Da in diesem Volume nur LUNs (und keine Files) abgelegt werden, müssen Sie die Snapshot-Reserve anschalten – auch den automatischen Snapshot-Scheduler müssen Sie deaktivieren: na3021> snap reserve esxfcp 0 na3021> vol options esxfcp nosnap on
Als Ergebnis steht der gesamte angegebene Platz von 500 GB zur Verfügung. Nun legen Sie in diesem Volume mehrere LUNs an, in diesem Fall zwei LUNs mit je 200 GB: na3021> lun create -s 200g -t vmware -o noreserve /vol/esxfcp/fcp_ds1.lun na3021> lun create -s 200g -t vmware -o noreserve /vol/esxfcp/fcp_ds2.lun
Sie sollten die LUNs nicht zu groß oder klein erstellen, da einige Faktoren abzuwägen sind:
459
9.2
9
Storage-Konfiguration unter VMware
Backup- und Restore-Zeiten Je nachdem, wie gesichert wird, dauern das Backup und die Rücksicherung einer sehr großen LUN unter Umständen zu lange, um die vorgegebenen SLAs (Service Level Agreements) und die damit verbundenen RTOs (Recovery Time Objectives) einzuhalten. Anzahl der VMs pro LUN Viele virtuelle Maschinen pro LUN haben zwar den Vorteil, dass Sie insgesamt weniger Datastores verwalten müssen, allerdings wird dadurch auch die Performance negativ beeinflusst, da das VMFS bei Metadatenupdates die gesamte LUN sperrt (SCSI-Locking). Je mehr VMs, desto mehr Metadatenupdates und auch mehr Locks. Die Anzahl der VMs hängt auch von den Outstanding I/Os auf dem Storage-Array ab (LUN Queue Length). Unterstützt das Array z. B. 256 I/Os pro LUN und hat eine durchschnittliche VM vier I/Os pro Sekunde, so sollten Sie maximal 64 VMs pro Datastore ablegen (256 / 4 = 64). Best Practice ist aber aus der Praxiserfahrung, maximal ca. 30 VMs pro LUN-Datastore abzulegen. Diese Zahlen sind in jedem Fall abhängig vom Lastverhalten der virtuellen Maschinen und davon, wie stark Snapshots und Thin Provisioning bei virtuellen Maschinen genutzt wird. In unserem Fall gehen wir von ca. 10 GB Platzverbrauch pro virtueller Maschine aus, somit können wir auf einem 200-GB-Datastore circa 20 VMs ablegen; da aber Auslagerungsdateien und VM-Snapshots auch Platz belegen, lautet die Empfehlung, nur etwa 15 VMs einzurichten. An diesem Punkt sind wir so weit, dass: 왘
die ESX-Hosts und der NetApp-Cluster sich aufgrund des Zonings bereits »sehen« können,
왘
auf der NetApp LUNs erstellt wurden.
Jetzt ist es noch notwendig, die LUNs auch den ESX-Hosts zu »zeigen«, in Fachtermini spricht NetApp vom sogenannten Mapping. Andere Hersteller bezeichnen einen ähnlichen Vorgang als »Masking«. Eine LUN wird nie direkt an eine WWPN-Nummer gezeigt, sondern immer nur an eine Gruppe von WWPNs, da ja ein einzelner Host meist mehrere FC-Adapter und somit auch mehrere WWPNs besitzt. Diese Gruppe von WWPNs wird als Initiator-Group oder kurz iGroup bezeichnet. Im Falle des ESX-Clusters sollen sogar mehrere Hosts auf die gleiche LUN zugreifen (»Shared Storage«), also sollten Sie die LUNs in diesem Fall an alle sichtbaren
460
Einrichtung und Konfiguration von Datastores
ESX-Hosts zeigen – Sie nehmen einfach alle WWPNs in die iGroup auf. Die momentan verbundenen Initiator-WWPNs lassen Sie sich wie folgt anzeigen: na3021> fcp show initiator Initiators connected on adapter 0a: Portname Group -----------10:00:00:00:c9:89:2c:e1 Initiators connected on adapter 0b: Portname Group -----------10:00:00:00:c9:89:2c:e0
Sie sehen also zwei Initiatoren, einen über jeden FC-Target-Port der NetApp. Anschließend nehmen Sie diese in die neue Initiator-Group auf: na3021> na3021> na3021> na3021>
igroup create -f -t vmware esxfcp_all igroup add esxfcp_all 10:00:00:00:c9:89:2c:e0 igroup add esxfcp_all 10:00:00:00:c9:89:2c:e1 igroup show esxfcp_all (FCP) (ostype: vmware): 10:00:00:00:c9:89:2c:e0 (logged in on: 0b, vtic) 10:00:00:00:c9:89:2c:e1 (logged in on: 0a, vtic)
Die beiden WWPN sind also in der iGroup, und Sie sehen sehr schön, dass jede WWPN zweimal eingeloggt ist: einmal direkt über den Adapter 0a oder 0b, und ein zweites Mal indirekt über den VTIC, den virtuellen getunnelten Interconnect. NetApp verwendet im FCP-Umfeld einen Cluster-Modus (cfmode), der sich single_image nennt. Die beiden Cluster-Knoten der NetApp, die ja eigentlich zwei Systeme sind, melden sich den Hosts gegenüber als ein einziges System – eben dem Single Image –, indem sie die gleiche WWNN präsentieren. Der Host sieht also ein und dieselbe LUN über vier Pfade: die zwei direkten und die zwei indirekten, die über den Cluster-Partner laufen. Die beiden direkten Pfade sind dabei den indirekten vorzuziehen, da die indirekten Pfade über den NetApp-Cluster-Interconnect transportiert werden, was zu höherer Last auf dem Partner führt, den Interconnect unnötig belastet und auch gesteigerte Latenz mit sich bringt. Stellt die Multipathing-Software auf dem ESXHost die Pfade nicht korrekt ein, bekämen Sie auf der NetApp die Fehlermeldung »FCP Partner Path misconfigured«. Unter ESX 3.x war es noch nötig, die präferierten Pfade auf dem Host manuell auszuwählen oder ein NetApp-Tool zur Auswahl zu installieren (FCP Host Utilities); seit Version vSphere 4 können Sie auf dem ESX-Host und der NetApp auch
461
9.2
Storage-Konfiguration unter VMware
d
HBA 2
ESX-Host HBA 1
9
d
i Switch
Switch
Target-HBAs
Target-HBAs
vtic Filer X
lun_1
Abbildung 9.2
0b
0a
0b
0a
i
Filer Y (partner)
lun_2
Direkte (d) und indirekte (i) Pfade im Überblick
einfach das Feature ALUA (Asynchronuous LUN Access) aktivieren – die NetApp teilt dem ESX-Host über das SCSI-Protokoll mit, welche Pfade zu bevorzugen sind. Neu in ESX 4 ist auch, dass Sie nun pro LUN mehrere Pfade gleichzeitig aktiv nutzen, also echtes Load-Balancing beim Multipathing realisieren können. Also schalten Sie für die iGroup auf der NetApp-Seite ALUA ein (ALUA ist bei NetApp nur im Fibre-Channel-Umfeld zu nutzen): na3021> igroup set esxfcp_all alua yes
Im letzten Schritt sollten Sie auf dem NetApp-System noch die Verbindung zwischen der LUN und der iGroup herstellen – Sie müssen das LUN-Mapping durchführen. Beachten Sie dabei, dass LUN-IDs nie doppelt vergeben werden dürfen – sowohl in der selben iGroup als auch über die beiden Cluster-Knoten hinweg, da sich ja beide Knoten dem Host gegenüber wie das gleiche Speichersystem ausweisen. Das LUN-Mapping ist relativ einfach und logisch zu erklären, im Prinzip wird nur konfiguriert: »Welche LUN zeige ich welcher iGroup als welche ID?« na3021> lun map /vol/esxfcp/fcp_ds1.lun esxfcp_all 1 na3021> lun map /vol/esxfcp/fcp_ds2.lun esxfcp_all 2 na3021> lun show -m
462
Einrichtung und Konfiguration von Datastores
LUN path Mapped to LUN ID Protocol ------------------------------------------------------/vol/esxfcp/fcp_ds1.lun esxfcp_all 1 FCP /vol/esxfcp/fcp_ds2.lun esxfcp_all 2 FCP
Nun sind alle Tätigkeiten zum Provisionieren von LUN-Storage auf NetApp-Seite geschafft: 왘
Volume angelegt
왘
LUNs angelegt
왘
iGroup erstellt
왘
LUNs an iGroup gemappt
Jetzt können Sie zum ESX-Host wechseln, um die bereitgestellten LUNs zu finden und anschließend als VMFS-Datastore zu labeln (formatieren). Arbeiten am ESX-Host Um neue Block-Devices auf dem ESX-Host zu finden, müssen Sie zunächst einmal an den entsprechenden Host-Bus-Adaptern nach neuen Geräten suchen. Um die folgenden Vorgänge anschaulicher zu gestalten, demonstrieren wir die Beispiele anhand von Screenshots. Für die Arbeiten ist ein Virtual Infrastructure Client nötig, der sich entweder direkt auf einen ESX-Host verbindet oder auf einen vCenter-Server, der den entsprechenden Host verwaltet. Im Reiter Konfiguration wählen Sie Speicheradapter aus; Abbildung 9.3 zeigt die vorhandenen Fibre-Channel-Karten vom Typ Emulex und deren dazugehörige WWPN, die wir schon bei der NetApp-Konfiguration mit in die iGroup genommen haben. Das Bild zeigt auch noch einen dritten HBA, den Sie aber ignorieren können; wichtig sind die HBAs vmhba18 und vmhba19.
Abbildung 9.3
Die Speicheradapter und ihre WWPNs
463
9.2
9
Storage-Konfiguration unter VMware
Nun scannen Sie auf diesen HBAs nach neuen Geräten. Es gibt zwei Arten von Scans: Die »kleine« Variante durchsucht nur einen speziellen ausgewählten Adapter (Rechtsklick auf den gewünschten Adapter) nach neuen LUNs/Targets und ignoriert den Inhalt der gefundenen LUNs. Den etwas ausführlicheren Scan hingegen erreichen Sie per Klick auf Erneut prüfen oben rechts im Bild; er scannt alle vorhandenen Adapter gleichzeitig nach neuen LUNs/Targets und prüft, ob auf den neu gefundenen LUNs bereits ein VMFS-3-File-System vorhanden ist. Wir wählen den ausführlicheren Scan, damit alle Adapter geprüft werden.
Abbildung 9.4
Beim ausführlichen Scan Geräte und VMFS-Volumes suchen
Abbildung 9.5
Der Scan wird als Task angezeigt.
Nach dem Scan werden auf beiden HBAs die LUNs gefunden, wie Abbildung 9.6 und Abbildung 9.7 zeigen.
Abbildung 9.6
Am vmhba18 wurden beide 200-GB-LUNs erkannt ...
Nachdem unsere LUNs nun erkannt wurden, müssen wir prüfen, ob diese auch die volle Redundanz der Pfade besitzen. Ein Rechtsklick auf eine der LUNs und die Auswahl Pfade verwalten zeigt vier Pfade zur selben LUN (hier LUN #1).
464
Einrichtung und Konfiguration von Datastores
Abbildung 9.7
… ebenso finden wir beide LUNs am vmhba19.
Abbildung 9.8
Die vier Wege zu jeder FC-LUN: zwei Wege über jeden HBA
Warum es vier Pfade zur gleichen LUN gibt, wurde im vorherigen Abschnitt schon erklärt, und an dieser Stelle sehen Sie diese Tatsache sehr schön. Auf der rechten Seite in Abbildung 9.8 erkennen Sie, dass alle vier Pfade funktionieren (Aktiv), die I/O-Befehle aber nur über einen einzigen Pfad laufen, den »bevorzugten« (siehe *-Symbol). Wegen der Nutzung von Fixed (»Festes«) Multipathing ist ALUA nicht aktiv, da VMware davon ausgeht, dass der Administrator weiß, welche Pfade optimal sind und welche nicht. MRU und Round-Robin sind ALUA-fähig. Um optimale Performance zu den LUNs zu bekommen, sollten Sie das LoadBalancing nach Round-Robin-Algorithmus aktivieren – dadurch werden die I/Os über alle direkten Pfade zum NetApp-Controller geschickt. Welche die direkten
465
9.2
9
Storage-Konfiguration unter VMware
Pfade sind und welche die indirekten, teilt die NetApp dem ESX-Host über die ALUA-SCSI-Kommando automatisch mit. Die Voraussetzung dafür ist, dass wir das Native-Multipathing-Plug-in (NMP) von ESX informieren, welche Art von Path Selection Policy (PSP) durchgeführt werden soll und um welche Art von Storage-Array es sich bei einem NetApp-Cluster handelt. Dafür muss das Storage-Array Type Plug-in manuell auf ALUA gestellt werden oder der ESX Host erkennt ALUA-Funktionalität beim ersten Scan der NetApp iGroup schon automatisch. Diese Vorgänge sind in der aktuellen Version 4.0 allerdings nur über die Kommandozeile möglich, eventuell wird VMware später ein grafisches Menü zur Verfügung stellen. [root@rx3023-esx~]# esxcli nmp satp setdefaultpsp –psp VMW_PSP_RR --satp VMW_SATP_ALUA Default PSP for VMW_SATP_ALUA is now VMW_PSP_RR
Anschließend sollten Sie den ESX-Host neu starten; beim nächsten Hochfahren erkennt dieser das NetApp-System als ALUA-Gerät (VMW_SATP_ALUA), und dafür wurde durch den Befehl oben als Path Selection Policy Round-Robin eingestellt – die I/Os werden gleichmäßig über beide Pfade verteilt, siehe Abbildung 9.9.
Abbildung 9.9
ESXTOP: gleichmäßige Lastverteilung auf vmhba18/19
Auch die grafische Pfadanzeige im vCenter-Client zeigt die beiden aktiven Pfade deutlich an, Sie erkennen auch die geänderte SATP-Variante ALUA (Abbildung 9.10). Nachdem an diesem Punkt die LUNs erkannt wurden und Sie das Load-Balancing sowie die Pfade korrigiert haben, müssen Sie die LUNs mit VMFS-3-Dateisystem formatieren – dadurch werden sie zu einem Datastore. Diesen Vorgang können Sie sowohl grafisch als auch auf der Kommandozeile erledigen. Hier die grafische Variante.
466
Einrichtung und Konfiguration von Datastores
Abbildung 9.10
MPIO-Load-Balancing per Round-Robin über beide HBAs
Abbildung 9.11
Speicher hinzufügen
Wählen Sie im Reiter Konfiguration den Menüpunkt Speicher, und klicken Sie auf den Knopf Speicher hinzufügen.
Abbildung 9.12
FC ist Blockspeicher, eine LUN.
467
9.2
9
Storage-Konfiguration unter VMware
Wählen Sie Festplatte/LUN, da ein Blockspeicher formatiert werden soll. Der gleiche Vorgang wird übrigens auch für lokale Festplatten und RAIDs sowie für iSCSI durchgeführt. Die andere Auswahl, Netzwerkdateisystem (NFS erklären wir in Abschnitt 9.2.3, »NFS-Datastores«.)
Abbildung 9.13
Wählen Sie eine der beiden leeren LUNs aus.
Es werden alle gefundenen Geräte ohne Partitionstabelle angezeigt – da davon ausgegangen wird, dass sie leer sind – sowie Geräte mit freien, nicht partitionierten Bereichen. Wir wählen eine unserer frischen LUNs.
Abbildung 9.14
Informationen über den aktuellen Zustand der LUN (leer)
In diesem Schritt vergeben Sie einen sprechenden Name für den Datastore. Die Empfehlung lautet, den Namen des beherbergenden Speichersystems, das Speicherprotokoll und die LUN-ID mit in den Namen aufzunehmen. Dadurch behalten Sie später, wenn mehrere LUNs vorhanden sind, einen besseren Überblick.
468
Einrichtung und Konfiguration von Datastores
Abbildung 9.15
Namen für den Datastore wählen
Abbildung 9.16
Blockgröße auswählen und Kapazität maximieren
Im folgenden Dialogfeld können Sie zwei Parameter einstellen, die Blockgröße des VMFS und ob die Kapazität maximiert werden soll. Von der Blockgröße des File-Systems leitet sich die maximale Größe einer einzelnen Datei innerhalb des VMFS ab. Die Standardauswahl von 1 MB Blocksize sollte für die meisten Anwendungen reichen, da hieraus eine Dateigröße von 256 GB resultiert, also ein vmdk-File nicht größer als 256 GB werden darf. Positive Auswirkungen auf die Performance sind bei verschiedenen Blockgrößen eher minimal (+ 1–3 %), dafür ist der Platzverschnitt bei sehr kleinen Dateien relativ groß. Die Empfehlung ist: Falls Sie nicht planen, vmdk-Dateien mit mehr als 256 GB Größe zu erstellen, sollten Sie den Wert von 1 MB beibehalten. Mit dem zweiten Parameter, Kapazität maximieren, wird der Platz der gesamten LUN verwendet, es werden keine weiteren Partitionen erstellt. Aus Gründen der Übersichtlichkeit und der späteren Verwaltung wird empfohlen, pro LUN nur einen Datastore anzulegen.
469
9.2
9
Storage-Konfiguration unter VMware
Abbildung 9.17
Zusammenfassung der Datastore Einstellungen
Abbildung 9.18
Der neue, 200 GB große FC-Datastore ist fertig.
Nachdem Sie den Datastore angelegt haben, können Sie ihn für virtuelle Maschinen oder ISO-Files verwenden. Abschließend werfen wir in Abbildung 9.19 noch einen kurzen Blick auf die Eigenschaften des Datastores.
Abbildung 9.19
470
Datastore-Eigenschaften
Einrichtung und Konfiguration von Datastores
9.2.2
iSCSI
Nach der »klassischen« Anbindung von ESX-Hosts an das Speichersystem über Fibre-Channel-Technologie betrachten wir nun eine modernere Alternative: iSCSI. Wie der »SCSI«-Teil des Namens schon suggeriert, handelt es sich dabei um blockorientierten Storage, allerdings werden die SCSI-Kommandos und -Daten nicht über FC transportiert, sondern über IP. iSCSI erfreut sich steigender Beliebtheit, da viele Administratoren aus dem kleineren Mittelstand vor einer Investition in Fibre-Channel zurückschrecken, sowohl hinsichtlich Switches als auch, was das Erlernen von neuem Wissen angeht. iSCSI dagegen ist relativ schnell einsetzbar, weil oft Netzwerkkenntnisse vorhanden sind und die Netzwerk-/LAN-Infrastruktur sowieso. Wo für FCP noch zwingend HBAs gekauft werden müssen, haben Sie bei iSCSI die Wahl: Kaufe ich einen iSCSI-HBA, oder nehme ich einen iSCSI-Softwaretreiber, der die vorhandene LAN-Karte verwendet? Beide haben Vor- und Nachteile: Die iSCSI-HBA-Karte belastet die Host-CPU weniger und erlaubt das Booten von iSCSI-LUNs, kostet aber Geld und einen PCI-Slot. Softwaretreiber belasten die CPU, sind nicht bootfähig – dafür aber sind sie meist kostenlos. Arbeiten an der Infrastruktur Für iSCSI ist bei der Infrastruktur eigentlich nur das LAN wichtig, allerdings gibt es hier auch einiges zu beachten, um optimale Ergebnisse zu erzielen. Die LAN-Switches sollten auf keinen Fall überbucht sein, das heißt, Sie müssen auf allen Ports, die mit iSCSI zu tun haben, darauf achten, dass wirklich volle 1 GBit/s zur Verfügung stehen. Viele Switch-Hersteller überbuchen ihre Switches, es ist also nicht auf allen Ports die volle Bandbreite verfügbar – das kann zu erheblichen Performance-Einbußen führen. Sie sollten sich nicht von der Namhaftigkeit eines Switch-Herstellers blenden lassen, sondern am besten die technische Spezifikation zu Rate ziehen. Erfahrungen haben gezeigt, dass z. B. ein 48Port-Einschub mit 1-GBit-Port eines bekannten Switch-Herstellers nur über 8 GBit/s auf der Backplane verfügt, der Switch also um Faktor 1:6 überbucht ist. In punkto Redundanz sei angemerkt, dass es bei iSCSI nicht sinnvoll ist, einen Etherchannel (oder LACP, je nach Hersteller) zu bauen – es steigt dadurch weder die Geschwindigkeit (IP-Hash-Verteilung funktioniert nicht, weil nur eine Ziel-IP der NetApp existiert) noch die Redundanz (wenn die Uplink-Ports des vSwitches auf den gleichen LAN-Switch verbunden sind). Bei iSCSI sollten Sie einen eigenen vSwitch konfigurieren, der mit zwei Uplinks auf verschiedene Switches verbunden ist. An diesem vSwitch müssen Sie zwei Port-Groups erstellen, jeweils vom Typ »VMkernel«, diese werden die iSCSI-Connections bedienen. Sehr wich-
471
9.2
9
Storage-Konfiguration unter VMware
tig ist, dass jede dieser Portgruppen nur einen aktiven Uplink besitzt, der andere Port muss zwingend auf »unused« stehen, nicht auf »Standby«, sonst kommt es später zu Fehlermeldungen.
Abbildung 9.20
Pro Portgruppe: ein Adapter »active«, der andere »unused«
Abbildung 9.21
vSwitch mit zwei VMkernel-Port-Groups
Die genauere Konfiguration der iSCSI-Software-HBAs und der Portgruppen wird später noch gezeigt, an dieser Stelle sind nur die Vorarbeiten im LAN-Umfeld wichtig. Um iSCSI noch leistungsfähiger zu gestalten und die CPU-Auslastung auf dem ESX-Host möglichst niedrig zu halten, ist der Einsatz von Jumbo-Frames im Netzwerksegment empfehlenswert. Jumbo-Frames sind LAN-Frames mit einer Größe von 9K (statt der normalen Maximum Transfer Unit von 1.500 Bytes). Da typische I/O-Größen von VMs zwischen 4K und 8K liegen, passen die meisten I/Os in einen einzigen LAN-Frame, die Latenz sinkt durch ausbleibende Segmentierung. Bei Jumbo-Frames ist zu beachten, dass alle Komponenten in diesem LANSegment oder VLAN eine MTU von 9.000 besitzen müssen! Für VMkernel-Interfaces müssen Sie manuell auf der ESX Service Console Folgendes einstellen: esxcfg-vswitch –m 9000 vSwitch1
472
Einrichtung und Konfiguration von Datastores
9.2
esxcfg-vmknic -a "vmk-IPSTORAGE" -i 192.168.123.1 -n 255.255.255.0 -m 9000 esxcfg-vmknic -a "vmk-IPSTORAGE2" -i 192.168.124.1 -n 255.255.255.0 -m 9000
Dabei kann es nötig sein, die vorher angelegten VMkernel-Ports noch einmal auf der grafischen Oberfläche zu löschen: offensichtlich handelt es sich dabei um einen Bug – falls die Interfaces vorher nicht vorhanden waren, schlägt das Kommando immer fehl. Das Ergebnis sollte so aussehen: esxcfg-vmknic -l Interface Port Group/DVPort IP Family IP Address Netmask Broadcast MAC Address MTU TSO MSS vmk1 vmk-IPSTORAGE IPv4 192.168.123.1 255.255.255.0 192.168.123.255 00:50:56:75:bb:76 9000 65535 vmk0 vmk-IPSTORAGE2 IPv4 192.168.124.1 255.255.255.0 192.168.124.255 00:50:56:79:00:12 9000 65535
Enabled Type true STATIC true STATIC
Jumbo-Frames können allerdings auch eine Problemquelle sein. Deshalb sollten Sie das iSCSI-Netzwerk erstmals ohne diese eingerichtet und getestet sein; für mehr Performance können Sie später immer noch umstellen. Arbeiten am Storage-System Der iSCSI-Dienst muss auf einem NetApp-System erst einmal gestartet werden, das geschieht mit dem Kommando iscsi start. Es handelt sich wie bei allen Protokollen auf NetApp um ein lizenzpflichtiges Feature, allerdings hat NetApp schon immer iSCSI-Lizenzen kostenlos an die Kunden vergeben, um möglichst schnell Marktanteile zu gewinnen. Die Arbeiten für die Bereitstellung von iSCSI-LUNs sind auf NetApp-Seite sehr ähnlich wie die Konfiguration von Fibre-Channel. In beiden Fällen müssen Sie Volumes, LUNs und iGroups erstellen. Der wichtigste Unterschied liegt darin, dass es sich um eine iSCSI-iGroup handelt, die sogenannte IQNs enthält. Die FCPiGroup enthielt dagegen die WWPNs. IQN steht für iSCSI Qualified Name und bezeichnet einen iSCSI-Host (egal ob Initiator oder Target) eindeutig – unabhängig davon, wie viele LAN-Karten oder Host-Namen das Gerät hat. Ein Beispiel für einen solchen IQN-Namen ist: iqn.1998-01.com.vmware:rx3023-esx-1ad9214f. Er besteht aus dem umgedrehten Datum der Domain-Registrierung, dem umgedrehten Domain-Namen selbst und – durch einen Doppelpunkt getrennt – einem eindeutigen String, bei vSphere sind das der ESX-Host-Name und einige zufällig gewählte Zeichen. Bis auf die iGroup-Konfiguration führen Sie also den gleichen Vorgang wie bei FCP durch, begonnen mit dem Anlegen eines Volumes: na3022> vol create esx_iscsi aggr0 200g Creation of volume 'esx_iscsi' with size 200g on containing aggregate 'aggr0' has completed.
473
9
Storage-Konfiguration unter VMware
Auf dem Volume sollten Sie auch wieder automatische Snapshots deaktivieren, für Backup-Zwecke legen Sie später skriptgesteuerte Snapshots an. na3022> na3022>
snap reserve esx_iscsi 0 vol options esx_iscsi nosnap on
Im nächsten Schritt erstellen Sie wieder eine LUN: na3022> lun create -s 200g -t vmware -o noreserve /vol/esx_iscsi/ iscsi_ds01.lun
Nun erstellen Sie die iSCSI-iGroup und nehmen die iSCSI-Initiator-IQNs in diese neue Gruppe auf. Allerdings verhält sich iSCSI an dieser Stelle deutlich anders als FCP: Da wir in diesem Beispiel mit Software-iSCSI arbeiten, müssen Sie auf jedem ESX-Host: 왘
den Software-iSCSI-HBA aktivieren, erst dann wird dessen IQN-Nummer erstellt und angezeigt;
왘
den Software-HBA so konfigurieren, dass er sich bei der NetApp anmeldet.
Beide Schritte erfordern eine kurze Konfiguration am ESX-Host. Unter Konfiguration und dann Speicheradapter klicken Sie auf den iSCSI-Software-Initiator, anschließend können Sie den Adapter unter Properties und Configure durch das Setzen des Häkchens auf Enabled aktivieren. Dies wird in Abbildung 9.22 gezeigt. Nach dem Bestätigen ist der iSCSI-HBA aktiviert, und die IQN wird angezeigt. Diese IQN müssen Sie im nächsten Schritt in die iGroup übernehmen, am besten per Cut & Paste (Abbildung 9.23). na3022> na3022>
igroup create -i -t vmware esx_iscsi_all igroup add esx_iscsi_all iqn.1998-01.com.vmware:rx3023-esx1ad9214f (für alle ESX Hosts wiederholen) na3022> igroup show esx_iscsi_all (iSCSI): OS Type: vmware Member: iqn.1998-01.com.vmware:rx3023-esx-1ad9214f (logged in on: e0a)
Anders als bei FCP müssen Sie für iSCSI-Multipathing die iGroup nicht auf ALUA setzen, da das iSCSI-Protokoll das Multipathing anders implementiert, nämlich per MCS, also Multiple Connections per Session.
474
Einrichtung und Konfiguration von Datastores
Abbildung 9.22
Den Software-iSCSI-HBA aktivieren
Abbildung 9.23
Aktivierter HBA
475
9.2
9
Storage-Konfiguration unter VMware
Falls iSCSI nur auf bestimmten LAN-Interfaces der NetApp gesprochen werden soll, müssen Sie die unerwünschten Interfaces ausblenden. Das geschieht mit iscsi interface disable . Der Vorgang ist deshalb wichtig, weil im iSCSI-Log-in-Dialog zwischen Initiator und Target versucht wird, über alle aktiven Interface zu kommunizieren, leider auch über IP-Routing technisch nicht erreichbare Interfaces – das Phänomen tritt immer dann auf, wenn es eine Trennung zwischen Storage-Netz und anderen Netzen gibt. Der Rest des Vorgangs gestaltet sich auf NetApp-Seite wie auch bei FCP, Sie müssen die LUN an die iGroup mappen: na3022> lun map /vol/esx_iscsi/iscsi_ds01.lun esx_iscsi_all 1 Fri Oct 30 11:38:06 MET [na3022: lun.map:info]: LUN /vol/esx_iscsi/ iscsi_ds01.lun was mapped to initiator group esx_iscsi_all=1 na3022> lun show -m LUN path Mapped to LUN ID Protocol /vol/esx_iscsi/iscsi_ds1.lun esx_iscsi_all 1 iSCSI
Die LUN sollte nun an den entsprechenden Hosts sichtbar sein, alle weiteren Arbeiten erledigen Sie am ESX-Host. Arbeiten am ESX-Host Damit die soeben erstellte LUN beim nächsten HBA-Rescan auf dem ESX-Host sichtbar wird, muss der Software-HBA am ESX-Host sich zunächst auf das iSCSITarget verbinden. Sie müssen sich von jedem Host aus auf das Speichersystem verbinden; es handelt sich um eine Point-to-Point-Verbindung und nicht wie bei FCP um ein gemeinsam nutzbares (shared) Medium (die Zone), das durch das Zoning definiert wurde. In den Eigenschaften des Software-HBAs definieren Sie das Target bei Send Targets:
Abbildung 9.24
476
IP-Adresse des NetApp-Systems eintragen
Einrichtung und Konfiguration von Datastores
Anschließend können Sie neu scannen, die LUN sollte auftauchen. Auf dem NetApp-System erscheint eine Meldung, dass sich ein iSCSI-Initiator neu verbunden hat: [na3022: iscsi.notice:notice]: ISCSI: New session from initiator iqn.1998-01.com.vmware:rx3023-esx-1ad9214f at IP addr 192.168.123.1
Abbildung 9.25
Nach dem Rescan wird die LUN angezeigt.
In ESX-Versionen vor 4.0 musste neben dem VMkernel-Interface auch noch ein Service-Console-Interface im selben Subnetz definiert sein, da früher der Send Targets-Log-in-Dialog zwischen ESX und Storage noch in zwei Schritten definiert war. Beim ersten Schritt prüfte die Service Console die Verfügbarkeit der LUNs, im zweiten Schritt wurde dann die Datenverbindung vom VMkernel zum iSCSI-Storage hergestellt. Ab Version 4 ist das nicht mehr nötig, der VMkernel macht beides. Nachdem die LUN sichtbar ist, können Sie nun ein VMFS-3-Dateisystem anlegen, der Vorgang ist der gleiche wie bei FCP: Unter Speicher klicken Sie Speicher hinzufügen an und wählen anschließend die noch leere iSCSI zum Erstellen des Datastores aus. In den nächsten Schritten des Dialogs stellen Sie auch wieder die Blockgröße ein, klicken auf Kapazität maximieren und bestätigen dann; die LUN wird benannt und somit zum nutzbaren Datastore (Abbildung 9.27). Damit die gleiche Ausfallsicherheit wie bei FCP gewährleistet werden kann, müssen Sie nun noch dem Software-iSCSI-HBA das zweite VMkernel-Interface hinzufügen. Dieses haben Sie vorhin schon angelegt, allerdings konfigurieren Sie nun beide VMkernel-Interfaces zum Software-Initiator hinzu:
477
9.2
9
Storage-Konfiguration unter VMware
Abbildung 9.26
Die leere iSCSI-LUN auswählen
Abbildung 9.27
Der iSCSI-Datastore ist fertig.
[root@rx3023-esx ~]# esxcli swiscsi nic add -n vmk-IPSTORAGE2 -d vmhba34 [root@rx3023-esx ~]# esxcli swiscsi nic add -n vmk-IPSTORAGE -d vmhba34
Abbildung 9.28
Zwei Pfade zur gleichen LUN
Mit zwei Pfaden würde der Failover grundsätzlich schon einmal funktionieren, allerdings sollten Sie auch von Load-Balancing profitieren. Dafür stellen Sie die
478
Einrichtung und Konfiguration von Datastores
Path Selection Policy auf Round-Robin ein, ähnlich wie es bei FCP nötig war, nur ist im Falle von iSCSI kein spezielles SATP im Einsatz, sondern Sie verwenden das normale SATP_DEFAULT_AA.
Abbildung 9.29
Active-active mit Round-Robin-Load-Balancing mit iSCSI
Ein echtes iSCSI-Load-Balancing mit ESX 3 und 3.5 war nicht einfach möglich, es sei denn, man setzte einen Hardware-HBA ein. Dieser verfügt über zwei getrennte Ports und meldet sich auch als zwei HBAs gegenüber dem ESX-Host, die Konfiguration war dadurch fast identisch mit Fibre-Channel.
9.2.3
NFS-Datastores
Das Network File System (NFS) wurde in den 80er Jahren von SUN Microsystems veröffentlicht. Es war damals ein revolutionärer Ansatz, über das Netzwerk auf Dateien zuzugreifen, die auf einem anderen Rechner gespeichert waren. Seit ESX-Version 3.0 erlaubt VMware auch die Verwendung des NAS-(Networkattached Storage-)Protokolls für die Ablage von virtuellen Maschinen. Das andere aus der Windows-Welt bekannte NAS-Prokokoll namens CIFS wird für die Ablage von vmdks hingegen aus Performance-Gründen nicht unterstützt. Mit NFS greifen wir das erste Mal dateiorientiert auf das Speichersystem zu – es ist kein VMFS-3-Cluster-File-System auf LUNs mehr nötig. Auf ein Share (deutsch: Netzlaufwerk) kann schon immer parallel zugegriffen werden. LockingMechanismen im NFS-Protokoll verhindern den gleichzeitigen Zugriff auf dieselbe Datei von zwei verschiedenen Hosts aus. Standardmäßig unterstützt VMware bis zu 8 NFS-Datastores pro ESX-Host. Allerdings ist es möglich, dies auf 64 zu erhöhen, indem Sie unter Advanced Settings die Option NFS.MaxVolumes ändern. Sie müssen bei der Erhöhung der NFSDatastores immer bedenken, dass Sie auch die TCP/IP-Heap-Size entsprechend anpassen müssen. Bei einer Erhöhung auf beispielsweise 64 NFS-Datastores empfiehlt NetApp die Anpassung des Net.TcpipHeapsize-Werts auf 30 und des Net.TcpipHeapMaxWerts auf 120.
479
9.2
9
Storage-Konfiguration unter VMware
Abbildung 9.30
Erhöhung der maximal unterstützten NFS-Datastores
Abbildung 9.31 Anpassung TCP/IP-Heap-Size/-Heap-Max bei Erhöhung der unterstützten NFS-Datastore-Anzahl
Arbeiten am Speichersystem Die Konfiguration von NFS-Freigaben auf einem NetApp-Speichersystem ist relativ einfach und schnell zu erledigen – schließlich war NFS das erste Protokoll, das von NetApp unterstützt wurde. Ein weiterer Punkt, der zur einfachen Konfiguration beiträgt, ist die Tatsache, dass beim dateiorientierten Zugriff keinerlei LUNs nötig sind. Ein NetApp-Volume entspricht einem Dateisystem, das heißt, es kann direkt per NFS freigegeben werden. Allerdings müssen Sie durch diese Verände-
480
Einrichtung und Konfiguration von Datastores
rung nun auf andere Dinge achten, zum Beispiel Zugriffsrechte auf das Share und die Dateien. Bei einem NetApp-System ist NFS ein kostenpflichtiges Protokoll, das lizenziert werden muss. Erworbene Lizenzen spielen Sie mit dem Befehl license add ein. Gegebenenfalls müssen Sie den Dienst noch starten, und zwar mit nfs on. Zuerst erstellen Sie auf der NetApp wieder ein Volume, diesmal zur direkten Ablage von VMs: na3022> vol create esx_nfs aggr0 200g Creation of volume 'esx_nfs' with size 200g on containing aggregate 'aggr0' has completed.
In einem NAS-Volume ist es sinnvoll, die Snapshot-Reserve nicht abzuschalten, da die NFS-Clients jeweils den echten Wert für freien Speicher in dem Volume angezeigt bekommen. Weil der Snapshot-Plattenplatzverbrauch bei einem Volume mit abgeschalteter Snapshot-Reserve zum normalen Speicherverbrauch addiert wird, erhalten die Clients falsche oder verwirrende Informationen über den freien und belegten Speicher. In unserem Beispiel ist der Standardwert von 20 % für Snapshot-Reserve eingestellt. Sie könnten diesen Wert jederzeit verändern, solange noch genug Platz im Volume frei ist. na3022> df -h esx_nfs Filesystem /vol/esx_nfs/ /vol/esx_nfs/.snapshot
total 160GB 40GB
used 104KB 0GB
avail capacity 159GB 0% 40GB 0%
Ähnlich wie bei FCP oder iSCSI ergibt es keinen Sinn, von der NetApp regelmäßig automatisch Snapshots erzeugen zu lassen – die VMs und deren enthaltene Applikationen wären nicht konsistent. Also schalten wir auch wieder den automatischen Scheduler für Snapshots auf der NetApp aus, die Snapshots zur Datensicherung lösen wir später manuell oder per Skript aus. na3022> vol options esx_nfs nosnap on
Eine empfohlene Tuning-Option für NFS-Datastores ist das Ausschalten der Access-Time-Flags auf dem Volume. Dadurch werden bei reinen Leseanfragen auf die vmdk-Dateien keine unnötigen Metadaten-Schreibzugriffe ausgeführt, die die letzte Zugriffszeit auf das File (die A-Time) aktualisieren. na3022> vol options esx_nfs no_atime_update on
Sie sollten auf einem NetApp-Speichersystem auch dringend darauf achten, dass die Zugriffsrechte der Dateien in einem Volume nach Unix-Art verwaltet werden.
481
9.2
9
Storage-Konfiguration unter VMware
Gerade wenn ein Kunde das System als Multiprotokoll-Gerät konfiguriert hat (also für NFS und CIFS gleichzeitig), kann es vorkommen, dass per Default CIFSRechte auf dem Volume verwaltet werden und keine Unix-Rechte. vSphere greift allerdings als Unix-Client über NFS auf das Volume zu, deshalb müssen die Rechte auch auf Unix eingestellt sein: na3022> qtree security /vol/esxnfs unix
Nachdem alle Einstellungen für das Volume durchgeführt wurden, so muss es noch für die Clients freigegeben werden. Der Vorgang ist auf jeder Art von NFSServer sehr ähnlich: Meist gibt es eine Konfigurationsdatei namens /etc/exports und einen dazu passenden Befehl exportfs. Da der VMkernel von vSphere als User-ID 0 läuft, müssen Sie auch den Zugriff auf den Export als User root erlauben. Dafür dient die Option root=. Oder anders herum ausgedrückt: Falls Sie diese Option nicht setzen, so schaltet die NetApp den Zugriff von ESX als User root zu einem anonymen Zugriff um – und dieser anonyme User hat dann keine Rechte mehr, die Zugriffe werden fehlschlagen. Man spricht dabei auch von einem Root-Squash. Außerdem braucht der ESX-Host logischerweise Lese- und Schreibrechte auf das Volume, das konfigurieren Sie durch die Option rw=. Entweder tragen Sie nun diese Einstellungen in die Datei /etc/exports ein und lesen die Datei erneut mit dem Befehl exportfs -a, oder Sie erledigen beides mit einem einzigen Befehl: na3022> exportfs -p rw=192.168.123.1,root=192.168.123.1 /vol/esx_nfs
Weitere IP-Adressen von ESX-Hosts können Sie mit Doppelpunkt getrennt angeben. Arbeiten am ESX-Host Nun gilt es wieder, den soeben bereitgestellten Speicherplatz mit dem ESX-Host zu verbinden; diesmal wird ein NFS-Datastore verbunden. Da der VMkernel den NFS-Datastore über ein IP-Netzwerk verbindet, müssen Sie zuerst im Netzwerkbereich ein VMkernel-Interface für IP-Storage erstellen. Wie auch bei iSCSI empfiehlt sich eine Abtrennung dieses Netzes in ein eigenes VLAN oder noch besser auf eine eigene physische Infrastruktur, weil dadurch die Performance am wenigsten beeinträchtigt wird und Sie gegebenenfalls bessere Einstellungen wählen können, zum Beispiel Jumbo-Frames. Die Details zur Konfiguration des VMkernel-Interfaces entnehmen Sie dem Kapitel 7, »Netzwerk«, oder Abschnitt 9.2.2, »iSCSI«.
482
Einrichtung und Konfiguration von Datastores
Abbildung 9.32
Mindestens ein VMkernel-Interface für IP-Storage (NFS)
Bevor Sie den Datastore verbinden, sollten Sie prüfen, ob das neue VMkernelInterface überhaupt mit dem NFS-Server kommunizieren kann. Dazu pingen Sie auf der Service Console mit dem Befehl vmkping das Speichersystem, und zwar aus Perspektive des VMkernels. Funktioniert die Netzwerk-Kommunikation, ist die Anbindung des NFS-Datastores relativ schnell erledigt. Wählen Sie unter Konfiguration und Speicher nun Speicher hinzufügen, und klicken Sie diesmal Netzwerkdateisystem (NFS) an (Abbildung 9.33).
Abbildung 9.33
NFS auswählen
Im nächsten Dialog geben Sie an, zu welchem NFS-Server bzw. welcher IPAdresse sich der ESX-Host (genauer: dessen VMkernel) verbinden soll und welches NFS-Share verbunden wird. Zusätzlich müssen Sie wie auch bei den anderen Datastores einen Namen vergeben. Stehen die ESX-Hosts unter der Verwaltung eines vCenter-Servers, so müssen Sie den NFS-Export trotzdem auf allen Hosts manuell verbinden, der Name des Datastores wird dann aber automatisch auf allen Hosts auf den gleichen Namen gesetzt, und zwar auf den zuerst vergebenen. Sie können jedoch später
483
9.2
9
Storage-Konfiguration unter VMware
noch den Namen des Datastores ändern, indem Sie einfach einen Rechtsklick ausführen und umbenennen wählen.
Abbildung 9.34
NFS-Server, Volume und Datastore-Name angeben
Ist der Datastore dann verbunden, so erscheint es in der Liste der Datastores (Abbildung 9.35).
Abbildung 9.35
Ergebnis: Der NFS-Datastore ist sichtbar.
Load-Balancing und Failover sind mit NFS ebenso realisierbar wie mit den anderen beiden Storage-Protokollen, allerdings nur bedingt. Einen NFS-Datastore können Sie redundant anbinden, indem Sie den vSwitch mit mehreren Uplinks zum physischen Switch binden. Möchten Sie allerdings eine redundante aktiv/ aktiv-Anbindung, also einen Etherchannel oder LACP über mehrere Switches hinweg, so müssen Sie darauf achten, dass die Switches das Feature MLAG (Multichassis Link Aggregation) unterstützen oder aber dass die Switches gestackt werden, also für den ESX-Host wie ein einzelner Switch aussehen. Um mehr Datendurchsatz zu erlangen, sollten Sie als Load-Balancing-Option auf der Portgruppe IP-Hash wählen. Das allein hat jedoch nicht den gewünschten Effekt, da der Hash-Algorithmus als Resultat immer denselben Link verwendet –
484
Umgang mit Datastores
schließlich wird die Verbindung ja nur von einer einzigen VMkernel-IP zu einer einzigen NFS-Server-IP hergestellt. Diesen Effekt können Sie vermeiden, indem Sie der NetApp einfach mehrere IP-Adressen geben und verschiedene Datastores über die verschiedenen IPs verbinden. Das ist zwar kein echtes Round-RobinLoad-Balancing, jedoch wird die Last der verschiedenen Datastores über die verschiedenen Links verteilt. Um NFS-Datastores zu vergrößern oder verkleinern, reicht es, auf der NetApp das entsprechende flexible Volume anzupassen. Das kann im laufenden Betrieb geschehen. Anzahl der VMs pro NFS-Datastore Es ist nicht leicht, etwas zu der Maximalanzahl von VMs auf einem NFS-Datastore zu schreiben, da dieser aufgrund der File-Locks wesentliche Vorteile in der Skalierung gegenüber den blockbasierten VMFS-Volumes hat, die mit SCSI-Locks arbeiten. Grundlegend hängt die sinnvolle Anzahl der VMs auf einem NFS-Datastore natürlich von der darunterliegenden Speicherarchitektur ab und davon, welche Leistung diese liefern kann. So können Sie beispielsweise mit einer genügend ausgestatteten NetApp FAS2050 einige Dutzend VMs mit entsprechenden I/OCharakteristiken versorgen. Müssten Sie mehrere hundert VMs versorgen, müssen Sie den Filer auch entsprechend auf Controller- und Festplattenseite ausbauen. Im Standard nutzen Kunden die NFS-Datastores mit einer Belegung zwischen 50 und 150 VMs. Derzeit existiert bei NetApp allerdings aufgrund der Deduplizierung ein Soft Limit, dass maximal 255 VMs auf einem NFS-Export (Datastore) betrieben werden sollen, da bei größerer Anzahl kein Deduplizierungs-Effekt mehr erzielt werden kann. Getestet wurden allerdings auch schon NFS-Datastores mit über 800 VMs, was auch problemlos funktionierte. Hier stellt sich aber dann die Frage der Sinnhaftigkeit wegen Redundanz und maximaler Cluster-Konfiguration auf VMwareSeite.
9.3
Umgang mit Datastores
Sind die Datastores einmal angelegt, so will man mit diesen auch arbeiten. VMware hat in den letzten Jahren viel Zeit damit verbracht, die Bedienbarkeit über die grafische Oberfläche des vSphere-Clients und die WebAccess-Schnittstelle zu realisieren.
485
9.3
9
Storage-Konfiguration unter VMware
9.3.1
Rescan SAN
Eine starke Vereinfachung beim SAN-Rescan wurde ebenfalls mit vSphere eingeführt, die es ermöglicht, auf Datacenter oder Cluster-Ebene im Kontextmenü Rescan SAN auszuwählen und gleich mehrere Hosts auf einmal zu scannen. Außerdem wird nun automatisch bei der Anlage eines neuen FC-/iSCSI-Datastores ein Rescan auf allen Hosts im Cluster ausgeführt.
Abbildung 9.36
9.3.2
Rescan Datastores auf Cluster-Ebene
Storage Views
Neben dem Zugriff über den ESX-Host existiert im vCenter eine DatastoresAnsicht, in der Sie die Datastores zentral bedienen können.
Abbildung 9.37
Datastores-View
In dieser Ansicht sehen Sie auf einen Blick den Status der verschiedenen Datastores ein und erkennen, wie viele virtuelle Maschinen auf diesem registriert sind, welche Hosts mit dem Datastore verbunden sind oder welche Berechtigungen gesetzt sind. Eine der interessantesten Ansichten ist allerdings unter dem Performance-Tab zu finden. Die wahrscheinlich nützlichste Funktion sind aber die Storage Views, die ideal ist für die schnelle Statuskontrolle sowie das Auslesen der WWPNs oder der Anzahl der Pfade.
486
Umgang mit Datastores
Abbildung 9.38
Datastores in der Performance-View
Abbildung 9.39
Datastores in den Storage Views
Die Storage Views sind nicht nur unter der Datastores-View, sondern auch in der Ansicht der ESX-Host-Systeme zu finden. Dabei ist die Last Update Time, also der Zeitpunkt der letzten Aktualisierung, zu beachten. Im Zweifelsfall sollten Sie immer erst eine Aktualisierung durchführen, bevor Sie auf die Angaben vertrauen.
487
9.3
9
Storage-Konfiguration unter VMware
9.3.3
Datastore-Browser
Möchten Sie mit bestehenden Daten im Datastore arbeiten oder neue Daten importieren, so bietet sich der Datastore-Browser an. Diesen starten Sie aus dem vSphere-Client heraus oder in funktionsbeschränkter Form auch über die Browserschnittstelle von ESX oder vCenter (WebAccess).
Abbildung 9.40
WebAccess-Zugriff auf die Datastores
Der Datastore-Browser wird automatisch geöffnet, sobald Sie im Kontextmenü des Datastores Browse Datastore (»Datenspeicher durchsuchen«) aufrufen.
Abbildung 9.41
Datastore-Browser starten
Innerhalb des Datastore-Browsers können Sie nahezu beliebig agieren, da vom Umbenennen von Ordnern oder Dateien über Verschieben zwischen Datastores bis hin zur Registrierung neuer VMs alles möglich ist.
488
Umgang mit Datastores
Abbildung 9.42
9.3.4
Datastore-Browser-Nutzung
Storage-Alerts
Viele Leser werden aufatmen, dass die Storage-Alerts mit vSphere Einzug gehalten haben, um vor volllaufenden Datastores zu warnen oder natürlich den Füllstand bei Nutzung von Thin Provisioning im Auge zu behalten.
Abbildung 9.43
Storage-Alerts = Standardalarme, die Datastores überwachen
Innerhalb der Storage-Alerts unterscheiden wir zwischen zwei Zuständen des Alarmtyps: Statuskontrolle und Ereigniskontrolle.
489
9.3
9
Storage-Konfiguration unter VMware
Abbildung 9.44
Statuskontrolle über Alarme
Mittels Statuskontrolle überwachen Sie die Nutzung der Datastores, den Status zu jedem verbundenen ESX-Hosts und die Überbuchung der Datastores (Thin Provisioning).
Abbildung 9.45
Ereigniskontrolle über Alarme
Die Ereigniskontrolle dient auf der anderen Seite dazu, Änderungen an den Datastores zu überwachen. Dies reicht von dem Hinzufügen oder Löschen des gesamten Datastores oder einzelner Dateien bis hin zur Überwachung, ob ein Datastore per »extend« oder »expand« vergrößert wurde.
9.3.5
Datastore-Erweiterung
Eine weitere sehr wichtige Änderung von vSphere besteht in der Möglichkeit, VMFS-Volumes zu erweitern. Bisher war dies nur mit Extents möglich, das heißt, mehrere VMFS-Partitionen wurden »zusammengeklebt«, sie waren also in ihrer Eigenschaft immer noch eigenständig (Größe, Plattennutzung etc.), allerdings wurden sie als ein einzelner Datastore angezeigt. VMFS Volume Grow nennt sich die neue Funktion, die einzelne VMFS-Partitionen auf dem Volume im laufenden Betrieb vergrößert. So ist es möglich, auf neue Gegebenheiten, z. B. das Datenwachstum von VMs, zu reagieren, ohne direkt die größtmöglichen LUNs nutzen zu müssen, um für den Fall der Fälle gerüstet zu sein.
490
Umgang mit Datastores
VMFS Grow vmfs
vmfs
alt: 300 GB
neu: 500 GB
LUN1
+ 200 GB
Abbildung 9.46 Vergrößerung der LUN von 300 GB auf 500 GB im Backend (LUN) und Frontend (VMFS)
Der erste Schritt besteht dabei im Vergrößern der LUN, die bereits mit VMFS formatiert und genutzt wird. Beim nächsten Rescan wird die Vergrößerung der LUN erkannt.
Abbildung 9.47
Einen Datastore vergrößern Sie in seinem Eigenschaften-Fenster.
Ist der zusätzliche Speicherplatz erkannt, sehen Sie die Vergrößerung in der Ansicht Datastore Extent , da eine Größendifferenz zwischen Device und Partition vorliegt. Per Increase rufen Sie den Dialog zur Auswahlerweiterung des Datastores auf.
Abbildung 9.48
Erkennung der Kapazitätserweiterung
491
9.3
9
Storage-Konfiguration unter VMware
Wählen Sie nun die gleiche LUN aus, so wird ein VMFS Volume Grow ausgeführt; wählen Sie eine andere LUN, so wird der Datastore mit einem Extent erweitert.
Abbildung 9.49 Abschließende Zusammenfassung, was durch die Erweiterung mit dem Datastore passiert
9.4
NetApp-Spezialitäten
NetApp-Speichersysteme bieten viele fortgeschrittene Funktionen, die das Zusammenspiel mit Virtualisierungslösungen verbessern. Die meisten dieser Features gab es schon, bevor man an Server-Konsolidierung dachte. Da aber NetAppStorages ja selbst schon eine Virtualisierungslösung darstellen – Storage-Virtualisierung –, passen ihre Features hervorragend zu den Funktionen von VMware. Im Folgenden gehen wir auf Cloning, Snapshots, Backup und Tuning von NetApp-Storage für VMware ein.
9.4.1
Cloning-Technologien
Virtuelle Maschinen liegen in Form von Dateien vor. Durch Kopieren dieser Dateien erstellen Sie auf einfache Weise Duplikate von VMs – virtuelle Maschinen müssen nicht immer frisch installiert werden. VMware bringt dafür im vCenter-Server das Feature »Templates«, also »Vorlagen«, mit. Dabei handelt es sich um VMs, die nicht einschaltbar sind, deren Konfigurations-Datei auf vmtx endet und die Sie bei Bedarf kopieren und anpassen, um so eine neue VM zu erstellen. Grundsätzlich gibt es verschiedenste Gründe, vmdk-Dateien zu kopieren: 왘
Ausrollen (Deployment) von VMs für neue Dienste
왘
Kopieren von aktiven VMs zu Testzwecken (z. B. Softwareupdate)
492
NetApp-Spezialitäten
왘
Bedarf an neuen VMs für virtuelle Desktops
왘
Backup oder Recovery
Ein normaler Kopiervorgang sieht bei ESX immer so aus, dass die entsprechenden Blöcke vom ESX-Host gelesen und anschließend wieder neu in den Datastore geschrieben werden. Aufgrund der Datenbewegung stellt das eine Belastung für den ESX-Host, das Netzwerk und das Speichersystem dar. NetApp-Speichersysteme erlauben es, virtuelle Kopien von Daten anzulegen, indem nur Zeiger kopiert werden – ähnlich wie bei NetApp-Snapshots. Diese Kopien belegen extrem wenig Platz (nur Metadaten für die Zeiger) und sind sofort verfügbar. VMware wird in naher Zukunft die vStorage-API so weit fertigstellen, dass die Erstellung von VM-Kopien auf das effiziente Storage-System ausgelagert werden kann, was die Geschwindigkeit beim Kopieren steigern und den Platzverbrauch verringern wird. Nach aktuellem Stand funktionieren diese Features schon, allerdings fehlt die Integration in das vCenter und die vCenter-Clients – Sie müssen die CloningMechanismen manuell auf der Console des NetApp Systems durchführen. LUN-Clones Kunden, die ein Blockprotokoll (egal ob iSCSI oder FCP) lizenziert haben, erhalten die kostenlose Funktionalität, mit der sie Clones von LUNs erstellen können. Anwendungsbeispiele für die Verwendung von LUN-Clones sind: 왘
Testzwecke: Clonen Sie einen gesamten Datastore, um die VMs noch einmal auf einem anderen, isolierten Host hochzufahren und ein Softwareupgrade durchzuführen, bevor der produktive Datastore eventuell kaputtgeht.
왘
Recovery-Zwecke: Falls Sie Backups mit NetApp-Snapshot machen, können Sie per LUN-Clone einen alten Snapshot-Zustand des Datastores an den ESXHost mappen – von dort aus kopieren Sie die rückzusichernde VM dann wieder auf Ihren produktiven Datastore.
LUN-Clones basieren auf NetApp-Snapshots. Um also einen Clone einer LUN zu erstellen, muss mindestens ein Snapshot des Volumes mit der enthaltenen LUN vorhanden sein. Am besten stellen Sie sich vor, dass jede Stunde ein Snapshot des Volumes zu Backup-Zwecken erstellt wird. (Mehr zu Backups per Snapshot in Abschnitt 14.1.4, »Backup von vSphere-Umgebungen mit NetApp-Storage«, unter der Überschrift »SMVI«.)
493
9.4
9
Storage-Konfiguration unter VMware
Ein Snapshot ist ein eingefrorener Zustand des Volumes, der nicht mehr veränderbar ist, also read-only. Auf diesem Zustand können Sie nun eine Clone-LUN anlegen, indem Sie einfach eine neue LUN erstellen und so tun, als ob diese schon Daten enthielte – es werden von der NetApp einfach Zeiger auf die Originaldaten aus dem Snapshot erstellt. Somit werden Lesezugriffe auf die Clone-LUN durch die Kopie der Zeiger in Wirklichkeit von den Originalblöcken bedient, die Schreibzugriffe werden im LUN-Clone direkt abgelegt. Das heißt: Ein LUN-Clone braucht initial fast keinen Platz, später, wenn mehr Daten in den Clone geschrieben wurden, steigt der Platzverbrauch an. Die Verwendung von LUN-Clones auf der NetApp-Kommandozeile funktioniert wie folgt: Zuerst muss ein Snapshot des Volumes existieren, in dem die LUN liegt; an dieser Stelle gehen wir davon aus, dass die VMs irgendwie in einen konsistenten Zustand gebracht wurden. na3021> snap create esxfcp snap4backup na3021> snap list esxfcp %/used %/total date name ---------- ---------- ------------ -------9% (9%) 0% ( 0%) Nov 14 14:01 snap4backup
Nun erzeugen Sie den LUN-Clone: na3021> lun clone create usage: lun clone create [-o noreserve] -b <parent_ lunpath> <parent_snap> na3021> lun clone create /vol/esxfcp/datastore1-CLONE.lun o noreserve -b /vol/esxfcp/datastore1.lun snap4backup
Daraufhin gibt es zwei LUNs im Volume, das Original und einen Clone – da der Clone auf dem Snapshot basiert und diesen als »Lebensgrundlage« benötigt, ändert sich der Zustand des Snapshots auf »busy« und ist nicht mehr löschbar, solange der Clone existiert: fortknox> lun show /vol/esxfcp/datastore1-CLONE.lun 5g (r/w, online) /vol/esxfcp/datastore1.lun 5g (r/w, online) fortknox> lun show -v /vol/esxfcp/datastore1-CLONE.lun /vol/esxfcp/datastore1-CLONE.lun 5g (r/w, online) Serial#: C4iACZT5GWDq
494
NetApp-Spezialitäten
Backed by: /vol/esxfcp/.snapshot/snap4backup/datastore1.lun Share: none Space Reservation: disabled Multiprotocol Type: vmware fortknox> snap list esxfcp %/used %/total date name ---------- ---------- ------------ -------12% (12%) 0% ( 0%) Nov 14 14:01 snap4backup (busy,LUNs)
Um den Clone dann auf ESX-Seite verwenden zu können, müssen Sie ihn noch an eine iGroup mappen, genau wie jede andere normale LUN auch. Taucht der geclonte Datastore nach dem HBA-Rescan am ESX-Host auf, so können Sie wählen, was im Anwendungsfall »Recovery einer defekten VM« nun geschehen soll: Entweder kopieren Sie die gewünschte VM aus dem Clone-Datastore in das Original-Datastore und schalten die so recoverte VM wieder ein, oder Sie registrieren die VM direkt auf dem Clone-Datastore, starten sie dort und kopieren sie dann im laufenden Betrieb per Storage VMotion auf den produktiven Datastore. In jedem Fall sollten Sie einen LUN-Clone nach erledigter Arbeit wieder zerstören, da er einen Snapshot blockiert und sonst das Datenwachstum im Volume im Laufe der Zeit zu viel Platz belegen würde. VMFS-Resignatur Die VMFS-Signatur (u. a. UUID) wird beim Anlegen der VMFS-Partition anhand der Storage-Daten vergeben und auf die LUN geschrieben. Diese Signatur ist einmalig und stimmt nur überein, wenn sich nichts an der LUN oder dem StorageSystem ändert. Der ESX-Server berechnet die UUID beim Erkennen eines Datastores seinerseits und vergleicht sie mit der Signatur auf dem Datastore. Stimmen die berechneten Daten nicht mit den Metadaten überein, wird ein DatastoreSnapshot erkannt. Unter ESX 3.x führte auch die Anpassung der LUN-ID noch zur Änderung der berechneten VMFS-Signatur, was seit 3.5 U3 nicht mehr der Fall ist. Kopien von LUNs mit bestehendem VMFS werden von den ESX-Hosts aufgrund der veränderten Metadaten daher auch als aus Sicherheitsgründen als Snapshot erkannt und können daher nicht direkt genutzt werden. Mappen Sie den Clone der LUN an dieselben ESX-Hosts wie den Original-Datastore, so müssen Sie bedenken, dass der ESX-Host bereits eine LUN kennt, die dieselbe VMFS-3-ID hat. Binden Sie den Clone an einen ESX-Host, der mit dem Original-Volume keinen Kontakt hat, so können Sie die Signatur beibehalten.
495
9.4
9
Storage-Konfiguration unter VMware
Da der Clone nun mit der gleichen VMFS-3-ID kommt, jedoch eine andere LUNID und LUN-Seriennummer hat, erkennt der ESX-Host, dass es sich dabei um einen Snapshot handeln muss, und wird diesen Snapshot »re-signieren«, d. h. eine neue VMFS-ID für den geclonten Datastore vergeben. In ESX 3 und 3.5 musste für das Resignature-Feature noch die Advanced Option LVM.Resignature auf 1 gesetzt werden.
Abbildung 9.50
Was soll mit dem als Snapshot erkannten Datastore passieren?
Bei ESX 4 wählen Sie dies beim Hinzufügen eines neuen Datastores aus, also in diesem Fall Assign a new signature. Möchten Sie den Datastore einfach hinzufügen, ohne ihn zu resignieren, wählen Sie Keep the existing signature aus. Diese Unterscheidung ist wichtig, da bei einer Neusignatur die VMs auf diesem Datastore neu registriert werden müssen. Möchten Sie über die die Kommandozeile vorgehen, so arbeiten Sie mit dem Befehl esxcfg-volume: 왘
esxcfg-volume -l = Auflisten aller als Snapshot erkannten Datastores
왘
esxcfg-volume -r = Resignatur des angegebenen Data-
stores 왘
esxcfg-volume -M = Beibehaltung der Signatur und Ver-
binden des Snapshot erkannten Datastores FlexClones FlexClones haben eine sehr starke Ähnlichkeit mit LUN-Clones, allerdings ist das Feature kostenpflichtig. Mit FlexClones ist es möglich, ganze Volumes zu clonen und nicht nur Clones von einzelnen LUNs anzulegen. Möchten Sie ähnliche Vorgänge wie oben beschrieben (Recovery usw.) mit NFSDatastores durchführen, so müssen Se eine FlexClone-Lizenz anschaffen – NFSDatastores bringen keine LUNs mit sich, sondern stellen immer den Export eines
496
NetApp-Spezialitäten
gesamten FlexVols einer NetApp dar – deshalb muss auch das ganze Volume geclont werden. Ist eine FlexClone-Lizenz auf der NetApp eingespielt, so erzeugen Sie mit dem folgenden Befehl einen Clone: na3021> vol clone create usage: vol clone create [-s none | file | volume] -b <parent_ flexvol> [<parent_snapshot>] – create a new flexible volume that is a clone of <parent_flexvol> na3021> vol clone create esxnfs_clone -s none -b esxnfs Creation of clone volume 'esxnfs_clone' has completed.
Es gibt auch wieder die Möglichkeit, einen alten Snapshot-Zustand für den Clone zu verwenden – oder aber Sie geben beim VolClone keinen alten Snapshot an, dann wird ein neuer aktueller Snapshot erzeugt: na3021> vol status esxnfs Volume State esxnfs online
Status raid_dp, flex redirect Volume has clones: esxnfs_clone Containing aggregate: 'aggr0'
Options
na3021> vol status esxnfs_clone Volume State esxnfs_clone online
Status Options raid_dp, flex guarantee=none redirect, active_redirect Clone, backed by volume 'esxnfs', snapshot 'clone_esxnfs_clone.1' Containing aggregate: 'aggr0'
Das geclonte NFS-Volume muss nur per exportfs zur gemeinsamen Nutzung freigegeben und dann auf dem ESX-Host als neues NAS-Datastore verbunden werden. Resignature oder Ähnliches ist nicht nötig – es kann sofort verwendet werden. File-Clones und Sub-LUN-Cloning Die FlexClone-Lizenz bringt in Verbindung mit Deduplizierung (siehe Abschnitt 9.4.2, »Tuning und Optimierung«) noch einige nette Funktionen mit, die im Alltag noch nicht einfach verwendbar sind, sie werden erst durch die Integration von APIs oder die Bereitstellung von Tools wie dem Rapid Cloning Utility von NetApp interessant. Es wird mindestens ONTAP 7.3.2 benötigt.
497
9.4
9
Storage-Konfiguration unter VMware
Der theoretische Hintergrund sei dennoch kurz erklärt: Für das Erstellen neuer VMs aus Templates helfen beide soeben vorgestellten Cloning-Funktionen noch relativ wenig, da beide Clones (egal ob LUN- oder Volume-Clones) immer als Resultat einen weiteren Datastore erstellen. Eigentlich möchte man ja aber im vorhandenen Datastore eine Datei kopieren, nur eben effizienter, also clonen. Genau dafür sind File- und LUN-Clones vorgesehen. Ein File-Clone funktioniert so, dass – anstatt eine Datei in einem Volume zu kopieren – lediglich eine Kopie der Metadaten (Zeiger auf die Datenblöcke) erstellt wird mit einem neuen Dateinamen. So haben Sie zwei Dateien, die aber auf dieselben Blöcke zeigen. Dieser Vorgang ist sehr sinnvoll bei NAS-Datastores, Sie clonen einfach ganze VMs, indem Sie die vmdks clonen. Der Sub-LUN-Clone geht davon aus, dass innerhalb einer LUN ein VMFS-Datastore existiert und darin vmdks liegen. Statt den gesamten Datastore zu clonen, bekommt die NetApp über eine API eine Liste der Blöcke übermittelt, die das zu kopierende VMDK innerhalb der LUN belegt, und erzeugt auch wieder nur durch Kopieren der Zeiger auf diese Blöcke eine Kopie des VMDKs innerhalb der LUN. Beide Funktionen können Sie manuell testen, wobei nur die File-Clones so wirklich sinnvoll realisierbar sind. Zum Testen wechseln Sie auf der Kommandozeile zunächst in den AdvancedMode, anschließend arbeiten Sie mit dem Befehl clone: fas3040*> priv set –q advanced fas3040*> clone start /vol/esxfs/OK-test-flat.vmdk /vol/esxnfs/ OK-test-flat2.vmdk Clone operation started successfully. ID: 1.
Clones auf diese Weise zu erstellen, ist noch relativ mühsam, da Sie alle Dateien einzeln clonen müssen. Abhilfe schafft das Rapid Cloning Utility von NetApp, das Sie kostenlos über die now.netapp.com-Website erhalten. Sollte künftig die vStorage-API zwischen den beiden Herstellern NetApp und VMware besser integriert werden, so wird es möglich sein, aus dem vCenter-Server direkt Clones auf der NetApp zu erstellen – transparent mit den gleichen Klicks, wie Sie bisher Dateien kopieren, nur eben schneller und platzsparender.
9.4.2
Tuning und Optimierung
PAM-Karte NetApp hat seit kurzem neue Storage-Beschleuniger-Karten im Portfolio, die sogenannten Performance Accelerator Modules (PAM). Damit deutlich wird,
498
NetApp-Spezialitäten
warum diese Karten sehr sinnvoll sind und wie genau sie funktionieren, muss man zuerst verstehen, wann ein Speichersystem schnell ist. Bei den meisten Storage-Systemen gilt die alte Regel »Viele Spindeln (also Festplatten) bedeuten viel Geschwindigkeit«. Aber wie schnell ist eine Festplatte eigentlich? Die Geschwindigkeit einer Festplatte wird – wie in Kapitel 8, »Storage-Architektur«, schon beschrieben – in der Anzahl der Input/Output-Operationen pro Sekunde (IOPS) gemessen. Die maximal mögliche Anzahl der IOPS hängt dabei stark von der mittleren Zugriffszeit der Disk ab, und diese ist wiederum von der Drehzahl abhängig. Als Beispiel wählen wir eine moderne FC- oder SAS-Platte mit 15 000 Umdrehungen pro Minute. Eine solche Platte hat eine Zugriffszeit von ca. 5 ms. Das bedeutet, dass man ca. 200 Mal pro Sekunde den Plattenkopf umpositionieren kann und die Disk somit auch 200 I/Os pro Sekunde abarbeiten kann. Der maximale Datendurchsatz ist bei einer Festplatte eine ebenso wichtige Kenngröße wie die Zugriffszeit bzw. die I/O-Leistung einer Platte – jedoch hängt der Datendurchsatz direkt von der Art des Zugriffsmusters ab. Lesen Sie beispielsweise in 4K-Blöcken zufällige Daten von der Disk (Random-Read-Muster), so errechnen Sie den Durchsatz einfach mit: 200 IOPS * 4kByte / IOP = 800KByte/s Das ist ein erschreckend niedriger Wert, der allerdings bei echtem Random-Workload nicht unrealistisch ist. Greifen Sie hingegen sequentiell auf eine Festplatte zu, so muss der Plattenkopf nicht umpositioniert werden, und Sie erhalten deutlich höhere Datentransferraten, die meist bis an die physische Grenze des Festplattenbusses von mehreren hundert Megabytes pro Sekunde heranreichen. In der Praxis zeigt sich jedoch sehr deutlich, dass die Zugriffsmuster gerade im VMware-Umfeld ziemlich zufällig sind und eine typische I/O-Größe von 4 bis 8 kBytes haben. Das ist nicht verwunderlich, weil typischerweise mehrere Hundert virtuelle Maschinen gleichzeitig auf einem zentralen Storage-Array lesen und schreiben. Für die Planung einer VMware-vSphere-Umgebung müssen Sie deshalb unbedingt auf die Anzahl der benötigten I/Os achten und nicht ausschließlich – wie leider sehr häufig fälschlich angenommen – auf die benötigte Speicherkapazität. Stellen Sie beispielsweise eine Rechnung an, dass 300 VMs durchschnittlich 40 IOPS benötigen, so sind das in Summe 12 000 I/Os, zur Sicherheit rechnen Sie für Lastspitzen noch mal 25 % hinzu, also kommen Sie insgesamt auf 15 000 IOPS. Um diese gewünschte Anzahl an parallelen Zugriffen ohne zu hohe Latenz
499
9.4
9
Storage-Konfiguration unter VMware
abzuwickeln, braucht unser Speichersystem ca. 75 Datenfestplatten in der RAIDGruppe (15 000 geteilt durch 200 I/Os pro Disk). Im Falle eines NetApp-Speichersystems entspricht das ca. 6 Disk-Shelves, jedes Disk-Shelf enthält nämlich 14 Festplatten. Bei einer Festplattengröße von 450 GB ergibt sich aus 75 Disks eine nutzbare Größe von ca. 25 TB (408.000 MB/Disk * 75 Disks 15 % Overhead). Rechnen Sie nun diese 25 TB herunter auf den möglichen Speicher pro VM, so kommen Sie eindeutig zu dem Schluss, dass ca. 85 GB pro VM deutlich zu viel Speicher ist! Die Erfahrung aus vielen Kundenprojekten zeigt, dass eine durchschnittliche VM deutlich weniger Platz benötigt, in den meisten Fällen belegt eine einzelne VM oft nicht mehr als 20 GB. An diesem Punkt sollte Folgendes klargeworden sein: 왘
Für ausreichende Performance wird eine gewisse Anzahl Disks benötigt.
왘
Jede Disk bringt neben I/O-Leistung auch Kapazität mit.
왘
Sizing wird primär nach Performance gemacht, danach erst nach Kapazität.
왘
Die meisten Kunden kaufen oft deutlich mehr Kapazität, als sie benötigen, weil sie die I/O-Leistung der vielen Platten brauchen.
Und genau an dieser Stelle greift das Performance Acceleration Module von NetApp ein. In der bisherigen Betrachtung der Geschwindigkeit von Storage-Systemen haben wir nämlich eine wichtige Kenngröße außer Acht gelassen: den Cache. Doch was ist ein Cache, und wie funktioniert er? Der Lesecache eines jeden Speichersystems merkt sich in einem sehr schnellen Speicher (meistens ein Teil des SystemRAMs des Controllers) kürzlich von Festplatten gelesene Daten oder Daten, auf die sehr häufig zugegriffen wird. Sollte ein Client auf Daten zugreifen, die sich schon im Cache befinden, so kann auf einen langsamen Festplattenzugriff verzichtet werden, und die angefragten Daten kommen mit sehr hoher Geschwindigkeit aus dem Cache direkt zum Client. Je größer also der Cache, desto häufiger werden die Daten aus dem Cache zum Client geliefert, und desto seltener muss auf die Festplatten zugegriffen werden – die Performance des Speichersystems steigt. Könnte man also den Cache eines Speichersystems erweitern, so wäre es möglich, die gewünschte Performance aus dem vergrößerten Cache zu gewinnen statt durch die Anschaffung vieler Festplatten. Das PAM von NetApp ist kurz gesagt eine Cache-Erweiterungskarte. Durch den Einsatz von PAM können Sie auf den zusätzlichen Kauf von Festplatten verzich-
500
NetApp-Spezialitäten
ten, bei gleichzeitig sinkenden Betriebskosten. Schließlich brauchen Festplatten im Betrieb Strom, Kühlung, Platz und einen Wartungsvertrag. Die meisten Storage-Hersteller begegnen der Problematik von extrem hohen I/OAnforderungen ihrer Kunden mit dem Einsatz von Solid-State-Disks (SSDs), einer modernen Art von nicht flüchtigem Flash-Speicher. Bei Flash-Speicher entfällt die mechanische Umpositionierung der Festplattenköpfe, daher sind die Antwortzeiten von SSDs je nach Bauart um den Faktor 10–100 schneller als klassische Platten. Da SSDs aktuell aber noch sehr teuer und leider nur mit relativ niedrigen Kapazitäten verfügbar sind, ist ihre Verwendung nur im sogenannten Tier-0-Einsatz rentabel, also bei Applikationen, die wirklich allerhöchste Anforderungen stellen. Der Kunde wählt also sehr genau aus, welche Art von Daten auf die teuren, aber schnellen Disks gelegt wird. NetApp bietet zurzeit keine SSDs als direkten Datenspeicher an, sondern verfolgt eine andere, effizientere Strategie: Anstatt den Kunden aktiv wählen zu lassen, welche Daten von Applikation es verdienen, auf den schnellen Platten zu lagern, nutzt NetApp die Flash- und SSD-Technologie einfach als Cache. Dadurch profitieren alle Daten, die auf dem Storage-System liegen – eben alle Daten, die am häufigsten abgerufen werden, wie beim normalen System-RAM-Cache. Der einzige Unterschied ist, dass der Cache um ein Vielfaches größer ist als das reguläre System-RAM, das in der Regel zwischen 2 und 32 GB groß ist. Die PAM-Karten sind in drei Varianten verfügbar: 왘
PAM I / 16 GB SDRAM
왘
PAM II / 256 GB Solid State
왘
PAM II / 512 GB Solid State
Je nach NetApp-Controller-Typ sind in den aktuellen Mittelklasse- und HighEnd-Systemen zwischen eine und fünf Karten nutzbar, was die Gesamtmenge des Cache deutlich erhöht. Nachdem wir erklärt haben, wie die PAM-Karte funktionieren, möchten wir jetzt die Konfiguration zeigen. Neben der PAM-Karte brauchen Sie eine Softwarelizenz für die NetApp, diese wird allerdings beim Kauf der Karte mitgeliefert.
501
9.4
Storage-Konfiguration unter VMware
Festplatten (Disks)
Relative Latenz
10 9 8 7
PAM
Latenz (ms)
9
Memory
6 5 4 PAM reduziert die Latenz um Faktor 10
3 2 1
CPUs
0 Abbildung 9.51
Disk
PAM
Memory
Arbeitslogik von PAM Karten und deren Latenzzeiten
Eine Karte wird aus Sicht des NetApp-Betriebssystems ONTAP so erkannt: na3142a> sysconfig -v 2 slot 2: Performance Accelerator Module I State: Enabled Memory Size: 16 GB Model Name: X1936A-R5 Serial Number: 123123 Part Number: 111-00360 Board Revision: B1 FPGA Release: 1.0 FPGA Build: 200706123123
Die Konfiguration der PAM-Karte ist relativ einfach: Sie müssen sie lediglich aktivieren, später passen Sie gegebenenfalls auch noch Parameter an, je nachdem, welche Art von Daten im Cache der Karte landen soll. Zum Einschalten verwenden Sie den folgenden Befehl: na3142a> options flexscale.enable on
Weitere Parameter prüfen Sie mit: na3142a> options flexscale flexscale.enable
502
on
NetApp-Spezialitäten
flexscale.lopri_blocks off flexscale.max_io_qdepth 512 flexscale.normal_data_blocks on
Diese Einstellungen sind ein sinnvoller Default. Generell werden Metadaten immer gecacht, die normalen Datenblöcke auch. Auf das Cachen von »Low-PrioBlocks« sollten Sie verzichten, weil dadurch bei großen Lesevorgängen (z. B. Backups) sonst der gesamte Cache überschrieben wird und somit wertlos ist. Anschließend sollten Sie an das System einfach arbeiten lassen und nach einigen Stunden oder Tagen die Nutzung des Cache prüfen. na3142a> stats show -i 5 -p flexscale-access Cache Reads Writes Usage Hit Miss Hit Evict Inval Insert Chain Blocks Chain Blocks % /s /s % /s /s /s /s /s /s /s 2 0 0 0 0 0 46508 0 0 728 46508 5 5804 1 99 0 1240 49718 156 5799 779 49718 11 0 0 0 0 0 38155 0 0 598 38155 18 0 0 0 0 0 23788 0 0 373 23788 20 0 0 0 0 0 35091 0 0 551 35091 20 16660 0 100 0 11 0 279 16617 0 0 20 15078 0 100 0 0 0 254 15035 0 0 20 32473 0 100 0 0 614 578 32349 10 614 20 18879 0 100 0 12 0 422 18835 0 0
Anfangs ist der Cache noch fast leer, später, wenn einige Daten dort bereits vorliegen (siehe Cache Usage und Inserts/s) steigt die Cache-Hit-Rate enorm, bei diesem künstlichen Benchmark sogar auf 100 %. Gerade bei VMware- und VDI-Workloads sind PAM-Karten extrem nützlich, da viele VMs gleichzeitig von den Platten lesen (Random-Workload), dabei sind die höchsten Beschleunigungsraten zu erzielen. PAM-Karten funktionieren übrigens auch hervorragend mit der NetApp-Deduplizierung zusammen. Stellen Sie sich vor, dass in einem VDI-Szenario 200 Desktop-VMs die gleiche vmdk-Festplattendatei haben. Dieses wurde durch NetAppDeduplizierung auf nur eine einzige Instanz reduziert, braucht also nur so viel Diskspeicher wie eine einzelne VM, alle doppelten Blöcke wurden eliminiert. Diese reduzierte Menge an Speicherplatz passt nun gut in den Cache der PAMKarte. Bei einer 256 GB großen PAM-Karte kann es durchaus vorkommen, dass ein großer Teil der Leseanfragen ausschließlich aus der Karte bedient wird und die Disks nur noch zum Schreiben benötigt werden. Die spürbare höhere Geschwindigkeit für die Clients ist dabei enorm, der eingesparte Plattenplatz ebenso.
503
9.4
9
Storage-Konfiguration unter VMware
Deduplication Deduplizierung ist die Erkennung und Eliminierung von redundanten Daten. Netapp hat seit ONTAP 7.2 einen Mechanismus zur Deduplication in das Betriebssystem mit eingebaut. Der NetApp-Name dafür ist »Advanced SingleInstance Storage«, kurz A-SIS – so heißt auch die benötigte ONTAP-Lizenz. A-SIS hilft dabei, weniger Speicherplatz zu verbrauchen, indem man doppelte Blöcke mehrfach verlinkt (ähnlich wie klassische Unix-Hardlinks) und sie somit nicht mehr doppelt speichern muss. Etwas Ähnliches kann ONTAP schon sehr lange, und zwar im Zusammenhang mit CIFS-File-Folding. Um es noch einmal ganz deutlich zu sagen: A-SIS hat nichts mit Komprimierung zu tun! Die Dateien werden weiterhin unkomprimiert auf den Platten abgelegt. Lediglich mehrfach vorhandene Datenblöcke desselben Inhalts werden eliminiert. Das Feature ist kein Performance-Killer, da es sich um einen sogenannten PostProcessing-Mode handelt, die Daten werden also zuerst normal gespeichert – dedupliziert wird dann später. Und zwar nur, wenn es explizit gestartet wird: entweder manuell oder per Scheduler. Das bedeutet, dass im Normalbetrieb keine Deduplizierung der gleichen Blöcke stattfindet, Sie also die normale Performance der Maschine erwarten können. Erst um Mitternacht (das ist der verstellbare Default) legt der A-SIS-Mechanismus los. A-SIS arbeitet wie folgt: 1. Das NetApp-System scannt alle Blöcke in einem Volume und erstellt Prüfsummen, die sogenannten Fingerprints. 2. Anschließend werden die Fingerprints sortiert und miteinander verglichen. 3. Gleiche Fingerprints kommen auf die Liste der genauer zu inspizierenden Blöcke. 4. Die Blöcke werden anschließend wirklich Byte für Byte verglichen, um sicherzustellen, dass es sich hierbei wirklich um ein Duplikat handelt und nicht nur zufällig die Prüfsumme der Blöcke gleich ist. 5. Jetzt erst beginnt der eigentliche Vorgang der Deduplizierung. Die identifizierten Dubletten werden erst neu verlinkt, anschließend die redundanten Blöcke als frei markiert. Neben dem Nearline- und Backup-Storage-Markt gibt es besonders bei NetAppKunden auch eine starke Nachfrage aus dem Primärspeicher-Umfeld nach DeDupe. Die Erfahrungen zeigen, dass auch im normalen File-Serving-Umfeld relativ einfach Einsparungseffekte von 30 bis 40 % zu erzielen sind, aber auch im
504
NetApp-Spezialitäten
Block-Storage-Umfeld (erst ab ONTAP 7.2.2 unterstützt) gute Ergebnisse erreicht werden können, insbesondere wenn es sich um offensichtliche Dubletten handelt wie im VMware ESX-Umfeld … Dort hat schließlich jede virtuelle Maschine ein Betriebssystem installiert. Je mehr VMs also auf dem gleichen Volume bzw. innerhalb der gleichen LUN liegen, desto mehr Einsparungen ergeben sich, in einigen Kundenszenarien sogar mehr als 70 %. Bei all den Vorteilen wollen wir die Nachteile nicht verschweigen: A-SIS funktioniert nur auf Volume-Ebene. Damit können Sie nur Einsparungen innerhalb eines flexiblen Volumes erzielen, jedoch leider noch nicht volumeübergreifend, also auf Aggregatsebene. Sie müssen also beim Layout des Storage darauf achten, jene Volumes zusammenzufassen, die latent zu Dubletten neigen. Ein Deduplizierungsprozess wirkt sich auf den Snapshot-Platzverbrauch aus. Das ist kein wirklicher Nachteil per se, sondern nur ein »normaler technischer Vorgang», wird jedoch von einigen Kunden als leichter Nachteil empfunden: Deduplizierung bedeutet Datenveränderung, genau wie andere Löschvorgänge. Damit wird der Plattenplatz zwar freigegeben, aber die deduplizierten Blöcke werden immer noch im Snapshot festgehalten, bis dieser verschwindet. Im Zusammenspiel mit Block-Storage (FCP und iSCSI) funktioniert DeDupe auch, allerdings muss zwingend auch Thin Provisioning aktiviert werden, sonst sind die Einsparungen vorhanden, aber leider nicht sichtbar. Das ist auch kein wirklicher Nachteil (Thin Provisioning ist sehr effizient!), nur schrecken einige Kunden davor zurück, weil sie durch die Überbuchung, die Thin Provisioning mit sich bringt, gezwungen sind, den Speicherplatzverbrauch genauer zu überwachen (Aufwand). Mehr dazu lesen Sie im folgenden Abschnitt. Praxisbeispiel Konfiguration und Auswertung von DeDupe Zuerst müssen Sie die beiden benötigten Lizenzen einspielen. na3024> license add XXXXXXX A nearstore_option site license has been installed. Data ONTAP is switching to NearStore mode. NearStore Option enabled. Mon May 14 14:57:32 MEST [rc:notice]: nearstore_option licensed na3024> license add XXXXXXX A a_sis site license has been installed. A-SIS enabled. Mon May 14 14:58:08 MEST [rc:notice]: a_sis licensed
505
9.4
9
Storage-Konfiguration unter VMware
Grund-Setup Wir brauchen zuerst ein Aggregat und ein Volume, auf denen wir Platz sparen wollen. In vorhandenen Umgebungen können Sie diesen Schritt natürlich überspringen. na3024> aggr create aggr0 5 Creation of an aggregate with 5 disks has completed. Mon May 14 14:58:34 MEST [wafl.vol.add:notice]: Aggregate aggr0 has been added to the system. na3024> na3024> vol create asisdemo aggr0 10g Creation of volume 'asisdemo' with size 10g on containing aggregate 'aggr0' has completed.
Anschließend müssen wir Daten auf unserem Volume erzeugen. Das machen wir am einfachsten und schnellsten mit dem versteckten Befehl mkfile. Ein Vorteil von mkfile ist, dass es lauter Nullen in die erzeugte Dateien schreibt – welche Daten eignen sich besser für Deduplizierung als lauter Nullen? na3024> priv set -q diag na3024*> mkfile 1g /vol/asisdemo/f1 na3024*> mkfile 1g /vol/asisdemo/f2 na3024*> df -h asisdemo Filesystem total used /vol/asisdemo/ 8192MB 2052MB
avail capacity 6139MB 25%
Nun liegen ca. 2 GB in zwei verschiedenen Dateien vor – fast alle Blöcke können theoretisch eliminiert werden. A-SIS müssen wir für das Volume aktivieren und danach den Deduplizierungsprozess starten: DeDupe aktivieren na3024*> sis on /vol/asisdemo SIS for "/vol/asisdemo" is enabled. Already existing data could be processed by running "sis start -s /vol/asisdemo".
Initialen DeDupe-Lauf starten na3024*> sis start -s /vol/asisdemo The file system will be scanned to process existing data in /vol/asisdemo. This operation may initialize related existing metafiles. Are you sure you want to proceed with scan (y/n)? y Mon May 14 15:00:37 MEST [wafl.scan.start:info]: Starting SIS volume scan on volume asisdemo.
506
NetApp-Spezialitäten
Den initialen Lauf müssen Sie nur einmal durchführen, später starten Sie die Deduplizierungsvorgänge entweder per Scheduler oder manuell. Der Filer erstellt nun im Hintergrund seine Fingerprint-Datenbank mit den Hashes aller Blöcke auf dem Volume. Dieser Vorgang braucht erstaunlich wenig CPU, wirkt sich aber negativ auf den Read-Cache aus. Das Cache-Age sinkt auf wenige Minuten. Den Fortschritt der Indizierung prüfen Sie wie folgt: Phase 1: Fingerprints sammeln na3024*> sis status Path /vol/asisdemo na3024*> na3024*> sis status Path /vol/asisdemo
/vol/asisdemo State Status Enabled Active
Progress 1949 MB Scanned
/vol/asisdemo State Status Enabled Active
Progress 2048 MB Scanned
Phase 2: Doppelte Prüfsummen finden
Jetzt identifizieren Sie die doppelten Blöcke anhand des Indexes: na3024*> sis status /vol/asisdemo Path State Status /vol/asisdemo Enabled Active
Progress 372 MB Searched
Phase 3: Die Dubletten entfernen na3024*> sis status /vol/asisdemo Path State Status /vol/asisdemo Enabled Active na3024*> sis status /vol/asisdemo Path State Status /vol/asisdemo Enabled Active
Progress 178 MB (8%) Done Progress 559 MB (27%) Done
Das Ergebnis ist wie folgt: na3024*> sis status Path /vol/asisdemo na3024*> na3024*> sis status -l Path: State: Status: Progress: Type: Schedule: Last Operation Begin:
State Enabled
Status Idle
Progress Idle for 00:07:31
/vol/asisdemo Enabled Idle Idle for 00:07:33 Regular sun-sat@0 Mon May 14 15:00:37 MEST 2009
507
9.4
9
Storage-Konfiguration unter VMware
Last Operation End: Mon May Last Operation Size: 2048 MB Last Operation Error: Stage: Done Fingerprints Gathered: 524288 Gathering Begin: Mon May Fingerprints Sorted: 524288 Duplicate Blocks Found: 524287 Sorting Begin: Mon May Blocks De-duplicated: 522571 De-duping Begin: Mon May Fingerprints Deleted: 0 Checking Begin: na3024*> na3024*> df -h asisdemo Filesystem total /vol/asisdemo/ 8192MB
14 15:02:42 MEST 2009
14 15:00:37 MEST 2009
14 15:01:10 MEST 2009 14 15:01:15 MEST 2009
used 30MB
avail capacity 8161MB 0%
Das Beispiel zeigt extreme Einsparungsraten: Von 524.288 Blöcken sind 524.287 Blöcke gleich! Das war zu erwarten, da nur Nullen in den Blöcken enthalten sind. Warum konnten aber nur 522.571 Blöcke dedupliziert werden? Das liegt an der Art und Weise, wie das WAFL-Dateisystem von NetApp funktioniert. Momentan sind »nur« 255 Zeiger auf den gleichen Block möglich. Dadurch ergibt sich eine maximale Einsparungs-Rate von 1:255. Schließlich können Sie sich noch anzeigen lassen, wie viel wirklich eingespart wurde: na3024*> sis stat -b Path Allocated /vol/asisdemo 13615 blocks na3024*> sis stat -v Path Allocated /vol/asisdemo 53 MB
Saving 783345 blocks Saving 3059 MB
%Saved 98% %Saved 98%
Es sei nochmals angemerkt, dass dies ein Extrembeispiel ist. Realistische Werte bewegen sich je nach Art der Daten zwischen 5 und 70 % Einsparung. Wer grob abschätzen möchte, wie viel er sparen könnte, dem sei die NetApp-(Marketing-) Website www.dedupecalc.com empfohlen. Thin Provisioning Thin Provisioning ermöglicht weitere Platzeinsparungen auf dem Speichersystem, da nur noch der Speicherplatz reserviert wird, der auch real belegt ist. Dadurch können Sie das Speichersystem überbuchen, also mehr Kapazität an die Hosts vergeben, als wirklich vorhanden ist. Das ist an vielen Stellen sehr sinnvoll,
508
NetApp-Spezialitäten
da die Platzausnutzung des Hosts oft sehr schlecht ist. Dies wollen wir an einem Beispiel zeigen. Wir gehen davon aus, dass der ESX-Host ein FCP-Datastore (also eine LUN) benötigt, die 100 GB groß ist. Auf dem NetApp-System legen Sie ein Volume an, das ebenfalls 100 GB groß ist und das wiederum eine 100 GB große LUN enthält. Es sollen keine NetApp-Snapshots erstellt werden, deshalb reichen 100 GB VolumeGröße aus. Somit sind auf der NetApp 100 GB Platz verbraucht, obwohl der ESXHost noch gar nichts in dem Datastore abgelegt hat. Die Planung ist, dass in diesem Datastore 7 VMs mit je 10 GB vmdk abgelegt werden sollen, somit wären ca. 70 GB verbraucht, allerdings muss noch 30 GB Platz freigelassen werden, da die VMs ja Delta-Dateien (für VMSnapshots) und vswpFiles für Memory-Overcommitment anlegen werden. Innerhalb eines jeden vmdks wird Windows XP installiert, die Installation ist ca. 4 GB groß, dazu kommen 2 GB pro VM an Applikationen. Zusammengezählt wäre der reale Platzverbrauch 7 × 6 GB, in Summe 42 GB. Doch auf der NetApp wurden 100 GB belegt. Durch Thin Provisioning können Sie den nicht belegten Platz wieder frei machen. Thin Provisioning auf NetApp-Seite ist nicht mit dem Thin-Format der VMDKPlatten zu verwechseln! Der Mechanismus ist zwar grundlegend der gleiche, allerdings spart ein Thin-VMDK auf NetApp nur Platz, wenn die LUN auch im Thin-Provisioning-Modus läuft oder das Thin-VMDK auf einem NFS-Datastore liegt. Auf NetApp-Seite gibt es mehrere logische Schichten, die überbucht werden können. Die wichtigste Schicht ist die LUN. Ob eine LUN dünn provisioniert ist, hängt damit zusammen, ob die sogenannte LUN Space Reservation aktiviert ist. Das wählen Sie beim Anlegen der LUN aus (lun create -o noreserve) oder schalten es später an- und ab (lun set reservation enable/disable). LUN Space Reservation an hat zwei Auswirkungen: 1. Die LUN belegt sofort den vollen Platz im Volume, auch wenn noch keine Blöcke in der LUN belegt wurden. 2. Sämtlicher Platz, der in der LUN belegt ist, wird im Falle eines VolumeSnapshots auf der NetApp noch einmal außerhalb der LUN im Volume belegt, man spricht von der Overwrite Reserve.
509
9.4
9
Storage-Konfiguration unter VMware
Punkt 1 ist an sich schon unschön, siehe die Kalkulation von gerade eben. Aber Punkt 2 wirkt sich sehr negativ auf die Platzbelegung aus, da im Falle einer vollen LUN die doppelte LUN-Größe im Volume an Platz belegt (eigentlich reserviert) wird. Es gibt eine Volume-Option namens Fractional Reserve, die per Default auf 100 % steht. Sie besagt, dass 100 % des in der LUN belegten Platzes nochmals außerhalb reserviert werden, falls ein Snapshot erstellt wurde. Sie können diese Option justieren und den Wert reduzieren (z. B. auf die reale Datenänderungsrate), aber dann ist nicht mehr gewährleistet, dass immer genug Platz im Volume zur Verfügung steht, um alle Schreibzugriffe erfolgreich durchzuführen. Noch einmal ganz deutlich: Wer diese Reserve angeschaltet lässt, hat immer die Sicherheit, dass genug Platz für Schreibzugriffe in der LUN vorhanden ist – allerdings wird auch ziemlich viel Platz verschwendet. LUN Space Reservation aus hat auch zwei Auswirkungen: 1. Die LUN belegt nur den Platz im Volume, der auch innerhalb der LUN belegt ist. 2. Im Falle von Snapshots des Volumes, in dem die LUN liegt, wird keinerlei Reserve abgebildet. Dieser Zustand ist aus Gründen der Platzeinsparung optimal, da leerer Platz dann keinerlei Speicher im Volume der NetApp belegt. Allerdings besteht hier die große Gefahr, dass das Volume sich so weit füllt, dass kein Platz mehr für Schreibzugriffe in der LUN zur Verfügung steht. In diesem Fall nimmt die NetApp die LUN aus Schutzgründen bezüglich der Datenkonsistenz die LUN offline: Das fatale Resultat für den ESX-Host ist, dass der Datastore verschwindet und alle VMs darin abstürzen werden. Damit das nicht passieren kann, gibt es einen Schutzmechanismus, der sich »Volume Autosize« nennt. Sie können einstellen, dass im Volume automatisch bestimmte Snapshots gelöscht (snap autodelete) werden oder dass das Volume sich automatisch vergrößert (vol autogrow). Im Falle von NFS-Datastores ist das Thin Provisioning wesentlich einfacher, da im Volume ja sowieso nur der Platz belegt ist, der real durch Daten im Datastore verwendet wird. Ein Container wie LUNs existiert bei NFS nicht. Zusätzliche Einsparungen sind einfach möglich, indem Sie die VMDKs als Thin-Files anlegen (default). Deduplication von NetApp erzeugt weiteren freien Platz im Volume. Diesen neuen Platzgewinn können Sie mit LUNs nur dann nutzen, wenn diese thin-provisioned sind. Wäre die Platzreserve dagegen nicht ausgeschaltet, so belegt die
510
NetApp-Spezialitäten
LUN immer ihre volle Größe – egal ob Daten darin sind oder nicht. Einsparungen von DeDupe werden bei NFS-Datastores sofort sichtbar. Aggregate überbuchen Die Einsparungen, die im Volume durch Thin Provisioning oder DeDupe erzielt werden, sollten im Idealfall an das Aggregat weitergegeben werden, in dem das Volume liegt, nur dann können andere Volumes im selben Aggregat vom gewonnenen Speicher profitieren. Der dafür vorgesehene Mechanismus heißt Volume Space Guarantee und lässt sich in drei Stufen einstellen: 1. Volume: Der gesamte Volume-Platz wird im Aggregat abgezogen, egal ob Daten darin liegen oder nicht, ähnlich der vollen LUN Space Reservation. 2. None: Im Aggregat wird nur der Plattenplatz belegt, der auch im Volume real verbraucht ist. 3. File: Das Aggregat reserviert für das Volume exakt so viel Platz, wie das Volume benötigt, um die LUN Space Reservation einzuhalten. Somit wäre im Gesamtbild betrachtet die platzsparendste Variante: 1. LUN Space Reservation: aus 2. DeDuplizierung: an 3. Volume Space Reservation: auf None Die große Krux an Thin Provisioning ist, dass Sie gezwungen sind, die Platzverbräuche zu überwachen, um eine Überfüllung des gesamten Systems frühzeitig zu erkennen und zu verhindern. Das Monitoring-Produkt Operations Manager von NetApp erlaubt dies. Wer lieber mit einer Open-Source-Lösung arbeiten möchte, dem sei das Nagios-Plug-in check_filer der Firma Teamix GmbH aus Nürnberg empfohlen. Noch einmal deutlich: Thin Provisioning ist eine tolle Sache, wer aber nicht überwacht, der handelt fahrlässig!
9.4.3
Best Practices
Zu Beginn dieses Kapitels haben wir die grundlegende Konfiguration und Einrichtung der Storage-Anbindung gezeigt, allerdings sind im Zusammenhang mit NetApp und Speichersystemen allgemein noch weitere Punkte für einen reibungslosen Betrieb zu beachten. All diese Punkte fassen wir hier unter »Best Practices« zusammen.
511
9.4
9
Storage-Konfiguration unter VMware
NetApp Host Utilities NetApp liefert für die automatische Implementierung aller empfohlenen Einstellungen die sogenannten Host Utilities an seine Kunden aus. Der Download der Software von now.netapp.com ist kostenlos, so Sie einen Log-in für diese Seite besitzen. Für vSphere 4 ist mindestens die Version 5.1 vom Mai 2009 nötig. Diese Utilities liefern Folgendes mit: 왘
optimierte Einstellungen für HBAs
왘
richtiges Setzen der Timeout-Werte für LUNs und NFS-Datastores
왘
richtige Timeouts für Gastbetriebssysteme
왘
Diagnosetools für HBAs, SAN-Switches und die NetApp
왘
Prüfen und Korrigieren von VMDK-Alignment-Fehlern (siehe S. 514 unter Überschrift, »Virtual Storage Console«)
Damit der VMware-Betrieb im NetApp-Umfeld richtig funktioniert, ist es zwingend nötig, entweder alle diese Einstellungen durchzuführen oder die ESX Host Utilities (HU) zu installieren, sonst kommt es in einigen Fällen (z. B. Cluster-Takeover) zu Problemen, weil z. B. der ESX-Host seinen Datastore verliert. Die ESX Host Utilities installieren Sie in der Service Console. Sollte der Kunde die Variante ESXi gewählt haben, so hat er leider keinen Zugriff auf die Service Console und muss auf die neue Alternative der Host Utilities zurückgreifen, die Virtual Storage Console (VSC). Mehr dazu im Anschluss. Die Host Utilities werden in Form eines TGZ-Paketes geliefert. Sie installieren Sie nach dem Entpacken einfach mit dem Skript ./install auf dem ESX-Host: [root@rx3008-esx ~]# tar xfz netapp_esx_host_utilities_5_1.tar.gz [root@rx3008-esx ~]# cd netapp_esx_host_utilities_5_1 [root@rx3008-esx netapp_esx_host_utilities_5_1]# ./install These tools require several ports to be open in the ESX firewall. The following ports will need to be opened: 20/tcp (incoming) 21/tcp (outgoing) 23/tcp (outgoing) 80/tcp (incoming/outgoing) 443/tcp (incoming) Do you want to open the ports now (yes or no)?> yes Installing VMware(R) ESX Host Utilities 5.1......................... Unpacking files to /opt/netapp/santools.................DONE Adding the ESX Host Utilities firewall rules............DONE Enabling the ESX Host Utilities firewall service........DONE Creating symbolic link for sanlun.......................DONE
512
NetApp-Spezialitäten
Creating symbolic link for config_nfs...................DONE Creating symbolic link for config_hba...................DONE Creating symbolic link for config_mpath.................DONE Creating symbolic links for MAN pages...................DONE Checking for installed HBAs.............................DONE Installing Emulex HBAAPI libraries......................DONE Optimizing HBA settings.................................DONE Optimizing NFS Heartbeat settings.......................DONE Optimizing Preferred Paths............................. DONE
Die Host Utilities sind nun installiert, Sie finden die Binaries unter /opt/netapp/ santools. Die wichtigsten Tools für den Umgang mit Datastores und LUNs sind: 왘
sanlun (sanlun lun show)
Zeigt eine Übersicht, welche LUNs von der NetApp welche Device-Namen auf dem ESX haben. 왘
config_mpath (config_mpath –loadbalance –primary)
Setzt die aktiven und passiven FCP-Pfade zur NetApp; bei echtem RoundRobin-Load-Balancing sollten Sie wie im Abschnitt zu FCP vorher beschrieben auch noch config_mpath –m ausführen. 왘
config_hba und config_nfs
Setzen die Timeout- und Queue-Length-Variablen richtig. Sind die Einstellungen für den ESX-Host nun so weit korrekt ausgeführt, so müssen Sie auch noch zwingend in jedem Gastsystem den richtigen Wert für die DiskTimeouts setzen. Dafür liefert NetApp ISO-Files mit, die Sie lediglich an die virtuellen Maschinen binden. Im Falle von Windows wird automatisch ein RegistryKey gesetzt, der den Disk-Timeout auf 190 Sekunden stellt; bei Linux passiert etwas ähnliches, allerdings über udev und nicht über die Registry. Die GOS-ISOFiles werden bei der Host-Utilities-Installation unter /vmimages/gos_timeout-isoimages abgelegt. Die Werte können Sie auch manuell ohne Guest-OS-ISO setzen: Windows:
Setzen Sie [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk] auf 190. Linux:
Tragen Sie in die Datei /etc/udev/rules.d/z50_netapp.rules folgende Zeile ein: ACTION=="add", SUBSYSTEM=="scsi", SYSFS{type}=="0|7|14", RUN+="/bin/sh -c 'echo 190 > /sys/$$DEVPATH/timeout'"
513
9.4
9
Storage-Konfiguration unter VMware
ONTAP-Versionen vor 7.3 brauchen einen Timeout von 190 Sekunden, ab 7.3 reichen laut NetApp auch 130 Sekunden. Virtual Storage Console Die noch relativ junge Virtual Storage Console (VSC) von NetApp ist ein Plug-in für das ESX-vCenter, das Konfiguration und Prüfung der NetApp-Einstellungen für optimale Zusammenarbeit mit VMware erlaubt. Nach aktueller Planung von NetApp wird die VSC langfristig die Host Utilities ersetzen – momentan sind sie nur dann wirklich nötig, wenn man auf ESXi setzt. Nach der Installation sehen im vCenter-Client ein weiteres Konfigurationsfenster, Sie müssen noch die Log-in-Daten für die NetApp eingeben (Abbildung 9.52).
Abbildung 9.52
Konfiguration der Virtual Storage Console
Anschließend erhalten Sie eine schöne Übersicht über die SAN-Komponenten (Abbildung 9.53). Diese Übersicht gibt es auch für die NAS-Datastores, zu sehen in Abbildung 9.54.
514
NetApp-Spezialitäten
Abbildung 9.53
Ansicht des FCP Datastores und einer freien LUN
Abbildung 9.54
Ansicht eines NFS Datastores
515
9.4
9
Storage-Konfiguration unter VMware
Die VSC erlaubt auch die Sammlung von Supportinformationen, ähnlich der Kommandos switch_info, sanlun, esx_info usw. aus den Host Utilities. Diese Log-Files können Sie dann im Supportfall an NetApp oder VMware hochladen (Abbildung 9.55).
Abbildung 9.55
Informations-Sammler für Support-Fälle
Neben den reinen Informationen lässt die VSC den Administrator auch per Klick die Best Practices wie Timeouts usw. anzeigen, kontrollieren und konfigurieren (Abbildung 9.56 und Abbildung 9.57).
Abbildung 9.56
516
Matrix zur Prüfung der empfohlenen Einstellungen
NetApp-Spezialitäten
Abbildung 9.57
Automatische Konfiguration der empfohlenen Einstellungen
Genau wie auch die Host Utilities bringt die VSC die notwendigen Tools wie mbrscan und mbralign mit, um die Alignment-Probleme von vmdk-Dateien zu reparieren. Auch die Timeout-Guest-OS-ISOs werden mitgeliefert (Abbildung 9.58).
Abbildung 9.58 Download der mitgelieferten Tools
Fazit: Die VSC ist ein würdiger Nachfolger der ESX Host Utilities, besonders positiv hervorzuheben ist die Übersichtlichkeit bei der Prüfung, ob die korrekten Werte eingestellt sind. Wichtig ist auch der neue Support von ESXi – bisher mussten die Kunden mit ESXi aufgrund des fehlenden Supports der Host Utilities alle Einstellungen manuell durchführen.
517
9.4
9
Storage-Konfiguration unter VMware
Alignment-Probleme: LUNs, VMFS, NFS und »vmdk«-Dateien Um die beste Performance für VMs auf einer NetApp zu erreichen, ist es notwendig, dass die File-System-Blöcke innerhalb eines Guest-OS direkt korrekt an den Blockgrenzen des NetApp-Speichersystems ausgerichtet (englisch: Alignment) sind. Typischerweise sind in einer vSphere-Umgebung mehrere verschiedene Schichten im Speicherumfeld vorhanden; wir betrachten die Schichten von der untersten bis zur obersten: 왘
NetApp-WAFL-File-System und die darin liegenden LUNs
왘
VMFS-3-File-System auf der LUN
왘
vmdk-Datei mit Partitionierung und File-System des Gast-OS
Durch diese verschiedenen involvierten Schichten kommt es zu einem unschönen Effekt: Jede Schicht bringt eigene Partitionstabellen mit, die den Anfang der Partition so verschieben, dass die Grenzen nicht mehr korrekt aneinander ausgerichtet sind, wie Abbildung 9.59 zeigt. inkonsistente Zuordnung VM-NTFS-Partition
VMFS-Partition
Storage-Partition
Abbildung 9.59 Inkonsistente Partitions-Ausrichtung
So kann es dazu kommen, dass ein Schreib- oder Lesezugriff auf einen Block im Guest-OS zu zwei oder gar drei Zugriffen auf dem NetApp-System führt. Das wirkt sich negativ auf die Antwortzeit und die Last des Speichersystems aus, die Performance der virtuellen Maschine verschlechtert sich. konsistente Zuordnung VM-NTFS-Partition
Cluster
VMFS-Partition
Blocks
Storage-Partition
Chunks
Abbildung 9.60
518
Konsistentes Partition-Alignment
NetApp-Spezialitäten
Der eigentliche Haken am Thema Ausrichtung (oder auf Englisch: Alignment) ist, dass die Default-Einstellungen der Partitionierungstools fdisk (Linux) und diskpart (Windows) sowie die vmkfstools von VMware dieses Problem hervorrufen. Oder anders ausgedrückt: Die Default-Einstellungen führen leider zum falschen Ergebnis. Dieses allgemeine Problem tritt bei jedem Speicherhersteller auf, NetApp liefert aber zum Glück Lösungen, um die Alignment-Probleme zwischen allen Schichten zu korrigieren. LUN-Alignment korrigieren Um die VMFS-3-Partition automatisch korrekt an der NetApp-Blockgrenze der LUN und des WAFL-Dateisystems auszurichten, ist nur sehr wenig Aufwand nötig. Im Prinzip erledigt NetApp die gesamte Arbeit für uns, vorausgesetzt, dass der Administrator beim Erstellen der LUN den richtigen LUN-Typ auswählt. na3021> lun create –s 200g –t vmware ...... na3021> lun show -v /vol/esxfcp/fcp_ds01.lun 200g (r/w, online, mapped) Serial#: P3HwDJT0HNed Share: none Space Reservation: disabled Multiprotocol Type: vmware Maps: esx_fcp_all=1
Der Multiprotocol Type steht auf vmware, das heißt, NetApp rechnet einfach den entsprechenden Partition-Offset des VMFS-3-Dateisystems dazu, somit ist die Blockgrenze des VMFS-3 identisch mit der der NetApp-LUN. Bei NFS-Datastores ist ein LUN-Alignment nicht notwendig, schließlich gibt es in diesem Zusammenhang keine LUNs. Auf die korrekte Ausrichtung der vmdkDateien müssen Sie jedoch trotzdem achten, wie gleich im Anschluss erklärt wird. VMDK-Alignment korrigieren Anschließend müssen Sie noch die Ausrichtung der Dateisystemblöcke innerhalb des vmdk-Disk-Files korrigieren, was sich leider als etwas aufwendiger erweist, da dieses Alignment direkt vom Gastbetriebssystem abhängt. Jedes Gastbetriebssystem hat eigene Partitionen, daher sind Sie auf die verschiedenen Partitionierungstools angewiesen. Die generelle Regel ist: NetApp hat eine Blockgröße von 4K (4.096 Bytes), also muss die Partition auch ein einer 4K-Grenze beginnen.
519
9.4
9
Storage-Konfiguration unter VMware
Entweder legen Sie vor der Installation des Gastbetriebssystems manuell eine korrekt ausgerichtete Partition an (und erstellen darauf ein sauberes VM-Template), oder Sie korrigieren das Problem später mit dem Tool mbralign von NetApp aus den Host Utilities bzw. der Virtual Storage Console. Möglichkeit 1: Manuelle Partitionierung Windows-Partitionen haben per Default einen Partition-Offset von 32.256 Bytes, das wird sehr schön unter msinfo32.exe sichtbar (Abbildung 9.61).
Abbildung 9.61 MSInfo32 zeigt den Partitionstartoffset an, der Maßgabe für die Alignment-Prüfung ist.
Allerdings ist 32.256 kein volles Vielfaches von 4.096, also stimmt das Alignment nicht. Die Lösung ist, eine leere virtuelle Festplatte an eine vorhandene VM anzuhängen und manuell mit diskpart.exe eine Partition anzulegen. Diese Festplatte hängen Sie anschließend an eine neue VM an und installieren darin dann Windows (Abbildung 9.62).
Abbildung 9.62
520
Erstellen einer richtig ausgerichteten Partition mit Diskpart
NetApp-Spezialitäten
Das Ergebnis in msinfo32.exe zeigt danach, dass die Partition jetzt richtig ausgerichtet ist, da der neue Offset mit 32.768 Bytes durch 4.096 teilbar ist. Unter Linux müssen Sie die Partition in der VM auf einer leeren Disk mit dem Befehl fdisk /dev/sda anlegen (Abbildung 9.63).
Abbildung 9.63
Partition mit fdisk unter Linux anlegen
Nachdem Sie wie im Screenshot dargestellt eine neue Partition mit (n) angelegt und die gesamte Platte ausgewählt haben, ändern Sie anschließend im ExpertenModus (x) den Beginn der Partition (b), und zwar auch wieder auf einen durch 4 096 teilbaren Wert, z. B. 64K; das Ergebnis sollte dann aussehen wie in (Abbildung 9.64).
Abbildung 9.64
Mit fdisk unter Linux die Partition prüfen
Egal, ob Sie eine sauber ausgerichtete Linux- oder Windows-Platte angelegt haben, das Ergebnis sollten Sie auf jeden Fall nach der Betriebssysteminstallation als VM-Template festhalten, damit Sie diese Arbeit nicht für jede neue VM erledigen müssen. Möglichkeit 2: Reparatur mit NetApp Tools Für Administratoren, die mit richtigem Alignment bisher noch nicht allzu vertraut sind, gibt es auch eine Abhilfe: Die beiden kleinen Programme mbrscan und mbralign aus den Host Utilities von NetApp können falsch ausgerichtete vmdks aufspüren und reparieren. Zuerst starten Sie das Programm mbrscan auf das entsprechende -flat.vmdk-File: # /opt/netapp/santools/mbrscan OK-fcp-w2k3-1-flat.vmdk -------------------OK-fcp-w2k3-1-flat.vmdk p1 (NTFS) lba:63
offset:32256
aligned:No
--------------------
521
9.4
9
Storage-Konfiguration unter VMware
Sie können auch einen Massenlauf mit einfachen Shell-Wildcards auf sämtliche VMs im Datastore anstoßen, um einen schnellen Gesamtüberblick zu erhalten: # /opt/netapp/santools/mbrscan /vmfs/volume/fcp_datastore1/*/*-flat.vmdk
Wichtig! Um die betroffenen VMDKs zu reparieren, müssen Sie die VM ausschalten. Außerdem darf die VM keine Snapshots oder Linked Clones besitzen!
Anschließend starten Sie den Befehl mbralign auf das vmdk-File (nicht das -flat.vmdk): # /opt/netapp/santools/mbralign OK-fcp-w2k3-1.vmdk Part Type old LBA New Start LBA New End LBA Length in KB P1 07 63 64 12562831 6281383 Creating a backup of OK-fcp-w2k3-1.vmdk Creating a backup of ./OK-fcp-w2k3-1-flat.vmdk Creating a copy the Master Boot Record Working on partition P1 (3): Starting to migrate blocks from 32256 to 32768. 12801 read ops in 1 sec. 99.29% read (99.31 mB/s). 99.29% written (99.31 mB/s) Working on space not in any partition: Starting to migrate blocks. 100.00 percent complete. 100.00 percent written. Making adjustments to ./OK-fcp-w2k3-1-flat.vmdk. Adjusting the descriptor file.
Das Tool erstellt zunächst ein Backup der Originalendatei und legt dann eine neue, konsistent zugeordnete vmdk-Festplattendatei an und kopiert die Blöcke aus dem Original in die neue Datei. Dabei gibt es neben dem Aspekt der Plattenplatzbelegung (Aufräumen nicht vergessen!) auch zu beachten, dass nach der Reparatur eventuell der Bootloader der VM nicht mehr funktioniert, besonders Linux-VMs sind betroffen, WindowsVMs weniger. Die Abhilfe für einen kaputten Bootloader ist sehr einfach: Booten Sie eine Recovery-DVD, z. B. Knoppix oder die Distributions-CD, und schreiben Sie den Bootloader bzw. den Bootrecord neu. Im Falle von GRUB starten Sie nach dem Boot von der Rescue-CD den Befehl grub: grub> root hd(0,0) grub> setup (hd0) grub> quit
Danach sollte die Linux-VM auch wieder problemlos booten.
522
Es existieren äußerst viele Storage-Hersteller und Storage-Modelle auf dem Markt. Viele Hersteller haben sich der Server-Virtualisierung angenommen und neue Funktionen genau für die Anforderungen der Virtualisierung entwickelt. In diesem Kapitel finden Sie eine kleine Auflistung der Hersteller-Best-Practices.
10
Hersteller-Best-Practices Autor dieses Kapitels ist Dennis Zimmer, icomasoft AG, [email protected]
Im Folgenden finden Sie Informationen zu Storage-Produkten und ihren Herausstellungsmerkmalen. Außerdem haben wir zu vielen Produkten auch Best Practices (BP) hinterlegt sowie die uns bekannten URLs zu diesen. Aufgrund der Vielzahl an verschiedenen Einstellungen und Herstellerempfehlungen können wir nicht alle Produkte auflisten und haben uns dazu entschlossen, dies von der Menge an Informationen und natürlich auch von der Unterstützung durch die Hersteller abhängig zu machen.
10.1
Storage-Produkte
Leider existieren noch nicht von jedem Hersteller die aktuellen BP-Anleitungen zu vSphere, sondern nur zu VMware ESX 3.5. Eine allgemeine Übersicht erhalten Sie auch in den Dokumentationen von VMware: http://www.vmware.com/support/pubs/vs_pages/vsp_pubs_esx40_vc40.html 왘
Fibre Channel SAN Configuration Guide (»Setting Up SAN Storage Devices with ESX/ESXi«)
왘
iSCSI SAN Configuration Guide (»Modifying SAN Storage Systems with ESX/ESXi«)
10.1.1
3PAR
3PAR hat sich als relativ junger Hersteller im Storage-Markt sehr schnell einen Namen für sehr performanten und effizienten Storage im Enterprise-Segment
523
10
Hersteller-Best-Practices
gemacht. Die F-Modelle sind im Mid-Range-Segment anzusiedeln, die T-Modelle im oberen Mid-Range-Bereich und im High-End-Enterprise-Bereich. Die größte Unterscheidung bei den Modellen und Typen liegt in der Ausbaufähigkeit und Skalierbarkeit der Hardware. Die System- und Verwaltungssoftware (Abbildung 10.1) ist immer die gleiche.
Abbildung 10.1 Mit der InForm-Verwaltungskonsole können Sie bis zu 16 Systeme gleichzeitig verwalten und überwachen.
F200 Controller Nodes Fibre Channel Host Ports Optional iSCSI Host Ports Built-in Remote Copy Ports GBs Control Cache GBs Data Cache Disk Drives Drive Types Throughput/ IOPS (from disk) SPC-1 Benchmark Results
F400
T400
T800
2
2–4
2–4
2–8
0 –12 0–8 2
0 –24 0 –16 2
0 –64 0 –16 2
0 –128 0 –32 2
8 12
8 –16 12 –24
8 –16 24 – 48
8 –32 24 –96
16 –192
16 –384
16 – 640
16 –1,280
FC 15K, FC 10K, NL 7.2K
FC 15K, FC 10K, NL 7.2K
FC 15K, FC 10K, NL 7.2K
FC 15K, FC 10K, NL 7.2K
1,300 (MB/s)/ 46,800
2,600 (MB/s)/ 93,600
3,200 (MB/s)/ 156,000
6,400 (MB/s)/ 312,000
93,050 SPC-1 IOPS
224,990 SPC-1 IOPS
Abbildung 10.2 3PAR-Modellübersicht (Anzeige der 3PAR-Modelle: http://www.3par.com/ products/inserv_storage_server/inserv_models.html).
Die schnelle Adaptierung des Storage im Markt begründet sich u. a. in der sehr leistungsfähigen Architektur (Abbildung 10.2) des Systems und der Verteilung der Daten über die Festplatten. 3PAR verfügt über ein vollwertiges active/activeSystem.
524
Storage-Produkte
Traditional Monolithic Architecture
3PAR InSpire® Architecture
point-to-point or switched connection
point-to-point or switched connection
Legend
Traditional Modular Architecture
Abbildung 10.3
Host Connectivity
a finely, massively, and automatically load balanced cluster
Data Cache Disk Connectivity
Vergleich traditioneller Architektur gegenüber 3PAR InSpire®
Außerdem werden die Daten nicht nur über die Festplatten, sondern auch über die Kontroller und die Ports verteilt (Abbildung 10.3), wodurch eine optimale Lastverteilung entsteht. Dies können Sie auch jederzeit in der 3PAR InForm Management Console einsehen.
Abbildung 10.4
Ansicht der aktuellen SCSI-Reservations
In der Verwaltungsoberfläche lässt sich sehr leicht erkennen, ob noch SCSI-Reservations (Abbildung 10.4) aktiv sind, was beim Betrieb größerer Infrastrukturen sehr interessant ist, da dies auf eine zu hohe Anzahl von VMs auf einer LUN hinweist.
525
10.1
10
Hersteller-Best-Practices
Abbildung 10.5 Die Datenverteilung über Festplatten des gleichen Tiers (hier FC-Festplatten) sehen Sie über die InForm Management Console ein.
Durch die intelligente Verteilung der Daten über alle Kontroller, Platten und Ports müssen Sie aus VMware-Sicht keine weitere manuelle Lastverteilung durchführen. Daher müssen Sie aus Storage-Sicht (Abbildung 10.5) nur den Parameter zur automatischen Verteilung bei der LUN-Anlage auf dem Standardwert aktiv belassen. VM store 1 VM store 2 VM store 3 19200 IOPS available to all 3 VM stores
96 x 15K disks Potential 19200 IOps
Abbildung 10.6 Die LUNs werden auf alle Festplatten verteilt, was eine enorme Leistung für die VMs bereitstellt.
526
Storage-Produkte
Werden Platten hinzugefügt oder fallen Festplatten aus, so kommt es nicht zu einem Levelling mit Leistungseinbruch, sondern der Migrationsvorgang ist unterbrechungsfrei. Dieser Migrationsvorgang kann auf der Virtual-VolumeEbene oder im ganzen Array durchgeführt werden. Der Performance-Vorteil durch die Erhöhung der Festplattenanzahl ist sehr schnell realisiert. Außerdem wird die Veränderung von RAID-Level oder Festplattentypen (von FC nach SATA) im laufenden Betrieb ebenfalls ohne Ausfall unterstützt. Technisch läuft dies im Hintergrund mittels transparenter Migrationsvorgänge auf neue Blöcke im Storage ab. Nach dieser Migration arbeitet der Host auf den neuen Blöcken, während die alten gelöscht und dem Pool wieder zur Verfügung gestellt werden. Für den ESX-Host ist der komplette Vorgang nicht zu erkennen und bringt keine Nachteile mit sich. Außerdem kann der Migrationsvorgang jederzeit vom Administrator pausiert, abgebrochen, gestoppt und später wieder aufgenommen werden. Beispiel: Arbeiten Sie mit einem 3PAR-InServ-T400-System mit vier Kontrollerknoten und 400 Fibre-Channel-Festplatten mit 15.000 RPM und erstellen eine Standard-LUN (nicht Thin Provisioning) mit 400 GB, so wird diese LUN automatisch über alle 400 Festplatten mit jeweils 1 GB verteilt und sichergestellt, dass über jeden Kontrollerknoten 100 GB verwaltet werden. Dies ist unabhängig vom genutzten RAID-Level.
Diese 400 Festplatten arbeiten wie ein Pool zusammen und erbringen die Leistung für alle darauf angelegten LUNs (Datastores). Jede dieser LUNs wäre daher potentiell in der Lage, 80.000 IOPS im Backend zu erbringen, wenn wir von 200 IOPS pro 15K-FC-Platte und einer durchschnittlichen Latenzzeit von 10 ms ausgehen. Multipathing Beim Multipathing können Sie aus VMware-Sicht Fixed oder Round-Robin wählen, da das 3PAR-System über ein vollwertiges active/active verfügt und mit den eingebautem VMware NMP (Native-Multipathing-Plug-in) arbeitet. Daher benötigen Sie weder ALUA noch ein Dritthersteller-Modul. 3PAR empfiehlt, RoundRobin so zu konfigurieren, dass nach jedem I/O der Pfad gewechselt wird. Dazu führen Sie den Befehl esxcli entweder auf der Service Console oder im Remote CLI aus:
527
10.1
10
Hersteller-Best-Practices
왘
Service Console: esxcli nmp roundrobin setconfig --device=naa.## --iops 1 --type iops
Um die NAA-Adressen der LUNs und die Werte auszulesen, benötigen Sie folgende Befehle: esxcfg-mpath -l esxcli nmp roundrobin getconfig --device=naa.## 왘
Remote CLI: esxcli --server=ESXIP nmp roundrobin setconfig --device=naa.## --iops 1--type iops
Thin Provisioning 3PAR gilt außerdem als Erfinder des Thin Provisionings im blockorientierten Storage-Bereich und bietet daher sehr weit entwickelte Funktionen.
Abbildung 10.7
Anzeige, welcher Plattenplatz wirklich von den Volumes genutzt wird
Nutzen Sie Thin Provisioning im Storage-Bereich, sollten Sie allerdings kein Thin Provisioning auf VMware-Seite anwenden, sondern die Festplatten im StandardThick-Format erstellen. Da 3PAR-Thin-Provisioning auf der Storage-Ebene arbeitet, werden die Komponenten des ESX-Hosts auch nicht belastet. Außerdem müssten Sie bei der Verwendung von Thin Provisioning auf beiden Ebenen (VMware und 3PAR) auch beide Ebenen überwachen, was unnötigen Aufwand bedeutet.
528
Storage-Produkte
Abbildung 10.8 Überwachung der Allokation einer Thin-Provisioning-Festplatte, um Überfüllung des Storage-Systems zu verhindern
Seit vSphere hat VMware übrigens die Cloning- und Storage-VMotion-Vorgänge thin-provisioning-kompatibel gestaltet, so dass diese Kopiervorgänge keine Einschränkungen mehr bei der Nutzung von Thin Provisioning im Storage-Umfeld bedeuten. Benutzen Sie das eagerzeroedthick-Format für virtuelle Festplattendateien, das die Blocke mit Nullen überschreibt, so können Sie im 3PAR-System die Policy Zero detect aktivieren (Abbildung 10.9), die diesen Vorgang erkennt und so ein Thin Provisioning trotzdem ermöglicht. Dies bietet sehr große Vorteile aus VMware-Sicht, da Sie nun jedes Format nutzen können, ohne die Thin-Provisioning-Effizienz zu verlieren. Genauer gesagt erlaubt dieser Schalter dem 3PARSystem, jeden vom Host mit Nullen überschriebenen Block (16 KB) auf dem Storage abzufangen. Dadurch wird weniger I/O-Last erzeugt und Thin Provisioning weiterhin ermöglicht. Die Zero-Detect-Erkennung erfordert allerdings eine ThinConversion-Lizenz, InForm OS 2.3.1 und ein InServ-T- oder -F-Typ-System. Diese Zero-Detection ist auch nachträglich möglich, das heißt, das Storage-System überprüft die Blöcke auf Nullen und löscht offensichtliche »Verschwendung«.
529
10.1
10
Hersteller-Best-Practices
Abbildung 10.9 Die Erkennung der geschriebenen Nullen auf 16-KB-Blockbasis können Sie pro Virtual Volume einschalten.
Snapshots und Replication 3PAR bietet sehr flexible Snapshot-Möglichkeiten (Virtual Copy), das heißt, Sie müssen im Vorfeld den Snapshot-Plattenbedarf nicht reservieren. Dies können Sie jederzeit im Nachhinein angehen, vorausgesetzt, der Plattenpool verfügt noch über entsprechende freie Kapazität. Durch das Anlegen der Snapshots wird die Leistungsfähigkeit nicht verringert, selbst wenn Hunderte Snapshots pro Volume existieren. Ähnlich der SnapshotTechnologie von NetApp wird keine Standard-Copy-on-Write-Technik (CoW, beim Schreiben eines neuen Blocks wird dieser im Snapshot und in den von diesem abhängigen Snapshots geschrieben) angewendet, sondern eine Thin CoW, die geänderten Blöcke werden also immer dem ersten Snapshot zugeschrieben und bei anderen Snapshots per Pointer integriert. Hier ist es sogar möglich, die Snapshots auf einem anderen RAID-Level oder anderen Festplatten zu halten als dem Original-Volume. Außerdem können Sie
530
Storage-Produkte
jederzeit die Snapshots zusätzlich read-only oder read-write an den ESX-Host verbinden. Somit könnten Sie einen Snapshot read-only zur Sicherheit vorhalten, während eine weitere Kopie dieses Snapshots bearbeitet werden kann. Kommt es zu einem Problem, haben Sie den Read-only-Snapshot immer als FallbackLösung. Zur Replikation bietet 3PAR die Remote-Copy-Funktion, die eine synchrone oder asynchrone Datenspiegelung mittels FC- oder IP-Netzwerk hält. Dabei gibt Ihnen Remote Copy die Möglichkeit, zwischen unterschiedlichen 3PAR-Modellen zu replizieren. URLs mit weiterführenden Informationen http://www.3par.com/SiteObjects/46004B3AF456B6E5409C237509D3145C/ 3PAR-vmw-wp-09.1.pdf http://www.3par.com/SiteObjects/043E2553E81D03204DBE682CBE4ACD3B/ esx3_3par_util_stor.pdf
10.1.2
CoRAID
CoRAID liefert sehr kostengünstigen zentralen Storage, der allerdings nicht auf den bekannten Standardkommunikationsarten basiert. Zwar wird Ethernet verwendet, allerdings läuft darüber ATA (AoE = ATA over Ethernet) und nicht iSCSI oder NFS.
ESX-Server
EtherDrive HBA
EtherDrive HBA
ESX-Server
Ethernet
EtherDrive Storage
Abbildung 10.10
CoRAID-ATA-over-Ethernet-Zugriff (Quelle: www.coraid.com)
Der CoRAID-Storage ist vom Aufbau her einfach gestrickt und bietet kein ausgefeiltes Management mit Snapshots etc. Allerdings ist er sehr interessant für kleinere und mittlere Umgebungen, wo auf eine sehr kostengünstige Lösung gesetzt werden soll. Die Lösung ist mit den entsprechenden CoRAID-AoE-Ethernet-Karten VMwarezertifiziert und kann damit direkt an den Storage angeschlossen werden. Das
531
10.1
10
Hersteller-Best-Practices
benutzte AoE-Protokoll ist nicht routingfähig und benötigt kein IP, da es direkt auf Layer 2 läuft. Daher ist dieses Protokoll auch sehr robust und leistungsfähig. Da man die RAID-Gruppen immer direkt als LUN herausgibt, können diese nicht weiter von der Größe unterteilt werden. Dies bedeutet, dass Sie bei acht 1-TBSATA-Festplatten im RAID 5 knapp 7 TB Nutzkapazität erreichen. Der ESX-Server kann damit nicht umgehen, da er nur 1,99 TB verwalten kann. Daher dient die AoE-Karte auch dazu, die erkannten LUNs immer gleich in 1,99-TB-Happen für den ESX-Server zu teilen. URL http://www.coraid.com/site/co-pdfs/EtherDriveBestPractices.pdf
10.1.3 EMC EMC ist natürlich einer der ganz Großen im Storage-Markt und bietet mehrere Produktreihen, die sich vom SMB-Markt bis zum High-End-Enterprise-Markt erstrecken. Da EMC ausgezeichnete und sehr umfangreiche Dokumente zu den Storage-Systemen und zur korrekten Konfiguration im VMware-Umfeld online bereitstellt, geht dieser Abschnitt nur oberflächlich auf die EMC-Produkte ein. Allerdings finden Sie viele Links zu den Technologie-Dokumenten. Außerdem kann jedem EMC bzw. sogar Storage/VMware Nutzer nur der sehr gute Blog von Chad Sakac ans Herz gelegt werden: http://virtualgeek.typepad.com Fangen wir mit den NAS-Storage-Systemen an, so finden wir die reine NASLösung Celerra und die Mischlösung NS, die eine Kombination aus CLARiiON und Celerra ist und NAS/SAN vereint. CLARiiON ist die iSCSI-/FC-Lösung, die mit der AX im Low-End unterwegs ist und mit der CX bis in den gehobenen Mittelstand reicht. Derzeit ist die CX in der vierten Generation mit Funktionen wie Snapshots, Snapshot-Clones und Thin Provisioning (Virtual Provisioning) verfügbar. Als Festplatten sind SATA-, FC- und SSD-Laufwerke nutzbar. Zur Replikation dient das Produkt Mirrorview. Nähere Informationen zur CX-4 bietet der Hersteller hier: http://germany.emc.com/collateral/hardware/data-sheet/h5527-emc-clariioncx4-ds.pdf
532
Storage-Produkte
CLARiiON Es existiert unter vSphere 4, auch mit Update 1, ein sehr unschöner Bug bei der Nutzung von Round Robin, wenn die Rate der Pfadwechsel von 1000 IOs (Standard) auf 1 heruntergesetzt wird. In diesem Fall wird aus dem Wert 1 nach dem Neustart des ESX Hosts ein Zufallswert, welcher zu einem negativen Lastverhalten führt. Daher sollte bis zur Beseitigung dieses Bugs der Standardwert 1000 belassen werden. 왘
Genauere Informationen finden Sie hier: http://virtualgeek.typepad.com/virtual_geek/2009/11/ vsphere-update-1-and-other-friday-goodies.html http://virtualgeek.typepad.com/virtual_geek/2009/12/ vsphere-4-nmp-rr-iooperationslimit-bug-and-workaround.html
왘
Weitere CLARiiON Links: http://www.emc.com/collateral/hardware/white-papers/ h1416-emc-clariion-intgtn-vmware-wp.pdf http://virtualoasis.typepad.com/files/ esx_hostconnectivity_dmx_cx_072009.pdf http://virtualoasis.typepad.com/files/esx_clariion_bible.pdf
Celerra http://www.emc.com/collateral/hardware/white-papers/ h6337-introduction-using-celerra-vmware-vsphere-wp.pdf http://virtualoasis.typepad.com/files/esx_celerra_bible.pdf Symmetrix Im Enterprise-Segment liegt die EMC Symmetrix, die als DMX in Generation 4 verfügbar ist. Außerdem existiert eine weitere High-End-Lösung namens V-MAX, eine DMX in Grid-Architektur. Die Replikation bei der Symmetrix-Nutzung läuft nicht über Mirrorview, sondern über SRDF (Symmetrix Remote Data Facility). Bei der Nutzung von EMC DMX Systemen ist unter vSphere 4 das SPC-2 Bit zu beachten. Wird es nicht aktiviert, so kommt es zu Fehlermeldungen während der Nutzung der LUN (z. B. Probleme beim Anlegen des VMFS Datastore), da keine korrekte NAA berechnet wird. Eine gute Anzeige des SPC-2 Bit wird durch den EMC Storage Viewer für vSphere gewährleistet. Es wird empfohlen, folgendes Dokument beim Betrieb von vSphere auf EMC DMX zu beachten:
533
10.1
10
Hersteller-Best-Practices
EMC PowerLink: H4116-enabling-spc2-compl-emc-symmetrix-dmx-vmwareenvn mt-wp.pdf http://www.emc.com/collateral/hardware/white-papers/ h6531-using-vmware-vsphere-with-emc-symmetrix-wp.pdf http://www.emc.com/collateral/hardware/solution-overview/ h2529-vmware-esx-svr-w-symmetrix-wp-ldv.pdf http://virtualoasis.typepad.com/files/esx_dmx_integration-bible.pdf PowerPath/VE EMC hat als erster Storage-Hersteller seine Multipathing-Software PowerPath/VE für vSphere veröffentlicht, die sich direkt als Third-Party-Modul ins VMwareMultipathing integriert. PowerPath/VE wird über die Remote CLI installiert und ersetzt die VMware-Multipathing-Policies. Durch PowerPath/VE ist es möglich, die CX-Systeme über die optimalen Pfade anzubinden, um optimale Leistung zu erhalten. EMC hat einen Best Practice Guide für PowerPath/VE für vSphere veröffentlicht: http://www.emc.com/collateral/software/white-papers/ h6340-powerpath-ve-for-vmware-vsphere-wp.pdf http://www.emc.com/collateral/software/white-papers/ h6533-performance-optimization-vmware-powerpath-ve-wp.pdf
10.1.4 Hitachi Data Systems Hitachi Data Systems (HDS) führt zwei verschiedene Storage-Typen im Sortiment: AMS (Adaptable Modular Storage) und USP (Universal Storage Platform). Während die AMS im Mittelstand sehr beliebt und geschätzt ist, sind die Typen USP-V und USP-VM eher im gehobenen Mittelstand und vor allem im EnterpriseSegment zu finden. AMS 2000 Die AMS 2000 bietet vielfältige Möglichkeiten, das System auszubauen, mit FC oder iSCSI zu verbinden und entsprechende RAID-Sets (6, 5, 1, 0, 1+0) anzulegen. An Festplattentypen können Sie SATA-II mit SAS verwenden und miteinander mischen. Die Verwaltung erfolgt über das Webinterface HDS Storage Navigator Modular (Abbildung 10.11).
534
Storage-Produkte
Abbildung 10.11
Webinterface HDS Storage Navigator Modular
Ein absolutes Highlight dieses Systems ist aber definitiv die vollwertige active/ active-Unterstützung, was in diesem Preissegment zur Drucklegung des Buches einmalig ist. Vor allem im VMware-Umfeld ist dies sehr von Vorteil, da alle Pfade gleich schnell sind und Sie damit auch ein Round-Robin problemlos einrichten können.
ESX
0
ESX
1
0
Fabric 1
0
1
0
1
Fabric 2
1
EMC CX
Abbildung 10.12
0
1
0
1
HDS AMS
HDS-Dynamic-Load-Balancing-Controller-Architektur im Vergleich
535
10.1
10
Hersteller-Best-Practices
Durch die Dynamic-Load-Balancing-Controller-Architektur von Hitachi (Abbildung 10.12) ergeben sich auch Vereinfachungen bei der Controller-Zuordnung und -verkabelung, was zu weniger Fehleranfälligkeit führt. Außerdem werden die Storage-Prozessoren und -Controller durch das Load-Balancing gleichmäßig belastet, was die Effizienz und Leistungsfähigkeit deutlich erhöht. Snapshots werden nach dem Copy-on-Write-Verfahren durchgeführt und können sowohl kopiert als auch direkt zusätzlich zur Original-LUN dem ESX-Host bereitgestellt werden.
LUN0 LUN1 LUN2 LUN3 HD0
HD1
HD2
HD3
HD4
HD5
HD6
HD7
HD4
HD5
HD6
HD7
LUN0 LUN1 LUN2 LUN3
HD0
HD1
HD2
HD3
Abbildung 10.13 Automatische Neuverteilung der LUNs auf die zusätzlichen Platten der vergrößerten RAID-Gruppe
Sie können LUNs vergrößern und verkleinern, wobei das Vergrößern im laufenden Betrieb stattfinden kann (Abbildung 10.13). Darüber hinaus ist es möglich, RAID-Gruppen im laufenden Betrieb zu vergrößern, d. h. zusätzliche Festplatten der RAID-Gruppe hinzuzufügen. Dabei können Sie bestimmen, ob dieser Vorgang länger dauern soll oder ob mehr Leistung der Controller abgezogen werden soll. Nach der RAID-Vergrößerung werden alle LUNs automatisch über die zusätzlichen Festplatten verteilt. Möchten Sie maximale Leistungsfähigkeit, so können Sie mit sogenannten MegaLUNs (Abbildung 10.14) arbeiten, das heißt, eine LUN wird über viele RAIDGruppen verteilt, um alle Festplatten zu nutzen.
536
Storage-Produkte
LUN A
LUN A
LUN A
LUN A
LUN A
Abbildung 10.14
HDS-Mega-LUNs zum Verteilen von LUNs über mehrere RAID-Gruppen
Gerade in VMware-Umgebungen ist es aufgrund des hohen Random-I/O-Anteils schwierig, Cachetreffer zu landen. HDS arbeitet beim Caching mit einer anpassbaren Segmentgröße, der Cache wird also nicht in 128-KB-Blöcke aufgeteilt, sondern an den ankommenden Datenstrom angepasst. So existieren beispielsweise Regionen mit 4 KB, 16 KB und 64 KB, wodurch die möglichen Cachetreffer aus den entsprechenden Anwendungen deutlich erhöht werden. Jeder Cachetreffer führt natürlich zu wesentlichem Leistungszuwachs, da in diesem Fall nicht auf die langsameren Festplatten zugegriffen werden muss. USP Die beiden Systeme USP-V und USP-VM siedeln sich im Mid-Range- und HighEnd-Bereich an und werden von HP auch für die XP-Reihe lizenziert. Selbstverständlich ist die USP ein vollwertiges active/active-System und steht in Konkurrenz zu EMC Symmetrix, der IBM-8000-Familie und 3PAR. Dementsprechend ist der Funktionsumfang enorm und auf sehr leistungshungrige Umgebungen ausgelegt und ist mandantenfähig. Die USP unterstützt Copy-on-Write-Snapshots, die bei Änderung des OriginalVolumes wachsen, da dessen Ursprungsdaten kopiert werden müssen.
537
10.1
10
Hersteller-Best-Practices
Abbildung 10.15 Aufbau von HDS USP-V als mandantenfähige Lösung (Quelle: hitachiuniversal-storage-platform-family-architecture-guide.pdf)
Mittels Hitachi TrueCopy ist eine controller-basierte synchrone oder asynchrone Replikation möglich und mittels Hitachi ShadowImage auch eine Replikation zwischen heterogenen Systemen. Eine Besonderheit mit Thin Provisioning ist die ZPR-(Zero Page Reclaim-)Funktion, die geschriebene Nullen im Dateisystem auf Blockebene wieder freigibt. Diese Funktion ist allerdings manuell zu starten und wird nicht automatisiert durchgeführt. Thin Provisioning wird im HDS-Jargon übrigens »Dynamic Provisioning« genannt.
538
Storage-Produkte
Neben der »reinen« Storage-Funktion unterstützt die USP-V auch die Möglichkeit, Storage von Drittherstellern über eine Virtualisierungsfunktion im Backend anzuschließen, während das Frontend nach wie vor den Storage über die USP-V erhält. URLs http://www.hds.com/assets/pdf/hitachi-ams-2000.pdf http://www.hds.com/assets/pdf/hitachi-adaptable-modular-storage-2000-familybest-practices-for-vmware-virtual-infrastructure-wp.pdf Sehr empfehlenswerte Whitepapers zum Betrieb von MS Exchange unter vSphere: http://www.hds.com/assets/pdf/hitachi-adaptable-modular-storage-2500-bestpractices-guide-deployment-guide.pdf http://www.hds.com/assets/pdf/hitachi-adaptable-modular-storage-2500-bestpractices-guide.pdf
10.1.5 HP HP führt drei verschiedene Storage-Typen im Sortiment: MSA, EVA und XPSerie, auf die wir im Folgenden kurz eingehen. MSA (Modular Smart Array) Das MSA ist eher für kleinere Arbeitsgruppen und VMware-Infrastrukturen gedacht. Im Normalfall können Sie mit etwa 20–30 VMs auf einem MSA planen. Dies hat weniger mit der Limitierung der Anzahl der Festplatten auf 60 zu tun, sondern eher mit der Anzahl der Controller. Das MSA kann iSCSI- oder FC-fähig sein und bietet grundlegende Storage-Funktionen. Eine aktuelle Limitierung zur Drucklegung des Buches ist die fehlende Unterstützung bei Emulex-HBAs, wenn Brocade-Switches eingesetzt werden. Außerdem wird das HP MSA als Direct-attached Shared Storage für VMware vSphere bei maximal zwei ESX-Hosts unterstützt. Die Verwendung von Snapshots muss getrennt lizenziert werden, und Sie müssen bereits bei der Anlage der LUNs planen, ob Sie Snapshots nutzen möchten oder nicht. Die Snapshots werden mittels Copy-on-Write-Technik erstellt. Um Snapshots zur Wiederherstellung verlorener Daten zu nutzen, müssen Sie sie per Cloning doppeln und dem ESX-Host zur Verfügung stellen, um z. B. eine einzelne vmdk-Datei wiederherzustellen.
539
10.1
10
Hersteller-Best-Practices
Als Replikationslösung zwischen den aktuellen MSA2000-Systemen können Sie das Produkt Storage Mirroring einsetzen. EVA (Enterprise Virtual Array) Die EVA-Reihe ist im Mid-Range-Segment anzusiedeln, und Sie können je nach Festplattenanzahl und Storage-Typ mehrere Hundert VMs betreiben. Während die älteren Modelle 3000 und 5000 active/passive-Systeme waren, sind die neueren asymmetric-active/active-fähig. Dadurch können zwar alle Pfade gleichzeitig zum Zugriff auf eine LUN genutzt werden, allerdings sind nur die Pfade des LUN-Eigners zum Zugriff mit voller Geschwindigkeit optimiert. Alle Pfade des zweiten Controllers müssen immer einen Umweg über den der LUN zugeordneten Controller machen, was teilweise zu deutlichen Leistungseinbußen führt. Dank der ALUA-Unterstützung von vSphere wird dieses Problem allerdings sehr gut umgangen, in dem die optimalen Pfade immer bevorzugt genutzt werden. Multipathing Ist active/active konfiguriert, wird als Multipathing-Policy zwar Fixed empfohlen, allerdings haben sich zwei andere Konfigurationen als sinnvoll erwiesen. Durch die Nutzung von ALUA kann der ESX-Host bei Round-Robin (RR) und MRU die optimalen von den nicht-optimalen Pfaden unterscheiden. Daher können Sie Round-Robin auch beim HP-EVA wählen, da RR immer den optimalen Pfad wählt und nur im Ausfall umschaltet. Falls Sie kein RR nutzen wollen, ist MRU aufgrund der ALUA-Unterstützung der bessere Weg. Ist das EVA active/passive konfiguriert, sollte Ihre Wahl immer auf MRU fallen. Nutzen Sie beim Betrieb des EVA Fixed Multipathing, ist ALUA zur Auswahl der optimalen Pfade nicht mehr aktiv, und Sie müssen sich als Administrator selbständig um die richtigen Zuordnungen kümmern. Beim Betrieb des EVA ohne ALUA (Fixed) ist es äußerst wichtig, auf die richtige Reihenfolge beim Multipathing zu achten. Es ist generell immer nur ein Controller LUN-Eigner, daher sind je nach EVA-Modell entweder zwei oder vier Ports optimiert, je nachdem, wie viele Ports auf einem Controller aktiv sind. HP empfiehlt, Round-Robin so zu konfigurieren, dass nach jedem I/O der Pfad gewechselt wird, allerdings sollten Sie immer mit dem Standard von 1000 beginnen und nicht unnötig an den Standardeinstellungen drehen. Um RR zu konfigurieren führen Sie den Befehl esxcli aus, entweder auf der Service Console oder im Remote CLI: esxcli nmp roundrobin setconfig --device=naa.## --iops 1 --type iops
540
Storage-Produkte
Um die NAA-Adressen der LUNs und die Werte auszulesen, benötigen Sie folgende Befehle: esxcfg-mpath -l esxcli nmp roundrobin getconfig --device=naa.##
Remote CLI: esxcli --server=ESXIP nmp roundrobin setconfig --device=naa.## --iops 1--type iops
LUN-Erkennung im ESX-Server Um die LUNs der HP EVA sehr schnell den Volumes im VMware ESX 4-Server zuzuordnen, empfiehlt sich der Vergleich der UUID in den Eigenschaften der Vdisk (Abbildung 10.16) mit dem hinteren Teil der NAA-Adresse des ESX-Volumes.
Abbildung 10.16
HP EVA: Eigenschaften des Volumes – UUID
vRAID Eine Besonderheit des EVA ist die Verteilung der RAID-Gruppen über die Festplatten, da keine physischen, sondern virtuelle RAID-Gruppen (Abbildung 10.18) genutzt werden. Diese verwenden nur Teile der physischen Festplatten, um RAID-Sets mit vorgegebener Größe über die vorgegebene Plattenanzahl zu verteilen. Dies bringt den Vorteil, dass Sie bei der RAID-Größe nicht auf die physi-
541
10.1
10
Hersteller-Best-Practices
1
2
3
5
6
SAN7 Frontend
Spare
LUN 7 LUN 6
4
LUN 4
LUN 5
Spare
LUN 1 LUN 2
LUN 3
Abbildung 10.17 Traditionelle Storage-Verteilung – Anlage von RAID-Gruppen auf kompletten Festplatten und LUNs im Backend und Präsentieren zu den Hosts im Frontend
schen Platten angewiesen sind und die Leistung durch die Nutzung aller Festplatten im Pool optimiert wird. Dies gilt übrigens auch für die Spare-Disks, die nicht als physische gesonderte Festplatten vorgehalten, sondern als Spare-Kapazität auf den vRAID-Platten definiert werden.
SAN-Frontend
1
2
3
300 GB
200 GB
150 GB
LUN2
LUN3
LUN1
Abbildung 10.18
HP EVA: vRAID-Verteilung
Warnung: Leistungsengpässe! Während der normalen Tageszeiten sollten Sie nie neue Festplatten einer EVA-DiskGroup hinzufügen, da es aufgrund der Neuanordnung der Daten (Levelling) zu deutlichen Leistungsengpässen kommt. Das Gleiche gilt für ausgefallene Festplatten, die beim Levelling auch zu einer Neuanordnung der Daten führen. Sehr wichtig ist es auch, zu bedenken, dass Sie diesen Levelling-Vorgang nicht mehr stoppen können, nachdem er gestartet wurde.
542
Storage-Produkte
Durch die Verteilung der Daten über die Festplatten innerhalb des vRAID können Sie erhebliche Leistungsverbesserungen erreichen, weswegen das EVA im Mittelstand auch beliebt und bekannt ist. Wer derzeit noch nicht zu vSphere gewechselt ist, kann übrigens von der französischen Firma Antemeta ein vCenter 2.5-Plug-in für die EVA-Integration käuflich erwerben, das auf der EVA Command View basiert: http://www.antemeta.fr/ pages/plug_in_vmware.php URLs:
http://www.clusterfunk.co.uk/crib-sheet-on-eva/ XP Die XP-Reihe ist für Enterprise-Umgebungen gedacht und ist ein angepasster Hitachi-Storage (XP24000 = HDS USP V; XP20000 = HDS USP VM). Die XP-Systeme eignen sich für größere Mid-Range- und High-End-Infrastrukturen.
10.1.6 IBM Auch IBM hat natürlich Storage-Systeme von Low-End bis High-End im Programm, genauer von der 4000er-Familie über die 6000er-Reihe bis zum Enterprise-Storage, der 8000er-Reihe. Derzeit sind noch keine Best-Practice-Dokumente oder Red Books für vSphere zu den IBM-Storage-Systemen öffentlich verfügbar. Die 4000/6000/8000er-Familien sind reine SAN-Storage-Systeme, allerdings bietet IBM zusätzlich ein NAS-System, die N-Series. Allerdings handelt es sich bei der N-Series um NetApp-Filer, daher können Sie neben den IBM-Red-Books auch die NetApp-Dokumente nutzen, welche für vSphere bereits existieren. IBM-Red-Book zum Thema IBM N-Series (NetApp) und VMware ESX-Server: http://www.redbooks.ibm.com/redbooks/pdfs/sg247636.pdf Red Book zu IBM XIV: http://www.redbooks.ibm.com/redbooks/pdfs/sg247659.pdf
10.1.7 Dell EqualLogic PS-Serie An dieser Stelle möchten wir uns ganz herzlich bei Bernd Morbach bedanken, der den folgenden sehr umfangreichen und interessanten Abschnitt zum Buch beigesteuert hat.
543
10.1
Hersteller-Best-Practices
Bernd Morbach ist ein alter Hase in der IT und verfügt über enorme Erfahrung im Storage-Umfeld. Er hat 2008 das Beratungsunternehmen GreyFrog (www.greyfrog.eu) gegründet und berät Kunden im VMware- und StorageUmfeld. Storage-Virtualisierung mit der Dell EqualLogic PS-Serie Ansätze zur Virtualisierung von Storage gibt es am Markt in vielfältiger Form. In diesem Abschnitt wird der Ansatz der Firma EqualLogic erläutert, die Anfang 2008 von Dell übernommen wurde und deren Produkte seitdem als die Dell EqualLogic PS-Serie angeboten werden, der Einfachheit halber hier nur PS-Serie genannt. Klassische Storage-Systeme folgen meist einem ähnlichen Aufbau: Es gibt ein Backend bestehend aus den Platten des Storage-Systems mit geeigneten I/OAnbindungswegen, wie Bussen, Ringen oder einer Switch-Architektur. Im Frontend arbeiten ein oder mehrere Controller, die jeweils über eine eigene CPU, einen eigenen Cache und ein oder mehrere Frontend-Ports verfügen.
Frontend
Controller
CPU
Controller
Cache
CPU
Cache
Backend
10
Platten Abbildung 10.19
Klassisches Storage-Array
Die Controller bauen auf den physischen Platten des Backends logische Platten, die dann am Frontend über die Controller-Ports an Storage-Verbraucher präsentiert werden. Aus Performance-Gründen wird der I/O mit dem Verbraucher zuerst im Cache der Controller gepuffert und später auf das Backend geschrieben.
544
Storage-Produkte
Für die eigentlichen Verbraucher ist dies transparent, sie sehen schlichtweg eine Platte. Bei Storage-Systemen für Rechenzentren gehört es daneben einfach dazu, dass Ausfälle einzelner Komponenten intern kompensiert werden können. Dazu gehört ebenso der Einsatz von RAID-Technologie zur Kompensation von Plattenausfällen und die Redundanz der I/O-Wege mit redundanter Anbindung aller Controller wie auch die Spiegelung der Controller-Caches untereinander. Die Caches selbst müssen durch Batteriepufferung gegen Stromausfälle gesichert sein. Das Problem dieses klassischen Ansatzes besteht darin, dass die feste Anzahl bestimmter Komponenten die Ausbaufähigkeit des Systems beschränkt. Kleine Systeme sind preisgünstig zu erwerben, bieten dafür aber nur beschränkte Ausbauvarianten. Große Systeme können eine große Investition bedeuten, insbesondere dann, wenn Sie zuerst mit einer kleinen Ausbaustufe beginnen möchten, aber den Einstiegspreis des großen Systems gleich aufbringen müssen. Müssen Sie deshalb später Chassis tauschen, schafft dies Probleme bei der Migration der Daten, und eventuell müssen Sie auch neben der reinen Hardware wieder neue Lizenzen für Storage-Funktionen beschaffen, da diese nicht mit umziehen können oder dürfen. Forschungsinstitute setzen schon seit langem auf Grid-Technologien gesetzt. Die Grundidee dabei besteht darin, ein Netzwerk aus vielen preiswerten Standardkomponenten aufzubauen. Jede Komponente bietet ihre Funktionen im Netzwerk an, und Grid-Broker verteilen Anwendungslasten auf die einzelnen Komponenten, wenn diese freie Kapazitäten im Grid melden. Vielleicht haben Sie schon vom Projekt Seti@Home der Universität Berkeley gehört, bei dem nach diesem Prinzip weltweit Tausende Computer bei Privatpersonen und auch in Firmen freie Rechenleistung bereitstellen, um nach Zeichen von Intelligenz außerhalb unseres Sonnensystems zu suchen. Das Storage-Grid der PS-Serie arbeitet nach einem ähnlichen Prinzip, wenn auch mit wesentlich weniger einzelnen Systemen. Die PS-Serie ist ein logischer Verbund von gleichartigen einzelnen Storage-Systemen. Dabei ist jedes einzelne System ein eigenständiges Storage-Array bestehend aus einem Chassis mit jeweils 16 oder 48 Platten und zwei Controllern. Die Chassis sind homogen mit SATA- oder SAS-Platten bestückt. Die Controller versorgen die Platten einheitlich mit einem RAID-Level pro Chassis und bieten am Frontend jeweils drei oder vier Ports zur Präsentation logischer Platten an Verbraucher. Daneben verfügt das Chassis über zwei Stromversorgungs- und Lüftergruppen.
545
10.1
10
Hersteller-Best-Practices
Gruppe Pool 2
Pool 1
Array 1
Array 2
Array 4 Pool 3
Array 3
Abbildung 10.20
Array 5
Dell EqualLogic Storage-Grid
Alle Komponenten eines Chassis (mit Ausnahme der Chassisrückwand) sind voll redundant ausgelegt, können Ausfälle kompensieren und im Betrieb getauscht werden. Die Controller laufen aktiv/passiv, das heißt, einer der beiden Controller übernimmt die I/Os zu den logischen Platten, der Zweite spiegelt dabei den Cache des aktiven Controllers und übernimmt bei Ausfall des aktiven Controllers. Innerhalb des logischen Verbundes gibt jedes Array seine RAID-Nettokapazität an einen logischen Container, genannt Pool, weiter. Ein Pool kann aus bis zu acht Arrays bestehen; er kumuliert damit seine eigene Poolkapazität aus der Summe der Einzelkapazitäten seiner Mitglieder. Der logische Verbund selbst ist primär eine administrative Einheit und wird Gruppe genannt. Eine Gruppe kann bis zu vier Pools umfassen. Der kleinste logische Verbund ist eine Gruppe mit einem Pool und nur einem Arraymitglied in diesem Pool. Logische Platten (Volumes) werden in diesem Verbund grundsätzlich aus Poolkapazitäten gebildet. Volumes bestehen dabei aus einer Menge von Seiten. Eine Seite ist die kleinste Storage-Kapazität, mit der die PS-Serie arbeitet. Eine Seite liegt immer auf einem einzelnen Storage-Array und ist dort über alle physischen Platten verteilt. Ein Volume ist lediglich eine Allokation von 1 Seite (kleinste Größe) bis zu 1 024 × 1 024 Seiten (größtes Volume).
546
Storage-Produkte
Besteht ein Pool nur aus einem Arraymitglied, liegen alle Seiten eines Volumes auf diesem Array. Umfasst der Pool aber mehrere Mitglieder, werden die Seiten des Volumes über die Poolmitglieder anteilig Ihrer Kapazitäten verteilt, es werden also I/O-Aufträge automatisch auf mehrere einzelne Arrays gesplittet. Dadurch lassen sich Kapazität und Leistung des Gesamtsystems durch Hinzufügen weiterer Einzelarrays praktisch linear steigern. Daneben ist die Art der Speicherallokation ein Attribut des einzelnen Volumes. Standardmäßig wird die Verteilung über die Mitglieder eines Pools angewendet. Ein Administrator kann dies aber anpassen und z. B. auf ein bestimmtes RAIDLevel beschränken. Wird diese Verteilungsregel verändert, verwendet die Gruppe einen Paging-Algorithmus und verschiebt die einzelnen Seiten eines Volumes so lange auf andere Arrays, bis die neue Regel gültig ist. Ebenso können Volumes zwischen Pools verschoben werden. Damit ist eine ähnliche Loslösung von logischen Platten von der Physik vollzogen, wie sie bei VMware zwischen physischen ESX-Hosts und den virtuellen Maschinen erfolgt ist. Analog zum Verschieben von virtuellen Maschinen mittels VMotion können Sie bei der PS-Serie logische Volumes beliebig zwischen den physischen Arrays des Storage-Verbundes online verschieben. Um diese Leistung auch am Frontend fortsetzen zu können, muss das StorageProtokoll ein sehr flexibles Load-Balancing unterstützen. Aus diesem Grund baut das Design der PS-Serie ausschließlich auf dem iSCSI-SAN-Protokoll auf. Da jedes Array auf seinem aktiven Controller 3–4 Ports für Verbraucher bereithält, bedeutet dies die Verwendung von 3–4 IP-Adressen je Array. Die Gruppe selbst wird über eine virtuelle IP-Adresse repräsentiert und stellt die eigentliche Präsentationsschicht des logischen Verbundes zum Storage-Verbaucher hin dar. Ein Storage-Verbraucher wird die für ihn freigegebenen logischen Platten immer nur über eine Anfrage an die IP-Adresse der Gruppe finden. Die PS-Serie präsentiert dabei jedes Volume als ein eigenes Storage-Target mit der Logic Unit Number (LUN) 0. Nach dem iSCSI-Protokoll muss ein Storage-Verbraucher jetzt einen iSCSI-Log-in auf dieses Target machen, um eine iSCSI-Session aufzubauen und das Target verwenden zu können. Die virtuelle Gruppen-IP fungiert als Grid-Broker, nimmt die iSCSI-Log-in-Anfrage an und weist sie dann einem physischen gering ausgelasteten Frontend-Port zu. Das zu diesem Port gehörige Array führt dann den Log-in zu Ende und baut die iSCSI-Session auf. Falls der Storage-Verbraucher über mehr als nur einen SAN-
547
10.1
Storage-Produkte
Mit ESX 3.0 wurde die Unterstützung für iSCSI in die VMware Virtual Infrastructure eingeführt. Für die Anbindung eines ESX-Servers an ein iSCSI-Storage-Target können Sie unter VMware drei Methoden anwenden: Beim ersten Anschlussweg bauen Sie iSCSI-Host-Bus-Adapter (iSCSI-HBAs) im ESX-Server ein, die dann die iSCSI-Sessions aufbauen und damit den StorageZugang realisieren. Das entspricht der klassischen Anschlussmethode wie bei einem Fibre-Channel-Array. ESX-Server
VMkernel iSCSI Initiator
LUN LUN
iSCSI HBA
RDM
VM VM APP VM APP OS APP OS OS
Dell EqualLogic Group
iSCSI HBA
VMFS
VM VM APP VM APP OS APP OS OS
IP-Network
VMkernel iSCSI Initiator
LUN
LUN
VM APP
Software iSCSI Initiator
Abbildung 10.22
NIC OS NIC
LUN
LUN
VMware-iSCSI-Konnektivität
Daneben gibt es seit ESX 3.0 ein VMkernel-Modul, das einen iSCSI-Software-Initiator implementiert. Dieser Initiator baut die iSCSI-Verbindung dann über eine der normalen Netzwerkkarten auf. Da es sich bei iSCSI um ein SAN handelt, sollten Sie für diese Anschlussmethode einen eigenen vSwitch mit dedizierten Netzkarten für den Datenverkehr verwenden. iSCSI-Targets, die Sie über Hardware- oder Software-Initiatoren an einen ESXServer anbinden, können Sie dann wiederum mit VMFS-3 formatieren werden, was die Bereitstellung von vmdk-Dateien an virtuelle Maschinen ermöglicht. Alternativ reichen Sie einzelne iSCSI-SAN-LUNs auch direkt per Raw-DeviceMapping an virtuelle Maschinen weiter.
549
10.1
10
Hersteller-Best-Practices
Bei Verwendung eines Hardwareinitiators wird die I/O-Leistung vom HBA erbracht, beim Einsatz des VMkernel-Software-Initiators leistet der VMkernel diese Arbeit. Bei der dritten Anschlussmethode bleibt der ESX-Server selbst außen vor. Stattdessen wird in der virtuellen Maschine selbst ein iSCSI-Software-Initiator verwendet, der die Verbindung zum iSCSI-Storage direkt selbst aufbaut. Dazu richten Sie ebenfalls einen dedizierten vSwitch mit eigenen NICs für den iSCSIDatenverkehr ein und verbinden die virtuellen Maschinen über Port-Groups mit diesem SAN-vSwitch. Bis zu ESX 3.x waren SAN-Anbindungen (iSCSI wie Fibre-Channel) nur einpfadig möglich. Eine redundante Anbindung über mehrere HBAs war zwar möglich, allerdings nur in einer active/passive-Anbindung, das heißt, zu einer LUN hin wurde aktiv immer nur ein Pfad unterstützt. Eine mehrpfadige Anbindung mit Round-Robin-Verteilung war mit späten Updates zu ESX 3.5 experimentell verfügbar. Der VMkernel-iSCSI-Software-Initiator ließ bis ESX 3.5 keinerlei Redundanz zu. VMware vSphere und iSCSI-Multipathing mit dem VMkernel Mit ESX 4.0 wurde die Anschlussmöglichkeit von iSCSI-Storage wesentlich verbessert und stellt jetzt auch für die Hersteller von Storage-Arrays Schnittstellen bereit, um Funktionen der Storage-Hardware von ESX aus gezielt zu nutzen. Eine wesentliche Änderung besteht darin, dass Sie jetzt bis zu acht VMkerneliSCSI-Initiatoren verwenden können, um ein iSCSI-Target anzubinden. Dann können diese Software-Initiatoren dazu dienen, active/active-Multipathing zum iSCSI-Target herzustellen. Damit kann der Software-Initiator mehr Pfade und Bandbreite anbinden, als dies mit iSCSI-HBAs möglich ist. Er ist dadurch eine echte Alternative zur Verwendung von Hardware-Initiatoren. Zudem schließt iSCSI dadurch zu einer vollwertigen Alternative gegenüber Fibre-Channel auf. Das folgende Beispiel demonstriert die mehrpfadige Anbindung eines ESX 4.0Servers an ein Dell-EqualLogic-Array. Das Einrichten der Storage-Anbindung wird auf Basis des CLI dargestellt. Hinweis Da die PS-Serie sich über die Gruppen-IP darstellt und beim Session-Aufbau ein iSCSI-Redirect auf einen physischen Arrayport erfolgt, müssen die Gruppen-IP sowie die IPs aller physischen Ports für alle ESX-Server-Ports eines Clusters ständig sichtbar und erreichbar sein. Bei einer redundanten Anbindung über zwei Netzwerk-Switches bedingt dies auch die Anbindung der Switches untereinander über einen InterswitchLink (ISL) oder Switch-Stacking.
550
Storage-Produkte
Für dieses Beispiel wurde eine Dell-EqualLogic-Gruppe mit einem Pool und einem Array in diesem Pool genutzt. Der verwendete ESX-Server verfügt über zwei Dual-Port-Gigabit-Karten, von denen drei Ports für den Storage-Zugang verwendet werden. NIC vmnic0 wird für die Service Console genutzt, für die Storage-Anbindung verbleiben damit die Karten vmnic1, vmnic2 und vmnic3. esxcfg-vswitch -a iscsi esxcfg-vswitch –m 9000 iscsi
Abbildung 10.23
SAN-vSwitch wurde erzeugt.
Zuerst erzeugen wir den SAN-vSwitch. Seit ESX 4.0 kann der VMkernel mit einer höheren Paketgröße für iSCSI konfiguriert werden. Wir verwenden daher Jumbo-Frames (MTU 9.000). Diese Einstellung ist nur über das CLI möglich. Jetzt fügen wir drei Portgruppen für die drei VMkernel-iSCSI-Initiatoren hinzu und für jede Portgruppe jeweils einen VMkernel. Das VMkernel-Modul statten wir jeweils mit einer IP-Adresse und der korrekten Netzmaske des iSCSI-SANNetzwerks aus. Auch beim VMkernel konfigurieren wir die Verwendung von Jumbo-Frames: esxcfg-vswitch -A iscsi-1 iscsi esxcfg-vmknic -a -i 192.168.1.150 -n 255.255.255.0 -m 9000 iscsi-1 esxcfg-vswitch -A iscsi-2 iscsi esxcfg-vmknic -a -i 192.168.1.151 -n 255.255.255.0 -m 9000 iscsi-2 esxcfg-vswitch -A iscsi-3 iscsi esxcfg-vmknic -a -i 192.168.1.152 -n 255.255.255.0 -m 9000 iscsi-3
Abbildung 10.24
vSwitch nach Hinzufügen der VMkernels
551
10.1
10
Hersteller-Best-Practices
Nun müssen wir die drei Netzkarten zum vSwitch hinzufügen. Normalerweise würde man die Karten über NIC-Teaming einrichten. Da die VMkernels aber ohnehin für Multipathing eingerichtet werden, ist das nicht gewünscht. Daher weisen wir sinnvollerweise jedem VMkernel nur eine Netzkarte zu. Um dies zu erreichen, fügen wir die Karten zunächst dem vSwitch hinzu. Danach hat jede Port-Group am vSwitch Zugang zu allen Netzkarten. Dann entfernen wir die nicht benötigten Netzkarten von den jeweiligen Port-Groups. Hinzufügen der Netzkarten zum vSwitch: esxcfg-vswitch -L vmnic1 iscsi esxcfg-vswitch -L vmnic2 iscsi esxcfg-vswitch -L vmnic3 iscsi
Entfernen der unerwünschten Netzwerkkarten von den VMkernel-Port-Groups: esxcfg-vswitch -p iscsi-1 -N vmnic2 iscsi esxcfg-vswitch -p iscsi-1 -N vmnic3 iscsi esxcfg-vswitch -p iscsi-2 -N vmnic1 iscsi esxcfg-vswitch -p iscsi-2 -N vmnic3 iscsi esxcfg-vswitch -p iscsi-3 -N vmnic1 iscsi esxcfg-vswitch -p iscsi-3 -N vmnic2 iscsi
Ergebniskontrolle: esxcfg-vswitch -l Switch Name Num Ports Used Ports Configured Ports iscsi 64 7 64 PortGroup Name VLAN ID Used Ports Uplinks iscsi-3 0 1 vmnic3 iscsi-2 0 1 vmnic2 iscsi-1 0 1 vmnic1
Abbildung 10.25
552
vSwitch mit port-group-assoziierten NICs
MTU 9000
Uplinks vmnic3,vmnic2,vmnic1
Storage-Produkte
10.1
Um iSCSI mit dem VMkernel-Port verwenden zu können, aktivieren wir jetzt den ESX-Software-Initiator: esxcfg-swiscsi -e Enabling software iSCSI... Module iscsi_vmk loaded successfully
Damit die verschiedenen VMkernel-Ports tatsächlich für Multipathing genutzt werden können, müssen wir sie mit dem jetzt laufenden iSCSI-Modul verbinden. Dazu ermitteln wir zuerst den Gerätenamen des iSCSI-Software-Initiators. Anschließend kann die Bindung der VMkernels an dieses Gerät erfolgen. Der Gerätename ist mit dem Kernel-Modul iscsi_vmk assoziiert. In unserem Fall ermitteln wir den Gerätenamen vmhba33. esxcfg-scsidevs -a vmhba0 aic79xx link-n/a pscsi.vmhba0 (4:2.0) Adaptec AIC-8902 U320 OEM vmhba1 aic79xx link-n/a pscsi.vmhba1 (4:2.1) Adaptec AIC-8902 U320 OEM vmhba2 ata_piix link-n/a ide.vmhba2 (0:31.1) Intel Corporation 631xESB/632xESB IDE Controller vmhba32 ata_piix link-n/a ide.vmhba32 (0:31.1) Intel Corporation 631xESB/632xESB IDE Controller vmhba33 iscsi_vmk link-n/a iscsi.vmhba33 () Software iSCSI
Für die jetzt folgende Bindung an den iSCSI-Software-Initiator müssen Sie die korrekten Namen der VMkernel Module beachten, am besten sie rufen Sie im CLI mit esxcfg-vmknic -l ab, oder vergewissern sich in der GUI. In unserem Fall handelt es sich um vmk0, vmk1 und vmk2. esxcfg-vmknic -l Interface Port Group/DVPort IP Family IP Address MAC Address MTU TSO MSS Enabled Type vmk0 iscsi-1 IPv4 192.168.1.150 00:50:56:75:5a:4a 9000 65535 true STATIC vmk1 iscsi-2 IPv4 192.168.1.151 00:50:56:71:db:65 9000 65535 true STATIC vmk2 iscsi-3 IPv4 192.168.1.152 00:50:56:7e:f2:41 9000 65535 true STATIC
Netmask
Broadcast
255.255.255.0
192.168.1.255
255.255.255.0
192.168.1.255
255.255.255.0
192.168.1.255
Die eigentliche Bindung kann nur über das CLI erfolgen, was auch der Grund dafür ist, dass diese Beschreibung sich mehr auf das CLI bezieht. vmkiscsi-tool -V -a vmk0 vmhba33 Adding NIC vmk0 ... Added successfully.
553
10
Hersteller-Best-Practices
vmkiscsi-tool -V -a vmk1 vmhba33 Adding NIC vmk1 ... Added successfully. vmkiscsi-tool -V -a vmk2 vmhba33 Adding NIC vmk2 ... Added successfully.
Abschließend können Sie mit vmkiscsi-tool -V -l vmhba33 (setzen Sie den korrekten Gerätenamen bei vmhba für Ihre Umgebung ein) überprüfen, ob Sie die korrekte Bindung hergestellt haben und ob alle VMkernels korrekt konfiguriert sind. Durch die Verwendung des iSCSI-Multipathings mit der PS-Serie ist das Array jetzt in der Lage, die vom ESX-Server eingehende Last optimal zu verteilen. Auch das soll jetzt demonstriert werden. Dazu erzeugen Sie auf einer PS-Serien-Gruppe ein Volume und präsentieren es dem ESX 4.0-Server. Damit ein mehrpfadiger Zugriff möglich ist, müssen Sie für jeden VMkernel-Port den Zugang auf das Volume erlauben. Dazu könnten Sie für jede der in den VMkernels verwendeten IP-Adressen eine Access-Control-Regel in der PS-Serie definieren. Da aber alle VMkernels den gleichen iSCSI-SoftwareInitiator verwenden, machen wir uns das Leben leicht und authentifizieren die VMkernel über die IQN dieses Initiators. Die IQN finden Sie in der GUI unter ESX-Server 폷 Konfiguration 폷 Speicheradapter 폷 iSCSI Software Adapter.
Abbildung 10.26
Ermitteln der IQN des iSCSI-Software-Adapters
Im CLI erreichen Sie die IQN mit: vmkiscsi-tool -I -l vmhba33 iSCSI Node Name: iqn.1998-01.com.vmware:bilbo-0c445bbc
Zum Erzeugen des Volumes in der PS-Serie verwenden Sie die GUI oder das CLI. Der Einfachheit halber zeigen wir kurz das Einrichten eines Volumes über das CLI:
554
Storage-Produkte
volume create vsphere 50g volume select vshpere access create initiator iqn.199801.com.vmware:bilbo-0c445bbc
Um den Zugriff auf dieses Volume im ESX-Server zu ermöglichen, tragen Sie das Storage-Gerät beim iSCSI-Initiator ein. Dies zeigen wir über die GUI:
Abbildung 10.27
Properties iSCSI Software Adapter
Wählen Sie ESX-Server 폷 Konfiguration 폷 Speicheradapter 폷 iSCSI Software Adapter 폷 Eigenschaften aus. Dort tragen Sie im Reiter Dynamische Erkennung die Gruppen IP-Adresse der PS-Serie ein.
Abbildung 10.28
Hinzufügen der PS-Serie als Storage-Target
555
10.1
10
Hersteller-Best-Practices
Anschließend fragt vCenter nach, ob es nach der Konfigurationsänderung nach neuen Speichergeräten scannen soll. Bestätigen Sie dies.
Abbildung 10.29
Scannen nach neuen iSCSI-Targets
Nach Abschluss des Scan-Vorgangs ist das neue Storage-Target als Gerät am iSCSISoftware-Initiator sichtbar.
Abbildung 10.30
Neue EqualLogic-Platte nach Scan
Die neue Platte verfügt bereits über einen mehrpfadigen Anschluss, allerdings gilt hier noch die Default-Einstellung nach einem ersten Scan. Dies bedeutet, dass nur ein Pfad aktiv genutzt wird und die anderen Pfade passiv sind. Mit einem rechten Mausklick auf die neue Platte können Sie dies ändern. Wählen Sie dazu die Option Pfade verwalten.
Abbildung 10.31
Pfadeinstellungen zum Storage-Target anpassen
Stellen Sie bei jedem Pfad die Option Round Robin ein, und achten Sie darauf, dass anschließend alle Pfade im Status Aktiv (I/O) sind.
556
Storage-Produkte
Abbildung 10.32
Active/active-Multipathing mit der PS-Serie
VMware und iSCSI-Multipathing aus der Windows-VM Neben der VMkernel-Implementierung ist Multipathing ebenfalls möglich, wenn die virtuelle Maschine selbst auf ein iSCSI-Target zugreift. Wie bereits im vorherigen Abschnitt unterstrichen, sollten Sie auch hier einen getrennten vSwitch für den SAN-Einsatz konfigurieren und mit dedizierten Netzkarten versehen. Dieser vSwitch wird dann über eigene Portgruppen an virtuelle Maschinen durchgereicht, die dann darüber direkt auf das iSCSI-SAN zugreifen können. Binden Sie die virtuelle Maschine mit mindestens zwei Netzkarten am SAN an, kann sie den mehrpfadigen Zugang selbst realisieren. Eine hervorragende Unterstützung für iSCSI-Multipathing aus einem Gastbetriebssystem gibt es auf den Microsoft-Server-Betriebssystemen. Microsoft unterstützt seit langem schon den Anschluss von iSCSI-Systemen und ermöglicht den 8-pfadigen Zugang zu einem Storage-Target. Ab Windows 2008 ist der iSCSI-Software-Initiator Standardbestandteil von Windows, vorher musste er nachinstalliert werden. Für den mehrpfadigen Anschluss von iSCSI-Targets gibt es grundsätzlich zwei Wege: Entweder öffnen Sie eine iSCSI-Session und fahren innerhalb dieser Ses-
557
10.1
10
Hersteller-Best-Practices
sion mehrere Verbindungen. Oder Sie öffnen mehrere iSCSI-Sessions, die jeweils nur über eine Verbindung verfügen. Die PS-Serie verwendet den zuletzt genannten Weg. Die Multipathing-Funktion ist Bestandteil des Microsoft-iSCSI-Initiators.
Abbildung 10.33
Aufbau mehrerer iSCSI-Sessions
Im iSCSI-Initiator geben Sie die Gruppen IP-Adresse als Storage-Target an. Anschließend sind PS-Series-Volumes, die für den betroffenen Server angelegt wurden, an diesem Server sichtbar (siehe Abbildung 10.34). Dann füllen Sie den Log-in-Dialog für diese Targets aus. Unter der Option Advanced beim iSCSI-Log-in spezifizieren Sie dann, über welche Netzkarte diese Session geöffnet werden soll. Analog führen Sie den Log-in für jede weitere zusätzliche Netzkarte durch, bis alle iSCSI-SAN-Pfade aufgebaut sind. Anschließend sind die verschiedenen Pfade mit Multipathing-Unterstützung über die Option Details sichtbar. Unter der Option Advanced im Reiter Devices können Sie dann die MPIO-Policy neu setzen. Für ein active/active-Array wie die PS-Serie ist Round Robin eine sinnvolle Option (siehe Abbildung 10.35).
558
Storage-Produkte
Abbildung 10.34
Setzen der Multipathing-Policy
Abbildung 10.35
Automatisches Multipathing mit dem Host Integration Toolkit
Der mehrfache Aufbau von iSCSI-Sessions mit Multipathing erlaubt es der PSSerie, die einzelnen Sessions über die physischen NICs der logischen Gruppe mit
559
10.1
10
Hersteller-Best-Practices
automatischem Load-Balancing zu verteilen. Dadurch lassen sich Bandbreite und I/O-Leistung dynamisch anpassen. Mit dem kostenlosen Host Integration Toolkit (HIT) bietet die PS-Serie eine umfangreiche Integration für die Windows Plattform. Dieses Werkzeug bietet u. a. das selbsttätige Erkennen mehrerer Netzzugänge zum SAN und eine automatische Konfiguration des Multipathings. Dabei können Sie im Werkzeug selbst einstellen, wie viele Pfade zu einem Target führen und wie viele Sessions zu einem einzelnen Array aufgebaut werden sollen. Der Microsoft-iSCSI-Initiator erlaubt Storage-Herstellern den Einsatz eines Device-specific Modules (DSM), um dem Initiator zusätzliche Intelligenz zu verleihen. Die PS-Serie nutzt dies aus, um Targets, die innerhalb der Gruppe über mehrere Arrays verteilt sind, automatisch mit dedizierten iSCSI-Sessions zu genau diesen Arrays zu versehen. Eine weitere Funktion dieses Toolkits, die nicht unerwähnt bleiben soll, ist die Unterstützung für Microsoft Volume Shadow Services (VSS). VSS ist eine Bibliothek in Windows-Server-Betriebssystemen, die es ermöglicht, anwendungskonsistente Hardware-Snapshots auf Storage-Ebene zu erzeugen. Durch die Verwendung von VSS können alle Microsoft-Applikationen innerhalb einer virtuellen Maschine anwendungskonsistent gesichert werden, wenn sie auf einem iSCSITarget der PS-Serie liegen. Zum Zeitpunkt der Erstellung dieses Buches unterstützt das HIT der PS-Serie eigene GUIs und CLI-Schnittstellen für Backup und Restore von Microsoft SQL und Microsoft Exchange. VMware und iSCSI-Multipathing aus der Linux-VM Analog zu den letzten Ausführungen können auch virtuelle Linux-Gäste selbsttätig auf iSCSI-Targets zugreifen und damit auch mehrpfadige Zugriffe realisieren. Da die einzelnen Linux-Distributionen unterschiedliche Integrationstiefen aufweisen, erläutern wir die Art der Anbindung am Beispiel einer Debian-Umgebung. In den meisten Linux-Distributionen wurde lange Zeit ein iSCSI-Initiator der Firma Cisco eingesetzt, der auch die Grundlage für den iSCSI-Initiator in ESX 3.x war. Dieser Initiator hatte den Nachteil, dass er von der Leistungsfähigkeit her beschränkt war und auch kein Multipathing unterstützte. Der aktuell leistungsfähigste Initiator ist der Open iSCSI Initiator, der auf www.open-iscsi.org zum Download bereitsteht. Dieser Initiator existiert bereits
560
Storage-Produkte
in der zweiten Version, wird aber immer noch als semi-stable bezeichnet, da sich der Entwickler weiterhin Änderungen am Design offenhält. Die ursprüngliche Version dieses Initiators ging zur Multipathing-Unterstützung davon aus, dass ein iSCSI-Storage-Target über mehrere IP-Adressen erreicht werden kann. Die aktuelle Version ist aber auch in der Lage, mehrere iSCSI-Sessions zur gleichen IP-Adresse aufzubauen, und unterstützt dadurch auch Multipathing mit iSCSI-Targets der PS-Serie. Der Linux-Storage-Verbraucher muss für Multipathing über mindestens zwei Netzkarten für den SAN-Zugang verfügen, die beide mit einer festen IP-Adresse versehen sein müssen. Die MAC-Adressen dieser Karten machen Sie dem iSCSI-Initiator bekannt, und wenn ein iSCSI-Log-in erfolgen soll, wird dieser automatische mehrfach über alle konfigurierten Netzkarten durchgeführt. Dazu wird das Tool iscsiadm verwendet.
Anwendungen /dev/dm-0 Linux Device Mapper
Linux Virtual Machine
/dev/eth0
/dev/eth1
/dev/sda
LAN vNIC
LAN Portgroup
VMDK
LAN NIC
/dev/eth2
/dev/eth3
SAN vNIC
VMFS 3
LAN vSwitch LAN NIC
/dev/sdc
Open-iSCSI-Initiator
Linux-Kernel LAN vNIC
/dev/sdb
SAN vNIC
SAN Portgroup SAN vSwitch
SAN NIC
SAN NIC
ESX-Server
PS Series Group
Abbildung 10.36
Mehrpfadiger iSCSI-Anschluss unter Linux
Im folgenden Beispiel zeigen wir die Konfigurationsdateien für zwei Netzkarten mit SAN-Zugang:
561
10.1
10
Hersteller-Best-Practices
cat /etc/iscsi/ifaces/iface0 iface.transport_name = tcp iface.hwaddress = 00:0c:29:34:4f:d0 cat /etc/iscsi/ifaces/iface1 iface.transport_name = tcp iface.hwaddress = 00:0c:29:34:4f:da
Wie bei den vorhergehenden Beispielen scannen Sie auch hier zunächst die Group-IP der PS-Serie als iSCSI-Portal: iscsiadm -m discovery -t st -p 192.168.20.10 192.168.20.10:3260,1 iqn.2001-05.com.equallogic:0-290c06-38573141800b000000104ae3c-vsphere 192.168.20.10:3260,1 iqn.2001-05.com.equallogic:0-290c06-38573141800b000000104ae3c-vsphere
Das gefundene iSCSI-Target wird über zwei Pfade gesehen: Beim folgenden iSCSI-Log-in werden dementsprechend zwei iSCSI-Sessions aufgebaut: iscsiadm -m node -T iqn.2001-05.com.equallogic:0-290c06-38573141800b000000104ae3c-vsphere -p 192.168.20.10 -l Logging in to [iface: iface0, target: iqn.2001-05.com.equallogic: 0-290c06-385731418-00b000000104ae3c-vsphere, portal: 192.168.20.10,3260] Logging in to [iface: iface1, target: iqn.2001-05.com.equallogic: 0-290c06-385731418-00b000000104ae3c-vsphere, portal: 192.168.20.10,3260] Login to [iface: iface0, target: iqn.2001-05.com.equallogic: 0-290c06-385731418-00b000000104ae3c-vsphere, portal: 192.168.20.10,3260]: successful Login to [iface: iface1, target: iqn.2001-05.com.equallogic: 0-290c06-385731418-00b000000104ae3c-vsphere, portal: 192.168.20.10,3260]: successful
Der iSCSI-Log-in erzeugt ein neues SCSI-Gerät im Device-Tree des Linux-Betriebssystems. Sollte später z. B. die iSCSI-Session geschlossen werden und dann ein weiterer Log-in erfolgen, erzeugt dies unter Linux einen neuen Gerätenamen. Dementsprechend ist der Gerätename nicht verlässlich. Das umgehen Sie, indem Sie beim Mount eines File-Systems nicht den Gerätenamen verwenden, sondern die UUID des vorher erzeugten File-Systems. Im Fall der im Beispiel aufgebauten iSCSI-Sessions wurden die Geräte /dev/sdc und /dev/sdd neu erzeugt:
562
Storage-Produkte
iscsiadm -m session -P 3 | grep "Attached scsi disk" Attached scsi disk sdd State: running Attached scsi disk sdc State: running
Mehrpfadige Anschlüsse von Platten erfolgen unter Linux durch den DeviceMapper. Er muss gemeinsam mit den Multipath-Tools installiert sein. Der Device-Mapper erkennt die gleiche Platte hinter den beiden neu erzeugten Geräten und baut dazu ein neues virtuelles Gerät auf. Mit dem Tool multipath fragen Sie die Multipathing-Konfiguration ab und ändern Sie bei Bedarf werden. Gegebenenfalls müssen Sie die Gerätenamen in der Blacklist der Datei /etc/multipath.conf auskommentieren und die Verwendung von Round-Robin dort aktivieren. Ein Beispiel der Datei /etc/multipath.conf finden Sie nachfolgend: defaults { udev_dir /dev polling_interval 10 selector "round-robin 0" path_grouping_policy multibus getuid_callout "/lib/udev/scsi_id -g -u -s /block/%n" prio_callout /bin/true path_checker directio rr_min_io 100 rr_weight priorities failback immediate no_path_retry fail user_friendly_names yes } #blacklist { # wwid 26353900f02796769 # devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" # devnode "^hd[a-z][[0-9]*]" #} multipath -l 360c09082413157383cae04010000b000 dm-0 EQLOGIC ,100E-00 [size=50G][features=0][hwhandler=0] \_ round-robin 0 [prio=0][active] \_ 4:0:0:0 sdc 8:32 [active][undef] \_ round-robin 0 [prio=0][active] \_ 3:0:0:0 sdd 8:48 [active][undef] ls -l /dev/mapper total 0 brw-rw---- 1 root disk 254, 0 2009-1101 20:52 360c09082413157383cae04010000b000
563
10.1
10
Hersteller-Best-Practices
Auf dem neuen virtuellen Gerät können Sie jetzt z. B. ein File-System anlegen und verbinden, auf das mit Round-Robin zugegriffen wird. mkfs -t ext3 /dev/mapper/360c09082413157383cae04010000b000 mkdir /iscsi tune2fs -l /dev/mapper/360c09082413157383cae04010000b000 | grep UUID Filesystem UUID: 3b1f51f8-d791-4841-aa54-9d15e703cc06 echo „UUID=3b1f51f8-d791-4841-aa54-9d15e703cc06 /iscsi ext3 _netdev 0 0“ >>/etc/fstab mount /iscsi df -h /iscsi Filesystem Size Used Avail Use% Mounted on /dev/mapper/360c09082413157383cae04010000b000 50G 180M 47G 1% /iscsi
Datensicherung mit der PS-Serie unter VMware vSphere Für die Datensicherung in virtuellen Umgebungen setzen viele Administratoren Backup-Agenten innerhalb virtueller Maschinen ein, die dann eine normale Datensicherung über das Netzwerk durchführen. Dies erzeugt entsprechende Last auf dem Hypervisor, die Sie durch den Einsatz anderer Techniken vermeiden können. Vom einem Enterprise-Storage-System kann man heute die Unterstützung von Online-Backups in Form der Snapshot-Technologie erwarten. Bei der PS-Serie gehören höhere Funktionen wie Snapshots und Replikation zum Grundumfang der Firmware und benötigen keine weiteren Lizenzen. Wie weiter oben erläutert, ist eine logische Platte (Volume) in der PS-Serie eine Aufzählung von einzelnen Seiten, die jeweils auf einem physischen Array realisiert werden, insgesamt aber über mehrere Arrays verteilt sein können. Die Seiten eines Volumes werden über Metadaten verwaltet (siehe Abbildung 10.37). Soll ein Volume-Snapshot gezogen werden, wird die I/O zum Volume angehalten und eine Kopie der Metadaten erzeugt. Dies geschieht sehr schnell und erfolgt im Sekundenbereich, anschließend kann das Volume sofort wieder verwendet werden. Der Snapshot belegt zunächst keinen zusätzlichen Platz. Wird jetzt eine Seite des Volumes schreibend verändert, reserviert die Firmware eine neue Seite aus dem Poolbereich des Volumes, kopiert die Originalseite auf die neue Seite und weist die neue Seite dann dem Volume neu zu. Dann wird die Änderung in diese neue Seite geschrieben. Nur der Snapshot verweist noch auf die ursprüngliche Seite und garantiert so immer den Zustand des Volumes zum Zeitpunkt des
564
Storage-Produkte
Volume Abbildung 10.37
VolumeSeiten
SnapshotSeiten
Snapshot A
Snapshot-Metadaten
Volume-Metadaten
Snapshot-Metadaten
Snapshots. Durch diese Technik benötigt der Snapshot nur dann Ressourcen des Arrays, wenn eine neue Seite zum Erhalt des Snapshot-Zustands benötigt wird. So sind Snapshots der PS-Serie ohne wesentliche Leistungseinbussen auf den Array-Controllern möglich. Die PS-Serie unterstützt 512 Snapshots je Volume; mehrfache Snapshots eines Volumes sind kaskadierend auf dem gleichen Prinzip aufgebaut und unterscheiden sich nur durch Deltas von ihren Vorgängern. Jeder Snapshot in einer Kaskade kann einzeln gelöscht werden, ohne die anderen Snapshots dadurch zu beeinflussen.
SnapshotSeiten
Snapshot B
Dell-EqualLogic-Snapshots
Snapshots können Sie ad hoc grafisch oder über Kommandozeile erstellen oder auch über einen Scheduler planen und automatisch ausführen. Hardware-Snapshots haben natürlich keinen Bezug zu den die Volumes nutzenden Anwendungen, sie sind daher nur crashkonsistent. Sie entsprechen damit dem Zustand eines im vollen Betrieb abgestürzten Systems, und ihre Verwendung erfordert gegebenenfalls Wiederherstellungsmaßnahmen, wie z. B. einen File-System-Check oder eine Datenbankwiederherstellung. Aus Sicht eines Datensicherungskonzeptes ist das nicht immer ausreichend. Die PS-Serie bietet daher schon seit langem mit dem kostenlosen Auto-Snapshot Manager ein Werkzeug, das auf Windows-Plattformen den Volume Shadow Service (VSS) nutzt, um für alle Microsoft-Anwendungen applikationskonsistente Snapshots von iSCSI-Targets zu erzeugen. Dies ist ein gutes Argument für den
565
10.1
10
Hersteller-Best-Practices
Einsatz eines iSCSI-Software-Initiators innerhalb einer virtuellen Maschine. ASM-Snapshots werden in der PS-Serie als Smart Copies bezeichnet. Die Werkzeuge verschiedener Datensicherungshersteller integrieren sich ebenfalls in VSS und können so anwendungskonsistente Snapshots mit der PS-Serie erzeugen (z. B. Symantec Backup Exec); ASM fungiert dann als VSS-Provider der PS-Serie.
Abbildung 10.38
Auto-Snapshot Manager für VMware (ASM/VE)
Für VMware vSphere bietet die PS-Serie einen ebenfalls kostenlosen AutoSnapshot Manager für VMware an (ASM/VE). Der ASM/VE verbindet sich über die vCenter-API mit dem vCenter-Server und gleichzeitig mit der korrespondierenden PS-Serie. Vor dem Erzeugen von Smart Copies können Sie VMware Memory-Dumps und VMware-Snapshots erzeugen, um eine möglichst hohe Datenkonsistenz der Smart Copies zu ermöglichen. Der ASM/VE stellt die Sicht der VMware-Objekte analog zum vCenter in einem Web-GUI dar, und bei Bedarf führen Sie Datastore-Sicherungen ad hoc durch oder planen und automatisieren sie auch hier über einen Scheduler. Smart Copies können dann nicht nur als Datensicherung verwendet werden, sondern erlauben auch das Clonen von virtuellen Maschinen mit Storage-Mitteln. Das ermöglicht ein deutlich schnelleres Cloning als mit VMware-eigenen Mitteln.
566
Storage-Produkte
Natürlich können Sie Datastores und virtuelle Maschinen auch von einer Smart Copy restaurieren. Smart Copies können neben den reinen VMware-Datastores auch Snapshots von iSCSI-Targets enthalten, die mit einem Gast-Initiator innerhalb einer zu sichernden virtuellen Maschine angebunden sind. Der ASM/VE präsentiert neben den Smart Copies auch storage-relevante Sichten des vCenter-Servers, und Sie können ein Rescan von Storage-Targets auf den ESXServern direkt aus ASM/VE heraus anstoßen. Disaster-Recovery Neben der reinen Snapshot-Funktion stellt die PS-Serie auch eine Replikationsfunktion bereit. In der Firmwareversion zum Zeitpunkt der Drucklegung handelte es sich dabei um eine Point-in-Time-Kopie. Ein synchrones Replikat ist für eine zukünftige Firmwareversion geplant. Das Point-in-Time-Replikat ist im Prinzip ein Snapshot, der an einen entfernten Standort übertragen wird. Dazu werden getrennte Gruppen benötigt, zwischen denen eine Replikationspartnerschaft aufgebaut wird. Jede der beteiligten Gruppen kann Replikate zu ihren Partnern übertragen. Dazu wird ein Teil der Poolkapazität einer Gruppe für den Partner reserviert (delegiert) und ist dann für normale Volumes innerhalb der Gruppe nicht mehr nutzbar. Vielmehr werden hier replizierte Daten der Partnergruppe abgelegt. Analog zu Snapshots können Sie auch Replikate ad hoc oder über einen Scheduler planen und automatisiert erzeugen. Der ASM/VE bietet neben Smart Copies auch die Integration für Smart-CopyReplikate an. Smart-Copy-Replikate können Sie ebenfalls mit einem VMwareMemory-Dump verknüpfen. Neben dem ASM/VE bietet die PS-Serie einen Storage-Replication-Adapter für den VMware Site Recovery Manager. Damit können Sie Replikate in ein standortübergreifendes Disaster-Recovery-Konzept mit automatischer Umschaltung integrieren. Die Umschaltungen werden mittels VMware Site Recovery Manager als Workflow implementiert. URLs http://www.equallogic.com/resourcecenter/assetview.aspx?id=8453
567
10.1
Hersteller-Best-Practices
VMware Site Recovery Manager Standort A
Standort B VM
VM
VM
VM
VM
VM
VM
VM
APP
APP
APP
APP
APP
APP
APP
APP
OS
OS
OS
OS
OS
OS
OS
OS
vSphere
vSphere
iSCSI-SAN
Dell EqualLogic SRM-Adapter
®
WAN
LUN
Abbildung 10.39
LUN
LUN
®
®
iSCSI-SAN
®
Dell EqualLogic SRM-Adapter
10
LUN
LUN
LUN
Integration VMware Site Recovery Manager
10.1.8 Pillar Pillar Data Systems wurde bereits 2001 gegründet, allerdings wurde das erste Storage-System 2005 ausgeliefert. Während dieser Zeit wurde das Axiom-System entwickelt, welches Pillar im April 2005 am Markt vorstellte. Mit den Modellen Axiom 300 (SMB-Markt) und Axiom 600 (früher 500 – Mittelstand und gehobener Mittelstand) deckt Pillar bis auf den High-End-Markt alle Kundengrößen ab. Die Architektur der Axiom-Systeme ist so aufgebaut, dass unter gleicher Software die Systeme absolut flexibel und linear skalierbar, also ausbaubar, sind. Es existieren zwei Komponenten in dieser Architektur, die als Slammer (I/O-Controller) und Bricks (Platteneinheiten) bezeichnet werden. Beide Komponenten können ausgebaut werden, um Bandbreite, I/Os und Kapazität zu steigern. Hierbei werden allerdings keine zusätzlichen Lizenzkosten fällig (Ausnahme Thin Provisioning). In Bricks können Sie SATA- und FC-Festplatten nutzen, allerdings ist ein Brick mit komplett einheitlichen Festplatten zu bestücken. Mit der Axiom 600 sind auch SSD-Laufwerke nutzbar.
568
Storage-Produkte
Außerdem ist es möglich, die Axiom-Systeme blockorientiert über FC oder iSCSI zu verwenden, aber auch dateiorientiert als NAS-System (CIFS + NFS). Hier wird im Gegensatz zu NetApp komplett getrennt gearbeitet, das heißt, die blockorientierten Zugriffe finden wirklich blockorientiert im Backend statt und nicht durch die Ablage der LUNs auf dem Filer-Dateisystem.
BANDBREITE Storage System Fabric
IOPS TB
Abbildung 10.40
IOPS TB
IOPS TB
IOPS TB
Skalierbare Infrastruktur Pillar Axiom
Die Slammer bilden die I/O-Controller-Einheit, die mit 24 GB Cache ausgebaut ist. Pro Axiom sind maximal 4 Slammer und 64 Bricks möglich. Gesteuert wird das voll redundante System mittels Pilot-Komponente, die in geclusterter Ausführung einmal vorkommt. Der Pilot stellt die Weboberfläche zur Verwaltung der Axiom-Systeme bereit und bietet neben der Bedienung des Storage auch die Möglichkeiten einer Kapazitätsplanung und der Anpassung von Qualitätsklassen im laufenden Betrieb. Die Platteneinheiten, Bricks genannt, sind je nach Festplattentyp (SATA, FC, SSD) unterschiedlich von der Anzahl der Festplatten und des RAID-Sets aufgebaut, allerdings existieren immer zwei redundante RAID-Controller. Dies sorgt für die lineare Skalierbarkeit, da die RAID-Berechnung nicht im Storage-Prozessor im Slammer, sondern in den RAID-Controllern in den Bricks erfolgt. In Abbildung 10.42 sehen Sie ein SSD-Brick, das über eine Hot-Spare und zwei RAID-Gruppen à sechs SSD-Platten verfügt. Diese Zuordnung wird automatisch durch die Axiom getroffen.
569
10.1
10
Hersteller-Best-Practices
Abbildung 10.41
Axiom Capacity Planner – Webmanagement
RAID-Controller
RAID
RAID HotSpare
Abbildung 10.42
Axiom-SSD-Brick
Allerdings wird nicht direkt auf die RAID-Gruppen in den Bricks zugegriffen, sondern der Slammer sorgt für ein Spanning verschiedener RAIDs zu einem RAID 50 oder 100. Dieses große RAID kann mittels LUN beliebig aufgeteilt an die Hosts gegeben werden. Interessant hierbei ist allerdings, dass der I/O über alle Festplatten läuft und nicht nur über die einer kleinen RAID-Gruppe.
570
Storage-Produkte
In dem Beispiel in Abbildung 10.43 erkennen Sie die Verteilung: Die RAIDGruppe, die die Volumes für das Frontend bereitstellt, besteht im Backend aus einem RAID 0, das über vier RAID-5-Gruppen verfügt. Dadurch werden bei Anfragen auf die Volumes mindestens 24 Festplatten genutzt.
Abbildung 10.43
Axiom Distributed-RAID-Konzept
Möchten Sie die Ausfallsicherheit weiter erhöhen, so ist es möglich, die Hälfte der Kapazität mittels Double Protection als internen Datenspiegel zu verwenden, was den Ausfall von kompletten Platteneinheiten ohne Datenverlust erlaubt.
Abbildung 10.44
Axiom Double Parity zur Erhöhung der Ausfallsicherheit
571
10.1
10
Hersteller-Best-Practices
Neben diesem – besonders auch für virtuelle Umgebungen – leistungsfähigen Konzept bietet Pillar auch die Möglichkeit, verschiedene Leistungsklassen mittels Plattentypen, aber auch Plattenbereichen zu nutzen. Dies wird weiter vervollständigt durch die Zuweisung von Cachegrößen und Priorisierung der Warteschlangen. Die Quality-of-Service-Level der Volumes entscheiden auch über die Datenablage auf den Festplattenbereichen. Rein physisch sind die äußeren Bereiche einer Festplatte schneller erreichbar, da der Schreib-Lese-Kopf sehr wenig Bewegung benötigt, um viele Festplattensektoren zu erreichen. Je weiter sich die Sektoren im Inneren der Festplatte befinden, desto langsamer und aufwendiger sind die Zugriffe durch den Schreib-Lese-Kopf. QoS Bands Seek Time
High 20% Medium 40%
Rotational Velocity
Low 20% Archive 20%
S-ATA Disk Platter
Abbildung 10.45
Axiom-QoS durch Nutzung von Plattenbereichen
Dies ist besonders bei der Nutzung von SATA-Platten interessant, da deren Leistungsfähigkeit bei Random-I/O im Vergleich zu SAS- oder FC-Festplatten sehr nachlässt. Durch die Nutzung der äußeren Bereiche ist eine wesentlich bessere Ausbeute möglich. Bei Verwendung von SSD-Laufwerken funktioniert diese Weise des QoS natürlich nicht, allerdings bringt dort die Cache- und QueuePriorisierung die gewünschten QoS-Level. Dank der Möglichkeiten der Pillar Axiom im Zusammenhang mit VMware können LUNs und damit VMs priorisiert werden (Abbildung 10.46). Außerdem werden die LUNs immer über sehr viele Festplatten verteilt, was die Leistungsfähigkeit im Random-Bereich deutlich steigert und für VMware ideal ist. Die Zuordnungen sind im laufenden Betrieb änderbar, und Sie können sowohl nur die Caching-/Queuing-Einstellungen anpassen als auch die Daten auf der Plattenphysik verschieben (QoS – äußere vs. innere Sektoren).
572
Storage-Produkte
Abbildung 10.46
VMware- vs. Pillar-Axiom-Layout
Die Pillar Axiom unterstützt generell Snapshots und auch Snapshot-Clones, so dass Sie Kopien von LUNs an die ESX-Hosts zusätzlich mounten können (z. B. für Sicherungen). Außerdem ist Thin Provisioning möglich. Ein Wermutstropfen ist das fehlende Controller-based Mirroring, wodurch mehrere Axioms nicht nativ miteinander Daten replizieren oder spiegeln können. Allerdings ist die Implementierung nur noch eine Frage der Zeit. Zur Replikation und Spiegelung arbeitet Pillar allerdings sehr eng mit dem Spezialisten für Storage-Virtualisierung, FalconStor, zusammen, was von Kunden sehr gut angenommen wird. Die Implementierung von FalconStor hat übrigens auch den positiven Nebeneffekt, dass die Pfade der Axiom genau angesteuert werden können, um immer die optimalen Pfade zum Storage-System zu nutzen, da es sich bei der Axiom um ein Asymmetric-active/active-System handelt. Auch das in VMware vSphere integrierte ALUA-Pfadmanagement wird von der Axiom unterstützt. Pillar hat zwar keine öffentlichen Best-Practice-Dokumente für die Axiom-Systeme und vSphere, allerdings existiert ein sehr interessantes allgemeines Dokument zur Pillar-Architektur und zu deren Vorteilen für virtuelle Maschinen: http://go.pillardata.com/forms/VirtualInfrastructureForm
10.1.9 NetApp NetApp ist definitiv einer der beliebtesten Storage-Hersteller im Virtualisierungsumfeld und damit auch bei VMware-Integrationen. Durch die Verbindung von NAS (NFS), FC, FCoE und iSCSI bieten die Plattformen bei Nutzung der gleichen Storage-Verwaltung (Software und API) sämtliche Flexibilität.
573
10.1
10
Hersteller-Best-Practices
Flexibilität bringt allerdings wenig, wenn man Sie sie nicht zielorientiert für den Kunden bereitstellen können, daher sollten Sie sich immer sehr kompetente Partner in dem Umfeld suchen. Allzu oft habe ich in meiner Beratungszeit Kunden getroffen, die durch falsche Storage-Beratung nur durch teure nachträgliche Aufrüstung zum erwarteten Ziel gelangten oder dieses aufgrund fehlenden Budgets nicht mehr erreichten. Die NetApp-FAS-Familie bildet nahezu jede Größenordnung im Unternehmen ab, beginnend bei einer FAS2020 (bis zu 68 TB) bis hin zu einer FAS6080 (bis zu 1.176 TB). Außerdem ist NetApp unangefochten der führende Softwarehersteller unter den Storage-Anbietern, da die Vielzahl an Softwarelösungen mit Integration in die FAS-Hardware doch enorm ist. Vor allem die Funktionen Thin Provisioning, Deduplication und Software wie Rapid Cloning Utilities und SnapManager for Virtual Infrastructures sind bei Kunden im Virtualisierungsumfeld sehr beliebt. Eine der großen Stärken von NetApp sind die ausgefeilten Snapshot-Methoden, die sich auch platzsparend kaskadieren lassen. Dies geht so weit, das virtuelle Desktops nicht per VM-Cloning, sondern per Snapshot-Cloning realisiert werden, um auch größere Anzahlen virtueller Maschinen sehr zeitnah (mehrere Hundert, innerhalb Minuten) anzulegen. Außerdem bestehen alle die Möglichkeiten der synchronen und asynchronen Replikation zwischen den Storage-Systemen durch SnapMirror bis hin zur Metrocluster-Architektur, bereits beginnend bei kleinen Storage-Modellen. Im Kapitel 9, »Storage-Konfiguration unter VMware«, wurden die VMware-Einstellungen auf Basis der NetApp-Systeme näher erklärt, und Oliver Kügow von team(ix) geht auch tiefer in die Themen Troubleshooting und Tuning am Beispiel NetApp ein. Daher möchte ich an dieser Stelle nicht tiefer auf das Thema eingehen. Der »vSphere on NetApp Best Practice Guide« von NetApp ist außerdem zum Download verfügbar, und Sie sollten ihn in jedem Fall vor Integration des NetApp-Systems und Verbindung zu vSphere lesen, da er äußerst nützliche Informationen bei Design und Betrieb enthält: http://media.netapp.com/documents/tr-3749.pdf
574
Storage-Virtualisierung
10.2
Storage-Virtualisierung
Neben den traditionellen Speichernetzwerken wurden bereits vor Jahren die virtuellen Speichernetzwerke eingeführt. Obwohl technisch reif und hochinteressant, dauerte es eine ganze Zeit, bis die ersten Unternehmen diese Technologie ins Rechenzentrum aufnahmen. Mittlerweile existieren sehr viele Lösungen am Markt, darunter von Storage-Giganten wie IBM, HDS und EMC. Aber auch kleinere Unternehmen haben sich mit ihren Lösungen am Markt etabliert, darunter FalconStor, DataCore und HP LeftHand. Außerdem existieren switch-basierte Lösungen von Cisco oder Brocade. Ohne zu tief in die Technologie eintauchen zu wollen, bieten Storage-Virtualisierungs-Lösungen einige Vorteile, die sich absolut sehen lassen. Diese werde ich im Folgenden vorstellen.
10.2.1
Herstellerunabhängige Replikation
Da die Virtualisierungsschicht die direkte Kommunikation mit den Frontend-Servern (z. B. ESX) hält und die Storage-Systeme im Backend verbirgt, ist es möglich, die ankommenden und abgehenden I/Os zu beeinflussen. Dadurch können Sie die Replikation oder Spiegelung von Daten mit jeglichem Storage im Backend realisieren. Selbst Storage-Systeme, die keine eigene Replikation mitbringen, lassen sich so zur Replikationsfähigkeit aufwerten. Virtualisierung ist für jedes Storage-Protokoll möglich, das heißt, es existieren Lösungen für SAN, IP-SAN und NAS. Sie müssen jedoch die bestehende Leistungsfähigkeit der Storage-Systeme beachten. Wenn Sie beispielsweise einen synchronen Spiegel aufbauen, so entscheidet das langsamste System über die Gesamtgeschwindigkeit. Sparsamkeit am falschen Ende führt schnell zu sehr unschönen Überraschungen.
10.2.2 Transparente Ausfallsicherheit Ein absolutes Highlight der Storage-Virtualisierung ist die Nutzung verteilter Storage-Ressourcen. Dadurch kann die Leistung und Ausfallsicherheit bereits enorm erhöht werden, indem sowohl die Last zwischen der Hardware im Backend aufgeteilt wird als auch bei Ausfall eines Systems die Kommunikation über die verbleibenden Systeme erfolgt. Dies geht so weit, dass manche Hersteller einen transparenten Failover realisieren können, das heißt, trotz des Ausfalls eines kompletten Storage-Systems merken die Applikationen nichts, da die Datenkommunikation innerhalb kürzester Zeit auf noch aktive gespiegelte Systeme umgeschaltet wird. Für den ESX-Host ist dies noch nicht einmal ein Pfadwechsel im
575
10.2
10
Hersteller-Best-Practices
SAN. Kommt es zum Ausfall einer der Appliances, die für die Storage-Virtualisierung zuständig sind, so findet zwar ein Pfadwechsel statt, es kommt allerdings zu keinem Ausfall für die Server. Beim Einsatz von virtuellen Maschinen bringt die Storage-Virtualisierung zusätzliche Ausfallsicherheit, die vor allem beim Storage dringend nötig ist.
10.2.3 Erweiterte Volume-Konfigurationen Außerdem lassen sich dank der Storage-Virtualisierung Funktionen realisieren, die die Storage-Systeme im Backend von Haus aus nicht haben oder die nicht lizenziert wurden. Neben der bereits erwähnten Replikation sind auch Funktionen wie Snapshots, Thin Provisioning oder Cloning möglich.
10.2.4 Implementierung Je nach Hersteller und Art der Speichervirtualisierung ist auch die Implementierung unterschiedlich. Die meisten Lösungen klinken sich als Appliance zwischen Host-Systeme und Storage-Systeme. Die Storage-Systeme provisionieren die Volumes an die Appliances, die die LUNs in gleicher oder angepasster Form an die Host-Systeme verteilen.
Abbildung 10.47
576
Storage-Virtualisierung
Storage-Virtualisierung
Zumeist ist die Implementierung mit äußerst geringer Ausfallzeit verbunden, und zwar der Umschaltung von der traditionellen Storage-Anbindung zur Storage-Virtualisierung. In manchen Fällen werden die Storage-Virtualisierungsprodukte auch nur kurzzeitig zur Migration von Alt- auf Neu-Storage implementiert und eingesetzt. Im Folgenden möchten wir einige der bekannteren Storage-Virtualisierungslösungen vorstellen. Wir verzichten bewusst auf die Enterprise-Lösungen von EMC, HDS, NetApp und IBM, da diese nahezu ausschließlich in gehobenen Mittelstand- und Enterprise-Architekturen zu finden sind. Die Produkte von HP (LeftHand), DataCore (SANmelody, SANSymphony) und FalconStor sind in allen Größenordnungen von Unternehmen zu finden.
10.2.5 DataCore DataCore hat sich komplett der Storage-Virtualisierung verschrieben und feiert sowohl im SMB-Markt als auch in Enterprise-Umgebungen Erfolge. Bemerkenswert ist die Analogie zur Hypervisorentwicklung, bei der die Hardwareunabhängigkeit und die Entkoppelung des Bereitstellungszyklus von Hardware gegenüber der eigentlichen Darstellung von Ressourcen den Durchbruch zum Mainstream bedeuteten. Neben der SMB-Lösung SANmelody existiert die umfangreichere Version SANsymphony, die sich auch für den größeren Mittelstand und Rechenzentren eignet und für deren Bedürfnisse einen größeren Funktionsumfang und deutlich mehr Speicherunterstützung bietet. Damit können Sie bis zu 1.024 Storage-Server in unterschiedliche »Regionen« zusammenfassen und die in »Domains« gruppierten Anwendungs-Server auf Basis von Quality-of-Service-Merkmalen mit den jeweils passenden Speicherklassen bedienen. Auch hier lässt der Vergleich mit Peer-to-Peer-Verfahren à la Vuze ahnen, welche Vision DataCore spätestens nach der »Cloud« in Form des Storage-Grids umzusetzen gedenkt. Beide Lösungen basieren auf Microsoft Windows, und die neuesten Versionen SANmelody 3 und SANsymphony 7 benötigen zwingend einen Microsoft Windows Server 2008 64-Bit, um den verfügbaren RAM linear in bis zu 1 TB Cache zu verwandeln. Daher können DataCore-Storage-Domain-(SDS-)Server auf Standard-Industrie-Servern oder virtuellen Maschinen gleichermaßen laufen. Besonders beliebt ist die Kombination HP DL380 mit P800-SAS-Controller und der Platteneinheit HP MSA70.
577
10.2
10
Hersteller-Best-Practices
Abbildung 10.48
DataCore-Funktionsvergleich SANmelody vs. SANsymphony
Allerdings plant man die Systeme entsprechend der Anforderungen des Kunden individuell, und es muss hauptsächlich auf die ausreichende Anzahl an FC- oder iSCSI-Schnittstellen und den Durchsatz des Server-Systems geachtet werden. Sie können natürlich auch intelligente Storage-Systeme im Backend verwenden und nicht nur Platteneinheiten. DataCore brachte frei nach der Fernsehserie »Pimp my ride« den Slogan »Pimp my storage«, der definitiv passt. Hintergrund ist u. a. die Möglichkeit, den Hauptspeicher des Server-Systems zum größten Teil als Storage-Cache zu verwenden. Hier kommt natürlich die Basis eines Windows-64-Bit-Betriebssystems aufgrund der hohen Hauptspeichergrößen besonders zur Geltung. Bei den heutigen Hauptspeichergrenzen ist es daher kein Problem, ein 32-GB-System aufzubauen, das bis zu 30 GByte als Storage-Cache verwenden könnte. Dies erlaubt einen deutlichen Leistungszuwachs, um jedoch neben dem immer eingeschalteten Lesecache insbesondere den Schreibcache für die Volumes nutzen zu können, müssen Sie die Volumes durch synchrone Spiegelung ausfallsicher realisieren. Außerdem lassen sich dank der Storage-Virtualisierung auch »dumme« StorageSysteme mit Funktionen wie Snapshots, asynchroner Replikation oder Thin Provisioning versorgen. Thin Provisioning unterstützt auch das sogenannte Space Reclamation, um den verbrauchten Plattenplatz von bereits gelöschten Dateien wieder zurückzugewinnen.
578
Storage-Virtualisierung
Abbildung 10.49
DataCore Level 1 Caching beschleunigt die Storage-Ressourcen deutlich.
Mit den Storage-Pools setzt DataCore das Speicherklassenmodell ein, bei dem beliebige Disks in einem Pool durch ein effizientes RAID-Striping bedient werden. Natürlich können Sie die teilnehmenden Disks im laufenden Betrieb austauschen und zwischen den Speicherklassen verschieben oder auch entsorgen. Auf diese Art können Sie unterschiedlichste Backend-Speicher verwenden. So realisieren Sie mit der Kombination aus dem DataCore-Cache und nur wenigen Intel-X25-M-SLC-SSDs die gleiche I/O-Performance wie manch komplett ausgestattete Platteneinheiten. Auf diese Art konfektionieren Sie Ihren eigenen Massenspeicher.
Abbildung 10.50
DataCore-Funktionen im Überblick
579
10.2
10
Hersteller-Best-Practices
Die Anbindung erfolgt im Frontend (also an die Host-Systeme) über iSCSI, FibreChannel und FCoE oder aus dem vom Windows Server 2008 bereitgestellten NFS bzw. CIFS, wobei iSCSI und Fibre-Channel von Kunden bevorzugt sind. Im Backend besteht eine Vielzahl von Möglichkeiten, da nahezu alle von MS Windows zu sehenden Massenspeicher verwendet werden. Dabei spielt es weniger eine Rolle, ob lokaler SAS-Controller, FC, FCoE oder iSCSI-HBA, iSCSI-SoftwareInitiator oder AoE-Softwaretreiber verwendet wird, sondern eher, welche Leistungsfähigkeit benötigt wird.
Abbildung 10.51 DataCore-Integrationsbeispiel für ein redundantes Rechenzentrum mit Spiegelung (FC-Frontend und -Backend)
Daher ist eine entsprechende Planung bei der Implementierung der DataCoreLösungen enorm wichtig, um wirklich alle Aspekte des produktiven Einsatzes zu bedenken. Dies gilt auch für den Bedarf an Ausfallsicherheit, da DataCore eine Vielfalt an Möglichkeiten bietet, bis zum transparenten Failover und transparenten Failback. Speziell im Zusammenhang mit VMware ESX Server ist DataCore mit beiden Produkten auf der Zertifizierungsliste (HCL) vertreten, sowohl für ESX 3.x als auch für vSphere. Die Besonderheit ist, dass DataCore keine zusätzlichen Treiber oder Agents benötigt, sondern ausschließlich das native Multipathing des ESX-Servers verwendet – ein nicht zu unterschätzender Faktor mit Blick auf die allgegenwärtige VMwareSupportproblematik.
580
Storage-Virtualisierung
Abbildung 10.52
Metro-weite virtuelle Festplatten sorgen für hohe Ausfallsicherheit.
Beim transparenten Failover wird die Ausfallvermeidung zum Maximum getrieben, da auch ein Verlust eines Storage-Systems, auf dem die virtuelle Maschine gerade betrieben wird, oder dessen zuführender Switch-Technik abgefangen wird und die virtuelle Maschine ohne Ausfall auf der Redundanz des StorageSpiegelpartners weiterläuft. Da DataCore kein Storage-Cluster ist, sondern einen Duplexbetrieb im Innenverhältnis der Storages darstellt, stehen beide StorageServer autark und immer active/active zur Verfügung. Der Architekturvorteil ist, dass die SCSI-Timeouts der Gastsysteme nicht zu erhöhen sind und damit kein Bluescreen oder Re-Mount zu erwarten ist, weil der Standardwert von 60 Sekunden völlig ausreicht.
Abbildung 10.53
Vorgang des transparenten Failovers
581
10.2
10
Hersteller-Best-Practices
Beschreibt man den transparenten Failover technisch, so wären die Schritte wie folgt: 왘
Der ESX-Host setzt einen I/O-Schreibzugriff auf dem präferierten Pfad ab und erkennt einen Fehler (1).
왘
Über das Multipathing-Modul des VMkernels erfolgt ein Neuversuch der I/OAnfrage über den alternativen Pfad (1).
왘
Der Schreibvorgang wird im Cache angenommen und auf die Festplatten geschrieben (2).
왘
In der Protokolldatei wird aktualisiert, welcher Block verändert wurde (3).
왘
Der Schreib-I/O an den ESX-Host wird bestätigt (4).
Sobald das ausgefallene System wieder aktiv ist, werden lediglich die Änderungen mittels Protokoll nachgezogen, um den Spiegel schnellstmöglich wieder zu aktivieren. Ein weiteres Feature von DataCore ist SANmotion, das eine transparente Migration von Daten zwischen zwei Platten oder Storage-Systemen ermöglicht, um z. B. neue Plattensysteme ohne Ausfall zu integrieren. Darüber hinaus bietet DataCore den Transporter an, der die Migration von physischen Windows-Systemen in die virtuelle Infrastruktur wie P2V ermöglicht, ebenso das V2V bzw. V2P. Last but not least ist die Implementierung von CDP (Continuous Data Protection) möglich, die die höchste Form der Wiederherstellungsmöglichkeiten darstellt. Kennen Sie das Problem, dass eine wichtige LUN durch eine automatische unbeaufsichtigte Installation überschrieben wurde? DataCore löst diese Situation mit einem tertiären synchronen Spiegel und der Option von Konsistenz-Markern, und Sie können abhängig von der verfügbaren Plattenkapazität mehrere Tage auf einen beliebigen Zustand in diesem Zeitraum zurückwechseln. Auf Kommandozeilenebene springen Sie mit CDP bis auf einen bestimmten gewünschten I/O zurück und erstellen sich daraus ein sogenanntes Business Continuity Volume (BCV). Wurde beispielsweise am 20.10.09 um 15:45 Uhr ein Problem in der Datenbank festgestellt, das um 15:40 entstand, so könnten Sie mittels CDP (Traveller CPR) auf die Daten von 15:35 Uhr zurückwechseln. Im Endeffekt wird das BCV zurück an den Anwendungs-Server verbunden, so dass dieser beispielsweise kein zeitraubendes Datenbank-Log-Replay durchführen muss. Schaut man sich CDP im Vergleich zu den Möglichkeiten von Backups oder Snapshots an, sähe dies wie folgt aus:
582
Storage-Virtualisierung
Technologie
Traveller CPR Snapshot Backup 24 Stunden Gestern (Full Backup)
Abbildung 10.54
Letzte Nacht (Incremental Backup)
Jetzt
CDP vs. Snapshots vs. Backup
Backup 왘
zeitlich weit voneinander entfernte und wenige Restore-Punkte
왘
Beeinflussung der laufenden IT und Verfügbarkeiten (langsames Backup und Restore)
왘
kein Mehrwert bis zum Restore-Fall
Snapshot 왘
zeitlich näher zusammenliegende, aber immer noch limitierte Restore-Punkte
왘
Beeinflussung des Produktionsablaufs (Datenbank-Stop, Buffer-Flushing, Snapshotting)
왘
eingeschränkter Nutzen wegen limitierter Anzahl von Restore-Punkten
Traveller CPR 왘
jeder Restore-Punkt möglich durch »Continuous Protection« und »Continuous Recovery«
왘
keinerlei Beeinflussung der laufenden Produktion, weder in Performance noch in Kapazität
왘
unzählige Einsatzmöglichkeiten der unabhängigen »MakeTime Volumes«
Sämtliche Verwaltung wird über einheitliche Konsolen (Microsoft MMC bei SANmelody, Windows-Applikation bei SANSymphony) realisiert, die mehrere Storage-Systeme gleichzeitig verwalten kann.
Abbildung 10.55
DataCore SANcentral Management
583
10.2
10
Hersteller-Best-Practices
Ein wesentlicher Aspekt bei den Verwaltungsmöglichkeiten ist auch die direkte Integration der Performance-Überwachung, was auch das Troubleshooting bei Performance-Problemen vereinfacht. In diesem Zusammenhang bietet DataCore das SANmaestro als Erweiterung an zur Trendanalyse und als Vorstufe des Billing-Prozesses zur Berechnung von Speicher auf Basis von Kostenstellen.
Abbildung 10.56
DataCore-Virtual-Storage-Plug-in für vCenter
Seit einiger Zeit ist auch das Virtual-Storage-Plug-in von DataCore für VMware verfügbar, das DataCore-Kunden auf der Download-Seite des Herstellers finden. Als kleiner Blick über den Tellerrand sei erwähnt, dass DataCore ein Snap-in für StorageLink als Bestandteil der Citrix Essentials anbietet. Damit lässt sich für Hyper-V und XenServer gleichermaßen der Speicher beim Erstellen von VMs gleich direkt mitkonfigurieren. Die DataCore-Produkte sind daher echte Allrounder, und man findet für jegliche Anforderungen eine entsprechende Lösung für den Kunden, die überdies auch oft sehr kostengünstig ist. URL http://www.datacore.com/products/prod_SANmel_whitepapers.asp
584
Storage-Virtualisierung
10.2.6 HP LeftHand LeftHand Networks wurde 1999 gegründet und 2009 von Hewlett-Packard aufgekauft und in die Storageworks-Produktreihe integriert. Durch den sehr skalierbaren und kostengünstigen Ansatz eines »Grid«-Storage auf iSCSI-Basis konnte unter anderem eine Eingruppierung im berühmten Magic Quadrant von Gartner als Visionär erreicht werden. Seit der Version 6.6 SP1 wird vSphere offiziell von HP LeftHand unterstützt. Die vorherigen Versionen 6.5 und 6.6 werden nur mit den Patches 10004 bzw. 10005 unterstützt, haben jedoch Einschränkungen. Das Produkt mit dem Namen SAN/IQ bildet technisch gesehen einen Cluster von mehreren Storage-Systemen, um diese für die Außenwelt (Frontend, ESX-Hosts) als ein einziges Storage-System darzustellen. Dabei skaliert dieses System sehr gut und kann sowohl als Kleinstlösung als auch im Enterprise-Segment Verwendung finden. So ist eines der Referenzbeispiele der Einsatz von LeftHand bei der U. S. Army im Irak, wo nahezu hundert VSAs (Virtual Storage Appliance = SAN/IQ-Knoten) eingesetzt werden, um ausfallsicheren Storage in 23 verteilten Bunkern zu realisieren. Eine gute Planung ist auch hier eine Voraussetzung, da die Grid-Architektur auf iSCSI-Basis wesentliches Storage-, iSCSI- und Ethernet-Wissen erfordert. So erlaubt die Grid-Architektur eine sehr hohe Performance bereits durch 1 GBit über Ethernet, ohne auf 10 GBit umstellen zu müssen. Dieser Ansatz hat den großen Vorteil, dass Sie mehrere RAID-Controller, Netzwerkkarten, Systembusse und natürlich Festplatten zusammenfassen und deren Leistung bis auf einen gewissen Overhead sehr gut summieren können. Außerdem wird über die Systemverteilung eine sehr hohe Ausfallsicherheit hergestellt, da ein Netzwerk-RAID über alle Systeme gelegt wird. Daher sind verschiedene Stufen der Ausfallsicherheit möglich, die sich so erweitern lassen, dass die Funktionsfähigkeit auch nach Ausfall von mehreren Storage-Knoten immer noch gegeben ist. LeftHand installieren Sie entweder auf Standard-Servern, die über lokalen Massenspeicher verfügen, oder betreiben es als virtuelle Maschine, um Massenspeicher zentral bereitzustellen. Oft wird LeftHand auch als Appliance eingesetzt, um den lokalen Speicher mehrerer ESX-Server als zentralen Massenspeicher zu nutzen. Derzeit wird nur DAS (Direct-attached Storage), also lokaler Massenspeicher, offiziell unterstützt, wodurch ein MSA 2000 oder ein EVA nicht verwendet werden kann. Dies wird sich allerdings im Laufe des Jahres 2010 ändern.
585
10.2
10
Hersteller-Best-Practices
Abbildung 10.57
LeftHand zur zentralen Nutzung des lokalen ESX Storage
Diese sehr kostengünstige und trotzdem effiziente Lösung bietet Performance und Ausfallsicherheit über die Grid-Architektur und macht aus lokalem Storage VMotion/HA-, DRS-fähiges IP-SAN. Um LeftHand zu testen, bietet die HP-Website eine kostenlose Testversion, die sie sehr einfach in vSphere importieren und direkt nutzen können.
Abbildung 10.58 Beispielaufbau einer HP-LeftHand-Lösung mit mehreren Storage-SAN/IQKnoten und ESX-Servern
586
Storage-Virtualisierung
Egal, wie viele Storage-Knoten im SAN/IQ genutzt werden, für den ESX-Host und die virtuellen Maschinen stellt sich der Storage immer als ein einzelnes System mit redundanten Ethernet-Anschlüssen dar. Dass die Daten auf verschiedenen Knoten verteilt sind, weiß der ESX-Server nicht. Wie alle beschriebenen Storage-Virtualisierungs-Plattformen bringt auch LeftHand »dummen« Speicher mit Snapshot-, Thin-Provisioning- und Replizierfunktionalität mit geringem Kostenaufwand zu enormem Funktionsumfang. Sämtliche Funktionen werden unabhängig von der Anzahl der LeftHand-StorageKnoten über eine zentrale Windows-Verwaltungskonsole integriert und konfiguriert. Die Storage-Knoten selbst laufen jedoch autonom weiter, so dass auch ein Ausfall der Managementkonsole keine Funktionen beeinträchtigt.
Abbildung 10.59
LeftHand-Verwaltungskonsole – Use Summary-Ansicht
Dabei wird das Managementnetzwerk nicht vom Storage-Netzwerk getrennt, daher muss ein Administrations-PC Zugriff zum Storage-Netzwerk haben. LeftHand war auch einer der ersten Storage-Anbieter, der eine Integration in die VMware-SRM-(Site Recovery Manager-)Software anbot. Unter den Funktionen finden Sie auch Smart-Clone-Volumes, die eine einfache Duplizierung der LUNs ermöglicht und weiteren Plattenplatz nur für die Änderungsdaten der angeschlossenen Systeme benötigt. Dies ist vor allem in Test- und Entwicklungsumgebungen sowie bei der Desktop-Virtualisierung von großem Vorteil.
587
10.2
10
Hersteller-Best-Practices
Bezüglich des Cachings verhält sich das LeftHand-System wie folgt: Die I/O-Bestätigung wird ausgegeben, sobald der Block im Cache des batteriegesicherten RAID-Controllers geschrieben wurde, bevor der I/O auf die Platte durchgeschrieben wird. Lesend werden stark frequentierte Daten in den Cache geholt. Der Memory der Knoten wird allerdings nicht zum Caching genutzt. Die Ausfallsicherheit wird im Normalfall auch rechenzentrumsübergreifend realisiert, das heißt, ein oder mehrere Storage-Knoten sind in Rechenzentrum 1 und ein oder mehrere in Rechenzentrum 2. Die Replikation findet auf Blockebene zwischen den Rechenzentren und den Knoten statt. SAN/IQ bietet die Möglichkeit eines transparenten Failovers für die angeschlossenen Server-Systeme, das heißt, trotz des Ausfalls eines Storage-Systems übernimmt das noch laufende System dessen Funktion, ohne dass die Server-Systeme ausfallen. Werden nur zwei SAN/IQ-VSA-Systeme eingesetzt, muss entweder ein manueller Failover stattfinden oder der kostenlose FOM (Failover Manager) auf einem dritten System installiert werden, da es sich für die Storage-Systeme um eine SplitBrain-Situation handeln könnte. Sobald drei oder mehr VSA-Systeme im Einsatz sind, wird der Ausfall automatisch erkannt und abgefangen. Wie bei allen ethernet-basierten Storage-Lösungen sollte entweder eine physische oder eine logische (VLAN-)Trennung zwischen dem Produktiv- und dem Speichernetzwerk stattfinden. Diese sollten Sie natürlich immer redundant auslegen. Trotzdem ist die physische Trennung zu bevorzugen. Falls dies nicht möglich ist, ist es empfehlenswert, auf port-based VLANs zu setzen und nicht auf VLAN-Tagging. Dabei müssen Sie immer darauf achten, dass es sich um Non-Blocking-EthernetSwitches handelt, da es sonst zu deutlichen Leistungsengpässen kommen kann, weil die schmale Backplane die Frontend-Geschwindigkeit ausgebremst. Außerdem sollten Sie auf den Switches die Ethernet-Flow-Control aktivieren, die die Pakete pausiert, falls die Systeme mit unterschiedlicher Geschwindigkeit die Pakete bearbeiten. Die Verwendung von Jumbo-Frames ist ebenfalls möglich, allerdings müssen Sie dabei dafür sorgen, dass alle Geräte zwischen den kommunizierenden Endpunkten und die Systeme selbst (ESX, Storage) Jumbo-Frames unterstützten. Dies ist mit ESX 4 und SAN/IQ der Fall, und Sie können die MTU-Größe auf 9.000 Bytes erhöhen. Damit werden weniger Header-Informationen ausgetauscht, was die Leistung bei großen I/O-Vorgängen um 10–15 % erhöhen kann.
588
Storage-Virtualisierung
Abbildung 10.60
LeftHand-SAN/IQ-Bonding von Netzwerkkarten
Mittels Link-Aggregation, also der Bündelung der GBit-Schnittstellen, lässt sich die Bandbreite weiter erhöhen. Bonding von Netzwerkkarten wird von SAN/IQ unterstützt und führt zu erhöhter Performance und Ausfallsicherheit. Nun ist natürlich auch interessant, wie die Daten in der Grid-Struktur gelesen und geschrieben werden, die SAN/IQ über viele Knoten hinweg realisiert. Da aufgrund der Redundanz die Daten immer mehrfach vorliegen, kann jeder Knoten lesend auf die Daten zugreifen, allerdings ist einer dieser Knoten der Eigner, das alleinig schreiben darf. Wegen der Nutzung des iSCSI-Portals ist es derzeit bei der Verwendung von VMware ESX eher zufällig, wenn der Dateneigner gleichzeitig auch der primäre Knoten im SAN/IQ ist. Wenn dies nicht der Fall ist, leitet der primäre Knoten die Anfrage an den Dateneigner weiter, was natürlich keine Idealleistung bringt. Daher unterstützt LeftHand eine sehr interessante Form des MPIO (Multipathing), das mehrere Pfade im iSCSI-Umfeld gleichzeitig nutzen kann und darüber hinaus weiß, welches System die Daten hält. Dies ist in der LeftHand-Architektur sehr sinnvoll und bringt wesentliche Leistungsvorteile, da direkt der StorageKnoten angesprochen werden kann, der die Daten hält, womit ein Weiterleiten entfällt. Während eine Unterstützung für diese Form des Zugriffs bereits für Windows- und Linux-Betriebssysteme verfügbar ist, wird HP eine Implementierung für VMware voraussichtlich im ersten Quartal 2010 als PSA-Modul veröffentlichen.
589
10.2
10
Hersteller-Best-Practices
URL Auf der VMware-Website sind verschiedene Dokumentationen und Whitepapers zu finden. Eines dieser Dokumente beschäftigt sich auch mit vSphere und LeftHand: http://h20195.www2.hp.com/v2/GetDocument.aspx?docname=4AA30261ENW&doctype=white%20paper&doclang=EN_US&searchquery=vmware%20storage%20&cc=uk&lc=en
10.2.7 FalconStor Software Das Unternehmen FalconStor ist eines der bekanntesten und erfahrensten im Storage-Virtualisierungs-Markt und hat technologisch in vielen Funktionen die Nase vorn, u. a. mit dem Application Snapshot Director. Einer der direkten Konkurrenten ist mitunter DataCore, der in diesem Kapitel bereits erläutert wurde. Allerdings hat FalconStor wohl eher im gehobenen Mittelfeld und im EnterpriseSegment hohe Marktanteile, während DataCore hauptsächlich im Mittelstand bzw. generell im SMB-Markt punktet. Der IPStor ist die Plattform von FalconStor für alle Produkte und bringt auf Basis eines Linux-Systems eine Storage-Virtualisierung, die über eine eigene Hardware- oder virtuelle Appliance oder über Standard-Industrie-Server realisiert werden kann. Weitere Produkte auf dieser Basis sind VTL (Virtual Tape Library), CDP (Continuous Data Protection) und FDS (File-Interface Deduplication System). Die Appliances werden als NSS (Network Storage Server) bezeichnet. Zum Betrieb der NSS ist es wichtig, die Leistungsfähigkeit der Systembusse in der Appliance und die benötigte Anzahl der Frontend- und Backend-Ports vor der Implementierung zu beachten und entsprechend zu planen. Die Größe des Hauptspeichers ist im Gegensatz zur DataCore-Lösung wenig relevant, da NSS nicht selbst cacht, sondern die Caching-Möglichkeiten der StorageSysteme oder externer Devices (z. B. SSD) nutzt. Dadurch muss auch nur die Queue und kein große Cache zwischen ausfallsicheren NSS-Appliances übertragen werden. Setzen Sie die NSS als virtuelle Appliance ein, so können Sie beliebige vmdkDateien oder Raw-Device-Mappings einbinden, um den Storage virtuell bereitzustellen. Damit ist es auch möglich, den lokalen Festplattenspeicher der ESX-Server zu nutzen, um diesen mittels Vervielfachung der Appliances ausfallsicher und zentral zu machen und so VMotion, DRS oder HA zu realisieren. Die Nutzung von VMDirectPath I/O erlaubt seit vSphere sehr hohe Netzwerkund Storage-Leistung in VMs, was der NSS-Lösung zugutekommt.
590
Storage-Virtualisierung
Abbildung 10.61 Ausfallsichere IPStor-Lösung von FalconStor mit zwei NSS-Appliances, Außenstellen-Replikation und Backup-Integration
Dedicated Storage Virtualization I/O Ports
ESX-Server
NSS Virtual Appliance
Virtual Machine
Virtual Machine
Virtualization Layer
Port3
Port1
Port 2
…
Port4
Direct FC/iSCSI Storage Service for VMs
SAN Switch Fiber Channel or iSCSI
Abbildung 10.62 Beispiel FalconStor-NSS-Appliance mit direkter Nutzung der FC- oder iSCSI-HBAs mittels VMDirectPath I/O
Generell ist es auch mit FalconStor möglich, »dumme« Storage-Systeme in leistungsfähige und funktionsreiche Storage-Systeme zu verwandeln. Durch die Zertifizierung der FalconStor-NSS-Lösung mit VMware-SRM können Sie außerdem jedes Storage-System SRM-kompatibel machen.
591
10.2
10
Hersteller-Best-Practices
Wesentlich häufiger findet man die NSS-Systeme allerdings als physische Appliances, die mit entsprechend performanter Anbindung im Backend an leistungsfähige Storage-Systeme angeschlossen werden. So ist es keine Seltenheit, Systeme wie HP EVA, Pillar Axiom, EMC CX etc. oder sogar Enterprise-Systeme wie EMC DMX im Backend von FalconStor zu finden. Durch die Möglichkeit der StorageVirtualisierung, beliebige Storage-Plattformen im Backend miteinander zu mischen, wird dies auch gerne umgesetzt, indem eine günstigere Plattform im Backup-Rechenzentrum realisiert wird. 4: Power On
3: Register, Reconfigure
VMware Virtual Center with SRM
VMware Virtual Center with SRM
1: Environment Scan
2: Replicated back
Remote Site
Production Site
Abbildung 10.63
FalconStor-SRM-Failback-Plug-in
Man merkt der Produktpalette von FalconStor auch deutlich an, dass das Unternehmen sich im Server-Virtualisierungsmarkt wohlfühlt, da viele Lösungen exakt auf diese Umgebungen abgestimmt sind. Diese beginnen im Kleinen mit Erweiterungen des VMware-Clients durch Plug-ins für SRM (Failback-Plug-in) oder einem Plug-in zur Storage-Verwaltung (Virtual Storage Management), das u. a. eine automatisierte Erstellung von Storage und VMs erlaubt. FalconStor bietet natürlich auch die synchrone und asynchrone Replikation an und hat diese auch auf kleinere Bandbreiten optimiert. Allerdings adressierte FalconStor auch das Thema CDP (Continuous Data Protection) bereits sehr früh im Markt, das mit konsistenten Snapshots und Replikation dem Administrator die Möglichkeit bietet, in einem angegebenen Zeitraum der Vergangenheit zu jedem beliebigen Datenzustand zurückzukehren. Dies geht bis auf den einzelnen Schreib-I/O zurück, was eine enorme Datensicherheit gewährleistet.
592
Storage-Virtualisierung
Abbildung 10.64
FalconStor-Plug-in im vSphere-Client
Außerdem erlaubt FalconStor als eines der wenigen Storage-Produkte einen transparenten Failover, der bei Ausfall eines Storage-Systems selbständig auf das noch aktive umschaltet, ohne dass es zu Datenverlust oder Dienstausfall im Frontend (z. B. ESX-Hosts und VMs) kommt. Data Paths
VMware ESXServer
Abbildung 10.65
VMware ESXServer
VMware ESXServer
Backup Apps
FalconStor-Deduplication mittels FDS Virtual Appliance
593
10.2
10
Hersteller-Best-Practices
Auch im Bereich der Datendeduplizierung bietet FalconStor mit FDS eine Lösung, die sich auch als virtuelle Maschine betreiben lässt, um unnötige Datenredundanz effizient zu minimieren. Generell unternimmt FalconStor viel, um das sehr »anstrengende« Thema Backup und Restore im Virtualisierungsumfeld zu vereinfachen. Dazu gehört das Produkt FalconStor HyperTrac, das eine Erweiterung für VMware Consolidated Backup darstellt. Die Idee hinter diesem Produkt ist es, die Sicherung komplett aus der produktiven ESX-Farm auszulagern. Zur Erinnerung: VCB als Einzelprodukt ist nach wie vor auf Aktivitäten auf dem ESX-Host-System angewiesen.
Abbildung 10.66
VCB-Sicherung mittels FalconStor HyperTrac
HyperTrac nutzt die Snapshot-Technologie der NSS-Appliances, um die zu sichernden Daten (VMware-Konfigurations- und Festplattendaten) einem Standby-
594
Storage-Virtualisierung
ESX-Host bereitzustellen. Dieser dient nur der Sicherung der virtuellen Maschinen mittels VCB. Damit wird eine Anlage von Snapshots in der produktiven VMware-Infrastruktur mit entsprechendem Datenwachstum (Delta-Dateien) während der Sicherung komplett überflüssig. Durch die Auslagerung der Sicherungen auf eine eigene »Backup«-ESX-Infrastruktur ist VCB wesentlich skalierbarer. Ein weiteres Highlight – das zusätzliche Lizenzen erfordert – ist der Application Snapshot Director. Er bietet eine einzigartige Möglichkeit, die Sicherungen der virtuellen Maschinen storage-unabhängig mittels konsistenter Storage-Snapshots zu realisieren. Dabei werden Agenten in den Gästen verwendet, die neben dem Betriebssystem auch viele Applikationen in einen Sicherungsmodus versetzen können (z. B. Oracle, SQL, Exchange), um danach einen Snapshot der VM und der darunterliegenden LUN anzulegen. Natürlich wird entsprechender Festplattenplatz vorausgesetzt, allerdings ist dies eine der durchdachtesten Lösungen im Storage/VMwareUmfeld. Der Application Snapshot Director geht so weit, dass Sie auch Application Storage Groups erstellen können, da manche Systeme über mehrere LUNs verstreut sind oder Systeme, die miteinander kommunizieren, vorhanden sind. So ist es beispielsweise sinnvoll, den Datenbank-Server mit dem darauf aufsetzenden Applikations-Server zu sichern, damit die Gesamtinfrastruktur konsistent gesichert ist und keine unterschiedlichen Datenstände aufgrund der unterschiedlichen Sicherungszeiten entstanden sind. Wichtig bei der Integration der FalconStor-NSS Ein wichtiger Tipp in Zusammenhang mit FalconStor NSS, der allerdings auch manch andere Storage-Plattform betrifft, ist in vSphere-Umgebungen anzuwenden. Vielen Dank an Axel Rosenberg! Wenn Sie die einschlägigen Foren zu vSphere 4 durchforsten, dann sehen Sie, dass bereits viele Konstellation von Server/Hardware und Storage-Modell durch Probleme mit nicht mehr bootenden ESX-Servern oder nicht mehr enden wollenden HBA-PathFailovers auffällig geworden sind. Folgendes sollten Sie daher bei der Integration der FalconStor-NSS mit vSphere beachten: 왘
Es muss eine LUN 0 von NSS an ESX gemappt werden.
왘
Es muss mindestens der Patch 40 (und alle anderen darunter) installiert sein.
왘
Nehmen Sie in /usr/local/ipstor/etc/fshba.conf folgenden Eintrag vor: reply_invalid_device=48
595
10.2
10
Hersteller-Best-Practices
10.2.8 Emulex Das Unternehmen Emulex ist einer der Marktführer im FibreChannel HBA Segment und wird sehr gerne im VMware Umfeld eingesetzt. In der HCL (www.vmware.com/go/hcl) können Sie sich die unterstützten HBA Typen heraus suchen. Es kann passieren, dass Sie aufgrund der SAN Infrastruktur bestimmte Parameter der Emulex HBA Treiber anpassen müssen, um beispielsweise die Timeoutwerte oder die Queue-Depth zu verändern. Die Treiber beginnen immer mit lpfc, z. B. lpfc820 oder lpfcdd. Dies ist über die Kommandozeile (esxcfg-module) oder über die PowerCLI (GetVMHostModule/Get-VMHostModule) möglich. Soll zum Beispiel die Queue Depth des LPFC820 Treiber (kann mit esxcfgmodule –l ausgelesen werden) auf 20 angepasst werden, so lautet der Befehl: esxcfg-module –s lpfc_lun_queue_depth = 20 lpfc820
Zum Auslesen der Optionen nutzen Sie den Befehl esxcfg-module –g lpfc820, und die Optionen können mit esxcfg-module –s lpfc820 entfernen. Danach müssen Sie den Befehl esxcfg-boot –b ausführen und einen Reboot durchführen. Die genauen Werte für die HBA Einstellungen müssen an die genutzte Infrastruktur angepasst werden, da diese von der Anzahl der LUNs und der Queue Depth der Storage Controller abhängig sind. Ein sehr gutes Dokument von Emulex, in dem auch die Installation des Emulex HBAnywhere zur Konfiguration der HBAs beschrieben ist, finden Sie unter diesem Link: http://www-dl.emulex.com/support/vmware/8203049vmw/vmware.pdf Ist die vMA Appliance oder die RCLI installiert lautet der Befehl: vicfg-module -s lpfc_lun_queue_depth = 20 lpfc820
10.2.9 QLogic Das Unternehmen QLogic ist im FibreChannel und iSCSI HBA Segment bekannt und ist wie Emulex sehr häufig im VMware-Umfeld anzutreffen. In der HCL (www.vmware.com/go/hcl) können Sie die unterstützten HBA Typen heraus suchen.
596
Storage-Virtualisierung
QLogic hat derzeit kein Supportdokument zur Beschreibung des Treibers unter vSphere, allerdings greifen nach wie vor die gleichen Befehle wie unter ESX 3.5. Dies ist über die Kommandozeile (esxcfg-module) oder über die PowerCLI (GetVMHostModule/Get-VMHostModule) möglich. Soll beispielsweise die Queue Depth des QLA2xxx Treiber (kann mit esxcfgmodule –l ausgelesen werden) auf 64 angepasst werden, so lautet der Befehl: esxcfg-module –s ql2xmaxqdepth = 64qla2xxx
Zum Auslesen der Optionen nutzen Sie den Befehl esxcfg-module –g qla2xxx, und die Optionen können Sie mit esxcfg-module –s qla2xxx entfernen. Danach muss der Befehl esxcfg-boot –b gefolgt von einem Reboot ausgeführt werden. Sollte der HBA Treiber danach nicht erfolgreich geladen werden, was das NichtErscheinen der LUNs zur Folge hat, so hat sich das nochmalige Ausführen der vorherigen Kommandos als erfolgreich herausgestellt. Es ist derzeit unklar, warum es manchmal zum falschen Zurückschreiben der Treiberoptionen kommt, ein erneutes Setzen der Parameter löste das Problem bisher.
597
10.2
Die Konfiguration der Virtual Infrastructure 4 kann sehr umfassend und komplex sein. Es gibt viele Punkte, die Sie konfigurieren können oder müssen, um einen reibungslosen Betrieb zu gewährleisten. Auf diese Punkte gehen wir in diesem Kapitel ein.
11
Konfiguration von ESX und vCenter Autor dieses Kapitels ist Betram Wöhrmann, Ligarion, [email protected]
Die gesamte Infrastruktur umfasst nicht nur den vSphere-Host und den vCenterServer, sondern auch zusätzliche Komponenten. Bei der Konfiguration müssen Sie auch andere Komponenten wie zum Beispiel den Lizenz-Server oder den NTP-Server beachten. Auf den folgenden Seiten gehen wir näher auf die verschiedenen Komponenten sowie die Konfiguration der Virtual Infrastructure 4 ein. Für die eigentlichen Konfigurationsarbeiten können Sie entweder die Service Console oder den vSphere-Client nutzen. Nicht immer stehen unterschiedliche Möglichkeiten für ein und dieselbe Konfiguration zur Verfügung. Es gibt Arbeiten, die sich nur über die Service Console durchführen lassen. Bei der Nutzung des vSphere-Clients kann die Verbindung direkt zum Host oder zum vCenter erfolgen. An dieser Stelle möchten wir nicht alle Konfigurationsmöglichkeiten abarbeiten, sondern das Ganze themenorientiert durchführen. Die Themen Storage und Netzwerk werden in eigenen Kapiteln beschrieben.
11.1
Host-Profiles
Mit Version 4 der VMware Virtual Infrastructure hat VMware ein neues Feature eingeführt. Es handelt sich um die Host-Profiles. Sie erleichtern die Konfiguration einer Farm von vSphere-Servern. Dadurch ist es möglich, die Konfiguration eines Hosts auf verschiedene andere Hosts zu übertragen und somit identische Systeme zu erhalten. Es ist nicht mehr nötig, die Konfiguration auf jedem Host einzeln und manuell vorzunehmen. Das spart Zeit, und die Fehleranfälligkeit sinkt. In der Vorgänger-
599
11
Konfiguration von ESX und vCenter
version von vSphere musste bei der Konfiguration von zehn Hosts jeder einzelne Host angefasst werden. Dabei kam es schnell einmal zu Fehlern, wenn z. B. mal eben ein neues virtuelles Netzwerk eingerichtet werden musste. Dies störte nicht nur den Betrieb erheblich, sondern konnte auch dazu führen, dass nicht alle Funktionen in der virtuellen Infrastruktur zur Verfügung standen. Durch das einmalige Erstellen eines Host-Profiles und das Verteilen auf die einzelnen Server ist eine schnelle und sichere Konfiguration einer vSphere-Farm möglich. Das Erstellen und Verteilen dieser Host-Profiles wird im Folgenden näher beschrieben. Als Erstes müssen Sie ein Host-Profile von einem fertig konfigurierten Host im System anlegen oder ein bestehendes importieren. Auf der Management-Seite des vSphere-Clients oder über das Menü rufen Sie das Fenster für die Host Profiles auf (Abbildung 11.1). Im Fenster der Host-Profiles können Sie Profile erstellen, löschen und editieren. Außerdem ist es möglich, vorhandene Cluster und ESX-Hosts mit einem Profil zu verknüpfen.
Abbildung 11.1
Aufruf der Host-Profiles-Konfigurationsseite
Das Verknüpfen der Cluster oder vSphere-Hosts mit einem Host-Profile ähnelt dem Verbinden mit Policies für den VMware Update Manager. Sind Hosts mit einem Profil verbunden, können Sie die Hosts auf Konformität prüfen und die Profile auf die Hosts übertragen. Auch wenn Host-Profiles die Konfiguration eines Hosts sehr erleichtern, kommen Sie um die eigentliche Konfiguration eines Hosts nicht herum. Auf den nächsten Seiten nehmen wir die Konfigurationen vor.
600
Host-Profiles
Wichtig Es gibt einige wenige Einstellungen, die nicht in die Host-Profiles einfließen. Darunter fallen im Bereich Storage die iSCSI-HBAs und deren Targets sowie die MultipathingEinstellungen für die Anbindung der LUNs. Storage, der über die Pluggable Storage Architecture angebunden wird, wird ebenfalls nicht berücksichtigt. Im Netzwerkbereich werden die Konfigurationen für IPV6, statische IP-Routen und die Zuordnung von physischen Netzwerkkarten über die PCI-Reihenfolge zu virtuellen Switches nicht gespeichert. Auch die administrativen Passwörter der Hosts und die UUID werden nicht übernommen.
Hinweis In einem Profil werden nur die Werte gesetzt, die vom Standard abweichen. Wird also eine einmal veränderte Einstellung wieder zurückgesetzt, kann sie mit dem Profil nicht auf andere Systeme ausgerollt werden, weil der Wert nur aus dem Profil gelöscht wird.
11.1.1
Erstellen eines Host-Profiles
Das Erstellen eines Host-Profiles ist denkbar einfach. Es werden keine Einstellungen oder Ähnliches in einer Konfigurationsdatei editiert. Zuerst konfigurieren Sie einen vSphere-Host komplett so durch, wie er produktiv zum Einsatz kommen soll. So parametrieren Sie zum Beispiel die Einstellungen für das Netzwerk. Als Beispiel werden drei virtuelle Switches erstellt und mit physischen Netzwerkkarten verbunden und Service Console, Fault-Tolerance und VMotion konfiguriert. Damit diese Einstellungen jetzt auch auf die anderen Hosts übertragen werden, muss lediglich ein Profil von diesem Host erstellt werden. Ebenso ist es möglich, ein Profil zu importieren. Dateien mit der Endung .vpf sind die beschriebenen Profildateien für VMware-Hosts. Die Profile werden automatisch in der Datenbank gespeichert. Über den Weg des Exports erhalten Sie eine Datei. So ist es zum Beispiel möglich, eine Datei zu erstellen, um diese dann beim Kunden zu nutzen oder dem Kunden zu schicken. Das Einzige, was Sie nach dem Einspielen noch anpassen müssen, ist die IP-Adresse. Sieht der Inhalt der Datei in der Oberfläche des vCenters noch recht lesbar aus (Abbildung 11.2), so ist der Inhalt der abgespeicherten XML-Datei aufgrund fehlender Umbrüche sehr schwer lesbar. Neben den Daten zu der Profildatei finden sich im Summary im Klartext einige Konfigurationsteile. An dieser Stelle lässt sich das Profil exportieren oder auch editieren.
601
11.1
11
Konfiguration von ESX und vCenter
Abbildung 11.2
11.1.2
Profildatei eines vSphere-Hosts
Anpassen eines Host-Profiles
Haben Sie ein Profil einmal mit einem primären Host erstellt, ist es auch nachträglich möglich, das Profil Ihren Bedürfnissen anzupassen. Dazu starten Sie den Editiermodus über das Kontextmenü des entsprechenden Profils. Es öffnet sich ein Fenster, das wesentlich mehr offenbart als das Summary-Fenster (Abbildung 11.3).
Abbildung 11.3
602
Editor für Host-Profiles
Host-Profiles
Auch können Sie hier angeben, welche Einstellungen Host-individuell sind und damit beim Verteilen des profils auf einen neuen Host via Aufforderung angepasst werden müssen. Sind die Anpassungsarbeiten beendet, schließen Sie das Fenster mit OK und können mit dem Profil arbeiten.
11.1.3
Host/Cluster mit Profil assoziieren
Nachdem ein Host-Profile erstellt wurde, kann es noch nicht mit einem Host assoziiert werden. Dafür müssen Sie als Erstes den Cluster oder den Host mit dem Profil verbinden. Wählen Sie im Fenster das Profil aus, um über den Button Attach Host/Cluster Maschinen mit dem Profil zu assoziieren (Abbildung 11.4).
Abbildung 11.4
Binden von vSphere-Servern an ein Profil
Wenn alle Maschinen hinzugefügt wurden, erscheinen diese im Profil unter dem Reiter Hosts and Clusters. Hier ist es ebenfalls möglich, die Host-Profile auf die Maschinen zu übertragen und die nötigen Einstellungen vorzunehmen. Durch das Auswählen eines Servers in diesem Menü ist es möglich zu prüfen, ob der Host nach den Vorgaben des Host-Profiles richtig konfiguriert ist. In diesem Fall hat noch kein Test der Host-Konfiguration stattgefunden. Dies erfolgt erst durch die Aktivierung von Check Compliance Now.
Abbildung 11.5
Ergebnis der Compliance-Prüfung
603
11.1
11
Konfiguration von ESX und vCenter
Sollte der Host nicht compliant sein (Abbildung 11.5), fahren Sie ihn in den Maintenance-Modus und wenden das Profil an.
11.1.4
Anwenden eines Host-Profiles
Das Anwenden eines Host-Profiles auf einen Host ist nur dann möglich, wenn dieser im Maintenance-Mode ist. Ist ein geprüfter Host nicht compliant, können Sie ein Profil anwenden. Dafür müssen Sie, wie bereits erwähnt, den Host in den Maintenance-Mode fahren. In Abbildung 11.5 ist ein Host zu sehen, der nicht richtig konfiguriert ist. Wird der Host markiert, zeigt das darunterliegende Fenster an, welche Fehlkonfiguration vorliegt. So sehen Sie, welche Änderungen an der Host-Konfiguration vorgenommen werden. Der erste in der Abbildung gelistete Host ist compliant. Jetzt binden Sie das Profil auf den zweiten Host. Ist dieser nicht im MaintenanceMode, erscheint direkt eine Fehlermeldung. Über das Kontextmenü können Sie den Host in den Maintenance-Modus fahren, um im folgenden Schritt das Profil zuzuweisen. Je nachdem, welche Probleme beim Konfigurationscheck aufgetreten sind, öffnet sich entweder ein Fenster, das anzeigt, welche Änderungen durchgeführt werden (Abbildung 11.6), und Sie können den Vorgang starten, oder Sie erhalten die Möglichkeit, Konfigurationsfehler zu beheben. Bestünde z. B. die Gefahr, dass zwei Systeme mit identischer IP-Adresse im Netzwerk stehen, könnten Sie in dem folgenden Dialog die Adresse ändern.
Abbildung 11.6
Zusammenfassung vor Änderungen
Sobald Sie alle Einstellungen vorgenommen haben, wird die Konfiguration aktualisiert. In den Recent Tasks des vCenters erkennen Sie nun den jeweiligen Task dazu (Abbildung 11.7).
Abbildung 11.7
604
Host-Profiles in den Recent Tasks
NTP
Durch das Verwenden von Host-Profiles wird das Durchführen und Prüfen von Konfigurationsänderungen in großen Umgebungen nicht nur sehr viel einfacher, sondern auch wesentlich weniger fehleranfällig.
11.2
NTP
Das Network Time Protocol (NTP) ist ein Standard zur Synchronisierung der Uhrzeit über das Netzwerk. Diese simpel klingende, aber sehr kritische Funktion sollten Sie unter allen Umständen konfigurieren. Eine Uhrzeit, die über alle Systeme im Netzwerk identisch ist, ist für den korrekten und reibungslosen Betrieb einer virtuellen Umgebung absolut notwendig! Es gibt verschiedene Möglichkeiten, NTP auf einem vSphere-Server zu konfigurieren. Für die Synchronisierung der Zeit der virtuellen Maschinen mit dem vSphere-Host können Sie die VMware Tools des Gastes verwenden. Dieses Thema behandeln wir in Abschnitt 11.2.3.
11.2.1
NTP-Dienst unter vSphere
Einer der besten Möglichkeiten ist die Konfiguration des NTP-Dienstes. Dazu müssen Sie die Datei /etc/ntp.conf mit einem oder mehreren NTP-Servern füllen, mit denen sich der vSphere-Server abgleichen kann. Sie sollten mindestens zwei NTP-Server einrichten. Fällt einer von beiden aus, besteht nicht die Gefahr, dass die Uhrzeit aus dem Ruder läuft. Bevor wir die Datei /etc/ntp.conf editieren, müssen wir die Firewall des ESXHosts anpassen. Mit dem Befehl esxcfg-firewall --enableService ntpClient wird die Firewall so eingestellt, dass ein NTP-Client, den wir hier verwenden, eine Verbindung mit einem NTP-Server aufbauen kann. Vergessen Sie aber nicht, unter Umständen mit den Kollegen der Netzwerkabteilung zu sprechen, damit der NTP-Request auch wirklich die NTP-Zielserver erreicht. Um die Datei zu editieren, öffnen Sie sie mit vi /etc/ntp.conf (oder einem anderen Editor). Passen Sie in dieser Datei die Zeilen # restrict mytrustedtimeserverip mask 255.255.255.255 nomodify notrap noquery # server mytrustedtimeserverip
an: Ersetzen Sie mytrustedtimeserverip durch einen vorhandenen NTP-Server, und kommentieren Sie die Zeilen ein, indem Sie jeweils das # entfernen. Ein Eintrag könnte dann wie folgt aussehen:
605
11.2
11
Konfiguration von ESX und vCenter
restrict 192.168.178.12 mask 255.255.255.255 nomodify notrap noquery server 192.168.178.12
Wenn Sie weitere Server oder mehrere NTP-Server eintragen möchten, kopieren Sie einfach die erste Zeile und passen den Eintrag für den weiteren NTP-Server an. So konfigurieren Sie eine Ausfallsicherheit für die NTP-Server. Die Datei /etc/ntp/step-tickers wird ebenfalls für die Zeitsynchronisation benötigt. Übernehmen Sie einfach die Einträge, die Sie bereits in der Datei ntp.conf eingepflegt haben. Eine Überprüfung, ob alle Einstellungen funktionieren und die Verbindung zum NTP-Server aufgebaut werden kann, lässt sich mit einem einfachen Befehl durchführen: Der Befehl ntpdate –q 192.168.178.12 fragt den NTP-Server ab. Mit dem Befehl date wird die aktuelle Zeit auf dem ESX-Host angezeigt. Wenn alles sauber eingepflegt und alle Server überprüft und konfiguriert wurden, können Sie den NTP-Service mit dem Befehl /etc/init.d/ntpd start starten oder mit restart den Dienst neu starten. Nach einem Neustart des ESX-Hosts würde allerdings dieser NTP-Client nicht mehr arbeiten. Dafür müssen Sie extra mit einem Befehl die Startprozedur anpassen: Mit chkconfig --level 345 ntpd on wird der Dienst beim Booten automatisch gestartet. Dieser Weg ist für einen ESXi-Host nicht möglich. Die Konfiguration ohne den vSphere-Client unter ESXi wird in Abschnitt 11.2.2, »NTP unter ESXi«, erläutert. Über den vSphere-Client gibt es ebenfalls eine Option. die NTP-Server zu konfigurieren. Es ist dabei unerheblich, ob Sie sich mit dem vCenter-Server oder mit dem Host direkt verbinden. Über den Reiter Configuration 폷 Time Configuration rufen Sie das Konfigurationsfenster auf (Abbildung 11.8). Hier rufen Sie mit dem Link Properties ein Fenster auf, in dem Sie alle Einstellungen vornehmen können. Über Options gelangen Sie in das Konfigurationsfenster, wo Sie wiederum über NTP Settings auf der linken Seite des Dialogfensters eine Eingabebox öffnen. Mit Add erreichen Sie wieder einen Eingabedialog für den NTP-Server. Sind die Server eingetragen, können Sie alle Dialogfenster schließen. Legen Sie den NTP-Server auf diese Art an, müssen Sie auch nicht mehr die Firewall anpassen – dies geschieht automatisch.
606
NTP
Abbildung 11.8
NTP-Konfiguration über den vSphere-Client
NTP in der Crontab Eine weitere Möglichkeit, die Zeit des ESX-Hosts zu synchronisieren, besteht mit Hilfe der Crontab. Dafür tragen Sie zum Beispiel die folgende Zeile in die Crontab ein: 0 * * * * root ntpdate -v 192.168.178.13 && hwclock --systohc
Diese Zeile bewirkt, dass zu jeder vollen Stunde die Zeit von einem NTP-Server geholt und direkt auf den vSphere-Host geschrieben wird. Der Nachteil an dieser Möglichkeit ist, dass die Zeit jede Stunde hart auf den vSphere-Host geschrieben wird. Dadurch sind eventuell Zeitsprünge möglich. Die Konfiguration des NTPClients dagegen synchronisiert die Zeit weich mit dem Host. Aus diesem Grund ist nach unserer Ansicht die Crontab-Variante nicht die bevorzugte.
11.2.2
NTP unter ESXi
Unter ESXi konfigurieren Sie NTP mit dem Befehl vicfg-ntp.pl des Remote Command Line Interfaces. Der Befehl vicfg-ntp.pl hat verschiedene Optionen, die in Tabelle 11.1 näher erläutert werden.
607
11.2
11
Konfiguration von ESX und vCenter
Optionen
Beschreibung
-a|--add
Name oder IP-Adresse des NTP-Servers, der hinzugefügt werden soll
-d|--delete
Name oder IP-Adresse des NTP-Servers, der entfernt werden soll
-l|--list
Zeigt alle verwendeten NTP-Server an
-h|--vihost
Angabe des zu benutzenden Hosts
Tabelle 11.1
11.2.3
Optionen des Befehls vicfg-ntp.pl
NTP in der virtuellen Maschine mittels VMware Tools
Es ist möglich, die Zeit des virtuellen Gastes mit der Zeit des VMware-vSphereHosts zu synchronisieren (Abbildung 11.9). Dabei spielen die VMware Tools im virtuellen Gastsystem eine entscheidende Rolle, sie müssen also installiert sein.
Abbildung 11.9
Aktivierung der Zeitsynchronisation für den Gast
Setzen Sie dazu in den Einstellungen einer virtuellen Maschine (Kontextmenü der VM 폷 Edit Settings) unter dem Reiter Optionen einen Haken an der Option Synchronize guest time with host. Nach dem Setzen des Hakens in der Checkbox werden die VMware Tools die Zeit mit dem vSphere-Host abgleichen und die Zeit des Gastes anpassen.
608
NTP
Wichtig Die Gastzeitsynchronisation der VMware Tools ist nur dafür ausgelegt, eine zu langsam laufende Uhr zur Zeitanpassung schneller laufen zu lassen. Die Tools können die Zeit nicht langsamer laufen lassen!
Verwenden Sie nicht parallel mehrere Möglichkeiten der Zeitsynchronisation. Gibt es bereits eine globale Unternehmenslösung zur Synchronisierung der Zeit, sollten Sie die virtuellen Maschinen ebenfalls entsprechend konfigurieren; in diesem Fall ist der Haken zu deaktivieren. Achten Sie auch darauf, dass Mitglieder einer Domäne ihre Zeit automatisch mit dem AD-Controller (Active Directory Server) synchronisieren. Auch in diesem Fall ist von einer Aktivierung der Checkbox Synchronize guest time with host abzusehen. Gerade in großen Umgebungen ist darauf zu achten, dass es einen definierten Prozess gibt, der beschreibt, wie mit dem Thema verfahren wird. Oft wird die Konfiguration der Gäste und der Hosts von unterschiedlichen Teams vorgenommen, was Fehlern Tür und Tor öffnet, wenn kein einheitliches Verfahren für die Zeitsynchronisation existiert.
11.2.4
Zeitsynchronisationsprobleme
So schön diese Funktionen sind und so simpel sich das Thema Zeitsynchronisation auch anhört, es gibt einige Tücken und Fallen, auf die Sie aufpassen müssen. Das Thema Zeit ist ein sehr wichtiges Thema in allen Netzwerken, aber vor allem bei der Verwendung von Verzeichnisdiensten. Warum soll die Zeit überhaupt synchronisiert werden, und worin liegt die Ursache, dass die Zeit aus dem Ruder laufen kann? Die Mechanismen, die VMware nutzt, um Ressourcen in der virtuellen Umgebung zu sparen, wirken sich auf die Timer im Gast aus. Benötigt der virtuelle Server keine Rechenzeit, erhält er auch keine. Damit bekommt auch der Zeitgeber keine Rechenzeit, und so läuft die Uhr im Gast unregelmäßig. Aber nicht nur bei hohen Idle-Zyklen gibt es Probleme, auch wenn ein Host am oberen Limit läuft, kann es problematisch werden, jeder VM genug CPU-Rechenzeit zu geben, damit der Timer richtig läuft. Der Timer kann sowohl zu schnell als auch zu langsam laufen. Ganz kritisch ist das Zurückstellen der Uhrzeit besonders dann, wenn Sie auf dem System Datenbanken betreiben. Die einzelnen Transaktionen verlieren ihre Reihenfolge, wenn die Zeit zurückgestellt wird. Das ist dann der Beginn aller Probleme.
609
11.2
11
Konfiguration von ESX und vCenter
Allgemeines Die Firma VMware hat die Probleme erkannt, die im Rahmen der Zeitsynchronisierung auftreten können. Aus diesem Grund gibt es eine zentrale Einstiegsseite auf der VMware-Website, die zu allen bekannten Artikeln zum Thema Zeitsynchronisation verzweigt. Sie finden den Link unter http://blogs.vmware.com/kb/ 2009/02/new-timekeeping-articles.html. Schlagen Sie hier nach, wenn Sie unsicher sind oder Probleme mit der Zeit in Ihrer Infrastruktur haben. Die Seite wird ständig aktualisiert; so haben Sie immer Zugriff auf die neuesten Dokumente zu diesem Thema. Zeitsynchronisation im Active Directory Der Verzeichnisdienst Active Directory ist, was die Uhrzeit angeht, hochkritisch. Die AD-Implementierung von Microsoft erlaubt standardmäßig eine maximale Zeitdifferenz von 5 Minuten für das Kerberos-Protokoll. Fast alle Dienste und Policies arbeiten mit sogenannten Timestamps. Bei der Migration von physischen Maschinen zu virtuellen Maschinen werden auch oft die Active-DirectoryServer (DCs = Domänen-Controller) migriert. Da diese Server das Herz eines Microsoft-Active-Directory-Netzwerks sind, ist für diese Maschinen meist ein NTPServer konfiguriert. Sollte dies der Fall sein, müssen Sie darauf achten, dass entweder die Active-Directory-Server die Zeitsynchronisation bestimmen oder die vSphere-Hosts die aktuelle Zeit holen und diese per VMware Tools an die Gäste geben. Sie dürfen auf keinen Fall beide Möglichkeiten verwenden. Das Zeitthema bei AD-Controllern können Sie aber mit einigen einfachen Kniffen entschärfen. Zuerst sollten Sie den Time-Service auf dem AD-Controller anpassen. Dazu ändern Sie im Registry Editor den Wert HKLM\System\CurrentControlSet\ W32Time\Parameters\Type von NT5DS auf NTP geändert. Als Time-Server geben Sie einen anderen Stratum-1-NTP-Server an. Stratum Was bedeutet Stratum 1 im Zusammenhang mit Zeit-Servern? Das Stratumlevel gibt an, wie weit ein Zeit-Server von der Zeitreferenzquelle entfernt steht. Je größer das Level, desto weiter ist das System von der Quelle entfernt. Stratum-0-Systeme können nicht direkt genutzt werden, allenfalls Computer, die direkt mit der Quelle verbunden sind. Systeme, die direkt mit einer Stratum-0-Quelle verbunden sind, bezeichnet man als Stratum-1-Systeme.
610
NTP
Der
Wert
des Keys HKLM\System\CurrentControlSet\W32Time\Config\ AnnounceFlags ist von 10 auf 5 anzupassen. Hiermit weisen Sie dem DomänenController fest die Funktion eines Zeit-Servers zu. Mit net stop w32time und net start w32time starten Sie den Zeitdienst nach der Neukonfiguration neu. Abschließend stoßen Sie in der Kommandozeile manuell eine Synchronisation mit dem neuen Stratum-1-Server mit dem Befehl w32tm /resync /rediscover an.
Abbildung 11.10
Deaktivierung der Zeitsynchronisation der VMware Tools
Nach dieser Konfiguration liegt für die gesamte Domäne eine stabile Zeitquelle vor. Entscheidend ist aber, dass Sie auf allen Servern der Domäne die Zeitsynchronisation über die VMware Tools deaktivieren (Abbildung 11.10)! Es gibt zwei Möglichkeiten den Dialog zu öffnen: entweder über das Startmenü, oder durch einen Doppelklick auf das VMware-Symbol in der Statusleiste. Zeitsynchronisation unter Linux Die Problematik, dass die Zeit im Betriebssystem aus dem Ruder laufen kann, existiert auch unter Linux-Betriebssystemen. Die Ursache des Phänomens haben wir schon weiter oben beschrieben. Je nach eingesetztem Linux-Derivat und verwendetem Kernel haben Sie verschiedene Optionen, das Problem anzugehen. VMware bietet einen Knowledge-BaseArtikel, der immer aktualisiert wird. Dieser Artikel beschreibt, wie bei welchem System mit welchem Kernel verfahren werden muss, damit die Zeitsynchronisation einwandfrei funktioniert. Wir verzichten an dieser Stelle darauf, die Informationen direkt anzugeben; bei der Drucklegung des Buches wären Teile davon schon wieder überholt. Sie finden den Artikel unter http://kb.vmware.com/selfservice/microsites/search.do?language=en_US& cmd=displayKC&externalId=1006427.
611
11.2
11
Konfiguration von ESX und vCenter
11.3
SNMP
Das Simple Network Management Protocol (SNMP) ist ein Standard-Netzwerkprotokoll, das Sie zur Überwachung von Hardware verwenden können. Diese Informationen werden auf einem zentralen System gesammelt. Die Kommunikation mit dem zentralen Managementsystem erfolgt über zwei Wege: Entweder sendet das Managementsystem eine Anforderung von Informationen an ein zu überwachendes System, oder das zu überwachende System stellt die Überwachungsinformationen selbständig dem Managementsystem zur Verfügung.
11.3.1
SNMP unter ESX
Das SNMP-Protokoll wird auch von VMware unterstützt. Unter Zuhilfenahme des Netzwerkprotokolls können Sie den vSphere-Server überwachen. Auch hier holt entweder das Managementsystem die Informationen ab, oder der vSphereHost sendet Informationen bei einem speziellen Event an das zentrale Management. Alle Enterprise-Produkte von VMware (vCenter, vSphere und ESXi) unterstützen das SNMP-Protokoll. Der SNMP-Agent, der vom VMware-vSphere-Host verwendet wird, ist von Haus aus direkt im System installiert. Der Agent lässt sich mit jeglicher Software nutzen, die mit Management Information Base (MIB) umgehen kann. Die MIBs sind eine Art Adresse für die zu überwachenden Objekte. Mit Hilfe dieser Adresse können die Zustandsinformationen des zugehörigen Objekts abgefragt werden. Der Vollständigkeit halber sei noch erwähnt, dass MIBs Zahlenketten sind, die durch Punkte getrennt werden, z. B. 1.3.6.1.4.1. VMware unterstützt dabei Traps und SNMP GETs. Traps sind die Informationen, die unaufgefordert an das Management geschickt werden. Die SNMP GETs werden ausgelöst, wenn das zentrale Managementsystem gezielte Nachrichten von einem SNMP sprechenden Gerät benötigt. Konfiguration des ESX-Host-Agenten von der Service Console aus Um MIBs auf einem VMware ESX-Hosts zu verwenden, müssen Sie eine Anpassung vornehmen. Ändern Sie dafür die Datei /etc/snmp/snmpd.conf mit einem Editor Ihrer Wahl. Fügen Sie in dieser Datei die Zeile Dlmod SNMPESX /usr/lib/vmware/snmp/libSNMPESX.so
hinzu. Es ist dabei unerheblich, wo Sie die Zeile einfügen.
612
SNMP
Alle MIBs finden Sie hier: /usr/lib/vmware/snmp/mibs/VMWARE-RESOURCES-MIB.mib /usr/lib/vmware/snmp/mibs/VMWARE-ESX-MIB.mib /usr/lib/vmware/snmp/mibs/VMWARE-SYSTEM-MIB.mib /usr/lib/vmware/snmp/mibs/VMWARE-ROOT-MIB.mib /usr/lib/vmware/snmp/mibs/VMWARE-TRAPS-MIB.mib /usr/lib/vmware/snmp/mibs/VMWARE-VMINFO-MIB.mib /usr/lib/vmware/snmp/mibs/VMWARE-IF-MIB.mib /usr/lib/vmware/snmp/mibs/VMWARE-SNMPv2-MIB.mib /usr/lib/vmware/snmp/mibs/VMWARE-SNMPv2-TC.mib /usr/lib/vmware/snmp/mibs/VMWARE-PRODUCTS-MIB.mib /usr/lib/vmware/snmp/mibs/VMWARE-ENV-MIB.mib /usr/lib/vmware/snmp/mibs/VMWARE-TC-MIB.mib /usr/lib/vmware/snmp/mibs/VMWARE-VMKERNEL-MIB.mib
Nach dieser Aktion ist es nötig, den SNMP-Dienst durchzustarten. Verwenden Sie dafür den Befehl service snmpd restart oder /etc/rc.d/init.d/snmpd restart. Sollte der Dienst nicht nach jedem Start des ESX-Server-Systems automatisch gestartet werden, so richten Sie dies über den Befehl chkconfig snmpd on ein. Beachten Sie dabei, dass Sie die Firewall ebenfalls anpassen müssen. Dies ist über den vSphere-Client oder die Service Console möglich. Der Befehl für die Service Console lautet: esxcfg-firewall –e snmpd. Damit SNMP-Traps funktionieren, müssen Sie die Ziele in die Datei /etc/snmp/ snmpd.conf eintragen. Dazu verwenden Sie die Einträge trapcommunity und trapsink. Diese beiden müssen Sie in der Datei anpassen. Hier finden Sie eine Beispieldatei: # Sample snmpd.conf containing VMware MIB module entries. # This is a simple snmpd.conf that may help you test SNMP. # It is not recommended for production use. Consult the # snmpd.conf(5) man pages to set up a secure installation. syscontact root@localhost (edit snmpd.conf) syslocation room1 (edit snmpd.conf) rocommunity public trapcommunity “Name der Community” trapsink “Zielsystem” trapsink “Zielsystem2” trapsink “Zielsystem3” # VMware MIB modules. To enable/disable VMware MIB items # add/remove the following entries. dlmod SNMPESX /usr/lib/vmware/snmp/libSNMPESX.so
613
11.3
11
Konfiguration von ESX und vCenter
Beachten Sie dabei, dass Sie trapcommunity nur einmal verwenden dürfen, trapsink jedoch mehrmals. Bei einem Zielsystem, das Sie unter trapsink angeben, muss es sich um einen erreichbaren Server handeln ist. Sollte zum Beispiel die Namensauflösung nicht funktionieren und der vSphere-Host das Ziel nicht erreichen, werden Aktionen, die einen Trap auslösen, bis zu einem Timeout verzögert.
11.3.2
SNMP unter ESXi
Der SNMP-Agent unter ESXi unterscheidet sich von dem SNMP-Agenten des vSphere. Durch die fehlende Service Console ist natürlich auch die Konfiguration von SNMP unter ESXi eine andere. Der SNMP-Agent unter ESXi unterstützt im Moment nur SNMP-Traps und keine GETs. Im Gegensatz zur vSphere ist der SNMP-Agent standardmäßig abgeschaltet. Um den Agenten zu verwenden, müssen Sie den SNMP-Service aktivieren und eine Community sowie ein Ziel konfigurieren. Diese Arbeit erledigen Sie im Falle des ESXi mit dem VMware Remote Command Line Interface (Remote CLI). Der dazugehörige Befehl lautet vicfg-snmp. Selbstverständlich können Sie auch einen vSphere-Host über diese Mechanismen konfigurieren. Tabelle 11.2 listet alle Optionen des Befehls vicfg-snmp auf. Optionen
Beschreibung
-c|--communities
Setzt die SNMP-Communities; mehrere durch Kommas trennen.
-D|--disable
Stoppt den SNMP-Service.
-E|--enable
Startet den SNMP-Service.
-p|--port
Setzt den Port des SNMP-Agenten. Standard ist udp/162.
-r|--reset
Löscht alle Communities.
-s|--show
Zeigt die SNMP-Agenten-Konfiguration an.
-t|--targets
Setzt den Host für die die Benachrichtigungen. hostname[@port][/community][,...]
-T|--test
Sendet eine Testbenachrichtigung.
-h|--vihost
Angabe des zu benutzenden Hosts
Tabelle 11.2
Optionen des Befehls vicfg-snmp
Mit dem Befehl vicfg-snmp –T wird der ESXi einen Test-Trap schicken. So überprüfen Sie die Konfiguration und die Einstellungen.
614
DNS
11.3.3
SNMP in Gastbetriebssystemen
Natürlich können Sie das SNMP-Protokoll auch in den verschiedenen Gastbetriebssystemen verwenden. Auf Seite der Virtual Infrastructure sind dafür kein weiteres Eingreifen und keine weitere Konfiguration nötig. Je nach Gastbetriebssystem und Applikation lassen sich SNMP-Einstellungen vornehmen. Zu den nötigen Konfigurationsschritten können Sie sich bei dem Hersteller des entsprechenden Betriebssystems informieren.
11.4
DNS
Eine sauber funktionierende Namensauflösung ist Grundvoraussetzung für eine einwandfrei arbeitende virtuelle Infrastruktur. Aus diesem Grund sollten Sie in der gesamten Umgebung DNS einsetzen. Ein falsch konfigurierter DNS kann zu viele Problembilder haben, die oftmals nicht direkt dem eigentlichen Problem zuzuordnen sind. Die DNS-Konfiguration eines vSphere-Hosts können Sie über den vSphere-Client vornehmen. Dafür müssen Sie sich direkt am Host oder am vCenter-Server anmelden. Über den Tab Configuration gelangen Sie zur Einstellung DNS and Routing, mit dem Link Properties erreichen Sie die Eingabemaske. In dieser Maske machen Sie alle nötigen Eingaben, um den Namensdienst zu konfigurieren (Abbildung 11.11).
Abbildung 11.11
DNS-Konfiguration der vSphere-Hosts
615
11.4
11
Konfiguration von ESX und vCenter
Routing/Gateway Eine Änderung am Gateway ist ebenfalls über den vSphere-Client sehr einfach möglich. Der Weg ist identisch mit der Anpassung der DNS-Einstellungen. Rufen Sie einfach den Reiter Routing auf. Hier verbirgt sich die Möglichkeit, Gateways für die Service Console sowie den VMkernel einzugeben. Beachten Sie – aber das ist keine vSphere-Eigenart –, dass das Gateway in Ihrem Netzwerksegment liegen muss.
11.5
Einrichtung von Resource-Pools
Nicht nur in großen Umgebungen ist es sinnvoll, mit Resource-Pools zu arbeiten, sondern auch in kleineren Umgebungen. Dabei lassen sich die Resource-Pools für andere Funktionen zweckentfremden; dazu aber später mehr im Abschnitt 11.11, »vCenter-Berechtigungen«. In Resource-Pools werden Teile von CPU- und Memory-Ressourcen eines Hosts zusammengefasst. Dabei ist es möglich, die Parameter des Pools variabel zu gestalten. Aber Pools fassen nicht nur Ressourcen zusammen, sie bieten auch die Möglichkeit der Rechtebündelung. Somit ist es ein Mittel der Wahl, Anwendern in »ihren« Resource-Pools mehr Rechte zu geben als auf den anderen Objekten der virtuellen Infrastruktur. In Resource-Pools ist es dem Administrator möglich, Ressourcen aufzuteilen, bereitzustellen und zu reservieren. Erstellung eines Resource-Pools Das Kontextmenü des Hosts oder Clusters führt zu dem Punkt New Resource Pool zur Erstellung von Resource-Pools (Abbildung 11.12).
Abbildung 11.12
616
Neuen Resource-Pool erstellen
Einrichtung von Resource-Pools
Anschließend erscheint ein Fenster, in dem Sie verschiedene Einstellungen vornehmen können, um den Resource-Pool anzulegen (Abbildung 11.13).
Abbildung 11.13
Konfiguration von Resource-Pools
In dem Feld Name geben Sie einen Name für diesen neuen Resource-Pool ein. Hier legen wir einen Pool für die Entwicklungsabteilung an. In den anderen Feldern konfigurieren Sie die zu verwendeten CPU- und RAM-Ressourcen. Reservation Bei dem Teil Reservation nehmen Sie auf Wunsch eine Reservierung für den Pool vor. Bei einer Reservierung werden die hier angegebenen Ressourcen dem Pool immer garantiert zugewiesen, wenn diese benötigt werden. Im Falle der CPU-Ressourcen, in Abbildung 11.13, werden immer 1.000 MHz zugewiesen, bei den Memory-Ressourcen geben Sie durch den Wert 0 alle Speicherressourcen frei, wenn sie nicht benötigt werden. Limit Die Einstellung für Limit ist ähnlich wie eine Reservierung. Stellen Sie ein Limit ein, kann dieser Pool maximal diese Ressourcen anfordern und verwenden. Damit ist garantiert, dass virtuelle Maschinen, die in einem Resource-Pool liegen, nicht den Ressourcenbedarf von anderen VMs außerhalb des Pools beeinflussen.
617
11.5
11
Konfiguration von ESX und vCenter
Expandable Haben Sie bei Expandable Reservation einen Haken gesetzt, können sich Kinder (virtuelle Maschinen und Pools) eines Vater-Objektes an dessen Ressourcen bedienen. Wenn Sie den Haken nicht gesetzt haben, können Kinder (virtuelle Maschinen und Pools) nur von diesem Pool Ressourcen beziehen, auch wenn der darüberstehende Vater-Pool freie Ressourcen zur Verfügung hat. Sie sehen also, dass das Anlegen eines solchen Pools sehr einfach und schnell erledigt ist. Bei großen und komplexen Umgebungen sollten Sie allerdings auf jeden Fall ein grundlegendes Konzept erstellen. Oft entstehen Ressourcen- oder Performance-Probleme aufgrund einer falschen Konfiguration von ResourcePools in Zusammenhang mit einer großen Struktur. Shares Die sogenannten Shares greifen immer dann, wenn keine freien Ressourcen mehr zur Verfügung stehen und die virtuellen Maschinen weitere Ressourcen anfordern. In diesem Fall priorisieren die Shares die Ressourcen der virtuellen Maschine anhand eines share-basierten Modells. Wie viel Zeit das Objekt auf der eingestellten Ressource erhält, hängt immer von den eigenen Shares im Vergleich zu den vorhandenen Gesamt-Shares ab. Hat zum Beispiel eine virtuelle Maschine (VM1) 2 000 CPU-Shares und eine zweite virtuelle Maschine (VM2) 4 000 CPUShares, dann bekommt VM1 33 % CPU und VM2 66 % CPU. Die Aufteilungsgrundlage der CPU-Ressourcen bildet die Gesamtsumme aller Shares, das sind in diesem Fall 6 000 Shares (2 000 [VM1] + 4 000 [VM2]). VMware nutzt drei Standardwerte, die zum Einsatz kommen können. Natürlich ist es auch möglich, eigene Werte zu vergeben. In Tabelle 11.3 sind die Share-Werte aufgelistet. Shares
Wert
Low
2 000
Normal
4 000
High
8 000
Custom
variabel
Tabelle 11.3
Standardwerte der Shares
Shares sind zwar ein Mittel der Priorisierung von Ressourcen, aber weniger ist hier definitiv mehr. Bedenken Sie: Je komplexer die Struktur ist, desto schwieriger ist es im Falle von Problemen, die Fehlerursache zu finden. Arbeiten Sie aus diesem Grund nie ohne Konzept, wenn Sie diese Mechanismen nutzen. Wichtig ist ebenfalls eine genaue Dokumentation solcher Konfigurationen, damit bei Problemen alle nötigen Informationen für die Fehlerbehebung vorliegen.
618
VMware vApp
11.6
VMware vApp
Bieten Resource-Pools die Möglichkeit, unterschiedliche virtuelle Maschinen zu gruppieren, so haben Sie die Option, mit VMware vApp Server zusammenzufassen, die funktionell zusammengehören. Nicht nur das – es ist sogar möglich, die Abhängigkeiten der Systeme untereinander zu hinterlegen. Soll heißen: Der vCenter-Server weiß genau, in welcher Reihenfolge die Systeme gebootet werden müssen. Lassen Sie uns das Ganze an einem Beispiel verdeutlichen. Wir nehmen dazu einen Web-Server, der als Backend einen Datenbank-Server benötigt. Aus diesen beiden Systemen erzeugen wir nun eine vApp. Doch bevor die Arbeiten beginnen können, benötigen Sie einen DRS-Cluster oder einen VMware-Host mit mindestens Version 3.x.
11.6.1
Erstellen einer vApp
Zum Erstellen einer neuen vApp rufen Sie den entsprechenden Menüpunkt aus dem Kontextmenü des Hosts bzw. des Clusters auf (Abbildung 11.14).
Abbildung 11.14
Erstellen einer vApp über das Kontextmenü
619
11.6
11
Konfiguration von ESX und vCenter
Es startet – wie sollte es auch anders sein – ein Wizard, der Sie durch das Anlegen der vApp führt. Zuallererst geben Sie der Applikation einen Namen. Der Name muss eindeutig sein und darf nicht mit anderen Namen in der virtuellen Infrastruktur kollidieren. Beachten Sie, dass die Länge auf 80 Zeichen beschränkt ist. Es folgt die Angabe des Ablageorts in der Infrastruktur. Das kann ein Host oder ein Cluster sein. Es ist aber auch möglich, die vApp in einen Resource-Pool oder in eine bereits vorhandene vApp zu legen. Handelt es sich bei dem Zielort um einen nicht automatischen DRS-Cluster, dann ist die vApp direkt auf einem Host in diesem Cluster-Verbund abzulegen. Machen Sie sich Ihre eigenen Gedanken, was für Sie am sinnvollsten ist. Auch hier sollten Sie darauf achten, dass eine Einheitlichkeit vorhanden ist und dass Sie alles so übersichtlich wie möglich halten (Abbildung 11.15).
Abbildung 11.15
Anlage einer vApp und Namensvergabe
Wie schon bei der Anlage eines Resource-Pools können Sie der vApp nun auf Wunsch Ressourcen zuweisen (Abbildung 11.16). Damit sind die Arbeiten für die Anlage der vApp schon erledigt. Nach der Zusammenfassung schließen Sie einfach den Dialog.
11.6.2
Verknüpfung einer vApp mit virtuellen Servern
Ist die Hülle für eine vApp komplett angelegt, folgt im nächsten Schritt die Verknüpfung mit anderen vApps oder mit vorhandenen VMs. Die Verknüpfung von bereits vorhandenen VMs mit der vApp erfolgt durch einfaches Drag & Drop (Abbildung 11.17). Der Zustand der virtuellen Maschinen ist für den Aufnahmevorgang unerheblich. Die Aufnahme funktioniert sowohl im ausgeschalteten als auch im eingeschalteten Zustand.
620
VMware vApp
Abbildung 11.16
Ressourcenzuweisung für die vApp
Abbildung 11.17
Erstellte vApp mit ihren zukünftigen VMs
Neue virtuelle Maschinen können Sie aber auch direkt in der vApp anlegen. Die Vorgehensweise entspricht der Ihnen bereits bekannten für die Erstellung einer VM. Wenn Sie die beiden virtuellen Maschinen DB-Server und Web-Server der vApp Bookshop_vApp hinzugefügt haben, dann stellt sich das so dar wie in Abbildung 11.18.
621
11.6
11
Konfiguration von ESX und vCenter
Ist die vApp eingeschaltet, befindet sich, wie bei den VMs auch, ein grüner Pfeil in dem Anzeige-Icon.
Abbildung 11.18
Fertig erstellte vApp Bookshop_vApp
Jetzt haben Sie die vApp Bookshop_vApp erstellt. In dieser vApp liegen ein Datenbank-Server und der dazugehörige Web-Server.
11.6.3 vApp – Einstellungen Über den Link Edit Settings können Sie die Einstellungen der vApp weiter bearbeiten. Das sich öffnende Fenster bietet zwei Reiter: Optionen und Start Order (Abbildung 11.19). Der nach dem erstmaligen Aufruf angezeigte Dialog sollte Ihnen von der Anlage der vApp her bekannt vorkommen. Es handelt sich um die Ressourceneinstellungen der vApp.
Abbildung 11.19
622
Anpassung der Ressourcen
1450.book Seite 623 Freitag, 5. Februar 2010 12:11 12
VMware vApp
Im Properties-Fenster finden sich derzeit keine weiteren Einstellmöglichkeiten. Die hier angezeigten Werte hängen mit den Einträgen im Fenster Advanced 폷 Properties zusammen. Nur wenn die Optionen in dem Properties-Fenster aktiv sind, werden in diesem Fenster Einträge angezeigt. Die IP Allocation Policy legt fest, in welcher Art und Weise die vApp ihre IPParameter erhält (Abbildung 11.20).
Abbildung 11.20
IP-Versorgung der vApp
Die Einträge in diesem Fenster korrelieren mit den Einträgen im Fenster Advanced 폷 IP Allocation. Nur wenn die Optionen im IP Allocation-Fenster aktiv sind, ist es möglich, in dieser Policy andere Einstellungen als fixed auszuwählen. Bei fixed wird mit statischen IP-Adressen gearbeitet, bei DHCP wird der vApp automatisch eine Adresse zugewiesen, und bei transient wird die IP-Adresse aus einem Pool bezogen, der auf dem HA-Cluster unter IP Pool eingerichtet wird. In der Advanced-Auswahl können Sie die vApp personalisieren (Abbildung 11.21). Die Felder in diesem Dialog sind selbsterklärend. Zusätzlich finden Sie hier die beiden Buttons, die die weiter oben beschriebenen Konfigurationsfenster bereitstellen. Es handelt sich dabei um die Konfiguration der IP-Bereitstellung (Abbildung 11.22). Die Einstellung DHCP an dieser Stelle aktiviert die DHCP-Option in der IP Allocation Policy. Die Option OVF Environment hängt mit der Transient-Option in der Allocation Policy zusammen. Bei der Auswahl können Sie noch festlegen, mit welcher IP-Version gearbeitet werden soll – IPv4, IPv6 oder mit beiden IPVersionen.
623
11.6
11
Konfiguration von ESX und vCenter
Abbildung 11.21
Personalisierung der vApp
Abbildung 11.22
Konfiguration der IP-Bereitstellung
Zum Schluss bleibt noch die Konfiguration der Start Order (Abbildung 11.23). Aus unserer Sicht ist dieser Punkt ein sehr wichtiger Baustein für die einwandfreie Funktion einer vApp, wenn diese nur zur Gruppierung von VMs dient und zur Abbildung von deren Abhängigkeiten untereinander.
624
VMware vApp
Abbildung 11.23
Startreihenfolge für die vApp
Für jeden Server können Sie eine eigene Aktion für den Start bzw. für den Shutdown festlegen. Beim Start gibt es, außer dem Power On, nur die Option, keine Aktion ausführen zu lassen. Zusätzlich können Sie angeben, welche Aktion der Startschuss für die folgende Gruppe ist. Entweder arbeiten Sie mit einem Timer, oder der abgeschlossene Start der VMware Tools ist der Trigger für die Aktivierung der nächsten Gruppe. None, Power off, guest shutdown und suspend stehen als Optionen für das Beenden der Applikation zur Verfügung. Die Abarbeitungsreihenfolge erfolgt von oben nach unten für das Starten und von unten nach oben für das Stoppen der Applikation. Über die Pfeiltasten verschieben Sie beteiligte VMs zwischen den unterschiedlichen Gruppen, um so die Reihenfolge korrekt abzubilden. Wichtig Wenn Sie mit vApps arbeiten, dann denken Sie bitte daran, die Ein- und Ausschaltbefehle nur über das Kontextmenü der vApp zu nutzen. Anderenfalls wird die Startreihenfolge unter Umständen nicht eingehalten. Wurde über die vApp eine Aktion gestartet, sind die Befehle im Kontextmenü der VM ausgeblendet.
Wenn Sie tiefer in das Thema einsteigen und komplexere vApps und auch eigene OVFs (Open Virtualization Format) erstellen wollen, sollten Sie sich mit dem VMware Studio auseinandersetzen. Dieses Entwicklertool von VMware ermöglicht Ihnen, komplett eigene VMs zu kreieren.
625
11.6
11
Konfiguration von ESX und vCenter
Nähere Informationen zu dem Thema finden Sie auf der Webseite von VMware unter http://www.vmware.com/appliances/learn/vmware_studio.html.
11.7
Automatisches Starten und Stoppen der VMs mit dem Host
Mit dem Start des vSphere-Hosts gibt es die Möglichkeit, virtuelle Maschinen automatisch zu starten. Speziell dafür bietet der Reiter Configuration auf einem vSphere-Host eine entsprechende Option. Unter dem Link Software 폷 Virtual Machine Startup/ Shutdown können Sie dies konfigurieren und einschalten (Abbildung 11.24).
Abbildung 11.24
Automatisches Starten und Stoppen von virtuellen Maschinen
Im oberen Teil des Fensters wird der Status dieses Features angezeigt. In der Abbildung ist die Funktion komplett abgeschaltet. Dadurch besteht keine Möglichkeit, die virtuellen Maschinen automatisch zu stoppen oder zu starten. Über den Properties-Link lässt sich die Funktion global für den Host aktivieren. Rufen Sie mit dem Link Properties im rechten Teil des Fensters das in Abbildung 11.25 angezeigte Fenster auf. in dem Sie das automatische Starten und Stoppen der virtuellen Maschinen konfigurieren. Die Checkbox Allow virtual machines muss aktiviert werden, damit alle anderen Funktionen freigeschaltet werden. Anschließend können Sie das Verhalten der VMs nach einem Neustart des Hosts einstellen.
626
vSphere-Firewall
Abbildung 11.25
Automatisches Starten und Stoppen von virtuellen Maschinen aktivieren
Für beide Optionen, das Starten und Stoppen, ist es möglich, eine Delay-Zeit anzugeben. Diese Zeit wird noch verstreichen, bevor die Aktionen durchgeführt werden. Bei den Verzögerungszeiten handelt es sich um eine globale Einstellung, die automatisch für alle VMs auf dem Host angewendet wird. Im unteren Teil des Fensters positionieren Sie über die Buttons Move Up und Move Down gegebenenfalls die virtuellen Maschinen in einer bestimmten Reihenfolge. Die Reihenfolge gibt an, in welcher Abfolge die virtuellen Maschinen gestartet werden. In derselben Reihenfolge, aber rückwärts, werden die virtuellen Maschinen heruntergefahren. Virtuelle Maschinen unter dem Bereich Manual Startup werden nicht automatisch gestartet, sondern bleiben abgeschaltet, bis ein anderer Task oder eine manuelle Aktion die Maschinen bootet. Maschinen unter dem Punkt Any Order werden automatisch vom System gebootet, genau wie die Maschinen unter dem Punkt Automatic Startup.
11.8
vSphere-Firewall
Der VMware-vSphere-Host ist mit einer Firewall ausgestattet, die die Service Console des vSphere-Hosts schützt. Die Firewall ist nach der Installation eingeschaltet und konfiguriert. Standardmäßig werden alle Ports erst einmal geschlossen, abgesehen von den Ports, die für die Standardkommunikation notwendig
627
11.8
11
Konfiguration von ESX und vCenter
sind. Die offenen Ports sind: 902, 80, 443 und 22. Abgesehen davon werden ICMP-Pakete (Internet Control Message Protocol), der Ping sowie DHCP- und DNS-Traffic zugelassen.
11.8.1
Öffnen und Schließen von Ports über die Service Console
Es ist möglich, weitere Ports auf der Firewall zu öffnen oder zu schließen. Das Öffnen eines Ports ist dann nötig, wenn weitere Software oder Dienste installiert wurden, die über das Netzwerk kommunizieren. Ein Beispiel dafür wäre die Installation eines Backup-Agenten, der mit seinem Backup-Server kommunizieren muss. Es gibt zwei Möglichkeiten, einen Port auf einer Firewall zu öffnen oder zu schließen: Ein Weg führt direkt über die GUI mit dem vSphere-Client, der andere Weg basiert auf der Service Console. Im Folgenden werden beide Möglichkeiten beschrieben und näher erläutert. Öffnen eines Ports auf der Service Console Melden Sie sich auf der Service Console mit root-Rechten an, und setzen Sie den folgenden Befehl ab: esxcfg-firewall –openport ,tcp| udp,in|out, 왘
steht dabei für den Port, der geöffnet werden soll.
왘
tcp|udp gibt das Protokoll an.
왘
in|out deklariert ein- oder ausgehende Verbindungen.
왘
bezeichnet den Namen für die Portfreischaltung.
Bitte nutzen Sie den Portnamen, damit auch Ihre Kollegen wissen und beurteilen können, warum und wofür die Freischaltung gemacht worden ist. Abschließend führen Sie den Befehl service mgmt-vmware restart aus, um den vmware-hostdProzess neu zu starten. Schließen eines Ports auf der Service Console Zum Schließen eines Ports müssen Sie sich mit root-Rechten an der Service Console anmelden. Nutzen Sie den folgenden Befehl: esxcfg-firewall –closeport ,tcp|udp,in|out 왘
steht dabei für den Port, der geöffnet werden soll.
628
vSphere-Firewall
왘
tcp|udp bezeichnet das Protokoll.
왘
in|out gibt an, ob es sich um eine eingehende oder eine ausgehende Verbin-
dung handelt. Hier ist ebenfalls mit dem Befehl service mgmt-vmware restart der vmwarehostd-Prozess neu zu starten, damit die Veränderung der Einstellungen aktiv wird. Öffnen und Schließen eines Ports mit dem vSphere-Client Um einen Port mit dem vSphere-Client zu öffnen oder zu schließen, müssen Sie sich direkt mit dem vSphere-Host oder mit einem vCenter verbinden und auf dem Configuration-Reiter des VMware-Hosts zugreifen. Dort gibt es einen Link mit dem Namen Security Profile. Man vermutet nicht direkt die Firewall-Einstellungen dahinter, allerdings sind diese genau dort zu finden (Abbildung 11.26).
Abbildung 11.26
ESX-Firewall-Ansicht
Es wird eine komplette Übersicht angezeigt, welche Ports mit welchen Parametern freigeschaltet sind. Diese können Sie auch hier über den Link Properties ändern. Folgen Sie dem Link, öffnet sich ein Fenster mit gängigen vorkonfigurierten Ports, die freigeschaltet werden können (Abbildung 11.27). Sollen Ports freigeschaltet werden, die in dieser Liste nicht auftauchen, bleibt nur der Weg über die Service Console, um die Freischaltungen hinzuzufügen.
629
11.8
11
Konfiguration von ESX und vCenter
Abbildung 11.27
11.8.2
Portfreischaltungen der vSphere-Firewall
Automatisches Starten und Stoppen
Das Startverhalten der eingerichteten Freischaltung oder Sperrung von Ports lässt sich individuell konfigurieren. Sie haben drei Optionen für das Startverhalten der Portfreischaltung (Abbildung 11.28).
Abbildung 11.28
Startarten für Portfreischaltungen
Start automaticly if any ports are open, and stop when all ports are closed ist die Standardoption für alle Ports. Wenn der Port geöffnet wurde, wird der Dienst automatisch gestartet. Mit der Option Start and stop with the host werden die Dienste direkt mit dem Host gestartet oder beendet.
630
Lizenz-Server
Bei Aktivierung von Start and stop manually startet keine Freischaltung automatisch. Der Dienst muss manuell gestartet werden. Wird der Dienst mit dieser Option manuell gestartet und später der Host neu gebootet, ist der Dienst nach dem Neustart nicht mehr verfügbar. Vorsicht Wird ein Port auf der Firewall, der bisher geöffnet war, geschlossen, werden bereits aktive Verbindungen nicht beendet. Die laufende Kommunikation über einen bestimmten nachträglich geschlossenen Port funktioniert noch so lange weiter, bis die Verbindung getrennt wird.
11.9
Lizenz-Server
Mit der Einführung der Version vSphere hat sich das Thema Lizenz-Server grundlegend geändert. Bei der Einführung der Virtual Infrastructure 3 hat VMware – warum auch immer, verstanden haben das viele Anwender nicht wirklich – den Lizenz-Server aus dem Virtual Center-Server ausgegliedert. Es wurde ein externes Produkt zugekauft, das die Lizenzen verwaltete. Unter vSphere und dem vCenterServer in der aktuellen Version hat ein »back to the Roots« stattgefunden – der Lizenz-Server gliedert sich wieder ins vCenter ein. Viele werden sich freuen, aber nur diejenigen, die eine reine vSphere-Umgebung haben. Bauen Sie Mischumgebungen auf, müssen Sie beide Produkte einsetzen, den alten Lizenz-Server für alle VI 3.x-Systeme und den neuen, integrierten für die vSphere-Hosts. Deshalb gehen wir auch auf beide Produkte ein. Der Lizenz-Server ist integraler Bestandteil des vCenter-Servers und wird automatisch mit installiert. Er verwaltet alle Lizenzen und stellt sie dem vCenter selbst und den vSphere-Hosts zur Verfügung.
11.9.1
Konfiguration des vCenter-Lizenz-Servers
Der Lizenz-Server der neuen Virtual Infrastructure 4.0 ist nicht separat zu installieren. Er integriert sich direkt in den vCenter-Server. Der Aufruf erfolgt einfach über die Management-Homepage des vCenters (Abbildung 11.29). Haben Sie den Lizenz-Server aufgerufen, dann zeigt sich ein Übersichtsfenster mit den bereits installierten Lizenzen (Abbildung 11.30). Die Ansicht können Sie wechseln zwischen einer Sortierung nach Produkten, Lizenz-Keys und AssetDaten. Die angezeigte Liste lässt sich auch exportieren, dabei stehen die Dateiformate CSV, XML, XLS, Standard-HTML und External CSS-HTML zur Verfügung.
631
11.9
11
Konfiguration von ESX und vCenter
Abbildung 11.29
Aufruf des integrierten Lizenz-Servers
Abbildung 11.30
Übersicht des Lizenz-Servers
Über den Link Manage vSphere Licenses gelangen Sie in den eigentlichen Lizenzmanager des vCenters, wo Sie die Lizenzen verwalten (Abbildung 11.31). Das Einpflegen von Lizenzen gliedert sich in mehrere Schritte. Als Erstes tragen Sie den Schlüssel ein. Optional fügen Sie zusätzlich eine Bezeichnung der Lizenz hinzu. Im zweiten Schritt weisen Sie den Key einem Asset-Satz zu (Abbildung 11.32). Verschiedene Sortieroptionen ermöglichen eine Auflistung nach lizenzierten, unlizenzierten oder aller Assets. Zwei Reiter separieren die Lizenzen zwischen vCenter Server und vSphere-Hosts. Genauere Informationen über den AssetSatz finden Sie im unteren Teil des Fensters.
632
Lizenz-Server
Abbildung 11.31
Hinzufügen von Lizenzen
Abbildung 11.32
Zuweisen der Lizenzen zum Asset
Im folgenden Fenster können Sie nicht zugewiesene Lizenzen vom Server entfernen. Ihnen steht noch ein weiterer Weg zum Einpflegen von Lizenzen zur Verfügung, und zwar unter Administration 폷 vCenter Server Settings… 폷 Licensing (Abbildung 11.33). Die Vorgehensweise entspricht im Wesentlichen der bereits weiter oben beschriebenen.
633
11.9
11
Konfiguration von ESX und vCenter
Abbildung 11.33
11.9.2
Lizenzpflege über die vCenter Server Settings
Konfiguration des Lizenz-Servers für VI 3.x-Systeme
Benötigen Sie weiterhin, ob temporär oder auf Dauer, einen Lizenz-Server für eine Virtual Infrastructure 3.x, dann ist dieser nach der Installation dem vCenterServer bekanntzugeben. Setzen Sie keine VI 3-Systeme mehr ein, können Sie diesen Abschnitt komplett überspringen. Die Anmeldung der VI 3.x-Lizenz-Servers erfolgt ebenfalls unter Administration 폷 vCenter Server Settings… 폷 Licensing. Im unteren Teil des Fensters (siehe Abbildung 11.33) geben Sie den Lizenz-Server bekannt. Der Lizenzserver selbst kann über das vCenter nicht administriert werden. Dort müssen Sie über das Startmenü den VMware Lizenz Server aufrufen. Die beiden Menü-Einträge im Startmenü sind die Tools, mit denen Sie den VMware-LizenzServer konfigurieren und administrieren können (Abbildung 11.34). Eine entsprechende Dokumentation finden Sie dort ebenfalls. Nach dem Aufruf der VMware-Lizenz-Server-Tools startet die GUI, mit dem Sie den VMware-Lizenz-Server konfigurieren (Abbildung 11.35).
634
Lizenz-Server
Abbildung 11.34
Start-Menü-Eintrag VMware License Server
Die wichtigsten Reiter für die Administration sind System Settings, Start/Stop/ Reread, Server Diags und Config Services. Mit diesen Reitern konfigurieren und analysieren Sie den VMware-Lizenz-Server.
Abbildung 11.35
Konfigurationsfenster VMware-Lizenz-Server
Unter dem Reiter System Settings werden wichtige Informationen angezeigt (Abbildung 11.36). Diese sollten Sie in einer Datei speichern. Für ein eventuelles Wiederherstellen des Lizenz-Servers sind diese Dateien möglicherweise entscheidend. Mit den Funktionen unter dem Reiter Start/Stop/Reread halten Sie den LizenzServer an, starten ihn und lesen die Lizenzdatei neu ein (Abbildung 11.37). Bei Problemen mit dem Lizenz-Server bringt ein einfaches Neustarten und/oder ein Einlesen der Lizenzdatei oft die gewünschte Funktion wieder online. Sollten Probleme mit dem Lizenz-Server auftreten, ist es möglich, unter dem Reiter Server Diags eine Diagnose durchzuführen (Abbildung 11.38).
635
11.9
11
Konfiguration von ESX und vCenter
Abbildung 11.36
VMware-Lizenz-Server System Settings
Abbildung 11.37
VMware-Lizenz-Server Start/Stop/Reread
Abbildung 11.38
VMware-Lizenz-Server Server Diags
636
Lizenz-Server
Die eigentliche Konfiguration erfolgt unter dem Reiter Config Services. Hier geben Sie die Pfade an, die das System benötigt, damit es einwandfrei läuft. Die Angaben beziehen sich auf das Log-Verzeichnis, den Ort der Lizenzdateien und den Pfad der exe-Datei (Abbildung 11.39).
Abbildung 11.39
VMware-Lizenz-Server Config Services
Einbindung der Lizenzdateien in den Lizenz-Server vereinfachen Viele Anwender kopieren die Lizenzdateien zusammen, damit sie in den Lizenz-Server eingebunden werden können. Es ist auch möglich, die Dateien alle in ein Verzeichnis zu kopieren und beim Path to the license file nicht, wie oft beschrieben, die Lizenzdatei, sondern nur den Pfad anzugeben. In diesem Fall werden alle LizenzFiles eingelesen, die in diesem Verzeichnis gefunden werden.
11.9.3 DNS-Name für Lizenz-Server Es gibt einen relativ einfachen Weg, damit Umzüge des Lizenz-Servers nicht zu arbeitsintensiv sind: Der Administrator lässt sich von den DNS-Verantwortlichen ein Alias für den Lizenz-Server einrichten. Das Problem des Lizenz-Servers ist aber, dass er sich trotz Alias auf den HostNamen referenziert und auf dem ESX 3.x-Host das Alias gegen den Server-Namen tauscht. Diese Problem umgehen Sie, indem Sie nach dem Umzug des Servers dem System das Alias als Server-Namen geben und den eigentlichen ServerNamen als Alias im DNS einrichten. Bei dieser Vorgehensweise müssen Sie weder auf dem vCenter-Server noch auf den VI 3.x-Hosts nach dem Umzug eine Anpassung vornehmen.
637
11.9
11
Konfiguration von ESX und vCenter
11.9.4 Umzug eines Lizenz-Servers Nachdem Sie einen Lizenz-Server für die VMware Virtual Infrastructure installiert und konfiguriert haben, arbeitet dieser in den meisten Fällen ohne Probleme und wird so schnell nicht mehr angefasst. Es gibt allerdings nicht wenige Fälle, bei denen der Lizenz-Server umziehen muss. Dies kann verschiedene Gründe haben, wie zum Beispiel den Austausch der Hardware oder die Erweiterung der Infrastruktur. Der Vorgang als solcher ist eigentlich relativ unproblematisch: Sie installieren den Lizenz-Server auf einem anderen System neu und stellen ihn zur Verfügung. Sie kopieren die Lizenzen in das entsprechende Verzeichnis, testen die Funktion und geben den neuen Server allen Systemen bekannt. Zum einen müssen Sie auf den VI 3.x-Hosts den neuen Server eintragen und zum anderen im vCenterLizenzmanager das neue Ziel angeben (siehe Abbildung 11.33).
11.10
Erweiterte Konfiguration
Lassen Sie uns nun auf die Einstellungen eingehen, die Sie am Host noch vornehmen können, die wir aber bis jetzt noch nicht angesprochen haben. Es handelt sich um insgesamt drei Punkte.
11.10.1
Speicherkonfiguration
Dieser Konfigurationspunkt ist unter Hardware / Memory zu finden. Diese Auswahl ist nur für ESX-Systeme interessant, bei ESXi-Systemen können Sie an dieser Stelle nichts konfigurieren, Bei dieser Konfiguration handelt es sich um die Zuweisung von Arbeitsspeicher für die Service Console. ESXi hat keine Service Console, somit entfällt diese Einstellmöglichkeit. Per Default werden der Service Console laut Knowledge Base 358 MB Speicher zugewiesen. Auf den von uns installierten Systemen waren nach der Installation unterschiedliche Speichermengen zugeteilt. Es hängt davon ab, wie viel Hauptspeicher der Host installiert hat. In der folgenden Tabelle finden Sie die von uns ermittelten Werte. Hauptspeichergröße
Speicher für die Service Console
8 GB
300 MB
16 GB
400 MB
Tabelle 11.4
638
Übersicht Hauptspeicher zu Service Console Speicher
Erweiterte Konfiguration
Hauptspeichergröße
Speicher für die Service Console
32 GB
500 MB
64 GB
615 MB
96 GB
661 MB
128 GB
703 MB
Tabelle 11.4
Übersicht Hauptspeicher zu Service Console Speicher (Forts.)
Maximal können Sie 800 MB Speicher zuweisen. Wann sollten Sie nun den Speicherwert ändern? Die Empfehlung von VMware verweist auf installierte Komponenten von Drittherstellern, die in der Service Console laufen. Das können z. B. Datensicherungs- oder Überwachungsagenten sein, oder der Server ist Mitglied eines HA-Clusters. Es hat sich bewährt, den Wert mindestens auf 512 MB zu setzen; wer es sich vom Speicherausbau des Hosts leisten kann, sollte direkt den Maximalwert einstellen. Dann hat der Administrator auf jeden Fall erst einmal seine Ruhe, und im Fehlerfall sind nicht noch Reboots durchführen, bevor VMware eine genaue Fehleranalyse durchführen kann. Beim Auftreten von Server-Problemen empfiehlt VMware nämlich, den Speicher auf den maximalen Wert zu setzen. Beachten Sie bitte, dass eine Konfigurationsänderung dieses Wertes erst aktiv ist, nachdem der Host neu gestartet wurde.
11.10.2
Ablage der VM-Swapfiles
VMware setzt bei seiner virtuellen Infrastruktur Mechanismen ein, die es ermöglichen, den virtuellen Maschinen mehr Arbeitsspeicher zuzuweisen, als tatsächlich in dem Host-System vorhanden ist. Das sogenannte Memory-Overcommitment bedingt aber, dass der Host nicht aktiv genutzten Arbeitsspeicher der einzelnen virtuellen Maschine auslagert. Diese Auslagerung findet, wie bei anderen Systemen auch, ins File-System statt. An dieser Stelle gibt es nun die Möglichkeit, festzulegen, an welchem Speicherort der Arbeitsspeicher ausgelagert werden soll. Berücksichtigen Sie bitte, dass es zwei Stellen gibt, an denen diese Einstellung beeinflusst werden kann: zum einen auf dem einzelnen Host selbst und zum anderen in der Konfiguration eines angelegten Clusters. Die zur Verfügung stehenden Optionen variieren dabei nicht. Die Datei wird entweder im selben Verzeichnis abgelegt in dem auch die VM liegt, oder Sie müssen einen eigenen Datastore für die Ablage der Swapfiles anlegen (Abbildung 11.40).
639
11.10
11
Konfiguration von ESX und vCenter
Abbildung 11.40
Ablage der Swapfiles der virtuellen Maschine
Beachten Sie aber, dass die Ablage auf einem zentralen Swap-Datastore zu Performance-Engpässen führen kann. Nutzen Sie auf gar keinen Fall einen lokalen Datastore für Swapfiles. In einem solchen Fall hebeln Sie zentrale Funktionen wie z. B. VMotion aus und alle Funktionen, die sich daran angliedern. Unsere Empfehlung ist: Nutzen Sie den obersten Punkt, und legen Sie das Swapfile direkt zu den Daten der einzelnen VM.
11.10.3
Host-Systemressourcen
Wählen Sie den Punkt Software/System Ressource Allocation aus. An dieser Stelle lassen sich die Systemressourcen des Host-Systems sehr granular einstellen. Es geht dabei nicht um die Service Console, sondern um die Zuweisungen von Ressourcen für den Hypervisor. Die Einstellungen gruppieren sich in zwei Abschnitte. Im ersten Abschnitt weisen Sie den einzelnen Softwarekomponenten die Prioritäten und Ressourcen zu, im zweiten Abschnitt dem Hypervisor die Hardwareressourcen. Zu finden sind die Einstellungen im ConfigurationBereich (Abbildung 11.41). An die Einstellungen für die Hardwareressourcen gelangen Sie über den EditButton. Die standardmäßigen Einstellungen für diesen Punkt sind in Abbildung 11.42 dargestellt. Im Dialog fallen drei Dinge sofort auf: Zum einen liegen die Shares-Werte weit unter den standardmäßigen Low-Werten, zum Zweiten liegt für den Arbeitsspeicher keine Reservierung vor, und als Drittes ist für die Reservierung der CPU ein Wert eingetragen, der je nach gewähltem Host unterschiedlich ist. Woher kommt nun dieser krumme Wert? Die Erklärung ist ganz einfach: Das System reserviert automatisch 10 % der Taktfrequenz der CPU. In diesem Beispiel hat der Host also eine oder mehrere CPUs mit 1,91 GHz Taktfrequenz. Die Anzahl der Cores pro CPU spielt an dieser Stelle keine Rolle.
640
Erweiterte Konfiguration
Abbildung 11.41
Einstellung der Hypervisor-Ressourcen
Abbildung 11.42
Ressourcenzuweisung für den Hypervisor
Kommen wir nun auf das Thema Priorisierung von Systemressourcen. Über die beiden Links oben rechts lässt sich die Ansicht variieren. Mit der Auswahl von simple werden keine zusätzlichen Einstellmöglichkeiten dargestellt. Wechseln
641
11.10
11
Konfiguration von ESX und vCenter
Sie dagegen in den Advanced-Modus, können Sie für jede der gelisteten SystemResource-Pool-Einträge die Konfiguration anpassen. Hier eine eindringliche Warnung von unserer Seite: Überlegen Sie sich genau, ob sie an dieser Stelle Änderungen vornehmen, ohne dass der VMware-Support Sie dazu auffordert. Gehen Sie einfach davon aus, dass sich VMware bei der Festlegung der Standardwerte Gedanken gemacht hat. Sie hebeln hier unter Umständen das System aus. Überlassen Sie den Spieltrieb anderen, und bewahren Sie Ihr System vor selbst verursachten Problemen.
11.10.4
Erweiterte Einstellungen
Jetzt kommen wir zu einem großen Abschnitt mit sehr vielen Unbekannten. Unter Software 폷 Advanced Settings erreichen Sie das folgende Fenster aus Abbildung 11.43.
Abbildung 11.43
642
Fenster der Advanced Settings
vCenter-Berechtigungen
Dieser Dialog bietet die Möglichkeit, viele Parameter des vSphere-Hosts anzupassen. Hier ändern Sie Einstellungen, wenn z. B. der Hardwarehersteller des Storages Sie dazu auffordert. Auch der VMware-Support verlangt von Ihnen hier möglicherweise eine Anpassung von Einstellungen, wenn es Probleme gibt. Viel mehr können wir Ihnen zu diesem Fenster aber nicht berichten, denn für die Funktion der einzelnen Parameter gibt es nur eine Kurzbeschreibung in der rechten Fensterhälfte. Mehr ist nirgends dokumentiert. Nur einige wenige Werte sind in unterschiedlichen Internetforen beschrieben. Auch hier gilt das, was wir schon im vorhergehenden Abschnitt geschrieben haben: Ändern Sie nur Werte, wenn der Hardware- oder Softwaresupport Sie dazu auffordert. Weniger ist auch hier mehr.
11.11
vCenter-Berechtigungen
Wir haben uns bis jetzt wie selbstverständlich im vCenter bewegt. Aber wie ist das möglich? Woher kennt der vCenter-Server den Benutzer-Account aus dem Betriebssystem? Diese Fragen möchten wir in diesem Abschnitt klären. VMware integriert den vCenter-Server nahtlos in das Benutzer-Gruppen-System des Windows-Betriebssystems. Ist der Server Mitglied eines Active Directorys (ADS), dann können auch Benutzer und Gruppen des ADS im vCenter berechtigt werden. Dass diese nahtlose Integration auch Probleme aufwirft, zeigen wir Ihnen später im Abschnitt 11.11.3. Lesen Sie jetzt, wie VMware mit den Berechtigungen im vCenter umgeht. Berechtigungssysteme führen immer zwei Komponenten zusammen: zum einen die Anwender, das können sowohl Benutzer als auch Gruppen sein (wir werden, der Einfachheit halber, nur noch von den »Benutzern« sprechen), zum anderen die Rechte. Beides wird in der Managementoberfläche zusammengeführt und bildet so ein Netzwerk für die Administration der gesamten Infrastruktur mit unterschiedlichen Rechteebenen. Keine Angst, Sie müssen bei der Installation keine Benutzer anlegen. Das vCenter sucht sich automatisch die Gruppe Administrators und verbindet sie mit der Administratorengruppe des vCenters. Dieser Mechanismus funktioniert übrigens auch, wenn die Administratorengruppe umbenannt wurde. Die Gruppe der lokalen Administratoren ist damit auch automatisch die HauptadministratorenGruppe im vCenter-Server. Rechte können an alle Objekte des vCenters gebunden werden. Wenn die Möglichkeit besteht, aktiv Rechte zu vergeben, dann ist auf der rechten Seite im
643
11.11
11
Konfiguration von ESX und vCenter
vCenter ein Reiter Permissions zu sehen. Hier führen Sie dann die entsprechenden Arbeiten durch (Abbildung 11.44).
Abbildung 11.44
Rechtevergabe im vCenter
Unsere Empfehlung ist, dass Sie Rollen – so nennt VMware die Berechtigungen – für alle benötigten Zwecke erstellen und passend benennen. Lassen Sie in der Domäne ebenfalls passende Gruppen erstellen. Diese beiden Elemente fügen Sie dann im vCenter zusammen. Alle Anwender, die Berechtigungen benötigen, müssen dann nur in die passende ADS-Gruppe geschoben werden, und schon stehen die Berechtigungen. Mit dieser Strategie lassen sich die Benutzer und Rechte sehr einfach einpflegen. Wie so oft kann man auch hier sagen: Weniger ist mehr. Vergeben Sie nur Rechte für Anwender, die Berechtigungen benötigen, und berechtigen Sie Mitarbeiter nicht schon im voreilenden Gehorsam.
11.11.1
Rollen
Nach der Neuinstallation stellt das System eine Reihe von Rollen zur Verfügung. Über den Menüpunkt Ansicht 폷 Verwaltung 폷 Rollen gelangen Sie in die Verwaltung der Benutzerrechte (Abbildung 11.45).
Abbildung 11.45
644
Management der Benutzerrechte
vCenter-Berechtigungen
Wie Sie sehen, stellt das System schon einige Benutzerrollen zur Verfügung. Tabelle 11.5 listet diese und beschreibt ihre Funktion. Rolle
Rollentyp
Bemerkungen
Kein Zugriff
System
Das Objekt ist nicht sichtbar, und es können keine Änderungen vorgenommen werden.
Nur Lesen
System
Alle Objekte und Reiter sind sichtbar mit Ausnahme der Console.
Administrator
System
Diese Rolle stellt den Benutzern alle Rechte zur Verfügung, es gibt keinerlei Einschränkungen.
Hauptbenutzer virtueller Maschinen
Beispiel
Administrative Rechte für die Arbeiten mit virtuellen Maschinen vergibt diese Rolle. Das schließt Hardwareänderungen und das Erstellen von Snapshots ein.
Benutzer virtueller Maschinen
Beispiel
Entspricht den Rechten des Hauptbenutzers virtueller Maschinen ohne die Rechte, Hardwareänderungen vorzunehmen und Snapshots zu erstellen.
RessourcenpoolAdministrator
Beispiel
Gibt das Recht, untergeordnete ResourcePools anzulegen und zu manipulieren.
VMware Consolidated Backup-Benutzer
Beispiel
Rechte für die Verwendung von VMware VCB
Datenspeicherkonsument
Beispiel
Erlaubt das Erstellen von virtuellen Festplatten oder Snapshots.
Netzwerkkonsument
Beispiel
Erlaubt die Manipulation der Netzwerkeinstellungen von VMs und Hosts.
Tabelle 11.5
Beschreibung der Rollentypen
Die drei System-Rollen lassen sich nicht ändern, Sie können aber eine Rolle kopieren und anschließend für Ihre Zwecke anpassen. Die Beispiel-Rollen sind manipulierbar. Trotzdem sollten Sie diese Rollen nicht ändern. Über das Kontextmenü erstellen Sie einfach einen Klon der Musterrolle, passen ihn mit dem EditBefehl an Ihre Bedürfnisse an und benennen ihn sprechend (Abbildung 11.46). Selbstverständlich können Sie Rollen auch komplett neu erstellen. Über Add Role legen Sie eine neue Rolle ohne jegliche Rechte an. Diese müssen Sie nur für Ihre Zwecke anpassen.
645
11.11
11
Konfiguration von ESX und vCenter
Abbildung 11.46
Anpassen einer Rolle
Die Rechte werden immer hierarchisch vererbt. Die Vererbungsreihenfolge zeigt Abbildung 11.47. Rootordner
DatacenterOrdner
Dataoenter
VM-Ordner
Vorlage
Cluster
Hostordner
Netzwerkordner
DatenspeicherOrdner
Host
Host
Netzwerk
Datenspeicher
VM
Abbildung 11.47
646
ResourcePool
Form der Rechtevererbung
vCenter-Berechtigungen
Wie Sie sehen, übernehmen die meisten Objekte ihre Rechte von einem Vorgänger; einzig die virtuelle Maschine wird von mehreren übergeordneten Objekten beeinflusst. Das müssen Sie berücksichtigen, wenn Sie auf virtuellen Maschinen Rechte vergeben wollen. Außerdem ist es wichtig zu wissen, dass für die Freischaltung von detaillierten Funktionen, wie z. B. das Anhängen einer ISO-Datei, auch auf dem Host und dem Datastore Rechte vorhanden sein müssen.
11.11.2
Benutzer einrichten
Wie oben bereits gesagt, werden im vCenter keine Benutzer erstellt. Der vCenterServer referenziert sich auf die Benutzerdatenbank des Betriebssystems oder des ADS. Bevor Sie Benutzern Rollen zuweisen, sollten Sie diese Rollen einrichten. Die Verbindung zwischen dem User und den Rollen erfolgt im vCenter unter dem Reiter Permissions eines Objekts (Abbildung 11.48).
Abbildung 11.48
Neue Rechte verlinken
Nach Aufruf des Dialogs öffnet sich ein Fenster, in dem Sie zuerst auf der rechten Seite die Nutzerrechte auswählen (Abbildung 11.49). Zur Kontrolle können Sie sich unterhalb der Auswahl die zugewiesenen Rechte noch einmal genau anschauen. Änderungen der Zugriffsrechte sind hier nicht mehr möglich. Über den Add-Button ordnen Sie dem ausgewählten Recht nun die Nutzer oder besser die Gruppen zu (Abbildung 11.50). Im Dropdown-Menü Domain bestimmen Sie die Benutzerdatenbank, entweder die lokale Benutzerdatenbank des vCenters oder das ADS.
647
11.11
11
Konfiguration von ESX und vCenter
Abbildung 11.49
Einstellen der Rolle
Abbildung 11.50
Auswahl der Gruppe
648
vCenter-Berechtigungen
Mit dem Abschluss des Dialogs wird der Zusammenhang im Hauptfenster dargestellt (Abbildung 11.51). Selbstverständlich können Sie auch mehrere Objekte hinzufügen und mit dem ausgewählten Recht verbinden.
Abbildung 11.51
Auswahl der Gruppen bzw. Benutzer
Achten Sie auf die Auswahl unten rechts im Fenster. Über die Aktivierung von Propagate to Child Objects werden die Rechte in sämtliche untergeordnete Objekte weitergereicht.
Abbildung 11.52
Neu eingerichtete Rechte für die Gruppe VM-Admins
Das neu angelegte Recht ist nun in der Oberfläche sichtbar. Eine große Hilfe ist an dieser Stelle, dass in der rechten Spalte angezeigt wird, an welcher Stelle der Ursprung des Rechtes liegt.
649
11.11
11
Konfiguration von ESX und vCenter
Benutzerrechte werden regelmäßig vom System validiert. Im vCenter können Sie das Zeitintervall einstellen. Im Standard werden die Accounts einmal am Tag (Abbildung 11.53) und selbstverständlich bei einem Neustart des ManagementServers überprüft.
Abbildung 11.53
Berechtigungsvalidierung
Lassen Sie uns näher darauf eingehen, wie die Überprüfung der Accounts funktioniert. Wird ein vorhandener User Meier umbenannt in Meier-Schmitz, dann werden bei der nächsten Validierung die Rechte von Meier gelöscht, weil es den User nicht mehr gibt. Verlässt eben dieser Herr Meier das Unternehmen und wird sein Account gelöscht, dann werden nach der nächsten Synchronisierung mit der Domäne alle Rechte von Herrn Meier gelöscht. Wird aber vor der nächsten Überprüfung ein Benutzer mit demselben Namen, also wieder Meier, neu angelegt, dann erhält der neue User die Rechte im vCenter, die der alte Benutzer schon hatte. Die Ursache für diesen Umstand liegt darin, dass das vCenter nicht die SID (Security Identifier) des ADS auswertet. Aus diesem Grund sollten Sie das Refresh-Intervall zum AD verkürzen. Aus unserer Sicht ist ein Zeitfenster von zwei Stunden empfehlenswert.
650
vCenter-Berechtigungen
11.11.3
Absicherung gegenüber dem Betriebssystem
Wie schon am Anfang des Abschnitts angedeutet, kann es ein Problem sein, dass automatisch die lokalen Administratoren auch die Administratoren im vCenter sind. Es hängt nicht unbedingt von der Größe eines Unternehmens ab, wie die Betriebsaufgaben aufgeteilt werden. Die Administratoren des Betriebssystems sind nicht unbedingt auch die Personen, die die virtuelle Landschaft administrieren. Nicht selten werden die Betriebssystemadministratoren in Gruppen zusammengefasst und diese Gruppen in die lokale Gruppe der Administratoren eines jeden Servers aufgenommen. Folgerichtig sind jetzt alle Mitglieder der Gruppe auch Administratoren im vCenter. Dieses Problem lässt sich nicht umgehen, indem Sie die Administratorengruppe vor der Installation umbenennen. Die Installationsroutine stellt das selbständig fest und verlinkt die umbenannte Gruppe mit den vCenter-Administratoren. Es gibt aber einen Weg, diesen Sachverhalt zu umgehen. Installieren Sie zuerst das vCenter normal auf einem unterstützten System. Anschließend legen Sie nach einem Neustart des Systems eine neue Gruppe auf Betriebssystemebene an; nennen wir die Gruppe VC-Admins. In diese Gruppe nehmen Sie nun einen vorhandenen oder neu angelegten lokalen User auf. Alternativ wählen Sie eine Gruppe von vCenter-Administratoren aus dem Active Directory aus. Melden Sie sich jetzt mit einem User an, der Mitglied der lokalen Administratorengruppe ist. In der Wurzel des vCenters berechtigen Sie die Gruppe VC-Admins mit der Rolle der Administratoren. Achten Sie darauf, dass Sie die Rechte durchpropagieren. Anschließend melden Sie sich wieder ab und melden sich neu am vCenter mit einem Benutzer aus der Gruppe der VC-Admins an. Auf der obersten Ebene löschen Sie die Gruppe der Administratoren. In der Übersicht sehen Sie jetzt nur noch die neu angelegte Gruppe der VC-Admins.
Abbildung 11.54
Anpassung der administrativen Rechte
Es sind jetzt nur noch Anwender im vCenter berechtigt, die auch – über Gruppen oder direkt – Mitglied in der Gruppe VM-Admins sind. Für alle anderen Rechteebenen können Sie ebenfalls Gruppen anlegen und diese mit angemessenen Rechen versorgen.
651
11.11
11
Konfiguration von ESX und vCenter
11.12
Performance-Daten des Hosts im vCenter
In der virtuellen Umgebung ist es wichtig, die Leistungsdaten der Landschaft im Auge zu behalten. Zur Überwachung der Leistungsdaten gibt es im vSphereClient den Reiter Performance.
Abbildung 11.55
Übersicht der Host-Leistungsdaten
Der Administrator kann sich Leistungsdaten anzeigen lassen für das Datacenter, den Cluster, den Host, den Resource-Pool, die vApp und die virtuelle Maschine. In Tabelle 11.6 zeigen wir Ihnen, welche Diagrammoptionen wo angezeigt werden können. Die Diagrammoptionen für die virtuelle Maschine listen wir an dieser Stelle der Vollständigkeit halber mit auf. Auf die Daten der VM gehen wir aber im Kapitel für die virtuelle Maschine (vgl. Kapitel 13, »Virtuelle Maschinen«) mit ein. Sie müssen an dieser Stelle unterscheiden, ob Sie eine Echtzeitdarstellung möchten oder ob Sie ein längerfristiges Intervall betrachten wollen. Echtzeitdarstellungen sind nur beim Host und bei der VM möglich. Tabelle 11.6 zeigt die Optionen für die Echtzeitbeobachtung.
652
Performance-Daten des Hosts im vCenter
Diagrammoptionen
Beschreibung
Host
Cluster-Service CPU Disk Memory Network System
VM
CPU Disk Memory Network System
Tabelle 11.6
Zusammenhang vCenter-Objekte und Leistungsdaten
Tabelle 11.7 zeigt die Objekte, die nur eine Langzeitbetrachtung erlauben. Diagrammoptionen
Beschreibung
Datacenter
VM Operations
Cluster
Cluster-Service CPU Memory VM Operations
Resource-Pool
CPU Memory
vApp
CPU Memory
Tabelle 11.7
Zusammenhang vCenter-Objekte und Leistungsdaten
Für jede aufgelistete Diagrammoption gibt es weitere Unterpunkte. So können Sie die zu beobachteten Objekte auswählen und die passenden Leistungsindikatoren aktivieren. Es wäre müßig, alle Permutationen für alle Punkte aufzuzählen. Sollten Sie die nötigen Informationen benötigen, möchten wir an dieser Stelle auf die VMware-Dokumentationen verweisen.
653
11.12
11
Konfiguration von ESX und vCenter
Abbildung 11.56
Übersicht der Performance-View
Das Fenster gliedert sich in zwei große Abschnitte. Im oberen Abschnitt sehen Sie die grafische Darstellung der ausgewerteten Performance-Daten. In dem unteren Drittel wird Ihnen angezeigt, welche Daten zur Darstellung kommen. Jedem Parameter ist ein farbiges Kästchen vorangestellt, das die Farbe des zugehörigen Diagrammelements zeigt. Wandern Sie mit der Maus über das Diagramm. Es wird ein kleines Übersichtsfenster eingeblendet, das Ihnen nähere Informationen über den ausgewählten Zeitpunkt gibt. Außer Datum und Uhrzeit sehen Sie die Werte des Zeitpunkts. Dabei werden der Farbcode des Parameters, die Beschreibung und der absolute Wert angezeigt. Oben auf der rechten Seite haben Sie fünf Auswahlmöglichkeiten. Das Dropdown-Menü bietet die Option, eines von mehreren Diagrammen zu wählen. Die nächsten drei folgenden Symbole sprechen für sich selbst – Ausdrucken, Aktualisieren und Abspeichern des Diagramms ist dort möglich. Durch Klick auf das Symbol ganz rechts in der Zeile wird die Anzeige in einem eigenständigen Fenster geöffnet. Bis hier wurden die Auswertungen genutzt, die VMware in der Standardeinstellung zur Verfügung stellt. Sind für Sie auch andere Kombinationen von Messwerten interessant, gelangen Sie über den Link Chart Options in ein Fenster zur Anpassung der Anzeige (Abbildung 11.57). Auf der linken Seite des Fensters wählen Sie den anzuzeigenden Parameter und das gewünschte Zeitintervall aus. Die Beschriftung der Auswahl ist eigentlich eindeutig. Nutzen Sie die Custom-Auswahl, dann ist unten links das Zeitintervall individuell einstellbar.
654
Performance-Daten des Hosts im vCenter
Abbildung 11.57
Anpassung der Diagrammanzeige
Auf der rechten Seite setzen Sie dann die Objekte und die zugehörigen Counter. Ihre selbsterstellten Ansichten lassen sich über den Button unten rechts abspeichern und anschließend über Manage Chart Settings anzeigen oder löschen. Alle gespeicherten Einstellungen können Sie später unter ihrem Namen auch direkt im Performance-Fenster aufrufen. Performance-Messwerte Wie Sie sich die verschiedenen Messwerte anzeigen lassen, haben wir nun erläutert. Nun stellt sich die Frage, wie Sie mit den angezeigten Messwerten umgehen. In diesem Abschnitt wollen wir nur auf den Host eingehen. Im Kapitel für die virtuellen Maschinen (vgl. Kapitel 13) werden wir die Auswertung der VM-Performance-Daten gesondert erläutern.
655
11.12
11
Konfiguration von ESX und vCenter
CPU-Performance Als Erstes betrachten wir die Messwerte für die durchschnittliche CPU-Last des Hosts. Liegt diese im Durchschnitt nicht über 75 % und treten nicht häufig Spitzen von über 90 % auf, dann müssen Sie sich keine Gedanken machen. Falls die Schwellenwerte überschritten werden, müssen Sie kontrollieren, ob die HostCPU in die Sättigung geht. Dazu kontrollieren Sie die CPU Ready-Werte aller auf dem betroffenen Host liegenden virtuellen Maschinen. Überschreitet ein Wert 20 000 ms, dann läuft die CPU zeitweise in der Sättigung. Dadurch werden durchaus auch andere VMs beeinflusst. Können Sie das Problem durch die Performance-Auswertung mit einer VM assoziieren, dann sollten Sie sich näher mit dieser VM beschäftigen. Ein einfacher Weg ist an dieser Stelle, die Anzahl der Host-CPUs zu erweitern oder die Anzahl der virtuellen Maschinen zu verringern. Alternativ machen Sie den Host zum Mitglied eines DRS-Clusters; so kann die VM bei höherem Ressourcenbedarf verschoben werden. Der bessere Weg ist aber, sich mit den VMs näher zu beschäftigen, die die Probleme verursachen. Besonders die erste physische CPU sollten Sie im Auge behalten, wenn die Variante vSphere mit Service Console zum Einsatz kommt. Diese läuft auf der ersten CPU des Hosts. Liegt die CPU-Last über 75 % oder liegt sie 20 % über dem Durchschnitt der Host-Auslastung, sollten Sie die Service Console kontrollieren. Schauen Sie sich z. B. zusätzlich installierte Software an, vielleicht verursacht sie das Lastverhalten. Memory-Performance Welches sind nun die Punkte, die beim Arbeitsspeicher berücksichtigt werden müssen? Wie schon in Kapitel 2, »vSphere-Architektur«, beschrieben, erlaubt VMware, mehr Arbeitsspeicher an virtuelle Maschinen zu vergeben, als physisch verbaut ist. Mit dem Ballooning wird dieser Speicher zurückgefordert. Kann nicht genügend Speicher akquiriert werden, muss geswappt werden. Das sind die Werte, die auch bei den Performance-Auswertungen wichtig sind. Hinzu kommt der Wert Shared bzw. Shared Common. Der letztere Wert zeigt die Größe des Bereichs an, in dem alle virtuellen Maschinen ihre gemeinsamen Speicherseiten ablegen. In Shared findet sich die Summe an Speicher wieder, die durch das Page-Sharing eingespart wurde. Der Wert swap used deklariert die Speichermenge, die ins File-System des Hosts geswappt wird. Je stärker das System Speicher auf die Festplatte auslagert, desto stärker leidet die Performance.
656
Performance-Daten des Hosts im vCenter
Ballon zeigt an, wie viel Speicher aktuell von dem vmmemctl-Treiber aus den VMware Tools genutzt wird. Hier sehen Sie nur dann Daten, wenn Sie mit Memory-Overcommitment arbeiten. Storage-Performance Die Punkte, die Sie berücksichtigen müssen, damit die Anbindung an den Storage performant ist, und was Sie tun müssen, damit das auch so bleibt, lesen Sie im Storage-Kapitel. Die Performance-Werte des Storages können Sie am besten über die Auswertetools des Storages anzeigen und messen. Diese Werte zeigen aber die GesamtPerformance an aller angeschlossenen Server an, nicht nur von den VMware-Systemen. Über das Performance-Chart und die Werte Read Latancy und Write Latency wird sichtbar, wie lange die Abarbeitung der Lese- bzw. Schreibzyklen dauert. Der Usage-Wert ist bei System mit mehreren unterschiedlichen Storage-Anbindungen nicht ganz so aussagekräftig. Die Anzeige erfolgt nur für den gesamten Host und nicht für die einzelne LUN oder den einzelnen Storage. Network-Performance Hier sehen Sie, wie der Durchsatz auf den Netzwerkschnittstellen ist. Über Usage wird angezeigt, welche Datenmengen über die einzelnen Adapter fließen. Dieser Wert hilft zu erkennen, ob die Anbindung der Komponenten ausreichend ist oder ob die Bandbreite erhöht werden muss. Sollte der Durchsatz an die Grenze gehen – das ist schön dadurch zu sehen, dass sich im oberen Bereich eine gerade Linie zeigt –, dann ist zu kontrollieren, ob und wann dieses Phänomen auftritt. Erst nach einer solchen Analyse sind Gegenmaßnahmen möglich, z. B. eine Erhöhung der Bandbreite. Solche Werte können aber auch entstehen, weil gerade besondere einmalige Aktionen im Netzwerk durchgeführt werden. Bei der Auswertung der Datenbandbreite müssen Sie berücksichtigen, dass der praktische maximale Durchsatz nie die theoretische Grenze erreicht. Über die Parameter DroppedRX und DroppedTX lassen sich die verlorenen Pakete darstellen. Diese Werte sind bei öfter auftretenden Übertragungsfehlern hilfreich.
657
11.12
11
Konfiguration von ESX und vCenter
11.13
Weitere Funktionen des vCenters
In diesem Abschnitt möchten wir die vCenter-Funktionen erläutern, auf die wir bis jetzt aber noch nicht eingegangen sind. Lassen Sie uns Ihnen noch einen kleinen Hinweis geben: Die Suchfunktion, die immer oben rechts im vCenter-Fenster zu sehen ist, ist sehr umfangreich und komplex, bringt Sie aber sehr schnell ans Ziel. Kommen wir nun zu den offenen Anzeigemöglichkeiten beim vCenter-Server.
11.13.1
Storage Views
Der Reiter Storage Views gibt Ihnen ausführlich Auskunft über – wie sollte es anders sein – den Storage. Der Reiter steht Ihnen zur Verfügung bei den Objekten Datacenter, Cluster, Host und VM. Die Anzeige ist neu mit der aktuellen Version von VMware vSphere und stellt Ihnen die Informationen in Listenform zur Verfügung. In Abbildung 11.58 ist zu sehen, dass alle Informationen angezeigt werden, die den Administrator interessieren. Der freie und belegte Plattenplatz wird genauso gelistet wie die Belegung durch Snapshots und die Anzahl der virtuellen Festplatten-Files. In Abbildung 11.59 sehen Sie, welche zusätzlichen Anzeigemöglichkeiten Sie haben.
Abbildung 11.58
Auflistung der Datastores eines Hosts
Genügen Ihnen diese Informationen nicht, dann passen Sie die Ansicht für Ihren Informationsgrad an, indem Sie einfach die Ausgabe entsprechend ändern (Abbildung 11.60). Alle Ansichten, die Sie bis jetzt gesehen haben, waren aus Sicht des Hosts. Sie können aber auch die Sichtweise der virtuellen Maschine wählen und so sehen, wie der Storage dort angebunden ist (Abbildung 11.61).
658
Weitere Funktionen des vCenters
Abbildung 11.59
Anzeigemöglichkeiten
Abbildung 11.60
Anpassung der Ansichten
Abbildung 11.61
Storage-Ansicht der virtuellen Maschinen
659
11.13
11
Konfiguration von ESX und vCenter
Auch hier finden Sie alle Informationen, die mit dem Storage und der Anbindung der VM zu tun haben. Sollten Ihnen aber Tabellen nicht gefallen und benötigen Sie eine managementähnliche Ansicht, kein Problem – nutzen Sie doch einfach die Kartenansicht der Daten.
Abbildung 11.62
Grafische Ansicht der Anbindung
Alternativ füllen Sie mit den Daten eine Grafik, die Ihnen eine globale Übersicht der Zusammenhänge darstellt. Die anzuzeigenden Komponenten wählen Sie oben rechts aus. In dem Fenstersegment unterhalb stellen Sie den Zoom-Faktor ein. Die Darstellung umfasst den gesamten Weg, vom Host bis zum Storage. Die Anzahl der Pfade ist genauso sichtbar wie die Netzwerkkarte, über die der iSCSIStorage angesprochen wird. Die Adressen sind ebenfalls eingeblendet. Auch wenn hier die Karte aus Sicht des Hosts dargestellt wird, ist es selbstverständlich auch möglich, den Standpunkt zu wechseln und die Sicht der VM einzunehmen.
660
Weitere Funktionen des vCenters
11.13.2
Maps
Im Gegensatz zu den Storage Views ist die Auswahl des Reiters Maps an allen Objekten möglich. Sehen Sie eine solche Übersicht, fällt Ihnen sofort die Ähnlichkeit zu den Storage Views auf. Einen Unterschied gibt es schon: Das Zoom-Fenster und die Auswahl sind vertauscht. Sonst ist die gesamte Funktionalität identisch, zeigt aber zusätzliche Komponenten an.
Abbildung 11.63
Die grafische Übersicht der virtuellen Landschaft
Bei unserer relativ kleinen Testlandschaft ist das Bild schon sehr unübersichtlich, wenn man alle Verbindungen anzeigen lässt. Weniger ist auch an dieser Stelle mehr. Überlegen Sie genau, auf welchem Objekt Sie die Ansichten wählen und welche Objekte Sie anzeigen lassen wollen.
11.13.3
Events
Besteht die Notwendigkeit, einmal zu einem späteren Zeitpunkt nachzuvollziehen, wann welche Aktion lief und wie sie abgeschlossen wurde, dann finden Sie die Information unter dem Menüpunkt View 폷 Management 폷 Event.
661
11.13
11
Konfiguration von ESX und vCenter
Abbildung 11.64
Anzeige der Events im vCenter
Im Hauptfenster des Clients werden zwar alle Ereignisse angezeigt, doch die Anzeige wird nach relativ kurzer Zeit wieder gelöscht. Damit sind die Informationen aber nicht verloren – im Eventfenster können Sie sich alles noch einmal anschauen. Damit bei der Menge der Ereignisse die Forschungen zeitlich nicht ausufern, ist oben eine Suchfunktion implementiert, über die Sie detailliert das Log durchsuchen können. Bei Bedarf exportieren Sie über Export Events eine definierte Menge von Ereignissen. Die Auswahlmöglichkeiten sind sehr granular: Die Daten lassen sich getrennt nach System oder. Anwender und aufgeschlüsselt nach Fehlern, Informationen und Warnungen speichern. Dabei ist es sowohl möglich, nur die Daten aus einem bestimmten Zeitintervall zu inkludieren als auch eine definierte Anzahl von Ereignissen auszuwählen.
662
Weitere Funktionen des vCenters
Abbildung 11.65
11.13.4
Export von Ereignissen
Scheduled Tasks
Über den Menüpunkt View 폷 Management 폷 Scheduled Task gelangen Sie zu einer Liste mit allen Aktionen, die automatisch in der virtuellen Infrastruktur ablaufen.
Abbildung 11.66
Ansicht der Scheduled Tasks
Als zusätzliche Information werden die letzte Ausführung und die nächste Fälligkeit der entsprechenden Aktion angezeigt.
663
11.13
11
Konfiguration von ESX und vCenter
In diesem Fenster können Sie auch neue Tasks anlegen. Mit den Buttons New, Properties und Remove manipulieren Sie die Tasks in diesem Fenster. Die Bezeichnung der einzelnen Schaltflächen lassen keine Fragen offen, deshalb möchten wir nur auf den New-Button eingehen. Aktivieren Sie diesen, öffnet sich ein Eingabefenster, über das Sie einen neuen Task erstellen.
Abbildung 11.67
Erstellen eines neuen Tasks
VMware gibt eine Reihe von Möglichkeiten für die Neuerstellung von Tasks vor. Eigene können nicht kreiert werden. Hier die Liste der möglichen Tasks: 왘
Change the power state of a virtual machine
왘
Clone a virtual machine
왘
Deploy a virtual machine
왘
Migrate a virtual machine
왘
Create a virtual machine
왘
Make a snapshot of a virtual machine
왘
Add a host
왘
Change resource settings of resource pool or Virtual Machine
왘
Check compliance of a profile
왘
Import a machine
왘
Export a virtual machine
왘
Scan for updates
왘
Remediate
Je nach Auswahl des entsprechenden Tasks öffnet sich das Fenster, das benötigt wird, um die Informationen zur späteren Ausführung zu sammeln. So wird z. B. der vCenter Converter Wizard gestartet, wenn ein Server importiert werden soll.
664
Weitere Funktionen des vCenters
11.13.5
System-Logs
Ein weiterer sehr wichtiger Punkt ist die Auswertung von Log-Dateien beim vCenter-Server. Auf diese Funktion sind Sie angewiesen, wenn es Unregelmäßigkeiten gibt. Dabei ist es unerheblich, ob Sie selbst nähere Informationen suchen oder ob ein Supporter Informationen aus der virtuellen Landschaft benötigt. Zu dem Fenster gelangen Sie über View 폷 Administration 폷 System Logs. Abbildung 11.68 zeigt Ihnen die Ansicht.
Abbildung 11.68
Anzeige der Log-Dateien
Hier können Sie das zu betrachtende Log auswählen. Die Schaltflächen in der oberen Reihe sprechen für sich. Auch hier gibt es eine Suchfunktion, die sehr hilfreich ist, wenn Sie größere Log-Dateien durchsuchen müssen. Ist es notwendig, für eine Fehlerauswertung ein aktuelles definiertes Log zu ziehen, dann stoßen Sie den Vorgang über den Link oben links an (Abbildung 11.69). Hier lässt sich genau angeben, welche Einträge in dem Export enthalten sein sollen. Das File kann direkt ausgewertet oder dem Support übermittelt werden.
665
11.13
11
Konfiguration von ESX und vCenter
Abbildung 11.69
11.13.6
Export von Log-Dateien
Sessions
Für den vCenter-Administrator ist es wichtig zu sehen, welche User sich am vCenter angemeldet haben. Die Frage, wie lange einzelne Anwender angemeldet sind, ohne etwas gemacht zu haben, wird ebenfalls beantwortet. Über View 폷 Administration 폷 Sessions gelangen Sie zum Ziel (Abbildung 11.70).
Abbildung 11.70
Verbindungen der Anwender zum vCenter
Außerdem sehen Sie sofort, wenn User doppelt angemeldet sind. Zur Ansicht kommen der Anwendername, die Anmeldezeit und der Status der Sitzung. Zusätzlich gibt es die Möglichkeit, einen »Tip of the Day« einzustellen. Dieser eignet sich besonders dafür, Wartungsarbeiten anzukündigen oder Ähnliches. Erstellen können Sie diese Nachricht über den Menüpunkt Administration 폷 Edit 폷 Message of the Day ...
666
Weitere Funktionen des vCenters
11.13.7
Health Status
Der Health Status befindet sich auf einem eigenen Reiter, der nach der Auswahl eines Hosts sichtbar ist. Dieses Fenster zeigt den »Gesundheitsstatus« der Hardware an (Abbildung 11.71). Die Informationen holt sich das vCenter über den Open-IPMI-Standard (Intelligent Platform Management Interface).
Abbildung 11.71
Hardware Status des vSphere-Hosts
Jetzt werden Sie sich vielleicht darüber wundern, dass bei unterschiedlichen Hardwareherstellern auch unterschiedliche Daten angezeigt werden. Das hängt damit zusammen, wie der Hardwarehersteller das IPMI implementiert hat. Bei einer reinen Open-IPMI-Implementierung sehen Sie nicht nur die Angaben, wie sie in Abbildung 11.71 dargestellt sind, sondern auch den RAID-Controller, die Festplatten und weitere Angaben. Der Vorteil bei dieser Implementierung ist, dass keine hardwarespezifischen Tools installiert werden müssen, damit alle Status angezeigt werden. Der Hersteller HP hat z. B. eine eigene Implementierung von IPMI, weswegen nicht alle Hardwareinformationen angezeigt werden, wenn die HP-SIM-Treiber nicht installiert sind.
11.13.8
Dienste anzeigen
Mit dem vCenter der Version 4 hat VMware eine zusätzliche Funktion eingeführt, die es dem Administrator erleichtern soll, im Fehlerfall die Suche besser
667
11.13
11
Konfiguration von ESX und vCenter
einzugrenzen. Über View 폷 Administration 폷 vCenter Service Status erreichen Sie diese Übersicht. Hier wird der Status aller vom vCenter genutzten Dienste angezeigt. In Abbildung 11.72 laufen derzeit alle Dienste einwandfrei.
Abbildung 11.72
11.14
Status der vCenter-Dienste
vCenter-Konfigurationseinstellungen
Jetzt möchten wir noch auf die restlichen Konfigurationseinstellungen des vCenter-Servers eingehen, die wir bis jetzt noch nicht angesprochen haben. Das Konfigurationsmenü gehen wir einfach von oben nach unten durch. Der Aufruf erfolgt über den Menüpunkt View 폷 Administration 폷 Server Settings. Achten Sie bitte auf die Anzeigen im Konfigurationsfenster. Ist nach einer Anpassung von Konfigurationsparametern ein Reboot nötig, dann wird dies im Fenster angezeigt.
668
vCenter-Konfigurationseinstellungen
Abbildung 11.73
Einstellen der Intervalle für das Sammeln der Auswertungsdaten
Die Einstellungen betreffen das Sammeln der Performance-Daten. Die Standardeinstellungen sind im Fenster sichtbar. Es gibt an dieser Stelle vier unterschiedliche Regeln, um die Daten zu sammeln und vorzuhalten. Über den Edit-Button können Sie die Einstellungen manipulieren. Denken Sie daran, dass ein Ändern der Werte die Größe der vCenter-Datenbank direkt beeinflusst. Dabei ist es sehr hilfreich, dass in dem Fenster sofort angezeigt wird, wie sich die Größe der Datenbank ändert, wenn Sie Parameter anpassen. Sie können nicht nur das Intervall und die Aufbewahrungszeit einstellen, sondern auch die Sammeltiefe der Daten. In Tabelle 11.8 zeigen wir, welche Informationen wann gesammelt werden. PerformanceLevel
Informationen
1
Die Grundmetriken werden über dieses Level gesammelt. Das sind die durchschnittliche Nutzung von CPU, Arbeitsspeicher, Festplatte und Netzwerk. Zusätzlich werden Systemlaufzeit, Systemtakt und DRSMetriken protokolliert. Geräte werden in diesem Level nicht geloggt.
2
Level 2 enthält Level 1, wobei zu den Metriken CPU, Arbeitsspeicher, Festplatte und Netzwerk alle Informationen gesammelt werden, einschließlich des letzten Rollup-Typs. Einzige Ausnahme sind die Minund Max-Werte des Rollup-Typs.
Tabelle 11.8
Liste der Statistics-Level
669
11.14
11
Konfiguration von ESX und vCenter
PerformanceLevel
Informationen
3
Hier ist ebenfalls Level 2 komplett inkludiert, einschließlich der Geräte. Auch hier bilden die Min- und Max-Werte der Rollup-Typen die Ausnahme.
4
Dieses Level sammelt alle Metriken, die das vCenter zur Verfügung stellt.
Tabelle 11.8
Liste der Statistics-Level (Forts.)
Es folgt die Konfiguration der Runtime Settings. Hier ist die ID des vCenters hinterlegt, der Name und die IP-Adresse können eingetragen werden.
Abbildung 11.74
Einstellungen für die Runtime Settings
Die Unique ID muss einen Wert zwischen 0 und 63 haben. Dieser Wert wird bei der Installation zufällig vergeben. Die beiden anderen Einträge sprechen für sich. Vergessen Sie nicht, die Mail-Einträge im vCenter-Server vorzunehmen. Neben dem Mail-Server tragen Sie eine E-Mail-Adresse, besser noch eine Verteilerliste ein (Abbildung 11.75). An diesen Empfänger werden die Benachrichtigungen gesendet, die das System verschickt.
670
vCenter-Konfigurationseinstellungen
Abbildung 11.75
Einstellung der Mail-Benachrichtigung
Sollen die vom vCenter generierten SNMP-Nachrichten auf einem zentralen Managementsystem ausgewertet werden, dann sind die Parameter passend zu wählen.
Abbildung 11.76
Konfiguration der SNMP-Empfänger
671
11.14
11
Konfiguration von ESX und vCenter
Es ist dabei nicht nur möglich, ein Ziel zu konfigurieren. Das vCenter unterstützt bis zu vier unterschiedliche Ziele für SNMP-Traps. Die Zugriffsports für den vCenter-Server lassen sich ebenfalls anpassen. Als Standard sind für HTTP Port 80 und für HTTPS Port 443 festgelegt.
Abbildung 11.77
Kommunikationsports des vCenters
Denken Sie daran, eine Änderung in der Zugriffsmetrik zu dokumentieren, damit auch die Kollegen wissen, was zu tun ist, wenn der Installateur bei Anpassungen nicht dabei ist. Für die Kommunikation mit den Objekten in der virtuellen Infrastruktur werden im vCenter Timeout-Werte gesetzt.
Abbildung 11.78
Zeitüberschreitungseinstellungen
Es werden zwei Vorgänge parametriert: der normale Vorgang und der lange Vorgang. Beide Werte sollten logischerweise nicht auf Null gesetzt werden. Wichtig ist die Einstellung im Dialog für das Log-Level. An dieser Stelle bietet das vCenter sechs Optionen (Abbildung 11.79). Je nach ausgewähltem Level werden mehr oder weniger Daten gesammelt. Lassen Sie uns kurz in Tabelle 11.10 die unterschiedlichen Level auflisten.
672
vCenter-Konfigurationseinstellungen
Abbildung 11.79
Einstellung des Log-Levels
Log-Level
Informationen
None
Mit dieser Auswahl wird das Logging komplett abgeschaltet.
Error
Diese Option loggt nur Fehlereinträge.
Warning
Wählen Sie diesen Punkt, wenn Sie nur Warnungen und Fehler sehen wollen.
Information Es werden Informationen, Warnungen und Fehler angezeigt. Das ist das Standard-Log-Level. Verbose
Dieses Level entspricht dem der Information, aber mit ausführlicherem Inhalt.
Trivia
In diesem Level wird der Informationsinhalt gegenüber dem VerboseLevel noch weiter erhöht.
Tabelle 11.9
Auflistung der möglichen Log-Level
Passen Sie das Level nur an, wenn es notwendig ist; die Datenmengen nehmen sonst einen enormen Umfang an. Die Anzahl der Datenbankverbindungen ist nach der Installation des vCenter-Servers auf 10 gesetzt. Der Dialog bietet an, den Wert zu ändern (Abbildung 11.80). Erhöhen Sie den Wert, wenn viele zeitkritische Aktionen laufen, was die Kommunikation zwischen vCenter und DB verbessert. Natürlich ist es auch möglich, die Anzahl der Verbindungen zu reduzieren, etwa wenn diese Verbindungen hausintern verrechnet werden. Wünschen Sie, dass die Datenbankgröße nicht zu stark anwächst, begrenzen Sie über die Database Retention Policy das Wachstum der Datenbank. Das Speichern der Events und Tasks kann hier eingeschränkt werden (Abbildung 11.81).
673
11.14
11
Konfiguration von ESX und vCenter
Abbildung 11.80
Anzahl von parallelen Datenbankverbindungen
Abbildung 11.81
Beschränkung der Datenbankgröße
Berücksichtigen Sie, dass nach der Aktivierung der Retention Policy nicht mehr alle Aktionen in der virtuellen Landschaft nachvollzogen werden können. Es ist also abzuwägen, was wichtiger ist, eine Nachvollziehbarkeit aller Aktionen oder das Einsparen von Festplattenplatz. Unter SSL Settings ist manipulierbar, wie das vCenter mit den vSphere-Hosts kommuniziert. Vorkonfiguriert ist eine Verbindung mit der Nutzung von SSLZertifikaten. Es ist nicht empfehlenswert, diese Einstellung zu ändern (Abbildung 11.82). Zu guter Letzt bietet VMware mit den Advanced Settings eine Option, zusätzlich Parameter einzufügen, die Sie nicht direkt über eine GUI einpflegen können (Abbildung 11.83). Trotzdem werden hier auch die Parameter angezeigt, die über die GUI geändert werden können, die wir bis zu dieser Stelle besprochen haben. Alle Werte können Sie in den Advanced Settings einsehen, aber nicht manipulieren. Es besteht nur die Option, neue Werte einzutragen und über Add hinzuzufügen.
674
vCenter-Konfigurationseinstellungen
Abbildung 11.82
Aktivierung von SSL-Zertifikaten
Abbildung 11.83
Advanced Settings des vCenters
675
11.14
11
Konfiguration von ESX und vCenter
11.15
Einrichten von Alarmen
Abschließend möchten wir in diesem Abschnitt auf die Alarmierungsfunktionen im vCenter-Server eingehen. Vergleicht man die Version vCenter 4.x mit der Vorgängerversion, fällt auf, dass sich die Anzahl der möglichen Alarme stark erhöht hat. Des Weiteren besteht auch die Möglichkeit, eigene Alarme zu kreieren und so die Alarmierung an die eigenen Bedürfnisse anzupassen. Alarme können Sie mit fast jedem Objekt in der Infrastruktur verbinden, als da wären: 왘
Datacenter
왘
Cluster
왘
Host
왘
Datastore
왘
Network
왘
Distributed Virtual Switch
왘
Distributed Virtual Switch Portgroup
왘
Virtual Machine
Dabei stehen Ihnen insgesamt 34 vordefinierte Alarme zur Verfügung. Es hängt nur vom Objekt ab, welche Alarme Sie nutzen können. Unterschieden wird dabei zwischen den Definitions, die hier im rechten Fensterabschnitt zu sehen sind, und den Triggered Alarms. Der letzte Punkt zeigt an, welche Alarme an dem betreffenden Objekt auch aktiv sind. Bevor wir nun darauf eingehen, wie Sie Alarme erstellen, sollten wir uns anschauen, wie VMware die Struktur der Alarme angelegt hat. Auch wenn Alarme nur an bestimmte Objekte gebunden werden können, so wurden sie doch alle auf der Wurzelebene des vCenters definiert. Das ist auch schön in Abbildung 11.84 zu erkennen. In der mittleren Spalte ist leicht zu sehen, wo ein Alarm definiert wurde. Nur an diesem Definitionsort kann ein einmal definierter Alarm manipuliert werden. Dies gilt auch für die vordefinierten Alarme. Unsere Empfehlung ist, bei vordefinierten Alarmen nur die Schwellenwerte anzupassen. Bei weitergehenden Änderungen sollten Sie immer neue Alarme anlegen. Am einfachsten ist es, die Definitionen immer in der vCenter-Wurzel anzulegen und dann passend weiter unten mit den Objekten zu verbinden.
676
Einrichten von Alarmen
Abbildung 11.84
Übersicht der Alarmdefinitionen
Alarme werden erst in der Ansicht Triggered Alarms sichtbar, wenn sie aktiviert wurden. Neu erstellt werden Alarme über das Kontextmenü der Definitions-Ansicht. Es öffnet sich ein Dialog, in dem die weiteren Parameter eingegeben werden (Abbildung 11.85). Legen Sie einen neuen Alarm an, sind diverse Grundeinstellungen vorzunehmen.
Abbildung 11.85
Grundparameter eines Alarms
677
11.15
11
Konfiguration von ESX und vCenter
Neben einem eindeutigen Namen ist festzulegen, für welches Objekt Sie den Alarm generieren. Was soll nun überwacht werden, ein Ereignis oder bestimmte Zustände? In diesem ersten Fenster können Sie den Alarm auch direkt aktivieren. Jetzt definieren Sie die Zustände, die überwacht werden sollen. Es steht eine lange Liste von Optionen zur Verfügung. Wählen Sie die passende aus, und markieren Sie den Status, der für den Trigger wichtig ist. Abschließend hinterlegen Sie in diesem Fenster die Konditionen für den Alarm.
Abbildung 11.86
Trigger des Alarms
Sie können im Alarm auch mehrere Events hinterlegen.
Abbildung 11.87
Wiederholungsintervall für den Alarm
Beim Reporting legen Sie fest, unter welcher Bedingung ein ausgelöster Alarm wiederholt werden soll. Dabei stellen Sie einen Abweichungswert in Prozent ein und eine Frequenz, wie oft ein einmal ausgelöster Alarm wiederholt werden soll.
678
Einrichten von Alarmen
Abschließend wählen Sie im Dropdown-Menü die bei einem Alarm auszuführende Aktion.
Abbildung 11.88
Parametrierung der Alarmaktion
Je nach Auswahl können Sie unter Configuration auch noch einen Eintrag vornehmen. In den rechten vier Spalten parametrieren Sie, bei welchem Statuswechsel die Aktion durchgeführt werden soll. Die Symbole repräsentieren dabei den Übergang zwischen den einzelnen Schwellenwerten. Die Aktion kann entweder einmal oder jedes Mal beim Erreichen der Grenze ausgeführt werden. Die Alarmfunktion bietet eine Fülle von Möglichkeiten. Nutzen Sie sie, aber achten Sie darauf, nicht so viele Alarme zu erstellen, dass Ihr Postfach geflutet wird. Die Anzahl sollten Sie so wählen, dass Sie die Menge der Benachrichtigungen noch bewältigen können.
679
11.15
Haben wir uns in dem vorhergehenden Kapitel mit der Konfiguration des vCenters und des Hosts beschäftigt, so wollen wir in diesem Kapitel des Buchs näher auf die Konfiguration der vCenter-Add-ons eingehen.
12
Konfiguration von vCenter-Add-ons Autor dieses Kapitels ist Betram Wöhrmann, Ligarion, [email protected]
Lag der Schwerpunkt der Betrachtung im vorhergehenden Kapitel auf den Basisfunktionen des vCenter Servers, so kommen wir jetzt zu zusätzlichen Optionen, die dem Administrator das Leben sehr erleichtern können. Es besteht die Möglichkeit des Patchens von Host und Client Betriebssystemen. Dabei unterstützt VMware die Client-Betriebssysteme Windows und Linux. Werden andere Gastsysteme eingesetzt, müssen Sie auf Patch-Mechanismen zurückgreifen. Es folgt eine Erklärung der Importfunktion von physischen bzw. virtuellen Systemen in die Virtualisierungslandschaft. Die Ausfallsicherheit des zentralen Managementsystems ist der Focus des nächsten Abschnitts. Zu guter Letzt möchten wir Ihnen die Datensicherungslösung von VMware näherbringen.
12.1
Einsatz des vCenter Update Managers
Der VMware vCenter Update Manager wurde mit Version 3.5 der VMware Virtual Infrastructure eingeführt. Er ist ein eigenständiges kostenloses Produkt zur Aktualisierung der VMware-Hosts in den Versionen 3.x und 4.x sowie der Betriebssysteme der Gäste, die auf den VMware-Hosts laufen. Der Update Manager wird nicht mehr während der Installation des VMware vCenter-Servers installiert. Wie bereits in Kapitel 5, »Installation«, beschrieben, installiert sich der Update Manager separat und wird später als Plug-in im vCenter sowie in den zugehörenden Clients hinzugefügt. In diesem Abschnitt werden wir näher auf den VMware Update Manager eingehen und alle wichtigen Punkte und Themen behandeln.
681
12
Konfiguration von vCenter-Add-ons
Exemplarisch zeigen wir Ihnen die vorbereitenden Arbeiten, die Sie durchführen müssen, um die Software effektiv nutzen zu können. Die Aktualisierung von virtuellen Maschinen folgt dabei genau derselben Vorgehensweise, wie das Patchen der Hosts. Beachten Sie bitte dabei, dass die Anwendung von Updates auf virtuelle Maschinen im Inventory unter Virtual Machines and Templates zu finden ist, während Sie ESX-Hosts unter Hosts And Clusters patchen.
12.1.1
Installation
Die Installation des Update Managers wurde bereits ausführlich in Kapitel 5, »Installation«, beschrieben. Installation des Plug-ins Bei der ersten Anmeldung am vCenter, nach der Installation des vCenter Update Managers, sehen Sie im Menü unter Plug-ins 폷 manage plug-ins im Plug-inManager ein neues Modul unter Available Plug-ins. Ein Klick auf den Link Download and Install installiert die Client-Komponente des Update Managers. Anschließend wird das Plug-in automatisch aktiviert. Der Client findet sich dann auf der vCenter-Homepage unter Solutions and Applications (Abbildung 12.1).
Abbildung 12.1
682
Aufruf des vCenter-Update-Manager-Clients
Einsatz des vCenter Update Managers
Damit ist die Installation des Update Manager abgeschlossen. Der Update Manager ist nun bereit zur Konfiguration. Über den Button Update Manager gelangen Sie in das Hauptfenster des Plug-ins (Abbildung 12.2).
Abbildung 12.2
vCenter Update Manager: Baselines and Groups
Das Managementfenster hat vier Reiter: Baselines and Groups, Configuration, Events und Patch repository. Im oberen Drittel des Fensters lassen sich Baselines erstellen und verwalten, getrennt nach Hosts und virtuellen Maschinen. Im mittleren Drittel erstellen Sie Baseline-Gruppen, in denen Sie wiederum PatchBaselines zusammenfassen können. Im unteren Teil des Fensters werden die abgearbeiteten Tasks angezeigt. Im Folgenden werden wir einzeln auf die Konfigurationsfenster eingehen.
12.1.2
Konfiguration
Als Erstes müssen Sie den Update Manager konfigurieren. Die entsprechenden Einstellungen nehmen Sie im Reiter Configuration im Update-Manager-Hauptfenster vor (Abbildung 12.3). Netzwerkkonfiguration Über den Link Network Connectivity gelangen Sie in das Konfigurationsfenster, in dem Sie die Kommunikationsports der Applikation einstellen. Dabei handelt es sich um die Verbindung von Client und Applikation und den Port für den Zugriff auf das Patch-Repository sowie um die die Ziel-IP oder den DNS-Namen des Repositorys.
683
12.1
12
Konfiguration von vCenter-Add-ons
Abbildung 12.3
Netzwerkkonfiguration des Update Managers
Download-Einstellungen In diesem Konfigurationsabschnitt wird die Netzwerkkonfiguration der Serverkomponente vorgenommen. Bereiten Sie den Server dafür vor, die gewünschten Patches in das Repository zu laden (Abbildung 12.4). Wichtig an der Stelle ist, dass der Speicherplatz auf der Festplatte, auf der das Repository liegt, ausreicht (siehe auch Kapitel 5, »Installation«). Die erste Konfiguration betrifft die Patches, die mit dem Update Manager verteilt werden sollen. Die Auswahl gliedert sich in Patches für ESX 3.x-, ESX 4.x-, Windows- und Linux-Systeme. Wird das vCenter nur als Client ohne DownloadFunktion genutzt und liegen dadurch die Patches in einem Repository auf einem anderen Server, dann können Sie unter Use shared repository den Zielpfad angeben. Erlaubt sind hier aber nur die Angabe einer lokalen Festplatte oder einer HTTP-basierten Quelle. Ist das Herunterladen der Patches nur über einen Proxy-Server möglich, können Sie in diesem Fenster die passenden Parameter eintragen. Der Verbindungstest zeigt sofort, ob die Einstellungen korrekt sind oder modifiziert werden müssen. Einen Download der Patches stoßen Sie hier direkt über den entsprechenden Button Download Now an.
684
Einsatz des vCenter Update Managers
Abbildung 12.4
Download-Einstellungen des Update Managers
Download-Zeitplaner Der Update Manager enthält einen Zeitplaner für das Herunterladen von Patches. Dieser Prozess lässt sich in diesem Fenster automatisieren. Nach dem Aufruf werden Ihnen die derzeitigen Einstellungen gezeigt (Abbildung 12.5).
Abbildung 12.5
Download-Zeitplaner des Update Managers
Möchten Sie den Job anpassen, öffnen Sie über den Link Edit Patch Downloads eine Dialogbox zum Einstellen der Parameter (Abbildung 12.6).
685
12.1
12
Konfiguration von vCenter-Add-ons
Abbildung 12.6
Parametrierung des Download-Tasks
An sich ist das Fenster selbsterklärend. Je nach ausgewählter Download-Frequenz ergeben sich unterschiedliche Konfigurationsoptionen. Zur Verfügung stehen die Download-Frequenzen once, After Startup, Hourly, Daily, Weekly und Monthly. Die Frequenz des Downloads sollten Sie davon abhängig machen, welche Systeme gepatcht werden sollen. Wir sind der Meinung, dass der Wochenrhythmus empfehlenswert ist. Ein stündlicher oder täglicher Rhythmus scheint nicht sonderlich sinnvoll. Aber auch hier spielen die Sicherheitsrichtlinien im Unternehmen eine große Rolle. Ist der Job eingerichtet, besteht noch die Möglichkeit, eine E-Mail-Adresse anzugeben, die den Administrator benachrichtigt, wenn neue Patches heruntergeladen worden wurden. Gast-Einstellungen Eine sehr interessante Option geben Ihnen die Virtual Machine Settings an die Hand: Sie können die Patch-Arbeiten mit Unterstützung der Snapshot-Funktionalität durchführen (Abbildung 12.7). Wie funktioniert das Ganze? Bevor der PatchVorgang im Gast angestoßen wird, initiiert der Update Manager einen Snapshot. Ist der Snapshot erstellt, werden die Patch-Arbeiten durchgeführt. Im Konfigurationsfenster ist nun einstellbar, was mit dem Snapshot passieren soll. Entweder er wird angelegt und bleibt weiter aktiv, oder Sie geben ein Zeitfenster vor, nach dem er zurückgeschrieben wird. Ist das Zeitfenster optimal gewählt, dann bleibt genug Zeit, den Gast und seine Applikation zu testen und zu entscheiden, ob das Patchen erfolgreich war oder ob der Ursprungszustand wiederhergestellt werden muss.
686
Einsatz des vCenter Update Managers
Abbildung 12.7
Einstellungen für den Gast
ESX-Host-Einstellungen Das Verhalten des Hosts beim Patchen parametrieren Sie unter ESX Host Settings (Abbildung 12.8). Startet der Patch-Vorgang für einen Host, wird als Erstes versucht, den vSphere-Host in den Maintenance-Modus zu fahren. Ist das nicht möglich, kommen die Einstellungen zum Tragen, die in diesem Fenster vorgegeben wurden.
Abbildung 12.8
Konfiguration des Hosts im Update Manager
687
12.1
12
Konfiguration von vCenter-Add-ons
Zum Ersten ist einzustellen, was passieren soll, wenn der Host nicht in den Maintenance-Modus gefahren werden kann. Entweder wird die Aktion abgebrochen (Fail Task), oder es wird noch einmal probiert (Retry). Andere Möglichkeiten sind, die virtuellen Maschinen in den Suspend-Modus zu versetzen (Suspend virtual Machines and Retry) oder sie herunterzufahren (Power off virtual Machines and Retry); in beiden Fällen wird danach erneut versucht, den Host zu patchen. Zu guter Letzt ist das Wiederholungsintervall einzustellen – wann soll der erneute Patch-Vorgang gestartet werden, und wie oft soll versucht werden, die Patches einzuspielen? vApp-Konfiguration Im Konfigurationsabschnitt vApp Settings bestimmen Sie, wie sich eine vApp nach dem Patchen verhält (Abbildung 12.9).
Abbildung 12.9
Verhalten einer vApp im Update Manager konfigurieren
Ist die Option Enable smart reboot after remediation aktiviert, sorgt der Update Manager dafür, dass alle von einer vApp betroffenen Appliances und VMs selektiv neu gestartet werden. Damit wird erreicht, dass die Abhängigkeiten der Systeme untereinander eingehalten werden. Deaktivieren Sie diese Option, bleiben die Abhängigkeiten der VMs untereinander unberücksichtigt, und die VMs werden in der Reihenfolge des Patchens neu gestartet. Das kann abschließend aber dazu führen, dass die vApp nicht funktioniert, weil die Boot-Reihenfolge nicht eingehalten worden ist.
688
Einsatz des vCenter Update Managers
12.1.3
Download von Updates
Nachdem Sie alle nötigen Einstellungen vorgenommen haben, können Sie die Updates herunterladen. Dies geschieht am einfachsten über den dafür angelegten Scheduled Task. Mit der rechten Maustaste auf diesen Task führen Sie ihn direkt aus. Anschließend werden die Updates direkt heruntergeladen (Abbildung 12.10).
Abbildung 12.10
VMware Update Manager – Download der Patches
Jetzt wird ein Task im Fenster der Recent Tasks gestartet. Hier erkennen Sie, dass der Update Manager Patches herunterlädt (Abbildung 12.11).
Abbildung 12.11
VMware Update Manager – Task: Download der Patches
Wird der Task zum ersten Mal angestoßen, kann der Vorgang ziemlich lange dauern, je nachdem, welche Patches heruntergeladen werden müssen.
12.1.4
Download von Updates auf Offline-Update-Manager
Zum Herunterladen von Patches auf einem dedizierten Download-Server müssen Sie auf jeden Fall die Kommandozeile bemühen. Für den Download Manager gibt es keine GUI. Damit die Routinen einwandfrei funktionieren, sind die Befehle im Programmverzeichnis abzusetzen. Für den Administrator sind zwei Dateien wichtig, die ausführbare Datei vmware-umds.exe und das Konfigurations-File downloadConfig.xml. Die verschiedenen Aufrufparameter der vmware-umds.exe-Datei finden Sie in Abbildung 12.12.
689
12.1
12
Konfiguration von vCenter-Add-ons
Abbildung 12.12
Befehlsparameter von vmware-umds.exe
Es gibt nun zwei Wege zu bestimmen, welche Patches heruntergeladen werden sollen: 1. Parametrierung der Downloads über die Kommandozeile 2. Einschränkung der Downloads durch Anpassen der Konfigurationsdatei Im Handbuch wird nur die Nutzung der Kommandozeile beschrieben. Die Befehle für die Konfiguration lauten: vmware-umds –set-config –enable-host 1 –enable-win 0 –enable-lin 0
Es ist nicht schwer, die Syntax zu entschlüsseln. Eine Null hinter dem Parameter deaktiviert ihn, eine eins aktiviert den Download der Patches. Dabei steht host für VMware-, win für Windows- und lin für Linux-Patches. Es gibt aber, unseres Wissens, keine Möglichkeit, die Downloads weiter einzuschränken. Bei genauer Ansicht der Konfigurationsdatei finden Sie zumindest eine Möglichkeit, die Anzahl der ESX-Patches einzuschränken. In der Konfigurationsdatei (downloadConfig.xml) lassen sich die Anpassungen auch manuell vornehmen. Sollen z. B. keine ESX 3.x-Patches heruntergeladen werden, weil Sie eine reine vSphere-Umgebung haben, entfernen Sie einfach die Zeile <ESX3xUpdateUrl>... Schon werden beim Download nur noch Patches für vSphere berücksichtigt. <patchStore>C:\Patche\
690
Einsatz des vCenter Update Managers
<exportStore> <proxySettings> <useProxyServer> <proxyServer> <proxyPort> true <windowsUpdateEnabled>false false ENU <ESX3xUpdateUrl>https://www.vmware.com/PatchManagementSystem/ patchmanagement <ESX4xUpdateUrl>https://hostupdate.vmware.com/software/VUM/ PRODUCTION/index.xml 8 <maxConnections>8 vmware-downloadService verbose info info
Als Nächstes können Sie die Updates herunterladen. Dieses stoßen Sie mit dem Befehl vmware-udms –download an. Ist der Job abgeschlossen, befinden sich die gewünschten Patches im zugehörigen Verzeichnis, welches während der Installa-
691
12.1
12
Konfiguration von vCenter-Add-ons
tion als Patch-Repository angegeben worden ist. Jetzt exportieren Sie das PatchRepository mit dem Befehl vmware-cmd –export –export-store . Wesentlich mehr Funktionen stellt das Tool nicht zur Verfügung, außer den Optionen, einen erneuten Download von Patches anzustoßen und die Sprachversionen, die heruntergeladen werden sollen, einzuschränken. Abschließend sind die Patches noch auf dem vCenter-Server zu importieren (Abbildung 12.13). Das erfolgt über das vCenter selbst. Achtung Damit Ihnen der Import gelingt, genügt der Export auf dem Download-Server nicht. Beim Export wird nämlich eine wichtige Datei nicht mitgenommen, und ohne diese Datei gelingt der Import nicht. Es handelt sich um die Datei version.txt, die im Wurzelverzeichnis des Patch-Ordners liegt. Die Datei muss im Wurzelverzeichnis des Exportverzeichnisses auf dem Server stehen auf dem die Patches importiert werden sollen. Erst dann gelingt der Import!
Abbildung 12.13
Import von Patches aus einer externen Quelle
Bitte beachten Sie, dass Sie das Importverzeichnis nicht löschen dürfen. Beim Import der Patches werden nur die Metadaten in das Patch-Verzeichnis kopiert, die Patches selbst verbleiben im Verzeichnis der Importquelle. Ist der Import abgeschlossen, sind die importierten Patches im Repository sichtbar und können genutzt werden (Abbildung 12.14). Unter dem Punkt Recent Tasks ist der erfolgreiche Importjob noch sichtbar. Nachdem die Patches nun im System hinterlegt sind, können Sie mit den weiterführenden Arbeiten beginnen.
692
Einsatz des vCenter Update Managers
Abbildung 12.14
12.1.5
Patch-Repository mit den importierten Patches
Baselines
Erstellung einer Baseline Damit die Updates angewandt werden können, müssen Sie eine sogenannte Baseline erstellen. Diese Baseline legen Sie im Menü des Update Managers an und weisen sie später einem bestimmten Objekt im Inventory des vCenters zu. So ist es möglich, eine Baseline für die vSphere-Hosts zu erstellen und sie dann entweder einem Datacenter, einem Ordner oder einem einzelnen Host zuzuordnen. In der Baseline-Übersicht wird genau angezeigt, wie viele kritische und nicht kritische Patches im Repository zur Verfügung stehen (Abbildung 12.15). Nach der Installation des vCenter Update Managers stehen bereits acht Baselines zur Verfügung, vier davon für das Patchen von Hosts. Die restlichen vier Baselines sind für das Updaten von virtuellen Maschinen eingerichtet. Sie enthalten alle vorhandenen kritischen und nicht kritischen Patches und Updates. Damit die Darstellung nicht zu unübersichtlich wird, trennt die Anzeige über zwei Reiter die Upgrades und die Patches voneinander. Auf jeder Reiterkarte wird jeweils zwischen Hosts und VMs unterschieden.
693
12.1
12
Konfiguration von vCenter-Add-ons
Abbildung 12.15
vCenter-Update-Manager-Baselines
Abbildung 12.14 zeigt die Patches für die vSphere-Hosts. Andere Dateien wurden in diesem Beispiel noch nicht importiert. Interessant ist die Möglichkeit, eine Baseline zu erstellen, die nicht alle verfügbaren Patches enthält, sondern die Funktionsupdates ausschließt. Somit spielen Sie beim Patchen der Hosts nur die Korrekturen ein. Im umgekehrten Fall besteht die Option, nur Funktionserweiterungen zu installieren. So trennen Sie Patches und Updates und können sie unabhängig voneinander anwenden. Zur Erstellung einer neuen Baseline dient der Create-Link im Fenster Baselines and Groups des Update Managers verwendet. Daraufhin startet ein Wizard, der Sie durch das Erstellen einer neuen Baseline führt (Abbildung 12.16).
Abbildung 12.16
694
Erstellen einer neuen Baseline
Einsatz des vCenter Update Managers
Der Dialog stellt vier verschiedene Optionen für das Anlegen einer Baseline zur Auswahl. Host Upgrade entspricht der in Abschnitt 5.2, »Upgrade auf vSphere von ESX 3.x«, beschriebenen Vorgehensweise. Host Patch und VM Patch sind von der weiteren Vorgehensweise weitestgehend miteinander identisch. Die Baselines können einen Fixed-Status bekommen. In diesem Fall werden die Patches aus dem Repository fest zugeordnet. Am Status der Regel wird sich zukünftig nichts ändern. Im Gegensatz dazu steht der Status Dynamic: Bei der Erstellung werden die Regeln dynamisch erstellt. Das bedeutet, dass alle neu heruntergeladenen Patches, die der Auswahl entsprechen, automatisch zur Baseline hinzugefügt werden. Dabei ist es unerheblich, ob Patches schon vorhanden sind oder zukünftig heruntergeladen werden. In unserem Beispiel erstellen wir zwei Baselines, die nur Patches für die Version ESXi 4.0 enthält, getrennt nach Firmwareupdates und Patches. Nach der Auswahl des Fixed-Modus zeigt der Wizard das Fenster, in dem Sie die Patches der Baseline hinzufügen können (Abbildung 12.17). Öffnen Sie einen Patch per Doppelklick, um den zugehörigen Knowledge-BaseArtikel zu lesen. Voraussetzung dafür ist aber ein funktionierender Internetzugang.
Abbildung 12.17
Aufnahme der Patches in die Baseline
Wären wir den Weg über die dynamische Baseline gegangen, würde sich der Dialog darstellen wie in Abbildung 12.18.
695
12.1
12
Konfiguration von vCenter-Add-ons
Abbildung 12.18
Erstellung einer dynamischen Baseline
Hier sehen Sie sehr schön den Unterschied: Die Baseline ordnet die Patches automatisch zu. Es werden nur Dateien hinzugewählt, die für ESXi bestimmt sind und im Namen das Wort »Firmware« enthalten. Nun aber zurück zu unserem Beispiel. Nachdem wir jetzt noch eine zweite Baseline für die Firmware erstellt haben, zeigt sich das Übersichtsfenster wie in Abbildung 12.19.
Abbildung 12.19
696
Erstellte Baselines
Einsatz des vCenter Update Managers
Der Vollständigkeit halber möchten wir noch erwähnen, dass zuvor noch zwei weitere dynamische Baselines erstellt worden sind. Diese sehen Sie ebenfalls in der Abbildung. Erstellung einer Baseline-Gruppe Auch wenn es möglich ist, die erstellten Baselines direkt an einen oder mehrere Hosts zu binden, bietet der Update Manager eine weitere Möglichkeit der Gruppierung: In Baseline-Gruppen können Sie wiederum Patches- und. oder UpgradeBaselines zusammenfassen. Tun Sie sich selbst und Ihren Kollegen einen Gefallen, und entscheiden Sie sich für eine durchgehende Strategie. Entweder binden Sie Patch- und, oder Upgrade-Baselines an zu patchende Objekte, oder nutzen Sie Gruppen, aber vermischen Sie nicht beides, das wird definitiv unübersichtlich. Abschließend legen Sie eine Baseline-Gruppe an, in der Sie alle Patches für die ESXi-Systeme sammeln. Über den Create-Link erreichen Sie den Dialog zur Erstellung der Gruppe. Im ersten Fenster wird nur der Name abgefragt, und Sie müssen angeben, ob Sie Host-Systeme oder andere Systeme gruppieren wollen. Das Zuordnen der Patches zur Gruppe erfolgt anschließend (Abbildung 12.20), bevor Sie den Dialog schließen.
Abbildung 12.20
Zuordnung von Patches zur Gruppe
Hiermit sind die Arbeiten abgeschlossen, und es ist nun möglich, mit den Baselines zu arbeiten. Arbeiten mit Baselines Nach den vorbereitenden Arbeiten können Sie die Baseline-Gruppe mit einem Host verbinden (Abbildung 12.21). An erster Stelle steht die Auswahl eines Hosts oder Clusters; auf dem Reiter des Update Managers erzeugen Sie dann über den Attach-Link eine Verknüpfung zwischen Host und Baseline. Anschließend wird sofort gezeigt, ob der Host compliant ist oder nicht (Abbildung 12.22).
697
12.1
12
Konfiguration von vCenter-Add-ons
Abbildung 12.21
Verknüpfung von Host und Baseline
Abbildung 12.22
Compliance-Status
Es ist nicht schwer zu erkennen, dass der Host Patches benötigt, damit er auf dem aktuellen Stand ist. Doch bevor wir die Patches einspielen – was übrigens über den Remediate-Button geschieht –, möchten wir kurz auf den Stage-Button eingehen. Dieser sorgt dafür, dass die Patches auf die zu patchende Maschine geladen werden. Der eigentliche Patch-Vorgang läuft dann wesentlich schneller ab.
698
Einsatz des vCenter Update Managers
Starten Sie den Patch-Vorgang jetzt, wird angezeigt, welche Baselines mit dem Host verknüpft sind. Es folgt eine Zusammenfassung aller zur Anwendung kommenden Patches, mit der Möglichkeit, einzelne zu entfernen. Sie haben nun die Möglichkeit festzulegen, ob der Task sofort startet oder ob er zu einem bestimmten Zeitpunkt automatisch die Patch-Arbeiten durchführt. Ist die Aktion angestoßen, stellt sich das vCenter dar wie in Abbildung 12.23.
Abbildung 12.23
Patch-Status
Hier ist schön zu sehen, dass der Host zuerst automatisch in den MaintenanceModus gefahren wird, bevor die Patch-Arbeiten beginnen. Nach dem Abschluss der Arbeiten erfolgt ein automatischer Reboot. Ist das System wieder erreichbar, wird erneut ein Compliance-Check angestoßen. Waren die Patch-Arbeiten erfolgreich, zeigt sich das an dem großen grünen Button auf der Update-Manager-Seite. Jetzt nur keine Angst vor dem Patchen von kompletten Clustern. Es werden natürlich nicht alle Systeme auf einmal gepatcht, sondern nach und nach. Zur Unterstützung wird die Funktion VMotion eingesetzt. Das Patchen beginnt so z. B. mit dem ersten Host. Durch die Aktivierung des Maintenance-Modus werden die laufenden VMs evakuiert und auf die restlichen betriebsbereiten vSphere-Hosts verschoben. Nach dem Abschluss der Patch-Arbeiten wird der Maintenance-Modus automatisch wieder deaktiviert, und der Host kann wieder virtuelle Maschinen aufnehmen. Erst jetzt wird mit dem nächsten Host begonnen. Es bleiben immer so viele Ressourcen frei, wie nötig sind, damit die Leistung der VMs nicht beeinflusst wird. Status einer Baseline und ihrer Objekte Jede Baseline, die zugewiesen wurde, hat einen bestimmten Status. Dieser hängt davon ab, welchen Status die verknüpften Systeme haben. Es wird der Zustand von einzelnen Hosts angezeigt, es gibt aber auch eine Zusammenfassung, die über den Gesamtstatus informiert und auch grafisch aufbereitet ist (Abbildung 12.24).
699
12.1
12
Konfiguration von vCenter-Add-ons
Abbildung 12.24
vCenter-Update-Manager-Status
Sollten Maschinen unter der Spalte Unknown angezeigt werden, müssen Sie einen Scan durchführen, um zu überprüfen, welche Patches installiert wurden. Dazu starten Sie einen Scan-Tasks über den entsprechenden Link oder über das Kontextmenü von Host oder Cluster – der dritte Punkt von unten, Scan for Updates, führt ebenfalls einen Scan durch. Update der VMware Tools Viele Anwender haben es bedauert, dass die Vorgängerversion des vCenter Update Managers keine Option bot, die VMware Tools zu aktualisieren. Dies hat sich geändert, und zusätzlich besteht sogar die Möglichkeit, die virtuelle Hardware über den Update Manager zu aktualisieren. Diese Funktion werden vor allem diejenigen zu schätzen wissen, die ein größeres Upgrade vor der Brust haben. Da der Upgrade Manager auch das Upgrade des Hosts unterstützt, können Sie den kompletten Upgradepfad über den Update Manager beschreiten und haben eine zentrale Konsole, die den aktuellen Status dokumentiert.
12.2
Einsatz des VMware vCenter Converters
12.2.1
VMware vCenter Converter
Wie auch der vCenter Update Manager integriert sich der vCenter Converter ebenfalls direkt in den vCenter-Server. Auch in diesem Fall ist auf dem Client das
700
Einsatz des VMware vCenter Converters
Plug-in herunterzuladen und zu installieren. Der Weg ist ja schon bekannt, deshalb nur noch einmal der Hinweis: Im Menü unter Plug-ins 폷 Plug-in Manager 폷 Available Plug-ins liegt der Download-Link für die Installation des Clients. Nach der erfolgreichen Installation hat sich das Kontextmenü im vCenter um den Punkt Import Machine erweitert (Abbildung 12.25).
Abbildung 12.25
Aufruf des vCenter Converters
Es gibt aber auch eine Variante, die von CD gestartet werden kann; genutzt wird sie für Coldclone-Vorgänge, aber dazu später mehr in Abschnitt 12.2.2. Den zusätzlichen Menüpunkt sehen Sie, wenn Sie das Kontextmenü des Clusters oder des Hosts öffnen. Dann öffnet sich ein Wizard, der Sie durch die Übernahme der Maschine führt. Bevor wir jetzt die weitere Vorgehensweise beschreiben, möchten wir kurz erläutern, welche Optionen es gibt und wann sie genutzt werden können. Die weitere Beschreibung bezieht sich aber auf das Plug-in im vCenter-Server. Der vCenter Converter – viele werden ihn noch als P2V oder VMware Converter kennen –, ermöglicht die Konvertierung von Computern in eine virtuelle Maschine. Es ist dabei nicht entscheidend, welche Hardware die zu übernehmende Maschine hat. Viel wichtiger ist, dass der Converter dazu in der Lage ist, die systemkritischen Treiber nicht nur zu entfernen, sondern auch durch VMware-konforme zu ersetzen. Es gibt zwei Möglichkeiten, den Converter zu nutzen. Ein sogenannter Coldclone oder ein Hotclone. Bei einem Coldclone wird das zu übernehmende System mit einer Converter-CD gestartet, und der Server wird direkt auf einem Host oder vCenter-Server impor-
701
12.2
12
Konfiguration von vCenter-Add-ons
tiert, ohne dass das zu übernehmende System aktiv ist. Das erzeugte Image kann auch auf einem Datenträger gespeichert und anschließend importiert werden. Im Falle des Hotclones; wird ein aktiver Server im laufenden Betrieb übernommen. Bevor die Arbeiten beginnen können, wird ein Agent auf dem System installiert. Je nach Gastbetriebssystem ist ein Neustart des Servers notwendig. Für die Abbildung der Funktion erzeugen Sie einen Snapshot des zu übernehmenden Systems. Alle Änderungsdaten werden in diesen Snapshot geschrieben. So übernehmen Sie zuerst die statischen Daten. Ist dieser Schritt abgeschlossen, erstellen Sie erneut einen Snapshot, und so fort. Dies geschieht so lange, bis die Maschine übernommen ist. Problematisch wird es, wenn die Applikation nicht angehalten wird. Ist die Übernahme abgeschlossen, können sich die Daten der Source-Maschine weiterhin ändern, und damit sind Quell- und Zielsystem nicht identisch. Garantieren Sie deshalb, dass keine Client-Applikation auf das System zugreifen kann. Die Übernahme wird dann auch schneller vonstattengehen. Hinweis zur Konvertierung Soll das Hotclone-Verfahren genutzt werden, ist es zumindest bei Datenbankapplikationen empfehlenswert, die Datenbank zu stoppen, bevor Sie die Übernahme starten. Ebenso sollten Sie bei anderen Applikationen verfahren, die hohe Änderungsraten im Content haben.
Die Übernahme von Computern mit dem vCenter Converter funktioniert nicht für alle Betriebssysteme. Unterstützt werden alle Windows-Betriebssysteme ab der Version Windows NT 4.0 SP4, wobei die Versionen Windows NT4 SP4 und Windows XP Home Edition nur offline konvertiert werden können. Alle anderen Windows-Systeme lassen sich auch im laufenden Betrieb übernehmen. Linux-Systeme mit den Derivaten SUSE, Red Hat und Ubuntu werden ebenfalls unterstützt, aber nur im Coldclone-Verfahren. Es wundert nicht, dass es mittlerweile auch möglich, ist mit Fremdherstellertools erstellte Images zu übernehmen. Unterstützt werden an dieser Stelle Images von Norton Ghost, Symantec Lifestate, Symantec Backup Exec System Recovery, StorageCraft ShadowProtect, Acronis True Image und VMware-VCB-SicherungsImages. Übernahme eines Systems mit dem vCenter Converter Nun aber zu einer Beispielübernahme, um Ihnen zu zeigen, wie der Arbeitsablauf ist. Ist der Vorgang über das Kontextmenü, Import Machine, gestartet, zeigt sich der Wizard aus Abbildung 12.26.
702
Einsatz des VMware vCenter Converters
Abbildung 12.26
Wizard-Startfenster vCenter Converter
Rufen Sie mit Next das nächste Fenster auf. Hier wählen Sie dann aus, welcher Maschinentyp übernommen werden soll (Abbildung 12.27).
Abbildung 12.27
Auswählen des zu übernehmenden Systems
Im vorliegenden Beispiel soll eine physische Maschine übernommen werden. Für den folgenden Schritt werden der FQDN oder die IP-Adresse der SourceMaschine benötigt sowie ein administrativer Account. Zuvor listen wir in Tabelle 12.1 die unterschiedlichen Maschinentypen auf und was sich dahinter verbirgt.
703
12.2
12
Konfiguration von vCenter-Add-ons
Quelle
Beschreibung
Physische Maschine
Diese Option konvertiert einen physischen Computer, der dediziert auf seiner eigenen Hardware im Netzwerk läuft.
Virtuelle vSphereMaschine
Mit dieser Option konvertieren Sie virtuelle Maschinen, die in einem VMware-vCenter-Server oder auf einem VMware-vSphere-Host registriert sind.
Andere
Andere fasst alle anderen Maschinen zusammen. So ist es zum Beispiel möglich, eine virtuelle Maschine, die auf einem PC im Netzwerk liegt, zu konvertieren. Diese könnte zum Beispiel mit der VMware Workstation erstellt worden sein oder mit einem unterstützten Image-Tool.
Tabelle 12.1
VMware Converter: Convert Machine – Beschreibung Quelltyp
Haben Sie die Eingaben bestätigt, versucht der Client, sich mit dem Quellsystem zu verbinden. Dabei werden auch die Rechte überprüft. Beachten Sie bitte, dass die Einfache Freigabe auf Windows XP-Systemen inaktiv sein muss. Nun ist die Entscheidung zu treffen, wie nach erfolgreicher Übernahme mit dem Client umgegangen wird, der auf der Quellmaschine installiert wird. Die zwei möglichen Optionen sind eine automatische Deinstallation nach der Übernahme oder eine manuelle. Einige Betriebssysteme benötigen einen Reboot nach der Installation des Converter-Agenten, so z. B. Windows NT4. Wie soll mit den zu übernehmenden Festplatten umgegangen werden (Abbildung 12.28)? Die Festplattengröße können Sie belassen, indem Sie den oberen Punkt, Alle Festplatten importieren und deren Grösse beibehalten, wählen.
Abbildung 12.28
704
Übernahme der Festplatten mit Größenanpassung
Einsatz des VMware vCenter Converters
Wählen Sie die untere Option, Volumes auswählen und Grösse ändern ..., können Sie die Größe der Festplatten/Partitionen ändern. Ist die Festplatte eines Computers in mehrere Partitionen unterteilt, haben Sie die Option, jede Partition auf ein eigenes Festplatten-File zu portieren. Dies bietet einen sehr großen Vorteil: Ohne großen Aufwand können die Größen der Partitionen bzw. Festplatten (beides ist ja identisch, wenn Sie es so durchgeführt haben wie beschrieben) später geändert werden, ohne spezielle Software für die Arbeiten nutzen zu müssen. Überlegen Sie genau, wie Sie hier verfahren, denn zu einem späteren Zeitpunkt sind diese Anpassungen nur mit sehr viel Aufwand möglich, und die Auszeit für die Übernahme entsteht ja sowieso. Es folgt die Angabe des Zielsystems, auf dem die Maschine importiert werden soll (Abbildung 12.29). Da wir den Import direkt auf dem Host gestartet haben, gibt es keine weitere Auswahlmöglichkeit für das Ziel, und es wird nur der Server angezeigt, auf dem die Konvertierung gestartet wurde.
Abbildung 12.29
Auswahl des Host-Zielsystems
Geben Sie nun den Namen der neuen virtuellen Maschine an und unter welchem Objekt sie im vCenter abgelegt werden soll. Als Nächstes wird der Storage abgefragt, auf dem der neue Computer erzeugt werden soll. Nun wird das Netzwerk der Quellmaschine analysiert. Die Anzahl der Netzwerkkarten wird übernommen. Beachten Sie bitte, dass Teaming-Software nicht unterstützt wird. Das Teaming als solches kann ja auf dem Host eingerichtet werden, deshalb wird aus Redundanzgründen keine zweite Netzwerkkarte im Gast benötigt. Das gilt natürlich nur, wenn die virtuellen Switches auf dem Host mit mindestens zwei physischen Karten verbunden sind.
705
12.2
12
Konfiguration von vCenter-Add-ons
Nehmen Sie jetzt die Einstellungen für die Netzwerkkarte vor (Abbildung 12.30). Beachten Sie, dass zwei Systeme mit identischem Namen und identischer IPAdresse im Netz sind, wenn die Netzwerkkarte aktiv ist und Sie den virtuellen Server nach der Übernahme direkt starten. Dies trifft natürlich nur für den Hotclone zu.
Abbildung 12.30
Einstellungen für die Netzwerkkarte
Als letzter Schritt vor der Migration des Systems in eine virtuelle Maschine haben Sie drei weitere Möglichkeiten, die Maschine anzupassen (Abbildung 12.31).
Abbildung 12.31
706
Zusätzliche Aufgaben
Einsatz des VMware vCenter Converters
왘
VMware Tools installieren installiert die richtigen Treiber für die neue Hardware der virtuellen Maschine sowie die Tools, die VMware benötigt, um zum Beispiel alle Funktionen zu unterstützen, die ein ESX-Host bietet. Dieser Schritt wird in den meisten Fällen empfohlen.
왘
Identität der virtuellen Maschine anpassen ermöglicht Ihnen, die virtuelle Maschine anzupassen, zum Beispiel die IP-Adresse oder den Host-Namen des Systems zu ändern. Im Falle einer Physical-to-virtual-Migration eines bestehenden Systems ist dies nicht immer sinnvoll. Handelt es sich dabei aber um einen Test und wird die neue virtuelle Maschine neben der alten Maschine betrieben, ist diese Funktion durchaus empfehlenswert. Ist dieser Punkt nicht auswählbar, weist dies darauf hin, dass keine Sysprep-Tools auf der vCenterMaschine vorhanden sind. Die Sysprep-Tools sind ein Programm von Microsoft zur Änderung von Systemeigenschaften. In dem folgenden Abschnitt wird dies noch einmal näher erläutert.
왘
Alle Prüfpunkte für die Systemwiederherstellung entfernen (empfohlen) entfernt alle gesetzten Punkte der sogenannten Systemwiederherstellung unter Windows, die es ermöglicht, das System zu einem bestimmten Zeitpunkt wiederherzustellen. In den meisten Fällen ist es nicht nötig, im späteren virtuellen System auf diese Punkte zuzugreifen.
Die Ausführungszeit planen Sie im nächsten Schritt (Abbildung 12.32).
Abbildung 12.32
vCenter Converter – Scheduled Task
Den Import der Maschine können Sie als Task planen, um so den Auftrag für die Maschine auf lastarme Zeiten zu terminieren, oder Sie führen ihn direkt aus.
707
12.2
12
Konfiguration von vCenter-Add-ons
Zum Schluss wird eine Zusammenfassung der bevorstehenden Migration angezeigt, und Sie haben die Möglichkeit, die virtuelle Maschine direkt nach der Migration zu starten (Abbildung 12.33).
Abbildung 12.33
Zusammenfassung der Übernahmedaten
Mit dem Beenden des Wizards über Finish starten Sie den Task, der nun in der Recent Tasks-Anzeige des vCenters erscheint (Abbildung 12.34). Als Erstes wird eine virtuelle Maschine angelegt, und anschließend beginnt der Import der Maschine. Je nach Größe der Festplatten und der Datenverbindung nimmt dies einige Zeit in Anspruch.
Abbildung 12.34
Task-Anzeige für den Import des Servers
Installation der Sysprep-Tools zur Anpassung von Windows-Maschinen Wie bereits im vorherigen Abschnitt erwähnt, müssen die Microsoft-SysprepTools auf dem vCenter-Server, auf dem der vCenter Converter ausgeführt wird, vorhanden sein. Anderenfalls ist das Anpassen der zu übernehmenden Maschine beim Import mit dem Converter nicht möglich. Im Verzeichnis C:\Documents and Settings\All Users\Application Data\VMware\ VMware VirtualCenter\sysprep befinden sich Ordner für verschiedene Betriebssysteme.
708
Einsatz des VMware vCenter Converters
Verzeichnisname
Betriebssystem
2k
Windows 2000 Workstation/Server
xp
Windows XP
xp-64
Windows XP 64-Bit
srv2003
Windows Server 2003
srv2003-64
Windows Server 2003 64-Bit
Tabelle 12.2
Verzeichnisnamen für die Sysprep-Ablage
In den, in der Tabelle genannten Ordner, müssen Sie die passenden SysprepTools kopieren. Sie finden die Sysprep-Dateien auf jeder Windows-CD im Ordner SUPPORT\TOOLS in der Datei mit dem Namen Deploy.cab. Durch das Kopieren der Dateien in die entsprechenden Ordner ist es möglich, die Zielmaschine beim Import anzupassen.
12.2.2
VMware vCenter Converter Standalone
Die Arbeit mit dem vCenter Converter Standalone gestaltet sich etwas anders als der Import mit dem vCenter Converter. Nach dem Aufruf des Clients und dem Start zeigt sich Ihnen eine ganz eigene Oberfläche (Abbildung 12.35).
Abbildung 12.35
vCenter Converter Standalone
Über den Link Convert Machine starten Sie den Wizard für den Import eines Computers. Geben Sie direkt auf der ersten Seite die Daten der Quellmaschine ein (Abbildung 12.36).
709
12.2
12
Konfiguration von vCenter-Add-ons
Abbildung 12.36
Daten der Quellmaschine
Unter Select Source Type stehen Ihnen fünf Möglichkeiten zur Auswahl, die Optionen sind vielfältiger als bei der im vCenter integrierten Version. Die Varianten sind: Powered-on machine, VMware Infrastructure VM, Other VMware VM, Backup image or Thirdparty VM and Virtual appliance. Des Weiteren ist es möglich, entweder den lokalen Computer oder einen Rechner aus dem Netzwerk zu übernehmen. In der folgenden Abbildung sehen Sie als Übernahmebeispiel einen Computer aus dem Netzwerk. Nach einem Klick auf Next versucht die Applikation, sich mit dem vConverterServer zu verbinden. Bekommt der Applikations-Server eine positive Rückmeldung, dann erscheint die Anfrage, wie mit der Installation des Agenten umgegangen werden soll (Abbildung 12.37). Mit Yes beginnt die Verteilung des Agenten auf das Quellsystem. Nach einigen Minuten ist der Agent installiert, und es geht an die Eingabe der Parameter für den Host, der die neue virtuelle Maschine aufnehmen soll (Abbildung 12.38).
710
Einsatz des VMware vCenter Converters
Abbildung 12.37
Was passiert mit dem Agenten nach erfolgter Übernahme?
Abbildung 12.38
Eingabe des Namens der Zielmaschine und der Ziel-LUN
Vergeben Sie jetzt den Namen des Zielsystems, und geben Sie die Ziel-LUN für das System an. Zusätzlich wird nach der Virtual machine version gefragt. Dahinter verbirgt sich die Hardwareversion der virtuellen Maschine. Eine Übernahme in der Version 7 bedeutet, dass das Zielsystem nur auf vSphere-Hosts lauf-
711
12.2
12
Konfiguration von vCenter-Add-ons
fähig ist. Soll das zu übernehmende System in einer VI 3.x-Umgebung genutzt werden, ist eine frühere Hardwareversion einzusetzen. Options – Data To copy Data to copy ermöglicht die Anpassung der zu übernehmenden Festplatte. Auf der Reiterseite Source Volumes werden die Volumes der Quellmaschine angezeigt. Der Reiter Target Layout ermöglicht die Manipulation der Ziel-Volumengröße (Abbildung 12.39).
Abbildung 12.39
Festplattenkonfiguration – Basic
Im Basic-Modus der Festplattenanpassung, der in Abbildung 12.39 dargestellt wird, können Sie die Ziel-LUN noch einmal ändern. Markieren Sie die Festplatten, die Sie übernehmen möchten. Die Größe der Festplatte ist ebenfalls anpassbar. Möchten Sie weitergehende Konfigurationen vornehmen, wechseln Sie an der markierten Stelle in den Advanced-Modus. Der Reiter Source Volumes stellt nur die Auswahl zur Verfügung, welche Festplatten übernommen werden sollen. Weitere Einstellungen sind hier nicht möglich.
Abbildung 12.40
712
Data to copy 폷 Advanced 폷 Source Volumes
Einsatz des VMware vCenter Converters
Der Reiter Target Layout bietet weitergehende Konfigurationsoptionen (Abbildung 12.41). Auch hier können Sie selbstverständlich die Ziel-LUN noch einmal anpassen. Der wohl wichtigste Punkt in diesem Dialog ist die Änderung des Plattentyps von Flat auf Thin oder umgekehrt.
Abbildung 12.41
Data to copy 폷 Advanced 폷 Target Layout
Bei der Auswahl Flat wird der gesamte Festplattenspeicher, den die virtuelle Festplatte benötigt, sofort allokiert, so wie es bis zu der Version VI 3.x Standard war. Bei Thin wird nur der Plattenplatz belegt, der aktuell auch beschrieben ist. Die angegebene Festplattengröße markiert hier die obere Grenze. Achten Sie bei der Nutzung dieser Option darauf, dass genügend freier Platz auf der LUN vorhanden ist. Selbst wenn zu Beginn nur ein Bruchteil der virtuellen Platte genutzt wird, kann der verwendete Plattenplatz ganz schnell steigen und dann Probleme verursachen. Von Haus aus werden die Platten und Partitionen so abgebildet, wie die Aufteilung auf dem Quellsystem war. Möchten Sie diese Aufteilung ändern, fügen Sie über Add Disk eine neue Festplatte hinzu. Markieren Sie die Partition, die auf eine eigene Festplatte verschoben werden soll, und bringen Sie sie über die Buttons Move up oder Move Down an die gewünschte Position (Abbildung 12.42). Options – Devices Der folgende Dialog ist extrem komplex. Einen Großteil der Parameter des Zielcomputers können Sie an dieser Stelle anpassen (Abbildung 12.43). Auf die verschiedenen Optionen gehen wir jetzt einzeln ein. VMware gibt Ihnen durch eine Bewertung der einzelnen Punkte ein Hilfsmittel an die Hand. Ist vor den einzelnen Devices ein rotes oder gelbes Zeichen, sollten Sie sich die entsprechende Konfiguration genau anschauen; es ist nicht ausgeschlossen, dass es dort Probleme gibt.
713
12.2
12
Konfiguration von vCenter-Add-ons
Abbildung 12.42
Aufteilen der Partitionen auf getrennte Festplatten
Bei Devices können Sie mehrere Optionen anpassen: die Anzahl der CPUs und die Größe des Arbeitsspeichers. Der wichtigste Punkt ist hier aber die Einstellung des Festplatten-Controllers. Es werden nur Controller angezeigt, die in dem System auch genutzt werden können. Ändern Sie den Controller-Type z. B. von IDE auf SCSI, ist es wichtig, dass Sie die VMware Tools automatisch mitinstallieren lassen, damit Ihr System später auch booten kann. Options – Networks Unter Networks stellen Sie den virtuellen Switch ein, an dem die Zielmaschine angeschlossen werden soll. Den Verbindungsstatus beim Start des Computers bestimmten Sie in der rechten Spalte Connect at power-on (Abbildung 12.44).
714
Einsatz des VMware vCenter Converters
Abbildung 12.43
Anpassung der Parameter der Zielmaschine
Abbildung 12.44
Konfiguration Netzwerk
Options – Services Services bietet eine Besonderheit der Standalone-Version, nämlich eine Anpassung der Dienste, sowohl auf dem Quell- als auch auf dem Zielsystem (Abbildung 12.45). Gibt es Dienste, die beim Import besser nicht aktiv sein sollten, so sind sie hier zu deaktivieren. Nicht alle Dienste sind manipulierbar, aber ein Großteil der installierten. Die Startart aller Dienste des Zielsystems ist hingegen anpassbar. Beachten Sie bitte, dass der Computer einige Services auf jeden Fall benötigt, damit er starten kann. An dieser Stelle können Sie bereits eingreifen und Dienste deaktivieren, die über die Systemtools des Server-Hardwareherstellers installiert wurden. Grundsätzlich sollten Sie aber bei einer Eins-zu-eins-Übernahme an dieser Stelle nichts ändern.
715
12.2
12
Konfiguration von vCenter-Add-ons
Abbildung 12.45
Dienste-Einstellungen
Options – Advanced Options Unter Advanced options geben Sie an, welche Aktionen im Rahmen der Übernahme zusätzlich durchgeführt werden sollen (Abbildung 12.46).
Abbildung 12.46
Advanced Options beim vCenter Converter Standalone
Synchronize changes that occur to the source during cloning bewirkt, dass nach der kompletten Übernahme des Quellsystems alle nicht benötigten Dienste angehalten und die bis zu diesem Zeitpunkt aufgelaufenen Änderungen im Content auf das Zielsystem synchronisiert werden.
716
Einsatz des VMware vCenter Converters
Die beiden nächsten Punkte steuern das Verhalten von Quell- und Zielsystem nach der Übernahme. Sie können die Quellmaschine nach dem Vorgang automatisch starten (Power on target machine) oder Sie lassen das Ziel ausgeschaltet (Power off source machine). Achten Sie bitte darauf, dass nicht beide Maschinen gleichzeitig aktiv sind. Install VMware Tools on the imported virtual Machine ist an sich selbsterklärend. Wir empfehlen, diese Option zu aktivieren. Der folgende Punkt Configure guest preferences for the virtual machine ermöglicht die Anpassung der Systemkonfiguration eines Windowsservers. Es werden die Eingaben für die Punkte erwartet, die Sie in der Tabelle 12.3 sehen. Optionen
Parameter
Computer Informationen
Computername Benutzername Organisationsname Erstellung einer neuen SID
Windows Lizenz
Einstellung der Lizensierungsart, pro Server oder pro Arbeitsplatz
Zeitzone
Einstellen der Zeitzone
Netzwerk
Hier werden die Netzwerkparameter eingestellt.
Arbeitsgruppe/Domain
Festlegung ob das Zielsystem in einer Arbeitsgruppe steht oder Mitglied einer Domäne sein soll
Tabelle 12.3
Parameterübersicht für die Anpassung von Windows-Systemen
Remove System Restore checkpoints on destination entfernt alle gesetzten Punkte der sogenannten Systemwiederherstellung unter Windows, die es ermöglicht, das System zu einem bestimmten Zeitpunkt wiederherzustellen. In den meisten Fällen ist es nicht nötig, im späteren virtuellen System auf diese Punkte zuzugreifen. Reconfigure destination virtual machine aktiviert das Installieren der nötigen Device-Treiber. Diese Option sollten Sie auf jeden Fall aktivieren. Nach der Betätigung von Next erscheint eine Zusammenfassung aller Einstellungen. Sollten noch Defizite vorhanden sein, werden sie oben im Fenster darauf hingewiesen (Abbildung 12.47). Mit Finish starten Sie den Import der Maschine. Der Vorgang nimmt je nach Größe der Quellmaschine eventuell längere Zeit in Anspruch.
717
12.2
12
Konfiguration von vCenter-Add-ons
Abbildung 12.47
12.2.3
Zusammenfassung der Übernahme
Nacharbeiten nach der Übernahme
Bevor Sie die importierte Maschine starten, sollten Sie sich die Konfiguration der virtuellen Maschine anschauen. Löschen Sie die Hardwarekomponenten, die Sie nicht benötigen, so z. B. serielle Schnittstelle, parallele Schnittstelle und Audio. Achten Sie auch darauf, dass bei Wechselmedien das Client-Device eingestellt ist. Verbinden sollten Sie Floppy und CD-ROM nur, wenn Sie sie benötigen. Unter Umständen ist es später sehr zeitaufwendig, ein verbundenes CD-ROM zu suchen. Dies kann zu Problemen in der virtuellen Infrastruktur führen und auch Funktionen aushebeln. Ist der Server dann gestartet, sollten Sie die gesamte installierte Software auf den Prüfstand stellen. Deinstallieren Sie alle vom Hardwarehersteller gelieferten Tools, wie Treiber für Remote-Konsole, RAID-Treiber, Netzwerktreiber, Konfigurationstools für die Computerhardware und so weiter.
718
VMware vCenter Linked Mode
Nach der systemspezifischen Software geht es den überflüssigen Treibern des Windows-Systems an den Kragen. Legen Sie dazu eine neue System-Environment-Variable an. Sie lautet devmgr_show_nonpresent_devices mit dem Wert 1. Anschließend rufen Sie den Gerätemanager und den Menüpunkt Ansicht 폷 Ausgeblendete Geräte auf. Jetzt können Sie die nicht benötigten Gerätetreiber deinstallieren. Eine relativ einfache Richtschnur ist, sich alle Treiber anzuschauen, die mit einem ausgegrauten Symbol markiert sind. Haben Sie die Arbeiten abgeschlossen, sollten Sie den Computer neu starten. Jetzt kann die Maschine nach einem ausführlichen Applikationstest den Job des alten Servers übernehmen.
12.3
VMware Guided Consolidation
Diesem Thema ist ein eigenes Kapitel (Kapitel 16, »Kapazitätsplanung mit dem VMware Capacity Planner«) gewidmet, aus diesem Grund werden wir hier nicht näher darauf eingehen. Es handelt sich zwar um die größere Variante der Guided Consolidation, aber dort finden Sie die nötigen Informationen.
12.4
VMware vCenter Linked Mode
Mit der Einführung des Linked Modes beim vCenter-Server ist es möglich, mehrere vCenter-Server miteinander zu verbinden, so dass der Administrator einen Single Point of Contact für die Anmeldung hat. Das heißt, dass Sie sich an einem vCenter-Server anmelden und damit auch die verlinkten Hosts und virtuellen Maschinen mit administrieren können, ohne sich an jeder Infrastruktur extra anmelden zu müssen. Diese Verlinkung nehmen Sie entweder direkt bei der Installation vor – es ist nur der entsprechende Menüpunkt zu Beginn der Installation aufzurufen –, oder Sie stoßen sie nachträglich über das Start-Menü unter Start 폷 Programme 폷 VMware vCenter Server Linked Mode Configuration an (Abbildung 12.48). Wichtige Voraussetzung ist, dass der vCenter-Server Mitglied einer Domäne ist. Diese Mitgliedschaft sollten Sie vor der vCenter-Installation einrichten. Möchten Sie vCenter-Server miteinander verlinken, die nicht Mitglied ein und derselben Domäne sind, wird ein Two-Way-Trust zwischen den Domänen der vCenter-Server benötigt. Außerdem ist es äußerst wichtig, dass die Namensauflösung in beiden Richtungen funktioniert; andernfalls bricht die Installation ab. Ist der Punkt für die Verlinkung von vCenter-Servern ausgewählt, haben Sie im folgenden Schritt die Option, das vCenter zu verlinken oder es wieder zu isolieren (Abbildung 12.49).
719
12.4
12
Konfiguration von vCenter-Add-ons
Abbildung 12.48
Einrichtung von »Linked Mode« für vCenter-Server
Abbildung 12.49
Verlinkungsoptionen für vCenter-Server
Der nun folgende Dialog erwartet die Eingabe des Servers, mit dem dieses vCenter verlinkt werden soll. Eine Portangabe ist ebenfalls nötig, und auch hierbei kann es keine Kollision mit den anderen vCenter-Portkonfigurationen geben, wenn Sie vom Standard nicht abgewichen sind (Abbildung 12.50).
720
VMware vCenter Linked Mode
Abbildung 12.50
Angabe des Verlinkungsziels mit Port
Haben Sie das Ziel festgelegt und den Next-Button gedrückt, führt die Installationsroutine einige Überprüfungen durch. Probleme werden Sie auf jeden Fall bekommen, wenn die Uhrzeiten der beiden betroffenen vCenter-Server nicht abgeglichen sind. Sie werden dann mit der Fehlermeldung aus Abbildung 12.51 »belohnt«.
Abbildung 12.51
Ein Uhrzeitabgleich ist notwendig.
Sollten, nachdem die Uhrzeiten angepasst sind, weitere Probleme auftreten, wird erneut eine Fehlermeldung angezeigt (Abbildung 12.52).
Abbildung 12.52
Fehlermeldung bei Verlinkungsproblemen
721
12.4
12
Konfiguration von vCenter-Add-ons
Achtung Der Dialog sagt aus, dass die Log Datei für den Ablauf der Installation im Verzeichnis C:\Documents and Settings\.....\jointool-0.log liegt. Hier wird die Datei aber gar nicht abgelegt. Sie ist zu finden unter C:\Program Files\VMware\Infrastructure\ tomcat\temp\jointool-0.log.
Nach der erfolgreichen Installation werden alle verlinkten vCenter-Server zusammen im vSphere-Client angezeigt (Abbildung 12.53).
Abbildung 12.53
Verlinkung von zwei vCenter-Servern
Im linken Teil des Clients sind die beiden vCenter-Server zu sehen. Alle Objekte, die zu einem vCenter gehören, werden aber auch nur unter dem entsprechenden Element angezeigt, aber es ist keine weitere Anmeldung vonnöten, um auch die zweite Umgebung zu administrieren. Sollten Sie eine größere Umgebung Ihr Eigen nennen, bedenken Sie, dass Sie maximal zehn vCenter-Server miteinander verlinken können. Die Funktionen, die Sie vom vCenter her kennen, ändern sich sonst nicht; alles verhält sich wie bei einem Stand-alone-System.
12.5
VMware vCenter Server Heartbeat
vCenter Server Heartbeat ist eine relativ neue Funktion, die es ermöglicht, den vCenter-Server hochverfügbar zu machen. Das bezieht sich auch auf die Datenbank und die weitergehenden Funktionen, die VMware in das vCenter einbindet.
722
VMware vCenter Server Heartbeat
VMware hat auch eine Version auf den Markt gebracht, die mit der Vorgängerversion des vCenter-Servers zusammenarbeitet, dem Virtual Center Server. Es muss aber mindestens Version 2.5.0 des Virtual Center Servers installiert sein. Die Administration des vCenter Server Heartbeats ist jedoch sehr umfangreich, deshalb möchten wir auf diesen Aspekt genauer eingehen und ihm etwas mehr Platz einräumen. Die Gliederung des Abschnitts orientiert sich an der Reihenfolge der Funktionsbuttons auf der linken Seite (Abbildung 12.54). Die Unterpunkte entsprechen den Reitern der Funktionen.
Abbildung 12.54
Oberfläche des Heartbeat-Managements
In der Übersicht ist schön zu sehen, welches System gerade das aktive ist und welches im Standby-Modus läuft. In diesem Fall ist alles in Ordnung, und es sind keine Unregelmäßigkeiten aufgetreten. Auch die Version der Applikation ist auf beiden Servern identisch. Mit dem Auswahlpunkt unten links – derzeit als Standard sichtbar – reduzieren Sie den Umfang der Oberfläche. Ist der Standard aktiv, fehlen die Punkte Communication und Rollback. Ebenso entfallen einige Reiter, vor allem der Konfigurationsreiter in allen Unterpunkten.
723
12.5
12
Konfiguration von vCenter-Add-ons
Bevor Sie jedoch die Managementoberfläche sehen können, müssen Sie sie aufrufen, entweder über das Icon im System-Tray oder über den Menüpunkt Start 폷 All Programs 폷 VMware 폷 VMware vCenter Server Heartbeat 폷 Manage Server. Es zeigt sich eine erste Oberfläche (Abbildung 12.55).
Abbildung 12.55
Start der Managementoberfläche
Mit der Auswahl der zu verwaltenden Instanz und Klick auf Open rufen Sie das Administrationsfenster der markierten Umgebung auf. Nun möchten wir die einzelnen Punkte detailliert beschreiben.
12.5.1
Heartbeat – System
System – Status & Control Die Übersicht des Fensters System – Status & Control haben wir Ihnen schon in Abbildung 12.55 gezeigt. Außer der Anzeige der systemrelevanten Daten erhalten Sie hier die Möglichkeit, das System zu verwalten (Abbildung 12.56).
Abbildung 12.56
Aktionsbuttons für den Server Heartbeat
Im Bereich Controls können Sie vier verschiedene Aktionen initiieren. In Tabelle 12.4 werden die einzelnen Funktionen näher beschrieben. Befehl
Funktion
Start Replicating
Aktiviert in einem vorhandenen vCenter-Server-Verbund den Abgleich zwischen dem Primary und dem Secondary Server.
Tabelle 12.4
724
Befehle des Controls-Bereichs
VMware vCenter Server Heartbeat
Befehl
Funktion
Stop Replicating
Der Abgleich zwischen dem primären und dem sekundären vCenter-Server wird angehalten.
Switchover
Dieser Punkt löst einen Rollentausch zwischen dem primären und sekundären vCenter-Server aus. Diese Option sollten Sie nur auswählen, wenn die Systeme voll synchronisiert sind.
Shutdown
Hält, wie Stop Replicating, die Applikation an. Zusätzlich wird auf beiden Servern der Heartbeat-Service gestoppt.
Tabelle 12.4
Befehle des Controls-Bereichs (Forts.)
Der Punkt Shutdown wird für Heartbeat-Updates oder Konfigurationsanpassungen genutzt. Ansonsten werden nur die ersten drei Aktionen verwendet. Den Switchover können Sie selbstverständlich auch einsetzen, um nach einem Failover die ursprüngliche Reihenfolge wieder herzustellen. Der Fall, dass nach einem Failover einer der Server erneuert werden muss, wird am Ende dieses Kapitels beschrieben. System – Configuration Unter System 폷 Configuration nehmen Sie einige allgemeine Einstellungen vor (Abbildung 12.57).
Abbildung 12.57
Systemkonfiguration des Heartbeats
725
12.5
12
Konfiguration von vCenter-Add-ons
Im oberen Bereich konfigurieren Sie das Verhalten beim Stoppen des vCenterServer-Heartbeat-Services – sollen die überwachten Applikation ebenfalls gestoppt werden (Stop protected applications), oder soll die Applikation weiterlaufen (Do not stop protected applications)? Empfehlenswert ist die Einrichtung eines Mail-Accounts für die Überwachung im unteren Teil des Fensters. Hier wird der Tatsache Rechnung getragen, dass die Server möglicherweise in unterschiedlichen Netzen und auf verschiedenen Standorten stehen. Deshalb können Sie für jedes System einen eigenen Mail-Server einrichten, um so zu gewährleisten, dass die Benachrichtigungen auch ihr Ziel erreichen.
12.5.2 Heartbeat – Log Log – View Event Log Die Log-Daten des vCenter-Heartbeat-Servers können Sie unter Log 폷 View Event Log näher analysieren. Im oberen Teil des Fensters wird das Log angezeigt (Abbildung 12.58).
Abbildung 12.58
726
Anzeige der Log-Daten
VMware vCenter Server Heartbeat
Im unteren Teil des Fensters lässt sich die Anzeige einschränken, sowohl nach dem Datum als auch nach der Wichtigkeit der Meldungen. Bei der Wichtigkeit gibt es vier Stufen: Informational, Operational, Warning und Error. Das gefilterte Log können Sie über das Diskettensymbol als csv-Datei speichern. Mit dem Briefumschlag versenden Sie das Log als E-Mail. Mit Klick auf den Papierkorb löschen Sie das Log. Die Nutzung des Doppelpfeils aktualisiert die Anzeige. Ein Doppelklick auf ein Ereignis öffnet ein neues Fenster. Darin werden alle Informationen zu dem entsprechenden Event angezeigt. So können Sie weitergehende Informationen einsehen, die Sie bei der Fehlersuche unterstützen. Log – Configuration Die Einstellungen für das Log nehmen Sie unter Log 폷 Configuration vor (Abbildung 12.59).
Abbildung 12.59
Konfiguration der Log-Einstellungen
Im oberen Abschnitt geben Sie den Zielpfad und den Namen des Logs ein, wenn es exportiert wird. Im unteren Segment tragen Sie die Empfänger-E-Mail-Adressen der Personen oder Gruppen ein, die die Logs erhalten sollen, und bestimmen einen Zeitpunkt für den Mail-Versand. Zusätzlich besteht die Option, identische
727
12.5
12
Konfiguration von vCenter-Add-ons
Ereignisse, die innerhalb eines definierten Zeitintervalls auftreten, zu ignorieren, um so die Übersichtlichkeit der Dateien zu erhöhen (Ignore Repeated Events Within). Es ist sicherlich nicht sehr sinnvoll, an dieser Stelle einzelne Kollegen in die Liste der E-Mail-Adressen einzutragen. Arbeiten Sie an dieser Stelle am besten mit Verteilerlisten. Diese lassen sich einfacher pflegen, und für Anpassungen wird kein vCenter-Administrator benötigt. Hiermit sind die Einstellungen rund um das Log abgeschlossen.
12.5.3 Heartbeat – Application In der Sektion Heartbeat 폷 Application administrieren Sie die Einstellungen für die zu überwachenden Applikationen. Application – Applications Einen Überblick über die zu überwachenden Systeme erhalten Sie im Hauptfenster Applications (Abbildung 12.60).
Abbildung 12.60
Übersicht Applikationsfenster
Im obersten Segment wird der aktuelle Status der Umgebung angezeigt. Sie erkennen den aktiven Server wird und den derzeitigen Zustand der Applikation.
728
VMware vCenter Server Heartbeat
Über Clear setzen Sie die Anzeige zurück. Der folgende Abschnitt, Application Log, informiert über den Status der eigentlichen Applikationen, und zwar einzeln für jedes Softwarepaket (Abbildung 12.61).
Abbildung 12.61
Applikationsübersicht
Kommen wir zuerst zu den Konfigurationselementen auf der linken Seite. Über Remove entfernen Sie hier eine markierte Software aus der Überwachung. Besteht ein direkter Zusammenhang zwischen einer Applikation und einem Plugin, wie z. B. zwischen vCenter-Server und dem vCenter-Server-Plug-in von Neverfail, dann wird auch das Plug-in deinstalliert! Über den Button Edit ändern Sie die Timeout-Parameter eines jeden Softwarepakets (Abbildung 12.62), sowohl für das Starten als auch für das Stoppen der Applikation.
Abbildung 12.62
Parametrierung der Applikation-Timeouts
Die Knöpfe auf der rechten Seite des Fensters führen genau die Aktionen aus, die auf den Buttons beschrieben sind. Dabei wird aber der vCenter Server Heartbeat beeinflusst und nicht die zu überwachenden Applikationen. Sie können den Heartbeat starten oder stoppen sowie ihn weitergehend konfigurieren (Abbildung 12.63). Spielen Sie nicht mit den Parametern bei den Standard-vCenter-Applikationen, sondern ändern Sie die Werte hier nur, wenn Sie dazu von einem Supportmitarbeiter aufgefordert werden. Sollten Sie zusätzlich Applikationen in die Überwachung aufnehmen wollen, für die es kein Plug-in von Neverfail gibt, können Sie hier das Start-/Stopp-Verhalten beeinflussen.
729
12.5
12
Konfiguration von vCenter-Add-ons
Abbildung 12.63
Erweiterte Applikationsparameter
Aktivieren (Protect services and monitor all applications) oder deaktivieren (Unprotect services and stop monitoring all applications ...) Sie die Überwachung, gilt dies für alle Applikationen. So können Sie die Applikation temporär außer Betrieb nehmen, ohne den Server Heartbeat zu beeinflussen. Über Verbose plugin logging heben Sie das Log-Level an. Die zu überwachenden Replikationen, ob Daten oder Services, können Sie hier aktivieren. Wundern Sie sich nicht, wenn bei einem reinen vCenter-Server nur der untere Punkt aktiv ist, denn beim vCenter werden keine besonderen Daten repliziert. Der letzte Punkt, Reset rule trigger count after, gibt an, in welchem Intervall der Trigger zurückgesetzt werden soll. Der Default-Wert liegt bei 24 Stunden. Zu guter Letzt wird nach Bestätigung dieses Dialogs ein Log angezeigt, in dem die Einträge abgelegt sind, die durch die überwachten Applikationen erzeugt werden (Abbildung 12.64).
Abbildung 12.64
730
Log-Datei mit Einträgen zu den überwachten Applikationen
VMware vCenter Server Heartbeat
Hier sind Sie an der richtigen Stelle, wenn Sie Fehler im Applikationsumfeld suchen müssen. Der Filter-Button hilft bei der Optimierung der anzuzeigenden Events. Über Properties oder einen Doppelklick auf ein Ereignis öffnet sich ein Fenster, das die komplette Meldung anzeigt. Application – Services Der Services-Reiter zeigt alle überwachten Dienste an. Alle zusammengehörigen Dienste werden in einer eigenen Gruppe zusammengefasst. Zusätzlich werden im unteren Bereich, ausgegraut, alle die Dienste zusammengefasst und angezeigt, die in Abhängigkeit zu den überwachten Diensten stehen. Diese Dienste können Sie in keiner Weise manipulieren. Die Darstellung ist für eine Fehleranalyse sehr hilfreich (Abbildung 12.65).
Abbildung 12.65
Auflistung der überwachten Dienste mit Abhängigkeiten
Über die Funktion Add binden Sie zusätzliche Dienste in die Überwachung ein. Der dann erscheinende Dialog ermöglicht die Auswahl und Konfiguration eines der installierten Services (Abbildung 12.66). Konfigurieren Sie, wie der ausgewählte Dienst sich auf dem aktiven bzw. passiven Server verhalten soll. Mögliche Einstellungen sind Running, Stopped, Restarted und Any. Bei den ersten drei Punkten entspricht das Verhalten dem Options-Namen, beim letzten Punkt ist der Status unerheblich.
731
12.5
12
Konfiguration von vCenter-Add-ons
Abbildung 12.66
Hinzufügen eines Dienstes in die Überwachung
Im unteren Teil des Dialogs definieren Sie, welche Aktionen durchgeführt werden sollen, wenn der Dienst einen Fehler verursacht. Insgesamt stehen vier Optionen zur Verfügung. Bei einem Fehler wird der Dienst wiederhergestellt, es wird eine Warnung in das Log eingetragen, es erfolgt ein Schwenk auf das passive System, oder die Applikation wird neu gestartet. Mit dem Befehl Edit ändern Sie die Einstellungen eines bereits konfigurierten Dienstes. Das Fenster entspricht dem bei der Neuanlage eines Dienstes. Remove entfernt einen installierten und markierten Dienst. Application – Tasks Der Task-Reiter zeigt Tasks an, die das Heartbeat-System ausmachen. Dabei ist es unerheblich, ob es sich um Start-, Stopp- oder Monitoring-Skripte handelt. Die Ansicht ist sehr übersichtlich. Die Skripte sind nach dem relativen Zeitpunkt sortiert, zu dem sie laufen. Die Gliederung erfolgt in Pre-, Post- und periodische Skripte statt. Auch hier wird eine Gruppierung nach den Servicegruppen vorgenommen (Abbildung 12.67). Je nach Wunsch oder je nach Anforderung fügen Sie an dieser Stelle neue Tasks hinzu. Halten Sie sich an die vorgegebenen Gruppierungen, damit Sie die Übersicht nicht verlieren und auch die Kollegen sich in dem System noch zurechtfinden. Sie erhalten ein Fenster, das sich je nach gewähltem Task-Typ anders darstellt (Abbildung 12.68). Allen Versionen gemein ist aber, dass der Task einen eindeutigen Namen benötigt und natürlich einen Befehl, der ausgeführt werden soll.
732
VMware vCenter Server Heartbeat
Abbildung 12.67
Tasks-Ansicht für den vCenter Heartbeat
Abbildung 12.68
Hinzufügen eines Tasks
Zwei Task-Typen benötigen zusätzliche Angaben: der periodische Task-Typ ein Wiederholungsintervalls und der Netzwerk-Task-Typ die Angabe, auf welchem System der Task ausgeführt werden soll. Wurden an dem System keine Änderungen vorgenommen, wird unter Run As nur der lokale System-Account angeboten. Soll ein Task mit einem speziellen User gestartet werden, können Sie über den Button User Accounts einen Benutzer hinzufügen. Dieser steht dann zur Nutzung in der Applikation zur Verfügung. Über Edit lassen sich die einzelnen Tasks aktivieren oder deaktivieren. Beim periodischen Task-Typ ist der Intervallzyklus anpassbar. Mit Remove können Sie Tasks auch wieder löschen; das betrifft aber nur die Aufgaben, die nicht durch die Installation erstellt wurden. Sie können hier nur benutzerdefinierte Tasks entfernen. Über Run Now lässt sich jeder markierte Task auch außerhalb der festgelegten Zeiten jederzeit ausführen.
733
12.5
12
Konfiguration von vCenter-Add-ons
Application – Rules Rollen werden direkt durch die Installation von Plug-ins erzeugt. Es besteht keine Möglichkeit, eigene Rollen zu erstellen.
Abbildung 12.69
Anpassung der Regeln
Application – Plug-ins Im Fenster Plugins werden die installierten Neverfail-Plug-ins mit der zugehörigen Versionsnummer sowie die Parameter der Dienste angezeigt. Auch hier können Sie verschiedene Aktionen durchführen; die Namen der Buttons sind wieder Programm.
Abbildung 12.70
734
Auflistung der installierten Plug-ins
VMware vCenter Server Heartbeat
12.5.4 Heartbeat – Communication Ein äußerst wichtiger Abschnitt ist die Konfiguration des Netzwerks. An dieser Stelle nehmen Sie alle Einstellungen vor, die für die interne Kommunikation zwischen den zu schützenden Servern wichtig sind; dazu gehört auch der Paketfilter. Gestaltete sich die Konfiguration und Administration der Applikation doch recht komplex, so sind die Einstellmöglichkeiten im Umfeld der Kommunikation nicht ganz so aufwendig. Communication – Status Im Status-Fenster werden die Daten zum Heartbeat- bzw. Channel-Netzwerk angezeigt (Abbildung 12.71).
Abbildung 12.71
Statusansicht der Channel- bzw. Heartbeat-Kommunikation
Außer dem Verbindungsstatus werden die IP-Adressen des Channels und die geflossene Datenmenge angezeigt. Abschließend zeigt die Anzeige den Status des Heartbeat-Netzwerks an. Communication – Configuration Unter Communication 폷 Configuration (Abbildung 12.72) können Sie die Einstellungen für das private Netzwerk beeinflussen. Wurden nach der Installation keine Änderungen vorgenommen, ist der Punkt Failover If Active Server’s Public Network Connection Is Lost nicht aktiv. Wenn Sie das erste Mal in dieses Konfigurationsfenster schauen, können Sie nur die Werte in den unteren beiden Blöcken manipulieren. Unter Channel Heartbeat geben Sie an, wie viele Netzwerkpakete auf dem Channel-Netzwerk verlorengehen dürfen, bevor ein Failover initiiert wird. Zusätzlich bestimmen Sie
735
12.5
12
Konfiguration von vCenter-Add-ons
beim Heartbeat Interval, in welchen Zeitabständen der passive Server die Heartbeat-Pakete zum aktiven Server sendet.
Abbildung 12.72
Konfiguration der Kommunikation
Der Wert Max. Disk Usage gibt an, wie viele Daten maximal in der Queue stehen können. Bei den Daten handelt es sich um die Informationen, die zum passiven Server gesendet werden müssen, damit die Server-Systeme im Einklang bleiben. Die Anpassung dieses Wertes wird empfohlen, wenn das aktive und das passive System nur über WAN miteinander verbunden sind. In diesem Fall ist der Wert zu erhöhen. Als Letztes besteht die Option, den Punkt Max Server Time Difference zu konfigurieren. Die Angabe zeigt die maximale Zeitdifferenz, die zwischen dem aktiven und dem passiven Server liegen darf. Seien Sie bitte vorsichtig, denn der passive Server kann, da das produktive Netzwerk-Interface inaktiv ist, keinen ZeitServer erreichen. Die einzige Möglichkeit besteht darin, einen Zeit-Client auf der Maschine zu installieren und den aktiven Server als Zeit-Server zu nutzen. Wird der passive zum aktiven Server, müssen Sie diesen Mechanismus aber deaktivieren, denn sonst wären zwei konkurrierende NTP-Clients aktiv, zum einen der zum Domänen-Controller und zum anderen der zum passiven Server.
736
VMware vCenter Server Heartbeat
Kommen wir nun zu den übrigen Optionen für die Kommunikation im öffentlichen Netzwerk, die Sie im oberen Berech des Fensters sehen können. Dabei gehen wir die Abschnitte von oben nach unten durch. Wenn Sie die oben beschriebene Option aktivieren, schalten Sie die Überwachung des öffentlichen Netzwerks ein. Geben Sie im oberen Feld, Max Ping Echoes Missed Before Failover, an, wie viele Pings verlorengehen dürfen, bevor ein Failover ausgelöst wird. Bestimmen Sie unter Ping Interval, in welchen Abständen die Pings angesetzt werden sollen. Tragen Sie unter Time Out For Ping Echoes den Zeitwert ein, ab dem ein Ping als nicht durchlaufend angesehen wird. Der Standardwert liegt hier bei 5 Sekunden. Wird diese Rückantwortzeit überschritten, gilt der Ping als nicht erfolgreich. Bei der Überwachung des öffentlichen Netzes werden automatisch drei Zielpunkte im Netzwerk angesprochen, um die Aktivität des Anschlusses zu kontrollieren. Somit soll gewährleistet sein, dass ein Zugriff auf das System möglich ist. Die drei Standard-Zielpunkte sind das Standard-Gateway, der DNS-Server und der Gobal-Catalog-Server. Sollte die Notwendigkeit bestehen zusätzliche Punkte auszuwählen, aktivieren Sie die Option Auto Select. In diesem Fall müssen Sie das ausgewählte Ziel direkt eingeben. Bedenken Sie, dass Sie verschiedene ZielIP-Adressen angeben müssen, wenn der Heartbeat-Server-Verbund in unterschiedlichen Netzen steht, z. B. bei einer Verbindung über ein WAN. Es ergibt keinen Sinn, Komponenten anzugeben, die hinter der WAN-Verbindung stehen und unter Umständen für eines der Systeme nicht erreichbar sind. Communication – Split-Brain Avoidance Configuration Eine wichtige Konfigurationsmöglichkeit bietet der Reiter Split-Brain Avoidance Configuration. An dieser Stelle legen Sie das Verhalten des Server Heartbeats beim Ausfall des Channel-Netzwerks fest (Abbildung 12.73), wenn die öffentliche Adresse noch erreichbar ist. Achtung Diese Konfiguration ist für Sie nur wichtig, wenn die Heartbeat-Server über ein WAN verbunden sind.
Die beiden oberen Parameter sind Ihnen schon aus dem vorhergehenden Reiter bekannt. Auch hier geben Sie wieder die Randbedingungen für die Überwachung des Netzwerks an. Die unteren Felder nehmen die öffentlichen IP-Adressen der beiden vCenter-Server auf. Bei einer Trennung der Netzwerke über ein WAN dürfen diese nicht identisch sein.
737
12.5
12
Konfiguration von vCenter-Add-ons
Abbildung 12.73
Verhalten beim Ausfall des Netzwerk-Channels
12.5.5 Heartbeat – Data Data – File Synch and Verify Damit die beiden Server zu jeder Zeit wechselseitig aktiv sein können, müssen Sie nicht nur die Datenbankinhalte identisch halten, sondern auch verschiedene Dateien umkopieren. In dem Fenster Data werden die Informationen zu diesem Thema bereitgestellt (Abbildung 12.74).
Abbildung 12.74
Anzeige des Datenabgleichs
Im oberen Teil wird mittig der Status angezeigt. Der linke obere Bereich listet die zu spiegelnden Verzeichnisse auf, der Bereich rechts daneben die zugehörigen Dateien. Die auslösbaren Aktionen sind selbsterklärend. Aktive und offene Tasks sehen Sie links bzw. rechts im unteren Teil des Fensters.
738
VMware vCenter Server Heartbeat
Data – Registry Sync and Verify Der Abschnitt Synch and Verify beschäftigt sich ebenfalls mit der Synchronisation der beiden Server. Nur geht in diesem Fall nicht um das File-System, sondern um die Registry. Die Anzeige an dieser Stelle ist nicht so detailliert wie beim File-System. Es wird nur der Status dargestellt, und es besteht die Option, eine Synchronisation anzustoßen. Data – Configuration Welche Filter für die File-Synchronisation zum Einsatz kommen, sehen Sie unter Configuration. Die Auflistung gliedert sich in drei Abschnitte: Filter für das vCenter, Filter für die Datenbank und benutzerdefinierte Filter. Sie können selbstverständlich Einträge hinzufügen (Abbildung 12.75).
Abbildung 12.75
Filterlisten für die Datensynchronisation
Dabei ist es aber auch möglich, Ausschlusslisten von Dateien anzufügen. Egal welche Dateien von den hinzugefügten Filtern betroffen sind, sie werden immer unter user Defined angezeigt.
12.5.6 Heartbeat – Alerts Unter Heartbeat 폷 Alerts richten Sie die weitergehende Überwachung des Systems ein. Alerts – Reporting Das System als solches dokumentiert die auftretenden Aktionen und Ereignisse mit einer Vielzahl von Meldungen. Die Wertigkeit der Meldungen und die durchzuführenden Aktionen beim Auftreten der Fehler hinterlegen Sie hier. Im oberen Bereich des Fensters geben Sie die E-Mail-Adressen an, die die aktivierten Nachrichten erhalten sollen (Abbildung 12.76). Denken Sie auch an dieser Stelle
739
12.5
12
Konfiguration von vCenter-Add-ons
daran, besser mit Verteilerlisten zu arbeiten und nicht die Administratoren einzeln einzupflegen.
Abbildung 12.76
E-Mail-Benachrichtigung für Applikationsereignisse
Die Einstellungen an diesem Punkt gestalten sich sehr einfach. Sie können nur das Ziel für die Benachrichtigungen konfigurieren, die der vCenter Server Heartbeat erzeugt. Getrennt wird hier nur zwischen den roten, den sogenannten kritischen Meldungen und den gelben, den weniger kritischen Meldungen. Der Nachrichtentext lässt sich individuell anpassen. Des Weiteren kann ein Kommando ausgeführt werden, wenn eine Meldung erzeugt wird. Es gibt aber keine individuellen Anpassungen für differierend auftretende Fehlerkombinationen. Es kann nur eine generische Aktion durchgeführt werden, wenn eine gelbe oder eine rote Meldung erzeugt wird. Damit die Benachrichtigung den Empfänger auch erreicht, muss zuvor die Konfiguration unter System richtig parametriert worden sein (siehe Abschnitt 12.5.1 in diesem Kapitel). Alerts – Configuration Haben Sie im vorherigen Abschnitt die Benachrichtigung als solche eingestellt, so legen Sie an diesem Punkt die Wertigkeit einer Meldung fest. Hier obliegt es dem Administrator festzulegen, ob eine Meldung für ihn kritisch und / oder unkritisch ist (Abbildung 12.77).
740
VMware vCenter Server Heartbeat
Abbildung 12.77
Auflistung der Meldungswertigkeit
Die markierten und aktiv ausgewerteten Nachrichten werden farblich hinterlegt. Der Farbcode zeigt direkt an, welche Wertigkeit eine Meldung hat. Es lassen sich keine Events hinzufügen oder anpassen. Sie können nur die Meldungen nutzen, die die Firma VMware respektive Neverfail zur Verfügung stellt.
12.5.7 Heartbeat – Rollback Wurden bei der Installation des Betriebssystems keine Anpassungen vorgenommen, dann besteht auf den Reitern des Abschnitts Rollback keine Einstellmöglichkeit. Voraussetzungen für Einstellmöglichkeiten an dieser Stelle sind zum einen die Aktivierung des Volume Shadow Services und zum anderen der Erwerb eines Zusatzmoduls der Firma Neverfail. Wir möchten an dieser Stelle nur auf die Funktionen eingehen, die VMware direkt zur Verfügung stellt, und erläutern, was zu tun ist, damit Sie die Funktion Rollback nutzen können. Im Kontextmenü der Festplatte aktivieren Sie auf Wunsch die Volumen-Schattenkopien. Über die Eigenschaften und den Reiter VSS gelangen Sie in das Konfigurationsfenster. Der Dienst sorgt dafür, dass das File-System z. B. vor einer Sicherung in einen beruhigten Zustand gebracht wird, damit die Daten in der Sicherung konsistent sind. Tiefer möchten wir an dieser Stelle nicht auf das
741
12.5
12
Konfiguration von vCenter-Add-ons
Thema eingehen, die Knowledge Base von Microsoft bietet hervorragende Artikel zum Thema VSS.
12.5.8 Heartbeat – Hinweise Bedenken Sie bitte: So angenehm die Funktion des vCenter Server Heartbeats auch ist, es werden nur die Änderungen übertragen, die zu der zu überwachenden Applikation gehören. Schnell wird vergessen, dass einige Betriebsprozesse in einer Heartbeat-Konfiguration nicht so einfach einzuhalten sind. Als Beispiel möchten wir hier das Viren-Pattern anführen. Vom Administrator wird erwartet, dass er die folgenden Fragen beantworten kann: 왘
Wie kann das Viren-Pattern verteilt werden, wenn die Maschine nicht im produktiven Netzwerk steht?
왘
Wie können Patches verteilt werden?
왘
Wie werden allgemeine Konfigurationsänderungen eingespielt?
Berücksichtigen Sie bei den Überlegungen, das Produkt einzusetzen, wie die in Ihrem Hause üblichen Betriebsprozesse eingehalten werden können.
12.6
VMware Data Recovery
Wird nach der Installation die Data Recovery Appliance gestartet, bootet das Linux in einen rudimentären Schirm, in dem sich einige einfache Konfigurationsänderungen durchführen lassen (Abbildung 12.78).
Abbildung 12.78
Startbildschirm der VMware Data Recovery Appliance
An dieser Stelle können Sie die Netzwerkeinstellungen der Appliance anpassen und die Zeitzone konfigurieren. Die bessere Wahl, aus unserer Sicht, ist die Nutzung der Managementoberfläche via Webbrowser. Der Zugriff erfolgt über die im Konsolenfenster angezeigte IP-Adresse. Achten Sie bitte darauf, dass der benötigte Port 5480 im Netzwerk freigegeben ist. Wird die angegebene Adresse im Browser eingegeben, dann folgt die Anmeldung auf der Oberfläche (Abbildung 12.79).
742
VMware Data Recovery
Abbildung 12.79
Anmeldung an der Managementkonsole
Die Anmeldung für den Administrator erfolgt mit dem User root und dem Passwort »vmw@re«. Jetzt können Sie einige Einstellungen an der Server-Konfiguration vornehmen (Abbildung 12.80).
Abbildung 12.80
Hauptfenster der Managementkonsole des Data-Recovery-Servers
Das Hauptfenster der Appliance bietet zwei Reiter. Der erste Reiter ist eine Statusanzeige für das Recovery–System; hier sehen Sie unter anderem die Appliance-Version. Des Weiteren können Sie den Server herunterfahren oder neu booten. Im zweiten Reiter nehmen Sie die Netzwerkeinstellungen vor (Abbildung 12.81).
Abbildung 12.81
Kontrolle der Netzwerkeinstellungen
743
12.6
12
Konfiguration von vCenter-Add-ons
Das erste Fenster zeigt die aktuellen Netzwerkeinstellungen. Nach Aktivierung des Buttons Address lassen sich die IP-Einstellungen anpassen. Entweder aktivieren Sie DHCP mit Obtain configuration from DHCP Server, oder Sie nehmen die IP-Konfiguration in den unteren Eingabefeldern statisch vor (Abbildung 12.82).
Abbildung 12.82
Konfiguration der IP-Einstellungen
Sollten Sie die IP-Konfiguration anpassen, müssen Sie sich nach der Aktivierung der Einstellungen mit Save Settings neu mit der Appliance über die dann aktuelle IP-Adresse verbinden. Die vorhergehende Verbindung geht aufgrund der Änderung der IP-Konfiguration verloren. Falls ein Proxy-Server in Ihrem Environment steht, können Sie ihn unter dem Punkt Proxy aktivieren (Abbildung 12.83).
Abbildung 12.83
Proxyeinstellungen des Data Recovery
Weitere Einstellungen lassen sich über das Web-Interface nicht vornehmen. Sie können den Dialog an dieser Stelle über den Logout-Link verlassen. Die weiteren Funktionen der Data Recovery Appliance rufen Sie über den Data Recovery Client über das vCenter auf. Sie finden ihn unter Home 폷 Inventory 폷 Solutions and Applications 폷 VMware Data Recovery. Mit diesem Client führen Sie die unterschiedlichen Sicherungs- und Rücksicherungsarbeiten durch.
744
VMware Data Recovery
Eine Übersicht und eine Anpassung des Clients sind über das vCenter-Plug-in möglich. Nach dem Aufruf des Plug-ins zeigt sich Ihnen die Oberfläche aus Abbildung 12.84.
Abbildung 12.84
Oberfläche des Data Recovery Clients
Die allgemeinen Einstellungen für die Sicherungsjobs nehmen Sie unter dem Reiter Configuration vor. Unter dem Punkt Destinations legen Sie das Ziel der Sicherung fest. Als Ziel können SAN (Storage Area Network), NAS (Network Attached Storage) und CIFS (Common Internet File-System) zum Einsatz kommen, also jede von vSphere unterstützte Disk. Berücksichtigen Sie bitte, dass eine Verbindung mit einem CIFS-Ziel nur über die IP-Adresse erfolgen kann. Der FQDN ist an dieser Stelle nicht unterstützt. Auf diesem CIFS Ziel werden die Daten gesichert. Damit die zu sichernde Datenmenge nicht zu umfangreich wird, wird der Datenstrom dedupliziert, was bedeutet, dass identische Daten nicht mehrfach auf das Sicherungsziel geschrieben werden. Sind zu sichernde Daten schon vorhanden, werden im aktuellen BackupStream die entsprechenden Dateien nur auf das vorhandene Ziel verlinkt. Bei der Deduplizierung müssen Sie einige Punkte beachten. Der Zieldatenträger sollte mindestens doppelt so groß sein wie die zu sichernde Datenmenge. Ist das Ziel kleiner, kann die Appliance nicht richtig deduplizieren. Außerdem stellt ein VMFS-Datastore als Sicherungsziel eine Besonderheit dar: Bei diesem Ziel erfolgt im Gast eine Formatierung mit Nullen; damit funktioniert das Thin Provisioning von VMware nicht mehr. Des Weiteren haben auch viele Storage-Hersteller Probleme mit ihren Thin-Provisioning-Funktionen. Uns ist derzeit nur ein Hersteller
745
12.6
12
Konfiguration von vCenter-Add-ons
bekannt, der mit diesem Umstand sauber umgehen kann, und zwar die Firma 3PAR mit ihren Produkten. Über den Link Log werden die Log-Dateien der VMware Data Recovery Appliance angezeigt. Der Reiter Backup listet alle erstellten Backup-Jobs. Selbstverständlich können Sie an dieser Stelle mit dem Button New auch neue Jobs erstellen (Abbildung 12.85).
Abbildung 12.85
Erstellung eines Backup-Jobs
Im vorliegenden Beispiel soll die VM Bert-VC gesichert werden. Markieren Sie den Server, und wählen Sie im nächsten Schritt das Ziellaufwerk für die Datensicherung aus. Konfigurieren Sie dann das Zeitfenster für die Datensicherung (Abbildung 12.86). Das Management, wann die Datensicherung wirklich zeitlich terminiert wird, obliegt der internen Planung der Software. Im aktuellen Fall ist es dem System erlaubt, montags bis freitags von 0:00 bis 6:59 Uhr und von 18:00 bis 23:59 Uhr zu sichern. An Samstagen und Sonntagen gibt es keine zeitlichen Einschränkungen. Der folgende Schritt beschäftigt sich mit der Aufbewahrungszeit der Sicherung (Abbildung 12.87).
746
VMware Data Recovery
Abbildung 12.86
Datensicherungszeitplan
Abbildung 12.87
Aufbewahrungsfristen für die Datensicherung
Drei Sicherungszyklen sind im System vorkonfiguriert. Sollten diese nicht ausreichen, besteht die Option, sich eine eigene Policy einzurichten. Für den von Ihnen definierten Zeitraum sperren Sie die letzten – in diesem Fall sieben –, relevanten Sicherungen. Zusätzlich zu den sieben Sicherungen werden die Sicherungen gesperrt, die den unteren Kriterien genügen.
747
12.6
12
Konfiguration von vCenter-Add-ons
Nach der Fertigstellung des Jobs können Sie diesem in der zentralen Oberfläche einen sprechenden Name geben. Das User-Interface bietet die Anpassungsoptionen für den Job. Hier sind alle bereits gesehenen Optionen frei änderbar. Der Backup-Job lässt sich über das Kontextmenü starten. Das System markiert jede virtuelle Maschine, die über einen entsprechenden Job gesichert wird, mit einem neuen Icon. Das Icon der VM enthält dann zusätzlich einen kleinen weißen Haken in einem grünen Kreis. Im Log-Fenster sehen Sie den Erfolg des Backups (Abbildung 12.88).
Abbildung 12.88
Positiver Sicherungsabschluss
Wurde eine Maschine gesichert, besteht selbstverständlich die Möglichkeit, den Server wiederherzustellen. Diesen Prozess stoßen Sie über das Kontextmenü der VM an, oder Sie wechseln auf den Reiter Restore (Abbildung 12.89).
Abbildung 12.89
Restore einer gesicherten Maschine
Die möglichen Funktionen im Reiter Restore und im Kontextmenü unterscheiden sich ein wenig voneinander. Im Reiter Restore starten Sie nicht nur die Wie-
748
VMware Data Recovery
derherstellung, sondern stellen auch den Umgang mit den erfolgten Sicherungen ein. Mit Lock wird eine Sicherung länger aufbewahrt. Das Gegenteil ist bei Mark for Delete der Fall: Hier erteilen Sie dem System die Freigabe, diese markierte Sicherung zu löschen. Das Kontextmenü enthält den zusätzlichen Punkt Restore Rehearsal. Im Gegensatz zum einfachen Restore wird bei Restore Rehearsal parallel zu der vorhandenen Maschine eine Kopie der VM mit den Sicherungsdaten erstellt. Über diesen Mechanismus besteht die Möglichkeit, Dateien aus der parallel erstellten Maschine herauszukopieren und zurück in das Original zu schreiben. Alternativ legen Sie bei Problemen in einer VM parallel eine Kopie in einem isolierten Netzwerk an, um darin eine Fehleranalyse vorzunehmen. Achtung Bedenken Sie bitte, dass zur Durchführung der Datensicherung ein Snapshot in der virtuellen Maschine erstellt wird. Dieser wird erst wieder gelöscht, wenn die Datensicherung abgeschlossen ist. Bei der Planung der LUNs des vSphere-Servers ist das entsprechend zu berücksichtigen. Achten Sie darauf, dass immer genügend freier Plattenplatz auf den LUNs vorhanden ist!
Data Recovery – Hinweise Im Gegensatz zu anderen VMware-Appliances gibt es keine Möglichkeit, die VMware Data Recovery Appliance upzudaten, es ist auf jeden Fall eine Neuinstallation notwendig. Dies ist aber gar nicht so kritisch, wie es sich anhört, denn die Konfigurationsdaten liegen auf dem Deduplizierungs-Storage neben den Sicherungen. Somit konfiguriert sich die aktualisierte Appliance automatisch, wenn die Daten auf dem Storage erkannt wurden. Aktualisieren Sie den Datensicherungs-Server regelmäßig, denn es werden immer wieder viele Bugfixes und Funktionserweiterungen zur Verfügung gestellt. So profitieren Sie von den Korrekturen und Erweiterungen. Nun stellt sich abschließend die Frage, wie leistungsfähig die Datensicherungsmaschine ist. Ausführliche Tests haben ergeben, dass es ohne weiteres möglich ist, 100 virtuelle Maschinen mit einer Appliance zu sichern. Machen Sie sich aber keine Sorgen, wenn Ihre Landschaft wesentlich größer ist, denn es ist kein Problem und wird vor allem auch unterstützt, mehrere dieser Server in einer Landschaft zu betreiben. Achten Sie nur darauf, dass Sie die Sicherungszeiten der unterschiedlichen Server miteinander koordinieren.
749
12.6
In diesem Kapitel erhalten Sie einen Überblick über virtuelle Maschinen, deren Einrichtung und Betrieb.
13
Virtuelle Maschinen Autor dieses Kapitels ist Carsten Schäfer, G-TAC IT-Beratung, [email protected]
13.1
Grundlagen
13.1.1
Was ist eine virtuelle Maschine?
Eine virtuelle Maschine gaukelt einem Gastbetriebssystem ein Intel-x86-System vor, wahlweise 32 oder 64 Bit. Die virtuelle Maschine (VM) stellt virtuelle Hardware bereit, damit diese aus der Sicht des Gastbetriebssystems so genutzt werden kann, wie es sich auch bei physischen Servern verhalten würde. Einige Ausnahmen gibt es, diese stellen wir aber in diesem Kapitel vor.
Abbildung 13.1
13.1.2
Eine virtuelle Maschine besteht aus virtueller Hardware.
Virtuelle Hardware
CPU und Speicher Die CPU und der Hauptspeicher einer virtuellen Maschine werden im Gegensatz zur restlichen virtuellen Hardware nicht emuliert, sondern durch die VMware-
751
13
Virtuelle Maschinen
ESX-Virtualisierungsschicht nahezu identisch mit der physischen Hardware einer VM bereitgestellt. Beim Speicher können Sie durch die VMware-Technologie Memory-Overcommitment mehr Speicher als tatsächlich vorhanden zur Verfügung stellen, indem Sie einen Teil des Speichers einer VM auf Datastores (DAS, SAN, NFS) in Dateiform ablegen, anstatt ihn im physischen RAM des ESX-Servers zu nutzen. Ausführliche Informationen zu den Grundlagen und dem Ressourcenmanagement von CPU und Memory erhalten Sie iin Kapitel 2, »vSphere - Architektur«. Diskettenlaufwerk Das Medium des virtuellen Diskettenlaufwerks einer VM können Sie auf unterschiedliche Weise konfigurieren. Dabei bleibt die virtuelle Hardware im Gastbetriebssystem immer identisch, aber das Medium kann jederzeit angepasst werden. Außerdem ist es möglich, verschiedene Quellen als Medium zu nutzen. Für die virtuelle Maschine wird unabhängig von der Quelle immer ein lokales Diskettenlaufwerk mit oder ohne Diskette gesehen. Des Weiteren kann das Medium im laufenden Betrieb der VM hinzugefügt oder entfernt werden (Device-Status) oder grundsätzlich beim Starten der VM immer zur Verfügung stehen. Folgende Möglichkeiten stehen zur Verfügung: 왘
Client Device Diese Einstellung ermöglicht das Verbinden des Diskettenlaufwerks im Gast mit einem physisch vorhandenen Diskettenlaufwerk oder einem FloppyImage auf dem PC oder Server, auf dem der Virtual Center Client läuft und die VMware Console geöffnet werden kann. Bei Nutzung eines Images muss dieses nur vom vSphere-Client-Programm erreichbar sein und nicht vom ESXServer oder der virtuellen Maschine.
왘
Host Device Diese Einstellung bietet eine Verbindung zum im ESX-Server eingebauten Diskettenlaufwerk. Dabei müssen Sie die Unix-Schreibweise des Devices verwenden, z. B. /dev/fd0. Diese Einstellung ist nicht empfehlenswert, da es zu Problemen mit VMotion und DRS kommen kann. Außerdem blockiert eine eingelegte bootfähige Diskette möglicherweise sämtliche VMs mit konfiguriertem Host-Device beim Starten, da die virtuellen Maschinen von Diskette booten.
왘
Use existing floppy image in datastore (bestehendes Floppy-Image im Datastore verwenden) Bei dieser Einstellung kann ein vorhandenes Floppy-Image auf dem VMwareDatastore verwendet werden. Dieses muss vorher in ein beliebiges Verzeichnis auf dem VMware-Datastore kopiert werden. Außerdem kann das lokale
752
Grundlagen
/vmimage-Verzeichnis des ESX-Servers genutzt werden. Allerdings gelten hier die gleichen Nachteile bezüglich VMotion und DRS wie bei der Nutzung des Host-Devices. 왘
Create new floppy image in datastore (neues Floppy-Image im Datastore erstellen) Bei dieser Einstellung wird ein neues Floppy-Image auf dem VMware-Datastore erstellt und dann der VM bereitgestellt. Die Auswahl dieser Option bleibt nicht bestehen, sondern die vorherige Option, Use existing floppy image in datastore wird aktiviert und als Auswahl das neu erstellte FloppyImage definiert.
CD-ROM-/DVD-Laufwerk Genau wie das Diskettenlaufwerk können Sie auch ein virtuelles CD-ROM-/DVDLaufwerk einer VM konfigurieren. Die grundsätzlichen Eigenschaften sind mit denen des virtuellen Diskettenlaufwerks identisch, allerdings bestehen bessere Möglichkeiten zur Nutzung von Medien mit großen Datenmengen. Folgende Möglichkeiten stehen zur Verfügung: 왘
Client Device Diese Einstellung ermöglicht das Verbinden des CD-ROM-/DVD-Laufwerks im Gast mit einem physisch vorhandenen CD-Laufwerk auf dem PC oder Server, auf dem Virtual Center Client läuft und die VMware Console geöffnet werden kann. Alternativ verbinden Sie das Laufwerk des Gastes auch mit einem ISO-Image. Dieses Image muss vom vSphere-Client aus erreichbar sein.
Zusätzlich zur Auswahl dieser Option können Sie den Modus der Verbindung zum Client-Device konfigurieren: 왘
Passthrough IDE Dies ist die Standardeinstellung für die Verbindung zu einem physischen Laufwerk und bietet die größte Performance. Optional definieren Sie hier die exklusive Nutzung des Laufwerks von der virtuellen Maschine.
왘
Emulate IDE Die Einstellung bietet nur Lesezugriff auf eine CD oder DVD, da der Zugriff emuliert wird.
왘
Host Device Diese Einstellung bietet eine Verbindung zum im ESX-Server eingebauten CDROM-/DVD-Laufwerk. Dabei müssen Sie die Unix-Schreibweise des Devices verwenden, z. B. /dev/cdrom. Bitte beachten Sie die Einschränkungen für VMotion.
753
13.1
13
Virtuelle Maschinen
왘
Datastore ISO file Bei dieser Einstellung kann ein vorhandenes ISO-Image auf einem VMwareDatastore verwendet werden. Dieses muss vorher in ein beliebiges Verzeichnis auf dem VMware-Datastore kopiert werden.
Abschließend können Sie die ID des virtuellen Devices ändern. Standardmäßig ist diese beim ersten Laufwerk immer 0:0, beim zweiten 0:1, beim dritten 1:0 und beim vierten Laufwerk 1:1. SCSI-Controller Als SCSI-Controller werden folgende Typen unterstützt: 왘
BusLogic Parallel
왘
LSI Logic Parallel
왘
LSI Logic SAS
왘
VMware Paravirtual
Der BusLogic-Parallel-Controller wird von älteren Gastbetriebssystemen verwendet. Den LSI-Logic-Parallel-Controller hingegen nutzen neuere Betriebssysteme, und LSO Logic SAS steht nur virtuellen Maschinen ab der Version 7 zur Verfügung. Der Typ VMware Paravirtual ist ebenso nur in Version 7 von VMs einsetzbar und bietet die beste Performance bei geringerer CPU-Auslastung; allerdings wird dieser Controller-Typ im Gastbetriebssystem bislang ab Windows 2003 und für RHEL 5 unterstützt. Seit dem Update 1 von vSphere steht auch ein Floppy-Image mit passenden Treibern zur Verfügung, um diese während der Installation des Betriebssystems zu installieren. Ein weiterer Nachteil zeigt sich darin, dass weniger Features unterstützt werden. Es wird ab dem Update 1 von vSphere Bootpartitionen von Windows Server 2003 und Windows Server 2008 unterstützt. Für Linux steht dies noch nicht zur Verfügung – verwenden Sie für die Bootpartitionen wie bislang einen LSI-Controller. Den paravirtualisierten Controller setzen Sie dann zum Betrieb weiterer Festplatten in der VM ein, um z. B. Daten oder Datenbanken darauf abzulegen. Des Weiteren werden die Features Record/ Replay und Fault-Tolerance nicht unterstützt, genauso wenig wie der Einsatz von Microsoft Clustering. Beim Einsatz des HotAdd-Features von Festplatten muss das Gastbetriebssystem einen Rescan anstoßen, um die neuen Festplatten im laufenden Betrieb zu erkennen. Bei der Änderung des Controller-Typs müssen Sie darauf achten, dass das Gastbetriebssystem über die notwendigen Treiber verfügt, da das Betriebssystem ansonsten die virtuellen Festplatten nicht mehr sehen und verwenden kann.
754
Grundlagen
Hierzu installieren Sie entweder die Treiber des zukünftigen Controllers vorher im Gast, oder Sie fügen zu dem bestehenden Controller den neuen Controller hinzu, um die Treiber zu installieren und abschließend den ursprünglichen Controller zu entfernen. Zusätzlich können Sie eine Richtlinie über das SCSI-Bus-Sharing definieren. Weitere Informationen dazu erhalten Sie in Abschnitt 13.2.2, »Festplattenkonfiguration«. Netzwerkkarten Eine virtuelle Maschine kann je nach Gastbetriebssystem aus folgenden Netzwerkkartentypen auswählen: 왘
vlance
왘
vmxnet
왘
vmxnet 3
왘
Flexible
왘
E1000
왘
vmxnet 2 (Enhanced)
Nachfolgend finden Sie weitere Informationen über die von VMware je nach ausgewähltem Gastbetriebssystem bereitgestellten Netzwerkadaptertypen: 왘
vlance Dieser Typ stammt noch aus der grauen Vorzeit und funktioniert auf allen Betriebssystemen, da keine VMware Tools benötigt und die im Betriebssystem enthaltenen Standardtreiber verwendet werden. Dieser Typ lässt sich nur noch für virtuelle Maschinen früherer ESX-Versionen auswählen und ist recht CPU-intensiv.
Der vlance-Typ ist der kleinste gemeinsame Nenner in den Typen der Netzwerkkarten. Er ist eine virtuelle Abbildung der physischen Netzwerkkarte AMD PCnet32 und bietet geringste Funktionalität, geringste Performance, aber dafür maximale Kompatibilität. Die meisten 32-Bit-Betriebssysteme, außer Microsofts Vista und später, bieten nativen Support für diesen Netzwerkkartentyp. Dieser Typ wird gerne bei der Erstellung von Bootdisketten auf Basis von Microsofts DOS oder Windows 9x verwendet. Für den Einsatz in den heute gängigen Betriebssystemen wird dieser Typ nicht mehr empfohlen. Dieser Netzwerkkartentyp belastet die CPU des Host-Systems, da eine komplette Emulation stattfindet.
755
13.1
13
Virtuelle Maschinen
왘
vmxnet Ebenso wie vlance lässt sich vmxnet nur auf VMs früherer ESX-Versionen auswählen und ist automatisch gesetzt, wenn der Typ »Flexible« gewählt wurde und die VMware Tools im Gast installiert wurden. Der vmxnet-Typ wurde von VMware entwickelt, um in virtuellen Umgebungen optimale Performance zu bieten. Da es für diesen Typ keine Hardwareentsprechung gibt, existiert in keinem Betriebssystem native Treiber-Unterstützung für diesen Typ von Netzwerkkarte. Durch die Installation der VMware Tools innerhalb des Gastbetriebssystems wird neben anderen Hardwaretreibern der Treiber für diesen Netzwerkadaptertyp installiert. Der vmxnet-Adapter ist ein paravirtualisierter Adapter, das heißt, der Treiber im Gastbetriebssystem ermöglicht eine optimale Kommunikation in der virtuellen Umgebung. Dadurch ist die Leistungsfähigkeit höher und die CPU-Belastung des Host-Systems geringer.
왘
vmxnet 2 (Enhanced) Für 32–Bit- und 64-Bit-Gastbetriebssysteme ist dieser Typ eine optimierte Variante des vmxnet-Adapters und steht seit ESX 3.5 zur Verfügung. Die VMware Tools werden hierfür zwingend benötigt.
Dieser Typ erweitert den vmxnet um verschiedene Features wie z. B. der Unterstützung von Jumbo-Frames. Eine Einschränkung bei diesem Typ ist die Kompatibilität der VM beim Einsatz älterer ESX-Server (vor 3.5) in einem Datacenter. Hierbei können Sie keine VM zwischen einem ESX 3.5- und einem älteren ESX-Host migrieren. Allerdings wird dieser Typ nicht von allen Betriebssystemen im Gast unterstützt, sondern nur von den folgenden:
왘
왘
Microsoft Windows 2003 Enterprise und Datacenter Edition, 32 und 64 Bit
왘
Microsoft Windows 2003 Standard Edition (32 und 64 Bit) unter Vorbehalt (Hierzu gibt es von VMware einen Workaround, um diesen Typ zu verwenden: http://kb.vmware.com/selfservice/microsites/search.do?language=en_ US&cmd=displayKC&externalId=1007195.)
왘
Microsoft Windows XP, 32 Bit
왘
Red Hat Enterprise Linux 5.0, 32 und 64 Bit
왘
SUSE Linux Enterprise Server 10, 32 und 64 Bit
왘
Red Hat Enterprise Linux 4.0, 64 Bit
왘
Ubuntu Linux, 64 Bit
vmxnet 3 Dieser Typ erweitert den vmxnet 2 und stellt VMwares dritte Generation der paravirtualisierten Adapter dar. Er bietet die meisten Netzwerk-Features und
756
Grundlagen
höchste Performance, ist aber erst ab der Hardwareversion 7 der virtuellen Maschinen verfügbar. Der Einsatz der VMware Tools ist bei diesem Typ zwingend erforderlich. Dieser Typ wird nur von folgenden Betriebssystemen unterstützt: 왘
Microsoft Windows XP und später, 32 und 64 Bit
왘
Red Hat Enterprise Linux 5.0 und später, 32 und 64 Bit
왘
SUSE Linux Enterprise Server 10 und später, 32 und 64 Bit
왘
Asianux 3 und später, 32 und 64 Bit
왘
Debian 4/Ubuntu 7.04 und später, 32 und 64 Bit
왘
Sun Solaris 10 U4 und später, 32 und 64 Bit
Zusätzlich zu den in vmxnet 2 neuen Features bringt der vmxnet 3-Adapter Unterstützung für folgende Netzwerk-Features mit: 왘
MSI/MSI-X
왘
Receive Side Scaling (wird ab Windows 2008 unterstützt und muss explizit aktiviert werden)
왘
IPv6-Checksum
왘
IPv6 TCP Segmentation Offloading (TSO)
왘
VLAN Off-Loading
왘
Erhöhung der TX/RX-Ringgrößen (wird in der virtuellen Maschine aktiviert)
왘
Flexible Dieser Typ ist, wie der Name schon preisgibt, ein flexibler, der zwischen den Netzwerkadaptertypen »vlance« und »vmxnet« umschalten kann. Während des Bootvorgangs einer VM verhält sich dieser Typ wie der Typ vlance, sie können ihn aber durch einen geeigneten Treiber (in den VMware Tools enthalten) in den Modus des vmxnet-Adapters umschalten. Ist im Gastbetriebssystem kein VMware-Tools-Netzwerkkartentreiber installiert, bleibt der Adapter im Modus des Typs vlance; das bringt zwar optimale Kompatibilität, aber garantierte Performance-Einbußen. Dieser Typ steht für 32-Bit-Gastbetriebssysteme ab der ESX-Server-Version 3 bereit.
왘
E1000 Für 64-Bit-Gastbetriebssysteme ab der ESX-Server-Version 3 emuliert dieser Typ eine Intel-82545EM-Gigabit-Ethernet-Karte und wird hierfür standardmäßig vorgegeben. Ebenso wird dieser Adapter von Microsoft Vista (32 und 64 Bit) unterstützt. VMwares Angaben zufolge liegt die Performance dieses Adaptertyps zwischen vlance und vmxnet.
757
13.1
13
Virtuelle Maschinen
Hardware
Maximum
SCSI-Controller
4
Devices pro SCSI-Controller (z. B. Festplatte)
15
Devices insgesamt, unabhängig vom VM-Betriebssystem
60
Größe einer SCSI-Festplatte
2 TByte
virtuelle CPUs
8
maximaler Speicher
255 GByte
Netzwerkkarten
10
IDE-Devices
4
Diskettenlaufwerke
2
parallele Ports
3
serielle Ports
4
Größe der Swap-Datei
255 GByte
Verbindungen via Remote Console
40
Tabelle 13.1
13.1.3
Maximale Ausstattung einer VM
Bestandteile einer virtuellen Maschine
Eine virtuelle Maschine setzt sich aus verschiedenen Dateien zusammen, deren Namen alle den Namen der virtuellen Maschinen besitzen und durch die Endung unterschieden werden: 왘
vmx-Datei Diese Datei enthält die Konfiguration der virtuellen Maschine, wie diese z. B. im vSphere-Client über Settings im Kontextmenü einer VM eingerichtet wurde.
왘
vmdk-Datei Diese Datei stellt die virtuelle Festplatte dar, und pro virtuelle Festplatte existieren zwei Dateien. Beispiel: Hat eine VM eine Festplatte, so existieren die zwei Dateien servername.vmdk und servername-flat.vmdk. Dabei enthält die Datei servername.vmdk Informationen über die emulierte physische Zusammensetzung sowie den Namen der eigentlichen Datei mit den Festplattendaten, in der Regel die Datei servername-flat.vmdk. Pro Festplatte einer VM werden diese Dateien erstellt, dabei bekommen alle weiteren virtuellen Festplatten die Namen der VM mit dem Anhang _durchlaufende Nummer, z. B. servername_1.vmdk und servername_1-flat.vmdk.
758
Grundlagen
Abbildung 13.2 왘
Der Inhalt einer Konfigurationsdatei (vmx)
vswp-Datei Diese Datei ist die Swap-Datei pro virtuelle Maschine. Die Größe ist identisch mit der RAM-Größe abzüglich einer etwaig vorhandenen RAM-Reservierung der VM. Dieses Swapfile benötigt der VMkernel, um der virtuellen Maschine die konfigurierte Speichermenge auch dann zur Verfügung zu stellen, wenn der physische Speicher des ESX-Servers dies nicht mehr hergibt. Bedenken Sie bei Ihrer Planung der Datastores, dass sich zu den vmdk-Dateien immer diese Dateien hinzugesellen, sobald die VM eingeschaltet wird. Bei virtuellen Maschinen mit sehr großem Speicher von beispielsweise 16 GByte wird der Plattenplatz auf einem Datastore sehr schnell knapp. Vergeben Sie
759
13.1
13
Virtuelle Maschinen
eine RAM-Reservierung auf 100 %, wird die Swap-Datei auf eine Größe von 0 verkleinert. Die Swap-Datei hat immer die Größe »Zugewiesene Speichergröße – Speicher-Reservierung«. 왘
vmxf-Datei Diese Datei enthält erweiterte Konfigurationsdaten.
왘
vmsd-Datei Diese Datei speichert Meta-Informationen über eventuell vorhandene Snapshots einer VM.
왘
nvram-Datei Diese Datei beinhaltet die BIOS-Einstellungen einer VM.
왘
log-Dateien Die Dateien mit der Endung log enthalten die Protokollierung der VM-Aktivitäten und sind im Fehlerfalle für das Troubleshooting sehr nützlich. Die aktuelle Datei heißt immer vmware.log, die älteren Dateien vmware-n.log wobei n eine fortlaufende Nummer ist. Hat die aktuelle Datei die maximale Größe erreicht, so wird diese mit der nächst höheren Nummer versehen und eine neue, leere vmware.log-Datei wird angelegt.
왘
vmss-Datei Diese Datei wurde bei einer suspendierten VM erstellt und enthält den eingefrorenen Status dieser.
13.2
Erstellung von virtuellen Maschinen
Virtuelle Maschinen können über mehrere Wege erstellt werden: 왘
über den vSphere-Client mittels des New Virtual Machine Wizards
왘
VMware SDK respektive das PowerCLI oder das CLI
왘
Cloning (erstellt Repliken von bestehenden VMs)
왘
Importieren (importiert eine im OVF-Format gespeicherte VM oder vApp)
왘
Deploy from Templates (VMware-Provisioning-Methode)
왘
Consolidate/VMware Converter (P2V-Migration von bestehenden physischen Servern)
왘
weitere Anwendungen wie VMwares Lab Manager oder VMwares Lifecycle Manager
Auf den nachfolgenden Seiten beschreiben wir die Wizard-Methode via vSphereClient.
760
Erstellung von virtuellen Maschinen
Mit Hilfe des vSphere-Clients können Sie entweder eine VM im Virtual Center anlegen oder, wenn Sie direkt auf einem ESX-Server verbunden sind, direkt auf diesem. Eine VM im vCenter kann unter folgenden Objekten erstellt werden: 왘
Cluster
왘
Host
왘
Virtual Machine Folders
Je nach Verbindungsart (vCenter oder ESX) und Startobjekt variieren die einzelnen Schritte des Wizards; er fragt nur die für die aktuelle Auswahl notwendigen Informationen ab. Den New Virtual Machine Wizard starten Sie beispielsweise, indem Sie das jeweilige Objekt markieren und im Kontextmenü den Befehl New Virtual Machine auswählen. Im ersten Schritt werden Sie gefragt, ob Sie eine typische (Typical) oder eine angepasste (Custom) Installation einer VM durchführen möchten. Die beiden Wege unterscheiden sich darin, dass der Wizard bei der Auswahl von Typical eine Reihe von standardmäßigen Voreinstellungen annimmt. Bei der Auswahl von Custom werden zusätzliche Schritte abgefragt. Hier finden Sie eine Übersicht der beiden Wege: Typische Installation
Benutzerdefinierte Installation
Name und Location
Name und Location
Resource-Pool
Resource-Pool
Datastore
Datastore Virtual Machine Version
Guest Operating System
Guest Operating System CPUs Memory Network SCSI Controller
Create a Disk
Select a Disk
Ready to Complete
Ready to Complete
Tabelle 13.2
Vergleich der Schritte einer typischen und einer angepassten Installation
Die Schritte zur Erstellung einer virtuellen Maschine im Custom-Modus sind:
761
13.2
13
Virtuelle Maschinen
1.
Nach dem Starten des Wizards und Auswahl von Custom vergeben Sie den Namen der VM und wählen einen Ablageort aus. Dieser Name ist zum einen der Inventarname der VM, zum anderen werden die Dateien, die die VM auf dem Dateisystem des Datastores abbilden, anhand dieses Namens benannt. Die maximale Länge sind 80 Zeichen.
2.
Wählen Sie den ESX-Host oder Cluster aus, auf dem die virtuelle Maschine angelegt werden soll.
3.
Legen Sie den Resource-Pool fest, sofern die VM in einem Resource-Pool abgelegt werden soll.
4.
Definieren Sie den Datastore, das heißt, auf diesem VMFS-Laufwerk werden die Dateien der VM gespeichert.
5.
Sollten sich im Datacenter ESX-Server unterschiedlicher Versionen befinden, so steuern Sie in diesem Schritt, in welcher Version die VM angelegt werden soll. Wenn eine VM via VMotion oder Storage VMotion auch auf einem ESXServer 3.x verschoben werden muss, dann wählen Sie die Version 4! 왘
Version 4: für alle ESX-Server der Version 3.x
왘
Version 7: für alle ESX-Server der Version 4.x
6.
Wählen Sie das Gastbetriebssystem aus.
7.
Je nach ausgewähltem Gastbetriebssystem schlägt der Wizard CPU- und Memory-Standardwerte vor, die Sie aber anpassen können.
8.
Legen Sie die Netzwerk-Verbindungen der virtuellen Maschine fest. Dabei geben Sie an, wie viele virtuelle Netzwerkkarten diese VM erhalten soll, mit welchem Netzwerk diese Netzwerkkarten jeweils verbunden werden soll und welcher Netzwerkkarten-Treiber dazu verwendet werden soll.
9.
Der Wizard schlägt den optimalen SCSI-Controller vor. Sie wählen aus folgender Liste aus : 왘
BusLogic Parallel
왘
LSI Logic Parallel
왘
LSI Logic SAS
왘
VMware Paravirtual
Im Wizard ist die Standardeinstellung abhängig vom Gastbetriebssystem bereits vorgewählt. 10. Haben Sie den Controller festgelegt, folgt nun die Auswahl der virtuellen Disk. Hier haben Sie bis zu vier Möglichkeiten: 왘
762
Create a new virtual disk: Der Wizard erstellt eine neue virtuelle Festplatte, und Sie legen im folgenden Schritt die Größe, den Speicherort (im
Erstellung von virtuellen Maschinen
Verzeichnis der VM oder auf einem alternativen Datastore) und die Optionen zum Disk-Provisioning (Einsatz von Thin Provisioning und FaultTolerance) fest. 왘
Use an existing virtual disk: Sie wählen im nächsten Schritt eine virtuelle Disk in Form einer vmdk-Datei aus.
왘
Raw Device Mappings: Bestimmen Sie nachfolgend eine LUN im SAN, die von der VM direkt angesprochen wird.
왘
Do not create disk: Sie überspringen diesen Schritt und weisen eine virtuelle Festplatte später zu.
11. Sie haben die Möglichkeit, die SCSI-Device-ID oder IDE-Device-ID zu verändern oder den Independent-Disk-Mode zu aktivieren: Die Optionen Persistent und Non-persistent legen fest, ob Änderungen an der virtuellen Festplatte unwiderruflich in die Festplatte geschrieben werden oder bei einem Power-Off der VM wieder verworfen werden. Beim Einsatz des Independent-Disk-Modes sind keine Snapshots möglich. 12. Der letzte Schritt im Wizard zeigt eine Zusammenfassung aller gewählten Optionen an und bietet nochmals die Gelegenheit, verschiedene Einstellungen zu ändern oder weitere Optionen einzustellen. Hierbei wird die virtuelle Maschine im Bearbeitungsmodus angezeigt.
13.2.1
Netzwerkkonfiguration
Während des Anlegens der VM können Sie im Wizard eine bis mehrere Netzwerkkarten der VM hinzufügen. Nachträglich können die bestehenden Netzwerkkarten im ausgeschalteten Zustand der VM verändert oder gelöscht sowie neue hinzugefügt werden. Beim Anlegen einer Netzwerkkarte geben Sie den Typ an und wählen die auf dem ESX-Server konfigurierte Port-Group aus. Die zur Verfügung stehenden Netzwerktypen sind abhängig von der Version der VM (diese wiederum richtet sich danach, auf welchem ESX-Host die VM erstellt oder aktualisiert wurde) und dem Gastbetriebssystem. Die Auswahl des Adaptertyps steht nur beim Hinzufügen einer Netzwerkkarte zur Verfügung. Wenn eine VM bereits angelegt und die Auswahl des Gastbetriebssystems unter Options 폷 General Options 폷 Guest Operating Systems geändert wurde, lässt sich der Typ eines bestehenden Netzwerkadapters nicht ändern. Die für das neu ausgewählte Gastbetriebssystem verfügbaren Netzwerkkarten werden nur beim Hinzufügen neuer Netzwerkadapter als Option angeboten.
763
13.2
13
Virtuelle Maschinen
Bei der automatischen Vergabe der MAC-Adresse stellt VMware sicher, dass diese Adresse auf den ESX-Servern bislang noch nicht verwendet wurde, und garantiert dadurch eine Eindeutigkeit. Bei der manuellen Vergabe muss der VIAdministrator selbst dafür sorgen.
13.2.2
Festplattenkonfiguration
In diesem Abschnitt erhalten Sie weitere Informationen über die verschiedenen Modi einer virtuellen Festplatte, das RDM (Raw-Device-Mapping) sowie das SCSI-Bus-Sharing. Einleitend sei noch erwähnt, dass es ab ESX 3.5 möglich ist, eine VM ohne virtuelle Festplatte zu erstellen, z. B. um die Erstellung dieser via Kommandozeilentool (vmkfstools) durchzuführen oder diese virtuelle Maschine ohne Festplatte zu betreiben, z. B. als eine Router-VM. Independent – Non-independent Der Virtual-Disk-Mode Non-independent ist der standardmäßig eingestellte Mode einer Virtual Disk. In diesem Modus verhält sich eine virtuelle Festplatte einer VM genauso, wie es eine physische Festplatte tun würde – der verwaltet sämtliche Schreibzugriffe auf die Festplatte durch das Gastbetriebssystem. Dabei wird eine weitere Schicht über eine einzelne virtuelle Festplatte gelegt, die eine REDO-Datei erzeugte, die später dann verworfen wurde. Dieser Mode existiert noch in ESX 3.x-Umgebungen und stellt wiederum zwei Verfahren zur Verfügung: den Persistent und den Non-persistent Mode. Der Independent Mode wird heute beispielsweise verwendet, um die Sicherung von virtuellen Festplatten über den VCB (VMware Consolidated Backup) zu verhindern. 왘
Persistent Mode Im Persistent Mode werden alle Daten direkt auf die Festplatte geschrieben, das heißt, die Festplatte funktioniert im Endeffekt ganz normal. Sie müssen allerdings beachten, dass es hierbei kein Zurück mehr gibt, weil diese Festplatten nicht mehr über das Snapshot-Verfahren abgedeckt werden. Wenn Sie demnach einen gesicherten Snapshot zurückspielen, werden die seit dem Snapshot vorgenommenen Änderungen auf einer persistenten Festplatte trotzdem bestehen bleiben.
왘
Non-persistent Mode Der Non-persistent Mode ist das genaue Gegenteil des Persistent Modes, es werden nämlich keine Änderungen der virtuellen Festplatte zurückgeschrieben. Alle Änderungen gehen beim Ausschalten der virtuellen Maschine oder
764
Erstellung von virtuellen Maschinen
beim Zurückschreiben eines Snapshots unwiederbringlich verloren. Diese Option wäre beispielsweise sinnvoll für Kiosk-PCs oder auch PCs in einer Hotel-Lobby, wo nach der Abmeldung sämtliche Änderungen im Gast-Datensatz wieder verworfen werden. RAW-Device-Mapping Unter VMware ESX ist es möglich, eine physische Festplatte direkt der virtuellen Maschine zuzuordnen. Aber diese physische Festplatte muss zwingend eine SANLUN oder eine Festplatte an einem ausschließlich für den VMkernel genutzten SCSI-Adapter sein. Dabei wird immer die komplette Festplatte beansprucht, was eine Formatierung im VMFS von vornherein ausschließt. Allerdings muss der Festplatten-Controller über eine eindeutige SCSI-Serial verfügen, damit Sie die angeschlossenen Festplatten mittels RDM nutzen können. RDM ist weiterhin für die Verwendung der NPIV-Fibre-Channel-Virtualisierung notwendig. Um eine solche Festplatte anzulegen, wählen Sie beim Hinzufügen einer virtuellen Festplatte den Punkt Raw Device Mappings aus. Seit der VMFS-Version 2 ist es möglich, bezüglich des eigentlichen Raw-Devices Metadaten abzulegen, die statt der Target-ID (z. B. vmhba0:0:0:1) eine Zuordnung über einen sprechenden Namen im Dateisystem erlauben. Diese Metadaten sind im Prinzip einfach eine Verknüpfungsdatei, die statt des direkten Zugriffes genutzt wird. Sie ist im Heimatverzeichnis der virtuellen Maschine als vmdk-Datei zu finden. Werden VMs mit RDM geclont, werden die RDM-Festplatten automatisch im Heimatverzeichnis der virtuellen Maschine in Form virtueller Festplatten erstellt. Diese Information ist besonders zu beachten, da keine Warnung über den freien Festplattenplatz eines Datastores erscheint. Bei einem Clone einer VM mit 1 TB RDM würde eine Festplattendatei von 1 TB auf dem Datastore der VM angelegt! Storage VMotion wird derzeit bei der Verwendung von RDM nur im virtual compatibility mode unterstützt. Bei der Auswahl des Kompatibilitätsmodus Physical kann das Gastbetriebssystem direkt auf die SAN-LUN zugreifen, das ist sinnvoll für z. B. SAN-awareAnwendungen. Nachteilig ist, dass eine VM mit RDM (Raw-Device-Mapping) im PhysicalModus nicht geclont werden und auf Basis dieser VM kein Template erstellt werden kann. Außerdem werden für diesen Festplattenmodus keine Snapshots unterstützt. Nur wenn Sie beim Anlegen dieser Festplattenzuordnung unter dem Punkt Compatibility Mode die Option Virtual auswählen, stehen Ihnen alle erweiterten Festplattenmodi wie Persistent oder Non-persistent (im Mode Independent) zur
765
13.2
13
Virtuelle Maschinen
Verfügung. Auch besteht in diesem Modus die Möglichkeit, von VMwareSnapshots Gebrauch zu machen. Gerade im Umfeld des VMware ESX Servers gibt es zwei große Server-Installationen, in denen physische Festplatten ihren Nutzen voll entfalten: Die wichtigste Gruppe sind zweifellos Cluster-Systeme, genauer gesagt Cluster zwischen virtuellen und physischen Systemen, die ohne eine RDM nicht realisierbar wären. Weitere Kandidaten sind virtuelle Maschinen mit einer hohen Frequenz von Festplattenzugriffen, da sich durch die direkte Verlinkung mit der physischen Festplatte die Leistungsfähigkeit immens erhöht. Generell werden jedoch produktive Cluster zwischen virtuellen Maschinen auf unterschiedlichen Host-Systemen (Clusteracross-Boxes) nur mit Raw-Device-Mappings unterstützt. Nachteilig ist bei Clustern jedoch die Bestimmung, dass die Systemplatten der Cluster-Nodes auf lokalem Storage liegen müssen, was kein VMotion und kein DRS zulässt. Daher nutzen viele VMware-Kunden entweder keine Cluster unter VMware oder gehen den nicht unterstützten Weg, die Systemfestplatten im SAN zu belassen. SCSI-Bus-Sharing Das SCSI-Bus-Sharing ermöglicht das gleichzeitige Verwenden der virtuellen Festplatten durch mehrere virtuelle Maschinen. Dies wird z. B. beim Einsatz von Microsoft Clustern in virtuellen Maschinen für die gemeinsam genutzte Festplatte wie die Quorum-Disk benötigt. Die Einstellung ist eine Konfiguration des SCSI-Controllers und muss vom jeweiligen Host unterstützt werden. Folgende Optionen stehen zur Auswahl: 왘
None Die virtuellen Festplatten an diesem SCSI-Controller können nicht mit anderen VMs gemeinsam verwendet werden.
왘
Virtual Die virtuellen Festplatten an diesem SCSI-Controller können von anderen VMs mitverwendet werden, sofern diese auf dem gleichen ESX-Server liegen.
왘
Physical Die virtuellen Festplatten an diesem SCSI-Controller können von anderen VMs mitverwendet werden, auch wenn diese auf anderen ESX-Servern liegen.
Gemeinsam genutzte virtuelle Festplatten müssen mit Nullen beschrieben werden. Dazu steht folgender Konsolenbefehl zur Verfügung: vmkfstools [-w |--writezeroes] /vmfs/volumes/<mydir>/<myDisk>.vmdk
766
Erstellung von virtuellen Maschinen
13.2.3 Aktualisieren der virtuellen Hardware Wenn Sie nicht auf der grünen Wiese mit einer vSphere-Implementierung starten, so haben Sie in Ihrer aktuellen Umgebung bereits virtuelle Maschinen im Einsatz, die bestenfalls mit der Hardwareversion 4 ausgestattet sind. vSphere 4 bringt die Hardwareversion 7 mit, und VMwares Empfehlung an dieser Stelle ist, die aktuelle Hardwareversion zu verwenden. Version 7 bietet Ihnen neue virtuelle Hardware an, z. B. den vmxnet 3-Netzwerkadapter, bis zu acht vCPUs je nach vSphere-Edition, bis zu 256 MB RAM pro VM, EVC-Unterstützung, HotAdd und HotPlug. Das Aktualisieren der VM-Hardware geschieht über den Befehl Upgrade Virtual Hardware, beispielsweise über das Kontextmenü einer VM.
Abbildung 13.3
Upgrade der VM-Hardware
Sehr oft sind die VMware Tools noch nicht auf den aktuellen Stand gebracht worden, und in diesem Fall erhalten Sie einen Warnhinweis, dass die Netzwerkeinstellungen der VM zurückgesetzt werden.
767
13.2
13
Virtuelle Maschinen
Abbildung 13.4
Warnhinweis beim Upgrade
Laut VMware-Empfehlung sollten Sie allerdings vor dem VMware-HardwareUpgrade erst eine Aktualisierung der VMware Tools durchführen. Der Vorgang benötigt unter Windows mehrere Neustarts der VM und geht insgesamt so vonstatten: 1. Update der VMware Tools 2. Reboot 3. Herunterfahren der VM 4. Upgrade der VM-Hardware 5. Start der VM 6. Erkennung der neuen Hardware durch Windows 7. Reboot Unter Linux ist der Vorgang identisch, nur dass lediglich für den HardwareUpgrade ein Reboot beziehungsweise ein Herunterfahren notwendig ist. Nach dem Upgrade haben Sie eine VM mit aktueller virtueller Hardware. Jetzt können Sie auch die neuen VM-Features einsetzen.
Abbildung 13.5
13.3
Die VM wurde auf die aktuelle Version aktualisiert.
Eigenschaften einer virtuellen Maschine – Optionen
Für jede virtuelle Maschine können Sie individuell weitere Einstellungen treffen. Diese umfassen im Groben:
768
Eigenschaften einer virtuellen Maschine – Optionen
왘
Anzeige des Namens und des Ablageorts der VM, Möglichkeit zur Änderung des Namens
왘
vApp-Optionen
왘
Änderung der Auswahl des Gastbetriebssystems
왘
Verhalten der VM bei Power-Aktivitäten (Einschalten, Ausschalten, Reset, Suspend)
왘
VMware-Tools-bezogene Einstellungen wie das Aktivieren von VMwareTools-Skripts, Überprüfung der Version und gegebenenfalls Aktualisierung dieser beim Einschalten der VM oder Zeitsynchronisation mit der VM
왘
Verhalten der VM bei Betriebssystem-Standby
왘
erweiterte Einstellungen wie z. B. Logging, Debug-Modus, VMotion-Kompatibilität, Bootverhalten, Aktivierung der VMI-Paravirtualisierung, Zuweisung von Fibre-Channel-WWNs, Optionen zur Virtualisierung der MMU (Memory Management Unit) und Auswahl des Speicherorts der Swap-Datei
13.3.1
Änderung des Namens und des Ablageorts der VM
In den Eigenschaften einer VM im Reiter Optionen haben Sie im Abschnitt General Options die Möglichkeit, den Namen der VM zu ändern. Diese Änderung wirkt sich aber nicht auf das VMFS aus, auf dem die Dateien dieser VM liegen, das heißt, der Verzeichnisname, in dem sich die VM befindet, und die Dateien werden nicht geändert. Die Änderung kann nur bei ausgeschalter VM durchgeführt werden. Ebenso finden Sie an gleicher Stelle den kompletten Pfad des Ablageorts der VM-Dateien.
13.3.2 Änderung des Gastbetriebssystems In den Eigenschaften einer VM im Reiter Optionen können Sie im Abschnitt General Options das konfigurierte Gastbetriebssystem ändern. Die VM muss dabei ausgeschaltet sein. Eine Änderung an dieser Stelle wirkt sich nicht auf das Gastbetriebssystem direkt aus, es wird lediglich die Konfigurationseinstellung in der vmx-Datei geändert. Aufgrund dieser Konfigurationseinstellung jedoch beruhen sämtliche Empfehlungen zur Hardware-Ausstattung einer virtuellen Maschine. Bereits eingerichtete virtuelle Hardware, die durch das Anlegen der VM durch z. B. den Wizard definiert wurde, ändert sich nicht nachträglich. Je nach getroffener Auswahl wird auch die Art des VMware-Tools-Setups geändert, um es an die Rahmenbedingungen des Betriebssystems anzupassen. Diese Option zum Ändern des Gastbetriebssystems ist sinnvoll, wenn das Gastbetriebssystem einer VM durch ein Upgrade aktualisiert wird, z. B. Windows Server 2003 auf Windows Server 2008.
769
13.3
13
Virtuelle Maschinen
Abbildung 13.6 Sie sehen den Ablageort der Dateien der virtuellen Maschine ein und können den Namen der VM im vCenter-Inventory und das Gastbetriebssystem ändern.
13.3.3 Erweiterung der Power-Aktivitäten durch die VMware Tools Nach der Installation der VMware Tools im Gastbetriebssystem bieten die »Power«-Buttons weitere Optionen zum Verhalten der VM respektive deren Betriebssystems. Diese Einstellung können Sie im auch im eingeschalteten Zustand einer VM vornehmen; Sie finden sie unter VMware Tools. 왘
Power Off-Schalter Diesen Schalter können Sie anstelle seiner standardmäßigen Funktion zum »harten« Ausschalten einer VM (Hard Power-Off) auch zum geregelten Herunterfahren des Gastbetriebssystems und anschließendem Ausschalten umkonfigurieren werden (Soft Power-Off). Des Weiteren ist auch die systemweite Standardeinstellung möglich. Wie diese aktuell konfiguriert ist, wird bei der Auswahl angezeigt.
왘
Reset-Schalter Diesen Schalter können Sie anstelle seiner standardmäßigen Funktion zum »harten« Ausschalten einer VM (Hard Reset) und anschließendem Neustart der VM auch zum geregelten Herunterfahren des Gastbetriebssystems und anschließendem Neustart dieser umkonfigurieren (Soft Reset). Des Weiteren ist auch die systemweite Standardeinstellung möglich. Wie diese aktuell konfiguriert ist, wird bei der Auswahl angezeigt.
Der Power On-Schalter zum Einschalten oder Reaktivieren (Resume) einer VM lässt sich nicht umkonfigurieren.
770
Eigenschaften einer virtuellen Maschine – Optionen
13.3.4 Automatische Ausführung der VMware-Tools-Skripte Die VMware Tools können im Gastbetriebssystem je nach Power-Aktivität Skripte ausführen, um z. B. Datenbankdienste zu stoppen oder zu starten. Die möglichen Skripte sind: 왘
Nach dem Einschalten einer VM (Power On-Schalter einer ausgeschalteten VM) wird das Skript poweron-vm-default ausgeführt.
왘
Nach dem Reaktivieren (Fortsetzen) aus dem Suspend-Modus (Power OnSchalter bei suspendierter VM) wird das Skript resume-vm-default ausgeführt.
왘
Vor dem Suspendieren (Anhalten) einer VM (Pause-Schalter bei eingeschalteter VM) wird das Skript suspend-vm-default ausgeführt. Unter einem Windows-Gast wird eine per DHCP vergebene IP-Adresse der VM freigegeben, und unter Linux werden die Netzwerkdienste gestoppt.
왘
Vor dem Herunterfahren einer VM (Power Off-Schalter bei eingeschalter VM) wird das Skript poweroff-vm-default ausgeführt.
Die standardmäßig aktivierten und vorhandenen Skripte liegen innerhalb der virtuellen Maschine in einem Windows-Betriebssystem im Verzeichnis %ProgramFiles%\VMware\VMware Tools und in einem Linux-Betriebssystem im Verzeichnis /etc/vmware-tools. Möchten Sie hingegen eigene Skripte verwenden, so hinterlegen Sie diese in der virtuellen Maschine und definieren den Pfad in der Konfiguration der VMware Tools im Reiter Scripts.
Abbildung 13.7 Anstelle der Default-Skripte können Sie in der VM eigene Skripte verwenden.
Die Konfiguration nehmen Sie im Reiter Options der VM-Eigenschaften im Bereich VMware Tools vor.
771
13.3
13
Virtuelle Maschinen
13.3.5 Automatische Aktualisierung der VMware Tools Bei jedem Einschalten einer VM kann überprüft werden, ob die neueste Version der VMware Tools im Gastbetriebssystem installiert ist, und können bei Bedarf installiert werden. Beachten Sie dabei, dass bei der Verwendung von WindowsVMs ein Neustart nach Aktualisierung der VMware Tools durchgeführt und bei Linux VMs die Netzwerkverbindung kurz unterbrochen wird. Die automatische Aktualisierung der VMware Tools steht ab der Version 3 der VMware Tools zur Verfügung, das heißt, je nach Versionsstand Ihrer Umgebung (z. B. vor einem vSphere-Upgrade) könnte zuerst ein einmaliges Upgrade der VMware Tools über andere Verfahren anstehen, um dieses Feature zukünftig nutzen zu können. Sie aktivieren dieses Feature im Reiter Options der VM-Eigenschaften, Bereich VMware Tools.
13.3.6 Zeitsynchronisation der VM mit dem ESX-Server Das Feature Zeitsynchronisation übermittelt dem Gastbetriebssystem durch die VMware Tools die jeweilige Zeit vom ESX-Server. Diese Kommunikation findet direkt über den VMkernel statt, der dem Gastsystem die Uhrzeit zur Verfügung stellt, das heißt, es muss keine Netzwerkverbindung zwischen dem Host-System und der virtuellen Maschine bestehen. Sie aktivieren die Zeitsynchronisation durch VMware im Reiter Options der VMEigenschaften unter VMware Tools.
Abbildung 13.8 Einstellung der Power-Aktivitäten, VMware-Tools-Aktualisierung und Zeitsynchronisation der virtuellen Maschine
772
Eigenschaften einer virtuellen Maschine – Optionen
Beachten Sie dabei, dass die VMware Tools im Abstand von 60 Sekunden die neue Uhrzeit übernehmen. Außerdem wird die Uhrzeit nur vor- und nicht zurückgestellt, da es im Normalfall bei virtuellen Maschinen nur zu einer verlangsamten Zeitberechnung kommt. Eine Ausnahme besteht bei der Nutzung mancher Linux-Systeme, deren Kernel-Konfiguration zu einer beschleunigten Zeitberechnung führt. In diesem Fall müssen Sie einen Kernel-Parameter (Grub Boot Parameter – clock = pit) anpassen.
13.3.7 Power-Management des Gastbetriebssystems Durch die Power Management-Einstellungen lässt sich das Verhalten einer VM durch einen Standby-Modus des Gastbetriebssystems ändern. Die Standardeinstellung weist eine VM an, in den Suspend-Modus zu gehen. Alternativ ändern Sie dies abhängig vom Gastbetriebssystem, so dass die VM im normalen Poweron-Status bleibt. Zusätzlich können Sie in diesem Bereich noch zusätzlich definieren, ob das Wake-on-LAN-Feature für diese VM ermöglicht werden soll. Hierzu müssen Sie noch den Netzwerkadapter der VM angeben, über den das Wake-onLAN-Paket erwartet wird. Dieses Wake-on-LAN-Feature steht momentan nur für Windows-Betriebssysteme innerhalb der VM zur Verfügung und setzt auch eine virtuelle Netzwerkkarte vom Typ Flexible voraus. Des Weiteren können Sie das Power Management nur bei ausgeschalteter VM konfigurieren. Diese Einstellung nehmen Sie im Bereich Power Management vor.
13.3.8 Erweiterte Konfiguration: Logging, Debugging, Acceleration und erweiterte Konfigurationsparameter Standardmäßig ist das Protokollieren aller VM-Aktivitäten aktiv und kann bei Bedarf, z. B. bei Ressourcenproblemen, deaktiviert werden. Diese Änderung ist auch im eingeschalteten Zustand einer VM möglich. Die Protokolldateien finden Sie auf dem VMFS-Volume im jeweiligen Ordner der VM (diesen können Sie im ersten Abschnitt des Reiters Options einsehen), sie tragen die Endung .log. In Ausnahmefällen wird der VMware-Support Sie anweisen, eine VM mit zusätzlichen Debug-Features zu betreiben. Dabei werden zur Fehleranalyse erweiterte Informationen zur Laufzeit einer VM in eine Datei geschrieben. Je nach Gastbetriebssystem stehen Ihnen neben den Debug-Informationen auch Statistiken zur Verfügung. Dieses Feature lässt sich nur bei ausgeschalteter VM aktivieren. Um die maximale Geschwindigkeit im Betriebssystem einer VM zu erhalten, ist die Beschleunigung (Acceleration) einer VM grundsätzlich aktiv. In bestimmten Fällen behindert dies die Installation oder Ausführung einer Applikation und
773
13.3
13
Virtuelle Maschinen
kann deaktiviert werden. Meistens finden Sie hierzu die Information im VMware-Forum oder erhalten sie direkt vom VMware-Support. In seltenen Fällen wird Sie der VMware-Support bei Problemen mit bestimmten Applikationen in einer VM anweisen, entweder bestehende erweiterte Konfigurationsparameter zu ändern oder neue hinzuzufügen. Gehen Sie hier mit größter Vorsicht vor, da neu erstellte Einträge nicht mehr gelöscht werden können, und das Entfernen des Values des Key/Value-Paares kann bei bestimmten Parametern eine VM nicht mehr startbar hinterlassen. In solch einem Fall müssen Sie die VMEinstellungen dokumentieren, eine neue VM mit der Option, eine vorhandene Disk als virtuelle Festplatte (oder mehrere) zu nutzen, erstellen, und nach dem Kopieren aller vmdk-Dateien aus dem Speicherplatz der zerstörten VM in das Verzeichnis der neuen VM die vmdk-Dateien in die VM einbinden. Alle genannten Einstellungen nehmen Sie im Reiter Options in den Eigenschaften einer VM im Abschnitt Advanced 폷 General vor.
Abbildung 13.9 Einstellungen zu Logging, Acceleration und den erweiterten Konfigurationsparametern
13.3.9 Erweiterte Konfiguration: CPU Identification Mask Die CPU Identification Mask unterstützt die Kompatibilität von unterschiedlichen CPUs der ESX-Server bei VMotion-Operationen. Diese Einstellungen können nur bei ausgeschalteter VM vorgenommen werden und verstecken in erster Linie das Nx-Flag der CPU vor den Augen des Gastbetriebssystems, damit die VM auf einen ESX-Host ohne das CPU-Nx-Flag live migriert werden kann. Diese Einstellung ist auf der Basis einzelner virtueller Maschinen zu treffen und ist im Vergleich zum neuen Feature EVC (Enhanced VMotion Compatibility) eher
774
Eigenschaften einer virtuellen Maschine – Optionen
die angestaubte Variante. EVC wird auf Basis des Clusters aktiviert, erstellt die CPU-Gleichheit direkt auf den ESX-Servern und stellt so die CPU-Kompatibilität für VMotion-Operationen sicher. Weitere Informationen zu EVC finden Sie in Kapitel 4, »Cluster«.
Abbildung 13.10
CPU-Kompatibilitätseinstellungen
13.3.10 Erweiterte Konfiguration: Memory/CPU Hotplug Das Hinzufügen von weiteren CPUs oder Memory einer eingeschalteten virtuellen Maschine steuern Sie pro VM. Schauen Sie vor der Verwendung dieser Möglichkeiten in der VMware-Dokumentation GuestOS_guide.pdf nach, ob das eingesetzte Gastbetriebssystem dies unterstützt!
Abbildung 13.11
Einstellungen der HotAdd- und HotPlug-Features
775
13.3
13
Virtuelle Maschinen
13.3.11
Erweiterte Konfiguration: Boot Options
Das seit ESX Server 3.5 neu eingeführte Feature Boot Options hat bereits viele Administratoren erfreut, da sie jetzt endlich eine Möglichkeit haben, das Startverhalten der VM zu beeinflussen, um z. B. die Bootreihenfolge zu ändern oder direkt in das BIOS der VM zu gelangen. Die erste Einstellung, Power-On Boot Delay, verzögert den Start der VM nach Klick auf den Power on-Button. Damit bleibt Ihnen ausreichend Zeit, um in die VMware Console zu wechseln und dort via (Esc), (F2) oder (F12) mit dem BIOS der VM zu interagieren. Bitte beachten Sie, dass die Zeit hier in Millisekunden angegeben wird, und daher sind Werte ab 2 000 sinnvoll. Die Bootoption Force BIOS Setup startet beim nächsten Einschalten einer VM sofort das BIOS-Setup. Diese Einstellung gilt nur einmalig für den nächsten Startvorgang. Die Bootoptionen stellen Sie in den Eigenschaften der VM im Reiter Options in der Rubrik Advanced 폷 Boot Options ein.
13.3.12
Erweiterte Konfiguration: Paravirtualization
Diese Einstellung greift in der VM nur für verschiedene Linux-Betriebssysteme (in der Regel ab der Kernel-Version 2.6.21), die die VMI-Paravirtualisierung unterstützen, und bringt eine Performance-Steigerung. Die Paravirtualisierung ermöglicht das Zugreifen auf Host-Ressourcen über eine von der Virtualisierungsschicht bereitgestellte Programmierschnittstelle. Dazu ist eine Anpassung des Betriebssystems notwendig. Bei der Aktivierung dieser Option müssen Sie bedenken, dass die Migrationsfähigkeit einer VM eingeschränkt wird. Da ESX erst ab der Version 3.5 (inklusive ESX 3i) dieses Feature unterstützt, wird die Live-Migrationen einer paravirtualisierten VM nur bei ESX-Hosts ab der Version 3.5 unterstützt. Im ausgeschalteten Zustand kann eine VM auch auf ältere ESX-Versionen verschoben werden, jedoch müssen Sie hierbei mit einem Performance-Verlust rechnen. Sie aktivieren das Feature in den Eigenschaften einer VM im Reiter Options in der Rubrik Advanced 폷 Paravirtualization.
13.3.13
Erweiterte Konfiguration: Fibre Channel NPIV
Ab ESX Server 3.5 wird die direkte Verwendung von FC-HBAs durch virtuelle Maschinen, welche NPIV (N-Port-ID-Virtualisierung) beherrschen, unterstützt. Dabei greift eine VM mit einem eindeutigen WWN (World Wide Name) direkt auf die Hardware zu.
776
Eigenschaften einer virtuellen Maschine – Optionen
NPIV ermöglicht die Zuweisung mehrerer WWNs auf einen Fibre-Channel-HBA. Wie der Name bereits vermuten lässt, teilen sich hierbei mehrere N_PORTs einen physischen N_PORT. Die Fibre-Channel-Switches sowie die im ESX-Server verwendeten FC-HBAs müssen diese Technik unterstützen. Beim Einschalten der betreffenden virtuellen Maschine erstellt der ESX-Server einen virtuellen Port (VPORT) auf dem FC-HBA, der dann für den Datenaustausch zwischen der virtuellen Maschine und der RDM dient. Bei der Erstellung der LUNs, die von diesen virtuellen Maschinen verwendet werden, ist zu beachten, dass die LUNs mit den WWNs der virtuellen Maschine sowie denen der ESX-Server maskieren müssen. Die neuen WWNs erstellen Sie bei ausgeschalter VM in ihren Eigenschaften im Reiter Options im Abschnitt Fibre Channel NPIV. Deaktivieren Sie dort die Checkbox Temporarily Disable NPIV for this virtual machine 1, und generieren Sie die WWNs durch Klick auf Generate new WWNs 2.
Abbildung 13.12
Aktivierung der NPIV einer virtuellen Maschine
777
13.3
13
Virtuelle Maschinen
Abbildung 13.13
13.3.14
Einstellungen zur Fibre-Channel-N-Port-ID-Virtualisierung
Erweiterte Konfiguration: CPU/MMU Virtualization
Vor der Einführung von hardwarebasierter Virtualisierungsunterstützung in den CPUs erreichte der Virtual Machine Monitor (VMM) eines ESX-Servers die CPUVirtualisierung nur mit Hilfe von Software. Dabei wurde die Binary Translation (BT) zur Virtualisierung des Instruction-Sets einer CPU verwendet, und Shadow Page Tables dienten zur Virtualisierung der Memory Management Units. Die erste hardwarebasierte Unterstützung seitens der Hersteller kam mit Intel VT-x und AMD-V. Der nächste Schritt wurde durch Intel EPT und AMD RVI eingeläutet, um die hardwarebasierte MMU-Virtualisierung zu ermöglichen. Mit dieser Einstellung steuern Sie auf Ebene von einzelnen VMs die von der Hardware angebotene CPU-Virtualisierungsunterstützung. Folgende Optionen stehen hierbei zu Verfügung: 왘
Automatic Dieser Modus erkennt, welche Features die CPU-Hardware konkret unterstützt, und aktiviert die Verwendung der Hardwareunterstützung für die Virtualisierung des Instruction-Sets oder der Memory Management Units.
왘
Use software for instruction set and MMU virtualization Der VMM verwendet zur CPU-Virtualisierung für diese virtuelle Maschine nur die native softwarebasierte Virtualisierung.
778
Eigenschaften einer virtuellen Maschine – Optionen
왘
Use Intel® VT-x/AMD-V™ for instruction set virtualization and software for MMU virtualization Der VMM verwendet nur die von Intel VT-x oder AMD-V angebotene Unterstützung zur Virtualisierung des Instruction-Sets. Die MMUs werden weiterhin durch VMwares Software virtualisiert.
왘
Use Intel® VT-x/AMD-V™ for instruction set virtualization and Intel® EPT/AMD RVI for MMU virtualization Der VMM verwendet nur die von Intel VT-x oder AMD-V angebotene Unterstützung zur Virtualisierung des Instruction-Sets und die Intel-EPT/AMD-RVIUnterstützung der MMU-Virtualisierung.
Die Konfiguration nehmen Sie in den Eigenschaften der VM im Reiter Options unter Advanced 폷 Virtualized MMU vor.
Abbildung 13.14
13.3.15
Einstellungen zur CPU-/MMU-Virtualisierung
Erweiterte Konfiguration: Swapfile Location
Der Ablageort des Swapfiles einer VM lässt sich ab der ESX-Server-Version 3.5 ändern. Entweder legen Sie Swapfiles wie bisher mit den VM-Dateien gemeinsam ab, oder Sie verwenden dafür einen eigenen Swapfile-Datastore. Die grundlegende Einstellung legen Sie auf ESX-Ebene fest, bei Verwendung von Clustern (HA oder DRS) wird diese Einstellung auf Ebene des Clusters definiert und an die ESX-Server vererbt. Hierbei sollten Sie beachten, dass ein anderer Ablageort als der empfohlene (gemeinsam mit den anderen VM-Dateien) gegebenenfalls die
779
13.3
13
Virtuelle Maschinen
Performance von VMotion-Operationen beeinflusst, da die lokale Swap-Datei mit übertragen werden muss. Sie können die Einstellung pro VM überschreiben. Ihnen stehen folgende Optionen zur Verfügung: 왘
Default Es wird die vom ESX-Host oder Cluster vererbte Einstellung verwendet.
왘
Always store with the virtual machine Wenn Sie auf ESX- oder Cluster-Ebene die Ablage der Swapfiles in einem eigenen Datastore definiert haben, überschreibt diese Einstellung den Ablageort für diese VM. Es wird für diese VM der gleiche Ablageort wie für die VMDateien verwendet.
왘
Store in the host’s swapfile datastore Wenn Sie auf ESX- oder Cluster-Ebene standardmäßig den gleichen Ablageort wie für die VM-Dateien definiert haben, überschreibt diese Einstellung den Ablageort für diese VM. Es wird für diese VM der auf ESX- oder Cluster-Ebene definierte Swapfile-Datastore verwendet.
13.4
Ressourcenmanagement einer VM
Unter dem Ressourcenmanagement einer VM versteht man die erweiterten Einstellungen zum Performance-Verhalten wie Reservierung, Limitierung und priorisierte Zuweisung von Ressourcen einer VM von den virtuellen Hardwarebausteinen CPU, Memory und Disk sowie die Möglichkeit zur Zuweisung einer dedizierten physischen CPU. Diese Einstellungen nehmen Sie in den Eigenschaften einer VM im Reiter Resources vor. Die Hintergründe von CPU- und Memory-Management sind detailliert in Kapitel 2, »vSphere-Architektur«, beschrieben.
13.4.1 CPU-Ressourcen Die Einstellungen zu CPU-Shares, dem CPU-Limit und einer CPU-Reservation konfigurieren Sie in den Eigenschaften einer virtuellen Maschine im Reiter Resources im Abschnitt CPU. Die CPU-Affinity sowie die Hyperthreading-Einstellung legen Sie im Abschnitt Advanced CPU fest. Empfehlungen zum Umgang mit diesen Einstellungen finden Sie in Kapitel 2, »vSphere-Architektur«.
780
Ressourcenmanagement einer VM
Abbildung 13.15
Einstellung der CPU-Ressourcen
CPU-Shares Die einer VM zugewiesenen CPU-Shares definieren, mit welcher Priorität einer virtuellen Maschine freie CPU-Rechenkapazität zugewiesen wird; mit den CPUShares legen Sie die Wichtigkeit einer VM beim Zugriff auf die Ressource CPU fest. Da alle virtuellen Maschinen anteilige Ressourcen der physischen CPUs des ESX-Servers erhalten, weisen die Memory-Shares eine relative Priorität zwischen den VMs zu. Die Shares werden in der Regel in drei Stufen justiert: High, Medium und Low. Dabei entspricht High dem Wert 2000, Medium dem Wert 1000 und Low dem Wert 500. Zusätzlich zu diesen Einstellungen können Sie den Wert direkt unter Custom bestimmen. Die drei Werte High, Medium und Low legen eine Ratio von 4:2:1 fest. CPU-Limit Einer VM können Sie ein Limit für die CPU-Auslastung in MHz zuweisen. Per Default ist diese Einstellung unlimited, was besagt, dass eine VM sich bei Bedarf so viel CPU-Ressource anfordern kann, wie sie benötigt, und natürlich die zugewiesene physische CPU zu leisten vermag. Hinweis Das Limit kann nie tiefer sein als der Wert der CPU-Reservation.
781
13.4
13
Virtuelle Maschinen
CPU-Reservation Die Reservierung von CPU-Ressourcen einer VM legt eine garantierte Menge von CPU-Rechenleitung in MHz fest. Diese Mindestmenge muss beim Starten der VM auf einem ESX-Server zur Verfügung stehen und wird durch die Admission Control überprüft. Sollte die CPU eine nicht ausreichende Menge von MHz zur Verfügung haben, so zeigt die Admission Control eine Fehlermeldung an. Der Standardwert der CPU-Reservation ist 0 und kann nie höher sein als der Wert des CPU-Limits einer VM. Die Reservierung einer CPU-Reservierung für eine VM müssen Sie mit Bedacht wählen, denn dies limitiert automatisch die verfügbaren CPU-Gesamtressourcen eines ESX-Servers. CPU-Affinity Eine weitere Konfigurationsmöglichkeit einer VM im Bereich der CPU ist die direkte Zuweisung der virtuellen CPU auf eine physische CPU, die Definition der CPU-Affinity. Diese Technik sollten Sie nur in Ausnahmefällen verwenden, da sie etliche Auswirkungen auf andere Bereiche hat: Zum einen setzt sie die CPU-Lastverteilung des ESX-Servers außer Kraft, zum anderen kollidiert diese CPU-Zuordnung mit eventuell vorgenommenen Einstellungen von CPU-Shares und einer CPU-Reservation, da durch das Umgehen der CPU-Lastverteilung den Forderungen seitens der VM eventuell nicht mehr nachzukommen ist. Die CPU Admission Control kann mit der CPU-Affinity nicht korrekt umgehen, und als Folge davon sind die Überprüfungen, die die Admission Control durchführt, um die Ressource CPU zuzusichern, nicht mehr korrekt. Auch kann das Verschieben der VM auf einen anderen ESX-Host Probleme mit sich bringen, da nicht sichergestellt ist, dass der andere ESX-Server die identische Ressource CPU zur Verfügung stellt; hierbei würde dann die CPU-Affinity ignoriert. Diese Konfigurationsmöglichkeit finden Sie im Reiter Resources unter Advanced CPU. Hyperthreading Der ESX-Server verteilt die Last zwischen den Cores, um eine ausgewogene Auslastung zu erreichen. Wenn für eine logische CPU keine Last gefordert wird, wird diese in einen speziellen Ruhezustand (halt state) geschaltet. Dabei profitiert eine VM auf dem Core von der zusätzlichen Performance dieser CPU. Um virtuelle Maschinen mit für Hyperthreading problematischen Anwendungen ohne das Feature zu betreiben, existieren in der erweiterten Konfiguration von virtuellen Maschinen folgende Einstellungen:
782
Ressourcenmanagement einer VM
왘
Any Any ist die Standardeinstellung und ermöglicht das Teilen der logischen CPUs eines Cores mit entweder einer weiteren virtuellen CPU der identischen VM oder einer virtuellen CPU einer weiteren VM. Diese Einstellung bietet, sofern die Anwendungen dafür ausgelegt sind, die optimale Performance.
왘
None None schaltet das Hyperthreading für die gewählte virtuelle Maschine aus. Eine virtuelle CPU wird einer logischen CPU eines Cores zugeordnet, die zweite logische CPU wird in den halted state geschaltet. Da diese Einstellung eine virtuelle CPU vom restlichen System isoliert, wird diese Konfiguration für hyperthreading-problematische Applikationen verwendet und sollte nur nach Aufforderung seitens VMware-Support oder Herstellersupport der Anwendung implementiert werden.
왘
Internal Internal beschränkt die Nutzung der zwei logischen CPUs auf eine VM und gilt daher nur für VMs mit aktiviertem Virtual SMP (Symmetric Multi-Processing). Eine VM teilt sich den Core nicht mit anderen VMs, sondern der Core wird nur die virtuellen CPUs einer VM verwendet. Wurde diese Einstellung für eine Uniprocessor-VM ausgewählt, schaltet ESX diese Einstellung automatisch auf None.
Diese Einstellung hat keinen Einfluss auf die Verteilung und Priorisierung von CPU-Ressourcen an die virtuelle Maschine. Diese Konfigurationsmöglichkeit finden Sie im Reiter Resources unter Advanced CPU.
13.4.2 Memory-Ressourcen Die Einstellungen zu Memory-Shares, dem Memory-Limit und einer MemoryReservation konfigurieren Sie in den Eigenschaften einer virtuellen Maschine im Reiter Resources im Abschnitt Memory. Empfehlungen zum Umgang mit diesen Einstellungen finden Sie in Kapitel 2, »vSphere-Architektur«. Memory-Shares Die einer VM zugewiesenen Memory-Shares definieren, mit welcher Priorität einer virtuellen Maschine freie Speicherbereiche zugewiesen werden: MemoryShares legen also die Wichtigkeit einer VM beim Zugriff auf den Speicher fest. Da alle virtuellen Maschinen aus dem gemeinsamen Bereich, dem Virtual-Machine-
783
13.4
13
Virtuelle Maschinen
Memory, den Speicher erhalten, legen die Memory-Shares eine relative Priorität zwischen den VMs fest. Die Memory-Shares werden in der Regel in drei Stufen eingeteilt: High, Medium und Low. Dabei entspricht High dem Wert 2000, Medium dem Wert 1000 und Low dem Wert 500. Zusätzlich zu diesen Einstellungen können Sie den Wert direkt unter Custom bestimmen. Die drei Werte High, Medium und Low legen eine Ratio von 4:2:1 fest. Memory-Limit Einer VM können Sie ein Limit für die Speichernutzung zuweisen. Per Default ist diese Einstellung unlimited, was bewirkt, dass eine VM die RAM-Menge erhält, die in ihrer Ressourcenkonfiguration definiert ist, allerdings immer in Abhängigkeit vom aktuellen Overcommitment-Status des ESX-Servers. Dies bedeutet, dass nur ein ESX-Server, der nicht overcommitted ist, einer VM von Beginn an den maximalen Speicher zuordnet. Memory-Reservation Die Speicherreservierung einer VM legt eine garantierte Speichermenge fest, die einer VM beim Starten zugewiesen wird. Diese Mindestmenge muss beim Starten der VM auf einem ESX-Server zur Verfügung stehen und wird durch die Admission Control überprüft. Sollten nicht ausreichend Speicher zur Verfügung stehen, so zeigt die Admission Control eine Fehlermeldung an. Der Standardwert der Memory-Reservation ist 0 und kann nie höher sein als das dieser VM zugewiesene RAM. Speicher für eine VM müssen Sie mit Bedacht reservieren, denn dies limitiert automatisch den verfügbaren Speicherbereich auf einem ESX-Server. Um virtuelle Maschinen hoch performant zu gestalten, können Sie u. a. die Reservierung von Memory auf 100 % setzen. Dies ist aber mit Vorsicht einzusetzen, da die Memory-Reservierung von mehreren virtuellen Maschinen die Funktionalität von VMware HA blockiert, indem die Current Failover Capacity im Summary der HA-Cluster-Eigenschaften auf Null gesetzt wird. Folgende Beispielberechnung soll die Hintergründe dazu erläutern: 왘
In einer Umgebung stehen drei ESX-Server, die mit jeweils 16 GByte RAM ausgestattet sind.
왘
Alle drei ESX-Server wurden zu einem HA-Cluster konfiguriert.
왘
Auf diesen ESX-Servern sind 30 virtuelle Maschinen im Einsatz. Die konfigurierte Speichergröße dabei ist wie folgt:
784
Ressourcenmanagement einer VM
왘
1 VM mit 4 GByte
왘
4 VMs mit je 2 GByte
왘
15 VMs mit je 1 GByte
왘
10 VMs mit je 512 MByte
왘
Keine der virtuellen Maschine wurde mit einer Memory-Reservierung versehen.
왘
Die Cluster Failover Capacity ist jetzt mit einer 1 angegeben.
Die pro ESX-Server maximal adressierbare Speichergröße beträgt ca. 30 GByte. Diese Erhöhung fußt auf der Einbeziehung von swap-basiertem Speicher. Ändern Sie jetzt die Konfiguration der größten virtuellen Maschine mit 4 GByte auf eine Memory-Reservierung von 100 %, wird die Failover-Kapazität mit 0 neu berechnet. Eine Failover-Kapazität von 0 ist aber mit dem Ausschalten des HAClusters gleichzusetzen, da die HA-Agenten keine verfügbaren Ressourcen im Cluster-Verbund mehr sehen. Folgende Berechnung soll aufzeigen, dass trotz der Memory-Reservierung besagter VM und der Angabe einer Failover-Kapazität von 0 genügend Ressourcen zur Verfügung stehen: 왘
physischer Speicher aller drei ESX-Server: 3 × 16 = 48 GByte
왘
swap-basierter Speicher aller drei ESX-Server: 3 × 16 = 48 GByte
왘
maximal möglicher Verbrauch aller virtuellen Maschinen = 32 GByte
왘
durchschnittlicher realer Verbrauch aller virtuellen Maschinen (da eine VM im Durchschnitt nur 20–50 % von dem ihr maximal zur Verfügung stehenden Speicher nutzt) = 12 GByte
Somit hätte der HA-Cluster trotzdem noch ausreichend Ressourcen zur Verfügung, um den Ausfall eines ESX-Servers zu verkraften. VMware verwendet zur Slot-Berechnung die virtuelle Maschine mit der am stärksten konfigurierten Speicher-Ausstattung, und dieser Slot wird mit der Anzahl der virtuellen Maschinen multipliziert. Dadurch entsteht der Berechnungs- und Anzeigefehler in den Summaries von HA. Weitere Hintergrundinformationen über VMware HA und die Slot-Berechnung finden Sie in Kapitel 4, »Cluster«. NUMA Memory Affinity Ebenfalls im Reiter Resources finden Sie im Abschnitt Advanced Memory die Möglichkeit, festzulegen, wie auf ESX-Servern mit NUMA-Speicherarchitektur
785
13.4
13
Virtuelle Maschinen
der virtuelle Speicherbereich einer virtuellen Maschine im physischen Speicher des ESX-Servers abgelegt werden soll. Diese Einstellung ist nicht für VMs verfügbar, die auf DRS-Clustern abgelegt sind. Nach dem Verschieben einer virtuellen Maschine auf einen anderen ESX-Server werden diese Einstellungen gelöscht. Hinweis Wenn Sie alle Nodes selektieren, entspricht diese Einstellung wieder der Einstellung No Affinity!
NUMA (Non-Uniform Memory Access) ist eine Hardwareoptimierung des Speicherzugriffs. Durch den Einbau von immer mehr CPUs in die Server-Systeme stellte sich der Speicher bzw. der Speicherzugriff als Flaschenhals heraus, da die CPUs über den Systembus mit dem Speicher kommunizieren müssen. NUMA verbindet nun mehrere kleinere Einheiten (Knoten, Nodes) von CPU und Speicher über eine Hochgeschwindigkeitsverbindung. Jetzt kann eine SPU auch Speicher aus einem anderen Knoten ansprechen, was zu Geschwindigkeitseinbußen führt, da die Daten zuerst über die NUMA-Verbindung übertragen werden müssen. Der ESX-Server stellt durch seinen NUMA-Scheduler sicher, dass entweder die CPU-Lastverteilung und die Speicher-Ablage dynamisch optimiert werden oder nur die CPU-Last optimal auf den Numa-Knoten verteilt wird. Dazu wird jeder virtuellen Maschine auf einem NUMA-fähigen System ein sogenannter HomeNode zugewiesen, und bei der Speicherzuteilung wird der Speicher dann bevorzugt aus dem Home-Node zugewiesen. Ändert sich die System-Auslastung, so kann der NUMA-Scheduler den Home-Node der virtuellen Maschine auf einen anderen NUMA-Knoten ändern. Dabei wird auch der von der VM genutzte Speicher auf den Speicher im neuen Home-Node verschoben. Unter bestimmten Umständen können virtuelle Maschinen nicht vom NUMAScheduler des ESX-Servers verwaltet werden und somit auch nicht von der Optimierung durch NUMA profitieren. Dies ist etwa der Fall, wenn die virtuelle Maschine mehr virtuelle CPUs als physische CPUs in einem NUMA-Knoten hat oder wenn für eine virtuelle Maschine die CPU-Affinity manuell gesetzt wurde. In bestimmten Fällen ist es sinnvoll, den NUMA-Scheduler manuell zu beeinflussen, indem Sie entweder einer virtuellen Maschine eine CPU (CPU-Affinity) oder einen bestimmten Speicherbereich zuweisen (NUMA Memory Affinity). Dies gilt z. B. für VMs mit einer sehr speicherintensiven Anwendung. NUMA-Informationen über Ihr System finden Sie im Bereich Memory des esxtop-Tools.
786
Starten, Stoppen und weitere Power-Aktivitäten
Abbildung 13.16
Konfiguration der NUMA Memory Affinity
13.4.3 Disk-Ressourcen Die Disk-Shares konfigurieren Sie in den Eigenschaften einer virtuellen Maschine im Reiter Resources im Abschnitt Disk. Die einer VM zugewiesenen Disk-Shares definieren, mit welcher Priorität eine virtuelle Maschine I/O-Zugriff auf die Festplatten-Subsysteme erhält. Sie legen die Wichtigkeit einer VM beim Festplattenzugriff fest, oder anders ausgedrückt, es wird zwischen den VMs eine relative Priorität bestimmt. Die Disk-Shares werden in der Regel in drei Stufen justiert: High, Medium und Low. Dabei entspricht High dem Wert 2000, Medium dem Wert 1000 und Low dem Wert 500. Zusätzlich zu diesen Einstellungen können Sie den Wert direkt unter Custom festlegen. Die drei Werte High, Medium und Low legen eine Ratio von 4:2:1 fest. Die Zuweisung von Disk-Ressourcen-Shares erfolgt allerdings in Produktionsumgebungen recht selten.
13.5
Starten, Stoppen und weitere Power-Aktivitäten
Eine virtuelle Maschine kann in einem der folgenden Power-Zustände sein: 왘
eingeschaltet
왘
ausgeschaltet
왘
suspended Die virtuelle Maschine wurde eingefroren und der Speicherinhalt in eine Datei aus dem File-System geschrieben. Der Befehl »Resume« befreit eine VM aus diesem Zustand und bringt sie wieder zurück in den normalen Betriebsmodus.
787
13.5
13
Virtuelle Maschinen
Je nach aktuellem Zustand einer VM können Sie verschiedene Power-Aktivitäten durchführen: 왘
Power on Schaltet die virtuelle Maschine ein. Optional führen Sie nach der Installation der VMware Tools im Gastbetriebssystem ein Skript nach dem Einschalten der VM aus.
왘
Power off Schaltet die virtuelle Maschine aus. Optional führen Sie nach der Installation der VMware Tools im Gastbetriebssystem ein Skript vor dem Ausschalten der VM aus.
왘
Suspend Hält eine VM an. Optional führen Sie nach der Installation der VMware Tools im Gastbetriebssystem ein Skript vor dem Suspendieren der VM aus. Der eingefrorene Zustand der virtuellen Maschine wird in einer Datei mit der Endung .vmss gespeichert und wird für das Reaktivieren wieder benötigt.
왘
Resume Das Reaktivieren einer suspendierten (angehaltenen) VM mit dem Power onButton oder dem gleichnamigen Befehl. Optional führen Sie nach der Installation der VMware Tools im Gastbetriebssystem ein Skript nach dem Reaktivieren der VM aus.
왘
Reset Vereint die zwei Power-Aktivitäten »Power off« und »Power on« in einem Schritt. Nach der Installation der VMware Tools im Gastbetriebssystem und entsprechender Umkonfiguration einer VM in den Optionen können Sie das Gastbetriebssystem geregelt herunterfahren und neu starten.
Nach der Installation der VMware Tools im Gastbetriebssystem stehen weitere Power-Aktivitäten zur Verfügung. In den Optionen einer VM lässt sich das Verhalten bei »Power on«, »Power off« und »Restart« umkonfigurieren, so dass nachfolgende Power-Aktivitäten wahlweise zur Verfügung stehen: 왘
Shut down guest Bei einem »Power off« wird anstelle des direkten Ausschaltens einer VM das Betriebssystem zuerst geregelt heruntergefahren und dann die VM ausgeschaltet.
왘
Restart guest Bei einem »Reset« wird anstelle des direkten Ein- und Ausschaltens einer VM das Betriebssystem zuerst geregelt heruntergefahren und dann die VM neu gestartet.
788
Installation des Gastbetriebssystems
13.6
Installation des Gastbetriebssystems
Die Installation des Gastbetriebssystems erfolgt so, wie Sie es bislang gewohnt sind. Entweder haben Sie hierfür eine CD/DVD oder ein ISO-Image. Beides können Sie in der Remote Console einer virtuellen Maschine mit dem CD-/DVDLaufwerk verbinden und im BIOS der VM konfigurieren, dass die virtuelle Hardware vom CD-/DVD-Laufwerk booten soll. Konfigurieren Sie im ersten Schritt Ihre VM so, dass sie beim Starten ein verbundenes CD-ROM-/DVD-Laufwerk hat und dieses auch ein Installationsmedium enthält, beispielsweise ein verbundenes ISO-Image eines VMware-Datastores.
Abbildung 13.17
Ihre VM startet mit verbundenem ISO-Image.
Danach können Sie Ihre VM anweisen, direkt in das BIOS zu booten, um dort die Bootreihenfolge umzustellen (Abbildung 13.18). Alternativ drücken Sie während des Startvorgangs innerhalb der VM die (Esc)Taste, um das Boot-Device auszuwählen (Abbildung 13.19). Beim nächsten Starten der VM wird vom angehängten ISO-Image gebootet. Sie sehen im Screenshot, dass das ISO-Image verbunden ist, da Sie jetzt die Verbindung lösen könnten (Abbildung 13.20). Der Setup-Vorgang des Betriebssystems wird gestartet.
789
13.6
13
Virtuelle Maschinen
Abbildung 13.18
Drücken Sie die ESC-Taste, um zum Boot Menu der VM zu gelangen.
Abbildung 13.19 Legen Sie im Boot Menu fest, von wo die VM starten soll. Zum Starten via CDROM/DVD wählen Sie hier Nummer 3.
Abbildung 13.20
790
Das Windows Setup wurde gestartet.
Konfiguration und Anpassung von virtuellen Maschinen
Ebenso funktioniert der netzwerkbasierte Installationsvorgang über ein Netzwerk-Boot mittels PXE, z. B. für Windows-Betriebssysteme über Windows Remote Installation Services (RIS) oder Windows Deployment Services (WDS). Die Netzwerkkarte versucht, eine DHCP-Adresse zu erhalten, um einen Installations-Service zu finden (Abbildung 13.21).
Abbildung 13.21
Netzwerk-Boot der VM
13.7
Konfiguration und Anpassung von virtuellen Maschinen
13.7.1
Ändern der Hardware
Sie können nach der Erstellung einer virtuellen Maschine deren Hardwareausstattung erweitern. Dabei müssen Sie immer die maximal erlaubte Ausstattung einer VM beachten. Zur Auswahl stehen je nach Hardwareversion der virtuellen Maschine folgende virtuelle Geräte: 왘
serieller Port
왘
paralleler Port
왘
Diskettenlaufwerk
왘
DVD-/CD-ROM Laufwerk
왘
USB-Controller
왘
Netzwerkkarte (Ethernet)
왘
Festplatte
왘
SCSI-Gerät
Des Weiteren können Sie die Anzahl der CPUs erhöhen (sofern die notwendige vSMP-Lizenz zur Verfügung steht) und die Größe des RAM-Speichers ändern.
791
13.7
13
Virtuelle Maschinen
Nur in der vSphere-Edition Enterprise Plus können Sie acht vCPUs vergeben, in allen anderen Editionen maximal vier!
13.7.2 Hinzufügen weiterer Hardware im laufenden Betrieb (HotAdd) Das Hinzufügen von Speicher und CPUs steht nur für die Hardwareversion 7 von virtuellen Maschinen zur Verfügung, unter der Voraussetzung, dass das Gastbetriebssystem dies ebenso unterstützt. Außerdem unterscheiden sich die verfügbaren vSphere-Editionen – HotAdd wird nur in folgenden Editionen angeboten: Advanced, Enterprise und Enterprise Plus. Das Feature müssen Sie auf der Basis der virtuellen Maschine aktivieren. Dabei stehen diese Schalter nur dann zur Verfügung, wenn Sie in den Eigenschaften einer virtuellen Maschine auch ein Gastbetriebssystem ausgewählt haben, das HotAdd unterstützt. Das grundsätzliche Aktivieren von HotAdd muss allerdings im ausgeschalteten Zustand der VM erfolgen. Nach dieser Vorbereitung können Sie der laufenden VM weitere CPUs oder mehr Speicher zuweisen. Die nächste Hürde ist das Gastbetriebssystem – entweder es erkennt die neue Hardware im laufenden Betrieb, oder es benötigt einen Neustart. Hier kommt es ganz auf die HotAdd-Unterstützung im Betriebssystem an. Das Entfernen von Speicher und CPUs im laufenden Betrieb wird nicht unterstützt – hierzu müssen Sie die VM stoppen. Hinweis HotAdd wird nicht in Verbindung mit VMware FT (Fault-Tolerance) unterstützt!
HotAdd von Speicher Das Hinzufügen von mehr Speicher in laufenden Betrieb funktioniert nicht bei einem Windows Server 2003 Standard, sondern erst ab der Enterprise Edition. Dabei ist es unerheblich, ob es sich um 32 oder 64 Bit handelt. Eine Einschränkung bei Windows Server 2008 Standard Edition: Hier ist ein Neustart des Gastes erforderlich, damit das Betriebssystem den Speicher erkennt. Nach dem Hinzufügen von mehr Speicher zu einer VM mit einem Linux-Betriebssystem kommt es in manchen Fällen vor, dass das Gastbetriebssystem den neuen Speicher nicht erkennt. Schauen Sie sich den Speicherstatus an, und setzen Sie ihn dann manuell online.
792
Konfiguration und Anpassung von virtuellen Maschinen
Für Red Hat Enterprise Linux und CentOS verwenden Sie folgende Befehle: 왘
den Speicher finden: grep line /sys/devices/system/memory/*/state
왘
den Speicher online setzen: /sys/devices/system/memory/memory[number]/state
Überprüfen Sie abschließend mit dem Befehl free den jetzt zur Verfügung stehenden Speicher. HotAdd von CPUs Das Hinzufügen von weiteren CPUs funktioniert bei Microsofts Betriebssystemen nur mit Windows Server 2008, unabhängig von der Edition. Damit das Betriebssystem die neue CPU nutzen kann, muss der Gast – außer bei der 64-BitDatacenter-Edition – neu gestartet werden. Das Hinzufügen von weiteren CPUs bei laufenden Linux-Gästen wird ab der Kernel-Version 2.6.14 unterstützt. Eine ausführliche Erklärung hierzu finden Sie unter http://www.kernel.org/doc/Documentation/cpu-hotplug.txt. VMware hat ein Dokument veröffentlicht, das das Hinzufügen von virtuellen CPUs in einem Linux-Gast detailliert beschreibt: http://communities.vmware.com/docs/DOC-10493.
Abbildung 13.22
Aktivierung der HotAdd-Funktionalität pro virtueller Maschine
793
13.7
13
Virtuelle Maschinen
Das Hinzufügen von weiteren Festplatten oder weiteren Netzwerkkarten wird seit ESX 3.5 unterstützt, und die Verwendung im Gast ist auch hier wieder abhängig vom jeweiligen Betriebssystem. Das Erweitern von bereits existierenden Festplatten erweitert nur die Größe der Festplatte. Im Betriebssystem selbst müssen Sie die jeweilige Partition um diesen neuen Bereich vergrößern. Bei Windows können Sie das mit diskpart.exe durchführen, sofern es sich nicht um die Bootpartition handelt. In diesem Fall müssen Sie auf Tools von Drittherstellern zurückgreifen. Bei Linux setzen Sie den Befehl fdisk ein.
13.7.3 Statische MAC-Adresse über GUI Ab der Version 3.5 des ESX-Servers lässt sich die MAC-Adresse einer VM komfortabel manuell und demnach auch statisch setzen. In den Eigenschaften einer VM wählen Sie die Netzwerkkarte aus und klicken dann auf Manual; jetzt können Sie die letzten sechs Stellen der MAC-Adresse frei editieren. Der manuell nutzbare MAC Adressbereich liegt im Bereich von 00:50:56:00:00:00 bis 00:50:56:3F:FF:FF. Diese manuelle Vergabe stellt einen erhöhten Verwaltungsaufwand dar, da Sie sicherstellen müssen, dass die manuell vergebenen MAC-Adressen nicht versehentlich doppelt zugewiesen werden. Sinnvoll ist dieser Einsatz beispielsweise dann, wenn eine Anwendung auf die MAC-Adresse lizenziert wurde. Wird hingegen eine physische Maschine mit solch einer Software in eine virtuelle Maschine überführt, können Sie die MAC-Adresse der physischen Maschine nicht in den Einstellungen einer VM setzen, da hier die Herstellerkennung in der MAC-Adresse bereits vorgegeben ist. Alternativ setzen Sie dann die MACAdresse manuell in der Netzwerkkartenkonfiguration des Gastbetriebssystems.
Abbildung 13.23
794
Optional vergeben Sie manuell eine MAC-Adresse.
Konfiguration und Anpassung von virtuellen Maschinen
13.7.4 Umgang mit Wechselmedien Einer VM können Sie Floppy- oder CD-/DVD-Laufwerke zuweisen und diese entweder mit einem physischen Laufwerk oder mit einem Image verbinden. Das physische Laufwerk kann zum einen ein physisches Laufwerk auf dem ESX-Server sein, zum anderen ein physisches Laufwerk auf dem PC oder dem Windows Server, auf dem die VMware Console des vSphere-Clients läuft. Das Gleiche gilt für das Image: Es kann auf einem Datastore liegen und über den ESX an das Laufwerk der VM verbunden werden oder auf einem Windows-Share und über die VMware Console des vSphere-Clients verbunden werden. Beim Einsatz von VMware VMotion müssen Sie darauf achten, dass die zu verschiebende VM keine aktive Verbindung ihres Floppy- oder CD-/DVD-Laufwerks besitzt, egal ob zu einem physischen Laufwerk des ESX-Servers, einem PC oder einem Image. Sollte eine Verbindung noch bestehen, lässt sich der VMotion-Vorgang ausführen. Kommt VMware DRS zum Einsatz, das das Verteilen von VMs auf weniger ausgelastete ESX-Server automatisch bis semi-automatisch durchführen will, kann ein verbundenes Floppy- oder CD-/DVD-Laufwerk innerhalb der VM diesen Mechanismus lahmlegen. Client-Devices Die Laufwerksverbindungen zu Client-Devices steuern Sie über die VMware Console innerhalb des vSphere-Clients. Dabei wählen Sie zwischen dem physischen Laufwerk des PCs oder Servers, auf dem der vSphere-Client läuft, und einem ISO-Image, das über ein Laufwerk des PCs erreichbar ist:
Abbildung 13.24
Das Verbinden eines CD-/DVD-Laufwerks mit einem ESX-basierten Image
In Abbildung 13.25 sehen Sie das via Image eingebundene CD-Laufwerk mit den Möglichkeiten, die Verbindung zum ISO-Image via VMware Console (Disconnect …) oder via VMware Tools (den Haken entfernen bei IDE 1:0) wieder zu unterbrechen.
795
13.7
13
Virtuelle Maschinen
Abbildung 13.25
13.8
Verbundenes CD-/DVD-Laufwerk wieder entfernen
Optimierung einer virtuellen Maschine
Nachfolgend finden Sie einige generelle Empfehlungen, um virtuelle Maschinen optimal zu betreiben: 왘
Gehen Sie sparsam mit Remote-Konsole-Verbindungen um, denn diese verbrauchen CPU-Zeit, auch wenn keine Interaktion stattfindet.
왘
Seien Sie ebenfalls sparsam virtuellen CPUs, da nicht jedes System alle CPUs auch optimal ausnutzt und vSMP durch seinen Virtualisierungs-Overhead weitere Ressourcen des ESX-Servers verbraucht.
왘
Die zugewiesene RAM-Menge sollte sich nach der wirklich benötigten Menge des Servers und seiner Applikationen richten. Eine sparsame Vergabe von RAM verhindert das Memory-Overcommitment, das selbst zwar mehr RAM zur Verfügung stellt, als ein ESX-Server physisch bietet, aber eben auch weitere CPU-Zeit des ESX-Servers zur Bereitstellung des Speichers benötigt. Je nach Applikationen bringt eine Erhöhung des Speichers einer VM nicht unbedingt mehr Leistung. Auch existieren Anwendungen (SQL Server, Exchange Server) die jeden verfügbaren Speicher allokieren, aber nicht unbedingt dadurch performanter werden.
왘
Zur Optimierung der VM-Performance können Sie CPU-Reservierungen vergeben, um das buchstäbliche Verhungern einer VM zu vermeiden. Ebenso sollten Sie aber auch den Einsatz von CPU-Maximum bedenken, um weniger wichtige Server-Systeme bei der Gier nach CPU-Zeit zu zügeln.
796
Optimierung einer virtuellen Maschine
왘
Ein weiterer wichtiger Aspekt ist die virtuelle Hardware einer VM. Virtuelle Hardware, die von der VM nicht benötigt wird, sollte aus dem System entfernt werden. Dazu gehören CD-/DVD-Laufwerke, Floppy-Laufwerke, nicht benötigte Netzwerkkarten, serielle und parallele Schnittstellen. Auch sollten verbundene ISO-Images der Wechselmedien nicht verbunden sein, wenn sie nicht benötigt werden.
왘
Weitere Optimierung erreichen Sie durch den Einsatz der VMware Tools. Achten Sie darauf, dass Sie möglichst die aktuellste Version verwenden. Ausführliche Informationen über die VMware Tools erhalten Sie in Abschnitt 13.9.
Je nach eingesetztem Gastbetriebssystem gibt es verschiedene Möglichkeiten, das Betriebssystem selbst zu tunen. Dies gilt nicht nur für den Einsatz als virtuelle Maschinen, auch physische Server freuen sich über diese Art von Administratoren-Aufmerksamkeit. Windows 왘
Defragmentierung der Festplatten
왘
Aktivierung des Write-Through-Caches der Festplatte (im Gerätemanager, in den Eigenschaften der Festplatte, auf dem Reiter Policies)
왘
Deaktivierung von nicht benötigten Diensten
왘
Deaktivierung von visuellen Desktop- und Maus-Effekten und Entfernung von Hintergrundbildern
왘
Deaktivierung von Screensavern
Linux 왘
Verwendung eines Kernels ab der Version 2.4
왘
keine Verwendung von X-Windows
왘
nur Installation benötigter Packages
왘
eventuell Optimierung des Kernels
왘
Deaktivierung von nicht benötigten Diensten, Daemons und HintergrundTasks
왘
eventuell Einsatz der VMI-Paravirtualisierung
797
13.8
13
Virtuelle Maschinen
13.9
VMware Tools
Die VMware Tools sind eine Ansammlung von Treibern und Tools speziell für virtuelle Maschinen. Dabei bieten die spezifischen Treiber eine optimale Performance für die VM, und die Tools erleichtern die Verwaltung einer VM. Diese Tools stehen für Windows-Betriebssysteme, Linux, Solaris sowie für NetWare zur Verfügung und sollten idealerweise grundsätzlich installiert werden. Zwar ist das Betriebssystem in der VM auch ohne VMware Tools lauffähig, aber deren Vorteile sind die Motivation, sie zu installieren und auch regelmäßig bei Erscheinen einer neueren Version zu aktualisieren. Die VMware Tools ermöglichen oder bieten: 왘
optimierte Treiber für die virtuelle Hardware
왘
Synchronisierung der Uhr einer VM
왘
Shutdown- oder Restart-Power-State-Operationen (Skripte, die bei diesen Operationen gestartet werden)
왘
Drag & Drop zwischen der VM und dem Betriebssystem, auf dem die VMware Console läuft
왘
automatische Freigabe des Cursors/Fokus beim Verlassen der VM mit der Maus in der VMware Console
왘
erweiterte Speicherverwaltung seitens des ESX-Servers durch den MemoryControl-Driver
왘
absturzkonsistente Snapshots durch den Filesystem Sync Driver
Die Tools werden bei der Installation als ISO-Image im Gastbetriebssystem bereitgestellt, und die Setup-Routine startet automatisch. Das VMware Virtual Center ist zuständig für das Einbinden des ISO-Images innerhalb der VM in das virtuelle CD-/DVD-Laufwerk. Die VMware Tools umfassen: 왘
VMware Tools Service Unter Windows wird der Dienst VMwareService.exe und unter Linux/Solaris der Dämon vmware-gustd installiert. Dieser Service ist die Grundlage für die Zeitsynchronisation zwischen ESX-Server und dem Gastbetriebssystem. Unter Windows ist der Service ebenso für das Mausverhalten in der VMware Console zuständig.
왘
VMware-Gerätetreiber Für das Gastbetriebssystem werden optimierte Treiber für die virtuelle Hardware bereitgestellt, der SVGA-Bildschirmtreiber, der vmxnet-Netzwerkkar-
798
VMware Tools
tentreiber, der BusLogic-SCSI-Treiber und ein Treiber für die Maus. Des Weiteren werden ein Memory-Treiber und ein Synchronisierungstreiber installiert. 왘
VMware Tools Toolbox Die Toolbox dient zum Ändern von Einstellungen, zum Shrinken der virtuellen Disk und zum Verwalten der virtuellen Geräte (Floppy, CD-ROM).
왘
VMware Scripts Verschiedene Skripte die bei Power State-Änderungen der VM im Gastbetriebssystem ausgeführt werden. Die Ausführung wird über die Eigenschaften einer VM gesteuert.
왘
VMware User Prozess Auf Windows-Betriebssystemen wird die VMwareUser.exe installiert und auf Linux und Solaris-Betriebssystemen der vmware-user-Prozess. Dieser Prozess ermöglicht das Kopieren von Texten über Copy & Paste zwischen dem Gast und dem Betriebssystem der VMware Console.
13.9.1 Zeitsynchronisation Die Zeitsynchronisation einer VM ist die einzige Möglichkeit einer VM, die korrekte Zeit zu erhalten, da eine VM über keine CMOS-Uhr verfügt. Natürlich existieren etliche betriebssystemeigene Methoden, um die Uhrzeit abzugleichen, z. B. Windows-Server, die als Mitglieder einer Domäne immer die korrekte Zeit von einem Windows-Zeitgeber erhalten. Auch nach einem Suspend muss die Uhrzeit der VM aktualisiert werden, da sie während des Suspendierens ebenso angehalten wurde. Sollten Sie Microsoft-Domain-Controller virtualisieren, dann empfiehlt sich auf jeden Fall die Verwendung der Windows-eigenen Zeitsynchronisierung und keine Vergabe der Zeit via VMware. Ansonsten ist die Zeitvergabe über die VMware Tools der empfohlene Weg, sofern die ESX-Server mit einer externen Zeit via NTP konfiguriert wurden.
13.9.2 Installation der VMware Tools Die Installation der VMware Tools kann zum einen manuell nach der Installation des Gastbetriebssystems oder auch als unbeaufsichtigte Variante durchgeführt werden. Das vCenter kann die VMware Tools beim Starten der VM überprüfen und gegebenenfalls eigenständig aktualisieren.
799
13.9
13
Virtuelle Maschinen
13.9.3 Manuelle Installation Die manuelle Installation starten Sie über den Befehl Install VMware Tools entweder über das Kontextmenü der VM oder über das Hauptmenü unter Inventory 폷 Virtual Machine gestartet. Dadurch wird an das Laufwerk des Gastbetriebssystems ein ISO-Image angehangen, und das Setup wird gestartet. Nachfolgend beschreiben wir die Installationsvorgänge für Linux, Solaris und Windows. Linux 1. Sollten CDs nicht automatisch gemountet werden, erledigt das dieser Befehl für Sie: mount –t iso 9660 /dev/cdrom /<mountpoint>
2. Auf der CD-ROM gibt es für gängige Distributionen ein RPM-Paket, für alle andere unterstützen Gäste ein TAR-Archiv. 3. Nach der Installation über ein RPM-Paket erfolgt die Konfiguration der Tools und nachfolgend der Start: /usr/bin/vmware-config-tools.pl
4. Der Aufruf der grafischen Toolbox erfolgt über: /usr/bin/vmware-toolbox
5. Alternativ installieren Sie die VMware Tools über das TAR-Archiv: cp /mnt/cdrom/VMwareTools-$Version-$Build.i386.tar.gz /tmp cd /tmp tar –xvfz ./VMwareTools-$Version-$Build.i386.tar.gz ./vmware-tools-distrib/vmware-install.pl
Ein textbasiertes Setup leitet durch die Installation der Treiber. Die Open Linux Tools finden Sie unter http://www.vmware.com/download/ packages.html. Bei der Linux-Distribution Debian benötigen Sie mangels offiziellen VMwareSupports die Debian-Kernel-Quellen sowie die Interpreter und den Compiler zur Anpassung der VMware-Tools-Komponenten. Wird von einer Minimalinstallation ausgegangen, ist die Installation der Komponenten folgendermaßen durchzuführen: 왘
Installation der Programme mit: apt-get install autoconf automake make psmisc gcc
왘
Installation der Quellen des aktuell genutzten Kernels mit: apt-get install linux-headers-`uname -r` build-essential
800
VMware Tools
Danach können Sie die VMware Tools wie gewohnt über die tar.gz-Datei installieren: tar -xzvf VMwareTools-######.tar.gz cd vmware-tools-distrib ./vmware-install.pl vmware-tools-config.pl
Um die korrekte Installation der VMware Tools zu überprüfen, werfen Sie einen Blick in das Summary einer virtuellen Maschine im vSphere-Client. Dort sollte der Status der VMware Tools mit OK angezeigt werden. Solaris Die Installation erfolgt bei Solaris immer über ein TAR-Archiv. mount –t iso9660 /dev/cdrom /mnt/cdrom cp /cdrom/vmwaretools/VMwareTools-solaris.tar.gz /tmp cd /tmp gunzip ./vmwaretools/VMwareTools-solaris.tar.gz tar –xvf VMwareTools-solaris.tar ./vmware-tools-distrib/vmware-install.pl
Hinweis: Ein textbasiertes Setup leitet durch die Installation der Treiber. Windows 1. Nach dem Startbildschirm entscheiden Sie sich für den Installationstyp: Typisch, Vollständig oder Benutzerdefiniert. 2. Wählen Sie unter Benutzerdefiniert die zu installierenden Komponenten (Abbildung 13.26).
Abbildung 13.26
Auswahl der zu installierenden Komponenten
801
13.9
13
Virtuelle Maschinen
3. Installieren Sie die VMware Tools. 4. Schalten Sie die Hardware acceleration ein, indem Sie den Riegel ganz nach rechts schieben (Abbildung 13.27).
Abbildung 13.27
Einschalten der Hardware Acceleration
5. Nach Abschluss der Installation booten Sie die virtuelle Maschine. Um die korrekte Installation der VMware Tools zu überprüfen, werfen Sie einen Blick in das Summary einer virtuellen Maschine im vSphere-Client. Dort sollte der Status der VMware Tools mit OK angezeigt werden.
13.9.4 Aktualisierung der VMware Tools Eine neue Version der VMware Tools gelangt in Form von Patches für ESX-Server auf den ESX-Host, und der vSphere-Client zeigt pro VM den Status der VMware Tools an. Veraltete VMware Tools ab der Version 3.5 werden im Summary einer VM mit einem »out of date« gekennzeichnet. Manuell Die Aktualisierung der VMware Tools auf eine neue Version nehmen Sie analog zur Installation vor. Im ersten Schritt geben Sie an, ob vCenter für Sie den Upgrade-Vorgang automatisiert vornehmen soll oder ob Sie den Wizard manuell füttern möchten, um eine Änderung an den installierten Komponenten vornehmen zu können.
802
VMware Tools
Abbildung 13.28
Upgrade der VMware Tools
Automatisiert durch vCenter Das vCenter unterstützt das automatische Aktualisieren der VMware Tools. Dazu aktivieren Sie in den Eigenschaften einer VM im Reiter Options unter VMware Tools den Befehl Check and upgrade Tools before each power-on (Abbildung 13.29). Bei jedem Einschalten der VM wird jetzt überprüft, ob eine neue Version der VMware Tools zur Verfügung steht, und diese dann automatisch installiert.
Abbildung 13.29
vCenter überprüft und aktualisiert die VMware Tools eigenständig.
803
13.9
13
Virtuelle Maschinen
13.10
Migration von virtuellen Maschinen
13.10.1
Verschiedene Arten der Migration
Die Migration einer VM ist das Verschieben einer virtuellen Maschine von einem ESX-Server auf einen anderen ESX-Server. Dabei wird unterschieden, ob die VM eingeschaltet oder ausgeschaltet bzw. suspendiert ist. Abschließend wird die verschobene VM auf dem Ziel-ESX-Server registriert und kann dort gestartet werden. Das Verschieben einer eingeschalteten VM wird VMotion genannt und setzt zum einen voraus, dass die Dateien der VM (Konfiguration, virtuelle Festplatte etc.) auf einem gemeinsam genutzten Storage-Bereich (via iSCSI, SAN oder NFS) abgelegt sind. Zum anderen müssen Sie die CPU-Kompatibilität der ESX-Server beachten. Bei VMotion wird die VM ohne Unterbrechung im Gastbetriebssystem vom Ursprungs-ESX-Server auf einen anderen ESX-Server live verschoben. Die VMDateien bleiben dabei an ihrem aktuellen Speicherort liegen. Zur Durchführung des VMotion-Vorgangs einer VM muss sichergestellt sein, dass die VM keine Verbindung zu einem CD-ROM oder einem Floppy-Laufwerk des ESX-Hosts besitzt. Bei der Validierung des Ziels wird dies als Fehler angezeigt. Eine Verbindung zu einem Client-Device oder einem ISO-Image stellt kein Hindernis für VMotion dar. Das Verschieben der eingeschalteten VM kann mit unterschiedlichem Prioritätslevel erfolgen, high und low. Die Einstellung high stellt sicher, dass auf dem Ziel-Server ausreichend Ressourcen zur Verfügung stehen und reserviert diese, damit die VM während der Migration verfügbar ist. Hat der ESX-Server nicht ausreichend Ressourcen, wird die Migration nicht durchgeführt. Die Einstellung low reserviert keine Ressourcen auf dem Ziel und führt die Migration auch bei Ressourcenengpässen durch. Dabei kann es vorkommen, dass die VM kurzzeitig nicht zu erreichen ist. Eine ausgeschaltete oder auch suspendierte VM muss nicht zwingend auf einem zentralen Storage liegen und bedingt auch keine CPU-Kompatibilität der ESX-Server. Hierbei lassen sich die VMs auch zwischen Datacentern verschieben. Vor dem endgültigen Verschieben der VM können Sie wählen, ob die Dateien einer VM ebenfalls verschoben werden oder ob sie am bisherigen Speicherplatz liegen bleiben sollen (sofern sie auf einem zentral verfügbaren Speicherbereich abgelegt wurden). Damit der Speicherort der VM-Dateien bei einer Migration nicht verändert wird, muss sich dieser auf einem zentralen Storage befinden, damit der ZielESX-Server die Dateien auch im Zugriff haben kann.
804
Templates und Clones
Das ab der ESX Version 3.5 eingeführte Feature Storage VMotion ermöglicht die Live-Migration einer VM zwischen verschiedenen Datastores. Dabei erfolgt Storage VMotion auf einem ESX-Server; die Dateien einer VM werden von einem Datastore auf einen anderen verschoben, ohne dass der Betrieb einer VM unterbrochen werden muss. Diese Art der Migration ist sinnvoll, um z. B. alle VMs eines Datastores zu verschieben und nachfolgend an diesem Datastore Wartungsarbeiten durchführen zu können. Abschließend können die verschobenen VMs wieder zurück auf den ursprünglichen Datastore verschoben werden. Ein weiterer Verwendungszeck ist die optimale Lastverteilung zwischen verschiedenen Datastores ohne Ausfall der darauf liegenden VMs. Der ESX-Server benötigt für diese Migration ebenfalls eine VMotion-Lizenz und sollte ausreichend Ressourcen für zwei Instanzen der zu verschiebenden VM bereitstellen.
13.10.2
Verwendung des Migration-Wizards zur Migration einer VM
Das Verschieben einer virtuellen Maschine starten Sie über den vSphere-Client mittels des Migration-Wizards gestartet. Diesen rufen Sie vom Menü oder Kontextmenü einer VM über den Befehl Migrate auf. Die Schritte des Wizards variieren je nach Art der Migration und je nach Ziel. Den Migration-Wizard können Sie auch über Drag & Drop starten. Lassen Sie dabei die VM auf einem ESX-Host, einem Cluster oder einem Resource-Pool fallen. Je nach Ziel wird der Schritt Select Destination nicht mehr angezeigt, da die Auswahl schon getroffen wurde, z. B. wenn das Ziel ein ESX-Server ist oder ein Resource-Pool, der einem ESX-Host zugeordnet wurde. Eine detaillierte Beschreibung und Anleitung finden Sie in Kapitel 3, »VMotion und Storage VMotion«.
13.11
Templates und Clones
13.11.1
Was sind Template und welchen Nutzen bringen sie?
Unter Templates versteht man Vorlagen oder Vorlagendateien, die dazu dienen, bei der Erstellung z. B. eines neuen Word-Dokumentes Zeit einzusparen. Das ist jedoch nicht alles: Sie grenzen auch Fehlerquellen ein oder beseitigen sie, indem Sie, um beim Word-Beispiel zu bleiben, sich wiederholende Textpassagen in eine Vorlage speichern und mittels dieser immer wieder neue Dokumente erstellen. Natürlich hat dies auch den entscheidenden Nachteil, dass bei einem Fehler in der Vorlage alle darauf basierenden Dokumente auch von diesem Fehler befallen sind. Aber es gibt nur eine Fehlerquelle, nämlich einzig und allein die Vorlage
805
13.11
13
Virtuelle Maschinen
selbst. Daher sollten Sie auch bei der Anlage des ersten Templates äußerst sorgfältig vorgehen, um spätere Probleme schon im Voraus auszuschließen. Mittlerweile hat man dieses doch sehr nützliche Verfahren nicht nur bei Word oder allgemeinen Dokumenten eingebracht, sondern auch in Form von Images für physische Maschinen, z. B. durch Symantec Ghost. Dort installiert man ein Betriebssystem mit allen benötigten Anwendungen, löscht die individuellen Einstellungen wie die Netzwerkkonfiguration und sichert diese Daten in einem Image. Mit diesem Image werden dann alle weiteren Systeme deutlich schneller und fehlerfreier installiert, als es manuell möglich wäre. Einen großen Nachteil hat dieses Verfahren, zumindest bei physischen Maschinen: Es läuft nur bei identischer Hardwarekonfiguration sicher und fehlerfrei. Virtuelle Maschinen passen durch die immer gleiche virtuelle Hardware allerdings perfekt in den Mechanismus von Templates. Hinzu kommt, dass meistens nur eine Datei (die Festplattendatei des Betriebssystems) benötigt wird und nicht einmal ein Imaging-Tool eingesetzt werden muss, um ein Image herzustellen, denn Sie haben dieses automatisch, sobald die virtuelle Maschine fertig installiert ist. Daher empfiehlt es sich auch, die System- und Datenpartition einer VM zu trennen und als unterschiedliche Festplattendateien anzulegen. Wenn wir diesen Gedanken weiterspinnen, kommen wir sehr schnell darauf, dass nicht nur ein Template, sondern viele verschiedene Templates erstellt und hinterlegt werden können, die verschiedenste Betriebssysteme mit unterschiedlichsten Softwareständen und Service Packs enthalten können. Dadurch lassen sich in kürzester Zeit – bei guter Festplattenleistung in ca. 15 Minuten – neue virtuelle Maschinen auf der Basis eines Templates erstellen. Diesen Vorgang könnten Sie sogar noch automatisieren, um beispielsweise eine Test- oder Entwicklungsumgebung regelmäßig neu aufzusetzen. Aber vor allem das Disaster-Recovery wird durch Templates sehr verbessert, da Sie mehrere Templates für die einzelnen ServicePack-Stände Ihrer virtuellen Maschinen hinterlegen und sie je nach ausgefallenem System entsprechend »zurücksichern« können. So schnell können Sie kein physisches System in seinem Ursprungszustand wiederherstellen.
13.11.2
Templates im vCenter
Unter VMware ist ein Template genau das, was man von ihm erwartet: eine komplette Kopie einer virtuellen Maschine. Dabei ist es Ihnen überlassen, ob Sie nur das reine Gastbetriebssystem inklusive der aktuellen Patches installiert haben oder auch eine Anzahl von Applikationen. Dieses Template verwenden Sie, um schnell und ohne weiteres Wissen über die VM-Spezifikation neue virtuelle Maschinen des gleichen Typs ins Leben zu rufen.
806
Templates und Clones
Die Templates sind ebenso wie die virtuellen Maschinen im vCenter sichtbar und lassen sich auch mit den gleichen Hilfsmitteln gruppieren, indem Sie sie in Foldern zusammenfassen oder auch mit Zugriffsrechten belegen. Um die Templates von den virtuellen Maschinen zu unterscheiden, haben die Template in der Darstellung im Inventory des vSphere-Clients leicht abgeänderte Icons. Eine zusätzliche Kennzeichnung, z. B. mit _Template, schadet sicher nicht, um einen Überblick über die virtuelle Infrastruktur zu behalten.
13.11.3
Templates erstellen, bearbeiten und löschen
Zum Erstellen von Templates können Sie zwischen folgenden Vorgehensweisen wählen: 왘
eine virtuelle Maschine in ein Template konvertieren
왘
eine virtuelle Maschine in ein Template clonen
왘
ein existierendes Template in ein neues Template clonen
Die ersten zwei Möglichkeiten wandeln entweder eine existierende virtuelle Maschine in ein Template um (Convert to Template) oder kopieren eine virtuelle Maschine in ein Template (Clone to Template).
Abbildung 13.30
Zwei Möglichkeiten, aus einer VM ein Template zu erstellen
807
13.11
13
Virtuelle Maschinen
Bei Clone to Template wird eine Kopie der ausgewählten virtuellen Maschine erstellt. Dabei vergeben Sie für das Template einen Namen, wählen einen ZielFolder aus, selektieren den ESX-Host und wählen den Datastore aus. Bei Convert to Template hingegen wandeln Sie eine bestehende virtuelle Maschine in ein Template um.
13.11.4
Virtuelle Maschinen mit Hilfe von Templates erstellen
Das Deployment von virtuellen Maschinen erfolgt in der Regel durch Deploy Virtual Machine from this Template aus dem Kontextmenü eines Templates. Alternativ wandeln Sie ein Template in eine virtuelle Maschine um. Im Deployment-Prozess werden Sie nach dem Namen der neuen virtuellen Maschine gefragt, nach dem Ziel-Host oder -Cluster, gegebenenfalls nach einem Resource-Pool und dem Datastore, auf dem die Dateien abgelegt werden sollen. Der letzte Schritt des Wizards bietet Ihnen wieder die Gelegenheit, den Guest Customization Wizard aufzurufen. (Eine Beschreibung des Guest Customization Wizards finden Sie im folgenden Abschnitt.) Nach diesen Einstellungen geben Sie dem vCenter einen Moment Zeit, um die Dateien des Templates in eine neue virtuelle Maschine zu kopieren und das Betriebssystem zu modifizieren.
Abbildung 13.31
808
Zwei Wege, aus einem Template eine VM zu erstellen
Anpassen der Gastbetriebssysteme
13.11.5
Was sind Clones, und wir erstellt man sie?
Ein Clone ist eine direkte Kopie einer bestimmten virtuellen Maschine mit der Möglichkeit, das Gastbetriebssystem der Kopie am Ende des Vorgangs anzupassen. Sie starten den Vorgang durch Auswahl des Befehls Clone aus dem Kontextmenü einer virtuellen Maschine.
Abbildung 13.32
Eine virtuelle Maschine clonen
Nach dem Start des Clone-Wizards geben Sie für den Clone an, wie er benannt werden soll und in welcher Folder-Struktur er abgelegt werden soll. Zusätzlich wählen Sie den Ziel-ESX-Server, gegebenenfalls einen Resource-Pool und den Datastore aus. Am Ende legen Sie fest, ob das vCenter das Gastbetriebssystem des Clones bearbeiten soll. Nach diesen Einstellungen geben Sie dem vCenter einen Moment Zeit, um die Dateien der virtuellen Maschine zu kopieren und das Betriebssystem zu modifizieren.
13.12
Anpassen der Gastbetriebssysteme
Mit dem Guest Customization Wizard passen Sie die Gastbetriebssysteme Windows 2000, XP, 2003 und Vista oder Linux (RHEL 2-5, SLES 8-10) während des
809
13.12
13
Virtuelle Maschinen
Deployment-Vorgangs an. Dabei können Sie z. B. den Host-Namen oder die Netzwerkkarten-Konfiguration verändern. Speziell für Windows bietet dieser Wizard die Möglichkeit, der neuen VM eine neue SID zu geben. Dieser Computer Security Identifier (SID) kennzeichnet verschiedene Windows-Systeme im Netzwerk und sollte bei Deployment-Prozessen, die auf dem Imaging-Verfahren beruhen, für jede neue Windows-Installation verändert werden. Letzteres war bis November 2009 die gängige Meinung aller Windows-Experten und wurde auch so seit Windows-NT-Zeiten für Image-based Deployment-Prozesse gelebt. Doch der Entwickler des Tools NewSID, Mark Russinovich, erschütterte am 3. November 2009 die IT-Jünger schwer, als er das Tool NewSID als retired kennzeichnete und dabei in seinem Blog dem Mythos der Machine SID Duplication ein Ende bereitete. Möge ein jeder sich selbst darüber informieren: http://blogs.technet.com/markrussinovich/archive/2009/11/03/329 1024.aspx. Den Guest Customization Wizard rufen Sie am Ende von Cloning- oder Deployment-Prozessen auf, siehe Abbildung 13.38. Entweder tragen Sie alle gewünschten Änderungen Schritt für Schritt im Wizard ein, oder Sie wählen aus der Datenbank des Customization Specifications Managers eine Spezifikation aus.
13.12.1
Voraussetzungen
Der Wizard setzt in beiden Fällen (Windows und Linux) voraus, dass die VMware Tools in der virtuellen Maschine installiert sind. Speziell für Windows wird die Installation des Microsoft-Tools sysprep auf dem vCenter und für Linux im Gastbetriebssystem eine Perl-Installation benötigt. Sysprep Für die Anpassung von Windows-Betriebssystemen stellt Microsoft das Tool Sysprep bereit. Microsoft bietet es für die Betriebssysteme Windows XP, Windows Server 2000 – 2003, jeweils 32 und 64 Bit, an. Sie finden die jeweilige Version für Ihr Gastbetriebssystem auf Microsofts TechNet. Das Microsoft-Tool muss mit all seinen Dateien im jeweiligen Unterverzeichnis in %ALLUSERSPROFILE%\ Application Data\VMware\VMware VirtualCenter\sysprep liegen. Für Windows 2008 sowie für Vista wird das Tool nicht auf dem vCenter benötigt, da es bereits im Betriebssystem enthalten ist. Des Weiteren werden die Einstellungen jetzt über eine xml-Datei geregelt, die vom vCenter vor dem Anpassen des Gastbetriebssystems auf den Gast kopiert wird. In der Community häufen sich jedoch die Meldungen, dass die vollständige Anpassung eines Windows 2008-
810
Anpassen der Gastbetriebssysteme
Servers oft fehlschlägt. Ein einfacher Workaround ist, vor dem Umwandeln der Windows Server 2008-VM die Betriebssystemeinstellung auf Vista zu ändern. Nachdem Sie von diesem Template eine VM erstellt haben und die Anpassungen im Betriebssystem fehlerfrei durchgeführt wurden, ändern Sie in der virtuellen Maschine die Angabe des Gastbetriebssystems wieder auf Windows Server 2008. Sollten Sie Probleme mit der Anpassung des Gastbetriebssystems haben, finden Sie detaillierte Informationen in folgenden Log-Dateien: 왘
Windows: %WINDIR%\temp\vmware-imc
왘
Linux: /var/log/vmware/customization.log
13.12.2
Bearbeiten von Anpassungsspezifikationen
Sie starten den Customization Specification Manager im vSphere-Client über View 폷 Management 폷 Customization Specification Manager oder über die Adressleiste:
Abbildung 13.33
Starten des Customization Specification Managers
Dort können Sie jetzt neue Spezifikationen erstellen oder importieren sowie bestehende Spezifikationen duplizieren, bearbeiten, exportieren oder löschen.
811
13.12
13
Virtuelle Maschinen
Das Erstellen oder Bearbeiten einer Spezifikation sieht wie folgt aus: 1. Geben Sie die obligatorischen Registrierungsinformationen an. 2. Wählen Sie, wie der Host-Name der virtuellen Maschine vergeben werden soll: 왘
Sie geben einen festen Namen ein.
왘
Der Name der virtuellen Maschine soll als Host-Name übernommen werden.
왘
Der Name wird durch den Anwender eingegeben.
왘
Der Name kann von einem externen Tool vergeben werden.
Abbildung 13.34
Setzen des Host-Namens
3. Nur in Windows-Systemen geben Sie jetzt den Product-Key ein und hinterlegen die Lizenzinformationen. 4. Ebenfalls nur in Windows-Systemen geben Sie ein Administratorkennwort ein und bestimmen, wie viele automatisierte Anmeldevorgänge nach der Installation durchgeführt werden sollen. 5. Legen Sie die Zeitzone fest. 6. Wiederum nur für Windows-Systeme können Sie Run-once-Skripte angeben. 7. Bei der Netzwerkkartenkonfiguration wählen Sie zwischen der typischen Einstellung, der Verwendung von DHCP für alle Netzwerkkarten und der angepassten Einstellung. Letzteres ermöglicht Ihnen, für die virtuelle Maschine
812
Anpassen der Gastbetriebssysteme
entweder eine feste IP-Adresse im Wizard zu hinterlegen oder dem Anwender die Möglichkeit zu geben, eine IP-Adresse anzugeben.
Abbildung 13.35
Die Custom settings lassen Sie …
Abbildung 13.36
… die IP-Adressen der VM und des DNS-Clients festlegen.
8. Entscheiden Sie für Windows-Systeme, ob sie einer Workgroup oder einer Domäne angehören sollen, und hinterlegen Sie den Account, um diese Aktion durchzuführen.
813
13.12
13
Virtuelle Maschinen
9. Die letzte Einstellung gilt wiederum nur für Windows-Systeme und automatisiert die Vergabe einer neuen SID.
Abbildung 13.37
Soll für das Windows-System eine neue SID erstellt werden?
Der letzte Schritt des Wizards fasst nochmals alle Informationen auf einen Blick zusammen.
13.12.3
Anpassung des Gastbetriebssystems
Die Anpassung eines Gastbetriebssystems wird entweder am Ende eines CloneVorgangs gestartet oder durch das Deployment einer virtuellen Maschine mittels Templates. Dabei bekommen Sie jeweils im letzten Schritt des Wizards die Möglichkeit, den Customization Wizard zu starten.
Abbildung 13.38 Vorgang
814
Möglichkeiten zur Bearbeitung des Gastbetriebssystems nach dem Clone-
Snapshots
Dabei stehen Ihnen zwei Optionen zur Verfügung: Bei Customize using the Customization Wizard legen Sie die Einstellungen für das Betriebssystem in den folgenden Schritten des Wizards fest. Eine vorher erstellte und abgespeicherte Konfiguration wählen Sie bei Customize using an existing customization specification aus. Hierbei können Sie noch angeben, ob Sie gewisse Bereiche der ausgewählten Konfiguration vor dem Anwenden noch abändern möchten.
Abbildung 13.39 Anpassung einer neuen virtuellen Maschine am Ende eines Clone-Vorgangs mittels gespeicherter Spezifikationen
13.13
Snapshots
13.13.1
Funktionsweise
Ein Snapshot erstellt eine Momentaufnahme einer virtuellen Maschine inklusive des Gastbetriebssystems. Dabei werden je nach Art des Snapshots der aktuelle Zustand der virtuellen Festplatte(n), die Eigenschaften der VM sowie der aktuelle Zustand des RAMs eingefroren und im Verzeichnis der VM auf dem Datastore abgelegt. Sie können zu jedem Zeitpunkt wieder zu einem beliebigen Snapshot zurückspringen, womit alle Änderungen und Einstellungen, die in der VM seit Erstellung des Snapshots erfolgten, obsolet sind. Dies ist das ideale Werkzeug, um die Installation neuer Software oder Konfigurationsänderungen zuerst zu testen. Der Zustand einer VM nach einem Snapshot, z. B. nach der erfolgreichen Installation einer neuen Software, kann als fester Zustand wieder persistiert werden. Dabei werden alle Änderungen der VM, d. h. insbesondere der virtuellen
815
13.13
13
Virtuelle Maschinen
Festplatte, in die ursprüngliche Festplatte übertragen, und die Snapshot-Dateien werden gelöscht. Somit enthält die Festplattendatei den zum jetztigen Zeitpunkt gültigen Zustand einer VM. Die Erstellung von mehreren Snapshots der gleichen VM ist möglich. Damit wird jeder Zwischenschritt, z. B. während einer Installation mehrerer Softwarepakete oder Updates, abgelegt und dient als eine Art Recovery-Point. Sie können zu einem beliebigen Snapshot innerhalb der Hierarchie zurückspringen und alle Änderungen, die seit der Erstellung dieses bestimmten Snapshots gemacht wurden, verwerfen. Im Gegensatz dazu kann auch jeder beliebige Zustand persistiert werden. In Summe ist eine Hierarchietiefe von 32 Stufen möglich. Bedenken Sie, dass mit jedem neuen Level die Zeit zum Verwerfen oder zum Persistieren eines Snapshots ansteigt. Bei der Erstellung eines Snapshots wird der in diesem Moment gültige Zustand einer VM eingefroren. Bei primär schreibenden Applikationen, z. B. DatenbankServern, ist zwar während der Erstellung des Snapshots die volle Funktionalität der Anwendung gegeben. Aber beim Zurücksetzen einer VM auf einen Snapshot kann es zu Inkonsistenzen kommen, wenn während der Erstellung schreibende Operationen durchgeführt wurden. Hier empfiehlt es sich, die jeweiligen Dienste oder Anwendungen zu stoppen, bevor Sie einen Snapshot erstellen. Bei Domänen-Controllern wird aber grundsätzlich davon abgeraten, Snapshots anzuwenden, da Sie sonst mit USN-Rollback-Problemen zu kämpfen haben (http://support.microsoft.com/kb/875495)! Die Performance einer VM wird nach der Erstellung eines Snapshots eventuell beeinträchtigt, da alle Änderungen im Gastbetriebssystem respektive in der virtuellen Festplatte in einer weiteren Datei auf dem Datastore gespeichert werden. Kurzübersicht der Snapshot-Manager-Befehle: 왘
Delete Dieser Befehl fügt den ausgewählten Snapshot dem Parent-Snapshot (übergeordneter Snapshot) hinzu und löscht die Snapshot-Datei. Der Inhalt der VMFestplatte bleibt unverändert.
왘
Delete All Dieser Befehl fügt alle Snapshots vor dem »You Are Here«-Status dem ParentSnapshot hinzu und löscht alle Snapshot-Dateien. Der Inhalt der VM-Festplatte bleibt unverändert.
왘
Go To Dieser Befehl setzt den Inhalt der virtuellen Festplatte in den ausgewählten Zustand zurück, das heißt, der Inhalt der VM-Festplatte wird auf einen vorherigen Stand gebracht.
816
Snapshots
왘
Revert To Snapshot Dieser Befehl setzt den Inhalt der virtuellen Festplatte auf den ParentSnapshot zurück, der Inhalt der VM-Festplatte wird also auf einen vorherigen Stand verändert.
13.13.2
Snapshot-Dateien auf dem Datastore
Nach der Erstellung eines Snapshots werden auf dem Datastore im Verzeichnis der virtuellen Maschine mehrere Dateien erstellt. Hier eine Beschreibung der wichtigsten Dateien: 왘
.vmsn-Datei Diese Datei existiert pro Snapshot und enthält die Konfiguration einer VM zu dem Zeitpunkt, als der Snapshot erstellt wurde. Diese Datei ist human readable (lesbar) und beinhaltet im Wesentlichen die Einstellungen der vmxDatei. Die Nummer des Snapshots wird im Dateinamen angezeigt, z. B.: VM_NAME-Snapshot1.vmsn -> erster Snapshot VM_NAME-Snapshot2.vmsn -> zweiter Snapshot
왘
.vmsd-Datei Diese Datei existiert pro VM einmalig und speichert die Definitionen vorhandener Snapshots einer VM.
왘
.vmem-Datei Diese Datei existiert pro Snapshot und archiviert den Inhalt des Speichers (RAM) der VM zu dem Zeitpunkt, als der Snapshot erstellt wurde und die VM eingeschaltet war.
왘
-nnn.vmdk-Datei Diese Datei existiert pro Snapshot und enthält die Änderungen der virtuellen Festplatte. Über den Inhalt der vmsd-Datei wird eine vmdk-Datei mit einer laufenden Nummer einem bestimmten Snapshot zugeordnet. Die fortlaufende Nummer erzeugt Dateinamen ähnlich dieser: VM_NAME-000001.vmdk VM_NAME-000002.vmdk
13.13.3
Hilfe bei Problemen
Wenn Sie mit Snapshots Probleme haben, z. B. wenn sich dieser nicht mehr löschen oder zusammenführen lässt, dann finden Sie im Blog von Dennis Zimmer einen guten Artikel, der die gängigen Snapshot-Probleme und deren Lösung beschreibt:
817
13.13
13
Virtuelle Maschinen
http://www.vmachine.de/cms/index.php/de/component/content/article/1/ 655-wenn-snapshots-zur-qual-werden
13.13.4
Die Snapshot-Hierarchie
Mit Hilfe des Snapshot Managers können Sie alle Snapshots einer VM einsehen und komfortabel verwalten, d. h. bestimmte Zustände persistieren oder verwerfen. Der Snapshot-Manager zeigt den Hierarchiebaum an und stellt die Beziehungen der Snapshots zueinander dar: Jeder Snapshot hat einen direkten Parent-Snapshot und einen direkten ChildSnapshot, sofern er nicht der letzte in der Hierarchie ist. Ein Snapshot kann mehrere Child-Snapshots haben. Aus dieser Hierarchie können Sie einen bestimmten Snapshot auswählen und zu diesem zurückspringen, d. h. den Zustand der VM basierend auf diesem Snapshot wiederherstellen. Dabei werden alle vorhandene Child-Snapshots entfernt. Das Persistieren von Snapshots hat zur Folge, dass alle vorherigen Snapshots gelöscht und die differenten vmdk-Daten in die vmdk-Datei eingefügt werden. Beispiel: Ein neuer Server W2K3Test4 wird mit SQL 2008-Server und dem IIS (Internet Information Server) installiert. Abschließend werden alle Datenbanken von einem bestehenden SQL-Server migriert. Die untenstehenden Screenshots dokumentieren das Leid des Administrators, da sehr viele Probleme dabei auftreten. Zum Glück ist es nicht immer so. 1. Das Betriebssystem inklusive der aktuellen Patches und diversen Agenten des neuen Servers W2KTest4 wurde installiert und von dieser Grundinstallation ein Snapshot erstellt. Sollte in einem nachfolgenden Schritt etwas schiefgehen, können Sie jederzeit zu diesem Ausgangspunkt zurückkehren (Abbildung 13.40).
Abbildung 13.40
818
Erster Snapshot nach der Grundinstallation
Snapshots
2. Im nächsten Schritt installieren Sie den IIS installiert und erstellen die virtuellen Verzeichnisse und verschiedene Application-Pools (Abbildung 13.41).
Abbildung 13.41
Snapshot nach der IIS-Installation
3. Nach der Erstellung des letzten Snapshots wurde der SQL Server 2008 installiert, doch die Installation brach aus unerklärlichen Gründen ab und hinterließ Fragmente auf dem Server. Wählen Sie den letzten Snapshot aus (Button Go to), um die Installation erneut zu wagen (Abbildung 13.42).
Abbildung 13.42
SQL-Installation schlug fehl; einen Schritt zurückgehen.
4. Jetzt ist die Installation des SQL-Servers geglückt, und die Datenbanken wurden erfolgreich migriert. Zu diesem Zeitpunkt können Sie alle Snapshots löschen (Abbildung 13.43).
819
13.13
13
Virtuelle Maschinen
Abbildung 13.43
13.13.5
Löschen aller Snapshots
Das Erstellen eines Snapshots (Take a Snapshot)
Das Erstellen eines Snapshots erfolgt am einfachsten über den vSphere-Client. Je größer das RAM der virtuellen Maschine und je höher die Last des ESX-Servers, desto länger dauert die Erstellung eines Snapshots. Ein Snapshot kann bei jedem beliebigen Power-State einer virtuellen Maschine durchgeführt werden, also im eingeschalteten Zustand – dann mit RAM-Inhalt –, im ausgeschalteten Zustand oder im suspendierten Zustand. Nach der Auswahl der VM im vSphere-Client rufen Sie entweder im Kontextmenü den Befehl Snapshot 폷 Take a Snapshot auf, oder Sie gehen über das Menü Inventory 폷 Virtual Machine des vSphere-Clients. Zur eindeutigen Identifikation des Snapshots geben Sie einen Namen an, z. B. »PreSQLSETUP«. Optional geben Sie noch eine erklärende Beschreibung dazu ab. Nach dem Klicken auf OK startet der Snapshot-Vorgang, und Sie können den Fortschrittsgrad im Fenster Recent Tasks überwachen.
13.13.6 Das Persistieren eines Snapshots (Delete a Snapshot) Ein wenig missverständlich ist der Punkt Delete a Snapshot. Hinter diesem Menüpunkt verbirgt sich das Persistieren der seit der Erstellung eines Snapshots aufgelaufenen Änderungen an der virtuellen Disk in die physische Datei mit anschließendem Löschen aller Snapshot-Dateien – kurz, als wenn nie ein
820
Die virtuelle Maschine im vSphere-Client
Snapshot erstellt wurde. Nach diesem Vorgang ist ein revert zu diesen Snapshot nicht mehr möglich, da er nicht mehr existiert. Eine sehr schnelle Möglichkeit, alle Snapshots einer virtuellen Maschine zu löschen und somit den aktuellen Zustand der virtuellen Maschine in die Dateien zu persistieren, ist der Menüpunkt Delete All Snapshots. Hinweis Das Löschen von Snapshots ist im vSphere-Client nur über den Snapshot-Manager möglich.
13.13.7
Das Verwerfen des aktuellen Zustands oder die Wiederherstellung eines Snapshots (Revert to Snapshot)
Auch beim Verwerfen des aktuellen Zustands oder Wiederherstellen eines Snapshots führt der einfachste Weg über den vSphere-Client. Sie haben drei Möglichkeiten, einen vorherigen Snapshot wiederherzustellen: 왘
Hinter dem Menüpunkt Inventory 폷 Virtual Machine 폷 Snapshot klicken Sie den Button Revert to Snapshot. Im Kontextmenü finden Sie ebenfalls den Befehl Revert to Snapshot.
왘
Klicken Sie auf den Button Revert to Snapshot in der Toolbar.
Jeder dieser drei Wege stellt den Parent-Snapshot einer virtuellen Maschine wieder her, also den jeweils letzten Snapshot. Wenn Sie die VM auf einen früheren Snapshot als den letzten zurücksetzen möchten, müssen Sie den Snapshot Manager verwenden. Dieser zeigt Ihnen alle bestehenden Snapshots und bietet daneben auch die Möglichkeit, bestimmte Snapshot-Zustände zu persistieren (Delete Snapshot).
13.14
Die virtuelle Maschine im vSphere-Client
Der vSphere-Client bietet Ihnen über die virtuellen Maschinen eine ganze Reihe von Informationen. Wählen Sie im Inventory eine VM aus, und klicken Sie sich durch die Reiter: Reiter Summary Der erste Reiter Summary bietet Ihnen eine Übersicht über die Konfiguration der virtuellen Maschine sowie der aktuell von ihr genutzten Ressourcen. Zusätzlich finden Sie Befehle, die Sie an der VM durchführen können und die Sie auch im Kontextmenü oder in der Menüleiste erreichen können.
821
13.14
13
Virtuelle Maschinen
Erklärungsbedürftig wären folgende Angaben: 왘
Memory Overhead: Dies ist der Virtualisierungs-Overhead, der auf dem ESXServer erzeugt wird, um diese VM zu verwalten. Er variiert je nach Anzahl der vCPUs, zugewiesenem Speicher und je nachdem, ob der Gast ein 32- oder 64Bit-Betriebssystem ist.
왘
Consumed Host CPU: auf dem ESX-Server von der virtuellen Maschine genutzte CPU-Ressourcen in MHz
왘
Consumed Host Memory: auf dem ESX-Server von der virtuellen Maschine genutzter Speicher
왘
Active Guest Memory: der benutzte Speicher in der virtuellen Maschine
왘
Provisioned Storage: die der VM garantiert auf dem Datastore zugewiesene Speichermenge
왘
Not-shared Storage: von der VM allein genutzte Speichermenge auf dem Datastore
왘
Used Storage: von der VM aktuell benötigter Speicherplatz auf dem Datastore
Abbildung 13.44
822
Die Übersichtsseite einer virtuellen Maschine
Die virtuelle Maschine im vSphere-Client
Reiter Resource Allocation Der Resource Allocation-Reiter bietet Ihnen im Vergleich zur Summary-Seite detailliertere Informationen über die CPU- und Speichernutzung Ihrer virtuellen Maschine. Im oberen Teil des CPU-Bereichs finden Sie analog zur Summary-Seite wieder den Wert Consumed, der den aktuellen CPU-Verbrauch dieser virtuellen Maschine in MHz angibt. Zusätzlich sehen Sie den Wert Active, der für den geschätzten CPU-Verbrauch auf dem ESX-Server in MHz dieser VM steht, sofern es keinen CPU-Ressourcenwettbewerb zwischen dieser und anderen VMs gibt. Bei der Vergabe eines CPU-Limits wird dieser Wert immer unter dem definierten Limit liegen. Im unteren Teil des Bereichs CPU sehen Sie die Werte einer eventuell eingestellten CPU-Ressourcenallokierung (zu finden in den Eigenschaften einer VM, Reiter Resources). Zusätzlich wird hier der Wert Worst Case Allocation angezeigt, der die maximal für diese VM zu vergebende CPU-Ressource in Bezug auf die physische Ausstattung des ESX-Servers angibt. Oben im Bereich Memory finden Sie unter Host Memory wieder analog zur Übersichtsseite die Angabe Consumed, die die auf dem ESX-Server allokierte Speichermenge für diese VM anzeigt. Der Wert Overhead Consumption informiert Sie über die aktuell benötigte Menge des für Memory-Overhead reservierten Speichers. Der Bereich Guest Memory zeigt Ihnen die folgenden Werte an: 왘
Private: vom ESX-Host für diese VM geschützte, private Speichermenge
왘
Shared: vom ESX-Host mit anderen VMs gemeinsam (»shared«) benutzte Speichermenge
왘
Swapped: vom ESX-Host mit Hilfe der Auslagerung in eine Swap-Datei gewonnener Speicherbereich
왘
Ballooned: vom ESX-Host mit Hilfe der Ballooning-Technik von dieser VM wiedergewonnener Speicherbereich
왘
Unaccessed: die bislang noch nie von der VM referenzierte Speichermenge
왘
Active: aktuell von der VM genutzte Speichermenge des ESX-Hosts
In der unteren Hälfte des Memory-Bereichs sehen Sie die Werte einer eventuell eingestellten Memory-Ressourcenallokierung (zu finden in den Eigenschaften einer VM, Reiter Resources). Zusätzlich ist hier der Wert Worst Case Allocation angegeben, der die maximal für diese VM zu vergebende Speichermenge angibt, also die der VM zugewiesene Speichermenge zuzüglich der Speichermenge für den Virtualisierungs-Overhead.
823
13.14
13
Virtuelle Maschinen
Abbildung 13.45
Die Ressourcenallokierung einer VM
Reiter Performance Im Reiter Performance können Sie die Performance-Werte der Core Four (CPU, RAM, Disk, Network) einsehen – entweder in Echtzeit oder als historische Daten. Zum einen sind die Werte absolut angegeben, im Falle der CPU also in MHz, oder in Prozent, also der Anteil der von der VM genutzten Ressource. Die Ansicht verändern Sie mit Klick auf die Combo-Box bei Switch to und wählen die Ressource aus, zu der sie die Performance-Daten sehen möchten. Zu jedem Ressourcentyp werden Ihnen vordefinierte Performance-Zähler angezeigt. Möchten Sie andere Informationen von diesem Counter einsehen oder auch die vom vCenter-Server historisierten Daten, so klicken Sie auf Chart Options und konfigurieren dort Ihre Ansicht. Zu jeder Ressource können Sie die Daten entweder in Echtzeit oder die historisierten Daten des letzten Tages, der letzten Woche, des letzten Monats oder des letzten Jahres anzeigen lassen. Alternativ geben Sie unter Custom einen genauen Zeitraum an. Diese Einstellungen können Sie als Chart abspeichern, um zu einem späteren Zeitpunkt Ihre Vorlage wieder zu verwenden. Bedenken Sie bei den historisierten Daten, dass diese über die Zeiträume hinweg geglättet dargestellt werden! So erkennen Sie z. B. bei einer Monatsansicht nicht, dass vor drei Wochen Ihr ESX-Host für eine Stunde einen Vollausschlag gezeigt hat.
824
Die virtuelle Maschine im vSphere-Client
Abbildung 13.46
Ansicht der Standard-Performance-Counter
Abbildung 13.47
Die Konfiguration eigener Performance-Charts
825
13.14
13
Virtuelle Maschinen
Reiter Task & Events Der Reiter Task & Events zeigt Ihnen eine Übersicht von an dieser VM durchgeführten Aktivitäten (Tasks) an oder von Ereignissen (Events), die zu dieser VM aufgetreten sind. Wählen Sie in der Übersicht einen Task oder ein Event aus, so erhalten Sie im unteren Fensterbereich detaillierte Informationen dazu. Die Listen können Sie nach allen Kriterien, die Sie in der Übersicht sehen, sortieren (z. B. nach Datum, nach Name, nach Status). Reiter Alarms Unter Alarms können Sie zum einen Alarmdefinitionen hinterlegen und zum anderen alle zu dieser VM aufgetretenen Alarme einsehen. Ein Alarm kann beispielsweise ausgelöst werden durch zu hohe Ressourcenauslastung oder durch Fehler bei Migrationen (VMotion). Ein ausgelöster Alarm kann wiederum selbst Aktionen ausführen wie das Senden eines SNMP-Traps.
Abbildung 13.48
Die vordefinierten Alarme einer VM
Reiter Console Im Reiter Console haben Sie eine direkte Sicht auf die Konsole des Betriebssystems. Sie stehen praktisch im Rechenzentrum vor diesem Server. Komfortabler stellen Sie eine Konsolenverbindung her, indem Sie die Remote Console über das Kontextmenü einer VM starten. Hier haben Sie nicht nur die Konsole in einem eigenen Fenster, losgelöst von der aktuellen vSphere-Client-Ansicht, Sie erstellen und verwalten damit auch die Snapshots oder verwalten das Floppy- oder CDROM-/DVD-Laufwerk der VM. Sollten zwei vSphere-Administratoren zur gleichen Zeit die Konsole einer VM öffnen, so erhalten beide einen nicht zu übersehenden Hinweisbalken, dass eine weitere Verbindung zur Konsole hergestellt wurde. Die Probleme mit einer Konsolenverbindung können sich auf den verschiedensten Wege bemerkbar machen. Die möglichen Fehlermeldungen sehen sie in Abbildung 13.49.
826
Die virtuelle Maschine im vSphere-Client
Abbildung 13.49
Mögliche Fehler bei einer Konsolenverbindung
Zusätzlich könnten Sie von folgenden Problemen heimgesucht werden: 왘
Die Konsolenverbindung lässt sich nicht öffnen.
왘
Die Konsole ist leer (schwarzer Bildschirm).
왘
Die Konsolenverbindung wird durch einen Timeout getrennt.
왘
Der VMotion-Vorgang schlägt fehl.
Hierzu gibt es eine Reihe von Dingen, die zu beachten oder zu konfigurieren sind: 왘
Überprüfen Sie eventuell zwischen Ihren vSphere-Clients und ESX-Server liegende Firewalls. Diese benötigen eine Regel, damit der Datenverkehr ungehindert über den Port 903 fließen kann. Sollten Sie mit Ihren Firewall-Kollegen keine Einigung über einen weiteren zu öffnenden Port finden, so können Sie auch den Remote-Console-Verkehr über den Port der Service Console (902) senden. Aktivieren Sie dazu den vmauthdProxy im ESX-Server: Fügen Sie die Zeile vmauthd.server.alwaysProxy = "TRUE" zur Datei /etc/ vmware/config hinzu, und starten Sie die Netzwerkdienste mit dem Befehl service xinetd restart neu.
왘
Überprüfen Sie die ESX-interne Firewall. Stoppen Sie dazu die Firewall mit folgendem Befehl, um danach zu testen, ob sich dann eine Konsolenverbindung aufbauen lässt: service firewall stop. Denken Sie daran, die Firewall wieder zu starten (verwenden Sie dazu start statt stop!).
왘
Stellen Sie sicher, dass zwischen dem ESX-Host und dem PC mit dem vSphereClient die Zeit synchron ist. Idealerweise verwenden Sie NTP.
왘
Der ESX-Server sowie der PC mit dem vSphere-Client benötigt eine korrekte Namensauflösung via DNS. Dies ist der am häufigsten anzutreffende Fehler bei Problemen mit der Konsolenverbindung.
왘
Hat Ihr ESX-Server zwei Netzwerkkarten in der Service Console konfiguriert, so dürfen diese nicht im gleichen Netzwerk hängen.
왘
Überprüfen Sie, dass die /var-Partition nicht vollgelaufen ist.
827
13.14
13
Virtuelle Maschinen
Reiter Permissions Im Reiter Permissions fügen Sie Benutzer, die entweder aus dem am vCenterServer angeschlossenen Active Directory oder der lokalen Windows-Benutzerverwaltung stammen, zu vordefinierten Rollen hinzu und weisen sie einzelnen virtuellen Maschinen zu. Idealerweise legen Sie die Berechtigung eine oder mehrere Stufen höher fest; z. B. haben Sie einen Folder Linux-Server, in dem all Ihre Linux-Server vereint sind, und definieren dafür eine Rolle »Linux-Admins«, die gewisse Berechtigungen auf diesen Folder erhält. Somit erben die Rolleninhaber für alle virtuellen Maschinen in diesem Folder die notwendigen Rechte. Weitere Informationen dazu erhalten Sie in Kapitel 11, »Konfiguration von ESX und vCenter«. Reiter Maps Die Maps können Sie auf allen Objektebenen (Datacenter, Cluster, ESX, Folder, VM etc.) einsehen. sie zeigen alle mit diesem Objekt verbundenen Einheiten und deren Bezug untereinander an.
Abbildung 13.50
Die Map einer virtuellen Maschine
13.15
Erweitertes VM-Management
13.15.1
Killen einer hängenden VM
Wenn das Stoppen einer virtuellen Maschine über den vSphere-Client nicht mehr den gewünschten Erfolg bringt, dann gibt es noch Wege, dies über die Ser-
828
Erweitertes VM-Management
vice Console des ESX-Servers durchzuführen, auf dem die virtuelle Maschine aktiv ist. 왘
Das »sanfte« Stoppen einer VM initiieren Sie durch: vmware-cmd /vmfs/volumes///.vmx stop
왘
Bringt dieser Befehl nicht den gewünschten Erfolg, versuchen Sie das »harte« Stoppen der VM mit: vmware-cmd /vmfs/volumes///.vmx hard
왘
Als letzte Möglichkeit steht Ihnen noch das Killen des Prozesses der virtuellen Maschine zur Verfügung. Dazu machen Sie zuerst die PID (Process-ID) der VM ausfindig: ps auxfww | grep
Die erste Zahl der Ausgabe ist die Process-ID. Mit dieser im Gepäck setzen Sie jetzt den kill-Befehl ein, um die VM endgültig zu stoppen: kill –9 ProcessID
Bedenken Sie bitte, dass alle Methoden versuchen, die virtuelle Maschine zu stoppen, ungeachtet dessen, ob das Gastbetriebssystem bereits heruntergefahren wurde oder nicht. Im schlimmsten Falle müssen Sie mit Datenverlust rechnen!
13.15.2
Überwachung der CPU-Performance von virtuellen Maschinen mit ESXTOP
Um einen recht guten Einblick über den Ressourcenhunger Ihrer virtuellen Maschinen zu erhalten, bietet sich der Befehl esxtop bzw. resxtop an, den Sie auf der Service Console eingeben. Sie erhalten alle möglichen Werte über die CPU- und Speicher-Auslastung, die Storage-Adapter oder Storage-Device-Auslastung und über die Netzwerklast. Bedenken Sie, dass Sie grundsätzlich alle zu ermittelnden Werte über eine ausreichend lange Zeit verfolgen müssen, um aussagekräftige Informationen zu erhalten! Möchten Sie den CPU-Verbrauch Ihrer virtuellen Maschinen überwachen, so starten Sie esxtop und werten die Zahlen zur aktuellen CPU-Auslastung in den CPU-Statistiken aus. Schauen Sie sich hier den Wert von %RDY in der Zeile an, wo der Name Ihrer VM in der ersten Spalte (Name) steht. Der %RDY-Wert steigt an, wenn die virtuellen CPUs in der VM CPU-Zeit vom physischen ESX-Server benötigen, aber dieser sie nicht liefern kann. Hauptsächlich sind dort die Werte interessant, die nicht dauerhaft über 5 % (Warning) oder sogar über 10 % (Error) sein sollten. Je höher der %RDY-Wert ist, desto langsamer
829
13.15
13
Virtuelle Maschinen
ist also Ihre virtuelle Maschine. Allerdings gilt dieser Wert bei einer virtuellen CPU in der VM; hat die VM vier virtuelle CPUs, so wäre der Wert bei »20« auf Warnung und bei »40« auf Error.
Abbildung 13.51
CPU-%RDY-Werte einer VM mit »esxtop« ermitteln
Zusätzlich zu diesem Prozentwert können Sie sich über den vSphere-Client die Performance-Statistik für Ready anzeigen lassen. Dieser Wert wird dort in Millisekunden angegeben.
Abbildung 13.52
Weitere CPU-Performance-Werte einer VM
Weiterführende Dokumente von VMware finden Sie unter http://communities.vmware.com/docs/DOC-9279 und http://viops.vmware.com/home/docs/DOC1404.pdf.
830
Dieses Kapitel beschäftigt sich mit der Ausfallsicherheit und der Hochverfügbarkeit der virtuellen Infrastruktur und deren Komponenten. Die Sicherung von Hosts und VMs ist genauso Bestandteil wie die Konfiguration eines Microsoft Cluster Services.
14
Ausfallsicherheit Autor dieses Kapitels ist Betram Wöhrmann, Ligarion, [email protected]
Zur Abbildung der Funktionen müssen Sie sich nicht nur auf dem Third-PartyMarkt orientieren, auch VMware bietet Software-Add-ons an, mit denen Sie solche Aufgaben durchaus lösen können.
14.1
Sicherung – Rücksicherung
Eines der wichtigsten Themen beim Betrieb einer virtuellen Infrastruktur ist die Sicherung der verschiedenen Komponenten. Zur Datensicherung der virtuellen Maschinen kommen jetzt noch Sicherungen der VMware-vSphere-Hosts hinzu. Des Weiteren ist eine Backup-Strategie für den vCenter-Server, die zugehörige Datenbank und weitere Komponenten der Infrastruktur sowie deren Konfiguration zu erarbeiten. Es gibt verschiedene Alternativen, diese Aufgaben zu erfüllen. In diesem Kapitel gehen wir auf verschiedene Möglichkeiten ein, die einzelnen Komponenten zu sichern.
14.1.1
Sicherung des ESX-Hosts
Wie geht man nun mit der Sicherung der Host-Systeme um? Schauen wir einmal zurück, wie ein Host installiert wird und welche Daten er vorhält. Die Installation eines vSphere-Hosts geht grundsätzlich sehr schnell. Der Zeitfaktor wird nur dadurch beeinflusst, wie die Installation erfolgt, ob manuell, per Skript oder über eine Installations-Appliance. Die Daten, die ein Host vorhält, sind eigentlich nur Konfigurationsdaten. Alle anderen Informationen gehören zu
831
14
Ausfallsicherheit
den virtuellen Maschinen und liegen auf dem Datastore oder in der Datenbank des vCenter-Servers. Selbstverständlich können Sie einen Datensicherungs-Client in der Service Console installieren. Die Hersteller bieten dazu passende Whitepaper, die die Installation beschreiben. Berücksichtigen Sie bitte, dass diese Lösung nur für ESX-Systeme funktioniert, nicht aber für ESXi-Systeme, weil diese ja keine Service Console besitzen! Eine Rücksicherung der Daten erfolgt hier über die bekannten Rücksicherungsmechanismen der Softwareanbieter. Warum gehen wir darauf an dieser Stelle ein? Schauen wir uns einmal den schlechtestmöglichen Fall an: Das System muss zurückgesichert werden, während gerade das Vollsicherungszeitfenster für die Systeme im Rechenzentrum läuft. Was geht nun schneller – die Rücksicherung oder die Neuinstallation? Des Weiteren ist zu berücksichtigen, dass bei einem Verlust einer Installation zuerst ein Host neu installiert werden muss, dann wird der Datensicherungs-Client installiert. Erst jetzt ist es möglich, die gesicherten Daten auf dem Host einzuspielen. Aus diesem Grund müssen Sie sich die Frage stellen, ob es überhaupt sinnvoll ist, den Host zu sichern. Können Sie aufgrund der Lizensierung mit Host-Profiles arbeiten, gestaltet sich der Prozess der Inbetriebnahme nach der Installation recht einfach. Steht die Funktion der Host-Profiles lizenztechnisch nicht zur Verfügung, können Sie sie auch mit der PowerCLI und dem PowerScripter nachbauen. Mit einem Installationsskript oder einer Installations-Appliance sind Neuinstallationen in sehr kurzer Zeit möglich. Aus unserer Sicht investieren Sie die Zeit besser in eine gute automatisierte Installation. Damit schlagen Sie zwei Fliegen mit einer Klappe: Zum einen ist das System im Fehlerfall schnell wieder am Start, und zum anderen können Sie neue Systeme schneller in Betrieb nehmen.
14.1.2
Sicherung der Komponenten
Der erste Teil dieses Abschnitts beschäftigt sich mit allgemeinen Möglichkeiten, die verschiedenen Komponenten zu sichern, die für den Betrieb einer virtuellen Landschaft nötig sind. Dabei gehen wir nicht näher auf spezielle Produkte ein. Wir möchten darlegen, was wie gesichert werden sollte bzw. gesichert werden kann.
832
Sicherung – Rücksicherung
Wir können Ihnen natürlich nur Empfehlungen geben und technisch darstellen, was möglich ist. In vielen Unternehmen gibt es aber Richtlinien, die dem Administrator erst einmal keinen Spielraum für die Vorgehensweise beim Thema Datensicherung und Datenrücksicherung lassen. Es kann also gut sein, dass Sie erst Entwicklungsarbeit leisten müssen, damit Sie den technisch optimalen Weg gehen können. Sicherung des Managements An dieser Stelle sei angemerkt, dass wir davon ausgehen, dass alle Applikationskomponenten auf einem Server installiert sind. Lediglich die Datenbank kann auch auf einem anderen Server bereitgestellt werden. Für die grundsätzliche Strategie zur Sicherung der betroffenen Server ist es entscheidend, ob Applikationen und Datenbank auf einem System liegen oder nicht. Schon bei der Abwägung, ob Datenbank und Applikation voneinander getrennt werden, sollten Sie die Datensicherung immer in der Planung berücksichtigen. Vergessen Sie nie, dass jede Verfügbarkeit nur so gut ist wie das schwächste Glied in der Kette. Sicherung des vCenter-Servers Der VMware vCenter Server ist einer der entscheidenden und wichtigsten Faktoren in einer virtuellen Landschaft. Obwohl über diese Komponente alle wichtigen Arbeiten durchgeführt werden und alle Fäden der Umgebung hier zusammenlaufen, ist ein Ausfall des vCenters im Grunde erst einmal nichts, was eine laufende Umgebung stark beeinträchtigt. Zwar stehen einige Funktionen nicht zur Verfügung, das ist aber unter Umständen zu verschmerzen. Bevor Sie tiefer in die Planung einsteigen, sollten Sie sich vergegenwärtigen, welche Funktionen bei einem Ausfall des Managements nicht zur Verfügung stehen. Die Tabelle 14.1 zeigt Ihnen, auf welche Eigenschaften Sie bei einem Ausfall verzichten müssen und welche Eigenschaften Sie weiterhin im Betrieb unterstützen. Funktion
Funktion ohne Virtual Center
VMotion
nein
VMware DRS: Manual
nein
VMware DRS: Automatic
nein
VMware DRS: Affinity rules
nein
Resource Pool: Create
nein
Tabelle 14.1
Funktionsstatus bei inaktivem vCenter-Server
833
14.1
14
Ausfallsicherheit
Funktion
Funktion ohne Virtual Center
Resource Pool: Add VM
nein
Resource Pool: Remove VM
nein
VMware HA: Restart VM
ja
VMware HA: Admission Control Add new host to cluster
nein
VMware HA: Add new host to cluster
nein
VMware HA: Host rejoins the Cluster
ja
Tabelle 14.1
Funktionsstatus bei inaktivem vCenter-Server (Forts.)
Mit den Daten, die Ihnen jetzt vorliegen, können Sie entscheiden, wie lange das System ausfallen darf, bevor es für den Betrieb kritisch wird. Darf die Ausfallzeit nur minimal sein, empfehlen wir den Einsatz des vCenter Server Heartbeats (siehe Kapitel 5, »Installation«, und Kapitel 12, »Konfiguration von vCenter-Add-Ons«), alternativ den Einsatz eines Clusters oder eines ColdStandby-vCenter-Servers als virtuelle Maschine. Alle wichtigen Daten und Informationen des VMware vCenters liegen in der Datenbank. Im Falle einer Zerstörung des vCenters wäre es möglich, den Server neu zu installieren und durch Anhängen der Datenbank direkt weiterzuverwenden. Das geht natürlich nur, wenn die Datenbank auf einem getrennten System zur Verfügung gestellt wird. Die Datensicherung erfolgt in diesem Fall klassisch: für den Applikations-Server als file-basierte Sicherung und für die Datenbank über einen Wartungsplan. Welche Datensicherungssoftware Sie nutzen wollen, bleibt Ihnen überlassen. Es sollte das Produkt zum Einsatz kommen, für das schon Know-how in Ihrem Hause vorhanden ist. Sicherung der vCenter-Server-Datenbank Eine der wichtigsten Komponenten in der virtuellen Landschaft ist die Datenbank, mit der das vCenter arbeitet. In dieser Datenbank werden alle relevanten Daten gespeichert. Dementsprechend ist eine Sicherung der Datenbank notwendig und wichtig. Sollte es in Ihrer Firma einen Datenbank-Server für zentrale Aufgaben geben oder auch »nur« einen Datenbank-Server, der noch eine weitere Datenbank aufnehmen kann, dann empfehlen wir Ihnen, diesen zu nutzen. Zum einen wird dann eine einzeln liegende Datenbank nicht vergessen, zum anderen können Sie sie einfach in die Standardprozesse integrieren. Das Thema Sicherung ist dann
834
Sicherung – Rücksicherung
auch recht einfach abgehandelt: Sie verwenden einfach den bekannten Firmenstandard, was eine einfache Einbettung in die bestehenden Betriebsprozesse bedeutet. An dieser Stelle beschreiben wir kurz das Prinzip und die Grundlagen einer Datenbanksicherung. Diese Beschreibung ist allgemein gehalten, geht also in keiner Weise auf ein spezielles Produkt ein. Die Datensicherung einer Datenbank kann im Normalfall nicht mit dem Programm zur Datensicherung des Betriebssystems vollständig abgedeckt werden. Mit dieser Software lassen sich nur mehrere oder einzelne Files sichern. Sollen Datenbanken im laufenden Betrieb gesichert werden, benötigen Sie einen herstellerspezifischen Datenbankagent, der das Handling für die Arbeiten übernimmt. Dieser Agent garantiert, dass die Sicherung konsistent ist und somit auch für den Aufbau eines neuen Servers genutzt werden kann. Die einfachste und sicherste Methode der Datenbanksicherung ist eine komplette Sicherung der Datenbank im heruntergefahrenen Zustand. Bei dieser Sicherung sind keine Daten der Datenbank im Zugriff, so dass Sie sie ohne Probleme sichern können. Diese Methode ist allerdings aufgrund der geforderten Verfügbarkeit der Datenbanksysteme meist nicht umsetzbar. Die Alternative zum Backup der Datenbank im heruntergefahrenen Zustand ist die Sicherung im Onlinemodus. Dabei wird die Datenbank im laufenden Betrieb, also während des Zugriffs auf die Daten, gesichert. Der Nachteil bei dieser Methode ist, dass Inkonsistenzen nicht komplett ausgeschlossen werden können. Trotz alledem wird mindestens einmal, besser aber regelmäßig, eine Offlinesicherung der Datenbank benötigt. Auf diese Sicherung setzt die Onlinesicherung dann auf. Alle Transaktionen, die in einem Datenbanksystem stattfinden, werden in den Log-Dateien gespeichert. Aus diesem Grund ist es wichtig, diese Log-Dateien ebenfalls zu sichern. Nach dem Rücksichern der Datenbank können Sie so, durch das Einspielen der Transaktionen, einen Status wiederherstellen, der sehr nahe an dem letzten produktiven Stand ist. Wir empfehlen, eine Offlinesicherung einmal die Woche durchzuführen, sowie eine tägliche Onlinesicherung. Zusätzlich sollten Sie die Log-Dateien mehrmals täglich wegschreiben. Die Rücksicherung erfolgt nach den bekannten Prozessen. Ist die Offlinesicherung eingespielt, verarbeiten Sie die zusätzlich aufgelaufenen Log-Dateien, um so auf den letztmöglichen Stand zu kommen. Das eigentliche Vorgehen bedarf an dieser Stelle keiner näheren Beschreibung.
835
14.1
14
Ausfallsicherheit
14.1.3 Sicherung der virtuellen Maschinen Eine der wichtigsten Aufgaben bei der Sicherung der Daten ist selbstverständlich das Backup der virtuellen Maschinen. Dem Administrator stehen verschiedene Optionen für die Gewährleistung der Datensicherheit einer virtuellen Maschine zur Auswahl. In diesem Abschnitt erläutern wir näher, welche Wege zum Ziel führen. Als Unterscheidung dient die Sicherung innerhalb oder außerhalb der VM. Klassische Datensicherung Die erste Methode der Datensicherung einer virtuellen Maschine ist dieselbe wie bei einem physischen Server. Dabei verwenden Sie die bereits vorhandene Backup-Infrastruktur, um die Daten der virtuellen Maschine zu sichern. Installieren und konfigurieren Sie dazu einen Backup-Agent der verwendeten Backup-Software im Betriebssystem der virtuellen Maschine. Dieser überträgt alle Daten zu einem vorhandenen Backup-Server. Die Datensicherung erfolgt dabei zeitgesteuert über den Client und läuft ins zentrale Management. Der Vorteil einer solchen Datensicherung ist, dass Sie die bereits verwendete Backup-Infrastruktur ohne Anpassungen oder spezielle Erweiterungen verwenden können. Sie können sogar Maschinen, die von einer physischen Infrastruktur auf eine virtuelle Infrastruktur übernommen wurden, ganz normal weiter sichern, einschließlich der Übernahme der bereits vorhandenen Sicherungsdaten. Legen Sie aber ein Augenmerk auf die Netzwerkanbindung der virtuellen Server, denn der gesamte Datensicherungsdatenstrom läuft über das LAN. Eine Rücksicherung erfolgt ebenfalls über den Datensicherungs-Client, in gewohnter Manier. Also auch hier gibt es keine Änderung bei den Datensicherungsprozessen. VMware Consolidated Backup (VCB) Seit der Version Virtual Infrastructure 3.x liefert VMware ein eigenes Produkt zur Sicherung der virtuellen Maschinen. Mit dem VMware Consolidated Backup (im Folgenden VCB genannt) hat VMware ein Produkt entwickelt, mit dem sich VMs schnell und komfortabel sichern lassen. Was genau ist nun VCB, und wie funktioniert das Ganze? Beim VCB handelt es sich um einen sogenannten Sicherungsproxy-Server. Dieser Server sammelt die Sicherungsdaten der virtuellen Maschinen und gibt sie geschlossen an einen Sicherungs-Server weiter.
836
Sicherung – Rücksicherung
Es gibt zwei Varianten, wie die Daten zum Proxy bzw. zum Datensicherungs-Server gelangen können. Liegen die virtuellen Maschinen auf SAN- oder iSCSILUNs, können die Daten LAN-free direkt von der LUN gesichert werden. Kommt anderer Storage zum Einsatz, geht der Datenfluss über die Netzwerkkarte der Service Console zum VCB-Server und dann weiter zum Datensicherungs-Server. Hier wird auch der Vorteil des VCB-Systems deutlich: Kann LAN-free gearbeitet werden, entlastet das nicht nur das Netzwerk, sondern steigert auch enorm die Sicherungsgeschwindigkeit. Bedenken Sie bitte, dass Sie im Falle des LAN-freeBackups ein oder mehrere physische Server benötigen, damit ein Zugriff auf die Komponenten im SAN möglich ist. Ein VCB-Server kann nicht unendlich viele Server sichern, darum ist mit dem Einsatz mehrerer VCB-Server zu rechnen. Für das genaue Sizen einer VCB-Landschaft sind im Vorfeld ausgiebige Tests notwendig, um zu bestimmen, wie viele VCB-Proxies benötigt werden. Müssen die Daten über das LAN direkt gesammelt werden, können Sie als VCBProxy auch eine oder mehrere virtuelle Maschinen einsetzen. Der Vorteil an dieser Stelle ist, dass sich als Zielspeicher auch preiswertere NAS-Systeme eignen, im Gegensatz zum teureren SAN. Der Nachteil dabei ist aber, dass der gesamte Datenfluss wieder über das Netzwerk läuft. Kommen wir nun zur Funktionsweise. Als Orientierungshilfe für die Beschreibung der Funktionsweise dient Abbildung 14.1.
Abbildung 14.1
Arbeitsschritte des VCB-Servers
837
14.1
1450.book Seite 838 Freitag, 5. Februar 2010 12:11 12
14
Ausfallsicherheit
Mit dem Beginn der Datensicherung initiiert der VCB-Proxy auf der virtuellen Maschine die Erstellung eines Snapshots (1). Ist dieser Snapshot erstellt, mountet sich der Proxy-Server diesen Snapshot und sammelt die Daten aus der VM (2). Ist die Datensicherung abgeschlossen, wird der Snapshot wieder gelöscht und mit den Daten, die sich während der Sicherung geändert haben, zusammengeführt. Unabhängig von der virtuellen Maschine kann der VCB-Server die Daten des virtuellen Servers nun wegsichern (3). Für alle unterstützten Betriebssysteme ist auch eine image-basierte Sicherung möglich. Dabei werden alle Dateien direkt aus dem VMFS-File-System auf den VCB-Server gesichert. Das schließt auch die Konfigurations-Files ein. Setzen Sie auf der zu sichernden VM ein Windows-basiertes Betriebssystem ein, können Sie die Sicherung auch auf File-Level-Ebene durchführen. Beim DateiLevel-Backup gibt es wiederum drei verschiedene Methoden, die Dateien aus der virtuellen Maschine zu sichern. Full file Backup sichert alle Dateien, die in dem virtuellen Server vorhanden sind. Bei einem Differentiellen Backup werden alle Dateien gesichert, die seit einem Full file Backup geändert wurden. Als dritte und letzte Möglichkeit bietet sich die Methode Inkrementelles Backup an. Dabei werden alle Daten gesichert, die seit dem letzten Backup, egal ob Full oder Inkrementell, geändert wurden. In diesem Fall gestaltet sich die Rücksicherung nicht ganz so einfach wie in den vorhergehenden Fällen. Wir unterscheiden mehrere verschiedene Möglichkeiten der Rücksicherung. Jeder für sich muss abschließend entscheiden, welcher Weg für ihn am besten ist. Aus unserer Sicht sind nicht alle beschriebenen Wege im normalen Betrieb wirklich realisierbar. Eine Rolle spielen sicherlich auch die Größe der Landschaft und die Vorgaben, die in der Firma vorherrschen. Bei der ersten Rücksicherungsoption werden die zu restaurierenden Daten auf dem VCB-Proxy wiederhergestellt. Dann kopieren Sie die wiederhergestellten Daten über einen CIFS-Share auf die entsprechende virtuelle Maschine. Der Vorteil ist sicherlich, dass Sie keinen Datensicherungs-Client in der VM benötigen; wie praktikabel das Ganze ist, muss jeder für sich selbst entscheiden. Achtung Diese Funktion steht nur zur Verfügung, wenn als Betriebssystem der VM Windows zum Einsatz kommt. Bei anderen Gastbetriebssystemen ist diese Funktion derzeit noch nicht verfügbar.
838
1450.book Seite 839 Freitag, 5. Februar 2010 12:11 12
Sicherung – Rücksicherung
Für das Zurücksichern von image-basierten Sicherungen gibt es zwei Möglichkeiten: Speichern Sie die Files einer virtuellen Maschine auf dem VCB-Proxy zwischen; anschließend erstellen Sie über den vCenter Converter aus diesen Dateien eine neue VM. Alternativ kopieren Sie die Files über den Proxy direkt auf den Datastore des Hosts und registrieren die virtuelle Maschine über den vCenterServer neu. Voraussetzung dafür ist aber, dass die alte VM vorher deaktiviert wurde. Die erste Methode eignet sich auch ideal zur Fehlersuche in einem virtuellen Server. Beide Server lassen sich parallel betreiben; die IP-Adresse und den Namen sollten Sie schon vor der Inbetriebnahme anpassen oder den zweiten Server in ein privates Netzwerk stellen. Die zweite Funktion können Sie in Verbindung mit dem klassischen BackupAgenten einsetzen. Die Full Backups sind so schnell über das Fibre-Channel-Netzwerk ausgeführt, und die file-basierte Sicherung erfolgt über den Datensicherungs-Client. Hier ist ebenfalls, wie bei allen anderen Lösungen, zu prüfen, inwieweit sich die Arbeiten in den bestehenden Datensicherungs- bzw. Restore-Prozess integrieren lassen.
14.1.4 Backup von vSphere-Umgebungen mit NetApp-Storage Autor dieses Abschnitts ist Oliver Kügow, team(ix) GmbH, [email protected]
Die meisten Firmen entscheiden sich ganz klar für Virtualisierung, da die Konsolidierung der Infrastruktur viele Vorteile mit sich bringt, die wichtigsten sind wohl drastische Kosteneinsparungen und vereinfachtes Management. Allerdings wird an einigen Stellen vergessen, dass ein hoher Konsolidierungsgrad auch Folgeeffekte mit sich bringt, wie zum Beispiel eine starke Konzentration der Daten auf einem Punkt: das zentrale Speichersystem. Mit dieser Datenkonzentration auf einen Punkt muss im Alltagsbetrieb umgegangen werden, insbesondere beim Thema Backup. Vor der Virtualisierung installierte man typischerweise Backup-Agenten auf jeden einzelnen Server, die dann über das LAN die Backup-Datenströme an einen zentralen Backup-Server sendeten, der sie wiederum auf Band schrieb. Ein solcher Ansatz ist zwar immer noch möglich, indem Sie einfach die Agenten in jede virtuelle Maschine installieren, allerdings resultieren daraus erhebliche Lastspitzen, sowohl auf dem vSphere-Host als auch auf dem Speichersystem. Diese Problematik müssen Sie mit intelligenten neuen Technologien lösen, ähnlich wie
839
14.1
14
Ausfallsicherheit
Konsolidierungsfragen durch Virtualisierung gelöst wurden. Sprich: Das Backup muss sich der Virtualisierung und der damit folgenden Datenkonzentration anpassen. Ein Backup wird immer besser, wenn folgende Kriterien erfüllt werden: 왘
Niedriges RPO (Recovery Point Objective): Man darf im Falle einer Wiederherstellung möglichst wenig Daten verlieren. Das gewährleisten Sie durch häufiges Ausführen von Backups.
왘
Niedriges RTO (Recovery Time Objective): Die Wiederherstellung sollte möglichst schnell erfolgen.
왘
Beim Erstellen des Backups sollten möglichst wenige Daten bewegt werden, sonst kann das Backup-Zeitfenster aufgrund gestiegener Datenmengen nicht mehr eingehalten werden.
왘
Backups sollten Sie möglichst an geografisch entfernten Orten werden, damit auch ein Desasterschutz existiert.
왘
Backups müssen automatisiert durchgeführt werden, manuelle Eingriffe sollten Sie vermeiden. Dazu zählt z. B. neben dem Transport von Bändern auch die manuelle Konfigurationserweiterung oder Anpassung bei Server-Änderungen – diese werden nämlich leicht vergessen.
NetApp löst all diese Anforderungen nahezu perfekt, gerade im Zusammenspiel mit VMware vSphere. Snapshots bilden die Basis für eine schnelle, effiziente und häufige Datensicherung. Ein NetApp-Snapshot hält den Zustand eines Volumes als Read-only-Kopie eines bestimmten Zeitpunktes fest. Die Snapshots sind performance-neutral und belegen nur so viel Platz, wie sich real Daten geändert haben. Es ist möglich, bis zu 255 Snapshots pro Volume zu erzeugen. Beim Erstellen eines Snapshots werden keine Daten bewegt oder kopiert, sondern lediglich Zeiger auf die vorhandenen Daten eingefroren – das geht sehr schnell, ein Snapshot ist in weniger als einer Sekunde erstellt. Die Snapshots liegen allerdings noch auf denselben Disks wie die Originalplatten, das verhindert zwar das versehentliche Löschen von Daten, aber ein ausreichender Desasterschutz fehlt noch. Dafür hat NetApp Replikationsmechanismen wie SnapMirror oder SnapVault im Portfolio – mit diesen Mechanismen werden nur die geänderten Daten über das Netzwerk auf eine andere NetApp-Maschine repliziert. Die Replikation geschieht vollautomatisch und in regelmäßigen Abständen, z. B. einmal pro Stunde. Am besten stellen Sie sich den Vorgang so vor:
840
Sicherung – Rücksicherung
왘
Snapshots halten den (konsistenten) Zustand auf dem produktiven Speichersystem fest.
왘
Replikation transportiert diese Zustände auf ein Backup-System, es werden nur blockweise Änderungen seit dem letzten Transport kopiert.
Damit im Zusammenhang mit VMware die virtuellen Maschinen aber in jeder Sicherung konsistent sind, müssen Sie vor der Sicherung per Snapshot die VMs in einen sauberen, definierten Zustand bringen. Es kommen grundsätzlich drei Zustände in Frage: 왘
VM ausgeschaltet (kalt): Damit ist die Disk der VM sicher konsistent, allerdings spricht die damit verbundene Downtime oft gegen diese Variante.
왘
VM suspended (warm): Die VM wird in den Ruhezustand gebracht, das RAM der VM wird auf Disk geschrieben. Da die VM und ihre Applikationen nicht mehr laufen, ist der Zustand auch wirklich konsistent, nur ist auch dies wieder mit (kürzerer) Downtime verbunden.
왘
VM angeschaltet (hot): Die Disk der virtuellen Maschine muss in einen sauberen Zustand gebracht werden, das kann durch einen VM-Snapshot geschehen. Es gibt keine Downtime, allerdings ist auch keine 100 %ige Konsistenz gewährleistet; VMware spricht hier von »Crash-consistent«, also genauso konsistent wie nach einem Absturz. Damit die Applikationskonsistenz gewährt ist, können Sie durch ein Skript in der VM die Applikation vor dem VMSnapshot in den Backup-Modus bringen. Der FS-Sync-Treiber der VMware Tools leert vor dem VM-Snapshot auch noch die Schreibcaches der VM.
Der gesamte Vorgang sähe also zusammengefasst so aus: 1. alle VMs im Datastore konsistent machen, VM-Snapshot erstellen 2. NetApp-Snapshot des Datastore-Volumes erstellen 3. die VM-Snapshots wieder löschen Um diesen Ablauf zu koordinieren, gibt uns NetApp zwei Tools an die Hand: 왘
SnapManager for Virtual Infrastructure (SMVI)
왘
Virtual Infrastructure Backup Engine (VIBE)
SMVI ist das Tool der Wahl. Es hat eine GUI und wird von NetApp offiziell unterstützt. Allerdings kostet es auch Geld. Es bietet neben der Backup-Funktion auch die Möglichkeit, Restores durchzuführen, seit Version 2.0 können User sogar einzelne Dateien aus VM-Snapshots selbst wiederherstellen.
841
14.1
14
Ausfallsicherheit
VIBE ist ein Perlskript. Es gibt keine GUI und keinen Support, dafür ist das Tool allerdings kostenlos und im Quelltext verfügbar, Sie können es also auch gut an Ihre eigenen Bedürfnisse anpassen. SMVI Es soll noch kurz die Funktionsweise von SMVI gezeigt werden, inklusive einer kurzen Anleitung zur Installation. Für SMVI benötigen Sie einen Windows-Rechner benötigt, Sie können aber auch eine virtuelle Maschine verwenden, sollte dann aber darauf achten, dass diese auf einem anderen Datastore liegt als die zu sichernden VMs, weil es sonst während der Sicherung zu unerwünschten Hängern kommen kann. Führen Sie den Installer aus, und wählen Sie, ob Sie nur die Server-Komponente installieren, nur den Client oder beides. Wir entscheiden uns für das gesamte Paket (Abbildung 14.2).
Abbildung 14.2
Installation des SnapManagers
Nach erfolgter Installation stellen Sie zuerst die Log-in-Daten für den SMVI-Server ein (Abbildung 14.3). Die gewählte User-Passwort-Kombination muss identisch sein mit einem administrativen Log-in auf dem vCenter-Server!
Abbildung 14.3
842
Setzen der Server-Credentials
14.1
Sicherung – Rücksicherung
Beim ersten Start des SMVI-Clients loggen Sie sich mit den Daten aus Abbildung 14.4 ein.
Abbildung 14.4
Log-in-Dialog des SnapManagers
Anschließend führen Sie unter dem Punkt Set up (1) noch kurz die Konfiguration durch: Geben Sie das Virtual Center an (2) und die entsprechenden NetApp-Systeme (3).
2
3
1
Abbildung 14.5
Konfiguration des SnapManagers
Nach der Konfiguration zeigt das Inventory alle vorhandenen Objekte; wir finden den FCP-Datastore und darin eine VM (Abbildung 14.6).
843
14
Ausfallsicherheit
Abbildung 14.6
Fibre-Channel-Datastore
Nun erstellen Sie manuell ein Backup. Wir sichern als Beispiel die eine vorhandene virtuelle Maschine. Dabei können Sie wählen, ob Sie für die Konsistenz der VM vorher einen Snapshot erstellen, außerdem starten Sie optional auch nach einem erfolgreichen Backup gleich die Replikation per SnapMirror. SnapVault ist leider noch nicht integriert (Abbildung 14.7).
Abbildung 14.7
844
Wizard zur Einrichtung eines Backup-Jobs
Sicherung – Rücksicherung
Entscheiden Sie nun, wie oft der Job laufen soll oder ob er nur einmal gestartet wird (Abbildung 14.8).
Abbildung 14.8
Zeitfenster für den Backup-Job einstellen
Schließlich haben Sie noch die Möglichkeit, sich E-Mail-Reports über den Verlauf eines Backup-Jobs zuschicken zu lassen (Abbildung 14.9).
Abbildung 14.9
Einrichtung der E-Mail-Benachrichtigung
845
14.1
14
Ausfallsicherheit
Der Backup-Job wird in diesem Fall manuell gestartet. Der gesamte Vorgang dauert ca. 20 Sekunden – nicht schlecht für eine 6-GB-VM! Die längste Zeit des Backups wird damit verbracht, die VM-Snapshots nach dem NetApp-Snapshot wieder zu entfernen.
Abbildung 14.10
Task-Fenster des SnapManagers
Der Mechanismus skaliert hervorragend, selbst bei 100 VMs dauert ein Backup nur wenige Minuten. Das SnapMirror-Update wird danach im Hintergrund gestartet und betrifft den eigentlichen Backup-Prozess nicht mehr. Abschließend sei noch kurz ein Recovery-Vorgang gezeigt, in diesem Beispiel spielen wir die gesamte VM zurück. SMVI erlaubt aber das Wiederherstellen von einzelnen Dateien aus einem VM-Snapshot. SMVI erzeugt für die Wiederherstellung der VM einen LUN-Clon des Datastores. Dieser Clone wird an den Host gemappt, und anschließend werden die Files der VM zurück auf den Original-Datastore kopiert, was etwas Zeit kostet. Dieses RTO ist zwar relativ schnell im Vergleich zu einem klassischen Recovery von Band, allerdings besteht noch Optimierungspotential, was in künftigen Versionen des SMVI ausgeschöpft werden wird.
846
Sicherung – Rücksicherung
Abbildung 14.11
Restore-Fenster des SnapManagers
Momentan bleibt für eine noch schnellere Rücksicherung der VM nur der manuelle Weg: Erzeugen Sie einen LUN-Clone des Datastores, mappen Sie diesen an den ESX-Host, und registrieren Sie direkt auf dem Clone die VM neu. Anschließend können Sie diese direkt auf der Clone-LUN starten. Damit läuft die VM innerhalb von Sekunden wieder. Damit der Clone wieder entfernt werden kann, müssen Sie anschließend die VM per Storage VMotion auf den ursprünglichen Datastore zurückmigrieren. Dieser Vorgang funktioniert auch mit NFS-Datastores, allerdings ist dafür die FlexClone-Lizenz von Netapp nötig. VIBE Die Virtual Infrastructure Backup Engine (VIBE) ist die kostenlose und quelloffene Alternative zum SMVI, allerdings ohne Support und mit etwas mehr Handarbeit.
847
14.1
14
Ausfallsicherheit
Das Paket ist als kompilierte .exe-Datei für Windows und als .pl-Skript für diverse Unix-Varianten verfügbar. Für die Perlvariante müssen Sie allerdings noch einige Perl-Bibliotheken nachinstallieren, was unter Umständen ziemlich aufwendig ist. VIBE können Sie von now.netapp.com herunterladen. Nach der Installation auf Windows ist eine VIBE.exe verfügbar, es wird auch eine sehr ausführliche Dokumentation als PDF mitgeliefert. Hier soll nur kurz exemplarisch ein Backup unseres FCP-Datastores demonstriert werden. Der Ablauf ist identisch mit dem SMVI. Sie machen die VMs per VMSnapshot konsistent, lösen anschließend wird den NetApp-Snapshot aus und entfernen dann die VM-Snapshots wieder.
Abbildung 14.12
Backup mit VIBE
[14:17:34] VIBE Version: 1.0.11 [14:17:34] Log Filename: C:\Programme\NetApp\VIBE\Report\VIBE_20091112_ 141734.log [14:17:34] Backup Start Time: Thu Nov 12 14:17:34 2009 [14:17:34] WARNING: --vcpasswd not defined on command line. [14:18:57] WARNING: --sapasswd not defined on command line. [14:18:57] Datastore(s) selected: na2026a_fcp_ds01 [14:18:57] Datastore snapshot prefix will be used (VIBE_ds_snap). [14:18:57] Command line arguments successful. [14:18:57] Initializing connectivity to Virtual Center and storage appliances. [14:18:57] Converting Virtual Center hostname to IP address ...
848
Sicherung – Rücksicherung
[14:18:57] Attempting to ping Virtual Center 10.100.24.103 ... [14:18:57] Ping of Virtual Center 10.100.24.103 successful. [14:18:57] Creating new Virtual Center instance for 10.100.24.103 ... [14:18:57] Logging into Virtual Center server 10.100.24.103 ... [14:18:58] Virtual Center login successful. [14:18:58] Attempting to ping storage appliance 10.32.76.1 ... [14:18:58] Ping of storage appliance 10.32.76.1 successful. [14:18:58] Testing login to storage appliance 10.32.76.1 ... [14:18:58] Adding IP address 10.32.76.1 for storage appliance 10.32.76.1 ... [14:18:58] Storage appliance login successful. [14:18:58] Collecting VMware and storage appliance configuration data. [14:18:58] Collecting LUN information ... [14:18:58] Attempting to collect LUN serial numbers for storage appliance 10.32.76.1 ... [14:18:58] Found LUN name /vol/esxfcp/rdm_windows1.lun, serial number: 50334877444a5430504b7672 [14:18:58] Found LUN name /vol/esxfcp/fcp_ds01.lun, serial number: 50334877444a5430484e6564 [14:18:58] Collecting datacenter information ... [14:18:58] Found 2 Datacenter(s). [14:18:58] Collecting host system information ... [14:19:05] Host system information collected. [14:19:05] Looking on host system rx3025-esx.qs.de for datastore na2026a_fcp_ds01 ... [14:19:05] Looking on host system rx3008-esx.qs.de for datastore na2026a_fcp_ds01 ... [14:19:05] Requested Datastore (na2026a_fcp_ds01) is available. [14:19:05] Saving virtual machine information for OK-fcp-w2k3-1. [14:19:05] Searching for matching disk name naa.60a9800050334877444a543 0484e6564 on storage appliance 10.32.76.1 ... [14:19:05] Checking host system rx3025-esx.qs.de ... [14:19:05] Name = naa.60a9800043346541434a543042797433, UUID = 43346541434a543042797433. [14:19:05] Checking host system rx3008-esx.qs.de ... [14:19:05] Name = naa.60a9800043346541434a5261736d6379, UUID = 43346541434a5261736d6379. [14:19:05] Name = naa.60a9800050334877444a5430504b7672, UUID = 50334877444a5430504b7672. [14:19:05] Name = naa.60a9800050334877444a5430484e6564, UUID = 50334877444a5430484e6564. [14:19:05] Found LUN with UUID 50334877444a5430484e6564, host 10.32.76.1 [14:19:05] Snapshot host: 10.32.76.1 [14:19:05] Snapshot path: /vol/esxfcp/fcp_ds01.lun
849
14.1
14
Ausfallsicherheit
[14:19:05] Checking to ensure 10.32.76.1 (for volume esxfcp) is in our list of storage appliances ... [14:19:05] Starting VIBE backup process. [14:19:05] Executing VIBE operations before backup. [14:19:05] Quiescing and snapshotting all VMs being backed up ... [14:19:05] Checking power state of VM OK-fcp-w2k3-1 ... [14:19:05] Checking snapshot capability of VM OK-fcp-w2k3-1 ... [14:19:05] Creating snapshot of VM OK-fcp-w2k3-1 (attempt #1) ... [14:19:09] Snapshot of VM OK-fcp-w2k3-1 successful. [14:19:09] Taking storage system snapshot(s). [14:19:09] Removing recent snapshot with ZAPI ... [14:19:09] Checking if snapshot VIBE_ds_snap.recent exists on esxfcp on storage appliance 10.32.76.1 ... [14:19:09] Snapshot VIBE_ds_snap.recent on esxfcp not found. [14:19:09] Recent snapshot VIBE_ds_snap.recent does not exist on esxfcp. [14:19:09] Taking recent snapshot with ZAPI ... [14:19:09] Taking snapshot VIBE_ds_snap.recent for esxfcp on storage appliance 10.32.76.1 ... [14:19:09] Running ZAPI snapshot-create 'volume' 'esxfcp' 'snapshot' 'VIBE_ds_snap.recent' ... [14:19:10] Snapshot created successfully. [14:19:10] Removing oldest snapshot with ZAPI ... [14:19:10] Checking if snapshot VIBE_ds_snap.7 exists on esxfcp on storage appliance 10.32.76.1 ... [14:19:10] Snapshot VIBE_ds_snap.7 on esxfcp not found. [14:19:10] Oldest snapshot VIBE_ds_snap.7 does not exist on esxfcp. [14:19:10] Rotating snapshots with ZAPI ... [14:19:10] Rotating snapshots named VIBE_ds_snap.# on esxfcp ... [14:19:10] Checking if snapshot VIBE_ds_ snap.6 exists on esxfcp on storage appliance 10.32.76.1 ... [14:19:10] Snapshot VIBE_ds_snap.6 on esxfcp not found. [14:19:10] Checking if snapshot VIBE_ds_snap.5 exists on esxfcp on storage appliance 10.32.76.1 ... [14:19:10] Snapshot VIBE_ds_snap.5 on esxfcp not found. [14:19:10] Checking if snapshot VIBE_ds_snap.4 exists on esxfcp on storage appliance 10.32.76.1 ... [14:19:10] Snapshot VIBE_ds_snap.4 on esxfcp not found. [14:19:10] Checking if snapshot VIBE_ds_snap.3 exists on esxfcp on storage appliance 10.32.76.1 ... [14:19:10] Snapshot VIBE_ds_snap.3 on esxfcp not found. [14:19:10] Checking if snapshot VIBE_ds_snap.2 exists on esxfcp on storage appliance 10.32.76.1 ... [14:19:10] Snapshot VIBE_ds_snap.2 on esxfcp not found. [14:19:10] Checking if snapshot VIBE_ds_snap.1 exists on esxfcp
850
Sicherung – Rücksicherung
on storage appliance 10.32.76.1 ... [14:19:10] Snapshot VIBE_ds_snap.1 on esxfcp not found. [14:19:10] Checking if snapshot VIBE_ds_snap.0 exists on esxfcp on storage appliance 10.32.76.1 ... [14:19:11] Snapshot VIBE_ds_snap.0 on esxfcp found. [14:19:11] Running ZAPI snapshot-rename 'volume' 'esxfcp' 'current-name' 'VIBE_ds_snap.0' 'new-name' 'VIBE_ds_snap.1' on storage appliance 10.32.76.1 ... [14:19:11] Removing oldest snapshot with ZAPI ... [14:19:11] Checking if snapshot VIBE_ds_snap.7 exists on esxfcp on storage appliance 10.32.76.1 ... [14:19:11] Snapshot VIBE_ds_snap.7 on esxfcp not found. [14:19:11] Oldest snapshot VIBE_ds_snap.7 does not exist on esxfcp. [14:19:11] Renaming most recent snapshot with ZAPI ... [14:19:11] Renaming snapshot VIBE_ds_snap.recent to VIBE_ds_snap.0 for esxfcp on storage appliance 10.32.76.1 ... [14:19:11] Checking if snapshot VIBE_ds_snap.recent exists on esxfcp on storage appliance 10.32.76.1 ... [14:19:11] Snapshot VIBE_ds_snap.recent on esxfcp found. [14:19:11] Running ZAPI snapshot-rename 'volume' 'esxfcp' 'current-name' 'VIBE_ds_snap.recent' 'new-name' 'VIBE_ds_snap.0' on storage appliance 10.32.76.1 ... [14:19:11] Snapshot rename completed successfully. [14:19:11] Executing VIBE operations after backup. [14:19:11] Removing snapshots for all VMs being backed up ... [14:19:11] Checking power state of VM OK-fcp-w2k3-1 ... [14:19:11] Checking snapshot capability of VM OK-fcp-w2k3-1 ... [14:19:11] Attempting to find snapshot 'VIBE_snap_20091112_141905' for VM OK-fcp-w2k3-1 ... [14:19:11] Removing snapshot 'VIBE_snap_20091112_141905' ... [14:19:13] Removal of VM snapshot for VM OK-fcp-w2k3-1 successful. [14:19:13] Command completed successfully. [14:19:13] Backup End Time: Thu Nov 12 14:19:13 2009 VMs Successfully Quiesced ------------------------...OK-fcp-w2k3-l VMs With Successful Snapshot Removal -----------------------------------...OK-fcp-w2k3-l Exiting with return code: 0
Der gesamte Prozess wird im Verzeichnis Report in einem Log-File für jeden Backup-Vorgang festgehalten.
851
14.1
14
Ausfallsicherheit
VIBE ermöglicht nach dem Backup auch eine Replikation per SnapMirror – anders als bei SMVI ist sogar eine Sicherung per SnapVault möglich. VIBE kann auch Restores durchführen, allerdings nur von gesamten VMs. Einzelne Dateien aus VMs lassen sich nicht wiederherstellen.
14.1.5 VMware Data Recovery Mit der Einführung der aktuellen Version des vSphere Servers hat VMware, sehr zur Überraschung von vielen Anwendern, eine eigene Datensicherungs-Appliance auf den Markt gebracht. Mit dem Softwarepaket VMware Data Recovery besteht die Möglichkeit, virtuelle Maschinen zu sichern und wiederherzustellen, ohne dass Sie weitere Datensicherungssoftware benötigen. Hier unterscheidet sich das Tool wesentlich von dem VCB-Server, der ja zur Arbeit eine Anbindung an eine bestehende Datensicherungslandschaft benötigt. Die Installation bzw. Konfiguration von VMware Data Recovery haben wir ja bereits in Kapitel 6 und Kapitel 11 beschrieben. Auch hierbei handelt es sich, in der derzeitigen Version, um ein image-basiertes Sicherungssystem. Die zu sichernden virtuellen Server werden dedupliziert auf ein SAN, NAS, CIFS oder einen lokalen Storage gesichert. Die Funktionsweise zeigt Abbildung 14.13.
Abbildung 14.13
Sicherung einer VM mit VMware Data Recovery
Ähnlich dem VCB wird vor dem Beginn der Datensicherung ein Snapshot der zu sichernden VM angefertigt (1). Danach sorgt die Data-Recovery-Appliance dafür,
852
Sicherung – Rücksicherung
dass die virtuelle Maschine auf ein unterstütztes Ziel-File-System weggeschrieben wird. Vor dem Schreibvorgang wird kontrolliert, ob identische Daten schon einmal geschrieben wurden. Ist das der Fall, wird lediglich ein Zeiger auf die bestehenden Daten angelegt, ohne die Daten reell noch einmal wegzuschreiben (2). So wird der benötigte Plattenplatz für die Datensicherung stark reduziert. Ist die Datensicherung abgeschlossen, wird der Snapshot aufgelöst und die in der Zwischenzeit geänderten Daten werden eingepflegt (3). Für die Rücksicherung ist ebenfalls die Appliance zuständig. Abbildung 14.14 zeigt den Ablauf der Rücksicherung.
Abbildung 14.14
Rücksicherung einer VM mit VMware Data Recovery
Für den Fall, dass eine virtuelle Maschine ausfällt (1), stoßen Sie über das DataRecovery-Plug-in auf dem vCenter-Server die Rücksicherung an. Als Erstes wählen Sie das Image aus, das zurückgesichert werden soll (2). Im folgenden Schritt startet der Rücksicherungsvorgang, und die defekte Maschine wird wiederhergestellt (3). Dabei haben Sie die Wahl, in welcher Form Sie die Rücksicherung durchführen möchten. Der eine Weg führt zur Ersetzung der originalen Maschine, das heißt, das Original wird gelöscht und durch die Sicherung ersetzt. Für eine detaillierte Fehleranalyse können Sie aus einer Sicherung auch einen neuen Server erstellen. Durch eine gezielte friedliche Koexistenz stellen Sie zum einen den Service dem Kunden wieder zur Verfügung und können zum anderen auf dem defekten System eine Fehleranalyse betreiben. Derzeit gibt es noch keine unterstützte Möglichkeit, einzelne Files aus einer vorhandenen Data-Recovery-Sicherung in eine virtuelle Maschine zurückzusichern. VMware arbeitet aber daran und bietet zurzeit ein Tool (File Level Restore) an, das eine solche Rücksicherung ermöglicht. Das Tool unterstützt nur Windows-
853
14.1
14
Ausfallsicherheit
Betriebssysteme. Sie rufen es in der betroffenen VM auf und können dann, nach einer Auswahl, Sicherungsdateien mounten. Jetzt können Sie mit dem Explorer nach den Dateien suchen, die zurückgesichert werden sollen. Wie aber schon gesagt, gibt es für dieses Tool noch keinen offiziellen Support.
14.2
Cluster-Konfiguration
Die Firma VMware unterstützt den Einsatz von Microsoft Cluster Service (MSCS) unter vSphere. Wer sich jetzt fragt, wozu eigentlich das Ganze, VMware bietet ja auch ein HA für den Host-Ausfall, dem sei gesagt, dass es durchaus Sinn ergibt, einen MSCS-Cluster in einer virtuellen Umgebung aufzubauen. In Kundenumgebungen ist es nicht selten, dass zwar für ein produktives System ein Cluster eingesetzt wird, aber für die Entwicklung werden vermeintlich Kosten gespart, und es wird ein Stand-alone-Server verwendet. Das muss nicht sein, denn unter VMware ist eine solche Landschaft einfach und kostengünstig abbildbar. Ein weiteres mögliches Szenario ist der Test für den Update einer Cluster-Landschaft. Abseits der produktiven Umgebung können Sie in aller Ruhe die Reihenfolge für ein Update erarbeiten, ohne die Verfügbarkeit der produktiven Kundensysteme zu beeinflussen. Für die Abbildung eines Clusters gibt es grundsätzlich drei Möglichkeiten: Zum Ersten können Sie den Cluster mit zwei virtuellen Maschinen auf einem Host aufbauen. Alternativ verteilen Sie die Cluster-Knoten auf mehrere Hosts. Abschließend gibt es auch Support für einen Cluster mit einem physischen und einem virtuellen Knoten. Im Folgenden werden wir einzeln auf die verschiedenen Konfigurationsmöglichkeiten eingehen. Zuvor möchten wir aber noch die Voraussetzungen für den Einsatz von MSCS auf virtuellen Servern erläutern.
14.2.1
Voraussetzungen für Microsoft Cluster Service
Damit Sie den Cluster unter VMware vSphere unterstützt aufbauen können, müssen soft- und hardwareseitig diverse Voraussetzungen erfüllt sein. Tabelle 14.2 listet die Bedingungen für den Einsatz auf. Komponente
Bedingung
Betriebssystem
Windows 2000 Service Pack 4 Windows 2003 Service Pack 2 Windows 2008
Tabelle 14.2
854
Voraussetzungen MSCS
Cluster-Konfiguration
Komponente
Bedingung
Virtual SCSI-Adapter
LSI Logic Parallel for Windows 2000 Server LSI Logic Parallel for Windows Server 2003 LSI Logic SAS for Windows Server 2008
Festplattenformat
Anlegen der Festplatten mit der Option eagerzeroedthick, das heißt, bei der Anlage wird der gesamte Festplattenplatz allokiert und mit Nullen beschrieben.
Virtual NIC
Standardadapter für alle Betriebssysteme
Festplatten- und Netzwerkkonfiguration
Zuerst sind die Netzwerkadapter und anschließend die Festplatten hinzuzufügen.
Anzahl Knoten
Es werden maximal zwei Knoten unterstützt.
I/O-Timeout
Der Wert des Registry-Keys: HKEY_LOCAL_MACHINE\ System\CurrentControlSet \Services\Disk\TimeOutValue ist auf mindestens 60 zu
setzen. Bei der Neuerstellung des Clusters wird der Wert automatisch zurückgesetzt. NTP-Server
Die Zeitsynchronisierung über die VMware Tools deaktivieren und nur die Standarddomänen-Synchronisation nutzen.
Domäne
Beide Knoten müssen Mitglied einer Windows-Domäne sein.
Tabelle 14.2
Voraussetzungen MSCS (Forts.)
Zusätzlich zu diesen Bedingungen müssen Sie bei der Anlage der Festplatten ein Augenmerk darauf richten, wie Sie sie einrichten und wie Sie sie zur Verfügung stellen. Auch hier geben wir Ihnen in Tabelle 14.3 Aufschluss darüber, was unterstützt ist(). Festplattentyp
Cluster auf einem Host
Cluster auf mehreren Hosts
physischer/virtueller Cluster
virtuelle Festplatte im VMFS
yes
no
no
Raw-Device-Mapping RDM (virtual compatibility mode)
yes
yes
no
Raw-Device-Mapping (physical compatibility mode)
no
yes
yes
Tabelle 14.3
Kompatibilität der einzelnen Festplattentypen
855
14.2
14
Ausfallsicherheit
Es ist selbstverständlich möglich, mit virtuellen Maschinen, die vom SAN gebootet werden, einen Cluster aufzubauen. Sie müssen jedoch bedenken, dass solche Landschaften extrem komplex sind und die Fehlersuche sich ebenfalls nicht einfach gestaltet. Der Microsoft Cluster Service selbst hat noch ein paar Einschränkungen, die den Einsatz verbieten. Diese Grenzen sind in der folgenden Aufzählung gelistet. 왘
Soll der Cluster unter der Version ESX/ESXi 4.x erfolgen, müssen Sie die Hardwareversion 7 einsetzen.
왘
Alle zum Einsatz kommenden Hosts müssen dieselbe Version des HostBetriebssystems haben. Gemischte Umgebungen sind nicht unterstützt.
왘
Cluster dürfen weder in HA- noch in DRS-Umgebungen eingesetzt werden.
왘
VMware Fault-Tolerance ist nicht unterstützt.
왘
Clustering ist auf iSCSI- und NFS-Platten nicht erlaubt.
왘
VMotion von Cluster-Knoten wird nicht unterstützt.
왘
Der Storage darf nicht mit Round-Robin-Multipathing konfiguriert sein.
왘
N-Port-ID-Virtualisierung (NPIV) ist nicht erlaubt.
왘
Die Nutzung einer Multipathing-Software im Gast ist nicht legitim.
왘
Die Bootplatte der VM darf nicht auf einem iSCSI-Device liegen.
Möchten Sie ein Cluster Continuous Replication Environment für Exchange aufsetzen, ist das grundsätzlich möglich. Achten Sie darauf, dass die Cluster-Knoten virtuell aufgebaut werden. Als Festplatten sollten Sie RDMs im physischen Modus nutzen. Die Installation der Cluster Services für die drei verschiedenen Möglichkeiten beschreiben wir im folgenden Abschnitt 14.2.1, »Cluster-Konfiguration auf einem Host«. In den Abschnitten nach den genannten gehen wir nur noch auf die lösungsspezifischen Dinge ein.
14.2.2 Cluster-Konfiguration auf einem Host Zur Veranschaulichung der Cluster-Konfiguration auf einem Host dient Abbildung 14.15. Hier ist schön zu sehen, dass beide betroffenen VMs auf einem Host liegen, die Daten aber nicht alle auf einer LUN liegen müssen. Die einfachste Variante des MSCS in einer virtuellen Infrastruktur ist der Cluster auf einem Host. Als Erstes werden die virtuellen Maschinen mit ihren lokalen, nicht gemeinsam genutzten Ressourcen angelegt.
856
Cluster-Konfiguration
Node 1
Node 2 Heartbeat
Cluster
Public
OS
Network
Cluster OS
VMware ESX Server
Abbildung 14.15
Microsoft Cluster Service auf einem ESX-Host
Erstellen Sie nun die beiden Cluster-Knoten, und nutzen Sie dabei eine »typische« VM-Konfiguration. Zum Einsatz sollte ein unterstütztes Betriebssystem kommen, das selbstverständlich bei der Anlage der VM eingestellt werden muss. Beim Einrichten der Festplatte für das Betriebssystem ist es wichtig, die Option Support clustering features such as Fault Tolerance zu aktivieren (Abbildung 14.16). Hinter dieser Alternative verbirgt sich die Option eagerzeroedthick. Der Speicherplatz der Disk wird direkt reserviert und mit Nullen vollgeschrieben.
Abbildung 14.16
Konfiguration der lokalen Festplatte des Cluster-Knotens
857
14.2
14
Ausfallsicherheit
Bei der Konfiguration des Clusters werden mindestens zwei Netzwerkkarten benötigt. Die zusätzliche Karte wird dem Server hinzugefügt. Achten Sie darauf, dass Sie für die zweite Karte dieselbe »Hardware« nutzen, die auch bei der ersten Karte zum Einsatz kommt. Im Beispiel ist eine Netzwerkkarte für den internen Heartbeat-Traffic eingerichtet und eine zweite für den Client-Zugriff. Es ist ebenfalls zu sehen, dass die VM eine aktuelle Hardwareversion hat (Abbildung 14.17).
Abbildung 14.17
Konfiguration eines Cluster-Knotens
Den zweiten Cluster-Knoten legen Sie mit der gleichen Konfiguration an. Sind die Server-Hüllen bereitgestellt, installieren Sie auf beiden Systemen das Betriebssystem und bringen es auf das aktuelle Patch-Level. Den Heartbeat konfigurieren Sie in ein privates Netzwerk ohne Gateway, und deaktivieren Sie NetBIOS over TCP/IP. Bevor Sie mit der Einrichtung der gemeinsam genutzten Festplatten beginnen, sollten Sie beide Server in die Domäne aufnehmen. Jetzt richten Sie eine gemeinsame Festplatte ein. Beginnen Sie mit den Arbeiten auf dem ersten Knoten. Über die Einstellungen des ersten Cluster-Knotens fügen Sie eine neue Festplatte hinzu. Die Festplatte sollte in demselben Verzeichnis liegen wie die Files der virtuellen Maschine. Auch in diesem Fall ist die Option zu setzen, dass es sich um eine Cluster-Festplatte handelt (Abbildung 14.18).
858
Cluster-Konfiguration
Abbildung 14.18
Anlegen einer gemeinsamen Festplatte auf dem ersten Knoten
Unter den Advanced Options geben Sie bei dem Abschnitt Virtual Device Node die SCSI-ID für das neue Festplatten-Device an. Die erste Festplatte wird eine ID mit einer führenden Null haben. Aus diesem Grund muss bei der zweiten Festplatte die ID eine andere führende Ziffer haben. Was passiert nun im Hintergrund bei der Änderung der Einstellung? Die erste Ziffer gibt an, über welchen SCSI-Adapter die Festplatte bedient wird. Durch die Auswahl einer anderen führenden Ziffer bei der SCSI-ID wird dem System ein zusätzlicher SCSI-FestplattenController hinzugefügt. Für die weitere Vorgehensweise ist das enorm wichtig. Es wäre sonst nicht möglich, dass zwei virtuelle Systeme auf eine Festplatte zugreifen könnten (Abbildung 14.19).
Abbildung 14.19
Auswahl der SCSI-ID
859
14.2
14
Ausfallsicherheit
Die SCSI-ID setzt sich wie folgt zusammen: :<SCSI Gerätenummer>. Nun ist die neue Festplatte in der Konfiguration der VM sichtbar. Über Change Type bestimmen Sie den SCSI-Controller-Typ (Abbildung 14.20). Die Auswahl erfolgt nach der Auswertung der Informationen in Tabelle 14.4. Betriebssystem
Controller-Typ
Windows 2000 Server
LSI Logic Parallel
Windows Server 2003
LSI Logic Parallel
Windows Server 2008
LSI Logic SAS
Tabelle 14.4
Abhängigkeit zwischen Betriebssystem und Festplatten-Controller
Damit der Zugriff von zwei virtuellen Maschinen auf eine gemeinsame Festplatte erfolgen kann, ist der Modus für SCSI Bus Sharing zu konfigurieren. In diesem speziellen Fall wählen wir virtuell. So können zwei VMs direkt auf ein vmdk-File zugreifen, solange sich die zugreifenden virtuellen Maschinen auf einem Host befinden (Abbildung 14.20).
Abbildung 14.20
Konfiguration des SCSI-Bus-Sharings
Die hardwaretechnischen Arbeiten auf dem ersten Knoten sind nun abgeschlossen. Jetzt können Sie mit der Einrichtung des Clusters im Betriebssystem beginnen. Eine funktionierende DNS-Auflösung ist für eine einwandfreie Installation unbedingt erforderlich. Formatieren Sie die zukünftigen gemeinsamen Festplatten in der Computerverwaltung, und versehen Sie sie mit Laufwerksbuchstaben. Stoßen Sie über den Menüpunkt Start 폷 Administrative Tools 폷 Cluster Administrator die Installa-
860
Cluster-Konfiguration
tion des Microsoft-Clusters an. Es startet ein Wizard für die Einrichtung des Clusters. Zu Beginn wird die Angabe der Windows-Domäne und des Cluster-Namens erwartet. Im folgenden Dialog geben Sie den Computernamen des ersten ClusterKnotens an. Jetzt überprüft die Software, ob alle Voraussetzungen für die endgültige Installation des Clusters erfüllt sind (Abbildung 14.21).
Abbildung 14.21
Check der Cluster-Konfiguration
Der Wizard erfragt nun die IP-Adresse für den Cluster. Einen Domänen-Account für den Start des Cluster-Dienstes erwartet die Installationsroutine einen Schritt später. Die übliche Installationszusammenfassung wird angezeigt, bevor Sie den eigentlichen Installationsvorgang starten. An dieser Stelle können Sie auch auswählen, auf welcher Festplatte die Quorumdisk installiert werden soll (Abbildung 14.22).
Abbildung 14.22
Auswahl der Quorumdisk
Nach Abschluss der Arbeiten können Sie das Installations-Log einsehen. Beenden Sie den Wizard, stellt sich der Cluster im Cluster Administrator dar (Abbildung 14.23). Nachdem der erste Cluster-Knoten nun vollständig konfiguriert und eingerichtet ist, nehmen wir uns den zweiten virtuellen Cluster-Knoten vor. Auch hier ist eine zweite Festplatte mit dem System zu verbinden. Der Unterschied besteht darin, dass keine neue Festplatte angelegt, sondern eine bereits vorhandene mit der
861
14.2
14
Ausfallsicherheit
Abbildung 14.23
Cluster nach der Installation des ersten Knotens
zweiten VM verbunden wird. Es handelt sich um die Festplatte, die beim ClusterNode1 an den zweiten Festplatten-Controller gehängt wurde. Geben Sie der Festplatte die gleiche ID wie auf dem ersten Server. Jetzt ist der Cluster Service auf dem zweiten Cluster-Knoten bereitzustellen. Auch starten Sie über den Menüpunkt Start 폷 Administrative Tools 폷 Cluster Administrator die Aufnahme des zweiten Knotens in den Cluster-Verbund. Für die Aufnahme eines zweiten Knotens gibt es einen eigenen Auswahlpunkt. Hier wird auch die Eingabe des Namens des Clusters erwartet. Jetzt wird, wie bei der Initialinstallation, geprüft, ob alle Voraussetzungen für die Aufnahme des Knotens erfüllt sind. Geben Sie im nächsten Dialogfenster das Passwort des angezeigten Accounts ein, und starten Sie mit zwei weiteren Klicks die Installation. Jetzt ist der Cluster erfolgreich installiert (Abbildung 14.24).
Abbildung 14.24
862
Erfolgreich installierter Cluster mit zwei Knoten
Cluster-Konfiguration
Die Arbeiten sind jetzt so weit abgeschlossen, dass Sie die Applikation installieren können.
14.2.3 Cluster-Konfiguration über mehrere Hosts Im Gegensatz zur Konfiguration in Abschnitt 14.2.1 liegen die Cluster-Daten der beiden Knoten nicht auf einer virtuellen Festplatte, sondern auf einer eigenen dedizierten LUN. Beide Cluster-Mitglieder greifen direkt auf den Storage zu. Das File-System wird direkt über das Betriebssystem des Clusters angelegt. Alle anderen virtuellen Maschinen können die Raw LUN nicht sehen (Abbildung 14.25). Node 1 Cluster OS
Node 2 Heartbeat
Cluster
Public Network
OS
VMware ESX
VMware ESX
Server1
Server 2
Abbildung 14.25
MS mit VMs über zwei Hosts verteilt
Es ist möglich und wird auch unterstützt, den zweiten Knoten eines Clusters über unterschiedliche Hosts zur Verfügung zu stellen. Die Konfiguration und Bereitstellung der beiden Grundmaschinen ist mit den im vorherigen Abschnitt beschriebenen Schritten absolut identisch. Die Arbeiten unterscheiden sich lediglich in der Anlage der gemeinsam genutzten (shared) Festplatten. In diesem Fall können Sie keine virtuelle Festplatte nutzen, sondern müssen sogenanntes RawDevice-Mapping verwenden. Das bedeutet, dass Sie eine SAN-LUN direkt mit der virtuellen Maschine verbinden. Der SCSI-Bus-Sharing-Modus ist auf Physical zu setzen. Ist diese Platte im Betriebssystem sichtbar, richten Sie das File-System ein. Jetzt stellen Sie den Cluster bereit, was sich von den Arbeitsschritten, die wir schon beschrieben haben, in keiner Weise unterscheidet. Ist der erste Cluster-Knoten betriebsbereit, fügen Sie den zweiten Knoten dem Cluster hinzu. Hierbei gibt es unter Umständen Herausforderungen, die recht einfach zu lösen sind. Das Hinzufügen des zweiten Knotens kann zu Problemen führen, wenn das Raw-Device auf
863
14.2
14
Ausfallsicherheit
beiden Servern nicht dieselbe ID hat. Das ist durchaus möglich und auch unterstützt. Es kann sein, dass der Knoten sich nicht hinzufügen lässt. In diesem Fall klicken Sie beim Hinzufügen des zweiten Knotens im Auswahlfenster des Computers den Advanced-Button (Abbildung 14.26) und deaktivieren die Option für die Verifikation des Storages (Abbildung 14.27).
Abbildung 14.26
Aufruf der Advanced-Option
Abbildung 14.27
Aktivierung der Advanced (minimum) configuration
Die weitere Vorgehensweise gestaltet sich nun wie bei der vorherigen Variante.
14.2.4 Cluster-Konfiguration zwischen physischem und virtuellem Knoten Diese Variante unterscheidet sich nur geringfügig von der Konfiguration in Abschnitt 14.2.2, denn eigentlich liegen die beiden Cluster-Knoten auf verschiedenen Hosts (Abbildung 14.28). Auch wenn der eine Host ein dedizierter physischer Server ist, so liegt der Unterschied nur in der Bereitstellungsreihenfolge. Der Unterschied besteht darin, dass der erste Knoten ein physischer ist.
864
Cluster-Konfiguration
Node 1
Node 2 Heartbeat
Cluster
Cluster
Public OS
Network
OS VMware ESX
Server1
Server 2
Abbildung 14.28
Physischer/virtueller MS-Cluster
Die Einstellungen in der VM müssen Sie anders als in der zuletzt beschriebenen Variante nicht anpassen. Auch hier wird ein Raw-Device-Mapping mit physisch gemeinsam genutzten Platten eingesetzt, aber die Reihenfolge ist eine andere. Nachdem Sie auf beiden Servern das passende freigegebene Betriebssystem installiert haben, fahren Sie mit den Arbeiten auf dem virtuellen Knoten fort. Den physischen Knoten nehmen Sie erst im zweiten Schritt in den Cluster auf. Welchen Vorteil bringt nun die Nutzung eines physischen/virtuellen Clusters? In Abbildung 14.29 haben wir das einmal veranschaulicht. Schauen Sie sich an, welche Cluster-Typen in der Regel in Betrieb genommen werden, dann fällt auf, dass meistens active/passive-Cluster aufgesetzt werden. Das bedeutet: Primär ist ein Knoten aktiv, und der andere wartet darauf, dass der erste den Dienst versagt. Node 1
Node 1
Cluster
Cluster
Cluster
OS
OS
OS
Server 1
Server 2
Server x
Node 2
Node 2
Cluster
Cluster
Cluster
OS
OS
OS
te
Cl
us
us te rx
r1
Node 2
Cl
Cluster 2
Node 1
VMware ESX Server
Abbildung 14.29
vSphere-Host mit mehreren MS-Cluster-Knoten
865
14.2
14
Ausfallsicherheit
Das führt dazu, dass die Kosten für den Cluster recht hoch sind. Es werden zwei Server gekauft, damit ein Dienst zur Verfügung gestellt werden kann. Jetzt kommt der Vorteil der Virtualisierung voll zum Tragen. Kommen mehrere Cluster in der Firma zum Einsatz, dann werden die primär aktiven Systeme als physische Maschine abgebildet, und die zweiten Cluster-Knoten werden virtuell aufgebaut. Der Vorteil liegt auf der Hand: Die Maschine, die die virtuellen Systeme aufnimmt, ist zwar etwas größer zu dimensionieren, aber man macht sich den Umstand zunutze, wie unwahrscheinlich es ist, dass alle Cluster gleichzeitig ausfallen. So übernimmt der virtuelle Host die Arbeit im Falle eines Ausfalls oder bei Wartungsaufgaben. Auf diese Weise können Sie die zu nutzenden Ressourcen im Rechenzentrum reduzieren. Sie sparen Stellplatz, Netzwerkports, SAN-Ports, Strom und Klimabedarf. Dem gegenüber stehen zwar die Lizenzkosten von VMware, aber das rechnet sich recht schnell.
14.3
Virtual Machine Monitoring
Seit der Version 3.5 der Virtual Infrastructure bietet VMware eine Funktion zur Überprüfung der virtuellen Maschinen auf Reaktion. Wann kann die Funktion genutzt werden? Was genau bedeutet die Funktion? Das Virtual Machine Monitoring ist eine Unterfunktion des VMware HA, was heißt, dass Sie die Funktion nur in einem aktiven HA-Cluster nutzen können. Erst wenn die HA-Funktionalität in einem Cluster aktiviert ist, steht die Funktion zur Verfügung (Abbildung 14.30).
Abbildung 14.30
866
Virtual Machine Monitoring
Virtual Machine Monitoring
Die Funktion ist eine Ergänzung zu dem schon bekannten Heartbeat zur virtuellen Maschine. Der Heartbeat kommuniziert mit den VMware Tools einer virtuellen Maschine, um zu kontrollieren, dass sie noch einwandfrei arbeitet. Antworten die VMware Tools ordnungsgemäß, ist für den Host alles in Ordnung. Weitere Tests werden nicht durchgeführt. An dieser Stelle greift das Virtual Machine Monitoring ein. Dieser Zusatz überwacht zusätzlich die Aktivitäten der Festplatte und der Netzwerkkarte. Zeigen sich bei der Auswertung der beiden Funktionen Unregelmäßigkeiten, wird die virtuelle Maschine neu gestartet. Die Art und Weise, wie die Maschine rebootet, können Sie selbst definieren (Abbildung 14.31). Zuallererst aktivieren Sie das VM Monitoring oben im Fenster. Zwei Optionen bieten sich Ihnen zur Auswahl: Entweder stellen Sie alle Kontrollwerte manuell ein, oder Sie greifen auf die Parameter zurück, die Sie über den Schieberegler regulieren können.
Abbildung 14.31
Konfiguration des VMM
Mit dem Regler lassen sich drei mögliche Parametrierungen einstellen.
867
14.3
14
Ausfallsicherheit
MonitoFailure ring sensi- interval tivity
Minimum uptime Maximum per VM resets
Maximum resets time window
low
120 Sekunden
7 Minuten
3
7 Tage
middle
60 Sekunden
4 Minuten
3
1 Tag
high
30 Sekunden
2 Minuten
3
1 Stunde
Tabelle 14.5
Überwachungsparameter des VMM
Das failure interval gibt an, wie lange die Bedingung erfüllt sein muss, bevor ein Fehler angezeigt wird. Die Minimum uptime bezeichnet ein Zeitintervall, das nach dem Start der VM abläuft, bis das Überwachungstaktsignal erzwungen wird. Erst ab diesem Zeitpunkt wird die VM wieder überwacht. Über das Maximum resets time window legen Sie fest, wie oft eine virtuelle Maschine maximal neu gestartet werden darf. Das gültige Zeitintervall für die Messung der Anzahl der Reboots ist die Einstellung, die sich hinter dem Wert Maximum resets time window verbirgt. Der Neustart des virtuellen Servers im Falle eines Fehlers erfolgt automatisch, wenn die Option in der Konfiguration des VMMs aktiviert wurde. Die Optionen des Virtual Machine Monitors sind jetzt definiert. Bei den genannten Regeln handelt es sich um die cluster-weite Standardeinstellung für den gesamten HA-Cluster. Diese Einstellung gilt standardmäßig für alle virtuellen Maschinen des Clusters. Sollen einige der virtuellen Server anders eingestellt sein, konfigurieren Sie das einzeln für jede VM im unteren Drittel des Einstellungsfensters. Wählen Sie einfach einen virtuellen Server aus, und passen Sie dessen Parameter an. Hier treffen Sie wieder auf die bereits bekannten Parameter low, medium, high und custom. Über den Wert none deaktivieren Sie die Überwachungsfunktion für eine VM. Wir raten Ihnen: Versuchen Sie, mit so wenig granularen Einstellungen auszukommen wie möglich. Es geht sonst einfach die Übersichtlichkeit verloren. Definieren Sie eine Custom-Einstellung, und versuchen Sie dann, mit den vier Kategorien (low, medium, high und custom) zurechtzukommen, die Sie danach zur Verfügung haben. Der Vollständigkeit halber möchten wir noch erwähnen, dass Sie die Werte für den Cluster auch anders manipulieren können, indem Sie im Einstellungsfenster unter VMware HA 폷 Advanced Options die Werte für die Einstellungen manuell eintragen.
868
Fault-Tolerance
Lassen Sie uns die Werte in Tabelle 14.6 kurz erläutern. Option
Beschreibung
clusterSettings
Sollen die Cluster-Einstellungen oder die Einstellungen Cluster der VM genutzt werden?
enabled
Ist der Service aktiviert?
failureInterval
Definiert, wie lange eine VM maximal nicht antworten 30 sek. darf, bevor sie auf fehlerhaft gesetzt wird.
maxFailures
Anzahl der Fehler, die im maxFailureWindow auftre- 3 ten dürfen, bevor die Überwachung eingestellt wird
maxFailureWindow
Anzahl von Sekunden, in denen maxFailure auftreten 1 sek. darf, bevor die Überwachung eingestellt wird
minUpTime
Zeit in Sekunden, die der Server benötigt, um neu zu 120 sek. starten. Für dieses Zeitintervall wird die Überwachung ausgesetzt.
Tabelle 14.6
Standard
nein
Virtual Machine Monitoring Advanced Options
Mit dem VMM können Fehlfunktionen in einem virtuellen Server abgefangen werden. Als Beispiel sei hier der allseits bekannte Bluescreen genannt. Ein solcher Missstand ließe sich mit dem VMM beheben. Es besteht durchaus die Option, mit dieser Funktion die Verfügbarkeit von virtuellen Maschinen zu erhöhen. Kommt eine Fehlfunktion in einer VM öfter vor, so dass VMM einen Systemneustart durchführt, sollten Sie genau analysieren, warum das so ist. Sie können davon ausgehen, dass in diesem Fall ein Fehler in der VM vorliegt, der selbstverständlich behoben werden muss. Die Zuverlässigkeit der Funktion lässt sich im Grunde genommen sehr einfach testen: Halten Sie einfach die VMware Tools im laufenden Betrieb an. Die Verbindung des Taktsignals reißt ab, und die Maschine wird nach dem festgesetzten Intervall neu gestartet.
14.4
Fault-Tolerance
Fault-Tolerance ist eine neue Technologie von VMware, die mit der Version vSphere neu eingeführt wurde. Sie dient zur unterbrechungsfreien Bereitstellung eines Server-Dienstes. Die Funktionsweise und die Voraussetzungen von VMware Fault-Tolerance werden in Kapitel 4, »Cluster«, näher beschrieben.
869
14.4
Während man mit dem Schutz der Windows-, Linux- oder Solaris-Gastbetriebssysteme meist viel Erfahrung im Sicherheitsumfeld gesammelt hat und über genügend Drittherstellersoftware verfügt, befindet sich die Sicherheitsbranche im VMware-Umfeld noch im Aufbau.
15
Sicherheit Autor dieses Kapitels ist Dennis Zimmer, icomasoft AG, [email protected]
Obwohl vSphere zum größten Teil über den vSphere-Client bedient werden kann, sind viele Sicherheitseinstellungen nur über die Service Console machbar. Daher wird in diesem Kapitel auch ein kleiner Schwenk in Richtung Kommandozeile notwendig sein. Da von der Service Console die Rede ist, ist es natürlich auch so, dass viele Einstellungen und Einstellungsmöglichkeiten nur den ESXund nicht den ESXi-Server betreffen, da dieser keine umfangreiche Service Console hat. Allerdings sollten Sie bei ESXi den SSH-Zugang nicht aktivieren und auch den Lockdown-Mode anschalten, damit kein lokaler Zugriff mehr möglich ist. Die Service Console ist die wesentliche Schwachstelle des ESX-Servers, da hinter ihr ein Red Hat Enterprise Linux 5 aus dem Netzwerk erreichbar ist. Die meisten der Red-Hat-Sicherheitskonfigurationen und auch -Schwachstellen betreffen daher auch die Service Console des ESX-Servers, was an der deutlichen Mehrzahl an Patches gegenüber der ESXi-Variante leicht zu erkennen ist. Dies bedeutet aber auch, dass viele Einstellungsmöglichkeiten wie beispielsweise die Nutzung von TCP-Wrappers nicht möglich sind. Daher empfehlen wir bei Nutzung von ESXi hauptsächlich, dessen Managementadapter in ein geschütztes Netzwerk zu stellen, ein sehr starkes root-Passwort zu wählen und mit den HostProfiles zu arbeiten, um die Konfiguration sicherzustellen. VMware sichert zwar bereits nach der Installation viele offensichtliche Schwachstellen ab, trotzdem gibt es einige Aspekte zu beachten.
871
15
Sicherheit
Wichtig Installieren Sie in der Service Console keine Software, die nicht unbedingt notwendig ist. Ausnahmen stellen Backup-Agenten und Hardwaremanagement-Agenten dar, obwohl diese zumeist abgelöst und auch über die VMware-API funktionieren. Sonstige Linux-Programme oder sogar -Dienste haben auf der Service Console nichts zu suchen und können Sicherheitsrisiken und Performance-Probleme zur Folge haben.
15.1
Service-Console-Netzwerk
Die erste Schutzmaßnahme, um die Service-Console-Zugriffe einzudämmen, besteht darin, die Netzwerkkarte(n) in ein abgeschottetes Managementnetzwerk zu stecken. Dieses Managementnetzwerk sollte komplett physikalisch oder durch die Nutzung von VLANs vom »Produktiv-LAN« und vor allem von halböffentlichen (DMZ) oder öffentlichen Netzwerken abgeschottet sein. Damit ist der wichtigste Schritt getan, um unerlaubte Zugriffe aus dem internen oder externen Netzwerk zu verhindern.
15.2
VMware ESX 4i
VMware ESX 4i verfügt nicht über die Service Console eines ESX 4, wodurch viele Sicherheitsaspekte entfallen. Allerdings ist das von ESX 4i genutzte Managementnetzwerk wie das ServiceConsole-Netzwerk zu betrachten, das heißt, es sollte in einem abgeschotteten LAN/VLAN angeschlossen sein. Unter ESX 4i ist kein SSH-Zugriff, sondern nur ein Zugriff über die API möglich.
15.3
root-Zugriff
In einem Linux-System bedeutet root-Zugriff die komplette Verwaltung aller Dienste und Dateien. Daher ist es von enormer Bedeutung, den root-Zugriff möglichst eingeschränkt zu halten und vor allem einen unautorisierten Zugriff unter allen Umständen zu verhindern. Eine Anmeldung per Benutzer-Account mit Standardberechtigung und Wechsel zu root bei Bedarf wird empfohlen. Die definitiv wichtigste Maßnahme ist immer die Wahl eines komplizierten Kennworts. Außerdem sollten Sie das Kennwort in regelmäßigen Abständen ändern.
872
root-Zugriff
Wichtig Die Benutzer root und vpxuser und die Gruppe root dürfen nicht gelöscht werden, da sonst Zugriffsprobleme durch den VI Client und auch ESX-eigene Prozesse vorprogrammiert sind. Außerdem sollten Sie den Benutzer vpxuser und dessen Kennwort nicht anpassen, da dieser Benutzer vom vCenter genutzt und verwaltet wird.
15.3.1
su, sudo
su (»switch user«) dient dazu, zwischen Benutzerkonten zu wechseln. Nach der
Anmeldung als »normaler« Benutzer können Sie durch su – root oder einfach su zum root-Benutzer umschalten. sudo führt einen einzelnen Befehl als rootBenutzer aus, z. B. sudo cat /etc/shadow. Der sudo-Befehl ermöglicht einen höheren Grad an Flexibilität. So können z. B. nur Benutzer, die in der Konfigurationsdatei /etc/sudoers aufgeführt sind, den Befehl sudo ausführen. Dieser Befehl wird dann in der Shell des Benutzers ausgeführt und nicht in der root-Shell. Dies bedeutet, dass die root-Shell vollständig deaktiviert werden kann. Bei Verwendung des sudo-Befehls wird die erfolgreiche Authentifizierung in die Datei /var/log/messages (inklusive des ausgeführten Befehls) und der Benutzername in die Datei /var/log/secure geschrieben. Der Vorteil von sudo ist, dass einem Benutzer kein root-Kennwort mitgeteilt werden muss, sondern dieser mit seinem eigenen Benutzernamen und Kennwort Zugriff hat. Ein weiterer wichtiger Aspekt ist, dass Sie die Befehle, die durch sudo als root-Benutzer ausgeführt werden dürfen, in der /etc/sudoers einschränken können.
15.3.2 wheel-Gruppe Um nicht jedem Benutzer das Recht zu geben, zum Benutzer root zu wechseln, wird die wheel-Gruppe eingesetzt. In dieser Gruppe müssen alle Benutzer Mitglied sein, denen su erlaubt werden soll. Um Benutzer in der wheel-Gruppe einzutragen, verwenden Sie den Befehl usermod: usermod -G wheel Benutzer usermod -G wheel dennis
Danach müssen Sie den su-Befehl anpassen, um nur root und die wheel-Gruppe zu berechtigen:
873
15.3
15
Sicherheit
chgrp wheel /bin/su chmod 4750 /bin/su
Ab jetzt können Benutzer nur noch bei Mitgliedschaft in der wheel-Gruppe mit su in das root-Level wechseln. Berechtigungsvergabe Falls Sie bei der Berechtigungsvergabe aus Versehen lediglich eine dreistellige Nummer bei chmod angegeben haben, wird das suid-Bit gelöscht, das dem Programm su überhaupt erst den root-Wechsel erlaubt. Danach funktioniert su nicht mehr, und das Programm muss durch chmod +s /bin/su erst wieder das suid-Bit erhalten.
pam anpassen Alternativ können Sie die Datei /etc/pam.d/su anpassen, damit die wheel-Gruppe genutzt wird. Aktivieren Sie dazu folgende Zeile durch Entfernen des Kommentarzeichens: auth required /lib/security/$ISA/pam_wheel.so use_uid
Datei »sudoers« anpassen Um die wheel-Gruppe auch zur Einschränkung des sudo-Befehls zu nutzen, müssen Sie die Datei /etc/sudoers anpassen. Zum Editieren der Datei /etc/sudoers geben Sie einfach den Befehl visudo ein, und der Editor startet. Wenn sudo für die Mitglieder der wheel-Gruppe erlaubt werden soll, sieht der Eintrag wie folgt aus: %wheel ALL=(ALL) ALL
Wenn sudo für die Mitglieder der wheel-Gruppe erlaubt werden soll und kein Passwort benötigt wird, sieht der Eintrag so aus: %wheel ALL=(ALL) NOPASSWD: ALL
Innerhalb der Datei sudoers können Sie allerdings wesentlich weiter gehen und Makros hinterlegen, denen Programme oder Dateien zugewiesen sind. Damit grenzen Sie die Benutzerrechte wesentlich ein und vergeben nicht die kompletten root-Rechte. Mit man sudoers finden Sie eine genaue Anleitung, wie die Datei zu pflegen ist. Mit folgender Einstellung erlauben Sie beispielsweise nur das Ausführen von /sbin/fdisk mittels sudo (sudo /sbin/fdisk) für die users-Gruppe: Cmnd_Alias UTILS = /sbin/fdisk %users ALL = UTILS
874
root-Zugriff
15.3.3 root-Zugriff über die Konsole Es bestehen mehrere Möglichkeiten, den Zugriff des root-Benutzers komplett zu sperren. Dadurch wird der Benutzer dazu gezwungen, sich mit einem Account mit geringeren Rechten anzumelden und bei Bedarf zum root-Account zu wechseln. Tabelle 15.1 zeigt einen Auszug aus dem Red-Hat-Linux-Handbuch zur Absicherung des root-Zugriffs über die Konsole. Methode
Beschreibung
Betrifft
Betrifft nicht
Ändern der rootShell
/etc/passwd-Shell des root-Benutzers von /bin/bash in /sbin/nologin ändern
Verhindert Zugang zur root-Shell und zeichnet den Versuch auf. Die folgenden Programme können nicht mehr auf den rootAccount zugreifen:
Programme, die keine Shell benötigen, wie z. B. FTP-Clients, MailClients und viele setuid-Programme. Für die folgenden Programme wird der rootAccount nicht gesperrt:
왘 왘 왘 왘
Sperren des rootZugangs über alle Arten von Konsolengeräten (tty)
Eine leere /etc/securetty-Datei verhindert die Anmeldung als root für jegliche angeschlossene Geräte: cat /dev/null > / etc/securetty
login su ssh scp
왘
sudo
왘
VMware
Verhindert den Zugang zum rootAccount über die Konsole oder das Netzwerk. Die folgenden Programme sind für den Zugang zum root-Account gesperrt: 왘 왘
Programme, die sich nicht als root anmelden, aber administrative Aufgaben durch setuid oder andere Mechanismen ausführen. Die folgenden Programme werden nicht für den login Netzwerkdienste, Zugang zum rootdie eine tty öff- Account gesperrt: nen 왘 su 왘 왘
sudo ssh scp
왘
VMware
왘
Tabelle 15.1
Auszug aus dem Red-Hat-Handbuch: Zugriffe einschränken
875
15.3
15
Sicherheit
Methode
Beschreibung
Sperren der rootHinzufügen von Anmeldung bei Log- auth required / in über PAM lib/security/pam_ securetty.so in /etc/pam.d/login
Betrifft
Betrifft nicht
Verhindert alle root-Anmeldungen über PAM an der Konsole.
Die folgenden Programme werden nicht für den Zugang zum rootAccount gesperrt: 왘
왘
su sudo ssh scp
왘
VMware
왘 왘
Tabelle 15.1
Auszug aus dem Red-Hat-Handbuch: Zugriffe einschränken (Forts.)
15.3.4 root-Zugriff über SSH Der root-Zugriff über SSH ist bei einer Neuinstallation von VMware ESX 4 automatisch deaktiviert.Als Administrator können Sie eigentlich sehr gut mit einem gesperrten root-Zugriff über SSH leben, da Sie sehr schnell mit su zum rootAccount wechseln können. Allerdings existieren immer noch einige Programme, z. B. WinSCP, die mit dieser Situation nicht umgehen können. Die Einstellung selbst befindet sich in der Datei /etc/ssh/sshd_config unter dem Parameter PermitRootLogin (No = kein root-Log-in erlaubt, Yes = root-Log-in erlaubt). Eine Änderung greift erst nach dem Neustart des SSH-Dämons mit service sshd restart. Will man eine Root Anmeldung mit Zertifikat zulassen, allerdings ohne ein Passwort zu nutzen, so muss in der /etc/ssh/sshd_config der Parameter PermitRootLogin without-password eingetragen werden.
15.3.5 root-Zugriff über ein SSH-Zertifikat Der SSH-Dienst bietet neben dem Zugriff per Benutzername und Passwort auch die wesentlich sicherere Methode des Zugriffs über ein Zertifikat an. Dabei meldet sich der Client mit Benutzername und Zertifikat beim SSH-Dienst und wird über das Zertifikat authentifiziert. Globale Zertifikatsanmeldung In der sshd-Konfigurationsdatei ist es möglich, die Zertifikatsanmeldung global zu aktivieren oder zu deaktivieren. Aktivierung Zertifikatsanmeldung (Standard): PubKeyAuthentication Yes
Deaktivierung Zertifikatsanmeldung (Standard): PubKeyAuthentication No
876
root-Zugriff
Das Zertifikat können Sie entweder unter Linux (ssh-keygen -t rsa -b 2048) oder unter Windows (z. B. mit dem Programm PuTTYgen, http://www.chiark. greenend.org.uk/~sgtatham/putty/download.html) erstellen. Im Folgenden beschreibe ich den Vorgang von der Zertifikatserstellung unter MS Windows bis zur Anmeldung. Wie Sie in Abbildung 15.1 sehen, sollte das Zertifikat eine Mindestlänge von 2.048 Bits besitzen und vom Typ SSH-2 RSA sein. Danach wird das Zertifikat mit Generate erstellt.
Abbildung 15.1
Noch ist kein SSH-Zertifikat vorhanden.
Das Zertifikat wird anhand von Zufallswerten erstellt, die aus der Mausbewegung errechnet werden.
Abbildung 15.2
Zertifikatserstellung durch Mausbewegung
Sobald das Zertifikat erstellt ist, sollten Sie eine Key-Passphrase hinterlegen, was gleichbedeutend mit einem Kennwort zur Zertifikatsnutzung ist. Nur bei Ver-
877
15.3
15
Sicherheit
wendung automatisierter SSH-Zugriffe (plink oder scp/pscp) ist ein leeres Passwort besser geeignet. Über Save public key und Save private key speichern Sie das Schlüsselpaar ab. Während der Public Key weitergegeben werden kann, muss der Private Key geheim gehalten werden. Der Besitzer dieses Private Keys kann sich an jedem System anmelden, bei dem der dazugehörige Public Key als autorisiert hinterlegt ist. Der gesamte obere Teil in Abbildung 15.3 (Public Key for pasting into …) kann in die Zwischenablage kopiert und entweder dem zuständigen Administrator per Mail geschickt oder aber selbst zur Eintragung in die authorized_keys-Datei genutzt werden.
Abbildung 15.3
Das Zertifikat ist generiert.
Auf dem ESX-Server können mehrere öffentliche Schlüssel in der Datei /root/ .ssh/authorized_keys hinterlegt werden (falls es sich um die Anmeldung als User root handelt; bei allen anderen Benutzern ist die Datei in deren Home-Verzeichnis zu nutzen: /home//.ssh/authorized_keys). Diese Datei muss im Normalfall neu erstellt werden: mkdir /root/.ssh && touch /root/.ssh/ authorized_keys. An diesem Prozess muss daher der Administrator des ESX-Servers beteiligt sein. Wenn wir bei dem Windows-Beispiel bleiben, muss in PuTTY der private Schlüssel des Zertifikats hinterlegt werden, wie in Abbildung 15.4 zu sehen ist. Die Anmeldung geschieht dann mit dem Benutzer root und dem Passwort des Zertifikats (siehe Abbildung 15.5).
878
root-Zugriff
Abbildung 15.4
PuTTY mit Zertifikat
Abbildung 15.5
Anmeldung mit Zertifikat
Bleiben Sie in einer reinen Linux-Umgebung, wird das Zertifikat über den Befehl ssh-keygen -t rsa -b 2048 erzeugt (siehe Abbildung 15.6). Während der Anlage wird nach dem Ablageort der Schlüssel und nach dem Passwort gefragt. Der Inhalt der Public-Key-Datei (Standard /root/.ssh/id_rsa.pub) muss 1:1 in der Datei /root/.ssh/authorized_keys hinterlegt werden.
Abbildung 15.6
Erstellung eines Zertifikats unter Linux
Um das Zertifikat zu nutzen, müssen Sie dem ssh- oder scp-Befehl die Option -i <private-key> mitgeben, z. B. ssh [email protected] -i /root/.ssh/id_rsa. Ein großer Vorteil dieser Form der Anmeldung ist, dass ein sehr kryptisches lokales root-Passwort verwendet werden kann, da es von niemandem eingegeben werden muss und da es bei Kompromittierung eines Zertifikats direkt vom Zugriff ausgeschlossen werden kann (ohne eine notwendige Passwortänderung; es sei denn, auf dem System wurde schon unautorisiert »gewildert«).
879
15.3
15
Sicherheit
Passwortvergabe und Sperrung Übrigens müssen Sie bei der Verwendung eines Zertifikats, das zur Anmeldung genutzt wird, bei der Erstellung dieses Zertifikats nicht zwingend ein Passwort angeben. Dies ist vor allem bei der Nutzung von externen Skripten vorteilhaft. Allerdings sollten Sie wissen, dass Sie damit selbstverständlich das Sicherheitslevel wesentlich heruntersetzen! Bei der Verwendung von Zertifikaten müssen Sie bedenken, dass eine Sperrung des lokalen Benutzer-Accounts keine Auswirkungen auf die Anmeldemöglichkeit mit Zertifikat hat! Soll eine Zertifikatsanmeldung verhindert werden, z. B. weil das Zertifikat in fremde Hände gelangt ist, entfernen Sie einfach den Eintrag in der authorized_ keys-Datei.
15.3.6 root-SSH-Zugriff – Host Eine weitere Möglichkeit der Einschränkung bietet die Konfiguration des SSHDämons (/etc/ssh/sshd_config) durch die Option AllowUsers. Dieser Parameter hilft bei der Einschränkung von Benutzern oder entfernten Systemen, was die SSH-Anmeldemöglichkeiten betrifft. Mehrere Systeme werden durch Leerzeichen getrennt, und der * dient als Platzhalter. 왘
AllowUsers [email protected] [email protected]
Erlaubt SSH-Zugriff von den Rechnern 192.168.0.1 und 192.168.0.2 mit dem root-Benutzer. 왘
AllowUsers *@192.168.0.*
Erlaubt den Zugriff von allen Rechnern im 192.168.0er-Netzwerk mit jedem dem System bekannten Benutzer mit Anmelderecht. Außerdem sollten Sie mit der Option PermitEmptyPasswords no in der Datei sshd_config eine Anmeldung von Benutzern mit leeren Passwörtern verhindern. Als einzige Ausnahme gilt, wenn Dateien in Skripten per SCP automatisch zu den ESX-Servern kopiert werden müssen. Nach jeder Änderung innerhalb der sshd_config muss der SSH-Server-Dienst neu gestartet werden: service sshd restart. hosts.allow, hosts.deny Neben der Einschränkung der Benutzer in der sshd_config ist es auch möglich, die erlaubten bzw. verbotenen Rechner im Netzwerk über die Dateien /etc/ hosts.allow und /etc/hosts.deny einzurichten. Näheres dazu erfahren Sie auch in Abschnitt 15.5.4, »TCP-Wrappers«.
880
Benutzerverwaltung
Soll beispielsweise nur der Rechner 192.168.0.1 über SSH zugreifen dürfen, so lautet der Eintrag in der Datei /etc/hosts.allow: sshd: 192.168.0.1 sshd: ALL: DENY
15.4
Benutzerverwaltung
Wenn Sie Wert auf Sicherheit legen, kommen Sie an zwei grundlegenden Einstellungen nicht vorbei: Passwortkomplexität und Passwortgültigkeit. Außerdem ist es bei vorhandenen Benutzerverwaltungen wie Active Directory, bei denen diese Regelungen meist schon gelten, interessant, diese AD Anmeldung auch für die Anmeldung unter VMware ESX zu nutzen. Um die Komplexität der Konfiguration wesentlich zu vermindern, hat VMware den Befehl esxcfg-auth eingeführt, mit dem Sie die meisten Konfigurationseinstellungen bezüglich der Benutzerverwaltung durchführen können.
15.4.1 Passwortkomplexität Was nutzen die komplexesten Richtlinien auf dem Papier, wenn sie nicht eingehalten werden? Um diese Richtlinien zu erzwingen, können Sie den ESX-Server auf folgende Art und Weise umkonfigurieren: 왘
Passwortlänge Mit Passwortlänge ist die Mindestanzahl der Zeichen gemeint, die für ein gültiges Passwort benötigt wird. Die Standardlänge sind acht Zeichen der gleichen Zeichenklasse, wobei bei Unterschreitung nur eine Warnung ausgegeben wird. Außerdem kann durch Mischung verschiedener Zeichenklassen (Großbuchstaben, Kleinbuchstaben, Zahlen, Sonderzeichen) die Mindestlänge verringert werden.
왘
Falscheingaben Der Benutzer hat die vorgegebene Anzahl an Versuchen zur Verfügung, um ein Kennwort einzugeben. Gibt er innerhalb dieser Versuchsanzahl kein gültiges Kennwort ein, wird er gesperrt. Die Standardanzahl sind drei Versuche. Dies gilt nicht für root, der nie gesperrt wird!
Um einen gesperrten Benutzer zu entsperren, müssen Sie den Befehl esxcfgauth ausführen.
881
15.4
15
Sicherheit
Anpassung der Passworteinstellungen Diese Einstellungen können Sie direkt mit dem Befehl esxcfg-auth vornehmen. Syntax: esxcfg-auth --usecrack="Falscheingaben" "Mindestlänge" "KB_Bonus" "GB_Bonus" "Z_Bonus" "AZ_Bonus"
Optionen
Beschreibung
Falscheingaben
die Anzahl der Wiederholungsversuche, die der Anwender hat, bis ESX-Server ihn aus dem Kennwortänderungsmodus ausschließt
Mindestlänge
Die Mindestanzahl von Zeichen, die ein Anwender eingeben muss, damit das Kennwort angenommen wird. Diese Anzahl ist die Gesamtlänge vor der Anwendung jeglicher Zeichenboni.
KB_Bonus
die Anzahl von Zeichen, um die der Parameter Mindestlänge verringert wird, wenn im Kennwort min. ein Kleinbuchstabe enthalten ist
GB_Bonus
die Anzahl von Zeichen, um die der Parameter Mindestlänge verringert wird, wenn im Kennwort min. ein Großbuchstabe enthalten ist
Z_Bonus
die Anzahl von Zeichen, um die der Parameter Mindestlänge verringert wird, wenn im Kennwort min. eine Ziffer enthalten ist
AZ_Bonus
die Anzahl der Zeichen, um die der Parameter Mindestlänge verringert wird, wenn der Anwender min. ein Sonderzeichen wie z. B. einen Unterstrich oder einen Bindestrich verwendet
esxcfg-auth Mit dieser Einstellung hat ein Benutzer drei Versuche frei, sich --usecrack=3 9 0 0 0 2 anzumelden, bevor das Konto gesperrt wird. Außerdem muss
das Kennwort mindestens acht Zeichen lang sein, außer es werden Sonderzeichen benutzt; dann reichen sechs Zeichen. Tabelle 15.2
Mögliche Einstellungen für Passwörter
Wichtig Es wird immer min. ein Zeichenbonus angewendet, daher ist die Kennwortlänge effektiv ein Zeichen kürzer als im Parameter Mindestlänge angegeben. Da das genutzte PAM-Plug-in pam_cracklib.so (Standard) nur Kennwörter mit min. sechs Zeichen annimmt, muss der Parameter Mindestlänge so berechnet werden, dass die Kennwortlänge nach Abzug der Zeichenboni nicht kleiner als sechs sein kann.
Ein weiteres Sicherheitsmerkmal ist die ermöglichte Wiederverwendung von Kennwörtern.
882
Benutzerverwaltung
Historie Mit dieser Einstellung schränken Sie die Wiederverwendung schon genutzter Kennwörter ein. Im Standard ist diese Einstellung nicht gesetzt. Um diese Einstellung zu ändern, müssen Sie die Datei /etc/pam.d/system-auth anpassen, indem Sie im Anschluss an die Zeile remember=# einfügen: password sufficient /lib/ security/$ISA/pam_unix.so remember=3 # steht für die Anzahl der alten Kennwörter, die pro Anwender gespeichert wer-
den sollen. Danach müssen Sie im Verzeichnis /etc/security/ mit touch opasswd eine leere Datei erstellen und sie mit chmod 0600 opasswd und chown root:root opasswd berechtigen. Änderung des Kennworts mit Hilfe eines Plug-ins Wem die Kennwortkonfigurationsmöglichkeiten des Standard-Plug-ins pam_ cracklib.so nicht ausreichen, der kann das Plug-in pam_passwdqc.so verwenden. Sie wechseln das Plug-in mit dem Befehl esxcfg-auth. Syntax: esxcfg-auth --usepamqc="1" "2" "3" "4" "5" "Übereinstimmung"
Optionen
Beschreibung
1
die Anzahl der Zeichen, die für ein Kennwort notwendig sind, das nur aus Zeichen einer Zeichenklasse besteht
2
die Anzahl der Zeichen, die für ein Kennwort notwendig sind, das aus Zeichen zweier Zeichenklassen besteht
3
Wird für Sätze verwendet. Für VMware ESX sind mindestens drei Wörter notwendig, um einen Kennwortsatz zu bilden, z. B. the white house.
4
die Anzahl der Zeichen, die für ein Kennwort notwendig sind, das aus Zeichen dreier Zeichenklassen besteht
5
die Anzahl der Zeichen, die für ein Kennwort notwendig sind, das aus Zeichen aller vier Zeichenklassen besteht
Übereinstimmung
Mit Übereinstimmung ist die Anzahl der Zeichen gemeint, die in einer Zeichenfolge wiederverwendet werden und die aus dem vorherigen Kennwort stammen. Wenn pam_passwdqc.so eine wiederverwendete Zeichenfolge mit mindestens dieser Länge findet, schließt es diese Zeichenfolge für den Qualitätstest aus und verwendet zur weiteren Prüfung nur die restlichen Zeichen.
Tabelle 15.3
Optionen von pam_passwdqc.so
883
15.4
15
Sicherheit
Wird eine der Optionen auf –1 gesetzt, wird ein Passwort mit entsprechendem Merkmal abgelehnt. Beispiel: esxcfg-auth --usepamqc=-1 12 10 8 8 –1
Dieser Eintrag führt zu folgenden Richtlinien: 1. Passwörter mit nur einer Zeichenklasse werden abgelehnt. 2. Passwörter mit zwei Zeichenklassen müssen mindestens 12 Zeichen lang sein. 3. Passwörter, die als Sätze erkannt werden, müssen mindestens 10 Zeichen lang sein. 4. Passwörter mit drei oder vier Zeichenklassen müssen mindestens 8 Zeichen lang sein. 5. Übereinstimmungen werden ignoriert. Diese Einrichtung führt zu folgendem Eintrag in der /etc/pam.d/system-auth: Password required /lib/security/$ISA/pam_passwdqc.so min=disabled,12,10,8,8 similar=deny match=0
ð
Wichtig Die Werte der Parameter müssen mit Ausnahme von –1 in absteigender Reihenfolge verwendet werden, da das Modul sonst bei Verwendung einen Fehler verursacht, das heißt, –1, 12, 9, 12, 9, –1 führt zu einem Fehler.
15.4.2 Passwortgültigkeit Bei der Passwortgültigkeit lassen sich drei wesentliche Parameter unterscheiden: die Höchstanzahl von Tagen, die Mindestanzahl von Tagen und die Ablaufwarnung. Höchstanzahl von Tagen Die Höchstanzahl von Tagen bestimmt, wie lange ein Kennwort verwendet werden kann, bevor der Anwender es ändern muss. Die Standardeinstellung unter ESX-Server für normale Benutzer ist 90 Tage. Der root-Benutzer und andere Dienstkonten sind von dieser Einstellung im Standard nicht betroffen. Syntax: esxcfg-auth --passmaxdays="Anzahl_von_Tagen"
884
Benutzerverwaltung
Beispiel: esxcfg-auth --passmaxdays=30 würde eine nahezu monatliche Kennwortände-
rung erzwingen. Diese Einstellung können Sie auch pro Benutzer oder pro Gruppe anpassen: chage -M "Anzahl_von_Tagen" "Benutzername"
Die Aufforderung zur Kennwortänderung erfolgt bei der Anmeldung des Benutzers nach Ablauf der Anzahl von Tagen. Mindestanzahl von Tagen Die Mindestanzahl von Tagen legt fest, wie viel Zeit zwischen zwei Kennwortänderungen verstreichen muss. Die Standardeinstellung ist 0, das heißt, die Anwender können ihre Kennwörter jederzeit ändern. Syntax: esxcfg-auth --passmindays="Anzahl_von_Tagen"
Beispiel: Bei Angabe von esxcfg-auth --passmindays=1 muss das Passwort mindestens einen Tag bestehen, bevor es geändert werden kann. Diese Einstellung können Sie auch pro Benutzer oder pro Gruppe anpassen: chage -m "Anzahl_von_Tagen" "Benutzername"
Ablaufwarnung Mit der Ablaufwarnung definieren Sie, wie viele Tage vor Ablauf des Kennworts ein Hinweis zur Kennwortänderung ausgegeben wird. Die Standardeinstellung ist 7 Tage. Syntax: esxcfg-auth --passwarnage="Anzahl_von_Tagen"
Beispiel: Durch Angabe von esxcfg-auth --passwarnage=14 werden 14 Tage vor Ablauf des Kennworts bei jeder Anmeldung über die Konsole oder SSH Warnmeldungen angezeigt. Diese Einstellung können Sie auch pro Benutzer oder pro Gruppe anpassen: chage -W "Anzahl_von_Tagen" "Benutzername"
Um sich die derzeitige Einstellung dieser Werte anzeigen zu lassen, nutzen Sie folgenden Befehl: esxcfg-auth -p | grep PASS
885
15.4
15
Sicherheit
Pro Benutzer können Sie den Befehl chage -l "Benutzer" verwenden.
15.4.3 Zentrale Benutzerverwaltung Um die Benutzer- bzw. die Passwortverwaltung zu zentralisieren, will man häufig mit LDAP, insbesondere Active Directory, arbeiten. VMware ESX bietet die Möglichkeit, verschiedene Authentifizierungsverfahren einzurichten. Im Folgenden wird die Anmeldung an Active Directory beschrieben. Ausgangssituation: Domäne: test.local Domänencontroller: dc.test.local, 192.168.0.20/255.255.255.0 Benutzer: dennis Auf den ESX-Servern muss folgender Befehl abgesetzt werden, um den ActiveDirectory-Zugriff nutzen zu können: esxcfg-auth --enablead --addomain=test.local --addc=dc.test.local --enablekrb5 --krb5realm=test.local --krb5kdc=dc.test.local
ð
Oder ohne Kerberos: esxcfg-auth --enablead --addomain=test.local --addc=dc.test.local
Tipp Will man weitere Domänencontroller aus Ausfallsicherheitsgründen nutzen, so kann der Parameter --addc= mehrfach angegeben werden.
Zusätzlich müssen Sie jeden Benutzer, der sich am ESX-Server anmelden soll, lokal einrichten, da nur die Kennwörter mit dem Active Directory abgeglichen werden und nicht die Benutzer-Accounts: useradd dennis
Über die PowerShell könnten den Benutzer im Active Directory und in den lokalen Linux-Benutzern abgleichen. Quest (www.quest.com) stellt kostenlos ein Active-Directory-Plug-in für die PowerShell zur Verfügung, und der Befehl der PowerCLI zum Hinzufügen eines Benutzers lautet: New-VMHostAccount -ID User -Password Pass -UserAccount -GrantShellAccess
886
Firewall
Da der Benutzer auch über root-Rechte über su verfügen soll, muss er zusätzlich der wheel-Gruppe hinzugefügt werden, falls damit gearbeitet wird: usermod -G wheel dennis
Übereinstimmung der Uhrzeit Bei Kerberos-Verwendung müssen Sie darauf achten, dass die Uhrzeit aller an der Authentifizierung teilnehmenden Systeme übereinstimmt. Eine maximale Abweichung von 5 Minuten wird toleriert.
15.4.4 Zurücksetzen des root-Passworts Es kann vorkommen, dass Sie irgendwann vor Ihrem seit Monaten problemlos laufenden ESX-Server stehen und sich anmelden möchten, aber das root-Passwort nicht mehr wissen. Da der Server immer noch in der vCenter-Verwaltung ist, können Sie die virtuellen Maschinen allerdings per VMotion verschieben oder zumindest herunterfahren. Im Fall eines direkten Konsolenzugriffs auf das System – lokal, über einen KVMSwitch oder per Hardwaremanagement (iLO, RSA etc.) – können Sie das System durch (Strg)+(Alt)+(Entf) zum Neustart bewegen und am Grub-Bootmenü Linux im Single-User-Modus booten. Um den Single-User-Modus zu benutzen, geben Sie einfach im Grub-Bootmenü linux single ein. Dadurch bootet nur die Service Console, und root wird automatisch angemeldet. Die Passwortänderung führen Sie dann mit passwd root aus. Alternative: Starten Sie den vSphere-Client auf dem ESX-Server, rufen Sie Users & Groups auf, dann root Edit und anschließend Change Password.
15.5
Firewall
Nach der Installation von VMware ESX 4 sind die Firewall-Einstellungen schon auf ein Minimum beschränkt, und es werden nur die VMware-Dienste und SSHZugriff erlaubt. Möchten Sie zusätzliche Dienste betreiben, z. B. Hardwaremanagement-Agenten oder Backup-Agenten, müssen Sie dies explizit erlauben. Das gleiche gilt bei der Nutzung von NFS, SMB oder SW iSCSI, die ohne einen vorhergehenden Benutzereingriff nicht laufen.
887
15.5
15
Sicherheit
Firewall-Regeln anzeigen Eine Auflistung des derzeit gültigen Regelwerks sehen Sie mit dem Befehl esxcfg-firewall -q ein. Außerdem müssen Sie auch Firewall-Systeme bedenken, die möglicherweise zwischen dem Administrations-Client oder vCenter bzw. dem Lizenz-Server und dem ESX-Server platziert sind. Port
Richtung
Daten
80
eingehend TCP
Ungesicherter HTTP-Zugriff für VMware WebAccess, wird allerdings auf Port 443 umgeleitet.
443
eingehend TCP
WebAccess-Verbindungen von SDK-Zugriffen (API) entweder zum vCenter-Server oder direkt zum VMware ESXServer, z. B. durch Zusatzsoftware
902
eingehend TCP ausgehend UDP
왘 왘 왘 왘
903
eingehend TCP
왘 왘
2.049
eingehend TCP ausgehend TCP
VI-Client-Zugriff auf den vCenter-Server vCenter-Server-Zugriff auf den ESX-Server direkter VI-Client-Zugriff auf den ESX-Server ESX-Server-Host-Zugriff auf andere ESX-Server für Migration und Provisioning VI-Client-Zugriff auf die Konsolen virtueller Maschinen WebAccess-Client-Zugriff auf die Konsolen virtueller Maschinen
Datenübertragungen von den NFS-Speichergeräten. Dieser Port wird auf der VMkernel-Schnittstelle und nicht auf der Service Console verwendet.
2.050 – ausgehend TCP 5.000 eingehend UDP ausgehend UDP
Datenverkehr zwischen dem ESX-Server für VMware HA und den EMC Autostart Manager
3.260
ausgehend TCP
Datenübertragungen von den Software-iSCSI-Speichergeräten. Dieser Port wird auf der VMkernel-Schnittstelle und auf der Service Console verwendet. Bei Nutzung eines iSCSI-HBA muss dieser für den Port freigeschaltet werden; die Service Console ist in diesem Fall nicht betroffen.
8.000
ausgehend TCP eingehend TCP
Eingehende VMotion-Anfragen. Dieser Port wird nur auf der VMkernel-Schnittstelle verwendet.
8.042 – ausgehend TCP 8.045 eingehend UDP ausgehend UDP Tabelle 15.4
888
Datenverkehr zwischen den ESX-Servern für VMware HA und den EMC Autostart Manager
Portübersicht VMware ESX 3.x unter vSphere
Firewall
Port
Richtung
Daten
9000 – 9100
eingehend TCP
VMware Update Manager
27.000
ausgehend TCP
Lizenzübertragungen vom ESX-3.x-Server an den LizenzServer
27.010
eingehend TCP
Lizenzübertragungen vom Lizenz-Server bei ESX 3.x
Tabelle 15.4
Portübersicht VMware ESX 3.x unter vSphere (Forts.)
Die komplette Liste aller TCP- und UDP-Ports für vCenter-Server und andere Netzwerkmanagement-Komponenten finden Sie unter: http://kb.vmware.com/ kb/1012382.
15.5.1 Firewall-Bedienung Der ESX-Server bringt einen Befehl zur Verwaltung der Firewall mit, der die wichtigsten Einstellungen ermöglicht: esxcfg-firewall. Aktion
Befehl
Dienst erlauben
esxcfg-firewall -e "Dienst"
Dienst verbieten
esxcfg-firewall -d "Dienst"
aktive Firewall-Regeln auslesen
esxcfg-firewall -q
bekannte Dienste anzeigen
esxcfg-firewall -s
eingehend alles erlauben
esxcfg-firewall --allowIncoming
ausgehend alles erlauben
esxcfg-firewall --allowOutgoing
eingehend bis auf Standarddienste alles blocken esxcfg-firewall --blockIncoming ausgehend bis auf Standarddienste alles blocken esxcfg-firewall -blockOutgoing speziellen Port erlauben
esxcfg-firewall -o <port,tcp|udp,in|out,name>
speziellen Port blocken
esxcfg-firewall -c <port,tcp|udp,in|out,name>
Tabelle 15.5
Verwendung von esxcfg-firewall
15.5.2 Standardports Der ESX-Server kennt nach der Installation mehrere Dienste samt deren Portbeschreibung und Namen. Dies vereinfacht die Verwaltung der Firewall-Einstellungen doch erheblich, da sich Namen immer besser merken lassen als Portnummern.
889
15.5
15
Sicherheit
Im Folgenden finden Sie eine Auflistung mit Diensten, die oft manuell aktiviert werden müssen: 왘
NFS-Verbindung über die Service Console erlauben: esxcfg-firewall -e nfsClient blocken: esxcfg-firewall -d nfsClient
왘
NTP-Zeit-Server erlauben: esxcfg-firewall -e ntpClient blocken: esxcfg-firewall -d ntpClient
왘
SMB-Verbindung (Windows- oder Samba-Freigabe) über die Service Console erlauben: esxcfg-firewall -e smbClient blocken: esxcfg-firewall -d smbClient
왘
SSH-Zugriff, von ESX ausgehend erlauben: esxcfg-firewall -e sshClient blocken: esxcfg-firewall -d sshClient
왘
Software-iSCSI-Initiator erlauben erlauben: esxcfg-firewall -e swISCSIClient blocken: esxcfg-firewall -d swISCSIClient
왘
SNMP-Überwachung erlauben erlauben: esxcfg-firewall -e snmpd blocken: esxcfg-firewall -d snmpd
Übrigens werden bei Einrichtung über die esxcfg-Befehle automatisch die benötigten Firewall-Einstellungen nachgezogen, z. B. nfsClient bei esxcfg-nas.
15.5.3 Custom Ports Die mitgelieferten Dienste reichen in den wenigsten Fällen aus, da viele Zusatzprogramme wie Hardwaremanagement- oder Backup-Software eigene Ports nutzen. Allerdings ist es kein Problem, diese Ports freizuschalten, wenn Richtung, Protokoll und Portnummer bekannt sind. Der Parameter -o des Befehls esxcfgfirewall hilft an dieser Stelle weiter: Syntax: esxcfg-firewall -o <port,tcp|udp,in|out,name>
890
Firewall
Beispiele: esxcfg-firewall -o 11111,tcp,in,custom1 esxcfg-firewall -o 11111,tcp,out,custom2 esxcfg-firewall -o 11111,udp,in,custom3 esxcfg-firewall -o 11111,udp,out,custom4
Um die Ports wieder zu schließen, verwenden Sie einfach statt des -o-Parameters -c: esxcfg-firewall -c 11111,udp,out,custom4
Möchten Sie diese Ports auch über Namen ansprechen, tragen Sie diese in der Datei /etc/vmware/firewall/services.xml ein. Hat alles geklappt, muss der Dienst bei esxcfg-firewall -s angezeigt werden. Ein wesentlich sicherer Weg ist das Erstellen einer gesonderten Datei im /etc/vmware/firewall-Verzeichnis (z. B. custom.xml). Diese Datei muss vom Aufbau mit der services.xml-Datei identisch sein. Im Fall des kostenlosen Kopierprogramms Veeam FastSCP sähe der Inhalt wie folgt aus: <service> FastSCP outbound <protocol>tcp <port type='dst'> 2500 <end>5000 -m state --state NEW inbound <protocol>tcp <port type='dst'> 2500 <end>5000 -m state --state NEW
891
15.5
15
Sicherheit
Beispiel mit IBM Director Benötigte Ports (zusätzlich zu snmpd): 왘
14247 eingehend TCP
왘
14247 eingehend UDP
왘
14248 eingehend TCP
Änderung in services.xml: <service id='0027'> ibmdir inbound <protocol>tcp <port type='dst'>14247 -m state --state NEW inbound <protocol>udp <port type='dst'>14247 -m state --state NEW inbound <protocol>tcp <port type='dst'>14248 -m state --state NEW
Änderungen platzieren bzw. zusätzliche Firewall-Regel-Datei Die Änderungen müssen vor der Zeile eingefügt werden! Außerdem müssen Sie darauf achten, dass Sie die Service-ID hochzählen (letzte Service-ID +1). Falls Schreibfehler enthalten oder Zeilenumbrüche falsch sind (Unix-Kodierung zwingend!), startet unter Umständen der VMkernel nicht korrekt.
15.5.4 TCP-Wrappers Während Sie mit der Firewall in der Lage sind, bestimmte Ports global zu sperren oder zu erlauben, lässt die SSH-Konfigurationsdatei schon genauere Restriktionen zu, z. B. eine Beschränkung auf Zertifikate oder bestimmte Host-Systeme.
892
Firewall
Diese Einschränkung auf IP-Adressen oder Hosts ist mit den TCP-Wrappers auch für jeden TCP-Dienst möglich, daher gehen wir darauf im Folgenden näher ein. Die TCP-Wrapper nutzen die beiden Dateien /etc/hosts.allow und /etc/hosts.deny, um Netzwerkverbindungen explizit zu erlauben oder zu verbieten. Von der Reihenfolge her wird immer zuerst die /etc/hosts.allow-Datei ausgewertet und erst, wenn keine passende Regel gefunden wurde, die /etc/hosts.deny angeschaut. Sobald eine passende Regel gefunden wird, ist diese entscheidend und wird genutzt. Der Aufbau ist bei beiden Dateien gleich: Service Dämon : Client [:option1:option2:option3:...]
Ein Name eines Service-Dämonen wäre z. B. der SSH-Dienst sshd. An Dämonen wie einem vpxd sollten Sie nur agieren, wenn Sie sich über die Auswirkungen im Klaren sind. Würden Sie den vpxd, also den vCenter-Agenten, nicht mehr vom vCenter-Server aus erlauben, so wäre keine Integration ins vCenter mehr möglich. 왘
sshd:192.168.199.20:allow würde alle Zugriffe von dem Rechner mit der
IP-Adresse 192.168.199.20 auf den SSH-Dienst erlauben. 왘
sshd:esx1.bookshop.local:allow würde alle Zugriffe von dem Rechner mit
dem DNS-Namen esx1.bookshop.local auf den SSH-Dienst erlauben. 왘
sshd:192.168.199.0/24:allow würde alle Zugriffe von Rechnern im Subnetz
von 192.168.199.1 bis 192.168.199.254 auf den SSH-Dienst erlauben. Würden Sie nur mit der /etc/hosts.allow-Datei arbeiten, so könnten Sie diese Datei auch weglassen, da eine Netzwerkkommunikation nicht explizit zugelassen werden muss. Daher existiert die Datei /etc/hosts.deny, die danach alle »Bösewichte« abfängt. 왘
sshd:ALL oder sshd:ALL:deny erlaubt keinerlei Zugriffe per SSH – nur die Sys-
teme in der /etc/hosts.allow-Datei sind nicht von dieser Regel betroffen. 왘
sshd:esx2.bookshop.local:allow
verhindert
Zugriffe
von
esx2.book-
shop.local. 왘
sshd:192.168.199.0/24:allow verhindert alle weiteren Zugriffe aus dem
192.168.199.0er Subnetz – nur die Systeme in der Datei /etc/hosts.allow sind nicht von dieser Regel betroffen. Diese Einschränkung der TCP-Dienste ist ebenso bei HardwaremanagementAgenten in der Service Console sinnvoll oder auch bei USV-Agenten. Achten Sie darauf, immer ein Backup der Original-Dateien /etc/hosts.allow und /etc/ hosts.deny zu machen, bevor Sie Anpassungen vornehmen.
893
15.5
15
Sicherheit
Reihenfolge der Regeln Beachten Sie, dass die Regeln innerhalb der Dateien /etc/hosts.allow und /etc/ hosts.deny sequentiell abgearbeitet werden und der erste Treffer der entscheidende ist. Wird ein System z. B. in Zeile 15 gesperrt, in Zeile 20 aber erlaubt, greift immer die Regel in Zeile 15, und Zeile 20 wird nie ausgewertet.
15.5.5 VMware WebAccess Seit vSphere ist standardmäßig nur noch die SDK und nicht mehr der WebAccess automatisch für Benutzer im Netzwerk verfügbar. Da WebAccess im Normalfall auf dem ESX-Host direkt auch genutzt wird, ist diese eine sinnvolle Anpassung gegenüber ESX 4. Änderungen am Startverhalten des WebAccess sind mittels chkconfig-Befehl möglich. 왘
alles an: chkconfig --level 2345 vmware-webAccess on
왘
alles aus: chkconfig --level 2345 vmware-webAccess off
Eine der sinnvollsten Möglichkeiten, die nicht viel Aufwand verursacht, besteht darin, neben dem Abschalten von Webdienstkomponenten wie WebAccess die Index-Webseite umzuleiten oder zu löschen. Diese ist unter /var/lib/vmware/ hostd/docroot/index.html zu finden.
15.6
SSL-Zertifikat
Während des ersten Starts des ESX-Server wird durch das mgmt-vmware-Skript automatisch ein SSL-Zertifikat erstellt. Dieses wird ab diesem Zeitpunkt für die Kommunikation zwischen Browser und ESX-Server bzw. zwischen VMware vCenter und ESX-Server genutzt. Wegen der Erzeugung über eine eigene und nicht über eine offizielle Zertifizierungsstelle ist dieses Zertifikat nicht vertrauenswürdig. Das Zertifikat ist im Verzeichnis /etc/vmware/ssl zu finden und besteht aus den zwei Dateien rui.crt (öffentliches Zertifikat) und rui.key (privater Schlüssel). Diese können Sie durch eigene Zertifikatsdateien ersetzen. Tipp Das Zertifikat wird immer beim Start des mgmt-vmware-Skripts gesucht und gegebenenfalls neu erstellt. Daher können Sie durch Löschen oder Umbenennen der Zertifikatsdateien eine Neuerstellung erzwingen.
894
Überwachung
Achten Sie bei der Zertifikatserstellung darauf, dass keine Kennwortsätze (verschlüsselte Schlüssel) verwendet werden, da der VMware ESX-Server diese nicht interpretieren kann. Falls Sie eine zentrale Ablage für die Zertifikate besitzen, können Sie auch in der Datei /etc/vmware/hostd/config.xml einen Proxy konfigurieren.
15.7
Überwachung
VMware ESX bietet eine Vielzahl von Informationen über das SNMP-v1-Protokoll an, die das Wirtssystem selbst, aber auch die virtuellen Maschinen betreffen. Im Gegensatz zu VMware ESX 3.x wurde nun ein eigener SNMP-Agent eingeführt, den Sie aktivieren müssen. Daher wurden die .6876-OIDs aus dem in der Service Console (Red Hat) integrierten snmpd-Agenten entfernt. Um den VMware-SNMP-Agenten (läuft im hostd mit) zu aktivieren, müssen Sie den Standard-SNMP-Agenten deaktivieren, da dieser auf dem gleichen Port lauscht. Alternativ stellen Sie die Ports um. Zum Deaktivieren des SNMP-Agenten sind folgende Befehle auf der Service Console einzugeben: service snmpd stop chkconfig -level 2345 snmpd off
Den vSphere-SNMP-Agenten aktivieren Sie am besten über den Befehl vicfgsnmp.pl im VMware vSphere Command-Line Interface. Dieses finden Sie unter http://www.vmware.com/support/developer/vcli/. Aktivieren per vicfg-snmp.pl unter dem Community-String public: vicfg-snmp.pl --server 192.168.1.10 --password password -c public vicfg-snmp.pl --server 192.168.1.10 --password password --show vicfg-snmp.pl --server 192.168.1.10 --password password –enable vicfg-snmp.pl --server 192.168.1.10 --password password --show
--username root --username root --username root --username root
Sollte der enable-Befehl fehlschlagen, kann ein service mgmt-vmware restart Wunder wirken. Anpassung der Firewall: esxcfg-firewall –e snmpd
895
15.7
15
Sicherheit
SNMP-Traps Sollen SNMP-Traps verwendet werden, müssen Sie die Trap-Ziele in der Datei / etc/snmp/snmpd.conf einrichten. Dazu dienen die beiden Einträge trapcommunity und trapsink. Auszug aus der Datei /etc/snmp/snmpd.conf: trapcommunity "Communityname" trapsink "Zielsystem-1" trapsink "Zielsystem-n"
Achtung Fehlerhafte trapsink-Ziele können zu enormen Leistungseinbußen führen. Ist z. B. ein falscher DNS-Name eingetragen, der nicht aufgelöst werden kann, werden viele Aktionen (z. B. der Start einer virtuellen Maschine), die ein Trap auslösen, bis zum Timeout verzögert.
Bei Nutzung der VMware-SNMP-Dienste müssen die Trap-Ziele mittels Remote CLI konfiguriert werden: vicfg-snmp.pl --server --username <user> --password <pass>-t @162/
Die Konfigurationsdateien liegen hier: /etc/vmware/snmp.xml Die MIBS finden Sie im Verzeichnis: /usr/share/snmp/mibs/ Neben dem VMware-Dokument existiert eine sehr gute Anleitung von Dell: http://en.community.dell.com/groups/dell_management_console/media/p/ 19527351.aspx
15.8
Protokollierung
Protokollrotierung Es wird empfohlen, die Protokolldateien vmkernel, vmksummary und vmkwarning auf 4 MB Protokollgröße und Komprimierung bei der Rotation zu konfigurieren. Dazu müssen Sie die Konfigurationsdateien von logrotate, /etc/logrotate.d/vmkernel, /etc/logrotate.d/vmksummary und /etc/logrotate.d/vmkwarning, wie folgt anpassen: compress (gegebenenfalls vorhandenes nocompress entfernen) size 4M
896
Protokollierung
Zentrale Protokollierung In der Standardeinstellung protokolliert der Syslog-Dienst nur lokal. Dies können Sie allerdings umstellen, so dass ein zentraler Syslog-Server im Netzwerk alle Protokolldaten erhält. Besonders in Umgebungen mit vielen ESX-Servern ist so eine wesentlich schnellere Fehler- oder Einbruchssuche möglich. Um dem Syslog-Dienst das zentrale Protokollieren beizubringen, muss lediglich folgender Eintrag in der Datei /etc/syslog.conf erfolgen: # Alle Meldungen gehen an den zentralen "Protokollserver" *.* @Protokollserver
Zum Beispiel: *.*
@192.168.0.50
Danach müssen Sie den Syslog-Dienst mit service syslog restart neu starten, um alle Änderungen anzunehmen. Rotierung der Protokolldateien virtueller Maschinen Jede virtuelle Maschine schreibt ein Protokoll in die Datei vmware.log in ihrem Heimatverzeichnis. Werden diese Protokolldateien zu groß, kann es zur kompletten Nutzung des Datastores kommen, was zu erheblichen Problemen beim Betrieb der virtuellen Maschinen führt. Zur Lösung dieses Problems sollten Sie die Protokolldateien entweder löschen oder in gewissen Abständen rotieren, sobald eine gewisse Dateigröße erreicht wird. VMware ESX rotiert im Standard mit bis zu 6 Dateien, d. h. eine aktuelle Datei und fünf alte Protokolle. VMware schlägt die Protokollgröße von 500 KB als ausreichenden Wert vor. Die Protokollierung ist pro virtueller Maschine zu konfigurieren, was mittels VI-Client oder Kommandozeile möglich ist. Folgende Werte sind von Interesse: log.rotateSize (Größe der Log-Dateien in Bytes) und log.keepOld (Anzahl der zu haltenden alten Protokolldateien). VI-Client: Edit Settings 폷 Options 폷 Advanced 폷 Configuration Parameters · Add Row Kommandozeile: vmware-cmd vm.vmx setconfig log.rotatesize 524288 vmware-cmd vm.vmx setconfig log.keepOld 4
897
15.8
15
Sicherheit
Externe Protokollierung Neben der normalen Protokollierung auf den Festplatten ist ein weiterer Aspekt interessant, wenn es um die Sicherheit und um die Durchgängigkeit der Protokollierung geht: die Protokollierung über die serielle Schnittstelle. Dieses Verfahren wird vor allem im Bereich von Sicherheitskomponenten wie Firewall- oder Backbone-Routern angewandt und bietet im VMware ESX-Umfeld zwei große Vorteile: 왘
Sicherheit vor Manipulation Daten werden nicht auf die lokalen Festplatten, sondern auf ein weiteres Gerät über die serielle Schnittstelle geschrieben. Da dies nur in eine Richtung passiert, kann ein Angreifer keine Spuren verwischen, indem er die Protokolldateien nachträglich manipuliert.
왘
Sicherheit vor Plattenausfällen Fallen die lokalen Festplatten aus, ist ohne die Nutzung serieller Leitungen keine Protokollierung mehr möglich. Das Gerät an der seriellen Schnittstelle protokolliert auch bei Ausfall der lokalen Platten munter weiter.
Um den ESX-Server zur seriellen Protokollierung zu bewegen, sind folgende Schritte notwendig: 1. Anbindung eines zweiten Systems über die serielle Schnittstelle (z. B. per NullModem-Kabel) 2. Konfiguration des ESX-Server zur Verwendung einer seriellen Schnittstelle (1 = COM1, 2 = COM2): esxcfg-advcfg -s 1 /Misc/SerialPort
3. Starten eines Terminalprogramms für serielle Schnittstellen auf dem zweiten System mit Protokollierung auf der Festplatte
15.9
Nützliche Zusatzsoftware
Neben den »Papier«-Anweisungen zur Härtung des ESX-Hosts ist es sehr interessant, sich die folgenden kostenlosen Softwareprodukte näher anzuschauen, da diese eine automatische Konfigurationsüberprüfung oder auch -überwachung bieten.
898
Nützliche Zusatzsoftware
15.9.1 Configuresoft Compliance Checker Beim Compliance Checker von Configuresoft (wurde von EMC übernommen) ist der Name Programm, das heißt, dieses kostenlose Tool gibt einen direkten Überblick über die Konfiguration des VMware ESX-Servers. Nach der Einrichtung der zu überprüfenden Server erhalten Sie eine Auswertung der derzeitigen Konfiguration, die die Unterschiede beim Vergleich zu den Best Practices bzw. zum CIS (Center of Internet Security) aufzeigt. Bis zu fünf Hosts können Sie mit dem kostenlosen Tool gleichzeitig auf Sicherheitsaspekte überprüfen.
Abbildung 15.7
Configuresoft Compliance Checker for VMware ESX
URL: http://www.configuresoft.com/compliance-checker.aspx Zur Drucklegung war keine Version für ESX 4.x verfügbar.
899
15.9
15
Sicherheit
15.9.2 Tripwire ConfigCheck Tripwire ist bereits seit langer Zeit bekannt für Server-Lösungen zum Erkennen von Änderungen an Systemeinstellungen. Dies wird vor allem bei Systemen mit hohem Sicherheitsbedarf angewandt, um Fehlkonfiguration, aber auch unbefugtes Eindringen ins System zu erkennen. Tripwire hat mit dem ConfigCheck für VMware ein kostenloses Programm zur Verfügung gestellt, mit dem neben der Prüfung der Konfiguration auch das Härten des Linux-Systems (VMware ESX-Service-Console) möglich ist. Dieses Tool ist vor allem nützlich, um unterschiedliche Konfigurationen auf verschiedenen VMware ESX-Servern zu erkennen und zu dokumentieren.
Abbildung 15.8
Tripwire ConfigCheck
URL: http://www.tripwire.com/configcheck/index.cfm Zur Drucklegung war keine Version für ESX 4.x verfügbar.
15.9.3 SolarWinds VM Monitor SolarWinds hat eine kostenfreie Software für die rudimentäre Überwachung von VMware ESX-Servern veröffentlicht, die einen ESX-Server mittels SNMP abfragt. ESXi wird daher aufgrund des fehlenden SNMP-Servers derzeit nicht unterstützt.
900
Virtuelle Maschinen in der DMZ
Abbildung 15.9
SolarWinds VM Monitor
Funktionsumfang: 왘
Überwachung des VMware ESX-Servers: CPU, Hauptspeichernutzung, Informationen zu den virtuellen Maschinen
왘
detaillierte Informationen über den Zustand der virtuellen Systeme
왘
bereits vordefinierte Best-Practice-Schwellenwerte für Warnungen
왘
rudimentäre Hilfe beim Erkennen von Leistungsengpässen
URL: http://www.solarwinds.com/products/freetools/vm_monitor.aspx Sobald es eine ESX-4-Unterstützung gibt, müssen Sie sich an die Konfigurationsanweisungen für SNMP halten, damit der VM Monitor die OIDs auslesen kann.
15.10
Virtuelle Maschinen in der DMZ
Ein sehr gern diskutierter Schritt ist die Nutzung von virtuellen Maschinen in der DMZ. Dabei ist immer seltener das Ob eine Fragestellung, sondern vielmehr das Wie.
901
15.10
15
Sicherheit
15.10.1
Isolation
Ein sehr einfach verständlicher Weg führt über die Absicherung der virtuellen Umgebung, indem diese isoliert wird, das heißt, der ESX-Server kann nur lokal angesprochen werden. Dazu werden Firewall-Systeme zwischen Internet, DMZ und LAN eingerichtet, die sämtlichen Netzwerkverkehr auf die Service Console des ESX-Hosts verbieten. Außerdem wird auf dem ESX-Host selbst die Firewall sehr konservativ konfiguriert und der Zugriff auf die Dienste per hosts.allow/ deny-Dateien sehr restriktiv eingerichtet. Sämtliche Konfiguration muss entweder über die lokale Konsole an dem ESXHost passieren oder über ein speziell zugelassenes Managementsystem, das an die SDK von VMware andocken kann, um entweder per vSphere-Client oder vCenter zu kommunizieren. Das Service-Console-Netzwerk muss natürlich von den Netzwerken der virtuellen Maschinen getrennt werden. Wird iSCSI oder NFS eingesetzt, müssen auch diese Netze gegen Angriffe aus der virtuellen Maschine geschützt werden, das heißt, auch hier muss eine Trennung erfolgen. Je nach Sicherheitsstandard dürfen keine VLANs genutzt werden, wodurch sich die Anzahl der Netzwerkports zwangsweise erhöht.
15.10.2
Firewalls und VMs
Es ist selbstverständlich möglich, auch in den virtuellen Maschinen Firewall-Software zu installieren und zu betreiben. Allerdings sind gerade Firewall-Funktionen enorme Netzwerk- und CPU-Ressourcenfresser, die gerne die IRQs häufig belegen. Daher werden die Host-CPU und das Netzwerk deutlich belastet, wenn in jeder VM eine Firewall konfiguriert ist. VMware arbeitet allerdings sehr eng mit den Hardwareherstellern zusammen, wodurch dieses Problem vor allem durch neue Netzwerkkarten mit intelligenter IRQ-Nutzung relativiert wird. Eine Alternative aus eigenem Hause hat VMware mit den vShield Zones entwickelt, die in diesem Kapitel in Abschnitt 15.11, »VMware vShield Zones«, getrennt beschrieben werden. Ohne die Nutzung von Firewalls ist es allerdings nicht möglich, virtuelle Maschinen, die sich in den gleichen Portgruppen befinden, gegeneinander zu schützen, da eine Portgruppe mit einem physikalischen Switch ohne VLAN-Einrichtung vergleichbar ist.
902
VMware vShield Zones
15.10.3 Best Practices Es existieren allgemeine Best Practices, um virtuelle Maschinen in der DMZ zu betreiben, die allerdings gegen die eigene Umgebung und deren Möglichkeiten abgewogen und geprüft werden müssen. 왘
ESX-Hosts mit eigenen LUNs für die DMZ-VMs verwenden
왘
ESX-Hosts in der DMZ von ESX-Hosts im normalen LAN trennen
왘
keine DMZ-VMs mit LAN-VMs auf dem gleichen ESX-Host oder der gleichen LUN mischen
왘
Bei Nutzung von DRS-Clustern müssen entsprechende Regeln zum Schutz vor automatischer Migration getroffen werden, um keine Mischumgebungen zu schaffen.
왘
Storage VMotion und VMotion werden im Klartext durchgeführt, daher sollten diese Netze vom Netzwerk der virtuellen Maschinen getrennt werden.
15.11
VMware vShield Zones
VMware vShield Zones lassen sich einfach als Firewall-Lösung in Form einer oder mehrerer virtueller Appliances beschreiben, die den Netzwerkverkehr zwischen den virtuellen Maschinen und zwischen den VMs und der Außenwelt protokollieren und regulieren. Ein guter Punkt ist auch die Integration in vCenter, da alle Netzwerkeinstellungen und vShield-Knoteninstallationen automatisch erfolgen.
Abbildung 15.10
vShield-Zones-Integration ins vCenter
vShield Zones wird ausschließlich über Weboberfläche und Kommandozeile verwaltet und konfiguriert, allerdings können Sie die Weboberfläche als Plug-in in den vCenter-Client integrieren.
903
15.11
15
Sicherheit
Abbildung 15.11
VMware vShield Zones
Da diese Software eines der Kernprodukte von vSphere ist, gehen wir in diesem Abschnitt näher auf das Produkt ein.
15.11.1
Installation
Abbildung 15.12
904
VMware-vShield-Zones-Download
VMware vShield Zones
Zur Installation laden Sie das VMware Data Recovery and VMware vShield Zones Medium auf der VMware-Webseite herunter, das ab der Advanced Edition zur Verfügung steht. Nach dem Start des Wizards werden die beiden virtuellen Appliances vShield Manager und vShield sowie die Handbücher entpackt. vShield Manager Danach müssen Sie zuerst den vShield Manager als virtuelle Appliance importieren, aber noch nicht starten und konfigurieren, da noch kein vShield-Managementnetzwerk existiert. Daher sollten Sie einen neuen virtuellen Switch (ohne Uplinks) und darin eine Portgruppe vsmgmt anlegen. Für den vShield Manager müssen Sie eine weitere Netzwerkkarte (Flexible) mit Zuordnung auf die Portgruppe vsmgmt konfigurieren, bevor Sie die virtuellen Maschinen starten und anschließend mit Netzwerkinformationen versorgen dürfen.
Abbildung 15.13
Importieren der vShield Appliances
Die Einrichtung der Portgruppen muss auch bereits für den Import erfolgt sein, da Sie Management-, Protected- und Unprotected-Portgruppe auswählen müssen. 왘
Management: Über dieses Verwaltungsnetzwerk der vShield Appliances kommuniziert der vShield Manager mit den vShield Appliances.
왘
Protected: Über dieses Netzwerk werden die von vShield geschützten VMs eingerichtet und kommunizieren. Der gesamte Netzwerkverkehr dieser Portgruppe läuft zwingend durch die Firewall-Engine der vShield Appliances.
왘
Unprotected: Über dieses Netzwerk werden die VMs eingerichtet und kommunizieren, die nicht durch vShield geschützt werden. Der gesamte Netzwerkverkehr dieser Portgruppe geht an der Firewall-Engine der vShield Appliances vorbei.
905
15.11
15
Sicherheit
Abbildung 15.14 Die Portgruppe »vsmgmt« muss zum korrekten Betrieb von vShield Zones angelegt sein.
Die Erstanmeldung auf der Kommandozeile am vShield Manager erfolgt mit dem Benutzer admin und dem Kennwort default, die Konfiguration mit dem Befehl setup (Host-Name und Netzwerkdetail). Als Nächstes muss der vShield-Knoten als virtuelle Appliance importiert werden. Diese VM darf allerdings nicht gestartet werden und ist stattdessen in ein Template zu konvertieren. Aus diesem Template werden später die vShield-Zone-Knoten automatisch erstellt.
Abbildung 15.15
Erstkonfiguration des vShield Managers
Nach der Konfiguration können Sie sich direkt mittels Webbrowser auf dem vShield Manager verbinden: https://vShield-Manager. Dort müssen Sie die vCenter-Adresse samt administrativem Benutzer-Account angeben, um die Erstverbindung von vShield zu vCenter herzustellen. Möchten Sie die Erstverbindung zum vCenter mit dem DNS-Namen durchführen, müssen Sie zuerst die DNS-Einstellungen im Unterpunkt DNS setzen. Sobald die Verbindung vom vShield Manager zum vCenter erfolgreich war, wird direkt die Hierarchie der Hosts und Clusters angezeigt. Derzeit ist nur der vShield Manager aktiv und nicht die vShields. Diese müssen auf jedem zu überwachenden ESX-Server installiert werden, und zwar im Eigenschaftsfenster der einzelnen ESX-Server.
906
VMware vShield Zones
Abbildung 15.16
Erfolgreiche Verbindung vom vShield Manager zum vCenter
vShield Mittels Install vShield starten Sie die Installation und geben dann in der weiteren Konfiguration das vShield-Template, einen entsprechenden Datastore und die Netzwerkeinstellungen an. Außerdem ist der zu schützende vSwitch festzulegen.
Abbildung 15.17
Installation der vShield-VM auf dem ESX-Server
Ziel dieser Installation ist es, das vShield zwischen das physikalische Netzwerk und die virtuellen Adapter zu bringen, daher werden die virtuellen Switches und die virtuellen Maschinen umkonfiguriert (Abbildung 15.18). Eine genaue Zusammenfassung, welche Änderungen durchgeführt werden, wird noch vor der eigentlichen Durchführung angezeigt, und Sie können nochmals sicherstellen, dass alles korrekt konfiguriert ist (Abbildung 15.19).
907
15.11
15
Sicherheit
Abbildung 15.18
Zusammenfassung der vShield-Installation
Abbildung 15.19
Detailauflistung der Installationsschritte mit dem derzeitigen Fortschritt
Sobald die Installation läuft, können Sie in der Detailauflistung mitverfolgen, welche Schritte fertig, bearbeitet und noch offen sind. Dies trägt auch deutlich zum Verständnis der Funktionsweise von vShield Zones bei, daher sollten Sie sich dies auch im Detail einmal anschauen. Sobald die Installation erfolgreich durchgeführt wurde, sollten Sie die vShieldVM das Netzwerk automatisch nach neuen Systemen durchsuchen lassen, die geschützt werden oder die neu im Netzwerk erkannt werden.
908
VMware vShield Zones
Abbildung 15.20
Automatische Erkennung der VM-Daten mittels vShield
Abbildung 15.21
Ergebnisanzeige der einzelnen Scans
Den kompletten Installationsvorgang sollten Sie nun für jeden betroffenen ESXHost durchführen, damit je ein vShield auf den ESX-Hosts läuft. Allerdings ist es möglich, mehrere vShield Appliances gleichzeitig pro Host zu betreiben.
909
15.11
15
Sicherheit
Tipp Derzeit unterstützen die vShield Zones noch keine automatische Installation der vShield Appliances, wenn distributed vSwitches für die VMs genutzt werden. In diesem Fall müssen Sie vShield manuell installieren. Hinweise zu weiteren Problemen mit dvSwitches in Zusammenhang mit vShield Zones sind in der VMware Knowledge Base unter http://kb.vmware.com/kb/1012440zu finden.
15.11.2
VMotion, DRS und HA
Die vShield-Zone-VM darf auf keinen Fall zwischen Host-Systemen migriert werden, da diese auf den jeweiligen ESX-Host abgestimmt sind. Daher müssen Sie in den Eigenschaften von HA für die virtuelle Maschine (Virtual Machine Options) Folgendes einrichten: 왘
VM Restart Priority: Disabled
왘
Host Isolation Response: Leave VM powered on
Bei DRS müssen Sie die virtuelle vShield Zones Appliance beim Automation Level auf Disabled stellen. vShield Zones erlaubt es in der Standardkonfiguration nicht, dass geschützte virtuelle Maschinen zwischen ESX-Hosts migriert werden, das heißt, VMotion ist nicht mehr möglich. Dies passiert, da der vShield-protected-vSwitch, auf dem die geschützten virtuellen Maschinen verbunden, sind keine Uplinks besitzt und daher als Intranet-Switch erkannt wird. VMs an Intranet-vSwitches dürfen im Standard nicht migriert werden. Um dies zu erlauben, passen Sie die Datei C:\Documents and Settings\All Users\ Application Data\VMware\VMware vCenter\vpxd.cfg unterhalb der config-Sektion an: <migrate> false
Nach dem Abspeichern der Datei müssen Sie den VMware-vCenter-Dienst neu starten.
910
VMware vShield Zones
15.11.3
Ausfall der vShield-VM
Fällt die vShield-VM (nicht das Management) aus, so sind zwangsweise alle geschützten virtuellen Maschinen dieses Host-Systems nicht mehr in der Lage, mit der Außenwelt zu kommunizieren. Daher sollten Sie die vShield-VM auch immer mit der höchsten Priorität neu starten, falls es zum Ausfall des Host-Systems kommt. Führt Sie Wartungen durch, müssen Sie immer daran denken, die vShield-VM wie ein rohes Ei zu behandeln, damit es nicht zu Netzwerkstörungen kommt. Außerdem sollten Sie nie einfach an den Netzwerkkonfigurationen (virtuelle Netzwerkzuordnung) der vShield-Zone-VM »spielen«.
15.11.4
Regelkonfiguration, die VM-Wall
Die Firewall-Regeln zur Kontrolle der Netzwerkpakete können auf den Hierarchieebenen Datacenter, Cluster und Host verwalten. Es werden die IP-Layer 2/3 und 4 unterschieden.
Abbildung 15.22
Layer-2/3-Regelwerke unter vShield Zones
Layer 2/3 kontrolliert die ICMP- und IP-Kommunikation zwischen den VMs und zwischen der physikalischen Infrastruktur und den VMs. Somit ist es möglich, den IP-Verkehr einzuschränken, um etwa VMs in der DMZ zu schützen – z. B. erlauben Sie nur den internen Netzwerken, auf eine Proxy-VM in der DMZ zuzugreifen, während Sie alle anderen Zugriffe von außen verbieten.
Abbildung 15.23
Layer-4-Regelwerke unter vShield Zones
911
15.11
15
Sicherheit
Sehr häufig reicht es nicht aus, nur auf Layer 2/3 zu prüfen und zu kontrollieren, daher bietet vShield Zones auch die Möglichkeit, die Kommunikation auf Layer 4, also auf Portebene, zu kontrollieren. So ist es möglich, dediziert HTTP- oder SMTP-Netzwerkverkehr zu verbieten oder zu erlauben.
Abbildung 15.24
Aktive vShield-Regeln auf der jeweiligen VM
Wählen Sie die einzelnen VMs aus, können Sie die effektiven Firewall-Regeln für die virtuelle Maschine anzeigen. Die entsprechenden Regelwerke stammen von den übergeordneten Gruppen.
15.11.5
Reports – VM-Flow
Eine Firewall ist nur so nützlich wie das Reporting, das heißt, der Administrator muss jederzeit sehen können, welche Pakete eigentlich geblockt werden oder ob vielleicht auch erwünschte Pakete nicht durch die Firewall kommen.
Abbildung 15.25
912
Grafische Darstellung des Netzwerkverkehrs
VMs und der Virenschutz
VMware vShield Zones bietet über den vShield Manager daher auch die Möglichkeit, sich über die Auswahl VM Flow Reports anzeigen und exportieren zu lassen. Diese können Sie auf der entsprechenden Hierarchieebene (Datacenter, Cluster …) durch Eingabe eines Zeitfensters beliebig einschränken oder erweitern.
Abbildung 15.26
Listenauswertung des Netzwerkverkehrs
Neben der reinen Grafik existiert auch die für Administratoren zur schnellen Kommunikationskontrolle oft besser nutzbare Tabellenansicht. Gerade die geblockten Pakete sollten Sie des Öfteren kontrollieren.
15.12
VMs und der Virenschutz
Ein sehr unschönes Problem wurde in den letzten Jahren oft bei Kunden festgestellt, die in den VMs sehr aktive Virenschutzprodukte betreiben, da diese häufig Pattern-Updates laden und installieren. Dieses Problem wird beim Betrieb von vielen virtuellen Desktops enorm, da sich die Anzahl der Pattern-Updates aufgrund der hohen Anzahl virtueller Desktops nicht selten verhundertfacht.
15.12.1
Pattern-Updates
Dabei wurde auch festgestellt, dass manche Virenschutzsoftware zwar nur wenige MByte an Pattern-Aktualisierung lädt, allerdings das Entpacken der Pattern und Integrieren in die Virenschutzsoftware mehrere hundert MByte an Daten verändert. Dies stört bei einem Server nicht weiter, bei Hunderten oder Tausenden Desktops jedoch sehr, da der Storage im Hintergrund doch sehr belastet wird.
913
15.12
15
Sicherheit
Daher sollten Sie eine Trennung der Updatezyklen nach Server-Gruppen in Betracht ziehen, so dass immer nur Teile der Infrastruktur zur gleichen Zeit aktualisiert werden.
15.12.2
CPU-Last im Host
Ein weiteres Problem bei der Nutzung von Virenschutzsoftware in den Gästen liegt im sporadischen Lastverhalten der Gäste, was sich direkt auf die Host-Systeme und deren CPU-Last auswirkt. Hier wurde schon öfter beobachtet, dass der Task-Manager in den virtuellen Maschinen eine sehr geringe CPU-Nutzung anzeigte, während die Ansicht über esxtop oder die CPU-Grafiken des vSphereClients eine andere Wahrnehmung hin zur Volllast hatte. Es stellte sich in der Vergangenheit bereits öfter heraus, dass der Virenschutz eine gewisse Mitschuld hatte. VMware und natürlich auch die Virenschutzhersteller verbessern das Zusammenspiel jedoch stetig.
15.12.3
Antwortzeiten im Gast
Virtuelle Maschinen können aufgrund der gemeinsamen Nutzung der physikalischen Hardware im Gegensatz zu physikalischen Systemen niemals schneller als diese werden. Allerdings ist es auch nicht möglich, bei gleicher Ausstattung die gleichen Maximalergebnisse zu erreichen. Trotzdem sind die Leistungsunterschiede minimal und daher zumeist zu vernachlässigen. Bei der Nutzung von Virenschutzsoftware haben sich allerdings die etwas langsameren Antwortzeiten über das Netzwerk als Problem dargestellt, so dass z. B. ein Pattern-Update länger dauert als auf der Physik. Auch hier wieder der Hinweis: Bei 10 Servern merkt dies niemand, bei 1 000 wird es langsam sehr deutlich. Hier helfen nur Verbesserungen durch die Hersteller und eine Gruppierung der Systeme. Zum Beispiel ist eine Trennung der Updatezyklen nach Server-Gruppen sinnvoll, so dass immer nur 50 oder 100 Systeme aktualisiert werden und die nächsten 100 erst fünfzehn Minuten später.
15.12.4
File-Server mit Virenschutz
Die Königsklasse der Ressourcenvernichtung besteht natürlich im Betrieb eines virtuellen File-Servers mit eingeschaltetem Virenschutz. Natürlich ist ein virtueller File-Server bei gleicher Ausstattung etwas langsamer als ein physikalisches System. Dedizierte NAS-Produkte, wie beispielsweise NetApp Filer, sind nochmals deutlich schneller. Kommt der Virenschutz hinzu, so ist eine solche Lösung nur für kleinere Umgebungen (kleine Unternehmen oder Projektgruppen) mit wenigen Hundert Benutzern sinnvoll.
914
VMware VMsafe API
Allerdings verfügt man in größeren Umgebungen auch meist über dedizierte physikalische File-Server oder NAS-Systeme, die genau auf diese Anwendungsprofile ausgelegt sind. Aus einigen der oben genannten Gründe wurde die VMsafe API entwickelt, die Prozesse des Virenschutzes in virtuellen Infrastrukturen optimieren und absichern soll.
15.13
VMware VMsafe API
VMware hat mit vSphere die VMsafe API ins Leben gerufen, die auf einer Initiative begründet ist, dass Hersteller von Sicherheitssoftware die Kernel-Informationen und damit auch die Informationen über alle virtuellen Maschinen mitlesen können. Damit würde sich ein Agent im jedem Gastbetriebssystem erübrigen, was deutliche Last von den VMware-Systemen nähme.
Abbildung 15.27
Durch VMsafe geschützte VMs
Zum Beispiel sind Hersteller von Antivirensoftware durch die VMsafe API in der Lage, Informationen vom VMkernel direkt zugestellt zu bekommen und diese auf Viren und andere Schadsoftware zu analysieren. Dazu muss von der Idee nur eine Antivirusinstanz als virtuelle Appliance vorhanden sein und den Datenverkehr, die Hauptspeicherzugriffe, die Prozesse oder den Netzwerkverkehr überwachen und gegebenenfalls eingreifen. Die VMsafe API kann vom Endanwender nicht konfiguriert oder manipuliert werden und muss seitens VMware natürlich so sicher aufgestellt werden, dass keine Entwickler von Schadsoftware in den gleichen Genuss kommen können. Daher arbeitet VMware auch sehr eng mit Unternehmen wie McAfee, Symantec oder Trend Micro zusammen.
915
15.13
Der VMware Capacity Planner ist ein Werkzeug, das im Umfeld eines Migrationsvorhabens eingesetzt werden kann. Es unterstützt die IT durch Fakten bei ihren Entscheidungen und ermöglicht dadurch nachhaltige Planungssicherheit in Migrationsprojekten.
16
Kapazitätsplanung mit dem VMware Capacity Planner Autor dieses Kapitels ist Günter Baumgart, Consultico GmbH, [email protected]
Das nun folgende Kapitel beschäftigt sich mit dem VMware Capacity Planner und entstand zum Zeitpunkt, als die Version 2.6 des VMware Capacity Planner Data Managers für die Betrachtung von IT-Umgebungen eingesetzt wurde. In der Regel befinden sich unterschiedlichste Server in einem Unternehmen. Das können beispielsweise Mail-Server, File-Server, Datenbank-Server usw. sein. Jeder Server im Unternehmen stellt mindestens einen Dienst zur Verfügung. In den meisten Unternehmen hat sich im Laufe der Jahre die Anzahl der Dienste, die benötigt werden, dramatisch vergrößert. Durch diesen Zuwachs an effektiv nicht ausgelasteten Servern stoßen die Rechenzentren oder Server-Räume vielerorts an ihre Leistungsgrenzen. Oftmals teilen sich auch unterschiedlichste Unternehmen ein Rechenzentrum, wobei die Trennung der einzelnen Bereiche, die die Unternehmen benutzen, sehr häufig durch Gitterwände erfolgt. Hier kommt es dann auch durchaus vor, dass ein Bereich derart große Wärmemengen produziert, dass andere Bereiche stillgelegt werden müssen oder nur eingeschränkt genutzt werden können. Jede Höheneinheit in einem Rechenzentrum ist kostspielig und muss bezahlt werden. Das beschriebene Szenario der eingeschränkten Nutzung oder gar die Stilllegung von Stellfläche ist der absolute Kostengau für einen Rechenzentrumsbetreiber! Klimageräte, die Stromversorgung, Anschlüsse an das Unternehmens- oder Speichernetzwerk, Stellfläche für neue Server-Schränke etc., all diese Ressourcen sind begrenzt, und eine Aufrüstung sprengt oft den finanziellen Rahmen des IT-Etats.
917
16
Kapazitätsplanung mit dem VMware Capacity Planner
Spätestens an dieser Stelle gilt es nun zu überlegen, ob es Ansätze für die Virtualisierung von Server-Landschaften gibt, um durch Optimierung die Kosten im Rechenzentrum zu senken.
16.1
Erste Vorüberlegungen zu einem Migrationsprojekt
Entscheidet sich die Unternehmens-IT nun für eine Virtualisierung der physischen Systeme, löst sich das eine oder andere angesprochene Problem schnell auf. Nicht zuletzt dadurch, dass die Hardware, die zur Virtualisierung herangezogen wird, höchst effizient genutzt wird. Damit aber die zur Virtualisierung benötigte Hardware, wie beispielsweise Host und Storage, auch im Hinblick auf den Nutzungsgrad optimal verwendet wird, bedarf es unterschiedlichster Informationen. Die Frage, wie Host und Storage beschaffen sein müssen, kann natürlich nur beantwortet werden, wenn die späteren Belastungen, die durch die virtuellen Maschinen entstehen werden, vor dem Virtualisierungsvorhaben bereits bekannt sind. Sehr oft ist liegt der Nutzungsgrad – oder anders gesagt, die mittlere Auslastung eines Servers – zwischen fünf und fünfzehn Prozent. Natürlich gibt es immer wieder temporäre Spitzenlasten, die aber in den seltensten Fällen die volle Leistung moderner Server-Systeme ausschöpfen. Einige Server-Systeme lassen sich gar nicht so einfach virtualisieren, da Spezialhardware wie Faxkarten oder Ähnliches, in diesen Servern eingebaut sind. Hier scheint dann auf den ersten Blick keine Virtualisierung möglich zu sein. In derartigen Fällen müssen Sie über andere Lösungsmöglichkeiten nachdenken. In diesem Beispiel böte es sich an, die Faxkarte durch ein Faxmodem, das im lokalen Netzwerk erreichbar ist, zu ersetzen und dann den Server zu virtualisieren. Der virtuelle Fax-Server nutzt dann für den Faxempfang und -versand das Faxmodem im LAN. Hier denkt man auch sofort an Banking-Systeme, bei denen die Aufgabenstellung fast identisch ist. In diesem Zusammenhang stellt sich auch immer wieder die Frage, wie mit Dongles umzugehen ist. Auch hierbei ist es immer ratsam, zuerst einmal mit dem Hersteller der Software zu sprechen. In den meisten Fällen halten die Softwarehersteller bereits eine Lösung vor, um ihre Software auch in virtuellen Umgebungen zertifiziert betreiben zu können. Ebenfalls muss die Frage nach dem zukünftigen Wachstum im Zusammenhang mit Daten und Diensten im Vorfeld beantwortet werden. Überlegungen im Hinblick auf die Möglichkeit der Skalierung des Gesamtsystems sollten Sie an dieser Stelle ebenfalls mit in die Planungen einbeziehen.
918
Erste Vorüberlegungen zu einem Migrationsprojekt
Auch müssen Sie bei der Konzeption der virtuellen Infrastruktur die Ressourcen berücksichtigen, die für die Bereitstellung einer hochverfügbaren Lösung notwendig sind. Oftmals können die soeben genannten Punkte nicht hinreichend beantwortet werden. Nicht immer ist die Auslastung der zu virtualisierenden Systeme vollständig transparent, und Fragen wie »Zu welchem Zeitpunkt ist der Server wie belastet?« bleiben häufig unbeantwortet. Natürlich ist der Unternehmens-IT bekannt, dass z. B. während der Monatsübergänge oder anderer markanter Zeitpunkte in einem Unternehmen unter Umständen mit einem Anstieg der Last auf den Server-Systemen zu rechnen ist, aber genauere Aussagen dieser Art sind eher die Ausnahme. An dieser Stelle sei darauf hingewiesen, dass viele Virtualisierungsprojekte genau daran kranken, dass die Auslastung der zu virtualisierenden physischen ServerLandschaften im Vorfeld nicht genügend genau untersucht wurde. Ein weiterer interessanter Aspekt wäre, wenn der Load eines einzelnen Servers bezogen auf die Zeit bereits vor der Virtualisierung bekannt wäre. Lägen derartige Informationen vor, wäre es leicht möglich, die spätere Belastung der Hosts optimal auszuloten. Dies gilt selbstverständlich für alle zu virtualisierenden Systeme. Im nun folgenden Beispiel werden wir unabhängig von Taktraten und Benchmarks einen Sachverhalt beleuchten, der in der Praxis des Öfteren vorkommt. Der Server, der betrachtet wird, verfügt über zwei CPUs. Die CPUs des Systems werden im Mittel um die zehn Prozent genutzt. Außerdem sind die CPUs unterschiedlich stark ausgelastet; CPU0 wird deutlich höher belastet als CPU1. Der Dienst, der von diesem Server bereitgestellt wird, kann augenscheinlich ein Zweiwegesystem nicht optimal ausnutzen. Eine Balance in der Belastung der CPUs funktioniert also nicht vollständig. Kurz gesagt, haben wir eine minimal ausgelastete physische Zweiwegemaschine mit zwei unsymmetrisch belasteten CPUs, und dabei haben wir noch nicht einmal den Faktor der Taktfrequenz des Server-Systems in die Betrachtung einbezogen. Das heißt, die physische Maschine, die wir in diesem Beispiel betrachten, ist gänzlich ungeeignet, was Ausstattung und Dimensionierung angeht. Wäre es da nicht sinnvoll, den Einsatz dieser physischen Maschine zu überdenken und sie gegen eine besser an die Anforderungen des Dienstes angepasste Hardware auszutauschen?
919
16.1
16
Kapazitätsplanung mit dem VMware Capacity Planner
Würde der Dienst dieser physischen Maschine nun in eine virtuelle Maschine konvertiert werden, würden wir natürlich eine Einwegemaschine erstellen. Des Weiteren wäre die virtuelle CPU bei dieser virtuellen Maschine auch so konfiguriert, dass sie nur die Leistung garantiert, die vorher in der physischen Maschine genutzt wurde. Der eingangs genannte unter zehn Prozent liegende Nutzungsgrad in der physischen Umgebung läge dann in der virtuellen Umgebung wesentlich höher. Da ja die Ressourcen der virtuellen Maschine geringer dimensioniert wurden, verbesserte sich der Nutzungsgrad, was die Effizienz steigerte. Spätestens an dieser Stelle wird überdeutlich, dass eine Migration eines Environments umso erfolgreicher wird, je detailliertere Informationen bereits im Vorfeld über das Lastverhalten der Umgebung zur Verfügung stehen. In diesem Kontext ist es natürlich möglich, alle Daten, die für eine erfolgreiche Virtualisierung einer physischen Server-Umgebung benötigt werden, an den Servern abzufragen und manuell oder teilautomatisiert auszuwerten. Die Frage hierbei ist allerdings: Steht mir die erforderliche Zeit dafür zur Verfügung?
16.2
Arbeitsweise und Funktion des Capacity Planners
Der VMware Capacity Planner stellt sich als Framework dar (Abbildung 16.1) und besteht im Wesentlichen aus zwei Teilen: Zum einen handelt es sich um den Data Collector und zum anderen um das Information Warehouse bei VMware in Palo Alto im Silicon Valley. Der Data Collector ist eine physische x86/x64Maschine, auf der z. B. das Betriebssystem Microsoft Windows 2003 Server installiert wurde. Als Applikation wird VMware Data Collector installiert. Natürlich ist es erforderlich, die Applikation auch noch entsprechend der Rahmenbedingungen des Environments zu administrieren, aber dazu später mehr.
16.2.1
Data Collector und Information Warehouse
Der Data Collector wird in das zu analysierende Environment gebracht und im lokalen Unternehmensnetzwerk in Betrieb genommen. Nun steht dieser in dem zu analysierenden Environment und sammelt Informationen über die hier befindlichen Server. Der Data Collector arbeitet ohne den Einsatz von Agenten. Das heißt, es ist nicht erforderlich, zusätzliche Software auf einem der zu untersuchenden physischen Server zu installieren. Welche Server betrachtet werden und welche nicht, legen Sie ebenfalls im Zuge der bereits angesprochenen Administration des Data Kollektors fest.
920
Arbeitsweise und Funktion des Capacity Planners
16.2
Data Manager Modul • Benutzerschnittstelle des Daten Kollektors Collector Modul • Entdeckung von Systemen • Datensammlung • Synchonisation von Daten
Lokale Datenbank des Daten Kollektors
Internet
Data Collector Host
Unternehmensnetzwerk
Data Analyzer • Aggregation von Daten • Datenvergleich Dashboard • Analyse von Daten • Generierung von Berichten • Erstellen von Phantomszenarien
Abbildung 16.1
Datenbank des Data-Warehouse
Information Warehouse
Framework Capacity-Planning
Bei den Daten, die der Data Collector einsammelt, handelt es sich um Inventarisierungs- und Performance-Daten. Der Data Collector kann somit als die Datenquelle angesehen werden. Das Information Warehouse, die Datensenke, im Silicon Valley ist der Teil des Frameworks, der die Daten, die der Data Collector einsammelt, empfängt und aufbereitet. Das Information Warehouse ist eine gesicherte und kontrollierte zentrale Datenbank. In dieser Datenbank lagern die Daten, die alle im Einsatz befindlichen Datenkollektoren anliefern. Die Daten werden, bevor sie in die Datenbank aufgenommen werden, überprüft und bereinigt. Da alle Datenkollektoren weltweit ihre Daten in diese Datenbank transferieren, entsteht eine enorme Datenbasis, die auch zu Vergleichszwecken herangezogen werden kann. In frei einstellbaren zeitlichen Intervallen werden nun die Daten von der Quelle zur Senke übertragen (Abbildung 16.2). Die Übertragung der Daten erfolgt SSL-verschlüsselt über HTTP. In der Regel werden die Daten über einen Zeitraum von einem Monat gesammelt. Im Anschluss daran wird die Messung beendet bzw. das Sammeln der Daten eingestellt. Alle Messdaten stehen nun zur Auswertung im Information Warehouse bereit. In den nächsten Schritten werden die Daten dann anhand
921
16
Kapazitätsplanung mit dem VMware Capacity Planner
unterschiedlichster Kriterien analysiert und erläutert. Ein Data Collector kann durchschnittlich etwa 500 Zielsysteme im Netz überwachen. In einem Netzwerk können mehrere Datenkollektoren betrieben werden, so dass auch Server-Umgebungen mit einer weitaus größeren Anzahl an physischen Zielsystemen mit diesem Verfahren analysiert und betrachtet werden können. Information Warehouse
physische Zielsysteme
Data Collector Abbildung 16.2
Datenübertragung zum Information Warehouse
16.2.2 Collector-Modul Ein Data Collector wird, wie bereits erwähnt, auf einem Windows-System installiert. Er läuft als Windows-Service im Hintergrund. Der Data Collector setzt sich aus drei Teilen zusammen: einer lokalen Datenbank, dem Data-Manager-Modul und dem Collector-Modul. Das Collector-Modul des Data Collectors wird zur Entdeckung der physischen Server-Systeme im Netzwerk eingesetzt. Außerdem übernimmt es auch die Übertragung der Daten zum Information Warehouse. Es sammelt detaillierte Inventarisierungsdaten über die Hardware und die installierte Software auf den Zielsystemen. Das Collector-Modul sammelt auch die wichtigsten Performance-Daten der zu untersuchenden Server. Es sei an dieser Stelle abermals darauf hingewiesen, dass es nicht erforderlich ist, zur Gewinnung dieser Daten Agenten auf den zu untersuchenden physischen Ziel-Server-Systemen zu installieren.
922
Arbeitsweise und Funktion des Capacity Planners
Bei den Zielsystemen kann es sich um Windows-, Linux- oder Unix-Systeme handeln. Bei Windows-Systemen werden die Daten mittels der Standard-Interfaces ermittelt. Wenn es sich bei den Zielsystemen um Linux- oder Unix-Systeme handelt, werden die Leistungs- und Inventarisierungsdaten unter Zuhilfenahme einfacher Skripte ermittelt. Hierzu wird eine Verbindung über Secure Shell (SSH) zum Zielsystem aufgebaut. Der Data Collector verfügt über einen Task- bzw. Job-Planer. Dieser Scheduler ermöglicht ein zeitgesteuertes Ausführen von Umgebungsanalyse-, Inventarisierungs-, Leistungsdatenermittlungs- und Datensynchronisationsmodulen. Die zeitlichen Intervalle sind sehr fein granulierbar, wie in Abbildung 16.3 zu erkennen ist.
Abbildung 16.3
Job-Planer
16.2.3 Data-Manager-Modul Der Benutzer arbeitet, wie bereits erwähnt, mit der grafischen Benutzerschnittstelle des Data Collectors, dem Data Manager. Über diese Benutzerschnittstelle können Sie das System konfigurieren und administrieren. Hierzu gehören sowohl die Erstellung und Konfiguration von Collection-Jobs als auch die Eingabe von Benutzerkennung und Kennwortkombinationen für den Zugang zu den Zielsystemen.
923
16.2
16
Kapazitätsplanung mit dem VMware Capacity Planner
Der Datenmanager erlaubt dem Benutzer im ersten Schritt, bevor die automatischen bzw. die zeitgesteuerten Jobs abgearbeitet werden, erste manuelle Überprüfungen. Konkret bedeutet dies, dass Sie u. a. Verbindungstests als auch gezielte Inventarisierungen und Performance-Messungen der zu untersuchenden Systeme manuell durchführen können. Eine Überprüfung der Datensynchronisation zwischen dem Data Collector und dem Information Warehouse ist ebenfalls mit dem Data Manager möglich. Auch ermöglicht der Data Manager dem Anwender eine erste Sicht auf die ermittelten Rohdaten, bevor sie manuell oder mittels Automatismen in das Information Warehouse übertragen werden.
16.2.4 Data Analyzer Der Data Analyzer stellt das Herzstück, die Analytical Engine, des Information Warehouse dar. Er ermöglicht Auswertungen bei der Kapazitätsplanung. Hierbei werden unterschiedlichste Verfahren angewendet, um Aussagen im Hinblick auf Aggregation, Trendanalyse und Benchmarking bezogen auf die Messwerte einer physischen Umgebung zu tätigen. Das heißt, der Data Analyzer unterstützt die Analyse von Belastungsprofilen und die Erstellung von Modellszenarien. Durch derartige Modellszenarien, die auch als Phantomszenarien bezeichnet werden, ist es möglich, Empfehlungen dahingehend auszusprechen, welche virtuellen Maschinen auf einem Host optimal zusammenpassen.
16.2.5 Dashboard Das Dashboard ist die webbasierte Benutzerschnittstelle zum Data Warehouse und zum Data Analyzer. Es ermöglicht den Zugriff auf die vom Data Collector gewonnenen Daten aus der physischen Umgebung. Außerdem regelt es den Zugriff auf die Funktionen des Data Analyzers. Auch gewährleistet das Dashboard den direkten Zugriff auf den Data Collector und stellt die unterschiedlichsten Informationen über Capacity-Planning zur Verfügung. Die gesamte projektbezogene Organisation, die erforderlich ist, um ein Data-Collector-Projekt durchzuführen, kann mit dem Dashboard umgesetzt werden. Unter anderem bedeutet das im Einzelnen: 왘
Anzeige des Status der Datenkollektierung
왘
Remote-Steuerung von unterschiedlichen Tasks des Data Collectors
왘
Bereitstellung von Templates für Analyse und Synthese
왘
Darstellung der kollektierten Daten in unterschiedlichster Art und Weise
왘
Szenariomodellierung
924
Die Arbeit mit dem Data Collector
왘
Performance-Monitoring und Trendanalyse
왘
Entdeckung und Meldung von Anomalien und Alarmen
왘
Aufzeigen von Konsolidierungsmöglichkeiten
왘
Erkennen von Systemen, die sich nicht zur Konsolidierung eignen
왘
Erkennen von veralteten und unbrauchbaren Zielsystemen
16.3
Der Capacity Planner
Nachfolgend wird die Arbeitsweise mit dem Capacity Planner näher beschrieben. In den vorangegangenen Abschnitten wurden die Funktionen der einzelnen Module des Capacity-Planner-Frameworks zum besseren Verständnis des Gesamtbildes kurz erläutert. Dazu war es notwendig, die beiden Hauptbestandteile des Capacity Planners, den Data Collector und das Information Warehouse, in ihre Bestandteile zu zerlegen. Im weiteren Verlauf sehe ich davon ab, über das Data-Manager-Modul, das Collector-Modul oder die Data-Collector-Datenbank zu sprechen. Gleiches gilt für das Information Warehouse. Auch hier unterscheiden wir nicht mehr zwischen dem Data Analyzer, dem Dashboard und der Information-Warehouse-Datenbank.
16.4
Die Arbeit mit dem Data Collector
16.4.1 Auffinden der Zielsysteme Im ersten Schritt wird der Data Collector dazu verwendet, alle Server der zu vermessenden Umgebung ausfindig zu machen. Damit er diese Aufgabe auch erfüllen kann, gibt es unterschiedliche Vorgehensweisen. Zum einen ist es möglich, die Adressen und Zugangsdaten aller zu untersuchenden Server mittels Datei in den Data Collector zu importieren. Handelt es sich um wenige zu untersuchende Systeme, können Sie die Adress- und Zugangsdaten dem Data Collector auch manuell angeben. Eine weitere Möglichkeit, die zu untersuchenden Systeme zu erkennen, besteht darin, die Server mittels LAN-Manager und/oder Active Directory im Netzwerk zu finden. Sollten diese beiden Methoden nicht zum gewünschten Erfolg führen, gibt es auch noch den Weg, das Netzwerk im Hinblick auf bestimmte IP-Ranges (Hauptsächlich für Linux/Unix Discovery) zu durchsuchen. Letztendlich wird in einem komplexen Environment, das untersucht wird, immer eine Kombination aus den genannten Verfahren zur Auffindung der Zielsysteme angewendet werden.
925
16.4
16
Kapazitätsplanung mit dem VMware Capacity Planner
16.4.2 Verbindungsaufbau zu den Zielsystemen Im nächsten Schritt, nachdem alle in die Messung einbezogenen Systeme gefunden und die Anmeldeinformationen für die Zielsysteme im Data Collector hinterlegt wurden, können Sie damit beginnen, Verbindungstests zu den einzelnen Zielsystemen durchzuführen. Die Verbindungstests verwenden unterschiedlichste Methoden, je nachdem, welches Betriebssystem auf dem Zielsystem installiert ist. Methoden zur Datengewinnung im Windows-Umfeld Im Windows-Umfeld werden unterschiedlichste Verfahren genutzt, um die Informationen über die Server zu sammeln. Aus diesem Grund ist ein einwandfreies Funktionieren der im Folgenden aufgeführten Methoden Voraussetzung für eine korrekte Funktion des Data Collectors. 왘
name resolution / ping
왘
traceroute / tracert
왘
read IPC$ map / share
왘
read remote registry
왘
access WMI namespace
왘
access performance manager
Methoden zur Datengewinnung bei Unix und Linux Im Umfeld von Unix und Linux werden die folgenden Verfahren benutzt. Auch hier gilt wieder: Ein einwandfreies Funktionieren der aufgeführten Methoden ist Voraussetzung für eine fehlerfreie Funktion des Data Collectors. 왘
name resolution / ping
왘
traceroute / traceroute
왘
SSH secure shell execution
Bei Linux- und Unix-Systemen ist es zusätzlich notwendig, den SSH-Sicherheitsschlüssel lokal im Data Collector zu hinterlegen. Zu diesem Zweck öffnen Sie über den Data Manager ein Unix-Terminal zum entsprechenden Server. Es muss für alle Methoden garantiert sein, dass die aufgelisteten Verfahren ohne Einschränkung während der Kollektierungsphase zwischen Data Collector und den Zielsystemen genutzt werden können.
926
Die Arbeit mit dem Data Collector
16.4.3 Manuelle Inventarisierung Nachdem nun sichergestellt wurde, dass die Verbindung zwischen dem Data Collector und den Nodes bzw. Zielsystemen verfügbar ist, können Sie nun manuell einmalig einen ersten vollständigen Inventarisierungs-Task zu Testzwecken anstoßen. Nodes bzw. Zielsysteme, die durch den Discovery-Task erfolgreich identifiziert wurden, werden nun inventarisiert. Hierbei wird sowohl die Hardware als auch die auf dem Zielsystem installierte Software aufgenommen. Die Inventarisierung bzw. Systemanalyse bezieht sich auf den Zeitpunkt der Durchführung. Das heißt: Erfolgt nach der Inventarisierung eine Veränderung am Zielsystem, wird diese natürlich auch erst beim nächsten Inventarisierungsdurchlauf dokumentiert. Die Inventarisierungsinformationen werden gewöhnlich im ersten Schritt der Untersuchung mittels »Windows Management Instrumentation« (WMI) und dann im nächsten Schritt aus der Registry des Zielsystems ermittelt. Betreiben Sie die Zielsysteme unter Unix oder Linux, erfolgt die Inventarisierung über Secure Shell (SSH). An dieser Stelle stellt sich nun die Frage, worauf das Zielsystem untersucht wird. Im Wesentlichen werden die Punkte Mainboard und Chassis, Prozessor, Memory, Laufwerke und Adapter, File-System, NetzwerkInterface, Applikationen und Services analysiert, wie in Abbildung 16.4 zu erkennen ist.
Abbildung 16.4 Merkmale des Ziel-Servers »TEST-SERVER« im Hinblick auf das Betriebssystem und die Hardware
Die Inventarisierung erfolgt multithreaded. Sollte die Inventarisierung mit der einen Methode nicht erfolgreich abgeschlossen werden können, wird eine andere Methode zur Informationsgewinnung angewendet (»auto-detect method«). Dadurch wird sichergestellt, dass eine gewisse Redundanz in diesem Verfahren enthalten ist. Der Vorgang der Inventarisierung kann je nach Komplexitätsgrad des Zielsystems eine gewisse Zeitspanne in Anspruch nehmen. Zur
927
16.4
16
Kapazitätsplanung mit dem VMware Capacity Planner
Überprüfung des Inventarisierungsvorganges wird für jede Inventarisierung eines einzelnen Zielsystems eine Protokolldatei (Log-File) auf dem Data Collector abgelegt.
16.4.4 Manuelle Leistungsdatenermittlung Auch bei der Leistungsdatenermittlung ist eine Verbindung zu den Zielsystemen, wie in Abschnitt 16.4.3, »Manuelle Inventarisierung«, beschrieben, sicherzustellen. Sind die Zielsysteme also erreichbar, können Sie nun wiederum exemplarisch einen manuellen Leistungsmessungs-Task anstoßen. Bei allen Nodes, die durch den Discovery-Task erfolgreich identifiziert wurden, wird nun eine Performance-Messung durchgeführt. Das Verfahren zur Leistungsdatenermittlung generiert statistische Daten der Zielsysteme. Die Gewinnung von Leistungsdaten der Zielsysteme geschieht bei Systemen, die unter Windows laufen, über den Performance Monitor (Perfmon). Bei Unix- oder Linux-Systemen werden die Leistungsdaten durch das Ausführen von speziellen Skripten ermittelt. Der Prozess der Leistungsmessung verbindet sich bei zu vermessenden Unix- oder Linux-Zielsystemen zuerst über eine SecureShell-(SSH-)Verbindung. Im Anschluss daran werden unterschiedliche Skripte ausgeführt, um die benötigten Messwerte am Zielsystem abzufragen. Die Daten werden in einem weiteren Prozessschritt dann mittels SCP (Secure Copy Protokoll) an den Data Collector zurückgegeben. Der Leistungsdatenbericht enthält folgende Messungen: 왘
CPU-Statistik
왘
Prozessorauslastung
왘
Processor Queue Length
왘
Memory-Auslastung
왘
Network-Auslastung
왘
physische Disk-Auslastung
왘
Logical Disk Size
16.4.5 Die Datensynchronisationsfunktion des Data Collectors Bevor eine Datensynchronisation zwischen Data Collector und Information Warehouse über eine gesicherte Verbindung durchgeführt wird, wird der Besitzer der Daten mittels Pseudonym anonymisiert. Dieses Verfahren bietet bereits eine gewisse Basissicherheit. Um die Forderung nach Anonymität noch weiter zu erhöhen, ist es möglich, zusätzlich Server- und Domänennamen zu verbergen.
928
Die Arbeit mit dem Data Collector
Durch diese Maßnahmen wird die Forderung nach Vertraulichkeit und Integrität während der Synchronisation der Daten erfüllt. Damit Sie sich ein Bild vom Ablauf des Synchronisationsprozesses des Data Collectors machen können, erläutern wir diesen nun näher. Im ersten Schritt werden die Dateien z. B. aus einem erfolgreichen Inventarisierungs- und Leistungsdatenermittlungsprozess in einem Unterverzeichnis des Data Collectors mit der Bezeichnung Outbox abgelegt. Die Namen der Dateien, die die Inventarisierungsdaten enthalten, beginnen mit Inv_, und diejenigen der Dateien mit den Leistungsdaten beginnen mit Stats_. An dieser Stelle sei darauf hingewiesen, dass sämtliche Aktionen, die der Data Collector ausführt, in der Message-Box des Data Collectors protokolliert werden. In Schritt zwei wird ein Log-File gespeichert. Dieses Log-File enthält u. a. die Ausgabe der Message-Box des Data Collectors. Anschließend wird der Inhalt der Outbox an das Information Warehouse übertragen und eine Kopie aller Files, die die Inventarisierungs-, Leistungs- und Log-Daten enthalten, in ein Archivierungsverzeichnis geschrieben. Im Anschluss daran wird der aktuelle Inhalt der Outbox gelöscht.
Abbildung 16.5
Optionale Einstellungen zur Datensynchronisation
Falls Sie die optionale Funktion (Abbildung 16.5), Remote-Konfiguration des Data Collectors mittels Information Warehouse, nutzen, werden diesbezügliche Informationen in diesem Schritt zurückübertragen. Für den Fall, dass Sie die Funktionalität der automatischen Produktupdates aktiviert haben, werden ebenfalls entsprechende Updates für den Data Collector übertragen.
16.4.6 Automatisierte Ausführung von Jobs Die zeitgesteuerte Ausführung von Aufgaben (Abbildung 16.6) ermöglicht es, die bereits beschriebenen Einzelaktionen wie Verbindungsaufbau zu den Zielsyste-
929
16.4
16
Kapazitätsplanung mit dem VMware Capacity Planner
men, Inventarisierung der Zielsysteme, Leistungsdatenmessung an den Zielsystemen und Datensynchronisationsfunktion zwischen Data Collector und Information Warehouse zu automatisieren.
Abbildung 16.6
Zeitgesteuerte Jobausführung
Wie bereits in Abbildung 16.6 dargestellt, ist die zeitliche Steuerung der automatischen Ausführung von Jobs sehr fein einstellbar. Es können Daten zu unterschiedlichsten Zeitpunkten und Intervallen gemessen werden. Die zeitliche Abfolge bei der Messwerterfassung hängt natürlich unmittelbar damit zusammen, inwieweit Änderungen an den Zielsystemen stattfinden. Normalerweise sind Veränderungen in Bezug auf Inventar im Server-Umfeld eher selten anzutreffen. Ziehen wir das Patchen der Systeme in diesem Zusammenhang noch in Betracht, sollte in der Regel eine tägliche Inventarisierung völlig ausreichend sein. Im Falle der Leistungsdatenermittlung ist sicherlich eine wesentlich häufigere Durchführung des Jobs notwendig. In Abbildung 16.6 wurde die Ausführung der Jobs Datensynchronisation und Leistungsdatenmessung auf alle 20 Minuten eingestellt. Es ist nicht unbedingt erforderlich, die Datensynchronisation synchron zur Leistungsdatenmessung auszuführen. Bei der Leistungsdatenermittlung trifft die eingangs aufgestellte These, dass ein direkter Zusammenhang zwischen Mess- und Belastungsintervall der Zielsysteme besteht, zu. Hier gilt es, sich vorab die zu vermessenden Nodes näher anzuschauen und die Automation entsprechend anzupassen.
930
Die Arbeit mit dem Data Collector
16.4.7 Registrierung des Data Collectors im Information Warehouse Die Data-Collector-System-ID wurde zum Zeitpunkt der Installation des Data Collectors erzeugt und in der Windows Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VMware, Inc.\ VMware Capacity Planner\Common\Settings
abgelegt. Während der Installation des Data Collectors wurde ebenfalls eine sogenannte Database-ID erzeugt. Die Database-ID kann innerhalb des Data Collectors angezeigt werden (Abbildung 16.7). Die Registrierung des Data Collectors im Information Warehouse erfolgt, indem Sie die Database-ID im Dashboard des Information Warehouse in ein entsprechendes Formular eintragen. Dieses Formular enthält auch die Company-ID. Nachdem die Eintragung erfolgt ist, wird im Information Warehouse die System-ID des Data Collector ermittelt und über das Dashboard angezeigt. Der Vorgang der Registrierung des Data Collectors im Information Warehouse ist somit abgeschlossen.
Abbildung 16.7
Registrierung des Data Collectors am Information Warehouse
Nun existiert eine Zuordnung zwischen der Company-ID, der System-ID und der Database-ID. Die Inventarisierungs-, Performance- und Log-Files, die der Data Collector zum Information Warehouse überträgt, werden zur Identifizierung mit der System-ID und der Zeit gestempelt. Dieses Verfahren ermöglicht eine anonymisierte Datensynchronisation zwischen dem Data Collector und dem Information Warehouse. Die Nomenklatur der Dateien stellt sich wie folgt dar: 왘
Leistungsdaten: Stats_<SystemID>_.csv
왘
Inventarisierungsdaten: Inv_<SystemID>_.csv
왘
Protokolldatei: LogFile_<SystemID>_.log
931
16.4
16
Kapazitätsplanung mit dem VMware Capacity Planner
16.5
Das Dashboard im Detail
Das Dashboard des Capacity Planners ist, wie bereits eingangs erläutert, eine Anwendung, die von VMware gehostet und über das Internet zur Verfügung gestellt wird. Dadurch ist es möglich, dass mittels Browser von jedem Internetanschluss aus direkt auf das Dashboard zugegriffen werden kann. Aufbau und Benutzung des Dashboards Das Dashboard stellt dem Benutzer über ein Menü (Abbildung 16.8) sechs unterschiedliche Bereiche zur Verfügung. Die einzelnen Bereiche erlauben einerseits die Verwaltung des Accounts und den Zugriff auf die über die Zielsysteme gesammelten Daten und ermöglichen andererseits, auf die Auswertungsfunktionalität des Dashboards zuzugreifen.
Abbildung 16.8
Die einzelnen Rubriken des Dashboards im Information Warehouse
Den Zugriff auf das Dashboard und die Menüoptionen können Sie, falls unterschiedliche Nutzer an der Auswertung der Daten der Zielsysteme oder der Überwachung des Kapazitätsplanungsprojektes beteiligt sind, auch durch die Vergabe von Policies regeln. So ist es z. B. denkbar, dass der Hauptadministrator einen Read-only-User erstellt, der nur eingeschränkt im Dashboard agieren kann. Hierbei kann ein Benutzer, der vom Hauptadministrator erstellt und mit administrativen Rechten ausgestattet wurde, sämtliche Funktionalitäten des Dashboards nutzen. Die Funktionen der einzelnen Bereiche des Dashboards, die im Folgenden näher erläutert werden, sind von ganz unterschiedlicher Art. Dashboards Der Bereich Dashboards gestattet einen Überblick in Form von Statistiken über den Status der gemessenen Server (Abbildung 16.9) sowie des Inventars und der Leistungsdaten aller Zielsysteme. Außerdem können Sie in diesem Bereich unterschiedlichste Überprüfungen vornehmen. Im Einzelnen sind das Informationen darüber, wann und welche Daten vom Data Collector zum Dashboard gesendet wurden, ob Daten verworfen wurden oder wie die gewonnenen Daten sich im Detail darstellen.
932
Das Dashboard im Detail
Abbildung 16.9
Gesamtüberblick über den Status der gemessenen Server
Inventory Beim Inventory geht es um die Bereitstellung der Inventarisierungsdaten der Zielsysteme. Die Inventarisierungsdaten werden üblicherweise in drei Gruppen unterteilt: 1. Enterprise Summary 2. Applications Services File-Systems 3. Chassis Processors Memory Drives Drive Controllers Network Interface Cards Asset Information
933
16.5
16
Kapazitätsplanung mit dem VMware Capacity Planner
Enterprise Summary (Abbildung 16.10) gibt einen guten Überblick über die zu inventarisierenden Zielsysteme sowie deren Domain-Zugehörigkeit.
Abbildung 16.10
Zu inventarisierende Server-Systeme
Unter Applications werden alle auf den Zielsystemen installierten Applikationen aufgelistet, so dass Sie sich einen vollständigen Überblick über den Installationszustand verschaffen können. Die auf den Zielsystemen laufenden Services sind unter Services zu finden. File-Systems ermöglicht es dem Nutzer des Dashboards, alle File-Systems, die den Zielsystemen zur Verfügung stehen, zu analysieren. In der dritten Gruppe sind, wie in einem der früheren Kapitel bereits beschrieben, die Hardware-Inventarisierungsdaten zu finden. Mit dem Punkt Asset Information fügen Sie den Zielsystemen weitere Inventarisierungsinformationen wie Anschaffungsdatum, Beschaffungspreis oder monatliche Kosten für Leasing bei. Performance Von den Hunderten unterschiedlichster Arten von Leistungsdaten, die aus den Zielsystemen gewonnen werden könnten, werden effektiv nur wenige benötigt. Da dem Capacity Planner durch die Inventarisierung bekannt ist, welche Soft-
934
Das Dashboard im Detail
ware auf den Zielsystemen installiert ist, berücksichtigt er auch nur die Leistungsindikatoren, die in direktem Zusammenhang mit der installierten Software stehen. Dadurch werden auf höchst effiziente Weise nur die Messwerte genommen, die tatsächlich benötigt werden. Es werden für jeden Indikator Minimal-, Maximal- und Durchschnittswerte aufgezeichnet. 1. Enterprise Summary 2. Forecast Critical Processors Server Processors Balance Server Processors Load Trends 3. Performance Groups Im Menüpunkt Enterprise Summary können Sie die gemessenen Leistungsdaten der Zielsysteme mit den Industriedurchschnittswerten des Information Warehouse sowie den darin hinterlegten Benchmarks von Softwareherstellern gegenüberstellen. Die Industriedurchschnittswerte setzen sich aus allen Daten der letzten vier Wochen zusammen, über die das Information Warehouse verfügt. Dadurch können Systeme identifiziert werden, die signifikant vom Industriedurchschnitt abweichen. In einer tabellarischen Darstellung werden die vom Data Collector gemessenen Basisleistungswerte den entsprechenden Industriedurchschnittswerten gegenübergestellt und Alarme sowie Anomalien farbig hervorgehoben (Abbildung 16.11).
Abbildung 16.11 Unter Performance Summary wurde innerhalb von Data Filter Performance Counters auf MS SQL Server gestellt.
Hierbei steht Rot für Alarme. Alarme treten auf, wenn die vom Data Collector gelieferten Messwerte die von den Softwareherstellern hinterlegten Schwellenwerte überschreiten. Gelb hinterlegte Felder stehen für Anomalien, die auftreten, wenn die Messwerte zu stark von den Industriedurchschnittswerten abweichen. Die Funktion Forecast Critical Processors identifiziert die kritischen Server und ermöglicht dann den Einstieg in die nähere Untersuchung der einzelnen Server und gibt einen Ausblick auf die zukünftige Entwicklung (Abbildung 16.12). Nehmen wir einmal an, dass einer der zu betrachtenden Server als kritisches Sys-
935
16.5
Kapazitätsplanung mit dem VMware Capacity Planner
tem eingestuft wurde. In Forecast Critical Processors sehen wir nun detailliert, in tabellarischer als auch in grafischer Darstellung, welche Indikatoren betroffen sind und wie sie sich in Kürze entwickeln werden. Prime Time Average
Forecast
60 50 Pages/sec
16
40 30 20 10 0
04/19/08
04/26/08
05/03/2008
05/10/08
Abbildung 16.12 Der helle Graph stellt die voraussichtliche Entwicklung eines erhöhten Paging-Aufkommens dar.
Das Dashboard erstellt eine Vorhersage und zeigt die zukünftige Entwicklung der betroffenen Indikatoren auf. Mittels Server Processors Balance werden die Unterschiede bei den Nutzungsgraden der einzelnen CPUs respektive CPU-Kerne eines Servers, die als äußerst signifikant in Erscheinung treten, gekennzeichnet. In der aktuellen Version der Server Processors Balance wird davon ausgegangen, dass physische Server, die zur Disposition stehen, maximal acht CPUs besitzen, unabhängig davon, ob es sich um logische oder physische Kerne handelt. Somit wird eine CPU, die über einen physischen Kern mit Hyperthreading- bzw. Multithreading-Implementierung verfügt, in der Auswertung als zwei getrennte CPUs dargestellt. Im Tabellenausschnitt (Abbildung 16.13) sind die Leistungswerte der CPUs einiger der physischen Server, die der zu untersuchenden Gruppe angehören, zu sehen. Die mit einer stärkeren Umrahmung gekennzeichneten Bereiche zeigen die eingangs erwähnten signifikant unterschiedlichen Prozessorauslastungen der zu untersuchenden Server-Systeme.
Abbildung 16.13
Unterschiedliche Belastung der CPUs eines Servers
In unserem Beispiel gilt es nun zu beachten, dass die Server K1 und K2 (Abbildung 16.13) mit CPUs bestückt sind, die über einen physischen Kern mit Hyperthrea-
936
Das Dashboard im Detail
ding-Erweiterung verfügen, die CPU von K3 jedoch nicht. Die Processor Balance Table stellt sich nun wie in Abbildung 16.14 dar.
Abbildung 16.14
Server mit und ohne Hyperthreading-CPUs
Die erste physische CPU von K1 wird stark genutzt, die zweite physische CPU in wesentlich geringerem Umfang. In der Tabelle (Abbildung 16.13) stellen CPU0 und CPU1 jeweils einen logischen Kern der ersten physischen CPU dar. CPU2 und CPU3 von K1 bilden die zweite physische CPU des Servers. Diese zweite CPU ist gegenüber der ersten CPU in geringerem Umfang ausgelastet. Derartige Sachverhalte deuten oftmals darauf hin, dass die Dienste der physischen Systeme keine optimale Nutzung im Hinblick auf den Einsatz von Multiprozessor- bzw. Multikernsystemen und Hyperthreading-Implementierung gewährleisten. Eine weitere Möglichkeit, sich die physischen Server anzuschauen, ist die Überprüfung mittels Processors Load. Die Untersuchung der Prozessorauslastung wird ebenfalls über eine Tabelle (Abbildung 16.15) ermöglicht. Sie gibt Aufschluss darüber, wie hoch die Auslastung während der Business Hours (Hauptgeschäftszeit zwischen 7 Uhr und 18 Uhr) und der Peak Hour (Hauptbelastungszeit) ist.
Abbildung 16.15
Prozessorauslastung bezogen auf die volle Stunde
Die Spalte CPUs gibt an, wie viele CPUs ein Server enthält. Der Wert zeigt ausschließlich physische Kerne an. Unter MHz wird die Taktfrequenz der CPU angezeigt. Business Hours stellt dar, wo die mittlere Auslastung der CPU während der Geschäftszeit liegt, und Peak Load informiert über die mittlere Belastung während der Hauptbelastungszeit. Die Peak Hour steht für eine Stunde innerhalb des 24 Stundenrhythmus, eine 1 bedeutet also 1 Uhr, eine 0 bedeutet 0 Uhr, und die 17 steht für 17 Uhr. Die Performance-Trend-Analyse Trends zeigt die acht Hauptleistungsindikatoren eines physischen Server-Systems über einen Messzeitraum von bis zu 13 Wochen an (Abbildung 16.16). Die Darstellung der Hauptleistungsindikatoren ist so skaliert, dass alle acht Parameter in einem Diagramm dargestellt werden können. Hierdurch wird es möglich, alle Hauptleistungsindikatoren über die gleiche Zeitspanne zu beobachten. Geht zum Beispiel aus dem Diagramm eine hohe Belas-
937
16.5
Kapazitätsplanung mit dem VMware Capacity Planner
tung der CPU zeitgleich mit hohem Aufkommen an Memory-Paging hervor, können Sie daraus schließen, dass nicht ein Dienst oder eine Applikation das System überlastet, sondern aller Voraussicht nach ein Mangel an Hauptspeicher die Ursache für das Verhalten des Systems ist. Oftmals können Sie genau an diesem Sachverhalt, nämlich dass zwei oder mehr Indikatoren zeitgleich ein ähnliches Verhaltensmuster aufweisen, erkennen, dass eine Anomalie vorliegt. Memory ()/Available Bytes (x10000000) System()/Processor Queue Length (x.001) Paging File(_total)/% Usage PhysicalDisk(_total)/Avg. Disk Queue Length (x.01) Memory()/Cache Bytes (x10000000)
Processor(_total)/% Processor Time (x.1) Memory()/Pages/sec PhysicalDisk(_total)/% Disc Time (x.1) Server()/Bytes Total/sec (x1000)
100 75 Statistics
16
50 25 0
04/19/08
04/26/08
05/03/08
Week
Abbildung 16.16
Trendanzeige der acht Hauptleistungsindikatoren
Analyze Bevor Sie die einzelnen Systeme optimieren können, müssen Sie erst einmal herausfinden, welche Systeme und Applikationen überhaupt Performance-Probleme haben. Wie in früheren Abschnitten bereits erläutert, überprüft das Dashboard des Capacity Planners, wie die Server-Daten im Vergleich zu Hersteller-Benchmarks und industriellen Mittelwerten stehen. Hier noch einmal zur Erinnerung: Anomalien liegen die industriellen Mittelwerten zugrunde und Alarmen die Benchmarks der Hersteller. Server und Applikationen, die außerhalb der üblichen Parameter arbeiten, werden gekennzeichnet. Außerdem werden diejenigen Systeme identifiziert, die ihre Ressourcen unverhältnismäßig verbrauchen oder diese nicht effizient nutzen. Also werden die Daten in tabellarischer Form angezeigt, und Sie können sie nach Belieben sortieren. Die Indikatoren, bei denen die Hersteller-Benchmarks oder die generischen industriellen Mittelwerte überschritten wurden, werden mit einem Flag versehen.
938
Das Dashboard im Detail
Diese Kennzeichnung ermöglicht das genaue Erkennen der Schwächen der Systeme. Hierdurch können Sie z. B. feststellen, welche Dienste sich für eine Konsolidierung eignen. Auch erkennen Sie in diesem Bereich der Untersuchung inwieweit Sie physische Systeme verändern sollten, um eventuelle Schwächen der Systeme zu kompensieren. In einem nächsten Schritt können Sie dann das physische System entsprechend verändern. Im Anschluss an eine solche Maßnahme wird dann eine erneute Messung unter Umständen zeigen, dass der Mangel behoben ist und eine Migration unter den aktuellen Aspekten dann durchaus sinnvoll sein könnte. Die vergangenen vier Wochen stehen zur Auswertung der Daten im Bereich Anomalien und Alarme zur Verfügung. Über eine Filterfunktion ist es möglich, jeweils eine der vergangenen vier Wochen für eine Analyse auszuwählen. Wie in den entsprechenden Tabellen (Abbildung 16.17 und Abbildung 16.18) zu sehen ist, werden alle Zielsysteme, die Anomalien oder Alarme aufweisen, gelistet. Hierbei werden die Anomalien oder Alarme nochmals unterschiedlich gekennzeichnet, je nachdem, wie stark die Werte vom Schwellenwert abweichen.
Abbildung 16.17
Anomalien
Überschreitet z. B. ein Indikator den Schwellenwert des generisch industriellen Mittelwertes, wird er in der entsprechenden Tabelle (Abbildung 16.18) durch ein rotes Ausrufungszeichen gekennzeichnet. Die Überschreitung des Thresholds durch den Prime Time Average ist im vorliegenden Fall überdeutlich.
Abbildung 16.18
Auflistung aller Anomalien eines Zielsystems
Der Mittelwert aller Standard Deviations (Abbildung 16.18) eines Zielsystems entspricht dem Average Anomaly Score (Abbildung 16.17), wobei Statistics Found (Abbildung 16.19) die Summe aller Anomalien eines Zielsystems anzeigt.
Abbildung 16.19
Alarme
939
16.5
16
Kapazitätsplanung mit dem VMware Capacity Planner
Unter Trend Deviations können Sie alle Zielsysteme betrachten, bei denen die aktuellen Daten erheblich von den für sie ursprünglich ermittelten Trend- bzw. den tendenziell zu erwartenden Daten abweichen. Unter Forecast Alerts werden möglicherweise eintretende Alarme einzelner Leistungsindikatoren angezeigt. Die Voraussage erstreckt sich über einen Zeitraum von höchstens einem Jahr. Die Spalte Weeks Till Alert gibt an, in wie vielen Wochen mit einem Alarm bei dem entsprechenden Indikator zu rechnen ist. Unter Application Profiles werden Applikationen aufgelistet, deren Belastungsprofile bezüglich der Hardware, auf denen sie betrieben werden, zur Verfügung stehen (Abbildung 16.20). Diese Applikationsprofile zeigen z. B. die mittlere Anzahl von CPUs eines Servers an, auf dem eine der ausgewählten Applikationen läuft.
Abbildung 16.20
Verteilung der Server bezogen auf die Prozessorauslastung
Zur Verdeutlichung ein Beispiel: Nehmen wir einmal an, dass insgesamt Daten von 25 Servern, auf denen die ausgewählte Applikation betrieben wird, im Information Warehouse zur Verfügung stehen. Die Verteilung der 25 Server setzt sich wie folgt zusammen: 40 % aller Server, auf denen die ausgewählte Applikation läuft, verfügen durchschnittlich über einen Prozessor, weitere 40 % über durchschnittlich zwei Prozessoren, 16 % über durchschnittlich vier Prozessoren und 4 % über durchschnittlich acht Prozessoren. Ergänzt werden diese Daten durch die Angabe, in welcher Verteilung die 25 Server welche prozentualen Belastungen ihrer CPUs aufweisen und in welchen Betrachtungszeiträumen (Business Hours / Peak Hours) diese auftreten. Mit Hilfe dieser Daten können Sie nun Rückschlüsse auf die eigenen Systeme ziehen. Unter Vintage Servers identifizieren Sie Systeme, bei denen die Prozessorgeschwindigkeit darauf schließen lässt, dass es sich um ältere Modelle handelt. Gewöhnlich ist ein Gerät umso älter, je langsamer die CPU ist.
940
Das Dashboard im Detail
Der Schwellenwert ist im Information Warehouse grundsätzlich auf 500 MHz voreingestellt. Diese Einstellung können Sie allerdings beliebig anpassen. In Abschnitt 16.7 erläutern wir das Verfahren der Consolidation Scenarios näher. In diesem Szenario werden Templates benötigt, in denen Sie dann den Schwellenwert nach eigenem Ermessen einstellen können. Um innerhalb von Vintage Servers den veränderten Schwellenwert zu nutzen, ist es erforderlich, das entsprechende Template anzuwenden (Abbildung 16.21).
Abbildung 16.21 Auswahl der Consolidation Scenarios mit entsprechendem Schwellenwert
Mittels Compare Servers zeigen Sie Belastungsdaten von Servern an, auf denen eine bestimmte Applikation läuft. Diese Belastungsdaten sind gesammelte Industriedaten und stammen aus dem Bestand des Information Warehouse. Die vom eigenen Data Collector gemessenen Belastungsdaten der Server beziehen sich auf die Applikation, die im zu vermessenden Environment, in dem der Data Collector steht, vorhanden sind. Hier ist es nun denkbar, dass die Daten einer bestimmten Applikation ausgewählt und angezeigt werden. Die Belastungsdaten aus dem Information Warehouse lassen sich ebenfalls bezüglich einer bestimmten Applikation filtern (Abbildung 16.22). Somit können nun die gemessenen Belastungsdaten vom eigenen Data Collector, die mittels einer bestimmten Applikation gefiltert wurden, den Belastungsdaten aus dem Information Warehouse, die bezüglich der gleichen Applikation gefiltert wurden, gegenübergestellt werden (Abbildung 16.23). Damit nun auch die eigenen inventarisierten Server-Hardware-Daten und die Server-Hardware-Daten aus dem Information Warehouse möglichst in Übereinstimmung gebracht werden können, stehen die Daten von 100 Servern wahlfrei zum Vergleich zur Verfügung. Hierbei wurde bereits vom Information Warehouse in einer Vorabanalyse eine möglichst große Übereinstimmung der Leistungsdaten ermittelt.
941
16.5
16
Kapazitätsplanung mit dem VMware Capacity Planner
Abbildung 16.22 Die Auswahl eines Applikationsfilters der auf die Belastungsdaten aus dem Information Warehouse angewendet wird.
Abbildung 16.23
Gegenüberstellung der Belastungsdaten
Unter Set Up Assessment Global Settings können Sie Parameter einstellen, die eine Auswertung oder Beurteilung der Konsolidierungsvorhaben ermöglichen. Das Formular Allowed Hardware Templates gestattet es dem Administrator des Dashboards, für andere Nutzer Einschränkungen bei der Auswahl von Hardware-Templates vorzunehmen; z. B. sind prinzipiell zwei Einstellungen grundsätzlich möglich.
942
Das Dashboard im Detail
Zum einen können Sie alle Templates für die Auswertung und Beurteilung zulassen. Die andere Einstellung berechtigt Sie dazu, Templates nach Hersteller, Name eines Templates oder nach der Modellbezeichnung der Hardware für die Auswertung zu nutzen. Unter CE Scenario and Hardware Templates können Sie nun die Bedingungen, wie eine Auswertung oder Beurteilung abzulaufen hat, festlegen. In der Vorlage A Blank Scenario ist es beispielsweise nötig, alle Einstellungen über den Consolidation Scenario Template Wizard selbst vorzunehmen. In anderen Vorlagen wie CE Moderate Scenario Template oder CE Aggressive Scenario Template wurden bereits diverse Einstellungen im Vorfeld vorgenommen. Der Punkt Report Titles and Labels erlaubt es nun noch zu guter Letzt, Basisinformationen der Auswertung des Konsolidierungsvorhabens im System zu hinterlegen. Consolidation Estimator Reports stellt eine Rubrik zur Verfügung, in der mit den beiden möglichen Varianten der zu generierenden Berichte gearbeitet werden kann. Die Berichtsvarianten sind der Zwischenbericht und der finale Bericht. Sowohl Zwischen- als auch finaler Bericht können in dieser Rubrik erzeugt und heruntergeladen werden. Der Interim Report, also der Zwischenbericht, wird in der Regel während des laufenden Assessments erstellt und heruntergeladen, z. B. um sich einen ersten Überblick zu verschaffen. Dieser Virtualization Progress Report erlaubt bereits nach kurzem einen ersten tiefen Einblick in die zu untersuchende Umgebung, wogegen der Final Report oder finaler Bericht am Ende der Untersuchung erstellt wird und auch vom Erscheinungsbild her den Charakter eines Abschlussberichtes hat. Ein solcher Abschlussbericht enthält beispielsweise auch Aussagen über die Konsolidierungsratio. Unter Reports können Sie einerseits neue Templates für diverse Reports durch einen Report Wizard erstellen und andererseits Berichte selbst generieren. Das Erstellen von Berichten basiert entweder auf Standardvorlagen, die schon im System hinterlegt sind, oder auf Grundlage selbst erstellter Vorlagen. Die Berichtsgenerierung ist auch zeitgesteuert möglich. Eigens zu diesem Zweck steht ein entsprechender Automatismus zur Verfügung. Die Vorgehensweise ist wie folgt: Zuerst ordnen Sie einer Report-Vorlage, z. B. eine aus den im System hinterlegten, eine Company-ID zu. Im Anschluss daran nutzen Sie diese Report-Vorlage dann entweder so, wie sie ursprünglich erstellt wurde, oder Sie ändern sie entsprechend den eigenen Wünschen ab. Nun können Sie anhand der soeben erstellten Vorlage ein neues Report-Template erstellen und über New reports from this Template zur Reporterzeugung nutzen.
943
16.5
16
Kapazitätsplanung mit dem VMware Capacity Planner
1. Anomalies Alerts Trend Deviations Forecast Alerts 2. Application Profiles Vintage Servers Compare Servers 3. Set Up Assessment Global Settings Consolidation Estimator Reports 4. Reports Optimize Der Bereich Optimize dient hauptsächlich dem Konsolidierungsszenario. Alle unter Optimize aufgeführten Punkte wie Gruppenbildung, Scenario-, Hardware-, Report- und Notification-Templates unterstützen im Wesentlichen das Konsolidierungsszenario. Die Beziehungen zwischen Templates, Szenarien, Gruppen und Schwellenwerten stellt Abbildung 16.24 grafisch dar. Templates
Schwellenwerte für Konfigurationsszenarien
Informationen über die Hardware
Systeme
Abbildung 16.24
944
Gruppen
Konsolidierungsszenario
Konsolidierungsszenarien
Das Dashboard im Detail
Der Bereich System Groups gestattet die Erstellung von Gruppen. Hierbei wird zwischen logischen und physischen Gruppierungen unterschieden. Außerdem gibt es bereits im System hinterlegte Gruppierungsmöglichkeiten. Sie können aber auch Gruppen nach eigenen Kriterien erstellen. Eine Gruppe stellt eine Ansammlung von Servern, die nach bestimmten Merkmalen klassifiziert werden, dar. Auch ist Gruppenbildung von Servern in Hinsicht auf Konsolidierungsszenarien sehr hilfreich. Sie können Gruppen nach unterschiedlichsten Kriterien bilden, wie Domain-Zugehörigkeit, Standortabhängigkeit oder Applikationsbezug. Notification-Templates können als Vorlage zur Erstellung von Benachrichtigungen benutzt werden (Abbildung 16.25).
Abbildung 16.25
Vorlage zur Erstellung einer Benachrichtigung im Störfall
Nachdem Sie derartige Benachrichtigungen erstellt haben, können Sie sie im Menü Administration unter Notifications in die Benachrichtigungs-Queue einstellen und aktivieren.
Abbildung 16.26
Abruf der Benachrichtigung im Störfall
Die Benachrichtigungen sind dann im Dashboard unter dem entsprechenden Assessment zu finden (Abbildung 16.26). Außerdem wird eine Benachrichtigungs-E-Mail an die E-Mail-Adresse des Owners, der im Benachrichtigungsformular eingetragen wurde, gesendet.
945
16.5
16
Kapazitätsplanung mit dem VMware Capacity Planner
1. Consolidation Scenarios System Groups 2. Scenario Templates Hardware Templates Report Templates Notification Templates Administration In der Rubrik Administration sind grundsätzlich alle organisatorischen Einstellungen, die den Capacity Planner betreffen, möglich. Es können sämtliche Einstellungen den eigenen Account betreffend vorgenommen werden. Außerdem ist es möglich, Gastkonten anzulegen, wo es anderen im Projekt Mitwirkenden ebenfalls gestattet wird, je nach administrativem Grad unterschiedlichste Einstellungen, Überwachungen oder Auswertungen vorzunehmen. Von der Passwortvergabevorschrift über das Setzen von Verfallsdaten der Gastkonten bis hin zur Überwachung, wer wo und wann welche Seite besucht oder welche Auswertung vorgenommen hat, ist in diesem Bereich alles möglich. Meldungen zu erstellen, die darüber informieren, ob z. B. der Data Collector ordnungsgemäß seine Daten an das Dashboard überträgt, lassen sich ebenfalls in dieser Rubrik definieren. Hierbei bieten sich Einstellungsmöglichkeiten, ob derartige Meldungen allen (shared) oder lediglich einem Einzelnen (private) zugestellt werden. Der Abschnitt Collector eröffnet nochmals ein sehr umfangreiches Untermenü. Unter Register Database ID tragen Sie die Database-ID des Data Collectors ein. Mit Configure Collectors legen Sie Einstellungen des Data Collectors Remote über das Dashboard fest. Der Punkt Manage Systems gestattet es, sich mit dem Task-Status der Zielsysteme zu beschäftigen oder bestimmte Systeme vom Konsolidierungsszenario zu isolieren. Unter Performance Counters können Sie sämtliche Leistungsmessungen, die die aktiven Indikatoren in den letzten vier Wochen lieferten, untersuchen. Sollte ein Environment derart umfangreich sein, dass die maximale Obergrenze von 500 Zielsystemen für einen Data Collector überschritten wird, müssen Sie einen weiteren Data Collector einsetzen. Hierbei kann ein Lastausgleich der eingesetzten Data Collectors erforderlich werden. Zu diesem Zweck stehen unter Load Balance Collectors und Load Balance Collectors – Systems unterschiedlichste Verfahren zur Verfügung.
946
Ablauf eines Kapazitätsplanungsprojekts
Auch für den Fall, dass das Kollektieren der Daten bei einem Data Collector nicht erwartungsgemäß funktioniert, unterstützen die Bereiche Troubleshoot Collectors und Troubleshoot Systems Sie hier bei der Ursachenforschung. Ein weiterer Punkt in diesem Abschnitt des Dashboards lautet Job History. Damit lassen Sie eine zeitbezogene Liste aller Jobs des Data Collectors, hier im Dashboard, anzeigen. 1. My Account Change Password 2. Company Info Users Companies Roles 3. Security Policy Activity Log 4. Notifications Subscriptions 5. Collector
16.6
Ablauf eines Kapazitätsplanungsprojekts
Prinzipiell besteht zwischen einem Kapazitätsplanungsprojekt und jedem anderen Projekt keinerlei Unterschied hinsichtlich Organisation und Ablauf. Ein Kapazitätsplanungsprojekt erstreckt sich meistens über einen Zeitraum von vier Wochen. Zu Beginn wird gemeinsam mit dem Auftraggeber ein initial Workshop angesetzt. Am Ende des Kapazitätsplanungsprojektes wird ein gemeinsames Schlussmeeting mit Präsentation der Ergebnisse, Ergebnisbesprechung und weiterem Vorgehen im Folgeprojekt – Umsetzung und Migration – durchgeführt. Es werden Meilensteine während des Projektes definiert und zwischenzeitlich Vorab-Ergebnisse mit dem Auftraggeber durchgesprochen. Genau wie in thematisch anders gearteten Projekten ist eine genaue Kenntnis der Ansprechpartner, deren Rollen im Unternehmen und deren Kontaktdaten unabdingbar. Zu diesem Zweck ist es immer sehr hilfreich, sich bereits vor dem Projekt entsprechende »Contact Info Sheets« (Abbildung 16.27) zu erstellen und sie vom Auftraggeber ausfüllen zu lassen.
947
16.6
16
Kapazitätsplanung mit dem VMware Capacity Planner
Abbildung 16.27
Projektbezogene Kontaktdaten
Außerdem ist es vor Projektbeginn sehr hilfreich, sich bei dem oder den Verantwortlichen auf der Seite des Auftraggebers mittels »Pre-Screen Phone Interview« wichtige Vorabinformationen zu verschaffen, zum Beispiel: Werden lokale Administrationsrechte für jedes Zielsystem benötigt, befinden sich Proxy-Server in der Umgebung oder ist das zu betrachtende Environment über mehrere Standorte hinweg verteilt? In diesem Zusammenhang sollten Sie den Auftraggeber auch dazu anhalten, eine Liste der zu betrachtenden Server-Systeme (Abbildung 16.28) zu erstellen.
Abbildung 16.28
Formular zur Erfassung der Zielsysteme
Eine Gruppierung auf Tabellenebene nach Windows-, Linux- und Unix-Zielsystemen ist von Vorteil, sollte es erforderlich sein, Server-Listen in den Data Collector zu importieren. Ein auch nicht zu vernachlässigender Faktor ist die zeitliche Abfolge des Projektes. Der Auftragnehmer ist natürlich sehr daran interessiert, dass er im Vorfeld bereits über die Timeline und die bereitzustellenden Ressourcen informiert ist. Der Data Collector hilft der Unternehmes-IT, ihre Vorhaben optimal zu unterstützen. Vergessen Sie aber bitte nicht, dass er immer noch ein Fremdkörper in der Kundenumgebung ist. Zeitverläufe lassen sich in vielerlei Art und Weise darstellen. Es gibt sehr unterschiedliche Werkzeuge, um Projekte zeitlich abzubilden. Ob Sie nun ein Gantt-Diagramm (Abbildung 16.29) oder eine zeitliche Planung mittels Tabelle erstellen, um an dieser Stelle einmal zwei mögliche Verfahren aufzuzählen, bleibt Ihren Vorlieben überlassen. Fest steht allerdings, dass im Zuge eines professionell angegangenen Kapazitätsplanungsprojektes Derartiges unbedingt erforderlich ist.
948
Ablauf eines Kapazitätsplanungsprojekts
Abbildung 16.29
Gantt-Diagramm zur zeitlichen Ablaufplanung
16.6.1 Company-ID-Request Wird ein Data Collector in einer Server-Umgebung einer Organisation aufgestellt, besteht seine Aufgabe grundsätzlich darin, Daten über die Server bzw. Zielsysteme und deren bereitgestellte Dienste zu sammeln. Damit die gesammelten Daten auch ausgewertet werden können, ist es unabdingbar, diese an das Information Warehouse zu übertragen. Dies wird primär aber erst dadurch möglich, dass innerhalb des Information Warehouse ein Projekt eröffnet wird. Ein derartiges Projekt geht mit der Vergabe einer Company-ID einher (Abbildung 16.30). Eine Company-ID, bezogen auf eine bestimmte Organisation, beantragen Sie bei VMware.
Abbildung 16.30
Einen Antrag auf die Zuteilung einer Company-ID stellen
Solch ein Company-ID-Request ist einer der ersten Schritte in einem Kapazitätsplanungsprojekt. Sie beantragen eine Company–ID auf der Internetseite von
949
16.6
16
Kapazitätsplanung mit dem VMware Capacity Planner
VMware unter http://mylearn1.vmware.com/cp/?mL_method=CompanyI. Hier pflegen Sie nun in ein Formular die Daten der Organisation ein, für die Sie eine Company-ID beantragen. In der Regel dauert die Bearbeitung des Antrages 24 Stunden. Nach diesem Zeitraum steht innerhalb des Dashboards eine entsprechende Company-ID zur Verfügung. Eine detaillierte Anleitung zur Beantragung einer Company-ID ist bei VMware unter der Überschrift »Capacity Planner Company ID Request Guide« (http://mylearn.vmware.com/lcms/mL_faq/1147/ companyidguide.doc) erhältlich.
16.6.2 Vorbereitende Maßnahmen Da der Data Collector ja in einem fremden Environment arbeiten muss, bedarf es einiger Abstimmung mit denjenigen, die den Betrieb des zu untersuchenden Environments verantworten. Meistens sind es nur Kleinigkeiten, die eine Kapazitätsmessung behindern und dadurch für Verstimmung sorgen können. Damit es gar nicht erst so weit kommt, sind einige grundsätzliche Vorgaben, die bereits vor der Aufstellung eines Data Collectors kommuniziert werden sollten, sehr hilfreich. Hierzu gehört, dass der Data Collector einen Internetzugang benötigt. Der Data Collector wird hierbei die Verbindung über die Ports 80 und 443 zum Information Warehouse aufbauen. Dann dürfen zwischen dem Data Collector und den zu überprüfenden Systemen keine Firewalls, wie beispielsweise Desktop-Firewalls, den Informationsfluss blockieren. Des Weiteren muss sichergestellt sein, dass Remote-Registry und auch WMI auf den zu überprüfenden Windows-Servern aktiviert wurde. Der Data Collector muss als ein zusätzlicher Server in dem Environment, in dem er arbeiten soll, betrachtet werden. Natürlich benötigt er auch eine IP-Adresse, die Adresse eines DNS und eines Default-Gateways. Wie bereits dargelegt, ist es meistens auch von großem Vorteil, wenn eine Liste erstellt wurde, in der alle zu untersuchenden Server enthalten sind. Je detaillierter diese Liste ist, desto weniger Informationen müssen am Tag der Inbetriebnahme des Data Collectors zusammengetragen werden. Daten wie das primäre DNS-Suffix, NetBIOS/Computernamen und dazugehörige Domänennamen, IP-Adressen sowie die entsprechenden Subnetzmasken der zu untersuchenden Server-Systeme sind oft sehr hilfreich. Ein immer wieder äußerst heikles Thema sind die Anmeldenamen und Passwörter der Zielsysteme. Die Anmeldedaten der zu untersuchenden Server müssen dem Data Collector in jedem Fall mitgeteilt werden. Hier sollten Sie im Vorfeld unbedingt darauf achten, dass am Tage der Inbetriebnahme des Data Collectors die entsprechenden Geheimnisträger zugegen sind.
950
Ablauf eines Kapazitätsplanungsprojekts
Der Data Collector arbeitet ohne Agenten. Hieraus folgt, dass er die unterschiedlichen Dienste eines zu untersuchenden Servers bezüglich Inventarisierungs- und Performancedaten befragt. Es muss sichergestellt sein, dass Ping, Traceroute, Zugriff auf Remote-Registry, den Performance Manager usw. bei Zielsystemen mit Windows-Betriebssystem möglich sind. Bei Linux- oder Unix-Servern ist es notwendig, dass dieses Zielsystem über Ping und Traceroute erreichbar und der Zugriff über Secure Shell möglich ist. Die Umgebungen, in denen der Data Collector eingesetzt wird, verfügen oftmals über Notstromversorgungen. Es ist von großem Vorteil, dass der Data Collector hiervon profitiert. Ein störungsfreier Betrieb des Data Collectors muss in jedem Fall das Ziel sein. Immer wieder wird während des Messzeitraumes der Data Collector als Verursacher von zusätzlicher Netzlast gesehen. In dem Zeitraum, in dem der Data Collector läuft, kommt es natürlich in den im Data Collector gesetzten Messintervallen zu diversen Anfragen an die zu untersuchenden Server-Systeme. Diese Transfers sind allerdings innerhalb eines mittelstark belasteten Netzes eher vernachlässigbar und in der Regel von äußerst kurzer Dauer. Es ist natürlich niemals wirklich auszuschließen, dass unter Umständen einzelne Systeme während der Messzyklen mit unterschiedlichen Meldungen reagieren. Dies ist während einer Kollektierung allerdings völlig normal. Betriebssysteme, die zur Analyse freigegeben sind Nachfolgend sind die Betriebssysteme aufgeführt, die von der Version 2.6 des Capacity Planner Data Collectors untersucht werden können. Natürlich wächst die Liste der zu betrachtenden Betriebssysteme mit jeder neuen Version des Capacity Planner Data Collectors. 1. Microsoft-Windows-Betriebssysteme 왘
Windows NT 4.0 Server
왘
Windows NT 4.0 Professional Workstation
왘
Windows 2000 Server
왘
Windows 2000 Advanced Server
왘
Windows 2000 Datacenter
왘
Windows 2000 Server (64-Bit Itanium)
왘
Windows 2000 Professional Workstation
왘
Windows XP Professional
951
16.6
16
Kapazitätsplanung mit dem VMware Capacity Planner
왘
Windows XP Professional (64-Bit x86/EM64T/AMD64)
왘
Windows 2003 Server
왘
Windows 2003 Server (64-Bit Itanium)
왘
Windows 2003 Server (64-Bit x86/EM64T/AMD64)
2. Unix-Betriebssysteme 왘
Sun Solaris 7 (SPARC)
왘
Sun Solaris 8 (SPARC)
왘
Sun Solaris 9 (SPARC)
왘
Sun Solaris 9 (x86)
왘
Sun Solaris 10 (SPARC)
왘
Sun Solaris 10 (x86)
왘
HP-UX 10.xx (PA-RISC)
왘
HP-UX 11 (PA-RISC)
왘
HP-UX 11.11 (PA-RISC)
왘
HP-UX 11.22 (PA-RISC)
왘
HP-UX 11.23 (Itanium)
왘
AIX 5.1
왘
AIX 5.2
왘
AIX 5.3
3. Linux-Betriebssysteme 왘
SUSE Linux Enterprise Server 9
왘
SUSE Linux 10
왘
SUSE Linux 9
왘
SUSE Linux 8
왘
Red Hat Linux 9
왘
Red Hat Linux 8
왘
Red Hat Enterprise Linux (ES/AS/WS) 4
왘
Red Hat Enterprise Linux (ES/AS/WS) 3
16.6.3 Überwachung der Messung Die Überwachung des Data Collectors bzw. der Messung ist über unterschiedliche Wege möglich. Prinzipiell stehen zwei Methoden zur Verfügung. Zum einen können Sie den Data Collector indirekt überwachen. Das heißt, Sie kontrollieren
952
Ablauf eines Kapazitätsplanungsprojekts
die Ergebnisse, die der Data Collector produziert und an das Information Warehouse überträgt. Uploaded
Processed
Rejected
Data file counts
500 400 300 200 100 0 4/28/08
4/30/08
Abbildung 16.31
05/02/08
05/04/08 05/06/08 Date
05/08/08
05/10/08
05/12/08
File-Übertragungsstatistik
Hier bietet sich der Bereich Collection Dashboard geradezu an. Die Rubriken Collector Data File Statistics (Abbildung 16.31), Data Files Received (Abbildung 16.32), Performance Data File Events usw. geben Aufschluss über die Aktivitäten des Data Collectors. 700
Data file size (K)
600 500 400 300 200 100 0 05/12/08
05/12/08
05/12/08
05/12/08
05/12/08
05/12/08
05/12/08
01:57:35
03:37:02
04:57:40
06:38:58
08:17:48
09:57:18
12:17:51
Date
Abbildung 16.32
Empfangsstatistik der Leistungs- und Inventarisierungsdaten
Die andere Variante ist, sich direkt mit dem Data Collector zu verbinden. Dies geschieht in der Regel über Remote-Zugriffe, z. B. über eine VPN-Verbindung. Über eine derartige Verbindung ist es dann auch möglich, administrative Veränderungen am Data Collector vorzunehmen. Stehen derartige Zugänge nicht zur Verfügung, können Sie den Data Collector auch über das Dashboard des Information Warehouse fernsteuern. Dies geschieht im Bereich Administration unter Configure Collectors.
16.6.4 Außerbetriebnahme des Data Collectors Nachdem der Data Collector seinen Dienst über das Untersuchungszeitfenster absolviert hat und somit die Kollektierungsperiode abgeschlossen ist, können Sie ihn nun außer Dienst stellen. Dies geschieht in der Regel durch das Herunterfahren und Ausschalten des Data Collectors.
953
16.6
16
Kapazitätsplanung mit dem VMware Capacity Planner
16.7
Auswertung
Ein BCE (Basic Consolidation Estimate) stellt eine Überprüfung des Environments im Hinblick auf die geplante Konsolidierung dar – quasi ein Basisgutachten zur Virtualisierungsfähigkeit der untersuchten Server-Umgebung.
16.7.1 Phantom-Server Das Dashboard des Data Warehouse stellt eine umfangreiche Sammlung an Hardware-Templates, die auch als Modellsysteme bezeichnet werden, zur Verfügung und erlaubt die Erstellung eigener Hardware-Templates.
Abbildung 16.33
Hardware-Template eines generischen Phantom-Servers
Diese Hardware-Templates bzw. -Vorlagen werden auch Phantom-Server genannt. Ein Phantom-Server wird durch die Angabe von unterschiedlichen Leistungsdaten (Abbildung 16.33) beschrieben. Das heißt, anhand von Definitionen, wie die Menge an Hauptspeicher oder die Anzahl der CPU-Kerne usw., kann ein virtueller Host im Dashboard hinterlegt werden. Wie am Anfang des Abschnitts beschrieben, stehen derartige Phantom-Server bereits in großer Anzahl im Dashboard zur Verfügung. Außerdem ist es möglich, aus diesen bereits hinterlegten Modellsystemen neue Modellsysteme zu generieren. Natürlich können Sie diese dann nach Belieben abändern. Auch ist es vorstellbar, von Grund auf selbstdefinierte Modellsysteme zu erstellen. All diese auf der Basis von Templates oder von Grund auf neu erstellten Modellsysteme sind selbstverständlich innerhalb des Dashboards abspeicherbar, so dass sie bei zukünftigen Auswertungen ebenfalls zur Verfügung stehen. Sowohl Host-Modelle als auch Modelle der Zielsysteme sind innerhalb des Dashboards zugänglich.
954
Auswertung
16.7.2 Konsolidierungsszenario Das Konsolidierungsszenario basiert im Grunde auf einem einfachen Modell. Die gemessenen Daten, die aus einer realen physischen Server-Umgebung stammen, werden als Grundlage für die Virtualisierung der physischen Systeme genutzt. Die Systeme, deren Datenbasis anzeigt, dass keine Virtualisierung möglich ist, werden gekennzeichnet und im Zuge einer Migrationsuntersuchung nicht weiter berücksichtigt. Daten derartiger Systeme können Sie mit den Möglichkeiten, die das Dashboard des Information Warehouse zur Verfügung stellt, näher untersuchen. Stellt sich dann heraus, dass die kritischen Werte dieser Systeme eventuell durch diverse Maßnahmen oder Optimierungen an den physischen Systemen zu verbessern sind, kann eine erneute Untersuchung hier letztendlich doch noch zu einer Virtualisierungsempfehlung und einer damit verbundenen Anhebung der Virtualisierungsratio führen. Nachdem aber nun alle physischen Maschinen, die sich auf der Basis ihrer Daten für ein Konsolidierungsszenario eignen, in Form von Modellen bereitstehen, kann der Prozess des Konsolidierungsszenarios nun beginnen. Durch Auswahl von New Consolidation Scenario starten Sie einen Assistenten bzw. Wizard, der Sie durch die einzelnen Schritte eines Konsolidierungsszenarios führt. Im ersten Schritt wählen Sie ein Scenario Template aus. In einem nächsten Prozessschritt ist es möglich, die gemessenen Server zu gruppieren.
Abbildung 16.34
Formular zur Einstellung diverser Regeln
Ein weiterer Schritt im Prozess erlaubt es, mannigfaltig Regeln (Abbildung 16.34) im Szenario zu hinterlegen. Mit diesen Regeln ist es z. B. auch möglich, bereits bestehende Hardware in die bevorstehende Betrachtung einzubeziehen. Außerdem können Sie die Granularität im Hinblick auf die Darstellung der Ergebnisse
955
16.7
16
Kapazitätsplanung mit dem VMware Capacity Planner
einstellen. Im Anschluss daran wählen Sie eine Hardwarevorlage (Abbildung 16.33) aus. Hierbei bietet der Wizard bereits ein Quick Assessment (Abbildung 16.35) an. Das Quick Assessment lässt bereits zum jetzigen Zeitpunkt eine erste Voranalyse für die Komponenten Prozessor, Memory, Disk-Speed und NetworkSpeed zu. Durch die Auswahlbox Variance (Abbildung 16.35) nehmen Sie eine Einstellung vor.
Abbildung 16.35
Quick Assessment
Im folgenden Beispiel erläutern wir anhand des Hauptspeichers das »Quick Assessment« einmal exemplarisch. Hierbei gehen wir von einem auf 16 GB eingestellten Hauptspeicher aus. Die Tabelle, mit der Sie ein »Quick Assessment« vornehmen, besteht aus sieben Zeilen. Die mittlere Zeile stellt den aktuell eingestellten maximalen Hauptspeicher des Modell-Hosts dar. Nun ist eine Betrachtung in drei Stufen (Abbildung 16.36) möglich. Über die Combo Box Stepping können Sie Stufen von einem Viertel GB, einem halben GB und einem GB einstellen. In diesem Beispiel wurde eine Abstufung von einem GB gewählt (Abbildung 16.36). Wie deutlich zu erkennen ist, werden bei der aktuellen Hauptspeicherwahl vier Hosts benötigt. Erst ab 19 GB Hauptspeicherbestückung wird es möglich, lediglich drei Hosts einzusetzen (Abbildung 16.36), um alle ausgewählten Zielsysteme in einer virtuellen Server-Landschaft zu betreiben. Diese Aussage beruht allerdings ausschließlich auf der Betrachtung der Hauptspeicherausstattung. Um eine nachhaltige Aussage zu treffen, wie viele Hosts tatsächlich benötigt werden, müssen Sie selbstverständlich alle anderen maßgeblichen Faktoren ebenfalls berücksichtigen.
Abbildung 16.36
956
Quick Assessment: Memory liegt bei 16 GB.
Auswertung
Durch Anklicken des Eintrags 19456 (19 GB) in der Spalte Memory (MB) wird nun die Tabelle neu geschrieben und dieser Wert in die mittlere Zeile eingetragen. Des Weiteren wird der Hauptspeicher des Modellsystems von 16 GB auf 19 GB erhöht. Es ist nun zu erkennen, dass sich bis zur letzten Zeile der Tabelle (Abbildung 16.37) keine Veränderung bei der Anzahl der Server ergibt.
Abbildung 16.37
Quick Assessment: Memory liegt bei 19 GB.
Falls im Blick auf das geplante Virtualisierungsvorhaben diese Menge an Hosts nicht erwünscht ist, können Sie nun im Weiteren untersuchen, ob bezogen auf den Hauptspeicherausbau eine weitere Reduzierung der benötigten Hosts im Rahmen des »Quick Assessments« möglich ist. Zu diesem Zweck führen Sie das soeben beschriebene Vorgehen in gleicher Art und Weise fort. Im letzten Schritt werden noch Schwellenwerte für die Betrachtung festgelegt. Hierbei hinterlegen Sie unter anderem Obergrenzen für die Auslastung des Hauptspeichers oder den maximalen Nutzungsgrad des Netzwerkes (Abbildung 16.38). Im Anschluss daran werden die gemessenen Daten der Zielsysteme, Modelldaten der Zielsysteme, die aus der realen physischen Server-Umgebung stammen, mit den Modelldaten der Hosts, Phantom-Server, in Korrelation gebracht.
Abbildung 16.38
Formular zur Einstellung der Schwellenwerte
Als vorbereitende Maßnahme für eine erste Näherung ist es auch in dieser Rubrik möglich, ein »Quick Assessment« durchzuführen. Dieses »Quick Assessment« ist dem bereits bei »Hardwarevorlagen« beschriebenen Verfahren sehr ähnlich. Das Resultat ist eine bestimmte Menge von Phantom-Servern, die später die virtuellen Maschinen in einer gemittelten Kombination hosten können.
957
16.7
16
Kapazitätsplanung mit dem VMware Capacity Planner
16.7.3 Ergebnis Als Ergebnis der Korrelation von zugrundegelegtem Phantom-Server (Abbildung 16.39) und der Messdaten der Zielsysteme wird nun einerseits die Menge der benötigten Phantom-Server und andererseits eine Zusammensetzung der Hosts im Hinblick auf die zukünftig virtualisierten Zielsysteme (Abbildung 16.40) angezeigt.
Abbildung 16.39
Modell eines Phantom-Servers
Im vorliegenden Beispiel werden auf Phantom-Server 1 acht Zielsysteme und auf Phantom-Server 2 sechs Zielsysteme platziert. Wie anhand der einzelnen Werte (Abbildung 16.40) deutlich zu sehen ist, stellt sich die Belastungsbilanz recht optimiert und ausgeglichen dar.
Abbildung 16.40
Phantom-Server und Zielsysteme
Zielsysteme, die aus unterschiedlichsten Gründen für eine Virtualisierung nicht geeignet sind, werden ebenfalls dargestellt. Hierbei werden auch die Gründe für die Nichtvirtualisierungsempfehlung hervorgehoben. Im vorliegenden Beispiel wird eine Ausgrenzung des Zielsystems MO mit zu hohem Paging (Abbildung 16.40) begründet.
16.7.4 Was bedeutet Verfügbarkeit? Im Umfeld von High Availability stellt sich immer die Frage, wie hoch die Verfügbarkeit denn tatsächlich sein soll. Auch sollte genau hinterfragt werden, was mit Verfügbarkeit eigentlich genau gemeint ist – Verfügbarkeit des Storage, der
958
Auswertung
Hosts, der virtuellen Maschinen, der Dienste oder des Gesamtsystems? Sie müssen sich in diesem Zusammenhang immer vor Augen führen, dass, wenn z. B. die Forderung von five-nines-Verfügbarkeit (Abbildung 16.41) für das Gesamtsystem gestellt wird, praktisch gesehen das Speichersystem, auf dem die virtuellen Maschinen liegen, quasi innerhalb eines Jahres überhaupt nicht ausfallen darf, da five nines lediglich gut fünf Minuten Betriebsunterbrechung im Jahr für das Gesamtsystem zulässt.
Abbildung 16.41
Zeitfenster bei five nines
16.7.5 Berücksichtigung von Verfügbarkeit In den folgenden Überlegungen wird der Hochverfügbarkeits-Service der virtuellen Infrastruktur zugrunde gelegt. Die Gewährleistung des High-Availability-Service hängt in dieser Betrachtung im Wesentlichen von der Verteilung der Ressourcen ab. Primär kann also gesagt werden, dass der Verbund im Idealfall bei einfacher High-Availability-Redundanz so viele Ressourcen benötigt, dass der Ausfall eines Knotens im Gesamtverbund abgefangen werden kann. Bei einem Zweiknotensystem kann also, wenn ein Knoten ausfällt, der zweite Knoten die ausgefallenen Ressourcen zur Verfügung stellen. In Bezug auf die Ressource CPU bedeutet das, dass genauso viel CPU-Ressourcen vom verbleibenden Knoten bereitstehen, wie auf dem ausgefallenen Knoten von den virtuellen Maschinen genutzt wurden. Besteht der Verbund aus drei Knoten und fällt ein Knoten aus, müssen die verbleibenden beiden Knoten die verlorene Ressource abfangen. In unserem Beispiel würde das bedeuten, dass die Ressource CPU gleichermaßen von zwei Hosts bereitgestellt werden muss. Hierbei stellt sich nun die Frage, inwieweit der verbleibende Verbund noch Redundanz im Hinblick auf den Ausfall eines weiteren Knotens bereitstellen soll. Aber dazu später mehr. Bei einem High-Availability-Verbund mit noch mehr Hosts gilt die gleiche Anforderung. Nur werden derartige Überlegungen beliebig kompliziert. Bleiben wir aber der Einfachheit halber bei unserem Zweiknotenbeispiel. Nehmen wir einmal an, dass in unserer Simulation der Modell- bzw. Phantom-Server eine Ausstattung von 8 GB RAM sowie zwei Single-Core-CPUs mit je 2 800 MHz besitzt. Nach der Simulation stellt sich uns das folgende Ergebnis dar:
959
16.7
16
Kapazitätsplanung mit dem VMware Capacity Planner
왘
CPU (Phantom 1): 5 %
왘
CPU (Phantom 2): 8 %
왘
CPU total: 13 %
Das Ergebnis des Modellszenarios lautet: Es werden mindestens zwei Hosts benötigt, um die Dienste, die es zu virtualisieren gilt, zu betreiben. Für die Ausnutzung der CPU bedeutet das, dass der Nutzungsgrad im Verbund bei gerade einmal 13 % liegt. Im Hinblick auf den Hauptspeicher des Verbundes stellt sich ein nicht zufriedenstellendes Ergebnis ein. Wie an den Zahlen zu sehen ist, liegt der Ausnutzungsgrad 44 % über den vorhandenen Ressourcen des gewählten Phantom-Servers. 왘
RAM (Phantom 1): 69 %
왘
RAM (Phantom 2): 75 %
왘
RAM total: 144 %
In einem nächsten Auswertungslauf wählen wir einen Phantom-Server, der mit 16 GB Hauptspeicher und mit zwei Single-Core-CPUs mit je 2.800 MHz ausgestattet wird. Wie wir aus dem vorhergehenden Szenario herausgearbeitet haben, sind zwar die beiden CPUs in keiner Weise erforderlich, aber in unserem Beispiel bleiben wir der Einfachheit halber bei dem ursprünglich gewählten Hardwaremodell. Die Ergebnisse für den Nutzungsgrad der CPU bleiben also identisch, so dass wir hierauf nicht weiter eingehen. 왘
RAM (Phantom 1): 46 %
왘
RAM (Phantom 2) :26 %
왘
RAM total: 72 %
Das Ergebnis spricht für sich. Der Hauptspeicher des Zweiknotenverbundes wird maximal zu 72 % ausgelastet. Fällt z. B. Phantom 1 aus, wird Phantom 2 mit Verbrauchern oder, besser gesagt, virtuellen Maschinen belastet, die zusätzlich dem Host 26 % Hauptspeicher abverlangen. An dieser Stelle sei darauf hingewiesen, dass der aus mehr als zwei Knoten bestehende Verbund – neben der höheren Verfügbarkeit – einen weiteren großen Vorteil bietet; am Beispiel des Dreiknotenverbundes wird dies sehr deutlich: Durch den Ansatz, drei Knoten einzusetzen, wird es mittels dieser erhöhten Redundanz möglich, einen der Knoten ohne den Verlust von einfacher Redundanz zu warten respektive auf- oder umzurüsten. Sollte nämlich der Fall eintreten, dass einer der beiden verbleibenden Knoten während der Wartung des dritten Knotens ausfällt, arbeitet die Anlage gemäß High Availability weiter und die Dienste für den Endbenutzer stehen nach der Übernahme durch den verbleibenden Knoten dem Endbenutzer schnellstens
960
Auswertung
wieder zur Verfügung. Das Betriebspersonal muss also nicht sofort eingreifen. Die Voraussetzung für ein derartiges Sicherheitsniveau ist allerdings, dass in dem soeben beschriebenen Dreiknotenverbund jeder der Knoten sämtliche virtuellen Maschinen vollständig übernehmen und hinreichend mit Ressourcen versorgen kann.
16.7.6 Betrachtung der Skalierbarkeit Ein weiterer Aspekt ist, dass die Auslastung der Hosts nicht bei oder zu nah an 100 % geplant werden sollte. In der Praxis kommt in der Regel nach der Inbetriebnahme einer virtuellen Infrastruktur entgegen allen Vorsätzen der IT einer Organisation schnell die eine oder andere virtuelle Maschine hinzu. Aus diesem Grund ist eine großzügigere Planung äußerst empfehlenswert. Faktoren wie zukünftiges Wachstum sind unbedingt einzuplanen. Was auch immer wieder bei der Planung im Verbund der Hosts unterschätzt wird, ist die Berücksichtigung einer virtuellen Testumgebung. Gerade im Hinblick auf Experimente mit geclonten Produktivsystemen sollten Sie hinreichend Ressourcen einplanen. Wie im Beispiel des Modellszenarios (Abbildung 16.40) veranschaulicht wurde, gibt es sehr oft Systeme, die sich aus den bereits genannten Gründen nicht virtualisieren lassen. Meistens werden diese Systeme, nachdem die Gründe für eine Nichtvirtualisierung bekannt geworden sind, nach Problembehebung zu einem späteren Zeitpunkt virtualisiert. Die Ressourcenanforderungen dieser Zielsysteme müssen unbedingt bei der Auslegung der Hosts berücksichtigt werden. Sollte eine Organisation sich dann auch noch für das Thema Virtual Desktop Infrastructure begeistern, sind die Anforderungen an die Ressourcen noch schwieriger festzumachen, da im Hinblick auf Virtual Desktop Infrastructure z. B. der Personalbestand eines Unternehmens einen noch unmittelbareren Einfluss auf die Ressourcen der IT hat als im Umfeld von bereitzustellenden Diensten. Da diese Technik virtuelle Rich Clients bereitstellt, sind die Anforderungen oftmals entsprechend hoch. In Anbetracht dieser Situation sind die Entscheidungen für die richtige Hardware nicht einfach und hängen von unterschiedlichsten Faktoren ab. Werden einige große Server gewählt – verfügen also die Hosts über viel CPU, eine große Menge an Hauptspeicher und sind mit umfangreichen Festplattensubsystemen ausgestattet –, so ist dies anders zu bewerten, als wenn im Environment eine große Anzahl von geringer ausgestatteten Hosts eingesetzt wird. Auch im Hinblick auf die Lizenzierung einer Umgebung ist es wichtig zu entscheiden, ob die Zahl der Knoten in einem Server-Verbund begrenzt werden darf oder nicht. Durch moderne Server gibt es allerdings noch eine weitere Variante, die beleuchtet werden muss.
961
16.7
16
Kapazitätsplanung mit dem VMware Capacity Planner
Durch den Fortschritt bei der CPU-Architektur steigen die Zahlen der Kerne in einer CPU stetig. Waren es früher Zweikernsysteme, so sind es heute Vierkernsysteme, und mit einem Ende dieses Trends ist eher nicht zu rechnen. Nehmen wir einmal an, dass ein Server die Möglichkeit bietet, mit acht Sockeln ausgestattet zu werden. Werden diese Sockel dann mit Vierkern-CPUs bestückt, verfügt das Gesamtsystem über 32 Kerne. Derartige Hosts stellen auch noch beispielsweise 256 GB Hauptspeicher zur Verfügung. Hosts dieser Klasse können ohne weiteres mit um die 100 anspruchsvollen virtuellen Maschinen belastet werden. Bei zwei voll ausgebauten Hosts dieser Leistungsklasse ist es unter Umständen möglich, eine Knotenobergrenze festzulegen. Bei kleineren Systemen ist die Entscheidung für eine Festlegung auf eine Obergrenze wesentlich schwieriger zu treffen. An dieser Stelle nun ein Beispiel bezogen auf die Menge von CPUs respektive Kerne in den CPUs: Werden zwei Hosts mit je vier Sockeln zugrunde gelegt, von denen nur je zwei Sockel mit Vierkern-CPUs bestückt wurden, verfügt das Environment bereits über insgesamt 16 Kerne. Da das System in unserem Beispiel bisher aber nur halb ausgebaut wurde, ist noch Raum für Wachstum. An dieser Stelle muss jetzt die Entscheidung getroffen werden, ob bei Wachstum über die noch im Verbund verfügbaren acht Sockel hinaus ein weiterer Knoten eingesetzt oder ob schon zum jetzigen Zeitpunkt mit stärker ausbaubaren Hosts begonnen werden soll. Abgesehen von der Anzahl der CPU-Kerne kann auch die Aufnahme der elektrischen Leistung bei kleineren Systemen deutlich höher liegen. So würden bei dem hier erläuterten Beispiel zwei Achtwegemaschinen ca. ein Kilowatt weniger Leistungsaufnahme bedeuten als vier Vierwegemaschinen, und bei acht Zweiwegemaschinen läge der Verbrauch noch höher. Dabei lassen wir noch ganz außer Acht, wie sich dies auf den Bedarf an Höheneinheiten und Kühlleistung auswirkt. Außerdem benötigen mehr Server-Systeme auch mehr Anschlüsse an das Storage-Netz, was ein weiterer nicht zu vernachlässigender Faktor ist. Hierbei wird sehr deutlich nachvollziehbar, dass die Betrachtungen der unterschiedlichen Umgebungen in Hinsicht auf die Fragestellung der Skalierbarkeit sehr differieren. Jede Umgebung muss individuell für sich betrachtet werden.
16.7.7 Ermittlung der Konsolidierungsratio bzw. der Grad der Konsolidierung bei der Virtualisierung Der Grad der Konsolidierung zeigt die Qualität der Migration an. Das heißt, es wird ein Wert ermittelt, der aufzeigt, wie hoch die Migrationsquote sein wird. Hierzu wird die Menge aller physischen Server-Systeme, die zur Migration anste-
962
Auswertung
hen, mit der Zahl der physisch verbleibenden Server-Systeme – sprich der ServerSysteme, die aus den unterschiedlichsten Gründen nicht virtualisiert werden können – ins Verhältnis gesetzt. Es handelt sich quasi um eine Vorher-NachherBetrachtung bezogen auf die Gesamtzahl der Server-Systeme. Nehmen wir einmal an, dass es 53 Zielsysteme zu virtualisieren gilt. Des Weiteren hat sich herausgestellt, dass 3 Zielsysteme nicht virtualisierbar sind. Der Grund hierfür könnte sein, dass die Systeme einen derart hohen Verbrauch an Ressourcen haben, dass eine Virtualisierung nicht sinnvoll wäre. Das Fazit ist: Es sollen 50 physische Server-Systeme virtualisiert werden. Auch haben wir herausgefunden, dass sieben ESX-Server benötigt werden, um die 50 virtuellen Maschinen zu hosten. Die Ermittlung der Konsolidierungsratio bezogen auf unser Beispiel geschieht dann wie folgt: Definition: 왘
die Menge aller physischen Server im Environment: Srvs In
왘
die Menge der ermittelten ESX-Hosts: ESX Srvs Out
왘
die Server, die sich nicht virtualisieren lassen: Exception Servers
왘
Con Ratio bzw. Konsolidierungsverhältnis: CR
왘
Con Ratio bzw. Konsolidierungsverhältnis in %: CR (%)
Berechnung: Srvs In CR = ----------------------------------------------------------------------------------ESX Srvs Out + Exception Servers 1CR (%) = 100 ⋅ 1 – ------CR Beispiel:
Srvs In = 53 Stück ESX Srvs Out = 7 Stück Exception Servers = 3 Stück
963
16.7
16
Kapazitätsplanung mit dem VMware Capacity Planner
Ergebnis:
Die Konsolidierungsratio, also das Konsolidierungsverhältnis, beträgt 81 %.
16.7.8 Der Weg zum CP-Admin Einen Zugriff auf das Dashboard sowie die Möglichkeit, den Data Collector einzusetzen, erhält ein Consultant, indem er bei VMware den Lehrgang »Instructor Lead Capacity Planner« absolviert. Dieser Lehrgang kann ausschließlich von einem Mitarbeiter eines Unternehmens durchgeführt werden, das eine entsprechende VMware-Partnerschaft hält. Hat nun ein Consultant die Zulassung erlangt, verfügt er auch über einen Zugang zum Dashboard und kann hier für weitere Consultants entsprechende Accounts anlegen. Damit diese Consultants ihre Arbeit mit dem Capacity Planner aufnehmen können, schreibt VMware vor, dass sie eine Onlineschulung bei VMware absolvieren. Unter http://mylearn1.vmware.com kann der Kurs »Installing the Data Manager« absolviert werden.
964
In diesem Kapitel erfahren Sie, welche zusätzlichen Softwareprodukte VMware anbietet, um Ihnen als Administrator die Arbeit mit der virtuellen Infrastruktur zu erleichtern. Dabei geht es nicht nur um Server-, sondern auch um Desktop-Virtualisierung.
17
Zusatzsoftware von VMware Autor dieses Kapitels ist Betram Wöhrmann, Ligarion, [email protected]
Durch das Studium dieses Kapitels erhalten Sie einen Überblick über die Softwarefamilie von VMware. Wir zeigen Ihnen, welchen Mehrwert die Produkte für Sie haben können. Eine Beschreibung der Installation und Konfiguration der einzelnen Softwarepakete ist nicht Bestandteil dieses Kapitels.
17.1
Automatisierung
In diesem Abschnitt finden Sie alle Add-ons der vCenter-Produktfamilie, die Sie bei der Automatisierung der Server-Landschaft unterstützen.
17.1.1
VMware vCenter Lab Manager
Mit dem VMware vCenter Lab Manager stellen Sie einem End-User Test- und Entwicklungssysteme in einer virtuellen Umgebung zur Verfügung. Durch diesen Self-Service-Ansatz entlastet der vCenter Lab Manager die Administratoren der virtuellen Infrastruktur. So richten Sie den Applikationsentwicklern eine virtuelle Entwicklungsumgebung für ihre Arbeiten ein. Zu diesem Zweck stellt der Administrator den Nutzern im Vorfeld eine Auswahl von virtuellen Maschinen als Templates zur Verfügung. Aus diesem Portfolio können sich die Nutzer dann ihre Testumgebung erstellen und anschließend ihre Applikation darauf installieren und weiterentwickeln. Die Entwickler haben es dabei selbst in der Hand, die Personen auf dem System zu berechtigen, die ihre Arbeit unterstützen sollen. Der Zugriff auf den vCenter Lab Manager erfolgt dabei komplett über den Browser, so dass kein Endanwender einen weiteren Client installieren muss.
965
17
Zusatzsoftware von VMware
Virtual Machines
Resource Pool
Image Storage Library
VMWARE vCENTER LAB MANAGER
Lab Admin
VMWARE vCENTER
Local Team Remote Team Abbildung 17.1
Funktionsübersicht des Lab Managers
Die VM-Templates sind selbstverständlich jederzeit erweiterbar, so dass Sie den Anwendern auch neue oder aktuellere Systeme zur Verfügung stellen können. Der Vorteil liegt auf der Hand: Die Systeme kommen fertig »out of the box«, und es ist keine weitere Konfigurationsarbeit seitens des Administrators mehr notwendig. Der Anwender selbst ist für seine Umgebung komplett eigenverantwortlich. Er baut aus den bestehenden Templates sein System oder seine Systemkette selbst auf. Der Anforderer der VM wählt im Portal eine geeignete VM (1). Anschließend sucht der vCenter Lab Manager, in Zusammenarbeit mit dem vCenter, den geeigneten Host aus (2) und stellt den virtuellen Server zur Verfügung. Nach der Fertigstellung kann sich der Anwender direkt per Browser auf die Konsole des Systems verbinden (3).
966
Automatisierung
2 VMware vCenter Lab Manager determines the best host servers, then deploys the machines
1 users select a multi-machine configuration, click deply
VMware vCenter Lab Manager
Image Storage Library
2 Once deployed, users directly interact with the machines, as if sitting at each console
VMware Infrastructure Virtualized Server Pool
Automated Virtual Lab Abbildung 17.2
Funktionsweise des Lab Managers
Sie können aber nicht nur neue Umgebungen aufbauen, sondern auch Duplikate von produktiven Systemen. Eine mögliche Anwendung wäre, die Verteilung von Patches zu testen, bevor Sie sie in der eigentlichen produktiven Landschaft ausrollen. In diesen Duplikaten können Sie selbstverständlich auch eine Fehlerbehebung verproben, wenn es Schwierigkeiten mit einem Server oder einer Applikationskette gibt. Alternativ nutzen Sie die Duplikate, um den Upgradepfad der Applikation zu erarbeiten. Verwenden Sie die Umgebung, um detaillierte Skalierungstests durchzuführen oder um die Lastverteilung über mehrere Applikations-Server zu testen. Durch den gezielten Einsatz von Resource-Pools lassen sich vCenter-Lab-Manager-Umgebungen vom produktiven Rechenzentrum abschotten. Sie machen sich so nicht gegenseitig die Ressourcen streitig. Selbstverständlich ist der vCenter Lab Manager skalierbar, so dass Sie im Bedarfsfall die unterliegende Umgebung erweitern können. Der vCenter Lab Manager wird auf einer bestehenden vSphere-Landschaft mit einem installierten vCenter-Server aufgesetzt. Das vCenter muss in der aktuellen Version 4.x zur Verfügung stehen, als Host können Sie sowohl Systeme der Ver-
967
17.1
17
Zusatzsoftware von VMware
sion 3.5 als auch Hosts der Version 4.x nutzen. Sowohl ESX- als auch ESXi-Plattformen werden unterstützt. Nach der Installation bauen Sie nun einmalig eine Bibliothek von virtuellen Maschinen auf. Diese Maschinen erhalten ein Betriebssystem mit allen Tools, die installiert werden müssen, um einen reibungslosen und sicherer Betrieb zu ermöglichen. Über den fertig konfigurierten vCenter Lab Manager wird ein Webportal zur Verfügung gestellt, über das sich der potentielle Nutzer anmelden kann (Abbildung 17.3).
Abbildung 17.3
Übersicht der Lab-Manager-Umgebung
Hier sieht er alle zur Verfügung stehenden Basis-Images und kann sich daraus »bedienen«, um sich einen Server oder eine Landschaft von Servern aufzubauen. Mit diesem Werkzeug kann er auch seinen Entwickler- oder Testkollegen Zugriffsrechte erteilen. Der vCenter Lab Manager bringt im Bereich Netzwerk besondere Fähigkeiten mit: Mit der Funktion Network Fencing erstellen Sie ein komplett isoliertes Netzwerk und hosten dort die Kopie einer produktiven Server-Landschaft. Selbstver-
968
Automatisierung
ständlich können Sie die virtuellen Server auch über mehrere Hosts verteilen. Somit vermeiden Sie z. B. einen IP-Adressen-Konflikt.
Abbildung 17.4
vCenter-Lab-Manager-Konfigurationen
Eine weitere Funktion ist das Anlegen von Archiven. Eine einmal erstellte Testumgebung lässt sich archivieren und jederzeit wieder rearchivieren, um mit ihr weiterzuarbeiten. Das kann auch mehrfach und parallel geschehen, so dass sich der vCenter Lab Manager sehr gut für das Bereitstellen von Trainingsräumen eignet. Zur weiteren Unterteilung richten Sie einfach mehrere Organisationen ein und konfigurieren so die gesamte Landschaft sehr granular. So machen Sie für die Anwender nur das sichtbar, was sie sehen sollen. Dabei hilft auch das ausgefeilte Berechtigungssystem, das über 50 verschiedene Berechtigungen kennt. Dieses Werkzeug entlastet die Administratoren und überlässt dem eigentlichen Nutzer einen großen Teil der administrativen Aufgaben. Gerade in Entwicklungsund Testumgebungen ist das auch sehr sinnvoll. Der Nutzer hat in Eigenverantwortung zu entscheiden, wer wie wo berechtigt wird. Vorteile bietet auch hier die Funktion, mit Linked Clones zu arbeiten. Bei Linked Clones referenzieren sich die virtuellen Maschinen auf ein Masterabbild. Dies bietet eine Platzersparnis auf dem Storage und eine extrem schnelle Bereitstellung von neuen Maschinen.
969
17.1
17
Zusatzsoftware von VMware
In der neu erschienenen Version 4.0.1 des VMware Lab Managers sind die Funktionen des Lab Managers und des ehemaligen vCenter Stage Managers zusammengewachsen. Ein Video, das eine Übersicht über die Funktionen gibt, finden Sie unter: http:// www.youtube.com/user/VMwareDE.
17.1.2
VMware vCenter Orchestrator
Für die Erstellung von Workflows für Ihre täglichen Arbeiten können Sie den vCenter Orchestrator einsetzen. Es handelt sich hier um eine Erweiterung des vCenter-Servers und ist auch Bestandteil von ihm. Das System bringt eine Reihe von vorgefertigten Workflows mit, die Standardarbeiten abbilden und dem Nutzer zeigen sollen, wie man sich in der ganzen Thematik zurechtfindet. Die Aufgaben lassen sich in einem Designer anschauen und erstellen, damit Sie sich anhand der Beispiele mit der Funktionsweise der Anwendung vertraut machen können.
Abbildung 17.5
Struktureller Aufbau des Orchestrators
Sie kombinieren verschiedene Aktionen, die sich auch in der Oberfläche durchführen lassen, miteinander und bauen sich somit einen Funktionsbaukasten. Dieser soll die Arbeit des Administrators unterstützen. Diese Workflows lassen auch Aktionen auf mehreren Objekten gleichzeitig zu. Was sich so einfach anhört, ist ein recht komplexer Vorgang, der nicht so einfach zu beherrschen ist. Macht man sich die Mühe, nach Beispiel-Files zu suchen, findet man nur sehr wenige Administratoren, die sich intensiver mit der Materie auseinandergesetzt haben. Vielen
970
Automatisierung
VMware-Administratoren reicht es für Ihre Arbeit aus, ihre Routineaufgaben über die verschiedenen vCenter-Schnittstellen durchzuführen. Als Beispiel sei die PowerShell genannt; sie ist zwar vom Umfang sehr komplex, aber recht leicht zu erlernen.
Abbildung 17.6
Zusammenarbeit zwischen dem Orchestrator und dem Lifecycle Manager
Der Orchestrator lässt sich auch mit anderen Produkten von VMware kombinieren, wie zum Beispiel dem VMware vCenter Lifecycle Manager. Dieser setzt auf dem Orchestrator auf und kann nur installiert werden, wenn der Orchestrator auf dem Server bereits als Applikation läuft.
17.1.3
VMware vCenter Lifecycle Manager
Der VMware Lifecycle Manager (LCM) erstellt eine Dokumentation über den Lebenszyklus einer virtuellen Maschine. Abbildung 17.7 stellt einen solchen Lebenszyklus schematisch dar. Für die Anfrage zur Erstellung einer virtuellen Maschine wird kein eigenes Benutzer-Interface benötigt. Das Management erfolgt einfach über einen Webbrowser. An dieser Stelle können eine oder mehrere Maschinen »bestellt« werden. Wird eine Maschine angefragt und wurde bei der Erstellung der VM ein Genehmigungsschritt eingefügt, dann erhält der Genehmiger nach der Beantragung eine Benachrichtigungs-E-Mail für die Freigabe der Installation. Nach der Freigabe der Bestellung wird die virtuelle Maschine automatisch angelegt. Sollte es einen Konflikt mit einer bereits bestehenden VM geben, erhält der LCMAdministrator eine Information und kann die Unstimmigkeiten beheben. Nachdem die virtuelle Maschine produktiv gesetzt wurde, läuft sie bis zum angegebenen Ablaufdatum. Fünf Tage vor dem Ablauf der Lebenszeit der VM erhält der Anforderer eine E-Mail und damit die Möglichkeit, den Lebenszyklus des Servers zu verlängern. Diese Aktion erfolgt natürlich erst, nachdem die Genehmigung für die Verlängerung erteilt wurde. Wird das Ablaufdatum der VM nicht geändert, wird sie außer Betrieb genommen und archiviert oder gelöscht.
971
17.1
17
Zusatzsoftware von VMware
Abbildung 17.7
Lebenszyklus einer virtuellen Maschine
Die Rechtezuweisung für die einzelnen Aufgaben im System erfolgt über Rollen. Derer gibt es fünf unterschiedliche, Tabelle 17.1 gibt über ihre Funktion Auskunft. Rolle
Beschreibung
LCM Administrator
Der LCM Administrator legt die Richtlinien fest, nach denen die VMs angelegt und konfiguriert werden.
LCM Requester
Diese Rolle ist für die Beantragung von VMs zuständig und umfasst das Recht zum Ein- und Ausschalten der beantragten VM. Die administrativen Rechte an der VM können auch delegiert werden.
LCM Tech Requester Diese Rolle entspricht der LCM-Requester-Rolle mit der zusätzlichen Möglichkeit, das Template anzupassen. LCM Approver
Diese Rolle bezeichnet den Personenkreis, der für die Freigabe einer bestellten VM geben darf.
LCM IT Staff
Nutzer dieser Gruppe sind dafür zuständig, sich um die virtuellen Maschinen zu kümmern, die nach der Freigabe einen Konflikt gemeldet haben.
Tabelle 17.1
972
Rollen im Lifecycle Manager
Automatisierung
Wie schon beim vCenter Lab Manager wird auch in diesem Fall die VM aus einem Template von fertigen virtuellen Maschinen erstellt. Es entsteht eine lückenlose Dokumentationskette, von der automatisierten Bereitstellung einer virtuellen Maschine über ihre Nutzungsdauer bis hin zur Deinstallation bzw. Außerbetriebnahme und Archivierung. Es besteht sogar die Option, Kosten in dem Tool zu hinterlegen. So haben Sie eine volle Transparenz von der Beantragung bis zur Abschaltung der VM. Es ist möglich, Schnittstellen zu anderen weitergehenden Systemen zu nutzen. Zur Rechtevergabe wird ein bestehender Verzeichnisdienst verwendet, und Informationen werden in einer eigenen Datenbank abgelegt. Das System integriert sich ins vCenter. Dieses muss aber mindestens in der Version 2.5 U3 oder neuer installiert sein. Die Version 4.x wird ebenfalls unterstützt.
17.1.4 VMware vCenter CapacityIQ Die Applikation vCenter CapacityIQ von VMware unterstützt den Administrator der virtuellen Infrastruktur in der Planung und der Erweiterung der VMwareLandschaft. Das Add-on VMware vCenter CapacityIQ gibt Ihnen eine Übersicht über die Ressourcenauslastung Ihrer VMware-Infrastruktur. Es zeigt Ihnen an, wie viele Ressourcen derzeit genutzt werden und welche Reserven noch vorhanden sind. Neben der aktuellen Auslastung sind auch die historische und die zu erwartende künftige Auslastung dargestellt. Dadurch gibt das Tool Ihnen eine Planungsmöglichkeit an die Hand, rechtzeitig zu erkennen, wann die Ressourcen erweitert werden müssen. Eine Reporting-Funktion erstellt eine Liste von Möglichkeiten zur Optimierung der Landschaft. Mit dieser Funktion können Sie Engpässe sofort erkennen und darauf reagieren. Sie können sich auch darstellen lassen, wie sich die virtuellen Maschinen mit der Zeit entwickelt haben. Die Applikation wird als virtuelle Appliance heruntergeladen. Die Appliance besteht vom Prinzip her aus vier Elementen: Der eigentliche vCenter-CapacityIQServer kommuniziert mit dem enthaltenen Datenbank-Server. Das CollectorInterface sammelt die Performance-Daten aus der virtuellen Infrastruktur, sowohl von den Hosts als auch von den virtuellen Gästen. Dieses Interface liefert seine Daten im Minutenrhythmus direkt an die Datenbank. Über alle Elemente legt sich das Administrations-Interface, mit dem Sie die Appliance konfigurieren. Die Administration erfolgt über ein vCenter-CapacityIQ-Plug-in im vSphere-Client.
973
17.1
17
Zusatzsoftware von VMware
Nach der Aktivierung der Applikation bietet sie Ihnen vier Schritte, um Ihre virtuelle Infrastruktur zu verstehen. Ist die initiale Sammlung der PerformanceDaten erfolgt, wird detailliert angezeigt, wie viele Ressourcen derzeit verbraucht bzw. genutzt werden. Sie sehen auch, welche Menge an Ressourcen noch für die Nutzung zur Verfügung stehen. Das Dashboard stellt aber auch Informationen zur Verfügung, die Ihnen helfen zu erkennen, wie viele VMs Sie noch aufbauen können, bevor die Landschaft erweitert werden muss. So liegen die nötigen Informationen vor, die benötigt werden, um zur rechten Zeit zu investieren. Damit bleiben Ihnen Stresssituationen erspart, wenn zu kurzfristig zusätzliche Ressourcen benötigt werden. Als zusätzliche Funktion wird die Möglichkeit geboten, »Was wäre wenn«-Szenarien zu erstellen. Für den Fall, dass größere Übernahmen anstehen oder Sie eine größere Anzahl von virtuellen Maschinen ausrollen müssen, stellt das Tool einen Forecast Wizard zur Verfügung. Dieser Wizard gibt Ihnen das Mittel an die Hand, die Anzahl, die Konfiguration und die Last von neuen virtuellen Maschinen als Simulation in die virtuelle Infrastruktur einzubinden. Mit diesen Informationen berechnet das Softwarepaket die benötigten zusätzlichen Ressourcen für die Abbildung der zusätzlichen virtuellen Systeme. Als Vorlage für die neue Berechnung können Sie auch Profile von bereits vorhandenen Systemen verwenden. Was mit virtuellen Maschinen geht, ist selbstverständlich auch mit ESX-Hosts möglich. Durch das Hinzufügen von neuen oder das Ändern von vorhandenen Hosts berechnen Sie die vorhandenen Host-Ressourcen neu. So ist auf einfache Weise planbar, ob es sinnvoll ist, einen bestehenden Cluster zu erweitern oder einen neuen Cluster aufzubauen. Bevor jedoch neue Ressourcen angeschafft werden, ermöglicht vCenter CapacityIQ zu ermitteln, ob VMs überdimensioniert sind oder ob VMs zwar laufen, aber eigentlich nicht von den Benutzern verwendet werden. Diese überflüssigen Ressourcenfresser können Sie so erkennen und eliminieren. All diese Optionen erlauben in jedem Projekt eine optimale Planung. Die Informationen, die das System zur Auswertung nutzt, stehen ebenfalls zum Abruf von Server-Listen zur Optimierung der derzeit genutzten Ressourcen bereit. Es ist einfach, eine Liste mit Low- bzw. High-Performern zu erstellen. Diese Daten helfen, die Systeme gut zu gruppieren, so dass die Landschaft optimal genutzt werden kann.
974
Billing: VMware vCenter Chargeback
17.2
Billing: VMware vCenter Chargeback
Das sich direkt ins vCenter integrierende VMware vCenter Chargeback dient nicht nur der Kostenanalyse der virtuellen Infrastruktur, sondern auch einer verursachergerechten Abrechnung der Ressourcen anhand der Kundensysteme. Der Aufbau und der Betrieb von virtuellen Infrastrukturen nimmt immer mehr zu. Im Gegensatz zu anderen Anbietern von Virtualisierungslösungen bietet VMware eine Applikation, VMware vCenter Chargeback, um die Ressourcennutzung der virtuellen Maschinen abzurechnen. Während der Installation wird die Applikation mit dem vCenter und dem Datenbank-Server verbunden. Eine Einbindung ins LDAP findet ebenfalls statt. So haben Sie die Option, granulare Rechte im System zu vergeben. Abschließend können Sie eine E-Mail-Adresse oder einen E-Mail-Verteiler für das automatische Versenden von Reports einrichten.
Abbildung 17.8
Struktur von VMware vCenter Chargeback
Der wichtigste Punkt bei der Einrichtung der Anwendung ist das Definieren der Kosten für die Ressourcen. Die Werte sind dabei für jede benutzte Hardwareeinheit einstellbar. Bei der Hinterlegung der Kosten haben Sie einen hohen Flexibilitätsgrad. Sie können die Kosten verbrauchsabhängig oder als Fixkosten festlegen. Auch zusätzliche fixe oder periodische Kosten können Sie berücksichtigen.
975
17.2
17
Zusatzsoftware von VMware
Bei den Ressourcen wird entweder der Durchsatz als Berechnungsgrundlage herangezogen oder die vergebene Kapazität. Damit Sie die monetären Werte für die Abrechnung der Ressourcen richtig hinterlegen können, stellt VMware ein ExcelSheet zur Verfügung. Mit dessen Hilfe können Sie berechnen, welche Kosten verrechnet werden müssen, um die Investition in die Infrastruktur zurückzuerhalten. Dieses Sheet finden Sie unter: http://www.vmware.com/support/vcbm10/doc/vCenter_Chargeback-Costing_ Calculator.xls
Abbildung 17.9
vCenter-Chargeback-Kostenkalkulationssheet
Auf dem ersten Sheet befindet sich eine kurze Anleitung für die Nutzung des Sheets. Der Reiter Costs nimmt alle Kosten auf, die die Landschaft verursacht – die Server-Hardware, Lizenzkosten für die virtuelle Landschaft und die Gastsysteme, das Netzwerk, die Datenbank und den genutzten Storage. Beim CapacityReiter ist zu hinterlegen, welche Reserven in der Landschaft freigehalten werden, damit alle Anfragen bedient werden können. Der letzte Reiter, Recovery, berechnet die Kosten, die eine VM einer definierten Ausprägung verursacht. Die einmaligen Kosten für die Installation einer VM werden ebenfalls eingerechnet. Es fehlen nur die Beträge für die Betriebsaufwände des Gastes und der vSphere-Hosts. In der Applikation hinterlegen Sie nun die Kosten für die zum Einsatz kommenden Ressourcen. Es wird ein Grundbetrag für jede Ressource manifestiert. Anschließend ist für jede virtuelle Maschine ein Faktor einzugeben. Durch die Ressourcengrundkosten und den Ressourcenfaktor einer jeden VM können Sie für jede virtuelle Maschine eine individuelle Rechnung erstellen.
976
Billing: VMware vCenter Chargeback
Abbildung 17.10
Erstellen eines Reports
Über das Kontextmenü der einzelnen VM erstellen Sie einen individuellen Report (Abbildung 17.11). Nach dem Aufruf wählen Sie die individuellen Verrechnungswerte aus, die zur Erstellung der Rechnung herangezogen werden sollen. Geben Sie den Zeitraum der Berechnung an und den Zeitpunkt des Rechnungslaufes. Eine Beispielrechnung für ein System sehen Sie in Abbildung 17.12. So können Sie für jeden virtuellen Server eine Rechnung einsehen. Dies bietet Ihnen eine Transparenz für die Kosten, die durch virtuelle Maschinen entstanden. Durch eine Gegenrechnung der erwirtschafteten Erträge und der Investition lassen sich die Kosten für eine virtuelle Infrastruktur optimieren. Selbstverständlich müssen Sie nicht jede Abrechnung manuell anstoßen, Sie haben natürlich auch die Option, den Rechnungslauf zu automatisieren und die Abrechnung periodisch zu verschicken. Alternativ rufen Sie die Verrechnung der Ressourcen über ein Webportal ab. Die Applikation ist lauffähig ab der Version 2.5 U3 des vCenter-Servers. Die aktuelle Version des vCenters 4.x ist ebenfalls unterstützt.
977
17.2
17
Zusatzsoftware von VMware
Abbildung 17.11
Zusammenstellung einer Abrechnung
Abbildung 17.12
Abrechnungsreport eines Server-Pools
978
Performance: VMware vCenter AppSpeed
17.3
Performance: VMware vCenter AppSpeed
Auch wenn wir in diesem Buch fast durchgängig von virtuellen Landschaften sprechen, so gibt es doch Dinge, die virtuellen und physischen Systemen gemein sind. Es genügt nicht, dass diese Systeme zur Verfügung stehen, es wird von ihnen auch erwartet, dass sie performant arbeiten und definierten SLAs (Service Level Agreements) genügen. Es stellt sich aber immer die Frage, wie und mit welchen Mitteln entsprechende Informationen zur Verfügung gestellt werden können. An dieser Stelle greift die VMware AppSpeed ein. Die Applikation kommt als Virtual Appliance und misst die Latenzzeiten einer Applikation. Es wird der gesamte Datenstrom gemessen, sowohl der eingehende als auch der ausgehende. Die erhaltenen Daten werden mit den SLAs abgeglichen. Auf der dann entstandenen Datenbasis wird ein Reporting erstellt. Unter Zuhilfenahme der Messdaten lassen sich den VMs die Ressourcen zuweisen, die benötigt werden, um die SLAs zu gewährleisten. Beleuchten wir zuerst einmal die Architektur von vCenter AppSpeed. Da ist zuerst einmal der eigentliche Applikations-Server, er integriert sich an den vCenter-Server. Als Client-Interface kommt ein vCenter-Plug-in zum Einsatz, wie Sie das auch schon von anderen VMware-Applikationen kennen. Der AppSpeed-Server dient nur zur Verarbeitung von den Informationen, die von den AppSpeedMesserfassungs-Servern, den sogenannten Probes, geliefert werden. Von diesen Probes benötigen Sie mindestens eine pro vSphere-Host. Die VMware vCenter AppSpeed Probes überwachen den Datenstrom von MSSQL, Oracle, MySQL und Exchange. Des Weiteren tracken Sie Webtraffic über HTTP oder HTTPS. Jede Probe kann Daten von bis zu 8 Switches sammeln, dabei ist es unerheblich, ob es sich um distributed oder Standard-vSwitches handelt. In einer Landschaft können Sie bis zu 32 Probes in Betrieb nehmen. Der VI-Administrator muss nicht unbedingt jede Applikation kennen. AppSpeed durchsucht das Netz und listet die gefundenen Applikationen in seinem Fenster auf. Zusätzlich werden die Server angezeigt, auf denen die Applikationen installiert sind. Über den Traffic im Netzwerk werden die Applikations-Server gefunden und aufgenommen. Zur Darstellung gibt es zwei mögliche Ansichten, entweder serverbasiert oder applikationsbasiert. Selbstverständlich können die Abhängigkeiten der betroffenen Server untereinander auch grafisch aufbereitet werden. Es gibt auch hier verschiedene Darstellungsmodi, bei denen sowohl die Anwendung als auch die Server dargestellt werden.
979
17.3
17
Zusatzsoftware von VMware
Abbildung 17.13
Grafische Übersicht der überwachten Applikationen
Sind die Applikationen erkannt, werden die Zugriffszeiten gemessen. Die Latenzzeiten werden aufgenommen und für spätere Auswertungen gespeichert. Sind erst einmal Messdaten vorhanden, können Sie sich die Daten anschauen und bis auf Befehlsebene hinunter erkennen, welches Kommando welche Laufzeiten hatte. An der Charakteristik des Befehls lässt sich dann im Falle einer zu langen Abarbeitungszeit feststellen, wo der Engpass in der Applikationskette liegt.
Abbildung 17.14
980
Auflistung der Abarbeitungszeiten
Performance: VMware vCenter AppSpeed
Mit diesen Informationen schlagen Sie zwei Fliegen mit einer Klappe: Durch die agentenlose Datenaufnahme rund um die Uhr ist es möglich zu analysieren, wie optimal das Sizing der Server-Kette erfolgte. Eine genaue Auswertung der Daten fördert sofort zutage, an welcher Stelle die Systeme zu viele freie Ressourcen haben oder wo Sie die virtuelle Hardware zusätzlich erweitern müssen. So lassen sich an der einen oder anderen Stelle eine Menge Ressourcen einsparen oder optimieren. Der zweite Vorteil ist die Verwendung der Daten zum Nachweis der Einhaltung der SLAs.
Abbildung 17.15
Einhaltung der SLAs
Dabei lassen sich genau die Werte auswählen, die für die Überwachung der SLAs entscheidend sind. Selbstverständlich können Sie die Überschreitung der Schwellwerte mit einem Alarm koppeln, oder Sie lassen sich einfach per E-Mail informieren. Eine sehr granulare Analyse ermöglicht es Ihnen, genau festzustellen, welche der betroffenen Elemente den Performance-Engpass verursacht hat. Die Software greift hier an einem Punkt an, den jeder Administrator einer virtuellen Infrastruktur kennt: Für alle Probleme in den Gästen ist die Virtualisierung verantwortlich, und es wird vom Administrator erwartet, dass er alle Applikationen kennt, die auf den virtuellen Servern installiert sind. Hier hilft vCenter AppSpeed bei der Root-Cause-Analysis. Sie können genau analysieren und darstellen,
981
17.3
17
Zusatzsoftware von VMware
welcher Befehl beim Zugriff auf die Datenbank Probleme verursacht hat. So gelangen Sie schnell zu einer Problemlösung und können die betroffene Betriebsabteilung gezielt auf die Unstimmigkeit ansetzen, ohne dass Sie selbst Kenntnis von der Applikation und deren Komponenten haben müssen. Die gesamte Datenaufnahme erfolgt agentenlos. Es ist keine zusätzliche Software im Gast notwendig, um die Funktion von VMware AppSpeed zu gewährleisten. Auch hier gibt es einen Link zu einem Video: http://blip.tv/file/2874476/.
17.4
Desktop Autor dieses Abschnitts ist Christoph Dommermuth, Blog: http:// www.thatsmyview.net
Neben dem Thema der Virtualisierung von Server-System hat sich VMware auch mit der Virtualisierung von Desktop-Systemen auseinandergesetzt, wobei man hier grundsätzlich zwei unterschiedliche Verfahren voneinander unterscheiden muss. Das ist zum einen die Virtualisierung der einzelnen Applikation. In diesem Fall stellt ein entferntes System eine Software zur Verfügung, die auf dem Endgerät ausgeführt werden kann, ohne dass sie auf dem Gerät installiert wurde. Zum anderen gibt es die sogenannte Desktop-Virtualisierung. Hier wird der gesamte Desktop, also Betriebssystem und die zu gehörige Applikation, zentral virtualisiert. Der Anwender greift nun über eine Remote-Control-Software auf seinen Desktop zu und kann dort arbeiten. Für diesen Zugriff wird lediglich ein ThinClient benötigt. VMware hat zu beiden Themen ein Produkt im Warenkorb, beide möchten wir nun kurz beschreiben.
17.4.1 ThinApp 4 Um eine VDI-Installation noch flexibler zu gestalten, bietet VMware je nach Lizenzierungsmodell auch gleich die Anwendungsvirtualisierung mit an. ThinApp unterscheidet sich von anderen Anwendungsvirtualisierungsprodukten. Es wird kein Streaming-Server und auch kein Client zur Ausführung der Anwendung benötigt. Alles, was eine ThinApp-Applikation braucht, steckt in einer .exeDatei, dem ThinApp Package. Das Paket wird nicht explizit für eine bestimmte Windows-Versionen erstellt.
982
Desktop
APP
Virtual Registry
Virtual File System
Sandbox
Application THINAPP
OS
OS
Abbildung 17.16
Aufbau eines Softwarepakets
ThinApp-Anwendungen können entweder als EXE/MSI direkt auf das Endgerät (virtueller Desktop, Desktop-/Laptop-PC, Terminal-Server) verteilt oder über das Netzwerk gestreamt werden. Im letzteren Fall werden die Pakete auf einem zentralen Datei-Server abgelegt und über eine einfache Dateiverknüpfung, die auf die Anwendung zeigt, aufgerufen. Zunächst wird dann ein Mini-Streaming-Client aus dem .exe-Paket extrahiert und in den Hauptspeicher des ausführenden Betriebssystems geladen, danach versorgt sich der Client mit den gerade benötigten Daten zur Ausführung der Anwendung aus dem ThinApp-Container.
VMware ThinApp
THINAPP
Abbildung 17.17
Portabilität des ThinApp-Pakets
983
17.4
17
Zusatzsoftware von VMware
VMware View wird durch den Einsatz von ThinApp flexibler, weil Anwendungen nun wie Module nach Bedarf auf dem virtuellen Desktop aufgesetzt werden können. Ein zusätzlicher Vorteil von ThinApp ist es, dass die Anwendungspakete auf verschiedenen Windows-Versionen ausgeführt werden können. Wurde eine Anwendung auf einem Windows-XP-Arbeitsplatz virtualisiert, so kann dasselbe Paket auch auf einem Vista- oder sogar auf einem Windows-Terminal-Server ausgeführt werden. Dies führt zu einer Reduzierung der Kosten im Bereich der Paketierung.
17.4.2 VMware View 4 Desktop-Computer nehmen in der IT-Welt einen kosten- und arbeitsintensiven Platz ein, da der Bedarf an Verwaltungstätigkeiten hier oft extrem hoch ist. Durch die Virtualisierung können Sie diese Arbeitsplätze zentralisieren und die gesamte Desktop-Verwaltung vereinfachen, z. B. bei der Softwareverteilung, dem PatchManagement oder bei bevorstehenden Migrationen auf neue Betriebssysteme, wie aktuell im Fall von Windows 7. VMware bietet mit dem Produkt View 4 eine der führenden Desktop-Virtualisierungslösungen am Markt, die speziell dazu entwickelt wurde, den Desktop als einen Managed Service bereitzustellen – von der Plattform bis hin zum Übertragungsprotokoll für die Bildschirminhalte. VMware View erleichtert das Desktop-Management und hilft dadurch, Kosten im operationellen Bereich einzusparen und der IT eine höhere Kontrolle über die Desktop-Umgebung zu geben und ermöglicht dem Benutzer einen flexiblen, zuverlässigen und sicheren Zugriff auf die von ihm benötigten Anwendungen. Mit View 4 und dem neu implementierten PCoIP-Remote-Protokoll hat VMware eine neue Ära der zentralen Bereitstellung von Desktop-Betriebssystemen eingeläutet. In der Vergangenheit zeigte sich, dass veraltete Remote-Protokolle Schwächen hatten und nicht die optimale Anwendererfahrung (User-Experience) liefern konnten. Genau dort setzt VMware nun an und bringt mit dem PcoIPProtokoll, ein Protokoll, das die Anforderungen an einen heutigen Firmen-Desktop-Arbeitsplatz mit Bravour meistert. PcoIP übermittelt den Desktop aus dem Rechenzentrum über LAN- und WAN-Umgebungen zum Benutzer und ist dabei in der Lage, sich dynamisch an Bandbreiten und Latenzen anzupassen. Dadurch können grafisch intensive Anwendungen, Flash-Animationen und Multimediadaten ohne Probleme in lokalen und Weitverkehrsnetzen übertragen werden. VMware View 4 nutzt als Plattform VMware vSphere und profitiert damit von allen Vorteilen dieser Enterprise-Virtualisierungslösung. VMware View 4 kann problemlos auf einem Windows-Server installiert werden und benötigt keine Schemaerweiterung des Active Directorys. Alle Daten werden in einer lokalen ADAM-Instanz (Active Directory Application Mode) gespeichert. Selbst die
984
Desktop
Datensicherung dieser ADAM-Instanz ist bereits in das Produkt integriert. Abbildung 17.18 stellt eine Standard-View-Umgebung dar.
Centralized Virtual Desktops
Terminal Servers
Linked Clones
Microsoft Active Directory
Blade PCs
VMWARE VIEW MANAGER
Physical PCs
Master Image VMWARE vENTER Clients Offline Desktop
Abbildung 17.18
VMWARE VIEW COMPOSER
Struktur einer VMware-View-Umgebung
Desktop-Virtualisierung hilft schon heute vielen Unternehmen, schwierige Anwendungsfälle abzudecken, bei denen die Sicherheit und Compliance des Betriebs geschützt werden müssen oder Benutzer einfach aus Remote-Locations auf ihre Daten im zentralen Rechenzentrum zugreifen sollen. Bereits heute hat VMware begonnen, die zentrale Verwaltung der Desktops durch View auch auf den mobilen PC-Bereich auszuweiten. Mit dem Offline Desktop – eine Funktion, die sich derzeit noch in einem Tech-Preview-Status befindet – ermöglicht VMware, selbst virtuelle Maschinen, die auf einem mobilen Endgerät gehostet werden, zentral zu verwalten. Diese Lösung wird zukünftig durch die Client-Virtualisierungs-Plattform erweitert (CVP), die VMware auf der VMworld-Veranstaltung im vergangenen Jahr bereits Live demonstrierte. Dadurch wird es später möglich sein, virtuelle Maschinen direkt auf einer zertifizierten Laptophardware ohne Host-Betriebssystem laufen zu lassen, ähnlich wie es vSphere heute im Rechenzentrum macht. Durch diese Schritte wird VDI (Virtual Desktop Infrastructure) auf den mobilen Bereich ausgeweitet. Gehen wir nun etwas genauer auf die einzelnen Komponenten ein.
985
17.4
17
Zusatzsoftware von VMware
Die heutige VMware-View-4-Lösung besteht aus den folgenden Komponenten: 왘
VMware vSphere 4 for Desktops
왘
VMware View Manager 4
왘
VMware View Client
왘
VMware View Agent
왘
VMware View Composer
왘
ThinApp 4
왘
VMware View PCoIP Display Protokoll
왘
Offline Desktop (Tech Preview)
왘
Lassen Sie uns nun die einzelnen Komponenten durcharbeiten.
VMware vSphere 4 for Desktops VMware View 4 nutzt vSphere 4 als Plattform und erhält damit Zugriff auf alle Vorteile der weltweit führenden Virtualisierungs-Infrastruktur-Lösung, die in diesem Buch ausführlich beschrieben wird. Durch höhere Skalierbarkeit und bessere Hardwareunterstützung erlaubt es die Plattform, noch mehr Desktops zu virtualisieren und dadurch auch im Investitionsbereich Kosten zu sparen. VMware View Manager 4 Der VMware View Manager 4 ist eine flexible Desktop-Management- und Broker-Lösung, die es dem Administrator ermöglicht, in kürzester Zeit Desktops bereitzustellen. Dem Benutzer wird dann die Erlaubnis erteilt, auf diese Arbeitsplätze über das Netzwerk zuzugreifen. Der View Manager nutzt das VMware vCenter, um Desktops auf der vSphere Plattform bereitzustellen. Zusätzlich verwendet der View Manager den Verzeichnisservice Microsoft Active Directory in Version 2003/2008 für die Benutzerauthentifizierung und -verwaltung. Nach der Erstellung der Desktops und der Vergabe der Zugriffsberechtigung für einen Benutzer kann dieser per Webportal oder lokal installierter Client-Software über den View Manager auf den oder die zugewiesenen Desktops zugreifen. Der View Manager übernimmt folgende Hauptfunktionen: 왘
Connection Broker Der View Manager verwaltet die Verbindungen zwischen dem Benutzer und dem virtuellen Desktop. Wird ein Anwender erfolgreich authentifiziert, so wird ihm der Bildschirm des entfernten Computers angezeigt.
986
Desktop
Terminal Servers Physical PCs
Blade PCs
VMWARE VIEW MANAGER
Abbildung 17.19
Der View Manager
Der View Manager kann nicht nur Managed Desktops (vCenter Managed VM) bereitstellen, sondern auch andere Quellen wie z. B. Microsoft-Terminal-Server-Sitzungen oder physische Rechner.
Abbildung 17.20
Erstellen eines virtuellen Desktops
Der Dialog bietet die Option, vier verschiedene Client-Maschinen zu erstellen. Im Folgenden möchten wir diese Möglichkeiten näher erläutern. 왘
Individuelle Desktops Unter individuellen Desktops versteht man virtuelle Desktops, die manuell erstellt und einem Benutzer für eine 1:1-Beziehung zugewiesen werden. Nur ein Anwender hat in diesem Fall Zugriff auf die virtuelle Maschine.
987
17.4
17
Zusatzsoftware von VMware
왘
Pools Bei Desktop-Pools spricht man von mehreren Desktops, die zu einem Pool, also einer Einheit, zusammengefasst werden. Desktop-Pools werden automatisch aus einer Vorlage für eine virtuelle Maschine generiert. Beim Anlegen des Pools können Sie neben dem Namen, der Anzahl der verfügbaren Arbeitsplätze und dem Verhalten bei Nichtbenutzung (z. B. Suspend oder Abschalten der VM) viele nützliche Parameter konfigurieren, um die Verwaltung der Umgebung zu erleichtern.
Abbildung 17.21
Eigenschaften eines Desktop-Pools
Auf einen Pool haben entweder einzelne Benutzer oder Benutzergruppen Zugriff. Die Pools unterteilt man nochmals in zwei verschiedene Gruppen, den persistenten und den nicht-persistenten Pools. Der gravierende Unterschied liegt in der festen Zuordnung einer virtuellen Maschine zu einem Benutzerkonto, wobei nach der ersten Anmeldung an einem persistenten Pool eine feste Bindung zwischen dem Benutzer und dem virtuellen Desktop eingegangen wird. Jede zukünftige Verbindung bringt den Benutzer zurück zu seinem eigenen Desktop. Die nicht-persistenten Pools bieten diese Bindung nicht. Hier erhält der Anwender jedes Mal einen neuen Desktop, der nach der Nutzung zur weiteren Verwendung zurück in den Pool geht oder gar gelöscht wird.
988
Desktop
왘
Blade-PC/physischer Desktop In gewissen Anwendungsfällen, wo eine dedizierte Hardware mit hoher Rechenleistung benötigt wird, aber trotzdem eine Zentralisierung, beispielsweise aufgrund von Sicherheitsrichtlinien, gefordert ist, kommen Blade-PCs oder physische Desktops im Rechenzentrum zum Einsatz. View 4 bietet auch hier die Möglichkeiten zur Anbindung und zum Zugriff über den View Client.
왘
Terminal Server Viele Unternehmen setzen schon seit Jahren Microsoft Terminal Server für die zentrale Bereitstellung von Anwendungen ein. Auch hier bietet VMware View eine Integrationsmöglichkeit. Desktops von Windows-Server-2003- und Windows-Server-2008-Terminal-Servern können über den View Manager eingebunden werden.
왘
Hochverfügbarkeit Sie können bis zu fünf Connection-Server in einem Cluster zusammenfassen, was die Verfügbarkeit und Skalierbarkeit einer virtuellen Desktop-Umgebung erhöht und einen automatischen Failover im Fehlerfall erlaubt. Die Server nutzen für das Load-Balancing Industriestandards wie den Microsoft Network Load Balancer (NLB), der mit dem Windows-Server-Betriebssystem kommt, virtuelle Appliances oder auch Hardware-Load-Balancer.
왘
Sicherer Zugriff Die Netzwerkverbindungen in der virtuellen Desktop-Umgebung können durch SSL-Verschlüsselung gesichert werden. Zudem bietet View die Möglichkeit einer Zwei-Faktor-Authentifizierung mit RSA SecurID oder auch die Integration einer Smart-Card-Lösung.
왘
USB-Umleitung USB-Geräte, wie z. B. Massenspeicher oder Drucker, die an den lokalen ClientComputer angeschlossen werden, können nach Wunsch an die virtuellen Desktops weitergereicht werden.
왘
Webbasierende Verwaltung Die komplette Verwaltung der Desktop-Umgebung erfolgt über die webbasierte Managementkonsole. Dadurch erhält der Administrator von jedem Ort aus Zugriff auf die Verwaltungsoberfläche.
Voraussetzung für die Installation eines View Managers ist entweder eine dedizierte 32-/64-Bit-Server-Hardware oder eine virtuelle Maschine, auf der das Betriebssystem Windows Server 2003 ausgeführt wird. VMware View Client VMware View unterstützt den Zugriff von Windows, Linux, Mac und proprietären Betriebssystemen. Dabei wird zwischen einem Webzugriff und dem Zugriff
989
17.4
17
Zusatzsoftware von VMware
über den View Client unterschieden. Der View Client steht für Windows- und Linux-Betriebssysteme zur Verfügung, wobei es hier Unterschiede gibt: Der Windows-Client liefert den höchsten Funktionsumfang und kann ab Windows 2000 SP4 über Windows XP bis zu Windows Vista eingesetzt werden. View 4 unterstützt Windows 7 nur als Tech-Preview. Den View-Linux-Client gibt es in zwei Varianten: den kommerziellen Client, der von Thin-Client-Herstellern integriert wird, und den Open Client, der frei zum Download erhältlich ist. Der Unterschied liegt wieder beim Funktionsumfang, denn der Open Client bietet z. B. nicht die Multimedia-Redirection, mit der Sie bessere Ergebnisse bei der Wiedergabe von Videos erreichen. VMware View Agent Zur Kommunikation mit dem View Manager wird auf jedem virtuellen Desktop der View Agent installiert. Diese Anwendung hat z. B. die Aufgabe, den View Manager über den Status des Desktops zu informieren, also ob aktuell ein Benutzer angemeldet ist, ob dieser sich von der Remote-Sitzung getrennt oder abgemeldet hat. Einen Teil der Informationen können Sie über die View-Verwaltungsoberfläche abfragen. Durch den View Agent wird auch das Single-Sign-on realisiert, das dem Benutzer eine nahtlose Anmeldung an seinem Desktop ermöglicht, ohne die Benutzer-Passwort Kombination mehrmals eingeben zu müssen. VMware View Composer Bereits mit der Einführung von View 3 im Jahr 2008 erweiterte VMware die View-Lösung durch den View Composer. Diese Komponente erreicht je nach Anwendung und Aufbau der Umgebung laut VMware Storage-Einsparungen im Bereich von 50 bis 70 %, manchmal auch mehr. Dabei setzt das Produkt auf die Linked-Clone-Technologie, bei der die Desktops nicht wie beim traditionellen VDI jeweils eine eigene Festplatte zur Ablage der Betriebssystemdateien und Programme besitzen, sondern sich ein sogenanntes Parent-Image teilen. Jeder virtueller Desktop verlinkt sich für »sein« Betriebssystem mit dem Parent-Image. Dabei arbeiten nach den Best Practices bis zu 64 virtuelle Maschinen auf einem Image, wodurch die Storage-Einsparungen erzielt werden. Jede virtuelle Maschine hat zusätzlich eine eigene Festplatte, um die Personalisierung sowie die Änderungen zu speichern, mit denen sich der Desktop und das Parent-Image voneinander unterscheiden. Der View Composer ermöglicht durch seine Funktionen aber auch ein sehr schnelles Provisioning von neuen Desktops, denn Sie müssen nicht mehr für jede virtuelle Maschine einen Full-Clone erzeugen.
990
Desktop
Abbildung 17.22
Unterschied klassischer VDI versus View Composer
VMware View PCoIP Display Protokoll Mit View 4 hat VMware auch die erste Version des neuen Software-PCoIP-Protokolls veröffentlicht, das speziell für den Einsatz auf virtuellen Maschinen optimiert ist. Das Protokoll, das in einer Gemeinschaftsentwicklung mit dem eigentlichen Hersteller Teradici entstand, ist nicht ganz neu, denn es existierte bereits schon mehrere Jahre am Markt, allerdings in einer Hardwarevariante, bei der im Client sowie im Endgerät, auf das zugegriffen werden soll, ein spezieller Chip integriert sein muss. Das auf Hardware basierende PCoIP wird heute häufig im Bankensektor, für CAD/CAM-Arbeitsplätze oder auch im Gesundheitsbereich eingesetzt, jeweils dort, wo Bildschirminhalte sehr schnell, sicher und zuverlässig übertragen werden müssen. View 4 enthält aber eine Softwarevariante des Protokolls, die keinerlei Chip für den Betrieb benötigt. Die PCoIP-Komponenten werden einfach mit dem View Client und dem View Agent installiert, wobei auf der virtuellen Maschine dadurch auch spezielle Grafikkarten- und Audiotreiber implementiert werden. Das Protokoll liefert im LAN eine der Arbeit am lokalen PC nahezu gleiche Erfahrung, und selbst im WAN kann in Latenzbereichen von 150 bis 250 ms noch mit einem produktiven Desktop gearbeitet werden. PCoIP ist ein dynamisches Protokoll und passt sich den gegebenen Bandbreiten und Latenzen an, ändert also basierend darauf die Qualität von Audio und die Kompression der Bildinhalte. Neben einer Multimedia-Umleitung zum Client, dem dynamischen Host- und Client-side Rendering von Grafikdaten und der dynamischen Adobe-Flash-Kontrolle bringt PCoIP eine Technologie mit dem
991
17.4
17
Zusatzsoftware von VMware
Namen Progressive Build mit sich, die eine spezielle Art der Komprimierung vornimmt, um dem Benutzer so eine gewohnte Erfahrung zu liefern. Bildschirminhalte werden bei geringeren Bandbreiten zunächst mit verlustreicher Qualität übermittelt, damit der Benutzer schon ein Bild sieht, und werden dann sofort nachgeschärft, wobei Text sofort angezeigt wird. Mit PCoIP können Sie selbst Spezial-Arbeitsplatzkonfigurationen abbilden, die mehrere Monitore benötigen. Die Softwareversion des Protokolls unterstützt – Stand zur Drucklegung des Buches – vier Bildschirme, die auch per Pivot-Funktion um 90 Grad gedreht werden können. Diese erste Version von PCoIP enthält folgende Schlüsselfunktionen: 왘
spezielle Optimierung des Protokolls für den Einsatz in virtuellen Maschinen
왘
Virtual-Channel-Unterstützung für Third-Party-Add-ons
왘
Unterstützung der Gastbetriebssysteme Windows XP, Vista und Windows 7 (Tech-Preview)
왘
dynamische Bandbreitenanpassung basierend auf den Netzwerkkonditionen
왘
dynamische Audioanpassung
왘
Multi-Monitor-Betrieb bis 1 920 × 1 200 pro Monitor
왘
Unterstützung für ClearType-Schriftarten
왘
Pivot-Unterstützung
왘
Multimedia-Redirection
왘
dynamisches Client- oder Host-side Rendering
왘
progressiver Bildaufbau
왘
USB-Umleitung
vier
Monitore
mit
einer
Auflösung
von
VMware View unterstützt beide Varianten des Protokolls, sowohl Software, als auch Hardware. Dabei sind Software-zu-Software, Hardware-zu-Hardware, aber auch Mischverbindungen wie Hardware-zu-Software und umgekehrt über den View Manager möglich. So erreicht der Kunde eine maximale Flexibilität bei der Auswahl der Client-Hardware, da nicht nur FAT-Clients oder Standard-ThinClients eingesetzt werden können, sondern auch die speziellen Geräte, die schon einen Teradici-Tera-1-Chip integriert haben. Offline Desktop (Tech-Preview) Mit der Funktion Offline Desktop, die in View 4 noch nicht offiziell vom VMware-Support unterstützt wird, hat VMware die Möglichkeiten und Vorteile einer virtuellen Desktop-Umgebung auf mobile Benutzer erweitert. Um View zu
992
Desktop
nutzen, benötigt der Anwender eine Netzwerkverbindung. Es gibt Situationen, z. B. im Außendienst, wo der Anwender aufgrund von fehlender Anbindung an das Internet nicht auf seinen zentralisierten Desktop im Rechenzentrum zugreifen kann.
Centralized Virtual Desktops
Offline Desktop Abbildung 17.23
VMWARE VIEW MANAGER VMware View Offline Desktop
Dies ist einer von vielen Anwendungsfällen, bei denen ein Offline Desktop zum Einsatz kommen könnte. Ein zweites Beispiel wäre das Thema Employee-owned IT (EOIT), bei der Firmen dem Mitarbeiter einen gewissen Anschaffungsbetrag für einen Laptopcomputer zur Verfügung stellen. Der Mitarbeiter wählt dann selbst aus einer Liste von kompatiblen Geräten aus und verwaltet seinen HostComputer selbst. Die Firmenanwendungen laufen dabei in der virtuellen Maschine, die über Offline Desktop bereitgestellt wird und die den Sicherheitsund Compliance-Anforderungen des Unternehmens entspricht. Offline Desktop befindet sich noch in einem Tech-Preview-Status, kann jedoch schon sehr weitreichend genutzt werden. Der Benutzer benötigt auf seinem Endgerät eine spezielle View-Client-Version mit Offlinefunktionalität, um seinen virtuellen Desktop aus dem Rechenzentrum auszuchecken und dann offline, ohne Netzwerkverbindung, nutzen zu können. Während die virtuelle Maschine auf dem mobilen HostComputer ausgecheckt ist, kann die Kopie, die sich noch auf der zentralen VMware-View-Umgebung befindet, nicht verwendet werden – sie ist gesperrt.
993
17.4
17
Zusatzsoftware von VMware
Erst nach einem Check-in, bei dem nur die geänderten Daten (Delta) vom Laptop zurück in das Rechenzentrum synchronisiert werden, ist der Zugriff auf den sich im Rechenzentrum befindlichen virtuellen Computer wieder möglich. Sollte der Benutzer längere Zeit unterwegs sein, so kann er den virtuellen Desktop bei Verbindung zum View-Server auch einfach sichern; der Arbeitsplatz bleibt dabei aber ausgecheckt. Bereits in dieser Tech-Preview-Version von Offline Desktop hat VMware gewisse Sicherheitsrichtlinien eingebaut. So können Sie zentral festlegen, wer einen Desktop mitnehmen darf und wie lange dieser Computer offline genutzt werden kann. Zudem ist das Offline-Image verschlüsselt. Zukünftig wird der Offlinebereich noch um eine weitere Funktion, der Client-Virtualisierungs-Plattform (CVP), ergänzt, wobei dann kein Windows-Host-Betriebssystem mehr benötigt wird, weil die CVP dies selbst darstellt. Planung ist alles! Virtuelle Desktop-Umgebungen unterscheiden sich von herkömmlichen Desktop-Arbeitsplätzen auf den ersten Blick nicht drastisch. Es handelt sich ja auch nur um ein Standard-Desktop-Betriebssystem, das zentral im Rechenzentrum ausgeführt wird. Bei genauerer Betrachtung entdeckt man jedoch viele Punkte, die eine unterschiedliche Handhabung und Verwaltung der Umgebung erfordern. Darum sollten Sie vor jedem Virtual-Desktop-Infrastructure-Projekt dringend Rat von einem kompetenten Partner einholen, um jede Hürde ohne Probleme zu nehmen. Zu Beginn eines jeden Projekts sollte ein Assessment der bestehenden DesktopUmgebung erfolgen. Dadurch wird die Tauglichkeit der verschiedenen Arbeitsplatz-Typen als virtueller Desktop identifiziert. In einem solchen Assessment sollten Sie CPU, Speicher und Netzwerkaktivitäten, aber auch die ausgeführten Betriebssysteme, die installierte Software und die angeschlossene Hardwareperipherie betrachten. Das Know-how des Partners sowie die Qualität der in einem Assessment gesammelten Informationen sind maßgeblich für den Erfolg eines View-Projekts. Inzwischen haben sich Softwarehersteller wie Liquidware Labs am Markt etabliert, die eine spezielle Softwarelösung für Desktop-Assessments entwickelt haben und damit genau analysieren können, inwieweit bestimmte Workloads oder Anwendungen für VDI geeignet sind. Sie helfen dann bei der Migration/Integration und schließlich beim Monitoring und Capacity-Planning der virtuellen Desktop-Umgebung und verhelfen dem gesamten Projekt zum Erfolg.
994
vCenter Site Recovery Manager
17.5
vCenter Site Recovery Manager Autor dieses Abschnitts ist Sebastian Wischer, team(ix) GmbH, [email protected]
Mit dem vCenter Site Recovery Manager (SRM) bietet VMware ein Produkt an, das im Desasterszenario unterstützen soll. Dabei wird nicht nur die Verwaltung der Sites unterstützt, sondern auch der Prozess der Automatisierung. Im Gegensatz zu anderen Funktionen zur Ausfallsicherheit, die in VMware vSphere bereits enthalten sind, deckt der SRM den Ausfall ganzer Sites ab. Es handelt sich hierbei also nicht um Szenarien wie den Ausfall einzelner Komponenten – z. B. eines Hosts, eines Controllers, eines Switches oder einer einzelnen virtuellen Maschine –, sondern um den kompletten Ausfall eines Rechenzentrums oder eines Standortes.
Abbildung 17.24
Überblick VMware Site Recovery Manager
Dabei ist der SRM nur eine Teilkomponente, die zu einem komplexen Konglomerat gehört. Schließlich ist es ebenfalls notwendig, den Plattenplatz über zwei Standorte zu spiegeln. Mit der Software kann nicht nur die endgültige Übernahme einer Site oder eines Rechenzentrums erfolgen, dieser Prozess kann auch verprobt werden, ohne dass dies für die produktiven Systeme eine Auszeit bedeutet. Damit kann regelmäßig ein Test erfolgen ohne eine weitere Beeinträchtigung anderer Komponenten und vor allem der Anwender.
995
17.5
17
Zusatzsoftware von VMware
17.5.1
Der Katastrophenfall
Tritt der Katastrophenfall ein, ist das gleichbedeutend mit einem kompletten Neustart der IT-Landschaft an einem anderen Standort. Wer schon einmal eine Stromabschaltung in seinem Rechenzentrum miterlebt hat, versteht, wovon wir hier reden. Es ist nicht einfach mit dem Einschalten aller Komponenten getan, Sie müssen sich schon im Vorfeld Gedanken machen, was in welcher Reihenfolge gestartet werden muss, damit alle Dienste ordnungsgemäß laufen. In der Regel gibt es sogenannte K-Fall-Handbücher, in denen ein solcher Prozess genau hinterlegt ist. Diese Informationen kommen Ihnen bei der Planung nun zugute. Dieses Handbuch hilft dem Administrator, Schritt für Schritt die ausgefallene Umgebung an einem anderen Standort wieder hochzufahren. Aufgrund stetiger Änderungen im Rechenzentrum ist die Pflege eines solchen Handbuches häufig sehr schwer, der praktische Test eines solchen Schwenks meist unmöglich. Problematisch ist dabei, dass viele Ansätze in diesem Umfeld ein zweites Rechenzentrum benötigen mit nahezu identischer Hardwareausstattung, die für den eventuellen K-Fall bereitsteht. Man könnte fast sagen, es muss eine Investition getätigt werden, bei der man hofft, dass sie nie wirklich benötigt wird. Ein weiterer zu beachtender Faktor bei einem solchen Szenario ist der Mensch oder besser der Administrator. Zu den eventuell möglichen Tippfehlern, die beim Abschreiben der nötigen Kommandos aus dem Handbuch passieren können, kommt ein hoher Stressfaktor in dieser Situation hinzu. Eventuell muss der Administrator, gerade aus einem Gebäude vor dem Feuer geflüchtet, nun dafür sorgen, dass ein ganzes Unternehmen schnell wieder grundlegend arbeitsfähig wird. Zur Vereinfachung dieses Prozesses und der fehlerunanfälligen Abarbeitung der Inbetriebnahme des Backup-Rechenzentrums dient der SRM als Unterstützung.
17.5.2 Aufbau und Implementierung Der Site Recovery Manager greift genau an diesen Punkten ein. Als Voraussetzung muss es auf der Storage-Ebene ein unterstütztes System mit Replikationsfunktion geben. Mit Hilfe dieser Technologie werden die virtuellen Server der vSphere-Landschaft von der primären bzw. produktiven Seite auf die sekundäre, die Recovery-Site, übertragen. In der Regel erfolgt dies mittels asynchroner Spiegelung. Eine asynchrone Spiegelung bedeutet einen zeitlichen Versatz bei der Übertragung der Storage-Informationen. Ist die WAN-Bandbreite zwischen zwei Standorten nicht so performant, dann ist dies die Methode der Wahl. Natürlich können verschiedene Storage-Systeme auch synchron spiegeln. In diesem Fall sind die Daten in beiden Standorten identisch, mit einem minimalen Zeitversatz. Auf der primären Seite findet man weiterhin die produktiven vSphere-Hosts, das vCenter und natürlich die gesamten virtuellen Maschinen.
996
vCenter Site Recovery Manager
Ähnlich wie andere Zusatzprodukte von VMware wird der Site Recovery Manager auf einem Windows-Server zusätzlich zum vCenter installiert. Die Entscheidung liegt beim Administrator, ob er die Software auf einem physischen oder einem virtuellen Server installiert.
»Protected« Site vSphere Client
Protection can be bidirectional
SRM Plug-In
»Recovery« Site SRM Plug-In
DB
vSphere Client
DB DB
DB
vCenter Server
SRM-Server
vCenter Server
SRM-Server
SRA
SRA
ESX ESX ESX BlockReplication Software vmfs
vmfs
SAN-Array
ESX
BlockReplication Software vmfs
vmfs
Abbildung 17.25
ESX
vmfs
vmfs
SAN-Array
Aufbau Site Recovery Manager im Detail
Auf der sekundären Seite sind ebenfalls ein oder mehrere Hosts aufzubauen, um die virtuellen Server abbilden zu können, die im Desasterfall übernommen werden sollen. Die Anzahl und der Ausbau der Server müssen nicht der primären Seite entsprechen. Zusätzlich zu den ESX-Servern muss auch ein zweites vCenter und ein zweiter SRM-Server auf der sekundären Seite eingerichtet werden.
17.5.3 Storage-Replication-Modul (SRA) Für die Kommunikation des vSphere Site Recovery Managers mit dem angeschlossenen Storage müssen Sie den entsprechenden Storage-Replication-Adapter installieren. Die Replikation ist manuell einzurichten. Im Desasterfall muss der SRM-Server mit Hilfe dieses Moduls die Spiegelung aufbrechen. Das bedeutet, dass die Daten nicht weiter von dem primären Rechenzentrum auf die sekundäre Seite übertragen werden. Zudem wird der Lese- und Schreibzugriff auf den Speicher der sekundären Seite für die dort stehenden Hosts aktiviert. Das SRA-Modul sorgt auch dafür, dass bei einem Test eines Recovery-Plans ein Clone der replizierten LUN oder des Volumes angelegt und nach Abschluss des Tests wieder gelöscht wird.
997
17.5
17
Zusatzsoftware von VMware
Für jeden Storage, den der vCenter Site Recovery Manager unterstützt, stellt VMware ein passendes SRA-Modul zur Verfügung. Nur mit diesem Modul ist die Funktion der SRM gewährleistet.
17.5.4 Site Recovery Manager Plug-in Der SRM integriert sich in das vCenter. Über den vSphere-Client wird die ClientKomponente installiert. Über dieses Interface werden die beiden vCenter-Server und die beiden Array-Manager vom primären und sekundären Standort miteinander verknüpft. Zur einwandfreien Funktion ist im Client ein Inventory-Mapping vorzunehmen. Dabei werden die Datacenter- und VM-Netzwerke miteinander verknüpft. Damit wird festgelegt, welches die primäre und welches die sekundäre Komponente ist. Die Datacenter haben immer unterschiedliche Namen, z. B. »DC-Primär« und »DC-Sekundär«, damit der SRM weiß, welches das primäre und welches das zugehörige sekundäre Datacenter ist. Beide werden dann in einem Folgeschritt miteinander verknüpft. Hier wird dem Umstand Rechnung getragen, dass in einem Rechenzentrum auch mehrere Sites gehostet werden können, weil dort beispielsweise unterschiedliche Kunden ihre Systeme stehen haben. So können unterschiedliche Umgebungen abgebildet und voneinander getrennt werden. Es muss ja nicht jedes Datacenter im SRM berücksichtigt werden.
Abbildung 17.26
998
Konfiguration des SRM im vSphere-Client
vCenter Site Recovery Manager
Seit vSphere 4 können die produktive und die Recovery-Site mittels Linked Mode in einem vSphere-Client angezeigt werden. Ohne Linked Mode muss immer ein vSphere-Client mit der produktiven Seite und einer mit der Recovery-Seite in Verbindung sein, um beide Seiten parallel einsehen zu können. Abbildung 17.27 zeigt zwei Sites in einem Client. In diesem Fall handelt es sich um einen Cluster mit zwei Hosts, zwei Resource-Pools und acht virtuellen Maschinen. site1vc.vcb.local site1 site1cluster 192.168.92.11 192.168.92.16 Site1Infrastructure site1mgmt site1srm1 site1srm2 site1srm3 site1vc Site1Production site1-vm1 site1-vm2 site1-vm3 site1-vm4 site2vc.vbc.local site2 site2cluster 192.168.92.12 192.168.92.17 Site1Recovery site1-vml1 site1-vml2 site1-vml3 site1-vml4 Site2Infrastructure site2srm1 site2srm2 site2srm3 site2vc
Abbildung 17.27
Übersicht der Sites im vSphere-Client
17.5.5 Protection Groups Nach der Verknüpfung der beiden Seiten müssen die Protection Groups eingerichtet werden. Eine Protection Group ist eine Gruppe von virtuellen Maschinen, die im Desasterfall auf der sekundären Seite neu gestartet werden. Die Anzahl der Protection Groups ist nicht auf eine beschränkt. Sie besteht aus virtuellen Maschinen, die gruppiert werden. So fassen Sie z. B. alle VMs auf einem gemeinsamen Datastore in einer Gruppe zusammen. Eine Protection Group kann gebildet werden mit den virtuellen Maschinen der ersten LUN oder des ersten Volumes, eine andere mit den VMs der zweiten LUN. Alternativ füllen Sie eine mit den virtuellen Maschinen beider LUNs oder Volumes.
999
17.5
17
Zusatzsoftware von VMware
17.5.6 Recovery-Plan Für eine oder mehrere Protection Groups ist ein Recovery-Plan sinnvoll. In diesem legen Sie fest, wie bei einem Ausfall vorzugehen ist. Es kann einen RecoveryPlan für den kompletten Ausfall der primären Seite geben oder auch für den Ausfall einer einzelnen LUN. So bereiten Sie schon jetzt für die unterschiedlichen Szenarien Pläne vor. In einem Recovery-Plan können Sie verschiedene Aktionen festlegen, angefangen beim Herunterfahren der virtuellen Maschinen auf der primären Seite über die Startreihenfolge und Anpassung der virtuellen Maschine auf der sekundären Seite. Letzteres kann zum Beispiel nötig sein, um virtuelle Maschinen auf der sekundären Seite in ein anderes Netzwerk zu konfigurieren. In den RecoveryPlan können Sie auch individuelle Skripte, Befehle oder Abhängigkeiten einarbeiten. Eine Abhängigkeit kann zum Beispiel sein, dass erst, nachdem die VMware Tools der virtuellen Maschinen gestartet sind, mit dem nächsten Schritt begonnen wird. So werden unterschiedliche Gruppen von virtuellen Maschinen, die in Abhängigkeit voneinander stehen, nacheinander gestartet. Abbildung 17.28 zeigt die Funktionen, die mit einem Recovery-Plan verbunden werden können.
Abbildung 17.28
Überblick VMware Site Recovery Manager
Ein weiterer Vorteil des SRMs ist, dass auf der sekundären Seite auch virtuelle Maschinen betrieben werden dürfen. Sie können Testumgebungen aufbauen, die im Desasterfall dann einfach heruntergefahren werden, um so die Ressourcen für die produktiven VMs freizugeben. Der SRM wird auf Ebene der virtuellen
1000
vCenter Site Recovery Manager
Maschinen konfiguriert, so können nichtkritische VMs im K-Fall ausgeschaltet bleiben oder erst später eingeschaltet werden. So wäre es möglich, zunächst den Domain-Controller zu starten. Nachdem dieser komplett gebootet ist, wird mit dem Mail-Server fortgefahren. Erst dann würden die wichtigen Datenbank- und Applikations-Server folgen. Wichtig ist aber, dass der Recovery-Plan stetig gelebt und an die Änderungen in der Umgebung angepasst wird. Sehr angenehm ist dabei die Möglichkeit des Tests, ohne dass die produktive Umgebung beeinflusst wird.
17.5.7 Testen des Desasterfalls Für den täglichen Betrieb ist es sehr angenehm, dass Sie den Recovery-Plan jederzeit testen können. So überprüfen Sie immer wieder, im Fall des Falles der Plan noch aktuell ist. Beim Test des Recovery-Plans wird die Spiegelung nicht aufgebrochen, und die virtuellen Maschinen auf der produktiven Seite arbeiten normal weiter. Für den Test erstellen Sie nur einen Clone des Storage-Spiegels und versuchen, aus diesem Clone die benötigten virtuellen Maschinen zu starten. Damit es zu keinen IP-Adressen-Konflikten kommen kann, hängen Sie die gestarteten VMs in ein isoliertes Netz. So kann mit Hilfe der VM-Konsole im vSphereClient auch in den VMs gearbeitet werden.
Abbildung 17.29
Testen eines Recovery-Plans
Der Test eines Recovery-Plans kann also auch dafür genutzt werden, kurzzeitig eine Testumgebung bereitzustellen. Diese basiert dann auf einem Datenbestand der Produktion zum Zeitpunkt der letzten Replikation, aber Sie können Tests an
1001
17.5
17
Zusatzsoftware von VMware
einer mit der Produktion fast identischen Umgebung durchführen. Dies wäre zum Beispiel vor einem größeren Patch-Vorgang interessant. Durch das Aktivieren eines Test Recovery-Plans wird die sekundäre Seite isoliert gestartet. Jetzt können dort die gewünschten Tests durchgeführt werden, ohne dass die produktive Landschaft beeinträchtigt wird. Am Ende löschen Sie die Testumgebung wieder. Auf dem Speichersystem wird dafür nur der Platz für die Änderungen der Storage-Daten benötigt, denn es darf auf dem Spiegel nur gelesen werden! Einzig die Änderungen werden in den Snapshot-Bereich geschrieben, der Plattenplatz wird nach dem Abschluss der Tests wieder freigegeben.
17.5.8 Der Desasterfall Der SRM erkennt einen Desasterfall nicht automatisch, aber die Bereitstellung eines passenden Recovery-Plans erleichtert dem Administrator das Umschalten oder Neustarten der IT-Landschaft wesentlich. So muss anstelle der manuellen Arbeit nur noch das Desaster von einer autorisierten Instanz im Unternehmen erklärt werden. Dann kann der Administrator den Recovery-Prozess mit Hilfe des entsprechenden Plans starten. Wenn der Wunsch besteht, kann die Abwicklung des Recovery-Plans auch automatisch erfolgen. Der grundlegende Ablauf ist also immer identisch: Zuerst wird das Desaster erklärt, dann startet der Recovery-Vorgang durch den Administrator. Jetzt übernimmt der SRM, entsprechend dem vorher erstellten Plan, die Wiederherstellung. Dabei kann der Administrator Schritt für Schritt mitverfolgen, welche Aktion gerade durchgeführt wird – Herunterfahren der eventuell noch laufenden virtuellen Maschinen auf der primären Seite, Herunterfahren von eventuell vorhandenen und nichtkritischen virtuellen Maschinen auf der Recovery-Site; Aufbrechen der Replikation und Anbindung des Speichers an die ESX-Hosts auf der sekundären Seite. Anschließend werden die festgelegten virtuellen Server in der definierten Reihenfolge gestartet, bis alle benötigten Dienste wieder zur Verfügung stehen.
17.5.9 Neuerungen in SRM 4 Die Version 4 des Site Recovery Managers erschien im Oktober 2009. In erster Linie stand die Unterstützung von vSphere als Grundlage für den SRM im Vordergrund. So können jetzt endlich bestehende Umgebungen, die mit dem SRM und VMware Infrastructure 3 arbeiten, auf vSphere upgraden.
1002
vCenter Site Recovery Manager
Seit SRM 4 wird auch ein bidirektionaler Betrieb unterstützt. Wie in Abbildung 17.25 angedeutet, kann ein Standort produktiv und gleichzeitig die Recovery-Site für einen anderen Standort sein. Dadurch muss nicht mehr eine dedizierte Infrastruktur für den Desasterfall aufgebaut werden. Eine weitere Neuerung ist die Shared DR Site. Das bedeutet: Ein Rechenzentrum kann Recovery-Site für mehrere Standorte sein. Ein mögliches Szenario wäre ein Unternehmen mit mehreren Standorten. Die Standorte replizieren ihre Daten in den Hauptstandort. Anstelle des Hauptstandortes könnte auch ein HostingAnbieter eingesetzt werden. Das Unternehmen repliziert seine kritischen Systeme zum Hosting-Unternehmen und fährt im Notfall dort die wichtigen Systeme hoch. Wird eine Testumgebung benötigt, kann sie beim Hosting-Unternehmen gestartet werden. Bei diesen Szenarien müssen Sie natürlich die Anbindung zwischen Außenstandort und Zentrale bzw. Hosting-Unternehmen bedenken. Eine weitere Neuerung ist die Unterstützung von NFS-Datastores. Viele Unternehmen nutzen heute NFS zur Anbindung ihres Speichers.
Abbildung 17.30
NFS-Unterstützung des Site Recovery Managers
Frühere SRM-Versionen unterstützten nur die Anbindung zentraler Speicher über Fibre-Channel oder iSCSI. Mit SRM 4 können Sie auch in solchen Umgebungen Desaster-Recovery-Konzepte auf Basis des SRM realisieren.
1003
17.5
17
Zusatzsoftware von VMware
17.5.10 Anmerkungen Der Site Recovery Manager ist ein interessantes Produkt für die Realisierung von DR-Konzepten mittels Replikation auf Storage-Ebene. Die Hauptkosten entstehen durch die Anbindungen zwischen den beiden Standorten und Bereitstellung der Hardware und Software auf der zweiten Seite. Da der SRM aber nicht nur im Desasterfall genutzt werden kann, sondern auch bei anderen Anforderungen wie z. B. der Bereitstellung einer produktionsnahen Testumgebung, nutzt er die zweite Umgebung auch aktiv. Außerdem darf und kann die zweite Seite auch für produktive virtuelle Maschinen verwendet werden. Damit nutzen Sie die Ressourcen effektiver.
1004
Oftmals sind die Lizenzierungsmodelle von Software auf den ersten Blick nicht so klar, wie mancher es sich wünschen würde. Im folgenden Kapitel werden wir genau diesen Sachverhalt angehen. Es wird versucht, ein Höchstmaß an Transparenz in die Lizenzierung von vSphere und die damit verbundenen Fragestellungen zu bringen. Weiter werden Fragen zum Support behandelt und das Lizenzportal näher beleuchtet.
18
Die Lizenzierung von vSphere Autor dieses Kapitels ist Günter Baumgart, Consultico GmbH, [email protected]
Die Lizenzierungsmodelle der Softwarehersteller sind sehr unterschiedlich. Jeder Hersteller hat eigene Methoden, seine Software zu vermarkten. Hier gilt es, gut darauf zu achten, dass das Lizenzierungssystem vor der Bestellung verstanden wurde, da sonst sehr schnell große Schäden entstehen können. Es gibt immer sehr viele Fragen, die im Vorfeld beantwortet werden müssen, darunter: 왘
Wie viele Pakete oder Bundles gibt es überhaupt?
왘
Welche Merkmale sind in welchem Paket enthalten?
왘
Was kosten Lizenzen?
왘
Basiert die Lizenzierung auf Sockeln?
왘
Was ist denn bzgl. der Lizenzierung eigentlich gemeint, Kerne in einer einzelnen CPU oder komplette CPUs bzw. Sockel?
Sicher haben Sie sich auch schon oft derartige Fragen stellen müssen und hoffentlich auch immer richtige Antworten bekommen. In den Beispielen zur Lizenzierung, die Sie auf den Folgeseiten finden werden, sind hier und da auch Preise enthalten. Diese stammen aus der Preisliste von VMware (Mai 2009). Bitte fragen Sie, wenn Sie eine Beschaffung planen, immer nach aktuellen Preisen für die Lizenzen. Prüfen Sie lieber einmal mehr nach, ob in der Kombination der Softwaremerkmale kürzlich Änderungen vorgenommen wurden. Wer möchte schon, nachdem er sich alles mühevoll zusammengestellt hat und im Unternehmen unterschiedlichste Hürden nehmen musste, letztendlich erfahren, dass der Etat doch nicht ausreicht? Der umgekehrte Fall kommt eigentlich eher seltener vor.
1005
18
Die Lizenzierung von vSphere
Auch müssen Sie immer im Auge behalten, dass es sogenannte Acceleration-Kits gibt. Hierbei handelt es sich um Pakete, die im Vergleich zu Einzellizenzen einen deutlichen Preisvorteil bieten. An dieser Stelle wird bereits klar, dass eine genaue Kenntnis der VMware-Lizenzthematik zu Einsparungen führen kann.
18.1
Die unterschiedlichen Pakete
VMware bietet zum Zeitpunkt der Drucklegung des Buches drei unterschiedliche Gruppen von Paketen an. Beachten Sie jedoch, dass zurzeit nicht alle Pakete erweiterbar sind. Wenn Sie ein derartiges Paket erwerben, müssen Sie sich bereits im Vorfeld darüber im Klaren sein, dass zusätzliche Merkmale und Erweiterungen nicht mehr möglich sind. Diese Entscheidung ist oftmals kaum zu treffen, da nicht immer klar ist, wie sich die geplante Virtualisierung in einem Unternehmen später tatsächlich auswirken wird. Hier ist schnell eine Fehlinvestition getätigt, und das nicht nur bei der Lizenzierung, sondern natürlich auch im Hinblick auf die verbrauchten Ressourcen.
18.1.1
vSphere4 – for free
Der ESXi Server ist die kostenfreie Variante des Hypervisors zur Server-Virtualisierung aus der VMware-Produktfamilie. Wie Abbildung 18.1 zu entnehmen ist, unterstützt diese Server-Variante Vier-Wege-vSMP, 256 GB Hauptspeicher, CPUs mit bis zu sechs Kernen sowie Thin Provisioning.
Abbildung 18.1
1006
Die Merkmale des ESXi
Die unterschiedlichen Pakete
18.1.2
vSphere4 – Small Business
Eine weitere Möglichkeit, Virtualisierung zu praktizieren, stellt VMware mit den beiden Essential-Paketen zur Verfügung.
Abbildung 18.2
Die Merkmale des Small-Business-Paketes
Essential ist in zwei unterschiedlichen Variationen erhältlich: als Essential und als Essential Plus. Das Interessante daran ist, dass der vCenter Server in beiden Paketen in der Version Foundation enthalten ist. Der vCenter Server kann in diesen Versionen zwar nur in einem Dreiknotenverbund eingesetzt werden, aber das ist bei modernen Servern ja unter Umständen kein Nachteil. Denken Sie an dieser Stelle z. B. an Server, die mit zwei Sockeln ausgestattet sind und jeweils sechs Kerne je CPU enthalten. Ein derartiger Dreiknotenverbund enthält immerhin 36 Kerne. Diese Menge an möglicher Leistung ist für viele kleine Anwender oftmals mehr als hinreichend. Die Leistungsmerkmale dieser beiden Essential-Versionen können sich sehen lassen (Abbildung 18.2). Zusätzlich zu den Merkmalen der ESXi-Version umfassen die Essential-Versionen den vCenter Agent und den Update Manager. Die Variante Essential Plus bietet darüber hinaus noch High Availability, vStorage-API und Data Recovery. Das ganze Essential-Paket ist in beiden Varianten für sechs Sockel ausgelegt.
1007
18.1
18
Die Lizenzierung von vSphere
Was die Erweiterung angeht, bietet VMware hier aktuell keine Möglichkeiten. Es kann zwar mittels Upgrade von Essential nach Essential Plus migriert werden, aber darüber hinaus ist aktuell keine Upgrade-Möglichkeit vorgesehen. Das heißt, zusätzliche Funktionalität über die im Essential Plus bereits enthaltenen Funktionen hinaus können nicht hinzugekauft werden. An dieser Stelle möchte ich unbedingt auf das am Anfang von Abschnitt 18.1 besprochene Thema zur Entscheidungsfindung verweisen.
18.1.3 vSphere4 – Standard, Advanced, Enterprise und Enterprise Plus Die vier Bundle-Varianten vSphere4 Standard, Advanced, Enterprise und Enterprise Plus haben keinerlei Beschränkungen; lizenztechnisch ist quasi alles möglich.
Abbildung 18.3
Die Merkmale des Enterprise-Paketes
Sofort fällt auf, dass lediglich bei Advanced und Enterprise Plus die Nutzung von mehr als sechs Kernen je CPU möglich ist. Die Standard-Lizenzierung enthält über die Merkmale der freien Version hinaus den vCenter Agent, den Update Manager, High Availability und vStorage-API.
1008
Die unterschiedlichen Pakete
Advanced-Lizenzierung umfasst zusätzlich Data Recovery, die Funktionalität VMotion, HotAdd, Fault-Tolerance und vShield Zones. Die Lizenz Enterprise stellt zusätzlich zur Advanced-Version Storage VMotion, den Distributed Resource Scheduler und Distributed Power Management bereit. Enterprise Plus ermöglicht darüber hinaus durch die Funktionalität von distributed Switches die Verwendung von Third-Party-Switches. Ein Merkmal, das sicherlich in größeren Umgebungen geschätzt wird, ist Host-Profiles. Diese Funktionalität ist ebenfalls in der Lizenzierungsvariante Enterprise Plus enthalten. Drei der vier Lizenzierungsvarianten, nämlich Standard, Advanced und Enterprise, sind bezogen auf den Hauptspeicherausbau limitiert. Hier liegt die Obergrenze bei 256 GB. Lediglich die Lizenzierungsvariante Enterprise Plus ist, was den Ausbau des Hauptspeichers angeht, unbeschränkt. Außerdem sind nur in dieser Lizenzierungsvariante virtuelle Acht-Wege-Maschinen nutzbar. Also auch hierbei hat VMware deutlich gemacht, dass es sich bei Enterprise Plus um ein Lizenzierungsmodell für größere Strukturen handelt. Die Lizenzierung geschieht auf Basis eines einzelnen Sockels. Das heißt, dass Sie beispielsweise für einen physischen Server, der mit vier Sockeln ausgerüstet ist, die alle mit CPUs bestückt sind, vier ESX-Server-Lizenzen benötigen. Beim vCenter Server gibt es nach wie vor zwei unterschiedliche Methoden der Lizenzierung. Zum einen gibt es die Variante der Limitierung auf drei Knoten, wobei hier die Größe der drei physischen Server nicht beschränkt ist. Setzen Sie zum Beispiel Acht-Sockel-Maschinen ein, die je Sockel und CPU sechs Kerne enthalten, kommen Sie bei der Lizenzierung bezüglich Foundation auf stolze 144 Kerne. Darüber hinaus besteht die Möglichkeit, eine unlimitierte Version zu erwerben, die dann auch noch das Merkmal Linked Mode enthält und den Einsatz des Orchestrators gestattet. Die auf drei Knoten limitierte Version wird, wie bereits erwähnt, als »Foundation« und die unlimitierte Version als »Standard« bezeichnet.
18.1.4 Erweiterung einer Umgebung durch Hinzufügen von Funktionalität Funktionserweiterungen sind auf die Versionen Standard, Advanced, Enterprise und Enterprise Plus anwendbar. Bei der Version Enterprise Plus kann das Merkmal »distributed vSwitch« zum jetzigen Zeitpunkt um den »Cisco Nexus 1000V« erweitert werden. Die Versionen Standard, Advanced und Enterprise lassen sich durch Upgrades in jede beliebige Version umwandeln. Das heißt, Sie können durchaus auch Versionsstufen überspringen. So ändern Sie zum Beispiel eine
1009
18.1
18
Die Lizenzierung von vSphere
Standard-Lizenz durch Upgrade direkt in eine Enterprise- oder sogar EnterprisePlus-Lizenz um.
18.2
Support und Subscription
Generell ist es nicht möglich, im Umfeld der hier betrachteten Produkte Lizenzen bei VMware zu erwerben, ohne auch Support und Subscription – womit der Abonnement-Service gemeint ist – mitzukaufen. Lediglich ausgelaufener Support und Subscription muss nicht nach Ablauf der Laufzeit nachgekauft werden. In der Praxis ist es aber durchaus sinnvoll, Support und Subscription bei Ende des Support- und Subscription-Vertrages zu erneuern. Selbst wenn im Unternehmen Störungen ohne die Nutzung von VMware-Support behoben werden, ist nicht immer gesagt, ob dies in Zukunft nicht doch einmal erforderlich sein wird. Diese Frage muss aber jeder Administrator für sich selbst entscheiden. Bei der Subscription liegt die Sache etwas anders. Subscription bedeutet, dass Sie neue Versionen oder Updates bei Neuerscheinung herunterladen können und einsetzen bzw. benutzen dürfen. VMware unterscheidet bei den Server-Produkten grundsätzlich zwischen zwei unterschiedlichen Arten von Support und Subscription, die Stufe Gold (demnächst auch als »Basic« bezeichnet) und die Stufe Platinum (künftig auch als »Production« bezeichnet). Bei den Laufzeiten für Support und Subscription können Sie zwischen einem, zwei und drei Jahren wählen. Falls Sie darüber hinaus größere Zeiträume für Support und Subscription wünschen, ist dies in der Regel auch möglich. Allerdings muss dies individuell angefragt werden. Für die Erreichbarkeit von VMware im Supportfall hier in Europa gilt für die Stufe Gold Montag bis Freitag in der Zeit von 7.00 Uhr bis 19.00 Uhr und für die Stufe Platinum 24 Stunden an sieben Tagen in der Woche und 365 Tagen im Jahr. Wenn Sie alle Einzelheiten zu Support und Subscription in Bezug auf die Stufen Gold und Platinum nachlesen möchten, empfehle ich das gold_datasheet_de.pdf (www.vmware.com/files/de/pdf/gold_datasheet_de.pdf) und das platinum_data sheet_de.pdf (www.vmware.com/files/de/pdf/platinum_datasheet_de.pdf) von VMware. Eine sehr interessante Variante aus dem Bereich Support stellt der geschäftskritische Support von VMware dar. Dieser Support ist für alle gedacht, die Mission Critical Environments betreiben. Er ist als Ergänzung zum bereits erläuterten Platinum-Support zu sehen. Bei dieser Art des Supports wird eine enge Beziehung zwischen dem Hersteller und dem Kunden hergestellt. So stehen dedizierte Ansprechpartner und vieles mehr zur Verfügung. Auch hier verweise ich auf das entsprechende Datenblatt von VMware: business_critical_datasheet_de.pdf (www.vmware.com/files/de/pdf/business_critical_datasheet_de.pdf).
1010
Support und Subscription
Eine ganz andere Art von Support – ohne enthaltene Subscription – steht mit dem Einzelfall-Support für ESXi und vSphere4 Essential zur Verfügung. Der Einzelfall-Support ermöglicht es, VMware-Support auf Einzelfallbasis zu erwerben. Hier können Sie drei unterschiedliche Einzelfall-Supportpakete für einen, drei oder fünf einzelne Supportfälle kaufen. Anfragen stellen und Antworten erhalten Sie wahlweise über das Internet oder telefonisch. Eine Einzelfall-Supportanfrage ist in der Zeit von Montag bis Freitag von 7.00 Uhr bis 19.00 Uhr möglich. Detailliertere Informationen erhalten Sie im Dokument per_incident_datasheet_de.pdf (www.vmware.com/files/de/pdf/per_incident_datasheet_de.pdf) von VMware. Sollte einmal Unklarheit darüber herrschen, ob ein vorhandenes VMware-Produkt noch unter Support ist, können Sie dies unter http://www.vmware.com/de/ support/tools/ überprüfen (Abbildung 18.4).
Abbildung 18.4
18.2.1
Überprüfung von Supportberechtigungen
Die unterschiedlichen Schweregrade
VMware bietet die Möglichkeit, die Schweregrade der Supportanfrage zu klassifizieren. Grundsätzlich werden vier Schweregrade unterschieden. Im Wesentlichen werden diese Auswahlmöglichkeiten angeboten, um die relativen Auswirkungen eines Problems auf die Systeme in einem Unternehmen zu erfassen. Die Einstufung eines Problems in den entsprechenden Schweregrad hat eine direkte Auswirkung auf die Reaktionsgeschwindigkeit des VMware-Support-Teams. 왘
Schweregrad 1 liegt vor, wenn die Produktions-Server oder andere unternehmenskritische Systeme ausgefallen sind und eine Behelfslösung nicht unmittelbar zur Verfügung steht, wenn für wesentliche Teile der unternehmenskritischen Daten ein erhebliches Verlust- oder Beschädigungsrisiko besteht, die Services in unannehmbarem Umfang ausgefallen sind oder gar der Geschäftsbetrieb in erheblichem Umfang unterbrochen wurde.
왘
Um Schweregrad 2 handelt es sich, wenn eine wichtige Funktion maßgeblich beeinträchtigt ist. In dieser Klassifikationsstufe kann der Betrieb mit Einschränkungen fortgesetzt werden, und eine vorübergehende Behelfslösung steht auch zur Verfügung.
1011
18.2
18
Die Lizenzierung von vSphere
왘
Schweregrad 3 wird angegeben, wenn die Supportanfrage sich auf Situationen mit zum Teil unkritischem Funktionsverlust der Software bezieht. Es liegen Beeinträchtigungen bestimmter Komponenten vor, und der Anwender kann die Software weiterhin nutzen.
왘
Unter Schweregrad 4 sind unkritische Probleme wie zum Beispiel ein Fehler in der Dokumentation oder Ähnliches zu verstehen. Dieser Schweregrad bezieht sich auf eher allgemeine Fragen, die keiner zeitnahen Reaktionen bedürfen.
18.2.2 Wie wird eine Supportanfrage bei VMware gestellt? Eine Anfrage beim VMware-Support stellen Sie telefonisch oder über die Website von VMware. Bevor Sie eine Supportanfrage stellen, ist es ratsam, bereits einige Informationen zu notieren, die normalerweise vom VMware-Supportmitarbeiter grundsätzlich angefordert werden: der Name des Anfragenden, der Name der Firma und die Telefonnummer, unter der der Anfragende erreichbar ist. Falls Sie wegen einer früheren Supportanfrage anrufen, sollten Sie die Referenznummer der früheren Supportanfrage kennen. Natürlich ist eine kurze Beschreibung des Problems erforderlich. Im Anschluss teilt der VMware-Supportmitarbeiter Ihnen eine Referenznummer mit. Diese Referenznummer bleibt so lange erhalten, bis die Supportanfrage vollständig beantwortet oder das Problem behoben wurde. Oftmals muss der Support weiterführende Informationen anfordern, um Probleme zu diagnostizieren und die Supportanfrage somit zügig bearbeiten zu können. Darum ist es unter Umständen extrem hilfreich, wenn die Umgebung gut dokumentiert ist. Diagramme und Dateien zur System-, Storage- und/oder Netzwerkkonfiguration sind für den Support bei der Problemerkennung und der damit verbundenen Problembehebung ausgesprochen hilfreich. Außerdem wird der Support nach Protokolldateien oder der Core-Datei (vm-support Diagnosedatei) fragen. An dieser Stelle sollten Sie gut mit Ihrem System vertraut sein, um dem Support die geforderten Informationen geben zu können. Die Reaktionszeit des VMware-Supports ist je nach Supportstufe unterschiedlich, wie Abbildung 18.6 zeigt.
1012
Support und Subscription
Abbildung 18.5
Erstellen der VMware-Support-Informationen
Abbildung 18.6
Reaktionszeit des VMware-Supports
Telefonische Supportanfrage Eine telefonische Eröffnung einer Supportanfrage stellen Sie in Deutschland unter 0800 1 00 67 11 oder 069 51 70 90 16. Für andere Länder stehen ebenfalls derartige Support-Rufnummern zur Verfügung. Sie finden sie unter dem Link http://www.vmware.com/de/support/phone_support.html. Der Telefonsupport wird hier in Deutschland ausschließlich innerhalb der Hauptgeschäftszeiten in Landessprache angeboten. Außerhalb der Hauptgeschäftszeiten erfolgt der Telefonsupport in englischer Sprache. Die Hauptgeschäftszeit innerhalb von Europa beginnt am Montag und endet am Freitag jeweils von 7.00 Uhr und bis 19.00 Uhr Ortszeit. Supportanfrage über die Website Die andere Art, eine Supportanfrage zu stellen, ist die Anfrage über das Internet. Zu diesem Zweck hat VMware die Adresse http://www.vmware.com/de/support eingerichtet. Der Link Support-Anfrage erstellen (Abbildung 18.7) führt Sie zum Ziel.
1013
18.2
18
Die Lizenzierung von vSphere
Abbildung 18.7
Der VMware-Internet-Support
Im nächsten Schritt loggen Sie sich mit Ihren Anmeldedaten ein und wählen in der Auswahl-Box Create a Support Request (Abbildung 18.8). Sollten Sie noch keine persönlichen Anmeldedaten besitzen, können Sie sich unter https:// www.vmware.com/account/customerRegistration.do? bei VMware registrieren. Nach Eingabe aller erforderlichen Anmeldedaten werden auf der nun folgenden Seite zwei mögliche Vorgehensweisen angezeigt (Abbildung 18.9).
1014
Support und Subscription
Abbildung 18.8
Eröffnung einer Supportanfrage über das Internet
Abbildung 18.9
Suchen in der Knowledge Base oder Eröffnung einer Supportanfrage
1015
18.2
18
Die Lizenzierung von vSphere
In Step 1 wird auf die Suche in der Knowledge Base verwiesen, und in Step 2 stellen Sie eine Supportanfrage. Durch Auswahl des Buttons File Support Request werden Sie zur Seite Support Entitlements weitergeleitet (Abbildung 18.10).
Abbildung 18.10
Support Entitlements
Auf dieser Seite können Sie den aktuellen Status des erworbenen Supports für alle Produkte bzw. Lizenzen einsehen. Der Status lautet Active (noch unter Sup-
1016
Support und Subscription
port) oder Expire (Support ist ausgelaufen). In der Spalte Supported Products / File SR stellen Sie durch Anklicken der einzelnen Links eine Supportanfrage bezogen auf das ausgewählte Produkt.
Abbildung 18.11
Supportanfrageformular
Abbildung 18.11 zeigt das Formular zur Supportanfrage. Nach dem Ausfüllen und Absenden dieses Formulars startet der Supportprozess, und je nach Art des Supports meldet sich ein Mitarbeiter des VMware-Support-Teams. Knowledge Base Eine weitere wichtige Informationsquelle, die so manche Supportanfrage überflüssig macht, ist die VMware Knowledge Base. Die VMware Knowledge Base ist über die Supportsite von VMware zu erreichen (Abbildung 18.12).
1017
18.2
18
Die Lizenzierung von vSphere
Abbildung 18.12
VMware-Support
Abbildung 18.13
VMware Knowledge Base
1018
Die vSphere 4-Lizenzen
Sie können die Dokumente, die in der Knowledge Base hinterlegt sind, durchsuchen und dadurch auf höchst effiziente Art und Weise an Informationen gelangen. Die Knowledge Base ist, wenn es nicht gerade um Support im Bereich von Schweregrad 1 oder 2 geht, eine durchaus geeignete Methode, sich selbst zu helfen. Hinzu kommen weitere Selbsthilfe-Tools wie Dokumentation, technische Ressourcen (http://www.vmware.com/de/support/pubs/) oder Diskussionsforen (http://www.vmware.com/de/community/) und Anwendergruppen (http:// www.vmware.com/de/vcommunity/usergroups.html). Ressourcen für Entwickler finden Sie unter http://www.vmware.com/de/support/developer/. Das Schließen einer Supportanfrage In der Regel wird eine Supportanfrage geschlossen, wenn der Anfragende bestätigt, dass eine Lösung erzielt wurde. Auch gilt eine Supportanfrage als geschlossen, wenn VMware nach drei Kontaktversuchen in einem Zeitraum von 10 Tagen keine Rückmeldung vom Anfragenden erhält. Es kann natürlich auch vorkommen, dass Supportanfragen aus bestimmten Gründen nicht gelöst werden können. In einem derartigen Fall wird die Supportanfrage dann ebenfalls geschlossen.
18.3
Die vSphere 4-Lizenzen
Die Version VMware vSphere läuft ohne Angabe einer Lizenz 60 Tage im Evaluierungsmodus, mit vollem Funktionsumfang. Besitzen Sie bereits Lizenzen oder haben Sie Lizenzen bestellt, sind diese im VMware-Lizenzportal jederzeit abrufbar. Das Lizenzportal finden Sie unter der URL http://www.vmware.com/support/licensing.html. Alternativ erreichen Sie sie über die VMware-Startseite unter Support 폷 Lizenzen anfordern und verwalten. Die Lizenzierung hat sich mit Einführung der Version 4 vollständig verändert. Eine Verwaltung der Lizenzen von früheren Versionen ist unter Server & Datacenter Products anwählbar. Sie finden den Zugang zu diesem Portal, indem Sie VMware Infrastructure 3 auswählen (Abbildung 18.14). Möchten Sie hingegen Ihre vSphere 4-Lizenzen sehen, wählen Sie an dieser Stelle VMware vSphere 4 aus.
1019
18.3
18
Die Lizenzierung von vSphere
Abbildung 18.14 Die Lizenzen für vSphere 4 bzw. die Vorgängerversion VI 3 sind getrennt anwählbar und in unterschiedlichen Portalen zu finden.
Der Umgang mit Lizenzschlüsseln Nach der Auswahl der Produktgruppe, in unserem Fall VMware vSphere 4 (Abbildung 18.14), gelangen Sie auf die Anmeldeseite (Abbildung 18.15). Haben Sie die richtige Benutzerkennung mit Passwort eingegeben, werden Sie in Ihren Lizenzbereich weitergeleitet. Hier werden Ihnen nun Ihre Lizenzen angezeigt (Abbildung 18.16), die Sie eingepflegt haben. Sollte einer Ihrer Kollegen auch VMware-Lizenzen aktiviert haben, dann muss er diese explizit für Sie freischalten, damit Sie die Lizenzen ebenfalls sehen können. Das Portal zeigt Ihnen nun eine Übersicht, welche Lizenzen Sie in welcher Menge zur Verfügung haben und entsprechend nutzen können (Abbildung 18.16). Für jedes Produkt, das Sie besitzen, können Sie sich nun die Eigenschaften der Lizenzen anzeigen lassen, indem Sie auf das Pluszeichen vor der eingetragenen Lizenz klicken. Zu den Eigenschaften zählen die Ordernummer, das Bestelldatum und natürlich auch die bestellte Menge. Die Lizenznummer gehört ebenso dazu wie die Angabe, ob die Lizenz noch unter Support ist.
1020
Die vSphere 4-Lizenzen
Abbildung 18.15
Anmeldeseite, die Ihnen den Zugang zu Ihrem Lizenzportal ermöglicht
Abbildung 18.16 Hier können Sie die Eigenschaften Ihrer vSphere-Lizenzen einsehen und verwalten.
1021
18.3
18
Die Lizenzierung von vSphere
Außerdem können Sie für Ihre Dokumentation hier auch einen Kommentar hinterlegen. Im Beispiel in Abbildung 18.17 wurde, wie in der Umrahmung zu erkennen ist, ein Kommentar beigefügt. Wenn der Kommentar eingetragen wurde, können Sie ihn mit Save speichern.
Abbildung 18.17
Ergänzende Informationen zur Lizenz hinzufügen
Bei der Anzahl der Lizenzen werden anfänglich Lizenzen für mehrere CPUs angezeigt. In unserem Beispiel steht im Portal ein Lizenzschlüssel für acht CPUs (Abbildung 18.18). Wenn Sie nun im vCenter diese Lizenz für einen Host einpflegen, der nur zwei CPUs besitzt, wäre eine derartige Vorgehensweise ineffizient.
Abbildung 18.18
Ungeteilter Lizenzschlüssel für acht CPU-Sockel
Damit der Host optimal lizenziert wird, können Sie im Portal zuvor einen neuen Lizenz-Key für eine Zwei-Prozessor-Maschine erstellen. Dazu teilen Sie die Lizenz über Divide einfach in vier Zwei-Prozessor-Lizenzen (Abbildung 18.19 und Abbildung 18.20) oder eine Zwei-Prozessor- und eine Sechs-Prozessor-Lizenz auf.
Abbildung 18.19
1022
Aufsplittung einer Acht-Prozessor-Lizenz in vier Zwei-Prozessor-Lizenzen
Die vSphere 4-Lizenzen
Ersetzen Sie den Host mit den zwei Prozessoren nun durch einen mit z. B. vier Prozessoren, ist es notwendig, eine zur Hardwareausstattung des Hosts passende Lizenz zu erzeugen.
Abbildung 18.20 Aufsplittung
Vier Lizenzschlüssel für je zwei CPUs respektive Sockeln nach der
Sie benötigen also eine Vier-Prozessor-Lizenz. Dazu setzen Sie nun zwei ZweiProzessor-Lizenzen mittels der Funktion combine zu einer Vier-Prozessor-Lizenz zusammen (Abbildung 18.21).
Abbildung 18.21 Zusammenführung von zwei Zwei-Prozessor-Lizenzen zu einer VierProzessor-Lizenz
Hierbei legen Sie durch Anklicken der entsprechenden Checkbox die zu migrierenden Zwei-Prozessor-Lizenzen fest (Abbildung 18.21). Im Anschluss daran sind im Portal dann nur noch drei Lizenzschlüssel zu sehen: eine Vier-ProzessorLizenz und zwei Zwei-Prozessor-Lizenzen, was zusammen acht Prozessorlizenzen ergibt. Den erzeugten Vier-Prozessor-Lizenz-Key tragen Sie einfach in den vCenter-Server ein, und schon können Sie den Host oder das vCenter selbst lizenztechnisch aktivieren. Die Historie der Lizenz-Keys Selbstverständlich bietet VMware auch eine Historie der Lizenz-Keys an. Des Weiteren können Sie den Orderstatus aufrufen, Lizenzen downgraden oder ein Upgrade bestellen. Das gesamte Handling für die Lizenzen geschieht sehr anwenderfreundlich und transparent in diesem Portal.
1023
18.3
18
Die Lizenzierung von vSphere
Abbildung 18.22
18.4
Die Historie der Lizenzschlüssel und des Orderstatus
Die VI 3-Lizenzierung
Wenn Sie weiterhin ESX 3.x-Host-Systeme mit vCenter 4 verwalten möchten, kommen Sie an der Nutzung des »alten Lizenz-Servers« und der Anpassung des vCenters 4 zu dessen Nutzung nicht vorbei. Daher wird im Folgenden die Informationen zur VI 3-Lizenzierung erläutert.
Abbildung 18.23
Umschaltung auf VI 3-Lizenzierung
Lizenzdateien ansehen, anlegen, verändern und abrufen Nach der Anmeldung mit dem Portal-Account, dem die Lizenzen zugeordnet sind, erscheint die Ansicht über alle verfügbaren und bereits aktivierten Lizenzen. Die VMware Lizenzen sind modular in Komponenten aufgeteilt (Abbildung 18.24). Im Falle eines Verlustes einer Lizenzdatei können Sie jederzeit im VMwareLizenzportal eine neue erstellen (Abbildung 18.25) und sich diese entweder per E-Mail zusenden lassen oder direkt herunterladen. Dies gilt natürlich auch für den Fall, dass die vorhandenen Lizenzdateien nicht korrekt angelegt sind oder aus dem einen oder anderen Grund verändert werden müssen.
1024
Die VI 3-Lizenzierung
Abbildung 18.24
Übersicht über die verfügbaren und aktiven VI 3-Lizenzen
Abbildung 18.25
Erstellung einer Lizenz
Es kann natürlich auch vorkommen, dass die Art der Lizenzdatei verändert werden muss. Nach einem Klick auf Generate New License File zur Neuerstellung einer Lizenz wird nach dem Lizenzmodell gefragt (Abbildung 18.26). Es gibt grundsätzlich zwei Arten von Lizenzdateien im Lizenzmodell von VI 3: die Server- und die Host-based Lizenzierung. Bei der Server-based Lizenzierung wird die Umgebung unter Einbeziehung des VMware-Lizenz-Servers lizenziert. Bei der Host-based Methode lizenzieren Sie einen oder mehrere Hosts direkt ohne Nutzung des Lizenz-Servers. Hierbei wird die Lizenzdatei direkt an den Host gebunden bzw. importiert.
1025
18.4
18
Die Lizenzierung von vSphere
Abbildung 18.26
Das VI 3-Lizenzmodell
Wie Sie in Abbildung 18.27 erkennen, gibt es drei unterschiedliche Spalten. Unterschieden wird nach insgesamt gekauften (1), bereits aktivierten (2) und noch verfügbaren (3) Lizenzen. Die letztgenannte Spalte zeigt an, in welcher Menge Lizenzen noch zur Benutzung zur Verfügung stehen oder nicht in Benutzung sind. Aktivieren Sie verfügbare Lizenzen, werden diese unter 3 abgezogen und dann unter 2 gutgeschrieben. 1 2 3
Abbildung 18.27
Es sind keine aktiven Lizenzen verfügbar.
Benötigen Sie eine Lizenzdatei nicht mehr, können Sie sie unter My License Files mittels Delete löschen (Abbildung 18.28). Das bedeutet aber nicht, dass sie tatsächlich gelöscht wird. Vielmehr wird sie lediglich innerhalb der Portalverwaltung verschoben. Das Delete bewirkt eine Verschiebung von Activated nach Available.
Abbildung 18.28
1026
Löschen einer bereits erzeugten Lizenzdatei
Die VI 3-Lizenzierung
Im Anschluss daran können Sie diese Lizenz wieder zur Generierung eines neuen Lizenz-Files benutzen.
Abbildung 18.29
Erstellung einer neuen Lizenzdatei inklusive Kommentar
Nach optionaler Angabe eines Kommentars (Abbildung 18.29) können Sie eine Lizenzdatei herunterladen oder per E-Mail weiterleiten (Abbildung 18.30). Letzteres ist natürlich für Berater interessant, die so im Auftrag des Kunden vor der Installation bereits alles vorbereiten können.
Abbildung 18.30
Versenden oder Herunterladen des Lizenz-Files
Leider existiert keine Möglichkeit, innerhalb des Lizenzportals ein Benutzerkonto für mehrere Personen freizugeben.
1027
18.4
18
Die Lizenzierung von vSphere
Lizenzdateien – Lizenz-Server Eine Lizenzdatei hat immer einen bestimmten Aufbau, und Sie können mehrere Lizenzdateien miteinander kombinieren. Die Kombination der Lizenzen erfolgt entweder über das Portal oder auch manuell. Aufbau der Lizenzdatei SERVER this_host ANY 27000 VENDOR VMWARELM port=27010 USE_SERVER INCREMENT PROD_VC VMWARELM 2005.05 permanent 1 \ VENDOR_STRING=licenseType=Server ISSUED=19-Dec-2006 \ NOTICE=FulfillmentId=214114 SIGN=" "
Die ersten drei Zeilen einer Lizenzdatei dienen der Zuordnung durch den LizenzServer. Erst danach folgen die eigentlichen Lizenzschlüssel, mit denen die Funktionen freigeschaltet werden können. Möchten Sie mehrere Lizenzdateien kombinieren, müssen diese ersten Zeilen am Anfang der Datei lediglich ein einziges Mal vorkommen. Alle weiteren mit INCREMENT beginnenden Teile dürfen Sie aus mehreren Dateien zusammenkopieren. Sehen Sie sich die Zeile beginnend mit dem Wort INCREMENT näher an, können Sie das Produkt (PROD_VC; vCenter Server), die Gültigkeit (permanent), das Erstellungsdatum (19-Dec-2006) und den Lizenztyp (licenseType=Server) Serverbased auslesen. Die Zeile VENDOR_STRING kann die unterschiedlichsten Zusatzinformationen enthalten oder aus einer Lizenz eine bestimmte Funktion entfernen. Außerdem ist die Zahl hinter der Gültigkeit (permanent) sehr wichtig, da sie die Anzahl der Lizenzen dieses Typs beschreibt. Im vorliegenden Fall handelt es sich um eine Lizenz. Werden beispielsweise 20 ESX-Server-Sockel lizenziert, wäre hier die Zahl 20 an Stelle der 1 zu finden. Folgende Produktlizenzentypen werden derzeit verwendet: Produktlizenz
String
Virtual Center Server
PROD_VC
ESX Server Starter
PROD_ESX_STARTER
ESX Server Standard
PROD_ESX_FULL
VMware Consolidated Backup
ESX_FULL_BACKUP
Virtual Center Agent VMware ESX
VC_ESXHOST
Tabelle 18.1
1028
Lizenztypen
Die VI 3-Lizenzierung
Produktlizenz
String
VMware VMotion
VC_VMOTION
VMware High Availability
VC_DAS
VMware DRS
VC_DRS
Tabelle 18.1
Lizenztypen (Forts.)
Alle Lizenzdateien werden im Programmverzeichnis des VMware Lizenz-Servers (%programfiles%\VMware\VMwareLicense Server\Licenses) abgelegt. In der aktuellen Version 3.5 können mehrere Dateien problemlos im gleichen Verzeichnis gespeichert werden. Der Lizenz-Server-Dienst liest diese entsprechend aus.
1029
18.4
Die Autoren Günter Baumgart Günter Baumgart ist seit 1990 im Bereich Softwareentwicklung und Engineering von IT-Systemen tätig. Er ist bei der Firma Consultico GmbH verantwortlicher Director für den Bereich Konzeption und Planung sowie für die anschließende Umsetzung virtueller Infrastrukturen.
Oliver Kügow Oliver Kügow ist Gründer und Geschäftsführer der team(ix) GmbH aus Nürnberg. Die Firma wurde 2001 gegründet und ist auf IT Infrastruktur-Lösungen spezialisiert, insbesondere auf NetApp, VMware und Open-Source-Software. Oliver Kügow ist zertifizierter Trainer für NetApp und hält auch Schulungen im VMware ESX Umfeld.
Carsten Schäfer Carsten Schäfer arbeitet seit 1990 in der IT-Branche. Als Inhaber der G-TAC IT-Beratung berät er Kunden zu den Themen Windows-Architektur, Active Directory, VMware und Hyper-V. Darüber hinaus entwickelt er im Kundenauftrag Individual-Software. Seit 2009 ist er geschäftsführender Gesellschafter der G-TAC Software UG, die sich auf Software-Lösungen im Bereich der Virtualisierung und der Betriebsautomatisierung sowie auf Administrations-Tools spezialisiert hat.
1031
Die Autoren
Sebastian Wischer Mit einer Ausbildung bei Siemens in Paderborn begann für Sebastian Wischer im Jahr 1999 der Einstieg in die IT. Nach Erfahrungen in der Produkteinführung und im Support wechselte er zur team(ix). Dort ist er als Consultant im Bereich der Infrastrukturlösungen im Einsatz. Häufig hat er es dabei mit einer Kombination aus den Produkten von VMware, NetApp und Fujitsu zu tun. Bei der Firma qSkills in Nürnberg vermittelt er regelmäßig seine Erfahrungen in Workshops und Schulungen. Bertram Wöhrmann Mit der Programmierung einer Teleskopsteuerung für ein optisches Teleskop auf La Silla in Chile begann der berufliche Einstieg von Bertram Wöhrmann. Über das Design, den Aufbau und die Administration von Windows-Systemen und -Netzwerken ist er vor ca. 5 Jahren mit dem Thema Virtualisierung in Kontakt gekommen. Bei seinem derzeitigen Arbeitgeber, einem Tochterunternehmen der Siemens AG, ist er momentan mit dem Aufbau, der Pflege und der Weiterentwicklung von virtuellen Infrastrukturen betraut. Das bildet – neben der Evaluierung und Einführung neuer Technologien im Rechenzentrum – seinen derzeitigen Arbeitsschwerpunkt. Dennis Zimmer Dennis Zimmer arbeitet als Chief Technology Officer bei dem Schweizer Unternehmen icomasoft AG, das er Mitte 2008 gemeinsam mit seinem Geschäftspartner Diego Boscardin (CEO) gegründet hat. Die icomasoft AG hat sich auf Softwarelösungen im Bereich der Virtualisierung und Rechenzentrumsverwaltung spezialisiert.
1032
Index .ovf-Datei 354 /etc /hosts.allow 880 /hosts.deny 880 /pam.d/su 874 /pam.d/system-auth 883 /securetty 875 /ssh/sshd_config 876 /sudoers 873 /syslog.conf 897 /vmware/firewall/services.xml 891 /vmware/ssl 894 /etc/exports 482 /etc/multipath.conf 563 /opt/vmware/aam/bin/Cli 141 /root /.ssh/authorized_keys 878 /sbin/nologin 875 /snmpd.conf 612 /var/log /messages 873 /secure 873 3PAR 523 InForm Management Console 525 InServ T400 527 64-Bit ODBC 230 802.1q-Trunk 314
A Acceleration-Kit 1006 Access 227 Account 650, 932 Read-only 223 Active Directory 302, 610, 881, 925 active/passive-Team 329 ActivePerl 306 ADAM-Instanz 984 AD-Controller 609 Add Role 645 AD-Integration 302 Administration 946 Administrator lokaler 255 Administratorengruppe 651
Admission Control 128 Advanced Edition 51 Advanced Single-Instance Storage 504 Advanced-CPU-Funktion 121 Advanced-Modus 188 Agenten 920, 951 Aggregation 924 aktiv/aktiv-Cluster 455 Alarm 676, 935, 938, 939 Aktion 679 Definitions 676 Reporting 678 Trigger 678 Alarmierung 676 Alarmtyp 489 alicreate 458 Allowed Host Failures 125 AllowUsers 880 Alternate Boot Device 203 ALUA 462, 540, 573 AMD Nested Page Tables 102 AMD PCnet32 358 AMD Tagged TLB 102 AMD-Opteron-Generation 123 AMD-V 166 AMS 2000 534 Anaconda 183 Analysierendes Environment 920 Analytical Engine 924 Analyze 938 Anmeldeinformationen 926 Anmeldung 289 Anomalien 935, 939 anonymisiert 928 AoE 531 Application Profile 940 Application Snapshot Director 590, 595 Applikationskonsistenz 841 AppSpeed Probes 979 Arbeitsspeicher auslagern 639 Archiv 969 ARP-Paket 337 A-SIS 504 ASM/VE 566 Asset Information 933
1033
Index
Assign Role 303 asymmetric active/active 540, 573 Asynchronous LUN Access 462 ATA over Ethernet 531 Auffinden der Zielsysteme 925 Ausfall des Gastbetriebssystems 123 Ausfallsicherheit 194 transparente 575 Ausfallsicherungsmechanismen 275 Auslagerungsdatei 102 Auslastung eines Servers 918 Außerbetriebnahme 953 Auswertungsdaten 669 authorized_keys 878 auto-detect method 927 Automated Availability Manager 135 Automation level fully automated 155 partially automated 155 Automatisierte Ausführung von Jobs 929 Automatisierungsgrad eines DRS-Clusters 154 Automounter 262 Auto-Snapshot Manager für VMware 566 Average Bandwith 338 Axiom 568
B Backup differentielles 838 inkrementelles 838 Backup- und Disaster-Recovery 36 Backup-Appliance 279, 280 Backup-Daten 273 Backup-Datenstrom 839 Backup-Rechenzentrum 996 Backup-Strategie 831 Baseline 683, 693 Create 694 Dynamic 695 Fixed 695 für Hostsysteme 214 Status 699 Baseline-Gruppe 683, 697 Basisinstallation 184 BCE (Basic Consolidation Estimate) 954 Beacon Probing 336 Beaconing 337
1034
Beacon-Paket 336 Belastung 936, 940 Belastungsdaten 941 Belastungsprofil 924 Benachrichtigung per Mailserver 726 Benchmark 938 Benchmarking 924 Benutzer 288, 932 einrichten 647 exklusiver 233 Benutzer-Account 643 Benutzerdatenbank 647 Benutzerrolle 645 Benutzerschnittstelle 923 Benutzerverwaltung 881 Berechnungsgrundlage 976 Berechtigungen 643 Gruppe 651 Berechtigungsstruktur 234 Berechtigungssystem 643 Bereitstellungsreihenfolge 864 Berichte 943 Betriebsaufgaben 651 Betriebssysteme 951 Betriebsunterbrechung 959 Bibliothek 968 BIOS 182 Blade-PC 989 Blocksize 469 Boot Options 776 Boot-Environment 192 Bootmenü 217 Boot-on-iSCSI 200 Boot-on-SAN 194, 197 Brandabschnitt 335 Brick 568 Broadcom 317 Brocade 456 Browse Datastore 488 Bundle 1005 Burst Size 338 Business Continuity Volume 582 Business Hours 937, 940 BusLogic Parallel 754
C Cache 500 Capacity Planner Data Managers 917
Index
Capacity-Planner-Frameworks 925 CDP 319 CD-ROM-/DVD-Laufwerk 753 Celerra 532 cfgcreate 457, 458 cfgenable 458 cfgshow 458 chage 885 Channel 271, 735 Channel Heartbeat 735 Channel-Netzwerk Datenmenge 735 Chart Options 654 Checksumme 179 chgrp 874 Child-Resource-Pool 147 chkconfig 606, 613, 894 chmod 874 CIFS 454, 569, 745 Cisco Discovery Protocol 316, 349 Hot Standby Router Protocol 132 Nexus 311 Nexus 1000V 1009 Nexus 1000v 352 Switch 318 Cisco-IOS 352 CLARiiON 532 CLI-Befehle 305 Client-Device 718 Client-Komponente 254 Client-LAN 329 Client-Tools 246 Client-Virtualisierungs-Plattform 985, 994 Clone 805, 809 Clone to Template 807 Cluster 119, 298, 854 Administrator 861 Gruppe 266 Knoten 861 Konfiguration 856 Landschaft 854 Name 861 Produkte 151 Service 862 Typ 865 Verbund 862 Cluster-aware 124
cluster-fähig 264 Clustering 275 Cold Migration 89 Cold Standby 263 Collection-Jobs 923 Collector-Interface 973 Collector-Modul 922 combine 1023 Command-Line Interface 304 Community 350 Company-ID 931, 949 Company-ID-Request 949 Compare Servers 941 Compliance-Check 699 compliant 697 Connection Manager 237 Consolidated Backup 173 Consolidation 34 Contact Info Sheets 947 Continuous Data Protection 582, 590 Continuous High Availability 165 Control LAN 354 Control Plane 341 Controller-Cache 545 Convert to Template 807 CoRAID 531 Core Four 34 CP-Admin 964 CPU Generationen 98 Identification Mask 774 Identification Utility 94 CPU Ready 656 CPU/MMU Virtualization 778 CPU-Affinity 782 CPU-Generationen, unterschiedliche 120 CPUID Mask 96 CPU-Kompatibilität 94 CPU-Limit 781 CPU-Masking 94 CPU-Reservation 782 CPU-Ressourcen 780 CPU-Shares 781 CPU-Statistik 928 Crash-consistent 841 Create a Support Request 1014 Crontab 607 Current Failover Capacity 139 Custom Drivers 185
1035
Index
Custom Port 890 CVP 985, 994
D das.allowNetwork 132 das.isolationaddress 131 Dashboard 924, 932, 946, 954, 964 Data Analyzer 924 Data Collector 920 Data Mover 109 Data Recovery 742, 1009 Lock 749 Mark for Delete 749 Restore 748 Restore Rehearsal 749 zeitliche Einschränkungen 746 Data Recovery Client 744 Destinations 745 Data Warehouse 954 Database ID 946 Database Retention Policy 673 Database-ID 931 Datacenter 298 Data-Collector-System-ID 931 DataCore 577 DataCore Storage Domain 577 Data-Manager-Modul 923 Data-Recovery-Appliance 852 Data-Recovery-Plug-in 853 Datastore 285, 470 Assign a new signature 496 Browse 488 expand 490 extend 490 Extent 491 überbuchen 490 Datastore-Browser 488 Datastores-View 486, 487 Datastore-UUID 105 Dateisystemblock 519 Datenaufkommen 224, 279 Datenbank 833 Datenbankagent 835 Datenbankschnittstelle 231 Datenbank-Server 224 Datenbanksicherung 835 Datenbanksoftware 229 Datenbanksystem 297
1036
Datenbankverbindung 673 Datenbankwachstum 224 Datendeduplizierung 594 Datendurchsatz 499 Datengewinnung bei Unix und Linux Methoden 926 Datenkollektoren 921 Datenkonzentration 839 Datenquelle 229 Datenquellenname 232 Datensicherheit 836 Datensicherung 746, 831 Richtlinien 833 Datensicherungs-Client 832 Datensicherungsdatenstrom 836 Datensicherungslösung 279 Datensicherungsstrom 279 Datensynchronisation 924, 928, 931 Datensynchronisationsfunktion 930 Datensynchronisationsmodule 923 Deduplication 574 Deduplizierung 279, 485, 504, 505, 745, 852 Deduplizierungs-Storage 749 Delay-Zeit 627 Delete a Snapshot 820 Dell EqualLogic PS-Serie 544 Dell EqualLogic-Array 550 Denial-of-Service-Attacke 101 Deploy OVF Template 354 Desasterfall 1001 Desasterschutz 840 Desktop individueller 987 Desktop-Firewalls 950 Desktop-Pool nicht-persistent 988 persistent 988 Device-specific Modules 560 Device-Treiber 717 devmgr_show_nonpresent_devices 719 df -h 481 Diagnosedatei 1012 Diagnoselauf 279 Diagrammoption 653 Dienst 288, 917, 949 anzeigen 667 Direct-attached Storage 453, 585 Disable Fault Tolerance 173
Index
Discovery-Task 928 Diskettenlaufwerk 752 Disk-Ressourcen 787 Disk-Shelf 500 Distributed Power Management 45, 161, 1009 Distributed Resource Scheduler 45, 47, 1009 distributed vSwitch 311, 340, 1009 DMX 533 DMZ 872 DNS 615 Namensauflösung 615 DNS-Name 299 Domain-Zugehörigkeit 934 Domänen-Account 302, 861 Domänenbenutzer 298 Double Protection 571 Download Manager 251 downloadConfig.xml 689 Drittherstellersoftware 286 DRS 119 Affinity Rules 154 Automatisierungsstufen 152 Berechnungsprozess 153 Virtual Machine Options 158 DRS-Affinity-Rules 157 DRS-Cluster overcommitted 147 DRS-Empfehlungen 152 DRS-Konfiguration 125 DRS-Limitierungen 161 DRS-Prioritäten 154 Durchschnittswerte 935 dvPortGroup 342 DVS 45 dvSwitch 342 migrieren auf 347 Dynamic Provisioning 538
E eagerzeroedthick 114 eagerzeroedthick-Format 529 Editor 287 Einzelfall-Support 1011 elxvmwarecorekit 195 E-Mail 945 E-Mail-Report 845 EMC 532
Employee-owned IT 993 Enable Host Monitoring 127 Enable VM Monitoring 148 Endsystemgruppe 320 Enhanced VMotion Compatibility 97 Enhanced VMotion Compatibility Mode 120 Enterasys 319 Enterprise Edition 52 Enterprise Plus 352 Enterprise Plus Edition 53 Enterprise Summary 933 Environment-Variable 719 EOIT 993 Ereignisse Export 662 Ergebnis 958 Ergebnisbesprechung 947 Erweiterte Konfiguration 638 Essential Edition 50 Essential Plus 1007 Essential Plus Edition 51 Essential-Paket 1007 Estimator Reports 943 esxcfg advcfg 898 auth 881 firewall 889 esxcfg-firewall 199, 628 esxcfg-nics 104 esxcfg-vmknic 473 esxcfg-vmknic -l 553 esxcfg-volume 496 esxcfg-vswitch 318, 472 esxcli 527 esxcli swiscsi 478 ESX-Hosts 963 ESXi 322 embedded 216 installable 216 ESXi Server 1006 esxtop 334, 829 etc:hosts.allow 880 etc:hosts.deny 880 etc:pam.d/su 874 etc:pam.d/system-auth 883 etc:securetty 875 etc:ssh/sshd_config 876 etc:sudoers 873
1037
Index
etc:syslog.conf 897 etc:vmware/firewall/service 891 etc:vmware/ssl 894 Etherchannel 327, 333, 364, 484 Ethernet Flow Control 588 Ethernet-Frame 328 Evaluation 242 EVC-Cluster 97, 121 Event 612, 661 Export 662 Excel 225 Excel-Sheet 253 Explicit Failover 334 Export 304 exportfs 482
F Fabric 455 Failback-Plug-in 592 Failover 267, 334, 348, 484, 580, 737 failover host 129 Failover-Aktivitäten 146 Failure Interval 868 FalconStor 590 HyperTrac 594 Fast!UTIL 202 Fault Tolerance Logging 169 Fault-Tolerance 46, 119, 164, 366, 856, 869, 1009 FC-/iSCSI-Datastore 486 FCoE 573 FCP Partner Path 461 fcp show initiator 461 Fehleranalyse 639 Fehlfunktion 869 Festplatte 2gbsparse 414 monolithic flat 414 monolithic sparse 414 Physical compatibility 415 Virtual compatibility 415 Festplattentyp 855 Flat 713 Thin 713 Fibre Channel NPIV 776 Fibre Channel SAN Configuration Guide 523 Fibre-Channel 180, 365, 453
1038
Fibre-Channel over Ethernet 454 File Level Restore 853 File-Clone 498 File-Interface Deduplication System 590 Filer 454 Firewall 627 Einstellungen 887 Port öffnen 628 schließen 628 Startverhalten 630 Firmware 181 five nines 959 FlexClone 496, 847 flexible Volume 485 FlexVol 497 Forecast Alerts 940 Forecast Critical Processors 935 Forged Transmit 340 Formatierung 191 Foundation 1007 FQDN 256 FQDN-Namen 146 Fractional Reserve 510 freie Ressourcen innerhalb des Clusters 161 Freischaltung Port 628 Fremdherstellertool 702 FT sekundäre VM 172 FT-Lizenz 168 FT-Loggings 168 Full Backup 839 Full file Backup 838
G Gantt-Diagramm 948 Gastbetriebssystem anpassen 809 Gateway 616 Generate New License File 1025 Gigabit-Ethernet 316 Gold-Support 1010 Grafted from ESXHost 154 Grid-Architektur 585 Grid-Broker 545 Größenberechnung 224 Grundmetrik 669 Guest Customization Wizard 809
Index
Guest Operating System Installation Guide 177 GUI 289
H HA 119 Advanced Options 130 Agent 135, 140 Cluster 144 Failover 139 Failover-Capacity 128 Knoten 137 Regeln 140 HA/DRS-Kombination 164 Hardware vereinheitlichen 36 virtuelle 700, 751, 767 Hardware Compatibility Guides 175 Hardware-Initiator 548 Hardwareversion 711, 856 Hardwarevirtualisierung 166 Hauptadministrator 932 Hauptleistungsindikatoren 937 Hauptspeicher-Checkpoint 90 HBA-Controller 192 HBAnyware 195, 198 HDS 534 Adaptable Modular Storage 534 Storage Navigator Modular 534 Universal Storage Platform 534 Health Status 293, 667 Hearbeat-Netzwerk Datenmenge 735 Heartbeat 867 Interval 736 Netzwerk 269 Pakete 127 Traffic 858 Hersteller-Benchmarks 938 Hersteller-ID 361 High Availability 씮 HA Hitachi 534 Hitachi TrueCopy 538 Hochverfügbarkeit 89, 262 Home-Verzeichnis 112 Host Failure Detection 143 failures cluster tolerates 129
Host (Forts.) Integration Toolkit 560 Isolation response 134 Isolation Timing 143 standardisieren 214 Update Utility 208, 246 Utilities 512 Host-based Lizenzierung 1025 Host-Bus-Adapter 180, 194 hostd 92 Host-only vSwitch 315 Host-Profile 48, 351, 599, 832, 1009 assoziieren 603 Editiermodus 602 erstellen 600, 601 exportieren 601 importieren 600, 601 Konfigurationscheck 604 Konformität 600 nicht compliant 604 verknüpfen 600 verteilen 600 zuweisen 604 Host-Ressourcen 974 Host-Systemressourcen CPU-Reservierung 640 Hot Migration 89 Hot Standby 267 HotAdd 792, 1009 HotPlug 775 Hot-Spare 569 HP Enterprise Virtual Array 540 HP iLO 162 HP Modular Smart Array 539 HP XP 543 HPs MC/ServiceGuard 124 Hyperthreading 782, 937 Hypervisor 325, 640 Typ 1 38 Typ 2 38
I I/O Compatibility Guide 177 I/O Plane 341 IBM 543 id_rsa 879 Idle-Zyklus 609 IEEE802.3 ad 333
1039
Index
igroup create 474 igroup show 461, 474 Image 702 Import 254 Indikatoren 936 Industriedurchschnittswerte 935 Infiniband 316 Information Warehouse 920, 930, 931, 935, 941, 950 InForm-Verwaltungskonsole 524 initial Workshop 947 Initiator-Group 460 Inkonsistenz 835 Installations-Appliance 831 Installationshilfe 269 Installationsmodus 188 Installationsoptionen 239 Installationstools 192 Installationszustand 934 Integrität 929 INTEL VT 166 Intel-e1000-Adapter 359 Intelligent Platform Management Interface 667 Interim Report 943 Inv 929 Inventarisierung 924, 930 Inventarisierungs- und Performance-Daten 921 Inventarisierungsdaten 931, 933 Inventarisierungs-Task 927 Inventory 290 IOPS 499 IP-Einstellungen 744 IP-Hash 334, 335, 372, 484 IPMI 667 IP-Port 250, 253 IP-Ranges 925 IPStor 590 IP-Storage 317 IPv6-Checksum 359 iqlremote 205 IQN 473, 554 iSCSI 180, 453, 471 Ausfallsicherheit 477 iSCSI Qualified Name 473 iSCSI SAN Configuration Guide 523 iscsi start 473 iscsi_vmk 553
1040
iSCSI-Load-Balancing 479 iSCSI-Protokoll 548 iSCSI-Session 557 iSCSI-Storage 370 iSCSI-Target 331, 557 ISO-File 212 Isolated 350 Isolation Response 144
J Job History 947 Job-Planer 923 Jumbo-Frame 359, 472, 588
K Kapazitätsmessung 950 Kapazitätsplanungsprojekt 932, 947, 948 Katastrophenfall 996 Keep Virtual Machines Together 158 Kennwortänderung 232, 235 Kerberos 887 K-Fall-Handbuch 996 Kickstart 183 Klimabedarf 866 Knowledge Base 1016, 1017 Kollektierung 951 Kommandozeile 289, 303, 306 Kommunikationszone 457 Kompatibilitätsliste 176, 226 Kompatibilitätsmatrix 228 Kompatibilitätsprobleme 246 Konfigurations-File 838 Konfigurationsmenü 196 Konfigurationsschritte 298 Konsistenz 844 Konsole 287 Konsolidierung 35, 939, 962 Konsolidierungsratio 962 Konsolidierungsszenario 944, 955 Kontextmenü 259 Kontrollerknoten 527 Konvertierung 705 Korrelation 958 Kostenanalyse 975 ks-first.cfg 184 ks-first-safe.cfg 183
Index
L LACP 327, 333, 371, 484 LAN-Frame 472 LAN-free 837 LAN-Manager 925 Lastausgleich 946 Lastspitze 839 Laufwerk gemeinsam genutzt (shared) 264 LCM 971 LDAP 886 LeftHand Networks 585 Leistungs- und Inventarisierungsdaten 953 Leistungsaufnahme 962 Leistungsdaten 931, 932 Bericht 928 Ermittlung 928, 930 Messung 930 Leistungsindikatoren 653, 935 Leistungswerte 936 Levelling 527 license add 481 Licensed Features 295 Lichtwellenleiter 335 Link State only 336 Linkabbruch 329 Linked Clone 522 Linked Mode 243, 719, 1009 Linux 286, 611, 928 Linux-Befehle 289 Live-Migrationsfunktion 89 Lizenz Asset-Satz 632 einpflegen 632 Server Diags 635 Lizenzbereich 1020 Lizenzdatei 635, 1024 Lizenzierungsmodelle 1005 Lizenz-Key 631, 1023 Lizenzmanager 632 Lizenzportal 277 Lizenzschlüssel 1020, 1028 Lizenz-Server 240, 258, 631 DNS 637 integrierter 276 Umzug 638 Load Balance Collectors 946
Load-Balancing 326, 330, 334, 462, 484 IP-based 333 Lockdown-Mode 219 Locking-Mechanismus 479 Log on as a service 243 Log-Datei 287, 760 Log-File 929 Log-Level 304, 672 Long Distance VMotion 106 lpfcutil 195 LSI Logic Parallel 754 LSI Logic SAS 754 LUN 194 Alignment 519 Clone 493, 846 ID 468 Kapazität maximieren 469 Queue Length 460 Space Reservation 509 vergrößern 491 lun clone create 494 lun create 459, 474 lun map 462, 476 LVM.Resignature 496
M MAC-Adresse 333, 339, 360 manuelle 361 statisch 794 Zuordnung 314 Mail-Einträge 670 Maintenance-Mode 146 Maintenance-Modus 119, 210, 699 Manage existing virtual adapters 346 Managed Service 984 Management Information Base 612 Management-Appliance 222, 306 Management-Homepage vCenter 631 Management-Interface 286 Managementnetz 186 Management-Server 263 Managementumgebung 207 Manuelle Inventarisierung 927 Manuelle Leistungsdatenermittlung 928 Mapping 460 Maps 661 Maschinentyp 703
1041
Index
Masking 460 Mastermaschine 267 Master-Server geclonter 268 Maximum resets time window 868 mbralign 521 mbrscan 521 MD5 179 Mega-LUN 536 Meilensteine 947 Memory 638 Auslastung 928 Limit 784 Overcommitment 639, 657 Reservation 784 Ressourcen 783 Shares 783 Merkmale des Ziel-Servers 927 Message-Box 929 Messung 921 Messwerte 924, 935 Messwerterfassung 930 Messzeitraum 937, 951 Messzyklen 951 Metadaten Schreibzugriff 481 mgmt-vmware 894 MIB 612 Microsoft Cluster 264 Cluster-Lösung 124 NLB-Verbund 158 SQL 2005 Express 297 SQL Server 2005 Express Edition 227 Volume Shadow Services 560 Windows Installer 239 Microsoft-iSCSI-Initiators 558 Migration 947 Migrations Wizard 347, 351 Migrationsprojekt 918 Minimum Uptime 868 Mirrorview 533 Mischumgebung 245, 276 mkfile 506 Modellsysteme 954 Modellszenarien 924 Monitoring sensitivity 148 MPIO-Policy 558 MRU 465
1042
MSCS 854 Einschränkungen 856 MSDE 227 MSI/MSI-X-Unterstützung 359 msinfo32.exe 521 Multichassis Link Aggregation 484 Multikernsysteme 937 Multipathing 365, 527, 557 Multipathing-Policy 540 Multiple Connections per Session 474 Multiprotocol 519 Multiprozessor 937 Musterrolle 645
N NAA-Adresse 541 NAC-Regelwerk 320 Nagios-Plug-in 511 Namensauflösung 719 NAS 745 Native Client 230 Native-Multipathing-Plug-in 466, 527 Nearline 504 Net.TcpipHeapMax 479 Net.TcpipHeapsize 479 NetApp 455, 573 FAS2050 485 FAS-Familie 574 Snapshot 493 Volume 480 WAFL File-System 518 Neterion 317 Network Adapter 294 Auslastung 928 Fencing 968 File System 479 Storage Server 590 Network-attached Storage 479 NetXen 317 Netzwerkadapter 10-Gigabit 317 paravirtualisierter 358 Typen 357 Netzwerkeinstellungen 287 Netzwerkkarte 755 Netzwerkkartentyp E1000 755
Index
Netzwerkkartentyp (Forts.) Flexible 755 vlance 755 vmxnet 755 vmxnet 2 (Enhanced) 755 vmxnet 3 755 Netzwerklabel 362 Netzwerkpfad 271 Netzwerkport 253, 312, 335 Netzwerk-RAID 585 Netzwerkschicht physische 311 Netzwerkstatistiken 351 Netzwerkverkehr 316 Neuinstallation 208 Neverfail 268 NewSID 810 Nexus 1000v 356 NFC Copier 109 NFS 453, 479, 569 NFS.MaxVolumes 479 NFS-Client 481 nfsClient 890 NFS-Datastore 364, 847 NFS-Export 483 NFS-Speicher 125 NFS-Target 331 Nichtvirtualisierungsempfehlung 958 Non-Execution-Bit 97 Non-persistent Mode 764 Notifications 945 Notification-Templates 944 Notify Switches 91 Notstromversorgungen 951 NPIV 856 N-Port-ID-Virtualisierung 776 NTP 605 angepasst 606 Firewall 605 ntpdate 606 ntp.conf 605 ntpd 606 NTP-Dienst 605 NTP-Server 606 NUMA Memory Affinity 785 Nutzerrecht 647 Nutzungsgrad 918 nvram-Datei 760 NX/XD flag 96
O Oberfläche 289 ODBC 229 ODBC-Einstellungen 251 Offline Desktop 985 Open IPMI 667 Open iSCSI Initiator 560 Operations Manager 511 Optimize 944 Oracle 227 Oracle-Treiber 238 Orchestrator 1009 Originating Port-ID 371 Outbox 929 Outstanding I/O 460
P P2V 701 Packet-Filter 273 Packet-LAN 354 Paketfilter 735 pam_cracklib.so 882 pam_passwdqc.so 883 PAM-Karte 501 Paravirtualization 776 Parent-Image 990 Partition-Alignment konsistentes 518 Partitionierung 188 Partitionierungsmöglichkeiten 218 Partitionierungsvorschlag 191 Partitionstabelle 468 Partitionstartoffset 520 Passwort 184 Passwortgültigkeit 881, 884 Passwortkomplexität 881 Passwortlänge 881 Patch-Baseline 683 Patch-Datenbank 250 Patchen 930 Patch-Repository 212, 683, 693 Path Selection Policy 466, 479 PcoIP 984 PCoIP-Display-Protokoll 991 Peak Bandwith 338 Peak Hour 937 Peak Hours 940
1043
Index
Performance 292, 300, 652, 934 Performance Accelerator Module 498 Performance Counters 946 Performance-Daten 921 Performance-Messungen 924 Performance-Tab 486 Permissions 292, 300 PermitEmptyPasswords 880 PermitRootLogin 288, 876 Persistent Mode 764 Pfad verwalten 464 Phantom-Server 954, 958, 959 Phantomszenarien 924 Physical-to-virtual-Migration 707 physische Broadcast–Domäne physische 350 Pillar Data Systems 568 Pilot 569 Ping 926, 951 Planungsmöglichkeit 973 Platinum-Support 1010 Plattengröße 266 Plattentyp 713 plink 878 Plug-in 259, 342 Plug-in-Manager 259, 682 Plug-in-Schnittstelle 55 Policies 932 Port blocken 349 Freischaltung 628 Freischaltung über die Service Console 629 Port-Aggregation 314 Portal 966, 1020 Portal-Account 1024 Portangabe 720 Portfreigabe 259 Portfreischaltung 628 Port-Group 186 Portgruppe 312, 325 Portgruppenebene 367 Port-ID Originating 333 Portkonfiguration 271 Portübersicht VMware ESX 4 888 Post-Processing-Mode 504 PostScript 214
1044
Power-Aktivitäten 770 PowerCLI 308 Power-Management 773 Power-Management-Funktion 162 PowerPath/VE 534 PowerShell 308 Pre-Installation-Tasks 231 Pre-Screen Phone Interview 948 Primary Boot Device 203 private 946 Private Key 878 Private VLAN 344 Processor Balance Table 937 Processors Load 937 Produktlizenzentypen 1028 Profile-Ordner 250 Profilverzeichnis 252 Projekt 947 Projektbezogene Organisation 924 Promiscuous 350 Promiscuous Mode 339 Protection Group 999 Protokolldatei 928, 931 Protokollierung 898 externe 898 Protokolllevel 225 Provisioning 990 Proxy-Server 250, 744 Prozessorauslastung 928, 936, 937 Prüfpunkt 707 Prüfsumme 332 PubKeyAuthentication 876 Public Key 878 PuTTYgen 877 PVLAN 349 primary 350 secondary 350 PXE 191
Q qtree security 482 Quality of Service 572 Quick Assessment 956, 957 Quorumdisk 861
Index
R RAID 468 Random-Read-Muster 499 Random-Workload 499 Rapid Cloning Utility 497, 574 now.netapp.com 498 Rapid Virtualization Index 102 RARP-Pakete 105 Raw Device Mapping 112, 193, 765, 863, 865 Raw LUN 863 RDM 193 RDM-Mapping-Datei 115 Read-Cache 507 Read-only-User 932 Rechenzeit 609 Rechenzentren 917 Recht 288 administratives 269 durchpropagieren 651 Rechtezuweisung 972 Record- und Replay-Funktionen 165 Recovery Point Objective 840 Recovery Time Objective 460, 840 Recovery-Modell 234 Recovery-Plan 1000 Recovery-Prozess 1002 Recovery-Site 1002 REDO-Logs 111 Redundanz 927 Redundanz des Service-Console-Netzwerks 145 Referenznummer 1012 Refresh-Intervall 650 Regelwerk 888 Register Plug-in 355 Registrierung des Data Collectors im Information Warehouse 931 Registrierung neuer VMs 488 Registry Editor 610 Registry-Angaben 233 Remote 946 Remote Administrationstool 286 Remote CLI 107, 286, 304 Remote-Konfiguration 929 Remote-Steuerung 924 Replikation 266 Replikationsfunktion 996
Replikationsmechanismus 840 Replizierfunktionalität 587 Reports 943 Report-Template 943 Rescan SAN 486 Reservierung 292 Resource-Distribution-Charts 156 Resource-Pool 291, 300, 616 erstellen 616 expandable 618 Kontextmenü 616 Limit 617 Reservation 617 Shares 618 Ressourcenauslastung 153 Ressourcengruppe 264 Ressourcenmanagement 780 Ressourcenreservierung 90 Restore-Prozess 839 Reverse-Lookup-Zonen 146 Revert to Snapshot 821 Rich Clients 961 Rollback 211 root 482, 873 root:.ssh/authorized_keys 878 Root-Account für SSH-Zugriff freischalten 287 Root-Resource-Pool 154 root-Zugriff 872 Round-Robin 465 Round-Robin-Verfahren 365 Route based on ip hash 332 Route based on the originating port ID 332 Rückantwortzeit 737 Rücksicherung 832 Rücksicherungsoption 838 Runtime Settings 670
S SAN 745 Rescan 464 SAN/IQ 588 SANmaestro 584 SANmelody 577 SANmotion 582 SAN-Speicher 125 SANsurfer GUI 201
1045
Index
SANsurfer iscli 201 SANsymphony 577 SAS-Festplatte 499 sbin/nologin 875 Scheduled Task 663 Scheduler 481 Schlussmeeting 947 Schreib-/Lese-Belastung des StorageSystems 111 Schreibcache 578 Schwellenwert 935, 939, 941, 957 SCSI-Bus-Sharing 766 SCSI-Bus-Sharing-Mode 860 SCSI-Controller 754 SCSI-Festplatten-Controller 859 SCSI-Protokoll 548 SCSI-Reservation 525 SCSI-Reservation-Conflicts 102 Sechs-Prozessor-Lizenz 1022 Secondary PVLAN 350 Secure Shell 927 Security Profile 629 Self-VMotion 107 Send Targets 477 Separate Virtual Machines 158 Server Auslastung 37 Server-based Lizenzierung 1025 Server-Deployment 36 Server-Farm 599 Server-Landschaften 919 Server-Management-Controller 368 Service Console 213, 286, 288, 363 Portfreischaltung 629 service mgmt-vmware restart 93 Service-Console-Netz 322 Service-Console-Port 137, 313 Service-Console-Verbindung 125 Servicegruppe 732 Services 933 services.xml 245 Session 666 SHA1 179 Share 273, 292 shared 946 Shared Storage 460 Shares Custom 618 High 618
1046
Shares (Forts.) Low 618 Normal 618 Sharing-Modus 863 Shell 308 Sicherheit 898 Komponenten 898 Sicherheitsrichtlinien 288 Sicherheitsrisiko 192 Sicherung 831 konsistente 741 Sicherungsdaten 836 Sicherungszeiten 749 Sicherungsziel 745 Sicherungszyklus 747 SID 650 Simple Network Management Protocol (SNMP) 612 Simple-Recovery-Mode 234 Single Point of Failure 37 single_image-Cluster 461 Site Recovery Manager Plug-in 998 Site Survey Tool 168 Skalierbarkeit 961 Skalierungstest 967 Skript 289 skriptgesteuert 191 SLA 979 Slammer 568 Small Business 1007 Smart Copy 566 Smart-Clone-Volume 587 Smart-Copy-Replikat 567 SMVI 841 snap create 494 snap reserve 474 SnapManager for Virtual Infrastructures 574 SnapMirror 840 Snapshot 115, 460, 481, 576, 815, 838, 840, 852 Snapshot-Clone 573 Snapshot-Datei 817 Snapshot-Manager Befehle 816 Snapshot-Reserve 459 SnapVault 840 SNMP 612, 671, 895 SNMP GET 612
Index
snmpd 892 SNMP-Protokoll 612 SNMP-Trap 896 Software systemspezifische 719 Software-iSCSI 474 Softwareupdate-Server 208 Solutions & Applications 257 Source-MAC 335, 369 Source-Maschine 703 Spanning Tree 336 Spanning-Tree-Protokoll 314 Speicher hinzufügen 467 Speicherausbau 639 Speicherklassenmodell 579 Spiegelung asynchrone 996 Split-Brain 737 Split-Brain-Situation 143 Sprachen 291 SQL-Benutzerauthentifizierung 233 SQL-Server-Name 232 SRA 997 SRM 995 SSD-Laufwerk 568 SSH 287 sshd_config 287 ssh-keygen 879 SSH-Sicherheitsschlüssel 926 SSL-Zertifikat 168, 674, 894 Standardinstallation 261 Standardport 889 Standard-Setup 188 Standard-vSwitch 323 Start Order 624 Startart 267 Startparameter 266 Startseite 296 Statistics 669 Statistiken 932 Stats 929 Status des erworbenen Supports 1016 Stellplatz 866 Storage Adapter 294 Storage Alert 489 Storage Cluster 581 Storage Grid 545 Storage Pool 579
Storage Views 658 Storage VMotion 46, 89, 106, 1009 Storage/SAN Compatibility Guide 177 Storage-Prozessor 569 Storage-Replication-Modul 997 Storage-Virtualisierung 575 Storage-VMotion-Plug-in 106 Storage-VMotion-Prozess 109 Stratum 610 Streaming-Client 983 Strict Admission Control 124 su 873 Sub-LUN-Clon 498 Subscription 1010 sudo 222, 873 suid-Bit 874 Summary 291, 300 Support 1010 Support Entitlements 1016 Supportanfrage Schweregrad 1011 svmotion 307 Swap-Datastore 640 Swapfile Location 779 Switch Ausfall 370 unmanaged 366 switch user 873 Switch-Port physischer 328 überbuchen 471 Symmetrix 533 Symmetrix Remote Data Facility 533 Synchronisation 929 Synchronisierung 605 Syntax 306 sysconfig -v 502 Syslog 897 Sysprep 707, 708 sysprep 810 System geclontes 268 System-Account 243 Systemanalyse 927 System-DSN 230 System-ID 931 System-Logs 665 System-Resource-Pool 642 System-Rolle 645
1047
Index
Systems Compatibility Guide 177 Systemsteuerung 229 Systemtools 715 Systemvoraussetzungen 226 Systemwiederherstellung 707, 717 Szenariomodellierung 924
Triggered Alarm 676 Trunk 182 Trust 719 Turn on Fault Tolerance 170
T
Übernahme der Resource-Pools 154 Übertragungsstatistik 953 Überwachung 729 Überwachung der Messung 952 Überwachungsinformationen 612 Unified Storage 454 Unix 928 Hardlink 504 Rechte 482 Update Manager 207, 212, 250, 342, 356 Download 689 Download-Frequenz 686 Download-Server 689 Einstellungen 687 Export 692 Export der Patches 692 Kommandozeile 690 Konfigurationsdatei 690 Metadaten 692 Network Connectivity 683 Sicherheitsrichtlinien 686 smart reboot 688 Snapshot 686 Sprachversionen 692 vApp 688 Wiederholungsintervall 688 Zeitplaner 685 Update-Repository 213 Upgrade-Baselines 212 Uplink 312, 326, 368 für die Weiterleitung 332 Uplink-Port 471 Use shared repository 684 User-DSN 230 User-ID 0 482 usermod 873 USP-V 537 USP-VM 537
Take a Snapshot 820 Taktsignal 869 Target-Port 455 Task New 664 Task- bzw. Job-Planer 923 Task-Typ 732 TCP Segmentation Offload 359 TCP/IP-Heap-Size 479 Teaming 330, 348, 705 Template 805, 965 Templates 924, 941, 954 Test-Trap 614 Testumgebung 961 Thin CoW 530 Thin Provisioned Format 114 Thin Provisioning 489, 508, 527, 528, 568, 574 ThinApp 982 Threshold 939 Time Configuration 295, 606 Timeline 948 Timeout-Parameter 729 Timeout-Wert 512, 672 Timer 609 Time-Service 610 Tip of the Day 666 tnsnames.ora 237 TNS-Profil 237 Toolkit 308 Traffic Shaping 325, 337, 349 Transaktion 609 Trap 612 trapcommunity 613, 896 trapsink 613, 896 Traveller CPR 582 Trend 937 Trend Deviations 940 Trendanalyse 924 Trendanzeige 938
1048
U
Index
V vApp 619 Abarbeitungsreihenfolge 625 anlegen 620 Edit Settings 622 IP Allocation Policy 623 Längenbeschränkung des Namens 620 Manual Startup 627 Optionen 622 Ressourcen 620 Start Order 622 transient 623 Verknüpfung 620 var/log:messages 873 var/log:secure 873 VCB 46, 261, 836 VCB-Proxy 837 vCenter Advanced Settings 674 Management-Homepage 631 vCenter Agent 1008 vCenter CapacityIQ 973 vCenter Chargeback 975 vCenter Converter 253, 254, 700 Advanced options 716 Data to copy 712 Devices 714 Dienste 715 Größe der Festplatten 705 Nacharbeiten 718 Networks 714 vCenter Converter Standalone 260, 709 vCenter Guided Consolidation 239, 255 vCenter Heartbeat add 731 Anhebung des Log-Levels 730 Ausschlussliste 739 Auto Select 737 Benachrichtigungen 740 Data 738 Event 727 Fehlersuche 731 Fehlerverhalten 732 Filter 739 Heartbeat Update 725 Konfigurationsreiter 723 Log-Daten 726 Mail-Versand 727
vCenter Heartbeat (Forts.) Max. Disk Usage 736 Meldungen 739 Plug-ins 734 Registry 739 Remove 733 Rollen 734 Services 731 Shutdown 725 Start Replicating 724 Stop Replicating 725 Switchover 725 Task 732 Verteilerliste 728 Wichtigkeit 727 Wiederholungsintervall 733 vCenter Lab Manager 965 vCenter Orchestrator 970 vCenter Server Heartbeat 267, 722 Fehlerkombinationen 740 Rollback 741 Wertigkeit 741 vCenter Site Recovery Manager 995 vCenter Update Manager 247, 681 vCenter-Plug-in 355 vCenter-Protokolldateien 260 vCenter-Server 224, 298, 483 Bestandsliste 297 Kombinationen von physischen oder virtuellen 276 Lösungen und Anwendungen 297 Management 297 Verwaltung 297 VDI 985 Vdisk 541 Verbindungsaufbau 254, 929 zu den Zielsystemen 926 Verbindungstests 924, 926 Verbindungsverlust 362 Vererbungsreihenfolge 646 Verfügbarkeit 329, 958 Verlinkung 224 Vertraulichkeit 929 Verwaltungsmöglichkeiten 283 Verwaltungssicherheit 257 vi 287 VI3 Lizenzierung 1024 VIBE 841, 847 vicfg-ntp.pl 607
1049
Index
vicfg-snmp 614 Video-RAM 103 View Client 989 View Composer 990 View Manager 4 986 Vintage Servers 940 Viren-Pattern 742 Virtual Appliance 222 Virtual Center-Verwaltung 887 virtual compatibility mode 109 Virtual Copy 530 Virtual Desktop Infrastructure 961 Virtual Ethernet Module 352 Virtual Machine Startup/Shutdown 626 Virtual Machine File System 45 Virtual Machine Manager 38 Virtual Machine Monitoring 148, 302, 866 Virtual Machine Options 133 Virtual Storage Appliance 585 Virtual Storage Console 514 Virtual Storage Management 592 Virtual Storage Plug-in 584 Virtual Supervisor-Modul 352 Virtual Symmetric Multi Processing 45 Virtual Tape Library 590 Virtual-Disk-Mode 764 Virtualisierung hypervisor-basierte 38 Virtual-Machine-Netzwerk 322 Virtual-Machine-Netzwerkverbindungen 124 Virtual-Volume-Storage-Bus-Treiber 262 Virtuelle Hardware 751, 767 Virtuelle Maschine 34, 751 Ablaufdatum 971 Lebenszyklus 971 Migration 804 Optimierung 796 Virtueller getunnelter Interconnect 461 Virtueller Server Rechnung 977 VLAN 364 VLAN-ID 187, 327 VLAN-Offloading 359 VLAN-Pass-through 328 VLAN-Tagging 314, 325, 327 VLAN-Trunking 344
1050
VLAN-Trunk-Port 327 VLAN-Zuordnung 327 vLockstep-Technologie 165 VM Killen einer hängenden 828 Registrierung neuer 488 VM Network 347 vMA 307 V-MAX 533 VMDirectPath I/O 360, 590 VMDK-Alignment 512 vmdk-Datei 758, 860 VMFS Volume Grow 490 VMFS-3 459 VMFS-Partition 262 VMFS-Signatur 495 VMkernel 286 VMkernel-iSCSI-Software-Initiator 550 VMkernel-Netz 321, 323 VMkernel-Port 93, 313, 553 vmkiscsi-tool -V -l 554 vmklogger 165 vmkping 483 VMM 38, 868, 869 vmnic 318 vmnic-Adapter 334 VMotion 89, 316, 547, 887 VMotion-Abbrüche 105 VMotion-Datenübertragung 100 VMotion-Interface 93 VMotion-Migration 126 VMotion-Modul 92 VMotion-Netz 365 VMotion-Priorität 99 VMotion-Prozess 90 VMotion-Vorgang 148, 337 vmsd-Datei 760 vmss-Datei 760 vm-support 1012 VM-Swapfile 639 VMW_SATP_ALUA 466 VMware Backup 110 VMware Consolidated Backup 46, 115, 261, 594, 836 VMware Converter 48, 701 VMware Data Recovery 47, 279, 852 Managementoberfläche 742 VMware DPM 45 VMware DRS 45, 47, 301
Index
VMware ESX 43 VMware ESXi 43 VMware Fast Server Recovery 124 VMware Fault-Tolerance (FT) 46, 317 VMware Fusion 42 VMware Guided Consolidation 49 VMware High Availability (HA) 46, 124, 164, 301 VMware Lifecycle Manager 971 VMware Paravirtual 754 VMware Player 42 VMware Scripts 799 VMware SDK 107 VMware SDK for Perl 49 VMware Server 42 VMware Site Recovery Manager (SRM) 567, 587 VMware Storage Thin Provisioning 45 VMware Storage VMFS 45 VMware Studio 49 VMware Tools 358, 608, 700, 798 aktualisieren 802 VMware Tools Service 798 VMware Tools Toolbox 799 VMware User Prozess 799 VMware vCenter Orchestrator 49 VMware vCenter Server 47 standalone 243 VMware vCenter Server Heartbeat 48 VMware vCenter Server Linked Mode 49 VMware vCenter Update Manager 48 VMware View 4 984 VMware VMotion 46 VMware VMotion and CPU Compatibility 177 VMware VMsafe 47 VMware vNetwork Distributed Switch 45 VMware vShield Zones 47 VMware vSMP 45 VMware vSphere 43 VMware vSphere CLI 50 VMware vSphere Client 49 VMware vSphere Guest SDK 50 VMware vSphere Management Assistant 50 VMware vSphere PowerCLI 50 VMware vSphere Web Services SDK 49 VMware vSphere WebAccess 49 VMware Workstation 41, 205
VMware-Gerätetreiber 798 VMware-HA-Cluster 363 VMware-Lizenzen 1006 VMware-Lizenz-Server 634 VMware-Maps-Funktion 169 VMware-Tools-Skript 771 vmware-umds.exe 689 vmx-Datei 339, 758 vmxf-Datei 760 vmxnet2-Adapter 359 vmxnet3-Adapter 359 vmxnet-Adapter 358 vNIC-Port 331 vol autogrow 510 vol create 459, 473 Volume Schattenkopie 741 VSS 741 Volume Space Guarantee 511 Volumen-Schattenkopie 741 Volume-Snapshot 564 Vorher-Nachher-Betrachtung 963 Vorhersage 936 VPN-Verbindung 953 vpxa 92 vpxuser 873 vRAID 542 vShield Zones 315, 352, 1009 VSM 357 VSM-Appliance 354 vSphere 4i 216 vSphere 4-Lizenzen 1019 vSphere Advanced 1008 vSphere CLI 220 vSphere Compatibility Matrixes 177 vSphere Enterprise 1008 vSphere Enterprise Plus 1008 vSphere_removehba_V1.sh 181 vSphere4 Essential 1011 vSphere4 Standard 1008 vSphere-Client 245, 290 herunterladen 290 vSphereHost Advanced Settings 642 vSphere-Server reparieren 218 vStorage-API 498 vSwitch 311, 367
1051
Index
vswp-Datei 759 VTIC 461
Workflow 970 WWPN 457
W
X
w32tm 611 WAFL-Dateisystem 508 Wartungsmodus 164 Wartungsplan 834 Watchdog-Prozess 137 WebAccess 488 webbasierte Benutzerschnittstelle 924 Webbrowser 285 Webdienst 283 Weboberfläche 283 Webservice 283 Webzugriff 283 Wechselmedien 718 wheel-Gruppe 873 Wiederherstellbarkeit 257 Windows 306 Windows Automounter 262 Windows Management Instrumentation 927 Windows Registry 931 Windows Vista 359 Wireshark 339
XML-Datei 601
1052
Z Zeitdienst 611 Zeitfenster 650 Zeitreferenzquelle 610 Zeit-Server 736 Zeitsynchronisation 274, 609, 772, 799 Zeitzone 742 zentrale Benutzerverwaltung 886 Zero Page Reclaim 538 Zero-Detection 529 Zieldatenbank 248 Zielpartition 214 Zielsystem 922, 927, 930, 932, 934, 940, 948, 951, 957, 958 zonecreate 458 Zoning 181, 456 Zugangsdaten 925 Zugriffsport 672 Zugriffsrecht 298, 647 Zwei-Prozessor-Lizenz 1022 Zwischenbericht 943
