Шинэчлэх!. Сэтгэгдэл дээр уншигчдын нэг нь оролдохыг санал болгов (магадгүй тэр өөрөө үүн дээр ажиллаж байгаа байх) тиймээс би энэ шийдлийн талаар хэсэг нэмсэн. Би ч бас бичсэн , учир нь үйл явц нь бусадтай харьцуулахад маш их ялгаатай.
Үнэнийг хэлэхэд би бууж өгсөн, бууж өгсөн (ядаж одоохондоо). Би ашиглах болно . Яагаад? Хадгалалтын улмаас! Намайг Кубернетесээс илүү агуулахтай холбоотой асуудал гарна гэж хэн санах билээ. би хэрэглэдэг Учир нь энэ нь хямд бөгөөд гүйцэтгэл нь сайн бөгөөд би анхнаасаа кластеруудыг ашиглаж байна. . Би өөрөө бүгдийг сурахыг хүссэн учраас Google/Amazon/Microsoft/DigitalOcean гэх мэтийн удирддаг Kubernetes үйлчилгээг туршиж үзээгүй. Би бас хэмнэлттэй.
Тийм ээ, би Kubernetes стекийг үнэлэхдээ аль хадгалах санг сонгохоо шийдэх гэж маш их цаг зарцуулсан. Би нээлттэй эхийн шийдлүүдийг илүүд үздэг, зөвхөн үнийн хувьд ч биш, гэхдээ хязгаарлалттай үнэгүй хувилбарууд байдаг тул би сонирхсондоо төлбөртэй хэд хэдэн сонголтыг авч үзсэн. Би янз бүрийн хувилбаруудыг харьцуулахдаа сүүлийн үеийн туршилтуудын зарим тоог тэмдэглэсэн бөгөөд тэдгээр нь Kubernetes хадгалах сангийн талаар суралцсан хүмүүст сонирхолтой байж магадгүй юм. Хэдийгээр би хувьдаа Кубернетестэй одоохондоо баяртай гэж хэлсэн. Би бас дурдмаар байна , энэ нь Hetzner Cloud-ийн хэмжээг шууд хангах боломжтой, гэхдээ би үүнийг хараахан туршиж үзээгүй байна. Надад хуулбарлах, ямар ч зангилаа дээр, ялангуяа зангилааны эвдрэл болон бусад ижил төстэй нөхцөл байдлын үед байнгын эзлэхүүнийг хурдан холбох чадвартай байх шаардлагатай байсан тул би үүлэн програм хангамжаар тодорхойлсон хадгалах санг судалж үзсэн. Зарим шийдэл нь агшин зуурын агшин зуурын зураг болон сайтаас гадуур нөөцлөлтийг санал болгодог бөгөөд энэ нь тохиромжтой.
Би 6-7 хадгалах шийдлийг туршиж үзсэн:
Би аль хэдийн хэлсэнчлэн Жагсаалтын ихэнх сонголтыг туршиж үзээд би OpenEBS дээр суурьшсан. OpenEBS нь суулгах, ашиглахад маш хялбар боловч үнэнийг хэлэхэд ачааллын үед бодит өгөгдөлтэй туршилт хийсний дараа түүний гүйцэтгэлд сэтгэл дундуур байсан. Энэ бол нээлттэй эх сурвалж бөгөөд хөгжүүлэгчид өөрсдөө юм надад тусламж хэрэгтэй үед үргэлж тусалдаг. Харамсалтай нь энэ нь бусад сонголтуудтай харьцуулахад маш муу гүйцэтгэлтэй тул туршилтыг дахин явуулах шаардлагатай болсон. OpenEBS одоогоор 3 хадгалах системтэй, гэхдээ би cStor-ийн жишиг үр дүнг нийтэлж байна. Надад Jiva болон LocalPV-ийн дугаар одоогоор алга.
Товчхондоо, Jiva нь арай хурдан бөгөөд LocalPV нь ерөнхийдөө хурдан бөгөөд дискний жишиг үзүүлэлтээс дордохгүй. LocalPV-тэй холбоотой асуудал бол эзлэхүүнийг зөвхөн бэлтгэсэн цэг дээр нь хандах боломжтой бөгөөд хуулбарлах зүйл огт байхгүй. Нөөцлөлтийг сэргээхэд надад асуудал гарсан зангилааны нэр өөр байсан тул шинэ кластер дээр. Хэрэв бид нөөцлөлтийн талаар ярих юм бол cStor-д байдаг , үүний тусламжтайгаар та агшин зуурын зургийг сайтаас гадуур нөөцлөх боломжтой бөгөөд энэ нь Velero-Restic ашиглан файлын түвшний нөөцлөлтөөс илүү тохиромжтой. би бичсэн , энэ залгаасын тусламжтайгаар нөөцлөлт болон сэргээлтийг удирдахад хялбар болгох. Ерөнхийдөө би OpenEBS-д үнэхээр дуртай, гэхдээ түүний гүйцэтгэл...
Rook нь мөн нээлттэй эх сурвалж бөгөөд жагсаалтад байгаа бусад сонголтуудаас ялгаатай нь хадгалалтын удирдлагын нарийн төвөгтэй даалгавруудыг өөр өөр арын хэсэгт гүйцэтгэдэг, жишээ нь. , болон бусад, энэ нь ажлыг ихээхэн хялбаршуулдаг. Хэдэн сарын өмнө би EfgeFS-тэй холбоотой асуудал гарсан тул би голчлон Ceph-ээр туршиж үзсэн. Ceph нь зөвхөн блок санах ойг санал болгодог төдийгүй S3/Swift болон тархсан файлын системтэй нийцтэй объект хадгалах боломжтой. Ceph-ийн надад таалагддаг зүйл бол эзлэхүүний мэдээллийг олон дискээр тараах чадвар бөгөөд ингэснээр эзлэхүүн нь нэг дискэнд багтаахаас илүү дискний зайг ашиглах боломжтой юм. Энэ нь тухтай. Өөр нэг гайхалтай онцлог нь таныг кластерт диск нэмэхэд бүх дискний өгөгдлийг автоматаар дахин хуваарилдаг явдал юм.
Ceph-д хормын хувилбарууд байгаа ч миний мэдэж байгаагаар тэдгээрийг Rook/Kubernetes-д шууд ашиглах боломжгүй. Үнэн, би энэ талаар гүнзгийрээгүй. Гэхдээ сайтаас гадуур нөөцлөлт байхгүй тул та Velero/Restic-тэй ямар нэгэн зүйл ашиглах хэрэгтэй болно, гэхдээ зөвхөн файлын түвшний нөөцлөлтүүд байдаг бөгөөд агшин зуурын агшин зуурын агшин зуурын зураг биш. Рукийн надад үнэхээр таалагдсан зүйл бол Ceph-тэй ажиллахад маш хялбар байсан - энэ нь бараг бүх төвөгтэй зүйлсийг нууж, алдааг олж засварлах зорилгоор Ceph-тэй шууд ярилцах хэрэгслийг санал болгодог. Харамсалтай нь, Ceph volume-ийн стресс тестийн үеэр би асуудалтай хэвээр байсан , энэ нь Цефийг тогтворгүй болоход хүргэдэг. Энэ нь Сефийн алдаа уу эсвэл Рук Сефийг удирдаж байгаатай холбоотой асуудал уу гэдэг нь одоогоор тодорхойгүй байна. Би санах ойн тохиргоог хийсэн бөгөөд энэ нь сайжирсан боловч асуудал бүрэн шийдэгдээгүй. Цеф нь сайн гүйцэтгэлтэй байгааг та доорх жишиг үзүүлэлтээс харж болно. Энэ нь бас сайн хяналтын самбартай.
Би Лонгхорнд үнэхээр дуртай. Миний бодлоор энэ бол ирээдүйтэй шийдэл юм. Үнэн бол хөгжүүлэгчид өөрсдөө (Rancher Labs) энэ нь ажлын орчинд тохиромжгүй байгааг хүлээн зөвшөөрдөг бөгөөд үүнийг харуулж байна. Энэ нь нээлттэй эх сурвалж бөгөөд хангалттай гүйцэтгэлтэй (хэдийгээр тэд үүнийг хараахан оновчтой болгоогүй байгаа боловч) эзлэхүүнийг подволд холбоход маш удаан хугацаа шаардагддаг бөгөөд хамгийн муу тохиолдолд, ялангуяа том нөөцлөлтийг сэргээсний дараа эсвэл 15-16 минут болдог. ажлын ачааллыг сайжруулах. Энэ нь агшин зуурын зураг болон эдгээр агшин агшнуудын сайтаас гадуур нөөцлөлттэй боловч тэдгээр нь зөвхөн хэмжээст хамаарах тул бусад нөөцийг нөөцлөхийн тулд танд Velero шиг зүйл хэрэгтэй болно. Нөөцлөх, сэргээх нь маш найдвартай боловч зохисгүй удаашралтай байдаг. Үнэнийг хэлэхэд, үнэхээр удаан. Longhorn-д дунд хэмжээний өгөгдөлтэй ажиллах үед CPU-ийн хэрэглээ болон системийн ачаалал ихэвчлэн нэмэгддэг. Лонгхорныг удирдахад тохиромжтой хяналтын самбар байдаг. Би Longhorn-д дуртай гэдгээ аль хэдийн хэлсэн, гэхдээ үүнд бага зэрэг ажиллах шаардлагатай байна.
StorageOS бол жагсаалтын анхны төлбөртэй бүтээгдэхүүн юм. Энэ нь 500 ГБ-ын хязгаарлагдмал удирдлагатай хадгалах багтаамжтай хөгжүүлэгчийн хувилбартай боловч зангилааны тоонд хязгаарлалт байхгүй гэж би бодож байна. Борлуулалтын алба надад хэрэв би буруу санаж байвал 125 TB-ийн зардал сард 1 доллараас эхэлдэг гэж хэлсэн. Үндсэн хяналтын самбар, тохиромжтой CLI байдаг, гэхдээ гүйцэтгэлд хачирхалтай зүйл тохиолдож байна: зарим жишиг үзүүлэлтээр энэ нь хангалттай сайн байсан ч эзлэхүүний стресс тестийн хувьд хурд нь надад огт таалагдаагүй. Ерөнхийдөө би юу хэлэхээ мэдэхгүй байна. Тиймээс би нэг их юм ойлгосонгүй. Энд сайтаас гадуур нөөцлөлт байхгүй бөгөөд та мөн эзлэхүүнийг нөөцлөхийн тулд Restic-тэй Velero-г ашиглах хэрэгтэй болно. Энэ нь хачирхалтай, учир нь бүтээгдэхүүн нь төлбөртэй байдаг. Мөн хөгжүүлэгчид Slack дээр харилцах хүсэлгүй байсан.
Би Reddit дээрх Робиныг техникийн захирлаас нь мэдсэн. Би түүний тухай өмнө нь сонсож байгаагүй. Магадгүй би үнэ төлбөргүй шийдлийг хайж байсан болохоор Робин цалинтай. Тэд 10TB хадгалах багтаамжтай, гурван зангилаа бүхий өгөөмөр үнэгүй хувилбартай. Ерөнхийдөө бүтээгдэхүүн нь маш сайн, сайхан шинж чанартай байдаг. Гайхалтай CLI байдаг, гэхдээ хамгийн гайхалтай нь та програмыг бүхэлд нь (нөөц сонгогч дээр үүнийг Helm хувилбарууд эсвэл "flex програмууд" гэж нэрлэдэг) агшин зуурын зургийг авч нөөцлөх боломжтой бөгөөд боть болон бусад нөөцийг багтаасан бөгөөд ингэснээр та Veleroгүйгээр хийх боломжтой. Нэг жижиг нарийн ширийн зүйл биш бол бүх зүйл сайхан байх болно: хэрэв та шинэ кластер дээрх програмыг сэргээвэл (эсвэл "импорт" гэж Робин хэлснээр) - жишээлбэл, гамшгийн дараа сэргэсэн тохиолдолд - сэргээх, Мэдээжийн хэрэг, ажилладаг, гэхдээ програмыг үргэлжлүүлэн нөөцлөхийг хориглоно. Энэ хувилбарт энэ нь зүгээр л боломжгүй гэдгийг хөгжүүлэгчид баталсан. Энэ нь зөөлөн хэлэхэд хачирхалтай, ялангуяа бусад давуу талуудыг (жишээлбэл, маш хурдан нөөцлөх, сэргээх) харгалзан үзэх нь хачирхалтай юм. Хөгжүүлэгчид дараагийн хувилбарт бүх зүйлийг засахаа амлаж байна. Гүйцэтгэл нь ерөнхийдөө сайн, гэхдээ би нэг хачирхалтай зүйлийг анзаарсан: хэрэв би жишиг тестийг хост дээр хавсаргасан эзлэхүүн дээр шууд ажиллуулбал унших хурд нь ижил хэмжээний эзлэхүүнийг под дотроос ажиллуулахаас хамаагүй хурдан болно. Бусад бүх үр дүн ижил боловч онолын хувьд ялгаа байх ёсгүй. Хэдийгээр тэд үүн дээр ажиллаж байгаа ч сэргээх, нөөцлөхтэй холбоотой асуудалд сэтгэл дундуур байсан - би эцэст нь тохирох шийдлийг олсон гэж бодож байсан бөгөөд надад илүү зай эсвэл илүү сервер хэрэгтэй үед би үүнийг төлөхөд бэлэн байсан.
Надад энд хэлэх нэг их зүйл алга. Энэ бол төлбөртэй бүтээгдэхүүн бөгөөд адилхан сэрүүн, үнэтэй. Гүйцэтгэл нь ердөө л гайхалтай юм. Энэ бол одоогоор хамгийн сайн үзүүлэлт юм. Slack надад Google-ийн GKE Marketplace-д жагсаасан үнэ нь зангилаа тус бүрд сард 205 доллараас эхэлдэг гэж хэлсэн. Шууд авбал хямдрах эсэхийг мэдэхгүй. Би ямар ч байсан үүнийг төлж чадахгүй тул хөгжүүлэгчийн лиценз (1 TB ба 3 зангилаа хүртэл) нь статик хангамжид сэтгэл хангалуун бус байвал Кубернетес-д бараг хэрэггүй болсонд би маш их сэтгэл дундуур байсан. Туршилтын хугацаа дуусахад лицензийг автоматаар хөгжүүлэгчид бууруулна гэж найдаж байсан ч тийм зүйл болсонгүй. Хөгжүүлэгчийн лицензийг зөвхөн Docker-тэй шууд ашиглах боломжтой бөгөөд Kubernetes дахь тохиргоо нь маш төвөгтэй бөгөөд хязгаарлагдмал байдаг. Мэдээжийн хэрэг, би нээлттэй эх сурвалжийг илүүд үздэг, гэхдээ надад мөнгө байсан бол би мэдээж Portworx-ыг сонгох байсан. Одоогийн байдлаар түүний гүйцэтгэл нь бусад сонголтуудтай харьцуулагдахгүй байна.
Нийтлэл нийтлэгдсэний дараа нэг уншигч Linstor-ийг туршиж үзэхийг санал болгосны дараа би энэ хэсгийг нэмсэн. Би үүнийг туршиж үзсэн бөгөөд надад таалагдсан! Гэхдээ бид илүү гүнзгий ухах хэрэгтэй хэвээр байна. Одоо би гүйцэтгэл муу биш гэж хэлж чадна (би жишиг үр дүнг доор нэмсэн). Үндсэндээ би дисктэй ижил гүйцэтгэлийг ямар ч ачаалалгүйгээр шууд авсан. (Portworx яагаад хөтөчийн жишиг үзүүлэлтээс илүү сайн үзүүлэлттэй байгааг бүү асуу. Би ямар ч ойлголтгүй байна. Ид шид, би таамаглаж байна.) Тиймээс Линстор одоогоор маш үр дүнтэй харагдаж байна. Энэ нь суулгахад тийм ч хэцүү биш боловч бусад сонголттой адил хялбар биш юм. Эхлээд би Linstor (цөмийн модуль ба хэрэгслүүд/үйлчилгээнүүд) суулгаж, LVM-г Kubernetes-ээс гадуур, шууд хост дээр нимгэн нөөцлөх, агшин зуурын дэмжлэг үзүүлэхээр тохируулах, дараа нь Kubernetes-ээс хадгалах санг ашиглахад шаардлагатай нөөцийг бий болгох шаардлагатай болсон. Энэ нь CentOS дээр ажиллахгүй байгаа нь надад таалагдаагүй бөгөөд би Ubuntu-г ашиглахаас өөр аргагүй болсон. Мэдээжийн хэрэг аймшигтай биш, гэхдээ бага зэрэг ядаргаатай, учир нь баримт бичигт (дашрамд хэлэхэд энэ нь маш сайн) Epel-ийн заасан репозиторуудаас олж чадахгүй хэд хэдэн багцыг дурдсан байдаг. Linstor-д агшин зуурын зураг байгаа боловч сайтаас гадуур нөөцлөлт байхгүй тул энд дахин эзлэхүүнийг нөөцлөхийн тулд Restic-тэй Velero-г ашиглах шаардлагатай болсон. Би файлын түвшний нөөцлөлтийн оронд агшин зуурын зургийг илүүд үзэх болно, гэхдээ шийдэл нь гүйцэтгэлтэй, найдвартай байвал үүнийг тэвчих боломжтой. Linstor нь нээлттэй эх сурвалж боловч төлбөртэй дэмжлэг үзүүлдэг. Хэрэв би зөв ойлгосон бол дэмжлэг үзүүлэх гэрээгүй байсан ч үүнийг хязгаарлалтгүйгээр ашиглаж болно, гэхдээ үүнийг тодруулах хэрэгтэй. Linstor-ийг Kubernetes-д хэр туршиж үзсэнийг би мэдэхгүй, гэхдээ хадгалах давхарга нь өөрөө Кубернетесээс гадуур байгаа бөгөөд шийдэл нь өчигдөр гарч ирээгүй тул бодит нөхцөлд аль хэдийн туршиж үзсэн байх магадлалтай. Намайг бодлоо өөрчилж, Кубернетес рүү буцах шийдэл энд байна уу? Би мэдэхгүй байна. Бид илүү гүнзгий ухаж, хуулбарыг судлах шаардлагатай хэвээр байна. Харцгаая. Гэхдээ анхны сэтгэгдэл сайхан байна. Би илүү эрх чөлөөтэй байж, шинэ зүйл сурахын тулд Херокугийн оронд өөрийн Кубернетес кластеруудыг ашиглахыг илүүд үзэх нь гарцаагүй. Линсторыг суулгах нь бусадтай адил хялбар биш тул удахгүй энэ тухай нийтлэл бичих болно.
Жишиг үзүүлэлт
Харамсалтай нь би энэ талаар бичнэ гэж бодоогүй тул харьцуулалтын талаар нэг их тэмдэглэл хөтөлсөнгүй. Надад зөвхөн үндсэн fio жишиг болон зөвхөн нэг зангилааны кластерын үр дүн байгаа тул хуулбарласан тохиргооны тоо хараахан алга. Гэхдээ эдгээр үр дүнгээс та сонголт бүрээс юу хүлээж болох талаар ойролцоогоор ойлголттой болох боломжтой, учир нь би тэдгээрийг ижил үүлэн серверүүд, 4 цөм, 16 ГБ RAM, шалгасан хэмжээнүүдэд нэмэлт 100 ГБ дисктэй харьцуулсан. Би шийдэл бүрийн хувьд жишиг шалгуурыг гурван удаа хийж, дундаж үр дүнг тооцож, бүтээгдэхүүн бүрийн серверийн тохиргоог дахин тохируулсан. Энэ бүхэн шинжлэх ухааны үндэслэлгүй, зөвхөн ерөнхий ойлголт өгөхийн тулд. Бусад туршилтуудад би унших, бичихийг шалгахын тулд эзлэхүүнээс 38 ГБ зураг, видео хуулсан боловч харамсалтай нь би тоог хадгалаагүй. Товчхондоо: Portworkx илүү хурдан байсан.
Эзлэхүүний жишигт зориулж би энэ манифестыг ашигласан:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: dbench
spec:
storageClassName: ...
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
name: dbench
spec:
template:
spec:
containers:
- name: dbench
image: sotoaster/dbench:latest
imagePullPolicy: IfNotPresent
env:
- name: DBENCH_MOUNTPOINT
value: /data
- name: FIO_SIZE
value: 1G
volumeMounts:
- name: dbench-pv
mountPath: /data
restartPolicy: Never
volumes:
- name: dbench-pv
persistentVolumeClaim:
claimName: dbench
backoffLimit: 4Би эхлээд тохирох хадгалах ангитай боть үүсгээд дараа нь тайзны ард fio-тай ажлыг гүйцэтгэсэн. Гүйцэтгэлийг тооцоолохын тулд би 1 ГБ зарцуулсан бөгөөд хэтэрхий удаан хүлээхгүй. Үр дүн нь энд байна:
Би хэмжигдэхүүн бүрийн хамгийн сайн утгыг ногоон өнгөөр, хамгийн мууг нь улаанаар онцолсон.
дүгнэлт
Таны харж байгаагаар ихэнх тохиолдолд Portworx бусдаас илүү сайн ажилласан. Гэхдээ миний хувьд энэ нь үнэтэй. Робин ямар үнэтэйг мэдэхгүй байна, гэхдээ тэдгээр нь маш сайн үнэ төлбөргүй хувилбартай тул хэрэв та төлбөртэй бүтээгдэхүүн авахыг хүсвэл үүнийг туршиж үзэх боломжтой (тэд удахгүй сэргээх болон нөөцлөлттэй холбоотой асуудлыг засна гэж найдаж байна). Гурван үнэгүй хувилбараас би OpenEBS-тэй холбоотой хамгийн бага асуудалтай байсан ч гүйцэтгэл нь маш муу байна. Би илүү үр дүнг хадгалаагүйд харамсалтай байна, гэхдээ тоонууд болон миний сэтгэгдэл танд тусална гэж найдаж байна.
Эх сурвалж: www.habr.com