Seth Noble er grunnlegger og president for Data Expedition.
Å flytte terabyte eller til og med petabyte med data til skyen er en skremmende oppgave. Men det er viktig å se utover antall byte. Du vet sannsynligvis at applikasjonene dine vil oppføre seg annerledes når de åpnes i skyen, at kostnadsstrukturer vil være forskjellige (forhåpentligvis bedre), og at det vil ta tid å flytte alle dataene.
Fordi selskapet mitt, Data Expedition, driver med dataoverføring med høy ytelse, kommer kunder til oss når de forventer at nettverkshastighet er et problem. Men i ferd med å hjelpe selskaper med å løse dette problemet, har vi sett mange andre faktorer som truer med å spore skymigrasjoner hvis de blir oversett.
Å samle inn, organisere, formatere og validere dataene dine kan by på mye større utfordringer enn å flytte dem. Her er noen vanlige faktorer du bør vurdere i planleggingsfasen av en skymigrasjon, slik at du kan unngå tidkrevende og dyre problemer senere.
Flaskhals for migrering av nettsky nr. 1: Datalagring
Den vanligste feilen vi ser i skymigrering er å skyve data inn i skylagring uten å vurdere hvordan dataene skal brukes. Den typiske tankeprosessen er: "Jeg vil legge dokumentene og databasene mine i skyen, og objektlagring er billig, så jeg legger dokumentene og databasefilene mine der." Men filer, objekter og databaser oppfører seg veldig annerledes. Å sette byte i feil kan forringe skyplanene dine.
Filer er organisert av et hierarki av stier, et katalogtre. Hver fil kan nås raskt, med minimal ventetid (tid til første byte) og høy hastighet (biter per sekund når dataene begynner å strømme). Individuelle filer kan enkelt flyttes, gi nytt navn og endres til byte-nivå. Du kan ha mange små filer, et lite antall store filer eller en hvilken som helst blanding av størrelser og datatyper. Tradisjonelle applikasjoner kan få tilgang til filer i skyen akkurat som de ville gjort i lokalene, uten spesiell skybevissthet.
Alle disse fordelene gjør filbasert lagring til det dyreste alternativet, men lagring av filer i skyen har noen få andre ulemper. For å oppnå høy ytelse har de fleste skybaserte filsystemer (som Amazon EBS) tilgang til bare en skybasert virtuell maskin om gangen, noe som betyr at alle applikasjoner som trenger dataene, må kjøres på en enkelt sky-VM. For å betjene flere virtuelle maskiner (som Azure Files), krever fronting lagring med en NAS-protokoll (nettverkstilkoblet lagring) som SMB, noe som kan begrense ytelsen sterkt. Filsystemer er raske, fleksible og eldre kompatible, men de er dyre, bare nyttige for applikasjoner som kjører i skyen, og skalerer ikke godt.
Objekter er ikke filer. Husk det, fordi det er lett å glemme. Objekter bor i et flatt navnerom, som en gigantisk katalog. Forsinkelsen er høy, noen ganger hundrevis eller tusenvis av millisekunder, og gjennomstrømningen er lav, og fyller ofte rundt 150 megabit per sekund med mindre smarte triks brukes. Mye om å få tilgang til objekter kommer ned til smarte triks som opplasting i flere deler, tilgang til byteområde og optimalisering av nøkkelnavn. Objekter kan leses av mange skyinnfødte og nettbaserte applikasjoner på en gang, både innenfor og utenfor skyen, men tradisjonelle applikasjoner krever ytelseslammende løsninger. De fleste grensesnitt for tilgang til objektlagring får objekter til å se ut som filer: nøkkelnavn filtreres etter prefiks for å se ut som mapper, egendefinerte metadata er festet til objekter for å se ut som filmetadata, og noen systemer som FUSE cache-objekter på et VM-filsystem for å gi tilgang av tradisjonelle applikasjoner. Men slike løsninger er sprø og sap ytelse. Skylagring er billig, skalerbar og skyinnfødt, men det er også tregt og vanskelig tilgjengelig.
Databaser har sin egen komplekse struktur, og de får tilgang til spørringsspråk som SQL. Tradisjonelle databaser kan være støttet av fillagring, men de krever en live databaseprosess for å kunne stille spørsmål. Dette kan løftes inn i skyen ved å kopiere databasefilene og applikasjonene til en VM, eller ved å migrere dataene til en skyvert databasetjeneste. Men å kopiere en databasefil til objektlagring er bare nyttig som sikkerhetskopiering uten nett. Databaser skalerer seg godt som en del av en skyhostet tjeneste, men det er viktig å sikre at applikasjonene og prosessene som er avhengig av databasen, er fullt kompatible og skyinnfødte. Databaselagring er høyt spesialisert og applikasjonsspesifikk.
Å balansere de tilsynelatende kostnadsbesparelsene på objektlagring mot funksjonaliteten til filer og databaser krever nøye vurdering av nøyaktig hvilken funksjonalitet som kreves. Hvis du for eksempel vil lagre og distribuere mange tusen små filer, arkiverer du dem i en ZIP-fil og lagrer det som et enkelt objekt i stedet for å prøve å lagre hver enkelt fil som et eget objekt. Feil lagringsvalg kan føre til komplekse avhengigheter som det er vanskelig og dyrt å endre senere.
Flaskhals for migrering av nettsky 2: Dataforberedelse
Å flytte data til skyen er ikke så enkelt som å kopiere byte til den angitte lagringstypen. Mye forberedelser må skje før noe kopieres, og den tiden krever nøye budsjettering. Proof-of-concept-prosjekter ignorerer ofte dette trinnet, noe som kan føre til kostbare overskridelser senere.
Filtrering av unødvendige data kan spare mye tid og lagringskostnader. Et datasett kan for eksempel inneholde sikkerhetskopier, tidligere versjoner eller skrapefiler som ikke trenger å være en del av arbeidsflyten i skyen. Den kanskje viktigste delen av filtrering er å prioritere hvilke data som må flyttes først. Data som brukes aktivt tåler ikke å være ute av synkronisering i løpet av ukene, månedene eller årene det tar å fullføre hele migreringsprosessen. Nøkkelen her er å komme opp med et automatisert middel for å velge hvilke data som skal sendes og når, og deretter føre nøye oversikt over alt som er og ikke er gjort.
Forskjellige arbeidsflyter i skyen kan kreve at dataene har et annet format eller en annen organisasjon enn lokale applikasjoner. For eksempel kan en lovlig arbeidsflyt kreve å oversette tusenvis av små Word- eller PDF-dokumenter og pakke dem i ZIP-filer, en mediearbeidsflyt kan involvere transkoding og metadatapakking, og en arbeidsinformasjon for bioinformatikk kan kreve å plukke og iscenesette terabyte genomdata. Slik omformatering kan være en intenst manuell og tidkrevende prosess. Det kan kreve mye eksperimentering, mye midlertidig lagring og mye unntakshåndtering. Noen ganger er det fristende å utsette omformatering til skymiljøet, men husk at dette ikke løser problemet, det skifter det bare til et miljø der hver ressurs du bruker har en pris.
En del av lagrings- og formateringsspørsmålene kan innebære beslutninger om komprimering og arkivering. For eksempel er det fornuftig å ZIP millioner av små tekstfiler før du sender dem til skyen, men ikke en håndfull multigigabyte mediefiler. Arkivering og komprimering av data gjør det lettere å overføre og lagre dataene, men vurder tiden og lagringsplassen det tar å pakke og pakke ut arkivene i hver ende.
Flaskhals for migrering av nettsky nr. 3: Validering av informasjon
Integritetskontroll er det viktigste trinnet, og også det enkleste å ta feil. Ofte antas det at korrupsjon vil oppstå under datatransporten, enten det er ved fysisk media eller nettverksoverføring, og kan fanges opp ved å utføre kontrollsummer før og etter. Sjekksummer er en viktig del av prosessen, men det er faktisk forberedelse og import av dataene der du mest sannsynlig vil lide tap eller korrupsjon.
Når data skifter formater og applikasjoner, kan mening og funksjonalitet gå tapt selv når byte er den samme. En enkel inkompatibilitet mellom programvareversjoner kan gjøre petabytes med “riktige” data ubrukelige. Å komme med en skalerbar prosess for å bekrefte at dataene dine er både riktige og brukbare, kan være en skremmende oppgave. I verste fall kan den overgå til en arbeidskrevende og upresis manuell prosess med "det ser bra ut for meg." Men selv det er bedre enn ingen validering i det hele tatt. Det viktigste er å sikre at du vil være i stand til å gjenkjenne problemer før de eldre systemene tas ut av drift!
Flaskhals for migrering av sky # 4: Overfør marshaling
Når du løfter et enkelt system til skyen, er det relativt enkelt å bare kopiere de forberedte dataene til fysiske medier eller skyve dem over Internett. Men denne prosessen kan være vanskelig å skalere, spesielt for fysiske medier. Det som virker "enkelt" i et proof-of-concept kan ballongere til "mareritt" når mange og varierte systemer spiller inn.
En medieenhet, for eksempel en AWS Snowball, må være koblet til hver maskin. Det kan bety at du fysisk går enheten rundt et eller flere datasentre, sjonglerer kontakter, oppdaterer drivere og installerer programvare. Hvis du kobler til via det lokale nettverket, sparer du den fysiske bevegelsen, men programvareoppsett kan fremdeles være utfordrende, og kopieringshastigheten kan falle til godt under det som kan oppnås med en direkte internettopplasting. Overføring av data direkte fra hver maskin over Internett sparer mange trinn, spesielt hvis dataene er skyklare.
Hvis dataklargjøring innebærer kopiering, eksport, omformatering eller arkivering, kan lokal lagring bli en flaskehals. Det kan være nødvendig å sette opp dedikert lagring for å iscenesette de utarbeidede dataene. Dette har fordelen av at mange systemer kan utføre klargjøring parallelt, og reduserer kontaktpunktene for overførbar programvare for media og dataoverføring til bare ett system.
Flaskhals nr. 5 for skymigrering: Dataoverføring
Når man sammenligner nettverksoverføring med medieforsendelse, er det enkelt å fokusere på bare leveringstiden. For eksempel kan en 80 Terabyte AWS Snowball-enhet sendes med bud neste dag, og oppnår en tilsynelatende datahastighet på mer enn åtte gigabit per sekund. Men dette ignorerer tiden det tar å anskaffe enheten, konfigurere og laste den, forberede den for retur, og la skyleverandøren kopiere dataene fra back-enden. Kunder som gjør dette, rapporterer regelmessig at det er fire ukers behandlingstid (fra enhetsbestilling til data tilgjengelig i skyen). Det bringer den faktiske dataoverføringshastigheten for å sende enheten ned til bare 300 megabit per sekund, mye mindre hvis enheten ikke er fullstendig fylt.
Nettverksoverføringshastigheter avhenger også av en rekke faktorer, først og fremst den lokale uplink. Du kan ikke sende data raskere enn den fysiske bithastigheten, men nøye dataforberedelse kan redusere datamengden du trenger å sende. Eldre protokoller, inkludert de som skyleverandører bruker som standard for objektlagring, har vanskeligheter med hastighet og pålitelighet over langdistanse Internett-stier, noe som kan gjøre det vanskelig å oppnå den bithastigheten. Jeg kunne skrevet mange artikler om utfordringene som er involvert her, men dette er en du ikke trenger å løse selv. Data Expedition er et av få selskaper som spesialiserer seg på å sikre at stien blir utnyttet fullt ut uavhengig av hvor langt borte dataene dine er fra sky destinasjonen. For eksempel gir en gigabit internettforbindelse med akselerasjonsprogramvare som CloudDat 900 megabit per sekund, tre ganger nettoverføringen til en AWS Snowball.
Den største forskjellen mellom fysisk forsendelse og nettverksoverføring er også en av de mest oversett under proof-of-concept. Ved fysisk forsendelse må den første byten du legger på enheten vente til den siste byten er lastet før du kan sende. Dette betyr at hvis det tar uker å laste inn enheten, vil noen av dataene dine være uker utdatert når de kommer til skyen. Selv når datasett når petabyte-nivåer der fysisk forsendelse kan være raskere over alt, kan muligheten til å holde prioritetsdata oppdatert under migreringsprosessen fremdeles favorisere nettverksoverføring for viktige eiendeler. Nøye planlegging under filtrerings- og prioriteringsfasen av datatilberedning er viktig, og kan tillate en hybrid tilnærming.
Å få inn dataene til en skyleverandør er kanskje ikke slutten på trinnet for dataoverføring. Hvis det må replikeres til flere regioner eller leverandører, planlegg nøye hvordan det kommer dit. Opplasting over Internett er gratis, mens AWS for eksempel tar opptil to cent per gigabyte for interregional dataoverføring og ni cent per gigabyte for overføring til andre skyleverandører. Begge metodene vil møte båndbreddebegrensninger som kan ha nytte av transportakselerasjon, for eksempel CloudDat.
Flaskhals for migrering av sky # 6: Skalering
Når data kommer til målet i skyen, er migreringsprosessen bare halvparten ferdig. Sjekksummer kommer først: Forsikre deg om at byte som ankom samsvarer med de som ble sendt. Dette kan være vanskeligere enn du kanskje skjønner. Fillagring bruker lag med cacher som kan skjule korrupsjon av data som nettopp ble lastet opp. Slik korrupsjon er sjelden, men før du har ryddet alle av cachene og lese filene på nytt, kan du ikke være sikker på noen kontrollsummer. Å starte forekomsten på nytt eller demontere lagringen gjør en tålelig jobb med å tømme hurtigbuffer.
Validering av kontrollsum for objektlagring krever at hvert objekt leses ut til en forekomst for beregning. I motsetning til hva mange tror, er objektet "E-tags" det ikke nyttig som sjekksummer. Spesielt objekter lastet opp ved bruk av flerdelt teknikker kan bare valideres ved å lese dem ut igjen.
