Eu desenvolvi uma aplicação web. Ele será executado em um farm de cinco servidores IIS. É absolutamente essencial que, depois que uma sessão é estabelecida com um servidor no farm, outras solicitações HTTP dentro dessa sessão sejam direcionadas para o mesmo servidor no restante da sessão.
Hoje eu descobri o site da F5 e aprendi sobre "sessões complicadas". Devido ao fato de que a maioria dos meus usuários será móvel (por exemplo, iPhone), é possível que o endereço IP deles seja alterado no meio de uma única sessão. Isso significa que o IP de origem não pode ser usado para identificar sessões exclusivas. Os white papers sugerem que o dispositivo F5 LTM fornece uma solução para isso, permitindo que eu use o conteúdo dentro da própria solicitação HTTP [ou um cookie] para determinar a identidade da sessão.
Até aí tudo bem. Mas então eu comecei a pensar ... Esse dispositivo F5 é um ponto único de falha. Além disso, e se eu aumentar drasticamente a capacidade e quiser adicionar mais dispositivos F5? Configurar um cluster deles faz sentido. Mas, apesar de pesquisar no Google o melhor que posso, não consigo encontrar um white paper descrevendo os conceitos básicos de como um cluster funciona "sob o capô".
Considere ... Digamos que eu compre dois dispositivos F5. Eles compartilham um IP "virtual" comum na interface externa (voltada para a Internet) da minha rede. Uma conexão HTTP chega e, de alguma forma, os dois dispositivos determinam que a F5 nº 1 deve atender a chamada. F5 # 1 agora tem um mapa na memória que associa a identidade dessa sessão [via cookie, digamos] ao servidor web interno # 4. Dois minutos depois, esse mesmo cliente inicia uma nova conexão HTTP como parte da mesma sessão. O destino "virtual" IP é o mesmo, mas seu endereço IP de origem foi alterado. Como no mundo posso garantir que o F5 # 1 receberá essa conexão em vez do F5 # 2? Se o primeiro o receber, estamos em boa forma porque ele possui um mapa na memória para identificar a sessão. Mas se o último receber, não saberá que a sessão está associada ao servidor da Web nº 4.
Os dois dispositivos F5 compartilham informações uns com os outros de alguma forma para que isso funcione? Ou a configuração que estou descrevendo não é apenas uma maneira prática / comum de fazer as coisas?
Desculpe pelas perguntas do newb… este material é totalmente novo para mim.
A maioria dos F5 vem em pares de HA, então eles seriam agrupados. Assim que um F5 é desativado, os IPs são assumidos pelo outro F5 no par, portanto, não há tempo de inatividade. Para sua pergunta, cada IP é atribuído a apenas um F5 de cada vez e não é verdadeiramente ativo / ativo em ambos.
Essa é a sua solução, agora a próxima pergunta que você deve fazer é o que acontece se todo o site ficar inativo onde ambos os F5 estão hospedados? (e depois investigar o balanceamento de carga global).
Não acredito que você possa realmente agrupar dois switches de conteúdo F5, embora eu acredite que eles estejam trabalhando no recurso, mas posso estar errado. Agrupar balanceadores de carga é um grande desafio de engenharia - como eles compartilham informações na camada 4 ou na camada 7, como eles se comunicam na camada 2 ou na camada 3 e como o clustering e o compartilhamento de informações são ativados sem afetar o desempenho como balanceadores de carga na velocidade do fio, essencialmente.
Pense nos firewalls antigamente, os firewalls baseados em proxy sempre eram nós independentes porque faziam isso na camada 7 e era essencialmente impossível compartilhar essas informações entre nós sem prejudicar o desempenho, enquanto os filtros de pacotes com monitoração de estado precisavam apenas transferir informações da camada 4 e até mesmo isso era uma sobrecarga. Os balanceadores de carga normalmente serão implantados com grande parte de sua configuração, como no seu caso com VIPs, agindo como um endpoint e então toda a sessão TCP é reescrita e o load-balancer se torna o cliente para o servidor (ou seja, há essencialmente dois fluxos e essa é uma das razões pelas quais o cliente real não pode executar o pipelining http diretamente para o servidor back-end).
Com o HA, você não consegue a escala que deseja, então você terá que escalar o seu balanceador de carga para lidar com a carga, etc. Fornecedores como esse, como com o scale-up, geralmente (nem sempre como às vezes você pode habilitar a CPU extra com uma atualização de licença), significa que uma nova caixa maior, HA, fornece resiliência e confiabilidade, embora obviamente. Com o HA, você geralmente tem propagação de comando, sincronização de configuração e algum elemento de troca de sessão (que pode ser configurado em um grau, pois isso pode causar carga).
Você poderia dimensionar balanceando a carga de seus balanceadores de carga (ou seja, LB - > LB - > Web Farm), mas isso não é ótimo, pode apresentar latência, é (muito) caro e sua infraestrutura tem outro ponto de falha embora eu tenha visto implementado com sucesso.
Você pode usar algo como o VRRP, que é quase como um quase cluster. Nesta implementação, você pode ter dois conjuntos de pares de HA de balanceadores de carga na frente de seu farm da web, chamá-los de HA1 e HA2. Com o VRRP, você pode criar dois VIPs, sendo um deles ao vivo no HA1 (vip1) e o outro ao vivo no HA2 (vip2) devido à maior configuração de prioridade do VRRP. Tanto o vip1 quanto o vip2 podem fazer failover para o outro par de HA através do VRRP, seja automaticamente (baseado em monitores, etc.) ou manualmente, diminuindo a prioridade do VRRP.
A maioria dos fornecedores possui artigos da base de conhecimento sobre as configurações acima. Acredito que exista um fornecedor que tenha o verdadeiro cluster em seus produtos, mas deixarei que você pesquise no Google.
Todos os balanceadores de carga têm várias formas de persistência, que você aplica à associação do servidor de backend. As formas populares hoje em dia são cookie e hash (baseadas no 4-tuple e em uma ou duas outras coisas). Quando o balanceador de carga atua como um terminal como em seu cenário, uma vez que a conexão TCP esteja totalmente estabelecida, ele criará essencialmente um buffer de controle de protocolo, que conterá informações sobre a conexão (essencialmente a 4-tupla e algumas outras coisas novamente). Há dois desses buffers, um representando cada lado da conexão e esse buffer vive na memória no balanceador de carga até que a sessão seja finalizada, quando eles são liberados para liberar a memória para uso novamente.
O Citrix NetScaler parece ser a solução de balanceamento de carga mais avançada, especialmente na área de clustering. Você não precisa instalar um par de HA, basta usar um cluster de duas caixas. Então, como você quer crescer, basta adicionar mais caixas ao cluster. Eles também podem agrupar balanceadores de carga em execução nas VMs.
Para todos os balanceadores de carga, é possível configurar um par de HA para evitar um único ponto de falha. Este tem sido sempre o caso. O Big IP é caro. Você já considerou o Citrix NetScaler? Existe uma versão de máquina virtual que é muito mais barata. Na verdade, existe uma versão gratuita que você pode usar no processamento limitado de produção. Não só isso, mas você pode implantar o NetScaler VPX nos mesmos servidores que o seu aplicativo, se necessário. Apenas um pensamento. me mande um email se você quiser mais detalhes.
Você basicamente tem duas opções aqui na plataforma F5, dependendo do tipo de VIP que você está configurando. Em um VIP da Camada 4 (efetivamente um NAT), você pode configurar o espelhamento de conexão, o que permite que a sessão TCP não seja interrompida durante um evento HA. Isso não é possível para um VIP da Camada 7 - há simplesmente muito estado para "fazer backup" no modo de espera em tempo real - mas você pode espelhar os registros de persistência do cookie, garantindo que, após o failover de HA, o cliente seja reconectado ele será redirecionado para o mesmo servidor backend.
Eu não tenho conhecimento em primeira mão, mas acredito que o Netscaler tenha capacidades similares.
Dito isto, um esquema que é completamente dependente deste tipo de persistência vai ter problemas, especialmente se tiver servidores backend que entram e saem da rotação VIP em qualquer tipo de base regular. Eu encorajaria você a investigar a existência de um cache compartilhado (o memcached é ótimo para isso) que qualquer membro do pool de servidores pode consultar para validar o cookie em uma solicitação recebida. É mais fácil do que você pensa:)