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

Балансировка нагрузки для запущенного серверного процесса с сессиями

Я разрабатываю серверное приложение, которое принимает входящие соединения и работает с клиентскими приложениями. Заказчик хочет, чтобы две машины работали: если одна перейдет в автономный режим, вторая создаст резервную копию. Администратор машины (с которым я почти не общаюсь) предложил решение для балансировки нагрузки: будут две идентичные серверные машины, каждая из которых будет запускать серверный процесс независимо, а также будет машина балансировки нагрузки, которая будет разбрасывать входящие соединения между двумя рабочими машинами.

Должен отметить, что я не очень хорошо знаком с этой темой. Я думаю, что балансировка нагрузки имеет смысл с веб-сайтом (который также является частью настройки, частью которой является мой сервер), но мой сервер не основан на запросах: он поддерживает сеансы и связанные данные в своей памяти кучи и обменивается сеансом - и данные о состоянии клиентов (которые постоянно остаются на связи). Таким образом, если одна машина выходит из строя и балансировщик переключает клиента на другую машину, эта другая машина не сможет продолжить работу с этим клиентом без недостающих данных времени выполнения.

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

Операционная система основана на Linux, но меня больше интересуют общие концепции, чем установка чего-либо самостоятельно, поэтому могут быть интересны пакеты или руководства для любой системы.

Проблема и идея не на 100% понятны ни администратору, ни вам.
Есть два решения: «Высокая доступность» и «Балансировка нагрузки».
Эти два решения разные по своей природе!
В случае помещения двух серверов приложений за решением LoadBalancing у вас по-прежнему будет одна точка отказа для серверов приложений, которая является балансировщиком нагрузки.
В случае, если вам нужно решение для «высокой доступности», вам нужно работать на двух машинах, в то время как одна находится там, на случай проблем с другой.
Для HA вы можете использовать базовый Pacemaker, который позволяет одному серверу определять, работает ли другой, на основе всевозможных опций.
Вы должны знать о STONITH, который дает вам возможность не допустить, чтобы один сервер нарушал работу другого в нескольких случаях.
Взгляни на: Кардиостимулятор

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

Если вы ищете нестандартные решения, вам следует обратить внимание на использование Amazon Web Services (AWS). Их среда Elastic Beanstalk - отличный способ развернуть ваш код одновременно на нескольких машинах за настраиваемым балансировщиком нагрузки (http://aws.amazon.com/elasticbeanstalk/).

Еще посмотрите NGINX или Apache с несколькими вышестоящими серверами.

Здесь нет никакой «волшебной пули». Вам необходимо спроектировать свое приложение таким образом, чтобы ни одно состояние приложения не сохранялось локально, которое не синхронизировалось бы где-либо еще.

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

Что касается того, что «администратор» говорит о синхронизации, единственное, что я видел, - это отказоустойчивый (FT) режим VMware. При этом горячее подчиненное устройство всей виртуальной машины хранится в отдельном физическом ящике. Однако существует множество ограничений для этой настройки, и это не решение для балансировки нагрузки, так как только одна из копий виртуальной машины является «активной» в любой момент времени.