Partage via

Capacité de calcul Azure Stack Hub

Les tailles de machine virtuelle prises en charge sur Azure Stack Hub sont un sous-ensemble de celles prises en charge sur Azure. Azure impose des limites de ressources à différents niveaux pour éviter la consommation excessive des ressources (au niveau du service ou du serveur local). Sans imposer de limites à la consommation des locataires, les expériences client souffrent lorsque d’autres locataires surconsument des ressources. Pour la sortie réseau de la machine virtuelle, il existe des limites de bande passante sur Azure Stack Hub qui correspondent aux limitations Azure. Pour les ressources de stockage sur Azure Stack Hub, les limites d’IOPS de stockage évitent une surconsommation des ressources par les locataires pour l’accès au stockage.

Importante

Azure Stack Hub Capacity Planner ne tient pas compte des performances d’IOPS et ne les garantit pas. Le portail d’administration affiche une alerte d’avertissement lorsque la consommation totale de mémoire système atteint 85%. Cette alerte peut être corrigée en ajoutant plus de capacité ou en supprimant des machines virtuelles qui ne sont plus nécessaires.

Placement des machines virtuelles

Le moteur de placement Azure Stack Hub place les machines virtuelles clientes sur les hôtes disponibles.

Azure Stack Hub utilise deux considérations lors du placement de machines virtuelles. Un, y a-t-il suffisamment de mémoire sur l’hôte pour ce type de machine virtuelle ? En second lieu, les machines virtuelles font-elles partie d’un groupe à haute disponibilité ou constituent-elles des groupes de machines virtuelles identiques ?

Pour obtenir une haute disponibilité d’une charge de travail de production multi-machine virtuelle dans Azure Stack Hub, les machines virtuelles sont placées dans un groupe à haute disponibilité qui les répartit entre plusieurs domaines d’erreur. Un domaine d’erreur au sein d’un groupe à haute disponibilité est défini comme un nœud unique dans l’unité d’échelle. Azure Stack Hub prend ne charge les groupes à haute disponibilité avec un maximum de trois domaines d’erreur, pour rester cohérent avec Azure. Les machines virtuelles placées dans un groupe à haute disponibilité sont physiquement isolées les unes des autres en les répartissant aussi uniformément que possible sur plusieurs domaines d’erreur (nœuds Azure Stack Hub). En cas de défaillance matérielle, les machines virtuelles du domaine d’erreur ayant échoué sont redémarrées dans d’autres domaines d’erreur. Si possible, ils sont conservés dans des domaines d’erreur distincts des autres machines virtuelles du même groupe à haute disponibilité. Lorsque l’hôte revient en ligne, les machines virtuelles sont rééquilibrées pour maintenir la haute disponibilité.

Les groupes de machines virtuelles identiques utilisent des groupes à haute disponibilité sur le back-end et veillent à ce que chacune de leurs instances soient placées dans un domaine d’erreur différent. Cela signifie qu’ils utilisent des nœuds d’infrastructure Azure Stack Hub distincts. Par exemple, dans un système Azure Stack Hub à quatre nœuds, il peut arriver qu’un groupe de machines virtuelles identiques de trois instances échoue lors de la création en raison de l’absence de capacité à quatre nœuds pour placer trois instances de groupe de machines virtuelles identiques sur trois nœuds Azure Stack Hub distincts. De plus, les nœuds Azure Stack Hub peuvent être remplis à des niveaux variables avant la tentative de placement.

Azure Stack Hub ne surcommit pas de mémoire. En revanche, un surengagement du nombre de cœurs physiques est autorisé.

Étant donné que les algorithmes de placement n’examinent pas le ratio de surprovisionnement virtuel/physique existant en tant que facteur, chaque hôte peut avoir un ratio différent. En tant que Microsoft, nous ne fournissons pas de conseils sur le ratio de cœurs physiques à virtuels en raison de la variation des charges de travail et des exigences de niveau de service.

Considérations relatives au nombre total de machines virtuelles

Le nombre total de machines virtuelles pouvant être créées est limité. Le nombre maximal de machines virtuelles sur Azure Stack Hub est de 700 et 60 par nœud d’unité d’échelle. Par exemple, une limite de machines virtuelles Azure Stack Hub à huit serveurs est de 480 (8 * 60). Pour une solution Azure Stack Hub de 12 à 16 serveurs, la limite serait de 700 machines virtuelles. Cette limite a été créée en tenant compte de toutes les considérations relatives à la capacité de calcul, telles que la réserve de résilience et le ratio processeur virtuel-physique qu’un opérateur souhaite maintenir sur la plate-forme.

