Openstack дахь ачааллыг тэнцвэржүүлэх (2-р хэсэг)

В Сүүлийн нийтлэл Бид Watcher-г ашиглах оролдлогуудын талаар ярилцаж, туршилтын тайланг өгсөн. Бид томоохон аж ахуйн нэгж эсвэл операторын үүлний тэнцвэржүүлэх болон бусад чухал функцүүдийн хувьд ийм туршилтыг үе үе хийдэг.

Шийдэж буй асуудлын өндөр төвөгтэй байдал нь манай төслийг тайлбарлах хэд хэдэн нийтлэлийг шаардаж магадгүй юм. Өнөөдөр бид үүлэн дэх виртуал машинуудыг тэнцвэржүүлэхэд зориулагдсан цувралын хоёр дахь нийтлэлийг нийтэлж байна.

Зарим нэр томъёо

VmWare компани нь өөрсдийн хөгжүүлж, санал болгож буй виртуалчлалын орчны ачааллыг тэнцвэржүүлэхийн тулд DRS (Distributed Resource Scheduler) хэрэгслийг нэвтрүүлсэн.

Түүний бичсэнээр searchvmware.techtarget.com/definition/VMware-DRS
“VMware DRS (Distributed Resource Scheduler) нь виртуал орчинд байгаа нөөцтэй тооцоолох ачааллыг тэнцвэржүүлдэг хэрэгсэл юм. Энэхүү хэрэгсэл нь VMware Infrastructure хэмээх виртуалчлалын багцын нэг хэсэг юм.

VMware DRS-ийн тусламжтайгаар хэрэглэгчид виртуал машин (VM) хооронд физик нөөцийг хуваарилах дүрмийг тодорхойлдог. Хэрэгслийг гараар эсвэл автомат удирдлагаар тохируулах боломжтой. VMware нөөцийн сангуудыг амархан нэмж, устгаж, дахин зохион байгуулж болно. Хэрэв хүсвэл нөөцийн сангуудыг өөр өөр бизнесийн нэгжүүдийн хооронд тусгаарлаж болно. Хэрэв нэг буюу хэд хэдэн виртуал машин дээрх ажлын ачаалал эрс өөрчлөгдвөл VMware DRS нь виртуал машинуудыг физик серверүүдэд дахин хуваарилдаг. Хэрэв нийт ажлын ачаалал буурвал зарим физик серверүүдийг түр хугацаагаар офлайн болгож, ачааллыг нэгтгэж болно."

Яагаад тэнцвэржүүлэх шаардлагатай байна вэ?


Бидний бодлоор DRS нь заавал байх ёстой үүлний онцлог боловч энэ нь DRS-ийг үргэлж, хаа сайгүй ашиглах ёстой гэсэн үг биш юм. Үүлний зорилго, хэрэгцээ шаардлагаас хамааран DRS болон тэнцвэржүүлэх аргуудад өөр өөр шаардлага тавьж болно. Тэнцвэржүүлэх шаардлагагүй нөхцөл байдал байж болно. Эсвэл бүр хортой.

DRS хаана, ямар үйлчлүүлэгчид хэрэгтэйг илүү сайн ойлгохын тулд тэдний зорилго, зорилтуудыг авч үзье. Үүлийг нийтийн болон хувийн гэж хувааж болно. Эдгээр үүл болон хэрэглэгчийн зорилгын хоорондох үндсэн ялгааг энд харуулав.

Хувийн үүл / Том аж ахуйн нэгжийн үйлчлүүлэгчид
Нийтийн үүл / Дунд болон жижиг бизнес эрхлэгчид, хүмүүс

Операторын гол шалгуур, зорилго
Найдвартай үйлчилгээ, бүтээгдэхүүнээр хангах
Өрсөлдөөнт зах зээл дэх тэмцэлд үйлчилгээний өртгийг бууруулах

Үйлчилгээний шаардлага
Бүх түвшний болон системийн бүх элементүүдийн найдвартай байдал

Баталгаатай гүйцэтгэл

