Ako používať Amazon Route 53?

Pochopte, že trasu 53 je možné prima facie použiť aj na niečo ako vyrovnávanie zaťaženia.

• Ak napríklad chcete vyvážiť prichádzajúcu návštevnosť na troch serveroch, môžete nastaviť záznam trasy 53 A s adresami IP všetkých serverov. Môžete tiež nastaviť viac záznamov Route 53 A s rôznymi hmotnosťami pomocou zásady váženého smerovania (popísané neskôr na tejto stránke).
• Naopak, môžete použiť nástroj na vyrovnávanie zaťaženia na príjem prichádzajúcej návštevnosti a potom použiť tento nástroj na vyrovnanie zaťaženia na presmerovanie prenosu na rôzne servery.

Pochopte, že keďže trasa 53 neobsahuje žiadny centrálny bod toku dopravy, existujú veci, ktoré môže urobiť, čo vyrovnávače zaťaženia nedokážu.

• Pretože premávka v skutočnosti neprechádza žiadnym centrálnym bodom, trasu 53 je možné použiť na prerozdelenie dopravy medzi regióny bez toho, aby sa do latencie pridal čas spiatočnej cesty. Pri nástroji na vyrovnávanie zaťaženia sa čas oneskorenia medzi nástrojom na vyrovnávanie zaťaženia a serverom, ktorý žiadosť nakoniec spracuje, pridá k latencii koncového používateľa. Ak napríklad chceme zaistiť, aby ľudia v Európe boli obsluhovaní servermi v Európe, zatiaľ čo ľudia vo východnej Ázii budú obsluhovaní servermi vo východnej Ázii (s minimálnou latenciou), smerovanie prevádzky cez nástroj na vyrovnávanie zaťaženia porazí účel z dôvodu pridaného kola. -čas cesty. Môžeme však na tento účel použiť záznamy Route 53 bez pridania latencie, pretože záznamy Route 53 sú riešené lokálne bez toho, aby bolo potrebné vypínať centrálny server. Navyše kvôli ukladaniu vyhľadávaní do pamäte cache (až do TTL)aj to miestne rozlíšenie sa musí vykonať iba raz za minútu.
• Route 53 je tiež zodpovedajúco odolnejšia voči prestojom, pretože má veľký počet okrajových umiestnení, ktoré reagujú na požiadavky, a bola navrhnutá na základe princípu neustálej práce, aby sa predišlo kaskádovému zlyhaniu.
• Route 53 na báze trasy má oproti Amazon Elastic Load Balancers (ELB) výhodu v tom, že sa dá veľmi rýchlo škálovať na veľké záťaže, zatiaľ čo ELB nedokážu dostatočne rýchlo zvládnuť veľmi rýchle a veľké zmeny zaťaženia. Všimnite si toho, že ELB je dosť dobrý pre väčšinu prípadov použitia, ale napríklad ťažobná spoločnosť Loggly zistila, že Route 53 slúžila svojmu prípadu použitia lepšie. Všimnite si toho, že Loggly je neobvyklý v porovnaní s väčšinou webových služieb alebo služieb API, ktoré majú stabilnejšie alebo predvídateľnejšie zaťaženie. Jeho referenčnou triedou je „núdzový manažment“, ktorý kombinuje nepredvídateľnosť s veľmi rýchlymi zmenami záťaže v niektorých momentoch.

Pochopte, že keďže trasa 53 neobsahuje žiadny centrálny bod toku dopravy, nemôže vykonávať niektoré z činností, ktoré môže vykonávať nástroj na vyrovnávanie zaťaženia.

