Café & Info - Aliando teoria à prática

Instalando o Oracle 11g no Linux for Oracle 6.4 - parte final

2013-06-06T02:30:00.001-03:00

Boa noite caros leitores,

Hoje estarei finalizando a implementação do Oracle 11g no Linux for Oracle 6.

No post anterior demonstrei como proceder com a instalação do Sistema Operacional, neste post executarei todas as etapas para a conclusão do RDBMS Oracle.

PRÉ-REQUISITOS

Antes de proceder com a instalação do Oracle 11g alguns pré-requisitos deverão ser atendidos. A Oracle preparou um pacote de pré-instalação que realiza a maioria dos procedimentos necessários. Para instalar esse pacote, devemos proceder com as seguintes etapas:

Execute os seguintes comandos:

Os pacotes a seguir serão instalados:

Serão incluídos parâmetros necessários para o Oracle nos seguintes arquivos:

/etc/sysctl.conf
/etc/security/limits.conf

Após a instalação dos pré-requisitos, desabilite o SELINUX, para isso execute:

Modifique o parâmetro:

Para:

Adicione o nome do servidor no arquivo /etc/hosts, conforme abaixo:

Na execução do pacote de pré-instalação do Oracle, são criados os grupos oinstall e dba, mas é necessário a criação de mais alguns grupos e a adição do usuário oracle em alguns deles, para isso execute os seguintes comandos:

Crie os seguintes diretórios/subdiretórios e dê a permissão apropriada:

Para finalizar os pré-requisitos inclua as variáveis do ambiente no perfil do usuário oracle, para isso execute:

E inclua o seguinte conteúdo no final do arquivo:

##### Variaveis Oracle #####

TMP=/tmp; export TMP

TMPDIR=$TMP; export TMPDIR

ORACLE_HOSTNAME=vm-oracle11g; export ORACLE_HOSTNAME

ORACLE_UNQNAME=BDPRD; export ORACLE_UNQNAME

ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE

ORACLE_HOME=$ORACLE_BASE/product/11.2.0/db_1; export ORACLE_HOME

ORACLE_SID=BDPRD; export ORACLE_SID

PATH=/usr/sbin:$PATH; export PATH

PATH=$ORACLE_HOME/bin:$PATH; export PATH

LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib; export LD_LIBRARY_PATH

CLASSPATH=$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib; export CLASSPATH

Reinicie o servidor:

Após o servidor reiniciar, efetue o login com o usuário oracle.

Realize o downloads dos pacotes de instalação do Oracle aqui:

Descompacte os arquivos do Oracle:

Entre no diretório recém descompactado e execute o script de instalação:

Após isso, irá iniciar o guia de instalação do Oracle 11g. Coloque seu e-mail e seu password da Oracle e clique em next:

Configure seu web proxy ou marque a opção abaixo e clique em continue:

Escolha a seguinte opção e clique em next:

Escolha o(s) idioma(s) que será(ão) instalado(s) e clique em next:

Escolha a opção do RDBMS que atenderá as suas necessidades. Para missões críticas (real time, alta disponibilidade, etc ...) utilize a versão Enterprise. Após a escolha clique em next:

Especifique os diretórios que serão instalados o RDBMS Oracle. Como anteriormente foi configurado as variáveis do ambiente para o usuário oracle, estes campos estarão automaticamente preenchidos. Clique em next:

Especifique o diretório e o grupo de inventário. Como anteriormente foi configurado as variáveis do ambiente para o usuário oracle, estes campos estarão automaticamente preenchidos. Clique em next:

Escolha o tipo de database que será criado e clique em next:

Especifique os nomes que serão utilizados na Instância e no banco de dados. Como anteriormente foi configurado as variáveis do ambiente para o usuário oracle, estes campos estarão automaticamente preenchidos. Clique em next:

Na aba memory, especifique o tamanho da memória alocada para o SGA (System Global Area):

Na aba samples schemas, marque a opção abaixo e clique em next:

Escolha a forma de gerenciamento do RDBMS Oracle (grid ou local) e clique em next:

Escolha o diretório que armazenará o banco de dados. Para obter um melhor desempenho, é recomendado a alocação deste diretório em um disco diferente do qual será instalado o software do Oracle. Após a inclusão do diretório, clique em next:

Você pode automatizar o backup do banco de dados no momento da instalação. Como não faz parte do escopo deste post a implementação de backup, não estarei habilitando o backup nesta etapa. Marque a seguinte opção e clique em next:

Escolha as senhas que serão utilizadas e clique em next. Pode-se optar por definir senhas distintas para cada conta ou a mesma senha para todas as contas.

Defina os privilégios que serão dados aos grupos de administração e operação e clique em next:

A próxima tela será a conferência dos pré-requisitos necessários para a instalação. Note que alguns pacotes que foram previamente instalados no pacote de pré-instalação aparecem na lista de não conformidades. Este fato se dá, pelas versões dos pacotes que foram instalados (mais novas) divergirem das versões que constam na verificação (mais antigas).

Somente três pacotes não foram instalados no pacote de pré-instalação. Os pacotes que faltam estão contidos no CD de instalação do Linux for Oracle.

Para instalar os pacotes necessários, execute os seguintes comandos:

Marque ignore all e clique em next:

Clique em finish para instalar o Oracle:

Após a conclusão da instalação, haverá a tela com o assistente de configuração do banco de dados. Se não for realizar nenhuma alteração nas contas previamente criadas, clique em OK:

Para finalizar a instalação e tornar o Oracle operacional, dois scripts deverão ser executados:

Para isso, execute os seguintes comandos:

Clique em close:

O RDBMS Oracle já está em produção:

O Oracle por default não vem automatizado para iniciar a(s) Instância(s), o Enterprise Manager e o Listener após iniciar ou reiniciar o Sistema Operacional.

Para automatizar o inicio do Oracle execute os seguintes procedimentos:

Edite o arquivo oratab. O arquivo oratab é responsável por definir qual(is) instância(s) será(ão) iniciada(s) e finalizada(s) pelos scripts dbstart e dbshut.

Execute os seguintes comandos:

Edite o seguinte parâmetro:

Para:

Crie o script de inicialização do Oracle. Para isso execute os seguintes comandos:

Coloque o seguinte conteúdo no arquivo:

#!/bin/bash

# chkconfig: 35 99 10

# description: startup/shutdown listener, oracle database and enterprise manager

ORA_HOME=/u01/app/oracle/product/11.2.0/db_1

ORA_OWNER=oracle

start(){

echo "Starting..."

su - $ORA_OWNER -c "$ORA_HOME/bin/dbstart $ORA_HOME"

su - $ORA_OWNER -c "$ORA_HOME/bin/emctl start dbconsole"

touch /var/lock/subsys/dbora

}

stop(){

echo "Stopping..."

su - $ORA_OWNER -c "$ORA_HOME/bin/emctl stop dbconsole"

su - $ORA_OWNER -c "$ORA_HOME/bin/dbshut $ORA_HOME"

rm -f /var/lock/subsys/dbora }

restart(){

stop

start

}

usage(){

echo "usage: $0 {start|stop|restart}"

}

if [ `id -u` -ne 0 ]

then

echo "Este script deve ser executado como root"

exit

case $1 in

'start') start;;

'stop') stop;;

'restart') restart;;

*) usage;;

esac

Salve e feche o arquivo.

Dê permissão de execução ao arquivo e adicione o mesmo no chkconfig:

Pronto, após todas as etapas o Oracle está instalado, funcional e automatizado.

Bem senhores(as) por hoje é isto, espero que aproveitem e em breve estarei falando sobre backup com o RMAN integrado com o Tivoli Storage Manager.

Um grande abraço e até mais.

Instalando o Oracle 11g no Linux for Oracle 6.4 - parte 01

2013-05-01T14:28:00.000-03:00

Boa tarde, caros leitores.

Hoje estarei iniciando uma série de posts que irão demostrar todas as etapas para a instalação e configuração do Linux for Oracle 6.4 e do Oracle 11g.

Todos os procedimentos que serão descritos são baseados em uma instalação padrão e como tal, não é recomendado adotar os padrões (hardware e software) aqui demonstrados. Esta série, tem por finalidade nortear a implementação do Oracle 11g no S.O Linux for Oracle e antes de implantar um RDBMS Oracle de produção deverão ser observadas as melhores práticas recomendadas no Optimal Flexible Architecture (OFA) contidas no Oracle Database - Installation Guide 11g Release 2 for Linux.

Para efeito de laboratório será utilizado a seguinte configuração para o servidor:

Dois processadores dual core:

2 GB RAM;
1 HD 40 GB (Sistema Operacional);
1 HD 30 (Oracle Home);

Neste primeiro post irei demonstrar os procedimentos para a instalação do S.O Linux for Oracle versão 6.4.

1 – Faça o download do S.O

Para isso faça o download do S.O aqui. É necessário realizar um registro para efetuar o download:

Efetue o login;

Leia e aceite os termos e restrições e clique em continue:

Escolha a plataforma e a versão (6.4) e clique continue:

Para a instalação padrão é necessário realizar o download do seguinte pacote:

Após a finalização do download, inicie o servidor com a imagem do S.O (.iso) e realize as seguintes etapas.

Clique em install e tecle ENTER:

Pule os testes de mídia:

Clique em Next:

Escolha a linguagem utilizada na instalação e clique em Next:

Escolha o layout do teclado e clique em Next:

Se a sua instalação será em discos locais e não em uma rede SAN, escolha a primeira opção e clique em Next:

Como se trata de uma instalação “limpa” escolha em descartar qualquer arquivo que possa conter no disco:

Defina o nome do servidor:

Clique em Configure Network e habilite a interface para iniciar automaticamente:

Clique em Edit e depois marque Connect automatically e clique em Apply:

Feche e clique em Next:

Selecione o fuso horário e clique em Next:

Defina a senha do usuário root:

Na etapa de particionamento do disco e instalação, você pode escolher “Use All Space” e todo o disco selecionado será automaticamente particionado e utilizado com as configurações defaults, o problema desta opção e que todo o File System será montado em /, contrariando as boas práticas estabelecidas no Guia de Referência – Certificação Linux LPI (Pritchard, Pessanha, Langfeldt, Stanger e Dean). Por esse motivo escolherei a opção de criar um layout personalizado e clique em Next:

Não entrarei em detalhes neste post sobre melhores práticas de File System, para esse servidor e com as configurações de discos anteriormente apresentadas, o layout definido ficou assim:

Clique em Next e depois Format:

Confirme as mudanças que serão realizadas nos discos:

Instale o boot loader e clique em Next:

Para uma instalação com ambiente gráfico instalado selecione Desktop e clique em Next e inicie a instalação:

Reinicie o servidor:

Após reiniciar o servidor execute as seguintes etapas para finalizar a instalação:

Clique em Forward:

Aceite o termo de licenciamento e clique em Forward:

Se você possui uma licença válida, clique em Yes e registre seu servidor e atualize. No meu caso não irei registar a minha instalação por se tratar de um servidor de testes. Escolha e clique em Forward:

Crie o usuário Oracle e defina uma senha e clique em Forward:

Defina a data e hora e clique em Forward:

Nessa próxima tela você pode ativar ou não o Kdump. O Kdump é um mecanismo de despejo do travamento do kernel. Caso aconteça um travamento do sistema, o Kdump captura informações do seu sistema que podem ajudar a determinar a causa da indisponibilidade.

Se você selecionar esta opção, você precisará reservar memória para o Kdump e que esta memória não estará disponível para ser utilizada.

Por se tratar de um ambiente de testes e com limitação de memória eu não irei habilitar, mas recomendo fortemente a sua utilização em um servidor de produção. Faça a sua escolha e clique em Forward:

Após a conclusão de todas essas etapas, seu servidor estará pronto para instalar o RDBMS Oracle 11g:

Bem senhores(as) por hoje é isto. No próximo post estaremos instalando o Oracle 11g neste servidor.

Espero que aproveitem, até a próxima e um grande abraço.

Executando as primeiras etapas no servidor Tivoli Storage Manager no S.O Windows - parte final

2013-04-09T02:57:00.000-03:00

Boa noite, caros leitores.

Primeiramente, peço desculpas pela semana passada que não houve nenhum conteúdo novo. Eu estava bastante ocupado em um projeto no meu trabalho e o tempo disponível foi escasso.

Neste post, estarei completando com as primeiras etapas a serem realizadas no servidor TSM de forma manual, sem o auxílio do Assistente de Configuração, que foi demonstrado no post anterior.

Criando o ID do Usuário e os Diretórios para a Instância do Servidor

O primeiro passo consiste em criar o usuário que será o proprietário da(s) instância(s) do servidor TSM. Esse procedimento deverá ser adotado nos dois métodos (com ou sem o Assistente de Configuração).

Crie o usuário;

Adicione o novo usuário aos grupos Administrators, DB2ADMNS e DB2USERS;

Faça o login com o novo usuário criado;

Após a criação do usuário proprietário da(s) instância(s), é hora de criar os diretórios que serão utilizados. É extremamente importante verificar que o usuário previamente criado tenha permissão de leitura/gravação em todos os diretórios pertinentes ao servidor TSM.

