что такое rpo допустимая точка восстановления
Что такое rpo допустимая точка восстановления
Репликация в Veeam Backup & Replication 7-01
Всем привет сегодня хочу поговорить больше о теории что такое репликация в Veeam Backup & Replication 7. Ранее я рассказывал как реплицировать виртуальную машину в Veeam Backup & Replication 7. Но это было чисто механическое действие, мне хотелось бы познакомить вас как это происходит на уровне файловой системы и виртуальных машин, для того чтобы у вас было понимание того как это все работает.
Что такое репликация
Что такое RPO и RTO
Репликация в Veeam Backup & Replication 7-2
Допустимое время восстановления (RTO) определяется количеством времени неработоспособности сервиса в случае прерывания операций. Оно показывает раннюю точку времени, после которой операции могут быть продолжены. Обе концепции основываются на временных параметрах. На рисунке показаны взаимосвязи RPO и RTO.
Маленькое время до точки восстановления означает высокую стоимость реализации стратегии по резервированию. RPO равное нескольким минутам влечет применение отказоустойчивых кластерных технологий (дублирование / зеркалирование).
Маленькое время восстановления может означать необходимость иметь альтернативный Hot-Site, т.е. выделенные помещения с проложенной ЛВС, установленным и настроенным оборудованием и ПО. Маленькое RTO означает низкую толерантность к происшествиям. Толерантность к происшествиям означает интервал времени, в течение которого могут быть недоступны IT-сервисы и который может принять бизнес.
Кроме RPO и RTO существуют несколько важных дополнительных параметров, которые необходимо учитывать в стратегии восстановления. Они включают:
• окно недоступности сервиса (Interruption window) – ожидаемое время от начала происшествия до восстановления сервиса;
• уровень предоставления сервиса (Service delivery objective, SDO), который может быть достигнут на альтернативном оборудовании до возврата на основное. (одно из бизнес требований);
• максимальное альтернативное время (Maximum tolerable outages) – время, в течение которого возможна работоспособность сервиса на альтернативном оборудовании. После этого времени, возможно возникновение проблем, особенно если альтернативный уровень SDO ниже основного.
Как работает реплика в Veeam Backup & Replication 7
Есть два хоста Hyper-v или VMware, это не имеет значение.
Репликация в Veeam Backup & Replication 7-03
На хосте источнике и хосте назначения, Veeam разворачивает транспортный сервер. Это маленькая служба которая обрабатывает запросы на трансфер данных. Трафик между двумя хостами будет компрессированным.
Репликация в Veeam Backup & Replication 7-04
Далее нам на сервере источнике механизм репликации снимает VSS снапшот volume внутри самой ОС. Для примера на сервере может крутиться какой то сервис, например Active Directory и если в начале создавать снимок виртуальной машины, то те данные которые идут во время снимка могут повредиться. В результате снимка остановятся транзакции, но сервис будет продолжать работать. Далее идет снапшот на уровне гипервизора. Теперь первый снапшот VSS нам уже не нужен.
Репликация в Veeam Backup & Replication 7-механизм репликации
Транспортная служба начинает вытягивать данные на другой хост, начинается initial replication или первоначальная. Во время передачи транспортная служба удалит все неиспользуемое пространство, сожмет данные, удалит своп файл. Получиться полная копия на момент создания репликации. Виртуальная машина на втором хосте Hyper-V будет в выключенном состоянии.
Репликация в Veeam Backup & Replication 7-CBT
Допустим вы запускаете задание во второй раз или по расписанию, вступает в роль драйвер CBT (change block tracking), он смотрит измененные блоки с момента последней репликации. Эти блоки будут извлечены и скомпрессированны, и будут переданы серверу target.
Репликация в Veeam Backup & Replication 7-08
Если нагрузка создаваемая при репликации слишком ощутима для хоста источника, то можно развернуть Veeam backup proxy, который поможет уменьшить нагрузку, так как сервер бэкапов veeam может делать одновременно несколько бэкапов с разных мест, есть возможность его разгрузить. Veeam backup proxy будет делать компрессию сам и не нагружать этим хосты
Репликация в Veeam Backup & Replication 7-09
Вот так вот работает сам механизм репликации в Veeam Backup & Replication 7.
Функция Seeding
Seeding реплика нужна для организации initial replication в максимально правильном варианте. Очень распространена когда у вас идет реплика не по локальной сети, а между цодами разных городов.
Репликация в Veeam Backup & Replication 7-10
Представим ситуацию что нам нужно передать 4 тб по каналу 5 мбит, с такой скоростью первую реплику мы будем передавать очень долго
Репликация в Veeam Backup & Replication 7-11
Делается бэкап данной виртуальной машины, она сжимается, в ней удаляется свободное место, своп файлы. На выходе вы получаете файл меньшего размера, при чем существенно.
Репликация в Veeam Backup & Replication 7-2
После чего вы передаете сжатый файл бэкапа виртуальной машины, любым удобным для вас способом, через тот же зашифрованный VPN туннель, или облако. В любом случае передать бэкап но другую площадку таким методом будет быстрее.
Репликация в Veeam Backup & Replication 7-13
Далее за счет технологии seedingвы при первой репликации указываете что у вас есть бэкап, тот что мы до этого передали. В итоге на второй площадке вы получаете виртуальную машину на 99 процентов соответствующую виртуалке на первой площадке. Далее вы дореплицируете CBT блоки уже обычным методом
Репликация в Veeam Backup & Replication 7-14
Функция Mapping
Функция mapping похожа на siddig, представим две площадки, с первой площадки нужно передать реплику, но на второй площадки есть уже бэкап этой виртуальной машины, за счет технологии mapping можно при первой реплике указать уже существующий бэкап виртуальной машины
Репликация в Veeam Backup & Replication 7-mapping
Далее после указания на существующий бэкап виртуальной машины, при первой реплике будут дореплицированны только CBT блоки.
Репликация в Veeam Backup & Replication 7-mapping
Функция Network Mapping
Это функция полезна когда на ваших площадках у виртуальных машин разные подсети
Репликация в Veeam Backup & Replication 7-network mapping
Когда ваша реплицируемая виртуальная машина сетевым интерфейсом воткнута в виртуальный коммутатор vNetwork01, то и реплицируется она на вторую площадку с такой же конфигурацией, и подразумевается что она должна быть воткнута в тот же виртуальный коммутатор, но у нас на второй площадке он называется vNetwork10, тут то вам и поможет технология network mapping, которая и скажет что на второй площадке нужно подключать реплицируемую машину в виртуальный коммутатор vNetwork10.
Репликация в Veeam Backup & Replication 7-18
Функция Re-Ip
Функция Re-Ip похожа на network mapping, но работает на уровне гостевой системы. Предположим на первой площадке есть виртуальная машина с Ip адресом 10.10.10.1/24, если бы применялась только технология network mapping, то при реплике она была бы воткнута в нужный коммутатор. Но допустим на коммутаторе другая сетевая адресация, и воткнувшись в коммутатор у нас на виртуальной машине останется прежний статический ip 10.10.10.1/24 и работать она не будет, вот тут нам и поможет технология Re-Ip.
Репликация в Veeam Backup & Replication 7-Re-ip
При переключении виртуальной машины на вторую площадку, допустим в первой она вышла из строя, технология Re-ip пока только для Windows систем, проанализирует его реест и подменит там ip адрес на нужный, то что будет указан заранее.
Репликация в Veeam Backup & Replication 7-20
Вот такие вот полезные функции Veeam Backup & Replication 7. Надеюсь что про реплику вы теперь узнали больше.
Пусть хоть потоп, но 1С должна работать! Договариваемся с бизнесом о DR
Представьте себе: вы обслуживаете ИТ-инфраструктуру крупного торгового центра. В городе начинается ливень. Потоки дождя прорывают крышу, вода заполняет торговые помещения по щиколотку. Надеемся, что ваша серверная не в подвале, иначе проблем не избежать.
Описанная история — не фантазия, а собирательное описание пары событий 2020 года. В крупных компаниях на этот случай всегда под рукой план послеаварийного восстановления, или disaster recovery plan (DRP). В корпорациях за него отвечают специалисты по непрерывности бизнеса. Но в средних и небольших компаниях решение таких задач ложится на ИТ-службы. Нужно самому разобраться в бизнес-логике, понять, что и где может упасть, придумать защиту и внедрить.
Здорово, если ИТ-специалисту удается провести переговоры с бизнесом и обсудить необходимость защиты. Но я не раз наблюдал, как компания экономила на решении для disaster recovery (DR), так как считала его избыточным. Когда наступала авария, долгое восстановление грозило убытками, а бизнес оказывался не готов. Можно сколько угодно повторять: «А я же говорил», — восстанавливать сервисы все равно предстоит ИТ-службе.
С позиции архитектора расскажу, как избежать этой ситуации. В первой части статьи покажу подготовительную работу: как обсуждать с заказчиком три вопроса для выбора инструментов защиты:
Что защищаем: выясняем критические бизнес-функции
Лучше начинать подготовку с обсуждения плана послеаварийных действий c бизнес-заказчиком. Тут главная сложность — найти общий язык. Заказчика обычно не волнует, как ИТ-решение работает. Его волнует, может ли сервис выполнять бизнес-функции и приносить деньги. Например: если сайт работает, а платежная система «лежит», поступлений от клиентов нет, а «крайние» — все равно ИТ-специалисты.
ИТ-специалист может испытывать сложности в таких переговорах по нескольким причинам:
От чего защищаем: риски
Дальше выясняем у бизнес-заказчика, от каких рисков мы защищаемся в первую очередь. Все риски условно поделим на две группы:
Как сильно защищаем: RPO и RTO
Когда понятны критические точки отказа, рассчитываем показатели RTO и RPO.
Напомню, что RTO (recovery time objective) — это допустимое время с момента аварии и до полного восстановления сервиса. На языке бизнеса — это допустимое время простоя. Если мы знаем, сколько денег приносил процесс, то сможем посчитать убытки от каждой минуты простоя и вычислить допустимый убыток.
RPO (recovery point objective) — допустимая точка восстановления данных. Она определяет время, за которое мы можем потерять данные. С точки зрения бизнеса, потеря данных может грозить, например, штрафами. Такие потери тоже можно перевести в деньги.
Время восстановления нужно рассчитывать для конечного пользователя: в какой срок он сможет войти в систему. Так что сначала складываем время восстановления всех звеньев цепи. Здесь часто делают ошибку: берут RTO провайдера из SLA, а про остальные слагаемые забывают.
Посмотрим на конкретном примере. Пользователь заходит в 1С, система открывается с ошибкой базы данных. Он обращается к системному администратору. База находится в облаке, сисадмин сообщает о проблеме сервис-провайдеру. Допустим, на все коммуникации уходит 15 минут. В облаке база такого объема восстановится из бэкапа за час, следовательно, RTO на стороне сервис-провайдера — час. Но это не окончательный срок, для пользователя к нему прибавились 15 минут на обнаружение проблемы.
Дальше системному администратору надо проверить, что база корректная, подключить ее к 1С и запустить сервисы. На это необходим еще час, значит, RTO на стороне администратора — уже 2 часа 15 минут. Пользователю нужно еще 15 минут: залогиниться, проверить, что нужные транзакции появились. 2 часа 30 минут — общее время восстановления сервис в этом примере.
Эти расчеты покажут бизнесу, от каких внешних факторов зависит срок восстановления. Например, если офис заливают, то сначала нужно обнаружить протечку и устранить ее. Понадобится время, которое зависит не от ИТ.
Чем защищаем: выбираем инструменты для разных рисков
После обсуждения всех пунктов заказчик уже понимает цену аварии для бизнеса. Теперь можно выбирать инструменты и обсуждать бюджет. Покажу на примерах клиентских кейсов, какие инструменты мы предлагаем для разных задач.
Начнем с первой группы рисков: потерь из-за простоев сервиса. Варианты решения для этой задачи должны обеспечивать хороший RTO.
Для начала можно просто переехать в облако — там вопросы высокой доступности уже продумал провайдер. Хосты виртуализации собраны в кластер, электропитание и сеть зарезервированы, данные хранятся на отказоустойчивых СХД, а сервис-провайдер несет финансовую ответственность за простои.
Например, можно разместить в облаке виртуальную машину с базой данных. Приложение подключится к базе данных снаружи по установленному каналу или из этого же облака. Если возникнут проблемы с одним из серверов кластера, то ВМ перезапустится на соседнем сервере меньше чем за 2 минуты. После этого в ней поднимется СУБД, и через несколько минут база данных станет доступна.
Если хочется улучшить RTO, предыдущий вариант можно усилить и сразу разместить в облаке кластеризованное приложение.
Реализовать кластер можно в режиме active-passive или active-active. Создаем несколько ВМ, исходя из требований вендора. Для большей надежности разносим их по разным серверам и СХД. При отказе сервера с одной из БД, резервная нода принимает на себя нагрузку за несколько секунд.
RTO: измеряется в секундах.
Стоимость: чуть дороже обычного облака, потребуются дополнительные ресурсы для кластеризации.
От чего не защитит: по-прежнему не защитит от массовых сбоев на площадке. Но локальные сбои будут не такими продолжительными.
Из практики: У компании-ритейлера было несколько информационных систем и сайтов. Все базы данных располагались локально в офисе компании. Ни о каком DR не задумывались, пока офис не остался без электричества несколько раз подряд. Клиенты были недовольны сбоями на сайтах.
Проблема с доступностью сервисов решилась после переезда в облако. Плюс к этому удалось оптимизировать нагрузку на базы данных за счет балансировки трафика между узлами.
Если нужно, чтобы работе не помешало даже стихийное бедствие на основной площадке, можно выбрать катастрофоустойчивое облако В этом варианте провайдер разносит кластер виртуализации уже на 2 дата-центра. Между дата-центрами происходит постоянная синхронная репликация, один-в-один. Каналы между ЦОДами зарезервированы и идут по разным трассам, так что такому кластеру не страшны проблемы с сетью.
RTO: стремится к 0.
Стоимость: самый дорогой вариант в облаке.
От чего не защитит: Не поможет от порчи данных, а также от человеческого фактора, поэтому параллельно рекомендуется делать бэкапы.
Из практики: Один из наших клиентов разработал комплексный план послеаварийного восстановления. Вот какую стратегию он выбрал:
Еще один вариант, как можно избежать глобальных проблем на основной площадке: обеспечить георезервирование. Другими словами, создать резервные виртуальные машины на площадке в другом городе. Для этого подойдут специальные решения для DR: мы в компании используем VMware vCloud Availability (vCAV). С его помощью можно настроить защиту между несколькими площадками облачного провайдера или восстановиться в облако с on-premise площадки. Подробнее о схеме работы с vCAV я уже рассказывал тут.
RPO и RTO: от 5 минут.
Стоимость: дороже первого варианта, но дешевле, чем аппаратная репликация в катастрофоустойчивом облаке. Цена складывается из стоимости лицензии vCAV, платы за администрирование, стоимости ресурсов облака и ресурсов под резерв по модели PAYG (10% от стоимости работающих ресурсов за выключенные ВМ).
Из практики: Клиент держал в нашем облаке в Москве 6 виртуальных машин с разными базами данных. Сначала защиту обеспечивал бэкап: часть резервных копий хранили в облаке в Москве, часть — на нашей петербургской площадке. Со временем базы данных выросли в объеме, и восстановление из бэкапа стало требовать больше времени.
К бэкапам добавили репликацию на базе VMware vCloud Availability. Реплики виртуальных машин хранятся на резервной площадке в Санкт-Петербурге и обновляются каждые 5 минут. Если на основной площадке происходит сбой, сотрудники самостоятельно переключаются на реплику виртуальной машины в Санкт-Петербурге и продолжают работу с ней.
Все рассмотренные решения обеспечивают высокую доступность, но не спасают от потерь данных из-за вируса-шифровальщика или случайной ошибки сотрудника. На этот случай нам понадобятся бэкапы, которые обеспечат нужный RPO.
5. Не забыть про резервное копирование
Все знают, что нужно делать бэкапы, даже если у вас самое крутое катастрофоустойчивое решение. Так что лишь коротко напомню несколько моментов.
Строго говоря, бэкап — это не DR. И вот почему:
В итоговом плане послеаварийного восстановления должно быть минимум 2 инструмента:
Планирование процесса аварийного восстановления в облачных сервисах
Аварийное восстановление планируется1 в расчете на катастрофические события, наступление которых маловероятно в течение жизненного цикла системы. Если отказы, восстановление после которых вы планируете, являются событиями не столь уж невероятными, и наступления их можно ожидать, то процедуры восстановления подпадают под категорию традиционного планирования по восстановлению доступности системы. Хотя наступление любого конкретного катастрофического события в течение жизненного цикла системы и является маловероятным, тем не менее, вероятность того, что какое-нибудь бедствие все же произойдет, является ненулевой.
В процессе планирования аварийного восстановления вам необходимо определить так называемое приемлемое восстанавливаемое состояние (acceptable recovery state), до которого необходимо восстановить систему, а затем разработать пошаговые процедуры и способы восстановления этого состояния при ликвидации последствий катастрофы. Говоря о приемлемом восстанавливаемом состоянии, я имею в виду объем данных, который вы можете позволить себе потерять в случае наступления катастрофического события.
При выполнении планирования аварийного восстановления после катастрофических событий необходимо определить следующие два ключевых показателя.
± Целевая точка восстановления (Recovery Point Objective, RPO)2 — этот показа-
тель определяет, какой объем данных вы можете себе позволить потерять в случае наступления катастрофического события. Обычно это значение выражается в количестве часов или рабочих дней, в течение которых шли накопление и обработка данных. Например, если вы сочтете, что можете позволить себе потерять данные, наработанные в течение 24 часов, вам необходимо будет убедиться в том, что резервные копии, которые вы будете использовать при реализации вашего плана аварийного восстановления, не «старше» 24 часов.
1 Планирование и подготовка процессов аварийного восстановления после катастрофических событий является одной из самых горячих тем в отрасли IТ. Читателям, желающим углубленно ознакомиться с данной тематикой и не путаться в различиях между аварийным восстановлением (Disaster Recovery, DR), планированием непрерывности производственного процесса (Business Continuity Planning, BCP/BC) и такими вещами, как высокая доступность (High availability) и резервное копирование (Backups), можно порекомендовать для начала ознакомиться со следующими материалами: http://en.wikipedia.org/wiki/Disaster_recovery, http://www.continuitycentral.com/itdr.htm, http://www.disaster-recovery-guide.com/, http://www.drj.com/, http://msft.ineta.ru/blogs/blogEntrySearch.aspx?tags=failover. — Прим. перев.
2 Фактически представляет собой временную точку, на момент которой будет восстановлено состояние системы после приведения в действие плана аварийного восстановления. Подробнее см.:
http://en.wikipedia.org/wiki/Recovery_point_objective, http://www.it.ru/press_center/expert/Est_li_u_vas_plan. — Прим. перев.
± Допустимое время восстановления (Recovery Time Objective, RTO)1 — этот показатель определяет допустимое время простоя в случае наступления катастрофического события. Если показатель RTO составляет 24 часа, это означает, что промежуток между выходом вашей системы из строя и моментом, когда система должна будет возвращена в полнофункциональное состояние, должен составлять не более 24 часов.
В дополнение к только что упомянутым ключевым показателям, специалисты, занимающиеся разработкой плана аварийного восстановления, должны определить критерии, «запускающие» претворение в жизнь плана аварийного восстановления. В общем случае начало реализации любого плана, который допускает потерю данных, требует санкции менеджеров, возглавляющих предприятие или организацию, даже в том случае, когда реализация этого плана полностью автоматизирована, как я уже говорил в начале этой главы.
Естественно, что абсолютно все предпочтут такой сценарий восстановления работоспособности, при котором не наблюдается никакого простоя и не происходит никаких потерь данных, причем не имеет никакого значения тип произошедшей катастрофы. Однако в реальной жизни природа катастрофического события обычно вынуждает нас согласиться с некоторым уровнем потерь; что-либо другое окажется весьма дорогостоящим. Например, в случае такого бедствия в масштабах целого города, как ураган «Катрина» (Hurricane Katrina)2, стоимость выживания IT- компании, расположенной в Новом Орлеане (80 % площади которого было затоплено), без потери данных и с нулевым временем простоя включала бы стоимость множества физических центров обработки данных, расположенных в разных географических точках и постоянно синхронизирующих информацию. Иными словами, такая компания должна была обладать возможностью иметь не менее двух дублирующих центров обработки данных, соединенных выделенным широкополосным соединением.
Обеспечение такого уровня избыточности — это очень дорогой подход. К тому же, несмотря на избыточность, такая компания неизбежно столкнулась бы с нетривиальным падением производительности. Суровая реальность для большинства компаний заключается в том, что стоимость утраты данных, наработанных за последние 24 рабочих часа, все же меньше, чем затраты на поддержание инфраструктуры, обеспечивающей нулевое время простоя без каких бы то ни было потерь данных.
Определение оптимальных для компании показателей RPO и RTO, в таком случае, представляет собой именно финансовый расчет: необходимо определить, в какой именно момент стоимость потери данных и простоя превысит стоимость поддержания стратегии резервного копирования, которая предотвратит такие потери и
1 Подробнее см. http://en.wikipedia.org/wiki/Recovery_Time_Objective, http://www.trinitygroup.ru/solution/infrastucture/disastrous_accident. — Прим. перев.
2 Ураган «Катрина» — самый разрушительный ураган в истории США, произошедший относительно недавно (в конце августа 2005 года). См. http://hurricane-katrina.org/ — Прим. перев.
такой срок восстановления. Для различных предприятий и организаций правильный ответ на этот вопрос может существенно отличаться. Если вы являетесь топменеджером компании по управлению ее ресурсами IT, то вы наверняка знаете ответ на этот вопрос применительно именно к вашему бизнесу.
Наконец, важным элементом планирования катастрофоустойчивой инфраструктуры предприятия является понимание того, как именно будут развиваться события в случае катастрофы. Совершенно определенно можно сказать, что существует и вероятность наступления катастрофы такого масштаба, при котором ваша инфраструктура IT не выживет, не важно, как бы тщательно вы ни продумывали план ее восстановления и сколько бы времени вы на это ни потратили. В хорошо разработанном плане аварийного восстановления отдельным пунктом должна быть прописана возможность такого сценария, с тем, чтобы все акционеры понимали это и были готовы пойти на такой риск.
Целевая точка восстановления (RPO)
Проще всего начать планирование с определения целевой точки восстановления (RPO). Сценарий развития катастрофических событий по типу «Армагеддон» ведет к полной потере всех системных данных и сборок (binaries) всех приложений, необходимых для работы системы. Ваш показатель RPO лежит где-то в интервале между состоянием вашего приложения на момент его первого развертывания и состоянием, которое оно имело в момент наступления катастрофы. Вы можете также спланировать несколько уровней угрозы катастроф, и для каждого из них определить свой показатель RPO1.
Практически любая программная система должна обладать способностью поддержания показателя RPO между 24 часами (для менее масштабных катастроф) до одной рабочей недели (для более масштабных катастроф), не требуя при этом абсурдных затрат. Разумеется, потеря 24 часов рабочего времени в системе обработки банковских транзакций неприемлема, не говоря уже о недельном сроке.
Обычно ваш показатель RPO зависит от того, как вы сохраняете данные и выполняете их резервное копирование.
± Инфраструктуры, в которых выполняется удаленное резервное копирование (т. е. такое копирование, при котором резервная копия хранится за пределами здания, занимаемого вашим центром обработки данных), сможет пережить потерю вашего центра обработки данных с потерей данных, наработанных за неделю. Для обеспечения живучести гораздо лучше выбирать стратегию, когда удаленное резервное копирование выполняется ежедневно.
± Инфраструктура, в которых выбрана стратегия ежедневного создания удаленной резервной копии, сможет пережить потерю вашей производственной среды с потерей данных, наработанных за один рабочий день, плюс время репликации
1 Например, вы можете определить катастрофу первого уровня как потерю одного центра обработки данных, а катастрофу уровня 2 — как потерю двух или большего количества центров обработки данных.
транзакций за восстановительный период после полной потери системы. Если это для вас неприемлемо, лучше выполнять удаленное резервное копирование каждый час.
± Сетевые системы хранения данных (Network Attached Storage, NAS) и сети хранения данных (Storage Area Networks, SAN)1 могут без потерь пережить потерю любого отдельного сервера, за исключением случаев, когда имеет место повреждение данных.
± Кластеризованная база данных переживет потерю любого отдельного устройства хранения данных или узла базы данных без потери данных.
± Кластеризованная база данных, распределенная по множеству центров обработки данных, переживает потерю любого отдельного центра обработки данных без потери данных.
Далее в этой главе мы поговорим о том, как облачные технологии позволяют минимизировать показатель RPO.
Допустимое время восстановления (RTO)
Даже если вы будете выполнять удаленное резервное копирование вплоть до секунд, это не поможет вам, если у вас нет среды, в которой вы сможете восстановить информацию в случае отказа. Способность создать замещающую инфраструктуру для восстановления вашей рабочей среды в случае катастрофы, включая время, необходимое на восстановление данных, управляет другим показателем — допустимым (целевым) временем восстановления (RTO).
Что произойдет, если ваш сервис-провайдер, предоставляющий услуги внешнего управления, вдруг закроется завтра и без предупреждения? Если у вас есть ряд выделенных серверов, вам потребуется время (от нескольких дней до нескольких недель) для того, чтобы ваша производственная среда снова была приведена в рабочее состояние, если только у вас нет заранее заключенного соглашения о предоставлении вам замещающей инфраструктуры2.
Если вы имеете традиционную инфраструктуру IT, то обеспечение быстрого целевого времени восстановления окажется чрезвычайно дорогим мероприятием. Как я уже отмечал, на случай непредвиденных событий вам необходимо иметь заранее заключенное соглашение с другим провайдером услуг внешнего управления (MSP), который предоставит вам замещающую инфраструктуру, или соглашение об уровне обслуживания (SLA), предусматривающее предоставление вам замещающей инфраструктуры в случае прекращения деятельности вашего текущего
1 Подробнее см. http://en.wikipedia.org/wiki/Network-attached_storage, http://www.ixbt.com/storage/san.shtml, http://www.nas-central.org/. — Прим. перев.
2 Этот сценарий наглядно показывает, что просто выполнения резервного копирования с хранением резервных копий вне ваших рабочих площадей еще недостаточно для выживания в случае катастроф. Резервные копии должны быть неподконтрольны вашему провайдеру услуг внешнего управления, в противном случае вы рискуете лишиться их в случае банкротства вашего MSP.
MSP. В зависимости от типа заключенного соглашения, это может практически удвоить ваши расходы на инфраструктуру IT.
Облачная среда, даже при использовании виртуальных центров обработки данных, меняет и взгляды на показатель RTO. Этот вопрос мы тоже обсудим далее в этой главе.
Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.