• Trasu 53 nemožno použiť na zobrazenie celkovej premávky z vtáčej perspektívy.
• Route 53 nie je dobrá v rovnomernom rozdeľovaní prevádzky medzi servery. Dôvodom je, že hoci to umožňuje stratégiu IP vyhľadávania typu každý s každým, toto je len pre vyhľadávanie IP a _not_ pre skutočné požiadavky. Ak teda distribúcia zdrojov požiadaviek nie je úplne rovnomerná, potom môže byť aj rozdelenie dopravy zodpovedajúce nejednotné. Toto je obzvlášť dôležité, ak ponúkate službu API pre malý počet klientov s vysokým zaťažením na klienta.
• Route 53 nemožno distribuovať prevádzku spravodlivo na spôsob zaťaženie balancer silách. Napríklad Amazon Elastic Load Balancer používa algoritmus minimumconns: odošle požiadavku na server s najmenším počtom nevybavených požiadaviek. To pomáha znižovať dopravné zaťaženie na pomalších alebo viacerých nereagujú serverov. Na Route 53 to nie je možné, pretože cez to ani neprúdi doprava a nevie o dobách odozvy jednotlivých serverov.
• Servery nie je možné pridávať ani odstraňovať z trasy 53 tak rýchlo, ako je to možné s nástrojom na vyrovnávanie zaťaženia. Route 53 tiež nemôže byť integrovaná priamo do automatického škálovania, ktoré AWS ponúka, aj keď je možné písať skripty, ktoré vytvárajú nové servery a pridávajú k nim záznamy pomocou rozhrania Route 53 API na základe aktuálneho zaťaženia premávky, ako to robí protokolovacia spoločnosť Loggly. hotový.

Pri všetkých týchto výhradách je dôležité poznamenať, že cesta 53 a vyvažovanie záťaže sú doplnkami, nie konkurenciou.

• Vyrovnávanie záťaže je najvhodnejšie na rovnomerné rozdelenie návštevnosti a udržanie vysokej dostupnosti v rámci regiónu.
• Route 53 je najvhodnejšia na zaručenie dostupnosti v rôznych oblastiach, minimalizáciu latencie a zvládanie redundancie a záložných služieb medzi regiónmi.

Pochopte, že trasy 53 a siete na doručovanie obsahu (CDN) zdieľajú funkciu, že sú masívne distribuované s okrajovými lokalitami po celom svete.

• Route 53 a služba Amazon CloudFront (služba podobná službe Amazon CDN) v skutočnosti zdieľajú okrajové polohy.

Pochopte, že trasa 53 slúži na adresy IP, zatiaľ čo sieť CDN slúži na obsah.

• Cieľom siete CDN je priamo odpovedať na dotaz na (typicky statický) zdroj pomocou obsluhy tohto zdroja bez toho, aby došlo k zásahu na pôvodný server alebo súborový systém, v ktorom je zdroj uložený. CDN obnovuje zdroj zo zdroja (server alebo súborový systém) buď pravidelne, alebo keď je zdroj explicitne vyčistený.
• Cieľom trasy 53 a ďalších spravovaných služieb DNS je odpovedať iba na vyhľadávacie dotazy DNS a nezobrazovať skutočný obsah.
• CDN môžete použiť na to, aby ste všetkým používateľom ponúkli nízke spiatočné časy po celom svete (ohraničené časom spiatočnej cesty k najbližšiemu okrajovému miestu), ale trasa 53 to nerobí.

Pochopte, že existuje zaujímavý spôsob použitia cdns ako centrálnych bodov toku dopravy, konkrétne na zrýchlenie trojcestného podania ruky použitého na vytvorenie počiatočného pripojenia. Route 53 toto neponúka.

Pochopte koncept verejne hosťovanej zóny. Verejne hostovaná zóna je kontajner pre všetky sady záznamov priradené k webovej doméne a jej subdoménam.

