MySQL Cluster: Alta Disponibilidade com Interface NoSQL

Diante das constantes modificações tecnológicas e a crescente demanda por serviços web que atendam as requisições de acesso em tempo real, se faz necessário ter uma solução que se adapte às estas mudanças. Visto que os sistemas de informação tornaram-se onerosos, com o advento do NoSQL e a sua nova abordagem no tratamento dos dados, tendo como base a utilização do par, chave-valor, que trouxe a agilidade necessária para as demandas atuais.

Neste contexto, a fim de unir a infraestrutura atual das organizações com todas as vantagens de um sistema de banco de dados relacional, ao sistema de banco de dados NoSQL, este artigo visa propor a construção de uma solução híbrida, procurando reunir o modelo relacional do MySQL Server junto à API do próprio, que oferece suporte à interface NoSQL.

Pretende-se com essa abordagem técnica atender a uma aplicação que demande disponibilidade operacional 24x7, tal como a de um comércio eletrônico, por exemplo.

Banco de Dados

Entre as funcionalidades de um SGBD destacam-se o aprovisionamento dos privilégios de acesso, a disposição de planos de backup e recuperação, otimização de consultas, performance, disponibilidade, controle da redundância e da segurança dos dados.

O principal objetivo de um SGBD é o de proporcionar um ambiente tanto conveniente quanto eficiente para a recuperação e armazenamento das informações do banco de dados.

Um SGBD é composto por um conjunto de softwares que são adotados como os gerentes dos bancos de dados a fim de proteger o controle dos negócios. Dentre os modelos de dados mais utilizados, este artigo abordará as caraterísticas do relacional e do NoSQL.

De acordo com DB-Engines (2015), o modelo relacional é o tipo de banco de dados mais utilizado do mercado. Classificado no topo do ranking dos SGBDs, o modelo ocupa as três primeiras posições: Oracle seguido do MySQL e SQL Server.

Modelo MySQL

O modelo relacional representa os dados como uma coleção tabelas. Cada entidade possui uma estrutura que se repete a cada linha, como pode-se observar ao utilizar uma planilha, onde cada linha representa um registro e cada coluna, um tipo de dado.

A Figura 1 apresenta o modelo ER - Entidade Relacionamento, que ilustra as entidades, atributos e relacionamentos de um banco de dados relacional.

Figura 1. Representação do Modelo Entidade Relacionamento

Conforme evidenciado por Suehring (2002), um banco de dados relacional é uma coleção de uma ou mais tabelas, que se relacionam.

Este modelo destaca-se pela gerência das transações por meio da propriedade ACID - Automaticidade, Consistência, Isolamento e Durabilidade, se comprometendo com a autenticidade dos dados. As principais vantagens desta abordagem são a independência e a visão múltipla dos dados.

Modelo NoSQL

Este modelo pretende suprir os problemas de escalabilidade apresentado pelos modelos de dados tradicionais, garantindo alto desempenho para ambientes que necessitam da agilidade das transações. (Nascimento, 2010).

NoSQL possui a capacidade de trabalhar com dados não estruturados, contribuindo com diversos ramos, como a medicina, inteligência artificial e a estatística, a partir da análise, com precisão, de uma grande massa de dados. Com o advento desse banco é possível traçar estratégias eficazes adequadas a cada tipo de negócio.

O modelo NoSQL, baseado no par, chave-valor, é composto por uma coleção de dados indexados a partir da sua respectiva chave, sendo adequado para a proposta deste artigo, que pretende agilizar o tempo de resposta da aplicação, conforme apresentado na Figura 2.

Figura 2. Representação do modelo NoSQL baseado no par Chave-Valor

Independentemente das vantagens do banco relacional ou do NoSQL, não há uma regra que defina a melhor solução, visto que esta decisão cabe a aplicação que melhor se adequará à tecnologia.

Em contraponto, segundo Dias (2014), há situações em que é viável unir os dois modelos, usufruindo dos potenciais de ambos. É comum o uso de soluções híbridas, que usam tanto banco relacional como NoSQL. Um exemplo disso é quando em um produto há demanda por um controle transacional e, ao mesmo tempo, picos de acessos que exigem baixo tempo de resposta.

Banco de Dados Distribuído

Diferentemente do modelo convencional, onde os bancos estão centralizados em um único servidor, os bancos distribuídos são dispersos em vários servidores, uma vez que os mesmos podem ser replicados geograficamente, aumentando a segurança dos dados em caso de catástrofes. A Figura 3 apresenta o modelo desta arquitetura.

