В предыдущем руководстве вы развернули приложение. Теперь нужно разработать план восстановления.
План восстановления – это набор документированных процедур для восстановления работы компонентов приложения после возможных сбоев или ошибок администрирования. Создание плана восстановления также поможет вам определить основные компоненты и данные сервера приложений.
Самый базовый план восстановления может состоять из списка шагов, которые вы предприняли для первоначального развертывания сервера, с дополнительными процедурами восстановления данных приложения из резервных копий.
Более эффективный план восстановления может, помимо хорошей документации, использовать сценарии развертывания и инструменты управления конфигурацией, такие как Ansible, Chef или Puppet, чтобы помочь автоматизировать и ускорить процесс восстановления.
Данное руководство поможет создать базовый план восстановления для приложения WordPress.
Примечание: Требования вашего приложения, скорее всего, будут отличаться, но здесь вы найдёте много полезных инструкций, с помощью которых сможете создать индивидуальный план.
Цели плана восстановления
Цели данного базового плана заключаются в том, чтобы восстановить работу любого сервера инфраструктуры, функциональность и данные приложения. Для достижения этой цели нужно провести инвентаризацию каждого сервера, определить, какие данные необходимо скопировать, и написать план восстановления на основе ресурсов. Конечно, после восстановления необходимо проверить работу приложения.
Создайте план восстановления для каждого сервера:
- Сервера БД,
- Серверов приложений,
- Балансировщика нагрузки.
Начнем с сервера баз данных.
1: Восстановление сервера баз данных
Установка СУБД состоит из следующих этапов (их можно отследить в предыдущем руководстве):
- Установка MySQL
- Настройка MySQL
- Перезапуск MySQL
- Создание базы данных и пользователей
План восстановления сервера баз данных
Зная этапы создания сервера баз данных, можно понять, что все его компоненты можно воссоздать с нуля, кроме самого содержимого базы данных. В данном примере в базе данных хранится большая часть данных приложения WordPress (то есть заметки в блоге). Это означает, что для восстановления сервера баз данных необходимо поддерживать резервные копии БД. Также нужно создать резервную копию конфигурационного файла MySQL, так как он содержит пользовательские параметры.
Основываясь на полученных данных о сервере, схема плана восстановления сервера базы данных будет выглядеть так:
Резервное копирование:
- База данных MySQL;
- Конфигурационный файл MySQL.
Этапы восстановления:
- Установка MySQL.
- Восстановление конфигурационного файла MySQL (при необходимости изменение прослушиваемого IP-адреса).
- Восстановление БД.
- Перезапуск MySQL.
Теперь, когда у вас есть план восстановления сервера баз данных, вы должны подробно описать шаги восстановления и обеспечить сохранение требуемых резервных копий. Попробуйте подробно описать этапы восстановления самостоятельно: они могут отличаться в зависимости от настройки и включают в себя индивидуальные параметры.
Примечание: В данном примере можно использовать предыдущее руководство по развертыванию приложений в качестве документации.
2: Серверы приложений
Согласно предыдущему руководству, установка серверов приложений состоит из следующих этапов:
- Установка и настройка Apache и PHP.
- Загрузка и настройка приложения (WordPress).
- Копирование файлов приложения в DocumentRoot.
- Репликация файлов приложения на всех серверах приложений.
План восстановления сервера приложений
Просмотрев все этапы настройки сервера, можно увидеть, что все компоненты сервера приложений можно воссоздать с нуля, кроме файлов приложений. В данном случае к файлам приложения относятся файлы конфигурации WordPress (включая данные о подключении к БД), установленные плагины WordPress и загруженные файлы. Это означает, что для восстановления сервера приложений необходимо поддерживать резервное копирование файлов приложений.
Файлы приложения реплицируются несколькими серверами приложений; если все серверы приложений прекратили работу или данные были каким-то образом повреждены, достаточно восстановить данные из резервных копий. Если хотя бы один сервер приложений работает нормально и использует неповрежденные файлы приложения, репликация файлов восстановит данные приложения на новом сервере приложений.
Руководствуясь полученными данными о сервере приложений, можно разработать такую схему плана восстановления:
Резервное копирование:
- Файлы приложения (в данном случае каталог /var/www/html/).
Этапы восстановления:
- Установка и настройка Apache и PHP.
- Репликация файлов приложения на всех серверах приложений с рабочего сервера.
- Восстановление данных из резервной копии (если выполнить репликацию файлов невозможно и все серверы приложений не работают).
Имея план восстановления сервера приложений, необходимо выяснить подробности каждого этапа восстановления и обеспечить сохранение требуемых резервных копий. Поскольку каждая установка имеет индивидуальные требования, рекомендуем самостоятельно описать этапы восстановления (они будут отличаться в зависимости от фактической настройки).
Примечание: В данном примере можно использовать предыдущее руководство по развертыванию приложений в качестве документации.
3: Восстановление балансировщика нагрузки
Согласно предыдущему руководству, установка балансировщика состоит из следующих этапов:
- Получение сертификата SSL.
- Установка HAProxy.
- Настройка HAProxy.
- Перезапуск HAProxy.
План восстановления балансировщика нагрузки
Все компоненты балансировщика, кроме SSL-сертификата и связанных с ним файлов, можно восстановить с нуля. Это значит, что для восстановления балансировщика необходимо предоставить резервную копию сертификата и конфигурационного файла HAProxy (так как в нем есть пользовательские параметры).
Согласно всем этим требованиям можно построить такую схему восстановления сервера:
Резервное копирование:
- Файлы сертификата SSL.
- Конфигурационный файл HAProxy.
Этапы восстановления:
- Восстановление сертификата SSL.
- Установка HAProxy.
- Восстановление конфигураций HAProxy.
- Перезапуск HAProxy.
Имея план восстановления балансировщика, необходимо выяснить подробности каждого этапа восстановления и обеспечить сохранение требуемых резервных копий. Поскольку каждая установка имеет индивидуальные требования, рекомендуем самостоятельно описать этапы восстановления.
Примечание: В данном примере можно использовать предыдущее руководство по развертыванию приложений в качестве документации.
4: Дополнительные рекомендации
Если для восстановления одного из компонентов требуется переконфигурировать любые другие компоненты (например, если изменился IP-адрес сервера базы данных и т. п.), обязательно включите соответствующие этапы в план восстановления.
Также необходимо написать планы восстановления для всех других компонентов настройки (для серверов DNS и компонентов, которые вы добавите в дальнейшем: серверов резервного копирования, мониторинга и логирования). По мере развития инфраструктуры нужно пересматривать и обновлять существующие планы восстановления.
В руководстве не описано, как создавать и восстанавливать резервные копии. Речь об этом пойдет в следующей части этой серии руководств.
Подготовив планы восстановления компонентов, сохраните эту информацию на отдельном сервере.