При создании вашей политики резервного копирования вашего OpenStack лучшей практикой будет стандартное резервное копирование. Например, проблема того, как часто вы должны делать резервные копии своих данных тесно связана с тем, как быстро вы должны восстановить утраченные данные.
![[Замечание]](../common/images/admon/note.png) | Замечание |
|---|---|
|
Если вы совсем не должны иметь никаких потерь данных, вам также следует сосредоточиться на реализации высокой доступности (High Availability). If you cannot have any data loss at all, you should also focus on a Руководство по высокой доступности OpenStack дает советы для устранения единой точки отказа, которая может привести к простою системы. Хотя этот докумнт и не дает исчерпывающих инструкций, он предлагает методы и техники, позволяющие избежать простоев и потерь данных. |
Дополнительный анализ резервного копирования включают в себя:
-
Сколько резервных копий стоит хранить?
-
Должны ли резервные копии храниться за пределами площадки?
-
Как часто стоит проверять резервные копии?
Политика восстановления (или, по крайней мере тестирование восстановления) является не менее важной, чем политика резервного копирования.
Поскольку OpenStack состоит из многих компонентов и перемещающихся частей, резервное копирование критически важных данных достаточно простое.
В этой главе описывается только как выполнять резервное копирование файлов конфигурации и баз данных, которые необходимы для работы различных компонентов OpenStack. В данном разделе не описывается, как выполнять резервное копирование объектов внутри систем хранения объектов или данных, содержащихся внутри систем блочного хранения. Как правило, эти области отдаются на откуп пользователю для самостоятельного резервного копирования.
Приводимый пример архитектуры OpenStack определяет контроллер облака в качестве сервера MySQL. Этот сервер MySQL содержит базы данных для nova, glance, cinder и keystone. Поскольку все эти базы данных находятся в одном месте, создание резервной копии базы данных очень простое:
# mysqldump --opt --all-databases > openstack.sql
Если вы хотите выполнить резервное копирование только одной базы данных, вы можете вместо приведенного выше примера выполнить:
# mysqldump --opt nova > nova.sql
где nova база данных, резервную копию которой вы хотите сделать.
Вы можете легко автоматизировать процесс путем создания задания cron, которое ежедневно выполняет следующий сценарий:
#!/bin/bash
backup_dir="/var/lib/backups/mysql"
filename="${backup_dir}/mysql-`hostname`-`eval date +%Y%m%d`.sql.gz"
# Dump the entire MySQL database
/usr/bin/mysqldump --opt --all-databases | gzip > $filename
# Delete backups older than 7 days
find $backup_dir -ctime +7 -type f -delete
Приведенный сценарий выгружает всю базу данных MySQL и удаляет любые резервные копии старше 7 дней.
В данном разделе обсуждается, какие файлы и каталоги должны подвергаться регулярному резервному копированию со стороны службы.
Каталог /etc/nova должен регулярно резервироваться
и в контроллере облака и на вычислительных узлах.
Если все ваши журналы приходят в центральное место,
/var/log/nova не должен резервироваться.
Настоятельно рекомендуется использовать центральный сервер протоколирования
или выполнять резервное копирование каталога журналов..
/var/lib/nova является еще одним важным каталогом для резервного
копирования. Исключением из этого правила является подкаталог /var/lib/nova/instances
на вычислительных узлах. Этот подкаталог содержит образы KVM запущенных
на исполнение экземпляров. Вам следует создавать резервную копию этого подкаталога
только если у вас есть необходимость создавать резервные копии всех экземпляров. В большинстве случаев
в этом нет необходимости, однако это может меняться от облака к облаку и ваших уровней служб.
Также имейте в виду, что создание резервной копии запущенного экземпляра KVM может привести к тому,
что он не сможет загружаться надлежащим образом, будучи восстановленным из резервной копии.
/etc/glance и /var/log/glance
соблюдают те же правила, что и их аналоги в nova.
Для /var/lib/glance также необходимо создавать резервную копию.
Примите к сведению особенности /var/lib/glance/images.
Если вы используете сервера glance на основе файлов, /var/lib/glance/images
является местом, где хранятся образы и необходимо быть аккуратным.
Существует два способа обеспечить устойчивость этого каталога. Первый заключается в том, что этот каталог работает в RAID массиве. Если происходит сбой диска, каталог остается доступным. Второй способ заключается в использовании инструментов, например, rsync, для репликации образов на другой сервер:
# rsync -az --progress /var/lib/glance/images \ backup-server:/var/lib/glance/images/
/etc/keystone и /var/log/keystone
соблюдают те же правила, что и их аналоги в других компонентах.
/var/lib/keystone,
хотя он и не должен содержать никаких используемых данных, также может резервироваться на всякий случай.
/etc/cinder и /var/log/cinder
соблюдают те же правила, что и их аналоги в других компонентах.
/var/lib/cinder также должен резервироваться.
/etc/swift является очень важным и подлежит резервному копированию.
Этот каталог содержит файлы настройки swift, а также файлы кольца и
файлы- изготовитель кольца, в случае их утраты предоставление данных в вашем кластере невозможно.
Лучше всего копировать файлы-изготовители на все узлы хранения вместе с файлами кольца.
Множество резервных копий в этом случае распределено по вашему кластеру хранения.
Восстановление резервных копий является достаточно простым процессом.
Для начала убедитесь, что службы, которые вы собираетесь восстанавливать, не
запущены. Например, для полного восстановления nova
в контроллере облака вначале остановим все службы nova:
# stop nova-api # stop nova-cert # stop nova-consoleauth # stop nova-novncproxy # stop nova-objectstore # stop nova-scheduler
Теперь мы можем импортировать предварительно сохраненные базы данных:
# mysql nova < nova.sql
Также вы можете восстановить резервные копии каталогов nova:
# mv /etc/nova{,.orig}
# cp -a /path/to/backup/nova /etc/
Когда файлы восстановлены, запустите полное резервное копирование:
# start mysql # for i in nova-api nova-cert nova-consoleauth nova-novncproxy nova-objectstore nova-scheduler > do > start $i > done
Другие службы следуют аналогичным процессом со своими соответствующими каталогами и базами данных.
Резервное копирование и последующее восстановление является одной из наиважнейших задач, которую изучают системные администраторы. Однако, каждая система имеет собственные элементы, требующие внимания. Заботясь о своей базе данных, обслуживании образов и соответствующих местоположениях файловой системы, вы можете быть уверены, что вы сможете справиться с любым требующим восстановления событием.