Citrix Hypervisor

Erstellen eines Speicher-Repositorys

Wichtig:

Citrix Hypervisor 8.2 Kumulatives Update 1 wird am 25. Juni 2025 End of Life. Planen Sie jetzt Ihr Upgrade auf XenServer 8, um einen reibungslosen Übergang und kontinuierlichen Support zu gewährleisten. Weitere Informationen finden Sie unter Upgrade.

Wenn Sie Ihre Citrix Virtual Apps and Desktops-Lizenzdateien verwenden, um Ihre Citrix Hypervisor 8.2 Cumulative Update 1-Hosts zu lizenzieren, sind diese Lizenzdateien nicht mit XenServer 8 kompatibel. Vor dem Upgrade müssen Sie XenServer Premium Edition-Socket-Lizenzdateien für die Verwendung mit XenServer 8 erwerben. Diese Socket-Lizenzdateien sind als Berechtigung für die Abonnements Citrix für Private Cloud, Citrix Universal Hybrid Multi-Cloud, Citrix Universal MSP und Citrix Platform License für die Ausführung Ihrer Citrix-Workloads verfügbar. Citrix-Kunden, die noch nicht auf diese neuen Abonnements umgestiegen sind, können die Teilnahme an einer kostenlosen Aktion für 10.000 XenServer Premium Edition-Socket-Lizenzen anfordern. Weitere Informationen finden Sie unter XenServer (Englisch).

Wenn Sie vor dem Upgrade keine kompatible Lizenz für XenServer 8 erhalten, werden Ihre Hosts beim Upgrade auf die 90-Tage-Testversion zurückgesetzt. Die Testversion bietet die gleichen Funktionen wie die Premium Edition, jedoch mit einigen Einschränkungen. Weitere Informationen finden Sie unter Übersicht über die XenServer 8-Lizenzierung.

Sie können die Funktion Neues Speicher-Repository Assistent in XenCenter zum Erstellen von Speicher-Repositories (SRs). Der Assistent führt Sie durch die Konfigurationsschritte. Alternativ können Sie die CLI verwenden, und die sr-create Befehl. Das sr-create -Befehl erstellt eine SR auf dem Speichersubstrat (wobei möglicherweise vorhandene Daten zerstört werden). Außerdem werden das SR-API-Objekt und ein entsprechender PBD-Datensatz erstellt, sodass VMs den Speicher verwenden können. Nach erfolgreicher Erstellung der SR wird die PBD automatisch eingesteckt. Wenn der SR shared=wahr -Flag gesetzt ist, wird ein PBD-Datensatz für jeden Citrix Hypervisor im Ressourcenpool erstellt und angeschlossen.

Wenn Sie eine SR für IP-basierten Speicher (iSCSI oder NFS) erstellen, können Sie eine der folgenden Optionen als Speichernetzwerk konfigurieren: die Netzwerkkarte, die den Verwaltungsdatenverkehr verarbeitet, oder eine neue Netzwerkkarte für den Speicherdatenverkehr. Informationen zum Zuweisen einer IP-Adresse zu einer Netzwerkkarte finden Sie unter Konfigurieren einer dedizierten Speicher-NIC.

Alle Citrix Hypervisor SR-Typen unterstützen VDI-Größenänderung, schnelles Klonen und Snapshots. SRs, die auf dem LVM-SR-Typ (lokal, iSCSI oder HBA) basieren, bieten Thin Provisioning für Snapshots und versteckte übergeordnete Knoten. Die anderen SR-Typen (EXT3/EXT4, NFS, GFS2) unterstützen vollständiges Thin Provisioning, auch für aktive virtuelle Festplatten.

Warnungen:

  • Wenn VHD-VDIs nicht an eine VM angehängt sind, z. B. für einen VDI-Snapshot, werden sie standardmäßig als schlank bereitgestellt gespeichert. Wenn Sie versuchen, die VDI erneut anzufügen, stellen Sie sicher, dass genügend Speicherplatz für die Thick-Provisioning-Bereitstellung der VDI verfügbar ist. VDI-Klone werden dick bereitgestellt.

  • Citrix Hypervisor unterstützt keine Snapshots auf der externen SAN-Ebene einer LUN für einen SR-Typ.

  • Versuchen Sie nicht, eine SR zu erstellen, bei der die LUN-ID der Ziel-LUN größer als 255 ist. Stellen Sie sicher, dass Ihr Ziel die LUN mit einer LUN-ID kleiner oder gleich 255 bereitstellt, bevor Sie diese LUN zum Erstellen einer SR verwenden.

  • Wenn Sie Thin Provisioning auf einer dateibasierten SR verwenden, stellen Sie sicher, dass Sie den freien Speicherplatz auf Ihrer SR überwachen. Wenn die SR-Auslastung auf 100 % ansteigt, schlagen weitere Schreibvorgänge von VMs fehl. Diese fehlgeschlagenen Schreibvorgänge können dazu führen, dass die VM einfriert oder abstürzt.

Die maximal unterstützten VDI-Größen sind:

Format des Speicher-Repositorys Maximale VDI-Größe
EXT3/EXT4 2 TiB
GFS2 (mit iSCSI oder HBA) 16 TiB
LVM 2 TiB
LVMoFCOE (veraltet) 2 TiB
LVMoHBA 2 TiB
LVMoiSCSI 2 TiB
NFS 2 TiB
SMB 2 TiB

Lokale LVM

Der Typ Lokaler LVM stellt Festplatten innerhalb einer lokal angeschlossenen Datenträgergruppe dar.

Standardmäßig verwendet Citrix Hypervisor den lokalen Datenträger auf dem physischen Host, auf dem er installiert ist. Der Linux Logical Volume Manager (LVM) wird zur Verwaltung des VM-Speichers verwendet. Eine VDI wird im VHD-Format auf einem logischen LVM-Datenträger der angegebenen Größe implementiert.

Hinweis:

Die Blockgröße einer LVM-LUN muss 512 Byte betragen. Um Speicher mit nativen 4-KB-Blöcken zu verwenden, muss der Speicher auch die Emulation von 512-Byte-Zuordnungsblöcken unterstützen.

Überlegungen zur LVM-Leistung

Die Snapshot- und Fast-Clone-Funktionalität für LVM-basierte SRs ist mit einem inhärenten Performance-Overhead verbunden. Wenn eine optimale Leistung erforderlich ist, unterstützt Citrix Hypervisor die Erstellung von VDIs in der roh format zusätzlich zum standardmäßigen VHD-Format. Die Citrix Hypervisor-Snapshot-Funktionalität wird auf unformatierten VDIs nicht unterstützt.

Warnung:

Versuchen Sie nicht, einen Snapshot einer VM zu erstellen, die über typ=roh Angeschlossene Festplatten. Diese Aktion kann dazu führen, dass ein teilweiser Snapshot erstellt wird. In diesem Fall können Sie die verwaisten Snapshot-VDIs identifizieren, indem Sie das Kontrollkästchen Schnappschuss von und löschen Sie sie anschließend.

Erstellen einer lokalen LVM-SR

Eine LVM-SR wird standardmäßig bei der Hostinstallation erstellt.

Device-config-Parameter für LVM-SRs sind:

