Em nosso blog anterior, discutimos o ClusterControl CMON HA para alta disponibilidade de banco de dados distribuído escrito por Krzysztof Ksiazek em duas postagens separadas. Neste blog, abordaremos a distribuição de nós no local e em uma nuvem pública (usando o Google Cloud Platform (GCP)).
A razão pela qual escrevemos este blog é porque recebemos perguntas sobre como implementar uma instância de alta disponibilidade do ClusterControl com nó(s) CMON em execução no local e outro(s) nó(s) CMON em execução em um data center diferente (como uma nuvem pública). Em nosso blog anterior ClusterControl CMON HA for Distributed Database High Availability, estávamos usando os nós do Galera Cluster, mas desta vez usaremos a Replicação MySQL usando o Percona Server 5.7. Uma configuração ideal para isso é sempre encapsular a comunicação de nós de seu local e seus nós que residem em uma nuvem pública via VPN ou um canal seguro.
ClusterControl CMON HA está nos estágios iniciais para os quais acreditamos que ainda não está maduro o suficiente. No entanto, nosso CMON HA é capaz de fornecer a você a sensação de funcionalidade para implantar um ClusterControl para torná-lo altamente disponível. Vamos continuar sobre como você pode implantar e configurar a distribuição dos nós no local por meio da nuvem pública.
O que é um CMON?
Antes de ir para o tópico principal, vamos apresentar a você o que é CMON. CMON significa ClusterControl Controller, que é o “cérebro primário” do ClusterControl. Um serviço de backend realizando automação, gerenciamento, monitoramento de tarefas de agendamento e também a disponibilidade de HA. Os dados coletados são armazenados no banco de dados CMON, para o qual estamos usando bancos de dados compatíveis com MySQL como armazenamento de dados.
A configuração arquitetônica
Alguns de vocês podem não conhecer os recursos do ClusterControl que ele pode executar e ser configurado para alta disponibilidade. Se você tiver vários nós ClusterControl (ou CMON) em execução, isso será possível sem nenhum custo. Você pode executar vários nós do ClusterControl sempre que precisar.
Para esta configuração, teremos nós ClusterControl no topo de um ClusterControl para criar ou implantar os nós do banco de dados e gerenciar um failover automático sempre que ocorrer uma falha, por exemplo. Embora você possa usar MHA, Orchestrator ou Maxscale para gerenciar o failover automático, mas para eficiência e velocidade, usarei o ClusterControl para fazer as coisas especiais que outras ferramentas que mencionei não têm.
Então, vamos dar uma olhada no diagrama para esta configuração:
A configuração baseada nesse diagrama mostra isso no CMON de três nós , um CMON em execução (ClusterControl) está sobre eles, que monitorará o failover automático. Em seguida, o HAProxy poderá fazer o balanceamento de carga entre os três nós CMON monitorados, em que um nó está localizado em uma região separada hospedada no GCP para este blog. Você pode perceber que não incluímos o Keepalived porque não podemos colocar um VIP no GCP, pois ele está em uma rede diferente.
Como você deve ter notado, colocamos um total de três nós. O CMON HA requer que precisamos de pelo menos 3 nós para prosseguir com um processo de votação ou o chamado quorum. Portanto, para esta configuração, exigimos que você tenha pelo menos 3 nós para ter maior disponibilidade.
Implantação de nós de ClusterControl no local
Nesta seção, esperamos que você já tenha configurado ou instalado sua IU do ClusterControl, que usaremos para implantar um cluster de replicação MySQL de três nós usando o Percona Server.
Vamos primeiro criar o cluster implantando uma nova Replicação MySQL conforme mostrado abaixo.
Observe que estou usando o Percona Server 5.7 aqui, para o qual o padrão A configuração do ClusterControl funciona de forma eficiente.
Em seguida, defina o nome do host ou IP de seus nós,
Neste ponto, esperamos que você já tenha configurado dois nós Replicação mestre/escravo hospedada ou em execução no local. A captura de tela abaixo deve mostrar como serão seus nós:
Configure e instale o ClusterControl e habilite o CMON HA no primeiro nó
A partir deste blog anterior ClusterControl CMON HA para alta disponibilidade de banco de dados distribuído, fornecemos brevemente as etapas sobre como fazer isso. Vamos descer novamente e fazer as etapas conforme indicado, mas para esta configuração de replicação mestre/escravo específica.
Primeira coisa a fazer, escolha um nó que você deseja que o primeiro ClusterControl seja instalado (nesta configuração, acabo instalando primeiro no nó 192.168.70.80) e siga as etapas abaixo.
Primeiro passo
Instalar o ClusterControl
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as rootObserve que, uma vez que você seja avisado de que uma instância atual do mysql foi detectada, você precisa permitir que o ClusterControl use o mysqld existente em execução, pois esse é um dos nossos objetivos aqui para o CMON HA e para esta configuração usar o já configurou o MySQL.
Passo Dois
Bind CMON não apenas para permitir via localhost, mas também no endereço IP específico (já que habilitaremos o HA)
## edit /etc/default/CMON and modify the line just like below or add the line if it doesn't exist
RPC_BIND_ADDRESSES="127.0.0.1,192.168.70.80"Etapa Três
Em seguida, reinicie o CMON,
service CMON restartPasso Quatro
Instale as ferramentas de CLI do s9s
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.shDurante esta instalação, a ferramenta s9s configurará um usuário admin para o qual você pode usar ao lidar com o comando s9s, assim como habilitar o CMON HA.
Passo Cinco
Ative o CMON HA
$ s9s controller --enable-CMON-haPasso Seis
Por último, modifique o /etc/my.cnf e adicione,
slave-skip-errors = 1062na seção [mysqld]. Uma vez adicionado, não se esqueça de reiniciar o mysql como,
service mysql restartou
systemctl restart mysqlAtualmente, esta é a limitação que estamos enfrentando com o CMON HA, pois ele tenta inserir entradas de log no escravo, mas isso pode ser bom por enquanto.
Configure, instale o ClusterControl e habilite o CMON HA no segundo nó
Simples como para o primeiro nó. Agora, no 2º nó (192.168.70.70), precisamos fazer as mesmas etapas, mas precisamos fazer alguns ajustes nas etapas para possibilitar esse HA.
Primeiro passo
Copie a configuração para o 2º nó (192.168.70.70) do primeiro nó (192.168.70.80)
$ scp -r /etc/CMON* 192.168.70.70:/etc/Passo Dois
No 2º nó, edite o /etc/CMON.cnf e certifique-se de que o host esteja configurado corretamente. por exemplo.
vi /etc/CMON.cnfEm seguida, atribua o parâmetro hostname como,
hostname=192.168.70.70
Etapa Três
Instale o ClusterControl,
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as rootNo entanto, ignore a instalação do CMON (ou ClusterControl Controller) quando encontrar esta linha,
=> An existing Controller installation detected!
=> A re-installation of the Controller will overwrite the /etc/CMON.cnf file
=> Install the Controller? (y/N):O resto, faça como você fez no primeiro nó, como configurar o nome do host, use a instância em execução do mysqld existente, fornecendo a senha do MySQL e a senha para o seu CMON, que deve ser ambos têm a mesma senha com o primeiro nó.
Passo Quatro
Instale as ferramentas de CLI do s9s
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.shPasso Cinco
Copie a configuração restante do 1º nó para o 2º nó.
$ scp -r ~/.s9s/ 192.168.70.70:/root/
$ scp /etc/s9s.conf 192.168.70.70:/etc/
$ scp /var/www/html/clustercontrol/bootstrap.php 192.168.70.70:/var/www/html/clustercontrol/Passo Seis
Instale o pacote clustercontrol-controller,
Para Ubuntu/Debian,
$ apt install -y clustercontrol-controllerPara RHEL/CentOS/Fedora,
$ yum install -y clustercontrol-controllerEtapa Sete
Copie o arquivo /etc/default/CMON e modifique o endereço IP para o endereço de ligação RPC
scp /etc/default/CMON 192.168.70.70:/etc/default
RPC_BIND_ADDRESSES="127.0.0.1,10.0.0.103"Em seguida, reinicie o CMON da seguinte forma,
service CMON restartEtapa Oito
Modifique o /etc/my.cnf e adicione,
slave-skip-errors = 1062na seção [mysqld]. Uma vez adicionado, não se esqueça de reiniciar o mysql como,
service mysql restartou
systemctl restart mysqlAtualmente, esta é a limitação que estamos enfrentando com o CMON HA, pois ele tenta inserir entradas de log no escravo, mas isso pode ser bom por enquanto.
Passo Nove
Por fim, verifique a aparência dos nós CMON HA,
[[email protected] ~]# s9s controller --list --long
S VERSION OWNER GROUP NAME IP PORT COMMENT
l 1.7.5.3735 system admins 192.168.70.80 192.168.70.80 9501 Acting as leader.
f 1.7.5.3735 system admins 192.168.70.70 192.168.70.70 9501 Accepting heartbeats.
Total: 2 controller(s)Implantando seu nó ClusterControl na nuvem
Como mencionamos anteriormente, a configuração ideal para comunicação é encapsular os pacotes pela VPN ou outro meio de canal seguro. Se você tiver dúvidas sobre como fazer isso, consulte nosso blog anterior Multi-DC PostgreSQL:Configurando um nó de espera em uma localização geográfica diferente sobre uma VPN para a qual abordamos como você pode criar uma configuração VPN simples usando OpenVPN.
Então, nesta seção, esperamos que você já tenha configurado a conexão VPN. Agora, o que vamos fazer é adicionar um escravo que devemos distribuir a disponibilidade do CMON no Google Cloud Platform. Para fazer isso, basta acessar Adicionar Escravo de Replicação, que pode ser encontrado clicando no ícone do cluster próximo ao canto direito. Veja como fica abaixo:
Agora, é assim que vamos terminar com:
Agora, já que adicionamos um novo escravo hospedado no GCP, você pode precisar seguir novamente o que fizemos anteriormente no 2º nó. Vou retransmitir você para seguir essas etapas e seguir as instruções sobre como fizemos no 2º nó.
Depois de tê-lo corretamente, você terá o seguinte resultado:
[[email protected] ~]# s9s controller --list --long
S VERSION OWNER GROUP NAME IP PORT COMMENT
l 1.7.5.3735 system admins 192.168.70.80 192.168.70.80 9501 Acting as leader.
f 1.7.5.3735 system admins 192.168.70.70 192.168.70.70 9501 Accepting heartbeats.
f 1.7.5.3735 system admins 10.142.0.39 10.142.0.39 9501 Accepting heartbeats.onde nos nós
- 192.168.70.80 - (node8) e reside no meu local
- 192.168.70.70 - (node7) e reside no meu local
- 10.142.0.39 - (gnode1) está hospedado no GCP e em uma região diferente
CMON HA em ação
Meu colega Krzysztof Ksiazek já forneceu a configuração para HA usando HAProxy aqui neste blog ClusterControl CMON HA para Alta Disponibilidade de Banco de Dados Distribuído - Parte Dois (Configuração de Acesso GUI).
Para seguir o procedimento indicado no blog, certifique-se de ter os pacotes xinetd e pathlib. Você pode instalar xinetd e pathlib da seguinte forma,
$ sudo yum install -y xinetd python-pathlib.noarchCertifique-se também de ter o CMONhachk definido em /etc/services como abaixo:
[[email protected] ~]# grep 'CMONhachk' /etc/services
CMONhachk 9201/tcpe assegure as alterações e reinicie o xinetd,
service xinetd restartVou pular o procedimento Keepalived e HAProxy e espero que você tenha configurado adequadamente. Uma dica que você deve considerar nessa configuração é que o uso do Keepalived não pode ser aplicável se você estiver dispersando o VIP do local para a rede de nuvem pública porque eles são uma rede totalmente diferente.
Agora, vamos ver como o CMON HA reage se os nós estiverem inativos. Conforme mostrado anteriormente, o nó 192.168.70.80 (node8), estava atuando como líder exatamente como mostrado abaixo:
Em que o banco de dados do nó mestre também mostra que node8 é o mestre da visualização de topologia do ClusterControl . Vamos tentar matar o node8 e ver como o CMON HA continua,
Como você pode ver, gnode1 (nó GCP) está assumindo como líder como node8 vai para baixo. Verificando os resultados do HAProxy para o seguinte,
e nossos nós ClusterControl mostram que o node8 está inativo, enquanto o nó GCP está tomando mais como o mestre,
Por último, acessando meu nó HAProxy que está sendo executado no host 192.168.10.100 em a porta 81 mostra a seguinte interface do usuário,
Conclusão
Nosso ClusterControl CMON HA existe desde a versão 1.7.2, mas também tem sido um desafio para nós desde várias perguntas e preferências de como implantar isso, como usar a Replicação MySQL sobre o Galera Cluster.
Nosso CMON HA ainda não está maduro, mas agora está pronto para atender às suas necessidades de alta disponibilidade. Diferentes abordagens podem ser aplicáveis, desde que suas verificações determinem o nó correto que está funcionando.
Incentivamos você a configurar e implantar usando o CMON HA e nos informar como atende às suas necessidades ou, se o problema persistir, informe-nos como ajudá-lo a atender às suas necessidades de alta disponibilidade.
