procself

Lenovo Rescue and Recovery

Já me passaram dois casos destes pelas mãos…

Aparentemente, alguns modelos dos novos Thinkpad vêm de fábrica com o software Thinkvantage Rescue and Recovery instalado e configurado para fazer backups periódicos.

Isto até podia ser uma medida interessante de protecção adicional, não fosse o facto de os backups serem guardados para um folder ao qual nem o Administrator tem acesso (takeown também não ajuda).

O que invariavelmente acontece é que, após algumas semanas de utilização do novo portátil, o utilizador dá conta que já quase que não tem espaço em disco. Surpreendido, decide seleccionar todos os folders da raíz do disco C: (ficheiros escondidos incluídos) e conclui que afinal até não está a ocupar muito espaço. Então para onde foi o espaço todo em falta e porque é que não consegue continuar a trabalhar?

O espaço em falta está todo a ser consumido por um folder

c:\RRBackups

que é onde o Thinkvantage Rescue & Recovery guarda os backups que vai fazendo. Como o administrator não tem acesso ao folder, este não é contabilizado no espaço ocupado quando se seleccionam todos os folders na raíz do disco.

Para ultrapassar o problema basta abrir o programa em causa (está lá, bem à vista, no Start Menu), desactivar o schedule que vem activo e eliminar os backups que já foram feitos.

Pode parecer um problema simples, mas o diagnóstico não é dos mais fáceis. Já houve até portáteis devolvidos à IBM por suposta avaria de hardware, que a IBM diligentemente substituiu por hardware igualmente “avariado”.

Novos portáteis Lenovo

Recebi recentemente um portátil novo: um Thinkpad R61. Se dependesse só de mim esperava que o T61 chegasse ao distribuidor, mas não se pode ter tudo…

Já vem com o Windows Vista Business instalado e decidi manter, por um lado porque é que o caminho da menor resistência, e por outro porque gosto de experimentar coisas novas, venham elas da Microsoft ou não.

Foi a primeira vez que usei Vista durante mais de 5 minutos e a impressão foi bastante boa… até abrir o Internet Explorer! Já usava IE7 há bastante tempo no Windows XP e nunca tinha visto um comportamento tão mau como este. O browser abria bem rápido, mas depois engasgava durante uns 5 segundos antes de apresentar a página inicial – quer por acaso era about:blank. A mesma história repetia-se quando tentava abrir uma tab nova. Abrir uma tab é uma acção que espero que seja instantânea, esperar 5 segundos por isso é completamente inaceitável!

Mas é nestas alturas que dá jeito não ser fundamentalista e pensar dois minutos antes de culpar o Vista e instalar outro sistema operativo. Depois de procurar um bocado descobri que, basicamente, a culpa é de uma extensão para o IE7 que a Lenovo inclui nas instalações mais recentes. O add-on é o Lenovo Password Manager, que faz parte da ThinkVantage Client Security Solution. A extensão mantém-se activa mesmo que se desactive esta opção no Client Security Center, o que obriga a desactivar o add-on no IE para resolver o problema.

De uma forma geral acabei por desactivar a maior parte do software Lenovo / Thinkvantage que vem instalado de base. Mantenho o on-screen display, o power manager e pouco mais…

SLED 10 on Lenovo T60 – s2ram

Tenho estado a fazer alguns testes com SLED 10 em portáteis Thinkpad (aliás Lenovo…) T60.
São umas belas máquinas, pesadotas mas poderosas, pelo menos para os meus padrões de exigência.

A instalação reconheceu o hardware todo sem problemas. Houve só duas coisas que não ficaram a funcionar out-of-the-box. Uma foi o suspend-to-ram, outra foi a autenticação biométrica.

Ainda não me dediquei à segunda, mas a primeira já ficou resolvida. Este modelo de Thinkpad não está na whitelist do s2ram, por isso, para evitar potenciais chatices, o instalador desactiva esta opção sem dizer nada a ninguém. Este artigo ajudou-me a configurar as opções correctas para o s2ram e neste momento já funciona sem problemas. Resumidamente, é preciso acrescentar ao seguinte ficheiro:

/etc/powersave/sleep

as seguintes opções:

SUSPEND2RAM_FORCE=”yes”
SUSPEND2RAM_ACPI_SLEEP=”3″

Curiosamente, o suspend-to-disk funcionou sem problemas logo após a instalação.

PS: compiz rocks

TSM Live CD

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)

Database Disaster Resilience (2/3)

(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.