Ĉi tiu artikolo estis skribita por helpi vin elekti la ĝustan solvon por vi mem kaj kompreni la diferencojn inter SDS kiel Gluster, Ceph kaj Vstorage (Virtuozzo).
La teksto uzas ligilojn al artikoloj kun pli detala malkaŝo de certaj problemoj, do la priskriboj estos kiel eble plej mallongaj, uzante ŝlosilajn punktojn sen nenecesaj lanugoj kaj enkondukajn informojn, kiujn vi povas, se vi deziras, sendepende akiri en la Interreto.
Fakte, kompreneble, la levitaj temoj postulas la tonojn de la teksto, sed en la moderna mondo pli kaj pli da homoj ne multe ŝatas legi))), do vi povas rapide legi kaj fari elekton, kaj se io estas ne klara, sekvu la ligilojn aŭ google neklarajn vortojn))), kaj ĉi tiu artikolo estas kiel travidebla envolvaĵo por ĉi tiuj profundaj temoj, montrante la plenigon - la ĉefaj ŝlosilaj punktoj de ĉiu decido.
Brilo
Ni komencu per Gluster, kiu estas aktive uzata de fabrikantoj de hiperkonverĝaj platformoj kun SDS bazitaj sur malferma fonto por virtualaj medioj kaj troveblas en la retejo de RedHat en la stokado sekcio, kie vi povas elekti el du SDS-opcioj: Gluster aŭ Ceph.
Gluster konsistas el stako da tradukiloj - servoj, kiuj plenumas la tutan laboron por distribui dosierojn ktp. Briko estas servo kiu servas unu diskon, Volumo estas volumeno (naĝejo) kiu kunigas ĉi tiujn brikojn. Poste venas la servo por distribui dosierojn en grupojn uzante la funkcion DHT (distribuita hashtabelo). Ni ne inkludos la Sharding-servon en la priskribon ĉar la subaj ligiloj priskribos la problemojn asociitajn kun ĝi.
Dum skribado, la tuta dosiero estas stokita en briko kaj ĝia kopio estas samtempe skribita al briko sur la dua servilo. Poste, la dua dosiero estos skribita al la dua grupo de du brikoj (aŭ pli) sur malsamaj serviloj.
Se la dosieroj estas proksimume samgrandaj kaj la volumo konsistas el nur unu grupo, tiam ĉio estas en ordo, sed en aliaj kondiĉoj la sekvaj problemoj aperos el la priskriboj:
- spaco en grupoj estas uzata malegale, ĝi dependas de la grandeco de la dosieroj kaj se ne estas sufiĉe da spaco en la grupo por skribi dosieron, vi ricevos eraron, la dosiero ne estos skribita kaj ne estos redistribuita al alia grupo. ;
- skribante unu dosieron, IO iras nur al unu grupo, la ceteraj estas neaktivaj;
- vi ne povas ricevi IO de la tuta volumo skribante unu dosieron;
- kaj la ĝenerala koncepto aspektas malpli produktiva pro la manko de distribuo de datumoj en blokojn, kie estas pli facile ekvilibrigi kaj solvi la problemon de unuforma distribuo, kaj ne kiel nun la tuta dosiero eniras blokon.
El la oficiala priskribo ni ankaŭ nevole venas al la kompreno, ke gluster funkcias kiel dosierstokado aldone al klasika aparataro RAID. Okazis disvolvaj provoj tranĉi (Sharding) dosierojn en blokojn, sed ĉio ĉi estas aldono kiu trudas rendimentajn perdojn al la jam ekzistanta arkitektura aliro, kaj plie la uzadon de tiaj libere distribuitaj komponantoj kun rendimentaj limigoj kiel Fuse. Ne ekzistas metadatumaj servoj, kio limigas la agadon kaj faŭltoleremajn kapablojn de la stokado dum distribuado de dosieroj en blokojn. Pli bonaj agado-indikiloj povas esti observitaj kun la "Distribuita Replikita" agordo kaj la nombro da nodoj devus esti almenaŭ 6 por organizi fidindan kopion 3 kun optimuma ŝarĝa distribuo.
Ĉi tiuj trovoj ankaŭ rilatas al la priskribo de la uzantsperto kaj kompare kun , kaj ankaŭ estas priskribo de la sperto kondukanta al kompreno de ĉi tiu pli produktiva kaj pli fidinda agordo
La bildo montras la ŝarĝan distribuon dum vi verkado de du dosieroj, kie kopioj de la unua dosiero estas distribuitaj tra la unuaj tri serviloj, kiuj estas kombinitaj en la volumo 0 grupo, kaj tri kopioj de la dua dosiero estas metitaj sur la dua grupa volumo1 el tri. serviloj. Ĉiu servilo havas unu diskon.
La ĝenerala konkludo estas, ke vi povas uzi Gluster, sed kun la kompreno, ke estos limigoj en rendimento kaj faŭltoleremo, kiuj kreas malfacilaĵojn sub certaj kondiĉoj de hiperkonverĝa solvo, kie rimedoj ankaŭ estas bezonataj por la komputilaj ŝarĝoj de virtualaj medioj.
Estas ankaŭ kelkaj Gluster-agado-indikiloj, kiuj povas esti atingitaj sub certaj kondiĉoj, limigitaj al
ceph
Nun ni rigardu Ceph el la arkitekturaj priskriboj, kiujn mi povis Estas ankaŭ komparo inter , kie vi povas tuj kompreni, ke estas konsilinde deploji Ceph sur apartaj serviloj, ĉar ĝiaj servoj postulas ĉiujn aparatajn rimedojn sub ŝarĝo.
arkitekturo pli kompleksa ol Gluster kaj ekzistas servoj kiel metadatumoj, sed la tuta stako de komponantoj estas sufiĉe kompleksa kaj ne tre fleksebla por uzi ĝin en virtualiga solvo. La datumoj estas stokitaj en blokoj, kio aspektas pli produktiva, sed en la hierarkio de ĉiuj servoj (komponentoj), estas perdoj kaj latencia sub certaj ŝarĝoj kaj kriz-kondiĉoj, ekzemple la jenaj.
El la priskribo de la arkitekturo, la koro estas CRUSH, danke al kiu la loko por stoki datumojn estas elektita. Poste venas PG - tio estas la plej malfacila abstraktado (logika grupo) komprenebla. PGoj estas necesaj por fari CRUSH pli efika. La ĉefa celo de PG estas grupigi objektojn por redukti resursan konsumon, pliigi rendimenton kaj skaleblon. Adresi objektojn rekte, individue, sen kombini ilin en PG estus tre multekosta. OSD estas servo por ĉiu individua disko.
Areto povas havi unu aŭ multajn datumgrupojn por malsamaj celoj kaj kun malsamaj agordoj. Naĝejoj estas dividitaj en lokiggrupojn. Lokigaj grupoj stokas objektojn, kiujn klientoj aliras. Ĉi tie finiĝas la logika nivelo, kaj komenciĝas la fizika nivelo, ĉar ĉiu lokiga grupo ricevas unu ĉefan diskon kaj plurajn kopiajn diskojn (kiom da precize dependas de la naĝeja reproduktadfaktoro). Alivorte, ĉe la logika nivelo la objekto estas konservita en specifa lokiga grupo, kaj ĉe la fizika nivelo - sur la diskoj, kiuj estas asignitaj al ĝi. En ĉi tiu kazo, la diskoj povas esti fizike lokitaj sur malsamaj nodoj aŭ eĉ en malsamaj datumcentroj.
En ĉi tiu skemo, lokigaj grupoj aspektas kiel necesa nivelo por la fleksebleco de la tuta solvo, sed samtempe kiel ekstra ligo en ĉi tiu ĉeno, kiu nevole sugestas perdon de produktiveco. Ekzemple, dum skribado de datumoj, la sistemo devas dividi ĝin en ĉi tiujn grupojn kaj poste sur la fizika nivelo en la ĉefan diskon kaj diskojn por kopioj. Tio estas, la funkcio Hash funkcias kiam oni serĉas kaj enmetas objekton, sed estas kromefiko - ĝi estas tre altaj kostoj kaj limigoj pri rekonstruado de la hash (dum aldono aŭ forigo de disko). Alia hashproblemo estas la klare najlita loko de datumoj, kiuj ne povas esti ŝanĝitaj. Tio estas, se iel la disko estas sub pliigita ŝarĝo, tiam la sistemo ne havas la ŝancon ne skribi al ĝi (elektante alian diskon), la hash-funkcio devigas la datumojn troviĝi laŭ la regulo, kiom ajn malbonaj. la disko estas, do Ceph manĝas multe da memoro dum rekonstruado de la PG en kazo de memresaniĝo aŭ pliigo de stokado. La konkludo estas, ke Ceph funkcias bone (kvankam malrapide), sed nur kiam ne estas grimpado, krizaj situacioj aŭ ĝisdatigoj.
Estas, kompreneble, ebloj por pliigi rendimenton per kaŝmemoro kaj kaŝdividado, sed ĉi tio postulas bonan aparataron kaj ankoraŭ estos perdoj. Sed ĝenerale, Ceph aspektas pli tenta ol Gluster por produktiveco. Ankaŭ, kiam vi uzas ĉi tiujn produktojn, necesas konsideri gravan faktoron - ĉi tio estas alta nivelo de kompetenteco, sperto kaj profesieco kun granda emfazo de Linukso, ĉar estas tre grave disfaldi, agordi kaj konservi ĉion ĝuste, kiu trudas eĉ pli da respondeco kaj ŝarĝo al la administranto.
Vstorage
La arkitekturo aspektas eĉ pli interesa , kiu povas esti uzata kune kun hiperviziero sur la samaj nodoj, sur la sama , sed estas tre grave agordi ĉion ĝuste por atingi bonan rendimenton. Tio estas, disfaldi tian produkton el la skatolo sur ajna agordo sen konsideri la rekomendojn konforme al la arkitekturo estos tre facila, sed ne produktiva.
Kio povas kunekzisti por stokado apud la servoj de la kvm-qemu hiperviziero, kaj ĉi tiuj estas nur kelkaj servoj kie kompakta optimuma hierarkio de komponantoj estis trovita: klienta servo muntita per FUSE (modifita, ne malferma fonto), MDS metadatuma servo (Metadata servo), servo Chunk servo datumblokoj, kiu ĉe la fizika nivelo estas egala al unu disko kaj jen ĉio. Koncerne rapidecon, kompreneble, estas optimume uzi mistoleran skemon kun du kopioj, sed se vi uzas kaŝmemoron kaj protokolojn sur SSD-diskoj, tiam erartolerema kodigo (forviŝi kodigon aŭ raid6) povas esti dece overclocked sur hibrida skemo aŭ eĉ pli bona sur ĉiuj fulmoj. Estas iu malavantaĝo kun EC (forviŝi kodigon): kiam oni ŝanĝas unu datumblokon, necesas rekalkuli la parecajn kvantojn. Por preteriri la perdojn asociitajn kun ĉi tiu operacio, Ceph skribas al EC prokraste kaj agado problemoj povas okazi dum certa peto, kiam, ekzemple, ĉiuj blokoj devas esti legitaj, kaj en la kazo de Virtuozzo Storage, skribado ŝanĝitaj blokoj estas efektivigita. uzante la "log-strukturitan dosiersistemon" aliron, kiu minimumigas egaleckalkulkostojn. Por taksi proksimume la eblojn kun akcelo de laboro kun kaj sen EC, ekzistas – la ciferoj povas esti proksimumaj depende de la precizeca koeficiento de la fabrikanto de ekipaĵo, sed la rezulto de la kalkuloj estas bona helpo en planado de la agordo.
Simpla diagramo de stokaj komponantoj ne signifas, ke ĉi tiuj komponantoj ne sorbas sed se vi kalkulas ĉiujn kostojn anticipe, vi povas kalkuli je kunlaboro apud la hiperviziero.
Estas skemo por kompari la konsumon de hardvarresursoj de Ceph kaj Virtuozzo stokadservoj.
Se antaŭe eblis kompari Gluster kaj Ceph uzante malnovajn artikolojn, uzante la plej gravajn liniojn el ili, tiam kun Virtuozzo estas pli malfacila. Ne estas multaj artikoloj pri ĉi tiu produkto kaj informoj nur povas esti kolektitaj el la dokumentado aŭ en la rusa se ni konsideras Vstorage kiel stokado uzata en iuj hiperkonverĝaj solvoj en kompanioj kiel ekzemple kaj Acronis.
Mi provos helpi pri priskribo de ĉi tiu arkitekturo, do estos iom pli da teksto, sed necesas multe da tempo por mem kompreni la dokumentadon, kaj la ekzistanta dokumentaro povas esti uzata nur kiel referenco per revizio de la tabelo. de enhavo aŭ serĉado per ŝlosilvorto.
Ni konsideru la registradprocezon en hibrida aparatara agordo kun la komponantoj priskribitaj supre: la registrado komencas iri al la nodo de kiu la kliento iniciatis ĝin (la FUSE-montpunkta servo), sed la majstra komponanto de Metadatuma Servo (MDS) kompreneble faros. direkti la klienton rekte al la dezirata peco-servo (stoka servo CS-blokoj), tio estas, MDS ne partoprenas la registradprocezon, sed simple direktas la servon al la postulata peco. Ĝenerale, ni povas doni analogion al registrado kun verŝado de akvo en barelojn. Ĉiu barelo estas 256MB datumbloko.
Tio estas, unu disko estas certa nombro da tiaj bareloj, tio estas, la diskvolumo dividita per 256MB. Ĉiu kopio estas distribuita al unu nodo, la dua preskaŭ paralele al alia nodo, ktp... Se ni havas tri kopiojn kaj estas SSD-diskoj por kaŝmemoro (por legi kaj skribi protokolojn), tiam konfirmo de la skribo okazos post skribado. la protokolo al la SSD, kaj paralela restarigo de la SSD daŭros sur la HDD, kvazaŭ en la fono. En la kazo de tri kopioj, la rekordo estos farita post konfirmo de la SSD de la tria nodo. Eble ŝajnas, ke la sumo de la skribrapideco de tri SSD-oj povas esti dividita per tri kaj ni ricevos la skribrapidecon de unu kopio, sed la kopioj estas skribitaj paralele kaj la reto-Latencia rapideco estas kutime pli alta ol tiu de la SSD, kaj fakte la skriba rendimento dependos de la reto. Ĉi-rilate, por vidi verajn IOPS, vi devas ĝuste ŝargi la tutan Vstorage per , tio estas, provante la realan ŝarĝon, kaj ne memoron kaj kaŝmemoron, kie necesas konsideri la ĝustan datumblokan grandecon, nombron da fadenoj, ktp.
La supre menciita registra registro sur la SSD funkcias tiel, ke tuj kiam datumoj eniras ĝin, ĝi estas tuj legata de la servo kaj skribita al la HDD. Ekzistas pluraj metadatumaj servoj (MDS) per areto kaj ilia nombro estas determinita de kvorumo, kiu funkcias laŭ la Paxos-algoritmo. De la vidpunkto de la kliento, la FUSE-munta punkto estas amasa stokado dosierujo, kiu estas samtempe videbla por ĉiuj nodoj en la areto, ĉiu nodo havas muntitan klienton laŭ ĉi tiu principo, do ĉi tiu stokado estas disponebla por ĉiu nodo.
Por la agado de iu el la supre priskribitaj aliroj, estas tre grave, en la planado kaj disfalda stadio, ĝuste agordi la reton, kie estos ekvilibro pro agregado kaj ĝuste elektita reta kanala bendolarĝo. En agregado, estas grave elekti la ĝustan hakan reĝimon kaj kadrajn grandecojn. Ankaŭ estas tre forta diferenco de la SDS priskribita supre, ĉi tio estas kunfandita kun rapida vojo teknologio en Virtuozzo Storage. Kiu, krom la modernigita fuzo, male al aliaj malfermfontaj solvoj, signife pliigas IOPS kaj permesas vin ne esti limigita per horizontala aŭ vertikala skalo. Ĝenerale, kompare kun la supre priskribitaj arkitekturoj, ĉi tiu aspektas pli potenca, sed por tia plezuro, kompreneble, vi devas aĉeti licencojn, male al Ceph kaj Gluster.
Por resumi, ni povas reliefigi la supro de la tri: Virtuozzo Storage prenas la unuan lokon laŭ rendimento kaj fidindeco de la arkitekturo, Ceph prenas la duan lokon, kaj Gluster prenas la trian lokon.
La kriterioj laŭ kiuj Virtuozzo Storage estis elektita: ĝi estas optimuma aro de arkitekturaj komponentoj, modernigitaj por ĉi tiu Fuse-aliro kun rapida vojo, fleksebla aro de hardvarkonfiguracioj, malpli da resursokonsumo kaj la kapablo kunhavigi kun komputado (komputado/virtualigo), tio estas, ĝi estas tute taŭga por hiperkonverĝa solvo , de kiu li estas parto. La dua loko estas Ceph ĉar ĝi estas pli produktiva arkitekturo kompare kun Gluster, pro sia funkciado en blokoj, same kiel pli flekseblaj scenaroj kaj la kapablo labori en pli grandaj aretoj.
Estas planoj verki komparon inter vSAN, Space Direct Storage, Vstorage kaj Nutanix Storage, provante Vstorage sur HPE kaj Huawei-ekipaĵoj, kaj ankaŭ scenarojn por integri Vstorage kun eksteraj aparataj stokadsistemoj, do se vi ŝatus la artikolon, ĝi estus agrable ricevi komentojn de vi, kio povus pliigi instigon por novaj artikoloj, konsiderante viajn komentojn kaj dezirojn.
fonto: www.habr.com