Vraag Is Round-Robin DNS "goed genoeg" voor load-balancing van statische inhoud?


We hebben een set gedeelde, statische inhoud die we serveren tussen onze websites op http://sstatic.net. Helaas is deze inhoud momenteel helemaal niet in balans - het wordt geserveerd vanaf een enkele server. Als die server problemen heeft, zijn alle sites die erop vertrouwen effectief uitgeschakeld omdat de gedeelde bronnen essentiële gedeelde JavaScript-bibliotheken en afbeeldingen zijn.

We zijn op zoek naar manieren om de statische inhoud van deze server in evenwicht te brengen, om de afhankelijkheid van één server te voorkomen.

Ik realiseer me dat round-robin DNS op zijn best een low-end is (sommigen zouden zelfs kunnen zeggen getto) oplossing, maar ik kan het niet helpen af ​​te vragen - is round robin DNS een 'goed genoeg'-oplossing voor het reguliere load-balancing van statische inhoud?

Hierover is enige discussie in de [dns] [taakverdeling] tags, en ik heb enkele geweldige berichten over het onderwerp gelezen.

Ik ben me bewust van de algemene nadelen van DNS-taakverdeling door meerdere A-records van round-robin:

  • er is meestal geen hartslag of foutdetectie met DNS-records, dus als een bepaalde server in de rotatie uitvalt, moet de A-record ervan handmatig uit de DNS-vermeldingen worden verwijderd
  • de tijd om te leven (TTL) moet noodzakelijk vrij laag worden ingesteld om helemaal te werken, aangezien DNS-entries agressief in het cachegeheugen worden opgeslagen op het internet
  • de clientcomputers zijn verantwoordelijk om te zien dat er meerdere A-records zijn en de juiste te selecteren

Maar, is round robin DNS goed genoeg als starter, beter dan niets, "terwijl we onderzoek doen en betere alternatieven implementeren" vorm van taakverdeling voor onze statische inhoud? Of is DNS-Round Robin vrijwel waardeloos onder ieder situatie?


60
2018-01-09 03:01


oorsprong


HAProxy geen optie? - Howiecamp
zoals ik in de post zei, dit is een specifieke vraag over deze oplossing - kunnen we blijven over het onderwerp? - Jeff Atwood
load-balancing (en.wikipedia.org/wiki/Load_balancing_%28computing%29) is heel anders dan redundantie (en.wikipedia.org/wiki/Redundancy_%28engineering%29). Zoals Jeff in zijn openingsparagraaf al zei, is hij op zoek naar een manier om single point of failure (redundantie) te verwijderen, en niet om het werk in evenwicht te brengen. Kan iemand retageren? - antony.trupe
@jeff - absoluut, een dumb load balancer (welke gewone round robin DNS is) doet geen redundantie. Het is nog moeilijker als je het hebt over balancering / redundantie op meerdere sites. - Alnitak
@symcbean Ik ben goed bekend met de terminologievoorwaarden die zijn gedocumenteerd in RFC 2119. U zei dat de DNS-server de voorkeurslijst definieert. Tenzij je een bijzonder vreemde definitie van "voorkeurslijsten" hebt, is dat gewoon niet waar. - Alnitak


antwoorden:


Jeff, ik ben het er niet mee eens, load balancing impliceert geen overtolligheid, het is eigenlijk precies het tegenovergestelde. Hoe meer servers u heeft, des te groter de kans dat u op een bepaald moment een storing ondervindt. Daarom is redundantie verplicht bij het uitvoeren van load-balancing, maar helaas zijn er veel oplossingen die alleen load balancing bieden zonder enige gezondheidscontrole uit te voeren, wat resulteert in een minder betrouwbare service.

DNS roundrobin is uitstekend om de capaciteit te vergroten door de belasting te verdelen over meerdere punten (potentieel geografisch verdeeld). Maar het biedt geen fail-over. U moet eerst beschrijven welk type fout u probeert te dekken. Een serverstoring moet lokaal worden afgedekt met een standaard IP-adresovername mechanisme (VRRP, CARP, ...). Een switch-fout wordt afgedekt door veerkrachtige links op de server naar twee switches. Een WAN-linkstoring kan worden afgedekt door een multi-link-opstelling tussen u en uw provider, met behulp van een routeringsprotocol of een layer2-oplossing (bijv. Multi-link PPP). Een sitestoring moet worden gedekt door BGP: uw IP-adressen worden gerepliceerd over meerdere sites en u kondigt ze aan op het net alleen waar ze beschikbaar zijn.

Op basis van uw vraag lijkt het erop dat u alleen een fail-over-oplossing voor de server hoeft aan te bieden, wat de eenvoudigste oplossing is omdat er geen hardware bij is of een contract met een ISP. U hoeft daarvoor alleen maar de juiste software op uw server in te stellen en het is veruit de goedkoopste en meest betrouwbare oplossing.

U vroeg "wat als een haproxy-machine uitvalt?". Het is hetzelfde. Alle mensen die ik ken en die haproxy gebruiken voor load balancing en hoge beschikbaarheid hebben twee machines en voeren ofwel ucarp, keepalived of heartbeat uit om er zeker van te zijn dat één van deze altijd beschikbaar is.

In de hoop dat dit helpt!


56
2018-01-09 11:17



U bent wellicht geïnteresseerd in een artikel dat ik ongeveer 4 jaar geleden schreef over deze concepten: 1wt.eu/articles/2006_lb (neem de PDF, het lezen van de HTML door de pagina's is saai). - Willy Tarreau
-1: "biedt geen failover" - ja dat doet het - en implementeert het op de enige plaats waar niet-beschikbaarheid op betrouwbare wijze kan worden vastgesteld - bij de klant. - symcbean
Helemaal niet. Het zou werken als DNS geen gebruik zou maken van caches, maar dit is niet het geval en clients kunnen caches niet dwingen zich te vernieuwen. Praat met een persoon die regelmatig van DNS-ingangen wisselt en zij zullen u vertellen dat, hoewel ze binnen 5 minuten een switch van 80% waarnemen, het in het algemeen meer dan een week duurt om bijna 100% te worden. DNS biedt dus geen fail-over. - Willy Tarreau
Een eenvoudig voorbeeld van "load balancing without redundancy" is RAID0. - robbyt
Willy, je hebt gelijk dat DNS-records eeuwen nodig hebben om te updaten. RR-DNS met browsers wordt echter op browserniveau afgehandeld, waarbij alle IP-adressen één na één worden getest als de eerste verzonden door de DNS lijkt te zijn verwijderd. In dit geval wijzigt u nooit uw DNS-records, dus er zijn geen updates om op te wachten. - Yvan


Als load-balancing is het getto maar meer of minder effectief. Als u één server had die van de belasting overviel en deze naar meerdere servers wilde verspreiden, kan dat een goede reden zijn om dit te doen, in ieder geval tijdelijk.

Er zijn een aantal geldige kritieken op round-robin DNS als load-balancing, en ik zou het niet aanbevelen om het anders te doen dan als een kortdurend pleister.

Maar u zegt dat uw primaire motivatie is om een ​​afhankelijkheid van één server te voorkomen. Zonder een geautomatiseerde manier om dode servers uit de rotatie te halen, is het niet erg waardevol als een manier om downtime te voorkomen. (Met een geautomatiseerde manier om servers van rotatie en een korte TTL te trekken, wordt het getto-failover. Handmatig is dat zelfs niet zo.)

Als een van uw twee round-robined-servers uitvalt, krijgt 50% van uw klanten een fout. Dit is beter dan 100% storing met slechts één server, maar bijna elke andere oplossing die echte failover deed, zou beter zijn dan dit.

Als de faalkans van één server N is, is uw kans op twee servers 2N. Zonder geautomatiseerd, snel failover, dit schema toeneemt de kans dat sommige van uw gebruikers een storing zullen ervaren.

Als u van plan bent de dode server handmatig uit de rotatie te halen, wordt u beperkt door de snelheid waarmee u dat kunt doen en de DNS TTL. Wat als de server om 4 uur 's ochtends sterft? Het beste deel van echte failover is het doorslapen van de nacht.  U gebruikt al HAProxy, dus je zou er bekend mee moeten zijn. Ik raad sterk aan het te gebruiken, want HAProxy is ontworpen voor precies deze situatie.


19
2018-01-09 03:09



volledig van het onderwerp af, maar we hebben ook het probleem dat we meerdere HAProxy-instanties nodig hebben om te falen - wat als het HAProxy-apparaat faalt? Onderwerp van toekomstige vragen, ECHT van onderwerp voor deze. - Jeff Atwood
+1 - De "Met een geautomatiseerde manier ... wordt het ghetto failover. Handmatig is dat niet eens zo." zou in grote vette letters moeten staan. DNS round-robin wordt een aansprakelijkheid als u geen machines controleert en ze verwijdert uit de DNS als ze falen, en de enige redelijke manier om dit te doen, is met een geautomatiseerde oplossing. Er zijn veel betere oplossingen dan DNS round-robin. - Evan Anderson
Helemaal mee eens, maar 20% van uw klanten belt u met klachten is meer dan 100% van hen belt met klachten .. - Jeff Atwood
Het belangrijkste punt (voor mij) dat Schof maakt bij het beantwoorden van de vraag van Jeff is dat Round Robin zonder snelle failover betekent dat je na verloop van tijd meer klanten hebt beïnvloed dan zonder, maar elk (vaker) incident heeft alleen maar een subset van klanten in plaats van allemaal. Of dit "beter" is of niet hangt af van het scenario, maar in de meeste gevallen zou ik zeggen dat het dat niet is. - Helvick
The best part of true failover is getting to sleep through the night. Dat is een duidelijke definitie! - Basil Bourque


Round Robin DNS is niet wat mensen denken dat het is. Als auteur van DNS-serversoftware (namelijk, BINDEN) krijgen we gebruikers die zich afvragen waarom hun round robin stopt met werken zoals gepland. Ze begrijpen niet dat zelfs met een TTL van 0 seconden er een bepaalde hoeveelheid caching zal zijn, omdat sommige caches een minimale tijd (vaak 30-300 seconden) maken, wat er ook gebeurt.

Ook, terwijl uw AUTH-servers round robin kunnen doen, is er geen garantie dat degene waar u om geeft - de caches waar uw gebruikers mee spreken - zullen doen. Kortom, round robin garandeert geen enkele bestelling vanuit het oogpunt van de klant, alleen wat uw auth-servers aan een cache leveren.

Als u echte failover wilt, is DNS slechts één stap. Het is geen slecht idee om meer dan één IP-adres voor twee verschillende clusters op te geven, maar ik zou daar andere technologie (zoals eenvoudige anycast) gebruiken om de feitelijke taakverdeling uit te voeren. Persoonlijk heb ik een hekel aan hardwarematige load-balancing-hardware die muckt met DNS omdat het meestal fout gaat. En vergeet niet dat DNSSEC eraan komt, dus als u iets op dit gebied kiest, vraagt ​​u uw leverancier wat er gebeurt als u uw zone ondertekent.


14
2018-01-09 10:51



en sommige DNS-servers (of de bedieningspanelen) zijn geconfigureerd om u een TTL van 7200 te geven, ongeacht waar u deze op instelt - sommige grote hostingbedrijven doen dit IIRC. - gbjbaanb


Ik heb het al een paar keer eerder gezegd en ik zeg het nog een keer - als veerkracht het probleem is, dan zijn DNS-tricks niet het antwoord.

Met de beste HA-systemen kunnen uw klanten exact hetzelfde IP-adres blijven gebruiken voor elk verzoek. Dit is de enkel en alleen manier om ervoor te zorgen dat klanten de fout niet eens opmerken.

Dus de fundamentele regel is dat echte veerkracht IP vereist routing niveau bedrog. Gebruik een load-balancer-apparaat, of OSPF "equal cost multi-path", of zelfs VRRP.

DNS aan de andere kant is een aanpakken technologie. Het bestaat alleen om in kaart te brengen van de ene naamruimte naar de andere. Het was niet ontworpen om een ​​zeer korte termijn toe te staan dynamisch wijzigingen in die toewijzing, en dus wanneer u dergelijke wijzigingen probeert door te voeren, zullen veel klanten ze niet opmerken, of in het beste geval zal het lang duren om ze op te merken.

Ik zou ook zeggen dat sinds laden is geen probleem voor u, dat u net zo goed een andere server kunt hebben die klaar is om te draaien als een warme standby. Als u een domme round-robin gebruikt, moet u proactief uw DNS-records wijzigen wanneer iets kapot gaat, dus u kunt net zo goed proactief de hot-standby-server omzetten in actie en niet verander uw DNS.


14
2018-01-09 08:55





Ik heb alle antwoorden gelezen en één ding dat ik niet heb gezien, is dat de meeste moderne webbrowsers een van de alternatieve IP-adressen proberen als een server niet reageert. Als ik het me goed herinner, zal Chrome zelfs meerdere IP-adressen proberen en doorgaan met de server die als eerste reageert. Dus naar mijn mening is het in evenwicht brengen van DNS Round Robin Load altijd beter dan niets.

BTW: Ik zie DNS Round Robin meer als een eenvoudige oplossing voor de verdeling van de belasting.


7
2018-04-29 09:28



Oeps, heb je antwoord niet gezien voordat je de mijne hebt gepost, dus een +1 voor de jouwe zodat de waarheid naar voren komt! - Yvan


Windows Vista & Windows 7 klantondersteuning voor round robin op een andere manier implementeren terwijl ze de IPv6-adreskeuze backporteerden naar IPv4. (RFC 3484)

Dus, als u een groot aantal Vista-, Windows 7- en Windows 2008-gebruikers hebt, zult u waarschijnlijk gedrag tegenkomen dat niet overeenkomt met uw geplande manier van denken in uw ersatz-oplossing voor load balancing.


4
2018-01-09 13:55



ah, dank u, uitstekend, ik was op zoek naar deze link - ik had hierover gehoord maar kon de referentie niet vinden! - Jeff Atwood


Ik ben te laat met deze draad, dus mijn antwoord zal waarschijnlijk alleen op de bodem zweven, verwaarloosd, ruiken snuiven.

Ten eerste, het juiste antwoord op de vraag is niet om de vraag te beantwoorden, maar om te zeggen:

  1. "Je wilt waarschijnlijk Windows Netwerktaakverdeling in plaats daarvan." OF
  2. "Gebruik de tijden, plaats uw statische inhoud op iets als Cloudbestanden of S3en laat een CDN dit wereldwijd spiegelen. "

NLB is volwassen, goed geschikt voor de taak en vrij eenvoudig in te stellen. Cloud-oplossingen hebben hun eigen voor- en nadelen, die buiten het bestek van deze vraag vallen.

Vraag

is round robin DNS goed genoeg als starter, beter dan niets, "terwijl we onderzoek doen en betere alternatieven implementeren" vorm van taakverdeling voor onze statische inhoud?

Tussen, zeg, 2 of 3 statische webservers? Ja, het is beter dan niets, omdat er zijn DNS-providers die DNS Round Robin zullen integreren met server health checks, en zal dode servers tijdelijk uit de DNS-records verwijderen. Dus op deze manier krijg je fatsoenlijk belastingsverdeling en sommige hoge beschikbaarheid; en het duurt allemaal minder dan 5 minuten om op te zetten.

Maar de voorbehouden die door anderen in deze thread zijn geschetst, zijn van toepassing:

  • Huidige Microsoft-browsers cachen DNS-gegevens voor 30 minuten, dus u kijkt naar meer dan 30 minuten failover-tijd voor een subset van uw gebruikers, afhankelijk van hun oorspronkelijke DNS-cachestatus.
  • Wat de gebruikers zien tijdens fail-over kan ... raar zijn (je gebruikt geen auth op statische inhoud, en zeker geen auth, maar de link toont iets om op te letten).

Andere oplossingen

HAProxy is fantastisch, maar omdat Stack Overflow zich in de Microsoft-technologiestack bevindt, kan het gebruik van de Microsoft load balancing & high availability tools minder administratieve overhead kosten. Netwerktaakverdeling zorgt voor een deel van het probleem en Microsoft heeft eigenlijk een L7 HTTP reverse proxy / load balancer nu.

Ik heb ARR nooit zelf gebruikt, maar aangezien het een tweede grote release is en afkomstig is van Microsoft, ga ik ervan uit dat het goed genoeg is getest. Het heeft gemakkelijk te begrijpen documenten, hier is er een over hoe ze het zien distributie van statische en dynamische inhoud op webnodes, en hier is een stukje over hoe te gebruiken ARR met NLB om zowel belastingverdeling als hoge beschikbaarheid te bereiken.


4
2018-02-03 02:56





Het is opmerkelijk hoeveel van de bijdragers bijdragen aan het verspreiden van disinformatie over DNS Round Robin als mechanisme voor spreiding van de belasting en veerkracht. Het werkt meestal, maar je moet wel begrijpen hoe het werkt en de fouten vermijden die worden veroorzaakt door al die desinformatie.

1) De TTL op DNS-records die voor Round Robin worden gebruikt, moet kort zijn - maar NIET NUL. Als de TTL op nul staat, verbreekt dit de belangrijkste manier waarop veerkracht wordt geboden.

2) DNS RR verspreidt zich, maar balanceert niet, het verspreidt het omdat het over een groot klantenbestand de neiging heeft de DNS-server onafhankelijk te bevragen, en zo eindigen met verschillende eerste keuze DNS-vermeldingen. Die verschillende eerste keuzes betekenen dat de clients worden onderhouden door verschillende servers en dat de belasting wordt verspreid. Maar het hangt allemaal af van welk apparaat de DNS-query uitvoert en hoelang het het resultaat bevat. Een gebruikelijk voorbeeld is dat alle clients achter een bedrijfs-proxy (die de DNS-query voor hen uitvoert) uiteindelijk allemaal op een enkele server zullen worden getarget. De belasting is gespreid - maar deze is niet gelijkmatig in balans.

3) DNS RR biedt veerkracht zolang de clientsoftware deze correct implementeert (en zowel de TTL als de aandacht van de gebruikers niet te kort is). Dit komt omdat DNS round robin een geordende lijst met server-IP-adressen levert en de clientsoftware achter elkaar moet proberen contact te leggen, totdat een server wordt gevonden die de verbinding accepteert.

Dus als de eerste keuzeserver uitvalt, wordt de TCP / IP-verbinding van de client verbroken en zolang de DDL of de aandachtspanne niet is verstreken, voert de clientsoftware een andere verbindingspoging uit naar de tweede vermelding in de lijst - en zo verder tot de TTL verloopt, of het komt aan het einde van de lijst (of de gebruiker geeft walgend op).

Een lange lijst van kapotte servers (uw fout) en grote TCP / IP connect-retry-limieten (verkeerde configuratie van de clientconfiguratie) kan een lange periode duren voordat de klant daadwerkelijk een werkende server vindt. Een te korte TTL betekent dat het nooit zijn weg naar het einde van de lijst kan vinden, en in plaats daarvan een nieuwe DNS-vraag afgeeft en een nieuwe lijst krijgt (hopelijk in een andere volgorde).

Soms krijgt de klant pech en begint de nieuwe lijst nog steeds met kapotte servers. Om het systeem de beste kans te geven om de weerbaarheid van de klant te verbeteren, moet u ervoor zorgen dat de TTL langer is dan de gebruikelijke aandachtsspanne en dat de klant de onderkant van de lijst doorloopt.

Zodra de client een werkende server heeft gevonden, moet deze deze onthouden en wanneer hij de volgende verbinding moet maken, mag hij de zoekopdracht niet herhalen (tenzij de TTL is verlopen). Een langere TTL vermindert de frequentie waarmee gebruikers een vertraging ondervinden terwijl de client zoekt naar een werkende server, waardoor een betere ervaring wordt verkregen.

4) DNS TTL komt goed tot zijn recht, wanneer u de DNS-records handmatig wilt wijzigen (bijvoorbeeld om een ​​kapotte server op de lange termijn te verwijderen), dan zorgt een korte TTL ervoor dat die wijziging zich snel verspreidt (als u er eenmaal in bent), dus houd rekening met de balans tussen hoe lang het duurt voordat je het probleem kent en maak die handmatige wijziging - en het feit dat normale clients alleen een nieuwe zoekopdracht hoeven uit te voeren naar een werkende server als de TTL verloopt.

DNS-DNS heeft twee uitstekende functies die het zeer kosteneffectief maken in een groot aantal verschillende scenario's - ten eerste is het gratis en ten tweede is het bijna net zo geografisch verspreid als uw klantenbestand.

Het introduceert geen nieuwe 'eenheid van falen' die alle andere 'slimme' systemen doen. Er zijn geen toegevoegde componenten die een gemeenschappelijke en gelijktijdige storing over een hele reeks onderling verbonden elementen zouden kunnen ervaren.

De 'slimme' systemen zijn geweldig en introduceren prachtige mechanismen om te coördineren en zorgen voor een naadloos evenwichts- en failover-mechanisme, maar uiteindelijk zijn de methoden die ze gebruiken om die naadloze ervaring te bieden hun achilleshiel - het extra gecompliceerde ding dat mis kan gaan, en wanneer dat het geval is, biedt dit een naadloze ervaring van falend systeem breed.

Dus ja, DNS Round Robin is absoluut "goed genoeg" voor je eerste stap voorbij een enkele server die al je statische inhoud op één plek host.


4
2017-08-13 13:25



En ik vergat te zeggen dat het mechanisme nogal dom is. Het werkt wanneer de server volledig faalt, maar niet wanneer het alleen maar 'nutteloos' of 'ongezond' is. Een server die HTTP 500-fouten retourneert als reactie op elk verzoek, wordt niet verwijderd uit de DNS RR-lijst en blijft het willekeurige deel van uw klantenbestand frustreren. De 'slimme' mechanismen zouden altijd een robuuste gezondheidscontrole moeten implementeren die zo'n zombie kan afschudden. - Old Fogey
Als u een goede logica hebt na de RR-DNS, retourneert u geen 500 fouten. Gebruik bijvoorbeeld Varnish met regisseurs en u kunt meerdere back-endservers ondervragen totdat één correct antwoordt. Als u RR hebt, betekent dit dat u meerdere backends heeft, dus u moet deze niet behandelen omdat ze allemaal alleen zijn. Of u moet 500 fouten controleren en automatische of handmatige maatregelen nemen wanneer dat het geval is. Maar je hebt gelijk als je erop wijst dat de webserver niet beschikbaar hoeft te zijn voor RR zodat deze door browsers kan worden verwerkt. - Yvan


Ik denk niet dat het een oplossing is die goed genoeg is, laten we zeggen dat je nu twee servers hebt en dat je robin ronddraait met DNS naar het IP-adres van elke server. Wanneer een server uitvalt, weten de DNS-servers niet dat deze is verdwenen en blijven ze dat IP-adres dienen als onderdeel van het RR-proces. Dan krijgt 50% van uw publiek een kapotte site met ontbrekende javascript of afbeeldingen.

Misschien is het gemakkelijker om naar een gemeenschappelijk IP-adres te wijzen dat wordt behandeld door Windows NLB, dat twee servers achter zich vertegenwoordigt. Tenzij je een Linux-server gebruikt voor je statische inhoud, als ik me dat ergens kan herinneren?


1
2018-01-09 03:08



NLB is alleen round-robin bij de server-NIC's in plaats van bij de DNS-server. Hiervoor op Linux wil je een HA-oplossing - RedHat heeft er een, of kijk naar UltraMonkey voor veel detail. - gbjbaanb
ik weet wat NLB doet. Ik adviseer dat over DNS RR omdat een servermislukking de helft van de gebruikers niet verlamt. - icelava
@gbjbaanb of anders gezet, NLB is round robin op laag 2. Op DNS gebaseerde round robin is op (of hangt af van) Laag 7 - Alnitak


Round-robin load balancing werkt alleen als u ook de DNS-zone in handen hebt, zodat u de lijst met servers kunt wijzigen en tijdig naar de zonemeesters kunt pushen.

Zoals vermeld in een van de andere antwoorden, is het verborgen kwaad van round-robin DNS-caching, wat overal kan gebeuren tussen uw servers en de client, waardoor het kleine voordeel van deze oplossing volledig teniet wordt gedaan. Zelfs met DNS TTL ingesteld op een zeer lage waarde, hebt u weinig controle over hoe lang ISP's of zelfs de DNS-cache van de client het nu dode IP-adres actief zal houden.

Het is zeker een verbetering ten opzichte van een SPOF, maar slechts marginaal. Ik zou eens kijken wie ooit uw server host en zien wat ze te bieden hebben, velen hebben een soort van standaard load balancer-service die ze kunnen bieden.

U kunt net zo goed een enkele server hebben met de statische inhoud gedupliceerd in S3 en overschakelen naar de S3 CNAME wanneer uw primaire niveau lager wordt. U zult eindigen met dezelfde vertraging maar zonder de meerdere serverkosten.


1
2018-01-09 03:24





Dit hangt echt af van waar je het over hebt en hoeveel servers je roteert. Ik had ooit een site die op verschillende servers draaide, en ik gebruikte DNS round robin daarover vanwege voornamelijk mijn beginneling in die tijd, en het was echt geen groot probleem. Het was geen groot probleem omdat het niet crashte. Het was een heel stom, niet-gecompliceerd systeem, dus het hield op en had een vrij constant verkeersniveau. Als het uit het verkeer crashte, was het overdag en iets waar ik gemakkelijk voor kon zorgen. Ik zou zeggen dat uw statische inhoud net zo eenvoudig genoeg is om zelf geen crashes te veroorzaken.

Buiten de hardwarefout enz., Hoe stabiel is uw server geweest? Hoe "spikey" is uw verkeer op deze inhoud? Uitgaande van Apache of iets dergelijks en relatief vlak verkeer, zal het niet veel crashen, en ik zou zeggen dat Round-Robin "goed genoeg" is.

Ik weet zeker dat ik gestemd zal worden omdat ik geen 100% HA-oplossing predik, maar dat is niet waar je om vroeg. Het komt erop neer wat u bereid bent te accepteren als een oplossing versus inspanning.


1
2018-01-09 05:14