Parametername Beschreibung Erforderlich?
device Gerätename auf dem lokalen Host, der für die SR verwendet werden soll. Sie können auch eine durch Kommas getrennte Liste von Namen angeben. Ja

So erstellen Sie eine lokale LVM-SR auf /dev/sdbden folgenden Befehl.

      xe sr-create host-uuid=valid_uuid content-type=user \
      name-label="Example Local LVM SR" shared=false \
      device-config:device=/dev/sdb type=lvm
<!--NeedCopy-->

Lokale EXT3/EXT4

Die Verwendung von EXT3/EXT4 ermöglicht Thin Provisioning auf lokalem Speicher. Der Standard-Speicher-Repository-Typ ist jedoch LVM, da er eine konsistente Schreibleistung bietet und eine Überbelegung des Speichers verhindert. Wenn Sie EXT3/EXT4 verwenden, kann es in den folgenden Fällen zu Leistungseinbußen kommen:

  • Beim Ausführen von VM-Lebenszyklusvorgängen, wie z. B. Erstellen und Anhalten/Fortsetzen von VMs
  • Beim Erstellen großer Dateien innerhalb der VM

Lokale Festplatten-EXT3/EXT4-SRs müssen mit der Citrix Hypervisor CLI konfiguriert werden.

Ob eine lokale EXT-SR EXT3 oder EXT4 verwendet, hängt davon ab, welche Version von Citrix Hypervisor sie erstellt hat:

  • Wenn Sie die lokale EXT SR auf einer früheren Version von XenServer oder Citrix Hypervisor erstellt und dann auf Citrix Hypervisor 8.2 aktualisiert haben, wird EXT3 verwendet.
  • Wenn Sie die lokale EXT SR auf Citrix Hypervisor 8.2 erstellt haben, wird EXT4 verwendet.

Hinweis:

Die Blockgröße einer EXT3/EXT4-Festplatte muss 512 Byte betragen. Um Speicher mit nativen 4-KB-Blöcken zu verwenden, muss der Speicher auch die Emulation von 512-Byte-Zuordnungsblöcken unterstützen.

Beim Erstellen einer lokalen EXT4-SR (Extern)

Device-config-Parameter für EXT-SRs:

Parametername Beschreibung Erforderlich?
device Gerätename auf dem lokalen Host, der für die SR verwendet werden soll. Sie können auch eine durch Kommas getrennte Liste von Namen angeben. Ja

So erstellen Sie eine lokale EXT4-SR auf /dev/sdbden folgenden Befehl:

      xe sr-create host-uuid=valid_uuid content-type=user \
         name-label="Example Local EXT4 SR" shared=false \
         device-config:device=/dev/sdb type=ext
<!--NeedCopy-->

udev

Der Typ udev steht für Geräte, die mit dem udev-Geräte-Manager als VDIs angeschlossen wurden.

Citrix Hypervisor verfügt über zwei SRs vom Typ udev, die Wechseldatenträger darstellen. Eine ist für die CD oder DVD im physischen CD- oder DVD-ROM-Laufwerk des Citrix Hypervisor-Servers. Die andere ist für ein USB-Gerät, das an einen USB-Anschluss des Citrix Hypervisor-Servers angeschlossen ist. VDIs, die die Medien darstellen, kommen und gehen, wenn Festplatten oder USB-Sticks eingesteckt und entfernt werden.

ISO

Der ISO-Typ verarbeitet CD-Images, die als Dateien im ISO-Format gespeichert sind. Dieser SR-Typ ist nützlich für die Erstellung von gemeinsam genutzten ISO-Bibliotheken.

Die folgenden ISO SR-Typen sind verfügbar:

  • nfs_iso: Der NFS-ISO-SR-Typ verarbeitet CD-Images, die als Dateien im ISO-Format gespeichert sind und als NFS-Freigabe verfügbar sind.
  • CIFs: Der SR-Typ Windows File Sharing (SMB/CIFS) verarbeitet CD-Images, die als Dateien im ISO-Format gespeichert sind, die als Windows-Freigabe (SMB/CIFS) verfügbar sind.

Wenn Sie den Speichertyp, der für die SR verwendet werden soll, nicht angeben, verwendet Citrix Hypervisor die Ort device config-Parameter, um den Typ zu bestimmen.

Device-config-Parameter für ISO-SRs:

Parametername Beschreibung Erforderlich?
location Weg zum Reittier. Ja
type Zu verwendender Speichertyp für die SR: CIFs oder nfs_iso. Nein
nfsversion Gibt die zu verwendende NFS-Version an. Wenn Sie nfsversion="4"verwenden, verwendet die SR NFS v4.0, v4.1 oder v4.2, je nachdem, was verfügbar ist. Wenn Sie eine spezifischere Version von NFS auswählen möchten, können Sie nfsversion="4.0" Und so weiter. Es kann nur ein Wert angegeben werden für NFS-Version. Nein
vers Für den Speichertyp CIFS/SMB die zu verwendende SMB-Version: 1.0 oder 3.0. Der Standardwert ist 3.0. Nein
username Für den Speichertyp CIFS/SMB, wenn für den Windows-Dateiserver ein Benutzername erforderlich ist. Nein
cifspassword_secret (Empfohlen) Für den Speichertyp CIFS/SMB können Sie anstelle eines Kennworts ein Geheimnis für den Windows-Dateiserver übergeben. Nein
cifspassword Für den Speichertyp CIFS/SMB, wenn für den Windows-Dateiserver ein Kennwort erforderlich ist. Wir empfehlen Ihnen, die Option cifspassword_secret -Parameter. Nein

Hinweis:

Beim Ausführen der Funktion sr-create wird empfohlen, den Befehl Gerät-Konfiguration:cifspassword_secret -Argument verwenden, anstatt das Kennwort in der Befehlszeile anzugeben. Weitere Informationen finden Sie unter Geheimnisse.

Für Speicher-Repositories, die eine Bibliothek von ISOs speichern, wird die Inhaltstyp muss auf ISOZum Beispiel:

      xe sr-create host-uuid=valid_uuid content-type=iso  type=iso name-label="Example ISO SR" \
        device-config:location=<server:/path> device-config:type=nfs_iso
<!--NeedCopy-->

Sie können NFS oder SMB verwenden, um die ISO-SR zu mounten. Weitere Informationen zur Verwendung dieser SR-Typen finden Sie unter NFS und SMB.

Es wird empfohlen, SMB Version 3 zu verwenden, um ISO SR auf einem Windows-Dateiserver bereitzustellen. Version 3 ist standardmäßig ausgewählt, da sie sicherer und robuster ist als SMB-Version 1.0. Sie können ISO SR jedoch mit SMB Version 1 mit dem folgenden Befehl mounten:

       xe sr-create content-type=iso type=iso shared=true device-config:location=<\\IP\path>
       device-config:username=<username> device-config:cifspassword_secret=<password_secret> \
       device-config:type=cifs device-config:vers=1.0 name-label="Example ISO SR"
<!--NeedCopy-->

Software-iSCSI-Unterstützung

