SAN Configuration Guide

Transcription

Handbuch der SAN-Konfiguration
ESX Server 3.0.1 und VirtualCenter 2.0.1
Überarbeitung: 20061127
Artikel: VI-DEU-Q406-320
Die aktuelle technische Dokumentation finden Sie auf unserer Website unter folgender Adresse:
http://www.vmware.com/support/
Hier finden Sie auch die neuesten Produkt-Updates.
Anmerkungen zu dieser Dokumentation senden Sie bitte an folgende E-Mail-Adresse:
[email protected]
© 2006 VMware, Inc. Alle Rechte vorbehalten. Geschützt durch mindestens eines der US-Patente mit
folgenden Nummern: 6.397.242, 6.496.847, 6.704.925, 6.711.672, 6.725.289, 6.735.601, 6.785.886,
6.789.156, 6.795.966, 6.880.022, 6.961.941, 6.961.806 und 6.944.699; weitere Patente sind angemeldet.
VMware, das VMware „boxes“-Logo und -Design, Virtual SMP und VMotion sind eingetragene Marken
oder Marken der VMware, Inc. in den USA und/oder anderen Ländern.
Alle anderen in diesem Dokument erwähnten Bezeichnungen und Namen sind unter Umständen
markenrechtlich geschützt.
VMware, Inc.
3145 Porter Drive
Palo Alto, CA 94304
www.vmware.com
2
VMware Global Inc.
Zweigniederlassung Deutschland
Freisinger Str. 3
85716 Unterschleißheim/Lohhof
Tel: +49 89 371 564 000
Fax: +49 89 371 564 098
VMware, Inc.
Inhalt
Einleitung 9
1 Überblick über VMware ESX Server 15
Einführung in ESX Server 16
Software- und Hardware-Kompatibilität 18
Erläuterungen zur Virtualisierung 19
CPU-, Speicher- und Netzwerkvirtualisierung 19
Virtual SCSI 20
Festplattenkonfigurationsoptionen 21
Virtual Machine File System (VMFS) 22
Raw Device Mapping 23
Virtuelle SCSI-HBA 23
Interaktion mit ESX Server-Systemen 23
VMware Virtual Center 24
Service-Konsole 25
Prozesse und Services der Service-Konsole 25
Virtualisierung im Überblick 26
2 Verwenden von ESX Server mit SAN 29
SAN-Konzepte 30
Überblick über die Verwendung von ESX Server mit SAN 32
Vorteile der Verwendung von ESX Server mit SAN 32
Anwendungsbeispiele 33
Informationssuche 34
Besonderheiten der Verwendung von SAN-Arrays mit ESX Server 35
Gemeinsame Nutzung eines VMFS auf mehreren ESX Server-Systemen 35
Metadaten-Aktualisierungen 36
LUN-Anzeige und erneutes Scannen 37
Host-Typ 37
Komplexitätsebenen 37
Datenzugriff: VMFS oder RDM 38
Management-Anwendungen von Drittanbietern 39
Zoning und ESX Server 39
Zugriffskontrolle (LUN-Maskierung) und ESX Server 40
VMware, Inc.
3
Grundlegendes zu VMFS- und SAN-Speicheroptionen 40
Auswahl großer oder kleiner LUNs 40
LUN-Entscheidungen 41
Prädiktives Schema 42
Adaptives Schema 42
Tipps 42
Grundlegendes zum Datenzugriff 43
Aufrufen von Daten in einem SAN Array 43
Funktionsweise des Datenzugriffs virtueller Maschinen 44
Funktionsweise des Datenzugriffs virtueller Maschinen in einem SAN 45
Pfad-Management und Failover 46
Auswahl der Speicherorte virtueller Maschinen 48
Präventionsmaßnahmen gegen Server-Ausfälle 49
Verwenden von VMware HA 49
Verwenden von Cluster-Diensten 50
Server-Failover und Speicheraspekte 51
Optimieren der Ressourcen-Nutzung 51
Verwenden von VMotion zum Migrieren virtueller Maschinen 52
Verwenden von VMware DRS zum Migrieren virtueller Maschinen 52
3 Voraussetzungen und Installation 53
Allgemeine Voraussetzungen für ESX Server mit SAN 54
Einschränkungen 55
Festlegen von LUN-Zuweisungen 55
Einrichten des FC-HBA 56
Empfehlungen 57
Voraussetzungen für einen ESX Server-Systemstart über SAN 57
Schritte für Installation und Setup 59
4 Einrichten von SAN-Speicher-Devices
mit ESX Server 61
Einrichtungsübersicht 62
Tests 62
Unterstützte Devices 63
Allgemeine Überlegungen 64
EMC CLARiiON-Speichersysteme 64
EMC CLARiiON AX100 65
EMC CLARiiON AX100 und RDM 65
AX100-Anzeigeprobleme mit inaktiven Verbindungen 65
Automatische Volume-Resignatur 66
4
VMware, Inc.
Inhalt
EMC Symmetrix-Speichersysteme 66
IBM TotalStorage DS4000-Speichersysteme 67
Konfigurieren der Hardware für SAN-Failover bei
DS4000-Speicherservern 67
Überprüfen der Port-Konfiguration des Speicherprozessors 69
Deaktivieren der automatischen Volume-Übertragung (AVT) 70
Konfigurieren von Sense-Daten des Speicherprozessors 70
IBM TotalStorage DS4000 und Pfad-Thrashing 71
IBM TotalStorage 8000 71
Automatische Resignatur 71
HP StorageWorks-Speichersysteme 72
HP StorageWorks MSA 72
Festlegen des Profilnamens „Linux“ 72
Probleme mit dem Hub-Controller 74
HP StorageWorks EVA 74
HP StorageWorks XP 74
Hitachi Data Systems-Speicher 75
Network Appliance-Speicher 75
Festlegen des LUN- und Initiatorgruppentyps 75
Speicherbereitstellung 76
5 Verwenden des Systemstarts über SAN mit ESX Server-Systemen 77
Einführung in den Systemstart über SAN 78
Funktionsweise des Systemstarts über SAN 78
Vorteile des Systemstarts über SAN 79
Vorbereitungen für den Systemstart über SAN 79
Grundsätzliche Überlegungen 80
LUN-Maskierung beim Systemstart über SAN 81
Vorbereiten des SAN 81
Minimieren der Anzahl an Initiatoren 82
Einrichten des FC-HBA für den Systemstart über SAN 83
Einrichten des QLogic-FC-HBA für den Systemstart über SAN 83
Aktivieren des QLogic-HBA-BIOS 83
Aktivieren der Boot-Auswahl 84
Auswählen der Boot-LUN 84
Einrichten des Systemstarts über CD-ROM 85
Einrichten des Emulex-FC-HBA für den Systemstart über SAN 85
VMware, Inc.
5
6 Verwalten von ESX Server-Systemen,
die SAN-Speicher verwenden
87
Probleme und Lösungen 88
Mögliche Probleme 89
Abrufen von Informationen 89
Anzeigen von HBA-Informationen 90
Anzeigen von Datastore-Informationen 90
Lösen von Anzeigeproblemen 92
Erläuterungen zur LUN-Benennung in der Anzeige 92
Beheben von Problemen mit nicht sichtbaren LUNs 93
Verwenden von „Neu scannen“ 94
Entfernen von Datastores 95
Erweiterte Konfiguration der LUN-Anzeige 95
Ändern der Anzahl gescannter LUNs mithilfe von Disk.MaxLUN 95
Masking von LUNs mithilfe von Disk.MaskLUNs 96
Ändern der Sparse-LUN-Unterstützung mithilfe von
DiskSupportSparseLUN 97
Multipathing 97
Anzeigen des aktuellen Multipathing-Status 98
Aktive Pfade 101
Festlegen der Multipathing-Policy einer LUN 101
Deaktivieren und Aktivieren von Pfaden 102
Einrichten des bevorzugten Pfads (Nur feste Pfad-Policy) 103
Pfad-Management und manueller Lastausgleich 104
Beispiel für die Verwendung des manuellen Lastausgleichs 104
Failover 105
Festlegen des HBA-Timeout für Failover 107
Festlegen von Device-Treiberoptionen für SCSI-Controller 107
Festlegen des Betriebssystem-Timeouts 108
Konfiguration des VMkernels 108
Gemeinsame Nutzung von Diagnosepartitionen 109
Vermeiden und Beheben von Problemen 109
Optimieren der SAN-Speicherleistung 110
Speicher-Array-Leistung 110
Server-Leistung 111
Lösen von Leistungsproblemen 112
Überwachen der Leistung 112
Auflösen von Pfad-Thrashing 113
Erläuterungen zum Pfad-Thrashing 114
Ausgleichen des Festplattenzugriffs zwischen virtuellen Maschinen 115
6
VMware, Inc.
Inhalt
Entfernen von VMFS-2-Treibern 115
Verringern von SCSI-Reservierungen 116
Festlegen der maximalen Warteschlangentiefe für HBAs 116
Anpassen der Warteschlangentiefe für einen QLogic-HBA 116
Anpassen der Warteschlangentiefe für einen Emulex-HBA 117
Überlegungen zum SAN-Speicher-Backup 118
Backups in einer SAN-Umgebung 118
Snapshot-Software 119
Verwenden eines Drittanbieter-Backup-Pakets 120
Auswählen Ihrer Backup-Lösung 120
Anwendungen mit mehreren Ebenen 121
Array-basierte (Drittanbieter-)Lösung 121
Dateibasierte (Drittanbieter-)Lösung 121
VMFS-Volume-Resignatur 122
Mounten von Original- und Snapshot-VMFS-Volumes 122
Probleme mit der Anzeige derselben LUN-ID auf mehreren Hosts 123
Erläuterungen zu Resignatur-Optionen 124
Status 1 - EnableResignature=no, DisallowSnapshotLUN=yes
(Standard) 124
Status 2 - EnableResignature=yes, (DisallowSnapshotLUN ist
nicht relevant) 125
Status 3 - EnableResignature=no, DisallowSnapshotLUN=no 125
A Checkliste für Multipathing 127
B Dienstprogramme 129
Dienstprogramm esxtop 130
Dienstprogramm storageMonitor 130
Optionen 131
Beispiele 131
Index 133
VMware, Inc.
7
8
VMware, Inc.
Einleitung
In dieser Einleitung wird der Inhalt vom Handbuch der SAN-Konfiguration beschrieben
und auf technisches Hilfsmaterial sowie VMware®-Schulungen verwiesen.
Diese Einleitung umfasst die folgenden Themen:

„Über dieses Handbuch“ auf Seite 10.

„Technischer Support und Schulungen“ auf Seite 12.
VMware, Inc.
9
Über dieses Handbuch
Das vorliegende Handbuch der SAN-Konfiguration enthält Informationen zur
Verwendung eines ESX Server-Systems mit einem Storage Area Network (SAN).
Es behandelt konzeptionelle Hintergründe, Installationsanforderungen und
Management-Aspekte zu folgenden Themenschwerpunkten:

Grundlegendes zu ESX Server – Verschafft SAN-Administratoren einen ersten
Überblick über ESX Server-Systeme.

Verwendung von ESX Server mit einem SAN – Beschreibt Anforderungen,
wesentliche Unterschiede in der SAN-Einrichtung bei Verwendung von
ESX Server sowie die gleichzeitige Verwaltung und Fehlerbehebung
beider Systeme.

Einrichten eines ESX Server-Systems für den Systemstart über eine LUN in einem
SAN – Beschreibt Anforderungen, Einschränkungen und Management eines
Systemstarts über SAN.
HINWEIS Schwerpunkt dieses Handbuchs sind Fibre-Channel (FC)-SANs. iSCSI- oder
NFS-Speicher-Devices werden nicht behandelt. Informationen über iSCSI und
NFS finden Sie im Handbuch zur Server-Konfiguration.
Verlauf der Überarbeitung
Dieses Handbuch wird bei jeder Produktveröffentlichung oder nach Bedarf revidiert.
Eine überarbeitete Version kann geringfügige oder signifikante Änderungen enthalten.
Tabelle P-1 zeigt den Verlauf der Überarbeitung dieses Handbuchs.
Tabelle P-1. Verlauf der Überarbeitung
Überarbeitung
Beschreibung
20060615
ESX Server 3.0- und VirtualCenter 2.0-Version vom
Handbuch der SAN-Konfiguration für VMware Infrastructure 3.
Dies ist die erste Ausgabe dieses Handbuchs.
20060925
ESX Server 3.0.1- und VirtualCenter 2.0.1-Version vom Handbuch der
SAN-Konfiguration für VMware Infrastructure 3. Diese Ausgabe enthält
geringfügige Änderungen.
10
VMware, Inc.
Einleitung
Zielleserschaft
Die Informationen aus diesem Handbuch sind für erfahrene Windows- oder
Linux-Systemadministratoren bestimmt, die mit dem Betrieb virtueller Maschinen im
Rechenzentrum vertraut sind.
Feedback zu diesem Dokument
Anmerkungen zu dieser Dokumentation senden Sie bitte an folgende E-Mail-Adresse:
[email protected]
Dokumentation zur VMware Infrastruktur
Die Dokumentation zur VMware Infrastruktur besteht aus der kombinierten
Dokumentation zu VirtualCenter und ESX Server.
Die neueste Version dieses Handbuchs und weitere Handbücher sind unter folgender
Adresse verfügbar:
http://www.vmware.com/support/pubs
Konventionen
Tabelle P-2 zeigt die in diesem Handbuch verwendeten typografischen Konventionen.
Tabelle P-2. Typografische Konventionen
Schriftart
Elemente
Blau (nur online)
Querverweise und E-Mail-Adressen
Blauer Fettdruck (nur online)
Links
Schwarzer Fettdruck
Elemente der Anwenderoberfläche, z. B.
Schaltflächenbezeichnungen und Menüelemente
Nicht-Proportionalschrift
Befehle, Dateinamen, Verzeichnisse und Pfade
Nicht-Proportionalschrift, fett
Anwendereingaben
Kursiv
Dokumenttitel, Glossarbegriffe und
gelegentliche Hervorhebungen
< Name >
Variablen- und Parameternamen
VMware, Inc.
11
In Grafiken verwendete Abkürzungen
In den Grafiken in diesem Handbuch werden die in Tabelle P-3 aufgeführten
Abkürzungen verwendet.
Tabelle P-3. Abkürzungen
Abkürzung
Beschreibung
VC
VirtualCenter
VI-Client
Client der virtuellen Infrastruktur
Server
VirtualCenter-Server
Datenbank
VirtualCenter-Datenbank
Hostn
Von VirtualCenter verwaltete Hosts
VM#
Virtuelle Maschinen auf einem verwalteten Host
Anwender#
Anwender mit Zugriffsgenehmigungen
spf#
Speicherfestplatte für den verwalteten Host
Datastore
Speicher für den verwalteten Host
SAN
SAN-Datastore, der von mehreren verwalteten Hosts gemeinsam genutzt wird
vrlg
Template
Technischer Support und Schulungen
In den folgenden Abschnitten werden die verfügbaren Ressourcen für den technischen
Support beschrieben.
Selbsthilfe-Support
Im VMware-Technologienetzwerk (VMTN) finden Sie Tools zur Selbsthilfe sowie
technische Informationen:

Produktinformationen – http://www.vmware.com/products/

Technologieinformationen – http://www.vmware.com/vcommunity/technology

Dokumentation – http://www.vmware.com/support/pubs

VMTN-Wissensbasis – http://www.vmware.com/support/kb

Diskussionsforen – http://www.vmware.com/community

Anwendergruppen – http://www.vmware.com/vcommunity/usergroups.html
Weitere Informationen zum VMware-Technologienetzwerk finden Sie unter
http://www.vmtn.net.
12
VMware, Inc.
Einleitung
Online- und Telefonsupport
Im Onlinesupport können Sie technische Unterstützung anfordern, Ihre Produkt- und
Vertragsdaten abrufen und Ihre Produkte registrieren. Weitere Informationen finden
Sie unter http://www.vmware.com/support.
Im Telefon-Support erhalten Kunden mit entsprechenden Support-Verträgen schnelle
Hilfe bei Problemen der Prioritätsstufe 1. Weitere Informationen finden Sie unter
http://www.vmware.com/support/phone_support.html.
Supportangebote
Wenn Sie wissen möchten, wie die Supportangebote von VMware Sie dabei
unterstützen können, Ihre geschäftlichen Anforderungen zu erfüllen, besuchen
Sie die Website http://www.vmware.com/support/services.
VMware-Schulungen
Die Kurse von VMware umfassen umfangreiche Praxisübungen, Fallbeispiele und
Kursmaterialien, die zur Verwendung als Referenz-Tools bei der praktischen Arbeit
vorgesehen sind. Weitere Informationen über VMware-Schulungen finden Sie unter
http://mylearn1.vmware.com/mgrreg/index.cfm.
VMware, Inc.
13
14
VMware, Inc.
1
Überblick über
VMware ESX Server
1
Sie können ESX Server in Verbindung mit einem SAN (Storage Area Network)
einsetzen. Dabei handelt es sich um ein spezielles Hochgeschwindigkeitsnetzwerk,
das Computersysteme mit leistungsfähigen Speichersubsystemen verbindet. Durch
den Einsatz von ESX Server mit einem SAN verfügen Sie über zusätzlichen Speicher
für die Konsolidierung. Darüber hinaus wird die Zuverlässigkeit optimiert und die
Disaster Recovery vereinfacht.
Damit Sie ESX Server effektiv mit einem SAN einsetzen können, müssen Sie über
praktische Kenntnisse zu ESX Server-Systemen und SAN-Konzepten verfügen. In
diesem Kapitel erhalten Sie einen Überblick über ESX Server-Konzepte. Es richtet sich
an SAN-Administratoren, die noch nicht mit ESX Server-Systemen vertraut sind und
enthält die folgenden Abschnitte:

„Einführung in ESX Server“ auf Seite 16.

„Erläuterungen zur Virtualisierung“ auf Seite 19.

„Interaktion mit ESX Server-Systemen“ auf Seite 23.

„Virtualisierung im Überblick“ auf Seite 26.
Ausführliche Informationen über VMware ESX Server finden Sie unter
http://www.vmware.com/products/esx/ im Bereich Technical Resources.
Dieser Bereich enthält Dokumentation, Listen zur Hardware-Kompatibilität,
White Paper und mehr.
VMware, Inc.
15
Einführung in ESX Server
Mit der ESX Server-Architektur können Administratoren Hardware-Ressourcen
mehreren Arbeitslasten in vollständig isolierten Umgebungen zuweisen, die als
virtuelle Maschinen bezeichnet werden.
Ein ESX Server-System besteht aus den folgenden Hauptkomponenten:

Virtualisierungsebene - Diese Ebene stellt die idealisierte Hardware-Umgebung
und Virtualisierung zugrunde liegender physischer Ressourcen für die virtuellen
Maschinen bereit. Sie umfasst den Virtual Machine Monitor (VMM), der für die
Virtualisierung verantwortlich ist, und VMkernel.
Die Virtualisierungsebene plant die Service-Konsole, die auf dem ESX Server-Host
ausgeführt wird, und die Betriebssysteme der virtuellen Maschine. Die
Virtualisierungsebene verwaltet den Zugriff der Betriebssysteme auf physische
Ressourcen. Der VMkernel benötigt eigene Treiber, um Zugriff auf die physischen
Devices bereitzustellen. Bei VMkernel-Treibern handelt es sich um modifizierte
Linux-Treiber, auch wenn der VMkernel keine Linux-Variante ist.
16

Hardware-Schnittstellenkomponenten - Die virtuelle Maschine kommuniziert
über Hardware-Schnittstellenkomponenten mit Hardware, wie z. B. der
CPU oder Festplatte. Diese Komponenten enthalten Gerätetreiber, die eine
Hardware-spezifische Bereitstellung von Diensten ermöglichen und
Hardware-Unterschiede gegenüber anderen Teilen des Systems ausblenden.

Benutzeroberfläche - Administratoren haben mehrere Möglichkeiten zum
Anzeigen und Verwalten von ESX Server-Hosts und virtuellen Maschinen
(siehe Abbildung 1-2).

Ein Client der virtuellen Infrastruktur (VI-Client) kann eine direkte
Verbindung zum ESX Server-Host herstellen. Dies bietet sich an, wenn Ihre
Umgebung nur über einen Host verfügt.

Ein VI-Client kann auch eine Verbindung zu einem
VirtualCenter-Management-Server herstellen und mit allen ESX Server-Hosts
interagieren, die von diesem VirtualCenter-Server verwaltet werden.

Mit dem Web Access-Client der virtuellen Infrastruktur können Sie zahlreiche
Managementaufgaben mit einer Browser-basierten Oberfläche ausführen.

Die Befehlszeilen-Oberfläche der Service-Konsole wird nur selten verwendet.
Der VI-Client ersetzt, ausgehend von ESX Server 3.0, die Service-Konsole für
die meisten Interaktionen. (Die Befehle haben sich gegenüber früheren
Versionen von ESX Server geändert.)
VMware, Inc.
Kapitel 1 Überblick über VMware ESX Server
In Abbildung 1-1 ist der VI-Client mit der ausgewählten Registerkarte
Übersicht dargestellt.
Abbildung 1-1. Benutzeroberfläche des VI-Clients
HINWEIS Mit ESX Server 3.0 und VirtualCenter 2.0 können Sie nahezu alle Vorgänge mit dem
VI-Client ausführen.
In Abbildung 1-2 ist die Interaktion der Komponenten dargestellt. Für den
ESX Server-Host sind vier verschiedene virtuelle Maschinen konfiguriert. Auf jeder
virtuellen Maschine werden ein eigenes Gastbetriebssystem und eigene Anwendungen
ausgeführt. Administratoren haben zwei Möglichkeiten zum Überwachen des Host
und der virtuellen Maschinen:

Verwenden eines VI-Clients zum direkten Verbinden mit einem ESX Server-Host.

Verwenden eines VI-Clients zum Verbinden mit einem VirtualCenter-Server. Der
VirtualCenter-Server kann eine Reihe von ESX Server-Hosts verwalten.
VMware, Inc.
17
VI Web Access
Infrastruktur
Infrastruktur
Infrastruktur
ESX Server-Host
Anwendungen Anwendungen Anwendungen Anwendungen
Gastbetriebssystem Gastbetriebssystem Gastbetriebssystem Gastbetriebssystem
VirtualCenterServer
virtuelle Maschine virtual machine virtual machine virtuelle Maschine
VMware-Virtualisierungsebene
Host-Betriebssystem
Arbeitsspeicher
CPUs
Speicher-Array Festplatte network
Abbildung 1-2. Virtuelle Infrastrukturumgebung
Weitere Informationen finden Sie unter „Software- und Hardware-Kompatibilität“ auf
Seite 18.
Software- und Hardware-Kompatibilität
In der VMware ESX Server-Architektur interagiert das Betriebssystem der virtuellen
Maschine (das Gastbetriebssystem) nur mit der x86-kompatiblen Standardhardware,
die durch die Virtualisierungsebene dargestellt wird. Dadurch können
VMware-Produkte alle x86-kompatiblen Betriebssysteme unterstützen.
In der Praxis unterstützen VMware-Produkte zahlreiche x86-kompatible
Betriebssysteme, die während des gesamte Produktentwicklungszyklus getestet
werden. VMware dokumentiert die Installation und den Betrieb dieser
Gastbetriebssysteme und schult die technischen Mitarbeiter im Support.
Die meisten Anwendungen interagieren nur mit dem Gastbetriebssystem, nicht mit der
zugrunde liegenden Hardware. Daher können Sie Anwendungen auf Hardware Ihrer
Wahl ausführen, wenn Sie eine virtuelle Maschine mit dem Betriebssystem installieren,
das die Anwendung erfordert.
18
VMware, Inc.
Erläuterungen zur Virtualisierung
Die VMware-Virtualisierungsebene ist in allen VMware-Desktop-Produkten
(wie z. B. VMware Workstation) und Server-Produkten (wie z. B. VMware ESX Server)
vorhanden. Diese Ebene bietet eine einheitliche Plattform für die Entwicklung,
Prüfung, Bereitstellung und den Support von Anwendungsarbeitslasten und ist wie
folgt aufgebaut:

Auf jeder virtuellen Maschine werden ein eigenes Betriebssystem
(das Gastbetriebssystem) und eigene Anwendungen ausgeführt.

Die Virtualisierungsebene stellt die virtuellen Geräte bereit, die Anteilen
bestimmter physischer Geräte zugeordnet werden. Dazu gehören virtualisierte
CPU, Speicher, I/O-Busse, Netzwerkschnittstellen, Speicheradapter und –geräte,
Human Interface Devices und BIOS.
Weitere Informationen finden Sie in den folgenden Abschnitten:

„CPU-, Speicher- und Netzwerkvirtualisierung“ auf Seite 19.

„Virtual SCSI“ auf Seite 20.
CPU-, Speicher- und Netzwerkvirtualisierung
Eine virtuelle VMware-Maschine bietet die vollständige Hardware-Virtualisierung.
Das Gastbetriebssystem und Anwendungen, die auf einer virtuellen Maschine
ausgeführt werden, können in keinem Fall direkt ermitteln, auf welche physischen
Ressourcen sie zugreifen (beispielsweise, auf welcher physischen CPU sie in einem
Multiprozessorsystem ausgeführt werden oder welcher physischer Speicher ihren
Seiten zugeordnet ist).

CPU-Virtualisierung - Jede virtuelle Maschine scheint vollständig isoliert von
anderen virtuellen Maschinen auf einer eigenen CPU (oder einer Reihe von CPUs)
ausgeführt zu werden. Register, der Translation Look-aside Buffer und andere
Kontrollstrukturen werden für jede virtuelle Maschine separat verwaltet.
Die meisten Anweisungen werden direkt auf der physischen CPU ausgeführt.
Dadurch können ressourcenintensive Arbeitslasten bei nahezu nativer
Geschwindigkeit ausgeführt werden. Privilegierte Anweisungen werden von der
Virtualisierungsebene sicher ausgeführt.
Weitere Informationen finden Sie im Handbuch zum Ressourcen-Management.
VMware, Inc.
19

Speichervirtualisierung - Ein angrenzender Speicherbereich ist für jede
virtuelle Maschine sichtbar. Der zugewiesene physische Speicher ist jedoch unter
Umständen nicht angrenzend. Stattdessen werden nicht angrenzende physische
Seiten erneut zugeordnet und jeder virtuellen Maschine präsentiert. Bei
ungewöhnlich speicherintensiven Lasten wird der Serverspeicher überlastet.
In diesem Fall kann ein gewisser Anteil des physischen Speichers einer virtuellen
Maschine gemeinsam genutzten Seiten, nicht zugeordneten Seiten oder
ausgelagerten Seiten zugeordnet werden.
ESX Server führt diese virtuelle Speicherverwaltung ohne Wissen des
Gastbetriebssystems aus und ohne das eigene Speicherverwaltungssubsystem
des Gastbetriebssystems zu stören.

Netzwerkvirtualisierung - Die Virtualisierungsebene stellt sicher, dass jede
virtuelle Maschine von anderen virtuellen Maschinen isoliert ist. Virtuelle
Maschinen können nur über Networking-Mechanismen miteinander
kommunizieren, die den Mechanismen ähneln, die zum Verbinden separater
physischer Rechner verwendet werden.
Durch die Isolierung können Administratoren interne Firewalls oder andere
Netzwerkisolierungsumgebungen einrichten. So können einige virtuelle
Maschinen eine externe Verbindung herstellen, während andere nur über
virtuelle Netzwerke oder andere virtuelle Maschinen verbunden werden.
Weitere Informationen finden Sie im Handbuch zur Server-Konfiguration.
Virtual SCSI
In einer ESX Server-Umgebung enthält jede virtuelle Maschine einen bis vier virtuelle
SCSI-HBAs (Host-Bus-Adapter). Diese virtuellen Adapter können als Buslogic- oder
LSI Logic-SCSI-Controller angezeigt werden. Dies sind die einzigen Arten von
SCSI-Controllern, auf die eine virtuelle Maschine zugreifen kann.
Jede virtuelle Festplatte, auf die eine virtuelle Maschine über einen der virtuellen
SCSI-Adapter zugreifen kann, residiert im VMFS oder auf einer Raw-Festplatte.
20

„Festplattenkonfigurationsoptionen“ auf Seite 21.

„Virtual Machine File System (VMFS)“ auf Seite 22.

„Raw Device Mapping“ auf Seite 23.

„Virtuelle SCSI-HBA“ auf Seite 23.
VMware, Inc.
Abbildung 1-3 bietet einen Überblick über die Speichervirtualisierung. Es wird
Speicher unter Verwendung von VMFS sowie Speicher unter Verwendung des
Raw Device Mapping dargestellt.
ESX Server
Virtuelle Maschine
1
SCSI-Controller
(Buslogic oder LSI Logic)
Virtuelle Festplatte 1
HBA
VMFS
LUN1
LUN2
.dsk
RDM
LUN5
Abbildung 1-3. SAN-Speichervirtualisierung
Festplattenkonfigurationsoptionen
Sie können virtuelle Maschinen mit mehreren virtuellen SCSI-Geräten konfigurieren.
Eine Liste der unterstützten Treiber finden Sie im Storage/SAN Compatibility Guide unter
www.vmware.com/support/pubs/vi_pubs.html. Das Gastbetriebssystem kann die
Gesamtanzahl der SCSI-Laufwerke beschränken.
Obwohl alle SCSI-Geräte als SCSI-Ziele dargestellt werden, gibt es drei physische
Implementierungsalternativen:

.vmdk-Datei der virtuellen Maschine wird auf einem VMFS-Volume gespeichert.
Siehe „Virtual Machine File System (VMFS)“ auf Seite 22.

Device wird einer SAN-LUN (logische Gerätenummer) zugeordnet. Siehe „Raw
Device Mapping“ auf Seite 23.

Das lokale SCSI-Gerät wird direkt an die virtuelle Maschine übergeben
(z. B. ein lokales Bandlaufwerk).
VMware, Inc.
21
Aus Sicht der virtuellen Maschine wird jede virtuelle Festplatte so angezeigt,
als wäre sie ein an einen SCSI-Adapter angeschlossenes SCSI-Laufwerk. Das
Gastbetriebssystem und Anwendungen, die auf der virtuellen Maschine ausgeführt
werden, können nachvollziehen, ob der Zugriff auf das eigentliche physische über
SCSI-, iSCSI-, RAID-, NFS- oder Fibre Channel(FC)-Controller erfolgt.
Virtual Machine File System (VMFS)
In einer einfachen Konfiguration sind die Festplatten der virtuellen Maschine als
Dateien in einem VMFS gespeichert. Wenn Gastbetriebssysteme SCSI-Befehle an ihre
virtuellen Festplatten ausgeben, übersetzt die Virtualisierungsebene diese Befehle in
VMFS-Dateivorgänge.
ESX Server-Systeme verwenden VMFS zum Speichern von Dateien virtueller
Maschinen. Um den I/O-Overhead der Festplatte zu minimieren, wurde VMFS so
optimiert, dass mehrere virtuelle Maschinen als eine Arbeitslast ausgeführt werden.
Außerdem bietet VMFS verteilte Sperren für die Dateien Ihrer virtuellen Maschine,
sodass diese in einer SAN-Umgebung, in der mehrere ESX Server-Hosts eine Reihe von
LUNs gemeinsam nutzen, sicher betrieben werden kann.
VMFS wird zunächst als Bestandteil der ESX Server-Installation konfiguriert. Wenn Sie
ein neues VMFS-3-Volume erstellen, muss dieses mindestens 600 MB groß sein. Siehe
Handbuch für Installation und Upgrade. Anschließend kann das VMFS angepasst werden,
wie im Handbuch zur Server-Konfiguration erläutert.
Ein VMFS-Volume kann über 32 physische Speichererweiterungen erweitert werden,
darunter SAN-LUNs und lokaler Speicher. Dies ermöglicht das Pooling von Speicher
und Flexibilität beim Erstellen des für Ihre virtuelle Maschine erforderlichen
Speicher-Volumes. Mit dem neuen ESX3 Logical Volume Manager (LVM) können Sie
ein Volume erweitern, während virtuelle Maschinen auf dem Volume ausgeführt
werden. Dadurch können Sie neuen Speicher zu Ihren VMFS-Volumes hinzufügen,
wenn die virtuelle Maschine den Speicher benötigt.
Weitere Informationen finden Sie in den folgenden Kapiteln:
22

Kapitel 3, „Voraussetzungen und Installation,“ auf Seite 53. In diesem Kapitel
werden HBAs und Speichergeräte aufgelistet, die von ESX Server-Systemen
unterstützt werden.

