Una migrazione è un progetto, non un ticket.
La piattaforma ad alto traffico di un editore, riprogettata per scalare, testata sotto carico e spostata sul nostro bare metal. L'impatto visibile al cliente è stato una finestra di circa cinque minuti dentro un'operazione di due ore.
In questo articolo 4 sezioni
- Il gruppo di testate ad alto traffico di un grande editore doveva cambiare datacenter verso il nostro bare metal, riprogettato per scalare lungo la strada. Il traffico delle breaking news è il loro business, e ogni lettore avrebbe visto un cutover andato male.
- Abbiamo progettato prima la piattaforma: una cache edge a due livelli su SAN all-flash, un load balancer tarato per un numero di connessioni molto alto, un livello database con separazione tra letture e scritture, e uno strato di object cache.
- Poi l'abbiamo dimostrata con un test di carico a scala reale, prima di spostare un solo lettore vero.
- Il cutover è stato un'operazione di due ore con una finestra DNS visibile al cliente di circa cinque minuti, ogni fase con un percorso di rollback.
Sono siti di news e lifestyle in cui il picco di traffico è il business. Una migrazione che li butta giù, o li riporta su più lenti, è visibile a ogni lettore nel mezzo di una notizia dell'ultima ora. Questo non sarebbe mai stato un ticket. Era un progetto con una notte di cutover.
Perché un solo team per tutto il lavoro
Il lavoro richiedeva due cose nello stesso momento, da un solo team: l'ingegneria per riprogettare i livelli di cache e di database, e l'infrastruttura di proprietà (SAN enterprise all-flash, un vero fabric di rete) su cui farla atterrare. Abbiamo messo insieme gli ingegneri e il ferro, e la notte del cutover era nostra da portare a termine.
La piattaforma, come progettata
L'intento progettuale era tre cose insieme: riprogettare per la scala di cache e database, fare il cutover con una finestra minima e delimitata, e portare ogni pezzo del nuovo design attraverso il cutover intatto. Ecco cosa è diventata.
Cache edge Varnish a due livelli
HAProxy davanti
ProxySQL su ogni nodo web
Cluster Percona XtraDB
Valkey + Sentinel
Il deterministico batte l'elegante
Il database si è spostato con un hot backup fresco invece che con il riallineamento di una replica live. È stata una decisione progettuale con una motivazione dichiarata: un backup è deterministico, quindi ciò che sta nel backup è ciò che il nuovo cluster ha, senza stato di replica da districare nel momento peggiore possibile. La strada più elegante esiste, e l'abbiamo rifiutata di proposito. La notte del cutover volete la mossa di cui conoscete già l'esito.
Spostare i dati in fretta ha significato farli rimbalzare in due salti: sulla rete pubblica fino a un relay di staging, poi sulla LAN interna a velocità di linea, trasformando una copia limitata dalla crittografia in pochi minuti. Sulla destinazione, il cluster è stato ricostruito dal backup e risincronizzato nodo per nodo.
E una sincronizzazione del filesystem portava con sé una lista di esclusioni chirurgica, perché la migrazione non potesse sovrascrivere la configurazione della nuova casa: la configurazione del puntatore al database, il drop-in dell'object cache e l'impianto della cache a due livelli erano tutti esplicitamente preservati. L'unico pezzo di stato che un ripristino di database cancella in silenzio, l'attivazione del plugin di purge della cache, era stato mappato in anticipo con la sua riattivazione pronta a scattare. Questo significa progettare il cutover due volte: una in avanti, e una per tutto ciò che potrebbe mordere lungo la strada.
I dati, in due salti
Rete pubblica fino a un relay di staging, poi la LAN interna a velocità di linea. Minuti, non ore.
Cluster ripristinato dall'hot backup
Risincronizzato nodo per nodo.
Spostamento del filesystem, protetto
Una lista di esclusioni protegge la nuova architettura dalla sovrascrittura.
Il DNS cambia
La finestra visibile: circa cinque minuti.
L'unica impostazione cancellata in silenzio, riattivata
Nei tempi, perché era stata mappata in anticipo.
“Non abbiamo spostato i vostri server. Abbiamo ricostruito la vostra piattaforma e l'abbiamo fatta atterrare sulla nostra, in una finestra di circa cinque minuti, pianificata in anticipo.”
Cosa è diventata la relazione
La migrazione era il punto d'ingresso, non la fine. Le testate sorelle hanno seguito lo stesso schema, e la disciplina operativa è arrivata come parte della costruzione invece che come upsell successivo: hot backup frequenti del database e snapshot del filesystem conservati, cache edge tarate, uno strato di monitoraggio delle prestazioni esteso a tutta la flotta, e validazione con test di carico prima del lancio. La relazione si è assestata su «gestiamo e facciamo evolvere la piattaforma», non su «la ospitiamo».
Risposte dirette
Potete migrare un sito ad alto traffico senza metterlo offline?+
Pianifichiamo una finestra delimitata e la dichiariamo in anticipo. In questo progetto: circa cinque minuti di propagazione DNS visibile al cliente dentro un'operazione di due ore.
Backup e ripristino o replica per la migrazione di un database?+
Entrambi sono legittimi. Qui abbiamo scelto un hot backup fresco perché è deterministico: ciò che sta nel backup è ciò che il nuovo cluster ha, senza stato di replica da districare a metà cutover. La strada elegante non è sempre quella sicura.
Cosa dovrebbe includere un piano di rollback per una migrazione?+
Un percorso di rollback su ogni fase, e un percorso documentato per tornare all'origine finché la nuova piattaforma non si è guadagnata la fiducia.
Riprogettate durante una migrazione o spostate e basta?+
Se lo spostamento merita un progetto, di solito merita anche la riprogettazione. Questa piattaforma ha guadagnato lungo la strada una cache edge a due livelli, un livello database con separazione letture/scritture e uno strato di object cache. Il lift-and-shift a volte è giusto, ma è una decisione, non un default.
State pianificando uno spostamento? Portateci la piattaforma, non un ticket.
Progetto, test di carico, playbook di cutover, corde di rollback. Vi diremo la finestra onesta prima della notte, e terremo la rete di sicurezza.
Parla con un ingegnere (shell cta.talkToEngineer)Siete arrivati alla fine.
Mettete la lettura al lavoro
Cosa fate girare?
Raccontateci il carico di lavoro, il traffico e i requisiti di ripristino. Partite dal configuratore di server, oppure discutete i dettagli con un ingegnere.
Scritto dagli ingegneri che costruiscono e gestiscono l'infrastruttura che descrive.Parla con un ingegnere