Dell VRTX - armazenamento compartilhado em cluster lento

Question

Eu tenho uma nova caixa Dell VRTX configurada como um cluster de failover que executa máquinas virtuais HA Hyper-V. Esta é a minha primeira vez configurando o cluster, e a minha primeira vez com uma dessas caixas, então tenho certeza que perdi algo.

As máquinas virtuais estão com alta latência de disco e desempenho ruim ao acessar seus arquivos VHD (x) localizados em um Volume Compartilhado do Cluster.

O VRTX possui 10 unidades SAS de 10K 900 GB 10K na configuração RAID 6, e o VRTX possui os controladores PERC 8 compartilhados redundantes. Ambas as lâminas têm acesso total aos discos virtuais. Existem dois blades M520 instalados, cada um com 128 GB de RAM. O MPIO está configurado para os controladores PERC 8. O sistema operacional nos blades é o Server 2012 (NÃO R2).

O array RAID 6 é dividido em um pequeno volume (8 GB) para testemunha de quorum de cluster e um grande volume (6.5 TB) para um Volume Compartilhado do Cluster (montado nos nós como C: \ ClusterStorage \ Volume1)

Um exemplo de acesso a disco lento: o logon em uma VM do Server 2012 e o Server Manager aparecem automaticamente. O acesso ao disco vai para 100%, com velocidades de gravação de 20 MB ou mais, velocidades de leitura de 500 KB ou mais, e tempo médio de resposta de mais de 1000 ms, às vezes chegando a 4000-5000 ms ou mais. É a latência que realmente me preocupa.

Existe algo específico que eu deveria olhar na minha configuração? Não parece importar se eu uso VHD ou VHDX, dinâmico ou estático.

    

Answer 1

Eu experimentei exatamente o mesmo problema de desempenho com um VRTX com o Dual SPERC8. O que eu fiz para contornar isso no momento é, alterar a configuração dupla para uma única configuração. Dessa forma, eu posso usar o write-back, que tem um desempenho melhor.

• As etapas exatas:
  • Remove o segundo controlador SPERC 8
  • Remover o segundo expansor
  • Re-conecte as conexões internas do SAS
  • Rebaixe o chassi para 1,25 (funciona da mesma forma que a atualização, sem etapas especiais necessárias)
  • Excluir todos os VDs (dados de backup / VMs, se necessário)
  • Ciclo de energia inteiro VRTX (remova e reconecte os cabos de energia para ter certeza)
  • crie VD ('s) com write-back ativado

Para ver a diferença de desempenho, verifique este / meu thread em: link

Atualização:
Resultados do teste:
Dual PERC / RAID6 / Write Through: Leitura 2500 MB / s Escrita 200 MB / s
Dual PERC / RAID10 / Write Through: Leia 2500 MB / s de gravação 400 MB / s
Único PERC / RAID6 / Write Voltar: Ler 2500 MB / s Escrever 2700 MB / s

Desde que o Dual PERC esteja vinculado à política Write Through, eu ficaria com uma configuração Single PERC

    

Answer 2

Este :

Fault Tolerant Shared PERC 8 Card Configuration — [...] The default cache policy for virtual disks created in this configuration is write-through. In this mode, write completion information is returned to the host after the data is written to the disk.

é o matador de desempenho final. Altere a política de cache para write-back se ela for suportada por seu aplicativo e não resultar em possíveis inconsistências nos dados gravados. Note que não tenho idéia se e por qual mecanismo o cache PERC8 está sendo espelhado para a outra instância. Como os dados em cache precisam ser acessíveis a partir de ambos os controladores, obviamente seria necessário para consistência.

    

Answer 3

Não é mais necessário remover o segundo controlador SPERC para poder usar write-back em vez de write-through, conforme descrito na postagem de Erik. Agora você pode desativar o segundo controlador PERC8 do CMC. No firmware atual (1.35), o segundo controlador desativado pode ser configurado como desativado e requer intervenção manual para ativar se o controlador ativo primário falhar. A utilidade disso não é realmente detalhada nas notas de correção, mas essa "correção" destina-se a permitir que as pessoas ativem o Write-Back e se livrem do desempenho abismal que você tem ao usar os dois controladores no Write-Through.

O failover automático (failover a frio, causando desconexão) é um recurso que será lançado posteriormente. Muito mais tarde, será a atualização do firmware "ativo / ativo", que permitiria failover "ao vivo" sem tempo de inatividade.

Etapas:

1. Faça o download do firmware do VRTX CMC versão 1.35 ou superior.
2. Encerre todas as suas lâminas.
3. Na interface do CMC, pressione "Visão geral do chassi > Atualizar".
4. Selecione as duas caixas de seleção para os controladores CMC no cabeçalho "CMC firmware" e pressione "Apply CMC Update".
5. Insira o local do arquivo de firmware do CMC e aplique-o.
6. O CMC mostrará seu progresso. O upload leva cerca de 8 minutos, aplicando a atualização por mais alguns minutos. Os CMCs serão reiniciados após a aplicação da atualização e você será expulso da interface web.
7. Após a reinicialização do CMC, navegue até a seção "Storage > Controllers > Troubleshooting".
8. Para o SPERC de sua escolha, selecione a opção "Disable RAID controller" e aplique. Isso reinicializará seu componente de armazenamento.
9. Após a reinicialização, vá para "Armazenamento > Discos virtuais > Gerenciar" e selecione "Editar: Gravar política" e escolha "Gravar atrás" em vez de "Gravar" para todos os seus discos virtuais (a menos que você tenha um motivo não para).
10. A alteração acima será executada imediatamente, mas ainda é sugerido que redefina o CMC novamente em "Visão geral do chassi > Energia > Controle" com "Redefinir CMC (inicialização a quente)".
11. Inicialize suas lâminas de desligamento.

Isso permitirá que você tenha um segundo PERC8 instalado no seu VRTX, caso o outro falhe. Mas você terá que fazer uma intervenção manual para failover em caso de falha. Suponho que isso seja destinado principalmente a locais de difícil acesso (escritórios remotos sem equipe de TI ou acesso fácil aos técnicos de suporte da Dell). Este é também o que usamos para isso.

Espero que até o final do ano tenhamos o recurso de failover automático e, no decorrer do próximo ano, a configuração ativa / ativa real com write-back ativado (caches sincronizados). Eu não vou segurar o fôlego pela correção do firmware do cache sincronizado ... Eu suspeito que não será fácil para a Dell.