Переключение AZ

• Чтобы обеспечить непрерывность сервиса, общее количество data‑узлов и cold‑data‑узлов в кластере должно быть не менее трех.
• Во время изменения узлы выводятся из эксплуатации по одному, после чего создаются новые узлы. Убедитесь, что общий объём диска оставшихся узлов достаточен для обработки всех данных кластера, и что использование диска узлами не превышает 80 %.
• Чтобы убедиться, что все index‑шарды в кластере могут быть размещены на оставшихся data‑узлах и cold‑data‑узлах, общее количество data‑узлов и cold‑data‑узлов должно быть больше максимального количества реплик индексов плюс 1.
• До завершения изменения некоторые узлы могут уже быть перемещены в новую AZ. В этом случае отображаются AZ до и после изменения. После успешного завершения изменения новые AZ и их узлы будут отображаться корректно.
• Когда вы add an AZ для кластера, текущий AZ должен сохраняться. При добавлении одного или двух AZ для кластера с одним AZ необходимо изменить AZ для всех узлов. При добавлении одного AZ для кластера с двумя AZ вы можете выбрать изменение AZ для определённых типов узлов или для всех узлов в кластере. Например, для кластера с двумя AZ вы можете использовать три AZ для его мастер‑узлов, при этом оставив два AZ для остальных узлов. Чтобы завершить изменение AZ, система постарается переместить как можно меньше узлов для восстановления кластера. В процессе также обновляется YML‑файл конфигурации узлов, которые не изменяются. Необходимо перезапустить кластер, чтобы изменение вступило в силу.
• При добавлении AZ для существующего кластера с целью высокой доступности следуйте правилам распределения узлов ниже:
  • Чтобы обеспечить высокую доступность сервиса и предотвратить перегрузку отдельных узлов в развертывании с несколькими AZ, необходимо соблюсти следующие требования к количеству узлов:
    • Для кластера с двумя AZ, должно быть не менее четырёх узлов данных (или холодных узлов данных), по два на каждый AZ; и должно быть не менее двух клиентских узлов (если они настроены), по одному на каждый AZ.
    • Для кластера с тремя AZ каждый доступный тип узлов должен иметь как минимум один узел в каждом AZ. Это означает, что каждый тип узлов должен иметь минимум три узла в сумме.
    • Для типов узлов, которые не развернуты (например, отсутствуют холодные узлы данных), требование к минимальному количеству узлов не применяется.
  • Повышение производительности: Чтобы предотвратить неравномерное распределение данных и обеспечить оптимальную производительность запросов и загрузки, количество узлов данных или холодных узлов данных должно быть целым кратным числу AZ.
• При миграции AZ (Migrate AZ) можно выбрать только один целевой AZ. Для этой операции вы можете выбрать миграцию только определённых типов узлов или всех узлов в кластере. Например, для кластера с двумя AZ можно переместить мастер‑узлы из одного AZ в другой, оставив остальные узлы без изменений. При миграции из одного AZ в другой перезапуск кластера не требуется. Если мигрируют несколько AZ, необходимо перезапустить кластер, чтобы изменение вступило в силу.

Перед изменением AZ кластера необходимо оценить потенциальные последствия и изучить рекомендации по эксплуатации. Это позволяет правильно спланировать изменение, минимизируя прерывания сервиса.

• Производительность

  Изменение AZ для кластера не прерывает сервисы. Однако миграция данных, происходящая в этом процессе, потребляет I/O‑производительность, а вывод отдельных узлов из эксплуатации всё же оказывает некоторое влияние на общую производительность кластера.

  Чтобы минимизировать это влияние, рекомендуется регулировать скорость миграции данных в зависимости от цикла нагрузки кластера: увеличивать скорость миграции данных в часы низкой нагрузки, чтобы сократить продолжительность задачи, и уменьшать её before начала пиковых часов, чтобы обеспечить оптимальную производительность кластера. Скорость миграции данных определяется параметром indices.recovery.max_bytes_per_sec. Значение параметра по умолчанию равно количеству vCPU, умноженному на 8 МБ. Например, для четырёх vCPU скорость миграции данных составляет 32 МБ/с. Вы можете изменить её в соответствии с требованиями сервиса.

  PUT /_cluster/settings  
  {  
    "transient": {  
      "indices.recovery.max_bytes_per_sec": "128MB"  
    }  
  }
  
  

• Влияние на обработку запросов

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

  • Используйте VPC endpoint или выделенный load balancer для обработки запросов доступа к вашему кластеру, что гарантирует автоматическую маршрутизацию запросов к доступным узлам.
  • Включите механизм экспоненциального отката & повторных попыток на клиенте (настройте три повторения).
  • Выполняйте эту операцию в непиковые часы.
• Характеристики этого процесса

  После запуска задачу изменения AZ нельзя остановить, пока она не завершится успешно или не завершится с ошибкой.

Для оценки времени, необходимого для изменения AZ в кластере, можно использовать следующую формулу:

Change duration (min) = 15 (min) x Total number of nodes involved + Data migration duration (min)

где 15 минут указывает типичное время выполнения операций, не связанных с миграцией данных (например, инициализация), на один узел. Это эмпирическое значение.

Data migration duration (min) = Total data size of the nodes to be migrated (MB) ÷ [Total number of vCPUs of the data nodes x 8 (MB/s) x 60 (s)]

где,

• 8 MB/s указывает, что каждый vCPU может обрабатывать 8 MB данных в секунду. Это эмпирическое значение.
• Приведённые выше формулы используют оценки при идеальных условиях. Фактическая скорость миграции зависит от нагрузки кластера.

• Статус кластера Available, и нет текущих задач.
• Убедитесь, что кластер не подвергался каким-либо нестандартным изменениям, таким как настройка пользовательских обратных маршрутов и системных параметров. Такие изменения, если они были внесены, будут потеряны после изменения AZ, что может повлиять на ваши сервисы.
• Все критически важные данные были сохранены в бэкапе. Для получения подробной информации см. Creating Snapshots to Back Up Data.

1. Войдите в консоль управления CSS.
2. В панели навигации слева выберите Clusters > Elasticsearch.
3. В списке кластеров найдите целевой кластер и выберите More > Modify Configuration в столбце Operation. Отобразится страница Modify Configuration.
4. Нажмите вкладку Change AZ.
5. На странице Change AZ задайте параметры.
   Caution

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

   Table 1 Параметры изменения AZ

   Параметр	Описание
   Тип операции	Add AZ: Добавьте один или два AZ для кластера с одним AZ или один AZ для кластера с двумя AZ. Для завершения изменения AZ система постарается переместить как можно меньше узлов для восстановления кластера. В ходе этого процесса также обновляется YML‑файл конфигурации узлов, которые не изменяются. Необходимо перезапустить кластер, чтобы изменения вступили в силу. Migrate AZ: Переместить данные из одной AZ в другую. После добавления AZs, необходимо перезапустить кластер, чтобы изменение вступило в силу.
   Node Type	Выберите тип узла для изменения AZ. Выберите один тип узла или All nodes для изменения их AZ. При добавлении одной или двух AZ в кластер с одним AZ вы можете выбрать только All nodes.
   Current AZ	Текущий AZ кластера
   Target AZ	AZ для добавления или миграции. Add AZ: Выберите до трёх AZ, которые должны включать все ваши текущие AZ. Migrate AZ: Выберите только один целевой AZ, который не может быть вашим текущим AZ.

6. Нажмите Submit. В отображаемом диалоговом окне выберите, проверять ли наличие полного снимка индекса, и нажмите OK для начала изменения.
   Note

   Рекомендуется выбрать Check full index snapshot. Это гарантирует, что все данные были сохранены, поэтому в случае сбоя задачи данные можно восстановить с помощью этого снимка.

   Рисунок 1 Check Full Index Snapshot

   
   

   Когда Task Status в списке задач ниже изменится на Successful, изменение AZ завершено.

7. Подтвердите результат.
   1. В списке кластеров нажмите имя целевого кластера. Отображается страница информации о кластере.
   2. На вкладке Overview проверьте AZ кластера в области Basic Information, чтобы определить, успешно ли выполнено изменение.

В области Jobs на вкладке Change AZ найдите задачу изменения AZ.

Разверните список задач и нажмите View Progress, чтобы проверить прогресс задачи и статус узла.

Если Task Status имеет значение Failed, вы можете повторить задачу или завершить её.

• Повторить задачу: нажмите Retry в столбце Operation.
• Завершить задачу: нажмите Terminate в столбце Operation. Перед завершением задачи убедитесь, что AZ успешно изменён ни для одного из узлов.