Cистема резервного копирования может работать вот так
Чем корпоративный бэкап отличается от домашнего?
Масштаб — инфраструктуры до петабайта. Скорость – тысячи транзакций в секунду, поэтому, например, нужно уметь забирать бэкап из базы данных на лету, не останавливая запись. Зоопарк систем: рабочие машины, мобильные телефоны и планшеты, профили людей в «облаке», копии баз данных CRM/ERP, все это на разных ОС и в тяжелых разветвленных системах.
Ниже я расскажу про решения от IBM, EMC, CommVault, Symantec и то, что они дают как бизнесу в целом, так и IT-отделу. Плюс о некоторых подводных камнях.
Давайте посмотрим на эти особенности бэкапа в обычных российских компаниях. В том числе таких, которые бэкапятся только на случай изъятия оборудования.
Начинаем ликбез. Бэкап вообще нужен?
Обычно такой вопрос задают люди, далекие от IT. Правильный вопрос — «какой бэкап нужен»? В начале этого года мне на глаза попадался отчет, что в среднем по миру утеря данных стоит до трети стоимости компании, в США и Европе — до половины. Проще говоря, отсутствие свежего бэкапа может в некоторых случаях означать уход с рынка.
Зачем вообще нужен бэкап?
Конечно, для защиты от сбоев, атак и человеческой глупости. В целом, вопрос немного наивный, но все же давайте разберемся чуть подробнее.
- Во-первых, он защищает данные от утери. Основные причины утери — это сбои оборудования, падение удаленных площадок (например, при пожаре в ЦОДе), изъятие оборудования. Более мелкие случаи — утеря ноутбуков и так далее.
- Также бэкап защищает целостность данных: страхует от ошибок оператора, например. Это вторая по распространенности причина: человек может взять и «запороть» важные данные не той командой.
- В-третьих, в корпоративной среде «горячий» бэкап может понадобиться для быстрого развертывания сервисов при чрезвычайном происшествии, это очень актуально у тех, для кого особенно критична непрерывность IT-процессов, например, у телеком операторов или банков.
Как обычно приходят к сложным системам?
Тут все просто: с ростом компании. Сначала используются простые средства: копирование вручную, затем скриптами по расписанию или настройкой утилиты, после появляется серверное приложение, которое этим управляет. На этой стадии обычно добавляются требования к уровню бэкапа от безопасников или финансового отдела (управляющего рисками компании) — и вот тогда начинается внедрение. Каждая задача классифицируется по важности и оценивается, например, биллинг должен накатываться через 5 минут после аварии на активную дублирующую систему в другом ЦОДе, а данные сотрудников офиса — через 2 часа на заранее подготовленное, но законсервированное оборудование. На этом уровне появляется необходимость плотной интеграции с приложениями, а чуть позже — и с аппаратными массивами для хранения.
Как выглядит интеграция на практике?
Как правило, когда наши специалисты приходят ставить тотальный бэкап, в крупной компании уже есть несколько подсистем резервного копирования. Чаще всего, речь идет об уже настроенных приложениях файлового бэкапа и регулярном снятии отпечатков баз данных (например, о ночном бэкапе базы 1С) и складированию их на отдельное устройство. Бывают, конечно, и феерические случаи. Например, одна розничная сеть вообще не делала бэкап баз о наличии товара на складе — и в случае сбоя отправляла людей делать инвентаризацию.
Или вот еще пример — в филиале есть копия базы данных, которая используется только для чтения. Все данные, которые создаются на ее основе, временные. При падении копия этой базы запрашивается из головной организации и идет три дня. Люди сидят и ждут. Понятно, что данные не теряются, но если бы был правильный бэкап, они бы смогли продолжить работу уже через 20 минут.
Что самое важное в ПО для резервного копирования?
Давайте рассмотрим главные параметры.
Архитектура
Архитектура решения несомненно важна. Разделение системы на функциональные модули является обычной практикой для всех корпоративных решений по резервному копированию. Важным моментом является отделение слоя хранения от логического уровня управления данными, как это сделано, например в CommVault Simpana – одно задание резервного копирования может использовать как диск, так и ленту или даже облачное хранилище.
Пример архитектуры ПО резервного копирования (CommVault Simpana)
Функции централизованного управления.
Важно управлять всеми операциями. Бэкап крупных систем достаточно сложен, поэтому важно, чтобы администратор точно представлял, что происходит. При разветвленной структуре, например, в крупном ЦОД с сотнями систем, к каждой не «подойдешь» и не посмотришь, есть у нее резервная копия или нет. Тут нужна система, которая может построить отчет, посмотреть, что все данные и приложения копируются или не копируются, на что нужно обратить внимание, известить администратора о каких-то проблемах.
Централизованное управление СРК
У лидеров рынка появляются системы, которые позволяют посмотреть, что и где хранится, какие типы данных, что именно можно оптимизировать и так далее. Можно построить прогноз на год вперед.
Конкретные массивы и БД
Первое — поддержка массивов, заточенность под конкретные базы данных. Нужно получать данные снизу и использовать их в более сложных функциях, вроде создания аппаратных снимков. Сами системы резервного копирования уже умеют выполнять операции с массивами для обеспечения защиты данных, не затрагивая производственные системы, которые работают с этими массивами, или минимизируя нагрузку на них,
Проще говоря, система должна уметь налету делать копию базы данных, с которой сейчас производятся транзакции, и не запрашивать эту копию у серверного приложения. То есть должна грамотно и незаметно для приложения и пользователей забирать данные с дискового массива.
К примеру, системы CommVault или ЕМС поддерживают практически все имеющиеся на корпоративном рынке ОС и коммерческие приложения (в частности, базы данных Oracle, Microsoft, у CommVault есть еще поддержка PostgreSQL и MySQL, Documentum, SAP).
Дедупликация — архитектура
Важна грамотная дедупликация. Хорошая дедупликация в разы снижает требования по цене к дисковым массивам и очень хорошо жмет трафик. Грубо говоря, если первый бэкап пользовательских данных с виртуальных машин был на 10 Gb, то каждый следующий, за день, может быть на 50-60 Mb — из-за разницы между слепками систем. При этом у лидеров рынка резервного копирования (про них ниже) для внешних систем копии видны как отдельные слепки, то есть так, как если бы каждый раз делался тотальный бэкап. Это невероятно ускоряет восстановление.
Особо отмечу, дедупликация в современных системах делается на источнике, то есть на той системе, откуда данные забираются, что сильно снижает нагрузку на каналы. Это очень важно для разветвленных сетей, у которых не всегда есть достаточно широкий канал, по которому можно передать полную резервную копию. Обычная «серийная» копия для сложных систем уровня SAP — это всего пара процентов от полного объема базы.
Подсистема дедупликации, по-хорошему, должна удобно масштабироваться. В идеале, линейно с добавлением узлов хранения путем организации некоторого Grid или Cloud. При этом узлы не должны быть отдельными островами со своими наборами данных, а связаны в единое дедупликационное пространство. И совсем хорошо, если эти узлы распараллеливают нагрузку и параллельно ее обрабатывают. Отмечу, что сейчас многие заказчики бросаются меряеть коэффиценты дедупликации при сравнении продуктов. Но это не совсем правильно: современные SATA диски уже по 4ТБ в объеме каждый. Плюс-минус пару дисков и все системы смогут хранить одинаковый объем данных – и лучше докупить один диск в начале, чем при необходимости роста перестраивать всю систему.
Балансировка нагрузки
Еще в таких системах есть функции по обеспечению отказоустойчивости операции и балансировки нагрузки, что важно в больших ЦОДах, когда объемы данных в одной системе могут достигать десятков и сотен Tb. Например, у платформы виртуализации может быть очень большой объем данных и большое количество виртуальных машин. Сама система, в данном случае, должна позволять построить набор серверов, которые будут передавать данные, получать их с платформы и записывать на хранилище, при этом так, чтобы они между собой имели возможность взаимодействовать, а в случае повышения или снижения нагрузки перераспределять ее автоматически. Функция простая и очевидная, но достаточно критичная, потому что влияет на скорость и оперативность создания резервных копий.
Важна непрерывность. При отказах любых компонентов можно обеспечить успешное прохождение заданий за окно резервного копирования (ночь обычно). CommVault Simpana позволяет это делать автоматически при отказах медиа-серверов, баз данных дедупликации. В других системах есть ограничения или требуются дорогостоящие аппаратные решения. На рисунке можно видеть два сервера с агентами, которые работают в связке и если один ломается, вступает в работу другой. При этом оба они пишут на один и тот же диск, имеют общую базу дедупликации:
Физическое хранение
Чаще всего речь идет о хранении на дисковых массивах, где обеспечивается дополнительная защита данных. Первый слой — важные данные обязательно хранятся на двух независимых удаленных площадках (например, в разных ЦОДах). Второй слой — эти данные хранятся на разных накопителях. Например, файл из 10 блоков может быть записан на 11 накопителей — и при выходе из строя любого из них остальные будут содержать достаточное количество данных для восстановления недостающего звена. Вот пример одной из таких систем.
Диски и лента + «облако»
Так получается, что ленточные накопители все еще используются. Чаще всего «горячие» данные (скажем, процентов 10 самых важных) хранятся на дисках, откуда их можно быстро получить, а уже второй уровень — на ленте. Это практично и дешево, плюс лента позволяет хранить данные чуть ли не десятилетиями без замены оборудования, они просто вынимаются и кладутся на полку. Частый случай — логи и другие документы банков, которые нужно хранить определенный срок. Система бэкапа умеет выделять такие данные на диске, отчуждать их и архивировать на ленточном накопителе. При этом всегда есть возможность в случае аварии найти эту информацию и восстановить. Записывать, кстати, можно как полные копии, так и дедуплицированные – если необходимо, умная система может собрать все обратно так, как будто последний слепок был полным.
А вот CommVault Simpana умеет еще напрямую складывать копию данных из корпоративного хранилища в «облако» (некоторые наши заказчики так делают с «облаком» КРОК – мы даже проводили сертификацию). Эта дополнительная копия может рассматриваться заказчиком как долговременный архив. Для его хранения не нужно думать об аппаратной части. Еще такая копия может быть использована для аварийного восстановления систем. Например, один из заказчиков делает так: копия всех виртуальных машин отправляется в наше «облако» на хранение. В случае падения основного ЦОДа заказчика, мы можем запустить все эти виртуальные машины на своей инфраструктуре. При этом оплата до запуска идет только за емкость – то есть получается очень экономично.
Прямая работа с пользователями
Если вы не сталкивались с корпоративным бэкапом, то у вас может сложиться впечатление, что обратно данные накатывает только IT-отдел, причем делает это вручную. Но, например, у CommVault это не совсем так.
В этой ситуации пользователь может сам зайти на портал (на картинке ниже) и накатить себе конкретно свои данные, если они были в копии. Обычно на таком портале также есть поисковик по резервным копиям и архивам (в рамках прав пользователя). К этому же архиву можно открыть доступ и сотрудникам информационной безопасности — это в разы уменьшит количество запросов к IT-отделу с вопросами вроде: «А у кого был документ такой-то».
Да, вы правильно поняли. Если пользователь потерял файл, случайно удалил письмо или же захотел найти старую версию документа для сравнения – он просто идет и делает все сам за считанные секунды без лишних сложностей. И даже не звонит и не пишет в IT-отдел.
Отдельно стоит сказать про поиск. Все неструктурированные данные (файлы, почта, объекты SharePoint и т.п.) которые попадают в систему, хорошо бы проиндексировать и организовать поисковик. Simpana это умеет. С одной стороны пользователи через консоль самообслуживания могут найти любой объект сами по ключевым словам. С другой стороны, служба безопасности может проводить целенаправленные мероприятия по анализу всей этой информации, в том числе для поиска внутренних угроз. Ну и система может устанавливать сроки хранения данных в зависимости от содержимого этих данных.
Как быстро все можно накатить обратно?
Предположим, у нас есть сложная система с базой данных Oracle в качестве хранилища. Данные физически «размазаны» по нескольким серверам в одном ЦОД. Используется CommVault.
- Первый случай — пользователь взял и удалил данные со своей рабочей станции. Восстанавливает либо он сам, либо администратор: заходит в интерфейс, выбирает участок. Все остальное делает система. Пользователь видит красивый веб-интерфейс, администратор может работать с ним же или с консолью.
- Теперь у нас падает почтовый сервер Exchange. Сценарий все еще достаточно простой: опять же, либо сам пользователь, либо администратор определяет, какие данные необходимо восстановить, подключается, заходит в систему, открывает консоль восстановления, выбирает область, жмет кнопку «восстановить».
- Теперь у нас пропадают данные из базы нашего большого коммерческого приложения за сегодня. Например, все транзакции по купле-продаже. В этом случае бэкап-система будет стучаться к механизму RMAN, который есть в Oracle (это своего рода API по восстановлению данных). Но поскольку у нас уже все интегрировано, то администратор также только выбирает, что именно надо восстановить. Дальше уже сам RMAN вместе с бэкап-системой решает, что конкретно делать: восстанавливать целиком базу или какой-то TableSpace, т.е. отдельную таблицу, и так далее.
- А теперь у нас ночью взрывается ЦОД. В этом случае администратор выбирает другой ЦОД и накатывает на «чистое» оборудование последнюю копию. Система сама собирает ему наиболее свежий полный слепок из дедуплицированных данных и отдает нужную информацию каждой подсистеме и приложению. Обычные пользователи, скорее всего, даже не замечают произошедшего. Может быть и так, что в другом ЦОДе частично данные уже есть, среплицированы или просто восстанавливаются по расписанию, тогда все еще проще и восстановление происходит уже даже не на чистую систему.
Развитие систем от версии к версии
С развитием систем резервного копирования появляется поддержка новых коммерческих приложений. Речь о стандартных сервис-паках в рамках поддержки. У CommVault, например, есть хорошая политика выпускать апдейты совместимости к текущей версии, а не заставлять покупать следующий релиз: это удобно, потому что инфраструктура компании развивается постоянно.
В новых версиях софта появляются новые фичи, вроде копирования за один проход, например, с одновременным переносом в архив с файл-серверов. Или относительно недавно объединились операции архивирования и бэкапа в Exchange — теперь они делаются тоже за один проход. В последнее время появилась приятная для крупных облачных систем возможность архивирования виртуальных машин: если машина долго не используется или выключена, то, в соответствии с набором правил, она может быть удалена с платформы виртуализации, и останется только резервная копия.
Недавно появились клиенты для iOS и Android для управления копиями своей рабочей станции: удобно, если кто-то уезжает в командировку и забывает презентацию, например. Или когда в дороге ломается ноутбук. Здесь тоже не нужно будить админа в два ночи: пользователь может сделать все сам.
Вендоры
По отчету Gartner — среди лидеров, с которыми мы активно работаем, в частности, IBM, Symantec, ЕМС и CommVault.
Квадрат Gartner: лидеры сверху-справа, нишевые игроки снизу-слева.
IBM Tivoli Storage Manager (TSM) — довольно гибкий продукт в плане настройки и организации схемы резервного копирования на предприятии. Совмещая различные компоненты TSM, заказчик получает возможность выстраивать нужный функционал под свои задачи. Но, зачастую, для этого требуется больше времени на проектирование и внедрение. TSM часто используется в составе комплексных решений на базе оборудования и ПО от IBM.
EMC. Являясь компанией производящей не только ПО, но и оборудование, нацелена, прежде всего, на интеграцию всех своих решений. Поэтому если инфраструктура в большей мере построена на СХД Clariion, VNX, data domain, стоит посмотреть на продукты по резервному копированию от EMC, которые позволят обеспечить однородную структуру системы. Кстати, и продукт EMC Avamar тоже является программно-аппаратным решением.
Symantec представлен на рынке резервного копирования своим флагманским продуктом NetBackup, ориентированным на enterprise-сегмент, и более «легковесным» BackupExec, традиционно используемым в средах, построенных в основном на продуктах Microsoft. NetBackup славится поддержкой большого спектра операционных систем, СУБД и бизнес-приложений, развернутых в том числе в виртуальном окружении. А также умеет использовать продвинутые возможности современных СХД. NetBackup является хорошим выбором для среды с большой долей UNIX-систем. С недавнего времени продукты от Symantec поставляются не только как ПО, но и как ПАК, что ускоряет их развертывание и настройку.
CommVault. Пожалуй, самым важным является то, что это целостный продукт, который закрывает практически все потенциальные потребности заказчиков. Это унифицированная платформа, объединяющая в себе функционал копирования, архивирования и доступа к данным. Плюс традиционно хорошая интеграция с платформами виртуализации, дедупликация и интеграция с облачными хранилищами. Ну и как говорилось выше, очень сильно разгружает IT-отдел за счет грамотной политики прав доступа пользователей к элементам архива. По опыту ряда внедрений, CommVault будет хорошим выбором при наличии большого количества разнородного ПО и оборудования. В гомогенных средах на базе *unix возможно стоит думать о других продуктах, но в гетерогенных – она сразу позволяет избавиться от хаоса и всегда быть спокойным за то, что бэкап есть, он свежий, и быстро накатится обратно, если что. А это, как вы наверняка знаете, весьма бережет нервы.
В целом, надо смотреть, конечно, по месту. Если у вас есть вопросы, что выбрать под вашу инфраструктуру, пишите на AlBelyaev@croc.ru, поможем оценить все аспекты и предупредить о возможных подводных камнях.
Еще интересные ссылки
- Виртуализация хранения данных: как «размазать» их по всему ЦОДу, чтобы в случае попадания метеорита можно было продолжить работу.
- Обзор «быстрого» хранилища, использующегося для active-active систем в сфере Big Data.
- Ликбез про то, как делать катастрофоустойчивые решения у себя.
- Про разницу в проектировании ЦОДов и история одной аварии.
- Обзор решения EMC для бэкапа: большое хранилище в далеком ЦОДе и маленький сервер у вас, который за всем следит.
Автор: SveChu
