Fiabilité dans Load Balancer

Cet article contient recommandations de fiabilité spécifiques pour Load Balancer, ainsi que des informations détaillées sur la résilience régionale de Load Balancer avec les zones de disponibilité et la récupération d'urgence inter-régions et la continuité d’activité.

Pour obtenir une vue d’ensemble architecturale de la fiabilité dans Azure, consultez Fiabilité Azure.

Recommandations en matière de fiabilité

Cette section contient des recommandations pour atteindre la résilience et la disponibilité. Chaque recommandation appartient à l’une des deux catégories suivantes :

• Les éléments d’intégrité couvrent des domaines tels que les éléments de configuration et le bon fonctionnement des principaux composants de votre charge de travail Azure, tels que les paramètres de configuration des ressources Azure, les dépendances vis-à-vis d’autres services, etc.

• Les éléments de risque couvrent des domaines tels que les exigences de disponibilité et de reprise d’activité, les tests, le monitoring, le déploiement et d’autres éléments qui, s’ils ne sont pas résolus, augmentent les risques de problèmes dans l’environnement.

Matrice de priorité des recommandations de fiabilité

Chaque recommandation est marquée conformément à la matrice de priorité suivante :

Image	Priority	Description
	Élevé	Correctif immédiat nécessaire.
	Moyenne	Corriger dans les 3 à 6 mois.
	Faible	Doit être examiné.

Résumé des recommandations en matière de fiabilité

Category	Priorité	Recommandation
Disponibilité		Vérifier que Standard Load Balancer est redondant interzone
		Vérifier que le pool de back-end contient au moins deux instances
Efficacité du système		Utiliser NAT Gateway au lieu de règles de trafic sortant pour les charges de travail de production
		Utiliser la référence SKU Standard Load Balancer

Disponibilité

Vérifier que Standard Load Balancer est redondant interzone

Dans une région qui prend en charge les zones de disponibilité, Standard Load Balancer doit être déployé avec redondance de zone. Un Load Balancer redondant interzone permet au trafic d’être servi par une adresse IP de front-end unique qui peut survivre à une défaillance de zone. L’adresse IP de front-end peut être utilisée pour atteindre tous les membres du pool dorsal (non impactés), quel que soit la zone. Si une zone de disponibilité échoue, le chemin des données peut survivre tant que les zones restantes de la région restent saines. Pour plus d’informations, consultez Équilibreur de charge redondant interzone.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with with regional or zonal public IP Addresses
resources
| where type == "microsoft.network/loadbalancers"
| where tolower(sku.name) != 'basic'
| mv-expand feIPconfigs = properties.frontendIPConfigurations
| extend
    feConfigName = (feIPconfigs.name),
    PrivateSubnetId = toupper(feIPconfigs.properties.subnet.id),
    PrivateIPZones = feIPconfigs.zones,
    PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
    JoinID = toupper(id)
| where isnotempty(PrivateSubnetId)
| where isnull(PrivateIPZones) or array_length(PrivateIPZones) < 2
| project name, feConfigName, id
| union (resources
    | where type == "microsoft.network/loadbalancers"
    | where tolower(sku.name) != 'basic'
    | mv-expand feIPconfigs = properties.frontendIPConfigurations
    | extend
        feConfigName = (feIPconfigs.name),
        PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
        JoinID = toupper(id)
    | where isnotempty(PIPid)
    | join kind=innerunique (
        resources
        | where type == "microsoft.network/publicipaddresses"
        | where isnull(zones) or array_length(zones) < 2
        | extend
            LBid = toupper(substring(properties.ipConfiguration.id, 0, indexof(properties.ipConfiguration.id, '/frontendIPConfigurations'))),
            InnerID = toupper(id)
    ) on $left.PIPid == $right.InnerID)
| project recommendationId = "lb-4", name, id, tags, param1="Zones: No Zone or Zonal", param2=strcat("Frontend IP Configuration:", " ", feConfigName)

Vérifiez que le pool de back-end contient au moins deux instances

