Introdución

Hai algún tempo encomendáronme a tarefa de desenvolver un clúster de conmutación por fallo para PostgreSQL, que operan en varios centros de datos conectados por fibra dentro da mesma cidade e son capaces de soportar a falla (por exemplo, un apagón) dun centro de datos. Como software responsable da tolerancia a fallos, escollín marcapasosporque esta é a solución oficial de RedHat para crear clústeres de conmutación por fallo. É bo porque RedHat ofrece soporte para iso e porque esta solución é universal (modular). Coa súa axuda, será posible garantir a tolerancia a fallos non só de PostgreSQL, senón tamén doutros servizos, ben utilizando módulos estándar ou creándoos para necesidades específicas.

Esta decisión suscitaba unha pregunta razoable: que tan tolerante será un clúster de conmutación por fallo? Para investigar isto, desenvolvín un banco de probas que simula varios fallos nos nodos do clúster, espera a que se restaure o servizo, recupera o nodo fallido e continúa probando nun bucle. Este proxecto chamábase orixinalmente hapgsql, pero co paso do tempo aburriime do nome, que só tiña unha vogal. Polo tanto, comecei a chamar bases de datos tolerantes a fallos (e a IP flotante apuntando a elas) krogan (un personaxe dun xogo de ordenador, no que se duplican todos os órganos importantes), e os nodos, clústeres e o propio proxecto son tuchanka (o planeta onde viven os krogans).

Agora a dirección permitiu abrir un proxecto para a comunidade de código aberto baixo a licenza MIT. O README será traducido en breve ao inglés (porque se espera que os desenvolvedores de Pacemaker e PostgreSQL sexan os principais consumidores), e decidín publicar a versión antiga rusa do README (parcialmente) na forma deste artigo.

Os clústeres están implantados en máquinas virtuais VirtualBox. Despregaranse un total de 12 máquinas virtuais (36GiB en total), que forman 4 clústeres tolerantes a fallos (diferentes opcións). Os dous primeiros clústeres consisten en dous servidores PostgreSQL, que están situados en diferentes centros de datos, e un servidor común testemuña c dispositivo de quórum (aloxado nunha máquina virtual barata nun terceiro centro de datos) que resolve a incerteza 50% / 50%emitindo o seu voto. O terceiro clúster en tres centros de datos: un mestre, dous escravos, non dispositivo de quórum. O cuarto clúster consta de catro servidores PostgreSQL, dous por centro de datos: un mestre, o resto son réplicas e tamén usa testemuña c dispositivo de quórum. O cuarto sobrevive á falla de dous servidores ou dun centro de datos. Esta solución pódese ampliar a máis réplicas se é necesario.

Servizo de Tempo ntpd tamén reconfigurado para tolerancia a fallos, pero usa o método de ntpd (modo orfo). Servidor Compartido testemuña actúa como un servidor NTP central, distribuíndo o seu tempo a todos os clústeres, sincronizando así todos os servidores entre si. Se testemuña falla ou resulta estar illado, entón un dos servidores do clúster (dentro do clúster) comezará a distribuír o seu tempo. Caché auxiliar Proxy HTTP tamén elevado a testemuña, coa súa axuda, outras máquinas virtuais teñen acceso aos repositorios Yum. En realidade, os servizos como o tempo preciso e o proxy probablemente estean aloxados en servidores dedicados e na cabina no que están aloxados. testemuña só para gardar o número de máquinas virtuais e espazo.

Versións

v0. Funciona con CentOS 7 e PostgreSQL 11 en VirtualBox 6.1.

Estrutura do cluster

Todos os clústeres están deseñados para estar situados en varios centros de datos, combinados nunha rede plana e deben soportar fallos ou illamento da rede dun único centro de datos. Por iso é imposible usar para protección contra cerebro dividido chamada tecnoloxía de marcapasos estándar STONITH (Dispara ao outro nodo na cabeza) ou esgrima. A súa esencia: se os nodos do clúster comezan a sospeitar que algo está mal nalgún nodo, non responde ou se está comportando incorrectamente, entón apágano forzosamente a través de dispositivos "externos", por exemplo, unha tarxeta de control IPMI ou UPS. . Pero isto só funcionará nos casos nos que, en caso de producirse un único fallo, o servidor IPMI ou UPS continúe funcionando. Aquí planeamos protexernos contra un fallo moito máis catastrófico, cando falla todo o centro de datos (por exemplo, perde enerxía). E con tal negativa, todo pedreira-dispositivos (IPMI, UPS, etc.) tampouco funcionarán.

