Просмотр кода страницы Резервное копирование и восстановление кластера

'''''<code>[[Установка и настройка]] / [[Ключ-АСТРОМ Managed]] / [https://doc.ruscomtech.ru/index.php/%D0%9A%D0%BB%D1%8E%D1%87-%D0%90%D0%A1%D0%A2%D0%A0%D0%9E%D0%9C_Managed#.D0.AD.D0.BA.D1.81.D0.BF.D0.BB.D1.83.D0.B0.D1.82.D0.B0.D1.86.D0.B8.D1.8F Эксплуатация] / Резервное копирование и восстановление кластера</code>'''''



Чтобы настроить автоматическое резервное копирование для управляемого кластера Ключ-АСТРОМ

1. В меню Ключ-АСТРОМ выберите «Настройки»> «Резервное копирование».

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

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

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

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

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

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

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

== Автоматическое резервное копирование кластера ==
Управляемые данные конфигурации Ключ-АСТРОМ (правила именования, теги, зоны управления, профили предупреждений и т. Д.), Данные метрик временных рядов и пользовательские сеансы могут быть скопированы автоматически. Для максимальной устойчивости рекомендуется сохранять файлы резервных копий за пределами предприятия.

* Каждый узел должен быть подключен к общей файловой системе, а общая файловая система должна быть смонтирована в одном и том же общем каталоге на каждом узле.
* Пользователю, запускающему службы Ключ-АСТРОМ, необходимы разрешения на чтение и запись для общей файловой системы.
* Подключение к общей файловой системе должно быть доступно при перезапуске системы.
* Вы можете добавить точку монтирования в <code>fstab</code> или использовать инструмент управления дисками, чтобы сделать монтирование общей файловой системы постоянным.
* Протокол, используемый для передачи данных, зависит от вашей конфигурации. Мы рекомендуем NFSv4. Из-за низкой производительности и отказоустойчивости мы не рекомендуем CIFS.

----<blockquote>''<big>Точка монтирования общей файловой системы при загрузке системы</big>''

* 

Если точка монтирования общей файловой системы недоступна при загрузке системы, Ключ-АСТРОМ не запустится на этом узле. Это может привести к недоступности кластера. Чтобы запустить Ключ-АСТРОМ, необходимо вручную отключить резервное копирование.</blockquote>
----

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

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

* Снимок выполняется ежедневно.
* Любые данные, которые реплицируются между узлами, также хранятся в резервной копии (дедупликации нет).
* Ключ-АСТРОМ исключает наиболее часто изменяющиеся семейства столбцов (исключенные семейства столбцов составляют около 80% от общего объема памяти) в дополнение к данным с разрешением 1 и 5 минут.

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

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

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

----<blockquote>''<big>Нет резервной копии хранилища транзакций</big>''

* 

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

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

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

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

----<blockquote>''<big>Мы рекомендуем</big>''

* 

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

* Убедитесь, что существующий кластер остановлен, чтобы два кластера с одинаковым идентификатором не могли подключиться к Ключ-АСТРОМ Mission Control. См. Запуск / остановка / перезапуск кластера.

* Убедитесь, что системные пользователи, созданные для Ключ-АСТРОМ Managed, имеют одинаковые идентификаторы UID: GID на всех узлах.
* На каждом целевом узле смонтируйте хранилище резервных копий, например, в <code>/mnt/backup</code>. Этот путь упоминается как <code><path-to-backup></code> в приведенных ниже шагах.
* Убедитесь, что у установщика есть разрешения на чтение NFS.
* Создайте инвентарь кластера. Эта информация понадобится вам во время восстановления.
** Идентификаторы узлов в кластере - резервная копия каждого узла хранится в выделенном каталоге, названном по его идентификатору, в формате <code>node_ <node_id></code> (например, <code>node_1</code> , <code>node_5</code> и т.д.).
** IPv4-адреса новых машин.
** Решите, какой будет целевой компьютер для каждого узла.
** Решите, какой узел станет начальным узлом в кластере.

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

1. '''Скопируйте установщик на целевые узлы'''

Для восстановления кластера необходимо использовать ту же версию установщика, что и в исходной. Скопируйте программу установки из <code><path-to-backup>/<UUID>/node_<node_id>/</code> на локальный диск на каждом целевом узле.

2. '''Запустите восстановление Ключ-АСТРОМ на каждом узле'''

Параллельно на каждом узле запустите программу установки Ключ-АСТРОМ Managed со следующими параметрами:

* <code>--restore</code> - переводит программу установки в режим восстановления.
* <code>--cluster-ip</code> - IPv4-адрес узла, на котором вы запускаете установщик.
* <code>--cluster-nodes</code> - разделенный запятыми список идентификаторов и IP-адресов всех узлов в кластере, включая тот, на котором вы запускаете установщик, в следующем формате <code><node_id>:<node_ip>,<node_id>:<node_ip></code>.
* <code>--seed-ip</code> - IPv4-адрес исходного узла.
* <code>backup-file</code> - путь к файлу резервной копии <code>*.tar</code> , который включает путь к монтированию общего файлового хранилища, идентификатор кластера, идентификатор узла, версию резервной копии и файл резервной копии <code>*.tar</code> в следующем формате:

<code><path-to-backup>/<UUID>/node_<node_id>/files/<backup_version_number>/<backup_file></code>

Пример резервного пути

В этом примере пути: <code>/mnt/backup/bckp/c9dd47f0-87d7-445e-bbeb-26429fac06c6/node_1/files/19/backup-001.tar</code> части пути следующие:

* <code><path-to-backup></code> = <code>/mnt/backup/bckp/</code>

* <code><UUID></code> = <code>c9dd47f0-87d7-445e-bbeb-26429fac06c6</code>

* <code><node_id></code> = <code>1</code>

* <code><backup_version_number></code> = <code>19</code>

Во время резервного копирования могут присутствовать два каталога резервных копий с разными номерами версий резервных копий:

* Каталог с более низким номером версии содержит старую резервную копию. Он будет удален после завершения резервного копирования.
* Каталог с более высоким номером версии содержит текущую резервную копию.

Номер версии резервной копии увеличивается при каждом выполнении резервного копирования.

Получите идентификаторы и IP-адреса из инвентаря, который вы создали перед началом работы.

Например:

<code>10.176.41.168</code> - IP-адрес восстанавливаемого узла

<code>1: 10.176.41.168, 3: 10.176.41.169, 5: 10.176.41.170</code> - идентификаторы узлов и новые IP-адреса всех узлов в кластере

<code>sudo /tmp/<backup-managed-installer-name>.sh</code>

<code>--restore</code>

<code>--cluster-ip "10.176.41.168"</code>

<code>--cluster-nodes "1:10.176.41.168,3:10.176.41.169,5:10.176.41.170"</code>

<code>--seed-ip "10.176.41.169"</code>

<code>--backup-file /mnt/backup/bckp/c9dd47f0-87d7-445e-bbeb-26429fac06c6/node_1/files/19/backup-001.tar</code>

3. '''Запустите брандмауэр, Cassandra и Elasticsearch'''

На каждом узле последовательно запустите брандмауэр, Cassandra и Elasticsearch, используя скрипт запуска:

4. '''Проверить состояние Cassandra'''

На каждом узле проверьте, запущена ли Cassandra. Выполните команду:

<code><install-dir>/utils/cassandra-nodetool.sh status</code>

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

<code>Status = Up</code>

<code>State = Normal</code>

5. '''Проверить состояние Elasticsearch'''

На каждом узле проверьте, работает ли Elasticsearch. Выполните команду:

<code>curl -s -N -XGET '<nowiki>http://localhost:9200/_cluster/health?pretty'</nowiki> | grep status</code>

Вы должны получить следующий ответ:

<code>"status" : "green"</code>

или для настройки одного узла:

<code>"status" : "yellow"</code>

6. '''Восстановить базу данных Elasticsearch'''

На начальном узле выполните следующую команду: <code><install-dir>/utils/restore-elasticsearch-data.sh <path-to-backup>/<UUID></code>

7. '''Восстановление файлов метрик и данных конфигурации'''

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

<code><install-dir>/utils/restore-cassandra-data.sh <path-to-backup>/<UUID>/node_<node_id>/files/backup-001.tar</code>

Подождите, пока Cassandra полностью не настроит свой кластер. Используйте команду:

<code><install-dir>/utils/cassandra-nodetool.sh status</code>

* Вы должны получить следующий ответ:

<code>Status = Up</code>

<code>State = Normal</code>

8. <u>[опционально]</u> '''Почините Cassandra'''

Последовательно на всех узлах запустить восстановление Cassandra:

<code><install-dir>/utils/repair-cassandra-data.sh</code>

Это необходимо для обеспечения согласованности данных между узлами. Этот шаг может занять несколько часов.

9. '''Запустить Ключ-АСТРОМ'''

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

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

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

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

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

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

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

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

В противном случае необходимо настроить и перезапустить Cluster АктивныеШлюзы (или ЕдиныеАгенты, если АктивныеШлюзы не используются) с новым целевым адресом.

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

# Остановите службу ActiveGate.
# Обновите параметр <code>seedServerUrl</code> в <code>config.properties</code>.
# Обновите <code>cluster.properties</code> новыми URL-адресами.
# Удалите файл <code>connectivity_history.properties</code>.

Выполните следующий вызов API кластера для каждого узла, заменив <code><node-id></code> на идентификатор узла, <code><node-ip></code> на IPV4-адрес узла и <code><Api-Token></code> на действительный токен Cluster API.

<code>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"</code>

Вы должны получить ответ <code>200</code> , как в примере ниже:

<code>HTTP/1.1 200 OK</code>

<code>Date: Tue, 19 Feb 2019 17:49:06 GMT</code>

<code>X-Robots-Tag: noindex</code>

<code>Server: ruxit server</code>

<code>Content-Length: 0</code>

12. <u>[опционально]</u> '''Обновить записи DNS кластера'''

Если восстановление кластера привело к изменению IP-адресов, обновите записи DNS.

* Если вы используете автоматическое управление доменами и сертификатами, выполните следующий вызов API кластера для каждого узла, заменив <code><node-id></code> на идентификатор узла, <code><node-ip></code> на IPV4-адрес узла и <code><Api-Token></code> на действительный Токен API.

<code>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"</code>

Вы должны получить ответ <code>200</code> , как в примере ниже:

<code>HTTP/1.1 200 OK</code>

<code>Date: Tue, 19 Feb 2019 17:49:06 GMT</code>

<code>X-Robots-Tag: noindex</code>

<code>Server: ruxit server</code>

<code>Content-Length: 0</code>

* Если вы используете собственный DNS, обновите домен кластера на новый IP-адрес.

13. '''Включить резервное копирование'''

Чтобы предотвратить перезапись предыдущего снимка, резервное копирование автоматически отключается после восстановления. После завершения восстановления следует снова включить резервное копирование.

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

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

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

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

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