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

• Чтобы обеспечить непрерывность сервиса, общее количество узлов данных и узлов холодных данных в кластере должно быть не менее трех.
• Во время изменения узлы выводятся из эксплуатации поочередно, после чего создаются новые узлы. Убедитесь, что общий объём диска оставшихся узлов достаточен для обработки всех данных кластера, и что использование диска узлами не превышает 80 %.
• Чтобы убедиться, что все шарды индекса в кластере могут быть размещены на оставшихся узлах данных и узлах холодных данных, общее количество узлов данных и узлов холодных данных должно быть больше максимального количества реплик индекса плюс 1.
• До завершения изменения некоторые узлы могут уже быть перемещены в новую AZ. В этом случае отображаются AZ до и после изменения. После успешного завершения изменения новые AZ и их узлы будут отображаться корректно.
• Когда вы add an AZ для кластера, текущий AZ должен сохраняться. При добавлении одного или двух AZ для кластера с одним AZ необходимо изменить AZ для всех узлов. При добавлении одного AZ для кластера с двумя AZ вы можете выбрать изменение AZ для определённых типов узлов или для всех узлов кластера. Например, для кластера с двумя AZ можно использовать три AZ для его master‑узлов, при этом для остальных узлов использовать два AZ. Чтобы завершить изменение AZ, система постарается переместить как можно меньше узлов для восстановления кластера. В процессе также обновляется YML‑файл конфигурации узлов, которые не изменяются. Необходимо перезапустить кластер, чтобы изменения вступили в силу.
• При добавлении AZ для существующего кластера с целью высокой доступности следуйте приведённым ниже правилам распределения узлов:
  • Чтобы обеспечить высокую доступность сервиса и предотвратить перегрузку отдельных узлов в развертывании с несколькими AZ, необходимо соблюсти следующие требования к количеству узлов:
    • Для кластера с двумя AZ, должно быть не менее четырёх узлов данных (или узлов холодных данных), по два на каждый AZ; и должно быть не менее двух клиентских узлов (если они сконфигурированы), по одному на каждый AZ.
    • Для кластера с тремя AZ, каждый доступный тип узлов должен иметь как минимум один узел в каждом AZ. Это означает, что каждый тип узлов должен иметь минимум три узла в общей сложности.
    • Для типов узлов, которые не развернуты (например, отсутствуют узлы холодных данных), требование к минимальному количеству узлов не применяется.
  • Повышение производительности: Чтобы предотвратить неравномерное распределение данных и обеспечить оптимальную производительность запросов и загрузки, количество узлов данных или узлов холодных данных должно быть целым кратным числом AZ.
• При миграции AZ (Migrate AZ) можно выбрать только один целевой AZ. Для этой операции вы можете выбрать миграцию только определённых типов узлов или всех узлов кластера. Например, для кластера с двумя AZ можно переместить master‑узлы из одного 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 > OpenSearch.
3. In the cluster list, find the target cluster, and choose More > Modify Configuration in the Operation column. The Modify Configuration page is displayed.
4. Нажмите вкладку Change AZ.
5. На странице Change AZ задайте параметры.
   Caution

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

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

   Параметр	Описание
   Тип операции	Add AZ: Добавьте один или два AZ для кластера с одним AZ, или добавьте один AZ для кластера с двумя AZ. Для завершения изменения AZ система постарается переместить как можно меньше узлов для восстановления кластера. В процессе также обновляется файл конфигурации YML узлов, которые не изменяются. Необходимо перезапустить кластер, чтобы изменения вступили в силу. Migrate AZ: Переместить данные из одной AZ в другую. После добавления AZ, необходимо перезапустить кластер, чтобы изменения вступили в силу.
   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. Это гарантирует, что все данные были сохранены, поэтому в случае сбоя задачи данные можно восстановить с помощью этого снимка.

   Рисунок 1Check 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 успешно изменён ни для одного из узлов.