Distribuovaný systém souborů pro cloud - Distributed file system for cloud

A distribuovaný souborový systém pro cloud je souborový systém který umožňuje mnoha klientům přístup k datům a podporuje operace (vytváření, mazání, úpravy, čtení, zápis) s těmito daty. Každý datový soubor může být rozdělen na několik tzv. Částí kousky. Každý blok může být uložen na různých vzdálených počítačích, což usnadňuje paralelní provádění aplikací. Data se obvykle ukládají do souborů v a hierarchický strom, kde uzly představují adresáře. Existuje několik způsobů sdílení souborů v distribuované architektuře: každé řešení musí být vhodné pro určitý typ aplikace, v závislosti na složitosti aplikace. Mezitím musí být zajištěna bezpečnost systému. Důvěrnost, dostupnost a integrita jsou hlavní klíče pro zabezpečený systém.

Uživatelé mohou sdílet výpočetní prostředky prostřednictvím Internet díky cloud computing který je typicky charakterizován škálovatelné a elastický zdroje - například fyzické servery, aplikace a jakékoli služby, které jsou virtualizovaný a přiděleno dynamicky. Synchronizace je nutné zajistit, aby všechna zařízení byla aktuální.

Distribuované souborové systémy umožňují mnoha velkým, středním a malým podnikům ukládat a přistupovat ke svým vzdáleným datům stejně jako k místním datům, což usnadňuje použití variabilních zdrojů.

Přehled

Dějiny

Dnes existuje mnoho implementací distribuovaných souborových systémů. První souborové servery vyvinuli vědci v 70. letech. Sun Microsystem Systém síťových souborů byly k dispozici v 80. letech. Před tím lidé, kteří chtěli sdílet soubory, používali sneakernet metoda fyzického přenosu souborů na úložném médiu z místa na místo. Jakmile se počítačové sítě začaly šířit, bylo zřejmé, že stávající souborové systémy mají mnoho omezení a jsou nevhodné pro prostředí více uživatelů. Uživatelé původně používali FTP sdílet soubory.[1] FTP nejprve běžel na PDP-10 na konci roku 1973. I přes FTP bylo nutné soubory kopírovat ze zdrojového počítače na server a poté ze serveru do cílového počítače. Uživatelé byli povinni znát fyzické adresy všech počítačů zapojených do sdílení souborů.[2]

Podpůrné techniky

Moderní datová centra musí podporovat velká, heterogenní prostředí, která se skládají z velkého počtu počítačů různých kapacit. Cloudové výpočty koordinují provoz všech těchto systémů pomocí technik, jako je síť datového centra (DCN) MapReduce rámec, který podporuje datově náročné výpočty - aplikace v paralelních a distribuovaných systémech a - virtualizace techniky, které poskytují dynamické přidělování prostředků, což umožňuje koexistenci více operačních systémů na stejném fyzickém serveru.

Aplikace

Cloudové výpočty poskytuje rozsáhlé výpočty díky své schopnosti poskytnout uživateli potřebné prostředky CPU a úložiště s úplnou transparentností. Díky tomu je cloud computing obzvláště vhodný pro podporu různých typů aplikací, které vyžadují rozsáhlé distribuované zpracování. Tento datově náročné výpočty potřebuje vysoký výkon souborový systém které mohou sdílet data mezi virtuální stroje (VM).[3]

Cloudové výpočty dynamicky přidělují potřebné zdroje a uvolňují je po dokončení úkolu, což vyžaduje, aby uživatelé platili pouze za potřebné služby, často prostřednictvím dohoda o úrovni služeb. Cloudové výpočty a clusterové výpočty paradigmata jsou stále důležitější pro průmyslové zpracování dat a vědecké aplikace, jako je astronomie a fyzika, která k provádění experimentů často vyžaduje dostupnost velkého počtu počítačů.[4]

Architektury

Většina distribuovaných souborových systémů je postavena na architektuře klient-server, ale existují i ​​jiná, decentralizovaná řešení.

Architektura klient-server

Systém síťových souborů (NFS) používá a architektura klient-server, což umožňuje sdílení souborů mezi řadou počítačů v síti, jako by byly umístěny lokálně, a poskytuje standardizované zobrazení. Protokol NFS umožňuje heterogenním procesům klientů, pravděpodobně běžícím na různých počítačích a v různých operačních systémech, přístup k souborům na vzdáleném serveru, přičemž ignoruje skutečné umístění souborů. Spoléhání se na jeden server vede k tomu, že protokol NFS trpí potenciálně nízkou dostupností a špatnou škálovatelností. Použití více serverů nevyřeší problém s dostupností, protože každý server pracuje samostatně.[5] Model NFS je vzdálená souborová služba. Tento model se také nazývá model vzdáleného přístupu, který je v kontrastu s modelem nahrávání / stahování:

  • Model vzdáleného přístupu: Poskytuje transparentnost, klient má přístup k souboru. Odešle požadavky do vzdáleného souboru (zatímco soubor zůstane na serveru).[6]
  • Model nahrávání / stahování: Klient má k souboru přístup pouze místně. To znamená, že klient musí stáhnout soubor, provést úpravy a znovu jej nahrát, aby jej mohli použít klienti jiných uživatelů.

