Курсов Проект

Мрежи за съхранение на данни

Тема: Център за възстановяване при бедствия (Disaster recovery center)

Изготвил: Димитър Йорданов Александров

Фак. номер: 111322017
Специалност: Телекомуникации
Дата: 20.05.2023
 I. Теоретична част
В днешни дни всяка оперираща организация предлагаща своите услуги
използва оборудване, което да извършва необходимите дейности, за да
функционират правилно дадените услуги. Това оборудване представлява
сървъри, дискови масиви, комутатори, рутери и много други хардуерни и
софтуерни компоненти, тяхното правилно функциониране е строго обвързано
с помещението, в което се намират, дали отговаря на изискванията за
съхраняване на хардуерно оборудване като, дали е правилно охладено, да
разполага с няколко резервни източника на захранване, да се спазва чистота и
да няма голяма влажност в помощението. Не всяка организация разполага със
сертифицирано помощение за съхраняване на своето оборъдване, а и ако
организацията е от голям тип и разполага с множество оборудване, едно такова
помещение няма как да обслужва нужди на оборудването намиращо се в него.

Затова са създадени центровете за данни, те са централната нервна система

на всяка компания – през него минава цялата комуникация и, най-важното –
връзката с клиентите в света онлайн.

Ето защо е жизненоважно той да е добре организиран, да работи добре.

Разбира се, далеч не всяка организация днес има ресурсите да поддържа свой
пълноценен център за данни. За щастие, в наши дни дори не е нужно – в
епохата на cloud услугите за това се грижат хостинг компаниите като важна
връзка с облака.

Центровете за данни съхраняват сървъри, дискови масиви, комутатори,

рутери и много други хардуерни устройства, които изпълняват услугите на
една организация, като те са от критична важност и затова се планират и
имплементират множество резервирани решения, за да се избегне отпадането
на услугите при възникване на проблем с някое от хардуерните или
софтуерните оборудвания. Но дали това е достатъчноза да се подсигури
отказоустойчивостта на една организация.

Въпреки имплементирането на множество резервирани решения като

предоставеня на повече изчислителна мощност, мрежови устройства и
дискови масиви така, че ако отпадне един или няколко хардуерни устойства
поради някаквър проблем работата на услугите да не прекъсва, това не
винаги успавя да предотврати отпадането на услугите на една организация.
При съхраняване на цялото оборудване на една организация в един център за
данни това предоставя заплаха и не винаги подсигурява са напълно
отказоустойчивост, тъй като при наличние на отпадане на захранване,
наличние на природни бедствия с определен окръг, в който се намира
центъра за данни, това може да доведе до отпадане на целия център за данни,
което ще доведе до отпадане на услгите на всички организации, чието
оборъдване се намира изцяло в този център за данни.

Поради тази не пълна резервираност е строго препоръчително да се

планира и имплементира решение, което да съхранява оборудване, във втори
център за данни намиращ се на не по-малко от 350 км разстояние по този
начин да се запази непрекъсната или минално прекъсната работа на услугите
на една организация. Много от организациите пренебрегват тази препоръка с
цел да намалят разходите си, но не обмислят какви ще излязат разходите им
при възникване на такова бедствено положение и колко време ще им е
необходимо да се възстановят от тази загуба. Като тези заплахи не се
определят само като природни заплахи, но и много други, като кибер атаките
са една от най-големите заплахи в такива ситуации и затова такова решение е
от значителна важност да бъде имплементирано с цел сигурност и
резервираност на услугите.

Видове решения за възстановяване след бедствие

1. Център за данни за възстановяване след бедствие

Организациите със собствени центрове за данни трябва да прилагат

стратегия за възстановяване след бедствие, която обхваща всички компоненти
на ИТ инфраструктурата в центъра за данни и заобикалящото физическо
съоръжение. Тази стратегия обикновено се съсредоточава върху резервни
копия на сайтове за отказ, разположени във вторични центрове за данни или
съоръжения за колокация. Бизнес и ИТ лидерите трябва да документират
различните компоненти на тези физически съоръжения, включително
отопление, охлаждане, захранване, реакция при пожар и контрол на
сигурността [1].

2. Възстановяване след бедствие в мрежата

Мрежовата свързаност е от решаващо значение за външната и вътрешната

комуникация, достъпа до приложения и споделянето на данни в случай на
бедствие. Стратегията за възстановяване при бедствия в мрежата трябва да
описва подробно план за възстановяване на мрежовите услуги и да осигури
достъп до резервни данни и вторични места за съхранение [1].

3. Виртуализирано възстановяване след бедствие

Организациите могат да използват виртуализация, за да възпроизведат

