Tupperware-ийн тусламжтайгаар кластеруудыг ямар ч хэмжээгээр үр дүнтэй, найдвартай удирдах
Өнөөдөр Бид бараг бүх үйлчилгээгээ ажиллуулж байгаа сая сая серверүүд дээр контейнеруудыг зохион байгуулдаг кластерын удирдлагын систем болох Tupperware-ийг нэвтрүүлсэн. Бид анх 2011 онд Tupperware-ийг байршуулсан бөгөөд түүнээс хойш манай дэд бүтэц хөгжсөн. бүхэлд нь хүртэл . Энэ бүх хугацаанд Tupperware зогсолтгүй, бидэнтэй хамт хөгжсөн. Бид танд Tupperware хэрхэн нэгдүгээр зэрэглэлийн кластерын удирдлага, тухайлбал төлөв байдлын үйлчилгээнд тохиромжтой дэмжлэг үзүүлэх, бүх дата төвүүдэд зориулсан нэг хяналтын самбар, бодит цаг хугацаанд үйлчилгээнүүдийн хооронд хүчин чадлыг хуваарилах чадварыг харуулах болно. Дэд бүтэц хөгжихийн хэрээр бид сурсан сургамжаа хуваалцах болно.
Tupperware өөр өөр үүрэг гүйцэтгэдэг. Аппликейшн хөгжүүлэгчид үүнийг програм хангамжийг хүргэх, удирдахад ашигладаг. Энэ нь програмын код болон хамаарлыг зураг болгон багцалж, серверт контейнер хэлбэрээр хүргэдэг. Контейнерууд нь нэг сервер дээрх программуудын хооронд тусгаарлалтыг хангадаг бөгөөд ингэснээр хөгжүүлэгчид програмын логиктой харьцаж, сервер хайх, шинэчлэлтийг удирдах талаар санаа зовох шаардлагагүй болно. Tupperware нь мөн серверийн гүйцэтгэлийг хянадаг бөгөөд хэрэв алдаа илэрвэл асуудалтай серверээс контейнеруудыг шилжүүлдэг.
Чадавхи төлөвлөлтийн инженерүүд Tupperware-ийг төсөв болон хязгаарлалт дээр үндэслэн багуудад серверийн хүчин чадлыг хуваарилахад ашигладаг. Тэд мөн серверийн ашиглалтыг сайжруулахад ашигладаг. Дата төвийн операторууд өгөгдлийн төвүүдэд чингэлэгүүдийг зөв хуваарилахын тулд Tupperware-д ханддаг бөгөөд засвар үйлчилгээний явцад савыг зогсоож эсвэл зөөдөг. Үүний ачаар сервер, сүлжээ, тоног төхөөрөмжийг засварлах нь хүний оролцоо бага шаарддаг.
Tupperware архитектур
Tupperware PRN архитектур нь манай дата төвүүдийн нэг хэсэг юм. Тус бүс нь ойролцоо байрладаг хэд хэдэн дата төвийн барилгаас (PRN1 ба PRN2) бүрддэг. Бид нэг бүсийн бүх серверийг удирдах нэг хяналтын самбар хийхээр төлөвлөж байна.
Хэрэглээний хөгжүүлэгчид Tupperware-ийн ажлын байр хэлбэрээр үйлчилгээ үзүүлдэг. Ажил нь олон контейнерээс бүрдэх ба тэдгээр нь ихэвчлэн ижил програмын кодыг ажиллуулдаг.
Tupperware нь савыг бэлтгэх, тэдгээрийн амьдралын мөчлөгийг удирдах үүрэгтэй. Энэ нь хэд хэдэн бүрэлдэхүүн хэсгээс бүрдэнэ:
- Tupperware-ийн урд тал нь хэрэглэгчийн интерфэйс, CLI болон бусад автоматжуулалтын хэрэглүүрүүдэд зориулсан API-уудаар хангадаг бөгөөд ингэснээр та Tupperware-тэй харилцах боломжтой. Тэд Tupperware-ийн ажлын эздээс бүх дотоод бүтцийг нуудаг.
- Tupperware Scheduler нь контейнер болон ажлын амьдралын мөчлөгийг удирдах үүрэгтэй хяналтын самбар юм. Энэ нь бүс нутгийн болон дэлхийн түвшинд тавигдсан бөгөөд бүс нутгийн хуваарьлагч нь нэг бүс дэх серверүүдийг удирдаж, дэлхийн хуваарьлагч нь өөр өөр бүс нутгийн серверүүдийг удирддаг. Хуваарьлагч нь хэлтэрхийд хуваагддаг бөгөөд хэлтэрхий бүр нь ажлын багцыг удирддаг.
- Tupperware's Scheduler Proxy нь дотоод хэлтэрхийг нууж, Tupperware хэрэглэгчдэд тохиромжтой нэг шилээр хангадаг.
- Tupperware хуваарилагч нь серверүүдэд контейнер хуваарилдаг. Хуваарьлагч нь контейнеруудыг зогсоох, эхлүүлэх, шинэчлэх, шилжүүлэн суулгах ажлыг гүйцэтгэдэг. Одоогоор нэг хуваарилагч хэсэг болгон хуваахгүйгээр бүс нутгийг бүхэлд нь удирдах боломжтой. (Нэр томъёоны ялгааг анхаарна уу. Жишээ нь, Tupperware-ийн хуваарь гаргагч нь дах удирдлагын самбартай тохирч байна , мөн Tupperware хуваарилагчийг Kubernetes-д төлөвлөгч гэж нэрлэдэг.)
- Нөөцийн брокер нь сервер болон үйлчилгээний үйл явдлын үнэний эх сурвалжийг хадгалдаг. Бид өгөгдлийн төв бүрт нэг нөөц брокер ажиллуулдаг бөгөөд энэ нь тухайн дата төв дэх серверүүдийн талаарх бүх мэдээллийг хадгалдаг. Нөөцийн брокер ба чадавхийн удирдлагын систем буюу нөөцийн нөөцийн систем нь аль хуваарилагч хүргэлт нь аль серверийг хянахыг динамикаар шийддэг. Эрүүл мэндийн үзлэгийн үйлчилгээ нь серверүүдийг хянаж, тэдний эрүүл мэндийн талаарх мэдээллийг нөөцийн брокерт хадгалдаг. Хэрэв серверт асуудал байгаа эсвэл засвар үйлчилгээ шаардлагатай бол нөөцийн брокер хуваарилагч болон төлөвлөгчдөө контейнеруудыг зогсоох эсвэл өөр сервер рүү шилжүүлэхийг хэлдэг.
- Tupperware Agent нь сервер бүр дээр ажиллаж байгаа демон бөгөөд савыг бэлтгэх, зайлуулах ажлыг гүйцэтгэдэг. Аппликейшн нь сав дотор ажилладаг бөгөөд энэ нь тэдэнд илүү тусгаарлалт, дахин давтагдах боломжийг олгодог. Асаалттай Зураг, btrfs, cgroupv2 болон systemd ашиглан тус тусдаа Tupperware савыг хэрхэн бүтээдэг талаар бид аль хэдийн тайлбарласан.
Tupperware-ийн онцлог шинж чанарууд
Tupperware нь Kubernetes болон бусад кластерийн удирдлагын системүүдтэй олон талаараа төстэй юм , гэхдээ бас ялгаа байдаг:
- Төрийн үйлчилгээнд суурилуулсан дэмжлэг.
- Зорилго, кластеруудыг татан буулгах, засвар үйлчилгээ зэрэгт үндэслэн чингэлэг хүргэх ажлыг автоматжуулах зорилгоор өөр өөр өгөгдлийн төвийн серверүүдэд зориулсан нэг хяналтын самбар.
- Томруулахын тулд хяналтын самбарын хуваалтыг арилгана.
- Мэдрэмжтэй тооцоолол нь бодит цаг хугацаанд үйлчилгээнүүдийн хооронд эрчим хүчийг хуваарилах боломжийг олгодог.
Бид эдгээр гайхалтай функцуудыг дэлхийн асар том хуваалцсан серверийн флот даяар харьяалалгүй, статустай олон төрлийн програмуудыг дэмжих зорилгоор боловсруулсан.
Төрийн үйлчилгээнд суурилуулсан дэмжлэг.
Tupperware нь Facebook, Instagram, Messenger болон WhatsApp-ын бүтээгдэхүүний байнгын мэдээллийг хадгалдаг төрөл бүрийн чухал үйлчилгээ үзүүлдэг. Эдгээр нь түлхүүр-утга хосын томоохон дэлгүүрүүд байж болно (жишээ нь: ) болон мэдээллийн санг хянах (жишээлбэл, и ). Сүлжээний тасалдал, цахилгааны тасалдал зэрэг томоохон хэмжээний тасалдал, савны хангамжийг тэсвэрлэх чадвартай байх ёстой тул систем нь төлөв байдлын үйлчилгээг хадгалах нь тийм ч хялбар биш юм. Гэмтлийн домайнуудад контейнер түгээх гэх мэт уламжлалт аргууд нь харьяалалгүй үйлчилгээнд сайн ажилладаг ч төрийн үйлчилгээнд нэмэлт дэмжлэг хэрэгтэй.
Жишээлбэл, хэрэв серверийн доголдол нь нэг мэдээллийн сангийн хуулбарыг ашиглах боломжгүй бол та 50 цөмөөс 10 серверийн цөмийг шинэчлэх автомат засвар үйлчилгээг идэвхжүүлэх үү? Нөхцөл байдлаас шалтгаална. Хэрэв эдгээр 50 серверийн аль нэг нь ижил мэдээллийн сангийн өөр хуулбартай бол 2 хуулбарыг нэг дор алдахгүй байх нь дээр. Системийн засвар үйлчилгээ, гүйцэтгэлийн талаар динамикаар шийдвэр гаргахын тулд дотоод өгөгдлийн хуулбар болон төлөвтэй үйлчилгээ бүрийн байршлын логикийн талаархи мэдээлэл хэрэгтэй.
TaskControl интерфэйс нь мэдээллийн хүртээмжид нөлөөлөх шийдвэрт нөлөөлөх боломжийг төлөвтэй үйлчилгээнд олгодог. Энэхүү интерфэйсийг ашиглан хуваарь гаргагч нь контейнерийн үйл ажиллагааны (дахин эхлүүлэх, шинэчлэх, шилжүүлэх, засвар үйлчилгээ хийх) талаар гадны програмуудад мэдэгддэг. Төлөвлөсөн үйлчилгээ нь Tupperware-д үйл ажиллагаа бүрийг гүйцэтгэхэд аюулгүй болохыг хэлдэг хянагчийг хэрэгжүүлдэг бөгөөд эдгээр үйлдлийг түр хугацаагаар сольж эсвэл хойшлуулж болно. Дээрх жишээнд өгөгдлийн сангийн хянагч Tupperware-д 49 серверээс 50-ийг нь шинэчлэхийг хэлж болох ч тодорхой серверийг (X) одоохондоо орхи. Үүний үр дүнд, цөмийн шинэчлэлтийн хугацаа өнгөрч, мэдээллийн сан асуудалтай хуулбарыг сэргээх боломжгүй хэвээр байвал Tupperware X серверийг шинэчлэх болно.
Tupperware-ийн статустай олон үйлчилгээ TaskControl-ийг шууд бус, харин Facebook дээр төлөвтэй үйлчилгээ үүсгэх нийтлэг платформ болох ShardManager-ээр дамжуулан ашигладаг. Tupperware-ийн тусламжтайгаар хөгжүүлэгчид өгөгдлийн төвүүдэд чингэлэгүүдийг хэрхэн хуваарилах талаар өөрсдийн зорилгыг тодорхойлж чадна. ShardManager-ийн тусламжтайгаар хөгжүүлэгчид өгөгдлийн хэсгүүдийг чингэлэгт хэрхэн түгээх талаар өөрсдийн зорилгыг тодорхойлдог. ShardManager нь өөрийн программуудын өгөгдөл байршуулах, хуулбарлах талаар мэддэг бөгөөд TaskControl интерфейсээр дамжуулан Tupperware-тай холбогдож, шууд хэрэглээний оролцоогүйгээр контейнерийн үйл ажиллагааг төлөвлөдөг. Энэхүү интеграци нь төрийн үйлчилгээний удирдлагыг ихээхэн хөнгөвчлөх боловч TaskControl илүү ихийг хийх боломжтой. Жишээлбэл, манай өргөн цар хүрээтэй вэб давхарга нь харьяалалгүй бөгөөд TaskControl-ийг ашиглан контейнеруудын шинэчлэлтийн хурдыг динамикаар тохируулдаг. Эцэст нь хүртээмжийг алдагдуулахгүйгээр өдөрт.
Дата төв дэх серверүүдийг удирдах
Tupperware 2011 онд анх худалдаанд гарахад серверийн кластер бүрийг тусдаа хуваарь гаргагч удирддаг байсан. Тухайн үед Facebook-ийн кластер нь нэг сүлжээний унтраалгатай холбогдсон сервер тавиуруудын бүлэг байсан бөгөөд мэдээллийн төвд хэд хэдэн кластер байрладаг байв. Төлөвлөгч нь зөвхөн нэг кластерт серверүүдийг удирдах боломжтой бөгөөд энэ нь ажил олон кластерт тархах боломжгүй гэсэн үг юм. Манай дэд бүтэц хөгжиж, бид кластеруудыг улам бүр хассан. Tupperware нь ажлаа цуцлагдсан кластераас бусад кластерууд руу өөрчлөлтгүйгээр шилжүүлж чадахгүй байсан тул програм хөгжүүлэгчид болон дата төвийн операторуудын хооронд маш их хүчин чармайлт, нарийн зохицуулалт шаардагддаг. Энэ үйл явц нь серверүүдийг татан буулгах журмын улмаас хэдэн сарын турш ажиллахгүй байх үед нөөцийг дэмий үрсэн.
Бид кластерийг татан буулгах асуудлыг шийдвэрлэх, бусад төрлийн засвар үйлчилгээний ажлыг зохицуулах зорилгоор нөөцийн брокер үүсгэсэн. Нөөцийн брокер нь сервертэй холбоотой бүх физик мэдээллийг хянаж, сервер бүрийг аль хуваарьлагч удирдаж байгааг динамикаар шийддэг. Серверүүдийг хуваарь гаргагчид динамикаар холбох нь төлөвлөгч нь өөр өөр мэдээллийн төв дэх серверүүдийг удирдах боломжийг олгодог. Tupperware-ийн ажил зөвхөн нэг кластераар хязгаарлагдахаа больсон тул Tupperware-ийн хэрэглэгчид алдаатай домайнуудад контейнер хэрхэн хуваарилагдахыг зааж өгч болно. Жишээлбэл, хөгжүүлэгч өөрийн зорилгыг ("PRN бүс дэх 2 алдаатай домэйн дээр миний ажлыг ажиллуул" гэх мэт) тодорхой боломжит бүсийг заахгүйгээр зарлаж болно. Кластер эсвэл үйлчилгээг татан буулгасан ч гэсэн Tupperware өөрөө энэ зорилгыг хэрэгжүүлэхэд тохиромжтой серверүүдийг олох болно.
Бүхэл бүтэн дэлхийн системийг дэмжих боломжтой
Түүхийн хувьд манай дэд бүтэц нь бие даасан багуудад зориулагдсан хэдэн зуун серверийн санд хуваагдсан байдаг. Хэсэгчилсэн байдал, стандарт байхгүйгээс бид үйл ажиллагааны зардал өндөртэй байсан бөгөөд сул зогсолттой серверүүдийг дахин ашиглахад илүү төвөгтэй байсан. Өнгөрсөн жилийн чуулган дээр бид танилцуулсан , энэ нь манай дэд бүтцийг нэг том серверийн парк болгон нэгтгэх ёстой. Гэхдээ ганц серверийн парк нь өөрийн гэсэн бэрхшээлтэй байдаг. Энэ нь тодорхой шаардлагыг хангасан байх ёстой:
- Өргөтгөх чадвар. Бүс болгонд дата төвүүдийг нэмснээр манай дэд бүтэц өссөн. Серверүүд багасч, эрчим хүчний хэмнэлттэй болсон тул бүс бүрт илүү олон байдаг. Үүний үр дүнд нэг бүс нутаг дахь ганц хуваарьлагч нь бүс тус бүрийн хэдэн зуун мянган сервер дээр ажиллах боломжтой контейнеруудын тоог зохицуулж чадахгүй.
- Найдвартай байдал. Төлөвлөгчийг тийм их хэмжээгээр томруулж чадсан ч гэсэн том том хэмжээтэй байх нь алдаа гарах эрсдэл өндөр, савны бүхэл бүтэн бүсийг удирдах боломжгүй болно гэсэн үг.
- Алдааг тэсвэрлэх чадвар. Асар том хэмжээний дэд бүтцийн доголдол гарсан тохиолдолд (жишээ нь, төлөвлөгчийг ажиллуулж байгаа серверүүд сүлжээний доголдол эсвэл цахилгаан тасалдсаны улмаас доголдсон) сөрөг үр дагавар нь тухайн бүс нутгийн серверүүдийн зөвхөн нэг хэсэгт нөлөөлөх ёстой.
- Ашиглахад хялбар. Та нэг бүс нутагт хэд хэдэн бие даасан төлөвлөгч ажиллуулах хэрэгтэй юм шиг санагдаж магадгүй юм. Гэхдээ ая тухтай байдлын үүднээс авч үзвэл, тухайн бүс нутгийн дундын усан санд нэвтрэх нэг цэг нь хүчин чадал, ажлын байрыг удирдахад хялбар болгодог.
Томоохон дундын усан санг хадгалах асуудлыг шийдэхийн тулд бид хуваарийг хэлтэрхий болгон хуваасан. Төлөвлөгчийн хэлтэрхий бүр бүс нутаг дахь өөрийн ажлын багцыг удирддаг бөгөөд энэ нь төлөвлөгчтэй холбоотой эрсдлийг бууруулдаг. Хуваалцсан сан нэмэгдэхийн хэрээр бид илүү олон хуваарийн хэсгүүдийг нэмж болно. Tupperware хэрэглэгчдийн хувьд хэлтэрхий болон хуваарьлагч прокси нь нэг хяналтын самбар шиг харагддаг. Тэд даалгавруудыг зохион байгуулдаг олон тооны хэлтэрхийнүүдтэй ажиллах шаардлагагүй. Сүлжээний топологийн дагуу серверүүдийн хуваалцсан санг статик байдлаар хуваахгүйгээр хяналтын самбарыг хуваах үед бидний өмнө нь ашиглаж байсан кластер төлөвлөгчөөс хуваарийн хэсгүүд үндсэндээ ялгаатай.
Уян тооцооллын тусламжтайгаар ашиглалтын үр ашгийг дээшлүүлээрэй
Манай дэд бүтэц том байх тусам дэд бүтцийн зардлыг оновчтой болгох, ачааллыг бууруулахын тулд серверээ үр ашигтай ашиглах нь илүү чухал юм. Серверийн ашиглалтын үр ашгийг нэмэгдүүлэх хоёр арга бий:
- Мэдрэмжтэй тооцоолол - чимээгүй цагт онлайн үйлчилгээг багасгаж, машин сурах, MapReduce ажлууд зэрэг офлайн ажлын ачаалалд зориулж чөлөөлөгдсөн серверүүдийг ашиглана уу.
- Хэт ачаалал - Онлайн үйлчилгээ болон багц ажлын ачааллыг ижил серверүүд дээр байрлуулснаар багц ажлын ачаалал бага ач холбогдолтой.
Манай дата төвүүдийн гацаа нь . Тиймээс бид хамтдаа илүү их боловсруулах хүч өгдөг жижиг, эрчим хүчний хэмнэлттэй серверүүдийг илүүд үздэг. Харамсалтай нь CPU болон санах ой багатай жижиг серверүүд дээр хэт ачаалал өгөх нь үр дүн багатай байдаг. Мэдээжийн хэрэг, бид процессорын нөөц, санах ой бага зарцуулдаг эрчим хүчний хэмнэлттэй жижиг сервер дээр жижиг үйлчилгээний хэд хэдэн контейнер байрлуулж болох ч энэ тохиолдолд том үйлчилгээ бага гүйцэтгэлтэй байх болно. Тиймээс бид томоохон үйлчилгээгээ хөгжүүлэгчдэд серверүүдийг бүхэлд нь ашиглахын тулд тэдгээрийг оновчтой болгохыг зөвлөж байна.
Үндсэндээ бид уян хатан тооцоолол ашиглан ашиглалтын үр ашгийг сайжруулдаг. Мэдээний хангамж, Мессежийн функц, урд талын вэб давхарга зэрэг манай гол үйлчилгээнүүдийн ихэнх нь өдрийн цагаас хамаарч өөр өөр байдаг. Бид чимээгүй цагт онлайн үйлчилгээг зориудаар багасгаж, машин сурах, MapReduce ажлууд зэрэг офлайн ажлын ачаалалд чөлөөлөгдсөн серверүүдийг ашигладаг.
Томоохон үйлчилгээнүүд нь уян хатан чадлын гол хандивлагч, гол хэрэглэгчид хоёулаа байдаг бөгөөд серверүүдийг бүхэлд нь ашиглахад оновчтой байдаг тул серверүүдийг бүхэлд нь уян хатан чадлын нэгж болгон хангах нь дээр гэдгийг бид туршлагаасаа мэднэ. Серверийг чимээгүй цагаар онлайн үйлчилгээнээс гаргах үед нөөцийн брокер нь серверийг офлайн ачааллыг ажиллуулахын тулд хуваарь гаргагчид түрээслэдэг. Хэрэв онлайн үйлчилгээ хамгийн их ачаалалтай байвал нөөцийн зуучлагч зээлсэн серверээ хурдан дуудаж, хуваарь гаргагчийн хамт түүнийг онлайн үйлчилгээ рүү буцаана.
Сургамж, ирээдүйн төлөвлөгөө
Сүүлийн 8 жилийн хугацаанд бид Facebook-ийн хурдацтай өсөлтийг хангахын тулд Tupperware-г хөгжүүлсээр ирсэн. Бид сурсан зүйлээ хуваалцаж байгаа бөгөөд энэ нь бусдад хурдацтай хөгжиж буй дэд бүтцийг удирдахад тусална гэж найдаж байна:
- Хяналтын самбар болон түүний удирддаг серверүүдийн хооронд уян хатан холболтыг тохируулна уу. Энэхүү уян хатан байдал нь хяналтын самбарт өөр өөр өгөгдлийн төвүүдийн серверүүдийг удирдах боломжийг олгож, кластеруудыг татан буулгах, засвар үйлчилгээг автоматжуулахад тусалдаг ба уян тооцоолол ашиглан динамик хүчин чадлын хуваарилалтыг идэвхжүүлдэг.
- Бүс нутагт нэг хяналтын самбартай болсноор даалгавартай ажиллахад илүү хялбар болж, том хуваалцсан серверийн флотыг удирдахад хялбар болно. Удирдлагын самбар нь дотоод бүтэц нь масштабын шалтгаан эсвэл эвдрэлийг тэсвэрлэх чадвараас шалтгаалан тусгаарлагдсан байсан ч нэг нэвтрэх цэгийг хадгалдаг гэдгийг анхаарна уу.
- Залгаасны загварыг ашиглан хяналтын самбар нь удахгүй болох контейнерийн үйл ажиллагааны талаар гадны програмуудад мэдэгдэх боломжтой. Түүнчлэн, төлөвтэй үйлчилгээнүүд нь залгаасын интерфейсийг ашиглан контейнерийн менежментийг өөрчлөх боломжтой. Энэхүү залгаасын загварын тусламжтайгаар хяналтын самбар нь олон төрлийн төлөвтэй үйлчилгээнд үр дүнтэй үйлчлэхийн зэрэгцээ энгийн байдлыг хангадаг.
- Багц ажил, машин сургалт болон бусад яаралтай бус үйлчилгээнд зориулж хандивлагчийн үйлчилгээнээс серверүүдийг бүхэлд нь хасдаг уян тооцоолол нь жижиг, эрчим хүчний хэмнэлттэй серверүүдийн үр ашгийг дээшлүүлэх оновчтой арга гэдэгт бид итгэдэг.
Бид дөнгөж хэрэгжүүлж эхэлж байна . Одоогоор манай серверүүдийн 20 орчим хувь нь дундын санд байна. 100% хүрэхийн тулд дундын хадгалах санг хадгалах, засвар үйлчилгээг автоматжуулах, түрээслэгч хоорондын шаардлагыг удирдах, серверийн ашиглалтыг сайжруулах, машин сургалтын ажлын ачааллыг дэмжих зэрэг олон асуудлыг шийдвэрлэх шаардлагатай. Бид эдгээр сорилтуудыг даван туулж, амжилтаа хуваалцахыг тэсэн ядан хүлээж байна.
Эх сурвалж: www.habr.com