Влияние сбоев инфраструктуры на сегмент в сервисе Amazon OpenSearch

Переиздано Платоном

Читают: 0

Сервис Amazon OpenSearch — это управляемый сервис, упрощающий защиту, развертывание и эксплуатацию кластеров OpenSearch и устаревших Elasticsearch в масштабе облака AWS. Amazon OpenSearch Service выделяет все ресурсы для вашего кластера, запускает его, автоматически обнаруживает и заменяет отказавшие узлы, снижая нагрузку на самоуправляемые инфраструктуры. Сервис позволяет легко выполнять интерактивный анализ журналов, мониторинг приложений в реальном времени, поиск по веб-сайтам и многое другое, предлагая последние версии OpenSearch, поддержку 19 версий Elasticsearch (версии от 1.5 до 7.10) и возможности визуализации на базе Панели инструментов OpenSearch и Kibana (версии от 1.5 до 7.10).

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

Если вам нужна дополнительная информация о логике распределения сегментов в целом, см. Демистификация распределения осколков Elasticsearch.

Задача

Домен Amazon OpenSearch Service называется «сбалансированным», когда количество узлов равномерно распределено по настроенным зонам доступности, а общее количество сегментов равномерно распределено по всем доступным узлам без концентрации сегментов какого-либо одного индекса на каком-либо из них. узел. Кроме того, в OpenSearch есть свойство Zone Awareness, которое при включении гарантирует, что первичный сегмент и его соответствующая реплика размещаются в разных зонах доступности. Если у вас есть более одной копии данных, наличие нескольких зон доступности обеспечивает лучшую отказоустойчивость и доступность. В случае масштабирования или масштабирования домена или во время сбоя узла (узлов) OpenSearch автоматически перераспределяет сегменты между доступными узлами, соблюдая правила распределения, основанные на осведомленности о зонах.

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

Например, если один узел в кластере из трех узлов выходит из строя, OpenSearch перераспределяет неназначенные сегменты, как показано на следующей диаграмме. Здесь «P» представляет собой первичную копию сегмента, тогда как «R» представляет собой реплику сегмента.

Такое поведение домена можно объяснить двумя частями — при сбое и при восстановлении.

Во время сбоя

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

Полный отказ зоны

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

Когда сегменты затронутой зоны перераспределяются в исправные зоны, они запускают восстановление сегментов, что может увеличить задержки, поскольку они потребляют дополнительные циклы ЦП и пропускную способность сети.
Для конфигурации n-AZ, n-copy (n>1) оставшиеся n-1 зон доступности выделяются с n-й копией сегмента, что может быть нежелательно, поскольку может привести к перекосу в распределении сегментов, что также может привести к несбалансированный трафик между узлами. Эти узлы могут быть перегружены, что приведет к дальнейшим сбоям.

Частичный отказ зоны

В случае частичного сбоя зоны или когда домен теряет только некоторые узлы в зоне доступности, Amazon OpenSearch Service пытается как можно быстрее заменить отказавшие узлы. Однако, если замена узлов занимает слишком много времени, OpenSearch пытается выделить неназначенные сегменты этой зоны в уцелевшие узлы в зоне доступности. Если служба не может заменить узлы в затронутой зоне доступности, она может выделить их в другой настроенной зоне доступности, что может еще больше исказить распределение осколков как по зоне, так и внутри нее. Это снова имеет непредвиденные последствия.

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

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

Сегодня, чтобы поддерживать желаемое количество узлов домена, Amazon OpenSearch Service запускает узлы данных в оставшихся исправных зонах доступности, аналогично сценариям, описанным выше в разделе о сбоях. Чтобы обеспечить правильное распределение узлов по всем зонам доступности после такого инцидента, AWS потребовалось ручное вмешательство.

Что меняется

Чтобы улучшить общую обработку сбоев и свести к минимуму влияние сбоя на работоспособность и производительность домена, Amazon OpenSearch Service вносит следующие изменения:

Принудительная осведомленность о зоне: OpenSearch имеет ранее существовавшую конфигурацию балансировки осколков, называемую принудительной осведомленностью, которая используется для установки зон доступности, которым должны быть выделены осколки. Например, если у вас есть атрибут осведомленности, называемый зоной, и вы настроили узлы в zone1 и zone2, вы можете использовать принудительную осведомленность, чтобы OpenSearch не выделял реплики, если доступна только одна зона:

cluster.routing.allocation.awareness.attributes: zone
cluster.routing.allocation.awareness.force.zone.values: zone1,zone2

В этом примере конфигурации, если вы запустите два узла с node.attr.zone установлен в zone1 и создать индекс с пятью сегментами и одной репликой, OpenSearch создает индекс и выделяет пять основных сегментов, но не реплики. Реплики выделяются только после того, как узлы с node.attr.zone установлен в zone2 имеются.

Amazon OpenSearch Service будет использовать принудительную настройку осведомленности в доменах с несколькими зонами доступности, чтобы обеспечить выделение сегментов только в соответствии с правилами осведомленности о зонах. Это предотвратит резкое увеличение нагрузки на узлы работоспособных зон доступности.

Распределение осколков с учетом нагрузки: Amazon OpenSearch Service будет учитывать такие факторы, как выделенная емкость, фактическая емкость и общее количество копий сегментов, чтобы вычислить, перегружен ли какой-либо узел большим количеством сегментов, исходя из ожидаемого среднего количества сегментов на узел. Это предотвратило бы назначение осколков, если какой-либо узел выделил количество осколков, превышающее этот предел.

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

Аналогичным образом, чтобы решить проблему ручного восстановления (как описано выше в разделе «Восстановление»), Amazon OpenSearch Service также вносит изменения в свой внутренний компонент масштабирования. После внесения новых изменений Amazon OpenSearch Service не будет запускать узлы в оставшихся зонах доступности, даже если произойдет описанный выше сценарий сбоя.

Визуализация текущего и нового поведения

Например, домен Amazon OpenSearch Service настроен на 3 зоны доступности, 6 узлов данных, 12 основных сегментов и 24 сегмента реплик. Домен предоставляется в зонах доступности AZ-1, AZ-2 и AZ-3, по два узла в каждой из зон.

Текущее распределение осколков:
Общее количество осколков: 12 основных + 24 реплики = 36 осколков.
Количество зон доступности: 3
Количество осколков в зоне (осведомленность о зоне верна): 36/3 = 12
Количество узлов на зону доступности: 2
Количество осколков на узел: 12/2 = 6

На следующей диаграмме показано визуальное представление настройки домена. Кружки обозначают количество осколков, выделенных узлу. Amazon OpenSearch Service будет выделять шесть сегментов на каждый узел.

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

На приведенной выше диаграмме при потере одного узла в AZ-3 Amazon OpenSearch Service попытается запустить заменяющую емкость в той же зоне. Однако из-за какого-либо сбоя зона может быть повреждена, и запуск замены будет невозможен. В таком случае служба пытается запустить недостающую мощность в другой работоспособной зоне, что может привести к дисбалансу зон между зонами доступности. Осколки затронутой зоны помещаются в выживший узел в той же зоне. Однако с новым поведением служба попытается запустить мощности в той же зоне, но будет избегать запуска дефицитных мощностей в других зонах, чтобы избежать дисбаланса. Распределитель сегментов также гарантирует, что выжившие узлы не будут перегружены.

Аналогичным образом, в случае потери всех узлов в AZ-3 или нарушения работы AZ-3 сервис Amazon OpenSearch поднимает потерянные узлы в оставшейся зоне доступности, а также перераспределяет сегменты по узлам. Однако после новых изменений Amazon OpenSearch Service не будет выделять узлы в оставшуюся зону или попытается перераспределить потерянные сегменты в оставшуюся зону. Amazon OpenSearch Service будет ждать, пока произойдет восстановление и домен вернется к исходной конфигурации после восстановления.

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

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

Что вы можете ожидать,

После того как вы обновите свой домен Amazon OpenSearch Service до последней версии сервисного программного обеспечения, домены, которые были настроен с учетом лучших практик будет иметь более предсказуемую производительность даже после потери одного или нескольких узлов данных в зоне доступности. Будет уменьшено количество случаев перераспределения сегментов в узле. Хорошей практикой является предоставление достаточной мощности, чтобы иметь возможность выдержать сбой в одной зоне.

Время от времени вы можете видеть, как домен становится желтым во время таких неожиданных сбоев, поскольку мы не будем назначать сегменты реплик перегруженным узлам. Однако это не означает, что в хорошо настроенном домене будет потеря данных. Мы по-прежнему будем следить за тем, чтобы все основные цвета были назначены во время сбоев. Существует автоматическое восстановление, которое позаботится о балансировке узлов в домене и обеспечении назначения реплик после устранения сбоя.

Обновите служебное программное обеспечение своего домена Amazon OpenSearch Service, чтобы эти новые изменения применялись к вашему домену. Подробнее о процессе обновления сервисного ПО см. Документация по сервису Amazon OpenSearch.

Заключение

В этом посте мы увидели, как Amazon OpenSearch Service недавно улучшил логику распределения узлов и сегментов по зонам доступности во время зональных сбоев.

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

Об авторах

Бухтавар Хан — старший инженер-программист, работающий над Amazon OpenSearch Service. Интересуется распределенными и автономными системами. Он является активным участником OpenSearch.

Аншу Агарвал — старший инженер-программист, работающий над AWS OpenSearch в Amazon Web Services. Она увлечена решением проблем, связанных с построением масштабируемых и высоконадежных систем.

Шурья Дутта Бисвас — инженер-программист, работающий над AWS OpenSearch в Amazon Web Services. Он увлечен созданием высокоустойчивых распределенных систем.

Ришаб Нахата — инженер-программист, работающий над OpenSearch в Amazon Web Services. Он увлечен решением проблем в распределенных системах. Он является активным участником OpenSearch.

Ранджит Рамачандра является техническим менеджером, работающим над Amazon OpenSearch Service в Amazon Web Services.

Джон Хэндлер — старший главный архитектор решений, специализирующийся на поисковых технологиях AWS — Amazon CloudSearch и Amazon OpenSearch Service. Находясь в Пало-Альто, он помогает широкому кругу клиентов правильно развернуть и обеспечить бесперебойную работу рабочих нагрузок поиска и аналитики журналов.