Desafios e práticas recomendadas para falhar sobre os serviços

Question

Alguém conhece alguma prática melhor estabelecida para a execução de serviços do Windows (no meu caso, desenvolvido no .NET), de modo que eles (automaticamente) falhem corretamente em outro servidor, para fins de alta disponibilidade?

As principais maneiras pelas quais posso ver isso sendo feito estão iniciando o servidor secundário quando necessário (nesse caso, é necessário que haja algo monitorando o outro servidor) ou com os dois serviços em execução juntos (nesse caso, eles precisam sincronizar seu trabalho, então Eles não tentam fazer as mesmas coisas).

Existe um padrão ou modelo para esse tipo de problema? Sei que a situação exata fará uma grande diferença, mas parece um problema bastante comum.

Obrigado

John

Answer 1

Aqui está o que funcionou para mim.

Do ponto de vista da infraestrutura, você precisará ter 2 servidores Windows que estão agrupados. (2 caixas de servidor Windows padrão, a peça de agrupamento pode ser instalada e configurada, a maioria dos administradores do SYS deve saber como fazer isso.) Em seguida, instale seu serviço nos dois nós do cluster e tiverem desligados e definidos para manual comece. Em seguida, adicione um recurso em cluster ao administrador do cluster do Windows para o seu serviço que gerenciará e desativarão o serviço em que o nó estiver ativo. Deixe o cluster do Windows gerenciar quando seu serviço estiver em execução e em qual nó. Esta é a parte mais fácil de agrupar seu serviço.

Do ponto de vista do serviço, você desejará projetar seu serviço para que possa ser o mais apátrida possível. Este é um conselho coxo, mas realmente depende do que seu serviço está fazendo. No design, basta supor que, em algum ponto durante a vida útil do código, ele parará no pior momento possível. Como o serviço no Node2 saberá onde pegar onde o Node1 parou? Essa é a parte difícil para a qual você precisa projetar. Dependendo do que seu serviço está fazendo, você pode deixar a última tarefa concluída em uma tabela DB ou arquivo de dados compartilhado. Você também pode começar a partir do início e verificar se essa tarefa foi concluída ou não antes de agir sobre ele.

Novamente, isso realmente dependerá do que o serviço precisa realizar. Espero que isto ajude.

Answer 2

Ter dois funcionando o tempo todo é provavelmente a solução mais simples, mas você precisa garantir que nunca ultrapasse a carga de 50%; caso contrário, quando um falhar, o outro ficará sobrecarregado e talvez também falhe.

Para sincronizar, use um banco de dados transacional. Tentar escrever sua própria sincronização geralmente resultará em bugs.

Answer 3

Se você pode ter os dois serviços funcionando - é melhor. Você precisa ter certeza de que eles estão sem estado ou sabem como lidar com a questão do estado, e o banco de dados será sincronizado entre eles. Em um ponto de falha sem um único - você levará o problema ao banco de dados, e lá você pode ter um cluster ativo ativo de 2 nós e deixar a fabricação de banco de dados lidar com os problemas de sincronização.

Answer 4

Acredito que a melhor maneira de lidar com o failover está no nível da rede sempre que possível. Os IPS virtuais de frente para os ambientes de carga balanceada ou primária/failover é uma boa maneira de evitar escrever código para cenários de failover.

Nos casos em que você deve lidar com o failover no código:

1. Teste Conexão/Chamada de Serviço
2. Se o teste falhar, envie alertas
3. Falha no ponto final do serviço "registrado" "registrado"

Answer 5

Existem duas abordagens básicas.

1. Os clientes estão cientes do endereço e do interruptor diferentes, conforme necessário ou conforme indicado por outro mecanismo de serviço ou configuração. (como exemplo o Aplicação de demonstração do Stocktrader isso faz isso.)

2. Os clientes não estão cientes e você usa uma abordagem padrão de balanceamento de carga de rede que também pode fornecer failover. F5 é um produto. Existem muitos outros. É basicamente como um NAT para serviços, todas as solicitações passam pelo seu NLB e as envia para um servidor e encaminha a resposta de volta ao chamador. Esses produtos monitoram os serviços e usam apenas os que estão em alta. Além disso, você pode personalizá -lo com regras para atribuir novas solicitações aos servidores com base nas cargas de trabalho do servidor. O Windows Server tem isso funcionalidade integrada até certo ponto.

De qualquer maneira, você faz isso, é muito mais fácil se suas chamadas de serviço estiverem "sem estado".