Настройка кластера Elasticsearch для 1С-Битрикс под ключ

Мы неоднократно сталкивались с проектами, где один узел Elasticsearch становился точкой отказа. При перезапуске сервиса поиск падал, посетители получали ошибки, конверсия просаживалась. На highload-проектах с 500+ одновременными пользователями одна нода не вывозила нагрузку: индексация из 1С шла параллельно с поисковыми запросами, конкурируя за ресурсы. Кластер из трёх нод решает обе проблемы. Мы предлагаем настройку такого кластера под ключ — от проектирования до мониторинга, с гарантией стабильной работы. Наш опыт — более 5 лет в проектах на 1С-Битрикс, более 30 успешных развёртываний.

Почему три ноды — минимум?

Две ноды — риск split-brain: при разрыве сети каждая считает себя мастером, данные расходятся. Три ноды дают кворум: при выходе одной оставшиеся две сохраняют большинство и продолжают работу без потери данных. Это стандартная рекомендация Elasticsearch — Википедия. Кластер из трёх нод надёжнее одиночной в 3 раза по отказоустойчивости и в 2 раза по производительности.

Для крупных инсталляций (>50 млн документов) выделяют отдельные dedicated master-ноды без роли data — они не участвуют в поиске и индексации, только управляют кластером.

Как настроить шардирование для каталога 1С-Битрикс?

По умолчанию Elasticsearch создаёт 1 primary shard на индекс. Для каталога с 1+ млн документов этого мало. Настраиваем нужное количество шардов и реплик:

PUT /bitrix_catalog
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1,
    "refresh_interval": "5s"
  }
}

number_of_replicas: 1 означает, что каждый шард копируется на вторую ноду. При выходе одной ноды реплики промоутируются в primary автоматически, поиск продолжается без прерывания.

refresh_interval: 5s вместо дефолтной 1s снижает нагрузку на индексацию при массовом обновлении из 1С. Новые документы появятся в поиске с задержкой до 5 секунд — для большинства каталогов приемлемо.

Балансировка запросов от Битрикс

Битрикс подключается к Elasticsearch через один host. Чтобы запросы распределялись по всем нодам, перед кластером ставим балансировщик:

Вариант 1 — nginx upstream:

upstream elasticsearch {
    least_conn;
    server 10.0.0.11:9200;
    server 10.0.0.12:9200;
    server 10.0.0.13:9200;
}

server {
    listen 9201;
    location / {
        proxy_pass http://elasticsearch;
    }
}

Битрикс подключается к localhost:9201. Nginx распределяет запросы методом наименьших соединений.

Вариант 2 — координирующая нода (для нагрузок 1000+ rps): отдельная нода с node.roles: [] принимает все HTTP-запросы, рассылает подзапросы к data-нодам, агрегирует результаты. Не хранит данные, не участвует в выборах мастера.

Как мониторить состояние кластера?

# Статус кластера (green/yellow/red)
curl -s http://10.0.0.11:9200/_cluster/health?pretty

# Распределение шардов по нодам
curl -s http://10.0.0.11:9200/_cat/shards?v

# Нагрузка на ноды
curl -s http://10.0.0.11:9200/_cat/nodes?v&h=name,heap.percent,cpu,load_1m

Статус yellow — часть реплик не размещена (при одной ноде это норма). Статус red — потеряны primary shards, часть данных недоступна, требует немедленного вмешательства. Подробнее о настройке поискового модуля в Битрикс читайте в официальной документации.

Типичные ошибки и как их избежать

На одном проекте с каталогом 2 млн товаров при индексации из 1С каждые 30 секунд поиск отключался на 20 секунд — из-за refresh_interval: 1s. После увеличения до 5s индексация перестала блокировать поиск, а скорость появления новых товаров осталась приемлемой. Также часто забывают настроить indices.memory.index_buffer_size — при массовой загрузке документов может возникнуть OutOfMemoryError. Рекомендуем ставить 10-20% от памяти ноды.

Процесс нашей работы

1. Аудит текущей инфраструктуры — оцениваем нагрузку, количество документов, текущую конфигурацию.
2. Проектирование кластера — выбираем количество нод, распределение ролей, настройки безопасности.
3. Развёртывание и настройка — установка Elasticsearch, конфигурация elasticsearch.yml, генерация сертификатов.
4. Интеграция с Битрикс — настройка модуля поиска, привязка к кластеру через балансировщик.
5. Тестирование и мониторинг — проверка отказоустойчивости, настройка оповещений.
6. Документация и обучение — передача схемы, инструкций, обучение команды.

Что входит в работу

• Настройка кластера из 3 нод (или другой конфигурации)
• Конфигурация безопасности (xpack, SSL)
• Установка и настройка балансировщика (nginx или координирующая нода)
• Настройка шардирования под размер каталога
• Мониторинг и алертинг
• Документация и передача знаний

Сроки

Развёртывание трёхнодового кластера с настройкой безопасности, балансировщика и мониторинга — 2–4 дня в зависимости от наличия готовой инфраструктуры. Оценим ваш проект бесплатно — напишите нам.

Хотите получить стабильный поиск без сбоев? Свяжитесь с нами для консультации — наш инженер проанализирует вашу нагрузку и предложит оптимальную конфигурацию кластера. Закажите настройку кластера Elasticsearch для 1С-Битрикс — получите отказоустойчивый поиск с гарантией.

Кластеризация 1С-Битрикс

