Быстрый рост объемов корпоративных данных в виртуализованных дата-центрах и на удаленных площадках ведет к сокращению окна резервного копирования и требует новых подходов к организации бэкапа и восстановления.
Бизнес становится все более зависимым от приложений и данных, которыми он оперирует. Это происходит на фоне безудержного роста корпоративных данных, обусловленного технологическими успехами отрасли: каналы становятся шире, процессорные мощности растут, все большему количеству пользователей предоставляется удаленный доступ к корпоративным ресурсам практически из любой точки мира. В этих условиях традиционная стратегия резервного копирования с возможностью восстановления информации в случае потери или порчи перестает удовлетворять требованиям непрерывности и доступности бизнеса.
Как с точки зрения капитальных вложений, так и с точки зрения стоимости энергопотребления традиционное сохранение резервных копий больших объемов данных на диски обходится довольно дорого. Что же касается резервного копирования на ленту, то эта технология обладает низкой скоростью и невысокой надежностью самих лент.
По мере роста объемов данных ИТ-персоналу приходится управлять все большим числом проектов, обслуживать все большее количество серверов и рабочих мест и тратить непропорционально много времени на управление процессом резервного копирования в распределенной среде.
«Особенно сложно управлять бэкапом в крупных организациях с большим количеством серверов и приложений, — отмечает Алексей Поляков, менеджер по коммерческим системам хранения данных компании НP. — Этот процесс может оказаться слишком долгим».
«С течением времени неэффективный бэкап начинает диктовать бизнесу корпоративные политики, в то время как должно быть наоборот: политики должны формировать для ИТ процедуры и процессы», — констатирует Павел Бондарчук, вице-президент по развитию бизнеса компании CloudBerry Lab.
Тщетная предосторожность
Основной проблемой бэкапа, которая возникает систематически, Алексей Поляков считает сложность восстановления информации из резервных копий: «Многие ИТ-специалисты за свою практику уже сталкивались с ситуацией, когда попытка восстановления заканчивалась неудачно или на это требовалось слишком много времени».
Увеличение интенсивности обмена данными со стороны приложений высокой доступности, сокращение окна резервного копирования, недостаток централизованного контроля данных в распределенных системах в условиях прежней численности ИТ-персонала — все это ведет к повышению частоты отказов при восстановлении после сбоев элементов ИТ-инфраструктуры.
Аналитики Park Associates констатируют, что по мере того, как файлы данных будут становиться все более объемными, компаниям придется тратить все больше времени и денег на обеспечение доступа к ним, а это в свою очередь заставит совершенствовать методы резервного копирования.
Согласно отчету компании Park Associates, объем рынка цифрового хранения и резервного копирования к 2014 году оценивается в 4,4 млрд долларов.
Резервное копирование в виртуальной среде
По прогнозам Gartner, к 2018 году 86% серверов будут виртуализованы. С наступлением эры виртуализации появились специфические проблемы резервного копирования.
Задача, которую приходится решать в среде виртуализации, связана с необходимостью бэкапа большого количества виртуальных машин.
— В настоящее время все основные производители ПО резервного копирования предлагают решения, интегрированные с виртуальными средами, — рассказывает Алексей Пилипчук, технический директор компании «Техносерв». — Основа этих решений — резервное копирование с виртуальных хостов (минуя ОС внутри виртуальной машины), а также гранулярное (пофайловое) восстановление данных. Это позволяет серьезно снизить нагрузку на ОС внутри виртуальной машины, не зависеть от типа и версии ОС, а также тесно интегрироваться с гипервизором виртуальных машин.
Но сегодня, подчеркивает Пилипчук, у данного метода имеется недостаток, сильно ограничивающий его область применения: при работе с приложениями, находящимися внутри виртуальной машины, не существует технологии, позволяющей резервно копировать данные. Поэтому для бэкапа базы данных, находящихся внутри виртуальной машины, до сих пор необходимо использование агент-приложения, непосредственно работающего в той же виртуальной среде.
Алексей Пилипчук
Примером выхода на рынок резервного копирования в средах виртуализации Microsoft Hyper-V и VMware является покупка Double-Take компанией Vision Solutions, специализировавшейся прежде на решениях по обеспечению катастрофоустойчивости на платформе IBM Power Systems.
«Если компания думает о виртуализации инфраструктуры или о переходе в «облако», но при этом опасается сделать решительный шаг, можно прибегнуть к ступенчатому переходу, — предлагает Александр Трекин, региональный директор Vision Solutions в России и странах СНГ. — Сначала можно внедрить виртуализацию на резервных серверах, оставив существующую инфраструктуру в прежнем виде, а на следующем этапе виртуализовать и производственную инфраструктуру».
Смена традиций
Еще три–четыре года назад компании в подавляющем большинстве использовали старый, хорошо проверенный способ защиты данных в случае их потери — резервное копирование на ленту с последующим восстановлением.
Обычная схема бэкапа выглядит следующим образом: Система хранения -> Сервер -> Сервер РК -> Ленточная библиотека -> Удаленное хранилище. Типовой подход, помимо резервного копирования на ленту, предусматривает также промежуточное хранение на диске с последующим архивированием на ленточный накопитель. Зачастую регламент резервного копирования подразумевает вывоз ленточных накопителей за пределы дата-центра.
Традиционное резервное копирование — процесс трудоемкий, низкоскоростной и низкоэффективный: еженедельно в него вовлекается до 200% продуктивных данных, при этом объем последних в 8–20 раз меньше, чем у резервных копий. Но еще более трудоемким в традиционной схеме бэкапа является процесс восстановления информации после сбоя. Как правило, время восстановления непредсказуемо больше планируемого, а риск невозможности восстановления превышает 10% (по данным Gartner). Следует также принять во внимание риски утери или кражи ленточных накопителей при перевозке.
Алексей Пилипчук отмечает, что до недавнего времени самой универсальной была схема копирования «диск — диск — лента», в которой оперативные копии делаются на диски, а ленты применяются для долговременного хранения.
«В настоящее время распространяются и чисто дисковые архитектуры, в которых дедуплицированные данные могут занимать меньше места и храниться довольно долго, — говорит он. — У каждого из способов хранения существуют как достоинства, так и недостатки».
Глобальный рынок автоматизированных ленточных накопителей переживает спад: по данным IDC за IV квартал 2010 года, ежегодное снижение оборота на протяжении 2009–2014 годов достигнет 7,9%. В 2009 году оборот в этом сегменте рынка составлял $1,6 млрд, а в 2010-м — $1 млрд. Для сравнения: по данным TheInfoPro Wave 13 Storage Study (IV квартал 2009 года), рост выручки от продаж решений EMC для резервного копирования с использованием дедупликации в 2007–2009 годах равнялся 45%.
«Ленточные системы, сети хранения на основе FC, разрозненное ПО и аппаратные средства — эти технологии идут к закату», — уверен Иван Скудин, консультант по технологии BRS компании EMC. По его мнению, будущее — за дисками с дедупликацией, быстрыми сетями IP и интегрированными системами.
— Управлять съемными носителями непросто, — отмечает Алексей Поляков. — Они теряются, портятся (размагничиваются) и даже похищаются. Именно поэтому сейчас компании все чаще переходят к бэкапу на диски, используя для этих целей виртуальные ленточные библиотеки (Virtual Tape Library, VTL). В настоящее время дисковые библиотеки стали гораздо доступнее по цене.
Например, новое поколение библиотек HP D2D Backup System благодаря усовершенствованной технологии дедупликации данных опускает стоимость дискового бэкапа практически до цены ленточного. Дедупликация позволяет не записывать повторяющиеся блоки данных, что на порядок сокращает потребность в дисковом пространстве.
Первые поколения дисковых библиотек работали не слишком быстро, так как процесс дедупликации связан с обработкой «на лету» огромных объемов информации. Но технологии дедупликации совершенствовались.
«Новое поколение HP D2D Backup System использует технологию HP StoreOnce, разработанную в лабораториях HP, — рассказывает Алексей Поляков. — Благодаря встроенному алгоритму индексации Sparse Indexing (выборочное индексирование) система предугадывает наличие дубликатов на дисках библиотеки, что на порядок ускоряет бэкап. В зависимости от модели HP D2D скорость резервного копирования достигает 4 ТБ/час, и это с учетом дедупликации «на лету».
HP D2D для крупных организаций с филиалами дает возможность консолидировать бэкап в центре. Ранее было доступно два варианта передачи резервных копий из филиалов в ЦОД. Первый — через Интернет, но из-за плохих каналов в большинстве регионов он не всегда подходит. Второй способ — отправлять ленты почтой либо курьером, что чревато потерей и длительным восстановлением. Использование HP D2D позволяет упростить и автоматизировать такой процесс.
«В филиалах можно установить библиотеки начального уровня, а в центре — старшую модель, — поясняет Алексей Поляков. — Филиальный бэкап записывается на HP D2D, и уже дедуплицированные данные (в 20 раз меньше изначальных) по узким каналам передаются в центр, где записываются на большую библиотеку. Одна HP D2D 4324 позволяет собирать данные с 50 филиалов, и все это управляется одним администратором».
Алексей Поляков
Специалисты EMC отмечают, что невозможность использования современных технологий является недостатком многих «древних» систем резервного копирования не только на ленту, но и на диски. На рынке имеется большое число систем резервного копирования на диски, в которых ограничены возможности подключения по Ethernet на скорости 10 Гбит/с либо отсутствует поддержка DD Boost или Open Storage.
«В этом случае единственным методом модернизации системы резервного копирования, позволяющим использовать дедупликацию, является виртуальная ленточная библиотека VTL, работающая по FC, — считает Михаил Никитин. — В Data Domain такой тип подключения поддерживается в целях совместимости с устаревшими сетями и ПО. Это, пожалуй, единственное на сегодня эффективное применение систем VTL. Как отдельное устройство виртуальные ленточные библиотеки себя изжили. Будущее эксперты рынка видят в IP-подключении как систем хранения, так и устройств резервного копирования».
Хорошие перспективы, по мнению Никитина, имеют технологии резервного копирования на диск с интерфейсом подключения DD Boost. Фактически это семейство стандартов Open Storage (открытая платформа для разработки технологий хранения данных, изначально предложенная компанией Symantec), которые поддерживаются такими линейками продуктов, как EMC NetWorker, Avamar, Data Domain и ряд инструментов Symantec (в частности NetBackup). DD Boost является расширением протокола, предложенного компанией ЕМС для интерфейса систем дедупликации на целевом устройстве Data Domain. Подобные плагины EMC предоставляет также для Symantec NetBackup, BackupExec; они встроены в продукты линейки EMC Avamar и Networker.
Избавление от балласта
Механизмы резервного копирования постоянно совершенствуются. Алексей Пилипчук отмечает:
— Многие системы резервного копирования — такие, например, как Avamar, да и вообще системы лидеров в этой отрасли стали сразу ориентироваться на оптимизацию с точки зрения каналов и дисковой памяти. Ведь, по статистике, более 50% проектов по обеспечению катастрофоустойчивости не завершилось успешно по причине того, что либо телекоммуникационная структура не была готова, либо ее стоимость оказалась чрезмерно высока. Одно из последних нововведений — дедупликация на стороне клиента, благодаря чему снижается нагрузка на канал и дисковую память (но повышается процессорная нагрузка на хост и время восстановления). Стоит отметить, что этот способ применим только для резервного копирования на диски. Большинство существующих на рынке систем резервного копирования поддерживает и комбинированную дедупликацию — на клиенте и в точке хранения резервных копий. Поскольку аппаратные технологии постоянно совершенствуются, важно вовремя производить аппаратную модернизацию каналов и дисков, чтобы они соответствовали своей задаче.
Программно-аппаратный комплекс EMC представляет сейчас, пожалуй, наиболее полный инструментарий резервного копирования и восстановления с использованием дедупликации как на источнике (Avamar), так и на целевом устройстве (Data Domain). Под руководством системы Networker клиент Avamar может производить запись резервируемых данных на Data Domain: заказчик, таким образом, получает полностью законченное решение по резервному копированию и восстановлению от EMC, масштабируемое от рабочих станций до самых больших серверов.
«Дедупликация происходит во время копирования, — объясняет Михаил Никитин. — Это обеспечивает скорость, предсказуемость, простоту настройки и планирования».
Комплекс продуктов Avamar и Data Domain обеспечивает снижение требований к полосе пропускания корпоративной сети на 80–99%, а ускорение операций резервного копирования — на 50%. Поэтому с помощью существующих ресурсов заказчики могут обрабатывать гораздо больший объем резервных копий.
В частных «облаках» нередко используются схемы репликации данных на удаленные площадки. В то же время в виртуализованных средах репликация стала проблемой номер один, потому что количество ВМ увеличивается намного быстрее, чем количество физических серверов, а все эти данные нужно защищать.
«Без использования дедупликации репликация данных — очень дорогая вещь, — напоминает Михаил Никитин. — Особенно это касается репликации резервных копий. А с дедупликацией репликация на удаленный сайт становится доступной даже среднему бизнесу, что очень важно при использовании существующих каналов связи. У ЕМС есть заказчики, которые используют такие системы даже по спутниковым каналам».
Михаил Никитин
Вопрос выбора
Общее правило, которым следует руководствоваться при выборе методов резервного копирования с точки зрения эффективного восстановления, Алексей Пилипчук формулирует следующим образом: чем быстрее необходимо восстановить данные, тем дороже это обойдется, в том числе в виде создания дополнительного пространства и использования технологий.
«В первую очередь необходимо определиться с наиболее важными критериями, — объясняет он. — Например, в течение какого времени нужно восстановить данные, насколько восстановленные данные должны быть актуальны, каков приоритет восстановления по отношению к другим задачам… Затем можно строить систему уже с учетом этих критериев, выбирая политики, то есть частоту копирования, методы получения копий, сроки и параметры их хранения, количество и конфигурацию носителей».
Пилипчук также обращает внимание на необходимость учитывать аппаратные ограничения инфраструктуры и по возможности своевременно модернизировать или перестраивать узкие места.
Выбирая решение по резервному копированию и восстановлению, Михаил Никитин советует обратить внимание на несколько моментов: количество персонала, занятого в разработке продукта, его опыт, близость к центрам разработки современных технологий, своевременность выхода новых версий продуктов по мере выхода свежих версий операционных сред и приложений.
«Сегодня бизнес начинает понимать реальную стоимость систем резервного копирования, способных легко масштабироваться по мере расширения бизнеса, — говорит он. — Ведь замена уже построенной системы, содержащей данные, может оказаться очень дорогим мероприятием. Реальное понимание стоимости владения системой резервного копирования должно основываться на оценке уровня поддержки как самой системы, так и приложений завтрашнего дня».
Ошибки и проблемы
Какие организационные и технические проблемы, связанные с резервным копированием, наиболее характерны для современных компаний?
«К организационным проблемам можно отнести отсутствие регламентов восстановления и контроля прохождения резервного копирования, отсутствие проверок резервных копий и «тренировочных восстановлений», — делится опытом Алексей Пилипчук. — С технической же точки зрения главной проблемой можно считать отсутствие системного подхода и, как следствие, неудовлетворительные характеристики работы подсистемы резервного копирования или даже невозможность восстановления данных. Эти проблемы связаны с непроработанным или неправильно внедренным решением резервного копирования».
При составлении плана резервного копирования, отмечает Пилипчук, важно учесть множество параметров, начиная от самых важных, таких как объем данных, скорость канала, точка восстановления, время восстановления, и заканчивая такими, на первый взгляд, неочевидными, как скорость файловой системы.
«Только анализ всех этих параметров в комплексе позволит получить ожидаемый результат. Задачи резервного копирования также имеют свою область применения, которая не всегда учитывается при проектировании. Например, время восстановления данных после сбоя системы, если используется прямое копирование данных на любые носители, как диски, так и ленты, всегда будет большим. Для быстрого восстановления нужно настраивать дополнительный функционал, такой как использование мгновенных снимков данных. Если решение проработано, технических неразрешимых проблем практически не бывает».
Типичные ошибки, по мнению Алексея Пилипчука, происходят из-за неверной количественной оценки параметров системы (например, нехватка ленточных приводов для одновременного выполнения назначенных заданий), хранения данных и копий в одном хранилище, бэкапа не всех необходимых для восстановления данных, нехватки резервных мощностей для проведения восстановления и, конечно, из-за непродуманности процесса восстановления, отсутствия регулярных испытаний этой процедуры — когда план восстановления готовится в момент аварии.
— Идеальной системы резервного копирования не существует, — считает Пилипчук. — Каждое решение обладает набором достоинств и недостатков, которые необходимо осознавать и пытаться минимизировать. В этом и заключается поиск оптимального решения, которое необходимо тщательно подбирать в каждом конкретном случае, исходя из потребностей. Как и любая другая информационная система, система резервного копирования требует постоянного мониторинга и оперативного решения оператором проявившихся проблем. В общем случае практически все нештатные ситуации с утерей данных на 95% связаны с человеческим фактором, а труднее всего исправлять те ошибки, которые были допущены на стадии планирования и проработки решения.
Наталья Жилкина http://ibusiness.ru/