4 frågor att tänka på när du väljer en extern DNS-leverantör - IBM Blog

4 frågor att tänka på när du väljer en extern DNS-leverantör – IBM Blog

Källnod: 3093759


4 frågor att tänka på när du väljer en extern DNS-leverantör – IBM Blog



En man lutar sig över ett stökigt skrivbord och skriver på en väggmonterad whiteboard i en hemmakontorsmiljö

Det finns många skäl att flytta till en hanterad DNS-plattform, men de kretsar alla kring ett centralt tema. När du når en kritisk massa av trafik och börjar oroa dig för prestandan och tillförlitligheten för det du levererar, är det dags att överväga en hanterad DNS-lösning.

Det finns flera välkända alternativ där ute, och för en nykomling kan de verka relativt lika till en början. Alla hanterade DNS-leverantörer erbjuder en 100 % drifttid SLA genom ett globalt anycasted DNS-nätverk. De har alla failover-alternativ, vilket kan förbättra motståndskraften. De tillhandahåller alla instrumentpaneler och mätvärden så att du kan analysera prestanda. De tar alla betalt baserat på användning.

Men under dessa bordsinsatser hittar du några betydande skillnader. Det tillvägagångssätt som olika företag tar kommer i slutändan att påverka ditt nätverks prestanda, skala och kapacitet. Det är viktigt att veta vilka av dessa funktioner och funktioner som är viktiga för dig innan du jämför alternativ.

När du håller på att sammanställa din lista med "måste ha", sätter vi ihop några frågor som kan hjälpa dig att bygga ut din lista med krav.

1. Vilken är din riskprofil?

Alla hanterade DNS-leverantörer som är värda sitt salt kommer att erbjuda en 100 % drifttid SLA. Men även det kanske inte är tillräckligt bra. Nätverksavbrott inträffar, och ibland möter även ett mycket motståndskraftigt globalt nätverk tillgänglighetsproblem. 

Att ha ett redundant failover-alternativ är vanligtvis vettigt, särskilt för "alltid på"-tjänster som verkligen kräver hög tillgänglighet. I vissa fall innebär det att du registrerar dig hos mer än en leverantör. NS1 tar ett annat tillvägagångssätt och erbjuder en separerat redundant system som du kan hantera från samma kontrollplan. 

Det finns också frågan om hur din hanterade DNS-leverantör faktiskt ger motståndskraft. Mekaniken bakom failover spelar roll. Är det automatiserat? Är det anpassningsbart? Hur många alternativ har du? Hur lätt är det att hantera dessa alternativ? Även det mest stenhårda redundanta DNS-alternativet kan vara värdelöst om det finns en hicka i failover-processen.

2. Vad behöver dina utvecklare?

De flesta organisationer börjar använda en hanterad DNS-lösning för att förbättra upplevelsen för kunder och slutanvändare. Sedan upptäcker de att det finns en annan målgrupp: utvecklare.

Dagens nätverk drivs av DevOps, edge computing och serverlösa arkitekturer, som alla kräver en API-först strategi för infrastruktur. Anslutningar till verktyg som Terraform är också ett viktigt krav för utvecklare eftersom de utnyttjar nätverksinfrastruktur för att bygga kundnära tjänster.

När man utvärderar hanterade DNS-lösningar är det viktigt att undersöka bredden och djupet i deras API-erbjudande och kopplingar till standardverktyg som används av utvecklare. Det räcker inte att API:er bara är tillgängliga, de ska också vara väldokumenterade och lätta att använda.

3. Hur kommer du att hantera trafik mellan flera CDN:er och/eller moln?

Om du har tillräckligt med kritisk massa för att behöva en hanterad DNS-lösning, kommer du någon gång förmodligen att börja använda flera moln eller CDN:er för att leverera applikationer och innehåll. Det innebär att distribuera trafik till olika leverantörer till optimera prestanda och förbättra motståndskraften.

Det är vanligt att en hanterad DNS-leverantör erbjuder någon form av trafikstyrning, men det finns betydande skillnader i hur de fungerar. Du vill se hur enkelt det är att använda trafikstyrningsfunktionen i en hanterad DNS-lösning. Hur mycket manuell ansträngning är involverad i konfigurationer och distributioner?

