Economizando recursos com IBM Tivoli Storage Manager Progressive Backups

Opções de documento Opções de documento que necessitam de JavaScript não são exibidas Classificar esta página Ajude-nos a melhorar este conteúdo

Nível: Intermediário

Mauricio Massa, Especialista certifidado de sistemas, IBM

19/Ago/2009

Introdução - A demanda por storage tem se intensificado com grande rapidez e, junto com ela, a demanda por proteção aos dados tem se tornado um desafio às empresas, que não podem ter seus processos de produção afetados por indisponibilidade de servidores durante janelas de backup cada vez maiores.

Desde suas primeiras versões, na década de 90, o Tivoli Storage Manager possui a tecnologia de backups incrementais progressivos. Essa tecnologia, aliada a outros recursos presentes no Tivoli Storage Manager, permite que apenas dados novos ou alterados sejam alvo de backup, substituindo a necessidade de backups full mensais por backups progressivos mensais, em que apenas os dados novos ou alterados, desde o último mês, são backupeados. Isso evita redundância excessiva de armazenamento e reduz significativamente os custos com armazenagem, indisponibilidade dos servidores, administração, tráfego de rede e demanda por novos tape drives.

Backup Progressivo

Tendo-se em mente que, de forma geral, apenas 20% do volume de um servidor de arquivos é alterado de um mês para o outro, por que se armazenar, todos os meses, 100% dos equipamentos em backup novamente?

O TSM dispõe de meios para proteger as versões dos arquivos em fitas de cópia, controlar seu envio para sites externos e retê-las por tempos determinados. Dessa forma, caso um arquivo não seja mais alterado, ele não precisará ser backupeado várias vezes seguidas. Com exceção de servidores de Correio e de Bancos de Dados, que requerem armazenamento diferenciado, a tecnologia de backups progressivos permite grande economia de recursos, e vem sendo adotada com sucesso por clientes que precisam ter janelas de backup mais eficientes.

A pureQuery oferece três maneiras distintas de acesso a dados relacionais através de aplicações orientadas a objetos:

• Tabelas a partir de Objetos: permite a criação de tabelas num banco de dados relacional a partir de objetos de uma aplicação Java;
• Objetos a partir de tabelas: a partir das tabelas de um banco de dados relacionais, o pureQuery é capaz de criar objetos e interfaces para operações de CRUD (Create, Replace, Update e Delete) em cada uma dessas tabelas;
• Objetos a partir de SQL: os objetos de uma aplicação podem ser criados a partir dessas consultas em linguagem SQL. Esses objetos são criados através de parsing de consultas e da leitura dos metadados do banco de dados acessado.

Na aplicação exemplo, objeto principal desse artigo, a última forma de mapeamento objeto-relacional será utilizada.

Funcionamento

A maioria dos ambientes requer, para fins históricos, a retenção dos arquivos através de rotinas de backup diárias e mensais (alguns ambientes tem requisição de backups semanais, que também podem ser aplicados neste conceito).

Através da tecnologia de backups progressivos, tem-se o seguinte:

• Diariamente, backup dos arquivos novos ou alterados desde o dia anterior;
• Mensalmente, backup somente dos arquivos novos ou alterados desde o mês anterior.

Estas rotinas são armazenadas em áreas distintas do TSM Server, e, em conjunto com tecnologia para particionamento dos dados e reciclagem (desfragmentação) automática dos cartuchos, não oferecem perdas em processos de restore posteriores. O controle de políticas, por objeto, do TSM Server, garante que os períodos de retenção de cada rotina sejam atendidos de forma transparente.

Comparativamente:

Apenas os dados novos ou alterados são salvos, economizando-se 3x em quantidade de cartuchos e reduzindo-se a janela mensal em 5x

Restauração mais eficiente

Em restores, o Tivoli Storage Manager não depende de inter-relacionamento com full backups, e dessa forma, restaura os arquivos diretamente (por possuir o controle por objeto, e não por rotina de backup), sem gasto de tempo voltando-se versões antigas dos arquivos, e que serão sobrepostas ao se aplicar incrementais.

Ao restaurar um backup da noite passada, por exemplo, o TSM irá recuperar os arquivos como eles eram na noite anterior, independentemente se foram realmente copiados no backup da noite passada ou no backup de 6 meses atrás.

Sumário

A utilização da tecnologia de backups incrementais progressivos, parte integrante do Tivoli Storage Manager (sem custos adicionais), permite economia significativa de recursos em backups, tanto para as rotinas diárias como em rotinas mensais ou semanais, possibilitando maior eficiência e disponibilidade aos ambientes de produção.

Configuração técnica

TSM Server

Como forma de tornar a metodologia de backups progressivos mais eficiente, as seguintes configurações deverão ser feitas no TSM Server, inicialmente (antes de se configurar os clientes). Estas configurações se aplicam somente a servidores de arquivos.

- Defina inicialmente as device classes sequenciais que serão utilizadas pelo TSM (LTO, 3592, por exemplo). Como estas device classes apontam para as Tape Libraries, utilize-as de acordo com a quantidade de Tape Libraries que serão utilizadas (ou mesmo para se definir Tape Libraries locais ou em sites de DR). Caso já existam as Device Classes necessárias em seu ambiente, ignore este step.

- Defina os storage pools sequenciais, com opção de Collocation by Group ativada (este já é o default para o TSM 5.3), para permitir a utilização pelos grupos de nodes Diários e Mensais, que serão definidos a seguir. Por exemplo: FSTAPE_PRIM.

- Defina os storage pools de cópia, com opção de Collocation desabilitada, para prover maior economia de cartuchos. Por exemplo: FSTAPE_COPY.

- Defina os storage pools em disco, que apontarão para os storage pools sequenciais. É importante que estes storage pools em disco tenham tamanho suficiente para reter pelo menos 20% do tamanho total dos servidores de arquivos, visto que essa é a média de variação para esse tipo de equipamento. Como a variação diária será muito menor (em torno de 5%, no máximo), tem-se espaço para pelo menos 4 execuções de backup incremental em disco, antes dos mensais. Por exemplo FSDISK_PRIM. Lembre-se de setar a opção MIGPRocess para a quantidade de drives que quiser deixar disponível para envio destes dados para fita durante a migração.

- Defina Policy Domains separados, para os nodes diários e mensais. Por exemplo: PDFS_DIARIO e PDFS_MENSAL.

- Dentro de cada Policy Domain, defina Management Classes com retenções de acordo com sua política de backup. Por exemplo, para backup diário retido por 30 dias, e backup mensal retido por 1 ano (12 execuções mensais), poderão ser definidos os seguintes Backup Copy Groups:

(*) Como normalmente um arquivo não será alterado todos os meses, esta quantidade de versões não será utilizada pela maioria dos servidores.

Por exemplo, definir as Management Classes: DIARIO e MENSAL, dentro de cada Policy Domain correspondente.

- Deixe as Management Classes recém-criadas como default, em seus respectivos Policy Domains.

- Se necessário, ative os Policy Sets dos domínios Diario e Mensal (através da interface gráfica, isso será feito automaticamente pelo TSM).

- Para cada Policy Domain, defina os nodes diários e mensais que representarão cada equipamento físico. Por exemplo, para o equipamento SCFS001, deverão ser definidos os nodes SCFS001_DIARIO e SCFS001_MENSAL, com atenção para as seguintes características:

- Defina os Collocation Groups para os separar os dados dos nodes entre si, no storage pool primário de fitas, durante os processos de migração do TSM. Por exemplo, defina os grupos COLLGR_DIARIO e COLLGR_MENSAL. Pode ser utilizada a ISC ou o comando DEFINE COLLOCGROUP do TSM Server.

- Adicione a cada grupo os nodes diários e mensais correspondentes. Pode ser utilizada a ISC ou o comando DEFINE COLLOCMEMBER do TSM Server. Por exemplo, para os nodes diários e mensais:

DEFINE COLLOCMEMBER COLLGR_DIARIO *DIARIO
DEFINE COLLOCMEMBER COLLGR_MENSAL *MENSAL

