Latest / M365.FM – Podcast Microsoft 365, Copilot & IA en français / Azure Traffic Manager expliqué : répartition de charge DNS, 6 méthodes de routage et basculement automatique (Doublage IA)

Transcript

Azure Traffic Manager expliqué : répartition de charge DNS, 6 méthodes de routage et basculement automatique (Doublage IA) · M365.FM – Podcast Microsoft 365, Copilot & IA en français

0:00
Speaker 2: Prêt pour 10 jours de Microsoft 365, copilote, l'IA, Azure
0:04
Speaker 2: et les personnes qui façonnent l'avenir du travail. En janvier,
0:08
Speaker 2: la M365-ON est de retour et nous allons plus loin.
0:12
Speaker 2: Rejoignez-nous pour des sessions en direct, des démonstrations concrètes et
0:15
Speaker 2: des connaissances pratiques de MVP et d'experts du secteur du
0:17
Speaker 2: monde entier. Pas de diapositives génériques, pas de mots à
0:20
Speaker 2: la mode sans fin. Nous nous attaquons au vrai défi.
0:24
Speaker 2: Copilote studio, agent d'IA, fabrique, sécurité, gouvernance et automatisation concrète.
0:30
Speaker 2: Que vous soyez un professionnel de l'informatique, un développeur ou
0:32
Speaker 2: un chef d'entreprise, des sessions sont conçues pour vous. Pendant
0:35
Speaker 2: 10 jours complets, vous pouvez explorer de multiples technologies et
0:38
Speaker 2: vous connecter à une communauté mondiale. Regardez en direct et
0:41
Speaker 2: rapportez des informations pratiques à votre organisation. Janvier 2027, 10 jours,
0:48
Speaker 2: une communauté Microsoft. Les inscriptions sont ouvertes dès maintenant. Rendez-vous
0:52
Speaker 2: sur m365con. net et réservez votre place dès aujourd'hui. C'est m365con. net. net
1:00
Speaker 2: Rejoignez-nous dès maintenant sur m365con. net et nous vous retrouverons en
1:03
Speaker 2: direct en janvier. Bienvenue dans un nouvel épisode de Microsoft
1:06
Speaker 2: Knowledge Nuggets. Je suis votre Huck Millcopit, le sujet du jour,
1:10
Speaker 2: Azure Traffic Manager. Imaginez que vous ayez créé une application
1:13
Speaker 2: web que des utilisateurs du monde entier souhaitent utiliser. Les
1:15
Speaker 2: utilisateurs de Tokyo, Londres et São Paulo essayent tous d'accéder
1:18
Speaker 2: à votre application en même temps. Voici le problème. Chacun
1:21
Speaker 2: de ces utilisateurs accède à un serveur dans une région,
1:23
Speaker 2: disons la Virginie. L'utilisateur de Tokyo attend plus de 200
1:26
Speaker 2: millisecondes par requête et l'utilisateur de São Paulo vit une
1:29
Speaker 2: expérience encore pire. Si ce centre de données de Virginie
1:32
Speaker 2: tombe en panne en raison d'une panne de courant, d'une
1:34
Speaker 2: coupure de réseau, d'un événement inattendu, toute votre application est
1:36
Speaker 2: en ligne. Chaque utilisateur, ou qu'il soit, constitue un point
1:39
Speaker 2: de déférience unique et constitue un problème. Si vous pouviez
1:41
Speaker 2: acheminer automatiquement chaque utilisateur vers le serveur le plus proche,
1:43
Speaker 2: le plus rapide et le plus simple. Si un utilisateur
1:45
Speaker 2: de Tokyo était desservi par un centre de données au Japon,
1:48
Speaker 2: un utilisateur de Londres en Irlande et que l'une des
1:50
Speaker 2: régions tombe en panne, le trafic se déplace vers une
1:52
Speaker 2: autre région sans que vous n'ayez rien à faire. C'est
1:54
Speaker 2: exactement ce que fait Azure Traffic Manager. Et le fait
1:56
Speaker 2: au niveau DNS qui signifie que c'est plus simple que
1:58
Speaker 2: vous ne le pensez, A la fin de cet épisode,
2:01
Speaker 2: vous comprendrez ce qu'est réellement Traffic Manager, comment fonctionnent ces
2:04
Speaker 2: 6 méthodes de routage et quand utiliser chacune d'elles. Prenez
2:06
Speaker 2: votre café et plongeons-nous dans le vif du sujet. Pourquoi
2:08
Speaker 2: le routage du trafic mondial à bord? Analysons-le. La plupart
2:12
Speaker 2: des gens entendent parler d'équilibrage de charges et pensent à
2:13
Speaker 2: un serveur unique distribuant le trafic sur quelques machines au
2:15
Speaker 2: sein d'un centre de données. C'est Azure Load Balancer. Et
2:18
Speaker 2: il fonctionne parfaitement pour une seule région. Mais que se
2:20
Speaker 2: passe-t-il lorsque vos utilisateurs sont répartis sur plusieurs continents? Un
2:23
Speaker 2: utilisateur au Japon qui accède à un serveur en Virginie
2:25
Speaker 2: n'obtiendra jamais une réponse rapide. La physique d'Internet ne le
2:29
Speaker 2: permet tout simplement pas. La lumière voyage à une vitesse
2:31
Speaker 2: fixe et chaque saut de réseau ajoute du retard. Vous
2:35
Speaker 2: ne pouvez pas résoudre ce problème avec un meilleur code
2:36
Speaker 2: ou un service plus rapide. C'est le problème, les applications
2:38
Speaker 2: lentes perdent des utilisateurs. Un délai d'une seconde réduit les
2:41
Speaker 2: conversions de 7%. Une panne régionale ne fait pas que
2:44
Speaker 2: ralentir les choses, elle met toute votre application hors ligne.
2:46
Speaker 2: Vos utilisateurs ne peuvent pas vous joindre, vos revenus s'arrêtent
2:49
Speaker 2: et votre réputation en prend un coup. Il y a
2:51
Speaker 2: 20 ans, l'ancienne approche consistait à créer des serveurs dans
2:53
Speaker 2: chaque région et à diriger manuellement les utilisateurs vers le bon.
2:56
Speaker 2: Vous mettiez à jour les enregistrements de DNS, manuellement, tenait
2:59
Speaker 2: des feuilles de calcul indiquant où allaient les utilisateurs et
3:01
Speaker 2: priait pour ne pas faire d'erreur lors d'un basculement. Cette
3:03
Speaker 2: approche est peu pratique et fragile, car elle n'est pas
3:05
Speaker 2: évolutive et se casse sous la pression. La nouvelle approche
3:08
Speaker 2: est un directeur de trafic unique basé sur DNS qui
3:10
Speaker 2: choisit le meilleur point de terminaison par utilisateur et par requête.
3:13
Speaker 2: Elle ne nécessite aucune mise à jour manuelle ni aucune
3:15
Speaker 2: feuille de calcul fragile. Au lieu de cela, elle examine
3:17
Speaker 2: où se trouve l'utilisateur, vérifie quels points de terminaison sont
3:20
Speaker 2: sains et renvoie le meilleur. Imaginez cela comme un système
3:22
Speaker 2: mondial de contrôle du trafic aérien où chaque centre de
3:25
Speaker 2: données est un aéroport et Traffic Manager est la tour
3:27
Speaker 2: de contrôle qui dirige chaque utilisateur vers le serveur disponible
3:29
Speaker 2: le plus proche. C'est là qu'intervient Traffic Manager. Parlons donc
3:32
Speaker 2: de ce que c'est réellement, de ce qu'est Traffic Manager.
3:35
Speaker 2: Voici la définition la plus simple. Traffic Manager est un
3:37
Speaker 2: équilibreur de charges basé sur DNS qui fonctionne à l'échelle mondiale.
3:40
Speaker 2: Imaginez-le comme un comptoir d'accueil intelligent à l'entrée d'un immeuble
3:43
Speaker 2: de bureau mondial. Lorsque vous entrez, le réceptionniste ne gère
3:46
Speaker 2: pas vos appels téléphoniques ni ne traite vos documents. Il
3:49
Speaker 2: vous indique simplement le bon étage. C'est tout ce que
3:50
Speaker 2: fait Traffic Manager? Il oriente les utilisateurs vers le bon serveur.
3:53
Speaker 2: Voici la principale distinction. Traffic Manager ne voit jamais votre
3:57
Speaker 2: trafic réel. Il ne traite pas les requêtes par proxy,
3:59
Speaker 2: n'inspecte pas les paquets et ne met pas en cache
4:01
Speaker 2: le compte. Lorsqu'un utilisateur saisit votre nom de domaine dans
4:03
Speaker 2: son navigateur, une requête DNS est envoyée. Traffic Manager répond
4:07
Speaker 2: à cette requête avec l'adresse IP du meilleur point de terminaison,
4:09
Speaker 2: le plus proche, le plus sain, celui que vous avez
4:11
Speaker 2: configuré comme prioritaire. Ensuite, l'utilisateur se connecte directement à ce
4:15
Speaker 2: point de terminaison et Traffic Manager s'efface complètement. Cela signifie
4:18
Speaker 2: qu'il n'ajoute aucune latence à votre chemin de trafic car
4:20
Speaker 2: il n'est pas au milieu du flux de données et
4:22
Speaker 2: ne peut pas ralentir les choses. Il fonctionne également avec
4:24
Speaker 2: n'importe quel point de terminaison connecté à Internet, les services Azure,
4:27
Speaker 2: les serveurs dans un autre cloud et même votre propre
4:29
Speaker 2: centre de données sur site. Tant que le point de
4:31
Speaker 2: terminaison possède une adresse IP publique ou un nom de domaine,
4:33
Speaker 2: Traffic Manager peut y acheminer le trafic. Et comme il
4:36
Speaker 2: s'agit d'un service mondial, il résiste aux pannes régionales. Si
4:39
Speaker 2: une région Azure entière tombante par un Traffic Manager continue
4:41
Speaker 2: de fonctionner et achemine les utilisateurs vers des points de
4:43
Speaker 2: terminaison sains ailleurs. Alors comment Traffic Manager sait-il quels points
4:46
Speaker 2: de terminaison sont sains? Il les sonde de toutes les
4:48
Speaker 2: 30 secondes par défaut en envoyant une requête HTTP ou
4:51
Speaker 2: HTTPS à un chemin spécifique sur chaque point de terminaison.
4:54
Speaker 2: Si le point de terminaison répond avec un code d'état
4:56
Speaker 2: de niveau 200 dans un délai d'attente, il est sain.
4:59
Speaker 2: S'il ne répond pas plusieurs fois de suite, Traffic Manager
5:01
Speaker 2: le marque comme dégradé et arrête d'y envoyer les utilisateurs.
5:04
Speaker 2: Lorsque le point de terminaison récupère, Traffic Manager le détecte
5:06
Speaker 2: également et le remet en rotation et le rotation. Cette
5:09
Speaker 2: surveillance de l'état de santé permet le basculement automatique. Examinons
5:13
Speaker 2: maintenant les différentes façons dont Traffic Manager décide vers quel
5:15
Speaker 2: point de terminaison envoyer les utilisateurs. C'est là qu'interviennent les
5:18
Speaker 2: méthodes de routage. Routage prioritaire, reprise après sinistre simplifiée. Le
5:23
Speaker 2: routage prioritaire est la méthode la plus simple à comprendre.
5:26
Speaker 2: Vous classez vos points de terminaison de 1 à autant
5:27
Speaker 2: que vous en avez. C'est tout. Tout le trafic passe
5:29
Speaker 2: en priorité 1. Si ce point de terminaison tombe en panne,
5:32
Speaker 2: le trafic passe en priorité 2, puis 3, et ainsi
5:34
Speaker 2: de suite dans la liste. Il s'agit d'une configuration active-passive.
5:36
Speaker 2: Un point de terminaison gère tout, les autres attendent en coulisses.
5:40
Speaker 2: Voici un exemple concret. Supposons que vos serveurs principaux fonctionnent
5:43
Speaker 2: dans l'Est des Etats-Unis et que vous ayez une sauvegarde
5:45
Speaker 2: en Europe de l'Ouest. Vous définissez l'Est des Etats-Unis comme
5:47
Speaker 2: priorité 1, l'Europe de l'Ouest comme priorité 2. Fonctionnement normal,
5:50
Speaker 2: chaque utilisateur se rend dans l'Est des Etats-Unis. Mais lorsque
5:52
Speaker 2: l'Est des Etats-Unis subit une panne, peut-être une panne de courant,
5:54
Speaker 2: peut-être un problème de réseau, Traffic Manager le détecte en
5:56
Speaker 2: quelques secondes. Il arrête d'envoyer de nouveaux utilisateurs vers l'Est
5:59
Speaker 2: des Etats-Unis et commence à les rediriger vers l'Europe de
6:01
Speaker 2: l'Ouest à la place. Votre application reste en ligne, vos
6:03
Speaker 2: utilisateurs ne remarqueront peut-être même pas ce qui s'est passé.
6:05
Speaker 2: Et un détail important ici, les utilisateurs existants conservent leur
6:08
Speaker 2: connexion active. Le routage basé sur DNS n'affecte que les
6:10
Speaker 2: nouvelles recherches DNS. Ainsi, si quelqu'un a déjà chargé votre
6:13
Speaker 2: application et a une session active, cette session continue d'aller
6:15
Speaker 2: au point de terminaison d'origine jusqu'à ce qu'elle se termine,
6:16
Speaker 2: jusqu'à ce qu'elle se termine ou que le cache DNS expire.
6:18
Speaker 2: C'est pourquoi vous devez définir une durée de vie DNS faible.
6:21
Speaker 2: 30 à 60 secondes est la durée idéale. Une durée
6:23
Speaker 2: de vie faible signifie que les résolveurs DNS recherchent les
6:25
Speaker 2: mises à jour plus fréquemment. C'est lorsque Traffic Manager change
6:28
Speaker 2: de point de terminaison où le changement se propage plus rapidement.
6:30
Speaker 2: Une erreur courante est d'oublier de tester le basculement. Vous
6:33
Speaker 2: définissez un routage prioritaire, vous déployez votre région de sauvegarde
6:35
Speaker 2: puis vous partez du principe que cela fonctionne. Mais voilà
6:37
Speaker 2: le problème. votre région de sauvegarde doit gérer la charge complète.
6:41
Speaker 2: Si votre région principale gère 1 million d'utilisateurs par jour
6:43
Speaker 2: et que votre région de sauvegarde n'en gère que 100
6:45
Speaker 2: 000 en fonctionnement normal, cette région de sauvegarde risque de
6:47
Speaker 2: tomber en panne lorsque tout ce trafic lui est soudainement transféré.
6:50
Speaker 2: Testez votre bascule. Simulez une panne et observez ce qui
6:53
Speaker 2: se passe. C'est la seule façon de savoir si ça marche.
6:55
Speaker 2: La priorité consiste à maintenir votre application en vie en
6:57
Speaker 2: cas de panne. Mais qu'en est-il de la rendre rapide
7:00
Speaker 2: pour tout le monde? Routage de performance. La vitesse avant tout.
7:03
Speaker 2: Le routage de performance fonctionne différemment du routage de priorité.
7:06
Speaker 2: Au lieu de dire toujours utiliser ce point de terminaison
7:08
Speaker 2: en premier cœur, il dit envoyer chaque utilisateur vers le
7:09
Speaker 2: point de terminaison qui lui offre la connexion la plus rapide. Ainsi,
7:12
Speaker 2: un utilisateur à Tokyo est redirigé vers un serveur au Japon.
7:14
Speaker 2: Un utilisateur à Londres est redirigé vers la Nantes. Un
7:16
Speaker 2: utilisateur à São Paulo est redirigé vers le Brésil. Chaque
7:19
Speaker 2: utilisateur bénéficie de l'expérience la plus rapide possible où qu'il
7:21
Speaker 2: se trouve. Comment Traffic Manager sait-il quel point de terminaison
7:24
Speaker 2: est le plus rapide? Il utilise ce qu'on appelle une
7:26
Speaker 2: table de latence Internet. Considérez-la comme une carte qu'Azure tient
7:29
Speaker 2: à jour. Elle suit la latence réelle du réseau entre
7:31
Speaker 2: différentes parties du monde et chaque région Azure. Lorsqu'une requête
7:35
Speaker 2: DNS arrive, Traffic Manager vérifie où se trouve le résolveur
7:38
Speaker 2: DNS de l'utilisateur, recherche la table de latence et renvoie
7:41
Speaker 2: le point de terminaison qui offre à cet utilisateur la
7:43
Speaker 2: latence la plus faible. Voici quelque chose qui pourrait vous surprendre.
7:46
Speaker 2: Cela ne dépend pas de la distance physique. Un utilisateur
7:49
Speaker 2: en Inde peut en fait obtenir une latence plus faible
7:51
Speaker 2: vers l'est des Etats-Unis que vers l'Asie du Sud-Est selon
7:53
Speaker 2: la manière dont les câbles sous-marins et les points d'échange
7:54
Speaker 2: Internet acheminent le trafic à ce moment-là. Le tableau de
7:57
Speaker 2: latence capture les conditions réelles du réseau, pas seulement la
7:59
Speaker 2: distance en ligne droite. Ainsi, le point de terminaison, le
8:02
Speaker 2: plus proche, n'est pas toujours celui qui est le plus
8:03
Speaker 2: proche géographiquement. Le routage de performance est parfaitement adapté aux
8:06
Speaker 2: applications mondiales où l'expérience utilisateur dépend de la vitesse. Sites
8:10
Speaker 2: de commerce électronique, streaming vidéo, outils de collaboration en temps réel,
8:13
Speaker 2: tout ce qui implique une réponse lente pour perdre un utilisateur.
8:15
Speaker 2: Mais il y a un hic. Il ne tient pas
8:17
Speaker 2: compte de la charge que chaque point de terminaison gère déjà.
8:19
Speaker 2: Si votre région de l'Est des Etats-Unis fonctionne à 85%
8:22
Speaker 2: de sa capacité et que votre région d'Europe de l'Ouest
8:23
Speaker 2: à 20%, le routage de performance peut toujours envoyer de
8:25
Speaker 2: nouveaux utilisateurs vers l'Est des Etats-Unis car c'est la latence
8:27
Speaker 2: la plus faible. Il ne connaît pas la charge de
8:29
Speaker 2: votre serveur. Par conséquent, vous combinez généralement le routage de
8:32
Speaker 2: performance avec d'autres équilibreurs de charge dans chaque région Azure
8:34
Speaker 2: Load Balancer ou Application Gateway pour gérer la distribution réelle
8:38
Speaker 2: du trafic sur vos serveurs une fois que l'utilisateur arrive
8:40
Speaker 2: dans la bonne région. Le routage de performance optimise la vitesse.
8:44
Speaker 2: Mais que faire si vous devez contrôler le volume de
8:45
Speaker 2: trafic reçu par chaque point de terminaison? Routage pondéré géographique,
8:49
Speaker 2: contrôler conformité. Le routage de performance est donc une question
8:52
Speaker 2: de vitesse. Mais que faire si vous souhaitez contrôler exactement
8:54
Speaker 2: le volume de trafic reçu par chaque point de terminaison?
8:56
Speaker 2: Ou acheminer les utilisateurs en fonction de leur emplacement dans
8:59
Speaker 2: le monde? C'est là qu'interviennent le routage pondéré géographique. Commençons
9:02
Speaker 2: par le routage pondéré. Celui-ci est exactement ce à quoi
9:04
Speaker 2: il ressemble. Vous attribuez un poids à chaque point de terminaison,
9:07
Speaker 2: un nombre compris entre 1 et 1.000. Traffic Manager répartit
9:10
Speaker 2: ensuite le trafic proportionnellement en fonction de ses poids. Ainsi,
9:13
Speaker 2: si vous avez un point de terminaison A avec un
9:15
Speaker 2: poids de 80 et un point de terminaison B avec
9:17
Speaker 2: un poids de 20, environ 80% de vos utilisateurs sont
9:19
Speaker 2: dirigés vers A et 20% vers B. Un calcul simple.
9:22
Speaker 2: Pourquoi voudriez-vous faire cela? Pensez à une version Canary. Vous
9:25
Speaker 2: avez créé une nouvelle version de votre application et vous
9:27
Speaker 2: souhaitez la tester auprès de vrais utilisateurs avant de la
9:29
Speaker 2: déployer pour tout le monde. Vous configurez un deuxième point
9:31
Speaker 2: de terminaison exécutant. La nouvelle version lui attribue une pondération
9:33
Speaker 2: de 5 et attribue à votre point de terminaison de
9:35
Speaker 2: production actuelle une pondération de 95. 15% de 95% de
9:37
Speaker 2: vos utilisateurs utilisent la nouvelle version. Vous surveillez les erreurs,
9:40
Speaker 2: surveillez les performances et si tout semble correct, vous augmentez
9:43
Speaker 2: progressivement la pondération de la nouvelle version. Peut-être de 20%
9:45
Speaker 2: la semaine prochaine, puis de 50, puis de 100. Si
9:47
Speaker 2: quelque chose ne va pas, vous ramenez la pondération à
9:48
Speaker 2: zéro et le problème est maîtrisé. Pas de déploiement brutal,
9:51
Speaker 2: pas de retour en arrière sur une version défectueuse devant
9:53
Speaker 2: tous vos utilisateurs. La même idée s'applique au test A
9:55
Speaker 2: sur B. Vous voulez voir si une nouvelle fonctionnalité améliore l'engagement?
9:58
Speaker 2: Envoyez la moitié de vos utilisateurs vers la version A
10:00
Speaker 2: et l'autre moitié vers la version B en utilisant des pondérations.
10:02
Speaker 2: Comparez les résultats. Ou bien vous migrez des utilisateurs d'une
10:04
Speaker 2: région à une autre. Déplacez progressivement la pondération de l'ancienne
10:07
Speaker 2: région vers la nouvelle sur quelques semaines. Voici cependant un
10:10
Speaker 2: point important à comprendre. Le routage pondéré n'est pas un tourniquet.
10:13
Speaker 2: Il n'alterne pas entre les points de terminaison une requête
10:15
Speaker 2: à la fois. C'est une distribution statistique. Sur un grand
10:18
Speaker 2: nombre de requêtes, le trafic se répartit en fonction de
10:20
Speaker 2: vos pondérations. Cependant, un utilisateur unique effectuant plusieurs requêtes peut
10:24
Speaker 2: continuer à atteindre le même point de terminaison car son
10:25
Speaker 2: résolveur DNS met le résultat en cache. Ne considérez donc
10:28
Speaker 2: pas cela comme un équilibrage de choix. Considérez-le comme un
10:30
Speaker 2: contrôle de la proportion globale du trafic au fil du temps.
10:33
Speaker 2: Parlons maintenant du routage géographique. Celui-ci achemine les utilisateurs en
10:36
Speaker 2: fonction de l'origine de leur requête DNS, pays, continent ou
10:39
Speaker 2: région spécifique. Ainsi, un utilisateur en Allemagne est envoyé vers
10:42
Speaker 2: votre point de terminaison en Francfort. Un utilisateur au Brésil
10:45
Speaker 2: est envoyé vers votre point de terminaison à Sao Paulo.
10:47
Speaker 2: Ce niveau de granularité, pourquoi l'utiliser? La souveraineté des données
10:50
Speaker 2: est un aimant. Les réglementations de l'Union Européenne peuvent exiger
10:53
Speaker 2: que les données des utilisateurs restent en Europe. Le routage
10:55
Speaker 2: géographique vous permet de faire respecter cette règle au niveau
10:56
Speaker 2: du DER. Un utilisateur en France résout votre domaine et
10:59
Speaker 2: le gestionnaire de trafic renvoie l'adresse IP de votre point
11:01
Speaker 2: de terminaison européen. Ces données ne quittent jamais le continent.
11:04
Speaker 2: Il en va de même pour le contenu localisé. Si
11:06
Speaker 2: vous souhaitez que les utilisateurs au Japon voient une version
11:08
Speaker 2: en japonais de votre site, le routage géographique les envoie
11:10
Speaker 2: vers le point de terminaison qui diffuse ce contenu. Il
11:12
Speaker 2: y a une règle essentielle que vous devez connaître. Chaque
11:14
Speaker 2: région géographique doit correspondre exactement à un point de terminaison.
11:17
Speaker 2: Vous ne pouvez pas diviser un seul pays en deux
11:18
Speaker 2: points de terminaison. Donc si vous avez des utilisateurs en
11:21
Speaker 2: Allemagne et que vous voulez que 50% aient à Francfort
11:22
Speaker 2: et 50% à Berlin, vous ne pouvez pas le faire.
11:24
Speaker 2: Avec le routage géographique seul, seul, vous devrez plutôt utiliser
11:27
Speaker 2: un profil imbriqué. Les profils imbriqués sont exactement ce qu'ils
11:30
Speaker 2: semblent être. Vous placez un profil de gestionnaire de trafic
11:32
Speaker 2: dans un autre. Ainsi, au niveau supérieur, vous utilisez le
11:34
Speaker 2: routage géographique pour envoyer les utilisateurs européens vers un profil,
11:37
Speaker 2: les utilisateurs nord-américains vers un autre, et ainsi de suite. Ensuite,
11:39
Speaker 2: à l'intérieur de chacun de ces profils, vous utilisez le
11:41
Speaker 2: routage pondéré pour répartir le trafic entre les points de
11:43
Speaker 2: terminaison de cette région, Le routage géographique en haut pour
11:45
Speaker 2: la conformité, le routage pondéré à l'intérieur pour le contrôle.
11:47
Speaker 2: C'est une combinaison puissante. Deux autres méthodes de routage gèrent
11:50
Speaker 2: des scénarios plus spécifiques. Examinons-les. Le routage multivaleur et le
11:54
Speaker 2: routage de sous-réseau pour un contrôle précis. Le routage multivaleur
11:57
Speaker 2: est une astuce simple mais utile. Au lieu de renvoyer
11:59
Speaker 2: à un seul point de terminaison dans la réponse DNS,
12:01
Speaker 2: le gestionnaire de trafic renvoie plusieurs adresses IP saines en
12:04
Speaker 2: même temps. Votre navigateur ou votre application choisit la première
12:07
Speaker 2: adresse IP de la liste, ce qui répartit la charge
12:09
Speaker 2: sans que le gestionnaire de trafic ait besoin de prendre
12:10
Speaker 2: une décision pour chaque requête. Mais il y a un hic.
12:12
Speaker 2: Les valeurs multiples ne fonctionnent qu'avec les points de terminaison
12:14
Speaker 2: IPv4 et IPv6. Vous ne pouvez donc pas les utiliser
12:17
Speaker 2: avec les services d'application, les services cloud ou tout autre
12:19
Speaker 2: point de terminaison, utilisant un nom de domaine au lieu
12:21
Speaker 2: d'une adresse IP. Elles sont uniquement destinées aux points de terminaison,
12:24
Speaker 2: bien sûr. Cependant, lorsque vous en avez, cela rend le
12:26
Speaker 2: système plus résilient, car si une adresse IP échoue, le
12:28
Speaker 2: client peut en essayer une autre dans la liste sans
12:30
Speaker 2: effectuer une nouvelle recherche DNS. Cela signifie un basculement plus
12:33
Speaker 2: rapide côté client. Le routage de sous-réseau est encore plus spécialisé,
12:36
Speaker 2: mais puissant lorsque vous en avez besoin. Il achemine les
12:37
Speaker 2: utilisateurs en fonction du sous-réseau IP source d'où provient leur
12:40
Speaker 2: requête DNS? Vous pouvez donc mapper la plage d'adresse IP
12:42
Speaker 2: du bureau de votre entreprise à un point de terminaison
12:44
Speaker 2: intermédiaire et tous les autres obtiennent la version de production.
12:47
Speaker 2: Vous pouvez également acheminer les utilisateurs d'un sous-réseau VPN spécifique
12:49
Speaker 2: vers un backend dédié pour les tests. Imaginez un scénario
12:52
Speaker 2: de test interne dans lequel votre équipe de développement travaille
12:55
Speaker 2: depuis le bureau. Leurs requêtes DNS proviennent de votre plage
12:58
Speaker 2: d'adresse IP d'entreprise et vous mappez cette plage à un
13:00
Speaker 2: environnement de test où ils peuvent tester la dernière version.
13:03
Speaker 2: Tous les autres utilisateurs d'Internet obtiennent la version de production.
13:06
Speaker 2: Pas d'URL spéciale, pas de configuration VPN, juste un routage
13:09
Speaker 2: transparent basé sur la provenance de la requête. Ces deux
13:11
Speaker 2: méthodes sont spécialisées. La plupart des gens utiliseront la priorité,
13:14
Speaker 2: les performances, la pondération ou la géographie pour leur gestion
13:16
Speaker 2: principale du trafic. Cependant, les valeurs multiples et le sous-réseau
13:19
Speaker 2: sont là quand vous en avez besoin. Et ils résolvent
13:20
Speaker 2: des problèmes que les autres méthodes ne peuvent pas résoudre.
13:22
Speaker 2: Surveillance de l'état et basculement en pratique. Toutes ces méthodes
13:25
Speaker 2: de routage dépendent d'une chose, savoir quels points de terminaison
13:27
Speaker 2: sont réellement sains. Le routage du trafic vers un serveur
13:30
Speaker 2: défectueux n'aide personne. Parlons donc du fonctionnement pratique, de la
13:33
Speaker 2: surveillance de l'état. Traffic Manager envoie une sonde d'état à
13:36
Speaker 2: chaque point de terminaison toutes les 30 secondes par défaut.
13:38
Speaker 2: et cette sonde est une requête HTTP ou HTTPS vers
13:41
Speaker 2: un chemin spécifique sur votre point de terminaison, il attend
13:43
Speaker 2: une réponse avec un code d'état compris entre 200 et
13:45
Speaker 2: 299 dans un certain délai d'attente. Si le point de
13:49
Speaker 2: terminaison répond correctement et il est sain, si ce n'est
13:51
Speaker 2: pas le cas, Traffic Manager réessaye. Après un nombre configurable d'échecs,
13:55
Speaker 2: 3 par défaut, Traffic Manager marque ce point de terminaison
13:58
Speaker 2: comme dégradé et l'exclut du routage jusqu'à ce qu'il recommence
14:00
Speaker 2: à passer les contrôles d'intégrité. Vous pouvez configurer l'intervalle de
14:02
Speaker 2: vérification et l'île de l'expiration. Des vérifications plus rapides signifient
14:05
Speaker 2: un basculement plus rapide. Si vous définissez l'intervalle sur 10
14:07
Speaker 2: secondes au lieu de 30, Traffic Manager détecte les défaillances
14:09
Speaker 2: plus tôt et redirige le trafic plus rapidement. Cependant, des
14:13
Speaker 2: vérifications plus rapides mettent davantage de charges sur vos points
14:15
Speaker 2: de terminaison car chaque vérification est une requête que votre
14:17
Speaker 2: serveur doit traiter. Ainsi, si vous avez des milliers de
14:19
Speaker 2: points de terminaison et que vous effectuez une vérification toutes
14:21
Speaker 2: les 10 secondes, les requêtes s'additionnent. Vous devez donc trouver
14:23
Speaker 2: un équilibre entre la vitesse et la surcharge. L'impact réel
14:25
Speaker 2: d'une configuration de vérification d'intégrité appropriée est la différence entre
14:28
Speaker 2: un basculement transparent et une fausse alarme qui interrompt votre routage.
14:31
Speaker 2: Si votre vérification est trop sensible, vous risquez de marquer
14:33
Speaker 2: un point de terminaison comme dégradé alors qu'il est en
14:35
Speaker 2: réalité correcte. Un pic temporaire de latence, un bref problème réseau,
14:39
Speaker 2: une requête de base de données lente. Tout cela peut
14:41
Speaker 2: déclencher un faux positif. Lorsque Traffic Manager cesse d'envoyer les
14:45
Speaker 2: utilisateurs vers ce point de terminaison, vous venez de créer
14:47
Speaker 2: une panne qui n'était pas nécessaire. Voici un piège courant.
14:50
Speaker 2: Les utilisateurs définissent le chemin de la sonde à la
14:51
Speaker 2: racine de leur application, juste une barre oblique. C'est bien
14:54
Speaker 2: pour un contrôle de santé de base, mais ce n'est
14:56
Speaker 2: pas l'idéal car la page racine risque de se charger
14:58
Speaker 2: lentement si elle affiche une page complète avec des requêtes
15:00
Speaker 2: de base de données, des images et du javascript. Une
15:03
Speaker 2: meilleure approche consiste à créer un point de terminaison de
15:05
Speaker 2: contrôle de santé dédié, quelque chose de léger. Un point
15:07
Speaker 2: de terminaison simple qui renvoie rapidement un code d'état 200
15:09
Speaker 2: et confirme que l'application est en cours d'exécution. Pas de
15:12
Speaker 2: requête de base de données, pas de traitement lourd, juste
15:13
Speaker 2: un battement de cœur. De cette façon, vos sondes sont rapides,
15:16
Speaker 2: fiables et moins susceptibles de déclencher de fausses alarmes. Permettez-moi
15:19
Speaker 2: de conclure en vous expliquant quand vous devriez réellement utiliser
15:21
Speaker 2: Traffic Manager par rapport à d'autres options. Conclusion et guide
15:24
Speaker 2: de décision. Voici donc un bref récapitulatif. Traffic Manager est
15:28
Speaker 2: un directeur de trafic global basé sur DNS avec 6
15:30
Speaker 2: méthodes de routage. Il ne gère pas réellement votre trafic?
15:33
Speaker 2: Il oriente simplement les utilisateurs vers le bon endroit en
15:35
Speaker 2: fonction de la méthode que vous choisissez. Le routage prioritaire
15:37
Speaker 2: est destiné à la reprise à précision. Il permet à
15:39
Speaker 2: votre application de continuer à fonctionner même si une région
15:41
Speaker 2: entière tombe en bas. Le routage axé sur les performances
15:43
Speaker 2: est une question de vitesse. Il envoie chaque utilisateur au
15:46
Speaker 2: point de terminaison, présentant la latence la plus faible. Le
15:48
Speaker 2: routage pondéré vous permet d'effectuer des déploiements contrôlés, tels que
15:50
Speaker 2: les versions Canary ou les tests Asso2. Le routage géographique
15:54
Speaker 2: gère la conformité. Vous conservez les données dans la bonne
15:56
Speaker 2: région en fonction de l'emplacement de vos utilisateurs. Le routage
15:59
Speaker 2: à valeur multiple permet une distribution simple au niveau de
16:01
Speaker 2: l'adresse IP sur plusieurs adresses. Le routage de sous-réseau effectue
16:04
Speaker 2: des routes en fonction de l'adresse IP source de la
16:05
Speaker 2: requête DNS. Voyons maintenant comment Traffic Manager s'intègre dans une
16:08
Speaker 2: architecture réelle. Pensez-y.