{"id":2107,"date":"2016-07-01T09:53:52","date_gmt":"2016-07-01T07:53:52","guid":{"rendered":"https:\/\/inlab.fib.upc.edu\/?p=2107"},"modified":"2016-07-01T09:53:52","modified_gmt":"2016-07-01T07:53:52","slug":"pacemaker-alta-disponibilidad-para-linux","status":"publish","type":"post","link":"https:\/\/inlab.fib.upc.edu\/es\/uncategorized-ca\/pacemaker-alta-disponibilidad-para-linux","title":{"rendered":"Pacemaker: Alta disponibilidad para linux"},"content":{"rendered":"

Es bastante normal tener alta disponibilidad para servicios que se consideran cr\u00edticos dentro de una organizaci\u00f3n. En este caso concreto, pongamos que queremos implementar la alta disponibilidad para los sistemas de control perimetral (firewalls) que tenemos en una red controlada por inLab.<\/p>\n

El hecho de que uno de estos sistemas de control fallase dejar\u00eda la red aislada. Por lo tanto, es cr\u00edtico tener el servicio en alta redundancia de forma que si un servidor falla, otro asume el servicio.<\/p>\n

<\/p>\n

Introducci\u00f3n<\/h2>\n

Es bastante normal tener alta disponibilidad para servicios que se consideran cr\u00edticos dentro de una organizaci\u00f3n. En este caso concreto, pongamos que queremos implementar la alta disponibilidad para los sistemas de control perimetral (firewalls) que tenemos en una red controlada por inLab.<\/p>\n

El hecho de que uno de estos sistemas de control fallase dejar\u00eda la red aislada. Por lo tanto, es cr\u00edtico tener el servicio en alta redundancia de forma que si un servidor falla, otro asume el servicio.<\/p>\n

El software que hemos usado para tener alta disponibilidad se llama Pacemaker de Cluster Labs.<\/p>\n

Est\u00e1 disponible en la mayor\u00eda de distribuciones, directamente en la misma paqueter\u00eda, pero tambi\u00e9n podemos descargarnos el c\u00f3digo y compilarlo nosotros para nuestra plataforma.<\/p>\n

Conceptos<\/h2>\n

En nuestro caso tenemos dos servidores que ejecutan servicios cr\u00edticos por lo tanto hay que configurarlos con el software de alta disponibilidad de forma que se organicen los servicios, se monitoricen y si hay alg\u00fan problema, se pueda recuperar el servicio con el menor tiempo de fallo posible.<\/p>\n

Activo\/Activo vs. Activo\/Pasivo<\/h3>\n

Los cl\u00fasteres de servidores en alta disponibilidad se pueden organizar de forma que las dos m\u00e1quinas den el servicio o que una, la activa, lo d\u00e9 y la otra s\u00f3lo entre a dar servicio si la primera falla. La manera de aprovechar mejor los recursos seria hacer que las dos m\u00e1quinas ejecutasen el servicio, pero a veces no es posible ya que hay servicios que tienen estado y s\u00f3lo permitir\u00edan ejecuci\u00f3n en una m\u00e1quina. Es el caso de los firewalls, ya que hay el estado de las conexiones que es complicado sincronizar entre dos servidores, por lo tanto hemos optado por usar la configuraci\u00f3n activo-pasivo, una m\u00e1quina asume el rol de firewall primario y la otra se queda sin el servicio monitorizando si la primera falla. Con tal de que la m\u00e1quina que est\u00e1 pasiva no est\u00e9 sin hacer nada, hay otro servicio que nos va bien que se ejecute en alta disponibilidad, que es el proxy de Wake On Lan y con el Pacemaker podemos hacer que se ejecute preferentemente en el servidor que no tiene el firewall.<\/p>\n

De esta forma conseguimos que las dos m\u00e1quinas est\u00e9n ocupadas y aprovechamos un poco mejor los recursos.<\/p>\n

Recursos<\/h3>\n

Tenemos dos servidores que, seg\u00fan el Pacemaker, reciben el nombre de nodos<\/em>, el servicio de firewall que necesita un software (en este caso netfilter.org) con una pol\u00edtica, unas IPs \u201cflotantes\u201d y el servicio de Wake On Lan (a partir de ahora WoL).<\/p>\n

Las IPs flotantes son direcciones que no est\u00e1n asignadas a una m\u00e1quina sino que est\u00e1n conectadas al servicio y el servidor que ejecute el servicio es el que ha de tener esa direcci\u00f3n. Por lo tanto, reciben el nombre de flotantes porque pueden ir de una m\u00e1quina a otra dependiendo de donde est\u00e9 el servicio.<\/p>\n

Las dos m\u00e1quinas tienen que ser capaces de ejecutar las normas del firewall y el servicio de WoL. De forma que las dos tienen el netfilter, el software de WoL y las normas\/configuraciones. Esto lo conseguimos con el comando rsync ejecutado cada cierto tiempo desde el cron.<\/p>\n

Por lo tanto, identificamos como recursos las IPs flotantes m\u00e1s el software a ejecutar para ofrecer el firewall y el WoL.<\/p>\n

\"xarxa\"<\/p>\n

Prioridades<\/h3>\n

Con las prioridades podemos definir que un servicio se ejecute en una m\u00e1quina en concreto cuando las dos est\u00e1n en marcha, lo que hace es definir mayor prioridad a un nodo para un determinado servicio o conjunto de servicios. Esto nos va muy bien para definir las alarmas y documentaci\u00f3n de las m\u00e1quinas ya que definimos una como primaria para un determinado servicio y la otra como secundaria.<\/p>\n

Cu\u00f3rum<\/h3>\n

Un cl\u00faster tiene cu\u00f3rum cuando m\u00e1s de la mitad de los nodos del cl\u00faster est\u00e1n activos y han podido comunicarse satisfactoriamente. As\u00ed, si tenemos un cl\u00faster de 5 nodos, la red tiene un problema y 3 nodos quedan aislados de los otros 2, el minicl\u00faster de 3 nodos seguir\u00e1 sirviendo los servicios mientras que los otros 2 no lo har\u00e1n, ya que no llegan al cu\u00f3rum m\u00ednimo.<\/p>\n

En nuestro caso, el tema del cu\u00f3rum se trata diferente, ya que s\u00f3lo tenemos dos servidores, por lo tanto el funcionamiento es distinto y el cl\u00faster podr\u00eda llegar a funcionar con s\u00f3lo un servidor activo y el otro ca\u00eddo.<\/p>\n

Monitorizaci\u00f3n y Fencing<\/h3>\n

Los dos nodos del cl\u00faster est\u00e1n conectados a una red privada de forma que la comunicaci\u00f3n es lo m\u00e1s directa posible y se van monitorizando para ver que todo funciona correctamente (tienen cu\u00f3rum), cuando hay alg\u00fan problema en la comunicaci\u00f3n o un nodo detecta que el otro est\u00e1 malfuncionando (uno de los servicios cr\u00edticos no est\u00e1 en marcha, no responde suficientemente r\u00e1pido, hay problemas de disco, etc.) tiene que tomar la decisi\u00f3n de convertirse en nodo primario y ejecutar \u00e9l los servicios cr\u00edticos.<\/p>\n

Se podr\u00eda dar el caso que todos los servidores detectaran que hay alg\u00fan problema y los dos decidieran a la vez que el otro est\u00e1 malfuncionando, asumiendo tanto la IP como el servicio a la vez, lo que provocar\u00eda un caos en la red, esta situaci\u00f3n se conoce como split-brain. Para evitar esto tenemos el fencing.<\/p>\n

El mecanismo de fencing que usamos se llama STONITH que significa \u201cShoot The Other Node In The Head\u201d, que es una forma muy clara de explicar que un servidor \u201cdispara una bala a la cabeza\u201d del otro nodo, de forma que consigue pararlo para que no se d\u00e9 el problema de que los dos asuman el servicio (split-brain). Una vez parado el otro servidor puede asumir tranquilamente todos los servicios y recursos del cl\u00faster.<\/p>\n

Recuperaci\u00f3n<\/h3>\n

Una vez se ha producido un problema, se ha ejecutado el fencing y tenemos el servicio reestablecido a pesar de que en un cl\u00faster degradado (ya que habr\u00eda un servidor que se ha tenido que sacrificar) hace falta una intervenci\u00f3n t\u00e9cnica para volver a recuperar la situaci\u00f3n inicial. Es decir, poner en marcha el servidor sacrificado, ver qu\u00e9 problema ten\u00eda, solucionarlo y volver a poner el cl\u00faster en marcha.<\/p>\n

De forma autom\u00e1tica y gracias a las prioridades, una vez el cl\u00faster est\u00e1 en marcha se vuelve a establecer la configuraci\u00f3n inicial, con un servidor primario tal como hab\u00edamos definido y el otro como secundario, en este caso uno tendr\u00eda IP y servicios del firewall, mientras que el otro tendr\u00eda la IP y servicio de WoL.<\/p>\n

Hands On<\/h2>\n

Hacemos una configuraci\u00f3n b\u00e1sica del fichero \/etc\/corosync\/corosync.conf<\/code>, donde ponemos los nodos del cl\u00faster, la red, protocolo para la comunicaci\u00f3n, donde se hace el logging. El corosync ser\u00eda el daemon que forma parte del software de alta disponibilidad que se encarga de la comunicaci\u00f3n entre nodos.<\/p>\n

\r\nmiserver \/root# cat \/etc\/corosync\/corosync.conf\r\ntotem {\r\n version: 2\r\n crypto_cipher: none\r\n crypto_hash: none\r\n clear_node_high_bit: yes\r\n interface {\r\n ringnumber: 0\r\n bindnetaddr: Red IP interna\r\n mcastport: Puerto\r\n ttl: 1\r\n }\r\n transport: udpu --> Significa que usamos UDP para la comunicaci\u00f3n en lugar de multicast (al tener s\u00f3lo dos\r\nservidores ya nos va bien)\r\n}\r\nlogging { --> Configuramos los logs hacia el SYSLOG\r\n fileline: off\r\n to_syslog: yes\r\n debug: off\r\n timestamp: on\r\n logger_subsys {\r\n subsys: QUORUM\r\n debug: off\r\n }\r\n}\r\nnodelist { --> La lista de nodos del cl\u00faster y ponemos las IPs privadas\r\n node {\r\n ring0_addr: 192.168.10.1\r\n nodeid: 1\r\n }\r\n\r\n node {\r\n ring0_addr: 192.168.10.2\r\n nodeid: 2\r\n }\r\n}\r\nquorum { --> Al ser un cl\u00faster de dos nodos es necesario definir la opci\u00f3n two_node\r\n provider: corosync_votequorum\r\n two_node: 1\r\n no-quorum-policy: ignore\r\n stonith-action: poweroff --> si hay un problema apagamos el servidor que est\u00e1 dando el problema\r\n}\r\n<\/pre>\n
Una vez tenemos la misma configuraci\u00f3n en los dos servidores y hemos puesto en marcha el daemon de corosync, podemos usar la herramienta de l\u00ednea de comandos crm para configurar recursos, prioridades, fencing en uno de los nodos, ya que con el corosync la configuraci\u00f3n se aplicar\u00e1 a todos los nodos del cl\u00faster.<\/p>\n
Para que el cl\u00faster est\u00e9 funcionando correctamente hace falta que los nodos establezcan un cu\u00f3rum, si hacemos crm status veremos que nos dice \u201cpartition with quorum\u201d.<\/p>\n
\r\nmiserver:\/root # systemctl start corosync; systemctl start pacemaker\r\nmiserver:\/root # crm status\r\nStack: corosync\r\nCurrent DC: miserver (2) - partition with quorum\r\n2 Nodes configured\r\n0 Resources configured\r\n\r\nOnline: [ node1 node2 ]\r\n<\/pre>\n
Configuramos una IP flotante y un servicio: En este caso configurar\u00eda el que es el WoL pero para el firewall ser\u00eda lo mismo. Lo que pone lsb:nombre_servicio quiere decir que el servidor tiene definido un servicio que se puede hacer start\/stop que se llama nombre_servicio. Si no est\u00e1 este servicio, la configuraci\u00f3n del cl\u00faster da un error.<\/p>\n
\r\nmiserver \/root# crm configure\r\n\r\nprimitive ipWOL IPaddr2 params ip=10.10.10.254 cidr_netmask=24 op monitor interval=30s\r\nprimitive wol_relay lsb:wol_relay op monitor interval=15s\r\n\r\ngroup WOL ipWOL wol_relay\r\n\r\nlocation WOL1 WOL 100: NODE1\r\nlocation WOL2 WOL 50: NODE2\r\n\r\ncommit\r\n<\/pre>\n
STONITH: Se configura para NODE1 y tambi\u00e9n para NODE2<\/p>\n
\r\nmiserver \/root#crm configure primitive shootNODE1 stonith:external\/ipmi params hostname=\"node1fencing\"\r\nipaddr=\"xxxx\" userid=\"fence\" passwd=\"XXX\" interface=\"lanplus\" stonith-timeout=\"30s\" op monitor\r\ninterval=120s\r\nmiserver \/root# crm configure location shootNODE1LOC shootNODE1 -inf: NODE1\r\n<\/pre>\n
Hacemos lo mismo para NODE2<\/p>\n
Finalmente, con toda la configuraci\u00f3n hecha y habiendo resuelto problemas que nos hayamos encontrado, el crm status tendr\u00eda que dar algo as\u00ed:<\/p>\n
\r\nNODE1:\/root # crm status\r\nStack: corosync\r\nCurrent DC: NODE1 (2) - partition with quorum\r\n2 Nodes configured\r\n7 Resources configured\r\n\r\nOnline: [ NODE1 NODE2 ]\r\n\r\n shootNODE2 (stonith:extNODE2\/ipmi): Started NODE1\r\n Resource Group: WOL\r\n\r\n ipWOL (ocf::heartbeat:IPaddr2): Started NODE2\r\n wol_relay (lsb:wol_relay): Started NODE2\r\n Resource Group: FW\r\n gwip (ocf::heartbeat:IPaddr2): Started NODE1\r\n gw4ip (ocf::heartbeat:IPaddr2): Started NODE1\r\n firewall (lsb:firewall_cluster): Started NODE1\r\n<\/pre>\n
Conclusi\u00f3n<\/h3>\n
Antes de usar Pacemaker us\u00e1bamos un software que se llamaba Heartbeat (en realidad predecesor de Pacemaker).<\/p>\n
Era mucho m\u00e1s sencillo de instalar y configurar pero faltaban muchas cosas que han mejorado en Pacemaker, el tema de orden y prioridades por ejemplo.<\/p>\n
Tambi\u00e9n es mejor la posibilidad de configuraci\u00f3n con la herramienta crm que hace que se replique la configuraci\u00f3n en todos los nodos del cl\u00faster.<\/p>\n
En resumen, al principio usar Pacemaker parece una tarea m\u00e1s compleja, pero le vas viendo los beneficios y una vez te haces con la sintaxis es un software muy potente para gestionar la alta disponibilidad de servicios en Linux.<\/p>\n","protected":false},"excerpt":{"rendered":"
Es bastante normal tener alta disponibilidad para servicios que se consideran cr\u00edticos dentro de una organizaci\u00f3n. En este caso concreto, pongamos que queremos implementar la alta disponibilidad para los sistemas de control perimetral (firewalls) que tenemos en una red controlada por inLab. El hecho de que uno de estos sistemas de control fallase dejar\u00eda la […]<\/p>\n","protected":false},"author":594,"featured_media":2100,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"experteses":[],"class_list":["post-2107","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized-ca"],"acf":[],"_links":{"self":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts\/2107","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/users\/594"}],"replies":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/comments?post=2107"}],"version-history":[{"count":0,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts\/2107\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/media\/2100"}],"wp:attachment":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/media?parent=2107"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/categories?post=2107"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/tags?post=2107"},{"taxonomy":"experteses","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/experteses?post=2107"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}