Kapitel 4, „Einrichten von SAN-Speicher-Devices mit ESX Server,“ auf Seite 61.
Dieses Kapitel enthält Informationen zum Konfigurieren von SAN-Komponenten.
VMware, Inc.
Raw Device Mapping
Ein Raw Device Mapping (RDM) ist eine spezielle Datei in einem VMFS-Volume,
die als Proxy für ein Raw-Device fungiert. Das RDM bietet einige der Vorteile einer
virtuellen Festplatte im VMFS-Dateisystem und behält einige Vorteile des
Direktzugriffs auf physische Geräte bei.
RDM kann erforderlich sein, wenn Sie Microsoft Cluster Service (MSCS) verwenden
oder SAN-Snapshot oder andere Anwendungen mit mehreren Ebenen auf der
virtuellen Maschine ausführen. Mithilfe von RDMs können Systeme die in SAN-Arrays
enthaltenen Hardware-Funktionen besser nutzen. Weitere Informationen finden Sie
unter „Verwenden von Raw Device Mapping“ im Handbuch zur Server-Konfiguration.
Informationen über MSCS finden Sie im Dokument Einrichtung des Microsoft
Cluster-Dienstes.
Virtuelle SCSI-HBA
Mit virtuellen SCSI-HBAs können virtuelle Maschinen auf logische SCSI-Geräte
zugreifen, ebenso wie ein physischer HBA den Zugriff auf physische Speichergeräte
ermöglicht. Im Gegensatz zum physischen HBA ermöglicht der SCSI-HBA
Speicheradministratoren (wie z. B. SAN-Administratoren) keinen Zugriff auf den
physischen Rechner. Gleichzeitig können zahlreiche virtuelle HBAs hinter einem (oder
mehreren) FC-HBAs ausgeblendet werden. Der SAN sieht nur den physischen Rechner
und dessen HBAs.
Interaktion mit ESX Server-Systemen
Im Allgemeinen können Administratoren eine der folgenden Möglichkeiten für die
Interaktion mit ESX Server-Systemen nutzen:

Verwenden eines Clients (VI-Client oder VI Web Access), wie in „Einführung in
ESX Server“ auf Seite 16 erläutert. Clients können direkt mit dem ESX Server-Host
verbunden werden, oder Sie können mit dem VirtualCenter-Management-Server
mehrere ESX Server-Hosts gleichzeitig verwalten.
Weitere Informationen zum VirtualCenter-Management-Server finden Sie unter
„VMware Virtual Center“ auf Seite 24.

Verwenden der Service-Konsole. Beachten Sie, dass die Verwendung der
Service-Konsole in ESX Server 3.0 und höher im Allgemeinen nicht erforderlich
und nicht erwünscht ist, da die meisten administrativen Vorgänge mit einem
VI-Client oder VI Web Access ausgeführt werden können. Verwenden Sie Virtual
Infrastructure SDK für das Skript-Management.
Weitere Informationen zur Service-Konsole finden Sie unter „Service-Konsole“
auf Seite 25.
VMware, Inc.
23
VMware Virtual Center
Sie können über einen VI-Client oder über VI Web Access auf einen
VirtualCenter-Server zugreifen.

Der VirtualCenter-server fungiert als zentraler Administrator für VMware-Server,
die über ein Netzwerk miteinander verbunden sind. Der Server leitet Aktionen an
die virtuellen Maschinen und VMware ESX Server weiter.

Die Benutzeroberfläche des VI-Clients wird unter Microsoft Windows ausgeführt.
In einer Umgebung mit mehreren Hosts können Administratoren den VI-Client
verwenden, um Anforderungen an den VirtualCenter-Server zu stellen. Dies
wirkt sich wiederum auf die virtuellen Maschinen und Hosts aus. Die direkte
Verbindung zu einem ESX Server-Host ist normalerweise nur in einer Umgebung
mit einem Server sinnvoll.

Mit VI Web Access können Sie unter Verwendung eines HTML-Browsers eine
Verbindung zu einem VirtualCenter-Server herstellen.
In Abbildung 1-4 ist die Registerkarte Konfiguration einer VI-Client-Anzeige
dargestellt, wenn Speicher ausgewählt ist. Der ausgewählte ESX Server-Host stellt eine
Verbindung zu beiden SAN-LUNs und zu lokalen Festplatten her. Der Unterschied
in der Anzeige ist nur aufgrund der Namen sichtbar, die während des Setup
gewählt wurden.
Abbildung 1-4. Anzeige von Speicherdaten im VI-Client, Registerkarte Konfiguration
24
VMware, Inc.
Service-Konsole
Die Service-Konsole ist die ESX Server-Schnittstelle für das Befehlszeilenmanagement.
In früheren Versionen von ESX Server war die Service-Konsole die Hauptschnittstelle
zum ESX Server-Host. Ab der Version ESX Server 3 hat der VI-Client Priorität,
obwohl die Service-Konsole immer noch eingesetzt werden kann, um bestimmte
erweiterte Verwaltungsvorgänge durchzuführen. Die Service-Konsole unterstützt
Systemmanagementfunktionen und –schnittstellen des ESX Server-Systems. Dazu
gehören HTTP-, SNMP- und API-Schnittsellen sowie andere Supportfunktionen,
wie z. B. Authentifizierung und Zugriff auf leistungsschwache Geräte.
Da die VirtualCenter-Funktionen verbessert wurden und nahezu alle administrativen
Vorgänge ermöglichen, ist die Funktionalität der Service-Konsole eingeschränkt.
Die Service-Konsole wird nur unter bestimmten Bedingungen verwendet.
HINWEIS Verwenden Sie Virtual Infrastructure SDK für das Skript-Management. Befehle
der Service-Konsole sind in zukünftigen Versionen unter Umständen nicht mehr
verfügbar oder führen zu anderen Ergebnissen.
Die Service-Konsole wird mit einer modifizierten Linux-Distribution implementiert.
Die Service-Konsole entspricht jedoch nicht direkt einer
Linux-Befehlseingabeaufforderung.
Weitere Informationen finden Sie unter „Prozesse und Services der Service-Konsole“
auf Seite 25.
Prozesse und Services der Service-Konsole
Die folgenden Managementprozesse und -services von ESX Server werden in der
Service-Konsole ausgeführt:

Host-Daemon (hostd) - Führt im Auftrag der Service-Konsole und des VI-Clients
Aktionen in der Service-Konsole aus.

Authentifizierungs-Daemon (vmauthd) - Authentifiziert Remote-Anwender des
VI-Clients und Remote-Konsolen mithilfe der Datenbank mit den Anwendernamen
und Kennwörtern. Alle anderen Authentifizierungsspeicher, auf die über die
PAM-Funktionen (Pluggable Authentication Module) der Service-Konsole
zugegriffen werden kann, können ebenfalls verwendet werden. Die Verwendung
mehrerer Mechanismen zum Speichern von Kennwörtern ermöglicht den
Einsatz von Kennwörtern von einem Windows-Domain-Controller, LDAP- oder
RADIUS-Server oder einem ähnlichen zentralen Authentifizierungsspeicher in
Verbindung mit VMware ESX Server für den Remote-Zugriff.

SNMP-Server (net-snmpd) - Implementiert die SNMP-Traps und
Datenstrukturen, mit denen ein Administrator ein ESX Server-System in ein
SNMP-basiertes Systemmanagement-Tool integrieren kann.
VMware, Inc.
25
Neben diesen von VMware bereitgestellten Services kann die Service-Konsole zum
Ausführen anderer systemweiter oder Hardware-abhängiger Management-Tools
verwendet werden. Dazu können Hardware-spezifische Tools zur Statusüberwachung
(wie z. B. IBM Director oder HP Insight Manager), Software für vollständige
System-Backups und Disaster Recovery sowie Clustering- und
Hochverfügbarkeitsprodukte gehören.
HINWEIS Die Verfügbarkeit der Service-Konsole für die allgemeine
Linux-Hardware-Überwachung wird nicht gewährleistet. Sie ist kein Äquivalent
einer Linux-Shell.
Virtualisierung im Überblick
ESX Server virtualisiert die Ressourcen des physischen Systems für die
Verwendung durch die virtuellen Maschinen. Mehrere virtuelle Maschinen nutzen
physische Geräte gemeinsam.
Virtuelle Maschine 1
Arbeitsspeicher
CPU
Virtuelle Maschine 2
Netzwer- Fest- Festkadapter platte 1 platte 2
FestFestplatte 1 platte 2
Netzwerkadapter
CPU
Arbeitsspeicher
VMFS
Raw-Festplatte
SpeicherArray
network adapter
CPU
Arbeitss- Physische
peicher Ressourcen
Abbildung 1-5. Gemeinsame Nutzung physischer Ressourcen durch
virtuelle Maschinen
26
VMware, Inc.
In Abbildung 1-5 sind zwei virtuelle Maschinen dargestellt, die jeweils wie folgt
konfiguriert sind:

Eine CPU

Zuweisung von Speicher und ein Netzwerkadapter (NIC)

Zwei virtuelle Festplatten
Die virtuellen Maschinen verwenden jeweils eine der CPUs auf dem Server und greifen
auf nicht angrenzende Speicherseiten zu, wobei ein Teil des Speichers einer virtuellen
Maschine derzeit auf Festplatte ausgelagert ist (nicht dargestellt). Die zwei virtuellen
Netzwerkadapter sind mit zwei physischen Netzwerkadaptern verbunden.
Die Festplatten sind wie folgt zugeordnet:

Festplatte 1 der virtuellen Maschine 1 ist direkt einer Raw-Festplatte zugeordnet.
Diese Konfiguration ist im Normalfall nicht empfehlenswert, kann unter
bestimmten Bedingungen jedoch vorteilhaft sein.

Festplatte 2 der virtuellen Maschine 1 und beide Festplatten der virtuellen
Maschine 2 residieren auf dem VMFS, das sich auf einem SAN-Speicher-Array
befindet. VMFS stellt sicher, dass entsprechende Sperren und Sicherheit jederzeit
aktiviert sind.
VMware, Inc.
27
28
VMware, Inc.
2
Verwenden von
ESX Server mit SAN
2
Bei der Einrichtung von ESX Server-Hosts für die Verwendung mit FC-SAN-Arrays
müssen bestimmte Dinge beachtet werden. Dieses Kapitel enthält grundlegende
Informationen zur Verwendung von ESX Server mit einem SAN-Array und behandelt
die folgenden Themen:

„SAN-Konzepte“ auf Seite 30.

„Überblick über die Verwendung von ESX Server mit SAN“ auf Seite 32.

„Besonderheiten der Verwendung von SAN-Arrays mit ESX Server“ auf Seite 35.

„Grundlegendes zu VMFS- und SAN-Speicheroptionen“ auf Seite 40.

„Grundlegendes zum Datenzugriff“ auf Seite 43.

„Pfad-Management und Failover“ auf Seite 46.

„Auswahl der Speicherorte virtueller Maschinen“ auf Seite 48.

„Präventionsmaßnahmen gegen Server-Ausfälle“ auf Seite 49.

„Optimieren der Ressourcen-Nutzung“ auf Seite 51.
VMware, Inc.
29
SAN-Konzepte
Wenn Sie als ESX Server-Administrator die Einrichtung von ESX Server-Hosts in einem
SAN planen, benötigen Sie fundierte Kenntnisse über SAN-Konzepte. Informationen
über SAN finden Sie sowohl in Büchern bzw. Fachzeitschriften als auch im Internet.
Zwei Internetressourcen werden von der SAN-Branche aufgrund Ihres umfangreichen
Informationsangebots besonders empfohlen:

www.searchstorage.com

www.snia.org
Da die SAN-Branche dem schnellen Wandel unterlegen ist, sollten Sie diese Ressourcen
regelmäßig nutzen, um sich über die neuesten Entwicklungen zu informieren.
Falls Sie noch keine Erfahrungen auf dem Gebiet der SAN-Technologie sammeln
konnten, haben Sie im folgenden Abschnitt die Gelegenheit, sich mit einigen Begriffen
vertraut machen, die in diesem Handbuch verwendet werden. Informationen über
grundlegende SAN-Konzepte finden Sie im White Paper SAN Conceptual and Design
Basics unter http://www.vmware.com/support/pubs.
HINWEIS SAN-Administratoren können diesen Abschnitt überspringen und mit dem Rest des
Kapitels fortfahren.
Ein SAN (Storage Area Network) ist ein spezialisiertes
Hochgeschwindigkeitsnetzwerk, das Computersysteme oder Host-Server mit
leistungsstarken Speichersubsystemen verbindet. Die SAN-Komponenten umfassen
Host-Bus-Adapter (HBAs) in den Host-Servern, Switches zur Weiterleitung von
Speicherdaten, Kabel, Speicherprozessoren (SPs) und Speicher-Festplatten-Arrays.
Eine SAN-Topologie mit mindestens einem Switch bildet einen SAN-Fabric.
Zur Datenübertragung von den Host-Servern zum gemeinsamen Speicher
verwendet das SAN ein Fibre-Channel (FC)-Protokoll, über das SCSI-Befehle in
Fibre-Channel-Frames gepackt werden.
Im vorliegenden Dokument wird die Verbindung von einem Device zum SAN als Port
bezeichnet. Jeder Node im SAN, d. h. Host, Speicher-Device und Fabric-Komponente,
ist über einen oder mehrere Ports mit dem SAN verbunden. Ports können auf
verschiedene Arten identifiziert werden:

30
WWPN – World Wide Port Name. Ein weltweit eindeutiger Bezeichner für
einen Port, über den bestimmte Anwendungen auf den Port zugreifen können.
Die FC-Switches erkennen den WWPN eines Devices oder Hosts und weisen ihm
eine Port-Adresse zu.
VMware, Inc.
Kapitel 2 Verwenden von ESX Server mit SAN
Um den WWPN mit einem VI-Client anzuzeigen, klicken Sie auf die
Host-Registerkarte Konfiguration und wählen die Option Storage-Adapter.
Anschließend können Sie den Speicheradapter auswählen, dessen WWPN Sie
anzeigen möchten.

Port-ID (oder Port-Adresse) – Im SAN verfügt jeder Port über eine eindeutige ID,
die als FC-Adresse für den Port fungiert. Dadurch ist es möglich, Daten über das
SAN zum entsprechenden Port weiterzuleiten. Die FC-Switches weisen die
Port-ID zu, wenn sich das Device beim Fabric anmeldet. Die Port-ID ist nur gültig,
solange das Device angemeldet ist.
Bei der Datenübertragung zwischen Host-Server und Speicher verwendet das SAN ein
Multipathing-Verfahren. Durch Multipathing können mehrere physische Pfade vom
ESX Server-Host zu einer LUN in einem Speicher-Array führen.
Wenn ein Standardpfad oder eine der Komponenten im Pfad – HBA, Kabel,
Switch-Port oder Speicherprozessor – ausfällt, wählt der Server einen anderen
verfügbaren Pfad. Der Prozess der Erkennung eines ausgefallenen Pfads und der
Wechsel zu einem anderen Pfad wird als Pfad-Failover bezeichnet.
Es gibt folgende Arten von Speicher-Festplatten-Arrays:

Ein Aktiv/Aktiv-Festplatten-Array ermöglicht den gleichzeitigen Zugriff auf die
LUNs über alle verfügbaren Speicherprozessoren, ohne dass die Performance
wesentlich beeinträchtigt wird. Alle Pfade sind permanent aktiv (sofern kein
Pfad ausfällt).

In einem Aktiv/Passiv-Festplatten-Array verwaltet ein SP aktiv den Zugriff auf
eine bestimmte LUN. Der andere SP fungiert als Reserve für die LUN und kann
andere LUN-I/Os aktiv verwalten. I/Os können nur an einen aktiven Prozessor
gesendet werden. Wenn der primäre Speicherprozessor ausfällt, wird einer der
anderen Speicherprozessoren aktiv, entweder automatisch oder durch Eingreifen
des Administrators.
Um den Serverzugriff auf Speicher-Arrays zu beschränken, die diesem Server nicht
zugewiesen sind, verwendet das SAN Zoning. Normalerweise werden Zonen für jede
Gruppe von Servern erstellt, die auf eine gemeinsame Gruppe von Speicher-Devices
und LUNs zugreifen. Zonen definieren, welche HBAs eine Verbindung mit bestimmten
SPs herstellen können. Devices außerhalb einer Zone sind gegenüber Devices innerhalb
der Zone nicht sichtbar.
VMware, Inc.
31
Zoning ist vergleichbar mit der LUN-Maskierung, die in der Regel für das
Genehmigungs-Management verwendet wird. Bei der LUN-Maskierung handelt es
sich um einen Prozess, der eine LUN für einige Hosts verfügbar macht, für andere
Hosts hingegen nicht. Normalerweise wird die LUN-Maskierung auf SP- oder
Serverebene ausgeführt.
Überblick über die Verwendung von ESX Server mit SAN
Die Unterstützung von QLogic- und Emulex-FC-HBAs ermöglicht es, ein
ESX Server-System mit einem SAN-Array zu verbinden. Anschließend können
LUNs im SAN-Array zum Speichern von Konfigurationsinformationen und
Anwendungsdaten virtueller Maschinen verwendet werden. Die Verwendung von
ESX Server in einem SAN äußert sich in einer höheren Flexibilität, Effizienz und
Zuverlässigkeit. Darüber hinaus unterstützt diese Konfiguration zentralisiertes
Management, Failover und Technologien für den Lastausgleich.
Weitere Informationen finden Sie in folgenden Abschnitten:

„Vorteile der Verwendung von ESX Server mit SAN“ auf Seite 32.

„Anwendungsbeispiele“ auf Seite 33.

„Informationssuche“ auf Seite 34.
Vorteile der Verwendung von ESX Server mit SAN
Ein SAN mit ESX Server ermöglicht es Ihnen, die Ausfallsicherheit Ihrer
Umgebung zu verbessern:
32

Sie können Daten redundant speichern und mehrere FC-Fabrics konfigurieren,
um einen Single-Point-of-Failure auszuschließen. Ihr Unternehmen wird nicht
lahm gelegt, wenn ein Rechenzentrum ausfällt.

ESX Server-Systeme bieten standardmäßig Multipathing und unterstützen es
automatisch für jede virtuelle Maschine. Weitere Informationen finden Sie unter
„Pfad-Management und Failover“ auf Seite 46.

Bei Verwendung von ESX Server-Systemen wird die Ausfallsicherheit auf den
Server erweitert. Wenn Sie einen SAN-Speicher verwenden, können alle
Anwendungen nach einem Host-Ausfall unverzüglich neu gestartet werden.
Weitere Informationen finden Sie unter „Präventionsmaßnahmen gegen
Server-Ausfälle“ auf Seite 49.
VMware, Inc.
Bei Verwendung von ESX Server mit einem SAN sind Hochverfügbarkeit und
automatischer Lastausgleich für mehr Anwendungen erschwinglich als bei
Verwendung von dedizierter Hardware, die für Standby-Services reserviert ist.

Da ein gemeinsam genutzter zentraler Speicher verfügbar ist, können Cluster aus
virtuellen Maschinen gebildet werden, die MSCS verwenden. Weitere
Informationen finden Sie unter „Server-Failover und Speicheraspekte“ auf Seite 51.

Wenn virtuelle Maschinen als Standby-Systeme für physische Server verwendet
werden, ist ein gemeinsamer Speicher unerlässlich und ein SAN die beste Lösung.

Sie können die VMware VMotion-Funktionen verwenden, um virtuelle Maschinen
nahtlos von einem Host zum nächsten zu migrieren.

Sie können VMware HA in Verbindung mit einem SAN als Cold-Standby-Lösung
verwenden, die eine automatische Antwort ohne Verzögerung garantiert.

Sie können VMware DRS verwenden, um virtuelle Maschinen zum Lastausgleich
automatisch von einem Host zum nächsten zu migrieren. Da sich der Speicher in
einem SAN-Array befindet, werden die Anwendungen unterbrechungsfrei
weiter ausgeführt.

Wenn Sie VMware DRS-Cluster verwenden, können Sie einen ESX Server-Host im
Wartungsmodus ausführen, damit das System alle aktiven virtuellen Maschinen
auf andere ESX Server-Hosts migriert. Anschließend können Sie Upgrades oder
Wartungsarbeiten vornehmen.
Die Transportfähigkeit und Verkapselung von virtuellen VMware-Maschinen tragen
zur gemeinsamen Nutzung eines SAN-Speichers bei. Wenn sich virtuelle Maschinen
in einem SAN-basierten Speicher befinden, ist es möglich, innerhalb von wenigen
Minuten eine virtuelle Maschine auf einem Server herunterzufahren und auf einem
anderen Server wieder hochzufahren – oder auf einem Server anzuhalten und auf
einem anderen Server im gleichen Netzwerk weiter auszuführen. Dadurch können
Sie Rechenressourcen migrieren, ohne auf einen konsistenten gemeinsamen Zugriff
verzichten zu müssen.
Anwendungsbeispiele
Die Verwendung von ESX Server-Systemen in Verbindung mit SAN bietet sich
besonders für folgende Aufgaben an:

Ausfallfreie Wartungen – Bei der Durchführung von Wartungen können Sie
virtuelle Maschinen mit VMware DRS oder VMotion auf andere Server migrieren.
Wenn das SAN einen gemeinsamen Speicher umfasst, können Sie
Wartungsarbeiten vornehmen, ohne dass der Anwender dies bemerkt.
VMware, Inc.
33

Lastausgleich – Sie können VMotion oder VMware DRS verwenden, um virtuelle
Maschinen zum Lastausgleich auf andere Hosts zu migrieren. Wenn das SAN
einen gemeinsamen Speicher umfasst, können Sie den Lastausgleich vornehmen,
ohne dass der Anwender dies bemerkt.

Speicherkonsolidierung und Vereinfachung des Speicherlayouts – Wenn Sie mit
mehreren Hosts arbeiten und auf jedem Host mehrere virtuelle Maschinen
ausgeführt werden, reicht der Speicher des Hosts nicht aus, und Sie benötigen
einen externen Speicher. Ein SAN als externer Speicher vereinfacht die
Systemarchitektur und bietet Ihnen alle sonstigen in diesem Abschnitt genannten
Vorteile. Sie können zunächst eine große LUN reservieren und anschließend Teile
nach Bedarf auf die virtuellen Maschinen verteilen. Die LUN-Reservierung und
-Erstellung über das Speicher-Device muss nur einmal durchgeführt werden.

Disaster Recovery – Das Speichern aller Daten in einem SAN kann die
Remote-Speicherung von Daten-Backups deutlich vereinfachen. Darüber hinaus
können Sie virtuelle Maschinen auf entfernten ESX Server-Hosts zu
Recovery-Zwecken neu starten, wenn ein Standort ausfällt.
Informationssuche
Neben diesem Dokument bieten Ihnen zahlreiche andere Ressourcen Unterstützung
bei der Konfiguration Ihres ESX Server-Systems mit einem SAN.

Die meisten Fragen zur Einrichtung beantwortet Ihnen die Dokumentation zu
Ihrem Speicher-Array. Möglicherweise hält der Anbieter Ihres Speicher-Arrays
auch Informationen zur Verwendung des Speicher-Arrays in einer
ESX Server-Umgebung für Sie bereit.

VMware I/O Compatibility Guide – Enthält eine Liste der zurzeit unterstützten
HBAs, HBA-Treiber und Treiberversionen.

VMware Storage/SAN Compatibility Guide – Enthält eine Liste der zurzeit
unterstützten Speicher-Arrays.

VMware-Versionshinweise – Liefern Informationen über bekannte Probleme und
deren Lösungen.

VMware-Wissensbasis – Enthält Informationen über allgemeine Probleme und
deren Lösungen.
Weitere Informationen finden Sie auf der VMware Documentation-Website unter
http://www.vmware.com/support/pubs/.
34
VMware, Inc.
Besonderheiten der Verwendung von SAN-Arrays mit
ESX Server
Die Verwendung eines SANs in Verbindung mit einem ESX Server-Host unterscheidet
sich in vieler Hinsicht von der herkömmlichen SAN-Nutzung, wie im folgenden
Abschnitt beschrieben:

„Gemeinsame Nutzung eines VMFS auf mehreren ESX Server-Systemen“.

„Metadaten-Aktualisierungen“ auf Seite 36.

„LUN-Anzeige und erneutes Scannen“ auf Seite 37.

„Host-Typ“ auf Seite 37.

„Komplexitätsebenen“ auf Seite 37.

„Datenzugriff: VMFS oder RDM“ auf Seite 38.

„Management-Anwendungen von Drittanbietern“ auf Seite 39.
Gemeinsame Nutzung eines VMFS auf mehreren
ESX Server-Systemen
ESX Server VMFS wurde für den gleichzeitigen Zugriff über mehrere physische
Rechner konzipiert und übernimmt die Zugriffskontrolle für Dateien auf virtuellen
Maschinen. Weitere Informationen über VMFS finden Sie unter „Virtual Machine File
System (VMFS)“ auf Seite 22 sowie im Handbuch zur Server-Konfiguration.
VMFS übernimmt folgende Aufgaben:

Koordination des Zugriffs auf virtuelle Festplattendateien – ESX Server verwendet
Sperren auf Dateiebene, die vom VMFS Distributed Lock Manager verwaltet werden.

Koordination des Zugriffs auf interne VMFS-Dateisysteminformationen
(Metadaten) – ESX Server verwendet SCSI-Reservierungen für die gesamte LUN.
Weitere Informationen finden Sie unter „Metadaten-Aktualisierungen“ auf Seite 36.
HINWEIS SCSI-Reservierungen werden bei Metadaten-Aktualisierungen des VMFS-Volumes
nicht beibehalten. ESX Server verwendet temporäre SCSI-Reservierungen als Teil
seines verteilten Sperrprotokolls.
Da virtuelle Maschinen ein VMFS gemeinsames verwenden, kann es schwierig sein,
Zeiten höchster Auslastung zu bestimmen oder die Performance zu optimieren.
Einerseits müssen Sie den Speicherzugriff virtueller Maschinen für Zeiten höchster
Auslastung planen, andererseits sind diese unter Umständen von Anwendung zu
Anwendung verschieden. Je mehr virtuelle Maschinen ein VMFS gemeinsam
verwenden, desto höher ist die Gefahr einer möglichen Verschlechterung der
Performance aufgrund von I/O-Kollisionen.
VMware, Inc.
35
HINWEIS VMware empfiehlt, dass Sie den Datenverkehr virtueller Maschinen auf Server,
CPU und Speicher aufteilen. Sie sollten auf jedem Server einen Mix virtueller
Maschinen ausführen, sodass nicht alle zur selben Zeit im selben Bereich einer hohen
Nachfrage unterliegen.
Abbildung 2-1 zeigt mehrere ESX Server-Systeme, die das gleiche
VMFS-Volume verwenden.
ESX
Server A
ESX
Server B
ESX
Server C
VM1
VM2
VM3
VMFS-Volumen
Festplatte1
Virtuelle
Fest- Festplattplatte2
endateien
Festplatte3
Abbildung 2-1. Zugriff auf virtuelle Festplattendateien
Metadaten-Aktualisierungen
Ein VMFS enthält u. a. Dateien, Verzeichnisse, symbolische Links, RDMs sowie
entsprechende Metadaten für diese Objekte. Ein Zugriff auf die Metadaten findet
immer dann statt, wenn die Attribute einer Datei aufgerufen oder geändert werden.
Dies ist unter anderem bei folgenden Aktionen der Fall:
36

Erstellen, Erweitern oder Sperren einer Datei

Ändern der Dateiattribute

Ein- und Ausschalten virtueller Maschinen
VMware, Inc.
LUN-Anzeige und erneutes Scannen
Ein SAN ist dynamisch, d. h. welche LUNs für einen bestimmten Host verfügbar sind,
hängt von zahlreichen Faktoren ab, beispielsweise folgenden:

Erstellung neuer LUNs in den SAN-Speicher-Arrays.

Änderungen an der LUN-Maskierung.

Änderungen an der SAN-Konnektivität oder anderen Aspekten im
Zusammenhang mit der SAN .
Der VMkernel erkennt LUNs beim Hochfahren. Diese LUNs sind daraufhin im
VI-Client sichtbar. Wenn Änderungen an den LUNs vorgenommen werden, müssen
Sie erneut scannen, um die Änderungen zu sehen.
Host-Typ
Eine LUN kann sich abhängig davon, welcher Host-Typ auf sie zugreift,
anders verhalten. Normalerweise betrifft die Zuweisung des Host-Typs
betriebssystemspezifische Funktionen oder Probleme. ESX Server-Systeme werden
für gewöhnlich mit einem Linux-Host-Typ für den LUN-Zugriff konfiguriert.
Weitere Informationen finden Sie in Kapitel 6, „Verwalten von ESX Server-Systemen,
die SAN-Speicher verwenden,“ auf Seite 87 und in der VMware-Wissensbasis.
Komplexitätsebenen
Wenn Sie bisher mit herkömmlichen SANs gearbeitet haben, können die
Komplexitätsebenen anfangs verwirrend sein.

Ein direkter Zugriff auf das Betriebssystem virtueller Maschinen im SAN ist nicht
möglich. Mit herkömmlichen Tools können Sie nur das Betriebssystem von
VMware ESX Server überwachen (jedoch nicht das Betriebssystem virtueller
Maschinen). Zum Überwachen virtueller Maschinen verwenden Sie den VI-Client.

Jede virtuelle Maschine wird bei der Installation standardmäßig mit einer
(virtuellen) Festplatte und einem (virtuellen) SCSI-Controller konfiguriert.
Sie können den SCSI-Controller-Typ und die Eigenschaften für die gemeinsame
SCSI-Bus-Verwendung ändern, indem Sie die Einstellungen virtueller Maschinen
mit dem VI-Client bearbeiten (siehe Abbildung 2-2). Darüber hinaus können Sie
einer virtuellen Maschine Festplatten hinzufügen. Weitere Informationen finden
Sie im Handbuch zur Server-Konfiguration.
VMware, Inc.
37
Abbildung 2-2. Festlegen des SCSI-Controller-Typs

Der HBA, den die Tools für die SAN-Administration erkennen, ist Teil des
ESX Server-Systems, nicht der virtuellen Maschine.

Das ESX Server-System führt Multipathing durch. Multipathing-Software
(z. B. PowerPath) auf der virtuellen Maschine wird nicht unterstützt (und nicht
benötigt). Eine Ausnahme ist Multipathing-Software für dynamische Festplatten
in virtuellen Windows-Maschinen.
Datenzugriff: VMFS oder RDM
Standardmäßig wird eine virtuelle Festplatte in einem VMFS-Volume während der
Erstellung einer virtuellen Maschine erstellt. Wenn Gastbetriebssysteme SCSI-Befehle
an ihre virtuellen Festplatten ausgeben, übersetzt die Virtualisierungsebene diese
Befehle in VMFS-Dateivorgänge. Weitere Informationen finden Sie unter „Virtual
Machine File System (VMFS)“ auf Seite 22.
Eine Alternative zu VMFS bieten RDMs. RDMs sind spezielle Dateien in einem
VMFS-Volume, die als Proxy für ein Raw Device fungieren. Bei Verwendung von
RDMs gehen einige Vorteile einer virtuellen Festplatte im VMFS zwar verloren, einige
Vorteile des direkten Zugriffs auf ein physisches Device bleiben jedoch erhalten.
Weitere Informationen finden Sie unter „Raw Device Mapping“ auf Seite 23.
38
VMware, Inc.
Management-Anwendungen von Drittanbietern
Die meisten SAN-Hardware-Komponenten werden mit entsprechender
SAN-Management-Software geliefert. Diese Software wird normalerweise im
Speicher-Array oder auf einem einzelnen Server ausgeführt, und zwar unabhängig von
den Servern, die das SAN zum Speichern verwenden. Sie können die
Management-Software von Drittanbietern für verschiedene Aufgaben verwenden:

Speicher-Array-Management, einschließlich LUN-Erstellung,
Array-Cache-Management, LUN-Zuordnung und LUN-Sicherheit

Einrichtung von Replikation, Checkpointing, Snapshotting oder Spiegelung
Wenn Sie die SAN-Management-Software auf einer virtuellen Maschine ausführen,
profitieren Sie von den damit verbundenen Vorteilen (Failover mit VMotion, Failover
mit VMware HA usw.). Es ist jedoch möglich, dass die Management-Software das SAN
aufgrund der zusätzlichen Komplexitätsebene nicht erkennt. Dieses Problem kann
durch Verwendung von RDMs behoben werden. Weitere Informationen finden Sie
unter „Anwendungen mit mehreren Ebenen“ auf Seite 121.
HINWEIS Ob Management-Software auf einer virtuellen Maschine ausgeführt werden kann,
hängt vom jeweiligen Speicher-Array ab.
Zoning und ESX Server
Zoning ermöglicht die Zugriffskontrolle in der SAN-Topologie. Es definiert, welche
HBAs eine Verbindung mit bestimmten SPs herstellen können. Wenn ein SAN unter
Verwendung von Zoning konfiguriert wird, sind die Devices außerhalb einer Zone
gegenüber den Devices innerhalb der Zone nicht sichtbar.
Zoning hat folgende Auswirkungen:

Es reduziert die Anzahl der Ziele und LUNs, die einem ESX Server-System
zugeordnet sind.

Es kontrolliert und isoliert Pfade in einem Fabric.