Det är också viktigt att titta på din förmåga att anpassa trafikstyrningsalternativ. Kommer du att få de riktade resultat du letar efter med de alternativ som finns tillgängliga? Eller är alternativen för trafikstyrning för tunna för att ge den prestanda du verkligen behöver? Kommer du att använda trafikstyrning för grundläggande lastbalansering och failover-funktioner, eller går dina behov djupare?

4. Hur viktig är prestation?

För leverans av de flesta applikationer och tjänster räcker hastigheten för de flesta hanterade DNS-tjänster för att få jobbet gjort. Några millisekunder snabbare eller långsammare än de genomsnittliga industririktmärkena spelar ingen roll.

Ändå finns det specifika användningsfall – streaming video och spel i synnerhet – där dessa millisekunder direkt kan påverka intäkterna. I dessa fall är det viktigt att vara särskilt uppmärksam på både hastigheten på nätverkssvaren och djupet på trafikstyrningsalternativen.

Eftersom de flesta högpresterande applikationer och tjänster kommer att använda flera moln och/eller CDN:er, är möjligheten att automatiskt styra trafiken till den bästa tjänsten avgörande. Du kanske också vill väga prestanda mot faktorer som kostnad eller tillförlitlighet – en annan anledning att prioritera lösningar med anpassningsbara trafikstyrningsalternativ.

Om du levererar innehåll till Kina kräver optimering av prestanda särskild uppmärksamhet på distributionsgeografi. Dess unika nätverksarkitektur kräver en hanterad DNS-lösning med lokal närvaro.

Läs mer om IBM NS1 Connects Managed DNS-lösning.

var den här artikeln hjälpsam?

JaNej


Mer från Cloud




Är premium DNS värt det?

4 min läs - Det finns ett ögonblick i livet för de flesta företag där kopplingen mellan Domain Name System (DNS) och intäkter kommer i större fokus. Det är ögonblicket då företag upptäcker att leverans av högkvalitativa applikationer, tjänster och innehåll kräver mer uppmärksamhet på kvaliteten på DNS-anslutningar. För de flesta företag är detta också ögonblicket då de upptäcker att de gratis DNS-tjänster som erbjuds av domänregistratorer eller gör-det-själv-system som de har använt inte längre är lämpliga för ändamålet. Den kopplingen mellan...




Bör stora företag vara värd för sin auktoritativa DNS?

4 min läs - I ett nyligen inlägg beskrev vi fallgroparna med ett auktoritativt domännamnssystem (DNS) som är självvärd, ur perspektivet av ett nystartat eller medelstort företag som sätter ihop ett gör-det-själv-system med hjälp av BIND DNS eller andra verktyg med öppen källkod. Huvudtanken var att varje företag kommer till en punkt där de växer ur sina egna, hemodlade auktoritativa DNS-system. Av vilken anledning som helst – vare sig det är funktionalitet, kostnad, tillförlitlighet eller resurser – kommer de flesta företag naturligtvis över behovet av en hanterad DNS-tjänst som levereras av...




ManagePlus – din resa före, med och bortom RISE med SAP

5 min läs - RISE med SAP har inte bara varit en stor molnaktör de senaste åren, det har också blivit standardmolnerbjudandet från SAP för olika produkter. Men när man bedömer vad som krävs för att gå ombord i RISE med SAP, finns det flera punkter att tänka på. Särskilt viktigt är en god förståelse för RACI-uppdelningen kring standard-, tilläggs- och tillvalstjänster, tillsammans med relevanta CAS-paket (Cloud Application Service). Om du undrar om RISE med SAP är rätt lösning...




Densitet gör skillnad med 4:e generationens Intel Xeon på IBM Cloud Bare Metal-servrar

4 min läs - När det gäller barmetallservrar är det bra att vara tät. Faktum är att ju tätare lagring och kärnor är, desto bättre. Den här veckan introducerade vi IBM Cloud Bare Metal-servrar med 4:e generationens Intel® Xeon®-processorer i fler viktiga IBM Cloud Data Centers runt om i världen. För alla som precis kommit ikapp, 4:e generationens Intel Xeon-processorer är Intels senaste, mest högpresterande processorer som vi först tillkännagav i januari 2023 i vår kärnserverflotta. Låt oss packa upp där kärnan...

IBMs nyhetsbrev

Få våra nyhetsbrev och ämnesuppdateringar som ger det senaste tankeledarskapet och insikter om nya trender.

Prenumerera nu

Fler nyhetsbrev

Tidsstämpel:

Mer från IBM IoT