{"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\/pt\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","title":{"rendered":"Modelagem de clusters tolerantes a falhas com PostgreSQL e Pacemaker","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Introdu\u00e7\u00e3o<\/h1>\n

<\/p>\n

H\u00e1 algum tempo, fui encarregado de desenvolver um cluster de alta disponibilidade para PostgreSQL<\/a><\/noindex>, operando em v\u00e1rios centros de dados interconectados por fibra \u00f3ptica dentro de uma \u00fanica cidade, e capaz de suportar a falha (por exemplo, perda de energia) de um centro de dados. Como software respons\u00e1vel pela alta disponibilidade, escolhi Pacemaker<\/a><\/noindex>, porque \u00e9 a solu\u00e7\u00e3o oficial da RedHat para a cria\u00e7\u00e3o de clusters de alta disponibilidade. \u00c9 favor\u00e1vel, pois a RedHat oferece suporte, e \u00e9 uma solu\u00e7\u00e3o universal (modular). Com isso, ser\u00e1 poss\u00edvel garantir a alta disponibilidade n\u00e3o apenas do PostgreSQL, mas tamb\u00e9m de outros servi\u00e7os, seja atrav\u00e9s de m\u00f3dulos padr\u00e3o ou criando-os para necessidades espec\u00edficas.<\/p>\n

<\/p>\n

A essa solu\u00e7\u00e3o surgiu uma pergunta pertinente: qu\u00e3o resiliente ser\u00e1 o cluster de alta disponibilidade? Para investigar isso, desenvolvi um ambiente de teste que simula v\u00e1rias falhas nos n\u00f3s do cluster, aguarda a recupera\u00e7\u00e3o do funcionamento, restaura o n\u00f3 que falhou e continua o teste em ciclo. Inicialmente, este projeto se chamava hapgsql, mas com o tempo fiquei entediado com o nome, que tinha apenas uma vogal. Portanto, comecei a nomear as bases de dados de alta disponibilidade (e o IP flutuante que as aponta) de krogan<\/strong> (um personagem de um jogo de computador que tem todos os \u00f3rg\u00e3os importantes duplicados), e os n\u00f3s, clusters e o pr\u00f3prio projeto de tuchanka<\/strong> (o planeta onde vivem os krogan).<\/p>\n

<\/p>\n

Atualmente, a ger\u00eancia autorizou a abrir o projeto para a comunidade open source sob a licen\u00e7a MIT<\/a><\/noindex>. O README ser\u00e1 em breve traduzido para o ingl\u00eas (pois espera-se que os principais usu\u00e1rios sejam desenvolvedores do Pacemaker e PostgreSQL), e decidi formatar a vers\u00e3o antiga em russo do README (parcialmente) como este artigo.<\/p>\n

<\/p>\n

\"Modelagem<\/p>\n

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

Os clusters s\u00e3o implantados em m\u00e1quinas virtuais VirtualBox<\/a><\/noindex>. No total, ser\u00e3o implantadas 12 m\u00e1quinas virtuais (totalizando 36GiB), que formam 4 clusters de alta disponibilidade (diferentes variantes). Os dois primeiros clusters s\u00e3o compostos por dois servidores PostgreSQL, que est\u00e3o localizados em diferentes centros de dados, e um servidor compartilhado witness<\/em> c quorum device<\/strong> (localizado em uma m\u00e1quina virtual barata em um terceiro centro de dados), que resolve a ambiguidade 50%\/50%<\/strong>, dando seu voto a um dos lados. O terceiro cluster abrange tr\u00eas centros de dados: um mestre, dois escravos, sem quorum device<\/strong>. O quarto cluster \u00e9 composto por quatro servidores PostgreSQL, dois em cada data center: um mestre e os outros como r\u00e9plicas, e tamb\u00e9m utiliza witness<\/em> c quorum device<\/strong>. O quarto suporta a falha de dois servidores ou de um data center. Esta solu\u00e7\u00e3o pode ser escalada para um maior n\u00famero de r\u00e9plicas, se necess\u00e1rio.<\/p>\n

<\/p>\n

Servi\u00e7o de Hora Precisa ntpd<\/a><\/noindex> tamb\u00e9m est\u00e1 configurado para resist\u00eancia a falhas, mas utiliza o m\u00e9todo de ntpd<\/code> (modo orphan<\/em>). O servidor geral witness<\/em> atua como o servidor NTP central, distribuindo sua hora para todos os clusters, sincronizando assim todos os servidores entre si. Se witness<\/em> falhar ou ficar isolado, um dos servidores do cluster come\u00e7ar\u00e1 a distribuir seu tempo (dentro do cluster). Um cache de apoio proxy HTTP<\/strong> tamb\u00e9m foi levantado em witness<\/em>, com isso as outras m\u00e1quinas virtuais t\u00eam acesso aos reposit\u00f3rios Yum. Na realidade, servi\u00e7os como hora precisa e proxy provavelmente ser\u00e3o hospedados em servidores dedicados, enquanto na configura\u00e7\u00e3o atual est\u00e3o alocados em witness<\/em> apenas para economizar virtual machines e espa\u00e7o.<\/p>\n

<\/p>\n

Vers\u00f5es<\/h1>\n

<\/p>\n

v0. Funciona com CentOS 7 e PostgreSQL 11 no VirtualBox 6.1.<\/p>\n

<\/p>\n

Estrutura dos Clusters<\/h1>\n

<\/p>\n

Todos os clusters foram projetados para serem localizados em v\u00e1rios data centers, unidos em uma rede plana e deve suportar a falha ou o isolamento de um data center. Portanto, \u00e9 imposs\u00edvel<\/strong> usar para prote\u00e7\u00e3o contra split-brain<\/strong> a tecnologia padr\u00e3o do Pacemaker, chamada de STONITH<\/em> (Shoot The Other Node In The Head) ou fencing<\/em>. A ess\u00eancia: se os n\u00f3s no cluster come\u00e7am a suspeitar que um dos n\u00f3s est\u00e1 apresentando problemas, n\u00e3o responde ou se comporta de maneira errada, eles o desligam for\u00e7osamente atrav\u00e9s de dispositivos 'externos', como um cart\u00e3o controlador IPMI ou UPS. Mas isso s\u00f3 funcionar\u00e1 nos casos em que, em uma \u00fanica falha de servidor, o IPMI ou UPS continuem operando. Aqui, a prote\u00e7\u00e3o est\u00e1 prevista para uma falha muito mais catastr\u00f3fica, quando todo o data center falha (por exemplo, perde a energia). E com essa falha, todos os dispositivos stonith (IPMI, UPS, etc.) tamb\u00e9m n\u00e3o funcionar\u00e3o.<\/em>Em vez disso, o sistema baseia-se na ideia de qu\u00f3rum. Todos os n\u00f3s t\u00eam voz, e s\u00f3 podem trabalhar aqueles que veem mais da metade de todos os n\u00f3s. Esta quantidade 'metade+1' \u00e9 chamada de<\/p>\n

<\/p>\n

qu\u00f3rum .<\/strong>. Se o qu\u00f3rum n\u00e3o for alcan\u00e7ado, o n\u00f3 decide que est\u00e1 em isolamento de rede e deve desligar seus recursos, ou seja, \u00e9 uma prote\u00e7\u00e3o contra split-brain<\/strong>. Se o software que gerencia esse comportamento n\u00e3o funcionar, um watchdog deve entrar em a\u00e7\u00e3o, por exemplo, baseado em IPMI.<\/p>\n

<\/p>\n

Se o n\u00famero de n\u00f3s for par (cluster em dois data centers), pode ocorrer o que se chama incerteza 50%\/50%<\/strong> (cinquenta\/cinquenta<\/em>), quando o isolamento de rede divide o cluster exatamente ao meio. Portanto, para um n\u00famero par de n\u00f3s, \u00e9 adicionado quorum device<\/strong> \u2014 um daemon que n\u00e3o exige muitos recursos, que pode ser executado na m\u00e1quina virtual mais barata de um terceiro data center. Ele d\u00e1 seu voto a um dos segmentos (que v\u00ea), assim resolvendo a incerteza 50%\/50%. O servidor onde ser\u00e1 executado o dispositivo de qu\u00f3rum eu chamei de witness<\/em> (terminologia do repmgr, que achei interessante).<\/p>\n

<\/p>\n

Os recursos podem ser movidos de um lugar para outro, por exemplo, de servidores defeituosos para servidores funcionando, ou por comando dos administradores. Para que os clientes saibam onde est\u00e3o os recursos que necessitam (para onde se conectar?), s\u00e3o utilizados IPs flutuantes<\/em> (float IP<\/strong>). Esses IPs, que o Pacemaker pode mover entre os n\u00f3s (tudo est\u00e1 em uma rede plana), simbolizam um recurso (servi\u00e7o) e estar\u00e3o onde \u00e9 necess\u00e1rio se conectar para ter acesso a esse servi\u00e7o (no nosso caso, ao BD).<\/p>\n

<\/p>\n

Tuchanka1 (esquema com compacta\u00e7\u00e3o)<\/h2>\n

<\/p>\n

Estrutura<\/h3>\n

<\/p>\n

\"Modelagem<\/p>\n

<\/p>\n

A ideia foi que temos muitos pequenos bancos de dados com baixa carga, pelos quais n\u00e3o compensa manter um servidor slave dedicado em modo de hot standby para transa\u00e7\u00f5es de leitura (n\u00e3o h\u00e1 necessidade de tal desperd\u00edcio de recursos).<\/p>\n

<\/p>\n

Em cada data center h\u00e1 um servidor. Em cada servidor, existem duas inst\u00e2ncias do PostgreSQL (na terminologia do PostgreSQL, elas s\u00e3o chamadas de clusters, mas para evitar confus\u00e3o, eu as chamarei de inst\u00e2ncias (por analogia com outros bancos de dados), e chamarei de clusters apenas os clusters do Pacemaker). Uma inst\u00e2ncia opera no modo mestre, e apenas ela presta servi\u00e7os (apenas ela recebe o IP flutuante). A segunda inst\u00e2ncia opera como escravo para o segundo data center e prestar\u00e1 servi\u00e7os apenas se seu mestre falhar. Uma vez que a maior parte do tempo a presta\u00e7\u00e3o de servi\u00e7os (execu\u00e7\u00e3o de consultas) ser\u00e1 realizada apenas por uma das duas inst\u00e2ncias (o mestre), todos os recursos do servidor s\u00e3o otimizados para o mestre (mem\u00f3ria \u00e9 alocada para o cache shared_buffers, etc.), mas de modo que haja recursos suficientes para a segunda inst\u00e2ncia (mesmo que para um funcionamento sub\u00f3timo atrav\u00e9s do cache do sistema de arquivos) em caso de falha de um dos data centers. O escravo n\u00e3o presta servi\u00e7os (n\u00e3o executa consultas read only) durante a opera\u00e7\u00e3o normal do cluster, para evitar competi\u00e7\u00e3o por recursos com o mestre na mesma m\u00e1quina.<\/p>\n

<\/p>\n

No caso de dois n\u00f3s, a alta disponibilidade s\u00f3 \u00e9 poss\u00edvel com replica\u00e7\u00e3o ass\u00edncrona, pois na replica\u00e7\u00e3o s\u00edncrona, a falha do escravo levar\u00e1 \u00e0 parada do mestre.<\/p>\n

<\/p>\n

Falha do witness<\/h3>\n

<\/p>\n

\"Modelagem<\/p>\n

<\/p>\n

Falha do witness (quorum device<\/em>) eu vou considerar apenas para o cluster Tuchanka1, a hist\u00f3ria ser\u00e1 a mesma para todos os outros. Em caso de falha do witness na estrutura do cluster, nada mudar\u00e1, tudo continuar\u00e1 a funcionar como antes. Mas o qu\u00f3rum se tornar\u00e1 igual a 2 em 3, e portanto qualquer falha subsequente ser\u00e1 fatal para o cluster. Afinal, ter\u00e1 que ser urgente consertado.<\/p>\n

<\/p>\n

Falha do Tuchanka1<\/h3>\n

<\/p>\n

\"Modelagem<\/p>\n

<\/p>\n

Falha de um dos data centers para o Tuchanka1. Nesse caso witness<\/em> ceder\u00e1 seu voto ao segundo n\u00f3 no segundo data center. L\u00e1, o antigo escravo se transforma em mestre, resultando em que ambos os mestres operam em um servidor e ambos recebem seus IPs flutuantes.<\/p>\n

<\/p>\n

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

<\/p>\n

Estrutura<\/h3>\n

<\/p>\n

\"Modelagem<\/p>\n

<\/p>\n

Esquema cl\u00e1ssico de dois n\u00f3s. Em um, opera o mestre; no outro, o escravo. Ambos podem executar consultas (escravo apenas read only), portanto ambos t\u00eam IPs flutuantes: krogan2 \u2014 para o mestre, krogan2s1 \u2014 para o escravo. A alta disponibilidade ser\u00e1 mantida tanto para o mestre quanto para o escravo.<\/p>\n

<\/p>\n

No caso de dois n\u00f3s, a alta disponibilidade s\u00f3 \u00e9 poss\u00edvel com replica\u00e7\u00e3o ass\u00edncrona, pois na replica\u00e7\u00e3o s\u00edncrona, a falha do escravo levar\u00e1 \u00e0 parada do mestre.<\/p>\n

<\/p>\n

Falha do Tuchanka2<\/h3>\n

<\/p>\n

\"Modelagem<\/p>\n

<\/p>\n

Na falha de um dos data centers witness<\/em> vota pelo segundo. No \u00fanico data center em funcionamento, um mestre ser\u00e1 levantado, e ambos os IPs flutuantes \u2014 o do mestre e o do escravo \u2014 apontar\u00e3o para ele. Naturalmente, a inst\u00e2ncia deve ser configurada de forma a ter recursos suficientes (limites de conex\u00e3o, etc.) para lidar simultaneamente com todas as conex\u00f5es e solicita\u00e7\u00f5es dos IPs flutuantes mestre e escravo. Ou seja, durante o funcionamento normal, deve haver uma margem suficiente nos limites.<\/p>\n

<\/p>\n

Tuchanka4 (muitos escravos)<\/h2>\n

<\/p>\n

Estrutura<\/h3>\n

<\/p>\n

\"Modelagem<\/p>\n

<\/p>\n

J\u00e1 \u00e9 outra extremidade. Existem bancos de dados que recebem muitas solicita\u00e7\u00f5es somente de leitura (um caso t\u00edpico de um site de alta carga). Tuchanka4 \u00e9 uma situa\u00e7\u00e3o onde pode haver tr\u00eas ou mais escravos para processar tais solicita\u00e7\u00f5es, mas ainda assim n\u00e3o muito. Com um n\u00famero muito grande de escravos, ser\u00e1 necess\u00e1rio inventar um sistema hier\u00e1rquico de replica\u00e7\u00e3o. No caso m\u00ednimo (na imagem), h\u00e1 dois servidores em cada um dos dois data centers, em cada um dos quais reside uma inst\u00e2ncia do PostgreSQL.<\/p>\n

<\/p>\n

Outra caracter\u00edstica desse esquema \u00e9 que aqui j\u00e1 \u00e9 poss\u00edvel organizar uma replica\u00e7\u00e3o s\u00edncrona. Ela \u00e9 configurada para replicar, sempre que poss\u00edvel, para outro data center, e n\u00e3o para a r\u00e9plica no mesmo data center que o mestre. Tanto o mestre quanto cada escravo apontam para um IP flutuante. Idealmente, entre os escravos, deve haver balanceamento de solicita\u00e7\u00f5es por algum proxy SQL<\/em>, por exemplo, do lado do cliente. Diferentes tipos de clientes podem exigir diferentes tipos de proxy SQL<\/em>, e somente os desenvolvedores dos clientes sabem quem precisa de qual. Essa funcionalidade pode ser implementada tanto como um dem\u00f4nio externo quanto como uma biblioteca de cliente (pool de conex\u00f5es), etc. Tudo isso est\u00e1 al\u00e9m do escopo do tema de um cluster de banco de dados tolerante a falhas (a toler\u00e2ncia a falhas proxy SQL<\/em> pode ser implementada de forma independente, juntamente com a toler\u00e2ncia a falhas do cliente).<\/p>\n

<\/p>\n

Falha Tuchanka4<\/h3>\n

<\/p>\n

\"Modelagem<\/p>\n

<\/p>\n

No caso de falha de um data center (ou seja, de dois servidores), o witness vota pelo segundo. Como resultado, funcionam dois servidores no segundo data center: em um est\u00e1 o mestre, e nele aponta o IP flutuante do mestre (para aceitar solicita\u00e7\u00f5es de leitura e grava\u00e7\u00e3o); e no segundo servidor, funciona um escravo com replica\u00e7\u00e3o s\u00edncrona, e nele aponta um dos IPs flutuantes dos escravos (para solicita\u00e7\u00f5es somente de leitura).<\/p>\n

<\/p>\n

A primeira coisa a ser observada: n\u00e3o ser\u00e3o todos os IPs flutuantes dos escravos que estar\u00e3o ativos, mas apenas um. E para o funcionamento correto com ele, ser\u00e1 necess\u00e1rio que proxy SQL<\/em> redirecionou todas as solicita\u00e7\u00f5es para o \u00fanico IP float restante; se n\u00e3o, proxy SQL<\/em> pode listar todos os IPs float dos escravos separados por v\u00edrgula na URL de conex\u00e3o. Nesse caso, libpq<\/em> a conex\u00e3o ser\u00e1 feita ao primeiro IP de trabalho, assim foi feito no sistema de testes autom\u00e1ticos. Pode ser que em outras bibliotecas, como JDBC, isso n\u00e3o funcione e seja necess\u00e1rio proxy SQL<\/em>. Isso foi feito porque os IPs float dos escravos n\u00e3o podem ser levantados simultaneamente em um servidor, para que sejam distribu\u00eddos uniformemente entre os servidores escravos, caso haja v\u00e1rios em funcionamento.<\/p>\n

<\/p>\n

Segunda: mesmo em caso de falha do data center, a replica\u00e7\u00e3o s\u00edncrona ser\u00e1 mantida. E mesmo que haja uma segunda falha, ou seja, um dos dois servidores no data center restante falhe, o cluster, embora deixe de prestar servi\u00e7os, ainda manter\u00e1 informa\u00e7\u00f5es sobre todas as transa\u00e7\u00f5es comprometidas, para as quais ele deu confirma\u00e7\u00e3o de commit (n\u00e3o haver\u00e1 perda de informa\u00e7\u00f5es em caso de falha secund\u00e1ria).<\/p>\n

<\/p>\n

Tuchanka3 (3 data centers)<\/h2>\n

<\/p>\n

Estrutura<\/h3>\n

<\/p>\n

\"Modelagem<\/p>\n

<\/p>\n

Este \u00e9 um cluster para situa\u00e7\u00f5es em que existem tr\u00eas data centers plenamente operacionais, em cada um dos quais h\u00e1 um servidor de banco de dados totalmente funcional. Nesse caso, quorum device<\/em> n\u00e3o \u00e9 necess\u00e1rio. Em um data center, o mestre opera, enquanto nos outros dois, os escravos. A replica\u00e7\u00e3o \u00e9 s\u00edncrona, do tipo ANY (slave1, slave2), ou seja, o cliente receber\u00e1 confirma\u00e7\u00e3o de commit quando qualquer um dos escravos responder primeiro que aceitou o commit. Um IP float \u00e9 designado para o mestre e dois para os escravos. Ao contr\u00e1rio do Tuchanka4, todos os tr\u00eas IPs float s\u00e3o tolerantes a falhas. Para balancear consultas SQL somente leitura, voc\u00ea pode usar proxy SQL<\/em> (com toler\u00e2ncia a falhas separada), ou designar um IP float escravo para metade dos clientes e o outro para a outra metade.<\/p>\n

<\/p>\n

Falha do Tuchanka3<\/h3>\n

<\/p>\n

\"Modelagem<\/p>\n

<\/p>\n

Em caso de falha de um dos data centers, permanecem dois. Em um, o mestre e o IP float do mestre est\u00e3o ativos; no segundo, o escravo e ambos os IPs float dos escravos (a inst\u00e2ncia deve ter um suprimento de recursos duplicado para aceitar todas as conex\u00f5es de ambos os IPs float dos escravos). Entre o mestre e o escravo h\u00e1 replica\u00e7\u00e3o s\u00edncrona. O cluster tamb\u00e9m manter\u00e1 informa\u00e7\u00f5es sobre transa\u00e7\u00f5es comprometidas e confirmadas (n\u00e3o haver\u00e1 perda de informa\u00e7\u00f5es) em caso de destrui\u00e7\u00e3o de dois data centers (se forem destru\u00eddos n\u00e3o simultaneamente).<\/p>\n

<\/p>\n

Decidi n\u00e3o incluir uma descri\u00e7\u00e3o detalhada da estrutura de arquivos e implanta\u00e7\u00e3o. Quem quiser experimentar, pode ler tudo isso no README. Apresento apenas a descri\u00e7\u00e3o do teste autom\u00e1tico.<\/em><\/p>\n

<\/p>\n

Sistema de teste autom\u00e1tico<\/h1>\n

<\/p>\n

Para verificar a resist\u00eancia a falhas dos clusters simulando v\u00e1rias falhas, foi criado um sistema de teste autom\u00e1tico. \u00c9 iniciado por um script test\/failure<\/code>. O script pode aceitar como par\u00e2metros os n\u00fameros dos clusters que deseja testar. Por exemplo, este comando:<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
testar\u00e1 apenas o segundo e o terceiro cluster. Se os par\u00e2metros n\u00e3o forem especificados, todos os clusters ser\u00e3o testados. Todos os clusters s\u00e3o testados em paralelo, e o resultado \u00e9 exibido no painel tmux. O tmux utiliza um servidor tmux dedicado, portanto o script pode ser executado a partir do tmux padr\u00e3o, resultando em tmux aninhado. Recomendo usar um terminal com uma janela grande e fonte pequena. Antes de iniciar o teste, todas as m\u00e1quinas virtuais s\u00e3o revertidas para um snapshot no momento do t\u00e9rmino do script. setup<\/code>.<\/p>\n
<\/p>\n
\"Modelagem<\/p>\n
<\/p>\n
O terminal \u00e9 dividido em colunas conforme o n\u00famero de clusters testados, por padr\u00e3o (na captura de tela) s\u00e3o quatro. O conte\u00fado das colunas ser\u00e1 detalhado usando Tuchanka2 como exemplo. Os pain\u00e9is na captura de tela est\u00e3o numerados:<\/p>\n
<\/p>\n
    \n
  1. Aqui \u00e9 exibida a estat\u00edstica dos testes. Colunas:\n