Es kann andere Systeme daran hindern, ein bestimmtes Speichersystem zu
erkennen und möglicherweise ESX Server VMFS-Daten zu zerstören.

Es kann verwendet werden, um verschiedene Umgebungen voneinander zu
trennen (z. B. eine Test- von einer Produktionsumgebung).
VMware, Inc.
39
Bei der Verwendung von Zoning sollten Sie Folgendes beachten:

ESX Server-Hosts, die einen gemeinsamen Speicher für Failover oder
Lastausgleich verwenden, müssen sich in einer Zone befinden.

Wenn Sie über eine sehr umfangreiche Konfiguration verfügen, müssen Sie ggf.
separate Zonen für verschiedene Funktionsbereiche definieren. Beispielsweise
können Sie die Bereiche Buchhaltung und Personal voneinander trennen.

Es ist nicht ratsam, viele kleine Zonen aus beispielsweise zwei Hosts mit jeweils
vier virtuellen Maschinen zu erstellen.
HINWEIS Informationen zu den Best-Practices beim Zoning erhalten Sie vom Anbieter Ihres
Speicher-Arrays.
Zugriffskontrolle (LUN-Maskierung) und ESX Server
Durch Zugriffskontrolle können Sie die Anzahl der ESX Server-Hosts (oder anderer
Hosts), die eine LUN erkennen können, beschränken. Zugriffskontrolle ist in folgenden
Fällen sinnvoll:

Um die Anzahl der LUNs zu reduzieren, die einem ESX Server-System
zugeordnet sind.

Um andere Systeme daran zu hindern, ESX Server-LUNs zu erkennen und
möglicherweise VMFS-Volumes zu zerstören.
Grundlegendes zu VMFS- und SAN-Speicheroptionen
In diesem Abschnitt werden die verfügbaren VMFS- und SAN-Speicheroptionen
beschrieben und Entscheidungshilfen zur Verfügung gestellt. In diesem Abschnitt
werden folgende Themen behandelt:

„Auswahl großer oder kleiner LUNs“ auf Seite 40.

„LUN-Entscheidungen“ auf Seite 41.

„Tipps“ auf Seite 42.
Auswahl großer oder kleiner LUNs
Bei der Installation von ESX Server werden Sie aufgefordert, Partitionen für das System
zu erstellen. Daher sollten Sie sich schon vor der Installation überlegen, wie Sie den
Speicher für die ESX Server-Systeme einrichten möchten. Dabei haben Sie die Wahl
zwischen folgenden Ansätzen:
40

Viele LUNs mit einem VMFS-Volume für jede LUN.

Viele LUNs mit einem VMFS-Volume für alle LUNs.
VMware, Inc.
Maximal ist ein VMFS-Volume pro LUN möglich. Sie können aber auch eine große
LUN oder mehrere kleine LUNs verwenden.
Folgende Gründe sprechen für wenige große LUNs:

Mehr Flexibilität beim Erstellen virtueller Maschinen, ohne beim
SAN-Administrator mehr Platz anfordern zu müssen.

Mehr Flexibilität bei der Größenänderung virtueller Festplatten, dem Erstellen von
Snapshots usw.

Weniger LUNs, die identifiziert und verwaltet werden müssen.
Folgende Gründe sprechen für viele kleine LUNs:

Weniger Konkurrenzsituationen auf den einzelnen VMFS aufgrund von Sperren
und SCSI-Reservierungen.

Unterschiedliche Anwendungen könnten unterschiedliche
RAID-Charakteristiken erfordern.

Mehr Flexibilität (die Multipathing-Policy und gemeinsam genutzte Festplatten
werden pro LUN festgelegt).

Für den Einsatz von Microsoft Cluster Service muss jede
Cluster-Festplatten-Ressource in ihrer eigenen LUN eingerichtet sein.
HINWEIS Sie können Ihr Rechenzentrum auf Server aufteilen, die wenige große LUNs
verwenden, sowie Server, die viele kleine LUNs verwenden.
LUN-Entscheidungen
Wenn die Speichercharakterisierung für eine virtuelle Maschine nicht verfügbar ist,
lässt sich häufig nicht ohne weiteres beantworten, wann Entscheidungen hinsichtlich
der Größe und Anzahl der zu verwendenden LUNs getroffen werden sollten.
Die folgenden Ansätze können Sie bei der Entscheidungsfindung unterstützen:

Prädiktiv. Weitere Informationen finden Sie unter „Prädiktives Schema“ auf
Seite 42.

Adaptiv. Weitere Informationen finden Sie unter „Adaptives Schema“ auf Seite 42.
VMware, Inc.
41
Prädiktives Schema
Das prädiktive Schema umfasst folgende Schritte:

Erstellen mehrerer LUNs mit verschiedenen Speichereigenschaften.

Erstellen eines VMFS-Volumes für jede LUN (wobei jedes Volume eine
Bezeichnung erhält, die seine Eigenschaften wiedergibt).

Identifizieren der Anforderungen aller Anwendungen im entsprechenden RAID.

Verwenden gemeinsam genutzter Festplatten, um virtuelle Maschinen hoher
Priorität von virtuellen Maschinen niedriger Priorität zu unterscheiden. Beachten
Sie, dass gemeinsam genutzte Festplatten nur innerhalb eines bestimmten
ESX Server-Hosts relevant sind. Die gemeinsam genutzten Festplatten, die
virtuellen Maschinen auf einem ESX Server-Host zugewiesen sind, haben keine
Auswirkungen auf virtuelle Maschinen auf anderen ESX Server-Hosts.
Adaptives Schema
Das adaptive Schema umfasst folgende Schritte:

Erstellen einer großen LUN (RAID 1+0 oder RAID 5) mit aktivierter
Write-Cache-Funktion.

Erstellen eines VMFS in dieser LUN.

Platzieren von vier oder fünf virtuellen Festplatten im VMFS.

Ausführen der Anwendungen und Überprüfen der Festplatten-Performance.

Wenn die Performance akzeptabel ist, können Sie zusätzliche virtuelle Festplatten
im VMFS platzieren. Andernfalls erstellen Sie eine neue, größere LUN, nach
Möglichkeit mit einem anderen RAID-Level, und wiederholen den Vorgang.
Damit bei der LUN-Erstellung keine virtuellen Maschinen verloren gehen, können
Sie eine Cold-Migration verwenden.
Tipps
Bei der LUN-Entscheidung sollten Sie Folgendes beachten:
42

Jede LUN sollte über den richtigen RAID-Level und die richtigen
Speichereigenschaften für Anwendungen auf virtuellen Maschinen verfügen,
die diese verwenden.

Eine LUN darf nur ein VMFS-Volume umfassen.

Wenn mehrere virtuelle Maschinen auf die gleiche LUN zugreifen, verwenden
Sie gemeinsam genutzte Festplatten, um virtuellen Maschinen eine
Priorität zuzuweisen.
VMware, Inc.
So weisen Sie virtuellen Maschinen durch gemeinsam genutzte Festplatten
eine Priorität zu
1
Starten Sie einen Client der virtuellen Infrastruktur und verbinden Sie ihn mit
einem VirtualCenter-Server.
2
Wählen Sie die virtuelle Maschine im Inventarfenster aus, und klicken Sie im
Kontextmenü auf Einstellungen bearbeiten.
3
Klicken Sie auf die Registerkarte Ressourcen, und wählen Sie Festplatte aus.
4
Klicken Sie mit der rechten Maustaste auf die Spalte Shares für die Festplatte,
die Sie bearbeiten möchten, und wählen Sie den erforderlichen Wert aus dem
Dropdown-Menü aus.
Grundlegendes zum Datenzugriff
In diesem Abschnitt werden folgende Themen behandelt:

„Aufrufen von Daten in einem SAN Array“ auf Seite 43

„Funktionsweise des Datenzugriffs virtueller Maschinen“ auf Seite 44

„Funktionsweise des Datenzugriffs virtueller Maschinen in einem SAN“ auf
Seite 45
Aufrufen von Daten in einem SAN Array
Wenn Sie nicht damit vertraut sind, wie ein physischer (nicht virtueller) Rechner die
Daten in einem SAN-Array aufruft, lesen Sie das White Paper SAN Conceptual and
Design Basics auf der VMware Documentation-Website unter
www.vmware.com/support/pubs/.
VMware, Inc.
43
Funktionsweise des Datenzugriffs virtueller Maschinen
Virtuelle Maschinen rufen Daten über eine der folgenden Methoden auf:

VMFS – In einer einfachen Konfiguration sind die Festplatten der virtuellen
Maschinen als .vmdk-Dateien in einem ESX Server VMFS gespeichert. Wenn
Gastbetriebssysteme SCSI-Befehle an ihre virtuellen Festplatten ausgeben,
übersetzt die Virtualisierungsebene diese Befehle in VMFS-Dateivorgänge.
In einer Standardeinrichtung ruft die virtuelle Maschine eine Datei stets über das
VMFS auf, egal ob sich die Datei in einem SAN oder auf den lokalen Festplatten
eines Hosts befindet. Weitere Informationen finden Sie unter „Virtual Machine File
System (VMFS)“ auf Seite 22.

Raw Device Mapping (RDM) – Unter RDM versteht man eine Zuordnungsdatei
innerhalb des VMFS, die als Proxy für ein Raw Device fungiert. RDM ermöglicht
dem Gastbetriebssystem Zugriff auf das Raw Device.
RDM wird empfohlen, wenn eine virtuelle Maschine mit einer physischen
Festplatte im SAN interagieren muss. Dies ist zum Beispiel der Fall, wenn Sie
Snapshots vom Festplatten-Array erstellen, gelegentlich aber auch, wenn Sie über
eine große Datenmenge verfügen, die Sie nicht auf eine virtuelle Festplatte
verschieben möchten. Außerdem ist es für die Einrichtung von Microsoft Cluster
Service erforderlich. Weitere Informationen finden Sie im VMware-Dokument
Einrichtung des Microsoft Cluster-Dienstes.
44
VMware, Inc.
Abbildung 2-3 zeigt, wie virtuelle Maschinen unter Verwendung von VMFS oder RDM
auf Daten zugreifen.
ESX Server
Virtuelle Maschine
1
SCSI-Controller
(Buslogic oder LSI Logic)
HBA
VMFS
LUN1
LUN2
.dsk
RDM
LUN5
Abbildung 2-3. Funktionsweise des Datenzugriffs virtueller Maschinen
Weitere Informationen über VMFS und RDMs finden Sie im Handbuch zur
Server-Konfiguration.
Funktionsweise des Datenzugriffs virtueller Maschinen in
einem SAN
Bei der Interaktion einer virtuellen Maschine mit einem SAN finden folgende
Schritte statt:
1
Wenn das Gastbetriebssystem auf einer virtuellen Maschine einen Lese- oder
Schreibvorgang auf einer SCSI-Festplatte ausführen muss, gibt es SCSI-Befehle an
die virtuelle Festplatte aus.
2
Device-Treiber auf dem Betriebssystem der virtuellen Maschine kommunizieren
mit den virtuellen SCSI-Controllern. VMware ESX Server unterstützt zwei Arten
von virtuellen SCSI-Controllern: BusLogic und LSILogic.
3
Der virtuelle SCSI-Controller leitet den Befehl an den VMkernel weiter.
VMware, Inc.
45
4
5
6
Der VMkernel führt folgende Schritte aus:

Er sucht die Datei im VMFS-Volume, das der Festplatte der virtuellen
Gastmaschine entspricht.

Er ordnet die Anforderungen nach Blöcken auf der virtuellen Festplatte
Blöcken auf dem entsprechenden physischen Device zu.

Er sendet die geänderten I/O-Anforderungen vom Device-Treiber im
VMkernel an den physischen HBA (Host-HBA).
Der Host-HBA führt folgende Schritte aus:

Er konvertiert die Anforderung aus ihrer binären Datenform in die optische
Form, die zur Übertragung über Glasfaserkabel erforderlich ist.

Er packt die Anforderung gemäß den Regeln des FC-Protokolls.

Er überträgt die Anforderung an das SAN.
Je nachdem, über welchen Port der HBA eine Verbindung mit dem Fabric herstellt,
empfängt einer der SAN-Switches die Anforderung und leitet sie an das
Speicher-Device weiter, auf den der Host zugreifen möchte.
Der Host interpretiert dieses Speicher-Device als eine bestimmte Festplatte. Es
kann sich jedoch um ein logisches Device handeln, das einem physischen Device
im SAN entspricht. Der Switch muss bestimmen, welches physische Device dem
Host für das angesteuerte logische Device zur Verfügung gestellt wurde.
Pfad-Management und Failover
ESX Server unterstützt Multipathing, um eine dauerhafte Verbindung zwischen dem
Server und dem Speicher-Device bei einem Ausfall eines HBAs, Switches, Speicherprozessors oder FC-Kabels aufrecht zu erhalten. Bei Multipathing-Unterstützung sind
keine speziellen Failover-Treiber erforderlich.
Um Pfad-Switching zu unterstützen, verfügt der Server in der Regel über einen oder
mehrere HBAs, über die der Speicher-Array unter Verwendung von einem oder
mehreren Switches erreicht werden kann. Alternativ kann die Konfiguration auch
einen HBA und zwei Speicherprozessoren aufweisen, sodass der HBA einen anderen
Pfad verwenden kann, um auf den Festplatten-Array zuzugreifen.
46
VMware, Inc.
ESX
Server
HBA2
ESX
Server
HBA1
HBA3
HBA4
Switch
Switch
SP2
SP1
Speicher-Array
Abbildung 2-4. Multipathing und Failover
Abbildung 2-4 zeigt, dass jeder Server über mehrere Pfade mit dem Speicher-Device
verbunden ist. Wenn zum Beispiel HBA1 oder die Verbindung zwischen HBA1 und
dem FC-Switch ausfällt, übernimmt HBA2 und stellt eine Verbindung zwischen dem
Server und dem Switch zur Verfügung. Der Prozess, bei dem ein HBA für einen
anderen HBA einspringt, wird als HBA-Failover bezeichnet.
Wenn entsprechend SP1 ausfällt oder die Verbindungen zwischen SP1 und den
Switches unterbrochen sind, übernimmt SP2 und stellt eine Verbindung zwischen dem
Switch und dem Speicher-Device zur Verfügung. Dieser Vorgang wird SP-Failover
genannt. VMware ESX Server unterstützt über die Multipathing-Funktion sowohl
HBA- als auch SP-Failover.
Sie können eine Multipathing-Policy für Ihr System wählen, nämlich Feststehend oder
Zuletzt verwendet. Wenn die Policy Feststehend lautet, können Sie einen bevorzugten
Pfad angeben. Jede LUN (Festplatte), die für den ESX Server-Host sichtbar ist, kann
über ihre eigene Pfad-Policy verfügen. Informationen zum Anzeigen des aktuellen
Multipathing-Status und zum Festlegen der Multipathing-Policy finden Sie unter
„Multipathing“ auf Seite 97.
VMware, Inc.
47
HINWEIS I/Os virtueller Maschinen können während des Failovers mit maximal sechzig
Sekunden Verzögerung erfolgen, insbesondere in einem Aktiv/Passiv-Array. Diese
Verzögerung ist erforderlich, damit der SAN-Fabric nach Topologieänderungen oder
anderen Fabric-Eregnissen Zeit zum Stabilisieren seiner Konfiguration hat. Bei einem
Aktiv/Passiv-Array mit der Pfad-Policy Feststehend kann Pfad-Thrashing ein
Problem darstellen. Weitere Informationen finden Sie unter „Auflösen von
Pfad-Thrashing“ auf Seite 113.
Auswahl der Speicherorte virtueller Maschinen
Wenn Sie die Performance virtueller Maschinen optimieren möchten, spielt der
Speicherort eine entscheidende Rolle. Es gibt immer einen Kompromiss zwischen
kostspieligen Speichern mit hoher Performance und hoher Verfügbarkeit sowie
günstigeren Speichern mit schlechterer Performance. Speicher können in verschiedene
Tier unterteilt werden, die von einer Reihe von Faktoren abhängen:

High-Tier – Bietet hohe Performance und hohe Verfügbarkeit. Kann integrierte
Snapshots für einfachere Backups und Point-in-Time (PiT)-Wiederherstellungen
umfassen. Unterstützt Replikation, vollständige SP-Redundanz und
Fibre-Laufwerke. Verwendet teure Spindeln.

Mid-Tier – Bietet mittlere Performance, geringere Verfügbarkeit, gewisse
SP-Redundanz und SCSI-Laufwerke. Kann Snapshots umfassen. Verwendet
günstigere Spindeln.

Lower-Tier – Bietet niedrige Performance und wenig interne Speicherrredundanz.
Verwendet einfache SCSI- oder SATA-Laufwerke (günstige serielle Spindeln).
Nicht alle Anwendungen müssen maximale Performance und Verfügbarkeit bieten,
zumindest nicht während ihres gesamten Lebenszyklus.
HINWEIS Wenn Sie bestimmte Funktionen von High-Tier-Speichern benötigen, z. B. Snapshots,
aber kein Geld dafür ausgeben möchten, können Sie einige dieser Eigenschaften unter
Umständen durch entsprechende Software erreichen. Beispielsweise können Sie
Snapshots mit Software erstellen.
Um den Speicherort einer virtuellen Maschine zu bestimmen, müssen Sie sich folgende
Fragen stellen:
48

Welche Bedeutung hat die virtuelle Maschine?

Wie sehen seine Anforderungen in puncto Performance und Verfügbarkeit aus?

Wie sehen seine Anforderungen in puncto Point-in-Time
(PiT)-Wiederherstellung aus?
VMware, Inc.

Wie sehen seine Backup-Anforderungen aus?

Wie sehen seine Replikationsanforderungen aus?
Eine virtuelle Maschine kann im Laufe seines Lebenszyklus verschiedene Tier
durchlaufen, sei es durch eine Neubewertung seiner Bedeutung oder durch
technologische Änderungen, infolgedessen Funktionen einem niedrigeren Tier
zugeordnet werden. Bedeutung ist relativ und kann sich aus zahlreichen Gründen
ändern, z. B. durch Veränderungen im Unternehmen, Änderungen bei betrieblichen
Abläufen, Vorschriften, Disaster Planning usw.
Präventionsmaßnahmen gegen Server-Ausfälle
Durch die RAID-Architektur von SAN-Speichern sind Sie vor Ausfällen physischer
Festplatten geschützt. Ein dualer Fabric mit Duplizierung aller Fabric-Komponenten
schützt das SAN vor den meisten Fabric-Ausfällen. Der letzte Schritt, um Ihre gesamte
Umgebung vor Ausfällen zu schützen, ist der Schutz vor Server-Ausfällen. Die
Failover-Optionen von ESX Server-Systemen werden in den folgenden
Abschnitten behandelt:

„Verwenden von VMware HA“ auf Seite 49.

„Verwenden von Cluster-Diensten“ auf Seite 50.

„Server-Failover und Speicheraspekte“ auf Seite 51.
Verwenden von VMware HA
VMware HA ermöglicht es, virtuelle Maschinen in Failover-Gruppen zu organisieren.
Bei einem Host-Ausfall werden unverzüglich all seine virtuellen Maschinen auf
anderen Hosts neu gestartet. HA erfordert einen SAN-Speicher.
Wenn eine virtuelle Maschine auf einem anderen Host wiederhergestellt wird, geht
sein Speicherzustand zwar verloren, seine Festplatte befindet sich jedoch noch im
gleichen Zustand wie zum Zeitpunkt des Host-Ausfalls (absturzkonsistentes Failover).
Für HA wird ein gemeinsam genutzter Speicher (z. B. ein SAN) benötigt. Ausführliche
Informationen finden Sie im Handbuch zum Ressourcen-Management.
HINWEIS Wenn Sie VMware HA verwenden möchten, müssen Sie über eine entsprechende
Lizenz verfügen.
VMware, Inc.
49
Verwenden von Cluster-Diensten
Server-Clustering ist ein Verfahren, mit dem zwei oder mehr Server über eine
Hochgeschwindigkeits-Netzwerkverbindung miteinander verbunden werden,
sodass die Server-Gruppe als einzelner, logischer Server fungiert. Wenn einer der
Server ausfällt, übernehmen die anderen Server im Cluster die Vorgänge, die von dem
ausgefallenen Server ausgeführt wurden.
VMware testet Microsoft Cluster Service in Verbindung mit ESX Server-Systemen,
andere Cluster-Lösungen werden jedoch eventuell auch unterstützt. Für
Cluster-Failover stehen verschiedene Konfigurationsmöglichkeiten zur Verfügung:

Cluster in einer Box – Zwei virtuelle Maschinen auf einem Host fungieren als
Failover-Server für den jeweils anderen. Wenn eine virtuelle Maschine ausfällt,
übernimmt der andere. (Diese Konfiguration bietet keinen Schutz vor
Host-Ausfällen. Sie wird für gewöhnlich beim Testen der
Cluster-Anwendung verwendet.)

Cluster in mehreren Boxen – Einer virtuellen Maschine auf einem
ESX Server-Host ist eine entsprechende virtuelle Maschine auf einem
anderen ESX Server-Host zugeordnet.

P2V-Clustering (N+1-Clustering) – Eine virtuelle Maschine auf einem
ESX Server-Host fungiert als Failover-Server für einen physischen Server.
Da virtuelle Maschinen, die auf einem einzigen Host ausgeführt werden, als
Failover-Server für zahlreiche physische Server fungieren können, bietet diese
Clustering-Methode eine kostengünstige N+1-Lösung.
Weitere Informationen finden Sie im Dokument Einrichtung des Microsoft
Cluster-Dienstes.
Abbildung 2-5 zeigt verschiedene Konfigurationsmöglichkeiten für Cluster-Failover.
Virtuelle
Maschine
Virtuelle
Maschine
Virtuelle
Maschine
Virtuelle
Maschine
Virtuelle
Maschine
Virtuelle
Maschine
Virtuelle
Maschine
Cluster in einer Box
Cluster in mehreren Boxen
P2V-Clustering
Abbildung 2-5. Clustering mit einem Clustering-Dienst
50
VMware, Inc.
Server-Failover und Speicheraspekte
Bei jeder Art von Server-Failover müssen bestimmte Speicheraspekte beachtet werden:

Ansätze für Server-Failover funktionieren nur, wenn jeder Server Zugriff auf den
gleichen Speicher hat. Da mehrere Server viel Speicherplatz beanspruchen und
Failover für den Server durch Failover für das Speicher-Array ergänzt wird,
werden SANs normalerweise in Verbindung mit Server-Failover bereitgestellt.

Wenn Sie ein SAN mit Server-Failover bereitstellen möchten, müssen alle LUNs,
die von den virtuellen Maschinen im Cluster verwendet werden, von allen ESX
Server-Hosts erkannt werden. Dies erscheint SAN-Administratoren möglicherweise
nicht logisch, ist bei Verwendung von virtuellen Maschinen aber sinnvoll.
Auch wenn ein Host auf eine LUN zugreifen kann, müssen nicht zwangsläufig alle
virtuellen Maschinen auf diesem Host Zugriff auf alle Daten dieser LUN haben.
Eine virtuelle Maschine kann nur auf die virtuellen Festplatten zugreifen, für die
er konfiguriert wurde. Bei einem Konfigurationsfehler werden die virtuellen
Festplatten gesperrt, wenn die virtuelle Maschine gestartet wird, sodass keine
Datenverluste entstehen.
HINWEIS Bei Verwendung des Systemstarts über SAN sollte in der Regel jede Boot-LUN
nur von dem ESX Server-System erkannt werden, das über diese LUN gestartet
wird. Dies gilt jedoch nicht, wenn Sie versuchen, nach einem Absturz in den
Ausgangszustand zurückzukehren, indem Sie ein zweites ESX Server-System
auf die gleiche LUN verweisen. In diesem Fall ist die betreffende SAN-LUN im
Grunde keine LUN für den Systemstart über SAN. Da sie beschädigt ist, wird
kein ESX Server-System über sie gestartet. Die SAN-LUN ist dann eine normale
LUN, die für ein ESX Server-System sichtbar gemacht wird.
Optimieren der Ressourcen-Nutzung
Virtual Infrastructure ermöglicht Ihnen die Optimierung der Ressourcen-Zuweisung,
indem Sie virtuelle Maschinen von übermäßig stark genutzten Hosts auf zu wenig
genutzte Hosts migrieren. Es gibt zwei Optionen:

Virtuelle Maschinen explizit mit VMotion migrieren. Weitere Informationen
finden Sie unter „Verwenden von VMotion zum Migrieren virtueller Maschinen“
auf Seite 52.

Virtuelle Maschinen automatisch mit VMware DRS migrieren. „Verwenden von
VMware DRS zum Migrieren virtueller Maschinen“ auf Seite 52.
Sie können VMotion oder DRS nur verwenden, wenn sich die virtuellen Festplatten auf
dem gemeinsam genutzten Speicher befinden, der mehreren Server zur Verfügung
steht. In den meisten Fällen wird ein SAN-Speicher verwendet. Weitere Informationen
über VMotion finden Sie unter Grundlagen der Systemverwaltung. Weitere Informationen
über DRS finden Sie im Handbuch zum Ressourcen-Management.
VMware, Inc.
51
Verwenden von VMotion zum Migrieren virtueller Maschinen
Die VMotion-Technologie ermöglicht ein intelligentes Arbeitslast-Management.
Mit VMotion können Administratoren virtuelle Maschinen manuell auf verschiedene
Hosts migrieren. Eine aktive virtuelle Maschine kann unterbrechungsfrei auf einen
physischen Server migriert werden, der mit dem gleichen SAN verbunden ist.
VMotion ermöglicht Folgendes:

Durchführung ausfallfreier Wartung durch Verschieben von virtuellen Maschinen.
Dadurch können Wartungsarbeiten an der zugrunde liegenden Hardware und an
den Speicherressourcen erfolgen, ohne dass Anwendersitzungen unterbrochen
werden müssen.

Kontinuierlicher Lastausgleich im gesamten Rechenzentrum zur optimalen
Ressourcennutzung bei schwankenden Geschäftsanforderungen.
Abbildung 2-6 zeigt, wie Sie eine virtuelle Maschine mit VMotion migrieren können.
ESX Server
ESX Server
VMotion-Technologie
Anwendungen
Anw
wendu
wendu
u
ungen
n
Anwendungen
Anwendungen
Gastbetriebssystem
Gastbe
a ettriebssystteem
Gastbetriebssystem
Gastbetriebssystem
Virtuelle Maschine
Virtueeelle
lle Maaschine
a
e
Virtuelle Maschine
Virtuelle Maschine
Abbildung 2-6. Migration mit VMotion
Verwenden von VMware DRS zum Migrieren
virtueller Maschinen
VMware DRS verbessert die Ressourcen-Zuweisung über alle Hosts und
Ressourcen-Pools hinweg. DRS erfasst Ressourcen-Nutzungsinformationen für alle
Hosts und virtuellen Maschinen in einem VMware-Cluster und gibt in einer der beiden
folgenden Situationen Empfehlungen (oder migriert virtuelle Maschinen):

Startplatzierung – Wenn Sie eine virtuelle Maschine erstmalig in einem Cluster
einschalten, sorgt DRS entweder für eine adäquate Platzierung der virtuellen
Maschine oder gibt eine Empfehlung.

Lastausgleich – DRS versucht, die Ressourcen-Auslastung im gesamten Cluster
zu verbessern, indem virtuelle Maschinen automatisch migriert werden (VMotion)
oder eine Empfehlung für die Migration virtueller Maschinen gegeben wird.
52
VMware, Inc.
3
Voraussetzungen
und Installation
3
In diesem Kapitel werden Hardware- und Systemvoraussetzungen für den Einsatz von
ESX Server-Systemen mit SAN-Speicher erläutert. Das Kapitel umfasst die
folgenden Abschnitte:

„Allgemeine Voraussetzungen für ESX Server mit SAN“ auf Seite 54.

„Voraussetzungen für einen ESX Server-Systemstart über SAN“ auf Seite 57.

„Schritte für Installation und Setup“ auf Seite 59.
Es werden nur die grundlegendsten Voraussetzungen aufgeführt. Lesen Sie vor dem
Konfigurieren Ihres Systems Kapitel 4, „Einrichten von SAN-Speicher-Devices mit
ESX Server,“ auf Seite 61.
VMware, Inc.
53
Allgemeine Voraussetzungen für ESX Server mit SAN
Prüfen Sie während der Vorbereitung der SAN-Konfiguration und der Einrichtung
Ihres ESX Server-Systems für die Verwendung von SAN-Speicher die folgenden
Anforderungen und Empfehlungen:

Hardware und Firmware. In Verbindung mit ESX Server-Systemen wird nur eine
begrenzte Zahl von Kombinationen aus SAN-Speicher-Hardware und -Firmware
unterstützt. Eine aktuelle Liste finden Sie im Storage/SAN Compatibility Guide.

Ein VMFS-Volume pro LUN. Stellen Sie sicher, dass Sie Ihr System
so konfigurieren, dass pro LUN nur ein VMFS-Volume vorhanden ist.
(In VMFS-3 müssen Sie die Zugänglichkeit nicht mehr festlegen.)

Sofern Sie keine Server ohne Festplatte verwenden, richten Sie die
Diagnosepartition auf einer SAN-LUN nicht ein.
Für Server ohne Festplatte, die über SAN booten, eignet sich eine gemeinsam
genutzte Diagnosepartition. Weitere Informationen finden Sie unter „Gemeinsame
Nutzung von Diagnosepartitionen“ auf Seite 109.

Die Verwendung von RDMs wird für den Zugriff auf Raw-Festplatten über einen
Rechner mit ESX Server 2.5 oder höher empfohlen. Weitere Informationen über
RDMs finden Sie im Handbuch zur Server-Konfiguration.

Multipathing. Damit Multipathing fehlerfrei funktioniert, muss jede LUN auf
allen ESX Server-Hosts dieselbe LUN-Nummer darstellen.

Warteschlangengröße. Stellen Sie sicher, dass der BusLogic- oder LSILogic-Treiber
im Gastbetriebssystem eine ausreichend große Warteschlange angibt. Sie
können die Warteschlangentiefe für den physischen HBA während der
Systemkonfiguration festlegen. Im Storage/SAN Compatibility Guide finden
Sie eine Liste der unterstützten Treiber.

SCSI-Timeout. Auf virtuellen Maschinen, die Microsoft Windows ausführen,
sollten Sie den Wert des SCSI-Parameters TimeoutValue erhöhen, sodass
Windows verzögerte I/O aufgrund eines Pfad-Failovers besser tolerieren kann.
Siehe „Festlegen des Betriebssystem-Timeouts“ auf Seite 108.
54

„Einschränkungen“ auf Seite 55

„Festlegen von LUN-Zuweisungen“ auf Seite 55

„Einrichten des FC-HBA“ auf Seite 56
VMware, Inc.
Kapitel 3 Voraussetzungen und Installation
Einschränkungen
Die folgenden Einschränkungen gelten, wenn Sie ESX Server mit einem
SAN verwenden:

ESX Server unterstützt keine FC-verbundenen Band-Devices. Diese Devices
können vom VMware Consolidated Backup-Proxy verwaltet werden, der im
Handbuch für das Backup virtueller Maschinen erläutert wird.

Multipathing-Software für virtuelle Maschinen kann nicht zum Ausführen des
I/O-Lastausgleichs auf eine einzige physische LUN verwendet werden.

Sie können logische Volume-Manager-Software für virtuelle Maschinen nicht
zum Spiegeln virtueller Festplatten verwenden. Dynamische Festplatten auf
einer virtuellen Microsoft Windows-Maschine sind eine Ausnahme, erfordern
allerdings eine besondere Konfiguration.
Festlegen von LUN-Zuweisungen
Beachten Sie beim Festlegen von LUN-Zuweisungen die folgenden Punkte:

Speicherbereitstellung - Um sicherzustellen, dass das ESX Server-System die
LUNs beim Starten erkennt, stellen Sie den entsprechenden HBAs alle LUNs
bereit, bevor Sie das SAN mit dem ESX Server-System verbinden.
HINWEIS Die gleichzeitige Bereitstellung aller LUNs für alle ESX Server-HBAs wird
empfohlen. HBA-Failover funktioniert nur, wenn alle HBAs dieselben
LUNs sehen.

VMotion und VMware DRS - Wenn Sie VirtualCenter und VMotion oder DRS
verwenden, stellen Sie sicher, dass die LUNs für die virtuellen Maschinen allen
ESX Server-Hosts bereitgestellt werden. Dies bietet maximale Flexibilität beim
Verlagern virtueller Maschinen.

