Compréhension du cache de pool de stockage
S’applique à : Azure Stack HCI, versions 22H2 et 21H2 ; Windows Server 2022, Windows Server 2019
La fonctionnalité Espaces de stockage direct, qui est la technologie sous-jacente de virtualisation du stockage d’Azure Stack HCI et de Windows Server, comprend un cache intégré côté serveur pour optimiser les performances de stockage tout en réduisant les coûts. Il s’agit d’un cache de lecture et d’écriture volumineux, permanent et en temps réel, qui est configuré automatiquement lors du déploiement. Dans la plupart des cas, aucune gestion manuelle n’est nécessaire. Le fonctionnement du cache varie en fonction des types de lecteur utilisés.
Types de lecteur et options de déploiement
Pour l’heure, les espaces de stockage direct fonctionnent avec quatre types de lecteurs :
| Type de lecteur | Description |
|---|---|
 |
PMem fait référence à la mémoire persistante, un nouveau type de stockage à faible latence et haute performance. |
 |
NVMe (Non-Volatile Memory Express) fait référence aux disques SSD qui se trouvent directement sur le bus PCIe. Les facteurs de forme courants sont les suivants : U.2 2,5 pouces, PCIe Add-In-Card (AIC) et M.2. NVMe offre un plus haut débit d’IOPS et un d’E/S avec une latence plus faible que tout autre type de lecteur actuellement pris en charge, en dehors de PMem. |
 |
SSD fait référence aux disques SSD qui se connectent par le biais de connecteurs SATA ou SAS conventionnels. |
 |
