Finanční efektivita, měřítko a možnosti správy cloudového úložiště jsou nedosažitelné i pro datová centra největších společností. Poskytovatelé hyperškálovatelných cloudových úložišť, jako jsou AWS (Amazon), Google nebo Azure (Microsoft), snížili v minulém roce ceny až o 65 procent a slíbili, že ceny budou v budoucnu odpovídat tzv. Mooreovu zákonu.
AWS nabízí jedenáctidevítkovou trvanlivost, což znamená, že při uložení deset tisíc objektů pomocí Amazonu S3 můžete průměrně očekávat ztrátu jednoho objektu jednou za deset milionů let. Amazon S3 je také navržen tak, aby vydržel současnou ztrátu dat ve dvou lokalitách – ukládá objekty ve více zařízeních v rámci různých lokalit.
Až do nedávné doby však bylo cloudové úložiště opravdu užitečné jen pro nepoužívaná data, a nikoli pro produkční údaje. Jinými slovy – cloudové úložiště je levné a velké, ale není schopné nabídnout výkon místního úložiště.
Aby se mohlo cloudové úložiště rozumně využívat také pro ukládání nestrukturovaných dat, musí poskytnout ekvivalentní flexibilitu, výkon a produktivitu jako podnikové úložné systémy. Cenová výhodnost, přestože je sama o sobě přesvědčivá, v tomto případě jednoduše nestačí.
Aby bylo možné použít cloud pro oboje – aktivní i neaktivní data – musí fungovat stejně nebo lépe než lokální, již nasazená úložiště. Proto je nezbytné splnit následující klíčové požadavky:
1. Lokální cache: Vzhledem k očekávání uživatelů, že budou doby přístupu podobné jako u LAN, je nutné ukládat aktivní data do lokální vyrovnávací paměti, zatímco neaktivní data jsou přímo v cloudu.
K většině dat není potřebné přistupovat příliš často a výborně se hodí pro cloud, aktivní data však musejí zůstat blízko uživatele. Pro zajištění toho, aby se do vyrovnávací paměti ukládaly pouze ty správné soubory, je nutné použít strojové učení založené na využití souborů, „připnuté složky“ nebo kombinaci obou metod.
2. Globální deduplikace: Ta zajišťuje, aby se do cloudu a do vyrovnávací paměti ukládal jen jeden unikátní blok dat. Globální deduplikace snižuje díky výskytu stejných bloků v různých souborech množství dat uložených v cloudu, takže se mezi cloudem a místními vyrovnávacími paměťmi přenášejí jen změny.
Když například známá herní firma Electronic Arts centralizovala svá data v cloudovém úložišti, poklesla spotřebovaná úložná kapacita z 1,5 PB na pouhých 45 TB. Doba potřebná k přenosu 50GB hry mezi pobočkami se navíc snížila z až deseti hodin na minuty, protože se ve skutečnosti přenášejí jen změny v sestaveních.
3. Rychlost reakce jako u NAS: Procházení složkami souborů musí být stejně rychlé jako u lokálního NAS. Za tímto účelem by se měla na SSD na všech pracovištích místně ukládat nejen aktivní data, ale také metadata všech souborů, nejen souborů uložených ve vyrovnávací paměti.
SSD jsou nutné, aby mohl uživatel vidět úplné zastoupení všech souborů v celém souborovém systému, přestože je v místní vyrovnávací paměti uloženo jen 5 % souborů. Když uživatel zobrazuje soubory ve složkách na síťovém disku, musí se to jevit tak, jako by tam byly všechny soubory.
Protože se součást metadat souboru často zobrazuje s názvem souboru a uzamčení souboru musí být pro každý soubor okamžité, přestože se nenachází v místní paměti cache, je nezbytné mít přístup k metadatům co nejrychlejší.
Bez metadat všech souborů ve vyrovnávací paměti cache si uživatelé myslí, že jejich počítač či síť fungují pomalu, protože je procházení složkami jednou ze základních funkcí.
4. Podpora „upovídaných“ aplikací: Aplikace musejí fungovat současně na všech pracovištích tak, jako by pracovaly na jednom místě. Mnoho technických aplikací (CAD, PLM, BIM) je velmi upovídaných, což obvykle prodlužuje čas na otevření, uložení a synchronizaci souboru z méně než 30 sekund v lokálním NAS na více než 20 minut v případě centralizace v cloudu.
Mnoho lidí si sice myslí, že je to důsledek šířky pásma, skutečnou příčinou je ale nadměrná upovídanost aplikací – běžná aplikace CAD například musí vykonat při otevírání souboru téměř 16 tisíc sekvenčních operací. Pokud je směrodatná kopie ve stejné síti LAN, trvá uzamčení souboru jen 0,5 ms, takže se soubor otevře za osm sekund (tj. 16 000 * 0,5 ms).
Upovídanost však způsobuje obrovská zpoždění při práci v síti WAN. Je-li soubor centrálně uložený v Londýně vzdáleně otevíraný z Prahy, trvá uzamčení desítky ms, takže otevření souboru trvá spoustu minut. Vlastní přenos dat potom představuje jen zlomek ze zmíněné doby.
5. Integrita dat a zamykání mezi pracovišti. Když se data nacházejí na souborovém serveru, musíme se starat jen o udržení jedné konzistentní kopie (pokud je soubor uzamčený, když ho nějaký uživatel edituje). To se změní, když se data ukládají do cloudu a přistupuje se k nim z mnoha pracovišť. Chcete-li zabránit...
Tento příspěvek vyšel v Computerworldu 11/2015.Oproti této on-line verzi je výrazně obsáhlejší a přináší další poznatky a tipy, které lze využít při praktické implementaci u vás ve firmě.
Časopis (starší čísla i předplatné těch nadcházejících) si můžete objednat na adrese našeho vydavatelství.