Сегодня я попытаюсь объяснить, что такое понятие доступности данных с точки зрения ИТ-специалиста, будь то ИТ-администратор, системный интегратор, консультант по внедрению и т. д. Надеюсь, что эта статья будет полезна читателям при составлении экономическое обоснование внедрения соответствующих программных и/или аппаратных решений, а также соглашений об уровне обслуживания (SLA) – и поможет кому-то другому составить эти документы более убедительно .
Для начала в качестве «узлов для памяти» сформулирую два постулата, с которыми многие, я уверен, вполне знакомы:
- РПО (цель точки восстановления) – допустимая потеря данных.
Любая информационная система должна обеспечивать (как внутренними средствами, так и сторонними) защиту своих данных от потери выше допустимого уровня.
- РТО (recovery time Objective) – приемлемое время восстановления данных.
Любая информационная система должна обеспечивать (внутренними или сторонними средствами) возможность восстановления своей работоспособности в течение приемлемого времени.
Но в такой одномерной схеме нет самого главного, на чем фокусируется бизнес – денег! Ниже я расскажу, как рассчитать RTO и RPO исходя из бизнес-требований.
Начнем «от печки», то есть с прямой по оси времени, где:
- Точка события отмечает сбой системы
- Слева от этой точки (то есть в прошлое) отмечается целевое значение RPO.
- Справа (т.е.
в будущем) отмечается целевое значение RTO.
) 
Понятно, что все системы в компании работают не просто так, но для разных нужд/целей.
Компания сама зарабатывает (и тратит) деньги.
Если система даст сбой, компания, очевидно, потеряет деньги.
Показатели RTO и RPO указывают на приемлемый размер этих потерь.
Поэтому в схему вводится второе измерение – финансовое (вот они, деньги – $): 
Из этого графика уже видно, что стоимость простоя сервиса со временем увеличивается: чем дольше система не работает, тем больше денег теряет компания.
То же самое относится и к стоимости потери данных: чем больше данных мы теряем (в исторической перспективе), тем дороже такая потеря будет стоить компании.
И да, эти графики в живой природе не симметричны.
Как правило, эти значения не изменяются линейно, что отражено на рисунке.
Чаще всего наступает момент, когда стоимость потери начинает резко возрастать – отсюда и та самая грустные истории , когда компании потеряли настолько много из-за системного сбоя, что некоторые даже не смогли вернуться в бизнес.
Для защиты от таких проблем необходимо внедрить систему, которая обеспечит защиту от потери данных и аварийное восстановление.
Такие системы имеют свои издержки, а значит, их тоже можно отразить на графике (нарисуем их синим цветом): 
Как видно из графика, чем ниже показатели RPO и RTO при потере данных, тем меньше простоев сервиса обеспечивает решение защиты, тем дороже такая защита.
Определим точку безубыточности защитного решения
И вот мы видим на графике пересечение кривых — эти точки я отметил зелеными стрелками.Это так называемые точки безубыточности системы защиты и защищаемой информационной системы.
Отойдя от этой точки, мы получаем дорогую систему защиты, стоимость которой превышает стоимость потерь/простоев, или наоборот – дешевую систему защиты, но не обеспечивающую приемлемый уровень потерь.
Кажется, вывод напрашивается сам собой: именно ориентируясь на точки безубыточности, нам необходимо подбирать системы, которые обеспечат нам необходимую защиту.
На самом деле, если построить такие графики на основе реальных данных, мы получим несколько иную картину.
В частности, график стоимости решения защиты будет выглядеть не сплошной линией, а набором точек.
Различные решения безопасности не выстраиваются вплотную друг за другом на графике, а представляют собой отдельные точки, поскольку каждое имеет свои «координаты»: стоимость (указанную вендором-производителем этого решения) и время, необходимое для реализации этого решения.
обеспечить соответствующие потери данных (RPO) и скорость восстановления.
(РТО).
При этом, как правило, ищут решение для защиты не одной конкретной информационной системы (ИС), а группы (или вообще всех) информационных систем компании (то есть всей инфраструктуры).
Более того, каждое такое решение, скорее всего, будет иметь свои графики зависимости стоимости простоя/потери данных от времени.
Получается, что наши точки безубыточности — это уже не точки, а области: 
Если мы присмотримся к нашей инфраструктуре и начнем строить графики для каждой ИС, то увидим интересную тенденцию — системы группируются со схожими.
Подробнее об этом ниже.
Мы рассматриваем разные классы решений
Обратите внимание, до сих пор я говорил о «защите», но не уточнил, какая это защита: резервная, кластерная, какие-то другие виды защиты? Здесь стоит сказать, что системы защиты бывают разные, и их можно классифицировать.
На диаграмме ниже примерно показано, какой класс решения рекомендуется выбрать в зависимости от целевого RTO/RPO. 
Конечно, на картинке все показано довольно схематично.
На самом деле четких границ между типами решений нет, как и точных значений в виде баллов.
Например, сейчас многие решения для резервного копирования используют технологию запуска сервиса из резервной копии.
Время обеспечения доступности при использовании этой технологии составляет в среднем ~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 функции Instant Recovery составляет 2 минуты.
Не могу посчитать такое резервное копирование один раз в день составляет RPO 24 часа.
Все идет в обратную сторону, то есть от бизнеса, а конкретно для МРК будет объявлено так:
Для определенного сервиса в случае отказа системы, обслуживающей этот сервис, необходимо обеспечить восстановление, не допуская простоя в работе этого сервиса более 5 минут (RTO - 5 минут).Или для РПО:Это означает, что подойдет решение, которое сделает систему доступной менее чем за 5 минут.
Для базы данных в случае сбоя СУБД необходимо обеспечить восстановление с допустимой потерей данных на срок не более 24 часов с момента сбоя.Значит, подойдет решение, которое обеспечит гарантированное восстановление базы данных из точек восстановления, выполняемое чаще, чем раз в сутки.
При этом отмечу, что резервное копирование раз в час, создающее 24 точки восстановления, дает больше гарантий восстановления, чем копирование раз в день, составляющее всего 1 точку.
А вот практический пример
Допустим, компания говорит следующее: «Это очень важный, критичный сервис, и если он простаивает более 5 минут, -финансовые потери произойдут, а после 30 минут простоя - в 10 раз больше! И это уже неприемлемо для компании».Казалось бы, можно рассуждать так:
«Использование функции Instant Recovery обеспечит процесс технического восстановления за 2 минуты.Но! При этом нужно понимать еще несколько моментов:»
- Прежде всего, нам необходимо отследить момент возникновения сбоя.
- Определите последствия сбоя: все сломано или что-то доступно.
- Целесообразно найти причины сбоя или хотя бы локализовать (изолировать) проблему: если возник пожар, потушить его, прежде чем пытаться что-либо восстановить в той же инфраструктуре; если вирус повреждает данные, отключите зараженный сервер от сети, а не передавайте вирус на восстановленный сервер.
- Далее определитесь со способами восстановления (наиболее подходящий порядок восстановления: перезагрузить ВМ, дождаться переключения кластера на другой узел или восстановить из резервной копии).
- Примите решение о восстановлении и фактически начните восстановление.
Поэтому обсуждаем дальше:
«У меня настроен мониторинг для этого сервиса, и оповещение сработает и будет замечено через минуту-две (нужно достать из кармана телефон с полученной СМС, либо открыть почтовый клиент с помощью Новое письмо).Как видите, за 5 минут мы вряд ли справимся.Я сяду за компьютер, пропингую сервис, попробую открыть на нем консоль и посмотрю, что происходит с гипервизором и железом.
Проведу первичную реанимацию (попробую перезагрузить аппарат).
На всё это я потрачу около 15 минут. Если быстрые шаги по реанимации не помогут, восстановлю из резервной копии.
Но так как данные будут копироваться из резервной копии еще 15-20 минут, я воспользуюсь Instant VM Recovery за 2 минуты, а затем начну онлайн-перенос данных машины в продакшен».
Теперь давайте подумаем, возможно, нам нужен HA-кластер со временем восстановления 2 минуты? Но это не обеспечит нам защиту от всех типов сбоев: перезагрузка машины в BSoD вполне вероятна, диск ВМ тоже является точкой отказа и т. д. Поэтому нужна дополнительная защита.
Итак, продолжим наши рассуждения:
«В случае кластера я восстановлюсь за 2 минуты.В результате ваш ответ владельцу бизнес-IP будет таким:И кроме того, я потрачу, как я уже прикинул, 15+2 минуты при восстановлении из резервной копии, всего 2+15+2=19 минут, а в запасе еще останется 11 минут».
«ОК.Очень важно! Самый главный совет: после того, как вы согласовали с владельцем ИС конкретные задачи и договорились — обязательно зафиксируйте свои договоренности с ним в письменной форме, подпишите с ним соглашение об уровне обслуживания (SLA).Я предоставлю RTO за 30 минут. Я включу этот сервис в кластер, чтобы обеспечить 5-минутное RTO, и настрою резервное копирование для защиты от сбоев с более серьезными последствиями».
Почему мы называем это «концепцией доступности»?
Вы заметили, что я постоянно пишу «восстановление данных и восстановление сервисов»? Чаще всего пишу слитно, в одном предложении.Это две взаимосвязанные вещи, которые я почти всегда не могу жить друг без друга.
Мы восстановили сервис, но при этом потеряли все его данные – это недопустимо.
Мы восстановили базу данных, но СУБД не запускается, не может прочитать данные — это недопустимо.
Именно поэтому мы говорим о доступности как данных, так и услуг.
И RPO, и RTO важны — вместе они обеспечивают доступность оба.
Через 15 минут после сбоя доступ к сервису был восстановлен с данными за весь предыдущий период работы (до 1 часа включительно) – это все об общей доступности.Вот такой дуализм ;) Вместе двойная пара RTO и RPO является важным индикатором в одном и том же направлении.
соглашение об уровне обслуживания ( Соглашение об уровне обслуживания , или Соглашение об уровне обслуживания ) для конкретной ИС в части обеспечения доступности ее сервисов и данных в случае сбоя.
И соответствующий договор подписывается, как я уже сказал выше, между владельцем ИП (заказчиком услуги) и вами, ИТ-подразделением (поставщиком услуги).
Ссылки по теме:
- Важность тестирования резервных копий.
- Подробнее о деньгах (о бизнесе, непрерывности бизнеса и о том, как все это сочетается с RTO/RPO)
-
Перегрев Xbox 360 – Как Этого Избежать
19 Oct, 24 -
Игра World Of Tanks — Сложное Приложение
19 Oct, 24 -
Банк «Открытие» Купил Рокетбанк
19 Oct, 24 -
Шпионские Гаджеты 007 Или Выбор Бонда
19 Oct, 24 -
Про2. Перезагрузить
19 Oct, 24 -
Adwords И Старые Аккаунты
19 Oct, 24
