Types de stockage Azure pour une charge de travail SAP
Azure possède de nombreux types de stockage qui diffèrent notablement en termes de capacités, de débit, de latence et de prix. Certains des types de stockage ne sont pas, ou peu, utilisables pour les scénarios SAP. En revanche, plusieurs types de stockage Azure sont bien adaptés ou optimisés pour des scénarios de charge de travail SAP spécifiques. Pour SAP HANA en particulier, certains types de stockage Azure ont été certifiés pour être utilisés avec SAP HANA. Dans ce document, nous passons en revue les différents types de stockage et décrivons leur capacité et leur facilité d’utilisation avec les charges de travail et les composants SAP.
Remarquez les unités utilisées dans cet article. Les fournisseurs de cloud public ont décidé d'utiliser le Gio (Gibioctet) ou le Tio (Tebioctet) comme unités de taille, au lieu du gigaoctet ou du téraoctet. C’est pourquoi toute la documentation et la tarification Azure utilisent ces unités. Dans le document, nous référençons ces unités de taille en unités Mio, Gio et Tio exclusivement. Vous devrez peut-être planifier des Mo, des Go et des To. Par conséquent, vous devez tenir compte de quelques petites différences dans les calculs si vous devez dimensionner un débit de 400 Mio/s au lieu d’un débit de 250 Mio/s.
Résilience du Stockage Microsoft Azure
Le stockage Microsoft Azure comprenant des disques HDD Standard et SSD Standard, le Stockage Premium Azure, SSD Premium v2 et un disque Ultra conserve le disque dur virtuel de base (avec SE) et les disques de données attachés à des machines virtuelles ou les disques durs virtuels (VHD) sur trois nœuds de stockage différents. Le basculement vers un autre réplica et l’amorçage d’un nouveau réplica en cas de défaillance d’un nœud de stockage sont transparents. En raison de cette redondance, il n’est PAS nécessaire d’utiliser une quelconque couche de redondance de stockage sur plusieurs disques Azure. Il s’agit du stockage localement redondant (LRS). Le LRS est la valeur par défaut pour ces types de stockage dans Azure. Azure NetApp Files offre une redondance suffisante pour atteindre les mêmes contrats SLA (Accords au niveau du service) que les autres stockages Azure natifs.
Plusieurs autres méthodes de redondance, toutes décrites dans l’article Réplication du Stockage Azure, s’appliquent à certains types de stockage différents proposés par Azure.
Remarque
À l’aide du stockage Azure pour stocker les données de base de données et le fichier journal de restauration, LRS est le seul niveau de résilience pris en charge à ce stade
Gardez également à l’esprit que différents types de stockage Azure influencent la disponibilité de machine virtuelle unique. Les contrats SLA sont publiés dans Contrat SLA pour les machines virtuelles.
Disques managés Azure
Les disques managés sont un type de ressources d’Azure Resource Manager. Ils peuvent être utilisés à la place des disques durs virtuels qui sont stockés dans les comptes de stockage Azure. Les disques managés s’alignent automatiquement sur le [groupe à haute disponibilité][virtual-machines-manage-availability] de la machine virtuelle à laquelle ils sont attachés. Avec un tel alignement, vous noterez une amélioration de la disponibilité de votre machine virtuelle et des services qui s’exécutent dans la machine virtuelle. Pour plus d’informations, consultez l’article de vue d’ensemble.
Notes
Nous demandons à ce que les nouveaux déploiements de machines virtuelles qui utilisent le stockage de bloc Azure pour leurs disques (tout le stockage Azure sauf Azure NetApp Files et Azure Files) utilisent des disques managés Azure pour les disques VHD/de système d’exploitation de base et les disques de données qui stockent des fichiers de base de données SAP. Indépendamment de la nécessité de déployer les machines virtuelles via un groupe à haute disponibilité, sur Zones de disponibilité ou indépendamment des ensembles et des zones. Les disques utilisés pour stocker des sauvegardes ne doivent pas nécessairement être des disques managés.
Scénarios de stockage avec charges de travail SAP
Le stockage persistant est nécessaire dans la charge de travail SAP dans les différents composants de la pile que vous déployez dans Azure. Ces scénarios présentent des situations au moins similaires à celles-ci :
- Conservez le disque dur virtuel de base de votre machine virtuelle contenant le système d’exploitation et les autres logiciels que vous installez sur ce disque. Ce disque/disque dur virtuel est la racine de votre machine virtuelle. Toutes les modifications qui lui ont été apportées doivent être rendues persistantes. C’est pourquoi la prochaine fois que vous arrêtez et redémarrez la machine virtuelle, toutes les modifications apportées auparavant continuent d’exister. En particulier dans les cas où la machine virtuelle est déployée par Azure sur un autre hôte que celui qu’elle exécutait à l’origine
- Disques de données persistantes. Ces disques sont des disques durs virtuels que vous joignez pour y stocker des données d’application. Il peut s’agir de données et de fichiers journaux/de restauration par progression d’une base de données, de fichiers de sauvegarde ou d’installations de logiciels. Désigne tout disque au-delà de votre disque dur virtuel de base qui héberge le système d’exploitation
- Partages de fichiers ou disques partagés qui contiennent votre répertoire de transport global pour NetWeaver ou S/4HANA. Le contenu de ces partages est consommé par un logiciel s’exécutant sur plusieurs machines virtuelles ou utilisé pour créer des scénarios de cluster de basculement à haute disponibilité.
- Répertoire /sapmnt ou partages de fichiers communs pour les processus EDI (Échange de données informatisé) ou similaires. Le contenu de ces partages est consommé par un logiciel s’exécutant sur plusieurs machines virtuelles ou utilisé pour créer des scénarios de cluster de basculement à haute disponibilité.
Dans les sections suivantes, nous voyons les différents types de stockage Azure et leur utilisabilité dans les quatre scénarios de charge de travail SAP. L’article Quels sont les types de disque disponibles dans Azure ? répertorie les façons dont les différents types de stockage Azure doivent être utilisés. Les recommandations relatives à l’utilisation des différents types de stockage Azure pour la charge de travail SAP ne vont pas être très différentes.
Pour connaître les restrictions de prise en charge des types de stockage Azure pour SAP NetWeaver/la couche applicative de S/4HANA, consultez la note de support SAP 2015553. Pour connaître les types de stockage Azure certifiés et pris en charge par SAP HANA, lisez l’article Configurations du stockage des machines virtuelles SAP HANA Azure.
Les sections décrivant les différents types de stockage Azure vous donnent plus d’informations sur les restrictions et les possibilités d’utilisation du stockage que SAP prend en charge.
Options de stockage lors de l’utilisation de la réplication SGBD
Nos architectures de référence prévoient l’utilisation de fonctionnalités SGBD (Système de gestion de base de données) telles que SQL Server Always On, Réplication de système HANA, DB2 HADR ou Oracle Data Guard. Pour utiliser ces technologies entre deux machines virtuelles Azure ou plus, les types de stockage choisis pour chacune des machines virtuelles doivent être identiques. Cela signifie que la configuration de stockage entre le nœud actif et le nœud de réplica dans la configuration de haute disponibilité du SGBD doit être identique.
Recommandations de stockage pour les scénarios de stockage SAP
Avant d’aborder les détails, nous présentons le résumé et les recommandations au début du document. Tandis que les détails des types particuliers de stockage Azure suivent cette section du document. Voici un exemple de tableau récapitulatif des recommandations de stockage pour les scénarios de stockage SAP :
| Scénario d’usage | HDD Standard | SSD Standard | Stockage Premium | SSD Premium v2 | Disque Ultra | Azure NetApp Files | Fichiers Azure Premium |
|---|---|---|---|---|---|---|---|
| Disque de système d’exploitation | Non approprié | Restreint adapté (non prod) | Recommandé | Impossible | Impossible | Impossible | Impossible |
| Répertoire de transport global | Non prise en charge | Non prise en charge | Recommandé | Recommandé | Recommandé | Recommandé | Fortement recommandé |
| /sapmnt | Non approprié | Restreint adapté (non prod) | Recommandé | Recommandé | Recommandé | Recommandé | Fortement recommandé |
| Volume de données SGBD SAP HANA pour les familles de machines virtuelles M/Mv2 | Non prise en charge | Non prise en charge | Recommandé | Recommandé | Recommandé | Recommandé | Non pris en charge |
| Volume du journal SGBD SAP HANA pour les familles de machines virtuelles M/Mv2 | Non prise en charge | Non prise en charge | Recommandé1 | Recommandé | Recommandé | Recommandé | Non pris en charge |
| Volume de données SGBD SAP HANA pour les familles de machines virtuelles Esv3/Edsv4 | Non prise en charge | Non prise en charge | Recommandé | Recommandé | Recommandé | Recommandé | Non pris en charge |
| Volume du journal SGBD SAP HANA pour les familles de machines virtuelles Esv3/Edsv4 | Non prise en charge | Non pris en charge | Non prise en charge | Recommandé | Recommandé | Recommandé | Non pris en charge |
| Volume partagé HANA | Non pris en charge | Non prise en charge | Recommandé | Recommandé | Recommandé | Recommandé | Recommandé |
| Volume de données SGBD non HANA | Non prise en charge | Restreint adapté (non prod) | Recommandé | Recommandé | Recommandé | Uniquement pour des versions Oracle spécifiques sur Oracle Linux, Db2 et SAP ASE sur SLES/RHEL Linux | Non pris en charge |
| Volume du journal de SGBD non HANA des familles de machines virtuelles M/Mv2 | Non prise en charge | Restreint adapté (non prod) | Recommandé1 | Recommandé | Recommandé | Uniquement pour des versions Oracle spécifiques sur Oracle Linux, Db2 et SAP ASE sur SLES/RHEL Linux | Non pris en charge |
| Volume du journal de SGBD non HANA n’appartenant aux familles de machines virtuelles M/Mv2 | Non prise en charge | restreint adapté (non prod) | Convient pour une charge de travail faible à moyenne | Recommandé | Recommandé | Uniquement pour des versions Oracle spécifiques sur Oracle Linux, Db2 et SAP ASE sur SLES/RHEL Linux | Non pris en charge |
1 Avec utilisation de l’Accélérateur d’écriture Azure pour les familles de machines virtuelles M/Mv2 et les volumes journal/restauration par progression
Caractéristiques que vous pouvez attendre des types de stockage différents :
| Scénario d’usage | HDD Standard | SSD Standard | Stockage Premium | SSD Premium v2 | Disque Ultra | Azure NetApp Files | Fichiers Azure Premium |
|---|---|---|---|---|---|---|---|
| SLA de débit/IOPS | Non | Non | Oui | Oui | Oui | Oui | Oui |
| Lectures de latence | Élevé | Moyen à élevé | Faible | inférieur à la milliseconde | inférieur à la milliseconde | inférieur à la milliseconde | low |
| Écritures de latence | Élevé | Moyen à élevé | Faible (inférieure à la milliseconde1) | inférieur à la milliseconde | inférieur à la milliseconde | inférieur à la milliseconde | low |
| HANA pris en charge | Non | Non | Oui1 | Oui | Oui | Oui | Non |
| Captures instantanées de disque possibles | Oui | Oui | Oui | Oui3 | Non 2 | Oui | Non |
| Allocation de disques sur différents clusters de stockage lors de l’utilisation de groupes à haute disponibilité | Via des disques managés | Via des disques managés | Via des disques managés | Type de disque non pris en charge avec les machines virtuelles déployées via des groupes à haute disponibilité | Type de disque non pris en charge avec les machines virtuelles déployées via des groupes à haute disponibilité | Non3 | Non |
| Aligné avec les Zones de disponibilité | Oui | Oui | Oui | Oui | Oui | En préversion publique | Non |
| Redondance de zone synchrone | Pas pour les disques managés | Pas pour les disques managés | Non pris en charge pour le SGBD | Non | Non | Non | Oui |
| Redondance de zone asynchrone | Pas pour les disques managés | Pas pour les disques managés | Non pris en charge pour le SGBD | Non | Non | En préversion | Non |
| Redondance géographique | Pas pour les disques managés | Pas pour les disques managés | Non | Non | Non | Possible | Non |
1 Avec utilisation de l’Accélérateur d’écriture Azure pour les familles de machines virtuelles M/Mv2 et les volumes journal/restauration par progression
2 La création de différents pools de capacité Azure NetApp Files ne garantit pas le déploiement de pools de capacité sur des unités de stockage différentes
3 Les instantanés (incrémentiels) d’un disque SSD Premium v2 ou SSD Ultra ne peuvent pas être utilisées immédiatement après leur création. La copie en arrière-plan doit être terminée avant de pouvoir créer un disque à partir de l’instantané
Important
Consultez la section Azure NetApp Files de ce document pour trouver des détails sur le placement de proximité des volumes NFS et des machines virtuelles quand vous avez besoin de latences inférieures à 1 milliseconde.
Stockage Premium Azure
Le stockage SSD Premium Azure a été introduit dans le but de fournir les avantages suivants :
- Faible latence des E/S
- Contrat de niveau de service pour les IOPS et le débit
- Moins de variabilité dans la latence des E/S
Ce type de stockage cible les charges de travail SGBD, le trafic de stockage qui nécessite une latence de moins de 10 millisecondes et les contrats SLA sur les IOPS et le débit. Pour le Stockage Premium Azure, les coûts ne sont pas basés sur le volume réel de données stocké dans les disques, mais sur la catégorie de taille du disque, sans tenir compte de la quantité de données stockée sur celui-ci. Vous pouvez également créer des disques dans Stockage Premium qui ne sont pas directement mappés aux catégories de taille présentées dans l’article SSD Premium. Les conclusions de cet article sont les suivantes :
- Le stockage est organisé en plages. Par exemple, un disque dans la plage 513 Gio à 1024 Gio partage les mêmes fonctionnalités et les mêmes coûts mensuels
- Les IOPS par Gio ne suivent pas de manière linéaire les catégories de taille. Les petits disques de moins de 32 Gio ont des taux d'IOPS par Gio plus élevés. Pour les disques entre 32 Gio et 1024 Gio, le taux d'IOPS par Gio se situe entre 4 et 5 IOPS par Gio. Pour les disques plus volumineux jusqu'à 32 767 Gio, le taux d’IOPS par Gio est inférieur à 1
- Le débit d’entrée/sortie de ce stockage n’est pas linéaire avec la taille de la catégorie de disque. Pour les disques plus petits, comme la catégorie entre 65 Gio et 128 Gio de capacité, le débit est d’environ 780 Ko par Gio. Pour les disques de très grande taille, comme un disque de 32 767 Gio, le débit est de 28 ko par Gio
- Les contrats SLA d’IOPS et de débit ne peuvent pas être changés sans changer la capacité du disque
La matrice de capacité pour la charge de travail SAP ressemble à ceci :
| Fonctionnalité | Commentaire | Remarques/liens |
|---|---|---|
| Disque dur virtuel de base du système d’exploitation | Approprié | Tous les systèmes |
| Disque de données | Approprié | Tous les systèmes - spécialement pour SAP HANA |
| Répertoire de transport global SAP | Oui | Pris en charge |
| SAP sapmnt | Approprié | Tous les systèmes |
| Stockage de sauvegarde | Approprié | Pour le stockage à court terme des sauvegardes |
| Partages/disque partagé | Non disponible | Nécessite des fichiers Azure Premium ou des fournisseurs tiers |
| Résilience | LRS | Aucun GRS ou ZRS n’est disponible pour les disques |
| Latence | Faible à moyen | - |
| Contrat de niveau de service IOPS | Oui | - |
| IOPS linéaires à la capacité | semi-linéaire entre crochets | Tarification des disques managés |
| Maximum d’E/S par seconde par disque | 20 000 dépendant de la taille du disque | Tenez également compte des limites de machine virtuelle |
| SLA de débit | Oui | - |
| Débit linéaire par rapport à la capacité | Semi-linéaire entre crochets | Tarification des disques managés |
| Certifié HANA | Oui | spécialement pour SAP HANA |
| Prise en charge de l’Accélérateur des écritures Azure | Non | - |
| Mode rafale des disques | Oui | - |
| Captures instantanées de disque possibles | Oui | - |
| Captures instantanées de machines virtuelles Sauvegarde Azure possibles | Oui | - |
| Coûts | Moyenne | - |
Le stockage premium Azure ne remplit pas les KPI de latence du stockage SAP HANA avec les types de cache courants proposés avec le stockage premium Azure. Afin de remplir les KPI de latence de stockage pour les écritures de log SAP HANA, vous devez utiliser la mise en cache d’Accélérateur d'écriture Azure comme décrit dans l'article Activer l’Accélérateur d’écriture. Accélérateur d’écriture Azure tire parti de tous les autres systèmes SGBD pour l’écriture du journal des transactions et la restauration des écritures de journal. Par conséquent, il est recommandé de l’utiliser dans tous les déploiements de SGBD SAP. Pour SAP HANA, l’utilisation d’Accélérateur d’écriture Azure est obligatoire pour /hana/log avec le Stockage Premium Azure.
Résumé : Le Stockage premium Azure est l'un des types de stockage Azure recommandé pour la charge de travail SAP. Cette recommandation s’applique aux systèmes de production et hors production. Le Stockage premium Azure est adapté pour gérer les charges de travail des bases de données. L’utilisation d’Accélérateur d’écriture Azure va améliorer considérablement la latence d’écriture sur les disques premium Azure. Cependant, pour les systèmes de SGBD avec des taux d’IOPS et de débit élevés, vous devez soit surprovisionner la capacité de stockage, soit utiliser des fonctionnalités comme les Espaces de stockage Windows ou les gestionnaires de volumes logiques sous Linux pour créer des ensembles de bandes qui vous donnent la capacité souhaitée. Mais aussi les IOPS nécessaires ou le débit au meilleur coût d’efficacité.
Fonctionnalité en rafale Azure pour le stockage Premium
Pour les disques de stockage Premium Azure plus petits ou égaux à 512 Gio en capacité, une fonctionnalité en rafale est proposée. Le fonctionnement exact du mode rafale des disques est décrit dans l’article Mode rafale des disques. En lisant cet article, vous comprendrez le concept d’IOPS et de débit dans les cas où votre charge de travail d’E/S se trouve au-dessous des valeurs d’IOPS et de débit nominales des disques (pour plus d’informations sur le débit nominal, consultez Tarification des disques managés). Vous allez cumuler le delta d’IOPS et de débit entre votre utilisation actuelle et les valeurs nominales du disque. Les rafales sont limitées à un maximum de 30 minutes.
Idéalement, cette fonctionnalité en rafales sera planifiée pour des volumes ou disques contenant des fichiers de données pour les différents SGBD. La charge de travail d’E/S attendue pour ces volumes, en particulier avec les systèmes de petite ou moyenne taille, devrait ressembler à ceci :
- Charge de travail faible à modérée, car les données sont idéalement mises en cache dans la mémoire ou, comme avec SAP HANA, sont complètement en mémoire
- Rafales d’écritures déclenchées par des points de contrôle de base de données ou des points d’enregistrement émis régulièrement
- Charge de travail de sauvegarde qui lit un flux continu dans les cas où les sauvegardes ne sont pas exécutées via des captures instantanées de stockage
- Pour SAP HANA, charger les données en mémoire après le redémarrage d’une instance
En particulier sur les systèmes SGBD plus petits dans lesquels votre charge de travail gère uniquement quelques centaines de transactions par seconde, une telle fonctionnalité en rafales peut également être utile pour les disques ou volumes qui stockent la transaction ou le journal de rétablissement. La charge de travail attendue sur un disque ou plusieurs volumes ressemble à ceci :
- Des écritures régulières sur le disque qui dépendent de la charge de travail et de la nature de la charge de travail, étant donné que chaque validation émise par l’application est susceptible de déclencher une opération d’E/S
- Une charge de travail plus élevée en débit pour les tâches opérationnelles, par exemple la création ou la reconstruction d’index
- Des rafales d’écritures lorsque vous effectuez des sauvegardes du journal des transactions ou du journal de rétablissement
SSD Premium Azure v2
Le stockage SSD Premium v2 Azure est une nouvelle version du stockage Premium qui a été introduite avec l’objectif de fournir :
- Latence des E/S inférieure à la milliseconde pour des tailles d’E/S de lecture et d’écriture plus petites
- Contrat de niveau de service pour les IOPS et le débit
- Paiement de la capacité par Go approvisionné
- Mise à disposition d’un ensemble par défaut d’IOPS et de débit de stockage par disque
- Possibilité d’ajouter davantage d’IOPS et de débit à chaque disque et de payer séparément pour ces ressources provisionnées supplémentaires
- Certification SAP HANA passée sans l’aide d’autres fonctionnalités comme l’Accélérateur d’écriture Azure ou d’autres caches
Ce type de stockage cible les charges de travail SGBD, le trafic de stockage qui nécessite une latence de moins de 1 milliseconde et les contrats SLA sur les IOPS et le débit. Les disques SSD Premium v2 sont fournis avec un ensemble par défaut de 3 000 IOPS et 125 Mbits/s. Et la possibilité d’ajouter davantage d’IOPS et de débit à des disques individuels. La tarification du stockage est structurée de manière à ce que l’ajout de plus de débit ou d’IOPS n’influence pas lourdement le prix. Néanmoins, nous vous laissons décider de la façon dont vous gérerez la configuration de votre stockage pour SSD Premium v2. Pour commencer, lisez Configurations du stockage SSD Premium v2 des machines virtuelles SAP HANA Azure.
Pour connaître les régions dans lesquelles ce nouveau type de stockage de bloc est disponible et les restrictions réelles, consultez le document SSD Premium v2.
La matrice de capacité pour la charge de travail SAP ressemble à ceci :
| Fonctionnalité | Commentaire | Remarques/liens |
|---|---|---|
| Disque dur virtuel de base du système d’exploitation | Non pris en charge | Aucun système |
| Disque de données | Approprié | Tous les systèmes |
| Répertoire de transport global SAP | Oui | Tous les systèmes |
| SAP sapmnt | Approprié | Tous les systèmes |
| Stockage de sauvegarde | Approprié | Pour le stockage à court terme des sauvegardes |
| Partages/disque partagé | Non disponible | Nécessite Azure Premium Files ou Azure NetApp Files |
| Résilience | LRS | Aucun GRS ou ZRS n’est disponible pour les disques |
| Latence | inférieur à la milliseconde | - |
| Contrat de niveau de service IOPS | Oui | - |
| IOPS linéaires à la capacité | semi-linéaire | Tarification des disques managés |
| Maximum d’E/S par seconde par disque | 80 000 en fonction de la taille du disque | Tenez également compte des limites de machine virtuelle |
| SLA de débit | Oui | - |
| Débit linéaire par rapport à la capacité | Semi-linéaire | Tarification des disques managés |
| Certifié HANA | Oui | - |
| Prise en charge de l’Accélérateur des écritures Azure | Non | - |
| Mode rafale des disques | Non | - |
| Captures instantanées de disque possibles | Oui1 | - |
| Captures instantanées de machines virtuelles Sauvegarde Azure possibles | Oui | - |
| Coûts | Moyenne | - |
1 Les captures instantanées (incrémentielles) d’un disque SSD Premium v2 ou SSD Ultra ne peuvent pas être utilisées immédiatement après leur création. La copie en arrière-plan doit être terminée avant de pouvoir créer un disque à partir de l’instantané
Face au stockage Premium Azure, le SSD Premium Azure v2 répond aux indicateurs de performance clés de latence de stockage de SAP HANA. Par conséquent, vous N’AVEZ PAS besoin d’utiliser la mise en cache de l’Accélérateur d’écriture Azure comme décrit dans l’article Activer l’accélérateur d’écriture.
Résumé : Azure SSD Premium v2 est le stockage en bloc qui présente le meilleur rapport prix/performances pour les charges de travail SAP. SSD Premium Azure v2 est adapté pour gérer les charges de travail des bases de données. La latence inférieure à la milliseconde en fait un stockage idéal pour les charges de travail SGBD exigeantes, Bien que ce type de stockage ne soit disponible que depuis novembre 2022. Par conséquent, il peut encore y avoir des limitations qui vont disparaître au cours des prochains mois.
Disque Ultra Azure
Les disques Ultra Azure fournissent un stockage sur disque présentant un débit élevé, un nombre d’IOPS élevé et une faible latence homogène pour les machines virtuelles Azure IaaS. Entre autres avantages, les disques Ultra permettent de changer dynamiquement les IOPS et le débit des disques en fonction de vos charges de travail sans avoir à redémarrer les machines virtuelles. Les disques Ultra sont adaptés aux charges de travail à forte intensité de données telles que la charge de travail du SGBD SAP. Les disques Ultra ne peuvent être utilisés que comme disques de données et comme disque virtuel de base qui stocke le système d'exploitation. Nous recommandons l’utilisation du Stockage Premium Azure en tant que disque dur virtuel.
En créant un disque Ultra, vous disposez de trois dimensions que vous pouvez définir :
- Capacité du disque. Les plages sont comprises entre 4 Gio et 65 536 Gio
- IOPS provisionnées pour le disque. Des valeurs maximales différentes s’appliquent à la capacité du disque. Lire l’article Disque Ultra pour plus de détails
- Bande passante de stockage approvisionnée. Une bande passante maximale différente s’applique en fonction de la capacité du disque. Lire l’article Disque Ultra pour plus de détails
Le coût d’un seul disque est déterminé par les trois dimensions que vous pouvez définir pour les disques spécifiques séparément.
La matrice de capacité pour la charge de travail SAP ressemble à ceci :
| Fonctionnalité | Commentaire | Remarques/liens |
|---|---|---|
| Disque dur virtuel de base du système d’exploitation | Ne fonctionne pas | - |
| Disque de données | Approprié | Tous les systèmes |
| Répertoire de transport global SAP | Oui | Pris en charge |
| SAP sapmnt | Approprié | Tous les systèmes |
| Stockage de sauvegarde | Approprié | Pour le stockage à court terme des sauvegardes |
| Partages/disque partagé | Non disponible | A besoin d’un tiers |
| Résilience | LRS | Aucun GRS ou ZRS n’est disponible pour les disques |
| Latence | Très faible | - |
| Contrat de niveau de service IOPS | Oui | - |
| IOPS linéaires à la capacité | Semi-linéaire entre crochets | Tarification des disques managés |
| Maximum d’E/S par seconde par disque | 1 200 à 160 000 | dépend de la capacité du disque |
| SLA de débit | Oui | - |
| Débit linéaire par rapport à la capacité | Semi-linéaire entre crochets | Tarification des disques managés |
| Certifié HANA | Oui | - |
| Prise en charge de l’Accélérateur des écritures Azure | Non | - |
| Mode rafale des disques | Oui | - |
| Captures instantanées de disque possibles | Oui1 | - |
| Captures instantanées de machines virtuelles Sauvegarde Azure possibles | Oui | - |
| Coûts | Supérieur au stockage Premium | - |
1 Les captures instantanées (incrémentielles) d’un disque SSD Premium v2 ou SSD Ultra ne peuvent pas être utilisées immédiatement après leur création. La copie en arrière-plan doit être terminée avant de pouvoir créer un disque à partir de l’instantané
Résumé : Les disques Ultra Azure constituent un stockage adapté à faible latence (moins d’une milliseconde) pour toutes sortes de charges de travail SAP. Jusqu’à présent, il n’est possible d’utiliser un disque Ultra que conjointement avec des machines virtuelles déployées par le biais de Zones de disponibilité Azure (déploiement zonal). Contrairement à tous les autres types de stockage, le disque Ultra ne peut pas être utilisé comme disque dur virtuel de base. Un disque Ultra est idéal pour les cas où la charge de travail d’E/S fluctue énormément et que vous souhaitez adapter le débit de stockage déployé ou les IOPS aux modèles de charge de travail de stockage au lieu de dimensionner l’utilisation maximale de la bande passante et des IOPS.
Azure NetApp Files
Azure NetApp Files est un service de stockage de fichiers Azure natif, interne, de classe entreprise et hautes performances certifié pour une utilisation avec SAP HANA. Il fournit des Volumes en tant que service pour lesquels vous pouvez créer des comptes NetApp, des pools de capacité et des volumes. Avec Azure NetApp Files, vous pouvez sélectionner des niveaux de performance et de service et gérer la protection des données pour créer et gérer des partages de fichiers hautes performances, hautement disponibles et scalables, avec des protocoles et des outils que vous connaissez déjà et sur lesquels vous vous appuyez localement.
Les types de charge de travail SAP suivants sont pris en charge sur les volumes Azure NetApp Files :
- Charge de travail SGBD SAP
- Partage SAPMNT
- Répertoire de transport global
Azure NetApp Files est disponible dans trois niveaux de service, chacun avec ses propres spécifications de débit et de tarification. Le niveau le plus adapté à votre déploiement dépend de la taille de celui-ci. Des recommandations de dimensionnement personnalisées sont disponibles dans l’estimateur TCO SAP sur Azure NetApp Files.
Pour plus d’informations sur les niveaux de service, consultez Niveaux de service pour Azure NetApp Files.
Déploiement de volumes
Pour obtenir des résultats optimaux, utilisez le groupe de volumes d’applications pour SAP HANA pour déployer les volumes. Le groupe de volumes d’applications place des volumes à des emplacements optimaux de l’infrastructure Azure à l’aide de règles d’affinité et d’anti-affinité pour réduire la contention et permettre le meilleur débit et la latence la plus faible.
Remarque
Les pools de capacité sont une unité d’approvisionnement de base pour Azure NetApp Files. Les pools de capacité sont proposés à partir d’une taille de 1 Tio ; vous pouvez développer un pool de capacités par incréments de 1 Tio. Les pools de capacité sont l’unité parente pour les volumes. Pour plus d’informations sur le dimensionnement, consultez les Limites de ressources Azure NetApp Files. Pour connaître la tarification, consultez la Tarification d’Azure NetApp Files.
Azure NetApp Files est pris en charge pour plusieurs scénarios de charge de travail SAP :
- Déploiements SAP HANA utilisant des partages NFS pour des volumes /hana/data et /hana/log pour des volumes /hana/shared comme documenté dans les Configurations de stockage des machines virtuelles Azure SAP HANA
- Fourniture de partages SMB ou NFS pour le répertoire de transport global SAP
- Le partage sapmnt dans les scénarios de haute disponibilité, comme décrit dans :
- Haute disponibilité pour SAP NetWeaver sur des machines virtuelles Azure sur Windows avec Azure NetApp Files (SMB) pour les applications SAP
- Haute disponibilité pour SAP NetWeaver sur les machines virtuelles Azure sur SUSE Linux Enterprise Server avec Azure NetApp Files pour les applications SAP
- Haute disponibilité des machines virtuelles Azure pour SAP NetWeaver sur Red Hat Enterprise Linux avec Azure NetApp Files pour les applications SAP
- IBM Db2 dans la machine virtuelle Azure basée sur Suse ou Red Hat Linux
- SAP sur les déploiements Oracle dans un système d’exploitation invité Oracle Linux à l’aide de dNFS pour les volumes de données Oracle et de journalisation de progression. Pour plus d’informations, consultez l’article Déploiement de SGBD Oracle sur les machines virtuelles Azure pour la charge de travail SAP
- SAP sur ASE dans le système d’exploitation invité Suse ou Red Hat Linux
- AP sur MAXDB dans le système d’exploitation invité Suse ou Red Hat Linux
- SAP sur Microsoft SQL Server avec des volumes SMB
Remarque
Pour les charges de travail SGBD sur Linux, utilisez des volumes basés sur NFS sur Azure NetApp Files.
Découplage du débit à partir de la taille du volume
Le stockage pour les applications de base de données a généralement des exigences de débit qui n’évoluent pas linéairement avec la taille des volumes. C’est-à-dire que les volumes de journaux sont relativement petits, mais nécessitent des niveaux élevés de débit.
Azure NetApp Files vous permet d’allouer le débit de volume indépendamment des tailles de volume lors de l’utilisation d’un pool de capacités de type QoS manuelle.
Voici un exemple :
- Un volume pour des fichiers de base de données nécessite un débit de 500 Mio/s et une capacité de 39 Tio
- Un volume pour des fichiers journaux nécessite un débit de 2000 Mio/s et une capacité de 1 Tio
Vous pouvez créer un pool de capacité QoS manuelle pour ce scénario et allouer le débit indépendamment des tailles de volume. La capacité totale requise est de 40 Tio, et le budget de débit total est de 2500 Mio/s. Un pool de capacités au niveau de service Premium (64 Mio/s par Tio alloué) prend en charge les exigences de performances et de capacité (40 Mio * 64 io/s/Tio = 2560 Mio).
La mise à l’échelle linéaire des performances nécessiterait une surapprovisionnement considérable du volume du fichier journal pour atteindre l’exigence de débit. Pour atteindre le débit de 2000 Mio/s pour le volume de journal, vous devriez déployer un pool de capacité au niveau Ultra (128 Mio/s par Tio allouée) de 16 Tio, ce qui entraîne un suraprovisionnement et donc une perte de capacité de 15 Tio.
Utilisez la calculatrice de performances Azure NetApp Files pour obtenir une estimation pour votre scénario.
La matrice de capacité pour la charge de travail SAP sur Azure NetApp Files ressemble à ceci :
| Fonctionnalité | Commentaire | Remarques/liens |
|---|---|---|
| Disque dur virtuel de base du système d’exploitation | Utilisation d’un disque managé | - |
| Disque de données | Approprié | SAP HANA, Oracle sur Oracle Linux, DB2 et SAP ASE sur SLES/RHEL, MAXDB, SQL Server |
| Répertoire de transport global SAP | Oui | SMB (Windows uniquement) et NFS (Linux uniquement) |
| SAP sapmnt | Approprié | SMB (Windows uniquement) ou NFS (Linux uniquement) |
| Stockage de sauvegarde | Approprié | Utiliser des instantanés et/ou une sauvegarde Azure NetApp Files ; La sauvegarde de journal pour HANA peut également être utilisée comme destination de sauvegarde basée sur des fichiers |
| Partages/disque partagé | Oui | SMB, NFS |
| Résilience | LRS et GRS | GRS avec une réplication inter-régions ; ZRS avec une réplication interzone |
| Latence | Très faible | Généralement moins de 1 ms |
| Contrat de niveau de service IOPS | Oui | - |
| IOPS linéaires à la capacité | Linéaire avec QoS automatique, configurable indépendamment avec une QoS manuelle | Trois niveaux de service disponibles |
| SLA de débit | Oui | Les recommandations de dimensionnement sont disponibles dans l’estimateur TCO SAP sur Azure NetApp Files |
| Débit linéaire par rapport à la capacité | Linéaire avec QoS automatique, configurable indépendamment avec une QoS manuelle | Trois niveaux de service disponibles |
| Certifié HANA | Oui | - |
| Captures instantanées de disque possibles | Oui | Consulter Comment fonctionnent les snapshots Azure NetApp Files |
| Instantané cohérent des applications et orchestration de sauvegarde | Non | Utiliser AzAcSnap ou SnapCenter |
| Coûts | Utiliser des outils d’estimation de TCO | Utiliser l’estimateur de TCO SAP sur Azure NetApp Files et entrez la taille du paysage |
Autres fonctionnalités intégrées du stockage Azure NetApp Files :
- Possibilité d’effectuer des instantanés cohérents d’application de volume à l’aide de AzAcSnap
- Clonage des volumes Azure NetApp Files à partir d’instantanés pour les tests et le développement
- Restauration de volumes à partir d’instantanés (restauration enfichable) pour les restaurations rapides en cas d’altérations et les erreurs
Important
Pour les déploiements de base de données en particulier, vous avez besoin de faibles latences, au moins pour vos journaux de restauration. Pour SAP HANA en particulier, SAP nécessite une latence inférieure à 1 milliseconde pour les écritures de journal de restauration HANA dont la taille est plus petite. Pour obtenir ces latences, consultez les possibilités ci-dessous.
Important
Lors du déploiement des volumes Azure NetApp Files, notez la zone dans laquelle les machines virtuelles sont ou seront déployées. Veillez à sélectionner la même zone. Cette fonctionnalité est documentée dans l’article Gérer le placement des volumes de zone de disponibilité pour Azure NetApp Files. Le groupe de volumes d’applications pour SAP HANA utilise la même fonctionnalité pour déployer les volumes le plus près possible des machines virtuelles d’application.
L’intérêt de ce type d’alignement de zone de disponibilité est la réduction de la surface de risque en ayant les partages NFS dans la même zone de disponibilité que les machines virtuelles d’application.
- Déployez des volumes Azure NetApp Files pour votre déploiement SAP HANA à l’aide de groupe de volumes d’applications pour SAP HANA. L’avantage du groupe de volumes d’applications est que les volumes de données sont déployés sur plusieurs points de terminaison de stockage, ce qui réduit la contention réseau et améliore les performances.
Résumé: Azure NetApp Files est une solution de stockage à faible latence certifiée pour SAP HANA. Le service fournit des volumes sculptés sur un ou plusieurs pools de capacité. Les pools de capacité sont disponibles dans trois niveaux de service qui définissent la capacité totale et le débit alloués. Les volumes peuvent être redimensionnés et le débit alloué peut être ajusté sans interruption de service pour répondre aux besoins changeants et contrôler les coûts. Le service fournit des fonctionnalités permettant de répliquer des volumes vers d’autres régions ou zones à des fins de reprise d’activité et de continuité d’activité.
Fichiers Azure Premium
Azure Premium Files est un stockage partagé qui offre SMB et NFS pour un prix modéré et une latence suffisante pour gérer les partages de la couche application de SAP. En outre, Azure Premium Files offre une réplication zonale synchrone des partages avec un automatisme qui, en cas d’échec d’un réplica, permet à un autre réplica dans une autre zone de prendre le relais. Contrairement à Azure NetApp Files, il n’existe aucun niveau de performances. Il n’est pas nécessaire de disposer d’un pool de capacité. La facturation est basée sur la capacité réelle approvisionnée des différents partages. Azure Premium Files n’a pas du tout été testé en tant que stockage de SGBD pour une charge de travail SAP. Mais au lieu de cela, le scénario d’utilisation de la charge de travail SAP s’est concentré sur tous les types de partages SMB et NFS, car ils sont utilisés sur la couche application de SAP. Azure Premium Files est également adapté à l’utilisation de /hana/shared.
Notes
Pour l’instant, aucune charge de travail SAP DBMS n’est prise en charge sur les volumes partagés basés sur Azure Premium Files.
Scénarios SAP pris en charge sur Azure Premium Files :
- Fourniture de partages SMB ou NFS pour le répertoire de transport global SAP
- Utilisation en tant que partage pour les interfaces avec les systèmes SAP et les processus EDI
- Le partage sapmnt dans les scénarios de haute disponibilité, comme décrit dans :
- Haute disponibilité pour SAP NetWeaver sur les machines virtuelles Azure sur SUSE Linux Enterprise Server avec NFS sur Azure Files
- Haute disponibilité pour SAP NetWeaver sur les machines virtuelles Azure sur Red Hat Enterprise Linux avec NFS sur Azure Files
- Haute disponibilité pour SAP NetWeaver sur des machines virtuelles Azure sous Windows avec Azure Files Premium SMB pour les applications SAP
- Haute disponibilité pour système scale-out SAP HANA avec montée en puissance parallèle avec HSR sur SUSE Linux Enterprise Server
Azure Premium Files commence par une plus grande quantité d’IOPS à la taille minimale de partage de 100 Go par rapport à Azure NetApp Files. Cette barre plus élevée d’IOPS peut éviter le surprovisionnement de capacité pour atteindre certaines valeurs d’IOPS et de débit. Pour les IOPS et le débit de stockage, lisez la section Objectifs de performance et d’extensibilité d’Azure Files dans les objectifs d’extensibilité et de performance d’Azure Files.
Remarque
En raison de l’architecture hiérarchisée d’Azure Premium Files, la latence d’accès aux métadonnées des fichiers stockés dans des partages est nettement supérieure à celle d’Azure NetApp Files. Cette latence plus élevée peut avoir un impact sur la création et la suppression de fichiers, par exemple. Mais elle peut également avoir un impact notable sur le temps nécessaire au listage du contenu des grands répertoires contenant des centaines de milliers de fichiers. Le cas d’usage principal lors duquel nous voyons cette latence de métadonnées plus élevée est l’utilisation en tant que partage d’interface, où les clients peuvent rencontrer des centaines de milliers ou même des millions de créations de fichiers et des suppressions de masse tous les jours. Par conséquent, vous devez tester les scénarios de partage d’interface avec diligence. Pour déterminer si votre charge de travail est lourde en métadonnées, consultez Charge de travail lourde en métadonnées ou en espaces de noms
La matrice de capacité pour la charge de travail SAP ressemble à ceci :
| Fonctionnalité | Commentaire | Remarques/liens |
|---|---|---|
| Disque dur virtuel de base du système d’exploitation | Ne fonctionne pas | - |
| Disque de données | Non pris en charge pour les charges de travail SAP | - |
| Répertoire de transport global SAP | Oui | SMB et NFS |
| SAP sapmnt | Approprié | Tous les systèmes SMB (Windows uniquement) ou NFS (Linux uniquement) |
| Stockage de sauvegarde | Approprié | - |
| Partages/disque partagé | Oui | SMB 3.0, NFS v4.1 |
| Résilience | LRS et ZRS | Pas de GRS disponible pour Azure Premium Files |
| Latence | low | - |
| Contrat de niveau de service IOPS | Oui | - |
| IOPS linéaires à la capacité | strictement linéaire | - |
| SLA de débit | Oui | - |
| Débit linéaire par rapport à la capacité | strictement linéaire | - |
| Certifié HANA | Non | - |
| Captures instantanées de disque possibles | Oui | - |
| Captures instantanées de machines virtuelles Sauvegarde Azure possibles | Non | - |
| Coûts | low | - |
Résumé : Azure Premium Files est un stockage à faible latence qui permet de déployer des volumes ou des partages NFS et SMB. Azure Premium Files offre un excellent rapport prix/performances pour les partages de couche application SAP. Il fournit également une réplication zonale synchrone pour ces partages. Jusqu’à présent, nous ne prenons pas en charge ce type de stockage pour la charge de travail SGBD SAP. Il peut toutefois aussi être utilisé pour des volumes /hana/shared.
Stockage SSD Standard Azure
Par rapport aux disques HDD Standard Azure, les disques SSD Standard Azure offrent une disponibilité, une cohérence, une fiabilité et une latence meilleures. Ce stockage est optimisé pour les charges de travail qui nécessitent une performance constante aux niveaux d’IOPS inférieurs. Il s’agit du stockage minimal utilisé pour les systèmes SAP hors production qui présentent des demandes d’IOPS et de débit faibles. La matrice de capacité pour la charge de travail SAP ressemble à ceci :
| Fonctionnalité | Commentaire | Remarques/liens |
|---|---|---|
| Disque dur virtuel de base du système d’exploitation | Restreint adapté | Systèmes de non-production |
| Disque de données | Restreint adapté | Certains systèmes hors production avec des demandes d’IOPS et de latence faibles |
| Répertoire de transport global SAP | Non | Non pris en charge |
| SAP sapmnt | Restreint adapté | Systèmes de non-production |
| Stockage de sauvegarde | Approprié | - |
| Partages/disque partagé | Non disponible | A besoin d’un tiers |
| Résilience | LRS, GRS | Aucun ZRS disponible pour les disques |
| Latence | high | Trop élevé pour le répertoire de transport global SAP ou les systèmes de production |
| Contrat de niveau de service IOPS | Non | - |
| Maximum d’E/S par seconde par disque | 500 | Indépendamment de la taille du disque |
| SLA de débit | Non | - |
| Certifié HANA | Non | - |
| Captures instantanées de disque possibles | Oui | - |
| Captures instantanées de machines virtuelles Sauvegarde Azure possibles | Oui | - |
| Coûts | Faible | - |
Résumé : Le stockage SSD standard Azure est la recommandation minimale pour les machines virtuelles hors production pour le VHD de base, les déploiements SGBD éventuels avec une insensibilité relative à la latence et/ou des taux d’IOPS et de débit faibles. Ce type de stockage Azure n’est plus pris en charge pour l’hébergement du répertoire de transport global SAP.
Stockage HDD Standard Azure
Le stockage HDD Standard Azure était le seul type de stockage lorsque l'infrastructure Azure était certifiée pour la charge de travail SAP NetWeaver au cours de l’année 2014. En 2014, les machines virtuelles Azure étaient peu volumineuses et modestes en terme de débit du stockage. Par conséquent, ce type de stockage était en mesure de suivre les demandes. Le stockage est idéal pour les charges de travail non sensibles à la latence, que vous ne pouvez pas rencontrer dans l’espace SAP. Avec le débit croissant des machines virtuelles Azure et l’augmentation de la charge de travail que ces machines virtuelles produisent, ce type de stockage n’est plus pris en compte pour l’utilisation avec les scénarios SAP. La matrice de capacité pour la charge de travail SAP ressemble à ceci :
| Fonctionnalité | Commentaire | Remarques/liens |
|---|---|---|
| Disque dur virtuel de base du système d’exploitation | Non approprié | - |
| Disque de données | Non approprié | - |
| Répertoire de transport global SAP | Non | Non pris en charge |
| SAP sapmnt | Non | Non pris en charge |
| Stockage de sauvegarde | Approprié | - |
| Partages/disque partagé | Non disponible | Nécessite Azure Files ou un fournisseur tiers |
| Résilience | LRS, GRS | Aucun ZRS disponible pour les disques |
| Latence | high | Trop élevé pour l’utilisation du SGBD, le répertoire de transport global SAP ou sapmnt/saploc |
| Contrat de niveau de service IOPS | Non | - |
| Maximum d’E/S par seconde par disque | 500 | Indépendamment de la taille du disque |
| SLA de débit | Non | - |
| Certifié HANA | Non | - |
| Captures instantanées de disque possibles | Oui | - |
| Captures instantanées de machines virtuelles Sauvegarde Azure possibles | Oui | - |
| Coûts | Faible | - |
Résumé : HDD Standard est un type de stockage Azure qui ne doit être utilisé que pour stocker des sauvegardes SAP. Il ne doit pas être utilisé qu’en tant que disque virtuel de base pour les systèmes inactifs, comme les systèmes retirés utilisés pour la recherche de données ici ou là. Cependant, aucune machine virtuelle de développement, d’assurance qualité ou de production active ne doit être basée sur ce stockage. Les fichiers de base de données ne doivent pas non plus être hébergés sur ce stockage
Limites des machines virtuelles Azure dans le trafic de stockage
À l’inverse des scénarios locaux, le type de machine virtuelle que vous sélectionnez joue un rôle essentiel dans la bande passante de stockage que vous pouvez atteindre. Pour les différents types de stockage, vous devez prendre en compte les éléments suivants :
| Type de stockage | Linux | Windows | Commentaires |
|---|---|---|---|
| HDD Standard | Tailles des machines virtuelles Linux dans Azure | Tailles des machines virtuelles Windows dans Azure | Il est probablement difficile d’atteindre les limites de stockage des machines virtuelles moyennes ou grandes |
| SSD Standard | Tailles des machines virtuelles Linux dans Azure | Tailles des machines virtuelles Windows dans Azure | Il est probablement difficile d’atteindre les limites de stockage des machines virtuelles moyennes ou grandes |
| Stockage Premium | Tailles des machines virtuelles Linux dans Azure | Tailles des machines virtuelles Windows dans Azure | Limites d’IOPS ou de débit de stockage facilement atteintes par la machine virtuelle avec la configuration du stockage |
| SSD Premium v2 | Tailles des machines virtuelles Linux dans Azure | Tailles des machines virtuelles Windows dans Azure | Limites d’IOPS ou de débit de stockage facilement atteintes par la machine virtuelle avec la configuration du stockage |
| Stockage sur disque Ultra | Tailles des machines virtuelles Linux dans Azure | Tailles des machines virtuelles Windows dans Azure | Limites d’IOPS ou de débit de stockage facilement atteintes par la machine virtuelle avec la configuration du stockage |
| Azure NetApp Files | Tailles des machines virtuelles Linux dans Azure | Tailles des machines virtuelles Windows dans Azure | Le trafic de stockage utilise la bande passante du débit réseau et non la bande passante du stockage. |
| Fichiers Azure Premium | Tailles des machines virtuelles Linux dans Azure | Tailles des machines virtuelles Windows dans Azure | Le trafic de stockage utilise la bande passante du débit réseau et non la bande passante du stockage. |
Comme limitations, vous devez noter que :
- Plus la machine virtuelle est petite, plus le nombre de disques que vous pouvez joindre est réduit. Cette restriction ne s’applique pas à Azure NetApp Files. Étant donné que vous montez des partages NFS ou SMB, le nombre de volumes partagés à joindre est illimité.
- Les machines virtuelles ont des limites de débit et d’IOPS qui peuvent facilement être dépassées avec des disques de stockage Premium et des disques Ultra
- Avec Azure NetApp Files et Azure Premium Files, le trafic vers les volumes partagés consomme la bande passante réseau de la machine virtuelle et non la bande passante du stockage
- Avec des volumes NFS importants dans l'espace de capacité exprimé en Tio sur deux chiffres, le débit d'accès à un tel volume à partir d'une seule machine virtuelle va atteindre un plateau basé sur les limites de Linux pour une seule session interagissant avec le volume partagé.
Au fur et à mesure que vous augmentez la taille des machines virtuelles Azure dans le cycle de vie d’un système SAP, vous devez évaluer les limites de débit de stockage et d’IOPS du nouveau type de machine virtuelle. Dans certains cas, il peut être judicieux d’ajuster la configuration du stockage aux nouvelles fonctionnalités de la machine virtuelle Azure.
Agrégation par bandes ou non ?
La création d’un agrégat par bandes à partir de plusieurs disques Azure dans un volume de plus grande taille vous permet d’accumuler les IOPS et le débit des disques individuels en un seul volume. Elle est utilisée pour le stockage standard Azure et le stockage Premium Azure uniquement. Le disque Azure Ultra, dont vous pouvez configurer le débit et les IOPS indépendamment de la capacité du disque, ne nécessite pas l’utilisation de jeux de bandes. Les volumes partagés basés sur NFS ou SMB ne peuvent pas être agrégés par bandes. En raison de la nature non linéaire du débit et des IOPS du stockage Premium Azure, vous pouvez approvisionner une capacité inférieure avec les mêmes IOPS et le même débit que les grands disques de stockage Premium Azure. C’est la méthode qui permet d’obtenir un débit plus élevé ou des IOPS plus élevées à moindre coût en utilisant le stockage Premium Azure. À titre d’exemple, l’entrelacement sur deux disques de stockage Premium P15 vous permet d’obtenir un débit de
- 250 Mio/s. Un tel volume aura une capacité de 512 Gio. Si vous souhaitez disposer d’un disque unique qui offre un débit de 250 Mio par seconde, vous devez choisir un disque P40 avec une capacité de 2 Tio.
- 400 Mio/s en distribuant quatre disques de stockage Premium P10 avec une capacité globale de 512 Gio par entrelacement. Si vous souhaitez disposer d’un disque unique avec un débit de 500 Mio minimum par seconde, vous devez choisir un disque de stockage Premium P60 avec 8 Tio. Étant donné que le coût du stockage Premium est quasiment linéaire avec la capacité, l’entrelacement vous permet de constater rapidement les économies réalisées.
Certaines règles doivent être suivies en cas d’entrelacement :
- Aucune redondance de stockage configurée sur une machine virtuelle ne doit être utilisée, car le stockage Azure conserve déjà le disque de données redondant sur le back-end de stockage Azure
- Les disques sur lesquels le jeu de bandes est appliqué doivent être de la même taille
- Avec le SSD Premium v2 et le disque Ultra, la capacité, les IOPS approvisionnées et le débit approvisionné doivent être identiques
L’entrelacement sur plusieurs disques plus petits est la meilleure façon d’obtenir un rapport prix/performances optimal à l’aide du Stockage Premium Microsoft Azure. Il est compris que l’entrelacement peut entraîner une surcharge supplémentaire de déploiement et de gestion.
Pour obtenir des recommandations spécifiques sur la taille des bandes, consultez la documentation des différents SGBD, comme Configurations du stockage des machines virtuelles SAP HANA Azure.
Étapes suivantes
Lisez les articles :