Уявіце сабе: вы абслугоўваеце ІТ-інфраструктуру буйнога гандлёвага цэнтра. У горадзе пачынаецца лівень. Патокі дажджу прарываюць дах, вада запаўняе гандлёвыя памяшканні па шчыкалатку. Спадзяемся, што ваша серверная не ў склепе, інакш праблем не пазбегнуць.
Апісаная гісторыя - не фантазія, а зборнае апісанне пары падзей 2020 года. У буйных кампаніях на гэты выпадак заўсёды пад рукой план пасляаварыйнага аднаўлення, ці disaster recovery plan (DRP). У карпарацыях за яго адказваюць спецыялісты па бесперапыннасці бізнэсу. Але ў сярэдніх і невялікіх кампаніях рашэнне такіх задач кладзецца на ІТ-службы. Трэба самому разабрацца ў бізнэс-логіцы, зразумець, што і дзе можа зваліцца, прыдумаць абарону і ўкараніць.
Выдатна, калі ІТ-адмыслоўцу атрымоўваецца правесці перамовы з бізнэсам і абгаварыць неабходнасць абароны. Але я не раз назіраў, як кампанія эканоміла на рашэнні для disaster recovery (DR), бо лічыла яго залішнім. Калі надыходзіла аварыя, доўгае аднаўленне пагражала стратамі, а бізнэс аказваўся не гатовы. Можна колькі заўгодна паўтараць: "А я ж казаў", – аднаўляць сэрвісы ўсё роўна трэба будзе ІТ-службе.
З пазіцыі архітэктара раскажу, як пазбегнуць гэтай сітуацыі. У першай частцы артыкула пакажу падрыхтоўчую працу: як абмяркоўваць з замоўцам тры пытанні для выбару прылад абароны:
- Што абараняем?
- Ад чаго абараняем?
- Як моцна абараняем?
У другой частцы пагаворым аб варыянтах адказу на пытанне: чым абараняцца. Прывяду прыклады кейсаў, як розныя замоўцы будуюць сваю абарону.
Што абараняем: высвятляем крытычныя бізнэс-функцыі
Лепш пачынаць падрыхтоўку з абмеркавання плана пасляаварыйных дзеянняў з бізнес-заказчыкам. Тут галоўная складанасць - знайсці агульную мову. Замоўца звычайна не хвалюе, як ІТ-рашэнне працуе. Яго хвалюе, ці можа сэрвіс выконваць бізнэс-функцыі і прыносіць грошы. Напрыклад: калі сайт працуе, а аплатная сістэма "ляжыць", паступленняў ад кліентаў няма, а "крайнія" – усё роўна ІТ-спецыялісты.
ІТ-спецыяліст можа адчуваць складанасці ў такіх перамовах па некалькіх прычынах:
- ІТ-службе не да канца вядомая роля інфармацыйнай сістэмы ў бізнэсе. Напрыклад, калі няма даступнага апісання бізнэс-працэсаў ці празрыстай бізнэс-мадэлі.
- Ад ІТ-службы залежыць не ўвесь працэс. Напрыклад, калі частка працы выконваюць падрадчыкі, а ў ІТ-адмыслоўцаў няма на іх прамога ўплыву.
Я б пабудаваў размову так:
- Тлумачым бізнэсу, што аварыі здараюцца са ўсімі, а на аднаўленне патрабуецца час. Лепш за ўсё - прадэманстраваць сітуацыі, як гэта адбываецца і якія наступствы магчымыя.
- Паказваем, што ад ІТ-службы залежыць не ўсё, але вы гатовы дапамагчы з планам дзеянняў у зоне вашай адказнасці.
- Просім бізнэс-заказчыка адказаць: калі здарыцца апакаліпсіс, які працэс трэба аднавіць першым? Хто і як у ім удзельнічае?
Ад бізнэсу неабходны просты адказ, напрыклад: трэба, каб колл-цэнтр працягнуў рэгістраваць заяўкі 24/7.
- Просім аднаго-двух карыстачоў сістэмы падрабязна апісаць гэты працэс.
Лепш прыцягнуць на дапамогу аналітыка, калі ў вашай кампаніі такой ёсць.Для пачатку апісанне можа выглядаць так: кол-цэнтр атрымлівае заяўкі па тэлефоне, па пошце і праз паведамленні з сайта. Потым заводзіць іх у 1С праз вэб-інтэрфейс, адтуль іх забірае вытворчасць вось такім спосабам.
- Затым глядзім, якія апаратныя і праграмныя рашэнні падтрымліваюць працэс. Для комплекснай абароны ўлічваем тры ўзроўні:
- прыкладанні і сістэмы ўнутры пляцоўкі (праграмны ўзровень),
- саму пляцоўку, дзе круцяцца сістэмы (інфраструктурны ўзровень),
- сетку (пра яе наогул часта забываюць).
- Высвятляем магчымыя кропкі адмовы: вузлы сістэмы, ад якіх залежыць працаздольнасць сэрвісу. Асобна адзначаем вузлы, якія падтрымліваюць іншыя кампаніі: аператары сувязі, хостынг-правайдэры, дата-цэнтры і гэтак далей. З гэтым можна вяртацца да бізнэс-заказчыку для наступнага кроку.
Ад чаго абараняем: рызыкі
Далей высвятляем у бізнэс-заказчыка, ад якіх рызык мы абараняемся ў першую чаргу. Усе рызыкі ўмоўна падзелім на дзве групы:
- страта часу з-за прастою сэрвісаў;
- страта даных з-за фізічных уздзеянняў, чалавечага фактару і г.д.
Бізнэсу страшна страціць і дадзеныя, і час - усё гэта вядзе да страты грошай. Так што зноў задаём пытанні па кожнай групе рызык:
- Ці можам мы ацаніць для гэтага працэсу, колькі ў грошах каштуе страта дадзеных і страта часу?
- Якія дадзеныя мы не можам страціць?
- Дзе не можам дапусціць прастою?
- Якія падзеі найбольш верагодныя і мацнейшыя нам пагражаюць?
Пасля абмеркавання мы зразумеем, як расставіць прыярытэты для кропак адмовы.
Як моцна абараняем: RPO і RTO
Калі зразумелыя крытычныя кропкі адмовы, разлічваем паказчыкі RTO і RPO.
Нагадаю, што RTO (recovery time objective) - Гэта дапушчальны час з моманту аварыі і да поўнага аднаўлення сэрвісу. На мове бізнесу - гэта дапушчальны час прастою. Калі мы ведаем, колькі грошай прыносіў працэс, то зможам палічыць страты ад кожнай хвіліны прастою і вылічыць дапушчальную страту.
RPO (recovery point objective) - Дапушчальная кропка аднаўлення дадзеных. Яна вызначае час, за які мы можам страціць дадзеныя. З пункту гледжання бізнесу, страта даных можа пагражаць, напрыклад, штрафамі. Такія страты таксама можна перавесці ў грошы.
Час аднаўлення трэба разлічваць для канчатковага карыстальніка: у які тэрмін ён зможа ўвайсці ў сістэму. Так што спачатку складаем час аднаўлення ўсіх звёнаў ланцуга. Тут часта робяць памылку: бяруць RTO правайдэра з SLA, а пра астатнія складнікі забываюцца.
Паглядзім на канкрэтным прыкладзе. Карыстальнік заходзіць у 1С, сістэма адчыняецца з памылкай базы дадзеных. Ён звяртаецца да сістэмнага адміністратара. База знаходзіцца ў воблаку, сісадмін паведамляе аб праблеме сэрвіс-правайдэру. Дапушчальны, на ўсе камунікацыі сыходзіць 15 хвілін. У воблаку база такога аб'ёму адновіцца з бэкапу за гадзіну, такім чынам, RTO на баку сэрвіс-правайдэра – гадзіну. Але гэта не канчатковы тэрмін, для карыстальніка да яго дадаліся 15 хвілін на выяўленне праблемы.
Далей сістэмнаму адміністратару трэба праверыць, што база карэктная, падлучыць яе да 1С і запусціць сэрвісы. На гэта неабходна яшчэ гадзіна, значыць, RTO на баку адміністратара – ужо 2 гадзіны 15 хвілін. Карыстальніку трэба яшчэ 15 хвілін: залагініцца, праверыць, што патрэбныя транзакцыі з'явіліся. 2 гадзіны 30 хвілін - агульны час аднаўлення сэрвіс у гэтым прыкладзе.
Гэтыя разлікі пакажуць бізнэсу, ад якіх знешніх фактараў залежыць тэрмін аднаўлення. Напрыклад, калі офіс заліваюць, то спачатку трэба выявіць працёк і ўхіліць яе. Спатрэбіцца час, які залежыць не ад ІТ.
Чым абараняем: выбіраемы прылады для розных рызык
Пасля абмеркавання ўсіх пунктаў заказчык ужо разумее цану аварыі для бізнесу. Цяпер можна выбіраць інструменты і абмяркоўваць бюджэт. Пакажу на прыкладах кліенцкіх кейсаў, якія прылады мы прапануем для розных задач.
Пачнём з першай групы рызык: страт з-за прастояў сэрвісу. Варыянты рашэння для гэтай задачы павінны забяспечваць добры RTO.
- Размясціць прыкладанне ў воблаку
Для пачатку можна проста пераехаць у воблака - там пытанні высокай даступнасці ўжо прадумаў правайдэр. Госты віртуалізацыі сабраны ў кластар, электрасілкаванне і сетка зарэзерваваны, дадзеныя захоўваюцца на абароненай ад збояў СХД, а сэрвіс-правайдэр нясе фінансавую адказнасць за прастоі.
Напрыклад, можна размясціць у воблаку віртуальную машыну з базай дадзеных. Дадатак падключыцца да базы дадзеных звонку па ўстаноўленым канале або з гэтага ж аблокі. Калі ўзнікнуць праблемы з адным з сервераў кластара, то ВМ перазапусціцца на суседнім серверы менш чым за 2 хвіліны. Пасля гэтага ў ёй паднімецца СКБД, і праз некалькі хвілін база даных стане даступная.
OTR: вымяраецца ў хвілінах. Прапісаць гэтыя тэрміны можна ў дамове з правайдэрам.
Кошт: лічым кошт рэсурсаў аблокі пад ваша прыкладанне.
Ад чаго не абароніць: ад масавых збояў на пляцоўцы правайдэра, напрыклад, з-за аварый на ўзроўні горада. - Кластарызаваць дадатак
Калі жадаецца палепшыць RTO, папярэдні варыянт можна ўзмацніць і адразу размясціць у воблаку кластарызаванае прыкладанне.
Рэалізаваць кластар можна ў рэжыме active-passive ці active-active. Ствараем некалькі ВМ, зыходзячы з патрабаванняў вендара. Для большай надзейнасці разносім іх па розных серверах і СХД. Пры адмове сервера з адной з БД, рэзервовая нода прымае на сябе нагрузку за некалькі секунд.
OTR: вымяраецца ў секундах.
Кошт: крыху даражэйшае за звычайнае воблака, спатрэбяцца дадатковыя рэсурсы для кластарызацыі.
Ад чаго не абароніць: па-ранейшаму не абароніць ад масавых збояў на пляцоўцы. Але лакальныя збоі будуць не такімі працяглымі.З практыкі: У кампаніі-рытэйлера было некалькі інфармацыйных сістэм і сайтаў. Усе базы дадзеных размяшчаліся лакальна ў офісе кампаніі. Ні аб якім DR не задумваліся, пакуль офіс не застаўся без электрычнасці некалькі разоў запар. Кліенты былі незадаволеныя збоямі на сайтах.
Праблема з даступнасцю сэрвісаў вырашылася пасля пераезду ў воблака. Плюс да гэтага ўдалося аптымізаваць нагрузку на базы даных за кошт балансіроўкі трафіку паміж вузламі. - Пераехаць у катастрофаўстойлівае воблака
Калі трэба, каб працы не перашкодзіла нават стыхійнае бедства на асноўнай пляцоўцы, можна абраць катастрофаўстойлівае воблака. У гэтым варыянце правайдэр разносіць кластар віртуалізацыі ўжо на 2 дата-цэнтра. Паміж дата-цэнтрамі адбываецца сталая сінхронная рэплікацыя, адзін-у-адзін. Каналы паміж ЦАД зарэзерваваны і ідуць па розных трасах, так што такому кластару не страшныя праблемы з сеткай.
OTR: імкнецца да 0.
Кошт: самы дарагі варыянт у воблаку.
Ад чаго не абароніць: Не дапаможа ад псавання звестак, а таксама ад чалавечага фактару, таму паралельна рэкамендуецца рабіць бэкапы.З практыкі: Адзін з нашых кліентаў распрацаваў комплексны план пасляаварыйнага аднаўлення. Вось якую стратэгію ён абраў:
- Катастрафоўстойлівае воблака абараняе дадатак ад збояў на ўзроўні інфраструктуры.
- Двухузроўневы бэкап забяспечвае абарону на выпадак чалавечага фактару. Рэзервовыя копіі робяць двух відаў: "лядоўні" і "гарачыя". «Халодны» бэкап знаходзіцца ў выключаным стане, на яго разгортванне патрабуецца час. "Гарачы" бэкап ужо гатовы да працы і аднаўляецца хутчэй. Яго захоўваюць на спецыяльна выдзеленай СГД. Трэцюю копію запісваюць на стужку і захоўваюць у іншым памяшканні.
Раз у тыдзень кліент тэсціруе абарону і правярае працаздольнасць усіх бэкапаў, у тым ліку са стужкі. Штогод у кампаніі праводзяць тэсціраванне ўсяго катастрофаўстойлівага аблокі.
- Арганізаваць рэплікацыю на іншую пляцоўку
Яшчэ адзін варыянт, як можна пазбегнуць глабальных праблем на асноўнай пляцоўцы: забяспечыць геарэзерваванне. Іншымі словамі, стварыць рэзервовыя віртуальныя машыны на пляцоўцы ў іншым горадзе. Для гэтага падыдуць спецыяльныя рашэнні для DR: мы ў кампаніі выкарыстоўваем VMware vCloud Availability (vCAV). З яго дапамогай можна наладзіць абарону паміж некалькімі пляцоўкамі хмарнага правайдэра ці аднавіцца ў воблака з on-premise пляцоўкі. Больш падрабязна пра схему працы з vCAV я ўжо расказваў .
RPO і RTO: ад 5 хвілін.
Кошт: даражэйшы за першы варыянт, але таннейшы за апаратную рэплікацыю ў катастрофаўстойлівым воблаку. Кошт складаецца з кошту ліцэнзіі vCAV, платы за адміністраванне, кошты рэсурсаў аблокі і рэсурсаў пад рэзерв па мадэлі PAYG (10% ад кошту працуючых рэсурсаў за выключаныя ВМ).
З практыкі: Кліент трымаў у нашым воблаку ў Маскве 6 віртуальных машын з рознымі базамі даных. Спачатку абарону забяспечваў бэкап: частку рэзервовых копій захоўвалі ў воблаку ў Маскве, частка - на нашай пецярбургскай пляцоўцы. З часам базы дадзеных выраслі ў аб'ёме, і аднаўленне з бэкапу стала патрабаваць больш часу.
Да бэкапаў дадалі рэплікацыю на базе VMware vCloud Availability. Рэплікі віртуальных машын захоўваюцца на рэзервовай пляцоўцы ў Санкт-Пецярбургу і абнаўляюцца кожныя 5 хвілін. Калі на асноўнай пляцоўцы адбываецца збой, супрацоўнікі самастойна пераключаюцца на рэпліку віртуальнай машыны ў Санкт-Пецярбургу і працягваюць працаваць з ёй.
Усе разгледжаныя рашэнні забяспечваюць высокую даступнасць, але не ратуюць ад страт дадзеных з-за віруса-шыфравальшчыка або выпадковай памылкі супрацоўніка. На гэты выпадак нам спатрэбяцца бэкапы, якія забяспечаць патрэбны RPO.
5. Не забыцца пра рэзервовае капіраванне
Усе ведаюць, што трэба рабіць бэкапы, нават калі ў вас самае крутое катастрофаўстойлівае рашэнне. Так што толькі сцісла нагадаю некалькі момантаў.
Строга кажучы, бэкап - гэта не DR. І вось чаму:
- Гэта доўга. Калі дадзеныя вымяраюцца ў тэрабайтах, на аднаўленне запатрабуецца не адну гадзіну. Трэба аднавіць, прызначыць сетку, праверыць, што ўключыцца, паглядзець, што даныя ў парадку. Так што забяспечыць добры RTO можна, толькі калі даных мала.
- Дадзеныя могуць аднавіцца не з першага разу і трэба закласці час на паўторнае дзеянне. Напрыклад, бываюць выпадкі, калі мы сапраўды не ведаем час страты дадзеных. Дапусцім, страту заўважылі ў 15.00, а копіі робяцца кожную гадзіну. З 15.00 мы глядзім усе кропкі аднаўлення: 14:00, 13:00 і гэтак далей. Калі сістэма важная, мы імкнемся мінімізаваць узрост кропкі аднаўлення. Але калі ў свежым бэкапе не знайшлося патрэбных дадзеных, бярэм наступную кропку - гэта дадатковы час.
Пры гэтым расклад рэзервовага капіявання можа забяспечыць патрэбны РПО. Для бэкапаў важна прадугледзець геарэзерваванне на выпадак праблем з асноўнай пляцоўкай. Частку рэзервовых копій рэкамендуецца захоўваць асобна.
У выніковым плане пасляаварыйнага аднаўлення павінна быць мінімум 2 інструменты:
- Адзін з варыянтаў 1-4, які абароніць сістэмы ад збояў і падзенняў.
- Рэзервовае капіраванне для абароны дадзеных ад страт.
Таксама варта паклапаціцца аб рэзервовым канале сувязі на выпадак падзення асноўнага інтэрнэт-правайдэра. І - вуаля! - DR на мінімалках ўжо гатовы.
Крыніца: habr.com