Delen via

Well-Architected Framework perspectief op Azure Traffic Manager

  • Artikel

Azure Traffic Manager is een globale load balancer die verkeer kan distribueren over meerdere Azure-regio's, zones binnen een regio of datacenters binnen die zones. Het maakt gebruik van het DNS-protocol (Domain Name System) om een communicatiepad tot stand te brengen tussen een client en de eindpunten van uw workload. Nadat de verbinding tot stand is gebracht, kunnen clients rechtstreeks verbinding maken met het eindpunt zonder de hulp van Traffic Manager.

In dit artikel wordt ervan uitgegaan dat u als architect de opties voor taakverdeling in Azure hebt bekeken en Azure Traffic Manager hebt gekozen voor uw workload, die wordt geïmplementeerd in meerdere regio's in een actief-actief- of actief-passiefmodel. De instructies in dit artikel bevatten architectonische aanbevelingen die gerelateerd zijn aan de principes van de Well-Architected frameworkpijlers.

Belangrijk

Deze handleiding gebruiken

Elke sectie heeft een ontwerpcontrolelijst die architectuurgebieden van belang presenteert, samen met ontwerpstrategieën die zijn gelokaliseerd in het technologiebereik.

Ook zijn inbegrepen aanbevelingen voor de technologiemogelijkheden die kunnen helpen bij het materialiseren van deze strategieën. De aanbevelingen vertegenwoordigen geen volledige lijst met alle configuraties die beschikbaar zijn voor Traffic Manager en de bijbehorende afhankelijkheden. In plaats daarvan vermelden ze de belangrijkste aanbevelingen die zijn gekoppeld aan de ontwerpperspectieven. Gebruik de aanbevelingen om uw proof-of-concept te bouwen of om uw bestaande omgevingen te optimaliseren.

Basisarchitectuur die de belangrijkste aanbevelingen demonstreert: multiregiotaakverdeling met Traffic Manager, Azure Firewall en Application Gateway.

Technologieomvang

Deze beoordeling is gericht op de onderling gerelateerde beslissingen voor de volgende Azure-resource:

  • Verkeersmanager

diagram met een failoverscenario met Azure Traffic Manager.

Notitie

Voor workloads die HTTP-toepassingen hosten, is Azure Front Door een natuurlijke keuze vanwege de functies, zoals een netwerk voor contentlevering, TLS-beëindiging (Transport Layer Security) en een geïntegreerde firewall.

In vergelijking met Azure Front Door is Traffic Manager eenvoudiger in te stellen, te configureren en te onderhouden. Traffic Manager heeft geen eindpunt dat u rechtstreeks kunt beheren. In tegenstelling tot Front Door, dat clientaanvragen verwerkt, verbindt Traffic Manager alleen clients met het eindpunt van een workload.

Maar deze eenvoud wordt geleverd met compromissen die complexiteit in een architectuur kunnen introduceren. U moet bijvoorbeeld extra beveiligingsmaatregelen implementeren om OWASP-aanvalstypen (Open Worldwide Application Security Project) te blokkeren. Een Web Application Firewall (WAF) in Azure Front Door of Azure Application Gateway biedt deze mogelijkheid. Of u kunt een cache toevoegen, waardoor de levering van inhoud kan worden versneld, maar dat voegt complexiteit toe omdat u een gegevensopslag moet beheren.

Zie Well-Architected Framework-perspectief op Azure Front Doorvoor meer informatie.

Betrouwbaarheid

Het doel van de pijler Betrouwbaarheid is om continue functionaliteit te bieden door voldoende tolerantie te ontwikkelen en de mogelijkheid om snel te herstellen van storingen.

principes voor betrouwbaarheidsontwerp een ontwerpstrategie op hoog niveau bieden die wordt toegepast op afzonderlijke onderdelen, systeemstromen en het systeem als geheel.

Controlelijst voor ontwerpen

