Problema de desempenho do servidor de arquivos de cluster de failover com o Windows Server 2016

Question

Eu me deparei com um problema de desempenho de velocidade de transferência do servidor de arquivos com um cluster de failover que configurei recentemente no Server 2016. O problema específico é que quando eu acesso o compartilhamento de arquivo do caminho de armazenamento clusterizado (por exemplo, \\ store01 \ share01 ) velocidade de transferência de arquivos (escreve em particular, parece) é maneira, caminho mais lento do que quando eu acessá-lo através do caminho local no nó proprietário atual (por exemplo, \\ srv04 \ e $ \ Shares \ Share01 ).

Por exemplo, eu copiei 499 arquivos .txt (totalizando 26,07 MB) usando o Robocopy:

• \\ srv04 \ e $ \ Shares \ Share01: 0: 0: 03 - 635 MB / min

• \\ store01 \ share01: 0:02:20 - 11.286 MB / min

Este é um problema, independentemente do nó do proprietário atual ou de onde os dados são transferidos. Embora eu não tenha seguido isso na época, eu mais ou menos instalei e configurei o serviço conforme indicado em este guia . Eu tentei brincar com algumas configurações, mas elas estão de volta ao padrão (até onde eu sei). Eu olhei em volta um pouco e não encontrei nada especificamente mencionando um problema de desempenho enorme com o uso de um cluster de failover, então eu tenho feito algumas pesquisas aleatórias sem muito para mostrar isso.

Poucas coisas sobre a configuração que podem ser relevantes:

• O cluster atualmente possui dois nós. Ambos estão executando o Server 2016 e ambos possuem duas Equipes de Nic (configuradas no Windows, Switch Independent) consistindo de duas conexões de 1Gbit cada.
• O armazenamento real em uso é um Synology que as duas máquinas estão acessando via iSCSI, configurado usando estas instruções .
• Todo o resto parece funcionar bem, da mesma forma que a simulação de um failover funciona e o outro nó ocorre alguns segundos depois.

Eu estou supondo que este é um daqueles "óbvios para qualquer um que saiba mais do que eu". Ou talvez eu esteja apenas esperando por isso. De qualquer forma, agradeço qualquer orientação! Tentei mantê-lo curto, por favor, deixe-me saber se você precisar de alguma outra informação.

Obrigado antecipadamente.

    

Answer 1

Após remover o agrupamento de NICs e colocar as conexões no Synology / Server em uma sub-rede diferente para uma boa medida, ainda não vi nenhuma melhoria de desempenho.

Eu finalmente encontrei a solução, no entanto. Acontece que a Disponibilidade Contínua está ativada (o padrão) para o compartilhamento foi o culpado. Há documentação que diz que pode causar uma penalidade de desempenho "leve" ( como aqui devido a ignorar o cache de gravação, parece que em alguns casos a penalidade de desempenho "leve" é na verdade "gigantesca". Veja uma artigo que entra em um contexto bastante útil sobre a Disponibilidade Contínua e quando você pode usá-lo (para resumir, talvez você queira desativá-lo se o seu compartilhamento estiver configurado para" Servidor de Arquivos de Uso Geral "e você está preocupado com o desempenho).

Então, para resumir a história, desativei Continuous Availability no compartilhamento que está sendo usado pelo cluster, reiniciei os dois servidores para uma boa medida e o problema de desempenho foi resolvido. Embora eu prefira garantir a integridade dos dados durante um evento de failover, eles serão tão poucos e distantes no meu ambiente que não há dúvidas de que a penalidade de desempenho não valeu a pena.

    

Answer 2

Seu primeiro problema são as NICs unidas pelo iSCSI. Você nunca faz isso, a menos que o seu destino e o inicializador suportem várias conexões por sessão e, no seu caso, nenhum deles o faz.

link

Solução: você precisa desassociar suas NICs e usar o MPIO.

Seu segundo problema é a própria Synology. Não é o que você usa para armazenamento primário, mas sim a unidade de backup.

Solução: você copia seu conteúdo para discos locais e usa o Synology como repositório de backup ou o que for.