Desempenho da cópia de arquivo do Volume Compartilhado do Cluster da SAN

Question

Espero que alguém possa me ajudar com um problema estranho.

Estamos executando um cluster de failover da Microsoft com o Server 2008 R2 e uma SAN Equallogic PS4000. Nossa configuração principal possui 2 servidores Dell Poweredge T710 no cluster. Nós temos a configuração CSV e Quorm. Cada um dos servidores possui 10 NIC Broadcom 1Gb. Atualmente, 4 dos NICS estão na rede iSCSI para acessar a SAN. Eles usam o MPIO e o pacote Dell HIT.

Temos 5 VMs em execução em cada nó e tudo funciona bem. Nenhum problema de desempenho perceptível ou qualquer coisa. A partir do SAN, posso ver as 4 conexões iSCSI de cada servidor para cada volume (CSV e Quorm). Mais uma vez, parece ter um ótimo desempenho.

O problema que estou encontrando é com backups. Eu tentei alguns programas de backup como backupchain e Veeam. O problema é que ambos são muito lentos para fazer backup das VMs. Por exemplo, tenho um VHD de 500 GB (disco fixo) em execução no cluster. São necessárias mais de 18 horas para fazer backup desse VHD e isso é com a compactação e o depuping desativados, o que supostamente é o jejum.

Também temos um servidor separado, apenas para backups. Tem um monte de armazenamento anexado direcionado. Como parte da solução de problemas, decidi trazer esse servidor para o cluster como um nó. Agora ele tem acesso ao CSV e pode ler em C: \ clusterstorage \ volume1, que é onde nossos VHDs residem. Este servidor de backup possui apenas 2 NICs. 1 NIC está indo para a rede iSCSI e o outro é apenas na rede principal. Ele tem o Intel NICS sem qualquer tipo de MPIO ou agrupamento.

Então, com o terceiro servidor agora no cluster, comecei a fazer alguns benchmarking. Eu tenho um teste de VHD que é de cerca de 7 GBs armazenado no CSV. Eu testei a cópia de arquivos que o VHD de todos os 3 servidores para o armazenamento anexado direcionado no respectivo servidor. Os dois servidores Dell que são os nós principais no cluster (eles abrigam as VMs) estão lendo esse arquivo a cerca de 20Mbs / seg. Que nessa taxa é a maneira de retardar os backups. O outro servidor que tem apenas 1 NIC para a SAN está lendo em torno de 100Mbs / s.

Eu passei algumas horas no telefone com a Dell hoje sobre isso. Nós passamos por todos os tipos de testes e ele foi muito burro. Ele realmente não tem idéia de por que esse servidor com apenas 1 NIC está lendo cerca de 5 vezes mais rápido que os servidores com 4 NICS e MPIO.

Analisamos a utilização da rede das NICs enquanto a cópia do arquivo estava em andamento. Os servidores com as 4 NICs tiveram um pequeno aumento de atividade durante a cópia do arquivo, mas eles subiram apenas cerca de 8-10% em todas as 4 NICs. O outro servidor com o 1 NIC pulou para mais de 80% durante a cópia do arquivo.

Eu planejo fazer mais testes depois do expediente e ligarei para a Dell amanhã, mas estou realmente confuso (e também o representante de suporte da Dell) porque não consigo acesso mais rápido a cópia de arquivo para o CSV nesses servidores.

Alguém tem alguma opinião sobre isso? Qualquer feedback seria muito apreciado.

Obrigado antecipadamente.

    

Answer 1

Com as informações fornecidas, parece que o processo de backup está colocando o CSV no modo Redirecionado de acesso . Pode ser que o seu software de backup não esteja ciente do CSV e tente acessar os arquivos VHD por meio de um servidor que não possui os recursos.

Você deve conseguir verificar isso visualizando os CSVs no Gerenciador de Cluster de Failover em Armazenamento.

Se esse for o caso, eu entrarei em contato com a Veeam para saber como eles recomendam a realização de backups em cluster do Hyper-V.

Mais informações sobre acesso redirecionado estão disponíveis aqui: link

    

Answer 2

Isso soa como uma configuração MPIO mal configurada para mim. É impossível identificar o problema exato sem gastar horas em seu site, mas aqui estão algumas dicas para conferir:

• Como o Equallogic é configurado para apresentar o (s) LUN (s)? Está fazendo ativo / passivo ou ativo / ativo? Está usando o ALUA? Se não for ALUA, talvez você esteja passando por uma lixeira de caminho, que irá dobrar uma SAN nos joelhos durante uma E / S intensa.
• Você está usando quadros jumbo? Se sim (ou se você não souber) - verifique a SAN, o (s) switch (es) e o (s) nic (s) em TODOS os dispositivos para certificar-se de que a configuração da MTU é idêntica em todos os lugares

Todo fornecedor de SAN respeitado fornece as práticas recomendadas para diferentes cenários de uso. Você deve conseguir encontrar um para o MPIO no Windows com o iSCSI.