Маршрутизация с учетом реплик

Направляйте связанные запросы на одну и ту же реплику ClickHouse Cloud для временных таблиц, сеансов и повторного использования кэша

Маршрутизация с учетом реплик (также известная как липкие сеансы, липкая маршрутизация или привязка сеанса) направляет связанные запросы в одну и ту же реплику ClickHouse. Используйте ее, если нужно, чтобы временные таблицы или именованное состояние сеанса оставались доступными между запросами, либо если вы хотите, чтобы связанные запросы повторно использовали локальные кэши одной и той же реплики.

Это механизм best effort, и он не гарантирует изоляции. Масштабирование, обновления и перезапуски могут изменить, на какую реплику попадет данный session_id.

Требуется HTTP-интерфейс

Маршрутизация с учетом реплик применяется на уровне прокси поверх HTTP/HTTPS-интерфейса с использованием параметра запроса session_id (см. ниже). Она недоступна через собственный протокол (порт native-протокола, например драйвер clickhouse-go в стандартном режиме native). Клиенты, использующие собственный протокол, должны переключиться на HTTP и передавать session_id в каждом запросе. Для clickhouse-go (v2) установите Protocol: clickhouse.HTTP и передавайте session_id как настройку. Драйвер отправляет его как параметр запроса URL, который хеширует прокси.

Предварительные требования

• Вашему сервису требуется 2 или более реплики. В сервисе с одной репликой привязывать попросту не к чему.
• Сервис должен быть запущен. Вывод неактивного сервиса из спящего режима может изменить, какой реплике соответствует session_id.
• По умолчанию доступно на уровне Enterprise после выхода возможности в GA.
• Поддерживается в стандартных сервисах ClickHouse Cloud. BYOC пока не поддерживается.

Настройка маршрутизации с учетом реплик

Откройте тикет в службу поддержки и попросите включить HTTP-маршрутизацию запросов к репликам с закреплением сеанса. Укажите ID вашего сервиса и причину, по которой она вам нужна (временные таблицы, состояние сеанса или повторное использование кэша). После включения начните передавать ?session_id= в HTTPS-запросах. Перезапуск не требуется.

Маршрутизация на основе HTTP (session_id)

Чтобы закрепить рабочую нагрузку за репликой, задайте параметр запроса session_id в интерфейсе HTTPS. Прокси использует согласованное хеширование по этому значению для выбора реплики, поэтому все запросы с одинаковым session_id направляются на один и тот же сервер, пока не изменится топология кластера.

Используйте существующее имя хоста сервиса. Никаких специальных sticky-хостов или изменений DNS не требуется.

echo 'SELECT hostName()' | curl \
  -H 'X-ClickHouse-User: default' \
  -H 'X-ClickHouse-Key: <password>' \
  'https://<host>:8443/?session_id=my-workload-1' -d @-

Каждый запрос с session_id=my-workload-1 попадает на одну и ту же реплику. Другое значение session_id хэшируется независимо и может попасть на ту же или на другую реплику. Соответствие остаётся постоянным, но выбрать, на какую именно реплику попадёт конкретное значение, нельзя.

session_id — это любая строка на ваш выбор (имя приложения, идентификатор пользователя или метка рабочей нагрузки). Запросы без session_id сохраняют обычную балансировку нагрузки.

Подойдёт любой HTTP-клиент, который умеет добавлять параметр запроса, включая curl, clickhouse-connect, JDBC/ODBC и другие. Для clickhouse-go (v2) используйте режим HTTP, как указано выше.

Проверьте, на какую реплику вы попали

Снова выполните приведённый выше пример SELECT hostName() с тем же session_id. Вы должны получить то же имя хоста. Другой session_id может направить вас на другую реплику.

Маршрутизация на основе поддоменов (устарело)

Устарело

Описанный ниже механизм на основе поддоменов устарел и больше не включается для новых сервисов. Он не масштабируется (для каждой sticky-конечной точки требуется собственный TLS-сертификат). Вместо него используйте HTTP-метод session_id. Если вы уже используете sticky-поддомены, обратитесь в поддержку, чтобы включить маршрутизацию session_id. Это обратно несовместимое изменение, и потребуется миграция.

Ранее включение маршрутизации с учётом реплик позволяло использовать подстановочный поддомен для имени хоста сервиса. Для сервиса с именем хоста abcxyz123.us-west-2.aws.clickhouse.cloud любое имя хоста, соответствующее шаблону *.sticky.abcxyz123.us-west-2.aws.clickhouse.cloud (например, aaa.sticky.abcxyz123.us-west-2.aws.clickhouse.cloud), Envoy по хешу направлял на одну и ту же реплику. Исходное имя хоста по-прежнему использовало балансировку нагрузки LEAST_CONNECTION — алгоритм маршрутизации по умолчанию.

Ограничения маршрутизации с учетом реплик

Привязка может нарушиться при изменениях сервиса

Любые изменения в работе сервиса меняют кольцо хеширования маршрутизации. К ним относятся перезапуски серверных подов (обновление версии, сбой, вертикальное масштабирование), а также масштабирование наружу или внутрь. В результате запросы с одинаковым session_id могут попасть на другой серверный под. Если вы используете временные таблицы или настройки на уровне сеанса, будьте готовы создать их заново после переназначения.

Маршрутизация с учетом реплик не является изоляцией рабочих нагрузок

Липкая маршрутизация определяет только то, какая реплика обрабатывает запрос. Эта реплика по-прежнему может обслуживать и другой трафик. Для выделенных вычислительных ресурсов используйте compute-compute separation.

Private Link и устаревший метод с поддоменом

Маршрутизация HTTP по session_id работает с частным сетевым подключением на стандартном хосте вашего сервиса. Дополнительные записи DNS не требуются.

Устаревший метод с поддоменом так не работает: нужно добавить DNS для шаблона хоста *.sticky.*, а неправильная настройка может привести к неравномерному распределению нагрузки между репликами.

Для маршрутизации с учетом реплик требуется HTTP-протокол

Липкая маршрутизация использует параметр запроса session_id, который существует только в HTTP/HTTPS-интерфейсе. Собственный бинарный протокол не передает такой параметр, по которому прокси мог бы вычислить хеш, поэтому маршрутизация с учетом реплик недоступна через собственный протокол. На сегодняшний день, чтобы использовать эту возможность, клиентам собственного протокола необходимо перенести соответствующую рабочую нагрузку на HTTP-интерфейс.

Устранение неполадок

Запросы по-прежнему попадают на разные реплики при одном и том же session_id

• Убедитесь, что session_id — это query parameter в URL (?session_id=...), а не HTTP-заголовок.
• После включения немного подождите. Изменения могут вступить в силу меньше чем за минуту.
• Проверьте, не масштабировался и не перезапускался ли сервис недавно; после изменений топологии перепривязка ожидаема. Используйте SELECT hostName(), чтобы определить новую привязку.