Apparence
Uubu.fr

Les systèmes Linux, l’open source, les réseaux, l’interopérabilité, etc.
« Il vaut mieux viser la perfection et la manquer que viser l’imperfection et l’atteindre. » (Bertrand Arthur William RUSSEL)
26 janvier 2015

htmlpdflatexmanmd




cmap_keys

cmap_keys

Vue générale dans le CMAP

Description

   La librairie cmap est utilisée pour interagir avec la base de configuration utilisée par corosync. Il y a 3 types de clé stockés dans cmap: Mappage de valeurs stockées dans le fichier de configuration, statistiques temps réels, valeurs créées par l'utilisateur.

Clés

internal_configuration.* Données de configuration interne. Ces clés sont lecture seule. Si une configuration spécifique au sous-système est nécessaire, la clé doit être sous la forme logging.logger_subsys.SERVICE.key où SERVICE est un nom de service en majuscule et la clé est la même que dans le fichier de configuration.
nodelist.* Valeurs lues depuis le fichier de configuration. Chaque élément node dans le fichier de configuration à une position assignées commençant à 0. Donc de premier nœud a le préfixe nodelist.node.0..
runtime.blackbox.* Trigger keys. Il est recommandé d'utiliser corosync-blackbox pour trouver facilement les adresses nodeid/ring du nœud local directement de cmap.
runtime.connections.* Informations sur le nombre total de connexions actives, terminées, et sur chaque connexion IPC à un moment donné. Tous les clés sont lecture seules.
runtime.connections.ID.* Chaque connexion IPC a un ID unique. C'est sous la forme [[short_name:][PID:]internal_id. Les clés typiques sont:

        client_pid Contient le PID d'une connexion IPC
        dispatched avec le nombre de messages dispatchés
        invalid_request nombre de requête faites par IPC qui sont invalides
        name Contenant le nom court d'une connexion IPC
        overload Nombre de de requêtes qui n'ont pas été traité à cause d'une surcharge
        queue_size nombre de messages en queue d'attente d'envoie
        recv_retries nombre total de réceptions interrompues
        requests nombre de requêtes faites par IPC
        responses nombre de réponses envoyées par IPC
        send_retries nombre total d'envoies interrompues
        service_id ID du service auquel IPC est connecté

runtime.services.* statistiques pour les moteurs de service. Chaque service a son propre service_id avec un nom runtime.services.SERVICE., où SERVICE est un nom de service en minuscule.
runtime.totem.pg.mrp.srp.* Statistiques sur totem. Les clés sont lecture seule:

        commit_entered Nombre de fois qu'un processeur entre en état COMMIT
        commit_token_lost Nombre de fois qu'un processeur perd le token en état COMMIT
        consensus_timeouts Nombre de fois qu'un processeur dépasse le délai en créant un consensus sur le membership
        continuous_gather Nombre de fois qu'un processeur n'a pas été capable d'atteindre de consensus
        firewall_enabled_or_nic_failure à 1 quand le processeur n'a pas été capable d'atteindre le consensus depuis longtemps.
        gather_entered Nombre de fois qu'un processeur entre à l'état GATHER
        gather_token_lost Nombre de fois qu'un processeur perd le token en état GATHER
        mcast_retx Nombre de messages retransmis
        mcast_rx Nombre de message multicast reçus
        mcast_tx Nombre de message multicast transmis
        memb_commit_token_rx Nombre de token reçus
        memb_commit_token_tx Nombre de token émis
        memb_join_rx Nombre de message join reçus
        memb_join_tx Nombre de message join transmis
        memb_merge_detect_rx Nombre de message member merge reçus
        memb_merge_detect_tx Nombre de message member merge transmis
        orf_token_rx Nombre de tokens orf reçus
        orf_token_tx Nombre de tokens orf transmis
        recovery_entered Nombre de fois qu'un processeur entre à l'état recovery
        recovery_token_lost Nombre de fois qu'un token a été perdu à l'état recovery
        rx_msg_dropped Nombre de messages reçus qui ont été supprimés parce qu'ils n'étaient pas attendus
        token_hold_cancel_rx Nombre de token reçus contenant un message cancel
        token_hold_cancel_tx Nombre de token émis contenant un message cancel
        mtt_rx_token Mean Transmis Time du token, en ms. temps entre 2 tokens consécutifs reçus
        avg_token_workload Temps moyen en ms du temps à maintenir le token dans le processeur courant
        avg_backlog_calc Temps moyen de message non encore envoyés du processeur courant.

