Аварийное восстановление Linux Red Hat. Disaster Recovery & High Availability с Bacula Enterprise.

Содержание

В данном документе подробно рассматриваются принципы и процедуры, которые необходимо соблюдать для реализации стратегии аварийного восстановления и повышения доступности (disaster recovery & high availability) ИТ-систем с Bacula Enterprise Edition.

Введение в аварийное восстановление (disaster recovery)

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

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

Системы GNU/Linux Red Hat для high availability

Данный документ содержит решения для ПО Bacula Enterprise 4.0 и более поздних версий. Решения для аварийного восстановления и повышения доступности описаны для систем GNU/Linux Red Hat а также баз данных PostgreSQL.

1 Аварийное восстановление (disaster recovery)

1.1 Предварительные рекомендации для disaster recovery planning

На случай наступления аварийной ситуации пользователь должен иметь заранее подготовленный аварийный план (disaster recovery plan) по восстановлению системы. В противном случае объем работы будет значительно больше. Например, если вы ранее не сохраняли информацию на своем жестком диске, вы не сможете восстановить ее в случае замены диска.

  • Убедитесь в том, что у вас есть подходящий загрузочный файл для резервной копии системы и резервная копия каталога, и что они сохранены на альтернативной машине. Это позволит вам быстро восстановить систему.
  • Убедитесь в том, что каталог сохраняется каждый день. Вы также можете добавить бинарные и конфигурационные файлы Bacula в набор файлов FileSet резервной копии BackupCatalog.
  • Если есть возможность, ежедневно копируйте ваш каталог на альтернативную машину. Если у вас есть подходящий загрузочный файл, данная процедура не обязательна, но может быть полезной, если вы не хотите перезагружать все подряд.
  • Сделайте копию файлов Bacula с расширением .conf, в частности файлов bacula-dir.conf и bacula-sd.conf, поскольку в случае отказа сервера, эти файлы потребуются для его восстановления, а их довольно сложно восстановить из памяти. Использование исходной версии системы управления, например, git или svn совместно с удаленным репозитарием в директориях с конфигурационными файлами и скриптами может помочь вам отслеживать конфигурационные изменения создавать бэкап удаленно после каждого изменения.
  • Прежде чем выполнять восстановление в аварийной ситуации, проведите тесты с использованием USB накопителя или CD диска.
  • Убедитесь в том, что вы «запомнили» структуру разделов дисков для всех серверов. Процесс можно упростить при использовании USB-ключа Bacula Systems для Linux и Windows.

1.2 Рекомендации по организации хранилища данных

Есть ли у вас стороннее хранилище для резервных копий данных на случай, если сгорит или будет иным способом разрушено здание, в котором располагаются ваши компьютеры и сервера? Хранить данные «на стороне» можно на магнитных лентах, которые, в свою очередь, можно хранить в хранилище или даже в банковской ячейке. Все гораздо сложнее, если речь идет о большом дисковом массиве, с которым необходимо обращаться с особой осторожностью. Конечно, вы можете организовать перекрестное резервное копирование данных с использованием нескольких ЦОД, если у вас они есть. Или же можно создавать копии данных с помощью услуг поставщика облачных услуг. Однако использование облачного хранилища может обернуться весьма большими затратами, особенно, если речь идет о хранении больших объемов данных. Чтобы снизить не только затраты, но и нагрузку на сеть, можно воспользоваться методом создания инкрементальных резервных копий. Однако также стоит подумать о скорости восстановления данных. Некоторые поставщики облачных услуг предоставляют доступ к своим ЦОД в экстренных ситуациях и «заливают» данных на диски непосредственно из хранилища.

disaster recovery

Рисунок 1. Перекрестное резервное копирование с использованием нескольких ЦОД

аварийное восстановление

Рисунок 2. Использование хранилища провайдера облачных сервисов

Иногда, чтобы оправдать инвестиции на создание инфраструктуры из дорогостоящих дисковых массивов, пользователи предпочитают хранить тома Bacula на тех же носителях, поскольку большие дисковые массивы обеспечивают избыточность, возможность использования оптоволоконных маршрутизаторов, множество каналов, резервных дисков, и т.д. Таким образом, может создаваться ощущение надежной сохранности данных. Однако существует вероятность, что все пойдет не так, и тогда, согласно закону Мерфи, вы потеряете не только текущие данные, но и резервные копии.

1.3 Зеркалирование данных между ЦОД

