Migrazione in Datacenter: le regole d’oro per non fallire – Parte 2

Tutti gli step e i passi principali di uno dei tanti casi complessi e di pieno successo portati a segno da Momit

Illustriamo adesso un caso complesso di Migrazione in Datacenter gestito da Momit:

Step #0: Screening

Il primo screening delinea una situazione complessa:

• I sistemi applicativi di front-end sono tutti interconnessi fra loro; decisamente non pronti ad una migrazione da Datacenter a Datacenter.
• Nel back-end si trovano diversi TeraByte che insistono su centinaia di Database. Considerando che alcuni di questi sono in costante cambiamento, la migrazione real-time è una bella sfida.
• Fortunatamente, nel middle-end si trovano alcuni server e applicativi non critici che non sono complessi da migrare.

Questa prima analisi avviene a febbraio ed appare subito impossibile praticare la migrazione a “BigBang”: le notizie non si fermano e il mondo delle news non può non essere alimentato.  Impensabile, quindi, fermare tutto per un Week-end e ripartire il lunedì con il sistema migrato.

Nella teoria – e in un mondo ideale – per una migrazione “a contagocce” ottimale basterebbe una sincronia delle piattaforme tramite Veeam o similare. Oppure si potrebbero sincronizzare i due storage per minimizzare il down: spegnere da una parte, accendere dall’altra. Chiaramente deve essere presente un link dedicato ad altissima velocità.
E già… in un mondo ideale per l’appunto, che non è il mondo reale: fra i Datacenter abbiamo “solo” una interconnessione a pochi Gigabit, e la stessa deve continuare anche a servire i servizi. Impensabile quindi ipotizzare di saturare la banda per sincronizzare.

E poi ci sono gli storage. Il mondo delle SAN è meraviglioso con tutti i vendor che fanno la gara a vendere le feature più mirabolanti del mondo. Peccato che, se si passa da uno storage tradizionale con una precisa capacità ad uno scalabile in pay-per-use a capacità illimitata, come Zadara, tutte le feature vengono meno. Parole come integrazione, semplicità, replica spariscono magicamente dalle caratteristiche degli storage. Come sempre, sulla bilancia ci sono i costi/benefici, e l’opzione Zadara ha davvero troppi, troppi vantaggi competitivi su una soluzione tradizionale per non essere scelta.

La scelta di Momit

La scelta di Momit, in accordo e condivisa con Volocom, è stata quindi quella di procedere per step, e con alcuni punti fermi:

• Da febbraio ad aprile Volocom avrebbe dovuto rendere indipendenti i sistemi di front-end così che la migrazione in datacenter divenisse possibile;
• Si è optato per uno spostamento “a contagocce” con le sincronie dei sistemi; nell’architettura era presente, ed è stato implementato, un cluster per il load balancing. Il cluster, basato sul performante sistema di Oplon Networks, avrebbe consentito con discreta semplicità lo spostamento delle applicazioni;
• Nonostante ciò, con la migrazione “a contagocce” alcune cose pesanti sarebbero risultate impossibili da sincronizzare, poiché il dato cambia più velocemente di quanto si riesca a sincronizzare. Questo si sarebbe tradotto in un task infinito e impossibile da completare. Per queste ragioni abbiamo scelto di procedere a “BigBang”. Abbiamo individuato come unico giorno utile il 15 di agosto – unico giorno dell’anno in cui non escono i giornali.
• Il punto di non ritorno è quindi definito nel “15 Agosto”. Spostando a BigBang avremmo dovuto riaccendere l’infrastruttura con switch off complessivo di datacenter il 15 notte. Se fossero accaduti imprevisti avremmo dovuto risolverli in quello stesso momento, poiché non sarebbe stato possibile semplicemente tornare indietro.

Step #1: Stesura del progetto e nuova infrastruttura

La realtà, quindi, è che si hanno 24 ore di tempo per poter trasferire i dati pesanti, sincronizzare tutti i sistemi, cambiare i puntatori delle varie piattaforme, fare il renumbering IP dei sistemi, riaccendere tutto ed essere online come se nulla fosse accaduto. Una sfida.

Sfida che abbiamo ben volentieri accettato. La stesura del documento di progetto di migrazione è durata più di 3 mesi, con incluso un test che ha centrato tutte le aspettative. Ed imprevisti, di cui tanto si è parlato, non ce ne sono stati?  Certo che ne abbiamo avuti.

