O SMB3 Multipathing pode ser ponderado pela política?

5

Considere uma configuração com dois servidores WS2012R2 idênticos. Ambos possuem placas de rede com quatro portas. Cada um tem uma NIC conectada a uma sub-rede compartilhada por outros servidores e, finalmente, acessível às máquinas clientes. As três portas restantes em cada servidor são "unidas em equipe" e conectadas a uma sub-rede diferente compartilhada apenas pelos dois servidores em questão. O que eu gostaria de ver é o tráfego SMB preferencialmente passando pelo caminho 3-nic mais rápido e recorrendo apenas ao caminho 1-nic mais congestionado, se necessário.

Posso confiar no balanceamento de carga do SMB3 para fazer a coisa certa aqui? Se não, posso aplicar algum tipo de ponderação semelhante ao custo de rota tcp / ip?

    
por Jeff Sacksteder 18.01.2014 / 04:11

1 resposta

3

Estou bastante à vontade para dizer que o produto "fará a coisa certa", mas não tenho um ambiente representativo para simular exatamente o que você está falando.

Para falar sobre isso tecnicamente, o diabo está em detalhes após os detalhes de comunicação dos computadores servidores de suas interfaces de rede por meio da API FSCTL_QUERY_NETWORK_INTERFACE_INFO . Essa negociação é realmente mostrada como um exemplo na seção 4.8 do [MS-SMB2]: Bloco de mensagens do servidor (SMB) ) Versões 2 e 3 do Protocolo . Infelizmente, a parte da especificação que conteria a lógica associada à seleção de conexão de rede diz apenas "O cliente seleciona qualquer par de interface de rede para estabelecer uma nova conexão ...". Há alguma nuance no protocolo de seleção de interface (que, de maneira útil, a Microsoft omitiu da especificação, embora eu suponha que alguém possa argumentar que esse comportamento está fora da especificação). Este artigo , por exemplo, descreve como "não-roteável" (leia-se: APIPA e endereços locais de link) não são usados para SMB multicanal.

Além dos endereços "não-roteaveis" descritos no artigo acima, isso realmente me faz pensar se existe uma suposição implícita no produto de que interfaces de rede arbitrárias em um par cliente / servidor são capazes de comunicação. (Isso pode muito bem ser um fracasso apenas esperando para ser extraído em alguns cenários excêntricos em que a filtragem / política de tráfego torna essa suposição falsa.) Eu acho que provavelmente há alguma preferência por interfaces na mesma sub-rede que a interface inicial. canal foi criado em. (Com certeza seria legal se a Microsoft publicasse esse comportamento!) (Eu vejo que eu não sou o apenas um que tenha pensado nisso , pelo menos ...)

Você pode fazer um Get-SmbMultichannelConnection da máquina para ver se a conexão multicanal SMB entre os servidores está sendo criada durante uma operação de cópia de longa duração. Adicione o argumento -IncludeNotSelected se você quiser ver os caminhos "não selecionados".

Você pode excluir conexões diretas de multicanais SMB com o cmdlet New-SmbMultichannelConstraint , mas isso não está ponderando a prioridade do canal, por si só - é apenas exclusão (que não é o que você está procurando).

Como um aparte: Suponho que você esteja usando a funcionalidade de agrupamento de NIC integrada no W2K12. Você pode querer verificar, com seus switches, se o algoritmo de hash do LACP (chamado de "Modo de balanceamento de carga" no Windows Server) escolhido é o ideal. Eu já vi algumas conversas sobre a mudança desse modo oferecendo maior taxa de transferência com switches diferentes.

    
por 18.01.2014 / 04:35