runtime.totem.pg.mrp.srp.members.* Contient les membres du protocole totem. Chaque membre à le format runtime.totem.pg.mrp.srp.members.NODEID.KEY œu key peut être:

        ip L'adresse IP du membre
        joint_count Nombre de fois que le processeur à joins le membership avec le processeur local.
        status Statut du processeur
        config_version Version de configuration du nœud membre.

resources.process.PID.* Préfixe créé par les applications utilisant SAM avec l'intégration CMAP. Il contient les clés suivantes:

        recovery Stratégie de récupération du processus.
        poll_period Valeur passée dans sam_initialize comme time_interval
        last_updated Dernière fois que sam a reçus un heartbeat du client
        state État du client.

uidgid.* Les informations sur les utilisateurs/groupes qui sont autorisés à faire des connexions IPC à corosync
quorum.cancel_wait_for_all Dit à votequorum d'annuler l'attente de tous les nœuds au démarrage du cluster. Peut être utilisé pour débloquer le quorum si des nœud sont éteinds.
config.reload_in_progress À 1 quand corosync.conf est rechargé, 0 sinon.
config.totemconfig_reload_in_progress Idem, mais changé après une configuration totem.

Exemples

Changer dynamiquement les permission user/group pour utiliser cororsync ipc:
corosync-cmapctl -s uidgid.uid.500 u8 1
GID est similaire:
corosync-cmapctl -s uidgid.gid.500 u8 1
Pour supprimer la permission, la supprimer:
corosync-cmapctl -d uidgid.gid.500
Ajouter/supprimer dynamiquement un nœud UDPU. On ajoute un nœud avec l'ip 10.34.38.108 et nodeid 3. On cherche une position de nœud qui n'est pas utilisée:
nodelist.local_node_pos (u32) = 1
nodelist.node.0.nodeid (u32) = 1
nodelist.node.0.ring0_addr (str) = 10.34.38.106
nodelist.node.1.nodeid (u32) = 2
nodelist.node.1.ring0_addr (str) = 10.34.38.107
Donc la position de nœud suivant sera 2:
corosync-cmapctl -s nodelist.node.2.nodeid u32 3
corosync-cmapctl -s nodelist.node.2.ring0_addr str 10.34.38.108
Toujours ajouter ring0_addr en dernier
^
26 janvier 2015

htmlpdflatexmanmd




corosync

corosync

Moteur de clustering Corosync

OPTIONS

-f Démarre l'application en tâche de fond
-r Set round robin realtime scheduling
-t Test la configuration et quitte
^
26 janvier 2015

htmlpdflatexmanmd




corosync-blackbox

corosync-blackbox

Dump les données à la volée depuis le corosync blackbox

Description

   corosync-blackbox pilote corosync pour écrire ses données dans un fichier et lancer qb-blackbox qui l'affiche.

Exemples

Afficher la données courante:
$ corosync-blackbox
Starting replay: head [74205] tail [0]
rec=[1] Log Message=Corosync Cluster Engine ('1.2.1'): started and ready to provide service.
[...]
rec=[2607] Log Message=Delivering MCAST message with seq a to pending delivery queue
rec=[2608] Log Message=downlist received left_list: 2
rec=[2609] Log Message=chosen downlist from node r(0) ip(192.168.100.11)
Finishing replay: records found [2609]

^
26 janvier 2015

htmlpdflatexmanmd




corosync-cfgtool

corosync-cfgtool

Outil administratif pour corosync

Description

   Outil pour afficher et configurer les paramètres actifs dans corosync

OPTIONS

-i Cherche seulement les informations sur l'adresse IP spécifiée
-s Affiche le statut des rings courants dans ce nœud. Si une interface est en faute, retourne 1, sinon 0.
-r Ré-initialise l'état du ring redondant du cluster après une faute pour réactiver l'opération de redondance.
-l Charge un service identifié par le nom du service spécifié
-u Décharge un service identifié par le nom du service spécifié
-a Affiche toutes les adresses IP d'un nœud.
-k Tue un nœud identifié par l'id de nœud
-R Dit à toutes les instances de corosync dans ce cluster de recharger corosync.conf
-H Éteins corosync proprement dans ce nœud.
^
26 janvier 2015

htmlpdflatexmanmd




corosync-cmapctl

corosync-cmapctl

Outil d'accès à la base d'objets

Options

