Utilisation de l’extension Intégrité de l’application avec des Virtual Machine Scale Sets

La surveillance de l’intégrité de votre application est un signal important pour la gestion et la mise à niveau votre déploiement. Groupes de machines virtuelles identiques Azure prennent en charge les mises à niveau propagées, y compris les mises à niveau automatiques de l’image du système d’exploitation et la mise à jour corrective automatique des invités de machine virtuelle, qui reposent sur la surveillance de l’état de santé des instances individuelles pour mettre à niveau votre déploiement. Vous pouvez également utiliser l’extension Intégrité de l’application pour surveiller l’intégrité des applications de chaque instance de votre groupe identique et effectuer des réparations d’instance à l’aide de réparations automatiques d’instances.

Cet article décrit comment vous pouvez utiliser les deux types d’extension Application Health, Binary Health States ou Rich Health States, pour surveiller l’état de santé de vos applications déployées sur des groupes de machines virtuelles identiques.

Prérequis

Cet article suppose de connaître :

• extensions de machine virtuelle Azure
• La modification des Virtual Machine Scale Sets

Quand utiliser l’extension Santé de l’application

L’extension Intégrité de l’application est déployée à l’intérieur d’une instance de Virtual Machine Scale Set et rend compte de l’intégrité des applications à partir de l’instance de groupe identique. L’extension sonde le point de terminaison d’une application locale et met à jour l’état d’intégrité en fonction des réponses TCP/HTTP(S) renvoyées par l’application. Cet état d’intégrité est utilisé par Azure pour lancer des réparations sur des instances non saines et pour déterminer si une instance est éligible à des opérations de mise à niveau.

L’extension signale l’état d’intégrité depuis l’intérieur d’une machine virtuelle et peut être utilisée lorsqu’il n’est pas possible d’utiliser une sonde externe, telle que les sondes d’intégrité d’Azure Load Balancer.

Binary ou Rich Health States

Les extensions Intégrité de l’application ont deux options : États d’intégrité binaires et États d’intégrité enrichis. Le tableau suivant met en évidence certaines différences clés entre les deux options. Consultez la fin de cette section pour obtenir des recommandations générales.

¹ L’état Inconnu n’est pas disponible sur le protocole TCP. ² S’applique uniquement au protocole HTTP/HTTPS. Le protocole TCP suit le même processus d’identification des instances non saines que dans Binary Health States.

En général, vous devez utiliser Rich Health States si :

• Vous envoyez des signaux d’état via le protocole HTTP/HTTPS et pouvez transmettre des informations d’état dans le corps de réponse de la sonde.
• Vous aimeriez utiliser une logique personnalisée pour identifier et marquer des instances non saines.
• Vous aimeriez définir une période de grâce d’initialisation pour les instances nouvellement créées, afin qu’elles atteignent un état de santé stable avant de rendre l’instance éligible à une mise à niveau progressive ou à des réparations d’instance
• Vous souhaitez avoir plus de contrôle sur le processus d'ordre et de mise à jour avec des mises à niveau progressives, en émettant des métriques personnalisées

Vous devez utiliser les états de santé binaires si :

• Vous n’êtes pas intéressé par la configuration d’une logique personnalisée pour identifier et marquer une instance non saine.
• Vous n’avez pas besoin d’une période de grâce d’initialisation pour les instances récemment créées.
• Vous n’avez pas besoin d’utiliser des métriques personnalisées lors de l’exécution d’une mise à niveau propagée sur vos machines virtuelles

États de santé riches

Les rapports États d’intégrité enrichis contiennent quatre états d’intégrité : Initialisation en cours, Sain, Non sain et Inconnu. Les tableaux suivants fournissent une brève description indiquant comment chaque état de santé est configuré.

Protocole HTTP/HTTPS

Protocole TCP

État d'initialisation

Cet état s’applique uniquement à Rich Health States. L’état Initialisation n’apparaît qu’au démarrage de l’extension et peut être configuré par les paramètres de l’extension gracePeriod et numberOfProbes.

Au démarrage de l’extension, l’état de santé de l’application restera dans l’état Initialisation jusqu’à ce que l’un des deux scénarios suivants se produise :

• Le même état d’intégrité (Sain ou Non sain) est signalé un nombre consécutif de fois comme configuré par numberOfProbes.
• Le gracePeriod expire.

Si le même état d’intégrité (Sain ou Non sain) est signalé consécutivement, l’intégrité de l’application sort de l’état Initialisation en cours pour passer à l’état d’intégrité signalé (Sain ou Non sain).

Exemple

Si numberOfProbes = 3, cela signifierait :

• Pour passer de l’état Initialisation en cours à l’état Sain : l’extension d’intégrité de l’application doit recevoir trois signaux Sain consécutifs via le protocole HTTP/HTTPS ou TCP.
• Pour passer de l’état Initialisation à l’état Dégradé : l’extension d’intégrité de l’application doit recevoir trois signaux Dégradé consécutifs via le protocole HTTP/HTTPS ou TCP.

Si le paramètre gracePeriod expire avant qu’un état d’intégrité consécutif ne soit signalé par l’application, l’intégrité de l’instance est déterminée ainsi :

• Protocole HTTP/HTTPS : l’intégrité de l’application passe de l’état Initialisation en cours à l’état Inconnu.
• Protocole TCP : l’état de santé de l’application passera de Initialisation en cours à Dégradé

État inconnu

Cet état s’applique uniquement aux états de santé enrichis. L’état Inconnu est signalé uniquement pour les sondes « http » ou « https » et se produit dans les scénarios suivants :

• Quand un code d’état autre que 2xx est retourné par l’application
• Quand la requête de sonde d’intégrité expire
• Lorsque le point de terminaison de l’application est inaccessible ou mal configuré
• Lorsqu’une valeur absente ou invalide est fournie pour ApplicationHealthState dans le corps de la réponse
• Quand la période de grâce expire

Une instance dont l’état est Inconnu est traitée de la même manière qu’une instance non saine. Si cette option est activée, les réparations d’instance sont effectuées sur une instance dont l’état est Inconnu, alors que les mises à niveau propagées sont suspendues jusqu’à ce que l’instance repasse à l’état Sain.

Le tableau suivant indique comment interpréter l’état d’intégrité pour les mises à niveau propagées et les réparations d’instance :

Schéma d’extension pour Rich Health States

Le code JSON suivant montre le schéma de l’extension Rich Health States. L’extension nécessite au minimum une requête « http » ou « https » avec respectivement un port ou un chemin de requête associés. Les sondes TCP sont également prises en charge, mais elles ne pourront pas définir le ApplicationHealthState via le corps de réponse de la sonde et n’auront pas accès à l’état Unknown.

{
  "extensionProfile" : {
     "extensions" : [
      {
        "name": "HealthExtension",
        "properties": {
          "publisher": "Microsoft.ManagedServices",
          "type": "<ApplicationHealthLinux or ApplicationHealthWindows>",
          "autoUpgradeMinorVersion": true,
          "typeHandlerVersion": "2.0",
          "settings": {
            "protocol": "<protocol>",
            "port": <port>,
            "requestPath": "</requestPath>",
            "intervalInSeconds": 5,
            "numberOfProbes": 1,
            "gracePeriod": 600
          }
        }
      }
    ]
  }
} 

Valeurs de propriétés

Paramètres

États de santé binaires

Le rapport d’état d’intégrité binaire contient deux états d’intégrité, Sain et Non sain. Les tableaux suivants présentent une brève description de la configuration des états de santé.

Protocole HTTP/HTTPS

Protocole TCP

Voici quelques scénarios susceptibles d’entraîner un état Non sain :

• Quand le point de terminaison d’application retourne un code d’état non-200
• Lorsqu’aucun point de terminaison d’application n’est configuré à l’intérieur des instances de machine virtuelle pour fournir l’état d’intégrité de l’application
• Lorsque le point de terminaison d’application n’est pas configuré correctement
• Lorsque le point de terminaison d’application n’est pas accessible

Schéma d’extension pour Binary Health States

Le code JSON suivant présente le schéma de l’extension Application Health. L’extension nécessite au minimum une requête « tcp », « http » ou « https » avec respectivement un port ou un chemin d’accès à la demande associés.

