Резервное копирование и восстановление кластера: различия между версиями
| Строка 27: | Строка 27: | ||
* Каждый узел должен быть подключен к общей файловой системе, например, к сетевому доступу к файлам (NFS), и эта общая файловая система должна быть смонтирована в одном и том же общем каталоге на каждом узле. Чтобы проверить права пользователя, выполните следующую команду на каждом узле: | * Каждый узел должен быть подключен к общей файловой системе, например, к сетевому доступу к файлам (NFS), и эта общая файловая система должна быть смонтирована в одном и том же общем каталоге на каждом узле. Чтобы проверить права пользователя, выполните следующую команду на каждом узле: | ||
{| class="wikitable" | {| class="wikitable" | ||
|su - | |su - astromkey -s /bin/bash -c "touch /nfs/astromkey/backup/$(uname -n)" | ||
ls -ltr /path/to/backup/ | ls -ltr /path/to/backup/ | ||
| Строка 48: | Строка 48: | ||
'''Характеристики резервного копирования''' | '''Характеристики резервного копирования''' | ||
* | * Снапшот выполняется ежедневно. | ||
* Любые данные, которые реплицируются между узлами, также хранятся в резервной копии (дедупликации нет). | * Любые данные, которые реплицируются между узлами, также хранятся в резервной копии (дедупликации нет). | ||
* Ключ-АСТРОМ исключает наиболее часто изменяющиеся семейства столбцов (исключенные семейства столбцов составляют около 80% от общего объема памяти) в дополнение к данным с разрешением 1 и 5 минут. | * Ключ-АСТРОМ исключает наиболее часто изменяющиеся семейства столбцов (исключенные семейства столбцов составляют около 80% от общего объема памяти) в дополнение к данным с разрешением 1 и 5 минут. | ||
=== Elasticsearch === | === Elasticsearch === | ||
Файлы Elasticsearch хранятся в несжатом двоичном формате. Хотя данные реплицируются между узлами и есть две реплики в дополнение к основному осколку, резервная копия исключает реплицированные данные. | Файлы '''Elasticsearch''' хранятся в несжатом двоичном формате. Хотя данные реплицируются между узлами и есть две реплики в дополнение к основному осколку, резервная копия исключает реплицированные данные. | ||
'''Характеристики резервного копирования''' | '''Характеристики резервного копирования''' | ||
* По умолчанию моментальный | * По умолчанию моментальный снапшот создается каждые 2 часа и является инкрементным. Первоначально Ключ-АСТРОМ копирует весь набор данных, а затем создает моментальные снимки различий. Старые снапшоты постепенно удаляются, когда им исполняется шесть (6) месяцев. Ключ-АСТРОМ сохраняет как минимум один снапшот в месяц. | ||
* Поскольку Ключ-АСТРОМ хранит некоторые из старых | * Поскольку Ключ-АСТРОМ хранит некоторые из старых снапшотов состояния, размер резервной копии увеличивается независимо от текущего размера на диске. Моментальные снапшоты являются инкрементными, но '''Elasticsearch''' со временем объединяет сегменты данных, что приводит к возникновению определенных дубликатов в резервной копии. | ||
----<blockquote>''<big>Нет резервной копии хранилища транзакций</big>'' | ----<blockquote>''<big>Нет резервной копии хранилища транзакций</big>'' | ||
| Строка 64: | Строка 64: | ||
* | * | ||
Данные хранилища транзакций не копируются, поэтому при восстановлении резервных копий вы можете увидеть пробелы в данных глубокого мониторинга (например, PurePaths и трассировки на уровне кода). По умолчанию данные хранилища транзакций хранятся только 10 дней. В долгосрочной перспективе нет необходимости включать данные хранилища транзакций в резервные копии.</blockquote> | Данные хранилища транзакций не копируются, поэтому при восстановлении резервных копий вы можете увидеть пробелы в данных глубокого мониторинга (например, '''PurePaths''' и трассировки на уровне кода). По умолчанию данные хранилища транзакций хранятся только 10 дней. В долгосрочной перспективе нет необходимости включать данные хранилища транзакций в резервные копии.</blockquote> | ||
---- | ---- | ||
| Строка 81: | Строка 81: | ||
---- | ---- | ||
* Убедитесь, что существующий кластер остановлен, чтобы два кластера с одинаковым идентификатором не могли подключиться к Ключ-АСТРОМ. См. Запуск / остановка / перезапуск кластера. | * Убедитесь, что существующий кластер остановлен, чтобы два кластера с одинаковым идентификатором не могли подключиться к Ключ-АСТРОМ. См. [[Запуск/остановка/перезапуск кластера|Запуск / остановка / перезапуск кластера]]. | ||
* Убедитесь, что системные пользователи, созданные для Ключ-АСТРОМ Managed, имеют одинаковые идентификаторы UID: GID на всех узлах. | * Убедитесь, что системные пользователи, созданные для Ключ-АСТРОМ Managed, имеют одинаковые идентификаторы '''UID''': '''GID''' на всех узлах. | ||
* На каждом целевом узле смонтируйте хранилище резервных копий, например, в <code>/mnt/backup</code>. Этот путь упоминается как <code><path-to-backup></code> в приведенных ниже шагах. | * На каждом целевом узле смонтируйте хранилище резервных копий, например, в <code>/mnt/backup</code>. Этот путь упоминается как <code><path-to-backup></code> в приведенных ниже шагах. | ||
* Убедитесь, что у установщика есть разрешения на чтение NFS. | * Убедитесь, что у установщика есть разрешения на чтение NFS. | ||
| Строка 137: | Строка 137: | ||
<code>1: 10.176.41.168, 3: 10.176.41.169, 5: 10.176.41.170</code> - идентификаторы узлов и новые IP-адреса всех узлов в кластере | <code>1: 10.176.41.168, 3: 10.176.41.169, 5: 10.176.41.170</code> - идентификаторы узлов и новые IP-адреса всех узлов в кластере | ||
{| class="wikitable" | |||
|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''' | |||
3. '''Запустите брандмауэр, Cassandra и Elasticsearch''' | |||
На каждом узле последовательно запустите брандмауэр, Cassandra и Elasticsearch, используя скрипт запуска: | На каждом узле последовательно запустите брандмауэр, Cassandra и Elasticsearch, используя скрипт запуска: | ||
{| class="wikitable" | |||
|/opt/astromkey-managed/launcher/firewall.sh start | |||
/opt/astromkey-managed/launcher/cassandra.sh start | |||
/opt/astromkey-managed/launcher/elasticsearch.sh start | |||
|} | |||
4. '''Проверить состояние Cassandra''' | 4. '''Проверить состояние Cassandra''' | ||
| Строка 211: | Строка 208: | ||
8. <u>[опционально]</u> '''Почините Cassandra''' | 8. <u>[опционально]</u> '''Почините Cassandra''' | ||
Последовательно на всех узлах запустить восстановление Cassandra: | Последовательно на всех узлах запустить восстановление '''Cassandra''': | ||
{| class="wikitable" | |||
|<install-dir>/utils/repair-cassandra-data.sh | |||
|}Это необходимо для обеспечения согласованности данных между узлами. Этот шаг может занять несколько часов. | |||
< | Чтобы восстановить только данные конфигурации без временных рядов метрик, выполните следующую команду: | ||
{| class="wikitable" | |||
|<astromkey-install-dir>/utils/repair-cassandra-data.sh 1 | |||
|}9. '''Запустить Ключ-АСТРОМ''' | |||
9. '''Запустить Ключ-АСТРОМ''' | |||
На каждом узле последовательно, начиная с начального узла, выполните следующую команду: | На каждом узле последовательно, начиная с начального узла, выполните следующую команду: | ||
{| class="wikitable" | |||
|<install-dir>/launcher/<main-script>.sh start | |||
|}Подождите, пока вы не сможете войти в Консоль управления кластером. | |||
Подождите, пока вы не сможете войти в Консоль управления кластером. | |||
10. <u>[опционально]</u> '''Удалить оставшиеся ссылки на старые узлы''' | 10. <u>[опционально]</u> '''Удалить оставшиеся ссылки на старые узлы''' | ||
| Строка 239: | Строка 237: | ||
Чтобы настроить новый целевой адрес на АктивномШлюзе: | Чтобы настроить новый целевой адрес на АктивномШлюзе: | ||
# Остановите службу | # Остановите службу АктивногоШлюза. | ||
# Обновите параметр <code>seedServerUrl</code> в <code>config.properties</code>. | # Обновите параметр <code>seedServerUrl</code> в <code>config.properties</code>. | ||
# Обновите <code>cluster.properties</code> новыми URL-адресами. | # Обновите <code>cluster.properties</code> новыми URL-адресами. | ||
| Строка 245: | Строка 243: | ||
Выполните следующий вызов API кластера для каждого узла, заменив <code><node-id></code> на идентификатор узла, <code><node-ip></code> на IPV4-адрес узла и <code><Api-Token></code> на действительный токен Cluster API. | Выполните следующий вызов API кластера для каждого узла, заменив <code><node-id></code> на идентификатор узла, <code><node-ip></code> на IPV4-адрес узла и <code><Api-Token></code> на действительный токен Cluster API. | ||
{| class="wikitable" | |||
|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>200</code> , как в примере ниже: | |||
{| class="wikitable" | |||
|HTTP/1.1 200 OK | |||
Date: Tue, 19 Feb 2019 17:49:06 GMT | |||
X-Robots-Tag: noindex | |||
Server: ruxit server | |||
12. <u>[опционально]</u> '''Обновить записи DNS кластера''' | Content-Length: 0 | ||
|}12. <u>[опционально]</u> '''Обновить записи DNS кластера''' | |||
Если восстановление кластера привело к изменению IP-адресов, обновите записи DNS. | Если восстановление кластера привело к изменению IP-адресов, обновите записи DNS. | ||
* Если вы используете автоматическое управление доменами и сертификатами, выполните следующий вызов API кластера для каждого узла, заменив <code><node-id></code> на идентификатор узла, <code><node-ip></code> на IPV4-адрес узла и <code><Api-Token></code> на действительный Токен API. | * Если вы используете автоматическое управление доменами и сертификатами, выполните следующий вызов API кластера для каждого узла, заменив <code><node-id></code> на идентификатор узла, <code><node-ip></code> на IPV4-адрес узла и <code><Api-Token></code> на действительный Токен API. | ||
{| class="wikitable" | |||
|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>200</code> , как в примере ниже: | |||
{| class="wikitable" | |||
|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-адрес. | * Если вы используете собственный DNS, обновите домен кластера на новый IP-адрес. | ||
| Строка 286: | Строка 281: | ||
Чтобы предотвратить перезапись предыдущего снимка, резервное копирование автоматически отключается после восстановления. После завершения восстановления следует снова включить резервное копирование. | Чтобы предотвратить перезапись предыдущего снимка, резервное копирование автоматически отключается после восстановления. После завершения восстановления следует снова включить резервное копирование. | ||
# В меню Ключ-АСТРОМ выберите | # В меню Ключ-АСТРОМ выберите '''Настройки > Резервное копирование'''. | ||
# Включите параметр | # Включите параметр '''Включить резервное копирование кластера''', подтвердите полный путь к архиву резервных копий и запланируйте время ежедневного резервного копирования. | ||
=== Отключить резервное копирование вручную === | === Отключить резервное копирование вручную === | ||
| Строка 294: | Строка 289: | ||
1. Отредактируйте файл <code><install-dir>/elasticsearch/config/elasticsearch.yml</code>. | 1. Отредактируйте файл <code><install-dir>/elasticsearch/config/elasticsearch.yml</code>. | ||
2. Удалите строку с параметром <code>path.repo:</code> | 2. Удалите строку с параметром <code>path.repo:</code> Например: | ||
{| class="wikitable" | |||
|network.host: [ _local_, "10.10.10.10" ] | |||
network.publish_host: 10.10.10.10 | |||
path.data: /var/opt/astromkey-managed/elasticsearch | |||
3. Сохраните файл и перезапустите систему. См. раздел Запуск/остановка/перезапуск кластера | path.repo: <REMOVE THIS LINE> | ||
|}3. Сохраните файл и перезапустите систему. См. раздел Запуск/остановка/перезапуск кластера | |||
Текущая версия на 00:14, 1 августа 2025
Установка и настройка / Ключ-АСТРОМ Managed / Эксплуатация / Резервное копирование и восстановление кластера
Чтобы настроить автоматическое резервное копирование для управляемого кластера Ключ-АСТРОМ
1. В меню Ключ-АСТРОМ выберите Настройки > Резервное копирование.
2. Включите резервное копирование кластера и выберите область действия:
- Пользовательские сеансы могут содержать конфиденциальную информацию.
Исключите сеансы пользователей из резервной копии, чтобы соответствовать требованиям GDPR.
- Исключите данные метрик таймсерий из резервной копии, если ваши исторические данные не актуальны и вы хотите сохранить только данные конфигурации.
- Включите резервную копию событий Мониторинга логов v2.
3. Необязательно Выберите центр обработки данных. Этот шаг требуется только в том случае, если у вас есть развертывание с несколькими центрами обработки данных (развертывание с высокой доступностью Premium). Дополнительные сведения о развертываниях высокой доступности Premium см. В разделах Высокая доступность для нескольких центров обработки данных и Аварийное восстановление из резервной копии.
4. Укажите полный путь к подключенному сетевому файловому хранилищу, где будут храниться архивы резервных копий.
5. Настройте время начала.
Автоматическое резервное копирование кластера
Управляемые данные конфигурации Ключ-АСТРОМ (правила именования, теги, менеджмент зоны, профили предупреждений и т. Д.), Данные метрик временных рядов и пользовательские сеансы могут быть скопированы автоматически. Для максимальной устойчивости рекомендуется сохранять файлы резервных копий за пределами предприятия.
- Каждый узел должен быть подключен к общей файловой системе, например, к сетевому доступу к файлам (NFS), и эта общая файловая система должна быть смонтирована в одном и том же общем каталоге на каждом узле. Чтобы проверить права пользователя, выполните следующую команду на каждом узле:
| su - astromkey -s /bin/bash -c "touch /nfs/astromkey/backup/$(uname -n)"
ls -ltr /path/to/backup/ |
- Пользователю, запускающему службы Ключ-АСТРОМ, необходимы разрешения на чтение и запись для общей файловой системы.
- Подключение к общей файловой системе должно быть доступно при перезапуске системы.
- Вы можете добавить точку монтирования в
fstabили использовать инструмент управления дисками, чтобы сделать монтирование общей файловой системы постоянным. - Протокол, используемый для передачи данных, зависит от вашей конфигурации. Мы рекомендуем NFSv4. Из-за низкой производительности и отказоустойчивости мы не рекомендуем CIFS.
Точка монтирования общей файловой системы при загрузке системы
Если точка монтирования общей файловой системы недоступна при загрузке системы, Ключ-АСТРОМ не запустится на этом узле. Это может привести к недоступности кластера. Чтобы запустить Ключ-АСТРОМ, необходимо вручную отключить резервное копирование.
Хранилище метрик и конфигурации
Ключ-АСТРОМ сохраняет предыдущую резервную копию, пока не будет создана новая.
Характеристики резервного копирования
- Снапшот выполняется ежедневно.
- Любые данные, которые реплицируются между узлами, также хранятся в резервной копии (дедупликации нет).
- Ключ-АСТРОМ исключает наиболее часто изменяющиеся семейства столбцов (исключенные семейства столбцов составляют около 80% от общего объема памяти) в дополнение к данным с разрешением 1 и 5 минут.
Elasticsearch
Файлы Elasticsearch хранятся в несжатом двоичном формате. Хотя данные реплицируются между узлами и есть две реплики в дополнение к основному осколку, резервная копия исключает реплицированные данные.
Характеристики резервного копирования
- По умолчанию моментальный снапшот создается каждые 2 часа и является инкрементным. Первоначально Ключ-АСТРОМ копирует весь набор данных, а затем создает моментальные снимки различий. Старые снапшоты постепенно удаляются, когда им исполняется шесть (6) месяцев. Ключ-АСТРОМ сохраняет как минимум один снапшот в месяц.
- Поскольку Ключ-АСТРОМ хранит некоторые из старых снапшотов состояния, размер резервной копии увеличивается независимо от текущего размера на диске. Моментальные снапшоты являются инкрементными, но Elasticsearch со временем объединяет сегменты данных, что приводит к возникновению определенных дубликатов в резервной копии.
Нет резервной копии хранилища транзакций
Данные хранилища транзакций не копируются, поэтому при восстановлении резервных копий вы можете увидеть пробелы в данных глубокого мониторинга (например, PurePaths и трассировки на уровне кода). По умолчанию данные хранилища транзакций хранятся только 10 дней. В долгосрочной перспективе нет необходимости включать данные хранилища транзакций в резервные копии.
Восстановление кластера
Чтобы восстановить кластер, выполните следующие действия.
Прежде чем вы начнете
- Убедитесь, что машины, подготовленные для восстановления кластера, имеют такое же оборудование и структуру дисков, что и исходный кластер, и достаточную емкость для обработки нагрузки после восстановления.
Мы рекомендуем
Мы рекомендуем восстановить в кластере то же количество узлов, что и в резервном кластере. В исключительных случаях можно выполнить восстановление в кластер, в котором до двух узлов меньше, чем в кластере, для которого создана резервная копия. Вы рискуете потерять конфигурацию кластера, если попытаетесь восстановить кластер, в котором более чем на два узла меньше исходной резервной копии кластера.
- Убедитесь, что существующий кластер остановлен, чтобы два кластера с одинаковым идентификатором не могли подключиться к Ключ-АСТРОМ. См. Запуск / остановка / перезапуск кластера.
- Убедитесь, что системные пользователи, созданные для Ключ-АСТРОМ 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, используя скрипт запуска:
| /opt/astromkey-managed/launcher/firewall.sh start
/opt/astromkey-managed/launcher/cassandra.sh start /opt/astromkey-managed/launcher/elasticsearch.sh start |
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 |
Это необходимо для обеспечения согласованности данных между узлами. Этот шаг может занять несколько часов.
Чтобы восстановить только данные конфигурации без временных рядов метрик, выполните следующую команду:
| <astromkey-install-dir>/utils/repair-cassandra-data.sh 1 |
9. Запустить Ключ-АСТРОМ
На каждом узле последовательно, начиная с начального узла, выполните следующую команду:
| <install-dir>/launcher/<main-script>.sh start |
Подождите, пока вы не сможете войти в Консоль управления кластером.
10. [опционально] Удалить оставшиеся ссылки на старые узлы
Если вы решили восстановить меньше узлов, чем в исходном кластере, удалите узлы, помеченные как Offline в консоли управления кластером. Дополнительные сведения см. В разделе Удаление узла кластера.
11. Переключите ЕдиныеАгенты на новый адрес кластера
Если вы изначально настроили кластер с DNS для ЕдиныхАгентов, вам нужно только обновить записи DNS, как описано в следующем шаге.
В противном случае вы должны настроить Cluster АктивныеШлюзы (или ЕдиныеАгенты, если АктивныеШлюзы не используются) с новым целевым адресом и перезапустить их. Если нет кластерных АктивныхШлюзов, но есть АктивныеШлюзы окружения, это следует сделать на АктивныхШлюзах окружения.
В противном случае необходимо настроить и перезапустить Cluster АктивныеШлюзы (или ЕдиныеАгенты, если АктивныеШлюзы не используются) с новым целевым адресом.
Чтобы настроить новый целевой адрес на АктивномШлюзе:
- Остановите службу АктивногоШлюза.
- Обновите параметр
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: Например:
| network.host: [ _local_, "10.10.10.10" ]
network.publish_host: 10.10.10.10 path.data: /var/opt/astromkey-managed/elasticsearch path.repo: <REMOVE THIS LINE> |
3. Сохраните файл и перезапустите систему. См. раздел Запуск/остановка/перезапуск кластера