Esse procedimento também deverá ser seguido nos dois métodos (com ou sem o Assistente de Configuração).

Crie diretórios vazios para cada um dos itens mostrados a seguir.

Como boa prática o banco de dados (DB2), o archive log e o active log devem residir em diferentes volumes físicos.

Para o laboratório eu configurei meu servidor com as seguintes unidades de disco:

Antes de prosseguir com a configuração manual, os seguintes pré-requisitos deverão ser atendidos:

1. Ative o Compartilhamento para Contas de Convidados ou de Todos.

2. Desative o compartilhamento da senha protegida:

Clique em Iniciar > Painel de Controle > Central de Rede e Compartilhamento > Compartilhamento e Descoberta.
Clique em Desativar compartilhamento protegido por senha.
Clique em Aplicar e saia.

3. Desative o Controle de Conta do Usuário:

4. Assegure-se de que o Registro Remoto nos Serviços do Windows seja iniciado e que as portas 445, 137 e 139 estejam desbloqueadas no firewall.

5. Clique em Painel de Controle > Ferramentas Administrativas > Política de Segurança Local > Configurações de Segurança > Políticas Locais > Opções de Segurança. Clique duas vezes na seção Contas: Status da Conta do Administrador. Selecione Ativar e clique em OK.

6. Clique em Painel de Controle > Ferramentas Administrativas > Política de Segurança Local > Configurações de Segurança > Políticas Locais > Opção de Segurança. Clique duas vezes na seção Controle de Conta do Usuário: Execute todos os administradores no Modo de Aprovação do Administrador. Selecione Desativar e clique em OK.

Após esses procedimentos, reinicie o servidor para que as novas políticas de segurança entrem em vigor.

Preparando o Gerenciador de Banco de Dados para Backup

Para fazer backup do banco de dados para o Tivoli Storage Manager, você deve ativar o gerenciador e configurar a interface de programação de aplicativos (API).

Este procedimento só se faz necessário se você não utilizar o assistente de configuração para criar uma instância do servidor.

Execute as seguintes etapas antes de emitir os comandos BACKUP DB ou RESTORE DB.

Todas as etapas a seguir utilizam os diretórios que foram criados nas etapas anteriores:

Diretório da instância: c:\Tivoli\TSM\Server1

Nome da instância: tsmserver1

1 – Crie um arquivo tsmdbmgr.env no diretório c:\Tivoli\TSM\Server1 com o seguinte conteúdo:

2- Defina a configuração da variável de ambiente da API DSMI para a instância de banco de dados:

a) Execute o utilitátio db2cmd.exe, o mesmo está localizado no subdiretório db2\bin, em seu diretório de instalação do TSM; no meu caso, está em C:\Tivoli\TSM\db2\BIN:

b) Emita o seguinte comando:

3 - Crie o arquivo tsmdbmgr.opt com o seguinte conteúdo:

4- Pare e inicie a instância do banco de dados:

5 – Execute os seguintes comandos:

Configurando a Instância do Servidor Manualmente

1 – Efetue login como Administrator:

2 – Crie uma instância do TSM com o comando db2icrt. O seguinte exemplo utilizará o usuário criado anteriormente (tsm_service) e o nome da instância será Server1:

3 – Altere o caminho padrão para o banco de dados para o diretório criado para a instância:

a) Clique em Iniciar > Programas > IBM DB2 > DB2TSM1 > Ferramentas de Linha de Comandos > Processador de Linha de Comandos.

b) Digite quit:

c) No prompt de comandos, execute o seguinte comando para setar a instância na qual estará sendo alterado o caminho padrão do banco de dados:

d) Defina a unidade padrão. No exemplo desta instalação, o diretório da instância está localizado no C:\Tivoli\TSM\Server1, então neste caso emitirei o seguinte comando:

4 – Crie um arquivo de configuração para o servidor (dsmserv.opt), no diretório da instância (C:\Tivoli\TSM\Server1).

Para melhor entendimento, você pode baixar e customizar esse arquivo dsmserv.opt com todas as opções comentadas.

Formatando o Banco de Dados e o Log

Nenhuma outra atividade do servidor é permitida durante a inicialização do banco de dados ou do log de recuperação.

Após configurar as comunicações do servidor, você estará pronto para inicializar o banco de dados. Estes procedimentos deverão ser efetuados após o login do usuário da instância.

“Como uma recomendação geral, inicie com quatro ou mais caminhos de armazenamento. O gerenciador do banco de dados para o servidor TSM possui uma oportunidade melhor de exploração de E/S paralela quando usar múltiplos caminhos de armazenamento.” IBM Tivoli Storage Manager para Windows: Guia de Instalação

Nesta instalação de demonstração, estarei utilizando somente um diretório para o armazenamento do banco de dados. Não adote essa prática em um ambiente de produção.

Configurando a Página de Código do Servidor

Configure a variável de ambiente do sistema DB2CODEPAGE como 819 para cada instância do servidor. Antes de emitir o comando DSMSERV FORMAT, efetue logon no sistema como o proprietário da instância do servidor e emita este comando:

Inicializando uma Instância do Servidor

Use o utilitário DSMSERV FORMAT para inicializar uma instância do servidor. Então, execute o seguinte comando:

Criando um Serviço do Windows para a Instância do Servidor

Após a conclusão das etapas anteriores, é necessário criar um Serviço do Windows para a instância do servidor TSM.

Para isso execute o seguinte comando:

Neste exemplo, criei o serviço com o nome TSM Server1 com o usuário que iniciará o serviço “tsm_service” e a senha do usuário especificado “admin”.

Iniciando a Instância do Servidor

Para iniciar a instância que foi configurada, execute os seguintes procedimentos:

1 – Entre no diretório de instalação do servidor TSM:

2 – Execute o seguinte comando para iniciar a instância Server1:

3 – Registre um usuário administrativo para o gerenciamento do servidor TSM:

Neste exemplo foi registrado o usuário admin com o password admin.

4 – Execute o seguinte comando para dar permissão administrativa ao usuário récem criado:

Registrando o nome do servidor TSM

Para finalizar com as etapas iniciais, devemos configurar o nome do servidor TSM. Para isso, abra o administrative command line no seguinte caminho “C:\Tivoli\TSM\server\tsmdiag\dsmadmc.exe” e realize o login com o usuário administrativo criado:

Após efetuar o login no dsmadmc, execute o seguinte comando para registrar o nome do servidor TSM:

Neste exemplo, foi configurado o nome do servidor para VM-SERVERTSM-WIN.

Depois de todos esses procedimentos de configuração, as seguintes etapas foram executadas:

Criação da base de dados da instância;
Formatação da base de dados;
Criação do arquivo de configuração dsmserv.opt;
Criação do serviço da instância;
Criação de 03 storage pools (BACKUPPOOL, ARCHIVEPOOL e SPACEMGPOOL);
Nomeação do servidor TSM (Neste exemplo VM-SERVERTSM-WIN);
Criação do usuário administrativo ADMIN;
Permissão de administrador para o usuário ADMIN;
Inicio do serviço da instância do TSM.

Após todas essas etapas o servidor TSM está instalado e operacional.

Lembrando que essas são configurações iniciais e que o servidor TSM pode e deve ser modificado, a fim de atender a necessidade do ambiente ao qual ele será implementado.

Conforme demonstrei no post anterior, utilize como boa prática colocar um atalho no desktop do dsmadmc.

Outra dica importante é criar um atalho do dsmadmc com a chave -consolemode no desktop. Assim, tudo o que ocorre no servidor TSM irá aparecer na tela do console, seja logs, comandos executados, processos administrativos etc....

Para criar o atalho do dsmadmc em modo de console, crie um atalho no desktop: clique com o botão direito do mouse em cima no ícone do dsmadmc; clique em propriedades; no caminho (target) após C:\Tivoli\TSM\server\tsmdiag\dsmadmc.exe, coloque a chave -consolemode. Abaixo segue um exemplo com o caminho já incluído o usuário e o password:

C:\Tivoli\TSM\server\tsmdiag\dsmadmc.exe -id=admin -password=**** -consolemode

Bem, senhores(as). Demonstrei como executar as primeiras etapas no servidor TSM pelos dois métodos possíveis: tanto pelo Assistente de Configuração, quanto pela execução de todos os procedimentos de forma manual.

Os próximos posts sobre Tivoli Storage Manager serão sobre os procedimentos de instalação no Sistema Operacional Linux.

Espero que aproveitem, até mais e um grande abraço.

Executando as primeiras etapas no servidor Tivoli Storage Manager no S.O Windows - parte 01

2013-03-31T00:08:00.000-03:00

Boa noite, caros leitores,

Neste post, estarei finalizando todas as etapas para o planejamento, instalação e implementação do servidor Tivoli Storage Manager.

Nos artigos anteriores, descrevi as etapas do planejamento para a instalação e a instalação propriamente dita; então hoje, irei completar com os primeiros procedimentos para tornar o servidor operacional após sua instalação.

Criando o ID do Usuário e os Diretórios para a Instância do Servidor

O primeiro passo consiste em criar o usuário que será o proprietário da(s) instância(s) do servidor TSM. Lembrando que um único usuário poderá ser proprietário de mais de uma instância do servidor TSM.

Este usuário será responsável por iniciar o servidor TSM como serviço no Windows; por isso, o mesmo deve ter os privilégios necessários (localmente ou no domínio, se for o caso).

Algumas regras devem ser obedecidas na criação do usuário, são elas:

Somente letras em minúsculas (a-z), números (0-9) e o caractere sublinhado podem ser usados.
Deve ter 30 caracteres ou menos e não pode iniciar com ibm, sql, sys ou um numeral.
O ID do usuário e o nome do grupo não podem ser user, admin, guest, public, local ou qualquer palavra reservada de SQL.

Crie o usuário;

Adicione o novo usuário aos grupos Administrators, DB2ADMNS e DB2USERS;

Faça o login com o novo usuário criado;

Após a criação do usuário proprietário da(s) instância(s), está na hora de criar os diretórios que serão utilizados. É extremamente importante verificar que o usuário, previamente criado, tenha permissão de leitura/gravação em todos os diretórios pertinentes ao servidor TSM.

Crie diretórios vazios para cada um dos itens mostrados a seguir. Como boa prática, o banco de dados (DB2), o archive log e o active log devem residir em diferentes volumes físicos.

Para o laboratório eu configurei meu servidor com as seguintes unidades de disco:

Crie os diretórios:

"Quando o banco de dados do servidor for inicialmente formatado, use vários caminhos de armazenamento (diversos diretórios). Como uma recomendação geral, inicie com quatro ou mais caminhos de armazenamento. O gerenciador do banco de dados para o servidor Tivoli Storage Manager possui uma oportunidade melhor de exploração de E/S paralela quando usar múltiplos caminhos de armazenamento." - IBM Tivoli Storage Manager para Windows: Guia de Instalação

Conforme explicado anteriormente, essa instalação é em ambiente de laboratório. Por esse motivo, estarei utilizando somente um único diretório para o banco de dados. Mas, lembre-se de que esse exemplo não deve ser seguido em um ambiente de produção.

Antes de prosseguir com o Assistente de Configuração ou com a configuração manual, os seguintes pré-requisitos deverão ser atendidos:

1. Ative o Compartilhamento de arquivo e de impressão.

2. Desative o compartilhamento protegido por senha:

Clique em Iniciar > Painel de Controle > Central de Rede e Compartilhamento > Compartilhamento e Descoberta.
Clique em Desativar compartilhamento protegido por senha.
Clique em Aplicar e saia.

3. Desative o Controle de Conta do Usuário:

4. Assegure-se de que o Registro Remoto nos Serviços do Windows esteja iniciado e que as portas 445, 137 e 139 estejam desbloqueadas no firewall.

Após esses procedimentos, reinicie o servidor para que as novas políticas de segurança entrem em vigor.

Após a criação do(s) usuário(s) e dos diretórios, iniciaremos a configuração inicial do servidor TSM.

Existem duas formas para conclusão das etapas:

Pelo o assistente de configuração, ou
Executando todas as etapas manualmente.

Configurando o Tivoli Storage Manager Usando o Assistente de Configuração

Clique em Iniciar > Todos os Programas > Tivoli Storage Manager > Configuration Wizard

Após iniciar o Assistente de Configuração siga as seguintes etapas:

Selecione o idioma;

Escolha o nome da Instancia a ser configurada, preencha com o usuário e a senha que foram previamente criados;

Defina o diretório da instância do servidor TSM:

Defina o(s) diretório(s) do banco de dados (DB2):

Defina o tamanho do active log e os diretórios a serem utilizados pelo active log, archive log, active log mirror e failover archive log:

Defina o nome do servidor TSM e o idioma do servidor. Por default o nome sugerido para o servidor e o hostname:

Especifique um usuário adminstrativo para o Tivoli Storage Manager:

Configure as portas a serem utilizadas ou deixe os valores padrões:

Será exibido um resumo das configurações:

E após todas as etapas a conclusão das configurações:

Através do guia de configuração as seguintes etapas foram executadas:

Criação da base de dados da instância;
Formatação da base de dados;
Criação do arquivo de configuração dsmserv.opt;
Criação do serviço da instância;
Criação de 03 storage pools (BACKUPPOOL, ARCHIVEPOOL e SPACEMGPOOL);
Nomeação do servidor TSM (Neste exemplo VM-SERVERTSM-WIN);
Criação do usuário administrativo ADMIN;
Permissão de administrador para o usuário ADMIN;
Inicio do serviço da instância do TSM.

Após todas essas etapas, o servidor TSM está instalado e operacional. Lembrando que essas são configurações iniciais e que o servidor TSM pode e deve ser modificado, a fim de atender a necessidade do ambiente ao qual ele será implementado.

Ao longo dos posts sobre o Tivoli Storage Manager, irei demonstrar a instalação do Administration Center e o gerenciamento do servidor TSM por essa ferramenta; mas, outra forma de gerenciar o servidor TSM é via linha de comando pelo dsmadmc e ele está localizado no seguinte caminho C:\Tivoli\TSM\server\tsmdiag (ou na raiz da instalação do TSM).

Utilize como boa prática colocar um atalho no desktop do dsmadmc. Outra dica importante é criar um atalho do dsmadmc com a chave -consolemode no desktop. Assim, tudo o que ocorre no servidor TSM irá aparecer na tela do console, seja logs, comandos executados, processos administrativos etc....

Para criar o atalho do dsmadmc em modo de console, crie um atalho no desktop: clique com o botão direito do mouse em cima no ícone do dsmadmc; clique em propriedades; no caminho (target), após C:\Tivoli\TSM\server\tsmdiag\dsmadmc.exe, coloque a chave -consolemode.

Abaixo segue um exemplo com o caminho já incluído, o usuário e o password:

C:\Tivoli\TSM\server\tsmdiag\dsmadmc.exe -id=admin -password=**** -consolemode

Bem senhores(as), como eu disse, após todos esses procedimentos o servidor Tivoli Storage Manager está instalado e operacional.

Na próxima parte, estarei realizando toda a configuração manualmente e não pelo Assistente de Configuração.

Até mais e um grande abraço.

Instalação do Tivoli Storage Manager no Windows Server 2008

2013-03-30T02:02:00.000-03:00

Boa noite, caros leitores.

Retomando a série sobre o planejamento, instalação e gerenciamento do Tivoli Storage Manager, hoje estarei dando continuidade com a instalação do servidor TSM no S.O Windows.

Nos posts anteriores, eu descrevi o planejamento da instalação do TSM e abordei os requisitos mínimos que devem ser utilizados em um ambiente de produção do TSM.

Hoje demonstrarei a instalação no servidor TSM no S.O Windows 2008 R2 Enterprise.

Todo o trabalho de instalação que será descrito foi realizado em ambiente de laboratório e, infelizmente, não possuo alguns dos requisitos mínimos (memória suficiente, tape library, etc...).

Isso, no entanto, não me impede de demonstrar a instalação e o funcionamento do servidor TSM, mas saliento que jamais deverão ser usados os padrões de hardware e software aquém dos descritos na fase de planejamento em um ambiente de produção.

Por ser tratar de um ambiente de laboratório, estarei usando as seguintes configurações:

- Windows Server 2008 R2 Enterprise

- 2 GB de memória

- 60 GB de tamanho da unidade c:\

- 55 GB de tamanho na unidade d:\ - banco de dados DB2

- 20 GB de tamanho na unidade e:\ - active log

- 52 GB de tamanho na unidade f:\ - archive log

Nesta instalação, não utilizarei o mirror active log e o failover archive log. Para utilização desses dois recursos, faz-se necessária uma avaliação do custo versus benefício para o ambiente que será implementado o Tivoli Storage Manager.

Nesta série, não realizarei o modo de instalação via console para o S.O Windows, mas somente via Assistente de Instalação.

Outro ponto importante a ser lembrando é que todos os procedimentos a seguir deverão ser executados como Administrador (Administrator).

Procedimentos para a instalação do Tivoli Storage Manager

1 – Utilizando a mídia de DVD do Tivoli Storage Manager

Insira a mídia do TSM e abra o Windows Explorer;
Acesse a unidade de DVD;
Dê um duplo clique em install.exe.

2 – Realizando o download do pacote de instalação

Escolha e baixe o pacote de instalação do servidor TSM aqui;
Verifique que o diretório que você ira extrair o pacote de instalação tenha espaço suficiente e que não contenha qualquer outro arquivo no mesmo diretório;
Após a extração dos arquivos você pode verificar se atende os pré-requisitos com o arquivo prereqcheck.exe;

Após a verificação ser concluída de um duplo clique em install.exe;
Selecione o idioma que será utilizado na instalação;
Clique em avançar na tela de boas vindas;
Selecione os produtos que você contratou e que irá instalar;

Aceite o contrato de Licença;
Se você contratou a opção de TSM para SAN (Lan Free) ou irá compartilhar sua tape library com outros servidores ou clientes TSM clique em Sim, caso contrário clique em Não.

Selecione a pasta que será instalado o TSM:

Selecione os componentes que serão instalados:

Você pode optar por utilizar os drivers de dispositivos nativos do Windows para as unidades de fita ou instalar e utilizar os driver do TSM, é recomendável verificar a documentação do fabricante da sua tape library e decidir qual driver utilizar. Se você não instalar os drivers do TSM no momento da instalação, os mesmos poderão ser instalados posteriormente.

Selecione os idiomas adicionais a serem instalados no servidor TSM;

Clique em Instalar;
Conclua a instalação:

Conforme visto, a instalação do servidor TSM é um processo bem simplificado. Após essas etapas, o servidor TSM está instalado, mas ainda não está funcional.

No próximo post, estarei finalizando com a execução das primeiras etapas no servidor TSM e tornando o mesmo operacional para o exercício de suas funções.

Até mais e um grande abraço.

Troubleshooting de rede com S.O Linux - parte final

2013-03-22T03:01:00.000-03:00

Boa noite, caros leitores.

Hoje estarei concluindo a série de post sobre ferramentas de análise e diagnose de rede em S.O Linux.

O intuito dessa série é prover uma linha de utilitários para troubleshooting de redes.

Todas as ferramentas demonstradas anteriormente são essenciais para a análise de problemas; mas uma entre elas se destaca - é o TCPDUMP, e ela será o "carro chefe" de hoje, pela sua importância e utilidade.

TCPDUMP

É um analisador de pacotes via linha de comando, extremamente útil em diversas ocasiões (análise pós-ataque, debug de conectividade, etc..). Com ele, literalmente, você pode ver tudo o que se passa no segmento de rede.

É aconselhável, normalmente usar a chave –p, para que a interface não entre em modo promíscuo (modo em que a interface recebe todos os pacotes que passam por ela, mesmo os que não são destinados a mesma). Outra chave que deve ser utilizada é -n, com ela o TCPDUMP não converte os nomes (hosts, portas, etc...), tornando o processo de análise mais limpo.

Outra chave importante é –i, com ela você especifica a interface a ser utilizada.

Capturando o tráfego com origem e destino de um único host:

Capturando o tráfego com origem e destino de mais de um host:

Capturando o tráfego com origem e destino de mais de um host, exceto de um host específico:

Capturando o tráfego em direção a um host específico:

Capturando o tráfego com origem de um host específico:

Capturando um protocolo específico:

Capturando mais de um protocolo:

Capturando uma porta específica:

Capturando mais de uma porta:

Capturando um range de portas:

Capturando o tráfego de origem de uma determinada porta:

Capturando o tráfego de destino de uma determinada porta:

Capturar pacotes maiores do que o tamanho especificado:

Capturar pacotes menores do que o tamanho especificado:

Com a chave –X podemos ler o payload (corpo de dados). Por default, somente são mostrados os primeiros 68 bytes, com a chave –s0 é exibido todo o payload:

Pode ser confuso fazer uma análise através do shell. Para tornar o trabalho mais fácil, utilize a chave –w. Esse artifício, permite que todo o tráfego capturado seja enviado para um arquivo, onde o mesmo poderá ser lido com a chave –r ou analisado com o programa Wireshark:

Visualizando o arquivo com o Wireshark:

Agora para ficar mais claro a análise com o TCPDUMP, irei comentar os campos de um fragmento de acesso http (80):

00:54:08.780858: é o timestamp (hh:mm:ss:fraction);

vm-ubuntu.60691: é o host e a porta de origem (no caso deste fragmento);

vm-centos.http: é o host e a porta de destino (no caso deste fragmento);

Flags [S]: A primeira parte do handshake do TCP (SYN, SYN-ACK,ACK);

seq 2316528663: é o numero de sequência de byte. O número de sequência inicial (ISN) é gerado de forma randômica;

win 14600: é o tamanho da janela (em bytes) de buffer que o host, pode receber de dados;

mss 1460: é o tamanho máximo do segmento ou o tamanho máximo do conjunto de dados que pode ser gerenciado sem usar fragmentação;

sackOK: é o reconhecimento positivo, permite ao destinatário reconhecer pacotes fora da sequência;

TS val 560480 ecr 0: é o tempo de ida e de volta do pacote;

nop: no operation, é usado para preencher campos de tamanho menores;

wscale 6: é utilizado para contornar a limitação original de tamanho da janela de 65,535 bytes;

length 0: tamanho dos dados contidos no pacote.

Quando você estiver analisando uma tentativa/ataque ou um serviço com problema, será muito útil, realizar capturas por flags TCP (SYN, SYN-ACK, ACK, FIN, URG, PSH e RST). Na man page do TCPDUMP, verifica-se como calcular os valores para as flags, ou você poderá utilizar os seguintes valores já calculados:

SYN

# tcpdump 'tcp[13] & 2!=0'

SYN-ACK

# tcpdump 'tcp[13] = 18'

ACK

# tcpdump 'tcp[13] & 16!=0'

FIN

# tcpdump 'tcp[13] & 1!=0'

URG

# tcpdump 'tcp[13] & 32!=0'

PSH

# tcpdump 'tcp[13] & 8!=0'

RST

# tcpdump 'tcp[13] & 4!=0'

Lembrando que estes cálculos, podem ser combinados com todas as outras opções mostradas anteriormente (hosts, portas, protocolos, redes, etc...).

IFTOP

Outra ferramenta muito útil é o IFTOP, com ele você pode monitorar o consumo de banda de uma determinada interface:

Para entrar no menu de ajuda pressione h. A seguir os principais comandos utilizados no IFTOP:

Opções de Hosts:

n – resolve ou não o nome dos hosts;

s – mostra ou não o host de origem;

d – mostra ou não o host de destino;

t – Alterar o ciclo de transmissão (entrada e saída na mesma linha, somente entrada, somente saída, entrada e saída em linha separada).

Opções de Portas:

N – resolve ou não as portas (TCP e UDP);

S – mostra ou não a porta de origem;

D – mostra ou não a porta de destino;

p – mostra ou não as portas (origem e destino).

IPERF

IPERF é utilizado para medir o desempenho de TCP e UDP entre dois hosts. Para a realização dos testes, dever ser instalado em ambos hosts.

Um estará executando o IPERF em modo de servidor (chave -s) e o outro estará em modo cliente (chave -c):

Para realizar um teste bi-direcional, adicione a chave -d, ou se quiser realizar o teste um um host por vez, utilize a chave -r.

Bem, senhores (as), estou finalizando esta série sobre ferramentas para troubleshooting de rede em S.O Linux.

Sei que existem milhares de outras que não foram citadas, mas com certeza as que foram mencionadas são de grande valia em qualquer tipo de ambiente ou de problema.

Espero que aproveitem e qualquer dúvida nos comandos mencionados, consulte a man page ou execute comando --help.

Até mais e um grande abraço.

Troubleshooting de rede com S.O Linux - parte 01

2013-03-18T02:20:00.000-03:00

Boa noite, caros leitores.

Hoje abordarei algumas ferramentas utilizadas na análise e diagnose de problemas de rede com S.O Linux.

As ferramentas a seguir demonstradas são extremamente úteis tanto em servidores rodando S.O Linux, quanto em um notebook/virtual machine, preparado com as ferramentas instaladas.

O domínio desses utilitários ajudará a reduzir drasticamente o tempo de "debug" em seu ambiente de homologação e produção.

PING

Sem dúvida nenhuma, este deve ser o primeiro teste realizado em um troubleshooting.

Mesmo sendo trivial seu uso, e muito dos leitores devem estar pensando o porque de citar essa ferramenta, eu explico: em inúmeras situações de análise em que eu me envolvi, esse simples teste foi literalmente neglicenciado.

Por isso, ressalto que ele deve ser utilizado como ponto de partida para análise de conectividade.

O comando ping é muito simples:

# ping destino(ip ou fqdn)

No Linux por default, será realizado o envio de ICMP infinito, se a chave -c não for utilizada:

No exemplo acima, foram realizados três envios de ICMP para o host 8.8.8.8 (-c3).

Se o servidor a ser analisado possuir mais que uma interface de rede, você poderá especificar a interface a ser utilizada com a chave -I:

