MySQL sliding window archive

Dezembro 2, 2007 on 4:05 am | In database, linux, MySQL, storage | No Comments

O objectivo
Já aqui falei sobre logs centralizados. O objectivo que se pretende atingir é concentrar todos os logs de um datacenter num único sítio para consulta fácil e arquivo histórico. Mais concretamente, é importante:

  • Guardar todos os logs durante pelo menos 5 anos.
  • Manter os últimos meses rapidamente acessíveis e passíveis de serem consultados de forma flexível e rápida.
  • Garantir que em caso de avaria grave não se perdem mais do que 1 ou dois dias de logs.

Noutro post falei da possibilidade de usar o Archive storage engine como forma de reduzir o espaço ocupado e, simultaneamente, dificultar o encobrimento de acções ilegítimas através da eliminação de logs. 

Os problemas
Ao tentar usar o Archive storage engine como repositório de todos os logs, tentanto tirar partido da compresão e da durabilidade inerentes, surgem alguns problemas, nomeadamente:

  • A compressão/descompressão de dados, associada à inexistência de índices torna as consultas com critérios complexos muito mais demoradas do que em MyISAM.
  • O recurso a partições para acelerar as consultas (que são sempre limitadas a um determinado intervalo de tempo, e por isso prestam-se a partition pruning) é uma boa ideia, mas há limites

A solução
A conjugação dos requisitos anteriores aponta quase directamente para uma solução heterogénea que combine o melhor de dois mundos: a rapidez de acesso e a flexibilidade do storage engine MyISAM, com a durabilidade e compressão do Archive.
A solução final tem os seguintes componentes:

  • Uma base de dados em que os logs são guardados em tabelas MyISAM. As tabelas são particionadas por intervalo, usando a data do evento como chave de particionamento. Cada partição irá conter um dia dados, ou seja uma média de 300.000 registos. As tabelas são criadas vazias com duas partições, uma para o dia actual e outra para o dia seguinte.
  • Uma base de dados em que os logs são guardados em tabelas Archive, sem recurso a partições, porque são conhecidos vários problemas com essa combinação, e já tive oportunidade de experimentar alguns deles. As tabelas são criadas vazias.
  • Um script executado diariamente que verifica a existência de dados na base de dados MyISAM com mais de 60 dias e, caso existam, os copia para a base de dados Archive, eliminando de seguida a partição correspondente (e os dados nela contidos) da base de dados MyISAM.

Desta forma mantém-se sempre 2 meses de logs que são muito rápidos de consultar, graças ao uso de partições e do storage engine MyISAM é fácil e rápido fazer backup, e assegura-se o armazenamento a longo prazo com taxas de ocupação adequadas.

Share

Database Disaster Resilience (3/3)

Maio 27, 2007 on 10:58 pm | In database, linux, MySQL, networking, open-source, storage | No Comments

(Continuação deste outro post)

Para encerrar este tema, a solução final passou por replicar duas partições de alguns GBs usando DRBD 0.7, e montar o /var/lib/mysql lá em cima.

Como storage engine ficou o InnoDB, mas com tablespaces individuais por cada tabela, para ser mais fácil gerir o espaço em disco (e também dá jeito para backup/restore binário).

Ainda não simulei desastres com o sistema em carga, mas conto fazê-los em breve, se houver novidades dignas de registo, avisarei.

Só mais uma nota, durante o setup foi necessário sincronizar a partição entre duas localizações remotas e fiquei agradavelmente surpreendido com o desempenho de rede do DRBD.

PS: A história das maçãs serve apenas para facilitar a escrita e evitar mencionar o objectivo real da aplicação que está em cima desta infra-estrutura. Como é ortogonal em relação aos temas discutidos, julgo que ninguém sai lesado.

Share

TSM Live CD

Maio 14, 2007 on 10:53 pm | In ibm, linux, MySQL, storage, tivoli | No Comments

No mundo empresarial de data protection, é mais ou menos assumido que há poucos rivais para o Tivoli Storage Manager (TSM) da IBM. É um produto maduro, com muitos anos de existência e conceitos pouco intuitivos mas extremamente eficazes (ao contrário da maior parte do software de backup, é data-oriented e não media-oriented, o que significa que gere a informação e não os mídias onde a informação é guardada). Para além disso é verdadeiramente multi-plataforma (Windows, Linux, AIX, z/OS, i5/OS, etc.).

Recentemente estive envolvido na realização de backups para Disaster Recovery (DR) recorrendo precisamente ao TSM. A mim couberam-me os servidores Linux. Para garantir backups completos com o filesystem em estado consistente, é importante que o sistema operativo que lança o cliente de backup não toque no disco, o que equivale a dizer que é preciso um live-cd com Linux.

Ainda tentei usar o bootcd do Debian para tentar gerar um Live CD de um sistema que já tinha o cliente de backup instalado, mas ficaram muitas arestas por limar. Finalmente decidi dar uma hipótese ao Ubuntu, e seguir este tutorial para criar um Dapper Drake à minha maneira. Correu às mil maravilhas. Bastou-me copiar as directorias do cliente de backup para o /opt, dar-lhe uma ajudinha a encontrar as bibliotecas com o ldconfig e ficou a funcionar.

