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)

Open-source vs. IT Procurement

Uma coisa que sempre me fez confusão foi a fraca adopção de tecnologias open-source no mundo corporativo. Como é que uma coisa que não se paga para ter (sim, o TCO é outra história) pode ter uma adesão tão baixa?

Mais recentemente tenho vindo a reparar que isto acontece com particular ênfase nas empresas mais old-school, aquelas que já existem há muitos anos, são estáveis e lucrativas. Mas porquê?

Seguramente que não é a única razão, mas parece-me pelo menos um forte motivo: estas empresas têm normalmente os seus processos muito bem definidos, sendo que um desses processos é o de procurement. É normal que, ao longo dos anos, estas empresas tenham reunido um conjunto de fornecedores à sua volta em quem confiam para obter propostas de novos serviços, software ou equipamentos. Estes parceiros – como é usual chamar-lhes – são as IBM, MSFT, HP, SAP, etc.

Se uma destas empresas tiver necessidade, por hipótese, de um software de monitorização para a sua infra-estrutura de IT e seguir o seu processo usual de procurement, obterá propostas de soluções que são referência no mercado: SMS + MOM da Microsoft, Openview da HP e Tivoli Monitoring da IBM. No entanto, pode muito bem acontecer que, para o caso concreto desta empresa, um software open-source como o Nagios, complementado com outras ferramentas igualmente open-source seja um better-fit. Simplesmente, nenhum dos seus parceiros habituais vai propôr essa hipótese e por isso a empresa em causa, provavelmente, nunca vai saber que ela existe.

Como resolver isto? A resposta parece-me simples: um dos grandes fornecedores de IT (por exemplo a Sun?) passar a ser um parceiro open-source, que prefere apresentar propostas com produtos open-source que servem melhor o cliente do que os seus próprios produtos (provavelmente aproveitando para abrir o código dos seus produtos — uma vez mais vem-me à cabeça a Sun…).

Software IBM

Tivoli Identity Manager Express

Trata-se de uma versão para mercados SMB do já antiguinho Tivoli Identity Manager da IBM.

Como já estou mais do que vacinado com software IBM, resolvi RTFM antes de começar a instalação e fiquei contente. A instalação estava muito bem detalhada e indicava vários gotcha’s em que eu teria caído.

Foi por isso com alguma confiança que iniciei a instalação numa máquina virtual VMware com Win2k3.
Um dos pré-requisitos é ter 10GB livres no disco de instalação do produto e “algum espaço” na directoria temporária. Como o clone que tenho de Win2k3 só tem 4GB no disco C: (e me esqueci do amigo diskpart), resolvi montar um segundo volume com 10GB em C:\IBM e instalar o produto lá dentro.
Rapidamente me apercebi do erro. Por algum motivo estúpido o wizard de instalação remove e torna a criar a directoria C:\IBM, tendo como resultado que o mount deixa de fazer efeito e a instalação acaba por ser feita no volume que só tem 4GB. Claro que só me apercebi disto quando, ao fim de 45 minutos de instalação o wizard fica bloqueado num dos passos (nem um errozito para amostra).

A segunda tentativa já é feita num volume D:\ com os 10GB pedidos. Acontece que o “algum espaço” na directoria temporária acabam por ser mais de 2,5 GB. Como as minhas variáveis de ambiente continuavam a apontar para o volume C:, voltei a ficar sem espaço em disco. E qual foi o sintoma desta vez? O wizard falha com um erro e manda-me ver os detalhes no log de instalação. Como sou bem mandado, vou lá espreitar o log e encontro logo a resposta: “Installation sucessful”…

Tudo bem, até posso concordar que isto são tudo problemas meus que não forneci ao produto as condições ideiais de instalação, mas não me parece desculpável que o wizard de instalação não seja capaz de apanhar um erro tão simples como falta de espaço em disco e, pior, não seja capaz de construir um uninstaller enquanto a instalação não terminar. O resultado é que por cada instalação falhada tenho que optar por gastar tempo a limpar à mão todos os resíduos deixados ou, alternativamente, começar a instalação do zero numa máquina virtual nova.

Felizmente já tinha aprendido a lição. O VMware é meu amigo e deixa-me colocar os discos em undoable e voltar atrás com um simples reboot.