Seth Noble je ustanovitelj in predsednik Data Expedition.
Premikanje terabajtov ali celo petabajtov podatkov v oblak je zastrašujoča naloga. Pomembno pa je gledati dlje od števila bajtov. Verjetno veste, da se bodo vaše aplikacije ob dostopu v oblaku obnašale drugače, da bodo strukture stroškov drugačne (upamo, da bodo boljše) in da bo potreben čas, da se vsi ti podatki premaknejo.
Ker se moje podjetje Data Expedition ukvarja z visoko zmogljivim prenosom podatkov, stranke prihajajo k nam, ko pričakujejo, da bo hitrost omrežja problem. Toda v postopku pomoči podjetjem pri premagovanju tega problema smo videli še veliko drugih dejavnikov, ki bi lahko, če jih ne bi spregledali, izrinili migracije v oblaku.
Zbiranje, organiziranje, oblikovanje in preverjanje podatkov lahko predstavlja veliko večje izzive kot njihovo premikanje. Tu je nekaj pogostih dejavnikov, ki jih je treba upoštevati v fazah načrtovanja migracije v oblaku, da se boste pozneje lahko izognili zamudnim in dragim težavam.
Ozko grlo za migracijo v oblak # 1: Shranjevanje podatkov
Najpogostejša napaka, ki jo opazimo pri selitvah oblakov, je potiskanje podatkov v oblak, ne da bi upoštevali, kako bodo ti podatki uporabljeni. Tipičen miselni postopek je: "Želim svoje dokumente in zbirke podatkov shraniti v oblak, shramba predmetov pa je poceni, zato bom tja postavila svoje dokumente in datoteke zbirke podatkov." A datoteke, predmeti in zbirke podatkov se obnašajo zelo različno. Če svoje bajte postavite v napačnega, lahko to omali vaše načrte v oblaku.
Datoteke so organizirane po hierarhiji poti, drevesu imenikov. Do vsake datoteke je mogoče hitro dostopati z minimalno zakasnitvijo (čas do prvega bajta) in visoko hitrostjo (bitov na sekundo, ko podatki začnejo teči). Posamezne datoteke lahko enostavno premikate, preimenujete in spreminjate do ravni bajtov. Lahko imate veliko majhnih datotek, majhno število velikih datotek ali poljubno kombinacijo velikosti in podatkovnih vrst. Tradicionalne aplikacije lahko dostopajo do datotek v oblaku tako kot v prostorih, brez posebnega zavedanja o oblaku.
Vse te prednosti naredijo shranjevanje datotek najdražjo možnost, vendar ima shranjevanje datotek v oblaku še nekaj pomanjkljivosti. Za doseganje visoke zmogljivosti lahko večino datotečnih sistemov, ki temeljijo na oblaku (na primer Amazon EBS), hkrati dostopa samo en navidezni stroj v oblaku, kar pomeni, da morajo vse aplikacije, ki potrebujejo te podatke, delovati v enem VM v oblaku. Za strežbo več VM-jev (na primer datotek Azure) je potrebno shranjevanje shraniti s protokolom NAS (omrežno shranjeno shranjevanje), kot je SMB, kar lahko močno omeji delovanje. Datotečni sistemi so hitri, prilagodljivi in združljivi s starejšimi različicami, vendar so dragi, uporabni samo za programe, ki se izvajajo v oblaku, in se ne prilagajajo dobro.
Predmeti niso datoteke. Ne pozabite tega, saj je na to lahko pozabiti. Predmeti živijo v ravnem imenskem prostoru, kot en velikanski imenik. Latencija je velika, včasih na stotine ali tisoče milisekund, prepustnost pa nizka, pogosto doseže približno 150 megabitov na sekundo, razen če se uporabljajo pametni triki. Pri dostopu do predmetov se veliko ukvarja s pametnimi triki, kot so nalaganje več delov, dostop do obsega bajtov in optimizacija imena ključa. Predmeti lahko berejo številne aplikacije v oblaku in spletne aplikacije hkrati, tako znotraj kot zunaj oblaka, vendar tradicionalne aplikacije zahtevajo rešitve, ki oškodujejo zmogljivost. Večina vmesnikov za dostop do shrambe predmetov naredi predmete videti kot datoteke: imena ključev so filtrirana s predpono, da so videti kot mape, metapodatki po meri so pritrjeni na predmete, kot metapodatki datotek, in nekateri sistemi, kot so predpomnilniki FUSE v datotečnem sistemu VM, ki omogočajo dostop s tradicionalnimi aplikacijami. Toda takšna rešitev je krhka in nesposobna. Skladiščenje v oblaku je poceni, razširljivo in v oblaku, vendar je tudi počasno in težko dostopno.
Podatkovne baze imajo svojo zapleteno strukturo in do njih dostopajo poizvedbeni jeziki, kot je SQL. Tradicionalne zbirke podatkov so lahko podprte s pomnilnikom datotek, vendar za poizvedbe potrebujejo postopek aktivne baze podatkov. To lahko dvignete v oblak s kopiranjem datotek baze podatkov in aplikacij v VM ali s selitvijo podatkov v storitev baze podatkov, ki jo gosti v oblaku. Kopiranje datoteke baze podatkov v shrambo objektov pa je koristno le kot varnostna kopija brez povezave. Podatkovne baze se dobro razširijo kot del storitve, ki jo gosti v oblaku, vendar je ključnega pomena zagotoviti, da so aplikacije in procesi, ki so odvisni od baze podatkov, popolnoma združljivi in vgrajeni v oblak. Shranjevanje baz podatkov je zelo specializirano in specifično za posamezne programe.
Za uravnoteženje navideznega prihranka stroškov shranjevanja predmetov glede na funkcionalnost datotek in baz podatkov je treba natančno pretehtati, katere natančno funkcije so potrebne. Če želite na primer shraniti in distribuirati več tisoč majhnih datotek, jih arhivirajte v datoteko ZIP in shranite kot en predmet, namesto da bi poskušali vsako posamezno datoteko shraniti kot ločen predmet. Nepravilne izbire shrambe lahko vodijo do zapletenih odvisnosti, ki jih je kasneje težko in drago spremeniti.
Ozko grlo za migracijo v oblak št. 2: Priprava podatkov
Prenos podatkov v oblak ni tako preprost kot kopiranje bajtov v določeno vrsto pomnilnika. Preden se kar koli kopira, se je treba veliko pripraviti in ta čas zahteva skrbno pripravo proračuna. Projekti z dokazovanjem koncepta ta korak pogosto ignorirajo, kar lahko kasneje povzroči drage prekoračitve.
S filtriranjem nepotrebnih podatkov lahko prihranite veliko časa in stroškov shranjevanja. Nabor podatkov lahko na primer vsebuje varnostne kopije, starejše različice ali datoteke s praskami, ki jih ni treba vključiti v potek dela v oblaku. Morda je najpomembnejši del filtriranja določanje prednosti, katere podatke je treba najprej premakniti. Podatki, ki se aktivno uporabljajo, ne bodo dopuščali neskladnosti v tednih, mesecih ali letih, potrebnih za dokončanje celotnega postopka selitve. Ključno je, da se samodejno izbere način, kateri podatki se pošljejo in kdaj, nato pa skrbno evidentirajte vse, kar je in česa ni.
Različni delovni tokovi v oblaku lahko zahtevajo, da imajo podatki drugačno obliko ali organizacijo kot krajevne aplikacije. Na primer za zakonit potek dela bo morda treba prevesti na tisoče majhnih dokumentov Word ali PDF in jih zapakirati v datoteke ZIP, medijski potek lahko vključuje prekodiranje in pakiranje metapodatkov, postopek bioinformatike pa bo morda zahteval izbiro in uprizoritev terabajtov genomičnih podatkov. Takšno preoblikovanje je lahko zelo ročen in dolgotrajen postopek. Morda bo potrebno veliko eksperimentiranja, veliko začasnega shranjevanja in veliko ravnanja z izjemami. Včasih je skušnjava kakršno koli preoblikovanje prestaviti v oblačno okolje, vendar ne pozabite, da to ne reši težave, temveč le premakne v okolje, kjer ima vsak vir, ki ga uporabljate, ceno.
Del vprašanj o shranjevanju in oblikovanju lahko vključuje odločitve o stiskanju in arhiviranju. Na primer, pred pošiljanjem v oblak je smiselno ZIP-jeti milijone majhnih besedilnih datotek, ne pa tudi peščice večmigabajtnih predstavnostnih datotek. Arhiviranje in stiskanje podatkov olajša prenos in shranjevanje podatkov, vendar upoštevajte čas in prostor za shranjevanje, ki sta potrebna za pakiranje in razpakiranje teh arhivov na obeh koncih.
Ozko grlo za migracijo v oblak št. 3: Preverjanje informacij
Preverjanje integritete je najpomembnejši korak in tudi najlažji, da se zmotite. Pogosto se domneva, da bo pri prenosu podatkov prišlo do korupcije, ne glede na to, ali gre za fizični medij ali prenos omrežja, in jo je mogoče ujeti z izvajanjem kontrolnih vsot pred in po. Kontrolne vsote so bistveni del postopka, vendar gre dejansko za pripravo in uvoz podatkov, kjer boste najverjetneje utrpeli izgubo ali korupcijo.
Ko podatki spreminjajo formate in aplikacije, se lahko smisel in funkcionalnost izgubi, tudi če so bajti enaki. Zaradi preproste nezdružljivosti med različicami programske opreme lahko petabajti "pravilnih" podatkov postanejo neuporabni. Priprava prilagodljivega postopka za preverjanje pravilnosti in uporabnosti vaših podatkov je lahko zastrašujoča naloga. V najslabšem primeru se lahko spremeni v delovno intenziven in nenatančen ročni postopek, "zdi se mi v redu." Toda tudi to je boljše kot nobeno preverjanje veljavnosti. Najpomembneje je zagotoviti, da boste lahko prepoznali težave pred razgradnjo starejših sistemov!
Ozko grlo za migracijo v oblak # 4: Prerazporeditev prenosov
Ko dvignete en sam sistem v oblak, je razmeroma enostavno samo kopirati pripravljene podatke na fizični medij ali jih potisniti po internetu. Toda ta postopek je lahko težko razširiti, zlasti za fizične medije. Kar se zdi, da je v dokaznem konceptu "preprosto", lahko preide v "nočno moro", ko pridejo v poštev številni in različni sistemi.
Na vsako napravo mora biti priključena medijska naprava, na primer snežna kepa AWS. To lahko pomeni fizično sprehajanje naprave po enem ali več podatkovnih centrih, žongliranje s priključki, posodabljanje gonilnikov in namestitev programske opreme. Povezava prek lokalnega omrežja prihrani fizično gibanje, vendar je nastavitev programske opreme še vedno zahtevna in hitrost kopiranja lahko pade precej pod tisto, kar bi lahko dosegli z neposrednim prenosom na internet. Prenos podatkov neposredno iz vsake naprave prek interneta prihrani veliko korakov, še posebej, če so podatki pripravljeni v oblaku.
Če priprava podatkov vključuje kopiranje, izvoz, preoblikovanje ali arhiviranje, lahko lokalno shranjevanje postane ozko grlo. Morda bo treba vzpostaviti namensko shrambo za uprizoritev pripravljenih podatkov. To ima prednost, da mnogim sistemom omogoča vzporedno pripravo in zmanjšuje kontaktne točke za prenosne medije in programsko opremo za prenos podatkov na samo en sistem.
Ozko grlo za migracijo v oblak št. 5: Prenos podatkov
Pri primerjavi omrežnega prenosa s pošiljanjem medijev se enostavno osredotočimo le na čas dostave. Na primer, kurir za naslednji dan lahko pošlje napravo AWS Snowball z 80 terabajti, s čimer doseže navidezno hitrost prenosa podatkov več kot osem gigabitov na sekundo. Toda to prezre čas, ki je potreben za pridobitev naprave, njeno konfiguracijo in nalaganje, pripravo na vrnitev in dovolitev prodajalcu oblaka, da kopira podatke na zaledni strani. Naše stranke, ki to redno počnejo, poročajo, da so pogosti štiritedenski obrati (od naročanja naprav do podatkov, ki so na voljo v oblaku). To dejansko hitrost prenosa podatkov pošilja naprave na samo 300 megabitov na sekundo, še manj, če naprava ni popolnoma napolnjena.
Hitrosti omrežnega prenosa so prav tako odvisne od številnih dejavnikov, predvsem lokalnih vzhodnih povezav. Podatkov ne morete poslati hitreje od fizične bitne hitrosti, vendar lahko natančna priprava podatkov zmanjša količino podatkov, ki jih morate poslati. Starejši protokoli, vključno s tistimi, ki jih ponudniki oblakov privzeto uporabljajo za shranjevanje predmetov, imajo težave s hitrostjo in zanesljivostjo na medmrežnih internetnih poteh, kar lahko oteži doseganje te bitne hitrosti. Lahko bi napisal veliko člankov o izzivih, ki so tu povezani, toda tega vam ni treba rešiti sami. Data Expedition je eno redkih podjetij, ki se specializira za zagotavljanje, da je pot v celoti izkoriščena ne glede na to, kako daleč so vaši podatki od cilja v oblaku. Na primer, ena gigabitna internetna povezava s pospeševalno programsko opremo, kot je CloudDat, prinese 900 megabitov na sekundo, kar je trikrat več kot neto prepustnost snežne kepe AWS.
Največja razlika med fizično pošiljanjem in prenosom omrežja je prav tako ena najpogosteje prezrtih med dokazovanjem koncepta. Pri fizični pošiljki mora prvi bajt, ki ga naložite v napravo, počakati, da se naloži zadnji bajt, preden ga lahko pošljete. To pomeni, da če bodo nalaganje naprave trajale tedne, bodo nekateri vaši podatki tedensko zastareli do prihoda v oblak. Tudi ko nabori podatkov dosežejo raven petabajtov, kjer je fizična pošiljka morda hitrejša od vseh, lahko možnost ohranjanja trenutnih podatkov med postopkom selitve še vedno daje prednost omrežnemu prenosu ključnih sredstev. Natančno načrtovanje med fazo filtriranja in določanja prednostnih nalog pri pripravi podatkov je bistvenega pomena in lahko omogoči hibridni pristop.
Prenos podatkov v ponudnika oblaka morda še ni konec koraka prenosa podatkov. Če ga je treba kopirati v več regij ali ponudnikov, natančno načrtujte, kako bo do njega prišel. Nalaganje prek interneta je brezplačno, medtem ko AWS na primer zaračuna do dva centa na gigabajt za medregionalni prenos podatkov in devet centov na gigabajt za prenos do drugih prodajalcev v oblaku. Obe metodi se bosta soočili z omejitvami pasovne širine, ki bi jim lahko koristilo pospeševanje prometa, kot je CloudDat.
Ozko grlo za migracijo v oblak št. 6: Spreminjanje obsega v oblaku
Ko podatki prispejo na cilj v oblaku, je postopek selitve končan šele na pol. Kontrolne vsote so na prvem mestu: poskrbite, da se prispeli bajti ujemajo s poslanimi. To je lahko bolj zapleteno, kot se morda zavedate. Shramba datotek uporablja plasti predpomnilnikov, ki lahko skrijejo poškodbe podatkov, ki so bili pravkar naloženi. Takšna korupcija je redka, vendar dokler je ne odstranite vse predpomnilnikov in znova preberite datoteke, ne morete biti prepričani o nobeni kontrolni vsoti. Ponovni zagon primerka ali demontaža pomnilnika opravi znosno delo pri čiščenju predpomnilnikov.
Preverjanje kontrolnih vsot za shranjevanje objektov zahteva, da se vsak predmet prebere v primerek za izračun. V nasprotju s splošnim prepričanjem so predmeti "E-oznake" ne uporabne kot kontrolne vsote. Predmete, naložene zlasti z večdelnimi tehnikami, je mogoče potrditi le tako, da jih preberemo nazaj.