Souborový systém používaný NFS je téměř stejný jako systém používaný Unix systémy. Soubory jsou hierarchicky uspořádány do grafu pojmenování, ve kterém jsou adresáře a soubory reprezentovány uzly.

Klastrové architektury

A klastrová architektura zlepšuje některé z problémů v architekturách klient-server a zlepšuje paralelní provádění aplikací. Zde používanou technikou je prokládání souborů: soubor je rozdělen na několik bloků, které jsou „prokládány“ na několika úložných serverech. Cílem je umožnit paralelní přístup k různým částem souboru. Pokud aplikace z této techniky nevyužívá, pak by bylo pohodlnější ukládat různé soubory na různé servery. Pokud však jde o organizaci distribuovaného systému souborů pro velká datová centra, jako jsou Amazon a Google, která nabízejí služby webovým klientům umožňující více operací (čtení, aktualizace, mazání, ...) velkému počtu souborů distribuovaných mezi velký počet počítačů, pak se klastrová řešení stanou výhodnějšími. Pamatujte, že mít velký počet počítačů může znamenat více selhání hardwaru.[7] Dva z nejpoužívanějších distribuovaných souborových systémů (DFS) tohoto typu jsou Souborový systém Google (GFS) a Systém distribuovaných souborů Hadoop (HDFS). Souborové systémy obou jsou implementovány procesy na úrovni uživatele běžícími na standardním operačním systému (Linux v případě GFS).[8]

Principy návrhu

Cíle

Souborový systém Google (GFS) a Systém distribuovaných souborů Hadoop (HDFS) jsou speciálně vytvořeny pro manipulaci dávkové zpracování pro velmi velké soubory dat. K tomu je třeba vzít v úvahu následující hypotézy:[9]

  • Vysoká dostupnost: shluk může obsahovat tisíce souborových serverů a některé z nich mohou být kdykoli nefunkční
  • Server patří do stojanu, místnosti, datového centra, země a kontinentu, aby bylo možné přesně určit jeho geografickou polohu
  • Velikost souboru se může pohybovat od mnoha gigabajtů po mnoho terabajtů. Souborový systém by měl být schopen podporovat obrovské množství souborů
  • Potřeba podporovat operace přidávání a umožnit viditelnost obsahu souboru i během psaní souboru
  • Komunikace je spolehlivá mezi pracovními stroji: TCP / IP se používá s a vzdálené volání procedur RPC komunikační abstrakce. TCP umožňuje klientovi téměř okamžitě vědět, kdy nastal problém a potřeba provést nové připojení.[10]
Vyrovnávání zatížení

Vyrovnávání zatížení je nezbytné pro efektivní provoz v distribuovaných prostředích. To znamená distribuci práce mezi různé servery,[11] spravedlivě, aby bylo možné za stejnou dobu udělat více práce a rychleji sloužit klientům. V systému obsahujícím N chunkservers v cloudu (N je 1000, 10 000 nebo více), kde je uložen určitý počet souborů, je každý soubor rozdělen na několik částí nebo chunků pevné velikosti (například 64 megabajtů), zatížení každého chunkserveru je úměrné počtu chunks hostovaných serverem.[12] V cloudu s vyváženým zatížením lze prostředky efektivně využívat při maximalizaci výkonu aplikací založených na MapReduce.

Vyvažování zátěže

V prostředí cloud computingu je selhání normou,[13][14] a chunkservers mohou být upgradovány, nahrazeny a přidány do systému. Soubory lze také dynamicky vytvářet, mazat a připojovat. To vede k nerovnováze zatížení v distribuovaném systému souborů, což znamená, že bloky souborů nejsou rovnoměrně rozděleny mezi servery.

Distribuované souborové systémy v cloudech, jako jsou GFS a HDFS, se při správě metadat a vyrovnávání zatížení spoléhají na centrální nebo hlavní servery nebo uzly (Master pro GFS a NameNode pro HDFS). Hlavní rebalancuje pravidelně repliky: data musí být přesunuta z jednoho DataNode / chunkserver do jiného, ​​pokud volné místo na prvním serveru klesne pod určitou prahovou hodnotu.[15] Tento centralizovaný přístup se však může stát překážkou pro tyto hlavní servery, pokud nebudou schopny spravovat velké množství přístupů k souborům, protože to zvýší jejich již tak velké zatížení. Problém s vyvážením zátěže je NP-tvrdé.[16]

Aby bylo možné získat velký počet serverů chunkservers pro spolupráci a vyřešit problém s vyrovnáváním zátěže v distribuovaných souborových systémech, bylo navrženo několik přístupů, například přerozdělení bloků souborů tak, aby mohly být bloky distribuovány co nejjednotněji při současném snížení náklady na pohyb co nejvíce.[12]

