Principes essentiels d’Azure DNS et de l’équilibreur de charge

Le DNS (Domain Name System) traduit les noms de domaine lisibles par les utilisateurs (comme api.mycompany.com) en adresses IP que les ordinateurs utilisent pour communiquer. Azure fournit deux services DNS : Azure DNS pour héberger des zones DNS publiques (domaines accessibles depuis Internet) et Azure Private DNS pour la résolution de noms interne au sein des réseaux virtuels. Sans configuration DNS appropriée, les ressources Azure doivent être référencées par leurs adresses IP, ce qui rend les architectures fragiles : toute modification d’adresse IP interrompt toutes les configurations dépendantes. Azure DNS est un service hautement disponible et distribué à l’échelle mondiale, soutenu par le réseau anycast de Microsoft.

Les zones publiques Azure DNS hébergent les enregistrements DNS de domaines accessibles depuis Internet. Vous déléguez votre domaine (enregistré auprès d’un bureau d’enregistrement tel que GoDaddy) à Azure DNS en mettant à jour ses enregistrements NS afin qu’ils pointent vers les serveurs de noms Azure. Une fois la délégation effectuée, vous gérez tous les enregistrements DNS (A, CNAME, MX, TXT, etc.) depuis le portail Azure ou la CLI, au lieu d’utiliser un fournisseur DNS distinct. Les zones publiques Azure DNS offrent une disponibilité garantie par un SLA de 100 %, une propagation mondiale en moins d’une seconde et un accès contrôlé par RBAC, afin que seuls les membres autorisés de l’équipe puissent modifier les enregistrements DNS.

Les zones Azure Private DNS assurent la résolution de noms pour les ressources des réseaux virtuels sans exposer publiquement les enregistrements DNS. Par exemple, vous pouvez créer une zone privée myapp.internal et y enregistrer vos VM afin qu’elles soient résolues par leur nom (db.myapp.internal) plutôt que par leur adresse IP. Les zones Private DNS sont liées aux réseaux virtuels : seules les ressources des réseaux virtuels liés peuvent résoudre les enregistrements privés. Vous pouvez également activer l’enregistrement automatique, qui crée automatiquement les enregistrements DNS des VM lorsqu’elles rejoignent le réseau virtuel, ce qui maintient la synchronisation du DNS sans gestion manuelle.

Les Private Endpoints (pour des services tels qu’Azure SQL, Blob Storage et Key Vault) nécessitent que le DNS résolve le nom d’hôte public du service vers l’adresse IP privée plutôt que vers l’adresse IP publique. Azure fournit des zones DNS privées pour chaque service (par exemple, privatelink.blob.core.windows.net pour Blob Storage). Lorsque vous créez un Private Endpoint, Azure crée dans cette zone un enregistrement DNS A pointant vers l’adresse IP privée. Liez cette zone à votre réseau virtuel : toutes les recherches DNS de l’URL du compte Storage sont alors automatiquement résolues vers l’adresse IP privée, ce qui achemine le trafic via le réseau dorsal privé sans aucune modification du code de l’application.

Azure Load Balancer distribue le trafic réseau entrant entre plusieurs ressources principales (VM ou instances d’un groupe identique) afin qu’aucune ressource ne soit surchargée. Il fonctionne au niveau 4 (couche transport) du modèle OSI : il achemine les paquets TCP et UDP en fonction des adresses IP et des ports source et de destination, sans inspecter le contenu HTTP. Azure Load Balancer est un service hautement disponible, redondant par zone, avec un SLA de 99,99 % (SKU Standard), qui prend en charge l’équilibrage de charge entrant (depuis Internet ou un réseau virtuel) ainsi que le SNAT sortant pour l’accès des VM à Internet.

Azure Load Balancer possède quatre composants principaux : configuration IP frontale — l’adresse IP publique ou privée à laquelle les clients se connectent. pool principal — l’ensemble des VM ou des instances du groupe identique qui reçoivent le trafic. règles d’équilibrage de charge — associent une adresse IP et un port frontaux à un port principal et indiquent l’algorithme de distribution de la charge (hachage à 5 tuples par défaut). sondes d’intégrité — testent périodiquement chaque instance principale ; les instances qui échouent aux contrôles d’intégrité ne reçoivent plus de nouvelles connexions jusqu’à leur rétablissement. Ensemble, ces composants définissent la manière dont le trafic est reçu, contrôlé et distribué.

