CherryPy, balanceamento de carga e failover remoto

Question

O site atual da nossa empresa voltado para o cliente & O site da intranet é atualmente construído no ASP clássico em execução no IIS 6. O site atual contém apenas cerca de 10 páginas voltadas para o cliente e um site interno que gerencia registros de RH, agendamento, etc.

A gerência decidiu que usaremos esse projeto de reescrita para finalmente desenvolver nossa loja de varejo on-line. Eles querem que usemos uma instalação separada geograficamente (também em um ISP completamente diferente) para fornecer um failover caso o link da WAN em nossas instalações primárias caia.

Escolhemos o Python para a reescrita, pois queremos ser capazes de migrar para uma plataforma baseada em Linux, e atualmente usamos o Python em outros projetos internos de desenvolvimento.

Nós analisamos as várias estruturas de desenvolvimento da Web em Python, e o CherryPy parece ser uma boa opção para o que precisamos, que é um ambiente mínimo para servir conteúdo gerado pelo Python. No entanto, estou tendo problemas para encontrar informações sobre o uso do CherryPy com tecnologias de balanceamento de carga e failover.

Parece que seremos forçados a hospedar o CherryPy no Apache para aproveitar um cluster de balanceamento de carga / failover que suporte sessões fixas. Está correto, ou existe uma maneira de fazer isso usando o servidor interno de CherryPy ou um servidor HTTP diferente?

Além disso, existem serviços que fornecem uma maneira de direcionar o tráfego no cluster para que nós mesmos não tenhamos que hospedá-lo? Precisamos ser capazes de distribuir nosso tráfego entre os dois datacenters, mas se o link da WAN ficar inativo em um deles, isso não afetará a capacidade do cluster direcionar o tráfego para o cluster que ainda está disponível.

    

Answer 1

Há duas partes principais nisso,
- balanceamento de carga e failover em vários datacenters
- balanceamento de carga e failover em vários servidores dentro de um datacenter

Existem três maneiras principais de fazer vários datacenters: BGP / "anycast", GSLB / DNS ou usando um mecanismo de failover de origem dentro de um CDN. none são simples, fáceis ou baratas.

Quando o tráfego dos usuários chegar em um datacenter específico, você precisará de um componente do balanceador de carga. Há várias opções aqui que podem ser categorizadas como appliance-vs-software e layer4-vs-layer7. A julgar pelos detalhes que você deu eu vou apostar que suas necessidades são bem simples e seu orçamento bem pequeno, então vamos apenas pular direto para o nginx nessa parte. Dentro do nginx você pode configurá-lo para servir o seu conteúdo estático e para balancear o seu conteúdo dinâmico em tantos servidores de back-end quanto você quiser rodando seu aplicativo python.

Boa sorte, é uma longa estrada que você começou.

    

Answer 2

Existem algumas subquestões em sua pergunta que realmente devem ser suas próprias entradas - mas vamos enfrentá-las de qualquer maneira ...

O "servidor" de CherryPy não deve ser usado na produção, é ótimo para o desenvolvimento, mas você deve usar o Nginx e uma configuração Fastcgi na frente do seu aplicativo CherryPy. Isso lhe dará melhor controle sobre a carga do servidor e quantas instâncias do aplicativo CherryPy você precisa executar para gerenciar essa carga.

Sua preocupação com balanceamento de carga entre ISPs me faz pensar que você está mais preocupado com redundância do que com balanceamento de carga porque precisará se preocupar em manter os dados envolvidos sincronizados entre os diferentes datacenters, o que é uma preocupação maior do que equilíbrio entre eles.

Dependendo de quanto de orçamento você pode controlar, o que levará a decisão de usar um balanceador de carga de hardware ou uma solução de software. Se você está procurando por redundância, você pode ter a configuração do servidor espelhada em outro site e, em seguida, alterar seus registros DNS para apontar para esse site em caso de falha. Qualquer outra coisa exigirá soluções de hardware que envolvam a sopa de letrinhas de acrônimos como o cagenut mencionado acima.

    

Answer 3

Usamos o ZXTM para balancear a carga de várias instâncias dos mesmos nós do CherryPy. Funciona muito bem.

As versões recentes do CherryPy (3.0.4 e 3.2, por exemplo) incluem uma correção para o servidor WSGI para torná-lo mais robusto. As versões anteriores aceitariam novas conexões e as pendurariam mesmo se a fila de solicitações de entrada estivesse cheia (ou seja, se todos os threads de trabalho estivessem ocupados). Agora, você pode definir server.accepted_queue_timeout como 0 se preferir que eles sejam rejeitados imediatamente. Fechar essas conexões imediatamente permite que o ZXTM tente passar a conexão para outro nó imediatamente.

    

Answer 4

Tem certeza de que é isso que você precisa? Peça à sua gerência uma estimativa de tempo de inatividade aceitável, pois eles podem muito bem reduzir o nível para níveis realistas. Dois sites completamente independentes colocam você na categoria big boys, com preços correspondentes nas soluções.

Talvez você possa encontrar uma solução personalizada com um parceiro de internet confiável? Encontre alguém disposto a oferecer colo em racks diferentes (em diferentes alimentações de energia), em dois comutadores de acesso a dois roteadores principais para dois uplinks muito diferentes.