Figura 3. Arquitetura de Banco de Dados Distribuído

Um banco de dados distribuído é um conjunto de banco de dados parciais independentes que compartilha um esquema comum e que coordena o processamento de transações com acesso de dados não local. Dentre as características destaca-se a transparência da replicação ao usuário final.

Com a utilização de um sistema de banco de dados distribuído, aumenta-se o nível da confiabilidade, disponibilidade e desempenho do banco como um todo, visto que o sistema será capaz de gerenciar um alto tráfego.

Cluster

Cluster pode ser definido como um sistema que compreende dois ou mais computadores que trabalham de maneira conjunta para realizar diversos tipos de processamento. (Pitanga, 2003)

Cada computador de um cluster é chamado de nó. Os nós de um cluster dividem as tarefas de processamento e trabalham como uma única máquina.

Um cluster deve estar previamente preparado para receber novos nós em sua arquitetura, ou ainda, em caso de danos, estar preparados para a retirada de um deles. Neste caso, todo o processamento destinado àquele nó deve ser redistribuído aos demais. Isto se faz necessário para que a remoção de um dos nós não interfira no funcionamento do cluster como um todo.

Este artigo aborda a implementação de um cluster de alta disponibilidade com o balanceamento de carga a fim de aumentar a disponibilidade e a escalabilidade dos serviços.

Cluster de Alta Disponibilidade com o Balanceamento de Carga

Este tipo de cluster tem como finalidade prover, de maneira ininterrupta, a disponibilidade e a distribuição dos seus serviços entre os nós que compõe o cluster. Estas operações se apresentam de maneira transparente ao usuário.

A disponibilidade de um serviço é calculada com base na porcentagem que quantifica a probabilidade de encontrar o serviço operacional em determinado momento. A esta porcentagem associa-se o termo Uptime do serviço, isto é, tempo em que o serviço se encontra operacional. Deste modo, A (t) é a probabilidade de que o sistema esteja funcionando e pronto para uso em um dado instante de tempo t.

Com a incorporação de mecanismos contra falhas, pode-se aumentar a disponibilidade do sistema.

A combinação da Alta Disponibilidade com o Balanceamento de Carga é adequada para ambientes que trabalham diretamente com o desempenho do cluster.

Clusters de balanceamento de carga são amplamente utilizados em serviços de comércio eletrônico e provedores de internet, visto que, estes ambientes necessitam resolver as diferenças de carga provenientes de múltiplas requisições de entrada em tempo real.

No entanto, a eficiência de um comércio eletrônico é calculada através da disponibilidade e da capacidade de gerenciar com eficiência os recursos computacionais de toda a sua infraestrutura.

Praticando

Dentro deste escopo de desenvolvimento foram implementadas sete máquinas virtuais com o Sistema Operacional Linux Debian, sendo quatro máquinas, em particular, para viabilizar o MySQL Cluster DB.

Na composição do MySQL Cluster, duas máquinas foram destinadas como nós gerentes e as outras duas como nós de dados e SQL (para essas duas, uma de redundância, em espelho). Uma característica importante desta estrutura é que os nós de SQL recebem o balanceamento de carga, contribuindo com múltiplas consultas simultâneas.

Para a viabilização da API NoSQL, foi aplicado um cluster, master-slave, a partir de duas máquinas, visando a garantia da disponibilidade do cache em caso de queda de um dos nós. E, uma última máquina, utilizada para a instalação da aplicação.

Portanto, pode-se afirmar que esta infraestrutura dispõe de dois clusters, um para o MySQL e outro para o NoSQL, que operam como um cluster integrado, em paralelo, visando oferecer alta disponibilidade da aplicação.

Estruturada na linguagem PHP, a página de teste desta infraestrutura é voltada ao comércio eletrônico, ramo onde a eficiência da aplicação pode determinar a valorização do negócio.

Dentre as configurações de hardware utilizadas para a implementação desta solução, destacam-se: um Processador Intel Core i5, segunda geração, e 8GB de memória RAM.

A Figura 4 apresenta a infraestrutura que atenderá a interface NoSQL:

Figura 4.Cenário da infraestrutura dos clusters

O nó de aplicação se comunica com o master do Cluster NoSQL através do seu IP Virtual, retornando os dados solicitados pela aplicação.

O cache viabiliza a diminuição de carga no servidor de banco de dados, reportando a disponibilidade da página e a navegabilidade do site para o Cluster NoSQL.

Já o sistema de busca da aplicação e as atualizações no site que exijam do modelo transacional, serão direcionadas aos nós de SQL, como pode-se observar ao efetuar uma compra.

Quando houver atualizações de registros no banco via aplicação, será invocada a atualização do cache, que por sua vez, se comunica com o master dos nós gerentes do MySQL Cluster.

A carga de acesso aos nós de SQL é dividida por meio do balanceamento de carga, que checa os bancos ativos intercalando as conexões entre os nós.

A Tabela 1detalha as configurações presentes em cada nó com os seus respectivos serviços:

Tabela 1.Configurações e serviços de cada nó do cluster

Nas próximas sessões deste artigo serão detalhadas as principais características das ferramentas utilizadas na composição desta solução.

MySQL Server

É um sistema de banco de dados relacional, cliente/servidor, desenvolvido para manipular grandes quantidades de dados garantindo agilidade e confiabilidade das informações.

“O MySQL é o banco de dados de código aberto mais popular do mundo, com uma estimativa de mais de 15 milhões de instalações e dezenas de milhares de novos downloads diários”. Oracle apud Gartner (2008).

Considerado um dos servidores de bancos de dados relacionais mais rápidos do mundo, o MySQL foi desenvolvido com o intuito de manter o custo baixo na instalação e manutenção do banco de dados.

“O MySQL é reconhecido por sua capacidade de ser executado e dimensionado horizontalmente em todo o hardware. Isso o tornou o banco de dados preferencial para os aplicativos mais exigentes e das maiores empresas na web, incluindo o Facebook, que tem milhares de servidores MySQL e escalou o MySQL para gerenciar mais de 1 bilhão de usuários ativos”. (Oracle, 2012)

MySQL Cluster

É um software livre projetado para oferecer disponibilidade de 99,999% com a garantia de recuperação de falhas e a capacidade de realizar a manutenção programada, sem tempo de inatividade. (Oracle, 2015)

O MySQL Cluster consiste na aplicação, responsável pela interface com o cliente, onde recebe as consultas por meio do SQL Node, um servidor MySQL tradicional que utiliza o motor de armazenamento NDB Cluster, onde é realizado o processamento dos dados. Estes processos são gerenciados pelo Management Node, utilizado pelos administradores de banco dados a fim de configurar, inicializar e parar os nós. (Oracle, 2015)

A Figura 5 apresenta a disposição destes serviços entre os nós:

Figura 5.Arquitetura do MySQL Cluster

O MySQL Cluster garante a integridade dos dados por meio da replicação síncrona, onde as transações são concluídas quando todos os nós confirmarem a sua atualização. Deste modo, pode-se afirmar que os pontos de falhas são contornados por meio do espelhamento dos dados entre os Data Nodes, garantindo a disponibilidade da aplicação.

Dentre os clientes desta tecnologia, destacam-se: Apple, Juniper, PayPal, Sky, empresas de telefonia, dentre outros. O MySQL Cluster deve ser considerado como uma solução para ambientes que visam a performance, escalabilidade, disponibilidade, flexibilidade, estabilidade e a segurança, observando o custo total da propriedade e o conhecimento da equipe. (Lastori, 2013)

API MemCached

A Oracle integrou capacidades NoSQL junto ao MySQL Cluster, a partir da versão 7.2.1, garantindo a eficiência no acesso aos dados.

Conforme descrito pela Oracle (2015), mantenedora da comunidade MySQL, com a API MemCached padrão, o aplicativo envia, lê e escreve para o processo MemCached, que por sua vez, chama o driver MemCached para NDB. Deste modo, consultas a partir da API NDB, tem o acesso mais rápido aos dados mantidos em nós de dados do MySQL Cluster, pois o mesmo ignora a camada de SQL.

“MemCached é a API popular que ‘fala’ NoSQL, provê alta performance, especialmente para aplicações web diminuindo a carga do banco de dados relacional. Utilizado pelo Twitter, Facebook, YouTube e entre outros”. (MySQL, 2011).

Esta solução foi projetada com o intuito de prover a flexibilidade de uso, sendo possível co-localizar a API MemCached em todos nós ou somente nos nós de dados, de aplicação ou, em alternativa, situá-la em uma camada MemCached dedicada.

