RTO и RPO. часть 5

В прошлой статье серии я рассматривал связь бизнеса (читай – денег) и ИТ сервисов. В этой части хочу сделать шаг в сторону практической реализации того, о чем писал в прошлых частях рассказа про RTO/RPO.
Но сразу оговорюсь, метод, описанный ниже, подойдет лишь для небольших ИТ-инфраструктур.

Список статей:

Часть 1: http://www.veskin.ru/2010/10/rto-rpo.html
Часть 2: http://www.veskin.ru/2017/03/rto-rpo-2.html
Часть 3: http://www.veskin.ru/2017/04/rto-rpo-3.html
Часть 4: http://www.veskin.ru/2017/04/rto-rpo-4.html
Часть 5: http://www.veskin.ru/2017/09/rto-rpo-5.html 

“If you fail to plan, you are planning to fail!”

                                                                  Б.Франклин

Или перефразирую известную песенку:

«Ни минуты простоя,
ни секунды простоя…
лишь бы не было сбоя…»

Помните я во второй части приводил такую картинку:

Да, все информационные системы разные, с разными стоимостями простоев и потерь данных. Как нам выбрать наиболее подходящее для всех, унифицированное решение? Ниже приведу один из способов решения этой задачи.

RTO и RPO. часть 4

И снова немного про "бизнес" (вот, думаю, может лучше взять в кавычки слово "немного"?;)).
Почему я пишу в техническом блоге про финансовую сторону, про деньги? Это нужно знать техническим специалистам, если вы не хотите застрять в профессии на одной ступеньке без возможности дальнейшего развития. Как собственного внутреннего развития, так и развития в глазах ваших коллег. Как технического специалиста  вас персонально могут воспринимать по-разному. И если вы будете знать, как ваша деятельность в компании помогает ей двигаться к намеченным финансовым целям, вы повысите понимание деятельности ИТ-службы в глазах ваших коллег. Не умея донести до пользователей внутри компании свою полезность, ИТ превращается в обособленное непонятное подразделение, требующее только расходов на себя. И вы  становитесь такой же затратной единицей в глазах своей компании.

Список статей:

Часть 1: http://www.veskin.ru/2010/10/rto-rpo.html
Часть 2: http://www.veskin.ru/2017/03/rto-rpo-2.html
Часть 3: http://www.veskin.ru/2017/04/rto-rpo-3.html
Часть 4: http://www.veskin.ru/2017/04/rto-rpo-4.html
Часть 5: http://www.veskin.ru/2017/09/rto-rpo-5.html

В прошлый раз я остановился на термине "доступность". Да, доступность - это два-в-одном-и-оба-сразу: доступность данных и доступность сервисов. Бэкап, к примеру, не нужен сам по себе. Это одно из средств обеспечения доступности.

Доступность в свою очередь является частью обеспечения непрерывности бизнеса. Вы наверняка слышали такое понятие.

RTO и RPO. часть 3

Продолжаю серию статей про RTO/RPO.

Список статей:

Часть 1: http://www.veskin.ru/2010/10/rto-rpo.html
Часть 2: http://www.veskin.ru/2017/03/rto-rpo-2.html
Часть 3: http://www.veskin.ru/2017/04/rto-rpo-3.html
Часть 4: http://www.veskin.ru/2017/04/rto-rpo-4.html
Часть 5: http://www.veskin.ru/2017/09/rto-rpo-5.html

В конце прошлой части я дал график для представления классификации различных решений по защите от последствий сбоев в зависимости от целевых RTO/RPO - кластеризация, репликация, резервное копирование. Повторю эту картинку:

Несколько комментариев к графику:

RTO и RPO. часть 2

К международному дню резервного копирования (или, как еще его называют День Бэкапа).

