6 скрити тесни места в миграцията на данни в облак

Сет Нобъл е основател и президент на Data Expedition.

Преместването на терабайта или дори петабайта данни в облака е страховита задача. Но е важно да се гледа извън броя на байтовете. Вероятно знаете, че вашите приложения ще се държат по различен начин при достъп в облака, че структурата на разходите ще бъде различна (надяваме се по-добра) и че ще отнеме време за преместване на всички тези данни.

Тъй като моята компания, Data Expedition, се занимава с високоефективен трансфер на данни, клиентите идват при нас, когато очакват скоростта на мрежата да бъде проблем. Но в процеса на подпомагане на компаниите да преодолеят този проблем, видяхме много други фактори, които заплашват да провалят облачните миграции, ако бъдат оставени без внимание.

Събирането, организирането, форматирането и валидирането на вашите данни може да създаде много по-големи предизвикателства от преместването им. Ето някои често срещани фактори, които трябва да се вземат предвид при етапите на планиране на облачната миграция, за да можете по-късно да избегнете отнемащи време и скъпи проблеми.

Облачно мигриране # 1: Съхранение на данни

Най-често срещаната грешка, която наблюдаваме при миграцията в облака, е изтласкването на данни в облачно хранилище, без да се обмисля как тези данни ще бъдат използвани. Типичният мисловен процес е: „Искам да поставя документите и базите си данни в облака, а съхранението на обекти е евтино, така че ще поставя там документите и файловете си с база данни.“ Но файловете, обектите и базите данни се държат съвсем различно. Поставянето на байтовете ви в грешен може да осакати вашите облачни планове.

Файловете са организирани от йерархия на пътеки, дърво на директории. Всеки файл може да бъде достъпен бързо, с минимална латентност (време до първия байт) и висока скорост (бита в секунда, след като данните започнат да текат). Отделните файлове могат лесно да бъдат премествани, преименувани и променяни до нивото на байта. Можете да имате много малки файлове, малък брой големи файлове или всякаква комбинация от размери и типове данни. Традиционните приложения могат да имат достъп до файлове в облака, точно както биха направили това в помещенията, без специално осведоменост за облака.

Всички тези предимства правят базираното на файлове съхранение най-скъпата опция, но съхраняването на файлове в облака има няколко други недостатъка. За да се постигне висока производителност, повечето базирани на облак файлови системи (като Amazon EBS) могат да бъдат достъпни само от една виртуална машина, базирана на облак, което означава, че всички приложения, които се нуждаят от тези данни, трябва да работят на една виртуална машина в облак. За да се обслужват множество виртуални машини (като Azure Files), се изисква изпращането на хранилището с протокол NAS (свързано с мрежа съхранение) като SMB, което може сериозно да ограничи производителността. Файловите системи са бързи, гъвкави и съвместими с наследство, но са скъпи, полезни само за приложения, работещи в облака, и не се мащабират добре.

Обектите не са файлове. Не забравяйте това, защото е лесно да се забрави. Обектите живеят в плоско пространство от имена, като една гигантска директория. Латентността е висока, понякога стотици или хиляди милисекунди, а пропускателната способност е ниска, често достигайки около 150 мегабита в секунда, освен ако не се използват хитри трикове. Голяма част от достъпа до обекти се свежда до хитри трикове като качване на няколко части, достъп до байтови диапазони и оптимизиране на имена на ключове. Обектите могат да се четат от много облачни и уеб-базирани приложения едновременно, както отвътре, така и извън облака, но традиционните приложения изискват заобикаляне на ефективността. Повечето интерфейси за достъп до съхранение на обекти правят обектите да изглеждат като файлове: имената на ключове се филтрират по префикс, за да изглеждат като папки, персонализирани метаданни се прикачват към обекти, за да се появят като метаданни на файлове,и някои системи като обекти за кеширане FUSE във файлова система на VM, за да позволят достъп от традиционни приложения. Но такива заобикалящи мерки са крехки и сочни резултати. Облачното съхранение е евтино, мащабируемо и облачно, но също така е бавно и трудно достъпно.

Базите данни имат своя собствена сложна структура и до тях се осъществява достъп от езици за заявки като SQL. Традиционните бази данни могат да бъдат подкрепени от съхранение на файлове, но те изискват процес на база данни на живо, за да обслужват заявки. Това може да бъде изведено в облака чрез копиране на файловете на базата данни и приложенията във виртуална машина или чрез мигриране на данните в услуга за бази данни, хоствана в облак. Но копирането на файл от базата данни в обект за съхранение е полезно само като офлайн архивиране. Базите данни се мащабират добре като част от услуга, хоствана в облак, но е от решаващо значение да се гарантира, че приложенията и процесите, които зависят от базата данни, са напълно съвместими и вградени в облака. Съхранението на базата данни е тясно специализирано и специфично за приложението.

