ProHoster > Blogs > Administrācija > Hiperkonverģēts risinājums AERODISK VAIR. Pamats ir ARDFS failu sistēma

Hiperkonverģēts risinājums AERODISK VAIR. Pamats ir ARDFS failu sistēma

Hiperkonverģēts risinājums AERODISK VAIR. Pamats ir ARDFS failu sistēma

Sveiki, Habr lasÄ«tāji. Ar Å”o rakstu mēs atklājam sēriju, kurā tiks runāts par mÅ«su izstrādāto hiperkonverģēto sistēmu AERODISK vAIR. Sākotnēji gribējām pirmajā rakstā izstāstÄ«t visu par visu, bet sistēma ir diezgan sarežģīta, tāpēc ziloni ēdÄ«sim pa daļām.

Sāksim stāstu ar sistēmas tapÅ”anas vēsturi, iedziļināsimies ARDFS failu sistēmā, kas ir vAIR pamatā, kā arÄ« nedaudz parunāsim par Ŕī risinājuma pozicionÄ“Å”anu Krievijas tirgÅ«.

Turpmākajos rakstos sÄ«kāk runāsim par dažādiem arhitektÅ«ras komponentiem (klasteri, hipervizoru, slodzes balansētāju, uzraudzÄ«bas sistēmu u.c.), konfigurācijas procesu, aktualizēsim licencÄ“Å”anas problēmas, atseviŔķi parādÄ«sim avārijas testus un, protams, rakstÄ«sim par slodzes testÄ“Å”anu un izmēru noteikÅ”ana. Mēs arÄ« veltÄ«sim atseviŔķu rakstu vAIR kopienas versijai.

Vai Aerodisk ir stāsts par uzglabāŔanas sistēmām? Vai arÄ« kāpēc mēs vispār sākām veikt hiperkonverÄ£enci?

Sākotnēji ideja izveidot savu hiperkonverÄ£enci mums radās kaut kur ap 2010. gadu. Tajā laikā tirgÅ« nebija ne Aerodisk, ne lÄ«dzÄ«gu risinājumu (komerciālas kastes hiperkonverģētās sistēmas). MÅ«su uzdevums bija Ŕāds: no serveru komplekta ar lokāliem diskiem, ko vieno starpsavienojums caur Ethernet protokolu, bija nepiecieÅ”ams izveidot paplaÅ”inātu krātuvi un palaist tur virtuālās maŔīnas un programmatÅ«ras tÄ«klu. Tas viss bija jāīsteno bez uzglabāŔanas sistēmām (jo vienkārÅ”i nebija naudas uzglabāŔanas sistēmām un to aparatÅ«rai, un mēs vēl nebijām izgudrojuÅ”i savas uzglabāŔanas sistēmas).

Mēs izmēģinājām daudzus atvērtā pirmkoda risinājumus un beidzot atrisinājām Å”o problēmu, taču risinājums bija ļoti sarežģīts un grÅ«ti atkārtojams. Turklāt Å”is risinājums bija kategorijā ā€œVai tas darbojas? Neaiztiec! Tāpēc, atrisinot Å”o problēmu, mēs tālāk neattÄ«stÄ«jām ideju par mÅ«su darba rezultātu pārveidoÅ”anu par pilnvērtÄ«gu produktu.

Pēc Ŕī incidenta mēs attālinājāmies no Ŕīs idejas, taču mums joprojām bija sajÅ«ta, ka Ŕī problēma ir pilnÄ«bā atrisināma, un ieguvumi no Ŕāda risinājuma bija vairāk nekā acÄ«mredzami. Pēc tam ārvalstu kompāniju izlaistie HCI produkti tikai apstiprināja Å”o sajÅ«tu.

Tāpēc 2016. gada vidÅ« mēs atgriezāmies pie Ŕī uzdevuma pilnvērtÄ«ga produkta izveides ietvaros. TobrÄ«d mums vēl nebija nekādu attiecÄ«bu ar investoriem, tāpēc nācās iegādāties attÄ«stÄ«bas stendu par savu ne pārāk lielo naudu. Savācot lietotos serverus un Avito slēdžus, mēs ķērāmies pie lietas.

Hiperkonverģēts risinājums AERODISK VAIR. Pamats ir ARDFS failu sistēma

Galvenais sākotnējais uzdevums bija izveidot savu, lai arÄ« vienkārÅ”u, bet savu failu sistēmu, kas varētu automātiski un vienmērÄ«gi sadalÄ«t datus virtuālo bloku veidā uz n-to klastera mezglu skaitu, kas savienoti ar starpsavienojumu caur Ethernet. Tajā paŔā laikā FS ir labi un viegli jāmēro un jābÅ«t neatkarÄ«gai no blakus sistēmām, t.i. tikt atsveÅ”inātam no vAIR ā€œtikai glabātavasā€ veidā.

Hiperkonverģēts risinājums AERODISK VAIR. Pamats ir ARDFS failu sistēma

Pirmā vAIR koncepcija

Hiperkonverģēts risinājums AERODISK VAIR. Pamats ir ARDFS failu sistēma

Mēs apzināti atteicāmies no gatavu atvērtā koda risinājumu izmantoÅ”anas izstieptas uzglabāŔanas organizÄ“Å”anai (ceph, gluster, luster un tamlÄ«dzÄ«gi) par labu savai attÄ«stÄ«bai, jo mums jau bija liela projektu pieredze ar tiem. Protams, Å”ie risinājumi paÅ”i par sevi ir lieliski, un pirms darba pie Aerodisk mēs ar tiem Ä«stenojām ne vienu vien integrācijas projektu. Bet viena lieta ir Ä«stenot konkrētu uzdevumu vienam klientam, apmācÄ«t personālu un, iespējams, iegādāties liela pārdevēja atbalstu, un pavisam cita lieta ir izveidot viegli pavairotu produktu, kas tiks izmantots dažādiem uzdevumiem, ko mēs kā pārdevējs, iespējams, pat par sevi nezināsim. Otrajam mērÄ·im esoÅ”ie atvērtā koda produkti mums nebija piemēroti, tāpēc nolēmām paÅ”i izveidot izkliedētu failu sistēmu.
Divus gadus vēlāk vairāki izstrādātāji (kuri apvienoja darbu pie vAIR ar darbu pie klasiskās Engine uzglabāŔanas sistēmas) sasniedza noteiktu rezultātu.

LÄ«dz 2018. gadam bijām uzrakstÄ«juÅ”i vienkārÅ”u failu sistēmu un papildinājām to ar nepiecieÅ”amo aparatÅ«ru. Sistēma, izmantojot iekŔējo starpsavienojumu, apvienoja dažādu serveru fiziskos (lokālos) diskus vienā plakanā baseinā un ā€œsagriezaā€ virtuālos blokos, pēc tam no virtuālajiem blokiem tika izveidotas blokierÄ«ces ar dažādu kļūdu tolerances pakāpi, uz kurām tika izveidoti virtuālie. un izpildÄ«ts, izmantojot KVM hipervizora automaŔīnas.

Mēs pārāk neuztraucāmies ar failu sistēmas nosaukumu un īsi nosaucām to par ARDFS (uzminiet, ko tas apzīmē))

Å is prototips izskatÄ«jās labi (ne vizuāli, protams, vizuālā noformējuma vēl nebija) un uzrādÄ«ja labus rezultātus veiktspējas un mērogoÅ”anas ziņā. Pēc pirmā reālā rezultāta iedarbinājām Å”o projektu, organizējot pilnvērtÄ«gu izstrādes vidi un atseviŔķu komandu, kas nodarbojās tikai ar vAIR.

TieÅ”i lÄ«dz tam laikam bija nobriedusi risinājuma vispārējā arhitektÅ«ra, kas vēl nav piedzÄ«vojusi lielas izmaiņas.

NirÅ”ana ARDFS failu sistēmā

