Latest / M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands / Azure Traffic Manager uitgelegd: DNS-loadbalancing, 6 routeringsmethoden en automatische failover (AI-nasynchronisatie)

Transcript

Azure Traffic Manager uitgelegd: DNS-loadbalancing, 6 routeringsmethoden en automatische failover (AI-nasynchronisatie) · M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands

• 0:00
  Speaker 2: Klaar voor 10 dagen vol Microsoft 365, Copilot, AI, Azure
• 0:05
  Speaker 2: en de mensen die de toekomst van werk vormgeven. In
• 0:08
  Speaker 2: januari is M365 komt terug en we pakken het groter aan.
• 0:12
  Speaker 2: Doe mee aan live sessies, praktijkdemonstraties en praktische kennis van
• 0:16
  Speaker 2: MVP's en experts uit de hele wereld. Geen generieke sliedes,
• 0:20
  Speaker 2: geen eindeloze modewoorden. We pakken de echte uitdagingen aan Copilot Studio,
• 0:25
  Speaker 2: AI Agents, Fabric, Beveiliging, Governance en Automatisering. Of je nu
• 0:30
  Speaker 2: een IT-professional, ontwikkelaar of bedrijfsleider bent, er zijn sessies speciaal
• 0:34
  Speaker 2: voor jou. Gedurende tien volle dagen kun je verschillende technologieën
• 0:38
  Speaker 2: verkennen en in contact komen met een wereldwijde community. Kijk
• 0:41
  Speaker 2: live mee en neem praktische inzichten mee terug naar je organisatie.
• 0:44
  Speaker 2: Januari 2027, tien dagen, één Microsoft Community. Registratie is nu geopend.
• 0:51
  Speaker 2: Ga naar m365com.net en verzeker je plek vandaag nog. Dat
• 0:56
  Speaker 2: is m365com.net. Meld je nu aan op m365con.net en we
• 1:03
  Speaker 2: zien je live in januari. Welkom bij een nieuwe aflevering
• 1:06
  Speaker 2: van Microsoft Knowledge Nuggets. Ik ben Milko Peters, uw gastheer.
• 1:09
  Speaker 2: Het onderwerp van vandaag, Azure Traffic Manager. Stel je voor
• 1:12
  Speaker 2: dat je een webapplicatie hebt gebouwd die mensen over de
• 1:14
  Speaker 2: hele wereld willen gebruiken. Gebruikers in Tokio, Londen, Sao Paulo,
• 1:17
  Speaker 2: ze proberen allemaal tegelijkertijd je applicatie te bereiken. Maar hier
• 1:20
  Speaker 2: is het probleem. Al die gebruikers maken verbinding met een
• 1:22
  Speaker 2: server in één regio, laten we zeggen Virginia. De gebruiker
• 1:25
  Speaker 2: in Tokio wacht meer dan 200 milliseconden per aanvraag en
• 1:28
  Speaker 2: de gebruiker in Sao Paulo heeft een nog slechtere ervaring.
• 1:30
  Speaker 2: En als dat datacenter in Virginia uitvalt, een stroomstoring, een netwerkonderbreking,
• 1:34
  Speaker 2: iets onverwachts, dan is je hele applicatie offline. Elke gebruiker,
• 1:37
  Speaker 2: waar dan ook. Dat is een single point of failure
• 1:39
  Speaker 2: en dat is een groot probleem. Wat als je elke
• 1:41
  Speaker 2: gebruiker automatisch naar de dichtstbijzijnde, snelste en meest betrouwbare server
• 1:44
  Speaker 2: zou kunnen routeren? Wat als een gebruiker in Tokio bediend
• 1:46
  Speaker 2: zou worden door een datacenter in Japan? Een gebruiker in
• 1:48
  Speaker 2: Londen door een datacenter in Ierland? En als één regio uitvalt,
• 1:51
  Speaker 2: zou het verkeer dan automatisch ergens anders naartoe worden verplaatst
• 1:53
  Speaker 2: zonder dat je iets hoeft te doen? Dat is precies
• 1:55
  Speaker 2: wat Azure Traffic Manager doet, en wel op DNS-niveau. Dat
• 1:58
  Speaker 2: betekent dat het eenvoudiger is dan je denkt. Aan het
• 2:00
  Speaker 2: einde van deze aflevering begrijp je wat Traffic Manager precies is,
• 2:03
  Speaker 2: hoe de zes routeeringsmethoden werken en wanneer je welke methode
• 2:05
  Speaker 2: moet gebruiken. Pak een kop koffie en laten we beginnen.
