Мэдээллийн технологийн салбар ямар нэг шалтгаанаар “төлөв” болон “эсэргүү” гэсэн хоёр болзолт лагерьт хуваагдсан түүхтэй. Түүнээс гадна маргааны сэдэв нь бүрэн дур зоргоороо байж болно. Аль үйлдлийн систем нь дээр вэ: Win эсвэл Linux? Android эсвэл iOS ухаалаг гар утсан дээр үү? Та бүх зүйлийг үүлэн дотор хадгалах уу, эсвэл хүйтэн RAID хадгалах санд хийж боолтыг нь сейфэнд хийх үү? РНР хүмүүс программист гэж нэрлэгдэх эрхтэй юу? Эдгээр маргаан нь заримдаа зөвхөн оршин тогтнох шинж чанартай бөгөөд спортын ашиг сонирхлоос өөр үндэслэлгүй байдаг.
Чингэлэг, докер болон нөхцөлт k8 бүхий энэ бүх дуртай хоол гарч ирснээр арын хэсгийн янз бүрийн хэсэгт шинэ боломжуудыг ашиглах "тэмцэх" ба "эсрэг" мэтгэлцээн эхэлсэн юм. (Хэдийгээр энэ хэлэлцүүлэгт Кубернетесийг ихэвчлэн найруулагчаар зааж өгөх боловч энэ хэрэгслийг сонгох нь тийм ч чухал биш гэдгийг урьдчилан сануулъя. Үүний оронд та өөрт хамгийн тохиромжтой, танил санагдсан өөр хэрэгслийг сольж болно. .)
Мөн энэ нь нэг зоосны хоёр талын хоорондох энгийн маргаан байх шиг байна. Дунд нь хаа нэгтээ хангалттай хүмүүс байдаг Win vs Linux-ийн хоорондох мөнхийн сөргөлдөөн шиг утгагүй бөгөөд өршөөлгүй. Гэхдээ савны хувьд бүх зүйл тийм ч хялбар биш юм. Ихэнхдээ ийм маргаантай тохиолдолд зөв тал байдаггүй, гэхдээ мэдээллийн санг хадгалах савыг "ашиглах" эсвэл "ашиглахгүй" тохиолдолд бүх зүйл орвонгоороо эргэж байдаг. Яагаад гэвэл тодорхой утгаараа энэ хандлагыг дэмжигчид ч, эсэргүүцэгчид ч зөв.
Гэгээтэй тал
Гэрэлт талын аргументыг нэг өгүүлбэрээр товч тайлбарлаж болно: "Сайн уу, 2k19 цонхны гадна байна!" Энэ нь мэдээж популизм мэт сонсогдож байгаа ч нөхцөл байдлыг нарийвчлан судлах юм бол давуу талтай. Одоо тэдгээрийг цэгцэлье.
Та том вэб төсөлтэй гэж бодъё. Энэ нь эхлээд микро үйлчилгээний хандлагын үндсэн дээр бүтээгдсэн байж болох юм, эсвэл хэзээ нэгэн цагт хувьслын замаар ирсэн - энэ нь тийм ч чухал биш юм. Та манай төслийг тусдаа бичил үйлчилгээ болгон тарааж, зохион байгуулалт, ачааллын тэнцвэржүүлэлт, масштабыг тохируулсан. Одоо, цэвэр ухамсартайгаар та хабра эффектийн үеэр унасан серверүүдийг өсгөхийн оронд гамак дотор можито шимж байна. Гэхдээ бүх үйлдэлдээ тууштай байх ёстой. Маш олон удаа зөвхөн програм өөрөө буюу код нь савлагдсан байдаг. Бидэнд кодоос өөр юу байгаа вэ?
Энэ нь зөв, өгөгдөл. Аливаа төслийн гол цөм нь түүний өгөгдөл юм: энэ нь ердийн DBMS - MySQL, Postgre, MongoDB эсвэл хайлт хийхэд ашигладаг санах ой (ElasticSearch), кэш хийх түлхүүр-утга хадгалах сан - жишээлбэл, redis гэх мэт байж болно. Одоогоор бид тийм биш байна. Муу бичигдсэн асуулгаас болж өгөгдлийн сан гацах үед бид хазайсан backend хэрэгжүүлэх сонголтуудын талаар ярих бөгөөд оронд нь үйлчлүүлэгчийн ачаалал дор яг энэ мэдээллийн сангийн алдааг тэсвэрлэх чадварыг хангах талаар ярих болно. Эцсийн эцэст, бид аппликейшнээ багтааж, ямар ч тооны ирж буй хүсэлтийг боловсруулахад чөлөөтэй масштабтай болгохыг зөвшөөрвөл энэ нь өгөгдлийн сангийн ачааллыг нэмэгдүүлдэг.
Үнэн хэрэгтээ мэдээллийн санд хандах суваг, түүний ажиллаж буй сервер нь манай үзэсгэлэнтэй савласан арын хэсэгт зүүний нүд болдог. Үүний зэрэгцээ, чингэлэг виртуалчлалын гол сэдэл нь бүтцийн хөдөлгөөнт байдал, уян хатан байдал бөгөөд энэ нь бидэнд байгаа бүх дэд бүтцэд оргил ачааллын хуваарилалтыг аль болох үр дүнтэй зохион байгуулах боломжийг олгодог. Өөрөөр хэлбэл, бид системийн одоо байгаа бүх элементүүдийг кластерт багтааж, түгээхгүй бол бид маш ноцтой алдаа гаргаж байна.
Зөвхөн програмыг төдийгүй өгөгдлийг хадгалах үүрэгтэй үйлчилгээг кластер болгох нь илүү логик юм. K8-д бие даан ажилладаг, ачааллыг хооронд нь хуваарилдаг вэб серверүүдийг кластер хийж, байрлуулснаар бид мэдээллийн синхрончлолын асуудлыг аль хэдийн шийдэж байна - хэрэв бид зарим хэвлэл мэдээллийн хэрэгсэл эсвэл блог платформыг жишээ болгон авч үзвэл нийтлэл дээрх ижил тайлбар. Ямар ч тохиолдолд бид өгөгдлийн сангийн ExternalService хэлбэрээр кластер доторх, тэр ч байтугай виртуал төлөөлөлтэй байдаг. Асуулт бол мэдээллийн сан нь өөрөө хараахан кластерлагдаагүй байгаа явдал юм - шоо дотор байрлуулсан вэб серверүүд нь тусдаа эргэлддэг манай статик байлдааны мэдээллийн сангаас өөрчлөлтийн мэдээллийг авдаг.
Та баригдаж байгааг мэдэрч байна уу? Бид ачааллыг хуваарилж, үндсэн вэб серверийг сүйрүүлэхгүйн тулд k8s эсвэл Swarm ашигладаг боловч мэдээллийн сангийн хувьд үүнийг хийдэггүй. Гэхдээ хэрэв мэдээллийн сан гацвал манай бүхэл бүтэн кластер дэд бүтэц ямар ч утгагүй болно - мэдээллийн санд нэвтрэх алдаа гаргадаг хоосон вэб хуудсууд ямар хэрэгтэй вэ?
Ийм учраас ердийнх шиг зөвхөн вэб серверүүд төдийгүй мэдээллийн сангийн дэд бүтцийг кластер болгох шаардлагатай байдаг. Зөвхөн ийм байдлаар л бид нэг багт бүрэн ажилладаг, гэхдээ нэгэн зэрэг бие биенээсээ хараат бус бүтцийг бий болгож чадна. Түүгээр ч зогсохгүй манай арын хэсгийн тал нь ачааллын дор "нурсан" байсан ч үлдсэн хэсэг нь амьд үлдэх бөгөөд кластер доторх мэдээллийн санг синхрончлох систем, шинэ кластеруудыг хязгааргүй масштаблах, байрлуулах чадвар нь шаардлагатай хүчин чадалд хурдан хүрэхэд тусална. - Дата төвд өлгүүр байгаа бол.
Нэмж дурдахад, кластерт хуваарилагдсан мэдээллийн сангийн загвар нь энэ мэдээллийн санг шаардлагатай газарт нь хүргэх боломжийг олгодог; Хэрэв бид дэлхийн үйлчилгээний тухай ярьж байгаа бол Сан Францискогийн хаа нэгтээ вэб кластер эргэлдүүлж, Москвагийн бүс нутаг дахь мэдээллийн сан руу нэвтрэх үед пакет илгээх нь логикгүй юм.
Мөн мэдээллийн баазыг контейнержуулах нь системийн бүх элементүүдийг хийсвэрлэлийн ижил түвшинд барих боломжийг олгодог. Энэ нь эргээд администраторуудын идэвхтэй оролцоогүйгээр яг энэ системийг кодоос шууд хөгжүүлэгчид удирдах боломжтой болгодог. Хөгжүүлэгчид шинэ дэд төсөлд тусдаа DBMS хэрэгтэй гэж бодсон - хялбар! yaml файл бичээд, кластерт байршуулаад дууслаа.
Мэдээжийн хэрэг, дотоод ажиллагааг ихээхэн хялбаршуулсан. Надад хэлээч, багийн шинэ гишүүн ажлаар байлдааны мэдээллийн санд гараа оруулахад та хэдэн удаа нүдээ анисан бэ? Яг одоо танд байгаа цорын ганц нь аль нь вэ? Мэдээжийн хэрэг, бид бүгд энд насанд хүрсэн хүмүүс бөгөөд хаа нэгтээ шинэхэн нөөцтэй, бүр цаашлаад эмээгийн өргөст хэмх, хуучин цанатай тавиурын ард - өөр нэг нөөц, магадгүй хөргөгчинд ч байж магадгүй, учир нь танай оффис аль хэдийн шатаж байсан. Гэсэн хэдий ч байлдааны дэд бүтэц, мэдээжийн хэрэг байлдааны мэдээллийн санд нэвтрэх боломжтой багийн шинэ гишүүнийг танилцуулах нь эргэн тойрон дахь бүх хүмүүст валидолын хувин болдог. За, түүнийг хэн мэдэх вэ, шинэхэн, магадгүй тэр загалмайлсан юм болов уу? Аймшигтай, чи зөвшөөрнө.
Контейнержүүлэлт, үнэндээ таны төслийн мэдээллийн сангийн тархсан физик топологи нь ийм баталгаажуулах мөчөөс зайлсхийхэд тусалдаг. Шинэхэн хүнд итгэхгүй байна уу? БОЛЖ БАЙНА УУ! Түүнд ажиллахын тулд өөрийн кластерийг өгцгөөе, мэдээллийн санг бусад кластеруудаас салгая - зөвхөн гараар түлхэж, хоёр товчлуурыг синхроноор эргүүлэх замаар синхрончлох (нэг нь багийн ахлагч, нөгөө нь админ). Мөн бүгд баяртай байна.
Одоо өгөгдлийн сангийн кластерийг эсэргүүцэгчид болж өөрчлөгдөх цаг болжээ.
Муу тал
Мэдээллийн санг хадгалах, нэг төв сервер дээр үргэлжлүүлэн ажиллуулах нь яагаад үнэ цэнэтэй зүйл биш гэж маргаж байгаа бол бид "Өвөг эцэг нь мэдээллийн санг техник хангамж дээр ажиллуулдаг байсан, бид ч бас тэгэх болно!" гэх мэт үнэн алдартны үг хэллэг, мэдэгдлүүдэд хазайхгүй. Үүний оронд чингэлэг нь бодит ногдол ашиг өгөх нөхцөлийг бий болгохыг хичээцгээе.
Зөвшөөрч байна, чингэлэгт суурь шаардлагатай төслүүдийг хамгийн сайн тээрэмдэх машинчин биш нэг гарын хуруугаар тоолж болно. Ихэнх тохиолдолд k8s эсвэл Docker Swarm-ийг ашиглах нь шаардлагагүй байдаг - технологийн ерөнхий шуугиан, хүйсийн хүн дэх "бүхнийг чадагч" -ын хандлагаас шалтгаалан эдгээр хэрэгслийг ихэвчлэн ашигладаг. үүл ба чингэлэг. За, учир нь энэ нь одоо моод болж, хүн бүр үүнийг хийдэг.
Тохиолдлын дор хаяж тал хувь нь төсөл дээр Kubernetis эсвэл зүгээр л Docker ашиглах нь илүүц юм. Асуудал нь үйлчлүүлэгчийн дэд бүтцийг хадгалахаар хөлсөлсөн бүх баг эсвэл аутсорсингийн компаниуд үүнийг мэддэггүй явдал юм. Үйлчлүүлэгчээс тодорхой хэмжээний зоос төлдөг тул чингэлэг ногдуулах нь илүү муу юм.
Ерөнхийдөө докер/шоо мафи нь эдгээр дэд бүтцийн асуудлыг аутсорсинг хийдэг үйлчлүүлэгчдийг тэнэгээр бут цохиж байна гэсэн үзэл бодол байдаг. Эцсийн эцэст, кластеруудтай ажиллахын тулд бидэнд үүнийг хийх чадвартай, хэрэгжүүлсэн шийдлийн архитектурыг ерөнхийд нь ойлгодог инженерүүд хэрэгтэй. Бид өмнө нь Бүгд Найрамдах Улсын хэвлэлд тохиолдсон асуудлаа аль хэдийн тайлбарласан - тэнд бид үйлчлүүлэгчийн багийг Кубернетисийн бодит байдалд ажиллахад сургасан бөгөөд бүгд сэтгэл хангалуун байсан. Мөн энэ нь зохистой байсан. Ихэнхдээ k8s-ийн "хэрэгжүүлэгчид" үйлчлүүлэгчийн дэд бүтцийг барьцаалдаг - учир нь одоо тэнд бүх зүйл хэрхэн явагддагийг тэд л ойлгож байна; үйлчлүүлэгчийн талд мэргэжилтэн байдаггүй.
Ийм байдлаар бид зөвхөн вэб серверийн хэсгийг төдийгүй мэдээллийн сангийн засвар үйлчилгээг аутсорсинг хийдэг гэж төсөөлөөд үз дээ. БД бол зүрх, зүрх алдах нь ямар ч амьд организмд үхэлд хүргэдэг гэж бид хэлсэн. Товчхондоо, хэтийн төлөв нь хамгийн сайн биш юм. Тиймээс, Kubernetis-ийг сурталчлахын оронд олон төсөл AWS-ийн ердийн тарифын талаар санаа зовох хэрэггүй бөгөөд энэ нь тэдний сайт / төслийн ачаалалтай холбоотой бүх асуудлыг шийдэх болно. Гэвч AWS моод байхаа больсон бөгөөд шоу нэвтрүүлэг нь мөнгөнөөс илүү үнэ цэнэтэй - харамсалтай нь мэдээллийн технологийн орчинд ч гэсэн.
БОЛЖ БАЙНА УУ. Төсөлд үнэхээр кластер хийх шаардлагатай байж магадгүй, гэхдээ харьяалалгүй програмуудын хувьд бүх зүйл тодорхой бол бид кластерлагдсан мэдээллийн сангийн зохистой сүлжээний холболтыг хэрхэн зохион байгуулах вэ?
Хэрэв бид k8s руу шилжих шилжилтийн асуудал болох ямар ч саадгүй инженерийн шийдлийн тухай ярьж байгаа бол бидний гол толгойн өвчин бол бөөгнөрсөн мэдээллийн сан дахь өгөгдлийг хуулбарлах явдал юм. Зарим DBMS нь эхэндээ өгөгдлийн хуваарилалтад үнэнч байдаг. Бусад олон хүмүүс тийм ч таатай хүлээж авдаггүй. Манай төслийн DBMS-ийг сонгох гол аргумент бол хамгийн бага нөөц, инженерийн зардлаар хуулбарлах чадвар биш юм. Ялангуяа төслийг анх бичил үйлчилгээ хэлбэрээр төлөвлөөгүй, харин зүгээр л энэ чиглэлд хөгжсөн бол.
Сүлжээний хөтчүүдийн хурдны талаар ярих шаардлагагүй гэж бид бодож байна - тэдгээр нь удаан байдаг. Тэдгээр. Хэрэв ямар нэг зүйл тохиолдвол процессорын хүчин чадал эсвэл үнэгүй RAM гэх мэт илүү их байгаа газар DBMS-ийн жишээг дахин эхлүүлэх бодит боломж бидэнд байхгүй хэвээр байна. Бид виртуалжуулсан дискний дэд системийн гүйцэтгэлд маш хурдан орох болно. Үүний дагуу DBMS нь ойролцоо байрладаг өөрийн хувийн машинтай байх ёстой. Эсвэл тооцоолсон нөөцийн хувьд хангалттай хурдан өгөгдөл синхрончлолыг ямар нэгэн байдлаар тусад нь хөргөх шаардлагатай болно.
Виртуал файлын системийн сэдвийг үргэлжлүүлэх нь: Харамсалтай нь Docker Volumes нь асуудалгүй биш юм. Ерөнхийдөө урт хугацааны найдвартай өгөгдөл хадгалах гэх мэт асуудалд би техникийн хувьд хамгийн энгийн схемүүдийг ашиглахыг хүсч байна. Контейнерийн FS-ээс эх хостын FS-д шинэ хийсвэр давхарга нэмэх нь өөрөө эрсдэлтэй. Гэхдээ контейнержуулалтыг дэмжих системийн ажиллагаа нь эдгээр давхаргын хооронд өгөгдөл дамжуулахад бэрхшээлтэй тулгарвал энэ нь үнэхээр сүйрэл юм. Одоогийн байдлаар дэвшилтэт хүн төрөлхтний мэддэг ихэнх бэрхшээлүүд арилсан бололтой. Гэхдээ та ойлгож байна, механизм нь илүү төвөгтэй байх тусам эвдрэх нь хялбар байдаг.
Эдгээр бүх "адал явдлууд" -ын үүднээс мэдээллийн санг нэг газар хадгалах нь илүү ашигтай бөгөөд хялбар бөгөөд хэрэв та програмыг хадгалах шаардлагатай байсан ч үүнийг өөрөө ажиллуулж, түгээлтийн гарцаар дамжуулан нэгэн зэрэг харилцаа холбоог хүлээн авах боломжтой. өгөгдлийн сан бөгөөд үүнийг зөвхөн нэг удаа, нэг дор уншиж, бичих болно. Энэ арга нь алдаа, синхрончлолын магадлалыг хамгийн бага хэмжээнд хүртэл бууруулдаг.
Бид юу руу хөтөлж байна вэ? Түүнээс гадна мэдээллийн санг хадгалах нь бодит хэрэгцээ байгаа тохиолдолд тохиромжтой. Та бүрэн програмын мэдээллийн санг дүүргэж, хэдэн арван микро үйлчилгээтэй юм шиг эргүүлэх боломжгүй - энэ нь тийм ч сайн ажиллахгүй. Мөн үүнийг тодорхой ойлгох ёстой.
Гаралтын оронд
Хэрэв та "өгөгдлийн санг виртуалчлах эсэх" гэсэн тодорхой дүгнэлтийг хүлээж байгаа бол бид таныг урмыг хугална: энэ нь энд байхгүй болно. Учир нь аливаа дэд бүтцийн шийдлийг бий болгохдоо загвар, дэвшлийг биш, хамгийн түрүүнд эрүүл саруул ухаанаар удирдуулах ёстой.
Kubernetis-тэй хамт ирдэг зарчим, хэрэгслүүд нь төгс тохирох төслүүд байдаг бөгөөд ийм төслүүдэд ядаж арын хэсэгт амар амгалан байдаг. Контейнержуулалт шаардлагагүй, ердийн серверийн дэд бүтэц шаардлагатай төслүүд байдаг, учир нь тэд үндсэндээ микро үйлчилгээний кластерийн загварт шилжих боломжгүй, учир нь тэд унах болно.
Эх сурвалж: www.habr.com