Diferències

Ací es mostren les diferències entre la revisió seleccionada i la versió actual de la pàgina.

Enllaç a la visualització de la comparació

--- cluster_hardware_amb_pacemaker_i_corosync [2023/07/01 19:23]
isaac_gonzalo_rivero [Infraestructura]
+++ cluster_hardware_amb_pacemaker_i_corosync [2023/07/06 06:52] (actual)
isaac_gonzalo_rivero
@@ Línia 1: / Línia 1: @@
-====== Cluster amb Pace Maker i Heartbeat ======
+====== Cluster amb Pace Maker i Corosync ======
-{{tag> #ASIXMp11Uf04 #ASIXMp11 #ASIX #FpInfor PaceMaker HeartBeat cluster }}
+{{tag> #ASIXMp11Uf04 #ASIXMp11 #ASIX #FpInfor PaceMaker Corosync cluster }}
 ===== Introducció =====
 De vegades necessitem crear un cluster amb més seguretat que un contenidor o màquina virtual, ja que en cas que ens guanyin accés a la màquina física, si muntem un entorn amb docker en alta disponibilitat, ens el poden tombar igualment, es per això que en aquests casos podem optar per un cluster hardware. Exemple d’això poden ser muntar un cluster de firewall o de routing.
@@ Línia 9: / Línia 10: @@
 ==== 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, en cas que el node amb el servei quedi bloquejat poder reiniciar-lo des de un altre node, per això primer definirem conceptes
+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, en cas que el node amb el servei quedi bloquejat poder reiniciar-lo des de un altre node, per això primer definirem conceptes:
-**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'aillament de un dels nodes, aquest podrà definir si el problema es propi o forani, si pot accedir a un dels altres 2 nodes.
-**Split-Brain**: Situació del cluster on dos o més nodes poden considerar-se actius alhora e intentar asumir el control dels recursos compartits al mateix moment. Això pot generar incosistències i conflictes a les dades.
-**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'apagada de un node considerat inestable o en fallida. Es un mecanisme pensat per evitar que diferents nodes del cluster puguin accedir als mateixos recursos de forma simultània. Això podria derivar en una situació coneguda com Split-Brain, Aquesta es una mesura extrema que força l'apagada de una màquina, i ha d'evitar, en la mesura del possible apagar un node que funcioni correctament.
-**Heartbeat**: Mecanisme de comunicació entre els diferents nodes del cluster per monitoritzar i verificar l'estat dels nodes del cluster. Utilitza una xarxa pròpia i exclusiva per on els nodes del cluster es comunicaràn a efectes de mantenir el servei actiu, controlar les fallades. Pot ser un simple ping, o un missatge més complex que inclogui informació adicional del estat i la carrega de cada node.
+  * **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'aillament de un dels nodes, aquest podrà definir si el problema es propi o forani, si pot accedir a un dels altres 2 nodes.
+  * **Split-Brain**: Situació del cluster on dos o més nodes poden considerar-se actius alhora e intentar asumir el control dels recursos compartits al mateix moment. Això pot generar incosistències i conflictes a les dades.
+  * **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'apagada de un node considerat inestable o en fallida. Es un mecanisme pensat per evitar que diferents nodes del cluster puguin accedir als mateixos recursos de forma simultània. Això podria derivar en una situació coneguda com Split-Brain, Aquesta es una mesura extrema que força l'apagada de una màquina, i ha d'evitar, en la mesura del possible apagar un node que funcioni correctament.
+  * **Heartbeat**: Mecanisme de comunicació entre els diferents nodes del cluster per monitoritzar i verificar l'estat dels nodes del cluster. Utilitza una xarxa pròpia i exclusiva per on els nodes del cluster es comunicaràn a efectes de mantenir el servei actiu, controlar les fallades. Pot ser un simple ping, o un missatge més complex que inclogui informació adicional del estat i la carrega de cada node.
+  * **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'encarreguen d'aïllar els nodes problemàtics per a evitar que afectin la resta del clúster. Això s'aconsegueix mitjançant mètodes com l'apagat remot o el reinici de nodes, l'aïllament a través d'interruptors d'alimentació o el bloqueig de ports de xarxa. Els agents de clos asseguren l'estabilitat i la continuïtat de les operacions en el clúster, mantenint l'alta disponibilitat i la tolerància a fallades.
 ===== Requisits previs =====
@@ Línia 453: / Línia 453: @@
 I comprovar que els serveis estan engegats
+<code bash>
+# crm status
+Status of pacemakerd: 'Pacemaker is running' (last updated 2023-07-01 21:23:43 +02:00)
+Cluster Summary:
+  * Stack: corosync
+  * Current DC: node2 (version 2.1.5-a3f44794f94) - partition with quorum
+  * Last updated: Sat Jul  1 21:23:43 2023
+  * Last change:  Sat Jul  1 21:15:39 2023 by hacluster via crmd on node2
+  * 3 nodes configured
+  * 0 resource instances configured
-===== Operació ======
+Node List:
+  * Online: [ node1 node2 node3 ]
+Full List of Resources:
+  * No resources
+</code>
+Ara ja tenim el cluster creat. Només falta afegir serveis al cluster
+=== Serveis ===
+== Introducció ==
+Els serveis del cluster, també anomenats recursos, son els recursos que s'aniràn migrant de node a node mentre estigui el cluster disponible.
+Per afegir els recursos, ho farem des de una màquina i fent servir l'entorn que corosync ens posa a disposició per editar-los. Aquest es la shell **crm** (Cluster Resource Manager)
+<code bash>
+crm
+</code>
+Amb aquesta shell podem fer servir el tabulador per saber les opcions que tenim disponibles i per finalitzar les paraules que volem pasar-li, podem fer servir la comanda help per mostrar ajuda sobre les comandes.
+N'afegirem els següents recursos:
+  * IP flotant que ens donarà el servei al servidor Web (!72.16.84.10/24)
+  * El servei web mateix (Nginx)
+  * Els agents de tanca dels nodes (fence_node1, fence_node2, fence_node3): Aquests agents es faran correr en els nodes que vigilen el node vallat, es a dir, en els nodes que no apareixen al nom del agent.
+== IP i Nginx ==
+Obrim **crm configure**:
+<code bash>
+crm configure
+</code>
+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/node1)configure#
+        property stonith-enabled=no
+        property no-quorum-policy=ignore
+</code>
+Ara, afegim els recursos per l'nginx (Aquest nginx l'hem instal·lat en el pas de generació de nodes, previament):
+Recorda, que si les teves IP's son diferents, les has de modificar, i has de definir l'adaptador que correspongui (Hauria de ser el mateix a tots els nodes!!!)
+<code bash>
+crm(live/node1)configure# primitive IP-nginx ocf:heartbeat:IPaddr2 params ip="172.16.84.10" nic="ens160" cidr_netmask="24" meta migration-threshold=2 op monitor interval=20 timeout=60 on-fail=restart
+crm(live/node1)configure# primitive Nginx-rsc ocf:heartbeat:nginx meta migration-threshold=2 option monitor interval=20 timeout=60 on-fail=restart
+crm(live/node1)configure# colocation lb-loc inf: IP-nginx Nginx-rsc
+crm(live/node1)configure# order lb-ord inf: IP-nginx Nginx-rsc
+crm(live/node1)configure# commit
+</code>
+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>crm(live/node1)configure# up
+resource stop "nom_del_recurs"
+configure delete "nom_del_recurs"
+commit</code>
+  * 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/node1)# cib new fencing
+INFO: cib.new: fencing shadow CIB created
+crm(fencing/node1)#
+</code>
+Per veure quins agents de //stonith// tenim, podem executar des de la linia de comandes de qualsevol node:
+<code bash>
+stonith_admin -I
+</code>
+Hi ha molts. Els executables son a **/usr/sbin** i al **man** de cada un d'ells surten les opcions que s'hi poden fer servir.
+Nosaltres farem servir **fence_virsh**, asumint que els nostres nodes son accesssibles via ssh, i hem habilitat l'access com a root. Si no fos així hauriem de configurar sudo per permetre que un usuari pogues executar les accions del cluster.
+<code bash>
+crm(fencing/node1)# configure
+crm(fencing/node1)configure# property stonith-enabled=yes
+crm(fencing/node1)configure# primitive fence_node01 stonith:fence_virsh params ipaddr=172.16.84.11 port=node1 action=off login=root passwd=Hola123 op monitor interval=60s
+crm(fencing/node1)configure# primitive fence_node02 stonith:fence_virsh params ipaddr=172.16.84.12 port=node2 action=off login=root passwd=Hola123 op monitor interval=60s
+crm(fencing/node1)configure# primitive fence_node03 stonith:fence_virsh params ipaddr=172.16.84.13 port=node3 action=off login=root passwd=Hola123 op monitor interval=60s
+crm(fencing/node1)configure# location l_fence_node01 fence_node01 -inf: node1
+crm(fencing/node1)configure# location l_fence_node02 fence_node02 -inf: node2
+crm(fencing/node1)configure# location l_fence_node03 fence_node03 -inf: node3
+commit
+</code>
+Amb això ja tindriem generats els agents de tanca. Podem simular el funcionament amb la nova cib:
+<code bash>
+crm(fencing/node1)configure# cib cibstatus simulate
+Current cluster status:
+  * Node List:
+    * Online: [ node1 node2 node3 ]
+  * Full List of Resources:
+    * IP-nginx	(ocf:heartbeat:IPaddr2):	 Started node2
+    * Nginx-rsc	(ocf:heartbeat:nginx):	 Started node2
+    * fence_node01	(stonith:fence_virsh):	 Stopped
+    * fence_node02	(stonith:fence_virsh):	 Stopped
+    * fence_node03	(stonith:fence_virsh):	 Stopped
+Transition Summary:
+  * Start      fence_node01     ( node3 )
+  * Start      fence_node02     ( node1 )
+  * Start      fence_node03     ( node1 )
+Executing Cluster Transition:
+  * Resource action: fence_node01    monitor on node3
+  * Resource action: fence_node01    monitor on node2
+  * Resource action: fence_node01    monitor on node1
+  * Resource action: fence_node02    monitor on node3
+  * Resource action: fence_node02    monitor on node2
+  * Resource action: fence_node02    monitor on node1
+  * Resource action: fence_node03    monitor on node3
+  * Resource action: fence_node03    monitor on node2
+  * Resource action: fence_node03    monitor on node1
+  * Resource action: fence_node01    start on node3
+  * Resource action: fence_node02    start on node1
+  * Resource action: fence_node03    start on node1
+  * Resource action: fence_node01    monitor=60000 on node3
+  * Resource action: fence_node02    monitor=60000 on node1
+  * Resource action: fence_node03    monitor=60000 on node1
+Revised Cluster Status:
+  * Node List:
+    * Online: [ node1 node2 node3 ]
+  * Full List of Resources:
+    * IP-nginx	(ocf:heartbeat:IPaddr2):	 Started node2
+    * Nginx-rsc	(ocf:heartbeat:nginx):	 Started node2
+    * fence_node01	(stonith:fence_virsh):	 Started node3
+    * fence_node02	(stonith:fence_virsh):	 Started node1
+    * fence_node03	(stonith:fence_virsh):	 Started node1
+</code>
+I, si tot sembla correcte, podem pasar els canvis a producció:
+<code bash>
+crm(fencing/node1)configure# cib commit
+INFO: configure.cib.commit: committed 'fencing' shadow CIB to the cluster
+crm(fencing/node1)configure# cib use
+crm(live/node1)configure#
+</code>
+Per fer un check de l'status podem fer-ho amb **crm status*
+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:  Mon Jul  3 08:40:06 2023 by root via cibadmin on node1
+  * 3 nodes configured
+  * 5 resource instances configured
+Node List:
+  * Online: [ node1 node2 node3 ]
+Active Resources:
+  * IP-nginx    (ocf:heartbeat:IPaddr2):         Started node2
+  * Nginx-rsc   (ocf:heartbeat:nginx):   Started node2
+  * fence_node01        (stonith:fence_virsh):   Started node3
+  * fence_node02        (stonith:fence_virsh):   Started node1
+  * fence_node03        (stonith:fence_virsh):   Started node1
+</code>
+Amb això ja tindrem el nostre Nginx en cluster corrent en 3 nodes, i podem jugar tancant i encenent nodes i comprovar com l'Nginx continua funcionant independentment del node on corri.
 ===== Referències =====
@@ Línia 463: / Línia 660: @@
 https://wiki.debian.org/Debian-HA/ClustersFromScratch
+https://clusterlabs.org/

bytes.cat

Eines de l'usuari

Eines del lloc

Diferències

Eines de la pàgina