[Ilya Evseev]

Дано:

• сервер с балансировщиком входящих HTTPS-запросов
• много серверов-воркеров

 

Хочется:

• после установки балансировщиком входящего HTTPS-соединения и получения заголовка HTTP-запроса полностью передавать установленное соединение на воркер
• после этого балансировщик полностью забывает про это соединение, а воркер общается с клиентом напрямую, минуя балансировщик

 

Примерно понятно, как реализовать такую схему для HTTP, но неясно, как отследить и передать на другой сервер состояние SSL-сессии прозрачно для клиента:

1. Собрать в балансировщике всю информацию о соединении
2. Отправить её в сериализованном виде на воркер
3. На воркере десериализовать её и создать рабочее соединение, завершить приём HTTP-запроса и ответить на него.

 

Кто-нибудь уже делал что-то похожее?
Ближайшее, что пока получилось найти - "SSL connection mirroring" в F5 BIG-IP.
Однако оно (a) проприетарное, (б) с ценой от самолёта и (в) failover-only, т.е. делает только HA без LB.

[Ivan_83]

Странная хотелка, мягко говоря.

 

Чтобы получить http тебе надо полностью заинитить tcp+tls.

Соответственно ты должен будешь переносить tcp+tls стейты. Ну и IP у тебя тоже попутно меняется.

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

Либо проксируй дальше по http до воркера.

[Ilya Evseev]

2 минуты назад, Ivan_83 сказал:

1) Ну и IP у тебя тоже попутно меняется.

2) Либо проксируй дальше по http до воркера.

1) Как сделать воркерам и балансеру одинаковый IP, понятно.

2) Мне не нужно проксирование через балансер, мне наоборот нужно, чтобы трафик ответа шёл к клиенту от воркера напрямую _мимо_ балансера. Иначе балансер ляжет. Для HTTP это сделать можно. Для HTTPS пока неясно как. Можно сделать быстрый ответ от балансера с фреймом, указывающим на конкретный воркер, но этот вариант оставлен на самый крайний случай, т.к. неприемлемо увеличивает TTFB.

[anix]

Мы отказалист от балансировщика сессий (IPVS) в пользу L3: запустили на каждом воркере OSPF+IP/32, "балансировщиком" сделали L3 коммутатор с OSPF+ECMP с hash L3+L4 (получилась схема похожая на bgp anycast). Клиентская сессия попадает сразу на конкретный воркер и там обрабатывается.

Изменено 14 декабря, 2017 пользователем anix

[Ilya Evseev]

13 часов назад, anix сказал:

Мы отказалист от балансировщика сессий (IPVS) в пользу L3: запустили на каждом воркере OSPF+IP/32, "балансировщиком" сделали L3 коммутатор с OSPF+ECMP с hash L3+L4 (получилась схема похожая на bgp anycast). Клиентская сессия попадает сразу на конкретный воркер и там обрабатывается.

Мне нужно делать балансировку по полям заголовка HTTP-запроса в HTTPS-сессии.

OSPF, ECMP и IPVS тут слабо помогут, для нас это давно пройденный этап))

[Ivan_83]

Я ж говорю - мечтать не вредно.

В 12/13/2017 в 18:49, Ilya Evseev сказал:

мне наоборот нужно, чтобы трафик ответа шёл к клиенту от воркера напрямую _мимо_ балансера. Иначе балансер ляжет. Для HTTP это сделать можно.

Как вы это делаете?

[nuclearcat]

Даже перенос http после установления сессии мягко говоря сомнителен на обычных ОС, бесплатными средствами.

Присоединяюсь к Ivan_83.

[rm_]

Много вопросов, начиная с почему "балансер ляжет" от HTTPS, и не переоценивает ли автор нагрузку от него, на современных многоядерных процах с AES-NI.

И заканчивая почему просто не поставить к нескольким воркерам несколько же балансеров (простым DNS round-robin), увеличивая количество того или другого по мере того где наблюдается узкое место.

[nuclearcat]

Угу

HTTPSBALANCER ~ # netstat -an|grep ":443"|grep ESTABLISHED|wc -l
620764

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

[zhenya`]

В 12/15/2017 в 05:33, rm_ сказал:

Много вопросов, начиная с почему "балансер ляжет" от HTTPS, и не переоценивает ли автор нагрузку от него, на современных многоядерных процах с AES-NI.

И заканчивая почему просто не поставить к нескольким воркерам несколько же балансеров (простым DNS round-robin), увеличивая количество того или другого по мере того где наблюдается узкое место.

Он тяжелое что-то мимо балансера отдаёт.

[Alex/AT]

"Балансер ляжет" - это решаемо. Делаете трёхуровневую балансировку: много HTTPS-балансировщиков перед воркерами. Перед ними ставите TCP-балансировщик(и), учитывающие в health нагрузку на HTTPS-балансировщики. С передачей на HTTPS-балансировщики TCP-соединений (если вы хотите, чтобы они напрямую общались с клиентами) особо проблем быть не должно.

[Ilya Evseev]

7 часов назад, Alex/AT сказал:

"Балансер ляжет" - это решаемо. Делаете трёхуровневую балансировку: много HTTPS-балансировщиков перед воркерами. Перед ними ставите TCP-балансировщик(и), учитывающие в health нагрузку на HTTPS-балансировщики. С передачей на HTTPS-балансировщики TCP-соединений (если вы хотите, чтобы они напрямую общались с клиентами) особо проблем быть не должно.

К сожалению, не годится по двум причинам.

 

Во-первых, балансировка изначально должна быть умной. Например, учитывать, что ответ на запрос у какого-то из воркеров уже лежит в горячем кэше. Для этого надо смотреть в заголовок HTTP-запроса. Поэтому TCP-балансировщик отпадает.

 

Во-вторых, воркер генерирует в ответ столько трафика, что любой балансировщик между воркерами и клиентами автоматически превращается в узкое место. Поэтому трафик с воркеров желательно гнать напрямую в коммутатор L3+ и оттуда соседям по iX.

[Alex/AT]

Вся "умность" в данной схеме начинается со 2 уровня балансировки (L7B<->worker). Первый уровень - чистый L4<->L7B, для равномерного и/или географического раскидывания нагрузки от крипты и трафика по балансерам 2 уровня.

Это для чисто софтового homebrewn решения.

 

Если же у вас столько трафика, что даже распределённый двухуровневый балансировщик "превращается в узкое место" - есть смысл не извращаться и смотреть что-то типа вот этого:

https://www.citrix.ru/products/netscaler-adc/netscaler-data-sheet.html

[Ivan_83]

5 часов назад, Ilya Evseev сказал:

Во-первых, балансировка изначально должна быть умной. Например, учитывать, что ответ на запрос у какого-то из воркеров уже лежит в горячем кэше. Для этого надо смотреть в заголовок HTTP-запроса. Поэтому TCP-балансировщик отпадает.

 

Во-вторых, воркер генерирует в ответ столько трафика, что любой балансировщик между воркерами и клиентами автоматически превращается в узкое место. Поэтому трафик с воркеров желательно гнать напрямую в коммутатор L3+ и оттуда соседям по iX.

Раз вы такие то пилите сами или готовьте бабло.

Люди по проще, типа ютупа и нетфликса таким не страдают.

 

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

[GrandPr1de]

2 часа назад, Alex/AT сказал:

Вся "умность" в данной схеме начинается со 2 уровня балансировки (L7B<->worker). Первый уровень - чистый L4<->L7B, для равномерного и/или географического раскидывания нагрузки от крипты и трафика по балансерам 2 уровня.

Это для чисто софтового homebrewn решения.

 

Если же у вас столько трафика, что даже распределённый двухуровневый балансировщик "превращается в узкое место" - есть смысл не извращаться и смотреть что-то типа вот этого:

https://www.citrix.ru/products/netscaler-adc/netscaler-data-sheet.html

ну или упомянутые F5 BIG IP, немножко видел эту штуку, даже дали cli поковырять

хотя часть проектов ушли на nginx балансеры с того кластера F5

[Ilya Evseev]

19 часов назад, Ivan_83 сказал:

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

Запрос лёгкий, ответ тяжёлый.

Единственный вариант, который остаётся в запасе: балансер отвечает редиректом и клиент шлёт второй запрос напрямую к конкретному воркеру, но при этом вся наша борьба за TTFB накроется медным тазом.

[Ivan_83]

В 12/19/2017 в 16:58, Ilya Evseev сказал:

Запрос лёгкий, ответ тяжёлый.

Единственный вариант, который остаётся в запасе: балансер отвечает редиректом и клиент шлёт второй запрос напрямую к конкретному воркеру, но при этом вся наша борьба за TTFB накроется медным тазом.

Илья, у меня возникают сомнения в адекватности или компетенции.

Ну нет таких штук и не будет, потому что трудозатраты на кастомный перенос tcp+tls контекста на хер пойми какой рабочий нод огромные. И к этому ещё добавляется то, что лечения проблем там будет тем ещё шаманством. Да ещё отдельной строкой то, как тупые админы будут это конфигурячить.

И всё это из за каких то лишних 0,5с на старте того что вы подразумеваете тяжёлым запросом который видимо будет раз 1000 дольше отрабатывать/отдавать.

 

Не стоит оно того.

Хотите развлекаться - тюньте tcp и tls чтобы шустрее работало, и на этом всё.

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