Салам, Habr окурмандары! Бул макаланын темасы AERODISK Engine сактоо тутумдарында кырсыкты калыбына келтирүү куралдарын ишке ашыруу болот. Башында биз бир макалада эки курал жөнүндө жазгыбыз келди: репликация жана метрокластер, бирок, тилекке каршы, макала өтө узун болуп чыкты, ошондуктан макаланы эки бөлүккө бөлдүк. Жөнөкөйдөн татаалга карай кетели. Бул макалада биз синхрондуу репликацияны орнотуп, сынайбыз - биз бир маалымат борборун түшүрөбүз, ошондой эле маалымат борборлорунун ортосундагы байланыш каналын бузуп, эмне болорун көрөбүз.
Биздин кардарлар бизге копиялоо боюнча ар кандай суроолорду беришет, андыктан репликаларды орнотууга жана ишке ашырууну сыноого өтүүдөн мурун, биз сизге сактагычтагы репликация деген эмне экенин бир аз айтып беребиз.
теориясынын бир үзүм
Сактоо тутумдарындагы репликация - бул бир эле учурда бир нече сактоо тутумдарында маалыматтардын идентификациясын камсыз кылуунун үзгүлтүксүз процесси. Техникалык жактан репликация эки жол менен ишке ашат.
Синхрондуу репликация – бул маалыматтарды негизги сактоо тутумунан резервдик тутумга көчүрүү, андан кийин эки сактоо тутумунан маалыматтар жазылган жана тастыкталганын милдеттүү түрдө ырастоо. Бул эки тараптан (эки сактоо тутумунда) тастыкталгандан кийин маалыматтар жазылган деп эсептелет жана алар менен иштөөгө болот. Бул репликага катышкан бардык сактоо тутумдарында кепилденген маалыматтын идентификациясын камсыздайт.
Бул ыкманын артыкчылыктары:
- Маалыматтар бардык сактоо тутумдарында дайыма бирдей
жактары:
- Чечимдин кымбаттыгы (тез байланыш каналдары, кымбат оптикалык була, узун толкундуу кабыл алгычтар ж.б.)
- Аралык чектөөлөр (бир нече ондогон километрдин ичинде)
- Логикалык маалыматтардын бузулушунан эч кандай коргоо жок (эгерде маалыматтар негизги сактоо тутумунда бузулса (атайылап же кокустан), ал резервдик көчүрмөдө автоматтык түрдө жана заматта бузулуп калат, анткени маалыматтар ар дайым бирдей (бул парадокс)
Асинхрондук репликация – бул ошондой эле маалыматты негизги сактоо тутумунан резервдик тутумга көчүрүү, бирок белгилүү бир кечигүү менен жана экинчи тарапка жазууну ырастоонун зарылдыгы жок. Сиз маалымат менен аны негизги сактоо тутумуна жаздыргандан кийин дароо иштей аласыз жана резервдик сактоо тутумунда маалыматтар бир нече убакыттан кийин жеткиликтүү болот. Бул учурда маалыматтардын идентификациясы, албетте, таптакыр камсыз кылынбайт. Камдык сактоо тутумундагы маалыматтар ар дайым бир аз "өткөндө".
Асинхрондук репликациянын жакшы жактары:
- Төмөн наркы чечим (ар кандай байланыш каналдары, оптика кошумча)
- Аралык чектөөлөр жок
- Камдык сактоо тутумунда маалыматтар негизги тутумда бузулса (жок дегенде бир нече убакытка) бузулбайт; эгерде маалыматтар бузулуп калса, камдык сактоо тутумунда маалыматтардын бузулушун алдын алуу үчүн репликаны дайыма токтото аласыз.
жактары:
- Ар кандай маалымат борборлорундагы маалыматтар ар дайым бирдей эмес
Ошентип, репликация режимин тандоо бизнес максаттарына жараша болот. Эгер сиз үчүн резервдик маалымат борбору негизги маалымат борбору менен бирдей маалыматтарды камтыса (б.а. RPO = 0 үчүн бизнес талабы) сиз үчүн өтө маанилүү болсо, анда сиз накталай акчаны чыгарып, синхрондук чектөөлөргө туруштук беришиңиз керек болот. реплика. Ал эми маалымат абалындагы кечигүү алгылыктуу болсо же жөн эле акча жок болсо, анда сиз сөзсүз асинхрондук ыкманы колдонушуңуз керек.
Ошондой эле мындай режимди (тактап айтканда, топологияны) метрокластер катары өзүнчө бөлүп көрөлү. Метрокластер режиминде синхрондуу репликация колдонулат, бирок кадимки репликадан айырмаланып, метрокластер эки сактоо тутумуна тең активдүү режимде иштөөгө мүмкүндүк берет. Ошол. сизде активдүү жана күтүүчү маалымат борборлорунун ортосунда айырма жок. Тиркемелер физикалык жактан ар кандай маалымат борборлорунда жайгашкан эки сактоо тутуму менен бир убакта иштейт. Мындай топологиядагы авариялар учурунда токтоп калуулар өтө аз (RTO, көбүнчө мүнөт). Бул макалада биз метрокластерди ишке ашырууну карабайбыз, анткени бул абдан чоң жана сыйымдуу тема, андыктан анын уландысы катары ага өзүнчө, кийинки макаланы арнайбыз.
Ошондой эле, көбүнчө, биз сактоо тутумдарын колдонуу менен репликациялоо жөнүндө сөз кылганда, көптөгөн адамдарда акылга сыярлык суроо пайда болот: > “Көптөгөн тиркемелерде өздөрүнүн репликациялоо куралдары бар, эмне үчүн сактоо тутумдарында репликацияны колдонушат? Бул жакшыбы же жаманбы?
Бул жерде так жооп жок, андыктан бул жерде ҮЧҮН жана КАРШЫ аргументтер:
Сактагычты репликациялоо үчүн аргументтер:
- Чечимдин жөнөкөйлүгү. Бир курал менен сиз жүктүн түрүнө жана колдонмосуна карабастан, бүт маалымат топтомуңузду кайталай аласыз. Колдонмолордун көчүрмөсүн колдонсоңуз, ар бир тиркемени өзүнчө конфигурациялашыңыз керек болот. Эгерде алардын саны 2ден көп болсо, анда бул өтө көп эмгекти талап кылат жана кымбатка турат (тиркемени репликациялоо, адатта, ар бир тиркеме үчүн өзүнчө жана бекер эмес лицензияны талап кылат. Бирок бул тууралуу төмөндө).
- Сиз каалаган нерсени - каалаган тиркемени, каалаган маалыматты кайталай аласыз жана ал ар дайым ырааттуу болот. Көптөгөн (көпчүлүк) тиркемелерди репликациялоо мүмкүнчүлүгү жок, жана сактоо тутумундагы репликалар кырсыктардан коргоону камсыз кылуунун жалгыз жолу болуп саналат.
- Колдонмонун репликациялоо функциясы үчүн ашыкча төлөөнүн кереги жок. Эреже катары, бул сактоо тутумунун көчүрмөсү үчүн лицензиялар сыяктуу эле арзан эмес. Бирок сиз сактоо репликациясына лицензия үчүн бир жолу төлөшүңүз керек жана тиркеменин репликасына лицензия ар бир тиркеме үчүн өзүнчө сатып алынышы керек. Эгерде мындай тиркемелер көп болсо, анда ал бир тыйын турат жана сактоону репликациялоо үчүн лицензиялардын баасы океандагы тамчы болуп калат.
Сактагычтын репликациясына КАРШЫ аргументтер:
- Тиркемелер аркылуу реплика тиркемелердин өз көз карашынан караганда көбүрөөк функционалдуулукка ээ, тиркеме өз маалыматтарын жакшы билет (албетте), алар менен иштөө үчүн көбүрөөк мүмкүнчүлүктөр бар.
- Кээ бир тиркемелердин өндүрүүчүлөрү репликация үчүнчү тараптын куралдары менен аткарылса, алардын маалыматтарынын ырааттуулугуна кепилдик бербейт. *
* - талаштуу тезис. Мисалы, белгилүү СББ өндүрүүчүсү расмий түрдө өтө узак убакыт бою алардын ДББсын алардын каражаттарын колдонуу менен кадимкидей репликациялоого болот, ал эми репликациянын калган бөлүгү (анын ичинде сактоо тутумдары) "чыныгы эмес" деп жарыялап келет. Бирок бул андай эмес экенин турмуш көрсөттү. Кыязы (бирок бул так эмес) бул кардарларга көбүрөөк лицензия сатуу үчүн эң чынчыл аракет эмес.
Натыйжада, көпчүлүк учурларда, сактоо системасынан репликация жакшы, анткени Бул жөнөкөй жана арзаныраак вариант, бирок конкреттүү тиркеме функциялары талап кылынган татаал учурлар бар жана колдонмо деңгээлиндеги репликация менен иштөө зарыл.
Теория менен бүттү, эми практика
Биз репликаны лабораториябызда конфигурациялайбыз. Лабораториялык шарттарда биз эки маалымат борборуна окшоштурдук (чындыгында, эки жанаша стеллаждар ар кандай имараттарда болуп көрүнгөн). Стенд бири-бирине оптикалык кабелдер аркылуу туташтырылган эки Engine N2 сактоо тутумунан турат. Windows Server 2016 менен иштеген физикалык сервер 10 Гб Ethernet аркылуу эки сактоо тутумуна туташтырылган. Стенд абдан жөнөкөй, бирок бул маңызын өзгөртпөйт.
Схемалык түрдө ал төмөнкүдөй көрүнөт:
Логикалык жактан кайталоо төмөнкүдөй уюштурулат:
Эми бизде бар репликация функциясын карап көрөлү.
Эки режим колдоого алынат: асинхрондуу жана синхрондуу. Синхрондук режим дистанция жана байланыш каналы менен чектелгени логикалуу. Атап айтканда, синхрондуу режим физика жана 10 Гигабит Ethernet (же андан жогору) катары була колдонууну талап кылат.
Синхрондук репликациялоо үчүн колдоого алынган аралык 40 километрди түзөт, маалымат борборлорунун ортосундагы оптикалык каналдын кечигүү мааниси 2 миллисекундга чейин. Жалпысынан алганда, ал чоң кечигүү менен иштейт, бирок андан кийин жаздыруу учурунда катуу жайлоолор болот (бул да логикалуу), андыктан маалымат борборлорунун ортосунда синхрондук репликациялоону пландаштырып жатсаңыз, оптиканын сапатын жана кечигүүлөрдү текшеришиңиз керек.
Асинхрондук репликацияга коюлган талаптар анчалык деле олуттуу эмес. Тагыраак айтканда, алар такыр жок. Бардык иштеген Ethernet байланышы болот.
Азыркы учурда, AERODISK ENGINE сактоо системасы Ethernet протоколу (жез же оптикалык) аркылуу блоктук түзүлүштөрдү (LUNs) репликациялоону колдойт. Fiber Channel аркылуу SAN ткани аркылуу репликация талап кылынган долбоорлор үчүн учурда биз тиешелүү чечимди кошуп жатабыз, бирок ал азырынча даяр эмес, ошондуктан биздин учурда бир гана Ethernet.
Репликация ар кандай ENGINE сериясындагы сактоо тутумдарынын (N1, N2, N4) ортосунда кенже системалардан эскилерине жана тескерисинче иштей алат.
Эки репликация режиминин функциялары толугу менен окшош. Төмөндө эмне бар экендиги жөнүндө көбүрөөк маалымат:
- Репликация "бирден бирге" же "бирден бирге", башкача айтканда, эки маалымат борбору бар классикалык версия, негизги жана резервдик
- Репликация "бирден көпкө" же "бирден көпкө", б.а. бир LUN бир эле учурда бир нече сактоо тутумдарына кайталанышы мүмкүн
- Репликацияны иштетүү, өчүрүү же репликациянын багытын өзгөртүү үчүн тиешелүүлүгүнө жараша репликацияны жандыруу, өчүрүү жана "кайтарым"
- Репликация RDG (Raid Distributed Group) жана DDP (Dynamic Disk Pool) бассейндеринде да жеткиликтүү. Бирок, РДГ бассейнинин LUNдары башка RDGге гана кайталанышы мүмкүн. Ошол эле DDP менен.
Дагы көптөгөн майда функциялар бар, бирок аларды тизмектештирүүнүн өзгөчө мааниси жок, биз аларды жөндөп жатканда айтабыз.
Репликацияны орнотуу
Орнотуу процесси абдан жөнөкөй жана үч этаптан турат.
- тармак Тарам
- Сактагычты орнотуу
- Эрежелерди (байланыштарды) орнотуу жана картага түшүрүү
Репликацияны орнотууда маанилүү жагдай, биринчи эки этап алыскы сактоо тутумунда кайталанышы керек, үчүнчү этап - негизгисинде гана.
Тармак ресурстарын орнотуу
Биринчи кадам - репликация трафиги өткөрүлө турган тармак портторун конфигурациялоо. Бул үчүн, сиз портторду иштетип, алардын IP даректерин Front-end адаптерлери бөлүмүндө коюшуңуз керек.
Андан кийин, биз бассейнди (биздин учурда RDG) жана репликациялоо үчүн виртуалдык IP (VIP) түзүшүбүз керек. VIP - бул сактагыч контроллердин эки "физикалык" даректерине (биз жаңы конфигурациялаган порттор) байланган калкып жүрүүчү IP дареги. Бул негизги репликация интерфейси болот. Сиз ошондой эле VIP менен эмес, VLAN менен иштей аласыз, эгер сизге тегтелген трафик менен иштөө керек болсо.
Реплика үчүн VIP түзүү процесси I/O (NFS, SMB, iSCSI) үчүн VIP түзүүдөн анча деле айырмаланбайт. Бул учурда, биз кадимки VIP түзөбүз (VLANсыз), бирок ал репликация үчүн экенин унутпаңыз (бул көрсөткүчсүз биз кийинки кадамда эрежеге VIP кошо албайбыз).
VIP ал калкып турган IP порттору менен бир ички тармакта болушу керек.
Биз бул орнотууларды алыскы сактоо тутумунда, албетте, башка IP менен кайталайбыз.
Ар кандай сактоо тутумдарынын VIP'тери ар кандай субсеттерде болушу мүмкүн, эң негизгиси алардын ортосунда маршруттук бар. Биздин учурда, бул мисал так көрсөтүлгөн (192.168.3.XX жана 192.168.2.XX)
Бул тармак бөлүгүн даярдоону аяктайт.
Сактагыч орнотулууда
Репликация үчүн сактагычты орнотуу адаттагыдан айырмаланып турат, биз картаны "Репликация картасы" атайын менюсу аркылуу жасайбыз. Болбосо, баары кадимки орнотуу менен бирдей болот. Эми, ирети менен.
Мурда түзүлгөн бассейн R02, сиз LUN түзүү керек. Аны жаратып, ЛУН1 деп атайлы.
Биз ошондой эле бирдей өлчөмдөгү алыскы сактоо тутумунда бир эле LUN түзүшүбүз керек. Биз түзөбүз. Чаташтырбоо учун алыскы ЛУН ЛУН1Р деп аталы
Эгер биз буга чейин бар LUNди алышыбыз керек болсо, анда репликаны орнотууда, биз бул жемиштүү LUNди хосттон ажыратып, алыскы сактоо тутумунда бирдей өлчөмдөгү бош LUN түзүшүбүз керек.
Сактагыч орнотуу аяктады, келгиле, репликация эрежесин түзүүгө өтөлү.
Репликация эрежелерин же репликация шилтемелерин орнотуу
Учурда негизги боло турган сактоо тутумунда LUN түзгөндөн кийин, биз 1 сактоо тутумунда LUN1 репликация эрежесин 1 сактоо тутумунда LUN2R менен конфигурациялайбыз.
Орнотуу "Алыскы репликация" менюсунда жасалган
Келгиле, эреже түзөлү. Бул үчүн, сиз репликаны алуучуну көрсөтүшүңүз керек. Ал жерден биз байланыштын атын жана репликациянын түрүн (синхрондуу же асинхрондуу) орнотобуз.
"Алыскы системалар" талаасында биз сактагыч системабызды кошобуз2. Кошумча кылуу үчүн сиз башкаруунун IP сактагыч системаларын (MGR) жана биз репликация жасай турган алыскы LUN атын колдонушуңуз керек (биздин учурда, LUN1R). Контролдук IP байланышты кошуу стадиясында гана керек, алар аркылуу репликация трафиги өткөрүлбөйт, бул үчүн мурда конфигурацияланган VIP колдонулат.
Бул этапта биз "бирден көпкө" топологиясы үчүн бирден ашык алыскы системаны кошо алабыз: төмөндөгү сүрөттөгүдөй "түйүн кошуу" баскычын басыңыз.
Биздин учурда бир гана алыскы система бар, ошондуктан биз муну менен чектелебиз.
Эреже даяр. Көңүл буруңуз, ал бардык репликация катышуучуларына автоматтык түрдө кошулат (биздин учурда алардын экөөсү бар). Сиз каалаган сандагы LUN үчүн жана каалаган багытта каалагандай көп эрежелерди түзө аласыз. Мисалы, жүктү тең салмактоо үчүн, биз LUNдардын бир бөлүгүн 1-сактоо тутумунан 2-сактоо тутумуна, ал эми экинчи бөлүгүн, тескерисинче, 2-сактоо тутумунан 1-сактоо тутумуна көчүрө алабыз.
Сактоо системасы 1. Түзүлгөндөн кийин дароо синхрондоштуруу башталды.
Сактоо системасы 2. Биз ошол эле эрежени көрүп жатабыз, бирок синхрондоштуруу буга чейин эле аяктаган.
1-сактоо тутумундагы LUN1 Негизги ролдо, башкача айтканда, активдүү. 1-сактоо тутумундагы LUN2R Экинчилик ролунда, башкача айтканда, 1-сактоо системасы иштебей калган учурда күтүү режиминде болот.
Эми биз LUNды хостко туташтыра алабыз.
Биз iSCSI аркылуу туташабыз, бирок аны FC аркылуу да жасаса болот. Репликада iSCSI LUN аркылуу карта түзүүнү орнотуу кадимки сценарийден дээрлик айырмаланбайт, андыктан биз бул жерде майда-чүйдөсүнө чейин карап отурбайбыз. Эгер бир нерсе болсо, бул процесс макалада сүрөттөлөт "«.
Бир гана айырмасы, биз картаны "Репликация картасы" менюсунда түзөбүз
Биз картаны орнотуп, LUNды хостко бердик. Алып баруучу ЛУНду көрдү.
Биз аны жергиликтүү файл тутумуна форматтадык.
Болду, орнотуу аяктады. Кийинки тесттер келет.
тестирлөө
Биз үч негизги сценарийди сынап көрөбүз.
- Үзгүлтүксүз ролду алмаштыруу Экинчилик > Негизги. Рөлдү үзгүлтүксүз алмаштыруу зарыл болгон учурда, мисалы, биз негизги маалымат борборунда кандайдыр бир алдын алуу операцияларын жасашыбыз керек жана ушул убакыттын ичинде маалыматтар жеткиликтүү болушу үчүн, жүктү резервдик маалымат борборуна өткөрүп беребиз.
- Шашылыш ролду алмаштыруу Экинчилик > Негизги (маалымат борборунун иштебей калышы). Бул репликациянын негизги сценарийи, ал компанияны узак мөөнөткө токтотпостон толук маалымат борборунун иштен чыгышына жардам берет.
- Маалымат борборлорунун ортосундагы байланыш каналдарынын бузулушу. Кандайдыр бир себептерден улам маалымат борборлорунун ортосундагы байланыш каналы иштебей калган шарттарда эки сактоо тутумунун туура жүрүм-турумун текшерүү (мисалы, экскаватор туура эмес жерде казылып, караңгы оптиканы сындырган).
Биринчиден, биз LUNга маалыматтарды жаза баштайбыз (кокус маалыматтар менен файлдарды жазуу). Биз дароо сактоо системалары ортосундагы байланыш каналы колдонулуп жатканын көрөбүз. Эгерде сиз репликациялоо үчүн жооптуу болгон порттордун жүгүн көзөмөлдөөнү ачсаңыз, муну түшүнүү оңой.
Эки сактоо тутумунда азыр "пайдалуу" маалыматтар бар, биз тестти баштасак болот.
Болбосо, келгиле, файлдардын биринин хэш суммаларын карап, аларды жазып алалы.
Дайыма ролду алмаштыруу
Ролдорду алмаштыруу операциясы (репликациянын багытын өзгөртүү) каалаган сактагыч тутуму менен аткарылышы мүмкүн, бирок сиз баары бир экөөнө тең барышыңыз керек, анткени сиз Негизгиде карта түзүүнү өчүрүп, аны Экинчиде иштетишиңиз керек (ал Негизги болуп калат) ).
Балким, азыр акылга сыярлык суроо туулат: эмне үчүн муну автоматташтырбаш керек? Жооп: бул жөнөкөй, репликация – бул табигый кырсыкка туруктуулуктун жөнөкөй каражаты, кол менен жасалган операцияларга негизделген. Бул операцияларды автоматташтыруу үчүн метрокластер режими бар, ал толугу менен автоматташтырылган, бирок анын конфигурациясы алда канча татаал. Метрокластер түзүү тууралуу кийинки макалада жазабыз.
Негизги сактоо тутумунда жаздыруу токтоп калбасын камсыз кылуу үчүн карта түзүүнү өчүрөбүз.
Андан кийин сактоо тутумдарынын биринде (негизги же камдык көчүрмөдө маанилүү эмес) "Алыскы репликация" менюсунан биздин REPL1 байланышын тандап, "Ролду өзгөртүү" баскычын чыкылдатыңыз.
Бир нече секунддан кийин, LUN1R (камдык сактоо системасы) Негизги болуп калат.
Биз сактагыч системасы1 менен LUN2R картасын.
Ушундан кийин биздин E: диски автоматтык түрдө хостко тиркелет, бул жолу гана ал ЛУН1Рден «келип».
Болгону, биз хэш суммаларын салыштырабыз.
Identically. Сыноо өттү.
Иштебей калуу. Маалымат борборунун катасы
Азыркы учурда, үзгүлтүксүз өтүү кийин негизги сактоо системасы тиешелүүлүгүнө жараша сактоо системасы 2 жана LUN1R болуп саналат. Кырсыкты туураш үчүн, сактагыч контроллерлорунун кубатын өчүрөбүз2.
Ага мындан ары мүмкүнчүлүк жок.
1-сактоо тутумунда эмне болуп жатканын карап көрөлү (учурда камдык көчүрмө).
Биз Негизги LUN (LUN1R) жеткиликсиз экенин көрүп жатабыз. Ката кабары журналдарда, маалымат панелинде, ошондой эле репликация эрежесинин өзүндө пайда болду. Демек, хосттон алынган маалыматтар учурда жеткиликтүү эмес.
LUN1 ролун Негизгиге өзгөртүңүз.
Мен хостко карта түзүп жатам.
Хостта E диски пайда болгонун текшериңиз.
Биз хэшти текшеребиз.
Баары жайында. Сактоо системасы активдүү болгон маалымат борборунун кулашынан ийгиликтүү өттү. Биз репликацияны "кайтарылууну" туташтырууга жана камдык маалымат борборунан LUNди туташтырууга болжолдуу убакыт 3 мүнөттөй болду. Чыныгы өндүрүштө баары алда канча татаал экени түшүнүктүү, жана сактоо тутумдары менен болгон аракеттерден тышкары, тармакта, хосттордо, тиркемелерде дагы көптөгөн операцияларды жасоо керек. Ал эми жашоодо бул убакыт бир топ узагыраак болот.
Бул жерде мен бардыгы, тест ийгиликтүү аяктады деп жазгым келет, бирок шашылбайлы. Негизги сактоо системасы "калп" болуп саналат, биз ал "жыгылганда" Негизги ролдо болгонун билебиз. Эгер күтүлбөгөн жерден күйүп калса эмне болот? Маалыматтын бузулушуна барабар болгон эки Негизги ролу болот? Келгиле, азыр текшерип көрөлү.
Келгиле, күтүлбөгөн жерден негизги сактоо тутумун күйгүзөлү.
Ал бир нече мүнөткө жүктөлөт, андан кийин кыска синхрондоштуруудан кийин кызматка кайтып келет, бирок экинчилик ролунда.
Баары жакшы. Бөлүнгөн мээ болгон жок. Биз бул жөнүндө ойлонгонбуз жана ар дайым кулагандан кийин сактоо тутуму "турмуш учурунда" кандай роль ойногонуна карабастан, экинчиликтин ролуна көтөрүлөт. Азыр биз маалымат борборунун ката сыноо ийгиликтүү болду деп так айта алабыз.
Маалымат борборлорунун ортосундагы байланыш каналдарынын иштебей калышы
Бул тесттин негизги милдети сактоо системасы эки сактоо тутумунун ортосундагы байланыш каналдарын убактылуу жоготуп, анан кайра пайда болуп калса, кызыктай иштей баштабасын текшерүү.
Ошентип. Сактоочу системалардын ортосундагы зымдарды ажыратабыз (келгиле, аларды экскаватор казган деп элестетели).
Башталгычта биз Орто менен эч кандай байланыш жок экенин көрөбүз.
Ортодо биз Баштапкы менен эч кандай байланыш жок экенин көрөбүз.
Баары жакшы иштейт жана биз маалыматтарды негизги сактоо тутумуна жазууну улантып жатабыз, башкача айтканда, алар резервдик көчүрмөдөн айырмаланат, башкача айтканда, алар "бөлүштү".
Бир нече мүнөттөн кийин биз байланыш каналын "оңдойбуз". Сактоо тутумдары бири-бирин көргөндө, маалыматтарды синхрондоштуруу автоматтык түрдө ишке киргизилет. Бул жерде администратордон эч нерсе талап кылынбайт.
Бир нече убакыт өткөндөн кийин, синхрондоштуруу аяктайт.
Байланыш калыбына келтирилди, байланыш каналдарынын жоголушу авариялык кырдаалды пайда кылган жок жана күйгүзүлгөндөн кийин синхрондоштуруу автоматтык түрдө ишке ашты.
табылгалары
Биз теорияны талдап көрдүк - эмне керек жана эмне үчүн, жакшы жактары кайда жана терс жактары кайда. Андан кийин биз эки сактоо тутумунун ортосунда синхрондуу репликацияны орноттук.
Андан кийин, кадимки коммутация, маалымат борборунун иштебей калышы жана байланыш каналынын бузулушу үчүн негизги тесттер жүргүзүлдү. Бардык учурларда, сактоо системасы жакшы иштеген. Дайындардын жоголушу жок жана административдик операциялар кол сценарийи үчүн минималдуу деңгээлде сакталат.
Кийинки жолу биз кырдаалды татаалдаштырабыз жана бул логиканын бардыгы автоматташтырылган метрокластерде активдүү-активдүү режимде, башкача айтканда, эки сактоо тутуму тең негизги болгондо жана сактоо тутуму бузулган учурда жүрүм-турум толугу менен автоматташтырылганда кантип иштээрин көрсөтөбүз.
Комментарий жазыңыз, биз туура сын жана практикалык кеңештерди алууга кубанычта болобуз.
Көрүшкөнчө.
Source: www.habr.com