Приветствую, читатели!
Дело было вечером, делать было нечего, и тут я вспомнил — я же хотел поделится с сообществом своим недавним боевым опытом.
Было у меня задание — автоматизировать процедуру резервного копирования и создать процедуру восстановления Graylog-сервера.
Сервер был для меня неизвестным, ранее сталкиваться не приходилось.
Ну что ж, посидел-почитал, да подумал — ничего сложного. Однако поиски в Google показали, что не каждый день такая задача появляется, ибо информации практически не было.
«Где наша не пропадала?» — подумал я, все должно быть предельно просто, скопируем конфигурационные файлы и вуаля.
Сделаю небольшое лирическое отступление, дабы описать Graylog-сервер и его составляющие.
Что такое Graylog-сервер?
Graylog2 — это open-source система для сбора и анализа статистики, позволяющий обрабатывать данные достаточно гибко. В качестве агента — он использует syslog. Данные посылаются с узлов посредством syslog и агрегируются Graylog-сервером.
В качестве базы данных для хранения контента и настроек — используется MongoDB.
Ну и самая громоздкая часть сервера — это ElasticSearch, мощный инструмент для индексирования данных и поиска по ним.
Процесс резервного копирования
Задание начинало приобретать очертания. Необходимо было копировать содержимое MongoDB и индексы ElasticSearch, а также конфигурационные файлы каждой из частей Graylog.
Остановив предварительно сервис graylog-server и elasticsearch, я приступил к резервному копированию.
/etc/init.d/graylog-server stop
/etc/init.d/elasticsearch stop
/etc/init.d/chef-client stopВ моем случае, в MongoDB у нас находилась база под названием graylog2. Дабы получить копию оной, я создал dump базы следующей командой:
logger -s -i "Dumping MongoDB"
mkdir -p path-to-backup
mongodump -h 127.0.0.1 -d graylog2 -o path-to-backup/Таким образом, в директории path-to-backup cоздается dump базы данных «graylog2», находящейся на localhost (можно указывать также удаленный узел).
Следующий шаг — резервное копирование и сжатие индексов ElasticSearch. В нашем случае, за 7 месяцев работы, собралось около 12 Гбайт индексов. По умолчанию, не было настроено их сжатие, что могло бы уменьшить затраты места под хранение в разы.
Директория, хранящая индексы, в нашем случае находилась на примонтированном разделе. За указание на место хранения индексов отвечает параметр path.data в /etc/elasticsearch/elasticsearch.yml. Также, немаловажным параметром (без него не заработает, никак) — является имя кластера, заданное в том же конфигурационном файле параметром cluster.name.
Для резервного копирования индексов я использовал следующую команду, которая сжимала и упаковывала содержимое директории с индексами:
logger -s -i "Dumping MongoDB"
tar -zcf path-to-backup/elasticsearch.tar.gz --directory=path-to-indices graylog2В результате, из 12 Гбайт исходной информации получился архив в 1.8 Гбайта. Что ж, уже неплохо…
Далее, оставалось скопировать конфигурационные файлы Graylog, MongoDB и ElasticSearch. Стоит отметить, что в конфигурационном файле ElasticSeach — elasticsearch.yml — содержался также параметр node.name, представляющий собой hostname нашего сервера. Это важно в том случае, если восстановление Graylog-сервера будет происходить на узле с другим hostname. Точно также содержимое конфигурационного файла Graylog — graylog2.conf — содержало настройки под нашу конкретную базу MongoDB, с используемым в ней для доступа пользователем и паролем.
Упоминаю я это все к тому, что бездумное копирование файлов конфигурации к добру не приведет, и это «не наши методы, Шурик» (с)
После того, как все конфигурационные файлы были упакованы и скопированы — осталось передать данные файлы на сервер резервного копирования. Тут, на самом деле, каждый волен делать как хочет и как того требует инфраструктура.
В моем случае копирование осуществлялось при помощи scp с использованием ключа для аутентификации:
logger -s -i "Copying backups to Backup server"
scp -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -r -i /root/.ssh/id_rsa path-to-backup backup-user@backup-server: logger -s -i «Copying backups to Backup server: DONE»
Подытоживая процесс резервного копирования, я бы хотел выделить шаги, которые необходимо предпринять:
- Остановка сервисов Graylog и ElasticSearch
- Создание dump-а (копии) MongoDB базы данных
- Копирование и архивирование директории индексов ElasticSearch
- Копирование конфигурационных файлов
Процесс восстановления Graylog-сервера
Неудивительно, что процесс восстановления — зеркальное отображение процесса резервного копирования.
Ниже я приведу небольшой bash-скрипт, который восстанавливает Graylog-сервер:
/etc/init.d/graylog-server stop
/etc/init.d/elasticsearch stop
scp -r user@backup-server/graylog-backup/* ./
tar zxf graylog2-mongodump.tar.gz
tar zxf elasticsearch.tar.gz
mongorestore -d graylog2 ./graylog2
mv ./elasticsearch/* /opt/elasticsearch/data/
mv ./graylog2.conf /etc/
mv ./elasticsearch.yaml /etc/elasticsearch/elasticsearch.yml
/etc/init.d/graylog-server start
/etc/init.d/elasticsearch start
Скрипт копирует архивы с backup-server, распаковывает их, потом восстанавливается база graylog2 в MongoDB и перемещаются индексы ElasticSearch в директорию по-умолчанию. Также копируются конфигурационные файлы ElasticSearch и Graylog-сервера. После этого запускаются сервис ElasticSearch и Graylog-server.
Для того, чтобы удостовериться в целостности восстановления можно поступить следующим образом:
- зайти на web-интерфейс сервера и удостоверится, что все Messages, Hosts, Streams и параметры присутствуют в идентичном состоянии
- сравнить результат curl-запроса curl -XGET " localhost:9200/graylog2_0/_mapping
Процесс простой, проверенный на нескольких экземплярах. Однако мало-документированный. Стоит также отметить, что с релизом ElasticSearch v.1 — он упрощается введением процедуры получения «слепков» индексов, но сути это не меняет.
Надеюсь, что кому-то данная статья поможет. Спасибо за внимание.
P.S. Отдельное спасибо моему коллеге Siah, который сделал этот скрипт красивым и поддающимся автоматизации. Ну а я — ленивый топикстартер :)
Автор: MistiC
