Mittwoch, 4. Mai 2022

Hyper-V auf RAID ist langsam...Warum?

Warum Hyper-V auf einem RAID langsam sein kann

Bei einem Striped RAID werden mehrere Festplatten zu einer zusammengefasst, indem aufeinanderfolgende Blöcke auf der nächsten Festplatte im Array gespeichert werden.

Wenn Sie beispielsweise vier Festplatten in einem Striped-Array verwenden, befinden sich die Blöcke Nr. 1 und 5 auf Festplatte Nr. 1 und die Blöcke Nr. 2 und 6 auf Festplatte Nr. 2.

Beim Kopieren von Dateien ist diese Anordnung sehr effizient, da das Betriebssystem Block für Block nacheinander liest und der RAID-Controller die nächsten vier Blöcke gleichzeitig laden kann, wodurch die gewünschte 4-fache Geschwindigkeit erreicht wird.

Auf virtuellen Hyper-V-Festplatten werden jedoch häufig VMs mit Exchange und SQL Server und anderen blockorientierten Diensten mit wahlfreiem Zugriff gespeichert.

Der Schlüssel dazu ist das Verständnis von Random Access. Zufälliger Zugriff bedeutet, dass das System die Blöcke nicht unbedingt der Reihe nach liest; daher ist Ihr tatsächlicher Durchsatz möglicherweise nicht besser als bei der Verwendung einer einzelnen Festplatte.

Wie kann das sein? Die Striped-RAID-Anordnung setzt einen sequentiellen Zugriff voraus, Block für Block. Nur dann können Sie eine nützliche Geschwindigkeitsverbesserung erzielen. Wenn das System Block Nr. 1 gefolgt von Block Nr. 101 liest und beide auf derselben Festplatte liegen, kann es unmöglich schneller werden. Außerdem lesen RAID-Controller möglicherweise einen ganzen Stripe auf einmal, was normalerweise ein Vielfaches von 4 KB ist, um die Sektorgröße moderner Festplatten zu optimieren.

Das ältere VHD-Format verwendet jedoch 512 Sektoren, und Hyper-V kann innerhalb einer VHD in 512-Byte-Schritten wahllos "springen". In einigen RAID-Einstellungen muss aufgrund der internen RAID-Verwaltung möglicherweise ein ganzer Stripe gelesen werden. Das bedeutet, dass es vorkommen kann, dass alle vier Laufwerke aktiviert sind, um einen winzigen Teil eines Blocks von der Festplatte Nr. 3 zu lesen.
Was ist zu tun?

Drei wichtige Faktoren in Hyper-V verschlimmern die Situation:

    Die Verwendung dynamisch expandierender Festplatten. Ein großes Tabu, wenn Sie Leistung wollen. Die Erweiterung von Festplatten führt dazu, dass sich die Festplattenköpfe irgendwann wie verrückt bewegen, da virtuelle Festplattenblöcke nicht wirklich sequentiell auf der Festplatte gespeichert werden.
    Verwendung von Prüfpunkten, auch bekannt als Hyper-V-Snapshots. Diese führen zu unterschiedlichen Festplatten, die auch zusätzliche "Sprünge" von einem Festplattensektor zum anderen erfordern. Diese Kopfbewegungen sind extrem zeitaufwändig
    Festplattenfragmentierung, meist verursacht durch die beiden oben genannten Punkte. Wenn dynamisch expandierende virtuelle Festplatten wachsen, verursachen sie auch eine Fragmentierung auf dem Host. Je mehr Dateifragmente vorhanden sind, desto mehr Zeit wird für das Springen von Sektor zu Sektor verschwendet, und auch die Suche nach dem Ort, an dem der nächste Block auf der Festplatte gespeichert ist, nimmt viel Zeit in Anspruch.

Die Empfehlung lautet daher:

    Verwenden Sie keine dynamisch expandierenden Festplatten
    Verwenden Sie keine Hyper-V Checkpoints/Snapshots
    Verwenden Sie VHDX mit fester Größe über VHD, um 4KB Block Alignment zu erhalten
    Machen Sie den RAID-Streifen nicht zu lang
    Defragmentieren Sie den Host, bevor Sie die VHDX erstellen.
    Überlegen Sie, ob eine Reihe von kleinen RAIDs mit zwei Festplatten und schnellen Festplatten nicht die bessere Wahl wäre
    SSDs verwenden? Diese sind zwar weniger zuverlässig und viel teurer, aber dafür entfallen die Kosten für die Bewegung der Festplattenköpfe. Sie sind jedoch nicht so zuverlässig wie magnetische Medien, und die CPU-Zeit wäre immer noch ein Problem bei der Verwendung von Differenzierungs- oder Erweiterungsfestplatten. Der CPU-Overhead ist jedoch viel geringer als die Zeit, die ein mechanisches Laufwerk benötigt, um seine Köpfe zu bewegen.

Und was ist mit Ihrer Hyper-V-Sicherung? Haben Sie eine zuverlässige Hyper-V Backup Lösung?


Keine Kommentare:

Kommentar veröffentlichen