- Para cada Policy Domain, crie os Schedules correspondentes, utilizando a opção de backup incremental. Obviamente, o backup diário, onde serão associados os nodes diários, terá frequência diária, enquanto que os schedules mensais, também incrementais, possuirão frequência mensal, sendo associado aos nodes mensais.

- Lembre-se de incluir em seu Maitenance Plan um novo relacionamento de cópia diária do storage pool FSTAPE_PRIM para FSTAPE_COPY.

As configurações do TSM Server estão concluídas.

TSM Clients Windows

A instalação do TSM Client nos servidores de arquivo Windows não tem nenhuma particularidade em seu processo. Para a execução de incrementais progressivos, os seguintes passos precisam ser observados:

- Caso ainda não exista, siga os passos da interface GUI do TSM Client para criar um arquivo de opções (dsm.opt) padrão.

- Saia da GUI do TSM Client e edite o arquivo recém-criado, localizado em
C:\Program Files\Tivoli\TSM\baclient\dsm.opt
Verifique (alterando ou incluindo) os parâmetros abaixo:

httpport 1581
nodename SCFS001_DIARIO
passwordaccess generate
schedmode prompted

- Chame a GUI do TSM Client novamente e informe a senha do node Diário, se necessário.

- Ainda dentro da GUI, com o node Diario (isso pode ser validado em “File – Connection Information”), crie os serviços de Scheduler e de WEB Client para este node:

Será iniciado o Wizard para criação do processo de Scheduler:

Os processos para o node Diário estão finalizados.

- Copie o arquivo dsm.opt para dsm.opt.mensal e altere as seguintes opções no arquivo dsm.opt.mensal:

httpport          1582
nodename          SCFS001_MENSAL
passwordaccess          generate
schedmode          prompted

- Inicie a GUI do TSM Client novamente, porém para o node mensal. Para isso, utilize a seguinte sintaxe:

- Informe a senha do node Mensal.

- Ainda dentro da GUI, com o node Mensal (isso pode ser validado em “File – Connection Information”), crie os serviços de Scheduler e de WEB Client para este node.

O processo de configuração do node mensal está terminado.

Para acessar os dados deste equipamento via WEB, basta se utilizar:

http://<IP.NODE>:1581 > Node Diário
http://<IP.NODE>:1582 > Node Mensal

TSM Clients UNIX

Siga os procedimentos normais de instalação do TSM Client em UNIX.

De acordo com a versão de UNIX utilizada, o TSM Client estará sob /usr (AIX) ou sob /opt (demais UNIX).

Tomando-se como exemplo um equipamento AIX, teremos os arquivos dsm.sys e seus respectivos dsm.opt.

Edite-os da seguinte forma:

/usr/tivoli/tsm/client/ba/bin/dsm.sys:

(*) Altere de acordo com as características de seu ambiente.

Em seguida, edite os arquivos dsm.opt (node diário) e dsm.opt.mensal (node mensal)

/usr/tivoli/tsm/client/ba/bin/dsm.opt:

/usr/tivoli/tsm/client/ba/bin/dsm.opt.mensal:

Será necessário gerar as senhas dos nodes, antes de se iniciar os serviços de Scheduler e de WEB Client para cada node.

Como root (ou equivalente), execute:

Confirme o nodename diário (<ENTER>) e informe a senha do node diário.

Repita o mesmo procedimento para o node mensal:

Confirme o nodename mensal (<ENTER>) e informe a senha do node mensal.

Feito isso, basta se iniciar os processos de scheduler e de WEB Client para os nodes.

Subida dos processos do node diário (AIX):

Subida dos processos do node mensal (AIX):

O processo de configuração dos nodes diário e mensal em UNIX está terminado.

Sobre o autor

		Especialista certificado de sistemas e trabalha na IBM desde 2001, no grupo de Tivoli Software, para a área de gerenciamento de armazenamento

Avalie esta página

Reserve um instante para completar este formulário para nos ajudar a servi-lo melhor. As informações o ajudaram a alcançar seu objetivo? Sim Não Não sei   Faça comentários para ajudar a melhorar esta página:   Quão úteis são as informações? 1 2 3 4 5 Não são úteis Extremamente úteis

Voltar para parte superior