FAQ sur les groupes de machines virtuelles identiques Azure

Un groupe identique peut contenir de 0 à 1 000 machines virtuelles basées sur des images de plateforme, ou de 0 à 600 machines virtuelles basées sur des images personnalisées.

Oui. Un groupe identique peut définir une configuration de disques de données attachés qui s’appliquera à toutes les machines virtuelles du groupe. Pour plus d’informations, consultez Groupes identiques Azure et disques de données attachés. Il existe d’autres options pour stocker les données :

• Disques managés Azure (Premium v2, Premium, Standard, Ultra)
• Fichiers Azure (lecteurs SMB ou NFS partagés)
• Fichiers Azure Netapp
• Disques partagés Azure
• lecteur du système d’exploitation
• Lecteur temp (local, non sauvegardé par le stockage Azure)
• Service de données Azure (par exemple, Stockage Table Azure ou Stockage Blob Azure)
• Service de données externe (par exemple, base de données distante)

Toutes les régions prennent en charge les groupes identiques.

Toutes les références SKU sont prises en charge pour les groupes de machines virtuelles identiques.

Créez et capturez une image de machine virtuelle, puis utilisez-la comme source de votre groupe identique. Pour un tutoriel sur la création et l’utilisation d’une image de machine virtuelle personnalisée, vous pouvez utiliser Azure CLI ou Azure PowerShell.

La mise à niveau de l’image du système d’exploitation est un processus progressif et non perturbateur qui met à jour l’image du système d’exploitation pour le groupe de machines virtuelles identiques au fil du temps, ce qui garantit un impact minimal sur les charges de travail en cours d’exécution.

La réinitialisation est une action plus immédiate et perturbatrice qui affecte uniquement l’instance de machine virtuelle sélectionnée, l’arrêtant temporairement et réinstallant le système d’exploitation.

Découvrez-en plus sur la différence entre la mise à niveau de l’image du système d’exploitation et la réinitialisation.

Par défaut, les machines virtuelles sont retirées du groupe identique de façon uniforme entre les zones de disponibilité (si le groupe identique est déployé dans une configuration zonale) et les domaines d’erreur pour optimiser la disponibilité. Les machines virtuelles avec les ID les plus élevés sont supprimées en premier.

Vous pouvez modifier l’ordre de suppression des machines virtuelles en spécifiant une Stratégie de scale-in pour le groupe identique.

Si vous augmentez la capacité à 18, 3 machines virtuelles sont créées. À chaque fois, l’ID d’instance de la machine virtuelle est incrémenté avec la valeur la plus élevée précédente (par exemple, 20, 21, 22). Les machines virtuelles sont équilibrées entre les domaines d’erreur.

Oui, vous pouvez appliquer une séquence d'exécution au groupe identique.

Un groupe identique régional (non zonal) utilise des groupes de placement, qui servent de groupe à haute disponibilité implicite avec cinq domaines d’erreur et cinq domaines de mise à jour. Les groupes identiques de plus de 100 machines virtuelles sont répartis entre plusieurs groupes de placement. Pour plus d’informations sur les groupes de placement, consultez Utilisation de grands groupes de machines virtuelles identiques. Un groupe de machines virtuelles à haute disponibilité peut figurer dans le même réseau virtuel qu’un groupe identique de machines virtuelles. Une configuration courante consiste à placer les machines virtuelles du nœud de contrôle qui nécessitent souvent une configuration unique dans un groupe à haute disponibilité, et les nœuds de données dans le groupe identique.

Oui. Pour plus d’informations, consultez le document relatif aux zones des groupes identiques.

Consultez les Meilleures pratiques pour la mise à l’échelle automatique de machines virtuelles.

Voir Métriques prises en charge avec Azure Monitor.

Oui. Pour consulter ces exemples, consultez Métriques courantes pour la mise à l’échelle automatique d’Azure Monitor.

Pour une file d’attente Service Bus, utilisez le JSON suivant :

"metricName": "MessageCount",
"metricNamespace": "",
"metricResourceUri": "/subscriptions/s1/resourceGroups/rg1/providers/Microsoft.ServiceBus/namespaces/mySB/queues/myqueue"

Pour une file d’attente de stockage, utilisez le JSON suivant :

"metricName": "ApproximateMessageCount",
"metricNamespace": "",
"metricResourceUri": "/subscriptions/s1/resourceGroups/rg1/providers/Microsoft.ClassicStorage/storageAccounts/mystorage/services/queue/queues/mystoragequeue"

Remplacez les exemples de valeurs par les URI (Uniform Resource Identifiers) de votre ressource.

Vous pouvez créer un paramètre de mise à l’échelle automatique sur une machine virtuelle pour utiliser les métriques au niveau de l’hôte ou les métriques basées sur un système d’exploitation invité.

