Назад | Перейти на главную страницу

Балансировка нагрузки без балансировщика нагрузки?

У меня есть 4 сервера изображений на базе nginx на их собственных поддоменах, к которым пользователи будут обращаться произвольно. Я решил разместить их всех за балансировщиком нагрузки HAProxy, чтобы повысить надежность и просмотреть статистику трафика из одного места. Это казалось легкой задачей.

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

Мне было интересно, что с этим делать - я мог бы обновить порт ($$) или вернуться к 4 отдельным серверам изображений, к которым осуществляется случайный доступ. Я подумал о том, чтобы разместить HAProxy на каждом сервере изображений, который, в свою очередь, направит на другой сервер изображений, если у службы nginx этого сервера возникнут проблемы.

Что бы вы сделали? Я бы не хотел тратить слишком много дополнительных денег.

Все, что сломает ваш nginx (перегрузка, аппаратный дефект), вероятно, также сломает ваш haproxy. Вероятно, лучше всего было бы получить дополнительный IP-адрес (использовать в качестве псевдонима в интерфейсе) для каждого сервера и использовать его в качестве IP-адреса (напрямую или через DNS-имя), который вы публикуете через URL-адреса ваших изображений. Создайте сценарий, который переместит вторичный ip на другой сервер в случае серьезных проблем. Дьявол в деталях будет в том, чтобы убедиться, что IP находится в безопасности. забрал с другого сервера. В случае, если скрипт больше не может войти на отказавший сервер и освободить псевдоним IP, лучше всего полностью выключить его через IPMI, если он доступен.

В качестве альтернативы вы можете установить на четвертый сервер что-то CGIish, которое просто перенаправляет на случайный выбор доступных серверов; контролировать список серверов, на которые он может выполнять перенаправление, с помощью сценария периодического мониторинга (например, для этого вы можете неправильно использовать nagios check_http). В качестве расширения этот сценарий также может принимать список исключений из другого файла - это очень удобно, если вам нужно приостановить один из серверов для обслуживания.

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

Решение 1. Активный мониторинг DNS / реклама

Настройте images.domain.com с низким TTL (30 секунд) для рекламы ваших 4 IP:
10.1.1.1, 10.1.1.2, 10.1.1.3, 10.1.1.4

Затем вашим серверам имен необходимо активно опрашивать http-статус каждого IP-адреса (как вы бы отслеживали с помощью балансировщика нагрузки) и прекращать рекламировать IP-адрес, когда он находится в состоянии «не работает». Сделайте это тщательным тестом, но избегайте использования каких-либо сервисов, общих для всех ящиков. (например, бэкэнд с одним БД). Когда узел выходит из строя, он перестает анонсироваться в DNS.

Уловы, больше DNS-запросов из-за низкого TTL. Отработка отказа занимает «DNS TTL» секунд (и некоторые люди также не хотят подчиняться TTL). Ваши серверы имен должны быть относительно близко к службам или иметь разумные настройки по умолчанию, например, если произошел сбой сети между NS и вашими серверами изображений.

Вы также можете сделать 4 отдельных доменных имени, которые возвращаются к другому IP-адресу с помощью того же метода.

Решение 2. Переключение IP при отказе

Захват IP-адреса rakandboneman реализован без особых проблем в Linux с keepalived / lvs с использованием протокола VRRP. (Предполагая, что ваши ящики расположены близко друг к другу в сети и Linux, ОС вроде bsd и солярис есть реализации vrrp / carp)

С 4 блоками вы можете создать круговую топологию для аварийного переключения Virutal IP, что означает, что вы можете потерять 2 бокса рядом друг с другом, но потерять только 1 VIP, поле слева от [] имеет наивысший приоритет для VIP.

         vip 1        vip 2        vip3         vip4
nodes [ 1 <-> 2 ]  [ 2 <-> 3 ]  [ 3 <-> 4 ]  [ 4 <-> 1 ]

или 3 узла на VIP, в порядке приоритета, более сложная настройка, но лучшая доступность.

nodes [1 - 2 - 3]  [2 - 3 - 4]  [3 - 4 - 1 ] [ 4 - 1 - 2]

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