Start uw strategie voor het ontwerpen gebaseerd op de checklist voor ontwerpbeoordeling voor betrouwbaarheid. Bepaal de relevantie van uw bedrijfsvereisten, terwijl u rekening houdt met de aard van uw toepassing en de kritieke aspecten van de onderdelen. Breid de strategie uit om zo nodig meer benaderingen op te nemen.

  • Houd rekening met potentiële falen. Traffic Manager is ontworpen om tolerant te zijn. Maar het kan nog steeds een enkel falenpunt zijn voor uw werkbelasting. Als u dit risico wilt beperken, definieert u een secundair pad naar een alternatieve service die actief wordt als Traffic Manager niet beschikbaar is. Gebruik Traffic Manager en de alternatieve service niet samen om routeringsproblemen te voorkomen.

  • Zorg voor een goed begrip van sla-dekking (Service Level Agreement). Wanneer u Traffic Manager SLA'sevalueert, krijgt u inzicht in de dekking met betrekking tot het gepubliceerde percentiel. Uw DNS-zoekopdrachten kunnen bijvoorbeeld meerdere keren mislukken. Deze fouten worden pas als downtime beschouwd als er een volledige minuut lang continu DNS-opzoekfouten optreden.

  • Redundantie opnemen in uw workloadarchitectuur. Als uw service beschikbaar is via een openbaar IP-adres, gebruikt u Traffic Manager om redundantie te implementeren in Azure-regio's, on-premises en andere clouds. U hebt bijvoorbeeld een on-premises toepassing met een secundair exemplaar in de cloud. Als het on-premises systeem uitvalt, kan het cloudexemplaar actief worden, wat helpt om continuïteit te waarborgen.

  • Gebruik een betrouwbare implementatiearchitectuur ter ondersteuning van redundantie. Als load balancer distribueert Traffic Manager verkeer over workloadeindpunten op basis van de manier waarop u de routeringsmethode configureert. U definieert deze configuratie in een Traffic Manager-profiel. Het profiel is een belangrijk onderdeel van uw implementatiestrategie. U kunt de juiste profielconfiguratie gebruiken om een actief-actief model of een actief-passief model met een warme reserve te implementeren.

    Elk profiel specificeert één verkeersrouteringsmethode. Voor sommige scenario's is geavanceerdere verkeersroutering vereist. U kunt Traffic Manager-profielen combineren om te profiteren van meer dan één verkeersrouteringsmethode.

    Zie Traffic Manager-routeringsmethodenvoor meer informatie.

  • Evalueer de cacheduur van DNS-antwoorden. De time-to-live-instelling (TTL) voor DNS-zoekacties in Traffic Manager bepaalt hoe lang downstream DNS-resolvers DNS-antwoorden in de cache opslaan. De standaard-TTL kan leiden tot langere cachetijden dan nodig is, wat mogelijk downtime veroorzaakt als een eindpunt uitvalt. Verminder de TTL om de frequentie van cache-updates te verhogen. Deze methode kan helpen de downtime te beperken, maar verhoogt de frequentie van DNS-zoekacties.

  • Vermijd het verzenden van verkeer naar beschadigde of gecompromitteerde instances. Bekijk de ingebouwde functies voor statustests in Traffic Manager.

    Implementeer voor toepassingen die HTTPS en HTTP gebruiken het patroon voor Gezondheidseindpuntbewaking om een aangepaste pagina binnen uw toepassing te bieden. Op basis van specifieke controles retourneert de pagina een geschikte HTTPS-statuscode. Naast de beschikbaarheid van het eindpunt moet uw gezondheidscontrole ook de afhankelijkheden van uw toepassing bewaken.

    Voor andere toepassingen gebruikt Traffic Manager tcp (Transmission Control Protocol) om de beschikbaarheid van het eindpunt te bepalen.

    Voor meer informatie, zie Health Endpoint Monitoring-patroon en Inzicht in Traffic Manager-probes.

  • Bepaal uw storingstolerantie. Als een back-end niet meer beschikbaar is, kan er enige tijd verstrijken voordat Traffic Manager de fout herkent en het verkeer naar het niet beschikbare eindpunt stopt door te sturen. Er is een periode waarin clientaanvragen niet kunnen worden verwerkt. Gebruik deze tolerantie om testinstellingen te configureren, die bepalen hoe snel u uw bedrijfscontinuïteitsbewerkingen wilt starten.

  • Neem de eindpunten op als onderdeel van uw tolerantietests. Simuleer niet-beschikbare eindpunten om te zien hoe Traffic Manager fouten verwerkt. Stel dat uw workload gebruikmaakt van een load balancer zoals Application Gateway in een particulier virtueel netwerk. U kunt regels voor netwerkbeveiligingsgroepen (NSG) in Azure Chaos Studio gebruiken om fouten van het eindpunt te simuleren. U kunt de toegang tot het subnet waarin Application Gateway zich bevindt blokkeren.