• 2:08
  Speaker 2: Waarom wereldwijde verkeersroutering belangrijk is. Laten we het eens nader bekijken.
• 2:12
  Speaker 2: De meeste mensen horen load balancing en denken aan één
• 2:14
  Speaker 2: server die verkeer verdeelt over een paar machines in één datacenter.
• 2:17
  Speaker 2: Dat is Azure Load Balancer en dat werkt prima voor
• 2:19
  Speaker 2: één regio. Maar wat gebeurt er als je gebruikers over
• 2:22
  Speaker 2: continenten verspreid zijn? Een gebruiker in Japan die een server
• 2:24
  Speaker 2: in Virginia probeert te bereiken... krijgt nooit een snelle reactie.
• 2:27
  Speaker 2: De natuurkundige wetten van het internet laten dat gewoon niet toe.
• 2:30
  Speaker 2: Licht reist met een vaste snelheid en elke netwerkhop voegt
• 2:33
  Speaker 2: vertraging toe. Dat kun je niet oplossen met betere code
• 2:36
  Speaker 2: of een snellere service. Het punt is, trage apps verliezen gebruikers.
• 2:40
  Speaker 2: Een vertraging van één seconde zorgt voor een daling van
• 2:42
  Speaker 2: 7% in conversies... en een regionale storing vertraagt niet alleen
• 2:45
  Speaker 2: de boel, maar legt je hele app plat. Je gebruikers
• 2:47
  Speaker 2: kunnen je niet bereiken... Je inkomsten vallen weg en je
• 2:49
  Speaker 2: reputatie loopt schade op. Twintig jaar geleden was de oude
• 2:52
  Speaker 2: aanpak om in elke regio servers te bouwen en gebruikers
• 2:54
  Speaker 2: handmatig naar de juiste server te leiden. Je moest handmatig
• 2:57
  Speaker 2: DNS-records bijwerken, spreadsheets bijhouden van welke gebruikers waar naartoe gingen
• 3:01
  Speaker 2: en hopen dat je geen fout maakte tijdens een failover.
• 3:03
  Speaker 2: Die aanpak is onpraktisch en kwetsbaar omdat hij niet schaalbaar
• 3:06
  Speaker 2: is en onder druk bezwijkt. De nieuwe aanpak is een
• 3:08
  Speaker 2: enkele DNS-gebaseerde verkeersmanager die per gebruiker en per verzoek het
• 3:12
  Speaker 2: beste eindpunt selecteert. Handmatige updates of kwetsbare spreadsheets zijn niet nodig.
• 3:16
  Speaker 2: In plaats daarvan kijkt het systeem naar de locatie van
• 3:18
  Speaker 2: de gebruiker, controleert welke eindpunten operationeel zijn en retourneert het
• 3:21
  Speaker 2: beste eindpunt. Zie het als een wereldwijd luchtverkeersleidingssysteem waarbij elk
• 3:24
  Speaker 2: datacenter een luchthaven is en Traffic Manager de verkeerstoren die
• 3:27
  Speaker 2: elke gebruiker naar de dichtstbijzijnde beschikbare server leidt. Dat is
• 3:30
  Speaker 2: waar Traffic Manager om de hoek komt kijken. Laten we
• 3:32
  Speaker 2: het dus hebben over wat Traffic Manager nu eigenlijk is.
• 3:35
  Speaker 2: Hier is de eenvoudigste definitie. Traffic Manager is een op
• 3:38
  Speaker 2: DNS gebaseerde load balancer die op wereldwijde schaal opereert. Zie
• 3:41
  Speaker 2: het als een slimme receptiebalie bij de ingang van een
• 3:43
  Speaker 2: wereldwijd kantoorgebouw. Wanneer je binnenkomt, neemt de receptioniste je telefoontjes
• 3:46
  Speaker 2: niet aan en verwerkt ze je papierwerk niet. Ze wijzen
• 3:48
  Speaker 2: je gewoon de weg naar de juiste verdieping. Dat is
• 3:50
  Speaker 2: alles wat Traffic Manager doet. Het verwijst gebruikers naar de
• 3:53
  Speaker 2: juiste server. Hier is het belangrijkste verschil. Traffic Manager ziet
• 3:56
  Speaker 2: nooit je daadwerkelijke verkeer. Het proxy het geen verzoeken, inspecteert
• 4:00
  Speaker 2: geen pakketten en caché geen content. Wanneer een gebruiker je
• 4:02
  Speaker 2: domeinnaam in zijn browser typt, wordt er een DNS-query verzonden.
• 4:05
  Speaker 2: Traffic Manager beantwoordt die query met het IP-adres van het
