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

Установка и настройка / Dynatrace Managed / Эксплуатация / Резервное копирование и восстановление кластера

Чтобы настроить автоматическое резервное копирование для управляемого кластера Dynatrace

1. В меню Dynatrace выберите «Настройки»> «Резервное копирование».

2. Включите резервное копирование кластера и выберите область действия:

• Пользовательские сеансы могут содержать конфиденциальную информацию.

Исключите сеансы пользователей из резервной копии, чтобы соответствовать требованиям GDPR.

• Исключите данные метрик таймсерий из резервной копии, если ваши исторические данные не актуальны и вы хотите сохранить только данные конфигурации.
• Включите резервную копию событий Log Monitoring v2.

3. (Необязательно) Выберите центр обработки данных. Этот шаг требуется только в том случае, если у вас есть развертывание с несколькими центрами обработки данных (развертывание с высокой доступностью Premium). Дополнительные сведения о развертываниях высокой доступности Premium см. В разделах Высокая доступность для нескольких центров обработки данных и Аварийное восстановление из резервной копии.

4. Укажите полный путь к подключенному сетевому файловому хранилищу, где будут храниться архивы резервных копий.

5. Настройте время начала.

Автоматическое резервное копирование кластера

Управляемые данные конфигурации Dynatrace (правила именования, теги, зоны управления, профили предупреждений и т. Д.), Данные метрик временных рядов и пользовательские сеансы могут быть скопированы автоматически. Для максимальной устойчивости рекомендуется сохранять файлы резервных копий за пределами предприятия.

• Каждый узел должен быть подключен к общей файловой системе, а общая файловая система должна быть смонтирована в одном и том же общем каталоге на каждом узле.
• Пользователю, запускающему службы Dynatrace, необходимы разрешения на чтение и запись для общей файловой системы.
• Подключение к общей файловой системе должно быть доступно при перезапуске системы.
• Вы можете добавить точку монтирования в fstab или использовать инструмент управления дисками, чтобы сделать монтирование общей файловой системы постоянным.
• Протокол, используемый для передачи данных, зависит от вашей конфигурации. Мы рекомендуем NFSv4. Из-за низкой производительности и отказоустойчивости мы не рекомендуем CIFS.

---

Точка монтирования общей файловой системы при загрузке системы

Если точка монтирования общей файловой системы недоступна при загрузке системы, Dynatrace не запустится на этом узле. Это может привести к недоступности кластера. Чтобы запустить Dynatrace, необходимо вручную отключить резервное копирование.

---

Хранилище метрик и конфигурации

Dynatrace сохраняет предыдущую резервную копию, пока не будет создана новая.

Характеристики резервного копирования

• Снимок выполняется ежедневно.
• Любые данные, которые реплицируются между узлами, также хранятся в резервной копии (дедупликации нет).
• Dynatrace исключает наиболее часто изменяющиеся семейства столбцов (исключенные семейства столбцов составляют около 80% от общего объема памяти) в дополнение к данным с разрешением 1 и 5 минут.

Elasticsearch

Файлы Elasticsearch хранятся в несжатом двоичном формате. Хотя данные реплицируются между узлами и есть две реплики в дополнение к основному осколку, резервная копия исключает реплицированные данные.

Характеристики резервного копирования

• По умолчанию моментальный снимок создается каждые 2 часа и является инкрементным. Первоначально Dynatrace копирует весь набор данных, а затем создает моментальные снимки различий. Старые снимки постепенно удаляются, когда им исполняется шесть (6) месяцев. Dynatrace сохраняет как минимум один снимок в месяц.
• Поскольку Dynatrace хранит некоторые из старых снимков состояния, размер резервной копии увеличивается независимо от текущего размера на диске. Моментальные снимки являются инкрементными, но Elasticsearch со временем объединяет сегменты данных, что приводит к возникновению определенных дубликатов в резервной копии.

---

Нет резервной копии хранилища транзакций

Данные хранилища транзакций не копируются, поэтому при восстановлении резервных копий вы можете увидеть пробелы в данных глубокого мониторинга (например, PurePaths и трассировки на уровне кода). По умолчанию данные хранилища транзакций хранятся только 10 дней. В долгосрочной перспективе нет необходимости включать данные хранилища транзакций в резервные копии.

---

Восстановление кластера

Чтобы восстановить кластер, выполните следующие действия.

Прежде чем вы начнете

• Убедитесь, что машины, подготовленные для восстановления кластера, имеют такое же оборудование и структуру дисков, что и исходный кластер, и достаточную емкость для обработки нагрузки после восстановления.

---

Мы рекомендуем

Мы рекомендуем восстановить в кластере то же количество узлов, что и в резервном кластере. В исключительных случаях можно выполнить восстановление в кластер, в котором до двух узлов меньше, чем в кластере, для которого создана резервная копия. Вы рискуете потерять конфигурацию кластера, если попытаетесь восстановить кластер, в котором более чем на два узла меньше исходной резервной копии кластера.

---

• Убедитесь, что существующий кластер остановлен, чтобы два кластера с одинаковым идентификатором не могли подключиться к Dynatrace Mission Control. См. Запуск / остановка / перезапуск кластера.

• Убедитесь, что системные пользователи, созданные для Dynatrace 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. Запустите восстановление Dynatrace на каждом узле

Параллельно на каждом узле запустите программу установки Dynatrace 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. Запустить Dynatrace

На каждом узле последовательно, начиная с начального узла, выполните следующую команду:

<install-dir>/launcher/<main-script>.sh start

Подождите, пока вы не сможете войти в Консоль управления кластером.

10. [опционально] Удалить оставшиеся ссылки на старые узлы

Если вы решили восстановить меньше узлов, чем в исходном кластере, удалите узлы, помеченные как Offline в консоли управления кластером. Дополнительные сведения см. В разделе Удаление узла кластера.

11. Переключите OneAgent'ы на новый адрес кластера

Если вы изначально настроили кластер с DNS для OneAgent'ов, вам нужно только обновить записи DNS, как описано в следующем шаге.

В противном случае вы должны настроить Cluster ActiveGate'ы (или OneAgent'ы, если ActiveGate'ы не используются) с новым целевым адресом и перезапустить их. Если нет кластерных ActiveGate'ов, но есть ActiveGate'ы окружения, это следует сделать на ActiveGate'ах окружения.

В противном случае необходимо настроить и перезапустить Cluster ActiveGate'ы (или OneAgent'ы, если ActiveGate'ы не используются) с новым целевым адресом.

Чтобы настроить новый целевой адрес на ActiveGate:

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. В меню Dynatrace выберите «Настройки»> «Резервное копирование».
2. Включите параметр «Включить резервное копирование кластера», подтвердите полный путь к архиву резервных копий и запланируйте время ежедневного резервного копирования.

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

В некоторых ситуациях необходимо вручную отключить резервное копирование кластера. Например, если точка монтирования общей файловой системы недоступна при загрузке системы, Dynatrace не запустится на этом узле. В этом случае необходимо вручную отключить резервное копирование, чтобы запустить Dynatrace.

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

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

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