Round-Robin DNS è "abbastanza buono" per il bilanciamento del carico del contenuto statico?

Abbiamo una serie di contenuti statici condivisi che pubblichiamo tra i nostri siti Web all'indirizzo http://sstatic.net . Sfortunatamente, al momento questo contenuto non è affatto bilanciato in base al carico: è offerto da un singolo server. Se quel server ha problemi, tutti i siti su cui si basano sono effettivamente inattivi perché le risorse condivise sono librerie e immagini javascript condivise essenziali.

Stiamo cercando dei modi per bilanciare il carico del contenuto statico su questo server, per evitare la dipendenza del singolo server.

Mi rendo conto che il DNS round robin è, nella migliore delle ipotesi, una soluzione di fascia bassa (alcuni potrebbero anche dire ghetto ), ma non posso fare a meno di chiedermi: il DNS round robin è una soluzione "abbastanza buona" per il bilanciamento del carico di base di contenuto statico ?

Si discute di questo nei tag [dns] [bilanciamento del carico] e ho letto degli ottimi post sull'argomento.

Sono a conoscenza dei lati negativi comuni del bilanciamento del carico DNS attraverso più record A round robin:

• in genere non ci sono battiti cardiaci o rilevamento degli errori con i record DNS, quindi se un determinato server nella rotazione scende, il suo record A deve essere rimosso manualmente dalle voci DNS
• il tempo necessario per vivere (TTL) deve essere necessariamente impostato su un valore abbastanza basso affinché funzioni, poiché le voci DNS sono memorizzate nella cache in modo aggressivo su Internet
• i computer client sono responsabili di vedere che ci sono più record A e di scegliere quello corretto

Ma il DNS round robin è abbastanza buono come antipasto, meglio di niente, "mentre cerchiamo e implementiamo alternative migliori" forma di bilanciamento del carico per il nostro contenuto statico? O il round robin DNS è praticamente inutile in nessun caso?

Jeff, non sono d'accordo, il bilanciamento del carico non implica ridondanza, è piuttosto il contrario. Più server hai, più è probabile che tu abbia un errore in un dato istante. Ecco perché la ridondanza è obbligatoria quando si esegue il bilanciamento del carico, ma sfortunatamente ci sono molte soluzioni che forniscono solo il bilanciamento del carico senza eseguire alcun controllo dello stato, risultando in un servizio meno affidabile.

Il roundrobin DNS è eccellente per aumentare la capacità, distribuendo il carico su più punti (potenzialmente geograficamente distribuito). Ma non fornisce il failover. È necessario innanzitutto descrivere il tipo di errore che si sta tentando di coprire. Un errore del server deve essere coperto localmente utilizzando un meccanismo di acquisizione dell'indirizzo IP standard (VRRP, CARP, ...). Un errore dello switch è coperto da collegamenti resilienti sul server a due switch. Un errore di collegamento WAN può essere coperto da un'impostazione multi-link tra te e il tuo provider, utilizzando un protocollo di routing o una soluzione layer2 (ad esempio: PPP multi-link). Un errore del sito dovrebbe essere coperto da BGP: i tuoi indirizzi IP vengono replicati su più siti e li annunci alla rete solo dove sono disponibili.

Dalla tua domanda, sembra che devi solo fornire una soluzione di failover del server, che è la soluzione più semplice poiché non coinvolge alcun hardware né contratto con alcun ISP. Devi solo installare il software appropriato sul tuo server per questo, ed è di gran lunga la soluzione più economica e affidabile.

Hai chiesto "cosa succede se una macchina haxyxy fallisce?". È lo stesso. Tutte le persone che conosco che usano haproxy per il bilanciamento del carico e l'elevata disponibilità hanno due macchine ed eseguono ucarp, keepalived o heartbeat su di esse per garantire che una di esse sia sempre disponibile.

Spero che questo aiuti!

Come bilanciamento del carico, è ghetto ma più o meno efficace. Se avevi un server che stava cadendo dal carico e volevi spargerlo su più server, questo potrebbe essere un buon motivo per farlo, almeno temporaneamente.

Ci sono una serie di valide critiche al DNS round robin come "bilanciamento del carico" e non consiglierei di farlo a parte quello come aiuto di banda a breve termine.

Ma dici che la tua motivazione principale è evitare una dipendenza a server singolo. Senza un modo automatizzato di disattivare la rotazione dei server morti, non è molto utile come modo per prevenire i tempi di inattività. (Con un modo automatizzato di estrarre i server dalla rotazione e un breve TTL, diventa failover del ghetto. Manualmente, non è nemmeno quello.)

Se uno dei due server round robined si arresta, il 50% dei clienti avrà un errore. Si tratta di un errore migliore del 100% con un solo server, ma quasi tutte le altre soluzioni che hanno eseguito un failover reale sarebbero migliori di così.

Se la probabilità di errore di un server è N, con due server la probabilità è 2N. Senza failover automatico e rapido , questo schema aumenta la probabilità che alcuni utenti riscontrino un errore.

Se prevedi di disattivare manualmente la rotazione del server morto, sei limitato dalla velocità con cui puoi farlo e dal DNS TTL. Cosa succede se il server muore alle 4 del mattino? La parte migliore del vero failover è riuscire a dormire tutta la notte. Usi già HAProxy , quindi dovresti conoscerlo. Consiglio vivamente di usarlo, poiché HAProxy è progettato proprio per questa situazione.

Il DNS round robin non è quello che la gente pensa che sia. Come autore del software server DNS (ovvero BIND ), otteniamo utenti che si chiedono perché il loro round robin smetta di funzionare come previsto. Non capiscono che anche con un TTL di 0 secondi ci sarà una certa quantità di cache là fuori, dal momento che alcune cache richiedono un tempo minimo (spesso 30-300 secondi), non importa quale.

Inoltre, mentre i server AUTH possono eseguire il round robin, non vi è alcuna garanzia che quelli a cui tieni - le cache con cui parlano gli utenti - lo faranno. In breve, round robin non garantisce alcun ordine dal punto di vista del cliente, ma solo ciò che i server di autenticazione forniscono a una cache.

Se si desidera un vero failover, DNS è solo un passo. Non è una cattiva idea elencare più di un indirizzo IP per due diversi cluster, ma utilizzerei lì altre tecnologie (come il semplice anycast) per eseguire il bilanciamento del carico effettivo. Personalmente disprezzo l'hardware di bilanciamento del carico hardware che si confonde con il DNS come di solito lo sbaglia. E non dimenticare che DNSSEC sta arrivando, quindi se scegli qualcosa in quest'area chiedi al tuo rivenditore cosa succede quando firmi la tua zona.

L'ho già detto più volte e lo ripeto: se il problema è la resilienza, i trucchi DNS non sono la risposta .

I migliori sistemi HA consentiranno ai tuoi clienti di continuare a utilizzare lo stesso indirizzo IP esatto per ogni richiesta. Questo è l' unico modo per garantire che i clienti non notino nemmeno l'errore.

Quindi la regola fondamentale è che la vera resilienza richiede un trucco a livello di routing IP . Utilizzare un dispositivo di bilanciamento del carico o OSPF "multi-path a costo uguale" o persino VRRP.

Il DNS d'altra parte è una tecnologia di indirizzamento . Esiste solo per mappare da uno spazio dei nomi a un altro. Non è stato progettato per consentire modifiche dinamiche a brevissimo termine a tale mappatura, e quindi quando si tenta di apportare tali modifiche molti clienti non le noteranno o, nella migliore delle ipotesi, impiegheranno molto tempo a notarle.

Direi anche che poiché il caricamento non è un problema per te, potresti anche avere un altro server pronto per l'esecuzione come hot standby. Se usi il round robin stupido devi cambiare in modo proattivo i tuoi record DNS quando qualcosa si rompe, quindi potresti anche attivare in modo proattivo il server hot standby e non cambiare il tuo DNS.

Ho letto tutte le risposte e una cosa che non ho visto è che la maggior parte dei browser Web moderni proverà uno degli indirizzi IP alternativi se un server non risponde. Se ricordo bene, Chrome proverà anche con più indirizzi IP e continuerà con il server che risponde per primo. Quindi, secondo me, DNS Round Robin Il bilanciamento del carico è sempre meglio di niente.

A proposito: vedo DNS Round Robin più come una semplice soluzione di distribuzione del carico.

Sono in ritardo su questa discussione, quindi la mia risposta probabilmente rimarrà da sola in fondo, trascurata, annusando.

Prima di tutto, la risposta giusta alla domanda non è quella di rispondere alla domanda, ma di dire:

1. "Probabilmente vuoi invece il bilanciamento del carico di rete di Windows ." O
2. "Vai al passo con i tempi, posiziona i tuoi contenuti statici su qualcosa come Cloud Files o S3 e fai in modo che un CDN rispecchi in tutto il mondo."

Bilanciamento carico di rete è maturo, ben adattato al compito e abbastanza facile da configurare. Le soluzioni cloud vengono fornite con i loro pro e contro, che non rientrano nell'ambito di questa domanda.

Domanda

DNS round robin è abbastanza buono come antipasto, meglio di niente, "mentre cerchiamo e implementiamo alternative migliori" forma di bilanciamento del carico per il nostro contenuto statico?

Tra, diciamo, 2 o 3 server web statici? Sì, è meglio di niente, perché ci sono provider DNS che integreranno DNS Round Robin con i controlli di integrità del server e rimuoveranno temporaneamente i server morti dai record DNS. In questo modo si ottiene una distribuzione del carico decente e una disponibilità elevata; e tutto richiede meno di 5 minuti per l'installazione.

Ma si applicano le avvertenze delineate da altri in questo thread:

• I browser Microsoft attuali memorizzano nella cache i dati DNS per 30 minuti , quindi stai cercando più di 30 minuti di tempo di failover per un sottoinsieme dei tuoi utenti, a seconda del loro stato iniziale della cache DNS.
• Ciò che gli utenti vedono durante il failover può essere ... strano (non stai usando auth su contenuto statico, e certamente non si tratta di auth, ma il link mostra qualcosa a cui fare attenzione).

Altre soluzioni

HAProxy è fantastico, ma dal momento che Stack Overflow è nello stack della tecnologia Microsoft, forse utilizzando gli strumenti di bilanciamento del carico e disponibilità elevata di Microsoft si avrà un minore carico amministrativo. Il bilanciamento del carico di rete si occupa di una parte del problema e Microsoft ha attualmente un proxy inverso / bilanciamento del carico HTTP L7 ora.

Non ho mai usato l'ARR da solo, ma dato che è alla sua seconda versione principale, e proveniente da Microsoft, presumo che sia stato testato abbastanza bene. Ha documenti di facile comprensione , qui c'è uno su come vedono la distribuzione di contenuti statici e dinamici sui webnode, ed ecco un pezzo su come usare l' ARR con NLB per ottenere sia la distribuzione del carico sia l'elevata disponibilità.

È notevole il numero di partecipanti che stanno contribuendo a contribuire all'informazione sul DNS Round Robin come meccanismo di ripartizione del carico e di resilienza. Di solito funziona, ma devi capire come funziona ed evitare gli errori causati da tutta quella disinformazione.

1) Il TTL sui record DNS utilizzati per Round robin dovrebbe essere breve, ma NON ZERO. Avere il TTL a zero interrompe il modo principale in cui viene fornita la resilienza.

2) DNS RR si diffonde, ma non bilancia il carico, lo diffonde perché su una base client di grandi dimensioni, tendono a interrogare il server DNS in modo indipendente e quindi finiscono con voci DNS di prima scelta diverse. Queste diverse prime scelte indicano che i client sono serviti da server diversi e il carico è ripartito. Ma tutto dipende da quale dispositivo sta eseguendo la query DNS e da quanto tempo conserva il risultato. Un esempio comune è che tutti i client dietro un proxy aziendale (che esegue la query DNS per loro) finiranno per colpire un singolo server. Il carico è distribuito, ma non è bilanciato in modo uniforme.

3) DNS RR offre resilienza fintanto che il software client lo implementa correttamente (e sia il TTL che l'intervallo di attenzione degli utenti non sono troppo brevi). Questo perché il round robin DNS fornisce un elenco ordinato di indirizzi IP del server e il software client dovrebbe tentare di contattare ciascuno di essi a turno, fino a quando non trova un server che accetta la connessione.

Pertanto, se il server di prima scelta è inattivo, la connessione TCP / IP del client scade e non è scaduto il TTL o l'intervallo di attenzione, quindi il software client tenta di eseguire un'altra connessione alla seconda voce dell'elenco e così via fino a quando il Il TTL scade o arriva alla fine della lista (o l'utente si arrende disgustato).

Un lungo elenco di server danneggiati (colpa tua) e limiti di tentativi di connessione TCP / IP di grandi dimensioni (malfunzionamento della configurazione del client) possono essere fatti per un lungo periodo prima che il client trovi effettivamente un server funzionante. Un TTL troppo breve significa che non riesce mai a raggiungere la fine dell'elenco e invece genera una nuova query DNS e riceve un nuovo elenco (si spera in un ordine diverso).

A volte il client diventa sfortunato e il nuovo elenco inizia ancora con server non funzionanti. Per offrire al sistema le migliori possibilità di fornire resilienza al cliente, è necessario assicurarsi che il TTL sia più lungo dell'intervallo di attenzione tipico e che il cliente arrivi in ​​fondo all'elenco.

Una volta che il client ha trovato un server funzionante, dovrebbe ricordarselo e quando deve effettuare la connessione successiva non dovrebbe ripetere la ricerca (a meno che il TTL non sia scaduto). Un TTL più lungo riduce la frequenza con cui gli utenti subiscono un ritardo mentre il client cerca un server funzionante, offrendo un'esperienza migliore.

4) Il DNS TTL si presenta da solo, quando si desidera modificare manualmente i record DNS (ad esempio per rimuovere un server danneggiato a lungo termine), un breve TTL consente a tale modifica di propagarsi rapidamente (una volta che si è in procinto di farlo), quindi considerare l'equilibrio tra quanto tempo ci vorrà prima di conoscere il problema e apportare quella modifica manuale - e il fatto che i client normali dovranno fare una nuova ricerca per un server funzionante alla scadenza del TTL.

Il round robin DNS ha due eccezionali funzionalità che lo rendono molto conveniente in una vasta gamma di scenari: in primo luogo è gratuito e in secondo luogo è quasi geograficamente disperso come la tua base di clienti.

Non introduce una nuova "unità di errore", come fanno tutti gli altri sistemi "intelligenti". Non ci sono componenti aggiunti che potrebbero verificarsi un errore comune e simultaneo su un intero carico di elementi interconnessi.

I sistemi "intelligenti" sono fantastici e introducono meravigliosi meccanismi per coordinare e fornire un meccanismo di bilanciamento e failover senza soluzione di continuità, ma alla fine gli stessi metodi che usano per fornire quell'esperienza senza soluzione di continuità sono il loro tallone d'Achille - la cosa complicata aggiuntiva che può andare storta, e quando lo farà, fornirà un'esperienza senza soluzione di continuità a livello di sistema.

Quindi SÌ, il round robin DNS è sicuramente "abbastanza buono" per il tuo primo passo oltre un singolo server che ospita tutti i tuoi contenuti statici in un unico posto.

Windows Vista e Windows 7 implementano il supporto client per il round robin in modo diverso quando eseguivano il backport della selezione dell'indirizzo IPv6 su IPv4. ( RFC 3484 )

Quindi, se hai un numero significativo di utenti Vista, Windows 7 e Windows 2008, probabilmente troverai comportamenti incompatibili con il tuo pensiero pianificato nella tua soluzione di bilanciamento del carico ersatz.

Ho sempre usato DNS Round-Robin, con un lungo TTL, come bilanciamento del carico. Funziona davvero bene per i servizi HTTP / HTTPS con i browser .

Mi stresso molto con i browser poiché la maggior parte dei browser implementa una sorta di "riprova su un altro IP", ma non so come altre biblioteche o software gestiranno la soluzione IP multipla.

Quando il browser non riceve una risposta da un server, chiamerà automaticamente il prossimo IP, quindi si attaccherà con esso (fino a quando non è inattivo ... e quindi prova un altro).

Nel 2007, ho fatto il seguente test:

• aggiungere un iframe sul mio sito Web, indicando una voce Round-Robin, come ad esempio http://roundrobin.test:10080/ping.php
• la pagina era servita da 3 socket PHP, in ascolto su 3 IP diversi, tutti sulla porta 10080 (non potevo permettermi di testare sulla porta 80, poiché il mio sito Web era in esecuzione su di essa)
• un socket (diciamo A ) era lì per verificare che il browser potesse connettersi sulla porta 10080 (poiché molte aziende consentono solo porte standard)
• altri due socket (diciamo B e C ) potrebbero essere abilitati o disabilitati al volo.

L'ho lasciato funzionare un'ora, avevo molti dati. I risultati furono che per il 99,5% degli hit sul socket A , ho avuto un hit su entrambi i socket B o C (ovviamente non li ho disabilitati entrambi contemporaneamente). I browser erano: iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3 / 3.5 ... Quindi anche i browser non conformi lo stavano gestendo correttamente!

Fino ad oggi, non l'ho mai più testato, ma forse un giorno configurerò un nuovo test o rilascerò il codice su github in modo che altri possano provarlo.

Nota importante: anche se è di lavoro la maggior parte del tempo, non rimuove il fatto che alcune richieste potranno fallire. Lo uso anche per richieste POST, poiché la mia applicazione restituirà un messaggio di errore nel caso in cui non funzioni, in modo che l'utente possa inviare nuovamente i dati e molto probabilmente il browser utilizzerà un altro IP in questo caso e il salvataggio funzionerà . E per i contenuti statici, funziona davvero alla grande.

Quindi, se lavori con i browser, usa Round-Robin DNS, sia per contenuti statici che dinamici, per lo più andrà bene. I server possono anche scendere nel mezzo di una transazione e anche con il miglior bilanciamento del carico non è possibile gestire un caso del genere. Per i contenuti dinamici, devi rendere le tue sessioni / database / file sincroni, altrimenti non sarai in grado di gestirlo (ma questo è vero anche con un vero bilanciamento del carico).

Nota aggiuntiva: è possibile testare il comportamento sul proprio IP utilizzando iptables. Ad esempio, prima della regola del firewall per il traffico HTTP, aggiungi:

iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT

(dov'è 12.34.56.78ovviamente il tuo IP)

Non utilizzare DROP, in quanto lascia la porta filtrata e il browser attenderà fino al timeout. Quindi ora puoi abilitare o disabilitare un server o l'altro. Il test più ovvio è disabilitare il server A, caricare la pagina, quindi abilitare il server A e disabilitare il server B. Quando caricherai di nuovo la pagina, vedrai una piccola attesa dal browser, quindi verrà caricata dal server A ancora. In Chrome, puoi confermare l'IP del server osservando la richiesta nel pannello di rete. Nella Generalscheda di Headers, vedrai un'intestazione falsa denominata Remote Address:. Questo è l'IP da cui hai ricevuto una risposta.

Quindi, se devi passare in modalità di manutenzione su un server, disabilita semplicemente il traffico HTTP / HTTPS con una iptables REJECTregola, tutte le richieste andranno ad altri server (con una piccola attesa, quasi impercettibile per gli utenti).

Non penso che sia una soluzione abbastanza buona perché supponiamo che tu abbia due server ora e round robin usando DNS per l'indirizzo IP di ciascun server. Quando un server si arresta, i server DNS non sono a conoscenza della caduta e continueranno a servire quell'indirizzo IP, come parte del processo RR. Quindi il 50% del tuo pubblico riceverà un sito danneggiato senza javascript o immagini.

Forse è più semplice puntare a un indirizzo IP comune gestito da NLB di Windows che rappresenta due server dietro. A meno che tu non stia usando un server Linux per il tuo contenuto statico, se ricordo di averlo letto da qualche parte?

Il bilanciamento del carico round robin funziona solo quando si ha anche il controllo della zona DNS in modo da poter modificare l'elenco dei server e inviarlo ai master di zona in modo tempestivo.

Come menzionato in una delle altre risposte, il male nascosto del round-robin è la memorizzazione nella cache DNS che può verificarsi in qualsiasi punto tra i server e il client e che nega completamente il piccolo vantaggio di questa soluzione. Anche con DNS TTL impostato su un valore molto basso, si ha uno scarso controllo su quanto a lungo ISP o anche la cache DNS del client manterrà attivo l'indirizzo IP ormai morto.

È sicuramente un miglioramento rispetto a uno SPOF, ma solo marginale. Vorrei dare un'occhiata a chi mai ospita il tuo server e vedere cosa hanno da offrire, molti hanno una sorta di servizio di bilanciamento del carico di base che possono fornire.

Potresti anche avere un singolo server con il contenuto statico duplicato in S3 e passare al CNAME S3 quando il tuo primario non funziona. Ti ritroverai con lo stesso ritardo ma senza il costo di più server.

Dipende molto da cosa stai parlando e da quanti server stai ruotando. Una volta avevo un sito che girava su più server e su questo usavo il round robin DNS a causa principalmente del mio novizio all'epoca, e in realtà non era un grosso problema. Non è stato un grosso problema perché non si è bloccato. Era un sistema davvero stupido, non complicato, quindi resistette e aveva un livello di traffico piuttosto costante. Se si è schiantato dal traffico, è stato durante il giorno e qualcosa di cui potrei facilmente occuparmi. Direi che i tuoi contenuti statici sono abbastanza semplici da non causare arresti anomali da soli.

A parte guasti hardware ecc., Quanto è stato stabile il tuo server? Quanto è "spikey" il tuo traffico su questi contenuti? Supponendo che Apache o qualcosa del genere e il traffico relativamente piatto, non si arresteranno molto, e direi che il round robin è "abbastanza buono".

Sono sicuro che mi voterò perché non sto predicando una soluzione HA al 100%, ma non è quello che mi hai chiesto. Dipende da ciò che sei disposto ad accettare come soluzione rispetto allo sforzo speso.

Se si utilizza RR DNS per il bilanciamento del carico, andrebbe bene, ma non lo è. Lo stai usando per abilitare un server ridondante, nel qual caso non va bene.

Come diceva un post precedente, hai bisogno di qualcosa per rilevare il battito cardiaco e smettere di colpirlo fino a quando non torna.

La buona notizia è che il battito cardiaco è disponibile davvero a buon mercato, sia negli switch che in Windows.

Non so di altri sistemi operativi, ma presumo che sia anche lì.

Ti suggerisco di assegnare un indirizzo IP aggiuntivo a ciascuno dei tuoi server (oltre all'IP statico che usi per, diciamo, ssh), e di prenderlo nel pool DNS. E poi usi alcuni software per cambiare questi indirizzi IP nel caso in cui un server fallisca. Heartbeat o CARP possono farlo, ad esempio, ma ci sono altre soluzioni là fuori.

Questo ha il vantaggio che per i clienti del tuo servizio, nulla deve cambiare nell'impostazione e non devi preoccuparti della memorizzazione nella cache DNS o del TTL, ma puoi comunque sfruttare il "bilanciamento del carico" del round robin DNS .

Probabilmente farà il lavoro, soprattutto se puoi avere più IP nelle tue caselle statiche. avere un IP "serve contenuto statico" e un IP "gestisci macchina". Se una casella si abbassa, è possibile utilizzare una soluzione HA esistente o un intervento manuale per portare l'IP dalla macchina guasta su uno degli altri "membri del cluster" o su una macchina completamente nuova (a seconda della velocità con cui sarebbe per farlo funzionare).

Tuttavia, tale soluzione avrà alcuni piccoli problemi. Il bilanciamento del carico non sarà da nessuna parte vicino alla perfezione e se ti affidi all'intervento manuale potresti avere interruzioni per alcuni visitatori.

Un bilanciamento del carico hardware può probabilmente svolgere un lavoro migliore sia condividendo il carico sia fornendo "uptime del cluster" rispetto al round robin DNS. D'altro canto, questo è uno (o due, poiché idealmente hai gli LB in un cluster HA) pezzi di hardware che avranno bisogno di acquisto, alimentazione e raffreddamento e (possibilmente) un po 'di tempo per familiarizzare (se non lo hai già fatto) hanno bilanciatori di carico dedicati).

Per rispondere in modo succinto alla domanda (il round robin DNS è abbastanza buono come antipasto, meglio di niente, "mentre cerchiamo e implementiamo alternative migliori" forma di bilanciamento del carico per il nostro contenuto statico?), Direi che è meglio di niente, ma dovresti assolutamente continuare a ricercare altre forme di bilanciamento del carico.

Durante la ricerca di Windows Load Balancing diversi anni fa, ho visto un documento in cui si affermava che la Web farm di Microsoft era configurata come più gruppi di bilanciamento del carico, con round robin DNS tra di loro. Poiché è possibile avere più server DNS che rispondono in ogni spazio dei nomi e poiché il bilanciamento del carico di Microsoft è autorigenerante, ciò fornisce sia ridondanza che bilanciamento del carico.

Unico inconveniente: sono necessari almeno 4 server (2 server x 2 gruppi).

Rispondendo al commento di Jeff sulla risposta di Schof, c'è un modo per il round robin DNS tra i server HAProxy?

Ha un uso molto marginale, abbastanza per farti passare mentre metti in atto una soluzione reale. Come dici tu, i TTL devono essere impostati piuttosto bassi. Questo ha il vantaggio secondario, tuttavia, di estrarre una macchina problematica dal DNS mentre si verificano problemi. Supponi di avere SvrA, SvrB e SvrC che distribuiscono i tuoi contenuti e SvrA diminuisce. Lo estrai dal DNS e dopo il breve periodo di tempo definito dal tuo TTL basso, i resolver scopriranno un server diverso (SvrB o SvrC) che è attivo. Ottieni SvrA di nuovo online e reinseriscilo in DNS. Un breve periodo di inattività per alcune persone, nessuno per altri. Non eccezionale, ma praticabile. Più server statici vengono inseriti nel mix, meno è probabile che si avrà la maggioranza dei gruppi di utenti inattivo.

Certamente non otterrai la vera distribuzione bilanciata che una vera soluzione di bilanciamento del carico fornirà a causa della topologia di Internet. Continuerei a guardare il carico su tutti i server coinvolti.