{
  "extensionProfile" : {
     "extensions" : [
      {
        "name": "HealthExtension",
        "properties": {
          "publisher": "Microsoft.ManagedServices",
          "type": "<ApplicationHealthLinux or ApplicationHealthWindows>",
          "autoUpgradeMinorVersion": true,
          "typeHandlerVersion": "1.0",
          "settings": {
            "protocol": "<protocol>",
            "port": <port>,
            "requestPath": "</requestPath>",
            "intervalInSeconds": 5,
            "numberOfProbes": 1
          }
        }
      }
    ]
  }
} 

Valeurs de propriétés

Paramètres

Déployer l’extension Application Health

Il existe plusieurs façons de déployer l’extension Intégrité de l’application sur vos groupes identiques, comme indiqué dans les exemples suivants.

États de santé riches

PUT on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/extensions/myHealthExtension?api-version=2018-10-01`

{
  "name": "myHealthExtension",
  "location": "<location>",
  "properties": {
    "publisher": "Microsoft.ManagedServices",
    "type": "ApplicationHealthWindows",
    "autoUpgradeMinorVersion": true,
    "typeHandlerVersion": "2.0",
    "settings": {
      "protocol": "<protocol>",
      "port": <port>,
      "requestPath": "</requestPath>",
      "intervalInSeconds": <intervalInSeconds>,
      "numberOfProbes": <numberOfProbes>,
      "gracePeriod": <gracePeriod>
    }
  }
}

POST on `/subscriptions/<subscriptionId>/resourceGroups/<myResourceGroup>/providers/Microsoft.Compute/virtualMachineScaleSets/< myScaleSet >/manualupgrade?api-version=2022-08-01`

{
  "instanceIds": ["*"]
}

# Define the scale set variables
$vmScaleSetName = "myVMScaleSet"
$vmScaleSetResourceGroup = "myVMScaleSetResourceGroup"

# Define the Application Health extension properties
$publicConfig = @{"protocol" = "http"; "port" = 80; "requestPath" = "/healthEndpoint"; "gracePeriod" = 600};
$extensionName = "myHealthExtension"
$extensionType = "ApplicationHealthWindows"
$publisher = "Microsoft.ManagedServices"

# Get the scale set object
$vmScaleSet = Get-AzVmss `
  -ResourceGroupName $vmScaleSetResourceGroup `
  -VMScaleSetName $vmScaleSetName

# Add the Application Health extension to the scale set model
Add-AzVmssExtension -VirtualMachineScaleSet $vmScaleSet `
  -Name $extensionName `
  -Publisher $publisher `
  -Setting $publicConfig `
  -Type $extensionType `
  -TypeHandlerVersion "2.0" `
  -AutoUpgradeMinorVersion $True

# Update the scale set
Update-AzVmss -ResourceGroupName $vmScaleSetResourceGroup `
  -Name $vmScaleSetName `
  -VirtualMachineScaleSet $vmScaleSet
  
# Upgrade instances to install the extension
Update-AzVmssInstance -ResourceGroupName $vmScaleSetResourceGroup `
  -VMScaleSetName $vmScaleSetName `
  -InstanceId '*'

az vmss extension set \
  --name ApplicationHealthLinux \
  --publisher Microsoft.ManagedServices \
  --version 2.0 \
  --resource-group <myVMScaleSetResourceGroup> \
  --vmss-name <myVMScaleSet> \
  --settings ./extension.json

{
  "protocol": "<protocol>",
  "port": <port>,
  "requestPath": "</requestPath>",
  "gracePeriod": <healthExtensionGracePeriod>
}

az vmss update-instances \
  --resource-group <myVMScaleSetResourceGroup> \
  --name <myVMScaleSet> \
  --instance-ids "*"

États de santé binaires

PUT on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/extensions/myHealthExtension?api-version=2018-10-01`