• 4:08
  Speaker 2: beste eindpunt, het dichtstbijzijnde, het gezondste, het eindpunt dat je
• 4:11
  Speaker 2: als prioriteit hebt geconfigureerd. Vervolgens maakt de gebruiker rechtstreeks verbinding
• 4:15
  Speaker 2: met dat eindpunt en treedt Traffic Manager volledig buitenspel. Dat
• 4:18
  Speaker 2: betekent dat het geen vertraging toevoegt aan uw verkeerspad, omdat
• 4:21
  Speaker 2: het zich niet midden in de gegevenstroom bevindt en de
• 4:22
  Speaker 2: boel dus niet kan vertragen. Het werkt ook met elk
• 4:25
  Speaker 2: internetgericht eindpunt, Azure Services, servers in een andere cloud en
• 4:28
  Speaker 2: zelfs uw eigen datacenter op locatie. Zolang het eindpunt een
• 4:31
  Speaker 2: openbaar IP-adres of een domeinnaam heeft, kan Traffic Manager ernaartoe routeren.
• 4:35
  Speaker 2: En omdat het een wereldwijde service is, is het bestand
• 4:37
  Speaker 2: tegen regionale storingen. Als een hele Azure-regio uitvalt, blijft Traffic
• 4:41
  Speaker 2: Manager gewoon draaien en routeert het gebruikers naar werkende eindpunten elders.
• 4:45
  Speaker 2: Maar hoe weet Traffic Manager welke eindpunten gezond zijn? Standaard
• 4:48
  Speaker 2: controleert het ze elke 30 seconden door een HTTP of
• 4:51
  Speaker 2: HTTPS verzoek naar een specifiek pad op elk eindpunt te sturen.
• 4:54
  Speaker 2: Als het eindpunt binnen een bepaalde tijd reageert met een
• 4:56
  Speaker 2: statuscode van niveau 200 is het gezond. Als het meerdere
• 4:59
  Speaker 2: keren achter elkaar niet reageert, markeert Traffic Manager het als
• 5:02
  Speaker 2: verslechterd en stopt het met het doorsturen van gebruikers ernaartoe.
• 5:04
  Speaker 2: Wanneer het eindpunt herstelt, detecteert Traffic Manager dat ook en
• 5:08
  Speaker 2: neemt het het weer in gebruik. Deze gezondheidsmonitoring maakt automatische
• 5:11
  Speaker 2: failover mogelijk. Laten we nu eens kijken naar de verschillende
• 5:14
  Speaker 2: manieren waarop Traffic Manager bepaalt naar welk eindpunt gebruikers worden doorgestuurd.
• 5:17
  Speaker 2: Dat is waar de roeteringsmethoden om de hoek komen kijken. Prioriteitsroetering,
• 5:21
  Speaker 2: noodherstel vereenvoudigd. Prioriteitsroetering is de eenvoudigste methode om te begrijpen.
• 5:25
  Speaker 2: Je rangschikt je eindpunten van 1 tot het aantal dat
• 5:27
  Speaker 2: je hebt. Dat is alles. Al het verkeer gaat naar
• 5:30
  Speaker 2: prioriteit 1. Als dat eindpunt uitvalt, verschuift het verkeer naar
• 5:33
  Speaker 2: prioriteit 2, dan 3, enzovoort. Het is een actieve passieve configuratie.
• 5:37
  Speaker 2: Eén eindpunt handelt alles af, de anderen staan klaar om
• 5:39
  Speaker 2: het over te nemen. Hier is een praktijkvoorbeeld. Stel dat
• 5:42
  Speaker 2: je primaire servers in Oost-Amerika staan en je een backup
• 5:44
  Speaker 2: hebt in West-Europa. Je stelt Oost-Amerika in als prioriteit 1
• 5:47
  Speaker 2: en West-Europa als prioriteit 2. Normaal gesproken gaat elke gebruiker
• 5:51
  Speaker 2: naar Oost-Amerika. Maar wanneer Oost-Amerika uitvalt, bijvoorbeeld door een stroomstoring
• 5:54
  Speaker 2: of een netwerkprobleem, detecteert Traffic Manager dit binnen enkele seconden.
• 5:57
  Speaker 2: Het stopt met het doorsturen van nieuwe gebruikers naar Oost-Amerika
• 6:00
  Speaker 2: en begint ze in plaats daarvan door te sturen naar West-Europa.
• 6:02
  Speaker 2: Je app blijft online en je gebruikers merken er misschien
• 6:04
  Speaker 2: niets van. Er is hier een belangrijk detail. Bestaande gebruikers