Souborový systém Google

Hlavní článek k tomu kategorie je Souborový systém Google.
Popis

Google, jedna z největších internetových společností, vytvořil vlastní distribuovaný souborový systém s názvem Google File System (GFS), který splňuje rychle rostoucí požadavky na potřeby zpracování dat společnosti Google, a používá se pro všechny cloudové služby. GFS je škálovatelný distribuovaný systém souborů pro aplikace náročné na data. Poskytuje vysoce výkonné datové úložiště odolné proti chybám a velký počet klientů, kteří k němu přistupují současně.

GFS používá MapReduce, což umožňuje uživatelům vytvářet programy a spouštět je na více počítačích bez přemýšlení o problémech s paralelizací a vyrovnáváním zátěže. Architektura GFS je založena na tom, že má jeden hlavní server pro více serverů chunkservers a více klientů.[17]

Hlavní server běžící ve vyhrazeném uzlu je zodpovědný za koordinaci úložných zdrojů a správu souborů metadata (ekvivalent například inod v klasických souborových systémech).[9]Každý soubor je rozdělen na několik bloků 64 MB. Každý blok je uložen na serveru bloku. Blok je identifikován popisovačem bloku, což je globálně jedinečné 64bitové číslo, které je přiřazeno hlavním serverem při prvním vytvoření bloku.

Hlavní server udržuje všechna metadata souborů, včetně názvů souborů, adresářů a mapování souborů na seznam bloků, které obsahují data každého souboru. Metadata jsou uchovávána v hlavní paměti hlavního serveru spolu s mapováním souborů na bloky. Aktualizace těchto dat se zaznamenávají do provozního protokolu na disku. Tento protokol operací je replikován na vzdálené počítače. Když se protokol stane příliš velkým, vytvoří se kontrolní bod a data v hlavní paměti se uloží do B-strom struktura usnadňující mapování zpět do hlavní paměti.[18]

Odolnost proti chybám

Umožnit odolnost proti chybám, každý blok je replikován na více (výchozí, tři) servery bloků.[19] Blok je k dispozici alespoň na jednom serveru bloku. Výhodou tohoto schématu je jednoduchost. Hlavní server je zodpovědný za přidělení serverů bloků pro každý blok a je kontaktován pouze pro informace metadat. U všech ostatních dat musí klient interagovat s blokovými servery.

Velitel sleduje, kde se blok nachází. Nepokouší se však přesně udržovat umístění diskových bloků, ale pouze občas kontaktuje servery diskových bloků, aby zjistil, které diskové bloky mají uložené.[20] To umožňuje škálovatelnost a pomáhá předcházet problémovým místům kvůli zvýšené pracovní zátěži.[21]

V GFS se většina souborů upravuje připojováním nových dat a nepřepisováním stávajících dat. Jakmile jsou soubory napsány, jsou obvykle čteny spíše sekvenčně než náhodně, a proto je tento DFS nejvhodnější pro scénáře, ve kterých je vytvořeno mnoho velkých souborů jednou, ale přečteno mnohokrát.[22][23]

Zpracování souborů

Když chce klient zapsat / aktualizovat soubor, hlavní mu přiřadí repliku, která bude primární replikou, pokud se jedná o první modifikaci. Proces psaní se skládá ze dvou kroků:[9]

  • Odesílání: Nejprve a zdaleka nejdůležitější, klient kontaktuje nadřízeného, ​​aby zjistil, které bloky serverů obsahují data. Klient dostane seznam replik identifikujících primární a sekundární bloky serverů. Klient poté kontaktuje nejbližší server replikového bloku a odešle na něj data. Tento server odešle data nejbližšímu nejbližšímu, který je pak předá další replice atd. Data se poté rozšíří a uloží do mezipaměti, ale ještě nejsou zapsána do souboru.
  • Zápis: Když všechna replika přijala data, klient odešle požadavek na zápis na primární server bloku, který identifikuje data, která byla odeslána ve fázi odesílání. Primární server poté přiřadí pořadové číslo operacím zápisu, které přijal, použije zápisy na soubor v pořadí podle sériového čísla a přepošle požadavky na zápis v tomto pořadí sekundárům. Mezitím je pán mimo smyčku.

V důsledku toho můžeme rozlišovat dva typy toků: datový tok a kontrolní tok. Tok dat je spojen s fází odesílání a tok toku je spojen s fází zápisu. Tím je zajištěno, že primární blok bloků převezme kontrolu nad pořadí zápisu. Všimněte si, že když hlavní server přiřadí operaci zápisu replice, zvýší číslo verze bloku a informuje všechny repliky obsahující tento blok o novém čísle verze. Čísla verzí diskových bloků umožňují detekci chyb aktualizace, pokud nebyla aktualizována replika, protože její server bloků byl nefunkční.[24]

