{"id":38542,"date":"2019-10-31T22:24:25","date_gmt":"2019-10-31T19:24:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs\/"},"modified":"2019-10-31T22:24:25","modified_gmt":"2019-10-31T19:24:25","slug":"giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","title":{"rendered":"Hiper-konwergentne rozwi\u0105zanie AERODISK vAIR. Podstaw\u0105 jest system plik\u00f3w ARDFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hiper-konwergentne<\/p>\n

<\/p>\n

Cze\u015b\u0107, czytelnicy Habra. Tym artyku\u0142em otwieramy cykl, kt\u00f3ry b\u0119dzie opowiada\u0107 o opracowanym przez nas hiperkonwergentnym systemie AERODISK vAIR. Pocz\u0105tkowo chcieli\u015bmy w pierwszym artykule opisa\u0107 wszystko, ale system jest do\u015b\u0107 skomplikowany, dlatego b\u0119dziemy je\u015b\u0107 s\u0142onia po kawa\u0142ku. <\/p>\n

<\/p>\n

Rozpoczniemy opowie\u015b\u0107 od historii powstania systemu, zag\u0142\u0119bimy si\u0119 w system plik\u00f3w ARDFS, kt\u00f3ry stanowi podstaw\u0119 vAIR, a tak\u017ce nieco porozmawiamy o pozycjonowaniu tego rozwi\u0105zania na rosyjskim rynku. <\/p>\n

<\/p>\n

W kolejnych artyku\u0142ach szczeg\u00f3\u0142owo opowiemy o r\u00f3\u017cnych komponentach architektonicznych (klaster, hipernadzorca, serwer r\u00f3wnowa\u017c\u0105cy obci\u0105\u017cenie, system monitorowania itp.), procesie konfiguracji, poruszymy kwestie licencjonowania, osobno poka\u017cemy testy wytrzyma\u0142o\u015bciowe i, oczywi\u015bcie, napiszemy o testowaniu obci\u0105\u017cenia i sizingu. Osobny artyku\u0142 po\u015bwi\u0119cimy wersji community vAIR.<\/p>\n

<\/a><\/noindex><\/p>\n

AERODISK \u2014 czy to historia o systemach pami\u0119ci masowej? A mo\u017ce po co w og\u00f3le zacz\u0119li\u015bmy zajmowa\u0107 si\u0119 hiperkonwergencj\u0105?<\/h2>\n

<\/p>\n

Pocz\u0105tkowa idea stworzenia w\u0142asnej hiperkonwergencji przysz\u0142a do nas gdzie\u015b w okolicach 2010 roku. Wtedy jeszcze nie by\u0142o ani AERODISK, ani podobnych rozwi\u0105za\u0144 (komercyjnych, gotowych system\u00f3w hiperkonwergentnych) na rynku. Naszym zadaniem by\u0142o nast\u0119puj\u0105ce: z zestawu serwer\u00f3w z lokalnymi dyskami, po\u0142\u0105czonych interkonektami przez protok\u00f3\u0142 Ethernet, trzeba by\u0142o stworzy\u0107 rozproszone magazynowanie i jednocze\u015bnie uruchamia\u0107 maszyny wirtualne i sie\u0107 programow\u0105. Wszystko to musia\u0142o by\u0107 zrealizowane bez system\u00f3w pami\u0119ci masowej (poniewa\u017c na systemy pami\u0119ci masowej i ich otoczenie po prostu nie by\u0142o pieni\u0119dzy, a w\u0142asnego systemu pami\u0119ci masowej jeszcze nie wynale\u017ali\u015bmy).<\/p>\n

<\/p>\n

Wypr\u00f3bowali\u015bmy wiele rozwi\u0105za\u0144 open source i w ko\u0144cu rozwi\u0105zali\u015bmy to zadanie, ale rozwi\u0105zanie by\u0142o bardzo skomplikowane i trudno by\u0142o je powt\u00f3rzy\u0107. Ponadto rozwi\u0105zanie to by\u0142o z rodzaju \u201eDzia\u0142a? Nie ruszaj!\u201d. Dlatego, rozwi\u0105zuj\u0105c ten problem, nie postanowili\u015bmy dalej rozwija\u0107 idei przekszta\u0142cania efekt\u00f3w naszej pracy w pe\u0142noprawny produkt. <\/p>\n

<\/p>\n

Po tym do\u015bwiadczeniu odeszli\u015bmy od tej idei, ale nadal nie opuszcza\u0142o nas wra\u017cenie, \u017ce zadanie to jest ca\u0142kowicie wykonalne, a korzy\u015bci z takiego rozwi\u0105zania s\u0105 wi\u0119cej ni\u017c oczywiste. W p\u00f3\u017aniejszym czasie wydane przez zagraniczne firmy produkty HCI tylko potwierdzi\u0142y to wra\u017cenie. <\/p>\n

<\/p>\n

W po\u0142owie 2016 roku wr\u00f3cili\u015bmy do tego zadania w ramach tworzenia kompleksowego produktu. W\u00f3wczas nie mieli\u015bmy jeszcze \u017cadnych relacji z inwestorami, wi\u0119c musieli\u015bmy kupi\u0107 stoisko deweloperskie za nasze do\u015b\u0107 niewielkie pieni\u0105dze. Zbieraj\u0105c u\u017cywane serwery i prze\u0142\u0105czniki na Avito, zabrali\u015bmy si\u0119 do pracy.<\/p>\n

<\/p>\n

\"Hiper-konwergentne<\/p>\n

<\/p>\n

G\u0142\u00f3wnym zadaniem na pocz\u0105tku by\u0142o stworzenie w\u0142asnego, cho\u0107 prostego, systemu plik\u00f3w, kt\u00f3ry by\u0142by w stanie automatycznie i r\u00f3wnomiernie rozdziela\u0107 dane w postaci wirtualnych blok\u00f3w na n-liczbie w\u0119z\u0142\u00f3w klastra, kt\u00f3re by\u0142y po\u0142\u0105czone interkonektami przez Ethernet. Przy tym system plik\u00f3w powinien by\u0107 dobrze i \u0142atwo skalowalny oraz niezale\u017cny od system\u00f3w s\u0105siednich, tzn. wydzielony z vAIR w formie \u201epo prostu magazynu\u201d.<\/p>\n

<\/p>\n

\"Hiper-konwergentne<\/p>\n

<\/p>\n

Pierwsza koncepcja vAIR<\/p>\n

<\/p>\n

\"Hiper-konwergentne<\/p>\n

<\/p>\n

Zdecydowanie zrezygnowali\u015bmy z u\u017cywania gotowych rozwi\u0105za\u0144 open source do organizacji rozproszonego magazynu (ceph, gluster, lustre i podobne) na rzecz w\u0142asnego rozwi\u0105zania, poniewa\u017c mieli\u015bmy z nimi wiele do\u015bwiadczenia projektowego. Oczywi\u015bcie te rozwi\u0105zania same w sobie s\u0105 doskona\u0142e i do pracy nad Aerodyskiem zrealizowali\u015bmy z nimi nie jeden projekt integracyjny. Jednak co innego \u2013 zrealizowa\u0107 konkretne zadanie jednego klienta, wyszkoli\u0107 personel i by\u0107 mo\u017ce wykupi\u0107 wsparcie du\u017cego dostawcy, a co innego \u2013 stworzy\u0107 \u0142atwo reprodukowalny produkt, kt\u00f3ry b\u0119dzie u\u017cywany do r\u00f3\u017cnych zada\u0144, o kt\u00f3rych my, jako dostawca, by\u0107 mo\u017ce nawet sami nie b\u0119dziemy wiedzie\u0107. Do drugiego celu istniej\u0105ce produkty open source nie pasowa\u0142y, dlatego postanowili\u015bmy samodzielnie rozwija\u0107 rozproszony system plik\u00f3w.
\nPo dw\u00f3ch latach prac kilku deweloper\u00f3w (kt\u00f3rzy \u0142\u0105czyli prac\u0119 nad vAIR z prac\u0105 nad klasycznym systemem macierzy Engine) osi\u0105gn\u0119li\u015bmy okre\u015blony wynik.<\/p>\n

<\/p>\n

Do 2018 roku napisali\u015bmy najprostszy system plik\u00f3w i uzupe\u0142nili\u015bmy go niezb\u0119dnym otoczeniem. System \u0142\u0105czy\u0142 fizyczne (lokalne) dyski z r\u00f3\u017cnych serwer\u00f3w w jeden p\u0142aski pul i \u201eucina\u0142\u201d je na wirtualne bloki, a nast\u0119pnie z tych wirtualnych blok\u00f3w tworzone by\u0142y urz\u0105dzenia blokowe o r\u00f3\u017cnym stopniu odporno\u015bci na awarie, na kt\u00f3rych za pomoc\u0105 hipernadzorcy KVM tworzone i uruchamiane by\u0142y maszyny wirtualne. <\/p>\n

<\/p>\n

Nie skupiali\u015bmy si\u0119 zbytnio na nazwie systemu plik\u00f3w, nazwa zosta\u0142a zwi\u0119\u017ale okre\u015blona jako ARDFS (zgadnijcie, co to znaczy))<\/p>\n

<\/p>\n

Ten prototyp wygl\u0105da\u0142 dobrze (nie wizualnie, oczywi\u015bcie, wizualizacja wtedy nie istnia\u0142a) i wykazywa\u0142 dobre wyniki pod wzgl\u0119dem wydajno\u015bci i skalowalno\u015bci. Po pierwszych realnych rezultatach przeszli\u015bmy do realizacji tego projektu, organizuj\u0105c ju\u017c pe\u0142noprawne \u015brodowisko deweloperskie oraz oddzielny zesp\u00f3\u0142, kt\u00f3ry zajmowa\u0142 si\u0119 wy\u0142\u0105cznie vAIR-em.<\/p>\n

<\/p>\n

W\u0142a\u015bnie wtedy dojrza\u0142a og\u00f3lna architektura rozwi\u0105zania, kt\u00f3ra do dzi\u015b nie uleg\u0142a powa\u017cnym zmianom.<\/p>\n

<\/p>\n

Zanurzamy si\u0119 w system plik\u00f3w ARDFS<\/h2>\n

<\/p>\n

ARDFS stanowi podstaw\u0119 vAIR, zapewniaj\u0105c rozproszone, odporne na awarie przechowywanie danych ca\u0142ego klastra. Jedn\u0105 z (ale nie jedyn\u0105) wyr\u00f3\u017cniaj\u0105cych cech ARDFS jest to, \u017ce nie wykorzystuje \u017cadnych dodatkowych dedykowanych serwer\u00f3w<\/a> podsystem\u00f3w i zarz\u0105dzania. Tak zaplanowano na pocz\u0105tku, aby upro\u015bci\u0107 konfiguracj\u0119 rozwi\u0105zania i zwi\u0119kszy\u0107 jego niezawodno\u015b\u0107. <\/p>\n

<\/p>\n

Struktura przechowywania<\/h3>\n

<\/p>\n

Wszystkie w\u0119z\u0142y klastra ARDFS organizuj\u0105 logiczny pul z ca\u0142ej dost\u0119pnej przestrzeni dyskowej. Wa\u017cne jest zrozumienie, \u017ce pul to jeszcze nie dane i nie sformatowana przestrze\u0144, a jedynie mapowanie, tzn. jakiekolwiek w\u0119z\u0142y z zainstalowanym vAIR-em, po dodaniu do klastra, automatycznie do\u0142\u0105czaj\u0105 do wsp\u00f3lnego pulu ARDFS, a zasoby dyskowe staj\u0105 si\u0119 automatycznie wsp\u00f3lne na ca\u0142y klaster (i dost\u0119pne do przysz\u0142ego przechowywania danych). Takie podej\u015bcie pozwala na dodawanie i usuwanie w\u0119z\u0142\u00f3w w locie bez jakiegokolwiek powa\u017cnego wp\u0142ywu na ju\u017c dzia\u0142aj\u0105cy system. Tzn. system jest bardzo \u0142atwy do skalowania \u201eceg\u0142ami\u201d, dodaj\u0105c lub usuwaj\u0105c w\u0119z\u0142y w klastrze w razie potrzeby.<\/p>\n

<\/p>\n

Na pul ARDFS dodawane s\u0105 wirtualne dyski (obiekty przechowywania dla maszyn wirtualnych), kt\u00f3re budowane s\u0105 z wirtualnych blok\u00f3w o wielko\u015bci 4 megabajty. Na wirtualnych dyskach bezpo\u015brednio przechowywane s\u0105 dane. Na poziomie wirtualnych dysk\u00f3w okre\u015bla si\u0119 r\u00f3wnie\u017c schemat odporno\u015bci na awarie. <\/p>\n

<\/p>\n

Jak mo\u017cna si\u0119 by\u0142o domy\u015bli\u0107, w celu zapewnienia odporno\u015bci na awarie w systemie dyskowym nie u\u017cywamy koncepcji RAID (Redundant Array of Independent Disks), lecz RAIN (Redundant Array of Independent Nodes). Oznacza to, \u017ce odporno\u015b\u0107 na awarie jest mierzona, automatyzowana i zarz\u0105dzana na podstawie w\u0119z\u0142\u00f3w, a nie dysk\u00f3w. Dyski, oczywi\u015bcie, r\u00f3wnie\u017c s\u0105 obiektami przechowywania, s\u0105 monitorowane jak wszystko inne, mo\u017cna na nich wykonywa\u0107 wszystkie standardowe operacje, w tym tworzy\u0107 lokalny sprz\u0119towy RAID, ale klaster operuje na w\u0119z\u0142ach. <\/p>\n

<\/p>\n

W sytuacji, gdy bardzo zale\u017cy nam na RAID (na przyk\u0142ad w scenariuszu obs\u0142uguj\u0105cym wiele awarii na ma\u0142ych klastrach), nic nie stoi na przeszkodzie, aby u\u017cywa\u0107 lokalnych kontroler\u00f3w RAID, a na to budowa\u0107 rozproszone przechowywanie i architektur\u0119 RAIN. Taki scenariusz jest jak najbardziej realny i wspierany przez nas, dlatego opowiemy o nim w artykule na temat typowych scenariuszy zastosowania vAIR.<\/p>\n

<\/p>\n

Schematy odporno\u015bci na awarie przechowywania<\/h3>\n

<\/p>\n

Schemat\u00f3w odporno\u015bci na awarie wirtualnych dysk\u00f3w w vAIR mo\u017ce by\u0107 dwa:<\/p>\n

<\/p>\n

1) Wsp\u00f3\u0142czynnik replikacji lub po prostu replikacja \u2013 ta metoda odporno\u015bci na awarie jest prosta \u201ejak kij i sznur\u201d. Wykonywana jest synchroniczna replikacja mi\u0119dzy w\u0119z\u0142ami z czynnikiem 2 (2 kopie w klastrze) lub 3 (3 kopie, odpowiednio). RF-2 pozwala wirtualnemu dyskowi wytrzyma\u0107 awari\u0119 jednego w\u0119z\u0142a w klastrze, ale \u201ezjada\u201d po\u0142ow\u0119 u\u017cytecznej pojemno\u015bci, a RF-3 wytrzyma awari\u0119 2 w\u0119z\u0142\u00f3w w klastrze, ale zarezerwuje ju\u017c 2\/3 u\u017cytecznej pojemno\u015bci na swoje potrzeby. Ten schemat przypomina RAID-1, to znaczy wirtualny dysk skonfigurowany w RF-2 jest odporny na awari\u0119 dowolnego jednego w\u0119z\u0142a klastra. W takim przypadku dane b\u0119d\u0105 w porz\u0105dku i nawet operacje wej\u015bcia\/wyj\u015bcia si\u0119 nie zatrzymaj\u0105. Kiedy uszkodzony w\u0119ze\u0142 wr\u00f3ci do dzia\u0142ania, zacznie si\u0119 automatyczna odbudowa\/synchronizacja danych. <\/p>\n

<\/p>\n

Poni\u017cej znajduj\u0105 si\u0119 przyk\u0142ady rozk\u0142adu danych RF-2 i RF-3 w normalnym trybie oraz w sytuacji awarii.<\/p>\n

<\/p>\n

Posiadamy maszyn\u0119 wirtualn\u0105 o obj\u0119to\u015bci 8 MB unikalnych (przydatnych) danych, kt\u00f3ra dzia\u0142a na 4 w\u0119z\u0142ach vAIR. Oczywi\u015bcie w rzeczywisto\u015bci taki ma\u0142y wolumen b\u0119dzie rzadko\u015bci\u0105, ale w przypadku schematu ilustruj\u0105cego logik\u0119 dzia\u0142ania ARDFS, ten przyk\u0142ad jest najbardziej zrozumia\u0142y. AB to wirtualne bloki po 4 MB, zawieraj\u0105ce unikalne dane maszyny wirtualnej. Przy RF-2 tworzone s\u0105 dwie kopie tych blok\u00f3w A1+A2 oraz B1+B2 odpowiednio. Bloki te s\u0105 \u201erozk\u0142adane\u201d po w\u0119z\u0142ach, unikaj\u0105c powielania tych samych danych na jednym w\u0119\u017ale, co oznacza, \u017ce kopia A1 nie b\u0119dzie znajdowa\u0107 si\u0119 na tym samym w\u0119\u017ale co kopia A2. B1 i B2 s\u0105 podobnie traktowane.<\/p>\n

<\/p>\n

\"Hiper-konwergentne<\/p>\n

<\/p>\n

W przypadku awarii jednego z w\u0119z\u0142\u00f3w (na przyk\u0142ad w\u0119z\u0142a nr 3, na kt\u00f3rym znajduje si\u0119 kopia B1), ta kopia automatycznie aktywuje si\u0119 na w\u0119\u017ale, na kt\u00f3rym nie ma kopii jej kopii (czyli kopii B2). <\/p>\n

<\/p>\n

\"Hiper-konwergentne<\/p>\n

<\/p>\n

W ten spos\u00f3b wirtualny dysk (i VM odpowiednio) bez trudu prze\u017cyje awari\u0119 jednego w\u0119z\u0142a w schemacie RF-2.<\/p>\n

<\/p>\n

Schemat replikacji, mimo swojej prostoty i niezawodno\u015bci, ma t\u0119 sam\u0105 wad\u0119 co RAID1 \u2013 ma\u0142o przydatnej przestrzeni.<\/p>\n

<\/p>\n

2) Kodowanie usuwaj\u0105ce (ang. Erasure coding), znane r\u00f3wnie\u017c jako \u201ekodowanie nadmiarowe\u201d lub \u201ekodowanie zerowania\u201d, zosta\u0142o stworzone, aby rozwi\u0105za\u0107 powy\u017cszy problem. EC to schemat nadmiarowo\u015bci, kt\u00f3ry zapewnia wysok\u0105 dost\u0119pno\u015b\u0107 danych przy mniejszych kosztach przestrzeni dyskowej w por\u00f3wnaniu do replikacji. Zasada dzia\u0142ania tego mechanizmu jest podobna do RAID 5, 6, 6P. <\/p>\n

<\/p>\n

Podczas kodowania proces EC dzieli wirtualny blok (domy\u015blnie 4 MB) na kilka mniejszych \u201ekawa\u0142k\u00f3w danych\u201d w zale\u017cno\u015bci od schematu EC (na przyk\u0142ad schemat 2+1 dzieli ka\u017cdy blok 4 MB na 2 kawa\u0142ki po 2 MB). Nast\u0119pnie proces generuje dla \u201ekawa\u0142k\u00f3w danych\u201d \u201ekawa\u0142ki parzysto\u015bci\u201d o wielko\u015bci nie wi\u0119kszej ni\u017c jedna z wcze\u015bniej podzielonych cz\u0119\u015bci. Podczas dekodowania EC generuje brakuj\u0105ce kawa\u0142ki, odczytuj\u0105c \u201eprzetrwa\u0142e\u201d dane w ca\u0142ym klastrze. <\/p>\n

<\/p>\n

Na przyk\u0142ad wirtualny dysk z schematem EC 2 + 1, realizowany na 4 w\u0119z\u0142ach klastra, bez trudu wytrzyma awari\u0119 jednego w\u0119z\u0142a w klastrze, tak jak RF-2. Przy tym koszty og\u00f3lne b\u0119d\u0105 ni\u017csze, wsp\u00f3\u0142czynnik efektywnej pojemno\u015bci przy RF-2 wynosi 2, a przy EC 2+1 wyniesie 1,5. <\/p>\n

<\/p>\n

M\u00f3wi\u0105c pro\u015bciej, istota polega na tym, \u017ce wirtualny blok jest dzielony na 2-8 (dlaczego od 2 do 8, patrz poni\u017cej) \u201ekawa\u0142k\u00f3w\u201d, a dla tych kawa\u0142k\u00f3w obliczane s\u0105 \u201ekawa\u0142ki\u201d parzysto\u015bci o podobnej wielko\u015bci. <\/p>\n

<\/p>\n

W rezultacie dane i parzysto\u015b\u0107 s\u0105 r\u00f3wnomiernie roz\u0142o\u017cone na wszystkich w\u0119z\u0142ach klastra. Jak przy replikacji, ARDFS automatycznie rozprowadza dane po w\u0119z\u0142ach w taki spos\u00f3b, aby uniemo\u017cliwi\u0107 przechowywanie identycznych danych (kopii danych i ich parzysto\u015bci) na jednym w\u0119\u017ale, by wykluczy\u0107 ryzyko utraty danych w przypadku awarii w\u0119z\u0142a, kt\u00f3ry przechowuje zar\u00f3wno dane, jak i ich parzysto\u015b\u0107. <\/p>\n

<\/p>\n

Poni\u017cej przyk\u0142ad z t\u0105 sam\u0105 wirtualn\u0105 maszyn\u0105 o pojemno\u015bci 8 MB i 4 w\u0119z\u0142ami, tym razem w schemacie EC 2+1. <\/p>\n

<\/p>\n

\u0411\u043b\u043e\u043a\u0438 A \u0438 B \u0434\u0435\u043b\u044f\u0442\u0441\u044f \u043d\u0430 \u0434\u0432\u0430 \u043a\u0443\u0441\u043a\u0430 \u043a\u0430\u0436\u0434\u044b\u0439 \u043f\u043e 2 \u041c\u0411 (\u043d\u0430 \u0434\u0432\u0430 \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e 2+1), \u0442\u043e \u0435\u0441\u0442\u044c \u043d\u0430 A1+A2 \u0438 B1+B2. \u0412 \u043e\u0442\u043b\u0438\u0447\u0438\u0435 \u043e\u0442 \u0440\u0435\u043f\u043b\u0438\u043a\u0438, A1 \u043d\u0435 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043a\u043e\u043f\u0438\u0435\u0439 A2, \u044d\u0442\u043e \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0439 \u0431\u043b\u043e\u043a A, \u0440\u0430\u0437\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0439 \u043d\u0430 \u0434\u0432\u0435 \u0447\u0430\u0441\u0442\u0438, \u0442\u0430\u043a \u0436\u0435 \u0438 \u0441 \u0431\u043b\u043e\u043a\u043e\u043c B. \u0418\u0442\u043e\u0433\u043e \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u043c \u0434\u0432\u0430 \u043d\u0430\u0431\u043e\u0440\u0430 \u043f\u043e 4\u041c\u0411, \u0432 \u043a\u0430\u0436\u0434\u043e\u043c \u0438\u0437 \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u043b\u0435\u0436\u0438\u0442 \u043f\u043e \u0434\u0432\u0430 \u0434\u0432\u0443\u0445\u043c\u0435\u0433\u0430\u0431\u0430\u0439\u0442\u043d\u044b\u0445 \u043a\u0443\u0441\u043a\u0430. \u0414\u0430\u043b\u0435\u0435, \u0434\u043b\u044f \u043a\u0430\u0436\u0434\u043e\u0433\u043e \u0438\u0437 \u044d\u0442\u0438\u0445 \u043d\u0430\u0431\u043e\u0440\u043e\u0432 \u0432\u044b\u0447\u0438\u0441\u043b\u044f\u0435\u0442\u0441\u044f \u0447\u0451\u0442\u043d\u043e\u0441\u0442\u044c \u043e\u0431\u044a\u0435\u043c\u043e\u043c \u043d\u0435 \u0431\u043e\u043b\u0435\u0435 \u043e\u0434\u043d\u043e\u0433\u043e \u043a\u0443\u0441\u043a\u0430 (\u0442.\u0435. 2-\u0445 \u041c\u0411), \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u043c \u0434\u043e\u043f\u043e\u043b\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u043e + 2 \u043a\u0443\u0441\u043a\u0430 \u0447\u0451\u0442\u043d\u043e\u0441\u0442\u0438 (A-P \u0438 B-P). \u0418\u0442\u043e\u0433\u043e \u0438\u043c\u0435\u0435\u043c 4×2 \u0434\u0430\u043d\u043d\u044b\u0445 + 2×2 \u0447\u0435\u0442\u043d\u043e\u0441\u0442\u044c.<\/p>\n

<\/p>\n

Nast\u0119pnie kawa\u0142ki s\u0105 \"uk\u0142adane\" po w\u0119z\u0142ach tak, aby dane nie pokrywa\u0142y si\u0119 z ich parzysto\u015bci\u0105. Tzn. A1 i A2 nie b\u0119d\u0105 le\u017ca\u0142y na tym samym w\u0119\u017ale co A-P.<\/p>\n

<\/p>\n

\"Hiper-konwergentne<\/p>\n

<\/p>\n

W przypadku awarii jednego w\u0119z\u0142a (na przyk\u0142ad trzeciego) upad\u0142y blok B1 zostanie automatycznie przywr\u00f3cony z parzysto\u015bci B-P, kt\u00f3ra jest przechowywana na w\u0119\u017ale nr 2, i zostanie aktywowany na w\u0119\u017ale, gdzie nie ma parzysto\u015bci B, tzn. kawa\u0142ka B-P. W tym przyk\u0142adzie jest to w\u0119ze\u0142 nr 1.<\/p>\n

<\/p>\n

\"Hiper-konwergentne<\/p>\n

<\/p>\n

Jestem pewien, \u017ce czytelnik zadaje sobie pytanie:<\/p>\n

<\/p>\n

\u201eWszystko, co opisali\u015bcie, zosta\u0142o ju\u017c dawno wdro\u017cone przez konkurencj\u0119 i w rozwi\u0105zaniach open source, jaka jest r\u00f3\u017cnica waszej realizacji EC w ARDFS?\u201d<\/p><\/blockquote>\n

A potem przedstawimy ciekawe cechy dzia\u0142ania ARDFS.<\/p>\n

<\/p>\n

Kodowanie usuni\u0119\u0107 z naciskiem na elastyczno\u015b\u0107<\/h3>\n

<\/p>\n

Pocz\u0105tkowo przewidzieli\u015bmy do\u015b\u0107 elastyczny schemat EC X+Y, gdzie X wynosi od 2 do 8, a Y od 1 do 8, zawsze mniejsze lub r\u00f3wne X. Taki schemat jest zaprojektowany dla elastyczno\u015bci. Zwi\u0119kszenie liczby kawa\u0142k\u00f3w danych (X), na kt\u00f3re dzieli si\u0119 wirtualny blok, pozwala na zmniejszenie koszt\u00f3w og\u00f3lnych, a tym samym zwi\u0119kszenie pojemno\u015bci u\u017cytkowej.
\nZwi\u0119kszenie liczby kawa\u0142k\u00f3w parzysto\u015bci (Y) zwi\u0119ksza niezawodno\u015b\u0107 wirtualnego dysku. Im wi\u0119ksza warto\u015b\u0107 Y, tym wi\u0119cej w\u0119z\u0142\u00f3w w klastrze mo\u017ce ulec awarii. Oczywi\u015bcie, zwi\u0119kszenie obj\u0119to\u015bci parzysto\u015bci zmniejsza pojemno\u015b\u0107 u\u017cytkow\u0105, ale to cena za niezawodno\u015b\u0107. <\/p>\n

<\/p>\n

Zale\u017cno\u015b\u0107 wydajno\u015bci od schemat\u00f3w EC jest niemal liniowa: im wi\u0119cej \u201efragment\u00f3w\u201d, tym ni\u017csza wydajno\u015b\u0107. W tym przypadku potrzebne jest zr\u00f3wnowa\u017cone podej\u015bcie. <\/p>\n

<\/p>\n

Takie podej\u015bcie pozwala administratorom na maksymalnie elastyczn\u0105 konfiguracj\u0119 rozci\u0105gni\u0119tej pami\u0119ci. W obr\u0119bie puli ARDFS mo\u017cna stosowa\u0107 dowolne schematy odporno\u015bci na b\u0142\u0119dy i ich kombinacje, co naszym zdaniem jest bardzo u\u017cyteczne. <\/p>\n

<\/p>\n

Poni\u017cej znajduje si\u0119 tabela por\u00f3wnawcza kilku (nie wszystkich mo\u017cliwych) schemat\u00f3w RF i EC.<\/p>\n

<\/p>\n

\"Hiper-konwergentne<\/p>\n

<\/p>\n

Z tabeli wynika, \u017ce nawet najbardziej \u201ezaawansowana\u201d kombinacja EC 8+7, pozwalaj\u0105ca na utrat\u0119 jednocze\u015bnie do 7 w\u0119z\u0142\u00f3w w klastrze, \u201ezu\u017cywa\u201d mniej u\u017cytecznej przestrzeni (1,875 w por\u00f3wnaniu do 2), ni\u017c standardowa replikacja, jednocze\u015bnie chroni\u0105c 7 razy lepiej, co sprawia, \u017ce ten mechanizm ochrony, cho\u0107 bardziej z\u0142o\u017cony, jest znacznie bardziej atrakcyjny w sytuacjach, gdy konieczne jest zapewnienie maksymalnej niezawodno\u015bci przy braku miejsca na dysku. Nale\u017cy jednak pami\u0119ta\u0107, \u017ce ka\u017cdy \u201eplus\u201d do X lub Y b\u0119dzie generowa\u0142 dodatkowe obci\u0105\u017cenie wydajno\u015bci, dlatego w tr\u00f3jk\u0105cie mi\u0119dzy niezawodno\u015bci\u0105, oszcz\u0119dno\u015bci\u0105 a wydajno\u015bci\u0105 nale\u017cy dokonywa\u0107 bardzo ostro\u017cnych wybor\u00f3w. Z tego powodu po\u015bwi\u0119cimy oddzielny artyku\u0142 do rozmiarowania usuwaj\u0105cego kodowania.<\/p>\n

<\/p>\n

\"Hiper-konwergentne<\/p>\n

<\/p>\n

Niezawodno\u015b\u0107 i autonomiczno\u015b\u0107 systemu plik\u00f3w<\/h3>\n

<\/p>\n

ARDFS uruchamia si\u0119 lokalnie na wszystkich w\u0119z\u0142ach klastra i synchronizuje je za pomoc\u0105 dedykowanych interfejs\u00f3w Ethernet. Wa\u017cnym punktem jest to, \u017ce ARDFS samodzielnie synchronizuje nie tylko dane, ale tak\u017ce metadane zwi\u0105zane z przechowywaniem. Podczas pracy nad ARDFS r\u00f3wnolegle badali\u015bmy szereg istniej\u0105cych rozwi\u0105za\u0144 i odkryli\u015bmy, \u017ce wiele z nich synchronizuje metadane systemu plik\u00f3w za pomoc\u0105 zewn\u0119trznej rozproszonej bazy danych, kt\u00f3r\u0105 r\u00f3wnie\u017c wykorzystujemy do synchronizacji, ale tylko konfiguracji, a nie metadanych FS (o tym oraz innych pokrewnych podsystemach w nast\u0119pnym artykule). <\/p>\n

<\/p>\n

Synchronizacja metadanych systemu plik\u00f3w z u\u017cyciem zewn\u0119trznej bazy danych to rozwi\u0105zanie, kt\u00f3re z pewno\u015bci\u0105 dzia\u0142a, ale w\u00f3wczas sp\u00f3jno\u015b\u0107 danych przechowywanych na ARDFS zale\u017ca\u0142aby od zewn\u0119trznej bazy danych i jej zachowa\u0144 (a ta, m\u00f3wi\u0105c szczerze, bywa kapry\u015bna), co wed\u0142ug nas jest z\u0142ym pomys\u0142em. Dlaczego? Je\u015bli metadane systemu plik\u00f3w ulegn\u0105 uszkodzeniu, to tak\u017ce same dane systemu plik\u00f3w b\u0119d\u0105 mog\u0142y by\u0107 uznane za stracone, dlatego zdecydowali\u015bmy si\u0119 na bardziej skomplikowan\u0105, ale niezawodn\u0105 drog\u0119. <\/p>\n

<\/p>\n

Podsystem synchronizacji metadanych dla ARDFS stworzyli\u015bmy sami, a funkcjonuje on ca\u0142kowicie niezale\u017cnie od innych podsystem\u00f3w. Innymi s\u0142owy, \u017caden inny podsystem nie mo\u017ce uszkodzi\u0107 danych ARDFS. Uwa\u017camy, \u017ce to najbardziej niezawodna i poprawna droga, a jak jest naprawd\u0119, czas poka\u017ce. Ponadto taki spos\u00f3b dzia\u0142ania ma dodatkow\u0105 zalet\u0119. ARDFS mo\u017cna u\u017cywa\u0107 niezale\u017cnie od vAIR, po prostu jako rozszerzonej pami\u0119ci, co z pewno\u015bci\u0105 wykorzystamy w naszych przysz\u0142ych produktach.<\/p>\n

<\/p>\n

Ostatecznie, opracowuj\u0105c ARDFS, uzyskali\u015bmy elastyczny i niezawodny system plik\u00f3w, daj\u0105cy wyb\u00f3r mi\u0119dzy oszcz\u0119dno\u015bciami na pojemno\u015bci a pe\u0142n\u0105 wydajno\u015bci\u0105 lub stworzeniem niezwykle niezawodnego magazynu za rozs\u0105dne pieni\u0105dze, ale przy ni\u017cszych wymaganiach dotycz\u0105cych wydajno\u015bci. <\/p>\n

<\/p>\n

Razem z prost\u0105 polityk\u0105 licencjonowania i elastycznym modelem dostarczania (dla jasno\u015bci, licencjonowanie vAIR odbywa si\u0119 na w\u0119z\u0142ach, a dostarczanie mo\u017ce by\u0107 realizowane jako oprogramowanie lub paczka) umo\u017cliwia to bardzo precyzyjne dopasowanie rozwi\u0105zania do r\u00f3\u017cnych wymaga\u0144 klient\u00f3w oraz p\u00f3\u017aniejsze \u0142atwe utrzymanie tego balansu. <\/p>\n

<\/p>\n

Kto potrzebuje tego cudu?<\/h2>\n

<\/p>\n

Z jednej strony mo\u017cna powiedzie\u0107, \u017ce na rynku s\u0105 ju\u017c gracze z powa\u017cnymi rozwi\u0105zaniami w dziedzinie hiper\u0142\u0105czno\u015bci i pytanie, dlaczego my si\u0119 tam pchamy. Wydaje si\u0119, \u017ce to twierdzenie jest prawdziwe, ALE\u2026<\/p>\n

<\/p>\n

Z drugiej strony, gdy wychodzimy \"w teren\" i rozmawiamy z klientami, my i nasi partnerzy widzimy, \u017ce wcale tak nie jest. Jest wiele zada\u0144 dla hiper\u0142\u0105czno\u015bci, gdzie ludzie po prostu nie wiedzieli, \u017ce takie rozwi\u0105zania istniej\u0105, w niekt\u00f3rych miejscach wydawa\u0142o si\u0119 to drogie, w innych by\u0142y nieudane testy alternatywnych rozwi\u0105za\u0144, a gdzie indziej zakup jest wr\u0119cz zabroniony z powodu sankcji. Og\u00f3lnie rzecz bior\u0105c, pole okaza\u0142o si\u0119 niezaorane, dlatego postanowili\u015bmy zacz\u0105\u0107 go uprawia\u0107))). <\/p>\n

<\/p>\n

Kiedy SAN jest lepszy ni\u017c HCI?<\/h3>\n

<\/p>\n

W trakcie pracy z rynkiem cz\u0119sto pytaj\u0105 nas, kiedy najlepiej zastosowa\u0107 klasyczny schemat z macierz\u0105 dyskow\u0105, a kiedy \u2013 hiper\u0142\u0105czno\u015b\u0107? Wiele firm \u2013 producent\u00f3w HCI (szczeg\u00f3lnie tych, kt\u00f3re nie maj\u0105 w swoim portfolio macierzy) m\u00f3wi: \u201eMacierz dyskowa odchodzi w zapomnienie, hiper\u0142\u0105cze tylko!\u201d. To odwa\u017cne stwierdzenie, ale nie ca\u0142kowicie odzwierciedla rzeczywisto\u015b\u0107. <\/p>\n

<\/p>\n

Prawd\u0119 m\u00f3wi\u0105c, rynek macierzy dyskowych rzeczywi\u015bcie przesuwa si\u0119 w stron\u0119 hiper\u0142\u0105cznych rozwi\u0105za\u0144, ale zawsze jest \u201eale\u201d.<\/p>\n

<\/p>\n

Po pierwsze, zbudowane centra danych i infrastruktury IT w klasycznym schemacie z macierz\u0105 dyskow\u0105 nie tak \u0142atwo przebudowa\u0107, wi\u0119c modernizacja i rozbudowa takich infrastruktury to jeszcze spadek na 5-7 lat.<\/p>\n

<\/p>\n

Po drugie, te infrastruktury, kt\u00f3re obecnie powstaj\u0105 w wi\u0119kszo\u015bci (mowa o Rosji) budowane s\u0105 w klasycznym schemacie z u\u017cyciem macierzy dyskowej, nie dlatego, \u017ce ludzie nie wiedz\u0105 o hiper\u0142\u0105czu, ale dlatego, \u017ce rynek hiper\u0142\u0105czno\u015bci jest nowy, rozwi\u0105zania i standardy jeszcze nie ustabilizowane, specjali\u015bci IT nie s\u0105 jeszcze przeszkoleni, do\u015bwiadczenie jest ma\u0142e, a budowa\u0107 centra danych trzeba tu i teraz. I ta tendencja jeszcze potrwa 3-5 lat (a potem jeszcze spadek, patrz punkt 1).<\/p>\n

<\/p>\n

Po trzecie, czysto techniczne ograniczenie w dodatkowych op\u00f3\u017anieniach wynosz\u0105cych 2 milisekundy na zapis (nie wliczaj\u0105c lokalnej pami\u0119ci podr\u0119cznej, oczywi\u015bcie), kt\u00f3re s\u0105 cen\u0105 za rozproszone przechowywanie. <\/p>\n

<\/p>\n

Nie zapominajmy r\u00f3wnie\u017c o wykorzystaniu du\u017cych fizycznych serwer\u00f3w, kt\u00f3re preferuj\u0105 wertykalne skalowanie systemu dyskowego.<\/p>\n

<\/p>\n

Istnieje wiele potrzebnych i popularnych zada\u0144, w kt\u00f3rych macierz dyskowa sprawuje si\u0119 lepiej ni\u017c HCI. Oczywi\u015bcie producenci, kt\u00f3rzy nie maj\u0105 macierzy w swoim portfolio, nie zgodz\u0105 si\u0119 z nami, ale jeste\u015bmy gotowi na rzeczow\u0105 dyskusj\u0119. Naturalnie, jako tw\u00f3rcy obu produkt\u00f3w, w jednym z przysz\u0142ych publikacji por\u00f3wnamy macierz dyskow\u0105 i HCI, gdzie wyra\u017anie poka\u017cemy, w jakich warunkach lepiej si\u0119 sprawdzaj\u0105.<\/p>\n

<\/p>\n

A gdzie rozwi\u0105zania hiper\u0142\u0105czne b\u0119d\u0105 dzia\u0142a\u0142y lepiej ni\u017c macierz dyskowa?<\/h3>\n

<\/p>\n

Na podstawie powy\u017cszych tez mo\u017cna wyci\u0105gn\u0105\u0107 trzy oczywiste wnioski: <\/p>\n

