Halo, para pembaca Habr. Kanthi artikel iki kita mbukak seri sing bakal ngomong babagan sistem hyperconverged AERODISK vAIR sing wis dikembangake. Kaping pisanan, kita pengin ngandhani kabeh babagan kabeh ing artikel pisanan, nanging sistem kasebut cukup rumit, mula kita bakal mangan gajah ing bagean.
Ayo miwiti crita kanthi sejarah nggawe sistem kasebut, goleki sistem file ARDFS, sing dadi basis saka vAIR, lan uga ngomong sethithik babagan posisi solusi iki ing pasar Rusia.
Ing artikel sabanjure kita bakal ngomong kanthi luwih rinci babagan komponen arsitektur sing beda-beda (cluster, hypervisor, load balancer, sistem pemantauan, lan liya-liyane), proses konfigurasi, ningkatake masalah lisensi, kanthi kapisah nuduhake tes kacilakan lan, mesthi, nulis babagan tes beban lan ukuran. Kita uga bakal nyawisake artikel sing kapisah kanggo vAIR versi komunitas.
Apa Aerodisk crita babagan sistem panyimpenan? Utawa kenapa kita miwiti nindakake hyperconvergence ing wiwitan?
Kaping pisanan, ide kanggo nggawe hiperkonvergensi kita teka ing endi wae ing sekitar taun 2010. Ing wektu iku, ora ana Aerodisk utawa solusi sing padha (kotak komersial sistem hyperconverged) ing pasar. Tugas kita yaiku ing ngisor iki: saka set server karo disk lokal, digabungake kanthi interkoneksi liwat protokol Ethernet, perlu kanggo nggawe panyimpenan lengkap lan miwiti mesin virtual lan jaringan piranti lunak ing kana. Kabeh iki kudu dileksanakake tanpa sistem panyimpenan (amarga ora ana dhuwit kanggo sistem panyimpenan lan hardware, lan kita durung nemokke sistem panyimpenan dhewe).
Kita nyoba akeh solusi open source lan pungkasane ngrampungake masalah iki, nanging solusi kasebut rumit banget lan angel diulang maneh. Kajaba iku, solusi iki ana ing kategori "Apa kerjane? Aja ndemek! Mula, sawise ngrampungake masalah kasebut, kita ora ngembangake ide kanggo ngowahi asil karya dadi produk lengkap.
Sawise kedadeyan kasebut, kita pindhah saka gagasan iki, nanging kita isih duwe perasaan yen masalah iki bisa dipecahake, lan keuntungan saka solusi kasebut luwih jelas. Salajengipun, produk HCI perusahaan manca sing dirilis mung dikonfirmasi perasaan iki.
Mulane, ing pertengahan 2016, kita bali menyang tugas iki minangka bagéan saka nggawe produk lengkap. Ing wektu iku kita durung duwe hubungan apa-apa karo investor, supaya kita kudu tuku pembangunan stand kanggo dhuwit kita ora amba banget. Sawise nglumpukake server sing digunakake lan ngalih ing Avito, kita entuk bisnis.
Tugas dhisikan utama yaiku nggawe sistem file dhewe, sanajan prasaja, nanging bisa disebarake kanthi otomatis lan merata ing wangun pamblokiran virtual ing nomer nth simpul kluster, sing disambungake dening interconnect liwat Ethernet. Ing wektu sing padha, FS kudu ukuran apik lan gampang lan bebas saka sistem jejer, i.e. dipisahake saka vAIR ing wangun "mung fasilitas panyimpenan".
Konsep vAIR pisanan
Kita sengaja nglirwakake panggunaan solusi open source sing wis siap kanggo ngatur panyimpenan dowo (ceph, gluster, luster lan liya-liyane) kanggo pangembangan kita dhewe, amarga kita wis duwe akeh pengalaman proyek karo dheweke. Mesthine, solusi kasebut dhewe apik banget, lan sadurunge nggarap Aerodisk, kita ngetrapake luwih saka siji proyek integrasi karo dheweke. Nanging siji bab kanggo ngleksanakake tugas tartamtu kanggo siji customer, Sepur Staff lan, mbok menawa, tuku dhukungan saka vendor gedhe, lan cukup liyane kanggo nggawe produk gampang replicated sing bakal digunakake kanggo macem-macem tugas, kang kita, minangka a vendor, malah bisa ngerti bab awake dhewe kita ora bakal. Kanggo tujuan kapindho, produk open source sing ana ora cocog kanggo kita, mula kita mutusake nggawe sistem file sing disebarake dhewe.
Rong taun sabanjure, sawetara pangembang (sing nggabungake karya ing vAIR karo karya ing sistem panyimpenan Engine klasik) entuk asil tartamtu.
Ing taun 2018, kita wis nulis sistem file sing gampang lan ditambah karo piranti keras sing dibutuhake. Sistem kasebut nggabungake disk fisik (lokal) saka server sing beda-beda dadi siji blumbang datar liwat interkoneksi internal lan "potong" dadi blok virtual, banjur mblokir piranti kanthi tingkat toleransi kesalahan sing beda-beda digawe saka blok virtual, sing digawe virtual. lan dieksekusi nggunakake mobil hypervisor KVM.
Kita ora keganggu banget karo jeneng sistem file lan kanthi ringkes diarani ARDFS (tebak apa tegese))
Prototipe iki katon apik (ora visual, mesthi, durung ana desain visual) lan nuduhake asil sing apik babagan kinerja lan skala. Sawise asil nyata pisanan, kita nyetel proyek iki ing gerakan, ngatur lingkungan pembangunan lengkap lan tim kapisah sing mung urusan karo vAIR.
Mung wektu iku, arsitektur umum solusi wis diwasa, sing durung ngalami owah-owahan gedhe.
Nyilem menyang sistem file ARDFS
ARDFS minangka pondasi saka vAIR, sing nyedhiyakake panyimpenan data sing disebarake lan tahan kesalahan ing kabeh kluster. Salah siji (nanging ora mung) fitur khas ARDFS yaiku ora nggunakake server khusus tambahan kanggo metadata lan manajemen. Iki wiwitane disusun kanggo nyederhanakake konfigurasi solusi lan linuwih.
Struktur panyimpenan
Ing kabeh simpul kluster, ARDFS ngatur blumbang logis saka kabeh ruang disk sing kasedhiya. Iku penting kanggo ngerti sing blumbang durung data utawa spasi format, nanging mung markup, i.e. Sembarang simpul karo vAIR diinstal, nalika ditambahake menyang kluster, kanthi otomatis ditambahake menyang ARDFS blumbang lan sumber disk sing dienggo bareng kanthi otomatis dadi bareng ing kabeh kluster (lan kasedhiya kanggo panyimpenan data ing mangsa ngarep). Pendekatan iki ngidini sampeyan nambah lan mbusak kelenjar ing fly tanpa impact serius ing sistem wis mlaku. Sing. sistem gampang banget kanggo ukuran "ing bata", nambah utawa mbusak kelenjar ing kluster yen perlu.
Disk virtual (obyek panyimpenan kanggo mesin virtual) ditambahake ing ndhuwur blumbang ARDFS, sing dibangun saka blok virtual kanthi ukuran 4 megabyte. Disk virtual langsung nyimpen data. Skema toleransi kesalahan uga disetel ing tingkat disk virtual.
Nalika sampeyan bisa uga wis guessed, kanggo toleransi fault saka subsistem disk, kita ora nggunakake konsep RAID (Redundant array of independen Disks), nanging nggunakake RAIN (Redundant array of independen Nodes). Sing. Toleransi kesalahan diukur, otomatis, lan dikelola adhedhasar simpul, dudu disk. Disk, mesthi, uga obyek panyimpenan, padha, kaya kabeh liya, teliti, sampeyan bisa nindakake kabeh operasi standar karo wong-wong mau, kalebu assembling RAID hardware lokal, nanging kluster makaryakke khusus ing kelenjar.
Ing kahanan sing pengin banget RAID (Contone, skenario sing ndhukung macem-macem gagal ing kelompok cilik), ora ana sing ngalangi sampeyan nggunakake kontrol RAID lokal, lan mbangun panyimpenan dowo lan arsitektur RAIN ing ndhuwur. Skenario iki cukup urip lan didhukung dening kita, mula kita bakal ngomong babagan iki ing artikel babagan skenario khas kanggo nggunakake vAIR.
Skema Toleransi Fault Panyimpenan
Bisa uga ana rong skema toleransi kesalahan kanggo disk virtual ing vAIR:
1) Faktor replikasi utawa mung replikasi - cara toleransi kesalahan iki gampang kaya tongkat lan tali. Replikasi sinkron ditindakake ing antarane simpul kanthi faktor 2 (2 salinan saben kluster) utawa 3 (3 salinan, masing-masing). RF-2 ngidini disk virtual kanggo nahan kegagalan siji simpul ing kluster, nanging "mangan" setengah saka volume migunani, lan RF-3 bakal tahan gagal 2 kelenjar ing kluster, nanging cadangan 2/3 saka volume migunani kanggo kabutuhan sawijining. Skema iki meh padha karo RAID-1, yaiku, disk virtual sing dikonfigurasi ing RF-2 tahan kanggo kegagalan siji simpul ing kluster. Ing kasus iki, kabeh bakal nggoleki data lan malah I / O ora bakal mandheg. Nalika simpul tiba bali menyang layanan, Recovery data otomatis / sinkronisasi bakal miwiti.
Ing ngisor iki conto distribusi data RF-2 lan RF-3 ing mode normal lan ing kahanan gagal.
Kita duwe mesin virtual kanthi kapasitas 8MB data unik (migunani), sing nganggo 4 simpul vAIR. Cetha yen ing kasunyatan, ora ana volume cilik, nanging kanggo skema sing nggambarake logika operasi ARDFS, conto iki paling bisa dingerteni. AB minangka blok virtual 4MB sing ngemot data mesin virtual sing unik. RF-2 nggawe rong salinan blok kasebut A1 + A2 lan B1 + B2, masing-masing. Blok kasebut "ditata" ing simpul, ngindhari persimpangan data sing padha ing simpul sing padha, yaiku, salinan A1 ora bakal ana ing simpul sing padha karo salinan A2. Padha karo B1 lan B2.
Yen salah siji simpul gagal (contone, simpul No. 3, sing ngemot salinan B1), salinan iki kanthi otomatis diaktifake ing simpul sing ora ana salinan salinane (yaiku salinan B2).
Mangkono, disk virtual (lan VM, miturut) bisa gampang urip Gagal siji simpul ing skema RF-2.
Skema replikasi, nalika prasaja lan dipercaya, nandhang masalah sing padha karo RAID1 - papan sing ora bisa digunakake.
2) Erasure coding utawa erasure coding (uga dikenal minangka "redundant coding", "erasure coding" utawa "redundansi kode") ana kanggo ngatasi masalah ing ndhuwur. EC minangka skema redundansi sing nyedhiyakake kasedhiyan data dhuwur kanthi overhead spasi disk sing luwih murah tinimbang replikasi. Prinsip operasi mekanisme iki padha karo RAID 5, 6, 6P.
Nalika enkoding, proses EC mbagi blok virtual (4MB minangka standar) dadi sawetara "potongan data" sing luwih cilik gumantung saka skema EC (contone, skema 2 + 1 mbagi saben blok 4MB dadi 2 potongan 2MB). Sabanjure, proses iki ngasilake "potongan paritas" kanggo "potongan data" sing ora luwih gedhe tinimbang salah sawijining bagean sing dipérang sadurunge. Nalika dekoding, EC ngasilake potongan sing ilang kanthi maca data "slamet" ing kabeh kluster.
Contone, disk virtual kanthi skema 2 + 1 EC, dileksanakake ing 4 kelenjar kluster, bakal gampang nahan kegagalan siji simpul ing kluster kanthi cara sing padha karo RF-2. Ing kasus iki, biaya overhead bakal luwih murah, utamane, koefisien kapasitas migunani kanggo RF-2 yaiku 2, lan kanggo EC 2 + 1 bakal dadi 1,5.
Kanggo njlèntrèhaké luwih gampang, intine yaiku blok virtual dipérang dadi 2-8 (kok saka 2 nganti 8, ndeleng ngisor) "potongan", lan kanggo potongan kasebut "potongan" paritas volume sing padha diitung.
Akibaté, data lan paritas disebarake kanthi rata ing kabeh simpul kluster. Ing wektu sing padha, kaya replikasi, ARDFS kanthi otomatis nyebarake data ing antarane simpul kanthi cara kanggo nyegah data sing padha (salinan data lan paritas) disimpen ing simpul sing padha, supaya bisa ngilangi kemungkinan kelangan data amarga kanggo kasunyatan sing data lan paritas sing dumadakan bakal mungkasi munggah ing siji simpul panyimpenan sing gagal.
Ing ngisor iki conto, karo padha 8 MB mesin virtual lan 4 kelenjar, nanging karo EC 2 + 1 rencana.
Blok A lan B dipérang dadi rong bêsik saben 2 MB (loro amarga 2+1), yaiku, A1+A2 lan B1+B2. Boten kados tiron, A1 dudu salinan A2, iku pamblokiran virtual A, dipérang dadi rong bagéan, padha karo pamblokiran B. Ing total, kita entuk rong set 4MB, sing saben ngemot rong potongan rong MB. Sabanjure, kanggo saben set kasebut, paritas diitung kanthi volume ora luwih saka siji potong (yaiku 2 MB), entuk tambahan + 2 paritas (A-P lan B-P). Total kita duwe 4 × 2 data + 2 × 2 paritas.
Sabanjure, potongan-potongan kasebut "ditata" ing simpul supaya data ora intersect karo paritas. Sing. A1 lan A2 ora bakal dumunung ing simpul sing padha karo A-P.
Yen gagal siji simpul (contone, uga katelu), blok B1 sing tiba bakal dibalekake kanthi otomatis saka paritas B-P, sing disimpen ing simpul No.. 2, lan bakal diaktifake ing simpul sing ana. ora B-paritas, i.e. bagean B-P. Ing conto iki, iki simpul No
Aku yakin sing maca duwe pitakonan:
"Kabeh sing sampeyan jelasake wis suwe ditindakake dening pesaing lan ing solusi sumber terbuka, apa bedane antarane implementasi EC ing ARDFS?"
Banjur bakal ana fitur menarik saka ARDFS.
Mbusak coding kanthi fokus ing keluwesan
Kaping pisanan, kita nyedhiyakake skema EC X + Y sing cukup fleksibel, ing ngendi X padha karo angka saka 2 nganti 8, lan Y padha karo angka saka 1 nganti 8, nanging tansah kurang saka utawa padha karo X. Skema iki diwenehake kanggo keluwesan. Nambah jumlah potongan data (X) sing dibagi blok virtual ngidini ngurangi biaya overhead, yaiku, nambah papan sing bisa digunakake.
Nambah jumlah potongan paritas (Y) nambah linuwih disk virtual. Sing luwih gedhe nilai Y, luwih akeh simpul ing kluster bisa gagal. Mesthine, nambah volume paritas nyuda jumlah kapasitas sing bisa digunakake, nanging iki minangka rega sing kudu dibayar kanggo linuwih.
Katergantungan kinerja ing sirkuit EC meh langsung: luwih akeh "potongan", kinerja sing luwih murah, ing kene, mesthine, tampilan sing seimbang dibutuhake.
Pendekatan iki ngidini pangurus ngatur panyimpenan sing dawa kanthi keluwesan maksimal. Ing blumbang ARDFS, sampeyan bisa nggunakake skema toleransi kesalahan lan kombinasi, sing, miturut pendapat kita, uga migunani banget.
Ing ngisor iki tabel sing mbandhingake sawetara (ora kabeh bisa) skema RF lan EC.
Tabel nuduhake yen kombinasi paling "terry" EC 8 + 7, sing ngidini ilang nganti 7 kelenjar ing kluster bebarengan, "mangan" papan sing kurang bisa digunakake (1,875 mungsuh 2) tinimbang replikasi standar, lan nglindhungi 7 kaping luwih apik. , sing ndadekake mekanisme proteksi iki, sanajan luwih rumit, luwih atraktif ing kahanan sing perlu kanggo njamin linuwih maksimal ing kahanan ruang disk sing winates. Ing wektu sing padha, sampeyan kudu ngerti yen saben "plus" menyang X utawa Y bakal dadi overhead kinerja tambahan, supaya ing segitiga antarane linuwih, tabungan lan kinerja sampeyan kudu milih kanthi teliti. Mulane, kita bakal nyawisake artikel sing kapisah kanggo mbusak ukuran coding.
Reliabilitas lan otonomi sistem file
ARDFS lumaku sacara lokal ing kabeh kelenjar kluster lan nyinkronake kanthi nggunakake cara dhewe liwat antarmuka Ethernet khusus. Titik penting iku ARDFS independen nyinkronake ora mung data, nanging uga metadata related kanggo panyimpenan. Nalika nggarap ARDFS, kita bebarengan nyinaoni sawetara solusi sing wis ana lan kita nemokake manawa akeh sing nyinkronake meta sistem file nggunakake DBMS sing disebarake eksternal, sing uga digunakake kanggo sinkronisasi, nanging mung konfigurasi, dudu metadata FS (babagan iki lan subsistem liyane sing gegandhengan. ing artikel sabanjure).
Nyinkronake metadata FS nggunakake DBMS eksternal, mesthi, minangka solusi sing bisa digunakake, nanging banjur konsistensi data sing disimpen ing ARDFS bakal gumantung marang DBMS eksternal lan prilaku (lan, terus terang, iku wanita capricious), sing ing panemu kita ala. Kenging punapa? Yen metadata FS rusak, data FS dhewe uga bisa diarani "pamit", mula kita mutusake kanggo njupuk dalan sing luwih rumit nanging dipercaya.
Kita nggawe subsistem sinkronisasi metadata kanggo ARDFS dhewe, lan urip kanthi bebas saka subsistem jejer. Sing. ora ana subsistem liyane sing bisa ngrusak data ARDFS. Ing mratelakake panemume, iki cara sing paling dipercaya lan bener, nanging wektu bakal ngomong apa iki bener. Kajaba iku, ana kauntungan tambahan karo pendekatan iki. ARDFS bisa digunakake kanthi bebas saka vAIR, kaya panyimpenan sing dawa, sing mesthi bakal digunakake ing produk sing bakal teka.
Akibaté, ngembangaken ARDFS, kita nampa sistem file fleksibel lan dipercaya sing menehi pilihan ngendi sampeyan bisa ngirit kapasitas utawa menehi kabeh munggah ing kinerja, utawa nggawe panyimpenan Ultra-dipercaya ing biaya cukup, nanging nyuda syarat kinerja.
Bebarengan karo kabijakan lisensi sing prasaja lan model pangiriman sing fleksibel (looking ahead, vAIR dilisensi dening node, lan dikirim minangka piranti lunak utawa minangka paket piranti lunak), iki ngidini sampeyan nyetel solusi kanthi tepat kanggo macem-macem syarat pelanggan lan banjur gampang njaga imbangan iki.
Sapa sing butuh mukjijat iki?
Ing tangan siji, kita bisa ngomong sing wis ana pemain ing pasar sing duwe solusi serius ing lapangan hyperconvergence, lan iki ngendi kita bener judhul. Kayane pernyataan iki bener, TAPI ...
Ing sisih liya, nalika kita metu menyang lapangan lan komunikasi karo pelanggan, kita lan mitra ndeleng manawa iki ora kedadeyan. Ana akeh tugas kanggo hiperkonvergensi, ing sawetara panggonan, wong mung ora ngerti yen solusi kasebut ana, ing wong liya katon larang, ing wong liya ana tes solusi alternatif sing ora sukses, lan ing liyane padha nglarang tuku amarga sanksi. Umumé, sawah kasebut ora diluku, mula kita lunga kanggo ngunggahake lemah prawan))).
Nalika sistem panyimpenan luwih apik tinimbang GCS?
Nalika kita nggarap pasar, kita asring takon nalika luwih becik nggunakake skema klasik kanthi sistem panyimpenan, lan nalika nggunakake hyperconvergent? Akeh perusahaan sing ngasilake GCS (utamane sing ora duwe sistem panyimpenan ing portofolio) ujar: "Sistem panyimpenan dadi lungse, mung hiperkonvergen!" Iki minangka statement kandel, nanging ora sakabehe nggambarake kasunyatan.
Sejatine, pasar panyimpenan pancen maju menyang hiperkonvergensi lan solusi sing padha, nanging mesthi ana "nanging".
Kaping pisanan, pusat data lan infrastruktur IT sing dibangun miturut skema klasik kanthi sistem panyimpenan ora bisa dibangun maneh kanthi gampang, mula modernisasi lan ngrampungake infrastruktur kasebut isih dadi warisan kanggo 5-7 taun.
Kapindho, infrastruktur sing saiki dibangun kanggo sebagian besar (tegese Federasi Rusia) dibangun miturut skema klasik nggunakake sistem panyimpenan, lan ora amarga wong ora ngerti babagan hyperconvergence, nanging amarga pasar hyperconvergence anyar, solusi lan standar durung ditetepake , wong IT durung dilatih, duwe pengalaman sethithik, nanging kudu mbangun pusat data ing kene lan saiki. Lan gaya iki bakal tahan nganti 3-5 taun liyane (banjur warisan liyane, deleng titik 1).
Katelu, ana watesan sejatine sifate teknis ing wektu tundha cilik tambahan 2 milliseconds saben nulis (ora kalebu cache lokal, mesthi), yaiku biaya panyimpenan sing disebarake.
Ya, aja lali babagan panggunaan server fisik gedhe sing seneng skala vertikal subsistem disk.
Ana akeh tugas sing perlu lan populer ing ngendi sistem panyimpenan tumindak luwih apik tinimbang GCS. Ing kene, mesthine, produsen sing ora duwe sistem panyimpenan ing portofolio produk ora bakal setuju karo kita, nanging kita siap mbantah kanthi wajar. Mesthi, kita, minangka pangembang produk loro kasebut, mesthi bakal mbandhingake sistem panyimpenan lan GCS ing salah sawijining publikasi sing bakal teka, ing ngendi kita bakal nuduhake kanthi jelas sing luwih apik ing kahanan apa.
Lan ing ngendi solusi hyperconverged bakal luwih apik tinimbang sistem panyimpenan?
Adhedhasar titik-titik ing ndhuwur, telung kesimpulan sing jelas bisa ditarik:
- Yen tambahan 2 milliseconds latensi kanggo ngrekam, sing terus-terusan ana ing produk apa wae (saiki kita ora ngomong babagan sintetik, nanodetik bisa ditampilake ing sintetik), ora kritis, hyperconvergent cocok.
- Ing ngendi beban saka server fisik gedhe bisa diowahi dadi akeh virtual cilik lan disebarake ing antarane kelenjar, hyperconvergence uga bakal bisa digunakake kanthi apik.
- Yen skala horisontal minangka prioritas sing luwih dhuwur tinimbang skala vertikal, GCS uga bakal apik.
Apa solusi kasebut?
- Kabeh layanan infrastruktur standar (layanan direktori, surat, EDMS, server file, sistem ERP lan BI cilik utawa medium, lsp.). Kita nyebut iki "komputasi umum".
- Infrastruktur panyedhiya maya, ing ngendi perlu kanthi cepet lan standar kanthi horisontal nggedhekake lan gampang "motong" akeh mesin virtual kanggo klien.
- Infrastruktur desktop virtual (VDI), ing ngendi akeh mesin virtual pangguna cilik mlaku lan "ngambang" kanthi tenang ing kluster seragam.
- Jaringan cabang, ing ngendi saben cabang mbutuhake infrastruktur standar, fault-tolerant, nanging murah saka 15-20 mesin virtual.
- Sembarang komputasi sing disebarake (layanan data gedhe, contone). Ing ngendi beban kasebut ora "jero", nanging "jembare".
- lingkungan Test ngendi wektu tundha cilik tambahan ditrima, nanging ana watesan budget, amarga iki tes.
Ing wayahe, kanggo tugas-tugas kasebut kita wis nggawe AERODISK vAIR lan kita fokusake (kasil nganti saiki). Mungkin iki bakal enggal ganti, amarga ... donya ora mandheg.
Dadi…
Iki ngrampungake bagean pisanan saka seri akeh artikel; ing artikel sabanjure kita bakal ngomong babagan arsitektur solusi lan komponen sing digunakake.
We welcome pitakonan, saran lan regejegan mbangun.
Source: www.habr.com