Виртуал машинуудыг хэд хэдэн ангилалд эрэмбэлэх 

Мэдээлэл, физик мэдээллийн аюулгүй байдал

SLA болон XNUMX/XNUMX дэмжлэг
Үйлчилгээг хүлээн авах хамгийн хялбар байдал

Харьцангуй энгийн үйлчилгээ

Мэдээллийн хариуцлагыг үйлчлүүлэгч хариуцна

VM-ийг эрэмбэлэх шаардлагагүй

Стандарт үйлчилгээний түвшинд мэдээллийн аюулгүй байдал, үйлчлүүлэгчийн хариуцлага

Алдаа гарсан байж магадгүй

SLA байхгүй, чанарын баталгаагүй

Имэйлийн дэмжлэг

Нөөцлөх шаардлагагүй

Үйлчлүүлэгчийн онцлог
Маш өргөн хүрээний хэрэглээ.

Компанид өвлөн авсан хуучин програмууд.

Үйлчлүүлэгч бүрийн нарийн төвөгтэй архитектур.

Холболтын дүрэм.

Програм хангамж нь 7x24 горимд зогсолтгүй ажилладаг. 

Шууд нөөцлөх хэрэгслүүд.

Хэрэглэгчийн мөчлөгийн ачааллыг урьдчилан таамаглах боломжтой.
Ердийн програмууд - сүлжээ тэнцвэржүүлэх, Apache, WEB, VPN, SQL

Аппликешн хэсэг хугацаанд зогсч магадгүй

Клоуд дахь VM-ийг дур мэдэн хуваарилахыг зөвшөөрдөг

Үйлчлүүлэгчийн нөөц

Олон тооны үйлчлүүлэгчидтэй урьдчилан тооцоолж болох статистикийн дундаж ачаалал.

Архитектурт үзүүлэх нөлөө
Газарзүйн бөөгнөрөл

Төвлөрсөн эсвэл хуваарилагдсан хадгалах газар

Нөөцлөгдсөн IBS
Тооцооллын зангилаа дээрх локал өгөгдөл хадгалах

Зорилгуудыг тэнцвэржүүлэх
Ачааллыг жигд хуваарилах

Аппликешны хамгийн их хариу үйлдэл 

Тэнцвэржүүлэх хамгийн бага саатал

Зөвхөн тодорхой шаардлагатай үед тэнцвэржүүлнэ

Урьдчилан сэргийлэх засвар үйлчилгээ хийх зарим тоног төхөөрөмжийг авчрах
Үйлчилгээний зардал болон операторын зардлыг бууруулах 

Ачаалал багатай тохиолдолд зарим нөөцийг идэвхгүй болгох

Эрчим хүч хэмнэх

Боловсон хүчний зардлыг бууруулах

Бид өөрсдөө дараахь дүгнэлтийг гаргаж байна.

Хувийн үүлний хувьдТомоохон аж ахуйн нэгжийн үйлчлүүлэгчдэд олгодог DRS-ийг дараахь хязгаарлалтын дагуу ашиглаж болно.

  • мэдээллийн аюулгүй байдал, тэнцвэржүүлэхдээ ойр дотно байдлын дүрмийг харгалзан үзэх;
  • ослын үед нөөцөд хангалттай нөөц байгаа эсэх;
  • виртуал машины өгөгдөл нь төвлөрсөн эсвэл хуваарилагдсан хадгалах систем дээр байрладаг;
  • цаг хугацааны явцад гайхалтай удирдлага, нөөцлөх, тэнцвэржүүлэх журам;
  • зөвхөн үйлчлүүлэгчийн хостуудын нийлбэр дотор тэнцвэржүүлэх;
  • хүчтэй тэнцвэргүй байдал, хамгийн үр дүнтэй, аюулгүй VM шилжих үед л тэнцвэржүүлэх (эцэст нь шилжилт хөдөлгөөн бүтэлгүйтэж болзошгүй);
  • харьцангуй "чимээгүй" виртуал машинуудыг тэнцвэржүүлэх ("шуугиантай" виртуал машиныг шилжүүлэхэд маш удаан хугацаа шаардагдана);
  • "зардал" - хадгалах систем ба сүлжээн дэх ачааллыг харгалзан тэнцвэржүүлэх (том үйлчлүүлэгчдэд тохирсон архитектуртай);
  • VM бүрийн зан үйлийн онцлогийг харгалзан тэнцвэржүүлэх;
  • Тэнцвэржүүлэлтийг ажлын бус цагаар (шөнө, амралтын өдрүүд, амралтын өдрүүд) хийх нь дээр.

