Se você tiver uma library grande, monitore-a:
Se você tem uma library grande, como uma 3494/3500, sobre a qual a organização depende, somente faz sentido implementando monitoração ativa para assegurar que está operacional e que envie alertas em tempo real quando um problema é detectado. Esperar o TSM detectar um erro pode significar descobrir muito tempo depois um problema já iniciado e recebendo indiretamente (e potencialmente obscuros) indicações que levam muito tempo para rastrear o motivo pelo qual a library está down.
Você pode colocar uma monitoração básica, algo tão simples como uma invocação periódica(loop) do comando ‘mtlib’, por exemplo.
Trate os problemas no primeiro indício que o problema existe!
Surpreendentemente, alguns clientes imediatamente implementam ações de correção arbitrárias antes de descobrir o que realmente causou o problema. Por exemplo, o técnico encontra fitas 3590 com status Unavailable e executa um audit library. Errado! Librarys 3494 mantém consistência própria e não necessitam de AUDITS. Problemas de hardware e intervenção humana (remoção de fitas da library) fazem com que as fitas fiquem com status Unavailable.
Implementar uma correção de um software baselevel durante um problema de hardware, é no mínimo desperdício de tempo, e pode até mesmo causar coisas piores.
Lembrem-se.: Os médicos não aplicam um tratamento antes do diagnóstico, e você também não deveria fazer.
Sempre considere o seu ambiente Server & Client como um todo:
Server e clients devem ser capazes de interoperar como um amálgama totalmente compatíveis. Ao considerar uma atualização do Server, o que é absolutamente essencial ter suas versões no nível mais alto, planeje também atualizar os clients que até podem funcionar. Por mais óbvio que este conselho possa parecer, ainda vemos postagens em fóruns, de administradores que atualizaram o TSMServer sem considerar os clients, e se perguntam por que alguns de seus clients não funcionam mais, e/ou o que as mensagens estranhas do Server querem dizer. Lembre-se que os fornecedores podem garantir (por seus testes), limitado a apenas algumas combinações Server e Client: faça a disparidade muito grande e os resultados serão imprevisíveis.
Use a sincronização de tempo em seus computadores!!!
Sincronizar os relógios dos computadores a um padrão de tempo é fundamental para as operações client-server. No mínimo, relógios atrasados, podem causar confusão durante o debug de um erro, e pode atrapalhar operações sensíveis como a autenticação Kerberos. Um simples comando, como o ‘dsmc q ses’ irá mostrar o horário atual do Server, para comparar com o horário do Client.
Logs:
O TSM tem a capacidade (e pode) produzir uma variedade de logs para Clients e Server. O Server possui o actlog; O Client possui a log de Schedule e a log de Erro; E os TDPs possuem logs. Além disso, o Sistema Operacional possui suas logs de mensagem. Você tem a habilidade de suprimir as logs, como a opção quiet do Client Option. Aqui você decide qual log armazenar, quanto de log será armazenado e por quanto tempo.
Mas, é você sozinho que tomará esta decisão? Seu site provavelmente tem normas que são aplicadas pelos auditores, definindo a extensão das logs e a retenção das mesmas, conforme o tempo necessário, segurança e outros requisitos. Note que o produto HSM do TSM, ou a sua função Archive, pode ajudar muito no gerenciamento de log. HSM em particular é muito útil porque permite que todos os logs estejam visíveis em um sistema de arquivo hierárquico, enquanto ao mesmo tempo, ocupa o mínimo de espaço no file system.
Validar um novo client antes de habilitar sua utilização:
Preocupantemente, muitos sites instalam um client e depois simplesmente executam full backups (pior, com um schedule) sem validação inicial que está corretamente instalado, configurado, ou totalmente utilizável. Então, quando ele não funciona como esperado, eles ficam confusos, e enviam diversas mensagens através de foruns, perguntando "O que há de errado?" Obviamente, quando se introduz um novo software, ele precisa ser instalado de acordo com instruções do fornecedor (não se esqueçam o arquivo README), então, ser configurado de acordo com o manual que corresponde a sua versão/release e depois validá-lo. Aqui estão alguns passos básicos de validação:
- Execute o comando 'dsmc q opt' para verificar que os parâmetros utilizados são válidos, e, se terá efeito, uma vez que este irá executar a primeira interação com o servidor TSM e irá procurar todas as opções do client setadas no lado do server.
- Execute o comando 'dsmc q inclexcl’ para verificar se os Include/Exclude são válidos. (Nem todos os includes/excludes são setados no client: alguns podem ser definidos no server.)
- Faça um backup teste para ver como se comporta este novo client com as opções setadas: 'dsmc selective
- Agora execute o comando 'dsmc incremental’ em um diretório, para testar esse tipo de backup.
- A maioria dos backups devem ser executadas através de um ClientSchedule, portanto, verifique esta funcionalidade através do immediate (define clientaction).
- Vá em frente para testar quaisquer outras funções que este client irá utilizar (Archive, Images, etc.)
Note que tudo isso é exercício. Qualquer novo filespaces criado durante os testes, podem ser descartados, ao final, se desejar. Se os problemas ou anomalias ocorrerem, verifique o dsmerror.log no client e o actlog no server. Execute o comando ‘query session’ no server durante e após os testes, em busca de problemas e verifique a transferência de dados em ambas as direções, pelas estatísticas relatadas. O Guia de Problem Determination do TSM está disponível para pesquisar erros, buscar dicas a respeito de erros reportados no client. Você também pode executar o client sob o comando ‘truss’ do Unix para ver o que está acontecendo, e o TSM Client rastrear sua disponibilidade.
Depois de subir a versão do client, teste:
Difícil de acreditar, mas muitos sites fazem coisas como subir a versão de seus clients e apenas aguardam a execução dos backups de produção da noite: SEM TESTES! Evitem pagar o preço de "assumir o risco": TESTE!!!.
Basicamente verifique primeiro como 'dsmc q opt' e 'dsmc q fi' deve ser feito para verificar se todas as opções estão rendendo o que se espera, e que a interação client-server básico pode ocorrer com sucesso. Então, é saudável para executar um define clientaction no server, para executar uma coisa básica como o comando 'date' um sistema operacional no cliente, para garantir que o mecanismo scheduler está funcionando. Em seguida, tentar um backup trivial.
Qualquer dúvida, sugestão, críticas ou correções, por favor escreva.
Um abraço.
