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

Высокая доступность без разрыва соединений

Можно ли настроить высокую доступность, в этом примере перейти на 2 веб-сервера, и позволить ей переключаться при сбое без разрыва соединений?

У меня есть два веб-сервера, которые используют комету, метод HTTP, при котором у вас есть долговечные HTTP-соединения. У меня есть два балансировщика нагрузки на переднем плане с общим IP. Если один из этих интерфейсных серверов выходит из строя, все соединения теряются.

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

Вы не можете сделать это через HAProxy, потому что он находится на неправильном уровне OSI - на уровне HTTP, а не на уровне TCP. Некоторые из балансировщиков нагрузки нижнего уровня имеют функцию, которая может выполнять то, о чем вы говорите, по крайней мере, для многих соединений, передавая информацию назад и вперед от активного узла к пассивному узлу. Посмотрите на виртуальный сервер Linux (LVS) в сочетании с демоном уровня обслуживания, таким как ldirectord, для выполнения того, что вы ищете.

Я также исследовал, как сбалансировать нагрузку на долгоживущие соединения Telnet. Даже большие дорогие балансировщики нагрузки, такие как F5, похоже, не поддерживают «миграцию» открытого TCP-соединения с мертвого сервера на другой сервер. Я подумал о том, чтобы перехватить пакеты подтверждения и подключения от telnet на нашем балансировщике нагрузки, а затем воспроизвести их, если ему придется повторно подключиться к другому серверу. Проблема в том, что каждое приложение (telnet, comet, ssh и т. Д.) Имеет другой набор правил для инициации соединения и входа в систему. Без программирования для каждого приложения я не знаю балансировщика нагрузки, который может делать такие вещи. .

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

Для кометы я предлагаю вам настроить веб-службу для повторного подключения при обнаружении отключения. Эта статья о HTTP Streaming на ajaxpatterns.org есть фрагмент кода для обнаружения отключения.

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

На самом деле это невозможно. Было бы гораздо лучше запрограммировать клиента, чтобы он допускал сбой сервера и автоматически переподключался. Это могло бы привести к отказу одного сервера и, возможно, отказоустойчивому сайту (в случае отказа всего сайта).

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

Этого можно добиться с помощью отказоустойчивости vmware на esx / esxi, но также существует множество ограничений.

Извините, что не установил ссылку, на моем телефоне в машине по дороге домой :-).