<\/p>\n

    \n
  1. Tam, gdzie dodatkowe 2 milisekundy op\u00f3\u017anienia na zapis, kt\u00f3re stabilnie wyst\u0119puj\u0105 w ka\u017cdej produkcji (teraz nie m\u00f3wimy o syntetyce, w syntetyce mo\u017cna pokaza\u0107 nawet nanosekundy), s\u0105 niekrytyczne, hiper\u0142\u0105cze b\u0119dzie odpowiednie.<\/li>\n
  2. Tam, gdzie obci\u0105\u017cenie z du\u017cych fizycznych serwer\u00f3w mo\u017cna przekszta\u0142ci\u0107 w wiele ma\u0142ych wirtualnych i rozdzieli\u0107 po nodach, tam r\u00f3wnie\u017c hiperkonwergencja dobrze si\u0119 sprawdzi.<\/li>\n
  3. Tam, gdzie skalowanie poziome jest bardziej priorytetowe ni\u017c poziome, tam r\u00f3wnie\u017c GKS sprawdz\u0105 si\u0119 \u015bwietnie.<\/li>\n<\/ol>\n

    <\/p>\n

    Jakie to rozwi\u0105zania?<\/h3>\n

    <\/p>\n

      \n
    1. Wszystkie standardowe us\u0142ugi infrastrukturalne (us\u0142uga katalogowa, poczta, SED, serwery plik\u00f3w, ma\u0142e lub \u015brednie systemy ERP i BI itd.). Nazywamy to \"wsp\u00f3lnym przetwarzaniem\". <\/li>\n
    2. Infrastruktura dostawc\u00f3w chmurowych, gdzie konieczne jest szybkie i znormalizowane rozszerzanie poziome oraz \u0142atwe \"ci\u0119cie\" du\u017cej liczby maszyn wirtualnych dla klient\u00f3w.<\/li>\n
    3. Infrastruktura wirtualnych pulpit\u00f3w<\/a> (VDI), gdzie uruchamiane s\u0105 ma\u0142e wirtualne maszyny u\u017cytkownik\u00f3w, kt\u00f3re swobodnie \"dryfuj\u0105\" w jednolitym klastrze.<\/li>\n
    4. Sieci filia, gdzie w ka\u017cdej filii potrzebna jest standardowa, odporna na awarie, ale jednocze\u015bnie niedroga infrastruktura z 15-20 maszyn wirtualnych.<\/li>\n
    5. Jakiekolwiek rozproszone obliczenia (us\u0142ugi big data, na przyk\u0142ad). Tam, gdzie obci\u0105\u017cenie idzie nie \"w g\u0142\u0105b\", a \"w szerz\". <\/li>\n
    6. \u015arodowiska testowe, gdzie dopuszczalne s\u0105 dodatkowe ma\u0142e op\u00f3\u017anienia, ale s\u0105 ograniczenia bud\u017cetowe, poniewa\u017c to s\u0105 testy.<\/li>\n<\/ol>\n

      <\/p>\n

      Na chwil\u0119 obecn\u0105 w\u0142a\u015bnie w tych zadaniach stworzyli\u015bmy AERODISK vAIR i na nich dok\u0142adamy szczeg\u00f3ln\u0105 wag\u0119 (jak na razie z sukcesem). Mo\u017cliwe, \u017ce wkr\u00f3tce si\u0119 to zmieni, poniewa\u017c \u015bwiat nie stoi w miejscu.<\/p>\n

      <\/p>\n

      Wi\u0119c\u2026<\/h3>\n

      <\/p>\n

      Na tym ko\u0144czy si\u0119 pierwsza cz\u0119\u015b\u0107 du\u017cego cyklu artyku\u0142\u00f3w, w nast\u0119pnym artykule opowiemy o architekturze rozwi\u0105zania i u\u017cywanych komponentach.<\/p>\n

      <\/p>\n

      B\u0119dziemy wdzi\u0119czni za pytania, propozycje i konstruktywne spory.<\/p>\n

      \u0179r\u00f3d\u0142o: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

      \u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0425\u0430\u0431\u0440\u0430. \u042d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u043c\u044b \u043e\u0442\u043a\u0440\u044b\u0432\u0430\u0435\u043c \u0446\u0438\u043a\u043b, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0431\u0443\u0434\u0435\u0442 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043e \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u043d\u043e\u0439 \u043d\u0430\u043c\u0438 \u0433\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 AERODISK vAIR. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043c\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u043f\u0435\u0440\u0432\u043e\u0439 \u0436\u0435 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u0432\u0441\u0451 \u043e\u0431\u043e \u0432\u0441\u0451\u043c, \u043d\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0441\u043b\u043e\u0436\u043d\u0430\u044f, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u0431\u0443\u0434\u0435\u043c \u0435\u0441\u0442\u044c \u0441\u043b\u043e\u043d\u0430 \u043f\u043e \u0447\u0430\u0441\u0442\u044f\u043c. \u041d\u0430\u0447\u043d\u0435\u043c \u0440\u0430\u0441\u0441\u043a\u0430\u0437 \u0441 \u0438\u0441\u0442\u043e\u0440\u0438\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u0443\u0433\u043b\u0443\u0431\u0438\u043c\u0441\u044f \u0432 \u0444\u0430\u0439\u043b\u043e\u0432\u0443\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u0443 ARDFS, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043e\u0439 vAIR, \u0430 \u0442\u0430\u043a\u0436\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28919,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38542","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Hiperkonwergentne rozwi\u0105zanie AERODISK vAIR. Podstawa \u2014 system plik\u00f3w ARDFS | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0413\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 AERODISK vAIR. \u041e\u0441\u043d\u043e\u0432\u0430 \u2014 \u0444\u0430\u0439\u043b\u043e\u0432\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 ARDFS | ProHoster","og:url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:24:25+00:00","article:modified_time":"2019-10-31T19:24:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38542","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 13:06:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:07:40","updated":"2026-02-09 13:06:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/38542","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=38542"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/38542\/revisions"}],"predecessor-version":[{"id":158207,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/38542\/revisions\/158207"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media\/28919"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=38542"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=38542"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=38542"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}