Si la limite de mise à l’échelle de la machine virtuelle est atteinte, les codes d’erreur suivants sont retournés en conséquence : VMsPerScaleUnitLimitExceeded, VMsPerScaleUnitNodeLimitExceeded.

Remarque

Une partie du maximum de 700 machines virtuelles est réservée aux machines virtuelles d’infrastructure Azure Stack Hub. Pour plus d’informations, reportez-vous au planificateur de capacité Azure Stack Hub.

Considérations relatives au déploiement par lots de machines virtuelles

Dans les versions antérieures et jusqu'en 2002, 2 à 5 machines virtuelles par lot avec 5 minutes d'écart entre les lots permettaient des déploiements fiables de machines virtuelles jusqu'à une échelle de 700 machines virtuelles. Avec la version 2005 d’Azure Stack Hub, nous pouvons approvisionner de manière fiable des machines virtuelles à des tailles de lots de 40 avec 5 minutes d’écart entre les déploiements par lots. Les opérations de démarrage, d’arrêt-désallocation et de mise à jour doivent être effectuées à une taille de lot de 30, ce qui laisse 5 minutes entre chaque lot.

Considérations relatives aux machines virtuelles GPU

Azure Stack Hub réserve de la mémoire pour le basculement des machines virtuelles de l’infrastructure et du locataire. Contrairement à d’autres machines virtuelles, les machines virtuelles GPU s’exécutent en mode non-HA (haute disponibilité) et ne basculent donc pas. Par conséquent, la mémoire réservée pour un tampon uniquement de machine virtuelle GPU est ce que l’infrastructure requiert pour le basculement, par opposition à la prise en compte également de la mémoire de la machine virtuelle du locataire HA.

Mémoire Azure Stack Hub

Azure Stack Hub est conçu pour maintenir l’exécution des machines virtuelles qui ont été correctement approvisionnées. Par exemple, si un hôte est hors connexion en raison d’une défaillance matérielle, Azure Stack Hub tente de redémarrer cette machine virtuelle sur un autre hôte. Un deuxième exemple se voit pendant la correction et la mise à jour des logiciels Azure Stack Hub. S’il est nécessaire de redémarrer un hôte physique, une tentative est effectuée pour déplacer les machines virtuelles s’exécutant sur cet hôte vers un autre hôte disponible dans la solution.

Cette gestion ou déplacement de machine virtuelle ne peut être effectué que s’il existe une capacité de mémoire réservée pour permettre le redémarrage ou la migration. Une partie de la mémoire hôte totale est réservée et indisponible pour le placement des machines virtuelles clientes.

Dans le portail d’administration, vous pouvez consulter un graphique en secteurs indiquant la mémoire libre et utilisée dans Azure Stack Hub. Le diagramme suivant montre la capacité de mémoire physique sur une unité d’échelle Azure Stack Hub dans Azure Stack Hub :

Capacité de mémoire physique sur une unité d’échelle Azure Stack Hub

La mémoire utilisée inclut plusieurs composants. Les composants suivants consomment la mémoire dans la section Utilisation du graphique en secteurs :

  • Utilisation ou réserve du système d'exploitation de l'hôte : La mémoire utilisée par le système d'exploitation (OS) sur l'hôte, les tables des pages de mémoire virtuelle, les processus en cours d'exécution sur le système d'exploitation de l'hôte, et le cache de mémoire direct de Spaces. Étant donné que cette valeur dépend de la mémoire utilisée par les différents processus Hyper-V s’exécutant sur l’hôte, elle peut varier.
  • Services d’infrastructure : Machines virtuelles d’infrastructure qui composent Azure Stack Hub. Comme indiqué précédemment, ces machines virtuelles font partie du maximum de 700 machines virtuelles. L’utilisation de la mémoire du composant Services d’infrastructure pourra varier, car nous essayons de rendre nos services d’infrastructure plus évolutifs et résilients. Pour plus d’informations, consultez le planificateur de capacité Azure Stack Hub
  • Réserve de résilience : Azure Stack Hub réserve une partie de la mémoire pour permettre la disponibilité du locataire lors d’une défaillance d’hôte unique, ainsi que pendant le correctif et la mise à jour pour permettre une migration dynamique réussie des machines virtuelles.
  • Machines virtuelles de locataire : Machines virtuelles clientes créées par les utilisateurs d’Azure Stack Hub. En plus de l’exécution de machines virtuelles, la mémoire est consommée par toutes les machines virtuelles qui ont atterri sur l’infrastructure. Cela signifie que les machines virtuelles qui ont l’état « Création en cours » ou « Échec », ou bien qui sont arrêtées à partir de l’invité, consomment de la mémoire. En revanche, les machines virtuelles libérées à l’aide de l’option d’arrêt appropriée du portail, de PowerShell ou de CLI ne consomment pas de mémoire d’Azure Stack Hub.
  • Fournisseurs de ressources à valeur ajoutée (RPs) : Les machines virtuelles déployées pour les fournisseurs de ressources à valeur ajoutée comme SQL, MySQL, App Service, et ainsi de suite.