-b Affiche les valeurs binaires
-s key_name type value Définis une clé où type est un parmi ([i|u][8|16|32|64] | flt | dbl | str | bin) pour bin, value est le nom du fichier (ou -pour stdin)
-d key_name Supprimer une clé
-D key_prefix Supprimer plusieurs clé de même préfixe
-g key_name Récupérér une clé
-t key_name Suivre les changements de clé
-T key_prefix Suivre les changements de plusieurs clés
-p filename Charger les paramètres depuis un fichier:

           Le format du fichier est sous la forme: [^[^]]‹key_name›[ ‹type› ‹value›]. Les clé préfixée avec '^' sont supprimées, les clé préfixé avec '^^' sont supprimées par préfixe. type et value sont optionnel dans ces cas là.

^
26 janvier 2015

htmlpdflatexmanmd




corosync-cpgtool

corosync-cpgtool

Outil d'affichage des groupes et membres cpg

Options

-d Délimiter entre les champs
 -e N'échappe par les caractères non imprimables dans le nom de groupe
 -n Affiche seulement tous les noms de groupes existant.
^
26 janvier 2015

htmlpdflatexmanmd




corosync-keygen

corosync-keygen

Génère une clé d'authentification pour corosync

Description

   Pour configurer corosync avec des techniques cryptographiques pour s'assurer de l'authenticité de la protection des données des messages, il faut générer une clé privée. corosync-keygen crée cette clé et l'écris dans /etc/corosync/authkey.

  La clé privée doit être copiée dans tous les processeurs dans le cluster. Si la clé privée n'est pas la même pour tous les nœuds, cet nœuds ne seront pas capables de se joindre à la même configuration.

Copier la clé dans un stockage sécurisé ou utiliser ssh. Puis l'installer avec la commande suivante:
install -D --group=0 --owner=0 --mode=0400 /path_to_authkey/authkey /etc/corosync/authkey
Si un message "Invalid digest" apparaît dans corosync, les clés ne sont pas consistantes entre les processeursS.

OPTIONS

-k ‹filename› Spécifie le chemin où créer la clé. défaut: /etc/corosync/authkey
-l Utilise une source de données aléatoires moins sûre, qui ne nécessite pas l'aide de l'utilisateur pour générer de l'entropy.
^
26 janvier 2015

htmlpdflatexmanmd




corosync-notifyd

corosync-notifyd

Écoute les évènements corosync importants et les envoie sur dbus et/ou snmp

Options

-f Lance en tâche de fond
-l Log tous les évènements
-o Affiche les évènements sur stdout
-s envoie des traps snmp
-m définis d'adresse du gestionnaire snmp
-d Envoie les signaux dbus dans tous les évènements
^
26 janvier 2015

htmlpdflatexmanmd




Corosync - Présentation

Corosync - Présentation

Présentation du moteur de cluster Corosync

Description

   Le projet corosync est un projet pour implémenter un outil de développement de haute disponibilité haute performance et faible charge. Le focus majeur de la haute disponibilité dans le passé a été de masquer les erreurs hardware. Les pannes dans d'autres composants du système restaient non-résolus jusqu'à corosync. Corosync est conçu pour les applications pour répliquer leur état jusqu'à 16 processeurs. Les processeurs contiennent tous un réplica de l'état de l'application.

  Le projet corosync fournis une API de message de groupe appelé CPG, qui implément un modèle de messagerie de groupe fermé présentant des garantie de synchronisation virtuel garantie.

  Pour gérer les conditions où les processus exécutant l'échange CPG plante, on fournis le Simple Availability Manager (SAM) pour permet de redémarrer l'application.

Démarrage rapide

   Dans le répertoire conf dans les sources se trouvent de nombreux fichiers qui doivent être copiés dans le répertoire /etc/corosync. corosync devrait fonctionner avec la configuration par défaut. Corosync utilise des techniques cryptographiques pour s'assurer de l'authenticité et de la protection des messages. pour que corosync soit sécurisé, une clé privée doit être générée et partagée par tous les processeurs.

Variables d'environnement

COROSYNC_MAIN_CONFIG_FILE Spécifie le fqdn du fichier de configuration. défaut: /etc/corosync/corosync.conf
COROSYNC_TOTEM_AUTHKEY_FILE fqdn de la clé partagée utilisée pour authentifier et chiffrer les données utilisée dans le protocole Totem. Défaut: /etc/corosync/authkey

