Windows NLB fonctionne très bien et supprime l'ordinateur du cluster lorsque l'ordinateur est mort.La détection des applications mortes pendant que le serveur est actif dans NLB
Mais que se passe-t-il si l'application meurt mais que le serveur fonctionne toujours correctement? Comment avez-vous résolu ce problème?
Merci
En n'utilisant NLB.
Les équilibreurs de charge matérielle ont souvent des fonctions «sonde» configurables pour déterminer si un serveur répond aux demandes. Cela peut être en accédant au port/URL réel de l'application, ou à une URL spécifique "healthcheck" qui ne retourne que si l'application est en bonne santé.
Autres options sur ces regardent la file d'attente/temps nécessaire pour répondre aux demandes
Cisco mis comme ceci:
Le Cisco CSM surveille en permanence le serveur et la disponibilité des applications en utilisant une variété de sondes , la surveillance de l'intégrité dans la bande, le code de retour et le protocole Dynamic Feedback (DFP). Lorsqu'un serveur réel ou une défaillance de passerelle se produit, le Cisco CSM redirige le trafic vers un autre emplacement . Les serveurs sont ajoutés et supprimés sans perturber les systèmes de service sont facilement mis à l'échelle ou vers le bas.
Vraisemblablement avec Windows NLB il y a une manière de définir par programme le poids des nœuds? Les nœuds doivent être auto-surveillés et s'il y a un problème (par exemple, un nœud particulier manque d'espace disque), réglez son poids sur zéro pour qu'il ne reçoive plus de trafic. Cependant, ceci doit être soigneusement conçu et faire l'objet d'une surveillance humaine supplémentaire pour s'assurer que vous ne vous retrouviez pas dans une situation où une défaillance entraîne l'annonce de l'ensemble du cluster.
Vous ne pouvez pas vraiment espérer faire face à une situation «générale byzantine» dans l'équilibrage de la charge réseau; un nœud cassé de manière appropriée peut penser que tout va bien, bien paraître, mais tout en étant complètement incapable de faire un travail réel. L'astuce consiste à essayer de minimiser la possibilité que ces situations se produisent en production.
Il existe plusieurs niveaux de vérification d'intégrité pour une application réseau.
Mon expérience avec NLB peut être incomplète, mais je vais décrire ce que je sais. NLB peut faire 1 et 2. Avec le codage personnalisé, vous pouvez ajouter les autres niveaux avec des difficultés variables. Avec certaines architectures de réseau, cela peut être difficile à très.
La plupart des équilibreurs de charge matériels de fournisseurs tels que Cisco ou F5 peuvent être facilement configurés pour effectuer 3 ou 4. Les tests de niveau 5 nécessitent toujours un codage personnalisé.
Nous commençons dans la situation où tous les nœuds font partie du cluster mais sont inactifs. Nous exécutons un moniteur de service personnalisé qui effectue une demande sur le service localement via l'interface externe. Si la réponse a été réussie, nous démarrons le noeud (lui permettre de commencer à gérer le trafic NLB). Si la réponse a échoué, nous empêchons le nœud de recevoir du trafic.
Toutes les étapes intermédiaires décrites par Darron ne sont pas pertinentes. Est-ce que ça a marché ou pas, c'est la seule chose qui nous intéresse? Si la machine est inaccessible, le reste du cluster NLB la traitera comme ayant échoué.