Partager via

Fiabilité dans Azure Spring Apps

  • Article

Cet article contient des informations détaillées sur la résilience régionale avec la prise en charge des zones de disponibilité et de la récupération d’urgence et continuité d’activité entre régions pour Azure Spring Apps.

Prise en charge des zones de disponibilité

Les zones de disponibilité sont des groupes de centres de données physiquement séparés au sein de chaque région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Pour plus d’informations sur les zones de disponibilité dans Azure, consultez Que sont les zones de disponibilité ?.

Azure Spring Apps prend en charge la redondance interzone. Quand vous créez une instance de service Azure Spring Apps avec la redondance interzone activée, Azure Spring Apps distribue automatiquement les ressources fondamentales entre les sections logiques de l’infrastructure Azure sous-jacente. La ressource de calcul sous-jacente répartit les machines virtuelles sur toutes les zones de disponibilité pour garantir la capacité de calcul. La ressource de stockage sous-jacente réplique les données entre les zones de disponibilité pour les garder disponibles même en cas de défaillance des centres de données. Cette distribution offre un niveau de disponibilité plus élevé et protège contre les défaillances matérielles et les événements de maintenance planifiée.

Prérequis

  • La redondance interzone n’est pas disponible dans le plan de base.

  • Azure Spring Apps prend en charge les zones de disponibilité dans les régions suivantes :

    • Australie Est
    • Brésil Sud
    • Centre du Canada
    • USA Centre
    • Asie Est
    • USA Est
    • USA Est 2
    • France Centre
    • Allemagne Centre-Ouest
    • Europe Nord
    • Japon Est
    • Corée Centre
    • Afrique du Sud Nord
    • États-Unis - partie centrale méridionale
    • Asie Sud-Est
    • Sud du Royaume-Uni
    • Europe Ouest
    • USA Ouest 2
    • USA Ouest 3

Créer une instance Azure Spring Apps avec une zone de disponibilité activée

Remarque

Vous pouvez activer la redondance interzone seulement quand vous créez votre instance de service Azure Spring Apps. Vous ne pouvez pas changer la propriété de redondance interzone après la création.

Vous pouvez activer la redondance interzone dans Azure Spring Apps avec Azure CLI ou le portail Azure.

Pour créer un service dans Azure Spring Apps en activant la redondance interzone avec Azure CLI, ajoutez le paramètre --zone-redundant quand vous créez le service, comme indiqué dans l’exemple suivant :

az spring create \
    --resource-group <your-resource-group-name> \
    --name <your-Azure-Spring-Apps-instance-name> \
    --location <location> \
    --zone-redundant true

Activer votre propre ressource avec les zones de disponibilité activées

Vous pouvez activer votre propre ressource dans Azure Spring Apps, comme votre propre stockage persistant. Toutefois, vous devez activer la redondance interzone pour votre ressource. Pour plus d’informations, consultez Guide pratique pour activer son propre stockage persistant dans Azure Spring Apps.

Expérience en cas de panne de zone

Si une instance d’application échoue en raison d’une panne de la zone où se trouve le nœud VM qui l’héberge, Azure Spring Apps crée une instance d’application pour cette application sur un autre nœud VM dans une autre zone de disponibilité. Les utilisateurs peuvent observer une brève interruption pendant cette période. Aucune action de l’utilisateur n’est nécessaire et l’instance Azure Spring Apps impactée est restaurée par le service.

Tarification

Aucun coût supplémentaire n’est associé à l’activation de la redondance interzone. Vous devez uniquement avoir acheté un plan Standard ou Entreprise, ce qui est obligatoire pour activer la redondance interzone.

Récupération d’urgence et continuité d’activité inter-région

La récupération d’urgence (DR) consiste à récupérer après des évènements à fort impact, comme des catastrophes naturelles ou des échecs de déploiements, qui entraînent un temps d’arrêt et une perte de données. Quelle qu’en soit la cause, la meilleure solution en cas de sinistre est d’avoir un plan de DR bien défini et testé, et une conception d’application qui prend activement en charge la DR. Avant de commencer à réfléchir à la création de votre plan de récupération d’urgence, consultez Suggestions pour la conception d’une stratégie de récupération d’urgence.

En ce qui concerne la récupération d’urgence (DR), Microsoft utilise le modèle de responsabilité partagée. Dans un modèle de responsabilité partagée, Microsoft garantit que l’infrastructure de référence et les services de plateforme sont disponibles. En même temps, de nombreux services Azure ne répliquent pas automatiquement les données ou reviennent d’une région défaillante pour effectuer une réplication croisée vers une autre région activée. Pour ces services, vous êtes en charge de la configuration d’un plan de récupération d’urgence qui fonctionne pour votre charge de travail. La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure fournissent des fonctionnalités et des conseils pour prendre en charge la récupération d’urgence et vous pouvez utiliser fonctionnalités spécifiques au service pour prendre en charge la récupération rapide pour vous aider à développer votre plan de récupération d’urgence.

Le service Azure Spring Apps ne fournit pas de géo-reprise d’activité après sinistre. Une planification minutieuse peut toutefois vous protéger contre les temps d’arrêt.