Sécurité

   Corosync chiffre tous les messages envoyés sur le réseau en utilisant le chiffrement SOBBER-128. Corosync utilise HMAC et SHA1 pour authentifier tous les messages. Corosync utilise NSS comme générateur de nombres pseudo-aléatoire. La libraire EVS utilise /dev/random.

  Si les messages de membre peuvent être capturés par des intrus, il est possible d'exécuter une attaque DOS dans le cluster. Dans ce scénario, le cluster est déjà compromis et une attaque DOS est le dernier des soucis de l'administrateur.

   La sécurité dans corosync n'offre pas de solution parfaite puisque les clés sont réutilisée. Il peut être possible pour un attaquant de capturer des packets et de déterminer la clé partagée. Dans ce scénario, le cluster est compromis. Pour des raisons de sécurité, corosync ne devrait jamais avoir le setuid ou setgid dans le système de fichier.

Composants

- La librairie cmap est utilisée pour interagir avec la base de configuration utilisée par corosync.
- La librairie cpg est utilisée pour créer des applications distribuées qui opèrent proprement durant le partitionement, fusions, et pannes du cluster.
- la librairie sam fournis un outils pour vérifier l'état de santé d'une application. Son but est de redémarrer un processus local quand il plante pour répondre à un requête d'état de santé dans un intervalle de temps configuré.
- La librairie quorum est chargé dans tous les nœuds du cluster et track le statut du quorum d'un nœud. Pour que ce service soit utile, un fournisseur de quorum doit être configuré.
- La librairie votequorum est optionnellement chargé dans tous les nœuds dans le cluster pour éviter les situations de split-brain. Il permet cela en ayant un nombre de votes assignés à chaque système dans le cluster et s'assurer que seulement lorsqu'une majorité de votes sont présents, les opérations du cluster sont autorisés à être traités.
^
26 janvier 2015

htmlpdflatexmanmd




corosync-quorumtool

corosync-quorumtool

Définis et affiche les paramètres de quorum et définis les options de vote

Options

-s Affiche le status du quorum
-m Monitor constamment le statut du quorum
-l Liste les nœuds
-v ‹votes› Change le nombre de votes pour un nœuds
‹nodeid› nodeid optionnel du nœud pour -v
-H Affiche les nodeids en hexadécimal
-i Affiche les adresses IP au lieu de résoudre leur noms
-o ‹a|n|i› Ordonne la sortie de la liste des nœuds. a pour l'adresse ip, n par nom, et i par id de nœud
^
26 janvier 2015

htmlpdflatexmanmd




corosync-xmlproc

corosync-xmlproc

Convertis corosync.xml en fichier de configuration corosync

Options

input_xml fichier xml à convertir
output_file nom du fichier de destination
^
26 janvier 2015

htmlpdflatexmanmd




corosync.conf

corosync.conf

Fichier de configuration de corosync

Description

   Le fichier de configuration consiste de directives en accolades. Les choix possibles sont:

totem {} Contient les options de configuration pour le protocole totem
logging {} Contient les options de configuration pour le logging
quorum {} Contient les options de configuration pour le quorum
nodelist {} Contient les options de configuration pour les nœuds dans le cluster
qb {} Contient les options de configuration liées à libqb

Options totem

