Практически стъпки за изграждане на резервна система, списание Network Solutions

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

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

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

Разбира се, както често правят, можете да се доверите на мнението на колеги в магазина, които вече имат този или онзи IBS. След като направите груба оценка на цената на същата система, можете да я закупите, да я прехвърлите в ИТ отдела за въвеждане в експлоатация и изведнъж да откриете, че няма достатъчно лицензи, само архиви от последната седмица са поставени в системата за съхранение или прехвърлянето на данни не се побира в прозореца за архивиране. Грешката е ясна - трябваше да се поръча предварителен преглед на ИТ системата и да се проведе обучение на служителите.

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

Оказва се, че изборът на доставчик на RMS, който е препоръчан от приятел, колега или интегратор, провел проучването, не е оптимален? Възможността да се поръча дизайн от двама или трима независими интегратори, за да се получат няколко решения от различни производители, дори не трябва да се разглежда, тъй като след такива проучвания няма да останат пари за внедряване.

Разпръснати по резервни сценарии

КАК ДА ПРОВЕДЕТЕ НЕЗАВИСИМО ПРОУЧВАНЕ И ДА ИЗБЕРЕТЕ ДОСТАВЧИК НА SRK

Сега нека се опитаме да отговорим на най-важния въпрос за собственика на компанията - за цената на решението. Нуждата от резервни копия е назряла, всеки разбира това, но малко хора имат представа колко пари трябва да платите за SRK. Защо точно толкова? И какъв ще е ефекта? Кога ще се върне инвестицията? За да отговорите на всички тези въпроси и да получите оценка на цената на CRO, е напълно възможно главният информационен служител, който не е необходимо да има специални познания на системния администратор за това.

Таблица 1. Класификация на фирмените услуги

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

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

Таблица 2. График за архивиране

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

Както винаги, има борба с противоречия: от една страна, бизнесът се нуждае от непрекъснати услуги, които могат да бъдат възстановени „с едно щракване“, а от друга страна, ИТ специалистите, които се интересуват от намаляване на работното си натоварване, биха искали да имат възможно най-малко резервно копие. Решението за каквокомпромисното състояние, което е най-подходящо за вашето предприятие и се вписва в бюджета, ще бъде решено по-късно. Сега е достатъчно да подготвите два или три сценария, които представят както твърди, така и меки изисквания за наличността на услугите (вижте въведението към статията).

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

НЕОБХОДИМ ЛИ Е IBS? КАКВИ РИСКОВЕ ПРЕДОТВРАТЯВА?

Нека преценим какви рискове възникват и какви загуби води до липсата на тази или онази услуга. Ако е трудно да направите точни изчисления, можете да използвате формулировката "от и до" или да оцените влиянието на риска върху оборота на компанията (пропорционално). В резултат на това разходите за загуба на определена услуга ще бъдат добавени към регистъра.

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

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

Таблица 3. Източници на защитени данни

Сега е моментът да помислим за RMS архитектурата. За да направите това, трябва да отговорите на няколко въпроса относно необходимото здраве на инфраструктурата. До каква степен може да се влоши обслужването на вашата компания, така че рисковете да са минимални? Кои услуги могат да бъдат изоставени в критична ситуация и кои трябва да бъдат предоставени първи? Как да приложим сигурността на съхранението на резервни данни?

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

Ако вашата компания има клонове, тогава може да е препоръчително да прехвърлите копия за съхранение в друг клон или да организирате централизирано управление на системата и съхранение на данни. За да направите това, оценете количеството защитени данни в клоновете, каналите за пренос на данни между тях и компетентността на ИТ специалистите. Определете възможните прозорци за архивиране и изчислете натоварването на каналите, особено ако клоновете са географски разпръснати или целевата архитектура на RMS включва отдалечено съхранение на архиви. Процесът на архивиране създава натоварване на работната система и в някои случаи изисква определени действия сданни, за да ги поддържате последователни. Следователно прозорецът за архивиране трябва да бъде планиран извън периодите на продуктивно използване на услугите или в момента на тяхното минимално търсене, тогава всички необходими операции за архивиране ще бъдат извършени с резерв.

ТЕХНИКА ЗА КОПИРАНЕ НА ДАННИ

Така на този етап ще създадете регистър на всички фирмени услуги, ще ги класифицирате според изискванията на бизнеса и ще формирате представа за целевата архитектура на системата. Този регистър може да се счита за технически изисквания за RMS и, както вероятно се досещате, те вече включват информация за RPO и RTO, обема и характеристиките на защитените данни, прозорците за архивиране и системната топология (вижте Таблица 4). Всъщност, ако сте направили оценъчен анализ на различни решения, както беше споменато по-горе, вие ще сте подготвили няколко алтернативни сценария за изпълнение на проекта RMS, които не зависят от хардуер и софтуер.

Таблица 4. Технически изисквания за RMS

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

Ако смятате, че сте направили достатъчно, вземете вашите изисквания и ги изпратете за оценка в отделите за подготовка на продажбите на различни доставчици или интегратори. Много компании са готови да се борят за потенциален купувач, предоставят достатъчна финансова подкрепа на офисите за предварителна продажба и могат да извършат изчислението безплатно. Всеки клиент, принадлежащ към корпоративния сегмент (Enterprise), може безопасно да се свърже с лидерите от квадрантаGartner и поискайте оценка на разходите за сценарии на RBS. По-малките компании вероятно няма да се нуждаят от допълнителен хардуер, а безплатен софтуер, който има доста дълга история на използване и положителни отзиви, е добре.

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

В резултат на това ще имате предложения за проектиране на RMS въз основа на решения от няколко доставчици и в съответствие с няколко сценария. Ще трябва да вземете предвид съществуващите ограничения и да вземете решение за избора на целевия модел в рамките на определения бюджет. Групирайте услугите по класификация и сумирайте низовете в регистъра, след което покажете на изпълнителния директор опциите за прилагане на RMS. Покажете ясно колко пари ще получи възстановяването на услугите на компанията и с каква скорост. Посочете какви рискове се предотвратяват и каква е прогнозната цена на тези рискове (вижте Таблица 5).

Таблица 5. Избор на сценарий и RMS решение

ПОСЛЕСЛОВ

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

Сергей Чекмасов - ръководител на службата за поддръжка на хардуерния и софтуерния комплекс на Карелския регионален дистрибуционен отдел, клон на OAO SO UES. С него може да се свържете чрез: http://www.linkedin.com/in/chekmasoff.

Споделяйте материал с колеги и приятели

---