Erstellen Sie ein Speicher-Repository

Sie können den Assistenten für neues Speicher-Repository in XenCenter verwenden, um Speicherrepositorys (SRs) zu erstellen. Der Assistent führt Sie durch die Konfigurationsschritte. Verwenden Sie alternativ die CLI und den Befehl sr-create. Der Befehl sr-create erstellt ein SR auf dem Speichersubstrat (wodurch möglicherweise alle vorhandenen Daten zerstört werden). Außerdem werden das SR-API-Objekt und ein entsprechender PBD-Datensatz erstellt, sodass VMs den Speicher verwenden können. Bei erfolgreicher Erstellung des SRs wird das PBD automatisch angeschlossen. Wenn das SR-Flag auf shared=true gesetzt ist, wird für jeden Citrix Hypervisor im Ressourcenpool ein PBD-Datensatz erstellt und angeschlossen.

Wenn Sie ein 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 Speicherverkehr. Informationen zum Zuweisen einer IP-Adresse zu einer Netzwerkkarte finden Sie unter Konfigurieren einer dedizierten Speicher-NIC.

Alle Citrix Hypervisor SR-Typen unterstützen die VDI-Größenänderung, schnelles Klonen und Snapshot. 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 die vollständige Thin Provisioning, auch für virtuelle Datenträger, die aktiv sind.

Warnungen:

• Wenn VHD-VDIs nicht an eine VM angeschlossen sind, z. B. für einen VDI-Snapshot, werden sie standardmäßig als dünn bereitgestellt gespeichert. Wenn Sie versuchen, den VDI erneut anzuhängen, stellen Sie sicher, dass ausreichend Datenträgerspeicher verfügbar ist, damit der VDI dick bereitgestellt werden kann. VDI-Klone werden dick bereitgestellt.

• Citrix Hypervisor unterstützt keine Snapshots auf der externen SAN-Ebene einer LUN für jeden 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 verfügbar macht, die kleiner oder gleich 255 ist, bevor Sie diese LUN verwenden, um eine SR zu erstellen.

• Wenn Sie Thin Provisioning auf einem dateibasierten SR verwenden, stellen Sie sicher, dass Sie den freien Speicherplatz auf Ihrem SR überwachen. Wenn die SR-Nutzung auf 100% ansteigt, schlagen weitere Schreibvorgänge von VMs fehl. Diese fehlgeschlagenen Schreibvorgänge können zum Einfrieren oder Absturz der VM führen.

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

Lokales LVM

Der Typ Local LVM stellt Datenträger innerhalb einer lokal angeschlossenen Volume-Gruppe 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. Ein VDI wird im VHD-Format in einem logischen LVM-Volume 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-Clon-Funktionalität für LVM-basierte SRs ist mit einem inhärenten Leistungsaufwand verbunden. Wenn eine optimale Leistung erforderlich ist, unterstützt Citrix Hypervisor die Erstellung von VDIs im Rohformat zusätzlich zum Standard-VHD-Format. Die Citrix Hypervisor Snapshot-Funktionalität wird auf RAW-VDIs nicht unterstützt.

Warnung:

Versuchen Sie nicht, einen Snapshot einer VM mit angeschlossenen type=raw-Datenträger zu erstellen. Diese Aktion kann dazu führen, dass ein teilweiser Snapshot erstellt wird. In dieser Situation können Sie die verwaisten Snapshot-VDIs identifizieren, indem Sie das Feld snapshot-of markieren und dann löschen.

Erstellen eines lokalen LVM SRs

Ein LVM SR wird standardmäßig bei der Host-Installation erstellt.

Die Gerätekonfigurationsparameter für LVM SRs sind:

Verwenden Sie den Befehl, um ein lokales LVM SR auf /dev/sdb zu erstellen.

    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-->

Lokales EXT3/EXT4

Die Verwendung von EXT3/EXT4 ermöglicht Thin Provisioning auf lokalem Speicher Der Standard-Speicherrepository-Typ ist jedoch LVM, da er eine konsistente Schreibleistung bietet und ein Überschreiben des Speichers verhindert. Wenn Sie EXT3/EXT4 verwenden, wird die Leistung in den folgenden Fällen möglicherweise reduziert:

• Bei der Durchführung von VM-Lebenszyklusvorgängen wie VM-Erstellen und Aussetzen/Fortsetzen
• Beim Erstellen großer Dateien innerhalb der VM

EXT3/EXT4 SRs des lokalen Datenträgers müssen mit der Citrix Hypervisor CLI konfiguriert werden.

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

• Wenn Sie das 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 das lokale EXT SR auf Citrix Hypervisor 8.2 erstellt haben, wird EXT4 verwendet.

Hinweis:

Die Blockgröße eines EXT3/EXT4-Datenträgers muss 512 Byte sein. 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 lokalen EXT4 SR (ext)

Gerätekonfigurationsparameter für EXT SRs:

Verwenden Sie den folgenden Befehl, um ein lokales EXT4 SR auf /dev/sdb zu erstellen:

    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ätemanager als VDIs angeschlossen wurden.

Citrix Hypervisor verfügt über zwei SRs vom Typ udev, die Wechselspeicher darstellen. Eine davon ist für den CD- oder DVD-Datenträger im physischen CD- oder DVD-ROM-Laufwerk des Citrix Hypervisor-Servers. Das andere Gerät ist für ein USB-Gerät vorgesehen, das an einen Port des Citrix Hypervisor-Servers angeschlossen ist. VDIs, die die Medien darstellen, kommen und gehen, wenn Datenträger oder USB-Sticks eingelegt und entfernt werden.

ISO-Image

Der ISO-Typ verarbeitet CD-Images, die als Dateien im ISO-Format gespeichert sind. Dieser SR-Typ eignet sich zum Erstellen gemeinsam genutzter 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, das als NFS-Freigabe verfügbar ist.
• 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 nicht angeben, der für die SR verwendet werden soll, verwendet Citrix Hypervisor den Gerätekonfigurationsparameter location, um den Typ zu bestimmen.

Gerätekonfigurationsparameter für ISO-SRs:

Hinweis:

Wenn Sie den Befehl sr-create ausführen, empfehlen wir, das Argument device-config:cifspassword_secret zu verwenden, anstatt das Kennwort in der Befehlszeile anzugeben. Weitere Informationen finden Sie unter Secrets.

Für Speicher-Repositorys, die eine Bibliothek von ISOs speichern, muss der Parameter content-type beispielsweise auf iso festgelegt werden. 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 das ISO-SR bereitzustellen. Weitere Informationen zur Verwendung dieser SR-Typen finden Sie unter NFS und SMB.

Wir empfehlen, dass Sie SMB Version 3 verwenden, um ISO SR auf dem Windows-Dateiserver zu mounten. 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 dem folgenden Befehl mit SMB Version 1 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 gemeinsam genutzte SRs auf iSCSI LUNs. iSCSI wird mit der Open-iSCSI-Software iSCSI-Initiator oder mit einem unterstützten iSCSI Host Bus Adapter (HBA) unterstützt. Die Schritte zur Verwendung von iSCSI-HBAs sind identisch mit den Schritten für Fibre-Channel-HBAs. Beide Schritte sind unter Create a Shared LVM over Fibre Channel/ Fibre Channel over Ethernet/ iSCSI HBA oder SAS SRbeschrieben.

Gemeinsame iSCSI-Unterstützung unter Verwendung des Software-iSCSI-Initiators wird basierend auf dem Linux Volume Manager (LVM) implementiert. Diese Funktion bietet dieselben Leistungsvorteile, die LVM-VDIs im lokalen Datenträgergehäuse bieten. Gemeinsam genutzte iSCSI-SRs, die den softwarebasierten Host-Initiator verwenden, können die VM-Agilität mithilfe der Livemigration unterstützen: VMs können auf jedem Citrix Hypervisor-Server in einem Ressourcenpool gestartet und ohne nennenswerte Ausfallzeiten zwischen ihnen migriert werden.

