Ací es mostren les diferències entre la revisió seleccionada i la versió actual de la pàgina.
Ambdós costats versió prèvia Revisió prèvia Següent revisió | Revisió prèvia | ||
cluster_hardware_amb_pacemaker_i_corosync [2023/07/01 19:44] isaac_gonzalo_rivero [Conceptes previs] |
cluster_hardware_amb_pacemaker_i_corosync [2023/07/06 06:52] (actual) isaac_gonzalo_rivero |
||
---|---|---|---|
Línia 10: | Línia 10: | ||
==== Conceptes previs ==== | ==== Conceptes previs ==== | ||
- | De totes maneres, i al igual que en qualsevol altre cluster, es molt recomanable fer el cluster amb 3 nodes. Això es degut a que, en cas que hi hagi una desconnexió de qualsevol dels nodes del cluster, el tercer cluster serveix per tenir quorum. També necessitarem, | + | De totes maneres, i al igual que en qualsevol altre cluster, es molt recomanable fer el cluster amb 3 nodes. Això es degut a que, en cas que hi hagi una desconnexió de qualsevol dels nodes del cluster, el tercer cluster serveix per tenir quorum. També necessitarem, |
* **Quorum**: Quantitat mínima de nodes o membres necessaris perque un servei funcioni correctament. Per tal que un sistema sigui minimament fiable, el minim de nodes necessaris es 3, això es degut a, en cas d' | * **Quorum**: Quantitat mínima de nodes o membres necessaris perque un servei funcioni correctament. Per tal que un sistema sigui minimament fiable, el minim de nodes necessaris es 3, això es degut a, en cas d' | ||
- | |||
* **Split-Brain**: | * **Split-Brain**: | ||
- | |||
* **STONITH** (Shot The Other Node In The Head): Mecanisme del cluster per protecció i recuperació davant de fallades. Es una tècnique que garantitza la disponibilitat i la integritat forçant l' | * **STONITH** (Shot The Other Node In The Head): Mecanisme del cluster per protecció i recuperació davant de fallades. Es una tècnique que garantitza la disponibilitat i la integritat forçant l' | ||
- | |||
* **Heartbeat**: | * **Heartbeat**: | ||
+ | * **Cluster Information Base** o **CIB**: Base de dades del cluster, replicada a tots els nodes, on es guarda la configuració dels recursos del cluster i les seves caracteristiques. | ||
+ | * **Agents de tanca** (fence agents, en anglés): Els agents de tanca en un clúster són components o programes utilitzats per a garantir la disponibilitat i la integritat dels recursos. S' | ||
- | |||
- | * **Cluster Information Base** o **CIB**: Base de dades del cluster, replicada a tots els nodes, on es guarda la configuració dels recursos del cluster i les seves caracteristiques | ||
===== Requisits previs ===== | ===== Requisits previs ===== | ||
Línia 478: | Línia 475: | ||
=== Serveis === | === Serveis === | ||
+ | == Introducció == | ||
Els serveis del cluster, també anomenats recursos, son els recursos que s' | Els serveis del cluster, també anomenats recursos, son els recursos que s' | ||
Línia 491: | Línia 489: | ||
* IP flotant que ens donarà el servei al servidor Web (!72.16.84.10/ | * IP flotant que ens donarà el servei al servidor Web (!72.16.84.10/ | ||
+ | * El servei web mateix (Nginx) | ||
+ | * Els agents de tanca dels nodes (fence_node1, | ||
+ | == IP i Nginx == | ||
- | ===== Operació | + | Obrim **crm configure**: |
+ | |||
+ | <code bash> | ||
+ | crm configure | ||
+ | </ | ||
+ | |||
+ | I executem les seguents comandes per habilitar el agents de tanca més endavant (stonith-enable) i habilitar que el cluster continui funcionant amb un sol node (no-quorum-policy) | ||
+ | |||
+ | ≤code bash> | ||
+ | crm(live/ | ||
+ | property stonith-enabled=no | ||
+ | property no-quorum-policy=ignore | ||
+ | </ | ||
+ | |||
+ | Ara, afegim els recursos per l' | ||
+ | |||
+ | Recorda, que si les teves IP's son diferents, les has de modificar, i has de definir l' | ||
+ | |||
+ | <code bash> | ||
+ | crm(live/ | ||
+ | crm(live/ | ||
+ | crm(live/ | ||
+ | crm(live/ | ||
+ | crm(live/ | ||
+ | </ | ||
+ | |||
+ | Amb això, hem creat 2 recursos (IP-nginx i Nginx-rsc) i hem definit que: | ||
+ | * Els dos recursos corrin al mateix node | ||
+ | * La IP sempre estigui disponible | ||
+ | |||
+ | Si en qualsevol moment ens equivoquem a l'hora de generar els recursos, (ens apareix qualsevol error per pantalla): | ||
+ | * Haurem de parar el recurs: <code bash> | ||
+ | resource stop " | ||
+ | configure delete " | ||
+ | commit</ | ||
+ | * Regenerar el recurs correctament i les subseqüents comandes. | ||
+ | |||
+ | == Agents de tanca == | ||
+ | |||
+ | La tanca es posa, perque, en cas que hi hagi un node malfuncionant per qualsevol motiu, es pugui aïllar del cluster | ||
+ | |||
+ | Per evitar tocar la base de dades del cluster, i liar-la parda, primer generarem una CIB de proves (//Shadow cib//) | ||
+ | |||
+ | <code bash> | ||
+ | crm(live/ | ||
+ | INFO: cib.new: fencing shadow CIB created | ||
+ | crm(fencing/ | ||
+ | </ | ||
+ | |||
+ | Per veure quins agents de //stonith// tenim, podem executar des de la linia de comandes de qualsevol node: | ||
+ | |||
+ | <code bash> | ||
+ | stonith_admin -I | ||
+ | </ | ||
+ | |||
+ | Hi ha molts. Els executables son a **/ | ||
+ | |||
+ | Nosaltres farem servir **fence_virsh**, | ||
+ | |||
+ | <code bash> | ||
+ | crm(fencing/ | ||
+ | crm(fencing/ | ||
+ | crm(fencing/ | ||
+ | crm(fencing/ | ||
+ | crm(fencing/ | ||
+ | crm(fencing/ | ||
+ | crm(fencing/ | ||
+ | crm(fencing/ | ||
+ | commit | ||
+ | </ | ||
+ | |||
+ | Amb això ja tindriem generats els agents de tanca. Podem simular el funcionament amb la nova cib: | ||
+ | |||
+ | <code bash> | ||
+ | crm(fencing/ | ||
+ | Current cluster status: | ||
+ | * Node List: | ||
+ | * Online: [ node1 node2 node3 ] | ||
+ | |||
+ | * Full List of Resources: | ||
+ | * IP-nginx (ocf: | ||
+ | * Nginx-rsc (ocf: | ||
+ | * fence_node01 (stonith: | ||
+ | * fence_node02 (stonith: | ||
+ | * fence_node03 (stonith: | ||
+ | |||
+ | Transition Summary: | ||
+ | * Start fence_node01 | ||
+ | * Start fence_node02 | ||
+ | * Start fence_node03 | ||
+ | |||
+ | Executing Cluster Transition: | ||
+ | * Resource action: fence_node01 | ||
+ | * Resource action: fence_node01 | ||
+ | * Resource action: fence_node01 | ||
+ | * Resource action: fence_node02 | ||
+ | * Resource action: fence_node02 | ||
+ | * Resource action: fence_node02 | ||
+ | * Resource action: fence_node03 | ||
+ | * Resource action: fence_node03 | ||
+ | * Resource action: fence_node03 | ||
+ | * Resource action: fence_node01 | ||
+ | * Resource action: fence_node02 | ||
+ | * Resource action: fence_node03 | ||
+ | * Resource action: fence_node01 | ||
+ | * Resource action: fence_node02 | ||
+ | * Resource action: fence_node03 | ||
+ | |||
+ | Revised Cluster Status: | ||
+ | * Node List: | ||
+ | * Online: [ node1 node2 node3 ] | ||
+ | |||
+ | * Full List of Resources: | ||
+ | * IP-nginx (ocf: | ||
+ | * Nginx-rsc (ocf: | ||
+ | * fence_node01 (stonith: | ||
+ | * fence_node02 (stonith: | ||
+ | * fence_node03 (stonith: | ||
+ | |||
+ | </ | ||
+ | |||
+ | I, si tot sembla correcte, podem pasar els canvis a producció: | ||
+ | |||
+ | <code bash> | ||
+ | crm(fencing/ | ||
+ | INFO: configure.cib.commit: | ||
+ | crm(fencing/ | ||
+ | crm(live/ | ||
+ | </ | ||
+ | |||
+ | Per fer un check de l' | ||
+ | |||
+ | que ens haurà de donar un resultat semblant al següent: | ||
+ | |||
+ | <code bash> | ||
+ | crm_mon | ||
+ | |||
+ | Cluster Summary: | ||
+ | * Stack: corosync | ||
+ | * Current DC: node2 (version 2.1.5-a3f44794f94) - partition with quorum | ||
+ | * Last updated: Mon Jul 3 08:41:48 2023 | ||
+ | * Last change: | ||
+ | * 3 nodes configured | ||
+ | * 5 resource instances configured | ||
+ | |||
+ | Node List: | ||
+ | * Online: [ node1 node2 node3 ] | ||
+ | |||
+ | Active Resources: | ||
+ | * IP-nginx | ||
+ | * Nginx-rsc | ||
+ | * fence_node01 | ||
+ | * fence_node02 | ||
+ | * fence_node03 | ||
+ | |||
+ | </ | ||
+ | |||
+ | Amb això ja tindrem el nostre Nginx en cluster corrent en 3 nodes, i podem jugar tancant i encenent nodes i comprovar com l' | ||
===== Referències ===== | ===== Referències ===== | ||
Línia 502: | Línia 660: | ||
https:// | https:// | ||
+ | |||
+ | https:// | ||