Chaque service de données fourni avec le produit Oracle Solaris Cluster est doté d'un détecteur de pannes intégré. Le détecteur de pannes effectue les fonctions suivantes :
Détection de la fin inattendue de processus pour le serveur du service de données
Vérification de l'intégrité du service de données
Le détecteur de pannes se trouve dans la ressource qui représente l'application pour laquelle le service de données a été écrit. Cette ressource est créée au moment de l'enregistrement et de la configuration du service de données Pour plus d'informations, reportez-vous à la documentation du service de données.
Les propriétés standard et les propriétés d'extension de cette ressource déterminent le comportement du détecteur de pannes. Les valeurs par défaut de ces propriétés déterminent le comportement prédéfini du détecteur de pannes. Le comportement prédéfini doit être adapté à la plupart des installations d'Oracle Solaris Cluster. Vous devez donc uniquement régler un détecteur de pannes si vous devez modifier le comportement prédéfini.
Le réglage d'un détecteur de pannes implique les tâches suivantes :
Paramétrage de l'intervalle entre les tests du détecteur de pannes
Paramétrage du délai d'attente pour les tests du détecteur de pannes
Spécification du comportement de basculement d'une ressource
Effectuez ces tâches lorsque vous enregistrez et configurez le service de données. Pour plus d'informations, reportez-vous à la documentation du service de données.
Pour déterminer si une ressource fonctionne correctement, le détecteur de pannes la teste régulièrement. L'intervalle entre les tests du détecteur de pannes affecte la disponibilité de la ressource et les performances de votre système comme suit :
L'intervalle entre les tests du détecteur de pannes a une influence sur le temps requis pour détecter une panne et y répondre. Réduire l'intervalle entre les tests du détecteur de pannes a donc également pour effet de réduire le temps nécessaire pour détecter une panne et y répondre. Cette réduction augmente la disponibilité de la ressource.
Chaque test du détecteur de pannes consomme des ressources du système telles que des cycles de processeur et de la mémoire. Réduire l'intervalle entre les tests du détecteur de pannes a donc également pour effet de détériorer les performances du système.
L'intervalle idéal entre les tests du détecteur de pannes dépend également du temps requis pour réagir à une panne de la ressource. Ce temps dépend de la complexité de la ressource, au sens où une complexité élevée affecte la durée d'opérations telles que le redémarrage de la ressource.
Pour définir l'intervalle entre les tests du détecteur de pannes, définissez la propriété standard Thorough_probe_interval de la propriété sur l'intervalle en secondes dont vous avez besoin.
Le délai d'attente des tests du détecteur de pannes définit la durée pendant laquelle un détecteur de pannes attend la réponse d'une ressource à un test. Si le détecteur de pannes ne reçoit pas de réponse pendant le délai d'attente, il considère que la ressource est défectueuse. Le temps requis par une ressource pour répondre à un test du détecteur de pannes dépend des opérations que celui-ci effectue pour tester la ressource. Pour plus d'informations sur les opérations effectuées par le détecteur de pannes d'un service de données pour tester une ressource, reportez-vous à la documentation du service de données.
Le temps requis par une ressource pour répondre dépend également de facteurs non liés au détecteur de pannes ou à l'application, tels que :
La configuration du système
La configuration du cluster
La charge du système
La quantité de trafic sur le réseau
Pour définir le délai d'attente des tests du détecteur de pannes, définissez la propriété d'extension Probe_timeout de la ressource sur le délai d'attente en secondes dont vous avez besoin.
Pour les sondes de détecteur de pannes de la plupart des types de ressource, vous pouvez également configurer la propriété Timeout_threshold pour envoyer une notification lorsque la durée d'exécution d'une sonde va bientôt dépasser le délai défini. Ces notifications peuvent vous aider à identifier les délais d'attente de sonde insuffisants, qui peuvent entraîner des basculements à tort. Pour plus d'informations sur la propriété Timeout_threshold, reportez-vous à la page de manuel r_properties(5).
Pour minimiser les perturbations engendrées dans une ressource par des pannes temporaires, le détecteur de pannes redémarre la ressource lorsque des pannes de ce type surviennent. Des mesures plus perturbatrices que redémarrer la ressource sont nécessaires pour les pannes persistantes :
S'il s'agit d'une ressource de basculement, le détecteur de pannes bascule la ressource sur un autre noeud.
S'il s'agit d'une ressource évolutive, le détecteur de pannes met la ressource hors ligne.
Un détecteur de pannes considère une panne comme persistante si le nombre de défaillances totales d'une ressource dépasse un nombre de nouvelles tentatives défini par la propriété standard Retry_count. Définir les critères de définition des pannes persistantes vous permet de paramétrer le nombre de nouvelles tentatives et l'intervalle avant nouvelle tentative les plus adaptés aux caractéristiques de votre cluster et à vos besoins de disponibilité.
Cette section présente les rubriques suivantes :
Un détecteur de panne considère certaines pannes comme des défaillances complètes d'une ressource. Une défaillance complète entraîne généralement un arrêt complet du service. Les défaillances suivantes constituent par exemple des défaillances complètes :
Fin inattendue de processus pour le serveur du service de données
Impossibilité pour un détecteur de pannes de se connecter à un serveur de service de données
En cas de défaillance complète, le détecteur de pannes augmente d'une unité le nombre de défaillances complètes au cours de l'intervalle avant nouvelle tentative.
Un détecteur de pannes considère d'autres pannes comme des défaillances partielles d'une ressource. Une défaillance partielle est moins grave qu'une défaillance complète et entraîne généralement une détérioration du service, mais pas un arrêt complet du service. L'envoi d'une réponse incomplète à un test du détecteur de pannes avant l'expiration du délai d'attente par un serveur de service de données constitue un exemple de défaillance partielle.
En cas de défaillance complète, le détecteur de pannes augmente d'une fraction d'unité le nombre de défaillances complètes au cours de l'intervalle avant nouvelle tentative. Toutefois, les défaillances partielles s'additionnent les unes aux autres pendant l'intervalle avant nouvelle tentative.
Les caractéristiques suivantes des défaillances partielles dépendent du service de données :
Les types de pannes que le détecteur de pannes considère comme des défaillances partielles
La fraction d'unité que chaque défaillance partielle ajoute au nombre total de défaillances complètes
Pour plus d'informations sur les pannes détectées par le détecteur de pannes d'un service de données, reportez-vous à la documentation du service de données concerné.
La durée maximale d'un seul redémarrage d'une ressource défectueuse correspond à la somme des valeurs des propriétés suivantes :
La propriété système Thorough_probe_interval
La propriété d'extension Probe_timeout
Pour être certain de définir un intervalle avant nouvelle tentative suffisamment long pour permettre d'atteindre le nombre de nouvelles tentatives, calculez les valeurs de l'intervalle avant nouvelle tentative et du nombre de nouvelles tentatives à l'aide de l'expression suivante :
Le facteur 2 permet de tenir compte des défaillances partielles du test qui n'entraînent pas immédiatement le basculement ou la mise hors ligne de la ressource.
Pour définir le nombre de nouvelles tentatives et l'intervalle avant nouvelle tentative, paramétrez les propriétés standard suivantes de la ressource :
Pour définir le nombre de nouvelles tentatives, paramétrez la propriété standard Retry_count sur le nombre maximal autorisé de défaillances complètes.
Pour définir l'intervalle avant nouvelle tentative, paramétrez la propriété standard Retry_interval sur l'intervalle en secondes dont vous avez besoin.
Le comportement de basculement d'une ressource détermine la manière dont le RGM répond aux pannes suivantes :
Echec du démarrage de la ressource
Echec de l'arrêt de la ressource
Echec de l'arrêt du détecteur de pannes de la ressource
Pour spécifier le comportement de basculement d'une ressource, définissez la propriété standard Failover_mode de la ressource. Pour plus d'informations sur les valeurs possibles de cette propriété, reportez-vous à la description de la propriété standard Failover_mode à la page de manuel r_properties(5).