Что такое rto и rpo
Обеспечение доступности данных и сервисов: показатели RPO, RTO и планирование SLA
Сегодня я постараюсь разъяснить, что такое концепция доступности данных с точки зрения ИТ-специалиста, будь то ИТ-администратор, системный интегратор, консультант по внедрению и т.д. Надеюсь, что эта статья будет полезна читателям при составлении экономического обоснования на внедрение соответствующих программных и\или аппаратных решений, а также соглашений об уровне обслуживания (SLA) – а кому-то поможет сделать эти документы более убедительными.
Для начала в качестве «узелков на память» сформулирую два постулата, с которыми многие, уверен, довольно хорошо знакомы:
Начнем «от печки», то есть с прямой линии вдоль оси времени, где:
Ясно, что все системы в компании работают не просто так, а для различных нужд/целей. Сама же компания зарабатывает (и тратит) деньги. В случае сбоя системы компания, очевидно, деньги теряет. Показатели RTO и RPO – то, что говорит о приемлемых размерах этих потерь.
Из такого графика уже видно, что стоимость простоя сервиса растет со временем: чем дольше не работает система, тем больше денег теряет компания.
Тоже самое и со стоимостью потерь данных: чем больше мы их (в исторической перспективе) теряем, тем дороже такая потеря обойдется компании. И да, эти графики в живой природе не симметричны.
Как правило, эти стоимости меняются не линейно, что отражено на картинке. Чаще всего наступает момент, когда стоимость потери начинает резко возрастать – отсюда и те самые печальные истории, когда компании теряли так много от сбоя системы, что некоторые даже не смогли вернуться в бизнес.
Чтобы защититься от таких проблем, необходимо внедрить систему, которая будет обеспечивать защиту от потерь данных и восстановление после сбоев. Такие системы имеют свои стоимости, и, значит, их тоже можно отразить на графике (нарисуем их синим):
Как видно из графика, чем меньше показатели RPO и RTO при потере данных, чем меньшее время простоя сервиса обеспечивает решение по защите, тем дороже такая защита стоит.
Определим точки безубыточности решения по защите
И тут мы наблюдаем пересечение кривых на графике – я отметил эти точки зелеными стрелками. Это так называемые точки безубыточности для системы защиты и для защищаемой информационной системы. Отдаляясь от данной точки, мы получаем дорогую систему защиты, стоимость которой превышает стоимость потери/простоя, либо наоборот – дешевую систему защиты, но не обеспечивающую приемлемый уровень потерь.
Как кажется, вывод напрашивается сам собой: именно ориентируясь на точки безубыточности, и надо подбирать системы, которые обеспечат нам необходимую защиту.
На самом деле, если мы построим такие графики, ориентируясь на данные из реальной жизни, то получим несколько иную картину. В частности, график стоимости решения по защите будет иметь вид не сплошной линии, а множества точек. Различные защитные решения не выстраиваются вплотную друг за другом вдоль графика, а представляют собой отдельные точки, ведь каждое имеет свои «координаты»: стоимость (обозначенная вендором-производителем данного решения) и время обеспечения этим решением соответствующих потерь данных (RPO) и скорости восстановления работоспособности (RTO).
К тому же, как правило, ищется решение по защите не одной конкретной информационной системы (ИС), а группы (или вообще всех) инфосистем компании (то есть всей инфраструктуры). При этом каждое такое решение, скорее всего, будет иметь свои графики зависимостей стоимости простоя/потери данных от времени.
Получается, что наши точки безубыточности – уже не точки, а области:
Если мы рассмотрим нашу инфраструктуру более пристально и начнем строить графики для каждой ИС, то мы увидим интересную тенденцию — системы группируются со схожими. Об этом ниже.
Рассматриваем различные классы решений
Обратите внимание, до сего момента я говорил про «защиту», но не оговаривал, что это за защита конкретно: резервное копирование, кластер, какие-то еще виды защиты? Тут стоит сказать, что системы защиты бывают разные, и их можно классифицировать.
На схеме ниже видно, какой примерно класс решения в зависимости от целевых 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 для почтовых серверов. Кластер защищает от выхода из строя физического сервера и обеспечивает быстрое переключение на резервный сервер. Но кластер не защищает от потери данных (нежелательного удаленных данных, невозможности запуска ВМ после сбоя оборудования и т.п.). Для этого необходимо применение резервного копирования.
Что при этом дает совместное использование VMware vSphere HA? Быстрое восстановление уровня защиты. Если просто выключился один сервер с одной нодой MS Exchange, то вначале отработает DAG, переключив сервисы на другую ноду, а затем HA VMware загрузит сбойный сервер на другом плече своего кластера. И система готова к работе. (Хотя в этом примере я бы рассматривал применение виртуализации не только для одной функции только кластера, но и для всех остальных преимуществ самой платформы).
Говорим и пишем правильно! Или еще раз про RTO и RPO
Хочу сделать на этом акцент, поскольку я сам периодически совершаю ошибку, потому и остерегаю от этого вас:
RTO ≠ скорость восстановления!
RPO ≠ количество потерянных данных!
RTO и RPO – это целевые значения для информационных систем (ИС), максимальные рамки, в которые мы должны уложиться. И эти целевые значения нам, ИТ-специалистам, сообщает бизнес, точнее, бизнес-владельцы соответствующей ИС, но не наоборот.
То есть:
Нельзя сказать, что RTO функции Instant Recovery – 2 минуты.
Нельзя считать, что резервное копирование раз в сутки и есть RPO 24 часа.
Всё идет в обратную сторону, то есть от бизнеса, и конкретно для RTO будет озвучиваться так:
Для определенного сервиса, в случае сбоя обслуживающей этот сервис системы, необходимо обеспечить восстановление, не допустив простоя в работе этого сервиса более 5 минут (RTO – 5 минут). Значит, подойдет решение, которое позволит сделать систему доступной за срок менее 5 минут.
Для базы данных, в случае сбоя СУБД, нужно обеспечить восстановление с допустимой потерей данных сроком не более 24 часов от момента сбоя. Значит, подойдет решение, которое обеспечит гарантированное восстановление базы из точек восстановления, производимых чаще, чем 1 раз в сутки. При этом отмечу, что резервное копирование раз в час, создающее 24 точки восстановления, дает больше гарантий восстановления, чем копирование раз в сутки, делающее только 1 точку.
А вот и практический пример
Казалось бы, можно рассуждать так:
«Применение функции Instant Recovery обеспечит технический процесс восстановления в 2 минуты. »
Но! При этом надо понимать еще несколько моментов:
Поэтому рассуждаем дальше:
«У меня настроен мониторинг для этого сервиса, и оповещение сработает и будет замечено за минуту-две (телефон с полученной СМС надо из кармана достать, или почтовый клиент с новым письмом надо открыть). Я сяду за компьютер, пингану сервис, попытаюсь открыть на нем консоль, посмотрю, что там с гипервизором и железом. Проведу первичную реанимацию (попробую перегрузить машину). На все это я потрачу порядка 15 минут. Если не помогут действия по быстрой реанимации — восстановлюсь из резервной копии. Но так как копироваться из бэкапа данные будут еще минут 15-20, то я воспользуюсь Instant VM Recovery за 2 минуты, а затем запущу онлайн перенос данных машины в продакшен.»
Как видим, в 5 минут мы вряд ли укладываемся.
Теперь подумаем, возможно, нужен HA-кластер со временем восстановления 2 минуты? Но и он не обеспечит нам защиту от всех типов сбоев: рестарт машины в BSoD вполне вероятен, диск ВМ — тоже точка отказа, и т.п. Следовательно нужна дополнительная защита. Значит, продолжаем наши рассуждения:
«В случае кластера я восстановлюсь за 2 минуты. А в дополнение я потрачу, как уже прикинул(а), 15+2 минут при восстановлении из резервной копии, всего 2+15+2=19 минут, и 11 минут ещё остаются в запасе.»
В итоге, ваш ответ бизнес-владельцу ИС будет таким:
«ОК. Я обеспечу RTO в 30 минут. Я включу этот сервис в кластер — для обеспечения 5 минутного RTO, и настрою резервное копирование — для защиты от сбоев с более серьёзными последствиями.»
Очень важно! Самый главный совет: после того, как вы согласовали с владельцем ИС конкретные целевые показатели, договорились – обязательно фиксируйте ваши договоренности с ним в письменном виде, подписывайте с ним соглашение об уровне обслуживания (SLA).
Почему мы называем это «концепцией доступности»?
Заметили, что я пишу постоянно «восстановление данных и восстановление работоспособности сервиса»? Чаще всего пишу вместе, в одном предложении. Это две связанные между собой вещи, которые почти всегда не могу жить друг без друга.
Мы восстановили работу сервиса, но при этом потеряли все его данные – это неприемлемо. Мы восстановили БД, но СУБД не запускается, прочитать данные не могут – это неприемлемо. Именно поэтому мы говорим о доступности и данных, и сервисов. Важны и RPO, и RTO – в совокупности они обеспечивают доступность и того, и другого.
Через 15 минут после сбоя восстановлен доступ к сервису с данными за весь предыдущий период работы (до 1 часа включительно) – это всё про общую доступность.
Вот такой вот дуализм 😉 Вместе дуальная пара RTO и RPO является важным показателем в том самом соглашении об уровне обслуживания (Service Level Agreement, или SLA) для конкретной ИС в части обеспечения доступности её сервисов и данных в случае возникновения сбоя. А подписывается соответствующее соглашение, как я говорил выше, между владельцем ИС (заказчиком услуги), и вами, ИТ-отделом (поставщиком услуги).
Олонцев Сергей
Блог об обработке и анализе данных
Что такое RPO и RTO
В этой статье я бы хотел подробно остановиться на двух магических показателях, с которыми необходимо определиться до того, как планировать резервное копирование и восстановление не только баз данных Microsoft SQL Server, но и любых других хранилищ информации. Не понимая и не зная этих двух чисел, вы рискуете неправильно оценить риски для бизнеса и составить неверный план восстановления.
Итак, RPO (recovery point objective) это максимальный период времени, за который могут быть потеряны данные в результате инцидента. Например, у нас имеется информационная система и RPO для нее мы определили в 1 час. Это значит, что, если вдруг происходит авария, мы готовы к тому, что систему удастся восстановить, но в ней будут потеряны данные не более, чем за последний час. Количество потерянных данных может быть меньше, если нам повезет, но не более 1 часа. Этот показатель говорит нам о том, как часто мы должны делать резервные копии нашей системы, и какие технологии применять, чтобы удержать этот показатель. Может ли он быть ноль? Теоретически да, но на практике организовать это очень сложно. Это можно организовать, только, если запись идет как минимум в 2 разных хранилища. Использование AlwaysOn Availability Groups или Database Mirroring вам не поможет, т.к. эти технологии не спасут от случайного удаления таблицы.
RTO (recovery time objective) это промежуток времени, в течение которого система может оставаться недоступной в случае аварии. Например, в центре обработки данных произошел пожар, но мы хотим, чтобы система была снова доступна для работы через 2 часа. Это и есть наш RTO. Мы должны планировать так, чтобы за этот промежуток восстановить работоспособность информационной системы на резервном оборудовании или площадке. Это можно реализовать с помощью различных технологий отказоустойчивости или же простым восстановлением из резервных копий на другой сервер. В любом случае мы должны обеспечить этот показатель при инциденте.
Кто определяет эти числа? В идеале, их вам должен сказать владелец сервисов. Обычно это представитель бизнеса, который редко знает, что это за показатели. Ваша задача состоит в том, чтобы совместно с ним прийти к итоговому решению, т.к. чем меньше эти показатели, тем больше ресурсов потребуется, чтобы их обеспечить. Например, для тестовой базы данных не нужен показатель RPO в 1 минуту, т.к. они, скорее всего, готовы потерять все данные целиком и просто повторно их сгенерировать. А вот RTO для них может быть критичен, т.к. в случае недоступности, несколько человек не смогут работать какое-то время. В то же время не надо переусердствовать, обеспечивая очень маленький показатель, т.к. затраты на его поддержку могут легко превысить оплату труда простаивающих специалистов. В то же время для основных баз данных эти показатели будут играть большую роль, т.к. от них будет зависеть доход и репутация компании.
Что такое RPO и RTO
В этой статье я бы хотел подробно остановиться на двух магических показателях, с которыми необходимо определиться до того, как планировать резервное копирование и восстановление не только баз данных Microsoft SQL Server, но и любых других хранилищ информации. Не понимая и не зная этих двух чисел, вы рискуете неправильно оценить риски для бизнеса и составить неверный план восстановления.
Итак, RPO (recovery point objective) это максимальный период времени, за который могут быть потеряны данные в результате инцидента. Например, у нас имеется информационная система и RPO для нее мы определили в 1 час. Это значит, что, если вдруг происходит авария, мы готовы к тому, что систему удастся восстановить, но в ней будут потеряны данные не более, чем за последний час. Количество потерянных данных может быть меньше, если нам повезет, но не более 1 часа. Этот показатель говорит нам о том, как часто мы должны делать резервные копии нашей системы, и какие технологии применять, чтобы удержать этот показатель. Может ли он быть ноль? Теоретически да, но на практике организовать это очень сложно. Это можно организовать, только, если запись идет как минимум в 2 разных хранилища. Использование AlwaysOn Availability Groups или Database Mirroring вам не поможет, т.к. эти технологии не спасут от случайного удаления таблицы.
RTO (recovery time objective) это промежуток времени, в течение которого система может оставаться недоступной в случае аварии. Например, в центре обработки данных произошел пожар, но мы хотим, чтобы система была снова доступна для работы через 2 часа. Это и есть наш RTO. Мы должны планировать так, чтобы за этот промежуток восстановить работоспособность информационной системы на резервном оборудовании или площадке. Это можно реализовать с помощью различных технологий отказоустойчивости или же простым восстановлением из резервных копий на другой сервер. В любом случае мы должны обеспечить этот показатель при инциденте.
Кто определяет эти числа? В идеале, их вам должен сказать владелец сервисов. Обычно это представитель бизнеса, который редко знает, что это за показатели. Ваша задача состоит в том, чтобы совместно с ним прийти к итоговому решению, т.к. чем меньше эти показатели, тем больше ресурсов потребуется, чтобы их обеспечить. Например, для тестовой базы данных не нужен показатель RPO в 1 минуту, т.к. они, скорее всего, готовы потерять все данные целиком и просто повторно их сгенерировать. А вот RTO для них может быть критичен, т.к. в случае недоступности, несколько человек не смогут работать какое-то время. В то же время не надо переусердствовать, обеспечивая очень маленький показатель, т.к. затраты на его поддержку могут легко превысить оплату труда простаивающих специалистов. В то же время для основных баз данных эти показатели будут играть большую роль, т.к. от них будет зависеть доход и репутация компании.
Раскрываем тайны целевых показателей восстановления
В современных организациях простои недопустимы: необходимо соответствовать требованиям и ожиданиям клиентов. Однако различные типы инцидентов могут нанести вашей компании финансовый ущерб и даже поставить под угрозу ее существование. Атаки программ-вымогателей, отключения электроэнергии, наводнения и просто человеческие ошибки — все эти события невозможно предсказать, поэтому нужно просто БЫТЬ К НИМ ГОТОВЫМИ.
Готовность означает, что необходимо разработать надежный план обеспечения непрерывности бизнес-процессов и послеаварийного восстановления (план BCDR). Этот план необходимо протестировать и убедиться, что его легко реализовать.
Два важных параметра, которые характеризуют план BCDR, — целевая точка восстановления (RPO) и целевое время восстановления (RTO). Для тех, кто еще не знаком с этими терминами, приведу их краткое определение:
RPO и RTO называются очень похоже, но они нужны для разных целей. В идеальной ситуации оба эти показателя должны быть максимально близки к нулю. Однако в реальной жизни затраты на достижение нулевых RPO и RTO будут очень высоки и, возможно, не окупятся.
Давайте рассмотрим целевые показатели восстановления подробнее. RPO определяет, каковы допустимые потери данных, чтобы это не повлияло на работу компании. Например, для банковской системы, работающей в режиме реального времени, потеря данных за 1 час может стать катастрофой. Чтобы вам проще было понять, что такое RPO, представьте себе, что это момент, когда вы последний раз сохраняли документ, над которым работаете. Если произойдет сбой в работе системы и все сделанные изменения пропадут, какой объем проделанной работы вы готовы безболезненно потерять?
Что касается RTO, это промежуток времени, в течение которого необходимо восстановить работу приложений и систем после аварии. Начинать отсчет RTO нужно с момента аварии, а не с момента, когда ИТ-отдел приступает к ее устранению. Это более практичный подход, поскольку он учитывает именно ту точку, когда пользователи сталкиваются с проблемой.
Определение показателей RTO и RPO для приложений
Нужно понимать, что универсального плана обеспечения непрерывности бизнеса и универсальных значений показателей не существует. Компании в разных отраслях устроены и работают по-разному, их потребности различаются, следовательно, различаются и требования к целевым показателям восстановления. Однако в общем случае принято делить приложения и сервисы на уровни. После этого можно устанавливать целевые показатели времени восстановления и точки восстановления (RTPO) в соответствии с соглашениями о гарантированном уровне обслуживания (SLA), действующими в конкретной организации.
Классификация данных по уровню необходимой защиты позволяет определить, как эффективно хранить, защищать, восстанавливать и обновлять данные и информацию, а также обеспечивать к ним доступ в зависимости от их характеристик. Главное — проанализировать имеющиеся приложения и понять, какие из них в первую очередь важны для развития бизнеса и получения прибыли и поэтому должны работать бесперебойно. Этот процесс называется анализом воздействия на бизнес (BIA). Он имеет ключевое значение для подготовки надежного плана обеспечения непрерывности бизнеса, позволяя определить необходимые протоколы и действия для устранения последствий аварий.
Например, при создании плана обеспечения непрерывности бизнеса можно разделить приложения на три уровня:
Важно помнить, что распределение приложений по трем уровням будет различаться в разных отраслях, каждая организация самостоятельно определяет важность тех или иных приложений в зависимости от особенностей работы и требований.
Распределив приложения и сервисы по уровням и понимая, какие последствия ждут вас в случае тех или иных аварий, нужно найти решение, которое поможет защитить данные и работу компании. Veeam Availability Platform — комплексный набор инструментов, который позволяет достичь минимальных целевых показателей восстановления данных виртуальных, физических и облачных систем.
Обеспечение RTO и RPO на практике
Быстрое восстановление объектов приложений
Представитель отдела продаж удалил сообщение электронной почты, которое нужно срочно отправить заказчику. Microsoft Exchange относится к приложениям 2 уровня. Поскольку у ИТ-администратора запланированы задания резервного копирования в течение дня, компании нетрудно достичь показателя RPO, равного 1 часу. С помощью Veeam Explorer for Microsoft Exchange, который входит во все версии Veeam Backup & Replication, очень просто восстановить отдельное сообщение электронной почты за несколько минут и даже секунд. При этом вы экономите время и ресурсы, которые потребовались бы для остановки и восстановления целой ВМ, на которой работает сервер приложения!
Мгновенное восстановление виртуализованного сервера непосредственно из резервной копии
Представим себе банк, у которого есть некоторое количество банкоматов. Банкоматы очень важны для работы банка (2 уровень), их недоступность в течение нескольких часов повлияет на проводимые банком операции, но не остановит их полностью. С помощью Veeam Backup & Replication и функции мгновенного восстановления ВМ можно сразу же перезапустить виртуализованный сервер банкоматов из дедуплицированного и сжатого файла резервной копии Veeam. Это позволяет достичь показателя RTO, равного нескольким минутам! Более того, используя функции миграции гипервизора и Veeam Quick Migration, можно легко перенести работающую ВМ с резервной площадки в производственную, завершив процесс восстановления.
Полное переключение на резервную площадку
Работы с электросетью привели к полному отключению питания и остановке работы одного из ваших дата-центров. В результате все критически важные приложения 1 уровня оказались недоступны. Допустим, вы делаете реплики всех критически важных ВМ на удаленную площадку каждые 10 минут, используя решение Veeam. Таким образом, вам несложно достичь требуемого показателя RPO в несколько минут. Что касается RTO, Veeam обеспечивает возможность быстрого восстановления в случае крупных аварий: переключение на реплику в один клик, упрощенное обратное переключение, автоматическое переназначение IP для восстановления сети на резервной площадке и полноценное послеаварийное восстановление с использованием облака.
Защита персональных компьютеров
Помимо виртуальной инфраструктуры, Veeam позволяет защитить и физические устройства, в том числе предлагает возможности резервного копирования и восстановления данных персональных компьютеров и ноутбуков. С помощью Veeam Agent for Microsoft Windows можно восстановить файлы с аварийного загрузочного диска на компьютер под управлением Windows или даже запустить образ ПК из резервной копии как виртуальную машину, чтобы обеспечить низкий RPO.
Кроме того, с помощью Veeam Agent for Linux можно защитить системы Linux как на локальной площадке, так и в публичном облаке.
Заключение
Никто не может предсказать, когда случится авария, но если она уже произошла, вы можете четко следовать плану обеспечения непрерывности бизнеса. Значения показателей RPO и RTO могут различаться в разных компаниях, но в любом случае они представляют собой компромисс между требованиями бизнеса к доступности данных и необходимыми инвестициями в ИТ. Их значения должны быть определены в ходе диалога между бизнес-подразделениями и ИТ-специалистами вашей компании. Однако не подлежит обсуждению необходимость надежного решения для обеспечения доступности данных виртуальных, физических и облачных систем, которое гарантирует непрерывность бизнес-процессов компании.