Pour garantir la haute disponibilité et la protection contre les sinistres, déployez dans plusieurs régions vos applications hébergées dans Azure Spring Apps. Azure fournit une liste de régions jumelées pour vous permettre de planifier vos déploiements d’applications en conséquence.

Tenez compte des facteurs clés suivants lorsque vous concevez votre architecture :

  • Disponibilité dans les régions : Pour réduire le décalage réseau et le temps de transmission, choisissez une région qui prend en charge la redondance interzone Azure Spring Apps ou une zone géographique proche de vos utilisateurs.
  • Régions appairées Azure. Pour garantir la coordination des mises à jour de plateforme et, si nécessaire, la hiérarchisation des efforts de récupération, choisissez des régions jumelées au sein de la zone géographique choisie.
  • Disponibilité du service. Décidez si vos régions appairées doivent avoir un niveau de disponibilité chaud/chaud, chaud/tiède ou chaud/froid.

Utiliser Azure Traffic Manager pour router le trafic

Azure Traffic Manager fournit un équilibreur de charge de trafic DNS qui peut répartir le trafic réseau entre plusieurs régions. Utilisez Azure Traffic Manager pour diriger les clients vers l’instance de service Azure Spring Apps la plus proche. Pour des performances et une redondance optimales, dirigez tout le trafic d’application via Azure Traffic Manager avant de l’envoyer à votre instance de service Azure Spring Apps. Pour plus d’informations, consultez Qu’est-ce que Traffic Manager ?

Si certaines de vos applications dans Azure Spring Apps s’exécutent dans plusieurs régions, Azure Traffic Manager peut contrôler le flux du trafic vers vos applications dans chaque région. Définissez un point de terminaison Azure Traffic Manager pour chaque instance de service à l’aide de l’adresse IP de l’instance. Connectez-vous à un nom DNS Azure Traffic Manager qui pointe vers l’instance de service Azure Spring Apps. Azure Traffic Manager équilibre la charge du trafic sur les points de terminaison définis. Si un incident survient dans un centre de données, Azure Traffic Manager dirige le trafic de cette région vers sa paire, garantissant ainsi la continuité du service.

Afin de créer une instance Azure Traffic Manager pour les instances Azure Spring Apps, procédez comme suit :

  1. Créez des instances de service Azure Spring Apps dans deux régions différentes, par exemple USA Est et Europe Ouest (cf. tableau suivant). Chaque instance sert de point de terminaison principal et de point de terminaison de basculement pour le trafic.

    Nom du service Emplacement Application
    service-sample-a USA Est passerelle / service d’authentification / service de compte
    service-sample-b Europe Ouest passerelle / service d’authentification / service de compte

  2. Configurez un domaine personnalisé pour les instances de service. Pour plus d’informations, consultez Tutoriel : Mappage d’un domaine personnalisé existant à Azure Spring Apps. Une fois la configuration réussie, les deux instances de service sont liées au même domaine personnalisé, par exemple bcdr-test.contoso.com.

  3. Créez un gestionnaire de trafic et deux points de terminaison. Pour obtenir des instructions, consultez la section Démarrage rapide : Création d’un profil Traffic Manager à l’aide du Portail Azure, qui produit le profil Traffic Manager suivant :

    • Nom DNS du gestionnaire de trafic : http://asa-bcdr.trafficmanager.net
    • Profils de point de terminaison :
    Profil Type Cible Priority Paramètres d’en-têtes personnalisés
    Profil A de point de terminaison Point de terminaison externe service-sample-a.azuremicroservices.io 1 host: bcdr-test.contoso.com
    Profil B de point de terminaison Point de terminaison externe service-sample-b.azuremicroservices.io 2 host: bcdr-test.contoso.com

  4. Créez un enregistrement CNAME dans une zone DNS similaire à l’exemple suivant : bcdr-test.contoso.com CNAME asa-bcdr.trafficmanager.net.

L’environnement est maintenant configuré. Si vous avez utilisé les exemples de valeurs des articles liés, vous devriez pouvoir accéder à l’application à l’adresse https://bcdr-test.contoso.com.

Utiliser Azure Front Door et Azure Application Gateway pour acheminer le trafic

Azure Front Door est un point d’entrée mondial scalable qui utilise le réseau de périphérie mondial de Microsoft pour créer des applications web rapides, sécurisées et très scalables. Azure Front Door fournit la même redondance multi-géographique et le même routage vers la région la plus proche qu’Azure Traffic Manager. Azure Front Door fournit également des fonctionnalités avancées telles que l’arrêt du protocole TLS, le traitement de la couche Application et le Web Application Firewall (WAF). Pour plus d’informations, consultez la page Présentation d’Azure Front Door

Le diagramme suivant montre l’architecture d’une instance de service Azure Spring Apps intégrée à un réseau virtuel, à redondance multi-région. Le diagramme montre la configuration correcte du proxy inverse pour Application Gateway et Front Door avec un domaine personnalisé. Cette architecture est basée sur le scénario décrit dans Exposer des applications avec TLS de bout en bout dans un réseau virtuel. Cette approche combine deux instances d’injection de réseau virtuel Azure Spring Apps intégrées à Application Gateway dans une instance géo-redondante.

Diagramme montrant l’architecture d’une instance de service Azure Spring Apps multirégion.

Étapes suivantes