logo

Рекомендации по балансировке

Назначение и ограничения

Балансировщик распределяет клиентские запросы к S3 API и Admin UI/Management API между узлами Закрома.Хранение. Все доступные экземпляры Закрома.Хранение принимают клиентский трафик, поэтому балансировщик должен проверять их доступность и исключать недоступные узлы из распределения запросов.

В статье не рассматривается механизмы межузлового трафика ZDS, PostgreSQL и Kafka, где балансировка выполняется средствами самого ПО, либо сторонними средствами. Для CDN в мультикластерной конфигурации поставки 7.2.3 используется отдельная схема с Nginx, описанная в статье Настройка Nginx.

Компоненты инфраструктуры

HAProxy, Keepalived и другие внешние балансировщики не входят в состав продукта. Их установка, настройка и сопровождение выполняются средствами инфраструктуры предприятия.

Выбор схемы балансировки

СхемаГде применятьОсобенности
Один HAProxyТестовые и простые среды, в которых допустим перерыв при отказе балансировщикаПростая настройка, но балансировщик остаётся единой точкой отказа
HAProxy и Keepalived с одним VIP-адресомБазовая отказоустойчивая конфигурация в пределах одного L2-сегментаПри отказе активного узла VIP-адрес переходит на резервный
Несколько VIP-адресов и DNS RRПродуктивные среды, где требуется распределить входящие подключения между несколькими отказоустойчивыми группами балансировщиковОдин FQDN разрешается в несколько VIP-адресов; каждый VIP-адрес должен иметь собственный механизм переключения
Внешний Application Delivery Controller (ADC), облачный балансировщик, GSLB или балансировщик платформы контейнеризацииСреды с принятыми корпоративными платформами балансировки или несколькими площадкамиВозможности и отказоустойчивость определяются выбранным решением

Один HAProxy

Один HAProxy можно использовать для функциональных испытаний и некритичных сред. Он предоставляет единые точки входа для S3 API и Admin UI/API, но при его отказе оба сервиса становятся недоступны через балансировщик.

image

HAProxy и Keepalived с одним VIP-адресом

Для отказоустойчивой точки входа используйте минимум два узла с HAProxy и Keepalived. HAProxy должен быть запущен на каждом узле, а клиентские DNS-имена должны указывать на общий VIP-адрес.

Для каждого VRRP-инстанса настройте:

  • одинаковый VIP-адрес на участвующих узлах;
  • разные приоритеты основного и резервного узлов;
  • локальную проверку состояния сервиса HAProxy;
  • освобождение VIP-адреса при отказе HAProxy;
  • уникальный VRID в пределах L2-сегмента.

Keepalived проверяет состояние локального HAProxy и переносит VIP-адрес между узлами. HAProxy отдельно проверяет доступность узлов Закрома.Хранение и исключает недоступные backend-серверы. Если multicast VRRP запрещён политиками сети, используйте unicast VRRP в соответствии с требованиями сетевой инфраструктуры.

image

Базовая конфигурация HAProxy

Следующий пример создаёт отдельные точки входа и пулы backend-серверов для S3 API и Admin UI/Management API. TCP-проверки подходят как базовый вариант независимо от того, используется ли HTTP или TLS на узлах Закрома.Хранение.

TCP-проверка подтверждает только доступность сетевого порта. Если выбранный балансировщик поддерживает проверку готовности приложения, используйте согласованный L7 health-check для установленной версии Закрома.Хранение.

Замените значения в угловых скобках. Порты <S3_API_PORT> и <MANAGEMENT_PORT> должны соответствовать параметрам zakroma_storage_gateway.s3api_port и zakroma_storage_gateway.management_port в конфигурации конкретной инсталляции.

1global
2    log /dev/log local0
3    log /dev/log local1 notice
4    maxconn 10000
5
6defaults
7    log global
8    mode tcp
9    option tcplog
10    timeout connect 5s
11    timeout client 1h
12    timeout server 1h
13
14frontend zakroma_s3
15    bind <BALANCER_IP>:<S3_PUBLIC_PORT>
16    default_backend zakroma_s3_nodes
17
18backend zakroma_s3_nodes
19    balance roundrobin
20    option tcp-check
21    server storage-1 <STORAGE_NODE_1_IP>:<S3_API_PORT> check inter 2s fall 3 rise 2
22    server storage-2 <STORAGE_NODE_2_IP>:<S3_API_PORT> check inter 2s fall 3 rise 2
23    server storage-3 <STORAGE_NODE_3_IP>:<S3_API_PORT> check inter 2s fall 3 rise 2
24
25frontend zakroma_admin
26    bind <BALANCER_IP>:<ADMIN_PUBLIC_PORT>
27    default_backend zakroma_admin_nodes
28
29backend zakroma_admin_nodes
30    balance roundrobin
31    option tcp-check
32    server storage-1 <STORAGE_NODE_1_IP>:<MANAGEMENT_PORT> check inter 2s fall 3 rise 2
33    server storage-2 <STORAGE_NODE_2_IP>:<MANAGEMENT_PORT> check inter 2s fall 3 rise 2
34    server storage-3 <STORAGE_NODE_3_IP>:<MANAGEMENT_PORT> check inter 2s fall 3 rise 2

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

Проверка доступности через /healthz

Закрома.Хранение и сервис gateway предоставляет специальный эндпоинт для проверки состояния - GET /healthz на отдельном management-порту, который указывается переменной zakroma_storage_gateway.management_port. Протокол доступа(HTTP или HTTPS) зависит от параметра zakroma_storage_gateway.tls.enabled: при false используется HTTP, при true — HTTPS.

Ответ с кодом 200 и телом {} означает, что HTTP-сервер gateway работает и принимает запросы.

Проверка состояния сервиса, используя TCP, также может применяться при балансировке. Если политика предприятия требует L7 health-check, используйте эндпоинт /healthz как отдельный вариант проверки. Следующий фрагмент показывает проверку работопособности S3-бекенда через <MANAGEMENT_PORT>: клиентский трафик при этом продолжает поступать на <S3_API_PORT>.

1backend zakroma_s3_nodes
2    mode tcp
3    balance roundrobin
4    option httpchk GET /healthz
5    http-check expect status 200
6    server storage-1 <STORAGE_NODE_1_IP>:<S3_API_PORT> check port <MANAGEMENT_PORT> inter 2s fall 3 rise 2
7    server storage-2 <STORAGE_NODE_2_IP>:<S3_API_PORT> check port <MANAGEMENT_PORT> inter 2s fall 3 rise 2
8    server storage-3 <STORAGE_NODE_3_IP>:<S3_API_PORT> check port <MANAGEMENT_PORT> inter 2s fall 3 rise 2

Если TLS включён на узлах Закрома.Хранение, health-check должен подключаться к management_port по HTTPS, передавать SNI и проверять сертификат через доверенный центр сертификации. Для каждой строки server можно добавить параметры:

1check port <MANAGEMENT_PORT> check-ssl check-sni <ADMIN_UI_FQDN> verify required ca-file <CA_CERT_PATH> verifyhost <ADMIN_UI_FQDN>

Можно применить аналогичный метод проверки доступности Admin UI, если он настраивается отдельно. Этот пример является рекомендацией и не заменяет базовые конфигурации HAProxy из предыдущего раздела.

TLS-терминация

TLS можно терминировать на балансировщике или передавать до узлов Закрома.Хранение без шифрования.

ВариантРазмещение сертификатовМаршрутизацияОсобенности
TLS-терминация на балансировщикеНа каждом узле балансировщикаПо HTTP Host и другим параметрам HTTP-запросаУпрощает централизованное управление сертификатами; до backend-серверов можно использовать HTTP или повторное TLS-шифрование
TLS passthroughНа каждом узле Закрома.ХранениеПо SNI в ClientHello или по отдельным IP-адресам и портамБалансировщик не расшифровывает трафик и не может анализировать HTTP-запрос

Настройка публичного URL Admin UI

Если Admin UI необходимо сделать доступным через внешний балансировщик по TLS, укажите в zakroma_storage_admin.path его внешний FQDN и включите формирование URL через reverse proxy. Параметр port должен содержать внешний порт балансировщика, а не внутренний zakroma_storage_gateway.management_port.

Для роли zakroma-storage версии 10.0.5 и новее используйте:

1zakroma_storage_admin:
2  # Внешний FQDN Admin UI без схемы и порта.
3  path: "zakroma-admin.zakroma.internal"
4  reverse_proxy:
5    enabled: true
6    # Внешний порт балансировщика.
7    port: 443

При enabled: true роль формирует для Admin UI параметр basepath вида https://<path>:<port>. Если оставить enabled: false, URL формируется с внутренним портом zakroma_storage_gateway.management_port и может не соответствовать адресу, доступному клиентам через балансировщик.

Настройка необходима как при TLS-терминации на балансировщике, так и при TLS passthrough с SNI, если внешний порт отличается от внутреннего порта Admin UI. При TLS-терминации без маршрутизации по SNI укажите в path и port публичный адрес Admin UI на внешнем балансировщике. В режиме TLS passthrough без SNI опубликуйте Admin UI через отдельный IP-адрес или порт и укажите эти внешние значения.

Совместимость с поставкой 7.2.3

В поставке 7.2.4 переменная zakroma_storage_admin.reverse_proxy заменит блок zakroma_storage_nginx_proxy. Для текущей версии задайте внешний FQDN в zakroma_storage_admin.path и включите совместимый параметр:

1zakroma_storage_admin:
2  path: "zakroma-admin.zakroma.internal"
3
4zakroma_storage_nginx_proxy: true

image

TLS-терминация на балансировщике

При TLS-терминации сертификат и закрытый ключ размещаются на каждом узле балансировщика. HAProxy принимает HTTPS-запросы, определяет Admin UI по HTTP Host и направляет остальные запросы в backend S3 API.

Следующий пример предполагает HTTP-соединения между HAProxy и узлами Закрома.Хранение. Параметр crt должен указывать на PEM-файл, содержащий сертификат, цепочку сертификатов и закрытый ключ.

1global
2    log /dev/log local0
3    log /dev/log local1 notice
4    maxconn 10000
5
6defaults
7    log global
8    timeout connect 5s
9    timeout client 1h
10    timeout server 1h
11
12frontend zakroma_https
13    bind <BALANCER_IP>:443 ssl crt <PEM_CERTIFICATE_PATH>
14    mode http
15    option httplog
16
17    acl is_zakroma_admin hdr(host) -i <ADMIN_UI_FQDN>
18    use_backend zakroma_admin_http if is_zakroma_admin
19    default_backend zakroma_s3_http
20
21backend zakroma_s3_http
22    mode http
23    balance roundrobin
24    server storage-1 <STORAGE_NODE_1_IP>:<S3_API_PORT> check
25    server storage-2 <STORAGE_NODE_2_IP>:<S3_API_PORT> check
26    server storage-3 <STORAGE_NODE_3_IP>:<S3_API_PORT> check
27
28backend zakroma_admin_http
29    mode http
30    balance roundrobin
31    server storage-1 <STORAGE_NODE_1_IP>:<MANAGEMENT_PORT> check
32    server storage-2 <STORAGE_NODE_2_IP>:<MANAGEMENT_PORT> check
33    server storage-3 <STORAGE_NODE_3_IP>:<MANAGEMENT_PORT> check

Не изменяйте заголовок Host, URI и query-параметры клиентского запроса: они используются для адресации S3 и проверки подписи запроса. Если между балансировщиком и узлами требуется TLS, настройте повторное шифрование и обязательную проверку сертификатов backend-серверов доверенным центром сертификации.

TLS passthrough и SNI

В режиме TLS passthrough HAProxy работает на уровне TCP. Значение SNI из TLS ClientHello позволяет направить запросы Admin UI в отдельный backend без расшифровки трафика. Остальные TLS-запросы направляются в S3 API.

1global
2    log /dev/log local0
3    log /dev/log local1 notice
4    maxconn 10000
5
6defaults
7    log global
8    mode tcp
9    option tcplog
10    timeout connect 5s
11    timeout client 1h
12    timeout server 1h
13
14frontend zakroma_tls
15    bind <BALANCER_IP>:443
16    mode tcp
17    option tcplog
18    tcp-request inspect-delay 5s
19    tcp-request content accept if { req.ssl_hello_type 1 }
20
21    acl is_zakroma_admin req.ssl_sni -i <ADMIN_UI_FQDN>
22    use_backend zakroma_admin_tls if is_zakroma_admin
23    default_backend zakroma_s3_tls
24
25backend zakroma_s3_tls
26    mode tcp
27    balance roundrobin
28    option tcp-check
29    server storage-1 <STORAGE_NODE_1_IP>:<S3_API_PORT> check
30    server storage-2 <STORAGE_NODE_2_IP>:<S3_API_PORT> check
31    server storage-3 <STORAGE_NODE_3_IP>:<S3_API_PORT> check
32
33backend zakroma_admin_tls
34    mode tcp
35    balance roundrobin
36    option tcp-check
37    server storage-1 <STORAGE_NODE_1_IP>:<MANAGEMENT_PORT> check
38    server storage-2 <STORAGE_NODE_2_IP>:<MANAGEMENT_PORT> check
39    server storage-3 <STORAGE_NODE_3_IP>:<MANAGEMENT_PORT> check

