Vantagem do Microsoft Cluster sobre o balanceador de carga de rede da Microsoft

1

Até recentemente, presumi que o Microsoft NLB funcionava em um nível de sistema operacional em vez de em nível de aplicativo. Ou seja, o NLB apenas monitora as pulsações na máquina para verificar se a máquina está ativa e, em seguida, desliga um nó específico se ele estiver inativo.

No entanto, encontrei este comentário em uma questão de falha de servidor que reivindica de forma diferente. Conforme o comentário

NLB just routes connections to the TCP port that is open. If your application closes the port then NLB won't route connections to it any more until the port is open again.

  1. O acima é verdadeiro? O NLB monitora aplicativos em um nível de porta?
  2. Se a resposta para (1) for "sim", ela será alternada para o serviço que está sendo desativado e também para o caso suspenso do serviço ou apenas para um desses casos?
  3. Se o NLB realmente faz todos os itens acima, qual é o caso de usar o Clustering? A única vantagem é que, para clustering, você não precisa de dados replicados. Mas o armazenamento em cluster geral seria a solução mais cara.
  4. As respostas para as perguntas acima serão diferentes para um produto padrão, como o MS SQL Server, em comparação com o meu próprio serviço ou será o mesmo?
  5. Se o NLB não fizer o acima e apenas fizer pulsações no nível do SO / Máquina, existe outra maneira além do cluster para fornecer HA e alternância para o meu próprio serviço?
por user93353 15.01.2013 / 05:39

1 resposta

2

Não é assim que o NLB funciona. A regra de porta NLB determina quais portas / portas são balanceadas por carga entre os hosts NLB. Tráfego não "vinculado" a uma regra de porta NLB não é balanceado de carga entre os hosts NLB. O NLB não monitora a porta / portas associadas a uma regra de porta e desabilita o tráfego de cluster NLB para esse host ao fechar essas / essas portas / portas ou o travamento de um aplicativo que fornece serviços nesses / aqueles porta / portas em um determinado host. O NLB usa uma "pulsação" da Camada 2 para determinar a disponibilidade de um host no cluster. Se um host falhar no mecanismo de heartbeat, todos os outros hosts "irão convergir" (ou convergir novamente) a remoção do host não-respondente do cluster, de forma que nenhum tráfego de cluster (baseado na regra de porta) seja direcionado para o host de resposta. O NLB é estritamente um mecanismo de balanceamento de carga da camada 3 (camada de rede). Não é um mecanismo de balanceamento de carga da camada 7 (camada de aplicação).

É perfeitamente normal ter um aplicativo suspenso em um host NLB (como HTTP ou RDP) definido em uma regra de porta NLB que ainda recebe tráfego NLB, embora o aplicativo não seja capaz de aceitar esse tráfego. Isso ocorre porque o NLB não está ciente de nada acima da camada 3.

    
por 15.01.2013 / 06:07