Les défis et les meilleures pratiques pour Basculement services

Question

Quelqu'un sait-il de toutes les meilleures pratiques pour la gestion des services Windows habituels (dans mon cas, développés en .NET) de telle sorte qu'ils (automatiquement) basculent correctement vers un autre serveur, à des fins de haute disponibilité?

Les principaux moyens que je peux voir ceci fait sont soit le démarrage du serveur secondaire lorsque cela est nécessaire (dans ce cas, il doit être quelque chose suivi de l'autre serveur), ou ayant les deux services en cours d'exécution ensemble (auquel cas ils doivent synchroniser leur travail afin qu'ils ne cherchent pas à faire les mêmes choses).

Y at-il un modèle ou un modèle pour ce genre de problème? Je sais que la situation exacte fera une grande différence, mais il ne semble comme un problème assez commun.

Merci

John

Answer 1

Voici ce qui a fonctionné pour moi.

D'un point de support d'infrastructure, vous aurez besoin d'avoir 2 serveurs Windows qui sont regroupés. (2 boîtes de Windows Server standards vont faire, la pièce Clustering peut être installé et configuré, la plupart des Admins doivent savoir comment faire.) Ensuite, installez votre service sur les deux nœuds du cluster et ont tous les deux éteints et mis à MANUEL Commencez. Ensuite, ajoutez une ressource en cluster à l'administrateur de cluster Windows pour votre service qui va gérer pour allumer et éteindre votre service quel que soit le noeud est actif. Laissez le cluster Windows gérer lorsque votre service est en cours d'exécution et sur lequel le noeud. Ceci est la partie facile du regroupement de votre service.

Du point de stand de service, vous souhaitez concevoir votre service afin qu'il puisse être aussi apatride que possible. C'est le genre de conseils boiteux, mais cela dépend vraiment de ce que votre service fait. Dans la conception, supposons simplement que, à somepoint pendant la durée de vie du code, il arrêtera au pire moment possible. Comment le service sur le node2 savoir où pick-up où node1 laissé? C'est la partie la plus difficile que vous devez concevoir pour. Selon ce que votre service fait vous pouvez laisser la dernière tâche terminée dans une table db ou d'un fichier de données partagées. Vous pourriez avoir aussi commencer dès le début et Revérifiez si cette tâche est terminée ou non avant d'agir sur elle.

Encore une fois, il va vraiment dépendre de ce que le service doit accomplir. Espérons que cela aide.

Answer 2

Ayant à la fois en cours d'exécution tout le temps est probablement la solution la plus simple, mais vous devez vous assurer que vous n'allez au-dessus de 50% de charge, sinon quand on tombe en panne, l'autre saturera et peut-être aussi l'échec.

Pour synchroniser, utilisez une base de données transactionnelle. Essayer d'écrire votre propre synchronisation entraîne généralement des bogues.

Answer 3

Si vous pouvez avoir les deux services de travail - il est préférable. vous devez vous assurer qu'ils sont apatrides ou ne savent pas comment gérer problème de l'Etat, et la Databse se synchroniser entre eux. Dans un point de défaillance unique - vous pousserez le problème à la base de données, et vous pouvez avoir un cluster actif actif 2 noeuds, et que la fabrication de DB gérer les problèmes de synchronisation

.

Answer 4

Je crois que la meilleure façon de traiter avec basculement est au niveau du réseau chaque fois que possible. IP virtuelles faisant face à charge équilibrée ou des environnements primaire / basculement est un bon moyen pour éviter d'avoir à écrire du code pour les scénarios de basculement.

Dans le cas où vous devez gérer le basculement dans le code:

1. Test de connexion / appel de service
2. Si le test échoue, envoyer des alertes
3. basculent vers endpoint suivant service "enregistré"

Answer 5

Il existe deux approches de base.

1. les clients connaissent une autre adresse de point final et le commutateur au besoin ou comme dirigé par un autre mécanisme de service ou de configuration. (Comme par exemple le application de démonstration de StockTrader le fait.)

2. Les clients ne sont pas au courant, et que vous utilisez une approche d'équilibrage standard charge du réseau qui peut également fournir un basculement. F5 est un produit. Il y a beaucoup d'autres. Il est fondamentalement comme un NAT pour toutes les demandes de services passent par votre NLB et il les envoie à un serveur, et transmet la réponse à l'appelant. Ces produits surveiller les services et utiliser uniquement ceux qui sont en place. vous pouvez également personnaliser souvent avec des règles pour avoir assigner de nouvelles demandes aux serveurs en fonction de la charge de travail du serveur. serveur Windows a cette fonctionnalité intégrée dans une certaine mesure.

De toute façon vous le faites, il est beaucoup plus facile si vos appels de service sont « apatrides ».