• Každá verejne hostovaná zóna má jeden záznam NS (Name Server), ktorý špecifikuje štyri menné servery Amazon, ktoré sa majú použiť na riešenie domény a jej subdomén. Táto sada štyroch menných serverov sa nazýva sada delegácií. Ak chcete migrovať záznamy DNS na Amazon Route 53, musíte aktualizovať zoznam štyroch menných serverov u registrátora (kde ste zaregistrovali doménu) na túto sadu štyroch menných serverov. Globálna aktualizácia tohto zoznamu môže trvať 24-48 hodín.
• Každá verejne hostovaná zóna má tiež jeden záznam SOA (Začiatok oprávnenia), ktorý poskytuje smerodajné informácie o doméne vrátane primárneho servera názvov, e -mailu správcu domény, sériového čísla domény a časovačov súvisiacich s obnovením zóny.
• Sada delegácií je vo všeobecnosti odlišná pre rôzne verejné hostované zóny. Je však možné použiť rozhranie Route 53 API, aby sa rovnaká sada delegácií používala pre rôzne verejné hostované zóny. To pomáha uľahčiť migráciu hostingu pre veľký počet webových stránok, pretože mnoho registrátorov umožňuje používateľom určiť predvolenú sadu serverov mien, ktoré sa majú použiť vo všetkých ich doménach.

Pochopte pojem množiny rekordov. Jednotlivé položky v každej hostiteľskej zóne sa nazývajú sady záznamov. Zodpovedajú záznamom DNS, ale s niektorými ďalšími nastaveniami.

• Každá sada záznamov má sadu adries, na ktoré sa subdoména môže rozhodnúť. Tieto adresy môžu byť adresy IP (to môžu alebo nemusia byť inštancie EC2) alebo názvy DNS (napríklad pre EC2 ELB, segment S3 nakonfigurovaný ako statický server alebo distribúciu CloudFront). Upozorňujeme, že keď používame názvy DNS, názov DNS sa môže zmeniť na jednu alebo viac adries IP. Napríklad EC2 ELB sa vo všeobecnosti vyrieši na viac adries IP, pričom počet adries IP závisí od počtu zón dostupnosti, v ktorých je v prevádzke, a od zaťaženia prevádzky, ktoré spracováva.
• Každá sada záznamov je priradená k doméne alebo subdoméne domény priradenej k hostiteľskej zóne a hrá úlohu pri riešení tejto domény. Vo všeobecnosti je možné (a rozhodujúce) mať viac množín záznamov (z ktorých každý môže mať zasa niekoľko záznamov) pre jednu subdoménu.
• Každá sada záznamov má typ záznamu. Typy záznamov sú podmnožinou typov záznamov DNS. Najdôležitejšími typmi záznamov pre bežné prípady použitia sú záznamy adries (záznamy A) a záznamy kanonických mien (záznamy CNAME). CNAME má zmysel, keď jednoducho prepisujete jednu subdoménu na druhú. Záznam A je oveľa univerzálnejší.
• Pri použití záznamu, ktorý smeruje priamo na IP adresu inštancie EC2, sa uistite, že IP adresa je elastická IP, aby prežila ukončenie inštancie a mohla byť znova pripojená k novej inštancii.
• Keď používate záznam A alebo CNAME pre Elastic Load Balancer, distribúciu CloudFront, vedro S3 nakonfigurované ako statické miesto alebo záznam Route 53, je možné ho nastaviť ako alias. Záznam Alias jednoducho premapuje subdoménu na názov DNS, ku ktorému je priradený, a preto zmeny druhého menovaného automaticky vyberie prvý. To umožňuje záznamom A využívať niektoré výhody záznamov CNAME a súčasne umožňuje viac záznamov na subdoménu. Umožňuje tiež hlbšiu integráciu so základnými zdrojmi vrátane priameho hodnotenia cieľového zdravia bez toho, aby sa stanovovali samostatné zdravotné kontroly. Myšlienku záznamu aliasu predstavil server DNSimple (nie je spojený s Amazon Route 53). Implementácia Amazonu sa trochu líši od implementácie DNSimple. Amazon ponúka návod na používanie súborov záznamov zdrojov Alias versus Non-Alias.
• V prípade viacerých súborov záznamov pre danú subdoménu a úplný obraz o tom, ako sa vyriešia vyhľadávania DNS pre túto subdoménu, závisí od všetkých súborov záznamov a ich interakcie.

Pochopte pojmy zdravia na ceste 53. Niektoré typy súborov záznamov podporujú kontroly stavu a hodnotenie cieľového zdravia.