• 6:07
  Speaker 2: behouden hun huidige verbinding. DNS-gebaseerde routering is alleen van invloed
• 6:11
  Speaker 2: op nieuwe DNS-zoekopdrachten. Dus als iemand uw app al heeft
• 6:13
  Speaker 2: geladen en een actieve sessie heeft, blijft die sessie verbonden
• 6:15
  Speaker 2: met het oorspronkelijke eindpunt totdat deze eindigt of de DNS-cache verloopt.
• 6:18
  Speaker 2: Daarom is het belangrijk om uw DNS TTL laag in
• 6:20
  Speaker 2: te stellen. 30 tot 60 seconden is ideaal. Een lage
• 6:23
  Speaker 2: TTL betekent dat DNS resolvers vaker controleren op updates. Wanneer
• 6:27
  Speaker 2: Traffic Manager dus van eindpunt wisselt, wordt de wijziging sneller doorgegeven.
• 6:30
  Speaker 2: Een veelgemaakte fout is het vergeten om de failover te testen.
• 6:33
  Speaker 2: U stelt prioriteitsroutering in, u implementeert uw backupregio en gaat
• 6:36
  Speaker 2: er vervolgens vanuit dat het werkt. Maar let op, uw
• 6:38
  Speaker 2: Backup-regio moet de volledige belasting aankunnen. Als uw primaire regio
• 6:42
  Speaker 2: een miljoen gebruikers per dag verwerkt en uw Backup-regio slechts 100.000
• 6:45
  Speaker 2: gebruikers tijdens normale omstandigheden, kan die Backup-regio uitvallen wanneer al
• 6:48
  Speaker 2: dat verkeer er plotseling naartoe verschuift. Test uw failover, simuleer
• 6:52
  Speaker 2: een daadwerkelijke storing en kijk wat er gebeurt. Dat is
• 6:54
  Speaker 2: de enige manier om te weten of het werkt. Prioriteit
• 6:56
  Speaker 2: zorgt ervoor dat uw app blijft functioneren tijdens storingen. Maar
• 6:59
  Speaker 2: hoe zit het met snelheid voor iedereen? Prestatieroutering. Snelheid boven alles.
• 7:03
  Speaker 2: Prestatieroutering werkt anders dan prioriteitsroutering. In plaats van te zeggen,
• 7:07
  Speaker 2: gebruik altijd eerst dit eindpunt, zegt het, stuur elke gebruiker
• 7:10
  Speaker 2: naar het eindpunt dat hen de snelste verbinding biedt. Dus
• 7:12
  Speaker 2: een gebruiker in Tokio wordt doorgestuurd naar een server in Japan.
• 7:14
  Speaker 2: Een gebruiker in Londen wordt doorgestuurd naar Ierland. Een gebruiker
• 7:17
  Speaker 2: in Sao Paulo wordt doorgestuurd naar Brazilië. Elke gebruiker krijgt
• 7:19
  Speaker 2: de snelst mogelijke ervaring, ongeacht waar ze zich bevinden. Hoe
• 7:22
  Speaker 2: weet Traffic Manager welk eindpunt het snelst is? Het gebruikt
• 7:25
  Speaker 2: een zogenaamde internetlatentietabel. Zie het als een kaart die Azure bijhoudt.
• 7:29
  Speaker 2: Deze tabel registreert de werkelijke netwerklatentie tussen verschillende delen van
• 7:33
  Speaker 2: de wereld en elke Azure-regio. Wanneer een DNS-query binnenkomt, controleert
• 7:37
  Speaker 2: Traffic Manager waar de DNS-resolver van de gebruiker zich bevindt,
• 7:40
  Speaker 2: raadpleegt de latentietabel en retorneert het eindpunt dat die gebruiker
• 7:43
  Speaker 2: de laagste latentie biedt. En nu komt iets dat je
• 7:45
  Speaker 2: misschien zal verbazen. Het is niet gebaseerd op fysieke afstand.
• 7:48
  Speaker 2: Een gebruiker in India kan in werkelijkheid een lagere latentie
• 7:51
  Speaker 2: ervaren naar Oost-VS dan naar Zuidoost-Azië, afhankelijk van hoe de
• 7:53
  Speaker 2: onderzeese kabels en internetknoppunten het verkeer op dat moment routeren.
• 7:56
  Speaker 2: De latentietabel geeft de werkelijke netwerkomstandigheden weer, niet alleen de
• 8:00
  Speaker 2: hemelsbrede afstand. Het dichtstbijzijnde eindpunt is dus niet altijd het
