Erstellen und Hinzufügen von Citrix XenServer-Speicherrepositorys - Teil 4
Im vierten Artikel dieser XenServer-Serie wird auf Speicherlösungen eingegangen. Ähnlich wie bei Netzwerken sind Speicherlösungen in XenServer auf den ersten Blick oft schwer zu verstehen. Bevor Sie mit der Konfiguration beginnen, sollten die neue Terminologie und die Konzepte für den XenServer-Speicher besprochen werden.
Update: Im Mai 2016 hat Citrix die neue Version der XenServer 7-Plattform veröffentlicht. Für die Installation folgen: Neuinstallation von XenServer 7.
XenServer führt mehrere neue Begriffe in die Liste der traditionellen Speicherterminologie ein. Während das Verständnis der Konzepte bei der Arbeit mit einem IT-System immer wichtig ist, ist der Speicher nicht annähernd so wichtig wie der vorherige Artikel über Netzwerkkonzepte. In diesem Artikel wird jedoch dennoch die Zeit in Anspruch genommen, diese Speicherkonzepte zu erläutern und zu verdeutlichen.
Das erste, was Sie beim XenServer-Speicher beachten sollten, ist, dass wir Speicher für den eigentlichen XenServer-Host haben und dann auch Speicher für den Gast oder die virtuellen Maschinen, die auf dem XenServer-Host ausgeführt werden. Konzeptionell ist dies einfach zu verstehen, aber die Verwaltung kann eine entmutigende Aufgabe sein, wenn der Administrator mit dem Zweck der einzelnen Speicheraspekte nicht vertraut ist.
Der erste Begriff ist als "SR" oder Storage Repository bekannt. Dies ist wohl der wichtigste Begriff im XenServer-Speicher, da er das physische Medium darstellt, auf dem Festplatten virtueller Maschinen gespeichert und abgerufen werden. Bei Speicher-Repositories kann es sich um verschiedene Arten von Speichersystemen handeln, z. B. lokalen Speicher, der physisch mit dem XenServer-Host verbunden ist, iSCSI/Fibre Channel-LUN, NFS-Netzwerkdateifreigaben oder Speicher auf einer Dell/NetApp-Speicher-Appliance.
Speicher-Repositories können gemeinsam genutzt oder dediziert werden und können zahlreiche nützliche Funktionen unterstützen, wie z. B. schnelles Klonen, Sparse-Zuweisung (Speicher wird nach Bedarf der virtuellen Maschine bereitgestellt) und VM-Images mit variabler Größe (mehr dazu später).
Storage Repositories, SR, sind logisch mit einem XenServer-Host verbunden, der als physisches Blockgerät bezeichnet wird und häufiger als "PBD" bezeichnet wird. Die PBD ist lediglich ein Verweis auf einen Lagerort. Diese PBD-Objekte können an einen XenServer-Host "angeschlossen" werden, damit dieser Host Informationen in dieses Speicherrepository lesen/schreiben kann.
Der Zweck von Speicher-Repositories besteht in erster Linie darin, die VDI-Dateien (Virtual Disk Image) der virtuellen Maschine zu speichern. VDI-Dateien sind Spots auf einer SR, die dem Betriebssystem und anderen Dateien für virtuelle Maschinen zugewiesen wurden, die auf dem XenServer-Host ausgeführt werden. VDI-Dateien können verschiedene Typen haben. Der Typ wird durch den Typ des Speicher-Repositorys bestimmt.
Gängige VDI-Typen in XenServer sind logische Volumes (LV), die von Logical Volume Manager verwaltet werden, virtuelle Festplatten (VHD) oder logische Einheitennummern (LUN) auf einem Dell- oder NetApp-Speichergerät. Hinweis: In diesem Artikel werden LUNs auf einem Dell Speichergerät verwendet.
Diese VDI-Dateien sind logisch über ein Objekt mit virtuellen Maschinen verbunden, das als Virtual Block Device bezeichnet wird und häufig als "VBD" bezeichnet wird. Diese VBD-Objekte können an virtuelle Gäste angehängt werden, wodurch der Gastcomputer dann auf die Daten zugreifen kann, die in diesem bestimmten VDI auf einer entsprechenden SR gespeichert sind.
Ähnlich wie bei Netzwerken in XenServer ist das Lesen über Speicher eine Sache, aber die Möglichkeit, die Beziehung zwischen jedem dieser Elemente zu sehen, festigt oft die Konzepte. Die gängigen Diagramme, die zur Darstellung von XenServer-Speicherkonzepten verwendet werden, verwirren neuere Leute oft, da die Diagramme oft linear gelesen werden. Unten sehen Sie ein solches Bild, das von Citrix ausgeliehen wurde.
Viele Menschen lesen dies linear von links nach rechts und denken, dass jedes Teil ein separates physisches Gerät ist. Dies ist nicht der Fall und führt oft zu viel Verwirrung über die Funktionsweise des XenServer-Speichers. Die folgende Grafik versucht, die Konzepte auf eine weniger lineare, aber pragmatischere Weise zu erklären.
Hoffentlich verwirrt die obige Grafik Einzelpersonen nicht weiter über den XenServer-Speicher. Das zweite Bild ist ein Versuch, die logischen Verbindungen (PBD und VBD) zu zeigen, die verwendet werden, um XenServer und Gäste über eine tatsächliche Netzwerkverbindung mit dem Remote-Speicher zu verbinden.
Nachdem die Konzeptualisierung aus dem Weg geräumt ist; Die Konfiguration kann beginnen. In Anlehnung an den ersten Artikel dieser Reihe wird in diesem Handbuch ein Dell PS5500E iSCSI-Speichergerät für die Speicherung der Festplatten der virtuellen Maschine (Gast) verwendet. In diesem Handbuch wird die Konfiguration des Dell iSCSI-Geräts nicht erläutert.
Systemkonfiguration:
- XenServer 6.5 installiert und gepatcht (Teil 1 der Serie)
- Dell PS5500E iSCSI-Gerät (andere iSCSI-Geräte können verwendet werden, ersetzen Sie einfach die Umgebungsinformationen bei Bedarf).
- XenServer-Netzwerkschnittstellen konfiguriert (Teil 3 der Serie).
- iSCSI-Gerät und XenServer können sich logisch sehen (über das Ping-Dienstprogramm).
- CIFS (SAMBA) Server, auf dem eine Freigabe von CD-ISO-Dateien ausgeführt und gehostet wird (nicht erforderlich, aber sehr nützlich).
Erstellung eines Citrix XenServer-Speicherrepositorys
Dieser erste Prozess durchläuft die Schritte zum Erstellen eines Software-iSCSI-Initiators vom XenServer-Host zum Dell PS5500E.
Diese spezielle LUN verwendet das Challenge-Handshake Authentication Protocol (CHAP), um den Zugriff auf das iSCSI-Volume auf bestimmte autorisierte Parteien zu beschränken.
Um das Speicher-Repository zu erstellen, wird ein traditioneller 'xe'-Befehl ausgeführt. Die richtigen iSCSI-Informationen müssen abgerufen werden, bevor das Speicher-Repository erstellt wird.
Durch Übergeben des Parameters 'sr-probe' an das Dienstprogramm 'xe' wird der XenServer angewiesen, ein Speichergerät nach dem iSCSI IQN (iSCSI Qualified Name) abzufragen.
Der erste Befehl sieht auf den ersten Blick intensiv aus, ist aber nicht so schlimm, wie er aussieht.
xe sr-probe type=lvmoiscsi device-config:target=X.X.X.X device-config:chapuser="tecmint" device-config:chappassword="tecmint_chap"
Dieser erste Befehl ist erforderlich, um den SCSI-IQN für die Speicher-Repository-Konfiguration zu erfassen. Bevor wir fortfahren, werfen wir einen Blick auf alle Teile dieses Befehls.
- sr-probe – Wird verwendet, um das iSCSI-Gerät nach Informationen über das Volume abzufragen, das für diesen XenServer-Host erstellt wurde.
- type= Wird verwendet, um dem XenServer den Speicher-Repository-Typ mitzuteilen. Dies hängt davon ab, welches System verwendet wird. Aufgrund der Verwendung des Dell PS5500 wird in diesem Befehl lvm über iSCSI verwendet. Achten Sie darauf, dass die Änderungen an den Typ des Speichergeräts angepasst werden.
- device-config:target= Wird verwendet, um dem XenServer mitzuteilen, welches iSCSI-Gerät anhand der IP-Adresse abgefragt werden soll.
- device-config:chapuser= Dies wird verwendet, um sich beim iSCSI-Gerät zu authentifizieren. In diesem Beispiel wurde zuvor ein iSCSI-Volume für den Benutzer "tecmint" erstellt. Wenn Sie den Benutzernamen und das Kennwort in diesem Befehl senden, antwortet das iSCSI-Gerät mit den erforderlichen Informationen, um die Erstellung des Speicher-Repositorys abzuschließen.
- Gerät-Konfiguration:chappassword= Dies ist das Passwort für den obigen CHAP-Benutzernamen.
Sobald der Befehl eingegeben und gesendet wurde, versucht der XenServer, sich beim iSCSI-Gerät anzumelden, und gibt einige Informationen zurück, die erforderlich sind, um dieses iSCSI-Gerät tatsächlich als Speicher-Repository hinzuzufügen.
Im Folgenden finden Sie, was das Testsystem von diesem Befehl zurückgegeben hat.
Error code: SR_BACKEND_FAILURE_96
Error parameters: , The SCSIid parameter is missing or incorrect , <?xml version"1.0" ?>
<iscsi-target-iqns>
<TGT>
<Index>
0
</Index>
<IPAddress>
</IPAddress>
<TargetIQN>
iqn.2001-05.com.equallogic:0-8a096-0d9a4ab02-46600020343560ef-xenct-xen2
</TargetIQN>
</TGT>
<TGT>
<Index>
</Index>
<IPAddress>
</IPAddress>
<TargetIQN>
</TargetIQN>
</TGT>
</iscsi-target-iqns>
Das hier hervorgehobene Stück ist als iSCSI IQN bekannt. Dies ist sehr wichtig und wird benötigt, um die SCSIid für das Speicherrepository zu bestimmen. Mit diesen neuen Informationen kann der vorherige Befehl geändert werden, um die SCSIid abzurufen.
xe sr-probe type=lvmoiscsi device-config:target=X.X.X.X device-config:targetIQN=iqn.2001-05.com.equallogic:0-8a0906-0d9a4ab02-46600020343560ef-xenct-xen2 device-config:chapuser="tecmint" device-config:chappassword="tecmint_chap"
Das einzige, was dem Befehl hinzugefügt wird, ist die targetIQN-Zeilengruppe. Wenn Sie diesen neuen Befehl ausgeben, antwortet das System mit den letzten Informationen, die zum Erstellen eines iSCSI-Speicher-Repositorys erforderlich sind. Bei der letzten Information handelt es sich um die SCSI-ID.
Error code: SR_BACKEND_FAILURE_107
Error parameters: , The SCSIid parameter is missing or incorrect , <?xml version"1.0" ?>
<iscsi-target>
<LUN>
<vendor>
EQLOGIC
</vendor>
<serial>
</serial>
<LUNid>
0
</LUNid>
<size>
107379425280
</size>
<SCSIid>
36090a028b04a9a0def60353420006046
</SCSIid>
</LUN>
</iscsi-target>
Von diesem Punkt an sind alle notwendigen Teile zum Erstellen eines iSCSI-Speicher-Repositorys verfügbar, und es ist an der Zeit, den Befehl zum Hinzufügen dieser SR zu diesem bestimmten XenServer auszugeben. Das Erstellen des Storage Repositorys aus den kombinierten Informationen erfolgt wie folgt:
xe sr-create name-label="Tecmint iSCSI Storage" type=lvmoiscsi content-type=user device-config:target=X.X.X.X device-config:port=3260 device-config:targetIQN=iqn.2001-05.com.equallogic:0-8a0906-0d9a4ab02-46600020343560ef-xenct-xen2 device-config:chapuser="tecmint" device-config:chappassword="tecmint_chap" device-config:SCSIid=36090a028b04a9a0def60353420006046
Wenn alles in Ordnung ist, stellt das System eine Verbindung zum iSCSI-Gerät her und gibt dann die UUID des neu hinzugefügten Storage Repositorys zurück.
bea6caa4-ecab-8509-33a4-2cda2599fb75
Die UUID-Ausgabe ist ein gutes Zeichen! Wie bei allen Aufgaben der Systemadministration ist es immer eine gute Idee, zu bestätigen, dass der Befehl erfolgreich war. Dies kann mit einem weiteren 'xe'-Befehl erreicht werden.
xe sr-list name-label="Tecmint iSCSI Storage"
Beispiel-Ausgabe
uuid ( RO) : bea6caa4-ecab-8509-33a4-2cda2599fb75
name-label ( RW) : Tecmint iSCSI Storage
name-description ( RW) :
host ( RO) : xenct-xen2
type ( RO) : lvmoiscsi
content-type ( RO) : user
Über die CLI-Ausgabe hat sich dieser XenServer erfolgreich mit dem Dell iSCSI-Gerät verbunden und ist bereit, Gast-VDI-Dateien zu speichern.
Erstellung eines ISO-Speicher-Repositorys
Die nächste Reihe von Schritten führt Sie durch den Prozess des Erstellens einer ISO-Bibliothek. ISO-Dateien sind in der Regel Images von CD-Installationsmedien.
Dadurch, dass für diese ISO-Dateien ein spezielles Speicher-Repository erstellt wird, kann die Installation neuer Gäste sehr schnell durchgeführt werden. Wenn ein Administrator einen neuen Gast erstellen möchte, kann er einfach eine der ISO-Dateien auswählen, die in dieser ISO-Bibliothek vorhanden sind, anstatt eine CD physisch in einen XenServer im Pool legen zu müssen.
In diesem Teil der Anleitung wird davon ausgegangen, dass der Benutzer über einen funktionierenden SAMBA-Server verfügt. Wenn kein SAMBA-Server eingerichtet ist, lesen Sie bitte diesen Artikel darüber, wie Sie diese Aufgabe in Red Hat/Fedora erledigen können (ich werde in Zukunft eine Anleitung für Debian-SAMBA-Server haben):
- Samba-Server für die Dateifreigabe einrichten
Der erste Schritt besteht darin, die erforderlichen Anmeldeinformationen und Konfigurationsinformationen für die SAMBA-ISO-Bibliothek zu sammeln. Sobald der Benutzername, das Passwort und die Verbindungsinformationen verfügbar sind, kann eine einfache 'xe'-Befehlsvariante verwendet werden, um die SAMBA-Bibliothek mit dem XenServer zu verbinden.
xe-mount-iso-sr //<servername>/ISO -o username=<user>,password=<password>
Dieser Befehl gibt nichts auf dem Bildschirm aus, es sei denn, er schlägt fehl. Um zu bestätigen, dass die SAMBA-ISO-Freigabe tatsächlich gemountet wurde, geben Sie einen weiteren 'xe'-Befehl ein:
xe sr-list
Beispiel-Ausgabe
uuid ( RO) : 1fd75a51-10ee-41b9-9614-263edb3f40d6
name-label ( RW) : Remote ISO Library on: // /ISO
name-description ( RW) :
host ( RO) : xenct-xen2
type ( RO) : iso
content-type ( RO) : iso
Dieser XenServer-Host ist jetzt sowohl mit einem iSCSI-Speicherrepository als auch mit einer CIFS-ISO-Bibliothek konfiguriert, um Installationsmedien für virtuelle Maschinen (Gäste) zu speichern.
Die nächsten Schritte sind die Erstellung virtueller Maschinen und die Verbindung dieser Systeme mit den richtigen Netzwerken aus dem vorherigen Netzwerkartikel.