Některé nové aplikace Google nefungovaly dobře s velikostí bloku 64 megabajtů. K vyřešení tohoto problému zahájila společnost GFS v roce 2004 implementaci Bigtable přístup.[25]

Distribuovaný systém souborů Hadoop

Hlavní článek k tomu kategorie je Apache Hadoop.

HDFS , vyvinutý společností Softwarová nadace Apache, je distribuovaný souborový systém navržený k ukládání velmi velkého množství dat (terabajtů nebo dokonce petabajtů). Jeho architektura je podobná GFS, tj. Architektura master / slave. HDFS se běžně instaluje na klastr počítačů. Konstrukční koncept Hadoop je informován společností Google, pomocí systému souborů Google, Google MapReduce a Bigtable, který je implementován systémy Hadoop Distributed File System (HDFS), Hadoop MapReduce a Hadoop Base (HBase).[26] Stejně jako GFS je i HDFS vhodný pro scénáře s přístupem k souborům typu read-once-read-many a podporuje namísto náhodných čtení a zápisů přidávání a zkracování souborů, aby se zjednodušily problémy s koherencí dat.[27]

Klastr HDFS se skládá z jednoho NameNode a několika DataNode strojů. NázevNode, hlavní server, spravuje a udržuje metadata datových uzlů úložiště v jeho paměti RAM. DataNodes spravují úložiště připojené k uzlům, na kterých běží. NameNode a DataNode jsou software navržený pro provoz na strojích pro každodenní použití, které běžně běží pod operačním systémem GNU / Linux. HDFS lze spustit na jakémkoli počítači, který podporuje Javu, a proto může běžet buď NameNode nebo software Datanode.[28]

V klastru HDFS je soubor rozdělen do jednoho nebo více bloků stejné velikosti, s výjimkou možnosti, že bude poslední blok menší. Každý blok je uložen na více DataNodes a každý může být replikován na více DataNodes, aby byla zaručena dostupnost. Ve výchozím nastavení je každý blok replikován třikrát, což je proces nazvaný „Replikace úrovně bloku“.[29]

NameNode spravuje operace oboru názvů systému souborů, jako je otevírání, zavírání a přejmenování souborů a adresářů, a reguluje přístup k souborům. Určuje také mapování bloků na DataNodes. DataNodes jsou zodpovědní za obsluhu požadavků na čtení a zápis od klientů systému souborů, správu alokace nebo mazání bloků a replikaci bloků.[30]

Když chce klient číst nebo zapisovat data, kontaktuje NameNode a NameNode zkontroluje, odkud mají být data načtena nebo zapsána. Poté má klient umístění DataNode a může do něj odesílat požadavky na čtení nebo zápis.

HDFS se obvykle vyznačuje svou kompatibilitou se schématy rebalancování dat. Obecně je správa volného místa na DataNode velmi důležitá. Data musí být přesunuta z jednoho DataNode do druhého, pokud není dostatek volného místa; a v případě vytvoření dalších replik by měla být data přesunuta, aby byla zajištěna rovnováha systému.[29]

Další příklady

Distribuované souborové systémy lze optimalizovat pro různé účely. Některé, například ty, které jsou určeny pro internetové služby, včetně GFS, jsou optimalizovány pro škálovatelnost. Jiné návrhy distribuovaných souborových systémů podporují výkonově náročné aplikace, které se obvykle spouštějí paralelně.[31] Některé příklady zahrnují: Systém souborů MapR (MapR-FS), Ceph-FS, Systém souborů Fraunhofer (BeeGFS), Lesklý souborový systém, IBM General Parallel File System (GPFS) a Paralelní virtuální souborový systém.

MapR-FS je distribuovaný souborový systém, který je základem MapR Converged Platform, s možnostmi úložiště distribuovaných souborů, databází NoSQL s více API a integrovaným systémem pro streamování zpráv. MapR-FS je optimalizován pro škálovatelnost, výkon, spolehlivost a dostupnost. Jeho schopnost ukládání souborů je kompatibilní s API Apache Hadoop Distributed File System (HDFS), ale s několika designovými charakteristikami, které ho odlišují od HDFS. Mezi nejpozoruhodnější rozdíly patří to, že MapR-FS je plně čitelný / zapisovaný souborový systém s metadaty pro soubory a adresáře distribuované po celém oboru názvů, takže neexistuje žádný NameNode.[32][33][34][35][36]

Ceph-FS je distribuovaný souborový systém, který poskytuje vynikající výkon a spolehlivost.[37] Odpovídá na výzvy spojené s manipulací s obrovskými soubory a adresáři, koordinací činnosti tisíců disků, poskytováním paralelního přístupu k metadatům v masovém měřítku, manipulací s vědeckými i obecnými úlohami, ověřováním a šifrováním ve velkém měřítku a zvyšováním nebo dynamicky klesá kvůli častému vyřazování zařízení z provozu, poruchám zařízení a rozšiřování clusterů.[38]