È quasi utopico che tutto vada liscio: abbiamo riscontrato sull’ hardware di ultima generazione un bug che impediva ai nodi del sistema di virtualizzazione di vedere la memoria ram disponibile. Fortunatamente, il vendor ha rilasciato un firmware con la correzione a sole 72 ore dalla segnalazione. 

Abbiamo anche scoperto che il Database – il cui produttore tanto decantava il sistema di replica e deduplica dei dati – funzionava sì egregiamente con i database piccoli (diciamo fino a 50-100GB); tuttavia, su Database da centinaia di GB, con dati in veloce mutamento, la sincronia real-time aveva non pochi problemi. Le procedure di test hanno comunque preventivamente evidenziato il limite del sistema, permettendoci di trovare una valida alternativa.

Parallelamente alla stesura del documento, il primo step ha incluso la creazione della nuova infrastruttura. Ciò è avvenuto mentre i vecchi sistemi continuavano a girare nel vecchio Datacenter da dismettere e i servzi via DNS continuavano a puntare sulla vecchia infrastruttura. Tutto il network, la connettività e l’infrastruttura di virtualizzazione sono stati messi a punto all’interno di Supernap Italia.  Non potendo disporre di un collegamento diretto fra i due siti, abbiamo creato una vpn con attente regole per la prioritarizzazione del traffico, in modo tale da non intaccare l’erogazione degli applicativi in produzione.  Una scelta, questa, che solitamente operiamo per il collegamento di due siti quando non c’è “di meglio”. 

Step #2: Il piano di renumbering

Il secondo step è stato il piano di renumbering, che peraltro ha permesso una revisione completa della segmentazione in vlan dell’infrastruttura cliente evidenziando quali sarebbero stati i sistemi oggetto di criticità (si pensi ai cluster, ad esempio). Si è invece proceduto da subito con tutti i sistemi che non “soffrono” e naturalmente funzionano. Ad esempio, per il sistema di autenticazione Microsoft Active Directory o il sistema di load balancing Oplon Network basta una semplice configurazione per avere operativa e migrata una parte dell’infrastruttura.

Fortunatamente i load balancer permettono di avviare una migrazione in datacenter senza prevedere interruzioni. Attraverso la soluzione Oplon si è proceduto a spostare le sessioni applicative da un datacenter all’altro con gli applicativi rimasti sempre operativi agli occhi degli utenti. Nel momento in cui c’erano zero utenti sul vecchio sistema e il 100% sulla nuova infrastruttura si è considerato concluso questo passaggio con il cambiamento dei puntamenti DNS. L’unico momento di stop si è avuto nel passaggio dei database pesanti tornati “live” appunto in un giorno, il famoso 15 agosto, in cui non venivano mutati con nuovi dati.

Il load balancing è da ritenersi una soluzione “smart” in quanto permette di continuare a navigare e a erogare i dati richiesti dagli utenti per pian piano indirizzarli verso la nuova infrastruttura secondo una percentuale sempre più crescente fino ad arrivare al 100%; tuttavia, perché sia applicabile e funzionale, bisogna che l’applicativo sia predisposto ad essere dietro ad un load balancer. Inoltre, non è la tecnica definitiva per qualsiasi caso: ad esempio, nel caso delle infrastrutture database non funziona.

Per concludere

Abbiamo parlato dei passaggi a cui si attiene Momit per effettuare le migrazioni e dunque del progetto che vi sta dietro. Se state valutando la migrazione in datacenter della vostra infrastruttura o prossimamente volete creare un documento di analisi dei rischi sulla potenziale migrazione potete liberamente prendere spunto da questo caso reale che noi abbiamo toccato con mano.

Oggi più che mai le aziende guardano alle soluzioni esternalizzate che tendono a ridurre, se non eliminare del tutto, la necessità di procedere alla migrazione e la gestione dei sistemi affidandoli a chi ha team di esperti verticali nelle varie piattaforme. E Momit, assieme ai partner Oplon Networks, Zadara e Supernap Italia è pronta a soddisfare ogni esigenza del cliente.

Se vuoi saperne di più sulle strategie di Migrazione in Datacenter leggi la prima parte dell’ articolo!