Можно ли использовать несколько балансировщиков нагрузки для перенаправления трафика на мои серверы приложений?

Я новичок в балансировке нагрузки и мне интересно, можно ли использовать несколько балансировщиков нагрузки для перенаправления трафика на мои серверы приложений. Я не очень понимаю, как это можно сделать. Разве доменное имя не должно совпадать один к одному с IP-адресом определенного сервера (в этом случае IP-адрес одного балансировщика нагрузки)? Если каждый сервер балансировки нагрузки имеет разные IP-адреса, как запрос может быть получен обоими балансировщиками нагрузки (или 10 балансировщиками нагрузки, или 50, или 100)?

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

Есть и другие способы добиться этого.
1) Активные / пассивные балансировщики нагрузки.
В основном один балансировщик нагрузки обрабатывает весь трафик для одного IP-адреса.
Если этот балансировщик выходит из строя, пассивный узел подключается и принимает IP.
Имейте в виду, что балансировщики нагрузки в значительной степени только перенаправляют трафик, поэтому для небольших и средних сайтов это может сработать.

2) Активные / активные балансировщики нагрузки.
Один и тот же IP трафика настроен на обоих (или многих других) балансировщиках нагрузки.
Входящий трафик отправляется всем балансировщикам нагрузки, но алгоритм выбирает, какой балансировщик должен отвечать, все остальные отбрасывают этот трафик.
Проще говоря, у вас есть два балансировщика нагрузки:
когда запрашивающий IP заканчивается четным числом, тогда отвечает балансировщик нагрузки A, в противном случае отвечает балансировщик нагрузки B.

Конечно, ваша инфраструктура должна поддерживать это, и есть издержки из-за того, что трафик отправляется, но отбрасывается.
Более подробная информация, например, здесь: http://community.brocade.com/t5/SteelApp-Docs/Feature-Brief-Deep-dive-on-Multi-Hosted-IP-addresses-in-Stingray/ta-p/73867

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

Существует множество таких протоколов, из которых я чаще всего видел с обычными балансировщиками нагрузки: VRRP и NLB (а также довольно много неописанных протоколов в устройствах черного цвета). При расширении до маршрутизаторов и межсетевых экранов можно также встретить , например , CARP , HRSP , GLSP .

Эта стратегия имеет ряд преимуществ по сравнению с балансировкой нагрузки на DNS, которая является более простой стратегией (о которой идет речь в другом ответе).

Балансировка нагрузки на DNS обременена, например, следующим:

• медленный оборот механизмов кеширования днс
• ограниченные алгоритмы балансировки нагрузки (обычно только циклический перебор)
• аутсорсинг решения балансировки нагрузки клиенту (через кэширование записи днс)
• Медленная утечка сервисных очередей, когда сервер (т. Е. Балансировщик нагрузки) выводится из ротации (на основе TTL-записей DNS, которые обрабатываются интернет-провайдерами и клиентами )
• Медленное переключение при сбое балансировки нагрузки

Используя виртуальный протокол IP для HA, можно выбрать, например:

• Выбор алгоритма балансировки нагрузки среди балансировщиков нагрузки
• Решения по балансировке нагрузки, ориентированной на сервер (например, способствующий измерению работоспособности сервиса и маршрутизации)
• Более быстрый расход сервисных очередей, когда балансировщик нагрузки выведен из ротации.
• Мгновенное переключение при сбое балансировки нагрузки

Только вы знаете, какая стратегия и протокол лучше всего соответствуют вашему сценарию.

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

Номер запроса дохода приложения неизвестен, но он должен быть достаточно высоким, чтобы соответствовать ожиданиям увеличения нагрузки без страха.

Давайте найдем приложение с похожим характером загрузки, например, магазин журналов и приложение поиска. Я нашел один .

Что они хотят:

1. Балансировать нагрузку на коллекторы
2. Обеспечивает отказоустойчивость, позволяя нам продолжать прием данных, если один из сборщиков умирает или испытывает проблемы
3. Горизонтальное масштабирование с ростом наших объемов журналов

Что они попробовали и узнали об ELB:

1. Не работает, как ожидалось
2. Проблемы с задержкой из-за увеличения нагрузки
3. Недостаточно средств мониторинга
4. Слишком много ограничений (количество открытых портов и протоколов)

Почему они выбрали с Route53:

1. «Round Robin - довольно простая балансировка нагрузки, но она хорошо работает для нас с точки зрения эффективности»
2. «Мы используем проверку работоспособности при отказе Route 53».
3. «Если возникает проблема с коллектором, Route 53 автоматически выводит его из эксплуатации; наши клиенты не увидят никакого влияния».
4. Предварительный прогрев с маршрутом 53 не требуется

Маршрут 53 оказался лучшим способом для Loggly воспользоваться нашими высокопроизводительными сборщиками, учитывая наши огромные объемы журналов, непредсказуемые изменения и постоянный рост нашего бизнеса. Это согласуется с основными целями сборщиков: сбор данных на скорости линии сети с нулевыми потерями, и это позволяет нам воспользоваться гибкостью всех сервисов AWS, которые мы используем в Loggly.

Этот конкретный пример показывает, что в некоторых сценариях (сборщик журналов, служба рекламы и т. П.) Балансировщик нагрузки избыточен, и «круговое решение проверки работоспособности DNS» отлично справляется со своей задачей.

Давайте посмотрим, что в AWS говорят об отказоустойчивости DNS:

С помощью DNS Failover Route 53 может обнаружить сбой вашего сайта и перенаправить ваших конечных пользователей в альтернативные или резервные местоположения, которые вы укажете. Маршрут 53 DNS Failover использует проверки работоспособности - регулярно отправляет интернет-запросы к конечным точкам ваших приложений из разных мест по всему миру - чтобы определить, работает ли каждая конечная точка вашего приложения или нет.

Этот метод также делает ELB (не требуется, просто для заметки) более устойчивым, опять же, он основан на RR + Health Check:

Маршрут 53 DNS Failover обрабатывает все эти сценарии сбоя путем интеграции с ELB за кулисами. После включения Route 53 автоматически конфигурирует и управляет проверками работоспособности для отдельных узлов ELB.

Давайте теперь посмотрим, как это работает за кулисами. Очевидный вопрос - как бороться с кешированием DNS:

Тем не менее, DNS-кэширование все еще может быть проблемой здесь (см. Наш предыдущий пост, где рассматривается проблема «длинного хвоста»), если TTL не соблюдается всеми слоями между вашим клиентом и Route 53. Затем вы можете применить технику «очистки кэша»: отправить запрос на уникальный домен

("http://<unique-id>.<your-domain>") 

и определить подстановочный ресурс

Record "*.<your-domain>" to match it.

Algolia представила «стратегию повторных попыток клиента», которая работает очень хорошо, если ваш клиент (JS в вашем случае) может справиться с этим:

В итоге мы внедрили базовую стратегию повторов в наших клиентах API. Каждый клиент API был разработан для доступа к трем различным машинам. Три разные записи DNS представляли каждого пользователя: USERIDID-1.algolia.io, USERID-2.algolia.io и USERID-3.algolia.io. Наша первая реализация состояла в том, чтобы случайным образом выбрать одну из записей, а затем повторить попытку с другой в случае сбоя.