BeeGFS je vysoce výkonný paralelní souborový systém z Fraunhofer Competence Center for High Performance Computing. Architektura distribuovaných metadat BeeGFS byla navržena tak, aby poskytovala škálovatelnost a flexibilitu potřebnou ke spuštění HPC a podobné aplikace s vysokými požadavky na I / O.[39]

Luster File System byl navržen a implementován tak, aby řešil problém úzkých míst tradičně vyskytujících se v distribuovaných systémech. Lesk se vyznačuje svou účinností, škálovatelností a redundancí.[40] GPFS byl také navržen s cílem odstranit taková úzká místa.[41]

Sdělení

Vysoký výkon distribuovaných souborových systémů vyžaduje efektivní komunikaci mezi výpočetními uzly a rychlý přístup k úložným systémům. Operace, jako je otevírání, zavírání, čtení, zápis, odesílání a příjem, musí být rychlé, aby byl zajištěn tento výkon. Například každý požadavek na čtení nebo zápis přistupuje k diskovému úložišti, které zavádí latenci hledání, rotace a sítě.[42]

Operace datové komunikace (odesílání / příjem) přenášejí data z vyrovnávací paměti aplikace do jádra stroje, TCP řízení procesu a implementace v jádře. V případě přetížení sítě nebo chyb však nemusí TCP odeslat data přímo. Při přenosu dat z vyrovnávací paměti v jádro do aplikace stroj nečte stream bajtů ze vzdáleného stroje. Ve skutečnosti je protokol TCP odpovědný za ukládání dat do vyrovnávací paměti pro aplikaci.[43]

Výběr velikosti vyrovnávací paměti pro čtení a zápis souborů nebo pro odesílání a příjem souborů se provádí na úrovni aplikace. Vyrovnávací paměť je udržována pomocí a kruhový propojený seznam.[44] Skládá se ze sady BufferNodes. Každý BufferNode má DataField. DataField obsahuje data a ukazatel s názvem NextBufferNode, který ukazuje na další BufferNode. Chcete-li zjistit aktuální pozici, dvě ukazatele jsou použity: CurrentBufferNode a EndBufferNode, které představují pozici v BufferNode pro poslední pozici pro zápis a čtení. Pokud BufferNode nemá volné místo, odešle klientovi signál čekání, aby počkal, dokud nebude k dispozici místo.[45]

Cloudová synchronizace distribuovaného systému souborů

Stále více uživatelů má více zařízení s ad hoc připojením. Datové sady replikované na těchto zařízeních je třeba synchronizovat mezi libovolným počtem serverů. To je užitečné pro zálohování a také pro offline provoz. Ve skutečnosti, když podmínky v síti uživatele nejsou dobré, zařízení uživatele selektivně replikuje část dat, která bude později upravena a offline. Jakmile se síťové podmínky zlepší, zařízení se synchronizuje.[46] K řešení problému distribuované synchronizace existují dva přístupy: uživatelsky řízená synchronizace typu peer-to-peer a synchronizace cloudu s replikou.[46]

  • uživatelem řízený peer-to-peer: software, jako je rsync musí být nainstalován ve všech počítačích uživatelů, které obsahují jejich data. Soubory jsou synchronizovány synchronizací typu peer-to-peer, kde uživatelé musí specifikovat síťové adresy a parametry synchronizace, a je tedy manuálním procesem.
  • cloudová synchronizace hlavní repliky: široce používaná cloudovými službami, ve kterých je hlavní replika udržována v cloudu, a všechny aktualizace a synchronizační operace jsou v této hlavní kopii, což nabízí vysokou úroveň dostupnosti a spolehlivosti v případě selhání.

Bezpečnostní klíče

V cloud computingu nejdůležitější bezpečnostní koncepty jsou důvěrnost, integrita, a dostupnost ("CIA "). Důvěrnost se stává nepostradatelnou pro zabránění vyzrazení soukromých dat. Integrita zajišťuje, že data nebudou poškozena.[47]

Důvěrnost

Důvěrnost znamená, že úlohy týkající se dat a výpočtu jsou důvěrné: ani poskytovatel cloudu, ani ostatní klienti nemají přístup k datům klienta. Bylo provedeno mnoho výzkumu o důvěrnosti, protože je to jeden z klíčových bodů, které stále představují výzvy pro cloud computing. Souvisejícím problémem je také nedůvěra v poskytovatele cloudových služeb.[48] Infrastruktura cloudu musí zajistit, aby k datům zákazníků neměly přístup neoprávněné strany.

Prostředí se stává nejistým, pokud poskytovatel služeb může provádět následující činnosti:[49]

  • vyhledejte data spotřebitele v cloudu
  • přistupovat a načítat data spotřebitele
  • pochopit význam dat (typy dat, funkce a rozhraní aplikace a formát dat).