Aktiv/Aktiv- vs. Aktiv/Passiv-Arrays - Wenn Sie VMotion oder DRS mit
einem Aktiv/Passiv-SAN-Speicher-Device verwenden, stellen Sie sicher, dass
alle ESX Server-Systeme über konsistente Pfade zu allen Speicherprozessoren
verfügen. Andernfalls kann es im Fall einer VMotion-Migration zu
Pfad-Thrashing kommen. Siehe „Auflösen von Pfad-Thrashing“ auf Seite 113.
Für Aktiv/Passiv-Speicher-Arrays, die nicht im Storage/SAN Compatibility Guide
aufgeführt sind, unterstützt VMware den Speicher-Port-Failover nicht. In diesem
Fall müssen Sie den Server mit dem aktiven Port auf dem Speicher-Array
verbinden. Diese Konfiguration stellt sicher, dass die LUNs auf dem
ESX Server-Host angezeigt werden.
VMware, Inc.
55
Einrichten des FC-HBA
Beachten Sie während der Einrichtung des FC-HBA die folgenden Punkte:

HBA-Standardeinstellungen - FC-HBAs funktionieren mit den
Standardkonfigurationseinstellungen fehlerfrei. Beachten Sie die von Ihrem
Speicher-Array-Anbieter vorgegebenen Konfigurationsrichtlinien.
HINWEIS Um optimale Ergebnisse zu erzielen, verwenden Sie innerhalb eines Servers
dasselbe HBA-Modell. Stellen Sie sicher, dass die Firmware-Ebene innerhalb
eines Servers auf jedem HBA identisch ist. Das Vorhandensein von Emulex- und
QLogic-HBAs auf demselben Server zum selben Ziel wird nicht unterstützt.

Statischer Lastausgleich über HBAs - Einige ESX Server-Systeme können so
konfiguriert werden, dass ein Lastausgleich des Verkehrs über mehrere HBAs auf
mehrere LUNs mit bestimmten Aktiv/Aktiv-Arrays erfolgt.
Dazu weisen Sie Ihren LUNs bevorzugte Pfade zu, sodass Ihre HBAs gleichmäßig
verwendet werden. Beispiel: wenn Sie über zwei LUNs (A und B) und zwei HBAs
(X und Y) verfügen, können Sie HBA X als bevorzugten Pfad für LUN A und
HBA Y als bevorzugten Pfad für LUN B festlegen. Dadurch wird die Ausnutzung
Ihrer HBAs maximiert. In diesem Fall muss die Pfad-Policy auf Fest gesetzt
werden. Siehe „So legen Sie die Multipathing-Policy mit einem VI-Client fest:“ auf
Seite 102.

Festlegen des Failover-Timeouts - Der Timeout-Value zum Erkennen des Ausfalls
eines Pfades wird im HBA-Treiber festgelegt. Wenn Sie den Timeout-Wert auf
30 Sekunden setzen, ist eine optimale Leistung sichergestellt. Dies ist die
empfohlene Einstellung. Befolgen Sie zum Festlegen des Wertes die Anweisungen
unter „Festlegen des HBA-Timeout für Failover“ auf Seite 107.

Dedizierter Adapter für Bandlaufwerke - Um optimale Ergebnisse zu erzielen,
verwenden Sie einen dedizierten SCSI-Adapter für alle Bandlaufwerke, die Sie mit
einem ESX Server-System verbinden. FC-verbundene Bandlaufwerke werden
nicht unterstützt. Verwenden Sie den Consolidated Backup-Proxy, wie im
Handbuch für das Backup virtueller Maschinen erläutert.
Weitere Informationen zum Systemstart über das SAN-HBA-Setup finden Sie in
Kapitel 5, „Verwenden des Systemstarts über SAN mit ESX Server-Systemen,“ auf
Seite 77.
56
VMware, Inc.
Empfehlungen
Im folgenden Abschnitt erhalten Sie Anweisungen zu Entscheidungen, die Sie beim
Einrichten Ihrer Umgebung mit ESX Server-Hosts und einem SAN treffen müssen:

Verwenden Sie das Raw-Device-Mapping für die virtuelle Festplatte einer
virtuellen Maschine, damit Sie einige der Hardware-Snapshotting-Funktionen des
Festplatten-Arrays nutzen oder in einer Cold-Standby-Host-Konfiguration für
Daten-LUNs sowohl von einer virtuellen Maschine als auch von einem physischen
Rechner auf eine Festplatte zuzugreifen.

Verwenden Sie das Raw-Device-Mapping für die freigegebenen Festplatten in
einem Microsoft Cluster Service-Setup. Weitere Informationen finden Sie im
VMware-Dokument Einrichtung des Microsoft Cluster-Dienstes.

Weisen Sie eine große LUN für die Verwendung durch mehrere virtuelle
Maschinen zu, und richten Sie diese als VMFS ein. Anschließend können Sie
virtuelle Maschinen dynamisch erstellen oder löschen, ohne bei jedem Hinzufügen
einer virtuellen Maschine zusätzlichen Speicherplatz anfordern zu müssen.

Wenn Sie eine virtuelle Maschine mit VMotion auf einen anderen Host
verschieben möchten, müssen die LUNs, die die virtuellen Festplatten der
virtuellen Maschinen enthalten, maskiert werden, sodass sie von allen Hosts
sichtbar sind.
Weitere Empfehlungen und Informationen zur Fehlerbehebung finden Sie in Kapitel 6,
„Verwalten von ESX Server-Systemen, die SAN-Speicher verwenden,“ auf Seite 87.
Voraussetzungen für einen ESX Server-Systemstart
über SAN
Wenn Sie SAN-Speicher mit Ihrem ESX Server-System konfiguriert haben, können
Sie das Boot-Image von ESX Server auf einer der LUNs auf dem SAN platzieren.
Diese Konfiguration muss bestimmte Kriterien erfüllen, die in diesem Abschnitt
erläutert werden. Weitere Informationen finden Sie unter „Verwenden des Systemstarts
über SAN mit ESX Server-Systemen“ auf Seite 77.
Um Ihr ESX Server-System für den Systemstart über SAN zu aktivieren, sollten Sie:

Die allgemeinen Voraussetzungen erfüllen. Siehe „Allgemeine Voraussetzungen
für ESX Server mit SAN“ auf Seite 54.

Die in Tabelle 3-1 aufgelisteten Aufgaben ausführen.
VMware, Inc.
57
Tabelle 3-1. Voraussetzungen für den Systemstart über SAN
Voraussetzung
Beschreibung
ESX Server-Systemvoraussetzungen
ESX Server 3.0 oder höher wird empfohlen. Wenn Sie ein
ESX Server 3.0-System verwenden, werden RDMs in Verbindung
mit dem Systemstart über SAN unterstützt. Für ein
ESX Server 2.5.x-System werden RDMs in Verbindung mit dem
Systemstart über SAN nicht unterstützt.
HBA-Voraussetzungen
Das HBA-BIOS für Ihre HBA-FC-Karte muss aktiviert und korrekt
konfiguriert sein, um auf die Boot-LUN zuzugreifen. Siehe
„Einrichten des FC-HBA“ auf Seite 56.
Der HBA sollte in den niedrigsten PCI-Bus und die niedrigste
Slot-Nummer eingesteckt werden. Dadurch können die Treiber den
HBA schnell erkennen, da die Treiber die HBAs unabhängig von
der zugehörigen HBA-Nummer der virtuellen Maschine in
absteigender Reihenfolge von PCI-Bus und Slot-Nummer scannen.
Hinweis: Ausführliche Informationen zu Treibern und Versionen
finden Sie im ESX Server I/O Compatibility Guide.
Überlegungen zur
Boot-LUN
SAN-Überlegungen
Hardwarespezifische
Überlegungen
58

Wenn Sie den Systemstart über einen
Aktiv/Passiv-Speicher-Array ausführen, muss der
Speicherprozessor, dessen WWN in der BIOS-Konfiguration
des HBA angegeben ist, aktiv sein. Ist dieser Speicherprozessor
passiv, kann der HBA den Boot-Prozess nicht unterstützen.

Um die BIOS-Konfiguration zu erleichtern, maskieren
Sie jede Boot-LUN, sodass sie nur von ihrem eigenen
ESX Server-System angezeigt werden kann. Jedes
ESX Server-System sollte seine eigene Boot-LUN sehen, nicht
jedoch die Boot-LUN eines anderen ESX Server-Systems.

SAN-Verbindungen müssen über eine
Switch-Fabric-Topologie erfolgen. Der Systemstart über SAN
unterstützt die direkte Verbindung (d. h. eine Verbindung
ohne Switches) oder FC-AL-Verbindungen (Fibre Channel
Arbitrated Loop) nicht.

Redundante und nicht redundante Konfigurationen werden
unterstützt. Im redundanten Fall blendet ESX Server die
redundanten Pfade aus, sodass dem Anwender nur ein Pfad zu
einer LUN angezeigt wird.

Wenn Sie ein IBM eServer BladeCenter ausführen und den
Systemstart über SAN verwenden, müssen Sie IDE-Laufwerke
auf den Blades deaktivieren.
Weitere hardware-spezifische Überlegungen finden Sie in der
VMware-Knowledge Base und in Kapitel 4, „Einrichten von
SAN-Speicher-Devices mit ESX Server,“ auf Seite 61.
VMware, Inc.
Schritte für Installation und Setup
In Tabelle 3-2 erhalten Sie einen Überblick über die Installations- und Setup-Schritte
mit Verweisen auf relevante Informationen.
Tabelle 3-2. Schritte für Installation und Setup
Schritt
Beschreibung
Siehe
1
Entwerfen Sie Ihr SAN, wenn es noch
nicht konfiguriert ist. Die meisten
vorhandenen SANs erfordern für
den Einsatz mit ESX Server nur
geringfügige Änderungen.
Kapitel 2, „Verwenden von ESX Server mit
SAN,“ auf Seite 29.
2
Prüfen Sie, ob alle
SAN-Komponenten die
Voraussetzungen erfüllen.
Kapitel 3, „Allgemeine Voraussetzungen
für ESX Server mit SAN,“ auf Seite 54.
Richten Sie die HBAs für die
ESX Server-Hosts ein.
Besondere Voraussetzungen, die nur für
den Systemstart über SAN gelten, finden
Sie in Kapitel 3, „Voraussetzungen für einen
ESX Server-Systemstart über SAN,“ auf
Seite 57.
3
Storage/SAN Compatibility Guide.
Weitere Informationen finden Sie auch in
Kapitel 5, „Verwenden des Systemstarts
über SAN mit ESX Server-Systemen,“ auf
Seite 77.
4
Führen Sie alle erforderlichen
Speicher-Array-Änderungen aus.
Einen Überblick finden Sie in Kapitel 4,
„Einrichten von SAN-Speicher-Devices mit
ESX Server,“ auf Seite 61.
Die meisten Anbieter verfügen über
anbieterspezifische Dokumentation zum
Einrichten eines SANs für den Einsatz mit
VMware ESX Server.
5
Installieren Sie ESX Server auf den
Hosts, die Sie mit dem SAN
verbunden haben und für die Sie die
HBAs eingerichtet haben.
Handbuch für Installation und Upgrade.
6
Erstellen Sie virtuelle Maschinen.
Grundlagen der Systemverwaltung.
VMware, Inc.
59
Tabelle 3-2. Schritte für Installation und Setup
Schritt
Beschreibung
Siehe
7
Richten Sie Ihr System für VMware
HA-Failover oder für die
Verwendung von Microsoft
Clustering Services ein.
VMware-Handbuch zum
Ressourcen-Management: ESX Server 3.0 und
VirtualCenter 2.0.
Richten Sie den Microsoft Cluster-Dienst ein.
Dieser Schritt ist optional.
8
Führen Sie gegebenenfalls
Upgrades oder Änderungen
Ihrer Umgebung durch.
Eine Einführung finden Sie in Kapitel 6,
„Verwalten von ESX Server-Systemen, die
SAN-Speicher verwenden,“ auf Seite 87.
Durchsuchen Sie die Artikel der
VMware-Knowledge Base nach
rechnerspezifischen Informationen
und aktuellen Daten.
60
VMware, Inc.
4
Einrichten von
SAN-Speicher-Devices
mit ESX Server
4
In diesem Kapitel werden verschiedene Speicher-Devices beschrieben, die in
Verbindung mit VMware ESX Server unterstützt werden. Zu jedem Device werden die
wichtigsten potenziellen Fehler, herstellerspezifische Angaben (sofern verfügbar) und
Informationen aus Artikeln der VMware-Wissenbasis aufgeführt.
HINWEIS Die Informationen in diesem Dokument werden nur bei einer neuen
Produktveröffentlichung aktualisiert. In der Zwischenzeit können jedoch neue
Informationen vorliegen. Lesen Sie den aktuellen Storage/SAN Compatibility Guide,
fragen Sie den Händler, bei dem Sie den Speicher-Array erworben haben, und
informieren Sie sich in den Artikeln der VMware-Wissensbasis.
In diesem Kapitel werden folgende Themen behandelt:

„Einrichtungsübersicht“ auf Seite 62.

„Allgemeine Überlegungen“ auf Seite 64.

„EMC CLARiiON-Speichersysteme“ auf Seite 64.

„EMC Symmetrix-Speichersysteme“ auf Seite 66.

„IBM TotalStorage DS4000-Speichersysteme“ auf Seite 67.

„IBM TotalStorage 8000“ auf Seite 71.

„HP StorageWorks-Speichersysteme“ auf Seite 72.

„Hitachi Data Systems-Speicher“ auf Seite 75.

„Network Appliance-Speicher“ auf Seite 75.
VMware, Inc.
61
Einrichtungsübersicht
VMware ESX Server unterstützt eine breite Palette von SAN-Speicher-Arrays in
verschiedenen Konfigurationen. Nicht alle Speicher-Devices sind für alle Funktionen
von ESX Server zertifiziert. Zudem wird ESX Server nicht von allen Anbietern
gleichermaßen unterstützt. Aktuelle Informationen über unterstützte Speicher-Arrays
finden Sie im Storage/SAN Compatibility Guide.
Ausführlichere Informationen enthalten die folgenden Abschnitte:

„Tests“ auf Seite 62.

„Unterstützte Devices“ auf Seite 63.
Tests
VMware testet ESX Server mit Speicher-Arrays in den folgenden Konfigurationen:
62

Basiskonnektivität – Testet, ob ESX Server den Speicher-Array erkennt und mit
ihm interagiert. Diese Konfiguration ermöglicht kein Multipathing oder Failover.

HBA-Failover – Der Server verfügt über mehrere HBAs, die mit ein oder mehreren
SAN-Switches verbunden sind. Der Server ist nur vor einem HBA- und
Switch-Ausfall geschützt.

Speicherport-Failover – Der Server ist mit mehreren Speicherports verbunden
und vor Speicherport- und Switch-Ausfällen geschützt.

Systemstart über SAN – Der ESX Server-Host startet über eine im SAN
konfigurierte LUN, anstatt über den Server selbst.

Direktverbindung – Der Server ist ohne Einsatz von Switches über ein FC-Kabel
mit dem Array verbunden. Für alle anderen Tests wird eine Fabric-Verbindung
verwendet. FC-AL (Fibre Channel Arbitrated Loop) wird nicht unterstützt.

Clustering – Das System wird mit Microsoft Cluster Service getestet, das auf der
virtuellen Maschine ausgeführt wird. Weitere Informationen finden Sie im
Dokument Einrichtung des Microsoft Cluster-Dienstes, das Teil dieses
Dokumentationssatzes ist.
VMware, Inc.
Kapitel 4 Einrichten von SAN-Speicher-Devices mit ESX Server
Unterstützte Devices
Tabelle 4-1 enthält eine Auflistung der von ESX Server 3.0 unterstützten
Speicher-Devices sowie Verweise auf Informationen über ihre Verwendung mit
ESX Server.
Tabelle 4-1. Unterstützte SAN-Arrays
Hersteller
Gerät
Siehe
EMC
CLARiiON-Speichersystem.
„EMC CLARiiON-Speichersysteme“
auf Seite 64.
Auch von FSC erhältlich.
Auch von Dell, Inc. erhältlich als
Dell/EMC FC RAID
Array-Produktreihe.
IBM
Symmetrix-Speichersystem.
„EMC Symmetrix-Speichersysteme“
auf Seite 66.
IBM TotalStorage DS
4000-Systeme (ehemals
FAStT-Speichersystem).
„IBM TotalStorage
DS4000-Speichersysteme“ auf
Seite 67.
Auch erhältlich von LSI Eugenio
und StorageTek.
IBM TotalStorage
Enterprise-Speichersysteme
(ehemals
Shark-Speichersysteme).
„IBM TotalStorage 8000“ auf Seite 71.
IBM SVC (SAN Volume Controller).
Hewlett Packard
HP StorageWorks (MSA, EVA
und XP).
„HP
StorageWorks-Speichersysteme“ auf
Seite 72.
Hitachi
Hitachi Data Systems-Speicher.
„Hitachi Data Systems-Speicher“ auf
Seite 75.
Auch erhältlich von Sun und als
HP XP.
Network
Appliance
VMware, Inc.
Network Appliance-FC-SANSpeicherlösungen.
„Network Appliance-Speicher“ auf
Seite 75.
63
Allgemeine Überlegungen
Stellen Sie bei allen Speicher-Arrays sicher, dass die folgenden Bedingungen
erfüllt sind:

Die LUNs müssen für jeden HBA der einzelnen Hosts die gleiche LUN-ID
aufweisen. Wenn mehrere Nummern verwendet werden, erkennen die
ESX Server-Hosts keine unterschiedlichen Pfade zur gleichen LUN.
Da sich die Anweisungen zur Konfiguration identischer LUN-IDs in einem SAN je
nach Anbieter unterscheiden, sollten Sie in der Dokumentation zu Ihrem
Speicher-Array nachschlagen.

Sofern für die in diesem Kapitel behandelten Speicher-Arrays nichts anderes
angegeben ist, sollten Sie den Host-Typ der LUNs für ESX Server auf Linux oder
Linux Cluster einstellen.

Wenn Sie VMotion, DRS oder HA verwenden, stellen Sie sicher, dass sowohl
die Quell- als auch die Ziel-Hosts für virtuelle Maschinen die gleichen
LUNs erkennen.
SAN-Administratoren erscheint es möglicherweise nicht logisch, dass mehrere
Hosts die gleichen LUNs erkennen, da sie um Datenverluste besorgt sind.
VMFS verhindert jedoch, dass mehrere virtuelle Maschinen gleichzeitig in eine
Datei schreiben, d. h. es macht durchaus Sinn, die LUNs allen erforderlichen
ESX Server-Systemen bereitzustellen.
EMC CLARiiON-Speichersysteme
Die CLARiiON-Speichersysteme von EMC können in SAN-Konfigurationen mit
ESX Server-Rechnern verwendet werden. Die Konfiguration umfasst im Wesentlichen
folgende Schritte:
1
Installieren und Konfigurieren des Speicher-Devices
2
Konfigurieren von Zoning auf der Switch-Ebene
3
Erstellen von RAID-Gruppen
4
Erstellen und Verknüpfen von LUNs
5
Registrieren der mit dem SAN verbundenen Server
6
Erstellen von Speichergruppen für die Server und LUNs
Die Konfiguration erfolgt mit EMC Software. Weitere Informationen finden Sie in der
EMC Dokumentation.
64
VMware, Inc.
HINWEIS Hierbei handelt es sich um einen Aktiv/Passiv-Festplatten-Array, zu dem dieses
Dokument verwandte Themen enthält.
Um ein potenzielles Pfad-Thrashing zu verhindern, lautet die Multipathing-Policy
standardmäßig nicht Feststehend, sondern Zuletzt verwendet. Das ESX Server-System
legt die Standard-Policy fest, wenn es den Array identifiziert. Weitere Informationen
finden Sie unter „Auflösen von Pfad-Thrashing“ auf Seite 113.
HINWEIS Stellen Sie für den Systemstart über SAN sicher, dass der aktive Speicherprozessor für
das über die Boot-LUN angesteuerte Ziel im HBA-BIOS ausgewählt ist.
Ausführlichere Informationen finden Sie unter „EMC CLARiiON AX100“ auf Seite 65.
EMC CLARiiON AX100
Wenn Sie einen EMC CLARiiON-Speicher-Array verwenden, lesen Sie die
folgenden Abschnitte:

„EMC CLARiiON AX100 und RDM“ auf Seite 65.

„AX100-Anzeigeprobleme mit inaktiven Verbindungen“ auf Seite 65.

„Automatische Volume-Resignatur“ auf Seite 66.
EMC CLARiiON AX100 und RDM
Auf EMC CLARiiON AX100-Systemen werden RDMs nur unterstützt, wenn Sie für die
SAN-Administration die Navisphere Management Suite verwenden. Die einwandfreie
Funktionsweise von Navilight kann nicht garantiert werden.
Um RDMs verwenden zu können, muss jedem ESX Server-Host im Cluster eine
bestimmte LUN mit der gleichen LUN-ID zugeordnet werden. Dies ist beim
AX100-System standardmäßig nicht der Fall.
AX100-Anzeigeprobleme mit inaktiven Verbindungen
Bei Verwendung eines AX100-FC-Speicher-Devices, das direkt mit einem
ESX Server-System verbunden ist, müssen Sie sicherstellen, dass alle Verbindungen
funktionieren, und nicht mehr verwendete Verbindungen deregistrieren. Andernfalls
kann ESX Server keine neuen LUNs oder Pfade erkennen.
VMware, Inc.
65
Stellen Sie sich folgendes Szenario vor:
1
Ein ESX Server-System ist direkt mit einem AX100-Speicher-Device verbunden.
Das ESX Server-System verfügt über zwei FC-HBAs. Einer der HBAs wurde
für den Speicher-Array registriert, und seine LUNs wurden konfiguriert, die
Verbindungen werden aber inzwischen nicht mehr benötigt.
2
Wenn Sie den zweiten HBA im ESX Server-Host mit dem AX100 verbinden und
ihn registrieren, zeigt der ESX Server-Host den Array korrekt mit einer aktiven
Verbindung an. Dennoch wird keine der LUNs angezeigt, die zuvor für den
ESX Server-Host konfiguriert wurden, auch nicht nach wiederholtem Scannen.
Um dieses Problem zu lösen, müssen Sie den inaktiven HBA entfernen, die Verbindung
mit dem inaktiven HBA deregistrieren oder alle inaktiven Verbindungen aktivieren.
Auf diese Weise enthält die Speichergruppe nur aktive HBAs. Nachdem Sie diese
Änderung vorgenommen haben, wiederholen Sie den Scanvorgang, um die
konfigurierten LUNs hinzuzufügen.
Automatische Volume-Resignatur
Die automatische Volume-Resignatur wird von AX100-Speicher-Devices nicht
unterstützt. Informationen über die Volume-Resignatur finden Sie unter
„VMFS-Volume-Resignatur“ auf Seite 122.
EMC Symmetrix-Speichersysteme
Die folgenden Einstellungen sind für ESX Server-Vorgänge in einem vernetzten
Symmetrix-Speichersystem erforderlich:

Gemeinsame Seriennummer (C).

Auto-Negotiation (EAN) aktiviert.

Fibrepath auf diesem Port aktiviert (VCM).

SCSI 3 (SC3) aktiviert.

Eindeutiger World Wide Name (UWN).

SPC-2 (Decal) (SPC2) SPC-2-Flag deaktiviert.
Die Konfiguration des Speicher-Arrays erfolgt mit EMC Software. Weitere
Informationen finden Sie in der EMC Dokumentation.
HINWEIS Der ESX Server-Host betrachtet alle LUNs eines Symmetrix-Speicher-Arrays mit
einer Kapazität von 50 MB oder weniger als Management-LUNs. Diese LUNs
werden auch als Pseudo- oder Gatekeeper-LUNs bezeichnet. Sie erscheinen in der
EMC Symmetrix Management Interface und sollten nicht zum Speichern von Daten
verwendet werden.
66
VMware, Inc.
IBM TotalStorage DS4000-Speichersysteme
Die frühere Bezeichnung von IBM TotalStorage DS4000-Systemen lautet IBM FAStT.
Zahlreiche Anbieter von Speicher-Arrays (einschließlich LSI und StorageTek) stellen
SAN-Speicher-Arrays her, die mit DS4000-Speichern kompatibel sind.
Ausführliche Informationen finden Sie im IBM Redbook Implementing VMware
ESX Server with IBM TotalStorage FAStT unter
http://www.redbooks.ibm.com/redbooks/pdfs/sg246434.pdf. Dieser
Abschnitt enthält eine Zusammenfassung der Konfiguration eines IBM
TotalStorage-Speichersystems zur Verwendung mit SAN und Microsoft Clustering
Service. Weitere Informationen finden Sie im Dokument Einrichtung des Microsoft
Cluster-Dienstes.
Neben den herkömmlichen Konfigurationsschritten für das IBM
TotalStorage-Speichersystem müssen Sie bestimmte Aufgaben ausführen.

„Konfigurieren der Hardware für SAN-Failover bei DS4000-Speicherservern“ auf
Seite 67

„Überprüfen der Port-Konfiguration des Speicherprozessors“ auf Seite 69.

„Deaktivieren der automatischen Volume-Übertragung (AVT)“ auf Seite 70.

„Konfigurieren von Sense-Daten des Speicherprozessors“ auf Seite 70.

„IBM TotalStorage DS4000 und Pfad-Thrashing“ auf Seite 71.
Darüber hinaus müssen Sie sicherstellen, dass die Multipathing-Policy auf Zuletzt
verwendet eingestellt ist. Weitere Informationen finden Sie unter „Anzeigen des
aktuellen Multipathing-Status“ auf Seite 98.
Konfigurieren der Hardware für SAN-Failover bei
DS4000-Speicherservern
Zum Einrichten einer hochverfügbaren SAN-Failover-Konfiguration für
DS4000-Speichermodelle mit zwei Speicherprozessoren benötigen Sie die folgenden
Hardware-Komponenten:

Zwei FC-HBAs auf jedem ESX Server-Rechner (z. B. QLogic oder Emulex).

Zwei FC-Switches zur Verbindung der HBAs mit dem SAN (z. B. FC-Switch 1 und
FC-Switch 2).

Zwei SPs (z. B. SP1 und SP2).
Jeder SP muss über mindestens zwei Ports mit dem SAN verbunden sein.
VMware, Inc.
67
ESX Server 1
HBA1
HBA2
FC-Switch 1
ESX Server 2
HBA3
HBA4
FC-Switch 2
SP1
SP2
Speicher
Abbildung 4-1. SAN-Failover
Verwenden Sie die folgenden Verbindungseinstellungen für den ESX Server-Host,
wie in Abbildung 4-1 gezeigt:

Verbinden Sie jeden HBA auf jedem ESX Server-Rechner mit einem separaten
Switch. Beispielsweise können Sie HBA1 mit FC-Switch 1 und HBA2 mit
FC Switch 2 verbinden.

Verbinden Sie SP1 an FC-Switch 1 mit einer niedrigeren Switch-Port-Nummer als
SP2, damit SP1 zuerst aufgeführt wird. Beispielsweise können Sie SP1 mit
FC-Switch 1, Port 1 und SP2 mit FC-Switch 1, Port 2 verbinden.

Verbinden Sie SP1 an FC-Switch 2 mit einer niedrigeren Switch-Port-Nummer als
SP2, damit SP1 zuerst aufgeführt wird. Beispielsweise können Sie SP1 mit Port 1
an FC-Switch 2 und SP2 mit Port 2 an FC-Switch 2 verbinden.
Diese Konfiguration stellt zwei Pfade von jedem HBA bereit, sodass jedes
Verbindungselement an einen redundanten Pfad übergeben werden kann. Die
Reihenfolge der Pfade in der oben beschriebenen Konfiguration ermöglicht ein
HBA-und Switch-Failover, ohne dass ein SP-Failover ausgelöst werden muss. Die
LUNs müssen dem Speicherprozessor zugeordnet sein, mit dem die bevorzugten Pfade
verbunden sind (in der Beispielkonfiguration oben sollten sie SP1 zugeordnet sein).
HINWEIS In den voranstehenden Beispielen wird davon ausgegangen, dass die Switches nicht
über einen Inter-Switch Link (ISL) in einem Fabric verbunden sind.
68
VMware, Inc.
Überprüfen der Port-Konfiguration des Speicherprozessors
Sie können die Port-Konfiguration des Speicherprozessors überprüfen, indem
Sie die Informationen des VI-Clients mit den Informationen im Profil des
DS4000-Subsystems vergleichen.
So überprüfen Sie die Port-Konfiguration des Speicherprozessors
1
Stellen Sie mit einem VI-Client eine Verbindung mit dem ESX Server-Host her.
2
Wählen Sie den Host aus, und klicken Sie auf die Registerkarte Konfiguration.
3
Klicken Sie im Hardware-Fenster auf Storage-Adapter.
4
Wählen Sie die einzelnen Speicheradapter aus, um ihren WWPN anzuzeigen.
5
Wählen Sie Speicher, um die verfügbaren Datastores anzuzeigen.
Vergleichen Sie die WWPN-Informationen mit den Informationen im Profil des
DS4000-Speichersubsystems.
VMware, Inc.
69
Deaktivieren der automatischen Volume-Übertragung (AVT)
Um ein potenzielles Pfad-Thrashing zu verhindern, deaktivieren Sie die automatische
Volume-Übertragung (Auto Volume Transfer, AVT) für die SAN-Speicherprozessoren.
Wenn AVT aktiviert ist, können die beiden Speicherprozessoren die LUN in
bestimmten Situationen abwechselnd beanspruchen, wodurch die Performance
beeinträchtigt wird. AVT wird auch als ADT (Auto Disk Transfer) bezeichnet.
Weitere Informationen finden Sie unter „Auflösen von Pfad-Thrashing“ auf Seite 113.
Um AVT zu deaktivieren, stellen Sie den Host-Typ im DS 4000 Storage Manager auf
LNXCL ein, und zwar für jeden Port, der in allen Host-Gruppen mit HBAs für einen oder
mehrere ESX Server-Rechner definiert ist.
HINWEIS Nachdem Sie die AVT-Konfiguration geändert haben, müssen Sie den
ESX Server-Host neu starten.
Konfigurieren von Sense-Daten des Speicherprozessors
Speicherprozessoren können so konfiguriert werden, dass sie im
Ruhezustand entweder Unit Attention oder Not Ready zurückgeben. Ein
DS4000-Speicherprozessor, der unter Windows als Gastbetriebssystem ausgeführt
wird, sollte im Ruhezustand die Sense-Daten Not Ready zurückgeben. Die Rückgabe
von Unit Attention kann bei einem Failover zu einem Absturz des
Windows-Gastbetriebssystems führen.
So konfigurieren Sie die Speicherprozessoren für die Rückgabe der Sense-Daten
Not Ready
1
Bestimmen Sie den Index für den Host-Typ LNXCL, indem Sie die folgenden
Befehle in einem Shell-Fenster eingeben. Drücken Sie nach jedem Befehl
die Eingabetaste.
SMcli.exe <IP-Adr-für-SPA> show hosttopology; <Eingabetaste>
SMcli.exe <IP-Adr-für-SPB> show hosttopology; <Eingabetaste>
Bei den folgenden Befehlen wird davon ausgegangen, dass 13 dem Index für
LNXCL in den NVSRAM-Host-Typ-Definitionen entspricht. Wenn Ihre
Speicherprozessoren einen anderen Index für LNXCL aufweisen, ersetzen Sie
diesen Index in den folgenden Befehlen durch 13.
2
Führen Sie die folgenden Befehle für SPA aus, damit dieser die Sense-Daten Not
Ready zurückgibt. Drücken Sie die Eingabetaste erst, nachdem Sie alle Befehle
eingegeben haben.
SMcli.exe <IP-Adr-für-SPA>
set controller [a] HostNVSRAMBYTE [13,0x12]=0x01;
set controller [a] HostNVSRAMBYTE [13,0x13]=0x00;
reset Controller [a];
<Eingabetaste>
70
VMware, Inc.
3
Führen Sie die folgenden Befehle für SPB aus, damit dieser die Sense-Daten Not
Ready zurückgibt. Drücken Sie die Eingabetaste erst, nachdem Sie alle Befehle
eingegeben haben.
SMcli.exe <IP-Adr-für-SPB>
set controller [b] HostNVSRAMBYTE [13,0x12]=0x01;
set controller [b] HostNVSRAMBYTE [13,0x13]=0x00;
reset Controller [b];
<Eingabetaste>
HINWEIS Wenn Sie die DS4000 Storage Manager-GUI verwenden, fügen Sie die
Konfigurationsbefehle für beide Speicherprozessoren in ein Skript ein, und
konfigurieren Sie die Speicherprozessoren gleichzeitig. Wenn Sie SMcli.exe
verwenden, müssen Sie mit jedem Speicherprozessor einzelne
Verbindungen herstellen.
IBM TotalStorage DS4000 und Pfad-Thrashing
Wenn Path-Thrashing bei einem DS 4000 oder einem kompatiblen SAN-Array
festgestellt wird, wird die folgende Warnung in das VMkernel-Protokoll geschrieben.
FAStT SAN is path thrashing with another system. Check AVT setting.
IBM TotalStorage 8000
IBM TotalStorage 8000-Systeme verwenden einen Aktiv/Aktiv-Array, der keine
besondere Konfiguration in Verbindung mit VMware ESX Server erfordert.
Um RDMs verwenden zu können, muss jedem ESX Server-Host im Cluster eine
bestimmte LUN mit der gleichen LUN-ID zugeordnet werden.
Aktivieren Sie im TotalStorage Configuration Management-Tool das Kontrollkästchen
Use same ID for LUN in source and target.
HINWEIS Wenn Sie den ESX Server-Host für den Systemstart über eine SAN-LUN in einem IBM
TotalStorage 8000-Array konfigurieren, deaktivieren Sie den internen Fibre-Port für
das entsprechende Blade, bis die Installation abgeschlossen ist.
Automatische Resignatur
Die automatische Resignatur wird für IBM TotalStorage 8000-Systeme
nicht unterstützt.
VMware, Inc.
71
HP StorageWorks-Speichersysteme
Dieser Abschnitt enthält Informationen zur Konfiguration der verschiedenen
HP StorageWorks-Speichersysteme. In diesem Abschnitt werden folgende
Themen behandelt:

