layout: doc description: Create and manage storage repositories in your XenServer environment.—

Verwalten von Speicherrepositories

In diesem Abschnitt wird beschrieben, wie Speicher-Repository-Typen erstellt und für Ihren XenServer-Host verfügbar gemacht werden. Es deckt auch verschiedene Vorgänge ab, die für die laufende Verwaltung von Speicherrepositories (SRs) erforderlich sind, einschließlich Live-VDI-Migration.

Erstellen von Speicherrepositories

In diesem Abschnitt wird erklärt, wie Sie Storage Repositories (SRs) verschiedener Typen erstellen und sie Ihrem XenServer-Host zur Verfügung stellen. In den bereitgestellten Beispielen wird das Erstellen von SRs über die xe-CLI behandelt. Einzelheiten zur Verwendung des Assistenten für neues Speicherrepository zum Hinzufügen von SRs mit XenCenter finden Sie in der XenCenter-Dokumentation.

Hinweis:

Lokale SRs vom Typ lvm, ext und xfs können nur mit der xe-CLI erstellt werden. Nach dem Erstellen können Sie alle SR-Typen entweder über XenCenter oder die xe-CLI verwalten.

Es gibt zwei grundlegende Schritte zum Erstellen eines Speicherrepositorys für die Verwendung auf einem Host über die CLI:

Prüfen Sie den SR-Typ, um Werte für alle erforderlichen Parameter zu ermitteln.
Erstellen Sie das SR, um das SR-Objekt und die zugehörigen PBD-Objekte zu initialisieren, schließen Sie die PBDs an und aktivieren Sie das SR.

Diese Schritte unterscheiden sich je nach Art des zu erstellenden SRs im Detail. In allen Beispielen gibt der Befehl sr-create bei Erfolg die UUID des erstellten SR zurück.

SRs können zerstört werden, wenn sie nicht mehr verwendet werden, um das physische Gerät freizugeben. SRs können auch vergessen werden, die SR von einem XenServer-Host zu trennen und an einen anderen anzuhängen. Weitere Informationen finden Sie im folgenden Abschnitt unter SRs entfernen .

Testen eines SR

Der Befehl sr-probe kann auf folgende Weise verwendet werden:

So identifizieren Sie unbekannte Parameter für die Erstellung eines SRs
So geben Sie eine Liste vorhandener SRs zurück

In beiden Fällen wird mit sr-probe ein SR-Typ und ein oder mehrere device-config-Parameter für diesen SR-Typ angegeben. Wenn ein unvollständiger Satz von Parametern angegeben wird, gibt der Befehl sr-probe eine Fehlermeldung zurück, die angibt, dass Parameter fehlen und die möglichen Optionen für die fehlenden Parameter angezeigt werden. Wenn ein vollständiger Satz von Parametern geliefert wird, wird eine Liste der vorhandenen SRs zurückgegeben. Die gesamte sr-probe-Ausgabe wird als XML zurückgegeben.

Ein bekanntes iSCSI-Ziel kann beispielsweise durch Angabe seines Namens oder seiner IP-Adresse untersucht werden. Der Satz von IQNs, der auf dem Ziel verfügbar ist, wird zurückgegeben:

    xe sr-probe type=lvmoiscsi device-config:target=192.168.1.10

    Error code: SR_BACKEND_FAILURE_96
    Error parameters: , The request is missing or has an incorrect target IQN parameter, \
    <?xml version="1.0" ?>
    <iscsi-target-iqns>
        <TGT>
            <Index>
                0
            </Index>
            <IPAddress>
                192.168.1.10
            </IPAddress>
            <TargetIQN>
                iqn.192.168.1.10:filer1
            </TargetIQN>
        </TGT>
    </iscsi-target-iqns>
<!--NeedCopy-->

Wenn Sie dasselbe Ziel erneut prüfen und sowohl den Namen/die IP-Adresse als auch den gewünschten IQN angeben, wird der Satz von SCSIids (LUNs) zurückgegeben, die auf dem Ziel/IQN verfügbar sind.

    xe sr-probe type=lvmoiscsi device-config:target=192.168.1.10  \
    device-config:targetIQN=iqn.192.168.1.10:filer1

    Error code: SR_BACKEND_FAILURE_107
    Error parameters: , The SCSIid parameter is missing or incorrect, \
    <?xml version="1.0" ?>
    <iscsi-target>
        <LUN>
            <vendor>
                IET
            </vendor>
            <LUNid>
                0
            </LUNid>
            <size>
                42949672960
            </size>
            <SCSIid>
                149455400000000000000000002000000b70200000f000000
            </SCSIid>
        </LUN>
    </iscsi-target>