Déployez Load Balancer avec au moins deux instances dans le back-end. Une seule instance pourrait constituer un point de défaillance unique. Pour rendre possible la mise à l’échelle, vous pouvez associer l’équilibreur de charge à Virtual Machine Scale Sets.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers which only have 1 backend pool defined or only 1 VM in the backend pool
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend bep = properties.backendAddressPools
| extend BackEndPools = array_length(bep)
| where BackEndPools == 0
| project recommendationId = "lb-2", name, id, Param1=BackEndPools, Param2=0, tags
| union (resources
        | where type =~ 'Microsoft.Network/loadBalancers'
        | extend bep = properties.backendAddressPools
        | extend BackEndPools = array_length(bep)
        | mv-expand bip = properties.backendAddressPools
        | extend BackendAddresses = array_length(bip.properties.loadBalancerBackendAddresses)
        | where BackendAddresses <= 1
        | project recommendationId = "lb-2", name, id, tags, Param1=BackEndPools, Param2=BackendAddresses)

Efficacité du système

Utiliser la NAT Gateway au lieu de règles de trafic sortant pour les charges de travail de production

Les règles de trafic sortant allouent des quantités fixes de ports SNAT à chaque instance de machine virtuelle dans un pool de back-end. Cette méthode d’allocation peut conduire à l’épuisement du port SNAT, notamment si des modèles de trafic irrégulier font qu’une machine virtuelle spécifique envoie un volume plus important de connexions sortantes. Pour les charges de travail de production, il est recommandé de coupler Standard Load Balancer ou tout déploiement de sous-réseau avec Azure NAT Gateway. NAT Gateway alloue de manière dynamique des ports SNAT sur toutes les instances de machine virtuelle dans un sous-réseau et réduit à son tour le risque d’épuisement des ports SNAT.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with Outbound rules configured
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend outboundRules = array_length(properties.outboundRules)
| where outboundRules > 0
| project recommendationId = "lb-3", name, id, tags, Param1 = "outboundRules: >=1"

Utiliser la référence SKU Standard Load Balancer

La référence SKU Standard Load Balancer prend en charge les zones de disponibilité et la résilience des zones, tandis que la référence SKU de base ne le fait pas. Lorsqu’une zone tombe en panne, votre Standard Load Balancer redondant interzone ne sera pas impacté et vos déploiements peuvent résister aux défaillances de zone au sein d’une région. De plus, Standard Load Balancer prend en charge l’équilibrage de charge inter-régions pour vous assurer que votre application n’est pas affectée par les défaillances de région.

Remarque

Les équilibreurs de charge de base n’ont pas de contrat de niveau de service (SLA).

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers using Basic SKU
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| where sku.name == 'Basic'
| project recommendationId = "lb-1", name, id, tags, Param1=strcat("sku-tier: basic")

Prise en charge des zones de disponibilité

Les zones de disponibilité Azure sont au moins trois groupes physiquement distincts de centres de données dans chaque région Azure. Les centres de données de chaque zone sont équipés d’une infrastructure réseau, de refroidissement et d’alimentation indépendante. En cas de défaillance de zone locale, les zones de disponibilité sont conçues de telle sorte que si une zone est affectée, les services, la capacité et la haute disponibilité de la région sont pris en charge par les deux autres zones.

Les défaillances sont aussi bien des défaillances logicielles et matérielles que des événements de type tremblements de terre, inondations et incendies. La tolérance aux défaillances est obtenue par la redondance et l’isolation logique des services Azure. Pour obtenir des informations détaillées sur les zones de disponibilité dans Azure, consultez Régions et zones de disponibilité.

Les services Azure compatibles avec les zones de disponibilité sont conçus pour fournir le niveau approprié de fiabilité et de flexibilité. Ils peuvent être configurés de deux façons. Un service peut être redondant interzone, avec une réplication automatique entre les zones, ou zonal, avec des instances épinglées à une zone spécifique. Vous pouvez également combiner ces approches. Pour plus d’informations sur l’architecture zonale et redondante interzone, consultez Recommandations relatives à l’utilisation de zones de disponibilité et de régions.

Azure Load Balancer prend en charge les scénarios des zones de disponibilité. Vous pouvez utiliser l’équilibreur de charge standard pour améliorer la disponibilité dans votre scénario en alignant les ressources et en les distribuant sur les zones. Consultez ce document pour comprendre ces concepts et obtenir des conseils de conception de scénarios.

