Hyper-V sur RAID est lent... Pourquoi ?

Pourquoi Hyper-V peut être lent sur un RAID

Le RAID à bandes combine plusieurs disques durs en un seul en stockant des blocs consécutifs sur le disque dur suivant dans la matrice.

Par exemple, si vous utilisez quatre disques durs dans une matrice à bandes, les blocs #1 et #5 sont sur le disque dur #1, les blocs #2 et #6 sont sur le disque #2.

À chaque fois que vous copiez des fichiers, cette disposition est très efficace car le système d'exploitation lit les blocs les uns après les autres et le contrôleur RAID peut charger les quatre blocs suivants simultanément, ce qui vous donne la vitesse multipliée (4x) que vous recherchez.

Cependant, les disques virtuels Hyper-V stockent souvent des VM avec Exchange et SQL Server et d'autres services orientés bloc, à accès aléatoire.

La compréhension de l'accès aléatoire est la clé ici. L'accès aléatoire signifie que le système ne lira pas nécessairement les blocs dans l'ordre ; par conséquent, votre débit réel peut ne pas être meilleur que lorsque vous utilisez un seul disque dur.

Comment cela est-il possible ? La configuration RAID à bandes suppose un accès séquentiel, bloc après bloc. Ce n'est que dans ce cas qu'il peut vous offrir une amélioration utile de la vitesse. Lorsque le système lit le bloc #1 suivi du #101 et que les deux se trouvent sur le même disque, il est impossible d'accélérer les choses. En outre, les contrôleurs RAID peuvent lire une bande entière à la fois, qui est généralement un multiple de 4 Ko pour optimiser la taille des secteurs des disques durs modernes.

Cependant, l'ancien format VHD utilise 512 secteurs et Hyper-V peut "sauter" aléatoirement dans un VHD par étapes de 512 octets. Dans certaines configurations RAID, une bande entière peut devoir être lue en raison de la manière dont le RAID est géré en interne. Cela signifie qu'il peut arriver que les quatre disques soient engagés pour lire une minuscule fraction d'un bloc du disque dur n°3.
Que faire ?

Trois facteurs majeurs dans Hyper-V aggravent la situation :

    L'utilisation de disques à expansion dynamique. Un grand non-non si vous voulez des performances. L'expansion des disques fera bouger les têtes de disques comme des fous, car les blocs de disques virtuels ne sont pas vraiment stockés séquentiellement sur le disque.
    Utilisation de points de contrôle, c'est-à-dire de snapshots Hyper-V. Cela entraîne des disques différents qui nécessitent également des "sauts" supplémentaires d'un secteur de disque à un autre. Ces mouvements de tête prennent énormément de temps
    La fragmentation du disque, principalement causée par les deux éléments ci-dessus. Lorsque les disques virtuels à expansion dynamique se développent, ils provoquent également une fragmentation sur l'hôte. Plus de fragments de fichiers signifie plus de temps perdu à sauter d'un secteur à l'autre, sans compter le temps perdu à chercher où le prochain bloc est effectivement stocké sur le disque.

La recommandation est donc la suivante :

    N'utilisez pas de disques à expansion dynamique
    N'utilisez pas de Checkpoints / Snapshots Hyper-V.
    Utilisez des VHDX de taille fixe plutôt que des VHD pour obtenir un alignement de bloc de 4KB.
    Ne rendez pas la bande RAID trop longue.
    Défragmentez l'hôte avant de créer le VHDX.
    Considérez si un ensemble de petits RAIDs miroir à deux disques durs utilisant des disques durs rapides ne serait pas un meilleur choix.
    Utiliser des disques SSD ? Ils sont peut-être moins fiables et beaucoup plus chers, mais ils éliminent les frais de déplacement des têtes de disques durs. Cependant, ils ne sont pas aussi fiables que les supports magnétiques et le temps de traitement reste un problème lors de l'utilisation de disques de différenciation ou d'expansion. Cependant, la surcharge du CPU est beaucoup plus faible que le temps nécessaire à un disque mécanique pour déplacer ses têtes.

Et qu'en est-il de votre sauvegarde Hyper-V ? Avez-vous une solution de sauvegarde Hyper-V fiable ?

Windows Server and Hyper-V Backup Solution for Windows