Linux e CIA: iMasters - Cluster no MySQL - Parte 01

terça-feira, julho 21, 2009

iMasters - Cluster no MySQL - Parte 01 - Linux

Quinta-feira, 26/02/2009 - 10:00 - Por Mauro Pichiliani
Seções relacionadas:
Cluster no MySQL - Parte 01

Olá, pessoal. Na coluna desta semana mostrarei como implementar um cluster com servidores MySQL rodando no Linux.
A necessidade de se montar um cluster no MySQL está relacionada à alta disponibilidade das informações e à tolerância a falhas. Com dois ou mais servidores MySQL sendo executados em cluster os dados são automaticamente replicados entre os servidores e cada nó que pertence ao cluster pode ser removido sem afetar a disponibilidade da aplicação.
O MySQL possui recursos para implementar o cluster nativamente, ou seja, não é preciso instalar nenhum software adicional, além da versão do MySQL já preparada para receber o cluster. O nome utilizado para identificar o componente do MySQL que permite a criação de clusters é NDBCluster e funciona como um engine do banco de dados. Neste artigo utilizarei o MySQL versão 5.0.51 sendo executado em servidores Linux com a distribuição Ubuntu 8.04 (Hard Heron).
O conceito de engine pode confundir alguns usuários que estão acostumados com o SQL Server ou mesmo o Oracle, pois estes produtos não permitem que o usuário escolha o engine do banco de dados. A idéia é que cada engine proporcione características próprias que tragam algum benefício. Por exemplo, no MySQL temos um engine que permite a utilização de transações. Para criar o cluster é preciso indicar que as tabelas que apresentaram a replicação automática utilizam o engine NDBCLUSTER. Notem que não é preciso nenhum hardware específico para a criação de um cluster MySQL.
O cluster do MySQL age de forma transparente, ou seja, a aplicação cliente não precisa saber que o cluster do MySQL está sendo utilizado. Esta característica facilita a utilização desta ferramenta e expande o leque de possibilidades tanto para o desenvolvedor como para quem administra o MySQL. Do ponto de vista de desenvolvimento, não há nenhuma mudança significativa: basta apenas continuar conectando em um endereço IP normalmente. Já para quem administra é preciso cuidados especiais, pois algumas configurações não são replicadas pelo cluster. Por exemplo, os logins e as permissões devem ser configuras nos servidores de forma independente.
É possível utilizar o cluster do MySQL em conjunto com o MySQL Proxy, apresentado em uma coluna anterior aqui no iMasters. Como o cluster apenas replica as instruções para todos os nós ele não distribui a carga entre os servidores. A utilização do MySQL Proxy com o cluster fornece a consistência ao ambiente, pois desta maneira o cluster garante que as bases de dados ficaram iguais. Já o MySQL Proxy permite dividir a carga entre os servidores de acordo com alguma regra específica. Porém cabe aqui dizer que o MySQL Proxy possui recursos para programar como será feita a distribuição de carga por meio da programação na linguagem LUA.
Os principais componentes de um cluster MySQL são os nós, ou seja, servidores MySQL já instalados. Também é preciso dispor de um servidor que receberá o serviço de administração do cluster. Este servidor que administrará o cluster não requer um MySQL instalado, pois apenas os arquivos binários do servidor NDBCluster precisam ser executados. É possível realizar a manutenção e checar o status do cluster conectando-se ao servidor NDBCluster, remotamente ou não.
Para entender o exemplo que será apresentado vamos observar o diagrama da Figura 1, que traz um cenário onde um sistema qualquer é utilizado por vários usuários. Neste cenário os clientes utilizam a aplicação normalmente se conectando no servidor Linux chamado ubuntu02 cujo endereço I.P é 192.168.1.25. Este cenário não contém nenhum tipo de replicação, balanceamento de carga ou tolerância a falhas. Caso aconteça alguma indisponibilidade do banco de dados do servidor ubuntu02 o uso da aplicação ficará comprometido.
Figura 1. Ambiente sem balanceamento de carga, replicação e tolerância a falhas.
A partir do ambiente apresentado na Figura 1 vamos montar um cluster com três servidores: um que conterá as ferramentas de administração do cluster e dois servidores MySQL com o mesmo banco de dados que está sendo utilizado pela aplicação. Notem que poderíamos utilizar mais de dois servidores de bancos de dados de acordo com a necessidade. A idéia aqui é que o servidor que conterá as ferramentas administrativas do cluster replique as instruções enviando igualmente os dados entre os dois servidores de bancos de dados de forma simultânea. Desta maneira o cenário contará com a tolerância a falhas, pois se um servidor não estiver disponível o cluster permite que a aplicação ainda continue sendo utilizada, uma vez que um servidor ainda está disponível. A Figura 2 apresenta o cenário com a configuração do cluster.
Figura 2. Ambiente com um cluster MySQL composto de dois nós.
Do ponto de vista da aplicação a única mudança que deve ser feita é a mudança da conexão com o banco de dados: antes a conexão era feita diretamente para o servidor 192.168.1.25 e agora a conexão será para o servidor 192.168.1.15. Novamente, o cluster não requer que o MySQL seja instalado no servidor na qual as aplicações vão se conectar, ou seja, o servidor 192.168.1.15 não precisar ter o MySQL instalado. É preciso apenas contar com os arquivos binários que compõem o serviço do cluster. Estes arquivos binários são encontrados junto com os arquivos de instalação do MySQL.
O funcionamento do cluster evita a falta de sincronia entre os dois servidores. Por exemplo, se um usuário A se conectar ao cluster e fizer uma instrução UPDATE nos dados de uma tabela este UPDATE será automaticamente enviado para os servidores 192.168.1.25 e 192.168.1.35, deixando os bancos de dados em sincronia. Caso algum dos servidores não possa executar a instrução UPDATE por algum motivo um erro é gerado e automaticamente a instrução é cancelada nos dois servidores.
Outra questão a ser considerada é o ponto de falha representado pelo servidor ubuntu01. Se ele ficar off-line a aplicação não poderá se conectar a nenhum dos bancos de dados. Para isso existe como configurar a tolerância de falha para o serviço de cluster em outro servidor de modo que ele detecte esta falha. Porém no exemplo não apresentarei como fazer isso, pois se trata de um tópico mais avançado.
Existem várias formas de se trabalhar com tolerância a falhas nos servidores Linux. Para quem desejar se aprofundar recomendo soluções que envolvem a configuração de endereços I.P virtuais diretamente no kernel. Apenas para referência, uma dessas aplicações que fazem a criação de endereços I.P. virtuais no Linux é o Ultra Monkey com os módulos do kernal IPVS. Outra alternativa mais fácil de se configurar é o pacote do HeartBet + PerlBal
Com isso terminamos a primeira parte do artigo que explicará como montar um cluster no MySQL. Na próxima coluna veremos passo a passo como configurar o MySQL e o serviço de cluster, além da criação do banco de dados e do teste de instruções.
Referência: HOWTO set up a MySQL Cluster for two servers (three servers required for true redundancy):
http://dev.mysql.com/tech-resources/articles/mysql-cluster-for-two-servers.html
É isso aí pessoal, um grande abraço e até a próxima.