Pessoal, desculpem a demora em continuar com esses textos, mas tive um contratempo familiar e não consegui atualizar.
Mas vamos lá, dando sequência a alguns conselhos para novos administradores.
Busque referência e valide um hardware antes de tentar utilizá-lo no TSM:
É incrível, mas muitos analistas de sistemas instalam novas librarys ou drives em seus sistemas operacionais e logo em seguida tentam usá-lo no TSM. Então eles simplesmente escrevem para ADSM-L dizendo que "não funciona", com o comando ‘lsdev’ no AIX para mostrar os devices com status Defined em vez de Available.
Você precisa validar totalmente, e depois buscar referências de novos hardwares antes colocá-lo em produção, sob qualquer aplicação. Validação significa testá-lo totalmente no nível do sistema operacional para assegurar sua funcionalidade por completo. Por exemplo, a nova library pode pegar uma fita do CAP(chamado também de I/O Station ou Bulk), reconhecer o seu código de barras, e armazená-la em um slot? Via comando ‘mtlib’ ou similar, a library vai responder para montar a fita designada? Eu consigo gravar na fita o volume de dados que eu espero que ela tenha capacidade, via comando ‘tapeutil’ ou outro comando?
Benchmarking é importante: Você compra um equipamento com base no que o fornecedor afirma sobre a capacidade e desempenho; Então você não deve medir a sua performance para ver se ele atende seus requisitos? Considere as ramificações de *não* fazer benchmarking, e mais tarde sendo colocado em produção e os usuários reclamando de baixa performance.
É no teste geral que você descobre coisas como throughput sendo a metade do que você esperava (talvez porque o adaptador SCSI está definido para a velocidade errada), a library tendo problema de leitura no barcode, devido a labels baratos que você comprou, a operação da unidade de fita com problemas devido a um microcódigo errado, etc.
Nunca assuma as configurações defaults:
A boa administração *nunca* permite os defaults, em parte porque não informa a possibilidade de alteração nos arquivos de configuração, e em parte porque você ficará à mercê do fornecedor devido a uma mudança arbitrária.Evitar misturar dados de curta e longa retenção na mesma fita:
Este é outro problema no desenho de configuração do seu ambiente. Você pode ter múltiplos filespaces que se misturam nos mesmos volumes(fitas). Se os respectivos arquivos têm retenções muito diferentes, os volumes vão acabar prematuramente com um monte de "buracos" onde os dados de curta retenção expiraram, o que eleva a quantidade de processos de reclamation que você terá de executar - o que é mecanicamente ruim para as unidades de fita, e pode interferir com outros schedules.
Não fique na versão+release baselevel quando houver atualizações disponível:
Notavelmente, no ADSM-L encontramos muitos clientes instalando a versão+release baselevel (por exemplo, 5.5.0.0) e nunca mais faz a atualização - e em seguida, escrevem de problemas que estão tendo. Tenham em mente que o baselevel é apena: Um ponto de partida. As versões de manutenção, em seguida, começam a aparecer, fixando vários problemas e fazendo ajustes necessários. Se você não aplicou as versões mais recentes de manutenção, você está em uma posição onde não poderá resolver problemas já conhecidos e resolvidos. E não tome uma postura axiomático que você não pode atualizar um TSMServer sem atualizar todos os outros clients e agents em seu ambiente, ao mesmo tempo: Os componentes de TSM possibilitam muitas vezes que uma versão mais atual do Server, pode trabalhar normalmente com uma versão mais antiga do client.(Os manuais costumam especificar todas as versões suportadas pela IBM). Conselho geral: Nunca implemente um ambiente apenas na versão baselevel do software. Espere um pouco para que uma nova versão tenha um código amadurecido antes de adotá-lo.
Caso tenham alguma dúvida, sugestão, reclamação ou correção, poste um comentário ou escreva para tsmnapratica@gmail.com
Um abraço!