Citrix Hypervisor unterstützt freigegebene SRs auf iSCSI-LUNs. iSCSI wird mit dem iSCSI-Initiator der Open-iSCSI-Software oder mit einem unterstützten iSCSI-HBA (Host Bus Adapter) unterstützt. Die Schritte für die Verwendung von iSCSI-HBAs sind identisch mit den Schritten für Fibre-Channel-HBAs. Beide Schritte sind in Erstellen eines gemeinsam genutzten LVM über Fibre Channel/Fibre Channel über Ethernet/iSCSI HBA oder SAS SR.

Die gemeinsame iSCSI-Unterstützung mit der Software iSCSI-Initiator wird auf Basis des Linux Volume Manager (LVM) implementiert. Diese Funktion bietet die gleichen Leistungsvorteile, die LVM-VDIs im Fall der lokalen Festplatte bieten. Freigegebene iSCSI-SRs, die den softwarebasierten Host-Initiator verwenden, können die VM-Agilität mithilfe der Live-Migration unterstützen: VMs können auf jedem Citrix Hypervisor-Server in einem Ressourcenpool gestartet und ohne spürbare Ausfallzeiten zwischen ihnen migriert werden.

iSCSI-SRs verwenden die gesamte LUN, die zum Zeitpunkt der Erstellung angegeben wurde, und dürfen sich nicht über mehr als eine LUN erstrecken. CHAP-Unterstützung wird für die Client-Authentifizierung sowohl während der Initialisierungsphase des Datenpfads als auch während der LUN-Erkennungsphase bereitgestellt.

Hinweis:

Die Blockgröße einer iSCSI-LUN muss 512 Byte betragen. Um Speicher mit nativen 4-KB-Blöcken zu verwenden, muss der Speicher auch die Emulation von 512-Byte-Zuordnungsblöcken unterstützen.

iSCSI-Konfiguration des Citrix Hypervisor-Servers

Alle iSCSI-Initiatoren und -Ziele müssen einen eindeutigen Namen haben, um sicherzustellen, dass sie im Netzwerk eindeutig identifiziert werden können. Ein Initiator verfügt über eine iSCSI-Initiatoradresse, und ein Ziel über eine iSCSI-Zieladresse. Zusammen werden diese Namen als iSCSI Qualified Names (IQNs) bezeichnet.

Citrix Hypervisor-Server unterstützen einen einzelnen iSCSI-Initiator, der während der Hostinstallation automatisch mit einem zufälligen IQN erstellt und konfiguriert wird. Der einzelne Initiator kann verwendet werden, um gleichzeitig eine Verbindung mit mehreren iSCSI-Zielen herzustellen.

iSCSI-Ziele bieten in der Regel eine Zugriffssteuerung mithilfe von iSCSI-Initiator-IQN-Listen. Alle iSCSI-Ziele/LUNs, auf die Ihr Citrix Hypervisor-Server zugreift, müssen so konfiguriert werden, dass der Zugriff durch den Initiator-IQN des Hosts zulässig ist. Auf ähnliche Weise müssen Ziele/LUNs, die als gemeinsam genutzte iSCSI-SRs verwendet werden sollen, so konfiguriert werden, dass der Zugriff durch alle Host-IQNs im Ressourcenpool zulässig ist.

Hinweis:

iSCSI-Ziele, die keine Zugriffssteuerung bieten, beschränken den LUN-Zugriff in der Regel standardmäßig auf einen einzelnen Initiator, um die Datenintegrität zu gewährleisten. Wenn eine iSCSI-LUN als gemeinsam genutzte SR für mehrere Server in einem Pool verwendet wird, stellen Sie sicher, dass der Zugriff mit mehreren Initiatoren für die angegebene LUN aktiviert ist.

Der IQN-Wert des Citrix Hypervisor-Servers kann mit XenCenter oder über die CLI mit dem folgenden Befehl angepasst werden, wenn der iSCSI-Software-Initiator verwendet wird:

      xe host-param-set uuid=valid_host_id other-config:iscsi_iqn=new_initiator_iqn
<!--NeedCopy-->

Warnung:

  • Jedes iSCSI-Ziel und jeder Initiator muss über einen eindeutigen IQN verfügen. Wenn eine nicht eindeutige IQN-Kennung verwendet wird, kann es zu einer Datenbeschädigung oder zur Verweigerung des LUN-Zugriffs kommen.
  • Ändern Sie nicht den IQN des Citrix Hypervisor-Servers mit angehängten iSCSI-SRs. Dies kann dazu führen, dass beim Herstellen einer Verbindung mit neuen Zielen oder vorhandenen SRs Fehler auftreten.

Software-FCoE-Speicher (veraltet)

Software-FCoE bietet ein Standard-Framework, an das Hardware-Anbieter ihre FCoE-fähige Netzwerkkarte anschließen und die gleichen Vorteile wie ein hardwarebasiertes FCoE nutzen können. Durch diese Funktion entfallen teure HBAs.

Hinweis:

Software-FCoE ist veraltet und wird in einer zukünftigen Version entfernt.

Bevor Sie einen Software-FCoE-Speicher erstellen, schließen Sie die erforderliche Konfiguration manuell ab, um eine LUN für den Host verfügbar zu machen. Diese Konfiguration umfasst die Konfiguration der FCoE-Fabric und die Zuweisung von LUNs zum Public World Wide Name (PWWN) Ihres SAN. Nachdem Sie diese Konfiguration abgeschlossen haben, wird die verfügbare LUN als SCSI-Gerät auf dem CNA des Hosts bereitgestellt. Das SCSI-Gerät kann dann für den Zugriff auf die LUN verwendet werden, als wäre es ein lokal angeschlossenes SCSI-Gerät. Informationen zum Konfigurieren des physischen Switches und des Arrays für die Unterstützung von FCoE finden Sie in der vom Anbieter bereitgestellten Dokumentation.

Hinweis:

Software-FCoE kann mit Open vSwitch und Linux Bridge als Netzwerk-Backend verwendet werden.

Erstellen einer Software-FCoE-SR

Vor dem Erstellen einer Software-FCoE-SR müssen Kunden sicherstellen, dass FCoE-fähige Netzwerkkarten an den Host angefügt sind.

Device-config-Parameter für FCoE-SRs sind:

Parametername Beschreibung Erforderlich?
SCSIid Die SCSI-Bus-ID der Ziel-LUN Ja

Führen Sie den folgenden Befehl aus, um einen freigegebenen FCoE-SR zu erstellen:

      xe sr-create type=lvmofcoe \
      name-label="FCoE SR" shared=true device-config:SCSIid=SCSI_id
<!--NeedCopy-->

Hardware-Host-Bus-Adapter (HBAs)

In diesem Abschnitt werden verschiedene Vorgänge behandelt, die zum Verwalten von SAS-, Fibre Channel- und iSCSI-HBAs erforderlich sind.

Beispiel für eine QLogic iSCSI-HBA-Einrichtung

Weitere Informationen zur Konfiguration von QLogic Fibre Channel und iSCSI-HBAs finden Sie in der Cavium Website.

Nachdem der HBA physisch auf dem Citrix Hypervisor-Server installiert wurde, führen Sie die folgenden Schritte aus, um den HBA zu konfigurieren:

  1. Legen Sie die IP-Netzwerkkonfiguration für den HBA fest. In diesem Beispiel wird von DHCP und HBA-Port 0 ausgegangen. Geben Sie die entsprechenden Werte an, wenn Sie eine statische IP-Adressierung oder einen HBA mit mehreren Ports verwenden.

      /opt/QLogic_Corporation/SANsurferiCLI/iscli -ipdhcp 0
    <!--NeedCopy-->
    
  2. Fügen Sie Port 0 des HBA ein persistentes iSCSI-Ziel hinzu.

      /opt/QLogic_Corporation/SANsurferiCLI/iscli -pa 0 iscsi_target_ip_address
    <!--NeedCopy-->
    
  3. Verwenden Sie die xe SR-Sonde , um einen erneuten Scan des HBA-Controllers zu erzwingen und die verfügbaren LUNs anzuzeigen. Weitere Informationen finden Sie unter Sondieren eines SR und Erstellen eines gemeinsam genutzten LVM über Fibre Channel/Fibre Channel über Ethernet/iSCSI HBA oder SAS SR.

Entfernen von HBA-basierten SAS-, FC- oder iSCSI-Geräteeinträgen

Hinweis:

Dieser Schritt ist nicht erforderlich. Es wird empfohlen, diesen Vorgang nur bei Bedarf nur von Power-Usern durchzuführen.

Jede HBA-basierte LUN verfügt über einen entsprechenden Eintrag für den globalen Gerätepfad unter /dev/disk/by-scsibus im Format &lt;SCSIid&gt;-&lt;adapter&gt;:&lt;bus&gt;:&lt;target&gt;:&lt;lun&gt; und einen Standardgerätepfad unter /Dev. Gehen Sie folgendermaßen vor, um die Einheiteneinträge für LUNs zu entfernen, die nicht mehr als SRs verwendet werden:

  1. Gebrauchen sr-vergessen oder sr-zerstören Gegebenenfalls um die SR aus der Citrix Hypervisor-Serverdatenbank zu entfernen. Siehe Entfernen von SRs für Details.

  2. Entfernen Sie die Zoning-Konfiguration innerhalb des SAN für die gewünschte LUN auf dem gewünschten Server.

  3. Verwenden Sie die Schaltfläche SR-Sonde , um die ADAPTER-, BUS-, TARGET- und LUN-Werte zu bestimmen, die der zu entfernenden LUN entsprechen. Weitere Informationen finden Sie unter Sondieren eines SR.

  4. Entfernen Sie die Geräteeinträge mit folgendem Befehl:

      echo "1" > /sys/class/scsi_device/adapter:bus:target:lun/device/delete
    <!--NeedCopy-->
    

Warnung:

Stellen Sie sicher, dass Sie sicher sind, welche LUN Sie entfernen. Wenn Sie versehentlich eine LUN entfernen, die für den Hostbetrieb erforderlich ist, z. B. das Boot- oder Root-Gerät, wird der Host unbrauchbar.

Gemeinsamer LVM-Speicher

Der freigegebene LVM-Typ stellt Festplatten als logische Volumes innerhalb einer Volume-Gruppe dar, die auf einer iSCSI-LUN (FC oder SAS) erstellt wurde.

Hinweis:

Die Blockgröße einer iSCSI-LUN muss 512 Byte betragen. Um Speicher mit nativen 4-KB-Blöcken zu verwenden, muss der Speicher auch die Emulation von 512-Byte-Zuordnungsblöcken unterstützen.

Erstellen eines gemeinsam genutzten LVM über iSCSI SR mithilfe des Software iSCSI-Initiators

Device-config-Parameter für LVMoiSCSI-SRs:

Parametername Beschreibung Erforderlich?
target Die IP-Adresse oder der Hostname des iSCSI-Ziels auf dem SAN, das die SR hostet. Dabei kann es sich auch um eine durch Kommas getrennte Liste von Werten handeln, um eine Verbindung zu mehreren Zielen herzustellen. Ja
targetIQN Der iSCSI Qualified Name (IQN) des Ziels auf dem iSCSI-SAN, das die SR hostet, oder * , um eine Verbindung zu allen IQNs herzustellen. Ja
SCSIid Die SCSI-Bus-ID der Ziel-LUN Ja
multihomed Aktivieren von Multi-Homing für dieses Ziel Nein (standardmäßig derselbe Wert wie host.other_config:Multipathing)
chapuser Der Benutzername, der für die CHAP-Authentifizierung verwendet werden soll Nein
chappassword_secret (Empfohlen) Geheime ID für das Kennwort, das für die CHAP-Authentifizierung verwendet werden soll. Übergeben Sie ein Geheimnis anstelle eines Kennworts. Nein
chappassword Das Kennwort, das für die CHAP-Authentifizierung verwendet werden soll. Wir empfehlen Ihnen, die Option chappassword_secret -Parameter. Nein
port Die Netzwerkportnummer, über die das Ziel abgefragt werden soll Nein
usediscoverynumber Der spezifische iSCSI-Eintragsindex, der verwendet werden soll Nein
incoming_chapuser Der Benutzername, den der iSCSI-Filter für die Authentifizierung beim Host verwendet Nein
incoming_chappassword_secret (Empfohlen) Geheime ID für das Kennwort, das der iSCSI-Filter zur Authentifizierung beim Host verwendet. Nein
incoming_chappassword Das Kennwort, das der iSCSI-Filter zur Authentifizierung beim Host verwendet. Wir empfehlen Ihnen, die Option incoming_chappassword_secret -Parameter. Nein

Hinweis:

Beim Ausführen der Funktion sr-create wird empfohlen, den Befehl Gerät-Konfiguration:chappassword_secret -Argument verwenden, anstatt das Kennwort in der Befehlszeile anzugeben. Weitere Informationen finden Sie unter Geheimnisse.

Verwenden Sie den folgenden Befehl, um eine gemeinsam genutzte LVMoiSCSI-SR auf einer bestimmten LUN eines iSCSI-Ziels zu erstellen.

      xe sr-create host-uuid=valid_uuid content-type=user \
      name-label="Example shared LVM over iSCSI SR" shared=true \
      device-config:target=target_ip= device-config:targetIQN=target_iqn= \
      device-config:SCSIid=scsci_id \
      type=lvmoiscsi
<!--NeedCopy-->

Erstellen eines gemeinsam genutzten LVM über Fibre Channel/Fibre Channel über Ethernet/iSCSI HBA oder SAS SR

SRs vom Typ LVMoHBA können mit der xe CLI oder XenCenter erstellt und verwaltet werden.

Device-config-Parameter für LVMoHBA-SRs:

Name des Parameters Beschreibung Erforderlich?
SCSIid SCSI-ID des Geräts Ja

