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

RTO, RPO и «девятки» высокой готовности

Эффективность решений, обеспечивающих высокую готовность критически важных для бизнеса приложений, обычно оценивают по трем показателям. Первый: целевое время восстановления RTO (Recovery Time Objective) – это то время, которое потребуется для восстановления нормальной работы приложений после аварии, то есть продолжительность простоя приложения, вызванного катастрофой либо неплановым сбоем. Чем меньше показатель RTO, тем раньше приложение начнет работать после ликвидации аварии и тем меньше будут убытки от его простоя. Второй показатель – это целевая точка восстановления RPO (Recovery Point Objective), определяющая, к какому состоянию приложения можно выполнить откат системы после ликвидации последствий аварий. RPO измеряется в единицах времени (минуты, часы, дни) и определяет объем последних по времени данных, которые будут безвозвратно потеряны в случае аварии. Чем эффективнее построено решение высокой доступности, тем меньше RPO и потери данных при аварии.

Наконец, сама степень готовности измеряется в процентах и показывает, сколько времени система сохраняет работоспособность в течение длительного периода эксплуатации. Чем больше показатель готовности, тем более надежно работает компьютерная система и тем меньше ее плановые и неплановые простои. Если у системы показатель доступности равен 90%, то это означает, что она простаивает 10% времени и за год ее простои составляют 36,5 дня. Большинство современных решений высокой доступности обеспечивают значение этого показателя до 99,999% (пять девяток) и 99,9999% (шесть девяток), что означает продолжительность простоев за год всего 5,26 минуты и 31,5 секунды соответственно.

Классический подход к защите от аварий

Примерно до середины прошлого десятилетия основным инструментом защиты от аварий данных приложений было резервное копирование на ленту. Причем было необходимо, чтобы копируемые данные не менялись, то есть работу приложения в момент резервного копирования нужно было останавливать. Это большой минус. Кроме того, резервное копирование на ленту данных даже одного приложения может растянуться на несколько часов и создать большую дополнительную нагрузку на локальную сеть, по которой передаются данные с сервера приложения на ленточную библиотеку. Поэтому обычно резервное копирование выполнялось в нерабочее время (ночью или в выходные).

При таком подходе целевая точка восстановления RPO равнялась одному дню, и в случае аварии – например, выхода из строя жесткого диска сервера, на котором хранилась основная копия данных приложения, – вся информация за последние сутки терялась. Целевое время восстановления RTO при этом в зависимости от объема данных также составляло несколько часов или суток, поскольку, помимо считывания резервных копий с ленты, могла потребоваться и повторная инсталляция на сервер операционной системы и прикладного ПО.

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

Данные высокой доступности

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

При аварии на основном дата-центре наиболее важные из приложений перезапускаются на резервном дата-центре

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

Разумеется, построение катастрофоустойчивой системы требует очень больших затрат – помимо оборудования резервного дата-центра, надо обеспечить надежные высокоскоростные каналы связи между дата-центрами и приобрести специальное ПО для синхронизации данных между установленными в этих дата-центрах серверами и дисковыми массивами. Такое могли себе позволить только крупные организации, а большинство небольших и средних компаний для защиты от аварий применяли только резервное копирование на ленту.

Новые требования к доступности приложений

В середине прошлого десятилетия требования к решениям для обеспечения высокой готовности резко возросли, во многих компаниях критичные для бизнеса приложения стали работать в круглосуточном режиме, и их нельзя было остановить для резервного копирования на ночь или на выходные дни. По мере того как бизнес многих компаний все больше зависел от работы приложений, требовалось обеспечить низкие RPO и RTO для критически важных систем. В это же время началось внедрение новых технологий резервного копирования. Благодаря появлению относительно дешевых дисковых массивов с жесткими дисками SATA стало возможным хранить резервные копии на жестких дисках, а не на ленте. Резервное копирование с диска на диск (D2D) значительно увеличило скорость резервного копирования и восстановления данных, избавило от ручных операций при выполнении этих задач и упростило управление резервными копиями. Популярность решений D2D и дисковых библиотек резервного копирования дала стимул для развития технологий дедупликации, позволяющих сократить место, которое резервные копии занимают на жестких дисках, а также уменьшающих трафик, связанный с перемещением по сети резервных копий.

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

Для резервного копирования без прерывания работы приложений сегодня широко применяется технология «мгновенных снимков»

Для резервного копирования без прерывания работы приложений сегодня широко применяется технология «мгновенных снимков» данных: с помощью метаданных практически мгновенно с данных приложений делается «снимок», и затем на его основе создается резервная копия «замороженных» данных. Периодичность «мгновенных снимков» определяет значение RPO. Например, если «мгновенные снимки» делаются каждый час, то RPO равен одному часу, а если четыре раза в час, то RPO равен 15 минутам. Благодаря мгновенным снимкам объем данных, которые можно потерять при аварии, существенно сокращается.

Эволюция резервного копирования D2D привела к появлению специализированных приставок резервного копирования. Целевые приставки резервного копирования – это дисковые библиотеки с функцией дедупликации, которые совместимы с основными пакетами резервного копирования и заменяют в корпоративной ИТ-инфраструктуре классические ленточные библиотеки, обеспечивая увеличение скорости резервного копирования и восстановления, а также быструю проверку правильности резервных копий. Для небольших организаций выпускаются интегрированные приставки резервного копирования, объединяющие в одной системе дисковую библиотеку и сервер резервного копирования с уже предустановленным и полностью настроенным ПО резервного копирования. Интегрированные приставки – это решение под ключ, которое хорошо подойдет для тех компаний, где нет своих ИТ-специалистов по резервному копированию, а также для филиалов крупных корпораций.

На протяжении последних двух лет продажи приставок резервного копирования постоянно росли, однако во втором квартале нынешнего года аналитическое агентство IDC впервые зафиксировало снижение спроса на эти системы. Как считают аналитики, сейчас многие компании, особенно малые и средние, вместо системы резервного копирования начинают применять сервисы обеспечения высокой готовности, предлагаемые провайдерами облачных вычислений. Стоит отметить, что такие сервисы не ограничиваются только резервным копированием данных в облако провайдера, а обеспечивают продолжение работы критически важных приложений в случае аварии. Для этого в публичное облако провайдера постоянно удаленно реплицируются данные приложений заказчика, а при возникновении нештатной ситуации в ИТ-инфраструктуре заказчика на виртуальных машинах облака провайдера быстро запускаются копии приложений – таким образом, простои из-за аварий сводятся к минимуму. Применение услуг облачного провайдера позволяет даже небольшим компаниям реализовать катастрофоустойчивое решение высокой готовности.