Балансирането на очевидните икономии на разходи за съхранение на обекти спрямо функционалността на файловете и базите данни изисква внимателно обмисляне точно каква функционалност се изисква. Например, ако искате да съхранявате и разпространявате много хиляди малки файлове, архивирайте ги в ZIP файл и ги съхранявайте като единичен обект, вместо да се опитвате да съхранявате всеки отделен файл като отделен обект. Неправилният избор за съхранение може да доведе до сложни зависимости, които е трудно и скъпо да се променят по-късно.

Тесно място за миграция в облак # 2: Подготовка на данните

Преместването на данни в облака не е толкова просто, колкото копирането на байтове в определения тип съхранение. Преди да се копира нещо, трябва да се извърши много подготовка и това време изисква внимателно бюджетиране. Проектите с доказателство за концепция често пренебрегват тази стъпка, което може да доведе до скъпо надхвърляне по-късно.

Филтрирането на ненужни данни може да спести много време и разходи за съхранение. Например набор от данни може да съдържа резервни копия, по-ранни версии или драскотини, които не е необходимо да бъдат част от работния процес в облака. Може би най-важната част от филтрирането е даване на приоритет кои данни трябва да бъдат преместени първо. Данните, които се използват активно, няма да понасят несинхронизиране от седмиците, месеците или годините, необходими за завършване на целия процес на миграция. Ключът тук е да измислите автоматизирано средство за избор кои данни да бъдат изпратени и кога, след което да поддържате внимателни записи на всичко, което е и не е направено.

Различните работни потоци в облака може да изискват данните да бъдат в различен формат или организация, отколкото локалните приложения. Например, легален работен поток може да изисква превод на хиляди малки Word или PDF документи и опаковането им в ZIP файлове, медийният работен поток може да включва прекодиране и пакетиране на метаданни, а биоинформатичният работен поток може да изисква избор и поставяне на терабайта геномни данни. Такова преформатиране може да бъде изключително ръчен и отнемащ време процес. Може да се наложи много експерименти, много временно съхранение и много обработка на изключения. Понякога е изкушаващо да отложите всяко преформатиране в облачната среда, но не забравяйте, че това не решава проблема, а просто го премества в среда, където всеки ресурс, който използвате, има цена.

Част от въпросите за съхранението и форматирането могат да включват решения за компресиране и архивиране. Например има смисъл да архивирате милиони малки текстови файлове, преди да ги изпратите в облака, но не и шепа мултигигабайтни медийни файлове. Архивирането и компресирането на данни улеснява прехвърлянето и съхраняването на данните, но вземете предвид времето и пространството за съхранение, които са необходими за опаковане и разопаковане на тези архиви в двата края.

Облачно мигриране # 3: Проверка на информацията

Проверката на почтеността е най-важната стъпка, а също и най-лесната грешка. Често се приема, че по време на транспортирането на данни ще възникне корупция, независимо дали това е чрез физически носител или мрежов трансфер, и може да бъде уловено чрез извършване на контролни суми преди и след това. Контролните суми са жизненоважна част от процеса, но всъщност това е подготовката и импортирането на данните, където е най-вероятно да претърпите загуба или корупция.

Когато данните променят формати и приложения, смисълът и функционалността могат да бъдат загубени, дори когато байтовете са еднакви. Една проста несъвместимост между версиите на софтуера може да направи петабайтите „правилни“ данни безполезни. Измислянето на мащабируем процес, за да проверите дали данните ви са едновременно правилни и използваеми, може да бъде обезсърчаваща задача. В най-лошия случай може да се превърне в трудоемък и неточен ръчен процес на „изглежда ми добре“. Но дори това е по-добре от липсата на никакво валидиране. Най-важното е да сте сигурни, че ще можете да разпознавате проблеми, преди старите системи да бъдат изведени от експлоатация!

Тесно място за миграция в облак # 4: Маршрутизиране на трансфера

Когато повдигате една система в облака, е сравнително лесно просто да копирате подготвените данни на физически носител или да ги изпратите в Интернет. Но този процес може да бъде труден за мащабиране, особено за физически носители. Това, което изглежда „просто“ в доказателствената концепция, може да доведе до „кошмар“, когато влязат в действие много и различни системи.

Мултимедийно устройство, като AWS Snowball, трябва да бъде свързано към всяка машина. Това може да означава физическо обхождане на устройството около един или повече центрове за данни, жонглиране с конектори, актуализиране на драйвери и инсталиране на софтуер. Свързването през локалната мрежа спестява физическото движение, но настройката на софтуера все още може да бъде предизвикателна и скоростта на копиране може да падне доста под това, което би могло да се постигне с директно качване в Интернет. Прехвърлянето на данните директно от всяка машина през Интернет спестява много стъпки, особено ако данните са готови за облак.

