Compartilhamento de rede no cluster de servidor de arquivos sendo interrompido

Question

Quando executo operações pesadas de disco, como excluir 10k arquivos por vez, o compartilhamento de rede não responde e não exibe arquivos por um curto período de tempo.

Aqui está minha configuração. Eu tenho um cluster de servidor de arquivos de failover composto por dois servidores Windows 2008 R2 Enterprise. Cada servidor é uma VM em execução em dois servidores Dell Poweredge independentes que executam o Windows Hyper-V. Ambos os servidores da Dell possuem NICs dedicados a uma SAN Dell MD3000i. Cada uma das VMs do servidor de arquivos roteia suas conexões iSCSI por meio dessa NIC dedicada para sua conexão com o volume na SAN em que os arquivos residem.

Se eu executar um arquivo em lote que executa 10k exclusões de um computador remoto que referencia o arquivo por nome de compartilhamento (por exemplo, \\ fileserver \ sharename \ folder \ filename.jpg), ele pode fazer 1.000 ou 8.000 exclusões antes do compartilhamento dá para fora. É aleatório a cada vez. Ironicamente, o arquivo em lote continuará excluindo os arquivos, mas outros servidores que acessam arquivos nesse mesmo compartilhamento ficarão retidos. Os arquivos que estou excluindo não seriam acessados por outros servidores, portanto, o bloqueio desses arquivos específicos não é um problema.

Se eu executar o mesmo arquivo de lote no servidor mestre do cluster de arquivos e referenciar os arquivos por seu caminho local (ou seja, x: \ folder \ filename.jpg), o compartilhamento será eliminado imediatamente e os outros servidores ficarão esperar. O acesso a esse compartilhamento será retomado quando eu terminar o arquivo de lote em execução.

Alguém tem uma idéia da causa do corte de compartilhamento ou o que eu poderia fazer para diagnosticar ainda mais essa questão? Qualquer sugestão é muito apreciada.

Nota atualizada: Eu isolei esse problema para ocorrer apenas dentro dos limites da caixa do host. Nenhum dos tráfegos de rede envolvidos para replicar esse problema com as VMs atinge o comutador físico ao qual a caixa de host se conecta, além da conexão iSCSI com a SAN. A conexão iSCSI tem seu próprio switch dedicado e sua sub-rede privada para o SAN, fora do tráfego de rede padrão.

    

Answer 1

Isso grita esgotamento de recursos de algum tipo. Se este fosse um host Linux, eu estaria pensando: "isso soa como uma carga de IO-Wait". Verifique os monitores de desempenho do nível do sistema operacional como mfinni apontado. Você tem duas áreas que podem ser de garrafa, e isso é o desempenho do disco lógico / físico e o desempenho da rede na conexão de rede iSCSI. PerfMon pode lhe dar isso. Eu não conheço o HyperV, mas se é algo parecido com o VMWare, você tem algumas métricas de desempenho no lado do Hypervisor que você pode ver também. Faça isso.

Como uma teoria , meu palpite é que o nível muito alto de atualizações de metadados que você está fazendo está causando uma latência inerente na sua pilha iSCSI para ampliar. Isso, por sua vez, elimina outras solicitações de E / S ou de metadados, o que resulta nos sintomas que você descreve, outros processos podem obter uma palavra no meio, já que os blocos da MFT estão sendo martelados por esse outro processo. O próprio iSCSI pode causar isso, mas a camada da VM provavelmente está adicionando seus próprios atrasos internos. Se esse for realmente o problema, convém considerar a apresentação do iSCSI LUN ao hipervisor e apresentá-lo à VM; Dessa forma, você não está contando com um adaptador de rede virtualizado para iSCSI, mas sim com um físico.

Editar: Parece que você provavelmente tem esse tipo de falha em suas mãos. Os contadores do PerfMon aos quais presto atenção são "Bytes enviados / s" e "Pacotes enviados / s" para a interface que executa a conexão iSCSI. A combinação dos dois deve dar-lhe o tamanho médio do pacote. (alternadamente, se você tiver a habilidade, lançar um sniffer no loop e ver como os pacotes se parecem no switch de rede. Este é o método mais confiável se você puder fazer isso) Se o tamanho do pacote for bem pequeno (digamos, sob 800 bytes), então não há muito o que fazer sobre isso além de descer para o nível TCP e ver que tipo de otimizações podem ser feitas entre os nós do cluster e o destino iSCSI. O Server 2008 é exigente com suas configurações de TCP, portanto, pode haver ganhos a serem feitos aqui.

    

Answer 2

Bom senhor. Existe alguma coisa no visualizador de eventos para indicar que o sistema operacional está vendo algum tipo de esgotamento de recursos? Você pode inspecionar com perfmon?