RTO и RPO. часть 3

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

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

Несколько комментариев к графику:
  • Здесь всё изображено схематично. На самом деле нет четких граней между решениями и точных значений.
    Например, сейчас много решений по резервному копированию используют технологию запуска сервиса из резервной копии (аналогичную Veeam Instant VM Recovery). Время обеспечения доступности при использовании такой технологии в среднем ~2-5 минут на одну ВМ. И такие показатели находятся в рамках RTO для реплик или даже кластеров.
  • Да, кластеры, как и DR-решения, и вообще практически все решения по защите от потерь данных или восстановлению работоспособности имеют свои значения по скорости восстановления данных и объемам данных, которые теряются. Потому они также связаны со своими показателями RTO/RPO.
    Говоря, например, про HA-кластер (HA - High Availability), его RTO равно времени переключения. Допустим, MSCS для двух нод переключает СУБД за 30 секунд? Значит, целевое RTO, которое может быть обеспечено этим видом кластера от 30 секунд.
    А если VMware HA отработает за 2 минуты (с учетом старта виртуальной машины, ее гостевой ОС и приложений). То такое решение подходит для приложений с целевым значением RTO от 2 минут.
    Где потери для HA-кластера (и соответственно обеспечение RPO), спросите вы? Когда сервис поднимается есть вероятность небольших потерь данных. Например, СУБД проверит состояние базы данных, и может откатить своё состояние на некорректно проведенную транзакцию. А файловая система вернется к корректно сохраненной версии файла и т.п.
  • Вывод из предыдущего комментария. Не всегда стоит строить одинаковые решения одно поверх другого. Например, HA над HA. Это только излишне усложнит инфраструктуру, усложнит (и удорожает) поддержку работы таких систем.
    К предыдущем примерам двух HA. Определите, какое реальное значение RTO необходимо обеспечить для приложения? Для значений больше 2 минут нет смысла стоить еще и HA-кластер для сервисов внутри ВМ.
    Но...
  • Но разные системы обеспечения доступности могут решать различные проблемы, закрывать различные риски (про рискменеджмент надо будет написать отдельно). И даже разные кластеры могут закрывать различные потенциальные проблемы и также дополнять друг друга.
    К примеру, резервное копирование почтового сервера не исключает, но дополняет использование кластера HA для почтовых серверов. Кластер защищает от выхода из строя физического сервера, и обеспечивает быстрое переключение на резервный сервер. Но кластер не защищает от потери данных (нежелательного удаленных данных, невозможности запуска ВМ после сбоя оборудования и т.п.). Для этого необходимо применение резервного копирования.
    И сами кластеры тоже могут быть призваны для защиты от различных сбоев, и дополнять друг друга. К примеру, Micosoft Exchange. DAG-кластер (по сути - HA) обеспечивает не только защиту от выхода из строя одной из вычислительных нод кластера (самого сервера), но и при выходе из строя диска сервера. За счет того, что данные дублируются на других нодах.
    Что при этом дает совместное использование VMware vSphere HA? Быстрое восстановление уровня защиты. Если просто выключился один сервер с одной нодой MS Exchange, то вначале отработает DAG, переключив сервисы на другую ноду, а затем HA VMware загрузит сбойный сервер на другом плече своего кластера. И система готова к повторным сбоям.     (Хотя в этом примере я бы рассматривал применение виртуализации не только для одной функции только кластера, но и для всех остальных преимуществ самой платформы).
    Так что совокупное применение различных решений - благо. Главное подходить с умом, и понимать для чего какое решение применяется.
  • Еще на графике выше я отметил решения по архивированию. Обратите внимание, про архивы не имеет смысл рассматривать RTO, так как применяются такие решения для восстановления старых исторических данных. Т.е. речь идет про глубину и долгосрочность хранения данных не используемых для текущей операционной деятельности компании. Необходимо обеспечение RPO для исторических данных.

И еще раз про RTO и RPO

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

Нельзя сказать, что RTO функции Instant Recovery - 2 минуты.
Нельзя считать, что резервное копирование раз в сутки - это и есть RPO 24 часа.
Всё идет в обратную сторону:
Для определенного сервиса, в случае сбоя обслуживающей этот сервис системы, необходимо обеспечить восстановление, не допустив простоя в работе этого сервиса более 5 минут (RTO - 5 минут). Значит подойдет решение, которое позволит сделать систему доступной за срок менее 5 минут.
Или же.
Для базы данных, в случае сбоя СУБД, нужно обеспечить восстановление с потерей данных сроком не более 24 часов от момента сбоя. Значит подойдет решение, которое обеспечит гарантированное восстановление базы из точек восстановления, производимых чаще чем 1 раз в сутки. При этом, отмечу, что резервное копирование раз в час, создающее 24 точки восстановления, дает больше гарантий восстановления, чем копирование раз в сутки, делающее только 1 точку.