ringnumber Spécifie le numéro pour l'interface. En utilisant le protocole ring redondant, chaque interface devrait avoir un numéro ring séparé pour identifier les membres du protocole que l'interface utilise pour le ring. doit commencer à 0.
bindnetaddr Spécifie l'adresse réseaux auquel corosync devrait se lier. Doit être une IP dans le système, ou un réseau.
broadcast Optionnel et peut être mis à yes. Permet d'utiliser le broadcast pour les communications.
mcastaddr Adresse de multicast pour corosync. Le défaut devrait fonctionner sur la plupart des réseaux. Éviter 224.x.x.x parce que c'est une adresse multicast de config.
mcastport Port UDP pour le multicast.
ttl Si le cluster fonctionne sur un réseau routé, un TTL de 1 sera trop petit.
version Spécifie la version du fichier de configuration. Actuellement la seule version valide est 2.
clear_node_high_bit Optionnel et est seulement utile quand aucun nodeid n'est spécifié. Certains client corosync nécessitent un nodeid 32-bits signé supérieur à 0, cependant corosync utilise tous les 32-bits de l'espace d'adressage IPv4 en générant un nodeid. À yes, cette options force le MSB à 0.
crypto_hash Spécifie l'algorithme d'authentification HMAC utilisé pour authentifier tous les messages. Les valeurs valides sont: none, md5, sha1, sha256, sha384 et sha512.
crypto_cipher Spécifie l'algorithme de chiffrement à utiliser pour chiffrer les messages. Les valeurs valides sont: none, aes256, aes192, aes128, et 3des.
rrp_mode Spécifie le mode de ring redondant, qui peut être: none, active, ou passive. La réplication active offre les latences les plus faibles mais est moins performant. La réplication passive peut presque doubler la vitesse du protocole totem. none spécifie que seul l'interface réseau sera utilisé pour opérer le protocole totem.
netmtu Spécifie l'unité de transmission maximum réseaux. Pour définir cette valeur au-delà de 1500, le support des jumbo frames est nécessaire sur tous les nœuds.
transport Contrôle le mécanisme de transport utilisé. Si l'interface auquel corosync est lié est une interface RDMA, le paramètre "iba" peut être spécifié. Pour éviter l'utilisation du multicast, un paramètre de transport unicast "udpu" peut être spécifié. Cela nécessite de spécifier la liste des membres dans la directive nodelist. Défaut: udp.
cluster_name Spécifie le nom du cluster et son utilisation pour la génération automatique d'adresse multicast.
config_version Spécifie la version du fichier de configuration. C'est convertit en entier non-signé 64-bits. Par défaut: 0. Permet d'éviter de joindre d'anciens nœud sans configuration à jours.
ip_version Spécifie la version d'IP à utiliser pour les communications. ipv4 ou ipv6.
token Ce timeout spécifié en millisecondes le délai au delà duquel une perte de token est déclaré. C'est le temps passé à détecter une panne d'un processeur dans la configuration courante. Réformer une nouvelle configuration prend 50 ms en plus de ce timeout.
token_coefficient Utilisé seulement quand la section nodelist est spécifiée et contient au moins 3 nœuds. Le vrai timeout de token est calculé par token + (number_of_nodes -2) * token_coefficient. Cela permet au cluster de s'agrandir sans changer manuellement le timeoute de token à chaque fois qu'un nœud est ajouté. Défaut: 650ms
token_retransmit Ce timeout spécifie, en ms, après combien de temps avant de recevoir un token le token est retransmis. Ce sera automatiquement calculé si le token est modifié. Il n'est pas recommandé d'altérer cette valeur. Défaut: 238ms.
hold Ce timeout spécifie, en ms, combien de temps le token devrait être maintenu quand le protocole est en sous-utilisation. Il n'est pas recommandé d'altérer ce paramètre. Défaut: 180ms
token_retransmits_before_loss_const Cette valeur identifie combien de token retransmis devraient être tentés avnt de former une nouvelle configuration. Si cette valeur est définie, la retransmission et le maintient sera automatiquement calculé depuis retransmits_before_loss et token. Défaut: 4 retransmissions.
join Ce timeout spécifie, en ms, combien de temps attendre les messages join dans le protocole membership.
send_join Ce timeout spécifie, en ms, une plage entre 0 et send_join d'attente avant d'envoyer un message join. Pour les configuration inférieur à 32 nœuds, ce paramètre n'est pas nécessaire. Pour les ring plus grands, ce paramètre est nécessaire pour s'assurer que l'interface n'est pas surchargée avec des messages join. Une valeur raisonnable pour les grands ring (128 nœuds) est de 80ms. Défaut: 0
consensus Ce timeout spécifie, en ms, combien de temps attendre pour que le consensus soit achevé avant de commencer un nouveau tour de configuration de membership. a valeur minimum pour le consensus doit être 1.2 * token. Ce calcul est automatique si cette option n'est pas spécifiée
merge Ce timeout spécifie, en ms, combien de temps attendre avant de vérifier une partition quand aucun trafique multicast n'a été envoyé. Si un trafique multicast est envoyé, la detection du merge se produit automatiquement en tant que fonction du protocole. Défaut: 200ms
downcheck Ce timeout spécifie, en ms, combien de temps attendre avant de vérifie qu'une interface réseaux est de nouveau disponible après une indisponibilité. Défaut: 1000ms
fail_recv_constf Cette constante spécifie combien de rotations du token sans recevoir de messages quand les message devaient être reçus peuvent se produire avant qu'une nouvelle configuration ne soit formée. Défaut: 2500 échecs de réception de message.
seqno_unchanged_const Cette constante spécifie combient de rotation du token sans trafique multicast devrait se produire avant que le timer hold soit démarré. Défaut: 30 rotations.
heartbeat_failures_allowed Mécanisme HeartBeating. Configure le mécanisme HeartBeating pour une détection d'erreur plus rapide. Garder en mémoire qu'engager ce mécanisme dans un réseau avec beaucoup de perte peut causer les déclaration de fausse perte vu que le mécanisme ne se base que sur le réseau. Défaut: 0 (désactivé)
max_network_delay Mécanisme HeartBeating. Cette constante spécifie, en ms, le délai approximatif que le réseau prend pour transporter un packet d'une machine à une autre. Cette valeur doit être définie par les ingénieurs système. Défaut: 50ms
window_size Cette constante spécifie le nombre de messages qui peuvent être envoyés en une rotation de token. Si tous les processeurs traitent de manière égale, cette valeur peut être grande (300). pour réduire la latence dans les grand ring (›=16), le défaut est un compromis de sûreté. Si un ou plusieurs processeur sont lents, window_size ne devrait pas être supérieur à 256000 / netmtu pour éviter la surchage des tampon. Défaut: 50 messages.
max_messages Cette constante spécifie le nombre maximum de messages qui peuvent être envoyés par un processeur à la réception du token. Ce paramètre est limité à 256000 / netmtu pour empêcher la saturation des tampons de transmission.
miss_count_const Définie le nombre maximum de fois à la réception d'un token qu'un message est vérifié pour retransmission avant qu'une retransmission se produise. Défaut: 5 messages.
rrp_problem_count_timeout Spécifie le temps en ms d'attente avant de décrémenter le compteur de problème de 1 pour un ring particulier pour s'assurer qu'un lien n'est pas marqué en panne. (Défaut: 2000 ms)
rrp_problem_count_threshold Spécifie le nombre de fois qu'un problème est détecté avec un lien avec de définir ce lien en faute. Une fois en faute, plus aucune donnée n'est émise sur ce lien. Également, le compteur de problème n'est plus décrémenté quand le timeout de compteur de problème expire. Un problème est détecté quand tous les tokens d'un processeur n'a pas été reçus dans le rrp_token_expired_timeout. Les rrp_problem_count_threshold * rrp_token_expired_timeout devrait être au moins à 50ms inférieur au timeout du token, ou une reconfiguration complète peut se produire. Défaut: 10 problèmes.
rrp_problem_count_mcast_threshold Spécifie le nombre de fois qu'un problème est détecté avec un multicast avant de définis le lien en faute pour un mode rrp passif. Cette variable n'est pas utilisée pour un mode rrp actif.
rrp_token_expired_timeout Spécifie le temps en ms pour incrémenter le compteur de problème pour le rrp après avoir reçu un token de tous les rings pour un processeur particulier. Cette valeur est automatiquement calculée du timeout de token et problem_count_threshold mais peut être écrasé. Défaut: 47ms
rrp_autorecovery_check_timeout Spécifie le temps en ms pour vérifier si le ring en panne peut être auto-récupéré.