ARDFS ir vAIR pamats, kas nodroÅ”ina izkliedētu, kļūdu izturÄ«gu datu glabāŔanu visā klasterÄ«. Viena no (bet ne vienÄ«gā) ARDFS atŔķirÄ«gajām iezÄ«mēm ir tā, ka metadatiem un pārvaldÄ«bai netiek izmantoti papildu serveri. Sākotnēji tas tika izstrādāts, lai vienkārÅ”otu risinājuma konfigurāciju un nodroÅ”inātu tā uzticamÄ«bu.

UzglabāŔanas struktūra

Visos klastera mezglos ARDFS organizē loÄ£isko pÅ«lu no visas pieejamās diska vietas. Ir svarÄ«gi saprast, ka pÅ«ls vēl nav dati vai formatēta telpa, bet vienkārÅ”i iezÄ«mējums, t.i. Visi mezgli ar instalētu vAIR, kad tie tiek pievienoti klasterim, tiek automātiski pievienoti koplietotajam ARDFS pÅ«lam, un diska resursi tiek automātiski koplietoti visā klasterÄ« (un pieejami turpmākai datu glabāŔanai). Å Ä« pieeja ļauj pievienot un noņemt mezglus lidojumā, neradot nopietnas ietekmes uz jau darbojoÅ”os sistēmu. Tie. sistēmu ir ļoti viegli mērogot ā€œÄ·ieÄ£eļosā€, vajadzÄ«bas gadÄ«jumā pievienojot vai noņemot mezglus klasterÄ«.

Virtuālie diski (virtuālo maŔīnu uzglabāŔanas objekti) tiek pievienoti ARDFS pÅ«lam, kas ir veidoti no 4 megabaitu lieliem virtuālajiem blokiem. Virtuālie diski tieÅ”i glabā datus. Kļūdu pielaides shēma ir iestatÄ«ta arÄ« virtuālā diska lÄ«menÄ«.

Kā jÅ«s, iespējams, jau uzminējāt, diska apakÅ”sistēmas kļūdu tolerancei mēs neizmantojam RAID (neatkarÄ«go disku liekā masÄ«va) jēdzienu, bet gan RAIN (neatkarÄ«go mezglu lieks masÄ«vs). Tie. Kļūdu tolerance tiek mērÄ«ta, automatizēta un pārvaldÄ«ta, pamatojoties uz mezgliem, nevis diskiem. Diski, protams, ir arÄ« uzglabāŔanas objekts, tie, tāpat kā viss pārējais, tiek uzraudzÄ«ti, ar tiem var veikt visas standarta darbÄ«bas, tai skaitā salikt lokālo aparatÅ«ras RAID, bet klasteris darbojas tieÅ”i uz mezgliem.

Situācijā, kad jÅ«s patieŔām vēlaties RAID (piemēram, scenārijs, kas atbalsta vairākas kļūmes mazos klasteros), nekas neliedz jums izmantot vietējos RAID kontrollerus un izveidot papildu krātuvi un RAIN arhitektÅ«ru. Å is scenārijs ir diezgan aktuāls, un mēs to atbalstām, tāpēc mēs par to runāsim rakstā par tipiskiem vAIR izmantoÅ”anas scenārijiem.

Krātuves kļūdu tolerances shēmas

VAIR virtuālajiem diskiem var būt divas kļūdu pielaides shēmas:

1) Replikācijas faktors vai vienkārÅ”i replikācija - Ŕī defektu tolerances metode ir tikpat vienkārÅ”a kā nÅ«ja un virve. Sinhronā replikācija tiek veikta starp mezgliem ar koeficientu 2 (attiecÄ«gi 2 kopijas katrā klasterÄ«) vai 3 (attiecÄ«gi 3 kopijas). RF-2 ļauj virtuālajam diskam izturēt viena klastera mezgla atteici, bet ā€œapēdā€ pusi no lietderÄ«gā apjoma, un RF-3 izturēs 2 klastera mezglu atteici, bet rezervē 2/3 no kopas. noderÄ«gs apjoms tās vajadzÄ«bām. Å Ä« shēma ir ļoti lÄ«dzÄ«ga RAID-1, tas ir, virtuālais disks, kas konfigurēts RF-2, ir izturÄ«gs pret jebkura klastera mezgla atteici. Å ajā gadÄ«jumā ar datiem viss bÅ«s kārtÄ«bā un pat I/O neapstāsies. Kad krituÅ”ais mezgls atgriežas darbā, sāksies automātiska datu atkopÅ”ana/sinhronizācija.

