Было время, когда по земле бродили динозавры; люди впервые начали работать с такими инструментами, как камни и балансировщики нагрузки 4-го уровня на основе DSR.
В то время эти инструменты были полезны тем, что с их помощью можно было связаться с серверами, а также тем, что с их помощью можно было легко убедиться в том, что серверу приложений представлен реальный IP-адрес клиента.
Балансировщик нагрузки находится между клиентом и приложением, поэтому, если смотреть со стороны приложения, кто является отправителем? Клиент (да, пожалуйста) или балансировщик нагрузки?
Это было довольно просто, и у Вас было несколько вариантов на выбор.
Режим DSR — Прямой возврат сервера.
- Клиент подключается к балансировщику нагрузки.
- Балансировщик нагрузки отправит его в Приложение с SourceIP Клиента.
- Затем приложение отправит ответ непосредственно клиенту. Вероятно, оно заметит, что SourceIP — это внешний IP, и направит ответ на шлюз, пропустив, таким образом, балансировщик нагрузки на Response.
Динозаврам понравился такой подход, поскольку он использовал меньше ресурсов инфраструктуры, а приложение получало реальный клиентский IP.
Недостатком является то, что Вам необходимо выполнить специальную сетевую настройку на сервере приложений… Балансировщик нагрузки не получает и не видит ответ, поэтому любые SSL или переключение контента не работают.
Другой недостаток заключается в том, что LB не имеет представления о том, насколько хорошо работает сервер приложений, поэтому сложнее сбалансировать нагрузку на серверы, которые, скорее всего, будут иметь более высокую производительность. ADC будет использовать наиболее быстро отвечающие или имеющие меньше всего соединений. (Человек каменного века может установить агента на App-сервер, который будет сообщать об этом.) Или ADC может использовать SNMP, чтобы получить эти данные.
Как бы то ни было, эта схема работала хорошо в течение многих лет, как лошадь и телега, и действительно, до сих пор есть ситуации, когда это лучший вариант, например, гонки на колесницах или некоторые старые протоколы.
Далее:
Режим шлюза
- Клиент подключается к балансировщику нагрузки
- Балансировщик нагрузки отправит его на App Server с SourceIP клиента.
- Затем приложение отправит ответ непосредственно клиенту, но через балансировщик нагрузки, поскольку Вы изменили шлюз по умолчанию сервера приложений на шлюз балансировщика нагрузки. Это означает, что балансировщик нагрузки получит ответ.
В некоторых отношениях это гораздо лучше, но ВЕСЬ внешний трафик с сервера App, например, обновления программного обеспечения, проходит через балансировщик нагрузки, поэтому он становится беспорядочным.
Это было более распространено, когда балансировщики нагрузки выглядели как коммутаторы, и все было напрямую подключено к высокоскоростным чашкам и струнным сетевым линиям.
Человек учится создавать фермы и использовать балансировку нагрузки на основе прокси-серверов
Примерно в это же время сети и скорость процессора становились все быстрее, и мы начали использовать подход Proxy.
Мы решили признаться в этом и начать использовать балансировщик нагрузки в качестве IP-адреса источника, а не обманывать сервер приложений. Мы сделали это по многим причинам, включая производительность TCP, безопасность и возможность предоставления дополнительных услуг на балансировщике нагрузки.
Но этот переход от охоты к собирательству был сопряжен с большими трудностями и проблемами.
Как Вы передаете IP клиента на сервер приложений?
К счастью, у старого доброго HTTP был отличный ответ, пока Вы использовали HTTP.
Заголовок X_Forwarded_For — позволяет Вам поместить IP клиента в заголовок и затем отправить его дальше.
Я не буду объяснять это слишком подробно, поскольку это довольно просто, но достаточно сказать, что это заголовок, который каждый может легко установить. Кроме того, он может быть сложным. Например, что произойдет, если балансировщику нагрузки уже отправлен IP-адрес X_Forwareded_For? Должен ли он использовать его или использовать исходный IP и изменить его? Все это обычно можно настроить на приличном LB, но все они имеют соображения безопасности и т.д.
Как бы то ни было, в 99% случаев, когда веб-приложению нужен исходный текст, они получают его именно таким образом (Примечание: 99% статистики выдуманы)
А как насчет других протоколов?
Некоторые из них имеют специфические для данного протокола хаки, но нет ничего общего, что было бы более широко распространено.
Так было до тех пор, пока не был предложен и широко принят протокол Proxy Protocol.
Протокол прокси объясняется
Протокол Proxy решает эту проблему, добавляя к перенаправленному запросу заголовок, содержащий данные о соединении оригинального клиента.
Уже существует две версии этого протокола.
- Протокол прокси v1: Использует простой, читаемый человеком текстовый формат.
- Протокол прокси v2: Использует двоичный формат, который более эффективен и может поддерживать дополнительные возможности, такие как IPv6 и адреса сокетов Unix.
Отличие заключается в том, что большинство серверов приложений сломаются, если Вы включите этот протокол, не настроив их на его прием. Это происходит потому, что Proxy Protocol буквально добавляет необходимые детали в начало данных.
Тем не менее, их распространение растет, и многие производители уже поддерживают эту технологию.
Он отлично подходит для DNS-проксирования, например.
Как и в случае с X_Forwardard_For, Вам еще предстоит принять некоторые решения:
Например, что Вы хотите, чтобы балансировщик нагрузки сделал, если Вам будет представлен заголовок Proxy Protocol? Удалить его и установить новый, или оставить его? Если Вы не ожидаете, что такой заголовок будет отправлен, Вам следует проигнорировать его и получить свой собственный, но эти решения должны быть обдуманными.
Протокол Proxy — это простой способ получить IP-адрес клиента, который сейчас широко поддерживается, так что пользуйтесь им и наслаждайтесь.
Я возвращаюсь к размышлениям о высокой доступности в облаке, Чао!
