(Continuação deste outro post)
O problema da dispersão geográfica pode ser resolvido em várias camadas.
- Pode ser a própria aplicação a assumir a necessidade de manter toda a informação em bases de dados distintas.
- Pode ser o servidor de base de dados a manter repositórios distintos para a mesma base de dados.
- Por fim, podemos ter algum tipo de storage inteligente que seja capaz de manter discos em sítios diferentes sincronizados.
A primeira abordagem é muito pouco elegante do ponto de vista da Arquitectura. Porque é que uma aplicação que lida com maçãs há-de ter que se preocupar com o facto de eu dar muita importância às minhas maçãs e querer tê-las guardadas em dois sítios diferentes? Para além disso, é frequente que as aplicações sejam consideradas off-premises no que a estes problemas diz respeito… Vou esquecer esta hipótese.
A segunda abordagem faz mais sentido. Há várias bases de dados (proprietárias ou open-source) que lidam com o problema através de mecanismos de replicação e clustering. Umas fazem-no de forma síncrona, outras de forma assíncrona, há muitas alternativas por onde escolher e é um mundo bem conhecido de muita gente.
A terceira hipótese é, na minha opinião, aquela que faz mais sentido de todas. O problema que descrevi não me obriga, por si só, a ter duas bases de dados, não me obriga a balancear carga, nem sequer me impõe requisitos de alta disponibilidade. A única coisa que está em causa é mesmo a recuperação de um desastre. Para conseguir fazer isso basta-me, de facto, ter uma cópia permanentemente actualizada dos discos onde guardo a base de dados num sítio longínquo.
Sabendo isto, que alternativas tenho?
Replicação de Base de Dados
Se me quiser manter dentro das soluções open-source (é sempre uma preferência), a opção clara é pelo MySQL. Ora o MySQL oferece duas formas de manter uma ou mais cópias da informação de uma base de dados em dois ou mais sítios. Uma é através dos mecanismos normais de replicação, a outra é através de um produto mais ou menos autónomo, que é o MySQL Cluster.
A replicação do MySQL é sempre assíncrona e é feita através da replicação de um binary log serializado de todas as transacções executadas sobre a base de dados. Isto não serve. Como a replicação é assíncrona, um desastre na localização que tivesse a cópia master da base de dados fazia-me perder as maçãs que estivessem in flight. Isto não é aceitável, vou ter que descartar esta opção.
O MySQL Cluster é síncrono! É verdade que faz muito mais do que aquilo do que preciso, mas pelo menos é síncrono. Tem no entanto um problema inesperado: pelo menos na versão actual obriga a que toda a base de dados caiba em memória! Alguns testes feitos com a aplicação levaram-me a ter bases de dados de maçãs com vários gigabytes, e estavamos apenas em testes. É verdade que podia comprar servidores com muita memória, transformar todo o disco em swap space, mas a verdade é que me pareceu que estava a tentar resolver o problema com a ferramenta errada. Se não houvesse alternativas até podia ser, mas…
Não seria justo não falar das alternativas proprietárias. A Microsoft lançou com o SQL Server 2005 uma nova tecnologia denominada database mirroring, que faz precisamente o que se pretende. O downside desta hipótese são as duas licenças de Windows 2003 + duas licenças de SQL Server 2005, que levam a solução para cerca de 12 K€… Ouch!
Claro que Oracle e DB2 também têm respostas para este problema, mas o preço é ainda superior.
Replicação de Storage
No capítulo da replicação de storage, as soluções mais badaladas são todas proprietárias. As que conheço melhor são as da IBM, mas outros vendors têm soluções semelhantes. Copiando directamente de um PDF da IBM, existem as seguintes opções:
Enhanced Remote Mirroring consists of Global Mirror, Global Copy, and Metro Mirror and is designed to provide the ability to mirror data from one storage system to another over extended distances. It is
designed to control synchronization from within the storage system so that it is nearly transparent to the host application servers. Unlike FlashCopy, Enhanced Remote Mirroring is designed to provide continuous updates from the primary logical drive to the secondary. This is designed to provide data availability, and is a key technology for implementing Disaster Recovery and Business Continuity plans. The Metro Mirror mode is designed to provide synchronous mirroring for logical drives. Global Mirror mode is designed to provide asynchronous mirroring and includes the write-order consistency option.
O grande problema desta solução é que obriga a ter não uma, mas duas SAN IBM, pelo menos da gama 4000 e, dependendo dos modelos, pode ser ainda necessária uma licença específica para activar a feature de Enhanced Remote Mirroring. Usando preços de equipamentos usados disponíveis para encomendar na net, a brincadeira dificilmente ficaria por menos de 50K€… way too much!
Mas a ideia é boa e felizmente o mundo open-source tem uma palavra a dizer. Um dos componentes mais usados para construir clusters linux, logo a seguir ao heartbeat, é o DRBD – Distributed Remote Block Device. Simplificando muito, pode pensar-se no DRBD como uma espécie de RAID 1 entre dois discos que estão em servidores diferentes, e em que o meio usado para sincronização dos discos é uma rede IP em fez de um backplane SCSI.
Felizmente o DRBD tem um modo de funcionamento em que a replicação é síncrona, isto é, uma escrita em disco só é ack’ed depois de a escrita no disco remoto o ter sido: exactamente o pretendido!
Parece ter sido identificado o melhor candidato. Como o post vai longo, reservo para a próxima a apresentação da solução completa.
