Резервное копирование и восстановление кластера
Установка и настройка / Ключ-АСТРОМ Managed / Эксплуатация / Резервное копирование и восстановление кластера
Чтобы настроить автоматическое резервное копирование для управляемого кластера Ключ-АСТРОМ
1. В меню Ключ-АСТРОМ выберите «Настройки»> «Резервное копирование».
2. Включите резервное копирование кластера и выберите область действия:
- Пользовательские сеансы могут содержать конфиденциальную информацию.
Исключите сеансы пользователей из резервной копии, чтобы соответствовать требованиям GDPR.
- Исключите данные метрик таймсерий из резервной копии, если ваши исторические данные не актуальны и вы хотите сохранить только данные конфигурации.
- Включите резервную копию событий Log Monitoring v2.
3. (Необязательно) Выберите центр обработки данных. Этот шаг требуется только в том случае, если у вас есть развертывание с несколькими центрами обработки данных (развертывание с высокой доступностью Premium). Дополнительные сведения о развертываниях высокой доступности Premium см. В разделах Высокая доступность для нескольких центров обработки данных и Аварийное восстановление из резервной копии.
4. Укажите полный путь к подключенному сетевому файловому хранилищу, где будут храниться архивы резервных копий.
5. Настройте время начала.
Автоматическое резервное копирование кластера
Управляемые данные конфигурации Ключ-АСТРОМ (правила именования, теги, зоны управления, профили предупреждений и т. Д.), Данные метрик временных рядов и пользовательские сеансы могут быть скопированы автоматически. Для максимальной устойчивости рекомендуется сохранять файлы резервных копий за пределами предприятия.
- Каждый узел должен быть подключен к общей файловой системе, а общая файловая система должна быть смонтирована в одном и том же общем каталоге на каждом узле.
- Пользователю, запускающему службы Ключ-АСТРОМ, необходимы разрешения на чтение и запись для общей файловой системы.
- Подключение к общей файловой системе должно быть доступно при перезапуске системы.
- Вы можете добавить точку монтирования в
fstab
или использовать инструмент управления дисками, чтобы сделать монтирование общей файловой системы постоянным. - Протокол, используемый для передачи данных, зависит от вашей конфигурации. Мы рекомендуем NFSv4. Из-за низкой производительности и отказоустойчивости мы не рекомендуем CIFS.
Точка монтирования общей файловой системы при загрузке системы
Если точка монтирования общей файловой системы недоступна при загрузке системы, Ключ-АСТРОМ не запустится на этом узле. Это может привести к недоступности кластера. Чтобы запустить Ключ-АСТРОМ, необходимо вручную отключить резервное копирование.
Хранилище метрик и конфигурации
Ключ-АСТРОМ сохраняет предыдущую резервную копию, пока не будет создана новая.
Характеристики резервного копирования
- Снимок выполняется ежедневно.
- Любые данные, которые реплицируются между узлами, также хранятся в резервной копии (дедупликации нет).
- Ключ-АСТРОМ исключает наиболее часто изменяющиеся семейства столбцов (исключенные семейства столбцов составляют около 80% от общего объема памяти) в дополнение к данным с разрешением 1 и 5 минут.
Elasticsearch
Файлы Elasticsearch хранятся в несжатом двоичном формате. Хотя данные реплицируются между узлами и есть две реплики в дополнение к основному осколку, резервная копия исключает реплицированные данные.
Характеристики резервного копирования
- По умолчанию моментальный снимок создается каждые 2 часа и является инкрементным. Первоначально Ключ-АСТРОМ копирует весь набор данных, а затем создает моментальные снимки различий. Старые снимки постепенно удаляются, когда им исполняется шесть (6) месяцев. Ключ-АСТРОМ сохраняет как минимум один снимок в месяц.
- Поскольку Ключ-АСТРОМ хранит некоторые из старых снимков состояния, размер резервной копии увеличивается независимо от текущего размера на диске. Моментальные снимки являются инкрементными, но Elasticsearch со временем объединяет сегменты данных, что приводит к возникновению определенных дубликатов в резервной копии.
Нет резервной копии хранилища транзакций
Данные хранилища транзакций не копируются, поэтому при восстановлении резервных копий вы можете увидеть пробелы в данных глубокого мониторинга (например, PurePaths и трассировки на уровне кода). По умолчанию данные хранилища транзакций хранятся только 10 дней. В долгосрочной перспективе нет необходимости включать данные хранилища транзакций в резервные копии.
Восстановление кластера
Чтобы восстановить кластер, выполните следующие действия.
Прежде чем вы начнете
- Убедитесь, что машины, подготовленные для восстановления кластера, имеют такое же оборудование и структуру дисков, что и исходный кластер, и достаточную емкость для обработки нагрузки после восстановления.
Мы рекомендуем
Мы рекомендуем восстановить в кластере то же количество узлов, что и в резервном кластере. В исключительных случаях можно выполнить восстановление в кластер, в котором до двух узлов меньше, чем в кластере, для которого создана резервная копия. Вы рискуете потерять конфигурацию кластера, если попытаетесь восстановить кластер, в котором более чем на два узла меньше исходной резервной копии кластера.
- Убедитесь, что существующий кластер остановлен, чтобы два кластера с одинаковым идентификатором не могли подключиться к Ключ-АСТРОМ Mission Control. См. Запуск / остановка / перезапуск кластера.
- Убедитесь, что системные пользователи, созданные для Ключ-АСТРОМ Managed, имеют одинаковые идентификаторы UID: GID на всех узлах.
- На каждом целевом узле смонтируйте хранилище резервных копий, например, в
/mnt/backup
. Этот путь упоминается как<path-to-backup>
в приведенных ниже шагах. - Убедитесь, что у установщика есть разрешения на чтение NFS.
- Создайте инвентарь кластера. Эта информация понадобится вам во время восстановления.
- Идентификаторы узлов в кластере - резервная копия каждого узла хранится в выделенном каталоге, названном по его идентификатору, в формате
node_ <node_id>
(например,node_1
,node_5
и т.д.). - IPv4-адреса новых машин.
- Решите, какой будет целевой компьютер для каждого узла.
- Решите, какой узел станет начальным узлом в кластере.
- Идентификаторы узлов в кластере - резервная копия каждого узла хранится в выделенном каталоге, названном по его идентификатору, в формате
Восстановить из резервной копии
Чтобы восстановить кластер, выполните следующие действия:
1. Скопируйте установщик на целевые узлы
Для восстановления кластера необходимо использовать ту же версию установщика, что и в исходной. Скопируйте программу установки из <path-to-backup>/<UUID>/node_<node_id>/
на локальный диск на каждом целевом узле.
2. Запустите восстановление Ключ-АСТРОМ на каждом узле
Параллельно на каждом узле запустите программу установки Ключ-АСТРОМ Managed со следующими параметрами:
--restore
- переводит программу установки в режим восстановления.--cluster-ip
- IPv4-адрес узла, на котором вы запускаете установщик.--cluster-nodes
- разделенный запятыми список идентификаторов и IP-адресов всех узлов в кластере, включая тот, на котором вы запускаете установщик, в следующем формате<node_id>:<node_ip>,<node_id>:<node_ip>
.--seed-ip
- IPv4-адрес исходного узла.backup-file
- путь к файлу резервной копии*.tar
, который включает путь к монтированию общего файлового хранилища, идентификатор кластера, идентификатор узла, версию резервной копии и файл резервной копии*.tar
в следующем формате:
<path-to-backup>/<UUID>/node_<node_id>/files/<backup_version_number>/<backup_file>
Пример резервного пути
В этом примере пути: /mnt/backup/bckp/c9dd47f0-87d7-445e-bbeb-26429fac06c6/node_1/files/19/backup-001.tar
части пути следующие:
<path-to-backup>
=/mnt/backup/bckp/
<UUID>
=c9dd47f0-87d7-445e-bbeb-26429fac06c6
<node_id>
=1
<backup_version_number>
=19
Во время резервного копирования могут присутствовать два каталога резервных копий с разными номерами версий резервных копий:
- Каталог с более низким номером версии содержит старую резервную копию. Он будет удален после завершения резервного копирования.
- Каталог с более высоким номером версии содержит текущую резервную копию.
Номер версии резервной копии увеличивается при каждом выполнении резервного копирования.
Получите идентификаторы и IP-адреса из инвентаря, который вы создали перед началом работы.
Например:
10.176.41.168
- IP-адрес восстанавливаемого узла
1: 10.176.41.168, 3: 10.176.41.169, 5: 10.176.41.170
- идентификаторы узлов и новые IP-адреса всех узлов в кластере
sudo /tmp/<backup-managed-installer-name>.sh
--restore
--cluster-ip "10.176.41.168"
--cluster-nodes "1:10.176.41.168,3:10.176.41.169,5:10.176.41.170"
--seed-ip "10.176.41.169"
--backup-file /mnt/backup/bckp/c9dd47f0-87d7-445e-bbeb-26429fac06c6/node_1/files/19/backup-001.tar
3. Запустите брандмауэр, Cassandra и Elasticsearch
На каждом узле последовательно запустите брандмауэр, Cassandra и Elasticsearch, используя скрипт запуска:
4. Проверить состояние Cassandra
На каждом узле проверьте, запущена ли Cassandra. Выполните команду:
<install-dir>/utils/cassandra-nodetool.sh status
В ответе должны быть перечислены все узлы восстановленного кластера со следующими значениями:
Status = Up
State = Normal
5. Проверить состояние Elasticsearch
На каждом узле проверьте, работает ли Elasticsearch. Выполните команду:
curl -s -N -XGET 'http://localhost:9200/_cluster/health?pretty' | grep status
Вы должны получить следующий ответ:
"status" : "green"
или для настройки одного узла:
"status" : "yellow"
6. Восстановить базу данных Elasticsearch
На начальном узле выполните следующую команду: <install-dir>/utils/restore-elasticsearch-data.sh <path-to-backup>/<UUID>
7. Восстановление файлов метрик и данных конфигурации
На каждом узле последовательно, начиная с начального узла, выполните следующую команду:
<install-dir>/utils/restore-cassandra-data.sh <path-to-backup>/<UUID>/node_<node_id>/files/backup-001.tar
Подождите, пока Cassandra полностью не настроит свой кластер. Используйте команду:
<install-dir>/utils/cassandra-nodetool.sh status
- Вы должны получить следующий ответ:
Status = Up
State = Normal
8. [опционально] Почините Cassandra
Последовательно на всех узлах запустить восстановление Cassandra:
<install-dir>/utils/repair-cassandra-data.sh
Это необходимо для обеспечения согласованности данных между узлами. Этот шаг может занять несколько часов.
9. Запустить Ключ-АСТРОМ
На каждом узле последовательно, начиная с начального узла, выполните следующую команду:
<install-dir>/launcher/<main-script>.sh start
Подождите, пока вы не сможете войти в Консоль управления кластером.
10. [опционально] Удалить оставшиеся ссылки на старые узлы
Если вы решили восстановить меньше узлов, чем в исходном кластере, удалите узлы, помеченные как Offline
в консоли управления кластером. Дополнительные сведения см. В разделе Удаление узла кластера.
11. Переключите ЕдиныеАгенты на новый адрес кластера
Если вы изначально настроили кластер с DNS для ЕдиныхАгентов, вам нужно только обновить записи DNS, как описано в следующем шаге.
В противном случае вы должны настроить Cluster АктивныеШлюзы (или ЕдиныеАгенты, если АктивныеШлюзы не используются) с новым целевым адресом и перезапустить их. Если нет кластерных АктивныхШлюзов, но есть АктивныеШлюзы окружения, это следует сделать на АктивныхШлюзах окружения.
В противном случае необходимо настроить и перезапустить Cluster АктивныеШлюзы (или ЕдиныеАгенты, если АктивныеШлюзы не используются) с новым целевым адресом.
Чтобы настроить новый целевой адрес на АктивномШлюзе:
- Остановите службу ActiveGate.
- Обновите параметр
seedServerUrl
вconfig.properties
. - Обновите
cluster.properties
новыми URL-адресами. - Удалите файл
connectivity_history.properties
.
Выполните следующий вызов API кластера для каждого узла, заменив <node-id>
на идентификатор узла, <node-ip>
на IPV4-адрес узла и <Api-Token>
на действительный токен Cluster API.
curl -ikS -X PUT -d <node-ip> https://<node_ip>:8021/api/v1.0/onpremise/endpoint/publicIp/agents/<node-id>?Api-Token=<Api-Token> -H "accept: application/json" -H "Content-Type: application/json"
Вы должны получить ответ 200
, как в примере ниже:
HTTP/1.1 200 OK
Date: Tue, 19 Feb 2019 17:49:06 GMT
X-Robots-Tag: noindex
Server: ruxit server
Content-Length: 0
12. [опционально] Обновить записи DNS кластера
Если восстановление кластера привело к изменению IP-адресов, обновите записи DNS.
- Если вы используете автоматическое управление доменами и сертификатами, выполните следующий вызов API кластера для каждого узла, заменив
<node-id>
на идентификатор узла,<node-ip>
на IPV4-адрес узла и<Api-Token>
на действительный Токен API.
curl -ikS -X PUT -d <node-ip> https://<Node-ip>:8021/api/v1.0/onpremise/endpoint/publicIp/domain/<node-id>?Api-Token=<Api-Token> -H "accept: application/json" -H "Content-Type: application/json"
Вы должны получить ответ 200
, как в примере ниже:
HTTP/1.1 200 OK
Date: Tue, 19 Feb 2019 17:49:06 GMT
X-Robots-Tag: noindex
Server: ruxit server
Content-Length: 0
- Если вы используете собственный DNS, обновите домен кластера на новый IP-адрес.
13. Включить резервное копирование
Чтобы предотвратить перезапись предыдущего снимка, резервное копирование автоматически отключается после восстановления. После завершения восстановления следует снова включить резервное копирование.
- В меню Ключ-АСТРОМ выберите «Настройки»> «Резервное копирование».
- Включите параметр «Включить резервное копирование кластера», подтвердите полный путь к архиву резервных копий и запланируйте время ежедневного резервного копирования.
Отключить резервное копирование вручную
В некоторых ситуациях необходимо вручную отключить резервное копирование кластера. Например, если точка монтирования общей файловой системы недоступна при загрузке системы, Ключ-АСТРОМ не запустится на этом узле. В этом случае необходимо вручную отключить резервное копирование, чтобы запустить Ключ-АСТРОМ.
1. Отредактируйте файл <install-dir>/elasticsearch/config/elasticsearch.yml
.
2. Удалите строку с параметром path.repo:
3. Сохраните файл и перезапустите систему. См. раздел Запуск/остановка/перезапуск кластера