A API se utiliza da memória RAM disponível no servidor, guardando em cache os dados acessados com frequência. Com a utilização deste cache, há uma diminuição de carga no servidor, suportando um alto tráfego sem a necessidade de aumentar os recursos da infraestrutura.

A principal vantagem da utilização desta API, está na velocidade do acesso aos dados, assegurando o desempenho em tempo real, sem descumprir com as propriedades ACID presentes no banco MySQL.

HAProxy

HAProxy, que significa High Availability Proxy, é um poderoso software open source, leve e de fácil configuração, voltado para aplicações baseadas nos protocolos TCP (Transmission Control Protocol) e HTTP (Hypertext Transfer Protocol). (HAProxy, 2015)

Esta ferramenta dispõe de recursos de alta disponibilidade, balanceamento de carga e proxy. No entanto, o HaProxy é apto para atender a demanda de toda a infraestrutura de um serviço web, seja aplicação ou banco de dados, suportando milhares de conexões em hardwares modestos. (HAProxy, 2015)

O HaProxy é utilizado como uma alternativa eficiente para a melhoria do desempenho e da confiabilidade de um servidor por meio da distribuição da carga de trabalho entre os seus nós.

A ferramenta é amplamente utilizada por empresas que avaliam o balanceamento de carga como recurso prioritário para a estabilidade dos seus negócios, como o GitHub, Instagram e Twitter.

KeepAlived

É um framework que mantém a disponibilidade de um serviço por meio do protocolo VRRP - Virtual Routing Redundancy Protocol, que elege o nó com maior prioridade como mestre e os demais, como backup. Os níveis de prioridade são definidos no arquivo de configuração do KeepAlived.

O nó principal (mestre) recebe um IP Virtual que estabelece a comunicação com a aplicação, enquanto os nós de backup ouvem a atividade do mestre. No entanto, o KeepAlived efetua checagens a nível de rede, transporte e aplicação. Se uma das checagens falhar, o mesmo se encarrega de direcionar o IP Virtual para o servidor de backup, que assumirá o serviço.

Para configurar um ambiente de alta disponibilidade é necessário, no mínimo, dois servidores, um definido como mestre e o outro como backup, garantindo a atividade da aplicação em caso de falhas.

Apache

O Apache é um servidor web, open source, responsável pela troca de informações com outras máquinas, que são chamadas de clientes, onde o cliente solicita as informações e o servidor atende aos pedidos. (Alecrim, 2006)

Com esta troca de dados, o Apache disponibiliza a página web, sendo possível realizar compras on-line, enviar e-mails, checar extrato da conta bancária e entre outros.

Um servidor web necessita estar disponível ininterruptamente a fim de atender as solicitações sempre que houver a necessidade.

Linguagem PHP

PHP (Hypertext Preprocessor) é uma linguagem de script, open source, adequada ao desenvolvimento web, podendo ser embutida dentro do HTML. (PHP, 2015)

Todo código PHP é executado no servidor, tornando-o capaz de interagir com um banco de dados ou aplicações internas. Uma das grandes vantagens desta característica é o de não expor o código fonte para o cliente, contribuindo com a segurança no gerenciamento de senhas e de informações confidenciais. (PHP, 2015)

O PHP é uma das linguagens mais populares do mundo que destaca por sua velocidade e flexibilidade, além de possuir a orientação a objetos.

Resultados

Conforme evidenciado por Harrington (2010), a parte mais lenta das ações de um Sistema Gerenciador de Banco de Dados é a de recuperar e gravar dados no disco. Partindo deste princípio, com a incorporação do MemCached, oferecido pela API NoSQL, é possível utilizar o par chave-valor, garantindo o acesso a partir da consulta dos dados em memória que, juntamente com o cluster MySQL, provê a distribuição da carga de operações, de acordo com a sua finalidade: consultas nas sessões do site são dirigidas ao cluster NoSQL e transações são dirigidas ao cluster MySQL.

Essa proposta, se deu à natureza da aplicação do comércio eletrônico que, em geral, tem um volume alto de consultas em detrimento a um volume menor de transações.

Portanto, admite-se que a proposta vem de encontro a oferecer, de fato, uma solução que utilize o melhor dos dois modelos, relacional e NoSQL: para o relacional, transações com a garantia de integridade e, para o NoSQL, a altíssima eficiência em consultas.

Formação do cache

Diferentemente do modelo convencional, onde o acesso aos dados em um banco relacional é cedido por meio do padrão SQL - Structured Query Language, com a API MemCached é possível atribuir capacidades NoSQL ao SGBD MySQL.

O banco de dados ndbmemcache é responsável pela atribuição do modelo chavevalor ao MySQL, contendo três tabelas que determinam o comportamento da interface NoSQL: containers, produto e key_prefixes.

A Figura 6 apresenta a entidade containers com 16 registros que estabelecem a comunicação com a tabela produto, onde os dados são representados no formato chave-valor, conforme ilustrado na Figura 7.

Figura 6.Demonstração da formação do modelo chave-valor

A Figura 7 representa um dos registros presentes na página principal, cujo prefixo do

identificador atribuído ao produto corresponde a sua sessão no site.

Figura 7.Demonstração dos dados no formato chave-valor

A tabela key_prefixes é responsável pela definição das chaves com os seus respectivos privilégios de acesso à tabela containers, que por sua vez, se comunica com os dados no formato chave-valor da tabela produto. A Figura 8 apresenta o modelo das chaves definidas que servirão a aplicação.

Figura 8.Definição das chaves do modelo chave-valor

Deste modo, o daemon MemCached fará a comunicação com o banco ndbmemcache quando for invocada uma atualização do cache ou quando for solicitado um dado que não esteja em memória.

Atualização do cache

Foram implementadas duas funções no PHP com o intuito de controlar o sistema NoSQL, deixando-o sempre atualizado e disponível para novas requisições de acesso.

A primeira função, denominada como, update_memcache(), conta com a busca dos dados da capa do site através do padrão SQL a fim de inseri-los nas tabelas destinadas ao cache, conforme ilustrado na Listagem 1.

Listagem 1.Demonstração da funçãoupdate_memcache()