Tālāk ir sniegti RF-2 un RF-3 datu sadales piemēri normālā režīmā un kļūmes situācijā.

Mums ir virtuālā maŔīna ar 8MB unikālu (noderÄ«gu) datu ietilpÄ«bu, kas darbojas 4 vAIR mezglos. Skaidrs, ka reāli maz ticams, ka bÅ«s tik mazs apjoms, bet shēmai, kas atspoguļo ARDFS darbÄ«bas loÄ£iku, Å”is piemērs ir saprotamākais. AB ir 4 MB virtuālie bloki, kas satur unikālus virtuālās maŔīnas datus. RF-2 izveido attiecÄ«gi divas Å”o bloku kopijas A1+A2 un B1+B2. Å ie bloki ir ā€œizkārtotiā€ pa mezgliem, izvairoties no to paÅ”u datu krustoÅ”anās tajā paŔā mezglā, tas ir, kopija A1 neatradÄ«sies tajā paŔā mezglā, kur kopija A2. Tas pats ar B1 un B2.

Hiperkonverģēts risinājums AERODISK VAIR. Pamats ir ARDFS failu sistēma

Ja kāds no mezgliem neizdodas (piemēram, mezgls Nr. 3, kurā ir B1 kopija), Ŕī kopija tiek automātiski aktivizēta mezglā, kur nav tā kopijas (tas ir, B2 kopija).

Hiperkonverģēts risinājums AERODISK VAIR. Pamats ir ARDFS failu sistēma

Tādējādi virtuālais disks (un attiecīgi VM) var viegli pārdzīvot viena mezgla kļūmi RF-2 shēmā.

Replikācijas shēma, lai arÄ« vienkārÅ”a un uzticama, cieÅ” no tās paÅ”as problēmas kā RAID1 ā€” nav pietiekami daudz izmantojamās vietas.

2) Lai atrisinātu iepriekÅ” minēto problēmu, pastāv dzÄ“Å”anas kodÄ“Å”ana vai dzÄ“Å”anas kodÄ“Å”ana (pazÄ«stama arÄ« kā ā€œlieka kodÄ“Å”anaā€, ā€œdzÄ“Å”anas kodÄ“Å”anaā€ vai ā€œredundances kodsā€). EC ir atlaiÅ”anas shēma, kas nodroÅ”ina augstu datu pieejamÄ«bu ar mazāku diska vietas pieskaitāmo slodzi, salÄ«dzinot ar replikāciju. Å Ä« mehānisma darbÄ«bas princips ir lÄ«dzÄ«gs RAID 5, 6, 6P.

Kodējot, EC process sadala virtuālo bloku (pēc noklusējuma 4 MB) vairākos mazākos "datu gabalos" atkarÄ«bā no EC shēmas (piemēram, shēma 2+1 sadala katru 4 MB bloku 2 2 MB gabalos). Pēc tam Å”is process Ä£enerē "datu gabaliem" "paritātes gabalus", kas nav lielāki par vienu no iepriekÅ” sadalÄ«tajām daļām. Dekodējot, EC Ä£enerē trÅ«kstoÅ”os gabalus, nolasot ā€œizdzÄ«vojuÅ”osā€ datus visā klasterÄ«.

Piemēram, virtuālais disks ar 2 + 1 EC shēmu, kas ieviests 4 klastera mezglos, viegli izturēs viena klastera mezgla atteici tāpat kā RF-2. Å ajā gadÄ«jumā pieskaitāmās izmaksas bÅ«s zemākas, jo Ä«paÅ”i lietderÄ«gās jaudas koeficients RF-2 ir 2, bet EC 2+1 tas bÅ«s 1,5.

Lai to aprakstÄ«tu vienkārŔāk, bÅ«tÄ«ba ir tāda, ka virtuālais bloks ir sadalÄ«ts 2-8 (kāpēc no 2 lÄ«dz 8, skatÄ«t zemāk) ā€œgabalosā€, un Å”iem gabaliem tiek aprēķināti lÄ«dzÄ«ga tilpuma paritātes ā€œgabaliā€.