Bien qu’il soit recommandé de déployer Load Balancer avec redondance interzone, un Load Balancer peut être redondant interzone, zonal ou non zonal. La sélection de la zone de disponibilité de l’équilibreur de charge est synonyme de la sélection de son adresse IP frontale. Pour les équilibreurs de charge publics, si l’adresse IP publique dans le serveur frontal de l’équilibreur de charge est redondante interzone, l’équilibreur de charge est également redondant interzone. Si l’adresse IP publique dans le frontal de l’équilibreur de charge est zonale, l’équilibreur de charge est également désigné dans la même zone. Pour configurer les propriétés liées aux zones pour votre équilibreur de charge, sélectionnez le type approprié de serveur frontal requis.

Remarque

Il n’est pas nécessaire d’avoir un équilibreur de charge pour chaque zone. Un équilibreur de charge unique avec plusieurs serveurs frontaux (en mode zonal ou redondant interzone) associés à leurs pools principaux respectifs sera suffisant.

Prérequis

• Pour utiliser des zones de disponibilité avec Load Balancer, vous devez créer votre équilibreur de charge dans une région qui prend en charge les zones de disponibilité. Pour voir quelles régions prennent en charge les zones de disponibilité, consultez la liste des régions prises en charge.

• Utilisez la référence SKU Standard pour l’équilibreur de charge et l’adresse IP publique pour la prise en charge des zones de disponibilité.

• Le type de référence SKU de base n’est pas pris en charge.

• Pour créer votre ressource, vous devez avoir un rôle de Contributeur réseau ou supérieur.

Limites

• Après la création, les zones de la ressource ne peuvent pas être modifiées, mises à jour ou créées.
• Les ressources ne peuvent pas être converties de zonales à redondantes interzones, ou inversement, après la création.

Équilibreur de charge redondant dans une zone

Dans une région avec Zones de disponibilité, un Standard Load Balancer peut être redondant interzone avec le trafic desservi par une seule adresse IP. Une adresse IP frontend unique survit à une défaillance de zone. L’adresse IP frontend peut être utilisée pour atteindre tous les membres du pool principal (non affectés), quelle que soit la zone. Jusqu’à une zone de disponibilité peut échouer et le chemin des données survit tant que les zones restantes de la région restent saines.

L’adresse IP frontend est servie simultanément par plusieurs déploiements d’infrastructure indépendants dans plusieurs zones de disponibilité. Toute nouvelle tentative ou tout rétablissement réussissent dans les autres zones non affectée par les défaillances de zone.

Remarque

Les machines virtuelles 1, 2 et 3 peuvent appartenir au même sous-réseau et ne doivent pas nécessairement se trouver dans des zones distinctes comme suggestions de diagramme.

En temps normal, les membres du pool principal d’un équilibreur de charge sont associés à une zone unique, par exemple, des machines virtuelles de zone. Une conception courante pour les charges de travail de production consiste à avoir plusieurs ressources zonales. Par exemple, le placement de machines virtuelles des zones 1, 2 et 3 dans le back-end d’un équilibreur de charge avec un front-end redondant interzone respecte ce principe de conception.

Équilibreur de charge zonal

Vous pouvez choisir de garantir un frontend dans une seule zone, ce qui donne un zonal. Dans ce scénario, une unique zone dans une région dessert tous les flux entrants ou sortants. Votre frontend connaît le même sort que l’intégrité de la zone. Le chemin de données n’est pas affecté par les défaillances des zones autres que celles dans lesquelles il a été garanti. Vous pouvez utiliser des frontends zonaux pour exposer une adresse IP par zone de disponibilité.

En outre, vous pouvez utiliser des frontends zonaux directement pour les points de terminaison à charge équilibrée dans chaque zone. Vous pouvez également utiliser cette configuration pour exposer des points de terminaison à charge équilibrée par zone afin de surveiller individuellement chaque zone. Pour les points de terminaison publics, vous pouvez les intégrer à un produit d’équilibrage de charge DNS comme Traffic Manager et utiliser un nom DNS unique.

Pour un frontend d’équilibreur de charge public, vous ajoutez un paramètre zones à l’adresse IP publique. Cette adresse IP publique est référencée par la configuration d’adresse IP frontend utilisée par la règle correspondante.

Pour un équilibreur de charge frontend interne, ajoutez un paramètre zones à la configuration IP de l’équilibreur de charge frontend interne. Un frontend zonal garantit une adresse IP dans un sous-réseau d’une zone spécifique.

