La realizzazione di Zero Downtime Deployment ha toccato lo stesso problema, ma ho bisogno di alcuni consigli su una strategia che sto prendendo in considerazione.
Contesto
Un'applicazione web con Apache / PHP per l'elaborazione lato server e MySQL DB / filesystem per la persistenza.
Attualmente stiamo costruendo l'infrastruttura. Tutto l'hardware di rete avrà ridondanza e tutti i cavi di rete principali verranno utilizzati in coppie legate per la tolleranza agli errori. I server vengono configurati come coppie ad alta disponibilità per la tolleranza agli errori hardware e saranno bilanciati in base al carico sia per la tolleranza agli errori della macchina virtuale che per le prestazioni generali.
È mia intenzione che siamo in grado di applicare gli aggiornamenti all'applicazione senza tempi di inattività. Ho preso molta cura nel progettare l'infrastruttura per assicurarmi di poter fornire il 100% di tempo di attività; sarebbe estremamente deludente avere 10-15 minuti di inattività ogni volta che è stato applicato un aggiornamento. Ciò è particolarmente significativo poiché intendiamo avere un ciclo di rilascio molto rapido (a volte può raggiungere una o più versioni al giorno.
Topologia di rete
Questo è un riepilogo della rete:
Load Balancer
|----------------------------|
/ / \ \
/ / \ \
| Web Server | DB Server | Web Server | DB Server |
|-------------------------|-------------------------|
| Host-1 | Host-2 | Host-1 | Host-2 |
|-------------------------|-------------------------|
Node A \ / Node B
| / |
| / \ |
|---------------------| |---------------------|
Switch 1 Switch 2
And onward to VRRP enabled routers and the internet
Nota: i server DB utilizzano la replica master-master
Strategia suggerita
Per raggiungere questo obiettivo, sto attualmente pensando di suddividere gli script di aggiornamento dello schema DB in due parti. L'aggiornamento sarebbe simile al seguente:
- Il server Web sul nodo A è disattivato; il traffico continua ad essere elaborato dal web server sul nodo B.
- Le modifiche allo schema di transizione vengono applicate ai server DB
- Server Web Una base di codice viene aggiornata, le cache vengono cancellate e vengono intraprese eventuali altre azioni di aggiornamento.
- Il server Web A viene portato in linea e il server Web B viene portato offline.
- La base di codice B del server Web viene aggiornata, le cache vengono cancellate e vengono intraprese eventuali altre azioni di aggiornamento.
- Il web server B viene portato online.
- Le modifiche dello schema finale vengono applicate al DB
Lo "schema transitorio" verrebbe progettato per stabilire un DB compatibile tra versioni. Ciò farebbe principalmente uso delle viste della tabella che simulano lo schema della vecchia versione mentre la tabella stessa verrebbe modificata al nuovo schema. Ciò consente alla versione precedente di interagire normalmente con il DB. I nomi delle tabelle includeranno i numeri di versione dello schema per garantire che non vi sia alcuna confusione su quale tabella scrivere.
"Schema finale" rimuove la compatibilità con le versioni precedenti e riordina lo schema.
Domanda
In breve, funzionerà?
più specificamente:
Ci saranno problemi dovuti al potenziale di scritture simultanee nel punto specifico della modifica dello schema di transizione? C'è un modo per assicurarsi che il gruppo di query che modifica la tabella e crea la vista compatibile con le versioni precedenti sia eseguito consecutivamente? vale a dire con qualsiasi altra query trattenuta nel buffer fino al completamento delle modifiche dello schema, che generalmente saranno solo millisecondi.
Esistono metodi più semplici che offrono questo grado di stabilità, consentendo al contempo aggiornamenti senza tempi di inattività? Si preferisce anche evitare la strategia dello schema "evolutivo" poiché non desidero essere bloccato nella compatibilità dello schema all'indietro.