Pour obtenir la liste des métriques prises en charge, consultez Métriques courantes pour la mise à l’échelle automatique d’Azure Monitor.

Pour obtenir un exemple complet pour les groupes de machines virtuelles identiques, consultez Configuration avancée de la mise à l’échelle automatique à l’aide de modèles Resource Manager pour les groupes de machines virtuelles identiques.

L’exemple utilise la métrique du processeur au niveau de l’hôte et une métrique de comptage de messages.

Vous pouvez créer des alertes sur des métriques pour les groupes de machines virtuelles identiques via PowerShell ou l’interface de ligne de commande Azure. Pour plus d’informations, consultez Exemples de démarrage rapide Azure Monitor PowerShell et Exemples de démarrage rapide de l’interface CLI multiplateforme pour Azure Monitor.

Le/La TargetResourceId du groupe de machines virtuelles identiques ressemble à ceci :

/subscriptions/yoursubscriptionid/resourceGroups/yourresourcegroup/providers/Microsoft.Compute/virtualMachineScaleSets/yourvmssname

Vous pouvez choisir n’importe quel compteur de performances de machine virtuelle en tant que métrique sur laquelle définir une alerte. Pour plus d’informations, consultez Métriques du système d’exploitation invité pour les machines virtuelles Windows Resource Manager et Métriques du système d’exploitation invité pour les machines virtuelles Linux dans l’articleMétriques courantes pour la mise à l’échelle automatique d’Azure Monitor.

Voir Mettre à l’échelle automatiquement un groupe de machines virtuelles. Vous pouvez également configurer la mise à l’échelle automatique avec Azure CLI et les modèles Azure.

Non. Si la mise à l’échelle automatique nécessite plus d’instances de machine virtuelle dans le groupe identique, une nouvelle instance de machine virtuelle est créée. Les instances de machine virtuelle arrêtées (libérées) ne démarrent pas sous l’événement de mise à l’échelle automatique. Toutefois, ces machines virtuelles arrêtées (libérées) risquent d’être supprimées dans le cadre d’un événement de mise à l’échelle qui diminue le nombre d’instances, de la même façon que n’importe quelle instance de machine virtuelle peut être supprimée en fonction de l’ordre de l’ID d’instance de machine virtuelle.

Pour expédier en toute sécurité un certificat sur la machine virtuelle, vous pouvez installer un certificat client directement dans un magasin de certificats Windows à partir du coffre de clés du client.

Utilisez le JSON suivant :

"secrets": [
    {
        "sourceVault": {
            "id": "/subscriptions/{subscriptionid}/resourceGroups/myrg1/providers/Microsoft.KeyVault/vaults/mykeyvault1"
        },
        "vaultCertificates": [
            {
                "certificateUrl": "https://mykeyvault1.vault.azure.net/secrets/{secretname}/{secret-version}",
                "certificateStore": "certificateStoreName"
            }
        ]
    }
]

Le code prend en charge Windows et Linux.

Pour plus d’informations, consultez Création ou mise à jour d’un groupe de machines virtuelles identiques.

Pour obtenir le dernier exemple, dans un shell Azure, utilisez l’instruction Azure CLI suivante, qui sera imprimée sur stdout :

az sf cluster create -h

Les certificats auto-signés ne peuvent pas être utilisés pour la distribution d’informations fournies par une autorité de certification, et ne doivent pas être utilisés pour un cluster Service Fabric conçu pour héberger des solutions de production d’entreprise. Pour obtenir plus de conseils en matière de sécurité, consultez les Bonnes pratiques pour la sécurité Azure Service Fabric et les Scénarios de sécurité de cluster Service Fabric.

Oui. L’API REST pour osProfile est similaire à l’API REST de machine virtuelle standard.

Incluez osProfile dans votre modèle :

"osProfile": {
    "computerName": "[variables('vmName')]",
    "adminUsername": "[parameters('adminUserName')]",
    "linuxConfiguration": {
        "disablePasswordAuthentication": "true",
        "ssh": {
            "publicKeys": [
                {
                    "path": "[variables('sshKeyPath')]",
                    "keyData": "[parameters('sshKeyData')]"
                }
            ]
        }
    }
}

Ce bloc JSON est utilisé dans ce modèle de démarrage rapide Azure.

Pour plus d’informations, consultez Création ou mise à jour d’un groupe de machines virtuelles identiques.

Pour supprimer les certificats obsolètes, supprimez l’ancien certificat dans la liste des certificats du coffre. Laissez tous les certificats que vous souhaitez garder sur votre ordinateur dans la liste. Cette action ne supprime pas le certificat de toutes vos machines virtuelles. Cela n’ajoute pas non plus le certificat sur les nouvelles machines virtuelles créées dans le groupe de machines virtuelles identiques.

