Перейти к содержимому
BXWiki

Веб-кластер 1С-Битрикс - репликация, memcached, сессии

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

Как это работает

Что даёт модуль. Распределение одного сайта на несколько серверов, вертикальный шардинг, репликацию базы с балансировкой, распределённый кеш memcached, хранение сессий в базе и кластеризацию веб-сервера. Доступен в старших редакциях; полноценная репликация master-master - в «Энтерпрайз».

Репликация master-slave. Запись идёт в master, чтение - со slave. Начиная с версии главного модуля 24.0.0 на slave может уходить вся нагрузка чтения: платформа отслеживает изменённые таблицы и, если они не менялись, продолжает читать со slave. После записи последующие чтения в том же процессе идут с master, потому что у репликации есть задержка.

Проектирование идёт от вида нагрузки. Упирается процессор - добавляют веб-ноды за балансировщиком, локальный memcached на каждой и синхронизацию контента. Упирается база - настраивают master-slave. Интенсивно используется кеш - memcached на каждой ноде.

Типовые архитектуры три: полные ноды (минимум две, базовая отказоустойчивость), раздельные ноды (минимум четыре, веб и база отдельно, гибкое масштабирование) и гео-кластер для максимальной отказоустойчивости.

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

Шардинг подробно разобран в статье о базе данных. Веб-кластер поддерживает только вертикальный шардинг базы - вынос таблиц веб-аналитики и поиска на отдельный сервер, без горизонтального распределения данных.

Примеры

1. Локальные изменения без срыва балансировки

// D7
$connection = \Bitrix\Main\Application::getConnection();
$connection->useMasterOnly(true);


// операции записи


$connection->useMasterOnly(false);
// легаси
$DB->StartUsingMasterOnly();
// операции записи
$DB->StopUsingMasterOnly();

Смысл в следующем: любой запрос на изменение переключает текущий хит на master и фактически выключает балансировку до конца запроса. Явное обёртывание локальных изменений помогает этого избежать. Но помните: сразу после записи читать со slave нельзя - он может быть ещё не синхронизирован.

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

2. Настройка memcached

memcache.hash_strategy = consistent

Параметр по умолчанию выключен, а без него отказ одного сервера memcached перетасовывает все ключи между оставшимися - кеш массово промахивается, и вся нагрузка мгновенно уходит в базу. Согласованное хеширование этого не допускает.

Память наращивают шагами по 32 мегабайта, начиная со 128, и следят за долей попаданий - она должна стремиться к сотне процентов.

3. Подключение к базе

В файле настроек на всех серверах указывают прямой адрес master-базы, а не локальный хост. Между серверами нужен быстрый канал.

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

Справочник

ЭлементНазначениеОсобенности
Модуль «Веб-кластер»распределение сайта на несколько серверовдоступен в старших редакциях
master-slave репликациязапись в master, чтение со slaveпосле записи чтение идёт с master
Порог отставания slaveзащита от рассинхронизациипри превышении slave отключается
useMasterOnly()явное указание писать в masterлегаси-аналог - методы старого ядра
memcached на нодахраспределённый кешобязательно согласованное хеширование
Сессии в базецентрализованное хранениеснижает скорость генерации на несколько процентов
ip_hash на балансировщикепривязка клиента к нодеальтернатива централизованным сессиям
auto_increment_increment / offsetразнесение генерации идентификаторовобязательно для master-master

Частые ошибки

Сессии остались в файлах. Авторизация на одной ноде теряется на другой. Централизуйте хранение или привязывайте клиента к ноде.

Забыли согласованное хеширование memcached. Отказ одного сервера кеша приводит к массовому промаху и лавинообразной нагрузке на базу.

Срыв балансировки на каждом хите. Изменяющий запрос в начале запроса переключает всё чтение на master. Ищите служебные файлы с изменяющими запросами и оборачивайте локальные изменения явно.

Slave добавили к большой базе без подготовки. Проект встаёт. Правильный порядок - предварительный дамп, ручное добавление в репликацию и только потом регистрация узла.

Сессии в базе на одиночном сервере. Это лишняя нагрузка: централизация нужна кластеру, а на одном сервере сессии держат в памяти.

Master-master без разнесения идентификаторов. Два узла начнут выдавать одинаковые значения автоинкремента. Настраивают шаг и смещение: один узел выдаёт чётные, другой нечётные.

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

Частые вопросы

Когда пора собирать кластер?

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

Где хранить сессии при нескольких веб-серверах?

Не в файловой системе - иначе запросы одного пользователя попадут на разные ноды и авторизация потеряется. Варианты: централизованное хранение в базе (просто, но добавляет нагрузку и немного замедляет генерацию), хранение в памяти через memcached или Redis (быстрее) либо привязка клиента к ноде на балансировщике. На одиночном сервере переносить сессии в базу не нужно.

Что такое срыв балансировки и как его избежать?

Любой изменяющий запрос переключает текущий хит на master, и до конца обработки чтение идёт мимо slave. Если такой запрос выполняется в начале каждого хита - например, из служебного файла подключения, - балансировка не работает вообще. Локальные изменения оборачивают явным указанием писать в master, а после записи не читают данные сразу: репликация имеет задержку.

Связанные темы

Первоисточники