• 8:03
  Speaker 2: geografisch dichtstbijzijnde. De prestatiegerichte routering is zeer geschikt voor wereldwijde
• 8:07
  Speaker 2: applicaties waarbij de gebruikerservaring afhangt van snelheid. Denk aan e-commerce websites,
• 8:11
  Speaker 2: video streaming, real-time samenwerkingstools, kortom, alles waarbij een trage reactie
• 8:14
  Speaker 2: een verloren gebruiker betekent. Maar er is een addertje onder
• 8:16
  Speaker 2: het gras. Er wordt geen rekening gehouden met de belasting
• 8:18
  Speaker 2: die elk eindpunt al te verwerken heeft. Als uw regio
• 8:20
  Speaker 2: Oost-VS op 95% capaciteit draait en uw regio West-Europa op 20%,
• 8:24
  Speaker 2: kan prestatiegerichte routering nieuwe gebruikers nog steeds naar Oost-VS sturen
• 8:27
  Speaker 2: omdat dat de laagste latentie voor hen is. Er wordt
• 8:28
  Speaker 2: geen rekening gehouden met de serverbelasting. Daarom combineert uw prestatiegerichte
• 8:32
  Speaker 2: routering doorgaans met andere load balancers binnen elke regio, zoals
• 8:35
  Speaker 2: Azure Load Balancer of Application Gateway, om de daadwerkelijke verkeersverdeling
• 8:38
  Speaker 2: over uw servers te regelen zodra de gebruiker de juiste
• 8:40
  Speaker 2: regio bereikt. Prestatiegerichte routering optimaliseert voor snelheid. Maar wat als
• 8:44
  Speaker 2: u wilt bepalen hoeveel verkeer elk eindpunt krijgt? Gewogen en
• 8:48
  Speaker 2: geografische routering, controle en compliance. Prestatiegerichte routering draait om snelheid.
• 8:53
  Speaker 2: Maar wat als u precies wilt bepalen hoeveel verkeer elk
• 8:55
  Speaker 2: eindpunt krijgt? Of gebruikers wilt routeren op basis van hun
• 8:58
  Speaker 2: locatie in de wereld? Dat is waar gewogen en geografische
• 9:00
  Speaker 2: routering van pas komen. Laten we beginnen met gewogen routering.
• 9:04
  Speaker 2: Dit is precies wat de naam al zegt. U kent
• 9:06
  Speaker 2: een gewicht toe aan elk eindpunt, een getal tussen 1
• 9:08
  Speaker 2: en 1000. Traffic Manager verdeelt het verkeer vervolgens proportioneel op
• 9:12
  Speaker 2: basis van die gewichten. Dus, als u eindpunt A hebt
• 9:14
  Speaker 2: met een gewicht van 80 en eindpunt B met een
• 9:16
  Speaker 2: gewicht van 20, wordt ongeveer 80% van uw gebruikers naar
• 9:20
  Speaker 2: A gestuurd en 20% naar B simpele wiskunde. Waarom zou
• 9:23
  Speaker 2: u dat willen doen? Denk aan een Canary Release. U
• 9:25
  Speaker 2: hebt een nieuwe versie van uw app gebouwd en u
• 9:27
  Speaker 2: wilt deze testen met echte gebruikers voordat u deze voor
• 9:29
  Speaker 2: iedereen beschikbaar stelt. Je configureert een tweede het point met
• 9:32
  Speaker 2: een nieuwe versie, geeft deze een gewicht van 5 en
• 9:34
  Speaker 2: je huidige productie het point een gewicht van 95. 5%
• 9:37
  Speaker 2: van je gebruikers gebruikt de nieuwe versie. Je controleert op fouten,
• 9:40
  Speaker 2: monitort de prestaties en als alles er goed uitziet, verhoog
• 9:42
  Speaker 2: je geleidelijk het gewicht van de nieuwe versie, bijvoorbeeld met
• 9:44
  Speaker 2: 20% volgende week, dan 50%, dan 100%. Als er iets misgaat,
• 9:48
  Speaker 2: zet je het gewicht terug naar nul en is het
• 9:49
  Speaker 2: probleem opgelost. Geen grote implementatie, geen terugdraaien van een defecte
• 9:53
  Speaker 2: release voor al je gebruikers. Hetzelfde principe geldt voor A,
• 9:55
  Speaker 2: B testen. Je wilt zien of een nieuwe functie de
• 9:57
  Speaker 2: betrokkenheid verbetert. Stuur de helft van je gebruikers naar versie
• 10:00
  Speaker 2: A en de andere helft naar versie B met gelijke gewichten.
