Eu tenho um site que está monitorando uma média de 50 milhões de acessos por dia e, nos próximos 3 meses, deverá ter mais de 100 milhões de acessos por dia. Estamos tentando usar GlusterFS v 3.0.0 (com patches mais recentes de 17/01/2010)
Atualmente, acabamos de atualizar para um ambiente de balanceador de carga que possui 3 hosts físicos com 6 VMs Xen-Server 5.5u1 (2 em cada host) para atender ao tráfego de páginas da web. Cada máquina possui 6 unidades de armazenamento local Raid-6 (7200RPM-SATA). A máquina antiga de onde viemos tinha 1 unidade SAS 10k espelhada.
Também configuramos o GlusterFS atualmente com 3 tijolos, um em cada host, e ele está atendendo as 6 VMs como clientes. Nos testes, tudo parecia bem. No entanto, quando iniciamos a produção, parecia que não havia E/S suficientes disponíveis para atender tráfego acima de 15 milhões de acessos. Semanas antes, nosso antigo servidor era capaz de lidar com o tráfego, no máximo, de 20 milhões.
Existe alguma configuração recomendada para tal aplicativo ou coisas que você deve saber que não são aparentes na documentação em gluster.org para um site do nosso tamanho?
Responder1
RAID-6 de unidades 6x7.2krpm sem cache de gravação (?) teráTerríveldesempenho de gravação, tão terrível que provavelmente irá sobrecarregar os discos o suficiente para realmente impactar o desempenho de leitura também se seu aplicativo tiver uma combinação saudável. Quero dizer, realisticamente, você está vendo cerca de 250 iops aleatórios em uma divisão de leitura/gravação 80/20 dessa matriz. Se você estiver fazendo centenas de solicitações http por segundo, algo tão trivial quanto o log de acesso do Apache irá atrapalhar isso como um ataque DoS.
Se puder, refaça-os como raid10. Isso custará algum espaço bruto, mas terá um enorme impacto no desempenho de E/S. E se você conseguir obter cache de gravação com bateria nas placas RAID, isso fará uma grande diferença.
Não estou familiarizado com o glusterfs em particular, mas todos os sistemas de arquivos distribuídos tendem a ter o mesmo problema básico, latência de rede + bloqueio complexo = desempenho ruim, especialmente em arquivos pequenos e especialmente em cargas de trabalho de gravação substanciais.
E/S de disco lenta e um sistema de arquivos lento, esse design de cluster simplesmente não se adapta à carga de trabalho. É tarde demais para devolver os servidores ou pelo menos os subsistemas de disco? Se esta for a plataforma principal de uma empresa com receitas substanciais, você realmente deveria contratar um profissional.
Responder2
Para qual meio você está transferindo seu tráfego do GlusterFS? Se for Ethernet, sua configuração será severamente limitada devido às despesas gerais do TCP/IP. GlusterFS não é o mais eficiente aí. Onde realmente brilha é no RDMA. Você pode conseguir isso com Infiniband ou 10GigE.
Também não estou certo de por que você decidiu colocar 2 hosts virtuais em cada host físico, se todos eles executam as mesmas tarefas. Por que não apenas executá-los no metal puro e evitar sobrecarga?
Responder3
Qual versão do GlusterFs você está usando? GlusterFS 3.0.0 é uma versão principal e tem muitas melhorias, incluindo aumento no desempenho de arquivos pequenos.
Existem muitos tradutores de desempenho no GlusterFS que podem ser ajustados para diversas cargas de trabalho. Por exemplo, para aumentar o desempenho de leitura, temos o tradutor de leitura antecipada e para o desempenho de gravação, temos o tradutor de gravação posterior. io-cache é outro tradutor de desempenho que pode ser usado para armazenamento em cache.
Que tipo de configuração é a sua? Você está usando replicar ou distribuir ou ambos? Qual é o back-end da sua rede? Você comparou a E/S de rede/disco entre os servidores antigos e os novos para eliminar gargalos?
Se você puder compartilhar seus arquivos de volume conosco, poderemos ajudá-lo a ajustar seus arquivos de configuração para otimizar o desempenho de suas cargas de trabalho.
Apenas para sua informação, oferecemos assinatura de suporte de teste gratuito de 30 dias[1], onde você pode obter respostas rápidas e detalhadas às suas dúvidas.
Obrigada, Sachi
Responder4
Sem mais informações sobre sua configuração (por exemplo, seu site é estático ou dinâmico? As transações de banco de dados ocorrem nos servidores que usam o mesmo subsistema de armazenamento?), mas o RAID 6 geralmente é uma má escolha para desempenho de gravação, não importa quando você introduz ainda mais complexidade através do brilho. Você potencialmente tem dois conjuntos de tradução de faixa de gravação em andamento, um no nível do gluster e outro no nível do controlador. Então você tem dois cálculos de paridade que tornam as coisas mais lentas e causam bloqueio de E/S, a menos que você tenha um grande cache de gravação e períodos de baixa atividade de E/S.
Eu recomendo que você mude para RAID 10 e faça backup com canal de fibra ou vários links GigE vinculados.