• Pre akýkoľvek typ záznamu (alias alebo nie, bez ohľadu na typ záznamu) s politikou inou ako „Jednoduché“ (typy záznamov sú popísané v ďalšej časti) môžete priradiť kontrolu stavu. To môže odoslať príkaz ping na konkrétny koncový bod (s portom, ktorý môžete zadať) pomocou protokolu HTTP (iné protokoly nie sú podporované) a v odpovedi vyhľadať konkrétny vyhľadávací reťazec. Interval požiadaviek je možné nastaviť na 10 sekúnd alebo 30 sekúnd. Limit časového limitu pre odpoveď, dĺžka počiatočného segmentu odpovede, ktorá sa bude zhodovať s vyhľadávacím reťazcom, a zlomok zdravotných kontrol, ktoré je potrebné vykonať, aby sa koncový bod považoval za zdravý, sú kontrolované spoločnosťou Amazon a nie je ich možné konfigurovať používateľom.
• Voľba „Vyhodnotiť cieľový stav“ je k dispozícii pre záznamy aliasov (záznamy CNAME alebo A) bez ohľadu na politiku. Pretože je táto možnosť ponúkaná iba pre konkrétne zdroje Amazonu, môže ťažiť z hlbokej integrácie so základnými zdrojmi. Napríklad v špeciálnom prípade záznamov Alias (záznamy CNAME alebo A), ktoré poukazujú na ELB Amazon Amazon, cieľové hodnotenie zdravia prejde vtedy, ak má ELB aspoň jednu inštanciu, ktorá je zaregistrovaná a je v prevádzke. Toto je špeciálna hlboká integrácia v zákulisí medzi dvoma službami AWS (Route 53 a ELB).

Pochopte „jednoduché“ zásady smerovania. Najjednoduchšou smerovacou politikou je „jednoduchá“ smerovacia politika. Platí to pre prípady, keď je k subdoméne priradená iba jedna sada záznamov. Jednoduchá politika smerovania môže zahŕňať viac adries IP alebo DNS a pre každú z nich sa vyrieši za rovnaký zlomok času. Konkrétne dodržiava stratégiu typu každý s každým. Jednoduché politiky smerovania sa dobre párujú so záznamami CNAME. Ako vždy používajte záznam Alias, ak ukazujete na adresu DNS EC2, ako je napríklad Elastic Load Balancer, a vyhodnotte cieľový stav.

Pochopte zásadu „váženého“ smerovania. Ďalšou bežne používanou smerovacou politikou je „vážená“ smerovacia politika. Tu každý súbor záznamov priradený k subdoméne dostane váhu. V rámci sady záznamov sú všetky jednotlivé IP adresy vyriešené pomocou stratégie každý s každým. V rámci všetkých súborov záznamov je pravdepodobnosť použitia danej sady záznamov pomer hmotnosti sady záznamov k súčtu váh všetkých súborov záznamov pre subdoménu. Ak napríklad existujú pre subdoménu sady záznamov s hmotnosťou 3, 2, 2 a 1, vyberú sa s pravdepodobnosťou 0,38, 0,25, 0,25 a 0,13.

• Zásady váženého smerovania majú zmysel iba v prípade viacerých množín záznamov, pričom všetky používajú zásadu váženého smerovania.
• Typicky pre zásadu váženého smerovania uvádzame iba jednu adresu IP alebo záznam DNS A na množinu záznamov, a preto vytvoríme toľko množín záznamov, koľko je adries IP alebo záznamov DNS A.
• Všimnite si toho, že číselná hmotnosť spojená so sadou záznamov v politike váženého smerovania neposkytuje úplný obraz o pravdepodobnosti použitia tejto sady záznamov: potrebujeme tiež poznať menovateľa (súčet váh vo všetkých súboroch záznamov). Najmä ak pridáme novú množinu záznamov, pravdepodobnosť rozlíšenia pre každú z ďalších množín záznamov klesá v rovnakom pomere. Podobne, ak sa zmení hmotnosť na jednom zo súborov záznamov, ovplyvní to pravdepodobnosť pre všetky ostatné súbory záznamov.