Aanbevelingen

Aanbeveling Voordeel
Meerdere eindpunten uitrollen in de Traffic Manager-profielen en ze inschakelen. Als een eindpunt niet is ingeschakeld, wordt het niet gecontroleerd op statuscontroles of opgenomen in de verkeersrouteringsrotatie. Plaats deze eindpunten in verschillende regio's. Redundante exemplaren helpen de beschikbaarheid te garanderen als één eindpunt uitvalt.
Evalueer de verschillende verkeersrouteringsmethoden. Configureer een of een combinatie van methoden om te worden afgestemd op uw implementatiestrategie. Traffic Manager past de gekozen methode toe op elke DNS-query en gebruikt de methode om te bepalen welk eindpunt wordt geretourneerd in het DNS-antwoord.

- De gewogen methode verdeelt verkeer op basis van de geconfigureerde gewichtscoëfficiënt. Deze methode ondersteunt actief-actieve modellen.
- De methode op basis van prioriteit configureert de primaire regio om verkeer te ontvangen en als back-up naar de secundaire regio te verzenden. Deze methode ondersteunt actief-passieve modellen.
- De geografische methode routeert verkeer op basis van de geografische oorsprong van de DNS-query. Als u alle regio's wilt behandelen, configureert u ten minste één eindpunt met de eigenschap Alle (wereld).		 Een geoptimaliseerde routeringsmethode zorgt ervoor dat u verkeer efficiënt over uw eindpunten distribueert.

U kunt de doelstellingen van uw actief-actief- of actief-passief implementatiemodel ondersteunen. Een efficiënte routeringsmethode zorgt ervoor dat secundaire regio's verkeer kunnen verwerken of als back-up kunnen fungeren.

Geografische routering helpt gebruikers om te leiden naar het dichtstbijzijnde eindpunt op basis van hun locatie. Het helpt ervoor te zorgen dat verkeer efficiënt wordt beheerd en niet verloren gaat.
Stel het DNS TTL-interval duur in op een lage waarde, bij voorkeur minder dan 60 seconden. Als u de prestaties wilt optimaliseren, past u de timing van de statustest en de TTL van de DNS-record aan. Een lage TTL-duur zorgt voor frequentere cache-updates voor downstream-DNS-resolvers en snellere failover. Het minimaliseert ook de downtime en verbetert de algehele reactiesnelheid van uw toepassing.
Stel gezondheidstesten in om het eindpunt te bewaken .

- Schakel AlwaysServeniet in, waardoor eindpuntbewaking wordt uitgeschakeld en aanvragen worden verzonden naar het eindpunt, ongeacht de status.
- Stel de probing interval-waarde in. Houd rekening met de afweging tussen hoe snel u fouten en het aantal aanvragen voor het eindpunt kunt detecteren. Het aantal aanvragen kan aanzienlijk zijn omdat Traffic Manager een globale service is die gelijktijdig pingt vanaf verschillende locaties.
- Stel de probe timeout-waarde in. Overweeg hoe lang er gewacht moet worden voordat het eindpunt als ongezond wordt verklaard. Neem valse positieven op in het aantal mislukkingen.		 Gezondheidsonderzoeken zorgen ervoor dat alleen gezonde instanties gebruikersaanvragen verwerken. Ze helpen ook bepalen of fouten niet-tijdelijk zijn en hoe snel failoverbewerkingen moeten plaatsvinden.

Veiligheid

Het doel van de pijler Beveiliging is het bieden van vertrouwelijkheid, integriteit en beschikbaarheid garanties voor de workload.

De Beveiligingsontwerpprincipes een ontwerpstrategie op hoog niveau bieden voor het bereiken van deze doelstellingen door benaderingen toe te passen op het technische ontwerp van Traffic Manager.

