Erstellen eines Speicher-Repositorys

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

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

Alle XenServer SR-Typen unterstützen VDI-Größenänderung, schnelles Klonen und Snapshot. SRs basierend auf dem LVM SR-Typ (lokal, iSCSI oder HBA) bieten Thin Provisioning für Snapshots und versteckte übergeordnete Knoten, jedoch nicht für andere Datenträger, wie etwa MCS-Delta-Datenträger pro VM. Die anderen SR-Typen (EXT3/EXT4, NFS, GFS2) unterstützen vollständiges Thin Provisioning, auch für aktive virtuelle Festplatten.

Warnungen:

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

• XenServer unterstützt für keinen SR-Typ Snapshots auf der externen SAN-Ebene einer LUN.

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

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

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

Lokale LVM

Der Typ Lokaler LVM stellt Festplatten innerhalb einer lokal angeschlossenen Datenträgergruppe dar. Wir empfehlen, nur einen lokalen SR pro Host anzuschließen.

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

Hinweis:

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

Überlegungen zur LVM-Leistung

Die Snapshot- und Fast-Clone-Funktionalität für LVM-basierte SRs ist mit einem inhärenten Performance-Overhead verbunden. Wenn optimale Leistung erforderlich ist, unterstützt XenServer zusätzlich zum Standard-VHD-Format die Erstellung von VDIs im Raw-Format . Die XenServer-Snapshot-Funktionalität wird auf Raw-VDIs nicht unterstützt.

Warnung:

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

Erstellen einer lokalen LVM-SR

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

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

Um einen lokalen LVM SR auf /dev/disk/<id>zu erstellen, verwenden Sie den folgenden Befehl.

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

Lokale EXT3/EXT4

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

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

Lokale EXT3/EXT4-SRs der Festplatte müssen mithilfe der XenServer-CLI konfiguriert werden.

Ob ein lokaler EXT SR EXT3 oder EXT4 verwendet, hängt davon ab, mit welcher Version von XenServer er erstellt wurde:

• Wenn Sie den lokalen EXT SR auf einer früheren Version von Citrix Hypervisor oder XenServer erstellt und dann auf XenServer 8.4 aktualisiert haben, verwendet er EXT3.
• Wenn Sie den lokalen EXT SR auf XenServer 8.4 erstellt haben, verwendet er EXT4.

Hinweis:

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

Beim Erstellen einer lokalen EXT4-SR (Extern)

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

Um einen lokalen EXT4 SR auf /dev/disk/<id>zu erstellen, verwenden Sie den folgenden Befehl:

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

Lokales XFS

Die Verwendung von XFS ermöglicht Thin Provisioning auf lokalem Speicher. Mit dem lokalen XFS-Typ können Sie lokale Speichergeräte mit 4 KB großen physischen Blöcken erstellen, ohne dass eine logische Blockgröße von 512 Byte erforderlich ist.

Einschränkungen

Für XFS SRs gelten die folgenden Einschränkungen:

• Die Speicher-Livemigration kann nicht auf VMs verwendet werden, deren VDIs sich auf einem XFS SR befinden.

• Intellicache wird für VMs, die ein XFS SR verwenden, nicht unterstützt.

• Der Software-FCoE-Transport wird mit XFS SRs nicht unterstützt (für vollständig entlastetes FCoE verwenden Sie HBA).

• Trimmen/Unmap wird auf XFS SRs nicht unterstützt.

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

Erstellen eines lokalen XFS SR

Gerätekonfigurationsparameter für XFS SRs:

Um einen lokalen XFS SR auf /dev/disk/<id>zu erstellen, verwenden Sie den folgenden Befehl:

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

udev

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

XenServer hat zwei SRs vom Typ udev, die Wechselspeicher darstellen. Eine ist für die CD- oder DVD-Disk im physischen CD- oder DVD-ROM-Laufwerk des XenServer-Hosts. Das andere ist für ein USB-Gerät, das an einen USB-Port des XenServer-Hosts angeschlossen ist. VDIs, die die Medien darstellen, kommen und gehen, wenn Festplatten oder USB-Sticks eingesteckt und entfernt werden.

ISO

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

Die folgenden ISO SR-Typen sind verfügbar:

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

Wenn Sie den für den SR zu verwendenden Speichertyp nicht angeben, verwendet XenServer den Gerätekonfigurationsparameter Standort , um den Typ zu bestimmen.

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

Hinweis:

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

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

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

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

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

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

Software-iSCSI-Unterstützung

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

Die gemeinsame iSCSI-Unterstützung mit der Software iSCSI-Initiator wird auf Basis des Linux Volume Manager (LVM) implementiert. Diese Funktion bietet die gleichen Leistungsvorteile, die LVM-VDIs im Fall der lokalen Festplatte bieten. Gemeinsam genutzte iSCSI SRs mit dem softwarebasierten Hostinitiator können die VM-Agilität durch Livemigration unterstützen: VMs können auf jedem XenServer-Host in einem Ressourcenpool gestartet und ohne merkliche Ausfallzeiten zwischen ihnen migriert werden.

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

Hinweis:

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

iSCSI-Konfiguration des XenServer-Hosts

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

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

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

Hinweis:

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

Der IQN-Wert des XenServer-Hosts kann mithilfe von XenCenter oder mithilfe der CLI mit dem folgenden Befehl angepasst werden, wenn der iSCSI-Softwareinitiator verwendet wird:

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

Warnung:

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

Software-FCoE-Speicher (veraltet)

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

Hinweis:

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

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

Hinweis:

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

Erstellen einer Software-FCoE-SR

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

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

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

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

Hardware-Host-Bus-Adapter (HBAs)

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

Konfigurationstools von Drittanbietern

Frühere Versionen von Citrix Hypervisor und XenServer enthielten Tools von Drittanbietern zur Verwaltung des Hardware-HBA-Speichers. Diese Tools sind nicht mehr im Lieferumfang enthalten, können aber von der Website des Hardwareanbieters heruntergeladen werden. Weitere Informationen finden Sie unter Änderungen an Komponenten von Drittanbietern.

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

Hinweis:

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

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

1. Verwenden Sie sr-forget oder sr-destroy , um den SR aus der XenServer-Hostdatenbank zu entfernen. Weitere 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 Server.

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

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

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

Warnung:

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

Gemeinsamer LVM-Speicher

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

Hinweis:

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

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

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

Hinweis:

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

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

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

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

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

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

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

1. Zonen Sie für jeden XenServer-Host im Pool eine oder mehrere LUNs ein. Dieser Prozess ist sehr spezifisch für die verwendeten SAN-Geräte. Weitere Informationen finden Sie in der SAN-Dokumentation.

2. Konfigurieren Sie den HBA bei Bedarf mithilfe von Drittanbietertools im BIOS oder in der Firmware.

   • Informationen zum Konfigurieren von QLogic Fibre Channel- und iSCSI-HBAs finden Sie auf der Marvell -Website.
   • Informationen zum Konfigurieren von Emulex Fibre Channel-HBAs finden Sie auf der Broadcom -Website.

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

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

   Wenn mehrere LUNs vorhanden sind, verwenden Sie den Hersteller, die LUN-Größe, die LUN-Seriennummer oder die SCSI-ID aus dem <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 den SR im Poolkoordinator. Geben Sie den globalen Gerätepfad an, der in der <path> Immobilien ab SR-Sonde. PBDs werden automatisch für jeden Host im Pool erstellt und angeschlossen.

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

Hinweis:

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

Thin-Provisioning-Shared-GFS2-Blockspeicher

Beim Thin Provisioning wird der verfügbare Speicher besser genutzt, indem den VDIs beim Schreiben von Daten auf die virtuelle Festplatte Speicherplatz zugewiesen wird, anstatt die volle virtuelle Größe der VDI im Voraus zuzuweisen. Thin Provisioning ermöglicht es Ihnen, den Speicherplatzbedarf auf einem gemeinsam genutzten Speicher-Array und damit Ihre Gesamtbetriebskosten (TCO) erheblich zu reduzieren.

Thin Provisioning für Shared Block Storage ist in folgenden Fällen besonders interessant:

• Sie möchten die Flächeneffizienz steigern. Die Bilder sind spärlich 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 Storage Read Caching auf gemeinsam genutztem Blockspeicher unterstützt.
• Sie verwenden ein gemeinsames Basisimage für mehrere virtuelle Maschinen. Die Images einzelner VMs belegen dann in der Regel noch weniger Speicherplatz.
• Sie verwenden Snapshots. 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 statt 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:

Es wird empfohlen, eine GFS2-SR nicht mit einem VLAN zu verwenden, da ein bekanntes Problem auftritt, bei dem Sie Hosts in einem Cluster-Pool nicht hinzufügen oder entfernen können, wenn sich das Cluster-Netzwerk in einem Nicht-Management-VLAN befindet.

Der gemeinsam genutzte GFS2 SR-Typ erstellt ein GFS2-Dateisystem auf einem iSCSI- oder HBA-LUN. VDIs werden im GFS2 SR als Dateien im QCOW2-Bildformat gespeichert.

Weitere Informationen zur Verwendung von GFS2-Speicher finden Sie unter Thin-Provisioning-gemeinsam genutzter GFS2-Blockspeicher.

NFS und SMB

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

• VMs, die auf beliebigen XenServer-Hosts in einem Ressourcenpool gestartet werden sollen

• VM-Migration zwischen XenServer-Hosts in einem Ressourcenpool mittels Live-Migration (ohne spürbare Ausfallzeiten)

Wichtig:

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

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

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

Hinweis:

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

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

XenServer wurde für Speicher der Enterprise-Klasse optimiert, der nichtflüchtigen RAM verwendet, um schnelle Bestätigungen von Schreibanforderungen bereitzustellen und gleichzeitig ein hohes Maß an Datensicherheit vor Fehlern zu gewährleisten. XenServer wurde umfassend mit den Speichersystemen Network Appliance FAS2020 und FAS3210 unter Verwendung von Data OnTap 7.3 und 8.1 getestet.

Warnung:

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

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

Erstellen eines freigegebenen NFS SR (NFS)

Hinweis:

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

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

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

Hinweis:

Der NFS-Server muss so konfiguriert sein, dass er den angegebenen Pfad zu allen Hosts im Pool exportiert. Wird diese Konfiguration nicht vorgenommen, schlägt das Anlegen der SR und das Einstecken des PBD-Eintrags fehl.

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

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

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

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

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

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

Erstellen eines freigegebenen SMB SR (SMB)

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

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

Hinweis:

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

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

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

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

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

LVM über Hardware-HBA

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

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

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

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

Weitere Informationen zum Erstellen gemeinsam genutzter HBA-basierter FC- und iSCSI-SRs finden Sie unter „Speicher-Repositories erstellen“ .

Hinweis:

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

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