Serviços Windows - cenários de alta disponibilidade e abordagem de design

Question

Digamos que eu tenha um serviço Windows independente em uma máquina do Windows Server. Como garantir que esteja altamente disponível?

1). Quais são todas as diretrizes de nível de design que você pode propor?

2). Como torná -lo altamente disponível, como primário/secundário, por exemplo, as soluções de agrupamento atualmente disponíveis no mercado

3). Como lidar com preocupações cruzadas, caso qualquer cenário de falha

Se qualquer outro você pode pensar, adicione aqui ..

Observação:A questão está relacionada apenas aos serviços do Windows e Windows, tente obedecer a esta regra :)

Answer 1

Para manter o serviço pelo menos em execução, você pode providenciar o gerenciador de serviços do Windows para reiniciar automaticamente o serviço se ele travar (consulte a guia de recuperação nas propriedades do serviço.) Mais detalhes estão disponíveis aqui, incluindo um script em lote para definir essas propriedades - Reinicie um serviço do Windows se ele travar

A alta disponibilidade é mais do que apenas manter o serviço de fora- o próprio serviço precisa ser construído com alta abordagem em mente (ou seja, use boas práticas de programação durante toda a parte, datraucturas apropriadas, pares de recursos e liberação) e todo o estresse- testado para garantir que ele permanecerá sob cargas esperadas.

Para comandos idempotentes, a toleração de falhas intermitentes (como recursos bloqueados) pode ser alcançada reinvando o comando um certo número de vezes. Isso permite que o serviço proteja o cliente da falha (até certo ponto.) O cliente também deve ser codificado para antecipar a falha. O cliente pode lidar com falhas de serviço de várias maneiras - registrar o log, levando o usuário, repetindo x vezes, registrando um erro fatal e saída são todos os manipuladores possíveis - o que é adequado para você depende de seus requisitos. Se o serviço tiver "estado de conversa", quando o serviço falhar (ou seja, o processo é reiniciado), o cliente deve estar ciente e lidar com essa situação, pois geralmente significa que o estado de conversação atual foi perdido.

Uma única máquina será vulnerável à falha de hardware; portanto, se você quiser usar uma única máquina, verifique se ela possui componentes redundantes. Os HDDs são particularmente propensos a falhas, por isso, pelo menos as unidades espelhadas ou uma matriz de ataque. As PSUs são o próximo ponto fraco, portanto, a PSU redundante também vale a pena, assim como um UPS.

Quanto ao clustering, o Windows suporta cluster de serviço e gerencia serviços usando um nome de rede, em vez de nomes individuais de computadores. Isso permite que seu cliente se conecte a qualquer máquina executando o serviço e não um nome codificado. Mas, a menos que você tome medidas adicionais, isso é de failover de recursos - direcionando solicitações de uma instância do serviço para outro. O estado de ConverStaion geralmente é perdido. Se seus serviços estiverem escrevendo em um banco de dados, isso também deve ser agrupado para garantir a confiabilidade e garantir que as alterações estejam disponíveis para todo o cluster, e não apenas o nó local.

Esta é realmente apenas a ponta do iceberg, mas espero que isso lhe dê idéias para começar em pesquisas mais aprofundadas.

Serviço de Clustering da Microsoft (MSCs)

Answer 2

Se você quebrar os problemas que está tentando resolver, acho que provavelmente apresentará algumas respostas. Como Justin mencionou no comentário, não há uma resposta. Depende completamente do que seu serviço faz e de como os clientes o usam. Você também não especifica detalhes sobre a interatividade do cliente-servidor. Http? TCP? UDP? Outro?

Aqui estão algumas coisas para pensar em você começar.

1) O que você faz se o serviço ou servidor cair?

• Que tal Run mais de uma instância do seu serviço em servidores separados?

2) OK, mas agora como os clientes sabem sobre os vários serviços?

• Você pode codificar a lista em cada cliente (não recomendado)
• Você pode usar o DNS Round-Robin para rejeitar solicitações em todos eles.
• Você pode usar um dispositivo de balanceamento de carga.
• Você pode ter um serviço separado que conhece todos os outros serviços e pode direcionar os clientes para os serviços disponíveis.

3) E se um serviço cair?

• Os aplicativos do cliente sabem o que fazer se o serviço com o qual estiverem conectados caírem? Caso contrário, eles precisam ser atualizados para lidar com essa situação.

Isso deve começar com a idéia básica de como começar com alta disponibilidade. Se você fornecer detalhes específicos sobre sua arquitetura, provavelmente obterá uma resposta muito melhor.

Answer 3

Se o serviço não expor nenhuma interface para a conectividade do cliente, você pode:

• Transmitir ou expor uma mensagem "I'm Alive" ou sinalizar um banco de dados/registro/tcp/o que quer que você esteja vivo

• Tenha um segundo serviço (monitor) que verifique esses sinais "estou vivo" e tente reiniciar o serviço, caso esteja inativo

Mas se você tiver um cliente conectando a esse serviço através do nome Nomepipes/TCP/etc, o cliente precisaria verificar o endereço da máquina com o serviço em execução em um banco de dados ou ter algo mais sofisticado como uma mudança inteligente para redirecionar o tráfego.