Translate

 

Introduzione

Spostare la vostra infrastruttura IT verso Amazon Web Services (o qualsiasi altro servizio cloud IAAS) suona come una decisione semplice da prendere. Puoi scalare su e giù le risorse come più necessario e pagare solo per la potenza di calcolo e lo storage usato. Decisone semplice a maggior ragione per quelle aziende che già operano con datacenter in co-location. Una delle prime domande che ci si pone però riguarda le modalità con cui un’azienda può migrare la propria infrastruttura, quale l’approccio, quali i rischi e quali i problemi.

In questo articolo viene descritto il progetto di una azienda cliente che ha recentemente completato l’operazione di migrazione verso Amazon Web Services.

L’azienda eroga servizi IT per il mercato retail (gestione POS, logistica, acquisti, fatturazione, business intelligence, fidelity cards, POS relationship management, store building, ..) in modalità SAAS attraverso una infrastruttura principalmente basata su architettura Microsoft, database servers Oracle e Sql Server e portali Sharepoint.

Il progetto è durato oltre un anno anche se la migrazione di per se è durata meno di due settimane; operazione in ogni caso notevole visto che nessuno ha mai parlato con personale Amazon (tutto si è svolto online senza intoppi) e il pagamento è stato gestito attraverso una carta di credito aziendale.

Note a margine

Prima di procedere con una descrizione del progetto è però interessante considerare alcune considerazioni ad alto livello:

L’infrastruttura precedente, allocata in un datacenter in co-location, operava con un carico medio inferiore al 10% ma era stata dimensionata per supportate il carico di picco più elevato. Con AWS è stato possibile costruire una infrastruttura dinamicamente scalabile in funzione delle esigenze con l’aggiunta di nuovi server e storage in qualche minuto. AWS lavora bene per attività di testing, dimostrazioni, rilasci beta ed altri esperimenti; è possibile allocare server dedicati ai clienti durante i progetti di sviluppo o come trial per nuovi clienti.

  • Se state pensando di utilizzare qualcosa di simile ad AWS verificate che i servizi che state per usare siano disponibili anche presso altri fornitori: evitate per quanto possibile di usare servizi proprietari. I servizi usati per questo progetto sono offerti anche da altri fornitori (vedi Windows Azure) così che si possa migrare ad un altro cloud nel caso fosse necessario. L’unica eccezione è il servizio di snapshot largamente usato per la clonazione a caldo che ad oggi non è disponibile presso, ad esempio, il cloud di Microsoft; il servizio non ostacolerebbe tuttavia una eventuale migrazione dei servizi.

  • E’ stato allestito un servizio di monitoraggio esterno all’infrastruttura per poter misurare le prestazioni del servizio a livello di interfaccia utente e per comunicare eventuali allarmi ai clienti in caso di indisponibilità dell’infrastruttura. La struttura di controllo realizza anche il servizio di schedulazione delle istanze; alcuni servizi sono erogati per contratto solo in orari di ufficio per cui i relativi server vengono spenti al di fuori di questi orari. Parte della struttura di controllo è allocata su Windows Azure.

  • Ci sono alcune implicazioni culturali da ponderare. L’azienda cliente eroga servizi SAAS da oltre dieci anni (qualche anno fa venivano chiamati servizi ASP) e quindi comprende il cloud; il suo personale non è a disagio senza interfacce umane. Non è detto che questo possa andar bene anche per altre aziende nel caso in cui vengano lasciate sole a muovere terabyte di dati verso il cloud.

  • Le policy di sicurezza da applicare sono le stesse adottate per il datacenter in co-location. La migrazione verso il cloud semplifica l’infrastruttura eliminando la necessità di realizzare infrastrutture in alta affidabilità perché incluse nel servizio. La vecchia infrastruttura includeva un cluster di database Oracle in modalità Failsafe per garantire la continuità di servizio anche in caso di caduta di uno dei servers; per il tipo di servizio erogato era ed è accettabile una indisponibilità momentanea di qualche minuto in caso di malfunzionamento di uno dei servers. Sulla nuova infrastruttura il servizio di database è stato allocato su un’unica istanza e questo garantisce lo stesso livello di disponibilità.

Progetto

Il progetto di migrazione è stato suddiviso in più fasi per evitare di spostare tutti i dati in un’unica soluzione ed evitare blocchi del servizio per più di qualche ora nella fase di migrazione.

Fase 1: sperimentazione e rilevazione dati