Pochopte zásady smerovania „latencie“. Latentné smerovanie (LBR) je jednou z prepracovanejších smerovacích politík. Každý záznam latencie určuje oblasť webových služieb Amazon.

• Router založený na latencii, keď je požiadaný o vyriešenie subdomény, sa pozerá na svoju pravidelne aktualizovanú tabuľku latencie medzi nasledujúcimi oblasťami: jeho okrajové umiestnenie najbližšie k adrese IP, ktorá robí vyhľadávanie, a oblasti Amazon Web Services uvedenej v sade záznamov.
• Všimnite si toho, že to logicky neznamená, že záznamy v množine záznamov sa nachádzajú v oblasti AWS určenej pre smerovanie na základe latencie. V skutočnosti vaše záznamy nemusia byť vôbec o infraštruktúre AWS! Ak majú infraštruktúru AWS, má zmysel použiť oblasť AWS, v ktorej sa nachádzajú. V opačnom prípade má zmysel použiť najbližšiu oblasť AWS, aby ste týmto záznamom ponúkli najlepšiu proxy pre latenciu.
• Podobne ako v prípade vážených záznamov, sady záznamov založené na latencii majú zmysel iba vtedy, ak je viac ako jeden z nich. V tomto prípade sa latencia pre každú sadu záznamov vypočíta tak, ako je vysvetlené vyššie (tabuľkovým vyhľadaním latencie medzi najbližším umiestnením okraja k žiadateľovi a oblasťou AWS uvedenou v sade záznamov). Potom sa vráti súbor záznamov s najnižšou hlásenou latenciou.
• Upozorňujeme, že tento odhad latencie sa môže veľmi líšiť od skutočnej latencie dopytov z dvoch dôvodov: používa latenciu od okrajových umiestnení k oblasti AWS, nie od skutočného klienta k skutočnému serveru, a po druhé ignoruje čas spracovania na samotných serveroch, ktorý sa môže medzi regiónmi líšiť.
• Trasa 53 predovšetkým neberie do úvahy žiadne informácie o skutočnej latencii dotazov, na rozdiel od vyrovnávača zaťaženia najmenejconns, ktorý používajú ELB spoločnosti Amazon, ktorý adaptívne prerozdeľuje návštevnosť na základe rozdielov v latencii. V ideálnom prípade by sme si mohli predstaviť, že ak je jeden región pomalší ako druhý, druhý región zachytí väčší podiel dopravy zo zemepisných oblastí niekde uprostred týchto dvoch. Čakacia doba na báze smerovanie však nie je to.
• Je známe, že algoritmus smerovania na základe latencie zlyhal, pretože niekedy smeruje dopravu na nesprávne miesto. Ak je teda pre vás latencia skutočne dôležitá a máte malú skupinu zákazníkov, ktorí vo veľkej miere používajú vaše API, je lepšie dať im subdomény, ktoré sa priamo vyriešia v konkrétnych oblastiach, než používať LBR v nádeji, že budú smerované správne.

Pochopte zásadu smerovania „geolokácia“. Je to podobné ako pri smerovaní na základe latencie, ale umožňuje to explicitné špecifikovanie toho, ktoré geografické polohy by sa mali mapovať na aké sady záznamov.

Pochopte zásady smerovania pri zlyhaní. AWS Route 53 ponúka aktívny aj pasívny failover založený na zdravotných kontrolách a priamom vyhodnotení cieľového zdravia, pričom všetky fungujú na princípe neustálej práce, aby sa predišlo kaskádovému zlyhaniu.