„HP StorageWorks MSA“ auf Seite 72.

„HP StorageWorks EVA“ auf Seite 74.

„HP StorageWorks XP“ auf Seite 74.
Weitere Informationen finden Sie in den HP ActiveAnswers im Abschnitt zu VMware
ESX Server unter
http://h71019.www7.hp.com/ActiveAnswers/cache/71086-0-0-0-121.html.
HP StorageWorks MSA
Dieser Abschnitt enthält Themen, die für Sie interessant sind, wenn Sie die
Aktiv/Passiv-Version von HP StorageWorks MSA verwenden.
Festlegen des Profilnamens „Linux“
Um HP StorageWorks MSA 1000 und MSA 1500 mit ESX Server-Systemen verwenden
zu können, müssen Sie die FC-Verbindungen zwischen dem SAN-Array und dem
ESX Server-Host konfigurieren und den Profilnamen Linux festlegen.
So legen Sie den Profilnamen für eine Verbindung fest
1
Richten Sie über die Befehlszeilen-Oberfläche des MSA 1000 eine statische
Verbindung mit dem MSA 1000 ein.
Informationen zur Installation und Konfiguration der Befehlszeilen-Oberfläche
finden Sie in der Dokumentation zu HP StorageWorks MSA 1000.
HINWEIS Die Verbindungseinstellungen können nicht mit dem HP Array Configuration
Utility festgelegt werden.
72
2
Verbinden Sie die Befehlszeilen-Oberfläche des MSA 1000 mit dem MSA 1000.
3
Stellen Sie sicher, dass das FC-Netzwerk zwischen dem MSA 1000 und dem
ESX Server-Host funktioniert.
VMware, Inc.
4
Rufen Sie die Befehlszeilen-Oberfläche auf, und geben Sie Folgendes in die
Befehlszeile ein:
SHOW CONNECTIONS
Zu jedem FC-WWNN und -WWPN, der dem MSA 1000 zugeordnet ist, wird eine
Verbindungsspezifikation angezeigt:
Connection Name: <unbekannt>
Host WWNN = 20:02:00:a0:b8:0c:d5:56
Host WWPN = 20:03:00:a0:b8:0c:d5:57
Profile Name = Default
Unit Offset 0
Controller 1 Port 1 Status = Online
5
Stellen Sie sicher, dass der WWNN und WWPN des Hosts die richtige Verbindung
zu jedem FC-Adapter auf dem ESX Server-Rechner anzeigen.
6
Erstellen Sie mit folgendem Befehl eine statische Verbindung:
ADD CONNECTION ESX_CONN_1 WWNN=20:02:00:a0:b8:0c:d5:56
WWPN=20:03:00:a0:b8:0c:d5:57 PROFILE=LINUX
7
Überprüfen Sie die Verbindung mit folgendem Befehl:
SHOW CONNECTIONS
Die Ausgabe zeigt eine einzelne Verbindung mit dem WWNN/WWPN-Paar
20:02:00:a0:b8:0c:d5:56 und 20:03:00:a0:b8:0c:d5:57 sowie den
Profilnamen Linux:
Connection Name: ESX_CONN_1
Host WWNN = 20:02:00:a0:b8:0c:d5:56
Host WWPN = 20:03:00:a0:b8:0c:d5:57
Profile Name = Linux
Unit Offset = 0
HINWEIS Stellen Sie sicher, dass für WWNN = 20:02:00:a0:b8:0c:d5:56 und WWPN =
20:03:00:a0:b8:0c:d5:57 nur eine Verbindung angezeigt wird.
Für WWNN= 20:02:00:a0:b8:0c:d5:56 und WWPN = 20:03:00:a0:b8:0c:d5:57
sollte keine Verbindung mit dem Verbindungsnamen unbekannt angezeigt
werden.
8
VMware, Inc.
Fügen Sie für jeden WWNN und WWPN auf dem ESX Server-Host statische
Verbindungen (mit unterschiedlichen Werten für den Verbindungsnamen) hinzu.
73
Probleme mit dem Hub-Controller
Es ist möglich, dass das ESX Server-System nicht einwandfrei mit dem
MSA-Hub-Controller funktioniert. Verwenden Sie stattdessen den internen 2/8-Switch
oder den Single Port Controller.
HP StorageWorks EVA
Es gibt zwei Arten von HP StorageWorks EVA-Systemen: das Aktiv/Passiv-System
EVA_GL und das Aktiv/Aktiv-System EVA_XL.
Legen Sie als Verbindungstyp Benutzerdefiniert fest, wenn Sie einem ESX Server-Host
eine LUN zuordnen. Die Werte lauten folgendermaßen:

Für HP EVAgl 3000/5000 (Aktiv/Passiv) verwenden Sie den Host-Modustyp
000000002200282E.

Für HP EVAgl-Firmware 4.001 (Aktiv/Aktiv-Firmware für GL-Reihe) und höher
verwenden Sie den Host-Modustyp VMware.

Für EVA4000/6000/8000-Aktiv/Aktiv-Arrays mit Firmware unter 5.031 verwenden
Sie den Host-Modustyp 000000202200083E.

Für EVA4000/6000/8000-Aktiv/Aktiv-Arrays mit Firmware 5.031 und höher
verwenden Sie den Host-Modustyp VMware.
Darüber hinaus erfordern EVA-Systeme keine besonderen
Konfigurationsanpassungen in Verbindung mit einem ESX Server-System.
Ausführliche Informationen finden Sie im Dokument VMware Infrastructure 3,
HP StorageWorks Best Practices unter
http://h71019.www7.hp.com/ActiveAnswers/downloads/VMware3_StorageWorks_
BestPractice.pdf.
HP StorageWorks XP
Legen Sie für HP StorageWorks XP den Host-Modus Windows fest (nicht Linux). Dieses
System ist von Hitachi Data Systems erhältlich. Weitere Informationen finden Sie unter
„Hitachi Data Systems-Speicher“ auf Seite 75.
74
VMware, Inc.
Hitachi Data Systems-Speicher
Dieser Abschnitt enthält einen Überblick über die Einrichtung von Hitachi
Data Systems-Speichern. Diese Speicherlösung ist auch von Sun und als
HP XP-Speicher erhältlich.

LUN-Maskierung – Um optimale Ergebnisse beim Maskieren von LUNs auf
einem ESX Server-Host zu erzielen, sollten Sie die HDS Storage
Navigator-Software verwenden.

Microcode und Konfigurationen – Informationen über die zur Interoperabilität
mit ESX Server erforderlichen Konfigurationen und Microcode-Level erhalten Sie
von Ihrem HDS-Vertreter. Wenn Ihr Microcode nicht unterstützt wird, ist
normalerweise keine Interaktion mit ESX Server möglich.

Modi – Die von Ihnen festgelegten Modi hängen davon ab, welches Modell
Sie verwenden:

9900 und 9900v verwenden den Netware-Host-Modus.

Die 9500v-Reihe verwendet den Host-Modus 1: Standard und Host-Modus 2:
SUN-Cluster.
Network Appliance-Speicher
Befolgen Sie zur Konfiguration eines Speicher-Devices von Network Appliance die
Anweisungen in den folgenden Abschnitten:

„Festlegen des LUN- und Initiatorgruppentyps“ auf Seite 75.

„Speicherbereitstellung“ auf Seite 76.
Festlegen des LUN- und Initiatorgruppentyps
Sie müssen für den Speicher-Array den entsprechenden LUN- und
Initiatorgruppentyp festlegen:

LUN-Typ – VMware (wenn VMware nicht verfügbar ist, verwenden Sie Linux).

Initiatorgruppentyp – VMware (wenn VMware nicht verfügbar ist, verwenden
Sie Linux).
VMware, Inc.
75
Speicherbereitstellung
Sie müssen Speicher bereitstellen.
So stellen Sie Speicher über ein Network Appliance-Speicher-Device bereit
1
Erstellen Sie über die Befehlszeilen-Oberfläche oder die FilerView-GUI ein
Aggregat, sofern erforderlich.
aggr create <WMware-Aggr> <Anzahl der Festplatten>
2
Erstellen Sie ein flexibles Volume.
vol create <Aggregatname> <Volume-Größe>
3
Erstellen Sie einen Qtree zum Speichern der LUNs.
qtree create <Pfad>
4
Erstellen Sie eine LUN.
lun create -s <Größe> -t vmware <Pfad>
5
Erstellen Sie eine Initiatorgruppe.
igroup create -f -t vmware <Initiatorgruppenname>
6
Ordnen Sie die LUN der zuvor erstellten Initiatorgruppe zu.
lun map (<Pfad>) <Initiatorgruppenname> <LUN-ID>
Weitere Informationen zur Verwendung von Network Appliance-Speichern mit
VMware-Technologie finden Sie in den folgenden Network Appliance-Dokumenten:
76

Network Appliance & VMware ESX Server: Instantaneous Backup & Recovery with
NetApp Snapshot Technology unter http://www.netapp.com/library/tr/3428.pdf.

Technical Case Study: Using a Network Appliance SAN with VMware to Facilitate
Storage and Server Consolidation unter http://www.netapp.com/library/tr/3401.pdf.
VMware, Inc.
5
Verwenden des
Systemstarts über SAN mit
ESX Server-Systemen
5
In diesem Kapitel werden die Vorteile eines Systemstarts über SAN sowie die
Aufgaben beschrieben, die ausgeführt werden müssen, wenn das Boot-Image von
ESX Server auf einer SAN-LUN gespeichert werden soll.
HINWEIS Wenn der ESX Server-Host nicht über ein SAN gestartet werden soll, können
Sie dieses Kapitel überspringen.
In diesem Kapitel werden folgende Themen behandelt:

„Einführung in den Systemstart über SAN“ auf Seite 78.

„Vorteile des Systemstarts über SAN“ auf Seite 79.

„Vorbereitungen für den Systemstart über SAN“ auf Seite 79.

„Einrichten des FC-HBA für den Systemstart über SAN“ auf Seite 83.
VMware, Inc.
77
Einführung in den Systemstart über SAN
Bevor Sie sich überlegen, wie Sie Ihr System für den Systemstart über SAN einrichten,
sollten Sie abwägen, ob dies für Ihre Umgebung überhaupt sinnvoll ist.
In folgenden Fällen ist ein Systemstart über SAN sinnvoll:

Wenn Sie den lokalen Speicher nicht warten möchten.

Wenn Sie Wert auf einfaches Klonen von Servicekonsolen legen.

In Hardware-Konfigurationen ohne Festplatte, z. B. bei einigen Blade-Systemen.
In folgenden Fällen ist ein Systemstart über SAN nicht sinnvoll:

Wenn Sie Microsoft Cluster Service verwenden.

Wenn die Gefahr von I/O-Kollisionen zwischen der Servicekonsole und
VMkernel besteht.
HINWEIS In ESX Server 2.5 wurde der Systemstart über SAN in Verbindung mit RDM
nicht unterstützt. Diese Einschränkung wurde in ESX Server 3.0 aufgehoben.
Weitere Informationen finden Sie unter „Funktionsweise des Systemstarts über SAN“
auf Seite 78.
Funktionsweise des Systemstarts über SAN
Wenn Sie Ihr System für den Systemstart über SAN einrichten, wird das Boot-Image
nicht auf der lokalen Festplatte des ESX Server-Systems, sondern auf einer SAN-LUN
gespeichert (siehe Abbildung 5-1).
ESX Server
ServiceKonsole
VMkernel
HBA
FC-Switch
Speicher-Array
Boot-Laufwerk
Abbildung 5-1. Funktionsweise des Systemstarts über SAN
78
VMware, Inc.
Kapitel 5 Verwenden des Systemstarts über SAN mit ESX Server-Systemen
Ein System, das für den Systemstart über SAN eingerichtet ist, muss folgende
Voraussetzungen erfüllen:

Das HBA-BIOS muss die FC-Karte als Boot-Controller bestimmen. Weitere
Informationen finden Sie unter „Einrichten des FC-HBA für den Systemstart über
SAN“ auf Seite 83.

Die FC-Karte muss so konfiguriert sein, dass eine einfache Verbindung mit dem
über die Boot-LUN angesteuerten Ziel initiiert wird.
Vorteile des Systemstarts über SAN
In einer Umgebung, die für den Systemstart über SAN eingerichtet wurde, ist das
Betriebssystem auf einer oder mehreren LUNs im SAN-Array installiert. Die Server
werden über den Speicherort des Boot-Images informiert. Der Start der Server erfolgt
über die LUNs im SAN-Array.
HINWEIS Wenn Sie den Systemstart über SAN in Verbindung mit einem VMware ESX
Server-System verwenden, muss jeder Server über seine eigene Boot-LUN verfügen.
Ein Systemstart über SAN bietet unter anderem folgende Vorteile:

Günstigere Server – Server können dichter gepackt werden und ohne internen
Speicher kühler laufen.

Einfacherer Austausch von Servern – Sie können Server austauschen und neue
Server auf den alten Boot-Speicherort verweisen lassen.

Weniger Platzverschwendung.

Einfachere Backup-Prozesse – Die Boot-Images im SAN können im Rahmen des
SAN-Backups gesichert werden.

Verbessertes Management – Die Erstellung und Verwaltung des
Betriebssystem-Images ist einfacher und effizienter.
Vorbereitungen für den Systemstart über SAN
Neben der allgemeinen Konfiguration von ESX Server in Verbindung mit einem
SAN müssen Sie die folgenden Aufgaben ausführen, um den ESX Server-Host für den
Systemstart über SAN einzurichten.
So richten Sie den Systemstart über SAN ein
1
Stellen Sie sicher, dass die Konfigurationseinstellungen die allgemeinen
Anforderungen für den Systemstart über SAN erfüllen.
Weitere Informationen finden Sie unter „Voraussetzungen für einen
ESX Server-Systemstart über SAN“ auf Seite 57.
VMware, Inc.
79
2
Bereiten Sie die Hardware-Komponenten vor.
Dazu zählen HBA, Netzwerk-Devices und das Speichersystem. Entsprechende
Anweisungen können Sie der Produktdokumentation der jeweiligen Devices
entnehmen. Weitere Informationen finden Sie unter „Einrichten des FC-HBA für
den Systemstart über SAN“ auf Seite 83.
3
Konfigurieren Sie die LUN-Maskierung im SAN.
Dadurch wird sichergestellt, dass jeder ESX Server-Host über eine dedizierte
LUN für die Boot-Partitionen verfügt. Die Boot-LUN muss einem einzelnen
Server zugeordnet sein.
4
Wählen Sie den Speicherort für die Diagnosepartition.
Diagnosepartitionen können auf der gleichen LUN wie die Boot-Partition
gespeichert werden. Speicherabbilder werden in Diagnosepartitionen gespeichert.
Weitere Informationen finden Sie unter „Gemeinsame Nutzung von
Diagnosepartitionen“ auf Seite 109.
Im übrigen Teil dieses Abschnitts werden die Aufgaben beschrieben, die ausgeführt
werden müssen, bevor ein ESX Server-Rechner über SAN gestartet werden kann.
Es werden folgende Themen behandelt:

„Grundsätzliche Überlegungen“ auf Seite 80.

„Vorbereiten des SAN“ auf Seite 81.

„Minimieren der Anzahl an Initiatoren“ auf Seite 82.
Grundsätzliche Überlegungen
Bevor Sie beginnen, sollten Sie folgende Schritte ausführen:
1
2
80
Prüfen Sie die Empfehlungen oder Beispiele für die von Ihnen
gewünschte Einrichtung:

Einzelne oder redundante Pfade zur Boot-LUN.

FC-Switch-Fabric.

Spezielle Empfehlungen zu Ihrem Speicher-Array.
Prüfen Sie eventuelle Einschränkungen und Anforderungen, z. B. folgende:

Einschränkungen für den Systemstart über SAN.

Der vom Hersteller empfohlene Speicher-Array für den Systemstart
über SAN.

Der vom Hersteller empfohlene Server für den Systemstart über SAN.
VMware, Inc.
3
Suchen Sie den WWN für den Boot-Pfad-HBA mit einer der folgenden Methoden:

Wechseln Sie beim Start in das FC-HBA-BIOS.

Suchen Sie den WWN auf der physischen Karte. Dieser ist vergleichbar mit
einer MAC-Adresse.
LUN-Maskierung beim Systemstart über SAN
Beim Systemstart über SAN spielt die richtige LUN-Maskierung eine
entscheidende Rolle.

Jeder Server darf lediglich seine eigene Boot-LUN erkennen, nicht die Boot-LUNs
anderer Server.

Mehrere Server können eine Diagnosepartition gemeinsam nutzen. Dies erreichen
Sie durch die LUN-Maskierung. Weitere Informationen finden Sie unter
„Gemeinsame Nutzung von Diagnosepartitionen“ auf Seite 109.
Vorbereiten des SAN
Dieser Abschnitt enthält die Schritte, mit denen das SAN-Speicher-Array für den
Systemstart über SAN vorbereitet wird. Schritte 3 bis 7 beziehen sich explizit auf den
Systemstart über SAN, Schritte 1 und 2 hingegen nicht.
So bereiten Sie das SAN vor
1
Verbinden Sie die FC- und Ethernet-Kabel gemäß den für Ihre Einrichtung
geltenden Anweisungen.
Überprüfen Sie die FC-Switch-Verkabelung, falls vorhanden.
2
VMware, Inc.
Konfigurieren Sie den Speicher-Array.
a
Machen Sie den ESX Server-Host über den SAN-Speicher-Array im
SAN sichtbar. Dieser Schritt wird häufig mit der Erstellung eines
Objekts gleichgesetzt.
b
Richten Sie den ESX Server-Host über den SAN-Speicher-Array so ein,
dass die WWPNs der FC-Adapter des Hosts den Port- oder
Node-Namen entsprechen.
c
Erstellen Sie LUNs.
d
Weisen Sie LUNs zu.
e
Notieren Sie die IP-Adressen der FC-Switches und Speicher-Arrays.
f
Notieren Sie den WWPN für jeden beteiligten Speicherprozessor und
Host-Adapter.
81
HINWEIS Wenn Sie zum Installieren von ESX Server im „Systemstart über SAN“-Modus
eine Skript-Installation verwenden, müssen Sie bestimmte Schritte ausführen,
um unbeabsichtigte Datenverluste zu vermeiden. Weitere Informationen finden
Sie im VMware-Wissensbasis-Artikel 1540 unter
http://www.vmware.com/support/kb/enduser/std_adp.php?p_faqid=1540.
3
4
Konfigurieren Sie das HBA-BIOS für den Systemstart über SAN, wie in den
folgenden Abschnitten beschrieben:

„Einrichten des QLogic-FC-HBA für den Systemstart über SAN“ auf Seite 83.

„Einrichten des Emulex-FC-HBA für den Systemstart über SAN“ auf Seite 85
Starten Sie das ESX Server-System über die Installations-CD von ESX Server.
Weitere Informationen finden Sie im Handbuch für Installation und Upgrade.
Das QLogic-BIOS verwendet für die Suche nach einem Boot-Image eine Suchliste
von Pfaden (wwpn:lun). Wenn einer der wwpn:lun-Pfade mit einem passiven Pfad
verknüpft ist (z. b. bei CLARiiON- oder IBM TotalStorage DS 4000-Systemen denkbar),
behält das BIOS den passiven Pfad bei, anstatt einen aktiven Pfad zu suchen. Wenn Sie
das ESX Server-System über eine SAN-LUN starten, schlägt der Startvorgang fehl,
solange der Host versucht, auf den passiven Pfad zuzugreifen.
Minimieren der Anzahl an Initiatoren
Stellen Sie sicher, dass die Zone eine minimale Anzahl an Host- und Speicherports
enthält. Wenn mehrere Initiatoren in der gleichen Zone enthalten sind und Sie
versuchen, eine Boot-LUN auszuwählen, kann dies zum Absturz des Emulex- und
QLogic-BIOS führen.
Enthält eine Zone beispielsweise fünfzehn Initiatoren und vier Symmetrix-Ports,
können Sie möglicherweise keine Boot-LUN über das Emulex- oder QLogic-BIOS
auswählen, da es nicht reagiert. Beschränken Sie die Zone für die beiden Host-Ports
hingegen auf die vier Speicherports, ist es möglich, eine Boot-LUN auszuwählen.
82
VMware, Inc.
Einrichten des FC-HBA für den Systemstart über SAN
In diesem Abschnitt wird beschrieben, wie die HBAs eingerichtet werden:

„Einrichten des QLogic-FC-HBA für den Systemstart über SAN“ auf Seite 83.

„Einrichten des Emulex-FC-HBA für den Systemstart über SAN“ auf Seite 85.
Einrichten des QLogic-FC-HBA für den Systemstart über SAN
Um das QLogic-HBA-BIOS so zu konfigurieren, dass ESX Server über SAN startet,
müssen folgende Aufgaben ausgeführt werden:

„Aktivieren des QLogic-HBA-BIOS“ auf Seite 83.

„Aktivieren der Boot-Auswahl“ auf Seite 84.

„Auswählen der Boot-LUN“ auf Seite 84.

„Einrichten des Systemstarts über CD-ROM“ auf Seite 85.
HINWEIS Wenn Sie ein IBM BladeCenter verwenden, trennen Sie alle lokalen Festplatten
vom Server.
Aktivieren des QLogic-HBA-BIOS
Um das QLogic-HBA-BIOS so zu konfigurieren, dass ESX Server über SAN startet,
müssen Sie zunächst das QLogic-HBA-BIOS aktivieren.
So aktivieren Sie das QLogic-HBA-BIOS
1
2
3
VMware, Inc.
Rufen Sie das Konfigurationsdienstprogramm BIOS Fast!UTIL auf:
a
Starten Sie den Server.
b
Drücken Sie beim Hochfahren des Servers die Tasten Strg+Q.
Führen Sie je nach Anzahl der HBAs einen der folgenden Schritte aus.

Wenn Sie über einen HBA verfügen, wird die Seite mit den
Fast!UTIL-Optionen angezeigt. Fahren Sie fort mit Schritt 3.

Wenn Sie über mehrere HBAs verfügen, wählen Sie den entsprechenden
HBA manuell aus:
i
Platzieren Sie den Cursor auf der Seite Select Host Adapter mit den
Pfeiltasten auf dem HBA.
ii
Betätigen Sie die Eingabetaste.
Wählen Sie auf der Seite Fast!UTIL Option die Option Configuration Settings
aus, und drücken Sie die Eingabetaste.
83
4
Wählen Sie auf der Seite Configuration Settings die Option Host Adapter
Settings, und drücken Sie die Eingabetaste.
5
Richten Sie das BIOS für die Suche nach SCSI-Devices ein:
a
Wählen Sie auf der Seite Host Adapter Settings die Option Host Adapter
BIOS aus.
b
Drücken Sie die Eingabetaste, um den Wert in Aktiviert zu ändern.
c
Drücken Sie zum Beenden die Esc-Taste.
Aktivieren der Boot-Auswahl
Sie müssen die Boot-Auswahl aktivieren.
So aktivieren Sie die Boot-Auswahl
1
Wählen Sie Selectable Boot Settings, und drücken Sie die Eingabetaste.
2
Wählen Sie auf der Seite Selectable Boot Settings die Option Selectable Boot.
3
Drücken Sie die Eingabetaste, um den Wert in Aktiviert zu ändern.
Auswählen der Boot-LUN
Wenn Sie ein Aktiv/Passiv-Speicher-Array verwenden, muss sich der ausgewählte
SP im bevorzugten (aktiven) Pfad zur Boot-LUN befinden. Wenn Sie nicht
sicher sind, welcher SP sich im aktiven Pfad befindet, überprüfen Sie dies mit der
Management-Software des Speicher-Arrays. Die Ziel-IDs werden vom BIOS erstellt
und können sich bei jedem Neustart ändern.
So wählen Sie die Boot-LUN aus
1
Wählen Sie mit den Pfeiltasten den ersten Eintrag in der Liste der
Speicherprozessoren aus, und drücken Sie die Eingabetaste, um die
Seite Select Fibre Channel Device zu öffnen.
2
Wählen Sie mit den Pfeiltasten den gewünschten Speicherprozessor (SP) aus, und
drücken Sie die Eingabetaste.

Wenn dem SP nur eine LUN zugeordnet ist, wird diese automatisch als
Boot-LUN ausgewählt. In diesem Fall können Sie mit Schritt 3 fortfahren.

Wenn dem SP mehrere LUNs zugeordnet sind, wird die Seite Select LUN
angezeigt. Wählen Sie mit den Pfeiltasten die gewünschte LUN aus, und
drücken Sie die Eingabetaste.
Platzieren Sie den Cursor auf den übrigen Speicherprozessoren in der Liste,
und drücken Sie C, um die Daten zu löschen.
3
84
Drücken Sie zum Beenden zweimal die Esc-Taste, und drücken Sie die
Eingabetaste, um die Einstellung zu speichern.
VMware, Inc.
Einrichten des Systemstarts über CD-ROM
Da sich die VMware-Installations-CD im CD-ROM-Laufwerk befindet, müssen Sie das
System zunächst für den Systemstart über CD-ROM einrichten. Dazu müssen Sie die
Startabfolge in der BIOS-Einrichtung des Systems ändern.
Auf dem IBM X-Series 345-Server müssen Sie beispielsweise folgende
Schritte ausführen:
1
Rufen Sie beim Hochfahren des Systems das Dienstprogramm für die
BIOS-Konfiguration/Einrichtung auf.
2
Wählen Sie Startup Options, und drücken Sie die Eingabetaste.
3
Wählen Sie Startup Sequence Options, und drücken Sie die Eingabetaste.
4
Ändern Sie First Startup Device in [CD-ROM].
Anschließend können Sie das ESX Server-System wie im Handbuch für Installation und
Upgrade beschrieben installieren.
Einrichten des Emulex-FC-HBA für den Systemstart über SAN
Um das Emulex-HBA-BIOS so zu konfigurieren, dass ESX Server über SAN startet,
müssen folgende Aufgaben ausgeführt werden:

Aktivieren der Boot-BIOS-Eingabeaufforderung (siehe „So aktivieren Sie die
Boot-BIOS-Eingabeaufforderung“).

Aktivieren des Boot-BIOS (siehe „So aktivieren Sie das BIOS“).
So aktivieren Sie die Boot-BIOS-Eingabeaufforderung
1
Führen Sie über die ESX Server-Servicekonsole oder eine
Linux-Eingabeaufforderung den Befehl lputil aus.
HINWEIS Es besteht die Möglichkeit, den ESX Server-Host über eine
Linux-Administrations-CD zu starten, um den Emulex-Treiber zu laden, und
anschließend den Befehl lputil darüber auszuführen.
2
Wählen Sie <3> Firmware Maintenance.
3
Wählen Sie einen Adapter aus.
4
Wählen Sie <6> Boot BIOS Maintenance.
5
Wählen Sie <1> Enable Boot BIOS.
VMware, Inc.
85
So aktivieren Sie das BIOS
1
Starten Sie den ESX Server-Rechner neu.
2
Drücken Sie an der Emulex-Eingabeaufforderung die Tasten <ALT+E>.
3
86
a
Wählen Sie einen Adapter (mit BIOS-Unterstützung) aus.
b
Wählen Sie <2> Configure Adapter's Parameters.
c
Wählen Sie <1> Enable or Disable BIOS.
d
Wählen Sie <1>, um das BIOS zu aktivieren.
e
Wählen Sie zum Beenden <x> aus und <N>, um zum
Hauptmenü zurückzukehren.
Gehen Sie im Emulex-Hauptmenü wie folgt vor:
a
Wählen Sie den gleichen Adapter aus.
b
Wählen Sie <1> Configure Boot Devices.
c
Wählen Sie den Speicherort für den Boot-Eintrag aus.
d
Geben Sie das zweistellige Boot-Device ein.
e
Geben Sie die zweistellige (HEX) Boot-LUN ein (z. B. 08).
f
Wählen Sie die Boot-LUN aus.
g
Wählen Sie <1> WWPN aus. (Starten Sie das Device über den WWPN,
nicht die DID).
h
Wählen Sie zum Beenden <x> aus und <Y>, um neu zu starten.
4
Rufen Sie das BIOS auf, und verschieben Sie Emulex in der Abfolge des
Boot-Controllers an die erste Stelle.
5
Starten Sie neu, und führen Sie die Installation auf einer SAN-LUN durch.
VMware, Inc.
6
Verwalten von
ESX Server-Systemen, die
SAN-Speicher verwenden
6
Dieses Kapitel unterstützt Sie bei der effektiven Verwaltung Ihres ESX Server-Systems,
das SAN-Speicher einsetzt, sowie bei der Fehlerbehebung. Folgende Themen
werden behandelt:

„Probleme und Lösungen“ auf Seite 88.

„Abrufen von Informationen“ auf Seite 89.

„Lösen von Anzeigeproblemen“ auf Seite 92.

„Erweiterte Konfiguration der LUN-Anzeige“ auf Seite 95.

„Failover“ auf Seite 105.

„Konfiguration des VMkernels“ auf Seite 108.

„Vermeiden und Beheben von Problemen“ auf Seite 109.

„Optimieren der SAN-Speicherleistung“ auf Seite 110.

„Lösen von Leistungsproblemen“ auf Seite 112.

„Überlegungen zum SAN-Speicher-Backup“ auf Seite 118.

„Anwendungen mit mehreren Ebenen“ auf Seite 121.

„VMFS-Volume-Resignatur“ auf Seite 122.
VMware, Inc.
87
Probleme und Lösungen
In Tabelle 6-1 sind die am häufigsten auftretenden Probleme aufgeführt. Es wird
entweder ein Lösungsvorschlag angegeben oder auf den Abschnitt verwiesen, in dem
das Problem behandelt wird.
Tabelle 6-1. Probleme und Lösungen
Problem
Lösung
Im VI-Client ist keine LUN
sichtbar.
Siehe „Lösen von Anzeigeproblemen“ auf Seite 92.
Eine gemeinsam genutzte LUN
und ein darauf formatiertes
VMFS-Dateisystem sind nicht für
alle ESX Server-Hosts sichtbar,
die auf die LUN zugreifen.
Siehe „Probleme mit der Anzeige derselben LUN-ID auf
mehreren Hosts“ auf Seite 123.
Sie möchten wissen, wie der
Pfad-Failover ausgeführt wird
oder die Ausführung des
Pfad-Failovers ändern.
Mithilfe des VI-Clients können Sie diese Aktionen ausführen. Siehe
Sie möchten die aktuelle
Multipathing-Policy oder den
bevorzugten Pfad anzeigen oder
ändern oder einen Pfad
deaktivieren oder aktivieren.
Mithilfe des VI-Clients können Sie diese Aktionen ausführen. Siehe
Sie müssen das
Windows-Festplatten-Timeout
erhöhen, um eine Unterbrechung
während des Failovers
zu vermeiden.
Siehe „Festlegen des Betriebssystem-Timeouts“ auf Seite 108.
Sie müssen Treiberoptionen für
den QLogic- oder Emulex-HBA
anpassen.
Siehe „Festlegen von Device-Treiberoptionen für SCSI-Controller“
auf Seite 107.
Der Server kann nicht oder nur
langsam auf eine LUN zugreifen.
Das Problem wird u. U. durch Pfad-Thrashing verursacht. Siehe
„Auflösen von Pfad-Thrashing“ auf Seite 113.
88
VMware, Inc.
Kapitel 6 Verwalten von ESX Server-Systemen, die SAN-Speicher verwenden
Tabelle 6-1. Probleme und Lösungen
Problem
Lösung
Der Zugriff ist langsam.
Wenn Sie über zahlreiche LUNs/VMFS-Volumes verfügen, die alle
den Typ VMFS-3 aufweisen, entfernen Sie den VMFS-2-Treiber, indem
Sie Folgendes an einer Befehlszeileneingabeaufforderung eingeben:
vmkload_mod -u vmfs2
Dadurch erhöht sich die Geschwindigkeit von
Management-Vorgängen, wie z. B. dem Aktualisieren
von Datastores und dem erneuten Scannen von
Speicheradaptern, erheblich.
Sie haben dem Speicher eine neue
LUN oder einen neuen Pfad
hinzugefügt, die bzw. der im
VI-Client angezeigt werden soll.
Sie müssen neu scannen. Siehe „Verwenden von „Neu scannen““ auf
Seite 94.
Mögliche Probleme
Halten Sie sich an die folgenden Richtlinien, um mögliche Probleme zu vermeiden:

Platzieren Sie auf jeder LUN nur ein VMFS-Volume. Mehrere VMFS-Volumes auf
einer LUN sind nicht empfehlenswert.

Ändern Sie die vom System festgelegte Pfad-Policy nicht. Insbesondere kann es zu
Pfad-Thrashing kommen, wenn Sie mit einem Aktiv/Passiv-Array arbeiten und
die Pfad-Policy auf Fest setzen.
Abrufen von Informationen
In diesem Abschnitt wird erläutert, wie Sie Informationen über HBAs, Status,
Multipathing usw. abrufen können. Sollten beim Ausführen dieser Aufgaben
Probleme auftreten, finden Sie unter „Lösen von Anzeigeproblemen“ auf Seite 92
weitere Informationen.
In diesem Abschnitt werden folgende Themen behandelt:

„Anzeigen von HBA-Informationen“ auf Seite 90.

„Anzeigen von Datastore-Informationen“ auf Seite 90.
VMware, Inc.
89
Anzeigen von HBA-Informationen
Mit dem VI-Client können Sie alle verfügbaren Speicheradapter und deren
Daten anzeigen.
So zeigen Sie eine Liste von HBA-Typen an:
1
Wählen Sie den Host aus, für den Sie die HBAs anzeigen möchten, und klicken Sie
auf die Registerkarte Konfiguration.
Über die Registerkarte Übersicht können Sie eine Liste aller Speicher-Devices
anzeigen. Hier können Sie jedoch keine Details anzeigen oder das Gerät verwalten.
2
Wählen Sie im Hardware-Fenster Storage-Adapter.
Eine Liste mit Speicheradaptern wird angezeigt. Sie können jeden Adapter
auswählen, um weitere Informationen anzuzeigen.
Anzeigen von Datastore-Informationen
Mit dem VI-Client können Sie alle formatierten Datastores anzeigen und Details zu
einem bestimmten Datastore prüfen.
So zeigen Sie alle Speicher-Devices und deren Details an:
1
90
Wählen Sie den Host aus, für den Sie die Speicher-Devices anzeigen möchten, und
klicken Sie auf die Registerkarte Konfiguration.
VMware, Inc.
2
Wählen Sie im Hardware-Fenster Speicher (SCSI, SAN und NFS).
Die Liste der Datastores (Volumes) wird im Fenster Speicher angezeigt.
Das gesamte VMFS für den ausgewählten Host wird angezeigt. Nur Speicher, der
mit VMFS formatiert wurde, wird in die Anzeige aufgenommen. In Abbildung 6-1
finden Sie ein Beispiel.
3
Um Details über einen Datastore anzuzeigen, wählen Sie den gewünschten
Datastore aus.
Im Fenster Details werden zusätzliche Informationen angezeigt. Dazu gehören
Speicherort und Kapazität, die Anzahl der Pfade, Pfad-Policy und Eigenschaften
sowie Erweiterungsinformationen.
Eine Erweiterung ist eine VMFS-formatierte Partition (Teil einer LUN). vmhba
0:0:14 ist z. B. eine LUN, und vmhba 0:0:14:1 ist eine Partition. Ein VMFS-Volume
kann mehrere Erweiterungen haben.
HINWEIS Die Abkürzung vmhba bezieht sich auf den physischen HBA (QLogic oder Emulex)
auf dem ESX Server-System, nicht auf den von den virtuellen Maschinen
verwendeten SCSI-Controller.
VMFS
Datastores
(formatiert)
Erweiterung
Abbildung 6-1. Anzeigen von Speicherinformationen
4
Klicken Sie auf Eigenschaften, um Eigenschaften anzuzeigen und zu ändern.
Multipathing-Informationen finden Sie unter „So zeigen Sie den aktuellen
Multipathing-Status an:“ auf Seite 98.
VMware, Inc.
91
Lösen von Anzeigeproblemen
In diesem Abschnitt wird erläutert, wie Sie häufig auftretende Probleme mit dem
Status und der Sichtbarkeit beheben:

„Erläuterungen zur LUN-Benennung in der Anzeige“ auf Seite 92.

„Beheben von Problemen mit nicht sichtbaren LUNs“ auf Seite 93.

„Verwenden von „Neu scannen““ auf Seite 94.

„Entfernen von Datastores“ auf Seite 95.
Wenn Sie einen AX100-Speicher-Array verwenden, können inaktive Verbindungen zu
Anzeigeproblemen führen. Siehe „AX100-Anzeigeprobleme mit inaktiven
Verbindungen“ auf Seite 65.
Erläuterungen zur LUN-Benennung in der Anzeige
Im VI-Client wird eine LUN als Abfolge von drei oder vier Zahlen angezeigt, die durch
Doppelpunkte getrennt sind:
<SCSI-HBA>:<SCSI-Ziel>:<SCSI-LUN>:<Festplattenpartition>
Wenn die letzte Zahl eine 0 ist oder nicht angezeigt wird, bezieht sich der Name auf die
gesamte LUN.
Die ersten drei Zahlen in einem ESX-Device-Namen können sich ändern, beziehen sich
aber trotzdem auf dasselbe physische Device. Beispiel: vmhba1:2:3 steht für
SCSI-LUN3, die an SCSI-Ziel 2 auf SCSI-HBA 1 angehängt ist. Wenn das
ESX Server-System neu gestartet wird, könnte sich der Device-Name für LUN 3 in
vmhba1:1:3 ändern. Die Zahlen haben folgende Bedeutung:
92

Die erste Zahl, der SCSI-HBA, ändert sich, wenn zu dem Zeitpunkt, zu dem das
System gestartet oder erneut gescannt wird, ein FC- oder iSCSI-Netzwerkausfall
auftritt und ESX über einen anderen SCSI-HBA auf das physische Device
zugreifen muss.

Die zweite Zahl, das SCSI-Ziel, ändert sich, wenn sich die Zuordnungen in den
FC- oder iSCSI-Zielen ändern, die für den ESX Server-Host sichtbar sind.

Die dritte Zahl, die SCSI-LUN, ändert sich nie.
VMware, Inc.
Beheben von Problemen mit nicht sichtbaren LUNs
Sie können LUNs mit dem VI-Client anzeigen.
Wenn die Anzeige (oder Ausgabe) von Ihren Erwartungen abweicht, prüfen
Sie Folgendes:

Kabelverbindung - Wenn Sie keinen Port sehen, könnte das Problem an der
Kabelverbindung oder Zoning liegen. Prüfen Sie zunächst die Kabel.

Zoning - Schränkt den Zugriff auf bestimmte Speicher-Devices an, erhöht die
Sicherheit und verringert den Netzwerkverkehr. Einige Speicheranbieter lassen
nur Zonen mit einem Initiator zu. In diesem Fall kann sich ein HBA in mehreren
Zonen befinden, die nur auf ein Ziel verweisen. Andere Anbieter lassen Zonen mit
mehreren Initiatoren zu. Zoning-Anforderungen finden Sie in der Dokumentation
Ihres Speicheranbieters. Verwenden Sie die SAN-Switch-Software zum
Konfigurieren und Verwalten des Zoning.

LUN-Masking - Wenn ein ESX Server-Host ein bestimmtes Speicher-Device,
jedoch nicht die für dieses Device erwarteten LUNs sieht, könnte es sein, dass das
LUN-Masking nicht ordnungsgemäß konfiguriert wurde.
Stellen Sie für einen Systemstart über SAN sicher, dass jeder ESX Server-Host nur
erforderliche LUNs sieht. Lassen Sie nicht zu, dass ein ESX Server-Host andere
Boot-LUNs anzeigen kann als seine eigenen. Verwenden Sie
Festplatten-Array-Software, um sicherzustellen, dass der ESX Server-Host nur die
LUNs sehen kann, die er sehen soll.
Stellen Sie sicher, dass die Einstellungen Disk.MaxLUN und Disk.MaskLUNs so
konfiguriert sind, dass Sie die LUN anzeigen können, die Sie erwarten. Siehe
„Ändern der Anzahl gescannter LUNs mithilfe von Disk.MaxLUN“ auf Seite 95
und „Masking von LUNs mithilfe von Disk.MaskLUNs“ auf Seite 96.

Speicherprozessor - Wenn ein Festplatten-Array mehrere Speicherprozessoren
enthält, stellen Sie sicher, dass der SAN-Switch mit dem SP verbunden ist, der
Eigentümer der LUNs ist, auf die Sie zugreifen möchten. Auf einigen
Festplatten-Arrays ist nur ein SP aktiv. Der andere SP ist passiv, bis ein Fehler
auftritt. Wenn Sie mit dem falschen SP (dem mit dem passiven Pfad) verbunden
sind, werden die erwarteten LUNs unter Umständen nicht angezeigt, oder die
LUNs werden angezeigt, jedoch werden beim Versuch, auf die LUNs zuzugreifen,
Fehler angezeigt.
VMware, Inc.
93
Verwenden von „Neu scannen“
Führen Sie jedes Mal einen erneuten Scan durch, wenn Sie:

Für einen neuen Festplatten-Array auf dem SAN Zoning zu einem
ESX Server-Host ausgeführt haben.

Neue LUNs auf einem SAN-Festplatten-Array erstellen.

Das LUN-Masking auf einem Festplatten-Array eines ESX Server-Hosts ändern.

Ein Kabel anders anschließen.

Eine Änderung an einem Host in einem Cluster vornehmen.
HINWEIS Führen Sie keinen erneuten Scan aus, wenn ein Pfad ausgefallen ist. Wenn ein Pfad
ausfällt, übernimmt der andere Pfad, und Ihr System ist weiterhin uneingeschränkt
funktionsfähig. Wenn Sie jedoch zu einem Zeitpunkt, zu dem ein Pfad nicht
verfügbar ist, einen erneuten Scan ausführen, entfernt der ESX Server-Host den Pfad
aus der Liste der Pfade zum Device. Der Pfad kann erst dann wieder vom
ESX Server-Host verwendet werden, wenn ein erneuter Scan ausgeführt wird,
während der Pfad aktiv ist.
Neu scannen
1
Wählen Sie im VI-Client einen Host aus und klicken Sie auf die Registerkarte
Konfiguration.
2
Wählen Sie im Fenster Hardware den Eintrag Speicheradapter, und klicken
Sie über dem Fensterbereich Speicheradapter auf Neu scannen.
HINWEIS Sie können auch einen einzelnen Adapter markieren und auf Neu scannen
klicken, wenn Sie nur diesen Adapter scannen möchten.
Neu scannen (Schaltfläche)
94
VMware, Inc.
Entfernen von Datastores
Mit dem VI-Client können Sie einen Datastore entfernen, sodass er nicht mehr als
Speicher für virtuelle Maschinen verwendet wird.
HINWEIS Um den Datastore vom ESX Server-Host zu entfernen, müssen Sie ein LUN-Masking
durchführen oder die LUN aus dem SAN-Array entfernen und einen erneuten Scan
vom VI-Client durchführen.
Entfernen eines Datastores
1
Fahren Sie alle virtuellen Maschinen herunter, die den Datastore verwenden, den
Sie entfernen möchten.
2
Wählen Sie im Bestandsfenster den Host aus.
3
Migrieren Sie alle virtuellen Maschinen, die Sie beibehalten möchten,
mit VMotion.
4
Klicken Sie auf die Registerkarte Konfiguration und dann auf Speicher, um alle
Speicher-Devices anzuzeigen.
5
Wählen Sie den Datastore aus, den Sie entfernen möchten, und klicken
Sie auf Entfernen.
6
Klicken Sie auf Neu scannen, um die Anzeige verfügbarer Speicheroptionen
zu aktualisieren.
Erweiterte Konfiguration der LUN-Anzeige
In diesem Abschnitt wird eine Reihe erweiterter Konfigurationsoptionen erläutert.

„Ändern der Anzahl gescannter LUNs mithilfe von Disk.MaxLUN“ auf Seite 95.

„Masking von LUNs mithilfe von Disk.MaskLUNs“ auf Seite 96.

„Ändern der Sparse-LUN-Unterstützung mithilfe von DiskSupportSparseLUN“
auf Seite 97.
Ändern der Anzahl gescannter LUNs mithilfe von Disk.MaxLUN
Standardmäßig scannt der VMkernel für jedes Ziel LUN 0 bis LUN 255 (insgesamt
256 LUNs). Sie können den Parameter Disk.MaxLun anpassen, um diese Zahl zu
ändern. Dadurch kann die Geschwindigkeit der LUN-Erkennung erhöht werden.
HINWEIS Sie können LUNs mit einer ID, die größer als 255 ist, nicht erkennen.
VMware, Inc.
95
Wenn der Wert verringert wird, verkürzen sich die Zeit für das erneute
Scannen und die Boot-Zeit. Die Zeit für das erneute Scannen von LUNs hängt
von mehreren Faktoren ab, unter anderem vom Typ des Speicher-Arrays und
davon, ob die Sparse-LUN-Unterstützung aktiviert ist. Siehe „Ändern der
Sparse-LUN-Unterstützung mithilfe von DiskSupportSparseLUN“ auf Seite 97.
So ändern Sie den Wert von Disk.MaxLUN:
1
Wählen Sie im Bestandsfenster des VI-Clients den Host aus, und klicken Sie auf die
Registerkarte Konfiguration und dann auf Erweiterte Einstellungen.
2
Wählen Sie im Dialogfeld, das daraufhin geöffnet wird, Festplatte aus.
3
Führen Sie einen Bildlauf zu Disk.MaxLUN aus, ändern Sie den vorhandenen
Wert in den gewünschten Wert, und klicken Sie auf OK.
Masking von LUNs mithilfe von Disk.MaskLUNs
Mit dem Parameter Disk.MaskLUNs können Sie bestimmte LUNs auf bestimmten
HBAs maskieren. Der VMkernel kann maskierte LUNs nicht ändern oder darauf
zugreifen, auch nicht während des ersten Scan-Vorgangs.
Verwenden Sie diese Option, wenn Sie verhindern möchten, dass das
ESX Server-System auf einige FC-LUNs zugreift, aber nicht den
LUN-Masking-Mechanismus mit FC-Switch oder FC-Device verwenden möchten.
96
VMware, Inc.
So ändern Sie den Wert von Disk.MaskLUNs:
1
2
3
Führen Sie einen Bildlauf zu Disk.MaskLUNs aus, ändern Sie den vorhandenen
Wert in den gewünschten Wert, und klicken Sie auf OK.
VORSICHT Wenn sich ein Ziel, eine LUN oder eine vmhba-Nummer aufgrund einer
SAN-Neukonfiguration ändert, wird die falsche LUN unter Umständen
maskiert oder aufgedeckt werden.
Ändern der Sparse-LUN-Unterstützung mithilfe von
DiskSupportSparseLUN
Standardmäßig ist der VMkernel so konfiguriert, dass Sparse-LUNs unterstützt
werden, d. h. Fälle, in denen einige LUNs im Bereich 0 bis N-1 nicht vorhanden sind,
LUN N jedoch vorhanden ist.
Wenn alle LUNs aufeinender folgen, können Sie den Parameter
Disk.SupportSparseLUN ändern. Dadurch wird die zum Scannen nach LUNs
erforderliche Zeit verringert.
So ändern Sie den Wert von Disk.SupportSparseLUN:
1
2
3
Führen Sie einen Bildlauf zu Disk.SupportSparseLUN, aus, ändern Sie den Wert
in 0, und klicken Sie auf OK.
Multipathing
In diesem Abschnitt werden folgende Multipathing-Themen behandelt:

„Anzeigen des aktuellen Multipathing-Status“ auf Seite 98.
„Festlegen der Multipathing-Policy einer LUN“ auf Seite 101.
„Deaktivieren und Aktivieren von Pfaden“ auf Seite 102.
„Einrichten des bevorzugten Pfads (Nur feste Pfad-Policy)“ auf Seite 103.
„Pfad-Management und manueller Lastausgleich“ auf Seite 104.
Eine Einführung in Multipathing-Konzepte finden Sie unter „Pfad-Management und
Failover“ auf Seite 46.
VMware, Inc.
97
Anzeigen des aktuellen Multipathing-Status
Mit dem VI-Client können Sie den aktuellen Multipathing-Status anzeigen.
So zeigen Sie den aktuellen Multipathing-Status an:
1
Wählen Sie im Bestandsfenster des VI-Clients einen Host aus, und klicken Sie auf
die Registerkarte Konfiguration.
2
Wählen Sie im Fenster Speicher einen der Datastores aus.
Im Fenster Details werden Informationen über den Datastore angezeigt.
Eigenschaften
98
3
Um weitere Informationen anzuzeigen oder die Multipathing-Policy zu ändern,
wählen Sie Eigenschaften oberhalb des Detailfensters aus.
4
Wählen Sie im Fenster Erweiterungen die Erweiterung aus, für die Sie
Informationen anzeigen oder ändern möchten.
VMware, Inc.
Im Fenster Gerät erweitern werden Informationen über die Erweiterung, den
Pfadauswahlalgorithmus, die verfügbaren Pfade und den aktiven Pfad angezeigt.
Die Anzeige beinhaltet Informationen über den Status jedes Pfads zur
Device-Erweiterung. Die folgenden Pfadinformationen werden angezeigt:
5
VMware, Inc.

Aktiv - Der Pfad ist aktiv. Es handelt sich um den aktuellen Pfad, der zum
Übertragen von Daten verwendet wird.

Deaktiviert - Der Pfad wurde deaktiviert, und es können keine Daten
übertragen werden.

Standby - Der Pfad ist betriebsbereit, wird jedoch derzeit nicht für die
Datenübertragung verwendet.

Tot - Die Software kann über diesen Pfad keine Verbindung zur
Festplatte herstellen.
Wenn Sie die Pfad-Policy Fest verwenden und feststellen möchten, welcher Pfad
der bevorzugte Pfad ist, klicken Sie auf Pfade verwalten.
99
Der bevorzugte Pfad ist mit einem Asterisk-Zeichen (*) in der vierten
Spalte gekennzeichnet.
In Tabelle 6-2 ist zusammengefasst, wie sich das Verhalten eines ESX Server-Systems je
nach Array-Typ und Failover-Policy ändert.
Tabelle 6-2. Auswirkungen der Pfad-Policy
Policy/Controller
Aktiv/Aktiv
Aktiv/Passiv
Zuletzt verwendet
Administrator-Aktion ist
für Failback nach
Pfadausfall erforderlich.
Administrator-Aktion ist
für Failback nach
Pfadausfall erforderlich.
Feststehend
VMkernel setzt die Ausführung
mit dem bevorzugten Pfad fort,
wenn die Verbindung
wiederhergestellt wurde.
VMkernel versucht, die
Ausführung mit dem
bevorzugten Pfad wieder
aufzunehmen. Dies kann zu
Pfad-Thrashing oder einem
Pfadausfall führen, da ein
anderer SP jetzt Eigentümer der
LUN ist. Siehe „Auflösen von
Pfad-Thrashing“ auf Seite 113.
Weitere Informationen finden Sie unter „Aktive Pfade“ auf Seite 101.
100
VMware, Inc.
Aktive Pfade
In der Regel führt ESX Server für eine bestimmte LUN keinen pfadübergreifenden
I/O-Lastausgleich durch. Zu einem bestimmten Zeitpunkt wird nur ein Einzelpfad
verwendet, um I/O an eine bestimmte LUN auszugeben. Der Pfad wird als aktiver
Pfad bezeichnet.

Ist die Pfad-Policy einer LUN auf Fest gesetzt, wählt ESX Server den als Bevorzugt
gekennzeichneten Pfad als aktiven Pfad aus.
Wenn der bevorzugte Pfad deaktiviert wurde oder auf andere Weise nicht
verfügbar ist, verwendet das ESX Server-System einen alternativen aktiven Pfad
als aktiven Pfad.

Ist die Pfad-Policy einer LUN auf Zuletzt verwendet gesetzt, wählt der
ESX Server-Host einen aktiven Pfad zur LUN aus, der Pfad-Thrashing verhindert.
Die Bezeichnung „Bevorzugter Pfad“ wird dabei ignoriert.
In einigen Fällen wird der Begriff aktiv in der SAN-Terminologie zur Bezeichnung
eines Pfades verwendet, der zum Ausgeben von I/O an eine LUN verfügbar ist.
Aus Sicht des ESX Server-Hosts bezeichnet der Begriff den einzigen Pfad, den der
ESX Server-Host verwendet, um I/O an eine LUN auszugeben.
Festlegen der Multipathing-Policy einer LUN
Die folgenden Multipathing-Policys werden derzeit unterstützt:

Fest - Der ESX Server-Host verwendet immer den bevorzugten Pfad zur Festplatte,
wenn dieser Pfad verfügbar ist. Wenn nicht über den bevorzugten Pfad auf die
Festplatte zugegriffen werden kann, werden die anderen Pfade probiert. Fest ist
die Standard-Policy für Aktiv/Aktiv-Speicher-Devices.

Zuletzt verwendet - Der ESX Server-Host verwendet den zuletzt verwendeten
Pfad zur Festplatte, bis dieser Pfad nicht mehr verfügbar ist. Dies bedeutet, dass
der ESX Server-Host nicht automatisch zum bevorzugten Pfad zurückkehrt.
Zuletzt verwendet ist die Standard-Policy für Aktiv/Passiv-Speicher-Devices und
wird für diese Geräte benötigt.
Der ESX Server-Host stellt die Multipathing-Policy automatisch und entsprechend des
erkannten Array-Modells ein. Wenn der erkannte Array nicht unterstützt wird, wird er
als aktiv/aktiv betrachtet. Im Storage/SAN Compatibility Guide finden Sie eine Liste der
unterstützten Arrays.
HINWEIS Es wird davon abgeraten, die Einstellung Zuletzt verwendet manuell in Fest zu
ändern. Das System stellt diese Policy für die Arrays ein, für die diese Einstellung
erforderlich ist.
VMware, Inc.
101
So legen Sie die Multipathing-Policy mit einem VI-Client fest:
1
Wählen Sie im Bestandsfenster des VI-Clients den Host aus, und klicken
Sie anschließend auf die Registerkarte Konfiguration.
2
Wählen Sie im Hardware-Fenster Speicher.
3
Wählen Sie den Datastore aus, für den Sie die Multipathing-Policy ändern
möchten, und klicken Sie im Detailfenster auf Eigenschaften.
4
Wählen Sie im Fenster Erweiterung das Device aus, für das Sie die Änderung
vornehmen möchten, und klicken Sie im Fenster Gerät erweitern auf der rechten
Seite auf Pfade verwalten.
5
Wählen Sie die Multipathing-Policy im Dialogfeld aus, das daraufhin geöffnet
wird, und klicken Sie auf Fertig.
HINWEIS Bei Aktiv/Passiv-Speicher-Devices wird die Einstellung Zuletzt verwendet
dringend empfohlen.
Deaktivieren und Aktivieren von Pfaden
In einigen Fällen müssen Sie Pfade zur Wartung oder aus anderen Gründen
vorübergehend deaktivieren. Dazu können Sie den VI-Client verwenden.
So deaktivieren Sie einen Pfad:
102
1
2
Wählen Sie im Fenster Hardware den Eintrag Speicher aus.
3
Wählen Sie das Device aus, für das Sie einen Pfad deaktivieren möchten, und
klicken Sie im Detailfenster auf Eigenschaften.
4
VMware, Inc.
5
Klicken Sie im Feld Pfade des Dialogfeldes Pfade verwalten auf Ändern, und
aktivieren Sie das Optionsfeld Deaktiviert, um den Pfad zu deaktivieren.
So aktivieren Sie einen Pfad:
Wenn Sie einen Pfad (z. B. zur Wartung) deaktiviert haben, können Sie ihn erneut
aktivieren, indem Sie die Schritte zum Deaktivieren eines Pfades ausführe, aber das
Optionsfeld Aktiviert aktivieren.
Einrichten des bevorzugten Pfads (Nur feste Pfad-Policy)
Wenn Sie die Pfad-Policy Fest verwenden, verwendet der Server immer den
bevorzugten Pfad, sofern dieser verfügbar ist.
So richten Sie den bevorzugten Pfad ein:
1
2
Wählen Sie im Hardware-Fenster Speicher.
3
Wählen Sie das Device aus, für das Sie einen Pfad deaktivieren möchten, und
klicken Sie im Detailfenster auf Eigenschaften.
4
VMware, Inc.
103
5
Wählen Sie den Pfad aus, den Sie als bevorzugten Pfad festlegen möchten, und
klicken Sie auf Ändern.
6
Klicken Sie im Bereich Einstellungen auf Bevorzugt.
Wenn die Option Bevorzugt nicht verfügbar ist, stellen Sie sicher, dass die
Pfad-Policy auf Fest gesetzt ist.
7
Klicken Sie auf OK und anschließend erneut auf OK, um die Dialogfelder
zu schließen.
Pfad-Management und manueller Lastausgleich
Durch einen Ausgleich der Last auf verfügbare Pfade wird die Leistung optimiert.
Sie können Ihr System so einrichten, dass verschiedene Pfade zu verschiedenen LUNs
verwendet werden, indem Sie den bevorzugten Pfad für die verschiedenen HBAs
ändern. Die ist nur für Aktiv/Aktiv-SPs möglich und erfordert, dass Sie die Pfad-Policy
auf Fest gesetzt haben. In „Beispiel für die Verwendung des manuellen Lastausgleichs“
auf Seite 104 finden Sie ein Beispiel.
Wenn ein Pfad ausfällt, übernimmt der verbleibende Pfad den gesamten Verkehr. Der
Pfadausfall kann eine Minute oder länger dauern, da der Fabric unter Umständen mit
einer neuen Topologie konvertiert, um zu versuchen, den Service wiederherzustellen.
Diese Verzögerung ist erforderlich, damit der SAN-Fabric nach Topologieänderungen
oder anderen Fabric-Ereignissen Zeit zum Stabilisieren seiner Konfiguration hat.
Beispiel für die Verwendung des manuellen Lastausgleichs
Wenn Sie einen Aktiv/Aktiv-Array verwenden, können Sie Ihre Umgebung für den
Lastausgleich einrichten. Gehen Sie von folgendem Setup aus, das in Abbildung 6-2
dargestellt ist:
104

Aktiv/Aktiv-SPs.

Ein ESX Server-System.

Vier Fibre-Channel-HBAs in jedem Server.

Director-Class-Software.
VMware, Inc.
ESX Server
HBA1
HBA2
HBA3
HBA4
FC-Switch
SP1
1
SP2
2
3
4
Speicher-Array
Abbildung 6-2. Manueller Lastausgleich
Legen Sie für den Lastausgleich die bevorzugten Pfade wie folgt fest:

LUN 1: vmhba1:1:1

LUN 2: vmhba2:1:2

LUN 3: vmhba3:2:3

LUN 4: vmhba4:2:4
Informationen finden Sie in „Einrichten des bevorzugten Pfads (Nur feste
Pfad-Policy)“ auf Seite 103.
HINWEIS Für den Lastausgleich sind zwei HBAs ausreichend, auch wenn in diesem Beispiel
vier eingesetzt werden.
Failover
Pfad-Failover bezieht sich auf Situationen, in denen der aktive Pfad zu einer
LUN geändert wird. Dies erfolgt normalerweise aufgrund des Ausfalls einer
SAN-Komponente des aktuellen Pfades. Ein Server verfügt in der Regeln über einen
oder zwei HBAs, und jeder HBA sieht einen oder zwei Speicherprozessoren auf einem
bestimmten SAN-Array. Sie können den aktiven, derzeit vom Server verwendeten Pfad
ermitteln, indem Sie die LUN-Eigenschaften prüfen.
VMware, Inc.
105
Aktive Pfade und Standby-Pfade
Abbildung 6-3. Aktive Pfade und Standby-Pfade
Wenn ein FC-Kabel gezogen wird, wird I/O unter Umständen für 30-60 Sekunden
angehalten, bis der FC-Treiber feststellt, dass die Verknüpfung ausgefallen ist und ein
Failover eingetreten ist. Daher kann es dazu kommen, dass die virtuellen Maschinen
(deren virtuelle Festplatten auf SAN-Speicher installiert sind) nicht reagieren. Wenn Sie
versuchen, den Host, dessen Speicher-Devices oder Adapter anzuzeigen, kann es den
Anschein haben, als hätte sich der Vorgang „aufgehängt“. Nach Abschluss des
Failovers wird I/O normal fortgesetzt.
Bei schwerwiegenden Ereignissen mit mehreren Ausfällen können alle Verbindungen
zu SAN-Speicher-Devices verloren gehen. Wenn keine der Verbindungen zum
Speicher-Device funktioniert, können bei einigen virtuellen Maschinen I/O-Fehler auf
den virtuellen SCSI-Festplatten auftreten.
106

„Festlegen des HBA-Timeout für Failover“ auf Seite 107.

„Festlegen von Device-Treiberoptionen für SCSI-Controller“ auf Seite 107.

„Festlegen des Betriebssystem-Timeouts“ auf Seite 108.
VMware, Inc.
Festlegen des HBA-Timeout für Failover
Der Timeout-Wert für wiederholte I/O-Vorgänge wird in der Regel im
HBA-BIOS-Treiber festgelegt. (Sie können auch den Timeout-Wert des Betriebssystems
ändern, wie in „Festlegen des Betriebssystem-Timeouts“ auf Seite 108 erläutert.)
VMware empfiehlt, dass Sie den Timeout-Wert auf 30 Sekunden setzen.

Für QLogic-HBAs beträgt der Timeout-Wert 2*n + 5 Sekunden, wobei n der Wert
des Parameters PortDownRetryCount des BIOS der QLogic-Karte ist. Sie können
die Erkennungszeit für einen Pfadausfall anpassen, indem Sie den Wert des
Modulparameters qlport_down_retry ändern (dessen Standardwert aus der
BIOS-Einstellung übernommen wird). Die empfohlene Einstellung für diesen
Parameter ist 14.