Pola contra, o sistema baséase na idea de quórum. Todos os nodos teñen voz e só poden funcionar aqueles que ven máis da metade de todos os nodos. Esta cantidade de "metade + 1" chámase quórum. Se non se alcanza o quórum, entón o nodo decide que está illado de rede e debe desactivar os seus recursos, é dicir. é así protección de cerebro dividido. Se o software responsable deste comportamento non funciona, entón debería funcionar un vixilante, por exemplo, baseado en IPMI.

Se o número de nodos é par (un clúster en dous centros de datos), entón pode xurdir a chamada incerteza 50% / 50% (cincuenta e cincuenta) cando o illamento da rede divide o clúster exactamente á metade. Polo tanto, para un número par de nós, engadimos dispositivo de quórum é un daemon pouco esixente que se pode lanzar na máquina virtual máis barata nun terceiro centro de datos. Dálle o seu voto a un dos segmentos (que ve), e así resolve a incerteza 50%/50%. Chamei o servidor no que se iniciará o dispositivo de quórum testemuña (terminoloxía de repmgr, gustoume).

Os recursos pódense mover dun lugar a outro, por exemplo, de servidores defectuosos a outros saudables, ou por orde dos administradores do sistema. Para que os clientes saiban onde se atopan os recursos que necesitan (onde conectarse?), IP flotante (IP flotante). Estas son as IP que Pacemaker pode mover polos nodos (todo está nunha rede plana). Cada un deles simboliza un recurso (servizo) e estará situado onde teña que conectarse para acceder a este servizo (no noso caso, a base de datos).

Tuchanka1 (esquema comprimido)

Estrutura

A idea era que dispoñemos de moitas pequenas bases de datos con pouca carga, para as que non resulta rendible manter un servidor escravo dedicado en modo de espera en quente para transaccións de só lectura (non hai necesidade de tal desperdicio de recursos).

Cada centro de datos ten un servidor. Cada servidor ten dúas instancias PostgreSQL (en terminoloxía PostgreSQL chámanse clusters, pero para evitar confusións chamarei instancias (por analoxía con outras bases de datos), e só chamarei clusters de Pacemaker). Unha instancia funciona en modo mestre e só proporciona servizos (só a IP flotante conduce a ela). A segunda instancia funciona como escrava para o segundo centro de datos e só ofrecerá servizos se o seu mestre falla. Dado que a maioría das veces só unha instancia de cada dúas (o mestre) proporcionará servizos (realizar solicitudes), todos os recursos do servidor están optimizados para o mestre (asignarase memoria para a caché de shared_buffers, etc.), pero para que a segunda instancia tamén ten recursos suficientes (aínda que para un funcionamento subóptimo a través da caché do sistema de ficheiros) en caso de falla dun dos centros de datos. O escravo non ofrece servizos (non realiza solicitudes de só lectura) durante o funcionamento normal do clúster, polo que non hai guerra de recursos co mestre na mesma máquina.

No caso de dous nodos, a tolerancia a fallos só é posible coa replicación asíncrona, xa que coa replicación síncrona, o fallo do escravo levará á parada do mestre.

Falta de testemuña

falta de testemuño (dispositivo de quórum) Considerarei só para o clúster Tuchanka1, a mesma historia será con todas as demais. Se a testemuña falla, nada cambiará na estrutura do clúster, todo continuará funcionando do mesmo xeito que funcionaba. Pero o quórum converterase en 2 sobre 3 e, polo tanto, calquera seguinte fallo será fatal para o clúster. Aínda haberá que arranxarlo con urxencia.

Rexeitamento Tuchanka1

Fallo dun dos centros de datos para Tuchanka1. Neste caso testemuña emite o seu voto ao segundo nodo do segundo centro de datos. Alí, o antigo escravo convértese nun mestre, como resultado, ambos os mestres traballan no mesmo servidor e os seus dous IPs flotantes apuntan a eles.

Tuchanka2 (clásico)

Estrutura

Esquema clásico de dous nodos. O mestre traballa nun, o escravo no segundo. Ambos poden executar solicitudes (o escravo só é de lectura), polo que ambos se sinalan mediante unha IP flotante: krogan2 é o mestre, krogan2s1 é o escravo. Tanto o mestre como o escravo terán tolerancia a fallos.

No caso de dous nodos, a tolerancia a fallos só é posible coa replicación asíncrona, xa que coa replicación síncrona, o fallo do escravo levará á parada do mestre.

Rexeitamento Tuchanka2

Se un dos centros de datos falla testemuña votos para o segundo. No único centro de datos que funciona, levantarase o mestre e as dúas IP flotantes apuntarán a el: o mestre e o escravo. Por suposto, a instancia debe estar configurada de forma que dispoña de recursos suficientes (límites de conexión, etc.) para aceptar simultaneamente todas as conexións e solicitudes do IP flotante mestre e escravo. É dicir, durante o funcionamento normal debería ter unha oferta suficiente de límites.

Tuchanka4 (moitos escravos)

Estrutura

Xa é outro extremo. Hai bases de datos que teñen moitas solicitudes de só lectura (un caso típico dun sitio moi cargado). Tuchanka4 é unha situación na que pode haber tres ou máis escravos para xestionar tales solicitudes, pero aínda non demasiados. Cun número moi grande de escravos, será necesario inventar un sistema de replicación xerárquica. No caso mínimo (na imaxe), cada un dos dous centros de datos ten dous servidores, cada un dos cales ten unha instancia de PostgreSQL.

Outra característica deste esquema é que xa é posible organizar aquí unha replicación síncrona. Está configurado para replicarse, se é posible, noutro centro de datos, e non nunha réplica no mesmo centro de datos que o mestre. O mestre e cada escravo indícanse mediante unha IP flotante. Para ben, entre os escravos haberá que facer algún tipo de balance de peticións proxy sql, por exemplo, no lado do cliente. Diferentes tipos de clientes poden requirir diferentes tipos proxy sql, e só os desenvolvedores de clientes saben quen precisa cal. Esta funcionalidade pode ser implementada por un daemon externo ou por unha biblioteca cliente (grupo de conexións), etc. Todo isto está fóra do alcance do clúster de conmutación por fallo da base de datos (failover proxy SQL pode implementarse de forma independente, xunto coa conmutación por fallo do cliente).

Rexeitamento Tuchanka4

Se un centro de datos (é dicir, dous servidores) falla, as testemuñas votan polo segundo. Como resultado, hai dous servidores en execución no segundo centro de datos: un está a executar un mestre e a IP flotante mestra apunta a el (para recibir solicitudes de lectura-escritura); e no segundo servidor hai un escravo en execución con replicación síncrona, e un dos IPs flotantes escravos apunta a el (para solicitudes de só lectura).

O primeiro que hai que ter en conta: non todas as IP flotantes de escravos funcionarán, senón só unha. E para traballar correctamente con el, será necesario que proxy sql redirixiu todas as solicitudes á única IP flotante restante; e se proxy sql non, entón podes enumerar todos os escravos IP flotantes separados por comas no URL de conexión. Neste caso, con libpq a conexión será coa primeira IP en funcionamento, como se fai no sistema de probas automáticas. Quizais noutras bibliotecas, por exemplo, JDBC, isto non funcione e sexa necesario proxy sql. Isto faise porque está prohibido que a IP flotante para escravos se eleve simultaneamente nun servidor, de xeito que se distribúan uniformemente entre os servidores escravos se hai varios deles.

Segundo: mesmo no caso dun fallo do centro de datos, manterase a replicación síncrona. E aínda que se produza un fallo secundario, é dicir, un dos dous servidores falla no centro de datos restante, o clúster, aínda que deixa de ofrecer servizos, seguirá conservando información sobre todas as transaccións comprometidas para as que confirmou a confirmación (haberá non haxa información de perda sobre fallos secundarios).

Tuchanka3 (3 centros de datos)

Estrutura

Este é un clúster para unha situación na que hai tres centros de datos en pleno funcionamento, cada un dos cales ten un servidor de bases de datos totalmente funcional. Neste caso dispositivo de quórum non é necesario. Un centro de datos está atendido por un mestre, os outros dous son escravos. A replicación é sincrónica, escribe ANY (slave1, slave2), é dicir, o cliente recibirá unha confirmación de commit cando algún dos escravos sexa o primeiro en responder que aceptou a commit. Os recursos indícanse mediante unha IP flotante para o mestre e dúas para os escravos. A diferenza de Tuchanka4, as tres IP flotantes son tolerantes a fallos. Para equilibrar as consultas SQL de só lectura que pode usar proxy sql (con tolerancia a fallos separada) ou asignar un flotador IP escravo á metade dos clientes e o segundo á outra metade.

Rexeitamento Tuchanka3

Se un dos centros de datos falla, quedan dous. Nunha, a IP mestra e flotante do mestre son levantadas, na segunda, a IP flotante escrava e ambas as IP flotantes escravas (debe haber unha dobre reserva de recursos na instancia para aceptar todas as conexións de ambas as IP flotantes escravas). Replicación sincrónica entre mestres e escravos. Ademais, o clúster gardará información sobre transaccións comprometidas e confirmadas (non haberá perda de información) en caso de destrución de dous centros de datos (se non se destrúen ao mesmo tempo).

Decidín non incluír unha descrición detallada da estrutura e despregamento do ficheiro. Quen queira xogar pode lelo todo no README. Só ofrezo unha descrición das probas automatizadas.

Sistema automático de probas

Para comprobar a tolerancia a fallos dos clusters con imitación de varios fallos, realizouse un sistema automático de probas. Lanzada por un guión test/failure. O script pode tomar como parámetros o número de clusters que quere probar. Por exemplo, este comando:

test/failure 2 3

só probará o segundo e o terceiro cluster. Se non se especifican parámetros, probaranse todos os clústeres. Todos os clústeres son probados en paralelo e o resultado móstrase no panel tmux. Tmux usa un servidor tmux dedicado, polo que o script pode executarse desde o tmux predeterminado, o que resulta nun tmux anidado. Recomendo usar o terminal nunha fiestra grande e cun tipo de letra pequeno. Antes de comezar a proba, todas as máquinas virtuais volven a unha instantánea no momento en que remata o script setup.

O terminal está dividido en columnas segundo o número de clusters probados, por defecto (na captura de pantalla) hai catro deles. Describirei o contido das columnas usando Tuchanka2 como exemplo. Os paneis da captura de pantalla están numerados:

1. Aquí móstranse as estatísticas das probas. Columnas:
   • falla — o nome da proba (función no script) que emula o fallo.
   • reacción — o tempo medio aritmético en segundos durante o cal o clúster restableceu o seu rendemento. Mídese desde o inicio do script que emula o fallo, e ata o momento en que o clúster restablece a súa saúde e é capaz de seguir prestando servizos. Se o tempo é moi curto, por exemplo, seis segundos (isto ocorre en clusters con varios escravos (Tuchanka3 e Tuchanka4)), isto significa que o mal funcionamento acabou nun escravo asíncrono e non afectou de ningún xeito ao rendemento, non houbo conmutadores de estado de clúster.
   • desviación — mostra a distribución (precisión) do valor reacción polo método de desviación estándar.
   • contar - Cantas veces se realizou esta proba.
2. Un pequeno rexistro permítelle avaliar o que o clúster está facendo actualmente. Móstrase o número de iteración (proba), a marca de tempo e o nome da operación. Unha execución demasiado longa (> 5 minutos) indica algún tipo de problema.
3. corazón (corazón) é a hora actual. Para a avaliación do rendemento visual mestre a hora actual escríbese constantemente na súa táboa usando a IP flotante do mestre. Se ten éxito, o resultado móstrase neste panel.
4. bater (pulso) - "hora actual", que foi previamente gravada polo guión corazón dominar, agora ler de escravo a través da súa IP flotante. Permite avaliar visualmente o rendemento dun escravo e a súa replicación. Non hai escravos con IP flotante en Tuchanka1 (non hai escravos que proporcionen servizos), pero hai dúas instancias (DB), polo que non se mostrará aquí baterE corazón segunda instancia.
5. Monitorización do estado do clúster mediante a utilidade pcs mon. Mostra a estrutura, distribución dos recursos por nodos e outra información útil.
6. Mostra o seguimento do sistema de cada máquina virtual de clúster. Pode haber máis paneis deste tipo: cantas máquinas virtuais ten o clúster. Dúas gráficas Carga da CPU (as máquinas virtuais teñen dous procesadores), nome da máquina virtual, Carga do sistema (denominado Load Average porque ten unha media de 5, 10 e 15 minutos), procesar datos e asignación de memoria.
7. Trazar o script que realiza as probas. No caso de producirse un mal funcionamento -unha interrupción repentina do traballo ou un ciclo de espera interminable- aquí podes ver o motivo deste comportamento.

A proba realízase en dúas etapas. En primeiro lugar, o script pasa por todo tipo de probas, escollendo aleatoriamente unha máquina virtual á que se aplica esta proba. A continuación, realízase un ciclo de probas interminable, as máquinas virtuais e un mal funcionamento son seleccionadas ao azar cada vez. A terminación súbita do script de proba (panel inferior) ou un ciclo de espera interminable por algo (> 5 minutos de tempo para completar unha operación, isto pódese ver na traza) indica que algunhas das probas deste clúster fallaron.

Cada proba consta das seguintes operacións:

1. Iniciando unha función que emula un fallo.
2. Listo? - á espera da restauración da saúde do clúster (cando se presten todos os servizos).
3. Móstrase o tempo de espera da recuperación do clúster (reacción).
4. Fixar - o clúster está "reparado". Despois diso, debería volver a un estado totalmente operativo e listo para o seguinte mal funcionamento.

Aquí tes unha lista de probas cunha descrición do que fan:

• ForkBomb: Crea "Foto de memoria" usando unha bomba de garfo.
• Fóra do espazo: o disco duro está cheo. Pero a proba é bastante simbólica, coa carga insignificante que se crea durante a proba, cando o disco duro se desborda, PostgreSQL normalmente non falla.
• Postgres-KILL: mata PostgreSQL co comando killall -KILL postgres.
• Postgres-STOP: bloquea o comando PostgreSQL killall -STOP postgres.
• Apagado: "desenergiza" a máquina virtual co comando VBoxManage controlvm "виртуалка" poweroff.
• Restablecer: sobrecarga a máquina virtual co comando VBoxManage controlvm "виртуалка" reset.
• PARADA SBD: suspende o demo SBD co comando killall -STOP sbd.
• Apagado: envía un comando á máquina virtual mediante SSH systemctl poweroff, o sistema apágase con gracia.
• Desligar: illamento da rede, comando VBoxManage controlvm "виртуалка" setlinkstate1 off.

Finaliza a proba co comando tmux estándar "kill-window" Ctrl-b e, ou mediante o comando "detach-client" Ctrl-b d: neste punto remata a proba, tmux pecha, as máquinas virtuais están desactivadas.

Problemas detectados durante a proba

• Neste momento watchdog demo sbd xestiona deter os daemons observados, pero non conxelalos. E, como resultado, os fallos non funcionan correctamente, polo que só se conxela Corosync и marcapasos, pero non colgado sbd... Para comprobar Corosync xa ten PR #83 (en GitHub en sbd), aceptado para o fío mestre. Prometeron (en PR # 83) que habería algo parecido para Pacemaker, espero que antes Sombreiro Vermello 8 vai facer. Pero tales "mal funcionamento" son especulativos e pódense simular facilmente artificialmente usando, por exemplo, killall -STOP corosyncpero nunca atoparse na vida real.

• У marcapasos na versión para CentOS 7 configurado incorrectamente sync_timeout у dispositivo de quórum, como resultado se un nodo fallaba, o segundo reiniciaba con certa probabilidade, á que debía trasladarse o mestre. Curado por aumento sync_timeout у dispositivo de quórum durante a implantación (en script setup/setup1). Esta modificación non foi aceptada polos desenvolvedores marcapasos, en cambio prometeron reelaborar a infraestrutura de tal forma (nun futuro indefinido) que este tempo de espera se calcule automaticamente.

• Se a configuración da base de datos o especifica LC_MESSAGES (mensaxes de texto) Pódese usar Unicode, p. ru_RU.UTF-8, despois ao inicio postgres nun ambiente onde a configuración rexional non é UTF-8, digamos nun ambiente baleiro (aquí marcapasos+pgsqlms(paf) comeza postgres), entón o rexistro conterá signos de interrogación en lugar de letras UTF-8. Os desenvolvedores de PostgreSQL non se puxeron de acordo sobre que facer neste caso. Custa, hai que instalar LC_MESSAGES=en_US.UTF-8 ao configurar (crear) unha instancia de base de datos.

• Se wal_receiver_timeout está definido (por defecto é de 60 segundos), entón ao probar PostgreSQL-STOP no mestre nos clústeres tuchanka3 e tuchanka4 A replicación non se reconecta a un novo mestre. A replicación é sincrónica, polo que non só se detén o escravo, senón tamén o novo mestre. Obtén configurando wal_receiver_timeout=0 ao configurar PostgreSQL.

• De cando en vez observei conxelacións de replicación en PostgreSQL na proba ForkBomb (desbordamento de memoria). Despois de ForkBomb, ás veces os escravos poden non volver conectarse co novo mestre. Vin isto só nos clusters tuchanka3 e tuchanka4, onde debido ao feito de que a replicación é sincrónica, o mestre colgou. O problema desapareceu por si só, despois dun longo tempo (unhas dúas horas). Fai falla máis investigación para solucionar isto. Os síntomas son similares ao erro anterior, que é causado por unha causa diferente, pero coas mesmas consecuencias.

Foto tomada de Krogan Deviant Art co permiso do autor:

Fonte: www.habr.com