• 10:02
  Speaker 2: Vergelijk de resultaten. Of, je migreert gebruikers van de ene
• 10:05
  Speaker 2: regio naar de andere. Verschuif het gewicht geleidelijk van de
• 10:07
  Speaker 2: oude regio naar de nieuwe regio over een paar weken.
• 10:10
  Speaker 2: Het is echter belangrijk om te begrijpen dat gewogen routing
• 10:12
  Speaker 2: geen round robin is. Het wisselt niet tussen endpoints één
• 10:15
  Speaker 2: verzoek per keer. Het is een statistische verdeling. Bij een
• 10:18
  Speaker 2: groot aantal verzoeken wordt het verkeer verdeeld op basis van
• 10:20
  Speaker 2: je gewichten. Maar een enkele gebruiker die meerdere verzoeken indient,
• 10:23
  Speaker 2: kan steeds hetzelfde eindpunt bereiken omdat de DNS resolver het
• 10:26
  Speaker 2: resultaat in de cache opslaat. Zie het dus niet als
• 10:28
  Speaker 2: perfecte load balancing, maar als het beheersen van de algehele
• 10:31
  Speaker 2: verhouding van het verkeer over tijd. Laten we het nu
• 10:33
  Speaker 2: hebben over geografische routing. Deze routeert gebruikers op basis van
• 10:37
  Speaker 2: de herkomst van hun DNS query, land, continent of een
• 10:39
  Speaker 2: specifieke regio. Een gebruiker in Duitsland wordt bijvoorbeeld naar je
• 10:42
  Speaker 2: eindpunt in Frankvoort gestuurd. Een gebruiker in Brazilië wordt naar
• 10:45
  Speaker 2: je eindpunt in Sao Paulo gestuurd. Dat is het detailniveau.
• 10:48
  Speaker 2: Waarom zou je dit gebruiken? Data-soevereiniteit is een belangrijke reden.
• 10:51
  Speaker 2: Regelgeving van de Europese Unie kan vereisen dat gebruikersgegevens binnen
• 10:54
  Speaker 2: Europa blijven. Met geografische routing kun je dit op DNS-niveau afdwingen.
• 10:57
  Speaker 2: Een gebruiker uit Frankrijk zoekt je domein op en de
• 10:59
  Speaker 2: verkeersmanager retourneert het IP-adres van je Europese eindpunt. Hun gegevens
• 11:03
  Speaker 2: verlaten het continent nooit. Hetzelfde geldt voor gelokaliseerde content. Als
• 11:06
  Speaker 2: je wilt dat gebruikers in Japan een Japanstalige versie van
• 11:08
  Speaker 2: je website zien, stuurt geografische routing ze naar het eindpunt
• 11:11
  Speaker 2: dat die content aanbiedt. Er is één belangrijke regel die
• 11:13
  Speaker 2: u moet kennen. Elke geografische regio moet aan precies één
• 11:16
  Speaker 2: eindpunt worden gekoppeld. U kunt een enkel land niet over
• 11:18
  Speaker 2: twee eindpunten verdelen. Dus als u gebruikers in Duitsland hebt
• 11:21
  Speaker 2: en u wilt dat 50% naar Frankfurt en 50% naar
• 11:23
  Speaker 2: Berlijn gaat, kunt u dat niet doen met alleen geografische routering.
• 11:26
  Speaker 2: U moet in plaats daarvan een genest profiel gebruiken. Geneste
• 11:29
  Speaker 2: profielen zijn precies wat de naam al zegt. U plaatst
• 11:31
  Speaker 2: het ene Traffic Manager profiel in het andere. Op het
• 11:33
  Speaker 2: hoogste niveau gebruikt u geografische routering om Europese gebruikers naar
• 11:36
  Speaker 2: het ene profiel te sturen, Noord-Amerikaanse gebruikers naar een ander, enzovoort.
• 11:39
  Speaker 2: Vervolgens gebruikt u binnen elk van die profielen gewogen routering
• 11:41
  Speaker 2: om het verkeer te verdelen over de eindpunten binnen die regio.
• 11:44
  Speaker 2: Geografische routering bovenaan voor naleving, gewogen routering daarbinnen voor controle.
• 11:47
  Speaker 2: Het is een krachtige combinatie. Twee andere routeringsmethoden behandelen meer
• 11:50
  Speaker 2: specifieke scenario's. Laten we die eens bekijken. Multivalue routing en
• 11:54
  Speaker 2: subnet routing voor fijnmazige controle. Multivalue routing is een simpele
• 11:58
  Speaker 2: maar nuttige truc. In plaats van slechts één eindpunt in
