Ao investigar os erros de sessões, olhe em ambas as
pontas da sessão:
Os arquivos do ADSM-L estão cheios de publicações sobre
problemas de sessão onde o técnico local olhou para indicações sobre apenas o
client final da sessão que falhou. Obviamente, se o TSMServer cancelou a
sessão, terá registrado algumas informações sobre o motivo. (A razão para os
problemas da sessão é quase sempre encontrado no TSMServer.) Examine indicações
em ambas as pontas da sessão para obter toda a imagem. Poste perguntas sobre
erros de sessão no ADSM-L somente depois de investigar o todo, e não encontrar
a resposta.
Verifique o
anti-virus onde está rodando Jobs de backup:
Há inúmeros problemas provocados pelo anti-vírus, não
só para o TSMServer, como para qualquer outro software de backup, quando
executado, ao mesmo tempo em um servidor onde o backup está ativo. Funcionalidade
e desempenho sofrem.
Não deixe que os usuários finais ditem as escolhas tecnológicas:
Dentro de uma organização, os usuários finais tendem a
ser conhecidos por ditarem como um sistema deve ser implementado, com base em
seus conhecimentos limitados e geralmente obsoletos para tecnologia de
processamento de dados. Departamentos do usuário final são responsáveis por
transmitir as necessidades do negócio, e não definir opções tecnológicas. O
departamento de TI está, suponhamos, mais apto a opinar sobre tecnologias, e
deve determinar a melhor implementação. Por exemplo, alguns usuários finais
podem chegar a um esquema de backup para diários, semanais e mensais –
obviamente com base em como eles viram, no passado, o funcionamento de alguns
produtos de backup. Seus esquemas, provavelmente, não tem nada a ver com as
necessidades do negócio, e se for seguido seria subverter as capacidades do TSMServer
que custou caro para a empresa, que o adotou, para segurança inteligente dos
dados de negócio.
Não use todos drives para fins administrativos:
Há ocasiões em que você, como administrador do TSMServer
quer fazer um monte de coisas, como fazer o backup de stgpools, reclaim e
restore de fitas, e por isso somos tentados a usar cada drive. Não! Na maioria
dos ambientes, solicitações de clients podem vir a qualquer momento. A ocupação
de todos os drives, no mínimo causará delay nas sessões. Também pode causar que
os processos administrativos sejam preteridos ... e se você esperava liberar fitas
scratchs o suficiente com o reclamation, próximo ao horário da janela de
backup, você pode, (e muito provavelmente será) ser rudemente surpreendido mais
tarde.
Conselho para análise de um problema. Alguns pontos nesta área:
- Na lista de discussão(mailing do ADSM), vemos muitas postagens
sobre problemas de performance que começa com.: "Nós temos dois sistemas
idênticos ...". Nunca acredite que
dois sistemas são idênticos. Tal coisa é fisicamente impossível, e se acredita,
irá inibir uma análise mais produtiva de problemas de performance do sistema.
Diferenças são saudáveis, e dar a oportunidade de comparar os efeitos de
diferentes ingredientes.
- Como uma
extensão do exposto, não entre em uma análise de qualquer sistema com noções
preconcebidas de como as coisas estão acontecendo nesse sistema. Faça isso e
você vai se cegar para funcionamento do sistema real. Coloque-se em uma
mentalidade de procurar, para saber o que está acontecendo, e sua análise será
muito mais eficaz.
- "Mas,
nada foi mudado!" Bem, às vezes, isso é uma coisa ruim. Sistemas podem rodar
durante muito tempo, muito bem, apesar de terem software, firmware, ou adaptadores
com problemas latentes. Muitas vezes, há mensagens de erro em “backuground” que
aparecem, mas o cliente ignora, porque "as coisas estão funcionando".
Tudo que torna uma situação incomum, porém, para causar a falha total, como o
hardware e/ou software, de repente enfrenta condições que estão além ou
incompatível com sua programação. Ignorando os sinais de perigo é uma má idéia.
Mantenha seu sistema com boa saúde.
Não confie cegamente nos fornecedores:
Nós queremos que todos sejam confiáveis, mas em
questões envolvendo dinheiro, a confiança tem de ser mensurada. Enquanto os
fornecedores são geralmente escrupulosos, há aqueles cujas mentalidades fazem
com que habitualmente recorram a truques sujos (Microsoft é um exemplo), e
casos em que ocorrem lapsos, como quando surge um novo executivo. Em particular,
tenha a certeza de que sua área de compras/jurídico debrucem sobre todos os detalhes
contratuais.
Espere verrugas:
Não crie expectativa de que nenhum release de qualquer
software seja perfeito. Todo release de qualquer coisa tem algumas verrugas.
Por exemplo, upgrade para o TSMServer 5.2.4 para resolver alguns problemas e
obter menor incômodo do query process com texto desalinhado para processos de
Reclaim. A palavra de ordem na vida: "É sempre alguma coisa."
Baixe os docs de fornecedores enquanto estão disponíveis:
Há uma tendência natural a considerar que a documentação
online do fornecedor como sempre estar lá e de fácil acesso. A realidade é que
os fornecedores (mesmo IBM) derrubem seus servidores web horários de pico
(apenas quando você pode estar em apuros); e eles removem os docs mais antigos
para liberar espaço para os novos. Então, quando você encontrar um PDF útil, utilize
todos os meios para salvar uma cópia no seu sistema local. Isso vai tornar o
acesso rápido e seguro.
Incentive a atualização da arquitetura de dados do departamento de TI
da empresa:
Regularmente vemos postagens de administradores TSM
tentando lidar com um backup de um filesystem contendo um número enorme de
arquivos (muitos milhões), resultando em ANS1030E e outros problemas; e vemos também,
sistemas 32bits, relativamente pequenos, controlando terabytes de dados. Tais
situações são normalmente encontrados em sistemas Windows, que estão sob o
controle de grupos de trabalho que são destemidos por conceitos de
processamento de dados e consideram o sistema Windows como assim como o PC que
eles usam em casa. O resultado comum é um único filesystem ocupando discos
inteiros: este filesystem é enorme, e eventualmente 100% ocupado, com um grande
número de arquivos. O resultado é uma massa de dados pesada, problemática,
difícil de fazer backup e singularmente vulnerável a um problema de mídia ou de
corrupção lógica. Arquitetura racional para organização de dados em partições
de tamanho razoável, facilitando o gerenciamento e o backup, e eliminando o ponto
único de falha. Uma organização com um bom departamento de TI irá publicar
diretrizes sólidas para as melhores práticas na implementação de discos e
filesystems, para ajudar a evitar passivos.
Planeje tirar proveito da evolução dos drives:
Alguns sites, por vezes, utilizam-se de uma library e um
modelo de drive e nunca pensam em evoluir conforme o tempo passa, e se
aproximam de esgotamento da capacidade. Os sites deveriam planejar a migração dos
drives para as gerações posteriores de sua tecnologia, o que permite manter uma
margem de capacidade saudável dentro dos limites da library existente. Por
exemplo, uma library 3494, com drives
3590E pode aumentar em 10x ou mais em capacidade, adicionando drives 3592 – uma
evolução que não exige mais uso de espaço físico, e até economiza em energia e
remoção de calor. Librarys SCSI podem desfrutar de ganhos semelhantes aos
avanços da tecnologia LTO.
Se estiver rodando Unix, instale o comando lsof.
O comando lsof é uma ajuda inestimável para a análise
do sistema, listando arquivos, portas, sockets, e outros objetos em seu
ambiente operacional. Usando este comando, você pode determinar imediatamente
quais portas seus TSMServer e client estão usando.
Para dúvidas, críticas, sugestões ou correções, postem no blog ou mandem um email para tsmnapratica@gmail.com.
Um abraço!
