100% di uptime per un'applicazione web

Oggi abbiamo ricevuto un "requisito" interessante da un cliente.

Vogliono il 100% di uptime con il failover off-site in un'applicazione web. Dal punto di vista della nostra applicazione Web, questo non è un problema. È stato progettato per essere scalabile su più server di database, ecc.

Tuttavia, da un problema di rete non riesco proprio a capire come farlo funzionare.

In breve, l'applicazione vivrà su server all'interno della rete del client. Vi si accede da persone sia interne che esterne. Vogliono che conserviamo una copia off-site del sistema che, in caso di un grave guasto nelle loro sedi, riprenderebbe immediatamente e subentrerebbe.

Ora sappiamo che non c'è assolutamente modo di risolverlo per le persone interne (piccione viaggiatore?), Ma vogliono che gli utenti esterni non se ne accorgano nemmeno.

Francamente, non ho la più pallida idea di come ciò sia possibile. Sembra che se perdono la connettività Internet, dovremmo fare una modifica DNS per inoltrare il traffico ai computer esterni ... Il che, ovviamente, richiede tempo.

Idee?

AGGIORNARE

Ho avuto una discussione con il cliente oggi e hanno chiarito la questione.

Hanno bloccato il numero del 100%, dicendo che l'applicazione dovrebbe rimanere attiva anche in caso di alluvione. Tuttavia, tale requisito entra in gioco solo se lo ospitiamo per loro. Hanno detto che avrebbero gestito il requisito di uptime se l'applicazione vivesse interamente sui loro server. Puoi indovinare la mia risposta.

Ecco il pratico diagramma di Wikipedia sulla ricerca di nove:

È interessante notare che solo 3 dei 20 migliori siti Web sono stati in grado di raggiungere i mitici 5 nove o il 99,999% di uptime nel 2007. Erano Yahoo, AOL e Comcast. Nei primi 4 mesi del 2008, alcuni dei social network più popolari non si sono nemmeno avvicinati a questo.

Dal grafico, dovrebbe essere evidente quanto sia ridicolo il perseguimento del 100% di uptime ...

Chiedi loro di definire il 100% e come verrà misurato in quale periodo di tempo. Probabilmente significano il 100% più vicino possibile. Dai loro i costi.

Elaborare. Nel corso degli anni ho discusso con clienti con requisiti apparentemente ridicoli. In tutti i casi, in realtà stavano solo usando un linguaggio abbastanza preciso.

Abbastanza spesso inquadrano le cose in modo che appaiano assolute, come il 100%, ma in realtà a un'indagine più approfondita sono abbastanza ragionevoli da eseguire le analisi costi / benefici necessarie quando presentate con i costi per i dati di mitigazione del rischio. Chiedere loro come misureranno la disponibilità è una domanda cruciale. Se non lo sanno, allora sei in grado di suggerire loro che questo deve essere definito per primo.

Chiederei al cliente di definire cosa succederebbe in termini di impatto / costi aziendali se il sito non funzionasse nelle seguenti circostanze:

• Nelle ore più trafficate per x ore
• Nelle ore meno impegnative per x ore

E anche come lo misureranno.

In questo modo puoi lavorare con loro per determinare il giusto livello di "100%". Sospetto che ponendo questo tipo di domande saranno in grado di determinare meglio le priorità degli altri requisiti. Ad esempio, potrebbero voler pagare determinati livelli di SLA e compromettere altre funzionalità per raggiungere questo obiettivo.

I tuoi clienti sono pazzi. Il 100% di tempo di attività è impossibile, indipendentemente dalla quantità di denaro che ci spendi. Chiaro e semplice - impossibile. Guarda Google, Amazon, ecc. Hanno una quantità quasi infinita di soldi da buttare nella loro infrastruttura e tuttavia riescono ancora ad avere tempi di inattività. Devi consegnare loro quel messaggio e se continuano a insistere sul fatto che offrono richieste ragionevoli. Se non riconoscono che un certo tempo di inattività è inevitabile, allora abbandonali.

Detto questo, sembra che tu abbia la meccanica per ridimensionare / distribuire l'applicazione stessa. La parte di rete dovrà coinvolgere uplink ridondanti a diversi ISP, ottenere un'allocazione ASN e IP e approfondire BGP e dispositivi di routing reali in modo che lo spazio degli indirizzi IP possa spostarsi tra gli ISP, se necessario.

Questa è, ovviamente, una risposta molto concisa. Non hai avuto esperienza con applicazioni che richiedono questo grado di uptime, quindi devi davvero coinvolgere un professionista se vuoi avvicinarti al mitico uptime del 100%.

Bene, questo è sicuramente interessante. Non sono sicuro che vorrei essere contrattualmente obbligato al 100% di uptime, ma se dovessi, penso che sarebbe simile a questo:

Inizia con l'IP pubblico su un servizio di bilanciamento del carico completamente fuori dalla rete e creane almeno due in modo che uno possa eseguire il failover sull'altro. Un programma come Heatbeart può aiutare con il failover automatico di quelli.

Lo smalto è principalmente noto come soluzione di memorizzazione nella cache, ma offre anche un bilanciamento del carico molto decente. Forse sarebbe una buona scelta per gestire il bilanciamento del carico. Può essere impostato per avere da 1 a n gruppi opzionalmente raggruppati in registi che caricheranno il saldo in modo casuale o round robin. La vernice può essere resa abbastanza intelligente da controllare la salute di ogni back-end e far cadere i back-malsani fuori dal circuito fino a quando non torna online. I backend non devono essere sulla stessa rete.

Sono un po 'innamorato degli IP elastici in Amazon EC2 in questi giorni, quindi probabilmente costruirò i miei bilanciatori di carico in EC2 in diverse regioni o almeno in diverse zone di disponibilità nella stessa regione. Ciò ti darebbe la possibilità di far girare manualmente un nuovo bilanciamento del carico (se non lo vuoi) se fosse necessario e spostare l'IP del record A esistente nella nuova casella.

Varnish, tuttavia, non può terminare SSL, quindi se questa è una preoccupazione potresti voler esaminare qualcosa come Nginx.

Potresti avere la maggior parte dei tuoi backend nella tua rete di client e uno o più al di fuori della loro rete. Credo, ma non sono sicuro al 100%, che tu possa dare la priorità ai backend in modo che le macchine dei tuoi clienti ricevano la priorità fino a quando tutte diventeranno malsane.

È da lì che inizierei se avessi questo compito e senza dubbio lo perfezionerei mentre procedo.

Tuttavia, come afferma @ErikA, è Internet e ci saranno sempre parti della rete che sono al di fuori del tuo controllo. Ti consigliamo di assicurarti che il tuo legale ti leghi solo a cose che sono sotto il tuo controllo.

Nessun problema, anche se la formulazione del contratto è leggermente rivista:

... garantiscono un tempo di attività del 100% (arrotondato a zero decimali).

Se Facebook e Amazon non possono farlo, allora non puoi. E 'così semplice.

Per aggiungere la risposta di oconnore da Hacker News

Non capisco quale sia il problema. Il cliente vuole che tu pianifichi un disastro e non sono orientati alla matematica, quindi chiedere una probabilità del 100% suona ragionevole. L'ingegnere, come gli ingegneri sono inclini a fare, ha ricordato il suo primo giorno di prob & stat 101, senza considerare che il cliente potrebbe non farlo. Quando dicono questo, non stanno pensando all'inverno nucleare, stanno pensando a Fred che scarica il suo caffè sul server dell'ufficio, a un disco che si blocca o a un ISP che cade. Inoltre, puoi farlo. Con server indipendenti, geograficamente distinti, indipendenti, non avrai praticamente tempi di inattività. Con 3 server che funzionano con un'affidabilità indipendente (1) tre 9, con buone modalità di failover, i tempi di inattività previsti sono inferiori a un secondo all'anno (2). Anche se questo accade tutto in una volta, sei ancora all'interno di un ragionevole SLA per le connessioni web, e quindi i tempi di inattività praticamente non esistono. Il cliente deve ancora gestire gli scenari del giorno del giudizio, ma Godzilla escluso, avrà un servizio "sempre" attivo.

(1) Un server a Los Angeles è ragionevolmente indipendente dal server di Boston, ma sì, capisco che c'è un incrocio che coinvolge la guerra nucleare, gli hacker cinesi che si infrangono sulla rete elettrica, ecc. Non credo che il tuo cliente sarà sconvolto da Questo.

(2) Il failover DNS potrebbe aggiungere alcuni secondi. Sei ancora in uno scenario in cui il cliente deve ritentare una richiesta una volta all'anno, che è, ancora una volta, entro un ragionevole SLA e non viene generalmente considerato nella stessa ottica di "downtime". Con un'applicazione che reindirizza automaticamente a un nodo disponibile in caso di errore, questo può essere impercettibile.

Ti viene chiesto qualcosa di impossibile.

Esamina le altre risposte qui, siediti con il tuo cliente e spiega PERCHÉ è impossibile e misura la loro risposta.

Se insistono ancora sul tempo di attività al 100%, informali educatamente che non può essere fatto e declinano il contratto. Non soddisferai mai la loro domanda e se il contratto non fa schifo, verrai infilato con delle penalità.

Prezzo di conseguenza, quindi stabilire nel contratto che eventuali tempi di fermo oltre lo SLA saranno rimborsati al tasso che stanno pagando.

L'ISP nel mio ultimo lavoro lo ha fatto. Abbiamo scelto una linea DSL "normale" con un uptime del 99,9% per $ 40 / mese, o un trio di T1 legato con un uptime del 99,99% per $ 1100 / mese. Ci sono state interruzioni frequenti di oltre 10 ore al mese, che hanno portato il loro tempo di attività ben al di sotto del DSL $ 40 / mo, ma siamo stati rimborsati solo circa $ 15 o giù di lì, perché è così che la tariffa all'ora * ore è finita a. Hanno capito come banditi dall'accordo.

Se addebiti $ 450.000 al mese per un uptime del 100% e raggiungi solo il 99,999%, dovrai rimborsarli di $ 324. Sono disposto a scommettere che i costi dell'infrastruttura per raggiungere il 99,999% si aggirano intorno ai $ 45.000 al mese ipotizzando colos completamente distribuiti, uplink multipli di livello 1, hardware di fantasia, ecc.

Se i professionisti si chiedono se la disponibilità del 99,999% [sia] mai una possibilità pratica o finanziariamente fattibile , la disponibilità del 99,9999% è ancora meno possibile o pratica. Per non parlare del 100%.

Non raggiungerai l'obiettivo di disponibilità al 100% per un lungo periodo di tempo. Potresti cavartela per una settimana o un anno, ma poi succederà qualcosa e sarai ritenuto responsabile. La caduta può variare dalla reputazione danneggiata (hai promesso, non hai consegnato) alla bancarotta dalle multe contrattuali.

Esistono due tipi di persone che richiedono il 100% di uptime:

1. Persone senza alcuna conoscenza di computer, sistemi informatici o Internet. *
2. Coloro che si stanno intenzionalmente facendo un culo da soli, sia per testare la tua capacità di dire di no (Google "il test del succo d'arancia"), o cercando di ottenere un qualche tipo di leva contrattuale SLA per uscire dal pagamento in seguito.

Il mio consiglio, dopo aver subito entrambi questi tipi di clienti in molte occasioni, è di non prendere questo cliente. Lascia che faccia impazzire qualcun altro.

* Questa stessa persona potrebbe non avere imbarazzo quando si informa su viaggi più veloci della luce, moto perpetuo, fusione fredda, ecc.

Vorrei comunicare con il cliente per stabilire con loro cosa significhi esattamente il 100% di uptime. È possibile che non vedano realmente una distinzione tra uptime del 99% e uptime del 100%. Per la maggior parte delle persone (cioè non amministratori del server) quei due numeri sono uguali.

100% di uptime?

Ecco cosa ti serve:

Server DNS multipli (e ridondanti) che puntano a più siti in tutto il mondo, con SLA adeguati con ciascun ISP.

Assicurarsi che i server DNS siano impostati correttamente, con TTL riconosciuto in modo efficace.

Questo è facile. Lo SLA Amazon EC2 afferma chiaramente:

La "percentuale di uptime annuale" viene calcolata sottraendo dal 100% la percentuale di periodi di 5 minuti durante l'anno di servizio in cui Amazon EC2 era nello stato di "Regione non disponibile".

http://aws.amazon.com/ec2-sla/

Definisci semplicemente "uptime" come relativo all'intero pacchetto di servizi che puoi effettivamente mantenere operativo il 100% delle volte e non dovresti avere problemi.

Inoltre, vale la pena sottolineare che l'intero punto di uno SLA è definire quali sono i tuoi obblighi e cosa succede se non riesci a soddisfarli. Non importa se il cliente richiede 3 o 5 o un milione di nove: la domanda è cosa ottengono quando / se non riesci a consegnare. La risposta ovvia è fornire un elemento pubblicitario per il 100% di uptime a 5 volte il prezzo che desideri addebitare, e quindi riceveranno un rimborso 4x se non raggiungi tale obiettivo. Potresti segnare!

Le modifiche DNS richiedono tempo solo se sono configurate per richiedere tempo. È possibile impostare il TTL su un record su un secondo: l'unico problema sarebbe quello di garantire una risposta tempestiva alle query DNS e che i server DNS possano far fronte a quel livello di query.

Questo è esattamente il modo in cui GTM funziona nel Big IP F5: il DNS TTL per impostazione predefinita è impostato su 30 secondi e se un membro del cluster deve subentrare, il DNS viene aggiornato e il nuovo IP viene acquisito quasi immediatamente. Un massimo di 30 secondi di interruzione, ma questo è il caso limite, la media sarebbe di 15 secondi.

Sai che è impossibile.

Senza dubbio il cliente si concentra sul vedere "100%", quindi il meglio che puoi fare è promettere il 100%, tranne per [tutte le ragionevoli cause che non sono colpa tua].

Anche se dubito che sia possibile il 100%, potresti voler considerare Azure (o qualcosa con uno SLA simile) come una possibilità. Che succede:

I tuoi server sono macchine virtuali. In caso di problemi hardware su un server, la macchina virtuale viene spostata su una nuova macchina. Il bilanciamento del carico si occupa del reindirizzamento, quindi il cliente non dovrebbe vedere alcun tempo di inattività (anche se non sono sicuro di come il tuo stato delle sessioni sarebbe influenzato).

Detto questo, anche con questo fail-over, la differenza tra 99.999 e 100 confina con la follia.

Dovrai avere il pieno controllo dei seguenti fattori.
- Fattori umani, sia interni che esterni, sia cattiveria che impotenza. Un esempio di questo è qualcuno che spinge qualcosa nel codice di produzione che porta giù un server. Ancora peggio, che dire del sabotaggio?
- Problemi commerciali. Che cosa succede se il tuo fornitore si spegne per affari o dimentica di pagare le bollette elettriche o semplicemente decide di smettere di supportare la tua infrastruttura senza un preavviso sufficiente?
- Natura. E se i tornado non correlati colpissero contemporaneamente abbastanza data center per sopraffare la capacità di backup?
- Un ambiente completamente privo di bug. Sei sicuro che non ci sia un caso limite con qualche controllo di sistema di terze parti o core che non si è manifestato ma potrebbe ancora farlo in futuro?
- Anche se hai il pieno controllo dei suddetti fattori, sei sicuro che il monitoraggio del software / persona non ti presenterà falsi negativi quando verifichi se il tuo sistema è attivo?

Onestamente il 100% è completamente pazzo senza almeno una vacillazione in termini di un attacco di hacking. La tua scommessa migliore è fare ciò che fanno Google e Amazon in quanto hai una soluzione di hosting geo-distribuita in cui hai il tuo sito e DB replicati su più server in più posizioni geografiche. Questo lo garantirà in tutto tranne che in un grave disastro come la spina dorsale di Internet che viene tagliata in una regione (cosa che succede di tanto in tanto) o qualcosa di quasi apocalittico.

Vorrei inserire una clausola proprio per questi casi (DDOS, taglio della spina dorsale di Internet, attacco terroristico apocalittico o una grande guerra, ecc.).

Oltre a ciò, cerca nei servizi cloud Amazon S3 o Rackspace. Fondamentalmente la configurazione del cloud non offrirà solo la ridondanza in ogni posizione, ma anche la scalabilità e la geo-distribuzione del traffico insieme alla capacità di reindirizzare intorno a aree geografiche fallite. Anche se la mia comprensione è che la geo-distribuzione costa più denaro.

Volevo solo aggiungere un'altra voce al "si può partito (teoricamente) essere fatto".

Non prenderei un contratto che avesse specificato questo, non importa quanto mi pagassero, ma come problema di ricerca ha alcune soluzioni piuttosto interessanti. Non ho abbastanza familiarità con la rete per delineare i passaggi, ma immagino che una combinazione di configurazioni relative alla rete + failover del cablaggio elettrico / hardware + failover software, possibilmente, in qualche configurazione o nell'altro lavoro possa effettivamente realizzarlo.

C'è quasi sempre un singolo punto di errore da qualche parte in qualsiasi configurazione, ma se lavori abbastanza duramente, puoi spingere quel punto di errore per essere qualcosa che può essere riparato "dal vivo" (cioè il root DNS scende, ma i valori sono ancora memorizzati nella cache ovunque, quindi hai tempo per sistemarlo).

Ancora una volta, non dire che è fattibile ... Non mi è piaciuto come una singola risposta non abbia affrontato il fatto che non è "una via d'uscita" - non è qualcosa che vogliono davvero se ci pensano.

Ripensare la metodologia di misurazione della disponibilità, quindi lavorare con il cliente per stabilire obiettivi significativi .

Se stai gestendo un sito Web di grandi dimensioni, il tempo di attività non è affatto utile. Se elimini le query per 10 minuti quando i tuoi clienti ne hanno più bisogno (picco del traffico), potrebbe essere più dannoso per l'azienda di un'interruzione di un'ora alle 3:00 di domenica.

A volte le grandi società Web misurano la disponibilità o l'affidabilità, utilizzando le seguenti metriche:

1. percentuale di query a cui viene fornita una risposta corretta, senza errori sul lato server (HTTP 500s).
2. percentuale di query a cui viene data risposta al di sotto di una determinata latenza target .
3. le query eliminate devono essere conteggiate rispetto alle tue statistiche (vedi sotto).

La disponibilità non deve essere misurata utilizzando le sonde di esempio, che è ciò che un'entità esterna come pingdom e pingability sono in grado di segnalare. Non fare affidamento esclusivamente su questo. Se vuoi farlo nel modo giusto, ogni singola query dovrebbe contare . Misura la tua disponibilità osservando il tuo successo reale e percepito.

Il modo più efficiente è quello di raccogliere registri o statistiche dal bilanciamento del carico e calcolare la disponibilità in base alle metriche sopra.

La percentuale di query eliminate dovrebbe essere conteggiata anche rispetto alle tue statistiche. Può essere contabilizzato nello stesso bucket degli errori sul lato server. Se si verificano problemi con la rete o con un'altra infrastruttura come DNS o i servizi di bilanciamento del carico, è possibile utilizzare la matematica semplice per stimare il numero di query perse . Se ti aspettavi X query per quel giorno della settimana ma hai ricevuto X-1000, probabilmente hai perso 1000 query. Traccia il tuo traffico in grafici di query al minuto (o secondi). Se vengono visualizzate delle lacune, hai eliminato le query. Utilizzare la geometria di base per misurare l'area di tali spazi vuoti, che fornisce il numero totale di query eliminate.

Discutere questa metodologia con il cliente e spiegarne i vantaggi. Imposta una linea di base misurando la loro disponibilità attuale. Risulterà chiaro a loro che il 100% è un obiettivo impossibile.

Quindi è possibile firmare un contratto in base a miglioramenti sulla base. Ad esempio, se attualmente stanno riscontrando il 95% di disponibilità, si potrebbe promettere di migliorare la situazione dieci volte arrivando al 98,5%.

Nota: ci sono degli svantaggi in questo modo di misurare la disponibilità. Innanzitutto, la raccolta dei registri, l'elaborazione e la generazione dei report da soli potrebbero non essere banali, a meno che non si utilizzino strumenti esistenti per farlo. In secondo luogo, i bug dell'applicazione potrebbero compromettere la tua disponibilità. Se l'applicazione è di bassa qualità, servirà più errori. La soluzione a questo è considerare solo i 500 creati dal bilanciamento del carico anziché quelli provenienti dall'applicazione.

Le cose possono essere un po 'complicate in questo modo, ma è un passo oltre la semplice misurazione del tempo di attività del server .

Mentre alcune persone hanno notato qui, che il 100% è folle o impossibile , in qualche modo ha perso il punto. Hanno sostenuto che la ragione di ciò è il fatto che nemmeno le migliori aziende / servizi non possono realizzarlo.

Bene, è molto più semplice di così. È matematicamente impossibile .

Tutto ha una probabilità. Potrebbe esserci un terremoto simultaneo in tutte le posizioni in cui vengono archiviati i server, distruggendoli tutti. Piacevolmente è una probabilità ridicolmente piccola, ma non è 0. Tutti i vostri provider internet potrebbero affrontare un attacco terroristico / cyber simultaneo. Ancora una volta, non molto probabile, ma neanche zero. Qualunque cosa tu fornisca, puoi ottenere uno scenario di probabilità diverso da zero che abbassa l'intero servizio. Pertanto, il tempo di attività non può essere pari al 100%.

Vai a prendere un libro sul controllo di qualità della produzione utilizzando il campionamento statistico. Una discussione generale in questo libro, i concetti ai quali un manager sarebbe stato esposto in un corso di statistica generale al college, impone i costi per passare da 1 a mille in mille, a 1 in diecimila a 1 in un milione a 1 su un miliardo aumenta in modo esponenziale. In sostanza, la capacità di raggiungere il 100% di uptime costerebbe una quantità quasi illimitata di fondi, un po 'come la quantità di carburante necessaria per spingere un oggetto alla velocità della luce.

Dal punto di vista dell'ingegneria delle prestazioni respingerei il requisito in quanto sia non verificabile e irragionevole, secondo cui questa espressione è più un desiderio che un vero requisito. Con le dipendenze dell'applicazione che esistono al di fuori di qualsiasi applicazione per networking, risoluzione dei nomi, routing, difetti propagandati da componenti architetturali sottostanti o strumenti di sviluppo, diventa praticamente impossibile avere qualcuno che garantisca il 100% di uptime.

Non credo che il cliente stia effettivamente chiedendo un uptime del 100% o addirittura un uptime del 99,999%. Se guardi a ciò che stanno descrivendo, stanno parlando di riprendere da dove si erano interrotti se una meteorite ha eliminato il loro datacenter in loco.

Se il requisito è che le persone esterne non se ne accorgono nemmeno, quanto deve essere drastico? Fare una richiesta Ajax riprovare e mostrare un filatore per 30 secondi all'utente finale sarebbe accettabile?

Questi sono i tipi di cose che interessano al cliente. Se il cliente stesse effettivamente pensando a contratti di servizio precisi, allora ne saprebbero abbastanza per esprimerlo come 99,99 o 99,999.

i miei 2 centesimi. Ero responsabile di un sito Web molto popolare per un'azienda di fortuna-5 che avrebbe pubblicato annunci per il super bowl. Ho dovuto affrontare enormi picchi di traffico e il modo in cui l'ho risolto è stato quello di utilizzare un servizio come Akamai. Non lavoro per Akamai ma ho trovato il loro servizio estremamente buono. Hanno un proprio sistema DNS più intelligente che sa che con un determinato nodo / host è sotto carico pesante o è inattivo e può indirizzare il traffico di conseguenza.

La cosa bella del loro servizio era che non dovevo davvero fare nulla di molto complicato per replicare il contenuto sui server nel mio data center nel loro data center. Inoltre, so che lavorando con loro, hanno fatto un uso intensivo dei server HTTP Apache.

Sebbene non sia attivo al 100%, puoi prendere in considerazione tali opzioni per disperdere i contenuti in tutto il mondo. A quanto ho capito, Akamai ha anche avuto la capacità di localizzare il traffico, il che significa che se fossi nel Michigan, avessi contenuto da un server Michigan / Chicago e se fossi in California, presumibilmente avrei avuto il contenuto da un server basato in California.

Invece del failover off-site, basta eseguire l'applicazione da due posizioni contemporaneamente, interna ed esterna. E sincronizzare i due database ... Quindi, se l'interno non funziona, le persone interne saranno ancora in grado di lavorare e le persone esterne saranno ancora in grado di utilizzare l'applicazione. Quando internal torna online, sincronizza le modifiche. Puoi avere due voci DNS per un nome di dominio o persino un router di rete con round robin.

Per i siti ospitati esternamente, il tempo di attività più vicino al 100% è l'hosting del sito su App Engine di Google e l'utilizzo del suo archivio dati di replica elevato (HRD) , che replica automaticamente i tuoi dati su almeno tre data center in tempo reale. Allo stesso modo, i server front-end di App Engine vengono ridimensionati / replicati automaticamente.

Tuttavia, anche con tutte le risorse di Google e la piattaforma più sofisticata al mondo, la garanzia di uptime di App Engine SLA è solo "il 99,95% delle volte in qualsiasi mese di calendario".

Semplice e diretto: Anycast

http://en.wikipedia.org/wiki/Anycast

Questo è ciò che cloudflare, google e qualsiasi altra grande azienda utilizzano per eseguire il failover / bilanciamento ridondante, a bassa latenza e transcontinentale.

Ma tieni anche presente che è impossibile avere un uptime del 100% e che i costi per passare dal 99,999% al 99,9999% sono MOLTO più grandi.