Вплив збоїв інфраструктури на фрагмент у службі Amazon OpenSearch

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

В останньому випуску сервісного програмного забезпечення ми оновили логіку розподілу шардів, щоб вона була з урахуванням навантаження, щоб під час перерозподілу шардів у разі будь-яких збоїв вузла служба не дозволяла вцілілим вузлам перевантажуватися шардами, які раніше були розміщені на несправному вузлі. Це особливо важливо для доменів Multi-AZ, щоб забезпечити послідовну та передбачувану продуктивність кластера.

Якщо вам потрібна додаткова інформація про логіку розподілу шардів загалом, див Демістифікація розміщення фрагментів Elasticsearch.

Змагання

Домен Amazon OpenSearch Service вважається «збалансованим», якщо кількість вузлів рівномірно розподілено між налаштованими зонами доступності, а загальна кількість фрагментів розподілена рівномірно між усіма доступними вузлами без концентрації сегментів будь-якого одного індексу на будь-якому одному. вузол. Крім того, OpenSearch має властивість під назвою «Інформація про зону», яка, коли її ввімкнено, гарантує, що основний шард і його відповідна репліка розміщено в різних зонах доступності. Якщо у вас більше однієї копії даних, наявність кількох зон доступності забезпечує кращу відмовостійкість і доступність. У разі масштабування домену або під час збою вузла (вузлів) OpenSearch автоматично перерозподіляє шарди між доступними вузлами, дотримуючись правил розподілу на основі визначення зони.

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

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

Таку поведінку домену можна пояснити двома частинами – під час відмови та під час відновлення.

Під час невдачі

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

Повний збій зони

З різних причин кластер може втратити одну зону доступності, а також усі вузли в цій зоні. Сьогодні служба намагається розмістити втрачені вузли в решті здорових зон доступності. Служба також намагається відтворити втрачені сегменти в інших вузлах, дотримуючись правил розподілу. Це може призвести до небажаних наслідків.

• Коли сегменти ураженої зони перерозподіляються на здорові зони, вони запускають відновлення шардів, що може збільшити затримки, оскільки це споживає додаткові цикли процесора та пропускну здатність мережі.
• Для налаштування n-AZ, n-копій, (n>1), уцілілі n-1 зони доступності розподіляються з n-ю шард-копією, що може бути небажаним, оскільки це може спричинити нерівність у розподілі сегментів, що також може призвести до незбалансований трафік між вузлами. Ці вузли можуть бути перевантажені, що призведе до подальших збоїв.

Відмова часткової зони

У разі часткового збою зони або коли домен втрачає лише деякі вузли в зоні доступності, служба Amazon OpenSearch намагається замінити несправні вузли якомога швидше. Однак, якщо заміна вузлів займає надто багато часу, 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 використовуватиме конфігурацію примусової обізнаності в доменах Multi-AZ, щоб гарантувати, що фрагменти розподіляються лише згідно з правилами обізнаності про зони. Це запобіжить раптове збільшення навантаження на вузли здорових зон доступності.

• Розподіл сегментів з урахуванням навантаження: Служба Amazon OpenSearch враховуватиме такі фактори, як передбачена ємність, фактична ємність і загальна кількість копій сегментів, щоб обчислити, чи перевантажений якийсь вузол більшою кількістю сегментів на основі очікуваної середньої кількості сегментів на вузол. Це запобіжить розподіл сегментів, якщо будь-який вузол виділить кількість сегментів, що перевищує це обмеження.

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

Так само, щоб вирішити проблему відновлення вручну (як описано в розділі «Відновлення» вище), Amazon OpenSearch Service також вносить зміни у свій внутрішній компонент масштабування. З новими змінами служба Amazon OpenSearch не запускатиме вузли в зонах доступності, що залишилися, навіть якщо проходить описаний раніше сценарій збою.

Візуалізація поточної та нової поведінки

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

Поточний розподіл фрагментів:
Загальна кількість осколків: 12 основних + 24 репліки = 36 осколків
Кількість зон доступності: 3
Кількість осколків на зону (усвідомлення зони вірне): 36/3 = 12
Кількість вузлів на зону доступності: 2
Кількість осколків на вузол: 12/2 = 6

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

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

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

Подібним чином, якщо всі вузли в AZ-3 буде втрачено або AZ-3 стане несправним, Amazon OpenSearch Service відкриє втрачені вузли в зоні доступності, що залишилася, а також перерозподілить фрагменти на вузлах. Однак після нових змін Amazon OpenSearch Service не розподілятиме вузли для зони, що залишилася, або намагатиметься перерозподілити втрачені сегменти для зони, що залишилася. Amazon OpenSearch Service чекатиме, доки відбудеться відновлення та домен повернеться до вихідної конфігурації після відновлення.

Якщо ваш домен не має достатньої потужності, щоб витримати втрату зони доступності, ви можете відчути падіння пропускної здатності для вашого домену. Тому наполегливо рекомендуємо дотримуватися найкращих практик під час визначення розміру домену, що означає наявність достатньої кількості ресурсів, щоб витримати втрату одного збою в зоні доступності.

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

Те, що ви можете очікувати

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

Іноді ви можете побачити, як домен стає жовтим під час таких неочікуваних збоїв, оскільки ми не будемо призначати фрагменти реплік перевантаженим вузлам. Однак це не означає, що в добре налаштованому домені відбудеться втрата даних. Ми все одно подбаємо про те, щоб усі первинні були призначені під час відключень. Існує автоматичне відновлення, яке подбає про балансування вузлів у домені та гарантує, що репліки будуть призначені після відновлення збою.

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

Висновок

У цій публікації ми побачили, як Amazon OpenSearch Service нещодавно вдосконалив логіку розподілу вузлів і сегментів між зонами доступності під час зональних збоїв.

Ця зміна допоможе службі забезпечити більш узгоджену та передбачувану продуктивність під час збоїв вузлів або зон. Домени не бачитимуть жодних збільшених затримок або блоків запису під час обробки записів і читань, які іноді з’являлися раніше через надмірний розподіл сегментів на вузлах.

Про авторів

Бухтавар-хан є старшим інженером-програмістом, який працює над Amazon OpenSearch Service. Його цікавлять розподілені та автономні системи. Він є активним учасником OpenSearch.

Аншу Агарвал є старшим інженером-програмістом, який працює над AWS OpenSearch в Amazon Web Services. Вона захоплена вирішенням проблем, пов’язаних зі створенням масштабованих і високонадійних систем.

Шурья Дутта Бісвас є інженером-програмістом, який працює над AWS OpenSearch в Amazon Web Services. Він захоплений створенням високостійких розподілених систем.

Рішаб Нахата є інженером-програмістом, який працює над OpenSearch в Amazon Web Services. Його захоплює вирішення проблем у розподілених системах. Він є активним учасником OpenSearch.

Ранджит Рамачандра є інженерним менеджером, який працює над службою Amazon OpenSearch в Amazon Web Services.

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

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• Платоблокчейн. Web3 Metaverse Intelligence. Розширені знання. Доступ тут.
• джерело: https://aws.amazon.com/blogs/big-data/impact-of-infrastructure-failures-on-shard-in-amazon-opensearch-service/