Эй Хабр!
Жаңы жылдык майрамдардан кийин биз эки сайтка негизделген кырсыкка каршы булутту кайра ишке киргиздик. Бүгүн биз анын кантип иштээрин айтып беребиз жана кластердин айрым элементтери иштебей калганда жана бүт сайт бузулганда (спойлер – аларда баары жакшы) кардар виртуалдык машиналары эмне болорун көрсөтөбүз.
OST сайтында кырсыкка туруктуу булут сактоо системасы.
Ичинде эмне бар
Капоттун астында кластерде VMware ESXi гипервизору бар Cisco UCS серверлери, эки INFINIDAT InfiniBox F2240 сактоо тутумдары, Cisco Nexus тармактык жабдуулары, ошондой эле Brocade SAN өчүргүчтөрү бар. Кластер эки сайтка бөлүнгөн - OST жана NORD, башкача айтканда, ар бир маалымат борборунда окшош жабдуулардын топтому бар. Чындыгында, бул аны кырсыкка чыдамдуу кылат.
Бир сайттын ичинде негизги элементтер дагы кайталанат (хосттор, SAN которгучтары, тармактык).
Эки сайт атайын була-оптикалык каттамдар менен байланышкан, ошондой эле корголгон.
сактоо системалары жөнүндө бир нече сөз. Биз NetApp'та кырсыкка туруктуу булуттун биринчи версиясын курдук. Бул жерде биз INFINIDATти тандадык жана эмне үчүн:
- Active-Active репликация опциясы. Бул виртуалдык машинага сактоо тутумдарынын бири толугу менен иштен чыкса дагы иштей берет. Репликация жөнүндө кийинчерээк айтып берем.
- Системанын каталарына чыдамдуулугун жогорулатуу үчүн үч диск контроллери. Адатта эки бар.
- Даяр чечим. Биз жөн гана тармакка туташып, конфигурацияланышы керек болгон алдын ала чогултулган стеллажды алдык.
- Кылдат техникалык колдоо. INFINIDAT инженерлери сактоо тутумунун журналдарын жана окуяларын дайыма талдап, жаңы микропрограмма версияларын орнотуп, конфигурациялоого жардам беришет.
Бул жерде таңгактан чыгарылган сүрөттөр:
Бул кандайча иштейт
Булут өз ичинде буга чейин каталарга чыдамдуу. Бул кардарды жалгыз аппараттык жана программалык камсыздоонун бузулушунан коргойт. Кырсыкка туруштук берүү бир сайттын ичиндеги массалык бузулуулардан коргоого жардам берет: мисалы, сактоо тутумунун (же SDS кластери, бул көп кездешет 🙂), сактагыч тармагындагы массалык каталар ж.б. Эң негизгиси, мындай булут өрт, өчүрүү, рейдерлик басып алуу же келгиндердин конуусунан улам бүтүндөй сайт жеткиликсиз болуп калганда сактайт.
Бул бардык учурларда, кардар виртуалдык машиналар ишин улантууда, жана бул жерде эмне үчүн.
Кластердин дизайны кардар виртуалдык машиналары бар каалаган ESXi хосту эки сактоо тутумунун каалаганына кире алгыдай кылып иштелип чыккан. OST сайтындагы сактоо системасы иштебей калса, виртуалдык машиналар ишин уланта берет: алар иштеп жаткан хосттор маалыматтар үчүн NORDдагы сактоо тутумуна кире алышат.
Кластердеги байланыш диаграммасы ушундай көрүнөт.
Бул эки сайттын SAN кездемелеринин ортосунда Inter-Switch Link конфигурациялангандыктан мүмкүн болот: Fabric A OST SAN которуштуруусу Fabric A NORD SAN алмаштыргычына жана ушуга окшош эле Fabric B SAN өчүргүчтөрү үчүн.
Ооба, SAN заводдорунун бардык бул татаалдыктары түшүнүктүү болушу үчүн, Active-Active репликация эки сактоо тутумунун ортосунда конфигурацияланган: маалымат дээрлик бир убакта жергиликтүү жана алыскы сактоо тутумдарына жазылат, RPO = 0. Көрсө, баштапкы маалыматтар бир сактоо системасында сакталат, ал эми анын көчүрмөсү экинчисинде сакталат. Маалыматтар сактоо көлөмүнүн деңгээлинде репликацияланат, ал эми VM маалыматтары (анын дисктери, конфигурация файлы, своп файлы ж.б.) аларда сакталат.
ESXi хосту негизги көлөмдү жана анын репликасын бир диск түзмөгү (Сактагыч түзмөк) катары көрөт. ESXi хостунан ар бир диск түзүлүшүнө 24 жол бар:
12 жол аны жергиликтүү сактоо тутумуна (оптималдуу жолдор), ал эми калган 12си алыскы сактоо тутумуна (оптималдуу эмес жолдор) туташтырат. Кадимки кырдаалда, ESXi "оптималдуу" жолдорду колдонуу менен жергиликтүү сактоо тутумундагы маалыматтарга жетет. Бул сактоо системасы иштебей калганда, ESXi оптималдуу жолдорун жоготот жана "оптималдуу эместерге" өтөт. Бул диаграммада кандай көрүнөт.
Кырсыктан корголбогон кластердин схемасы.
Бардык кардар тармактары жалпы тармак ткани аркылуу эки сайтка туташтырылган. Ар бир сайт Провайдер Edge (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 секунд. Бул учурда, виртуалдык машинанын бардык тармак орнотуулары сакталат жана ал тармак аркылуу кардар үчүн жеткиликтүү бойдон калат.
Камдык сайтта машиналарды кайра иштетүү үзгүлтүксүз жүрүшүн камсыз кылуу үчүн, ар бир сайт жарымы гана толгон. Экинчи жарымы бардык виртуалдык машиналар экинчи бузулган сайттан көчүп кеткен учурда резерв болуп саналат.
Эки маалымат борборуна негизделген кырсыкка туруктуу булут мындай каталардан коргойт.
Бул ырахат арзан эмес, анткени, негизги ресурстардан тышкары, экинчи сайтта резерв керек. Ошондуктан, бизнес үчүн маанилүү кызматтар ушундай булуттун ичинде жайгаштырылат, анын узак мөөнөттүү токтоп калуусу чоң каржылык жана репутациялык жоготууларды алып келет, же маалымат тутуму жөнгө салуучу органдардын же компаниянын ички эрежелеринин кырсыкка туруктуулук талаптарына баш ийсе.
булагы:
Source: www.habr.com