Principais testes a ser realizados com o PING:

Localhost: Se este teste inicial falhar, provavelmente todos os outros irão, pois se o host não conseguir acessar a interface de loopback, há algum problema na configuração TCP/IP.

Gateway: Se este teste falhar, provavelmente você tem um problema entre seu host e seu gateway. Ex: bloqueio do firewall, má configuração gateway/netmask, cabo ou porta do switch com defeito, etc...

Host externo (Ex.8.8.8.8): Se este teste falhar, provavelmente você tem um problema no seu gateway ou link de internet.

FPING

Na mesma linha do utilitário PING, o FPING realiza uma ECHO REQUEST, mas para vários hosts, dentro de uma mesma rede/subrede. Assim, você pode mapear todos os hosts, dentro de uma determinada rede/subrede, que respondem a pacotes ICMP.

Com a chave -g define-se uma rede a ser escaneada; com a chave -d realiza-se consulta DNS e com a chave -s exibe-se um resumo ao final do scan.

Outro ponto interessante é enviar o resultado para um arquivo .txt (Ex. > fpingtest):

NMAP

Esse utilitário é um verdadeiro canivete suíço, muito utilizado em scan de vulnerabilidades. Com ele você pode ter inúmeras opções de scan, desde hosts, portas, S.O, etc... Enfim, vale a pena dedicar um tempo no detalhamento desta ferramenta.

Eu abordarei os comandos mais simples, pois este post não é específico sobre NMAP. Para mais informações sobre todas as opções realizadas pelo NMAP consulte aqui.

Para começar a trabalhar com o NMAP você pode usar a chave -sP, que fará o mesmo trabalho realizado anteriormente pelo FPING:

No exemplo acima foi utilizado somente um host. Todavia, você poderá escanear uma rede ou subrede.

Com a chave -sS, o NMAP mostrará as portas que estão abertas no host ou rede especificado:

Acrescentando a chave -O, o NMAP mostrará o Sistema Operacional do host ou rede especificado

ARPING

Esta ferramenta é útil para verificar se um determinado endereço já está em uso, utilize com a chave -D para escanear endereços duplicados:

HTTPING

Para testar a latência de acesso a um determinado site, você pode utilizar essa ferramenta. Com a chave -c, você diz o número de requisições que serão realizadas; com a chave -g, você especifica a URL:

Isso mostrou somente o tempo que levou para o servidor responder a uma solicitação HEAD e não o tempo que levou para carregar a página completa. Com a chave -G (get), você carrega toda a página:

Para reportar o tempo de ida e de volta em kilobytes utilize a chave -b:

TELNET

Após testar conectividade, não há ferramenta mais simples que esta para testar um serviço especifico:

No primeiro exemplo, houve sucesso na tentativa de conexão no serviço de HTTP (80), no segundo houve falha, pois provavelmente, não há um serviço ou porta disponível no host especificado.

TRACEROUTE

Outro utilitário de grande importância é o traceroute. Com ele é possível visualizar o caminho percorrido (hops) de uma rede para outra.

Se for fazer uso desse comando para verificar uma rede pela Internet, é aconselhável empregar a chave -I que utiliza solicitações ICMP ECHO e não datagramas UDP (geralmente bloqueados pelos routers):

MTR

Essa ferramenta MTR (MyTraceroute), combina o PING com o TRACEROUTE.

Utilize-a para capturar latência combinada; perda de pacote e estatísticas de routers com problemas.

A chave -c diz o número de interações que serão realizadas e a chave -r organiza os dados em formato de relatório:

Bom, senhores (as), por hoje é só! No próximo post estarei completando esse assunto com mais algumas ferramentas extremamente úteis para análise e diagnose de troubleshooting de rede.

Sei que não falei de todas as opções das ferramentas citadas nesse posts, nem era esse o intuito, mas sim de dar um arcabouço para a resolução de problemas rotineiros.

Se necessitar de qualquer auxílio na utilização de algum utilitário aqui descrito, é só digitar comando --help, que aparecerão todas as opções possíveis de se executar.

Novamente friso que vale a pena despender um tempo no aprendizado do NMAP, haja vista tratar-se de uma ferramenta bastante útil e interessante.

Até mais e um grande abraço.

Planejando a instalação do Tivoli Storage Manager - parte final

2013-03-15T02:23:00.000-03:00

Boa noite, caros leitores,

Hoje estarei finalizando a etapa de planejamento da instalação do servidor TSM.

Como foi dito ao longo destes posts, é de suma importância dedicar um período inicial para evitar dissabores e problemas de desempenho ou até mesmo a indisponibilidade do serviço após sua implementação.

Para concluir esse assunto abordarei os dois últimos tópicos, são eles:

· Monitorando a utilização de espaço para o banco de dados e os logs de recuperação;

· Boas Práticas de Nomenclatura do Servidor.

1 - MONITORANDO A UTILIZAÇÃO DE ESPAÇO DO BANCO DE DADOS (DB2) E DOS LOGS DE RECUPERAÇÃO (ACTIVE LOG, ARCHIVE LOG)

Se mesmo após 02 posts e quase 50 páginas do Guia de Instalação, você ainda não conseguiu dimensionar corretamente o espaço para o banco de dados e os logs de recuperação, ainda há esperança, não se desespere. Brincadeiras a parte, irei mostrar como verificar os logs do servidor TSM e determinar a ação que deverá ser tomada.

Para verificar o banco de dados, no administrative command-line, execute o seguinte comando:

Se a quantidade de espaço disponível para as atividades do banco de dados for muito baixa, as seguintes mensagens serão exibidas no log de atividade:

ANR2992W: IC_LOG_FILE_SYSTEM_UTILIZATION_WARNING_2

O espaço usado do banco de dados excede o limite para utilização do espaço do banco de dados. Para aumentar o espaço para o banco de dados, use o comando EXTEND DBSPACE, o comando EXTEND DBSPACE ou o utilitário DSMSERV FORMAT com o parâmetro DBDIR.

ANR1546W: FILESYSTEM_DBPATH_LESS_1GB

O espaço disponível no diretório em que os arquivos do banco de dados do servidor estão localizados é menor que 1 GB.

Quando um servidor Tivoli Storage Manager é criado com o utilitário DSMSERV FORMAT ou com o assistente de configuração, um banco de dados do servidor e o log de recuperação também são criados. O caminho especificado nesta mensagem indica o local das informações do banco de dados usado pelo gerenciador do banco de dados. Se o espaço não estiver disponível no caminho, o servidor não poderá mais funcionar.

Para verificar os logs de recuperação no administrative command-line, execute o seguinte comando:

LOG ATIVO

Se a quantidade de espaço de log ativo disponível for muito baixa, as seguintes mensagens serão exibidas no log de atividade:

ANR4531I: IC_AUTOBACKUP_LOG_USED_SINCE_LAST_BACKUP_TRIGGER

Essa mensagem é exibida quando o espaço de log ativo exceder o tamanho máximo especificado. Nessa situação o servidor TSM inicia um backup completo do banco de dados.

Para alterar o tamanho máximo de log, pare o servidor. Abra o arquivo dsmserv.opt e especifique um novo valor para a opção ACTIVELOGSIZE. Quando tiver concluído, reinicie o servidor.

ANR0297I: IC_BACKUP_NEEDED_LOG_USED_SINCE_LAST_BACKUP

Essa mensagem é exibida quando o espaço de log ativo exceder o tamanho máximo especificado. Nesse caso, você deve fazer backup do banco de dados manualmente.

Para alterar o tamanho máximo de log, é o mesmo procedimento descrito anteriormente.

ANR4529I: IC_AUTOBACKUP_LOG_UTILIZATION_TRIGGER

A proporção de espaço de log ativo usado para o espaço de log ativo disponível excede o limite de utilização do log. Se pelo menos um backup completo do banco de dados tiver ocorrido, o servidor TSM iniciará um backup incremental do banco de dados. Caso contrário, o servidor iniciará um backup completo do banco de dados.

ANR0295I: IC_BACKUP_NEEDED_LOG_UTILIZATION

A proporção de espaço de log ativo usado para o espaço de log ativo disponível excede o limite de utilização do log. Você deve fazer backup do banco de dados manualmente.

ARCHIVE LOG

Se a quantidade de espaço de log disponível do archive for muito baixa, a seguinte mensagem será exibida no log da atividade:

ANR0299I: IC_BACKUP_NEEDED_ARCHLOG_USED

A proporção de espaço usado de log de archive para o espaço de log de archive disponível excede o limite de utilização do log. O servidor Tivoli Storage Manager inicia um backup completo automático do banco de dados.

2 - BOAS PRÁTICAS DE NOMENCLATURA DO SERVIDOR

A seguir estão as recomendações para a nomeação do usuário, instância, servidor, banco de dados e diretórios do TSM.

ID de Usuário da Instância

O ID de usuário da instância é usado como a base para outros nomes relacionados à instância do servidor. O ID de usuário da instância também é chamado de proprietário da instância.

Ex: tsminst1

O ID do usuário deve ter propriedade ou autoridade de acesso de leitura/gravação a todos os diretórios criados para o banco de dados e para o log de recuperação. A maneira padrão de executar o servidor é no ID do usuário da instância. Esse ID também deve ter acesso de leitura/gravação para os diretórios usados para quaisquer classes do dispositivo FILE.

Diretório inicial para o ID do usuário da instância (Linux)

O diretório inicial pode ser criado juntamente ao criar o ID do usuário da instância, usando a opção (-m).

Ex: /home/tsminst1

O diretório inicial é usado primariamente para conter o perfil para o ID do usuário e para as configurações de segurança.

Nome da Instância de Banco de Dados

O nome da instância de banco de dados é o nome da instância do servidor como ele aparece no registro.

Ex: Server1

Diretório de Instâncias

O diretório da instância é um diretório que contém arquivos especificamente para uma instância do servidor (o arquivo de opções do servidor e outros arquivos específicos do servidor). Ele pode ter qualquer nome que você deseje. Para uma identificação mais fácil, use um nome que faça a correspondência do diretório com o nome da instância.

(Windows) Você pode usar um nome que inclua o nome da instância do servidor como ele aparece (ou aparecerá) no registro.

Ex: d:\tsm\server1

(Linux) É possível criar o diretório de instâncias como um subdiretório do diretório inicial para o ID do usuário da instância.

Ex: /home/instance_user_ID/instance_user_ID

O exemplo a seguir coloca o diretório de instâncias no diretório inicial do ID de usuário tsminst1:

/home/tsminst1/tsminst1

É possível também criar o diretório em outro local, por exemplo:

/tsmserver/tsminst1

O diretório de instâncias armazena os seguintes arquivos para a instância do servidor:

· O arquivo de opções do servidor, dsmserv.opt;

· O arquivo de banco de dados de chave do servidor, cert.kdb e os arquivos .arm (usados pelos clientes e outros servidores para importar os certificados SSL do servidor);

· O arquivo de configuração do dispositivo, se a opção do servidor DEVCONFIG não especificar um nome completo;

· O arquivo do histórico de volume, se a opção do servidor VOLUMEHISTORY não especificar um nome completo;

· Volumes para conjuntos de armazenamentos DEVTYPE=FILE, se o diretório para a classe de dispositivo não estiver especificado integralmente ou não estiver completo;

· Saídas de usuário;

· Saída de rastreio (se não estiver completo);

Nome do Banco de Dados

O nome do banco de dados é sempre TSMDB1, para cada instância do servidor. Este nome não pode ser alterado.

Nome do Servidor

O nome do servidor é um nome interno para o TSM e é usado para operações que envolvem comunicação entre vários servidores.

Use um nome exclusivo para cada servidor. Para uma fácil identificação no Centro de Administração (ou a partir de um comando QUERY SERVER), use um nome que reflita o local ou a finalidade do servidor.

Se usar o assistente, o nome padrão sugerido será o nome do host do sistema que você estiver usando. É necessário digitar um nome exclusivo para cada servidor.

Por exemplo:

TSM_SERVER1

TSM_SERVER2

Diretórios para Espaço de Banco de Dados e Log de Recuperação

Os diretórios podem ser nomeados de acordo com práticas locais. Para uma identificação mais fácil, considere o uso de nomes que façam a correspondência dos diretórios com a instância do servidor.

Por exemplo, para o log de archive:

f:\server1\archlog (Windows)

/tsminst1_archlog (Linux)

Diretórios de Instalação (Linux)

Os diretórios de instalação do servidor TSM incluem o servidor, o DB2, o dispositivo, o idioma e outros diretórios. Cada um contém vários diretórios adicionais.

Os diretórios padrões e seus subdiretórios são listados aqui para o servidor, o DB2, os dispositivos e os idiomas:

Diretório do servidor (/opt/tivoli/tsm/server/bin), que contém:

– Código do servidor e licença

Diretórios do servidor adicionais:

– O comando e a ajuda de mensagem estão no diretório /opt/tivoli/tsm/server/bin/dsmserv.hlp.

– Inventário do Tivoli (/opt/tivoli/tsm/tivinv)

Diretórios do DB2