Pour supprimer le certificat sur des machines virtuelles existantes, utilisez une extension de script personnalisé afin de supprimer manuellement les certificats de votre magasin de certificats.

Si vous fournissez seulement une clé publique SSH aux machines virtuelles, vous n’avez pas besoin de placer les clés publiques dans Azure Key Vault. Les clés publiques ne sont pas secrètes.

Vous pouvez fournir les clés publiques SSH en texte brut lorsque vous créez une machine virtuelle Linux :

"linuxConfiguration": {
    "ssh": {
        "publicKeys": [
            {
                "path": "path",
                "keyData": "publickey"
            }
        ]
    }
}

Pour obtenir un exemple, consultez le modèle de démarrage rapide GitHub vm-sshkey.

Cette erreur peut se produire si vous essayez d’ajouter à nouveau le même coffre au lieu d’utiliser un nouveau certificat de coffre pour le coffre source existant. La commande Add-AzVmssSecret ne fonctionne pas correctement si vous ajoutez plus de secrets.

Pour ajouter d’autres secrets du même coffre de clés, mettez à jour la liste suivante : $vmss.properties.osProfile.secrets[0].vaultCertificates.

Pour connaître la structure d’entrée attendue, consultez Création ou mise à jour d’un groupe de machines virtuelles.

Recherchez le secret dans l’objet du groupe de machines virtuelles identiques qui se trouve dans le coffre de clés. Ensuite, ajoutez votre référence de certificat (l’URL et le nom du magasin des secrets) dans la liste associée au coffre.

Les nouvelles machines virtuelles ne disposent pas de l’ancien certificat. Toutefois, les machines virtuelles qui ont le certificat et qui sont déjà déployées disposent de l’ancien certificat.

Il est inutile de coder en dur les mots de passe dans les scripts. Vous pouvez récupérer de manière dynamique les mots de passe avec les autorisations que vous utilisez pour exécuter le script de déploiement. Si vous avez un script qui déplace un certificat à partir du magasin des secrets vers le coffre de clés, la commande get certificate du magasin des secrets génère également le mot de passe du fichier .pfx.

Une référence de certificat WinRM (Windows Remote Management) doit être présente dans la propriété Secrets du profil du système d’exploitation.

L’objectif consistant à indiquer le coffre source est d’appliquer les stratégies de liste de contrôle d’accès (ACL) qui existent dans le modèle Azure Cloud Services d’un utilisateur. Si le coffre source n’est pas spécifié, les utilisateurs ne disposant pas des autorisations pour déployer ou accéder aux secrets d’un coffre de clés peuvent y parvenir via un CRP (Compute Resource Provider). Les listes ACL existent même pour les ressources qui n’existent pas.

Si vous fournissez un ID sourceVault incorrect mais une URL de coffre de clés valide, une erreur est signalée lorsque vous interrogez l’opération.

Les certificats sont ajoutés à toutes vos machines virtuelles, mêmes les préexistantes. Si la propriété upgradePolicy de votre groupe de machines virtuelles identiques est définie sur manual, le certificat est ajouté à la machine virtuelle lorsque vous effectuez une mise à jour manuelle sur celle-ci.

Pour savoir comment déployer des certificats pour les machines virtuelles Linux, consultez Déployer des certificats sur les machines virtuelles à partir de coffres de clés gérés par les clients.

Pour ajouter un certificat de coffre à un secret existant, consultez l’exemple PowerShell suivant. Utilisez un seul objet secret.

$newVaultCertificate = New-AzVmssVaultCertificateConfig -CertificateStore MY -CertificateUrl https://sansunallapps1.vault.azure.net:443/secrets/dg-private-enc/55fa0332edc44a84ad655298905f1809

$vmss.VirtualMachineProfile.OsProfile.Secrets[0].VaultCertificates.Add($newVaultCertificate)

Update-AzVmss -VirtualMachineScaleSet $vmss -ResourceGroup $rg -Name $vmssName

Si vous réinitialisez une machine virtuelle, les certificats sont supprimés. La réinitialisation supprime l’intégralité du disque du système d’exploitation.

Si le secret est supprimé de Key Vault et si vous exécutez stop deallocate pour toutes vos machines virtuelles, puis les démarrez à nouveau, vous rencontrez une erreur. L’erreur se produit car le CRP, qui doit récupérer les secrets dans le coffre de clés, ne le peut pas. Dans ce scénario, vous pouvez supprimer les certificats à partir du modèle de groupe de machines virtuelles identiques.

Le composant CRP ne rend pas les secrets des clients persistants. Si vous exécutez stop deallocate pour toutes les machines virtuelles dans le groupe de machines virtuelles identiques, le cache est supprimé. Dans ce scénario, les secrets sont récupérés à partir du coffre de clés.

