AWS ELB como backend para o Acelerador de Verniz

Question

Estou trabalhando em uma grande implantação na AWS que possui altos requisitos de tempo de atividade e cargas variáveis ao longo do dia. Obviamente, este é o caso de uso perfeito para ELB (Elastic Load Balancer) e escalonamento automático.

No entanto, também dependemos de verniz para o armazenamento em cache de chamadas de API. Meu instinto inicial era estruturar a pilha para que o verniz usasse o ELB como back-end, o que, por sua vez, atingia um grupo de aplicativos.

Varnish -> ELB -> AppServers

No entanto, de acordo com um poucos não é possível, pois o ELB muda constantemente o endereço IP de seu nome de host DNS, que armazena em cache o verniz no início, o que significa que as alterações no IP não serão detectadas pelo verniz.

Lendo, no entanto, parece que as pessoas estão fazendo isso, então estou me perguntando quais soluções alternativas existem? Talvez um script para recarregar o vcl periodicamente?

No caso de isso não ser apenas uma boa idéia, alguma idéia de outras soluções?

    

Answer 1

O verniz pode funcionar como um balanceador de carga. Você deve tentar Varnish -> AppServers .

Basta definir cada servidor de aplicativos como um back-end em um diretor na configuração do Varnish.

Você pode até mesmo adicionar testes para verificar a disponibilidade do back-end, para tentar alternar para outro servidor quando um falhar durante um processo de solicitação, etc.

Onde a sua instância do Varnish está hospedada? ASW também? Você poderia tentar o diretor de hash Varnish e hospedar o Varnish nos mesmos servidores que os aplicativos. Cada instância processará as solicitações que devem manipular e encaminhará outras para o back-end correto. Cada URL única só será armazenada em cache em um servidor (disponível) e sua memória cache será multiplicada pelo número de instâncias de Varnish, enquanto as falhas de cache serão limitadas.

    

Answer 2

Isto é absolutamente possível, mas são necessários alguns passos para que funcione bem! A maneira como fazemos isso aqui quando precisamos desse tipo de configuração é:

• Crie um VPC. Você precisa fazer isso no VPC porque precisa criar sub-redes nelas.

• Crie uma sub-rede em cada zona de disponibilidade em que você terá instâncias registradas no ELB. Você deve criar uma sub-rede para que você tenha um pequeno número de endereços IP em cada sub-rede, pois cada endereço IP se transformará em sobrecarga. (Atualmente, usamos sub-redes que são / 26)

• Comece a criar um backend DNS Director no seu verniz VCL. Adicione as três sub-redes que você criou acima. ( link )

• Defina a configuração do host no backend do DNS Director como o nome do host que o verniz deve esperar ver. (por exemplo, se o seu serviço front-end for chamado, digamos, front-end-service.subdomain.example.com, coloque front-end-service.example.com como a configuração do Host na VCL.)

• Defina a configuração de sufixo no diretor DNS para algo que você possa resolver. Continuando o exemplo acima, você poderia facilmente usar '-varnish.example.com' para o seu sufixo. Quando uma solicitação atingir o verniz, o verniz examinará o cabeçalho do host HTTP e, se o nome corresponder ao que o verniz tem na configuração do cabeçalho do DNS Director da VCL, o verniz anexará o sufixo e executará uma pesquisa de DNS no nome do host. o resultado da concatenação do conteúdo do cabeçalho do Host com o sufixo. Assim, neste exemplo, uma pesquisa de DNS será executada por verniz para o host chamado "front-end-service.subdomain.example.com-varnish.example.com"

• Crie o backend do seu balanceador de carga e faça anexá-lo a cada sub-rede que você criou.

• Defina um registro DNS para o resultado da concatenação como sendo um CNAME para o nome DNS que a Amazon fornece para o seu balanceador de carga.

• Inicie o verniz. Opcionalmente, consulte varnishstat para verificar o número de back-ends.

• Teste sua configuração emitindo um

  curl -H "Anfitrião: front-end-service.subdomain.example.com" link

• Assista à solicitação com vernizlog para verificar se tudo está funcionando.

Pode ser útil observar que a AWS recomenda que você tenha uma sub-rede com pelo menos 20 endereços IP não usados se for colocar um balanceador de carga nessa sub-rede. (Veja link )

Fizemos isso para um projeto recente que precisava de ELBs para uma especificação de requisito, mas estamos preocupados com o dimensionamento com relação à facilidade de gerenciamento e estamos procurando abordagens baseadas em descoberta de serviço juntamente com algo como uma atualização automatizada de VCL. Além disso, a VCL automatizada é implantada por meio de algo como o Varnish Agent ( link )

No entanto, se você não se importar em gerenciar suas sub-redes VPC, a descrição acima funciona muito bem.

Felicidades!

    

Answer 3

Parte do objetivo do ELB é sobreviver às interrupções do host. Mesmo com o escalonamento automático e o CloudWatch, se uma instância inoperante precisar ser substituída, você estará possivelmente com vários minutos de inatividade.

Eu recomendo:

[Front End ELB] -> [Varnish] -> [Back End ELB] -> [AppServers]

Sei que você quer aproveitar ao máximo o armazenamento em cache, mas você realmente deve distribuir a carga em todas as zonas de disponibilidade. Isso significa ter um número igual de instâncias na zona A, B e C para a (s) região (ões) em que sua pilha está (então 3x Varnish). Isso, naturalmente, custará mais, mas lhe dará a capacidade de sobreviver a interrupções de AZ *. Cortar esse custo significa que, em algum momento, você provavelmente precisará reduzir o tempo. Essa é sua decisão, mas pelo menos você pode tomar uma decisão informada.

Tenha dois grupos de segurança, um para o Varnish e outro para AppServers. Configure cada um para que apenas o ELB associado possa acessá-lo na porta apropriada.

Para a configuração do Varnish, defina o direcionador do DNS para ter um TTL baixo. Defina-o como igual (ou parcial) do TTL do CNAME que a Amazon fornece para o ELB de back-end. Isso deve ser suficiente para o Verniz se manter atualizado.

* E se você quiser ir para a disponibilidade final. use o Route53 com redundância multi-região e multi-az.