6 skrivenih uskih grla u migraciji podataka u oblaku

Seth Noble je osnivač i predsjednik Data Expeditiona.

Premještanje terabajta ili čak petabajta podataka u oblak zastrašujući je zadatak. Ali važno je gledati dalje od broja bajtova. Vjerojatno znate da će se vaše aplikacije ponašati drugačije kada im se pristupi u oblaku, da će strukture troškova biti drugačije (nadamo se i bolje) i da će trebati vremena za premještanje svih tih podataka.

Budući da se moja tvrtka Data Expedition bavi prijenosom podataka visokih performansi, kupci nam se obraćaju kada očekuju da brzina mreže predstavlja problem. No, u procesu pomaganja tvrtkama da prevladaju taj problem, vidjeli smo i mnoge druge čimbenike koji prijete izbacivanjem migracija iz oblaka ako ih se previdi.

Prikupljanje, organiziranje, formatiranje i provjera valjanosti podataka mogu predstavljati mnogo veće izazove od premještanja. Evo nekoliko uobičajenih čimbenika koje treba uzeti u obzir u fazama planiranja migracije u oblak, tako da kasnije možete izbjeći dugotrajne i skupe probleme.

Usko grlo migracije u oblak br. 1: Pohrana podataka

Najčešća pogreška koju vidimo u migracijama iz oblaka je guranje podataka u pohranu u oblaku bez razmatranja kako će se ti podaci koristiti. Tipičan misaoni postupak je: "Želim svoje dokumente i baze podataka staviti u oblak, a pohrana predmeta je jeftina, pa ću tamo staviti svoje dokumente i baze podataka." Ali datoteke, predmeti i baze podataka ponašaju se vrlo različito. Stavljanje vaših bajtova u pogrešno može oštetiti vaše planove u oblaku.

Datoteke su organizirane hijerarhijom staza, stablom direktorija. Svakoj se datoteci može brzo pristupiti, s minimalnom latencijom (vrijeme do prvog bajta) i velikom brzinom (bitovi u sekundi nakon što podaci počnu teći). Pojedinačne datoteke mogu se lako premjestiti, preimenovati i promijeniti na razinu bajta. Možete imati mnogo malih datoteka, mali broj velikih datoteka ili bilo koju kombinaciju veličina i vrsta podataka. Tradicionalne aplikacije mogu pristupiti datotekama u oblaku baš kao i u prostorijama, bez posebne svijesti o oblaku.

Sve ove prednosti čine pohranu temeljenu na datotekama najskupljom opcijom, ali pohranjivanje datoteka u oblaku ima još nekoliko nedostataka. Da bi se postigle visoke performanse, većini datotečnih sustava temeljenih na oblaku (poput Amazona EBS) istovremeno može pristupiti samo jedan virtualni stroj zasnovan na oblaku, što znači da se sve aplikacije kojima su potrebni ti podaci moraju izvoditi na jednom VM u oblaku. Da bi se posluživalo više VM-ova (poput Azure datoteka), potrebno je spremište spremati NAS protokolom (mrežnom pohranom) poput SMB-a, što može ozbiljno ograničiti performanse. Datotečni sustavi su brzi, fleksibilni i kompatibilni s naslijeđima, ali su skupi, korisni samo za programe koji se izvode u oblaku i ne prilagođavaju se dobro.

