6 colli di bottiglia nascosti nella migrazione dei dati nel cloud

Seth Noble è fondatore e presidente di Data Expedition.

Spostare terabyte o addirittura petabyte di dati nel cloud è un compito arduo. Ma è importante guardare oltre il numero di byte. Probabilmente sai che le tue applicazioni si comporteranno in modo diverso quando si accede nel cloud, che le strutture dei costi saranno diverse (si spera migliori) e che ci vorrà del tempo per spostare tutti quei dati.

Poiché la mia azienda, Data Expedition, opera nel settore del trasferimento di dati ad alte prestazioni, i clienti si rivolgono a noi quando si aspettano che la velocità della rete sia un problema. Ma nel processo di aiutare le aziende a superare questo problema, abbiamo visto molti altri fattori che minacciano di far deragliare le migrazioni cloud se trascurati.

La raccolta, l'organizzazione, la formattazione e la convalida dei dati possono presentare sfide molto più grandi rispetto allo spostamento. Di seguito sono riportati alcuni fattori comuni da considerare nelle fasi di pianificazione di una migrazione al cloud, in modo da evitare problemi lunghi e costosi in un secondo momento.

Collo di bottiglia della migrazione al cloud n. 1: archiviazione dei dati

L'errore più comune che vediamo nelle migrazioni nel cloud è il trasferimento dei dati nell'archiviazione cloud senza considerare come verranno utilizzati tali dati. Il tipico processo di pensiero è: "Voglio mettere i miei documenti e database nel cloud e l'archiviazione degli oggetti costa poco, quindi inserirò lì i miei documenti e i file del database". Ma file, oggetti e database si comportano in modo molto diverso. Mettere i tuoi byte in quello sbagliato può paralizzare i tuoi piani cloud.

I file sono organizzati da una gerarchia di percorsi, un albero di directory. È possibile accedere rapidamente a ciascun file, con una latenza minima (tempo al primo byte) e ad alta velocità (bit al secondo una volta che i dati iniziano a fluire). I singoli file possono essere facilmente spostati, rinominati e modificati fino al livello di byte. Puoi avere molti file di piccole dimensioni, un numero ridotto di file di grandi dimensioni o qualsiasi combinazione di dimensioni e tipi di dati. Le applicazioni tradizionali possono accedere ai file nel cloud proprio come farebbero in locale, senza alcuna speciale consapevolezza del cloud.

Tutti questi vantaggi rendono l'archiviazione basata su file l'opzione più costosa, ma l'archiviazione di file nel cloud presenta alcuni altri svantaggi. Per ottenere prestazioni elevate, è possibile accedere alla maggior parte dei file system basati su cloud (come Amazon EBS) solo da una macchina virtuale basata su cloud alla volta, il che significa che tutte le applicazioni che richiedono quei dati devono essere eseguite su una singola VM cloud. Per servire più macchine virtuali (come File di Azure) è necessario far fronte all'archiviazione con un protocollo NAS (archiviazione collegata alla rete) come SMB, che può limitare notevolmente le prestazioni. I file system sono veloci, flessibili e compatibili con le versioni precedenti, ma sono costosi, utili solo per le applicazioni in esecuzione nel cloud e non si adattano bene.

