Ang artikulong ito ay isinulat upang tulungan kang pumili ng tamang solusyon para sa iyong sarili at maunawaan ang mga pagkakaiba sa pagitan ng SDS gaya ng Gluster, Ceph at Vstorage (Virtuozzo).
Ang teksto ay gumagamit ng mga link sa mga artikulo na may mas detalyadong pagsisiwalat ng ilang mga problema, kaya ang mga paglalarawan ay magiging maikli hangga't maaari, gamit ang mga pangunahing punto nang walang hindi kinakailangang himulmol at panimulang impormasyon na maaari mong, kung nais mo, nang nakapag-iisa na makuha sa Internet.
Sa katunayan, siyempre, ang mga paksa na itinaas ay nangangailangan ng mga tono ng teksto, ngunit sa modernong mundo parami nang parami ang hindi gustong magbasa ng maraming))), upang mabilis kang magbasa at gumawa ng isang pagpipilian, at kung mayroong isang bagay. hindi malinaw, sundin ang mga link o hindi malinaw na mga salita sa google))), at ang artikulong ito ay tulad ng isang transparent na pambalot para sa malalalim na paksang ito, na nagpapakita ng pagpuno - ang pangunahing mga pangunahing punto ng bawat desisyon.
gluster
Magsimula tayo sa Gluster, na aktibong ginagamit ng mga tagagawa ng mga hyperconverged na platform na may SDS batay sa open source para sa mga virtual na kapaligiran at makikita sa website ng RedHat sa seksyon ng imbakan, kung saan maaari kang pumili mula sa dalawang opsyon sa SDS: Gluster o Ceph.
Ang Gluster ay binubuo ng isang stack ng mga tagasalin - mga serbisyong gumaganap ng lahat ng gawain ng pamamahagi ng mga file, atbp. Ang Brick ay isang serbisyo na nagseserbisyo sa isang disk, Ang Volume ay isang volume (pool) na pinag-iisa ang mga brick na ito. Susunod ay ang serbisyo para sa pamamahagi ng mga file sa mga grupo gamit ang DHT (distributed hash table) function. Hindi namin isasama ang serbisyo ng Sharding sa paglalarawan dahil ilalarawan ng mga link sa ibaba ang mga problemang nauugnay dito.
Kapag nagsusulat, ang buong file ay naka-imbak sa brick at ang kopya nito ay sabay-sabay na isinulat sa brick sa pangalawang server. Susunod, ang pangalawang file ay isusulat sa pangalawang pangkat ng dalawang brick (o higit pa) sa magkaibang mga server.
Kung ang mga file ay humigit-kumulang sa parehong laki at ang dami ay binubuo lamang ng isang pangkat, kung gayon ang lahat ay maayos, ngunit sa ilalim ng iba pang mga kondisyon ang mga sumusunod na problema ay lilitaw mula sa mga paglalarawan:
- ang espasyo sa mga grupo ay hindi pantay na ginagamit, depende ito sa laki ng mga file at kung walang sapat na espasyo sa grupo para magsulat ng file, makakatanggap ka ng error, ang file ay hindi isusulat at hindi na ipapamahagi sa ibang grupo. ;
- kapag nagsusulat ng isang file, ang IO ay napupunta lamang sa isang grupo, ang iba ay idle;
- hindi ka makakakuha ng IO ng buong volume kapag nagsusulat ng isang file;
- at ang pangkalahatang konsepto ay mukhang hindi gaanong produktibo dahil sa kakulangan ng pamamahagi ng data sa mga bloke, kung saan mas madaling balansehin at lutasin ang problema ng pare-parehong pamamahagi, at hindi na ngayon ang buong file ay napupunta sa isang bloke.
Mula sa opisyal na paglalarawan hindi rin namin sinasadyang nauunawaan na gumagana ang gluster bilang imbakan ng file sa ibabaw ng klasikong hardware RAID. Nagkaroon ng mga pagtatangka sa pag-unlad na i-cut (Sharding) ang mga file sa mga bloke, ngunit ang lahat ng ito ay isang karagdagan na nagpapataw ng mga pagkalugi sa pagganap sa umiiral nang diskarte sa arkitektura, kasama ang paggamit ng mga naturang malayang ipinamamahaging bahagi na may mga limitasyon sa pagganap bilang Fuse. Walang mga serbisyo ng metadata, na naglilimita sa pagganap at mga kakayahan sa pagpapaubaya ng kasalanan ng imbakan kapag namamahagi ng mga file sa mga bloke. Maaaring maobserbahan ang mas mahusay na mga indicator ng performance gamit ang configuration na "Distributed Replicated" at ang bilang ng mga node ay dapat na hindi bababa sa 6 upang ayusin ang isang maaasahang replica 3 na may pinakamainam na pamamahagi ng load.
Ang mga natuklasang ito ay nauugnay din sa paglalarawan ng karanasan ng user at kung ikukumpara sa , at mayroon ding paglalarawan ng karanasang humahantong sa pag-unawa sa mas produktibo at mas maaasahang pagsasaayos na ito
Ipinapakita ng larawan ang pamamahagi ng load kapag nagsusulat ng dalawang file, kung saan ang mga kopya ng unang file ay ipinamamahagi sa unang tatlong server, na pinagsama sa volume 0 group, at tatlong kopya ng pangalawang file ay inilalagay sa pangalawang grupo volume1 ng tatlo mga server. Ang bawat server ay may isang disk.
Ang pangkalahatang konklusyon ay maaari mong gamitin ang Gluster, ngunit sa pag-unawa na magkakaroon ng mga limitasyon sa performance at fault tolerance na nagdudulot ng mga paghihirap sa ilalim ng ilang partikular na kondisyon ng isang hyperconverged na solusyon, kung saan kailangan din ang mga mapagkukunan para sa pag-compute ng mga load ng virtual na kapaligiran.
Mayroon ding ilang tagapagpahiwatig ng pagganap ng Gluster na maaaring makamit sa ilalim ng ilang partikular na kundisyon, limitado sa
Si Ceph naman
Ngayon tingnan natin si Ceph mula sa mga paglalarawan ng arkitektura na nagawa ko Mayroon ding paghahambing sa pagitan , kung saan maaari mong agad na maunawaan na ipinapayong i-deploy ang Ceph sa magkakahiwalay na mga server, dahil ang mga serbisyo nito ay nangangailangan ng lahat ng mga mapagkukunan ng hardware sa ilalim ng pagkarga.
arkitektura mas kumplikado kaysa sa Gluster at may mga serbisyo tulad ng mga serbisyo ng metadata, ngunit ang buong stack ng mga bahagi ay medyo kumplikado at hindi masyadong nababaluktot para sa paggamit nito sa isang virtualization solution. Ang data ay naka-imbak sa mga bloke, na mukhang mas produktibo, ngunit sa hierarchy ng lahat ng mga serbisyo (mga bahagi), may mga pagkalugi at latency sa ilalim ng ilang mga pagkarga at mga kondisyong pang-emergency, halimbawa ang mga sumusunod
Mula sa paglalarawan ng arkitektura, ang puso ay CRUSH, salamat kung saan napili ang lokasyon para sa pag-iimbak ng data. Susunod ang PG - ito ang pinakamahirap na abstraction (lohikal na grupo) na maunawaan. Kailangan ng mga PG para mas maging effective si CRUSH. Ang pangunahing layunin ng PG ay upang pangkatin ang mga bagay upang bawasan ang pagkonsumo ng mapagkukunan, pataasin ang pagganap at scalability. Ang direktang pagtugon sa mga bagay, nang paisa-isa, nang hindi pinagsama ang mga ito sa isang PG ay magiging napakamahal. Ang OSD ay isang serbisyo para sa bawat indibidwal na disk.
Ang isang cluster ay maaaring magkaroon ng isa o maraming data pool para sa iba't ibang layunin at may iba't ibang mga setting. Ang mga pool ay nahahati sa mga pangkat ng pagkakalagay. Ang mga pangkat ng placement ay nag-iimbak ng mga bagay na ina-access ng mga kliyente. Dito magtatapos ang lohikal na antas, at magsisimula ang pisikal na antas, dahil ang bawat pangkat ng placement ay itinalaga ng isang pangunahing disk at ilang mga replica disk (kung ilan ang eksaktong nakasalalay sa kadahilanan ng pagtitiklop ng pool). Sa madaling salita, sa lohikal na antas ang bagay ay naka-imbak sa isang partikular na pangkat ng placement, at sa pisikal na antas - sa mga disk na nakatalaga dito. Sa kasong ito, ang mga disk ay maaaring pisikal na matatagpuan sa iba't ibang mga node o kahit na sa iba't ibang mga sentro ng data.
Sa scheme na ito, ang mga placement group ay mukhang isang kinakailangang antas para sa flexibility ng buong solusyon, ngunit sa parehong oras, bilang isang karagdagang link sa chain na ito, na hindi sinasadyang nagmumungkahi ng pagkawala ng produktibo. Halimbawa, kapag nagsusulat ng data, kailangang hatiin ito ng system sa mga pangkat na ito at pagkatapos ay sa pisikal na antas sa pangunahing disk at mga disk para sa mga replika. Iyon ay, gumagana ang Hash function kapag naghahanap at nagpasok ng isang bagay, ngunit mayroong isang side effect - ito ay napakataas na gastos at mga paghihigpit sa muling pagtatayo ng hash (kapag nagdadagdag o nag-aalis ng isang disk). Ang isa pang problema sa hash ay ang malinaw na ipinako na lokasyon ng data na hindi mababago. Iyon ay, kung sa paanuman ang disk ay nasa ilalim ng pagtaas ng pag-load, kung gayon ang system ay walang pagkakataon na huwag sumulat dito (sa pamamagitan ng pagpili ng isa pang disk), ang hash function ay obligado ang data na matatagpuan ayon sa panuntunan, gaano man kalala ang disk ay, kaya kumakain si Ceph ng maraming memorya kapag muling itinayo ang PG sa kaso ng pagpapagaling sa sarili o pagtaas ng imbakan. Ang konklusyon ay gumagana nang maayos si Ceph (kahit na mabagal), ngunit kapag walang scaling, emergency na sitwasyon, o update.
Mayroong, siyempre, mga pagpipilian para sa pagpapataas ng pagganap sa pamamagitan ng pag-cache at pagbabahagi ng cache, ngunit nangangailangan ito ng mahusay na hardware at magkakaroon pa rin ng mga pagkalugi. Ngunit sa pangkalahatan, mukhang mas mapang-akit si Ceph kaysa kay Gluster para sa pagiging produktibo. Gayundin, kapag ginagamit ang mga produktong ito, kinakailangang isaalang-alang ang isang mahalagang kadahilanan - ito ay isang mataas na antas ng kakayahan, karanasan at propesyonalismo na may malaking diin sa Linux, dahil napakahalaga na i-deploy, i-configure at mapanatili ang lahat ng tama, na nagpapataw ng higit pang responsibilidad at pasanin sa administrador.
Vstorage
Ang arkitektura ay mukhang mas kawili-wili , na maaaring gamitin kasabay ng isang hypervisor sa parehong mga node, sa parehong , ngunit napakahalaga na i-configure nang tama ang lahat upang makamit ang mahusay na pagganap. Iyon ay, ang pag-deploy ng naturang produkto mula sa kahon sa anumang pagsasaayos nang hindi isinasaalang-alang ang mga rekomendasyon alinsunod sa arkitektura ay magiging napakadali, ngunit hindi produktibo.
Ano ang maaaring magkakasamang mabuhay para sa imbakan sa tabi ng mga serbisyo ng kvm-qemu hypervisor, at ito ay ilan lamang sa mga serbisyo kung saan natagpuan ang isang compact na pinakamainam na hierarchy ng mga bahagi: serbisyo ng kliyente na naka-mount sa pamamagitan ng FUSE (binago, hindi open source), serbisyo ng metadata ng MDS (Metadata service), service Chunk service data blocks, na sa pisikal na antas ay katumbas ng isang disk at iyon lang. Sa mga tuntunin ng bilis, siyempre, pinakamainam na gumamit ng isang fault-tolerant scheme na may dalawang replika, ngunit kung gumagamit ka ng caching at mga log sa SSD drive, kung gayon ang error-tolerant coding (erase coding o raid6) ay maaaring ma-overclocked nang disente sa isang hybrid scheme o mas maganda pa sa lahat ng flash. Mayroong ilang kawalan sa EC (burahin ang coding): kapag binabago ang isang bloke ng data, kinakailangang muling kalkulahin ang mga halaga ng parity. Upang i-bypass ang mga pagkalugi na nauugnay sa operasyong ito, sumulat si Ceph sa EC nang ipinagpaliban at ang mga problema sa pagganap ay maaaring mangyari sa panahon ng isang partikular na kahilingan, kapag, halimbawa, ang lahat ng mga bloke ay kailangang basahin, at sa kaso ng Virtuozzo Storage, ang pagsulat ng mga binagong bloke ay isinasagawa. gamit ang "log-structured file system" na diskarte, na nagpapaliit sa mga gastos sa pagkalkula ng parity. Upang matantya ang humigit-kumulang na mga opsyon na may acceleration ng trabaho na may at walang EC, mayroong β ang mga numero ay maaaring tinatayang depende sa koepisyent ng katumpakan ng tagagawa ng kagamitan, ngunit ang resulta ng mga kalkulasyon ay isang magandang tulong sa pagpaplano ng pagsasaayos.
Ang isang simpleng diagram ng mga bahagi ng imbakan ay hindi nangangahulugan na ang mga sangkap na ito ay hindi sumisipsip ngunit kung kalkulahin mo ang lahat ng mga gastos nang maaga, maaari kang umasa sa pakikipagtulungan sa tabi ng hypervisor.
Mayroong pamamaraan para sa paghahambing ng pagkonsumo ng mga mapagkukunan ng hardware ng mga serbisyo ng imbakan ng Ceph at Virtuozzo.
Kung dati ay posible na ihambing ang Gluster at Ceph gamit ang mga lumang artikulo, gamit ang pinakamahalagang linya mula sa kanila, kung gayon sa Virtuozzo ito ay mas mahirap. Walang maraming mga artikulo sa produktong ito at ang impormasyon ay maaari lamang makuha mula sa dokumentasyon sa o sa Russian kung isasaalang-alang namin ang Vstorage bilang imbakan na ginagamit sa ilang hyperconverged na solusyon sa mga kumpanya tulad ng at Acronis.
Susubukan kong tumulong sa isang paglalarawan ng arkitektura na ito, kaya magkakaroon ng kaunti pang teksto, ngunit nangangailangan ng maraming oras upang maunawaan ang dokumentasyon sa iyong sarili, at ang umiiral na dokumentasyon ay magagamit lamang bilang isang sanggunian sa pamamagitan ng pagbabago sa talahanayan ng mga nilalaman o paghahanap sa pamamagitan ng keyword.
Isaalang-alang natin ang proseso ng pag-record sa isang hybrid na pagsasaayos ng hardware na may mga bahagi na inilarawan sa itaas: ang pag-record ay magsisimulang pumunta sa node kung saan sinimulan ito ng kliyente (ang serbisyo ng FUSE mount point), ngunit ang Metadata Service (MDS) master component ay siyempre. direktang idirekta ang kliyente sa nais na serbisyo ng tipak (mga bloke ng serbisyo ng imbakan ng CS), iyon ay, ang MDS ay hindi nakikilahok sa proseso ng pag-record, ngunit idinidirekta lamang ang serbisyo sa kinakailangang tipak. Sa pangkalahatan, maaari kaming magbigay ng isang pagkakatulad sa pag-record na may pagbuhos ng tubig sa mga bariles. Ang bawat bariles ay isang 256MB data block.
Iyon ay, ang isang disk ay isang tiyak na bilang ng mga naturang bariles, iyon ay, ang dami ng disk na hinati sa 256MB. Ang bawat kopya ay ipinamamahagi sa isang node, ang pangalawa ay halos kahanay sa isa pang node, atbp... Kung mayroon kaming tatlong mga replika at mayroong mga SSD disk para sa cache (para sa pagbabasa at pagsulat ng mga log), pagkatapos ay ang pagkumpirma ng pagsulat ay magaganap pagkatapos ng pagsulat ang log sa SSD, at parallel reset mula sa SSD ay magpapatuloy sa HDD, na parang nasa background. Sa kaso ng tatlong replika, ang rekord ay gagawin pagkatapos ng kumpirmasyon mula sa SSD ng ikatlong node. Maaaring mukhang ang kabuuan ng bilis ng pagsulat ng tatlong SSD ay maaaring hatiin ng tatlo at makukuha natin ang bilis ng pagsulat ng isang replika, ngunit ang mga kopya ay nakasulat nang magkatulad at ang bilis ng Latency ng network ay karaniwang mas mataas kaysa sa SSD, at sa katunayan ang pagganap ng pagsulat ay depende sa network. Kaugnay nito, upang makita ang totoong IOPS, kailangan mong i-load nang tama ang buong Vstorage sa pamamagitan ng , iyon ay, pagsubok sa tunay na pag-load, at hindi memorya at cache, kung saan kinakailangang isaalang-alang ang tamang laki ng bloke ng data, bilang ng mga thread, atbp.
Ang nabanggit na recording log sa SSD ay gumagana sa paraang sa sandaling makapasok ang data dito, agad itong binabasa ng serbisyo at isinulat sa HDD. Mayroong ilang mga serbisyo ng metadata (MDS) bawat cluster at ang kanilang numero ay tinutukoy ng isang korum, na gumagana ayon sa Paxos algorithm. Mula sa pananaw ng kliyente, ang FUSE mount point ay isang cluster storage folder na sabay-sabay na nakikita ng lahat ng node sa cluster, ang bawat node ay may naka-mount na client ayon sa prinsipyong ito, kaya ang storage na ito ay available sa bawat node.
Para sa pagganap ng alinman sa inilarawan sa itaas na mga diskarte, napakahalaga, sa yugto ng pagpaplano at pag-deploy, na wastong i-configure ang network, kung saan magkakaroon ng pagbabalanse dahil sa pagsasama-sama at tamang napiling bandwidth ng channel ng network. Sa pagsasama-sama, mahalagang piliin ang tamang hashing mode at laki ng frame. Mayroon ding napakalakas na pagkakaiba mula sa SDS na inilarawan sa itaas, ito ay fuse sa teknolohiya ng mabilis na landas sa Virtuozzo Storage. Na, bilang karagdagan sa modernized fuse, hindi tulad ng iba pang mga open source na solusyon, ay makabuluhang nagpapataas ng IOPS at nagbibigay-daan sa iyo na hindi limitado sa pahalang o patayong scaling. Sa pangkalahatan, kumpara sa mga arkitektura na inilarawan sa itaas, ang isang ito ay mukhang mas malakas, ngunit para sa gayong kasiyahan, siyempre, kailangan mong bumili ng mga lisensya, hindi katulad ng Ceph at Gluster.
Upang buod, maaari naming i-highlight ang tuktok ng tatlo: Ang Virtuozzo Storage ay nangunguna sa mga tuntunin ng pagganap at pagiging maaasahan ng arkitektura, si Ceph ay pumangalawa, at si Gluster ay nasa ikatlong pwesto.
Ang pamantayan kung saan napili ang Virtuozzo Storage: isa itong pinakamainam na hanay ng mga bahagi ng arkitektura, na-moderno para sa diskarteng ito ng Fuse na may mabilis na landas, isang flexible na hanay ng mga configuration ng hardware, mas kaunting pagkonsumo ng mapagkukunan at ang kakayahang magbahagi sa compute (computing/virtualization), iyon ay, ito ay ganap na angkop para sa isang hyperconverged solusyon , kung saan siya ay bahagi ng. Ang pangalawang lugar ay ang Ceph dahil ito ay isang mas produktibong arkitektura kumpara sa Gluster, dahil sa operasyon nito sa mga bloke, pati na rin ang mga mas flexible na sitwasyon at ang kakayahang magtrabaho sa mas malalaking kumpol.
May mga planong magsulat ng paghahambing sa pagitan ng vSAN, Space Direct Storage, Vstorage at Nutanix Storage, pagsubok sa Vstorage sa HPE at Huawei equipment, pati na rin ang mga sitwasyon para sa pagsasama ng Vstorage sa mga external na hardware storage system, kaya kung nagustuhan mo ang artikulo, ito ay magiging Masaya akong makakuha ng feedback mula sa iyo, na maaaring magpapataas ng motibasyon para sa mga bagong artikulo, na isinasaalang-alang ang iyong mga komento at kagustuhan.
Pinagmulan: www.habr.com