Seth Noble er grundlægger og præsident for Data Expedition.
At flytte terabyte eller endda petabyte data til skyen er en skræmmende opgave. Men det er vigtigt at se ud over antallet af byte. Du ved sikkert, at dine applikationer vil opføre sig anderledes, når de åbnes i skyen, at omkostningsstrukturer vil være forskellige (forhåbentlig bedre), og at det vil tage tid at flytte alle disse data.
Fordi min virksomhed, Data Expedition, er i gang med dataoverførsel med høj ydeevne, kommer kunder til os, når de forventer, at netværkshastighed er et problem. Men i processen med at hjælpe virksomheder med at overvinde dette problem har vi set mange andre faktorer, der truer med at afspore skymigrationer, hvis de overses.
Indsamling, organisering, formatering og validering af dine data kan byde på meget større udfordringer end at flytte dem. Her er nogle almindelige faktorer, der skal overvejes i planlægningsfasen af en skymigration, så du kan undgå tidskrævende og dyre problemer senere.
Cloudmigrationsflaskehals nr. 1: Datalagring
Den mest almindelige fejl, vi ser i cloudmigrationer, er at skubbe data ind i skylagring uden at overveje, hvordan disse data vil blive brugt. Den typiske tankeproces er, "Jeg vil placere mine dokumenter og databaser i skyen, og objektopbevaring er billig, så jeg lægger mine dokument- og databasefiler der." Men filer, objekter og databaser opfører sig meget forskelligt. At sætte dine byte i den forkerte kan forringe dine skyplaner.
Filer er organiseret ved et hierarki af stier, et katalogtræ. Der er hurtig adgang til hver fil med minimal latenstid (tid til første byte) og høj hastighed (bits pr. Sekund, når dataene begynder at flyde). Individuelle filer kan let flyttes, omdøbes og ændres ned til byte-niveau. Du kan have mange små filer, et lille antal store filer eller en hvilken som helst blanding af størrelser og datatyper. Traditionelle applikationer kan få adgang til filer i skyen ligesom de ville have lokaler uden nogen særlig skybevidsthed.
Alle disse fordele gør filbaseret lagring til den dyreste mulighed, men lagring af filer i skyen har et par andre ulemper. For at opnå høj ydeevne kan de fleste skybaserede filsystemer (som Amazon EBS) kun få adgang til en skybaseret virtuel maskine ad gangen, hvilket betyder, at alle applikationer, der har brug for disse data, skal køre på en enkelt cloud-VM. For at kunne betjene flere virtuelle computere (som Azure Files) kræves fronting af lageret med en NAS-protokol (netværksbundet lager) som SMB, hvilket kan begrænse ydeevnen alvorligt. Filsystemer er hurtige, fleksible og ældre kompatible, men de er dyre, kun nyttige til applikationer, der kører i skyen, og skalerer ikke godt.
Objekter er ikke filer. Husk det, fordi det er let at glemme. Objekter lever i et fladt navneområde, som et kæmpe bibliotek. Latency er høj, undertiden hundreder eller tusinder af millisekunder, og kapaciteten er lav, og ofte topper ud omkring 150 megabit i sekundet, medmindre der bruges kloge tricks. Meget om adgang til objekter kommer ned til smarte tricks som upload af flere dele, adgang til byteområde og optimering af nøglenavne. Objekter kan læses af mange cloud-native og webbaserede applikationer på én gang, både inden for og uden for skyen, men traditionelle applikationer kræver ydelseslemmende løsninger. De fleste grænseflader til at få adgang til objektlagring får objekter til at ligne filer: nøglenavne filtreres efter præfiks for at ligne mapper, brugerdefinerede metadata er knyttet til objekter for at se ud som filmetadata, og nogle systemer som FUSE-cacheobjekter på et VM-filsystem for at give adgang ved traditionelle applikationer. Men sådanne løsninger er skøre og SAP-præstationer. Cloud-lager er billigt, skalerbart og cloud native, men det er også langsomt og vanskeligt at få adgang til.
Databaser har deres egen komplekse struktur, og de får adgang til forespørgselssprog som SQL. Traditionelle databaser kan være bakket op af lagring af filer, men de kræver en live databaseproces for at kunne levere forespørgsler. Dette kan løftes ind i skyen ved at kopiere databasefiler og applikationer til en VM eller ved at migrere dataene til en skyhostet databasetjeneste. Men kopiering af en databasefil til objektlagring er kun nyttig som offline backup. Databaser skaleres godt som en del af en skyhostet tjeneste, men det er afgørende at sikre, at de applikationer og processer, der afhænger af databasen, er fuldt kompatible og cloud-native. Databaselagring er meget specialiseret og applikationsspecifik.
At afbalancere de tilsyneladende omkostningsbesparelser ved objektlagring mod funktionaliteten i filer og databaser kræver nøje overvejelse af præcis, hvilken funktionalitet der kræves. Hvis du f.eks. Vil gemme og distribuere mange tusinde små filer, skal du arkivere dem i en ZIP-fil og gemme det som et enkelt objekt i stedet for at prøve at gemme hver enkelt fil som et separat objekt. Forkerte opbevaringsvalg kan føre til komplekse afhængigheder, der er vanskelige og dyre at ændre senere.
Cloud migration flaskehals nr. 2: Dataforberedelse
At flytte data til skyen er ikke så simpelt som at kopiere bytes til den angivne lagringstype. En masse forberedelser skal ske, før noget kopieres, og den tid kræver omhyggelig budgettering. Proof-of-concept-projekter ignorerer ofte dette trin, hvilket kan føre til dyre overskridelser senere.
Filtrering af unødvendige data kan spare meget tid og lageromkostninger. For eksempel kan et datasæt indeholde sikkerhedskopier, tidligere versioner eller ridsefiler, der ikke behøver at være en del af cloudworkflowet. Måske er den vigtigste del af filtrering at prioritere, hvilke data der først skal flyttes. Data, der bruges aktivt, tåler ikke at være ude af synkronisering i de uger, måneder eller år, det tager at gennemføre hele migreringsprocessen. Nøglen her er at komme med et automatiseret middel til at vælge, hvilke data der skal sendes, og hvornår, så hold nøje registreringer af alt, hvad der er og ikke er gjort.
Forskellige cloud-arbejdsgange kan kræve, at dataene er i et andet format eller en anden organisation end lokale applikationer. For eksempel kan en lovlig arbejdsgang kræve at oversætte tusinder af små Word- eller PDF-dokumenter og pakke dem i ZIP-filer, en medieworkflow kan involvere transkodning og metadataindpakning, og en bioinformatik-arbejdsgang kan kræve plukning og iscenesættelse af terabyte genomforskningsdata. Sådan omformatering kan være en intenst manuel og tidskrævende proces. Det kan kræve en masse eksperimenter, en masse midlertidig opbevaring og en masse undtagelsesbehandling. Nogle gange er det fristende at udskyde enhver omformatering til skymiljøet, men husk at dette ikke løser problemet, det skifter det bare til et miljø, hvor enhver ressource, du bruger, har en pris.
En del af spørgsmålene om opbevaring og formatering kan omfatte beslutninger om komprimering og arkivering. For eksempel giver det mening at ZIP millioner af små tekstfiler, inden de sendes til skyen, men ikke en håndfuld multigigabyte mediefiler. Arkivering og komprimering af data gør det lettere at overføre og gemme data, men overvej den tid og lagerplads, det tager at pakke og pakke ud af arkiverne i begge ender.
Cloud migration flaskehals nr. 3: Validering af oplysninger
Integritetskontrol er det vigtigste trin og også det nemmeste at tage fejl. Ofte antages det, at korruption vil forekomme under datatransporten, hvad enten det er ved fysisk medie eller netværksoverførsel, og kan fanges ved at udføre kontrolsum før og efter. Kontrolsummer er en vital del af processen, men det er faktisk forberedelse og import af de data, hvor du mest sandsynligt vil lide tab eller korruption.
Når data skifter formater og applikationer, kan betydning og funktionalitet gå tabt, selv når byte er de samme. En simpel inkompatibilitet mellem softwareversioner kan gøre petabytes med “korrekte” data ubrugelige. At komme med en skalerbar proces for at kontrollere, at dine data er både korrekte og anvendelige, kan være en skræmmende opgave. I værste fald kan det fordele sig til en arbejdskrævende og upræcis manuel proces med "det ser okay ud for mig." Men selv det er bedre end slet ingen validering. Det vigtigste er at sikre, at du er i stand til at genkende problemer, før de ældre systemer nedlægges!
Cloud migration flaskehals nr. 4: Overfør marskalering
Når du løfter et enkelt system til skyen, er det relativt let bare at kopiere de forberedte data til fysiske medier eller skubbe dem over internettet. Men denne proces kan være vanskelig at skalere, især for fysiske medier. Hvad der synes "simpelt" i et proof-of-concept kan ballonere til "mareridt", når mange og varierede systemer spiller ind.
En medieenhed, såsom en AWS Snowball, skal være forbundet til hver maskine. Det kan betyde, at man fysisk går rundt i et eller flere datacentre, jonglerer stik, opdaterer drivere og installerer software. Forbindelse via det lokale netværk sparer den fysiske bevægelse, men softwareopsætning kan stadig være udfordrende, og kopieringshastigheden kan falde til langt under, hvad der kan opnås med en direkte upload af internettet. Overførsel af data direkte fra hver maskine over Internettet gemmer mange trin, især hvis dataene er cloud-ready.
Hvis dataforberedelse indebærer kopiering, eksport, omformatering eller arkivering, kan lokal opbevaring blive en flaskehals. Det kan være nødvendigt at oprette dedikeret lagring til at iscenesætte de forberedte data. Dette har fordelen ved at tillade mange systemer at udføre forberedelse parallelt og reducerer kontaktpunkterne for medie- og dataoverførselssoftware, der kan overføres til kun et system.
Cloudmigrationsflaskehals nr. 5: Dataoverførsel
Når man sammenligner netværksoverførsel med medieforsendelse, er det let at fokusere på bare leveringstiden. For eksempel kan en 80 terabyte AWS Snowball-enhed sendes med kurér den næste dag og opnå en tilsyneladende datahastighed på mere end otte gigabit pr. Sekund. Men dette ignorerer den tid, det tager at erhverve enheden, konfigurere og indlæse den, forberede den til returnering og tillade cloud-leverandøren at kopiere dataene fra i back-end. Kunder af os, der gør dette, rapporterer regelmæssigt, at fire-ugers leveringstider (fra bestilling af enheder til data tilgængelige i skyen) er almindelige. Det bringer den faktiske dataoverførselshastighed for forsendelse af enheden ned til kun 300 megabit pr. Sekund, meget mindre, hvis enheden ikke er helt fyldt.
Netværksoverførselshastigheder afhænger ligeledes af en række faktorer, først og fremmest den lokale uplink. Du kan ikke sende data hurtigere end den fysiske bithastighed, men omhyggelig dataforberedelse kan reducere den mængde data, du skal sende. Ældre protokoller, inklusive dem, som cloud-leverandører bruger som standard til objektlagring, har problemer med hastighed og pålidelighed på tværs af internetstier, hvilket kan gøre det vanskeligt at opnå denne bithastighed. Jeg kunne skrive mange artikler om de udfordringer, der er involveret her, men dette er en, du ikke selv skal løse. Data Expedition er et af få virksomheder, der specialiserer sig i at sikre, at stien udnyttes fuldt ud, uanset hvor langt væk dine data er fra dens cloud-destination. For eksempel giver en gigabit internetforbindelse med accelerationssoftware som CloudDat 900 megabit pr. Sekund, tre gange nettoeffekten af en AWS Snowball.
Den største forskel mellem fysisk forsendelse og netværksoverførsel er også en af de mest overset under proof-of-concept. Ved fysisk forsendelse skal den første byte, du lægger på enheden, vente, indtil den sidste byte er indlæst, før du kan sende. Dette betyder, at hvis det tager uger at indlæse enheden, vil nogle af dine data være uger forældede, når det ankommer i skyen. Selv når datasæt når petabyte-niveauer, hvor fysisk forsendelse muligvis er hurtigere overhovedet, kan muligheden for at holde prioritetsdata opdateret under migrationsprocessen muligvis stadig favorisere netværksoverførsel for nøgleaktiver. Omhyggelig planlægning under filtrerings- og prioriteringsfasen af dataforberedelse er vigtig og kan muliggøre en hybrid tilgang.
At få dataene til en skyudbyder er muligvis ikke afslutningen på dataoverførselstrinnet. Hvis det skal replikeres til flere regioner eller udbydere, skal du planlægge nøje, hvordan det kommer dertil. Upload over internettet er gratis, mens AWS for eksempel opkræver op til to cent per gigabyte for interregional dataoverførsel og ni cent per gigabyte for overførsel til andre cloud-leverandører. Begge metoder står over for båndbreddebegrænsninger, der kan drage fordel af transportacceleration, såsom CloudDat.
Cloud migration flaskehals nr. 6: Skalering
Når data ankommer til deres destination i skyen, er migrationsprocessen kun halvt færdig. Kontrollsum kommer først: Sørg for, at de byte, der ankom, matcher dem, der blev sendt. Dette kan være vanskeligere, end du måske er klar over. Fillagring bruger lag af cacher, der kan skjule korruption af data, der netop blev uploadet. Sådan korruption er sjælden, men indtil du har ryddet alle af cacherne og genlæser filerne, kan du ikke være sikker på nogen kontrolsummer. Genstart af forekomsten eller afmontering af lageret gør et acceptabelt arbejde med at rydde cacher.
Validering af kontrollag for objektlagring kræver, at hvert objekt læses op i en instans til beregning. I modsætning til hvad mange tror, er objektet "E-tags" det ikke nyttigt som kontrolsummer. Især genstande, der uploades ved hjælp af flerdelt teknikker, kan kun valideres ved at læse dem tilbage.
