Хөөе Хабр!
Шинэ жилийн амралтын дараа бид хоёр сайт дээр тулгуурлан гамшгаас хамгаалах үүл ажиллуулсан. Өнөөдөр бид энэ нь хэрхэн ажилладагийг хэлж, кластерын бие даасан элементүүд бүтэлгүйтэж, сайт бүхэлдээ эвдэрсэн үед үйлчлүүлэгчийн виртуал машинд юу тохиолдохыг харуулах болно (спойлер - бүх зүйл зүгээр).
OST сайт дээрх гамшигт тэсвэртэй үүл хадгалах систем.
Дотор нь юу байна
Бүрээсний доор кластер нь VMware ESXi гипервизор бүхий Cisco UCS серверүүд, хоёр INFINIDAT InfiniBox F2240 хадгалах систем, Cisco Nexus сүлжээний төхөөрөмж, түүнчлэн Brocade SAN шилжүүлэгчтэй. Кластер нь OST ба NORD гэсэн хоёр сайтад хуваагддаг, өөрөөр хэлбэл мэдээллийн төв бүр ижил төрлийн тоног төхөөрөмжтэй байдаг. Чухамдаа энэ нь түүнийг гамшигт тэсвэртэй болгодог.
Нэг сайт дотор үндсэн элементүүд нь давхардсан байдаг (хостууд, SAN шилжүүлэгч, сүлжээ).
Хоёр сайтыг тусгай зориулалтын шилэн кабелиар холбосон, мөн нөөцлөгдсөн.
Хадгалах системийн талаар хэдэн үг хэлье. Бид NetApp дээр гамшигт тэсвэртэй үүлний анхны хувилбарыг бүтээсэн. Энд бид INFINIDAT-ийг сонгосон бөгөөд яагаад гэвэл:
- Идэвхтэй-Идэвхтэй хуулбарлах сонголт. Энэ нь хадгалах системийн аль нэг нь бүрэн доголдсон ч гэсэн виртуал машиныг ажиллуулах боломжийг олгодог. Би дараа нь хуулбарлах талаар дэлгэрэнгүй ярих болно.
- Системийн алдааг тэсвэрлэх чадварыг нэмэгдүүлэх гурван дискний хянагч. Ихэвчлэн хоёр байдаг.
- Бэлэн шийдэл. Бид сүлжээнд холбогдож, тохируулах шаардлагатай урьдчилан угсарсан тавиурыг хүлээн авлаа.
- Анхааралтай техникийн дэмжлэг. INFINIDAT инженерүүд хадгалах системийн бүртгэл, үйл явдлуудад байнга дүн шинжилгээ хийж, шинэ програм хангамжийн хувилбаруудыг суулгаж, тохиргоо хийхэд тусалдаг.
Энд задлах үеийн зарим зургууд байна:
Энэ нь хэрхэн ажилладаг вэ?
Үүл нь аль хэдийн алдааг тэсвэрлэдэг. Энэ нь үйлчлүүлэгчийг нэг техник хангамж, програм хангамжийн алдаанаас хамгаалдаг. Гамшигт тэсвэртэй нь нэг сайт доторх их хэмжээний эвдрэлээс хамгаалахад тусална: жишээлбэл, хадгалах системийн эвдрэл (эсвэл ихэвчлэн тохиолддог SDS кластер 🙂), хадгалах сүлжээн дэх асар их алдаа гэх мэт. За, хамгийн чухал нь: гал түймэр, гэрэл тасрах, довтлогчдыг булаан авах, харь гаригийн газардах зэргээс болж сайт бүхэлдээ нэвтрэх боломжгүй болсон үед ийм үүл нь авардаг.
Эдгээр бүх тохиолдлуудад үйлчлүүлэгчийн виртуал машинууд үргэлжлүүлэн ажиллаж байгаа бөгөөд яагаад гэдгийг эндээс үзнэ үү.
Кластерийн загвар нь үйлчлүүлэгчийн виртуал машинтай аливаа ESXi хост нь хоёр хадгалах системийн аль нэгэнд хандах боломжтой байхаар хийгдсэн. Хэрэв OST сайт дээрх хадгалах систем амжилтгүй болвол виртуал машинууд үргэлжлүүлэн ажиллах болно: тэдгээрийн ажиллаж байгаа хостууд нь NORD дээрх хадгалах системд өгөгдөл авах болно.
Кластер дахь холболтын диаграм иймэрхүү харагдаж байна.
Энэ нь хоёр сайтын SAN даавуунуудын хооронд Inter-Switch холбоосыг тохируулсан тул боломжтой юм: Fabric A OST SAN шилжүүлэгч нь Fabric A NORD SAN шилжүүлэгчтэй холбогдсон ба Fabric B SAN шилжүүлэгчтэй адил.
SAN үйлдвэрүүдийн эдгээр бүх нарийн ширийн зүйлийг ойлгохын тулд Идэвхтэй-Идэвхтэй хуулбарыг хоёр санах ойн системийн хооронд тохируулсан: мэдээлэл нь локал болон алсын санах ойн системд бараг нэгэн зэрэг бичигддэг, RPO = 0. Анхны өгөгдөл нь нэг санах ойн системд хадгалагдаж, хуулбар нь нөгөө дээр хадгалагддаг. Өгөгдлийг хадгалах багтаамжийн түвшинд хуулбарлах ба VM өгөгдөл (түүний диск, тохиргооны файл, своп файл гэх мэт) тэдгээрт хадгалагддаг.
ESXi хост нь үндсэн эзлэхүүн болон түүний хуулбарыг нэг дискний төхөөрөмж (Хадгалах төхөөрөмж) гэж хардаг. ESXi хостоос дискний төхөөрөмж бүрт 24 зам байдаг:
12 зам нь үүнийг локал хадгалах системд (оновчтой замууд), үлдсэн 12 нь алсын хадгалах системд (оновчтой бус зам) холбодог. Ердийн нөхцөлд ESXi нь "хамгийн оновчтой" замыг ашиглан дотоод санах ойн систем дээрх өгөгдөлд ханддаг. Энэ хадгалах систем ажиллахаа больсон үед ESXi оновчтой замаа алдаж, "оновчтой бус" руу шилждэг. Диаграм дээр иймэрхүү харагдаж байна.
Гамшгаас хамгаалах кластерын схем.
Бүх үйлчлүүлэгчийн сүлжээнүүд нь нийтлэг сүлжээгээр дамжуулан хоёр сайттай холбогддог. Сайт бүр нь үйлчлүүлэгчийн сүлжээг зогсоодог Provider Edge (PE) ажиллуулдаг. PE нь нийтлэг кластерт нэгдсэн. Хэрэв нэг сайт дээр PE бүтэлгүйтвэл бүх урсгалыг хоёр дахь сайт руу шилжүүлнэ. Үүний ачаар PE-гүй үлдсэн сайтын виртуал машинууд үйлчлүүлэгчдэд сүлжээгээр нэвтрэх боломжтой хэвээр байна.
Одоо янз бүрийн бүтэлгүйтлийн үед үйлчлүүлэгчийн виртуал машинд юу тохиолдохыг харцгаая. Хамгийн хөнгөн сонголтуудаас эхэлж, хамгийн ноцтойгоор дуусгацгаая - бүхэл бүтэн сайтын бүтэлгүйтэл. Жишээнүүдэд үндсэн платформ нь OST байх ба мэдээллийн хуулбар бүхий нөөц платформ нь NORD байх болно.
Үйлчлүүлэгчийн виртуал машинд юу тохиолдох вэ гэвэл...
Хуулбарлах холбоос амжилтгүй боллоо. Хоёр сайтын хадгалах системүүдийн хооронд хуулбарлах нь зогсдог.
ESXi нь зөвхөн дотоод дискний төхөөрөмжтэй ажиллах болно (хамгийн оновчтой замаар).
Виртуал машинууд үргэлжлүүлэн ажиллаж байна.
ISL (Inter-Switch Link) эвдэрнэ. Боломжгүй үйл явдал. Ямар нэг галзуу экскаватор бие даасан маршрутаар ажилладаг хэд хэдэн оптик замыг нэг дор ухаж, өөр өөр оролтоор сайт руу авчрахгүй л бол. Гэхдээ ямар ч байсан. Энэ тохиолдолд ESXi хостууд замын талыг алдаж, зөвхөн дотоод хадгалах системд хандах боломжтой. Хуулбаруудыг цуглуулсан боловч хостууд тэдгээрт хандах боломжгүй болно.
Виртуал машинууд хэвийн ажиллаж байна.
SAN шилжүүлэгч сайтуудын аль нэгэнд амжилтгүй болсон. ESXi хостууд нь хадгалах системд хүрэх замуудын заримыг алддаг. Энэ тохиолдолд шилжүүлэлт амжилтгүй болсон сайтын хостууд зөвхөн HBA-нхаа аль нэгээр дамжуулан ажиллах болно.
Виртуал машинууд хэвийн ажиллаж байна.
Аль нэг сайт дээрх бүх SAN шилжүүлэгч амжилтгүй болсон. OST сайт дээр ийм гамшиг тохиолдсон гэж бодъё. Энэ тохиолдолд энэ сайт дээрх ESXi хостууд диск төхөөрөмж рүүгээ орох бүх замаа алдах болно. Стандарт VMware vSphere HA механизм ажиллаж байна: энэ нь NORD дахь OST сайтын бүх виртуал машинуудыг дээд тал нь 140 секундын дотор дахин эхлүүлэх болно.
NORD сайтын хостууд дээр ажиллаж байгаа виртуал машинууд хэвийн ажиллаж байна.
ESXi хост нэг сайт дээр амжилтгүй болсон. Энд vSphere HA механизм дахин ажиллана: бүтэлгүйтсэн хостын виртуал машинууд бусад хостууд дээр - ижил эсвэл алсын сайт дээр дахин ачаалагдана. Виртуал машиныг дахин эхлүүлэх хугацаа 1 минут хүртэл байна.
Хэрэв OST сайт дээрх бүх ESXi хостууд амжилтгүй болвол ямар ч сонголт байхгүй: VM-ууд өөр дээр дахин ачаалагдана. Дахин эхлүүлэх хугацаа ижил байна.
Хадгалах систем нэг сайт дээр амжилтгүй болсон. OST сайт дээр хадгалах систем амжилтгүй болсон гэж бодъё. Дараа нь OST сайтын ESXi хостууд NORD дахь хадгалалтын хуулбартай ажиллахад шилжинэ. Амжилтгүй болсон хадгалалтын систем үйлчилгээнд буцаж ирсний дараа албадан хуулбарлах ба ESXi OST хостууд локал хадгалах системд дахин нэвтэрч эхэлнэ.
Энэ бүх хугацаанд виртуал машинууд хэвийн ажиллаж байсан.
Сайтуудын нэг нь амжилтгүй болсон. Энэ тохиолдолд бүх виртуал машинууд vSphere HA механизмаар дамжуулан нөөц сайт дээр дахин ачаалагдах болно. VM-ийг дахин эхлүүлэх хугацаа 140 секунд байна. Энэ тохиолдолд виртуал машины бүх сүлжээний тохиргоо хадгалагдах бөгөөд энэ нь сүлжээгээр дамжуулан үйлчлүүлэгчдэд хандах боломжтой хэвээр байна.
Нөөцлөлтийн сайт дээрх машинуудыг дахин эхлүүлэх ажлыг хэвийн явуулахын тулд сайт бүр хагасаар дүүрсэн байна. Хоёр дахь хагас нь бүх виртуал машинууд хоёр дахь гэмтсэн сайтаас шилжих тохиолдолд нөөц юм.
Хоёр өгөгдлийн төвд суурилсан гамшигт тэсвэртэй үүл нь ийм эвдрэлээс хамгаалдаг.
Энэ таашаал нь хямдхан биш, учир нь үндсэн нөөцөөс гадна хоёр дахь талбайд нөөц шаардлагатай байдаг. Тиймээс бизнесийн чухал үйлчилгээг ийм үүлэн дотор байрлуулж, урт хугацааны сул зогсолт нь санхүүгийн болон нэр хүндэд ихээхэн хэмжээний хохирол учруулдаг, эсвэл мэдээллийн систем нь зохицуулагчид эсвэл компанийн дотоод дүрэм журмын дагуу гамшигт тэсвэртэй байх шаардлагыг дагаж мөрддөг.
Эх сурвалж:
Эх сурвалж: www.habr.com