Ilya Evseev Опубликовано 13 декабря, 2017 · Жалоба Дано: сервер с балансировщиком входящих HTTPS-запросов много серверов-воркеров Хочется: после установки балансировщиком входящего HTTPS-соединения и получения заголовка HTTP-запроса полностью передавать установленное соединение на воркер после этого балансировщик полностью забывает про это соединение, а воркер общается с клиентом напрямую, минуя балансировщик Примерно понятно, как реализовать такую схему для HTTP, но неясно, как отследить и передать на другой сервер состояние SSL-сессии прозрачно для клиента: Собрать в балансировщике всю информацию о соединении Отправить её в сериализованном виде на воркер На воркере десериализовать её и создать рабочее соединение, завершить приём HTTP-запроса и ответить на него. Кто-нибудь уже делал что-то похожее? Ближайшее, что пока получилось найти - "SSL connection mirroring" в F5 BIG-IP. Однако оно (a) проприетарное, (б) с ценой от самолёта и (в) failover-only, т.е. делает только HA без LB. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 13 декабря, 2017 · Жалоба Странная хотелка, мягко говоря. Чтобы получить http тебе надо полностью заинитить tcp+tls. Соответственно ты должен будешь переносить tcp+tls стейты. Ну и IP у тебя тоже попутно меняется. В твоём случае только редирект на др сервер мимо балансера, иначе ты попадаешь на массу технических сложных задач. Либо проксируй дальше по http до воркера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 13 декабря, 2017 · Жалоба 2 минуты назад, Ivan_83 сказал: 1) Ну и IP у тебя тоже попутно меняется. 2) Либо проксируй дальше по http до воркера. 1) Как сделать воркерам и балансеру одинаковый IP, понятно. 2) Мне не нужно проксирование через балансер, мне наоборот нужно, чтобы трафик ответа шёл к клиенту от воркера напрямую _мимо_ балансера. Иначе балансер ляжет. Для HTTP это сделать можно. Для HTTPS пока неясно как. Можно сделать быстрый ответ от балансера с фреймом, указывающим на конкретный воркер, но этот вариант оставлен на самый крайний случай, т.к. неприемлемо увеличивает TTFB. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
anix Опубликовано 14 декабря, 2017 (изменено) · Жалоба Мы отказалист от балансировщика сессий (IPVS) в пользу L3: запустили на каждом воркере OSPF+IP/32, "балансировщиком" сделали L3 коммутатор с OSPF+ECMP с hash L3+L4 (получилась схема похожая на bgp anycast). Клиентская сессия попадает сразу на конкретный воркер и там обрабатывается. Изменено 14 декабря, 2017 пользователем anix Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 14 декабря, 2017 · Жалоба 13 часов назад, anix сказал: Мы отказалист от балансировщика сессий (IPVS) в пользу L3: запустили на каждом воркере OSPF+IP/32, "балансировщиком" сделали L3 коммутатор с OSPF+ECMP с hash L3+L4 (получилась схема похожая на bgp anycast). Клиентская сессия попадает сразу на конкретный воркер и там обрабатывается. Мне нужно делать балансировку по полям заголовка HTTP-запроса в HTTPS-сессии. OSPF, ECMP и IPVS тут слабо помогут, для нас это давно пройденный этап)) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 14 декабря, 2017 · Жалоба Я ж говорю - мечтать не вредно. В 12/13/2017 в 18:49, Ilya Evseev сказал: мне наоборот нужно, чтобы трафик ответа шёл к клиенту от воркера напрямую _мимо_ балансера. Иначе балансер ляжет. Для HTTP это сделать можно. Как вы это делаете? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 14 декабря, 2017 · Жалоба Даже перенос http после установления сессии мягко говоря сомнителен на обычных ОС, бесплатными средствами. Присоединяюсь к Ivan_83. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 14 декабря, 2017 · Жалоба Много вопросов, начиная с почему "балансер ляжет" от HTTPS, и не переоценивает ли автор нагрузку от него, на современных многоядерных процах с AES-NI. И заканчивая почему просто не поставить к нескольким воркерам несколько же балансеров (простым DNS round-robin), увеличивая количество того или другого по мере того где наблюдается узкое место. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 14 декабря, 2017 · Жалоба Угу HTTPSBALANCER ~ # netstat -an|grep ":443"|grep ESTABLISHED|wc -l 620764 Но сразу говорю - по этой железке инфой делится не могу, там проприетарщина есть. Без нее было бы около 250к, что в принципе тоже неплохо, но то что пишет автор - вышло бы намного дороже внедрять. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 17 декабря, 2017 · Жалоба В 12/15/2017 в 05:33, rm_ сказал: Много вопросов, начиная с почему "балансер ляжет" от HTTPS, и не переоценивает ли автор нагрузку от него, на современных многоядерных процах с AES-NI. И заканчивая почему просто не поставить к нескольким воркерам несколько же балансеров (простым DNS round-robin), увеличивая количество того или другого по мере того где наблюдается узкое место. Он тяжелое что-то мимо балансера отдаёт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 18 декабря, 2017 · Жалоба "Балансер ляжет" - это решаемо. Делаете трёхуровневую балансировку: много HTTPS-балансировщиков перед воркерами. Перед ними ставите TCP-балансировщик(и), учитывающие в health нагрузку на HTTPS-балансировщики. С передачей на HTTPS-балансировщики TCP-соединений (если вы хотите, чтобы они напрямую общались с клиентами) особо проблем быть не должно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 18 декабря, 2017 · Жалоба 7 часов назад, Alex/AT сказал: "Балансер ляжет" - это решаемо. Делаете трёхуровневую балансировку: много HTTPS-балансировщиков перед воркерами. Перед ними ставите TCP-балансировщик(и), учитывающие в health нагрузку на HTTPS-балансировщики. С передачей на HTTPS-балансировщики TCP-соединений (если вы хотите, чтобы они напрямую общались с клиентами) особо проблем быть не должно. К сожалению, не годится по двум причинам. Во-первых, балансировка изначально должна быть умной. Например, учитывать, что ответ на запрос у какого-то из воркеров уже лежит в горячем кэше. Для этого надо смотреть в заголовок HTTP-запроса. Поэтому TCP-балансировщик отпадает. Во-вторых, воркер генерирует в ответ столько трафика, что любой балансировщик между воркерами и клиентами автоматически превращается в узкое место. Поэтому трафик с воркеров желательно гнать напрямую в коммутатор L3+ и оттуда соседям по iX. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 18 декабря, 2017 · Жалоба Вся "умность" в данной схеме начинается со 2 уровня балансировки (L7B<->worker). Первый уровень - чистый L4<->L7B, для равномерного и/или географического раскидывания нагрузки от крипты и трафика по балансерам 2 уровня. Это для чисто софтового homebrewn решения. Если же у вас столько трафика, что даже распределённый двухуровневый балансировщик "превращается в узкое место" - есть смысл не извращаться и смотреть что-то типа вот этого: https://www.citrix.ru/products/netscaler-adc/netscaler-data-sheet.html Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 18 декабря, 2017 · Жалоба 5 часов назад, Ilya Evseev сказал: Во-первых, балансировка изначально должна быть умной. Например, учитывать, что ответ на запрос у какого-то из воркеров уже лежит в горячем кэше. Для этого надо смотреть в заголовок HTTP-запроса. Поэтому TCP-балансировщик отпадает. Во-вторых, воркер генерирует в ответ столько трафика, что любой балансировщик между воркерами и клиентами автоматически превращается в узкое место. Поэтому трафик с воркеров желательно гнать напрямую в коммутатор L3+ и оттуда соседям по iX. Раз вы такие то пилите сами или готовьте бабло. Люди по проще, типа ютупа и нетфликса таким не страдают. Мне в этой схеме не понятно в чём проблема, раз запрос такой тяжёлый то и редиректить его, а если это мелочь которая кешируется то велкам к готовым решениям из говна и палок. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 18 декабря, 2017 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 19 декабря, 2017 · Жалоба 19 часов назад, Ivan_83 сказал: Мне в этой схеме не понятно в чём проблема, раз запрос такой тяжёлый то и редиректить его, а если это мелочь которая кешируется то велкам к готовым решениям из говна и палок. Запрос лёгкий, ответ тяжёлый. Единственный вариант, который остаётся в запасе: балансер отвечает редиректом и клиент шлёт второй запрос напрямую к конкретному воркеру, но при этом вся наша борьба за TTFB накроется медным тазом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 21 декабря, 2017 · Жалоба В 12/19/2017 в 16:58, Ilya Evseev сказал: Запрос лёгкий, ответ тяжёлый. Единственный вариант, который остаётся в запасе: балансер отвечает редиректом и клиент шлёт второй запрос напрямую к конкретному воркеру, но при этом вся наша борьба за TTFB накроется медным тазом. Илья, у меня возникают сомнения в адекватности или компетенции. Ну нет таких штук и не будет, потому что трудозатраты на кастомный перенос tcp+tls контекста на хер пойми какой рабочий нод огромные. И к этому ещё добавляется то, что лечения проблем там будет тем ещё шаманством. Да ещё отдельной строкой то, как тупые админы будут это конфигурячить. И всё это из за каких то лишних 0,5с на старте того что вы подразумеваете тяжёлым запросом который видимо будет раз 1000 дольше отрабатывать/отдавать. Не стоит оно того. Хотите развлекаться - тюньте tcp и tls чтобы шустрее работало, и на этом всё. Я надеюсь что вы при своих хотелках уже хотя бы с кубика слезли, иначе просто смешно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...