Стратегия распределения узлов erlang otp за haproxy
У меня есть стандартное приложение erlang, построенное на принципах otp. Я планирую разместить мои узлы erlang в производстве, как описано ниже:
- получать весь трафик на публичный ip (haproxy)
- переадресовать их на один из доступных серверных узлов erlang
Все это работает очень хорошо, однако в случае http-транзакций на основе сеанса существует вероятность того, что один из узлов erlang получит запрос, а процессы, связанные с сеансами, находятся на другом узле erlang.
Мои вопросы связаны с лучшей стратегией для обработки таких случаев:
- Первый вариант - настроить haproxy для балансировки на основе источника (то есть IP-адреса), это всегда будет гарантировать, что все запросы на сеанс с одного ip-адреса будут отправлены на один и тот же серверный узел erlang.
- второй вариант - настроить балансировку haproxy на основе некоторого параметра cookie, относящегося к сеансу (который в основном дает мне то же, что и в случае 1)
- наконец, поскольку мои узлы erlang могут очень хорошо взаимодействовать друг с другом, также возможно просто настроить haproxy для балансировки в циклическом режиме, и когда узел erlang получает запрос, чьи сеансовые процессы находятся на другом узле erlang, он может осуществлять внутреннюю связь с узлом erlang с помощью rpc:call() и обработайте запрос.
1), 2) довольно просты в использовании и настройке, однако я прочитал и проверил, что балансировка на основе source/cookie/url_param не обеспечивает равную балансировку между бэкэндами.
3) достижимо, используя силу репликации мнезии внутри эрланга. С 3) я, вероятно, в конечном итоге получу случай, когда один узел erlang связывается внутри с другим узлом erlang, прежде чем он, наконец, отправит ответ на запрос.
Хотелось бы узнать, что предпочтительнее и почему? Будет 3) лучшим выбором в долгосрочной перспективе, учитывая, что мое приложение otp обрабатывает много данных в реальном времени (протокол xmpp).
1 ответ
Я думаю, что это во многом зависит от того, какую нагрузку может выдержать один из ваших узлов с точки зрения сеансов. Хэширование IP-адресов и файлов cookie, по крайней мере, с точки зрения HTTP, обеспечивает хорошую работу по поддержанию баланса с большим количеством коротких сеансов.
Так, например, может быть много клиентов за одним IP-адресом (хеширование на основе файлов cookie должно помочь). Если один узел может обрабатывать только относительно небольшое количество одновременных сеансов, то узел может быть перегружен. Также, если сеансы являются долгоживущими, дисбаланс хеширования может быть выражен Если, с другой стороны, количество сеансов велико и недолговечно, относительная значимость одного узла, имеющего еще несколько соединений, скорее всего, не будет иметь большого значения.
Теоретически я также ожидал бы, что с некоторой формой балансировки на основе исходных текстов или файлов cookie вы получите лучшие коэффициенты попадания в кэш. Еще одна вещь, которую следует учитывать, это то, что если вы скажете 3 узла, то, если один узел выйдет из строя, каждый из остальных узлов будет иметь нагрузку на ~ 16% больше на каждом из них даже при идеальной балансировке нагрузки. Таким образом, вы должны учитывать и обеспечение.
Если вы можете обрабатывать большое количество запросов на одном узле, то для меня третий вариант звучит так, будто вы решаете проблему, которой у вас нет и вряд ли возникнет, когда выполнимо гораздо более простое решение.