Windows Services - scénarios de haute disponibilité et une approche de conception

Question

Disons que j'ai un service Windows autonome fonctionnant dans une machine de serveur Windows. Comment assurez-vous qu'il est très disponible?

1). Quelles sont toutes les directives du niveau de la conception que vous pouvez proposer?

2). Comment le rendre hautement disponible comme primaire / secondaire, par exemple., Les solutions de clustering actuellement disponibles sur le marché

3). Comment traiter les questions transversales au cas où fail-over scénarios

Si un autre que vous pouvez penser s'il vous plaît ajouter ici ..

Remarque: La question ne concerne que les fenêtres et les services Windows, s'il vous plaît essayer d'obéir à cette règle:)

Answer 1

Pour maintenir le service au moins en cours d'exécution, vous pouvez prendre des dispositions pour le gestionnaire de services Windows pour redémarrer automatiquement le service si elle tombe en panne (voir l'onglet Récupération sur les propriétés du service.) Plus de détails sont disponibles ici, y compris un script batch pour définir ces propriétés - redémarrer un service windows si elle se bloque

La haute disponibilité est plus que maintenir le service à partir de l'extérieur - le service lui-même doit être construit avec haute availabiity à l'esprit (c.-à-utiliser les bonnes pratiques de programmation tout au long, datastructures appropriés, paires ressources Aquire et la libération), et testé stress tout pour qu'il reste sous les charges prévues.

Pour les commandes idempotents, tolérer des pannes intermittentes (comme les ressources verrouillées) peuvent être atteints en ré-invoquer la commande d'un certain nombre de fois. Cela permet au service de protéger le client de l'échec (jusqu'à un certain point.) Le client doit également être codé pour anticiper l'échec. Le client peut gérer l'échec des services de plusieurs façons - l'exploitation forestière, ce qui incite l'utilisateur, une nouvelle tentative X fois, l'enregistrement d'une erreur fatale et la sortie sont tous les gestionnaires possibles - dont l'un est bon pour vous dépend de vos besoins. Si le service a « état de conversation », lorsque le service ne dure (à savoir processus est redémarré), le client doit connaître et gérer ths situation, comme cela signifie généralement l'état de conversation en cours a été perdue.

Une seule machine va être vulnérable à une défaillance matérielle, donc si vous allez utiliser une seule machine, puis assurer qu'il a des composants redondants. Lecteurs de disque dur sont particulièrement sujettes à l'échec, donc au moins les disques miroir ou une matrice RAID. PSU sont le prochain point faible, PSU donc redondant est également utile, comme un onduleur.

En ce qui concerne le regroupement, Windows prend en charge le regroupement de services, et gérer les services en utilisant un nom de réseau, plutôt que d'ordinateurs individuels noms. Cela permet à votre client de se connecter à une machine exécutant le service et non un nom codé en dur. Mais à moins que vous prenez des mesures supplémentaires, ce basculement est des ressources - demandes dirigeant d'une instance du service à l'autre. état converstaion est généralement perdu. Si vos services sont en train d'écrire à une base de données, qui devrait également être regroupés aussi assurer reliabiity et assurer que les modifications sont à la disposition du cluster entier, et pas seulement le nœud local.

Ceci est vraiment que la pointe de l'iceberg, mais je l'espère, il vous donne des idées pour démarrer sur d'autres recherches.

Microsoft Clustering Services (MSCS)

Answer 2

Si vous décomposez les problèmes que vous essayez de résoudre, je pense que vous tomberez probablement avec quelques réponses vous-même. Comme Justin mentionné dans le commentaire, il n'y a pas de réponse. Cela dépend entièrement de ce que votre service fait et comment les clients utilisent. Vous pouvez aussi ne spécifiez pas de détails sur l'interactivité client-serveur. HTTP? TCP? UDP? Autre?

Voici quelques choses à penser pour vous lancer.

1) Que faites-vous si le service ou le serveur tombe en panne?

• Que diriez-vous courir plus d'une instance de votre service sur des serveurs distincts?

2) Ok, mais maintenant comment les clients connaissent les multiples services?

• Vous pouvez coder en dur la liste dans chaque client (non recommandé)
• Vous pouvez utiliser round-robin DNS pour rebondir les demandes dans tous.
• Vous pouvez utiliser un dispositif d'équilibrage de charge.
• Vous pouvez avoir un service distinct qui connaît tous les autres services et peut diriger les clients vers les services disponibles.

3) Alors, que si l'on descend le service?

• Bougez les applications clientes savent ce qu'il faut faire si le service qu'ils sont connectés à descend? Dans le cas contraire, ils doivent être mis à jour pour gérer cette situation.

Cela devrait vous aider à démarrer avec l'idée de base de la façon de commencer à haute disponibilité. Si vous fournissez des détails précis sur votre architecture, vous obtiendrez probablement une réponse beaucoup mieux.

Answer 3

Si le service n'expose aucune interface pour la connectivité client, vous pouvez:

• Diffusion ou exposer un « Je suis vivant » message ou signaler une base de données / registre / tcp / whatever que vous êtes en vie

• Avoir un deuxième service (moniteur) qui vérifie ces « je suis vivant » signaux et essayer de redémarrer le service dans le cas où il est bas

Mais si vous avez un client qui se connecte à ce service par namedpipes / tcp / etc, le client devra vérifier l'adresse de la machine avec le service en cours d'exécution dans une base de données, ou avoir quelque chose colombophile comme un commutateur intelligent pour rediriger le trafic .