Настройка Amazon OpenSearch Service для обеспечения высокой доступности | Веб-сервисы Амазонки

Настройка Amazon OpenSearch Service для обеспечения высокой доступности | Веб-сервисы Амазонки

Отметка времени: 31 мая 2023 г., 12:56
Исходный узел: 2691649

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

Ассоциация отраслевой стандарт для измерения доступности это класс девяток. Служба OpenSearch обеспечивает доступность по принципу «три девятки», когда вы следуете лучшие практики, что означает, что он гарантирует менее 43.83 минут простоя в месяц. В этом посте вы узнаете, как настроить домен службы OpenSearch для обеспечения высокой доступности и производительности, следуя передовым методам и рекомендациям при настройке домена.

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

Давайте рассмотрим доступные вам варианты, чтобы убедиться, что домен доступен и работает.

Конфигурация кластера

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

Развертывание в нескольких зонах доступности

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

Выделенный менеджер кластера (главные узлы)

AWS рекомендует использовать три выделенных узла диспетчера кластера (CM). для всех производственных нагрузок. Узлы CM отслеживают работоспособность кластера, состояние и расположение его индексов и сегментов, сопоставление всех индексов и доступность его узлов данных, а также поддерживают список выполняемых задач на уровне кластера. Без выделенных узлов CM кластер использует узлы данных, что делает кластер уязвимым для требований рабочей нагрузки. Вы должны определять размеры узлов CM в зависимости от размера задачи — в первую очередь, количество узлов данных, количество индексов и количество сегментов. Служба OpenSearch всегда развертывает узлы CM в трех зонах доступности, если это поддерживается регионом (два в одной зоне доступности и один в других зонах доступности, если в регионах есть только две зоны доступности). Для работающего домена только один из трех узлов CM работает в качестве избранного лидера. Два других узла CM участвуют в выборах, если выбранный узел CM выходит из строя.

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

Количество экземпляров Размер оперативной памяти узла диспетчера кластера Максимальное поддерживаемое количество осколков Рекомендуемый минимальный тип экземпляра выделенного диспетчера кластеров
1-10 8 GiB 10,000 m5.large.search или m6g.large.search
11-30 16 GiB 30,000 c5.2xlarge.search или c6g.2xlarge.search
31-75 32 GiB 40,000 c5.4xlarge.search или c6g.4xlarge.search
76 – 125 64 GiB 75,000 r5.2xlarge.search или r6g.2xlarge.search
126 – 200 128 GiB 75,000 r5.4xlarge.search или r6g.4xlarge.search

Индексы и осколки

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

Мониторинг и управление кластером

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

Использование ЦП

Вы используете ЦП в своем домене для выполнения своей рабочей нагрузки. Как правило, вы должны ориентироваться на среднюю загрузку ЦП 60 % для любого узла данных с пиками на уровне 80 % и допускать небольшие пики до 100 %. Когда вы рассматриваете доступность, и особенно учитывая недоступность полной зоны, есть два сценария. Если у вас две зоны доступности, то каждая зона обрабатывает 50% трафика. Если зона становится недоступной, другая зона забирает весь этот трафик, удваивая загрузку ЦП. В этом случае для поддержания доступности необходимо обеспечить среднюю загрузку ЦП на уровне 30–40 % в каждой зоне. Если вы используете три зоны доступности, каждая зона принимает 33% трафика. Если зона становится недоступной, каждая другая зона получит примерно 17% трафика. В этом случае вы должны ориентироваться на среднюю загрузку ЦП 50–60%.

Использование памяти

Служба OpenSearch поддерживает два типа сборки мусора. Первая — это сборка мусора G1 (G1GC), которая используется узлами службы OpenSearch на базе АМС Гравитон 2. Второй — Concurrent Mark Sweep (CMS), который используется всеми узлами, работающими на других процессорах. Из всей памяти, выделенной узлу, половина памяти (до 32 Гб) отводится кучи Java, а оставшаяся часть памяти используется другими задачами операционной системы, кешем файловой системы и так далее. Чтобы поддерживать доступность домена, мы рекомендуем поддерживать максимальное использование JVM на уровне около 80 % в CMS и 95 % в G1GC. Все, что выходит за рамки этого, повлияет на доступность вашего домена и сделает ваш кластер неработоспособным. Мы также рекомендуем включить автонастройку, которая активно отслеживает использование памяти и запускает сборщик мусора.

Использование хранилища

Служба OpenSearch публикует несколько руководств по размер доменов. Мы предоставляем эмпирическую формулу, чтобы вы могли определить правильный объем хранилища, необходимый для ваших требований. Однако важно следить за истощением хранилища со временем и изменениями характеристик рабочей нагрузки. Чтобы домен не исчерпал пространство для хранения и мог продолжать индексировать данные, необходимо настроить Amazon CloudWatch сигналы тревоги и следить за свободным местом для хранения.

AWS также рекомендует выбирать количество основных сегментов, чтобы каждый сегмент находился в оптимальном диапазоне размеров. Вы можете определить оптимальный размер сегмента с помощью проверки концепции с вашими данными и трафиком. Мы используем размеры основных сегментов 10–30 ГБ для вариантов использования поиска и размеры основных сегментов 45–50 ГБ для вариантов использования аналитики журналов в качестве рекомендации. Поскольку сегменты являются рабочими в вашем домене, они напрямую отвечают за распределение рабочей нагрузки между узлами данных. Если ваши сегменты слишком велики, вы можете столкнуться с нагрузкой в ​​куче Java из-за больших агрегаций, ухудшения производительности запросов и задач на уровне кластера, таких как перебалансировка сегментов, моментальные снимки и миграция «горячих» к «теплым». Если ваши сегменты слишком малы, они могут переполнить пространство кучи Java в домене, ухудшить производительность запросов из-за чрезмерной внутренней сети и замедлить выполнение задач на уровне кластера. Мы также рекомендуем, чтобы количество сегментов на узел пропорционально доступной куче (половина оперативной памяти экземпляра до 32 ГБ) — 25 сегментов на ГБ кучи Java. Это делает практический предел в 1,000 сегментов на любом узле данных в вашем домене.

Заключение

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

Следите за серией сообщений, посвященных различным возможностям и функциям OpenSearch Service. Если у вас есть отзывы об этом посте, отправьте их в разделе комментариев. Если у вас есть вопросы по этому сообщению, начните новую тему на Форум службы OpenSearch или контакт Поддержка AWS.

Об авторах

Рохин Бхаргава является старшим менеджером по продукту в команде Amazon OpenSearch Service. Его страстью в AWS является помощь клиентам в подборе правильного сочетания сервисов AWS для достижения успеха в достижении их бизнес-целей.

Прашант Агравал является старшим специалистом по поиску, архитектором решений в Amazon OpenSearch Service. Он тесно сотрудничает с клиентами, помогая им перенести свои рабочие нагрузки в облако, и помогает существующим клиентам настраивать свои кластеры для повышения производительности и экономии средств. Перед тем, как присоединиться к AWS, он помогал различным клиентам использовать OpenSearch и Elasticsearch для поиска и анализа журналов. Когда он не работает, вы можете найти его путешествующим и исследующим новые места. Короче говоря, ему нравится делать «Ешь» → «Путешествуй» → «Повторять».

Отметка времени:

Больше от AWS Большие данные