Les sondes d’intégrité sont des contrôles périodiques envoyés par l’équilibreur de charge à chaque instance principale afin de déterminer si elle est saine et doit recevoir du trafic. Vous configurez le protocole de la sonde (HTTP, HTTPS ou TCP), le port et l’intervalle. Pour les sondes HTTP/HTTPS, l’équilibreur de charge envoie une requête GET vers un chemin d’URL indiqué : l’instance est considérée comme saine si elle renvoie HTTP 200. Pour les sondes TCP, une connexion TCP établie avec succès indique que l’instance est saine. Si une instance principale échoue à un nombre configurable de sondes consécutives, l’équilibreur de charge cesse de lui envoyer de nouvelles connexions jusqu’à ce qu’elle réussisse à nouveau les sondes. Cela fournit une tolérance automatique aux pannes sans intervention manuelle.

Azure Load Balancer existe en deux SKU : Basic — gratuit, prend en charge jusqu’à 300 instances principales, sans SLA, sans prise en charge des zones de disponibilité et sans obligation de NSG sécurisé par défaut. Standard — payant (environ 20 $/mois de base), prend en charge jusqu’à 1 000 instances principales, avec un SLA de 99,99 %, une interface frontale redondante par zone, une sécurité par défaut (des règles NSG explicites sont nécessaires pour autoriser le trafic) et la prise en charge de plusieurs adresses IP frontales. Pour toute charge de travail de production, le SKU Standard est vivement recommandé. Microsoft retire progressivement le SKU Basic : les nouveaux déploiements doivent toujours utiliser Standard.

Azure Load Balancer peut être déployé selon deux configurations : Load Balancer public (externe) — possède une adresse IP publique sur l’interface frontale et distribue le trafic Internet entre les VM principales. Il est utilisé pour les applications accessibles depuis Internet, telles que les serveurs web et les passerelles API. Load Balancer interne (privé) — possède une adresse IP privée sur l’interface frontale au sein d’un réseau virtuel et distribue le trafic entre les ressources du réseau virtuel. Il est utilisé pour les applications multiniveaux lorsque l’équilibreur de charge de la couche applicative ne doit pas être accessible depuis Internet, mais uniquement depuis la couche web du même réseau virtuel. Vous pouvez déployer les deux simultanément : un LB public pour la couche web et un LB interne pour la couche applicative.

Azure propose deux services principaux d’équilibrage de charge pour des scénarios différents : Azure Load Balancer — couche 4, TCP/UDP, latence extrêmement faible, et gestion de millions de connexions par seconde. Idéal pour les charges de travail autres que HTTP ou lorsque le débit maximal et une latence minimale sont prioritaires. Azure Application Gateway — couche 7, HTTP/HTTPS, compréhension des chemins d’URL et des en-têtes, avec notamment un pare-feu d’applications web (WAF), la terminaison SSL, l’affinité de session basée sur les cookies et le routage basé sur l’URL. Idéal pour les applications web qui nécessitent un équilibrage de charge tenant compte du contenu, un déchargement TLS et la protection d’un WAF. Pour un équilibrage de charge TCP simple, utilisez Load Balancer. Pour les applications web, Application Gateway apporte une réelle valeur ajoutée.

DNS et Load Balancer fonctionnent ensemble pour créer des points de terminaison résilients et conviviaux. Schéma courant : 1) créez un Azure Load Balancer avec une adresse IP publique Standard et un pool principal de VM de serveurs web. 2) créez un enregistrement CNAME DNS dans Azure DNS qui pointe www.mycompany.com vers l’adresse IP publique (ou le nom DNS) de Load Balancer. 3) lorsque les utilisateurs consultent www.mycompany.com, DNS résout le nom vers l’adresse IP de Load Balancer, qui distribue ensuite les requêtes entre les instances de VM opérationnelles. Vous bénéficiez ainsi à la fois d’une URL conviviale et d’une distribution automatique du trafic avec tolérance aux pannes.

Vérifiez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) abordés dans cette leçon.

Dans cette leçon, vous avez appris que : Azure DNS héberge des zones DNS publiques et privées avec une disponibilité proche de 100 %, ce qui permet d’utiliser des noms lisibles par les humains pour les ressources Azure, que les zones DNS privées avec inscription automatique maintiennent à jour les enregistrements DNS du réseau virtuel sans gestion manuelle, et qu’Azure Load Balancer distribue le trafic TCP/UDP de couche 4 entre les instances de VM principales opérationnelles à l’aide de sondes d’intégrité qui détectent automatiquement les instances défaillantes et les contournent. Nous allons maintenant commencer le cours sur les bases de données Azure, avec Azure SQL Database.