Нийтийн үүлний хувьджижиг хэрэглэгчдэд үйлчилгээ үзүүлэхийн тулд DRS-ийг илүү олон удаа ашиглах боломжтой, дэвшилтэт боломжууд:

  • мэдээллийн аюулгүй байдлын хязгаарлалт, ойр дотно байдлын дүрэм байхгүй;
  • үүлэн дотор тэнцвэржүүлэх;
  • аль ч боломжийн үед тэнцвэржүүлэх;
  • аливаа VM-ийг тэнцвэржүүлэх;
  • "шуугиантай" виртуал машинуудыг тэнцвэржүүлэх (бусдад саад учруулахгүйн тулд);
  • виртуал машины өгөгдөл нь ихэвчлэн локал диск дээр байрладаг;
  • хадгалах систем, сүлжээний дундаж гүйцэтгэлийг харгалзан үзэх (үүлний архитектур нь нэгдсэн);
  • ерөнхий дүрэм болон дата төвийн зан байдлын статистикийн дагуу тэнцвэржүүлэх.

Асуудлын нарийн төвөгтэй байдал

Тэнцвэржүүлэхэд бэрхшээлтэй байдаг нь DRS олон тооны тодорхойгүй хүчин зүйлүүдтэй ажиллах ёстой:

  • үйлчлүүлэгчийн мэдээллийн систем бүрийн хэрэглэгчдийн зан байдал;
  • мэдээллийн системийн серверүүдийг ажиллуулах алгоритмууд;
  • DBMS серверүүдийн үйл ажиллагаа;
  • тооцоолох нөөц, хадгалах систем, сүлжээнд ачаалал;
  • үүлэн нөөцийн төлөөх тэмцэлд серверүүдийн харилцан үйлчлэл.

Олон тооны виртуал програмын серверүүд болон мэдээллийн баазын үүлэн нөөц дээр ачаалал нь цаг хугацааны явцад үүсдэг бөгөөд үр дагавар нь өөрөө илэрч, урьдчилан таамаглах аргагүй хугацаанд бие биентэйгээ давхцаж болно. Харьцангуй энгийн үйл явцыг хянахын тулд (жишээлбэл, хөдөлгүүр, гэртээ ус халаах системийг хянах) автомат удирдлагын системд нарийн төвөгтэй аргыг ашиглах шаардлагатай байдаг. пропорциональ-интеграл-дифференциал санал хүсэлт бүхий алгоритмууд.

Openstack дахь ачааллыг тэнцвэржүүлэх (2-р хэсэг)

Бидний даалгавар бол хэд хэдэн хэмжигдэхүүнээр илүү төвөгтэй бөгөөд хэрэглэгчдийн гадны нөлөөлөл байхгүй байсан ч систем нь боломжийн хугацаанд ачааллыг тогтсон утгыг тэнцвэржүүлж чадахгүй байх эрсдэлтэй.

Openstack дахь ачааллыг тэнцвэржүүлэх (2-р хэсэг)

Бидний хөгжлийн түүх

Энэ асуудлыг шийдэхийн тулд бид эхнээс нь биш, одоо байгаа туршлага дээрээ тулгуурлахаар шийдэж, энэ чиглэлээр туршлагатай мэргэжилтнүүдтэй харилцаж эхэлсэн. Аз болоход бидний асуудлын талаарх ойлголт бүрэн давхцсан.

Үе шат 1

