Текущий сайт нашей компании, ориентированный на клиентов, и сайт интрасети в настоящее время построены на классическом ASP, работающем на IIS 6. Текущий сайт содержит всего около 10 страниц, ориентированных на клиентов, и внутренний сайт, который управляет записями кадров, расписанием и т. Д.
Руководство решило, что мы будем использовать этот проект перезаписи для окончательного развития нашего розничного интернет-магазина. Они хотят, чтобы мы использовали географически отдельный объект (также на совершенно другом ISP), чтобы обеспечить аварийное переключение в случае выхода из строя канала WAN на нашем основном объекте.
Мы выбрали Python для переписывания, поскольку хотим иметь возможность перейти на платформу на основе Linux, и в настоящее время мы используем Python в других проектах собственной разработки.
Мы рассмотрели различные фреймворки веб-разработки Python, и CherryPy, похоже, хорошо подходит для того, что нам нужно, а именно для минимальной среды для обслуживания контента, созданного Python. Однако у меня возникают проблемы с поиском информации об использовании CherryPy с технологиями балансировки нагрузки и аварийного переключения.
Похоже, нам придется разместить CherryPy на Apache, чтобы использовать отказоустойчивый кластер с балансировкой нагрузки, поддерживающий закрепленные сеансы. Это правильно, или это способ сделать это с помощью внутреннего сервера CherryPy или другого HTTP-сервера?
Кроме того, существуют ли службы, которые позволяют направлять трафик в кластере, чтобы нам не приходилось размещать его самостоятельно? Нам необходимо иметь возможность распределять наш трафик между двумя центрами обработки данных, но если канал WAN выходит из строя в одном из них, это не может повлиять на способность кластера направлять трафик в кластер, который все еще доступен.
Вы уверены, что это то, что вам нужно? Спросите у своего руководства о приемлемом времени простоя, они вполне могут снизить планку до реалистичного уровня. Два полностью независимых сайта помещают вас в категорию больших мальчиков с одинаковыми ценами на решения.
Возможно, вы сможете найти индивидуальное решение у надежного интернет-партнера? Найдите кого-нибудь, кто готов предложить вам коло в разных стойках (с разными источниками питания), на двух коммутаторах доступа к двум основным маршрутизаторам и двум совершенно разным каналам связи.
Мы используем ZXTM для балансировки нагрузки нескольких экземпляров одних и тех же узлов CherryPy. Прекрасно работает.
Последние версии CherryPy (например, 3.0.4 и 3.2) включают исправление для сервера WSGI, чтобы сделать его более надежным. Предыдущие версии принимали новые соединения и зависали от них, даже если очередь входящих запросов была заполнена (то есть, если все рабочие потоки были заняты). Теперь вы можете установить server.accepted_queue_timeout в 0, если хотите, чтобы они были отклонены сразу. Мгновенное закрытие этих соединений позволяет ZXTM сразу же попытаться передать соединение другому узлу.
В вашем вопросе довольно много подвопросов, которые действительно должны быть отдельными записями, но давайте все равно займемся ими ...
«Сервер» CherryPy вообще не должен использоваться в производстве, он отлично подходит для разработки, но вам действительно следует использовать Nginx и настройку Fastcgi перед вашим приложением CherryPy. Это даст вам лучший контроль над загрузкой сервера и тем, сколько экземпляров приложения CherryPy вам нужно запустить для управления этой нагрузкой.
Ваше беспокойство по поводу балансировки нагрузки между поставщиками услуг Интернета заставляет меня думать, что вас больше беспокоит избыточность, чем балансировка нагрузки, потому что вам нужно будет беспокоиться о том, чтобы синхронизировать задействованные данные между различными центрами обработки данных, что является большим беспокойством, чем то, как балансировать нагрузку между ними .
В зависимости от того, насколько сложно справиться с бюджетом, вы решите использовать аппаратный балансировщик нагрузки или программное решение. Если вам нужна избыточность, вы можете настроить сервер на другом сайте, а затем изменить свои записи DNS, чтобы они указывали на этот сайт в случае сбоя. Для всего остального потребуются аппаратные решения, включающие алфавитный суп из аббревиатур, таких как cagenut, упомянутый выше.
В этом есть две основные части:
- балансировка нагрузки и переключение между несколькими центрами обработки данных
- балансировка нагрузки и переключение между несколькими серверами в центре обработки данных
Существует три основных способа создания нескольких центров обработки данных: BGP / "anycast", GSLB / DNS или использование механизма переключения источника при отказе в сети CDN. никто просты, легки или дешевы.
Как только пользовательский трафик поступает в конкретный центр обработки данных, вам понадобится компонент балансировки нагрузки. Здесь есть множество вариантов, которые можно в общих чертах разделить на «устройство против программного обеспечения» и «слой 4 против уровня 7». Судя по предоставленным вами деталям, я готов поспорить, что ваши потребности довольно просты, а ваш бюджет довольно мал, поэтому давайте сразу перейдем к nginx для этой части. В nginx вы можете настроить его для обслуживания вашего статического контента и для балансировки нагрузки вашего динамического контента на таком количестве внутренних серверов, на котором вы хотите запустить приложение Python.
Удачи, ты начал долгий путь.