Come vengono installati gli aggiornamenti critici di sicurezza sui sistemi che non è possibile effettuare il riavvio, ma l'aggiornamento richiede un riavvio. Ad esempio, i servizi / le aziende che devono eseguire 24x7 con tempi di inattività pari a zero, ad es. Amazon.com o Google.
Esistono varie utilità in diversi sistemi operativi che consentono l'hot patching del codice in esecuzione. Un esempio di questo sarebbe kpatch e livepatch caratteristiche di Linux che consentono di applicare patch al kernel in esecuzione senza interrompere le sue operazioni. Le sue capacità sono limitate e possono solo apportare modifiche banali al kernel, ma questo è spesso sufficiente per mitigare un numero di problemi di sicurezza critici fino a quando il tempo può essere trovato a fare una correzione adeguata. Questo tipo di tecnica, in generale, è chiamata software dinamico aggiornamento .
Vorrei sottolineare però che i siti con praticamente senza tempi di inattività ( ad alta disponibilità ) non sono così affidabili a causa della live-patching, ma a causa della ridondanza. Ogni volta che un sistema si arresta, ci sarà un certo numero di backup che possono immediatamente iniziare a instradare il traffico o elaborare le richieste senza ritardo. Ci sono un gran numero di diverse tecniche per realizzare questo. Il livello di ridondanza fornisce operatività significativa misurata in nove . Un tempo di attività di tre nove è del 99,9%. Quattro nove uptime è 99,99%, ecc. Il "Santo Graal" è di cinque nove, o tempo di disponibilità del 99,999%. Molti dei servizi che hai elencato hanno cinque nove disponibilità a causa dei loro sistemi di backup ridondanti diffusi in tutto il mondo.
Ho visto una presentazione a una conferenza sulla sicurezza da un dipendente Netflix. Non patch affatto. Invece, quando è richiesta una patch, si alzano le nuove istanze e poi soffiano via quelle prive di patch. Lo stanno facendo quasi costantemente. Lo chiamano implementazione red-black .
La risposta breve è:
Riavvia.
Sembra che si presuma che Amazon e Google vengano eseguiti su un singolo server e, in caso di riavvio, l'intero sito / servizio non è disponibile. Questo è molto lontano dalla verità: i servizi di grandi dimensioni in genere vengono eseguiti su molti server che funzionano in parallelo. Per ulteriori letture, guarda tecniche come clustering , bilanciamento del carico e failover .
Google, ad esempio, ha più di una dozzina di data center in tutto il mondo , e ognuno detiene un numero enorme di server (le stime sono 100.000-400.000 server per centro ).
In tali ambienti, gli aggiornamenti (sia le funzionalità che gli aggiornamenti di sicurezza) vengono generalmente installati come distribuzioni a rotazione :
Ci sono altre opzioni, come l'hot patching, ma non sono usate frequentemente nella mia esperienza, almeno non sui tipici siti web di grandi dimensioni. Vedi la risposta della foresta per i dettagli.
Puoi controllare " Attività di distribuzione " in "Distribuzione software". Un metodo comune consiste nell'utilizzare un Load Balancer di fronte ai propri servizi e reindirizzare il traffico di conseguenza. In una tecnica chiamata "distribuzione blu-verde", si reindirizza il traffico dai server "blu" a quelli "verdi". Questo non ha alcun downtime sul lato utente, a condizione ovviamente che l'applicazione possa gestirlo correttamente, ad es. attraverso i servizi stateless.
Supponiamo che l'applicazione esegua v1 sul server blu e che il bilanciamento del carico indirizzi il traffico lì. È possibile aggiornare il server verde (che non riceve traffico) alla v2. Quindi riconfigurare il bilanciamento del carico per indirizzare il traffico verso il server verde. Quindi, hai eseguito l'upgrade da v1 a v2 senza tempi di inattività.
Puoi usare la tecnica blu-verde anche come parte del test. Ad esempio, si configura il bilanciamento del carico per indirizzare il 95% del traffico verso il server blu (v1) e il 5% verso il server verde (v2). In questo modo puoi testare la tua nuova versione, con meno traffico e con un impatto minore sugli utenti in caso di bug.
È piuttosto facile quando le cose sono raggruppate e con proxy. Perché hai molti nodi in grado di eseguire lo stesso lavoro (o diversi nel caso di archivi di dati come motori di ricerca, file system Hadoop, ecc.)
Fai una ricerca sul web. Colpisci www.altavista.com. La voce DNS elenca una mezza dozzina di indirizzi IP e il tuo cliente ne colpisce uno a caso. Ogni IP è un router Cisco, che invia i fan a uno casuale di 8 server fisici front-end (48 in totale) su indirizzi IP interni. Quel server normalizza la tua query (rimuove gli spazi bianchi ecc.) Poi prende un hash MD5 di esso. L'MD5 decide quale dei 300 server proxy a cui accede la query. Quella 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 perde la sua richiesta. I dati RRD o altre raccolte di dati vengono utilizzati come watchdog quando un server front-end inizia a non funzionare e si reindirizza il traffico a un server di standby. Lo stesso si può dire dei router Cisco.
Il proxy prima controlla la sua cache . Per un colpo di cache, esegue il blending della localizzazione e restituisce la risposta; fatto. Se si tratta di un "cache miss", il proxy invia la query ai cluster di ricerca.
Se un proxy va giù, di nuovo un'altra macchina fisica può essere scambiata per quel proxy. È un po 'più critico ora, perché i proxy non sono intercambiabili; ognuno "possiede" una piccola porzione dello spettro dei risultati della ricerca. Quindi, se la macchina 0x0000-0x00d9 si arresta, il sostituto deve sapere intervenire per quell'intervallo. E peggio ancora, quella macchina sostitutiva avrà una cache vuota, quindi ogni query di ricerca sarà una mancanza di cache . Ciò aumenterà il carico sui cluster di ricerca appropriati da un piccolo bit per proxy downed . Ciò significa che se rimbalzi tutti i proxy allo stesso tempo, non farlo durante le ore di punta della ricerca !
I cluster di ricerca hanno una stratificazione e ridondanza simile, ovviamente, e ogni segmento del database di ricerca risiede su diversi nodi, quindi se un nodo scende, altri nodi possono servire quella porzione dei risultati.
Mi sto concentrando sul proxy come esempio. La comunicazione in esso avviene tramite SOAP, la comunicazione fuori da esso avviene tramite un protocollo di alto livello simile. I dati in entrata e in uscita sono transitori, ad eccezione della cache che è importante per bilanciare il carico del motore dei motori di ricerca. Il punto è che può essere scambiato all'istante in qualsiasi momento, con il peggior risultato di poche ricerche. Questo è qualcosa che il server front-end noterebbe e potrebbe semplicemente inviare nuovamente la sua query, entro la quale il nuovo proxy sarebbe attivo.
Quindi se hai 300 proxy e ci vuole 1/2 ora per un proxy per recuperare la cache, e puoi aspettare che il carico del motore di ricerca aumenti del 20%, allora puoi scambiare 1 proxy ogni 30 secondi, quindi qualsiasi periodo di 30 minuti di scorrimento, 60 proxy (20%) stanno ricostruendo le cache. Supponendo che sia anche urgente andare così velocemente.
Questo esempio richiede 2-1 / 2 ore per l'implementazione, e se una minaccia emergente richiede una risposta più rapida, allora si può sopportare il dolore di più errori di cache, o si scende il servizio abbastanza a lungo da patch (ma nella ricerca esempio di motore, i problemi di cache continueranno a essere un problema quando si ritorna in su. Ho visto i grafici RRD dopo un ricarico del DB di emergenza e lo svuotamento della cache necessario, è qualcosa da vedere.)
Naturalmente di solito il processo può essere riparato, fermato e riavviato senza un riavvio completo. Ho visto uptime di 2 anni sui nodi di produzione.