La meilleure façon de comprendre la consommation de mémoire sur le portail consiste à utiliser Azure Stack Hub Capacity Planner pour voir l’impact des différentes charges de travail. Le calcul suivant est identique à celui utilisé par le planificateur.

Ce calcul entraîne l’utilisation totale de la mémoire disponible pour le placement des machines virtuelles clientes. Cette capacité de mémoire est calculée pour l’intégralité de l’unité d’échelle Azure Stack Hub.

Mémoire disponible pour le placement des machines virtuelles = mémoire hôte totale - réserve de résilience - mémoire utilisée par les machines virtuelles clientes - Surcharge de l’infrastructure Azure Stack Hub 1

  • Mémoire hôte totale = Somme de la mémoire de tous les nœuds
  • Réserve de résilience = H + R * ((N-1) * H) + V * (N-2)
  • Mémoire utilisée par les machines virtuelles de locataire = Mémoire réelle consommée par la charge de travail du locataire, ne dépend pas de la configuration de haute disponibilité
  • Surcharge de l’infrastructure Azure Stack Hub = 268 Go + (4 Go x N)

Où :

  • H = Taille de la mémoire du serveur unique
  • N = Taille de l’unité d’échelle (nombre de serveurs)
  • R = La réserve du système d’exploitation pour la surcharge du système d’exploitation, qui est .15 dans cette formule2
  • V = Plus grande machine virtuelle haute disponibilité dans l’unité d’échelle

