Website-Suche

So erstellen und fügen Sie Citrix XenServer-Speicher-Repositorys hinzu – Teil 4

Im vierten Artikel dieser XenServer-Reihe werden Speicherlösungen besprochen. Ähnlich wie Netzwerke sind Speicherlösungen in XenServer oft zunächst schwer zu verstehen. Bevor mit der Konfiguration begonnen wird, sollten die neuen Terminologien und Konzepte im Zusammenhang mit der XenServer-Speicherung besprochen werden.

Update: Im Mai 2016 veröffentlichte Citrix die neue Version der XenServer 7-Plattform. Zur Installation folgen Sie: Neuinstallation von XenServer 7.

XenServer führt mehrere neue Begriffe in die Liste der traditionellen Speicherterminologie ein. Während es bei der Arbeit mit einem IT-System immer wichtig ist, die Konzepte zu verstehen, ist die Speicherung bei weitem nicht so wichtig wie im vorherigen Artikel über Netzwerkkonzepte. Dieser Artikel wird sich jedoch dennoch die Zeit nehmen, diese Speicherkonzepte zu erklären und zu klären.

Das Erste, was Sie bei XenServer-Speicher beachten sollten, ist, dass wir über Speicher für den eigentlichen XenServer-Host und dann auch über Speicher für die Gast- oder virtuellen Maschinen verfügen, die auf dem XenServer-Host ausgeführt werden. Vom Konzept her ist dies einfach zu verstehen, aber die Verwaltung kann eine entmutigende Aufgabe sein, wenn der Administrator mit den Zwecken 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. Speicherrepositorys können verschiedene Arten von Speichersystemen sein, darunter lokaler Speicher, der physisch an den XenServer-Host angeschlossen ist, iSCSI/Fibre Channel LUN, NFS-Netzwerkdateifreigaben oder Speicher auf einem Dell/NetApp-Speichergerät.

Speicherrepositorys können gemeinsam genutzt oder dediziert werden und unterstützen zahlreiche nützliche Funktionen wie schnelles Klonen, spärliche Zuweisung (Speicher wird so bereitgestellt, wie die virtuelle Maschine ihn benötigt) und in der Größe veränderbare virtuelle Festplatten-Images (mehr dazu später).

Speicherrepositorys (SR) sind logisch mit einem XenServer-Host über ein sogenanntes Physical Block Device verbunden, das häufiger als „PBD“ bezeichnet wird. Die PBD ist lediglich eine Referenz auf einen Speicherort. Diese PBD-Objekte können in einen XenServer-Host „eingesteckt“ werden, um diesem Host das Lesen/Schreiben von Informationen in dieses Speicher-Repository zu ermöglichen.

Der Zweck von Speicherrepositorys besteht in erster Linie darin, die Virtual Disk Image (VDI)-Dateien der virtuellen Maschine zu speichern. VDI-Dateien sind Stellen auf einem SR, die zum Speichern des Betriebssystems und anderer 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 die Art des Speicherrepositorys bestimmt.

Gängige VDI-Typen in XenServer sind Logical Volumes (LV), die vom Logical Volume Manager verwaltet werden, Virtual Hard Disk (VHD) oder sie können Logical Unit Numbers (LUN) auf einem Dell- oder NetApp-Speichergerät sein. Hinweis: In diesem Artikel werden LUNs auf einem Dell-Speichergerät verwendet.

Diese VDI-Dateien sind logisch mit virtuellen Maschinen über ein Objekt verbunden, das als Virtual Block Device bekannt ist und allgemein als „VBD“ bezeichnet wird. Diese VBD-Objekte können an virtuelle Gäste angehängt werden, wodurch der Gastcomputer dann auf die in diesem bestimmten VDI auf einem entsprechenden SR gespeicherten Daten zugreifen kann.

Ähnlich wie bei Netzwerken in XenServer ist das Lesen über Speicher eine Sache, aber wenn man die Beziehung zwischen den einzelnen Elementen erkennen kann, werden die Konzepte oft gefestigt. Die gängigen Diagramme, die zur Darstellung von XenServer-Speicherkonzepten verwendet werden, verwirren Neulinge 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 sei. Dies ist nicht der Fall und führt oft zu großer Verwirrung darüber, wie XenServer-Speicher funktioniert. Die folgende Grafik versucht, die Konzepte weniger linear, sondern pragmatischer zu erklären.

Hoffentlich verwirrt die obige Grafik die Leute nicht noch mehr in Bezug auf XenServer-Speicher. Das zweite Bild ist ein Versuch, die logischen Verbindungen (PBD und VBD) darzustellen, die verwendet werden, um XenServer und Gäste über eine tatsächliche Netzwerkverbindung mit dem Remotespeicher zu verbinden.

Mit der Konzeptualisierung aus dem Weg; Die Konfiguration kann beginnen. In Erinnerung 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 (Gäste) verwendet. In diesem Handbuch geht es nicht um die Konfiguration des Dell iSCSI-Geräts.