Objekti nisu datoteke. Sjetite se toga, jer je to lako zaboraviti. Predmeti žive u ravnom prostoru imena, poput jednog divovskog direktorija. Latencija je velika, ponekad stotine ili tisuće milisekundi, a protok je nizak, često dosežući oko 150 megabita u sekundi, osim ako se ne koriste pametni trikovi. Mnogo se o pristupu objektima svodi na pametne trikove poput prijenosa s više dijelova, pristupa rasponu bajtova i optimizacije imena ključa. Objekte mogu čitati mnoge aplikacije ugrađene u oblak i na webu odjednom, kako iz oblaka tako i izvan njega, ali tradicionalne aplikacije zahtijevaju zaobilaženje zaoštravanja performansi. Većina sučelja za pristup pohrani objekata čine objekte sličnima datotekama: imena ključeva filtriraju se prefiksom da bi izgledala poput mapa, prilagođeni metapodaci pridaju se objektima koji se pojavljuju poput metapodataka datoteke,i neki sustavi poput objekata predmemorije FUSE na sustavu datoteka VM koji omogućuju pristup tradicionalnim aplikacijama. Ali takvi zaobilazni postupci su lomljivi i neuspješni. Pohrana u oblaku je jeftina, skalabilna i izvorna za oblak, ali je i spora i teško joj je pristupiti.

Baze podataka imaju vlastitu složenu strukturu, a pristupaju im jezici upita poput SQL-a. Tradicionalne baze podataka mogu biti podržane pohranom datoteka, ali one zahtijevaju aktivni postupak baze podataka za posluživanje upita. To se može podići u oblak kopiranjem datoteka i aplikacija baze podataka na VM ili migriranjem podataka u uslugu baze podataka hostiranu u oblaku. No kopiranje datoteke baze podataka u objektnu pohranu korisno je samo kao izvanmrežna sigurnosna kopija. Baze podataka se dobro skaliraju kao dio usluge hostirane u oblaku, ali presudno je osigurati da su aplikacije i procesi koji ovise o bazi podataka u potpunosti kompatibilni i urođeni u oblaku. Pohrana baza podataka je visoko specijalizirana i specifična za primjenu.

Balansiranje prividne uštede troškova pohrane predmeta prema funkcionalnosti datoteka i baza podataka zahtijeva pažljivo razmatranje točno koje je funkcije potrebno. Na primjer, ako želite pohraniti i distribuirati tisuće malih datoteka, arhivirajte ih u ZIP datoteku i pohranite ih kao jedan objekt, umjesto da svaku pojedinu datoteku pokušate pohraniti kao zaseban objekt. Neispravan odabir pohrane može dovesti do složenih ovisnosti koje je kasnije teško i skupo promijeniti.

Usko grlo migracije iz oblaka br. 2: Priprema podataka

Premještanje podataka u oblak nije tako jednostavno kao kopiranje bajtova u naznačeni tip pohrane. Potrebno je obaviti mnogo priprema prije nego što se bilo što kopira, a to vrijeme zahtijeva pažljivo planiranje proračuna. Projekti s konceptom često ignoriraju ovaj korak, što kasnije može dovesti do skupih prekoračenja.

Filtriranje nepotrebnih podataka može uštedjeti puno vremena i troškova skladištenja. Na primjer, skup podataka može sadržavati sigurnosne kopije, starije verzije ili ogrebotine datoteke koje ne trebaju biti dio tijeka rada u oblaku. Možda je najvažniji dio filtriranja određivanje prioriteta koje podatke treba prvo premjestiti. Podaci koji se aktivno koriste neće tolerirati nesinkronizaciju tjednima, mjesecima ili godinama potrebnim za dovršetak cijelog postupka migracije. Ključno je ovdje doći do automatiziranog načina odabira podataka koji će se poslati i kada, a zatim pažljivo evidentirati sve što jest, a što nije učinjeno.

Različiti tijekovi rada u oblaku mogu zahtijevati da podaci budu u drugačijem formatu ili organizaciji od lokalnih aplikacija. Na primjer, pravni tijek rada može zahtijevati prijevod na tisuće malih Word ili PDF dokumenata i pakiranje u ZIP datoteke, tijek medija može uključivati ​​prekodiranje i pakiranje metapodataka, a tijek bioinformatike može zahtijevati odabir i postavljanje terabajta genomskih podataka. Takvo preoblikovanje može biti intenzivan ručni i dugotrajan postupak. To može zahtijevati puno eksperimentiranja, puno privremenog skladištenja i puno postupanja s iznimkama. Ponekad je primamljivo odgoditi svako formatiranje u oblak, ali imajte na umu da to ne rješava problem, već ga prebacuje u okruženje u kojem svaki resurs koji koristite ima cijenu.