O produto DB2 que é instalado como parte da instalação do servidor TSM possui a estrutura de diretório conforme documentada nas origens de informações do DB2. Proteja esses diretórios e arquivos como você faz com os diretórios do servidor.

– /opt/tivoli/tsm/db2

Diretórios de dispositivos

– /opt/tivoli/tsm/devices/bin

Diretório de idiomas

Partes dependentes de idioma do programa estão localizadas aqui:

/opt/tivoli/tsm/server/bin

Então senhores (as), com isso finalizei todos os tópicos dessa importante etapa, que se bem realizada, só trará benefícios e otimizará o desempenho dessa solução que é a mais completa do mercado.

Nos próximos encontros sobre TSM, abordarei a instalação do servidor (Windows e Linux).

Espero que esse assunto tenha ficado bem sedimentado e em caso de dúvida não hesitem em perguntar.

Até mais e um grande abraço.

Planejando a instalação do Tivoli Storage Manager - parte 02

2013-03-14T04:15:00.000-03:00

Boa noite, caros leitores.

No post anterior, citei os requisitos mínimos de hardware e software para o servidor TSM. Falei também a respeito das duas formas de dimensionamento de espaço para acomodação do Banco de Dados – DB2 (pelo número máximo de arquivos armazenados no servidor ou pela capacidade dos conjuntos de armazenamento).

Hoje, abordarei o dimensionamento de espaço reservado para os Logs de recuperação.

No TSM, o termo log de recuperação compreende:

Active log (Log Ativo);
Archive log;
Active log mirror;
Archive log failover archive.

A quantidade de espaço necessária para o log de recuperação depende de diversos fatores, incluindo, por exemplo, a quantidade de atividade dos clientes com o servidor.

Espaço de Log Ativo e Archive Log

No dimensionamento de espaço para logs ativos e archive logs, sempre inclua algum espaço extra para contingências, tais como: cargas de trabalho pesadas ocasionais e failovers.

A partir da V6.1, o log ativo pode ter um tamanho máximo de 128 GB.

O tamanho do log de archive é limitado ao tamanho do sistema de arquivos no qual está instalado.

Utilize as seguintes boas práticas ao estimar o tamanho do log ativo e archive log:

· O tamanho inicial sugerido para o log ativo é de 16 GB.

· O log ativo deve ser grande o suficiente para a quantidade de atividade simultânea que o servidor geralmente manipula. Forneça espaço extra ao log ativo para que possa ser usado se necessário. Vinte por cento é uma quantidade razoável de espaço extra a considerar.

· Monitore o espaço de log usado e ativo disponível e ajuste se necessário.

· Considere que o diretório que armazena o log ativo seja tão grande ou maior que o tamanho do log ativo. Um diretório maior que o log ativo pode acomodar failovers, caso ocorram.

· Certifique-se de que o sistema de arquivos que contém o diretório de log ativo possua pelo menos 8 GB de espaço livre para os requisitos de movimento de log temporário.

· O tamanho inicial sugerido para o log de archive é de 48 GB (3x Active Log).

O diretório de log de archive deve ser grande o suficiente para conter os arquivos de log desde o backup completo anterior.

Por exemplo, se você executar um backup completo do banco de dados todos os dias, o diretório de log do archive deverá ser grande o suficiente para conter os arquivos de log para toda a atividade do cliente que ocorrer durante 24 horas.

Para recuperar espaço, o servidor exclui arquivos de log de archive obsoletos após um backup completo do banco de dados. Se o diretório de log de archive ficar cheio e um diretório para logs de failover de archive não existir, os arquivos de log permanecerão no diretório de log ativo. Essa condição pode fazer com que o diretório de log ativo fique cheio e, consequentemente, pare o servidor.

Monitore a utilização de archive log e o espaço no diretório e ajuste caso necessário.

Se o espaço no diretório de archive log ficar cheio, pode acontecer o seguinte problema:

O servidor pode não executar backups completos do banco de dados.

Verifique se outros aplicativos não estão gravando no diretório de archive log, consumindo o espaço requerido. Nunca compartilhe o espaço do archive log. Cada servidor ou instância deverá ter seu local de armazenamento (archive log) separado.

Todas as estimativas que serão demonstradas a seguir foram retiradas do IBM Tivoli Storage Manager para Linux: Guia de Instalação

1 - Estimando tamanhos de log ativos e de archive para operações básicas de armazenamento de clientes (backup, archive e gerenciamento de espaço).

O espaço de log deve ser suficiente para manipular todas as transações de armazenamento que estiverem em andamento de uma só vez.

Para determinar os tamanhos dos logs ativos e de archive para operações básicas de armazenamento de clientes, use o seguinte cálculo:

número de clientes

arquivos armazenados durante cada transação

espaço de log necessário para cada arquivo

Item	Valores de exemplo	Descrição
Número máximo de nós clientes que efetuam backup, archive ou migração de arquivos simultaneamente a qualquer momento.	300	O número de nós clientes que fazem backup, archive ou migram arquivos no mesmo período
Arquivos armazenados durante cada transação	4096	O valor padrão da opção do servidor TXNGROUPMAX é 4096.
O espaço de log requerido para cada arquivo	3053 bytes	O valor de 3053 bytes para cada arquivo em uma transação representa os bytes do log necessários ao efetuar backup de arquivos de um cliente do Windows em que os nomes do arquivo sejam de 12 - 120 bytes.
Log ativo	19.5 GB	Use o cálculo a seguir para determinar o tamanho do log ativo. 1 GB = 1.073.741.824 bytes. (300 clientes x 4096 arquivos armazenados durante cada transacao x 3053 bytes para cada arquivo) ÷ 1.073.741.824 bytes = 3.5 GB + tamanho inicial sugerido de 16 GB: 3.5 + 16 = 19.5 GB
Archive log	58.5 GB	Devido ao requisito de poder armazenar logs de archive em três ciclos de backup do banco de dados do servidor, multiplique a estimativa para o log ativo por 3 para estimar o requisito de log de archive total. 3.5 x 3 = 10.5 GB + tamanho inicial sugerido de 48 GB: 10.5 + 48 = 58.5 GB
Sempre monitore seus logs e ajuste seu tamanho se necessário.

2 - Estimando tamanhos de log ativos e de archive para clientes que usam diversas sessões

Se a opção do cliente RESOURCEUTILIZATION for configurada para um valor maior que o padrão, a carga de trabalho simultânea para o servidor aumentará.

Para determinar os tamanhos dos logs ativo e de archive quando os clientes usarem diversas sessões use o seguinte cálculo:

número de clientes

sessões para cada cliente

arquivos armazenados durante cada transação

espaço de log necessário para cada arquivo

Item	Valores de exemplo	Descrição
Número máximo de nós clientes que efetuam backup, archive ou migração de arquivos simultaneamente a qualquer momento.	300	O número de nós clientes que fazem backup, archive ou migram arquivos no mesmo período
Sessões possíveis para cada cliente	3	A configuração da opção do cliente RESOURCEUTILIZATION é maior que o padrão. Cada sessão do cliente executa um máximo de três sessões em paralelo.
Arquivos armazenados durante cada Transação	4096	O valor padrão da opção do servidor TXNGROUPMAX é 4096.
O espaço de log requerido para cada Arquivo	3053 bytes	O valor de 3053 bytes para cada arquivo em uma transação representa os bytes do log necessários ao efetuar backup de arquivos de um cliente do Windows em que os nomes do arquivo sejam de 12 - 120 bytes.
Log ativo	26.5 GB	Use o cálculo a seguir para determinar o tamanho do log ativo. 1 GB = 1.073.741.824 bytes. (300 clientes x 3 sessoes para cada cliente x 4096 arquivos armazenados durante cada transacao x 3053 bytes para cada arquivo) ÷ 1.073.741.824 = 10.5 GB + tamanho inicial sugerido de 16 GB: 10.5 + 16 = 26.5 GB
Archive log	79.5 GB	Devido ao requisito de poder armazenar logs de archive em três ciclos de backup do banco de dados do servidor, multiplique a estimativa para o log ativo por 3 para estimar o requisito de log de archive total. 10.5 x 3 = 31.5 GB + tamanho inicial sugerido de 48 GB: 31.5 + 48 = 79.5 GB
Sempre monitore seus logs e ajuste seu tamanho se necessário.

3 - Estimando tamanhos de log ativos e de archive para operações simultâneas de gravação

Se as operações de backup do cliente usarem conjuntos de armazenamentos configurados para gravação simultânea, a quantidade de espaço de log requerida para cada arquivo aumenta.

O espaço de log requerido para cada arquivo aumenta aproximadamente 200 bytes para cada conjunto de armazenamentos de cópias que é usado para uma operação de gravação simultânea. No exemplo a seguir, os dados são armazenados em dois conjuntos de armazenamentos de cópias, além de um conjunto de armazenamentos primário. O tamanho do log estimado aumenta em 400 bytes para cada arquivo. Se você usar o valor sugerido de 3053 bytes de espaço de log para cada arquivo, o número total de bytes requerido será de 3453.

Item	Valores de exemplo	Descrição
Número máximo de nós clientes que efetuam backup, archive ou migração de arquivos simultaneamente a qualquer momento.	300	O número de nós clientes que fazem backup, archive ou migram arquivos no mesmo período
Arquivos armazenados durante cada transação	4096	O valor padrão da opção do servidor TXNGROUPMAX é 4096.
O espaço de log requerido para cada arquivo	3453 bytes	3053 bytes mais 200 bytes para cada conjunto de armazenamentos de cópias. O valor de 3053 bytes para cada arquivo em uma transação representa os bytes do log necessários ao efetuar backup de arquivos de um cliente do Windows em que os nomes do arquivo sejam de 12 - 120 bytes.
Log ativo	20 GB	Use o cálculo a seguir para determinar o tamanho do log ativo. 1 GB = 1.073.741.824 bytes. (300 clientes x 4096 arquivos armazenados durante cada transacao x 3453 bytes para cada arquivo) ÷ 1.073.741.824 bytes = 4 GB + tamanho inicial sugerido de 16 GB: 4 + 16 = 20 GB
Archive log	60 GB	Devido ao requisito de poder armazenar logs de archive em três ciclos de backup do banco de dados do servidor, multiplique a estimativa para o log ativo por 3 para estimar o requisito de log de archive total. 4 x 3 = 12 GB + tamanho inicial sugerido de 48 GB: 12 + 48 = 60 GB
Sempre monitore seus logs e ajuste seu tamanho se necessário.

4 - Estimando tamanhos de log ativos e de archive para operações básicas de armazenamento de clientes e operações do servidor

Migração de dados no armazenamento do servidor, processos de identificação para deduplicação de dados, reclamação e expiração podem ser executados simultaneamente com operações de armazenamento de clientes.

Igualmente, tarefas administrativas como comandos administrativos ou consultas SQL de clientes administrativos também podem ser executados simultaneamente com operações de armazenamento de clientes.

Operações do servidor e tarefas administrativas que são executadas simultaneamente podem aumentar o espaço de log ativo requerido.

Por exemplo, a migração de arquivos do conjunto de armazenamentos de acesso aleatório (DISK) para um conjunto de armazenamentos de disco de acesso sequencial (FILE) usa aproximadamente 110 bytes de espaço de log para cada arquivo que é migrado. Suponha que você tenha 300 clientes de backup-archive e cada um deles faça backup de 100.000 arquivos cada noite. Os arquivos são inicialmente armazenados no DISK e, em seguida, migrados para um conjunto de armazenamentos FILE. Para estimar a quantidade de espaço de log ativo requerido para a migração de dados, use o seguinte cálculo: o número de clientes do cálculo representa o número máximo de nós clientes que realiza backup, archive ou migra arquivos simultaneamente a qualquer momento.

300 clientes x 100.000 arquivos para cada cliente x 110 bytes = 3.1 GB

Por fim, inclua este valor na estimativa para o tamanho do log ativo calculado para operações básicas de armazenamento de clientes.

5 - Estimando tamanhos de log do archive com backups completos de banco de dados

O servidor Tivoli Storage Manager exclui arquivos desnecessários do log de archive somente quando ocorre um backup completo do banco de dados.

Consequentemente, quando você estima o espaço requerido para o log de archive, você também deve considerar a frequência dos backups completos do banco de dados.

Por exemplo, se ocorrer um backup completo do banco de dados uma vez por semana, o espaço de log do archive deverá conter as informações no log de archive para uma semana inteira.

Item	Valores de exemplo	Descrição
Número máximo de nós clientes que efetuam backup, archive ou migração de arquivos simultaneamente a qualquer momento.	300	O número de nós clientes que fazem backup, archive ou migram arquivos no mesmo período
Arquivos armazenados durante cada transação	4096	O valor padrão da opção do servidor TXNGROUPMAX é 4096.
O espaço de log requerido para cada arquivo	3453 bytes	3053 bytes mais 200 bytes para cada conjunto de armazenamentos de cópias. O valor de 3053 bytes para cada arquivo em uma transação representa os bytes do log necessários ao efetuar backup de arquivos de um cliente do Windows em que os nomes do arquivo sejam de 12 - 120 bytes.
Log ativo	20 GB	Use o cálculo a seguir para determinar o tamanho do log ativo. 1 GB = 1.073.741.824 bytes. (300 clientes x 4096 arquivos armazenados durante cada transacao x 3453 bytes para cada arquivo) ÷ 1.073.741.824 bytes = 4 GB + tamanho inicial sugerido de 16 GB: 4 + 16 = 20 GB
Archive log	60 GB	Devido ao requisito de poder armazenar logs de archive em três ciclos de backup do banco de dados do servidor, multiplique a estimativa para o log ativo por 3 para estimar o requisito de log de archive total. 4 x 3 = 12 GB + tamanho inicial sugerido de 48 GB: 12 + 48 = 60 GB
Archive log: Com um banco de dados completo toda semana	132 GB	Multiplique o resultado pelo número de dias entre os backups completos do banco de dados: (4 GB x 3 ) x 7 = 84 GB Aumente essa quantidade no tamanho inicial sugerido de 48 GB: 84 + 48 = 132 GB
Sempre monitore seus logs e ajuste seu tamanho se necessário.

6 - Estimando tamanhos de logs ativos e de archive para operações de deduplicação de dados

Se você deduplicar dados, deverá considerar seus efeitos nos requisitos de espaço para logs ativos e de archive.

Os fatores a seguir afetam requisitos para o espaço de logs ativos e de archive:

A quantidade de dados deduplicados

Os efeitos da deduplicação de dados no log ativo e no espaço de log do archive dependem da porcentagem de dados elegíveis para deduplicação.

Se a porcentagem de dados que pode ser deduplicada for relativamente alta, mais espaço de log será requerido.

O tamanho e o número de extensões

Aproximadamente 1.500 bytes de espaço de log ativo são requeridos para cada extensão identificada por um processo de identificação de deduplicações.

Por exemplo, se 250.000 extensões forem identificadas por um processo de identificação de deduplicações, o tamanho estimado do log ativo será 358 MB:

250.000 extensões identificadas durante cada processo x 1.500 bytes para cada extensão = 358 MB

Ex: 300 clientes de backup-archive fazem backup de 100.000 arquivos a cada noite. Essa atividade cria uma carga de trabalho de 30.000.000 de arquivos. O tamanho médio de extensões de cada arquivo é dois. Assim, o número total de extensões é 60.000.000 e o requisito de espaço para o log de archive é de 84 GB:

60.000.000 de extensões x 1.500 bytes para cada extensao = 84 GB

Um processo de identificação de duplicações opera em agregados de arquivos. Um agregado consiste em arquivos que são armazenados em uma determinada transação, conforme especificado pela opção do servidor TXNGROUPMAX. Suponha que a opção do servidor TXNGROUPMAX seja configurada para o padrão 4096. Se o número médio de extensões para cada arquivo for dois, o número total de extensões em cada agregado será 8192 e o espaço requerido para o log ativo será de 12 MB:

8192 extensões em cada agregado x 1500 bytes para cada extensão = 12 MB

Sincronização e número de processos de identificação de deduplicações

A sincronização e o número de processos de identificação de deduplicações também afetam o tamanho do log ativo. Usando o tamanho de log ativo de 12 MB que foi calculado no exemplo anterior, o carregamento simultâneo no log ativo será de 120 MB se 10 processos de identificação de deduplicações estiverem em execução em paralelo:

12 MB para cada processo x 10 processos = 120 MB

Tamanho do arquivo

Arquivos grandes que são processados para identificação duplicada também podem afetar o tamanho do log ativo. Por exemplo, suponha que um cliente de backup-archive faça backup de uma imagem do sistema de arquivos de 80 GB. Esse objeto pode ter um número elevado de extensões duplicadas se, por exemplo, for feito backup, de forma incremental, dos arquivos incluídos na imagem do sistema de arquivos. Por exemplo, suponha que uma imagem do sistema de arquivos tenha 1,2 milhões de extensões duplicadas. Os 1,2 milhões de extensões deste arquivo grande representam uma única transação para um processo de identificação de deduplicações. Por conseguinte, o espaço total no log ativo que é requerido para este único objeto é de 1.7 GB:

1.200.000 de extensões x 1.500 bytes para cada extensão = 1.7 GB

Se ocorrerem outros processos menores de identificação de deduplicação ao mesmo tempo em que o processo de identificação de deduplicação para um único objeto grande, o log ativo talvez não tenha espaço suficiente. Por exemplo, suponha que o conjunto de armazenamentos esteja ativado para deduplicação. O conjunto de armazenamentos possui uma mistura de dados, incluindo muitos arquivos relativamente pequenos que vão de 10 KB a várias centenas de KB. O conjunto de armazenamentos também possui poucos objetos grandes que têm uma alta porcentagem de extensões duplicadas.

Para levar em conta não apenas os requisitos de espaço, mas também a sincronização e duração de transações simultâneas, aumente o tamanho estimado do log ativo em um fator de dois. Por exemplo, suponha que seus cálculos para os requisitos de espaço sejam de 25 GB (23.3 GB + 1.7 GB para deduplicação de um objeto grande). Se os processos de deduplicação estiverem em execução simultaneamente, o tamanho sugerido do log ativo será de 50 GB. O tamanho sugerido do log de archive é de 150 GB.

Item	Valores de exemplo	Descrição
Tamanho do maior objeto único para deduplicação	800 GB	A granularidade de processamento para deduplicação está no nível do arquivo. Assim, o maior arquivo único para deduplicação representa a maior transação e um carregamento correspondentemente grande nos logs ativos e de archive.
Tamanho médio das extensões	256 KB	Os algoritmos de deduplicação usam um método de bloqueio variável. Nem todas as extensões deduplicadas para um determinado arquivo são do mesmo tamanho, assim, esse cálculo presume um tamanho médio de extensão.
Extensões para um determinado arquivo	3.276.800 bits	Usando o tamanho médio de extensão, esses cálculos representam o número total de extensões para um determinado objeto. O cálculo a seguir foi usado para diversas transações e um objeto de 800 GB: (800 GB ÷ 256 KB) = 3.276.800 bits
Log ativo: Tamanho sugerido requerido para a deduplicação de um único objeto grande durante um processo único de identificação de deduplicação	4.5 GB	O tamanho estimado do espaço de log ativo que é requerido para essa transação.
Log ativo: Tamanho total sugerido	71.6 GB	Após considerar outros aspectos da carga de trabalho no servidor além da deduplicação, multiplique a estimativa existente por um fator 2. Nesses exemplos, o espaço de log ativo requerido para deduplicar um único objeto grande é considerado juntamente com estimativas anteriores para o tamanho de log ativo requerido. O cálculo a seguir foi usado para diversas transações e um objeto de 800 GB: (23.3 GB + 4.5 GB) x 2 = 55.6 GB Aumente essa quantidade no tamanho inicial sugerido de 16 GB: 55.6 + 16 = 71.6 GB
Log de archive: Tamanho sugerido	214.8 GB	O tamanho estimado do log ativo multiplicado por um fator de 3. O cálculo a seguir foi usado para um objeto de 800 GB: 55.6 GB x 3 = 166.8 GB Aumente essa quantidade no tamanho inicial sugerido de 48 GB: 166.8 + 48 = 214.8 GB
Sempre monitore seus logs e ajuste seu tamanho se necessário.

Espaço do Espelho de Log Ativo

O log ativo pode ser espelhado para que a cópia espelhada seja usada se os arquivos de log ativos não puderem ser lidos. Observa-se, porém, que poderá haver somente um espelho de log ativo.

A criação de um espelho de log é uma opção sugerida. Se você aumentar o tamanho do log ativo, o tamanho de espelho do log ativo será aumentado automaticamente. O espelhamento de log pode afetar o desempenho devido à atividade duplicada de I/O requerida para manter o espelho.

O espaço adicional que o espelho de log requer é outro fator a considerar ao decidir se um espelho de log deve ser criado.

Se o diretório de log do espelho ficar cheio, o servidor emitirá mensagens de erro para o log da atividade e para o db2diag.log, mas isso não irá causar a parada do servidor.

Espaço de Failover Archive Log

O failover archive log é usado pelo servidor caso o diretório do archive log fique sem espaço.

Especificar um diretório de log de archive de failover pode evitar problemas que ocorrem se o log de archive ficar sem espaço.

Se o archive log e o failover archive log ficarem cheios, os dados permanecerão no diretório de log ativo. Essa condição pode fazer com que o log ativo fique cheio, o que causa a parada do servidor.

Bom senhores (as), mais um post enorme, eu sei, e peço desculpas por isso, mas como disse anteriormente este é um assunto que não permite abreviações.

No nosso próximo encontro estarei finalizando a etapa de Planejamento com os seguintes tópicos:

Monitorando a utilização de espaço para o banco de dados e os logs de recuperação;
Boas Práticas de Nomenclatura do Servidor.

Até mais e um grande abraço.

Planejando a instalação do Tivoli Storage Manager - parte 01

2013-03-12T02:32:00.000-03:00

Boa noite, caros leitores,

Como havia mencionado no post anterior sobre o TSM, irei segmentar os assuntos conforme o Guia de Instalação, dividindo-os em Planejando a instalação; Instalando e Executando as Primeiras Etapas do Tivoli Storage Manager.

Hoje iremos falar hoje sobre a primeira fase: Planejando a instalação

A importância dessa etapa se dá pelo o fato de uma ferramenta robusta como o TSM necessitar de um cuidado especial para a sua correta implementação, evitando assim a perda de desempenho ou até mesmo a indisponibilidade do serviço.

Um planejamento bem executado não tomará muito do seu tempo e em contrapartida irá trazer inúmeros benefícios.

Como mencionado, irei posteriormente descrever o processo de instalação do Servidor nos S.O Windows e Linux, estes processos serão descritos separadamente.

Já em relação ao planejamento, irei abordar em conjunto Windows e Linux, pois somente alguns requisitos diferem de um para o outro.

Outro ponto que também deve ser mencionado é que não irei descrever o planejamento de atualização de uma versão anterior para a versão 6.4. Falarei sobre atualização depois de completar o ciclo de instalação de uma nova liberação.

Requisitos do Sistema

Para a instalação do servidor TSM é necessário ter um nível mínimo de hardware e software.

O TSM é uma solução de alto desempenho e o servidor deve ser acomodado em um equipamento compatível com sua função.

Pense em backup como o seguro do seu ambiente de TI. Se você possuir uma Ferrari, você não colocará um seguro “meia-sola” nela. Da mesma forma, você não deve agir com sua solução de backup, que irá resguardar todas as suas informações; que em algumas situações pode ser o ativo mais valioso da Empresa ou cliente.

Já que seu cliente ou sua empresa optou pela melhor solução de backup do mercado, nada mais justo que se dedique um hardware compatível com o nível exigido para que o “seguro” ofereça o melhor desempenho possível.

As tabelas a seguir listam os requisitos mínimos de hardware e software para a instalação de um servidor TSM. Esses requisitos devem ser usados como um ponto de início.

Requisitos de Hardware

Tipo de hardware	Windows	Linux
Hardware	Um processador AMD64 ou Intel EMT-64	Um processador AMD64 ou Intel EMT-64
Espaço em disco	· Pelo menos 3 GB de armazenamento livre em disco (para uma instalação típica) · 200 MB de espaço em diretório temporário · Tamanho da partição de 2 GB na nidade C:\ · 300 MB no diretório de instância	· 5 MB para o diretório /var · 30 MB para o diretório /opt se você criar pontos de montagem · 2 GB para o diretório /opt/tivoli/tsm · 390 MB para o diretório /tmp · 300 MB para o diretório /usr · 2 GB no diretório inicial
Espaço em disco	Dica: Espere usar mais espaço para determinação de problemas. Espaço em disco adicional significativo é necessário para o banco de dados e os arquivos de log. O tamanho do banco de dados depende do número dos arquivos do cliente a serem armazenados e do método pelo qual o servidor gerencia os mesmos. O espaço no log ativo padrão é 16 GB, o mínimo necessário para a maioria das cargas de trabalho e das configurações. Aloque pelo menos três vezes o espaço no log ativo para o log de archive (48 GB). Assegure-se de ter recursos suficientes se estiver usando a deduplicação de dados ou esperando uma carga de trabalho pesada do cliente. Para desempenho ótimo e para facilitar a E/S, especifique pelo menos quatro diretórios separados ou Números de Unidade Lógica (LUNs) a serem usados pelo banco de dados e pelos logs. Fazendo essas especificações, a E/S é balanceada em múltiplos diretórios ou montagens.
Memória	· 12 GB. · 16 GB se você estiver usando deduplicação de dados. · Pelo menos 32 GB para servidores intensamente utilizados. A utilização de 32 GB ou mais de memória aprimora o desempenho do inventário do banco de dados do servidor do Tivoli Storage Manager. · Se você planeja executar múltiplas instâncias, cada instância exige a memória listada em um servidor. Multiplique a memória para um servidor pelo número de instâncias planejadas para o sistema. Processamento de replicação de nó requer memória adicional. Use um mínimo de 64 GB de memória para replicação de nó sem deduplicação de dados. A replicação de nó com a deduplicação de dados requer 128 GB de memória.

Requisitos de Software

Tipo de software	Windows	Linux
Sistema Operacional	.Microsoft Windows Server 2008: Standard, Enterprise ou Datacenter x64 Edition (64 bits) ·Microsoft Windows Server 2008 R2: Standard, Enterprise ou Datacenter Edition (64 bits)	· Red Hat Enterprise Linux 5, Update 3 ou posterior · Red Hat Enterprise Linux 6 · SUSE Linux Enterprise Server 10, Service Pack 2 ou posterior · SUSE Linux Enterprise Server 11
Bibliotecas	Não se aplica	Bibliotecas GNU C, Versão 2.3.3-98.38 ou posterior que estão instaladas no sistema do Tivoli Storage Manager. Para Red Hat Enterprise Linux e SUSE Linux Enterprise Servers: · Libaio.so.1 · Libstdc++so.6
Protocolo de comunicação	Pelo menos um dos seguintes protocolos de comunicação (instalado por padrão com os sistemas operacionais Windows atuais): · Canais Nomeados · TCP/IP Versão 4 ou Versão 6	·TCP/IP Versão 4 ou Versão 6, que é padrão com o Linux ·Protocolo de memória compartilhada (com o cliente x86_64 do Tivoli Storage Manager Versão 6.3 ou posterior Linux)
Processamento	Não se aplica	E/S assíncronas devem estar ativadas. Nos kernels Linux em 2.6 ou mais recente, instale a biblioteca libaio para ativar a E/S Assíncrona.
Navegador da Web	Um navegador da Web para recuperar um pacote de instalação on-line. Os navegadores a seguir são suportados: · Microsoft Internet Explorer 7.0 ou mais recente · Firefox 3.5 ou mais recente Seu navegador deve fornecer suporte à página de código do servidor. Se seu navegador não suportar a página de códigos do servidor, as janelas poderão estar ilegíveis. Se o navegador atender esses requisitos, mas não exibir corretamente uma interface do Tivoli Storage Manager baseada na Web, considere usar um navegador diferente.
Funções do Sistema	As funções do sistema Windows, como o Device Manager, são suportadas no Tivoli Storage Manager Console de 64 bits. Funções normais do sistema Windows estão disponíveis para o servidor de 64 bits usando a função Gerenciar Computador do sistema Windows.	Não se aplica
Outro software	Não se aplica	Korn Shell (ksh)

Verificando os Pré-requisitos

Existe um utilitário de verificação de Pré-requisitos de instalação. Este utilitário assegura que você tenha um ambiente mínimo para a implementação do servidor TSM.

O verificador de Pré-requisitos verifica somente o mínimo de memória necessário. Mais memória é requerida para tarefas adicionais (deduplicação, etc..).

Para executar o verificador de pré-requisitos (Windows\Linux), conclua as seguintes etapas:

1. Faça o download do pacote de instalação e extraia os arquivos. Um verificador de pré-requisitos é parte do pacote de instalação.

2. Escolha a interface gráfica (padrão) ou método do console para iniciar a instalação e siga as instruções do assistente para concluir a instalação:

Execute este comando para iniciar o assistente de instalação usando uma interface gráfica:

prereqcheck.exe (Windows)

./prereqcheck.bin (Linux)

Ou dê um clique duplo no arquivo prereqcheck.exe(Windows).

Execute este comando para iniciar o assistente de instalação usando o método de console:

prereqcheck.exe -i console (Windows)

./prereqcheck.bin -i console (Linux)

3. Selecione o idioma para a interface com o usuário do verificador dos pré-requisitos;

4. Nos painéis “bem-vindo” e “renúncia de responsabilidade”, revise as instruções e aceite-as.

Se a página de Resultados de Pré-requisito indicar que seu sistema transmitiu as verificações, você estará pronto para iniciar a instalação.

Se uma mensagem de erro for exibida na página Resultados de Pré-requisito, faça as correções requeridas antes de continuar com a instalação. A página de resumo lista os erros e direciona você para um arquivo de log de erros.

Planejamento de Capacidade

Planejar a capacidade para o servidor Tivoli Storage Manager inclui o gerenciamento de recursos. Esses recursos são:

Banco de dados (DB2);
Log de recuperação (active log, archive log).

Esses são os principais recursos do servidor TSM. Por esse motivo, você deve ter o extremo cuidado no dimensionamento de espaço para o banco de dados e dos logs de recuperação, pois se houver falta de espaço, fatalmente ocorrerá indisponibilidade no serviço.

Para entender os benefícios de deduplicação e obter mais orientações de como fazer uso efetivo do recurso de deduplicação do Tivoli Storage Manager, consulte este white paper publicado no fórum do developerWorks.

Estimando Espaço para o Banco de Dados – DB2

Há dois métodos para estimar o espaço necessário para o banco de dados (DB2):

1º - Usar o número máximo de arquivos que podem estar no armazenamento do servidor ao mesmo tempo;

2º - Usar a capacidade do conjunto de armazenamentos.

Considere utilizar pelo menos 25 GB para o espaço inicial do banco de dados.

Lembrando que 25 GB são adequados para um ambiente de teste ou um ambiente de gerenciador de bibliotecas somente. Para um servidor de produção suportando cargas de trabalho do cliente, espera-se que o tamanho do banco de dados seja maior. Se você for utilizar conjuntos de armazenamento de acesso aleatório ao disco (DISK), mais espaço de armazenamento de banco de dados e de log será necessário do que para os conjuntos de armazenamento de acesso sequencial (FILE).

O tamanho máximo do banco de dados do Tivoli Storage Manager é de 4 TB.

A seguir, irei detalhar como podemos obter informações sobre o dimensionamento do banco de dados em um ambiente de produção, com base no número de arquivos e no tamanho do conjunto de armazenamento.

Essas estimativas foram retiradas do IBM Tivoli Storage Manager para Windows: Guia de Instalação.

Todo o tópico a seguir foi transcrito “quase” que na íntegra, pois não há explicação melhor do que a dos próprios especialistas da IBM.

Estimando os requisitos de espaço do banco de dados com base no número de arquivos

Se você puder estimar o número máximo de arquivos que podem estar em armazenamento no servidor em dado momento (total de arquivos de todos os clientes armazenados no servidor TSM), será possível usar esse número para estimar os requisitos de espaço para o banco de dados.

Para estimar os requisitos de espaço para o banco de dados com base no número máximo de arquivos no armazenamento do servidor, use as seguintes diretrizes:

600 - 1000 bytes para cada versão armazenada de um arquivo.
100 - 200 bytes para cada arquivo em cachê; arquivo do conjunto de armazenamentos de cópias; arquivo de conjunto de dados ativos e arquivo deduplicado.
O espaço adicional é necessário para a otimização do banco de dados; para suportar padrões de acesso a dados variáveis e para suportar o processamento de backend do servidor dos dados. A quantidade de espaço adicional é igual a 50% da estimativa para o número total de bytes para objetos do arquivo.

No exemplo a seguir, para um único cliente, os cálculos são baseados nos valores máximos das diretrizes anteriores. Os cálculos não levam em conta o possível uso de agregação de arquivos. Em geral, agregar arquivos pequenos reduz a quantidade de espaço requerido do banco de dados. A agregação de arquivos não afeta os arquivos gerenciados por espaço.

1. Calcule o número de versões do arquivo:

a. Calcule o número de arquivos que sofreram backup (até 500.000 arquivos do cliente podem sofrer backup por vez). Atente-se à chamada das políticas de armazenamento para manter até três cópias de arquivos com backup feito:

500.000 arquivos x 3 copias = 1.500.000 arquivos

b. Calcule o número de arquivos no archive. Até 100.000 arquivos do cliente podem ser cópias de archive.

c. Calcule o número de arquivos gerenciados por espaço. Até 200.000 arquivos do cliente podem ser migrados a partir das estações de trabalho do cliente.

Usando 1000 bytes por arquivo, a quantidade total de espaço requerido no banco de dados para os arquivos que pertencem ao cliente é de 1.8 GB:

(1.500.000 + 100.000 + 200.000) x 1000 = 1.8 GB

2. Calcule o número de arquivos em cachê e copie os arquivos do conjunto de armazenamentos, arquivos do datapool ativo e arquivos deduplicados.

a. Calcule o número de cópias em cache. O armazenamento em cache é ativado em um conjunto de armazenamentos em disco de 5 GB. Os limites mínimo e máximo de migração do conjunto são 90% e 70%. Assim, 20% do conjunto de discos, ou 1 GB, é ocupado por arquivos em cache.

Se o tamanho médio do arquivo é de aproximadamente 10 KB, aproximadamente 100.000 arquivos estão em cache em um dado momento:

100.000 arquivos x 200 bytes = 19 MB

b. Calcule o número de arquivos do conjunto de armazenamentos de cópias. Todos os conjuntos de armazenamentos primários têm seu backup feito para o conjunto de armazenamentos de cópia:

(1.500.000 + 100.000 + 200.000) x 200 bytes = 343 MB

c. Calcule o número de arquivos do conjunto de armazenamentos ativos. Todos os dados ativos de backup do cliente, nos conjuntos de armazenamentos primários, são copiados para o conjunto de armazenamentos de dados ativos. Suponha que 500.000 versões dos 1.500.000 arquivos de backup do conjunto de armazenamento primário estejam ativas:

500.000 x 200 bytes = 95 MB

d. Calcule o número de arquivos deduplicados. Suponha que um conjunto de armazenamentos deduplicados contenha 50.000 arquivos:

50.000 x 200 bytes = 10 MB

Com base nos cálculos precedentes, aproximadamente 0.5 GB de espaço adicional do banco de dados é requerido para os arquivos em cache do cliente; arquivos do conjunto de armazenamentos de cópias; arquivos do conjunto de dados ativos e arquivos deduplicados.

3. Calcule a quantidade de espaço adicional requerido para otimização do banco de dados. Para fornecer acesso otimizado aos dados e gerenciamento pelo servidor, espaço adicional do banco de dados é requerido. A quantidade de espaço adicional do banco de dados é igual a 50% dos requisitos de espaço total para os objetos do arquivo.

(1.8 + 0.5) x 50% = 1.2 GB

4. Calcule a quantia total de espaço do banco de dados que é necessária para o cliente. O total é aproximadamente 3,5 GB:

1.8 + 0.5 + 1.2 = 3.5 GB

5. Calcule a quantidade total de espaço do banco de dados que é requerido para todos os clientes. Se o cliente que foi usado nos cálculos anteriores for típico e você tiver 500 clientes, por exemplo, será possível usar o seguinte cálculo para estimar a quantidade total de espaço de banco de dados requerida para todos os clientes:

500 x 3.5 = 1.7 TB

Dica: Nos exemplos anteriores, os resultados são estimativas. O tamanho real do banco de dados pode diferir da estimativa devido a fatores como o número de diretórios e o comprimento dos nomes do caminho e do arquivo. Periodicamente, monitore seu banco de dados e ajuste seu tamanho conforme necessário.

Durante operações normais, o servidor Tivoli Storage Manager pode requerer espaço temporário do banco de dados. Esse espaço é necessário pelas seguintes razões:

Para armazenar os resultados de classificação e ordenação que ainda não estão sendo guardados e otimizados no banco de dados diretamente. Os resultados são armazenados temporariamente no banco de dados para processamento.

Par dar acesso administrativo ao banco de dados por um dos seguintes métodos:

– Um cliente Open Database Connectivity (ODBC) do DB2;

– Um cliente do Java Database Connectivity (JDBC) do Oracle;

– Linguagem de Consulta Estruturada (SQL) para o servidor de uma linha de comandos do cliente administrativo.

Considere utilizar um espaço temporário adicional de 50 GB para cada 500 GB de espaço para objetos de arquivos e otimização.

Consulte as diretrizes na tabela a seguir.

Tamanho do banco de dados	Requisito de espaço temporário mínimo
< 500 GB	50 GB
≥ 500 GB e < 1 TB	100 GB
≥ 1 TB e < 1.5 TB	150 GB
≥ 1.5 e < 2 TB	200 GB
≥ 2 e < 3 TB	250 - 300 GB
≥ 3 e < 4 TB	350 - 400 GB

No exemplo usado neste tópico, um total de 1.7 TB de espaço do banco de dados é requerido para objetos de arquivos e otimização para 500 clientes. Com base nesse cálculo, 200 GB são requeridos para espaço temporário. A quantidade total de espaço requerido do banco de dados é de 1.9 TB.

Estimando requisitos de espaço do banco de dados com base na capacidade do conjunto de armazenamentos

Para estimar os requisitos de espaço no banco de dados com base na capacidade do conjunto de armazenamentos, use uma proporção de 1 a 5%.

Por exemplo, se você precisar de 200 TB de capacidade do conjunto de armazenamentos, espera-se que o tamanho de seu banco de dados seja de 2 a 10 TB. Como uma regra geral, torne seu banco de dados o maior possível para evitar falta de espaço. Se faltar espaço no banco de dados, as operações do servidor e as operações de armazenamento do cliente poderão falhar.

O Gerenciador de Banco de Dados e Espaço Temporário

O gerenciador de banco de dados do servidor Tivoli Storage Manager gerencia e aloca memória do sistema e espaço em disco para o banco de dados. A quantidade de espaço de banco de dados que o sistema necessita depende da quantidade de memória do sistema que está disponível e da carga de trabalho do servidor.

O gerenciador de banco de dados classifica dados em uma sequência específica, de acordo com a instrução SQL que você emite para solicitar os dados. Dependendo da carga de trabalho no servidor, e se houver mais dados do que o gerenciador de banco de dados pode gerenciar, os dados (que são ordenadas em sequência) serão alocados para espaço em disco temporário. Os dados são alocados para espaço em disco temporário quando há um conjunto de resultados grande. O gerenciador de banco de dados gerencia dinamicamente a memória utilizada quando os dados são alocados para espaço em disco temporário.

Por exemplo, o processamento de expiração pode produzir um conjunto de resultados grande. Se não houver memória do sistema suficiente no banco de dados para armazenar o conjunto de resultados, alguns dos dados serão alocados para espaço em disco temporário. Durante o processo de expiração, se um nó ou espaço no arquivo selecionado for muito grande para processar, o gerenciador de banco de dados não terá memória suficiente para classificar os dados.

Para executar operações do banco de dados, considere incluir mais espaço de banco de dados para os seguintes cenários:

O banco de dados tem uma pequena quantidade de espaço e a operação do servidor que requer espaço temporário usa o espaço livre restante.

Os espaços no arquivo são grandes ou os espaços no arquivo possuem uma política designada para ele que cria muitas versões de arquivos.

O servidor Tivoli Storage Manager deve executar com memória limitada. O banco de dados utiliza a memória principal do servidor Tivoli Storage Manager para executar operações do banco de dados. No entanto, se houver memória insuficiente disponível, o servidor Tivoli Storage Manager alocará espaço temporário em disco para o banco de dados. Por exemplo, se 10 GB de memória estiver disponível e as operações do banco de dados requererem 12 GB de memória, o banco de dados utilizará espaço temporário.

Um erro de “sem espaço de banco de dados” será exibido ao implementar um servidor Tivoli Storage Manager V6. Monitore o log de atividades do servidor para obter mensagens relacionadas ao espaço de banco de dados.

Bom, senhores (as), por hoje é isso! Desde já peço desculpas pelo longo post, mas o assunto não permite abreviações. No nosso próximo encontro, estarei abordando o seguinte tópico:

Dimensionamento do espaço dos Logs de recuperação (active log, archive log)

Até mais e um grande abraço.

Planejando, instalando e gerenciando o Tivoli Storage Manager

2013-03-09T20:11:00.000-03:00

Boa noite, caros leitores,

Hoje eu irei iniciar uma série de posts sobre a solução de backup Tivoli Storage Manager da IBM. Falo uma série, pois serão abordadas as três principais etapas de implementação do server (Windows e Linux) e as principais etapas dos clients (nodes).

Particularmente, sou suspeito de falar tanto de TSM quanto de IBM, pois são as minhas maiores paixões.

Já trabalhei com as principais ferramentas de backup disponíveis no mercado e afirmo que não há nada mais robusto e completo para grandes empresas (banco, Governo, telefônicas, etc...) como o TSM.

Pois bem, todos aqueles que já tiveram a oportunidade de implementar e trabalhar com os produtos da “Big Blue”, sabem que eles possuem uma base de conhecimento completa para todos os seus produtos. Mesmo assim, vejo inúmeros profissionais com problemas de planejar implementar e gerenciar o TSM devido a seu alto nível de complexidade.

Para aqueles que já trabalharam com outa solução de backup, muitos dos termos que serão utilizados nessa série de posts serão familiar. Mais há aqueles que efetivamente não possuem uma experiência profunda com backup/restore e estão com a árdua missão de aprender o mais rápido possível para que possam atender a necessidade de seu cliente ou de sua empresa, devido a uma nova implementação ou a uma mudança de trabalho.

Conforme disse anteriormente, alguns posts que escrevo são longos, esse fato se deve pelo o compromisso que eu tenho com vocês, leitores, de prover um material completo e de qualidade. Digo isso, porque de maneira nenhuma é intenção desse blog em passar “meio” conhecimento. Conhecimento é para todos e deve ser compartilhado de forma íntegra e direta, sem rodeios ou subterfúgios.

Eu sou Certificado na versão 6.2 do TSM e a IBM já está na versão 6.4 dos clients e 6.3.3 do server e essas serão as versão utilizadas para o desenvolvimento dos posts.

Estes posts sobre TSM serão divididos da seguinte forma:

1 - SERVIDOR TSM (Windows – Linux)

Conforme o Guia de Instalação TSM seguirei as três etapas

- Planejando a instalação;

- Instalação;

- Executando as primeiras etapas.

2 – CLIENTES DE BACKUP-ARCHIVE (Windows – Linux)

- Instalação;

- Configuração;

- Execução de backup/archive;

- Execução de restore.

Como todo o material deste blog, eu preparo o ambiente no meu laboratório e executo os procedimentos, para depois escrever, por esse motivo não irei abordar a instalação nos S.O AIX, HP-UX e Solaris e não estarei executando backup em storage pools de fitas em tape library, somente estarei utilizando storage pool em disco (file e disk).

Bom, meus amigos se preparem, pois virá bastante conteúdo e espero que venha trazer entendimento a todos sobre essa extraordinária solução.

Até mais e um grande abraço.

Criptografando arquirvos .txt

2013-03-06T01:16:00.000-03:00

Boa noite, caros leitores,

É muito comum realizarmos anotações em arquivo .txt (seja pelo bom e velho notepad ou por outro editor de texto).

O problema se dá quando essas anotações são dados sensíveis como login, senha, conta bancária, etc... e o usuário salva esse arquivo com os nomes mais sugestivos possíveis (senha, password, conta, login, etc...).

Nem é preciso dizer que estes sãos os primeiros arquivos procurados e copiados em caso de intrusão ou outra falha de segurança.

Uma boa alternativa para esses casos é criptografar o arquivo .txt.

Para isso siga os seguintes procedimentos:

- Baixe o programa LockNote;

- Crie o arquivo txt;

- Clique e arraste o arquivo txt em cima do LockNote.exe, que pedirá uma senha;

- Crie a senha.

Pronto, seu arquivo esta devidamente protegido! É claro que você deve criar uma senha forte, que protegerá esse arquivo, e não anotar essa senha em outro arquivo desprotegido.

Brincadeiras à parte, eu estou preparando um post sobre política de criação de senhas que em breve estarei disponibilizando aqui.

Até mais e um grande abraço.

Voucher gratuito para Certificação Brocade BCNE 150-130

2013-03-04T23:02:00.000-03:00

Boa noite, caros leitores,

É sempre bom preencher o curriculum com uma certificação e se essa certificação sair a custo zero é melhor ainda.

A empresa Brocade, gigante no seguimento de Network, está desde o ano passado ofertando vouchers para a realização da prova BCNE (Brocade Certified Network Engineer).

Para participar, basta acessar o site da Pearsonvue, realizar o cadastro, caso não possua, e agendar o exame 150-130. Na etapa do pagamento, no campo "Promo code", coloque CNE250BCNEPromo. Após a inserção do código, o custo do exame passará para 0$. A partir daí, e só estudar e realizar a prova.

Segue o conteúdo da prova:

Layer 1/Hardware Concepts

Identify physical media

Describe how to implement PoE/PoE+

Brocade Hardware Platforms

Identify Brocade hardware platforms

Describe how to implement hardware platforms and features

Layer 2 Switching and Protocols

Describe Layer 2 protocols

Identify Layer 2 functionality

Identify different VLAN implementations

Describe different link aggregation (LAG) implementations

General Layer 2/Layer 3 Concepts

Describe general routing and switching concepts

Routing Concepts

Describe general routing concepts

Describe how to implement the OSPF protocol

Describe multicast routing

Access Control List (ACL) Concepts

Describe ACL concepts

Quality of Service (QoS) Concepts

Describe QoS concepts

Network Security, Management and Monitoring

Describe the tools used to monitor a network

Describe the tools to manage a network

Demonstrate how to secure access to routers and switches

Describe maintenance procedures for switches and routers

Troubleshooting

Demonstrate knowledge of basic troubleshooting

Demonstrate the ability to analyze troubleshooting output

Material utilizado para estudo (número de página são os números das páginas do documento e não das páginas do PDF)

Brocade IP Primer

Páginas 22-33,45-53,68,173,182,186-188,210,220,237-242,245,246,250-251,318

Brocade Optics Family Datasheet (GA-DS-1344-03)

Brocade 1860 Fabric Adapter Datasheet (GA-DS-1566-00)

Deploying Brocade FastIron-based PoE and PoE+ Solutions in the Campus Network (GA-SG-170-01)

Páginas 5,12,13

Brocade FastIron v7.4 Configuration Guide (53-1002494-01)

Páginas LV,21,24-28,37,46,76,80,82,97,115,149,179,192,236-362,421-436,500,514,535,540,671,674,700,729,733,806,832,924,969,970,986,1028,1160,1234-1236,1455-1457,1501,1510,1511,1649,1650,1699,1705,1707,1708,1715,1734,1742,1782,1830,1842,1955,1963.1972,1979,2657

Brocade MLX Series and Page NetIron Family Configuration Guide (53-1002372-02)

Páginas 118,134,153,265,274,284,291,292,316,331,355,464,554,781-843,940,1080,1090,2622

Brocade FastIron, FCX, ICX, and TurboIron Diagnostic Reference 53-1002497-01

Páginas 1,147,151,1241

Todo o material está reunido e poderá ser baixado aqui.

Então, é aproveitar essa oportunidade e acrescentar conhecimento e conteúdo no curriculum.

Até mais e um grande abraço.

Instalando VMware Tools em S.O Linux (Red Hat/Debian)

2013-03-04T00:55:00.000-03:00

Boa noite, caros leitores,

Já faz algum tempo que a virtualização se tornou imperativo na Infraestrutura de TI, devido a redução de custo e a manutenção dos equipamentos necessários, seja no ambiente corporativo ou acadêmico.

E um dos sistemas mais utilizados é o vSphere/Workstation da VMware. E para que as virtual machines tenham sua performance/gerencia otimizada é necessária a instalação da suite VMware Tools.

Sem o VMware Tools as seguintes anomalias podem ser apresentadas:

- Baixa qualidade de vídeo

- Profundidade de cor inadequada

- Exibição incorreta de velocidade da rede

- Restrição no movimento do mouse

- Incapacidade de copiar e colar e arrastar e soltar arquivos

- Perda de áudio

O seguintes componentes são incluídos no VMware Tools:

- VMware Tools service

- VMware device drivers

- VMware user process

- VMware Tools control panel

A instalação no S.O Windows é totalmente simplificada, basta somente habilitar, através do vCenter/ESX/Workstation, e o deploy é automaticamente realizado.

Já no ambiente Linux, alguns procedimentos adicionais são exigidos.

Pré-requisitos:

- gcc

- kernel-devel

- make

- perl

1º - Habilitar através do vCenter/ESX/Workstation a instalação do VMware Tools;

2º - Montar o cdrom

3º - Instalar as dependências

4º - Descompactar o VMware Tools

5º - Executar script ./vmware-install.pl, se não for alterar os diretórios "default" e só concluir a instalação, conforme abaixo

Os procedimentos acima mencionados servem tanto para Red Hat e seus derivados, quanto para Debian e seus derivados. Todavia, para o Debian direfe o modo de instalação das dependências (apt-get install gcc kernel-devel make perl).

Espero que seja de grande utilidade e lembre-se sempre de instalar e atualizar (quando disponível) essa importante suíte.

Até mais e um grande abraço.

Post inicial

2013-03-03T00:13:00.000-03:00

Boa noite, caros leitores,

Este é o post inicial do novo projeto que estou empreendendo.

Há muito tempo, minha sábia mãe me aconselhou a publicar um blog, para poder compartilhar conhecimento e experiências adquiridas ao longo da minha carreira, mas sempre me sentia despreparado para exercer tal atribuição.

Hoje, com mais de sete anos envolvido ativamente nos mais diversos projetos de TI e com uma bagagem bastante sólida, penso que chegou a hora de contribuir com pessoas, que assim como eu, procuram ajuda em diversos sites e blogs.

Outro motivo que me encoraja, nessa nova empreitada, é a disseminação e solidificação do conhecimento, pois não tem forma melhor de aprender do que ensinar. Isso não é um simples "clichê", pois se você se torna capaz de transmitir um conhecimento de forma clara e concisa, é fato que esse mesmo conhecimento se torna parte do seu ser.

Espero que o maior número de pessoas se beneficie das informações, dicas, conselhos e tutoriais que serão postados.

Quero de antemão agradecer a todos que me apoiam (mãe, esposa, irmãos, amigos, colegas de profissão) e acima de tudo a Deus o autor e consumador da minha vida.