Für Emulex-HBAs können Sie die Erkennungszeit für einen Pfadausfall anpassen,
indem Sie den Wert der Modulparameter lpfc_linkdown_tmo (der Standardwert
ist 30) und lpfc_nodedev_tmo (der Standardwert ist 30) ändern. Die Summe der
Werte dieser beiden Parameter legt die Erkennungszeit für einen Pfadausfall fest.
Die empfohlene Einstellung ist jeweils der Standardwert.
Um diese Parameter zu ändern, müssen Sie eine zusätzliche Option an den Treiber
weitergeben, wie z. B. qlport_down_retry or lpfc_linkdown_tmo. Im folgenden
Abschnitt wird erläutert, wie Sie diese Optionen an den Treiber weitergeben können.
Festlegen von Device-Treiberoptionen für SCSI-Controller
In diesem Abschnitt werden Device-Treiberoptionen für QLogic, Emulex oder andere
SCSI-Kartentreiber festgelegt.
So legen Sie Device-Treiberoptionen für QLogic, Emulex oder andere
SCSI-Kartentreiber fest:
1
Erstellen Sie eine Sicherungskopie der Datei /etc/vmware/esx.conf, und öffnen
Sie die Datei zum Bearbeiten.
Die Datei enthält einen Abschnitt für jedes SCSI-Device, wie im folgenden
Beispiel dargestellt:
/device/002:02.0/class = "0c0400"
/device/002:02.0/devID = "2312"
/device/002:02.0/irq = "19"
/device/002:02.0/name = "QLogic Corp QLA231x/2340 (rev 02)"
/device/002:02.0/options = ""
/device/002:02.0/owner = "vmkernel"
/device/002:02.0/subsysDevID = "027d"
/device/002:02.0/subsysVendor = "1014"
/device/002:02.0/vendor = "1077"
/device/002:02.0/vmkname = "vmhba0"
VMware, Inc.
107
2
Suchen Sie die Zeile options direkt unter der Zeile name, und nehmen Sie die
entsprechenden Änderungen vor.
3
Wiederholen Sie dies bei Bedarf für jeden SCSI-Adapter, der vom selben
Treiber gesteuert wird.
Festlegen des Betriebssystem-Timeouts
Sie können den Standardwert für das Festplatten-Timeout erhöhen, sodass ein
Windows-Gastbetriebssystem während des Failovers nicht übermäßig lange
unterbrochen wird.
Für die Gastbetriebssysteme Windows 2000 und Windows Server 2003 können Sie das
Betriebssystem-Timeout in der Registry festlegen.
So legen Sie das Betriebssystem-Timeout für Windows-Server fest:
1
Führen Sie ein Backup Windows-Registry durch.
2
Wählen Sie Start > Ausführen, geben Sie regedit.exe ein, und klicken
Sie auf OK.
3
Doppelklicken Sie in der hierarchischen Ansicht im linken Fensterbereich auf
HKEY_LOCAL_MACHINE, dann auf System, CurrentControlSet, Services
und anschließend auf Disk.
4
Wählen Sie TimeOutValue aus, und setzen Sie den Wert auf x03c (hexadezimal)
oder 60 (dezimal).
Wenn Sie die Änderung vorgenommen haben, wartet Windows mindestens
60 Sekunden, damit verzögerte Festplattenvorgänge abgeschlossen werden
können, bevor Fehler ausgegeben werden.
5
Klicken Sie auf OK, um den Registry Editor zu schließen.
Konfiguration des VMkernels
Legen Sie beim Installieren des ESX Server-Systems fest, wo verschiedene
Speicherelemente abgelegt werden sollen, wie z. B. die Partitionen / und /boot der
Service-Konsole. Die verschiedenen Komponenten werden im Handbuch für Installation
und Upgrade ausführlicher erläutert.
Weitere Informationen finden Sie unter „Gemeinsame Nutzung von
Diagnosepartitionen“ auf Seite 109.
108
VMware, Inc.
Gemeinsame Nutzung von Diagnosepartitionen
Wenn Ihr ESX Server-Host über eine lokale Festplatte verfügt, wird diese am besten für
die Diagnosepartition verwendet. Ein Grund dafür besteht darin, dass es nach einem
Problem mit Remote-Speicher, das einen Core Dump verursacht, zum Verlust des Core
Dump kommt. Dadurch wird die Behebung des Problems erschwert.
Für Server ohne Festplatte, die über SAN booten, können mehrere ESX Server-Systeme
eine Diagnosepartition auf einer SAN-LUN gemeinsam nutzen. Verwenden mehrere
ESX Server-Systeme eine LUN als Diagnosepartition, muss ein Zoning dieser LUN
ausgeführt werden, sodass alle Server darauf zugreifen können.
Jeder Server benötigt 100 MB Speicherplatz, sodass die Größe der LUN festlegt, wie
viele Server sie gemeinsam nutzen können. Jedes ESX Server-System wird einem
Diagnose-Slot zugeordnet. VMware empfiehlt mindestens 16 Slots (1600 MB)
Festplattenspeicher, wenn Server einer Diagnosepartition gemeinsam nutzen.
Ist auf dem Device nur ein Diagnose-Slot vorhanden, werden alle ESX Server-Systeme,
die dieses Device gemeinsam nutzen, demselben Slot zugeordnet. Dies kann leicht zu
Problemen führen. Wenn zwei ESX Server-Systeme gleichzeitig einen Core
Dump ausführen, werden die Core Dumps auf dem letzten Slot der
Diagnosepartition überschrieben.
Wenn Sie genügend Speicher für 16 Slots zuweisen, ist es unwahrscheinlich, dass Core
Dumps demselben Speicherort auf der Diagnosepartition zugeordnet werden, auch
wenn zwei ESX Server-Systeme gleichzeitig einen Core Dump ausführen.
Vermeiden und Beheben von Problemen
In diesem Abschnitt erhalten Sie einige Tipps zum Vermeiden und Beheben
von Problemen:

Dokumentieren Sie alles. Nehmen Sie Informationen über Zoning,
Zugriffssteuerung, Speicher, Switch-, Server- und FC-HBA-Konfiguration,
Software- und Firmware-Versionen und den Speicherkabelplan auf.

Erstellen Sie einen Plan für Ausfälle:
VMware, Inc.

Erstellen Sie mehrere Kopien Ihrer Topologiekarte. Überlegen Sie für jedes
Element, welche Auswirkungen der Ausfall des Elements auf Ihr SAN hat.

Haken Sie verschiedene Zuordnungen, Switches, HBAs und andere
Elemente ab, zum sicherzustellen, dass Sie keinen kritischen Ausfallpunkt
vergessen haben.
109

Trennen Sie die Verbindung der Fibre-Channel-HBAs während der
lokalen Installation, wenn Sie einen ESX Server-Host auf einem
Produktionssystem installieren.
VORSICHT Mit dem Installationsprogramm können Sie alle zugänglichen
Festplatten löschen, darunter auch SAN-LUNs, die von anderen
Servern verwendet werden.

Stellen Sie sicher, dass die Fibre-Channel-HBAs auf der Grundlage von Slot- und
Bus-Geschwindigkeit in den richtigen Slots im ESX Server-Host installiert sind.
Verteilen Sie die PCI-Bus-Last auf die im Server verfügbaren Busse.

Machen Sie sich mit den verschiedenen Überwachungspunkten in Ihrem
Speichernetzwerk an allen Sichtbarkeitspunkten vertraut, wie z. B.
ESX Server-Leistungsdiagrammen, FC-Switch-Statistiken
und Speicherleistungsstatistiken.
Optimieren der SAN-Speicherleistung
Die zwei Hauptfaktoren für eine Optimierung einer typischen SAN-Umgebung
sind die Speicher-Array-Leistung und die Server-Leistung. Wenn die Umgebung
ordnungsgemäß konfiguriert ist, leisten die SAN-Fabric-Komponenten (insbesondere
die SAN-Switches) aufgrund ihrer geringen Latenz im Vergleich zu Servern und
Speicher-Arrays lediglich einen geringen Beitrag. Stellen Sie sicher, dass die Pfade durch
den Switch-Fabric nicht gesättigt sind, d. h. dass der Switch-Fabric mit dem maximalen
Durchsatz (z. B. 2 GB/Sekunde) läuft.

„Speicher-Array-Leistung“ auf Seite 110.

„Server-Leistung“ auf Seite 111.
Speicher-Array-Leistung
Wenn Probleme mit der Speicher-Array-Leistung auftreten, finden Sie relevante
Informationen in der Dokumentation Ihres Speicher-Array-Anbieters.
Denken Sie beim Zuweisen von LUNs dran, dass eine Reihe von ESX Server-Hosts auf
jede LUN zugreifen und dass auf jedem Host eine Reihe virtueller Maschinen
ausgeführt werden kann. Eine von einem ESX Server-Host verwendete LUN kann I/O
aus zahlreichen verschiedenen Anwendungen bedienen, auf verschiedenen
Betriebssystemen ausgeführt werden. Aufgrund dieser vielfältigen Workload sollte die
RAID-Gruppe, die die ESX Server-LUNs enthält, keine LUNs enthalten, die von
anderen Hosts verwendet werden, die ESX Server für I/O-intensive Anwendungen
nicht ausführen.
110
VMware, Inc.
Stellen Sie sicher, dass Read/Write-Caching aktiviert ist.
Beim Lastausgleich werden Server-I/O-Anforderungen auf alle verfügbaren SPs und
deren Host-Server-Pfade verteilt. Das Ziel besteht in der Leistungsoptimierung im
Hinblick auf den Durchsatz (I/O pro Sekunde, Megabyte pro Sekunde oder Antwortzeit).
SAN-Speicher-Arrays erfordern eine ständige Neuentwicklung und Feinabstimmung,
um sicherzustellen, dass der I/O-Lastausgleich auf alle Speicher-Array-Pfade erfolgt.
Um diese Anforderung zu erfüllen, verteilen Sie die Pfade auf die LUNs aller SPs, um
einen optimalen Lastausgleich zu erzielen. Eine lückenlose Überwachung zeigt an,
wann ein manueller Neuausgleich der LUN-Verteilung erforderlich ist. In
„Pfad-Management und manueller Lastausgleich“ auf Seite 104 finden Sie ein Beispiel.
Die Feinabstimmung statisch ausgeglichener Speicher-Arrays beinhaltet die
Überwachung der jeweiligen Leistungsstatistik (z. B. I/O-Vorgänge pro Sekunde, Blöcke
pro Sekunde und Antwortzeit) und die Verteilung der LUN-Workload auf alle SPs.
HINWEIS Der dynamische Lastausgleich wird in ESX Server derzeit nicht unterstützt.
Server-Leistung
Um eine optimale Server-Leistung sicherzustellen, muss eine Reihe von Faktoren
berücksichtigt werden. Jede Server-Anwendung muss Zugang zum benannten
Speicher mit folgenden Kriterien haben:

Hohe I/O-Rate (Anzahl der I/O-Vorgänge pro Sekunde).

Hoher Durchsatz (Megabyte pro Sekunde).

Minimale Latenz (Antwortzeiten).
Da jede Anwendung unterschiedliche Anforderungen hat, können Sie diese Ziele
erreichen, indem Sie auf dem Speicher-Array eine entsprechende RAID-Gruppe
auswählen. So erreichen Sie Leistungsziele:

Platzieren Sie jede LUN in einer RAID-Gruppe, die das erforderliche
Leistungsniveau bietet. Achten Sie besonders auf die Aktivitäten und
Ressourcennutzung anderer LUNs in der zugewiesenen RAID-Gruppe.
Eine leistungsfähige RAID-Gruppe, der zu viele I/O-intensive Anwendungen
zugewiesen sind, erfüllt die Leistungsziele einer Anwendung, die auf dem
ESX Server-Host ausgeführt wird, unter Umständen nicht.

Stellen Sie sicher, dass jeder Server über eine ausreichende Anzahl von HBAs verfügt,
um den maximalen Durchsatz aller auf dem Server gehosteten Anwendungen
während der Spitzenzeiten zu ermöglichen. Eine I/O-Verteilung auf mehrere HBAs
bietet einen höheren Durchsatz und weniger Latenz für jede Anwendung.

Um Redundanz im Fall eines HBA-Ausfalls sicherzustellen, achten Sie darauf,
dass der Server mit einem doppelt redundanten Fabric verbunden ist.
VMware, Inc.
111

Beachten Sie beim Zuweisen von LUNs oder RAID-Gruppen für
ESX Server-Systeme, dass mehrere Betriebssysteme diese Ressource verwenden
und gemeinsam nutzen. Daher kann die von jeder LUN im Speicher-Subsystem
geforderte Leistung erheblich höher sein, wenn Sie mit ESX Server-Systemen
arbeiten als wenn Sie physische Geräte einsetzen. Beispiel: wenn Sie vier
I/O-intensive Anwendungen ausführen möchten, weisen Sie die vierfache
Leistungskapazität für die ESX Server-LUNs zu.

Wenn Sie mehrere ESX Server-Systeme in Verbindung mit einem
VirtualCenter-Server verwenden, erhöht sich die vom Speicher-Subsystem
benötigte Leistung entsprechend.

Die Anzahl ausstehender I/Os, die von Anwendungen benötigt werden, die auf
einem ESX Server-System ausgeführt werden, sollte mit der Anzahl der I/Os
übereinstimmen, die der HBA und Speicher-Array verarbeiten können.
Lösen von Leistungsproblemen
In diesem Abschnitt werden die Leistungsüberwachung und Möglichkeiten zum
Beheben von Leistungsproblemen erläutert:

„Überwachen der Leistung“ auf Seite 112.

„Auflösen von Pfad-Thrashing“ auf Seite 113.

„Ausgleichen des Festplattenzugriffs zwischen virtuellen Maschinen“ auf
Seite 115.

„Entfernen von VMFS-2-Treibern“ auf Seite 115.

„Verringern von SCSI-Reservierungen“ auf Seite 116.

„Festlegen der maximalen Warteschlangentiefe für HBAs“ auf Seite 116.
HINWEIS Um die optimale Leistung zu erzielen, platzieren Sie jede virtuelle Maschine auf der
entsprechenden Speicherebene. Informationen finden Sie unter „Auswahl der
Speicherorte virtueller Maschinen“ auf Seite 48.
Überwachen der Leistung
Der VI-Client bietet umfassende Funktionen zum Sammeln von Leistungsdaten. Diese
Informationen werden anschießend grafisch im VI-Client dargestellt. Informationen
finden Sie im Virtual Infrastructure UserÕs Guide. Der VI-Client aktualisiert seine
Anzeige in regelmäßigen Abständen.
Sie können auch das Tool esxtop verwenden, das über die Service-Konsole verfügbar
ist. Informationen über esxtop finden Sie im Handbuch zum Ressourcen-Management
oder auf der Manpage (über die Service-Konsole). Sie können esxtop verwenden, um
die Leistung in Echtzeit zu überwachen.
112
VMware, Inc.
Auflösen von Pfad-Thrashing
Wenn Ihr Server nicht auf eine LUN zugreifen kann oder der Zugriff sehr langsam ist,
könnte ein Problem mit Pfad-Thrashing (wird auch als LUN-Thrashing bezeichnet)
vorliegen. Pfad-Thrashing kann auftreten, wenn zwei Hosts über verschiedene SPs auf
die LUN zugreifen und die LUN daher niemals tatsächlich verfügbar ist.
In der Regel können nur bestimmte SAN-Konfigurationen in Verbindung mit den
folgenden Bedingungen zu Pfad-Thrashing führen:

Sie arbeiten mit einem Aktiv/Passiv-Array.

Die Pfad-Policy ist auf Fest gesetzt.

Zwei Hosts greifen mit der entgegengesetzten Pfadreihenfolge auf die LUN zu.
Beispiel: Host A ist so eingerichtet, dass er über SP A auf die LUN mit der
niedrigsten Nummer zugreift. Host B ist so konfiguriert, dass er über SP B auf die
LUN mit der niedrigsten Nummer zugreift.
Pfad-Thrashing kann auch auftreten, wenn Host A einen bestimmten Pfad verloren hat
und nur Pfade zu SP A verwenden kann, während Host B andere Pfade verloren hat
und nur Pfade zu SP B verwenden kann.
Dieses Problem kann auch auf einem Array mit direkter Verbindung (wie z. B. AX100)
und einem HBA-Failover auf einen oder mehreren Nodes auftreten.
Pfad-Thrashing tritt mit anderen Betriebssystemen in der Regel nicht auf:

Kein anderes gängiges Betriebssystem verwendet gemeinsam genutzte LUNs für
mehr als zwei Server (dieses Setup ist normalerweise für Clustering vorbehalten).

Beim Clustering gibt nur jeweils ein Server I/Os aus. Pfad-Thrashing wird nicht zu
einem Problem.
Mehrere ESX Server-Systeme jedoch geben unter Umständen gleichzeitig I/O auf
derselben LUN aus.
So beheben Sie Pfad-Thrashing:

Stellen Sie sicher, dass alle Hosts, die dieselbe Gruppe von LUNs auf diesen
Aktiv/Passiv-Arrays gemeinsam nutzen, gleichzeitig auf denselben
Speicherprozessor zugreifen.

Korrigieren Sie alle Verkabelungsfehler zwischen verschiedenen ESX Server-Hosts
und SAN-Zielen, sodass alle HBAs dieselben Ziele in derselben Reihenfolge sehen.

Stellen Sie sicher, dass die Pfad-Policy auf Zuletzt verwendet (Standardwert)
gesetzt ist.
Weitere Informationen finden Sie unter „Erläuterungen zum Pfad-Thrashing“ auf
Seite 114.
VMware, Inc.
113
Erläuterungen zum Pfad-Thrashing
In allen Arrays verhalten sich die SPs wie unabhängige Computer, die Zugriff auf
gemeinsam genutzten Speicher haben. Algorithmen legen fest, wie der gleichzeitige
Zugriff verarbeitet wird.

Bei Aktiv/Passiv-Arrays kann nur jeweils eine LUN auf alle Sektoren des Speichers
zugreifen, aus denen eine bestimmte LUN besteht. Das Eigentum wird zwischen
den Speicherprozessoren weitergegeben. Dies hängt damit zusammen, dass
Speicher-Arrays Caches verwenden und SP A keine Daten auf die Festplatte
schreiben darf, durch die der Cache von SP B ungültig wird. Da der SP den Cache
nach Abschluss des Vorgangs leeren muss, nimmt es etwas Zeit in Anspruch, das
Eigentum zu wechseln. Während dieses Zeitraums können von keinem SP I/Os an
die LUN verarbeitet werden.

Bei Aktiv/Aktiv-Arrays ermöglichen die Algorithmen einen feiner abgestuften
Zugriff auf den Speicher und synchronisieren Caches. Der Zugriff kann ohne
zusätzliche Zeit gleichzeitig über einen beliebigen SP erfolgen.
Arrays mit AVT sind Aktiv/Passiv-Arrays, die versuchen, wie Aktiv/Aktiv-Arrays
zu wirken, indem sie das Eigentum an der LUN beim Eingang von I/O an
die verschiedenen SPs weitergeben. Dieser Ansatz eignet sich ideal für ein
Clustering-Setup. Wenn jedoch zahlreiche ESX Server-Systems gleichzeitig über
verschiedene SPs auf dieselbe LUN zugreifen, kommt es zu LUN-Thrashing.
Betrachten Sie die Funktionsweise der Pfadauswahl:

Auf einem Aktiv/Aktiv-Array beginnt das System mit dem Senden von I/O
entlang des neuen Pfads.

Für Aktiv/Passiv-Arrays prüft das ESX Server-System alle Standby-Pfade. Der SP
am Ende des gegenwärtig betrachteten Pfades sendet Informationen darüber, ob
es derzeit Eigentümer der LUN ist, an das System.

Wenn das ESX Server-System einen SP findet, der Eigentümer der LUN ist,
wird dieser Pfad ausgewählt, und I/O wird entlang dieses Pfades gesendet.

Wenn der ESX Server-Host keinen solchen Pfad findet, wählt er einen der
Pfade aus und sendet einen Befehl zum Übertragen des LUN-Eigentums an
diesen SP an den SP (am anderen Ende des Pfades).
Pfad-Thrashing kann infolge dieser Pfadauswahl auftreten: Wenn Server A eine
LUN nur über einen SP erreichen kann und Server B dieselbe LUN nur über einen
anderen SP erreichen kann, verursachen beide Server den ständigen Wechsel des
Eigentums an der LUN zwischen den beiden SPs. Da das System das Eigentum
schnell überträgt, kann der Speicher-Array keine I/O verarbeiten (oder nur einen
ganz geringen Teil). Folglich kommt es bei allen Servern, die von der LUN
abhängen, zu einem I/O-Timeout.
114
VMware, Inc.
Ausgleichen des Festplattenzugriffs zwischen
virtuellen Maschinen
Sie können die maximale Anzahl ausstehender Festplattenanforderungen mit dem
Parameter Disk.SchedNumReqOutstanding im VI-Client anpassen. Wenn zwei oder
mehr virtuelle Maschinen auf dieselbe LUN zugreifen, steuert dieser Parameter die
Anzahl ausstehender Anforderungen, die jede virtuelle Maschine an die LUN
ausgeben kann. Durch ein Anpassen des Grenzwerts kann der Festplattenzugriff
zwischen virtuellen Maschinen ausgeglichen werden.
Dieser Grenzwert gilt nicht, wenn auf einer LUN nur eine virtuelle Maschine aktiv ist.
In diesem Fall wird die Bandbreite durch die Warteschlangentiefe des
Speicheradapters beschränkt.
So legen Sie die Anzahl ausstehender Festplattenanforderungen fest:
1
Wählen Sie im VI-Client den Host aus dem Bestandsfenster aus.
2
Klicken Sie auf die Registerkarte Konfiguration und anschließend auf
Erweiterte Einstellungen.
3
Klicken Sie im linken Fenster auf Festplatte, und führen Sie einen Bildlauf zu
Disk.SchedNumReqOutstanding aus.
4
Ändern Sie den Parameterwert in die gewünschte Anzahl, und klicken Sie auf OK.
5
Starten Sie den Server neu.
Diese Änderung kann sich auf die Planung der Festplattenbandbreite auswirken.
Versuche haben jedoch nachgewiesen, dass es bei festplattenintensiven Workloads zu
Verbesserungen kommt.
Wenn Sie diesen Wert im VMkernel anpassen, können Sie die Warteschlangentiefe im
Speicheradapter ebenfalls anpassen.
Siehe „Festlegen der maximalen Warteschlangentiefe für HBAs“ auf Seite 116.
Entfernen von VMFS-2-Treibern
Wenn Sie über zahlreiche LUNs/VMFS-Volumes verfügen, die alle den Typ VMFS-3
aufweisen, können Sie die Leistung möglicherweise optimieren, indem Sie den
VMFS-2-Treiber entfernen. Geben Sie Folgendes an einer
Befehlszeileneingabeaufforderung ein:
vmkload_mod -u vmfs2
Dies sollte zu einer erheblichen Erhöhung der Geschwindigkeit bestimmter
Management-Vorgänge führen, wie z. B. dem Aktualisieren von Datastores und dem
erneuten Scannen von Speicheradaptern.
VMware, Inc.
115
Verringern von SCSI-Reservierungen
Vorgänge, die eine Datei- oder Metadatensperre in VMFS erfordern, führen zu kurzen
SCSI-Reservierungen. SCSI-Reservierungen sperren eine gesamte LUN. Übermäßige
SCSI-Reservierungen durch einen Server können zu einer Leistungsbeeinträchtigung
auf anderen Servern führen, die auf dasselbe VMFS zugreifen.
Beispiele für Vorgänge, die das Abrufen von Datei- oder Metadatensperren
erfordern, umfassen:

Einschalten einer virtuellen Maschine.

VMotion.

Virtuelle Maschinen, die mit virtuellen Festplatten-Snapshots ausgeführt werden.

Dateivorgänge von der Service-Konsole, das das Öffnen von Dateien oder das
Ausführen von Metadaten-Updates erfordern.
(Siehe „Metadaten-Aktualisierungen“ auf Seite 36.)
Es kann zu einer Leistungsbeeinträchtigung kommen, wenn solche Vorgänge häufig
auf mehreren Servern ausgeführt werden, die auf dasselbe VMFS zugreifen. Es wird
z. B. nicht empfohlen, zahlreiche virtuelle Maschinen von mehreren Servern, die
virtuelle Festplatten-Snapshots verwenden, auf demselben VMFS auszuführen.
Beschränken Sie die Anzahl der VMFS-Dateivorgänge, die von der Service-Konsole
ausgeführt werden, wenn zahlreiche virtuelle Maschinen auf dem VMFS ausgeführt
werden.
Festlegen der maximalen Warteschlangentiefe für HBAs
Wenn Sie eine unbefriedigende Leistung Ihrer HBAs feststellen, können Sie ihre
maximale Warteschlangentiefe ändern. Weitere Informationen finden Sie in
folgenden Abschnitten:

„Anpassen der Warteschlangentiefe für einen QLogic-HBA“ auf Seite 116.

„Anpassen der Warteschlangentiefe für einen Emulex-HBA“ auf Seite 117.
Anpassen der Warteschlangentiefe für einen QLogic-HBA
Sie können die maximale Warteschlangentiefe für einen QLogic-Adapter der Serie
qla2x00 mit dem folgenden Verfahren ändern.
So legen Sie die maximale Warteschlangentiefe für einen QLogic-HBA fest:
116
1
Melden Sie sich als Root-Benutzer an der ESX Server-Servicekonsole an.
2
Erstellen Sie eine Sicherungskopie der Datei /etc/vmware/esx.conf, und öffnen
Sie die Datei zum Bearbeiten.
VMware, Inc.
Die Datei sieht ähnlich aus wie das folgende Beispiel:
/device/002:02.0/class = "0c0400"
/device/002:02.0/devID = "2312"
/device/002:02.0/irq = "19"
/device/002:02.0/name = "QLogic Corp QLA231x/2340 (rev 02)"
/device/002:02.0/options = ""
/device/002:02.0/owner = "vmkernel"
/device/002:02.0/subsysDevID = "027d"
/device/002:02.0/subsysVendor = "1014"
/device/002:02.0/vendor = "1077"
/device/002:02.0/vmkname = "vmhba0"
3
Suchen Sie die Zeile options direkt unter der Zeile name, und ändern Sie diese
Zeile wie folgt, um die maximale Warteschlangentiefe anzugeben (wobei nn die
maximale Warteschlangentiefe ist):
/device/001:02.0/options = "ql2xmaxqdepth=nn"
HINWEIS Das zweite Zeichen in ql2xmaxqdepth ist ein kleines „L“.
4
Speichern Sie die Änderungen, und starten Sie den Server neu.
Anpassen der Warteschlangentiefe für einen Emulex-HBA
Sie können die maximale Warteschlangentiefe für einen Emulex-Adapter mit dem
folgenden Verfahren ändern.
So ändern Sie die Warteschlangentiefe eines Emulex-HBA:
1
Melden Sie sich als Root-Benutzer an der Service-Konsole an.
2
Prüfen Sie, welches Emulex-HBA-Modul gegenwärtig geladen ist:
vmkload_mod -l | grep lpfcdd
Je nach HBA-Modell kann eines der folgenden Module geladen sein:
lpfcdd_7xx
lpfcdd_732
3
Führen Sie für eine Instanz eines Emulex-HBA auf dem System die folgenden
Befehle aus. Im Beispiel ist das Modul lpfcdd_7xx dargestellt. Verwenden Sie je
nach Ergebnis von Schritt 2 das entsprechende Modul.
a
esxcfg-module -s lpfc0_lun_queue_depth=16 lpfcdd_7xx
b
esxcfg-boot -b
In diesem Fall wird die LUN-Warteschlangentiefe des durch lpfc0 HBA auf
16 gesetzt.
VMware, Inc.
117
4
Führen Sie für mehrere Instanzen eines Emulex-HBA auf dem System die
folgenden Befehle aus.
a
esxcfg-module -s "lpfc0_lun_queue_depth=16
lpfc1_lun_queue_depth=16" lpfcdd_7xx
b
esxcfg-boot -b
In diesem Fall wird die LUN-Warteschlangentiefe der beiden HBAs lpfc0 und
lpfc1 auf 16 gesetzt.
5
Führen Sie einen Neustart durch.
Überlegungen zum SAN-Speicher-Backup
In diesem Abschnitt werden Backups in der SAN-Umgebung erläutert:

„Backups in einer SAN-Umgebung“ auf Seite 118.

„Snapshot-Software“ auf Seite 119.

„Verwenden eines Drittanbieter-Backup-Pakets“ auf Seite 120.

„Auswählen Ihrer Backup-Lösung“ auf Seite 120.
Backups in einer SAN-Umgebung
Innerhalb der SAN-Umgebung haben Backups zwei Ziele. Das erste Ziel besteht darin,
Online-Daten auf Offline-Medien zu archivieren. Dieser Prozess wird gemäß einem
Zeitplan in regelmäßigen Abständen für alle Online-Daten wiederholt. Das zweite Ziel
besteht darin, Zugriff auf Offline-Daten zur Recovery nach einem Problem
bereitzustellen. Bei einer Datenbank-Recovery müssen beispielsweise archivierte
Log-Dateien abgerufen werden, die zurzeit nicht online sind.
Die Planung eines Backups hängt von einer Reihe von Faktoren ab:
118

Identifizierung kritischer Anwendungen, die innerhalb eines bestimmten
Zeitraums häufigere Backup-Zyklen erfordern.

Ziele im Hinblick auf Recovery-Punkt und Recovery-Zeit. Überlegen Sie, wie
präzise Ihr Recovery-Punkt sein muss und wie lange Sie darauf warten möchten.

Die mit den Daten verknüpfte Änderungsrate (Rate of Change – RoC). Wenn Sie
z. B. die synchrone/asynchrone Replikation verwenden, wirkt sich die RoC auf die
Bandbreite aus, die zwischen den primären und sekundären Speicher-Devices
erforderlich ist.

Allgemeine Auswirkung auf die SAN-Umgebung, Speicherleistung (während des
Backup) und andere Anwendungen.
VMware, Inc.

Identifizierung von Spitzenverkehrszeiten des SAN (Backups, die während
dieser Zeiten geplant werden, können die Anwendungen und den
Backup-Prozess verlangsamen).

Zeit zum Planen aller Backups im Rechenzentrum.

Erforderliche Zeit zum Sichern einer einzelnen Anwendung.

Ressourcenverfügbarkeit zum Archivieren von Daten; in der Regel
Offline-Medienzugriff (Band).
Nehmen Sie beim Entwerfen Ihrer Backup-Strategie eine Zielsetzung im Hinblick auf
die Recovery-Zeit für jede Anwendung auf. Das heißt, berücksichtigen Sie die Zeit und
Ressourcen, die zum erneuten Bereitstellen der Daten erforderlich sind. Beispiel: wenn
ein geplantes Backup so viele Daten speichert, dass eine Recovery ziemlich viel Zeit in
Anspruch nimmt, sollte das geplante Backup überprüft werden. Es könnte besser sein,
das Backup häufiger auszuführen. In diesem Fall werden weniger Daten gesichert und
die Recovery-Zeit verringert.
Wenn eine bestimmte Anwendung eine Recovery innerhalb eines bestimmten
Zeitraums erfordert, muss der Backup-Prozess einen Zeitplan und spezifische
Datenverarbeitung vorgeben, um diese Anforderung zu erfüllen. Eine schnelle
Recovery kann den Einsatz von Recovery-Volumes erfordern, die auf Online-Speicher
residieren, um den Zugriff auf langsame Offline-Medien für fehlende
Datenkomponenten zu minimieren oder ganz auszuschließen.
Snapshot-Software
Mit Snapshot-Software kann ein Administrator eine sofortige Kopie einer im
Festplatten-Subsystem definierten virtuellen Festplatte erstellen. Snapshot-Software ist
auf verschiedenen Ebenen verfügbar:

Mit ESX Server-Hosts können Sie Snapshots virtueller Maschinen erstellen.
Diese Software ist im ESX Server-Basispaket enthalten.

Backup-Software von Drittanbietern ermöglicht unter Umständen umfassendere
Backup-Verfahren und kann ausgereiftere Konfigurationsoptionen enthalten.
Administratoren erstellen Snapshots aus verschiedenen Gründen, wie z. B.:

Backup.

Disaster Recovery.

Verfügbarkeit mehrerer Konfigurationen und/oder Versionen

Forensik (Prüfen eines Snapshot, um die Ursache von Problemen während des
Systembetriebs herauszufinden).

Data Mining (Prüfen einer Kopie Ihrer Daten, um die Last für Produktionssysteme
zu verringern).
VMware, Inc.
119
Verwenden eines Drittanbieter-Backup-Pakets
Wenn Sie Drittanbieter-Backup-Software verwenden, stellen Sie sicher, dass die
Software mit ESX Server-Hosts unterstützt wird. Weitere Informationen finden Sie im
Backup Software Compatibility Guide.
Der Einsatz von Drittanbieter-Software bietet den Vorteil einer einheitlichen
Umgebung. Sie müssen jedoch berücksichtigen, dass die zusätzlichen Kosten der
Drittanbieter-Snapshotting-Software steigen können, wenn Ihr SAN wächst.
Wenn Sie Snapshots zum Sichern Ihrer Daten verwenden, beachten Sie die
folgenden Punkte:

Einige Anbieter unterstützen Snapshots für VMFS und RDMs. Wird beides
unterstützt, können Sie einen Snapshot des gesamten VMFS für einen Host oder
für die einzelnen virtuellen Maschinen (einer pro Festplatte) erstellen.

Einige Anbieter unterstützen Snapshots nur für ein Setup mit RDM.
Wenn nur RDM unterstützt wird, können Sie Snapshots einzelner virtueller
Maschinen erstellen.
Weitere Informationen finden Sie in der Dokumentation Ihres Speicheranbieters.
HINWEIS ESX Server-Systeme enthalten auch die Komponente Consolidated Backup, die im
Handbuch für das Backup virtueller Maschinen ausführlich erläutert wird.
Auswählen Ihrer Backup-Lösung
Beachten Sie beim Auswählen Ihrer Backup-Lösung, dass ein Backup eine oder alle der
folgenden Eigenschaften aufweisen kann:

Absturzkonsistent

Dateisystemkonsistent

Anwendungskonsistent
VMware bietet ein dateisystemkonsistentes Backup. In den meisten Fällen können
Sie mit einem dateisystemkonsistenten Backup nach einem Ausfall eine vollständige
Recovery ausführen. Wenn Ihre Anwendungen jedoch eine dateisystemübergreifende
Synchronisierung oder die Synchronisierung mit einer Datenbank erfordern, bietet die
VMware-Lösung unter Umständen keine ausreichende Konsistenz. In diesen Fällen
sollten Sie prüfen, ob eine Drittanbieter-Backup-Lösung Ihre Anforderungen besser
erfüllen kann.
120
VMware, Inc.
Anwendungen mit mehreren Ebenen
SAN-Administratoren setzen in der Regel spezielle Array-basierte Software für
Backup, Disaster Recovery, Data Mining, Forensik und Konfigurationstests ein.
Um mit Tools zu arbeiten, die im ESX Server-Host für dieselben Vorgänge
enthalten sind, können ESX Server-Administratoren eingesetzt werden. Wenn Sie
ein ESX Server-System in Verbindung mit einem SAN verwenden, müssen
Sie entscheiden, ob sich Array-basierte oder Host-basierte Tools besser für Ihre
jeweilige Situation eignen.

„Array-basierte (Drittanbieter-)Lösung“ auf Seite 121.

„Dateibasierte (Drittanbieter-)Lösung“ auf Seite 121.
Array-basierte (Drittanbieter-)Lösung
Berücksichtigen Sie beim Prüfen einer Array-basierten Lösung die folgenden Punkte:

