Сайн байна уу, Хабр уншигчид! Сүүлийн нийтлэлд бид AERODISK ENGINE хадгалах систем дэх гамшгийг арилгах энгийн арга хэрэгсэл болох хуулбарлах талаар ярилцсан. Энэ нийтлэлд бид илүү төвөгтэй, сонирхолтой сэдвийг судлах болно - метрокластер, өөрөөр хэлбэл дата төвүүдийг идэвхтэй-идэвхтэй горимд ажиллуулах боломжийг олгодог хоёр дата төвийн гамшгаас хамгаалах автомат хэрэгсэл юм. Бид чамд хэлнэ, үзүүлнэ, эвдэж засна.
Ердийнх шигээ эхлээд онол
Метрокластер гэдэг нь хот, бүс нутгийн хэд хэдэн газарт тархсан кластер юм. "Кластер" гэдэг үг нь цогцолбор нь автоматжуулсан, өөрөөр хэлбэл бүтэлгүйтсэн тохиолдолд кластерын зангилаанууд автоматаар солигддог гэдгийг тодорхой харуулж байна.
Метрокластер ба ердийн хуулбар хоёрын гол ялгаа энд л оршдог. Үйл ажиллагааны автоматжуулалт. Өөрөөр хэлбэл, тодорхой осол гарсан тохиолдолд (өгөгдлийн төвийн эвдрэл, эвдэрсэн суваг гэх мэт) хадгалах систем нь мэдээллийн хүртээмжийг хадгалахын тулд шаардлагатай үйлдлүүдийг бие даан гүйцэтгэдэг. Тогтмол хуулбарыг ашиглах үед эдгээр үйлдлийг администратор бүхэлд нь эсвэл хэсэгчлэн гараар гүйцэтгэдэг.
Энэ нь юу хийдэг вэ?
Метрокластерын тодорхой хэрэгжилтийг ашиглах үед үйлчлүүлэгчдийн зорьж буй гол зорилго бол RTO (Сэргээх хугацааны зорилго) багасгах явдал юм. Энэ нь алдаа гарсны дараа мэдээллийн технологийн үйлчилгээг сэргээх хугацааг багасгах явдал юм. Хэрэв та тогтмол хуулбарыг ашигладаг бол нөхөн сэргээх хугацаа нь метро кластертай сэргээх хугацаанаас үргэлж урт байх болно. Яагаад? Маш энгийн. Администратор өөрийн ширээн дээр байх ёстой бөгөөд хуулбарыг гараар солих ёстой бөгөөд метро кластер үүнийг автоматаар хийдэг.
Хэрэв танд унтдаггүй, хоол иддэггүй, тамхи татдаггүй, өвддөггүй, хадгалалтын системийн байдлыг 24 цагийн турш хянаж байдаг тусгай жижүүр байхгүй бол администратор нь жижүүргүй болно гэсэн баталгаа байхгүй. алдаа гарсан үед гараар солих боломжтой байх.
Үүний дагуу администраторын үүргийн үйлчилгээний 99-р түвшний метрокластер эсвэл үхэшгүй администратор байхгүй тохиолдолд RTO нь бүх системд шилжих хугацаа ба администратор ажиллаж эхлэх баталгаатай байх хамгийн дээд хугацааны нийлбэртэй тэнцүү байх болно. хадгалах систем болон холбогдох системүүдтэй.
Тиймээс бид RTO-д тавигдах шаардлага нь цаг, өдөр биш минут, харин дата төвийн доголдол гарсан тохиолдолд МТ-ийн хэлтэс нь бизнест цаг хугацаа өгөх шаардлагатай бол метро кластерийг ашиглах ёстой гэсэн тодорхой дүгнэлтэд хүрч байна. Мэдээллийн технологийн үйлчилгээний хандалтыг хэдэн минут, бүр секундын дотор сэргээх.
энэ нь хэрхэн ажилладаг вэ?
Доод түвшинд метро кластер нь өмнөх нийтлэлд дурдсан өгөгдлийг синхрон хуулбарлах механизмыг ашигладаг (харна уу. ). Хуулбарлах нь синхрон байдаг тул түүнд тавигдах шаардлага нь тохирч байна, эс тэгвээс:
- физикийн хувьд оптик шилэн, 10 гигабит Ethernet (эсвэл түүнээс дээш);
- мэдээллийн төвүүдийн хоорондох зай 40 км-ээс ихгүй байна;
- Өгөгдлийн төвүүдийн хоорондох (хадгалах системүүдийн хооронд) оптик сувгийн саатал 5 миллисекунд хүртэл (хамгийн тохиромжтой нь 2).
Эдгээр бүх шаардлагууд нь зөвлөн туслах шинж чанартай, өөрөөр хэлбэл эдгээр шаардлагыг хангаагүй байсан ч метро кластер ажиллах болно, гэхдээ эдгээр шаардлагыг дагаж мөрдөөгүйн үр дагавар нь хоёр дахь хадгалалтын системийн үйл ажиллагаа удаашрахтай тэнцүү гэдгийг бид ойлгох ёстой. метро кластер.
Тиймээс, синхрон хуулбарыг хадгалах системүүдийн хооронд өгөгдөл дамжуулахад ашигладаг бөгөөд хуулбарууд хэрхэн автоматаар солигддог, хамгийн чухал нь тархи хуваагдахаас хэрхэн зайлсхийх вэ? Үүнийг хийхийн тулд илүү өндөр түвшинд нэмэлт байгууллага - арбитрыг ашигладаг.
Арбитрч хэрхэн ажилладаг вэ, түүний үүрэг юу вэ?
Арбитр нь жижиг виртуал машин эсвэл тоног төхөөрөмжийн кластер бөгөөд үүнийг гуравдагч сайт дээр (жишээлбэл, оффис дээр) ажиллуулж, ICMP болон SSH-ээр дамжуулан хадгалах системд нэвтрэх боломжийг олгодог. Эхлүүлсний дараа арбитр нь IP-г тохируулах ёстой бөгөөд дараа нь хадгалалтын талаас түүний хаяг, мөн метро кластерт оролцдог алсын удирдлагануудын хаягийг зааж өгөх ёстой. Үүний дараа шүүгч ажиллахад бэлэн байна.
Арбитр нь метрокластер дахь бүх хадгалалтын системийг байнга хянаж байдаг бөгөөд хэрэв тодорхой хадгалах систем байхгүй бол кластерын өөр гишүүн ("амьд" хадгалах системүүдийн нэг) боломжгүй болохыг баталгаажуулсны дараа хуулбарлах дүрмийг өөрчлөх процедурыг эхлүүлэхээр шийддэг. болон зураглал.
Маш чухал цэг. Арбитрч нь хадгалалтын систем байрладаг газраас өөр газар, өөрөөр хэлбэл 1-р хадгалах систем суурилуулсан өгөгдлийн төв 1-д, 2-р хадгалах систем суурилуулсан өгөгдлийн төвд 2-т байхгүй байх ёстой.
Яагаад? Учир нь энэ бол арбитрч хадгалалтын систем суурилуулсан хоёр сайтын аль нэгнийх нь уналтыг хоёрдмол утгагүй, үнэн зөв тодорхойлох цорын ганц арга зам юм. Арбитрыг томилох бусад аргууд нь тархи хуваагдахад хүргэдэг.
Одоо арбитрчийн ажлын нарийн ширийнийг авч үзье.
Арбитр нь бүх хадгалалтын хянагчдыг байнга санал асуулга явуулдаг хэд хэдэн үйлчилгээг ажиллуулдаг. Санал асуулгын үр дүн өмнөхөөсөө ялгаатай (боломжтой/боломжгүй) бол энэ нь арбитр дээр ажилладаг жижиг мэдээллийн санд бүртгэгдэнэ.
Арбитрчийн ажлын логикийг илүү нарийвчлан авч үзье.
Алхам 1: Боломжгүй байдлыг тодорхойлох. Хадгалах системийн доголдол гэдэг нь нэг хадгалах системийн хоёр хянагчаас 5 секундын дотор ping байхгүй байх явдал юм.
Алхам 2. Шилжүүлэн суулгах процедурыг эхлүүлнэ үү. Арбитр хадгалах системүүдийн аль нэг нь ажиллахгүй байгааг мэдээд "үхсэн" хадгалах систем үнэхээр үхсэн эсэхийг шалгахын тулд "амьд" хадгалах системд хүсэлт илгээдэг.
Арбитраас ийм тушаал хүлээн авсны дараа хоёр дахь (амьд) хадгалах систем нь унасан анхны хадгалах систем байгаа эсэхийг нэмэлт шалгаж, хэрэв байхгүй бол арбитрч өөрийн таамаглалыг баталгаажуулна. Хадгалах систем үнэхээр боломжгүй байна.
Ийм баталгаажуулалтыг хүлээн авсны дараа арбитр унасан санах ойн систем дээр идэвхтэй (анхдагч) байсан хуулбарууд дээр хуулбарлах, зураглалыг нэмэгдүүлэх алсын горимыг эхлүүлж, хоёр дахь хадгалалтын систем рүү эдгээр хуулбарыг хоёрдогчоос үндсэн болон хувиргах тушаалыг илгээдэг. зураглалыг нэмэгдүүлэх. За, хоёр дахь хадгалах систем нь эдгээр процедурыг гүйцэтгэдэг бөгөөд дараа нь алдагдсан LUN-д хандах боломжийг олгодог.
Яагаад нэмэлт баталгаажуулалт шаардлагатай байна вэ? Чуулгын төлөө. Өөрөөр хэлбэл, кластерийн нийт сондгой (3) тооны гишүүдийн дийлэнх нь кластерийн зангилааны аль нэгний уналтыг баталгаажуулах ёстой. Тэгж байж л энэ шийдвэр гарцаагүй зөв болно. Энэ нь алдаатай шилжихээс зайлсхийхийн тулд шаардлагатай бөгөөд үүний дагуу тархи хуваагдана.
2-р алхам нь ойролцоогоор 5-10 секунд үргэлжлэх тул ослын дараа 5-10 секундын дотор боломжгүй байдлыг тодорхойлоход шаардагдах хугацааг (15 секунд) харгалзан үзвэл унасан хадгалах системээс LUN-ууд автоматаар шууд ажиллах боломжтой болно. хадгалах систем.
Хостуудтай холболтоо алдахаас зайлсхийхийн тулд та хостууд дээрх завсарлагыг зөв тохируулах талаар анхаарах хэрэгтэй. Санал болгож буй завсарлага нь дор хаяж 30 секунд байна. Энэ нь гамшгийн үед ачааллыг солих үед хостыг хадгалах системтэй холболтыг таслахаас сэргийлж, оролт гаралтын тасалдал байхгүй гэдгийг баталгаажуулах болно.
Түр хүлээнэ үү, хэрвээ метрокластерт бүх зүйл сайн байгаа бол бидэнд яагаад байнгын хуулбар хэрэгтэй байна вэ?
Бодит байдал дээр бүх зүйл тийм ч хялбар биш юм.
Метрокластерын давуу болон сул талуудыг авч үзье
Тиймээс, ердийн хуулбартай харьцуулахад метроны кластерын тодорхой давуу талууд нь:
- Бүрэн автоматжуулалт, гамшгийн үед нөхөн сэргээх хамгийн бага хугацааг хангах;
- Тэгээд л болоо :-).
Одоо анхаарлаа хандуулаарай, сул талууд:
- Шийдлийн зардал. Хэдийгээр Aerodisk систем дэх метрокластер нь нэмэлт лиценз шаарддаггүй (хуулбарлахтай ижил лицензийг ашигладаг) шийдлийн өртөг нь синхрон хуулбарыг ашиглахаас ч өндөр байх болно. Та синхрон хуулбарт тавигдах бүх шаардлагыг хэрэгжүүлэх шаардлагатай бөгөөд нэмэлт шилжүүлэлт болон нэмэлт сайттай холбоотой метроны кластерт тавигдах шаардлагуудыг (метрокластер төлөвлөлтийг үзнэ үү);
- Шийдлийн нарийн төвөгтэй байдал. Метрокластер нь ердийн хуулбараас хамаагүй илүү төвөгтэй бөгөөд төлөвлөлт, тохиргоо, баримтжуулалтад илүү их анхаарал, хүчин чармайлт шаарддаг.
Эцэст нь. Metrocluster бол үнэхээр RTO-г секунд эсвэл минутын дотор өгөх шаардлагатай үед технологийн хувьд маш дэвшилтэт, сайн шийдэл юм. Гэхдээ ийм даалгавар байхгүй, RTO нь олон цагаар ажиллахад тохиромжтой бол их буунаас бор шувуу буудах нь утгагүй болно. Метроны кластер нь нэмэлт зардал, мэдээллийн технологийн дэд бүтцэд хүндрэл учруулах тул ердийн ажилчин тариачны хуулбар хангалттай.
Метро кластер төлөвлөлт
Энэ хэсэг нь метро кластерын дизайны талаархи дэлгэрэнгүй гарын авлага гэж хэлэхгүй бөгөөд хэрэв та ийм системийг бий болгохоор шийдсэн бол боловсруулах ёстой үндсэн чиглэлүүдийг л харуулсан болно. Тиймээс, метро кластерийг бодитоор хэрэгжүүлэхдээ хадгалах системийн үйлдвэрлэгч (өөрөөр хэлбэл бид) болон бусад холбогдох системийг зөвлөлдөхөд оролцуулахаа мартуузай.
Байршил
Дээр дурдсанчлан, метро кластерт хамгийн багадаа гурван сайт шаардлагатай. Хадгалах систем болон холбогдох системүүд ажиллах хоёр дата төв, мөн арбитрч ажиллах гуравдагч сайт.
Дата төвүүдийн хооронд санал болгож буй зай нь 40 км-ээс ихгүй байна. Илүү том зай нь нэмэлт саатал үүсгэх магадлал өндөр бөгөөд энэ нь метроны кластерын хувьд туйлын хүсээгүй юм. Саатал нь 5 миллисекунд хүртэл байх ёстойг сануулъя, гэхдээ 2-ын дотор байлгахыг зөвлөж байна.
Төлөвлөлтийн явцад саатал гарсан эсэхийг шалгахыг зөвлөж байна. Мэдээллийн төвүүдийн хооронд шилэн кабелиар хангадаг ямар ч боловсорсон үйлчилгээ үзүүлэгч нь чанарын шалгалтыг маш хурдан зохион байгуулж чадна.
Арбитрчийн өмнө саатал гарах тухайд (өөрөөр хэлбэл гурав дахь сайт ба эхний хоёрын хооронд) санал болгож буй саатлын босго нь 200 миллисекунд хүртэл, өөрөөр хэлбэл интернетээр тогтмол корпорацийн VPN холболт тохиромжтой.
Шилжүүлэн суулгах ба сүлжээ
Хуулбарлах схемээс ялгаатай нь өөр өөр сайтуудын хадгалалтын системийг холбоход хангалттай байдаг бол метрокластерын схем нь өөр өөр сайтууд дахь хоёр хадгалах системтэй хостуудыг холбохыг шаарддаг. Ялгаа нь юу болохыг илүү тодорхой болгохын тулд хоёр схемийг доор харуулав.
Диаграмаас харахад манай сайтын 1 хостууд нь хадгалах систем 1 болон хадгалах систем 2-ыг хоёуланг нь хардаг. Мөн эсрэгээр сайт 2 хостууд хадгалах систем 2 болон хадгалах систем 1-ийг хоёуланг нь хардаг. Өөрөөр хэлбэл, хост бүр хадгалах системийг хоёуланг нь хардаг. Энэ нь метро кластерийн үйл ажиллагааны урьдчилсан нөхцөл юм.
Мэдээжийн хэрэг, хост бүрийг оптик утсаар өөр өгөгдлийн төв рүү холбох шаардлагагүй, ямар ч порт эсвэл утас хүрэлцэхгүй. Эдгээр бүх холболтыг Ethernet 10G+ эсвэл FibreChannel 8G+ шилжүүлэгчээр дамжуулан хийх ёстой (FC нь зөвхөн IO-д зориулсан хостууд болон хадгалах системийг холбоход зориулагдсан, хуулбарлах суваг нь одоогоор зөвхөн IP (Ethernet 10G+)-ээр боломжтой.
Одоо сүлжээний топологийн талаар хэдэн үг хэлье. Чухал зүйл бол дэд сүлжээнүүдийн зөв тохиргоо юм. Дараах төрлийн траффикийн хэд хэдэн дэд сүлжээг нэн даруй тодорхойлох шаардлагатай.
- Хадгалах системүүдийн хооронд өгөгдөл синхрончлогдох хуулбарлах дэд сүлжээ. Тэдгээрийн хэд хэдэн байж болох юм, энэ тохиолдолд энэ нь хамаагүй, бүгд одоогийн (аль хэдийн хэрэгжсэн) сүлжээний топологиос хамаарна. Хэрэв тэдгээрийн хоёр нь байгаа бол тэдгээрийн хооронд чиглүүлэлт хийх нь ойлгомжтой;
- Хостууд хадгалах нөөцөд хандах хадгалах дэд сүлжээнүүд (хэрэв энэ нь iSCSI бол). Дата төв бүрт нэг ийм дэд сүлжээ байх ёстой;
- Дэд сүлжээг хянах, өөрөөр хэлбэл хадгалах системийг удирддаг гурван сайт дээрх чиглүүлэх боломжтой гурван дэд сүлжээ, мөн арбитр тэнд байрладаг.
Бид энд хостын нөөцөд хандах дэд сүлжээг авч үзэхгүй, учир нь тэдгээр нь даалгавараас ихээхэн хамааралтай байдаг.
Янз бүрийн траффикийг өөр өөр дэд сүлжээнд хуваах нь маш чухал (ялангуяа I/O-аас хуулбарыг салгах нь чухал), учир нь хэрэв та бүх траффикийг нэг "зузаан" дэд сүлжээнд холих юм бол энэ урсгалыг удирдах боломжгүй болно. Хоёр өгөгдлийн төвийн нөхцөл байдал энэ нь сүлжээний өөр өөр сонголтуудыг үүсгэж болно. Энэ нийтлэлийн хүрээнд бид энэ асуудлыг нарийвчлан судлахгүй, учир нь та сүлжээний тоног төхөөрөмж үйлдвэрлэгчдийн нөөцөөс мэдээллийн төвүүдийн хооронд сүлжээг төлөвлөх талаар уншиж болно, үүнд үүнийг нарийвчлан тайлбарласан болно.
Арбитрын тохиргоо
Арбитр нь ICMP болон SSH протоколоор дамжуулан хадгалалтын системийн удирдлагын бүх интерфэйсүүдэд нэвтрэх эрхийг хангах ёстой. Та мөн арбитрын аюулгүй байдлын талаар бодох хэрэгтэй. Энд нэг нюанс бий.
Арбитрын бүтэлгүйтлийг маш их хүсч байгаа боловч шаардлагагүй. Шүүгч буруу цагт осолдвол яах вэ?
- Метрокластерын хэвийн горимд ажиллах байдал өөрчлөгдөхгүй, учир нь arbtir нь метроны кластерын хэвийн горимд ажиллахад огт нөлөө үзүүлэхгүй (түүний даалгавар бол мэдээллийн төвүүдийн хоорондох ачааллыг цаг тухайд нь солих явдал юм)
- Түүгээр ч зогсохгүй арбитр ямар нэг шалтгаанаар унаад дата төвд осолдвол "унтсан" тохиолдолд солигдохгүй, учир нь шаардлагатай сэлгэх командыг өгч, чуулга зохион байгуулах хүн байхгүй болно. Энэ тохиолдолд метро кластер нь гамшгийн үед гараар солигдох ёстой бөгөөд энэ нь RTO-д нөлөөлнө.
Үүнээс юу гарах вэ? Хэрэв та хамгийн бага RTO-г баталгаажуулах шаардлагатай бол арбитрын алдааг тэсвэрлэх чадвартай эсэхийг шалгах хэрэгтэй. Үүнд хоёр сонголт байна:
- Гэмтлийг тэсвэрлэх чадвартай гипервизор дээр арбитр бүхий виртуал машин ажиллуул, аз болоход насанд хүрсэн бүх гипервизорууд алдааг тэсвэрлэх чадварыг дэмждэг;
- Хэрэв гуравдахь сайт дээр (ердийн оффис дээр) ердийн кластер суулгахаас залхуурсан бөгөөд одоо байгаа гипервозор кластер байхгүй бол бид 2U хайрцагт хийсэн арбитрын техник хангамжийн хувилбарыг өгсөн. x-86 серверүүд ажилладаг бөгөөд тэдгээр нь орон нутгийн доголдлыг даван туулж чаддаг.
Метрокластерт ердийн горимд хэрэггүй байсан ч бид арбитрын алдааг тэсвэрлэх чадварыг баталгаажуулахыг зөвлөж байна. Гэхдээ онол, практикийн аль аль нь харуулж байгаачлан хэрэв та үнэхээр найдвартай гамшигт тэсвэртэй дэд бүтцийг бий болгож чадвал түүнийг аюулгүй ашиглах нь дээр. Өөрийгөө болон бизнесээ "зохисгүй байдлын хууль" -аас, өөрөөр хэлбэл арбитрч болон хадгалах систем байрладаг сайтуудын аль нэгний бүтэлгүйтлээс хамгаалах нь дээр.
Шийдлийн архитектур
Дээрх шаардлагыг харгалзан бид дараах ерөнхий шийдлийн архитектурыг олж авна.
Хүчтэй хэт ачааллаас зайлсхийхийн тулд LUN-ийг хоёр талбайд жигд хуваарилах хэрэгтэй. Үүний зэрэгцээ, хоёр дата төвд хэмжээг тогтоохдоо та зөвхөн давхар эзлэхүүнийг (энэ нь хоёр хадгалах систем дээр нэгэн зэрэг хадгалахад шаардлагатай) төдийгүй IOPS болон MB/s-ийн давхар гүйцэтгэлийг багтаасан байх ёстой. өгөгдлийн төвүүдийн аль нэг нь эвдэрсэн тохиолдолд ov.
Хэмжээг зөв тогтоох арга барилаар (өөрөөр хэлбэл бид IOPS ба MB/s-ийн зохих дээд хязгаарыг, түүнчлэн шаардлагатай CPU болон RAM-ийн нөөцийг хангасан тохиолдолд) санах ойд хадгалалтын системүүдийн аль нэг нь Метроны кластер бүтэлгүйтсэн тохиолдолд нэг хадгалах систем дээр түр зуур ажиллах нөхцөлд гүйцэтгэлд ноцтой уналт гарахгүй.
Үүнийг хоёр сайт зэрэг ажиллуулах үед гүйлгээ бүрийг хоёр санах ойн системд (RAID-1/10-тай төстэй) бичих ёстой тул синхрон хуулбар нь бичих гүйцэтгэлийн талыг "иддэг" гэж тайлбарладаг. Тиймээс, хадгалалтын системүүдийн аль нэг нь бүтэлгүйтсэн тохиолдолд хуулбарлах нөлөө түр зуур алга болж, бичих чадвар хоёр дахин нэмэгддэг. Амжилтгүй хадгалалтын системийн LUN-уудыг ажиллаж байгаа санах ойн систем дээр дахин ажиллуулсны дараа нөгөө санах ойн системийн LUN-аас ачаалал гарч ирснээс болж энэ хоёр дахин нэмэгдэл алга болж, бид өмнө нь байсан гүйцэтгэлийн түвшинд буцаж ирдэг. "уналт", гэхдээ зөвхөн нэг сайтын хүрээнд.
Чадварлаг хэмжээсийн тусламжтайгаар та бүхэл бүтэн хадгалах системийн эвдрэлийг хэрэглэгчид мэдрэхгүй байх нөхцлийг хангаж чадна. Гэхдээ бид дахин нэг удаа давтан хэлэхэд энэ нь маш болгоомжтой хэмжээс шаарддаг бөгөөд дашрамд хэлэхэд та бидэнтэй үнэ төлбөргүй холбогдож болно :-).
Метро кластер байгуулах
Метрокластер байгуулах нь бидний тайлбарласан ердийн хуулбарыг тохируулахтай маш төстэй юм . Тиймээс зөвхөн ялгаан дээр анхаарлаа хандуулцгаая. Бид лабораторид дээрх архитектурын үндсэн дээр вандан сандал суурилуулсан бөгөөд зөвхөн хамгийн бага хувилбараар: 10G Ethernet-ээр холбогдсон хоёр хадгалах систем, хоёр 10G свич, 10G порттой хоёр санах ойн системд шилжүүлэгчээр хардаг нэг хост. Арбитр нь виртуал машин дээр ажилладаг.
Виртуал IP (VIP) хуулбарыг тохируулахдаа та VIP төрлийг сонгох хэрэгтэй - metrocluster.
Бид хоёр LUN-д зориулж хоёр хуулбарлах холбоос үүсгэж, тэдгээрийг хоёр санах ойн системд тараасан: LUN TEST Primary on storage system (METRO link), LUN TEST1 Primary for storage system 2 (METRO link), LUN TEST2 Primary (METRO2 link).
Тэдний хувьд бид хоёр ижил зорилтыг тохируулсан (манай тохиолдолд iSCSI, гэхдээ FC нь бас дэмжигддэг, тохиргооны логик нь адилхан).
Хадгалах систем1:
Хадгалах систем2:
Хуулбарлах холболтын хувьд хадгалах систем бүр дээр зураглал хийсэн.
Хадгалах систем1:
Хадгалах систем2:
Бид multipath тохируулж, хостод танилцуулсан.
Арбитрч байгуулах
Та арбитр өөрөө ямар нэгэн онцгой зүйл хийх шаардлагагүй; та үүнийг гурав дахь сайт дээр идэвхжүүлж, IP хаяг өгч, ICMP болон SSH-ээр дамжуулан хандахыг тохируулах хэрэгтэй. Тохируулга нь өөрөө хадгалах системээс хийгддэг. Энэ тохиолдолд арбитрыг метрокластерын аль ч хадгалалтын хянагч дээр нэг удаа тохируулахад хангалттай бөгөөд эдгээр тохиргоог бүх хянагчдад автоматаар түгээх болно.
Алсын хуулбар >> Metrocluster (ямар ч хянагч дээр)>> хэсэгт "Тохируулах" товчийг дарна уу.
Бид арбитрын IP хаяг, мөн хоёр алсын хадгалалтын хянагчийн хяналтын интерфейсийг оруулна.
Үүний дараа та бүх үйлчилгээг идэвхжүүлэх хэрэгтэй ("Бүхнийг дахин эхлүүлэх" товч). Хэрэв ирээдүйд дахин тохируулсан бол тохиргоо хүчин төгөлдөр болохын тулд үйлчилгээг дахин эхлүүлэх шаардлагатай.
Бид бүх үйлчилгээ ажиллаж байгаа эсэхийг шалгадаг.
Энэ нь метро кластерын тохиргоог дуусгана.
Сүйрлийн тест
Хуулбарлах функцийг (шилжүүлэх, тууштай байдал гэх мэт) авч үзсэн тул манай тохиолдолд сүйрлийн тест нь маш энгийн бөгөөд хурдан байх болно. . Тиймээс, метроны кластерийн найдвартай байдлыг шалгахын тулд алдаа илрүүлэх автоматжуулалт, сэлгэн залгалт, бичлэгийн алдагдал (оролтын гаралтын зогсолт) байхгүй эсэхийг шалгахад хангалттай.
Үүнийг хийхийн тулд бид аль нэг хадгалах системийн бүрэн доголдлыг дуурайж, хоёр хянагчийг нь унтрааж, эхлээд том файлыг нөгөө санах ойн систем дээр идэвхжүүлэх ёстой LUN руу хуулж эхэлсэн.
Нэг хадгалах системийг идэвхгүй болгох. Хоёрдахь хадгалалтын систем дээр бид хөрш системтэй холболт тасарсан тухай логууд дахь анхааруулга, мессежүүдийг хардаг. Хэрэв SMTP эсвэл SNMP хяналтаар дамжуулан мэдэгдлийг тохируулсан бол администратор холбогдох мэдэгдлийг хүлээн авах болно.
Яг 10 секундын дараа (дэлгэцийн хоёр зураг дээр харагдаж байна) METRO хуулбарлах холболт (амжилтгүй хадгалалтын систем дээр анхдагч байсан) автоматаар ажиллаж байгаа санах ойн систем дээр Анхдагч болсон. Одоо байгаа зураглалыг ашигласнаар LUN TEST нь хостод нээлттэй хэвээр байсан бөгөөд бичлэг бага зэрэг буурсан (амласан 10 хувьд), гэхдээ тасалдсангүй.
Туршилт амжилттай боллоо.
Дүгнэлт
AERODISK Engine N-цуврал хадгалах систем дэх метрокластерийн одоогийн хэрэгжилт нь мэдээллийн технологийн үйлчилгээний сул зогсолтыг арилгах, багасгах шаардлагатай тулгамдсан асуудлыг бүрэн шийдвэрлэх боломжийг олгож, 24/7/365 цагийн турш хамгийн бага хөдөлмөрийн зардлаар ажиллуулах боломжийг олгодог.
Мэдээжийн хэрэг, энэ бүхэн онол, лабораторийн хамгийн тохиромжтой нөхцөл гэх мэт зүйл гэж бид хэлж чадна ... ГЭВЧ бидэнд гамшигт тэсвэртэй функцийг хэрэгжүүлсэн хэд хэдэн хэрэгжсэн төслүүд байгаа бөгөөд системүүд нь төгс ажилладаг. Гамшигт тэсвэртэй тохиргоотой хоёрхон хадгалалтын системийг ашигладаг манай нэлээд алдартай үйлчлүүлэгчдийн нэг нь төслийн талаарх мэдээллийг нийтлэхээр тохиролцсон тул дараагийн хэсэгт байлдааны хэрэгжилтийн талаар ярих болно.
Баярлалаа, бид үр дүнтэй хэлэлцүүлгийг тэсэн ядан хүлээж байна.
Эх сурвалж: www.habr.com