Бид мэдрэлийн сүлжээний технологид суурилсан системийг ашиглаж, түүн дээр тулгуурлан нөөцөө оновчтой болгохыг хичээсэн.

Энэ үе шатны сонирхол нь шинэ технологийг турших явдал байсан бөгөөд түүний ач холбогдол нь стандарт бус хандлагыг хэрэгжүүлэхэд оршино, учир нь бусад зүйлс ижил байх үед стандарт арга барил нь бараг дуусаагүй байсан.

Бид системийг эхлүүлж, бид үнэхээр тэнцвэржүүлж эхэлсэн. Манай үүлний цар хүрээ нь хөгжүүлэгчдийн хэлсэн өөдрөг үр дүнг авах боломжийг бидэнд олгосонгүй, гэхдээ тэнцвэржүүлэлт ажиллаж байгаа нь тодорхой байв.

Үүний зэрэгцээ бидэнд нэлээд ноцтой хязгаарлалтууд байсан:

  • Мэдрэлийн сүлжээг сургахын тулд виртуал машинууд хэдэн долоо хоног эсвэл хэдэн сарын турш мэдэгдэхүйц өөрчлөлтгүйгээр ажиллах ёстой.
  • Алгоритм нь өмнөх "түүхэн" өгөгдлийн шинжилгээнд үндэслэн оновчтой болгох зорилготой юм.
  • Мэдрэлийн сүлжээг сургах нь нэлээд их хэмжээний өгөгдөл, тооцоолох нөөц шаарддаг.
  • Оновчлол, тэнцвэржүүлэлтийг харьцангуй ховор - хэдэн цаг тутамд нэг удаа хийх боломжтой бөгөөд энэ нь хангалттай биш юм.

Үе шат 2

Бид нөхцөл байдалд сэтгэл хангалуун бус байсан тул системийг өөрчлөхөөр шийдсэн бөгөөд үүнийг хийхийн тулд хариулаарай. гол асуулт - Бид хэний төлөө үүнийг хийж байна вэ?

Нэгдүгээрт - корпорацийн үйлчлүүлэгчдэд зориулсан. Энэ нь бидэнд зөвхөн хэрэгжилтийг хялбаршуулдаг корпорацийн хязгаарлалттай хурдан ажилладаг систем хэрэгтэй гэсэн үг юм.

Хоёр дахь асуулт - "Шуурхай" гэдэг үгийг та юу гэж ойлгох вэ? Богино хугацааны мэтгэлцээний үр дүнд бид 5-10 минутын хариу өгөх хугацааг эхлүүлж болох бөгөөд ингэснээр богино хугацааны өсөлт нь системийг резонанс болгохгүй байхаар шийдсэн.

Гурав дахь асуулт – тэнцвэртэй тооны серверийн хэмжээг сонгох вэ?
Энэ асуудал өөрөө шийдэгдсэн. Ихэвчлэн үйлчлүүлэгчид серверийн нэгтгэлийг тийм ч том болгодоггүй бөгөөд энэ нь нэгтгэлийг 30-40 серверт хязгаарлах тухай өгүүллийн зөвлөмжтэй нийцдэг.

Нэмж дурдахад серверийн санг сегментчилснээр бид тэнцвэржүүлэх алгоритмын ажлыг хялбаршуулдаг.

Дөрөв дэх асуулт – Урт суралцах үйл явц, ховор тэнцвэржүүлэлтээрээ мэдрэлийн сүлжээ бидэнд хэр тохиромжтой вэ? Бид үр дүнг секундын дотор авахын тулд илүү хялбар үйлдлийн алгоритмуудыг ашиглахын тулд үүнийг орхихоор шийдсэн.

Openstack дахь ачааллыг тэнцвэржүүлэх (2-р хэсэг)

Ийм алгоритмыг ашигладаг системийн тодорхойлолт болон түүний сул талуудыг олж болно энд

