Partager via

Prise en charge de la zone de disponibilité pour App Service Environment v2

  • Article

Important

Cet article concerne la fonctionnalité App Service Environment v2, qui est utilisée avec les plans App Service isolés. App Service Environment v1 et v2 sont mis hors service le 31 août 2024. Il existe une nouvelle version d’App Service Environment, plus facile à utiliser et qui s’exécute sur des infrastructures plus puissantes. Pour en savoir plus sur la nouvelle version, commencez par consulter Présentation de l’environnement App Service Environment. Si vous utilisez actuellement App Service Environment v1, suivez les étapes de cet article pour migrer vers la nouvelle version.

À compter du 31 août 2024, le Contrat de niveau de service (SLA) et les crédits de service ne s’appliquent plus aux charges de travail App Service Environment v1 et v2 qui sont toujours en production, car ce sont des produits mis hors service. La mise hors service du matériel App Service Environment v1 et v2 a commencé, ce qui risque d’avoir une incidence sur la disponibilité et les performances de vos applications et de vos données.

Vous devez effectuer la migration vers App Service Environment v3 immédiatement, sans quoi vos applications et ressources risquent d’être supprimées. Nous ferons tout notre possible pour migrer automatiquement les charges de travail App Service v1 et v2 restantes à l’aide de la fonctionnalité de migration sur place, mais Microsoft ne garantit nullement ni n’affirme que les applications seront disponibles après la migration automatique. Vous serez peut-être amené à effectuer une configuration manuelle pour finaliser la migration et choisir la référence SKU du plan App Service la mieux adaptée à vos besoins. Si la migration automatique n’est pas possible, vos ressources et les données d’application associées seront supprimées. Nous vous recommandons vivement d’agir dès maintenant pour éviter l’un ou l’autre de ces scénarios extrêmes.

Si vous avez besoin de plus de temps, nous pouvons offrir une seule période de grâce de 30 jours pour vous permettre d’effectuer votre migration. Pour plus d’informations et pour demander cette période de grâce, passez en revue la vue d’ensemble de la période de grâce, puis accédez au portail Azure et visitez le panneau Migration pour chacun de vos environnements App Service.

Pour obtenir les informations les plus à jour sur la mise hors service d’App Service Environment v1/v2, consultez la Mise à jour sur la mise hors service d’App Service Environment v1 et v2.

App Service Environment (ASE) v2 peut être déployé dans des zones de disponibilité (AZ). Les clients peuvent déployer un ASE d’équilibreur de charge interne (ILB) dans une zone de disponibilité spécifique au sein d’une région Azure. Si vous épinglez votre ASE ILB à une zone de disponibilité spécifique, les ressources utilisées par un ASE ILB seront épinglées à la zone de disponibilité spécifiée ou bien déployées de manière redondante dans une zone.

Un ASE ILB déployé explicitement dans une zone de disponibilité est considéré comme une ressource zonale, car l’ASE ILB est épinglé à une zone spécifique. Les dépendances ASE ILB suivantes seront épinglées à la zone spécifiée :

  • l’adresse IP de l’équilibreur de charge interne de l’ASE
  • les ressources de calcul utilisées par l’ASE pour gérer et exécuter des applications web

Le stockage de fichiers à distance pour les applications web déployées sur un ASE ILB utilise le stockage redondant interzone (ZRS).

Si les étapes décrites dans cet article ne sont pas suivies, les ASE ILB ne sont pas déployés automatiquement de manière zonale. Vous ne pouvez pas épingler un ASE externe avec une adresse IP publique à une zone de disponibilité spécifique.

Les ASE ILB zonaux peuvent être créés dans l’une des régions suivantes :

  • Australie Est
  • Centre du Canada
  • USA Centre
  • USA Est
  • USA Est 2
  • USA Est 2 (EUAP)
  • France Centre
  • Japon Est
  • Europe Nord
  • Europe Ouest
  • Asie Sud-Est
  • Sud du Royaume-Uni
  • USA Ouest 2

