Hyperconverged na solusyon AERODISK vAIR. Ang batayan ay ang ARDFS file system

Kumusta, mga mambabasa ng Habr. Sa artikulong ito magbubukas kami ng isang serye na tatalakayin tungkol sa hyperconverged system na AERODISK vAIR na aming binuo. Sa una, gusto naming sabihin ang lahat tungkol sa lahat sa unang artikulo, ngunit ang sistema ay medyo kumplikado, kaya kakainin namin ang elepante sa mga bahagi.

Simulan natin ang kwento sa kasaysayan ng paglikha ng system, suriin ang ARDFS file system, na siyang batayan ng vAIR, at pag-usapan din ang kaunti tungkol sa pagpoposisyon ng solusyon na ito sa merkado ng Russia.

Sa hinaharap na mga artikulo ay tatalakayin natin nang mas detalyado ang tungkol sa iba't ibang bahagi ng arkitektura (cluster, hypervisor, load balancer, monitoring system, atbp.), ang proseso ng pagsasaayos, itaas ang mga isyu sa paglilisensya, hiwalay na nagpapakita ng mga pagsubok sa pag-crash at, siyempre, sumulat tungkol sa pagsubok ng pagkarga at pagpapalaki. Maglalaan din kami ng hiwalay na artikulo sa bersyon ng komunidad ng vAIR.

Ang Aerodisk ba ay isang kuwento tungkol sa mga sistema ng imbakan? O bakit nagsimula kaming gumawa ng hyperconvergence sa unang lugar?

Noong una, dumating sa amin ang ideyang gumawa ng sarili naming hyperconvergence noong 2010. Sa oras na iyon, walang Aerodisk o katulad na mga solusyon (komersyal na boxed hyperconverged system) sa merkado. Ang aming gawain ay ang mga sumusunod: mula sa isang hanay ng mga server na may mga lokal na disk, na pinagsama ng isang interconnect sa pamamagitan ng Ethernet protocol, kinakailangan upang lumikha ng isang pinahabang imbakan at maglunsad ng mga virtual machine at isang software network doon. Ang lahat ng ito ay kailangang ipatupad nang walang mga sistema ng imbakan (dahil walang pera para sa mga sistema ng imbakan at hardware nito, at hindi pa namin naimbento ang aming sariling mga sistema ng imbakan).

Sinubukan namin ang maraming open source na solusyon at sa wakas ay nalutas ang problemang ito, ngunit ang solusyon ay napakasalimuot at mahirap ulitin. Bukod dito, ang solusyon na ito ay nasa kategoryang "Gumagana ba ito? Huwag hawakan! Samakatuwid, nang malutas ang problemang iyon, hindi na namin binuo ang ideya ng pagbabago ng resulta ng aming trabaho sa isang ganap na produkto.

Pagkatapos ng insidenteng iyon, lumayo kami sa ideyang ito, ngunit mayroon pa rin kaming pakiramdam na ang problemang ito ay ganap na nalulusaw, at ang mga benepisyo ng naturang solusyon ay higit pa sa halata. Kasunod nito, kinumpirma lamang ng inilabas na mga produkto ng HCI ng mga dayuhang kumpanya ang pakiramdam na ito.

Samakatuwid, noong kalagitnaan ng 2016, bumalik kami sa gawaing ito bilang bahagi ng paglikha ng isang ganap na produkto. Noong panahong iyon, wala pa kaming anumang relasyon sa mga namumuhunan, kaya kailangan naming bumili ng development stand para sa sarili naming hindi masyadong malaking pera. Sa pagkakaroon ng pagkolekta ng mga ginamit na server at pag-switch sa Avito, bumaba kami sa negosyo.

Ang pangunahing paunang gawain ay ang lumikha ng sarili naming, kahit na simple, ngunit ang aming sariling file system, na maaaring awtomatiko at pantay na maipamahagi ang data sa anyo ng mga virtual na bloke sa ika-n na bilang ng mga cluster node, na konektado sa pamamagitan ng isang interconnect sa pamamagitan ng Ethernet. Kasabay nito, dapat na maayos at madali ang sukat ng FS at maging independyente sa mga katabing system, i.e. mapalayo sa vAIR sa anyo ng "isang pasilidad lamang ng imbakan".

Unang konsepto ng vAIR

Sinadya naming tinalikuran ang paggamit ng mga handa na open source na solusyon para sa pag-aayos ng naka-stretch na imbakan (ceph, gluster, luster at iba pa) pabor sa sarili naming pag-unlad, dahil marami na kaming karanasan sa proyekto sa kanila. Siyempre, ang mga solusyon mismo ay mahusay, at bago magtrabaho sa Aerodisk, nagpatupad kami ng higit sa isang proyekto ng pagsasama sa kanila. Ngunit isang bagay ang magpatupad ng isang partikular na gawain para sa isang customer, magsanay ng mga tauhan at, marahil, bumili ng suporta ng isang malaking vendor, at isa pang bagay upang lumikha ng isang madaling kopyahin na produkto na gagamitin para sa iba't ibang mga gawain, na kami, bilang isang vendor, maaaring kahit na malaman tungkol sa ating sarili hindi namin. Para sa pangalawang layunin, ang mga umiiral na open source na produkto ay hindi angkop para sa amin, kaya nagpasya kaming lumikha ng isang distributed file system sa aming sarili.
Pagkalipas ng dalawang taon, ilang developer (na pinagsama ang trabaho sa vAIR at trabaho sa classic na sistema ng imbakan ng Engine) ay nakamit ang isang tiyak na resulta.

Noong 2018, nagsulat kami ng isang simpleng file system at dinagdagan ito ng kinakailangang hardware. Pinagsama ng system ang mga pisikal (lokal) na disk mula sa iba't ibang mga server sa isang patag na pool sa pamamagitan ng isang panloob na interconnect at "pinutol" ang mga ito sa mga virtual na bloke, pagkatapos ay i-block ang mga device na may iba't ibang antas ng fault tolerance ay nilikha mula sa mga virtual na bloke, kung saan nilikha ang mga virtual. at isinagawa gamit ang KVM hypervisor cars.

Hindi kami masyadong nag-abala sa pangalan ng file system at mabilis na tinawag itong ARDFS (hulaan kung ano ang ibig sabihin nito))

Ang prototype na ito ay mukhang maganda (hindi biswal, siyempre, wala pang visual na disenyo) at nagpakita ng magagandang resulta sa mga tuntunin ng pagganap at pag-scale. Pagkatapos ng unang tunay na resulta, itinakda namin ang proyektong ito sa paggalaw, na nag-oorganisa ng ganap na kapaligiran sa pag-unlad at isang hiwalay na pangkat na tumutugon lamang sa vAIR.

Sa oras na iyon, ang pangkalahatang arkitektura ng solusyon ay tumanda na, na hindi pa sumasailalim sa malalaking pagbabago.

Sumisid sa ARDFS file system

Ang ARDFS ay ang pundasyon ng vAIR, na nagbibigay ng distributed, fault-tolerant na imbakan ng data sa buong cluster. Isa sa (ngunit hindi lamang) natatanging tampok ng ARDFS ay hindi ito gumagamit ng anumang karagdagang dedikadong server para sa metadata at pamamahala. Ito ay orihinal na ipinaglihi upang gawing simple ang pagsasaayos ng solusyon at para sa pagiging maaasahan nito.

Istraktura ng imbakan

Sa loob ng lahat ng node ng cluster, ang ARDFS ay nag-aayos ng isang lohikal na pool mula sa lahat ng magagamit na espasyo sa disk. Mahalagang maunawaan na ang isang pool ay hindi pa data o naka-format na espasyo, ngunit simpleng markup, i.e. Anumang mga node na may vAIR na naka-install, kapag idinagdag sa cluster, ay awtomatikong idinaragdag sa nakabahaging ARDFS pool at ang mga mapagkukunan ng disk ay awtomatikong maibabahagi sa buong cluster (at available para sa hinaharap na storage ng data). Binibigyang-daan ka ng diskarteng ito na magdagdag at mag-alis ng mga node nang mabilisan nang walang anumang seryosong epekto sa tumatakbo nang system. Yung. ang sistema ay napakadaling sukatin "sa mga brick", pagdaragdag o pag-alis ng mga node sa cluster kung kinakailangan.

Ang mga virtual disk (mga storage object para sa mga virtual machine) ay idinaragdag sa ibabaw ng ARDFS pool, na binuo mula sa mga virtual na bloke na 4 megabytes ang laki. Ang mga virtual na disk ay direktang nag-iimbak ng data. Ang fault tolerance scheme ay nakatakda din sa virtual disk level.

Tulad ng nahulaan mo na, para sa fault tolerance ng disk subsystem, hindi namin ginagamit ang konsepto ng RAID (Redundant array of independent Disks), ngunit gumagamit ng RAIN (Redundant array of independent Nodes). Yung. Sinusukat, awtomatiko, at pinamamahalaan ang fault tolerance batay sa mga node, hindi sa mga disk. Ang mga disk, siyempre, ay isang bagay din sa imbakan, sila, tulad ng lahat ng iba pa, ay sinusubaybayan, maaari mong isagawa ang lahat ng mga karaniwang operasyon sa kanila, kabilang ang pag-assemble ng isang lokal na hardware RAID, ngunit ang kumpol ay partikular na nagpapatakbo sa mga node.

Sa isang sitwasyon kung saan gusto mo talaga ang RAID (halimbawa, isang senaryo na sumusuporta sa maraming pagkabigo sa maliliit na cluster), walang pumipigil sa iyo na gumamit ng mga lokal na RAID controllers, at bumuo ng naka-stretch na storage at isang RAIN architecture sa itaas. Ang sitwasyong ito ay medyo live at sinusuportahan namin, kaya pag-uusapan natin ito sa isang artikulo tungkol sa mga tipikal na senaryo para sa paggamit ng vAIR.

Mga Scheme ng Pagpapahintulot sa Pag-iimbak ng Fault

Maaaring mayroong dalawang fault tolerance scheme para sa mga virtual na disk sa vAIR:

1) Replication factor o simpleng replikasyon - ang pamamaraang ito ng fault tolerance ay kasing simple ng isang stick at isang lubid. Isinasagawa ang sabay-sabay na pagtitiklop sa pagitan ng mga node na may factor na 2 (2 kopya bawat cluster) o 3 (3 kopya, ayon sa pagkakabanggit). Pinapayagan ng RF-2 ang isang virtual na disk na makatiis sa pagkabigo ng isang node sa cluster, ngunit "kumakain" sa kalahati ng kapaki-pakinabang na volume, at ang RF-3 ay makatiis sa pagkabigo ng 2 node sa cluster, ngunit inilalaan ang 2/3 ng kapaki-pakinabang na dami para sa mga pangangailangan nito. Ang scheme na ito ay halos kapareho sa RAID-1, iyon ay, ang isang virtual disk na na-configure sa RF-2 ay lumalaban sa kabiguan ng alinmang node sa cluster. Sa kasong ito, magiging maayos ang lahat sa data at kahit ang I/O ay hindi titigil. Kapag bumalik sa serbisyo ang nahulog na node, magsisimula ang awtomatikong pagbawi/pag-synchronize ng data.

Nasa ibaba ang mga halimbawa ng pamamahagi ng data ng RF-2 at RF-3 sa normal na mode at sa isang sitwasyon ng pagkabigo.

Mayroon kaming virtual machine na may kapasidad na 8MB ng natatanging (kapaki-pakinabang) na data, na tumatakbo sa 4 na vAIR node. Malinaw na sa katotohanan ay malamang na hindi magkakaroon ng ganoong kaunting dami, ngunit para sa isang pamamaraan na sumasalamin sa lohika ng operasyon ng ARDFS, ang halimbawang ito ay ang pinaka-naiintindihan. Ang AB ay 4MB na mga virtual na bloke na naglalaman ng natatanging data ng virtual machine. Lumilikha ang RF-2 ng dalawang kopya ng mga bloke na ito A1+A2 at B1+B2, ayon sa pagkakabanggit. Ang mga bloke na ito ay "inilatag" sa mga node, na iniiwasan ang intersection ng parehong data sa parehong node, iyon ay, ang kopya A1 ay hindi matatagpuan sa parehong node bilang kopya A2. Pareho sa B1 at B2.

Kung nabigo ang isa sa mga node (halimbawa, node No. 3, na naglalaman ng kopya ng B1), ang kopyang ito ay awtomatikong isinaaktibo sa node kung saan walang kopya ng kopya nito (iyon ay, isang kopya ng B2).

Kaya, ang virtual disk (at ang VM, nang naaayon) ay madaling makaligtas sa kabiguan ng isang node sa RF-2 scheme.

Ang pamamaraan ng pagtitiklop, habang simple at maaasahan, ay naghihirap mula sa parehong problema bilang RAID1 - hindi sapat na magagamit na espasyo.

2) Ang erasure coding o erasure coding (kilala rin bilang "redundant coding", "erasure coding" o "redundancy code") ay umiiral upang malutas ang problema sa itaas. Ang EC ay isang redundancy scheme na nagbibigay ng mataas na data availability na may mas mababang disk space overhead kumpara sa replication. Ang prinsipyo ng pagpapatakbo ng mekanismong ito ay katulad ng RAID 5, 6, 6P.

Kapag nag-encode, hinahati ng proseso ng EC ang isang virtual block (4MB bilang default) sa ilang mas maliliit na "data chunks" depende sa EC scheme (halimbawa, hinahati ng 2+1 scheme ang bawat 4MB block sa 2 2MB chunks). Susunod, ang prosesong ito ay bumubuo ng "parity chunks" para sa "data chunks" na hindi mas malaki kaysa sa isa sa mga naunang hinati na bahagi. Kapag nagde-decode, bubuo ng EC ang mga nawawalang chunks sa pamamagitan ng pagbabasa ng "surviving" na data sa buong cluster.

Halimbawa, ang isang virtual disk na may 2 + 1 EC scheme, na ipinatupad sa 4 na cluster node, ay madaling makatiis sa pagkabigo ng isang node sa cluster sa parehong paraan tulad ng RF-2. Sa kasong ito, ang mga gastos sa overhead ay magiging mas mababa, sa partikular, ang kapaki-pakinabang na koepisyent ng kapasidad para sa RF-2 ay 2, at para sa EC 2+1 ito ay magiging 1,5.

Upang ilarawan ito nang mas simple, ang kakanyahan ay ang virtual na bloke ay nahahati sa 2-8 (bakit mula 2 hanggang 8, tingnan sa ibaba) "mga piraso", at para sa mga piraso na ito "mga piraso" ng pagkakapareho ng isang katulad na dami ay kinakalkula.

Bilang resulta, ang data at parity ay pantay na ipinamamahagi sa lahat ng node ng cluster. Kasabay nito, tulad ng sa pagtitiklop, awtomatikong namamahagi ang ARDFS ng data sa mga node sa paraang maiwasang maimbak ang magkaparehong data (mga kopya ng data at pagkakapare-pareho ng mga ito) sa parehong node, upang maalis ang pagkakataong mawalan ng data dahil sa katotohanan na ang data at ang kanilang pagkakapareho ay biglang mapupunta sa isang storage node na nabigo.

Nasa ibaba ang isang halimbawa, na may parehong 8 MB virtual machine at 4 na node, ngunit may EC 2+1 scheme.

Ang mga bloke A at B ay nahahati sa dalawang piraso ng 2 MB bawat isa (dalawa dahil 2+1), iyon ay, A1+A2 at B1+B2. Hindi tulad ng isang replica, ang A1 ay hindi isang kopya ng A2, ito ay isang virtual na bloke A, nahahati sa dalawang bahagi, pareho sa bloke B. Sa kabuuan, nakakakuha kami ng dalawang set ng 4MB, na ang bawat isa ay naglalaman ng dalawang dalawang-MB na piraso. Susunod, para sa bawat isa sa mga set na ito, ang parity ay kinakalkula na may dami na hindi hihigit sa isang piraso (ibig sabihin, 2 MB), nakakakuha kami ng karagdagang + 2 piraso ng parity (AP at BP). Sa kabuuan mayroon kaming 4×2 data + 2×2 parity.

Susunod, ang mga piraso ay "inilatag" sa mga node upang ang data ay hindi magsalubong sa kanilang pagkakapareho. Yung. Ang A1 at A2 ay hindi nasa parehong node gaya ng AP.

Kung sakaling mabigo ang isang node (halimbawa, pati na rin ang pangatlo), ang nahulog na block B1 ay awtomatikong maibabalik mula sa parity ng BP, na nakaimbak sa node No. 2, at isaaktibo sa node kung saan mayroong walang B-parity, i.e. piraso ng BP. Sa halimbawang ito, ito ang node No. 1

Sigurado akong may tanong ang mambabasa:

"Lahat ng inilarawan mo ay matagal nang ipinatupad ng mga kakumpitensya at sa mga open source na solusyon, ano ang pagkakaiba sa pagitan ng iyong pagpapatupad ng EC sa ARDFS?"

At pagkatapos ay magkakaroon ng mga kagiliw-giliw na tampok ng ARDFS.

Burahin ang coding na may pagtuon sa flexibility

Sa una, nagbigay kami ng medyo nababaluktot na EC X+Y scheme, kung saan ang X ay katumbas ng isang numero mula 2 hanggang 8, at Y ay katumbas ng isang numero mula 1 hanggang 8, ngunit palaging mas mababa sa o katumbas ng X. Ang scheme na ito ay ibinigay para sa flexibility. Ang pagtaas ng bilang ng mga piraso ng data (X) kung saan nahahati ang virtual block ay nagbibigay-daan sa pagbawas ng mga gastos sa overhead, iyon ay, pagtaas ng magagamit na espasyo.
Ang pagtaas ng bilang ng mga parity chunks (Y) ay nagpapataas ng pagiging maaasahan ng virtual disk. Kung mas malaki ang halaga ng Y, mas maraming node sa cluster ang maaaring mabigo. Siyempre, ang pagtaas ng parity volume ay binabawasan ang dami ng magagamit na kapasidad, ngunit ito ay isang presyo na babayaran para sa pagiging maaasahan.

Ang pag-asa ng pagganap sa mga EC circuit ay halos direkta: mas maraming "piraso", mas mababa ang pagganap; dito, siyempre, kailangan ang isang balanseng pagtingin.

Ang diskarte na ito ay nagbibigay-daan sa mga administrator na i-configure ang naka-stretch na storage na may pinakamataas na flexibility. Sa loob ng pool ng ARDFS, maaari mong gamitin ang anumang mga scheme ng pagpapahintulot sa kasalanan at ang kanilang mga kumbinasyon, na, sa aming opinyon, ay lubhang kapaki-pakinabang din.

Nasa ibaba ang isang talahanayan na naghahambing ng ilang (hindi lahat ng posible) na mga scheme ng RF at EC.

Ipinapakita ng talahanayan na kahit na ang pinaka "terry" na kumbinasyon na EC 8+7, na nagbibigay-daan sa pagkawala ng hanggang 7 node sa isang cluster nang sabay-sabay, "kumakain" ng mas kaunting magagamit na espasyo (1,875 kumpara sa 2) kaysa sa karaniwang pagtitiklop, at pinoprotektahan ng 7 beses na mas mahusay. , na gumagawa ng mekanismong ito ng proteksyon, bagama't mas kumplikado, mas kaakit-akit sa mga sitwasyon kung saan kinakailangan upang matiyak ang maximum na pagiging maaasahan sa mga kondisyon ng limitadong espasyo sa disk. Kasabay nito, kailangan mong maunawaan na ang bawat "plus" sa X o Y ay magiging isang karagdagang overhead ng pagganap, kaya sa tatsulok sa pagitan ng pagiging maaasahan, pagtitipid at pagganap kailangan mong pumili nang maingat. Dahil dito, maglalaan kami ng hiwalay na artikulo para burahin ang coding sizing.

Pagiging maaasahan at awtonomiya ng file system

Lokal na tumatakbo ang ARDFS sa lahat ng mga node ng cluster at sini-synchronize ang mga ito gamit ang sarili nitong paraan sa pamamagitan ng mga nakalaang interface ng Ethernet. Ang mahalagang punto ay ang ARDFS ay nakapag-iisa na nagsi-synchronize hindi lamang sa data, kundi pati na rin sa metadata na nauugnay sa imbakan. Habang nagtatrabaho sa ARDFS, sabay-sabay naming pinag-aralan ang ilang mga umiiral nang solusyon at natuklasan namin na marami ang nagsi-synchronize ng file system meta gamit ang isang panlabas na distributed na DBMS, na ginagamit din namin para sa pag-synchronize, ngunit mga configuration lang, hindi FS metadata (tungkol dito at iba pang nauugnay na mga subsystem. sa susunod na artikulo).

Ang pag-synchronize ng metadata ng FS gamit ang isang panlabas na DBMS ay, siyempre, isang gumaganang solusyon, ngunit pagkatapos ay ang pagkakapare-pareho ng data na nakaimbak sa ARDFS ay depende sa panlabas na DBMS at sa pag-uugali nito (at, sa totoo lang, ito ay isang kapritsoso na babae), na sa masama ang opinyon natin. Bakit? Kung masira ang metadata ng FS, ang FS data mismo ay maaari ding sabihing "paalam," kaya nagpasya kaming kumuha ng mas kumplikado ngunit maaasahang landas.

Kami mismo ang gumawa ng metadata synchronization subsystem para sa ARDFS, at ganap itong nabubuhay nang hiwalay sa mga katabing subsystem. Yung. walang ibang subsystem ang makakasira sa data ng ARDFS. Sa aming opinyon, ito ang pinaka maaasahan at tamang paraan, ngunit sasabihin ng oras kung totoo nga ito. Bilang karagdagan, mayroong isang karagdagang kalamangan sa diskarteng ito. Maaaring gamitin ang ARDFS nang hiwalay sa vAIR, tulad ng naka-stretch na storage, na tiyak na gagamitin namin sa mga produkto sa hinaharap.

Bilang resulta, sa pamamagitan ng pagbuo ng ARDFS, nakatanggap kami ng flexible at maaasahang file system na nagbibigay ng pagpipilian kung saan makakatipid ka sa kapasidad o isuko ang lahat sa performance, o gumawa ng sobrang maaasahang storage sa isang makatwirang halaga, ngunit binabawasan ang mga kinakailangan sa pagganap.

Kasama ang isang simpleng patakaran sa paglilisensya at isang flexible na modelo ng paghahatid (sa hinaharap, ang vAIR ay lisensyado ng node, at inihahatid bilang software o bilang isang software package), nagbibigay-daan ito sa iyo na lubos na maiangkop ang solusyon sa isang malawak na iba't ibang mga kinakailangan ng customer at pagkatapos ay madaling mapanatili ang balanseng ito.

Sino ang nangangailangan ng himalang ito?

Sa isang banda, masasabi nating mayroon nang mga manlalaro sa merkado na may mga seryosong solusyon sa larangan ng hyperconvergence, at dito talaga tayo patungo. Mukhang totoo ang pahayag na ito, PERO...

Sa kabilang banda, kapag lumabas kami sa mga field at nakikipag-usap sa mga customer, nakikita namin at ng aming mga kasosyo na hindi ito ang lahat ng kaso. Mayroong maraming mga gawain para sa hyperconvergence, sa ilang mga lugar ay hindi alam ng mga tao na ang mga naturang solusyon ay umiiral, sa iba ay tila mahal, sa iba ay may mga hindi matagumpay na pagsubok ng mga alternatibong solusyon, at sa iba ay ipinagbabawal nila ang pagbili dahil sa mga parusa. Sa pangkalahatan, ang bukid ay hindi naararo, kaya nagpunta kami upang itaas ang birhen na lupa))).

Kailan mas mahusay ang storage system kaysa sa GCS?

Habang nagtatrabaho kami sa merkado, madalas kaming tinatanong kung kailan mas mahusay na gumamit ng isang klasikong pamamaraan na may mga sistema ng imbakan, at kailan gagamit ng hyperconvergent? Maraming kumpanyang gumagawa ng GCS (lalo na ang mga walang storage system sa kanilang portfolio) ang nagsasabing: "Ang mga storage system ay nagiging lipas na, hyperconverged na lang!" Ito ay isang matapang na pahayag, ngunit hindi ito ganap na sumasalamin sa katotohanan.

Sa katotohanan, ang merkado ng imbakan ay talagang lumilipat patungo sa hyperconvergence at katulad na mga solusyon, ngunit palaging mayroong "ngunit".

Una, ang mga sentro ng data at mga imprastraktura ng IT na binuo ayon sa klasikal na pamamaraan na may mga sistema ng imbakan ay hindi madaling maitayo muli, kaya ang modernisasyon at pagkumpleto ng mga naturang imprastraktura ay isang pamana pa rin sa loob ng 5-7 taon.

Pangalawa, ang imprastraktura na kasalukuyang itinatayo para sa karamihan (ibig sabihin ang Russian Federation) ay itinayo ayon sa klasikal na pamamaraan gamit ang mga sistema ng imbakan, at hindi dahil ang mga tao ay hindi alam ang tungkol sa hyperconvergence, ngunit dahil ang hyperconvergence market ay bago, mga solusyon at ang mga pamantayan ay hindi pa naitatag , ang mga taong IT ay hindi pa sanay, mayroon silang kaunting karanasan, ngunit kailangan nilang magtayo ng mga sentro ng data dito at ngayon. At ang trend na ito ay tatagal ng isa pang 3-5 taon (at pagkatapos ay isa pang legacy, tingnan ang punto 1).

Pangatlo, mayroong purong teknikal na limitasyon sa mga karagdagang maliliit na pagkaantala na 2 millisecond sa bawat pagsulat (hindi kasama ang lokal na cache, siyempre), na siyang halaga ng ibinahagi na storage.

Well, huwag nating kalimutan ang tungkol sa paggamit ng malalaking pisikal na server na gustong-gusto ang vertical scaling ng disk subsystem.

Maraming kinakailangan at tanyag na gawain kung saan ang mga storage system ay kumikilos nang mas mahusay kaysa sa GCS. Dito, siyempre, ang mga tagagawa na walang mga sistema ng imbakan sa kanilang portfolio ng produkto ay hindi sasang-ayon sa amin, ngunit handa kaming makipagtalo nang makatwiran. Siyempre, kami, bilang mga developer ng parehong produkto, ay tiyak na maghahambing ng mga storage system at GCS sa isa sa aming mga publication sa hinaharap, kung saan malinaw naming ipapakita kung alin ang mas mahusay sa ilalim ng anong mga kundisyon.

At saan mas gagana ang mga hyperconverged na solusyon kaysa sa mga storage system?

Batay sa mga punto sa itaas, tatlong malinaw na konklusyon ang maaaring iguguhit:

1. Kung saan ang karagdagang 2 milliseconds ng latency para sa pag-record, na patuloy na nangyayari sa anumang produkto (ngayon ay hindi natin pinag-uusapan ang tungkol sa synthetics, ang mga nanosecond ay maaaring ipakita sa synthetics), ay hindi kritikal, ang hyperconvergent ay angkop.
2. Kung saan ang load mula sa malalaking pisikal na server ay maaaring gawing maraming maliliit na virtual at ipamahagi sa mga node, gagana rin nang maayos ang hyperconvergence doon.
3. Kung saan ang pahalang na pag-scale ay isang mas mataas na priyoridad kaysa sa patayong pag-scale, ang GCS ay gagawa din ng maayos doon.

Ano ang mga solusyong ito?

1. Lahat ng karaniwang serbisyo sa imprastraktura (serbisyo ng direktoryo, mail, EDMS, mga file server, maliit o katamtamang ERP at BI system, atbp.). Tinatawag namin itong "pangkalahatang computing".
2. Ang imprastraktura ng mga tagapagbigay ng ulap, kung saan kinakailangan na mabilis at na-standardize nang pahalang na palawakin at madaling "i-cut" ang isang malaking bilang ng mga virtual machine para sa mga kliyente.
3. Virtual desktop infrastructure (VDI), kung saan maraming maliliit na user na virtual machine ang tumatakbo at tahimik na "lumulutang" sa loob ng magkatulad na cluster.
4. Mga network ng branch, kung saan ang bawat sangay ay nangangailangan ng isang standard, fault-tolerant, ngunit murang imprastraktura ng 15-20 virtual machine.
5. Anumang distributed computing (mga serbisyo ng malaking data, halimbawa). Kung saan napupunta ang pagkarga hindi "sa lalim", ngunit "sa lawak".
6. Mga pagsubok na kapaligiran kung saan ang mga karagdagang maliliit na pagkaantala ay katanggap-tanggap, ngunit may mga paghihigpit sa badyet, dahil ito ay mga pagsubok.

Sa ngayon, para sa mga gawaing ito na ginawa namin ang AERODISK vAIR at sa kanila kami tumutuon (matagumpay sa ngayon). Marahil ito ay magbago sa lalong madaling panahon, dahil... hindi tumitigil ang mundo.

Kaya…

Nakumpleto nito ang unang bahagi ng isang malaking serye ng mga artikulo; sa susunod na artikulo ay pag-uusapan natin ang tungkol sa arkitektura ng solusyon at ang mga sangkap na ginamit.

Tinatanggap namin ang mga tanong, mungkahi at nakabubuo na mga hindi pagkakaunawaan.

Pinagmulan: www.habr.com