Seth Noble je zakladatel a prezident Data Expedition.
Přesunutí terabajtů nebo dokonce petabajtů dat do cloudu je skličující úkol. Je ale důležité dívat se nad rámec počtu bajtů. Pravděpodobně víte, že vaše aplikace se budou chovat odlišně, když k nim budete mít přístup v cloudu, že nákladové struktury budou jiné (doufejme lepší) a že přesun všech těchto dat bude nějakou dobu trvat.
Protože moje společnost, Data Expedition, podniká v oblasti vysoce výkonného přenosu dat, zákazníci k nám přicházejí, když očekávají, že rychlost sítě bude problémem. Ale v procesu pomáhání společnostem překonat tento problém jsme viděli mnoho dalších faktorů, které hrozí vykolejením cloudových migrací, pokud budou opomenuty.
Shromažďování, organizace, formátování a ověřování dat může představovat mnohem větší výzvy než jejich přesun. Zde je několik běžných faktorů, které je třeba zvážit ve fázích plánování migrace cloudu, abyste se později mohli vyhnout časově náročným a nákladným problémům.
Úzké místo pro migraci do cloudu č. 1: Úložiště dat
Nejběžnější chybou, kterou vidíme v cloudových migracích, je tlačit data do cloudového úložiště bez ohledu na to, jak budou tato data použita. Typický myšlenkový proces je: „Chci dát své dokumenty a databáze do cloudu a úložiště objektů je levné, takže tam vložím své dokumenty a databázové soubory.“ Soubory, objekty a databáze se ale chovají velmi odlišně. Vložení vašich bajtů do nesprávného může ochromit vaše cloudové plány.
Soubory jsou uspořádány podle hierarchie cest, adresářového stromu. Ke každému souboru lze rychle přistupovat s minimální latencí (čas do prvního bajtu) a vysokou rychlostí (bitů za sekundu, jakmile data začnou proudit). Jednotlivé soubory lze snadno přesouvat, přejmenovávat a měnit až na úroveň bajtů. Můžete mít mnoho malých souborů, malý počet velkých souborů nebo libovolnou kombinaci velikostí a datových typů. Tradiční aplikace mohou přistupovat k souborům v cloudu stejně, jako by to dělaly v prostorách, bez zvláštního povědomí o cloudu.
Díky všem těmto výhodám je úložiště založené na souborech nejdražší možností, ale ukládání souborů v cloudu má několik dalších nevýhod. K dosažení vysokého výkonu lze k většině cloudových souborových systémů (jako je Amazon EBS) přistupovat pouze k jednomu cloudovému virtuálnímu počítači najednou, což znamená, že všechny aplikace vyžadující tato data musí běžet na jednom cloudovém virtuálním počítači. Chcete-li obsluhovat více virtuálních počítačů (například Azure Files), musíte fronting úložiště s protokolem NAS (síťové úložiště), jako je SMB, což může výrazně omezit výkon. Systémy souborů jsou rychlé, flexibilní a kompatibilní se staršími verzemi, ale jsou drahé, užitečné pouze pro aplikace běžící v cloudu a nemají dobré měřítko.
Objekty nejsou soubory. Pamatujte si to, protože je snadné zapomenout. Objekty žijí v plochém jmenném prostoru, jako jeden obrovský adresář. Latence je vysoká, někdy stovky nebo tisíce milisekund a propustnost je nízká, často se pohybuje kolem 150 megabitů za sekundu, pokud nejsou použity chytré triky. Hodně o přístupu k objektům přichází s chytrými triky, jako je vícedílné nahrávání, přístup k bajtovému rozsahu a optimalizace názvu klíče. Objekty lze číst mnoha cloudovými nativními i webovými aplikacemi najednou, a to jak v cloudu, tak mimo něj, ale tradiční aplikace vyžadují řešení ochromující výkon. Většina rozhraní pro přístup k úložišti objektů umožňuje, aby objekty vypadaly jako soubory: názvy klíčů jsou filtrovány podle předpony, aby vypadaly jako složky, vlastní metadata jsou připojena k objektům, aby vypadaly jako metadata souborů, a některé systémy, jako jsou objekty mezipaměti FUSE, v systému souborů VM umožňují přístup tradičními aplikacemi. Ale taková řešení jsou křehká a míza výkon. Cloudové úložiště je levné, škálovatelné a cloudové nativní, ale je také pomalé a obtížně přístupné.
Databáze mají vlastní složitou strukturu a přistupují k nim pomocí dotazovacích jazyků, jako je SQL. Tradiční databáze mohou být zálohovány úložištěm souborů, ale k poskytování dotazů vyžadují proces živé databáze. To lze zvednout do cloudu zkopírováním databázových souborů a aplikací na virtuální počítač nebo migrací dat do cloudové databázové služby. Ale kopírování databázového souboru do úložiště objektů je užitečné pouze jako offline záloha. Databáze jsou škálovatelné i jako součást služby hostované v cloudu, ale je důležité zajistit, aby aplikace a procesy, které závisí na databázi, byly plně kompatibilní a cloudově nativní. Úložiště databáze je vysoce specializované a specifické pro konkrétní aplikaci.
Vyvážení zjevné úspory nákladů na úložiště objektů a funkčnosti souborů a databází vyžaduje pečlivé zvážení přesně toho, co je požadováno. Například pokud chcete ukládat a distribuovat mnoho tisíc malých souborů, archivujte je do souboru ZIP a uložte je jako jeden objekt, místo abyste se pokoušeli ukládat každý jednotlivý soubor jako samostatný objekt. Nesprávné volby úložiště mohou vést ke složitým závislostem, které je obtížné a nákladné později změnit.
Úzké místo pro migraci do cloudu č. 2: Příprava dat
Přesun dat do cloudu není tak jednoduchý jako kopírování bajtů do určeného typu úložiště. Než se něco zkopíruje, je třeba hodně připravit a ten čas vyžaduje pečlivé sestavení rozpočtu. Projekty proof-of-concept tento krok často ignorují, což může později vést k nákladným překročením.
Filtrování nepotřebných dat může ušetřit spoustu času a nákladů na úložiště. Například datová sada může obsahovat zálohy, dřívější verze nebo stírací soubory, které nemusí být součástí cloudového pracovního postupu. Snad nejdůležitější součástí filtrování je stanovení priorit, která data je třeba nejprve přesunout. Data, která se aktivně používají, nebudou tolerovat, že nebudou synchronizovány v týdnech, měsících nebo letech potřebných k dokončení celého procesu migrace. Klíčem je přijít s automatizovaným prostředkem pro výběr, která data se mají odeslat a kdy, a poté pečlivě zaznamenávat vše, co se dělá a nedělá.
Různé cloudové pracovní postupy mohou vyžadovat, aby data byla v jiném formátu nebo organizaci než místní aplikace. Například legální pracovní postup může vyžadovat překlad tisíců malých dokumentů Word nebo PDF a jejich zabalení do souborů ZIP, pracovní postup médií může zahrnovat překódování a zabalení metadat a pracovní postup bioinformatiky může vyžadovat výběr a rozložení terabajtů genomických dat. Takové přeformátování může být velmi manuální a časově náročný proces. Může to vyžadovat hodně experimentování, hodně dočasného úložiště a hodně zpracování výjimek. Někdy je lákavé odložit jakékoli přeformátování do cloudového prostředí, ale pamatujte, že to problém nevyřeší, pouze ho přesune do prostředí, kde každý zdroj, který používáte, má cenu.
Část otázek týkajících se ukládání a formátování může zahrnovat rozhodnutí o kompresi a archivaci. Například má smysl ZIPovat miliony malých textových souborů před jejich odesláním do cloudu, ale ne několik multimediálních souborů s více gigabajty. Archivace a komprese dat usnadňuje přenos a ukládání dat, ale zvažte čas a úložný prostor potřebný k zabalení a vybalení těchto archivů na obou koncích.
Úzké místo pro migraci do cloudu č. 3: Ověření informací
Kontrola integrity je nejdůležitějším krokem a je také nejjednodušší se pokazit. Často se předpokládá, že během přenosu dat dojde k poškození, ať už je to fyzickým médiem nebo síťovým přenosem, a lze je zachytit provedením kontrolních součtů před a po. Kontrolní součty jsou důležitou součástí procesu, ale ve skutečnosti jde o přípravu a import dat, u nichž je největší pravděpodobnost ztráty nebo poškození.
Když data přesouvají formáty a aplikace, může dojít ke ztrátě významu a funkčnosti, i když jsou bajty stejné. Jednoduchá nekompatibilita mezi verzemi softwaru může způsobit, že petabajty „správných“ dat budou nepoužitelné. Přijít se škálovatelným procesem k ověření, že jsou vaše data správná a použitelná, může být skličující úkol. V nejhorším případě se to může vyvinout v pracný a nepřesný manuální proces „vypadá mi to dobře“. Ale i to je lepší než vůbec žádné ověření. Nejdůležitější věcí je zajistit, abyste byli schopni rozpoznat problémy před vyřazením starších systémů z provozu!
Překážka cloudové migrace č. 4: Zařazování přenosu
Při zvedání jednoho systému do cloudu je poměrně snadné jednoduše zkopírovat připravená data na fyzická média nebo je přesunout přes internet. Ale tento proces může být obtížné škálovat, zejména u fyzických médií. To, co se v důkazu konceptu jeví jako „jednoduché“, může nafouknout do „noční můry“, když do hry vstupuje mnoho různých systémů.
Ke každému stroji musí být připojeno mediální zařízení, například AWS Snowball. To by mohlo znamenat fyzickou procházku zařízením kolem jednoho nebo více datových center, žonglování s konektory, aktualizaci ovladačů a instalaci softwaru. Připojení přes místní síť šetří fyzický pohyb, ale nastavení softwaru může být stále náročné a rychlost kopírování může klesnout hluboko pod to, čeho lze dosáhnout přímým nahráním z Internetu. Přenos dat přímo z každého stroje přes internet šetří mnoho kroků, zejména pokud jsou data připravena na cloud.
Pokud příprava dat zahrnuje kopírování, export, přeformátování nebo archivaci, může se místní úložiště stát překážkou. Může být nutné nastavit vyhrazené úložiště pro fázování připravených dat. To má tu výhodu, že umožňuje mnoha systémům paralelně provádět přípravu, a snižuje kontaktní místa pro přepravitelná média a software pro přenos dat pouze na jeden systém.
Úzké místo pro migraci do cloudu č. 5: Přenos dat
Při porovnávání síťového přenosu s přepravou médií je snadné zaměřit se pouze na dobu přepravy. Například 80 terabajtové zařízení AWS Snowball může být zasláno kurýrem následujícího dne, čímž se dosáhne zdánlivé datové rychlosti více než osm gigabitů za sekundu. To ale ignoruje čas potřebný k získání zařízení, jeho konfiguraci a načtení, přípravě na vrácení a umožnění dodavateli cloudu zkopírovat data na back-end. Zákazníci, kteří to pravidelně dělají, hlásí, že čtyřtýdenní doba zpracování (od objednání zařízení po data dostupná v cloudu) jsou běžné. To přináší skutečnou rychlost přenosu dat při přepravě zařízení až na pouhých 300 megabitů za sekundu, mnohem méně, pokud zařízení není zcela zaplněno.
Rychlost přenosu v síti také závisí na řadě faktorů, především na místním uplinku. Data nemůžete odeslat rychleji, než je fyzická bitová rychlost, i když pečlivá příprava dat může snížit množství dat, která potřebujete odeslat. Starší protokoly, včetně protokolů, které dodavatelé cloudu používají ve výchozím nastavení pro ukládání objektů, mají potíže s rychlostí a spolehlivostí napříč dálkovými internetovými cestami, což může ztěžovat dosažení této bitové rychlosti. Mohl bych napsat mnoho článků o zde obsažených výzvách, ale tohle nemusíte řešit sami. Data Expedition je jednou z mála společností, které se specializují na zajištění plného využití cesty bez ohledu na to, jak daleko jsou vaše data od cloudového cíle. Například jedno gigabitové připojení k internetu s akceleračním softwarem, jako je CloudDat, přináší 900 megabitů za sekundu, což je trojnásobek čisté propustnosti sněhové koule AWS.
Největší rozdíl mezi fyzickou dodávkou a síťovým přenosem je také jedním z nejčastěji přehlížených během proof-of-concept. U fyzické dodávky musí první bajt, který načtete do zařízení, počkat, než se načte poslední bajt, než budete moci odeslat. To znamená, že pokud načtení zařízení trvá týdny, budou v době, kdy dorazí do cloudu, některá z vašich dat zastaralá. I když datové sady dosáhnou úrovně petabyte, kde může být fyzická dodávka ve všech rychlejší, schopnost udržovat aktuální prioritní data během procesu migrace může stále upřednostňovat síťový přenos klíčových aktiv. Pečlivé plánování během fáze filtrování a stanovení priorit přípravy dat je zásadní a může umožnit hybridní přístup.
Získání dat do poskytovatele cloudu nemusí být konec kroku přenosu dat. Pokud je třeba ji replikovat do více regionů nebo poskytovatelů, pečlivě naplánujte, jak se tam dostane. Nahrávání přes internet je zdarma, zatímco AWS například účtuje až dva centy za gigabajt za meziregionální přenos dat a devět centů za gigabajt za přenos k jiným cloudovým prodejcům. Obě metody budou čelit omezením šířky pásma, která by mohla těžit z akcelerace přenosu, jako je CloudDat.
Úzké místo pro migraci cloudu č. 6: Škálování cloudu
Jakmile data dorazí na místo určení v cloudu, je proces migrace dokončen pouze z poloviny. Kontrolní součty jsou na prvním místě: Zkontrolujte, zda se přijaté bajty shodují s odeslanými bajty. To může být složitější, než si možná uvědomujete. Úložiště souborů používá vrstvy mezipaměti, které mohou skrýt poškození dat, která byla právě nahrána. Taková korupce je vzácná, ale dokud to nevyřešíte Všechno mezipaměti a znovu si přečtěte soubory, nemůžete si být jisti žádným kontrolním součtem. Restartování instance nebo odpojení úložiště dělá přijatelnou práci při mazání mezipaměti.
Ověření kontrolních součtů úložiště objektů vyžaduje, aby byl každý objekt pro výpočet načten do instance. Na rozdíl od všeobecného přesvědčení jsou „E-tagy“ objektu ne užitečné jako kontrolní součty. Zejména objekty nahrané pomocí vícedílných technik lze ověřit pouze jejich zpětným načtením.