iSCSI-SRs verwenden die gesamte LUN, die bei der Erstellung angegeben wurde, und dürfen sich nicht über mehr als eine LUN erstrecken. CHAP-Unterstützung wird für die Clientauthentifizierung sowohl während der Datenpfadinitialisierung 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 hat eine iSCSI-Initiatoradresse und ein Ziel hat eine iSCSI-Zieladresse. Zusammenfassend werden diese Namen als iSCSI Qualified Names oder IQNs bezeichnet.

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

iSCSI-Ziele ermöglichen üblicherweise die Zugriffssteuerung mithilfe der IQN-Listen des iSCSI-Initiators. Alle iSCSI-Ziele/LUNs, auf die Ihr Citrix Hypervisor-Server zugreift, müssen so konfiguriert sein, dass sie den Zugriff durch den Initiator-IQN des Hosts ermöglichen. In ähnlicher Weise müssen Ziele/LUNs, die als gemeinsam genutzte iSCSI-SRs verwendet werden sollen, so konfiguriert werden, dass sie den Zugriff aller Host-IQNs im Ressourcenpool ermöglichen.

Hinweis:

iSCSI-Ziele, die keine Zugriffssteuerung bieten, beschränken in der Regel den LUN-Zugriff auf einen einzelnen Initiator, um die Datenintegrität zu gewährleisten. Wenn eine iSCSI-LUN als gemeinsam genutztes SR über mehrere Server in einem Pool verwendet wird, stellen Sie sicher, dass der Multi-Initiator-Zugriff 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 bei Verwendung des iSCSI-Softwareinitiators angepasst werden:

    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-ID verwendet wird, kann es zu Datenbeschädigungen oder Verweigerung des LUN-Zugriffs kommen.
• Ändern Sie nicht den IQN des Citrix Hypervisor-Servers mit angeschlossenen iSCSI SRs. Dies kann zu Fehlern bei der Verbindung zu neuen Zielen oder vorhandenen SRs führen.

Software-FCoE-Speicher (veraltet)

Software-FCoE bietet ein Standardrahmen, an das Hardwarehersteller ihre FCoE-fähige Netzwerkkarte anschließen und die gleichen Vorteile eines hardwarebasierten FCoE nutzen können. Diese Funktion macht die Verwendung teurer HBAs überflüssig.

Hinweis:

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

Bevor Sie einen Software-FCoE-Speicher erstellen, schließen Sie die Konfiguration manuell ab, die erforderlich ist, 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 in die CNA des Hosts eingebunden. 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 zur Unterstützung von FCoE finden Sie in der Dokumentation des Herstellers.

Hinweis:

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

Erstellen eines Software-FCoE SRs

Vor dem Erstellen eines Software-FCoE SRs müssen Kunden sicherstellen, dass FCoE-fähige NICs an den Host angeschlossen sind.

Die Gerätekonfigurationsparameter für FCoE SRs sind:

Führen Sie den folgenden Befehl aus, um ein gemeinsames FCoE SR zu erstellen:

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

Hardware-Hostbusadapter (HBAs)

Dieser Abschnitt behandelt verschiedene Vorgänge, die für die Verwaltung von SAS-, Fibre-Channel- und iSCSI-HBAs erforderlich sind.

Beispiel für eine QLogic iSCSI HBA-Einrichtung

Einzelheiten zur Konfiguration von QLogic Fibre Channel und iSCSI HBAs finden Sie auf der Cavium-Website .

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

1. Stellen Sie die IP-Netzwerkkonfiguration für den HBA ein. 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 Multiport-HBA verwenden.

   /opt/QLogic_Corporation/SANsurferiCLI/iscli -ipdhcp 0
   <!--NeedCopy-->
   

2. Fügen Sie ein beständiges iSCSI-Ziel zu Port 0 des HBA hinzu.

   /opt/QLogic_Corporation/SANsurferiCLI/iscli -pa 0 iscsi_target_ip_address
   <!--NeedCopy-->
   

3. Verwenden Sie den xe-Befehl sr-probe, um eine erneute Suche des HBA-Controller zu erzwingen und verfügbare 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.