In questa fase, durata diversi mesi, sono stati sperimentati e pesati i servizi erogati da diversi fornitori. Allo scopo sono stati spostati in cloud i server di sviluppo, quality assurance e test pre-produzione. Ogni server in cloud è stato costantemente controllato da un servizio di monitoraggio al tempo allocato su Aruba. Sono stati raccolti e analizzati dati circa la disponibilità e le prestazioni dei servizi. La fase si è conclusa con la scelta del fornitore e la decisione definitiva di andare in cloud.

Fase 2: infrastruttura EC2 (Elastic Compute Cloud)

In questa fase è stata costruita l’infrastruttura di base del datacenter. L’architettura del sistema si basa su una Virtual Private Network in cui è stato ricavato uno spazio IP dedicato e suddiviso in tre sottoreti:

  • DMZ: zona dedicata ai servizi di accesso e front-end per i portali Sharepoint. Questa zona sta già alle spalle del firewall condiviso EC2. Qui sono allocati i server di accesso per le VPN (Windows RRAS ed un server di emergenza normalmente spento basato Linux OpenSwan). Ai server di produzione si accede solo via VPN.

  • Application: zona dedicata agli application server

  • Data base: zona dedicata ai servizi di database SQL Server. Oracle è allocato su una istanza RDS in carico ad Amazon.

L’allestimento ha seguito i seguenti passi:

  • E’ stato allestito il servizio di backup basato su salvataggi su S3 (Simple Storage Services) e snapshots EBS per le immagini di sistema.

  • Per ogni server dell’infrastruttura originale in ambiente Windows 2003 è stata allocata una istanza in ambiente Windows 2008 R2.

  • Sono stati allocati i servers indispensabili per la costruzione dell’architettura di Active Directory.

  • Per la migrazione di AD è stata allestita una VPN tra la vecchia e la nuova infrastruttura; la nuova è stata considerata inizialmente come una sede remota con un controller di dominio locale.

  • E’ stata eseguita la sincronizzazione e quindi migrati i ruoli principali dal vecchio al nuovo controller di dominio.

  • Sono state installate le applicazioni e trasferiti i dati statici (documenti) presenti sulla vecchia infrastruttura.

  • Sono stati trasferiti i backup delle banche dati utilizzati poi per un primo ripristino.

  • E’ stato realizzato un sistema di sincronizzazione di documenti e banche dati da utilizzare al momento dello switchover. Si è fatto largo uso di Rsync e tecniche di invio dei log (Oracle Dataguard e SQL Server log shipping) per la sincronizzazione delle banche dati più grandi.

  • Definizione dei test-case da applicare a fine switchover.

La fase si è conclusa con il test dei sistemi e delle procedure.

Fase 3: switchover

Fortunatamente la compressione applicata ai backup ha permesso di ridurre i 700GB di occupazione delle banche dati a poco più di un centinaio di GB da trasferire. Operazione fattibile con un fermo del servizio di meno di 12 ore. In caso di problemi si sarebbe riattivata la vecchia infrastruttura e rinviato di una settimana lo switchover.

Per cui le operazioni eseguite per il passaggio alla nuova infrastruttura sono stati i seguenti:

  • Fermo del servizio alle 20 di un sabato sera.

  • Completamento dei trasferimenti dei backup, dei log delle due banche dati di dimensione superiore ai 100GB e dei documenti.

  • Applicazione dei log.

  • Ripristino dai backup ricevuti al punto 2.

  • Test generale come definito nei test cases progettati.

  • Modifica dei puntamenti ai nuovi server nel DNS Server pubblico.

  • Apertura del servizio alle 9 della domenica.

  • Migrazione P2V per una coppia di server a fine vite mediante il servizio VM Import di AWS.

Payoff

La riduzione del costo dei servizi di hosting è l’elemento più evidente con un risparmio di oltre il 70% rispetto ai costi mensili del vecchio servizio di co-location. Il risparmio è derivato anche da una operazione di consolidamento operata durante la migrazione.

Da un punto di vista qualitativo alcuni miglioramenti sono legati ovviamente alla virtualizzazione della infrastruttura come la possibilità di allestire un servizio di prova per i nuovi clienti mediante la clonazione di istanze pre-configurate e l’ampliamento delle risorse disponibili per l’acquisizione di nuovi clienti.

Progettato e realizzato da newits.it con l'aiuto di pixelsparadise.com e flexslider di madebymufffin. PRIVACY POLICY qui!.

Back to top