Восстановление системы из резервной копии без полностью функциональной резервной копии – задача не из простых. Зеркалирование серверов с резервными копиями Bacula между несколькими ЦОД поможет избежать стресса в критической ситуации. В следующем разделе мы расскажем о том, как снизить время простоя службы резервного копирования и восстановления Bacula при помощи запуска службы Director и каталога в кластерном режиме с репликацией конфигурационных, бинарных файлов и БД. Если вы приняли решение о зеркалировании серверов с Bacula Storage Daemon, вам следует решить, каким образом тома будут доступны на обои хостах. В случае большого объема данных зеркалирование может в два раза увеличить стоимость решения. Если вы решите сделать область хранения доступной для двух узлов, то данное решение должно согласовываться с планом аварийной защиты. Например, если сгорит здание, в котором хранится устройство хранения данных (магнитные ленты или диски) и первичный сервер Storage Daemon, сгорит, зеркальный сервер Storage Daemon будет практически бесполезен для восстановления данных. В таком случае вы будете защищены исключительно от отказа серверного оборудования, на котором храниться Storage Daemon. В такой ситуации можно принять решение о зеркалировании только критических пулов.

2 Высокая доступность ИТ-систем с Bacula
 (high availability)

2.1 Как выбрать решение для high availability, которое соответствует вашим потребностям

Макс. время простоя Решение Примечания
< 5 мин Кластер высокой доступности и репликация БД на уровне блока Необходим навык использования технологии кластеризации, например HACMP, HeartBeat- /Pacemaker, и т.д.
< 1-3 часов Резервные аппаратные средства и репликация БД Необходима четкая процедура для восстановления Bacula и использования внутренней репликации PostgreSQL.
< 12 часов Резервные аппаратные средства и репликация БД Необходима четкая процедура для восстановления Bacula. Вы можете восстановить каталог PostgreSQL с момента последнего резервного копирования.

Если произойдет отказ сервера, на котором храниться каталог, будут потеряны все записи о резервных копиях каталога. Отслеживание электронных писем и загрузочных файлов поможет восстановить файлы, но данный способ не совсем удобен. Чтобы избежать слежностей, можно воспользоваться функцией PostgreSQL Continuous Archiving и создать бинарные резервные копии каталога, а также не пользоваться стандартной процедурой создания SQL дампа. Смотрите http://www.postgresql.org/docs/9.0/

Архитектура Bacula Enterprise

high availability cluster

2.2 Повышение доступности системы с помощью кластерного решения (high availability cluster)

