Erstellen Sie ein Speicher-Repository

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

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

Alle XenServer SR-Typen unterstützen 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.

• 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 verfügbar macht, die kleiner oder gleich 255 ist, bevor Sie diese LUN verwenden, um eine SR zu erstellen.

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

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

Lokales LVM

Der Typ Local LVM stellt Datenträger innerhalb einer lokal angeschlossenen Volume-Gruppe dar.

Standardmäßig verwendet XenServer den lokalen Datenträger auf dem physischen Host, auf dem sie 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 physischen Blöcken von 4 KB zu verwenden, muss der Speicher auch die Emulation von 512-Byte-Zuweisungsblöcken unterstützen (die logische Blockgröße muss 512 Byte betragen).

Überlegungen zur LVM-Leistung

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

Warnung:

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

Erstellen eines lokalen LVM SRs

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

Die Gerätekonfigurationsparameter für LVM SRs sind:

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

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

Lokales EXT3/EXT4

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

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

Lokale Datenträger EXT3/EXT4 SRs müssen mit 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 aktualisiert haben, verwendet er EXT3.
• Wenn Sie den lokalen EXT-SR auf XenServer 8 erstellt haben, verwendet er EXT4.

Hinweis:

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

Erstellen eines lokalen EXT4 SR (ext)

Gerätekonfigurationsparameter für EXT SRs:

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

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

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 physischen Blöcken von 4 KB erstellen, ohne dass eine logische Blockgröße von 512 Byte erforderlich ist.

Erstellen einer lokalen XFS-SR

Gerätekonfigurationsparameter für XFS-SRs:

Verwenden Sie den folgenden Befehl, um eine lokale XFS-SR auf /dev/sdb zu erstellen:

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

udev

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

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

ISO-Image

Der ISO-Typ verarbeitet CD-Images, die als Dateien im ISO-Format gespeichert sind. Dieser SR-Typ eignet sich zum Erstellen gemeinsam genutzter ISO-Bibliotheken.

Die folgenden ISO-SR-Typen sind verfügbar:

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

locationWenn Sie den Speichertyp, der für die SR verwendet werden soll, nicht angeben, verwendet XenServer den Gerätekonfigurationsparameter, um den Typ zu bestimmen.

Gerätekonfigurationsparameter für ISO-SRs:

Hinweis:

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

