Сайн байна уу, Хабр уншигчид. Энэхүү нийтлэлээр бид өөрсдийн бүтээсэн AERODISK vAIR гиперконвергед системийн тухай өгүүлэх цувралыг нээж байна. Эхний нийтлэлд бид бүх зүйлийн талаар бүгдийг хэлэхийг хүссэн боловч систем нь нэлээд төвөгтэй тул зааныг хэсэг хэсгээр нь идэх болно.
Системийг бий болгосон түүхээс түүхийг эхлүүлж, vAIR-ийн үндэс болсон ARDFS файлын системийг судалж, Оросын зах зээл дээрх энэхүү шийдлийн байршлын талаар бага зэрэг ярилцъя.
Ирээдүйн нийтлэлүүдэд бид янз бүрийн архитектурын бүрэлдэхүүн хэсгүүд (кластер, гипервизор, ачаалал тэнцвэржүүлэгч, хяналтын систем гэх мэт), тохиргооны үйл явц, лицензийн асуудлыг хөндөх, ослын туршилтуудыг тусад нь харуулах, мэдээжийн хэрэг ачааллын туршилтын талаар дэлгэрэнгүй ярих болно. хэмжээс. Бид мөн vAIR-ийн олон нийтийн хувилбарт тусдаа нийтлэл зориулах болно.
Aerodisk нь хадгалах системийн тухай түүх мөн үү? Эсвэл бид яагаад эхлээд гиперконвергенцийг хийж эхэлсэн бэ?
Анх 2010 онд өөрсдийн гиперконвергенцийг бий болгох санаа бидэнд хаа нэгтээ орж ирсэн. Тухайн үед зах зээл дээр Aerodisk болон үүнтэй төстэй шийдлүүд (арилжааны хайрцагласан гиперконверж систем) байгаагүй. Бидний даалгавар бол: Ethernet протоколоор дамжуулан харилцан холболтоор нэгдсэн локал диск бүхий серверүүдийн багцаас өргөтгөсөн санах ой бий болгож, виртуал машин, програм хангамжийн сүлжээг ажиллуулах шаардлагатай байв. Энэ бүгдийг хадгалах системгүйгээр хэрэгжүүлэх ёстой байсан (учир нь хадгалах систем болон түүний техник хангамжид мөнгө байхгүй байсан бөгөөд бид өөрсдийн хадгалах системийг зохион бүтээгээгүй байсан).
Бид олон нээлттэй эхийн шийдлүүдийг туршиж үзсэн бөгөөд эцэст нь энэ асуудлыг шийдсэн боловч шийдэл нь маш төвөгтэй бөгөөд давтахад хэцүү байсан. Үүнээс гадна, энэ шийдэл нь "Энэ нь ажилладаг уу? Битгий хүр! Тиймээс, энэ асуудлыг шийдэж, бид ажлынхаа үр дүнг бүрэн хэмжээний бүтээгдэхүүн болгон хувиргах санааг цаашид хөгжүүлээгүй.
Тэр явдлаас хойш бид энэ бодлоосоо холдсон ч энэ асуудал бүрэн шийдэгдэх боломжтой, ийм шийдлийн ашиг тус нь илэрхий байсан юм шиг санагдаж байсан. Дараа нь гадаадын компаниудын гаргасан HCI бүтээгдэхүүн нь зөвхөн энэ мэдрэмжийг баталгаажуулсан.
Тиймээс 2016 оны дундуур бид бүрэн хэмжээний бүтээгдэхүүн бүтээх ажлын хүрээнд энэ ажилдаа эргэн орсон. Тэр үед бид хөрөнгө оруулагчидтай ямар ч харилцаа холбоогүй байсан учраас тийм ч их биш мөнгөөр бүтээн байгуулалтын стенд худалдаж авсан. Ашигласан серверүүд болон Avito свичийг цуглуулсны дараа бид ажилдаа орлоо.
Эхний гол ажил бол Ethernet-ээр харилцан холболтоор холбогдсон кластерийн зангилааны n-р тооны виртуал блок хэлбэрээр өгөгдлийг автоматаар жигд хуваарилах боломжтой, энгийн боловч өөрсдийн файлын системийг бий болгох явдал байв. Үүний зэрэгцээ, FS нь сайн, хялбар масштабтай байх ёстой бөгөөд зэргэлдээх системээс хараат бус байх ёстой. "зүгээр л хадгалах байгууламж" хэлбэрээр vAIR-аас хасагдах.
Анхны vAIR үзэл баримтлал
Сунгасан хадгалалт (ceph, gluster, glister гэх мэт) зохион байгуулахад бэлэн нээлттэй эхийн шийдлүүдийг ашиглахаас санаатайгаар татгалзаж, өөрсдийнхөө хөгжлийг дэмжсэн, учир нь бид төслийн талаар маш их туршлагатай байсан. Мэдээжийн хэрэг, эдгээр шийдлүүд нь өөрөө маш сайн бөгөөд Aerodisk дээр ажиллахаасаа өмнө бид тэдэнтэй нэгээс олон интеграцийн төслийг хэрэгжүүлсэн. Гэхдээ нэг үйлчлүүлэгчийн хувьд тодорхой даалгаврыг хэрэгжүүлэх, боловсон хүчнийг сургах, магадгүй томоохон борлуулагчийн дэмжлэгийг авах нь нэг хэрэг бөгөөд бидний хувьд янз бүрийн ажилд ашиглах амархан хуулбарлах бүтээгдэхүүн бий болгох нь өөр хэрэг юм. борлуулагч, тэр ч байтугай бид өөрсдийнхөө тухай мэдэхгүй байж болно. Хоёрдахь зорилгын үүднээс одоо байгаа нээлттэй эхийн бүтээгдэхүүнүүд бидэнд тохирохгүй байсан тул бид өөрсдөө тараагдсан файлын системийг бий болгохоор шийдсэн.
Хоёр жилийн дараа хэд хэдэн хөгжүүлэгчид (vAIR дээрх ажлыг сонгодог Хөдөлгүүрийн хадгалах систем дээр хийсэн ажилтай хослуулсан) тодорхой үр дүнд хүрсэн.
2018 он гэхэд бид энгийн файлын системийг бичиж, шаардлагатай техник хэрэгслээр хангасан. Систем нь өөр өөр серверүүдийн физик (локал) дискүүдийг дотоод холболтоор нэг хавтгай усан санд нэгтгэж, виртуал блок болгон "хүссэн" бөгөөд дараа нь виртуал блокуудаас янз бүрийн эвдрэлийг тэсвэрлэх чадвартай блок төхөөрөмжүүдийг үүсгэсэн бөгөөд тэдгээрийн дээр виртуал блокууд бий болсон. KVM hypervisor машинуудыг ашиглан гүйцэтгэсэн.
Бид файлын системийн нэрэнд нэг их санаа зовоогүй бөгөөд үүнийг ARDFS гэж товчоор нэрлэсэн (энэ нь юу гэсэн үг болохыг тааварлаарай))
Энэхүү прототип нь сайн харагдаж байсан (харааны хувьд биш, мэдээжийн хэрэг харааны дизайн хараахан байгаагүй) гүйцэтгэл, масштабын хувьд сайн үр дүнг харуулсан. Эхний бодит үр дүнгийн дараа бид энэ төслийг хөдөлгөж, бүрэн хэмжээний хөгжлийн орчин, зөвхөн vAIR-тай харьцдаг тусдаа багийг зохион байгуулав.
Яг тэр үед шийдлийн ерөнхий бүтэц боловсорч гүйцсэн бөгөөд энэ нь томоохон өөрчлөлтөд ороогүй байна.
ARDFS файлын систем рүү шумбах
ARDFS нь vAIR-ийн үндэс суурь бөгөөд бүх кластерт тархсан, гэмтэлд тэсвэртэй өгөгдөл хадгалах боломжийг олгодог. ARDFS-ийн нэг (гэхдээ цорын ганц биш) онцлог нь мета өгөгдөл болон менежментэд зориулж нэмэлт тусгай сервер ашигладаггүй явдал юм. Энэ нь шийдлийн тохиргоог хялбарчлах, найдвартай байдлыг хангах үүднээс анх санаачилсан юм.
Хадгалах бүтэц
Кластерын бүх зангилааны хүрээнд ARDFS нь бүх дискний зайнаас логик сан зохион байгуулдаг. Усан сан нь өгөгдөл эсвэл форматлагдсан орон зай биш гэдгийг ойлгох нь чухал бөгөөд зүгээр л тэмдэглэгээ, i.e. vAIR суулгасан аливаа зангилаа нь кластерт нэмэгдэхэд автоматаар хуваалцсан ARDFS санд нэмэгдэх ба дискний нөөцийг бүхэлд нь кластерт автоматаар хуваалцах болно (мөн ирээдүйд өгөгдөл хадгалах боломжтой). Энэ арга нь аль хэдийн ажиллаж байгаа системд ямар нэгэн ноцтой нөлөө үзүүлэхгүйгээр шууд зангилаа нэмэх, устгах боломжийг олгодог. Тэдгээр. Системийг "тоосгонд" масштаблахад маш хялбар бөгөөд шаардлагатай бол кластерт зангилаа нэмж, арилгах боломжтой.
Виртуал дискүүд (виртуал машинуудын хадгалах объектууд) нь 4 мегабайт хэмжээтэй виртуал блокуудаас бүтээгдсэн ARDFS цөөрмийн дээд талд нэмэгддэг. Виртуал диск нь өгөгдлийг шууд хадгалдаг. Гэмтлийг тэсвэрлэх схемийг мөн виртуал дискний түвшинд тохируулдаг.
Таны таамаглаж байсанчлан дискний дэд системийн алдааг тэсвэрлэхийн тулд бид RAID (бие даасан дискүүдийн илүүдэл массив) гэсэн ойлголтыг ашигладаггүй, харин RAIN (бие даасан зангилааны илүүдэл массив) ашигладаг. Тэдгээр. Гэмтлийн хүлцлийг хэмжиж, автоматжуулж, дискэн дээр биш зангилаа дээр тулгуурлан удирддаг. Мэдээжийн хэрэг дискүүд нь хадгалах объект бөгөөд бусад бүх зүйлсийн нэгэн адил хянагддаг, та тэдэнтэй хамт бүх стандарт үйлдлүүдийг хийж болно, үүнд локал техник хангамжийн RAID угсрах боломжтой боловч кластер нь тусгайлан зангилаанууд дээр ажилладаг.
Хэрэв та RAID-ийг үнэхээр хүсч байгаа нөхцөлд (жишээлбэл, жижиг кластерууд дээр олон алдаа гарахыг дэмждэг хувилбар) танд локал RAID хянагч ашиглах, өргөтгөсөн санах ой болон RAIN архитектурыг бий болгоход юу ч саад болохгүй. Энэ хувилбар нь нэлээд идэвхтэй бөгөөд бид дэмжигдсэн тул vAIR ашиглах ердийн хувилбаруудын тухай нийтлэлд энэ тухай ярих болно.
Хадгалалтын алдааг тэсвэрлэх схемүүд
vAIR дахь виртуал дискний алдааг тэсвэрлэх хоёр схем байж болно:
1) Хуулбарлах хүчин зүйл эсвэл зүгээр л хуулбарлах - алдааг тэсвэрлэх энэ арга нь саваа, олс шиг энгийн. Синхрон хуулбарыг 2 (кластер тутамд 2 хувь) эсвэл 3 (3 хувь) хүчин зүйлтэй зангилааны хооронд гүйцэтгэдэг. RF-2 нь виртуал дискийг кластерын нэг зангилааны эвдрэлийг тэсвэрлэх боломжийг олгодог боловч ашигтай эзэлхүүний хагасыг "иддэг" бөгөөд RF-3 нь кластер дахь 2 зангилааны эвдрэлийг тэсвэрлэх боловч 2/3-ийг нөөцлөх болно. хэрэгцээнд нь ашигтай хэмжээ. Энэ схем нь RAID-1-тэй маш төстэй, өөрөөр хэлбэл RF-2-д тохируулсан виртуал диск нь кластерын аль нэг зангилааны эвдрэлд тэсвэртэй байдаг. Энэ тохиолдолд бүх зүйл өгөгдөлтэй байх болно, тэр ч байтугай I/O зогсохгүй. Унасан зангилаа үйлчилгээнд буцаж ирэхэд автоматаар өгөгдлийг сэргээх/синхрончлол эхэлнэ.
RF-2 ба RF-3 өгөгдлийг хэвийн горимд болон бүтэлгүйтлийн нөхцөлд түгээх жишээг доор харуулав.
Бидэнд 8 vAIR зангилаа дээр ажилладаг 4МБ өвөрмөц (ашигтай) өгөгдлийн багтаамжтай виртуал машин байна. Бодит байдал дээр ийм жижиг хэмжээ байх магадлал багатай нь тодорхой боловч ARDFS-ийн үйл ажиллагааны логикийг тусгасан схемийн хувьд энэ жишээ хамгийн ойлгомжтой юм. AB нь виртуал машины өвөрмөц өгөгдлийг агуулсан 4МБ виртуал блок юм. RF-2 нь эдгээр блокуудын A1+A2 ба B1+B2 хоёр хуулбарыг тус тус үүсгэдэг. Эдгээр блокууд нь зангилааны хооронд "тавьсан" бөгөөд нэг зангилаа дээрх ижил өгөгдлийн огтлолцолоос зайлсхийдэг, өөрөөр хэлбэл A1 хуулбар нь A2 хуулбартай ижил зангилаа дээр байрлахгүй. B1 ба B2-тэй адилхан.
Хэрэв зангилааны аль нэг нь бүтэлгүйтсэн бол (жишээлбэл, В3-ийн хуулбарыг агуулсан зангилаа №1) энэ хуулбар нь түүний хуулбар (өөрөөр хэлбэл B2-ийн хуулбар) байхгүй цэг дээр автоматаар идэвхждэг.
Тиймээс виртуал диск (мөн үүний дагуу VM) нь RF-2 схемийн нэг зангилааны эвдрэлийг амархан даван туулж чадна.
Хуулбарлах схем нь энгийн бөгөөд найдвартай боловч RAID1-тэй ижил асуудалтай тулгардаг - ашиглахад хангалттай зай байхгүй.
2) Дээрх асуудлыг шийдвэрлэхийн тулд устгах кодчилол эсвэл устгах кодчилол ("ийлбэр кодчилол", "арилгах кодчилол" эсвэл "нөөцлөх код" гэж нэрлэдэг) байдаг. EC нь хуулбарлахтай харьцуулахад дискний зай багатай өндөр мэдээллийн хүртээмжийг хангадаг нөөцийн схем юм. Энэ механизмын ажиллах зарчим нь RAID 5, 6, 6P-тэй төстэй.
Кодлох үед EC процесс нь виртуал блокийг (анхдагчаар 4MB) EC схемээс хамааран хэд хэдэн жижиг "өгөгдлийн хэсгүүдэд" хуваадаг (жишээлбэл, 2+1 схем нь 4МБ блок бүрийг 2 2MB хэсэг болгон хуваадаг). Дараа нь энэ процесс нь өмнө нь хуваасан хэсгүүдийн аль нэгээс томгүй "өгөгдлийн хэсгүүд"-ийн хувьд "паритын хэсгүүд" үүсгэдэг. Кодыг тайлах үед EC нь бүхэл бүтэн кластерийн "амьд үлдсэн" өгөгдлийг уншиж, алга болсон хэсгүүдийг үүсгэдэг.
Жишээлбэл, 2 кластер зангилаа дээр хэрэгжсэн 1 + 4 EC схем бүхий виртуал диск нь RF-2-ийн нэгэн адил кластер дахь нэг зангилааны эвдрэлийг амархан тэсвэрлэх болно. Энэ тохиолдолд нэмэлт зардал бага байх болно, ялангуяа RF-2-ийн ашигтай хүчин чадлын коэффициент 2, EC 2+1-ийн хувьд 1,5 байна.
Үүнийг илүү энгийнээр тайлбарлахын тулд мөн чанар нь виртуал блокыг 2-8 (яагаад 2-оос 8 хүртэл, доороос үзнэ үү) "хэсэг" болгон хувааж, эдгээр хэсгүүдийн хувьд ижил хэмжээтэй ижил хэмжээтэй "хэсгүүдийг" тооцдог.
Үүний үр дүнд өгөгдөл болон паритет нь кластерын бүх зангилаанд жигд тархсан байна. Үүний зэрэгцээ, хуулбарлахын нэгэн адил ARDFS нь ижил өгөгдөл (өгөгдлийн хуулбар ба тэдгээрийн паритет) нэг зангилаа дээр хадгалагдахаас сэргийлж, өгөгдлийг автоматаар зангилаануудаар тарааж, улмаар өгөгдлийг алдах магадлалыг арилгадаг. өгөгдөл болон тэдгээрийн паритет нь амжилтгүй болсон нэг хадгалах цэг дээр гэнэт дуусна.
Доорх жишээ нь ижил 8 МБ виртуал машин, 4 зангилаатай, гэхдээ EC 2+1 схемтэй.
А ба В блокууд нь тус бүр нь 2 МБ хэмжээтэй хоёр хэсэгт хуваагдана (2+1 учраас хоёр), өөрөөр хэлбэл A1+A2 ба B1+B2. Хуулбараас ялгаатай нь A1 нь A2-ийн хуулбар биш бөгөөд энэ нь В блоктой адил хоёр хэсэгт хуваагдсан виртуал А блок юм. Нийтдээ бид 4МБ хэмжээтэй хоёр багц авах бөгөөд тус бүр нь хоёр МБ хэмжээтэй хоёр багцыг агуулдаг. Дараа нь, эдгээр багц бүрийн хувьд паритетыг нэг ширхэгээс илүүгүй хэмжээтэй (жишээ нь 2 МБ) тооцоолж, бид нэмэлт + 2 паритет (AP ба АД) авна. Бид нийтдээ 4 × 2 өгөгдөл + 2 × 2 париттай байна.
Дараа нь өгөгдөл нь тэдгээрийн паритеттай огтлолцохгүйн тулд хэсгүүдийг зангилааны хооронд "байруулсан". Тэдгээр. A1 ба A2 нь AP-тай ижил зангилаа дээр байхгүй.
Нэг зангилаа эвдэрсэн тохиолдолд (жишээлбэл, гурав дахь нь) унасан блок B1 нь 2-р зангилаа дээр хадгалагдсан АД-ын паритетаас автоматаар сэргээгдэж, байгаа зангилаа дээр идэвхжинэ. B-паритет байхгүй, өөрөөр хэлбэл. АД-ын хэсэг. Энэ жишээнд энэ нь зангилаа No1 юм
Уншигч танд асуулт байгаа гэдэгт итгэлтэй байна:
"Таны тодорхойлсон бүх зүйлийг өрсөлдөгчид болон нээлттэй эхийн шийдлүүдийн аль алинд нь аль эрт хэрэгжүүлсэн. ARDFS-д EC-ийг хэрэгжүүлэх нь таны хооронд ямар ялгаа байна вэ?"
Дараа нь ARDFS-ийн сонирхолтой шинж чанарууд байх болно.
Уян хатан байдалд анхаарлаа хандуулж кодчилолыг арилгана
Эхэндээ бид нэлээд уян хатан EC X+Y схемийг өгсөн бөгөөд X нь 2-оос 8 хүртэлх тоотой, Y нь 1-ээс 8 хүртэлх тоотой тэнцүү боловч үргэлж X-ээс бага эсвэл тэнцүү байна. Энэ схемийг өгсөн болно. уян хатан байдлын хувьд. Виртуал блокыг хуваах өгөгдлийн хэсгүүдийн (X) тоог нэмэгдүүлэх нь нэмэлт зардлыг бууруулах, өөрөөр хэлбэл ашиглах боломжтой зайг нэмэгдүүлэх боломжийг олгодог.
Паритын хэсгүүдийн тоог (Y) нэмэгдүүлэх нь виртуал дискний найдвартай байдлыг нэмэгдүүлдэг. Y утга их байх тусам кластер дахь илүү олон зангилаа бүтэлгүйтэж болно. Мэдээжийн хэрэг, паритетийн хэмжээг нэмэгдүүлэх нь ашиглах боломжтой хүчин чадлын хэмжээг бууруулдаг боловч энэ нь найдвартай байдлын төлөө төлөх ёстой үнэ юм.
Гүйцэтгэлийн EC хэлхээний хамаарал нь бараг шууд байдаг: "хэсэг" их байх тусам гүйцэтгэл бага байх болно; энд мэдээж тэнцвэртэй үзэл бодол хэрэгтэй.
Энэ арга нь админуудад сунгасан хадгалах санг хамгийн их уян хатан байдлаар тохируулах боломжийг олгодог. ARDFS-ийн санд та ямар ч алдааг тэсвэрлэх схем, тэдгээрийн хослолыг ашиглаж болно, энэ нь бидний бодлоор бас ашигтай юм.
Доорх нь хэд хэдэн (бүгд боломжгүй) RF болон EC схемүүдийг харьцуулсан хүснэгт юм.
Хүснэгтээс харахад кластер дахь 8 хүртэлх зангилааг зэрэг алдах боломжийг олгодог EC 7+7 хамгийн "терри" хослол нь стандарт хуулбараас илүү бага зайг "иддэг" (1,875-ын эсрэг 2), мөн 7 дахин сайн хамгаалдаг. , энэ нь энэхүү хамгаалалтын механизмыг илүү төвөгтэй боловч хязгаарлагдмал дискний зайтай нөхцөлд хамгийн их найдвартай байдлыг хангах шаардлагатай нөхцөлд илүү сонирхолтой болгодог. Үүний зэрэгцээ X эсвэл Y дээр "нэмэх" бүр нь гүйцэтгэлийн нэмэлт зардал болно гэдгийг та ойлгох хэрэгтэй, тиймээс найдвартай байдал, хэмнэлт, гүйцэтгэлийн гурвалжинд та маш болгоомжтой сонгох хэрэгтэй. Энэ шалтгааны улмаас бид кодчиллын хэмжээг арилгахын тулд тусдаа өгүүллийг зориулах болно.
Файлын системийн найдвартай байдал, бие даасан байдал
ARDFS нь кластерын бүх зангилаанууд дээр локал байдлаар ажилладаг бөгөөд тусгайлсан Ethernet интерфэйсүүдээр дамжуулан тэдгээрийг өөрийн хэрэгслээр синхрончилдог. Хамгийн чухал зүйл бол ARDFS нь зөвхөн өгөгдлийг төдийгүй хадгалахтай холбоотой мета өгөгдлийг бие даан синхрончлох явдал юм. ARDFS дээр ажиллаж байхдаа бид хэд хэдэн одоо байгаа шийдлүүдийг нэгэн зэрэг судалсан бөгөөд олон хүмүүс файлын системийн мета-г гадаад тархсан DBMS ашиглан синхрончлохыг олж мэдсэн бөгөөд үүнийг бид бас синхрончлолд ашигладаг, гэхдээ FS мета өгөгдөл биш зөвхөн тохиргоог хийдэг (энэ болон бусад холбогдох дэд системүүдийн талаар). дараагийн нийтлэлд).
Гадны DBMS ашиглан FS мета өгөгдлийг синхрончлох нь мэдээж хэрэг шийдэл боловч ARDFS дээр хадгалагдсан өгөгдлийн тууштай байдал нь гадаад DBMS болон түүний зан төлөвөөс (мөн илэн далангүй хэлэхэд энэ нь сэтгэл татам эмэгтэй) хамаарна. бидний бодол муу байна. Яагаад? Хэрэв FS мета өгөгдөл эвдэрсэн бол FS өгөгдөл өөрөө "баяртай" гэж хэлж болох тул бид илүү төвөгтэй боловч найдвартай замыг сонгохоор шийдсэн.
Бид ARDFS-д зориулж мета өгөгдлийн синхрончлолын дэд системийг өөрсдөө хийсэн бөгөөд энэ нь зэргэлдээх дэд системүүдээс бүрэн хамааралгүй амьдардаг. Тэдгээр. өөр ямар ч дэд систем ARDFS өгөгдлийг гэмтээж чадахгүй. Бидний бодлоор энэ бол хамгийн найдвартай бөгөөд зөв арга боловч энэ нь үнэхээр тийм эсэхийг цаг хугацаа харуулах болно. Үүнээс гадна энэ аргын нэмэлт давуу тал бий. ARDFS-ийг vAIR-аас хамааралгүй, сунгасан хадгалах хэрэгсэл болгон ашиглаж болох бөгөөд бид үүнийг ирээдүйн бүтээгдэхүүнүүдэд ашиглах нь гарцаагүй.
Үүний үр дүнд ARDFS-ийг хөгжүүлснээр бид хүчин чадлаа хэмнэж, гүйцэтгэлээс татгалзаж, боломжийн зардлаар хэт найдвартай хадгалалт хийх боломжтой, гэхдээ гүйцэтгэлийн шаардлагыг бууруулдаг уян хатан, найдвартай файлын системийг хүлээн авсан.
Энгийн лицензийн бодлого, хүргэх уян хатан загвартай хамт (цаашид vAIR нь зангилаанаас лиценз авч, программ хангамж эсвэл програм хангамжийн багц хэлбэрээр хүргэгдэнэ) энэ нь шийдлийг олон төрлийн хэрэглэгчийн шаардлагад нийцүүлэн маш нарийн тохируулах боломжийг олгодог. тэгвэл энэ тэнцвэрийг амархан хадгална.
Энэ гайхамшиг хэнд хэрэгтэй вэ?
Нэг талаас, бид зах зээл дээр гиперконвергенцийн талбарт ноцтой шийдлүүдийг гаргасан тоглогчид аль хэдийн байгаа гэж хэлж болно, бид яг энэ тийшээ явж байна. Энэ мэдэгдэл үнэн бололтой, ГЭХДЭЭ...
Нөгөөтэйгүүр, бид талбай дээр гарч, үйлчлүүлэгчидтэй харилцахдаа бид болон манай түншүүд огт тийм биш гэдгийг хардаг. Гиперконвергенцийн олон даалгавар байдаг, зарим газарт хүмүүс ийм шийдэл байдаг гэдгийг мэддэггүй байсан, заримд нь энэ нь үнэтэй мэт санагдаж, заримд нь өөр шийдлүүдийн туршилт амжилтгүй болсон, заримд нь хориг арга хэмжээний улмаас худалдаж авахыг огт хориглодог. Ер нь талбай хагалгаагүй болсон тул онгон хөрс өргөхөөр явсан))).
Хадгалах систем хэзээ GCS-ээс илүү дээр вэ?
Бид зах зээлтэй хамтран ажиллахдаа хадгалалтын системтэй сонгодог схемийг хэзээ ашиглах нь илүү дээр вэ, гиперконвергентийг хэзээ ашиглах вэ? GCS үйлдвэрлэдэг олон компаниуд (ялангуяа багцдаа хадгалах системгүй компаниуд) "Хадгалах системүүд хуучирч, зөвхөн хэт нэгдэж байна!" Энэ бол зоримог мэдэгдэл боловч бодит байдлыг бүрэн тусгадаггүй.
Үнэн хэрэгтээ, хадгалах зах зээл үнэхээр гиперконвергенц болон үүнтэй төстэй шийдлүүд рүү шилжиж байгаа ч үргэлж "гэхдээ" байдаг.
Нэгдүгээрт, хадгалалтын систем бүхий сонгодог схемийн дагуу баригдсан дата төвүүд болон мэдээллийн технологийн дэд бүтцийг амархан сэргээж чадахгүй тул ийм дэд бүтцийг шинэчлэх, дуусгах нь 5-7 жилийн хугацаанд өвлөгдсөн хэвээр байна.
Хоёрдугаарт, одоогийн байдлаар баригдаж байгаа дэд бүтэц (ОХУ гэсэн үг) нь хадгалалтын системийг ашиглан сонгодог схемийн дагуу баригдсан бөгөөд энэ нь хүмүүс гиперконвергенцийн талаар мэддэггүйгээс биш, харин гиперконвергенцийн зах зээл шинэ, шийдэл, шийдлүүдтэй холбоотой юм. стандарт хараахан тогтоогдоогүй байна , Мэдээллийн технологийн хүмүүс хараахан бэлтгэгдээгүй, туршлага багатай ч энд, одоо дата төв барих шаардлагатай байна. Мөн энэ хандлага дахин 3-5 жил үргэлжилнэ (дараа нь өөр өв залгамжлал, 1-р зүйлийг үзнэ үү).
Гуравдугаарт, нэг бичихэд 2 миллисекунд (мэдээжийн хэрэг локал кэшээс бусад) бага зэргийн саатал гарахад цэвэр техникийн хязгаарлалт байдаг бөгөөд энэ нь тархсан хадгалалтын зардал юм.
Дискний дэд системийн босоо масштабыг хайрладаг том физик серверүүдийг ашиглах талаар мартаж болохгүй.
Хадгалах системүүд нь GCS-ээс илүү ажилладаг олон шаардлагатай бөгөөд түгээмэл ажлууд байдаг. Мэдээжийн хэрэг, бүтээгдэхүүнийхээ багцад хадгалах системгүй үйлдвэрлэгчид бидэнтэй санал нийлэхгүй, гэхдээ бид үндэслэлтэй маргахад бэлэн байна. Мэдээжийн хэрэг, бид хоёр бүтээгдэхүүнийг боловсруулагчдын хувьд хадгалах систем болон GCS-ийг ирээдүйн хэвлэлүүдийнхээ аль нэгэнд харьцуулж, ямар нөхцөлд аль нь илүү сайн болохыг тодорхой харуулах болно.
Хэт нэгтгэсэн шийдлүүд нь хадгалах системээс илүү хаана ажиллах вэ?
Дээрх зүйлүүд дээр үндэслэн гурван тодорхой дүгнэлтийг гаргаж болно.
- Ямар ч бүтээгдэхүүнд байнга тохиолддог бичлэг хийх нэмэлт 2 миллисекунд хоцрогдол (одоо бид синтетикийн тухай яриагүй, наносекундыг синтетик дээр харуулж болно) нь шүүмжлэлтэй биш байвал гиперконвергент тохиромжтой.
- Том физик серверүүдийн ачааллыг олон жижиг виртуал сервер болгон хувиргаж, зангилааны хооронд хуваарилах боломжтой бол гиперконвергенц нь тэнд сайн ажиллах болно.
- Хэрэв хэвтээ масштаб нь босоо масштабаас илүү чухал бол GCS тэнд ч сайн ажиллах болно.
Эдгээр шийдлүүд юу вэ?
- Бүх стандарт дэд бүтцийн үйлчилгээ (лавлах үйлчилгээ, шуудан, EDMS, файлын серверүүд, жижиг эсвэл дунд ERP болон BI систем гэх мэт). Үүнийг бид "ерөнхий тооцоолол" гэж нэрлэдэг.
- Үйлчлүүлэгчдэд зориулсан олон тооны виртуал машинуудыг хэвтээ байдлаар хурдан, стандартчилах, хялбархан "тайрах" шаардлагатай үүлэн үйлчилгээ үзүүлэгчдийн дэд бүтэц.
- Виртуал ширээний дэд бүтэц (VDI), энд олон жижиг хэрэглэгчийн виртуал машинууд нэг кластер дотор чимээгүйхэн "хөвөгч" ажилладаг.
- Салбар бүрт 15-20 виртуал машинаас бүрдэх стандарт, гэмтэлд тэсвэртэй, гэхдээ хямд дэд бүтэц шаардлагатай салбар сүлжээнүүд.
- Аливаа тархсан тооцоолол (жишээлбэл, том мэдээллийн үйлчилгээ). Ачаалал "гүнд" биш, харин "өргөнөөр" явдаг.
- Нэмэлт жижиг саатал хүлээн зөвшөөрөгдөх боломжтой туршилтын орчин, гэхдээ эдгээр нь туршилтууд тул төсвийн хязгаарлалтууд байдаг.
Одоогийн байдлаар бид эдгээр ажлуудад зориулж AERODISK vAIR-ийг хийсэн бөгөөд эдгээрт анхаарлаа хандуулж байна (одоог хүртэл амжилттай). Магадгүй энэ байдал удахгүй өөрчлөгдөх байх, учир нь... дэлхий зогсохгүй байна.
Тиймээс ...
Энэ нь олон тооны нийтлэлийн эхний хэсгийг дуусгаж байгаа бөгөөд дараагийн өгүүллээр бид шийдлийн архитектур, ашигласан бүрэлдэхүүн хэсгүүдийн талаар ярих болно.
Асуулт, санал, бүтээлч маргааныг бид баяртайгаар хүлээн авна.
Эх сурвалж: www.habr.com