Gli oggetti non sono file. Ricordalo, perché è facile dimenticarlo. Gli oggetti vivono in uno spazio dei nomi piatto, come una directory gigante. La latenza è alta, a volte centinaia o migliaia di millisecondi e la velocità effettiva è bassa, spesso raggiungendo circa 150 megabit al secondo a meno che non vengano utilizzati trucchi intelligenti. Molto dell'accesso agli oggetti si riduce a trucchi intelligenti come il caricamento in più parti, l'accesso all'intervallo di byte e l'ottimizzazione del nome della chiave. Gli oggetti possono essere letti da molte applicazioni native del cloud e basate sul Web contemporaneamente, sia all'interno che all'esterno del cloud, ma le applicazioni tradizionali richiedono soluzioni alternative che riducono le prestazioni. La maggior parte delle interfacce per l'accesso all'archiviazione degli oggetti rende gli oggetti simili a file: i nomi delle chiavi vengono filtrati in base al prefisso per sembrare cartelle, i metadati personalizzati sono allegati agli oggetti per apparire come metadati di filee alcuni sistemi come FUSE cache di oggetti su un file system VM per consentire l'accesso da parte delle applicazioni tradizionali. Ma tali soluzioni alternative sono fragili e indeboliscono le prestazioni. Lo storage nel cloud è economico, scalabile e nativo del cloud, ma è anche lento e di difficile accesso.

I database hanno una propria struttura complessa e sono accessibili tramite linguaggi di query come SQL. I database tradizionali possono essere supportati dall'archiviazione di file, ma richiedono un processo di database attivo per servire le query. Questo può essere trasferito nel cloud copiando i file e le applicazioni del database su una VM o migrando i dati in un servizio di database ospitato nel cloud. Tuttavia, la copia di un file di database nell'archivio oggetti è utile solo come backup offline. I database scalano bene come parte di un servizio ospitato nel cloud, ma è fondamentale garantire che le applicazioni ei processi che dipendono dal database siano completamente compatibili e nativi del cloud. L'archiviazione del database è altamente specializzata e specifica dell'applicazione.

Bilanciare l'apparente risparmio sui costi dell'archiviazione di oggetti con la funzionalità di file e database richiede un'attenta considerazione di quale funzionalità sia richiesta. Ad esempio, se si desidera archiviare e distribuire molte migliaia di piccoli file, archiviarli in un file ZIP e archiviarlo come un singolo oggetto invece di provare a memorizzare ogni singolo file come un oggetto separato. Scelte di archiviazione errate possono portare a dipendenze complesse che sono difficili e costose da modificare in seguito.

Collo di bottiglia della migrazione al cloud n. 2: preparazione dei dati

Spostare i dati nel cloud non è semplice come copiare i byte nel tipo di archiviazione designato. È necessaria molta preparazione prima di copiare qualsiasi cosa e quel tempo richiede un'attenta pianificazione del budget. I progetti proof-of-concept spesso ignorano questo passaggio, il che può portare a costosi sforamenti in seguito.

Filtrare i dati non necessari può far risparmiare molto tempo e costi di archiviazione. Ad esempio, un set di dati può contenere backup, versioni precedenti o file temporanei che non devono necessariamente far parte del flusso di lavoro cloud. Forse la parte più importante del filtraggio è dare la priorità ai dati che devono essere spostati per primi. I dati utilizzati attivamente non tollereranno che non siano sincronizzati per le settimane, i mesi o gli anni necessari per completare l'intero processo di migrazione. La chiave qui è trovare un mezzo automatizzato per selezionare quali dati devono essere inviati e quando, quindi tenere un'attenta registrazione di tutto ciò che è e non viene fatto.

Flussi di lavoro cloud diversi potrebbero richiedere che i dati siano in un formato o un'organizzazione diversi rispetto alle applicazioni locali. Ad esempio, un flusso di lavoro legale potrebbe richiedere la traduzione di migliaia di piccoli documenti Word o PDF e il loro impacchettamento in file ZIP, un flusso di lavoro multimediale potrebbe comportare la transcodifica e il confezionamento di metadati e un flusso di lavoro bioinformatico potrebbe richiedere la raccolta e la messa in scena di terabyte di dati genomici. Tale riformattazione può essere un processo estremamente manuale e dispendioso in termini di tempo. Potrebbe richiedere molti esperimenti, molto spazio di archiviazione temporaneo e molta gestione delle eccezioni. A volte si è tentati di rimandare qualsiasi riformattazione all'ambiente cloud, ma ricorda che questo non risolve il problema, lo sposta semplicemente in un ambiente in cui ogni risorsa che utilizzi ha un prezzo.