натоварванията на вторично място или облачна среда за възстановяване след
бедствие. Виртуализираният DR е гъвкав, лесен за изпълнение, бърз и
ефективен - виртуализираните натоварвания имат малки ИТ отпечатъци,
поддържат честа репликация и позволяват бързо иницииране на отказ.
Различни доставчици на защита на данните предоставят виртуални DR и
резервни продукти [1].

4. Възстановяване след бедствие в облака

С много налични облачни услуги, организациите могат да хостват DR

системи в облачна среда, а не на физическо място. Възстановяването при
бедствия в облака включва повече от архивиране в облака. ИТ екипите трябва
да конфигурират автоматичното работно натоварване при отказ към облачната
платформа DR за незабавно възстановяване, когато възникне прекъсване [1].

5. Възстановяване след бедствие като услуга (DRaaS)

DRaaS е търговска облачна DR услуга, която позволява на организацията

да възпроизвежда и хоства своите виртуални и физически сървъри на
инфраструктурата на трета страна. Доставчикът на услуги DR е отговорен за
изпълнението на плана за възстановяване при бедствия по време на криза въз
основа на споразумението за ниво на обслужване [1].

Примерите на DRaaS включват платформи за защита на данните и

архивиране, решения за инфраструктура като услуга (IaaS) и добавки от
доставчици на колокация и центрове за данни [1].

Едно от най-често използваните възстановявания от бедствия са

възстановяване в облака и възстановяване от бедствие като услуга (DRaaS).

Планирането на въздстновяване от бедствия не е лесна процедура, изисква

много планиране, в което влючва определете целите на възстановяването,
определете правилната стратегия за репликация, разстоянието, свързаността и
общите разходи за собственост (Total Cost of Ownership (TCO)).
 Важно е да се определят целите на възстановяването, като например целта
за времето за възстановяване (RTO) и целта на точката за възстановяване
(RPO), като посочите приемливото ниво на загуба на данни. Различните
набори от данни могат да имат различни цели за възстановяване, изискващи
разнообразна стратегия за DR. Тези цели следва да са свързани с различни
сценарии за бедствия и приоритети за защита на данните.

Определянето на правилната стратегия за репликация и тип за

приложението е една от важните стъпки в проектирането на решение за
възстановяване при бедствие. Избягвайте смесването на нивата на репликация
за една и съща категория на приложение.

Четирите опции за репликация са:

• Ниво на приложение – предлага ниски RPOs и RTO, но изисква

поддръжка на операционната система и коригирането й, за да се гарантира
производителността при отказ. Този подход на репликация е подходящ за SQL
бази данни.

• Ниво на гостуваща операционна система – репликира данните на

целевата машина на блоково ниво. Тази репликация позволява failover с едно
щракване, но включва агент на машината източник и разходи за лиценз.

• SAN или LUN ниво – репликира целия LUN или SAN и неговите
виртуални машини. Тази опция работи с виртуални и физически машини, но е
по-малко подходяща за публичния облак.

• Ниво на хипервайзор – помага да се спестят пари за репликация в

облака и е SAN-агностик. Тази опция не е подходяща за физически машини.
 Помислете за разстоянието, свързаността и други фактори на околната
среда, сайтът на DR трябва да бъде на безопасно разстояние от основния
център за данни, за да се гарантира, че остава незасегнат от физически
бедствия като пожари или земетресения. Решенията за дистанционно
управление правят това по-лесно, но те могат да бъдат обект на проблеми с
латентността. Друг фактор, който трябва да се вземе предвид при избора на
местоположение, е климатът - по-топлият климат може да бъде по-скъп, като
се имат предвид нуждите от охлаждане на системата.

Помислете за TCO, нуждите от възстановяване при бедствия могат да се

променят с течение на времето, така че е важно да се вземат предвид общите
разходи за собственост на DR решението, заедно с нуждите от мащабируемост
и гъвкавост. Ако решението не може да се мащабира с бизнеса, то може да
стане по-малко ефективно и по-скъпо.
II. Решение на поставената задача
Решението за възстановяване от бедствие, което ще бъде представено е
възстановяване в друг център за данни намиращ се на отдалечена локация. Тъй
като е един от най-често срещаните варианти и сигурни варианти, затова ще
преставим решението за възстановяване в отдалечен център за данни.

Както разгледахме обширно възстановяването при възникване на бедствие

е от изключителна важност, но начина за синхронизация между двата сайта е
от голямо значение тъй като ако пътят не е сигурен между двете локации, то
сихронизацията и възстановяването става невъзможно. Затова едно от първите
важни фактори е подсигурения път меджу двата сайта, за да преминава
успешно репликацията.

Има множество начини за извършване на възстановяване от бедствени