{
  "name": "myHealthExtension",
  "location": "<location>", 
  "properties": {
    "publisher": "Microsoft.ManagedServices",
    "type": "ApplicationHealthWindows",
    "autoUpgradeMinorVersion": true,
    "typeHandlerVersion": "1.0",
    "settings": {
      "protocol": "<protocol>",
      "port": <port>,
      "requestPath": "</requestPath>"
    }
  }
}

POST on `/subscriptions/<subscriptionId>/resourceGroups/<myResourceGroup>/providers/Microsoft.Compute/virtualMachineScaleSets/< myScaleSet >/manualupgrade?api-version=2022-08-01`

{
  "instanceIds": ["*"]
}

# Define the scale set variables
$vmScaleSetName = "myVMScaleSet"
$vmScaleSetResourceGroup = "myVMScaleSetResourceGroup"

# Define the Application Health extension properties
$publicConfig = @{"protocol" = "http"; "port" = 80; "requestPath" = "/healthEndpoint"};
$extensionName = "myHealthExtension"
$extensionType = "ApplicationHealthWindows"
$publisher = "Microsoft.ManagedServices"

# Get the scale set object
$vmScaleSet = Get-AzVmss `
  -ResourceGroupName $vmScaleSetResourceGroup `
  -VMScaleSetName $vmScaleSetName

# Add the Application Health extension to the scale set model
Add-AzVmssExtension -VirtualMachineScaleSet $vmScaleSet `
  -Name $extensionName `
  -Publisher $publisher `
  -Setting $publicConfig `
  -Type $extensionType `
  -TypeHandlerVersion "1.0" `
  -AutoUpgradeMinorVersion $True

# Update the scale set
Update-AzVmss -ResourceGroupName $vmScaleSetResourceGroup `
  -Name $vmScaleSetName `
  -VirtualMachineScaleSet $vmScaleSet
  
# Upgrade instances to install the extension
Update-AzVmssInstance -ResourceGroupName $vmScaleSetResourceGroup `
  -VMScaleSetName $vmScaleSetName `
  -InstanceId '*'

az vmss extension set \
  --name ApplicationHealthLinux \
  --publisher Microsoft.ManagedServices \
  --version 1.0 \
  --resource-group <myVMScaleSetResourceGroup> \
  --vmss-name <myVMScaleSet> \
  --settings ./extension.json

{
  "protocol": "<protocol>",
  "port": <port>,
  "requestPath": "</requestPath>"
}

az vmss update-instances \
  --resource-group <myVMScaleSetResourceGroup> \
  --name <myVMScaleSet> \
  --instance-ids "*"

Résolution des problèmes

Besoin d’aide pour configurer une réponse de sonde

Consultez les exemples d’état de santé de l’application pour voir des exemples de réponses de sonde de vérification d’état envoyées à un point de terminaison local.

Voir VMHealth – instance unique

Get-AzVmssVM 
  -InstanceView `
  -ResourceGroupName <rgName> `
  -VMScaleSetName <vmssName> `
  -InstanceId <instanceId> 

Afficher VMHealth – appel par lot

Cette option est uniquement disponible pour les Virtual Machine Scale Sets avec orchestration Uniform.

GET on `/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Compute/virtualMachineScaleSets/<vmssName>/virtualMachines/?api-version=2022-03-01&$expand=instanceview`

L’état d’intégrité n’apparaît pas

Si l’état d’intégrité n’apparaît pas dans le portail Azure ou par le biais d’un appel GET, vérifiez que la machine virtuelle est mise à niveau vers le modèle le plus récent. Si la machine virtuelle n’utilise pas le modèle le plus récent, mettez-la à niveau et l’état d’intégrité s’affichera.

Journal de sortie d’exécution de l’extension

La sortie de l’exécution de l’extension est journalisées dans des fichiers figurant dans les répertoires suivants :

C:\WindowsAzure\Logs\Plugins\Microsoft.ManagedServices.ApplicationHealthWindows\<version>\

/var/lib/waagent/Microsoft.ManagedServices.ApplicationHealthLinux-<extension_version>/status
/var/log/azure/applicationhealth-extension

Les journaux d’activité capturent également régulièrement l’état d’intégrité de l’application.

Étapes suivantes

Découvrez comment déployer votre application sur des groupes identiques de machines virtuelles.