Vous ne rencontrez pas ce problème lors de la montée en charge, car il existe une copie en cache du secret dans Azure Service Fabric (dans le modèle client à structure unique).

L’objectif est de faire clairement savoir à l’utilisateur quel certificat est déployé sur ses machines virtuelles.

Si vous créez une machine virtuelle, puis mettez à jour votre secret dans le coffre de clés, ce nouveau certificat n’est pas téléchargé sur vos machines virtuelles. Mais vos machines virtuelles ont l’air d’y faire référence et les nouvelles machines virtuelles obtiennent le nouveau secret. Pour éviter ce problème, vous devez référencer une version du secret.

Pour déployer des clés publiques .cer dans un groupe de machines virtuelles identiques, vous pouvez générer un fichier .pfx qui contient uniquement des fichiers .cer. Pour ce faire, utilisez X509ContentType = Pfx. Par exemple, chargez le fichier .cer en tant qu’objet x509Certificate2 dans C# ou PowerShell, puis appelez la méthode.

Pour plus d’informations, consultez Méthode X509Certificate.Export (X509ContentType, chaîne).

Pour émuler le transfert d’un certificat sous forme de chaîne en base64, vous pouvez extraire la dernière version d’URL dans un modèle Resource Manager. Incluez la propriété JSON suivante dans votre modèle Resource Manager :

"certificateUrl": "[reference(resourceId(parameters('vaultResourceGroup'), 'Microsoft.KeyVault/vaults/secrets', parameters('vaultName'), parameters('secretName')), '2015-06-01').secretUriWithVersion]"

Dans les groupes de machines virtuelles identiques et les machines virtuelles, les certificats doivent être encapsulés dans des objets JSON.

Nous prenons également en charge le type de contenu application/x-pkcs12.

Actuellement, nous ne prenons pas en charge les fichiers .cer. Pour utiliser des fichiers .cer, exportez-les dans des conteneurs .pfx.

Les groupes de machines virtuelles identiques sont une fine couche API sur le composant CRP. Les deux composants font partie de la plateforme de calcul dans l’arborescence des services Azure.

Du point de vue de la conformité, les groupes de machines virtuelles identiques sont une composante essentielle de la plateforme de calcul Azure. Ils partagent ce qui suit avec le CRP lui-même : une équipe, des outils, des processus, une méthodologie de déploiement, des contrôles de sécurité, la compilation JIT, la surveillance et les alertes. Les groupes de machines virtuelles identiques sont conformes à PCI (Payment Card Industry), car le CRP fait partie de l’attestation PCI DSS (Data Security Standard) actuelle.

Pour plus d’informations, consultez le Centre de gestion de la confidentialité de Microsoft.

Oui. Pour plus d’informations, consultez Vue d’ensemble des identités managées. Vous pouvez voir des exemples de modèle MSI dans les modèles de démarrage rapide Azure pour Linux et pour Windows.

Dans le portail Azure, vous avez la possibilité de supprimer une instance individuelle ou de supprimer en bloc en sélectionnant plusieurs instances. Si vous essayez de supprimer une instance individuelle avec un verrou en place, le verrou est respecté et vous ne pourrez pas supprimer l’instance. Toutefois, si vous sélectionnez en bloc plusieurs instances et que l’une de ces instances a un verrou en place, les verrous ne sont pas respectés. Toutes les instances sélectionnées sont supprimées.

Dans Azure CLI, vous avez la possibilité de supprimer une instance individuelle. Si vous essayez de supprimer une instance individuelle avec un verrou en place, le verrou est respecté et vous ne pourrez pas supprimer cette instance.

Pour supprimer une extension de groupe de machines virtuelles identiques, utilisez l’exemple PowerShell suivant :

$vmss = Get-AzVmss -ResourceGroupName "resource_group_name" -VMScaleSetName "vmssName"

$vmss=Remove-AzVmssExtension -VirtualMachineScaleSet $vmss -Name "extensionName"

Update-AzVmss -ResourceGroupName "resource_group_name" -VMScaleSetName "vmssName" -VirtualMacineScaleSet $vmss

Vous pouvez trouver la valeur extensionName dans $vmss.

Pour obtenir un exemple de modèle de groupe de machines virtuelles identiques qui s’intègre aux journaux Azure Monitor, consultez le deuxième exemple sous Déployer un cluster Azure Service Fabric et activer le monitoring à l’aide des journaux Azure Monitor.

Si la stratégie de mise à jour est définie sur automatique, le redéploiement du modèle avec les nouvelles propriétés d’extension met à jour toutes les machines virtuelles.

