Руководство по стратегиям масштабирования кластера Elasticsearch для роста

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

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

Понимание основ масштабирования Elasticsearch

Масштабирование кластера Elasticsearch в основном включает две стратегии: Вертикальное масштабирование (увеличение) и Горизонтальное масштабирование (расширение). Оптимальная стратегия часто требует тщательного баланса обоих подходов, определяемого характеристиками вашей рабочей нагрузки.

Вертикальное масштабирование (увеличение)

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

Когда использовать вертикальное масштабирование:

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

Основные обновления ресурсов:

ОЗУ (Память): Elasticsearch требует JVM heap и большой кэш файловой системы ОС. Распространенная отправная точка — установить heap около 50% системной ОЗУ, оставаясь ниже порога сжатых обычных указателей объектов, который часто составляет около 26-32 ГБ в зависимости от JVM.
ЦП: Необходим для сложных агрегаций, интенсивной индексации и высокой конкурентности запросов.
Хранилище (ввод-вывод диска): Более быстрые SSD или NVMe диски значительно улучшают пропускную способность индексации и скорость поиска, особенно для рабочих нагрузок с интенсивным вводом-выводом.

Предупреждение о вертикальном масштабировании: Очень большие JVM heap могут потерять преимущества сжатых обычных указателей объектов и могут страдать от более длительных пауз сборки мусора. Дополнительная ОЗУ все еще полезна для кэша файловой системы, но увеличение размера heap не является долгосрочным планом масштабирования.

Горизонтальное масштабирование (расширение)

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

Когда использовать горизонтальное масштабирование:

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

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

Архитектурные лучшие практики для масштабируемости

Масштабирование — это не только добавление оборудования; оно требует хорошо структурированной топологии индексов и узлов.

Роли узлов и специализация

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

Роль узла	Основная ответственность	Рекомендация по лучшей практике
Master узлы	Управление состоянием кластера, стабильность.	Выделенный набор из 3 или 5 узлов. Не должны обрабатывать данные или запросы на индексацию.
Data узлы	Хранение данных, индексация, поиск.	Масштабируйте их агрессивно в зависимости от объема данных и нагрузки.
Ingest узлы	Предварительная обработка документов перед индексацией (с использованием конвейеров ingest).	Снимите нагрузку по предварительной обработке, интенсивно использующую ЦП, с узлов данных.
Coordinating узлы	Обработка больших поисковых запросов, сбор результатов с узлов данных.	Добавляйте их, когда поисковые запросы становятся сложными или часто перегружают узлы данных накладными расходами на координацию.

Стратегия распределения шардов

Шарды — это фундаментальная единица распределения и параллелизма в Elasticsearch. Плохое распределение шардов является основной причиной проблем с масштабированием.

1. Оптимизация количества первичных шардов

Выбор правильного количества первичных шардов (index.number_of_shards) критичен и не может быть легко изменен после создания индекса (если только не использовать псевдонимы индексов или переиндексацию).

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

Лучшая практика: Для многих рабочих нагрузок временных рядов и журналов стремитесь к размеру шардов в десятки гигабайт, часто примерно от 10 ГБ до 50 ГБ. Относитесь к этому как к начальному диапазону, затем тестируйте с вашей собственной скоростью индексации, окном хранения и шаблоном запросов.

2. Реплики шардов для высокой доступности и пропускной способности чтения

Реплики шардов (index.number_of_replicas) обеспечивают избыточность и увеличивают емкость чтения.

Установка number_of_replicas: 1 означает, что каждый первичный шард имеет одну копию, обеспечивая высокую доступность (HA).
Увеличение реплик может улучшить емкость чтения, поскольку поиск может обслуживаться как первичными, так и реплицированными копиями, но это также увеличивает использование хранилища и работу по индексации.

Пример настройки HA: Если у вас 10 первичных шардов и вы установили number_of_replicas: 1, кластеру потребуется как минимум 20 копий шардов (10 первичных + 10 реплик), распределенных по узлам.

PUT /my_growing_index
{
  "settings": {
    "index.number_of_shards": 20,
    "index.number_of_replicas": 1 
  }
}

Предотвращение горячих точек с помощью осведомленности

При добавлении новых узлов убедитесь, что шарды распределены по доменам отказов. Elasticsearch автоматически перебалансирует, но осведомленность о зонах или стойках работает только в том случае, если вы настроите атрибуты узлов и настройки осведомленности о распределении.

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

Практические шаги масштабирования: Управление ростом

Когда производительность вашего кластера ухудшается (высокое давление на JVM heap, медленные запросы, медленная индексация), выполняйте следующие шаги по порядку:

Шаг 1: Мониторинг и диагностика

Прежде чем вносить изменения, диагностируйте узкое место. Общие индикаторы:

Высокая загрузка ЦП/Низкая свободная память: Указывает на нехватку вычислительных ресурсов или памяти (потенциальная потребность в вертикальном масштабировании).
Чрезмерная длина очереди диска: Указывает на узкое место ввода-вывода (требуются более быстрые диски или добавление узла).
Скачки задержки поиска: Часто из-за недостаточного кэширования или слишком малого количества шардов/реплик (требуется больше памяти или горизонтальное масштабирование).

Шаг 2: Удовлетворение непосредственных потребностей в ресурсах (вертикальные настройки)

Если давление на память высокое, увеличьте размер JVM heap в безопасных пределах (макс. 32 ГБ) и убедитесь, что достаточно ОЗУ для кэша файловой системы ОС.

Шаг 3: Горизонтальное расширение

Если добавляете узлы, следуйте этой процедуре:

Подготовьте новые узлы данных с идентичным или более мощным оборудованием.
Настройте их с правильными ролями. Для роста емкости это обычно роли данных, такие как data_hot, data_content или data, в зависимости от вашего развертывания.
Укажите им на существующий кластер, используя discovery.seed_hosts.
Как только новые узлы присоединятся, Elasticsearch автоматически начнет перебалансировку существующих шардов для использования новой емкости.

Шаг 4: Защита индексов на будущее (переиндексация)

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

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

Пример команды переиндексации:

POST _reindex
{
  "source": {
    "index": "old_index_bad_shards"
  },
  "dest": {
    "index": "new_index_optimized_shards"
  }
}

Контрольный список лучших практик

Масштабирование Elasticsearch работает лучше всего, когда вы сначала мониторите, меняете одну переменную за раз и поддерживаете макет шардов в соответствии с вашим шаблоном роста.

Ключевые выводы:

Отдавайте приоритет горизонтальному масштабированию: Оно предлагает наилучший путь для непрерывного роста и отказоустойчивости.
Выделенные master узлы: Поддерживайте стабильность управления кластером, отделяя роли master.
Размер шардов постоянен: Стремитесь к размеру первичных шардов 10-50 ГБ при создании индекса.
Мониторьте JVM heap: Держите heap ниже порога сжатых указателей для вашей JVM и оставляйте достаточно ОЗУ для кэша ОС.
Используйте переиндексацию: Перестраивайте критически важные индексы, когда горизонтальное масштабирование требует изменения количества первичных шардов.