Équilibreur de charge non zonal

Les équilibreurs de charge peuvent également être créés dans une configuration non zonale à l’aide d’un front-end « sans zone ». Dans ces scénarios, un équilibreur de charge public utilise une adresse IP publique ou un préfixe d’adresse IP publique, tandis qu’un équilibreur de charge interne se sert d’une adresse IP privée. Cette option n’offre pas de garantie de redondance.

Notes

Toutes les adresses IP publiques mises à niveau de la référence SKU de base à la référence standard sont de type « sans zone ». Découvrez comment Mettre à niveau une adresse IP publique dans le Portail Azure.

Améliorations du SLA

Étant donné que les zones de disponibilité sont physiquement distinctes et fournissent une source d’alimentation, un réseau et un refroidissement distincts, les contrats SLA (contrats de niveau de service) peuvent augmenter. Pour plus d’informations, consultez les Contrats de niveau de service pour les services en ligne.

Créer une ressource avec la zone de disponibilité activée

Pour savoir comment équilibrer la charge des machines virtuelles au sein d’une zone ou sur plusieurs zones à l’aide d’un équilibreur de charge, consultez Démarrage rapide : créer un équilibreur de charge public pour équilibrer la charge des machines virtuelles.

Remarque

• Après la création, les zones de la ressource ne peuvent pas être modifiées, mises à jour ou créées.
• Les ressources ne peuvent pas être converties de zonales à redondantes interzones, ou inversement, après la création.

Tolérance de panne

Les machines virtuelles peuvent basculer vers un autre serveur dans un cluster, avec redémarrage du système d’exploitation de la machine virtuelle sur le nouveau serveur. Vous devez vous référer au processus de basculement pour la reprise d’activité après sinistre, la collecte de machines virtuelles dans la planification de la reprise et l’exécution d’exercices de reprise d’activité pour garantir la réussite de votre solution de tolérance de panne.

Pour plus d’informations, consultez les processus de récupération de site.

Expérience en cas de panne de zone

La redondance dans une zone n’implique pas de plan de données ni de plan de contrôle sans réponse. Les flux redondants interzone peuvent utiliser toutes les zones et vos flux utiliser toutes les zones saines dans une région. Dans le cas d’une défaillance de zone, les flux de trafic utilisant les zones saines ne sont pas affectés.

Les flux de trafic qui font appel à une zone au moment de la défaillance de cette dernière peuvent être concernés, mais les applications peuvent récupérer. Le trafic se poursuit dans les zones saines de la région après retransmission, une fois qu’Azure a convergé autour de la défaillance de zone.

Passez en revue les modèles de conception cloud Azure pour améliorer la résilience de votre application aux scénarios de défaillance.

Plusieurs serveurs frontaux

L’utilisation de plusieurs front-ends vous permet d’équilibrer la charge du trafic sur plusieurs ports et/ou adresses IP. Lors de la conception de votre architecture, veillez à prendre en compte la façon dont la redondance de zone interagit avec plusieurs serveurs frontaux. Si votre objectif est que chaque front-end soit toujours résistant aux défaillances, toutes les adresses IP utilisées comme front-ends doivent être redondantes interzone. Si un ensemble de front-ends est destiné à être associé à une seule zone, chaque adresse IP de cet ensemble doit être associée à cette zone spécifique. Un équilibreur de charge n’est pas nécessaire dans chaque zone. Au lieu de cela, chaque front-end zonal ou ensemble de front-ends zonaux peut être associé à des machines virtuelles du pool de back-ends qui font partie de cette zone de disponibilité spécifique.

Techniques de déploiement sécurisées

Passez en revue les modèles de conception cloud Azure pour améliorer la résilience de votre application aux scénarios de défaillance.

Migrer vers une prise en charge des zones de disponibilité

Dans le cas où une région est augmentée pour avoir des zones de disponibilité, les adresses IP existantes resteraient non zonales, par exemple des adresses IP utilisées pour les frontaux de l’équilibreur de charge. Pour vous assurer que votre architecture peut tirer parti des nouvelles zones, il est recommandé de créer une adresse IP front-end. Une fois créé, vous pouvez remplacer le front-end non zonal existant par un nouveau front-end redondant interzone. Pour savoir comment migrer une machine virtuelle vers la prise en charge de la zone de disponibilité, consultez Migrer Load Balancer vers la prise en charge de la zone de disponibilité.

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 responsable 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.

