Резервное копирование и восстановление кластера

Материал из Документация Ключ-АСТРОМ

Установка и настройка / Ключ-АСТРОМ 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 АктивныеШлюзы (или ЕдиныеАгенты, если АктивныеШлюзы не используются) с новым целевым адресом.

Чтобы настроить новый целевой адрес на АктивномШлюзе:

  1. Остановите службу ActiveGate.
  2. Обновите параметр seedServerUrl в config.properties.
  3. Обновите cluster.properties новыми URL-адресами.
  4. Удалите файл 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. В меню Ключ-АСТРОМ выберите «Настройки»> «Резервное копирование».
  2. Включите параметр «Включить резервное копирование кластера», подтвердите полный путь к архиву резервных копий и запланируйте время ежедневного резервного копирования.

Отключить резервное копирование вручную

В некоторых ситуациях необходимо вручную отключить резервное копирование кластера. Например, если точка монтирования общей файловой системы недоступна при загрузке системы, Ключ-АСТРОМ не запустится на этом узле. В этом случае необходимо вручную отключить резервное копирование, чтобы запустить Ключ-АСТРОМ.

1. Отредактируйте файл <install-dir>/elasticsearch/config/elasticsearch.yml.

2. Удалите строку с параметром path.repo:

3. Сохраните файл и перезапустите систему. См. раздел Запуск/остановка/перезапуск кластера

Источник — https://doc.ruscomtech.ru/index.php?title=Резервное_копирование_и_восстановление_кластера&oldid=2361