Өнгөрсөн оны сүүлээр Оросын PostgreSQL нийгэмлэгийн өөр нэг шууд нэвтрүүлэг болсон , энэ үеэр түүний үүсгэн байгуулагч Николай Самохвалов Flant-ийн техникийн захирал Дмитрий Столяровтой Кубернетесийн хүрээнд энэхүү DBMS-ийн талаар ярилцав.
Бид энэхүү хэлэлцүүлгийн гол хэсгийн бичлэгийг нийтэлж байна, мөн at Бүрэн видеог нийтэлсэн:
Өгөгдлийн сан ба Кубернетес
НС: Өнөөдөр бид ВАКУМ, ШАЛГАХ ЦЭГИЙН талаар ярихгүй. Бид Кубернетесийн тухай ярихыг хүсч байна. Таныг олон жилийн туршлагатай гэдгийг би мэднэ. Би таны видеог үзсэн, бүр заримыг нь дахин үзсэн... Шууд зүйлдээ орцгооё: яагаад Postgres эсвэл K8s дээр MySQL?
DC: Энэ асуултад тодорхой хариулт байхгүй, боломжгүй. Гэхдээ ерөнхийдөө энэ бол энгийн, тохь тухтай ... боломж юм. Хүн бүр удирдлагатай үйлчилгээг хүсдэг.
НС: Яаж , зөвхөн гэртээ?
DC: Тийм: RDS шиг, хаана ч байсан.
НС: "Хаана ч" гэдэг бол сайн санаа. Томоохон компаниудад бүх зүйл өөр өөр газар байрладаг. Хэрэв том компани юм бол яагаад бэлэн шийдэл авч болохгүй гэж? Жишээлбэл, Nutanix нь өөрийн гэсэн хөгжүүлэлттэй, бусад компаниуд (VMware...) ижил "RDS, зөвхөн гэртээ" байдаг.
DC: Гэхдээ бид зөвхөн тодорхой нөхцөлд ажиллах тусдаа хэрэгжилтийн талаар ярьж байна. Хэрэв бид Kubernetes-ийн тухай ярьж байгаа бол маш олон төрлийн дэд бүтэц байдаг (энэ нь K8-д байж болно). Үндсэндээ энэ нь үүлэнд зориулсан API стандарт юм...
НС: Энэ нь бас үнэгүй!
DC: Энэ тийм ч чухал биш. Зах зээлийн тийм ч том биш сегментийн хувьд эрх чөлөө чухал. Өөр нэг чухал зүйл байна ... Та тайланг санаж байгаа байх ""?
НС: Тиймээ.
DC: Маш хоёрдмол утгатай хүлээж авсныг ойлгосон. Зарим хүмүүс намайг “Залуус аа, бүх мэдээллийн санг Кубернетес рүү оруулъя!” гэж хэлж байна гэж бодож байсан бол зарим нь эдгээр нь бүгд аймшигтай унадаг дугуй гэж шийдсэн. Гэхдээ би огт өөр зүйл хэлэхийг хүссэн: “Юу болоод байгааг, ямар асуудал байгааг, яаж шийдвэрлэхийг хар л даа. Бид одоо Kubernetes мэдээллийн санг ашиглах ёстой юу? Үйлдвэрлэл үү? За, хэрэв та дуртай бол ... тодорхой зүйлийг хийх. Гэхдээ хөгжүүлэгчийн хувьд би үүнийг зөвлөж байна гэж хэлж болно. Хөгжүүлэгчийн хувьд орчин үүсгэх/устгах динамик нь маш чухал юм."
Н.С.: Хөгжүүлэгч гэж та бүтээгдээгүй бүх орчныг хэлж байна уу? Тайлбар, QA…
DC: Хэрэв бид төгс тавиурын тухай ярьж байгаа бол тэнд тавигдах шаардлага нь тодорхой байгаа тул үгүй байх. Хэрэв бид үе шат хийхэд маш том мэдээллийн сан шаардлагатай онцгой тохиолдлуудын тухай ярьж байгаа бол магадгүй тийм биш байх ... Хэрэв энэ нь статик, урт наслалттай орчин юм бол мэдээллийн сан K8s дээр байрласан нь ямар ашигтай вэ?
НС: Байхгүй. Гэхдээ бид статик орчныг хаанаас харж байна вэ? Статик орчин маргааш хуучирна.
DC: Тайлбар нь статик байж болно. Бидэнд үйлчлүүлэгчид бий...
НС: Тийм ээ, надад ч бас бий. Хэрэв та 10 TB мэдээллийн сантай, 200 ГБ хэмжээтэй бол энэ нь маш том асуудал юм ...
DC: Надад маш сайхан хэрэг байна! Үзүүлэн дээр өөрчлөлт оруулсан бүтээгдэхүүний мэдээллийн сан байдаг. Мөн "үйлдвэрлэлд шилжүүлэх" гэсэн товчлуур бий. Эдгээр өөрчлөлтүүд - дельта нь үйлдвэрлэлд нэмэгдсэн (тэдгээрийг API-ээр дамжуулан синхрончлогдсон юм шиг санагддаг). Энэ бол маш чамин сонголт юм.
НС: Би хөндийд RDS эсвэл бүр Херокуд сууж байгаа стартапуудыг харсан - эдгээр нь 2-3 жилийн өмнөх түүхүүд бөгөөд тэд хог хаягдлыг зөөврийн компьютер дээрээ татаж авдаг. Учир нь мэдээллийн сан нь ердөө 80 ГБ хэвээр байгаа бөгөөд зөөврийн компьютер дээр зай байгаа. Дараа нь тэд хүн бүрт нэмэлт диск худалдаж авдаг бөгөөд ингэснээр өөр өөр хөгжүүлэлт хийх 3 мэдээллийн сантай болно. Энэ нь бас ийм байдлаар тохиолддог. Тэд бүтээлийг тайзнаа хуулбарлахаас айдаггүйг би бас харсан - энэ нь компаниас ихээхэн хамаардаг. Гэхдээ тэд маш их айдаг, ихэвчлэн цаг хугацаа, гар хүрэлцэхгүй байгааг би харсан. Гэхдээ бид энэ сэдэв рүү шилжихээсээ өмнө Кубернетесийн талаар сонсохыг хүсч байна. Одоохондоо хэн ч үйлдвэрлэлд ороогүй гэдгийг би зөв ойлгож байна уу?
DC: Бидэнд жижиг мэдээллийн сан бий. Бид хуулбар хийхээс залхуурсан хэдэн арван гигабайтын хэмжээ, чухал бус үйлчилгээний талаар ярьж байна (мөн тийм шаардлага байхгүй). Мөн Kubernetes-ийн доор ердийн хадгалах газар байгаа тохиолдолд. Энэ мэдээллийн сан нь виртуал машин дээр ажилладаг байсан - нөхцөлт байдлаар VMware дээр, хадгалах системийн дээд талд. Бид үүнийг байрлуулсан одоо бид үүнийг машинаас машин руу шилжүүлж болно.
НС: Ийм хэмжээтэй 100 ГБ хүртэлх мэдээллийн санг хэдхэн минутын дотор сайн диск, сайн сүлжээгээр ашиглах боломжтой, тийм үү? Секундэд 1 ГБ хурд нь чамин биш болсон.
DC: Тиймээ, шугаман үйлдлийн хувьд энэ нь асуудал биш юм.
НС: За, бид зөвхөн бүтээгдэхүүний талаар бодох хэрэгтэй. Хэрэв бид Kubernetes-ийг үйлдвэрлэлийн бус орчинд ашиглах гэж байгаа бол бид юу хийх ёстой вэ? Би үүнийг Заландод харж байна , Crunchy-д , бусад сонголтууд байна. Бас байдаг - энэ бол Испаниас ирсэн бидний сайн найз Алваро: тэдний хийдэг зүйл бол зүгээр л нэг зүйл биш юм , мөн бүхэл бүтэн хуваарилалт (), үүнд Postgres-ээс гадна Элч төлөөлөгч прокси-г нөөцлөхөөр шийдсэн ...
DC: Юуны төлөө элч вэ? Postgres урсгалыг тусгайлан тэнцвэржүүлэх үү?
НС: Тиймээ. Өөрөөр хэлбэл, тэд үүнийг дараах байдлаар хардаг: хэрэв та Linux түгээлт ба цөмийг авбал ердийн PostgreSQL нь цөм бөгөөд тэд үүлд ээлтэй, Kubernetes дээр ажиллах түгээлт хийхийг хүсдэг. Тэд бүрэлдэхүүн хэсгүүдийг (нөөцлөлт гэх мэт) нэгтгэж, сайн ажиллахын тулд дибаг хийдэг.
DC: Маш сайхан! Үндсэндээ энэ нь өөрийн удирддаг Postgres үүсгэх програм хангамж юм.
НС: Линуксийн түгээлтүүд нь мөнхийн асуудалтай байдаг: бүх техник хангамжийг дэмжихийн тулд драйверуудыг хэрхэн хийх вэ. Мөн тэд Kubernetes-д ажиллана гэсэн санаатай байдаг. Zalando оператор дээр бид саяхан AWS-тэй холбогдохыг харсан бөгөөд энэ нь тийм ч сайн биш болсныг би мэднэ. Тодорхой дэд бүтэцтэй холбоотой байх ёсгүй - тэгвэл ямар учиртай вэ?
DC: Заландо яг ямар нөхцөл байдалд орсныг би мэдэхгүй байна, гэхдээ Kubernetes-д одоо ерөнхий аргыг ашиглан дискний нөөцлөлт хийх боломжгүй болсон. Саяхан стандартад - хамгийн сүүлийн хувилбарт - Бид хормын хувилбаруудыг хийх боломжтой болгосон, гэхдээ үүнийг хаана хэрэгжүүлж байна вэ? Үнэнийг хэлэхэд, бүх зүйл маш түүхий хэвээр байна ... Бид AWS, GCE, Azure, vSphere дээр CSI-г туршиж байна, гэхдээ та үүнийг ашиглаж эхлэхэд хараахан бэлэн болоогүй байгааг харж болно.
НС: Тийм учраас бид заримдаа дэд бүтцэд найдах хэрэгтэй болдог. Энэ бол эрт үе шат - өсөн нэмэгдэж буй өвдөлт гэж би бодож байна. Асуулт: PgSQL-г K8 дээр туршиж үзэхийг хүсч буй шинэхэн хүмүүст та ямар зөвлөгөө өгөх вэ? Ямар оператор байж болох вэ?
DC: Асуудал нь Postgres бол бидний хувьд 3% юм. Бидэнд Кубернетес дэх өөр өөр програм хангамжийн маш том жагсаалт байгаа тул би бүгдийг нь жагсаахгүй. Жишээлбэл, Elasticsearch. Маш олон операторууд байдаг: зарим нь идэвхтэй хөгжиж байгаа, зарим нь тийм биш юм. Бид үүнийг нухацтай авч үзэхийн тулд оператор юу байх ёстой талаар өөрсдөдөө шаардлага тавьсан. Kubernetes-д тусгайлан зориулсан операторт - "Amazon-ийн нөхцөлд ямар нэгэн зүйл хийх оператор"-д биш ... Үнэндээ бид нэлээд өргөн хүрээнд (= бараг бүх үйлчлүүлэгчид) нэг оператор ашигладаг - (Бид түүний тухай нийтлэлийг удахгүй нийтлэх болно).
НС: Мөн MySQL-д зориулсан биш гэж үү? Percona... тэд одоо MySQL, MongoDB болон Postgres дээр ажиллаж байгаа тул бүх мэдээллийн сан, бүх үүлэн үйлчилгээ үзүүлэгч нарт зориулсан бүх нийтийн шийдлийг бий болгох хэрэгтэй болно гэдгийг би мэднэ.
DC: Бидэнд MySQL-ийн операторуудыг үзэх цаг байсангүй. Энэ нь одоогоор бидний гол анхаарал хандуулах зүйл биш юм. MySQL бие даасан байдлаар сайн ажилладаг. Хэрэв та зүгээр л мэдээллийн сан ажиллуулж чадвал яагаад оператор ашиглах хэрэгтэй вэ... Та Postrges-тэй Docker контейнер ажиллуулж болно, эсвэл энгийн аргаар ажиллуулж болно.
НС: Энэ талаар бас нэг асуулт байсан. Оператор огт байхгүй юу?
DC: Тийм ээ, бидний 100% PostgreSQL нь операторгүйгээр ажилладаг. Одоог хүртэл. Бид Prometheus болон Redis-ийн операторыг идэвхтэй ашигладаг. Бид Elasticsearch-ийн операторыг олохоор төлөвлөж байна - энэ нь хамгийн "галтай" оператор юм, учир нь бид үүнийг 100% тохиолдолд Кубернетес дээр суулгахыг хүсч байна. Яг л бид MongoDB-г Кубернетес дээр байнга суулгаж байхыг хүсч байна. Энд тодорхой хүсэл эрмэлзэл гарч ирдэг - эдгээр тохиолдолд ямар нэгэн зүйл хийж болно гэсэн мэдрэмж байдаг. Тэгээд бид Постгресийг хараагүй. Мэдээжийн хэрэг, бид янз бүрийн хувилбарууд байдгийг мэдэж байгаа ч үнэн хэрэгтээ бид бие даасан байдаг.
Kubernetes дээр турших DB
НС: Туршилтын сэдэв рүүгээ орцгооё. Өгөгдлийн сангийн өөрчлөлтийг хэрхэн яаж нэвтрүүлэх вэ - DevOps-ийн үүднээс. Микро үйлчилгээ, олон мэдээллийн сан байдаг, хаа нэгтээ ямар нэг зүйл байнга өөрчлөгдөж байдаг. DBMS-ийн үүднээс бүх зүйл эмх цэгцтэй байхын тулд хэвийн CI/CD-г хэрхэн хангах вэ. Та ямар арга барилтай вэ?
DC: Нэг хариулт байж болохгүй. Хэд хэдэн сонголт байна. Эхнийх нь бидний гаргахыг хүсч буй суурийн хэмжээ юм. Үйлдвэрлэлийн мэдээллийн баазыг хөгжүүлэлт, тайз дээр хуулбарлах тал дээр компаниуд өөр өөр хандлагатай байдаг гэж та өөрөө хэлсэн.
НС: Мөн GDPR-ийн нөхцөлд тэд улам болгоомжтой байгаа гэж би бодож байна ... Европт тэд торгууль ногдуулаад эхэлчихсэн гэж би хэлж чадна.
DC: Гэхдээ ихэнхдээ та үйлдвэрлэлээс дамп авч, түүнийг бүдгэрүүлдэг программ хангамж бичиж болно. Бүтээгдэхүүний өгөгдлийг олж авдаг (хормын хувилбар, дамп, хоёртын хуулбар...), гэхдээ энэ нь нэргүй болно. Үүний оронд үүслийн скриптүүд байж болно: эдгээр нь бэхэлгээ эсвэл зүгээр л том мэдээллийн сан үүсгэдэг скрипт байж болно. Асуудал нь: үндсэн зургийг бүтээхэд хэр хугацаа шаардагдах вэ? Мөн хүссэн орчинд нь байрлуулахад хэр хугацаа шаардагдах вэ?
Бид схемд хүрсэн: хэрэв үйлчлүүлэгч тогтмол өгөгдлийн багцтай (өгөгдлийн сангийн хамгийн бага хувилбар) байвал бид тэдгээрийг анхдагч байдлаар ашигладаг. Хэрэв бид хянан шалгах орчны тухай ярьж байгаа бол салбар үүсгэх үед бид програмын жишээг байрлуулсан - бид тэнд жижиг мэдээллийн санг гаргадаг. Гэхдээ энэ нь сайн болсон , бид өдөрт нэг удаа (шөнийн цагаар) үйлдвэрлэлээс овоолгыг авч, түүн дээр тулгуурлан PostgreSQL болон MySQL-тэй Docker контейнер барих үед. Хэрэв та энэ зургаас мэдээллийн санг 50 дахин өргөжүүлэх шаардлагатай бол үүнийг маш энгийн бөгөөд хурдан хийдэг.
НС: Энгийн хуулбарлах замаар уу?
DC: Мэдээллийг Docker дүрс дээр шууд хадгалдаг. Тэдгээр. Бидэнд 100 ГБ ч гэсэн бэлэн зураг байгаа. Docker дахь давхаргын ачаар бид энэ зургийг хүссэн хэмжээгээрээ хурдан байрлуулж чадна. Энэ арга нь тэнэг боловч сайн ажилладаг.
НС: Дараа нь, та тест хийх үед энэ нь Docker дотор өөрчлөгддөг, тийм үү? Docker доторх хуулбарлах, бичих - үүнийг хаяад дахин яв, бүх зүйл хэвийн байна. Анги! Мөн та үүнийг аль хэдийн бүрэн ашиглаж байна уу?
DC: Урт хугацаанд.
НС: Бид маш төстэй зүйл хийдэг. Зөвхөн бид Docker-ийн хуулбарыг бичихгүй, харин өөр нэгийг ашигладаг.
DC: Энэ нь нийтлэг биш юм. Мөн Docker хаа сайгүй ажилладаг.
НС: Онолын хувьд тийм. Гэхдээ бидэнд бас модуль байдаг, та өөр өөр модуль хийж, өөр өөр файлын системтэй ажиллах боломжтой. Энд ямар хором вэ. Postgres талаас бид энэ бүхнийг өөрөөр харж байна. Одоо би Докерын талаас харахад бүх зүйл таны төлөө ажиллаж байгааг харлаа. Гэхдээ хэрэв мэдээллийн сан нь асар том, жишээ нь 1 TB бол энэ бүхэн маш их цаг хугацаа шаарддаг: шөнийн цагаар үйл ажиллагаа явуулах, бүх зүйлийг Docker руу чихэх ... Тэгээд 5 TB-г Docker-д чихвэл... Эсвэл бүх зүйл зүгээр үү?
DC: Ялгаа нь юу вэ: эдгээр нь бөмбөлөгүүд, зүгээр л бит ба байт юм.
НС: Ялгаа нь: та үүнийг dump болон сэргээх замаар хийдэг үү?
DC: Огт шаардлагагүй. Энэ зургийг бүтээх арга нь өөр байж болно.
НС: Зарим үйлчлүүлэгчдэд зориулж бид үүнийг үндсэн дүр төрхийг байнга үүсгэхийн оронд байнга шинэчилж байхаар хийсэн. Энэ нь үндсэндээ хуулбар юм, гэхдээ энэ нь өгөгдлийг мастераас шууд биш, харин архиваар дамжуулан хүлээн авдаг. WAL-уудыг өдөр бүр татаж авдаг, нөөцлөлтүүдийг авдаг хоёртын архив... Дараа нь эдгээр WAL-ууд үндсэн зурагтаа бага зэрэг саатал (шууд утгаараа 1-2 секунд) хүрдэг. Бид үүнээс ямар ч байдлаар хувилдаг - одоо бидэнд анхдагчаар ZFS байна.
DC: Гэхдээ ZFS-ийн тусламжтайгаар та нэг зангилаагаар хязгаарлагддаг.
НС: Тиймээ. Гэхдээ ZFS-д бас ид шид бий : үүнтэй хамт та хормын хувилбар илгээж болно, тэр ч байтугай (би үүнийг хараахан туршиж үзээгүй байна, гэхдээ ...) та хоёрын хооронд дельта илгээх боломжтой. PGDATA. Үнэн хэрэгтээ бидэнд ийм даалгаварт зориулж огт авч үзээгүй өөр хэрэгсэл бий. PostgreSQL-д байдаг , энэ нь "ухаалаг" rsync шиг ажилладаг бөгөөд үзэх шаардлагагүй олон зүйлийг алгасдаг, учир нь тэнд юу ч өөрчлөгдөөгүй. Бид хоёр серверийн хооронд хурдан синхрончлол хийж, ижил аргаар буцаах боломжтой.
Тиймээс, үүнээс илүү DBA талаас нь бид таны хэлсэнтэй ижил зүйлийг хийх боломжийг олгодог хэрэгслийг бий болгохыг оролдож байна: бидэнд нэг мэдээллийн сан байгаа, гэхдээ бид ямар нэг зүйлийг 50 удаа, бараг нэгэн зэрэг туршиж үзэхийг хүсч байна.
DC: 50 удаа та 50 Spot instance захиалах хэрэгтэй гэсэн үг.
НС: Үгүй ээ, бид бүгдийг нэг машин дээр хийдэг.
DC: Гэхдээ энэ мэдээллийн сан нь терабайт юм бол яаж 50 дахин тэлэх вэ. Түүнд нөхцөлт 256 ГБ RAM хэрэгтэй байх магадлалтай юу?
НС: Тийм ээ, заримдаа танд маш их санах ой хэрэгтэй байдаг - энэ бол хэвийн зүйл. Гэхдээ энэ бол амьдралаас авсан жишээ юм. Үйлдвэрлэлийн машин нь 96 цөм, 600 ГБ багтаамжтай. Үүний зэрэгцээ мэдээллийн санд 32 цөм (заримдаа 16 цөм ч байдаг) болон 100-120 ГБ санах ойг ашигладаг.
DC: Тэгээд 50 хувь багтах уу?
НС: Тэгэхээр ганцхан хуулбар байна, дараа нь copy-on-write (ZFS) ажилладаг... Би танд илүү дэлгэрэнгүй хэлье.
Жишээлбэл, бид 10 TB мэдээллийн сантай. Тэд үүнд зориулж диск хийсэн, ZFS мөн түүний хэмжээг 30-40 хувиар шахаж гаргасан. Бид ачааллын туршилт хийдэггүй тул яг хариу өгөх хугацаа нь бидний хувьд чухал биш: 2 дахин удаашруулна - зүгээр.
Бид програмистууд, QA, DBA гэх мэт боломжийг олгодог. туршилтыг 1-2 хэлхээнд хийнэ. Жишээлбэл, тэд ямар нэгэн төрлийн шилжилт хөдөлгөөн хийж болно. Энэ нь нэг дор 10 цөм шаарддаггүй - үүнд 1 Postgres backend, 1 цөм хэрэгтэй. Шилжилт хөдөлгөөн эхлэх болно - магадгүй эхэлсэн хэвээр байх болно, дараа нь хоёр дахь цөмийг ашиглах болно. Манайд 16-32 цөм хуваарилагдсан тул 10 хүн зэрэг ажиллах боломжтой, асуудалгүй.
Учир нь бие махбодийн хувьд PGDATA Үүнтэй адилаар бид Постгресийг хуурч байгаа нь харагдаж байна. Энэ заль мэх нь: жишээлбэл, 10 Postgres-ийг нэгэн зэрэг эхлүүлдэг. Ихэвчлэн ямар асуудал гардаг вэ? Тэд тавьсан , 25% гэж бодъё. Үүний дагуу энэ нь 200 ГБ юм. Та эдгээрээс гурваас илүүг эхлүүлэх боломжгүй, учир нь санах ой дуусах болно.
Гэхдээ хэзээ нэгэн цагт бид энэ шаардлагагүй гэдгийг ойлгосон: бид shared_buffers-ийг 2 ГБ болгож тохируулсан. PostgreSQL-д байдаг , мөн бодит байдал дээр энэ нь зөвхөн нөлөөлдөг . Бид үүнийг 0,5 TB болгон тохируулсан. Тэд үнэхээр байхгүй байх нь хамаагүй: тэр байгаа юм шиг төлөвлөгөө гаргадаг.
Үүний дагуу бид ямар нэгэн шилжилт хөдөлгөөнийг туршиж үзэхэд бид бүх төлөвлөгөөг цуглуулж чадна - энэ нь үйлдвэрлэлд хэрхэн өрнөхийг харах болно. Тэнд байгаа секундууд өөр өөр байх болно (удаан), гэхдээ бидний уншсан өгөгдөл, төлөвлөгөөнүүд өөрсдөө (ямар NOIN-ууд байдаг гэх мэт) нь үйлдвэрлэлийнхтэй яг адилхан болж хувирдаг. Мөн та ийм олон шалгалтыг нэг машин дээр зэрэгцүүлэн хийж болно.
DC: Энд хэдэн асуудал байгаа гэж бодохгүй байна уу? Эхнийх нь зөвхөн PostgreSQL дээр ажилладаг шийдэл юм. Энэ арга нь маш хувийн шинж чанартай бөгөөд энэ нь ерөнхий биш юм. Хоёрдахь зүйл бол Кубернетес (мөн одоо үүлэн технологид нэвтэрч буй бүх зүйл) олон зангилаатай бөгөөд эдгээр зангилаа нь түр зуурынх юм. Мөн таны тохиолдолд энэ нь төлөвтэй, байнгын зангилаа юм. Эдгээр зүйлс намайг зөрчилдүүлж байна.
НС: Нэгдүгээрт, энэ бол цэвэр Postgres түүх гэдгийг би зөвшөөрч байна. Хэрэв бид ямар нэгэн шууд IO болон бараг бүх санах ойд зориулсан буфер сантай бол энэ арга нь ажиллахгүй болно - төлөвлөгөө өөр байх болно. Гэхдээ одоогоор бид зөвхөн Postgres-тэй ажилладаг, бусдын тухай боддоггүй.
Кубернетесийн тухай. Та өөрөө бидэнд байнгын мэдээллийн сантай гэж хаа сайгүй хэлдэг. Хэрэв жишээ амжилтгүй болвол гол зүйл бол дискийг хадгалах явдал юм. Энд бид Кубернетес дэх бүх платформтой бөгөөд Postgres-тэй бүрэлдэхүүн хэсэг нь тусдаа байдаг (хэдийгээр нэг өдөр тэнд байх болно). Тиймээс бүх зүйл ийм байна: инстанс унасан боловч бид түүний PV-г хадгалж, юу ч болоогүй мэт өөр (шинэ) инстанц руу холбосон.
DC: Миний бодлоор бид Kubernetes дээр pods үүсгэдэг. K8s - уян харимхай: шаардлагатай бол зангилаа захиална. Даалгавар бол зүгээр л pod үүсгэж, түүнд X хэмжээний нөөц хэрэгтэй гэж хэлэх бөгөөд дараа нь K8-ууд үүнийг өөрөө олох болно. Гэхдээ Кубернетес дэх хадгалах сангийн дэмжлэг тогтворгүй хэвээр байна: , in (энэ хувилбар гарсан долоо хоног өмнө) эдгээр функцууд зөвхөн бета хувилбар болж хувирдаг.
Зургаан сараас нэг жил өнгөрөх болно - энэ нь бага эсвэл тогтвортой байх болно, эсвэл ядаж үүнийг тунхаглах болно. Дараа нь агшин зуурын зураг авах, хэмжээг өөрчлөх боломж нь таны асуудлыг бүрэн шийддэг. Учир нь танд суурь бий. Тиймээ, энэ нь тийм ч хурдан биш байж болох ч хурд нь "бүрээсний доор" байгаа зүйлээс хамаарна, учир нь зарим хэрэгжүүлэлт нь дискний дэд системийн түвшинд хуулж, бичих боломжтой.
НС: Мөн бүх хөдөлгүүрүүд (Amazon, Google...) энэ хувилбарыг дэмжиж эхлэх шаардлагатай - үүнд бас цаг хугацаа шаардагдана.
DC: Бид тэдгээрийг хараахан ашиглаагүй байна. Бид өөрсдийнхийгөө ашигладаг.
Kubernetes-ийн орон нутгийн хөгжил
НС: Нэг машин дээр бүх подволкуудыг суулгаад ийм жижиг тест хийх шаардлагатай байхад ийм хүсэл тааралдсан уу. Үзэл баримтлалын нотолгоог хурдан авахын тулд програм нь Кубернетес дээр ажилладаг бөгөөд үүнд зориулж олон тооны машин зориулалгүйгээр хараарай. Minikube байгаа биз дээ?
DC: Нэг зангилаа дээр байрлуулсан энэ хэрэг зөвхөн орон нутгийн хөгжлийн тухай юм шиг санагдаж байна. Эсвэл ийм хэв маягийн зарим илрэлүүд. Идэх , энд байна , . Бид Kubernetes IN Docker-ийг ашиглахаар явж байна. Одоо бид түүнтэй туршилт хийхээр ажиллаж эхэлсэн.
НС: Энэ нь бүх pods-ыг нэг Докерын дүрсэнд оруулах оролдлого гэж би боддог байсан. Гэвч энэ нь огт өөр зүйлийн тухай болох нь тогтоогдсон. Ямар ч байсан тусдаа сав, тусдаа савнууд байдаг - зүгээр л Docker-д.
DC: Тиймээ. Мөн нэлээд инээдтэй дуураймал хийсэн боловч утга нь энэ юм... Бидэнд байршуулах хэрэгсэл байна - . Бид үүнийг нөхцөлт горим болгохыг хүсч байна werf up: "Надад орон нутгийн Кубернетесийг аваач." Тэгээд тэнд нөхцөлийг ажиллуул werf follow. Дараа нь хөгжүүлэгч нь IDE-г засах боломжтой бөгөөд өөрчлөлтийг харж, зургийг дахин бүтээж, орон нутгийн K8-д дахин байршуулах процессыг системд эхлүүлэх болно. Ингэж л орон нутгийн хөгжлийн асуудлыг шийдмээр байна.
K8s бодит байдал дээр агшин зуурын зураг болон мэдээллийн санг клончлох
НС: Хэрэв бид copy-on-write руу буцвал. Үүлнүүд ч бас агшин зуурын зурагтай байдгийг би анзаарсан. Тэд өөрөөр ажилладаг. Жишээлбэл, GCP-д: танд АНУ-ын зүүн эрэгт олон терабайтын жишээ байна. Та үе үе агшин зуурын зураг авдаг. Та баруун эрэг дээрх дискний хуулбарыг агшин зуурын зургаас аваарай - хэдхэн минутын дотор бүх зүйл бэлэн болно, энэ нь маш хурдан ажилладаг, зөвхөн кэшийг санах ойд бөглөх шаардлагатай. Гэхдээ эдгээр клонууд (хормын хувилбарууд) нь шинэ боть гаргахын тулд юм. Та олон тохиолдлууд үүсгэх шаардлагатай үед энэ нь гайхалтай юм.
Гэхдээ туршилтын хувьд таны Docker дээр эсвэл миний ZFS, btrfs, тэр ч байтугай LVM дээр ярьдаг хормын хувилбарууд нь танд нэг машин дээр үнэхээр шинэ өгөгдөл үүсгэхгүй байх боломжийг олгодог. Үүлэн дээр та тэдний төлбөрийг цаг тутамд төлж, секунд биш, харин хэдэн минут хүлээх болно (мөн тохиолдолд , цаг байж магадгүй).
Үүний оронд та энэ өгөгдлийг хоёр секундын дотор авч, тестийг ажиллуулж, хаяж болно. Эдгээр хормын хувилбарууд нь янз бүрийн асуудлыг шийддэг. Эхний тохиолдолд - томсгож, шинэ хуулбар авах, хоёрдугаарт - тест хийх.
DC: Би санал нийлэхгүй байна. Эзлэхүүний клончлолыг зөв ажиллуулах нь үүлний даалгавар юм. Би тэдний хэрэгжилтийг хараагүй ч техник хангамж дээр үүнийг хэрхэн хийдгийг би мэднэ. Бидэнд Ceph байгаа, энэ нь ямар ч физик эзлэхүүнийг зөвшөөрдөг () хэлэх хуулбар хэдэн арван миллисекундэд ижил шинж чанартай хоёр дахь боть авах, Ами гэх мэт. Дотор нь бичихэд төвөгтэй хуулбар байдаг гэдгийг та ойлгох хэрэгтэй. Үүл яагаад ийм зүйл хийж болохгүй гэж? Тэд үүнийг ямар нэг байдлаар хийхийг оролдож байгаа гэдэгт би итгэлтэй байна.
НС: Гэхдээ жишээ босгох, Докерыг тэнд авчрах гэх мэт хэдэн секунд, хэдэн арван секунд шаардлагатай.
DC: Яагаад заавал бүхэл бүтэн жишээ татах шаардлагатай байна вэ? Бидэнд 32 цөмтэй, 16... жишээтэй, үүнд багтах боломжтой - жишээлбэл, дөрөв. Бид тав дахь удаагаа захиалах үед инстанс аль хэдийн босч, дараа нь устгагдах болно.
НС: Тийм ээ, сонирхолтой, Кубернетес бол өөр түүх юм. Манай мэдээллийн сан K8-д байдаггүй бөгөөд бидэнд нэг тохиолдол бий. Гэхдээ олон терабайтын мэдээллийн санг хувилахад хоёр секундээс илүүгүй хугацаа шаардагдана.
DC: Энэ үнэхээр сайхан. Гэхдээ миний анхны санаа бол энэ бол ерөнхий шийдэл биш юм. Тийм ээ, энэ нь дажгүй, гэхдээ энэ нь зөвхөн Postgres-д тохиромжтой бөгөөд зөвхөн нэг зангилаа дээр.
НС: Энэ нь зөвхөн Postgres-д тохирохгүй: миний тайлбарласнаар эдгээр төлөвлөгөөнүүд зөвхөн үүнд л ажиллах болно. Гэхдээ хэрэв бид төлөвлөгөөний талаар санаа зовохгүй, функциональ туршилт хийхэд бүх өгөгдөл хэрэгтэй бол энэ нь ямар ч DBMS-д тохиромжтой.
DC: Олон жилийн өмнө бид LVM агшин зуурын зураг дээр үүнтэй төстэй зүйл хийж байсан. Энэ бол сонгодог. Энэ аргыг маш идэвхтэй ашигласан. Төлөв зангилаа нь зүгээр л өвдөлт юм. Учир нь та тэднийг унагах ёсгүй, үргэлж санаж байх ёстой ...
НС: Энд эрлийз байх магадлалтай гэж та харж байна уу? Статистик гэдэг нь хэд хэдэн хүнд (олон тестер) зориулагдсан гэж бодъё. Бидэнд нэг боть байгаа боловч файлын системийн ачаар клонууд нь орон нутгийнх юм. Хэрэв хонхорхой унасан ч диск нь хэвээр байвал подвол босож, бүх клонуудын мэдээллийг тоолж, бүх зүйлийг дахин аваад: "Эдгээр портууд дээр таны клонууд ажиллаж байна, тэдэнтэй үргэлжлүүлэн ажиллана уу" гэж хэлээрэй.
DC: Техникийн хувьд энэ нь Кубернетес дотор олон Postgres ажиллуулдаг нэг pod гэсэн үг юм.
НС: Тиймээ. Түүнд хязгаар бий: түүнтэй нэг дор 10-аас илүү хүн ажилладаггүй гэж бодъё. Хэрэв танд 20 ширхэг хэрэгтэй бол бид хоёр дахь ийм подволк гаргах болно. Бид үүнийг бүрэн клончлох болно, хоёр дахь бүрэн боть хүлээн авснаар энэ нь ижил 10 "нимгэн" клонтой болно. Та энэ боломжийг харахгүй байна уу?
DC: Бид энд аюулгүй байдлын асуудлыг нэмэх хэрэгтэй. Энэ төрлийн байгууллага нь файлын систем дээр стандарт бус үйлдлүүдийг хийж чаддаг учраас энэ pod нь өндөр давуу эрхтэй (чадвартай) гэсэн үг юм... Гэхдээ би давтан хэлье: Дунд хугацаанд тэд Kubernetes дахь хадгалалтыг засах болно гэдэгт би итгэж байна. үүлс тэд түүхийг бүхэлд нь засах болно - бүх зүйл "зүгээр л ажиллах болно". Хэмжээг өөрчлөх, хувилах болно... Эзлэхүүн бий - бид: "Үүнд тулгуурлан шинийг бий болго" гэж хэлээд, секунд хагасын дараа бид хэрэгтэй зүйлээ олж авдаг.
НС: Би олон терабайтын нэг хагас секундэд итгэдэггүй. Ceph дээр та өөрөө үүнийг хийдэг, гэхдээ та үүлний тухай ярьдаг. Клоуд руу очоод EC2 дээр олон терабайт EBS эзлэхүүний клон хийж, гүйцэтгэл ямар байхыг хараарай. Энэ нь хэдэн секунд шаардахгүй. Хэзээ ийм түвшинд хүрэх бол гэдэг нь их сонирхолтой. Би таны юу хэлж байгааг ойлгож байна, гэхдээ би зөрүүдлэхийг хүсч байна.
DC: За, гэхдээ би богино хугацаанд биш дунд хугацаанд хэлсэн. Хэдэн жилийн турш.
Zalando-ийн PostgreSQL-д зориулсан операторын тухай
Энэ уулзалтын дундуур Заландогийн хөгжүүлэгч асан Алексей Клюкин бас нэгдэж, PostgreSQL операторын түүхийн талаар ярив.
Энэ сэдвийг ерөнхийд нь хөндөж байгаа нь гайхалтай юм: Postgres болон Kubernetes хоёулаа. 2017 онд бид үүнийг Заландо-д хийж эхлэхэд энэ нь хүн бүрийн хийхийг хүсдэг сэдэв байсан ч хэн ч хийгээгүй. Хүн бүр аль хэдийн Kubernetes-тэй байсан ч мэдээллийн сантай юу хийх талаар асуухад хүмүүс хүртэл дуртай байсан K8-ийг номлосон , дараах зүйлийг хэлэв.
"Удирдлагатай үйлчилгээнүүд рүү очоод тэдгээрийг ашигла, Кубернетес дэх мэдээллийн баазыг бүү ажиллуул. Үгүй бол таны K8-ууд шинэчлэл хийхээр шийдэж, бүх зангилааг унтрааж, таны өгөгдөл маш хол, хол нисэх болно."
Бид энэхүү зөвлөгөөний эсрэгээр Кубернетес дэх Postgres мэдээллийн санг нээх оператор хийхээр шийдсэн. Бидэнд сайн шалтгаан байсан - . Энэ нь PostgreSQL-д автоматаар шилжүүлэлт хийх бөгөөд зөв хийгдсэн, өөрөөр хэлбэл. etcd, consul эсвэл ZooKeeper-ийг кластерын талаарх мэдээллийн сан болгон ашиглах. Жишээлбэл, одоогийн удирдагч гэж хэн бэ гэж асуусан бүх хүнд ижил мэдээлэл өгөх ийм агуулах нь тархи хуваагдахгүй байхын тулд бүх зүйлийг тараасан ч гэсэн. Дээрээс нь бидэнд байсан түүнд.
Ерөнхийдөө компанийн дотоод техник хангамжийн дата төвөөс үүлэн систем рүү шилжсэний дараа автоматаар солих хэрэгцээ гарч ирсэн. Үүл нь өмчийн PaaS (Platform-as-a-Service) шийдэл дээр суурилсан байв. Энэ нь Нээлттэй эхийн программ хэдий ч үүнийг эхлүүлэхийн тулд маш их хөдөлмөр зарцуулсан. Үүнийг дуудаж байсан .
Эхэндээ Кубернетес гэж байгаагүй. Бүр тодруулбал, бидний өөрсдийн шийдлийг ашиглах үед K8-ууд аль хэдийн байсан боловч энэ нь маш түүхий байсан тул үйлдвэрлэхэд тохиромжгүй байв. Энэ бол миний бодлоор 2015 эсвэл 2016 он байсан. 2017 он гэхэд Кубернетес бага багаар төлөвшсөн - тийшээ нүүх шаардлагатай болсон.
Мөн бид аль хэдийн Docker контейнертэй байсан. Docker ашигладаг PaaS байсан. Яагаад K8-ийг туршиж болохгүй гэж? Яагаад өөрийн оператороо бичиж болохгүй гэж? Авито хотоос бидэн дээр ирсэн Мурат Кабилов үүнийг өөрийн санаачилгаар "тоглох" төсөл болгон эхлүүлж, төсөл "хөдөлгөөнтэй болсон".
Гэхдээ би ерөнхийдөө AWS-ийн талаар ярихыг хүссэн. Яагаад AWS-тэй холбоотой түүхэн код байсан бэ?
Та Kubernetes-д ямар нэгэн зүйл ажиллуулахдаа K8s бол ийм ажил хийгдэж байгааг ойлгох хэрэгтэй. Энэ нь байнга хөгжиж, сайжирч, бүр үе үе эвдэрч байдаг. Та Кубернетес дэх бүх өөрчлөлтийг анхааралтай ажиглаж, ямар нэгэн зүйл тохиолдвол түүнд шумбаж, энэ нь хэрхэн ажилладагийг нарийвчлан судлахад бэлэн байх хэрэгтэй - магадгүй таны хүссэнээс илүү юм. Энэ нь зарчмын хувьд таны өгөгдлийн санг ажиллуулдаг аливаа платформд хамаатай...
Тиймээс, бид мэдэгдлийг хийхдээ Postgres-ийг гадаад эзлэхүүн дээр ажиллуулсан (энэ тохиолдолд EBS, бид AWS дээр ажиллаж байсан). Мэдээллийн сан томорч, хэзээ нэгэн цагт түүний хэмжээг өөрчлөх шаардлагатай болсон: жишээлбэл, EBS-ийн анхны хэмжээ нь 100 TB байсан, мэдээллийн сан түүн рүү өссөн, одоо бид EBS 200 TB болгохыг хүсч байна. Хэрхэн? Та шинэ жишээн дээр дамп/сэргээх боломжтой гэж бодъё, гэхдээ энэ нь удаан хугацаа шаардагдах бөгөөд зогсолттой байх болно.
Тиймээс би EBS хуваалтыг томруулж, дараа нь файлын системд шинэ зай ашиглахыг хэлэх хэмжээг өөрчлөхийг хүссэн. Бид үүнийг хийсэн, гэхдээ тэр үед Kubernetes-д хэмжээг өөрчлөх ямар ч API байхгүй байсан. Бид AWS дээр ажиллаж байсан болохоор API-д нь код бичсэн.
Бусад платформ дээр ижил зүйлийг хийхэд тань хэн ч саад болохгүй. Энэ нь зөвхөн AWS дээр ажиллах боломжтой гэсэн мэдэгдэлд байхгүй бөгөөд бусад бүх зүйл дээр ажиллахгүй. Ерөнхийдөө энэ бол Нээлттэй эхийн төсөл юм: хэрэв хэн нэгэн шинэ API-ийн хэрэглээг хурдасгахыг хүсч байвал урьж байна. Идэх , татах хүсэлт - Zalando баг тэдэнд маш хурдан хариу өгч, операторыг сурталчлахыг хичээдэг. Миний мэдэхээр төсөл Google Summer of Code болон бусад ижил төстэй санаачилга дээр. Заландо үүн дээр маш идэвхтэй ажиллаж байна.
PS урамшуулал!
Хэрэв та PostgreSQL болон Kubernetes-ийн сэдвийг сонирхож байгаа бол дараагийн Postgres Мягмар гараг өнгөрсөн долоо хоногт болсон бөгөөд би Николайтай ярилцсан гэдгийг анхаарна уу. Заландогийн Александр Кукушкин. Үүнээс видеог үзэх боломжтой .
PPS
Мөн манай блог дээрээс уншина уу:
- «";
- «";
- «";
- «".
Эх сурвалж: www.habr.com