<!--NeedCopy-->

Wenn Sie dasselbe Ziel prüfen und alle drei Parameter angeben, wird eine Liste von SRs zurückgegeben, die in der LUN vorhanden sind, falls vorhanden.

    xe sr-probe type=lvmoiscsi device-config:target=192.168.1.10  \
    device-config:targetIQN=192.168.1.10:filer1 \
    device-config:SCSIid=149455400000000000000000002000000b70200000f000000

    <?xml version="1.0" ?>
    <SRlist>
        <SR>
            <UUID>
                3f6e1ebd-8687-0315-f9d3-b02ab3adc4a6
            </UUID>
            <Devlist>
                /dev/disk/by-id/scsi-149455400000000000000000002000000b70200000f000000
            </Devlist>
        </SR>
    </SRlist>
<!--NeedCopy-->

Die folgenden Parameter können für jeden SR-Typ geprüft werden:

SR-Typ	Die Parameter `device-config`, in der Reihenfolge der Abhängigkeit	Kann untersucht werden?	Erforderlich für `sr-create`?
`lvmoiscsi`	`target`	Nein	Ja
	`chapuser`	Nein	Nein
	`chappassword`	Nein	Nein
	`targetIQN`	Ja	Ja
	`SCSIid`	Ja	Ja
`lvmohba`	`SCSIid`	Ja	Ja
`lvmofcoe`	`SCSIid`	Ja	Ja
`nfs`	`server`	Nein	Ja
	`serverpath`	Ja	Ja
`smb`	`server`	Nein	Ja
	`username`	Nein	Nein
	`password`	Nein	Nein
`lvm`	`device`	Nein	Ja
`ext`	`device`	Nein	Ja

Informationen zum Testen einer GFS2-SR finden Sie unter Erstellen einer GFS2-SR.

SRs entfernen

Ein Speicherrepository (SR) kann entweder vorübergehend oder dauerhaft entfernt werden.

Trennen: Unterbricht die Zuordnung zwischen dem Speichergerät und dem Pool oder Host (PBD Unplug). Auf das SR (und ihre VDIs) kann nicht mehr zugegriffen werden. Der Inhalt der VDIs und die Metainformationen, die von VMs für den Zugriff auf die VDIs verwendet werden, werden beibehalten. Detach kann verwendet werden, wenn Sie ein SR vorübergehend offline nehmen, z. B. für Wartungsarbeiten. Ein abgelöstes SR kann später wieder angebracht werden.

Vergessen: Behält den Inhalt des SRs auf dem physischen Datenträger bei, aber die Informationen, die eine VM mit ihren VDIs verbinden, werden dauerhaft gelöscht. Ermöglicht es Ihnen beispielsweise, die SR erneut an einen anderen XenServer-Host anzuschließen, ohne den SR-Inhalt zu entfernen.

Zerstören: Löscht den Inhalt des SRs von dem physischen Datenträger.

Hinweis:

Wenn Sie SMB-Speicher verwenden, entfernen Sie die Freigabe nicht aus dem Speicher, bevor Sie den SMB-SR trennen.

Für Destroy or Forget muss das an das SR angeschlossene PBD vom Host getrennt werden.

Trennen Sie die PBD, um die SR vom entsprechenden XenServer-Host zu trennen:
```
xe pbd-unplug uuid=pbd_uuid

```
Verwenden Sie den Befehl sr-destroy, um ein SR zu entfernen. Der Befehl zerstört die SR, löscht die SR und die entsprechende PBD aus der XenServer-Hostdatenbank und löscht den SR-Inhalt von der physischen Datenträger:
```
xe sr-destroy uuid=sr_uuid

```
Verwenden Sie den Befehl sr-forget, um ein SR zu vergessen. Der Befehl entfernt die SR und die entsprechende PBD aus der XenServer-Hostdatenbank, lässt jedoch den tatsächlichen SR-Inhalt auf dem physischen Medium intakt:
```
xe sr-forget uuid=sr_uuid

```

Hinweis:

Es kann einige Zeit dauern, bis das Softwareobjekt, das dem SR entspricht, bereinigt wird.

Einführen eines SRs

