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 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 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 dans le temps
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 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 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é2 | 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é2 | 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é2 | 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é2 | Non pris en charge |
| Volume partagé HANA | Non pris en charge | Non prise en charge | Recommandé | Recommandé | Recommandé | Recommandé | Recommandé3 |
| 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
2 L’utilisation d’ANF nécessite que /hana/data and /hana/log se trouve sur ANF
3 Pour l’instant testé seulement sur SLES
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 | Non | Non | 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 zonale 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 zonale asynchrone | Pas pour les disques managés | Pas pour les disques managés | Non pris en charge pour le SGBD | Non | No | En version préliminaire | 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 Les coûts dépendent des IOPS et du débit approvisionnés
3 La création de pools de capacité différents ne garantit pas le déploiement de pools de capacité sur des unités de stockage différentes.
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 du 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 | Non | - |
| Captures instantanées de machines virtuelles Sauvegarde Azure possibles | Non | - |
| Coûts | Moyenne | - |
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 | Non | - |
| Captures instantanées de disque possibles | Non | - |
| Captures instantanées de machines virtuelles Sauvegarde Azure possibles | Non | - |
| Coûts | Supérieur au stockage Premium | - |
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). Le disque Ultra ne prend pas en charge les instantanés de stockage. 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 (ANF)
Azure NetApp Files est le fruit d’une collaboration entre Microsoft et NetApp dans le but de fournir des partages de fichiers NFS et SMB natifs Azure haute performance. L’objectif est de fournir une bande passante élevée et un stockage à faible latence permettant de réaliser des scénarios de déploiement SGBD et, au fil du temps, d’activer les fonctionnalités opérationnelles courantes du stockage NetApp par le biais d’Azure. Les partages NFS/SMB sont proposés dans trois niveaux de service différents qui différencient le débit de stockage et le prix. Les niveaux de service sont décrits dans l’article Niveaux de service pour Azure NetApp Files. Pour les différents types de charge de travail SAP, les niveaux de service suivants sont fortement recommandés :
- Charge de travail SGBD SAP : Performances, idéalement Ultra
- Partage SAPMNT : Performances, idéalement Ultra
- Répertoire de transport global : Performances, idéalement Ultra
Notes
La taille minimale d’approvisionnement est une unité de 4 Tio appelée pool de capacités. Vous créez ensuite des volumes en dehors de ce pool de capacités. Tandis que le plus petit volume que vous pouvez générer est de 100 Gio. Vous pouvez étendre un pool de capacités par incréments de Tio. Pour connaître la tarification, consultez l'article Tarification Azure NetApp Files
Le stockage ANF est actuellement pris en charge pour plusieurs scénarios de charge de travail SAP :
- Fourniture de partages SMB ou NFS pour le répertoire de transport global SAP
- Partage sapmnt dans les scénarios de haute disponibilité comme indiqué 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
- Déploiements SAP HANA utilisant des partages NFS v4.1 pour des volumes /hana/data et /hana/log et/ou des volumes NFS v4.1 ou NFS v3 pour des volumes /hana/shared comme documenté dans l’article Configurations de stockage des machines virtuelles Azure SAP HANA
- IBM Db2 dans le système d’exploitation invité Suse ou Red Hat Linux
- 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 ASE dans le système d’exploitation invité Suse ou Red Hat Linux
Notes
Pour l’instant, aucune charge de travail SGBD n’est prise en charge sur SMB basé sur Azure NetApp Files.
Comme c’est déjà le cas pour le stockage premium Azure, une taille de débit fixe ou linéaire par Go peut poser problème lorsque vous devez respecter un nombre minimal de débits. Comme c'est le cas pour SAP HANA. Avec ANF, ce problème peut s’accentuer davantage qu'avec le disque premium Azure. Avec un disque Azure Premium, vous pouvez utiliser plusieurs disques plus petits avec un débit relativement élevé par Gio et les entrelacer pour obtenir une rentabilité et un débit plus élevé avec une capacité inférieure. Ce type d’entrelacement ne fonctionne pas pour les partages NFS ou SMB hébergés sur ANF. Cette restriction a entraîné le déploiement de surcapacités :
- Par exemple, pour atteindre un débit de 250 Mio/s sur un volume NFS hébergé sur ANF, vous devez déployer une capacité de 1,95 Tio du niveau de service Ultra.
- Pour atteindre 400 Mio/s, il faudrait déployer une capacité de 3,125 Tio. Mais vous aurez peut-être besoin de la capacité d’approvisionnement excédentaire pour atteindre le débit dont vous avez besoin pour le volume. Ce sur-approvisionnement de capacité a un impact sur la tarification des instances HANA plus petites.
- Avec NFS au-dessus de ANF pour le répertoire SAP /sapmnt, vous vous retrouvez généralement à la capacité minimale de 100 Gio à 150 Gio appliquée par Azure NetApp Files. Toutefois, le client a montré que le débit associé de 12,8 Mio/s (à l’aide du niveau de service Ultra) peut ne pas être suffisant et avoir un impact négatif sur la stabilité du système SAP. Dans ce cas, les clients peuvent éviter des problèmes en augmentant le volume /sapmnt, ce qui signifie qu’un débit supérieur est fourni à ce volume.
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é | SAP HANA, Oracle sur Oracle Linux, DB2 et SAP ASE sur SLES/RHEL |
| 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 v3 et NFS v4.1 |
| Résilience | LRS et GRS | GRS disponible |
| Latence | Très faible | - |
| Contrat de niveau de service IOPS | Oui | - |
| IOPS linéaires à la capacité | strictement linéaire | Dépend du niveau de service |
| SLA de débit | Oui | - |
| Débit linéaire par rapport à la capacité | linear | Dépend du niveau de service |
| Certifié HANA | Oui | - |
| Captures instantanées de disque possibles | Oui | - |
| Captures instantanées de machines virtuelles Sauvegarde Azure possibles | Non | - |
| Coûts | Supérieur au stockage Premium | - |
Autres fonctionnalités intégrées du stockage ANF :
- Possibilité d’effectuer des captures instantanées du volume
- Clonage de volumes ANF à partir de captures instantanées
- Restaurer des volumes à partir de captures instantanées (réinitialisation du snap)
- Sauvegarde d’instantanés cohérente entre applications pour SAP HANA et Oracle
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. En particulier pour SAP HANA, SAP nécessite une latence de moins de 1 milliseconde pour les écritures de journal de restauration automatique HANA de tailles plus petites. Pour obtenir ces latences, consultez les possibilités ci-dessous.
Important
Même pour une utilisation non SGBD, vous devez utiliser la fonctionnalité d’évaluation qui vous permet de créer le partage NFS dans le même Zones de disponibilité Azure que vous avez placé vos machines virtuelles dans lesquelles vous devez monter les partages NFS. Cette fonctionnalité est documentée dans l’article Gérer le placement des volumes de zone de disponibilité pour Azure NetApp Files. La motivation à avoir ce type d’alignement de zone de disponibilité est la réduction de la surface de risque en ayant les partages NFS encore dans un autre AvZone où vous n’exécutez pas de machines virtuelles.
- Vous recherchez la proximité la plus étroite entre la machine virtuelle et le partage NFS en utilisant des groupes de volumes d’application. L’avantage des groupes de volumes d’application, en plus d’allouer une meilleure proximité et donc, d’avoir une latence plus faible, est que vos différents partages NFS pour les déploiements SAP HANA sont distribués sur différents contrôleurs dans les clusters de back-end Azure NetApp Files. L’inconvénient de cette méthode est que vous devez repasser par un processus d’épinglage. Processus qui finit par réduire votre déploiement de machine virtuelle à un seul centre de données au lieu d’une zone de disponibilité comme avec la première méthode. Cela signifie que vous avez moins de flexibilité pour changer la taille et la famille des machines virtuelles sur lesquelles sont montés les volumes NFS.
- Le processus actuel n’utilise pas de groupes de placement de disponibilité, qui jusqu’à présent sont disponibles pour SAP HANA uniquement. Ce processus utilise également le même processus d’épinglage manuel que celui des groupes de volumes de disponibilité. Cette méthode est celle utilisée depuis les trois dernières années. Elle a les mêmes restrictions de flexibilité que les groupes de volumes de disponibilité.
Pour allouer des volumes NFS basés sur ANF pour une utilisation spécifique de la base de données, essayez d’abord d’allouer le volume NFS dans la même zone que votre machine virtuelle. Pour les bases de données non-HANA en particulier. Seulement si la latence s’avère insuffisante, vous devez passer par un processus d’épinglage manuel. Pour une charge de travail HANA plus petite ou une charge de travail HANA hors production, vous devez également suivre une méthode d’allocation zonale. Vous devez utiliser des groupes de volumes d’application seulement dans les cas où les performances et la latence sont insuffisantes.
Résumé: Azure NetApp Files est un stockage à faible latence certifié HANA qui permet de déployer des volumes ou des partages NFS et SMB. Le stockage est fourni avec trois niveaux de service différents qui fournissent des débits et IOPS différents de manière linéaire par capacité du volume en Gio. Le stockage ANF permet de déployer des scénarios de scale-out SAP HANA avec un nœud de secours. Le stockage convient pour fournir des partages de fichiers en fonction des besoins pour /sapmnt ou le répertoire de transport global SAP. Le stockage ANF s’accompagne d’une disponibilité des fonctionnalités proposées en tant que fonctionnalités natives de NetApp.
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
- Partage sapmnt dans les scénarios de haute disponibilité comme indiqué 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.
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 | Non | - |
| 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 hors production |
| Disque de données | Restreint adapté | Certains systèmes hors production avec des demandes d’IOPS faible et de latence |
| Répertoire de transport global SAP | Non | Non pris en charge |
| SAP sapmnt | Restreint adapté | Systèmes hors 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 | LOW | - |
Résumé : Le stockage SSD standard Azure est la recommandation minimale pour les machines virtuelles hors production pour le disque dur virtuel 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 à ANF. É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 ANF 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 :
- Aucun stockage configuré dans la machine virtuelle ne doit être utilisé, car le stockage Azure conserve déjà les données redondantes
- 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 :