Гамшгаас хамгаалах шийдлүүдийн зах зээл дэх залуу тоглогчдын нэг бол 2016 онд Оросын гарааны компани болох Hystax юм. Гамшгийн нөхөн сэргээлтийн сэдэв нь маш их алдартай бөгөөд зах зээл нь маш өрсөлдөөнтэй тул стартап нь өөр өөр үүлэн дэд бүтцийн хооронд шилжих хөдөлгөөнд анхаарлаа хандуулахаар шийдсэн. Клоуд руу энгийн бөгөөд хурдан шилжих ажлыг зохион байгуулах боломжийг олгодог бүтээгдэхүүн нь Onlanta-ийн үйлчлүүлэгчдэд маш их хэрэгтэй болно. . Ингээд л би Hystax-тай танилцаж, түүний чадварыг туршиж эхэлсэн. Би энэ нийтлэлд юу болсныг танд хэлэх болно.
Hystax-ийн гол онцлог нь төрөл бүрийн виртуалчлалын платформ, зочны үйлдлийн систем, үүлэн үйлчилгээг дэмжих өргөн боломж бөгөөд энэ нь таны ажлын ачааллыг хаанаас ч, хаанаас ч шилжүүлэх боломжтой болгодог.
Энэ нь үйлчилгээний алдааг тэсвэрлэх чадварыг нэмэгдүүлэх DR шийдлүүдийг бий болгоод зогсохгүй өөр өөр сайтууд болон гиперскатеруудын хооронд нөөцийг хурдан, уян хатан байдлаар шилжүүлэх, зардлыг хэмнэж, тодорхой үйлчилгээний хамгийн оновчтой шийдлийг тухайн агшинд сонгох боломжийг олгоно. Гарчгийн зураг дээр жагсаасан платформуудаас гадна тус компани нь Оросын үүлэн үйлчилгээ үзүүлэгчидтэй идэвхтэй хамтран ажилладаг: Yandex.Cloud, CROC Cloud Services, Mail.ru болон бусад. 2020 онд тус компани Сколковод байрлах R&D төвийг нээсэн гэдгийг тэмдэглэх нь зүйтэй.
Зах зээл дээрх олон тооны тоглогчид нэг шийдлийг сонгох нь үнийн сайн бодлого, бүтээгдэхүүний хэрэглээ өндөр байгааг харуулж байгаа бөгөөд бид үүнийг практик дээр туршиж үзэхээр шийдсэн.
Тиймээс бидний тестийн даалгавар бол миний VMware тестийн сайт болон физик машинуудаас VMware-ийн удирддаг үйлчилгээ үзүүлэгчийн сайт руу шилжихээс бүрдэх болно. Тиймээ, ийм шилжилтийг хийх олон шийдэл байдаг, гэхдээ бид Hystax-ийг бүх нийтийн хэрэгсэл гэж үздэг бөгөөд шилжилт хөдөлгөөнийг боломжит бүх хослолоор турших нь ердөө л бодит бус ажил юм. Oncloud.ru үүл нь VMware дээр тусгайлан бүтээгдсэн тул энэхүү платформ нь биднийг илүү их сонирхдог. Дараа нь би үйл ажиллагааны үндсэн зарчмыг тайлбарлах болно, энэ нь ерөнхийдөө платформоос хамааралгүй бөгөөд аль ч талаас VMware-ийг өөр үйлдвэрлэгчийн платформоор сольж болно.
Эхний алхам бол системийн хяналтын самбар болох Hystax Acura-г байрлуулах явдал юм.
Энэ нь загвараас нээгддэг. Зарим шалтгааны улмаас бидний хувьд энэ нь бүрэн зөв биш байсан бөгөөд санал болгож буй 8CPU-ийн оронд 16Gb-ийг хагас нөөцөөр байрлуулсан. Тиймээс та тэдгээрийг өөрчлөхөө санах хэрэгтэй, эс тэгвээс бүх зүйл баригдсан VM доторх чингэлэгийн дэд бүтэц эхлэхгүй бөгөөд портал руу нэвтрэх боломжгүй болно. IN Шаардлагатай нөөц, түүнчлэн системийн бүх бүрэлдэхүүн хэсгүүдийн портуудыг нарийвчлан тайлбарласан болно.
Загвараар дамжуулан IP хаягийг тохируулахад бэрхшээлтэй байсан тул бид үүнийг консолоос өөрчилсөн. Үүний дараа та админ вэб интерфэйс рүү орж, анхны тохиргооны шидтэнг бөглөж болно.
Төгсгөлийн цэг - Манай vCenter-ийн IP эсвэл FQDN.
Нэвтрэх болон нууц үг - энэ нь ойлгомжтой.
Зорилтот ESXi хостын нэр нь манай кластерын хуулбарыг гүйцэтгэх хостуудын нэг юм.
Зорилтот мэдээллийн сан нь манай кластерт хуулбарлах өгөгдлийн сангуудын нэг юм.
Hystax Acura Control Panel Public IP – хяналтын самбарыг ашиглах боломжтой хаяг.
Хост болон мэдээллийн сангийн талаар бага зэрэг тодруулга хийх шаардлагатай. Үнэн хэрэгтээ Hystax хуулбар нь хост болон мэдээллийн сангийн түвшинд ажилладаг. Дараа нь би та түрээслэгчийн хост болон мэдээллийн санг хэрхэн өөрчлөх талаар хэлэх болно, гэхдээ асуудал өөр байна. Hystax нь нөөцийн сантай ажиллахыг дэмждэггүй, i.e. хуулбар нь үргэлж кластерын үндэс рүү очих болно (энэ материалыг бичих үед Hystax-ийн залуус шинэчилсэн хувилбарыг гаргаж, нөөцийн санг дэмжих талаархи миний хүсэлтийг хурдан хэрэгжүүлсэн). vCloud Director-ийг бас дэмждэггүй, i.e. Хэрэв миний тохиолдлын нэгэн адил түрээслэгч бүхэлдээ кластерт админ эрхгүй, зөвхөн тодорхой нөөцийн санд хандах эрхтэй бөгөөд бид Hystax-д хандах эрх өгсөн бол тэр эдгээр VM-ийг бие даан хуулбарлаж, ажиллуулах боломжтой болно, гэхдээ тэр Тэр хандах эрхтэй VMware дэд бүтцээс тэдгээрийг харах боломжгүй бөгөөд үүний дагуу виртуал машинуудыг цааш удирддаг. Кластерын администратор нь VM-ийг хүссэн нөөцийн сан руу шилжүүлэх эсвэл vCloud Director руу импортлох шаардлагатай.
Би яагаад эдгээр зүйлд маш их анхаарал хандуулж байна вэ? Учир нь, миний ойлгож байгаагаар бүтээгдэхүүний үзэл баримтлалыг хэрэглэгч Acura самбар ашиглан бие даан шилжүүлэх эсвэл DR-ийг хэрэгжүүлэх боломжтой байх ёстой. Гэхдээ одоог хүртэл VMware-ийн дэмжлэг нь ижил төстэй механизмуудыг аль хэдийн хэрэгжүүлсэн OpenStack-ийн дэмжлэгийн түвшнээс бага зэрэг хоцорч байна.
Гэхдээ дахин байршуулалт руугаа орцгооё. Юуны өмнө, самбарыг анх тохируулсны дараа бид системдээ анхны түрээслэгчийг бий болгох хэрэгтэй.
Энд байгаа бүх талбарууд тодорхой байна, би зөвхөн Үүлэн талбарын талаар танд хэлэх болно. Бидэнд анхны тохиргооны үеэр үүсгэсэн "өгөгдмөл" үүл аль хэдийн бий. Гэхдээ хэрэв бид түрээслэгч бүрийг өөрийн мэдээллийн сан болон нөөцийн санд байрлуулахыг хүсвэл үйлчлүүлэгч тус бүрт тусдаа үүл үүсгэснээр үүнийг хэрэгжүүлж чадна.
Шинэ үүл нэмэх маягт дээр бид анхны тохиргооны үеийнхтэй ижил параметрүүдийг зааж өгдөг (бид ижил хостыг ашиглаж болно), тодорхой хэрэглэгчдэд шаардлагатай мэдээллийн санг зааж өгдөг бөгөөд одоо нэмэлт параметрүүдэд шаардлагатай нөөцийг тус тусад нь зааж өгч болно. сан {"resource_pool" : "YOUR_POOL_NAME"}
Та анзаарсан байх, түрээслэгч үүсгэх маягт дээр нөөцийн хуваарилалт эсвэл квотын талаар юу ч байхгүй - системд эдгээрийн аль нь ч байхгүй. Түрээслэгчийг нэгэн зэрэг хуулбарлах тоо, хуулбарлах машинуудын тоо эсвэл бусад параметрээр хязгаарлах боломжгүй юм. Тиймээс бид анхны түрээслэгчийг бий болголоо. Одоо бүрэн логик биш, гэхдээ заавал хийх ёстой зүйл байна - Cloud агент суулгах. Агентийг тодорхой үйлчлүүлэгчийн хуудсан дээр татаж авсан тул энэ нь логикгүй юм.
Үүний зэрэгцээ, энэ нь үүсгэсэн түрээслэгчтэй холбоогүй бөгөөд манай бүх үйлчлүүлэгчид үүнийг (эсвэл хэд хэдэн, хэрэв бид тэдгээрийг байршуулах юм бол) дамжуулан хийх болно. Нэг агент нь нэгэн зэрэг 10 сессийг дэмждэг. Нэг машиныг нэг сесс гэж тооцдог. Хэдэн дисктэй байх нь хамаагүй. Өнөөдрийг хүртэл VMware-ийн дагуу Acura-д агентуудыг масштаблах механизм байхгүй байна. Өөр нэг тааламжгүй мөч байна - бид илүү их байршуулах шаардлагатай эсэх, эсвэл одоогийн суурилуулалт хангалттай эсэх талаар дүгнэлт хийхийн тулд Acura самбараас энэ агентийг "зайлсан" байдлыг харах боломж бидэнд алга. Үүний үр дүнд тавиур нь дараах байдлаар харагдаж байна.
Манай хэрэглэгчийн портал руу нэвтрэх дараагийн алхам бол данс үүсгэх явдал юм (мөн эхлээд энэ хэрэглэгчдэд хамаарах үүрэг).
Одоо манай үйлчлүүлэгч порталыг бие даан ашиглах боломжтой боллоо. Түүний хийх ёстой зүйл бол порталаас агентуудыг татаж аваад өөрийн талд суулгах явдал юм. Линукс, Windows, VMware гэсэн гурван төрлийн агент байдаг.
Эхний хоёрыг VMware-аас бусад гипервизор дээр физик эсвэл виртуал машин дээр суулгасан. Нэмэлт тохиргоо хийх шаардлагагүй, агентыг татаж авсан бөгөөд хаана тогшихоо аль хэдийн мэддэг бөгөөд нэг минутын дараа машин Acura самбар дээр харагдах болно. VMware агентын хувьд нөхцөл байдал арай илүү төвөгтэй байдаг. Асуудал нь VMware-ийн агентыг аль хэдийн бэлтгэсэн, шаардлагатай тохиргоог агуулсан порталаас татаж авсан явдал юм. Гэхдээ VMware агент нь манай Acura порталын талаар мэдэхээс гадна түүнийг байрлуулах виртуалчлалын системийн талаар мэдэх шаардлагатай.
VMware агентийг анх татаж авах үед систем биднээс энэ өгөгдлийг өгөхийг хүсэх болно. Асуудал нь аюулгүй байдлыг бүх нийтээрээ хайрладаг бидний эрин үед хүн бүр өөр хэн нэгний портал дээр админ нууц үгээ оруулахыг хүсэхгүй байгаа нь ойлгомжтой юм. Дотор талаас нь, байрлуулсны дараа агентыг ямар ч байдлаар тохируулах боломжгүй (та зөвхөн түүний сүлжээний тохиргоог өөрчлөх боломжтой). Энд би ялангуяа болгоомжтой үйлчлүүлэгчидтэй холбоотой бэрхшээлийг урьдчилан харж байна.
Тиймээс, агентуудыг суулгасны дараа бид Acura самбар руу буцаж очоод бүх машинуудаа харж болно.
Би системтэй хэд хоногийн турш ажиллаж байгаа тул өөр өөр мужуудад машинтай болсон. Би эдгээрийг бүгдийг нь Default бүлэгт байгаа боловч шаардлагатай бол тусдаа бүлгүүд үүсгэж, тэдэнд машин шилжүүлэх боломжтой. Энэ нь юунд ч нөлөөлөхгүй - зөвхөн өгөгдлийн логик танилцуулга, илүү тохиромжтой ажилд зориулж тэдгээрийг бүлэглэх. Үүний дараа бидний хийх ёстой хамгийн эхний бөгөөд хамгийн чухал зүйл бол шилжилт хөдөлгөөнийг эхлүүлэх явдал юм. Бид үүнийг гараар эсвэл хуваарийг тохируулах замаар, тэр дундаа бүх машинд нэг дор бөөнөөр нь хийж болно.
Hystax нь шилжилт хөдөлгөөнд зориулагдсан бүтээгдэхүүн байсныг сануулъя. Тиймээс хуулбарласан машинуудаа ажиллуулахын тулд DR төлөвлөгөө гаргах шаардлагатай байгаа нь гайхах зүйл биш юм. Төлөвлөгөөг аль хэдийн синхрончлогдсон төлөвт байгаа машинуудад зориулж хийж болно. Та нэг тодорхой VM болон бүх машинд нэг дор хоёуланг нь үүсгэж болно.
DR төлөвлөгөөг үүсгэх үед параметрийн багц нь таны шилжих дэд бүтцээс хамаарч өөр өөр байх болно. VMware орчинд хамгийн бага параметрийн багц боломжтой. Машинуудад зориулсан дахин IP-г бас дэмждэггүй. Үүнтэй холбогдуулан бид дараахь зүйлийг сонирхож байна: VM-ийн тайлбарт "дэд сүлжээ" параметр: "VMNetwork" бөгөөд бид VM-ийг кластер дахь тодорхой сүлжээнд холбодог. Зэрэглэл – хэд хэдэн VM-ийг шилжүүлэхэд хамааралтай бөгөөд энэ нь тэдгээрийг эхлүүлэх дарааллыг тодорхойлдог. Амт - VM-ийн тохиргоог тайлбарладаг, энэ тохиолдолд - 1CPU, 2GB RAM. Дэд сүлжээний хэсэгт бид "дэд сүлжээ": "VMNetwork" нь VMware "VM Network"-тэй холбоотой гэдгийг тодорхойлдог.
DR төлөвлөгөөг үүсгэх үед дискүүдийг өөр өөр мэдээллийн сангуудаар "тархах" арга байхгүй. Эдгээр нь энэ клиент үүлэнд зориулагдсан мэдээллийн сан дээр байрлах бөгөөд хэрэв танд өөр ангиллын диск байгаа бол энэ нь машиныг эхлүүлэхэд зарим хүндрэл учруулж болзошгүй бөгөөд VM-ийг Hystax-аас эхлүүлж, "салгасны" дараа мөн адил болно. шаардлагатай мэдээллийн сангууд руу тусдаа шилжих дискийг шаарддаг. Дараа нь бидний хийх ёстой зүйл бол DR төлөвлөгөөгөө эхлүүлж, машинууд маань босохыг хүлээх явдал юм. P2V/V2V хувиргах процесс нь бас цаг хугацаа шаарддаг. Миний хамгийн том туршилтын машин болох 100 ГБ гурван дисктэй, хамгийн ихдээ 10 минут зарцуулсан.
Үүний дараа та ажиллаж байгаа VM, түүн дээрх үйлчилгээ, өгөгдлийн нийцтэй байдлыг шалгаж, бусад шалгалтыг хийх хэрэгтэй.
Дараа нь бидэнд хоёр арга бий:
- Устгах – ажиллаж байгаа DR төлөвлөгөөг устгана. Энэ үйлдэл нь зүгээр л ажиллаж байгаа VM-г унтраах болно. Эдгээр хуулбарууд хаашаа ч явахгүй.
- Салгах – хуулбарласан машиныг Acura-аас салгах, өөрөөр хэлбэл. шилжих үйл явцыг үнэндээ дуусгах.
Шийдлийн давуу талууд:
- үйлчлүүлэгч болон үйлчилгээ үзүүлэгчээс суулгах, тохируулахад хялбар байдал;
- шилжилт хөдөлгөөнийг тохируулах, DR төлөвлөгөө гаргах, хуулбарыг эхлүүлэхэд хялбар;
- дэмжлэг болон хөгжүүлэгчид олдсон асуудлуудад маш хурдан хариу өгч, платформ эсвэл агентын шинэчлэлтүүдийг ашиглан засдаг.
Минусы
- Vmware-ийн дэмжлэг хангалтгүй.
- Платформоос түрээслэгчдэд зориулсан квот байхгүй.
Би мөн онцлох хүсэлтийг эмхэтгэсэн бөгөөд бид үүнийг худалдагчид илгээсэн:
- Cloud агентуудад зориулсан Acura удирдлагын консолоос ашиглалтын хяналт, байршуулалт;
- түрээслэгчдэд зориулсан квот байгаа эсэх;
- түрээслэгч бүрийн хувьд нэгэн зэрэг хуулбарлах тоо, хурдыг хязгаарлах чадвар;
- VMware vCloud Director-ийн дэмжлэг;
- нөөцийн санд дэмжлэг үзүүлэх (туршилтын явцад хэрэгжүүлсэн);
- Acura самбар дээрх үйлчлүүлэгчийн дэд бүтцээс итгэмжлэл оруулахгүйгээр VMware агентийг агентаас өөрөө тохируулах чадвар;
- DR төлөвлөгөөг ажиллуулж байх үед VM эхлүүлэх үйл явцын "дүрслэл".
Надад том шүүмжлэлд өртсөн цорын ганц зүйл бол баримт бичиг байсан. Би "хар хайрцаг"-д үнэхээр дургүй бөгөөд дотор нь бүтээгдэхүүн хэрхэн ажилладаг талаар нарийвчилсан баримт бичиг байгаа тохиолдолд илүүд үздэг. Хэрэв AWS болон OpenStack-ийн хувьд бүтээгдэхүүнийг илүү их эсвэл бага тайлбарласан бол VMware-ийн хувьд маш бага баримт бичиг байдаг.
Зөвхөн Acura самбарыг байрлуулах талаар тайлбарласан Суулгах гарын авлага байдаг бөгөөд Cloud агент хэрэгтэй гэсэн үг ч байхгүй. Бүтээгдэхүүний иж бүрэн үзүүлэлтүүд байгаа нь сайн хэрэг. Жишээ болгон AWS болон OpenStack-ийг ашиглан "эхнээс нь дуустал" тохиргоог тайлбарласан баримт бичиг байдаг (хэдийгээр энэ нь миний хувьд блогийн нийтлэл шиг харагдаж байна), мөн маш бага Мэдлэгийн сан байдаг.
Ерөнхийдөө энэ нь миний томоохон борлуулагчдаас дассан баримт бичгийн формат биш тул надад тийм ч таатай байгаагүй. Үүний зэрэгцээ, энэ баримт бичигт систем хэрхэн "дотор" ажилладаг талаархи зарим нарийн ширийн зүйлийн талаар би хэзээ ч хариулт олж чадаагүй - техникийн туслалцаатайгаар олон асуултыг тодруулах шаардлагатай байсан бөгөөд энэ нь стенд байрлуулах, явуулах үйл явцыг нэлээд хойшлуулсан. туршилт.
Дүгнэж хэлэхэд, би бүтээгдэхүүн, компанийн ажилдаа хандах хандлага нь надад таалагдсан гэж хэлж болно. Тиймээ, дутагдалтай тал бий, функциональ дутагдалтай (VMware-тай холбоотой) үнэхээр ноцтой дутагдал байна. Юуны өмнө тус компани олон нийтийн үүл, тэр дундаа AWS дээр төвлөрсөн хэвээр байгаа нь тодорхой бөгөөд зарим хүмүүсийн хувьд энэ нь хангалттай байх болно. Олон компаниуд олон үүлэн стратегийг сонгож байгаа өнөө үед ийм энгийн бөгөөд тохиромжтой бүтээгдэхүүнтэй байх нь туйлын чухал юм. Өрсөлдөгчидтэй харьцуулахад хамаагүй хямд үнийг харгалзан үзвэл энэ нь бүтээгдэхүүнийг маш их сонирхол татахуйц болгодог.
Бид багийн гишүүн хайж байна . Магадгүй чи юм болов уу?
Эх сурвалж: www.habr.com