Fiabilité dans Azure Bastion

Azure Bastion est une plateforme entièrement managée en tant que service (PaaS) que vous approvisionnez pour fournir des connexions haute sécurité aux machines virtuelles via une adresse IP privée. Elle fournit une connectivité RDP/SSH fluide à vos machines virtuelles, directement au travers du protocole TLS depuis le portail Azure ou via un SSH natif ou un client RDP déjà installé sur votre ordinateur local. Quand vous vous connectez via Azure Bastion, vos machines virtuelles n’ont pas besoin d’adresse IP publique, d’agent ou de logiciel client spécial.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre Azure Bastion résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région. Il met en évidence certaines informations clés sur le contrat de niveau de service Azure Bastion (SLA).

Important

La prise en charge des zones de disponibilité pour Azure Bastion est actuellement en préversion. Consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale.

Recommandations de déploiement de production pour la fiabilité

Pour les charges de travail de production, nous vous recommandons de :

• Utilisez le SKU de base ou supérieur.
• Activez la redondance de zone si votre hôte bastion se trouve dans une région prise en charge.

Vue d’ensemble de l’architecture de fiabilité

Lorsque vous utilisez Azure Bastion, vous devez déployer un hôte bastion sur un sous-réseau qui répond aux exigences d’Azure Bastion.

Un hôte bastion a un nombre défini d’instances, qui sont également parfois appelées unités d’échelle. Chaque instance représente une seule machine virtuelle dédiée qui gère vos connexions Azure Bastion. La plateforme gère automatiquement la création d’instances, la surveillance de l’intégrité et le remplacement d’instances non saines. Vous ne voyez pas ou gérez les machines virtuelles directement.

La référence SKU de base prend en charge exactement deux instances. Les références SKU Standard et Premium prennent en charge la mise à l’échelle de l’hôte, où vous pouvez configurer le nombre d’instances, avec un minimum de deux instances. Lorsque vous ajoutez d’autres instances, votre hôte bastion peut prendre en charge des connexions clientes simultanées supplémentaires.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des défaillances transitoires.

Si des erreurs temporaires affectent votre machine virtuelle ou hôte bastion, les clients utilisant les protocoles SSH (Secure Sockets Host) et RDP (Remote Desktop Protocol) réessayent généralement automatiquement.

Résilience aux échecs de zone de disponibilité

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

Azure Bastion prend en charge les zones de disponibilité dans les configurations redondantes interzone et zonales :

• Redondant interzone : un hôte bastion redondant interzone garantit la résilience et la fiabilité en répartissant ses instances entre plusieurs zones de disponibilité. Vous sélectionnez les zones de disponibilité que vous souhaitez utiliser pour votre hôte bastion.

  Le diagramme suivant illustre un hôte bastion redondant interzone, avec ses instances réparties entre trois zones :

  

  Si vous spécifiez plus de zones de disponibilité que vous avez d’instances, Azure Bastion répartit les instances dans autant de zones que possible.

• Zonal: Un hôte bastion zonal et toutes ses instances se trouvent dans une seule zone de disponibilité que vous sélectionnez.

  Important

  L’épinglage à une seule zone de disponibilité est recommandé uniquement lorsque la latence interzone est trop élevée pour vos besoins et après avoir vérifié que la latence ne répond pas à vos besoins. Par elle-même, une ressource zonale ne fournit pas de résilience à une panne d'une zone de disponibilité. Pour améliorer la résilience d’une ressource zonale, vous devez déployer explicitement des ressources distinctes dans plusieurs zones de disponibilité et configurer le routage et le basculement du trafic. Pour plus d’informations, consultez ressources zonales et résilience de zone.

Spécifications

• Prise en charge de la région : Les hôtes bastion zonaux et redondants interzone peuvent être déployés dans les régions suivantes :

  Amérique	Europe	Moyen-Orient	Afrique	Asie-Pacifique
  Centre du Canada	Europe Nord	Banque Centrale du Qatar	Afrique du Sud Nord	Australie Est
  Centre des États-Unis	Suède Centre	Israël Central		Centre de la Corée
  USA Est	Sud du Royaume-Uni
  USA Est 2	Europe Ouest
  Ouest des États-Unis 2	Norvège Est
  USA Est 2 (EUAP)	Italie Nord
  Mexique Centre	Espagne Centre

• SKU: Pour configurer des hôtes bastion pour qu’ils soient zonaux ou redondants interzone, vous devez effectuer un déploiement avec les références SKU De base, Standard ou Premium.

• Adresse IP publique : Azure Bastion nécessite une adresse IP publique redondante interzone standard.

Coût

Il n’existe aucun coût supplémentaire pour utiliser la prise en charge des zones de disponibilité pour Azure Bastion. Les frais sont basés sur la référence SKU de votre hôte bastion et le nombre d’instances qu’il utilise. Pour plus d’informations, consultez la tarification d’Azure Bastion.

Configurez la prise en charge des zones de disponibilité

• Déployez un nouvel hôte bastion avec prise en charge de la zone de disponibilité : Lorsque vous déployez un nouvel hôte bastion dans une région qui prend en charge les zones de disponibilité, vous sélectionnez les zones spécifiques sur lesquelles vous souhaitez effectuer le déploiement.

  Pour la redondance de zone, vous devez sélectionner plusieurs zones.

  Lorsque vous sélectionnez les zones de disponibilité à utiliser, vous sélectionnez en fait la zone de disponibilité logique. Si vous déployez d’autres composants de charge de travail dans un autre abonnement Azure, ils peuvent utiliser un autre numéro de zone de disponibilité logique pour accéder à la même zone de disponibilité physique. Pour plus d’informations, consultez Zones de disponibilité physiques et logiques.

• Hôtes bastion existants : Il n’est pas possible de modifier la configuration de la zone de disponibilité d’un hôte bastion existant. Au lieu de cela, vous devez créer un hôte bastion avec la nouvelle configuration et supprimer l’ancien.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsque les hôtes bastion sont configurés pour la prise en charge des zones de disponibilité et que toutes les zones de disponibilité sont opérationnelles.

• Routage du trafic entre les zones : Lorsque vous lancez une session SSH ou RDP, elle peut être routée vers une instance Azure Bastion dans l’une des zones de disponibilité que vous avez sélectionnées.

  Si vous configurez la redondance de zone sur votre hôte bastion, une session peut être envoyée à une instance bastion dans une zone de disponibilité différente de la machine virtuelle à laquelle vous vous connectez. Dans le diagramme suivant, une requête de l’utilisateur est envoyée à une instance Azure Bastion dans la zone 2, bien que la machine virtuelle se trouve dans la zone 1 :

  

  Conseil / Astuce

  Dans la plupart des scénarios, la quantité de latence interzone n’est pas significative. Toutefois, si vous avez des exigences de latence inhabituellement strictes pour vos charges de travail, vous devez déployer un hôte bastion à zone unique dédié dans la zone de disponibilité de la machine virtuelle. N’oubliez pas que cette configuration ne fournit pas de redondance de zone et que nous ne le recommandons pas pour la plupart des clients.

• Réplication des données entre les zones : Étant donné qu’Azure Bastion ne stocke pas l’état, il n’existe aucune donnée à répliquer entre les zones.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsque les hôtes bastion sont configurés pour la prise en charge de la zone de disponibilité et qu’il existe une panne de zone de disponibilité.

• Détection et réponse : quand vous utilisez la redondance de zone, Azure Bastion détecte les défaillances dans une zone de disponibilité et y répond. Vous n’avez rien à faire pour lancer un basculement de zone de disponibilité.

  Pour les instances redondantes interzone, Azure Bastion tente de remplacer les instances perdues en raison d’une panne de zone. Toutefois, il n’est pas garanti que les instances seront remplacées.

• Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle, et vous pouvez configurer des alertes Resource Health pour vous avertir des problèmes. Vous pouvez également utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

• Requêtes actives : lorsqu’une zone de disponibilité n’est pas disponible, toutes les connexions RDP ou SSH en cours qui utilisent une instance Azure Bastion dans la zone de disponibilité défectueuse sont arrêtées et doivent être retentées.

  Si la machine virtuelle à laquelle vous vous connectez ne se trouve pas dans la zone de disponibilité affectée, elle continue à s’exécuter. Pour plus d’informations sur l’expérience de défaillance de zone de machine virtuelle, consultez Fiabilité dans les VM - Comportement pendant une panne de zone.

• Temps d’arrêt attendu : Le temps d’arrêt attendu dépend de la configuration de la zone de disponibilité utilisée par votre hôte bastion.

  • Redondant interzone : un petit temps d’arrêt peut se produire pendant que le service récupère les opérations. Ce temps d’arrêt est généralement quelques secondes.

  • Zonal: Votre instance n’est pas disponible tant que la zone de disponibilité n’est pas récupérée.

• Perte de données attendue : Étant donné qu’Azure Bastion ne stocke pas l’état, aucune perte de données n’est attendue lors d’une défaillance de zone.

• Réacheminement du trafic : Lorsque vous utilisez la redondance de zone, de nouvelles connexions utilisent des instances Azure Bastion dans les zones de disponibilité saines. Dans l’ensemble, Azure Bastion reste opérationnel.

Récupération de la zone

Lorsque la zone de disponibilité récupère, Azure Bastion restaure automatiquement les instances dans la zone de disponibilité et redirige le trafic entre vos instances comme normale.

Tester les pannes de zone

La plateforme Azure Bastion gère le routage du trafic, le basculement et la restauration automatique pour les hôtes bastion redondantes interzone. Cette fonctionnalité étant complètement managée, vous n’avez pas besoin de lancer quoi que ce soit, ni de valider les processus de défaillance de zone de disponibilité.

Résilience aux défaillances à l’échelle de la région

Azure Bastion est déployé sur des réseaux virtuels ou des réseaux virtuels appairés, et il est associé à une région Azure. Azure Bastion est un service à région unique. Si la région devient indisponible, votre hôte bastion n’est pas disponible.

Azure Bastion prend en charge l’accès aux machines virtuelles dans des réseaux virtuels appairés globalement, mais si la région qui héberge votre hôte bastion n’est pas disponible, vous ne pourrez pas utiliser votre hôte bastion. Pour une résilience plus élevée, si vous déployez votre solution globale dans plusieurs régions avec des réseaux virtuels distincts dans chaque région, vous devez déployer Azure Bastion dans chaque région.

Si vous avez un site de récupération d’urgence dans une autre région Azure, veillez à déployer Azure Bastion dans le réseau virtuel de cette région.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit remplir pour atteindre cette disponibilité attendue. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.

Contenu connexe

• Fiabilité dans Azure