Я столкнулся со следующей проблемой: серверы становятся перенасыщенными, поскольку текущая стратегия балансировки нагрузки основана на IP-адресе клиента. Некоторые корпоративные клиенты получают доступ к нашим серверам из-за больших прокси, поэтому все клиенты появляются с одним и тем же IP-адресом для нашего балансировщика нагрузки. Я думаю, что мы используем какое-то аппаратное устройство для балансировки нагрузки (при необходимости могу продолжить исследование). Нам необходимо поддерживать привязку сеанса (сайт создается в ASP), чтобы все запросы с одинаковым IP-адресом направлялись на один и тот же узел.
Поскольку все коммуникации проходят через HTTPS, никакие данные запроса (например, идентификатор сеанса) не доступны для балансировщика в качестве дискриминатора клиента. Есть ли способ использовать некоторые другие данные, помимо IP, чтобы различать клиентов и маршрутизировать клиентов, даже если они приходят с одного IP на разные узлы?
Примечание: мне нужно поддерживать безопасный (зашифрованный) трафик между балансировщиком и узлами.
Самый простой способ сделать это, если у вас есть балансировщик нагрузки, - это расшифровать данные в балансировщике нагрузки и просмотреть файл cookie. На этом этапе вы можете либо отправить запрос на внутренний сервер в незашифрованном виде, либо повторно зашифровать его и отправить.
Большинство известных мне установок считают сетевое соединение между балансировщиком нагрузки и внутренним сервером безопасным и не утруждают себя повторным шифрованием трафика по нескольким причинам. Одна из причин заключается в том, что аппаратные балансировщики нагрузки также действуют как SSL-ускорители и это еще одна причина, по которой трафик HTTPS заканчивается у их дверей. Во-вторых, это позволяет трафику быть проверено на предмет атак.
Это можно сделать тремя распространенными способами:
Сначала вы можете изменить логику переадресации балансировщика нагрузки (либо отслеживать количество подключений к каждому хосту, либо пытаться равномерно распределить нагрузку, выполнить простой циклический перебор и т. Д.). Любой из упомянутых мной вариантов устраняет детерминированный характер вашей текущей настройки (клиенты с IP X больше не переходят на сервер Y), что также устраняет (или уменьшает) вашу проблему.
Обратите внимание, что вы хотите реализовать «липкие сеансы» или их эквивалент, чтобы после того, как клиент был случайным образом назначен внутреннему серверу, он продолжал переходить к тому же самому, пока их соединение активно.
Во-вторых, вы можете расшифровать информацию, прочитать от нее некоторый идентификатор сервера и затем передать его (либо повторно зашифровав его, либо передав в открытом виде по вашей внутренней сети). Обратите внимание, что это нецелесообразно в больших масштабах, если ваше оборудование для балансировки нагрузки не поддерживает SSL (например, коммутатор контента Cisco с модулями SSL), поскольку устройство, через которое вы перенаправляете весь трафик, должно выполнять ВСЕ SSL работают.
Согласно примечанию в исходном вопросе, № 2, вероятно, не вариант, поскольку трафик должен храниться в зашифрованном виде от конца до конца (похоже, расшифровка на балансировщике нагрузки будет нарушением политики?)
Третий метод, который я не рекомендую: настройка DNS с разделением горизонта или циклического перебора для вашего целевого сервера (либо непосредственно указывающего на внутренний сервер, либо указывающего на отдельные IP-адреса в балансировщике нагрузки, которые статически привязаны к резервному серверу). конец, иметь разные пулы балансировки и т. д.). Это довольно часто встречается в небольших операциях, таких как «балансировка нагрузки гетто», но в вашей ситуации (где у вас уже есть оборудование для балансировки нагрузки) это добавляет ненужную сложность по сравнению с другими решениями .
Единственный способ сделать то, что вы хотите, - отключить SSL на балансировщике нагрузки или до него, а затем выполнить балансировку нагрузки на основе идентификатора сеанса. Решениями с открытым исходным кодом для выполнения обоих шагов в одном программном обеспечении могут быть nginx, haproxy, varnish и многие другие.
Некоторые аппаратные балансировщики нагрузки использовались для балансировки на основе идентификатора сеанса SSL, но теперь браузеры повторно согласовывают сеансы SSL, поэтому это больше не работает надежно.
Зависит от конкретного типа бокса, но если вы можете изменить дискриминатор балансировки нагрузки, чтобы учесть (src ip + src port) вместо просто (src ip) вы бы сделали. Я знаю, что Citrix Netscaler поддерживает это, возможно, и другие устройства.
Не знаю, решена ли ваша проблема. В любом случае, хорошее решение - использовать привязку сеанса на основе SSL ID.
В этом случае ваше устройство запоминает идентификатор SSL в таблице памяти для маршрутизации пользовательских запросов с тем же идентификатором SSL на тот же узел сервера.
Поэтому вам придется дополнительно изучить, соответствует ли ваше устройство балансировки нагрузки.