Les applications déployées sur un ASE ILB zonal continuent à s’exécuter et à traiter le trafic sur cet ASE, même si d’autres zones de la même région subissent une panne. Il est possible que les comportements hors runtime, dont la mise à l’échelle du plan de service d’application, la création de l’application, la configuration de l’application et la publication de l’application soient affectés par une panne dans d’autres zones de disponibilité. Le déploiement épinglé à une zone d’un ASE ILB zonal assure uniquement la continuité de service des applications déjà déployées.

Comment déployer App Service Environment dans une zone de disponibilité

Les ASE ILB zonaux doivent être créés à l’aide de modèles ARM. Une fois qu’un ASE ILB zonal est créé via un modèle ARM, vous pouvez l’afficher et interagir avec via le portail Azure et l’interface CLI. Un modèle ARM n’est nécessaire que pour la création initiale d’un ASE ILB zonal.

Le seul changement nécessaire dans un modèle ARM pour spécifier un ASE ILB zonal est la nouvelle propriété zones. La propriété zones doit être définie sur la valeur « 1 », « 2 » ou « 3 » selon la zone de disponibilité logique à laquelle l’environnement ASE ILB doit être épinglé.

L'exemple de modèle ARM ci-dessous montre la nouvelle propriété zones qui spécifie que l'ASE ILB doit être placé dans la zone 2.

"resources": [
    {
        "type": "Microsoft.Web/hostingEnvironments",
        "kind": "ASEV2",
        "name": "yourASENameHere",
        "apiVersion": "2015-08-01",
        "location": "your location here",
        "zones": [
            "2"
        ],
        "properties": {
            "name": "yourASENameHere",
            "location": "your location here",
            "ipSslAddressCount": 0,
            "internalLoadBalancingMode": "3",
            "dnsSuffix": "contoso-internal.com",
            "virtualNetwork": {
                "Id": "/subscriptions/your-subscription-id-here/resourceGroups/your-resource-group-here/providers/Microsoft.Network/virtualNetworks/your-vnet-name-here",
                "Subnet": "yourSubnetNameHere"
            }
        }
    }
]

Pour que votre zone d’applications soit redondante, vous devez déployer deux ASE ILB zonaux. Les deux ASE ILB zonaux doivent se trouver dans des zones de disponibilité distinctes. Vous devez ensuite déployer vos applications dans chacun des ASE ILB. Une fois vos applications créées, vous devez configurer une solution d’équilibrage de charge. La solution recommandée consiste à déployer une passerelle applicative avec redondance interzone en amont de l’ASE ILB zonal.

Résidence des données dans la région

Les ASE ILB déployés dans une zone de disponibilité stockent uniquement les données client dans la région où l’ASE ILB zonal a été déployé. Le contenu du fichier de site web ainsi que les paramètres et secrets fournis par le client stockés dans App Service restent dans la région où l’ASE ILB zonal est déployé.

Les clients garantissent la résidence des données dans une région unique en suivant les étapes décrites plus haut dans la section « Comment déployer App Service Environment dans une zone de disponibilité ». Si vous configurez un environnement App Service Environment selon ces étapes, un environnement App Service Environment déployé dans une zone de disponibilité répond aux exigences de la résidence des données de la région, y compris celles spécifiées dans le Centre de confidentialité Azure.

Les clients peuvent valider qu’un App Service Environment est correctement configuré pour stocker des données dans une seule région en procédant comme suit :

  1. En utilisant l’Explorateur de ressources, accédez à la ressource Azure Resource Manager pour l’environnement App Service. Les ASE sont répertoriés sous providers/Microsoft.Web/hostingEnvironments.
  2. Si une propriété zones existe dans la vue de la syntaxe JSON Azure Resource Manager et qu’elle contient un tableau JSON à valeur unique avec la valeur « 1 », « 2 » ou « 3 », l’ASE est déployé par zone et les données du client restent dans la même région.
  3. Si aucune propriété zones n’est présente ou si la propriété n’a pas de valeur de zone valide comme indiqué précédemment, l’ASE n’est pas déployé par zone et les données du client ne sont pas stockées exclusivement dans la même région.