Controlelijst voor ontwerpen

  • Controleer de beveiligingsbasislijnen. Bekijk de beveiligingsbasislijn voor Traffic Manager-om uw beveiligingspostuur te verbeteren.

  • Niet-geautoriseerde wijziging van verkeersroutering voorkomen. Traffic Manager-profielen behandelen als kritieke workloadresources omdat ze de configuratie-instellingen voor het routeren van verkeer bevatten. Alleen geautoriseerde identiteiten moeten toegang hebben tot deze profielen. Implementeer op rollen gebaseerd toegangsbeheer (RBAC) op het besturingsvlak om taken zoals het maken, verwijderen of wijzigen van resources te beperken. Alleen geautoriseerde identiteiten moeten de autoriteit hebben om eindpunten in of uit te schakelen. Onbevoegde toegang kan leiden tot configuratiewijzigingen en kan verkeer omleiden naar schadelijke implementaties.

  • Bescherm toepassingen tegen bedreigingen aan de netwerkrand. Traffic Manager biedt geen ingebouwde beveiligingsfuncties, zoals een WAF. Als u HTTP-toepassingen wilt beveiligen, moet u verkeersinspectie implementeren op eindpuntniveau.

    Een typische architectuur kan Traffic Manager en meerdere eindpunten bevatten. Voor elk eindpunt biedt een toepassingsgateway die TLS-beëindiging afhandelt en andere beveiligingsfuncties beveiliging. Zie Multiregio-taakverdeling met Traffic Manager, Azure Firewall en Application Gatewayvoor een referentiearchitectuur die dat patroon laat zien.

  • DNS-vermeldingen beperken. Traffic Manager kan gevoelig zijn voor aanvallen die DNS-gegevens manipuleren, waardoor verkeer naar schadelijke sites kan worden omgeleid en beveiligingsproblemen kunnen veroorzaken. Een veelvoorkomende bedreiging is een overname van subdomeinen, waarbij een DNS-record verwijst naar een niet-ingerichte Azure-resource. Als u overname van subdomeinen wilt voorkomen, gebruikt u Azure DNS-aliasrecords en koppelt u de levenscyclus van een DNS-record met een Azure-resource.

    Zie voor meer informatie het voorkomen van zwevende DNS-vermeldingen.

Aanbevelingen

Aanbeveling Voordeel
toepassingsgateways toevoegen aan de werkbelastingeindpunten.

Als u beveiligingsinspectie wilt implementeren met een firewall voor HTTP-toepassingen, voegt u toepassingsgateways toe aan de workloadeindpunten.		 U kunt binnenkomend HTTP-verkeer inspecteren om de toepassing te beschermen tegen veelvoorkomende aanvallen.
Maak een aliasrecord in Azure DNS voor de apexdomeinnaam van uw workload om te verwijzen naar een Traffic Manager-profiel. Aliasrecords koppelen de levenscyclus van een DNS-record nauw aan een Azure-resource. Deze configuratie helpt bij het voorkomen van zwevende verwijzingen als de workload buiten gebruik wordt gesteld. Als het Traffic Manager-profiel wordt verwijderd, wordt de DNS-aliasrecord een lege recordset. Er wordt niet meer verwezen naar de verwijderde resource.

Kostenoptimalisatie

Kostenoptimalisatie richt zich op het detecteren van uitgavenpatronen, het prioriteren van investeringen in kritieke gebieden en het optimaliseren in andere gebieden om aan het budget van de organisatie en de bedrijfsvereisten te voldoen.

De ontwerpprincipes voor Cost Optimization bieden een ontwerpstrategie op hoog niveau voor het bereiken van deze doelstellingen en het maken van compromissen in het technische ontwerp met betrekking tot Traffic Manager en de omgeving ervan.

Controlelijst voor ontwerpen