Давно у меня зрел план дополнить и развить старый пост на тему RTO/RPO. Сделать не просто постом, а серией статей, чтобы с их помощью постепенно ввести специалистов в эти важные для любых информационных систем понятия.
RPO/RTO важны для систем и сервисов, а не для непонятной сферической защиты чего-то там в вакууме, в отрыве от реальной работы компании.
В этой статье я продолжу теоретическую часть.

Список статей:

Часть 1: http://www.veskin.ru/2010/10/rto-rpo.html
Часть 2: http://www.veskin.ru/2017/03/rto-rpo-2.html
Часть 3: http://www.veskin.ru/2017/04/rto-rpo-3.html
Часть 4: http://www.veskin.ru/2017/04/rto-rpo-4.html
Часть 5: http://www.veskin.ru/2017/09/rto-rpo-5.html

Два постулата чтобы напомнить, о чем речь:

RPO. Любая информационная система должна обеспечивать (внутренними ли средствами, или сторонними) защиту своих данных от потери выше приемлемого уровня.

RTO. Любая информационная система должна обеспечивать (внутренними ли средствами, или сторонними) возможность восстановления своей работы в приемлемый срок.

Резервное копирование. Incremental или Reverse Incremental?

Довольно-таки часто сталкиваюсь с вопросом, какой вариант резервного копирования лучше выбрать: инкрементальный (incremental) или реверс-инкрементальный (reversed incremental).

Оба варианта поддерживаются Veeam Backup & Replication, и даже есть еще один режим – смешанный (incremental with transform). Вот на примере VBR же и объясню, что к чему, хотя информация общая для всех систем резервного копирования, поддерживающих данные форматы.

BCP & DRP

Есть два понятия, которые довольно часто люди путают.
BCP — Business Continuity Planning — план работ по предотвращению возникновения и исправлению последствий в случае возникновения ситуаций, негативно влияющих на работу компании.
DRP — Disaster Recovery Plan — план восстановления инфраструктуры компании после возникновения аварии.

При этом, как правило, ИТ служба вовлечена в оба плана. А так как зачастую ИТ дистанцировано от непосредственно бизнеса, то понятия и путают.

Итак, что это за планы, и с чем их курят?


BCP — более общий, и глобальный план. Для его построения определяют все риски, способные негативно повлиять на работу компании, не только связанные с ИТ. Далее, план состоит из работ по каждому риску: списки вовлеченных сотрудников, внешних служб; мер по предотвращению риска; последовательности действий по уменьшения воздействия и выхода из кризисной ситуации.
Повторюсь, это не обязательно может быть связано с ИТ (вернее — должно покрывать не только ИТ). Так, например, репутиционные риски закрываются работой по ним администрации и юристов компании.

BCP должен постоянно развиваться вместе с компанией: риски и их влияние должны пересматриваться; мероприятия по предотвращению проводится в жизнь, а мероприятия по выходу из кризисной ситуации тестироваться; все новые сервисы и бизнес-процессы учитываться, добавляться в план.

DRP — как правило должен входить в состав BCP, однако может существовать и сам по себе, в случае отсутствия последнего (хотя это и не есть хорошо).
Этот план призван описать порядок действий по борьбе с последствиями аварий, влияющих на техническое состояние активов компании. Проще говоря, работу офисов, прочих помещений компании, инфраструктуры компании, включая инфраструктуру ИТ.
DRP не только техническое решение, это и административные действия, и определенные процедуры, и состав антикризисного комитета. Но так как наиболее сложная часть компании — инфраструктура ИТ, то и большая часть плана посвящается построению решения по защите этой инфраструктуры.
DRP тоже должен развивается, и желательно в рамках общего BCP. 

Производительность Veeam Instant VM Recovery

Меня часто спрашивают о производительности работы технологии Instant VM Recovery.

Напомню, в таком варианте скорость восстановления целой виртуальной машины фактически равна скорости загрузки этой ВМ, так как никакие данные не копируются, а машина просто запускается непосредственно из архивных файлов (дедуплицированных и сжатых).