Geografické umístění dat pomáhá určit soukromí a důvěrnost. Mělo by se vzít v úvahu umístění klientů. Například klienti v Evropě nebudou mít zájem o používání datových center umístěných ve Spojených státech, protože to ovlivní záruku důvěrnosti dat. Aby bylo možné tento problém vyřešit, někteří prodejci cloud computingu zahrnuli geografické umístění hostitele jako parametr dohody o úrovni služeb uzavřené se zákazníkem,[50] umožňující uživatelům zvolit si umístění serverů, které budou jejich data hostovat.

Další přístup k důvěrnosti zahrnuje šifrování dat.[51] V opačném případě bude existovat vážné riziko neoprávněného použití. Existuje celá řada řešení, například šifrování pouze citlivých dat,[52] a podporuje pouze některé operace, aby se zjednodušil výpočet.[53] Dále kryptografické techniky a nástroje jako FHE, slouží k ochraně soukromí v cloudu.[47]

Integrita

Integrita v cloud computingu znamená integrita dat stejně jako výpočetní integrita. Taková integrita znamená, že data musí být správně uložena na cloudových serverech a v případě selhání nebo nesprávného výpočtu musí být zjištěny problémy.

Integritu dat mohou ovlivnit škodlivé události nebo chyby správy (např. Během záloha a obnovit, migrace dat nebo změna členství v P2P systémy).[54]

Integrity lze snadno dosáhnout pomocí kryptografie (obvykle prostřednictvím ověřovací kód zprávy nebo MAC na datových blocích).[55]

Existují kontrolní mechanismy, které ovlivňují integritu dat. Například:

  • HAIL (High-Availability and Integrity Layer) je distribuovaný kryptografický systém, který umožňuje sadě serverů prokázat klientovi, že uložený soubor je neporušený a vyhledatelný.[56]
  • Hach POR (důkazy o) návratnost pro velké soubory)[57] je založen na symetrickém kryptografickém systému, kde existuje pouze jeden ověřovací klíč, který musí být uložen v souboru, aby se zlepšila jeho integrita. Tato metoda slouží k zašifrování souboru F a následnému vygenerování náhodného řetězce s názvem „sentinel“, který musí být přidán na konec zašifrovaného souboru. Server nemůže lokalizovat sentinel, což je nemožné odlišit od ostatních bloků, takže malá změna by naznačovala, zda byl soubor změněn nebo ne.
  • Kontrola PDP (prokazatelné držení dat) je třída efektivních a praktických metod, které poskytují efektivní způsob kontroly integrity dat na nedůvěryhodných serverech:
    • PDP:[58] Před uložením dat na server musí klient lokálně uložit některá metadata. Později a bez stahování dat je klient schopen požádat server o kontrolu, zda data nebyla zfalšována. Tento přístup se používá pro statická data.
    • Škálovatelné PDP:[59] Tento přístup je založen na symetrickém klíči, který je efektivnější než šifrování pomocí veřejného klíče. Podporuje některé dynamické operace (modifikace, mazání a přidávání), ale nelze jej použít pro veřejné ověření.
    • Dynamický PDP:[60] Tento přístup rozšiřuje model PDP tak, aby podporoval několik aktualizačních operací, jako je přidání, vložení, úprava a odstranění, což je vhodné pro intenzivní výpočet.

Dostupnost

Dostupnost je obecně ovlivněno replikace.[61][62][63][64] Mezitím musí být zaručena konzistence. Konzistence a dostupnosti však nelze dosáhnout současně; každý má přednost při nějaké oběti toho druhého. Musí být nastolena rovnováha.[65]

Data musí mít identitu, aby byla přístupná. Například Skute [61] je mechanismus založený na úložišti klíč / hodnota, který umožňuje efektivní alokaci dynamických dat. Každý server musí být označen štítkem ve tvaru kontinent-země-datové centrum-místnost-rack-server. Server může odkazovat na více virtuálních uzlů, přičemž každý uzel má výběr dat (nebo více oddílů s více daty). Každá část dat je identifikována klíčovým prostorem, který je generován jednosměrnou kryptografickou hashovací funkcí (např. MD5 ) a je lokalizován hodnotou hash funkce tohoto klíče. Prostor pro klíče může být rozdělen na více oddílů, přičemž každý oddíl odkazuje na část dat. K provedení replikace musí být virtuální uzly replikovány a odkazovány jinými servery. Aby se maximalizovala trvanlivost dat a dostupnost dat, musí být repliky umístěny na různých serverech a každý server by měl být v jiném geografickém umístění, protože dostupnost dat se zvyšuje s geografickou rozmanitostí. Proces replikace zahrnuje vyhodnocení dostupnosti místa, které musí být nad určitou minimální mezní hodnotou pro každý server bloku. Jinak jsou data replikována na jiný server bloku. Každý oddíl, i, má hodnotu dostupnosti představovanou následujícím vzorcem:

kde jsou servery hostující repliky, a jsou důvěra serverů a (spoléhání se na technické faktory, jako jsou hardwarové komponenty a netechnické, jako je ekonomická a politická situace v zemi) a rozmanitost je zeměpisná vzdálenost mezi a .[66]

Replikace je skvělé řešení pro zajištění dostupnosti dat, ale stojí příliš mnoho, pokud jde o paměťový prostor.[67] DiskReduce[67] je upravená verze HDFS, která je založena na NÁLET technologie (RAID-5 a RAID-6) a umožňuje asynchronní kódování replikovaných dat. Ve skutečnosti existuje proces na pozadí, který hledá široce replikovaná data a po jejich kódování odstraní další kopie. Dalším přístupem je nahradit replikaci vymazáním kódování.[68] Kromě toho k zajištění dostupnosti dat existuje mnoho přístupů, které umožňují obnovu dat. Ve skutečnosti musí být data kódována, a pokud dojde ke ztrátě, lze je obnovit z fragmentů, které byly vytvořeny během fáze kódování.[69] Některé další přístupy, které používají různé mechanismy k zajištění dostupnosti, jsou: Reed-Solomonův kód Microsoft Azure a RaidNode pro HDFS. Google také stále pracuje na novém přístupu založeném na mechanismu mazání a kódování.[70]

Pro cloudové úložiště neexistuje žádná implementace RAID.[68]

Ekonomické aspekty

Ekonomika cloud computingu rychle roste. Vláda USA se rozhodla utratit 40% své částky složená roční míra růstu (CAGR), očekává se, že do roku 2015 bude 7 miliard dolarů.[71]

Stále více společností využívá cloud computing ke správě obrovského množství dat a k překonání nedostatku úložné kapacity, a protože jim umožňuje využívat tyto zdroje jako službu, zajišťuje, že jejich výpočetní potřeby budou splněny, aniž by bylo nutné investovat v infrastruktuře (model Pay-as-you-go).[72]

Každý poskytovatel aplikace musí pravidelně platit náklady za každý server, na kterém jsou uloženy repliky dat. Cena serveru je dána kvalitou hardwaru, kapacitami úložiště a režií zpracování dotazů a komunikace.[73] Cloudové výpočty umožňují poskytovatelům škálovat své služby podle požadavků klienta.

Model pay-as-you-go také zmírnil zátěž začínajících společností, které chtějí těžit z podnikání náročného na výpočetní techniku. Cloudové výpočty také nabízejí příležitost mnoha zemím třetího světa, které by jinak neměly takové výpočetní zdroje. Cloudové výpočty mohou snížit překážky IT v inovaci.[74]

I přes široké využití cloudových výpočtů je efektivní sdílení velkých objemů dat v nedůvěryhodném cloudu stále výzvou.