HBA-basierte SAS-, FC- oder iSCSI-Geräteeinträge entfernen

Hinweis:

Dieser Schritt ist nicht erforderlich. Wir empfehlen, dass nur Hauptbenutzer diesen Vorgang ausführen, wenn dies erforderlich ist.

Jede HBA-basierte LUN hat einen entsprechenden globalen Gerätepfadeintrag unter /dev/disk/by-scsibus im Format <SCSIid>-<adapter>:<bus>:<target>:<lun> und einen Standardgerätepfad unter /dev. Gehen Sie folgendermaßen vor, um die Geräteeinträge für LUNs zu entfernen, die nicht mehr als SRs verwendet werden:

1. Verwenden Sie sr-forget oder sr-destroy nach Bedarf, um das SR aus der Citrix Hypervisor-Serverdatenbank zu entfernen. Einzelheiten finden Sie unter SRs entfernen .

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

3. Verwenden Sie den Befehl sr-probe, um die Werte ADAPTER, BUS, TARGET und LUNs zu ermitteln, die der zu entfernenden LUN entsprechen. Weitere Informationen finden Sie unter Sonde und SR.

4. Entfernen Sie die Geräteeinträge mit dem folgenden 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. Durch versehentliches Entfernen einer für den Host-Betrieb erforderlichen LUN, z. B. des Boot- oder Root-Geräts, wird der Host unbrauchbar.

Gemeinsam genutzter LVM-Speicher

Der Shared LVM-Typ stellt Datenträger 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

Gerätekonfigurationsparameter für LVMoiSCSI SRs:

Hinweis:

Wenn Sie den Befehl sr-create ausführen, empfehlen wir, das Argument device-config:chappassword_secret zu verwenden, anstatt das Kennwort in der Befehlszeile anzugeben. Weitere Informationen finden Sie unter Secrets.

Verwenden Sie den folgenden Befehl, um ein gemeinsam genutztes 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.

Gerätekonfigurationsparameter für LVMoHBA SRs:

Um ein gemeinsam genutztes 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 Ihrer SAN-Dokumentation.

2. Verwenden Sie bei Bedarf die im Citrix Hypervisor-Server enthaltene HBA-CLI, 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 die QLogic iSCSI-HBA-Konfiguration finden Sie unter Hardware-Host-Busadapter (HBAs) im vorherigen Abschnitt. Weitere Informationen zu Fibre-Channel- und iSCSI-HBAs finden Sie auf den Websites Broadcom und Cavium .

3. Verwenden Sie den Befehl sr-probe, um den globalen Gerätepfad der HBA-LUN zu bestimmen. Der Befehl sr-probe erzwingt einen Neuscan der im System installierten HBAs, um neue LUNs zu erkennen, die für den Host in Zonen unterteilt wurden. Der Befehl gibt eine Liste von Eigenschaften für jede gefundene LUN zurück. Geben Sie den Parameter an host-uuid, um sicherzustellen, dass die Sonde auf dem gewünschten Host erfolgt.

   Der globale Gerätepfad, der als <path>-Eigenschaft zurückgegeben wird, ist für alle Hosts im Pool gemeinsam. Daher muss dieser Pfad beim Erstellen des SRs als Wert für den Parameter device-config:device verwendet werden.

   Wenn mehrere LUNs vorhanden sind, verwenden Sie den Anbieter, die LUN-Größe, die LUN-Seriennummer oder die SCSI-ID der <path>-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 das SR. Geben Sie den globalen Gerätepfad an, der in der <path>-Eigenschaft von sr-probe zurückgegeben wird. PBDs werden für jeden Host im Pool automatisch 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 neu zu versuchen und Teile des Vorgangs sr-create zu blockieren. Diese Funktion kann in Fällen nützlich sein, in denen das LUN-Zoning für einen oder mehrere Hosts in einem Pool nicht korrekt war, als das SR erstellt wurde. Korrigieren Sie das Zoning für die betroffenen Hosts und verwenden Sie die Funktion “Speicherrepository reparieren”, anstatt das SR zu entfernen und neu zu erstellen.

