Энэ нийтлэлийг танд зөв шийдлийг сонгох, Gluster, Ceph, Vstorage (Virtuozzo) зэрэг SDS хоорондын ялгааг ойлгоход туслах зорилгоор бичсэн болно.
Текст нь тодорхой асуудлуудыг илүү дэлгэрэнгүй тайлбарласан нийтлэлүүдийн холбоосыг ашигладаг тул тайлбар нь аль болох товч бөгөөд шаардлагагүй хөвсгөр, танилцуулга мэдээлэлгүйгээр гол санаануудыг ашиглан, хэрэв та хүсвэл интернетээс бие даан олж авах боломжтой болно.
Үнэн хэрэгтээ, мэдээжийн хэрэг, хөндсөн сэдвүүд нь текстийн өнгө аясыг шаарддаг боловч орчин үеийн ертөнцөд улам олон хүн унших дургүй байдаг))), тиймээс та хурдан уншиж, сонголтоо хийх боломжтой бөгөөд хэрэв ямар нэг зүйл байвал тодорхой биш, холбоосыг дагаж, эсвэл Google-ийн тодорхойгүй үгс))), мөн энэ нийтлэл нь эдгээр гүн сэдвүүдэд зориулсан ил тод боодолтой адил юм, дүүргэлтийг харуулсан - шийдвэр бүрийн гол гол цэгүүд.
Цавуулаг
Виртуал орчинд зориулсан нээлттэй эх сурвалж дээр суурилсан SDS бүхий гиперконвергед платформ үйлдвэрлэгчдийн идэвхтэй ашигладаг Gluster-ээс эхэлцгээе, RedHat вэб сайтын хадгалах хэсэгт байрлах Gluster эсвэл Ceph гэсэн хоёр SDS сонголтоос сонгох боломжтой.
Gluster нь орчуулагчдын стекээс бүрддэг - файл түгээх бүх ажлыг гүйцэтгэдэг үйлчилгээ гэх мэт. Brick нь нэг дискэнд үйлчилгээ үзүүлдэг үйлчилгээ, Volume нь эдгээр тоосгонуудыг нэгтгэдэг эзлэхүүн (усан сан) юм. Дараа нь DHT (тараагдсан хэш хүснэгт) функцийг ашиглан файлуудыг бүлэгт хуваарилах үйлчилгээ гарч ирнэ. Доорх холбоосууд үүнтэй холбоотой асуудлуудыг тайлбарлах тул бид Sharding үйлчилгээг тайлбарт оруулахгүй.
Бичих үед файлыг бүхэлд нь тоосгонд хадгалдаг бөгөөд түүний хуулбарыг хоёр дахь сервер дээр нэгэн зэрэг бичдэг. Дараа нь хоёр дахь файлыг өөр өөр сервер дээр хоёр тоосго (эсвэл түүнээс дээш) хоёр дахь бүлэгт бичнэ.
Хэрэв файлууд нь ойролцоогоор ижил хэмжээтэй бөгөөд эзлэхүүн нь зөвхөн нэг бүлгээс бүрддэг бол бүх зүйл хэвийн, гэхдээ бусад нөхцөлд тайлбараас дараахь асуудлууд гарч ирнэ.
- бүлгүүд дэх орон зай жигд бус ашиглагддаг, энэ нь файлуудын хэмжээнээс хамаардаг бөгөөд хэрэв бүлэгт файл бичих хангалттай зай байхгүй бол та алдаа хүлээн авах бөгөөд файл бичигдээгүй бөгөөд өөр бүлэгт дахин хуваарилагдахгүй. ;
- нэг файл бичих үед IO зөвхөн нэг бүлэгт очдог, үлдсэн хэсэг нь идэвхгүй байна;
- та нэг файл бичихдээ бүх эзлэхүүний IO-г авч чадахгүй;
- ерөнхий үзэл баримтлал нь өгөгдлийг блок болгон хуваарилаагүйгээс бүтээмж багатай харагдаж байгаа бөгөөд энэ нь жигд хуваарилалтын асуудлыг тэнцвэржүүлж, шийдвэрлэхэд хялбар байдаг бөгөөд одоо бүх файл блок руу ордоггүй.
Албан ёсны тайлбараас Бид мөн gluster нь сонгодог техник хангамжийн RAID дээр файл хадгалах үүрэг гүйцэтгэдэг гэдгийг өөрийн эрхгүй ойлгодог. Файлуудыг блок болгон хуваах (хуваах) оролдлого хийсэн боловч энэ бүхэн нь одоо байгаа архитектурын арга барилд гүйцэтгэлийн алдагдал, мөн Fuse гэх мэт гүйцэтгэлийн хязгаарлалттай чөлөөтэй тараагдсан бүрэлдэхүүн хэсгүүдийг ашиглах нэмэлт зүйл юм. Мета өгөгдлийн үйлчилгээ байхгүй бөгөөд энэ нь файлуудыг блок болгон хуваарилах үед хадгалах сангийн гүйцэтгэл, алдааг тэсвэрлэх чадварыг хязгаарладаг. Ачааллын оновчтой хуваарилалт бүхий найдвартай хуулбар 6-ыг зохион байгуулахын тулд "Тараарсан хуулбарласан" тохиргооны тусламжтайгаар илүү сайн гүйцэтгэлийн үзүүлэлтүүдийг ажиглаж болох бөгөөд зангилааны тоо дор хаяж 3 байх ёстой.
Эдгээр олдворууд нь хэрэглэгчийн туршлагын тайлбартай холбоотой юм болон харьцуулах үед , мөн энэхүү илүү бүтээмжтэй, илүү найдвартай тохиргоог ойлгоход хүргэсэн туршлагын тайлбар бий
Зурган дээр хоёр файл бичих үед ачааллын хуваарилалтыг харуулсан бөгөөд эхний файлын хуулбарыг эхний гурван серверт тарааж, тэдгээрийг 0-р бүлэгт нэгтгэж, хоёр дахь файлын гурван хувийг гуравны хоёр дахь бүлгийн 1-р бүлэгт байрлуулна. серверүүд. Сервер бүр нэг дисктэй.
Ерөнхий дүгнэлт нь та Gluster-ийг ашиглаж болно, гэхдээ виртуал орчны тооцооллын ачаалалд нөөц шаардлагатай байгаа гиперконвергеж шийдлийн тодорхой нөхцөлд хүндрэл учруулдаг гүйцэтгэл, алдааг тэсвэрлэх чадварт хязгаарлалт байх болно гэдгийг ойлгосон.
Мөн хязгаарлагдмал нөхцөлд тодорхой нөхцөлд хүрч болох зарим Gluster гүйцэтгэлийн үзүүлэлтүүд байдаг
Кеф
Одоо миний чадаж байсан архитектурын тайлбараас Цефийг харцгаая Энэ хооронд харьцуулалт бас бий , Ceph-ийг тусдаа сервер дээр байрлуулах нь зүйтэй гэдгийг та шууд ойлгох болно, учир нь түүний үйлчилгээ ачаалалтай байгаа бүх техник хангамжийн нөөцийг шаарддаг.
архитектур Gluster-ээс илүү төвөгтэй бөгөөд мета өгөгдлийн үйлчилгээ гэх мэт үйлчилгээнүүд байдаг боловч бүрэлдэхүүн хэсгүүдийн бүх стек нь нэлээд төвөгтэй бөгөөд виртуалчлалын шийдэлд ашиглахад тийм ч уян хатан биш юм. Мэдээллийг блок болгон хадгалдаг бөгөөд энэ нь илүү бүтээмжтэй харагддаг боловч бүх үйлчилгээний (бүрэлдэхүүн хэсгүүдийн) шатлалд тодорхой ачаалал, онцгой байдлын үед алдагдал, хоцрогдол байдаг, жишээлбэл:
Архитектурын тайлбараас харахад зүрх нь CRUSH бөгөөд үүний ачаар өгөгдөл хадгалах байршлыг сонгосон болно. Дараа нь PG ирдэг - энэ нь ойлгоход хамгийн хэцүү хийсвэрлэл (логик бүлэг) юм. CRUSH-ийг илүү үр дүнтэй болгохын тулд PGs хэрэгтэй. PG-ийн гол зорилго нь нөөцийн хэрэглээг багасгах, гүйцэтгэл, өргөтгөх чадварыг нэмэгдүүлэх зорилгоор объектуудыг бүлэглэх явдал юм. Объектуудыг PG болгон нэгтгэхгүйгээр шууд, тус тусад нь хаяглах нь маш үнэтэй байх болно. OSD нь диск бүрийн үйлчилгээ юм.
Кластер нь өөр өөр зорилготой, өөр тохиргоотой нэг буюу олон мэдээллийн сантай байж болно. Усан сангуудыг байрлуулах бүлэгт хуваадаг. Байршлын бүлгүүд нь үйлчлүүлэгчийн ханддаг объектуудыг хадгалдаг. Эндээс логик түвшин дуусч, физик түвшин эхэлдэг, учир нь байршуулах бүлэг бүрт нэг үндсэн диск болон хэд хэдэн хуулбар диск хуваарилагдсан байдаг (энэ нь цөөрмийн хуулбарлах хүчин зүйлээс яг хэд нь хамаарна). Өөрөөр хэлбэл, логик түвшинд объект нь тодорхой байршлын бүлэгт, физик түвшинд - түүнд хуваарилагдсан дискнүүд дээр хадгалагддаг. Энэ тохиолдолд дискүүд нь өөр өөр зангилаанууд эсвэл бүр өөр өөр мэдээллийн төвүүдэд байрладаг.
Энэ схемд байрлуулах бүлгүүд нь бүхэл бүтэн шийдлийн уян хатан байдалд зайлшгүй шаардлагатай түвшин мэт харагддаг, гэхдээ үүнтэй зэрэгцэн энэ гинжин хэлхээний нэмэлт холбоос болж, бүтээмж алдагдахыг санал болгодог. Жишээлбэл, өгөгдлийг бичихдээ систем үүнийг эдгээр бүлгүүдэд хуваах шаардлагатай бөгөөд дараа нь физик түвшинд үндсэн диск болон хуулбарлах дискнүүд рүү хуваах шаардлагатай. Өөрөөр хэлбэл, Hash функц нь объект хайх, оруулах үед ажилладаг боловч гаж нөлөө байдаг - энэ нь маш өндөр зардал бөгөөд хэшийг дахин бүтээхэд хязгаарлалт тавьдаг (диск нэмэх эсвэл хасах үед). Өөр нэг хэш асуудал бол өөрчлөх боломжгүй мэдээллийн байршил юм. Өөрөөр хэлбэл, ямар нэгэн байдлаар диск ачаалал ихтэй байгаа бол систем нь түүнд бичихгүй байх боломж байхгүй (өөр диск сонгох замаар), хэш функц нь өгөгдлийг хичнээн муу байсан ч дүрмийн дагуу байрлуулахыг үүрэг болгодог. диск нь өөрөө эдгээх эсвэл хадгалах хэмжээг нэмэгдүүлэх тохиолдолд PG-г дахин бүтээх үед Ceph маш их санах ой иддэг. Дүгнэлт нь Ceph нь сайн ажилладаг (удаан ч гэсэн), гэхдээ зөвхөн масштаб, онцгой нөхцөл байдал, шинэчлэлт байхгүй үед л ажилладаг.
Мэдээжийн хэрэг, кэш болон кэш хуваалцах замаар гүйцэтгэлийг нэмэгдүүлэх сонголтууд байдаг, гэхдээ энэ нь сайн техник хангамж шаарддаг бөгөөд алдагдалтай хэвээр байх болно. Гэхдээ ерөнхийдөө Цеф бүтээмжийн хувьд Глустерээс илүү сонирхолтой харагдаж байна. Түүнчлэн, эдгээр бүтээгдэхүүнийг ашиглахдаа чухал хүчин зүйлийг харгалзан үзэх шаардлагатай - энэ нь Линукс дээр ихээхэн ач холбогдол өгдөг өндөр түвшний ур чадвар, туршлага, мэргэжлийн ур чадвар юм, учир нь бүх зүйлийг зөв байрлуулах, тохируулах, хадгалах нь маш чухал юм. энэ нь администраторт бүр ч илүү хариуцлага, ачаа үүрүүлдэг.
Хадгалах газар
Архитектур нь илүү сонирхолтой харагдаж байна , ижил зангилаа дээрх гипервизортой хамт хэрэглэж болно , гэхдээ сайн гүйцэтгэлд хүрэхийн тулд бүх зүйлийг зөв тохируулах нь маш чухал юм. Өөрөөр хэлбэл, архитектурын дагуу зөвлөмжийг харгалзахгүйгээр хайрцагнаас ийм бүтээгдэхүүнийг ямар ч тохиргоонд байрлуулах нь маш хялбар боловч бүтээмжгүй байх болно.
Kvm-qemu гипервизорын үйлчилгээнүүдийн хажууд хадгалахад юу байж болох вэ, эдгээр нь бүрэлдэхүүн хэсгүүдийн авсаархан оновчтой шатлалыг олж авсан цөөн хэдэн үйлчилгээ юм: FUSE (өөрчлөгдсөн, нээлттэй эх биш), MDS мета өгөгдлийн үйлчилгээ. (Мета өгөгдлийн үйлчилгээ), физик түвшинд нэг дисктэй тэнцүү байдаг Chunk үйлчилгээний мэдээллийн блокуудын үйлчилгээ. Хурдны хувьд мэдээжийн хэрэг, хоёр хуулбартай эвдрэлд тэсвэртэй схемийг ашиглах нь оновчтой боловч хэрэв та SSD диск дээр кэш, лог ашигладаг бол алдааг тэсвэрлэх кодчилол (кодлолтыг арилгах эсвэл raid6) -ийг сайн overclock хийх боломжтой. эрлийз схем эсвэл бүх флаш дээр бүр илүү сайн. EC-ийн зарим сул тал байдаг (кодлолтыг арилгах): нэг өгөгдлийн блокыг өөрчлөх үед паритетийн хэмжээг дахин тооцоолох шаардлагатай. Энэ үйлдэлтэй холбоотой алдагдлыг тойрч гарахын тулд Ceph нь EC-д хойшлуулсан байдлаар бичдэг ба гүйцэтгэлийн асуудал тодорхой хүсэлтийн үед гарч болзошгүй, жишээлбэл, бүх блокуудыг унших шаардлагатай үед, Virtuozzo Storage-ийн хувьд өөрчлөгдсөн блокуудыг бичих үед. нь "лог бүтэцтэй файлын систем" аргыг ашиглан хийгддэг бөгөөд энэ нь паритетыг тооцоолох зардлыг бууруулдаг. Ойролцоогоор EC-тэй болон EC-гүй ажлыг хурдасгах хувилбаруудыг тооцоолох боломжтой - Тоног төхөөрөмжийн үйлдвэрлэгчийн нарийвчлалын коэффициентээс хамааран тоонууд нь ойролцоо байж болох боловч тооцооллын үр дүн нь тохиргоог төлөвлөхөд сайн туслах болно.
Хадгалах бүрэлдэхүүн хэсгүүдийн энгийн схем нь эдгээр бүрэлдэхүүн хэсгүүдийг шингээдэггүй гэсэн үг биш юм гэхдээ та бүх зардлыг урьдчилан тооцоолсон бол та гипервизорын хажууд хамтран ажиллахад найдаж болно.
Ceph болон Virtuozzo хадгалах үйлчилгээний техник хангамжийн нөөцийн хэрэглээг харьцуулах схем байдаг.
Хэрэв өмнө нь Gluster болон Ceph-ийг хуучин нийтлэлүүдийг ашиглан тэдгээрийн хамгийн чухал мөрүүдийг ашиглан харьцуулах боломжтой байсан бол Virtuozzo-тэй харьцуулахад илүү хэцүү байдаг. Энэ бүтээгдэхүүний талаар олон нийтлэл байдаггүй бөгөөд мэдээллийг зөвхөн дээрх баримт бичгүүдээс авах боломжтой эсвэл Орос хэлээр Vstorage-ийг компаниудад зарим гиперконвергед шийдэлд ашигладаг хадгалалт гэж үзвэл болон Acronis.
Би энэ архитектурын тайлбарт туслахыг хичээх болно, тиймээс арай илүү текст байх болно, гэхдээ баримт бичгийг өөрөө ойлгоход маш их цаг хугацаа шаардагдах бөгөөд одоо байгаа баримт бичгийг зөвхөн хүснэгтийг засварлах замаар лавлагаа болгон ашиглах боломжтой. контент эсвэл түлхүүр үгээр хайх.
Дээр дурдсан бүрэлдэхүүн хэсгүүдтэй эрлийз техник хангамжийн тохиргоонд бичлэг хийх үйл явцыг авч үзье: бичлэг нь үйлчлүүлэгчийн үүсгэсэн зангилаа руу шилжиж эхэлдэг (FUSE холбох цэгийн үйлчилгээ), гэхдээ мета өгөгдлийн үйлчилгээний (MDS) үндсэн бүрэлдэхүүн хэсэг нь мэдээж хэрэг болно. үйлчлүүлэгчийг хүссэн хэсэг үйлчилгээ рүү шууд чиглүүлэх (хадгалах үйлчилгээний CS блокууд), өөрөөр хэлбэл MDS нь бичлэг хийх үйл явцад оролцдоггүй, харин үйлчилгээг шаардлагатай хэсэг рүү чиглүүлдэг. Ерөнхийдөө бид торхонд ус асгахтай адил бичлэг хийж болно. Баррель бүр нь 256 МБ дата блок юм.
Өөрөөр хэлбэл, нэг диск нь тодорхой тооны ийм баррель, өөрөөр хэлбэл дискний эзлэхүүнийг 256 МБ-т хуваасан юм. Хуулбар бүр нь нэг зангилаа руу, хоёр дахь нь бараг нөгөө зангилаатай зэрэгцэн тархдаг гэх мэт... Хэрэв бид гурван хуулбартай бөгөөд кэш (лог унших, бичих зориулалттай) SSD дискүүд байгаа бол бичсэний дараа бичих баталгаажуулалт хийгдэнэ. SSD руу лог, мөн SSD-ээс зэрэгцээ дахин тохируулах нь цаана нь байгаа мэт HDD дээр үргэлжлэх болно. Гурван хуулбарын хувьд гурав дахь зангилааны SSD-ээс баталгаажуулсны дараа бичлэгийг хийнэ. Гурван SSD-ийн бичих хурдны нийлбэрийг гурваар хувааж болох юм шиг санагдаж магадгүй бөгөөд бид нэг хуулбарын бичих хурдыг авах болно, гэхдээ хуулбарууд нь зэрэгцээ бичигдсэн бөгөөд сүлжээний хоцролтын хурд нь ихэвчлэн SSD-ээс өндөр байдаг. мөн үнэндээ бичих гүйцэтгэл нь сүлжээнээс хамаарна. Үүнтэй холбогдуулан жинхэнэ IOPS-ийг харахын тулд та Vstorage-ийг бүхэлд нь зөв ачаалах хэрэгтэй , өөрөөр хэлбэл өгөгдлийн блокийн зөв хэмжээ, хэлхээний тоо гэх мэтийг харгалзан үзэх шаардлагатай санах ой, кэш биш харин бодит ачааллыг турших.
SSD дээрх дээр дурдсан бичлэгийн бүртгэл нь өгөгдөл орж ирмэгц тэр даруй үйлчилгээнээс уншиж, HDD-д бичдэг байдлаар ажилладаг. Нэг кластерт хэд хэдэн мета өгөгдлийн үйлчилгээ (MDS) байдаг бөгөөд тэдгээрийн тоог Paxos алгоритмын дагуу ажилладаг чуулга тодорхойлдог. Үйлчлүүлэгчийн үүднээс FUSE холбох цэг нь кластерын бүх зангилаанд нэгэн зэрэг харагдах кластер хадгалах хавтас бөгөөд зангилаа бүрд энэ зарчмын дагуу суурилуулсан клиент байдаг тул энэ хадгалалт нь зангилаа бүрт боломжтой.
Дээр дурдсан аргуудын аль нэгийг хэрэгжүүлэхийн тулд төлөвлөлт, байршуулалтын үе шатанд сүлжээг зөв тохируулах нь маш чухал бөгөөд үүнд нэгтгэх, зөв сонгогдсон сүлжээний сувгийн зурвасын өргөнөөс шалтгаалан тэнцвэржилт үүснэ. Нэгтгэхдээ хэш хийх горим болон хүрээний хэмжээг зөв сонгох нь чухал юм. Дээр дурдсан SDS-ээс маш хүчтэй ялгаа байгаа бөгөөд энэ нь Virtuozzo Storage дахь хурдан зам технологийн гал хамгаалагч юм. Энэ нь орчин үеийн гал хамгаалагчаас гадна бусад нээлттэй эхийн шийдлүүдээс ялгаатай нь IOPS-ийг ихээхэн нэмэгдүүлж, хэвтээ эсвэл босоо масштабаар хязгаарлагдахгүй байх боломжийг олгодог. Ерөнхийдөө, дээр дурдсан архитектуруудтай харьцуулахад энэ нь илүү хүчирхэг харагдаж байна, гэхдээ ийм таашаал авахын тулд мэдээжийн хэрэг та Ceph, Gluster-ээс ялгаатай нь лиценз худалдаж авах хэрэгтэй.
Дүгнэж хэлэхэд, бид гурвын шилдэгийг онцолж болно: Virtuozzo Storage нь архитектурын гүйцэтгэл, найдвартай байдлын хувьд нэгдүгээр байр, Ceph хоёрдугаар байр, Gluster гуравдугаар байрыг эзэлдэг.
Virtuozzo Storage-ийг сонгосон шалгуур нь: энэ нь хурдан зам, уян хатан тоног төхөөрөмжийн тохиргоо, нөөц бага зарцуулалт, тооцоолол (тооцоолох/виртуалчлал) бүхий энэхүү Гал хамгаалагчийн аргад зориулан шинэчлэгдсэн архитектурын бүрэлдэхүүн хэсгүүдийн оновчтой багц юм. өөрөөр хэлбэл, Энэ нь бүрэн тохиромжтой юм hyperconverged шийдэл , түүний нэг хэсэг нь. Хоёрдугаарт Ceph нь блокоор ажилладаг, илүү уян хатан хувилбар, том кластерт ажиллах чадвартай учраас Gluster-тэй харьцуулахад илүү бүтээмжтэй архитектур юм.
vSAN, Space Direct Storage, Vstorage болон Nutanix Storage-ийн харьцуулалт, HPE болон Huawei төхөөрөмж дээр Vstorage-г турших, мөн Vstorage-г гадаад техник хангамжийн хадгалах системтэй нэгтгэх хувилбаруудыг бичихээр төлөвлөж байгаа тул нийтлэл танд таалагдсан бол Та бүхний санал хүсэлт, хүсэлтийг харгалзан шинэ нийтлэл гаргах сэдлийг нэмэгдүүлэх боломжтой санал хүсэлтийг авахдаа таатай байна.
Эх сурвалж: www.habr.com