Parte delle domande relative all'archiviazione e alla formattazione possono comportare decisioni sulla compressione e l'archiviazione. Ad esempio, ha senso ZIP milioni di piccoli file di testo prima di inviarli al cloud, ma non una manciata di file multimediali multi-gigabyte. L'archiviazione e la compressione dei dati semplifica il trasferimento e l'archiviazione dei dati, ma considera il tempo e lo spazio di archiviazione necessari per comprimere e decomprimere quegli archivi alle due estremità.

Collo di bottiglia della migrazione al cloud n. 3: convalida delle informazioni

Il controllo dell'integrità è il passaggio più importante e anche il più facile da sbagliare. Spesso si presume che il danneggiamento si verifichi durante il trasporto dei dati, sia che si tratti di un supporto fisico o di un trasferimento di rete, e che possa essere rilevato eseguendo checksum prima e dopo. I checksum sono una parte vitale del processo, ma in realtà è la preparazione e l'importazione dei dati in cui è più probabile che si subisca una perdita o il danneggiamento.

Quando i dati cambiano formati e applicazioni, il significato e la funzionalità possono essere persi anche quando i byte sono gli stessi. Una semplice incompatibilità tra le versioni del software può rendere inutili petabyte di dati "corretti". Elaborare un processo scalabile per verificare che i dati siano corretti e utilizzabili può essere un compito arduo. Nel peggiore dei casi, potrebbe trasformarsi in un processo manuale laborioso e impreciso di "mi sembra a posto". Ma anche questo è meglio che non convalidare affatto. La cosa più importante è assicurarsi di essere in grado di riconoscere i problemi prima che i sistemi legacy vengano disattivati!

Collo di bottiglia della migrazione al cloud n. 4: trasferimento del marshalling

Quando si solleva un singolo sistema nel cloud, è relativamente facile copiare semplicemente i dati preparati su un supporto fisico o inviarli tramite Internet. Ma questo processo può essere difficile da scalare, soprattutto per i supporti fisici. Ciò che sembra "semplice" in un proof-of-concept può diventare un "incubo" quando entrano in gioco molti e vari sistemi.

Un dispositivo multimediale, come AWS Snowball, deve essere connesso a ciascuna macchina. Ciò potrebbe significare camminare fisicamente con il dispositivo in uno o più data center, destreggiarsi tra i connettori, aggiornare i driver e installare software. La connessione alla rete locale consente di risparmiare il movimento fisico, ma la configurazione del software può comunque essere impegnativa e la velocità di copia potrebbe scendere ben al di sotto di quanto si potrebbe ottenere con un caricamento diretto su Internet. Il trasferimento dei dati direttamente da ogni macchina su Internet consente di risparmiare molti passaggi, soprattutto se i dati sono pronti per il cloud.

Se la preparazione dei dati prevede la copia, l'esportazione, la riformattazione o l'archiviazione, l'archiviazione locale può diventare un collo di bottiglia. Potrebbe essere necessario impostare un archivio dedicato per mettere in scena i dati preparati. Ciò ha il vantaggio di consentire a molti sistemi di eseguire la preparazione in parallelo e riduce i punti di contatto per i supporti spedibili e il software di trasferimento dati a un solo sistema.

Collo di bottiglia della migrazione al cloud n. 5: trasferimento dei dati

