Speicher-Repository-Formate

Mit dem Assistenten „ Neues Speicher-Repository “ in XenCenter können Sie Speicher-Repositories erstellen. Der Assistent führt Sie durch die Konfigurationsschritte. Alternativ können Sie die Befehlszeilenschnittstelle und densr-create Befehl verwenden. sr-create`` Mit dem Befehl wird ein SR auf dem Speichersubstrat erstellt (möglicherweise vorhandene Daten zerstört). Außerdem werden das SR-API-Objekt und ein entsprechender PBD-Datensatz erstellt, wodurch VMs den Speicher verwenden können. Bei erfolgreicher Erstellung der SR wird die PBD automatisch gesteckt. Wenn dasshared=true SR-Flag gesetzt ist, wird für jeden Citrix Hypervisor im Ressourcenpool ein PBD-Datensatz 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 unterKonfigurieren 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, NFS, GFS2) unterstützen die vollständige Thin Provisioning, auch für aktive virtuelle Laufwerke.

Warnhinweis:

Wenn VHD-VDIs nicht an eine VM angeschlossen sind, z. B. für einen VDI-Snapshot, werden sie standardmäßig als Thinly Provisioning gespeichert. Wenn Sie versuchen, den VDI erneut anzuhängen, stellen Sie sicher, dass genügend Speicherplatz zur Verfügung steht, damit der VDI stark bereitgestellt wird. VDI-Klone werden stark bereitgestellt.

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

Speicher-Repository-Format Maximale VDI-Größe
EXT3 2 TiB
LVM 2 TiB
NFS 2 TiB
LVMofCoe 2 TiB
LVMoiSCSI 2 TiB
- lvmohba 2 TiB
GFS2 (mit iSCSI oder HBA) 16 TiB

Lokale LVM

Der Typ Local LVMs stellt Datenträger innerhalb einer lokal angeschlossenen Volumegruppe 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.

Überlegungen zur LVM-Leistung

Die Snapshot- und schnelle Clone-Funktionalität für LVM-basierte SRs verfügt über einen inhärenten Performance-Overhead. Wenn eine optimale Leistung erforderlich ist, unterstützt Citrix Hypervisor die Erstellung von VDIs im Rohformat zusätzlich zum Standard-VHD-Format. Die Snapshot-Funktionalität von Citrix Hypervisor wird auf Raw-VDIs nicht unterstützt.

Nicht transportierbare Snapshots, die den standardmäßigen Windows VSS-Provider verwenden, funktionieren auf jedem VDI-Typ.

Warnung:Versuchen

Sie nicht, einen Snapshot einer virtuellen Maschine mit angeschlossenentype=raw``Festplatten zu erstellen. Diese Aktion kann dazu führen, dass ein Teilsnapshot erstellt wird. In diesem Fall können Sie die verwaiste Snapshot-VDIs identifizieren, indem Sie dassnapshot-of Feld überprüfen und dann löschen.

Erstellen eines lokalen LVM SR

Bei der Hostinstallation wird standardmäßig ein LVM-SR erstellt.

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

Parametername Beschreibung Erforderlich?
Gerätetyp Gerätename auf dem lokalen Host, der für die SR verwendet werden soll Ja

Verwenden Sie den folgenden Befehl/dev/sdb, um eine lokale LVM SR auf 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

Lokales EXT3

Die Verwendung von EXT3 ermöglicht die Thin Provisioning auf lokalem Speicher. Der Standardspeicher-Repository-Typ ist jedoch LVM, da er eine konsistente Schreibleistung bietet und Speicherüber-Commit verhindert. Wenn Sie EXT3 verwenden, wird in den folgenden Fällen möglicherweise eine reduzierte Leistung angezeigt:

  • Beim Ausführen von VM-Lebenszyklusvorgängen wie Erstellen von virtuellen Rechnern und Anhalten/Fortsetzen
  • Beim Erstellen großer Dateien innerhalb der VM

Die lokalen Datenträger EXT SRs müssen mit der Citrix Hypervisor CLI konfiguriert werden.

Erstellen eines lokalen EXT3 SR (ext)

Gerätekonfigurationsparameter für externe SRs:

Parametername Beschreibung Erforderlich?
Gerätetyp Gerätename auf dem lokalen Host, der für die SR verwendet werden soll Ja

Verwenden Sie den folgenden Befehl/dev/sdb, um einen lokalen ext SR auf zu erstellen:

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

udev