Dio pitanja o pohrani i formatiranju može uključivati ​​odluke o sažimanju i arhiviranju. Primjerice, logično je ZIP-om poslati milijune malih tekstualnih datoteka prije slanja u oblak, ali ne i pregršt multimedijskih datoteka s više gigabajta. Arhiviranje i komprimiranje podataka olakšava prijenos i pohranu podataka, ali uzmite u obzir vrijeme i prostor za pohranu potrebni za pakiranje i raspakiranje tih arhiva na oba kraja.

Usko grlo migracije u oblak br. 3: Provjera valjanosti podataka

Provjera integriteta najvažniji je korak, a ujedno je i najlakše pogriješiti. Često se pretpostavlja da će se korupcija dogoditi tijekom prijenosa podataka, bilo da se radi o fizičkom mediju ili mrežnom prijenosu, a može se uhvatiti obavljanjem kontrolnih suma prije i poslije. Kontrolne su sume vitalni dio procesa, ali zapravo je to priprema i uvoz podataka tamo gdje ćete najvjerojatnije pretrpjeti gubitak ili korupciju.

Kada podaci mijenjaju formate i aplikacije, značenje i funkcionalnost mogu se izgubiti čak i kada su bajtovi isti. Jednostavna nekompatibilnost između verzija softvera može učiniti petabajte "ispravnih" podataka beskorisnim. Izrada skalabilnog postupka kako biste provjerili jesu li vaši podaci ispravni i korisni može biti zastrašujući zadatak. U najgorem slučaju, može se pretvoriti u radno intenzivan i neprecizan ručni postupak "čini mi se u redu". Ali čak je i to bolje od nikakve provjere valjanosti. Najvažnije je osigurati da ćete moći prepoznati probleme prije nego što naslijeđeni sustavi budu ukinuti!

Usko grlo migracije u oblak # 4: Premještanje marširanja

Kada podižete jedan sustav u oblak, relativno je jednostavno kopirati pripremljene podatke na fizički medij ili ih proslijediti preko Interneta. Ali ovaj postupak može biti teško prilagoditi, posebno za fizičke medije. Ono što se čini "jednostavnim" u dokaznom konceptu može preletjeti u "noćnu moru" kada u igru ​​uđu mnogi i različiti sustavi.

Na svaki uređaj mora biti spojen medijski uređaj, poput AWS Snowball-a. To bi moglo značiti fizičko hodanje uređajem oko jednog ili više podatkovnih centara, žongliranje konektorima, ažuriranje upravljačkih programa i instaliranje softvera. Povezivanje preko lokalne mreže štedi fizičko kretanje, ali postavljanje softvera i dalje može biti izazovno, a brzina kopiranja može pasti znatno ispod onoga što bi se moglo postići izravnim prijenosom na Internet. Prijenos podataka izravno sa svakog računala putem Interneta sprema mnoge korake, pogotovo ako su podaci spremni za oblak.

Ako priprema podataka uključuje kopiranje, izvoz, preoblikovanje ili arhiviranje, lokalna pohrana može postati usko grlo. Možda će biti potrebno postaviti namjensko spremište za pripremu pripremljenih podataka. To ima tu prednost što omogućava da mnogi sustavi paralelno izvode pripremu i smanjuje kontaktne točke za isporučive medije i softver za prijenos podataka na samo jedan sustav.

Usko grlo migracije u oblak br. 5: Prijenos podataka

