Planen von Volumes auf Azure Stack HCI- und Windows Server-Clustern
Gilt für: Azure Stack HCI, Versionen 22H2 und 21H2; Windows Server 2022, Windows Server 2019
Wichtig
Azure Stack HCI ist jetzt Teil von Azure Local. Die Umbenennung der Produktdokumentation wird ausgeführt. Ältere Versionen von Azure Stack HCI, z. B. 22H2, verweisen jedoch weiterhin auf Azure Stack HCI und spiegeln die Namensänderung nicht wider. Weitere Informationen
Dieser Artikel enthält eine Anleitung zum Planen von Clustervolumes in Azure Stack HCI, um die Leistungs- und Kapazitätsanforderungen für Ihre Workloads zu erfüllen, einschließlich Auswahl von Dateisystem, Resilienztyp und Größe.
Hinweis
Storage Space Direct unterstützt keinen Dateiserver für die allgemeine Verwendung. Wenn Sie den Dateiserver oder andere generische Dienste auf Storage Space Direct ausführen müssen, konfigurieren Sie ihn auf den virtuellen Computern.
Überprüfung: Was sind Volumes?
In Volumes ordnen Sie die Dateien an, die von Ihren Workloads benötigt werden, z. B. VHD- oder VHDX-Dateien für virtuelle Hyper-V-Computer. Für Volumes werden die Laufwerke im Speicherpool kombiniert, um die Fehlertoleranz, Skalierbarkeit und Leistungsvorteile von Direkte Speicherplätze zu erhalten, der softwaredefinierten Speichertechnologie hinter Azure Stack HCI und Windows Server.
Hinweis
Wir verwenden den Begriff „Volume“, um sowohl auf das Volume als auch auf den zugrunde liegenden virtuellen Datenträger zu verweisen – einschließlich der Funktionalität, die von anderen integrierten Windows-Features, z. B. freigegebenen Clustervolumes (Cluster Shared Volumes, CSV) und ReFS, bereitgestellt wird. Eine genaue Kenntnis dieser Unterschiede auf Implementierungsebene ist nicht erforderlich, um „Direkte Speicherplätze“ erfolgreich planen und bereitstellen zu können.
Auf alle Volumes kann von allen Servern des Clusters gleichzeitig zugegriffen werden. Nach der Erstellung werden sie auf allen Servern unter C:\ClusterStorage angezeigt.
Auswählen der Anzahl zu erstellender Volumes
Wir empfehlen Ihnen, als Anzahl von Volumes ein Vielfaches der Anzahl von Servern Ihres Clusters zu wählen. Wenn Sie beispielsweise über 4 Server verfügen, werden Sie eine konsistentere Leistung mit 4 Gesamtvolumes als bei 3 oder 5 erleben. Der Cluster kann den „Volumebesitz“ (ein Server führt die Metadatenorchestrierung für jedes Volume durch) dann gleichmäßig auf die Server verteilen.
Wir empfehlen, die Gesamtzahl von Volumes auf 64 pro Cluster zu begrenzen.
Auswählen des Dateisystems
Wir empfehlen Ihnen die Verwendung des neuen resilienten Dateisystems (Resilient File System, ReFS) für „Direkte Speicherplätze“. ReFS ist ein Dateisystem, das speziell für die Virtualisierung entwickelt wurde. Es bietet viele Vorteile, z. B. erhebliche Leistungsverbesserungen und integrierter Schutz vor Datenbeschädigung. Nahezu alle wichtigen NTFS-Features werden unterstützt, z. B. die Datendeduplizierung unter Windows Server-Version 1709 und höher. Ausführliche Informationen finden Sie in der Tabelle mit dem Featurevergleich für ReFS.
Falls Sie für Ihre Workload ein Feature benötigen, das von ReFS noch nicht unterstützt wird, können Sie stattdessen NTFS verwenden.
Tipp
Volumes mit unterschiedlichen Dateisystemen können in demselben Cluster parallel vorhanden sein.
Auswählen des Resilienztyps
Volumes unter „Direkte Speicherplätze“ bieten Resilienz als Schutz vor Hardwareproblemen, z. B. Laufwerks- oder Serverfehler, und ermöglichen eine ununterbrochene Verfügbarkeit bei der Serverwartung, z. B. Softwareupdates.
Hinweis
Welche Resilienztypen Sie auswählen können, ist unabhängig davon, welche Laufwerkstypen Sie verwenden.
Mit zwei Servern
Bei zwei Servern im Cluster können Sie die Zwei-Wege-Spiegelung oder die geschachtelte Resilienz verwenden.
Bei der Zwei-Wege-Spiegelung werden zwei Kopien aller Daten beibehalten (eine Kopie auf dem Laufwerk jedes Servers). Die Speichereffizienz beträgt hierbei 50 %. Zum Schreiben von 1 TB an Daten benötigen Sie mindestens 2 TB an physischer Speicherkapazität im Speicherpool. Bei der Zwei-Wege-Spiegelung kann jeweils problemlos ein Hardwarefehler toleriert werden (ein Server oder Laufwerk).
Die geschachtelte Resilienz sorgt für Datenresilienz zwischen Servern mit Zwei-Wege-Spiegelung und fügt dann Resilienz auf einem Server mit Zwei-Wege-Spiegelung oder Parität mit Beschleunigung per Spiegelung hinzu. Die Schachtelung ermöglicht auch dann Datenresilienz, wenn ein Server neu gestartet wird oder nicht verfügbar ist. Hierbei beträgt die Speichereffizienz für die geschachtelte Zwei-Wege-Spiegelung 25 % und ca. 35 - 40 % für die geschachtelte Parität mit Beschleunigung per Spiegelung. Bei der geschachtelten Resilienz können jeweils zwei Hardwarefehler toleriert werden (zwei Laufwerke oder ein Server und ein Laufwerk auf dem verbleibenden Server). Aufgrund dieser zusätzlichen Datenresilienz empfiehlt sich die Verwendung der geschachtelten Resilienz in Produktionsbereitstellungen mit Clustern aus zwei Servern. Weitere Informationen finden Sie unter Geschachtelte Resilienz.
Mit drei Servern
Bei drei Servern sollten Sie die Drei-Wege-Spiegelung verwenden, um eine bessere Fehlertoleranz und Leistung zu erzielen. Bei der Drei-Wege-Spiegelung werden drei Kopien aller Daten beibehalten (eine Kopie auf dem Laufwerk jedes Servers). Die Speichereffizienz beträgt hierbei 33,3 %. Zum Schreiben von 1 TB an Daten benötigen Sie mindestens 3 TB an physischer Speicherkapazität im Speicherpool. Bei der Drei-Wege-Spiegelung können mindestens zwei gleichzeitige Hardwareprobleme (Laufwerk oder Server) problemlos toleriert werden. Wenn 2 Knoten nicht mehr verfügbar sind, verliert der Speicherpool das Quorum, da 2/3 der Datenträger nicht verfügbar sind und auf die virtuellen Datenträger nicht zugegriffen werden kann. Ein Knoten kann jedoch heruntergefahren werden, und mindestens ein Datenträger auf einem anderen Knoten kann fehlschlagen, und die virtuellen Datenträger bleiben online. Wenn Sie beispielsweise einen Server neu starten und plötzlich ein anderes Laufwerk bzw. ein Server ausfällt, bleiben alle Daten geschützt und sind ohne Unterbrechung zugänglich.
Mit vier oder mehr Servern
Bei vier oder mehr Servern können Sie für jedes Volume auswählen, ob die Drei-Wege-Spiegelung, die duale Parität (häufig als „Erasure Coding“ bezeichnet) oder eine Mischung dieser beiden Optionen mit Parität mit Beschleunigung per Spiegelung verwendet werden soll.
Die duale Parität bietet die gleiche Fehlertoleranz wie die Drei-Wege-Spiegelung, aber eine höhere Speichereffizienz. Bei vier Servern beträgt die Speichereffizienz 50,0 %. Zum Schreiben von 2 TB an Daten benötigen Sie 4 TB an physischer Speicherkapazität im Speicherpool. Bei sieben Servern erhöht sich die Speichereffizienz auf 66,7 %, und dieser Wert kann mit weiteren Servern auf bis zu 80,0 % gesteigert werden. Der Nachteil ist, dass es zu Leistungseinbußen kommen kann, weil die Paritätscodierung rechenintensiver ist.
Welcher Resilienztyp verwendet werden soll, hängt von den Leistungs- und Kapazitätsanforderungen für Ihre Umgebung ab. Hier ist eine Tabelle, die die Leistung und Speichereffizienz der einzelnen Resilienztypen zusammenfasst.
| Resilienztyp | Kapazitätseffizienz | Geschwindigkeit |
|---|---|---|
| Spiegel |  Dreiwegspiegel: 33% Zwei-Wege-Spiegelung: 50% |
 Höchste Leistung |