while($produto=mysql_fetch_row($vet)){ $ident= “capa.”.$i; //Nome $key_chave= ‘prod_nome:’ . $ident; $value_chave = “produto[1]”; $m->set($key_chave,$value_chave); //Descrição $key_chave= ‘prod_desc:’ . $ident; $value_chave = “produto[2]”; $m->set($key_chave,$value_chave); }

O tempo de atualização do cache da página principal é de aproximadamente 1,5 segundos. Esta função também é encarregada pela atualização dos demais produtos que são distribuídos entre as sessões do site.

A atualização total do cache é de aproximadamente 4 minutos, onde 4.999 produtos são enviados para o sistema de cache. No entanto, o tempo de atualização não traz prejuízos ao negócio, visto que, todas transações são direcionadas ao MySQL Cluster, que se encarrega de executar o commit (que atualiza as alterações no disco) a nível do SGBD.

A segunda função, chamada de search_body_memcache(), procura os dados no cache para compor os dados da aplicação. Esta função será invocada todas as vezes que uma nova consulta for realizada ou que novas solicitações de acesso ao site forem iniciadas. A Listagem 2 apresenta uma demonstração de como os valores são buscados no cache NoSQL:

Listagem 2.Demonstração da funçãosearch_body_memcache()

$m=new Memcached(); $m=addServer(‘192.168.0.01’,11211); while($i<27){ $result[$i]=$m->get(“prod_capa:$capa.$i”); $nome=$m->get(“prod_nome:$capa.$i”); $marca=$m->get(“prod_marca:$capa.$i”); }

Validação e Testes

A fim de demonstrar a eficiência do MySQL Cluster unido à API MemCached, foram aplicados testes de desempenho a partir da aplicação, que dispõe de 26 produtos em sua vitrine dos 4.999 produtos armazenados nos bancos de dados.

O cache NoSQL pretende atender todas sessões do site, tornando a carga do banco de

dados mais leve. A Figura 9 apresenta parte da página principal do site:

Figura 9. Página principal da aplicação de teste

A primeira prova desta solução é destinada a performance da aplicação com o cluster de banco de dados e, em seguida, é apresentada a proposta da camada NoSQL. No entanto, a Figura 10 demonstra os nós ativos durante a execução dos testes de atualização do cache e consulta ao banco de dados a fim de justificar a atividade do cluster:

Figura 10.Listagem dos nós ativos do cluster

O cluster é operado com apenas um nó gerencial ativo, demonstrando a estabilidade dos serviços em meio a parada de um dos seus componentes.

O cluster também conta com dois nós de dados e SQL ativos além de contar com três nós de cache, que correspondem à primeira máquina do MemCached.

Em ambos testes, seja na consulta ao banco ou no cache, foram simuladas 100 conexões simultâneas através da ferramenta ApacheBench, aumentando o número de conexões até 1000. A seguir, serão demonstrados os resultados desta operação.

Performance da aplicação aliada ao banco de dados

De acordo com os resultados obtidos pelo ApacheBench, foram gastos 44 segundos

para a conclusão do teste, sendo que, 882 das 1000 requisições apontaram falhas.

Figura 11.Requisições de acesso ao banco de dados

Figura 12.Tempo das requisições de acesso

Também foi submetida na página a função microtime() da linguagem PHP em um período sem tráfego na aplicação. O tempo de acesso à página foi satisfatório, visto que, o mesmo não ultrapassou 1,5 segundos.

Incorporação do cache NoSQL à Interface Web

Após a atualização do cache no NoSQL, foi submetido o teste do ApacheBench ao sistema NoSQL. A Figura 13 apresenta o resultado.

Figura 13.Requisições de acesso ao sistema NoSQL

Do mesmo modo, foi avaliado o tempo de requisições com o cache NoSQL, conforme apresentado na Figura 14.

Figura 14.Tempo das requisições de acesso aliado ao NoSQL

O tempo de resposta da aplicação utilizando a função microtime() para a consulta no cache NoSQL em um momento sem tráfego, obteve praticamente o mesmo resultado da consulta direta ao banco. A página foi carregada em apenas um 1 segundo.

Considerando 2GB de RAM, segmentado entre as máquinas de cache e aplicação, o resultado dos testes com o ApacheBench demonstra que o site suportou 876 conexões com eficiência.

A Tabela 2 apresenta o resumo dos testes de desempenho da aplicação, tendo como vertentes: a comunicação do site com o banco de dados e a incorporação da camada de cache NoSQL nesta infraestrutura.

Tabela 2. Resumo dos testes de desempenho

A partir dos dados apresentados, pode-se afirmar que o sistema de cache é altamente recomendável para ambientes que necessitam gerenciar um alto tráfego de acesso com segurança e agilidade no acesso à informação, visto que com a incorporação do sistema NoSQL, as falhas nas requisições de acesso diminuíram quase 7 vezes em relação ao modelo que contempla somente a tecnologia do MySQL Cluster.

A solução cache NoSQL, associada ao banco de dados é adequada para ambientes críticos, onde a segurança da informação e o tempo de resposta são essenciais para a evolução do negócio. A infraestrutura proposta garante a integridade dos dados através do modelo relacional unido ao melhor do NoSQL por meio do cache chave-valor, que assegura um tempo de resposta ágil para as demandas atuais.

Este tipo de implementação é justificado para ambientes que se utilizam de dados sigilosos, como o número da conta bancária de um cliente, cenário onde os bancos devem ser bem estruturados a fim de que o sistema não apresente brechas de segurança e entre outras falhas de normalização que podem ser tratadas nos bancos relacionais. No entanto, somente os dados com um baixo nível de exposição aos riscos serão entregues ao cache NoSQL, não comprometendo a autenticidade de dados importantes.

Referências

ALTMANN, Marcelo. MySQL & NoSQL - Memcached Plugin
Http://planet.mysql.com/entry/?id=5988879

BADGLEY, Jarvis. Introduction to using MySQL as a NoSQL store via Memcached
http://chipersoft.com/p/MySQL-via-Memcache/

FROM DUAL. Making HaProxy High Available For MySQL Galera Cluster
http://www.fromdual.com/making-haproxy-high-available-for-mysql-galera-cluster

HARRINGTON, Jan. Projeto de Bancos de Dados Relacionais: Teoria e Prática. 2 ed. Rio de Janeiro: Campus, 2002.

HAPROXY. HAProxy - A carga confiável, de alto desempenho TCP / HTTP Balancer
http://www.haproxy.org/#desc

LASTORI, Airton. MySQL Cluster - Visão geral
http://pt.slideshare.net/MySQLBR/mysql-cluster-viso-geral

MORGAN, Andrew. Scalable, Persistent, HA NoSQL Memcache Storage Using MySQL Cluster.
http://www.clusterdb.com/mysql-cluster/scalabale-persistent-hanosql-memcache-storage-using-mysql-cluster

REFERENCE MANUAL: Using MySQL with memcached
http://dev.mysql.com/doc/refman/5.1/en/ha-memcached.html