Thin Provisioning gemeinsam genutzter 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 zu verwenden, muss der Citrix Hypervisor Ressourcenpool ein Clusterpool sein. Aktivieren Sie das Clustering in Ihrem Pool, bevor Sie ein GFS2-SR erstellen. Weitere Informationen finden Sie unter Clustered-Pools.

Stellen Sie sicher, dass Storage-Multipathing zwischen Ihrem Clusterpool und Ihrem GFS2-SR eingerichtet ist. Weitere Informationen finden Sie unter Speicher-Multipathing.

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

Erstellen eines gemeinsam genutzten GFS2-SR

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

Erstellen eines gemeinsam genutzten 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:

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 gemeinsam genutzten 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:

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 jede Version von NFSv4 oder NFSv3 unterstützen) oder auf SMB-Servern (die SMB 3 unterstützen) können sofort als SR für virtuelle Laufwerke 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, außerdem:

• Auf allen Citrix Hypervisor-Servern in einem Ressourcenpool zu startende VMs

• VM migriert mithilfe von Livemigration zwischen Citrix Hypervisor-Servern in einem Ressourcenpool (ohne nennenswerte Ausfallzeiten)

Wichtig:

• Die Unterstützung für SMB3 ist auf die Möglichkeit beschränkt, mithilfe des 3-Protokolls eine Verbindung zu einer Freigabe herzustellen. Zusätzliche Funktionen wie transparentes Failover hängen von der Verfügbarkeit der Funktionen im Linux-Upstream-Kernel ab und werden in Citrix Hypervisor 8.2 nicht unterstützt.
• Clustered SMB wird von Citrix Hypervisor nicht unterstützt.
• Für NFSv4 wird nur der Authentifizierungstyp AUTH_SYS 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 für unabhängige Netzwerk-Switches mit redundanter Stromversorgung.
• 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, werden dünn bereitgestellt. Die Image-Datei wird zugewiesen, während die VM Daten auf den Datenträger schreibt. Dieser Ansatz hat den erheblichen Vorteil, dass die VM-Image-Dateien nur so viel Speicherplatz auf dem Speicher beanspruchen, wie erforderlich ist. Wenn beispielsweise ein 100-GB-VDI für eine VM zugewiesen ist und ein Betriebssystem installiert ist, spiegelt die VDI-Datei nur die Größe der auf den Datenträger geschriebenen Betriebssystemdaten wider 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 zum Zeitpunkt des Klonens die gemeinsamen Daten auf dem Datenträger. Jede VM nimmt ihre eigenen Änderungen in einer isolierten Copy-on-Write-Version des 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 durch diese Aktion der Inhalt von VDIs beschädigt werden kann.

Citrix Hypervisor wurde für Speicher der Unternehmensklasse optimiert, der nichtflüchtiges RAM verwendet, um schnelle Bestätigungen von Schreibanforderungen zu ermöglichen 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-Speicher getestet

Warnung:

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

Stellen Sie sicher, dass Sie den freien Speicherplatz auf Ihrem SR überwachen. Wenn die SR-Nutzung auf 100% ansteigt, schlagen weitere Schreibvorgänge von VMs fehl. Diese fehlgeschlagenen Schreibvorgänge können zum Einfrieren oder Absturz der VM führen.

Erstellen eines gemeinsam genutzten 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 — In das Dateisystem für SR kann nicht geschrieben werden.”

Um ein NFS-SR zu erstellen, müssen Sie den Hostnamen oder die IP-Adresse des NFS-Servers angeben. Sie können das SR auf jedem gültigen Zielpfad erstellen. Verwenden Sie den Befehl sr-probe, um eine Liste der vom Server exportierten gültigen Zielpfade anzuzeigen.

In Szenarien, in denen Citrix Hypervisor mit Low-End-Speicher verwendet wird, wartet es vorsichtig darauf, dass alle Schreibvorgänge bestätigt werden, bevor Bestätigungen an VMs weitergegeben werden. Dieser Ansatz verursacht erhebliche Leistungskosten und kann gelöst werden, indem der Speicher so eingestellt wird, dass der SR-Einhängepunkt als Export im asynchronen Modus dargestellt wird. Asynchrone Exporte bestätigen Schreibvorgänge, die nicht wirklich auf dem Datenträger sind. Überlegen Sie sich in diesen Situationen sorgfältig die Risiken eines Scheiterns.