Ако подготовката на данни включва копиране, експортиране, преформатиране или архивиране, локалното съхранение може да се превърне в пречка. Може да е необходимо да се създаде специално хранилище, за да се подготвят подготвените данни. Това има предимството, че позволява на много системи да извършват паралелно подготовка и намалява точките за контакт за транспортируеми носители и софтуер за трансфер на данни само до една система.

Облачно мигриране # 5: Прехвърляне на данни

Когато сравняваме мрежовия трансфер с доставката на медия, лесно е да се съсредоточим само върху времето за доставка. Например, устройство от 80 терабайта AWS Snowball може да бъде изпратено от куриер на следващия ден, като се постигне очевидна скорост на данни от повече от осем гигабита в секунда. Но това пренебрегва времето, необходимо за придобиване на устройството, конфигуриране и зареждане, подготовка за връщане и позволяване на доставчика на облак да копира данните на задния край. Клиентите ни, които правят това редовно, съобщават, че често срещаните периоди на изпълнение от четири седмици (от поръчки на устройства до данни, налични в облака) са често срещани. Това намалява реалната скорост на трансфер на данни при доставката на устройството до само 300 мегабита в секунда, много по-малко, ако устройството не е напълно запълнено.

Скоростите на мрежов трансфер също зависят от редица фактори, като преди всичко това е локалната връзка нагоре. Не можете да изпращате данни по-бързо от физическата скорост на предаване, въпреки че внимателната подготовка на данни може да намали количеството данни, които трябва да изпратите. Наследствените протоколи, включително тези, които доставчиците на облак използват по подразбиране за съхранение на обекти, имат затруднения със скоростта и надеждността по интернет пътища на дълги разстояния, което може да затрудни постигането на тази скорост на предаване. Бих могъл да напиша много статии за предизвикателствата, свързани тук, но това е, което не е нужно да решавате сами. Data Expedition е една от малкото компании, които се специализират в осигуряването на пълното използване на пътя, независимо колко далеч са данните ви от дестинацията им в облака. Например, една гигабитова интернет връзка със софтуер за ускорение като CloudDat дава 900 мегабита в секунда,три пъти по-голяма от нетната производителност на AWS Snowball.

Най-голямата разлика между физическата пратка и мрежовия трансфер също е една от най-често пренебрегваните по време на проверка на концепцията. При физическа пратка първият байт, който зареждате в устройството, трябва да изчака, докато последният байт бъде зареден, преди да можете да изпратите. Това означава, че ако отнема седмици, за да заредите устройството, тогава някои от вашите данни ще бъдат неактуални до момента, в който пристигнат в облака. Дори когато наборите от данни достигнат петабайтовите нива, при които физическата пратка може да бъде по-бърза от всички, възможността за поддържане на актуални данни по време на процеса на мигриране може да благоприятства мрежовия трансфер за ключови активи. Внимателното планиране по време на фазата на филтриране и приоритизиране на подготовката на данните е от съществено значение и може да позволи хибриден подход.

Получаването на данните в облачен доставчик може да не е краят на стъпката за прехвърляне на данни. Ако трябва да бъде репликиран в множество региони или доставчици, планирайте внимателно как ще стигне до там. Качването през интернет е безплатно, докато AWS например таксува до два цента на гигабайт за междурегионален трансфер на данни и девет цента на гигабайт за прехвърляне към други доставчици в облака. И двата метода ще се сблъскат с ограничения на честотната лента, които биха могли да се възползват от транспортното ускорение като CloudDat.

Тесно място за миграция в облак # 6: Мащабиране в облака

След като данните пристигнат до местоназначението си в облака, процесът на мигриране е само наполовина завършен. Контролните суми са на първо място: Уверете се, че пристигналите байтове съответстват на изпратените. Това може да е по-сложно, отколкото може би си представяте. Съхранението на файлове използва слоеве кеш, които могат да скрият повреда на току-що качените данни. Подобна корупция е рядка, но докато не изчистите всички кешове и не прочетете отново файловете, не можете да сте сигурни в контролни суми. Рестартирането на екземпляра или демонтирането на хранилището върши сносна работа за изчистване на кешовете.

Проверката на контролните суми за съхранение на обекти изисква всеки обект да бъде прочетен в екземпляр за изчисление. Противно на общоприетото схващане, обектните „E-тагове“ не са полезни като контролни суми. Обектите, качени с помощта на техники от няколко части, могат да бъдат валидирани само като ги прочетете обратно.