Назад | Перейти на главную страницу

Перенос балансировщика нагрузки из аппаратного программного обеспечения

В настоящее время мы используем балансировщики нагрузки OVH для обслуживания нашего веб-приложения стека LAMP.

Проблема в том, что услуги OVH LB на самом деле не так хороши и слишком сильно упали. Серверы также расположены с OVH, но у них большой процент времени безотказной работы, и поэтому мы довольны этими услугами.

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

Я думаю о настройке nginx на одном сервере, чтобы действовать как программный балансировщик нагрузки, но мне нужно знать, могу ли я управлять файлами cookie, которые настроены для этой настройки, или есть более подходящие настройки.

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

Entry-point: https://client.brandname.com
Application server 1: https://client.brandname1.com
Application server 1: https://client.brandname2.com
Application server 1: https://client.brandname3.com

Но у нас есть сессионный ключ и токен в пределах двух наборов файлов cookie с именем

session|client=xxx
token|client=xxx

Нам нужно, чтобы эти файлы cookie создавались, читались, изменялись и удалялись серверами приложений, поэтому их нужно передавать через прокси-сервер Load Balancer, возможно ли это при настройке балансировщика нагрузки nginx?

Итак, можно ли это сделать через балансировщик нагрузки nginx или есть более подходящий подход?

С точки зрения наличия двух балансировщиков нагрузки и выполнения DNS Roundrobin для маршрутизации трафика на балансировщики AWS с Route53 и включенными проверками работоспособности, включенными уже на уровне DNS, могут быть отличным решением.

В качестве балансировщиков нагрузки существует множество подходов, можно использовать Haorox, NGinx, Apache (mod_proxy_balancer), ...

В случае, если вы не хотите полагаться на внешних поставщиков DNS, поддержка активности также может помочь в решении проблемы DNS / IP. В сочетании с haproxy это часто используемый стек. Также есть corosync / pacemaker для переключения при отказе IP.

Печенье

Файлы cookie являются частью ответа сервера приложения, Nginx передает их, как и любую другую часть страницы. Я не вижу проблем с использованием Nginx.

Единая точка отказа / балансировка нагрузки DNS

Предупреждение: единый балансировщик нагрузки - это единственная точка отказа. Вы можете настроить два сервера и использовать балансировку нагрузки DNS - в основном вы создаете несколько записей A, и клиент должен (теоретически) использовать случайную запись. Однако я считаю, что многие просто используют первую запись, которая возлагает большую часть или всю нагрузку на один сервер.

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

Многозначные серверы имен

CloudFlare воля сделать циклический DNS для вас, изменяя порядок записей A, согласно этой статье. Это должно распределить запросы между двумя вашими балансировщиками нагрузки.

AWS Route53 также случайным образом изменит порядок возвращаемых записей.

Я использовал обе платформы. CloudFlare имеет тенденцию быть проще, AWS десятки - мощнее и сложнее.

Липкая балансировка нагрузки

Эта настройка не обеспечит жесткой балансировки нагрузки. Если вам это нужно, вам понадобится более продвинутый балансировщик нагрузки. CloudFlare имеет балансировщик нагрузки, который может это сделать, как и AWS Route53.