Derudev Typ stellt Geräte dar, die mit demudev Geräte-Manager als VDIs verbunden sind.

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

ISO

Der ISO-Typ verarbeitet CD-Images, die als Dateien im ISO-Format gespeichert sind. Dieser SR-Typ ist nützlich, um gemeinsam genutzte ISO-Bibliotheken zu erstellen. Für Speicher-Repositories, die eine Bibliothek von ISOs speichern, muss dercontent-type Parameter auf gesetzt werdeniso .

Zum Beispiel:

    xe sr-create host-uuid=valid_uuid content-type=iso \
      type=iso name-label="Example ISO SR" \
      device-config:location=nfs server:path

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

     xe sr-create content-type=iso type=iso shared=true device-config:location=valid location
     device-config:username=username device-config:cifspassword=password
     device-config:type=cifs device-config:vers=Choose either 1.0 or 3.0 name-label="Example ISO SR"

Hinweis:

Wenn Sie den sr-create Befehl ausführen, können Sie das device-config:cifspassword_secret Argument verwenden, anstatt das Kennwort in der Befehlszeile anzugeben. Weitere Informationen finden Sie unter Geheimnisse.

Software-iSCSI-Unterstützung

Citrix Hypervisor unterstützt gemeinsam genutzte SRs auf iSCSI-LUNs. iSCSI wird mit dem iSCSI-Software-iSCSI-Initiator oder mithilfe eines unterstützten iSCSI-Host-Bus-Adapters (HBA) unterstützt. Die Schritte zur Verwendung von iSCSI-HBAs sind identisch mit den Schritten für Fibre-Channel-HBAs. Beide Schritte werden unter beschriebenErstellen eines gemeinsam genutzten LVM über Fibre-Channel/Fibre-Channel-over-Ethernet/iSCSI-HBA oder SAS SR.

Die gemeinsam genutzte iSCSI-Unterstützung mit dem Software-iSCSI-Initiator wird basierend auf dem Linux Volume Manager (LVM) implementiert. Diese Funktion bietet die gleichen Leistungsvorteile, die LVM-VDIs im lokalen Festplattengehäuse bieten. Gemeinsame iSCSI-SRs, die den softwarebasierten Hostinitiator verwenden, können VM-Agilität durch Live-Migration unterstützen: VMs können auf jedem Citrix Hypervisor or-Server in einem Ressourcenpool gestartet und ohne spürbare Ausfallzeiten zwischen ihnen migriert werden.

iSCSI-SRs verwenden die gesamte zum Zeitpunkt der Erstellung angegebene LUN und erstrecken sich möglicherweise nicht über mehr als eine LUN. CHAP-Unterstützung wird für die Clientauthentifizierung sowohl während der Datenpfadinitialisierung als auch in der LUN-Erkennungsphase bereitgestellt.

Hinweis:

Die Blockgröße einer iSCSI-LUN muss 512 Byte betragen.

iSCSI-Konfiguration des Citrix Hypervisor or-Servers

Alle iSCSI-Initiatoren und -Ziele müssen über einen eindeutigen Namen verfügen, damit sie im Netzwerk eindeutig identifiziert werden können. Ein Initiator hat eine iSCSI-Initiatoradresse und ein Ziel hat eine iSCSI-Zieladresse. Gemeinsam werden diese Namen als iSCSI-qualifizierte Namen oder IQNs bezeichnet.

Citrix Hypervisor or-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 zu mehreren iSCSI-Zielen herzustellen.

iSCSI-Ziele bieten in der Regel Zugriffssteuerung mithilfe von iSCSI-Initiator-IQN-Listen. Alle iSCSI-Targets/LUNs, auf die der Citrix Hypervisor or-Server zugreift, müssen so konfiguriert sein, dass der Zugriff durch den Initiator-IQN des Hosts gewährt wird. Ebenso müssen Ziele/LUNs, die als gemeinsam genutzte iSCSI-SRs verwendet werden sollen, so konfiguriert sein, dass alle Host-IQNs im Ressourcenpool Zugriff haben.

Hinweis:

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

Der IQN-Wert des Citrix Hypervisor or-Servers kann mithilfe von XenCenter oder mithilfe der Befehlszeilenschnittstelle 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

Warnhinweis:

  • Jedes iSCSI-Ziel und jeder Initiator muss über einen eindeutigen IQN verfügen. Wenn ein nicht eindeutiger IQN-Bezeichner verwendet wird, kann Datenbeschädigung oder Verweigerung des LUN-Zugriffs auftreten.
  • Ändern Sie den Citrix Hypervisor or-Server-IQN mit angeschlossenen iSCSI-SRs nicht. Dies kann zu Fehlern bei der Verbindung mit neuen Zielen oder vorhandenen SRs führen.

Software FCoE-Speicher

Software-FCoE bietet ein Standard-Framework, in das Hardwarehersteller ihre FCOE-fähige NIC anschließen können und die gleichen Vorteile wie eine hardwarebasierte FCoE nutzen können. Diese Funktion macht die Verwendung teurer HBAs überflüssig.

Bevor Sie einen Software-FCoE-Speicher erstellen, führen Sie die Konfiguration manuell aus, 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 für den öffentlichen 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 gemountet. Das SCSI-Gerät kann dann verwendet werden, um auf die LUN zuzugreifen, 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 einer Software FCoE SR

Bevor Sie eine Software FCoE SR erstellen, müssen Kunden sicherstellen, dass FCOE-fähige Netzwerkkarten an den Host angeschlossen 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 eine gemeinsam genutzte FCoE SR zu erstellen:

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

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 QLogic iSCSI-HBA-Setup

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

Nachdem der HBA physisch auf dem Citrix Hypervisor or-Server installiert wurde, gehen Sie folgendermaßen vor, um den HBA zu konfigurieren:

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

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

    /opt/QLogic_Corporation/SANsurferiCLI/iscli -pa 0 iscsi_target_ip_address
    
  3. Verwenden Sie densr-probe Befehl xe, um eine erneute Suche des HBA-Controllers zu erzwingen und verfügbare LUNs anzuzeigen. Weitere Informationen finden Sie unter Sonde einer SR und Erstellen eines gemeinsam genutzten LVM über Fibre-Channel/Fibre-Channel-over-Ethernet/iSCSI-HBA oder SAS SR.

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

Hinweis:

Dieser Schritt ist nicht erforderlich. Wir empfehlen, dass nur Power-User diesen Prozess durchführen, wenn dies erforderlich ist.

Jede HBA-basierte LUN verfügt über 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 Siesr-forget odersr-destroy entfernen Sie den SR aus der Citrix Hypervisor or-Serverdatenbank. Weitere Informationen SRs entfernen finden Sie unter.

  2. Entfernen Sie die Zoning-Konfiguration im SAN für die gewünschte LUN auf den gewünschten Host.

  3. Verwenden Sie densr-probe Befehl, um die ADAPT-, BUS-, TARGET- und LUN-Werte zu ermitteln, die der zu entfernenden LUN entsprechen. Für weitere Informationen,Sonde einer SR.

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

    echo "1" > /sys/class/scsi_device/adapter:bus:target:lun/device/delete
    

Warnhinweis:

Stellen Sie sicher, dass Sie sicher sind, welche LUN Sie entfernen. Das versehentliche Entfernen einer LUN, die für den Hostbetrieb erforderlich ist, wie z. B. das Start- oder Root-Gerät, macht den Host unbrauchbar.

Gemeinsamer LVM-Speicher

Der Typ Shared LVMs stellt Datenträger als logische Volumes innerhalb einer Volumegruppe dar, die auf einer iSCSI-LUN (FC oder SAS) erstellt wurde.

Hinweis:

Die Blockgröße einer iSCSI-LUN muss 512 Byte betragen.

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

Gerätekonfigurationsparameter für LVMoiSCSI SRs:

Parametername Beschreibung Erforderlich?
target Die IP-Adresse oder der Hostname des iSCSI-Filers, der die SR hostet Ja
targetIQN Die IQN-Zieladresse des iSCSI-Filers, der die SR hostet Ja
SCSIid Die SCSI-Bus-ID der Ziel-LUN Ja
chapuser Der Benutzername, der für die CHAP-Authentifizierung verwendet werden soll Nein
chappassword Das Kennwort, das für die CHAP-Authentifizierung verwendet werden soll Nein
port Die Netzwerkportnummer, auf der das Ziel abgefragt werden soll Nein
usediscoverynumber Der spezifische iSCSI-Datensatzindex, der verwendet werden soll Nein
incoming_chapuser Der Benutzername, den der iSCSI-Filter zur Authentifizierung gegen den Host verwendet Nein
incoming_chappassword Das Kennwort, das der iSCSI-Filter zur Authentifizierung gegen den Host verwendet Nein

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

Erstellen eines gemeinsam genutzten LVM über Fibre-Channel/Fibre-Channel-over-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:

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

Führen Sie die folgenden Schritte auf jedem Host im Pool aus, um eine gemeinsam genutzte LVMohba SR zu erstellen:

  1. Zonen Sie in einer oder mehreren LUNs zu jedem Citrix Hypervisor or-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 ggf. die im Citrix Hypervisor or-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-Bus-Adapter (HBAs) im vorherigen Abschnitt. Weitere Informationen zu Fibre Channel- und iSCSI-HBAs finden Sie auf denBroadcomundKaviumWebsites.

  3. Verwenden Sie densr-probe Befehl, um den globalen Gerätepfad der HBA-LUN zu ermitteln. Dersr-probe Befehl erzwingt einen erneuten Scannen der im System installierten HBAs, um neue LUNs zu erkennen, die auf den Host in Zonen aufgeteilt wurden. Der Befehl gibt eine Liste der Eigenschaften für jede gefundene LUN zurück. Geben Sie denhost-uuid Parameter an, um sicherzustellen, dass der Prüfpunkt auf dem gewünschten Host auftritt.

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

    Wenn mehrere LUNs vorhanden sind, verwenden Sie den Hersteller, die LUN-Größe, die LUN-Seriennummer oder die SCSI-ID aus 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>
    
  4. Erstellen Sie auf dem Master-Host des Pools die SR. Geben Sie den globalen Gerätepfad an, der in der<path> Eigenschaft von zurückgegeben wirdsr-probe . 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
    

Hinweis:

Sie können die XenCenter Repair Storage Repository verwenden, um die PBD-Erstellung und das Anschließen von Teilen dessr-create Vorgangs zu wiederholen. Diese Funktion kann nützlich sein, wenn die LUN-Zoning für einen oder mehrere Hosts in einem Pool falsch war, als die SR erstellt wurde. Korrigieren Sie die Zoneneinteilung für die betroffenen Hosts und verwenden Sie die Funktion Speicher-Repository reparieren, anstatt die SR zu entfernen und neu zu erstellen.

Thin bereitgestellter gemeinsam genutzter GFS2-Blockspeicher

Thin Provisioning nutzt den verfügbaren Speicher besser, indem VDIs Speicherplatz zugewiesen wird, wenn Daten auf das virtuelle Laufwerk geschrieben werden, anstatt die volle virtuelle Größe des VDIs im Voraus zuzuweisen. Mit der Thin Provisioning können Sie den benötigten Speicherplatz für ein gemeinsam genutztes Speicher-Array und damit Ihre Total Cost of Ownership (TCO) erheblich reduzieren.

Die Thin Provisioning für Shared Block Storage ist in folgenden Fällen von besonderem Interesse:

  • Sie wollen mehr Platzeffizienz. Bilder sind dünn und nicht dick zugeordnet.
  • Sie möchten die Anzahl der E/A-Vorgänge pro Sekunde auf Ihrem Speicher-Array reduzieren. Der GFS2 SR ist der erste SR-Typ, der Speicherlesecaching auf Shared Block Storage unterstützt.
  • Sie verwenden ein gemeinsames Basisabbild für mehrere virtuelle Maschinen. Die Images einzelner VMs verbrauchen dann in der Regel noch weniger Speicherplatz.
  • Sie verwenden Schnappschüsse. Jeder Snapshot ist ein Bild, und jedes Bild ist jetzt dünn.
  • Ihr Speicher unterstützt NFS nicht und unterstützt nur Blockspeicher. Wenn Ihr Speicher NFS unterstützt, empfehlen wir, 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.

Der freigegebene GFS2-Typ stellt Datenträger als Dateisystem dar, das auf einer iSCSI- oder HBA-LUN erstellt wurde. VDIs, die auf einem GFS2 SR gespeichert sind, werden im QCOW2-Bildformat gespeichert.

Um gemeinsam genutzten GFS2-Speicher zu verwenden, muss der Citrix Hypervisor Ressourcenpool ein Clusterpool sein. Aktivieren Sie Clustering in Ihrem Pool, bevor Sie eine GFS2 SR erstellen. Weitere Informationen finden Sie unter Cluster-Pools.

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

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

Einschränkungen

Shared GFS2-Speicher weist derzeit folgende Einschränkungen auf:

  • Die VM-Migration mit Speicher-Livemigration wird für VMs, deren VDIs sich auf einem GFS2 SR befinden, nicht unterstützt.
  • Das FCoE-Protokoll wird von GFS2 SRs nicht unterstützt.
  • Trim/Unmap wird auf GFS2 SRs nicht unterstützt.
  • Leistungsmetriken sind für GFS2 SRs und Festplatten auf diesen SRs nicht verfügbar.
  • Die geänderte Blockverfolgung wird für VDIs, die auf GFS2 SRs gespeichert sind, nicht unterstützt.
  • VDIs, die größer als 2 TiB sind, können nicht als VHD oder OVA/OVF exportiert werden. Sie können jedoch VMs mit VDIs größer als 2 TiB im XVA-Format exportieren.

Hinweis:

Vorgänge auf GFS2 SRs können hängen bleiben, wenn Sie einen IP-Adresskonflikt (mehrere Hosts mit derselben IP-Adresse) in Ihrem Clusternetzwerk haben, auf dem mindestens ein Host mit aktiviertem Clustering beteiligt ist. In diesem Fall werden die Hosts nicht umzäunt. Um dieses Problem zu beheben, beheben Sie den IP-Adresskonflikt.

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

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

Alternativ können Sie die xe CLI verwenden, um eine 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 die SR hostet Ja
SCSIid SCSI-ID des Geräts Ja

Sie können die Werte finden, die für diese Parameter verwendet werden sollen, indem Sie denxe sr-probe-ext Befehl verwenden.

xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
  1. Starten Sie mit dem folgenden Befehl:

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

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

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

  3. Wenn die Befehlsausgabe mit beginnt The following SRs were found:, können Sie die device-config Parameter verwenden, die Sie angegeben haben, um die SR beim Ausführen des xe sr-create Befehls zu suchen.

Führen Sie den folgenden Befehl auf einem Server in Ihrem Clusterpool aus, um eine freigegebene GFS2-SR auf einer bestimmten LUN eines iSCSI-Ziels zu erstellen:

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 gemountet sind, können einige Hosts im Clusterpool einen Zaun aufweisen.

Weitere Hinweise zum Arbeiten mit iSCSI-SRs finden Sie unterSoftware-iSCSI-Unterstützung.

Erstellen eines gemeinsam genutzten GFS2 über HBA SR

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

Alternativ können Sie die xe CLI verwenden, um eine 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 Werte finden, die für den Parameter SCSIID verwendet werden sollen, indem Sie denxe sr-probe-ext Befehl verwenden.

xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
  1. Starten Sie mit dem folgenden Befehl:

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

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

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

  3. Wenn die Befehlsausgabe mit beginnt The following SRs were found:, können Sie die device-config Parameter verwenden, die Sie angegeben haben, um die SR beim Ausführen des xe sr-create Befehls zu suchen.

Um eine freigegebene 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 Hinweise zum Arbeiten mit HBA-SRs finden Sie unterHardware-Hostbusadapter.

NFS und SMB

Freigaben auf NFS-Servern (die NFSv4 oder NFSv3 unterstützen) oder auf SMB-Servern (die SMB 3.0 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, Folgendes:

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

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

Wichtig:

  • Die Unterstützung für SMB 3.0 beschränkt sich auf die Möglichkeit, eine Verbindung mit einer Freigabe mithilfe des 3.0-Protokolls herzustellen. Zusätzliche Funktionen wie Transparent Failover hängen von der Feature-Verfügbarkeit im Upstream-Linux-Kernel ab und werden in Citrix Hypervisor 8.0 nicht unterstützt.
  • Für NFSv4AUTH_SYS wird nur der Authentifizierungstyp unterstützt.
  • SMB-Speicher ist für Citrix Hypervisor Premium Edition-Kunden oder Kunden verfügbar, die über ihre Citrix Virtual Apps und Desktops Zugriff auf Citrix Hypervisor haben.

VDIs, die auf dateibasierten SRs gespeichert sind, werden dünn bereitgestellt. Die Image-Datei wird zugewiesen, wenn 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 belegen, wie es erforderlich ist. Wenn beispielsweise ein VDI mit 100 GB für eine VM zugewiesen wird und ein Betriebssystem installiert ist, spiegelt die VDI-Datei nur die Größe der auf den Datenträger geschriebenen Betriebssystemdaten statt der gesamten 100 GB wider.

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, verwenden die resultierenden VMs die gemeinsamen Daten auf der Festplatte zum Zeitpunkt des Klonens. 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 die Inhalte von VDIs beschädigt werden können.

Citrix Hypervisor wurde für Massenspeicher der Enterprise-Klasse optimiert, der nicht-flü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 umfassend gegen Network Appliance FAS2020- und FAS3210-Speicher getestet.

Warnhinweis:

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 or-Server erzwingen nicht, dass der für VDIs auf dateibasierten SRs erforderliche Speicherplatz vorhanden ist.

Erstellen eines freigegebenen NFS-SR (NFS)

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 jedem gültigen Zielpfad erstellen. Verwenden Sie densr-probe Befehl, um eine Liste gültiger Zielpfade anzuzeigen, die vom Server exportiert werden.

In Szenarien, in denen Citrix Hypervisor mit Lower-End-Speicher verwendet wird, wird vorsichtig darauf gewartet, dass alle Schreibvorgänge bestätigt werden, bevor Bestätigungen an VMs übergeben werden. Dieser Ansatz verursacht spürbare Performance-Kosten und kann gelöst werden, indem der Speicher so eingestellt wird, dass der SR-Bereitstellungspunkt als asynchronen Modus exportiert wird. Asynchrone Exporte bestätigen Schreibvorgänge, die sich nicht auf der Festplatte befinden. Berücksichtigen Sie die Risiken des Scheiterns in diesen Situationen sorgfältig.

Hinweis:

Der NFS-Server muss so konfiguriert sein, dass er den angegebenen Pfad auf alle Server im Pool exportiert. Wenn diese Konfiguration nicht erfolgt, schlägt die Erstellung des SR und das Einstecken des PBD-Datensatzes 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 ein Leistungsvorteil besteht. Geben Sie für diese Konfiguration beim Erstellen einer SR dendevice-config Parameter anuseUDP=true .

Gerätekonfigurationsparameter für NFS-SRs:

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

Verwenden Sie beispielsweise den folgenden Befehl, um einen freigegebenen NFS-SR auf192.168.1.10:/export1zu erstellen:

    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 \
    nfsversion="3", "4"

Führen Sie den folgenden Befehl aus, um einen nicht freigegebenen NFS-SR 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 \
    nfsversion="3", "4"

Erstellen eines gemeinsam genutzten SMB-SR (SMB)

Geben Sie zum Erstellen einer SMB-SR den Hostnamen oder die IP-Adresse des SMB-Servers, den vollständigen Pfad der exportierten Freigabe und die entsprechenden Anmeldeinformationen ein.

Hinweis:

SMB SR wurde gegen Network Appliance-Speicher getestet, auf denen OnTap 8.3 und Windows Server 2012 R2 ausgeführt wird.

Gerätekonfigurationsparameter für SMB-SRs:

Parametername Beschreibung Erforderlich?
server Vollständiger Pfad zur Freigabe auf dem Server Ja
username Benutzerkonto mit RW-Zugriff auf Freigabe Optional
password Passwort für das Benutzerkonto Optional

Verwenden Sie beispielsweise den folgenden Befehl, um eine gemeinsam genutzte SMB-SR auf192.168.1.10:/share1zu erstellen:

    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=valid_password type=smb

Führen Sie den folgenden Befehl aus, um eine nicht gemeinsam genutzte 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=valid_password type=smb

Hinweis:

Wenn Sie den sr-create Befehl ausführen, können Sie das device-config:password_secret Argument verwenden, anstatt das Kennwort in der Befehlszeile anzugeben. Weitere Informationen finden Sie unter Geheimnisse.

LVM über Hardware-HBA

Der HBA-Typ „LVM over Hardware“ stellt Festplatten als VHDs auf logischen Volumes innerhalb einer Volumegruppe dar, die auf einer HBA-LUN erstellt wurde, die beispielsweise hardwarebasierte iSCSI- oder FC-Unterstützung bietet.

Citrix Hypervisor or-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 machen, muss manuell abgeschlossen werden. Diese Konfiguration umfasst Speichergeräte, Netzwerkgeräte und den HBA innerhalb des Citrix Hypervisor or-Servers. Nachdem die gesamte FC-Konfiguration abgeschlossen ist, stellt der HBA ein von der FC-LUN gesichertes SCSI-Gerät für den Host bereit. 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 densr-probe Befehl, 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 vonsr-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 freigegebene SRs erstellt werden, auf die alle Hosts in einem Ressourcenpool zugreifen können.

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

Weitere InformationenErstellen von Speicher-Repositorieszum Erstellen freigegebener HBA-basierter FC- und iSCSI-SRs finden Sie unter.

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 Host zugeordnet und für die Verwendung in einer SR angegeben werden. VDIs innerhalb der SR werden VMs als Standardblockgeräte verfügbar gemacht.