Si la stratégie de mise à jour est définie sur manuelle, mettez d’abord à jour l’extension, puis mettez manuellement à jour toutes les instances de vos machines virtuelles.

Si la définition de l’extension dans le modèle de groupe de machines virtuelles identiques est mis à jour et la propriété upgradePolicy est définie sur automatic, les machines virtuelles sont mises à jour. Si la propriété upgradePolicy est définie sur manual, les extensions sont signalées comme ne correspondant pas au modèle.

Si une machine virtuelle existante est corrigée par service, cela s’apparente à un redémarrage et les extensions ne sont pas exécutées à nouveau. Si elle est réinitialisée, le processus est similaire au remplacement du disque du système d’exploitation par l’image source. Toutes les spécialisations du modèle le plus récent, telles que les extensions, sont exécutées.

Pour joindre un groupe de machines virtuelles identiques à un domaine Active Directory, vous pouvez définir une extension.

Pour définir une extension, utilisez la propriété JsonADDomainExtension :

"extensionProfile": {
    "extensions": [
        {
            "name": "joindomain",
            "properties": {
                "publisher": "Microsoft.Compute",
                "type": "JsonADDomainExtension",
                "typeHandlerVersion": "1.3",
                "settings": {
                    "Name": "[parameters('domainName')]",
                    "OUPath": "[variables('ouPath')]",
                    "User": "[variables('domainAndUsername')]",
                    "Restart": "true",
                    "Options": "[variables('domainJoinOptions')]"
                },
                "protectedsettings": {
                    "Password": "[parameters('domainJoinPassword')]"
                }
            }
        }
    ]
}

Vous pouvez utiliser l’extension Desired State Configuration d’Azure Automation. Si le système d’exploitation est Windows Server 2012 R2, Azure extrait la configuration Windows Management Framework (WMF) 5.0, redémarre, puis poursuit la configuration.

Définissez des paramètres protégés avec la clé et le nom du compte de stockage. Pour plus d’informations, voir Custom Script Extension (Extension de script personnalisé).

Vous pouvez :

• Changez directement le modèle de groupe de machines virtuelles identiques. Cette option n’est disponible qu’avec l’API 2017-12-01 et versions ultérieures.

  Mettez à jour les informations d’identification d’administrateur directement dans le modèle de groupe identique (par exemple en utilisant Azure Resource Explorer, PowerShell ou l’interface Azure CLI). Une fois que le groupe identique est mis à jour, toutes les nouvelles machines virtuelles disposent des nouvelles informations d’identification. Les machines virtuelles existantes ont les nouvelles informations d’identification uniquement si elles sont réinitialisées.

• Réinitialisez le mot de passe à l’aide des extensions d’accès aux machines virtuelles. Veillez à respecter les exigences de mot de passe, telles qu’elles sont décrites dans la FAQ.

  L’utilisation d’une extension d’accès aux machines virtuelles ne nécessite pas de réinitialisation, car l’extension ne met pas à jour le mot de passe dans le modèle. L’extension exécute un script pour ajouter le mot de passe au mot de passe ou au fichier de la clé SSH. L’extension ne supprime pas la clé SSH d’origine. Une fois l’extension mise à jour, mettez à niveau les instances pour appliquer les mises à jour du nom d’utilisateur et du mot de passe sur toutes les instances de machine virtuelle.

  Notes

  Si la stratégie de mise à niveau automatique est définie sur manual, sélectionnez manuellement l’instance pour effectuer une opération de mise à niveau sur des instances de machine virtuelle individuelles. Si la mise à niveau automatique est définie sur Auto, l’extension est automatiquement mise à niveau. Pour plus d’informations, consultez Mises à niveau automatiques des extensions.

  Utilisez l’exemple PowerShell suivant pour un groupe de machines virtuelles identiques Windows :

  $vmssName = "myvmss"
  $vmssResourceGroup = "myvmssrg"
  $publicConfig = @{"UserName" = "newuser"}
  $privateConfig = @{"Password" = "********"}
  
  $extName = "VMAccessAgent"
  $publisher = "Microsoft.Compute"
  $vmss = Get-AzVmss -ResourceGroupName $vmssResourceGroup -VMScaleSetName $vmssName
  $vmss = Add-AzVmssExtension -VirtualMachineScaleSet $vmss -Name $extName -Publisher $publisher -Setting $publicConfig -ProtectedSetting $privateConfig -Type $extName -TypeHandlerVersion "2.0" -AutoUpgradeMinorVersion $true
  Update-AzVmss -ResourceGroupName $vmssResourceGroup -Name $vmssName -VirtualMachineScaleSet $vmss
  

  Utilisez l’exemple Azure CLI suivant pour un groupe de machines virtuelles identiques Linux :

  az vmss extension set \
    --resource-group myResouceGroup \ 
    --vmss-name myScaleSet \
    --publisher Microsoft.OSTCExtensions \
    --name VMAccessForLinux \
    --version 1.5 \
    --protected-settings "{'username': 'newUser', 'password': 'newPassword'}"
  

