{"id":92570,"date":"2020-08-28T19:42:21","date_gmt":"2020-08-28T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker"},"modified":"2020-08-28T19:42:21","modified_gmt":"2020-08-28T17:42:21","slug":"modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","title":{"rendered":"Modelado de cl\u00fasteres tolerantes a fallos basados en PostgreSQL y Pacemaker","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Introducci\u00f3n<\/h1>\n

<\/p>\n

Hace un tiempo, se me plante\u00f3 la tarea de desarrollar un cl\u00faster de alta disponibilidad para PostgreSQL<\/a><\/noindex>, que funcione en varios centros de datos interconectados por fibra \u00f3ptica dentro de una misma ciudad, y que sea capaz de soportar la falla (por ejemplo, un corte de energ\u00eda) de un centro de datos. Como software que garantiza la alta disponibilidad, eleg\u00ed Pacemaker<\/a><\/noindex>, porque es la soluci\u00f3n oficial de RedHat para crear cl\u00fasteres de alta disponibilidad. Es ventajoso porque RedHat lo respalda, y porque esta soluci\u00f3n es universal (modular). Con su ayuda, se podr\u00e1 asegurar la alta disponibilidad no solo de PostgreSQL, sino tambi\u00e9n de otros servicios, ya sea utilizando m\u00f3dulos est\u00e1ndar o creando m\u00f3dulos para necesidades espec\u00edficas.<\/p>\n

<\/p>\n

A esta soluci\u00f3n surgi\u00f3 la pregunta razonable: \u00bfqu\u00e9 tan tolerante a fallos ser\u00e1 el cl\u00faster de alta disponibilidad? Para investigar esto, desarroll\u00e9 un banco de pruebas que simula diversas fallas en los nodos del cl\u00faster, espera la recuperaci\u00f3n de la operatividad, recupera el nodo fallido y contin\u00faa las pruebas en un ciclo. Originalmente, este proyecto se llamaba hapgsql, pero con el tiempo, me aburr\u00ed del nombre, que solo conten\u00eda una vocal. Por lo tanto, comenc\u00e9 a llamar a las bases de datos de alta disponibilidad (y la IP flotante que las apunta) krogan<\/strong> (un personaje de un videojuego que tiene todos sus \u00f3rganos vitales duplicados), y los nodos, los cl\u00fasteres y el propio proyecto \u2014 tuchanka<\/strong> (el planeta donde viven los kroganes).<\/p>\n

<\/p>\n

Ahora la direcci\u00f3n ha permitido abrir el proyecto a la comunidad de c\u00f3digo abierto bajo la licencia MIT<\/a><\/noindex>. El README ser\u00e1 traducido al ingl\u00e9s en breve (porque se espera que los principales consumidores sean los desarrolladores de Pacemaker y PostgreSQL), y decid\u00ed presentar la antigua versi\u00f3n en ruso del README (parcialmente) en esta art\u00edculo.<\/p>\n

<\/p>\n

\"Modelado<\/p>\n

<\/a><\/noindex><\/p>\n

Los cl\u00fasteres se desplegar\u00e1n en m\u00e1quinas virtuales VirtualBox<\/a><\/noindex>. Se desplegar\u00e1n un total de 12 m\u00e1quinas virtuales (en total 36GiB), que formar\u00e1n 4 cl\u00fasteres de alta disponibilidad (diferentes variantes). Los primeros dos cl\u00fasteres constan de dos servidores PostgreSQL, que se encuentran en diferentes centros de datos, y un servidor general witness<\/em> c quorum device<\/strong> (ubicado en una m\u00e1quina virtual barata en el tercer centro de datos), que resuelve la incertidumbre 50%\/50%<\/strong>, otorgando su voto a una de las partes. El tercer cl\u00faster est\u00e1 en tres centros de datos: un maestro, dos esclavos, sin quorum device<\/strong>. El cuarto cl\u00faster consta de cuatro servidores PostgreSQL, dos por centro de datos: uno maestro y los otros r\u00e9plicas, y tambi\u00e9n utiliza witness<\/em> c quorum device<\/strong>. El cuarto soporta la falla de dos servidores o de un centro de datos. Esta soluci\u00f3n puede ser escalada a un mayor n\u00famero de r\u00e9plicas si es necesario.<\/p>\n

<\/p>\n

Servicio de tiempo preciso ntpd<\/a><\/noindex> tambi\u00e9n ha sido reconfigurado para la alta disponibilidad, pero utiliza el m\u00e9todo m\u00e1s ntpd<\/code> (orphan mode<\/em>). El servidor general witness<\/em> act\u00faa como el servidor NTP central, distribuyendo su tiempo a todos los cl\u00fasteres, sincronizando as\u00ed todos los servidores entre s\u00ed. Si witness<\/em> se desconecta o se encuentra aislado, entonces uno de los servidores del cl\u00faster comenzar\u00e1 a distribuir su propio tiempo (dentro del cl\u00faster). Un proxy de cach\u00e9 auxiliar HTTP proxy<\/strong> tambi\u00e9n se ha levantado en witness<\/em>, mediante el cual las dem\u00e1s m\u00e1quinas virtuales tienen acceso a los repositorios de Yum. En la realidad, servicios como el tiempo preciso y el proxy, seguramente estar\u00e1n alojados en servidores dedicados, pero en esta configuraci\u00f3n est\u00e1n ubicados en witness<\/em> solo para ahorrar en el n\u00famero de m\u00e1quinas virtuales y espacio.<\/p>\n

<\/p>\n

Versiones<\/h1>\n

<\/p>\n

v0. Funciona con CentOS 7 y PostgreSQL 11 en VirtualBox 6.1.<\/p>\n

<\/p>\n

Estructura de los cl\u00fasteres<\/h1>\n

<\/p>\n

Todos los cl\u00fasteres est\u00e1n destinados a ubicarse en m\u00faltiples centros de datos, unidos en una sola red plana y deben soportar la falla o aislamiento de red de un centro de datos. Por lo tanto, no es posible<\/strong> se utiliza para proteger contra split-brain<\/strong> la tecnolog\u00eda est\u00e1ndar de Pacemaker, que se llama STONITH<\/em> (Shoot The Other Node In The Head) o fencing<\/em>. Su esencia: si los nodos en el cl\u00faster comienzan a sospechar que algo est\u00e1 mal con alg\u00fan nodo, no responde o se comporta incorrectamente, lo desconectan forzosamente a trav\u00e9s de dispositivos \u201cexternos\u201d, como una tarjeta de control IPMI o un UPS. Pero esto solo funcionar\u00e1 en casos donde, tras la falla de un servidor, el IPMI o el UPS contin\u00faan funcionando. Aqu\u00ed se planea proteger contra una falla mucho m\u00e1s catastr\u00f3fica, cuando falla (por ejemplo, se corta la energ\u00eda) todo el centro de datos. Y en tal caso todos los dispositivos stonith<\/em>(IPMI, UPS, etc.) tampoco funcionar\u00e1n.<\/p>\n

<\/p>\n

En su lugar, el sistema se basa en la idea de quorum. Todos los nodos tienen voz, y solo pueden funcionar aquellos que pueden ver m\u00e1s de la mitad de todos los nodos. Esta cantidad \u201cmitad+1\u201d se llama qu\u00f3rum<\/strong>. Si no se alcanza quorum, el nodo decide que est\u00e1 en aislamiento de red y debe desconectar sus recursos, es decir, es una protecci\u00f3n contra split-brain<\/strong>Si el software que controla este comportamiento no funciona, debe activarse un watchdog, por ejemplo, basado en IPMI.<\/p>\n

<\/p>\n

Si el n\u00famero de nodos es par (cl\u00faster en dos centros de datos), puede surgir lo que se llama una indeterminaci\u00f3n. 50%\/50%<\/strong> (cincuenta-cincuenta<\/em>), cuando la aislamiento de red divide el cl\u00faster exactamente por la mitad. Por lo tanto, para un n\u00famero par de nodos se a\u00f1ade quorum device<\/strong> \u2014 un demonio sin requerimientos, que puede ejecutarse en la virtualizaci\u00f3n m\u00e1s barata de un tercer centro de datos. Este emite su voto a uno de los segmentos (que puede ver), resolviendo as\u00ed la indeterminaci\u00f3n 50%\/50%. El servidor en el que se ejecutar\u00e1 el dispositivo de quorum lo llam\u00e9 witness<\/em> (terminolog\u00eda de repmgr, me gust\u00f3).<\/p>\n

<\/p>\n

Los recursos pueden moverse de un lugar a otro, por ejemplo, de servidores defectuosos a servidores operativos, o por orden de los administradores de sistemas. Para que los clientes sepan d\u00f3nde est\u00e1n los recursos que necesitan (\u00bfa d\u00f3nde deben conectarse?), se utilizan IPs flotantes<\/em> (float IP<\/strong>). Estas son IPs que Pacemaker puede mover entre los nodos (todo est\u00e1 en una red plana). Cada una simboliza un recurso (servicio) y estar\u00e1 donde se necesita conectarse para acceder a este servicio (en nuestro caso, la base de datos).<\/p>\n

<\/p>\n

Tuchanka1 (esquema con compresi\u00f3n)<\/h2>\n

<\/p>\n

Estructura<\/h3>\n

<\/p>\n

\"Modelado<\/p>\n

<\/p>\n

La idea era que tuvi\u00e9ramos muchas bases de datos peque\u00f1as con baja carga, para las cuales no es rentable mantener un servidor esclavo dedicado en modo hot standby para transacciones solo de lectura (no hay necesidad de tal despilfarro de recursos).<\/p>\n

<\/p>\n

En cada centro de datos hay un servidor. Cada servidor tiene dos instancias de PostgreSQL (en la terminolog\u00eda de PostgreSQL se llaman cl\u00fasteres, pero para evitar confusiones los llamar\u00e9 instancias (por analog\u00eda con otras bases de datos), y reservar\u00e9 el t\u00e9rmino cl\u00faster para los cl\u00fasteres de Pacemaker). Una instancia opera en modo maestro, y solo ella presta servicios (solo en ella se dirige la IP flotante). La segunda instancia funciona como esclavo para el segundo centro de datos, y solo prestar\u00e1 servicios si su maestro falla. Dado que la mayor parte del tiempo solo una de las dos instancias (el maestro) prestar\u00e1 servicios (realizar\u00e1 consultas), todos los recursos del servidor se optimizan para el maestro (se asigna memoria para cach\u00e9 shared_buffers, etc.), pero asegurando que la segunda instancia tambi\u00e9n disponga de recursos (aunque sea para un funcionamiento no \u00f3ptimo a trav\u00e9s de la cach\u00e9 del sistema de archivos) en caso de que falle uno de los centros de datos. El esclavo no presta servicios (no ejecuta consultas de solo lectura) durante el funcionamiento normal del cl\u00faster, para evitar la competencia por recursos con el maestro en la misma m\u00e1quina.<\/p>\n

<\/p>\n

En el caso de dos nodos, la tolerancia a fallos solo es posible con replicaci\u00f3n as\u00edncrona, ya que con replicaci\u00f3n s\u00edncrona la falla del esclavo provocar\u00e1 la detenci\u00f3n del maestro.<\/p>\n

<\/p>\n

Fallo witness<\/h3>\n

<\/p>\n

\"Modelado<\/p>\n

<\/p>\n

Fallo witness (quorum device<\/em>) lo considerar\u00e9 solo para el cl\u00faster Tuchanka1, con todos los dem\u00e1s suceder\u00e1 lo mismo. Con la falla del witness, la estructura del cl\u00faster no cambiar\u00e1, todo seguir\u00e1 funcionando como lo hac\u00eda. Pero el qu\u00f3rum ser\u00e1 igual a 2 de 3, y por lo tanto cualquier siguiente falla ser\u00e1 fatal para el cl\u00faster. Tendremos que arreglarlo de inmediato.<\/p>\n

<\/p>\n

Fallo Tuchanka1<\/h3>\n

<\/p>\n

\"Modelado<\/p>\n

<\/p>\n

Fallo de uno de los centros de datos para Tuchanka1. En este caso witness<\/em> da su voto al segundo nodo en el segundo centro de datos. All\u00ed, el anterior esclavo se convierte en maestro, resultando que en un servidor operan ambos maestros y ambos poseen sus IP flotantes.<\/p>\n

<\/p>\n

Tuchanka2 (cl\u00e1sica)<\/h2>\n

<\/p>\n

Estructura<\/h3>\n

<\/p>\n

\"Modelado<\/p>\n

<\/p>\n

Esquema cl\u00e1sico de dos nodos. Uno opera como maestro, el otro como esclavo. Ambos pueden realizar consultas (el esclavo solo en modo de solo lectura), por lo que ambos tienen IP flotantes: krogan2 \u2014 para el maestro, krogan2s1 \u2014 para el esclavo. La tolerancia a fallos existir\u00e1 tanto en el maestro como en el esclavo.<\/p>\n

<\/p>\n

En el caso de dos nodos, la tolerancia a fallos solo es posible con replicaci\u00f3n as\u00edncrona, porque con replicaci\u00f3n s\u00edncrona la falla del esclavo provocar\u00e1 la detenci\u00f3n del maestro.<\/p>\n

<\/p>\n

Fallo Tuchanka2<\/h3>\n

<\/p>\n

\"Modelado<\/p>\n

<\/p>\n

Con la falla de uno de los centros de datos witness<\/em> vota por el segundo. En el \u00fanico centro de datos funcionando se levantar\u00e1 el maestro, y ambos IP flotantes: el maestro y el esclavo apuntar\u00e1n a \u00e9l. Por supuesto, la instancia debe estar configurada de tal manera que tenga suficientes recursos (l\u00edmites de conexi\u00f3n, etc.) para aceptar simult\u00e1neamente todas las conexiones y solicitudes tanto del IP flotante maestro como del esclavo. As\u00ed que en condiciones normales, debe haber un margen suficiente en los l\u00edmites.<\/p>\n

<\/p>\n

Tuchanka4 (muchos esclavos)<\/h2>\n

<\/p>\n

Estructura<\/h3>\n

<\/p>\n

\"Modelado<\/p>\n

<\/p>\n

Ya es otro extremo. Hay bases de datos a las que llegan muchas solicitudes de solo lectura (un caso t\u00edpico de un sitio web altamente demandado). Tuchanka4 es una situaci\u00f3n en la que puede haber tres o m\u00e1s esclavos para manejar tales solicitudes, pero a\u00fan no demasiados. Con un n\u00famero muy elevado de esclavos, se necesitar\u00e1 inventar un sistema de replicaci\u00f3n jer\u00e1rquico. En el caso m\u00ednimo (en la imagen), hay dos servidores en cada uno de los dos centros de datos, cada uno con una instancia de PostgreSQL.<\/p>\n

<\/p>\n

Otra caracter\u00edstica de este esquema es que aqu\u00ed ya se puede organizar una replicaci\u00f3n s\u00edncrona. Est\u00e1 configurada para replicar, siempre que sea posible, en otro centro de datos, y no en la r\u00e9plica en el mismo centro de datos donde est\u00e1 el maestro. Tanto el maestro como cada esclavo apuntan a un IP flotante. Idealmente, se deber\u00eda hacer balanceo de solicitudes entre los esclavos con alg\u00fan tipo de proxy sql<\/em>, por ejemplo, del lado del cliente. Diferentes tipos de clientes pueden requerir diferentes tipos proxy sql<\/em>, y solo los desarrolladores de los clientes saben qui\u00e9n necesita qu\u00e9. Esta funcionalidad puede ser implementada tanto por un demonio externo, como por una biblioteca del cliente (pool de conexiones), etc. Todo esto est\u00e1 m\u00e1s all\u00e1 del tema de un cl\u00faster de base de datos tolerante a fallos (la tolerancia a fallos proxy SQL<\/em> se podr\u00e1 implementar de manera independiente, junto con la tolerancia a fallos del cliente).<\/p>\n

<\/p>\n

Fallo de Tuchanka4<\/h3>\n

<\/p>\n

\"Modelado<\/p>\n

<\/p>\n

En caso de fallo de un centro de datos (es decir, de los dos servidores), el testigo vota por el segundo. Como resultado, en el segundo centro de datos funcionan dos servidores: en uno est\u00e1 el maestro, y apunta al IP flotante maestro (para recibir solicitudes de lectura y escritura); y en el segundo servidor funciona un esclavo con replicaci\u00f3n s\u00edncrona, y a \u00e9l apunta uno de los IP flotantes esclavos (para solicitudes de solo lectura).<\/p>\n

<\/p>\n

Lo primero que hay que se\u00f1alar es que no todos los IP flotantes esclavos ser\u00e1n operativos, sino solo uno. Y para su correcto funcionamiento ser\u00e1 necesario que proxy sql<\/em> redirige todas las solicitudes al \u00fanico IP flotante restante; y si no, proxy sql<\/em> se pueden enumerar todos los IP flotantes de esclavos separados por comas en la URL para la conexi\u00f3n. En tal caso, libpq<\/em> la conexi\u00f3n ser\u00e1 al primer IP funcional, as\u00ed est\u00e1 hecho en el sistema de pruebas autom\u00e1ticas. Es posible que en otras bibliotecas, como JDBC, no funcione de esta manera y sea necesario proxy sql<\/em>. Esto se debe a que los IP flotantes de los esclavos tienen prohibido levantarse simult\u00e1neamente en un mismo servidor, para que se distribuyan equitativamente entre los servidores esclavos si hay varios funcionando.<\/p>\n

<\/p>\n

Segundo: incluso en caso de falla del centro de datos, se mantendr\u00e1 la replicaci\u00f3n sincr\u00f3nica. E incluso si ocurre una falla secundaria, es decir, si uno de los dos servidores en el centro de datos restante falla, el cl\u00faster, aunque dejar\u00e1 de ofrecer servicios, a\u00fan conservar\u00e1 la informaci\u00f3n de todas las transacciones confirmadas, para las que ha dado confirmaci\u00f3n de commit (no habr\u00e1 p\u00e9rdida de informaci\u00f3n en caso de falla secundaria).<\/p>\n

<\/p>\n

Tuchanka3 (3 centros de datos)<\/h2>\n

<\/p>\n

Estructura<\/h3>\n

<\/p>\n

\"Modelado<\/p>\n

<\/p>\n

Este es un cl\u00faster para situaciones en las que hay tres centros de datos completamente operativos, en cada uno de los cuales hay un servidor de base de datos completamente funcional. En este caso, quorum device<\/em> no es necesario. En un centro de datos opera el maestro, en los otros dos \u2014 esclavos. La replicaci\u00f3n es sincr\u00f3nica, del tipo ANY (slave1, slave2), es decir, el cliente recibir\u00e1 la confirmaci\u00f3n de commit cuando cualquiera de los esclavos responda primero que ha aceptado el commit. Un solo IP flotante se\u00f1ala para el maestro y dos para los esclavos. A diferencia de Tuchanka4, los tres IP flotantes son tolerantes a fallos. Para equilibrar las consultas SQL de solo lectura se puede usar proxy sql<\/em> (con tolerancia a fallos separada), o asignar un IP flotante de esclavo a la mitad de los clientes, y el segundo a la otra mitad.<\/p>\n

<\/p>\n

Fallo de Tuchanka3<\/h3>\n

<\/p>\n

\"Modelado<\/p>\n

<\/p>\n

En caso de fallo de uno de los centros de datos, quedan dos. En uno est\u00e1 levantado el maestro y el IP flotante del maestro, en el segundo \u2014 un esclavo y ambos IP flotantes de esclavos (el instancia debe tener un doble suministro de recursos para aceptar todas las conexiones de ambos IP flotantes de esclavos). Entre el maestro y el esclavo hay replicaci\u00f3n sincr\u00f3nica. Adem\u00e1s, el cl\u00faster conservar\u00e1 la informaci\u00f3n sobre las transacciones confirmadas y verificadas (no habr\u00e1 p\u00e9rdida de informaci\u00f3n) en caso de destrucci\u00f3n de dos centros de datos (si no son destruidos al mismo tiempo).<\/p>\n

<\/p>\n

He decidido no incluir una descripci\u00f3n detallada de la estructura de archivos y la implementaci\u00f3n. Quien quiera experimentar, puede leer todo eso en el README. Solo presento una descripci\u00f3n de las pruebas autom\u00e1ticas.<\/em><\/p>\n

<\/p>\n

Sistema de pruebas autom\u00e1ticas<\/h1>\n

<\/p>\n

Se ha creado un sistema de pruebas autom\u00e1ticas para verificar la resistencia del cl\u00faster simulando diversas fallas. Se ejecuta mediante un script test\/failure<\/code>. El script puede aceptar como par\u00e1metros los n\u00fameros de los cl\u00fasteres que se desean probar. Por ejemplo, este comando:<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
probar\u00e1 solamente el segundo y el tercer cl\u00faster. Si no se especifican par\u00e1metros, se probar\u00e1n todos los cl\u00fasteres. Todos los cl\u00fasteres se prueban en paralelo, y el resultado se muestra en la consola de tmux. Tmux utiliza un servidor tmux dedicado, por lo que el script puede ejecutarse desde el tmux predeterminado, resultando en un tmux anidado. Recomiendo usar una terminal en una ventana grande y con una fuente peque\u00f1a. Antes de comenzar las pruebas, todas las m\u00e1quinas virtuales se restauran a un snapshot que coincide con el momento en que finaliz\u00f3 el script. configuraci\u00f3n<\/code>.<\/p>\n
<\/p>\n
\"Modelado<\/p>\n
<\/p>\n
La terminal se divide en columnas seg\u00fan el n\u00famero de cl\u00fasteres en prueba, que por defecto (en la captura de pantalla) son cuatro. Describir\u00e9 el contenido de las columnas usando Tuchanka2 como ejemplo. Los paneles de la captura de pantalla est\u00e1n numerados:<\/p>\n
<\/p>\n
    \n
  1. Aqu\u00ed se muestra la estad\u00edstica de las pruebas. Columnas:\n