Достигая высокого значения RTO, приходится платить производительностью дисковой подсистемы ВМ, пока она не будет перенесена обратно на высокопроизводительную систему хранения. Для переноса необходимо выбрать наиболее подходящий способ миграции, например:

1. Storage vMotion - миграция дисков ВМ, без остановки ВМ.
2. Клонирование работающей ВМ (hot-cloning).
3. Репликация ВМ (например, с помощью Veeam Backup & Replication).
4. Перенос файлов выключенной ВМ в запланированном окне.

Но все же стоит вопрос, а насколько мы теряем в производительности? Сколько по времени будет происходить полное восстановление ВМ - не только доступность сервисов, но и восстановление производительности?

RTO и RPO

UPDATE! Теперь это серия статей по теме RTO/RPO

Список статей:

Часть 1: http://www.veskin.ru/2010/10/rto-rpo.html
Часть 2: http://www.veskin.ru/2017/03/rto-rpo-2.html
Часть 3: http://www.veskin.ru/2017/04/rto-rpo-3.html
Часть 4: http://www.veskin.ru/2017/04/rto-rpo-4.html
Часть 5: http://www.veskin.ru/2017/09/rto-rpo-5.html

Решил статью про одно написать, а углубился в другое... :)

Публикую в качестве ликбеза.

При разработки технических решений по защите данных и сервисов бизнес-задач предприятия обычно оперируют двумя основными понятиями:

• время восстановления (recovery time objective (RTO)) - допустимое время простоя сервиса в случае сбоя.
• точка возврата (recovery point objective (RPO)) - допустимый объем возможных потерь данных в случае сбоя.

Эти значения диктует сам бизнес. Например, если у вас просто обычная не автоматизированная автостоянка, то недоступность электронной почты не критично (это про RTO), а потеря статистики в пасьянсе за год, максимум может сказаться на настроении охранника стоянки (это RPO).

Если вы, допустим, социальная сеть, то простой пару часов - плохо: люди уже начнут смотреть на конкурентов - но еще не критично - тут свою роль играет раскрутка ресурса, и насколько подсажены на этот ресурс пользователи. (RTO)

Но если вы банк, и потеряете данные по платежам... вы можете попрощаться со своим бизнесом - и финансовый и репутационный риски его похоронят со свистом гильотины. (RPO)

RPO и RTO - не просто какие-то абстракции, они имеют совершенно конкретные значения. А чтобы легче было ими вместе оперировать, их приводят к одной шкале - временно́й.
Точка RPO - это время создание последней резервной копии, на момент которой вы можете вернуться в случае сбоя. RTO - время, которое необходимо потратить на восстановление (например, извлечь данные из резервной копии и запустить сервис, предоставляющий эти данные).

Отмечу, что значения RTO и RPO - это экстремумы - максимальные значения. Т.е. сколько нам максимум времени нам бизнес позволяет на простой, или сколько максимум данных (по времени) мы можем потерять.
Пример. RPO = 1 сутки. Значит копированием производим, по-старинке, раз в день (ночью). Если у нас резервное копирование запускается в 1:00, а у нас произошел сбой в 0:59, то мы и потеряли как раз сутки. Если сбой произошел сразу по успешному завершению резервного копирования - то вы ничего не потеряли.

Важно! Для RPO, если бизнес поставил значение, резервное копирование должно производится не реже этого значения!

То же касается и RTO. Если указано значение, а вы восстановили доступность сервиса/данных раньше - хорошо, соблюли бизнес-требование. Если потратили больше - не хорошо.

В идеале оба значения нужно привести к нулю. Тогда система превратиться в неваляшку и будет восстанавливаться в момент сбоя с сохранением всех данных.
Но, как вы понимаете, это утопия. В реальной жизни эти два фактора объединяются с третьим немаловажным - финансовым. И стоимость решения будет расти экспоненциально при попытке приблизить значения RTO и RPO к нулю.


Продолжение...