Oui. Vous pouvez appliquer un NSG directement à un groupe identique en le référant dans la section networkInterfaceConfigurations du profil réseau. Voici un exemple :

"networkProfile": {
    "networkInterfaceConfigurations": [
        {
            "name": "nic1",
            "properties": {
                "primary": "true",
                "ipConfigurations": [
                    {
                        "name": "ip1",
                        "properties": {
                            "subnet": {
                                "id": "[concat('/subscriptions/', subscription().subscriptionId,'/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/virtualNetworks/', variables('vnetName'), '/subnets/subnet1')]"
                            },
                            "loadBalancerInboundNatPools": [
                                {
                                    "id": "[concat('/subscriptions/', subscription().subscriptionId,'/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/loadBalancers/', variables('lbName'), '/inboundNatPools/natPool1')]"
                                }
                            ],
                            "loadBalancerBackendAddressPools": [
                                {
                                    "id": "[concat('/subscriptions/', subscription().subscriptionId,'/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/loadBalancers/', variables('lbName'), '/backendAddressPools/addressPool1')]"
                                }
                            ]
                        }
                    }
                ],
                "networkSecurityGroup": {
                    "id": "[concat('/subscriptions/', subscription().subscriptionId,'/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/networkSecurityGroups/', variables('nsgName'))]"
                }
            }
        }
    ]
}

Si vous disposez de deux groupes de machines virtuelles identiques avec Azure Load Balancer, et qu’ils font partie d’une région et d’un abonnement identique, vous pouvez libérer l’adresse IP publique d’un groupe pour l’assigner à l’autre. Pour plus d’informations, consultez VIP Swap: Blue-green deployment in Azure Resource Manager (Échange d’adresse IP virtuelle (VIP) : Déploiement Bleu/vert dans Azure Resource Manager). Un retard peut néanmoins se produire, car les ressources sont libérées ou allouées au niveau du réseau. Une option plus rapide consiste à utiliser la passerelle Azure Application Gateway avec deux pools backend et une règle de routage. Une autre option consiste à héberger votre application avec Azure App service, qui fournit une assistance pour basculer rapidement entre emplacements intermédiaires et emplacements de production.

Les adresses IP sont sélectionnées à partir d’un sous-réseau que vous spécifiez.

La méthode d’allocation des adresses IP d’un groupe de machines virtuelles identiques est toujours dynamique, mais cela ne signifie pas que ces adresses IP peuvent changer. Dans ce cas, « dynamique » signifie uniquement que vous ne spécifiez pas l’adresse IP dans une requête PUT. Spécifiez l’ensemble statique à l’aide du sous-réseau.

Voir Déployer un groupe de machines virtuelles identiques sur un réseau virtuel existant.

Oui. Pour utiliser une mise en réseau accélérée, définissez enableAcceleratedNetworking sur true dans les paramètres networkInterfaceConfigurations de votre groupe identique. Par exemple :

"networkProfile": {
    "networkInterfaceConfigurations": [
        {
            "name": "niconfig1",
            "properties": {
                "primary": true,
                "enableAcceleratedNetworking" : true,
                "ipConfigurations": [
                ]
            }
        }
    ]
}

Pour créer un groupe de machines virtuelles identiques avec une configuration DNS personnalisée, ajoutez un paquet JSON dnsSettings à la section networkInterfaceConfigurations du groupe identique. Voici un exemple :

    "dnsSettings":{
        "dnsServers":["10.0.0.6", "10.0.0.5"]
    }

Pour créer un groupe de machines virtuelles identiques qui attribue une adresse IP publique à chaque machine virtuelle, vérifiez que la version API de la ressource Microsoft.Compute/virtualMachineScaleSets est datée du 30/03/2017, puis ajoutez un paquet JSON publicipaddressconfiguration à la section ipConfigurations du groupe identique. Voici un exemple :

    "publicipaddressconfiguration": {
        "name": "pub1",
        "properties": {
        "idleTimeoutInMinutes": 15
        }
    }

Oui. Vous pouvez ajouter les ID de ressources pour plusieurs pools d’adresses de backend de passerelle d’application à la liste applicationGatewayBackendAddressPools de la section ipConfigurations du profil réseau de votre groupe identique.

L’une des raisons de créer un groupe de machines virtuelles identiques avec moins de deux machines virtuelles est d’utiliser les propriétés élastiques d’un groupe de machines virtuelles identiques. Vous pouvez, par exemple, déployer un groupe de machines virtuelles identiques avec zéro machine virtuelle afin de définir votre infrastructure sans payer les frais de fonctionnement de la machine virtuelle. Ensuite, quand vous êtes prêt à déployer des machines virtuelles, vous pouvez augmenter la capacité du groupe de machines virtuelles identiques en fonction du nombre d’instances de production.

Une autre raison de créer un groupe de machines virtuelles identiques avec moins de deux machines virtuelles est si vous vous souciez moins de la disponibilité par rapport à l’utilisation d’un groupe à haute disponibilité avec des machines virtuelles discrètes. Les groupes de machines virtuelles identiques vous permettent d’utiliser des unités de calcul indifférenciées qui sont fongibles. Cette uniformité est un atout pour les groupes de machines virtuelles identiques par rapport aux groupes à haute disponibilité. De nombreuses charges de travail sans état n’effectuent pas le suivi des unités individuelles. Si la charge de travail baisse, vous pouvez descendre en puissance à une unité de calcul, puis monter en puissance lorsque la charge de travail augmente.

Pour modifier le nombre de machines virtuelles dans un groupe de machines virtuelles identiques dans le portail Azure, dans la section Propriétés du groupe de machines virtuelles identiques, cliquez sur le panneau de Mise à l’échelle et utilisez la barre du curseur.

Vous bénéficiez d’une certaine flexibilité dans la façon dont vous gérez les alertes pour les seuils spécifiés. Vous pouvez, par exemple, définir des webhooks personnalisés. L’exemple de webhook suivant est extrait d’un modèle Resource Manager :

{
    "type": "Microsoft.Insights/autoscaleSettings",
    "apiVersion": "[variables('insightsApi')]",
    "name": "autoscale",
    "location": "[parameters('resourceLocation')]",
    "dependsOn": [
        "[concat('Microsoft.Compute/virtualMachineScaleSets/', parameters('vmSSName'))]"
    ],
    "properties": {
        "name": "autoscale",
        "targetResourceUri": "[concat('/subscriptions/',subscription().subscriptionId, '/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Compute/virtualMachineScaleSets/', parameters('vmSSName'))]",
        "enabled": true,
        "notifications": [
            {
                "operation": "Scale",
                "email": {
                    "sendToSubscriptionAdministrator": true,
                    "sendToSubscriptionCoAdministrators": true,
                    "customEmails": [
                        "youremail@address.com"
                    ]
                },
                "webhooks": [
                    {
                        "serviceUri": "<service uri>",
                        "properties": {
                            "key1": "custommetric",
                            "key2": "scalevmss"
                        }
                    }
                ]
            }
        ]
    }
}

Oui, vous pouvez.

Oui, vous pouvez déplacer des ressources d’un groupe identique vers un nouvel abonnement ou un nouveau groupe de ressources.

Pour mettre à jour votre groupe de machines virtuelles identiques sur une nouvelle image et gérer la mise à jour corrective, consultez Mettre à niveau un groupe de machines virtuelles identiques.

Oui, vous pouvez utiliser l’opération de réinitialisation pour réinitialiser une machine virtuelle sans modifier l’image. Toutefois, si votre groupe de machines virtuelles identiques référence une image de plateforme avec version = latest, votre machine virtuelle peut se mettre à jour vers une image de système d’exploitation ultérieure lorsque vous appelez reimage.

Oui, vous pouvez le faire en installant l’extension Azure Monitor sur les machines virtuelles du groupe identique. Voici un exemple qui utilise Azure CLI :

az vmss extension set --name MicrosoftMonitoringAgent --publisher Microsoft.EnterpriseCloud.Monitoring --resource-group Team-03 --vmss-name nt01 --settings "{'workspaceId': '<your workspace ID here>'}" --protected-settings "{'workspaceKey': '<your workspace key here'}"

Vous pouvez trouver l’espace les valeurs workspaceId et workspaceKey requises dans l’espace de travail Log Analytics du portail Azure. Dans la page Présentation, sélectionnez la vignette Paramètres. Sélectionnez l’onglet Sources connectées, situé en haut de la page.

Pour activer les diagnostics de démarrage, commencez par créer un compte de stockage. Puis, placez ce bloc JSON dans la propriété virtualMachineProfile de votre groupe de machines virtuelles identiques et mettez celui-ci à jour :

"diagnosticsProfile": {
    "bootDiagnostics": {
        "enabled": true,
        "storageUri": "http://yourstorageaccount.blob.core.windows.net"
    }
}

Lorsqu’une nouvelle machine virtuelle est créée, la propriété InstanceView de la machine virtuelle affiche les détails de la capture d’écran. Voici un exemple :

