Ми оновили старий великий кластер Elasticsearch 3PB без простою

У 2018 році, тобто п’ять років тому, ми опублікували допис у блозі з описом нашого кластера Elasticsearch із понад 400 вузлами. У цій статті ми розглянули важливу тему:

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

Ну, нарешті день оновлення настав.

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

Ми вирішили написати цю серію дописів у блозі, щоб поділитися отриманими уроками та описати деякі проблеми, з якими ми зіткнулися, і те, як ми їх подолали.

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

Частина 2 – Два когерентних кластери (18 листопада)

Частина 3: Ефективність пошуку та шаблони підстановки (25 листопада)

Частина 4. Токенізація для високого запам’ятовування всіма мовами (2 грудня)

Частина 5 – Процес розробки (9 грудня)

Частина 6. Тестування та стратегія розгортання (16 грудня)

Частина 7. Остаточна архітектура та навчання (23 грудня)

Тож слідкуйте за новинами, щоб дізнатися більше.

Передумови та випадки використання

Як описано в попередніх публікаціях блогу, у Meltwater ми використовуємо пошукову систему з відкритим кодом Elasticsearch. Ми використовуємо його для зберігання приблизно 400 мільярдів дописів у соціальних мережах і редакційних статей із усіх можливих джерел новин. Платформа надає нашим клієнтам результати досліджень високого рівня, діаграми, аналітику, експорт наборів даних і аналітику.

До минулого місяця цей величезний набір даних розміщувався в користувальницькій версії Elasticsearch, керованої внутрішньо. Кластер містив майже 1100 вузлів i3en.3xlarge, що працюють в AWS. Кластер мав кілька тисяч індексів, майже 100 000 фрагментів і майже 1 ПБ первинних даних, які зросли до понад 3 ПБ із репліками.

Сьогодні, після оновлення, набір даних фактично трохи більший, 3,5 ПБ (з причин, які ми пояснимо в наступній публікації в блозі), а загальна кількість вузлів тепер становить «лише» 320 (переважно екземпляри i3en.6xlarge ). Можливо, найголовніше те, що зараз ми використовуємо офіційно підтримувану версію Elasticsearch.

Причини оновлення

Для старіших версій Elasticsearch Elastic і Amazon не рекомендують запускати кластери розміром понад 100 вузлів. Але, як ви, мабуть, уже зрозуміли, ми перевищили цю межу багато років тому. Ми продовжуємо виправляти та вдосконалювати нашу спеціальну збірку, щоб і надалі обслуговувати наш бізнес, що розвивається, і випадки використання, що постійно розширюються.

Однак у міру зростання нашого кластеру ми відчули обмеження використання такої старої версії. Наприклад, версія, яку ми використовували, погано справлялася з поступовими оновленнями стану кластера. Elasticsearch надсилав увесь стан, який у нашому випадку становив >100 МБ, до кожного з наших 1100 вузлів для кожної зміни стану. Це означало що значним вузьким місцем була пропускна здатність нашої мережі 100 гігабіт на головних вузлах.

Деякі інші проблеми зі старішою версією Elasticsearch:

Непередбачувана поведінка, коли вузли та фрагменти залишають кластер або приєднуються до нього

Керування резервним копіюванням S3

Через неефективність у тому, як стара версія Elasticsearch обробляла репозиторії, схожі на S3, ми не змогли видалити старі резервні копії достатньо швидко, щоб не відставати від...