Um ein zuvor vergessenes SR wieder einzuführen, erstellen Sie ein PBD. Schließen Sie die PBD manuell an die entsprechenden XenServer-Hosts an, um den SR zu aktivieren.

Im folgenden Beispiel wird ein SR vom Typ lvmoiscsi eingeführt.

Prüfen Sie das vorhandene SR, um ihre UUID zu ermitteln:

xe sr-probe type=lvmoiscsi device-config:target=192.168.1.10 \
    device-config:targetIQN=192.168.1.10:filer1 \
    device-config:SCSIid=149455400000000000000000002000000b70200000f000000
<!--NeedCopy-->

Führen Sie die vorhandene SR-UUID ein, die vom Befehl sr-probe zurückgegeben wurde. Die UUID des neuen SRs wird zurückgegeben:

xe sr-introduce content-type=user name-label="Example Shared LVM over iSCSI SR" \
    shared=true uuid=valid_sr_uuid type=lvmoiscsi
<!--NeedCopy-->

Erstellen Sie ein PBD für das SR. Die UUID der neuen PBD wird zurückgegeben:

xe pbd-create type=lvmoiscsi host-uuid=valid_uuid sr-uuid=valid_sr_uuid \
    device-config:target=192.168.0.1 \
    device-config:targetIQN=192.168.1.10:filer1 \
    device-config:SCSIid=149455400000000000000000002000000b70200000f000000
<!--NeedCopy-->

Schließen Sie das PBD an, um das SR anzuschließen:
```
xe pbd-plug uuid=pbd_uuid

```
Überprüfen Sie den Status des PBD-Steckers. Wenn dies gelingt, ist die currently-attached-Eigenschaft wahr:
```
xe pbd-list sr-uuid=sr_uuid

```

Hinweis:

Führen Sie die Schritte 3 bis 5 für jeden Host im Ressourcenpool aus. Diese Schritte können auch mit der Funktion “Speicherrepository reparieren” in XenCenter ausgeführt werden.

Live-LUN-Erweiterung

Um die Kapazitätsanforderungen zu erfüllen, müssen Sie dem Speicher-Array möglicherweise Kapazität hinzufügen, um die Größe der für den XenServer-Host bereitgestellten LUN zu erhöhen. Mit der Live-LUN-Erweiterung können Sie die Größe der LUN ohne VM-Ausfallzeiten erhöhen.

Nachdem Sie Ihrem Speicher-Array mehr Kapazität hinzugefügt haben, geben Sie

xe sr-scan sr-uuid=sr_uuid
<!--NeedCopy-->

Dieser Befehl scannt das SR neu, und jede zusätzliche Kapazität wird hinzugefügt und zur Verfügung gestellt.

Dieser Vorgang ist auch in XenCenter verfügbar. Wählen Sie das zu ändernde SR aus, und klicken Sie dann auf Neu scannen.

Warnungen:

Es ist nicht möglich, LUNs zu verkleinern oder zu kürzen. Das Reduzieren der LUN-Größe auf dem Speicher-Array kann zu Datenverlust führen.

Live-VDI-Migration

Die Live-VDI-Migration ermöglicht es dem Administrator, das Virtual Disk Image (VDI) der virtuellen Maschine zu verlagern, ohne die VM herunterzufahren. Diese Funktion ermöglicht administrative Vorgänge wie:

Verschieben einer VM vom günstigen lokalen Speicher zu einem schnellen, stabilen, Array-gestützten Speicher.
Verschieben einer VM von einer Entwicklungs- in eine Produktionsumgebung.
Wechseln zwischen Speicherebenen, wenn eine VM durch Speicherkapazität begrenzt ist.
Durchführung von Speicher-Array-Upgrades.

Einschränkungen und Hinweise

Die Live-VDI-Migration unterliegt den folgenden Einschränkungen und Vorbehalte:

Im Ziel-Repository muss ausreichend Speicherplatz verfügbar sein.

So verschieben Sie virtuelle Datenträger mit XenCenter

Wählen Sie im Bereich Ressourcen das SR aus, in dem der virtuelle Datenträger gespeichert ist, und klicken Sie dann auf die Registerkarte Speicher.
Wählen Sie in der Liste Virtuelle Laufwerke das virtuelle Laufwerk aus, das Sie verschieben möchten, und klicken Sie dann auf Verschieben.
Wählen Sie im Dialogfeld Virtuellen Datenträger verschieben das Ziel-SR aus, auf das Sie den VDI verschieben möchten.