Wenn Sie die Array-basierte Lösung verwenden, ist RDM (nicht VMFS) in der
Regel die entsprechende Wahl. Wenn Sie RDM nicht verwenden möchten, müssen
Sie in der Dokumentation des Anbieters prüfen, ob Vorgänge auf virtuellen
Festplatten unterstützt werden.

Array-basierte Lösungen führen normalerweise zu umfassenderen Statistiken.
Mit RDM werden Daten immer entlang desselben Pfades übertragen, was das
Leistungs-Management vereinfacht.

Sicherheit lässt sich einfacher verwalten, wenn Sie RDM und eine Array-basierte
Lösung einsetzen, da virtuelle Maschinen mit RDM physischen Rechnern
ähnlicher sind.
Dateibasierte (Drittanbieter-)Lösung
Beachten Sie beim Prüfen einer dateibasierten Lösung mit VMware-Tools und VMFS
die folgenden Punkte:

Der Einsatz von VMware-Tools und VMFS ist besser für die Bereitstellung
geeignet: eine große LUN wird zugewiesen, und mehrere vmdk-Dateien können
auf dieser LUN platziert werden. Mit RDM ist für jede virtuelle Maschine eine
neue LUN erforderlich.

Snapshotting und Replikation sind ohne zusätzliche Kosten in Ihrem
ESX Server-Host enthalten. Daher ist die dateibasierte Lösung kostengünstiger als
die Array-basierte Lösung.
VMware, Inc.
121

Für ESX Server-Administratoren ist die Verwendung von
ESX Server-Tools einfacher.

ESX Server-Administratoren, die die dateibasierte Lösung einsetzen, sind
unabhängiger vom SAN-Administrator.
VMFS-Volume-Resignatur
Mit der VMFS-Volume-Resignature können Sie einen Hardware-Snapshot eines
VMFS-Volumes erstellen und von einem ESX Server-System auf diesen Snapshot
zugreifen. Dies beinhaltet die Resignatur der Volume-UUID und die Erstellung einer
neuen Volume-Bezeichnung. Sie können die Resignatur wie folgt steuern:

Aktivieren oder deaktivieren Sie die automatische Resignatur mit der Option
LVM.EnableResignature (standardmäßig ist die Option deaktiviert).

Als grundsätzliche Regel gilt, dass eine LUN auf allen Hosts, die auf die LUN
zugreifen, mit derselben LUN-ID angezeigt werden sollte. Unter bestimmten
Umständen müssen Sie dieses Verhalten mit der Option
LVM.DisallowSnapshotLUN ändern.

„Mounten von Original- und Snapshot-VMFS-Volumes“ auf Seite 122.

„Probleme mit der Anzeige derselben LUN-ID auf mehreren Hosts“ auf Seite 123.

„Erläuterungen zu Resignatur-Optionen“ auf Seite 124.
Mounten von Original- und Snapshot-VMFS-Volumes
Sie können das Original- und das Snapshot-VMFS-Volume auf demselben
ESX Server-Host mounten.
So mounten Sie Original- und Snapshot-VMFS-Volumes:
122
1
2
3
Führen Sie die folgenden Aufgaben nach Bedarf wiederholt aus:
a
Erstellen Sie den Snapshot.
b
Fügen Sie den Snapshot zum Speicher-Array hinzu.
c
Wählen Sie im linken Fenster LVM aus, und setzen Sie anschließend die
Option LVM.EnableResignature auf 1.
VMware, Inc.
4
Scannen Sie das Volume erneut.
Nach dem erneuten Scan wird die LUN als
/vmfs/volumes/snap-<DIGIT>-<old-label> angezeigt.
HINWEIS Alle virtuellen Maschinen auf diesem neuen Snapshot-Volume werden nicht
automatisch erkannt. Sie müssen die virtuellen Maschinen manuell registrieren.
Wenn die Datei vmx für eine der virtuellen Maschinen oder die Datei .vmsd für
virtuelle Maschinen-Snapshots /vmfs/volumes/<label oder UUID>/Pfade
enthält, müssen Sie diese Elemente ändern, um die Resignatur des
Volume-Pfades darzustellen.
5
Setzen Sie gegebenenfalls die Option LVM.EnableResignature nach Abschluss
der Resignatur auf 0.
Probleme mit der Anzeige derselben LUN-ID auf
mehreren Hosts
In der Regel wird eine LUN auf allen Hosts, die auf die LUN zugreifen, mit derselben
LUN-ID angezeigt. Auf einigen Arrays ist es jedoch unter Umständen nicht möglich,
die LUN mit derselben LUN-ID auf mehreren Hosts anzuzeigen. Dies führt dazu,
dass das ESX Server-System die LUN fälschlicherweise als Snapshot erkennt und
offline setzt.
Beispiele für Speicher-Arrays, bei denen dieselbe LUN-ID unter Umständen für eine
bestimmte LUN nicht auf mehreren Hosts sichtbar ist, sind CLARiiON AX100 und
einige IBM TotalStorage Enterprise Storage Systems (früher Shark Storage-Systeme).
HINWEIS Wenn Sie Clariion AX100 mit Navisphere Express verwenden, können Sie dieselbe
LUN-ID nicht für mehrere Speichergruppen konfigurieren. Stattdessen müssen Sie
eine Version der Navisphere-Software verwenden, die über umfassendere
Management-Funktionen verfügt. Für IBM TotalStorage 8000 müssen Sie diese LUNs
neu erstellen.
So beheben Sie Probleme mit unsichtbaren LUNs auf bestimmten Arrays:
1
2
VMware, Inc.
123
3
Wählen Sie im linken Fenster LVM aus, und setzen Sie anschließend die Option
LVM.DisallowSnapshotLUN im rechten Fenster auf 0.
4
Scannen Sie alle VMFS-Volumes neu.
Nach dem erneuten Scan sind alle VMFS-Volumes verfügbar.
VORSICHT Wenn LVM.DisallowSnapshotLUN auf 0 gesetzt ist, können Snapshots
nicht an den ESX Server-Host weitergegeben werden. Weitere
Informationen finden Sie unter „Status 3 - EnableResignature=no,
DisallowSnapshotLUN=no“ auf Seite 125.
Erläuterungen zu Resignatur-Optionen
In diesem Abschnitt wird die Interaktion der Optionen EnableResignature und
DisallowSnapshotLUN erläutert. Die folgenden drei Status, die sich aus einer
Änderung dieser Optionen ergeben, werden behandelt:

„Status 1 - EnableResignature=no, DisallowSnapshotLUN=yes (Standard)“ auf
Seite 124

„Status 2 - EnableResignature=yes, (DisallowSnapshotLUN ist nicht relevant)“ auf
Seite 125

„Status 3 - EnableResignature=no, DisallowSnapshotLUN=no“ auf Seite 125
Status 1 - EnableResignature=no, DisallowSnapshotLUN=yes (Standard)
In diesem Status:

Können Sie Snapshots von VMFS-Volumes nicht über den Array an den
ESX Server-Host weitergeben.

Müssen mit VMFS formatierte LUNs für jeden ESX Server-Host dieselbe
ID aufweisen.
Status 1 ist der sicherste Status, aber
124

Er kann auf einigen Arrays (wie z. B. IBM TotalStorage 8000-Arrays und
EMC AX100), die dieselben LUNs nicht immer mit derselben ID anzeigen, sofern
Sie nicht besonders darauf achten, zu Problemen führen.

Sie haben nicht mehr die Möglichkeit, einen Snapshot eines VMFS-Volumes zu
erstellen und an ein ESX Server-System weiterzugeben. Ändern Sie dazu die
Einstellung LMV.EnableResignature in 1.
VMware, Inc.
Status 2 - EnableResignature=yes, (DisallowSnapshotLUN ist
nicht relevant)
In diesem Status:

Können Sie Snapshots von VMFS-Volumes an denselben oder andere
Server weitergeben.

VMFS-Volumes, die LUNs aus IBM TotalStorage 8000 oder AX100 enthalten, die
nicht auf allen Servern mit denselben LUN-Nummern dargestellt werden, können
die auf diesem VMFS-Volume gespeicherten virtuellen Maschinen nicht mehr
verwenden. Vermeiden Sie diese Situation unbedingt.
Status 3 - EnableResignature=no, DisallowSnapshotLUN=no
Mit diesen Einstellungen können Snapshots nicht an den ESX Server-Host
weitergegeben werden. Dies ähnelt dem Verhalten von ESX Server 2.x.
Wenn Sie über einen IBM TotalStorage 8000 oder AX100 verfügen, der aus irgendeinem
Grund nicht so konfiguriert werden kann, dass dieselbe LUN-Nummer auf allen
Servern angezeigt wird, benötigen Sie diese Einstellung, damit alle ESX Server-Systeme
dieselben LUNs für Funktionen wie VMotion, VMware DRS und VMware HA
verwenden können.
Bedenken Sie vor dem Ändern dieser Einstellungen die folgenden
möglichen Probleme:

Wenn Sie ein- oder mehrmals Snapshots eines VMFS-Volumes erstellen und einen
oder mehrere dieser Snapshots dynamisch an einen ESX Server übertragen, ist nur
die erste Kopie brauchbar. Bei der brauchbaren Kopie handelt es sich
wahrscheinlich um die primäre Kopie. Nach dem Neustart kann nicht mehr
ermittelt werden, welches Volume (die Quelle oder einer der Snapshots) brauchbar
ist. Dieses Verhalten birgt Risiken.

Wenn Sie einen Snapshot eines übergreifenden VMFS-Volumes erstellen, könnte
ein ESX Server-Host das Volume aus Fragmenten erneut zusammenstellen,
die zu verschiedenen Snapshots gehören. Dadurch kann Ihr Dateisystem
beschädigt werden.
VMware, Inc.
125
126
VMware, Inc.
A
Checkliste für Multipathing
A
Dieser Anhang enthält eine Checkliste mit Anforderungen für das Multipathing-Setup
für verschiedene Speicher-Arrays.
Komponente
Anmerkungen
Alle Speicher-Arrays
Write-Cache muss deaktiviert werden, sofern er nicht batteriegepuffert ist.
Topologie
Kein einzelner Ausfall sollte zu einem Failover von HBA und SP führen,
insbesondere mit Aktiv/Passiv-Speicher-Arrays.
IBM TotalStorage DS 4000
(ehemals FastT)
Der Standard-Host-Typ muss LNXCL sein.
Der Host-Typ muss LNXCL sein.
AVT (Auto Volume Transfer) ist in diesem Host-Modus deaktiviert.
HDS 99xx- und
95xxV-Familie
HDS 9500V-Familie (Thunder) erfordert zwei Host-Modi:

Host-Modus 1 Standard.

Host-Modus 2 Sun Cluster
HDS 99xx-Familie (Lightning) und HDS Tabma (USP) erfordern, dass der
Host-Modus auf Netware gesetzt wird.
EMC Symmetrix
EMC Clariion
HP MSA
Aktivieren Sie die SC3-Einstellung. Deaktivieren Sie die SPC2-Einstellung.
Alle Initiator-Records müssen folgende Eigenschaften aufweisen

Failover-Modus = 1

Initiatortyp = Clariion Open

Array CommPath = Aktiviert oder 1
Der Host-Typ muss Linux sein.
Setzen Sie den Verbindungstyp für jeden HBA-Port auf Linux.
VMware, Inc.
127
Komponente
Anmerkungen
HP EVA
Setzen Sie den Host-Typ für EVA3000/5000 Firmware 4.001 und höher
sowie EVA4000/6000/8000 Firmware 5.031 und höher auf VMware.
Setzen Sie den Host-Modustyp andernfalls auf Benutzerdefiniert. Der
Wert lautet:

EVA3000/5000 Firmware 3.x: 000000002200282E

EVA4000/6000/8000: 000000202200083E
HP XP
Für XP 128/1024/10000/12000 sollte der Host-Modus auf 0C (Windows),
d. h. zeroC (Windows) gesetzt werden.
NetApp
Keine besonderen Anforderungen.
ESX Server-Konfiguration
Legen Sie die folgenden erweiterten Einstellungen für den
ESX Server-Host fest:

Setzen Sie Disk.UseLunReset auf 1.

Setzen Sie Disk.UseDeviceReset auf 0.
Für alle LUNs, die Cluster-Festplatten für Aktiv/Passiv-Arrays hosten,
muss Zuletzt verwendet als Multipathing-Policy festgelegt werden. Für
LUNs auf Aktiv/Aktiv-Arrays kann Zuletzt verwendet oder Fest als
Multipathing-Policy gewählt werden.
Alle FC-HBAs müssen dasselbe Modell sein.
128
VMware, Inc.
B
Dienstprogramme
B
In den meisten Fällen eignet sich der VI-Client ideal für die Überwachung eines
ESX Server-Hosts, der mit SAN-Speicher verbunden ist. Erfahrene Benutzer können
einige Befehlszeilendienstprogramme für zusätzliche Details verwenden.
Dieser Anhang enthält Informationen zu den folgenden Dienstprogrammen:

„Dienstprogramm esxtop“ auf Seite 130.

„Dienstprogramm storageMonitor“ auf Seite 130.
VMware, Inc.
129
Dienstprogramm esxtop
Das Befehlszeilen-Tool esxtop bietet einen sehr ausführlichen Überblick darüber, wie
ESX Server Ressourcen in Echtzeit nutzt. Das Tool wird auf der Service-Konsole des
ESX Server-Hosts ausgeführt. Ausführliche Informationen zu esxtop finden Sie im
Handbuch zum Ressourcen-Management, oder geben Sie man esxtop an der
Befehlszeileneingabeaufforderung ein.
Dienstprogramm storageMonitor
Das Dienstprogramm storageMonitor überwacht SCSI-Sense-Fehler, die in
Speicher-Devices auftreten, die mit VMware ESX Server verbunden sind. Das
Dienstprogramm trägt Sense-Fehlerinformationen zusammen, indem es den im
VMkernel ausgeführten storageMonitor in regelmäßigen Abständen abfragt und
Fehlerinformationen an Standardausgabe, eine Datei oder das Systemprotokoll sendet.
Bevor Fehlerinformationen an eine Ausgabe gesendet werden, werden sie formatiert.
Das Dienstprogramm wandelt z. B. Sense-Fehlercodes gemäß SCSI-3-Spezifikation in
entsprechenden Text um.
Ist keine Konfigurationsdatei angegeben, analysiert storageMonitor die
Standardkonfigurationsdatei /etc/vmware/storageMonitor.conf, um
bestimmte Fehler zu filtern und die Anzeige anderer Fehler zu ermöglichen.
Sie können storageMonitor im interaktiven Modus oder mit der Option -d im
Daemon-Modus ausführen.
130

„Optionen“ auf Seite 131.

„Beispiele“ auf Seite 131.
VMware, Inc.
Anhang B Dienstprogramme
Optionen
Sie können storageMonitor mit einer der folgenden Optionen über die
ESX Server-Befehlszeile aufrufen.
Tabelle B-1. Befehlszeilenoptionen von storageMonitor
Option
Beschreibung
<config-file>
Mit dieser Option können Sie eine Konfigurationsdatei angeben. Ist diese
Option nicht spezifiziert, wird der Standard verwendet.
Die Konfigurationsdatei gibt an, welche Fehlerarten storageMonitor
zulassen soll und welche vor der Anzeige gefiltert werden sollen.
Die Standardkonfigurationsdatei stellt das Format der Einträge dar.
-d
Gibt an, dass storageMonitor im Daemon-Modus ausgeführt werden
soll. Wenn diese Option angegeben ist, erfolgt die Ausgabe in syslog oder
eine vom Anwender angegebene Log-Datei. Wenn die Option -s
ebenfalls angegeben ist, wird die Ausgabe darüber hinaus in die
Standardausgabe geschrieben.
-h
Zeigt Hilfeinformationen an.
-l <log_file>
Wenn diese Option angegeben ist, wird die Ausgabe des Programms in
<log_file> geschrieben. Diese Option ist nur gültig, wenn die Option -d
ebenfalls angegeben ist.
-p <poll_interval>
Mit dieser Option können Sie das Intervall zum Abfragen des
Kernel-residenten Speichers und zum Abrufen des Status oder der
Fehler der Speicher-Devices in Sekunden angeben. Wird diese
Option nicht festgelegt, wird das Standard-Abrufintervall von
10 Sekunden verwendet.
-s
Gibt an, dass storageMonitor die Ausgabe an die Standardausgabe
senden soll. Diese Option ist nur gültig, wenn Sie storageMonitor im
Daemon-Modus starten (Option -d ist angegeben).
Beispiele
storageMonitor -p 60
Setzt das Abrufintervall auf 60 Sekunden. Sendet die Ausgabe an die Standardausgabe
(da storageMonitor nicht im Daemon-Modus ausgeführt wird). Verwendet die in der
Standardkonfigurationsdatei angegebenen Filter vor dem Senden der Ausgabe.
storageMonitor -d -c myconf.conf
VMware, Inc.
131
Führt storageMonitor im Daemon-Modus mit der Konfigurationsdatei myconf.conf
aus. Schreibt die Ausgabe in syslog. Standardmäßig befindet sich syslog in
/var/log/storageMonitor.
storageMonitor -d -l mylog.log -s
Führt storageMonitor im Daemon-Modus mit der Standardkonfigurationsdatei aus.
Sendet die Ausgabe an mylog.log anstelle von syslog. Schreibt die Ausgabe auch in
die Standardausgabe, da die Option -s angegeben ist.
132
VMware, Inc.
Index
Symbols
* neben Pfad 100
.vmdk-Datei 21
A
Abrufen von Informationen 89
Aktiv/Aktiv-FestplattenArrays 55, 71, 100, 104
Aktiv/Passiv-FestplattenArrays 48, 55, 84, 100
HP StorageWorks MSA 72
Pfad-Thrashing 114
Systemstart über SAN 58
Zurücksetzen der Pfad-Policy 89
Aktive Pfade 101
Aktiver Pfadstatus 99
Aktivieren der Boot-Auswahl 84
Aktivieren der Boot-BIOSEingabeaufforderung für
Aktivieren des BIOS für Systemstart
über SAN 86
Aktivieren von Pfaden 102, 103
Aktueller Multipathing-Status 98
Ändern von disk.maskLuns 97
Ändern von disk.maxLun 96
Ändern von disk.supportSparseLun 97
Anwendergruppen
Zugriff 12
Anwendungen mit mehreren
Ebenen 121
Anwendungen, Mehrere Ebenen 121
VMware, Inc.
Anwendungsbeispiele 33
Anzahl ausstehender
Festplattenanforderungen 115
Anzahl der Erweiterungen 22
Anzeigeprobleme, AX100 65
Array-Basierte (Drittanbieter)Lösung 121
Ausfall 49
Ausgefallene Pfade 99
Ausgleichen des Festplattenzugriffs 115
Ausstehende
Festplattenanforderungen 115
Authentifizierungs-Daemon 25
Auto Volume Transfer 70
Automatische Volume-Resignatur 66
IBM TotalStorage 71
AVT 70, 114
AX100 65
Anzeigeprobleme 65
Inaktive Verbindungen 65
B
Backups 55, 118
Drittanbieter-Backup-Paket 120
Lösung 120
Überlegungen 118
Band-Devices 56
Befehle, SDK 23
Beheben von Problemen 109
Betriebssystem-Timeout 108
Bevorzugter Pfad 100, 103
133
BIOS
Für Systemstart über SAN
aktivieren 86
Qlogic-HBA für Systemstart über
SAN aktivieren 83
Boot-Auswahl, aktivieren 84
Boot-BIOS-Eingabeaufforderung, für
Systemstart über SAN
aktivieren 85
Boot-LUN 84
Boot-LUN, auswählen 84
BusLogic
SCSI-Controller 20
Warteschlangentiefe 54
C
CD-ROM, Systemstart 85
Clariion AX100 123
Client der virtuellen Infrastruktur 16, 23
Cluster in einer Box 50
Cluster in mehreren Boxen 50
Cluster-Dienste 50
Consolidated Backup-Proxy 55
CPU-Virtualisierung 19
Device-Treiberoptionen 107
Emulex 107
Qlogic 107
Diagnosepartitionen 54
Gemeinsam nutzen 109
Dienstprogramme
esxtop 130
storageMonitor 130
Direktverbindung 62
disallowSnapshotLUN 124, 125
Disaster Recovery 34
disk.maskLuns 96, 97
disk.maxLun 95, 96
Disk.SchedNumReqOutstanding
(Parameter) 115
disk.supportSparseLun 97
Drittanbieter, ManagementAnwendungen 39
Drittanbieter-Backup-Paket 120
DRS 52
DS4000, Hardware-Konfiguration für
SAN-Failover 67
Dump-Partitionen 54
Gemeinsam nutzen 109
D
Datastores, Entfernen 95
Datenzugriff 43, 44
(SAN) Überblick 45, 48
RDM 38
Überblick 44
VMFS 38
Deaktivieren der automatischen VolumeÜbertragung 70
Deaktivieren von Pfaden 102
Deaktivierter Pfadstatus 99
Details zu Speicher-Devices 90
Device-Treiber 16
134
E
Ebenen, Komplexität 37
Einschränkungen 55
EMC CLARiiON 64
EMC CLARiiON AX100 65
EMC Symmetrix 66
Pseudo-LUNs 66
Emulex FC HBA
lpfc_linkdown_tmo 107
VMware, Inc.
Index
Emulex-FC-HBA
enableResignature 124, 125
Entfernen von Datastores 95
Entfernen von LUNs 95
Entfernen von VMFS-2-Treibern 115
Erneut scannen
LUN-Anzeige 37
Erweiterte Konfiguration der LUNAnzeige 95
Erweiterungen 22
Definition 91
ESX Server
Einführung 16
Gemeinsame VMFS-Nutzung 35
Vorteile 32
ESX Server und SAN,
Voraussetzungen 54
esxtop (Dienstprogramm) 130
EVA (HP StorageWorks) 74
Aktiv/Aktiv 55, 100, 104
Aktiv/Passiv 55, 71, 84, 100, 114
Zoning von Festplatten-Array zu
ESX Server 94
Festplattenzugriff, Ausgleichen 115
Feststehend, Pfad-Policy 48
G
Gemeinsam genutzte Festplatten 43
Gemeinsame Nutzung von
Gemeinsame VMFS-Nutzung auf
mehreren Servern 35
Größe der Zonen 40
H
HA 49
Hardware-Kompatibilität 18
HBA
Einrichten 56
Emulex 85
F
Failover 46, 51, 105
FAStT-Speicher 67
HBA 107
I/O-Verzögerung 48
Zonen 40
Fallen 89
FC-HBA-Setup 56
Fehler
Hub-Controller 74
Fehlerbehebung 88, 109
Feste Pfad-Policy 100, 101
Bevorzugter Pfad 103
Pfad-Thrashing 113
Festplatten, Konfigurationsoptionen 21
VMware, Inc.
Festplatten-Arrays
Liste von Typen 90
Qlogic 83
Qlogic-HBA-BIOS für Systemstart
über SAN aktivieren 83
Statischer Lastausgleich 56
Timeout 107
Typen 90
High-Tier-Speicher 48
Hitachi Data Systems-Speicher 75
Microcode 75
hostd 25
Host-Daemon 25
Host-Typ 64
135
HP StorageWorks 72
Lastausgleich 34, 56, 104
MSA 72
Manuell 104
LDAP 25
Leistung 110, 111
XP 74
Hub-Controller, Fehler 74
I
Entfernen von
VMFS-2-Treibern 115
I/O-Verzögerung 48, 54
IBM TotalStorage DS4000 67
Optimieren 110
Pfad-Thrashing 71
IBM TotalStorage EnterpriseSpeichersysteme 71
Informationssuche 34
Installation
SAN 58
Schritte 59
Vorbereiten für Systemstart über
SAN 79
Interaktion mit ESX ServerSystemen 23
Inter-Switch Link 68
iSCSI 22
ISL 68
K
Kabel
Neu anschließen und
Neu scannen 94
Verbindungsprobleme 93
Komplexität 37
Konfiguration
Optionen 21
Sense-Daten des
Speicherprozessors 70
Konfigurieren der Hardware für
SAN-Failover
DS4000 67
136
L
EVA 74
Probleme 112
Überwachen 112
Linux
Host-Typ 64
Profilname 72
Service-Konsole 25
VMkernel 16
Linux Cluster, Host-Typ 64
Liste von HBA-Typen 90
Logical Volume Manager 22
Lösungen 88
Lower-Tier-Speicher 48
lpfc_linkdown_tmo (Parameter) 107
lpfc_nodedev_tmo (Parameter) 107
LSI Logic-SCSI-Controller 20
LSILogic
LUN nicht sichtbar 92
Kabelverbindung 93
Masking 93
Probleme 93
SP-Sichtbarkeit 93
Zoning 93
LUN-Erkennung, VMkernel 37
LUN-Maskierung 40
LUN-Masking 93
VMware, Inc.
Index
LUNs
1 VMFS-Volume 54
Ändern der gescannten Anzahl 95
Anzeige und erneutes Scannen 37
Anzeigekonfiguration 95
Boot-LUN 84
Boot-LUN auswählen 84
disk.maskLuns 96
Entfernen 95
Entscheidungen 41
Erstellen, und Neu scannen 94
Festlegen der MultipathingPolicy 101
Gescannte Anzahl 95
Masking-Änderungen und
Neu scannen 94
maxLun 95
Mehrere Erweiterungen 91
Microcode, Hitachi Data
Systems-Speicher 75
Microsoft Cluster Service 23, 33, 62
Mid-Tier-Speicher 48
MRU-Pfad-Policy 100
MSA (HP StorageWorks) 72
MSCS 33, 62
Multipathing 97
Status 98
Multipathing-Policy 101
Festlegen 102
Multipathing-Software 38
Multipathing-Status 98
Multipathing-Policy 101
N
Nicht sichtbar 92
N+1-Clustering 50
Navisphere Express 123
net-snmpd 25
Netware-Host-Modus 75
Network Appliance-Speicher 75
Sparse 97
Unsichtbar 123
Wenige große oder viele kleine 40
Zuweisungen 55
LVM 22
LVM.DisallowSnapshotLUN
(Parameter) 122
LVM.EnableResignature
(Parameter) 122
Speicherbereitstellung 76
Netzwerkvirtualisierung 19
Neu scannen 94
Bei ausgefallenem Pfad 94
Hinzufügen eines
Festplatten-Arrays 94
M
Management-Anwendungen 39
Manueller Lastausgleich 104
Mapping-Datei 23
Maskierung 40
Masking
Verwenden von disk.maskLuns 96
Maximale HBAWarteschlangentiefe 116
VMware, Inc.
LUN-Erstellung 94
LUN-Masking 94
Neu anschließen von Kabeln 94
NFS 22
O
Offline-VMFS-Volumes 123
Optimieren der Ressourcen-Nutzung 51
137
P
P2V-Clustering 50
PAM 25
Parameter, lpfc_nodedev_tmo 107
Passiv-FestplattenArrays 55, 71, 84, 100
Pfad-Thrashing 114
Performance
SCSI-Reservierungen 35
Pfadausfall
Neu scannen 94
Pfade
Priorität für virtuelle Rechner 43
Probleme 88
Hub-Controller 74
Leistung 112
Offline-VMFS-Volumes 123
Sichtbarkeit 92
Vermeiden 109
Profilname, Linux 72
Prozesse, Service-Konsole 25
Q
Qlogic FC HBA
Aktiv 101
Aktivieren 102, 103
Bevorzugt 100, 103
Deaktivieren 102
Pfade verwalten (Dialogfeld) 103
Pfad-Failover 46
Pfad-Management 46, 104
Pfad-Policies
Feststehend 48, 100, 101
MRU 100
Pfad-Policy
Zuletzt verwendet 101
Pfadstatus 99
Pfad-Thrashing 65, 113, 114
IBM TotalStorage DS4000 71
Pluggable Authentication Module 25
Port-Adresse 31
PortDownRetryCount (Parameter) 107
Port-ID 31
Ports
Konfiguration 69
Präventionsmaßnahmen
PortDownRetryCount 107
Qlogic-FC-HBA
Qlogic-HBA-BIOS
Für Systemstart über SAN
aktivieren 83
R
RADIUS 25
Raw Device Mapping 23, 44, 65
Mapping-Datei 23
RDM 23, 38, 44, 65
Mapping-Datei 23
Microsoft Cluster Service 23
Reservierungen
Verringern von
Resignatur 66
IBM TotalStorage 71
Optionen 124
Ressourcen-Nutzung, optimieren 51
Gegen Server-Ausfälle 49
138
VMware, Inc.
Index
S
Speicher-Devices
SAN 40
Arrays 35
Backup-Überlegungen 118
Hardware-Failover 67
Anzeigen 90
Details 90
Speicheroptionen 40
Speicherprozessoren
Installationsüberlegungen 58
Konfigurieren von Sense-Daten 70
Server-Failover 51
Port-Konfiguration 69
Voraussetzungen 54
Vorbereiten 81
Vorbereiten für
ESX Server-Installation 79
SAN-Fabric 30
SAN-Speicher
Vorteile 32
SAN-Speicherleistung, Optimieren 110
Scan, Anzahl ändern 95
SCSI-Controller,
SCSI-Reservierungen, Verringern 116
SDK 23
Server-Ausfall 49
Server-Failover 51
Server-Leistung 111
Service-Konsole 16, 25
Authentifizierung 25
Prozesse 25
Schnittstellen 25
Services, Service-Konsole 25
Setup-Schritte 59
Sichtbarkeitsprobleme 92
snapshot 122
Snapshot-Software 119
SNMP-Server 25
Software-Kompatibilität 18
Sparse-LUN-Unterstützung 97
Speicher-Arrays
Sense-Daten 70
Speichersysteme
EMC CLARiiON 64
EMC Symmetrix 66
Hitachi 75
HP StorageWorks 72
Network Appliance 75
Speichervirtualisierung 19
Sperren 22
SP-Sichtbarkeit, LUN nicht sichtbar 93
Standby-Pfadstatus 99
Sternchen neben Pfad 100
storageMonitor (Dienstprogramm) 130
Systemstart über CD-ROM 85
Systemstart über SAN
Einführung 78
Emulex-FC-HBA 85
ESX Server-Voraussetzungen 58
HBA-Voraussetzungen 58
Konzeptionelle Übersicht 78
LUN-Maskierung 81
Qlogic-FC-HBA 83
Qlogic-HBA-BIOS aktivieren 83
Überlegungen zur Boot-LUN 58
Voraussetzungen 57
Vorbereiten der Installation 79
Vorteile 79
Leistung 110
VMware, Inc.
139
T
VMFS 22, 38, 40
1 Volume pro LUN 54
Tests 62
Timeout 107, 108
TimeoutValue (Parameter) 54
Tipps 42
Treiber
Erstellen eines neuen Volumes 22
Gemeinsame Nutzung auf mehreren
ESX Server-Systemen 35
Device-Treiber 107
Mindestgröße 22
VMFS -2 115
U
Überwachen der Leistung 112
Unsichtbare LUNs 123
Unterstützte Devices 63
V
Vermeiden von Problemen 109
Verteilte Sperren 22
VI Web Access 16, 23
Virtual Infrastructure SDK 23
Virtual Machine File System 22
Virtual Machine Monitor 16
Virtualisierung 19
Überblick 26
Virtuelle Maschinen
Ausgleichen des
Festplattenzugriffs 115
Datenzugriff 44
Datenzugriff im SAN 45, 48
Gemeinsames Nutzen von
Devices 26
I/O-Verzögerung 48
Priorität zuweisen 43
SAN-Datenzugriff 45, 48
Standard-Konfiguration 37
Virtuelle SCSI-HBAs 20, 23
vmauthd 25
140
Anzahl der Erweiterungen 22
Sperren 22
VMFS-2-Treiber 115
VMFS-Volume-Resignatur 122
VMFS-Volumes
Offline 123
vmhba 91
VMkernel 16
Konfiguration 108
LUN-Erkennung 37
VMM 16
VMotion 33, 34, 52, 55
VMware Consolidated Backup-Proxy 55
VMware DRS 33, 34, 52
VMware HA 33, 49
VMware-Diskussionsforen
Zugriff 12
Volume-Resignatur 66, 122
TotalStorage 71
Voraussetzungen 54
Vorteile 32
W
Wartung 33
Wissensbasis
Zugriff 12
World Wide Port Name 30
WWPN 30, 69
VMware, Inc.
Index
X
XP (HP StorageWorks) 74
Z
Zonen
Empfohlene Größe 40
Erstellung 40
Failover 40
Zoning
ESX Server 39
Zugriff
Ausgleichen des
Festplattenzugriffs 115
Daten 43, 44
Kontrolle 40
Zuletzt verwendete Pfad-Policy 100, 101
Pfad-Thrashing 113
Zurücksetzen der Pfad-Policy
Aktiv/Passiv-Festplatten-Array 89
Zuweisungen 55
VMware, Inc.
141
142
VMware, Inc.