Rezultātā dati un paritāte tiek vienmērÄ«gi sadalÄ«ti visos klastera mezglos. Tajā paŔā laikā, tāpat kā replikācijas gadÄ«jumā, ARDFS automātiski sadala datus pa mezgliem tā, lai novērstu identisku datu (datu kopiju un to paritātes) glabāŔanu tajā paŔā mezglā, lai novērstu datu zaudÄ“Å”anas iespēju. uz to, ka dati un to paritāte pēkŔņi nonāks vienā krātuves mezglā, kas neizdodas.

Zemāk ir piemērs ar to paÅ”u 8 MB virtuālo maŔīnu un 4 mezgliem, bet ar EC 2+1 shēmu.

Bloki A un B ir sadalÄ«ti divos gabalos pa 2 MB katrs (divos, jo 2+1), tas ir, A1+A2 un B1+B2. AtŔķirÄ«bā no replikas, A1 nav A2 kopija, tas ir virtuāls bloks A, sadalÄ«ts divās daļās, tas pats ar bloku B. Kopumā mēs iegÅ«stam divus 4 MB komplektus, no kuriem katrs satur divus divu MB gabalus. Tālāk katrai no Ŕīm kopām paritāti aprēķina ar tilpumu ne vairāk kā vienu gabalu (t.i., 2 MB), iegÅ«stam papildu + 2 paritātes vienÄ«bas (AP un BP). Kopumā mums ir 4 Ɨ 2 dati + 2 Ɨ 2 paritāte.

Pēc tam gabali tiek ā€œizkārtotiā€ starp mezgliem, lai dati nekrustotos ar to paritāti. Tie. A1 un A2 neatradÄ«sies tajā paŔā mezglā, kur AP.

Hiperkonverģēts risinājums AERODISK VAIR. Pamats ir ARDFS failu sistēma

Viena mezgla (piemēram, arÄ« treŔā) atteices gadÄ«jumā nokrituÅ”ais bloks B1 tiks automātiski atjaunots no BP paritātes, kas glabājas mezglā Nr.2, un tiks aktivizēts tajā mezglā, kurā atrodas. nav B paritātes, t.i. BP gabals. Å ajā piemērā tas ir mezgls Nr. 1

Hiperkonverģēts risinājums AERODISK VAIR. Pamats ir ARDFS failu sistēma

Esmu pārliecināts, ka lasītājam ir jautājums:

ā€œVisu, ko jÅ«s aprakstÄ«jāt, jau sen ir ieviesuÅ”i gan konkurenti, gan atvērtā pirmkoda risinājumos. Kāda ir atŔķirÄ«ba starp jÅ«su EC ievieÅ”anu ARDFS?ā€

Un tad būs interesantas ARDFS iespējas.

DzÄ“Å”anas kodÄ“Å”ana, koncentrējoties uz elastÄ«bu

Sākotnēji mēs nodroÅ”inājām diezgan elastÄ«gu EK X+Y shēmu, kur X ir vienāds ar skaitli no 2 lÄ«dz 8, un Y ir vienāds ar skaitli no 1 lÄ«dz 8, bet vienmēr ir mazāks vai vienāds ar X. Å Ä« shēma ir nodroÅ”ināta elastÄ«bas labad. Datu vienÄ«bu (X) skaita palielināŔana, kurās tiek sadalÄ«ts virtuālais bloks, ļauj samazināt pieskaitāmās izmaksas, tas ir, palielināt izmantojamo platÄ«bu.
Palielinot paritātes gabalu (Y) skaitu, palielinās virtuālā diska uzticamÄ«ba. Jo lielāka ir Y vērtÄ«ba, jo vairāk mezglu klasterÄ« var neizdoties. Protams, paritātes apjoma palielināŔana samazina izmantojamās jaudas apjomu, taču tā ir cena, kas jāmaksā par uzticamÄ«bu.