Systemkonfiguration:

  1. XenServer 6.5 installiert und gepatcht (Teil 1 der Serie)
  2. Dell PS5500E iSCSI-Gerät (andere iSCSI-Geräte können verwendet werden, ersetzen Sie einfach bei Bedarf die Umgebungsinformationen).
  3. XenServer-Netzwerkschnittstellen konfiguriert (Teil 3 der Serie).
  4. iSCSI-Gerät und XenServer können sich logisch sehen (über das Ping-Dienstprogramm).
  5. CIFS (SAMBA) Server, auf dem ein Teil der CD-ISO-Dateien läuft und gehostet wird (nicht erforderlich, aber sehr nützlich).

Erstellung des Citrix XenServer-Speicher-Repositorys

In diesem ersten Prozess werden die Schritte zum Erstellen eines Software-iSCSI-Initiators vom XenServer-Host zum Dell PS5500E durchlaufen.

Diese bestimmte 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 herkömmlicher ‘xe’-Befehl ausgeführt. Vor der Erstellung des Speicher-Repositorys müssen die richtigen iSCSI-Informationen eingeholt werden.

Durch die Übergabe 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.

  1. sr-probe – Wird verwendet, um das iSCSI-Gerät nach Informationen über das für diesen XenServer-Host erstellte Volume abzufragen.
  2. 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. Stellen Sie sicher, dass Sie die Änderungen an den Speichergerätetyp anpassen.
  3. device-config:target= Wird verwendet, um dem XenServer mitzuteilen, welches iSCSI-Gerät anhand der IP-Adresse abgefragt werden soll.
  4. device-config:chapuser= Dies wird zur Authentifizierung beim iSCSI-Gerät verwendet. In diesem Beispiel wurde zuvor ein iSCSI-Volume für den Benutzer „tecmint“ erstellt. Durch das Senden des Benutzernamens und des Passworts in diesem Befehl antwortet das iSCSI-Gerät mit den notwendigen Informationen, um die Erstellung des Speicher-Repositorys abzuschließen.
  5. device-config:chappassword= Dies ist das Passwort für den oben genannten CHAP-Benutzernamen.

Sobald der Befehl eingegeben und übermittelt 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.

Unten sehen 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 Teil ist als iSCSI IQN bekannt. Dies ist sehr wichtig und wird benötigt, um die SCSIid für das Speicher-Repository zu bestimmen. Mit diesen neuen Informationen kann der vorherige Befehl geändert werden, um die SCSIid zu erhalten.


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 wurde, ist die Zeilengruppe targetIQN. Durch die Ausgabe dieses neuen Befehls antwortet das System mit den letzten Informationen, die zum Erstellen eines iSCSI-Speicher-Repositorys erforderlich sind. Die letzte Information ist 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>

Ab diesem Zeitpunkt sind alle notwendigen Teile zum Erstellen eines iSCSI-Speicher-Repositorys verfügbar und es ist an der Zeit, den Befehl zum Hinzufügen dieses SR zu diesem bestimmten XenServer zu erteilen. Das Erstellen des Speicher-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 gut geht, stellt das System eine Verbindung zum iSCSI-Gerät her und gibt dann die UUID des neu hinzugefügten Speicher-Repositorys zurück.


bea6caa4-ecab-8509-33a4-2cda2599fb75

Die UUID-Ausgabe ist ein tolles Zeichen! Wie bei allen Systemverwaltungsaufgaben 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"
Beispielausgabe

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

Aus der CLI-Ausgabe geht hervor, dass dieser XenServer erfolgreich eine Verbindung zum Dell iSCSI-Gerät hergestellt hat und bereit ist, Gast-VDI-Dateien zu speichern.

Erstellung eines ISO-Speicher-Repositorys

Die nächste Reihe von Schritten führt Sie durch den Prozess der Erstellung einer ISO-Bibliothek. Bei ISO-Dateien handelt es sich in der Regel um Abbilder von CD-Installationsmedien.

Durch die Erstellung eines speziellen Speicher-Repositorys für diese ISO-Dateien kann die Installation neuer Gäste sehr schnell erfolgen. 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 physisch eine CD in einen XenServer im Pool einlegen zu müssen.

In diesem Teil des Handbuchs 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 einen Debian-SAMBA-Server-Leitfaden haben):

  1. Richten Sie den Samba-Server für die Dateifreigabe ein

Der erste Schritt besteht darin, die erforderlichen Anmeldeinformationen und Konfigurationsinformationen für die SAMBA ISO-Bibliothek zu sammeln. Sobald Benutzername, Passwort und Konnektivitätsinformationen verfügbar sind, kann eine einfache Befehlsvariante „xe“ 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
Beispielausgabe

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-Speicher-Repository als auch einer CIFS-ISO-Bibliothek zum Speichern von Installationsmedien für virtuelle Maschinen (Gäste) konfiguriert.

Die nächsten Schritte werden die Erstellung virtueller Maschinen und die Verbindung dieser Systeme mit den richtigen Netzwerken aus dem vorherigen Netzwerkartikel sein.