1 surcharge d’infrastructure Azure Stack Hub = 268 Go + (4 Go x # de nœuds). Environ 31 machines virtuelles sont utilisées pour héberger l’infrastructure d’Azure Stack Hub et, au total, consomment environ 268 Go + (4 Go x # de nœuds) de mémoire et 146 cœurs virtuels. La justification de ce nombre de machines virtuelles est de satisfaire la séparation de service nécessaire pour répondre aux exigences de sécurité, d’évolutivité, de maintenance et de mise à jour corrective. Grâce à cette structure de service interne, de nouveaux services d’infrastructure peuvent être intégrés à mesure qu’ils sont développés.

2 Réserve de système d’exploitation pour la surcharge = 15 % (0,15) de la mémoire de nœud. La valeur de réserve du système d’exploitation est une estimation et varie en fonction de la capacité de mémoire physique du serveur et de la surcharge générale du système d’exploitation.

La valeur V, la plus grande machine virtuelle haute disponibilité dans l’unité d’échelle, est basée dynamiquement sur la plus grande taille de mémoire de machine virtuelle de locataire. Par exemple, la plus grande valeur de machine virtuelle de haute disponibilité est d'au moins 12 Go (en tenant compte de la machine virtuelle d’infrastructure), ou 112 Go, ou toute autre taille de mémoire de machine virtuelle prise en charge dans la solution Azure Stack Hub. Le changement de la plus grande machine virtuelle haute disponibilité sur l’infrastructure Azure Stack Hub entraîne une augmentation de la réserve de résilience, ainsi que l’augmentation de la mémoire de la machine virtuelle elle-même. N’oubliez pas que les machines virtuelles GPU s’exécutent en mode non haute disponibilité.

Exemple de calcul

Nous avons un petit déploiement Azure Stack Hub à quatre nœuds avec 768 Go de RAM sur chaque nœud. Nous prévoyons de placer une machine virtuelle pour SQL Server avec 128 Go de RAM (Standard_E16_v3). Quelle est la mémoire disponible pour le placement des machines virtuelles ?

  • Mémoire hôte totale = Somme de la mémoire de tous les nœuds = 4 * 768 Go = 3072 Go
  • Réserve de résilience = H + R * ((N-1) * H) + V * (N-2) = 768 + 0,15 * ((4 - 1) * 768) + 128 * (4 - 2) = 1370 Go
  • Mémoire utilisée par les machines virtuelles de locataire = Mémoire réelle consommée par la charge de travail du locataire, ne dépend pas de la configuration haute disponibilité = 0 Go
  • Surcharge de l’infrastructure Azure Stack Hub = 268 Go + (4 Go x N) = 268 + (4 * 4) = 284 Go

Mémoire disponible pour le placement de machine virtuelle = mémoire hôte totale - réserve de résilience - mémoire utilisée par les machines virtuelles clientes - Surcharge de l’infrastructure Azure Stack Hub

Mémoire disponible pour le placement de machine virtuelle = 3072 - 1370 - 0 - 284 = 1418 Go

Considérations relatives à la désallocation

Lorsqu’une machine virtuelle est à l’état désalloué , les ressources mémoire ne sont pas utilisées. Cela permet à d’autres machines virtuelles d’être placées dans le système.

Si la machine virtuelle libérée est redémarrée, l'utilisation ou l'allocation de la mémoire est considérée comme celle d'une nouvelle machine virtuelle ajoutée au système et la mémoire disponible est utilisée. S’il n’y a pas de mémoire disponible, la machine virtuelle ne démarre pas.

Les grandes machines virtuelles déployées actuellement montrent que la mémoire allouée est de 112 Go, mais la demande de mémoire de ces machines virtuelles est d’environ 2 à 3 Go.

Nom Mémoire affectée (Go) Demande de mémoire (Go) Nom de l'ordinateur
ca7ec2ea-40fd-4d41-9d9b-b11e7838d508 112 2.2392578125 LISSA01P-NODE01
10cd7b0f-68f4-40ee-9d98-b9637438ebf4 112 2.2392578125 LISSA01P-NODE01
2e403868-ff81-4abb-b087-d9625ca01d84 112 2.2392578125 LISSA01P-NODE04

Il existe trois façons de libérer de la mémoire pour le placement de machine virtuelle à l’aide de la réserve de résilience de formule = H + R * ((N-1) * H) + V * (N-2) :

  • Réduire la taille de la plus grande machine virtuelle
  • Augmenter la mémoire d’un nœud
  • Ajouter un nœud

Réduire la taille de la plus grande machine virtuelle

La réduction de la taille de la plus grande machine virtuelle à la machine virtuelle de taille immédiatement inférieure dans l'ensemble (24 Go) réduit la taille de la réserve de résilience.

Réduire la taille de la machine virtuelle

Réserve de résilience = 384 + 172,8 + 48 = 604,8 Go

Mémoire totale Infra GB Locataire - Go Réserve de résilience Mémoire totale réservée Total de Go disponibles pour la sélection élective
1536 Go 258 Go 329.25 Go 604.8 Go 258 + 329,25 + 604,8 = 1 168 Go ~344 Go

Ajouter un nœud

L’ajout d’un nœud Azure Stack Hub libère de la mémoire en distribuant également la mémoire entre les deux nœuds.

Ajouter un nœud

Réserve de résilience = 384 + (0,15) ((5)*384) + 112 * (3) = 1008 Go

Mémoire totale Infra - Go Locataire GB Réserve de résilience Mémoire totale réservée Total de Go disponibles pour la sélection élective
1536 Go 258 Go 329.25 Go 604.8 Go 258 + 329,25 + 604,8 = 1 168 Go ~ 344 Go

Augmenter la mémoire sur chaque nœud à 512 Go

L’augmentation de la mémoire de chaque nœud augmente la mémoire totale disponible.

Augmenter la taille du nœud

Réserve de résilience = 512 + 230,4 + 224 = 966,4 Go

Mémoire totale Infra - Go Locataire de Grande-Bretagne Réserve de résilience Mémoire totale réservée Total de Go disponibles pour la sélection élective
2048 (4*512) Go 258 Go 505.75 Go 966.4 Go 1730.15 Go ~ 318 Go

Questions fréquentes

Q : Mon locataire a déployé une nouvelle machine virtuelle, combien de temps faut-il pour que le graphique des fonctionnalités sur le portail d’administration affiche la capacité restante ?

A : Prenez en compte que le panneau de capacité est actualisé toutes les 15 minutes.

Q : Comment puis-je voir les cœurs disponibles et les cœurs attribués ?

A : Dans PowerShell, exécutez test-azurestack -include AzsVmPlacement -debug, qui génère une sortie de ce type :

    Starting Test-AzureStack
    Launching AzsVmPlacement
     
    Azure Stack Scale Unit VM Placement Summary Results
     
    Cluster Node    VM Count VMs Running Physical Core Total Virtual Co Physical Memory Total Virtual Mem
    ------------    -------- ----------- ------------- ---------------- --------------- -----------------
    LNV2-Node02     20       20          28            66               256             119.5            
    LNV2-Node03     17       16          28            62               256             110              
    LNV2-Node01     11       11          28            47               256             111              
    LNV2-Node04     10       10          28            49               256             101              
    
    PASS : Azure Stack Scale Unit VM Placement Summary

Q : Le nombre de machines virtuelles déployées sur mon Azure Stack Hub n’a pas changé, mais ma capacité varie. Pourquoi?

R : La mémoire disponible pour le placement des machines virtuelles a plusieurs dépendances, dont l’une est la réserve de système d’exploitation hôte. Cette valeur dépend de la mémoire utilisée par les différents processus Hyper-V s’exécutant sur l’hôte, ce qui n’est pas une valeur constante.

Q : Quel est l’état dans lequel les machines virtuelles clientes doivent-ils être en mesure d’utiliser la mémoire ?

A : En plus de l’exécution de machines virtuelles, la mémoire est consommée par toutes les machines virtuelles qui ont été placées sur l’infrastructure. Cela signifie que les machines virtuelles qui se trouvent dans un état « Création » ou « Échec » consomment de la mémoire. Les machines virtuelles arrêtées à partir de l’invité consomment également de la mémoire, contrairement à celles qui sont libérées par l’option d’arrêt appropriée depuis le portail, PowerShell ou l’interface CLI.

Q : J’ai un Azure Stack Hub à quatre hôtes. Mon locataire a 3 machines virtuelles qui consomment 56 Go de RAM (D5_v2) chacune. L’une des machines virtuelles est redimensionnée à 112 Go de RAM (D14_v2), et les rapports de mémoire disponible du tableau de bord ont entraîné un pic d’utilisation de 168 Go sur la lame de capacité. Le redimensionnement ultérieur des deux autres machines virtuelles D5_v2 pour D14_v2 a entraîné une augmentation de ram de seulement 56 Go. Pourquoi est-ce si ?

R : La mémoire disponible est une fonction de la réserve de résilience gérée par Azure Stack Hub. La réserve de résilience est fonction de la taille de la plus grande machine virtuelle sur le tampon Azure Stack Hub. Dans un premier temps, la machine virtuelle la plus grande sur le tampon avait une capacité de 56 Go de mémoire. Lorsque la machine virtuelle a été redimensionnée, la plus grande machine virtuelle sur l'infrastructure est passée à 112 Go de mémoire, ce qui a non seulement augmenté la mémoire utilisée par ce locataire de machine virtuelle, mais a également augmenté la réserve de résilience. Cette modification a entraîné une augmentation de 56 Go (56 Go à 112 Go de mémoire de machine virtuelle cliente) + 112 Go d’augmentation de la mémoire de réserve de résilience. Lorsque les machines virtuelles suivantes ont été redimensionnées, la plus grande taille de machine virtuelle est restée à 112 Go, et il n’y a donc pas eu d’augmentation de la réserve de résilience souhaitée. L’augmentation de la consommation de mémoire était uniquement l’augmentation de la mémoire de la machine virtuelle du locataire (56 Go).

Remarque

Les exigences de planification de la capacité pour la mise en réseau sont minimes car seule la taille de l’adresse IP virtuelle publique est configurable. Pour plus d’informations sur l’ajout d’adresses IP publiques à Azure Stack Hub, consultez Ajouter des adresses IP publiques.

Étapes suivantes

En savoir plus sur le stockage Azure Stack Hub