• 12:00
  Speaker 2: het DNS-antwoord terug te geven, stuurt Traffic Manager meerdere geldige
• 12:04
  Speaker 2: IP-adressen tegelijk terug. Je browser of app kiest de eerste
• 12:06
  Speaker 2: optie uit de lijst, waardoor de belasting wordt verdeeld zonder
• 12:09
  Speaker 2: dat de verkeersmanager voor elk verzoek een beslissing hoeft te nemen.
• 12:11
  Speaker 2: Maar er is een addertje onder het gras. MultiValue werkt
• 12:14
  Speaker 2: alleen met IPv4 en IPv6 eindpunten, dus je kunt het
• 12:17
  Speaker 2: niet gebruiken met App Services, Cloud Services of eindpunten die
• 12:20
  Speaker 2: een domeinnaam in plaats van een IP-adres gebruiken. Het is
• 12:22
  Speaker 2: puur voor IP-gebaseerde eindpunten. Wanneer je die hebt, maakt het
• 12:25
  Speaker 2: het systeem echter veerkrachtiger, want als één IP-adres uitvalt, kan
• 12:28
  Speaker 2: de client een ander IP-adres uit de lijst proberen zonder
• 12:30
  Speaker 2: een nieuwe DNS-lookup uit te voeren. Dat betekent een snellere
• 12:32
  Speaker 2: failover aan de clientzijde. Subnet routing is nog specifieker, maar
• 12:36
  Speaker 2: krachtig wanneer je het nodig hebt. Het routeert gebruikers op
• 12:38
  Speaker 2: basis van het bron-IP-subnet waar hun DNS-query vandaan komt. Je
• 12:41
  Speaker 2: kunt bijvoorbeeld het IP-bereik van je kantoor koppelen aan een staging-eindpunt,
• 12:45
  Speaker 2: terwijl alle anderen de productieversie krijgen. Of je kunt gebruikers
• 12:48
  Speaker 2: van een specifiek VPN-subnet routeren naar een dedicated backend voor testen.
• 12:52
  Speaker 2: Stel je een intern testscenario voor waarbij je ontwikkelteam vanuit
• 12:55
  Speaker 2: kantoor werkt. Hun DNS-queries komen van uw bedrijfs-IP-adresbereik en u
• 12:59
  Speaker 2: koppelt dat bereik aan een testomgeving waar ze de nieuwste
• 13:02
  Speaker 2: versie kunnen testen. Iedereen op internet krijgt de productieversie. Geen
• 13:05
  Speaker 2: speciale URLs, geen VPN-configuraties, gewoon transparante routering op basis van
• 13:10
  Speaker 2: de herkomst van het verzoek. Beide methoden zijn niche. De
• 13:12
  Speaker 2: meeste mensen gebruiken prioriteit, prestaties, Gewogen of geografische routering voor
• 13:16
  Speaker 2: hun belangrijkste verkeersbeheer. Maar Multivalue en Subnet zijn er wanneer
• 13:19
  Speaker 2: u ze nodig hebt en losse problemen op die de
• 13:21
  Speaker 2: andere methoden niet kunnen oplossen. Gezondheidsmonitoring en veel over in
• 13:24
  Speaker 2: de praktijk. Al deze routeringsmethoden zijn afhankelijk van één ding,
• 13:27
  Speaker 2: weten welke eindpunten daadwerkelijk gezond zijn. Verkeer routeren naar een
• 13:30
  Speaker 2: defecte server helpt niemand. Laten we het daarom hebben over
• 13:32
  Speaker 2: hoe gezondheidsmonitoring in de praktijk werkt. Traffic Manager stuurt standaard
• 13:36
  Speaker 2: elke 30 seconden een gezondheidsprobe naar elk eindpunt. Deze probe
• 13:39
  Speaker 2: is een HTTP of HTTPS verzoek naar een specifiek pad
• 13:42
  Speaker 2: op uw eindpunt. Er wordt een reactie verwacht met een
• 13:44
  Speaker 2: statuscode tussen 200 en 299 binnen een bepaalde time-out periode.
• 13:48
  Speaker 2: Als het eindpunt correct reageert, is het gezond. Als dat
• 13:51
  Speaker 2: niet lukt, probeert Traffic Manager het opnieuw. Na een instelbaar
• 13:54
  Speaker 2: aantal fouten, standaard 3, markeert Traffic Manager dat eindpunt als
• 13:57
  Speaker 2: verslechterd en sluit het uit van de routering totdat het
• 14:00
  Speaker 2: de gezondheidscontroles weer doorstaat. U kunt het meetinterval en de