Um eine gemeinsam genutzte LVMoHBA-SR zu erstellen, führen Sie die folgenden Schritte auf jedem Host im Pool aus:

  1. Zonieren Sie eine oder mehrere LUNs zu jedem Citrix Hypervisor-Server im Pool. Dieser Prozess ist sehr spezifisch für die verwendeten SAN-Geräte. Weitere Informationen finden Sie in der SAN-Dokumentation.

  2. Verwenden Sie bei Bedarf die HBA-CLI, die im Citrix Hypervisor-Server enthalten ist, um den HBA zu konfigurieren:

    • Emulex: /bin/sbin/ocmanager

    • QLogic FC: /opt/QLogic_Corporation/SANsurferCLI

    • QLogic iSCSI: /opt/QLogic_Corporation/SANsurferiCLI

    Ein Beispiel für eine QLogic iSCSI-HBA-Konfiguration finden Sie unter Hardware-Host-Bus-Adapter (HBAs) im vorherigen Abschnitt. Weitere Informationen zu Fibre Channel- und iSCSI-HBAs finden Sie in der Broadcom (Englisch) und Cavium Websites.

  3. Verwenden Sie die Schaltfläche SR-Sonde , um den globalen Einheitenpfad der HBA-LUN zu ermitteln. Das SR-Sonde Der Befehl erzwingt einen erneuten Scan der im System installierten HBAs, um alle neuen LUNs zu erkennen, die dem Host zugewiesen wurden. Der Befehl gibt eine Liste der Eigenschaften für jede gefundene LUN zurück. Geben Sie die Option host-uuid , um sicherzustellen, dass der Test auf dem gewünschten Host ausgeführt wird.

    Der globale Gerätepfad, der als &lt;path&gt; Die Eigenschaft ist für alle Hosts im Pool gleich. Daher muss dieser Pfad als Wert für die Gerät-Konfiguration:Gerät beim Erstellen der SR.

    Wenn mehrere LUNs vorhanden sind, verwenden Sie den Hersteller, die LUN-Größe, die LUN-Seriennummer oder die SCSI-ID aus dem &lt;path&gt; -Eigenschaft, um die gewünschte LUN zu identifizieren.

          xe sr-probe type=lvmohba \
          host-uuid=1212c7b3-f333-4a8d-a6fb-80c5b79b5b31
          Error code: SR_BACKEND_FAILURE_90
          Error parameters: , The request is missing the device parameter, \
          <?xml version="1.0" ?>
          <Devlist>
              <BlockDevice>
                  <path>
                      /dev/disk/by-id/scsi-360a9800068666949673446387665336f
                  </path>
                  <vendor>
                      HITACHI
                  </vendor>
                  <serial>
                      730157980002
                  </serial>
                  <size>
                      80530636800
                  </size>
                  <adapter>
                      4
                  </adapter>
                  <channel>
                      0
                  </channel>
                  <id>
                      4
                  </id>
                  <lun>
                      2
                  </lun>
                  <hba>
                      qla2xxx
                  </hba>
              </BlockDevice>
              <Adapter>
                  <host>
                      Host4
                  </host>
                  <name>
                      qla2xxx
                  </name>
                  <manufacturer>
                      QLogic HBA Driver
                  </manufacturer>
                  <id>
                      4
                  </id>
              </Adapter>
          </Devlist>
    <!--NeedCopy-->
    
  4. Erstellen Sie auf dem Masterhost des Pools die SR. Geben Sie den globalen Gerätepfad an, der in der &lt;path&gt; Immobilien ab SR-Sonde. PBDs werden automatisch für jeden Host im Pool erstellt und angeschlossen.

          xe sr-create host-uuid=valid_uuid \
          content-type=user \
          name-label="Example shared LVM over HBA SR" shared=true \
          device-config:SCSIid=device_scsi_id type=lvmohba
    <!--NeedCopy-->
    

Hinweis:

Sie können die XenCenter Repair Storage Repository-Funktion verwenden, um die PBD-Erstellung und das Anschließen von Teilen der sr-create Operation. Diese Funktion kann in Fällen nützlich sein, in denen das LUN-Zoning für einen oder mehrere Hosts in einem Pool falsch war, als die SR erstellt wurde. Korrigieren Sie das Zoning für die betroffenen Hosts, und verwenden Sie die Funktion “Storage Repository reparieren”, anstatt die SR zu entfernen und neu zu erstellen.

Thin Provisioned Shared GFS2-Blockspeicher

Beim Thin Provisioning wird der verfügbare Speicher besser genutzt, indem VDIs Datenträgerspeicherplatz zugewiesen wird, während die Daten auf das virtuelle Laufwerk geschrieben werden, anstatt die volle virtuelle Größe des VDI im Voraus zuzuweisen. Thin Provisioning ermöglicht es Ihnen, den auf einem gemeinsam genutzten Speicher-Array benötigten Speicherplatz und damit Ihre Gesamtbetriebskosten (TCO) erheblich zu reduzieren.

Thin Provisioning für gemeinsam genutzten Blockspeicher ist in den folgenden Fällen von besonderem Interesse:

  • Sie möchten eine höhere Raumeffizienz. Images werden spärlich und nicht dicht verteilt.
  • Sie möchten die Anzahl der I/O-Vorgänge pro Sekunde auf Ihrem Speicher-Array reduzieren. GFS2-SR ist der erste SR-Typ, der das Speicherlesecaching auf gemeinsam genutztem Blockspeicher unterstützt.
  • Sie verwenden ein allgemeines Basisimage für mehrere virtuelle Maschinen. Die Images einzelner VMs benötigen dann in der Regel noch weniger Speicherplatz.
  • Sie verwenden Schnappschüsse. Jeder Snapshot ist ein Image und jedes Image ist jetzt spärlich.
  • Ihr Speicher unterstützt kein NFS und unterstützt nur Blockspeicher. Wenn Ihr Speicher NFS unterstützt, empfehlen wir Ihnen, NFS anstelle von GFS2 zu verwenden.
  • Sie möchten VDIs erstellen, die größer als 2 TiB sind. Der GFS2 SR unterstützt VDIs mit einer Größe von bis zu 16 TiB.

Hinweis:

Wir empfehlen, GFS2 SR nicht mit einem VLAN zu verwenden, da ein bekanntes Problem besteht, bei dem Sie Hosts in einem Clusterpool nicht hinzufügen oder entfernen können, wenn sich das Clusternetzwerk in einem Nicht-Management-VLAN befindet.

Der gemeinsam genutzte GFS2-Typ stellt Datenträger als Dateisystem dar, das auf einer iSCSI- oder HBA-LUN erstellt wurde. Auf einem GFS2 SR gespeicherte VDIs werden im QCOW2-Imageformat gespeichert.

Um gemeinsam genutzten GFS2-Speicher verwenden zu können, muss es sich bei dem Citrix Hypervisor-Ressourcenpool um einen Clusterpool handeln. Aktivieren Sie das Clustering in Ihrem Pool, bevor Sie eine GFS2-SR erstellen. Weitere Informationen finden Sie unter Clustered Pools.

Stellen Sie sicher, dass Storage Multipathing zwischen Ihrem Cluster-Pool und Ihrer GFS2 SR eingerichtet ist. Weitere Informationen finden Sie unter Multipathing für Speicher.

SRs vom Typ GFS2 können mit der xe CLI oder XenCenter erstellt und verwaltet werden.

Erstellen einer freigegebenen GFS2-SR

Sie können Ihre gemeinsam genutzte GFS2-SR auf einer iSCSI- oder HBA-LUN erstellen.

Erstellen eines freigegebenen GFS2 über iSCSI SR

Sie können GFS2 über iSCSI-SRs mit XenCenter erstellen. Weitere Informationen finden Sie unter Software-iSCSI-Speicher in der XenCenter-Produktdokumentation .

Alternativ können Sie die xe CLI verwenden, um ein GFS2 über iSCSI SR zu erstellen.

Gerätekonfigurationsparameter für GFS2-SRs:

Parametername Beschreibung Erforderlich?
provider Die Blockanbieter-Implementierung. In diesem Fall, iscsi. Ja
target Die IP-Adresse oder der Hostname des iSCSI-Filers, der hostet Ja
targetIQN Das IQN-Ziel des iSCSI-Filers, der das SR hostet Ja
SCSIid SCSI-ID des Geräts Ja

Sie können die für diese Parameter zu verwendenden Werte mit dem Befehl xe sr-probe-ext finden.

xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
  1. Führen Sie zunächst den folgenden Befehl aus:

    xe sr-probe-ext type=gfs2 device-config:provider=iscsi
    

    Die Ausgabe des Befehls fordert Sie auf, zusätzliche Parameter anzugeben, und enthält bei jedem Schritt eine Liste möglicher Werte.

  2. Wiederholen Sie den Befehl und fügen Sie jedes Mal neue Parameter hinzu.

  3. Wenn die Befehlsausgabe mit beginnt Found the following complete configurations that can be used to create SRs:, können Sie den SR mithilfe des xe sr-create Befehls und der von Ihnen angegebenen device-config Parameter suchen.

    Beispiel für eine Ausgabe:

    ```Es wurden die folgenden vollständigen Konfigurationen gefunden, die zur Erstellung von SRs verwendet werden können: Konfiguration 0: scsiID: 36001405852f77532a064687aea8a5b3f TargetIQN: iqn.2009-01.example.com:iscsi192a25d6 Ziel : 198.51.100.27 Anbieter: iscsi

    Configuration 0 extra information:

    ```

Um ein gemeinsam genutztes GFS2-SR auf einer bestimmten LUN eines iSCSI-Ziels zu erstellen, führen Sie den folgenden Befehl auf einem Server in Ihrem Clusterpool aus:

xe sr-create type=gfs2 name-label="Example GFS2 SR" --shared \
   device-config:provider=iscsi device-config:targetIQN=target_iqns \
   device-config:target=portal_address device-config:SCSIid=scsci_id

Wenn das iSCSI-Ziel nicht erreichbar ist, während GFS2-Dateisysteme eingehängt sind, können einige Hosts im Clusterpool einen Fence durchführen.

Weitere Informationen zum Arbeiten mit iSCSI SRs finden Sie unter Software-iSCSI-Unterstützung.

Erstellen eines freigegebenen GFS2 über HBA SR

Sie können GFS2 über HBA-SRs erstellen, indem Sie XenCenter verwenden. Weitere Informationen finden Sie unter Hardware-HBA-Speicher in der XenCenter-Produktdokumentation.

Alternativ können Sie die xe CLI verwenden, um ein GFS2 über HBA SR zu erstellen.

Gerätekonfigurationsparameter für GFS2-SRs:

Parametername Beschreibung Erforderlich?
provider Die Blockanbieter-Implementierung. In diesem Fall, hba. Ja
SCSIid SCSI-ID des Geräts Ja

Sie können die für den SCSIid-Parameter zu verwendenden Werte mit dem Befehl xe sr-probe-ext finden.

xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
  1. Führen Sie zunächst den folgenden Befehl aus:

    xe sr-probe-ext type=gfs2 device-config:provider=hba
    

    Die Ausgabe des Befehls fordert Sie auf, zusätzliche Parameter anzugeben, und enthält bei jedem Schritt eine Liste möglicher Werte.

  2. Wiederholen Sie den Befehl und fügen Sie jedes Mal neue Parameter hinzu.

  3. Wenn die Befehlsausgabe mit beginnt Found the following complete configurations that can be used to create SRs:, können Sie den SR mithilfe des xe sr-create Befehls und der von Ihnen angegebenen device-config Parameter suchen.

    Beispiel für eine Ausgabe:

    ```Es wurden die folgenden vollständigen Konfigurationen gefunden, die zur Erstellung von SRs verwendet werden können: Konfiguration 0: scsiID: 36001405852f77532a064687aea8a5b3f TargetIQN: iqn.2009-01.example.com:iscsi192a25d6 Ziel : 198.51.100.27 Anbieter: iscsi

    Configuration 0 extra information:

    ```

Um ein gemeinsam genutztes GFS2-SR auf einer bestimmten LUN eines HBA-Ziels zu erstellen, führen Sie den folgenden Befehl auf einem Server in Ihrem Clusterpool aus:

xe sr-create type=gfs2 name-label="Example GFS2 SR" --shared \
  device-config:provider=hba device-config:SCSIid=device_scsi_id

Weitere Informationen zum Arbeiten mit HBA-SRs finden Sie unter Hardware-Hostbusadapter.

Einschränkungen

Gemeinsam genutzter GFS2-Speicher weist derzeit die folgenden Einschränkungen auf:

  • Wie bei jeder Thin-Provisioning-SR schlagen weitere Schreibvorgänge von VMs fehl, wenn die GFS2 SR-Nutzung auf 100% ansteigt. Diese fehlgeschlagenen Schreibvorgänge können dann zu Fehlern innerhalb der VM oder zu einer möglichen Datenbeschädigung oder beidem führen.

  • XenCenter zeigt eine Warnung an, wenn Ihre SR-Auslastung auf 80% ansteigt. Stellen Sie sicher, dass Sie Ihren GFS2 SR auf diese Warnung überwachen und gegebenenfalls die entsprechenden Maßnahmen ergreifen. Bei einem GFS2 SR führt eine hohe Auslastung zu einer Leistungsverschlechterung. Wir empfehlen, dass Sie Ihre SR-Nutzung unter 80% halten.

  • VM-Migration mit Speichermigration (live oder offline) wird für VMs, deren VDIs sich auf einem GFS2-SR befinden, nicht unterstützt. Sie können auch keine VDIs von einem anderen SR-Typ auf eine GFS2 SR migrieren.

  • Der FCoE-Transport wird mit GFS2-SRs nicht unterstützt.

  • Trim/Unmap wird auf GFS2 SRs nicht unterstützt.

  • CHAP wird auf GFS2 SRs nicht unterstützt.

  • MCS-Vollklon-VMs werden mit GFS2 SRs nicht unterstützt.

  • Die Verwendung mehrerer GFS2 SRs im selben MCS-Katalog wird nicht unterstützt.

  • Leistungsmetriken sind für GFS2 SRs und Datenträger auf diesen SRs nicht verfügbar.

  • Die geänderte Blockverfolgung wird für VDIs, die auf GFS2 SRs gespeichert sind, nicht unterstützt.

  • Sie können VDIs, die größer als 2 TiB sind, nicht als VHD oder OVA/OVF exportieren. Sie können jedoch VMs mit VDIs, die größer als 2 TiB sind, im XVA-Format exportieren.

  • Wir empfehlen nicht, eine Thin Provisioning-LUN mit GFS2 zu verwenden. Wenn Sie diese Konfiguration wählen, müssen Sie jedoch sicherstellen, dass die LUN immer über genügend Speicherplatz verfügt, damit Citrix Hypervisor darauf schreiben kann.

  • Sie können nicht mehr als 62 GFS2 SRs in Ihrem Pool haben.

  • Clusterpools unterstützen nur bis zu 16 Hosts pro Pool.
  • Um HA in einem Clusterpool zu aktivieren, muss der Heartbeat-SR ein GFS2-SR sein.
  • Für den Cluster-Verkehr müssen Sie ein gebundenes Netzwerk verwenden, das mindestens zwei verschiedene Netzwerk-Switches verwendet. Verwenden Sie dieses Netzwerk nicht für andere Zwecke.
  • Um die IP-Adresse des Cluster-Netzwerks mithilfe von XenCenter zu ändern, müssen Clustering und GFS2 vorübergehend deaktiviert werden.
  • Ändern Sie nicht die Bindung Ihres Clusternetzwerks, während der Cluster aktiv ist und über laufende VMs verfügt. Diese Aktion kann zum Fence des Clusters führen.
  • Wenn Sie in Ihrem Clusternetzwerk einen IP-Adresskonflikt (mehrere Hosts mit derselben IP-Adresse) haben, an dem mindestens ein Host mit aktiviertem Clustering beteiligt ist, werden die Hosts nicht eingezäunt. Um dieses Problem zu beheben, lösen Sie den IP-Adresskonflikt.