HDD fait référence à des lecteurs de disque dur rotationnels et magnétiques qui offrent une grande capacité de stockage à faible coût. |
Ceux-ci peuvent être combinés de différentes façons, que nous regroupons dans deux catégories : « 100 % flash » et « hybride ». Les déploiements avec tous les HDD ne sont pas pris en charge.
Notes
Cet article traite des configurations du cache avec NVMe, SSD et HDD. Pour plus d’informations sur l’utilisation de la mémoire persistante en tant que cache, consultez Comprendre et déployer la mémoire persistante.
Possibilités de déploiement 100 % flash
L’objectif des déploiements 100 % flash est d’optimiser les performances de stockage. Ces déploiements n’incluent pas de HDD.
Possibilités de déploiement hybride
Les déploiements hybrides ont pour but d’équilibrer les performances et la capacité ou d’optimiser la capacité, et n’incluent pas de HDD.
Notes
Le déploiement hybride n’est pas pris en charge dans la configuration à serveur unique. Toutes les configurations de type de stockage unique plat (par exemple, NVMe uniquement ou SSD uniquement) sont le seul type de stockage pris en charge pour un seul serveur.
Les lecteurs de cache sont sélectionnés automatiquement
Dans les déploiements où cohabitent plusieurs types de lecteurs, les espaces de stockage direct utilisent automatiquement tous les lecteurs du type de mise en cache le plus rapide. Les lecteurs restants sont utilisés pour la capacité.
La rapidité des lecteurs est déterminée selon la hiérarchie suivante.
Par exemple, si vous avez des lecteurs NVMe et des disques SSD, les NVMe assureront la mise en cache pour les disques SSD.
Si vous avez des disques SSD et des lecteurs de disque dur (HDD), les SSD assureront la mise en cache pour les HDD.
Notes
Les lecteurs de cache ne contribuent pas à la capacité de stockage utilisable dans le cluster. Toutes les données stockées dans le cache sont aussi stockées ailleurs ou le seront une fois qu’elles auront été supprimées du stockage temporaire (« de-staging »). Cela signifie que la capacité totale de stockage brute de votre cluster correspond à la somme de vos lecteurs de capacité uniquement.
Quand tous les lecteurs sont du même type, aucun cache n’est configuré automatiquement. Vous avez la possibilité de configurer des lecteurs plus endurants pour la mise en cache de lecteurs moins endurants du même type. Pour en savoir plus, consultez la section Configuration manuelle.
Conseil
Dans certains cas, l’utilisation du cache du pool de stockage n’a aucun sens. Par exemple, pour tous les déploiements constitués exclusivement de NVMe ou de SSD, particulièrement à une très petite échelle, le fait qu’aucun lecteur ne soit « sacrifié » pour le cache peut améliorer l’efficacité du stockage et optimiser les performances. De la même façon, les petits déploiements distants ou de succursales peuvent avoir un espace limité pour les lecteurs de cache.
Le comportement du cache est défini automatiquement
Le comportement du cache est déterminé automatiquement selon le ou les types de lecteurs pour lesquels s’effectue la mise en cache. Lors de la mise en cache pour les disques mémoire USB (telle que la mise en cache de NVMe pour des SSD), seules les écritures sont mises en cache. Lors de la mise en cache pour les lecteurs de disque rotatifs (telle que la mise en cache de SSD pour des HDD), les lectures et les écritures sont mises en cache.
Mise en cache d’écriture seule pour les déploiements 100 % flash
La mise en cache peut être utilisée dans un scénario 100 % flash. Par exemple, en utilisant NVMe comme cache pour accélérer les performances des SSD. Lors de la mise en cache pour tous les déploiements 100 % flash, seules les écritures sont mises en cache. Cela réduit l’usure des lecteurs de capacité, car un grand nombre d’écritures et de réécritures peuvent fusionner dans le cache, puis annuler leur stockage dès que cela est nécessaire, ce qui réduit le trafic cumulé à destination des lecteurs de capacité et prolonge leur durée de vie. C’est pour cette raison que nous vous recommandons d’opter pour des lecteurs de plus grande endurance, optimisés en écriture pour le cache. Les lecteurs de capacité peuvent avoir une endurance en écriture relativement faible.
Puisque les lectures n’affectent pas significativement la durée de vie de la mémoire flash et que les SSD offrent universellement une faible latence de lecture, les lectures ne sont pas mises en cache : elles sont traitées directement par les lecteurs de capacité (sauf lorsque l’écriture des données est trop récente pour avoir eu le temps de quitter leur stockage temporaire). Le cache est ainsi entièrement dédié aux écritures, ce qui maximise son efficacité.
Par conséquent, les caractéristiques d'écriture, comme la latence, sont dictées par les lecteurs de cache, alors que les caractéristiques de lecture sont dictées par les lecteurs de capacité. Dans les deux cas, les caractéristiques sont cohérentes, prévisibles et uniformes.
Mise en cache de lecture/écriture pour les déploiements hybrides
Lors de la mise en cache pour HDD, les lectures et les écritures sont mises en cache pour fournir une latence semblable à celle de la mémoire flash pour les deux (souvent 10x meilleure). Le cache de lecture stocke les données lues récemment et fréquemment pour permettre un accès rapide et limiter autant que possible le trafic aléatoire à destination des HDD. (En raison des délais de recherche et de rotation, la latence et le temps perdu causés par l'accès aléatoire à un disque dur sont considérables.) Les écritures sont mises en cache pour absorber les pics de trafic, et comme précédemment, vous pouvez regrouper les écritures et réécritures afin de réduire au maximum le trafic cumulatif sur les lecteurs de capacité.
Les espaces de stockage direct implémentent un algorithme qui fait perdre aux écritures leur caractère aléatoire avant de les supprimer de leur stockage, pour émuler un modèle d’E/S sur le disque qui paraît séquentiel, même lorsque les E/S réelles en provenance de la charge de travail (comme les machines virtuelles) sont aléatoires. Cela optimise les IOPS et le débit à destination des HDD.
Mise en cache dans les déploiements avec NVMe, SSD et HDD
Lorsque les trois types de lecteurs sont présents, les lecteurs NVMe assurent la mise en cache pour les SSD et les HDD. Le comportement est conforme à celui décrit précédemment : seules les écritures sont mises en cache pour les disques SSD, et aussi bien les lectures que les écritures sont mises en cache pour les HDD. La charge de la mise en cache pour les HDD est répartie de façon équitable entre les lecteurs de cache.
Résumé
Ce tableau récapitule les lecteurs utilisés pour la mise en cache et la capacité, et rappelle les comportements de cache associés à chaque déploiement.
| Déploiement | Lecteurs de cache | Lecteurs de capacité | Comportement de cache (par défaut) |
|---|---|---|---|
| NVMe uniquement | Aucun (facultatif : configuration manuelle) | NVMe | Écriture seule (si configuré) |
| SSD uniquement | Aucun (facultatif : configuration manuelle) | SSD | Écriture seule (si configuré) |
| NVMe + SSD | NVMe | SSD | Écriture seule |
| NVMe + HDD | NVMe | HDD | Lecture + écriture |
| SSD + HDD | SSD | HDD | Lecture + écriture |
| NVMe + SSD + HDD | NVMe | SSD + HDD | Lecture + écriture pour les HDD, écriture seule pour les SSD |
Architecture côté serveur
Le cache est mis en œuvre côté lecteur : les différents lecteurs formant le cache au niveau d'un serveur sont reliés à un ou plusieurs lecteurs de capacité au sein de ce même serveur.
Étant donné que le cache est situé sous le reste de la pile de stockage à définition logicielle Windows, les concepts d'espaces de stockage et de tolérance de panne ne sont pas implémentés, ni nécessaires. Vous pouvez voir cela comme la création de lecteurs « hybrides » (en partie flash, en partie disque) qui sont ensuite présentés au système d'exploitation. Comme avec un véritable lecteur hybride, le mouvement en temps réel des données à chaud et à froid entre les portions plus rapides et plus lentes du support physique est presque invisible de l'extérieur.
Étant donné que la résilience dans les espaces de stockage direct relève au moins du niveau serveur (à savoir que les copies des données sont toujours écrites sur différents serveurs, avec au moins une copie par serveur), les données en cache bénéficient de la même résilience que les données qui ne sont pas en cache.
Par exemple, dans le cas d’une mise en miroir triple, les données sont écrites en trois exemplaires sur différents serveurs, où elles sont placées dans le cache. Qu’elles soient par la suite supprimées du stockage temporaire ou non, il existe toujours trois copies.
Les liaisons de lecteurs sont dynamiques
La liaison entre un lecteur de cache et un lecteur de capacité peut avoir un ratio allant de 1:1 à 1:12 et au-delà. Il s’ajuste dynamiquement chaque fois que des lecteurs sont ajoutés ou supprimés, notamment en cas de scale-up ou à la suite de défaillances. Cela signifie que vous pouvez ajouter des lecteurs de cache ou des lecteurs de capacité de façon indépendante, quand vous le souhaitez.
Pour des raisons de symétrie, nous vous recommandons de faire en sorte que le nombre de lecteurs de capacité soit un multiple du nombre de lecteurs de cache. Par exemple, si vous avez quatre lecteurs de cache, vous obtiendrez des performances plus équilibrées avec huit lecteurs de capacité plutôt qu'avec sept ou neuf.
Gestion des défaillances de lecteur de cache
En cas de panne d'un lecteur de cache, les écritures qui n'ont pas encore été déstockées de ce dernier sont perdues pour le serveur local, autrement dit il ne reste que les autres copies (sur les autres serveurs). Comme après n’importe quelle autre défaillance de lecteur, les espaces de stockage peuvent récupérer automatiquement en consultant les copies restantes.
Pendant une courte période, les lecteurs de capacité qui étaient liés au lecteur de cache perdu apparaissent comme étant non sains. Une fois la liaison du cache rétablie et les données réparées (le tout automatiquement), ils retrouvent leur état sain.
Ce scénario souligne l’importance de disposer d’au moins deux lecteurs de cache par serveur pour préserver le niveau de performance.
Vous pouvez alors remplacer le lecteur de cache comme n’importe quel autre lecteur.
Notes
Vous pouvez être amené à mettre le système hors tension pour remplacer un lecteur NVMe ayant un facteur de forme AIC (Add-In Card) ou M.2.
Relation avec les autres caches
La pile de stockage à définition logicielle Windows compte plusieurs autres caches non liés. Tel est le cas du cache en écriture différée des espaces de stockage ou du cache de lecture en mémoire d’un volume partagé de cluster.
Avec Azure Stack HCI, le comportement par défaut du cache en écriture différée des espaces de stockage ne doit pas être modifié. Par exemple, certains paramètres de l’applet de commande New-volume, comme -WriteCacheSize, ne doivent pas être utilisés.
En revanche, vous êtes libre de choisir d’utiliser ou non le cache d’un volume partagé de cluster. Il est activé par défaut dans Azure Stack HCI, mais il n’entre en rien en conflit avec le cache décrit dans cette rubrique. Dans certains scénarios, il peut offrir des gains de performances précieux. Pour plus d’informations, consultez Utiliser le cache de lecture en mémoire CSV avec Azure Stack HCI.
Configuration manuelle
Dans la plupart des déploiements, aucune configuration manuelle n’est pas nécessaire. Cependant, si vous en avez besoin, consultez les sections suivantes.
Si vous devez apporter des modifications au modèle de dispositif de cache après l’installation, modifiez le document des composants de prise en charge du Service de contrôle d’intégrité, comme indiqué dans Vue d’ensemble du Service de contrôle d’intégrité.
Spécifier le modèle de lecteur de cache
Dans les déploiements où tous les lecteurs sont de même type (par exemple, uniquement NVMe ou uniquement SSD), aucun cache n'est configuré, car Windows ne distingue pas automatiquement les caractéristiques telles que l'endurance en écriture sur des lecteurs de même type.
Pour utiliser les lecteurs les plus endurants pour la mise en cache et les lecteurs les moins endurants pour la capacité, vous pouvez spécifier le modèle de lecteur à utiliser avec le paramètre -CacheDeviceModel de l'applet de commande Enable-ClusterS2D. Tous les lecteurs de ce modèle seront utilisés pour la mise en cache.
Conseil
Veillez à ce que la chaîne de modèle soit exactement la même que celle figurant dans la sortie de Get-PhysicalDisk.
Exemple
Pour commencer, obtenez la liste des disques physiques :
Get-PhysicalDisk | Group Model -NoElement
Voici un exemple de sortie :
Count Name
----- ----
8 FABRIKAM NVME-1710
16 CONTOSO NVME-1520
Entrez ensuite la commande suivante en spécifiant le modèle de dispositif de cache :
Enable-ClusterS2D -CacheDeviceModel "FABRIKAM NVME-1710"
Vous pouvez vérifier que les lecteurs que vous avez choisis sont utilisés pour le cache en exécutant Get-PhysicalDisk dans PowerShell et en vérifiant que la propriété Usage indique bien "Journal" .
Possibilités de déploiement manuel
La configuration manuelle offre les possibilités de déploiement suivantes :
Définir le comportement du cache
Il est possible de remplacer le comportement par défaut du cache. Par exemple, vous pouvez le configurer de façon à mettre en cache les lectures même dans un déploiement 100 % flash. Nous vous déconseillons de modifier le comportement par défaut, à moins que vous soyez certain qu’il n’est pas adapté à votre charge de travail.
Pour remplacer le comportement, utilisez l’applet de commande Set-ClusterStorageSpacesDirect et ses paramètres -CacheModeSSD et -CacheModeHDD. Le paramètre CacheModeSSD définit le comportement du cache lorsque la mise en cache concerne des SSD. Le paramètre CacheModeSSD définit le comportement du cache lorsque la mise en cache concerne des HDD.
Vous pouvez utiliser Get-ClusterStorageSpacesDirect pour vérifier que le comportement est défini.
Exemple
Tout d’abord, obtenez les paramètres de la fonctionnalité Espaces de stockage direct :
Get-ClusterStorageSpacesDirect
Voici un exemple de sortie :
CacheModeHDD : ReadWrite
CacheModeSSD : WriteOnly
Ensuite, procédez comme suit :
Set-ClusterStorageSpacesDirect -CacheModeSSD ReadWrite
Get-ClusterS2D
Voici un exemple de sortie :
CacheModeHDD : ReadWrite
CacheModeSSD : ReadWrite
Dimensionnement du cache
La taille du cache doit être définie en fonction des besoins de votre charge de travail ou de vos applications (les données lues ou écrites activement à un instant T).
Cela est particulièrement important dans les déploiements hybrides constitués de lecteurs de disque dur. Si les plages de travail actives sont plus volumineuses que votre cache ou si elles dérivent trop vite, le nombre de lectures manquées risque d'augmenter et il faudra déstocker les écritures plus agressivement, ce qui nuira aux performances globales.
Vous pouvez utiliser l’utilitaire intégré Analyseur de performances (PerfMon. exe) de Windows pour inspecter le taux d’absences dans le cache. Plus particulièrement, vous pouvez comparer la valeur Cache Miss Reads/sec au niveau du décompte Cluster Storage Hybrid Disk et le nombre total d'E/S par seconde en lecture de votre déploiement. Chaque « disque hybride » correspond à un lecteur de capacité.
Par exemple, 2 lecteurs de cache liés à 4 lecteurs de capacité donnent 4 instances d’objet « disque hybride » par serveur.
Il n'y a pas de règle universelle, mais si vous constatez qu'il manque trop de lectures au niveau du cache, ce dernier est probablement trop petit et vous devez envisager d'ajouter des lecteurs de cache. Vous pouvez ajouter des lecteurs de cache ou des lecteurs de capacité de façon indépendante, quand vous le souhaitez.
Étapes suivantes
Pour plus d’informations sur le stockage additionnel, consultez également :
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour