Atualmente, estou pensando em migrar alguns de nossos servidores e aplicativos para um ambiente coreOS . Um dos problemas que vejo aqui é o gerenciamento de dados persistentes, pois o coreOS não lida com os volumes do Docker ao mover um contêiner para uma nova máquina. Após algumas pesquisas, encontrei o glusterFS, que afirma ser um sistema de arquivos em cluster que pode resolver todos os meus problemas.
Minha ideia atual é a seguinte: tenho um contêiner glusterFS que é executado como um contêiner privilegiado em cada uma das minhas máquinas coreOS e expõe um armazenamento /mnt/gluster, por exemplo. Nos meus Dockerfiles especifiquei que todos os meus volumes devem ser montados nesse caminho.
A próxima coisa que considerei foi quais contêineres deveriam obter seus próprios volumes e quais deveriam compartilhar um. Por exemplo, cada mysqlcontêiner obteria seu próprio volume, pois é capaz de lidar com a replicação sozinho. Eu não quero mexer com isso. Os servidores da Web que servem o mesmo site usariam adequadamente o mesmo volume para coisas como "imagens enviadas por usuários" etc., pois não são capazes de replicar esses dados.
Alguém já tentou algo assim ou há algo que eu perdi?
Respostas:
Implementamos uma configuração semelhante ao Atomic ( http://www.projectatomic.io/ ) em vez do CoreOS em um sistema de armazenamento GlusterFS replicado e não distribuído, com três conjuntos de réplicas-2. Isso funciona muito bem.
No entanto, você precisa manter algumas características especiais do GlusterFS em mente. Como Brian já mencionou, Gluster coloca acima de tudo consistência e confiabilidade. Quanto mais mudanças ocorrem, mais replicação ocorre. Isso coloca muita pressão, e quero dizer, MUITO no seu sistema.
Certifique-se de que seu subsistema de E / S seja rápido (duh, é armazenamento), conecte os nós do Gluster às conexões de rede mais rápidas disponíveis. Se você possui apenas GBit, agregue! Por último, mas não menos importante, o sistema de armazenamento deve ter um poder de computação sério, a Gluster faz muitos cálculos para verificar seu estado. Dito isto, mesmo sob alta carga, a Gluster entrega.
Reconsidere sua estratégia MySQL. O Gluster faz a replicação para você e também fornece uma espécie de balanceamento de carga na entrega. Na verdade, pode ser mais rápido usar o Gluster.
fonte
O uso do glusterfs dependeria do back-end de armazenamento que você está usando. Como um sistema de arquivos em cluster, pretende-se agrupar o armazenamento físico para que apareça como um grande volume contínuo. Este guia oficial de início rápido tem uma boa explicação do processo.
Caso sua configuração utilize dois ou mais servidores de armazenamento de back-end separados ou algo semelhante para armazenar todos os volumes da janela de encaixe, o uso do glusterfs ou outro sistema de arquivos paralelo semelhante pode oferecer vantagens significativas de desempenho. Se esse for o caso, você também pode considerar o uso do Luster , que é amplamente usado como um sistema de arquivos paralelo na comunidade HPC.
Com isso dito, ajustar, depurar e configurar sistemas de arquivos paralelos / de cluster pode ser uma tarefa demorada que requer muita experiência, paciência e, às vezes, disposição para reiniciar desde o início. Seria prudente garantir que o desempenho beneficie uma oferta de sistema de arquivos paralelos que valha a quantidade de esforço necessário para configurá-la e mantê-la.
fonte