Options logging

timestamp Spécifie si un horodatage est placé dans les messages de log. Défaut: off
fileline spécifique que le fichier et la ligne devrait être affichés. Défaut: off
function_name Spécifie que le nom de la fonction devrait être affiché. Défaut: off
to_stderr
to_logfile
to_syslog spécifient la sortie de logging. peut être yes ou no. Défaut: syslog et stderr
logfile si to_logfile est à yes, cette option spécifie le chemin du fichier de log.
logfile_priority Priorité du logfile pour un sous-système particulier. Ignoré si debug est on. (alert,crit, debug, emerg, err, info, notice, warning) Défaut: info.
syslog_facility Type de facilité syslog ( daemon, local0, local1, local2, local3, local4, local5, local6 et local7). Défaut: daemon
syslog_priority Log level pour le sous-système particulier ( alert, crit, debug, emerg, err, info, notice, warning ) Défaut: info
debug Active le debug. Défaut: off.

Options logger_subsys

Toutes les options de la directive logging sont valide, plus:
subsys Spécifie le nom du sous-système pour lequel le logging est spécifié. C'est le nom utilisé par un service dans l'appel log_init. Cette directive est requise.

Options quorum

provider seul corosync_votequorum est supporté.

Options nodelist

ringX_addr Spécifie l'adresse IP d'un des nœuds. X est le numéro du ring.
nodeid Requis pour IPv6, optionnel pour IPv4. valeur 32bits spécifiant l'identifiant du nœud délivré au service de cluster membership. 0 est réservé et ne doit pas être utilisé.

Options qb

ipc_type Type d'IPC à utiliser. Peut être native, shm et socket. Native signifie soit shm soit socket, en fonction de ce qui est supporté par l'OS. shm est généralement plus rapide, mais nécessite d'allouer un tampon ring dans /dev/shm.
^
26 janvier 2015

htmlpdflatexmanmd




corosync.xml

corosync.xml

version xml du fichier corosync.conf

   /etc/corosync/corosync.xml est utilisé par corosync-xmlproc pour générer un fichier de configuration valide. Ce fichier doit être un fichier xml valide, commençant avec l'élément racine corosync qui peut contenir les mêmes arguments que décris dans corosync.conf.