Veiktspējas atkarÄ«ba no EK shēmām ir gandrÄ«z tieÅ”a: jo vairāk ā€œgabaluā€, jo zemāka veiktspēja; Å”eit, protams, ir nepiecieÅ”ams lÄ«dzsvarots skatÄ«jums.

Šī pieeja ļauj administratoriem maksimāli elastīgi konfigurēt izstieptu krātuvi. ARDFS baseina ietvaros var izmantot jebkuras defektu tolerances shēmas un to kombinācijas, kas, mūsuprāt, arī ir ļoti noderīgi.

Zemāk ir tabula, kurā salīdzinātas vairākas (ne visas iespējamās) RF un EK shēmas.

Hiperkonverģēts risinājums AERODISK VAIR. Pamats ir ARDFS failu sistēma

Tabulā redzams, ka pat ā€œfrotēā€ kombinācija EC 8+7, kas ļauj vienlaicÄ«gi zaudēt lÄ«dz pat 7 mezgliem klasterÄ«, ā€œapēdā€ mazāk izmantojamās vietas (1,875 pret 2) nekā standarta replikācija un aizsargā 7 reizes labāk. , kas padara Å”o aizsardzÄ«bas mehānismu, lai arÄ« sarežģītāku, daudz pievilcÄ«gāku situācijās, kad nepiecieÅ”ams nodroÅ”ināt maksimālu uzticamÄ«bu ierobežotas diska vietas apstākļos. Tajā paŔā laikā jums ir jāsaprot, ka katrs ā€œplussā€ X vai Y bÅ«s papildu veiktspējas izmaksas, tāpēc trÄ«sstÅ«rÄ« starp uzticamÄ«bu, ietaupÄ«jumiem un veiktspēju jums ir jāizvēlas ļoti rÅ«pÄ«gi. Å Ä« iemesla dēļ mēs veltÄ«sim atseviŔķu rakstu dzÄ“Å”anas kodÄ“Å”anas izmēra noteikÅ”anai.

Hiperkonverģēts risinājums AERODISK VAIR. Pamats ir ARDFS failu sistēma

Failu sistēmas uzticamība un autonomija

ARDFS darbojas lokāli visos klastera mezglos un sinhronizē tos, izmantojot savus lÄ«dzekļus, izmantojot speciālas Ethernet saskarnes. SvarÄ«gi ir tas, ka ARDFS neatkarÄ«gi sinhronizē ne tikai datus, bet arÄ« ar uzglabāŔanu saistÄ«tos metadatus. Strādājot pie ARDFS, mēs vienlaikus pētÄ«jām vairākus esoÅ”os risinājumus un atklājām, ka daudzi failu sistēmas meta sinhronizē, izmantojot ārēju izplatÄ«tu DBVS, ko arÄ« izmantojam sinhronizÄ“Å”anai, bet tikai konfigurācijas, nevis FS metadatus (par Å”o un citām saistÄ«tām apakÅ”sistēmām nākamajā rakstā).

FS metadatu sinhronizÄ“Å”ana, izmantojot ārēju DBVS, protams, ir darbojoÅ”s risinājums, taču tad ARDFS saglabāto datu konsekvence bÅ«tu atkarÄ«ga no ārējās DBVS un tās uzvedÄ«bas (un, atklāti sakot, tā ir kaprÄ«za dāma), kas mÅ«su viedoklis ir slikts. Kāpēc? Ja FS metadati tiek bojāti, arÄ« paÅ”iem FS datiem var teikt ā€œardievuā€, tāpēc mēs nolēmām izvēlēties sarežģītāku, bet uzticamāku ceļu.

Mēs paÅ”i izveidojām ARDFS metadatu sinhronizācijas apakÅ”sistēmu, un tā darbojas pilnÄ«gi neatkarÄ«gi no blakus esoÅ”ajām apakÅ”sistēmām. Tie. neviena cita apakÅ”sistēma nevar sabojāt ARDFS datus. MÅ«suprāt, tas ir visuzticamākais un pareizākais veids, taču laiks rādÄ«s, vai tas tā ir. Turklāt Å”ai pieejai ir papildu priekÅ”rocÄ«ba. ARDFS var izmantot neatkarÄ«gi no vAIR, tāpat kā izstieptu krātuvi, ko mēs noteikti izmantosim turpmākajos produktos.