Kada se uspoređuje mrežni prijenos s isporukom medija, lako se usredotočiti samo na vrijeme otpreme. Na primjer, kurir sljedećeg dana može poslati AWS Snowball uređaj od 80 terabajta, postižući prividnu brzinu prijenosa podataka veću od osam gigabita u sekundi. No, to zanemaruje vrijeme potrebno za nabavu uređaja, konfiguriranje i učitavanje, pripremu za povratak i omogućavanje dobavljaču oblaka da kopira podatke na pozadini. Kupci koji to redovito rade izvještavaju da su uobičajena vremena obrade od četiri tjedna (od naručivanja uređaja do podataka dostupnih u oblaku). To smanjuje stvarnu brzinu prijenosa podataka isporuke uređaja na samo 300 megabita u sekundi, mnogo manje ako uređaj nije u potpunosti napunjen.

Brzine mrežnog prijenosa također ovise o brojnim čimbenicima, a ponajprije je to lokalna uplink. Ne možete slati podatke brže od fizičke brzine prijenosa, premda pažljiva priprema podataka može smanjiti količinu podataka koju trebate poslati. Naslijeđeni protokoli, uključujući one koje dobavljači oblaka prema zadanim postavkama koriste za pohranu objekata, imaju poteškoće s brzinom i pouzdanošću na velikim internetskim stazama, što može otežati postizanje te brzine prijenosa. Mogao bih napisati mnogo članaka o izazovima ovdje, ali ovaj ne morate riješiti sami. Data Expedition jedna je od rijetkih tvrtki koje su se specijalizirale za osiguravanje da se put u potpunosti iskoristi bez obzira na to koliko su vaši podaci udaljeni od odredišta u oblaku. Na primjer, jedna gigabitna internetska veza sa softverom za ubrzanje poput CloudData daje 900 megabita u sekundi,tri puta veća od neto propusnosti AWS snježne kugle.

Najveća razlika između fizičke pošiljke i mrežnog prijenosa također je jedna od najčešće previđenih tijekom provjere koncepta. Kod fizičke isporuke, prvi bajt koji učitate na uređaj mora pričekati dok se zadnji bajt ne učita prije nego što ga možete otpremiti. To znači da ako su za učitavanje uređaja potrebni tjedni, neki će vaši podaci zastarjeti do trenutka kada stignu u oblak. Čak i kada skupovi podataka dosegnu razinu petabajta gdje fizička poštarina može biti brža od svih, sposobnost održavanja prioritetnih podataka tijekom postupka migracije i dalje može pogodovati mrežnom prijenosu ključnih sredstava. Pažljivo planiranje tijekom faze filtriranja i prioritizacije pripreme podataka je neophodno i može omogućiti hibridni pristup.

Preuzimanje podataka u davatelja usluga u oblaku možda nije kraj koraka prijenosa podataka. Ako ga treba replicirati u više regija ili pružatelja, pažljivo planirajte kako će doći. Prijenos putem Interneta je besplatan, dok AWS, na primjer, naplaćuje do dva centa po gigabajtu za međuregionalni prijenos podataka i devet centi po gigabajtu za prijenos drugim dobavljačima u oblaku. Obje metode suočit će se s ograničenjima širine pojasa koja bi mogla imati koristi od ubrzanja transporta poput CloudDat-a.

Usko grlo migracije u oblak # 6: Razmjera u oblaku

Jednom kada podaci stignu na odredište u oblaku, postupak migracije završen je tek napola. Kontrolne su sume na prvom mjestu: Provjerite poklapaju li se bajtovi s onima koji su poslani. Ovo može biti nezgodnije nego što možda mislite. Pohrana datoteka koristi slojeve predmemorije koji mogu sakriti oštećenje podataka koji su upravo preneseni. Takva je korupcija rijetka, ali dok ne očistite sve predmemorije i ponovno pročitate datoteke, ne možete biti sigurni u postojanje kontrolnih suma. Ponovno pokretanje instance ili demontaža memorije podnošljiv je posao brisanja predmemorija.

Provjera valjanosti kontrolnih suma za pohranu objekata zahtijeva da se svaki objekt pročita u instancu radi izračuna. Suprotno uvriježenom mišljenju, objekt "E-oznake" nisu korisni kao kontrolne sume. Objekti učitani posebno tehnikama s više dijelova mogu se provjeriti samo vraćanjem unatrag.