• Ak priradíte kontroly stavu k svojim súborom záznamov Route 53, konkrétna sada záznamov bude vyradená z prevádzky po tom, čo zlyhala tri po sebe nasledujúce kontroly stavu (počet porúch je možné konfigurovať). Podobne, ak hodnotíte cieľový stav ELB, súbor záznamov sa vyradí z prevádzky, akonáhle sa cieľ ukáže ako nezdravý. Sady záznamov sa vrátia naživo, keď sa kontrola stavu alebo cieľový stav zdravia vrátia do normálu. Maximálny čas, kedy má byť efekt globálny, je 150 sekúnd: 3 30-sekundové neúspešné kontroly plus 60-sekundové TTL (všimnite si, že TTL je konfigurovateľné a ak ho nastavíte na dlhší čas, bude trvať dlhšie, kým sa zmena prejaví).
• V prípade vážených smerovacích politík to znamená, že váhy stále zdravých záznamov sa proporcionálne zvyšujú.
• V prípade smerovacích politík založených na latencii to znamená, že ak súbor záznamov úplne klesne, všetka návštevnosť, ktorá by tam bola smerovaná, bude namiesto toho smerovaná do najbližšej oblasti s najnižšou latenciou pre konkrétnu časť návštevnosti. Zaťaženie pre ostatné regióny sa preto nebude zvyšovať v rovnakom pomere, ale skôr sa bude zvyšovať na základe ich blízkosti k premávke, ktorú obsluhoval región, ktorý je teraz v prevádzke. To môže viesť k kaskádovému zlyhaniu. Povedzme napríklad, že máte tri regióny: us-west-1, us-East-1 a eu-west-1, pre každý je nastavený jeden záznam a nakonfigurovali ste kapacitu na zvládanie typického zaťaženia premávkou pre každý región. Teraz predpokladajme, že nás-východ-1 klesne. V tomto prípade bude takmer všetka doprava pre nás-východ-1 smerovať na nás-západ-1, najbližší región pre väčšinu dopravy, ktorá by smerovala k nám-východ-1. Pre nás-západ-1 by to mohlo byť významné zvýšenie dopravy a zvýšené zaťaženie by mohlo spôsobiť kolaps regiónu. Teraz všetka globálna premávka zasahuje eu-západ-1, čo môže spôsobiť kolaps tejto oblasti. Výsledkom je, že pasívne zlyhanie môže skutočne spôsobiť globálny kolaps bez starostlivého návrhu. Problém je akútnejší ako v prípade vážených politík smerovania, pretože veľa presmerovanej návštevnosti smeruje do jedného regiónu.
• Je tiež možné mať sady záznamov výslovne označené ako záložné. Tieto sady záznamov sa používajú iba vtedy, ak všetky ostatné sady záznamov vyradia z prevádzky. Môžeme ich použiť na poskytovanie statických záloh.

Dizajn zohľadňujúci náročnosť prepínania. V konzole Route 53 môže byť ťažké prepnúť typ záznamu, aliasy a smerovacie politiky.

• Napríklad existujú množiny záznamov pre konkrétnu subdoménu: nemôžeme kombinovať vážené a latenčné záznamy a nemôžeme mať viac ako jeden jednoduchý záznam.
• Jednou z východísk z tejto výzvy je začať so stromovou štruktúrou záznamov, ktorá umožní vytvorenie novej vetvy stromu. Amazon ponúka sprievodcov komplexnou konfiguráciou DNS.
• Použitie rozhrania Route 53 API poskytuje väčšiu flexibilitu pri vykonávaní zmien ako pri použití konzoly, pretože zložitejšie zmeny je možné vykonávať rýchlejšie, čím sa minimalizujú prestoje počas zložitých zmien medzi konfiguráciami.

Pochopte, že cesta 53 je kľúčovou súčasťou konfigurácie viacerých regiónov.

• Investujte aspoň niekoľko hodín, aby ste sa presvedčili, že vaše zásady pre Route 53 sú nastavené rozumne.
• Preskúmajte používanie dopravných politík a toku návštevnosti, ktoré vám umožňujú ukladať zložité konfigurácie. Z dlhodobého hľadiska nie je klikanie v konzole na úpravu politík dobrým nápadom pre kľúčovú zložku vašej dostupnosti.
• Skúste preskúmať začlenenie aktualizácií rozhrania Route 53 API do skriptov nasadenia (napríklad skriptov Ansible alebo Chef).