Azure Standard Load Balancer prend en charge l'équilibrage de charge inter-région, ce qui ouvre notamment la voie aux scénarios de haute disponibilité géo-redondants suivants :

• Trafic entrant en provenance de plusieurs régions.
• Basculement global instantané vers le prochain déploiement régional optimal.
• Distribution de la charge des différentes régions vers la région Azure la plus proche avec la très faible latence.
• Possibilité de scale-up/scale-down derrière un point de terminaison unique.
• Adresse IP globale anycast statique
• Conservation de l'adresse IP du client
• Tirer parti de la solution d'équilibrage de charge existante sans aucun besoin d'apprentissage

La configuration IP frontale de votre équilibreur de charge inter-région est statique et publiée dans la plupart des régions Azure.

Remarque

Le port principal de votre règle d’équilibrage de charge sur l’équilibreur de charge inter-région doit correspondre au port front-end de la règle d’équilibrage de charge/règle NAT de trafic entrant sur l’équilibreur de charge standard régional.

Récupération d’urgence dans la zone géographique multi-région

Redondance régionale

Configurez la redondance régionale en liant en toute transparence un équilibreur de charge inter-région à vos équilibreurs de charge régionaux existants.

En cas de défaillance d'une région, le trafic est acheminé vers l'équilibreur de charge régional sain le plus proche.

La sonde d’intégrité de l’équilibreur de charge inter-région collecte les informations relatives à la disponibilité de chaque équilibreur de charge régional toutes les 5 secondes. Si la disponibilité d’un équilibreur de charge régional passe à 0, l’équilibreur de charge inter-région détecte la défaillance. L'équilibreur de charge régional est alors retiré de la rotation.

Latence ultra faible

L'algorithme d'équilibrage de charge de géo-proximité est basé sur l'emplacement géographique de vos utilisateurs et de vos déploiements régionaux.

Le trafic initié par un client atteint la région participante la plus proche et passe par le réseau global principal de Microsoft pour arriver au déploiement régional le plus proche.

Par exemple, vous disposez d'un équilibreur de charge inter-région avec des équilibreurs de charge standard dans les régions Azure suivantes :

• USA Ouest
• Europe Nord

Si un flux est initié depuis Seattle, le trafic entre dans la région USA Ouest. Il s'agit de la région participante la plus proche de Seattle. Le trafic est acheminé vers l'équilibreur de charge de la région la plus proche, à savoir USA Ouest.

L'équilibreur de charge inter-région Azure utilise un algorithme d'équilibrage de charge de géo-proximité pour la décision de routage.

Le mode de distribution de la charge configuré pour les équilibreurs de charge régionaux est utilisé lors de la décision de routage finale si plusieurs équilibreurs de charge régionaux sont utilisés pour la géo-proximité.

Pour plus d’informations, consultez Configuration du mode de distribution pour Azure Load Balancer.

Le trafic de sortie suit la préférence de routage définie sur les équilibreurs de charge régionaux.

Possibilité de scale-up/scale-down derrière un point de terminaison unique

Lorsque vous exposez le point de terminaison global d’un équilibreur de charge inter-région aux clients, vous pouvez ajouter ou supprimer des déploiements régionaux derrière le point de terminaison global sans interruption.

Adresse IP globale anycast statique

L'équilibreur de charge inter-région est fourni avec une adresse IP publique statique, ce qui garantit que l'adresse IP restera la même. Pour en savoir plus sur les adresses IP statiques, cliquez ici.

Conservation de l'adresse IP du client

L'équilibreur de charge inter-région est un équilibreur de charge réseau « Pass-through » de type Couche 4. Ce « Pass-through » conserve l'adresse IP d'origine du paquet. L'adresse IP d'origine est accessible au code exécuté sur la machine virtuelle. Cette conservation vous permet d'appliquer une logique spécifique à une adresse IP.

IP flottante

L’adresse IP flottante peut être configurée à la fois au niveau de l’adresse IP globale et au niveau de l’adresse IP régionale. Pour plus d’informations, consultez Front-ends multiples dans Azure Load Balancer.