NFS und SMB

Freigaben auf NFS-Servern (die eine beliebige Version von NFSv4 oder NFSv3 unterstützen) oder auf SMB-Servern (die SMB 3 unterstützen) können sofort als SR für virtuelle Datenträger verwendet werden. VDIs werden nur im Microsoft VHD-Format gespeichert. Da diese SRs gemeinsam genutzt werden können, ermöglichen VDIs, die auf gemeinsam genutzten SRs gespeichert sind, Folgendes:

  • VMs, die auf beliebigen Citrix Hypervisor-Servern in einem Ressourcenpool gestartet werden sollen

  • VM-Migration zwischen Citrix Hypervisor-Servern in einem Ressourcenpool mithilfe der Live-Migration (ohne spürbare Ausfallzeiten)

Wichtig:

  • Die Unterstützung für SMB3 beschränkt sich auf die Möglichkeit, über das Protokoll 3 eine Verbindung zu einer Freigabe herzustellen. Zusätzliche Funktionen wie Transparent Failover hängen von der Verfügbarkeit von Funktionen im Upstream-Linux-Kernel ab und werden in Citrix Hypervisor 8.2 nicht unterstützt.
  • Clustered SMB wird mit Citrix Hypervisor nicht unterstützt.
  • Für NFSv4 nur der Authentifizierungstyp AUTH_SYS wird unterstützt.
  • SMB-Speicher ist für Citrix Hypervisor Premium Edition-Kunden oder Kunden verfügbar, die über ihre Citrix Virtual Apps and Desktops-Berechtigung oder Citrix DaaS-Berechtigung Zugriff auf Citrix Hypervisor haben.
  • Sowohl für NFS- als auch für SMB-Speicher wird dringend empfohlen, ein dediziertes Speichernetzwerk mit mindestens zwei gebundenen Verbindungen zu verwenden, idealerweise zu unabhängigen Netzwerk-Switches mit redundanten Netzteilen.
  • Wenn Sie SMB-Speicher verwenden, entfernen Sie die Freigabe nicht aus dem Speicher, bevor Sie den SMB-SR trennen.

VDIs, die auf dateibasierten SRs gespeichert sind, sind Dünn provisioniert. Die Imagedatei wird zugeordnet, wenn die VM Daten auf den Datenträger schreibt. Dieser Ansatz hat den erheblichen Vorteil, dass die VM-Imagedateien nur so viel Speicherplatz auf dem Speicher beanspruchen, wie benötigt wird. Wenn z. B. einer VM ein VDI mit 100 GB zugewiesen und ein Betriebssystem installiert ist, spiegelt die VDI-Datei nur die Größe der Betriebssystemdaten wider, die auf den Datenträger geschrieben wurden, und nicht die gesamten 100 GB.

VHD-Dateien können auch verkettet werden, sodass zwei VDIs gemeinsame Daten gemeinsam nutzen können. In Fällen, in denen eine dateibasierte VM geklont wird, teilen sich die resultierenden VMs die gemeinsamen Daten auf dem Datenträger zum Zeitpunkt des Klonens. Jede VM nimmt ihre eigenen Änderungen in einer isolierten Copy-on-Write-Version der VDI vor. Mit dieser Funktion können dateibasierte VMs schnell aus Vorlagen geklont werden, was eine sehr schnelle Bereitstellung und Bereitstellung neuer VMs ermöglicht.

Hinweis:

Die maximal unterstützte Länge von VHD-Ketten beträgt 30.

Dateibasierte SRs und VHD-Implementierungen in Citrix Hypervisor gehen davon aus, dass sie die volle Kontrolle über das SR-Verzeichnis auf dem Dateiserver haben. Administratoren dürfen den Inhalt des SR-Verzeichnisses nicht ändern, da diese Aktion die Gefahr birgt, dass der Inhalt von VDIs beschädigt wird.

Citrix Hypervisor wurde für Speicher der Enterprise-Klasse optimiert, der nichtflüchtigen RAM verwendet, um schnelle Bestätigungen von Schreibanforderungen bereitzustellen und gleichzeitig ein hohes Maß an Datenschutz vor Ausfällen zu gewährleisten. Citrix Hypervisor wurde mit Data OnTap 7.3 und 8.1 ausgiebig gegen Network Appliance FAS2020 und FAS3210 Storage getestet

Warnung:

Da VDIs auf dateibasierten SRs als Thin Provisioning erstellt werden, müssen Administratoren sicherstellen, dass die dateibasierten SRs über genügend Speicherplatz für alle erforderlichen VDIs verfügen. Citrix Hypervisor-Server erzwingen nicht, dass der für VDIs auf dateibasierten SRs erforderliche Speicherplatz vorhanden ist.

Stellen Sie sicher, dass Sie den freien Speicherplatz auf Ihrer SR überwachen. Wenn die SR-Auslastung auf 100 % ansteigt, schlagen weitere Schreibvorgänge von VMs fehl. Diese fehlgeschlagenen Schreibvorgänge können dazu führen, dass die VM einfriert oder abstürzt.

Erstellen eines freigegebenen NFS SR (NFS)

Hinweis:

Wenn Sie versuchen, eine schreibgeschützte NFS-SR anzuhängen, schlägt diese Aktion mit der folgenden Fehlermeldung fehl: “SR_BACKEND_FAILURE_461 - Das Dateisystem für SR kann nicht geschrieben werden.”

Um eine NFS-SR zu erstellen, müssen Sie den Hostnamen oder die IP-Adresse des NFS-Servers angeben. Sie können die SR auf einem beliebigen gültigen Zielpfad erstellen. Verwenden Sie die Schaltfläche SR-Sonde , um eine Liste der gültigen Zielpfade anzuzeigen, die vom Server exportiert wurden.

In Szenarien, in denen Citrix Hypervisor mit Low-End-Speicher verwendet wird, wartet es vorsichtig, bis alle Schreibvorgänge bestätigt wurden, bevor Bestätigungen an VMs übergeben werden. Dieser Ansatz führt zu erheblichen Leistungseinbußen und kann möglicherweise gelöst werden, indem der Speicher so festgelegt wird, dass der SR-Bereitstellungspunkt als Export im asynchronen Modus angezeigt wird. Asynchrone Exporte bestätigen Schreibvorgänge, die sich nicht tatsächlich auf dem Datenträger befinden. Wägen Sie die Risiken eines Scheiterns in diesen Situationen sorgfältig ab.

