Est-ce que quelqu'un connaît-il de meilleures pratiques établies pour exécuter des services Windows (dans mon cas, développées dans .NET) de sorte qu'elles échouent (automatiquement) échouent correctement à un autre serveur, à des fins de haute disponibilité?
Les principales façons de voir que cela se produisent sont soit en train de démarrer le serveur secondaire lorsque cela est requis (auquel cas il est nécessaire de surveiller l'autre serveur) ou d'avoir les deux services fonctionnant ensemble (auquel cas ils ont besoin de synchroniser leur travail alors ils n'essayent pas de faire les mêmes choses).
Y a-t-il un modèle ou un modèle pour ce type de problème? Je sais que la situation exacte fera une grande différence, mais cela semble être un problème assez courant.
merci
Jean
5 Réponses :
Avoir les deux courants tout le temps est probablement la solution la plus simple, mais vous devez vous assurer de ne jamais aller au-dessus de 50% de charge, sinon quand on échoue, l'autre deviendra surchargé et peut-être échouer aussi.
Pour synchroniser, utilisez une base de données transactionnelle. Essayer d'écrire votre propre synchronisation entraînera généralement des bugs.
Si vous pouvez avoir les deux services travaillant - c'est mieux. Vous devez vous assurer qu'ils sont apatrides ou savent comment gérer la question de l'état et que la base de données se synchronise entre eux. Dans un seul point d'échec unique, vous appuierez le problème sur la base de données et vous pouvez disposer d'un cluster actif 2 nœud actif et de laisser la fabrication de la DB gérer les problèmes de synchronisation.
Je crois que la meilleure façon de traiter le basculement est au niveau du réseau dans la mesure du possible. Virtual IPS qui fronçant les environnements équilibrés et primaires / basculants de la charge est un bon moyen d'éviter d'écrire du code pour les scénarios de basculement.
Dans les cas où vous devez gérer le basculement dans le code:
Quel est le réseau à faire avec les services Windows. Il peut y avoir un service d'arrière-plan en cours d'exécution et de faire son travail sans nécessairement aucun client qui y est connecté. Le système d'exploitation de manière correcte pour faire un clustering de basculement.
Il y a deux approches de base.
Les clients sont conscients de l'adresse du point d'extrémité différente et du commutateur au besoin ou selon les directives d'un autre service ou d'un autre mécanisme de configuration. (Comme exemple, le Application de démonstration de StockTrader fait cela.)
Les clients ne sont pas au courant et vous utilisez une approche d'équilibrage de charge réseau standard qui peut également fournir un basculement. F5 est un seul produit. Il y en a beaucoup d'autres. Il s'agit fondamentalement comme une NAT pour les services toutes les demandes suivent votre NLB et les envoie sur un serveur et renvoie la réponse à l'appelant. Ces produits surveillent les services et n'utilisent que celles qui sont en place. Vous pouvez également le personnaliser avec des règles pour affecter de nouvelles demandes à des serveurs basées sur des charges de travail du serveur. Windows Server a cette fonctionnalité intégrée dans une certaine mesure.
De toute façon que vous le faites, c'est beaucoup plus facile si vos appels de service sont «apatrides».
Voici ce qui a fonctionné pour moi.
à partir d'un point de support d'infrastructure, vous devez disposer de 2 serveurs Windows qui sont regroupés. (2 Boîtes de serveurs Windows standard feront, la pièce de clustering peut être installée et configurée, la plupart des administrateurs SYS doivent savoir comment faire cela.) Ensuite, installez votre service sur les deux nœuds du cluster et faites-les à la fois éteint et défini sur Manuel. Commencez. Ensuite, ajoutez une ressource en cluster à l'administrateur de cluster Windows pour votre service qui permettra de tourner et de désactiver votre service sur lequel le nœud est actif. Laissez le cluster Windows gérer lorsque votre service est en cours d'exécution et sur quel nœud. C'est la partie facile du regroupement de votre service.
Du point de vue du service, vous voudrez concevoir votre service afin qu'il puisse être aussi apatride que possible. C'est une sorte de conseil boiteux, mais cela dépend vraiment de votre service. Dans la conception, supposons simplement qu'à un point de vie pendant la vie du code, il s'arrêtera au pire temps possible. Comment le service sur le nœud2 peut-il savoir où ramasser où Node1 est parti? C'est la partie difficile que vous devez concevoir. En fonction de votre service, vous pouvez laisser la dernière tâche terminée dans une table DB ou un fichier de données partagé. Vous pouvez également commencer à partir du début et vérifiez si cette tâche a été complétée ou non avant d'y agir.
Encore une fois, cela va vraiment dépendre de ce que le service doit accomplir. J'espère que cela aide.
Oui Le cluster de basculement est la bonne approche. Vous pouvez scripter cela pour configurer des groupes, des ressources et des dépendances de cluster pendant le déploiement. Cela nécessite une édition de Windows Server Enterprise, cependant pas une édition standard.
Je suis faible dans les idées de regroupement et pouvez-vous alors expliquer ce que cela signifiait par "Ensuite, ajoutez une ressource en cluster à l'administrateur de cluster Windows pour votre service qui permettra de tourner et de désactiver votre service sur lequel le nœud est actif". Est-ce que cela signifiait par une application de contrôle distincte? Si oui, où cela sera installé à l'intérieur du cluster?
Merci pour votre réponse. Désolé, j'aurais dû souligner que le service que je faisais appelé était plus d'un service de traitement de fond - il ne gère pas les connexions réseau entrantes. J'apprécie tous les conseils!