ситуации главните и основни методи са чрез актуален бекъп до зададен момент
или чрез извършване на репликация между двата сайта, което позволява
синхронизация на данните и бърза реакция при бедствено състояние. Тъй като
възстановяването от бекъп отнема изключително много време за
възстановяване до съответен момент както и не е напълно подсигурено, че този
бекъп е работоспособен, това решение от гледна точна минално отпадане и
възстановяване е слабо прерочителен, след което няма да бъде представен в
това решение на поставената задача.

След като репликацията предоставя често синхронизиране на данните

между двата сайта, това позволява бърза реакция и моментно възстановяване
при възникване на бедствие, което ще минимизира отпадането на услугите и
работата на клиетите.
 Има множество топологий за репликация както и продукти, които
предоставят това решение, като ще представя две от решения за репликация,
като едното е значително нов на пазара.

Първото решение за репликация се казва Metro Replication (Метро

Репликация), имено то е ново решение, което е излязло на пазара. То
преставлява от блоков тип синхронна репликация, която се извършва чрез
Ethernet връзки с минимална скорост на предаване по канала 10 Gbps. Този тип
репликация представлява създаване на един или няколко общи ресурса, които
са достъпни от двете или повече страни и се оправлява от ръководещия сайт
(Primary Site), който се приема като предпочитан (Preffered), всички нови
данни записани на дисковият ресурс в ръководещия сайт ще бъдат
автоматично представени и на вторичния сайт (Disaster Recovery Site), който
се счита за непредпочитан (Non-Preffered). От страна на вторичния сайт могат
да се създадат такива ресурси също, които да бъдат представени в първиния
сайт по този начин се предоставя топология active-active, която предпазва от
възникване на бедствени положения, на който и да е сайт и бързо
възстановяване с минимална загуба.

Това решение е предоставено от световно известната компания Dell

използвайки дисков масив PowerStore модел T, като Metro репликацията може
да бъде извършена единствено между Dell PowerStore T дискови масиви. На
Фигура 1 е представен изглед на статута на двата дискови масива относно
създадените дискови ресурси на двата сайта, а на Фигура 2 е представена
топология на Metro репликацията между два дискови масива.
 Фигура 1 Статут на двата дискови масива спрямо дисковите ресурси

Фигура 2 Metro Репликация топология non-uniform връзки между инициатори и дискови масиви

Фигура 2 предоставя топология на варианта за връзка на определени

хостове да имат връзка към съответен дисков масив с цел сигурност за
писане в определени ресурс. Този вариант единствено хостовете намиращи се
в първичния център (Primary Site) могат да извършват писане в ресурси
предоставени от дисков масив в първичния сайт и тези данни се репликират
към втория сайт, чрез Metro volume (Metro ресурс, които е конфигуриран за
репликация).

Фигура 3 Metro Репликация топология uniform хост връзки с дисковите масиви

Фигура 3 предоставя топология на варианта за връзка на всички

хостове към всички дискови масиви с цел да имат няколко възможни пътя за
писане в предоставените от тях ресурс с цел резервираност за достъп до
данните. Този вариант дава на всички хостовете намиращи се, в който и да е
сайт да могат да извършват писане в ресурси предоставени от дисковите
масиви като търсят най-бързия път до ресурса и тези данни се репликират
към дисковите масиви на другите сайтове, чрез Metro volume (Metro ресурс,
които е конфигуриран за репликация).

Този вид репликация освен възстановяване, тя позволява и лесно

управление и миграция на данни от дисков масив от един сайт към друг,
което в днешно време отнема изключително много планиране и процедури за
потвърждение, че при тази миграция на данни, данните ще запазят своята
цялост и ще останат непроменени. Докато това решение извършва
автоматизирано всички дейности и може да бъде лесно управлявано при
необходимост от пауза при миграция, спиране на синхронизация и
пренасочване от един дисков масив от предпочитан към други да стане
предпочитан с цел планирани дейсности от тип поддръжка.

Второто решение за репликация е предназначено за съхраняване на

резервно копие на файлови усглуги, като данните да мога т да бъдат
възстановени без никакви или минимални загуби и отпадане на услугите.

Това решение предоставя възможността за репликацията на данни, ако е

необходимо да се използва файлов дисков масив, като решението, което ще
представя е отново решение на Dell EMC, продукт файлов дисков масив
Isilon / PowerScale, който е изцяло файлов дисков маси предоставящ
множество предимства пред останалите файлови дискови масиви като
автоматизирани задачи, които да облекчават ръчните задължения на
администраторите както и предоставя multi-tenancy в случай на
необходимост от сегментиране на различни инфраструктури в един дисков
клсътер.

