Exécuter une application multiniveau dans plusieurs régions Azure Stack Hub pour la haute disponibilité

Cette architecture de référence montre un ensemble de pratiques éprouvées pour l’exécution d’une application multiniveau sur plusieurs régions Azure Stack Hub pour obtenir la disponibilité et une infrastructure de récupération d’urgence robuste. Dans cette architecture, Azure Traffic Manager est utilisé pour obtenir une haute disponibilité. Toutefois, si Traffic Manager n’est pas un choix préféré dans votre environnement, vous pouvez remplacer une paire d’équilibreurs de charge hautement disponibles.

Architecture

Cette architecture s’appuie sur celle affichée dans l’application multiniveau avec SQL Server.

• Régions primaires et secondaires. Utilisez deux régions pour obtenir une disponibilité plus élevée. Une région est la région primaire. Utilisez l’autre région pour le basculement.

• Azure Traffic Manager. Traffic Manager achemine les requêtes entrantes vers l’une des régions. Pendant les opérations normales, il achemine les requêtes vers la région primaire. Si cette région devient indisponible, Traffic Manager bascule vers la région secondaire. Pour plus d’informations, consultez la section Configuration de Traffic Manager.

• Groupes de ressources. Créez des groupes de ressources distincts pour la région primaire et la région secondaire. Cette approche vous offre la possibilité de gérer chaque région en tant que collection unique de ressources. Par exemple, vous pouvez redéployer une région sans descendre l’autre région. Liez les groupes de ressources afin que vous puissiez exécuter une requête pour répertorier toutes les ressources de l’application.

• Réseaux virtuels. Créez un réseau virtuel distinct pour chaque région. Assurez-vous que les espaces d’adressage ne se chevauchent pas.

• Groupe de disponibilité Always On SQL Server. Si vous utilisez SQL Server, utilisez des groupes de disponibilité Always On SQL pour la haute disponibilité. Créez un groupe de disponibilité unique qui inclut les instances de SQL Server dans les deux régions.

• Connexion VPN de réseau virtuel à réseau virtuel. Étant donné que le peering de réseaux virtuels n’est pas encore disponible sur Azure Stack Hub, utilisez le réseau virtuel pour connecter les deux réseaux virtuels. Pour plus d’informations, consultez le réseau virtuel vers le réseau virtuel dans Azure Stack Hub.

Recommandations

Une architecture multirégion peut fournir une disponibilité plus élevée que le déploiement dans une seule région. Si une panne régionale affecte la région primaire, vous pouvez utiliser Traffic Manager pour basculer vers la région secondaire. Cette architecture peut également vous aider si un sous-système individuel de l’application échoue.

Il existe plusieurs approches générales pour atteindre la haute disponibilité entre les régions :

• Actif/passif avec secours à chaud. Le trafic passe à une région, tandis que l’autre attend le secours à chaud. La secours à chaud signifie que les machines virtuelles de la région secondaire sont allouées et en cours d’exécution à tout moment.

• Actif/passif avec secours à froid. Le trafic passe à une région, tandis que l’autre attend en veille à froid. La veille à froid signifie que les machines virtuelles de la région secondaire ne sont pas allouées tant que cela n’est pas nécessaire pour le basculement. Cette approche coûte moins cher à s’exécuter, mais il faudra généralement plus de temps pour venir en ligne lors d’une défaillance.

• Actif/actif. Les deux régions sont actives et les requêtes sont équilibrées entre elles. Si une région devient indisponible, elle est retirée de la rotation.

Cette architecture de référence se concentre sur le mode actif/passif avec secours à chaud, à l’aide de Traffic Manager pour le basculement. Vous pouvez déployer un petit nombre de machines virtuelles pour la secours à chaud, puis effectuer un scale-out en fonction des besoins.

Configuration de Traffic Manager

Tenez compte des points suivants lors de la configuration de Traffic Manager :

• Routage Traffic Manager prend en charge plusieurs algorithmes de routage. Pour le scénario décrit dans cet article, utilisez le routage de priorité (anciennement appelé routage de basculement ). Avec ce paramètre, Traffic Manager envoie toutes les requêtes à la région primaire, sauf si la région primaire devient inaccessible. À ce stade, il bascule automatiquement vers la région secondaire. Consultez Configurer la méthode de routage du basculement.