Hinweis:

Der NFS-Server muss so konfiguriert sein, dass er den angegebenen Pfad zu allen Servern im Pool exportiert. Wenn diese Konfiguration nicht erfolgt, schlägt das Erstellen des SRs und das Einstecken des PBD-Datensatzes fehl.

Die Citrix Hypervisor NFS-Implementierung verwendet standardmäßig TCP. Wenn es Ihre Situation 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 durchzuführen, geben Sie beim Erstellen eines SR den Parameter device-config mit useUDP=true an.

Die folgenden Parameter device-config werden mit NFS-SRs verwendet:

Verwenden Sie zum Beispiel den folgenden Befehl, um ein gemeinsam genutztes NFS-SR auf 192.168.1.10:/export1 mit einer beliebigen Version 4 von NFS zu erstellen, die vom Filer zur Verfügung gestellt wird:

    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-->

Führen Sie den folgenden Befehl aus, um speziell mit NFS Version 4.0 ein nicht gemeinsam genutztes NFS-SR auf 192.168.1.10:/export1 zu erstellen:

    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 gemeinsam genutzten SMB-SRs (SMB)

Um ein 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.

Gerätekonfigurationsparameter für SMB SRs:

Hinweis:

Wenn Sie den Befehl sr-create ausführen, empfehlen wir, das Argument device-config:password_secret zu verwenden, anstatt das Kennwort in der Befehlszeile anzugeben. Weitere Informationen finden Sie unter Secrets.

Um beispielsweise ein gemeinsam genutztes SMB-SR auf 192.168.1.10:/share1 zu erstellen, verwenden Sie den 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 ein nicht gemeinsam genutztes 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 LVM-über-Hardware-HBA-Typ stellt Datenträger als VHDs auf logischen Volumes innerhalb einer Volume-Gruppe dar, die auf einer HBA-LUN erstellt wurde und beispielsweise hardwarebasierte iSCSI- oder FC-Unterstützung bietet.

Citrix Hypervisor-Server unterstützen Fibre-Channel-SANs über Emulex- oder QLogic Hostbusadapter (HBAs). Die gesamte Fibre-Channel-Konfiguration, die erforderlich ist, um eine Fibre-Channel-LUN für den Host verfügbar zu Diese Konfiguration umfasst Speichergeräte, Netzwerkgeräte und den HBA innerhalb des Citrix Hypervisor-Servers. Nachdem die gesamte FC-Konfiguration abgeschlossen ist, macht der HBA ein von der FC-LUN unterstütztes SCSI-Gerät für den Host verfügbar. 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 den Befehl sr-probe, um die LUN-unterstützten SCSI-Geräte aufzulisten, die auf dem Host vorhanden sind. Dieser Befehl erzwingt einen Scan nach neuen LUN-gestützten SCSI-Geräten. Der von sr-probe für ein LUN-gestütztes SCSI-Gerät zurückgegebene Pfadwert ist auf allen Hosts mit Zugriff auf die LUN konsistent. Daher muss dieser Wert verwendet werden, wenn gemeinsam genutzte SRs erstellt werden, auf die alle Hosts in einem Ressourcenpool zugreifen können.

Dieselben Funktionen gelten für QLogic iSCSI-HBAs.

Weitere Informationen zum Erstellen von gemeinsam genutzten HBA-basierten FC- und iSCSI-SRs finden Sie unter Erstellen von Speicherrepositories .

Hinweis:

Citrix Hypervisor Unterstützung für Fibre Channel unterstützt keine direkte Zuordnung einer LUN zu einer VM. HBA-basierte LUNs müssen dem Host zugeordnet und für die Verwendung in einem SR angegeben werden. VDIs innerhalb des SRs sind für VMs als standardmäßige Blockgeräte verfügbar.

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