Navrhnite tak, aby ste sa vyhli poruchám smerovania založeným na latencii. Ako už bolo spomenuté, ak je latencia pre zákazníka obzvlášť dôležitá alebo ak z nejakého iného dôvodu chcete, aby konkrétny zákazník zasiahol váš koncový bod API iba v konkrétnom regióne, je lepšie mu poskytnúť subdoménu, pre ktorú ste nakonfigurovali iba záznamy. pre tento región, než aby sa spoliehali na smerovanie založené na latencii alebo geolokácii. Tieto zvyčajne nezlyhajú, ale keď sa stanú, ste bezmocní.

Zvážte kreatívne záložné prístupy založené na trase 53.

• Jeden často podceňovaný aspekt smerovania na základe latencie je, že ho môžete použiť na presmerovanie návštevnosti do regiónu, ktorý nie je najbližším regiónom.
• Jeden zo spôsobov, ako to môžete použiť, je nasledujúci. Predpokladajme, že máte dve šance na zadanie dotazu na server backend. Server väčšinou pri prvej šanci odpovie správne. Ak však zlyhá, môže to byť spôsobené problémami špecifickými pre región (napríklad preťažením serverov v regióne alebo problémami s pripojením k regiónu). Preto chcete, aby sa prvý dotaz nachádzal v geograficky najbližšom regióne, ale druhý dotaz v inom regióne, ktorý nie je geograficky najbližší, ale (dúfajme) druhý najbližší.
• Môžete to urobiť tak, že budete mať dve subdomény, jednu pre vašu prvú voľbu a jednu pre vašu druhú voľbu. Záznamy Route 53 pre prvú subdoménu jednoducho používajú smerovanie založené na latencii, ako je definované v predvolenom nastavení (tj. Vytvoríte jednu sadu záznamov pre túto subdoménu a každú aktívnu oblasť, pričom smerujete prenos najbližšie k tejto oblasti k serverom v tejto oblasti). Záznamy trasy 53 pre druhú subdoménu používajú smerovanie založené na latencii, ale odosielajú návštevnosť najbližšie k jednej oblasti do inej oblasti. To zaručuje, že vaše dve šance sú využité v rôznych oblastiach.
• Všimnite si, že to nie je náhradou za zdravotné kontroly a cieľových zdravotné hodnotenie, ale to robí Zamerať sa na prípady, kedy je región trochu preťažené, ale ešte veľmi zdravé. Vyhne sa tiež problému kaskádového zlyhania, kde môže región s vysokou mierou zlyhania skončiť s ďalšou návštevnosťou kvôli druhým pokusom.

Zoznámte sa s príkazmi shell pre lepšie ladenie.

• whois si môže vyhľadať smerodajné registračné informácie o doménach.
• nslookup je možné použiť na získanie informácií o menných serveroch.
• dig (najužitočnejší príkaz na ladenie trasy 53) dokáže nájsť IP adresy priradené k danej subdoméne a môžete si overiť, či sú vrátené výsledky v súlade s vašou smerovacou politikou. Vytlačí sa aj zostávajúci TTL. Keď zadáte prvý príkaz, malo by to byť vaše úplné TTL. Následné vyvolanie v rámci TTL by malo ukázať zostávajúci TTL. Ak je napríklad váš TTL 60 sekúnd, spustenie kopania po 15 sekundách by malo ukázať TTL 45 sekúnd. Ak názov DNS A obsahuje záznamy o aliasoch založené na latencii, ktoré ukazujú na názov DNS B a názov DNS C, môžete vykopať všetky tri mená a potom zistiť, či sa adresy IP, ktoré A vyriešia, zhodujú s adresami IP, na ktoré sa zhodujú písmená B a C. Môžete tiež zadať možnosť +stopy na kopanie, aby sa stopa vytlačila.
• traceroute je tiež užitočný na získanie jasnejších informácií o tom, ako došlo k rozlíšeniu.
• ping je možné použiť na zadanie dotazu na adresu DNS a získanie odhadov času spiatočnej cesty.
• curl alebo wget je možné použiť na odoslanie požiadavky HTTP a získanie odpovede.
• Tieto príkazy shellu môžete spustiť z vlastného počítača alebo prihlásením na vzdialených serveroch na rôznych miestach.