• Sonde d’intégrité. Traffic Manager utilise une sonde HTTP (ou HTTPS) pour surveiller la disponibilité de chaque région. La sonde vérifie la présence d’une réponse HTTP 200 pour un chemin d’URL spécifié. En guise de bonne pratique, créez un point de terminaison qui signale l’intégrité globale de l’application et utilisez ce point de terminaison pour la sonde d’intégrité. Sinon, la sonde peut signaler un point de terminaison sain lorsque les parties critiques de l’application échouent réellement. Pour plus d’informations, consultez Schéma de supervision de l'état de santé du point de terminaison.

Lorsque Traffic Manager bascule, il y a une période où les clients ne peuvent pas atteindre l’application. La durée est affectée par les facteurs suivants :

• La sonde d’intégrité doit détecter que la région primaire est devenue inaccessible.

• Les serveurs DNS doivent mettre à jour les enregistrements DNS mis en cache pour l’adresse IP, qui dépend de la durée de vie (TTL) DNS. La valeur TTL par défaut est de 300 secondes (5 minutes), mais vous pouvez configurer cette valeur quand vous créez le profil Traffic Manager.

Pour plus d’informations, consultez À propos de Traffic Manager Monitoring.

Si Traffic Manager bascule, nous vous recommandons d’effectuer une restauration automatique manuelle plutôt que d’implémenter une restauration automatique. Dans le cas contraire, vous pouvez créer une situation dans laquelle l’application retourne de nouveau et vers l’arrière entre les régions. Vérifiez que tous les sous-systèmes d’application sont intègres avant de procéder à une restauration automatique.

Notez que Traffic Manager échoue automatiquement par défaut. Pour éviter cela, réduisez manuellement la priorité de la région primaire après un événement de basculement. Par exemple, supposons que la région primaire est la priorité 1 et que la région secondaire est la priorité 2. Après un basculement, définissez la région primaire sur la priorité 3 pour empêcher la restauration automatique. Lorsque vous êtes prêt à basculer, revenez à la priorité à 1.

La commande Azure CLI suivante met à jour la priorité :

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type externalEndpoints --priority 3

Une autre approche consiste à désactiver temporairement le point de terminaison jusqu’à ce que vous soyez prêt à effectuer une restauration automatique :

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type externalEndpoints --endpoint-status Disabled

Selon la cause d’un basculement, vous devrez peut-être redéployer les ressources dans une région. Avant de revenir en arrière, effectuez un test de préparation opérationnelle. Le test doit vérifier les éléments suivants :

• Les machines virtuelles sont configurées correctement. (Tous les logiciels requis sont installés, IIS est en cours d’exécution, et ainsi de suite.)

• Les sous-systèmes d’application sont intègres.

• Tests fonctionnels. (Par exemple, le niveau de base de données est accessible à partir du niveau web.)

Configurer SQL Server groupes de disponibilité Always On

Avant Windows Server 2016, SQL Server groupes de disponibilité Always On nécessitent un contrôleur de domaine, et tous les nœuds du groupe de disponibilité doivent se trouver dans le même domaine Active Directory (AD).

Pour configurer le groupe de disponibilité :

• Au minimum, placez deux contrôleurs de domaine dans chaque région.

• Donnez à chaque contrôleur de domaine une adresse IP statique.

• Créez un VPN pour activer la communication entre deux réseaux virtuels.

• Pour chaque réseau virtuel, ajoutez les adresses IP des contrôleurs de domaine (des deux régions) à la liste des serveurs DNS. Vous pouvez utiliser la commande CLI suivante. Pour plus d’informations, consultez Modifier les serveurs DNS.

  az network vnet update --resource-group <resource-group> --name <vnet-name> --dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"
  

• Créez un cluster de clustering de basculement (WSFC) Windows Server qui inclut les instances de SQL Server dans les deux régions.

