Partager via

Les instances du groupe de machines virtuelles identiques Azure ne sont pas réparées même si la stratégie de réparation automatique est activée

  • Article

Les instances Azure VMSS restent dans un état « non sain » et ne sont pas réparées même lorsque la stratégie de réparation automatique est activée. Cet article fournit des causes possibles et des solutions correspondantes pour ce problème :

La stratégie de réparation automatique n’est pas correctement activée dans le groupe identique

Vérifiez que votre vmSS est choisi dans les réparations automatiques en affichant son état de service.

Sous la orchestrationServices propriété, si les serviceState réparations automatiques sont Runningeffectuées, la vmSS est choisie en réparations automatiques.

Si la serviceState stratégie de NotRunning réparation automatique ne s’affiche pas sous la orchestrationServices propriété, vous devez activer la stratégie de réparation automatique dans le groupe identique. Pour plus d’informations, consultez Activation de la stratégie de réparation automatique lors de la mise à jour d’un groupe identique existant.

Si la serviceState valeur est Suspended, accédez aux réparations automatiques ont été suspendues dans le groupe identique en raison d’un trop grand nombre de réparations ayant échoué.

La surveillance de l’intégrité n’est pas correctement configurée dans le groupe identique

Si toutes les instances du groupe identique s’affichent comme étant « non saines », il peut s’agir d’un signe indiquant que votre sonde d’analyse de l’intégrité n’est pas configurée correctement pendant l’installation. Assurez-vous que votre application émet les réponses HTTP/HTTPS/TCP attendues aux points de terminaison configurés.

Pour obtenir un état « Sain », les sondes d’extension d’intégrité de l’application ou les sondes d’intégrité de l’équilibreur de charge nécessitent, au minimum, une réponse HTTP(S) 2xx ou une négociation TCP réussie à partir de votre application au niveau du point de terminaison configuré. Si la réponse attendue n’est pas reçue, un état « non sain » est signalé. Vérifiez que les signaux d’intégrité corrects sont émis par votre application sur le point de terminaison fourni.

Pour plus d’informations sur les réponses TCP/HTTP(S) attendues pour les sondes d’intégrité de l’équilibreur de charge, consultez Sondes personnalisées Load Balancer.

Pour plus d’informations sur les réponses TCP/HTTP(S) attendues pour les sondes d’extension d’intégrité de l’application, consultez la section « Configurer le point de terminaison pour fournir l’état d’intégrité » dans Configuration requise pour l’utilisation des réparations automatiques d’instances.

L’instance est marquée comme non saine en raison d’un échec d’approvisionnement

Utilisez Get Instance View avec l’API version 2019-12-01 ou ultérieure pour vmSS pour afficher l’état d’approvisionnement des instances sous statusesSummary la virtualMachine propriété.

API REST

GET '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/virtualMachineScaleSets/{vmScaleSetName}/instanceView?api-version=2019-12-01'

"virtualMachine": {
        "statusesSummary": [
            {
                "code": "ProvisioningState/succeeded",
                "count": 2
            }
        ]
}

Si vous avez un ProvisioningState/failed code sous statusesSummary, supprimez l’instance ayant échoué et ajoutez une nouvelle instance à votre groupe identique. Actuellement, les réparations d’instance ne prennent pas en charge les scénarios où une machine virtuelle est marquée « Non saine » en raison d’un échec d’approvisionnement.

Pour supprimer l’instance ayant échoué de votre groupe identique, consultez Supprimer des machines virtuelles d’un groupe identique.

Pour ajouter une nouvelle instance à votre groupe identique, consultez Modifier la capacité d’un groupe identique.

Les réparations automatiques ont été suspendues dans le groupe identique en raison d’un trop grand nombre de réparations ayant échoué

Si votre application continue d’émettre un signal « Non sain » après des tentatives de réparation répétées, la plateforme interrompt éventuellement les réparations d’instance en tant que mesure de sécurité en changeant les serviceState réparations automatiques en Suspended.

Confirmez la serviceState stratégie de réparation automatique. Pour ce faire, consultez l’affichage et la mise à jour de l’état du service de la stratégie de réparation d’instance automatique.

Si c’est serviceState Suspendedle cas, reprenez les réparations automatiques en mettant à jour le serviceState retour à Running l’aide de l’API setOrchestrationServiceState et des exemples d’applets de commande dans l’affichage et la mise à jour de l’état du service de la stratégie de réparation d’instance automatique.

L’instance est dans sa période de grâce

Si aucune des causes ci-dessus ne s’applique au problème, l’instance peut se trouver dans sa période de grâce.

La période de grâce est la durée pendant laquelle les réparations automatiques attendent après toute modification de l’état sur l’instance avant d’effectuer des réparations, ce qui permet d’éviter toute réparation prématurée ou accidentelle. L’action de réparation doit se produire une fois que la période de grâce est terminée pour l’instance. Pour plus d’informations sur le paramètre de période de grâce pour les réparations automatiques, consultez Période de grâce.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.