Rezultātā, attÄ«stot ARDFS, mēs saņēmām elastÄ«gu un uzticamu failu sistēmu, kas ļauj izvēlēties, kur ietaupÄ«t uz jaudu vai atteikties no visa veiktspējas, vai izveidot Ä«paÅ”i uzticamu krātuvi par saprātÄ«gām izmaksām, bet samazinot veiktspējas prasÄ«bas.

Kopā ar vienkārÅ”u licencÄ“Å”anas politiku un elastÄ«gu piegādes modeli (skatoties uz nākotni, vAIR licencē mezgls un tiek piegādāts vai nu kā programmatÅ«ra, vai kā programmatÅ«ras pakotne), tas ļauj ļoti precÄ«zi pielāgot risinājumu dažādām klientu prasÄ«bām un prasÄ«bām. tad viegli saglabāt Å”o lÄ«dzsvaru.

Kam vajadzīgs Ŕis brīnums?

No vienas puses, mēs varam teikt, ka tirgÅ« jau ir spēlētāji, kuriem ir nopietni risinājumi hiperkonverÄ£ences jomā, un tas ir tas, kur mēs patiesÄ«bā virzāmies. Å Ä·iet, ka Å”is apgalvojums ir patiess, BET...

Savukārt, izejot laukos un komunicējot ar klientiem, mēs un mÅ«su partneri redzam, ka tas tā nebÅ«t nav. HiperkonverÄ£ences uzdevumu ir daudz, vietām cilvēki vienkārÅ”i nezināja, ka Ŕādi risinājumi pastāv, citur Ŕķita dārgi, citviet bija neveiksmÄ«gi alternatÄ«vu risinājumu testi, bet citās sankciju dēļ vispār aizliedz pirkt. Kopumā lauks izrādÄ«jās neuzarts, tāpēc mēs devāmies audzēt neapstrādātu augsni))).

Kad uzglabāŔanas sistēma ir labāka par GCS?

Strādājot ar tirgu, mums bieži tiek jautāts, kad labāk ir izmantot klasisko shēmu ar uzglabāŔanas sistēmām un kad izmantot hiperkonverÄ£entu? Daudzi uzņēmumi, kas ražo GCS (Ä«paÅ”i tie, kuru portfelÄ« nav uzglabāŔanas sistēmu), saka: "UzglabāŔanas sistēmas kļūst novecojuÅ”as, tikai hiperkonverģētas!" Tas ir drosmÄ«gs paziņojums, taču tas pilnÄ«bā neatspoguļo realitāti.

PatiesÄ«bā uzglabāŔanas tirgus patieŔām virzās uz hiperkonverÄ£enci un lÄ«dzÄ«giem risinājumiem, taču vienmēr ir ā€œbetā€.

Pirmkārt, datu centrus un IT infrastruktÅ«ras, kas uzbÅ«vētas pēc klasiskās shēmas ar uzglabāŔanas sistēmām, nav viegli pārbÅ«vēt, tāpēc Ŕādu infrastruktÅ«ru modernizācija un pabeigÅ”ana joprojām ir mantojums uz 5-7 gadiem.

Otrkārt, infrastruktÅ«ra, kas Å”obrÄ«d tiek bÅ«vēta lielākoties (ar to domāta Krievijas Federācija), ir veidota pēc klasiskās shēmas, izmantojot uzglabāŔanas sistēmas, un nevis tāpēc, ka cilvēki nezinātu par hiperkonverÄ£enci, bet gan tāpēc, ka hiperkonverÄ£ences tirgus ir jauns, risinājumi un standarti vēl nav noteikti , IT cilvēki vēl nav apmācÄ«ti, viņiem ir maz pieredzes, bet datu centri jābÅ«vē Å”eit un tagad. Un Ŕī tendence turpināsies vēl 3-5 gadus (un pēc tam vēl viens mantojums, skatÄ«t 1. punktu).