Репликацията на PowerScale клъстер е изцяло автоматизирана използвайки

лицензна услуга на име SyncIQ. Репликирането на данни се случа
еднопосочно от първичен клъстер (Primary) към вторичен клъстер (DR),
конфигурацията се извършва чрез политики, в които се дефинират какви
дейности да бъдат извършени за извършването на резервно копие, от типа
дали да бъде цяло копие на данните или синхронизирано, като първото копие
е пълно, а всички следващи единствено промени от предходни моменти.
Файловата репликация предоставя лесно копиране на цели директории, които
да бъдат репликирани, както и създаване на отделно политики, които да
съдържат различни индивидуални политики с различни конфигурации за
репликация, което предоставя голяма гъвкавост. На Фигура 4 е представена
топология на PowerScale файлова репликация.

Фигура 4 PowerScale Репликация Топологии

На Фигура 4 съм представил някои от най-често срещаните

конфигигурации, но има още възможности представени по документация.
Процесът за репликация да файлови услуги е представен на Фигура 5.

Фигура 5 Процес на репликация

 Процесът за репликация се случва като всеки отделен нод разполага със
Scheduler, който стартира политиката за репликация, която се координира
чрез Coordinator блока и се извършва репликацията на данните чрез Primary
Worker блоковете.

Репликацията на данните е частта, в която се създава резерното копие, но

частта, в която се премества активния център от първични към вторичния е
друг процес, който не се извършва автоматично. Преди да се извърши
преместването на активния център е необходимо да се подсигури, че
клиентите имат връзка до репликираните ресурси. Тъй като репликацията е
еднопосочна репликираните данни от страна на DR клъстера са в Read Only
(RO) състояние с цел да се запази тяхната цялост и да не могат да бъдат
модифицирани. Данните се прехвърлят в писуеми, когато се извърши така
нареченият Failover, който прехвърля клиентите от първияния клъстер към
вторични и те отново успяват да достъп своите данни с минимално отпадане
и минимални или никакви загуби.
III. Изводи и заключение
1. Сайтовете за възстановяване от бедствия е от изключителна важност,
тъй като предоставя сигурност и резервираност при възникване
природни стихии, но не само от тях. Днешни дни все повече и повече
организации биват хаквани, загубата на време при възстановяване от
такива ситуации без наличие на резервено копие е изключително
дълъг процес или в повечето случай невъзможен без да се извърши
плащане на откуп на похитителите, но дори след това много от
малките организации достигат до фалит поради загубите, които са
претърпяли от спиране на работата до възстановяване до
работоспособно състояние. Затова наличнието на резервно копие,
което да предоставя минимална отпадналост е от огромна важност и
много от организациите го пренебрегват като не преценяват риска от
това да бъдат хаквани. Както казват инженерите по сигурно
„Въпросът не е дали ще бъда хакнат, а КОГА?“

2. Репликацията е значително по-добър варинат за възстановяване от

бедствено положение, тъй като тя гарантира минимално отпадане на
услугите при наличие на проблем. Metro репликацията предоставя
лесно и бързо мигриране на данни от един сайт на друг както и бързно
прехвърля на работата от един сайт на друг с цел минимално отпадане
на услугите и минимални загуби.

3. Репликацията на файлови услуги изпозлвани на Isilon / PowerScale

дисков масив предоставя възможността за бързо и лесно
възстановяване на данни и възстановяване на услуги с минимално
отпадане и минимално или никакви загуби на данни. Както и бързо и
 лесно възстановяване от първичен клъстер (Primary) към вторичен
(DR).

IV. Списък с използваните съкращения

1. DR – Disaster Recovery
2. DraaS – Disaster Recovery as a Service
3. IaaS – Infrastructure as a Service
4. TCO - Total Cost of Ownership
5. RTO - Recovery Time Objective
6. RPO – Recovery Point Objective
7. SAN – Storage Area Network
8. LUN – Logical Unit Number
9. DC – Data Center
10. RO – Read Only
V. Списък с използваните литературни източници
1. https://cloudian.com/guides/disaster-recovery/disaster-
recovery-solutions-top-5-types-and-how-to-choose/
2. https://www.delltechnologies.com/asset/sv-se/products/data-
protection/briefs-
summaries/H16867_data_domain_cloud_dr_sb.pdf
3. https://infohub.delltechnologies.com/l/dell-powerstore-
metro-volume-1/introduction-3591
4. https://infohub.delltechnologies.com/l/configuration-best-
practices-dell-emc-storage-with-the-avigilon-control-center-
system-1/isilon-nas-26
5. https://www.delltechnologies.com/asset/en-
us/products/storage/industry-market/h8224-replication-
isilon-synciq-wp.pdf