Hinweis:

Stellen Sie sicher, dass das SR ausreichend Speicherplatz für einen anderen virtueller Datenträger hat: Der verfügbare Speicherplatz wird in der Liste der verfügbaren SRs angezeigt.
Klicken Sie auf Verschieben, um das virtuelle Laufwerk zu verschieben.

Eine xe-CLI-Referenz finden Sie unter vdi-pool-migrate.

Kalte VDI-Migration zwischen SRs (Offline-Migration)

Mit einer VM verknüpfte VDIs können von einem SR auf ein anderes kopiert werden, um Wartungsanforderungen oder Tiered Storage-Konfigurationen zu erfüllen. XenCenter ermöglicht es Ihnen, eine VM und alle ihre VDIs auf dasselbe oder ein anderes SR zu kopieren. Eine Kombination aus XenCenter und der xe CLI kann zum Kopieren einzelner VDIs verwendet werden.

Eine xe-CLI-Referenz finden Sie unter vm-migrate.

Kopieren Sie alle VDIs einer VM auf ein anderes SR

Die XenCenter Copy-VM-Funktion erstellt Kopien aller VDIs für eine ausgewählte VM auf demselben oder einem anderen SR. Die Quell-VM und VDIs sind standardmäßig nicht betroffen. Um die VM auf das ausgewählte SR zu verschieben, anstatt eine Kopie zu erstellen, wählen Sie im Dialogfeld “Virtuelle Maschine kopieren” die Option “Ursprüngliche VM entfernen” aus.

Fahren Sie die VM herunter.
Wählen Sie in XenCenter die VM aus und wählen Sie dann die VMaus > OptionVM kopieren .
Wählen Sie das gewünschte Ziel-SR aus.

Einzelne VDIs auf ein anderes SR kopieren

Eine Kombination der xe CLI und XenCenter kann verwendet werden, um einzelne VDIs zwischen SRs zu kopieren.

Fahren Sie die VM herunter.
Verwenden Sie die xe-CLI, um die UUIDs der zu verschiebenden VDIs zu identifizieren. Wenn die VM über ein DVD-Laufwerk verfügt, wird vdi-uuid als not in database aufgeführt und kann ignoriert werden.
```
xe vbd-list vm-uuid=valid_vm_uuid

```
Hinweis:

Der Befehl vbd-list zeigt sowohl die VBD- als auch die VDI-UUIDs an. Achten Sie darauf, die VDI-UUIDs und nicht die VBD-UUIDs aufzuzeichnen.
Wählen Sie in XenCenter die Registerkarte VM-Speicher aus. Wählen Sie für jeden zu verschiebenden VDI den VDI aus und klicken Sie auf die Schaltfläche Trennen . Dieser Schritt kann auch mit dem Befehl vbd-destroy ausgeführt werden.

Hinweis:

Wenn Sie den Befehl vbd-destroy zum Trennen der VDI-UUIDs verwenden, überprüfen Sie zunächst, ob für die VBD der Parameter other-config:owner auf true eingestellt ist. Stellen Sie diesen Parameter auf ein false. Durch das Ausgeben des Befehls vbd-destroy mit other-config:owner=true wird auch der zugehörige VDI zerstört.
Verwenden Sie den Befehl vdi-copy, um alle VM-VDIs zu kopieren, die auf das gewünschte SR verschoben werden sollen.
```
xe vdi-copy uuid=valid_vdi_uuid sr-uuid=valid_sr_uuid

```
Wählen Sie in XenCenter die Registerkarte VM-Speicher aus. Klicken Sie auf die Schaltfläche Anhängen und wählen Sie die VDIs von dem neuen SR aus. Dieser Schritt kann auch mit dem Befehl vbd-create ausgeführt werden.
Um die ursprünglichen VDIs zu löschen, wählen Sie in XenCenter die Registerkarte Speicher des ursprünglichen SRs aus. Die ursprünglichen VDIs werden mit einem leeren Wert für das VM-Feld aufgeführt. Verwenden Sie die Schaltfläche Löschen, um den VDI zu löschen.

Lokale Fibre-Channel-SRs in gemeinsame SRs umwandeln

Verwenden Sie die xe CLI und das XenCenter Repair Storage Repository Feature, um ein lokales FC-SR in ein gemeinsam genutztes FC-SR zu konvertieren:

Aktualisieren Sie alle Hosts im Ressourcenpool auf XenServer 8.
Stellen Sie sicher, dass alle Hosts im Pool die LUN des SRs entsprechend in Zonen eingeteilt haben. Weitere Informationen über den Befehl sr-probe zum Prüfen, ob die LUN auf jedem Host vorhanden ist, finden Sie unter Prüfen eines SR.

Konvertieren Sie das SR in Shared:

xe sr-param-set shared=true uuid=local_fc_sr
<!--NeedCopy-->

Das SR wird in XenCenter von der Host-Ebene auf die Poolebene verschoben, was darauf hinweist, dass es jetzt freigegeben ist. Das SR ist mit einem roten Ausrufezeichen gekennzeichnet, um anzuzeigen, dass es derzeit nicht an allen Hosts im Pool angeschlossen ist.
Wählen Sie das SR und dann den Speicher > Option “Speicherrepository reparieren”.
Klicken Sie auf Reparieren, um eine PBD für jeden Host im Pool zu erstellen und anzuschließen.

Mit Discard Speicherplatz für blockbasierten Speicher auf dem Backing-Array zurückgewinnen

Sie können die Speicherrückgewinnung verwenden, um ungenutzte Blöcke auf einer dünn bereitgestellten LUN freizugeben. Nachdem der Speicherplatz freigegeben wurde, kann das Speicher-Array diesen zurückgewonnenen Speicherplatz wiederverwenden.

Hinweis:

Die Speicherrückgewinnung ist nur bei einigen Arten von Speicher-Arrays verfügbar. Um festzustellen, ob Ihr Array diese Funktion unterstützt und ob eine bestimmte Konfiguration erforderlich ist, lesen Sie die Hardwarekompatibilitätsliste und die spezifische Dokumentation Ihres Speicheranbieters.

So fordern Sie den Speicherplatz über XenCenter zurück:

Wählen Sie die Infrastrukturansicht und dann den Host oder Pool aus, der mit der SR verbunden ist.
Klicken Sie auf die Registerkarte Speicher.
Wählen Sie das SR aus der Liste aus und klicken Sie auf Freigegebenen Speicherplatz zurückgewinnen.
Klicken Sie Ja, um den Vorgang zu bestätigen.
Klicken Sie auf Benachrichtigungen und dann auf Ereignisse, um den Status des Vorgangs anzuzeigen.

Für weitere Informationen drücken Sie F1 in XenCenter, um auf die Onlinehilfe zuzugreifen.

Um Speicherplatz über die xe CLI zurückzugewinnen, können Sie den folgenden Befehl verwenden:

xe host-call-plugin host-uuid=host_uuid \
    plugin=trim fn=do_trim args:sr_uuid=sr_uuid

Hinweise:

Der Vorgang ist nur für LVM-basierte SRs verfügbar, die auf dünn bereitgestellten LUNs im Array basieren. Lokale SSDs können auch von der Speicherrückgewinnung profitieren.

Für dateibasierte SRs wie NFS und EXT3/EXT4 ist keine Speicherrückgewinnung erforderlich. Die Schaltfläche Freigegebenen Speicherplatz zurückgewinnen ist in XenCenter für diese SR-Typen nicht verfügbar.

Wenn Sie den xe-Befehl zur Speicherrückgewinnung für ein dateibasiertes SR oder ein thick-provisioned LVM-basiertes SR ausführen, gibt der Befehl einen Fehler zurück.

Die Speicherrückgewinnung ist ein intensiver Vorgang und kann zu einer Verschlechterung der Speicher-Array-Leistung führen. Starten Sie diesen Vorgang daher nur, wenn eine Speicherrückgewinnung auf dem Array erforderlich ist. Wir empfehlen, dass Sie diese Arbeit außerhalb der Spitzenauslastungszeiten des Arrays einplanen.

Beim Löschen von Snapshots automatisch Speicherplatz zurückgewinnen

Beim Löschen von Snapshots mit XenServer wird der auf LVM-basierten SRs zugewiesene Speicherplatz automatisch zurückgewonnen und ein VM-Neustart ist nicht erforderlich. Dieser Vorgang wird als “Online-Koaleszenz” bezeichnet. Online-Koaleszierung gilt für alle Arten von SR.

In bestimmten Fällen kann die automatisierte Speicherrückgewinnung möglicherweise nicht fortgesetzt werden. Wir empfehlen, das Offline-Coalesce-Tool in den folgenden Szenarien zu verwenden:

Unter Bedingungen, bei denen ein VM-I/O-Durchsatz erheblich
Unter Bedingungen, in denen nach einem bestimmten Zeitraum kein Platz mehr zurückgewonnen wird

Hinweise:

Die Ausführung des Offline-Coalesce-Tools führt zu einigen Ausfallzeiten für die VM, da die ausgeführten Vorgänge zum Anhalten/Wiederaufnehmen ausgeführt werden.

Bevor Sie das Tool ausführen, löschen Sie alle Snapshots und Klone, die Sie nicht mehr benötigen. Das Tool beansprucht angesichts der verbleibenden Snapshots/Klone so viel Speicherplatz wie möglich. Wenn Sie den gesamten Speicherplatz zurückfordern möchten, löschen Sie alle Snapshots und Klone.

VM-Datenträger müssen sich entweder auf freigegebenem oder lokalem Speicher für einen einzelnen Host befinden. VMs mit Datenträgern in beiden Speichertypen können nicht koalesziert werden.

Mit dem Offline-Coalesce-Tool Speicherplatz zurückgewinnen

Aktivieren Sie die versteckten Objekte mit XenCenter. Klicken Sie auf Ansicht > Versteckte Objekte. Wählen Sie im Bereich Ressource die VM aus, für die Sie die UUID abrufen möchten. Die UUID wird auf der Registerkarte Allgemein angezeigt.

Wählen Sie im Bereich Ressourcen den RessourcenPoolkoordinator (den ersten Host in der Liste) aus. Auf der Registerkarte Allgemein wird die UUID angezeigt. Wenn Sie keinen Ressourcenpool verwenden, wählen Sie den Host der VM aus.

Öffnen Sie eine Konsole auf dem Host und führen Sie den folgenden Befehl aus:

xe host-call-plugin host-uuid=host-UUID \
    plugin=coalesce-leaf fn=leaf-coalesce args:vm_uuid=VM-UUID
<!--NeedCopy-->

Wenn die VM-UUID beispielsweise 9bad4022-2c2d-dee6-abf5-1b6195b1dad5 ist und die Host-UUID b8722062-de95-4d95-9baa-a5fe343898ea, führen Sie den folgenden Befehl aus:

xe host-call-plugin host-uuid=b8722062-de95-4d95-9baa-a5fe343898ea \
    plugin=coalesce-leaf fn=leaf-coalesce args:vm_uuid=9bad4022-2c2d-dee6-abf5-1b6195b1dad5
<!--NeedCopy-->

Dieser Befehl setzt die VM an (sofern sie nicht bereits heruntergefahren ist), initiiert den Speicherrückgewinnungsprozess und setzt die VM dann fort.

Hinweise:

Wir empfehlen, die VM manuell herunterzufahren oder anzuhalten, bevor Sie das Offline-Coalesce-Tool ausführen. Sie können die VM entweder mit XenCenter oder der XenServer-CLI herunterfahren oder anhalten. Wenn Sie das Coalesce-Tool auf einer laufenden VM ausführen, unterbricht das Tool die VM automatisch, führt die erforderlichen VDI-Coalesce-Operationen durch und setzt die VM fort. Agile VMs werden möglicherweise auf einem anderen Host neu gestartet.

Wenn sich die Virtual Disk Images (VDIs), die zusammengeführt werden sollen, auf gemeinsam genutztem Speicher befinden, müssen Sie das Offline-Koaleszentool auf dem Poolkoordinator ausführen.

Wenn sich die VDIs, die zusammengeführt werden sollen, im lokalen Speicher befinden, führen Sie das Offline-Koaleszenz-Tool auf dem Host aus, an den der lokale Speicher angeschlossen ist.

Arbeiten mit Datenträger-I/O

Sie können den Datenträger-I/O-Scheduler und die Datenträger-I/O-Prioritätseinstellungen konfigurieren, um die Leistung Ihrer Datenträger zu ändern.

Hinweis:

Die in diesem Abschnitt beschriebenen Datenträger-I/O-Funktionen gelten nicht für EqualLogic-, NetApp- oder NFS-Speicher.

Anpassen des Datenträger-E/A-Schedulers

Für die allgemeine Leistung wird der Standarddatenträgerplaner noop auf alle neuen SR-Typen angewendet. Der noop-Scheduler bietet die fairste Leistung für konkurrierende VMs, die auf dasselbe Gerät zugreifen.