Quando si confronta il trasferimento di rete con la spedizione di supporti, è facile concentrarsi solo sul tempo di spedizione. Ad esempio, un dispositivo AWS Snowball da 80 terabyte potrebbe essere inviato tramite corriere il giorno successivo, raggiungendo una velocità dati apparente di oltre otto gigabit al secondo. Ma questo ignora il tempo necessario per acquisire il dispositivo, configurarlo e caricarlo, prepararlo per la restituzione e consentire al fornitore del cloud di copiare i dati sul back-end. I nostri clienti che lo fanno regolarmente segnalano che i tempi di consegna di quattro settimane (dall'ordinazione del dispositivo ai dati disponibili nel cloud) sono comuni. Ciò riduce la velocità di trasferimento dati effettiva della spedizione del dispositivo a soli 300 megabit al secondo, molto meno se il dispositivo non è completamente pieno.

Allo stesso modo, le velocità di trasferimento di rete dipendono da una serie di fattori, primo fra tutti l'uplink locale. Non è possibile inviare dati più velocemente del bit rate fisico, sebbene un'attenta preparazione dei dati possa ridurre la quantità di dati che è necessario inviare. I protocolli legacy, inclusi quelli che i fornitori di cloud utilizzano per impostazione predefinita per l'archiviazione di oggetti, hanno difficoltà con la velocità e l'affidabilità su percorsi Internet a lunga distanza, il che può rendere difficile raggiungere tale velocità in bit. Potrei scrivere molti articoli sulle sfide coinvolte qui, ma questa non è una che devi risolvere da solo. Data Expedition è una delle poche aziende specializzate nell'assicurare che il percorso sia completamente utilizzato indipendentemente dalla distanza dei dati dalla loro destinazione cloud. Ad esempio, una connessione Internet gigabit con software di accelerazione come CloudDat produce 900 megabit al secondo,tre volte il throughput netto di un AWS Snowball.

La più grande differenza tra la spedizione fisica e il trasferimento di rete è anche una delle più comunemente trascurate durante il proof-of-concept. Con la spedizione fisica, il primo byte caricato sul dispositivo deve attendere il caricamento dell'ultimo byte prima di poterlo spedire. Ciò significa che se sono necessarie settimane per caricare il dispositivo, alcuni dei tuoi dati saranno scaduti di settimane quando arriveranno nel cloud. Anche quando i set di dati raggiungono i livelli di petabyte in cui la spedizione fisica può essere più veloce, la capacità di mantenere aggiornati i dati prioritari durante il processo di migrazione può comunque favorire il trasferimento di rete per le risorse chiave. Un'attenta pianificazione durante la fase di filtraggio e definizione delle priorità della preparazione dei dati è essenziale e può consentire un approccio ibrido.

Il trasferimento dei dati in un provider cloud potrebbe non essere la fine della fase di trasferimento dei dati. Se deve essere replicato su più regioni o provider, pianifica attentamente come raggiungerlo. Il caricamento su Internet è gratuito, mentre AWS, ad esempio, addebita fino a due centesimi per gigabyte per il trasferimento dati interregionale e nove centesimi per gigabyte per il trasferimento ad altri fornitori di cloud. Entrambi i metodi dovranno affrontare limitazioni di larghezza di banda che potrebbero trarre vantaggio dall'accelerazione del trasporto come CloudDat.

Collo di bottiglia della migrazione al cloud n. 6: scalabilità del cloud

Una volta che i dati arrivano a destinazione nel cloud, il processo di migrazione è terminato solo a metà. I checksum vengono prima: assicurati che i byte che sono arrivati ​​corrispondano a quelli che sono stati inviati. Questo può essere più complicato di quanto tu possa immaginare. L'archiviazione dei file utilizza livelli di cache che possono nascondere il danneggiamento dei dati appena caricati. Tale danneggiamento è raro, ma finché non hai cancellato tutte le cache e riletto i file, non puoi essere sicuro di alcun checksum. Il riavvio dell'istanza o lo smontaggio della memoria esegue un lavoro tollerabile di cancellazione delle cache.

La convalida dei checksum di archiviazione degli oggetti richiede che ogni oggetto venga letto in un'istanza per il calcolo. Contrariamente alla credenza popolare, gli oggetti "E-tag" non sono utili come checksum. Gli oggetti caricati utilizzando tecniche multiparte, in particolare, possono essere convalidati solo leggendoli nuovamente.