• Créez un SQL Server groupe de disponibilité Always On qui inclut les instances de SQL Server dans les régions primaires et secondaires. Consultez Extension du groupe de disponibilité Always On à remote Azure Datacenter (PowerShell) pour connaître les étapes.

  • Placez le réplica principal dans la région primaire.

  • Placez un ou plusieurs réplicas secondaires dans la région primaire. Configurez-les pour utiliser la validation synchrone avec le basculement automatique.

  • Placez un ou plusieurs réplicas secondaires dans la région secondaire. Configurez-les pour utiliser la validation asynchrone , pour des raisons de performances. (Sinon, toutes les transactions T-SQL doivent attendre un aller-retour sur le réseau vers la région secondaire.)

Considérations relatives à la disponibilité

Avec une application multiniveau complexe, il se peut que vous n’ayez pas besoin de répliquer l’ensemble de l’application dans la région secondaire. Au lieu de cela, vous pouvez simplement répliquer un sous-système critique nécessaire pour prendre en charge la continuité de l’activité.

Traffic Manager est un point d’échec possible dans le système. Si le service Traffic Manager échoue, les clients ne peuvent pas accéder à votre application pendant le temps d’arrêt. Passez en revue le contrat SLA Traffic Manager et déterminez si l’utilisation de Traffic Manager seul répond à vos besoins métier en matière de haute disponibilité. Si ce n’est pas le cas, envisagez d’ajouter une autre solution de gestion du trafic en tant que restauration automatique. Si le service Azure Traffic Manager échoue, modifiez vos enregistrements CNAME dans DNS pour qu’ils pointent vers l’autre service de gestion du trafic. (Cette étape doit être effectuée manuellement et votre application n’est pas disponible tant que les modifications DNS ne sont pas propagées.)

Pour le cluster SQL Server, il existe deux scénarios de basculement à prendre en compte :

• Tous les réplicas de base de données SQL Server dans la région primaire échouent. Par exemple, cette défaillance peut se produire lors d’une panne régionale. Dans ce cas, vous devez basculer manuellement le groupe de disponibilité, même si Traffic Manager bascule automatiquement sur le serveur frontal. Suivez les étapes décrites dans Effectuer un basculement manuel forcé d’un groupe de disponibilité SQL Server, qui décrit comment effectuer un basculement forcé à l’aide de SQL Server Management Studio, de Transact-SQL ou de PowerShell dans SQL Server 2016.

  Warning

  Avec le basculement forcé, il y a un risque de perte de données. Une fois que la région primaire est de retour en ligne, prenez un instantané de la base de données et utilisez tablediff pour trouver les différences.

• Traffic Manager bascule vers la région secondaire, mais le réplica de base de données principal SQL Server est toujours disponible. Par exemple, le niveau frontal peut échouer, sans affecter les machines virtuelles SQL Server. Dans ce cas, le trafic Internet est acheminé vers la région secondaire et cette région peut toujours se connecter au réplica principal. Toutefois, il y a une latence accrue, car les connexions SQL Server passent entre les régions. Dans ce cas, effectuez un basculement manuel comme suit :

  1. Basculez temporairement un réplica de base de données SQL Server dans la région secondaire pour valider synchrone. Cette modification garantit qu’il n’y a aucune perte de données pendant le basculement.

  2. Basculez vers ce réplica.

  3. Lorsque vous effectuez une restauration automatique vers la région primaire, restaurez le paramètre de validation asynchrone.

Considérations relatives à la facilité de gestion

Lorsque vous mettez à jour votre déploiement, mettez à jour une région à la fois pour réduire la probabilité d’une défaillance globale d’une configuration incorrecte ou d’une erreur dans l’application.

Testez la résilience du système en cas d’échecs. Voici quelques scénarios d’échec courants à tester :

• Arrêtez les instances de machine virtuelle.

• Pression des ressources telles que le processeur et la mémoire.

• Déconnectez ou retardez le réseau.

• Processus d’incident.

• Expirez les certificats.

• Simuler des erreurs matérielles.

• Arrêtez le service DNS sur les contrôleurs de domaine.

Mesurez les temps de récupération et vérifiez qu’ils répondent aux besoins de votre entreprise. Testez également les combinaisons de modes d’échec.

Étapes suivantes

• Pour en savoir plus sur les modèles cloud Azure, consultez Modèles de conception cloud.