| Parität mit Beschleunigung per Spiegelung |  Abhängig von Spiegelungs- und Paritätsanteil |
 Deutlich langsamer als die Spiegelung, aber bis zu doppelt so schnell wie die duale Parität Am besten für umfangreiche sequenzielle Schreib- und Lesevorgänge geeignet |
| Duale Parität |  4 Server: 50 % 16 Server: bis zu 80 % |
 Höchste E/A-Latenz und CPU-Auslastung bei Schreibvorgängen Am besten für umfangreiche sequenzielle Schreib- und Lesevorgänge geeignet |
Bei hohen Leistungsanforderungen
Workloads, für die hohe Latenzanforderungen gelten oder für die viele verschiedene zufällige IOPS-Vorgänge durchgeführt werden müssen, z. B. SQL Server-Datenbanken oder leistungsempfindliche virtuelle Hyper-V-Computer, sollten auf Volumes ausgeführt werden, für die die Spiegelung zum Maximieren der Leistung genutzt wird.
Tipp
Die Spiegelung ist schneller als alle anderen Resilienztypen. Wir verwenden die Spiegelung für nahezu alle Beispiele zur Leistung.
Bei hohen Kapazitätsanforderungen
Workloads mit seltenen Schreibvorgängen, z. B. Data Warehouses oder „Cold Storage“, sollten auf Volumes ausgeführt werden, für die die duale Parität zum Maximieren der Speichereffizienz genutzt wird. Für bestimmte andere Workloads, z. B.Dateiserver mit horizontaler Skalierung, virtuelle Desktopinfrastruktur (VDI) oder andere, bei denen keine großen Mengen von sich schnell änderndem, zufälligem E/A-Datenverkehr anfallen oder für die nicht die höchstmögliche Leistung erforderlich ist, kann je nach Ihren Anforderungen auch die duale Parität genutzt werden. Im Vergleich zur Spiegelung kommt es bei Parität unweigerlich zu einer Erhöhung der CPU-Auslastung und E/A-Latenz, vor allem für Schreibvorgänge.
Bei Massenschreibvorgängen für Daten
Für Workloads, bei denen es zu großen sequenziellen Schreibvorgängen kommt, z. B. Archivierungs- oder Sicherungsziele, gibt es eine andere Option: auf einem Volume können Spiegelung und duale Parität gemischt werden. Schreibvorgänge landen zuerst im gespiegelten Teil und werden später dann allmählich in den Paritätsteil verschoben. Hierdurch wird die Erfassung beschleunigt und die Ressourcenverwendung reduziert, wenn große Schreibvorgänge auftreten, indem es ermöglicht wird, dass die rechenintensive Paritätscodierung über einen längeren Zeitraum erfolgt. Beachten Sie bei der Größenanpassung für die Teile, dass die Menge an gleichzeitig durchgeführten Schreibvorgängen (z. B. die tägliche Sicherung) gut in den Spiegelungsteil passt. Wenn Sie beispielsweise einmal täglich 100 GB erfassen, sollten Sie erwägen, die Spiegelung für 150 bis 200 GB und die duale Parität für den Rest zu verwenden.
Die sich ergebende Speichereffizienz richtet sich nach den von Ihnen gewählten Anteilen.
Tipp
Falls Sie während der Datenerfassung eine abrupte Abnahme der Schreibleistung bemerken, kann dies ein Hinweis darauf sein, dass der Spiegelungsteil nicht groß genug ist oder die Parität mit Beschleunigung per Spiegelung für Ihren Anwendungsfall nicht gut geeignet ist. Beispiel: Wenn die Schreibleistung von 400 MB/s auf 40 MB/s abnimmt, sollten Sie erwägen, den Spiegelungsteil zu erweitern oder zur Drei-Wege-Spiegelung zu wechseln.
Informationen zu Bereitstellungen mit NVMe, SSDs und HDDs
Bei Bereitstellungen mit zwei Arten von Laufwerken übernehmen die schnelleren Laufwerke die Zwischenspeicherung und die langsameren die Kapazitätsaufgaben. Dies erfolgt automatisch. Weitere Informationen finden Sie unter Grundlegendes zum Cache in „Direkte Speicherplätze“. Bei Bereitstellungen dieser Art befinden sich alle Volumes letztendlich auf dem gleichen Laufwerkstyp, nämlich den Kapazitätslaufwerken.
Bei Bereitstellungen mit allen drei Laufwerkstypen übernehmen nur die schnellsten Laufwerke (NVMe) die Zwischenspeicherung, und zwei Laufwerkstypen (SSD und HDD) sind für die Kapazität zuständig. Sie können für jedes Volume auswählen, ob es sich vollständig auf der SSD-Ebene oder der HDD-Ebene befindet oder ob es übergreifend angeordnet ist.
Wichtig
Wir empfehlen Ihnen, die SSD-Ebene zu verwenden, um Ihre leistungsempfindlichsten Workloads als reine Flash-Bereitstellung anzuordnen.
Auswählen der Größe von Volumes
Wir empfehlen Ihnen, in Azure Stack HCI die Größe pro Volume auf 64 TB zu beschränken.
Tipp
Bei Verwendung einer Sicherungslösung, die auf dem Volumeschattenkopie-Dienst (VSS) und dem Softwareanbieter Volsnap basiert – wie bei Dateiserverworkloads üblich –, können Leistung und Zuverlässigkeit durch die Begrenzung der Volumegröße auf 10 TB verbessert werden. Sicherungslösungen, für die die neuere Hyper-V RCT-API, das Klonen von ReFS-Blöcken oder die nativen SQL-Sicherungs-APIs genutzt werden, weisen bei bis zu 32 TB und darüber hinaus eine gute Leistung auf.
Speicherbedarf
Die Größe eines Volumes bezieht sich auf die nutzbare Kapazität – also die Daten, die gespeichert werden können. Hierfür wird der Parameter -Size des Cmdlets New-Volume verwendet. Die Größe wird dann in der Size-Eigenschaft angezeigt, wenn Sie das Cmdlet Get-Volume ausführen.
Die Größe ist etwas anderes als der Speicherbedarf des Volumes. Der Speicherbedarf ist die gesamte physische Speicherkapazität, die im Speicherpool dafür genutzt wird. Der Speicherbedarf richtet sich jeweils nach dem Resilienztyp. Für Volumes mit Drei-Wege-Spiegelung wird beispielsweise ein Speicherbedarf in Höhe ihrer dreifachen Größe benötigt.
Der Speicherpool muss ausreichend groß sein, um den Speicherbedarf Ihrer Volumes abdecken zu können.
Reservekapazität
Wenn ein Teil der Kapazität im Speicherpool nicht belegt wird, ist für Volumes nach Laufwerksausfällen Platz für direkte Reparaturen, und dies führt zu einer Verbesserung der Datensicherheit und Leistung. Wenn genügend Kapazität vorhanden ist, kann eine sofortige, direkte parallele Reparatur Volumes in voller Resilienz wiederherstellen, auch bevor die fehlerhaften Laufwerke ersetzt werden. Dies erfolgt automatisch.
Wir empfehlen Ihnen, pro Server ein Kapazitätslaufwerk zu reservieren (bis zu vier Laufwerke). Sie können bei Bedarf auch mehr Laufwerke reservieren. Mit dieser Empfehlung zur Mindestkonfiguration wird aber sichergestellt, dass die sofortige, direkte, parallele Reparatur nach dem Ausfall eines Laufwerks erfolgreich durchgeführt werden kann.
Wenn Sie beispielsweise über 2 Server verfügen und 1 TB Kapazitätslaufwerke verwenden, reservieren Sie 2 x 1 = 2 TB Pool als Reserve. Bei drei Servern und Kapazitätslaufwerken mit 1 TB sind drei Terabyte (3 x 1 = 3 TB) als Reserve ratsam. Bei vier oder mehr Servern und Kapazitätslaufwerken mit 1 TB sind vier Terabyte (4 x 1 = 4 TB) als Reserve zu empfehlen.
Hinweis
Bei Clustern mit allen drei Laufwerkstypen (NVMe, SSDs und HDDs) lautet die Empfehlung, pro Server eine SSD und eine HDD zu reservieren (jeweils bis zu vier Laufwerke).
Beispiel: Kapazitätsplanung
Stellen Sie sich einen Cluster mit vier Servern vor. Jeder Server verfügt über einige Cachelaufwerke sowie 16 Kapazitätslaufwerke mit jeweils 2 TB.
4 servers x 16 drives each x 2 TB each = 128 TB
Von diesen 128 TB im Speicherpool reservieren wir vier Laufwerke (also 8 TB), damit direkte Reparaturen durchgeführt werden können, ohne dass Zeitnot beim Austauschen von Laufwerken nach einem Ausfall besteht. Es verbleiben 120 TB an physischer Speicherkapazität im Pool, die für die Erstellung von Volumes genutzt werden kann.
128 TB – (4 x 2 TB) = 120 TB
Angenommen, wir benötigen unsere Bereitstellung zum Hosten von einigen sehr aktiven virtuellen Hyper-V-Computern, verfügen aber auch über eine große Menge von „Cold Storage“ (alte Dateien und Sicherungen, die beibehalten werden müssen). Da wir vier Server haben, erstellen wir vier Volumes.
Wir ordnen die virtuellen Computer auf den ersten beiden Volumes Volume1 und Volume2 an. Wir verwenden ReFS als Dateisystem (aufgrund der schnelleren Erstellung und der Prüfpunkte) und die Drei-Wege-Spiegelung zur Erzielung von Resilienz, um die Leistung zu maximieren. „Cold Storage“ ordnen wir auf den anderen beiden Volumes Volume3 und Volume4 an. Wir wählen NTFS als Dateisystem (für die Datendeduplizierung) und die duale Parität zur Erzielung von Resilienz, um die Kapazität zu maximieren.
Es müssen nicht unbedingt alle Volumes die gleiche Größe haben, aber der Einfachheit halber wählen wir hier diese Vorgehensweise, indem wir beispielsweise für alle eine Größe von 12 TB festlegen.
Volume1 und Volume2 belegen jeweils 12 TB x 33,3 Prozent Effizienz = 36 TB physische Speicherkapazität.
Volume3 und Volume4 belegen jeweils 12 TB x 50,0 Prozent Effizienz = 24 TB physische Speicherkapazität.
36 TB + 36 TB + 24 TB + 24 TB = 120 TB
Die vier Volumes füllen genau die physische Speicherkapazität aus, die in unserem Pool verfügbar ist. Perfekt!
Tipp
Sie müssen nicht alle Volumes sofort erstellen. Es ist später jederzeit möglich, Volumes zu erweitern oder neue Volumes zu erstellen.
Der Einfachheit halber werden in diesem Beispiel durchgängig dezimale Einheiten (Basis 10) verwendet. Dies bedeutet dass 1 TB 1.000.000.000.000 Byte entspricht. Unter Windows werden Speichermengen dagegen als Binäreinheiten (Basis 2) angezeigt. Beispielsweise wird für 2-TB-Laufwerke unter Windows eine Größe von 1,82 TiB angegeben. Analog wird für den Speicherpool mit 128 TB eine Größe von 116,41 TiB angegeben. Dies entspricht dem erwarteten Verhalten.
Verbrauch
Weitere Informationen finden Sie unter Erstellen von Volumes in Azure Stack HCI.
Nächste Schritte
Weitere Informationen finden Sie auch unter: