Conselhos para novos administradores - Parte Final

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!

Diferença entre o Occupancy e o Import/Export

Por que há diferença de quantidade de objetos entre o Q OCC e as estatísticas do processo de import/export?

O comando Q OCC somente mostra os dados que estão retidos nos respectivos stgpools (tanto o primário quanto o pool de cópia, se houver). O Q OCC mostra a quantidade de arquivos, o espaço lógico e o espaço físico ocupado, e qual stgpool estão esses objetos.

O Q OCC não mostra os objetos que não estão armazenados no stgpool. O objeto que mais se enquadra nessa situação são os diretórios. Diretórios somente ocupam espaço no DB do TSM.

O processo de import/export irá reportar todos os dados que serão gravados em fita. Isto inclui todas as definições do nodes assim como todos os arquivos (objetos) que aparecem no inventário do server que se enquadram na especificação do FILEDATA. O processo de import/export conta cada um desses objetos bem como o tamanho. Com uma grande quantidade no número de diretórios envolvidos no processo, teremos uma grande diferença no "número de arquivos" entre o Q OCC e as estatísticas do import/export.

Portanto, os dados do occupancy deveriam ser usados apenas para estimar as estatísticas do processo de import/export.

Delete Filespace

Qual a ordem de deleção de objetos que o TSM faz quando rodamos o comando DELETE FILESPACE ?

A pergunta é válida para os casos em que alguém executa esse comando e logo em seguida, percebendo o erro, faz o cancelamento do processo.

O DELETEFILESPACE irá deletar todos os arquivos de todos os filespaces existentes no node. A deleção de objetos é executada em uma ordem para minimizar os danos caso o comando seja erroneamente executado.

A ordem de deleção será a seguinte.:

1- Backups Inactives

2- Backups Actives

3- Archives

4- Space managed files

Caso tenham alguma dúvida, sugestão, correção ou críticas, por favor escreva para tsmnapratica@gmail.com.

Qual fita utilizar em um restore ?

Um das coisas que considero ruim no TSM e que a IBM poderia melhorar é.: Como identificar facilmente quais fitas vou precisar para um determinado restore?

Sabemos, por exemplo, que o Netbackup em um processo de restore, basta clicar no botão PREVIEW, que ele informa qual fita será utilizada.

E no TSM?

Se você possui um ambiente pequeno, provavelmente todas as fitas estarão no robo, então não tem do que se preocupar. Com ambientes corporativos, de grande porte, pode ser um pouco complicado, pois provavelmente a quantidade de SLOTS disponíveis no seu robo não são suficientes para armazenar todas as suas fitas.

Podemos utilizar o comando query nodedata . Ele trará todas as fitas associadas a um determinado node, facilitando assim, a identificação das fitas.

E se tivermos um node com muitos filespaces e precisarmos fazer o restore de somente um deles? Abaixo tem um select que irá ajudar a indentificar essas fitas.

select volumeusage.node_name, volumeusage.filespace_name, volumeusage.volume_name from volumes,volumeusage where volumes.volume_name=volumeusage.volume_name and ((volumeusage.node_name='NODE_NAME') and volumes.LAST_WRITE_DATE between timestamp('AAAA-MM-DD HH:MM:SS.000000') and timestamp('AAAA-MM-DD HH:MM:SS.000000') and (volumeusage.filespace_name in ('FILESPACE_NAME')))

Utilize o timestamp para filtrar a data, como por exemplo, mostrar todas as fitas utilizadas entre 01/12/2011 a 19/12/2011.

Qualquer dúvida, sugestão, reclamação ou correção, entre em contato pelo blog ou pelo email tsmnapratica@gmail.com

Um abraço a todos.

Conselhos para novos administradores - Parte 5

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 '. Isto irá exercer o fluxo do path entre o client e o server, através do stgpool primário definido via Management Class e o Copy Group, que vão descobrir um possível problema e se as definições necessárias ou recursos não estão no lugar no server.

- 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.

Conselhos para novos administradores - Parte 4

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!

Conselhos para novos administradores - Parte 3

Investigar os primeiros indícios de problemas:

Muitas vezes vemos em posts do ADSM-L onde um administrador fala ter percebido alguns dias antes indícios de um problema, porém não tomou nenhuma ação – e em uma última análise, o problema se tornou uma calamidade. Não ignore um indício de problema: a natureza está tentando lhe dizer algo.

Melhor ainda: Procure os problemas antes que eles martelem sua cabeça. A maioria das pessoas não olham o dsmerror.log a menos que alguma falha notória obrigue-o a fazê-lo; Esta log pode conter informações valiosas relativas a arquivos não encontrados, delay na rede, e problemas relacionados a fitas. Da mesma forma, analise os registros do Sistema Operacional para os problemas (por exemplo, AIX Error Log, Windows Event Viewer...etc).

Planeje as configurações do TSM para Recuperações, mais do que para Backups:

Muitos Administradores inexperientes, dada a tarefa de criação de TSM "no vácuo", planeja a configuração para a melhor performance de backups. Errado! O ponto crítico de todo o software de backup é a recuperação rápida de dados. Se você otimizar seu ambiente para backups, provavelmente o resultado irá causar impacto no momento de recuperação.

Por exemplo, o administrador novato não vai usar o collocation, fazendo com que todas as fitas sejam utilizadas por completo. Óbvio, ele faz isso; Mas no restore de um determinado node:filespace:diretório, o processo de recuperação terá que procurar em todas as fitas que estão compartilhadas com outros nodes, outros filespaces.

Isso não quer dizer que a velocidade de recuperação deve ser o único fator na hora de projetar seu sistema: Ir totalmente nesse sentido pode criar uma situação onde os backups terão sua janela de execução prolongadas, ou que necessite utilizar mais drives ou fitas que podem estar ou não disponíveis. Seu projeto, portanto, tem que estar compromissado para melhor otimizar o tempo de restore.

Uma boa tarde a todos!

Qualquer dúvida, crítica ou sugestão, entre em contato fazendo comentários nos posts ou enviando email para tsmnapratica@gmail.com