Setas Noblas yra „Data Expedition“ įkūrėjas ir prezidentas.
Terabaitų ar net petabaitų duomenų perkėlimas į debesį yra nelengva užduotis. Tačiau svarbu žiūrėti ne tik į baitų skaičių. Jūs tikriausiai žinote, kad jūsų programos elgsis kitaip, kai bus pasiekiamos debesyje, kad sąnaudų struktūra bus kitokia (tikiuosi, geresnė) ir kad užtruks laiko perkeliant visus tuos duomenis.
Kadangi mano įmonė „Data Expedition“ užsiima didelio našumo duomenų perdavimu, klientai ateina pas mus, kai tikisi, kad tinklo greitis bus problema. Tačiau padėdami įmonėms įveikti šią problemą, mes matėme daug kitų veiksnių, kurie grasina nuvilti debesų migracijas, jei jų nepaisoma.
Duomenų rinkimas, tvarkymas, formatavimas ir patvirtinimas gali sukelti daug didesnių iššūkių nei jų perkėlimas. Čia yra keletas bendrų veiksnių, į kuriuos reikia atsižvelgti planuojant debesų perkėlimą, kad vėliau galėtumėte išvengti daug laiko reikalaujančių ir brangių problemų.
Debesų perkėlimo kliūtis Nr. 1: duomenų saugojimas
Dažniausia klaida, kurią matome debesų perkėlimuose, yra duomenų perkėlimas į debesies saugyklą, nesvarstant, kaip tie duomenys bus naudojami. Tipiškas minties procesas yra toks: „Aš noriu įdėti savo dokumentus ir duomenų bazes į debesį, o objektų saugojimas yra pigus, todėl aš ten įdėsiu savo dokumentų ir duomenų bazių failus“. Tačiau failai, objektai ir duomenų bazės elgiasi labai skirtingai. Įdėję baitus į neteisingą, galite suluošinti debesų planus.
Failai yra sutvarkyti pagal kelių hierarchiją, katalogų medį. Kiekvieną failą galima greitai pasiekti, naudojant minimalų delsą (laikas iki pirmo baito) ir didelę spartą (bitai per sekundę, kai duomenys pradeda tekėti). Atskiri failai gali būti lengvai perkelti, pervardyti ir pakeisti iki baitų lygio. Galite turėti daug mažų failų, nedidelį didelių failų skaičių arba bet kokį dydžių ir duomenų tipų derinį. Tradicinės programos gali pasiekti debesyje esančius failus kaip ir patalpose, be jokio ypatingo debesų supratimo.
Dėl visų šių pranašumų failų saugojimas yra brangiausias pasirinkimas, tačiau failų saugojimas debesyje turi dar keletą trūkumų. Norint pasiekti aukštą našumą, prie daugumos debesų failų sistemų (pvz., „Amazon EBS“) vienu metu galima pasiekti tik vieną debesies pagrindu veikiančią virtualią mašiną, o tai reiškia, kad visos programos, kurioms reikalingi šie duomenys, turi veikti viename debesies VM. Norint aptarnauti kelis VM (pvz., „Azure Files“), reikia nukreipti saugyklą naudojant NAS (prie tinklo prijungtos saugyklos) protokolą, pvz., SMB, o tai gali labai apriboti našumą. Failų sistemos yra greitos, lanksčios ir suderinamos su paveldu, tačiau jos yra brangios, naudingos tik debesyje veikiančioms programoms ir nėra masto.
Objektai nėra failai. Prisiminkite tai, nes ją lengva pamiršti. Objektai gyvena plokščioje vardų srityje, kaip vienas milžiniškas katalogas. Vėlavimas yra didelis, kartais šimtai ar tūkstančiai milisekundžių, o pralaidumas yra mažas, dažnai viršijantis apie 150 megabitų per sekundę, nebent naudojami gudrūs triukai. Daug apie prieigą prie objektų lemia sumanūs triukai, pvz., Kelių dalių įkėlimas, prieiga prie baitų diapazono ir raktų pavadinimų optimizavimas. Objektus vienu metu gali perskaityti daugybė debesyje esančių ir žiniatinklio programų tiek iš debesies, tiek iš išorės, tačiau tradicinėms programoms reikia sugadinti našumą. Dauguma sąsajų, leidžiančių pasiekti objektų saugyklą, daro objektus panašius į failus: raktų pavadinimai filtruojami pagal priešdėlį, kad jie atrodytų kaip aplankai, prie objektų pridedami pasirinktiniai metaduomenys, kad jie būtų rodomi kaip failų metaduomenys, o kai kurios sistemos, pvz., „FUSE“ talpyklos objektai VM failų sistemoje, kad būtų galima pasiekti pagal tradicines programas. Tačiau tokie būdai yra trapūs ir efektyvūs. Debesies saugykla yra pigi, keičiamo dydžio ir debesyje naudojama, tačiau ji taip pat lėta ir sunkiai pasiekiama.
Duomenų bazės turi savo sudėtingą struktūrą ir prie jų prisijungia užklausų kalbos, tokios kaip SQL. Tradicinės duomenų bazės gali būti palaikomos failų saugykloje, tačiau joms reikia tiesioginio duomenų bazės proceso, kad būtų galima teikti užklausas. Tai galima pakelti į debesį, nukopijuojant duomenų bazės failus ir programas į VM arba perkeliant duomenis į debesyje priglobtą duomenų bazės paslaugą. Tačiau duomenų bazės failo kopijavimas į objektų saugyklą yra naudingas tik kaip neprisijungus veikianti atsarginė kopija. Duomenų bazės taip pat masto kaip debesies priglobtos paslaugos dalis, tačiau labai svarbu užtikrinti, kad nuo duomenų bazės priklausančios programos ir procesai būtų visiškai suderinami ir pritaikyti debesims. Duomenų bazių saugojimas yra labai specializuotas ir pritaikytas konkrečioms programoms.
Norint subalansuoti akivaizdų objektų saugojimo sąnaudų ir failų bei duomenų bazių funkcionalumą, reikia gerai apsvarstyti, kokio funkcionalumo reikia. Pvz., Jei norite saugoti ir išplatinti daugybę tūkstančių mažų failų, suarchyvuokite juos į ZIP failą ir saugokite juos kaip vieną objektą, užuot bandę saugoti kiekvieną atskirą failą kaip atskirą objektą. Neteisingas pasirinkimas saugykloje gali sukelti sudėtingas priklausomybes, kurias vėliau sunku ir brangu pakeisti.
Debesų perkėlimo kliūtis Nr. 2: duomenų paruošimas
Duomenų perkėlimas į debesį nėra toks paprastas kaip baitų kopijavimas į nurodytą saugyklos tipą. Prieš ką nors nukopijuojant, reikia daug pasiruošti, o tam laikui reikia kruopštaus biudžeto. Koncepcijos įrodymo projektuose dažnai nepaisoma šio žingsnio, o tai vėliau gali sukelti brangų viršijimą.
Filtruojant nereikalingus duomenis galima sutaupyti daug laiko ir saugojimo išlaidų. Pvz., Duomenų rinkinyje gali būti atsarginių kopijų, ankstesnių versijų arba subraižytų failų, kuriems nereikia būti debesies darbo eigos dalimi. Bene svarbiausia filtravimo dalis yra prioritetų nustatymas, kuriuos duomenis reikia perkelti pirmiausia. Aktyviai naudojami duomenys netoleruos, kad per kelias savaites, mėnesius ar metus, per kuriuos bus užbaigtas visas perkėlimo procesas, nebus sinchronizuota. Svarbiausia yra sugalvoti automatizuotą būdą, kaip pasirinkti, kurie duomenys ir kada turi būti siunčiami, tada kruopščiai registruokite viską, kas yra ir nėra daroma.
Skirtingoms debesies darbo eigoms gali reikėti, kad duomenys būtų kitokio formato ar organizacijos nei vietinėse programose. Pvz., Teisinei darbo eigai gali tekti išversti tūkstančius mažų „Word“ ar PDF dokumentų ir supakuoti juos į ZIP failus, medijos darbo eiga gali būti susijusi su perkodavimu ir metaduomenų pakavimu, o bioinformatikos darbo eigoje gali tekti rinkti ir išdėstyti terabaitus genomikos duomenų. Toks formatavimas gali būti labai rankinis ir daug laiko reikalaujantis procesas. Tai gali reikėti daug eksperimentuoti, daug laikino saugojimo ir daug išimčių tvarkymo. Kartais kyla pagunda atidėti bet kokį debesų aplinkos formatavimą, tačiau atminkite, kad tai neišsprendžia problemos, o tiesiog perkelia ją į aplinką, kurioje kiekvienas jūsų naudojamas išteklius turi kainą.
Dalis saugojimo ir formatavimo klausimų gali būti susiję su sprendimais dėl glaudinimo ir archyvavimo. Pvz., Prieš siunčiant juos į debesį yra prasminga susieti milijonus mažų tekstinių failų, bet ne kelias gigabaitų daugialypės terpės failus. Duomenų archyvavimas ir glaudinimas palengvina duomenų perkėlimą ir saugojimą, tačiau atsižvelkite į laiką ir saugojimo vietą, reikalingą šiems archyvams supakuoti ir išpakuoti abiejuose galuose.
Debesų perkėlimo kliūtis Nr. 3: informacijos patvirtinimas
Sąžiningumo tikrinimas yra vienintelis svarbiausias žingsnis, taip pat lengviausia suklysti. Dažnai daroma prielaida, kad korupcija įvyksta perduodant duomenis, nesvarbu, ar tai yra fizinė laikmena, ar tinklo perdavimas, ir gali būti užfiksuotas atliekant kontrolines sumas prieš ir po. Kontrolinės sumos yra gyvybiškai svarbi proceso dalis, tačiau iš tikrųjų tai yra duomenų paruošimas ir importavimas ten, kur greičiausiai patirsite nuostolių ar korupcijos.
Kai duomenys keičia formatus ir programas, reikšmė ir funkcionalumas gali būti prarasti, net kai baitai yra vienodi. Paprastas programinės įrangos versijų nesuderinamumas gali padaryti „teisingų“ duomenų petabaitais nenaudingus. Sukurti mastelio procesą, siekiant patikrinti, ar jūsų duomenys yra teisingi ir tinkami naudoti, gali būti nelengva užduotis. Blogiausiu atveju tai gali pereiti į daug darbo reikalaujantį ir netikslų rankinį procesą „man atrodo gerai“. Bet net ir tai yra geriau nei jokio patvirtinimo. Svarbiausia užtikrinti, kad galėsite atpažinti problemas, kol senosios sistemos nebus eksploatuojamos!
Debesų migracijos kliūtis Nr. 4: perkėlimas
Pakeliant vieną sistemą į debesį, palyginti lengva paruoštus duomenis tiesiog nukopijuoti į fizinę laikmeną arba perkelti į internetą. Tačiau šį procesą gali būti sunku išplėsti, ypač fizinei laikmenai. Tai, kas koncepcijos įrodyme atrodo „paprasta“, gali sukelti „košmarą“, kai pradeda veikti daug ir įvairių sistemų.
Prie kiekvienos mašinos turi būti prijungtas laikmenos įrenginys, pvz., „AWS Snowball“. Tai gali reikšti, kad fiziškai vaikščiotumėte įrenginiu aplink vieną ar daugiau duomenų centrų, žongliruotumėte jungtimis, atnaujintumėte tvarkykles ir įdiegtumėte programinę įrangą. Prisijungus per vietinį tinklą, išsaugomas fizinis judėjimas, tačiau programinės įrangos nustatymas vis tiek gali būti sudėtingas, o kopijavimo greitis gali nukristi iki gerokai mažesnio, nei būtų galima pasiekti tiesiogiai įkėlus internetą. Perkėlus duomenis tiesiai iš kiekvienos mašinos per internetą, sutaupoma daugybė veiksmų, ypač jei duomenys paruošti debesims.
Jei duomenų paruošimas apima kopijavimą, eksportavimą, pertvarkymą ar archyvavimą, vietinė saugykla gali tapti kliūtimi. Paruoštiems duomenims atlikti gali tekti nustatyti specialią saugyklą. Tai turi pranašumą, nes leidžia daugybei sistemų lygiagrečiai atlikti pasirengimą, o perkeliamos laikmenos ir duomenų perdavimo programinės įrangos kontaktinius taškus sumažina tik viena sistema.
Debesų perkėlimo kliūtis Nr. 5: duomenų perdavimas
Lyginant tinklo perdavimą su laikmenų siuntimu, lengva sutelkti dėmesį tik į siuntimo laiką. Pvz., 80 dienų terabaitų „AWS Snowball“ įrenginį gali išsiųsti kitos dienos kurjeris, pasiekdamas matomą duomenų spartą, viršijančią aštuonis gigabitus per sekundę. Tačiau tai nepaiso laiko, kurio reikia įrenginiui įsigyti, sukonfigūruoti ir įkelti, paruošti jį grąžinti ir leisti debesijos tiekėjui nukopijuoti duomenis iš vidinės pusės. Mūsų klientai, kurie tai daro reguliariai, praneša, kad keturių savaičių trukmė (nuo įrenginių užsakymo iki debesyje pasiekiamų duomenų) yra įprasta. Tai sumažina faktinį prietaiso siuntimo duomenų perdavimo greitį iki 300 megabitų per sekundę, daug mažiau, jei įrenginys nėra visiškai užpildytas.
Tinklo perdavimo greitis taip pat priklauso nuo daugelio veiksnių, visų pirma, tai yra vietinis aukštupis. Negalite siųsti duomenų greičiau nei fizinis duomenų perdavimo sparta, tačiau kruopštus duomenų paruošimas gali sumažinti jūsų siunčiamų duomenų kiekį. Seniems protokolams, įskaitant tuos, kuriuos debesų tiekėjai pagal numatytuosius nustatymus naudoja objektų saugojimui, sunku pasiekti greitį ir patikimumą tolimojo interneto keliuose, todėl gali būti sunku pasiekti tą bitų greitį. Galėčiau parašyti daug straipsnių apie čia kylančius iššūkius, tačiau jūs neturite to išspręsti patys. „Data Expedition“ yra viena iš nedaugelio kompanijų, kurios specializuojasi užtikrindamos, kad kelias būtų visiškai išnaudotas, neatsižvelgiant į tai, kiek jūsų duomenys yra nutolę nuo debesies paskirties. Pavyzdžiui, vienas gigabito interneto ryšys su greitinimo programine įranga, pvz., „CloudDat“, duoda 900 megabitų per sekundę, tris kartus didesnį nei „AWS Snowball“ grynąjį pralaidumą.
Didžiausias skirtumas tarp fizinio siuntimo ir tinklo perdavimo taip pat yra vienas iš dažniausiai pamirštamų per koncepcijos įrodymą. Fiziškai siunčiant, pirmasis baitas, kurį įkeliate į įrenginį, turi palaukti, kol bus įkeltas paskutinis baitas, kad galėtumėte išsiųsti. Tai reiškia, kad jei įrenginio įkėlimas užtruks kelias savaites, tada kai kurie jūsų duomenys savaites bus pasenę, kol jie pasieks debesį. Net kai duomenų rinkiniai pasiekia petabaitų lygį, kur fizinis pristatymas gali būti greitesnis už visus, galimybė išlaikyti prioritetinius duomenis perėjimo metu vis tiek gali būti naudinga perduodant pagrindinius išteklius tinklui. Duomenų paruošimo filtravimo ir prioritetų nustatymo etape būtina kruopščiai planuoti ir tai gali leisti taikyti mišrų metodą.
Duomenų perdavimas į debesijos paslaugų teikėją gali būti ne duomenų perdavimo veiksmo pabaiga. Jei jį reikia pakartoti keliems regionams ar paslaugų teikėjams, atidžiai planuokite, kaip jis ten pateks. Įkėlimas internetu yra nemokamas, o, pavyzdžiui, AWS už tarpregioninį duomenų perdavimą ima iki dviejų centų už gigabaitą, o už perkėlimą į kitus debesijos tiekėjus - devynis centus už gigabaitą. Abu metodai susidurs su pralaidumo apribojimais, kuriems galėtų būti naudingas transporto pagreitis, pvz., „CloudDat“.
Debesų migracijos kliūtis # 6: Debesų mastelis
Duomenims pasiekus tikslą debesyje, perkėlimo procesas dar tik baigtas. Pirmiausia yra kontrolinės sumos: įsitikinkite, kad atėję baitai sutampa su išsiųstaisiais. Tai gali būti sudėtingiau, nei jūs suprantate. Failų saugykloje naudojami talpyklos sluoksniai, kurie gali paslėpti ką tik įkeltų duomenų sugadinimą. Tokia korupcija yra reta, bet kol nepašalinsite visi iš talpyklų ir iš naujo perskaitykite failus, negalite būti tikri, ar nėra kontrolinių sumų. Perkraunant egzempliorių arba atjungiant saugyklą, toleruotinas darbas išvalant talpyklas.
Patvirtinant objektų saugyklos kontrolines sumas, kiekvienas objektas turi būti perskaitytas į egzempliorių, kad būtų galima apskaičiuoti. Priešingai nei įprasta manyti, objektų „el. Žymos“ yra ne naudinga kaip kontrolinės sumos. Objektus, įkeltus naudojant daugelio dalių techniką, galima patvirtinti tik juos perskaičius.