Start uw ontwerpstrategie op basis van de -ontwerpbeoordeling checklist voor kostenoptimalisatie voor investeringen. Verfijn het ontwerp zodat de werklast is afgestemd op het budget dat aan deze is toegewezen. Uw ontwerp moet gebruikmaken van de juiste Azure-mogelijkheden, investeringen bewaken en mogelijkheden vinden om in de loop van de tijd te optimaliseren.

  • Evalueer de kosten van functies. In de dashboardfunctie voor verkeersweergave ziet u waar uw clients verbinding mee maken en de bijbehorende latentie. Deze informatie helpt de prestaties te optimaliseren en uw ontwerp te verfijnen, wat bijdraagt aan operationele uitmuntendheid en systeemefficiëntie. Er worden echter extra kosten in rekening gebracht. Zie Traffic View Billingvoor meer informatie.

    Houd ook rekening met de kosten die zijn verbonden aan gezondheidstests. Traffic Manager pingt uw gedefinieerde eindpunten vanaf verschillende locaties om de beschikbaarheid ervan te controleren. U kunt langzame pings en snelle pings kiezen. Snelle pings detecteren sneller fouten, maar er worden hogere kosten in rekening gebracht. Ze voegen ook meer belasting toe aan de workload omdat statuscontroles vaker voorkomen.

  • Evalueer de kosten van uw routeringsstrategie. Als de meeste clients bijvoorbeeld toegang hebben tot uw eindpunt vanuit een regio met hoge latentie, kunt u een ander eindpunt dichter bij die gebruikers maken en de routeringsmethode in Traffic Manager aanpassen. Deze procedure vermindert de latentie, zodat u meer aanvragen met minder capaciteit kunt verwerken, wat leidt tot kostenbesparingen.

Aanbevelingen

Aanbeveling Voordeel
Gebruik de prijscalculator om de kosten van Traffic Manager-functies te schatten. U kunt een nauwkeuriger kostenmodel hebben en zo nodig governance instellen voor resources.
Schakel het dashboard voor verkeersweergave in tijdens uw optimalisatie-inspanningen. De functie helpt u beter inzicht te krijgen in gebruikspatronen. Gebruik deze gegevens voor het afstemmen van prestaties om te voldoen aan uw workloaddoelen.

Schakel functies op het juiste moment in en pas de juiste laag toe om te voorkomen dat middelen worden onderbenut.
Kies tussen snelle of langzame pings voor statustests, afhankelijk van uw metrische herstelgegevens.

Snelle pings detecteren sneller fouten, maar kosten meer. Trage pings gaan langzamer, maar kosten minder.

Schakel pings niet uit.		 Ping minder vaak om de kosten te optimaliseren en de belasting op werklastendpunten te verminderen.

Operationele uitmuntendheid

Operational Excellence richt zich voornamelijk op procedures voor ontwikkelprocedures, waarneembaarheid en releasebeheer.

De ontwerpprincipes voor Operational Excellence bieden een ontwerpstrategie op hoog niveau voor het bereiken van deze doelstellingen voor de operationele vereisten van de workload.

Controlelijst voor ontwerpen

  • Operationele gegevens verzamelen en analyseren als onderdeel van uw workloadbewaking. Leg relevante Traffic Manager-logboeken en metrische gegevens vast. Gebruik deze gegevens om problemen op te lossen, verkeersgedrag te begrijpen en routeringslogica af te stemmen.

  • Verkeersgegevens voor profielen weergeven. Met deze gegevens kunt u gebieden voor verbetering vaststellen, zoals het uitbreiden van uw Azure-aanwezigheid in regio's met hoge latentie. Het markeert ook verkeerspatronen in verschillende regio's om u te helpen bepalen waar u investeringen moet verhogen of verlagen.

  • herstelbewerkingen implementeren. Uw implementatie voor herstel na noodgevallen kan worden ontworpen om netwerk-/webverkeer van de hoofdsite om te leiden naar een back-upsite. Deze methode voor herstel na noodgevallen kan worden geïmplementeerd met behulp van Azure DNS en Azure Traffic Manager (DNS). In het geval van een noodgeval, als het primaire eindpunt wordt gedegradeerd, leidt Traffic Manager verkeer om naar een gezond secundair eindpunt. Traffic Manager geeft standaard prioriteit aan het primaire eindpunt, maar kan ook worden ingesteld met extra failover-eindpunten of load balancers om de verkeersbelasting te verdelen. Zie Herstel na noodgevallen en detectie van storingen instellenvoor meer informatie.

  • Vermijd automatische failbackbewerkingen. Wanneer u een failback uitvoert, gebruikt u geen automatische failback, die onmiddellijk terugschakelt naar het oorspronkelijke eindpunt in het primaire eindpunt wanneer deze beschikbaar is. Schakel in plaats daarvan het oorspronkelijke eindpunt uit en gebruik het secundaire eindpunt totdat u wilt overschakelen. Deze aanpak biedt tijd voor stabilisatie. Directe failback kan extra belasting en vertragingen tot stand brengen.

    Zie referentiearchitectuur voor multiregiotaakverdelingvoor meer informatie.

  • Configuratie-instellingen testen. Onjuiste configuraties kunnen van invloed zijn op alle aspecten van de workload, met name op betrouwbaarheid. Test de configuraties met meerdere clients op verschillende locaties. Voor meer informatie, zie Controleer de Traffic Manager-instellingen.

Aanbevelingen

Aanbeveling Voordeel
Diagnostische logboeken inschakelen voor een Traffic Manager-profiel.

Gebruik hulpprogramma's om logboeken opnieuw af te spelen en de statuscontrolegegevens te analyseren.		 Diagnostische logboeken bieden inzicht in het gedrag van het Traffic Manager-profiel. U kunt bijvoorbeeld de redenen voor afzonderlijke time-outs voor tests voor een eindpunt identificeren.
Zet het dashboard voor verkeersweergave van in met. Krijg inzicht in de locatie waar uw clients verbinding mee maken en de bijbehorende latentie. Deze informatie helpt de prestaties en kosten te optimaliseren, omdat u uw ontwerp kunt verfijnen.
Profiteer van de Heat Map REST API, die gegevens over clientlocaties en latentie biedt. Deze benadering biedt flexibiliteit, zoals het instellen van een specifieke periode. U kunt gegevens toevoegen aan aangepaste hulpprogramma's of dashboards. U kunt deze API ook gebruiken om te integreren met externe hulpprogramma's.
de eindpunten uitschakelen voor operationele activiteiten. U kunt bijvoorbeeld failback uitschakelen na een failover om onderhoud of tests uit te voeren. Het uitschakelen van het eindpunt vanuit de load balancer is nuttig voor operationele taken, omdat u live verkeer niet kunt stoppen. Tijdens onderhoud ontvangen exemplaren geen verkeer als u het eindpunt uitschakelt. Deze methode voorkomt automatische failback.

Prestatie-efficiëntie

Prestatie-efficiëntie gaat over het behouden van de gebruikerservaring, zelfs wanneer er een toename van de belasting is, door de capaciteit te beheren. De strategie omvat het schalen van resources, het identificeren en optimaliseren van potentiële knelpunten en het optimaliseren van piekprestaties.

De ontwerpprincipes voor Prestatie-efficiëntie een ontwerpstrategie op hoog niveau bieden voor het bereiken van deze capaciteitsdoelen ten opzichte van het verwachte gebruik.

Controlelijst voor ontwerpen

Start uw ontwerpstrategie op basis van de controlelijst voor ontwerpbeoordeling voor prestatie-efficiëntie. Definieer een basislijn die is gebaseerd op key performance indicators voor Traffic Manager.

  • Meet de invloed van de prestaties van uw configuratie. Traffic Manager interfereert niet met de directe verbinding tussen de client en uw eindpunt. De belangrijkste invloed op de prestaties is de eerste DNS-zoekactie. De TTL-instelling is van invloed op hoe vaak deze zoekopdracht plaatsvindt. Een lagere TTL betekent frequentere DNS-resoluties, wat de prestaties enigszins kan beïnvloeden. Als u de TTL instelt op nul, vereist elke aanvraag een DNS-zoekactie, waardoor een kleine vertraging wordt toegevoegd voordat het eindpunt wordt geopend.

    Omdat Traffic Manager op DNS-niveau werkt, biedt dit geen ondersteuning voor sessieaffiniteit. Traffic Manager kan gebruikers voor elke aanroep naar verschillende eindpunten leiden. Als u sessieaffiniteit nodig hebt, moet u de status behouden in een afzonderlijk gegevensarchief.

    Zie Prestatieoverwegingen voor Traffic Manager-voor meer informatie.

  • Pas het gedrag van verkeersroutering aan om de prestaties te optimaliseren. Eén profiel kan meerdere eindpunten hebben, maar u kunt slechts één routeringsmethode tegelijk toepassen.

    Voor complexere scenario's kunt u een hiërarchie van profielen maken om verschillende routeringsmethoden te combineren. U kunt bijvoorbeeld regio's prioriteren en vervolgens routering op basis van prestaties binnen regio's gebruiken.