Расширенный пример:
Бизнес говорит, что "это очень важный критический сервис, и если он будет простаивать больше 5 минут - будут N-финансовые потери, а через 30 минут простоя - в 10 раз больше. И это уже не приемлемо для компании."
Ваши рассуждения:
"Применение функции Instant Recovery обеспечит технический процесс восстановления в 2 минуты..." 
Но!
При этом надо понимать еще несколько моментов. Нам, прежде всего, необходимо отследить момент возникновения сбоя. Определить произошедшие последствия от сбоя: всё сломалось или что-то доступно. Желательно найти причины возникновения сбоя, или хотя бы локализовать (изолировать) проблему: если пожар - потушить его прежде чем пытаться восстановить в ту же инфраструктуру; если вирус портит данные - отключить от сети зараженный сервер, а не кормить вирус восстановленным сервером. Далее определить способы реанимации (наиболее подходящую процедуру восстановления: перегрузить ВМ, дождаться переключения кластера на другую ноду, или восстановить из резервной копии). Принять решение по восстановлению и произвести действия для запуска восстановления.
Это все влияет на общее время восстановления.
Потому рассуждаем дальше:
"У меня есть мониторинг для этого сервиса, и оповещение сработает и будет замечено за минуту-две (телефон с полученной СМС надо из кармана достать, или почтовый клиент с новым письмом надо открыть).Я (а лучше - специально нанятый для обслуживания и поддержки этого сервиса человек - раз сервис настолько критичен) сяду за компьютер, пингану сервис, попытаюсь открыть на нем консоль, посмотрю что там с гипервизором и железом. Проведу первичную реанимацию (попробую перегрузить машину). На все это я потрачу порядка 15 минут.Если не помогут действия по быстрой реанимации - восстановлюсь из резервной копии. Но так как копироваться из бэкапа данные будут еще минут 15-20, то я воспользуюсь Instant VM Recovery за 2 минуты, а затем запущу онлайн перенос данных машины в продуктив."Как видим по рассуждениям в 5 минут не укладываемся с большой вероятностью. Нужен HA-кластер со временем восстановления 2 минуты. Но он не обеспечит нам защиту от всех типов сбоев. Рестарт машины в BSoD вполне вероятен, диск ВМ - тоже точка отказа, и т.п. Нужна дополнительная защита. Значит:
"В случае кластера я восстановлюсь за 2 минуты.А в дополнение 2+15+2=19 минут я потрачу при восстановлении из резервной копии, при этом 11 минут ещё остаются в запасе." 
Ваш ответ бизнес-владельцу ИС:
"ОК. Я обеспечу RTO в 30 минут.Я включу этот сервис в кластер для обеспечения 5 минутного RTO, и настрою резервное копирование для защиты от сбоев с более серьёзными последствиями."
Хотя последнее дополнение можно и не озвучивать бизнесу. Он требует 30 минут (при желательных 5) - вы ему обеспечиваете это.

И самый главный совет! После того как вы согласовали с владельцем ИС конкретные целевые показатели, договорились:
Важно! Фиксируйте ваши договоренности с владельцами ИС в письменном виде!
Подписывайте с ним SLA!!!

Почему называем "доступностью"?

Заметили, что я пишу постоянно "восстановление данных и восстановление работоспособности сервиса". Чаще всего пишу вместе, через запятую. Это две связанные между собой вещи, которые почти всегда не могу жить друг без друга. Мы восстановили работу сервиса, но при этом потеряли все его данные - это неприемлемо. Мы восстановили БД, но СУБД не запускается, прочитать данные не могут - это неприемлемо.
Именно поэтому мы говорим о доступность и данных, и сервисов. Важны и RPO, и RTO - в совокупности они обеспечивают доступность и того, и другого параметра.
После сбоя через 15 минут восстановлен доступ к сервису с данными за весь предыдущий период работы до 1 часа включительно - это всё - про общую доступность.

Вот такой вот дуализм ;)

И вместе дуальная пара RTO и RPO являются важным показателем в соглашении об уровне обслуживания (Service Level Agreement, или SLA) для конкретной ИС в части обеспечения доступности её сервисов и данных в случае возникновения сбоя.
А подписывается соответствующее соглашение между владельцем ИС (заказчиком услуги), и вами, ИТ-отделом (поставщиком услуги). О чём я и писал выше в качестве важного совета.


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

Например, сбой - выход из строя одной из нод DAG-кластера MS Exchange - отказоустойчивое к потерям данных (RPO=0) решение для данных типов сбоев: выключили сервер, сломался физический сервер, отключили его питание и прочие проблемы. Но для RTO данное решение к отказам не устойчиво.
Или же VMware Faut Taulerance - отказоустойчивое решение с RTO=0 и RPO=0 для сбоев, связанных с оборудованием. Но от сбоя, возникнувшего в случае вирусной атаки на приложение внутри ВМ, данное решение не защитит.



Автор: в
Ярлыки: , , , ,

Комментариев нет:

Отправить комментарий

Подписаться на: Комментарии к сообщению (Atom)