Reference

  1. ^ Sluneční mikrosystém, str. 1
  2. ^ Fabio Kon, str. 1
  3. ^ Kobayashi a kol. 2011, str. 1
  4. ^ Angabini a kol. 2011, str. 1
  5. ^ Di Sano a kol. 2012, str. 2
  6. ^ Andrew & Maarten 2006, str. 492
  7. ^ Andrew & Maarten 2006, str. 496
  8. ^ Humbetov 2012, str. 2
  9. ^ A b C Krzyzanowski 2012, str. 2
  10. ^ Pavel Bžoch, str. 7
  11. ^ Kai a kol. 2013, str. 23
  12. ^ A b Hsiao a kol. 2013, str. 2
  13. ^ Hsiao a kol. 2013, str. 952
  14. ^ Ghemawat, Gobioff a Leung 2003, str. 1
  15. ^ Ghemawat, Gobioff a Leung 2003, str. 8
  16. ^ Hsiao a kol. 2013, str. 953
  17. ^ Di Sano a kol. 2012, s. 1–2
  18. ^ Krzyzanowski 2012, str. 4
  19. ^ Di Sano a kol. 2012, str. 2
  20. ^ Andrew & Maarten 2006, str. 497
  21. ^ Humbetov 2012, str. 3
  22. ^ Humbetov 2012, str. 5
  23. ^ Andrew & Maarten 2006, str. 498
  24. ^ Krzyzanowski 2012, str. 5
  25. ^ „The Great Disk Drive in the Sky: How Web giants store big - and we mean big - data“. 2012-01-27.
  26. ^ Fan-Hsun a kol. 2012, str. 2
  27. ^ „Apache Hadoop 2.9.2 - HDFS Architecture“.
  28. ^ Azzedin 2013, str. 2
  29. ^ A b Adamov 2012, str. 2
  30. ^ Yee & Thu Naing 2011, str. 122
  31. ^ Soares a kol. 2013, str. 158
  32. ^ Perez, Nicolas (01.01.2016). „Jak MapR zvyšuje naši produktivitu a zjednodušuje náš design“. Střední. Střední. Citováno 21. června 2016.
  33. ^ Woodie, Alex (08.03.2016). „Od Hadoopu po Zetu: konverze konvergence uvnitř MapR“. Datanami. Tabor Communications Inc.. Citováno 21. června 2016.
  34. ^ Brennanová, Bob. "Flash Memory Summit". Youtube. Samsung. Citováno 21. června 2016.
  35. ^ Srivas, MC. "Systém souborů MapR". Summit Hadoop 2011. Hortonworks. Citováno 21. června 2016.
  36. ^ Dunning, Ted; Friedman, Ellen (leden 2015). „Kapitola 3: Porozumění distribuci MapR pro Apache Hadoop“. Real World Hadoop (První vydání). Sebastopol, CA: O'Reilly Media, Inc. str. 23–28. ISBN  978-1-4919-2395-5. Citováno 21. června 2016.
  37. ^ Weil a kol. 2006, str. 307
  38. ^ Maltzahn a kol. 2010, str. 39
  39. ^ Jacobi & Lingemann, str. 10
  40. ^ Schwan Philip 2003, str. 401
  41. ^ Jones, Koniges & Yates 2000, str. 1
  42. ^ Upadhyaya et al. 2008, str. 400
  43. ^ Upadhyaya et al. 2008, str. 403
  44. ^ Upadhyaya et al. 2008, str. 401
  45. ^ Upadhyaya et al. 2008, str. 402
  46. ^ A b Uppoor, Flouris & Bilas 2010, str. 1
  47. ^ A b Zhifeng & Yang 2013, str. 854
  48. ^ Zhifeng & Yang 2013, str. 845–846
  49. ^ Yau & An 2010, str. 353
  50. ^ Vecchiola, Pandey & Buyya 2009, str. 14
  51. ^ Yau & An 2010, str. 352
  52. ^ Miranda & Siani 2009
  53. ^ Naehrig & Lauter 2013
  54. ^ Zhifeng & Yang 2013, str. 5
  55. ^ Juels & Oprea 2013, str. 4
  56. ^ Bowers, Juels & Oprea 2009
  57. ^ Juels & S.Kaliski 2007, str. 2
  58. ^ Ateniese a kol. 2007
  59. ^ Ateniese a kol. 2008, s. 5, 9
  60. ^ Erway a kol. 2009, str. 2
  61. ^ A b Bonvin, Papaioannou & Aberer 2009, str. 206
  62. ^ Cuong a kol. 2012, str. 5
  63. ^ A., A. & P. ​​2011, str. 3
  64. ^ Qian, D. & T. 2011, str. 3
  65. ^ Vogels 2009, str. 2
  66. ^ Bonvin, Papaioannou a Aberer 2009, str. 208
  67. ^ A b Carnegie a kol. 2009, str. 1
  68. ^ A b Wang a kol. 2012, str. 1
  69. ^ Abu-Libdeh, Princehouse & Weatherspoon 2010, str. 2
  70. ^ Wang a kol. 2012, str. 9
  71. ^ Lori M. Kaufman 2009, str. 2
  72. ^ Angabini a kol. 2011, str. 1
  73. ^ Bonvin, Papaioannou a Aberer 2009, str. 3
  74. ^ Marston a kol. 2011, str. 3

Bibliografie

  1. Architektura, struktura a design:
  2. Bezpečnostní
  3. Synchronizace
    • Uppoor, S; Flouris, M.D; Bilas, A (2010). "Cloud-based synchronization of distributed file system hierarchies". 2010 IEEE International Conference on Cluster Computing Workshops and Posters (CLUSTER WORKSHOPS). Inst. of Comput. Sci. (ICS), Found. for Res. & Technol. - Hellas (FORTH), Heraklion, Greece. s. 1–4. doi:10.1109/CLUSTERWKSP.2010.5613087. ISBN  978-1-4244-8395-2. S2CID  14577793.
  4. Ekonomické aspekty
    • Lori M., Kaufman (2009). "Data Security in the World of Cloud Computing". Security & Privacy, IEEE. 7 (4): 161–64. doi:10.1109/MSP.2009.87. S2CID  16233643.
    • Marston, Sean; Lia, Zhi; Bandyopadhyaya, Subhajyoti; Zhanga, Juheng; Ghalsasi, Anand (2011). Cloud computing — The business perspective. Decision Support Systems Volume 51, Issue 1. pp. 176–189. doi:10.1016/j.dss.2010.12.006.
    • Angabini, A; Yazdani, N; Mundt, T; Hassani, F (2011). "Suitability of Cloud Computing for Scientific Data Analyzing Applications; an Empirical Study". 2011 International Conference on P2P, Parallel, Grid, Cloud and Internet Computing. Sch. of Electr. & Comput. Eng., Univ. of Tehran, Tehran, Iran. pp. 193–199. doi:10.1109/3PGCIC.2011.37. ISBN  978-1-4577-1448-1. S2CID  13393620.