TreÅ”kārt, pastāv tÄ«ri tehnisks ierobežojums papildu nelielai aizkavei 2 milisekundes katrā ierakstā (protams, izņemot vietējo keÅ”atmiņu), kas ir sadalÄ«tās krātuves izmaksas.

NeaizmirsÄ«sim par lielu fizisko serveru izmantoÅ”anu, kuriem patÄ«k diska apakÅ”sistēmas vertikālā mērogoÅ”ana.

Ir daudzi nepiecieÅ”ami un populāri uzdevumi, kuros uzglabāŔanas sistēmas darbojas labāk nekā GCS. Å eit, protams, tie ražotāji, kuru produktu portfelÄ« nav uzglabāŔanas sistēmu, mums nepiekritÄ«s, taču mēs esam gatavi pamatoti strÄ«dēties. Protams, mēs kā abu produktu izstrādātāji noteikti salÄ«dzināsim uzglabāŔanas sistēmas un GCS kādā no mÅ«su turpmākajām publikācijām, kur uzskatāmi parādÄ«sim, kura pie kādiem nosacÄ«jumiem ir labāka.

Un kur hiperkonverģētie risinājumi darbosies labāk nekā uzglabāŔanas sistēmas?

Pamatojoties uz iepriekÅ”minētajiem punktiem, var izdarÄ«t trÄ«s acÄ«mredzamus secinājumus:

  1. Ja papildu 2 milisekundes ieraksta latentums, kas konsekventi notiek jebkurā produktā (tagad nerunājam par sintētiku, nanosekundes var uzrādīt uz sintētikas), ir nekritisks, ir piemērots hiperkonverģents.
  2. Ja slodzi no lieliem fiziskajiem serveriem var pārvērst daudzos mazos virtuālos un sadalīt pa mezgliem, arī tur labi darbosies hiperkonverģence.
  3. Ja horizontālā mērogoÅ”ana ir augstāka prioritāte nekā vertikālā mērogoÅ”ana, GCS arÄ« tur darbosies lieliski.

Kādi ir Ŕie risinājumi?

  1. Visi standarta infrastruktÅ«ras pakalpojumi (direktoriju pakalpojums, pasts, EDMS, failu serveri, mazas vai vidējas ERP un BI sistēmas utt.). Mēs to saucam par "vispārējo skaitļoÅ”anu".
  2. Mākoņpakalpojumu sniedzēju infrastruktÅ«ra, kur nepiecieÅ”ams ātri un standartizēti horizontāli paplaÅ”ināt un ērti ā€œizgrieztā€ lielu skaitu virtuālo maŔīnu klientiem.
  3. Virtuālās darbvirsmas infrastruktÅ«ra (VDI), kurā darbojas daudzas mazas lietotāju virtuālās maŔīnas un mierÄ«gi ā€œpeldā€ vienotā klasterÄ«.
  4. Filiāles tÄ«kli, kur katrai filiālei ir nepiecieÅ”ama standarta, defektu izturÄ«ga, bet lēta infrastruktÅ«ra no 15-20 virtuālajām maŔīnām.
  5. Jebkura izplatÄ«ta skaitļoÅ”ana (piemēram, lielo datu pakalpojumi). Kur slodze iet nevis ā€œdziļumāā€, bet ā€œplatumāā€.
  6. Testa vides, kurās ir pieļaujama papildu neliela aizkave, bet ir budžeta ierobežojumi, jo tie ir testi.

Å obrÄ«d tieÅ”i Å”iem uzdevumiem esam izveidojuÅ”i AERODISK vAIR un tieÅ”i uz tiem koncentrējamies (pagaidām veiksmÄ«gi). VarbÅ«t tas drÄ«z mainÄ«sies, jo... pasaule nestāv uz vietas.

Tātad ...

Tas noslēdz pirmo daļu lielai rakstu sērijai; nākamajā rakstā mēs runāsim par risinājuma arhitektūru un izmantotajiem komponentiem.

Gaidām jautājumus, ieteikumus un konstruktīvus strīdus.

Avots: www.habr.com

Pievieno komentāru