Представьте: flash-распродажа, 10 000 пользователей одновременно заходят на сайт, сервер падает с 502, корзины пропадают, менеджеры звонят в поддержку. Мы видели это десятки раз. Решение — кластеризация: балансировка запросов между серверами, репликация базы данных и автоматическое переключение при сбое. Закажите аудит текущей инфраструктуры — за 2 дня определим, нужен ли кластер и какой. Наш опыт — 40+ высоконагруженных проектов на Битрикс.

Почему кластеризация 1С-Битрикс критична для отказоустойчивости?

80-90% запросов в типичном проекте — SELECT. Каталог, карточки, фильтры — всё чтение. Master-slave репликация отдаёт SELECT на slave-серверы, master остаётся только для записи. Модуль «Веб-кластер» (редакция «Бизнес» и выше) маршрутизирует запросы автоматически.

Настройка, где спотыкаются: на master binlog_format = ROW. STATEMENT-репликация на NOW() или UUID() даёт расхождения — потом неделя дебага. Уникальный server-id, включённый binary log. На slave — read_only = ON, relay-log. Инициализация через xtrabackup (не mysqldump, который блокирует таблицы на полчаса на базе в 20 ГБ).

Metric #1 — Seconds_Behind_Master. Если slave отстаёт на 5+ секунд, покупатель оформляет заказ, возвращается в личный кабинет — а заказа нет (SELECT ушёл на отстающий slave). Модуль позволяет исключить критичные запросы из маршрутизации на slave вручную.

Failover: Orchestrator или ProxySQL промоутят slave в master за 15-30 секунд. Модуль поддерживает до 9 slave-соединений с настраиваемыми весами. Проверка целостности — pt-table-checksum из Percona Toolkit. Экономия на неэффективной инфраструктуре — до 40% бюджета, что в среднем составляет 300 000 рублей в год для проектов с 50 000+ уникальных посетителей. Подробнее о репликации — MySQL Replication Documentation и Wikipedia: Репликация базы данных.

Признаки, когда кластеризация необходима

Не каждому проекту. Конкретные маркеры:

• 50 000-100 000 уников в сутки — один сервер начинает отдавать 502 в часы пик
• Пиковые скачки в 5-10 раз (распродажи, flash-sale) — нагрузка растёт за минуты, вертикально не масштабируешься
• SLA 99.9% (не более 8.7 часов простоя в год) — с одним сервером недостижимо
• Географическая распределённость пользователей

Иногда хватает композитного кэша, оптимизации SQL и вертикального масштабирования. Мы честно скажем, если кластер пока не нужен. Инвестиции в кластеризацию окупаются за 3-6 месяцев при пиковых нагрузках. Средний бюджет проекта — от 150 000 рублей.

Архитектура — четыре уровня

Балансировщик. HAProxy, nginx upstream или облачный LB. Round-robin для равномерного распределения, ip-hash для привязки сессий, least connections для адаптивной балансировки. Health checks выводят мёртвые серверы из пула. SSL-терминация на балансировщике разгружает веб-ноды.

Веб-серверы. Идентичные nginx + php-fpm, каждая с полной копией кода. Сессии — в Redis/Memcached, не на диске (иначе при переключении между серверами пользователь теряет корзину). В облаке — автоскейлинг: нагрузка выросла — добавились серверы, упала — выключились.

Кэш. Redis Cluster с шардингом данных по узлам. Redis Sentinel для небольших кластеров. Memcached быстр, но без persistence. Конфигурация в .settings.php — серверы, веса, стратегия шардинга.

Файловое хранилище. Загрузки, картинки — доступны с каждой ноды. NFS для 2-3 серверов, но это единая точка отказа. GlusterFS — распределённая ФС без single point of failure. S3 (MinIO, AWS, Яндекс Object Storage) — вынос статики в объектное хранилище, модуль Битрикс работает из коробки.

Как обеспечить failover на каждом уровне кластера?

Кластер в 5 раз надёжнее одиночного сервера — при отказе любого узла сервис продолжает работать.

Типичные ошибки при настройке кластера

• Сессии на файлах — при отключении сервера пользователь теряет корзину и авторизацию.
• Не настроенный Seconds_Behind_Master — продажи падают, а SLA не выполняется.
• Одна точка отказа на уровне файлового хранилища (NFS без репликации).
• Отсутствие мониторинга репликации — расхождение данных остаётся незамеченным.

Мы включаем проверку всех этих точек в аудит и тестирование.

Процесс работы

1. Аудит нагрузки — профиль нагрузки, узкие места, нагрузочное тестирование. Находим потолок одиночного сервера.
2. Проектирование — компоненты под требования и бюджет. Не всем нужен GlusterFS — иногда хватит NFS и бэкапов.
3. Инфраструктура — серверы, сеть, файрволы. Ansible для автоматизации — любой узел можно пересоздать за минуты.
4. Миграция — перенос с минимальным простоем. Компоненты подключаются последовательно, каждый шаг с проверкой.
5. Тестирование — имитация пиковых условий. Роняем master, отключаем веб-сервер, убиваем Redis — смотрим, как система себя ведёт.
6. Документация — схема архитектуры, runbook, планы аварийного восстановления.

Что входит в работу по кластеризации?

Сроки

Свяжитесь с нами — получите консультацию инженера и предварительную оценку проекта за 2 дня. Мы рассчитаем стоимость индивидуально под ваши задачи. Закажите аудит — узнайте точную архитектуру и бюджет.