Aumentar a largura de banda da rede no Windows Server 2008 R2

Question

Estou cuidando dessa rede com cerca de 40 clientes em um servidor Windows 2008 R2. Esses clientes estão conectados ao servidor por meio de dois switches gigabit (switches mudo de 24 portas). Nos próximos meses, o número de clientes vai aumentar. Vamos dizer que queremos planejar até 100 clientes.

O tráfego de rede já é alto e às vezes fica realmente entupido. Meu objetivo é dobrar a largura de banda da rede no futuro próximo e quadruplicar o mesmo quando adquirirmos um novo hardware de servidor.

Obviamente, isso exigiria várias placas NIC ou NIC com várias portas Ethernet. Estes são os meus pensamentos sobre opções / limitações:

1. Eu li que o Windows Server 2012 possui o recurso de agrupamento de NICs incorporado. No entanto, isso não é de todo viável, pois o custo de licenciamento (servidor + CAL) seria muito alto. Além disso, isso não pode ser um motivo para atualizar o software do servidor.

2. Vá com vários NIC sem o LACP / teaming. Cada NIC terá que estar em uma sub-rede separada porque o Windows Server não funciona muito bem quando duas de suas NICs estão na mesma sub-rede. Cada NIC conectará a um switch diferente e, consequentemente, esses clientes estarão em sub-redes diferentes. Enquanto isso aumentará a largura de banda total do servidor, ele também adicionará algumas complexidades na configuração da rede (roteamento, DHCP, DNS, firewall, etc.) Você pode me convencer do contrário?

3. Descarte os interruptores mudos existentes e escolha algo melhor. A Netgear oferece opções "não gerenciadas plus" que apresentam LACP / LAG. Cada switch de 24 portas (configuração de porta mais alta) custa cerca de Rs. 20k (~ US $ 350) na Índia, então quatro opções desse tipo nos custarão cerca de Rs. 80k (~ US $ 1400). Mas acho que ainda seria melhor do que substituir o próprio Windows Server. Isso pode ser uma espécie de último recurso.

4. Eu li que certas placas NIC de classe de servidor (como as da Intel) podem oferecer agrupamento / agrupamento baseado em driver mesmo se o sistema operacional do servidor ou o switch não suportar esse recurso. Eu fiz algumas pesquisas e a maioria dos resultados são sobre Linux e FreeNAS etc., então não tenho certeza se isso funciona no ambiente Windows. Se isso é realmente uma opção viável, é minha melhor aposta no futuro próximo. Alguém pode compartilhar sua experiência com esse tipo de configuração e sugerir qualquer modelo de NIC específico para seguir?

Além disso, posso tentar algum tipo de otimização de rede. Atualmente, todos os clientes estão conectados diretamente ao switch. O que posso fazer é introduzir alguns pequenos comutadores entre um grupo de clientes e conectar esses pequenos comutadores aos comutadores principais. Mas não tenho certeza se isso vai funcionar para mim porque o tráfego é na maior parte real e tudo envolve o servidor. Não há muita coisa acontecendo entre os clientes. O servidor está sendo usado principalmente como servidor de arquivos.

Quais são seus pensamentos? Estou faltando alguma coisa aqui?

    

Answer 1

Primeira pergunta:
Quais são as métricas medidas usadas para determinar sua utilização (isto é: o que é "alto" e "entupido"? Estou assumindo que isso foi feito no servidor apenas porque você não pode extrair estatísticas de switches não gerenciados.

Segundo:

• Eu ficaria longe de várias nics em diferentes sub-redes no servidor.
• Eu ficaria longe da opção "introduzir alguns pequenos comutadores"
• Eu definitivamente atualizaria os switches. Também recomendaria contra os switches NetGear. A maioria dos switches não gerenciados e os "switches corporativos" da Netgear têm buffer limitado e ainda sofrem com problemas de desempenho
• A maioria das NICs modernas no espaço do servidor podem fazer alguma forma de agrupamento de rede / ligação com base no conjunto de software de drivers. Quase todos eles funcionam bem no Windows. O BACS (Broadcom Advanced Control Suite) e o Intel ACS (Advanced Network Services) são dois dos mais comuns.

edite para responder ao seu comentário abaixo, pois a minha resposta foi longa demais para um comentário:

Minha pergunta foi tentar determinar por que você supõe que sua utilização de rede já é "alta" e "entupida". Se o seu problema real é uma falha de projeto (loops de rede, etc), um problema de configuração (velocidade / duplex, etc), ou um problema com os switches (buffer overruns / dropped packets / etc), fornecendo mais largura de banda ao servidor te ajudar. Com o seu hardware atual, é difícil restringir especificamente onde está o seu problema.

De onde você tirou seu rastro? Um traço de wireshark que você diz não mostrar nada incomum não é prova de que seu "tráfego de rede" já está alto ou ficando "entupido". E não ser muito duro, mas você sabe o que está procurando no traço? Com base na sua pergunta e na sua linha de pensamento atual, não sei onde está seu nível de conhecimento na solução de problemas de um rastreamento de rede para ver se há problemas.

A execução de contadores perfmon na NIC do servidor fornecerá uma imagem melhor da utilização na NIC do servidor e será apenas a primeira indicação de que mais largura de banda para o servidor pode ser útil. Mas você não disse se executou esses contadores ou não.

Por último, a maioria dos softwares de driver pode fazer alguma forma de agrupamento de rede com praticamente qualquer switch (incluindo swtiches não gerenciados). Geralmente, você está limitado apenas ao failover direto ou ao balanceamento de carga de transmissão. O failover é exatamente o que parece. Apenas uma NIC é usada até que uma falha seja detectada e, em seguida, falha na outra NIC. O balanceamento de carga de transmissão só carregará o tráfego de saída do sistema. O tráfego de entrada ainda é geralmente limitado a uma única NIC. Acredito que a Broadcom pode fazer o SLB (Smart Load Balancing) onde tenta fazer um balanceamento de carga limitado através de ARPs gratuitos, mas nunca usei muito. A agregação completa do LaCP exigirá que o switch ofereça suporte a ele. Há mais do que tudo isso, mas isso não é uma questão sobre os tipos de agrupamento de NICs e suporte.