Aanbevelingen

Aanbeveling Voordeel
Gebruik de routeringsmethode voor prestaties wanneer u eindpunten op verschillende geografische locaties hebt. Met deze methode wordt prioriteit gegeven aan het verzenden van verkeer naar het eindpunt met de laagste latentie. Deze methode zorgt voor een snelle service voor gebruikers.
Gebruik gespecialiseerde hulpprogramma's om de prestaties te optimaliseren. Meet de prestaties van uw DNS-zoekacties. Om de prestaties van het verkeer te analyseren, gebruikt u het verkeersoverzicht-dashboard of de Heat Map REST API. Hulpprogramma's voor dns-latentiemeting voeren een volledige DNS-zoekactie uit en bieden prestatiegegevens. U kunt deze gegevens gebruiken om de TTL-duur in te stellen en de prestaties te optimaliseren.
Combineer verkeerstechnieken met geneste profielen voor optimale prestaties, zoals bepaald door de vereisten van uw werkbelasting. Een geoptimaliseerde routeringsmethode zorgt ervoor dat verkeer wordt omgeleid naar de meest responsieve en dichtstbijzijnde eindpunten. Deze aanpak helpt de prestaties en gebruikerservaring van toepassingen te verbeteren.
Gebruik de functie voor echte gebruikersmetingen om netwerklatentiemetingen weer te geven in Azure-regio's. Deze functie is gratis beschikbaar. U kunt gegevensgestuurde routeringsbeslissingen nemen om query's naar de Azure-regio te leiden die de laagste latentie biedt.
Stel het DNS TTL-interval in op een hogere waarde. Clients kunnen de resultaten gedurende een langere periode in de cache opslaan, waardoor dns niet telkens hoeft te worden omgezet.

Azure-beleid

Azure biedt een uitgebreide set ingebouwde beleidsregels met betrekking tot Traffic Manager en de bijbehorende afhankelijkheden. Enkele van de voorgaande aanbevelingen kunnen worden gecontroleerd via Azure Policy. U kunt bijvoorbeeld controleren of:

  • Bronlogboeken zijn geactiveerd om activiteiten bij te houden.
  • Logboeken voor Traffic Manager-profielen worden verzonden naar Azure Event Hubs.

Raadpleeg de ingebouwde azure Policy-definities voor Azure-netwerkservicesvoor uitgebreide governance.

Aanbevelingen voor Azure Advisor

Azure Advisor- is een gepersonaliseerde cloudconsultant waarmee u de best practices kunt volgen om uw Azure-implementaties te optimaliseren. Hier volgen enkele aanbevelingen waarmee u de betrouwbaarheid, beveiliging, kosteneffectiviteit, prestaties en operationele uitmuntendheid van uw webtoepassingsexemplaren kunt verbeteren.

Compromissen

Mogelijk moet u een compromis tussen ontwerpen maken als u de benaderingen in de controlelijsten voor pijlers gebruikt. Hier volgen enkele voorbeelden van voordelen en nadelen.

betrouwbaarheid en prestatie-efficiëntie

  • De TTL-instelling voor DNS-zoekacties. De standaard-TTL-instelling kan leiden tot langere cachetijden. Lange cachetijden kunnen downtime veroorzaken als een eindpunt mislukt omdat de toepassing een verbinding met het mislukte eindpunt blijft proberen voor de TTL-duur.

    Verminder de TTL om dit probleem te verhelpen. Een lagere TTL heeft frequentere updates en snellere failover, maar verhoogt de frequentie van DNS-zoekacties. Deze aanpak kan van invloed zijn op de prestaties en de belasting op DNS-servers verhogen.

betrouwbaarheid en kostenoptimalisatie

  • Gezondheidstests Traffic Manager gebruikt statustests om uw eindpunten vanaf verschillende locaties te pingen om hun beschikbaarheid te controleren. U kunt kiezen voor trage pings of snelle pings. Snelle pings detecteren sneller fouten, maar kosten toevoegen. Langzame pings hebben langer nodig om storingen te detecteren, maar kosten minder. De snelheid van foutdetectie en herstel in balans houden met de bijbehorende kosten.

Volgende stap

Bekijk de volgende bronnen die de aanbevelingen in dit artikel laten zien.