Planifier des volumes sur des clusters Azure Local et Windows Server

Cet article fournit des conseils sur la planification des volumes de cluster pour répondre aux besoins en performances et en capacité de vos charges de travail, notamment en choisissant leur système de fichiers, leur type de résilience et leur taille.

Note

Les espaces de stockage direct ne prennent pas en charge un serveur de fichiers pour une utilisation générale. Si vous devez exécuter le serveur de fichiers ou d’autres services génériques sur l’espace de stockage direct, configurez-le sur les machines virtuelles.

Révision : que sont les volumes

Les volumes sont là où vous placez les fichiers dont vos charges de travail ont besoin, comme les fichiers VHD ou VHDX pour Hyper-V machines virtuelles. Les volumes combinent les disques du pool de stockage pour introduire les avantages de tolérance de panne, d'extensibilité et de performance des Espaces de Stockage Direct, la technologie de stockage définis par logiciel utilisée dans Azure Local et Windows Server.

Note

Nous utilisons le terme « volume » pour faire référence conjointement au volume et au disque virtuel sous celui-ci, y compris les fonctionnalités fournies par d’autres fonctionnalités Windows intégrées telles que les volumes partagés de cluster (CSV) et ReFS. La compréhension de ces distinctions au niveau de l’implémentation n’est pas nécessaire pour planifier et déployer des espaces de stockage direct avec succès.

Tous les volumes sont accessibles par tous les serveurs du cluster en même temps. Une fois créés, ils s’affichent sur C :\ClusterStorage\ sur tous les serveurs.

Choix du nombre de volumes à créer

Nous vous recommandons de faire en sorte que le nombre de volumes soit un multiple du nombre de serveurs de votre cluster. Par exemple, si vous avez 4 serveurs, vous obtiendrez des performances plus cohérentes avec 4 volumes totaux que 3 ou 5. Cela permet au cluster de distribuer le volume « propriété » (un serveur gère l’orchestration des métadonnées pour chaque volume) uniformément entre les serveurs.

Nous vous recommandons de limiter le nombre total de volumes à 64 volumes par cluster.

Choix du système de fichiers

Nous vous recommandons d’utiliser le nouveau système de fichiers résilient (ReFS) pour les espaces de stockage direct. ReFS est le premier système de fichiers conçu pour la virtualisation et offre de nombreux avantages, notamment des accélérations de performances spectaculaires et une protection intégrée contre la corruption des données. Il prend en charge presque toutes les fonctionnalités NTFS clés, notamment la déduplication des données dans Windows Server version 1709 et ultérieures. Pour plus d’informations, consultez le tableau de comparaison des fonctionnalités ReFS.

Si votre charge de travail nécessite une fonctionnalité que ReFS ne prend pas encore en charge, vous pouvez utiliser NTFS à la place.

Tip

Les volumes avec différents systèmes de fichiers peuvent coexister dans le même cluster.

Choix du type de résilience

Les volumes dans les espaces de stockage direct offrent une résilience pour se protéger contre les problèmes matériels, tels que les défaillances de lecteur ou de serveur, et pour permettre une disponibilité continue tout au long de la maintenance du serveur, comme les mises à jour logicielles.

Note

Les types de résilience que vous pouvez choisir sont indépendants des types de lecteurs dont vous disposez.

Avec deux serveurs

Avec deux serveurs dans le cluster, vous pouvez utiliser la mise en miroir bidirectionnel ou utiliser la résilience imbriquée.

Le miroir bidirectionnel conserve deux copies de toutes les données, une copie sur les disques de chaque serveur. Son efficacité de stockage est de 50 % ; pour écrire 1 To de données, vous avez besoin d’au moins 2 To de capacité de stockage physique dans le pool de stockage. La mise en miroir bidirectionnel peut tolérer en toute sécurité une défaillance matérielle à la fois (un serveur ou un lecteur).