Il est important de noter que l’adresse IP flottante configurée sur les Load Balancer inter-régions Azure fonctionne indépendamment des configurations IP flottantes sur les équilibreurs de charge régionaux back-end. Si l’adresse IP flottante est activée sur l’équilibreur de charge inter-régions, l’interface de bouclage appropriée doit être ajoutée aux machines virtuelles back-end.

Sondes d’intégrité

L’équilibreur de charge inter-régions d’Azure utilise l’intégrité des équilibreurs de charge régionaux back-ends pour décider où distribuer le trafic. Des vérifications d’intégrité par l’équilibreur de charge inter-régions sont effectuées automatiquement toutes les 5 secondes, à condition qu'un utilisateur ait configuré des sondes d’intégrité sur son équilibreur de charge régional.

Créer une solution inter-région sur une instance existante d'Azure Load Balancer

Le pool principal de l'équilibreur de charge inter-région contient un ou plusieurs équilibreurs de charge régionaux.

Ajoutez vos déploiements d'équilibreurs de charge existants à un équilibreur de charge inter-région pour bénéficier d'un déploiement inter-région hautement disponible.

La région d’accueil est celle où est déployé l’équilibreur de charge inter-région ou l’adresse IP publique du niveau global. Cette région n’affecte pas la façon dont le trafic est acheminé. Si une région d’hébergement tombe en panne, le flux de trafic n’est pas affecté.

Régions d'accueil

• USA Centre
• Asie Est
• USA Est 2
• Europe Nord
• Asie Sud-Est
• Sud du Royaume-Uni
• Gouvernement américain - Virginie
• Europe Ouest
• USA Ouest

Notes

Vous pouvez uniquement déployer votre équilibreur de charge inter-région ou IP publique dans un niveau Global de l’une des régions d’accueil répertoriées.

Une région participante est celle où l'adresse IP publique globale de l'équilibreur de charge est annoncée.

Le trafic initié par l’utilisateur est acheminé vers la région participante la plus proche via le réseau Microsoft principal.

L'équilibreur de charge inter-région achemine le trafic vers l'équilibreur de charge régional approprié.

Régions participantes

• Australie Est
• Australie Sud-Est
• Inde centrale
• USA Centre
• Asie Est
• USA Est
• USA Est 2
• Japon Est
• Centre-Nord des États-Unis
• Europe Nord
• États-Unis - partie centrale méridionale
• Asie Sud-Est
• Sud du Royaume-Uni
• Centre des États-Unis – US DoD
• Est des États-Unis – US DoD
• Gouvernement des États-Unis – Arizona
• Gouvernement des États-Unis – Texas
• Gouvernement américain - Virginie
• Centre-USA Ouest
• Europe Ouest
• USA Ouest
• USA Ouest 2

Notes

Les équilibreurs de charge régionaux principaux peuvent être déployés dans n’importe quelle région Azure disponible publiquement et ne se limitent pas aux régions participantes.

Limites

• Les configurations IP frontales inter-région sont uniquement publiques. Les serveurs frontaux internes ne sont actuellement pas pris en charge.

• Aucun équilibreur de charge privé ou interne ne peut pas être ajouté au pool principal de l’équilibreur de charge inter-région

• La traduction NAT64 n’est pas prise en charge pour l’instant. Les adresses IP front-end et back-end doivent être du même type (v4 ou v6).

• Le trafic UDP n’est pas pris en charge sur l’équilibreur de charge inter-régions pour iPv6.

• Le trafic UDP sur le port 3 n’est pas pris en charge sur l’équilibreur de charge inter-régions

• Les règles de trafic sortant ne sont pas prises en charge sur un équilibreur de charge inter-région. Pour des connexions sortantes, utilisez des règles de trafic sortant sur l’équilibreur de charge régional ou sur la passerelle NAT.

Tarifs et contrat SLA

Un équilibreur de charge inter-région partage le Contrat de niveau de service de l’équilibreur de charge standard.

Étapes suivantes

• Fiabilité dans Azure
• Voir le tutoriel : Créer un équilibreur de charge interrégional à l’aide du portail Azure pour créer un équilibreur interrégional.
• En savoir plus sur l’équilibreur de charge interrégional.
• En savoir plus sur Azure Load Balancer.