Passen Sie den Disk Scheduler an, indem Sie den folgenden Befehl verwenden:
```
xe sr-param-set other-config:scheduler=<option> uuid=<sr_uuid>

```
Der Wert von <option> kann einer der folgenden Begriffe sein: noop, cfq oder deadline.
Trennen Sie die entsprechende PBD und stecken Sie sie wieder ein, damit der Scheduler-Parameter wirksam wird.
```
xe pbd-unplug uuid=<pbd_uuid>
xe pbd-plug uuid=<pbd_uuid>

```

Um die Priorisierung von Datenträger-I/O-Anforderungen anzuwenden, überschreiben Sie die Standardeinstellung und weisen Sie den Datenträgerplaner cfq dem SR zu.

Priorisierung von I/O-Anforderungen für virtuelle Datenträger

Virtuelle Laufwerke verfügen über optionale Prioritätseinstellungen für I/O-Anfragen. Sie können diese Einstellungen verwenden, um I/O auf dem Datenträger einer bestimmten virtuellen Maschine gegenüber anderen zu priorisieren.

Bevor Sie die Prioritätsparameter für Datenträger-I/O-Anforderungen für eine VBD konfigurieren, stellen Sie sicher, dass der Datenträgerplaner für die SR entsprechend eingestellt wurde. Der Scheduler-Parameter muss auf dem SR auf cfq festgelegt sein und das zugehörige PBD getrennt und wieder angeschlossen werden. Informationen zum Anpassen des Schedulers finden Sie unter Anpassen des Datenträger-I/O-Schedulers.

Bei gemeinsam genutztem SR, bei dem mehrere Hosts auf dieselbe LUN zugreifen, wird die Prioritätseinstellung auf VBDs angewendet, die von demselben Host aus auf die LUN zugreifen. Diese Einstellungen werden nicht auf alle Hosts im Pool angewendet.

Der Host sendet eine Anfrage an den Remotespeicher, aber die Priorisierung der Anfragen erfolgt durch den Remotespeicher.

Datenträger-I/O-Anforderungsparameter festlegen

Diese Einstellungen können auf vorhandene virtuelle Laufwerke angewendet werden, indem Sie den Befehl xe vbd-param-set mit den folgenden Parametern verwenden:

qos_algorithm_type - Dieser Parameter muss auf den Wert ionice festgelegt werden. Dies ist der einzige Algorithmus, der für virtuelle Datenträger unterstützt wird.
qos_algorithm_param - Verwenden Sie diesen Parameter, um Schlüssel/Wert-Paare festzulegen. Für virtuelle Datenträger nimmt qos_algorithm_param einen Schlüssel sched, und je nach Wert ist auch ein Schlüssel class erforderlich.

Der Schlüssel qos_algorithm_param:sched kann einen der folgenden Werte haben:
- sched=rt oder sched=real-time — Dieser Wert setzt den Planungsparameter auf Echtzeitpriorität, was einen Parameter class erfordert, um einen Wert festzulegen.
- sched=idle - Dieser Wert setzt den Scheduling-Parameter auf die Leerlauf-Priorität, sodass kein Parameter class erforderlich ist, um einen Wert festzulegen.
- sched=anything - Dieser Wert setzt den Planungsparameter auf die Best-Effort-Priorität, was einen Parameter class erfordert, um einen Wert festzulegen.
Der Schlüssel qos_algorithm_param:class kann einen der folgenden Werte haben:
- Eines der folgenden Schlüsselwörter: highest, high, normal, low, lowest.
- Eine Ganzzahl zwischen 0 und 7, wobei 7 die höchste Priorität und 0 die niedrigste Priorität hat. Beispielsweise erhalten I/O-Anforderungen mit einer Priorität von 5 Vorrang vor I/O-Anforderungen mit einer Priorität von 2.

Beispiel

Die folgenden CLI-Befehle legen beispielsweise fest, dass die VBD des virtuellen Laufwerks die Echtzeitpriorität verwendet 5:

xe vbd-param-set uuid=<vbd_uuid> qos_algorithm_type=ionice
xe vbd-param-set uuid=<vbd_uuid> qos_algorithm_params:sched=rt
xe vbd-param-set uuid=<vbd_uuid> qos_algorithm_params:class=5
xe sr-param-set uuid=<sr_uuid> other-config:scheduler=cfq
xe pbd-unplug uuid=<pbd_uuid>
xe pbd-plug uuid=<pbd_uuid>
<!--NeedCopy-->