PAF

...Une brique dans la mare de la HA

Qui suis-je ?

• Jehan-Guillaume de Rorthais
• aka. ioguix
• utilise PostgreSQL depuis 2007
• dans la communauté depuis 2008
• @dalibo depuis 2009

Au menu

• intro sur la HA
• intro sur Pacemaker
• pourquoi PAF
• Fonctionnalités de PAF

Haute Disponibilité

 Rappels sur la HA

• High Availability, aka. Haute disponibilité
• Intégrée dans un Plan de Continuité de Service
• En gros, on double tout
• Bascule automatique ou non ?

 Bascule auto: techniquement

Complexe à mettre en œuvre:

• comment détecter une vraie défaillance ?
• le maître ne répond plus ?
• est-il vraiment éteint ?
• est-il vraiment inactif ?
• comment réagir à une panne réseau ?
• comment éviter les split brain ?

 Bascule auto: apprentissage

La route est (presque) droite mais la pente forte:

• plusieurs problèmes/mécaniques à comprendre: quorum, fencing, watchdog, ...
• configuration pointue
• maintenances complexes
• documenter, documenter, documenter
• tester, tester, tester

Si vous ne voulez pas de complexité, n'en faites pas.

 Pacemaker

Apprentissage difficile...

...Toute résistance est futile.

Généralités sur Pacemaker

• est LA référence de la HA sous Linux
• est un "Cluster Resource Manager"
• supporte les fencing, quorum et watchdog
• multi-service, avec dépendances, ordre, contraintes, règles, etc
• s'interface avec n'importe quel service
• chaque service a son Resource Agent
• RA stateless ou multi-state
• API possibles: script OCF, upstart, systemd, LSB

 Archi Pacemaker

 Mécanique du CRM

• sorte d'automate
• 4 états: arrêté, démarré, slave ou master
• calcul de transitions pour passer d'un état à l'autre
• API classique (eg. systemd): start, stop, monitor(status)
• API OCF: start, stop, promote, demote, monitor, notify
• cas d'une ressource multi-state:

Action notify

• seulement possible avec RA OCF
• déclenchés avant et après chaque action
• permet au RA d'effectuer des opérations