"bootDiagnostics": {
    "consoleScreenshotBlobUri": "https://o0sz3nhtbmkg6geswarm5.blob.core.windows.net/bootdiagnostics-swarmagen-4157d838-8335-4f78-bf0e-b616a99bc8bd/swarm-agent-9574AE92vmss-0_2.4157d838-8335-4f78-bf0e-b616a99bc8bd.screenshot.bmp",
    "serialConsoleLogBlobUri": "https://o0sz3nhtbmkg6geswarm5.blob.core.windows.net/bootdiagnostics-swarmagen-4157d838-8335-4f78-bf0e-b616a99bc8bd/swarm-agent-9574AE92vmss-0_2.4157d838-8335-4f78-bf0e-b616a99bc8bd.serialconsole.log"
}

Consultez la page Résolution des problèmes courants liés aux groupes de machines virtuelles identiques.

Vous pouvez appeler ListVMInstanceViews en exécutant une API REST GET sur l’URI de ressource suivant :

/subscriptions/<subscription_id>/resourceGroups/<resource_group_name>/providers/Microsoft.Compute/virtualMachineScaleSets/<scaleset_name>/virtualMachines?$expand=instanceView&$select=instanceView

Notez que le domaine d’erreur n’est pas retourné lorsque le groupe identique utilise la répartition maximale (platformFaultDomainCount = 1), car il n’existe aucune garantie quant au nombre de domaines d’erreur qui seraient utilisés avec ce paramètre.

Non, c’est impossible. Toutefois, les extensions peuvent agir en fonction des propriétés uniques de la machine virtuelle où elles s’exécutent, comme le nom de la machine. Les extensions peuvent aussi interroger les métadonnées d’instance sur http://169.254.169.254 pour obtenir plus d’informations sur la machine virtuelle.

Les lacunes sont dues au fait que la propriété de groupe de machines virtuelles identiques overprovision de votre machine virtuelle est définie sur la valeur par défaut de true. Si le sur-approvisionnement est défini sur true, le nombre de machines virtuelles créées est supérieur à ce qui est demandé. Les machines virtuelles supplémentaires sont ensuite supprimées. Dans ce cas, vous obtenez une fiabilité de déploiement accrue aux dépens d’une affectation de noms contigus et de règles NAT contiguës.

Vous pouvez affecter la valeur false à cette propriété. Pour les petits Virtual Machine Scale Sets identiques, la fiabilité du déploiement n’est pas considérablement affectée.

La principale différence est que les deallocate ne supprime pas les disques durs virtuels (VHD). Il existe des coûts de stockage associés à l’exécution de stop deallocate. Vous pouvez choisir l’une ou l’autre option pour l’une des raisons suivantes :

• Vous souhaitez arrêter de payer des frais de calcul, mais conserver l’état des disques des machines virtuelles.
• Vous souhaitez démarrer un groupe de machines virtuelles plus rapidement par rapport au scale-out d’un groupe de machines virtuelles identiques.
  • En relation avec ce scénario, vous avez peut-être créé votre propre moteur de mise à l’échelle automatique et souhaitez obtenir une mise à l’échelle de bout en bout plus rapide.
• Vous avez un groupe de machines virtuelles identiques qui est distribué inégalement entre les domaines d’erreur ou les domaines de mise à jour. Cette distribution inégale peut être due à la suppression sélective des machines virtuelles ou à la suppression des machines virtuelles après le surapprovisionnement. Exécutez stop deallocate suivi de start sur le groupe de machines virtuelles identiques pour distribuer uniformément les machines virtuelles entre les domaines d’erreur ou les domaines de mise à jour.

Créez une capture instantanée à partir d’une instance d’un groupe de machines virtuelles identiques. Voici un exemple :

$rgname = "myResourceGroup"
$vmssname = "myVMScaleSet"
$Id = 0
$location = "East US"

$vmss1 = Get-AzVmssVM -ResourceGroupName $rgname -VMScaleSetName $vmssname -InstanceId $Id
$snapshotconfig = New-AzSnapshotConfig -Location $location -AccountType Standard_LRS -OsType Windows -CreateOption Copy -SourceUri $vmss1.StorageProfile.OsDisk.ManagedDisk.id
New-AzSnapshot -ResourceGroupName $rgname -SnapshotName 'mySnapshot' -Snapshot $snapshotconfig

Créez un disque managé à partir de la capture instantanée. Voici un exemple :

$snapshotName = "mySnapshot"
$snapshot = Get-AzSnapshot -ResourceGroupName $rgname -SnapshotName $snapshotName
$diskConfig = New-AzDiskConfig -AccountType Premium_LRS -Location $location -CreateOption Copy -SourceResourceId $snapshot.Id
$osDisk = New-AzDisk -Disk $diskConfig -ResourceGroupName $rgname -DiskName ($snapshotName + '_Disk')