Administrator Guide

Informationen zu Neuerstellungen
Bei der Neuerstellung werden Daten von einem Quelllaufwerk zu einem Ziellaufwerk synchronisiert. Wenn Unterschiede zwischen den
Komponenten eines RAID auftreten, wird die veraltete Komponente durch eine Neuerstellung aktualisiert.
Es gibt zwei Typen von Neuerstellungen:
● Bei einer kompletten Neuerstellung wird der gesamte Inhalt der Quelle auf das Ziel kopiert.
● Bei einer Protokollierungsneuerstellung werden nur geänderte Blöcke von der Quelle auf das Ziel kopiert.
Lokale Spiegelungen werden mit einer kompletten Neuerstellung aktualisiert (lokale Geräte verwenden keine Protokollierungs-Volumes).
In Metro Node Metro-Konfigurationen haben alle verteilten Geräte ein zugehöriges Protokollierungs-Volume. Protokollierungs-Volumes
verfolgen Blöcke, die während eines Ausfalls der Verbindung zwischen Clustern geschrieben werden. Nach der Wiederherstellung der
Verbindung bzw. der Komponente synchronisiert das Metro Node-System die Spiegelungen mithilfe der auf den Protokollierungs-Volumes
aufgezeichneten Informationen. Dabei werden nur geänderte Blöcke über die Verbindung gesendet.
Neuerstellungen von Protokollierungs-Volumes treten auch auf, wenn eine Komponente eines verteilten RAID 1 nicht mehr erreichbar ist,
aber schnell wiederhergestellt wird.
Wenn zu dem Zeitpunkt, zu dem ein Element als veraltet markiert wird, kein Protokollierungs-Volume verfügbar ist, wird das Element als
vollständig veraltet markiert, was zu einem vollständigen Neuaufbau führt.
Die Nichtverfügbarkeit eines Protokollierungs-Volume spielt sowohl zum Zeitpunkt der Recovery eine Rolle (wenn das System das
Protokollierungs-Volume liest) als auch zum Zeitpunkt, an dem ein Schreibvorgang auf einem Element fehlschlägt und auf einem anderen
erfolgreich ist (wenn das System mit dem Schreiben auf das Protokollierungs-Volume beginnt).
VORSICHT: Wenn kein Protokollierungs-Volume verfügbar ist, führt eine Wiederherstellung der Verbindung
zwischen Clustern dazu, dass alle verteilten Geräte vollständig neu erstellt werden, auf die während die
Verbindungsunterbrechung geschrieben wurde.
Weitere Informationen finden Sie unter Protokollierungs-Volumes.
Neuerstellungen für Thin-Provisioning-Speicher
Thin Provisioning ermöglicht das Migrieren von Speicher auf ein durch Thin Provisioning bereitgestelltes Speicher-Volume, dabei wird die
minimale Menge an Thin-Speicher-Poolressourcen zugewiesen.
Durch Thin Provisioning bereitgestellte Speicher-Volumes können in RAID 1-Spiegelungen mit einem ähnlichen Verbrauch der Thin-
Speicher-Poolressourcen eingebunden werden.
Metro Node bewahrt den nicht zugewiesenen Thin-Pool-Speicherplatz des Zielspeicher-Volume auf verschiedene Arten auf, abhängig
davon, ob das Ziel-Volume Thin-fähig ist oder nicht. Bei Thin-fähigen Volumes gibt Metro Node UNMAP für diese Blöcke auf den
Ziel-Volumes aus, wenn das Quellelement Null-Daten anzeigt. Bei nicht-Thin-fähigen Ziel-Komponenten prüft Metro Node vor dem
Schreiben, ob der Dateninhalt null ist, und unterdrückt den Schreibvorgang, wenn er eine unnötige Zuweisung auslösen würde. Damit
dieser Thin-Rebuild-Algorithmus ausgewählt werden kann, setzt Metro Node das Flag thin-rebuild automatisch auf Thin-fähigen
Volumes als Teil des Anspruchsprozesses. Für die Speicher-Volumes, die nicht als Thin-fähig unterstützt werden, legt der Metro Node-
Administrator während oder nach der Speicheranforderung eine dritte Eigenschaft fest, setzt das Attribut thin-rebuild auf true.
ANMERKUNG:
Während des Anforderns des Speicher-Volume setzt Metro Node den Thin-Rebuild-Flag auf den Thin-fähigen Arrays
automatisch auf true. Metro Node führt diese Aktivität auf den Thin-Speicher-Volumes aus, die bereits angefordert wurden, wobei
das Flag auf false gesetzt ist.
Mit Metro Node können Sie den Wert für die Thin-Rebuild-Funktion für Speicher-Volumes ändern, unabhängig davon, ob die Speicher-
Volumes Thin-fähig sind oder nicht. Wenn Sie bei Thin-fähigen Speicher-Volumes versuchen, die Eigenschaft „thin-rebuild“ auf „false“ zu
setzen, zeigt die Metro Node-CLI eine Warnmeldung an. In einem Szenario, in dem alle Inhalte der Quelle auf das Ziel geschrieben werden,
ist die Performance möglicherweise besser als der normale Neuaufbau, wenn folgende Bedingungen erfüllt sind:
● Die Speicher-Volumes sind nicht Thin-fähig.
● Der Inhalt der Quelle und des Ziels der Neuerstellung sind nahezu identisch.
● Nur die unterschiedlichen Daten werden während des Thin-Rebuild-Prozesses geschrieben.
Die erkannte Thin-Provisioning-Eigenschaft der Speicher-Volumes ermöglicht die Erstellung von Thin-Provisioning-fähigen virtuellen
Metro Node-Volumes, an die Hosts UNMAP-Befehle senden können, um die nicht verwendeten Blöcke freizugeben. Die konfigurierte
Thin-Rebuild-Eigenschaft steuert jedoch die Spiegelungssynchronisierung, die am Metro Node-Back-End durchgeführt wird.
Thin-Support im Metro-Node bietet weitere Informationen zu den Thin-Aware-Funktionen von Metro Node.
Datenmigration
45