^
26 janvier 2015

htmlpdflatexmanmd




votequorum

votequorum

configuration pour votequorum

L'extrait corosync.conf suivant va activer le service votequorum avec corosync:
quorum {
    provider: corosync_votequorum
}

   votequorum lis sa configuration depuis corosync.conf. Certaines valeurs peuvent être changé en temps réel, d'autres sont seulement lues au lancement de corosync. Il est très important que ces valeurs soient consistantes entre tous les nœuds participant au cluster.

   votequorum requière une valeur expected_votes pour fonctionner, qui peut être fait de 2 manières. Le nombre de votes attendus sera automatiquement calculé quand la section nodelist est présente dans corosync.conf, ou expected_votes peut être spécifié dans la section quorum. Le manque des 2 définissions désactive votequorum. Si les 2 sont présents, la valeur de la section quorum a précédence.

Exemple (sans nodelist) d'un cluster de 8 nœuds (chaque nœud a 1 vote):
quorum {
    provider: corosync_votequorum
    expected_votes: 8
}

Exemple (avec nodelist) d'un cluster de 3 nœuds (chaque nœud a 1 vote):
quorum {
    provider: corosync_votequorum
}
    
nodelist {
    node {
        ring0_addr: 192.168.1.1
    }
    node {
        ring0_addr: 192.168.1.2
    }
    node {
        ring0_addr: 192.168.1.3
    }
}

Fonctionnalités spéciales

   two_node: 1 active les opération de cluster à 2 nœuds (défaut: 0). Ce mode est un cas qui nécessite une considération spéciale. Avec un cluster à 2 nœuds, chaque nœud avec un simple vote, il y a donc 2 votes dans le cluster. Utiliser le calcule de majorité (50% de vote + 1) pour calculer le quorum implique que le quorum est de 2. Cela signifie que les 2 nœuds doivent toujours être en fonction pour que le quorum soit opérationnel.

Activer le two_node, le quorum est définis artificiellement à 1:
quorum {
    provider: corosync_votequorum
    expected_votes: 2
    two_node: 1
}

ou:
quorum {
    provider: corosync_votequorum
    two_node: 1
}
    
nodelist {
    node {
        ring0_addr: 192.168.1.1
    }
    node {
        ring0_addr: 192.168.1.2
    }
}

   Notes: activer le two_node active automatiquement wait_for_all. Il reste possible de changer wait_for_all dans la configuratio. Si plus de 2 nœuds sont joins au cluster, l'option two_node est automatiquement désactivé.

   wait_for_all: 1 (défaut: 0). le fonctionnement général de votequorum est de basculer d'un état 'inquorate' à un état 'quorate' dès que possible. Par exemple, dans un cluster à 8 nœuds, où tous les nœuds ont un vote à 1, expected_votes est à 8, et quorum est à 5 ( 50% + 1 ). Dès qu'au moins 5 nœuds sont visibles entre-eux, la partition d'au moins 5 devient 'quorate' et peut commencer à opérer. Quand WFA est activé, le cluster attend que tous les nœuds sont visibles au moins un fois. C'est utile combiné avec last_man_standing.

Exemple de configuration:
quorum {
    provider: corosync_votequorum
    expected_votes: 8
    wait_for_all: 1
}

   last_man_standing: 1 / last_man_standing_window: 10000. Active le LMS (Last Man Standing), défaut: 0. Le fonctionnement général de votequorum est de définir expected_votes et quorum au démarrage et d'utiliser ces valeurs durant toute la duées du cluster. En utilisant l'exemple d'un cluster 8 nœuds où chaque nœud a 1 vote, expected_votes est définis à 8 et quorum à 5. Cette condition permet un total de 3 pannes. Si une 4ème panne se produit, le cluster devient 'inquorate' et il va stopper les services. LMS permet au cluster de recalculer dynamiquement expected_votes et quorum sous des conditions spécifiques. Il est essentiel d'active WFA en utilisant LMS. En utilisant un cluster à 8 nœud, LMS permet de poursuivre le quorum opérant en perdant en cascade, jusqu'à 6 nœuds.

Exemple