Данное решение представляет собой высокотехнологичное решение для Bacula. Если вы не знакомы с данной технологией, вы можете столкнуться с высокими затратами на обучение. Ваши решения должны быть продиктованы вашими потребностями. С помощью резервного оборудования можно интегрировать решения Bacula и стандартные кластерные решения на базе Linux, например Heartbeat или Pacemaker (смотрите http://www.linux-ha.org)

В случае отказа диспетчер ресурсов типа Pacemaker или Heartbeat автоматически инициирует восстановление и обеспечит доступность ПО с одной из работающих машин в кластере. Pacemaker – это новая версия Heartbeat, которая позволяет работать со сложными конфигурациями кластеров. Bacula не требует испольования сложных кластеров, поэтому рекомендуем вам создавать простую конфигурацию типа Primary/Slave. Остальная часть документа будет посвящена использованию Heartbeat в качестве диспетчера ресурсов. Репликацию данных PostgreSQL сервера можно выполнить с помощью инструмента DRBD (репликация данные с использованием блочных устройств) от LINBIT (смотрите http://linbit.com)

2.2.1 Архитектура high availability cluster

Для большого предприятия, возможно, потребуется работа нескольких серверов Storage Daemon для службы Director (SD1 и SD2 на рисунке ниже) А еще вам, возможно, потребуется выделенный сервер PostgreSQL Catalog для Director (SGBD на рисунке ниже).
Все сервера должны быть оснащены:

high availability cluster

Рисунок 4. Использование Bacula в средах нескольких ЦОД (high availability cluster)

 

  • RAID дисками с возможностью обратной записи
  • Множественными Ethernet-каналами с возможностью определения и обработки отказа при использовании модуля ядра в качестве связующего элемента. Эти каналы должны быть подключены к различному независимому сетевому оборудованию
  • Оперативно подключаемым оборудованием и резервным источником питания. В данной архитектуре каждый сервер, используемый для установки компонентов Bacula, должен быть защищен с использованием второго сервера, расположенного в другом ЦОД. Каждая пара кластерных узлов должна иметь выделенный прямой оптоволоконный Ethernet-канал и должна поддерживать механизм STONITH. В случае наличия единой точки отказа у всех серверов Storage Daemon (например, по причине того, что не использовался метод зеркалирования дисков между ЦОД, или же прямого подключения авточенджера), вам не обязательно защищать их на одном уровне. При этом, будет достаточно использовать несколько резервных элементов.
2.2.2 Кластерные ресурсы

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

Как правило, агенты ресурсов представлены в виде скриптов оболочки, однако, они могут быть написаны на любом языке (например, C, Python или Perl). При использовании ПО Bacula будут использоваться следующие стандартные ресурсы в диспетчере ресурсов:

  • Виртуальный IP адрес
red hat high availability clustering

Рисунок 5. Определение Pacemaker/Heartbeat

  • Служба Bacula Director
  • Службы Bacula Storage
  • Резервные файловые системы
  • Служба PostgreSQL Catalog
  • Файловая система с данными и файлами конфигурации PostgreSQL

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

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

2.2.3 Синхронизация конфигурации Bacula

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

2.2.4 Каталог PostgreSQL

Защита SQL каталога (PostgreSQL или MySQL) – задача довольно масштабная. Существует множество различных способов выполнения поставленной задачи. Наиболее сложной частью является создание конфигурации с высокой доступностью PostgreSQL. Чтобы перезапустить службу на вторичном узле после сбоя, данные должны быть реплицированы между узлами.

Для репликации можно использовать высокотехнологичное оборудование, стандартную репликацию PostgreSQL, или репликацию DRBD (RAID1 для всей сети, смотрите http://linbit.com)

В системах на основе открытого кода регулярно применяются кластеры, использующие решения на базе HeartBeat, DRBD и PostgreSQL. Довольно просто найти информацию и источники по таким видам кластеров.

Рисунок 6. Архитектура DRBD

DRBD – это программный модуль на основе открытого исходного, разрабатываемый более 10 лет. Он был официально включен в состав Linux Kernel 2.6.33. Он прост, характеризуется высокой производительностью и гибкостью. Он поддерживает технологию обеспечения безопасных транзакций. Все это значит, что DRBD позволяет реплицировать данные безопасным и надежным способом, не зависимо от нагрузки. Служба поддержки LINBIT оказывает помощь при установке модуля, обеспечивает круглосуточную поддержку, а также оказывает поддержку при возникновении единичного случая отказа.

Стоимость данного метода репликации данных может на 10-15% увеличить затраты на использование дискового хранилища, однако, модуль обладает преимуществами, гарантирующими безопасность и надежную работу системы во время операций по переходу в режим резервной работы/режим обоюдной поглощающей конфигурации. Благодаря использованию модуля практически отсутствует вероятность потери данных при использовании неправильной последовательности команд. Потоковая репликация с использованием PostgreSQL выполняется быстрее, однако, требует тщательного соблюдения процедур перед повторной активацией репликации. Поскольку DRBD отлично интегрируется с HeartBeat (LINBIT является стороной, оказывающей официальное сопровождение диспетчера ресурсов HeartBeat), после инициализации и синхронизации томов, HeartBeat должен получить правильное определение.

3 Стандартные решения по аварийному восстановлению (disaster recovery)

Поскольку ПО Bacula позволяет создавать резервные копии и восстанавливать любые системные файлы Unix/Linux, например, файлы char и блочные файлы, а также файлы hardlinks, symlinks и т.д, его можно использовать для восстановления системы напрямую.

3.1 Подготовка к аварийному восстановлению системы

Самый безопасный способ аварийного восстановления системы – это предварительное создание полного бэкапа.

Если вы используете утилиту для восстановления системы на «голое железо», вам потребуется запустить инструмент анализа сети и диска до создания резервной копии системы.

Возможно, вам потребуется исключить несистемные данные из объема данных для бэкапа, например, данные из директории /home, и использовать утилиту для создания резервных копий этих файлов с использованием другой политики. Если ваша сеть включает множество идентичных серверов (на которых установлена одна и та же ОС, одной и той же версии), вы можете использовать функцию Bacula Enterprise File Deduplication.

3.2 Стандартное аварийное восстановление систем GNU/Linux

Вам необходимо выполнить следующие шаги по восстановлению системы из резервной копии и ее запуску:

  1. Загрузите новую или восстановленную систему с использованием USB носителя или CD диска для аварийного восстановления
  2. Установите сетевой подключение (по локальной сети)
  3. Повторно разбейте жесткий диск(и) на разделы так, как они были разбиты ранее
  4. Повторно отформатируйте разделы
  5. Установите или запустите утилиту Bacula File Daemon (статическую версию)
  6. Выполните восстановление всех файлов с использованием Bacula
  7. Повторно установите программу начальной загрузки
  8. Перезагрузитесь

Более подробную информацию относительно восстановления вы найдете в документации к ПО Bacula Enterprise.

3.3 Аварийное восстановление GNU/Linux на «голое железо»

ПО Bacula Systems содержит утилиту для восстановления системы Linux на «голое железо», что, в отдельном случае, позволяет достаточно быстро восстанавливать сервера. Эта утилита была разработана для автоматического сбора и обработки данных сетевой конфигурации и структуры дисков, необходимых для восстановления системы, после создания каждого полного бэкапа.

  1. Загрузите новую или восстановленную систему с использованием USB носителя или CD диска для восстановления системы на “голое железо”
  2. Установите сетевое подключение (по локальной сети). Не продолжайте до тех пор, пока не будет установлено сетевое подключение
  3. Повторно разбейте жесткий диск(и) на разделы так, как они были разбиты до использования утилиты для восстановления на «голое железо»
  4. Выполните восстановление всех файлов с использованием Bacula , используя утилиту восстановления на «голое железо»
  5. Повторно установите программу начальной загрузки
  6. Перезагрузитесь

3.4 Аварийное восстановление Windows на «голое железо»

ПО Bacula Systems содержит утилиту для восстановления системы Windows на «голое железо», что, в отдельном случае, позволяет достаточно быстро восстанавливать сервера. Более подробную информацию вы найдете в документации по восстановлению Windows на «голое железо» с использованием решений Bacula Systems.

3.5 Аварийное восстановление конфигурации Bacula

При использовании пакетов программ Bacula Enterprise все файлы, которые необходимы для запуска и конфигурирования ПО Bacula, располагаются в каталоге /opt/bacula. Установка основных зависимостей, например, клиентских библиотек PostgreSQL или MySQL (с использованием формата пакетов ПО Bacula Systems), и восстановление этого каталога на новом сервере предполагает быстрый запуск новой копии Bacula. Этот метод может быть использован и для восстановления службы Director, как описано в разделе 3.6.

3.6 Аварийное восстановление службы Director

Если ваши конфигурационные и бинарные файлы сохранены на другом резервном сервере (например на сервере Storage Daemon, или сервере каталога) как рекомендуется, вы сможете восстановить службу Director, выполнив следующие действия:

  • Скорректируйте путь к новому бинарному файлу в загрузочном скрипте bacula-ctl-dir
  • Закомментируйте все директивы Job Schedule в файле bacula-dir.conf
  • Скопируйте IP адрес службы Director на временный сервер
  • Убедитесь в том, что временный сервер Director может подключаться к серверу, на котором расположен каталог
  • Запустите временную службу Director Daemon
  • Запустите процедуру восстановления на «голое железо» или стандартную процедуру восстановления на сервере с Director
  • Остановите исполнение временной службы Director и деконфигурируйте IP адрес Director
  • Перезагрузитесь для использования обновленной службы Director
  • Протестируйте службу Director, создав одну резервную копию и выполнив восстановление файлов на сервере Storage Daemon

Если службв Director и каталог расположены на одном хосте, вам необходимо сначала восстановить каталог или использовать загрузочный файл.

3.7 Аварийное восстановление Storage Daemon

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

3.8 Аварийное восстановление каталога

3.8.1 Использование процедуры горячего резервирования или передачи журналов

NTT разработала систему репликации без разделения ресурсов для PostgreSQL с передачей журналов транзакций. Цель решения – минимизировать время простоя и увеличить производительность системы. Таким образом, время восстановление системы после отказа может быть сокращено до 15 секунд, а непредвиденные расходы могут увеличиться на 7% и то, в случае самых сложных задач в текущей реализации решения.

Рисунок 7: Горячее резервирование каталога PostgreSQL

Данный метод позволяет обеспечить доступность валидной копии каталога в сети. В случае отказа сервера с каталогом вам нужно будет лишь активировать PostgreSQL в режиме master на узле с резервной копией, изменить виртуальный IP адрес и перезапустить службу Director.

3.8.2 Использование резервной копии каталога

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

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