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/03 05:36]
isaac_gonzalo_rivero [Conceptes previs]
+++ cluster_hardware_amb_pacemaker_i_corosync [2023/07/06 06:52] (actual)
isaac_gonzalo_rivero
@@ Línia 16: / Línia 16: @@
   * **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.
+  * **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 476: / Línia 475: @@
 === 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.
@@ Línia 490: / Línia 490: @@
   * IP flotant que ens donarà el servei al servidor Web (!72.16.84.10/24)
   * El servei web mateix (Nginx)
-  * Els agents de vallat dels nodes (fence_node1, fence_node2, fence_node3)
+  * 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>
-===== Operació ======
+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 =====

bytes.cat

Eines de l'usuari

Eines del lloc

Diferències

Eines de la pàgina