Маршрутизация по SNI доступна только для TLS-соединений, в которых клиент передаёт имя сервера. Для клиентов без SNI требуется отдельный IP-адрес или порт. При TLS passthrough HAProxy не проверяет сертификат, который узел Закрома.Хранение возвращает клиенту. Необходимые DNS-имена должны присутствовать в сертификате каждого backend-узла.

DNS Round-Robin

DNS Round-Robin (DNS RR) возвращает несколько IP-адресов для одного DNS-имени. Такой подход распределяет новые клиентские соединения без отдельного устройства балансировки, но сам по себе не проверяет доступность адресов и не гарантирует немедленное переключение клиента.

Прямые DNS-записи на узлы

Прямые A-записи на узлы Закрома.Хранение допустимы для тестовых и некритичных сред. При отказе узла его адрес может оставаться в DNS-ответах и клиентском кэше до истечения TTL. Кроме того, порядок и способ выбора адреса зависят от DNS-резолвера и клиента.

Все узлы, указанные в DNS, должны принимать запросы к одному FQDN и предоставлять подходящий TLS-сертификат. Для продуктивной среды используйте DNS-сервис с проверкой доступности или сочетайте DNS RR с отказоустойчивыми VIP-адресами.

DNS RR и несколько VIP-адресов

В отказоустойчивой схеме один FQDN разрешается в два или более VIP-адреса. Каждый VIP-адрес обслуживается независимой группой HAProxy и защищён Keepalived. Группы балансировщиков используют одинаковые FQDN, сертификаты и пулы backend-серверов.

Распределите основное владение VIP-адресами между разными узлами или группами, чтобы задействовать ресурсы нескольких балансировщиков. Низкий TTL сокращает время хранения DNS-ответа в кэше, но не заменяет health-check и не гарантирует мгновенное переключение уже подключённых клиентов.

image

VRRP рассчитан на переключение адреса в пределах общей сетевой инфраструктуры. Не растягивайте VRRP между центрами обработки данных. Для выбора доступной площадки используйте GSLB или другой DNS-сервис с проверкой состояния endpoint.

Другие балансировщики и подходы

Внешние балансировщики

Допускается использовать внешние балансировщики в соответствии со стандартами вашего предприятия.

Выбранный балансировщик должен обеспечивать:

  • балансировку TCP или HTTP в соответствии с выбранным вариантом TLS-терминации;
  • L4- или L7-проверки доступности узлов Закрома.Хранение и исключение недоступных узлов;
  • TLS-терминацию или TLS passthrough, а при маршрутизации зашифрованного трафика — поддержку SNI;
  • сохранение заголовка Host, URI и query-параметров S3-запросов;
  • тайм-ауты, достаточные для длительных операций и передачи больших объектов;
  • корректную работу с multipart-загрузками;
  • отключение нежелательной буферизации запросов и ответов.

Для нескольких площадок рекомендуется GSLB с проверкой доступности. В контейнерной среде можно использовать балансировщик или ingress-контроллер платформы, если он выполняет перечисленные требования. Выбор производителя и конкретной реализации определяется стандартами предприятия.

Проверка балансировки

После настройки выполните следующие проверки.

  1. Убедитесь, что DNS-имена S3 API и Admin UI возвращают ожидаемые VIP-адреса:

    1dig +short <S3_FQDN>
2dig +short <ADMIN_UI_FQDN>

  2. Если используется TLS, проверьте сертификат и выбор имени по SNI:

    1openssl s_client -connect <VIP_ADDRESS>:443 -servername <S3_FQDN>
2openssl s_client -connect <VIP_ADDRESS>:443 -servername <ADMIN_UI_FQDN>

  3. Проверьте синтаксис конфигурации HAProxy на каждом узле балансировщика:

    1haproxy -c -f /etc/haproxy/haproxy.cfg

  4. В согласованное окно испытаний сделайте один backend-сервер недоступным и убедитесь, что HAProxy исключил его из распределения, а S3 API и Admin UI продолжают работать через оставшиеся узлы.

  5. Для схемы с Keepalived проверьте перенос VIP-адреса при остановке HAProxy или отказе активного узла, а затем — возврат узла в рабочее состояние. Клиентские DNS-имена должны продолжать разрешаться в тот же VIP-адрес.

  6. Через используемый S3-клиент выполните запись, чтение и удаление объекта, а также multipart-загрузку. Проверьте доступ к Admin UI и выполнение операций через Admin API, если он используется.

Смотрите также
Требования
Типовые варианты конфигурации
Отказоустойчивость
Подготовка окружения к установке
Настройка Nginx