Für Speicher-Repositorys, die eine Bibliothek von ISOs speichern, muss der Parameter content-type beispielsweise auf iso festgelegt werden. Beispiel:

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

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

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

     xe sr-create content-type=iso type=iso shared=true device-config:location=<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 Open-iSCSI-Software-iSCSI-Initiator oder mit einem unterstützten iSCSI-Hostbusadapter (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 Agilität von VMs mithilfe der Live-Migration 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 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 physischen Blöcken von 4 KB zu verwenden, muss der Speicher auch die Emulation von 512-Byte-Zuweisungsblöcken unterstützen (die logische Blockgröße muss 512 Byte betragen).

XenServer-Host-iSCSI-Konfiguration

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.

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 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 XenServer-Host zugreift, müssen so konfiguriert sein, dass sie den Zugriff durch den Initiator-IQN des Hosts zulassen. 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 für mehrere Hosts in einem Pool verwendet wird, stellen Sie sicher, dass der Multiinitiatorzugriff für die angegebene LUN aktiviert ist.

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

Software-FCoE-Speicher (veraltet)

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

Hinweis:

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

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

Hinweis:

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

Erstellen eines Software-FCoE SRs

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

Die Gerätekonfigurationsparameter für FCoE SRs sind:

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

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

Hardware-Hostbusadapter (HBAs)

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

Beispiel für eine QLogic iSCSI HBA-Einrichtung

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

Sobald der HBA physisch auf dem XenServer-Host installiert ist, konfigurieren Sie den HBA mit den folgenden Schritten:

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

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

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

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

3. Verwenden Sie den xe-Befehl sr-probe, um eine erneute Suche des HBA-Controller zu erzwingen und verfügbare LUNs anzuzeigen. Weitere Informationen finden Sie unter Sondieren eines SR und Erstellen eines gemeinsam genutzten LVM über Fibre-Channel/ Fibre-Channel über Ethernet/ iSCSI HBA oder SAS SR.

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

Hinweis:

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

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

1. Verwenden Sie sr-forget oder nach sr-destroy Bedarf, um die SR aus der XenServer-Hostdatenbank 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 physischen Blöcken von 4 KB zu verwenden, muss der Speicher auch die Emulation von 512-Byte-Zuweisungsblöcken unterstützen (die logische Blockgröße muss 512 Byte betragen).

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

Gerätekonfigurationsparameter für LVMoiSCSI SRs:

Hinweis:

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

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

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

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

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

Gerätekonfigurationsparameter für LVMoHBA SRs:

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

1. Zonieren Sie jedem XenServer-Host im Pool eine oder mehrere LUNs. 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 XenServer-Host enthaltene HBA-CLI, um den HBA zu konfigurieren:

   • Emulex: /bin/sbin/ocmanager

   • QLogic FC: /opt/QLogic_Corporation/SANsurferCLI

   • QLogic iSCSI: /opt/QLogic_Corporation/SANsurferiCLI

   Ein Beispiel für die QLogic iSCSI-HBA-Konfiguration finden Sie unter Hardware-Host-Busadapter (HBAs) im vorherigen Abschnitt. Weitere Informationen zu Fibre-Channel- und iSCSI-HBAs finden Sie auf den Websites Broadcom und Cavium .

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

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

   Wenn mehrere LUNs vorhanden sind, verwenden Sie den Anbieter, die LUN-Größe, die LUN-Seriennummer oder die SCSI-ID der <path>-Eigenschaft, um die gewünschte LUN zu identifizieren.

       xe sr-probe type=lvmohba \
       host-uuid=1212c7b3-f333-4a8d-a6fb-80c5b79b5b31
       Error code: SR_BACKEND_FAILURE_90
       Error parameters: , The request is missing the device parameter, \
       <?xml version="1.0" ?>
       <Devlist>
           <BlockDevice>
               <path>
                   /dev/disk/by-id/scsi-360a9800068666949673446387665336f
               </path>
               <vendor>
                   HITACHI
               </vendor>
               <serial>
                   730157980002
               </serial>
               <size>
                   80530636800
               </size>
               <adapter>
                   4
               </adapter>
               <channel>
                   0
               </channel>
               <id>
                   4
               </id>
               <lun>
                   2
               </lun>
               <hba>
                   qla2xxx
               </hba>
           </BlockDevice>
           <Adapter>
               <host>
                   Host4
               </host>
               <name>
                   qla2xxx
               </name>
               <manufacturer>
                   QLogic HBA Driver
               </manufacturer>
               <id>
                   4
               </id>
           </Adapter>
       </Devlist>
   <!--NeedCopy-->
   

4. Erstellen Sie auf dem Poolkoordinator 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 neu zu versuchen und Teile des Vorgangs sr-create zu blockieren. Diese Funktion kann in Fällen nützlich sein, in denen das LUN-Zoning für einen oder mehrere Hosts in einem Pool nicht korrekt war, als das SR erstellt wurde. Korrigieren Sie das Zoning für die betroffenen Hosts und verwenden Sie die Funktion “Speicherrepository reparieren”, anstatt das SR zu entfernen und neu zu erstellen.

Gemeinsam genutzter GFS2-Blockspeicher mit Thin-Provisioning

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

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

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

Hinweis:

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

Der gemeinsam genutzte GFS2-SR-Typ erstellt ein GFS2-Dateisystem auf einer 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 Gemeinsam genutzter GFS2-Blockspeicher mit Thin-Provisioning.

NFS und SMB

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

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

• VM-Migration zwischen XenServer-Hosts in einem Ressourcenpool mithilfe der Livemigration (ohne merkliche 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 Transparent Failover hängen von der Funktionsverfügbarkeit im Upstream-Linux-Kernel ab und werden in XenServer 8 nicht unterstützt.
• Clustered SMB wird von XenServer nicht unterstützt.
• Für NFSv4 wird nur der Authentifizierungstyp AUTH_SYS 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 für unabhängige Netzwerk-Switches mit redundanter Stromversorgung.
• Wenn Sie SMB-Speicher verwenden, entfernen Sie die Freigabe nicht aus dem Speicher, bevor Sie den SMB-SR trennen.

VDIs, die auf dateibasierten SRs gespeichert sind, werden dünn bereitgestellt. Die Image-Datei wird zugewiesen, während die VM Daten auf den Datenträger schreibt. Dieser Ansatz hat den erheblichen Vorteil, dass die VM-Image-Dateien nur so viel Speicherplatz auf dem Speicher beanspruchen, wie erforderlich ist. Wenn beispielsweise ein 100-GB-VDI für eine VM zugewiesen ist und ein Betriebssystem installiert ist, spiegelt die VDI-Datei nur die Größe der auf den Datenträger geschriebenen Betriebssystemdaten wider und nicht die gesamten 100 GB.

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

Hinweis:

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

Dateibasierte SRs- und VHD-Implementierungen in XenServer 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.

XenServer wurde für Speicher der Enterprise-Klasse optimiert, der nichtflüchtiges RAM verwendet, um Schreibanforderungen schnell zu bestätigen und gleichzeitig ein hohes Maß an Datenschutz vor Ausfällen zu gewährleisten. XenServer 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. 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 Ihrem SR überwachen. Wenn die SR-Nutzung auf 100% ansteigt, schlagen weitere Schreibvorgänge von VMs fehl. Diese fehlgeschlagenen Schreibvorgänge können zum Einfrieren oder Absturz der VM führen.

Erstellen eines gemeinsam genutzten NFS-SR (NFS)

Hinweis:

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

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

In Szenarien, in denen XenServer mit Low-End-Speicher verwendet wird, wartet es vorsichtig, bis alle Schreibvorgänge bestätigt wurden, 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 Hosts im Pool exportiert. Wenn diese Konfiguration nicht erfolgt, schlägt das Erstellen des SRs und das Einstecken des PBD-Datensatzes fehl.

Die XenServer NFS-Implementierung verwendet standardmäßig TCP. Wenn es Ihre Situation zulässt, können Sie die Implementierung so konfigurieren, dass UDP in Szenarien verwendet wird, in denen möglicherweise ein Leistungsvorteil besteht. Um diese Konfiguration durchzuführen, geben Sie beim Erstellen eines SR den Parameter device-config mit useUDP=true an.

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

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

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

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

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

Erstellen eines gemeinsam genutzten SMB-SRs (SMB)

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

Gerätekonfigurationsparameter für SMB SRs:

Hinweis:

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

Um beispielsweise ein gemeinsam genutztes SMB-SR auf 192.168.1.10:/share1 zu erstellen, verwenden Sie den folgenden Befehl:

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

Führen Sie den folgenden Befehl aus, um ein nicht gemeinsam genutztes SMB-SR zu erstellen:

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

LVM über Hardware HBA

Der LVM-über-Hardware-HBA-Typ stellt Datenträger als VHDs auf logischen Volumes innerhalb einer Volume-Gruppe dar, die auf einer HBA-LUN erstellt wurde und beispielsweise hardwarebasierte iSCSI- oder FC-Unterstützung bietet.

XenServer-Hosts 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 XenServer-Hosts. Nachdem die gesamte FC-Konfiguration abgeschlossen ist, macht der HBA ein von der FC-LUN unterstütztes SCSI-Gerät für den Host verfügbar. Das SCSI-Gerät kann dann für den Zugriff auf die FC-LUN verwendet werden, als wäre es ein lokal angeschlossenes SCSI-Gerät.

Verwenden Sie den Befehl sr-probe, um die LUN-unterstützten SCSI-Geräte aufzulisten, die auf dem Host vorhanden sind. Dieser Befehl erzwingt einen Scan nach neuen LUN-gestützten SCSI-Geräten. Der von sr-probe für ein LUN-gestütztes SCSI-Gerät zurückgegebene Pfadwert ist auf allen Hosts mit Zugriff auf die LUN konsistent. Daher muss dieser Wert verwendet werden, wenn gemeinsam genutzte SRs erstellt werden, auf die alle Hosts in einem Ressourcenpool zugreifen können.

Dieselben Funktionen gelten für QLogic iSCSI-HBAs.

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

Hinweis:

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

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