Salom, Habr o'quvchilari. Ushbu maqola bilan biz o'zimiz ishlab chiqqan AERODISK vAIR giperkonverged tizimi haqida gapiradigan turkumni ochamiz. Dastlab, biz birinchi maqolada hamma narsa haqida hamma narsani aytib berishni xohladik, ammo tizim juda murakkab, shuning uchun biz filni qismlarga bo'lib yeymiz.
Keling, hikoyani tizimning yaratilish tarixidan boshlaylik, vAIR asosi bo'lgan ARDFS fayl tizimini o'rganamiz, shuningdek, ushbu yechimning Rossiya bozorida joylashishi haqida bir oz gaplashamiz.
Kelgusi maqolalarda biz turli xil arxitektura komponentlari (klaster, gipervisor, yuk balanslagichi, monitoring tizimi va boshqalar), konfiguratsiya jarayoni, litsenziyalash masalalarini ko'tarish, halokat testlarini alohida ko'rsatish va, albatta, yuk sinovlari haqida yozamiz va o'lchov. Shuningdek, biz vAIR ning hamjamiyat versiyasiga alohida maqola bag'ishlaymiz.
Aerodisk saqlash tizimlari haqida hikoyami? Yoki nima uchun biz birinchi navbatda giperkonvergentsiyani boshladik?
Dastlab, o'zimizning giperkonvergentsiyamizni yaratish g'oyasi bizga 2010 yilda kelgan. O'sha paytda bozorda na Aerodisk, na shunga o'xshash echimlar (tijorat qutisidagi giperkonvergent tizimlar) mavjud emas edi. Bizning vazifamiz quyidagicha edi: Ethernet protokoli orqali o'zaro bog'lanish orqali birlashtirilgan mahalliy disklarga ega serverlar to'plamidan kengaytirilgan saqlashni yaratish va u erda virtual mashinalar va dasturiy ta'minot tarmog'ini ishga tushirish kerak edi. Bularning barchasi saqlash tizimlarisiz amalga oshirilishi kerak edi (chunki saqlash tizimlari va uning jihozlari uchun shunchaki pul yo'q edi va biz hali o'z saqlash tizimlarimizni ixtiro qilmagan edik).
Biz ko'plab ochiq manba echimlarini sinab ko'rdik va nihoyat bu muammoni hal qildik, ammo yechim juda murakkab va takrorlash qiyin edi. Bundan tashqari, ushbu yechim “Ishlaydimi? Tegmang! Shu sababli, ushbu muammoni hal qilib, biz ishimiz natijasini to'liq huquqli mahsulotga aylantirish g'oyasini ishlab chiqmadik.
O'sha voqeadan so'ng biz bu fikrdan uzoqlashdik, ammo biz hali ham bu muammoni butunlay hal qilish mumkinligini his qildik va bunday yechimning foydasi aniqroq edi. Keyinchalik, xorijiy kompaniyalarning chiqarilgan HCI mahsulotlari bu tuyg'uni tasdiqladi.
Shu sababli, 2016 yil o'rtalarida biz to'liq huquqli mahsulotni yaratish doirasida bu vazifaga qaytdik. O'sha paytda biz hali investorlar bilan hech qanday aloqamiz yo'q edi, shuning uchun biz o'zimizning unchalik katta bo'lmagan pulga rivojlanish stendini sotib olishga majbur bo'ldik. Ishlatilgan serverlar va Avito kalitlarini yig'ib, biz ishga kirishdik.
Asosiy boshlang'ich vazifa - Ethernet orqali interkonnekt orqali ulangan klaster tugunlarining n-sonida virtual bloklar ko'rinishidagi ma'lumotlarni avtomatik va teng ravishda taqsimlashi mumkin bo'lgan o'zimizning, ammo oddiy bo'lsa-da, o'z fayl tizimimizni yaratish edi. Shu bilan birga, FS yaxshi va oson miqyosda bo'lishi va qo'shni tizimlardan mustaqil bo'lishi kerak, ya'ni. vAIR dan "shunchaki saqlash joyi" shaklida begonalashtiriladi.
Birinchi vAIR kontseptsiyasi
Biz o'zimizning rivojlanishimiz foydasiga cho'zilgan saqlashni (seph, gluster, lyuks va shunga o'xshash) tashkil qilish uchun tayyor ochiq manba echimlaridan foydalanishdan ataylab voz kechdik, chunki bizda ular bilan juda ko'p loyiha tajribamiz bor edi. Albatta, bu echimlarning o'zi juda zo'r va Aerodisk ustida ishlashdan oldin biz ular bilan bir nechta integratsiya loyihalarini amalga oshirdik. Ammo bitta mijoz uchun ma'lum bir vazifani bajarish, xodimlarni o'qitish va, ehtimol, yirik sotuvchining yordamini sotib olish boshqa narsa va biz turli xil vazifalar uchun ishlatiladigan osongina takrorlanadigan mahsulotni yaratish boshqa narsa. sotuvchi, hatto o'zimiz haqimizda bilmasligimiz ham mumkin. Ikkinchi maqsad uchun mavjud ochiq kodli mahsulotlar biz uchun mos emas edi, shuning uchun biz o'zimiz tarqatilgan fayl tizimini yaratishga qaror qildik.
Ikki yil o'tgach, bir nechta ishlab chiquvchilar (vAIR-dagi ishlarni klassik Dvigatel saqlash tizimidagi ishlarni birlashtirgan) ma'lum bir natijaga erishdilar.
2018 yilga kelib biz oddiy fayl tizimini yozdik va uni kerakli apparat bilan to'ldirdik. Tizim turli serverlardagi jismoniy (mahalliy) disklarni ichki o'zaro bog'lanish orqali bitta tekis hovuzga birlashtirdi va ularni virtual bloklarga "kesdi", so'ngra virtual bloklardan turli darajadagi nosozliklarga bardoshli blokli qurilmalar yaratildi, ularda virtuallar yaratilgan. va KVM gipervisor avtomobillari yordamida bajarilgan.
Biz fayl tizimining nomi bilan ko'p bezovta qilmadik va uni qisqacha ARDFS deb nomladik (u nimani anglatishini taxmin qiling))
Ushbu prototip yaxshi ko'rindi (vizual emas, albatta, hali vizual dizayn yo'q edi) va ishlash va masshtablash nuqtai nazaridan yaxshi natijalarni ko'rsatdi. Birinchi haqiqiy natijadan so'ng, biz ushbu loyihani to'liq rivojlanish muhitini va faqat vAIR bilan shug'ullanadigan alohida jamoani tashkil qilib, harakatga keltirdik.
Aynan o'sha vaqtga kelib, yechimning umumiy arxitekturasi pishib yetdi, u hali katta o'zgarishlarga duch kelmagan.
ARDFS fayl tizimiga kirish
ARDFS vAIR ning asosi bo'lib, u butun klaster bo'ylab taqsimlangan, nosozliklarga chidamli ma'lumotlarni saqlashni ta'minlaydi. ARDFS-ning o'ziga xos xususiyatlaridan biri (lekin yagona emas) - u metama'lumotlar va boshqaruv uchun qo'shimcha ajratilgan serverlardan foydalanmaydi. Bu dastlab yechimning konfiguratsiyasini soddalashtirish va uning ishonchliligi uchun ishlab chiqilgan.
Saqlash tuzilishi
Klasterning barcha tugunlarida ARDFS barcha mavjud disk maydonidan mantiqiy hovuzni tashkil qiladi. Hovuz hali ma'lumotlar yoki formatlangan bo'sh joy emasligini tushunish kerak, lekin oddiygina belgilash, ya'ni. vAIR o'rnatilgan har qanday tugunlar klasterga qo'shilganda avtomatik ravishda umumiy ARDFS hovuziga qo'shiladi va disk resurslari avtomatik ravishda butun klaster bo'ylab taqsimlanadi (va kelajakda ma'lumotlarni saqlash uchun mavjud). Ushbu yondashuv allaqachon ishlayotgan tizimga jiddiy ta'sir qilmasdan tugunlarni tezda qo'shish va olib tashlash imkonini beradi. Bular. tizimni "g'ishtlarda" o'lchash juda oson, agar kerak bo'lsa, klasterdagi tugunlarni qo'shish yoki olib tashlash.
Virtual disklar (virtual mashinalar uchun saqlash ob'ektlari) 4 megabayt o'lchamdagi virtual bloklardan qurilgan ARDFS pulining tepasiga qo'shiladi. Virtual disklar to'g'ridan-to'g'ri ma'lumotlarni saqlaydi. Xatolarga chidamlilik sxemasi virtual disk darajasida ham o'rnatiladi.
Siz allaqachon taxmin qilganingizdek, disk quyi tizimining nosozliklariga chidamliligi uchun biz RAID (mustaqil disklarning ortiqcha massivi) tushunchasidan foydalanmaymiz, balki RAIN (mustaqil tugunlarning ortiqcha massivi) dan foydalanamiz. Bular. Nosozlikka chidamlilik disklar emas, balki tugunlar asosida o'lchanadi, avtomatlashtiriladi va boshqariladi. Albatta, disklar ham saqlash ob'ekti bo'lib, ular hamma narsa kabi nazorat qilinadi, ular bilan barcha standart operatsiyalarni bajarishingiz mumkin, shu jumladan mahalliy apparat RAIDni yig'ish, lekin klaster maxsus tugunlarda ishlaydi.
Agar siz haqiqatan ham RAID-ni xohlayotgan bo'lsangiz (masalan, kichik klasterlarda bir nechta nosozliklarni qo'llab-quvvatlaydigan stsenariy), mahalliy RAID kontrollerlaridan foydalanishga va cho'zilgan xotira va RAIN arxitekturasini yaratishga hech narsa to'sqinlik qilmaydi. Ushbu stsenariy juda jonli va biz tomonidan qo'llab-quvvatlanadi, shuning uchun biz bu haqda vAIR-dan foydalanishning odatiy stsenariylari haqida maqolada gaplashamiz.
Saqlash xatolariga bardoshlik sxemalari
vAIR-da virtual disklar uchun ikkita nosozlikka chidamlilik sxemasi bo'lishi mumkin:
1) Replikatsiya omili yoki oddiygina replikatsiya - nosozlikka chidamlilikning bu usuli tayoq va arqon kabi oddiy. Sinxron replikatsiya 2 (klaster uchun 2 nusxa) yoki 3 (mos ravishda 3 nusxa) faktorli tugunlar o'rtasida amalga oshiriladi. RF-2 virtual diskga klasterdagi bitta tugunning ishdan chiqishiga bardosh berishga imkon beradi, ammo foydali hajmning yarmini "eydi" va RF-3 klasterdagi 2 tugunning ishdan chiqishiga bardosh beradi, ammo 2/3 qismini zaxira qiladi. ehtiyojlari uchun foydali hajm. Ushbu sxema RAID-1 ga juda o'xshaydi, ya'ni RF-2 da konfiguratsiya qilingan virtual disk klasterdagi biron bir tugunning ishdan chiqishiga chidamli. Bunday holda, ma'lumotlar bilan hamma narsa yaxshi bo'ladi va hatto I/U ham to'xtamaydi. Yiqilgan tugun xizmatga qaytsa, ma'lumotlarni avtomatik tiklash/sinxronizatsiya boshlanadi.
Quyida RF-2 va RF-3 ma'lumotlarini oddiy rejimda va nosozlik holatida taqsimlash misollari keltirilgan.
Bizda 8 vAIR tugunida ishlaydigan 4 MB noyob (foydali) ma'lumotlar sig'imiga ega virtual mashinamiz mavjud. Haqiqatda bunday kichik hajm bo'lishi dargumon, ammo ARDFS ishlashi mantiqini aks ettiruvchi sxema uchun bu misol eng tushunarli. AB noyob virtual mashina ma'lumotlarini o'z ichiga olgan 4MB virtual bloklardir. RF-2 mos ravishda A1+A2 va B1+B2 bloklarining ikkita nusxasini yaratadi. Ushbu bloklar bir xil tugundagi bir xil ma'lumotlarning kesishishidan qochib, tugunlar bo'ylab "joylashtiriladi", ya'ni A1 nusxasi A2 nusxasi bilan bir xil tugunda joylashmaydi. B1 va B2 bilan bir xil.
Agar tugunlardan biri ishlamay qolsa (masalan, B3 nusxasini o'z ichiga olgan №1 tugun), uning nusxasi (ya'ni B2 nusxasi) bo'lmagan tugunda bu nusxa avtomatik ravishda faollashadi.
Shunday qilib, virtual disk (va shunga mos ravishda VM) RF-2 sxemasida bitta tugunning ishdan chiqishidan osongina omon qolishi mumkin.
Replikatsiya sxemasi oddiy va ishonchli bo'lsa-da, RAID1 bilan bir xil muammoga duch keladi - etarli joy yo'q.
2) Yuqoridagi muammoni hal qilish uchun oʻchirish kodlash yoki oʻchirish kodlash (“ortiqcha kodlash”, “oʻchirish kodlash” yoki “ortiqchalik kodi” sifatida ham tanilgan) mavjud. EC - replikatsiya bilan solishtirganda kamroq disk maydoni bilan yuqori ma'lumotlar mavjudligini ta'minlaydigan ortiqcha sxema. Ushbu mexanizmning ishlash printsipi RAID 5, 6, 6P ga o'xshaydi.
Kodlashda EC jarayoni virtual blokni (sukut bo'yicha 4MB) EC sxemasiga qarab bir nechta kichikroq "ma'lumotlar bo'laklariga" ajratadi (masalan, 2+1 sxemasi har bir 4MB blokni 2 2MB bo'lakka ajratadi). Keyinchalik, bu jarayon avval bo'lingan qismlardan biridan katta bo'lmagan "ma'lumotlar bo'laklari" uchun "parite bo'laklarini" hosil qiladi. Dekodlashda EC butun klaster bo'ylab "omon qolgan" ma'lumotlarni o'qish orqali etishmayotgan qismlarni yaratadi.
Masalan, 2 ta klaster tugunlarida amalga oshirilgan 1 + 4 EC sxemasiga ega virtual disk, xuddi RF-2 kabi, klasterdagi bitta tugunning ishdan chiqishiga osongina bardosh beradi. Bunday holda, qo'shimcha xarajatlar kamroq bo'ladi, xususan, RF-2 uchun foydali quvvat koeffitsienti 2 ga, EK 2+1 uchun esa 1,5 ga teng bo'ladi.
Buni soddaroq ta'riflash uchun, mohiyat shundaki, virtual blok 2-8 ga bo'linadi (nima uchun 2 dan 8 gacha, quyida ko'ring) "bo'laklar" va bu qismlar uchun shunga o'xshash hajmdagi paritetning "bo'laklari" hisoblanadi.
Natijada, ma'lumotlar va paritet klasterning barcha tugunlari bo'ylab teng taqsimlanadi. Shu bilan birga, replikatsiyada bo'lgani kabi, ARDFS avtomatik ravishda tugunlar o'rtasida ma'lumotlarni bir xil ma'lumotlarning (ma'lumotlar nusxalari va ularning pariteti) bir tugunda saqlanishiga yo'l qo'ymaslik uchun ma'lumotlarni yo'qotish ehtimolini bartaraf etish uchun avtomatik ravishda taqsimlaydi. ma'lumotlar va ularning pariteti to'satdan muvaffaqiyatsiz bo'lgan bitta saqlash tugunida tugashiga.
Quyida bir xil 8 MB virtual mashina va 4 tugunli, lekin EC 2+1 sxemasi bilan misol keltirilgan.
A va B bloklari har biri 2 MB bo'lgan ikkita qismga bo'lingan (ikkitasi, chunki 2+1), ya'ni A1+A2 va B1+B2. Replikatsiyadan farqli o'laroq, A1 A2 nusxasi emas, bu A virtual bloki bo'lib, ikki qismga bo'lingan, B bloki bilan bir xil. Hammasi bo'lib, biz 4MB dan ikkita to'plamni olamiz, ularning har biri ikkita ikki MB bo'lakni o'z ichiga oladi. Keyinchalik, ushbu to'plamlarning har biri uchun paritet bir bo'lakdan ko'p bo'lmagan hajm bilan hisoblanadi (ya'ni 2 MB), biz qo'shimcha + 2 dona paritetni (AP va BP) olamiz. Hammasi bo'lib bizda 4 × 2 ma'lumotlar + 2 × 2 paritet mavjud.
Keyinchalik, ma'lumotlar ularning pariteti bilan kesishmasligi uchun qismlar tugunlar orasiga "yotqiziladi". Bular. A1 va A2 AP bilan bir xil tugunda bo'lmaydi.
Bitta tugun ishlamay qolganda (masalan, uchinchisi ham) tushib qolgan B1 bloki 2-tugunda saqlanadigan BP paritetidan avtomatik ravishda tiklanadi va mavjud bo'lgan tugunda faollashadi. B-pariteti yo'q, ya'ni. BP qismi. Ushbu misolda bu №1 tugun
Ishonchim komilki, o'quvchida savol bor:
"Siz ta'riflagan hamma narsa uzoq vaqtdan beri raqobatchilar tomonidan ham, ochiq manbali echimlarda ham amalga oshirilgan, sizning ARDFSda ECni amalga oshirishingiz o'rtasidagi farq nima?"
Va keyin ARDFS ning qiziqarli xususiyatlari bo'ladi.
Moslashuvchanlikka e'tibor qaratgan holda kodlashni o'chirish
Dastlab, biz juda moslashuvchan EC X+Y sxemasini taqdim etdik, bu erda X 2 dan 8 gacha bo'lgan raqamga teng, Y esa 1 dan 8 gacha bo'lgan raqamga teng, lekin har doim X dan kichik yoki unga teng. Bu sxema taqdim etilgan. moslashuvchanlik uchun. Virtual blok bo'lingan ma'lumotlar qismlari (X) sonini ko'paytirish qo'shimcha xarajatlarni kamaytirishga, ya'ni foydalanish mumkin bo'lgan maydonni ko'paytirishga imkon beradi.
Paritet qismlari (Y) sonini ko'paytirish virtual diskning ishonchliligini oshiradi. Y qiymati qanchalik katta bo'lsa, klasterdagi ko'proq tugunlar muvaffaqiyatsiz bo'lishi mumkin. Albatta, paritet hajmini oshirish foydalanish mumkin bo'lgan quvvat miqdorini kamaytiradi, ammo bu ishonchlilik uchun to'lanadigan narx.
Ishlashning EC davrlariga bog'liqligi deyarli to'g'ridan-to'g'ri: "qismlar" qancha ko'p bo'lsa, unumdorlik shunchalik past bo'ladi; bu erda, albatta, muvozanatli ko'rinish kerak.
Ushbu yondashuv administratorlarga maksimal moslashuvchanlik bilan kengaytirilgan saqlashni sozlash imkonini beradi. ARDFS hovuzida siz har qanday nosozliklarga chidamlilik sxemalaridan va ularning kombinatsiyalaridan foydalanishingiz mumkin, bu bizning fikrimizcha, bu ham juda foydali.
Quyida bir nechta (barcha mumkin emas) RF va EC sxemalarini taqqoslaydigan jadval mavjud.
Jadval shuni ko'rsatadiki, hatto bir vaqtning o'zida klasterdagi 8 tagacha tugunni yo'qotish imkonini beruvchi eng "terri" EC 7+7 kombinatsiyasi ham standart replikatsiyaga qaraganda kamroq foydalanish mumkin bo'lgan joyni (1,875 ga nisbatan 2) "yeydi" va 7 baravar yaxshiroq himoya qiladi. , bu himoya mexanizmini murakkabroq bo'lsa-da, cheklangan disk maydoni sharoitida maksimal ishonchlilikni ta'minlash zarur bo'lgan holatlarda ancha jozibador qiladi. Shu bilan birga, X yoki Y ga har bir "ortiqcha" qo'shimcha ish yuki bo'lishini tushunishingiz kerak, shuning uchun ishonchlilik, tejash va ishlash o'rtasidagi uchburchakda siz juda ehtiyotkorlik bilan tanlashingiz kerak. Shu sababli, biz kodlash o'lchamlarini o'chirish uchun alohida maqola ajratamiz.
Fayl tizimining ishonchliligi va avtonomligi
ARDFS klasterning barcha tugunlarida lokal ravishda ishlaydi va maxsus Ethernet interfeyslari orqali o'z vositalaridan foydalangan holda ularni sinxronlashtiradi. Muhim nuqta shundaki, ARDFS nafaqat ma'lumotlarni, balki saqlash bilan bog'liq metama'lumotlarni ham mustaqil ravishda sinxronlashtiradi. ARDFS ustida ishlayotganda, biz bir vaqtning o'zida bir qator mavjud echimlarni o'rganib chiqdik va biz ko'pchilik fayl tizimining meta-ni tashqi taqsimlangan DBMS yordamida sinxronlashini aniqladik, biz uni sinxronlashtirish uchun ham ishlatamiz, lekin FS metama'lumotlarini emas, balki faqat konfiguratsiyalarni (bu va boshqa tegishli quyi tizimlar haqida) keyingi maqolada).
FS metama'lumotlarini tashqi ma'lumotlar bazasidan foydalangan holda sinxronlashtirish, albatta, ishlaydigan yechimdir, lekin keyin ARDFSda saqlangan ma'lumotlarning izchilligi tashqi ma'lumotlar bazasi ma'lumotlar bazasiga va uning xatti-harakatlariga bog'liq bo'ladi (va ochig'ini aytganda, bu injiq ayol). fikrimiz yomon. Nega? Agar FS metama'lumotlari buzilgan bo'lsa, FS ma'lumotlarining o'zi ham "xayr" deyish mumkin, shuning uchun biz murakkabroq, ammo ishonchli yo'lni tanlashga qaror qildik.
Biz ARDFS uchun metadata sinxronlash quyi tizimini o'zimiz yaratdik va u qo'shni quyi tizimlardan butunlay mustaqil yashaydi. Bular. boshqa hech qanday quyi tizim ARDFS ma'lumotlarini buza olmaydi. Bizning fikrimizcha, bu eng ishonchli va to'g'ri yo'l, ammo bu haqiqatan ham shundaymi yoki yo'qligini vaqt ko'rsatadi. Bundan tashqari, ushbu yondashuv qo'shimcha afzalliklarga ega. ARDFS vAIR dan mustaqil ravishda, xuddi cho'zilgan saqlash sifatida ishlatilishi mumkin, biz kelajakdagi mahsulotlarda albatta foydalanamiz.
Natijada, ARDFSni ishlab chiqish orqali biz moslashuvchan va ishonchli fayl tizimini oldik, bu sizga sig'imni tejash yoki unumdorlikka hamma narsadan voz kechish yoki o'rtacha narxda o'ta ishonchli saqlashni amalga oshirish, lekin ishlash talablarini kamaytirish imkonini beradi.
Oddiy litsenziyalash siyosati va yetkazib berishning moslashuvchan modeli (oldinga qarab, vAIR tugun tomonidan litsenziyalangan va dasturiy ta'minot yoki dasturiy ta'minot to'plami sifatida yetkazib beriladi) bilan birgalikda bu yechimni mijozlarning turli talablari va talablariga juda aniq moslashtirish imkonini beradi. keyin bu muvozanatni osongina saqlab qoling.
Bu mo''jiza kimga kerak?
Bir tomondan, aytishimiz mumkinki, bozorda allaqachon giperkonvergentsiya sohasida jiddiy echimlarga ega bo'lgan o'yinchilar bor va biz aslida bu erga boryapmiz. Bu gap haqiqatga o'xshaydi, LEKIN...
Boshqa tomondan, biz dalalarga chiqib, mijozlar bilan muloqot qilganimizda, biz va hamkorlarimiz buning umuman emasligini ko'ramiz. Giperkonvergentsiya uchun juda ko'p vazifalar mavjud, ba'zi joylarda odamlar bunday echimlar mavjudligini bilishmagan, boshqalarda bu qimmatga o'xshardi, boshqalarida muqobil echimlarning muvaffaqiyatsiz sinovlari bo'lgan, boshqalarida esa sanktsiyalar tufayli sotib olishni umuman taqiqlaydi. Umuman olganda, dala shudgorlanmagan bo'lib chiqdi, shuning uchun biz bokira tuproqni ko'tarish uchun bordik))).
Qachon saqlash tizimi GCS dan yaxshiroq?
Bozor bilan ishlayotganimizda, bizdan tez-tez so'rashadi, qachon saqlash tizimlari bilan klassik sxemadan foydalanish yaxshiroq va qachon giperkonvergentdan foydalanish kerak? GCS ishlab chiqaruvchi ko'plab kompaniyalar (ayniqsa, o'z portfelida saqlash tizimlariga ega bo'lmaganlar) shunday deyishadi: "Saqlash tizimlari eskirgan, faqat giperkonversiyalangan!" Bu jasur bayonot, lekin u haqiqatni to'liq aks ettirmaydi.
Haqiqatan ham, saqlash bozori haqiqatan ham giperkonvergentsiya va shunga o'xshash echimlar tomon harakat qilmoqda, ammo har doim "lekin" mavjud.
Birinchidan, saqlash tizimlari bilan klassik sxema bo'yicha qurilgan ma'lumotlar markazlari va IT infratuzilmalarini osongina qayta qurish mumkin emas, shuning uchun bunday infratuzilmalarni modernizatsiya qilish va tugatish hali ham 5-7 yil davomida meros bo'lib qolmoqda.
Ikkinchidan, hozirda qurilayotgan infratuzilmaning katta qismi (Rossiya Federatsiyasi nazarda tutiladi) saqlash tizimlaridan foydalangan holda klassik sxema bo'yicha qurilgan, bu odamlar giperkonvergentsiya haqida bilmaganligi uchun emas, balki giperkonvergentsiya bozori yangi, echimlar va standartlar hali o'rnatilmagan , IT xodimlari hali o'qitilmagan, ular kam tajribaga ega, ammo ma'lumotlar markazlarini shu erda va hozir qurishlari kerak. Va bu tendentsiya yana 3-5 yil davom etadi (va keyin yana bir meros, 1-bandga qarang).
Uchinchidan, har bir yozish uchun 2 millisekundlik qo'shimcha kichik kechikishlarda sof texnik cheklov mavjud (albatta, mahalliy keshdan tashqari), bu tarqatilgan saqlash narxidir.
Xo'sh, disk quyi tizimini vertikal masshtablashni yaxshi ko'radigan katta jismoniy serverlardan foydalanishni unutmaylik.
Saqlash tizimlari GCSga qaraganda yaxshiroq harakat qiladigan juda ko'p zarur va mashhur vazifalar mavjud. Bu erda, albatta, mahsulot portfelida saqlash tizimlariga ega bo'lmagan ishlab chiqaruvchilar biz bilan rozi bo'lmaydilar, ammo biz oqilona bahslashishga tayyormiz. Albatta, biz ikkala mahsulotni ishlab chiquvchisi sifatida kelajakdagi nashrlarimizdan birida saqlash tizimlari va GCS ni albatta solishtiramiz, u erda qaysi sharoitda yaxshiroq ekanligini aniq ko'rsatamiz.
Va qayerda giperkonversiyalangan echimlar saqlash tizimlaridan yaxshiroq ishlaydi?
Yuqoridagi fikrlarga asoslanib, uchta aniq xulosa chiqarish mumkin:
- Har qanday mahsulotda doimiy ravishda yuzaga keladigan qo'shimcha 2 millisekundlik yozib olish kechikishi (endi biz sintetika haqida gapirmayapmiz, nanosoniyalarni sintetikada ko'rsatish mumkin) tanqidiy bo'lmaganda, giperkonvergent mos keladi.
- Katta jismoniy serverlardan yukni ko'plab kichik virtual serverlarga aylantirish va tugunlar o'rtasida taqsimlash mumkin bo'lgan joylarda giperkonvergentsiya ham yaxshi ishlaydi.
- Gorizontal o'lchov vertikal o'lchovdan ko'ra ustuvorroq bo'lsa, GCS u erda ham yaxshi ishlaydi.
Bu yechimlar nima?
- Barcha standart infratuzilma xizmatlari (katalog xizmati, pochta, EDMS, fayl serverlari, kichik yoki o'rta ERP va BI tizimlari va boshqalar). Biz buni "umumiy hisoblash" deb ataymiz.
- Bulutli provayderlar infratuzilmasi, bu erda tez va standartlashtirilgan gorizontal ravishda kengaytirish va mijozlar uchun ko'p sonli virtual mashinalarni osongina "kesish" kerak.
- Virtual ish stoli infratuzilmasi (VDI), bu erda ko'plab kichik foydalanuvchi virtual mashinalari ishlaydi va bir xil klaster ichida jimgina "suzadi".
- Har bir filial standart, nosozliklarga chidamli, ammo 15-20 ta virtual mashinadan iborat arzon infratuzilmaga muhtoj bo'lgan filial tarmoqlari.
- Har qanday taqsimlangan hisoblash (masalan, katta ma'lumotlar xizmatlari). Qaerda yuk "chuqurlikda" emas, balki "kenglikda" ketadi.
- Qo'shimcha kichik kechikishlar qabul qilinadigan sinov muhitlari, ammo byudjet cheklovlari mavjud, chunki bu sinovlar.
Ayni paytda biz AERODISK vAIR-ni aynan shu vazifalar uchun yaratdik va aynan ularga e'tibor qaratmoqdamiz (hozircha muvaffaqiyatli). Ehtimol, bu tez orada o'zgaradi, chunki ... dunyo bir joyda turmaydi.
Shunday qilib ...
Bu katta maqolalar seriyasining birinchi qismini yakunlaydi, keyingi maqolada biz yechimning arxitekturasi va ishlatilgan komponentlar haqida gaplashamiz.
Savollar, takliflar va konstruktiv bahslarni qabul qilamiz.
Manba: www.habr.com