Cluster de balanceamento de carga de rede para servidores de hub DFSR?

1

Eu tenho um servidor de hub DFSR com cerca de 80 conexões para 80 escritórios remotos.

Eu quero adicionar outro servidor de hub para balanceamento de carga e redundância, mas não quero dividir as conexões entre os dois servidores de hub. Não gosto da idéia de ter que manter \ administrar dois blocos diferentes de conexões em dois servidores.

editar As práticas recomendadas da Microsoft dizem dividir as conexões do DFSR entre vários servidores (se houver muitas conexões de alto volume, como em uma topologia de hub e spoke), porque muitas conexões simultâneas com um servidor podem causar problemas de desempenho. A única recomendação é dividir manualmente as conexões entre os servidores. Eu preferiria ter vários servidores de hub configurados da mesma forma (todos os hubs configurados com conexões para todos os escritórios remotos) e ter algo como o serviço NLB dividir as conexões automaticamente para mim.

O que eu quero é ter 2 (ou possivelmente mais) servidores de hub, cada um configurado com todas as 80 conexões estranhas, fazendo balanceamento de carga com algo como o serviço NLB. Suponho que isso funcionaria porque os hubs do DFSR poderiam dividir dinamicamente as conexões entre eles e apenas replicar as atualizações recebidas em uma das suas conexões com o outro hub.

Eu sei que você pode fazer um cluster DFSR de failover, mas pelo que li, um cluster de failover do Windows não faz o balanceamento de carga. Portanto, apenas um nó em um cluster de failover do DFSR está realmente ativo por vez - isso está correto? Se assim for, não parece satisfazer meus requisitos para balanceamento de carga.

Não encontrei documentos relacionados à configuração de um cluster NLB com o serviço DFSR. Isso é possível? Em caso afirmativo, alguém pode fornecer informações sobre uma forma de práticas recomendadas para fazer isso ou um documento?

Se um cluster NLB não for possível, há uma maneira de fazer como um round robin de DNS com registros DNS SVR ou possivelmente algum tipo de configuração de balanceamento de carga de "front-end".

Muito obrigado.

** editar Eu acho que eu estava apenas procurando por um set e esquecer a configuração. O hub único está lidando com tudo bem por enquanto, mas estamos planejando adicionar à nossa infraestrutura de DFSR.

Eu acho que vou ter que decidir se devo manter um hub e fazer um cluster de failover com um segundo, ou separar as conexões para um segundo hub.

Acho que vou fazer um único hub com um cluster de failover por enquanto. Então, se eu decidir dividir as conexões no futuro, sempre poderei adicionar outro cluster de failover (exigindo mais 2 servidores físicos) e dividir as conexões entre dois clusters de failover. Mais complexidade do que eu queria, mas acho que é o único jeito.

    
por red888 17.09.2013 / 16:09

2 respostas

1

Isso não pode ser feito. Como a topologia do DFS-R é armazenada no Active Directory, não é possível configurar membros do grupo de replicação para usar o nome / endereço do cluster de NLB ou qualquer outro tipo de balanceador de carga. Se você precisar de uma topologia de replicação customizada como descreve com um hub duplo por motivos de desempenho, será necessário configurá-la manualmente. O DFS na escala que você está descrevendo pode se tornar muito complexo e precisará de gerenciamento proativo. Não há "definir e esquecer" nesse tamanho, infelizmente.

    
por 18.09.2013 / 04:38
0

Talvez eu não tenha entendido completamente seu caso de uso aqui. Mas deixe-me dar uma facada, já que ninguém mais respondeu.

Suponho que você tenha 80 escritórios, cada um com um único conjunto de replicação para conversar com seu hub. Como você pode definir o "membro de envio" no DFSR, você deve ser capaz de adicionar outro servidor para fornecer os dados replicados aos servidores remotos. É o que é chamado de "replicação mutli-master"

Portanto, se você tivesse dois servidores DFSR "hub" (ou qualquer número para esse assunto), eles precisariam estar no grupo de replicação. Uma vez configurado, os servidores de "conexões remotas" precisariam apontar para todos os servidores "hub" e seriam capazes de replicar sob demanda conforme necessário. Eles simplesmente sincronizariam com o primeiro servidor disponível.

Uma coisa que você precisa resolver é garantir que os controles remotos não tentem sincronizar os dados novamente com os "hubs de host". Sites e serviços precisariam ser configurados corretamente para resolver isso.

Eu senti falta do que você estava perguntando?

    
por 18.09.2013 / 01:04