- Le cluster est pleinement opérationnel avec 8 nœuds ( expected_votes: 8, quorum: 5)
- 3 nœuds tombent en panne, le cluster reste en quorum avec 5 mœuds
- Après last_man_standing_window millisecondes, expected_votes et quorum sont recalculés: expected_votes: 5 quorum: 3.
- À ce point, 2 nœuds supplémentaires peuvent être en panne et le quorum est maintenu avec 3 nœuds.
- Encore une fois, les valeurs sont recalculées: expected_votes: 3 quorum: 2
- À ce point, 1 nœud peut tomber en panne et le quorum est maintenu avec 2 nœuds
- Une fois de plus: expected_votes: 2 quorum: 2

   Notes: pour que le cluster descende automatiquement de 2 nœuds à 1 nœuds, auto_tie_breaker doit également être activé.

Exemple de configuration:
quorum {
    provider: corosync_votequorum
    expected_votes: 8
    last_man_standing: 1
}

ou (augmente le timeout à 20 secondes):
quorum {
    provider: corosync_votequorum
    expected_votes: 8
    last_man_standing: 1
    last_man_standing_window: 20000
}

   auto_tie_breaker: 1 active ATB (Auto Tie Breaker), défaut: 0. Le fonctionnement général de votequorum permet de perdre simultanément 50% -1 nœud, assumant que chaque nœud a 1 vote. Quand ATB est activé, le cluster pour perdre jusqu'à 50% de nœuds en même temps. Par défaut le cluster, ou le jeu de nœuds qui sont en contacte avec le nœud qui a le nodeid le plus faible restera en quorum. Les autres nœuds deviennent 'inquorate'. Ce mode peut être changé avec:

   auto_tie_breaker_node: lowest|highest|‹list of node IDs› 'lowest' est le défaut. Alternativement il est possible de spécifier un id de nœud qui sera requis pour maintenir le quorum. Si une liste de nœud est donnée, les nœuds sont évalués dans l'ordre, donc si le premier est présent il sera utilisé pour déterminer la partition 'quorate', si ce nœud n'est pas disponible, le second est vérifié.

exemple de configuration:
quorum {
    provider: corosync_votequorum
    expected_votes: 8
    auto_tie_breaker: 1
    auto_tie_breaker_node: lowest
}

autre exemple:
quorum {
    provider: corosync_votequorum
    expected_votes: 8
    auto_tie_breaker: 1
    auto_tie_breaker_node: 1 3 5
}

   allow_downscale: 1, active l'AD (Allow Downscale), défaut: 0. Votequorum ne descend jamais les votes du quorum. Avec AD activé, les expected_votes et quorum sont recalculés quand un nœud quitte le cluster dan un état clean.

1) Un cluster de N nœuds ( N est supérieur à 3).
2) expected_votes est à 3
3) Seul 3 nœuds fonctionnent
4) l'admin souhaite augmenter le traitement et ajouter 10 nœuds
5) expected_votes est automatiquement définis à 13
6) expected_votes minimum est de 3 (définis dans la configuration)
- À ce point, le votequorum fonctionne normalement.
7) L'admin souhaite supprimer des nœuds du cluster
8) En utilisant un shutdown ordonné, l'admin peut réduire la taille du cluster automatiquement jusqu'à 3, mais pas en dessous.

Exemples de configuration:
quorum {
    provider: corosync_votequorum
    expected_votes: 3
    allow_downscale: 1
}

   expected_votes_tracking: 1 Active l'EVT (Expected Votes Tracking), défaut: 0. l'EVT stocke la plus haute valeur vue des votes attendus sur disque et l'utilise comme valeur minimum pour les votes attendus en l'absence d'une haute autorité. C'est utile quand un groupe de nœuds devient détaché du cluster principal et après un redémarrage pouvant avoir suffisamment de votes pour fournir un quorum, qui peut se produire en utilisant allow_downscale. Noter que même si la version en mémoire de expected_votes est réduite, par exemple en utilisant corosync-quorumtool, la valeur stockée supérieur à la valeur vue, qui n'est jamais réduite. La valeur est maintenue dans le fichier /var/lib/corosync/ev_tracking qui peut être supprimée si vous n'avez pas besoin d'expected_votes.

Notes

- WFA / LMS / ATB / AD peuvent être combinés ensembles
- Pour changer les votes par défau pour un nœud il y a 2 options:

nodelist:
nodelist {
    node {
        ring0_addr: 192.168.1.1
        quorum_votes: 3
    }
    ....
}

ou quorum (déprécié):
quorum {
    provider: corosync_votequorum
    expected_votes: 2
    votes: 2
}

   Dans le cas où votes dans nodelist et quorum sont définis, la valeur de nodelist est utilisée.

  Seul votes, quorum_votes, expected_votes et two_node peuvent être changé en temps réels. Le reste nécessite de redémarrer le cluster.