Hinweis:

Der NFS-Server muss so konfiguriert werden, dass der angegebene Pfad an alle Server im Pool exportiert wird. Wird diese Konfiguration nicht vorgenommen, schlägt das Anlegen der SR und das Einstecken des PBD-Eintrags fehl.

Die Citrix Hypervisor NFS-Implementierung verwendet standardmäßig TCP. Wenn Ihre Situation dies zulässt, können Sie die Implementierung so konfigurieren, dass UDP in Szenarien verwendet wird, in denen möglicherweise ein Leistungsvorteil besteht. Um diese Konfiguration vorzunehmen, geben Sie beim Erstellen einer SR die Option Gerät-Konfiguration Parameter useUDP=wahr.

Folgendes Gerät-Konfiguration Parameter werden mit NFS-SRs verwendet:

Parametername Beschreibung Erforderlich?
server IP-Adresse oder Hostname des NFS-Servers Ja
serverpath Pfad, einschließlich des NFS-Bereitstellungspunkts, zum NFS-Server, der die SR hostet Ja
nfsversion Gibt die zu verwendende NFS-Version an. Wenn Sie nfsversion="4"verwenden, verwendet die SR NFS v4.0, v4.1 oder v4.2, je nachdem, was verfügbar ist. Wenn Sie eine spezifischere Version von NFS auswählen möchten, können Sie nfsversion="4.0" Und so weiter. Es kann nur ein Wert angegeben werden für NFS-Version. Nein
useUDP Konfigurieren Sie die SR so, dass UDP anstelle des Standard-TCP verwendet wird. Nein

So erstellen Sie beispielsweise eine gemeinsam genutzte NFS-SR auf 192.168.1.10:/exportieren1Verwenden Sie unter Verwendung einer beliebigen Version 4 von NFS, die von der Datei zur Verfügung gestellt wird, den folgenden Befehl:

      xe sr-create content-type=user \
      name-label="shared NFS SR" shared=true \
      device-config:server=192.168.1.10 device-config:serverpath=/export1 type=nfs \
      device-config:nfsversion="4"
<!--NeedCopy-->

So erstellen Sie eine nicht gemeinsam genutzte NFS-SR auf 192.168.1.10:/exportieren1, speziell unter Verwendung der NFS-Version 4.0, den folgenden Befehl aus:

      xe sr-create host-uuid=host_uuid content-type=user \
      name-label="Non-shared NFS SR" \
      device-config:server=192.168.1.10 device-config:serverpath=/export1 type=nfs \
      device-config:nfsversion="4.0"
<!--NeedCopy-->

Erstellen eines freigegebenen SMB SR (SMB)

Um eine SMB-SR zu erstellen, geben Sie den Hostnamen oder die IP-Adresse des SMB-Servers, den vollständigen Pfad der exportierten Freigabe und die entsprechenden Anmeldeinformationen an.

Device-config-Parameter für SMB-SRs:

Parametername Beschreibung Erforderlich?
server Vollständiger Pfad zur Freigabe auf dem Server Ja
username Benutzerkonto mit RW-Zugang zum Teilen Optional
password_secret (Empfohlen) Geheime ID für das Passwort für das Benutzerkonto, die anstelle des Passworts verwendet werden kann. Optional
password Passwort für das Benutzerkonto. Wir empfehlen Ihnen, die Funktion password_secret -Parameter. Optional

Hinweis:

Beim Ausführen der Funktion sr-create wird empfohlen, den Befehl Gerät-Konfiguration:password_secret -Argument verwenden, anstatt das Kennwort in der Befehlszeile anzugeben. Weitere Informationen finden Sie unter Geheimnisse.

So erstellen Sie beispielsweise eine freigegebene SMB-SR auf 192.168.1.10:/Aktie1den folgenden Befehl:

      xe sr-create content-type=user \
      name-label="Example shared SMB SR" shared=true \
      device-config:server=//192.168.1.10/share1 \
      device-config:username=valid_username device-config:password_secret=valid_password_secret type=smb
<!--NeedCopy-->

Führen Sie den folgenden Befehl aus, um eine nicht freigegebene SMB-SR zu erstellen:

      xe sr-create host-uuid=host_uuid content-type=user \
      name-label="Non-shared SMB SR" \
      device-config:server=//192.168.1.10/share1 \
      device-config:username=valid_username device-config:password_secret=valid_password_secret type=smb
<!--NeedCopy-->

LVM über Hardware-HBA

Der HBA-Typ LVM über Hardware stellt Festplatten als VHDs auf logischen Datenträgern innerhalb einer Datenträgergruppe dar, die auf einer HBA-LUN erstellt wurde, die z. B. hardwarebasierte iSCSI- oder FC-Unterstützung bietet.

Citrix Hypervisor-Server unterstützen Fibre Channel-SANs über Emulex- oder QLogic-Hostbusadapter (HBAs). Alle Fibre-Channel-Konfigurationen, die erforderlich sind, um eine Fibre Channel-LUN für den Host verfügbar zu machen, müssen manuell abgeschlossen werden. Diese Konfiguration umfasst Speichergeräte, Netzwerkgeräte und den HBA innerhalb des Citrix Hypervisor-Servers. Nachdem die FC-Konfiguration abgeschlossen ist, stellt der HBA dem Host ein SCSI-Gerät zur Verfügung, das von der FC-LUN unterstützt wird. Das SCSI-Gerät kann dann für den Zugriff auf die FC-LUN verwendet werden, als wäre es ein lokal angeschlossenes SCSI-Gerät.

Verwenden Sie die Schaltfläche SR-Sonde , um die LUN-gestützten SCSI-Geräte aufzulisten, die auf dem Host vorhanden sind. Dieser Befehl erzwingt eine Suche nach neuen LUN-gestützten SCSI-Geräten. Der Pfadwert, der von SR-Sonde für ein LUN-gestütztes SCSI-Gerät ist auf allen Hosts mit Zugriff auf die LUN konsistent. Daher muss dieser Wert verwendet werden, wenn freigegebene SRs erstellt werden, auf die alle Hosts in einem Ressourcenpool zugreifen können.

Die gleichen Funktionen gelten für QLogic iSCSI-HBAs.

Siehe Erstellen von Speicher-Repositories , um weitere Informationen zum Erstellen von gemeinsam genutzten HBA-basierten FC- und iSCSI-SRs zu erhalten.

Hinweis:

Die Citrix Hypervisor-Unterstützung für Fibre Channel unterstützt keine direkte Zuordnung einer LUN zu einer VM. HBA-basierte LUNs müssen dem Server zugeordnet und für die Verwendung in einer SR angegeben werden. VDIs innerhalb der SR werden VMs als Standardblockgeräte zur Verfügung gestellt.

Die Blockgröße einer LVM-über-HBA-LUN muss 512 Byte betragen. Um Speicher mit nativen 4-KB-Blöcken zu verwenden, muss der Speicher auch die Emulation von 512-Byte-Zuordnungsblöcken unterstützen.

Erstellen eines Speicher-Repositorys