La résilience imbriquée fournit une résilience des données entre les serveurs avec une mise en miroir bidirectionnelle, puis ajoute une résilience au sein d’un serveur avec une mise en miroir bidirectionnelle ou une parité accélérée par miroir. L’imbrication offre une résilience des données même quand un serveur redémarre ou n’est pas disponible. L’efficacité du stockage est de 25 % pour la mise en miroir double imbriquée et d’environ 35 à 40 % pour la parité imbriquée avec accélération par miroir. La résilience imbriquée peut tolérer en toute sécurité deux défaillances matérielles à la fois (deux lecteurs ou un serveur et un lecteur sur le serveur restant). En raison de cette résilience des données ajoutée, nous vous recommandons d’utiliser la résilience imbriquée sur les déploiements de production de clusters à deux serveurs. Pour plus d’informations, consultez Résilience imbriquée.

Avec trois serveurs

Avec trois serveurs, vous devez utiliser la mise en miroir tridirectionnel pour une meilleure tolérance de panne et des performances. La mise en miroir à trois voies conserve trois copies de toutes les données, une copie sur les disques de chaque serveur. Son efficacité de stockage est de 33,3 % pour écrire 1 To de données, vous avez besoin d’au moins 3 To de capacité de stockage physique dans le pool de stockage. La mise en miroir tridirectionnelle peut sans risque tolérer au moins deux problèmes matériels (disque ou serveur) à la fois. Si 2 nœuds deviennent indisponibles, le pool de stockage perd le quorum, car 2/3 des disques ne sont pas disponibles et les disques virtuels ne sont pas accessibles. Toutefois, un nœud peut être arrêté et un ou plusieurs disques sur un autre nœud peuvent échouer et les disques virtuels restent en ligne. Par exemple, si vous redémarrez un serveur quand un autre lecteur ou serveur échoue soudainement, toutes les données restent sécurisées et accessibles en permanence.

Avec quatre serveurs ou plus

Avec quatre serveurs ou plus, vous pouvez choisir pour chaque volume d’utiliser la mise en miroir tridirectionnel, la parité double (souvent appelée « codage d’effacement ») ou mélanger les deux avec une parité accélérée par miroir.

La parité double offre la même tolérance de panne que la mise en miroir tridirectionnelle, mais avec une meilleure efficacité de stockage. Avec quatre serveurs, son efficacité de stockage est de 50,0 % ; pour stocker 2 To de données, vous avez besoin de 4 To de capacité de stockage physique dans le pool de stockage. Cela augmente à 66,7 % d’efficacité du stockage avec sept serveurs et continue jusqu’à 80,0 % d’efficacité de stockage. Le compromis est que l’encodage de parité est plus gourmand en calcul, ce qui peut limiter ses performances.

Le type de résilience à utiliser dépend des exigences en matière de performances et de capacité de votre environnement. Voici un tableau qui résume les performances et l’efficacité du stockage de chaque type de résilience.

Type de résilience	Efficacité de la capacité	Speed
Mirror	Miroir tridirectionnel : 33 % Miroir bidirectionnel : 50%	Performances les plus élevées
Parité accélérée en miroir	Dépend de la proportion de miroir et de parité	Beaucoup plus lent que le miroir, mais jusqu’à deux fois plus rapide que la parité double Idéal pour les écritures et lectures séquentielles volumineuses
Dual-parity	4 serveurs : 50 % 16 serveurs : jusqu’à 80%	Latence d’E/S la plus élevée et utilisation du processeur lors des écritures Idéal pour les écritures et lectures séquentielles volumineuses

Quand les performances comptent le plus

Les charges de travail qui ont des exigences de latence strictes ou qui nécessitent un grand nombre d’E/S par seconde aléatoires mixtes, telles que les bases de données SQL Server ou les machines virtuelles sensibles Hyper-V aux performances, doivent s’exécuter sur des volumes qui utilisent la mise en miroir pour optimiser les performances.

Tip

La mise en miroir est plus rapide que tout autre type de résilience. Nous utilisons la mise en miroir pour presque tous nos exemples de performances.

Quand la capacité importe le plus

Les charges de travail qui écrivent rarement, telles que les entrepôts de données ou le stockage « froid », doivent s’exécuter sur des volumes qui utilisent la parité double pour optimiser l’efficacité du stockage. Certaines autres charges de travail, telles que Scale-Out Serveur de fichiers (SoFS), l’infrastructure de bureau virtuel (VDI) ou d’autres charges de travail qui ne créent pas beaucoup de trafic d’E/S aléatoire à dérive rapide et/ou qui ne nécessitent pas les meilleures performances peuvent également utiliser la parité double, à votre discrétion. La parité augmente inévitablement l’utilisation du processeur et la latence d’E/S, en particulier sur les écritures, par rapport à la mise en miroir.

Lorsque les données sont écrites en bloc

Les charges de travail qui écrivent en grandes passes séquentielles, comme les cibles d’archivage ou de sauvegarde, ont une autre option : un même volume peut combiner la mise en miroir et la parité double. Les écritures arrivent d’abord dans la partie mise en miroir et sont progressivement déplacés dans la partie parité plus tard. Cela accélère l’ingestion et réduit l’utilisation des ressources lorsque des écritures volumineuses arrivent en permettant à l’encodage de parité nécessitant beaucoup de ressources de se produire plus longtemps. Lors du dimensionnement des portions, considérez que le volume d’écritures qui se produisent à la fois (par exemple, une sauvegarde quotidienne) doit s’adapter confortablement à la partition miroir. Par exemple, si vous ingérez 100 Go une fois par jour, envisagez d’utiliser la mise en miroir pour 150 Go à 200 Go et la parité double pour le reste.

L’efficacité du stockage résultant dépend des proportions que vous choisissez.

Tip

Si vous observez une diminution soudaine des performances d’écriture via l’ingestion des données, cela peut indiquer que la partie miroir n’est pas suffisamment grande ou que la parité accélérée par miroir n’est pas bien adaptée à votre cas d’usage. Par exemple, si les performances d’écriture diminuent de 400 Mo/s à 40 Mo/s, envisagez de développer la partie miroir ou de basculer vers un miroir triple.

À propos des déploiements avec NVMe, SSD et HDD

Dans les déploiements avec deux types de lecteurs, les lecteurs plus rapides fournissent une mise en cache tandis que les lecteurs plus lents fournissent de la capacité. Cela se produit automatiquement : pour plus d’informations, consultez Présentation du cache dans les espaces de stockage direct. Dans ces déploiements, tous les volumes résident finalement sur le même type de lecteurs : les lecteurs de capacité.

Dans les déploiements avec les trois types de lecteurs, seuls les lecteurs les plus rapides (NVMe) fournissent une mise en cache, laissant deux types de lecteurs (SSD et HDD) pour fournir une capacité. Pour chaque volume, vous pouvez choisir s’il réside entièrement sur le niveau SSD, entièrement sur le niveau HDD ou s’il s’étend sur les deux.

Important

Nous vous recommandons d’utiliser le niveau SSD pour placer vos charges de travail les plus critiques en termes de performances sur des unités entièrement SSD.

Choix de la taille des volumes

Nous vous recommandons de limiter la taille de chaque volume à 64 To dans Azure Local.

Tip

Si vous utilisez une solution de sauvegarde qui s’appuie sur le service VSS (Volume Shadow Copy) et le fournisseur de logiciels Volsnap, comme c’est le cas avec les charges de travail de serveur de fichiers, la limitation de la taille du volume à 10 To améliore les performances et la fiabilité. Les solutions de sauvegarde qui utilisent les api RCT Hyper-V plus récentes et/ou reFS bloquent le clonage et/ou les API de sauvegarde SQL natives fonctionnent bien jusqu’à 32 To et au-delà.

Footprint

La taille d’un volume fait référence à sa capacité utilisable, la quantité de données qu’il peut stocker. Cela est fourni par le paramètre -Size de l’applet de commande New-Volume , puis apparaît dans la propriété Size lorsque vous exécutez l’applet de commande Get-Volume .

La taille se distingue de l’empreinte du volume, qui est la capacité de stockage physique totale qu’il occupe dans le pool de stockage. L’empreinte dépend de son type de résilience. Par exemple, les volumes qui utilisent la mise en miroir tridirectionnelle ont une empreinte trois fois plus grande que leur taille.

Les empreintes de vos volumes doivent s’adapter au pool de stockage.

Capacité de réserve

Laisser une certaine capacité dans le pool de stockage non allouée permet aux volumes de se réparer « sur place » après l’échec des lecteurs, ce qui améliore la sécurité et le niveau de performance des données. Si la capacité est suffisante, une réparation parallèle immédiate, sur place, peut restaurer des volumes sur résilience totale, même avant que les lecteurs en échec ne soient remplacés. Cela se fait automatiquement.

Nous vous recommandons de réserver l’équivalent d’un lecteur de capacité par serveur, jusqu’à 4 lecteurs. Vous pouvez réserver davantage à votre discrétion, mais cette recommandation minimale garantit qu’une réparation parallèle immédiate, sur place, peut réussir après l’échec de n’importe quel lecteur.

Par exemple, si vous avez 2 serveurs et que vous utilisez des lecteurs de capacité de 1 To, mettez de côté 2 x 1 = 2 To du pool comme réserve. Si vous avez 3 serveurs et 1 To de capacité, réservez 3 x 1 = 3 To comme réserve. Si vous avez 4 serveurs ou plus et 1 To de capacité, réservez 4 x 1 = 4 To comme réserve.

Note

Dans les clusters avec des lecteurs de tous les trois types (NVMe + SSD + HDD), nous vous recommandons de réserver l’équivalent d’un disque SSD plus un disque DUR par serveur, jusqu’à 4 lecteurs de chacun.

Exemple : planification de la capacité

Envisagez un cluster à quatre serveurs. Chaque serveur possède des lecteurs de cache plus seize lecteurs de 2 To pour la capacité.

4 servers x 16 drives each x 2 TB each = 128 TB

À partir de ces 128 To dans le pool de stockage, nous avons mis de côté quatre lecteurs, ou 8 To, afin que les réparations sur place puissent se produire sans l’urgence de remplacer les lecteurs après leur échec. Cela laisse 120 To de capacité de stockage physique dans le pool avec laquelle nous pouvons créer des volumes.

128 TB – (4 x 2 TB) = 120 TB

Supposons que nous avons besoin de notre déploiement pour héberger des machines virtuelles hautement actives Hyper-V, mais que nous avons également beaucoup de stockage à froid : les anciens fichiers et les sauvegardes dont nous avons besoin pour conserver. Comme nous avons quatre serveurs, nous allons créer quatre volumes.

Nous allons placer les machines virtuelles sur les deux premiers volumes, Volume1 et Volume2. Nous choisissons ReFS comme système de fichiers (pour la création et les points de contrôle plus rapides) et la mise en miroir tridirectionnelle pour la résilience afin d'optimiser les performances. Nous allons placer le stockage à froid sur les deux autres volumes, Volume 3 et Volume 4. Nous choisissons NTFS comme système de fichiers (pour la déduplication des données) et la parité double pour la résilience afin d’optimiser la capacité.

Nous n’avons pas besoin de rendre tous les volumes de la même taille, mais par souci de simplicité, nous pouvons, par exemple, les rendre toutes 12 To.

Volume1 et Volume2 occupent chacun 12 To x 33,3 % d’efficacité = 36 To de capacité de stockage physique.

Volume3 et Volume4 occupent chacun une efficacité de 12 To x 50,0 % = 24 To de capacité de stockage physique.

36 TB + 36 TB + 24 TB + 24 TB = 120 TB

Les quatre volumes correspondent exactement à la capacité de stockage physique disponible dans notre pool. Perfect!

Tip

Vous n’avez pas besoin de créer tous les volumes immédiatement. Vous pouvez toujours étendre des volumes ou créer de nouveaux volumes ultérieurement.

Par souci de simplicité, cet exemple utilise des unités décimales (base-10), ce qui signifie 1 To = 1 000 000 000 000 octets. Toutefois, les quantités de stockage dans Windows apparaissent dans des unités binaires (base-2). Par exemple, chaque lecteur de 2 To apparaîtrait sous forme de 1,82 Tio dans Windows. De même, le pool de stockage de 128 To apparaît indiquant 116,41 Tio. Ceci est attendu.

Usage

Consultez Création de volumes.

Étapes suivantes

Pour plus d’informations, consultez également :

• Choix des lecteurs pour les espaces de stockage direct
• Tolérance de panne et efficacité du stockage