No final, o procedimento para fazer backups/restores de DR ficou com o seguinte aspecto:

Backup

  1. arrancar com live cd
  2. abrir terminal
  3. setxkbmap pt
  4. sudo su -
  5. sfdisk para gerar dump das partições (ex. sfdisk -d /dev/sda > partition-dump.txt)
  6. criar mount points (ex. mkdir /mnt/sda1)
  7. mount nos sitios certos (ex. mount -t ext3 /dev/sda1 /mnt/sda1)
  8. encher de zeros os blocos vazios do filesystem para melhor compressão (ex: dd if=/dev/zero of=/mnt/sda1/dummy; rm -f /mnt/sda1/dummy)
  9. mudar node name para o valor correcto e acrescentar “compression yes” ao ficheiro /opt/tivoli/client/ba/bin/dsm.sys
  10. fazer o backup dos vários discos (ex: /opt/tivoli/tsm/client/ba/bin/dsmc image backup /mnt/sda1 -imagetype=static)

Restore

  1. arrancar com live cd
  2. abrir terminal
  3. setxkbmap pt
  4. sudo su -
  5. sfdisk para criar as partições (ex. sfdisk /dev/sda
  6. mkfs.* para criar filesystems (ex. mkfs.ext3 /dev/sda1)
  7. mkswap para criar swap (ex. mkswap /dev/sda2)
  8. criar mount points (ex. mkdir /mnt/sda1)
  9. mount nos sitios certos (ex. mount -t ext3 /dev/sda1 /mnt/sda1)
  10. mudar node name no ficheiro /opt/tivoli/client/ba/bin/dsm.sys
  11. fazer o restore dos vários discos (ex. /opt/tivoli/tsm/client/ba/bin/dsmc image restore /mnt/sda1 /mnt/disco1)
Share

Database Disaster Resilience (2/3)

Abril 15, 2007 on 11:40 pm | In database, ibm, linux, MySQL, networking, open-source, storage | 1 Comment

(Continuação deste outro post)

O problema da dispersão geográfica pode ser resolvido em várias camadas.

  1. Pode ser a própria aplicação a assumir a necessidade de manter toda a informação em bases de dados distintas.
  2. Pode ser o servidor de base de dados a manter repositórios distintos para a mesma base de dados.
  3. 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.

Share

dnotify

Março 13, 2007 on 11:25 pm | In linux, storage | No Comments

Durante a última semana o Nelson Rodrigues esteve a instalar uma máquina antiga com Debian para construir um file server que servisse como repositório de software. A ideia era deixarmos de andar sempre todos atrás dos CDs que temos espalhados por todos os cantos, e que neste momento devem ser já uns milhares largos. Para além disso, serviria também para guardar ISOs de alguns CDs (tipo W2k3, Linuxes vários, etc.) para poderem ser usadas por NFS no cluster de vmwares.Acabamos por decidir ter uma estrutura fixa e proibir as escritas a toda a gente, reservando uma share para onde toda a gente pode fazer uploads (senão ía ser complicado reunir todo o software). E rapidamente surgiu a pergunta: “e como é que vamos saber que alguém meteu um ficheiro na share de uploads e que é preciso ir lá metê-lo no sítio certo?”A resposta óbvia é que queremos ser notificados cada vez que alguém colocar alguma coisa naquela share. E uma pesquisa bem feita no google revelou a solução: dnotify. É um programita muito catita e muito simples de usar que executa um comando por cada alteração feita a uma determinada directoria (ou árvore de). O dnotify interage directamente com o kernel, não precisando do FAM para nada.Provavelmente também se podia ter usado o inotify (que toda a gente diz que é mil vezes melhor), mas a verdade é que o dnotify estava ali mesmo à mão, não tem nenhum problema no ambiente em que é usado e funciona! :)A solução final ficou com o seguinte aspecto.1. A seguinte linha é incluída num init script, imediatamente a seguir ao volume em causa estar disponíveldnotify -b -q 0 --create /opt/root/Uploads -e /etc/upload_notification.sh2. O ficheiro /etc/upload_notification.sh tem o seguinte conteúdo:#!/bin/sh/usr/sbin/sendmail -F"Software Server" -t < /etc/upload_notification.txtComo resultado, o dnotify envia uma notificação quando é criado algum ficheiro ou directoria na share em causa, mas nunca envia mais do que uma notificação a cada 10 minutos (normalmente seria uma por cada ficheiro).Claro que para ser mesmo bem feito fazia o sleep primeiro e acrescentava à notificação a listagem do conteúdo da share no momento… mas deu-me a preguiça :)

Share
Página seguinte »

© procself. Este blog está alojado no FEUP Blogs. Crie também o seu blog.
Subscreva os Artigos (RSS) e os Comentários (RSS) do procself.