Салам, Habr окурмандары! Акыркы макалада биз AERODISK ENGINE сактоо тутумдарында кырсыкты калыбына келтирүүнүн жөнөкөй каражаты - репликация жөнүндө сүйлөштүк. Бул макалада биз бир кыйла татаал жана кызыктуу темага - метрокластерге, башкача айтканда, эки маалымат борборлору үчүн автоматташтырылган кырсыктан коргоо каражаты, маалымат борборлоруна активдүү-активдүү режимде иштөөгө мүмкүндүк берет. Биз сага айтабыз, көрсөтөбүз, бузуп, оңдойбуз.
Адаттагыдай эле, биринчи теория
Метрокластер - бул шаардын же аймактагы бир нече сайттарга таралган кластер. "Кластер" деген сөз бизге комплекстин автоматташтырылганын, башкача айтканда, кластердик түйүндөр бузулганда автоматтык түрдө ишке ашарын көрсөтүп турат.
Метрокластер менен кадимки репликациянын негизги айырмасы мына ушунда. Операцияларды автоматташтыруу. Башкача айтканда, белгилүү бир инциденттер болгон учурда (маалымат борборунун иштебей калышы, бузулган каналдар ж.б.) сактоо системасы маалыматтардын жеткиликтүүлүгүн сактап калуу үчүн зарыл болгон аракеттерди өз алдынча аткарат. Кадимки репликаларды колдонууда, бул аракеттер администратор тарабынан толугу менен же жарым-жартылай кол менен аткарылат.
ал эмне кылат?
Кээ бир метрокластердик ишке ашырууларды колдонууда кардарлар көздөгөн негизги максат RTO (калыбына келтирүү убактысынын максаты) минималдаштыруу болуп саналат. Башкача айтканда, бузулгандан кийин IT кызматтарынын калыбына келтирүү убактысын азайтуу. Эгер сиз үзгүлтүксүз репликацияны колдонсоңуз, калыбына келтирүү убактысы ар дайым метрокластер менен калыбына келтирүү убактысынан узак болот. Неге? Өтө жөнөкөй. Администратор өзүнүн столунда болушу керек жана репликацияны кол менен алмаштырышы керек, ал эми метро кластер муну автоматтык түрдө аткарат.
Эгер сизде уктабаган, тамак ичпеген, тамеки тартпаган же ооруп, 24 саат бою сактоо тутумунун абалын карап турган атайын администраторуңуз жок болсо, анда администратордун эч кандай кепилдик бере албайт. катачылык учурунда кол менен которуштуруу үчүн жеткиликтүү.
Демек, RTO администратордун нөөмөт кызматынын 99-деңгээлинин метрокластери же өлбөс администратору жок болгон учурда бардык системалардын которуштуруу убактысынын суммасына жана администратордун иштөөсүнө кепилдик берилген убакыттын максималдуу мезгилине барабар болот. сактоо системалары жана тиешелүү системалар менен.
Ошентип, биз ачык-айкын корутундуга келдик, эгерде RTO үчүн талап саат же күн эмес, мүнөттөр болсо, метрокластер колдонулушу керек, башкача айтканда, маалымат борбору эң начар иштебей калган учурда, IT бөлүмү бизнести убакыт менен камсыз кылышы керек. IT-кызматтарга кирүү мүмкүнчүлүгүн бир нече мүнөттүн ичинде, ал тургай секунданын ичинде калыбына келтирүү.
Бул кандай иштейт?
Төмөнкү деңгээлде, метрокластер маалыматтарды синхрондуу репликациялоо механизмин колдонот, аны биз мурунку макалада сүрөттөгөн (кара. ). Репликация синхрондуу болгондуктан, ага коюлган талаптар дал келет, тагыраак айтканда:
- физика катары оптикалык була, 10 гигабит Ethernet (же андан жогору);
- маалымат борборлорунун ортосундагы аралык 40 километрден ашпайт;
- маалымат борборлорунун ортосундагы оптикалык канал кечигүү (сактоо системалары ортосунда) 5 миллисекундга чейин (оптималдуу 2).
Бул талаптардын бардыгы кеңеш берүүчү мүнөзгө ээ, башкача айтканда, бул талаптар аткарылбаса да метрокластер иштейт, бирок биз бул талаптарды аткарбоо кесепеттери эки сактоо тутумунун тең иштешинин басаңдашына барабар экенин түшүнүшүбүз керек. метрокластер.
Ошентип, синхрондук реплика маалыматтарды сактоо тутумдарынын ортосунда өткөрүп берүү үчүн колдонулат жана репликалар кантип автоматтык түрдө которулат жана эң негизгиси, мээнин бөлүнүүсүнөн кантип сактануу керек? Бул үчүн, жогорку деңгээлде, кошумча субъект - арбитр колдонулат.
Арбитр кандай иштейт жана анын милдети кандай?
Арбитр – бул кичинекей виртуалдык машина же аппараттык кластер, ал үчүнчү сайтта (мисалы, кеңседе) ишке киргизилиши керек жана ICMP жана SSH аркылуу сактоо тутумуна кирүүнү камсыз кылат. Ишке киргизгенден кийин, арбитр IPди коюп, андан кийин сактагыч тараптан анын дарегин, ошондой эле метрокластерге катышкан дистанциялык контроллердин даректерин көрсөтүүсү керек. Андан кийин калыс иштөөгө даяр.
Арбитр арбитр метрокластердеги бардык сактоо тутумдарын такай көзөмөлдөп турат жана эгерде белгилүү бир сактоо тутуму жок болсо, кластердин башка мүчөсүнүн ("тирүү" сактоо тутумдарынын бири) жоктугун ырастагандан кийин, ал репликация эрежелерин алмаштыруу процедурасын баштоону чечет. жана картага түшүрүү.
Абдан маанилүү пункт. Арбитр ар дайым сактоо тутумдары жайгашкан жерден башка сайтта болушу керек, башкача айтканда, 1-сактоо тутуму орнотулган маалымат борборунда да, 1-сактоо тутуму орнотулган маалымат борборунда да эмес.
Неге? Анткени бул арбитр сакталып калган сактоо тутумдарынын биринин жардамы менен сактоо тутумдары орнотулган эки сайттын кайсы биринин кулашын так жана так аныктай алат. Арбитрди коюунун башка ыкмалары мээнин бөлүнүшүнө алып келиши мүмкүн.
Эми арбитрдин ишинин майда-чүйдөсүнө чейин тереңдеп кетели.
Арбитр бардык сактоо контроллерлорун дайыма сурамжылоочу бир нече кызматтарды иштетет. Эгерде сурамжылоонун натыйжасы мурункудан айырмаланса (жеткиликтүү/жеткиликсиз), анда ал арбитрде да иштеген кичинекей маалымат базасына жазылат.
Келгиле, арбитрдин ишинин логикасын кененирээк карап көрөлү.
1-кадам: Жеткиликсиздигин аныктоо. Сактоо тутумунун бузулуу окуясы - 5 секунддун ичинде бир эле сактоо тутумунун эки контролеринен тең пингдин жоктугу.
Кадам 2. Которуу процедурасын баштаңыз. Арбитр сактоо тутумдарынын бири жок экенин түшүнгөндөн кийин, ал "жандуу" сактоо тутумунун чындап эле өлүп калганына ынануу үчүн "тирүү" сактоо тутумуна суроо-талап жөнөтөт.
Арбитрден мындай буйрукту алгандан кийин, экинчи (тирүү) сактоо тутуму кулаган биринчи сактоо тутумунун болушун кошумча текшерет жана эгерде ал жок болсо, арбитрге өзүнүн божомолун ырастоосун жөнөтөт. Сактоо системасы чындап эле жеткиликтүү эмес.
Мындай ырастоону алгандан кийин, арбитр репликацияны которуунун жана түшүрүлгөн сактоо тутумунда активдүү (негизги) болгон репликалар боюнча карта түзүүнү жогорулатуунун алыскы процедурасын ишке киргизет жана экинчи сактоо тутумуна бул репликаларды экинчиликтен негизгиге өзгөртүү буйругун жөнөтөт. картаны көтөрүү. Ооба, экинчи сактоо системасы, ылайык, бул жол-жоболорду жүзөгө ашырат, андан кийин өзүнөн жоголгон LUNs мүмкүндүк берет.
Эмне үчүн кошумча текшерүү керек? Кворум үчүн. Башкача айтканда, кластер мүчөлөрүнүн жалпы так (3) санынын көпчүлүгү кластер түйүндөрүнүн биринин кулашын ырасташы керек. Ошондо гана бул чечим сөзсүз туура болот. Бул туура эмес которууну жана, демек, мээнин бөлүнүүсүнө жол бербөө үчүн зарыл.
Убакыт 2-кадам болжол менен 5 - 10 секундду талап кылат, ошентип, жеткиликсиздикти аныктоо үчүн талап кылынган убакытты (5 секунд) эске алуу менен, кырсыктан кийин 10 - 15 секунданын ичинде, кулап калган сактоо тутумунун LUN'лары тирүү менен иштөө үчүн автоматтык түрдө жеткиликтүү болот. сактоо системасы.
Хосттор менен байланышты жоготуп албаш үчүн, сиз да хосттордогу тайм-ауттарды туура конфигурациялоого кам көрүшүңүз керек экени түшүнүктүү. Сунушталган таймаут кеминде 30 секунд. Бул кырсык болгон учурда жүктү которуу учурунда хосттун сактоо тутумуна байланышын үзүүсүнө жол бербейт жана киргизүү/чыгаруу үзгүлтүксүздүгүн камсыздай алат.
Бир аз күтө туруңуз, эгер метрокластерде баары жакшы болсо, эмне үчүн бизге үзгүлтүксүз репликация керек?
Чындыгында, баары ушунчалык жөнөкөй эмес.
Метрокластердин жакшы жана жаман жактарын карап көрөлү
Ошентип, биз кадимки репликацияга салыштырмалуу метрокластердин айкын артыкчылыктары экенин түшүндүк:
- Толук автоматташтыруу, кырсык болгон учурда калыбына келтирүүнүн минималдуу убактысын камсыз кылуу;
- Болду :-).
Ал эми азыр, көңүл буруу, кемчиликтери:
- Чечимдин баасы. Aerodisk системаларындагы метрокластер кошумча лицензиялоону талап кылбаса да (ошондой эле лицензия реплика үчүн колдонулат), чечимдин баасы дагы эле синхрондуу репликацияны колдонуудан да жогору болот. Сиз синхрондуу репликага карата бардык талаптарды, ошондой эле кошумча коммутация жана кошумча сайт менен байланышкан метрокластерге талаптарды ишке ашырууңуз керек (метрокластерди пландаштырууну караңыз);
- Чечимдин татаалдыгы. Метрокластер кадимки репликага караганда алда канча татаал жана пландоо, конфигурациялоо жана документтештирүү үчүн көбүрөөк көңүл бурууну жана күч-аракетти талап кылат.
Жыйынтыгында. Metrocluster, албетте, абдан технологиялык өнүккөн жана жакшы чечим болуп саналат, сиз чындап эле секунда же мүнөт ичинде RTO камсыз кылуу керек болгондо. Бирок, эгерде андай тапшырма жок болсо жана сааттарда RTO бизнес үчүн жарайт, анда замбиректен таранчыларды атуудан эч кандай пайда жок. Кадимки жумушчу-дыйкан репликациясы жетиштүү, анткени метро кластери кошумча чыгымдарды жана IT инфраструктурасын татаалдантат.
Метро кластердик пландоо
Бул бөлүм метрокластерди долбоорлоо боюнча комплекстүү колдонмо болуп саналат деп ырастабайт, бирок, эгерде сиз ушундай системаны курууну чечсеңиз, иштелип чыгууга тийиш болгон негизги багыттарды гана көрсөтөт. Ошондуктан, иш жүзүндө метрокластерди ишке ашырууда, консультациялар үчүн сактоо тутумунун өндүрүүчүсүн (башкача айтканда, биз) жана башка тиешелүү системаларды тартууну унутпаңыз.
Орундар
Жогоруда айтылгандай, метрокластер үч сайтты талап кылат. Сактоо тутумдары жана ага тиешелүү системалар иштей турган эки маалымат борборлору, ошондой эле арбитр иштей турган үчүнчү сайт.
Маалымат борборлорунун ортосундагы сунушталган аралык 40 километрден ашпайт. Чоңураак аралык кошумча кечигүүлөрдү жаратышы мүмкүн, бул метрокластер үчүн өтө жагымсыз. Эскерте кетсек, кечигүү 5 миллисекундга чейин болушу керек, бирок аларды 2 ичинде сактоо сунушталат.
Пландоо процессинде да кечиктирүүнү текшерүү сунушталат. Маалымат борборлорунун ортосундагы оптикалык була менен камсыз кылган ар кандай аздыр-көптүр жетилген провайдер сапатты текшерүүнү тез уюштура алат.
Арбитрге (башкача айтканда, үчүнчү сайт менен биринчи экөөнүн ортосундагы) кечигүүлөргө келсек, сунушталган кечигүү босогосу 200 миллисекундга чейин, башкача айтканда, Интернет аркылуу үзгүлтүксүз корпоративдик VPN байланышы ылайыктуу.
Switching жана Networking
Репликациялоо схемасынан айырмаланып, бул жерде ар кандай сайттардан сактоо тутумдарын туташтыруу жетиштүү, метрокластер схемасы хостторду ар кайсы сайттардагы эки сактоо тутуму менен бириктирүүнү талап кылат. Айырмачылык эмне экенин айкыныраак кылуу үчүн, эки схема тең төмөндө көрсөтүлгөн.
Диаграммадан көрүнүп тургандай, биздин сайттын 1 хосттору 1 сактоо тутумун да, 2 сактоо тутумун да карашат. Башкача айтканда, ар бир хост эки сактоо тутумун көрөт. Бул метрокластердин иштешинин шарты болуп саналат.
Албетте, ар бир хостту оптикалык шнур менен башка маалымат борборуна туташтыруунун кереги жок, порт же шнур жетишсиз. Бул туташуулардын баары Ethernet 10G+ же FibreChannel 8G+ өчүргүчтөрү аркылуу жүргүзүлүшү керек (FC хостторду жана IO үчүн сактоо тутумдарын туташтыруу үчүн гана, репликация каналы учурда IP (Ethernet 10G+) аркылуу гана жеткиликтүү.
Азыр тармак топологиясы жөнүндө бир нече сөз. Маанилүү жагдай - субсеттердин туура конфигурациясы. Трафиктин төмөнкү түрлөрү үчүн дароо бир нече субсеттерди аныктоо зарыл:
- Маалыматтарды сактоо тутумдары ортосунда синхрондоштуруучу репликациянын ички тармагы. Алардын бир нечеси болушу мүмкүн, бул учурда эч кандай мааниге ээ эмес, бардыгы учурдагы (учурда ишке ашырылган) тармак топологиясынан көз каранды. Эгерде алардын экөөсү бар болсо, анда алардын ортосунда маршрутизация конфигурацияланышы керек;
- Хосттар сактоо ресурстарына кире турган сактагычтын ички тармактары (эгерде ал iSCSI болсо). Ар бир маалымат борборунда ушундай бир субтор болушу керек;
- Контролдоочу субторлор, башкача айтканда, сактоо тутумдары башкарылуучу үч сайттагы үч маршруттук тармак жана арбитр да ошол жерде жайгашкан.
Бул жерде хост ресурстарына кирүү үчүн субторлорду карабайбыз, анткени алар тапшырмалардан көз каранды.
Ар кандай трафикти ар кандай ички тармактарга бөлүү өтө маанилүү (репликаны киргизүү/чыгаруудан бөлүү өзгөчө маанилүү), анткени эгер сиз бардык трафикти бир "калың" субсетага аралаштырсаңыз, анда бул трафикти башкаруу мүмкүн болбой калат жана эки маалымат борборлорунун шарттары бул дагы эле ар кандай тармактын кагылышуусуна себеп болушу мүмкүн. Бул макаланын алкагында биз бул маселени терең изилдебейбиз, анткени сиз маалымат борборлорунун ортосунда жайгашкан тармакты пландаштыруу жөнүндө тармактык жабдууларды өндүрүүчүлөрдүн ресурстарынан окуй аласыз, бул жерде бул кеңири сүрөттөлөт.
Арбитр конфигурациясы
Арбитр ICMP жана SSH протоколдору аркылуу сактоо тутумунун бардык башкаруу интерфейстерине кирүү мүмкүнчүлүгүн камсыз кылууга тийиш. Сиз ошондой эле арбитрдин коопсуздугу жөнүндө ойлонушуңуз керек. Бул жерде бир нюанс бар.
Арбитрдин иштен чыгуусу абдан каалайт, бирок талап кылынбайт. Калыс туура эмес убакта кулап калса эмне болот?
- Метрокластердин нормалдуу режимде иштөөсү өзгөрбөйт, анткени arbtir нормалдуу режимде метрокластердин иштешине такыр таасир этпейт (анын милдети маалымат борборлорунун ортосундагы жүктөмдү өз убагында которуу)
- Анын үстүнө, арбитр тигил же бул себептерден улам кулап түшүп, маалымат борборунда авария болуп “уктап” калса, анда эч кандай которуштуруу болбойт, анткени керектүү которуштуруу командаларын берип, кворумду уюштура турган эч ким болбойт. Бул учурда, метрокластер репликациясы бар кадимки схемага айланат, ал кырсык учурунда кол менен которулууга туура келет, бул РТОго таасирин тийгизет.
Мындан эмне чыгат? Эгер сиз чындап эле минималдуу RTOну камсыз кылышыңыз керек болсо, анда арбитр күнөөгө чыдамдуу болушу керек. Бул үчүн эки вариант бар:
- Каталарга чыдамдуу гипервизордо арбитри бар виртуалдык машинаны ишке киргизиңиз, бактыга жараша бардык чоңдордун гипервизорлору катага чыдамдуулукту колдойт;
- Эгерде үчүнчү сайтта (шарттуу кеңседе) сиз кадимки кластерди орнотууга жалкоо болсоңуз жана гипервоздук кластер жок болсо, анда биз арбитрдин аппараттык версиясын бердик, ал 2U кутучасында жасалган, анда эки кадимки кластер бар. x-86 серверлери иштейт жана алар локалдык иштен туруштук бере алышат.
Метрокластерге нормалдуу режимде кереги жок экендигине карабастан, биз арбитрдин катачылыкка чыдамдуулугун камсыз кылууну сунуштайбыз. Бирок теория да, практика да көрсөткөндөй, эгер сиз чындап эле табигый кырсыкка туруштук бербеген инфраструктураны курсаңыз, анда аны коопсуз ойногонуңуз жакшы. Өзүңүздү жана бизнесиңизди “адепсиздиктин мыйзамынан”, башкача айтканда, арбитрдин да, сактоо тутуму жайгашкан сайттардын биринин да катасынан коргогонуңуз жакшы.
Чечимдин архитектурасы
Жогорудагы талаптарды эске алуу менен, биз төмөнкү жалпы чечим архитектурасын алабыз.
Ашыкча жүктү болтурбоо үчүн LUNs эки сайтка бирдей бөлүштүрүлүшү керек. Ошол эле учурда, эки маалымат борборлорунда өлчөмдөрдү аныктоодо, сиз эки эселенген көлөмдү гана эмес (бир эле учурда эки сактоо тутумунда маалыматтарды сактоо үчүн зарыл), ошондой эле IOPS жана МБ/с эки эселенген натыйжалуулукту камтышы керек. маалымат борборлорунун бири иштен чыккан окуя.
Өлчөмгө туура мамиле кылуу менен (башкача айтканда, биз IOPS жана МБ/сектердин тийиштүү жогорку чектерин, ошондой эле зарыл CPU жана RAM ресурстарын камсыз кылган шартта), эгерде сактагыч тутумдардын бири метро кластери иштебей калса, бир сактоо тутумунда убактылуу иштөө шарттарында иштөөдө олуттуу төмөндөө болбойт.
Бул эки сайт бир убакта иштегенде, синхрондуу репликация жазуу көрсөткүчүнүн жарымын "жеп" жатканы менен түшүндүрүлөт, анткени ар бир транзакция эки сактоо тутумуна (RAID-1/10 окшош) жазылууга тийиш. Ошентип, сактоо тутумдарынын бири иштебей калса, репликациянын таасири убактылуу (иштебеген сактоо системасы калыбына келгенге чейин) жоголот жана биз жазуу натыйжалуулугун эки эсеге көбөйтөбүз. Иштебей калган сактоо тутумунун LUN'лары иштеп жаткан сактоо тутумунда кайра иштетилгенден кийин, бул эки эсе өсүү башка сактоо тутумунун LUN'ларынан жүк пайда болгондугуна байланыштуу жоголот жана биз мурункудай эле аткаруу деңгээлине кайтып келебиз. "жыгылган", бирок бир гана сайттын алкагында.
Компетенттүү өлчөмдөрдүн жардамы менен сиз колдонуучулар бүтүндөй сактоо тутумунун иштебей калышын сезбей турган шарттарды камсыздай аласыз. Бирок биз дагы бир жолу кайталайбыз, бул өтө кылдат өлчөмдү талап кылат, бул үчүн, демек, сиз биз менен акысыз байланыша аласыз :-).
Метрокластерди орнотуу
Метрокластерди орнотуу биз сүрөттөгөн кадимки репликацияны орнотууга абдан окшош . Андыктан айырмачылыктарга гана токтололу. Биз лабораторияда жогорудагы архитектуранын негизинде отургучту, минималдуу версияда гана орноттук: 10G Ethernet аркылуу туташтырылган эки сактоо тутуму, эки 10G өчүргүч жана 10G порттору бар эки сактоо тутумунун өчүргүчтөрү аркылуу караган бир хост. Арбитр виртуалдык машинада иштейт.
Репликация үчүн виртуалдык IP (VIP) конфигурациялоодо, VIP түрүн тандоо керек - metrocluster үчүн.
Биз эки LUN үчүн эки репликация шилтемесин түзүп, аларды эки сактоо тутумуна бөлүштүрдүк: LUN TEST Primary 1 сактоо тутумунда (METRO шилтемеси), LUN TEST2 Primary 2 сактоо тутумунда (METRO2 шилтемеси).
Алар үчүн биз эки бирдей максатты конфигурацияладык (биздин учурда iSCSI, бирок FC да колдоого алынат, орнотуу логикасы бирдей).
Сактоо системасы 1:
Сактоо системасы 2:
Репликациялоо байланыштары үчүн ар бир сактоо тутумунда карта түзүлдү.
Сактоо системасы 1:
Сактоо системасы 2:
Биз multipath орнотуп, аны алып баруучуга сунуштадык.
Арбитрди түзүү
Арбитрдин өзү менен өзгөчө эч нерсе кылуунун кереги жок; сиз аны үчүнчү сайтта иштетип, ага IP берип, ага ICMP жана SSH аркылуу кирүү мүмкүнчүлүгүн конфигурациялашыңыз керек. Орнотуу өзү сактоо тутумдарынын өзүнөн жүзөгө ашырылат. Бул учурда, арбитрди бир жолу метрокластердеги сактоо контроллерлорунун каалаганында конфигурациялоо жетиштүү, бул орнотуулар бардык контроллерлорго автоматтык түрдө бөлүштүрүлөт.
Бөлүмдө Remote репликация>> Metrocluster (ар кандай контроллерде)>> "Configure" баскычын басыңыз.
Биз арбитрдин IP дарегин, ошондой эле эки алыскы сактагычтын башкаруу интерфейстерин киргизебиз.
Андан кийин, сиз бардык кызматтарды иштетишиңиз керек («Баарын кайра баштоо» баскычы). Эгер келечекте кайра конфигурацияланса, орнотуулар күчүнө кириши үчүн кызматтар кайра иштетилиши керек.
Бардык кызматтар иштеп жатканын текшеребиз.
Бул метрокластерди орнотууну аяктайт.
Crash test
Биздин учурда ката-тест өтө жөнөкөй жана тез болот, анткени репликациялоо функциясы (которуу, ырааттуулук ж.б.) талкууланган. . Ошондуктан, метрокластердин ишенимдүүлүгүн текшерүү үчүн бизге бузулууларды аныктоонун автоматташтырылганын, которуштурууну жана жоготууларды эсепке алуунун (киргизүү/чыгаруу аялдамаларынын) жоктугун текшерүү жетиштүү.
Бул үчүн, биз сактагыч тутумдардын биринин толук иштебей калышына окшоштуруп, анын эки контроллерин тең физикалык түрдө өчүрөбүз, адегенде чоң файлды LUNга көчүрө баштадык, ал башка сактоо тутумунда иштетилиши керек.
Бир сактоо тутумун өчүрүү. Экинчи сактоо тутумунда биз кошуна система менен байланыш үзүлгөнү жөнүндө журналдарда эскертүүлөрдү жана билдирүүлөрдү көрөбүз. SMTP же SNMP мониторинги аркылуу эскертмелер конфигурацияланса, администратор тиешелүү эскертмелерди алат.
Туура 10 секунддан кийин (эки скриншотто да көрүнүп турат), METRO репликациялоо туташуусу (иштебеген сактоо тутумунда Негизги болгон) автоматтык түрдө иштеп жаткан сактоо тутумунда Негизги болуп калды. Учурдагы картаны колдонуу менен LUN TEST хостко жеткиликтүү бойдон калды, жаздыруу бир аз төмөндөдү (убада кылынган 10 пайыздын чегинде), бирок үзгүлтүккө учураган жок.
Сыноо ийгиликтүү аяктады.
Өкүм чыгаруу
AERODISK Engine N-сериясындагы сактоо тутумдарында метрокластердин учурдагы ишке ашырылышы IT кызматтарынын токтоп калууларын жоюу же азайтуу жана алардын 24/7/365 минималдуу эмгек чыгымдары менен иштешин камсыз кылуу зарыл болгон маселелерди чечүүгө толук мүмкүнчүлүк берет.
Албетте, мунун баары теория, идеалдуу лабораториялык шарттар ж. Кырсыктан корголбогон конфигурацияда эки эле сактоо тутумун колдонгон биздин белгилүү кардарларыбыздын бири долбоор тууралуу маалыматты жарыялоого макул болгон, ошондуктан кийинки бөлүктө биз согуштук ишке ашыруу жөнүндө сүйлөшөбүз.
Рахмат, жемиштүү талкууну күтөбүз.
Source: www.habr.com