Citrix Hypervisor

Formate des Speicher-Repository

Sie können den Assistenten für neues Speicherrepository in XenCenter verwenden, um Speicherrepositories zu erstellen. Der Assistent führt Sie durch die Konfigurationsschritte. Verwenden Sie alternativ die CLI und den sr-create Befehl. Der sr-create Befehl erstellt eine 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 SR wird die PBD automatisch angeschlossen. Wenn das SR-Flag auf shared=truegesetzt 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 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.

  • Wenn Sie Thin Provisioning auf einer dateibasierten SR verwenden, stellen Sie sicher, dass Sie den freien Speicherplatz auf Ihrer 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:

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

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 einer lokalen LVM SR

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

Die Gerätekonfigurationsparameter für LVM SRs sind:

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

Verwenden Sie den 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
<!--NeedCopy-->

Lokales 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 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 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 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 einer lokalen EXT4 SR (ext)

Gerätekonfigurationsparameter für Ext-SRs:

Parametername Beschreibung Erforderlich?
Gerät 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 EXT4 SR auf 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 udev-Typ steht für Geräte, die mit dem udev-Gerätemanager als VDIs angeschlossen sind.

Citrix Hypervisor verfügt über zwei SRs des Typs udev, die Wechselmedien 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. Für Speicherrepositories, die eine ISO-Bibliothek speichern, muss der Parameter content-type auf iso gesetzt werden.

Beispiel:

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

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=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"
<!--NeedCopy-->

Hinweis:

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

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 genutzte 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 mithilfe der 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

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.

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 einer Software-FCoE SR

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

Die Gerätekonfigurationsparameter 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 gemeinsame 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 einer 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 die 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:

Parametername Beschreibung Erforderlich?
target Die IP-Adresse oder der Hostname des iSCSI-Filers, der die SR hostet. Dies kann auch eine kommagetrennte Werteliste sein. Ja
targetIQN Die IQN-Zieladresse des iSCSI-Filers, der die SR hostet Ja
SCSIid Die SCSI-Bus-ID der Ziel-LUN Ja
chapuser Der für die CHAP-Authentifizierung zu verwendende Benutzername Nein
chappassword Das für die CHAP-Authentifizierung zu verwendende Kennwort Nein
port Die Netzwerkportnummer, auf der das Ziel abgefragt werden soll Nein
usediscoverynumber Der zu verwendende iSCSI-Record-Index Nein
incoming_chapuser Der Benutzername, den der iSCSI-Filter verwendet, um sich gegen den Host zu authentifizieren. 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
<!--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:

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 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 sr-probe Befehl erzwingt einen erneuten Scan 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 host-uuid Parameter an, 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 SR als Wert für den device-config:device Parameter 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 den 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 und das Einstecken von Teilen des sr-create Vorgangs erneut zu versuchen. 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 die SR erstellt wurde. Korrigieren Sie das Zoning für die betroffenen Hosts und verwenden Sie die Funktion „Speicherrepository reparieren“, anstatt die 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 dünn und nicht dick zugeordnet.
  • Sie möchten die Anzahl der I/O-Vorgänge pro Sekunde auf Ihrem Speicher-Array reduzieren. Der 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.

Der gemeinsam genutzte 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-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 eine GFS2 SR erstellen. Weitere Informationen finden Sie unter Clustered-Pools.

Stellen Sie sicher, dass Storage-Multipathing zwischen Ihrem Cluster-Pool 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.

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.

  • Die VM-Migration mit Speicher-Livemigration wird nicht für VMs unterstützt, deren VDIs sich auf einer GFS2 SR befinden. Sie können auch keine VDIs von einem anderen SR-Typ auf eine GFS2 SR migrieren.

  • Das FCoE-Protokoll 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.

Hinweis:

Vorgänge auf GFS2-SRs können hängen bleiben, 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. In diesem Fall fechten die Hosts nicht ein. Um dieses Problem zu beheben, lösen 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 unter 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

Mit dem Befehl xe sr-probe-ext können Sie die Werte finden, die für diese Parameter verwendet werden sollen.

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 The following SRs were found: beginnt, können Sie die Parameter device-config verwenden, die Sie angegeben haben, um die SR beim Ausführen des Befehls xe sr-create zu suchen.

Um eine gemeinsam genutzte GFS2 SR auf einer bestimmten LUN eines iSCSI-Ziels zu erstellen, führen Sie den folgenden Befehl auf einem Server in Ihrem Cluster-Pool 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 eine GFS2 über HBA SR zu erstellen.

Gerätekonfigurationsparameter für GFS2 SRs:

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

Sie finden die Werte, die für den Parameter SCSIid verwendet werden sollen, indem Sie den Befehl xe sr-probe-ext verwenden.

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 The following SRs were found: beginnt, können Sie die Parameter device-config verwenden, die Sie angegeben haben, um die SR beim Ausführen des Befehls xe sr-create zu suchen.

Um eine gemeinsam genutzte GFS2 SR auf einer bestimmten LUN eines HBA-Ziels zu erstellen, führen Sie den folgenden Befehl auf einem Server in Ihrem Cluster-Pool 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.

NFS und SMB

Freigaben auf NFS-Servern (die 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, 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.
  • 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.

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 einer gemeinsam genutzten 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 den sr-probe Befehl, 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 die Erstellung der SR 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 einer SR den device-config Parameter an useUDP=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-Einhängepunkts, zum NFS-Server, der die SR hostet Ja

Um beispielsweise eine freigegebene NFS-SR auf zu erstellen 192.168.1.10:/export1, verwenden Sie 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 \
    nfsversion="3", "4"
<!--NeedCopy-->

Führen Sie den folgenden Befehl aus, um eine nicht gemeinsam genutzte 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"
<!--NeedCopy-->

Erstellen einer gemeinsam genutzten 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.

Gerätekonfigurationsparameter für SMB SRs:

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

Um beispielsweise eine gemeinsam genutzte SMB-SR auf zu erstellen 192.168.1.10:/share1, 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=valid_password type=smb
<!--NeedCopy-->

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

Hinweis:

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

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 sr-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 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 einer SR angegeben werden. VDIs innerhalb der SR 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