Amazon AutoScaling e GlusterFS

Question

Eu configurei o balanceamento de carga Elastic com 5 instâncias do EC2 registradas no balanceador de carga. Para o nosso site os usuários fazem o upload de seus dados (imagens), armazenamos essas imagens em armazenamento conectado à rede (NAS). Nós temos o NAS montado em todas as instâncias.

Estamos planejando uma mudança para introduzir o Amazon AutoScaling e também sair do armazenamento conectado à rede.

1. O GlusterFS é uma boa solução para compartilhar dados em todas as instâncias do grupo Escalonamento automático?

2. Gluster garante que não haja perda de dados?

3. O que acontecerá se todas as instâncias do Escalonamento automático forem encerradas? Perderei dados do usuário?

4. O que acontece quando um usuário faz o upload de uma imagem e o servidor que processa a solicitação fica inativo?

5. Existe algum impacto no IO se os clientes diminuírem? ( O que exatamente Gluster faz? )

Answer 1

Is GlusterFS a good solution to share data across all the instances in the Autoscaling group?

Possivelmente .. A única maneira de obter uma resposta definitiva é com seus próprios testes, no entanto. No passado, eu configurei um cluster de webserver de 4 nós em instâncias Linode, usando o GlusterFS para distribuir / compartilhar o diretório de ativos de imagens e assim por diante. Encontramos dois problemas principais com esta abordagem:

1. O GlusterFS é bastante intensivo em termos de E / S e funciona muito bem em hardware com IO não resolvido
2. Ocasionalmente, um servidor Linode experimentaria um acesso abaixo do ideal para a SAN de back-end, e o tempo de espera de IO aumentaria drasticamente. Quando isso acontecia, o Gluster copiava mais dados entre os nós restantes, o que fazia com que o desempenho de IO sofresse nesses nós. O resultado disso foi que um pequeno erro de IO, causado por uma configuração SAN suboptimal, ou compartilhamento de tempo significaria que todo o cluster do servidor da Web ficaria sem destino, e todo o sistema de arquivos compartilhado poderia ficar indisponível.

Evidência puramente anedótica, mas eu nunca mais corri o GlusterFS em uma máquina virtual com SAN / armazenamento compartilhado.

Does Gluster ensure there is no loss of data ?

Pode ... No Gluster 3.0, há um melhor reconhecimento de "pools de replicação" onde você pode definir quantas cópias dos dados existem em todo o cluster. Definir um nível de replicação de 2 significa que há duas cópias em todo o cluster. Isso diminui de forma eficaz a capacidade de armazenamento, mas significa que você tem maior resiliência à falha do nó. Importante, isso também significa que você precisa adicionar mais nós como múltiplos do nível de replicação, neste caso, pares de nós.

What will happen if all the instances in Autoscaling are terminated, will I lose user data ?

Se as instâncias estiverem usando somente armazenamento de instância efêmera, sim. Se eles são baseados em EBS, ou usando instâncias montadas do EBS, então não.

What happens if a user uploads a image and the server processing the request goes down ?

Isso depende muito de como seu aplicativo foi criado. Eu suspeito strongmente que o usuário perderia seus dados (quase certo em uma solução ingenuamente arquitetada).

Is there an impact on IO if clients go down ?

Veja acima .. Se o cliente ficar inativo devido a problemas de armazenamento de backend, ele poderá destruir completamente o desempenho do cluster.

    

Answer 2

O GlusterFS parece exigir um pouco demais de configuração ao trazer novas instâncias on-line para torná-lo um bom sistema para uso em instâncias que precisam escalonar automaticamente. Tenho certeza que isso pode ser feito, mas é mais fácil alterar a arquitetura para que as instâncias da web sejam diferentes das instâncias do glusterfs. As instâncias da web, então, só precisam se conectar como um cliente à camada glusterfs. As instâncias da web podem então ser configuradas para escala automática.

Uma boa regra ao lidar com sistemas em nuvem é ter um mapeamento de serviço de 1: 1 para instância. Não tente fazer um exemplo fazer muito. Arquitetonicamente isso ajuda ao tentar dimensionar as coisas.

    

Answer 3

Você já tem algumas boas respostas para suas perguntas no Gluster, mas gostaria de mencionar algo que possa ser útil.

Dependendo do seu caso de uso, você pode encontrar o seguinte mais fácil de gerenciar & menos propenso a erros:

Os
• EC2s são todos idênticos, com o código sendo extraído de um repositório para mantê-lo atualizado (você pode gerenciar isso de várias maneiras por meio de processos de implantação)
• Qualquer upload de usuário vai direto para o S3 via s3fs ou chamadas de API integradas ao seu aplicativo (python / php etc)

Os benefícios do S3 são perfeitos:

• Pague apenas pelo que você usa (não precisa pagar por um monte de itens não utilizados recursos em EC2s, custos de execução, replicação em várias máquinas, etc., também é necessário gerenciamento zero)
• A redundância é incorporada S3, para que seus arquivos estejam seguros no momento em que eles chegarem ao s3 (com segurança, eles estão em um serviço gerenciado, em vários locais do mundo. A AWS informa que eles nunca perdeu um arquivo em s3)

Se você quisesse ir além, você poderia configurar seu servidor (linux) para enviar todos os logs para um "servidor de registro" (isso mantém todos os EC2s idênticos, tão estúpidos quanto possível).

Descobri que esse tipo de configuração funcionou muito bem no passado para os servidores da Web que gerenciei.