• 14:03
  Speaker 2: time-out configureren. Snellere metingen betekenen een snellere failover. Als u
• 14:06
  Speaker 2: het interval instelt op 10 seconden in plaats van 30,
• 14:09
  Speaker 2: detecteert Traffic Manager fouten eerder en leidt het verkeer sneller om.
• 14:13
  Speaker 2: Snellere metingen belasten uw eindpunten echter meer omdat elke meting
• 14:16
  Speaker 2: een verzoek is dat uw server moet verwerken. Dus als
• 14:18
  Speaker 2: u duizenden eindpunten hebt en u meet elke 10 seconden,
• 14:21
  Speaker 2: lopen de verzoeken snel op. U moet dus een balans
• 14:23
  Speaker 2: vinden tussen snelheid en overhead. De werkelijke impact van een
• 14:25
  Speaker 2: goede configuratie van de gezondheidscontroles is het verschil tussen een
• 14:28
  Speaker 2: naadloze failover en een vals alarm dat uw routering verstoort.
• 14:31
  Speaker 2: Als uw meting te gevoelig is, kunt u een eindpunt
• 14:33
  Speaker 2: als verslechterd markeren terwijl het in werkelijkheid prima functioneert. Een
• 14:36
  Speaker 2: tijdelijke piek in latentie, een korte netwerkstoring, een trage database query,
• 14:40
  Speaker 2: al deze dingen kunnen een vals positief resultaat veroorzaken. Wanneer
• 14:43
  Speaker 2: Traffic Manager stopt met het doorsturen van gebruikers naar dat eindpunt,
• 14:46
  Speaker 2: heb je een storing gecreëerd die niet nodig was. Hier
• 14:48
  Speaker 2: is een veel voorkomende valkuil. Mensen stellen het probepad in
• 14:51
  Speaker 2: op de root van hun applicatie, gewoon een schuine streep.
• 14:54
  Speaker 2: Dat is prima voor een eenvoudige help check, maar niet
• 14:56
  Speaker 2: ideaal omdat de rootpagina traag kan laden als deze een
• 14:59
  Speaker 2: volledige pagina met database queries, afbeeldingen en javascript weergeeft. Een
• 15:03
  Speaker 2: betere aanpak is om een speciaal health check eindpunt te creëren,
• 15:06
  Speaker 2: iets lichtgewichts. Een eenvoudig eindpunt dat snel een 200 statuscode
• 15:09
  Speaker 2: retourneert en bevestigt dat de applicatie draait. Geen database queries,
• 15:12
  Speaker 2: geen zware processen, alleen een heartbeat. Op die manier zijn
• 15:15
  Speaker 2: je probes snel, betrouwbaar en is de kans kleiner dat
• 15:17
  Speaker 2: ze valse alarmen veroorzaken. Laten we tot slot kijken wanneer
• 15:20
  Speaker 2: je Traffic Manager wel moet gebruiken in plaats van andere opties.
• 15:23
  Speaker 2: Conclusie en beslissingsgids. Dus, hier is een korte samenvatting. Traffic
• 15:27
  Speaker 2: Manager is een op DNS gebaseerde globale traffic director met
• 15:30
  Speaker 2: zes routeeringsmethoden. Het beheert je verkeer niet zelf. Het stuurt
• 15:33
  Speaker 2: gebruikers simpelweg naar de juiste plek op basis van de
• 15:35
  Speaker 2: gekozen methode. Prioriteitsroutering is voor noodherstel. Het zorgt ervoor dat
• 15:39
  Speaker 2: uw app blijft werken, zelfs als een hele regio uitvalt.
• 15:42
  Speaker 2: De prestatieroutering draait om snelheid. Het stuurt elke gebruiker naar
• 15:46
  Speaker 2: het eindpunt met de laagste latentie. Gewogen routering maakt gecontroleerde
• 15:49
  Speaker 2: uithol mogelijk, zoals canary releases of A-B testen. Geografische routering
• 15:53
  Speaker 2: zorgt voor naleving van regelgeving. U bewaart gegevens in de
• 15:56
  Speaker 2: juiste regio, afhankelijk van waar uw gebruikers zich bevinden. Multivalue
• 15:59
  Speaker 2: is voor eenvoudige distributie op IP-niveau over meerdere adressen. En
• 16:02
  Speaker 2: subnetroutering routeert op basis van het bron IP-adres van de DNS-query.
• 16:06
  Speaker 2: Laten we het nu hebben over de plaats van Traffic
• 16:08
  Speaker 2: Manager in een echte architectuur. Denk er eens over na.