Бид энэ системийг нэвтрүүлж, эхлүүлж, урам зоригтой үр дүнд хүрсэн - одоо энэ нь үүлэн ачааллыг тогтмол шинжилж, виртуал машиныг шилжүүлэх зөвлөмжийг өгдөг бөгөөд энэ нь нэлээд зөв юм. Одоо ч гэсэн бид шинэ виртуал машинуудын нөөцийг 10-15% гаргахын зэрэгцээ одоо байгаа машинуудын ажлын чанарыг сайжруулж чадна гэдэг нь тодорхой байна.

Openstack дахь ачааллыг тэнцвэржүүлэх (2-р хэсэг)

RAM эсвэл CPU-ийн тэнцвэргүй байдал илэрсэн үед систем нь шаардлагатай виртуал машинуудыг шууд шилжүүлэхийг Tionix төлөвлөгч рүү команд өгдөг. Хяналтын системээс харахад виртуал машин нь нэг (дээд) хостоос нөгөө (доод) хост руу шилжиж, дээд хост дээр санах ойг чөлөөлсөн (шар дугуйгаар тодруулсан), доод талд нь (цагаан өнгөөр ​​тодруулсан) тус тус эзэлдэг. тойрог).

Одоо бид одоогийн алгоритмын үр нөлөөг илүү нарийвчлалтай үнэлэхийг оролдож байгаа бөгөөд үүнээс гарч болзошгүй алдааг олохыг хичээж байна.

Үе шат 3

Үүн дээр тайвширч, үр дүнтэй болохыг хүлээж, сэдвийг хааж болох юм шиг санагдаж байна.
Гэхдээ бид дараах тодорхой оновчлолын боломжуудаар шинэ үе шатыг явуулахад түлхэц болж байна

  1. Жишээ нь статистик, энд и энд Хоёр ба дөрвөн процессортой систем нь нэг процессортой системээс гүйцэтгэлийн хувьд мэдэгдэхүйц доогуур байгааг харуулж байна. Энэ нь бүх хэрэглэгчид нэг процессортой системтэй харьцуулахад олон процессорын системд худалдаж авсан CPU, RAM, SSD, LAN, FC-ээс хамаагүй бага гаралтыг авдаг гэсэн үг юм.
  2. Нөөц төлөвлөгчид өөрсдөө ноцтой алдаатай байж болно. нийтлэлүүдийн нэг нь энд байна энэ сэдэв дээр.
  3. Intel болон AMD-ийн санал болгож буй RAM болон кэшийг хянах технологи нь виртуал машинуудын үйл ажиллагааг судалж, "чимээгүй" хөршүүд нь "чимээгүй" виртуал машинуудад саад учруулахгүй байхаар байрлуулах боломжийг олгодог.
  4. Параметрүүдийн багцыг өргөжүүлэх (сүлжээ, хадгалах систем, виртуал машины тэргүүлэх чиглэл, шилжих зардал, шилжихэд бэлэн байдал).

Нийт

Тэнцвэржүүлэх алгоритмыг сайжруулах бидний ажлын үр дүн нь орчин үеийн алгоритмуудыг ашигласнаар дата төвийн нөөцийг мэдэгдэхүйц оновчтой болгох (25-30%), үйлчлүүлэгчдэд үзүүлэх үйлчилгээний чанарыг сайжруулах боломжтой гэсэн тодорхой дүгнэлт юм.

Мэдрэлийн сүлжээн дээр суурилсан алгоритм нь мэдээжийн хэрэг сонирхолтой шийдэл боловч цаашид хөгжүүлэх шаардлагатай бөгөөд одоо байгаа хязгаарлалтын улмаас хувийн үүлний ердийн эзлэхүүн дээр ийм төрлийн асуудлыг шийдвэрлэхэд тохиромжгүй юм. Үүний зэрэгцээ, алгоритм нь мэдэгдэхүйц хэмжээтэй нийтийн үүлэнд сайн үр дүнг харуулсан.

Бид дараах нийтлэлүүдэд процессор, хуваарь гаргагч, өндөр түвшний тэнцвэржүүлэх чадварын талаар дэлгэрэнгүй ярих болно.

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх