Esistono varie utilità in diversi sistemi operativi che consentono l'applicazione di patch a caldo del codice in esecuzione. Un esempio di ciò sarebbero le funzionalità kpatch e livepatch di Linux che consentono di applicare patch al kernel in esecuzione senza interromperne le operazioni. Le sue capacità sono limitate e possono apportare solo modifiche banali al kernel, ma questo è spesso sufficiente per mitigare una serie di problemi di sicurezza critici finché non si trova il tempo per fare una correzione adeguata. Questo tipo di tecnica in generale è chiamata aggiornamento dinamico del software.

Devo sottolineare però che i siti praticamente senza tempi di inattività ( alta disponibilità) non sono così affidabili a causa del live-patching, ma a causa della ridondanza. Ogni volta che un sistema si arresta, saranno presenti numerosi backup che possono iniziare immediatamente a instradare il traffico o elaborare le richieste senza ritardi. Esistono numerose tecniche diverse per eseguire questa operazione. Il livello di ridondanza fornisce un tempo di attività significativo misurato in nove. Un tempo di attività tre nove è del 99,9%. Il tempo di attività di quattro nove è del 99,99%, ecc. Molti dei servizi che hai elencato hanno cinque nove disponibilità a causa dei loro sistemi di backup ridondanti sparsi in tutto il mondo.

Ho guardato una presentazione a una conferenza sulla sicurezza di un dipendente Netflix. Non rattoppano affatto. Invece, quando è richiesta una patch, sostengono nuove istanze e poi spazzano via quelle prive di patch. Lo fanno quasi costantemente. Lo chiamano distribuzione rosso-nera.

La risposta breve è:

Si riavviano.

Sembri presumere che Amazon e Google vengano eseguiti su un unico server, e se quello viene riavviato, l'intero sito / servizio è inattivo. Questo è molto lontano dalla verità: i servizi di grandi dimensioni in genere vengono eseguiti su molti server che funzionano in parallelo. Per ulteriori letture, esamina tecniche come clustering, bilanciamento del carico e failover.

Google, ad esempio, ha più di una dozzina di data center in tutto il mondo e ciascuno contiene un numero enorme di server (le stime sono 100.000-400.000 server per centro).

In tali ambienti, gli aggiornamenti (sia aggiornamenti di funzionalità che aggiornamenti di sicurezza) vengono generalmente installati come distribuzioni in sequenza:

• scegli un sottoinsieme di server
• installa gli aggiornamenti sul sottoinsieme
• riavvia il sottoinsieme; nel frattempo gli altri server prendono il sopravvento
• ripeti con il sottoinsieme successivo :-)

Ci sono altre opzioni, come l'hot patch, ma non sono usate così frequentemente nella mia esperienza, almeno non sui tipici siti Web di grandi dimensioni. Vedi la risposta della foresta per i dettagli.

Puoi selezionare " Attività di distribuzione" in "Distribuzione software". Un metodo comune consiste nell'utilizzare un Load Balancer davanti ai tuoi servizi e reindirizzare il traffico di conseguenza. In una tecnica chiamata "distribuzione blu-verde", reindirizza il traffico dai server "blu" a quelli "verdi". Questo non ha alcun tempo di inattività lato utente, a condizione ovviamente che l'applicazione possa gestirlo correttamente, ad es. tramite servizi senza stato.

Supponiamo che la tua applicazione esegua la v1 sul server blu e il tuo sistema di bilanciamento del carico diriga il traffico lì. Puoi aggiornare il server verde (che non riceve traffico) alla v2. Quindi riconfigurare il bilanciamento del carico per indirizzare il traffico al server verde. Quindi, hai eseguito l'aggiornamento dalla v1 alla v2 senza tempi di inattività.

Puoi utilizzare la tecnica blu-verde anche come parte del test. Ad esempio, si configura il sistema di bilanciamento del carico per indirizzare il 95% del traffico al server blu (v1) e il 5% al ​​server verde (v2). In questo modo puoi testare la tua nuova versione, con meno traffico e con un minore impatto sugli utenti nel caso in cui abbia dei bug.

È abbastanza facile quando le cose sono raggruppate e trasmesse tramite proxy. Perché hai molti nodi in grado di svolgere lo stesso lavoro (o diversi nel caso di archivi di dati come motori di ricerca, file system Hadoop ecc.)

Fai una ricerca sul web. Hai colpito www.altavista.com. La voce DNS elenca una mezza dozzina di indirizzi IP e il tuo client ne colpisce uno a caso. Ogni IP è un router Cisco, che gestisce il traffico verso uno degli 8 server front-end fisici (48 in totale) su indirizzi IP interni. Quel server normalizza la tua query (rimuove gli spazi, ecc.) Quindi ne prende un hash MD5. L'MD5 decide a quale dei 300 server proxy deve essere indirizzata la query. La query viene inviata al proxy tramite un protocollo standard come SOAP.

I server front-end sono intercambiabili perché gestiscono solo le richieste transitorie di una singola query. Al di fuori dei casi peggiori, un cliente ottiene la sua richiesta abbandonata. I dati RRD o altre raccolte dati vengono utilizzati per il watchdog quando un server front-end inizia a non funzionare e il traffico viene reindirizzato a un server di standby. Lo stesso si può dire dei router Cisco.

Il proxy controlla prima la sua cache . Per un riscontro nella cache, esegue la fusione della localizzazione e restituisce la risposta; fatto. Se si tratta di un "errore nella cache", il proxy distribuisce la query ai cluster di ricerca.

Se un proxy non funziona, di nuovo un'altra macchina fisica può essere sostituita con quel proxy. È un po 'più critico ora, perché i proxy non sono intercambiabili; ognuno "possiede" una piccola fetta dello spettro dei risultati della ricerca. Quindi, se la macchina 0x0000-0x00d9 si arresta, il sostituto deve sapere di intervenire per quell'intervallo. E peggio ancora, quella macchina sostitutiva avrà una cache vuota, quindi ogni query di ricerca sarà una cache mancante . Ciò aumenterà il carico sui cluster di ricerca appropriati di un po ' per proxy disattivato . Ciò significa che se rimbalzi su tutti i proxy contemporaneamente, non farlo durante le ore di punta della ricerca !

I cluster di ricerca hanno livelli simili e la ridondanza, ovviamente, e ogni segmento del database di ricerca risiede su diversi nodi, quindi se un nodo si interrompe, altri nodi possono fornire quella fetta dei risultati.

Mi sto concentrando sul proxy come esempio. La comunicazione in esso avviene tramite SOAP, la comunicazione in uscita avviene tramite un protocollo simile di alto livello. I dati in entrata e in uscita sono temporanei, ad eccezione della cache che è importante per bilanciare il carico del cluster del motore di ricerca. Il punto è che può essere scambiato istantaneamente in qualsiasi momento, con il peggior risultato di alcune ricerche che scadono. Questo è qualcosa che il server front-end noterebbe e potrebbe semplicemente inviare di nuovo la sua query, a quel punto il nuovo proxy sarebbe attivo.

Quindi se hai 300 proxy e ci vuole mezz'ora per un proxy per recuperare la sua cache e puoi sopportare che il carico del motore di ricerca aumenti del 20%, quindi puoi scambiare 1 proxy ogni 30 secondi, quindi in qualsiasi periodo di 30 minuti, 60 proxy (20%) stanno ricostruendo le cache. Supponendo che ci sia persino un urgente bisogno di andare così velocemente.

Questo esempio richiede 2-1 / 2 ore per l'implementazione e se una minaccia emergente richiede una risposta più rapida, allora o sopporti il ​​dolore di più errori nella cache o interrompi il servizio abbastanza a lungo da applicare la patch (ma nella ricerca esempio di motore la mancata riuscita della cache sarà ancora un problema quando torni su. Ho guardato i grafici RRD dopo un ricaricamento di emergenza del DB e il necessario svuotamento della cache, è qualcosa da vedere.)

Ovviamente di solito il processo può essere corretto, interrotto e riavviato senza un riavvio completo. Ho visto tempi di attività di 2 anni sui nodi di produzione.