Rhel Isa PT BR

Red Hat Enterprise Linux 4
Introduo Administrao de Sistemas
Red Hat Enterprise Linux 4: Introduo Administrao de Sistemas Copyright 2005 por Red Hat, Inc.
Red Hat, Inc.
1801 Varsity Drive Raleigh NC 27606-2072 USA Telefone: +1 919 754 3700 Telefone: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Research Triangle Park NC 27709 USA
rhel-isa(PT)-4-Impresso-RHI (2004-08-25T17:11) Copyright 2005 Red Hat, Inc. Este material pode ser distribudo somente sob os termos e condies denidos na Open Publication License, verso 1.0 ou mais recente (a verso mais recente est disponvel em http://www.opencontent.org/openpub/). proibida a distribuio de verses substancialmente modicadas deste documento sem a permisso explcita do titular dos direitos autorais. proibida a distribuio total ou parcial do trabalho envolvido neste manual, em qualquer formato de livro (papel), para ns comerciais, sem a autorizao prvia do titular dos direitos autorais. Red Hat e o logo "Shadow Man" da Red Hat so marcas registradas da Red Hat, Inc. nos EUA e em outros pases. Todas as outras marcas referidas neste so de propriedade de seus respectivos titulares. O nmero do cdigo de segurana GPG em security@redhat.com : CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E
ndice
Introduo ............................................................................................................................................ i 1. Informaes especcas da arquitetura .................................................................................. i 2. Convenes de Documentos .................................................................................................. i 3. Ative Sua Assinatura............................................................................................................ iv 3.1. Prover um Login para a Red Hat ........................................................................... v 3.2. Prover Seu Nmero de Assinatura ......................................................................... v 3.3. Conectar Seu Sistema ............................................................................................ v 4. Mais por Vir .......................................................................................................................... v 4.1. Envie-nos Seu Feedback ........................................................................................ v 1. A Filosoa da Administrao de Sistemas.................................................................................... 1 1.1. Automatizar Tudo .............................................................................................................. 1 1.2. Documentar Tudo .............................................................................................................. 2 1.3. Comunique o Mximo Possvel ......................................................................................... 3 1.3.1. Informe aos Seus Usurios o Que Voc Far...................................................... 3 1.3.2. Informe aos Seus Usurios O Que Voc Est Fazendo....................................... 4 1.3.3. Informe aos Seus Usurios O Que Voc Fez ...................................................... 4 1.4. Conhea Seus Recursos ..................................................................................................... 5 1.5. Conhea Seus Usurios...................................................................................................... 6 1.6. Conhea Seu Negcio ........................................................................................................ 6 1.7. A Segurana No Pode ser Postergada .............................................................................. 6 1.7.1. Os Riscos da Engenharia Social ......................................................................... 7 1.8. Planejar com Antecedncia................................................................................................ 7 1.9. Espere o Inesperado ........................................................................................................... 8 1.10. Informaes Especcas do Red Hat Enterprise Linux ................................................... 8 1.10.1. Automao ........................................................................................................ 8 1.10.2. Documentao e Comunicao......................................................................... 9 1.10.3. Segurana ........................................................................................................ 10 1.11. Recursos Adicionais....................................................................................................... 10 1.11.1. Documentao Instalada ................................................................................. 11 1.11.2. Sites teis ....................................................................................................... 11 1.11.3. Livros Relacionados........................................................................................ 11 2. Monitoramento de Recursos ........................................................................................................ 13 2.1. Conceitos Bsicos ............................................................................................................ 13 2.2. Monitoramento do Desempenho do Sistema ................................................................... 13 2.3. Monitorando a Capacidade do Sistema............................................................................ 14 2.4. O Que Monitorar? ............................................................................................................ 14 2.4.1. Monitorando a Energia da CPU ........................................................................ 15 2.4.2. Monitorando a Largura de Banda ..................................................................... 16 2.4.3. Monitorando a Memria ................................................................................... 17 2.4.4. Monitorando o Armazenamento ....................................................................... 17 2.5. Informaes Especcas do Red Hat Enterprise Linux ................................................... 18 2.5.1. free .................................................................................................................. 18 2.5.2. top .................................................................................................................... 19 2.5.3. vmstat.............................................................................................................. 21 2.5.4. O Pacote Sysstat de Ferramentas de Monitoramento dos Recursos ................. 22 2.5.5. OProle ............................................................................................................. 26 2.6. Recursos Adicionais......................................................................................................... 29 2.6.1. Documentao Instalada ................................................................................... 29 2.6.2. Sites teis ......................................................................................................... 30 2.6.3. Livros Relacionados.......................................................................................... 30
3. Largura de Banda e Poder de Processamento............................................................................ 31 3.1. Largura de Banda ............................................................................................................. 31 3.1.1. Canais (buses) ................................................................................................... 31 3.1.2. Centrais de Dados (Datapaths).......................................................................... 32 3.1.3. Problemas Potenciais Relacionados Largura de Banda ................................. 32 3.1.4. Solues Potenciais Relacionadas Largura de Banda (Bandwidth)............... 33 3.1.5. Em Suma. . . ...................................................................................................... 33 3.2. Poder de Processamento .................................................................................................. 34 3.2.1. Fatos Sobre o Poder de Processamento ............................................................ 34 3.2.2. Consumidores do Poder de Processamento ...................................................... 34 3.2.3. Suprindo a Falta da uma CPU........................................................................... 35 3.3. Informaes Especcas do Red Hat Enterprise Linux ................................................... 38 3.3.1. Monitorando a Largura de Banda no Red Hat Enterprise Linux ...................... 38 3.3.2. Monitorando a Utilizao da CPU no Red Hat Enterprise Linux..................... 40 3.4. Recursos Adicionais......................................................................................................... 44 3.4.1. Documentao Instalada ................................................................................... 44 3.4.2. Sites teis ......................................................................................................... 44 3.4.3. Livros Relacionados.......................................................................................... 44 4. Memria Fsica e Virtual.............................................................................................................. 45 4.1. Padres de Acesso ao Armazenamento ........................................................................... 45 4.2. O Espectro do Armazenamento ....................................................................................... 45 4.2.1. Registradores de CPU ....................................................................................... 46 4.2.2. Memria Cache................................................................................................. 46 4.2.3. Memria Principal RAM ............................................................................. 47 4.2.4. Discos Rgidos .................................................................................................. 48 4.2.5. Armazenamento de Backup Off-Line ............................................................... 49 4.3. Conceitos da Memria Virtual Bsica ............................................................................. 49 4.3.1. Memria Virtual em Termos Simples ............................................................... 49 4.3.2. Backing Store a Doutrina Central da Memria Virtual ............................... 50 4.4. Memria Virtual: Os Detalhes ......................................................................................... 51 4.4.1. Falhas de Pgina ............................................................................................... 51 4.4.2. O Conjunto de Trabalho.................................................................................... 52 4.4.3. Swapping........................................................................................................... 52 4.5. Implicaes ao Desempenho da Memria Virtual ........................................................... 53 4.5.1. Cenrio do Desempenho no Pior Caso ............................................................. 53 4.5.2. Cenrio do Desempenho no Melhor Caso ........................................................ 53 4.6. Informaes Especcas do Red Hat Enterprise Linux ................................................... 54 4.7. Recursos Adicionais......................................................................................................... 56 4.7.1. Documentao Instalada ................................................................................... 57 4.7.2. Sites teis ......................................................................................................... 57 4.7.3. Livros Relacionados.......................................................................................... 57 5. Administrando o Armazenamento .............................................................................................. 59 5.1. Uma Viso Geral do Hardware de Armazenamento........................................................ 59 5.1.1. Pratos de Disco ................................................................................................. 59 5.1.2. Dispositivo de acesso/gravao de dados.......................................................... 59 5.1.3. Braos de Acesso .............................................................................................. 60 5.2. Conceitos de Endereamento do Armazenamento .......................................................... 61 5.2.1. Mapeamento Baseado na Geometria ................................................................ 61 5.2.2. Mapeamento Baseado no Bloco........................................................................ 63 5.3. Interfaces do Dispositivo de Armazenamento em Massa ................................................ 63 5.3.1. Histrico............................................................................................................ 63 5.3.2. Interfaces Padro de Hoje ................................................................................. 64 5.4. Caractersticas de Desempenho do Disco Rgido ............................................................ 67 5.4.1. Limitaes Mecnicas/Eltricas........................................................................ 67 5.4.2. Cargas I/O e Desempenho ................................................................................ 68
5.5. Tornando o Armazenamento Utilizvel ........................................................................... 70 5.5.1. Parties/Fatias ................................................................................................. 70 5.5.2. Sistemas de Arquivo ......................................................................................... 71 5.5.3. Estrutura de Diretrio ....................................................................................... 74 5.5.4. Habilitando Acesso ao Armazenamento........................................................... 74 5.6. Tecnologias de Armazenamento Avanado ..................................................................... 75 5.6.1. Armazenamento Acessvel via Rede ................................................................ 75 5.6.2. Armazenamento Baseado no RAID.................................................................. 76 5.6.3. Administrao de Volume Lgico (Logical Volume Management) ................. 81 5.7. Administrao Diria do Armazenamento....................................................................... 82 5.7.1. Monitorando Espao Livre ............................................................................... 82 5.7.2. Questes de Quota de Disco ............................................................................. 85 5.7.3. Questes Relativas a Arquivos.......................................................................... 86 5.7.4. Adicionando/Removendo Armazenamento ...................................................... 87 5.8. Um Pouco Sobre Backups. . . ........................................................................................... 93 5.9. Informaes Especcas do Red Hat Enterprise Linux ................................................... 93 5.9.1. Conveno de Nomenclatura de Dispositivos................................................... 93 5.9.2. Conceitos Bsicos do Sistema de Arquivo ....................................................... 96 5.9.3. Montando Sistemas de Arquivo ........................................................................ 98 5.9.4. Armazenamento Acessvel pela Rede Sob o Red Hat Enterprise Linux ........ 101 5.9.5. Montando Sistemas de Arquivo Automaticamente com /etc/fstab .......... 101 5.9.6. Adicionando/Removendo Armazenamento .................................................... 102 5.9.7. Implementando Quotas de Disco .................................................................... 106 5.9.8. Criando Conjuntos RAID ............................................................................... 110 5.9.9. Administrao Diria de Conjuntos RAID ..................................................... 112 5.9.10. Administrao de Volume Lgico (Logical Volume Management) ............. 113 5.10. Recursos Adicionais..................................................................................................... 113 5.10.1. Documentao Instalada ............................................................................... 113 5.10.2. Sites teis ..................................................................................................... 114 5.10.3. Livros Relacionados...................................................................................... 114 6. Administrando Contas de Usurio e Acesso a Recursos ......................................................... 115 6.1. Administrando Contas de Usurio ................................................................................. 115 6.1.1. O Nome de Usurio ........................................................................................ 115 6.1.2. Senhas ............................................................................................................. 118 6.1.3. Informaes de Controle de Acesso ............................................................... 122 6.1.4. Administrando Contas e Acesso a Recursos no Dia-a-Dia............................. 123 6.2. Administrando Recursos do Usurio ............................................................................. 125 6.2.1. Quem Pode Acessar Dados Compartilhados .................................................. 125 6.2.2. Onde os Usurios Acessam os Dados Compartilhados .................................. 126 6.2.3. Quais so as Barreiras Adotadas para Evitar o Abuso de Recursos ............... 127 6.3. Informaes Especcas do Red Hat Enterprise Linux ................................................. 127 6.3.1. Contas de Usurio, Grupos e Permisses ....................................................... 127 6.3.2. Arquivos que Controlam Contas de Usurio e Grupos................................... 129 6.3.3. Aplicaes de Conta de Usurio e Grupo ....................................................... 133 6.4. Recursos Adicionais....................................................................................................... 134 6.4.1. Documentao Instalada ................................................................................. 134 6.4.2. Sites teis ....................................................................................................... 135 6.4.3. Livros Relacionados........................................................................................ 135
7. Impressoras e Impresso ............................................................................................................ 137 7.1. Tipos de Impressoras ..................................................................................................... 137 7.1.1. Consideraes de Impresso ........................................................................... 137 7.2. Impressoras de Impacto ................................................................................................. 138 7.2.1. Impressoras Matriciais .................................................................................... 138 7.2.2. Impressoras Margarida.................................................................................... 139 7.2.3. Impressoras de Linha ...................................................................................... 139 7.2.4. Consumveis de Impressoras de Impacto........................................................ 139 7.3. Impressoras Jato de Tinta............................................................................................ 140 7.3.1. Consumveis das Impressoras Jato de Tinta................................................. 140 7.4. Impressoras Laser........................................................................................................ 140 7.4.1. Impressoras Laser Coloridas ........................................................................ 141 7.4.2. Consumveis da Impressora Laser ............................................................... 141 7.5. Outros Tipos de Impressora ........................................................................................... 141 7.6. Linguagens e Tecnologias de Impressoras..................................................................... 142 7.7. Impressoras em Rede Versus Locais.............................................................................. 143 7.8. Informaes Especcas do Red Hat Enterprise Linux ................................................. 143 7.9. Recursos Adicionais....................................................................................................... 145 7.9.1. Documentao Instalada ................................................................................. 145 7.9.2. Sites teis ....................................................................................................... 145 7.9.3. Livros Relacionados........................................................................................ 145 8. Planejamento para Desastres..................................................................................................... 147 8.1. Tipos de Desastres ......................................................................................................... 147 8.1.1. Falhas de Hardware......................................................................................... 147 8.1.2. Falhas de Software .......................................................................................... 152 8.1.3. Falhas no Ambiente ........................................................................................ 155 8.1.4. Erros Humanos................................................................................................ 161 8.2. Backups.......................................................................................................................... 165 8.2.1. Dados Diferentes: Necessidades Diferentes de Backup ................................. 165 8.2.2. Software de Backup: Comprar versus Criar ................................................... 167 8.2.3. Tipos de Backups ............................................................................................ 168 8.2.4. Mdia de Backup ............................................................................................. 169 8.2.5. Armazenamento de Backups........................................................................... 171 8.2.6. Questes de Restaurao................................................................................. 171 8.3. Recuperao de Desastres.............................................................................................. 172 8.3.1. Criando, Testando e Implementando um Plano de Recuperao de Desastres173 8.3.2. Locais de Backup: Frios, Mornos e Quentes .................................................. 174 8.3.3. Disponibilidade de Hardware e Software ....................................................... 175 8.3.4. Disponibilidade de Backups ........................................................................... 175 8.3.5. Conectividade de Rede ao Site de Backup...................................................... 175 8.3.6. Funcionrios do Site de Backup ..................................................................... 175 8.3.7. Voltando Normalidade ................................................................................. 176 8.4. Informaes Especcas do Red Hat Enterprise Linux ................................................. 176 8.4.1. Suporte ao Software........................................................................................ 176 8.4.2. Tecnologias de Backup ................................................................................... 176 8.5. Recursos Adicionais....................................................................................................... 180 8.5.1. Documentao Instalada ................................................................................. 180 8.5.2. Sites teis ....................................................................................................... 180 8.5.3. Livros Relacionados........................................................................................ 180 ndice Remissivo.............................................................................................................................. 183 Consideraes nais........................................................................................................................ 191
Introduo
Bem-vindo ao manual Introduo Administrao de Sistemas Red Hat Enterprise Linux. O Introduo Administrao de Sistemas Red Hat Enterprise Linux contm informaes introdutrias para novos administradores de sistemas Red Hat Enterprise Linux. Este manual no ensina a executar uma tarefa especca sob o Red Hat Enterprise Linux. Ao invs disso, traz o conhecimento acumulado ao longo dos anos por diversos administradores de sistemas experientes. Este manual assume que voc tem uma experincia limitada como usurio do Linux, mas nenhuma experincia como administrador de sistemas Linux. Se o Linux for completamente novo para voc (e o Red Hat Enterprise Linux especicamente), deve comear adquirindo um livro introdutrio sobre o Linux. Cada captulo do Introduo Administrao de Sistemas Red Hat Enterprise Linux tem a seguinte estrutura:

Viso geral Esta seo aborda o tpico do captulo sem entrar em detalhes sobre um sistema operacional, tecnologia ou metodologia especca. Material especco do Red Hat Enterprise Linux Esta seo aborda os aspectos do tpico relacionados ao Linux em geral e ao Red Hat Enterprise Linux em particular. Recursos Adicionais para estudos mais profundos Esta seo inclui indicadores para outros manuais do Red Hat Enterprise Linux, sites teis e livros contendo informaes relacionadas ao tpico.
Ao adotar uma estrutura consistente, os leitores podem acessar o Introduo Administrao de Sistemas Red Hat Enterprise Linux da forma que quiserem. Por exemplo: um administrador de sistemas experiente com pouco conhecimento do Red Hat Enterprise Linux, pode abordar somente as sees focadas no Red Hat Enterprise Linux, enquanto um novo administrador de sistemas pode comear lendo somente as sees de informaes gerais e usar as sees especcas do Red Hat Enterprise Linux como uma introduo a recursos mais profundos. E por falar em recursos mais profundos, o Guia de Administrao de Sistemas Red Hat Enterprise Linux um recurso excelente para executar tarefas especcas num ambiente Red Hat Enterprise Linux. Os administradores que quiserem ter informaes mais factuais e aprofundadas, devem consultar o Guia de Referncia do Red Hat Enterprise Linux. As verses HTML, PDF e RPM dos manuais esto disponveis no CD de Documentao do Red Hat Enterprise Linux e online: http://www.redhat.com/docs/.
Nota Apesar deste manual reetir as informaes mais recentes possveis, leia as Notas da Verso do Red Hat Enterprise Linux para acessar as informaes que no estavam disponveis antes da nalizao de nossa documentao. Elas podem ser encontradas no CD 1 do Red Hat Enterprise Linux e online: http://www.redhat.com/docs/.
1. Informaes especcas da arquitetura

Exceto quando informado, todas as informaes contidas neste manual se aplicam somente ao processador x86 e aos processadores com as tecnologias Intel Extended Memory 64 Technology (EM64T da Intel) e AMD64. Para obter informaes de arquiteturas especcas, consulte o Guia de Instalao do Red Hat Enterprise Linux.
ii
Introduo
2. Convenes de Documentos
Ao ler este manual, determinadas palavras esto representadas com fontes, tipos, tamanhos e pesos diferentes. Este destaque sistemtico; palavras diferentes so representadas no mesmo estilo para indicar sua incluso em uma categoria especca. Os tipos de palavras representadas desta maneira incluem as seguintes:
comando
Os comandos do Linux (e comandos de outros sistemas operacionais, quando usados) so representados desta maneira. Este estilo indica que voc pode digitar a palavra ou frase na linha de comandos e pressionar [Enter] para invocar um comando. s vezes o comando contm palavras que sero exibidas em um estilo diferente por si s (como nomes de arquivos). Nestes casos, estas so consideradas parte do comando, e ento a frase inteira ser exibida como um comando. Por exemplo: Use o comando cat testfile para visualizar o contedo de um arquivo chamado testfile, no diretrio de trabalho atual.
nome do arquivo
Nomes de arquivos, diretrios, localidades de arquivos e nomes de pacotes RPM so representados desta maneira. Este estilo indica que existe um determinado arquivo ou diretrio com aquele nome no seu sistema. Exemplos: O arquivo .bashrc do seu diretrio home contm denies da janela de comandos tipo bash e codenomes para seu uso pessoal. O arquivo /etc/fstab contm informaes sobre os dispositivos e sistemas de arquivo diferentes do sistema. Instale o RPM webalizer se voc quiser usar um programa de anlise do arquivo de registro do servidor Web. aplicao Este estilo indica que o programa uma aplicao direcionada ao usurio nal (ao contrrio do software do sistema). Por exemplo: Use o Mozilla para navegar na Web. [tecla] Uma tecla do teclado exibida neste estilo. Por exemplo: Para usar a tecla complementar [Tab] num terminal, digite um caractere e ento pressione a tecla [Tab]. Seu terminal exibe uma lista dos arquivos contidos no diretrio que comeam com esta letra. [tecla]-[combinao] Uma combinao de sequncia de teclas representada desta maneira. Por exemplo: A combinao de teclas [Ctrl]-[Alt]-[Espao] termina sua sesso grca, retornando tela ou ao console da autenticao grca. texto exibido em uma interface GUI (grca) Um ttulo, palavra ou frase na tela ou janela da interface GUI exibida neste estilo. O texto exibido neste estilo usado na identicao de uma tela GUI especca ou um elemento de uma tela GUI (como o texto associado a uma caixa de vericao ou campo). Exemplo: Selecione a caixa de vericao Solicitar Senha se voc deseja que seu protetor de tela solicite uma senha antes de ser desbloqueado.
Introduo nvel superior de um menu em uma tela ou janela GUI
iii
Uma palavra neste estilo indica que a palavra est no nvel superior de um menu suspenso (pulldown menu). Se voc clicar na palavra na tela GUI, o resto do menu dever aparecer. Por exemplo: Abaixo de Arquivo em um terminal do GNOME, voc ver a opo Nova Aba, que permite a voc abrir diversos prompts de comando na mesma janela. Se voc precisar digitar uma sequncia de comandos a partir de um menu GUI, eles so exibidos como o exemplo a seguir: V para Boto do Menu Principal (no Painel) => Programao => Emacs para iniciar o editor de texto Emacs. boto em uma tela ou janela GUI Este estilo indica que o texto pode ser encontrado em um boto clicvel de uma tela GUI. Por exemplo: Clique no boto Voltar para retornar ltima pgina web que voc visitou.
output do computador
Texto neste estilo indica o texto exibido em uma janela de comandos, como mensagens de erro e respostas a comandos. Por exemplo: O comando ls exibe o contedo de um diretrio:
Desktop Mail about.html backupfiles logs mail paulwesterberg.png reports
O output exibido em resposta ao comando (neste caso, o contedo do diretrio) apresentado neste estilo.
prompt
Um prompt (ou janela de comandos), uma forma computacional de dizer que o computador est pronto para voc inserir algo (input), ser exibido desta maneira. Exemplos:
$ # [stephen@maturin stephen]$ leopard login:
input do usurio O texto que o usurio precisa digitar, na linha de comandos ou em uma caixa de texto em uma tela GUI, apresentado neste estilo. No exemplo a seguir, text exibido neste estilo: Para inicializar seu sistema no programa de instalao em modo texto, voc deve digitar o comando text no prompt boot:. substituvel Texto usado para exemplos que devem ser subtitudos com dados providos pelo usurio so apresentados neste estilo. No exemplo a seguir, version-number exibido neste estilo:
Adicionalmente, ns utilizamos diversas estratgias diferentes para chamar sua ateno a determinadas partes da informao. De acordo com o quo crucial as informaes so para seu sistema, elas so apresentadas como uma nota (lembrete), dica, importante, ateno ou um aviso. Por exemplo:
diretrio da fonte do kernel /usr/src/ version-number /, version-number a verso do kernel instalado neste sistema.
onde
iv
Introduo
Nota Lembre-se que o Linux sensvel a maisculas e minsculas. Em outras palavras, uma rosa no uma ROSA nem uma rOsA.
Dica O diretrio /usr/share/doc/ contm documentao adicional para os pacotes instalados em seu sistema.
Importante Se voc modicar o arquivo de congurao do DHCP, as alteraes no tero efeito at que voc reinicie o daemon do DHCP.
Ateno No execute tarefas de rotina como root use uma conta de usurio comum, a no ser que voc precise usar a conta root para tarefas de administrao do sistema.
Aviso Cuidado para remover somente as parties necessrias do Red Hat Enterprise Linux. Remover outras parties pode resultar na perda de dados ou num ambiente de sistema corrompido.
3. Ative Sua Assinatura

Antes de poder acessar as informaes de manuteno do software e servios, e a documentao de suporte inclusa em sua assinatura, voc deve ativar sua assinautra registrando-a na Red Hat. O registro inclui estes passos simples:

Prover um login para a Red Hat Prover um nmero para a assinatura Conectar seu sistema
Na primeira vez que iniciar a instalao de seu Red Hat Enterprise Linux, voc ver o pedido de registro na Red Hat usando o Agente de Congurao. Se voc seguir os pedidos durante o Agente de Congurao, poder completar os passos do registro e ativar sua assinatura.
Introduo
Se voc no puder completar o registro durante o Agente de Congurao (que requer acesso rede), pode, alternativamente, completar o processo de registro da Red Hat online: http://www.redhat.com/register/.
3.1. Prover um Login para a Red Hat

Se voc ainda no possui um login para a Red Hat, pode cri-lo quando for solicitado no Agente de Congurao ou online em:
https://www.redhat.com/apps/activate/newlogin.html
Um login da Red Hat habilita seu acesso a:

Atualizaes, erratas e manuteno do software atravs da Red Hat Network Recursos do suporte tcnico, documentao e base de dados de conhecimento (knowledgebase) da Red Hat
Se voc esqueceu seu login da Red Hat, pode fazer uma busca online em:
https://rhn.redhat.com/help/forgot_password.pxt
3.2. Prover Seu Nmero de Assinatura

Seu nmero de assinatura est localizado no pacote que acompanha seu pedido. Caso seu pacote no inclua um nmero de assinatura, sua assinautra j foi ativada e, portanto, voc pode pular este passo. Voc pode prover seu nmero de assinatura ao ser solicitado durante o Agente de Congurao ou visitando http://www.redhat.com/register/.
3.3. Conectar Seu Sistema

O Cliente de Registro da Red Hat Network auxilia na conexo de seu sistema para que voc possa obter as atualizaes e efetuar a administrao de sistemas. H trs maneiras para conectar: 1. Durante o Agente de Congurao Selecione as opes Enviar informaes de hardware e Enviar lista de pacotes do sistema quando aparecerem. 2. Aps completar o Agente de Congurao No Menu Principal, clique em Ferramentas do Sistema, e ento selecione Red Hat Network. 3. Aps completar o Agente de Congurao Invoque o seguinte na janela de comandos como usurio root:
/usr/bin/up2date --register
4. Mais por Vir

O Introduo Administrao de Sistemas Red Hat Enterprise Linux parte do crescente comprometimento da Red Hat em prover suporte til e oportuno aos usurios do Red Hat Enterprise Linux. Juntamente ao lanamento de novas verses do Red Hat Enterprise Linux, ns depositamos todos os nossos esforos para incluir documentao nova e atualizada para voc.
vi
Introduo
4.1. Envie-nos Seu Feedback

Se voc encontrar um erro de digitao no Introduo Administrao de Sistemas Red Hat Enterprise Linux, ou se voc encontrou uma maneira de melhorar este manual, ns adoraramos saber. Por favor, submeta um relatrio no Bugzilla (http://bugzilla.redhat.com/bugzilla) sobre o componente rhel-isa. Certique-se de mencionar o identicador do manual:
rhel-isa(PT)-4-Impresso-RHI (2004-08-25T17:11)
Se voc mencionar o identicador, ns saberemos exatamente qual verso do guia voc possui. Se voc tiver alguma sugesto para melhorar a documentao, tente ser o mais especco possvel. Se encontrar um erro, por favor inclua o nmero da seo e um trecho do texto prximo ao erro para que possamos localiz-lo facilmente.
Captulo 1.
A Filosoa da Administrao de Sistemas
Apesar das particularidades de um administrador de sistemas variarem de acordo com a plataforma, h questes bsicas que no variam. Estas questes compoem a losoa da administrao de sistemas. As questes so:

Automatizar tudo Documentar tudo Comunicar o mximo possvel Conhecer seu recursos Conhecer seus usurios Conhecer seu negcio A segurana no pode ser postergada Planejar com antecedncia Espere o inesperado
As sees seguintes exploram cada uma das questes em detalhes.
1.1. Automatizar Tudo

A maioria dos administradores de sistemas sobrecarregado seja pelos seus usurios, pelos seus sistemas ou por ambos. Em muitos casos, a automao a nica sada. Em geral, qualquer atividade executada mais de uma vez deve ser analisada como uma possvel candidata para automao. Aqui esto algumas tarefas comumente automatizadas:

Vericao e relatrio do espao livre em disco Backups Coleta de dados sobre o desempenho do sistema Manuteno da conta do usurio (criao, remoo, etc) Funes especcas a negcios mensais/quadrimestrais/anuais, etc) (envio de dados a um servidor Web, relatrios
Esta lista no est completa; as funes automatizadas por administradores de sistemas so limitadas somente pela vontade do administrador em escrever os scripts necessrios. Neste caso, ser preguioso (e deixar todo o trabalho mundano para o computador) uma coisa boa. A automao tambm oferece aos usurios o benefcio extra de prever melhor a consistncia dos servios.
Dica Tenha em mente que, se voc tiver que automatizar uma tarefa, provvel que voc no seja o primeiro administrador de sistemas com essa necessidade. aqui que os benefcios do software livre se sobressaem voc pode alavancar o trabalho que outra pessoa teve em automatizar o
Captulo 1. A Filosoa da Administrao de Sistemas

trabalho manual que atualmente consome seu tempo. Portanto, sempre busque na Internet antes de escrever qualquer coisa mais complexa que um script Perl.
1.2. Documentar Tudo

Se tivesse a opo de instalar um servidor novinho ou escrever um documento de procedimentos sobre a execuo de backups do sistema, o administrador de sistemas mediano instalaria o servidor novo toda vez. Apesar disso ser bastante comum, voc deve documentar o que faz. Muitos administradores de sistemas deixam de documentar seus procedimentos por diversas razes: "Mais tarde eu fao." Infelizmente, isto no verdade na maioria das vezes. Mesmo se o administrador de sistemas no estiver brincando, a natureza do trabalho faz com que as atividades do cotidiano tornem-se muito caticas para "fazer mais tarde." Pior ainda, quanto mais a tarefa adiada, mais esquecida, levando produo de um documento menos detalhado (e portanto menos til). "Por qu anotar? Eu vou lembrar." A no ser que voc seja uma daquelas pessoas com memria fotogrca, voc no lembrar. Ou pior, lembrar somente metade, sem perceber que est esquecendo a histria toda. Isto acarreta em tempo perdido na tentativa de re-aprender o que voc esqueceu ou consertar o que voc quebrou devido a seu entendimento incompleto da situao. "Seu eu manter na minha mente, eles no podero me despedir terei estabilidade no emprego!" Apesar disto poder funcionar por um tempo, invariavelmente acarreta em menor e no maior estabilidade de emprego. Por um momento, pense no que pode ocorrer durante uma emergncia. Voc pode no estar disponvel; sua documentao pode salvar o dia se instruir algum a resolver o problema durante sua ausncia. E lembre-se que as emergncias tendem a ocorrer com mais frequncia quando a alta gerncia presta ateno. Nestes casos, melhor sua documentao ser parte da soluo do que sua ausncia ser parte do problema. Alm disso, se voc faz parte de uma pequena empresa em expanso, pode surgir a necessidade de outro administrador de sistemas. Como esta pessoa pode aprender a te cobrir se est tudo na sua cabea? Pior ainda, sem documentao, voc pode ser to indispensvel a ponto de no poder avanar na sua carreira. Voc pode acabar trabalhando para aquela pessoa que contratou para ajud-lo. Esperamos que agora voc esteja convencido dos benefcios da documentao de sistemas. Isto nos leva questo seguinte: O qu voc deve documentar? Aqui est uma lista parcial: Normas As normas so elaboradas para formalizar e claricar sua relao com a comunidade de usurios. Elas explicam aos seus usurios como voc lida com seus pedidos de recursos e/ou assistncia. A natureza, o estilo e o mtodo de disseminao das normas para sua comunidade variam de empresa a empresa. Procedimentos Os procedimentos so qualquer sequncia passo-a-passo das aes para realizar uma determinada tarefa. Os procedimentos a serem documentados podem incluir procedimentos de backup, procedimentos para administrao de contas de usurios, procedimentos para relatrio de problemas e assim por diante. Como na automao, se um procedimento seguido mais de uma vez, uma boa idia document-lo.
Captulo 1. A Filosoa da Administrao de Sistemas Alteraes
Uma grande parte da carreira de um administrador de sistemas dedicada s alteraes congurar sistemas para o mximo desempenho, ajustar scripts, modicar arquivos de congurao e assim por diante. Todas estas alteraes devem ser documentadas de alguma forma. Caso contrrio, voc pode encontrar-se numa situao muito confusa devido uma alterao feita h vrios meses. Algumas empresas utilizam mtodos mais complexos para registrar as alteraes, mas, muitas vezes, basta apenas ter uma reviso da histria no incio do arquivo sendo modicado. Cada entrada da histria revisada deve conter, no mnimo:

O nome ou as iniciais da pessoa efetuando a alterao A data da alterao A razo da alterao
Isso resulta em entradas concisas, porm teis: ECB, 12-Junho-2002 Item atualizado para a nova impressora de Contabilidade (para suportar a substituio da habilidade em imprimir duplex)
1.3. Comunique o Mximo Possvel

Quando se trata de seus usurios, no h comunicao demasiada. Tenha em mente que pequenas alteraes de sistemas que voc pensa ser nmas podem confundir totalmente o assistente administrativo de Recursos Humanos. O mtodo atravs do qual voc se comunica com seus usurios pode variar de acordo com a sua empresa. Agumas empresas usam e-mail; outras usam um site interno. Algumas ainda utilizam Usenet ou IRC. Em algumas empresas suciente colocar um comunicado no mural da sala de funcionrios. Em qualquer um dos casos, use o(s) mtodo(s) ecaz(es) em sua organizao. Em geral, melhor utilizar esta ttica usada para escrever artigos de jornal: 1. Informe aos seus usurios o que voc far 2. Informe aos seus usurios o que voc est fazendo 3. Informe aos seus usurios o que voc fez As sees a seguir trazem mais detalhes sobre estes passos.
1.3.1. Informe aos Seus Usurios o Que Voc Far

Certique-se de prover suciente avisos aos seus usurios antes de fazer qualquer coisa. A quantidade de avisos varia necessariamente de acordo com o tipo de alterao (fazer o upgrade de um sistema operacional demanda mais tempo que alterar a cor default da tela de login do sistema), e tambm com a natureza da sua comunidade de usurios (usurios com perl mais tcnico geralmente adaptam-se mais rapidamente s alteraes que usurios com poucas ou nenhuma caracterstica tcnica.) Voc deve descrever, no mnimo:

A natureza da alterao Quando a alterao ocorrer Porque est ocorrendo Quanto tempo deve levar, aproximadamente O impacto (se houver) que os usurios podem esperar devido a alterao
Captulo 1. A Filosoa da Administrao de Sistemas Informaes de contato caso tenham dvidas ou problemas
Eis uma situao hipottica. O departamento de nanas est enfrentando problemas de lentido em seu servidor de banco de dados. Voc desligar o servidor, atualizar (upgrade) o mdulo da CPU para um modelo mais veloz e o reinicializar. Uma vez terminado, voc mover o banco de dados para um armazenamento mais rpido baseado no RAID. Aqui est um possvel comunicado para essa situao:
Atualizao do Sistema na Sexta Noite

A partir desta sexta-feira s 18hs (meia-noite para nossos funcionrios do escritrio em Berlim), todas as aplicaes nanceiras estaro indisponveis por aproximadamente quatro horas. Durante este perodo, sero executadas alteraes no hardware e software do banco de dados de nanas. Estas alteraes devem reduzir drasticamente o tempo necessrio para rodar as aplicaes de Contas a Pagar, Contas a Receber, e tambm o relatrio de Balano Semanal. Alm do tempo fora do ar, a maioria das pessoas no deve notar outras alteraes. No entanto, aqueles que elaboraram suas prprias consultas ao SQL devem estar cientes que o layout de alguns ndices ser alterado. Estas alteraes esto documentadas na intranet da empresa, na pgina de Finanas. Caso vocs tenham alguma dvida ou comentrio, favor contatar o Administrador de Sistemas no ramal 4321.
Alguns pontos devem ser lembrados:

Comunique efetivamente o incio e a durao de qualquer tempo fora do ar que possa estar envolvido na alterao. Certique-se de informar a hora da alterao de maneira ecaz a todos os usurios, independente de suas localidades. Use termos que seus usurios entendam. As pessoas impactadas por esta mudana no se importam se o novo modelo da CPU uma unidade de 2GHz com o dobro de memria cache L2, ou se o banco de dados alocado num volume lgico RAID 5.
1.3.2. Informe aos Seus Usurios O Que Voc Est Fazendo

Este passo basicamente um aviso de ltima hora da alterao prestes a ocorrer e, como tal, deve ser uma breve repetio da primeira mensagem, porm com a iminncia da alterao mais aparente ("A atualizao do sistema ocorrer HOJE NOITE."). Esta tambm uma boa oportunidade para responder publicamente quaisquer perguntas que voc tenha recebido como resultado da primeira mensagem. Dando continuidade ao nosso exemplo hipottico, aqui est uma sugesto para o aviso de ltima hora:
Atualizao do Sistema Programada para Hoje Noite

Lembrete: A atualizao anunciada na ltima segunda-feira ocorrer conforme programada, hoje s 18hs (meia-noite para o escritrio de Berlim). Voc pode conferir o comunicado original na intranet, na pgina de Administrao de Sistemas. Diversas pessoas perguntaram se deveriam parar de trabalhar mais cedo hoje noite para garantir que seus trabalhos tenham backup antes da atualizao. Isto no ser necessrio, visto que a atualizao dos sistemas de hoje noite no impactar nenhuma tarefa efetuada em suas estaes de trabalho. Lembrem-se: aqueles que elaboraram suas prprias consultas ao SQL devem saber que o layout de alguns ndices ser alterado. Isto est documentado na intranet da empresa, na pgina de Finanas.
Seus usurios foram alertados; agora voc est pronto para efetuar a atualizao em si.
1.3.3. Informe aos Seus Usurios O Que Voc Fez

Aps nalizar suas alteraes, voc deve informar aos seus usurios o que voc fez. Novamente, esta deve ser um resumo das suas mensagens anteriores (com certeza, algum deixou de l-las.) 1 Entretanto, h algo importante a acrescentar. vital informar seus usurios sobre o estado atual do sistema. A atualizao no ocorreu conforme esperado? O novo servidor de armazenamento serve apenas sistemas de Engenharia e no de Finanas? Este tipo de questes deve ser mencionado aqui. Obviamente, se o estado atual difere do que voc comunicou anteriormente, voc deve claricar este ponto e descrever o que ser feito (se houver medidas determinadas) para atingir a soluo nal. Em nossa situao hipottica, a atualizao teve alguns problemas. O novo modelo de CPU no funcionou; uma ligao ao fabricante revelou que necessria uma nova verso do mdulo para atualizaes deste tipo. No aspecto positivo, a migrao do banco de dados ao volume RAID foi executada com sucesso (apesar de ter demorado um pouco mais devido a problemas com o mdulo da CPU.) Aqui est uma sugesto de comunicado:
Atualizao do Sistema Completa

A atualizao de sistema programada para sexta-feira noite (consulte a pgina de Administrao de Sistemas na intranet) foi completa. Infelizmente, questes relacionadas ao hardware impediram que uma das tarefas fosse completa. Devido este problema, as outras tarefas demoraram mais que as quatro horas originalmente programadas. Portanto, todos os sistemas estavam de volta produo meia-noite (s 6hs do sbado para o escritrio de Berlim). Devido s questes remanescentes de hardware, o desempenho da AP, AR e do relatrio de Balano Semanal ser ligeiramente melhor, mas no tanto quanto planejado originalmente. Uma segunda atualizao ser comunicada e programada assim que resolvermos as questes que impossibilitaram a concluso da tarefa. Favor notar que a atualizao alterou alguns ndices de banco de dados; as pessoas que elaboraram suas prpiras consultas ao SQL devem vericar a pgina de Finanas na intranet da empresa. No caso de dvidas, favor contatar a Administrao de Sistemas no ramal 4321.
Com este tipo de informao, seus usurios tero conhecimento suciente para continuarem seus trabalhos e entenderem como as alteraes os impactam.
1.4. Conhea Seus Recursos

A administrao de sistemas consiste basicamente em balancear recursos entre as pessoas e os programas que os utilizam. Consequentemente, sua carreira como administrador de sistemas ser curta e estressante se voc no entender perfeitamente os recursos sua disposio. Alguns destes recursos parecem bastante bvios:

Recursos de sistema, como o poder de processamento, a memria e o espao disponvel em disco Largura de banda de rede (network bandwidth) Dinheiro disponvel no oramento de TI
Mas alguns no so to bvios:

1. Certique-se de enviar esta mensagem assim que o trabalho estiver concludo, antes de ir para casa. Aps
sair do escritrio, muito fcil esquecer, deixando seus usurios sem saber se podem usar o sistema ou no.
Captulo 1. A Filosoa da Administrao de Sistemas Os servios dos funcionrios de operaes, outros administradores de sistemas ou at mesmo um assistente administrativo Tempo (geralmente de suma importncia, principalmente quando envolve o tempo durante o qual sero feitos backups do sistema) Conhecimento (seja armazenado em livros, na documentao do sistema ou na mente de uma pessoa que trabalhou para a empresa nos ltimos 20 anos)
importante notar o valor de elaborar um inventrio completo destes recursos disponveis e mant-lo atualizado a falta de "conscincia da situao" dos recursos pode ser pior que conscincia nenhuma.
1.5. Conhea Seus Usurios

Apesar de algumas pessoas se incomodarem com o termo "usurios" (talvez devido ao uso do termo por algum administrador de sistemas de forma pejorativa), usado aqui sem esta conotao. Usurios so as pessoas que utilizam os sistemas e recursos pelos quais voc responsvel nem mais, nem menos. Como tais, eles so centrais para sua habilidade em administrar seus sistemas adequadamente. Sem entender seus usurios, como voc pode entender os recursos de sistema solicitados por eles? Por exemplo: imagine um operador de caixa de banco. Um caixa de banco utiliza um conjunto de aplicaes estritamente denido e requer pouco dos recursos de sistema. Um engenheiro de software, por outro lado, usa muitas aplicaes diferentes e sempre agradece mais recursos de sistema (para tempos de criao mais rpidos). Dois usurios completamente diferentes com necessidades completamente diferentes. Certique-se de aprender o mximo possvel a respeito de seus usurios.
1.6. Conhea Seu Negcio

Mesmo se voc trabalha para uma empresa grande e multinacional, ou ento para uma pequena escola comunitria, deve entender a natureza do ambiente de negcios no qual voc trabalha. Isto pode ser resumido em uma questo: Qual o propsito dos sistemas que voc administra? O ponto central aqui entender o propsito de seus sistemas sob um aspecto mais global:

As aplicaes que devem rodar num determinado perodo de tempo, como o m de um ms, de um quadrimestre ou de um ano Os perodos durante os quais deve ser feita a manuteno do sistema As novas tecnologias que podem ser usadas para resolver antigos problemas do negcio
Levando em considerao o negcio da sua empresa, voc tomar melhores decises dirias para seus usurios e para voc.
1.7. A Segurana No Pode ser Postergada

No importa o que voc pensa sobre o ambiente no qual seus sistemas rodam; voc no pode ignorar o fator segurana. Mesmo sistemas standalone no conectados Internet podem estar em risco (apesar dos riscos serem obviamente diferentes de um sistema que tem conexes com o mundo externo). Consequentemente, extremamente importante considerar as implicaes de segurana em tudo que voc zer. A lista seguinte ilustra os tipos de questes que voc deve considerar:
A natureza de possveis ameaas a cada um dos sistemas sob seus cuidados
Captulo 1. A Filosoa da Administrao de Sistemas A localidade, o tipo e o valor dos dados nestes sistemas O tipo e a frequncia de acesso autorizado a estes sistemas
Quando pensar em segurana, no cometa o erro de assumir que os possveis ataques a seus sistemas viro apenas de fora da empresa. Muitas vezes, o invasor algum de dentro da empresa. Portanto, na prxima vez que voc caminhar pelo escritrio, observe as pessoas ao seu redor e pergunte a si mesmo: O que aconteceria se esta pessoa tentasse sabotar nossa segurana?
Nota Isso no signica que voc deve tratar seus colegas de trabalho como criminosos. Mas que voc deve observar o tipo de trabalho de cada um e determinar os tipos de brechas na segurana que uma pessoa naquela funo poderia perpetrar, caso tivesse essa vontade.
1.7.1. Os Riscos da Engenharia Social

Apesar da primeira reao da maioria dos administradores de sistemas quando pensa na segurana ser concentrar nos aspectos tecnolgicos, importante manter a perspectiva. Frequentemente, as brechas na segurana no so originadas na tecnologia, mas na natureza humana. Pessoas interessadas nas brechas de segurana frequentemente usam a natureza humana para burlar inteiramente os controles de acesso tecnolgico. Isso conhecido como engenharia social. Eis um exemplo: O operador do segundo turno recebe uma ligao externa. A pessoa que ligou clama ser o Diretor Financeiro da empresa (seu nome e informaes foram obtidos no site da empresa, na pgina "Equipe de Gerncia"). A pessoa que ligou clama estar em algum lugar do outro lado do globo (talvez esta parte da histria seja co total, ou talvez o site de sua empresa tenha publicado uma nota de imprensa mencionando a presena do diretor numa feira internacional). A pessoa que ligou conta uma fbula: seu laptop foi roubado no aeroporto, ele est com um cliente importante e, portanto, precisa de acesso intranet corporativa para vericar a conta deste cliente. Ser que o operador deve ser bonzinho e dar as informaes de acesso a ele? Voc sabe o que seu operador faria? A no ser que ele tenha instrues (na forma de normas e processos), voc provavelmente no sabe o que aconteceria. Assim como as luzes de um semforo, o objetivo das normas e procedimentos prover instrues explcitas sobre o que e o que no comportamento adequado. No entanto, assim como as luzes do semforo, as normas e procedimentos funcionam somente se todos os seguem. Aqui est o X da questo improvvel que todos sigam suas normas e procedimentos. Na realidade, dependendo da natureza de sua empresa, possvel que voc nem tenha autoridade suciente para denir normas, muito menos para refor-las. O que fazer ento? Infelizmente, no h respostas fceis. A educao dos usurios pode ajudar: faa tudo que voc puder para alertar sua comunidade de usurios sobre a segurana e engenharia social. Minstre apresentaes sobre segurana no horrio de almoo. Envie links de artigos sobre segurana nas listas de discusso da empresa. Enfatize sua disponibilidade para as perguntas de seus usurios sobre coisas que no parecem corretas. Em suma, envie sua mensagem aos usurios de todas as formas que puder.
1.8. Planejar com Antecedncia

Os administradores de sistemas que absorveram todo este aconselhamento e zeram o possvel para segu-lo risca, sero timos administradores de sistemas por um dia. Eventualmente, o ambiente mudar e nosso administrador fantstico ser pego de surpresa. Por que? Nosso fantstico administrador falhou em planejar com antecedncia. Certamente, ningum pode predizer o futuro com 100% de acuracidade. No entanto, com um pouco de conscincia, ca fcil ler os sinais de muitas mudanas:

Uma simples meno de um novo projeto durante aquela reunio semanal sacal , certamente, um sinal certeiro de que voc provavelmente precisar suportar seus usurios no futuro prximo. Uma conversa sobre uma aquisio iminente signica que voc talvez acabe sendo responsvel por sistemas novos (e possivelmente incompatveis) em uma ou mais localidades remotas.
Ser capaz de ler estes sinais (e responder a eles efetivamente) facilita a sua vida e a de seus usurios.
1.9. Espere o Inesperado

Apesar da frase "esperar o inesperado" ser clich, reete uma verdade elementar que todos os administradores de sistemas devem entender: Haver momentos em que voc ser pego de surpresa. Aps estar confortvel com este fato desconfortante, o que um administrador de sistemas engajado pode fazer? A resposta est na exibilidade; executando seu trabalho de maneira a oferecer a voc (e aos seus usurios) o maior nmero de opes possvel. Abordemos, por exemplo, a questo do espao em disco. Dado que nunca ter espao suciente em disco parece ser uma lei mais fsica do que a lei da gravidade, razovel assumir que, em algum ponto, voc ser confrontado por uma necessidade desesperada imediata de espao adicional em disco. O que faria um administrador de sistemas que espera o inesperado? Talvez seja possvel manter alguns drives de disco reservas na prateleira no caso de problemas com o hardware 2 . Uma pea reserva deste tipo pode ser empregada rapidamente3 temporariamente para resolver a necessidade imediata de espao em disco, alocando mais tempo para a soluo denitiva (seguindo o procedimento padro para a obteno de drives de disco adicionais, por exemplo). Ao tentar antecipar os problemas antes de ocorrerem, voc ser capaz de responder mais rpida e efetivamente do que se voc deixar se surpreender.
1.10. Informaes Especcas do Red Hat Enterprise Linux

Esta seo aborda as informaes relacionadas losoa da administrao de sistemas especcas ao Red Hat Enterprise Linux.
1.10.1. Automao
A automao de tarefas executadas frequentemente sob o Red Hat Enterprise Linux requer o conhecimento de diversos tipos de tecnologia. Primeiro, os comandos que controlam o tempo do comando ou a execuo do script. Os comandos cron e at so os mais usados para estas funes.
2. E, obviamente, um administrador de sistemas que espera o inesperado naturalmente usaria o RAID (ou
tecnologias relacionadas) para amenizar o impacto da falha de um drive de disco crtico durante a produo. 3. Novamente: os administradores de sistemas que pensam pr-ativamente conguram seus sistemas de forma a facilitar o mximo possvel a adio de um novo drive de disco ao sistema.
Incorporando um sistema de especicao de tempo bastante exvel, mas de fcil entendimento, o cron pode agendar a execuo de comandos ou scripts em intervalos recorrentes, variando de minutos a meses. O comando crontab usado para manipular os arquivos que controlam o daemon do cron, que na verdade agendam cada tarefa do cron para a execuo. O comando at (e o comando batch relacionado) mais apropriado para agendar a execuo de scripts ou comandos para uma nica ocorrncia. Estes comandos implementam um sub-sistema batch rudimentar que consiste de mltiplas las com prioridades de agendamento variadas. As prioridades so conhecidas como nveis de niceness (devido o nome do comando nice). Ambos os comandos, at e batch, so perfeitos para tarefas que devem ocorrer com horrio de incio determinado, mas no so crticas em seu tempo de trmino. Em seguida, esto as diversas linguagens de script. Estas so as "linguagens de programao", usadas pelo administrador de sistemas comum para automatizar operaes manuais. H muitas linguagens de script (e cada administrador de sistemas geralmente tem sua favorita), mas as que seguem so as mais comuns no momento:

O comando de linha bash A linguagem de script perl A linguagem de script python
Alm das diferenas bvias entre estas linguagens, a maior diferena a maneira atravs da qual interagem com outros programas em um sistema Red Hat Enterprise Linux. Os scripts escritos com a janela de comandos bash tendem a utilizar mais extensivamente os diversos utilitrios (por exemplo: para efetuar a manipulao dos strings de caracteres), enquanto os scripts perl executam mais esse tipo de operao usando funcionalidades integradas na prpria linguagem. Um script escrito usando o python pode explorar totalmente as capacidades orientadas a objetos da linguagem, tornando os scripts mais complexos facilmente extensveis. Isto signica que, para conhecer bem o script da janela de comandos, voc deve se familiarizar com os diversos programas de utilitrios (como grep e sed) que so parte do Red Hat Enterprise Linux. Aprender perl (e python), por outro lado, tende ser um processo mais "auto-suciente". No entanto, muitas construes da linguagem perl so baseadas na sintaxe de diversos programas de utilitrios tradicionais do UNIX, e portanto so familiares aos administradores de sistemas Red Hat Enterprise Linux com experncia em scripts de janela de comandos.
1.10.2. Documentao e Comunicao

Nas reas de documentao e comunicao h poucas coisas especcas ao Red Hat Enterprise Linux. Como documentao e comunicao podem consistir de qualquer coisa, de adicionar comentrios a um arquivo-texto de congurao a atualizar uma pgina web ou enviar um e-mail, um administrador de sistemas usando o Red Hat Enterprise Linux deve ter acesso a editores de texto, editores HTML e clientes de e-mail. Eis aqui uma pequena amostra dos diversos editores de texto disponveis sob o Red Hat Enterprise Linux:

O editor de texto gedit O editor de texto Emacs O editor de texto Vim
O editor de texto gedit uma aplicao estritamente grca (ou seja, requer um ambiente do Sistema X Window), enquanto vim e Emacs so baseados em texto por natureza.
10
A questo sobre qual o melhor editor de texto tem sido um debate quase to longo quanto a existncia dos computadores e continuar assim por um bom tempo. Consequentemente, o melhor a fazer experimentar cada um dos editores e utilizar aquele que mais te agrada. Em termos de editores HTML, os administradores de sistemas podem usar a funo Composer do navegador web Mozilla. Obviamente, alguns administradores de sistemas preferem codicar seu HTML manualmente, o que torna um editor de texto comum uma ferramenta perfeitamente aceitvel. Em relao a e-mail, o Red Hat Enterprise Linux inclui o cliente grco de e-mail Evolution, o cliente de e-mail Mozilla (tambm grco) e o mutt, que baseado em texto. Para os editores de texto, a escolha de um cliente de e-mail tende ser pessoal; portanto, o melhor a fazer experimentar cada um dos clientes e usar o que funciona melhor para voc.
1.10.3. Segurana
Como mencionado anteriormente neste captulo, a segurana no pode ser um pensamento posterior, e a segurana sob o Red Hat Enterprise Linux no supercial. Os controles de acesso e autenticao so profundamente integrados ao sistema operacional e baseados em designs extrados de longos anos de experincia da comunidade UNIX. Para autenticao, o Red Hat Enterprise Linux usa o PAM Mdulos de Autenticao Plugveis. O PAM possibilita o ajuste no da autenticao de usurios atravs da congurao de bibliotecas compartilhadas, usadas por todas as aplicaes que baseiam sua autenticao no PAM. Tudo isso feito sem a necessidade de alteraes nas aplicaes. O controle de acesso sob o Red Hat Enterprise Linux usa permisses tradicionais do estilo UNIX (ler/acessar, gravar e executar) para as classes usurio, grupo e "outros". Como no UNIX, o Red Hat Enterprise Linux tambm usa os bits setuid e setgid para conferir direitos de acesso expandido a processos rodando um programa especco, baseado na propriedade do arquivo do programa. Obviamente, isto traz a necessidade de auditar cuidadosamente qualquer programa que v rodar com privilgios setuid ou setgid para garantir que no h vulnerabilidades explorveis. O Red Hat Enterprise Linux tambm inclui suporte para as listas de controle de acesso. Uma lista de controle de acesso (ACL) uma estrutura que permite um controle restrito sobre quais usurios ou grupos podem acessar um arquivo ou diretrio. Por exemplo: as permisses de um arquivo podem restringir todos os acessos de qualquer pessoa alm do proprietrio (owner) do arquivo. Alm disso, a ACL do arquivo pode ser congurada para permitir somente ao usurio z gravar/salvar e ao grupo finanas ler/acessar o arquivo. Um outro aspecto da segurana a habilidade de registrar as atividades do sistema. O Red Hat Enterprise Linux usa extensivamente os registros, nos nveis do kernel e da aplicao. O registro controlado pelo daemon de registro do sistema, syslogd, que pode registrar informaes do sistema localmente (normalmente em arquivos do diretrio /var/log/) ou num sistema remoto (que atua como um servidor de registros dedicado para mltiplos computadores.) Os sistemas de deteco de intruso (IDS) so ferramentas poderosas para qualquer administrador de sistemas Red Hat Enterprise Linux. Um IDS possibilita que administradores de sistemas determinem se foram feitas alteraes no-autorizadas em um ou mais sistemas. O design do prprio sistema operacional inclui uma funcionalidade igual do IDS. Como o Red Hat Enterprise Linux instalado usando o Administrador de Pacotes RPM (RPM), possvel us-lo para vericar se foram feitas alteraes nos pacotes que constituem o sistema operacional. No entanto, como o RPM essencialmente uma ferramenta de administrao de pacotes, suas habilidades como um IDS so de certa forma limitadas. Mesmo assim, pode ser um bom primeiro passo para monitorar um sistema Red Hat Enterprise Linux e vericar modicaes no-autorizadas.
11
1.11. Recursos Adicionais

Esta seo inclui diversos recursos que podem ser usados para aprender mais sobre a losoa da administrao de sistemas e sua relao especca com o Red Hat Enterprise Linux.
1.11.1. Documentao Instalada

Os recursos a seguir so instalados no decorrrer de uma instalao tpica do Red Hat Enterprise Linux e podem ajud-lo a aprender mais sobre o assunto abordado neste captulo.

Pginas man crontab(1) e crontab(5) Aprenda como agendar comandos e scripts para execuo automtica em intervalos regulares. Pgina man at(1) Aprenda a agendar comandos e scripts para execuo posterior. Pgina man bash(1) Aprenda mais sobre a janela de comandos (shell) default e como escrever scripts nesta. Pgina man perl(1) Indicaes de diversos sites que compoem a documentao online do perl. Pgina man python(1) Aprenda mais sobre as opes, arquivos e variveis de ambiente que controlam o interpretador Python. Pgina man gedit(1) e item Help do menu Aprenda a editar arquivos-texto com este editor de texto grco. Pgina man emacs(1) Aprenda mais sobre este editor de texto altamente exvel, inclusive como rodar seu tutorial online. Pgina man vim(1) Aprenda a usar este editor de texto poderoso. O item Help Contents do menu do Mozilla Aprenda a editar arquivos HTML, ler e-mails e navegar na web. Pgina man evolution(1) e item Help do menu Aprenda a administrar seus e-mails com cliente grco de e-mail.
1.11.2. Sites teis

http://www.kernel.org/pub/linux/libs/pam/ A homepage do projeto Linux-PAM. http://www.usenix.org/ A homepage do USENIX. Uma organizao prossional dedicada a reunir prossionais da computao de todos os tipos, fomentando a melhoria da comunicao e inovao. http://www.sage.org/ A homepage da Associao dos Administradores de Sistemas (System Administrators Guild). Um grupo tcnico especial da USENIX que representa um bom recurso para todos os administradores responsveis por sistemas Linux (ou parecidos com o Linux). http://www.python.org/ O site da Linguagem Python, excelente para aprender mais sobre esta. http://www.perl.org/ O site dos entusiastas do Perl; um bom lugar para comear a aprender sobre a linguagem e interagir com a comunidade Perl. http://www.rpm.org/ A homepage do Administrador de Pacotes RPM. O site mais detalhado sobre o RPM.
Pgina man pam(8) e arquivos em /usr/share/doc/pam- verso ciona a autenticao sob o Red Hat Enterprise Linux.
Pgina man mutt(1) e arquivos em /usr/share/doc/mutt- verso istrar seus e-mails com este cliente de e-mail baseado em texto.
Aprenda a admin Aprenda como fun-
12
1.11.3. Livros Relacionados

A maioria dos livros sobre administrao de sistemas no aborda a questo losca por trs do trabalho. Entretanto, os livros a seguir tm sees que trazem um pouco mais de profundidade s questes aqui abordadas:
O Guia de Referncia do Red Hat Enterprise Linux; Red Hat, Inc. Provm uma viso geral das localidades de arquivos de sistema importantes, conguraes de usurio e grupo e congurao do PAM. O Guia de Segurana do Red Hat Enterprise Linux; Red Hat, Inc. Contm uma discusso detalhada sobre diversas questes relacionadas segurana para administradores de sistemas Red Hat Enterprise Linux. O Guia de Administrao de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. Inclui captulos sobre a administrao de usurios e grupos, automao de tarefas e administrao de arquivos de registro (log les). Linux Administration Handbook de Evi Nemeth, Garth Snyder e Trent R. Hein; Prentice Hall Provm uma boa seo sobre as normas e o lado poltico da administrao de sistemas, incluindo diversas discusses hipotticas sobre tica. Linux System Administration: A Users Guide de Marcel Gagne; Addison Wesley Professional Contm um captulo sobre a automao de diversas tarefas. Solaris System Management de John Philcox; New Riders Publishing Apesar de no ser escrito especicamente para o Red Hat Enterprise Linux (nem mesmo para o Linux em geral) e usar o termo "gerente de sistemas" ao invs de "administrador de sistemas", este livro traz uma viso geral de 70 pginas sobre as diversas funes exercidas pelo administrador de sistemas numa empresa.
Captulo 2.
Monitoramento de Recursos
Como mencionado anteriormente, grande parte dos administradores de sistemas conta com os recursos e seu uso eciente. Ao balancear vrios recursos atravs dos indivduos e programas que os utilizam, voc desperdia menos dinheiro e deixa seus usurios contentes. No entanto, isto traz duas questes: O que so recursos? e: Como possvel saber quais recursos so utilizados (e o quanto deles utilizado)? O propsito desse captulo capacit-lo a responder estas questes ajudando-o a apender mais sobre os recursos e seu monitoramento.
2.1. Conceitos Bsicos

Antes de monitorar os recursos, voc deve saber quais os recursos existentes para monitorar. Todos os sistemas tm os seguintes recursos disponveis:

Energia da CPU Largura de banda (bandwidth) Memria Armazenamento
Estes recursos so cobertos em mais detalhes nos captulos seguintes. No entanto, tudo o que voc precisa ter em mente por enquanto que estes recursos tm um impacto direto no desempenho do sistema e, consequentemente, na produtividade e bem-estar de seus usurios. Simplisticamente, o monitoramento de recursos nada mais que a obteno de informaes sobre a utilizao de um ou mais recursos do sistema. Entretanto, raramente to simples. Primeiramente, deve-se considerar os recursos a serem monitorados. Ento, necessrio examinar cada sistema a ser monitorado, prestando ateno especial situao de cada um deles. Os sistemas que voc monitorar esto em uma destas duas categorias:

No momento, o sistema est tendo problemas de desempenho parte do tempo e voc deseja melhorar seu desempenho. O sistema est OK no momento e voc deseja que continue assim.
A primeira categoria signica que voc deve monitorar os recursos sob a perspectiva de desempenho do sistema, enquanto na segunda voc deve monitorar os recursos do sistema sob a perspectiva do planejamento de capacidades. Como cada perspectiva tem seus prprios requerimentos nicos, as sees seguintes exploram cada categoria em maior profundidade.
14
Captulo 2. Monitoramento de Recursos
2.2. Monitoramento do Desempenho do Sistema

Conforme mencionado anteriormente, o monitoramento do desempenho do sistema normalmente feito em resposta a um problema de desempenho. Ou o sistema est muito lento ou os programas (e, s vezes, o sistema todo) no rodam de jeito nenhum. Em ambos os casos, o monitoramento do desempenho normalmente feito como o primeiro e ltimo passos de um processo de trs etapas: 1. Monitorar para identicar a natureza e escopo da reduo de recursos que causam os problemas de desempenho 2. Os dados obtidos atravs do monitoramento so analisados e tomada uma sequncia de aes (normalmente, o ajuste de desempenho e/ou a aquisio de hardware adicional) para resolver o problema 3. Monitorar para garantir que o problema de desempenho foi resolvido Por causa disso, o montoramento do desempenho tende ter uma durao relativamente pequena e um escopo mais detalhado.
Nota O monitoramento do desempenho do sistema frequentemente um processo repetitivo, com estes passos sendo repetidos diversas vezes a m de atingir o melhor desepenho possvel do sistema. A principal razo disso que os recursos do sistema e sua utilizao tendem ser altamente relacionados, ou seja, a eliminao do gargalo de um recurso frequentemente revela outro.
2.3. Monitorando a Capacidade do Sistema

O monitoramento da capacidade do sistema parte de um programa intermitente de planejamento da capacidade. Este planejamento usa o monitoramento de recursos a longo prazo para determinar as taxas de mudana na utilizao dos recursos do sistema. Uma vez conhecidas estas taxas de mudana, possvel conduzir um planejamento mais preciso a longo prazo em relao compra de recursos adicionais. O monitoramento da capacidade com o propsito de planejamento diferente do monitoramento do desempenho de duas maneiras:

O monitoramento feito quase continuamente O monitoramento geralmente no to detalhado
A razo destas diferenas baseia-se nos objetivos de um programa de planejamento da capacidade. O planejamento da capacidade requer um ponto de vista "macro"; o uso anmalo ou de curto prazo dos recursos tem pouca importncia. Ao invs, os dados so coletados ao longo de um perodo, possibilitando classicar a utilizao dos recursos em termos de alteraes da carga de trabalho. Em ambientes mais restritos (onde somente roda uma aplicao, por exemplo), possvel modelar o impacto da aplicao nos recursos do sistema. Isto pode ser feito com preciso suciente para poder determinar, por exemplo, o impacto da adio de cinco funcionrios de atendimento ao cliente rodando a aplicao de CRM durante o perodo mais intenso (ocupado) do dia.
15
2.4. O Que Monitorar?

Conforme dito antes, os recursos presentes em todos os sistemas so energia da CPU, largura de banda, memria e armazenamento. primeira vista, pode parecer que o monitoramento consistiria apenas da avaliao destes quatro fatores distintos. Infelizmente, no to simples. Por exemplo: considere um drive de disco. Quais as coisas que voc gostaria de saber sobre seu desempenho?

Quanto h de espao livre? Quantas operaes I/O por segundo executa em mdia? Quanto tempo leva para completar cada operao I/O em mdia? Quantas destas operaes I/O so acessos (reads)? Quantas so gravaes (writes)? Qual a quantidade mdia de dados acessados/gravados em cada I/O?
H outras maneiras de estudar o desempenho do drive de disco; estes pontos apenas abrangem a superfcie. O conceito principal ter em mente que h muitos tipos diferentes de dados para cada recurso. As sees seguintes exploram os tipos de utilizao das informaes teis para cada tipo de recurso principal.
2.4.1. Monitorando a Energia da CPU

Na sua forma mais simples, monitorar a energia da CPU consiste em determinar se a utilizao da CPU atinge, em algum momento, 100%. Se a utilizao da CPU traz algo abaixo de 100%, no importa o que o sistema est fazendo, h energia de processamento disponvel para mais carga de trabalho. Entretanto, raro um sistema que no atinge 100% de utilizao da CPU em pelo menos parte do tempo. Neste ponto importante examinar os dados de utilizao mais detalhadamente. Ao fazer isso, possvel comear a determinar onde a maioria da sua energia de processamento est sendo consumida. Aqui esto algumas das estatsticas mais comuns de utilizao da CPU: Usurios Versus Sistema A porcentagem de tempo gasto com o processamento a nvel de usurio versus o processamento a nvel do sistema pode indicar se a carga de um sistema deve-se execuo de aplicaes ou sobrecarga do sistema operacional. As altas porcentagens a nvel de usurio tendem a ser boas (assumindo que os usurios tenham desempenho satisfatrio), enquanto as altas porcentagens a nvel de sistema tendem a indicar problemas que requerem uma investigao mais profunda. Mudanas de Contexto Uma mudana de contexto ocorre quando a CPU para de rodar um processo e comea a rodar outro. Como cada mudana de contexto requer que o sistema operacional tome o controle da CPU, mudanas de contexto excessivas e altos nveis de consumo da CPU a nvel de sistema tendem a caminhar juntos. Interrupes Como o nome implica, as interrupes so situaes nas quais o processo desempenhado pela CPU alterado abruptamente. As interrupes geralmente ocorrem devido a atividade do hardware (como um dispositivo I/O completando uma operao I/O) ou devido a software (como interrupes do software que controla o processamento da aplicao). Como as interrupes devem ser resolvidas a nvel do sistema, altas taxas de interrupo levam a um consumo maior da CPU a nvel do sistema.
16 Processos Executveis (runnable)
Um processo pode estar em estados diferentes, como:

Aguardando a nalizao de uma operao I/O Aguardando o sub-sistema de administrao da memria resolver uma falha de pgina
Nestes casos, o processo no precisa da CPU. No entanto, o processo sofre mudanas eventualmente e torna-se executvel. Como o nome implica, um processo executvel capaz de executar o trabalho assim que estiver agendado para receber tempo da CPU. Entretanto, se mais de um processo for executvel numa determinada hora, todos os processos executveis menos um1 devem esperar pela sua vez na CPU. Ao monitorar o nmero de processos executveis, possvel determinar o quanto seu sistema depende da CPU. Outras medidas de desempenho que reetem um impacto na utilizao da CPU tendem a incluir servios diferentes que o sistema operacional oferece aos processos. Podem incluir estatsticas da administrao da memria, do processamento I/O e assim por diante. Estas estatsticas tambm revelam que, quando o desempenho do sistema monitorado, no h limites entre as estatsiticas diferentes. Em outras palavras: as estatsticas de utilizao da CPU podem terminar apontando para um problema no sub-sistema I/O ou as estatsticas de utilizao da memria podem revelar uma falha no design da aplicao. Consequentemente, ao monitorar o desempenho do sistema, no possvel examinar nenhuma estatstica isoladamente; s possvel extrair informaes signicativas ao examinar o quadro geral de quaisquer estatsticas que voc coletar.
2.4.2. Monitorando a Largura de Banda

Monitorar a largura de banda mais difcil que monitorar outros recursos aqui descritos. A razo disso deve-se ao fato que as estatsticas de desempenho geralmente baseiam-se nos dispositivos, enquanto a maioria dos lugares onde a largura de banda importante so os canais que conectam dispositivos. Nestes casos, onde mais de um dispositivo compartilha um canal em comum, voc deve observar estatsticas razoveis para cada dispositivo, mas a carga agregada imposta por estes dispositivos no canal seria bem maior. Um outro desao ao monitorar a largura de banda: pode haver circunstncias nas quais as estatsticas dos dispositivos podem no estar disponveis. Isto particularmente verdadeiro para canais de expanso do sistema e caminhos de dados2. No entanto, mesmo que as estatsticas relacionadas largura de banda no estejam 100% corretas, frequentemente h informaes necessrias para possibilitar algum nvel de anlise, particularmente ao considerar as estatsticas relacionadas. Estas so algumas das estatsticas mais comuns relacionadas largura de banda: Bytes recebidos/enviados As estatsticas da interface de rede oferecem um indicador da utilizao da largura de banda de um dos canais mais visveis a rede. Contagens e taxas da interface Estas estatsticas relacionadas rede podem indicar colises excessivas, transmitir e receber erros, entre outros. Atravs do uso destas estatsticas (particularmente, se houver estatsticas para mais de um sistema em sua rede), possvel solucionar um mnimo de problemas de rede, mesmo antes de usar as ferramentas de diagnstico de rede mais comuns.
1. 2. Assumindo um sistema com processador nico. Mais informaes sobre canais, caminhos de dados e largura de banda podem ser encontradas no Captulo 3.
Captulo 2. Monitoramento de Recursos Transferncias por Segundo
17
Normalmente coletada para dispositivos I/O de bloco, como drives de ta de alto desempenho e drives de disco, esta estatstica uma boa maneira de determinar se a largura de banda de um determinado dispositivo atingiu seu limite. Devido sua natureza eletromecnica, os drives de ta e de disco podem executar somente um determinado nmero de operaes I/O a cada segundo; seu desempenho decai rapidamente quando esse limite atingido.
2.4.3. Monitorando a Memria

Se existe alguma rea onde podemos encontrar uma riqueza de estatsticas de desempenho, essa rea o monitoramento da utilizao da memria. Devido complexidade inerente dos sistemas operacionais com memria virtual paginada por demanda, as estatsticas de utilizao da memria so muitas e variadas. aqui que reside a maioria do trabalho do administrador de sistemas com a administrao dos recursos. Os dados seguintes representam uma viso geral supercial das estatsticas comumente encontradas sobre a administrao da memria: Pginas Dentro/Pginas Fora (Page Ins/Page Outs) Estas estatsticas possibilitam medir o uxo de pginas da memria do sistema para os dispositivos de armazenamento em massa anexos (geralmente drives de disco). Taxas altas de ambas estatsticas podem signicar que o sistema tem pouca memria fsica e est com thrashing, ou seja, gastando mais recursos do sistema para mover pginas para dentro e para fora da memria que para rodar aplicaes. Pginas Ativas/Inativas (Active/Inactive Pages) Estes dados mostram como so usadas as pginas altamente residentes na memria. Uma falta de pginas inativas pode indicar a falta de memria fsica. Pginas Livres, Compartilhadas, no Buffer e no Cache (Free, Shared, Buffered, and Cached Pages) Estes dados oferecem detalhes adicionais sobre as estatsticas de pginas inativas/ativas mais simplistas. Ao usar estas estatsticas, possvel determinar a mistura geral da utilizao da memria. Swap Dentro/Swap Fora (Swap Ins/Swap Outs) Estes dados mostram o comportamento da memria swap do sistema. Altas taxas podem indicar a falta de memria fsica. O bom monitoramento da utilizao da memria requer um bom entendimento de como funcionam os sistemas operacionais com memria virtual paginada por demanda. Apesar do assunto isoladamente poder ocupar um livro inteiro, seus conceitos bsicos esto abordados no Captulo 4. Este captulo, juntamente ao tempo gasto com o monitoramento de um sistema real, oferece a base para aprender mais sobre o assunto.
2.4.4. Monitorando o Armazenamento

O monitoramento do armazenamento geralmente ocorre em dois nveis diferentes:

Monitoramento de espao suciente em disco Monitoramento de problemas de desempenho relacionados ao armazenamento
A razo disto: possvel ter problemas srios em uma rea e nenhum problema em outra. Por exemplo: possvel fazer com que um drive de disco esgote seu espao sem causar nenhum tipo de problema
18
relacionado ao desempenho. Da mesma forma, possvel ter um drive de disco com 99% de espao livre com seus limites de desempemnho sendo forados. Entretanto, mais provvel que o sistema mediano experimente vrios graus de falta de recursos em ambas reas. Por causa disso, tambm provvel que at certo ponto os problemas de uma rea impactem noutra rea. Frequentemente, esse tipo de interao toma a forma de desempenho I/O descendente, conforme o drive de disco se aproxima de 0% de espao livre; no obstante, nos casos de cargas I/O extremas, pode ser possvel diminuir I/O para um nvel no qual as aplicaes no mais rodam apropriadamente. Em qualquer caso, as estatsticas a seguir so teis para monitorar o armazenamento: Espao Livre (Free Space) Espao livre provavelmente o recurso que todos os administradores de sistemas monitoram de perto; seria raro um administrador de sistemas que nunca verica o espao livre (ou que no tenha uma maneira automatizada de faz-lo). Estatsticas Relaciondas ao Sistema de Arquivo Estas estatsticas (como nmero de arquivos/diretrios, tamanho mdio de arquivo, etc) oferecem detalhes adicionais sobre a simples porcentagem de espao livre. Como tais, estas estatsticas possibilitam aos administradores congurar o sistema para o melhor desempenho, j que a carga I/O imposta por um sistema de arquivo com muitos arquivos pequenos no a mesma que quela imposta por um sistema de arquivo com um nico arquivo enorme. Transferncias por Segundo Esta estatstica uma boa maneira de determinar se os limites de largura de banda de um determinado dispositivo foram atingidos. Acessos/Gravaes por Segundo (Reads/Writes per Second) Uma anlise um pouco mais detalhada das transferncias por segundo, estas estatsticas permitem ao administrador de sistemas entender melhor a natureza das cargas I/O experimentadas por um dispositivo de armazenamento. Isto pode ser crtico j que algumas tecnologias de armazenamento tm caractersticas de desempenho bem diferentes para operaes de acesso (read) e para operaes de gravao (write).

O Red Hat Enterprise Linux traz diversas ferramentas de monitoramento dos recursos. Apesar de existir mais ferramentas que as listadas aqui, essas so as mais representativas em termos de funcionalidade:
free top
(e Monitor GNOME do Sistema, uma verso mais grca do top)
vmstat
O pacote Sysstat de ferramentas de monitoramento dos recursos O perlador do sistema OProle
Vamos examinar cada um mais detalhadamente.
19
2.5.1. free
O comando free apresenta a utilizao da memria do sistema. Aqui est um exemplo de seu output:
total Mem: 255508 -/+ buffers/cache: Swap: 530136 used 240268 146488 26268 free 15240 109020 503868 shared 0 buffers 7592 cached 86188
A linha Mem: apresenta a utilizao da memria fsica, enquanto a linha Swap: apresenta a utilizao do espao swap do sistema, e a linha -/+ buffers/cache: traz a quantidade de memria fsica corrente dedicada aos buffers do sistema. Como o free apresenta as informaes de utilizao da memria uma s vez por default, til somente para monitoramento de curto prazo, ou para determinar rapidamente se um problema relativo memria est ocorrendo no momento. Apesar do free ter a habilidade de apresentar a utilizao da memria repetidamente atravs de sua opo -s, seu output se estende ao longo da tela, dicultando detectar as alteraes na utilizao da memria.
Dica Uma soluo melhor que o uso do free -s seria executar o free usando o comando watch. Por exemplo: para trazer a utilizao da memria a cada dois segundos (o intervalo default de display do watch), use esse comando:
watch free
O comando watch submete o comando free a cada dois segundos, limpando a tela e exibindo o novo output na mesma localidade. Isso facilita determinar as alteraes na utilizao da memria ao longo do tempo, j que o watch cria uma nica visualizao atualizada sem scrolling. Voc pode controlar o intervalo entre as atualizaes usando a opo -n e fazer com que quaisquer alteraes entre as atualizaes sejam destacadas, usando a opo -d, conforme o comando seguinte:
watch -n 1 -d free
Para mais informaes , consulte a pgina man watch. O comando watch roda continuamente at ser interrompido por [Ctrl]-[C]. O comando watch algo para ter em mente, pois pode ser til em diversas situaes.
2.5.2. top
Enquanto o free apresenta somente informaes relativas memria, o comando top faz um pouco de tudo. A utilizao da CPU, as estatsticas de processo, a utilizao da memria o top monitora tudo. Alm disso, ao contrrio do comando free, o comportamento defalut do top rodar continuamente; no h necessidade de usar o comando watch. Aqui est uma amostra:
14:06:32 up 4 days, 21:20, 4 users, load average: 0.00, 0.00, 0.00 77 processes: 76 sleeping, 1 running, 0 zombie, 0 stopped CPU states: cpu user nice system irq softirq iowait idle total 19.6% 0.0% 0.0% 0.0% 0.0% 0.0% 180.2% cpu00 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 100.0% cpu01 19.6% 0.0% 0.0% 0.0% 0.0% 0.0% 80.3% Mem: 1028548k av, 716604k used, 311944k free, 0k shrd, 131056k buff 324996k actv, 108692k in_d, 13988k in_c Swap: 1020116k av, 5276k used, 1014840k free 382228k cached
20
PID 17578 19154 1 2 3 4 5 6 9 7 8 10 11
USER root root root root root root root root root root root root root
PRI 15 20 15 RT RT 15 34 35 15 15 15 15 25
NI SIZE RSS SHARE STAT %CPU %MEM 0 13456 13M 9020 S 18.5 1.3 0 1176 1176 892 R 0.9 0.1 0 168 160 108 S 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0 19 0 0 0 SWN 0.0 0.0 19 0 0 0 SWN 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0
TIME CPU COMMAND 26:35 1 rhn-applet-gu 0:00 1 top 0:09 0 init 0:00 0 migration/0 0:00 1 migration/1 0:00 0 keventd 0:00 0 ksoftirqd/0 0:00 1 ksoftirqd/1 0:07 1 bdflush 1:19 0 kswapd 0:14 1 kscand 0:03 1 kupdated 0:00 0 mdrecoveryd
O resultado dividido em duas sees. A seo superior contm informaes relativas ao estado geral do sistema tempo ligado (uptime), carga mdia, contagens de processos, estado da CPU e estatsticas de utilizao da memria e do espao swap. A seo inferior apresenta estatsticas no nvel do processo. possvel alterar a exibio enquanto o top est rodando. Por exemplo: o top apresenta processos inativos e ativos por default. Para exibir somente os processos ativos, pressione [i]; pressionar novamente retorna ao modo de exibio default.
Aviso Apesar do top aparecer como um simples programa de apresentao, este no o caso. Isso ocorre porque o top usa comandos de caractere simples para executar vrias operaes. Por exemplo: se voc est autenticado como root, possvel alterar a prioridade e at mesmo terminar quaisquer processos de seu sistema. Consequentemente, at que voc reveja a tela de ajuda do top (digite [?] para apresent-la), mais seguro digitar somente [q] (que sai do comando top).
2.5.2.1. O Monitor GNOME do Sistema Um top grco Se voc prefere utilizar interfaces grcas de usurio, o Monitor GNOME do Sistema pode ser a sua escolha. Como o top, o Monitor GNOME do Sistema apresenta as informaes relacionadas ao estado geral do sistema, contagens de processos, utilizao da memria e swap e tambm estatsticas a nvel de processo. No entanto, o Monitor GNOME do Sistema vai um passo alm, incluindo tambm representaes grcas da utilizao da CPU, da memria e de swap, juntamente a uma listagem da utilizao do espao em disco em forma de tabela. Veja um exemplo da Listagem de Processos do Monitor GNOME do Sistema na Figura 2-1.
21
Figura 2-1. A Apresentao da Listagem de Processos do Monitor GNOME do Sistema possvel apresentar informaes adicionais para processos especcos; primeiro clique no processo desejado e ento clique no boto Mais Informaes (More Info). Para apresentar as estatsticas da CPU, memria e uso do disco, clique na aba Monitor do Sistema (System Monitor).
2.5.3. vmstat
Para um entendimento mais conciso do desempenho do sistema, tente o vmstat. Com o vmstat, possvel obter uma viso geral dos processos, memria, swap, I/O, sistema e das atividades da CPU numa linha de nmeros:
procs r b 0 0 memory swpd free buff cache 5276 315000 130744 380184 si 1 swap so 1 bi 2 io bo 24 in 14 system cpu cs us sy id wa 50 1 1 47 0
22
A primeira linha divide os campos em seis categorias, incluindo estatsticas do processo, da memria, swap, I/O, do sistema e da CPU. A segunda linha identica o contedo de cada campo, facilitando a busca de dados para estatsticas especcas. Os campos relativos ao processo so:
r b
O nmero de processos executveis (runnable processes) aguardando para acessar a CPU O nmero de processos num estado de dormncia contnua
Os campos relativos memria so:

swpd free buff
A quantidade de memria virtual usada A quantidade de memria livre A quantidade de memria usada para buffers A quantidade de memria usada para cache
cache
Os campos relativos swap so:

si so
A quantidade de memria enviada para swap pelo disco A quantidade de memria retirada de swap para o disco
Os campos relativos a I/O so:

bi bo
Blocos enviados a um dispositivo de bloco Blocos recebidos de um dispositivo de bloco
Os campos relativos ao sistema so:

in cs
O nmero de interrupes por segundo O nmero de mudanas de contexto por segundo
Os campos relativos CPU so:

us sy id wa
A porcentagem de tempo em que a CPU rodou cdigo a nvel do usurio A porcentagem de tempo em que a CPU rodou cdigo a nvel do sistema A porcentagem de tempo em que a CPU estava osciosa espera das I/O
Quando o vmstat executado sem nenhuma opo, apresenta somente uma linha. Essa linha contm mdias, calculadas desde a hora em que o sistema foi inicializado pela ltima vez. Entretanto, a maioria dos administradores de sistema no cona nas informaes dessa linha, j que varia o tempo ao longo do qual foram coletadas. Ao invs disso, a maioria dos administradores aproveita a habilidade do vmstat em apresentar repetidamente os dados de utilizao dos recursos em intervalos determinados. Por exemplo: o comando vmstat 1 apresenta uma nova linha com informaes de utilizao a cada segundo, enquanto o comando vmstat 1 10 apresenta uma nova linha por segundo, mas apenas nos prximos dez segundos. Nas mos de um administrador experiente, o vmstat pode ser usado para determinar rapidamente as questes de desempenho e utilizao de recursos. Mas, para ter mais conhecimento destas questes, necessrio usar um tipo diferente de ferramenta uma ferramenta capaz de coletar e analisar dados mais profundos.
23
2.5.4. O Pacote Sysstat de Ferramentas de Monitoramento dos Recursos

Enquanto as ferramentas anteriores so teis para obter mais conhecimento sobre o desempenho do sistema ao longo de perodos de tempo curtos, tm pouco uso alm de prover uma rpida visualizao da utilizao dos recursos. Alm disso, h aspectos do desempenho do sistema que no podem ser facilmente monintorados com ferramentas simplistas como estas. Sendo assim, necessrio uma ferramenta mais sosticada. Sysstat essa ferramenta. Sysstat contm as seguintes ferramentas relacionadas obteno de estatsticas de I/O e CPU:
iostat
Apresenta uma viso geral da utilizao da CPU, junto s estatsticas de I/O de um ou mais drives de disco.
mpstat
Apresenta estatsticas mais profundas da CPU. Sysstat tambm contm ferramentas que coletam dados de utilizao dos recursos do sistema e criam relatrios dirios baseados nestes dados. Estas ferramentas so:
sadc
Conhecido como o coletor de dados de atividade do sistema, o sadc coleta informaes da utilizao dos recursos do sistema e as grava num arquivo.
sar
Os relatrios do sar so criados a partir de arquivos do sadc, e podem ser gerados interativamente ou gravados num arquivo para uma anlise mais intensa. As sees seguintes exploram cada uma destas ferramentas mais detalhadamente. 2.5.4.1. O comando iostat O comando iostat, em sua forma mais bsica, oferece uma viso geral das estatsticas da CPU e operaes I/O do disco:
Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) avg-cpu: %user 6.11 %nice 2.56 tps 1.68 %sys 2.15 %idle 89.18 Blk_wrtn/s 22.42 Blk_read 31175836 Blk_wrtn 44543290 07/11/2003
Device: dev3-0
Blk_read/s 15.69
Abaixo da primeira linha (que contm a verso do kernel do sistema e o nome da mquina, junto data corrente), o iostat apresenta uma viso geral da utilizao mdia da CPU do sistema desde a ltima inicializao. O relatrio de utilizao da CPU inclui as seguintes porcentagens:

Porcentagem do tempo gasto no modo usurio (rodando aplicaes, etc) Porcentagem do tempo gasto no modo usurio (para processos que alteraram suas prioridades de agendamento usando o nice(2)) Porcentagem do tempo gasto no modo kernel Porcentagem do tempo inativo
24
O relatrio de utilizao do dispositivo est abaixo do relatrio de utilizao da CPU. Este relatrio contm uma linha para cada dispositivo de disco ativo no sistema e inclui as seguintes informaes:
comeando por zero.
um nmero sequencial
maior-nmero
O nmero de transferncias (ou operaes I/O) por segundo. O nmero de blocos de 512 bytes acessados por segundo. O nmero de blocos de 512 bytes gravados por segundo. O nmero total de blocos de 512 bytes acessados. O nmero total de blocos de 512 bytes gravados.
Esta apneas uma amostra das informaes que podem ser obtidas usando o iostat. Para mais informaes, consulte a pgina man iostat(1). 2.5.4.2. O comando mpstat primeira vista, o comando mpstat no parece ser diferente do relatrio de utilizao da CPU produzido pelo iostat:
Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 07:09:26 PM 07:09:26 PM CPU all %user 6.40 %nice %system 5.84 3.29 %idle 84.47 intr/s 542.47 07/11/2003
Alm da coluna adicional com as interrupes por segundo resolvidas pela CPU, no h diferena real. No entanto, a situao muda se a opo -P ALL do mpstat for usada:
Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 07:13:03 07:13:03 07:13:03 07:13:03 PM PM PM PM CPU all 0 1 %user 6.40 6.36 6.43 %nice %system 5.84 3.29 5.80 3.29 5.87 3.29 %idle 84.47 84.54 84.40 intr/s 542.47 542.47 542.47 07/11/2003
Em sistemas com multi-processadores, o mpstat permite exibir a utilizao de cada CPU separadamente, possibilitando determinar o quo efetivamente cada CPU usada. 2.5.4.3. O comando sadc Conforme mencionado anteriormente, o comando sadc coleta dados de utilizao do sistema e os grava num arquivo para anlise posterior. Por default, os dados so gravados em arquivos no diretrio /var/log/sa/. Os arquivos so nomeados como sa dd , onde dd a data do dia corrente em dois dgitos. O sadc normalmente executado pelo script do sa1. Esse script periodicamente invocado pelo cron atravs do arquivo sysstat, localizado em /etc/cron.d/. O script sa1 invoca o sadc para
3. Os nmeros maiores do dispositivos podem ser obtidos usando ls -l para exibir o arquivo do dispositivo
desejado em /dev/. O maior nmero aparece aps a especicao do grupo do dispositivo.
onde dev maior-nmero -nmero-sequencial, o maior nmero do dispositivo3 e nmero-sequencial
especicao
do
dispositivo
apresentada
como
25
um nico intervalo de medio de um segundo. Por default, o cron roda o sa1 a cada 10 minutos, adicionando os dados coletados durante cada intervalo ao arquivo /var/log/sa/sa dd corrente. 2.5.4.4. O comando sar O comando sar produz relatrios de utilizao do sistema baseados nos dados coletados pelo sadc. Conforme congurado no Red Hat Enterprise Linux, o sar automaticamente executado para processar os arquivos automaticamente coletados pelo sadc. Os arquivos de relatrios so gravados em /var/log/sa/ e so nomeados como sar dd , onde dd a representao de dois dgitos da data do dia anterior. O sar normalmente executado pelo script do sa2. Esse script periodicamente invocado pelo cron atravs do arquivo sysstat, localizado em /etc/cron.d/. Por default, o cron roda o sa2 uma vez por dia, s 23:53, permitindo que produza um relatrio com os dados do dia todo. 2.5.4.4.1. Acessando Relatrios do sar O formato de um relatrio do sar produzido pela congurao default do Red Hat Enterprise Linux consiste de sees mltiplas, e cada seo contm um tipo de dado especco, ordenado pela hora do dia em que o dado foi coletado. Como o sadc congurado para efetuar um intervalo de medio de um segundo a cada dez minutos, o relatrio default do sar contm dados em blocos de dez minutos, de 00:00 a 23:504. Cada seo do relatrio inicia com um cabealho descrevendo os dados contidos na seo. O cabealho repetido em intervalos regulares ao longo da seo, facilitando interpretar os dados enquanto navegamos no relatrio. Cada seo termina com uma linha contendo a mdia dos dados reportados na seo. Veja um exemplo de seo do relatrio do sar, com os dados de 00:30 a 23:40 removidos para economizar espao:
00:00:01 00:10:00 00:20:01 ... 23:50:01 Average: CPU all all all all %user 6.39 1.61 44.07 5.80 %nice 1.96 3.16 0.02 4.99 %system 0.66 1.09 0.77 2.87 %idle 90.98 94.14 55.14 86.34
Nesta seo so apresentadas as informaes de utilizao da CPU. Estas so bem similares s informaes apresentadas pelo iostat. Outras sees talvez tenham mais de uma linha de dados por vez, conforme exibido nesta seo gerada a partir dos dados de utilizao da CPU, coletados num sistema de processador duplo:
00:00:01 00:10:00 00:10:00 00:20:01 00:20:01 ... 23:50:01 23:50:01 Average: Average: CPU 0 1 0 1 0 1 0 1 %user 4.19 8.59 1.87 1.35 42.84 45.29 6.00 5.61 %nice 1.75 2.18 3.21 3.12 0.03 0.01 5.01 4.97 %system 0.70 0.63 1.14 1.04 0.80 0.74 2.74 2.99 %idle 93.37 88.60 93.78 94.49 56.33 53.95 86.25 86.43
4.
Devido dinmica das cargas de sistema, a hora real na qual os dados foram coletados pode variar em um
segundo ou dois.
26
H um total de dezessete sees diferentes presentes nos relatrios gerados pela congurao default do sar no Red Hat Enterprise Linux. Algumas destas sees so abordadas nos prximos captulos. Para mais informaes sobre os dados contidos em cada seo, consulte a pgina man sar(1).
2.5.5. OProle
O perlador do sistema OProle uma ferramenta de monitoramento de baixa sobrecarga. O OProle utiliza o hardware de monitoramento do desempenho do processador 5 para determinar a natureza de problemas relativos ao desempenho. O hardware de monitoramento do desempenho parte do prprio processador. Tem a forma de um contador especial, aumentando cada vez que um determinado evento (como o processador estar ativo ou os dados desejados no serem enviados ao cache) ocorre. Alguns processadores tem mais de um contador como esse, e permitem a seleo de tipos de eventos diferentes para cada contador. Os contadores podem ser carregados com um valor inicial e produzir uma interrupo sempre que o contador ultrapassar o limite. Ao carregar um contador com valores iniciais diferentes, possvel variar a taxa de produo de interrupes. Dessa maneira, possvel controlar a taxa de controle e, consequentemente, o nvel de detalhe obtido atravs dos dados coletados. Em um extremo, ajustar o contador para gerar uma interrupo de sobrecarga com todos os eventos, oferece dados de desempenho extremamente detalhados (mas com sobrecarga massiva). No outro extremo, ajustar o contador para gerar o menor nmero de interrupes possvel, oferece apenas uma viso genrica do desempenho do sistema (com praticamente nenhuma sobrecarga). O segredo do monitoramento efetivo a seleo de uma taxa limite sucientemente alta para capturar os dados necessrios, mas no to alta a ponto de sobrecarregar o sistema com a sobrecarga de monitoramento do desempenho.
Aviso Voc poode congurar o OProle para produzir sobrecarga suciente a m de tornar o sistema inutilizvel. Consequentemente, voc deve tomar cuidado ao selecionar os valores limite. Por este motivo, o comando opcontrol suporta a opo --list-events, que apresenta os tipos de evento disponveis para o processador instalado, junto a valores limite mnimos sugeridos para cada evento.
importante ter em mente a diculdade de equilbrio entre a taxa limite e a sobrecarga ao usar o OProle. 2.5.5.1. Componentes do OProle O Oprole consiste dos seguintes componentes:

Software de coleta de dados Software de anlise de dados Software de interface administrativa
O software de coleta de dados consiste do mdulo oprofile.o do kernel e do daemon oprofiled. O software de anlise de dados inclui os seguintes programas:
5. O OProle tambm pode usar um mecanismo de fallback (conhecido como TIMER_INT) para aquelas
arquiteturas de sistema que no tm hardware de monitoramento do desempenho.
27
op_time
Exibe o nmero e porcentagens relativas de amostras obtidas para cada arquivo executvel
oprofpp
Exibe o nmero e porcentagem relativa obtida pela instruo individual ou pelo output no estilo do gprof.
op_to_source
Exibe o cdigo fonte comentado e/ou as listagens de cdigo do assembly

op_visualise
Exibe gracamente os dados coletados Estes programas possibilitam exibir os dados coletados de diversas formas. O software de interface administrativa controla todos os aspectos da coleta de dados, da especicao dos eventos a serem monitorados ao incio e parada da prpria coleta. Isso feito usando o comando opcontrol. 2.5.5.2. Uma Amostra de Sesso do OProle Esta amostra exibe uma sesso de monitoramento e anlise de dados da congurao inicial anlise de dados nal. apenas uma viso geral introdutria; para mais informaes, consulte o Guia de Administrao de Sistemas Red Hat Enterprise Linux. Use o opcontrol para congurar o tipo de dados a serem coletados com o seguinte comando:
opcontrol \ --vmlinux=/boot/vmlinux-uname -r \ --ctr0-event=CPU_CLK_UNHALTED \ --ctr0-count=6000
As opes usadas aqui direcionam o opcontrol para:

Direcionar o OProle para uma cpia (--vmlinux=/boot/vmlinux-uname -r)
do
kernel
rodando
no
momento
Especicar que o contador 0 do processador deve ser usado e que o evento a ser monitorado o tempo em que a CPU est executando instrues (--ctr0-event=CPU_CLK_UNHALTED) Especicar que o OProle deve coletar amostras a cada 6000 vezes que o evento especicado ocorrer (--ctr0-count=6000)
Em seguida, verique se o mdulo oprofile do kernel est carregado usando o comando lsmod:
Module oprofile ... Size 75616 Used by 1 Not tainted
Conrme se o sistema de arquivo do OProle (localizado em /dev/oprofile/) est montado com o comando ls /dev/oprofile/:
0 1 buffer buffer_size buffer_watershed cpu_buffer_size cpu_type dump enable kernel_only stats
(O nmero exato de arquivos varia de acordo com o tipo de processador.)
28
Neste ponto, o arquivo /root/.oprofile/daemonrc contm os ajustes necessrios para o software de coleta de dados:
CTR_EVENT[0]=CPU_CLK_UNHALTED CTR_COUNT[0]=6000 CTR_KERNEL[0]=1 CTR_USER[0]=1 CTR_UM[0]=0 CTR_EVENT_VAL[0]=121 CTR_EVENT[1]= CTR_COUNT[1]= CTR_KERNEL[1]=1 CTR_USER[1]=1 CTR_UM[1]=0 CTR_EVENT_VAL[1]= one_enabled=1 SEPARATE_LIB_SAMPLES=0 SEPARATE_KERNEL_SAMPLES=0 VMLINUX=/boot/vmlinux-2.4.21-1.1931.2.349.2.2.entsmp
Em seguida, use opcontrol para iniciar a coleta de dados com o comando opcontrol --start:
Using log file /var/lib/oprofile/oprofiled.log Daemon started. Profiler running.
Verifque se o daemon oprofiled est rodando com o comando ps x | grep -i oprofiled:

32019 ? 32021 pts/0 S S 0:00 /usr/bin/oprofiled --separate-lib-samples=0 ... 0:00 grep -i oprofiled
(A linha de comando oprofiled apresentada pelo ps bem mais longa; no entanto, foi truncada aqui por motivos de formatao.) Agora o sistema est sendo monitorado, com coleta de dados para todos os executveis presentes no sistema. Os dados so armazenados no diretrio /var/lib/oprofile/samples/. Os arquivos desse diretrio seguem uma conveno de nomes fora do comum. Aqui est um exemplo:
}usr}bin}less#0
A conveno de nomes usa a localidade absoluta de cada arquivo contendo cdigo executvel, com os caracteres barra (/) substitudos por chaves nais (}), e terminando com um jogo da velha (#) seguido por um nmero (0, neste caso.) Consequentemente, o arquivo usado neste exemplo representa os dados coletados enquanto o /usr/bin/less estava rodando. Aps a coleta dos dados, use uma das ferramentas de anlise para exib-los. O OProle tem a vantagem de no precisar parar a coleta de dados antes de executar a anlise de dados. No entanto, voc deve esperar que pelo menos um conjunto de amostras seja gravado no disco, ou use o comando opcontrol --dump para forar as amostras no disco. No exemplo a seguir, o op_time usado para exibir (em ordem inversa do maior nmero de amostras ao menor) as amostras que foram coletadas.
3321080 761776 368933 293570 205231 167575 123095 105677 48.8021 11.1940 5.4213 4.3139 3.0158 2.4625 1.8088 1.5529 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 /boot/vmlinux-2.4.21-1.1931.2.349.2.2.entsmp /usr/bin/oprofiled /lib/tls/libc-2.3.2.so /usr/lib/libgobject-2.0.so.0.200.2 /usr/lib/libgdk-x11-2.0.so.0.200.2 /usr/lib/libglib-2.0.so.0.200.2 /lib/libcrypto.so.0.9.7a /usr/X11R6/bin/XFree86
29
...
Usar less uma boa idia ao produzir um relatrio interativamente, j que este pode ter centenas de linhas. O exemplo ilustrado aqui foi truncado por este motivo. O formato desse relatrio especco consiste na produo de uma linha para cada arquivo executvel dos quais as amostras foram retiradas. Cada linha segue este formato:
sample-count sample-percent unused-field executable-name
Onde:

sample-count
representa o nmero de amostras coletadas
cutvel especco
sample-percent
representa a porcentagem de todas as amostras coletadas para esse exe-
campo-no-usado executable-name
um campo que no est usado
representa o nome do arquivo contendo cdigo executvel para o qual as amostras foram coletadas.
Esse relatrio (produzido num sistema inativo na maior parte do tempo) mostra que quase metade das amostras foram coletadas enquanto a CPU estava rodando cdigo dentro do prprio kernel. Em seguida, na linha, est o dameon de coleta de dados do OProle, seguido por diversas bibliotecas e do servidor do Sistema X Window, o XFree86. Vale notar que, para o sistema rodar essa seo de amostra, o valor de 6000 usado no contador representa o valor mnimo recomendado pelo opcontrol --list-events. Isso signica que pelo menos para este sistema em particular a sobrecarga do OProle no seu pice consome aproximadamente 11% da CPU.

Esta seo inclui diversas fontes que podem ser usadas para aprender mais sobre o monitoramento de recursos do sistema e suas especicidades no Red Hat Enterprise Linux.

Os seguintes recursos so instalados no decorrer de uma instalao tpica do Red Hat Enterprise Linux.

Pgina man free(1) Aprenda a exibir as estatsticas de memria livre e usada. Pgina man top(1) Aprenda a exibir as estatsticas no nvel de processo e de utilizao da CPU. Pgina man watch(1) Aprenda a executar periodicamente o programa especicado pelo usurio, exibindo output na tela inteira. Entrada Help no menu do Monitor GNOME do Sistema Aprenda a exibir gracamente as estatsticas de processos, utilizao da CPU, memria e de espao em disco. Pgina man vmstat(8) Aprenda a exibir uma viso geral concisa dos processos, memria, swap, I/O, sistema e utilizao da CPU. Pgina man iostat(1) Aprenda a exibir as estatsticas da CPU e I/O. Pgina man mpstat(1) Aprenda a exibir as estatsticas das CPUs separadamente em sistemas multi-processadores. Pgina man sadc(8) Aprenda a coletar dados de utilizao do sistema. Pgina man sa1(8) Aprenda sobre um script que roda o sadc periodicamente.

30
Captulo 2. Monitoramento de Recursos Pgina man sar(1) Aprenda como produzir relatrios de utilizao dos recursos do sistema. Pgina man sa2(8) Aprenda a produzir arquivos com relatrios dirios de utilizao dos recursos do sistema. Pgina man nice(1) Aprenda como alterar a prioridade de agendamento do processo. Pgina man oprofile(1) Aprenda a traar o perl do desempenho do sistema. Pgina man op_visualise(1) Aprenda a exibir gracamente os dados do OProle.
2.6.2. Sites teis
http://people.redhat.com/alikins/system_tuning.html Informaes de Ajuste do Sistema para Servidores Linux. Uma ttica conscienciosa para o ajuste do desempenho e monitoramento de recursos em servidores. http://www.linuxjournal.com/article.php?sid=2396 Ferramentas de Monitoramento do Desempenho para Linux. Mais direcionada ao administrador interessado em elaborar uma soluo grca de desempenho personalizada. Como foi escrita h muitos anos, alguns de seus detalhes talvez estejam obsoletos, mas o conceito e execuo gerais ainda funcionam. http://oprole.sourceforge.net/ O site do projeto OProle. Inclui recursos valiosos do OProle, incluindo links para listas de discusso e para o canal IRC do #oprole.

Os livros seguintes abordam diversas questes relativas ao monitoramento de recursos e so boas fontes para administradores de sistemas Red Hat Enterprise Linux:
O Guia de Administrao de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. Inclui informaes sobre muitas das ferramentas de monitoramento de recursos descritas aqui, incluindo o OProle. Linux Performance Tuning and Capacity Planning de Jason R. Fink e Matthew D. Sherer; Sams Oferece vises mais profundas das ferramentas de monitoramento de recursos aqui abordadas e inclui outras que podem ser mais apropriadas para necessidades especcas de monitoramento de recursos. Red Hat Linux Security and Optimization de Mohammed J. Kabir; Red Hat Press Aproximadamente, as primeiras 150 pginas desse livro abordam questes relativas ao desempenho. Isso inclui captulos dedicados s questes de desempenho especcas para rede, Internet, e-mail e servidores de arquivo. Linux Administration Handbook de Evi Nemeth, Garth Snyder, e Trent R. Hein; Prentice Hall Oferece um captulo curto com escopo similar ao desse livro, mas inclui uma seo interessante sobre o diagnstico de um sistema que apresenta lentido repentinamente. Linux System Administration: A Users Guide de Marcel Gagne; Addison Wesley Professional Contm um pequeno captulo sobre o monitoramento e ajuste do desemepenho.
Captulo 3.
Largura de Banda e Poder de Processamento
Dentre os dois recursos abordados neste captulo, um (largura de banda) , frequentemente, de difcil compreenso para administradores de sistemas, enquanto o outro (poder de processamento) um conceito geralmente fcil de entender. Aparentemente, estes dois recursos no tem nenhuma relao prxima por que junt-los? A razo para abordar ambos recursos conjuntamente que os dois so baseados no hardware diretamente ligado habilidade do computador em mover e processar dados. Sendo assim, suas funes so frequentemente relacionadas.
3.1. Largura de Banda

Basicamente, largura de banda a capacidade de transferncia de dados em outras palavras, a quantidade de dados que pode ser movida de um ponto a outro num determinado perodo de tempo. Ter comunicao ponto-a-ponto implica em duas coisas:

Um conjunto de condutores eltricos usado para possiblitar a comunicao de nvel baixo Um protocolo para facilitar a comunicao de dados eciente e convel
H dois tipos de componentes de sistema que atendem estes requisitos:

Canais (buses) Centrais de Dados (Datapaths)
As sees a seguir exploram cada um em detalhes.
3.1.1. Canais (buses)

Conforme explanado anteriormente, os canais possibilitam a comunicao ponto-a-ponto e utilizam alguma espcie de protocolo para garantir que toda a comunicao ocorra de forma controlada. No entanto, os canais tm outras caractersticas distintas:

Caractersticas eltricas padronizadas (tais como nmero de condutores, nveis de voltagem, velocidades de sinalizao, etc.) Caractersticas mecnicas padronizadas (tais como tipo de conector, tamanho da placa, aparncia fsica, etc.) Protocolo padronizado
A palavra "padronizado" importante porque os canais so a principal forma de conexo entre diferentes componentes do sistema. Em muitos casos, os canais (buses) permitem interconectar hardware produzido por diversos fabricantes; sem a padronizao, isto no seria possvel. No entanto, mesmo nas situaes onde um canal de propriedade de um fabricante, a padronizao possibilita que este fabricante implemente outros componentes facilmente, usando uma interface comum o prprio canal.
32 3.1.1.1. Exemplos de Canais
Captulo 3. Largura de Banda e Poder de Processamento
No importa o local do sistema em questo; sempre h canais. Aqui esto alguns dos canais mais comuns:

Canais de armazenamento em massa (ATA e SCSI) Redes1 (Ethernet e Token Ring) Canais de memria (PC133 e Rambus) Canais de expanso (PCI, ISA, USB)
3.1.2. Centrais de Dados (Datapaths)

As centrais de dados (datapaths) podem ser mais difceis de identicar, mas, assim como os canais, elas esto em todo lugar. Como os canais, elas tambm possibilitam a comunicao ponto-a-ponto. Entretanto, ao contrrio dos canais, as centrais de dados:

Usam um protocolo mais simples (se houver) Tm pouca (ou nenhuma) padronizao mecnica
A razo destas diferenas que as centrais de dados (datapaths) normalmente fazem parte de algum componente do sistema e no so usadas para facilitar a interconexo improvisada de diferentes componentes. Como tais, as centrais de dados so altamente otimizadas para uma situao especca, na qual a velocidade e o baixo custo tm prioridade sobre a lentido e exibilidade de componentes mais caros. 3.1.2.1. Exemplos de Centrais de Dados (Datapaths) Aqui esto algumas centrais de dados tpicas:

central de dados da CPU para cache no chip (CPU to on-chip cache datapath) Processador grco para a central de dados da memria de vdeo
3.1.3. Problemas Potenciais Relacionados Largura de Banda

Os problemas relacionados largura de banda podem ocorrer de duas maneiras (para ambos, canais ou centrais de dados): 1. O canal ou central de dados pode representar um recurso compartilhado. Neste caso, os altos nveis de conteno do canal reduzem a largura de banda efetivamente disponvel para todos os dispositivos no canal. Um canal SCSI com diversos drives de disco altamente ativos seria um bom exemplo disto. Os drives de disco altamente ativos saturam o canal SCSI, deixando pouca banda disponvel para qualquer outro dispositivo no mesmo canal. O resultado nal que todas as I/O de qualquer dispositivo neste canal so lentas, mesmo que cada dispositivo no canal no esteja sobrecarregado. 2. O canal ou central de dados (datapath) pode ser um recurso dedicado com um nmero xo de dispositivos anexos. Neste caso, as caractersticas eltricas do canal (e at certo ponto, a natureza do protocolo utilizado) limitam a banda disponvel. Este caso geralmente ocorre mais
1. Ao invs de um canal intra-sistema, as redes podem ser encaradas como um canal inter-sistema.
33
frequentemente com centrais de dados que com canais. Esta uma das razes pelas quais os adaptadores grcos tendem a operar mais lentamente com denio e resoluo de cores mais altas para cada recarregamento da tela (refresh), h mais dados a serem passados atravs da central de dados conectando a memria de vdeo e o processador grco.
3.1.4. Solues Potenciais Relacionadas Largura de Banda (Bandwidth)

Felizmente, os problemas relacionados largura de banda podem ser solucionados. Na realidade, h diversas tticas para isso:

Distribuir a carga Reduzir a carga Aumentar a capacidade
As sees seguinites exploram cada uma das tticas detalhadamente. 3.1.4.1. Distribuir a Carga A primeira ttica distribuir a atividade do canal de forma mais balanceada. Em outras palavras, se um canal est sobrecarregado e um outro est ocioso, a situao pode ser melhorada ao mover parte da carga para o canal ocioso. Como administrador de sistemas, esta a primeira ttica a considerar, j que h canais adicionais frequentemente presentes em seu sistema. Por exemplo: a maioria dos PCs incluem ao menos dois canais ATA. Se voc tiver dois drives de disco ATA e dois canais ATA, por que os dois drives devem estar no mesmo canal? Mesmo se a congurao de seu sistema no incluir canais adicionais, distribuir a carga ainda uma ttica razovel. Os custos de hardware para isso so menores que os custos de uma substituio de um canal existente por hardware de capacidade maior. 3.1.4.2. Reduzir a Carga primeira vista, reduzir e distribuir a carga parecem ser dois lados da mesma moeda. Anal de contas, quando algum distribui a carga, age para a reduo da mesma (ao menos no canal sobrecarregado), certo? Apesar deste ponto de vista ser correto, no o mesmo que reduzir a carga globalmente. A questo aqui determinar se h algum aspecto da carga do sistema que esteja causando a sobrecarga do canal especco. Por exemplo: uma rede est altamente carregada devido a atividades desnecessrias? Talvez, um pequeno arquivo temporrio seja o recipiente de aes de leitura/gravao I/O pesadas. Se este arquivo temporrio reside num servidor de arquivos em rede, uma grande quantidade de trfego de rede pode ser eliminada ao trabalhar com o arquivo localmente. 3.1.4.3. Aumentar a Capacidade A soluo bvia para banda insuciente aument-la de alguma maneira. No entanto, esta uma alterantiva cara. Considere, por exemplo, um controlador SCSI e seu canal sobrecarregado. Para aumentar sua banda, o controlador SCSI (e provavelmente todos os dispositivos anexos) precisar ser trocado por hardware mais rpido. Se o controlador SCSI for uma placa separada, este ser um processo relativamente simples, mas se o controlador SCSI for parte da placa-me do sistema, ser mais difcil justicar a economia desta troca.
34
3.1.5. Em Suma. . .
Todos os administradores de sistemas devem estar cientes da largura de banda (bandwidth) e de como a congurao e o uso do sistema impactam na banda disponvel. Infelizmente, nem sempre aparente o que um problema relacionado largura de banda e o que no . s vezes, o problema no o canal, mas um dos componentes anexos a este. Por exemplo: considere um adaptador SCSI conectado a um canal PCI. Se h problemas de desempenho com o disco I/O SCSI, pode ser resultado de um adaptador SCSI com baixo desempenho, mesmo que os canais SCSI e PCI no estejam prximos de suas capacidades de largura de banda.
3.2. Poder de Processamento

Frequentemente conhecido como poder da CPU, ciclos da CPU e vrios outros nomes, poder de processamento a habilidade do computador em manipular dados. O poder de processamento varia de acordo com a arquitetura (e velocidade do relgio) da CPU geralmente, as CPUs com velocidades de relgio maiores que suportam tamanhos de palavra maiores tm maior poder de processamento que as CPUs mais lentas suportando tamanhos de palavra menores.
3.2.1. Fatos Sobre o Poder de Processamento

Aqui esto os dois principais fatos sobre o poder de processamento que voc deve ter em mente:

O poder de processamento xo O poder de processamento no pode ser armazenado
O poder de processamento xo, de modo que a CPU s pode atingir tal velocidade. Por exemplo: se voc precisa adicionar dois nmeros (uma operao que requer apenas uma instruo para a mquina, na maioria das arquiteturas), uma determinada CPU pode faz-la somente a uma velocidade. Com raras excees, no possvel diminuir a taxa com a qual a CPU processa as instrues, muito menos aument-la. O poder de processamento xo tambm de uma outra maneira: nito. Ou seja, h limites para os tipos de CPUs que podem ser conectadas a um determinado computador. Alguns sistemas so capazes de suportar uma grande variedade de CPUs com velocidades diferentes, enquanto outros podem no ser atualizveis (upgradeable)2 . O poder de processamento no pode ser armazenado para uso posterior. Em outras palavras, se uma CPU pode processar 100 milhes de instrues em um segundo, um segundo de tempo ocioso equivalem a 100 milhes de instrues de processamento que foram disperdiadas. Se examinarmos estes fatos sob uma perspectiva ligeiramente diferente, uma CPU "produz" um uxo de instrues executadas a uma taxa xa. E, se a CPU "produz" instrues executadas, isto siginifca que alguma outra coisa deve "consum-las". A prxima seo dene estes consumidores.
3.2.2. Consumidores do Poder de Processamento

H dois consumidores principais do poder de processamento:

Aplicaes O prprio sistema operacional

Esta situao acarreta no que chamado de forklift upgrade, o que signica uma troca completa de um
2.
computador.
Captulo 3. Largura de Banda e Poder de Processamento 3.2.2.1. Aplicaes
35
Os consumidores mais bvios do poder de processamento so as aplicaes e os programas que voc quer que o computador rode. De uma planilha de cculo a um banco de dados, as aplicaes so as razes pelas quais voc tem um computador. Um sistema com uma CPU pode fazer apenas uma coisa de cada vez. Consequentemente, se a sua aplicao est rodando, todo o resto do sistema no est. Obviamente, o contrrio tambm verdade se alguma outra coisa alm da sua aplicao est rodando, ento sua aplicao no est fazendo nada. Mas, como que muitas aplicaes diferentes aparentemente rodam ao mesmo tempo num sistema operacional moderno? A resposta que estes so sistemas operacionais multi-tarefas. Em outras palavras, eles criam a iluso de que muitas coisas diferentes esto acontecendo simultaneamente, apesar de isto no ser possvel de fato. O truque dar a cada processo o tempo rodando na CPU de uma frao de segundo antes de dar a prxima frao de um segundo a um outro processo. Se estas trocas de contexto ocorrerem com bastante frequncia, tem-se a iluso de que mltiplas aplicaes esto rodando simultaneamente. Obviamente, as aplicaes fazem outras coisas alm de manipular dados usando a CPU. Elas podem esperar pelo input do usurio, assim como desempenhar I/O a dispositivos como drives de disco e displays grcos. Quando estes eventos ocorrem, a aplicao no precisa mais da CPU. Nestas horas, a CPU pode ser usada para outros processos rodando outras aplicaes, sem atrasar a aplicao em espera. Alm disso, a CPU pode ser usada por um outro consumidor do poder de processamento: o prprio sistema operacional. 3.2.2.2. O Sistema Operacional difcil determinar o quanto de poder de processamento consumido pelo sistema operacional porque este utiliza uma mistura de cdigos a nvel de processo e a nvel de sistema para desempenhar seu trabalho. Apesar de ser fcil, por exemplo, usar um monitor de processos para determinar o que os processos rodando um daemon ou servio esto fazendo, no fcil determinar o quanto de poder de processamento est sendo consumido pelo processamento relacionado a I/O a nvel do sistema (o que normalmente feito no contexto do processo requisitando a I/O.) Em geral, possvel dividir esta espcie de sobrecarga do sistema em dois tipos:

Manuteno (housekeeping) do sistema operacional Atividades relacionadas a processos
A manuteno do sistema operacional inclui atividades como o agendamento de processos e a administrao da memria, enquanto as atividades relacionadas a processos incluem quaisquer processos que suportam o sistema operacional, tais como o registro de eventos do sistema ou nivelamento do cache I/O.
3.2.3. Suprindo a Falta da uma CPU

Quando h poder de processamento insuciente para o trabalho que precisa ser feito, voc tem duas opes:

Reduzir a carga Aumentar a capacidade
36 3.2.3.1. Reduzir a Carga
Reduzir a carga da CPU algo que pode ser feito sem nenhum custo adicional. Basta identicar os aspectos da carga do sistema sob seu controle que podem ser reduzidos. H trs reas nas quais focar:

Reduzir a sobrecarga do sistema operacional Reduzir a sobrecarga das aplicaes Eliminar as aplicaes inteiramente
3.2.3.1.1. Reduzir a Sobrecarga do Sistema Operacional Para reduzir a sobrecarga do sistema operacional, necessrio examinar a carga atual do sistema e determinar quais aspectos desta resultam em quantidades desordenadas de sobrecarga. Estas reas podem incluir:

Reduzir a necessidade do agendamento de processos frequente Reduzir a quantidade das I/O desempenhadas
No espere milagres; num sistema razoavelmente bem congurado, improvvel notar um grande aumento de desempenho ao tentar reduzir a sobrecarga do sistema operacional. Isto se deve ao fato de que um sistema razoavelmente bem congurado, por denio, resulta numa quantidade mnima de sobrecarga. No entanto, se o seu sistema est rodando com muito pouca RAM, por exemplo, voc talvez consiga reduzir a sobrecarga aliviando a falta de RAM. 3.2.3.1.2. Reduzir a Sobrecarga das Aplicaes Reduzir a sobrecarga de uma aplicao signica garantir que esta tenha tudo o que precisa para rodar bem. Algumas aplicaes apresentam comportamentos bem diferentes sob ambientes diferentes por exemplo: uma aplicao pode tornar-se altamente integrada ao computador ao processar certos tipos de dados, e com outros dados no. Deve-se manter em mente que voc precisa entender sobre as aplicaes rodando no seu sistema se pretende que elas rodem da maneira mais eciente possvel. Frequentemente, isto inclui trabalhar com seus usurios, e/ou com os desenvolvedores da sua empresa, para ajudar a descobrir maneiras pelas quais as aplicaes podem rodar mais ecientemente. 3.2.3.1.3. Eliminar Aplicaes Inteiramente Dependendo da sua empresa, esta ttica pode no estar disponvel, j que frequentemente no de responsabilidade do administrador de sistemas ditar quais aplicaes devem ou no rodar. Entretanto, se voc puder identicar aplicaes que so "CPU hogs" conhecidas, pode inuenciar os tomadores de deciso a aposent-las. Executar esta tarefa provavelmente envolver mais algum alm de voc. Os usurios afetados devem certamente fazer parte deste processo; em muitos casos eles talvez tenham o conhecimento e o poder poltico para efetuar as mudanas no mbito das aplicaes.
Dica Tenha em mente que uma aplicao talvez no precise ser eliminada de todos os sistemas de sua empresa. Voc pode transferir uma determinada aplicao que requer muito da CPU de um sistema sobrecarregado para outro sistema quase ocioso.
Captulo 3. Largura de Banda e Poder de Processamento 3.2.3.2. Aumentar a Capacidade
37
Obviamente, se no for possvel reduzir a demanda de poder de processamento, voc deve encontrar outras maneiras de aument-lo. necessrio dinheiro para fazer isso, mas pode ser feito. 3.2.3.2.1. Atualizando a CPU (upgrade) A ttica mais simples determinar se a CPU do seu sistema pode ser atualizada. O primeiro passo determinar se a CPU atual pode ser removida. Alguns sistemas (principalmente laptops) tm CPUs soldadas, impossibilitando uma atualizao. O resto, no entanto, tem CPUs anexas, o que possibilita as atualizaes pelo menos em tese. Em seguida, voc deve pesquisar se existe uma CPU mais rpida para a congurao de seu sistema. Por exemplo: se voc tem uma CPU de 1GHz e h uma unidade de 2GHz do mesmo tipo, pode ser possvel efetuar a atualizao. Finalmente, voc deve determinar a velocidade mxima do relgio suportada pelo seu sistema. Continuando o exemplo acima, mesmo se existir uma CPU do tipo apropriado de 2GHz, no ser possvel trocar a CPU se seu sistema suportar somente processadores de 1GHz ou menos. Se voc concluir que no possvel instalar uma CPU mais rpida no seu sistema, suas opes talvez estejam limitadas troca de placas-me ou at mesmo ao forklift upgrade (troca completa do computador) mencionado anteriormente. No entanto, algumas conguraes do sistema possibilitam uma ttica ligeiramente diferente. Ao invs de trocar a CPU atual, por que no adicionar outra? 3.2.3.2.2. Ser que o Multiprocessamento Simtrico (Symmetric Multiprocessing) Serve para Voc? O multiprocessamento simtrico (tambm conhecido como SMP, Symmetric Multiprocessing) possibilita que um sistema de computador tenha mais de uma CPU compartilhando todos os recursos do sistema. Isto signica que, ao contrrio do sistema com um processador, um sistema SMP pode ter mais de um processo rodando ao mesmo tempo. primeira vista, este parece ser um sonho para o administrador de sistemas. Antes de mais nada, o SMP possibilita aumentar o poder da CPU de um sistema, mesmo que no exista CPUs com velocidades de relgio maiores basta adicionar outra CPU. Entretanto, esta exibilidade traz algumas desvantagens. A primeira desvantagem que nem todos os sistemas so capazes de efetuar a operao SMP. Seu sistema precisa ter uma placa-me desenvolvida para suportar processadores mltiplos. Se no for o caso, ser necessrio uma atualizao da placa-me (no mnimo). A segunda desvantagem que o SMP aumenta a sobrecarga do sistema. Isto faz sentido se pararmos para pensar - tendo mais CPUs para agendar trabalho, o sistema operacional requer mais ciclos da CPU para a sobrecarga. Outro aspecto que, com CPUs mltiplas, pode haver mais conteno dos recursos do sistema. Devido estes fatores, atualizar um sistema com dois processadores para uma unidade de quatro processadores no resulta num aumento de 100% do poder da CPU. De fato, dependendo do hardware atual, da carga e da arquitetura do processador, possvel atingir um estgio no qual a adio de um outro processador pode, na realidade, reduzir o desempenho do sistema. Um outro aspecto para ter em mente que o SMP no ajuda cargas de trabalho que consistem de uma aplicao monoltica com um uxo de execuo. Ou seja, se um programa de simulao integrado ao computador roda como um processo e sem encadeamentos, no rodar mais rpido em um sistema SMP do que numa mquina com um processador. De fato, pode at rodar um pouco mais lentamente, devido ao aumento de sobrecarga trazido pelo SMP. Por estes motivos, muitos administradores de sistemas acreditam que o melhor caminho usar o poder de processamento de um uxo. Isto oferece o melhor poder de CPU com o menor nmero de restries sobre seu uso.
38
Apesar desta discusso parecer indicar que o SMP nunca uma boa idia, h ocasies nas quais faz sentido. Por exemplo: ambientes que rodam mltiplas aplicaes integradas ao computador so boas candidatas para o SMP. O motivo que as aplicaes, que no fazem nada alm de computar por perodos longos de tempo, mantm a conteno entre processos ativos (e, consequentemente, a sobrecarga do sistema operacional) a um mnimo, enquanto os processos mantm todas as CPUs ocupadas. Outra coisa sobre o SMP para ter em mente que o desempenho de um sistema SMP tende a degradar mais graciosamente conforme aumenta a carga do sistema. Isto torna os sistemas SMP conhecidos nos ambientes de servidor e multi-usurio, j que o mix de processos em constante alterao pode impactar menos a carga do sistema todo em uma mquina com multi-processador.

Monitorar a largura de banda e utilizao da CPU sob o Red Hat Enterprise Linux implica usar as ferramentas abordadas no Captulo 2; portanto, se voc ainda no leu este captulo, deve faz-lo antes de prosseguir.
3.3.1. Monitorando a Largura de Banda no Red Hat Enterprise Linux

Conforme apresentado na Seo 2.4.2, difcil monitorar diretamente a utilizao da banda (bandwidth). No entanto, ao examinar as estatsticas a nvel dos dispositivos, possvel detectar se a banda insuciente um problema em seu sistema. Usando o vmstat, possvel determinar se a atividade geral dos dispositivos excessiva, examinando os campos bi e bo. Anotar os campos si e so d mais algumas pistas sobre o quanto de atividade do disco est designada a atividades I/O relacionadas a swap:
r 1 procs b w 0 0 memory swpd free buff cache 0 248088 158636 480804 si 0 swap so 0 bi 2 io bo 6 in 120 system cs 120 us 10 sy 3 cpu id 87
Neste exemplo, o campo bi mostra dois blocos/segundo gravados nos dispositivos de bloco (principalmente drives de disco), enquanto o campo bo mostra seis blocos/segundo lidos pelos dispositivos de bloco. Podemos determinar que nenhuma destas atividades era relacionada ao swapping, j que ambos campos si e so mostram uma taxa de zero kilobytes/segundo de I/O relacionada a swap. Usando o iostat possvel ter mais algumas pistas sobre as atividades relacionadas ao disco:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) avg-cpu: %user 5.34 %nice 4.60 tps 1.10 0.00 %sys 2.83 %idle 87.24 Blk_wrtn/s 25.08 0.00 Blk_read 961342 16 Blk_wrtn 3881610 0 07/21/2003
Device: dev8-0 dev8-1
Blk_read/s 6.21 0.00
Este output nos mostra que o dispositivo com maior nmero 8 (/dev/sda, o primeiro disco SCSI) teve mdia um pouco acima de uma operao I/O por segundo (o campo tsp). A maior parte das atividades I/O deste dispositivo foram gravaes (o campo Blk_wrtn), com um pouco mais de 25 blocos gravados a cada segundo (o campo Blk_wrtn/s). Se voc precisar de mais detalhes, use a opo -x do iostat:
39
Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) avg-cpu: %user 5.37 %nice 4.54 %sys 2.81 r/s 0.36 0.00 0.00 0.29 0.04 %idle 87.27 w/s 0.77 0.00 0.00 0.62 0.15 rsec/s 32.20 0.34 0.00 4.74 1.06 wsec/s 29.05 0.00 0.00 21.80 7.24 rkB/s 16.10 0.17 0.00 2.37 0.53
07/21/2003
Device: /dev/sda /dev/sda1 /dev/sda2 /dev/sda3 /dev/sda4
rrqm/s wrqm/s 13.57 2.86 0.17 0.00 0.00 0.00 0.31 2.11 0.09 0.75
wkB/s avgrq-sz 14.53 54.52 0.00 133.40 0.00 11.56 10.90 29.42 3.62 43.01
Sobre e acima das linhas mais longas contendo mais campos, a primeira coisa para ter em mente que este output do iostat agora mostra as estatsticas por partio. Usando o df para associar os pontos de montagem aos nomes dos dispositivos, possvel usar este relatrio para determinar, por exemplo, se a partio contendo o /home/ est sobrecarregada de trabalho. Na verdade, cada linha do output do iostat -x mais longa e contm mais informaes que esta. Aqui est o resto de cada linha (com a adio da coluna dos dispositivos para facilitar a leitura):
Device: /dev/sda /dev/sda1 /dev/sda2 /dev/sda3 /dev/sda4 avgqu-sz 0.24 0.00 0.00 0.12 0.11 await svctm 20.86 3.80 141.18 122.73 6.00 6.00 12.84 2.68 57.47 8.94 %util 0.43 0.03 0.00 0.24 0.17
Neste exemplo interessante notar que /dev/sda2 a partio swap do sistema. bvio que o swapping no um problema neste sistema, devido os diversos campos apresentando 0.00 para esta partio. Um outro ponto interessante o /dev/sda1. As estatsticas desta partio so incomuns - a atividade geral parece baixa, mas por que o tamanho mdio do pedido I/O (o campo avgrq-sz), o tempo mdio de espera (o campo await) e o tempo mdio de servio (o campo svctm) so to maiores que os das outras parties? A resposta que a partio contm o diretrio /boot/, onde o kernel e o disco ram inicial esto armazenados. Quando o sistema inicializar, as I/Os de leitura (note que somente os campos rsec/s e rkB/s so diferentes de zero; nenhuma gravao feita aqui regularmente) usados durante o processo de inicializao so destinados a nmeros grandes de blocos, resultando na espera e tempos de servio relativamente longos apresentados pelo iostat. possvel usar o sar para uma viso geral mais longa das estatsticas I/O. Por exemplo: o sar -b apresenta um relatrio geral de I/O:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) 12:00:00 12:10:00 12:20:01 ... 06:00:02 Average: AM AM AM PM tps 0.51 0.48 1.24 1.11 rtps 0.01 0.00 0.00 0.31 wtps 0.50 0.48 1.24 0.80 bread/s 0.25 0.00 0.01 68.14 bwrtn/s 14.32 13.32 36.23 34.79 07/21/2003
Aqui, assim como na apresentao inicial do iostat, as estatsticas so agrupdas para todos os dispositivos de bloco. Um outro relatrio relacionado a I/O produzido usando o sar -d:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) 07/21/2003
40
12:00:00 12:10:00 12:10:00 12:20:01 12:20:01 ... 06:00:02 06:00:02 Average: Average:
AM AM AM AM AM PM PM
DEV dev8-0 dev8-1 dev8-0 dev8-1 dev8-0 dev8-1 dev8-0 dev8-1
tps 0.51 0.00 0.48 0.00 1.24 0.00 1.11 0.00
sect/s 14.57 0.00 13.32 0.00 36.25 0.00 102.93 0.00
Este relatrio oferece informaes por dispositivo, mas com poucos detalhes. Apesar de no haver estatsticas explcitas sobre a utilizao da banda para um determinado canal ou central de dados, ns podemos pelo menos determinar o que os dispositivos esto fazendo e usar suas atividades para determinar indiretamente a carga do canal.
3.3.2. Monitorando a Utilizao da CPU no Red Hat Enterprise Linux

Ao contrrio da banda, monitorar a utilizao da CPU bem mais simples. Desde uma porcentagem da utilizao da CPU no Sistema de Monitoramento GNOME s estatsticas mais aprofundadas reportadas pelo sar, possvel determinar com acuracidade o quanto de poder da CPU est sendo consumido e pelo que. Alm do Sistema de Monitoramento GNOME, o top a primeira ferramenta de monitoramento de recursos abordada no Captulo 2 para oferecer uma representao mais profunda da utilizao da CPU. Aqui est um relatrio do top sobre uma estao de trabalho com processador duplo:
9:44pm up 2 days, 2 min, 1 user, load average: 0.14, 0.12, 0.09 90 processes: 82 sleeping, 1 running, 7 zombie, 0 stopped CPU0 states: 0.4% user, 1.1% system, 0.0% nice, 97.4% idle CPU1 states: 0.5% user, 1.3% system, 0.0% nice, 97.1% idle Mem: 1288720K av, 1056260K used, 232460K free, 0K shrd, 145644K buff Swap: 522104K av, 0K used, 522104K free 469764K cached PID 30997 1120 1260 888 1264 1 2 3 4 5 6 7 8 9 10 USER ed root ed root ed root root root root root root root root root root PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 16 0 1100 1100 840 R 1.7 0.0 0:00 top 5 -10 249M 174M 71508 S < 0.9 13.8 254:59 X 15 0 54408 53M 6864 S 0.7 4.2 12:09 gnome-terminal 15 0 2428 2428 1796 S 0.1 0.1 0:06 sendmail 15 0 16336 15M 9480 S 0.1 1.2 1:58 rhn-applet-gui 15 0 476 476 424 S 0.0 0.0 0:05 init 0K 0 0 0 0 SW 0.0 0.0 0:00 migration_CPU0 0K 0 0 0 0 SW 0.0 0.0 0:00 migration_CPU1 15 0 0 0 0 SW 0.0 0.0 0:01 keventd 34 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU0 34 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU1 15 0 0 0 0 SW 0.0 0.0 0:05 kswapd 15 0 0 0 0 SW 0.0 0.0 0:00 bdflush 15 0 0 0 0 SW 0.0 0.0 0:01 kupdated 25 0 0 0 0 SW 0.0 0.0 0:00 mdrecoveryd
A primeira informao relativa a CPU est na primeira linha: a mdia de carga (load average). A mdia de carga corresponde ao nmero mdio de processos executveis no sistema. A mdia de carga frequentemente listada como um conjunto de trs nmeros (como o top faz), que representam a mdia da carga nos ltimos 1, 5 e 15 minutos, indicando que o sistema no estava muito ocupado neste exemplo.
41
A prxima linha, apesar de no ser restritamente relativa utilizao da CPU, tem uma relao indireta, pois mostra o nmero de processos executveis (aqui, somente um - lembre este nmero pois signica algo especial neste exemplo). O nmero de processos executveis um bom indicador do quo intregrado CPU o sistema deve ser. Em seguida, h duas linhas apresentando a utilizao corrente de cada uma das duas CPU no sistema. As estatsticas de utilizao esto detalhadas para mostrar se os ciclos da CPU foram gastos para processamento no nvel de usurio ou no nvel do sistema. Tambm h estatsticas que mostram quanto tempo de CPU foi gasto com processos com prioridades de agendamento alteradas. Finalmente, h uma estatstica de tempo ocioso. Um pouco mais abaixo, na seo relativa a processos, ns podemos observar que o processo usando a maior parte do poder da CPU o prprio top; ou seja, o nico processo executvel neste sistema era o top tirando uma "foto" de si mesmo.
Dica importante lembrar que o prprio ato de rodar o monitoramento do sistema afeta as estatsticas de utilizao dos recursos que voc recebe. Todos os monitores baseados em software fazem isso de alguma maneira.
Para obter um conhecimento mais detalhado sobre a utilizao da CPU, ns devemos mudar de ferramentas. Se examinarmos o output do vmstat, obteremos um entendimento ligeiramente diferente de nosso sistema exemplo:
r 1 0 0 0 0 0 0 0 0 0 procs b w 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 swpd 0 0 0 0 0 0 0 0 0 0 free 233276 233276 233276 233276 233276 233276 233276 233276 233276 233276 buff 146636 146636 146636 146636 146636 146636 146636 146636 146636 146636 memory cache 469808 469808 469808 469808 469808 469808 469808 469808 469808 469808 si 0 0 0 0 0 0 0 0 0 0 swap so 0 0 0 0 0 0 0 0 0 0 bi 7 0 0 0 0 0 0 0 0 0 io bo 7 0 0 0 0 32 0 0 0 0 in 14 523 557 544 517 518 516 516 516 516 system cs 27 138 385 343 89 102 91 72 88 81 us 10 3 2 2 2 2 2 2 2 2 sy 3 0 1 0 0 0 1 0 0 0 cpu id 87 96 97 97 98 98 98 98 97 97
Usamos aqui o comando vmstat 1 10 para examinar o sistema a todo segundo por dez vezes. Primeiramente, as estatsticas relativas CPU (os campos us, sy e id) parecem similares ao output do top, e pode at parecer um pouco menos detalhado. No entanto, ao contrrio do top, ns tambm podemos obter alguma pista sobre como a CPU est sendo utilizada. Se examinarmos os campos do system, percebemos que a CPU est tendo em mdia aproximadamente 500 interrupes por segundo e est alternando entre processos entre 80 e 400 vezes por segundo. Se voc acha que isto parece muito ativo, pense novamente, pois o processamento a nvel do usurio (o campo us) est apenas na mdia de 2%, enquanto o processamento a nvel do sistema (o campo sy) geralmente est abaixo de 1%. Mais uma vez, este um sistema ocioso. Ao rever as ferramentas que o Sysstat oferece, percebemos que o iostat e o mpstat oferecem poucas informaes adicionais em relao ao que vimos anteriormente com top e vmstat. Entretanto, o sar produz uma variedade de relatrios muito teis ao monitorar a utilizao da CPU. O primeiro relatrio obtido atravs do comando sar -q, que apresenta o comprimento da la de execuo, o nmero total de processos e as mdias de carga nos ltimos um e cinco minutos. Eis uma exemplo:
42
Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 12:00:01 12:10:00 12:20:01 ... 09:50:00 Average: AM AM AM AM runq-sz 3 5 5 4 plist-sz 122 123 124 123 ldavg-1 0.07 0.00 0.67 0.26 ldavg-5 0.28 0.03 0.65 0.26
07/21/2003
Neste exemplo, o sistema est sempre ocupado (dado que mais de um processo executvel ao mesmo tempo), mas no est sobrecarregado (devido o fato que este sistema em particular tem mais de um processador). O prximo relatrio do sar relativo CPU produzido pelo comando sar -u:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 12:00:01 12:10:00 12:20:01 ... 10:00:00 Average: AM AM AM AM CPU all all all all %user 3.69 1.73 35.17 7.47 %nice 20.10 0.22 0.83 4.85 %system 1.06 0.80 1.06 3.87 %idle 75.15 97.25 62.93 83.81 07/21/2003
As estatsticas contidas neste relatrio no so diferentes daquelas produzidas por muitas das outras ferramentas. O maior benefcio deste que o sar disponibiliza os dados intermitentemente e, portanto, mais til para obter mdias a longo prazo ou para a produo de grcos de utilizao da CPU. Em sistemas com multi-processadores, o comando sar -U pode produzir estatsticas para um determinado processador ou para todos os processadores. Aqui est um exemplo do output do sar -U ALL:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 12:00:01 12:10:00 12:10:00 12:20:01 12:20:01 ... 10:00:00 10:00:00 Average: Average: AM AM AM AM AM AM AM CPU 0 1 0 1 0 1 0 1 %user 3.46 3.91 1.63 1.82 39.12 31.22 7.61 7.33 %nice 21.47 18.73 0.25 0.20 0.75 0.92 4.91 4.78 %system 1.09 1.03 0.78 0.81 1.04 1.09 3.86 3.88 %idle 73.98 76.33 97.34 97.17 59.09 66.77 83.61 84.02 07/21/2003
O comando sar -w reporta o nmero de alternaes de contexto por segundo, possibilitando obter pistas adicionais sobre onde os ciclos da CPU esto sendo gastos:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 12:00:01 12:10:00 12:20:01 ... 10:10:00 Average: AM AM AM AM cswch/s 537.97 339.43 319.42 1158.25 07/21/2003
43
Tambm possvel produzir dois relatrios diferentes do sar sobre a atividade da interrupo. O primeiro (produzido usando o comando sar -I SUM) apresenta apenas uma estatstica de "interrupes por segundo":
Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 12:00:01 12:10:00 12:20:01 ... 10:40:01 Average: AM AM AM AM INTR sum sum sum sum intr/s 539.15 539.49 539.10 541.00 07/21/2003
Usando o comando sar -I PROC, possvel detalhar a atividade por processo (em sistemas com multi-processadores) e por nvel de interrupo (de 0 a 15):
Linux 2.4.21-1.1931.2.349.2.2.entsmp (pigdog.example.com) 12:00:00 AM 12:10:01 AM 12:10:01 12:20:01 ... 10:30:01 10:40:02 Average: AM AM AM AM CPU 0 CPU 0 CPU 0 0 i000/s 512.01 i000/s 512.00 i000/s 512.00 512.00 i001/s 0.00 i001/s 0.00 i001/s 1.67 0.42 i002/s 0.00 i002/s 0.00 i002/s 0.00 0.00 i008/s 0.00 i008/s 0.00 i003/s 0.00 N/A i009/s 3.44 i009/s 3.73 i008/s 0.00 0.00 07/21/2003 i011/s 0.00 i011/s 0.00 i009/s 15.08 6.03 i012/s 0.00 i012/s 0.00 i010/s 0.00 N/A
Este relatrio (que foi truncado horizontalmente para caber na pgina) inclui uma coluna para cada nvel de interrupo (ex.: o campo i002/s ilustrando a taxa do nvel 2 de interrupo). Se este fosse um sistema com multi-processador, haveria uma linha por perodo de amostra para cada CPU. Um outro ponto importante a notar sobre este relatrio que o sar adiciona ou remove campos de interrupo especcos se no houver dados coletados parta este campo. O relatrio exibido acima oferece um exemplo disto - o m do relatrio inclui os nveis de interrupo (3 e 10) que no estavam presentes no incio do perodo de amostragem.
Nota H outros dois relatrios do sar relativos interrupes sar -I ALL e sar -I XALL. No entanto, a congurao default do utilitrio de levantamento de dados sadc no coleta as informaes necessrias para estes relatrios. Isto pode ser alterado ao editar o arquivo /etc/cron.d/sysstat e alterar esta linha:
*/10 * * * * root /usr/lib/sa/sa1 1 1
para esta:
*/10 * * * * root /usr/lib/sa/sa1 -I 1 1
Tenha em mente que esta alterao faz com que o sadc levante informaes adicionais, resultando em tamanhos maiores de arquivos de dados. Portanto, assegure que a congurao de seu sistema possa suportar o consumo de espao adicional.
44

Esta seo inclui diversos recursos especicamente relacionados ao Red Hat Enterprise Linux que podem ser usados para aprender mais sobre o assunto discutido neste captulo.

O recursos seguintes so instalados no decorrer de uma instalao tpica do Red Hat Enterprise Linux e podem ajud-lo a aprender mais sobre o assunto abordado neste captulo.

Pgina man vmstat(8) Aprenda a exibir uma viso geral concisa do processo, memria, swap, I/O, sistema e utilizao da CPU. Pgina man iostat(1) Aprenda a exibir as estatsticas da CPU e I/O. Pgina man sar(1) Aprenda a produzir relatrios da utilizao de recursos do sistema. Pgina man sadc(8) Aprenda a coletar dados da utilizao do sistema. Pgina man sa1(8) Aprenda sobre um script que roda o sadc periodicamente. Pgina man top(1) Aprenda a exibir a utilizao e estatsticas no nvel de processo da CPU.
3.4.2. Sites teis
http://people.redhat.com/alikins/system_tuning.html Informaes de Ajuste para Servidores Linux (System Tuning Info for Linux Servers). Uma ttica para ajustar o desempenho e monitoramento de recursos para servidores. http://www.linuxjournal.com/article.php?sid=2396 Ferramentas de Monitoramento de Desempenho para Linux (Performance Monitoring Tools for Linux). Esta pgina mais direcionada ao administrador interessado em elaborar uma soluo grca customizada de desempenho. Como foi elaborado h muitos anos atrs, alguns dos detalhes talvez no possam mais ser aplicados, mas o conceito e execuo geral ainda funcionam.

Os livros seguintes abordam vrias questes relacionadas ao monitoramento de recursos e so boas fontes para administradores de sistemas Red Hat Enterprise Linux.

O Guia de Administrao de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. Inclui um captulo sobre muitas das ferramentas de monitoramento dos recursos abordadas aqui. Linux Performance Tuning and Capacity Planning de Jason R. Fink e Matthew D. Sherer; Sams Oferece uma viso mais profunda das ferramentas de monitoramento de recursos apresentadas aqui e inclui outras que podem ser apropriadas para necessidades mais especcas de monitoramento dos recursos. Linux Administration Handbook de Evi Nemeth, Garth Snyder, e Trent R. Hein; Prentice Hall Oferece um captulo curto com escopo similar ao deste manual, que inclui uma seo interessante sobre como diagnosticar um sistema que cou mais lento repentinamente. Linux System Administration: A Users Guide de Marcel Gagne; Addison Wesley Professional Contm um pequeno captulo sobre o monitoramento e ajuste de desempenho.
Captulo 4.
Memria Fsica e Virtual
Hoje em dia, todos os computadores de uso geral so do tipo conhecido como computadores de programas armazenados. Como o nome implica, os computadores de programas armazenados carregam as instrues (os blocos construtores dos programas) em algum tipo de armazenamento interno, onde subsequentemente executam estas intrues. Os computadores de programas armazenados tambm usam o mesmo armazenamento para dados. Isto contrasta com os computadores que usam a congurao de seu hardware para controlar sua operao (tais como computadores antigos baseados no plugboard). O local onde os progrmas eram armazenados nos primeiros computadores de programas armazenados tinha nomes variados e usava diversas tecnologias diferentes, desde pontos num tubo de raio ctodo presso em colunas de mercrio. Felizmente, os computadores de hoje usam tecnologias com maior capacidade de armazenamento e tamanhos como nunca vistos antes.
4.1. Padres de Acesso ao Armazenamento

Algo para ter em mente ao longo deste captulo que os computadores tendem a acessar o armazenamento de determinadas maneiras. De fato, a maioria do acesso ao armazenamento tende a exibir um (ou ambos) dos seguintes atributos:

O acesso tende ser sequencial O acesso tende ser localizado
Acesso sequencial signica que, se o endereo N acessado pela CPU, bem provvel que o endereo N +1 seja acessado em seguida. Isto faz sentido, j que a maioria dos programas consiste de grandes sees de instrues que so executadas em ordem uma aps a outra. Acesso localizado signica que, se o endereo X acessado, provvel que outros endereos prximos ao X tambm sejam acessados no futuro. Estes atributos so cruciais porque permitem que um armazenamento menor e mais rpido carregue um armazenamento maior e mais lento. Esta a base para a implementao da memria virtual. Mas, antes de abordarmos a memria virtual, precisamos examinar as diversas tecnologias de armazenamento em uso no momento.
4.2. O Espectro do Armazenamento

Os computadores atuais usam diversas tecnologias de armazenamento. Cada tecnologia direcionada a uma funo especca, com velocidades e capacidades correspondentes. Estas tecnologias so:

Registradores de CPU Memria cache RAM Discos rgidos Armazenamento de backup off-line (ta, disco tico, etc)
46
Captulo 4. Memria Fsica e Virtual
Em termos de capacidades e custos, estas tecnologias compoem um espectro. Por exemplo: os registradores da CPU so:

Muito rpido (tempos de acesso de alguns nanossegundos) Baixa capacidade (geralmente menor que 200 bytes) Capacidade de expanso muito limitada (seria necessria uma mudana na arquitetura da CPU) Caro (mais de um dlar US por byte)
No entanto, na outra extremidade do espectro, o armazenamento de backup off-line :

Muito lento (os tempos de acesso podem ser medidos em dias, caso a mdia de backup tenha que ser enviada atravs de distncias longas) Capacidade muito alta (10s - 100s de gigabytes) Capacidades de expanso essencialmente ilimitadas (limitadas apenas pelo espao no cho necessrio para comportar a mdia de backup) Muito barato (fraes de centavos por byte)
Ao utilizar tecnologias diferentes com capacidades diferentes, possvel ajustar o design do sistema para um desepenho mximo com o menor custo possvel. As sees seguintes exploram cada tecnologia dentro do espectro de armazenamento.
4.2.1. Registradores de CPU

Cada CPU atual inclui registradores para uma gama de propsitos, desde armazenar endereos da instruo sendo executada ao armazenamento e manipulao de dados para propsitos genricos. Os registradores da CPU rodam na mesma velocidade que o resto da CPU; caso contrrio, seriam um srio gargalo para o desempenho geral do sistema. A razo disso que praticamente todas as operaes desempenhadas pela CPU envolvem os registradores de alguma forma. O nmero de registradores da CPU (e seus usos) estritamente dependente do design arquitetnico da CPU. No h maneira de alterar o nmero de registradores da CPU, alm de migrar para uma CPU com arquitetura diferente. Por estes motivos, o nmero de registradores da CPU pode ser considerado uma constante, j que so alterveis somente com muito esforo e custo.
4.2.2. Memria Cache

O propsito da memria cache atuar como um buffer entre os registradores da CPU, muito limitados e de alta velocidade, e a memria principal do sistema, relativamente mais lenta e maior geralmente referida como RAM1. A memria cache tem uma velocidade operacional similar da prpria CPU, portanto, quando a CPU acessa os dados no cache, no ca esperando os dados. A memria cache congurada de maneira que, sempre que os dados forem acessados pela RAM, o hardware do sistema primeiro verica se os dados desejados esto no cache. Se os dados estiverem no cache, so rapidamente recuperados e usados pela CPU. Mas, se os dados no esto no cache, so acessados pela RAM e, enquanto so transferidos para a CPU, tambm so alocadas no cache (caso sejam novamente necessrios mais tarde). Da perspectiva da CPU, tudo isso feito transparentemente, de modo que a nica diferena entre acessar os dados no cache e na RAM o tempo de resposta. Em termos de capacidade de armazenamento, o cache bem menor que a RAM. Consequentemente, nem todo byte da RAM pode ter sua localidade nica no cache. Sendo assim, necessrio dividir o
1. Apesar de "RAM" ser o acrnimo de "Random Access Memory," e um termo que poderia ser facilmente
aplicado a qualquer tecnologia de armazenamento, permitindo o acesso no-sequencial de dados armazenados, quando os administradores de sistemas falam sobre RAM, referem-se memria principal do sistema.
47
cache em sees que podem ser usadas para armazenar reas diferentes da memria RAM e tambm ter um mecanismo que permite a cada rea do cache armazenar reas diferentes de RAM em horas diferentes. Mesmo com a diferena de tamanho entre cache e RAM, dada a natureza sequencial e localizada do acesso ao armazenamento, uma pequena quantidade de cache pode, efetivamente, acelerar o acesso a uma grande quantidade de memria RAM. Ao gravar dados pela CPU, as coisas podem complicar um pouco. H duas tticas diferentes que podem ser usadas. Em ambos os casos os dados so gravados primeiro no cache. No entanto, como o propsito do cache funcionar como uma cpia muito rpida do contedo de pores selecionadas da RAM, sempre que algum dado alterado, deve ser gravado em ambos, na memria cache e na memria RAM. Caso contrrio, os dados do cache e os dados da RAM no coincidiriam. As duas tticas diferem no processo de como isso feito. Uma ttica, conhecida como cache de gravao direta, grava os dados modicados imediatamente na RAM. O cache de gravao reversa, no entanto, atrasa a gravao dos dados modicados de volta RAM. A razo disto reduzir o nmero de vezes que um dado frequentemente modicado deve ser gravado de volta RAM. O cache de gravao direta um pouco mais simples para implementar e, por este motivo, mais comum. O cache de gravao reversa um pouco mais difcil de implementar; alm de armazenar os dados reais, necessrio manter alguma espcie de mecanismo capaz de avisar se os dados do cache esto limpos (quando os dados do cache so os mesmos que os dados da RAM) ou sujos (quando os dados do cache foram modicados, o que signica que os dados da RAM no esto mais atualizados). Tambm necessrio implementar uma maneira de enviar periodicamente entradas sujas do cache de volta RAM. 4.2.2.1. Nveis do Cache Os sub-sistemas do cache nos designs dos compudatores de hoje podem ser multi-nveis; ou seja, pode existir mais de um conjunto de cache entre a CPU e a memria principal. Os nveis do cache frequentemente so numerados, com os nmeros menores mais prximos CPU. Muitos sistemas tm dois nveis de cache:

O cache L1 (level 1) frequentemente localizado diretamente no chip da CPU e roda na mesma velocidade que a CPU. O cache L2 (level 2) frequentemente parte do mdulo da CPU, roda nas mesmas velocidades (ou prximas) da CPU, e geralmente um pouco maior e mais lento que o cache L1.
Alguns sistemas (normalmente, os servidores de alto desempenho) tambm tem o cache L3, que geralmente parte da placa-me do sistema. Conforme esperado, o cache L3 seria maior (e provavelmente mais lento) que o cache L2. Em qualquer um dos casos, o objetivo de todos os sub-sistemas de cache seja de nvel simples ou multi-nvel reduzir o tempo mdio de acesso memria RAM.
4.2.3. Memria Principal RAM

A RAM representa o armazenamento eletrnico em massa nos computadores de hoje. usada como armazenamento para dados e programas, enquanto estes esto em uso. A velocidade da RAM na maioria dos sistemas de hoje ca entre a velocidade da memria cache e a dos discos rgidos; bem mais prxima da memria cache. A operao bsica da RAM , na verdade, bem simples. No nvel mais baixo h chips da RAM circuitos integrados que executam a "memorizao" de verdade. Estes chips tm quatro tipos de conexes com o mundo externo:
Conexes de eletricidade (para operar os circuitos dentro do chip)
48
Captulo 4. Memria Fsica e Virtual Conexes de dados (para permitir a transferncia de dados para dentro ou para fora do chip) Conexes de leitura/gravao (para controlar se os dados devem ser armazenados no ou recuperados pelo chip) Conexes de endereo (para determinar onde os dados devem ser lidos/gravados dentro do chip)
Aqui esto os passos para armazenar dados na RAM: 1. Os dados a serem armazenados so apresentados s conexes de dados. 2. O endereo no qual os dados devem ser armazenados apresentado s conexes de endereo. 3. A conexo leitura/gravao est ajustada no modo gravao (write). Recuperar dados tambm simples: 1. O endereo dos dados desejados apresentado s conexes de endereo. 2. A conexo leitura/gravao ajustada no modo leitura (read). 3. Os dados desejados so lidos (acessados) pelas conexes de dados. Apesar destes passos parecerem simples, acontecem a velocidades muito altas, e o tempo gasto com cada passo medido em nanossegundos. Praticamente todos os chips de RAM criados hoje so vendidos como mdulos. Cada mdulo consiste de diversos chips de RAM ligados a uma pequena placa de circuito. A disposio mecnica e eltrica do mdulo adere aos diversos padres do setor, possibilitando adquirir memria de fabricantes variados.
Nota O principal benefcio de um sistema usando mdulos RAM padronizados que custo da RAM tende a manter-se baixo, devido possibilidade de adquirir mdulos de mais de um fabricante de sistemas. Apesar da maioria dos computadores usar mdulos RAM padronizados, h excees. A mais notvel o laptop (e mesmo aqui j vem ocorrendo alguma padronizao) e servidores high-end. No entanto, mesmo nestes casos, provvel que exista mdulos de terceiros, assumindo que o sistema seja relativamente conhecido e que no seja um design completamente inovador.
4.2.4. Discos Rgidos

Todas as tecnologias abordadas at ento so de natureza voltil. Em outras palavras, os dados contidos no armazenamento voltil so perdidos quando a energia desligada. Por outro lado, os discos rgidos so no-volteis os dados que eles contm continuam l, mesmo aps a energia ser desligada. Por este motivo, os discos rgidos ocupam uma posio especial no espectro de armazenamento. Sua natureza no-voltil torna-os ideais para armazenar programas e dados para uso a longo prazo. Um outro aspecto nico aos discos rgidos que, ao contrrio da memria RAM e do cache, no possvel executar programas diretamente quando esto armazenados em discos rgidos. Ao invs disso, eles precisam ser acessados primeiro pela memria RAM. Tambm diferentemente das memrias RAM e cache, a velocidade de armazenamnto e recuperao dos discos rgidos - pelo menos uma ordem de magnitude mais lentos que as tecnologias totalmente eletrnicas usadas para cache e RAM. A diferena de velocidades existe devido, principalmente, sua natureza eletromecnica. H quatro fases diferentes durante cada transferncia para ou de um disco rgido. A lista seguinte ilustra estas fases, juntamente ao tempo que levaria a um drive tpico de alto desempenho, em mdia, para completar cada fase:
Captulo 4. Memria Fsica e Virtual Movimento de acesso com o brao (5,5 milissegundos) Rotao do disco (0,1 milissegundos) Heads acessando/gravando dados (0,00014 milissegundos) Transferncia de dados de/para os eletrnicos do drive (0,003 milissegundos)
49
Dentre estas, somente a ltima fase no dependente de nenhuma operao mecnica.
Nota Apesar de haver muito mais a aprender sobre discos rgidos, as tecnologias de armazenamento em disco so abordadas com maior profundidade no Captulo 5. Por enquanto, necessrio somente ter em mente a diferena enorme de velocidades entre as tecnologias baseadas em disco e baseadas na memria RAM, e que sua capacidade de armazenamento geralmente excede a da RAM em pelo menos 10 vezes, e frequentemente 100 vezes ou mais.
4.2.5. Armazenamento de Backup Off-Line

O armazenamento de backup off-line vai um passo alm do armazenamento no disco rgido em termos de capacidadade (maior) e velocidade (mais lenta). Aqui as capacidades so efetivamente limitadas somente pela sua capacidade em obter e armazenar a mdia removvel. As tecnologias usadas nestes dispositivos variam amplamente. Aqui esto os tipos mais conhecidos:

Fita magntica Disco tico
Obviamente, ter mdia removvel signica que os tempos de acesso tornam-se ainda mais longos, particularmente quando os dados desejados esto numa mdia ainda no carregada pelo dispositivo de armazenamento. Esta situao amenizada pelo uso de dispositivos robticos capazes de carregar e descarregar mdia automaticamente, mas as capacidades do armazenamento de mdia destes dispositivos ainda nita. Mesmo no melhor dos casos, os tempos de acesso so medidos em segundos, o que bem mais longo que os tempos de acesso relativamente lentos de multi milissegundos de um disco rgido de alto desempenho. Agora, aps analisar rapidamente as diversas tecnologias de armazenamento usadas atualmente, vamos explorar os conceitos da memria virtual bsica.
4.3. Conceitos da Memria Virtual Bsica

Apesar da tecnologia por trs da construo de vrias tecnologias de armazenamento atuais ser muito impressionante, o administrador de sistemas mediano no precisa saber dos detalhes. De fato, h somente uma questo que os administradores de sistemas precisam ter em mente: Nunca h memria RAM suciente. Apesar desta evidncia parecer humorstica, muitos desenvolvedores de sistemas operacionais levaram bastante tempo tentando reduzir o impacto desta decincia real. Eles implementaram a memria virtual uma maneira de combinar RAM com armazenamento mais lento para dar a um sistema a impresso de ter mais memria RAM do que realmente h instalada.
50
4.3.1. Memria Virtual em Termos Simples

Vamos comear com uma aplicao hipottica. O cdigo da mquina criando esta aplicao tem tamanho de 10000 bytes. Tambm requer outros 5000 bytes para armazenamento de dados e buffers de I/O. Isto signica que, para rodar esta aplicao, deve haver 15000 bytes de RAM disponveis. Se houver um byte a menos, a aplicao no ser executada. Este requisito de 15000 bytes conhecido como o espao de endereo da aplicao. o nmero de endereos nicos necessrios para armazenar ambos, a aplicao e seus dados. Nos primeiros computadores, a quantidade de RAM disponvel tinha que ser maior que o espao de endereo da maior aplicao a rodar; caso contrrio, a aplicao falharia com um erro de "falta de memria". Uma ltima ttica, conhecida como sobreposio (overlaying), tentou amenizar o problema permitindo que programadores ditassem quais partes de sua aplicao precisavam estar residindo na memria em uma determinada hora. Desta maneira, o cdigo necessrio uma vez para propsitos de inicializao pde ser sobreposto (overlayed) com cdigo que seria utilizado mais tarde. Apesar da sobreposio ter facilitado a reduo de memria, era um processo muito complexo e suscetvel a erros. As sobrepopsies tambm falharam em resolver a questo da reduo de memria de todo o sistema no tempo de execuo (runtime). Em outras palavras, um programa sobreposto pode precisar de menos memria para rodar que um programa no sobreposto, mas se o sistema ainda no tiver memria suciente para o programa sobreposto, o resultado nal o mesmo um erro de falta de memria. A memria virtual altera o conceito do espao de endereo de uma aplicao. Ao invs de concentrar no quanto de memria uma aplicao precisa para rodar, um sistema operacional com memria virtual tenta continuamente responder pergunta: "quo pequena a memria precisa para rodar uma aplicao?" Apesar de, primeira vista, parecer que nossa aplicao hipottica precisa de 15000 bytes para rodar, pense em nossa abordagem na Seo 4.1 o acesso memria tende ser sequencial e localizado. Por este motivo, a quantidade de memria precisa para executar a aplicao numa determinada hora menor que 15000 bytes geralmente muito menor. Considere os tipos de acessos memria necessrios para executar uma nica instruo da mquina:

As instrues so lidas da memria. Os dados necessrios pelas instrues so acessados da memria. Aps completar as instrues, os resultados das instrues so gravados de volta na memria.
O nmero real de bytes necessrios para cada acesso memria varia de acordo com a arquitetura da CPU, com as instrues em si e com o tipo de dados. No entanto, mesmo se uma instruo precisasse de 100 bytes de memria para cada tipo de acesso memria, os 300 bytes necessrios seriam bem menos que todo o espao de endereo de 15000 bytes da aplicao. Se pudermos encontrar uma maneira de manter o registro das necessidades de memria de uma aplicao enquanto roda, poderamos manter a aplicao rodando enquanto usaramos menos memria que aquela ditada pelo seu espao de endereo. Mas isso nos traz uma pergunta: Se somente uma parte da aplicao est na memria em uma determinada hora, onde est o resto dela?
4.3.2. Backing Store a Doutrina Central da Memria Virtual

A resposta rpida para esta pergunta que o resto da aplicao continua no disco. Em outras palavras, o disco atua como o backing store da RAM; um meio de armazenamento maior e mais lento atuando como um "backup" de um meio de armazenamento menor e mais rpido. primeira vista, isto pode parecer um grande problema de desempenho acima de tudo, os drives de disco so bem mais lentos que a RAM.
51
Apesar disso ser verdade, possvel tirar proveito do comportamento de acesso sequencial e localizado das aplicaes e eliminar a maioria das implicaes do uso de drives de disco como backing store da memria RAM. Isto feito ao estruturar o sub-sistema da memria virtual, para que tente garantir que aquelas partes da aplicao necessrias no momento ou que, provavelmente, sero necessrias no futuro prximo sejam mantidas na RAM somente enquanto forem realmente necessrias. De muitas maneiras, isso parecido com a relao entre a memria cache e a memria RAM: fazer com que uma pequena quantidade de armazenamento rpido junto uma grande quantidade de armazenamento lento atuem como uma grande quantidade de armazenamento rpido. Com isso em mente, vamos explorar o processo mais detalhadamente.
4.4. Memria Virtual: Os Detalhes

Primeiro, devemos introduzir um novo conceito: espao de endereo virtual. O espao de endereo virtual (virtual address space) a quantidade mxima de espao de endereo disponvel para uma aplicao. O espao de endereo virtual varia de acordo com a arquitetura e sistema operacional da mquina. O espao de endereo virtual depende da arquitetura porque esta que dene quantos bits esto disponveis para propsitos de endereamento. O espao de endereo virtual tambm depende do sistema operacional porque a maneira atravs da qual este foi implementado pode introduzir limites adicionais alm ou aqum daqueles impostos pela arquitetura. A palavra "virtual" do espao de endereo virtual signica que este o nmero total das localidades da memria disponveis para uma aplicao que podem ser exclusivamente endereadas, e no a quantidade de memria fsica instalada no sistema, nem dedicada aplicao num determinado momento. No caso de nossa aplicao exemplo, seu espao de endereo virtual 15000 bytes. Para implementar a memria virtual necessrio que o sistema do computador tenha hardware para a administrao de memria especial. Este hardware geralmente conhecido como uma MMU (Memory Management Unit ou Unidade de Administrao de Memria). Sem uma MMU, quando a CPU acessa a memria RAM, as localidades reais da RAM nunca mudam o endereo de memria 123 sempre a mesma localidade fsica dentro da RAM. No entanto, com uma MMU, os endereos de memria passam por uma fase de traduo antes de cada acesso memria. Isso signica que o endereo de memria 123 pode ser direcionado ao endereo fsico 82043 uma vez e ao endereo fsico 20468 na prxima vez. No desenrolar do processo, a sobrecarga de registrar individualmente as tradues dos bilhes de bytes de memria de virtual para fsico seria muito grande. Ao invs disso, a MMU divide a RAM em pginas sees contguas de memria de tamanho determinado, que so encaradas pela MMU como entidades separadas. Manter o registro destas pginas e de suas tradues de endereos pode soar como um passo adicional desnecessrio e confuso. No entanto crucial para implementar a memria virtual. Por este motivo, considere o seguinte ponto: Se pegarmos nossa aplicao hipottica com 15000 bytes de espao de endereo virtual, assuma que os primeiros dados de acesso instruo da aplicao esto armazenados no endereo 12374. Entretanto, assuma tambm que nosso computador tenha somente 12288 bytes de memria RAM fsica. O que acontece quando a CPU tenta acessar o endereo 12374? O que acontece conhecido como uma falha de pgina (page fault).
4.4.1. Falhas de Pgina

Uma falha de pgina a sequncia de eventos que ocorre quando um programa tenta acessar os dados (ou cdigo) que est em seu espao de endereo, mas no est localizada na RAM do sistema no momento. O sistema operacional deve resolver as falhas de pgina tornando a memria dos dados acessados residente de alguma maneira, permitindo ao programa continuar a operao como se a falha de pgina nunca tivesse ocorrido.
52
No caso de nossa aplicao hipottica, a CPU apresenta primeiro o endereo desejado (12374) MMU. No entanto, a MMU no possui traduo para este endereo. Sendo assim, interrompe a CPU e faz com que o software, conhecido como fault handler, seja executado. O fault handler ento determina o que deve ser feito para resolver esta falha de pgina. possvel:

Encontrar onde a pgina desejada reside no disco e acess-la (normalmente, este o caso se a falha for de uma pgina de cdigo) Determinar que a pgina desejada j esteja na RAM (mas no localizada para o processo corrente) e recongurar a MMU para apontar para esta Apontar para uma pgina especial contendo somente zeros e alocar uma nova pgina para o processo, somente se o processo tentar gravar na pgina especial (isso chamado de uma pgina cpia na gravao - ou copy on write - e frequentemente usada para pginas contendo dados iniciados com zero) Obter a pgina desejada de algum outro lugar (abordado em mais detalhes posterirmente)
Apesar das trs primeiras aes serem relativamente simples, a ltima no . Para esta precisamos cobrir alguns tpicos adicionais.
4.4.2. O Conjunto de Trabalho

O grupo de pginas de memria fsica correntemente dedicado a um processo especco conhecido como grupo de trabalho (ou working set) para este processo. O nmero de pginas do grupo de trabalho pode aumentar e diminuir, dependendo da disponibilidade geral das pginas do sistema todo. O grupo de trabalho aumenta com as falhas de pgina de um processo. O grupo de trabalho diminui conforme a quantidade de pginas livres diminui. Para impedir que a memria acabe completamente, as pginas devem ser removidas dos conjuntos de trabalho do processo e transformadas em pginas livres, disponveis para uso posterior. O sistema operacional diminui os conjuntos de trabalho dos processos ao:

Gravar pginas modicadas numa rea dedicada de um dispositivo de armazenamento em massa (geralmente conhecido como espao de swapping ou paging) Marcar pginas no modicadas como livres (no h necessidade de gravar estas pginas em disco j que no foram alteradas)
Para determinar os conjuntos de trabalho apropriados para todos os processos, o sistema operacional precisa registrar as informaes de uso de todas as pginas. Desta maneira, o sistema operacional determina quais pginas esto sendo ativamente usadas (e devem permanecer residentes na memria). Na maioria dos casos, algum tipo de algoritmo recm-usado determina quais pginas so removveis dos conjuntos de trabalho do processo.
4.4.3. Swapping
Apesar do swapping (gravar pginas modicadas no espao swap do sistema) ser uma parte normal da operao de um sistema, possvel que haja swapping em demasia. A razo para car atento para o swapping excessivo que a situao a seguir pode ocorrer facilmente, diversas vezes:

As pginas de um processo so gravadas no espao swap O processo torna-se inexecutvel e tenta acessar uma pgina no espao swap A pgina retornada memria (provavelmente forando pginas de outros processos a serem gravadas no espao swap) Pouco tempo depois, a pgina novamente gravada no espao swap
53
Se esta sequncia de eventos for espalhada, conhecida como thrashing e um sinal de memria RAM insuciente para a atual carga de trabalho. O thrashing extremamente prejudicial ao desempenho do sistema, j que a carga da CPU e I/O que pode ser gerada numa situao como esta rapidamente compensa a carga imposta pelo trabalho real de um sistema. Em casos extremos, o sistema talvez no execute nenhum trabalho til, gastando todos os seus recursos movendo pginas da e para a memria.
4.5. Implicaes ao Desempenho da Memria Virtual

Apesar da memria virtual possibilitar que os computadores rodem aplicaes maiores e mais complexas com mais facilidade, assim como com qualquer outra ferramenta poderosa, ela tem um preo. Neste caso, o preo reetido no desempenho um sistema operacional com memria virtual tem muito mais a fazer do que um sistema operacional incapaz de suportar a memria virtual. Isto signica que o desempenho de uma aplicao com memria virtual nunca to bom quanto o desempenho da mesma aplicao com 100% residente na memria. No entanto, isto no motivo para desistncia. Os benefcios da memria virtual so muito bons para fazer isso. Com um pouco de esforo, possvel obter um bom desempenho. O que deve ser feito analisar os recursos do sistema impactados pelo alto uso do sub-sistema da memria virtual.
4.5.1. Cenrio do Desempenho no Pior Caso

Por um momento, lembre-se do que voc leu neste captulo e considere quais recursos do sistema so usados por atividades extremamente pesadas de swapping e de falha de pgina:

RAM a razo pela qual a RAM disponvel est baixa (caso contrrio, no haveria necessidade de falha de pgina ou swap). Disco O espao em disco talvez no seja impactado, mas a largura de banda I/O seria (devido ao alto ndice de paging e swapping). CPU A CPU est gastando ciclos no processamento necessrio para suportar a administrao da memria e a congurao das operaes I/O para o paging e swapping.
A natureza interrelacionada destas cargas facilita o entendimento de como a falta de recursos pode acarretar em problemas severos de desempenho. Tudo o que precisamos um sistema com pouca memria RAM, alto ndice de falhas de pgina e um sistema rodando prximo de seus limites em termos de I/O do disco ou CPU. Neste ponto, o sistema est com thrashing, com baixo desempenho como resultado inevitvel.
4.5.2. Cenrio do Desempenho no Melhor Caso

No melhor dos casos, a sobrecarga do suporte memria virtual apresenta uma carga extra mnima em um sistema bem congurado:

RAM RAM suciente para todos os conjuntos de trabalho com um restinho de memria capaz de resolver quaisquer falhas de pgina2 Disco Devido a atividade limitada da falha de pgina, a largura de banda I/O seria minimamente impactada
Um sistema razoavelmente ativo sempre tem um certo nvel de atividades relacionadas a falhas de pgina,
2.
devido s falhas de pgina ocorridas com a incurso de aplicaes recm-lanadas na memria.
54
Captulo 4. Memria Fsica e Virtual CPU A maioria dos cliclos de CPU so, na verdade, dedicados a rodar aplicaes, ao invs de rodar o cdigo de administrao de memria do sistema operacional
Sendo assim, temos que ter em mente que o impacto de desempenho da memria virtual mnimo quando usada o menos possvel. Isto siginica que o fator determinante para um bom desempenho do sub-sistema de memria virtual ter memria RAM suciente. A seguir (mas bem abaixo em termos de importncia relativa) est a capacidade da CPU e I/O do disco. No entanto, tenha em mente que estes recursos ajudam somente na degradao do desempenho do sistema devido a muitas falhas e swapping de maneira mais graciosa; fazem pouco para ajudar o desempenho do sub-sistema da memria virtual (apesar de poderem desempenhar uma funo maior no desempenho do sistema todo).

Devido complexidade inerente de um sistema operacional com memria virtual de pginas sob demanda, monitorar os recursos relacionados memria sob o Red Hat Enterprise Linux pode ser confuso. Consequentemente, melhor comear pelas ferramentas mais simples e seguir adiante. Usando o free, possvel obter uma viso geral concisa (e de certa maneira simplista) da utilizao da memria e de swap. Veja aqui um exemplo:
Ns percebemos que este sistema tem 1.2GB de RAM, dos quais somente 350MB esto em uso. Como esperado num sistema com tanta memria RAM livre, nenhuma das parties swap de 500MB est em uso. Contraste aquele exemplo com esse:
Esse sistema tem em torno de 256MB de RAM e a maioria est em uso, deixando apenas 8MB livres. Mais de 100MB da partio swap de 500MB esto em uso. Apesar desse sistema ser mais limitado que o primeiro em termos de memria, temos que investigar um pouco mais para saber se esta limitao de memria est causando problemas de desempenho. Apesar de ser mais secreto que o free, o vmstat tem o benefcio de apresentar mais que apenas estatsticas de utilizao da memria. Aqui est o output de vmstat 1 10:
r 2 2 1 1 2 3 3 2 3 procs b w 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 swpd 111304 111304 111304 111304 111304 111304 111304 111304 111304 free 9728 9728 9616 9616 9616 9620 9440 9276 9624 buff 7036 7036 7036 7036 7052 7052 7076 7076 7092 memory cache 107204 107204 107204 107204 107204 107204 107360 107368 107372 si 0 0 0 0 0 0 92 0 0 swap so 0 0 0 0 0 0 0 0 0 bi 6 0 0 0 0 0 244 0 16 io bo 10 0 0 0 48 0 0 0 0 in 120 526 552 624 603 768 820 832 813 system cs 24 1653 2219 699 1466 932 1230 1060 1655 us 10 96 94 98 95 90 85 87 93 sy 2 4 5 2 5 4 9 6 5 cpu id 89 0 1 0 0 6 6 7 2
55
2 111304
9624
7108 107372
972 1189
1165
68
23
Durante essa amostra de 10 segundos, a quantidade de memria livre (o campo free) varia ligeiramente, e h um pouco de I/O relacionada a swap (os campos si e so), mas, no geral, esse sistema est funcionando bem. No entanto, duvidoso o quanto de trabalho adicional pode suportar, dada a utilizao de memria corrente. Quando pesquisamos questes relativas memria, frequentemente necessrio determinar como o sub-sistema de memria virtual do Red Hat Enterprise Linux est usando a memria do sistema. Ao usar o sar, possvel examinar o aspecto do desempenho do sistema em mais detalhes. Ao rever o relatrio do sar -r, podemos examinar a utilizao da memria e de swap mais de perto:
Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 12:00:01 12:10:00 12:20:00 ... 08:40:00 Average: AM kbmemfree kbmemused AM 240468 1048252 AM 240508 1048212 PM 934132 324346 354588 964374 %memused kbmemshrd kbbuffers 81.34 0 133724 81.34 0 134172 27.51 74.83 0 0 26080 96072 07/22/2003 kbcached 485772 485600 185364 467559
Os campos kbmemfree e kbmemused exibem as estatsticas tpicas de memria usada e memria livre, com a porcentagem de memria utilizada exibida no campo %memused. Os campos kbbuffers e kbcached mostram quantos kilobytes de memria esto alocadas para buffers e para o cache de dados do sistema todo. O campo kbmemshrd sempre zero para sistemas usando o kernel 2.4 do Linux (como o Red Hat Enterprise Linux). As linhas deste relatrio foram quebradas para caber na pgina. Aqui est o restante de cada linha, com o timestamp adicionado esquerda para facilitar a leitura:
12:00:01 12:10:00 12:20:00 ... 08:40:00 Average: AM AM AM PM kbswpfree kbswpused 522104 0 522104 0 522104 522104 0 0 %swpused 0.00 0.00 0.00 0.00
Para a utilizao da memria swap, os campos kbswpfree e kbswpused exibem as quantidades de swap livre e de espao swap usado, em kilobytes, com o campo %swpused exibindo o espao swap utilizado em porcentagem. Para aprender mais sobre a atividade de swapping ocorrendo, use o relatrio sar -W. Aqui est um exemplo:
Linux 2.4.20-1.1931.2.231.2.10.entsmp (raptor.example.com) 12:00:01 12:10:01 12:20:00 ... 03:30:01 Average: AM AM AM PM pswpin/s pswpout/s 0.15 2.56 0.00 0.00 0.42 0.11 2.56 0.37 07/22/2003
Percebemos aqui que, em mdia, houve trs vezes menos pginas trazidas de swap (pswpin/s) que pginas indo para swap (pswpout/s).
56
Para entender melhor como as pginas esto sendo usadas, consulte o relatrio sar -B:
Linux 2.4.20-1.1931.2.231.2.10.entsmp (raptor.example.com) 12:00:01 12:10:00 12:20:00 ... 08:40:00 Average: AM AM AM PM pgpgin/s pgpgout/s 0.03 8.61 0.01 7.51 0.00 201.54 7.79 201.54 activepg 195393 195385 71236 169367 inadtypg 20654 20655 1371 18999 inaclnpg 30352 30336 6760 35146 07/22/2003 inatarpg 49279 49275 15873 44702
Aqui podemos determinar quantos blocos por segundo so paginados do (paged in) disco (pgpgin/s) e paginados para o (paged out) disco (pgpgout/s). Estas estatsticas servem como um barmetro da atividade geral da memria virtual. Entretanto, pode-se obter mais conhecimento ao examinar os outros campos deste relatrio. O kernel do Red Hat Enterprise Linux marca todas as pginas como ativas ou inativas. Como o nome implica, as pginas ativas esto em uso corrente de alguma forma (como processos ou pginas de buffer, por exemplo), enquanto as pginas inativas no esto. Este relatrio-exemplo mostra que a lista de pginas ativas (o campo activepg) tem, em mdia, aproximadamente 660MB 3. Os campos restantes deste relatrio concentram-se na lista inativa pginas que, por alguma razo, no foram utilizadas recentemente. O campo inadtypg mostra quantas pginas inativas esto sujas (alteradas) e talvez precisem ser gravadas no disco. O campo inaclnpg, por outro lado, mostra quantas pginas inativas esto limpas (inalteradas) e no precisam ser gravadas no disco. O campo inatarpg representa o tamanho desejado da lista inativa. Esse valor calculado pelo kernel do Linux e dimensionado de tal forma que a lista inativa continua grande o suciente para atuar como um pool de substituio de pginas. Para mais dicas sobre o status de pginas (especicamente, a frequncia de alterao de status), use o relatrio sar -R. Aqui est uma amostra:
Linux 2.4.20-1.1931.2.231.2.10.entsmp (raptor.example.com) 12:00:01 12:10:00 12:20:00 ... 08:50:01 Average: AM AM AM PM frmpg/s -0.10 0.02 -3.19 0.01 shmpg/s 0.00 0.00 0.00 0.00 bufpg/s 0.12 0.19 0.46 -0.00 campg/s -0.07 -0.07 0.81 -0.00 07/22/2003
As estatsticas deste relatrio sar especco so nicas, pois podem ser positivas, negativas ou zero. Quando positivas, o valor indica a frequncia com a qual as pginas desse tipo esto aumentando. Quando negativas, o valor indica a frequncia com a qual as pginas desse tipo esto diminuindo. O valor zero indica que pginas desse tipo no esto aumentando nem diminuindo. Nesse exemplo, a ltima amostra exibe um pouco mais de trs pginas por segundo sendo alocadas da lista de pginas livres (o campo frmpg/s) e aproximadamente uma pgina por segundo sendo adicionada ao cache de pginas (o campo campg/s). A lista de pginas usadas como buffers (o campo bufpg/s) ganhou aproximadamente uma pgina a cada dois segundos, enquanto a lista de pginas da memria compartilhada (o campo shmpg/s) no ganhou nem perdeu pginas.
3.
O tamanho de pgina sob o Red Hat Enterprise Linux no sistema x86 usado neste exemplo 4096 bytes.
Sistemas baseados em outras arquiteturas podem ter tamanhos de pgina diferentes.
57

Esta seo inclui vrias fontes que podem ser usadas para aprender mais sobre o monitoramento de recursos e sobre o assunto abordado neste captulo relativo ao Red Hat Enterprise Linux.

Os seguintes recursos so instalados no decorrer de uma tpica instalao do Red Hat Enterprise Linux e podem ajud-lo a aprender mais sobre o assunto abordado neste captulo.

Pgina man free(1) Aprenda a exibir as estatsticas da memria livre e usada. Pgina man vmstat(8) Aprenda a exibir uma viso geral concisa de processos, memria, swap, I/O, sistema e utilizao da CPU. Pgina man sar(1) Aprenda a produzis relatrios de utilizao dos recursos do sistema. Pgina man sa2(8) Aprenda a produzir arquivos dirios do relatrio de utilizao dos recursos do sistema.
4.7.2. Sites teis
http://people.redhat.com/alikins/system_tuning.html Informao de Ajuste do Sistema para Servidores Linux. Uma abordagem consciente do ajuste de desempenho e monitoramento de recursos para servidores. http://www.linuxjournal.com/article.php?sid=2396 Ferramentas de Monitoramento de Desempenho para Linux. Essa pgina mais direcionada ao administrador interessado em elaborar uma soluo grca personalizada de desempenho. Escrita h muitos anos atrs, alguns detalhes talvez no se apliquem mais, mas o conceito e execuo gerais ainda funcionam.

Os livros a seguir abordam vrias questes relacionadas ao monitoramento de recursos e so boas fontes de informao para administradores de sistemas Red Hat Enterprise Linux.

O Guia de Administrao de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. Inclui um captulo sobre diversas ferramentas de monitoramento de recursos abordadas aqui. Linux Performance Tuning and Capacity Planning de Jason R. Fink e Matthew D. Sherer; Sams Oferece vises mais aprofundadas das ferramentas de monitoramento de recursos abordadas aqui e inclui outras que podem ser apropriadas para necessidades de monitoramento mais especcas. Red Hat Linux Security and Optimization de Mohammed J. Kabir; Red Hat Press Aproximadamente, as 150 primeiras pginas deste livro abordam questes relativas ao desempenho. Isso inclui captulos dedicados a questes de desempenho especcas rede, Internet, e-mail e servidores de arquivos. Linux Administration Handbook de Evi Nemeth, Garth Snyder, e Trent R. Hein; Prentice Hall Oferece um pequeno captulo com escopo similar ao deste livro, mas inclui uma seo interessante sobre o diagnstico de um sistema que cou lento repentinamente. Linux System Administration: A Users Guide de Marcel Gagne; Addison Wesley Professional Contm um pequeno captulo sobre o monitoramento e ajuste de desempenho. Essential System Administration (3a Edio) de Aeleen Frisch; OReilly & Associates O captulo sobre a administrao de recursos do sistema contm boas informaes genricas, com algumas especcas ao Linux.
58
Captulo 4. Memria Fsica e Virtual System Performance Tuning (2a Edio) de Gian-Paolo D. Musumeci e Mike Loukides; OReilly & Associates Apesar de ser altamente direcionado a implementaes mais tradicionais do UNIX, h muitas referncias especcas ao Linux ao longo do livro.
Captulo 5.
Administrando o Armazenamento
Se h alguma atividade que toma a maior parte do dia de um administrador de sistemas, esta deve ser a administrao do armazenamento. Parece que os discos esto sempre sem espao livre, sendo sobrecarregados por muitas atividades I/O ou falhando inesperadamente. Sendo assim, vital ter um conhecimento slido do armazenamento em disco para ser um administrador de sistemas competente.
5.1. Uma Viso Geral do Hardware de Armazenamento

Antes de administrar o armazenamento, preciso entender o hardware no qual os dados so armazenados. A no ser que voc j tenha algum conhecimento sobre a operao do dispositivo de armazenamento em massa, poder se ver numa situao com um problema relativo ao armazenamento, mas no possuir o conhecimento elementar para interpretar o que est vendo. Ao obter um pouco de conhecimento da operao do respectivo hardware, voc poder determinar se o sub-sistema de armazenamento de seu computador est operando apropriadamente. A grande maioria dos dispositivos de armazenamento em massa usam alguma forma de mdia rotativa e suporta o acesso randmico aos dados nesta mdia. Isso signica que os seguintes componentes esto presentes de alguma forma em praticamente todos os dispositivos de armazenamento em massa:

Pratos de disco (disk platters) Dispositivo de acesso/gravao de dados Braos de acesso
As sees seguintes exploram cada um destes componentes em mais detalhes.
5.1.1. Pratos de Disco

A mdia rotativa usada para quase todos os dispositivos de armazenamento em massa tem a forma de um ou mais pratos circulares e achatados. O prato pode ser composto de diversos materiais diferentes, como alumnio, vidro e policarbonato. A superfcie de cada prato tratada de maneira a possibilitar o armazenamento de dados. A natureza exata desse tratamento depende da tecnologia de armazenamento de dados utilizada. A tecnologia mais comum baseada na propriedade do magnetismo; nestes casos os pratos so cobertos de um componente que exibe boas caractersticas magnticas. Uma outra tecnologia comum de armazenamento baseada nos princpios pticos; nestes casos, os pratos so cobertos por materiais cujas propriedades pticas podem ser modicadas, assim permitindo armazenar os dados opticamente1 . No importa a tecnologia de armazenamento em uso; os pratos de disco so torcidos, permitindo sua superfcie inteira varrer um outro componente o dispositivo de acesso/gravao de dados.
1.
Alguns dispositivos pticos notadamente os drives de CD-ROM usam tticas um pouco diferentes para
o armazenamento de dados; estas diferenas so apontadas ao longo do captulo.
60
Captulo 5. Administrando o Armazenamento
5.1.2. Dispositivo de acesso/gravao de dados

O dispositivo de acesso/gravao o componente que leva os bits e bytes no qual opera um sistema de computador e os transforma em variaes magnticas ou pticas, necessrias para interagir com os materiais que cobrem a superfcie dos pratos de disco. s vezes, as condies sob as quais estes dispositivos devem operar so desaadoras. Por exemplo: num armazenamento em massa magneticamente baseado, os dispositivos de acesso/gravao (conhecidos como cabeas) devem estar bem prximos superfcie do prato. No entanto, se a cabea e a superfcie do prato do disco tivessem contato, a frico resultante danicaria ambos seriamente. Sendo assim, as superfcies da cabea e do prato so polidas cuidadosamente, e a cabea usa presso do ar exercida pelos pratos giratrios para utuar sobre a superfcie do prato, "voando" h uma altitude mais na que um o de cabelo. por este motivo que os drives de disco magnticos so sensveis a choque, alteraes de temperatura repentinas e quaisquer contaminaes do ar. Os desaos enfrentados pelas cabeas pticas so de certa forma diferentes daqueles enfrentados pelas cabeas magnticas aqui, o grupo da cabea deve permanecer h uma distncia relativamente constante da superfcie do prato. Caso contrrio, as lentes usadas para focar no prato no produzem uma imagem sucientemente denida. Em qualquer um dos casos, as cabeas usam uma quantidade muito pequena da rea da superfcie do prato para o armazenamento de dados. Conforme o prato gira abaixo das cabeas, essa rea da superfcie toma a forma de uma linha circular muito na. Se essa fosse a maneira como os dispositivos de massa funcionam, signicaria que mais de 99% da rea da superfcie do prato seria desperdiada. Poderia-se montar cabeas adicionais sobre o prato, mas, para utilizar totalmente a rea da superfcie do prato, seriam necessrias mais de mil cabeas. Se faz necessrio um mtodo para mover a cabea sobre a superfcie do prato.
5.1.3. Braos de Acesso

Ao usar uma cabea conectada a um brao capaz de varrer toda a superfcie do prato, possvel usar o prato totalmente para o armazenamento de dados. Entretanto, o brao de acesso deve ser capaz de duas coisas:

Mover-se rapidamente Mover-se com muita preciso
O brao de acesso deve mover-se o mais rpido possvel porque o tempo gasto movendo a cabea de uma posio a outra tempo desperdiado. Isso ocorre porque no possvel acessar nenhum dado at que o brao de acesso pare de mover2. O brao de acesso deve ser capaz de mover-se com grande preciso porque, conforme armado anteriormente, a rea da superfcie usada pelas cabeas muito pequena. Sendo assim, para usar a capacidade de armazenamento do prato ecientemente, necessrio mover as cabeas somente o suciente para garantir que todos os dados gravados na nova posio no sobrescrevam os dados gravados numa posio anterior. Isso tem o efeito de dividir conceitualmente a superfcie do prato em mil ou mais "anis" concntricos ou faixas. O movimento do brao de acesso de uma faixa para outra frequentemente referido como busca, e o tempo que leva para o brao de acesso mover-se de uma faixa a outra conhecido como tempo de busca.
2. Em alguns dispositivos pticos (como drives de CD-ROM), o brao de acesso move-se continuamente,
fazendo com que o grupo da cabea faa um movimento espiral ao longo da superfcie do prato. Essa uma diferena fundamental de como o meio de armazenamento usado, e reete a origem do CD-ROM como um meio de armazenamento para msica, onde a recuperao contnua de dados uma operao mais comum que a busca de um ponto de dados especco.
61
Quando h pratos mltiplos (ou um prato com ambas superfcies utilizadas para o armazenamento de dados), os braos de cada superfcie cam empilhados, permitindo que a mesma faixa de cada superfcie seja acessada simultaneamente. Se as faixas de cada superfcie pudessem ser visualizadas com o acesso esttico sobre uma determinada faixa, elas pareceriam estar empilhadas uma sobre a outra, formando um formato cilndrico. Consequentemente, o conjunto de faixas acessvel numa determinada posio dos braos de acesso so conhecidas como cilindro.
5.2. Conceitos de Endereamento do Armazenamento

A congurao dos pratos de disco, cabeas e dos braos de acesso possibilita posicionar a cabea sobre qualquer parte de qualquer superfcie de qualquer prato no dispositivo de armazenamento em massa. No entanto, isso no suciente; para usar essa capacidade de armazenamento devemos ter algum mtodo para atribuir endereos a partes uniformemente dimensionadas do armazenamento disponvel. H um aspecto nal necessrio a este processo. Considere todas as faixas dos diversos cilindros presentes em um tpico dispositivo de armazenamento em massa. Como as faixas tm dimetros variados, suas circunferncias tambm variam. Sendo assim, se o armazenamento estivesse endereado somente ao nvel da faixa, cada faixa teria quantidades diferentes de dados a faixa #0 (a mais prxima do centro do prato) pode ter 10.827 bytes, enquanto a faixa #1.258 (prxima extremidade externa do prato) pode ter 15.382 bytes. A soluo dividir cada faixa em diversos setores ou blocos de segmentos de armazenamento de tamanho consistente (geralmente 512 bytes). O resultado que cada faixa contm um nmero denido3 de setores. Um efeito colateral disso que cada faixa contm espao no-usado o espao entre setores. Apesar do nmero constante de stores em cada faixa, a quantidade de espao no-usado varia h relativamente pouco espao no-usado nas faixas de dentro e uma quantidade bem maior de espao no-usado nas faixas de fora. Em ambos os casos, este espao no-usado desperdiado, j que no possvel armazenar dados ali. Em contrapartida, a vantagem deste espao desperdiado que agora possvel mapear efetivamente o armazenamento para um dispositivo de massa. De fato, h dois mtodos de mapeamento mapeamento baseado na geometria e mapeamento baseado no bloco.
5.2.1. Mapeamento Baseado na Geometria

O termo mapeamento baseado na geometria refere-se ao fato dos dispositivos de armazenamento em massa realmente armazenarem dados num ponto fsico especco no meio de armazenamento. No caso dos dispositivos aqui descritos, isto refere-se a trs itens especcos que denem um ponto especco nos pratos do disco do dispositivo:

Cilindro Cabea Setor
As sees a seguir explicam como um endereo hipottico pode descrever uma localidade fsica especca no meio de armazenamento.
3. Enquanto os dispositivos de armazenamento em massa mais antigos usam o mesmo nmero de setores para
todas as faixas, os dispositivos mais recentes dividiram a gama de cilindros em "zonas" diferentes, com cada zona contendo um nmero diferente de setores por faixa. O motivo tirar proveito do espao adicional entre os setores nos cilindros mais externos, onde h mais espao no-utilizado entre os setores.
62 5.2.1.1. Cilindro
Como armado anteriormente, o cilindro indica uma posio especca do brao de acesso (e, portanto, as cabeas de acesso/gravao). Ao especicar um determinado cilindro, estamos eliminando todos os outros cilindros, reduzindo nossa busca a apenas uma faixa de cada superfcie no dispositivo de armazenamento em massa. Cilindro 1014 Tabela 5-1. Mapeamento do Armazenamento Na Tabela 5-1, a primeira parte de um endereo baseado na geometria foi preenchido. Ainda h dois componentes indenidos neste endereo a cabea e o setor. 5.2.1.2. Cabea Ns estamos estritamente selecionando um prato especco do disco, mas, como cada superfcie tem uma cabea de acesso/gravao dedicada a ela, mais fcil pensar em termos de interao com uma determinada cabea. Na realidade, a essncia eletrnica do dispositivo seleciona uma cabea e desseleciona o resto somente interage com a cabea selecionada durante a operao I/O. Todas as outras faixas que formam o cilindro corrente agora foram eliminadas. Cilindro 1014 Tabela 5-2. Mapeamento do Armazenamento Na Tabela 5-2, as duas primeiras partes do endereo baseado na geometria foram preenchidos. Ainda h um componente nal faltando neste endereo o setor. 5.2.1.3. Setor Ao especicar um determinado setor, completamos o mapeamento e identicamos unicamente o bloco de dados desejado. Cilindro 1014 Tabela 5-3. Mapeamento do Armazenamento Na Tabela 5-3, o endereo baseado na geometria completo foi preenchido. Este endereo identica a localidade de um bloco especco dentre todos os blocos deste dispositivo. 5.2.1.4. Problemas com Mapeamento Baseado na Geometria Apesar do mapeamento baseado na geometria ser simples, h uma rea de ambiguidade que causa problemas a numerao dos cilindros, cabeas e setores. verdade que cada endereo baseado na geometria identica unicamente um bloco de dados especco, mas isto se aplica somente se o esquema de numerao dos cilindros, cabeas e setores no Cabea 2 Setor 12 Cabea 2 Setor X Cabea X Setor X
63
for alterado. Se o esquema de numerao mudar (como mudar o hardware/software interagindo com o dispositivo de armazenamento), ento o mapeamento entre os endereos baseados na geometria e seus blocos de dados correspondentes pode mudar, impossibilitando o acesso aos dados desejados. Devido esse potencial para ambiguidades, foi desenvolvida uma nova ttica de mapeamento. A prxima seo descreve-a com mais detalhes.
5.2.2. Mapeamento Baseado no Bloco

O mapeamento baseado no bloco bem mais simples que o mapeamento baseado na geometria. No mapeamento baseado no bloco, cada bloco de dados recebe um nmero nico. Esse nmero passado do computador para o dispositivo de armazenamento em massa, que executa a converso internamente para o endereo baseado na geometria, necessrio pelo circuito de controle do dispositivo. Como a converso para um endereo baseado na geometria sempre feita pelo prprio dispositivo, sempre consistente e elimina o problema de dar o mapeamento baseado na geometria ao dispositivo.
5.3. Interfaces do Dispositivo de Armazenamento em Massa

Cada dispositivo usado num sistema de computador deve ter alguns meios de conectar-se ao sistema do computador. Esse ponto de conexo conhecido como uma interface. Os dispositivos de armazenamento em massa no so diferentes tambm tm interfaces. importante saber sobre as interfaces por duas razes:

H muitas interfaces diferentes (na maioria incompatveis) Interfaces diferentes tm caractersticas de desempenho e preos diferentes
Infelizmente, no h uma nica interface de dispositivo universal e muito menos uma nica interface de dispositivo de armazenamento em massa. Sendo assim, os administradores de sistemas devem estar cientes da(s) interface(s) suportada(s) pelos sistemas de sua empresa. Caso contrrio, h um risco real de adquirir o hardware errado ao planejar uma atualizao (upgrade) dos sistemas. Interfaces diferentes tm capacidades de desempenho diferentes, o que torna algumas interfaces mais indicadas para determinados ambientes. Por exemplo: interfaces capazes de suportar dispositivos de alta velocidade so mais indicadas para ambientes de servidores, enquanto interfaces mais lentas so mais indicadas para o uso leve do desktop. Tais diferenas de desempenho tambm trazem diferenas nos preos, portanto voc como sempre obtm aquilo que pagou. A computao de alto desempenho no barata.
5.3.1. Histrico
Ao longo dos anos, houve muitas interfaces diferentes criadas para dispositivos de armazenamento em massa. Algumas foram deixadas de lado e outras ainda esto em uso. No entanto, a seguinte lista provida para se ter uma idia do escopo do desenvolvimento das interfaces ao longo dos ltimos trinta anos e para oferecer uma perspectiva das interfaces usadas hoje. FD-400 Uma interface originalmente desenvolvida para os drives de disco oppy de 8 polegadas em meados dos anos 70. Usava um cabo condutor 44 com um conector circuit board edge que fornecia energia e dados.
64 SA-400
Uma outra interface de drive de disco oppy (desta vez, desenvolvida originalmente no m dos anos 70 para o ento novo drive de oppy de 5,25 polegadas). Usava um cabo condutor 34 com um conector socket padro. Uma verso ligeiramente modicada desta interface ainda usada hoje em dia para drives de disquetes de 5,25 e 3,5 polegadas. IPI Signica Intelligent Peripheral Interface. Essa interface foi usada nos drives de disco de 8 e 14 polegadas, empregados em mini-computadores dos anos 70. SMD Um sucessor da IPI, o SMD (Storage Module Device) foi usado em discos rgidos de minicomputadores de 8 e 14 polegadas nos anos 70 e 80. ST506/412 Uma interface de disco rgido do incio dos anos 80. Usada em muitos computadores pessoais da poca, essa interface usava dois cabos um condutor 34 e um condutor 20. ESDI Signica Interface Aprimorada de Dispositivo Pequeno (Enhanced Small Device Interface). Essa interface foi considerada sucessora da ST506/412 com taxas de transferncia mais rpidas e tamanhos maiores de drives suportados. Datada de meados dos anos 80, a ESDI usava o mesmo esquema de conexo de dois cabos de sua antecessora. Havia tambm interfaces proprietrias dos maiores fabricantes de computadores da poca (IBM e DEC, principalmente). A inteno por trs da criao destas interfaces era tentar proteger o negcio extremamente lucrativo dos perifricos para seus computadores. Entretanto, devido sua natureza proprietria, os dispositivos compatveis com estas interfaces eram mais caros que seus dispositivos no proprietrios equivalentes. Por causa disso, estas interfaces no tiveram popularidade longo prazo. Apesar das interfaces proprietrias terem desaparecido em sua maioria, e as interfaces descritas no incio desta seo no terem muito ou nenhum market share, importante saber sobre estas interfaces que no so mais usadas, pois provam uma questo nada permanece por muito tempo na indstria de computadores. Portanto, que atento s novas tecnologias de interface. Um dia voc pode descobrir que uma delas pode ser melhor para suas necessidades do que aquelas mais tradicionais que voc usa.
5.3.2. Interfaces Padro de Hoje

Ao contrrio das interfaces proprietrias mencionadas na seo anterior, algumas interfaces foram mais amplamente adotadas e transformaram-se nos padres da indstria. Duas interfaces em particular sofreram essa transio e so o corao da indstria de armazenamento de hoje:

IDE/ATA SCSI
5.3.2.1. IDE/ATA IDE signica Integrated Drive Electronics. Essa interface tem origem no m dos anos 80 e usa um conector de 40 pinos.
65
Nota Na realidade, o nome apropriado dessa interface "AT Attachment" (ou ATA), mas o termo "IDE" (que, na verdade, refere-se a um dispositivo de armazenamento em massa compatvel com a ATA) ainda usado. No entanto, o restante desta seo usa o nome apropriado da interface ATA.
A ATA implementa uma topologia de canal, com cada canal suportando dois dispositivos de armazenamento em massa - o mestre e o escravo. Estes termos podem ser mal-interpretados, pois implicam algum tipo de relao entre os dispositivos, mas este no o caso. A seleo de qual dispositivo o mestre e qual o escravo feita normalmente atravs do uso de blocos jumper em cada dispositivo.
Nota Uma inovao mais recente a introduo das capacidades de seleo do cabo ATA. Essa inovao requer o uso de um cabo especial, um controlador ATA e dispositivos de armazenamento em massa que suportam a seleo de cabo (normalmente, atravs de uma congurao "cable select" do jumper.) Quando congurada apropriadamente, a seleo de cabo elimina a necessidade de alterar os jumpers movendo dispositivos; ao invs disso, a posio do dispositivo no cabo da ATA denota se mestre ou escravo.
Uma variao desta interface ilustra a nica maneira atravs da qual as tecnologias podem ser mescladas e tambm introduz nossa prxima interface padro. A ATAPI uma variao da interface ATA e sua sigla signica AT Attachment Packet Interface. Usada principalmente por drives de CD-ROM, a ATAPI obedece aos aspectos eltrico e mecnico da interface ATA, mas usa o protocolo de comunicao da prxima interface a ser abordada SCSI. 5.3.2.2. SCSI Formalmente conhecida como Small Computer System Interface, a SCSI como conhecida hoje foi originada no incio dos anos 80 e declarada como padro em 1986. Assim como a ATA, a SCSI usa uma topologia de canal, mas estas so as nicas similaridades. Usar uma topologia de canal signica que cada dispositivo do canal deve ser unicamente identicvel de alguma maneira. Enquanto a ATA suporta somente dois dispositivos diferentes para cada canal e os nomeia, a SCSI faz isso ao atribuir a cada dispositivo num canal SCSI um endereo numrico nico ou ID SCSI. Cada dispositivo num canal SCSI deve ser congurado (geralmente por jumpers ou interruptores4 ) para responder ao seu ID SCSI. Antes de continuar esta explanao, importante notar que o padro SCSI no representa uma nica interface, mas uma famlia de interfaces. H diversas reas nas quais a SCSI varia:

Largura do canal Velocidade do canal Caractersticas eltricas
O padro SCSI original descrevia uma topologia de canal na qual oito linhas do canal eram usadas para transferncia de dados. Isto signica que os primeiros dispositivos SCSI podiam transferir um byte de dados por vez. Nos anos seguintes, o padro foi expandido para permitir implementaes
4. Alguns hardware de armazenamento (geralmente aqueles que incorporam "portadores" de drives removveis)
so desenvolvidos de modo que o ato de plugar um mdulo automaticamente ajusta o ID SCSI para um valor apropriado.
66
nas quais dezesseis linhas podiam ser usadas, duplicando a quantidade de dados que os dispositivos podiam transferir. As implementaes originais de "8 bits" foram ento referidas como SCSI estreitos, enquanto as implementaes mais novas de 16 bits eram conhecidas como SCSI largos. Originalmente, a velocidade de canal do SCSI foi ajustada para 5MHz, permitindo uma taxa de transferncia de 5MB/segundo no canal SCSI original de 8 bits. No entanto, as revises subsequentes do padro duplicaram essa velocidade para 10MHz, resultando em 10MB/segundo para o SCSI estreito e 20MB/segundo para o SCSI largo. Assim como na largura do canal, as alteraes de velocidade do canal tambm receberam novos nomes; a velocidade de 10MHz do canal foi chamada rpida. As melhorias subsequentes trouxeram as velocidades de canal para ultra (20MHz), rpida40 (40MHz), e rpida805 . Outros aumentos nas taxas de transferncia trouxeram diversas verses diferentes da velocidade de canal ultra160. Combinando estes termos, possvel nomear concisamente vrias conguraes do SCSI. Por exemplo: "SCSI ultra largo" refere-se a um canal SCSI de 16 bits rodando a 20MHz. O padro SCSI original usava sinalizao single-ended; esta uma congurao na qual somente um condutor usado para passar um sinal eltrico. Implementaes posteriores tambm permitiram o uso da sinalizao diferencial, na qual dois condutores so usados para passar um sinal. O SCSI diferencial (mais tarde renomeado como diferencial de alta voltagem ou SCSI HVD) tinha o benefcio de sensibilidade reduzida a barulho eltrico e permitia comprimentos maiores de cabo, mas nunca tornou-se popular no mercado convencional da computao. Uma implementao posterior, conhecida como diferencial de baixa voltagem (LVD), nalmente inltrou o mercado convencional e um requisito para velocidades de canal mais altas. A largura de um canal SCSI no dita somente a quantidade de dados que pode ser transferida com cada ciclo do relgio, mas tambm determina quantos dispositivos podem ser conectados a um canal. O SCSI normal suporta 8 dispositivos endereados unicamente, enquanto o SCSI largo suporta 16. Nos dois casos, necessrio garantir que todos os dispositivos estejam ajustados para usar um nico ID SCSI. Dois dispositivos compartilhando um nico ID causam problemas que podem levar corrupo de dados. Uma outra coisa para ter em mente que todo dispositivo no canal usa um ID. Isso inclui o controlador SCSI. Frequentemente, os administradores de sistemas esquecem disso e inadvertidamente ajustam um dispositivo para usar o mesmo ID SCSI que o controlador do canal. Isso tambm signica que, na prtica, somente 7 (ou 15, para SCSI largo) dispositivos podem estar presentes em um nico canal, j que cada canal deve reservar um ID para o controlador.
Dica A maioria das implementaes SCSI inclui alguns meios de scanear o canal SCSI; isso frequentemente usado para conrmar se todos os dispositivos esto congurados apropriadamente. Se o scan de um canal retornar o mesmo dispositivo para todos os IDs SCSI, este dispositivo foi ajustado incorretamente para o mesmo ID SCSI que o controlador SCSI. Para resolver este problema, recongure o dispositivo para usar um ID SCSI diferente (e nico).
Como a arquitetura do SCSI orientada ao canal, necessrio terminar apropriadamente ambas extremidades do canal. A terminao feita ao alocar uma carga de impedncia correta em cada condutor que compe o canal SCSI. A terminao um requisito eltrico; sem ela, os diversos sinais presentes no canal seriam perdidos pelas extremidades, distorcendo toda a comunicao. Muitos (mas no todos) dispositivos SCSI vm com terminadores internos que podem ser ativados ou desativados usando interruptores ou jumpers. Terminadores externos tambm esto disponveis.
5. A Rpida80 no representa uma mudana tcnica na velocidade do canal; o canal de 40MHz foi mantido,
mas os dados foram inseridos no incio e m de cada pulso do relgio, efetivamente dobrando o output.
67
Uma ltima coisa para ter em mente sobre o SCSI no apenas um padro de interface para dispositivos de armazenamento em massa. Muitos outros dispositivos (como scanners, impressoras e dispositivos de comunicao) usam SCSI. Apesar de serem menos comuns que os dispositivos de armazenamento em massa SCSI, eles existem. No entanto, provvel que, com o advento do USB e IEEE-1394 (frequentemente chamado de Firewire), estas interfaces sejam mais usadas para este tipo de dispositivo no futuro.
Dica As interfaces USB e IEEE-1394 tambm esto comeando suas incurses na arena do armazenamento em massa; no entanto, no existe nenhum dispositivo de armazenamento em massa USB ou IEEE-1394 no momento. As ofertas de hoje so baseadas nos dispositivos ATA ou SCSI com circuito de converso externa.
No importa qual interface um dispositivo de armazenamento em massa usa; o funcionamento interno do dispositivo determina seu desempenho. A seo seguinte explora esta questo importante.
5.4. Caractersticas de Desempenho do Disco Rgido

As caractersticas de desempenho do disco rgido foram introduzidas na Seo 4.2.4. Esta seo aborda a questo com maior profundidade. importante que os administradores de sistemas a compreendam porque, sem o mnimo conhecimento bsico de como os discos rgidos operam, possvel alterar a congurao de seu sistema inadvertidamente de modo a impactar negativamente seu desempenho. O tempo que leva para um disco rgido responder a e completar um pedido I/O depende de duas coisas:

As limitaes mecnicas e eltricas do disco rgido A carga I/O imposta pelo sistema
As sees seguintes exploram estes aspectos do desempenho do disco rgido com mais detalhes.
5.4.1. Limitaes Mecnicas/Eltricas

Como os discos rgidos so dispositivos eletro-mecnicos, esto sujeitos a vrias limitaes em suas velocidades e desempenhos. Todo pedido I/O requer que os vrios componentes do disco trabalhem juntos para satisfaz-lo. J que cada um destes componentes tm caractersticas diferentes de desempenho, o desempenho geral do disco rgido determinado pela soma do desempenho individual dos componentes. Entretanto, os componentes eletrnicos so pelo menos uma ordem de magnitude mais rpidos que os componentes mecnicos. Portanto, so os componentes mecnicos que tm o maior impacto no desempenho geral do disco rgido.
Dica A maneira mais ecaz de melhorar o desempenho do disco rgido reduzir sua atividade mecnica o mximo possvel.
68
O tempo mdio de acesso de um disco rgido tpico aproximadamente 8,5 milissegundos. As sees a seguir explicam melhor este nmero, mostrando como cada componente impacta no desempenho geral do disco rgido. 5.4.1.1. Tempo de Processamento de Comandos Todos os discos rgidos produzidos hoje tm sistemas integrados controlando sua operao. Estes sistemas de computador executam as seguintes tarefas:

Interao com o mundo externo atravs da interface do disco rgido Controle da operao do resto dos componentes do disco rgido e recuperao de quaisquer condies de erro que possam ocorrer Processamento dos dados acessados da e gravados na mdia de armazenamento
Mesmo que os microprocessadores usados nos discos rgidos sejam relativamente poderosos, as tarefas atribudas a estes levam tempo para serem completas. Em mdia, este tempo prximo a 0,003 milissegundos. 5.4.1.2. Cabeas Acessando/Gravando Dados As cabeas de acesso/gravao do disco rgido funcionam somente quando os pratos do disco sobre os quais elas "voam" esto rodando. Como o movimento da mdia sob as cabeas que permite acessar ou ler os dados, o tempo que leva para a mdia contendo o setor desejado passar completamente por baixo da cabea o nico determinante da contribuio da cabea para o tempo total de acesso. A mdia de 0,0086 milissegundos para um drive de 10.000 RPM com 700 setores por faixa. 5.4.1.3. Latncia Rotacional Como os pratos do disco rgido esto girando continuamente, quando o pedido I/O chega, pouco provvel que o prato esteja exatamante no ponto certo de sua rotao para acessar o setor desejado. Consequentemente, mesmo que o resto do disco esteja pronto para acessar aquele setor, necessrio esperar at o prato girar, trazendo o setor desejado em posio sob a cabea de acesso/gravao. Este o motivo pelo qual os discos rgidos de alto desempenho tipicamente giram seus pratos a velocidades maiores. Hoje, as velocidades de 15.000 RPM so reservadas para os drives de desempenho mais alto, enquanto 5.400 RPM considerada adequada somente para drives de nvel bsico. A velocidade mdia de aproximadamente 3 milissegundos para um disco de 10.000 RPM. 5.4.1.4. Movimento do Brao de Acesso Se h um componente dos discos rgidos considerado o Tendo de Aquiles, este o brao de acesso. O brao deve mover muito rpida e corretamente atravs de distncias relativamente longas. Alm disso, o movimento do brao de acesso no contnuo deve acelerar rapidamente ao se aproximar do cilindro desejado e ento desacelerar rapidamente para evitar passar do ponto. Consequentemente, o brao de acesso deve ser forte (para suportar as foras violentas provocadas pela necessidade de movimentos rpidos) e leve ao mesmo tempo (para que haja menor massa para acelerar/desacelerar). difcil atingir estes objetivos conitantes, fato demonstrado pelo tempo relativamente longo que o movimento do brao de acesso leva quando comparado com o tempo que outros componentes levam. Sendo assim, o movimento do brao de acesso o fator determinante principal do desempenho geral de um disco rgido; 5,5 milissegundos, em mdia.
69
5.4.2. Cargas I/O e Desempenho

Um outro fator que controla o desempenho do disco rgido a carga I/O qual o disco rgido submetido. Veja alguns dos aspectos especcos carga I/O:

A quantidade de acessos versus gravaes O nmero de leitores/gravadores corrente A localidade dos acessos/gravaes
Estas questes so abordadas em detalhes nas prximas sees. 5.4.2.1. Acessos Versus Gravaes No disco rgido comum usando mdia magntica para armazenamento de dados, o nmero de operaes I/O de acesso (leitura) versus o nmero de operaes I/O de gravao no um fator preocupante, j que acessar e gravar dados leva o mesmo tempo6. Entretanto, outras tecnologias de armazenamento em massa levam tempos diferentes para processar acessos e gravaes 7 . O impacto disso que os dispositivos que levam um tempo mais longo para processar operaes de acesso I/O (por exemplo) so capazes de lidar com menos I/Os de gravao que I/Os de acesso. Ou seja, uma I/O de gravao consome mais da habilidade do dispositivo em processar pedidos I/O que a I/O de acesso. 5.4.2.2. Leitores/Gravadores Mltiplos Um disco rgido que processa pedidos I/O a partir de fontes mltiplas tem uma carga diferente que um disco rgido que atende aos pedidos I/O a partir de somente uma fonte. A principal razo deve-se ao fato de que os solicitantes I/O mltiplos tm o potencial de trazer cargas I/O maiores para serem conduzidas num disco rgido que um nico solicitante I/O. Isso ocorre porque o solicitante I/O deve executar um pouco de processamento antes que a I/O ocorra. Acima de tudo, o solicitante deve determinar a natureza do pedido I/O antes que possa ser executado. Como o processamento necessrio para esta determinao leva tempo, h um limite mximo para a carga I/O que qualquer solicitante pode gerar somente uma CPU mais rpida pode aument-lo. Esta limitao torna-se mais pronunciada se o solicitante requerer input humano antes de executar uma I/O. Entretanto, cargas I/O mais altas podem ser sustentadas com solicitantes mltiplos. Contanto que haja disponibilidade de energia suciente da CPU para suportar o processamento necessrio para gerar os pedidos I/O, adicionar mais solicitantes I/O aumenta a carga I/O resultante. No entanto, h outro aspecto que tambm inuencia na carga I/O resultante. Isso abordado na prxima seo.
6.
Esta no uma verdade absoluta. Todos os discos rgidos incluem alguma quantidade de memria cache na
placa, usada para melhorar o desempenho de acesso. No entanto, qualquer pedido I/O para acessar dados deve, eventualmente, ser atendido ao ler sicamente os dados pelo meio de armazenamento. Isso signica que, enquanto o cache pode aliviar os problemas de desempenho de acesso I/O, nunca pode eliminar o tempo necessrio para acessar os dados sicamente pelo meio de armazenamento. 7. Alguns drives de disco ptico apresentam este comportamento devido questes fsicas das tecnologias usadas para implementar o armazenamento de dados ptico.
70 5.4.2.3. Localidade de Acessos/Gravaes
Apesar de no ser estritamente restrito a um ambiente multi-solicitante, este aspecto do desempenho do disco rgido tende a aparecer mais neste tipo de ambiente. A questo se os pedidos I/O feitos de um disco rgido so de dados sicamente prximos a outros dados que tambm esto sendo solicitados. A razo de sua importncia torna-se aparente se a natureza eletromecnica do diso rgido mantida em mente. O componente mais lento de qualquer disco rgido o brao de acesso. Sendo assim, se os dados acessados pelos pedidos I/O de entrada no requerem movimentos do brao de acesso, o disco rgido capaz de atender mais pedidos I/O do que se os dados estivessem espalhados por todo o disco, requerendo bastante movimento do brao de acesso. Isto pode ser ilustrado ao observar as especicaes de desempenho do disco rgido. Estas especicaes frequentemente incluem tempos de busca ao cilindro adjacente (onde o brao de acesso pouco movido somente para o prximo cilindro), e tempos de busca com fora total (onde o brao de acesso movido do primeiro cilindro ao ltimo). Por exemplo: aqui esto os tempos de busca de um disco rgido de alto desempenho: Cilindro Adjacente 0.6 Fora Total 8.2
Tabela 5-4. Tempos de Busca ao Cilindro Adjacente e com Fora Total (em Milissegundos)
5.5. Tornando o Armazenamento Utilizvel

Uma vez estabelecido um dispositivo de armazenamento em massa, h poucos ns para utiliz-lo. verdade que os dados podem ser gravados neste e acessados deste, mas sem nenhuma estrutura bsica, o acesso de dados s possvel ao usar endereos de setor (geomtricos ou lgicos). So necessrios mtodos para facilitar a utilizao do armazenamento no-processado provido pelo disco rgido. As sees seguintes exploram algumas tcnicas comumente usadas para fazer isso.
5.5.1. Parties/Fatias
Frequentemente, a primeira coisa que intriga um administrador de sistemas que o tamanho do disco rgido pode ser bem maior que o necessrio para uma determinada tarefa. Como resultado, muitos sistemas operacionais tm a capacidade de dividir o espao de um disco rgido em vrias parties ou fatias. Como so separadas umas das outras, as parties podem ter quantidades de espao utilizado diferentes, e o espao utilizado de uma partio no tem impacto na outra. Por exemplo: a partio contendo os arquivos que compoem o sistema operacional no afetada pela partio contendo os arquivos do usurio, mesmo se esta estiver cheia. O sistema operacional continua com espao livre para seu prprio uso. Apesar de ser um pouco simplista, voc pode pensar nas parties como se fossem drives de disco separados. De fato, alguns sistemas operacionais referem-se s parties como "drives". No entanto, este ponto de vista no totalmente correto; portanto importante entendermos melhor as parties. 5.5.1.1. Atributos das Parties As parties so denidas pelos seguintes atributos:
Captulo 5. Administrando o Armazenamento Geometria da partio Tipo da partio Campo do tipo da partio
71
Estes atributos so explorados com mais detalhes nas sees a seguir. 5.5.1.1.1. Geometria A geometria de uma partio refere-se sua localizao fsica num disco rgido. A geometria pode ser especicada em termos de cilindros inicial e nal, cabeas e setores, mas geralmente as parties comeam e terminam nos limites dos cilindros. O tamanho de uma partio ento denido como a quantidade de armazenamento entre os cilindros inicial e nal. 5.5.1.1.2. Tipo da Partio O tipo da partio refere-se sua relao com as outras parties no disco rgido. H trs tipos diferentes de parties:

Parties primrias Parties extendidas Parties lgicas
Veja a descrio de cada tipo de partio nas prximas sees. 5.5.1.1.2.1. Parties Primrias As parties primrias so aquelas que ocupam um dos quatro slots primrios na tabela de parties do disco rgido. 5.5.1.1.2.2. Parties Extendidas As parties extendidas foram desenvolvidas em resposta necessidade de existir mais de quatro parties num disco rgido. Uma partio extendida pode conter diversas parties nela mesma, aumentando signicativamente o nmero de parties possveis num nico disco. A introduo das parties extendidas foi movida pelas sempre crescentes capacidades de novos drives de disco. 5.5.1.1.2.3. Parties Lgicas As parties lgicas so aquelas contidas numa partio extendida. Em termos de uso, so iguais a uma partio primria no-extendida.
5.5.1.1.3. Campo do Tipo da Partio Cada partio tem um campo de tipo que contm um cdigo indicando seu uso antecipado. O campo do tipo pode ou no reetir o sistema operacional do computador, mas reete como os dados devem ser armazenados dentro da partio. A seo seguinte contm mais informaes sobre isso.
72
5.5.2. Sistemas de Arquivo

Mesmo tendo o dispositivo de armazenamento em massa apropriado, congurado corretamente e particionado apropriadamente, no poderamos armazenar e recuperar informaes facilmente falta uma maneira de estruturar e organizar estas informaes. Precisamos de um sistema de arquivo. O conceito de um sistema de arquivo to fundamental para o uso dos dispositivos de armazenamento em massa, que o usurio comum de computador geralmente no distingue um do outro. Entretanto, os administradores de sistemas no podem ignorar os sistemas de arquivo e seu impacto no trabalho do dia-a-dia. Um sistema de arquivo um mtodo de representao de dados num dispositivo de armazenamento em massa. Os sistemas de arquivo geralmente possuem as seguintes caractersticas:

Armazenamento de dados baseado em arquivos Estrutura hierrquica de diretrio (s vezes chamada de "pasta") Registro de criao de arquivos, hora de acessos e de modicaes. Algum nvel de controle sobre o tipo de acesso permitido a um determinado arquivo Alguns conceitos sobre propriedade de arquivos (le ownership) Contabilidade do espao utilizado
Nem todos os sistemas de arquivo possuem todas estas caractersticas. Por exemplo: um sistema de arquivo construdo para um sistema operacional com um usurio nico poderia facilmente utilizar um mtodo de controle de acesso simplicado, e possivelmente acabar completamente com o suporte propriedade de arquivo. Um ponto para ter em mente que o sistema de arquivo usado pode ter um grande impacto na natureza da sua carga de trabalho diria. Ao garantir que o sistema de arquivo usado na sua empresa atende aos seus requisitos funcionais, voc pode assegurar no somente que o sistema de arquivo apropriado para a tarefa, mas tambm que mais fcil e ecientemente mantido. Com isso em mente, as sees seguintes exploram estas caractersticas mais a fundo. 5.5.2.1. Armazenamento Baseado em Arquivo Apesar dos sistemas de arquivo que usam a metfora do arquivo para armazenamento de dados serem quase to universais a ponto de no serem valorizados, ainda h alguns aspectos a serem considerados. Primeiro, deve-se estar ciente de quaisquer restries nos nomes dos arquivos. Por exemplo: quais os caracteres permitidos nos nomes de arquivos? Qual o tamanho mximo para o nome do arquivo? Estas questes so importantes, j que ditam os nomes de arquivos que podem ou no ser usados. Sistemas operacionais mais antigos com sistemas de arquivos mais primitivos frequentemente permitiam somente caracteres alfanumricos (em caixa alta) e nomes de arquivo 8.3 tradicional (um nome de arquivo de 8 caracteres, seguido por uma extenso de arquivo de 3 caracteres). 5.5.2.2. Estrutura Hierrquica de Diretrio Enquanto os sistemas de arquivo usados em alguns sistemas operacionais muito antigos no incluam o conceito de diretrios, todos os sistemas de arquivo comumente usados hoje incluem esta caracterstica. Os prprios diretrios so implementados como arquivos; o que signica que no necessrio nenhum utilitrio especial para mant-los. Alm disso, como os diretrios so arquivos em si, e contm arquivos, tambm podem conter outros diretrios, possibilitando uma hierarquia de diretrios multi-nvel. Este um conceito essencial com o qual todos os administradores de sistemas devem ser famliarizados - usar hierarquias de diretrios multi-nvel pode facilitar a administrao de arquivos para voc e seus usurios.
Captulo 5. Administrando o Armazenamento 5.5.2.3. Registro de Criao, Acessos e Hora de Modicao de Arquivos
73
A maioria dos sistemas de arquivo mantm o registro da hora na qual o arquivo foi criado; alguns tambm registram a hora de modicao e de acesso. Alm da convenincia de poder determinar quando um determinado arquivo foi criado, acessado ou modicado, estas datas so vitais para a operao apropriada de backups adicionais. Mais informaes sobre como os backups utilizam estas caractersticas do sistema de arquivo podem ser encontradas na Seo 8.2. 5.5.2.4. Controle de Acesso O controle de acesso uma rea na qual os sistemas de arquivo diferem drasticamente. Alguns sistemas de arquivo no tm um modelo de controle simples, enquanto outros so bem mais sosticados. Em termos gerais, os sistemas de arquivo mais modernos combinam dois componentes numa metodologia de controle de acesso coesa:

Identicao do usurio Lista de aes permitidas
Identicao do usurio signica que o sistema de arquivo, e seu sistema operacional, devem ser capazes de identicar unicamente usurios individuais. Isso possibilita ter responsabilidade total em relao a qualquer operao a nvel do sistema. Uma outra caracterstica muitas vezes til a dos grupos de usurios criar conjuntos de usurios conforme as necessidades. Os grupos so geralmente mais usados por empresas nas quais os usurios podem ser membros de um ou mais projetos. Uma outra caracterstica suportada por alguns sistemas de arquivo a criao de identicadores genricos que podem ser atribudos a um ou mais usurios. Em seguida, o sistema de arquivo deve ser capaz de manter listas de aes permitidas (ou proibidas) em cada arquivo. As aes mais comuns so:

Acessar (ler) o arquivo Gravar (escrever no) arquivo Executar o arquivo
Vrios sistemas de arquivo talvez extendam a lista para incluir outras aes como excluso (deleo), ou at mesmo a habilidade de alterar opes no controle de acesso de um arquivo. 5.5.2.5. Contabilidade do Espao Utilizado Uma constante na vida de um administrador de sistemas que nunca h espao livre suciente e, se houver, no permanecer assim por muito tempo. Sendo assim, um administrador de sistemas deve pelo menos determinar facilmente o nvel de espao livre disponvel para cada sistema de arquivo. Alm disso, os sistemas de arquivo com capacidades de identicao de usurios bem denidas, geralmente incluem a capacidade de exibir a quantidade de espao consumido por um determinado usurio. Esta funcionalidade vital em ambientes grandes de multi-usurios, j que infelizmente a regra 80/20 geralmente se aplica ao espao em disco 20 porcento de seus usurios sero responsveis por consumir 80 porcento do seu espao disponvel em disco. Ao determinar quais usurios esto nestes 20 porcento, ca mais fcil administrar seus bens de armazenamento efetivamente. Levando isso mais adiante, alguns sistemas de arquivo incluem a habilidade de determinar limites por usurio (geralmente conhecidos como quotas de disco) sobre a quantidade de espao em disco que pode ser consumida. As especicaes podem variar em diferentes sistemas de arquivo, mas em geral possvel atribuir a cada usurio uma determinada quantidade de armazenamento. Alm disso,
74
vrios sistemas de arquivo diferem. Alguns permitem ao usurio exceder seu limite somente uma vez, enquanto outros implementam um "perodo de carncia", durante o qual um segundo limite aplicado.
5.5.3. Estrutura de Diretrio

Muitos administradores de sistemas no se importam como o armazenamento disponibilizado hoje ser usado pelos seus usurios amanh. No entanto, um pouco de foco nesta questo, antes de disponibilizar o armazenamento para os usurios, pode poupar bastante esforo desnecessrio no futuro. A principal coisa que o administrador deve fazer usar os diretrios e sub-diretrios para estruturar o armazenamento disponvel de maneira inteligvel. H diversos benefcios nesta ttica:

Mais fcilmente entendido Mais exibilidade no futuro
Ao forar um certo nvel de estrutura no seu armazenamento, este pode ser mais facilmente entendido. Por exemplo: considere um grande sistema de multi-usurios. Ao invs de inserir todos os diretrios dos usurios em um diretrio grande, pode fazer mais sentido usar sub-diretrios que espelham a estrutura de sua empresa. Dessa maneira, as pessoas que trabalham na contabilidade tm seus diretrios sob um outro diretrio chamado contabilidade, as pessoas que trabalham na engenharia teriam seus diretrios sob engenharia e assim por diante. O benefcio dessa ttica a facilidade de manter o registro dirio de necessidades (e uso) do armazenamento de cada parte da sua empresa. Obter uma lista de arquivos usados por todos os funcionrios dos recursos humanos simples. Fazer o backup de todos os arquivos usados pelo departamento jurdico fcil. Com a estrutura apropriada, a exibilidade aumenta. Continuando o exemplo anterior, assuma por um momento que o departamento de engenharia est prestes a assumir novos projetos grandes. Por causa disso, muitos novos engenheiros sero contratados em breve. Entretanto, no momento no h armazenamento livre disponvel para suportar as adies esperadas engenharia.
engenharia, ser um processo simples para:

Mas, como todas as pessoas da engenharia tm seus arquivos armazenados sob o diretrio Adquirir o armazenamento adicional necessrio para suportar a engenharia Fazer backup de tudo sob o diretrio engenharia Restaurar o backup para o novo armazenamento Renomear o diretrio engenharia no armazenamento original para algo como engenharia-arquivo (antes de apag-lo inteiramente e aps trabalhar sem problemas com a
nova congurao por um ms)
Fazer as alteraes necessrias para que todo o pessoal de engenharia possa acessar seus arquivos no novo armazenamento
Obviamente, essa ttica tambm tem suas desvantagens. Por exemplo: se as pessoas mudam de departamentos com frequncia, voc deve ter uma maneira de manter-se informado sobre estas transferncias e ento modicar a estrutura de diretrio de acordo. Caso contrrio, a estrutura no mais reetir a realidade, aumentando o seu trabalho e no diminuindo-o a longo prazo.
5.5.4. Habilitando Acesso ao Armazenamento

Uma vez que o dispositivo de armazenamento em massa foi particionado apropriadamente, e um sistema de arquivo foi gravado no mesmo, o armazenamento est disponvel para o uso geral.
75
Isto verdade para alguns sistemas operacionais. Desde que o mesmo detecte o novo dispositivo de armazenamento em massa, pode ser formatado pelo administrador de sistemas e ser acessado imediatamente sem nenhum esforo adicional. Outros sistemas operacionais requerem um passo adicional. Este passo frequentemente chamado de montagem direciona o sistema operacional em como acessar o armazenamento. A montagem normal do armazenamento feita atravs de um utilitrio ou programa especial e requer que o dispositivo de aremazenamento em massa (e possivelmente a partio tambm) seja explicitamente identicada.
5.6. Tecnologias de Armazenamento Avanado

Apesar de tudo ser apresentado neste captulo referenciando somente discos rgidos simples diretamente ligados a um sistema, h outras opes mais avanadas que voc pode explorar. A sees seguintes descrevem algumas das tticas mais comuns para expandir as opes de seu armazenamento em massa.
5.6.1. Armazenamento Acessvel via Rede

Combinar as tecnologias de rede com o armazenamento em massa pode resultar em grande exibilidade para administradores de sistemas. H dois benefcios atingveis com esse tipo de congurao:

Consolidao do armazenamento Administrao simplicada
O armazenamento pode ser consolidado ao empregar servidores de alto desempenho com conectividade de rede de alta velocidade e congurados com grandes quantidades de armazenamento rpido. Com uma congurao apropriada, possvel prover acesso ao armazenamento a velocidades comparveis com o armazenamento local. Sendo assim, a natureza compartilhada de tal congurao frequentemente possibilita reduzir custos, j que os gastos de um armazenamento compartilhado centralizado podem ser menores que os gastos do armazenamento equivalente para cada um dos clientes. Alm disso, o espao livre consolidado, ao invs de estar espalhado (e no amplamente utilizvel) pelos diversos clientes. Os servidores de armazenamento centralizado tambm podem facilitar muitas tarefas administrativas. Por exemplo: monitorar o espao livre bem mais fcil quando o armazenamento a ser monitorado existe num servidor de armazenamento centralizado. Os backups podem ser bastante simplicados usando um servidor de armazenamento centralizado. possvel efetuar backups da rede para clientes mltiplos, mas requerem mais trabalho para congurar e manter. H diversas tecnologias de armazenamento em rede disponveis; escolher uma pode ser uma tarefa difcil. Quase todos os sistemas operacionais do mercado de hoje incluem alguns meios de acessar o armazenamento acessvel pela rede, mas as diferentes tecnologias no so compatveis umas com as outras. Qual a melhor ttica para determinar a tecnologia a empregar? A ttica que geralmente traz os melhores resultados deixar as capacidades embutidas do cliente decidirem a questo. H inmeras razes para isso:

Problemas minimizados com a integrao de clientes Trabalho minimizado em cada sistema cliente Baixo custo inicial por cliente
Tenha em mente que todas as questes relativas aos clientes so multiplicadas pelo nmero de clientes de sua empresa. Ao utilizar as capacidades embutidas dos clientes, voc no precisa instalar nenhum software adicional em cada cliente (custo adicional zero com a compra de software). E voc tambm tem a melhor chance de obter um bom suporte e integrao com o sistema operacional do cliente.
76
No entanto, h uma desvantagem. Isso signica que o ambiente de servidor deve estar apto a prover um bom suporte para as tecnologias de armazenamento acessveis pela rede requisitadas pelos clientes. Nos casos em que os sistemas operacionais do servidor e dos clientes so um e o mesmo, normalmente no h prolemas. Caso contrrio, ser necessrio investir tempo e trabalho em fazer com que o servidor "fale" a linguagem dos clientes. Entretranto, essa desvantagem geralmente justicvel.
5.6.2. Armazenamento Baseado no RAID

Uma habilidade a ser cultivada pelo administrador de sistemas poder olhar para conguraes de sistemas complexos e observar as decincias inerentes de cada congurao. Apesar de, primeira vista, este parecer um ponto de vista negativo, pode ser uma grande maneira de analisar alm das caixas brilhantes e visualizar uma noite de sbado com toda a produo derrubada devido uma falha que poderia ser facilmente evitada com um pouco de precauo. Com isso em mente, vamos usar o que sabemos agora sobre o armazenamento baseado no disco e vericar se podemos determinar as maneiras como os drives de disco podem causar problemas. Primeiro, considere uma falha completa no hardware: Um drive de disco com quatro parties tem uma pane geral: o que acontece com os dados contidos nestas parties? Ficam imediatamente indisponveis (pelo menos at que a unidade falha possa ser substituda e os dados recuperados de um backup recente). Um drive de disco com uma nica partio est operando em seus limites devido a enormes cargas I/O: o que acontece com as aplicaes que requerem acesso aos dados dessa partio? As aplicaes cam lentas pois o drive de disco no pode processar os acessos e gravaes mais rapidamente. Voc tem um grande arquivo de dados aumentando de tamanho lentamente; em breve, ser maior que o maior drive de disco no seu sistema. O que acontece ento? O drive de disco totalmente preenchido, o arquivo de dados para de aumentar e suas aplicaes associadas param de rodar. Apenas um destes problemas poderia incapacitar um centro de dados, mesmo assim os administradores precisam enfrentar esse tipo de situao todos os dias. O que pode ser feito? Felizmente, h uma tecnologia que pode resolver cada uma destas questes. O nome dessa tecnologia RAID. 5.6.2.1. Conceitos Bsicos RAID um acrnimo para Redundant Array of Independent Disks (Conjunto Redundante de Discos Independentes)8 . Como o nome implica, RAID uma maneira para que drives mltiplos de disco atuem como se fossem um nico drive de disco. As tcnicas RAID foram primeiramente desenvolvidas por pesquisadores da Universidade de Berkeley, Califrnia, em meados dos anos 80. Ao mesmo tempo, havia uma diferena maior de preo entre os drives de disco de alto desempenho usados em grandes instalaes de computadores da poca, e drives de disco menores e mais lentos usados nos idos da indstria da computao. O RAID era visto como um mtodo de substituir uma unidade de drive de disco cara por diversos drives de disco mais baratos.
8. No incio das pesquisas sobre o RAID, o acrnimo signicava Redundant Array of Inexpensive Disks (Discos Baratos), mas ao longo do tempo, os discos "independentes" que o RAID pretendia suplantar tornaram-se cada vez mais baratos, assim perdendo o signicado da comparao de preos.
77
Ainda mais importante: os conjuntos RAID podem ser construdos de diversas maneiras, resultando em caractersticas diferentes dependendo da congurao nal. Vamos observar as diferentes conguraes (conhecidos como nveis do RAID) com mais detalhes. 5.6.2.1.1. Nveis do RAID Os pesquisadores de Berkeley originalmente deniram cinco nveis diferentes do RAID e os numeraram de "1" a "5." Alm disso, nveis adicionais do RAID foram denidos por outros pesquisadores e membros da indstria de armazenamento. Nem todos os nveis do RAID eram igualmente teis; alguns interessavam somente aos propsitos dos pesquisadores, enquanto outros no eram economicamente viveis. No nal, apenas trs nveis do RAID foram adotados para o uso geral:

Nvel 0 Nvel 1 Nvel 5
As sees seguintes abordam cada um destes nveis em detalhes. 5.6.2.1.1.1. RAID 0 A congurao de disco conhecida como RAID nvel 0 um pouco confusa, j que o nico nvel do RAID que no emprega nenhuma redundncia. No entanto, mesmo que o RAID 0 no tenha vantagens sob o aspecto de conabilidade, possui outros benefcios. Um conjunto RAID 0 consiste de dois ou mais drives de disco. A capacidade de armazenamento de cada drive dividida em pedaos, que representam alguns mltiplos do tamanho de bloco nativo do drive. Os dados so gravados, pedao por pedao, em cada drive do conjunto. Os pedaos podem ser encarados como tiras (stripes, em ingls) ao longo de cada drive do conjunto; da vem o outro termo para o RAID 0: striping. Por exemplo: com um conjunto de dois drives e pedaos com 4KB de tamanho, gravar 12KB de dados no conjunto resultaria na gravao de trs pedaos de 4KB nos seguintes drives:

Os primeiros 4KB seriam gravados no primeiro pedao do primeiro drive Os 4KB seguintes seriam gravados no primeiro pedao do segundo drive Os ltimos 4KB seriam gravados no segundo pedao do primeiro drive
Comparado a um drive de disco nico, as vantagens do RAID 0 incluem:

Maior tamanho total os conjuntos de RAID 0 podem ser construdos para serem maiores que um drive de disco nico, facilitando armazenar maiores arquivos de dados Melhor desempenho de acesso/gravao A carga I/O num conjunto RAID 0 espalhada igualmente por todos os drives do conjunto (assuimndo que todas I/O no estejam concentradas num nico pedao) Sem espao desperdiado Todo o armazenamento de todos os drives do conjunto esto disponveis para o armazenamento de dados
Comparado a um drive de disco nico, o RAID 0 tem a seguinte desvantagem:
Menos conabilidade Todo drive de um conjunto de RAID 0 deve estar operante para o conjunto estar disponvel. Uma nica falha no conjunto RAID 0 drive-N resulta na remoo de 1/N de todos os dados, inutilizando o conjunto
78
Dica Se voc tiver problemas em memorizar os diferentes nveis do RAID, lembre-se apenas que o RAID 0 tem zero porcento de redundncia.
5.6.2.1.1.2. RAID 1 O RAID 1 usa dois (apesar de algumas implementaes suportarem mais) drives de disco idnticos. Todos os dados so gravados nos dois drives, tornando-os imagem espelho um do outro. Por isso, o RAID 1 comumente conhecido como mirroring. Sempre que os dados so gravados num conjunto de RAID 1, ocorrem duas gravaes fsicas: uma no primeiro drive e outra no segundo drive. Por outro lado, o acesso aos dados precisa ocorrer somente uma vez em qualquer drive do conjunto. Comparado a um drive de disco nico, o conjunto de RAID 1 tem as seguintes vantagens:

Melhor redundncia Mesmo se um drive do conjunto falhar, os dados ainda estaro acessveis Melhor desempenho de acesso Com ambos drives operantes, os acessos podem ser divididos igualmente entre eles, reduzindo as cargas I/O por drive
Quando comparado a um drive de disco nico, o conjunto de RAID 1 tem algumas desvantagens:

O tamanho mximo do conjunto limitado pelo maior drive disponvel. Desempenho de gravao reduzido Como os dois drives devem ser mantidos atualizados, todas as I/Os devem ser desempenhadas pelos dois drives, atrasando o processo geral de gravao de dados no conjunto Relao custo/ecincia reduzida Com um drive inteiro dedicado redundncia, o custo de um conjunto de RAID 1 , no mnimo, o dobro de um nico drive
Dica Se voc tiver problemas em memorizar os diferentes nveis do RAID, lembre-se que o RAID 1 tem cem porcento de redundncia.
5.6.2.1.1.3. RAID 5 O RAID 5 tenta combinar os benefcios do RAID 0 e do RAID 1 e minimizar suas respectivas desvantagens. Como o RAID 0, um conjunto de RAID 5 consiste de drives de discos mltiplos, cada um dividido em pedaos. Isso permite ao conjunto de RAID 5 ser maior que qualquer disco separadamente. Assim como um conjunto de RAID 1, um conjunto de RAID 5 usa parte do espao do disco de maneira redundante, aumentando a conabilidade. Entretanto, o modo de operao do RAID 5 diferente do RAID 0 e do RAID 1. Um conjunto de RAID 5 deve consistir de, no mnimo, trs drives de disco de tamanho idntico (talvez mais drives sejam usados). Cada drive dividido em pedaos e os dados so gravados nos pedaos em ordem. No entanto, nem todo pedao dedicado ao armazenamento de dados como no RAID 0. Ao invs disso, num conjunto com n drives de disco, todo pedao de nmero n dedicado paridade.
79
Os pedaos contendo paridade possibilitam recuperar dados caso um dos drives do conjunto falhe. A paridade no pedao x calculada combinando matematicamente os dados de cada pedao x armazenado em todos os drives do conjunto. Se os dados de um pedao so atualizados, o pedao de paridade correspondente deve ser recalculado e atualizado tambm. Isso tambm signica que, cada vez que os dados so gravados no conjunto, pelo menos dois drives so gravados: o drive contendo os dados e o drive contendo o pedao de paridade. Uma coisa importante para ter em mente que os pedaos de paridade no esto concentrados em nenhum drive do conjunto, mas esto espalhados igualmente por todos os drives. Apesar de ser possvel dedicar um drive especco para conter apenas paridade (de fato, esta congurao conhecida como RAID nvel 4), a atualizao constante da paridade conforme os dados so gravados no conjunto pode transformar o drive de paridade num gargalo de desempenho. Ao espalhar as informaes de paridade igualmente pelo conjunto, este impacto reduzido. No entanto, importante ter em mente o impacto da paridade na capacidade de armazenamento total do conjunto. Mesmo que as informaes de paridade sejam espalhadas igualmente por todos os drives do conjunto, a quantidade de armazenamento disponvel reduzida para o tamanho de um drive. Comparado a um drive de disco nico, o conjunto de RAID 5 tem as seguintes vantagens:

Mais redundncia Se um drive do conjunto falhar, as informaes de paridade podem ser usadas para reconstruir os pedaos de dados faltando, enquanto mantm-se o conjunto disponvel para uso 9 Melhor desempenho de acesso Devido sua semelhana com o RAID 0, os dados so divididos entre os drives do conjunto e a atividade de acesso I/O espalhada igualmente por todos os drives Relao custo/ecincia razoavelmente boa Em um conjunto de RAID 5 com n drives, somente 1/n do armazenamento total dedicado redundncia.
Comparado a um drive nico, um conjunto de RAID 5 tem a seguinte desvantagem:
Desempenho de gravao reduzido Como cada gravao no conjunto resulta em pelo menos duas gravaes nos drives fsicos (uma gravao para os dados e outra para a paridade), o desempenho de gravao pior do que num drive nico10
5.6.2.1.1.4. Nveis Embutidos do RAID A partir da abordagem dos vrios nveis do RAID, ca claro que cada nvel tem suas prprias vantagens e desvantagens. Pouco tempo depois que o armazenamento baseado no RAID comeou a ser usado, as pessoas comearam a pensar em combinar os diferentes nveis do RAID, produzindo conjuntos com todas as vantagens e nenhuma desvantagem dos nveis originais. Por exemplo: e se os drives de disco de um conjunto de RAID 0 fossem, na verdade, conjuntos de RAID 1? Isso traria as vantagens de velocidade do RAID 0, com a conabilidade do RAID 1. Esse o tipo de coisa que pode ser feita. Aqui esto os nveis embutidos de RAID mais comuns:

RAID 1+0 RAID 5+0 RAID 5+1

O desempenho I/O reduzido enquanto operar com um drive indisponvel, devido sobrecarga envolvida na
9.
reconstruo dos dados faltantes. 10. Tambm h impacto dos clculos de paridade necessrios para cada gravao. Mas, dependendo da implementao especca do RAID 5 (especialmente, em que localidade do sistema os clculos de paridade ocorrem), este impacto pode variar de um tamanho considervel a quase inexistente.
80
Como o RAID embutido usado em ambientes mais especializados, no abordaremos muitos detalhes aqui. No entanto, h dois pontos para ter em mente quando se tratar de RAIDs embutidos:

A ordem importa A ordem na qual os nveis do RAID so embutidos pode ter um grande impacto na conabilidade. Em outras palavras, o RAID 1+0 e o RAID 0+1 no so o mesmo. Os custos podem ser altos Se h alguma desvantagem comum a todas as implementaes embutidas de RAID, essa o custo. Por exemplo: o menor conjunto de RAID 5+1 consiste de seis drives de disco (so necessrios ainda mais drives para conjuntos maiores).
Agora que explicamos os conceitos por trs do RAID, vejamos como pode ser implementado.
5.6.2.1.2. Implementaes do RAID Em comparao com as sees anteriores, bvio que o RAID requer mais "conhecimento" que o processamento I/O de disco comum para drives individuais. No mnimo, as seguintes tarefas devem ser executadas:

Dividir os pedidos I/O de entrada entre os discos do conjunto Para o RAID 5, calcular a paridade e grav-la no drive apropriado no conjunto Monitorar os discos separadamente no conjunto e tomar as devidas aes caso um deles falhar Controlar a recriao de um disco separado no conjunto, quando este disco for substitudo ou reparado Prover uma maneira para os administradores manterem o conjunto (remover ou adicionar drives, iniciar e terminar recriaes, etc.)
H dois mtodos principais que podem ser usados para completar estas tarefas. As prximas duas sees descrevem-nos em detalhes. 5.6.2.1.2.1. RAID de Hardware Uma implementao de RAID de hardware geralmente toma a forma de uma placa especializada de controle do disco. A placa executa todas as funes relativas ao RAID e controla diretamente os drives separadamente nos conjuntos conectados a esta. Com o driver apropriado, os conjuntos administrados por uma placa de RAID de hardware aparecem como drives de disco comuns para o sistema operacional da mquina. A maioria das placas de controlador de RAID funcionam com drives SCSI, mas h tambm controladores RAID baseados na ATA. Em qualquer caso, a interface administrativa geralmente implementada de uma destas trs maneiras:

Utilitrios especializados, que rodam como aplicaes sob o sistema operacional da mquina, apresentando uma interface de software placa do controlador Uma interface da placa usando uma porta serial, que acessada atravs de um emulador de terminal Uma interface parecida com o BIOS, acessvel somente durante o teste de inicializao do sistema
Alguns controladores RAID tm mais de um tipo de interface administrativa. Por motivos bvios, uma interface de software provm mais exibilidade, j que permite funes administrativas enquanto o sistema operacional est rodando. No entanto, se voc inicializar um sistema operacional a partir de um controlador RAID, necessria uma interface que no requer um sistema operacional rodando. Como h diversas placas de controlador RAID diferentes no mercado, impossvel entrar em mais detalhes aqui. O melhor a fazer ler a documentao do fabricante para mais informaes.
Captulo 5. Administrando o Armazenamento 5.6.2.1.2.2. RAID de Software
81
O RAID de software o RAID implementado como um kernel - ou software de nvel de driver para um sistema operacional especco. Como tal, provm mais exibilidade em termos de suporte a hardware desde que o hardware seja suportado pelo sistema operacional, os conjuntos RAID podem ser congurados e empregados. Isto pode reduzir o custo de emprego do RAID drasticamente, eliminando a necessidade de hardware caro especializado de RAID. Frequentemente, o excesso de energia da CPU disponvel para os clculos de paridade do RAID de software excede o poder de processamento presente numa placa de controlador RAID. Consequentemente, algumas implementaes de RAID de software tm, na verdade, a capacidade de desempenho superior que implementaes de RAID de hardware. Entretanto, o RAID de software tem limitaes ausentes do RAID de hardware. A mais importante a considerar o suporte para inicializar a partir de um conjunto de RAID de software. Na maioria dos casos, somente os conjuntos RAID 1 podem ser usados para inicializao, j que o BIOS do computador no sabe do RAID. Como um drive nico de um conjunto de RAID 1 indiferencivel de um dispositivo de inicializao no-RAID, o BIOS pode iniciar o processo de inicializao; ento, o sistema operacional pode alternar para a operao de RAID de software quando obtiver o controle do sistema.
5.6.3. Administrao de Volume Lgico (Logical Volume Management)

Uma outra tecnologia avanada de armazenamento a administrao de volume lgico (logical volume management - LVM). O LVM possibilita tratar dispositivos fsicos de armazenamento em massa como blocos de construo de nvel baixo, nos quais so criadas conguraes de armazenamento diferentes. As capacidades exatas variam de acordo com a implementao especca, mas podem incluir agrupamento de armazenamento fsico, redimensionamento de volume lgico e migrao de dados. 5.6.3.1. Agrupamento de Armazenamento Fsico Apesar do nome dado a esta capacidade variar, o agrupamento de armazenamento fsico a base de todas as implementaes do LVM. Como o nome implica, os dispositivos fsicos de armazenamento em massa podem ser agrupados de maneira a criar um ou mais dipositivos lgicos de armazenamento em massa. Os dispositivos lgicos de armazenamento em massa (ou volumes lgicos) podem ter capacidade maior que a maior capacidade de qualquer um dos dispositivos fsicos de armazenamento em massa que compe o volume. Por exemplo: dados dois drives de 100GB, pode-se criar um volume lgico de 200GB. No entanto, tambm pode-se criar um volume lgico de 150GB e um de 50GB. Qualquer combinao de volumes lgicos igual ou menor que a capacidade total (200GB nestes exemplo) possvel. As alternativas so limitadas apenas pelas necessidades da sua empresa. Isso possibilita a um administrador de sistemas tratar todo o armazenamento como parte de um conjunto, disponvel para uso em qualquer quantidade. Alm disso, os drives podem ser adicionados posteriormente ao conjunto, facilitando o processo de antecipar a demanda de armazenamento de seus usurios. 5.6.3.2. Redimensionamento do Volume Lgico A caracterstica do LVM admirada pela maioria dos administradores de sistemas sua habilidade em direcionar armazenamento facilmente onde necessrio. Numa congurao de sistema sem LVM, estar sem espao signica no melhor dos casos mover arquivos do dispositivo cheio para outro
82
com espao disponvel. Isto pode signicar recongurar os dispositivos de armazenamento em massa de seu sistema; uma tarefa a ser executada aps o horrio comercial. Entretanto, o LVM possibilita aumentar o tamanho de um volume lgico. Assuma por um momento que nosso conjunto de armazenamento de 200GB foi usado para criar um volume lgico de 150GB, com os 50GB restantes na reserva. Se o volume lgico de 150GB car cheio, o LVM possibilita aumentar esse tamanho (digamos em 10GB) sem nenhuma recongurao fsica. Dependendo do ambiente do sistema operacional, pode ser possvel fazer isso dinamicamente ou pode ser necessrio deixar o sistema fora do ar por pouco tempo para executar o redimensionamento. 5.6.3.3. Migrao de Dados A maioria dos administradores de sistemas experientes cariam impressionados com as capacidades do LVM, mas tambm se perguntaria a seguinte questo: O que acontece se um dos drives que compe o volume lgico comea a falhar? A boa notcia que a maioria das implementaes do LVM incluem a habilidade de migrar dados de um drive fsico especco. Para que isso funcione, deve haver capacidade reserva suciente para absorver a perda do drive falho. Uma vez completa a migrao dos dados, o drive falho pode ser substitudo ou trazido de volta ao conjunto de armazenamento disponvel. 5.6.3.4. Com LVM, por que usar RAID? Dado que o LVM tem algumas funcionalidades similares s do RAID (a habilidade de substituir drives falhos dinamicamente, por exemplo), e algumas funcionalidades provendo capacidades que no podem ser atingidas pelas maioria das implementaes do RAID (como a habilidade de adicionar armazenamento dinamicamente a um conjunto de armazenamento central), muitas pessoas questionam se o RAID ainda importante. Nada poderia estar mais distante da verdade. RAID e LVM so tecnologias complementares que podem ser usadas em conjunto (similar ao uso dos nveis embutidos do RAID), possibilitando obter o melhor de cada uma.
5.7. Administrao Diria do Armazenamento

Os administradores de sistemas devem estar atentos ao armazenamento no curso de suas rotinas dirias. H diversas questes para ter em mente:

Monitorar espao livre Questes de quota de disco Questes relativas a arquivos Questes relativas a diretrios Questes relativas a backups Questes relativas a desempenho Adicionando/removendo armazenamento
As sees seguintes abordam cada uma destas questes com detalhes.
83
5.7.1. Monitorando Espao Livre

Garantir que haja suciente espao livre disponvel deve estar no topo da lista de tarefas dirias de um administrador de sistemas. A razo da vericao frequente e regular do espao livre to importante porque o espao livre muito dinmico; pode haver mais do que o espao suciente num momento, e praticamente nenhum em seguida. Em geral, h trs razes para espao livre insuciente:

Uso excessivo por um usurio Uso excessivo por uma aplicao Crescimento normal de uso
Estas razes so abordadas em detalhes nas prximas sees. 5.7.1.1. Uso Excessivo por um Usurio Pessoas diferentes tm nveis diferentes de organizao. Algumas pessoas cariam aterrorizadas em ver um pouco de p sobre uma mesa, enquanto outras no pensariam duas vezes em ter uma pilha de caixas de pizza do ano passado ao lado do sof. O mesmo ocorre com o armazenamento:

Algumas pessoas so muito frugais no uso de seu armazenamento e nunca largam arquivos desnecessrios por a. Algumas pessoas parecem nunca encontrar tempo para livrar-se dos arquivos de que no mais precisam.
Muitas vezes, quando um usurio usa grandes quantidades de armazenamento, o segundo tipo de pessoa a responsvel. 5.7.1.1.1. Resolvendo o Uso Excessivo por um Usurio Essa uma rea na qual o administrador de sistemas precisa usar toda a diplomacia e habilidades sociais que puder obter. Frequentemente, as discusses sobre espao em disco tornam-se emocionais, j que as pessoas encaram as restries de uso do disco como um fator limitante para seu trabalho, dizem que as restries so pequenas ou que simplesmente no tm tempo de fazer uma limpeza em seus arquivos. Os melhores administradores de sistemas consideram muitos fatores numa situao como essa. As restries so razoveis e justas para o tipo de trabalho que essa pessoa executa? Essa pessoa parece usar seu espao em disco apropriadamente? Voc pode ajud-la a reduzir o uso do disco de alguma maneira (criando um CD-ROM com backup de todos os e-mails com mais de um ano, por exemplo)? O seu trabalho durante as conversas tentar descobrir se este realmente o caso, enquanto garante que algum que no precisa de tanto espao esteja limpando seus arquivos. Em qualquer dos casos, a melhor coisa a fazer manter uma conversa em nvel prossional e factual. Tente resolver os problemas do usurio de uma maneira educada ("Eu entendo que voc esteja muito ocupado, mas todos em seu departamento tm a mesma responsabilidade em no desperdiar espao de armazenamento, e a mdia de uso menos que a metade do seu.") enquanto encaminha a conversa para a questo. Certique-se de oferecer ajuda caso a falta de conhecimento/experincia for um problema. Lidar com a situao de maneira sensvel porm rme, geralmente melhor que usar sua autoridade como administrador de sistemas para forar um resultado. Por exemplo: talvez voc acredite ser necessria uma concesso entre voc e o usurio. Essa concesso pode ter uma destas trs formas:

Prover espao temporrio Criar backups de arquivamento
84 Desistir
Talvez voc acredite que o usurio possa reduzir seu uso se tiver alguma quantidade de espao temporrio que possa usar sem restries. As pessoas que geralmente se aproveitam desta situao descobrem que possvel trabalhar sem se preocupar com espao at atingirem um ponto nal lgico, quando podem fazer uma limpeza e determinar quais arquivos do armazenamento temporrio so realmente necessrios.
Ateno Se voc oferecer esta opo a um usurio, no permita que esse espao temporrio torne-se permanente. Deixe bem claro que o espao oferecido temporrio e que no h possibilidade de garantir datas de reteno dos arquivos; backups de dados em espao temporrio nunca so feitos. Na verdade, muitos administradores de sistemas frequentemente enfatizam esse fato apagando automaticamente todos os arquivos em armazenamento temporrio com mais de uma determinada idade (uma semana, por exemplo).
Em outros casos, o usurio pode ter muitos arquivos obviamente antigos que provavelmente no precisa acessar continuamente. Garanta de comunicar essa questo se for o caso. s vezes, alguns usurios so responsveis por manter um arquivo com dados antigos; nestes casos, voc deve ajud-los nessa tarefa provendo diversos backups tratados de maneira diferente que os backups de arquivamento de seu centro de dados. Entretanto, h situaes nas quais os dados tm valor dbio. Nestes casos, talvez voc ache melhor oferecer a produo de um backup especial para eles. Ento, voc faz o backup dos dados antigos e entrega a mdia de backup ao usurio, explicando que ele responsvel por mant-la segura e que, se precisar acessar quaisquer dados, pea a voc (ou aos funcionrios de operaes o que for melhor para a empresa) para recuper-los. H algumas coisas para manter em mente para que a situao no se oponha a voc. Primeiro e mais importante: no inclua arquivos que provavelmente precisaro de recuperao; no selecione arquivos muito novos. Em seguida, certique-se da capacidade de executar uma recuperao caso seja necessria algum dia. Isso signica que a mdia de backup deve ser de um tipo a ser usado pelo seu centro de dados no futuro.
Dica Sua escolha da mdia de backup tambm deve considerar as tecnologias que possibilitam aos prprios usurios executar a recuperao dos dados. Por exemplo: mesmo que fazer o backup de muitos gigabytes em um CD-ROM seja mais trabalhoso que invocar um simples comando e envilos a um cartucho de lta de 20GB, considere que o usurio pode acessar os dados do CD-ROM quando quiser sem precisar do seu envolvimento.
5.7.1.2. Uso Excessivo por uma Aplicao s vezes, uma aplicao responsvel por uso excessivo. As razes podem variar, mas podem incluir:

Melhorias na funcionalidade da aplicao requerem mais armazenamento Um aumento do nmero de usurios que usam a aplicao A aplicao falha em fazer a limpeza aps terminada, deixando arquivos temporrios desnecessrios no disco
85
A aplicao est com cdigo quebrado e o erro faz com que esta use mais armazenamento do que deveria
Sua tarefa determinar quais dos motivos dessa lista se aplicam sua situao. Estar ciente do status das aplicaes usadas em seu centro de dados deve ajud-lo a eliminar diversos motivos, assim como deve acontecer com a cincia dos hbitos de processamento de seus usurios. O que resta a fazer frequentemente um pouco de trabalho de detetive para descobrir para onde foi o armazenamento. Isso deve reduzir substancialmente o campo. Neste ponto, voc deve tomar as aes apropriadas, seja adicionar armazenamento para suportar uma aplicao de uso crescente, contatar os desenvolvedores da aplicao para debater sobre suas caractersticas de processamento, ou escrever scripts para efetuar a limpeza aps a aplicao. 5.7.1.3. Crescimento Normal do Uso A maioria das empresas vivencia algum nvel de crescimento ao longo do tempo. Por causa disso, normal esperar que a utilizao do armazenamento aumente numa velocidade similar. Em praticamente todas as circunstncias, o monitoramento constante pode revelar a taxa mdia da utilizao do armazenamento em sua empresa; essa taxa pode ento ser usada para determinar o tempo no qual o armazenamento adicional deve ser adquirido antes que seu espao livre acabe. Se acontecer de acabar seu espao livre inesperadamente devido o crescimento normal, voc no fez seu trabalho corretamente. No entanto, podem ocorrer grandes demandas adicionais ao armazenamento de seus sistemas inesperadamente. Sua empresa pode ter sido unida com outra, requerendo alteraes rpidas na infra-estrutura de TI (e, portanto, no armazenamento). Um novo projeto de alta prioridade pode ter surgido durante a noite. As alteraes numa aplicao existente podem resultar em necessidades de armazenamento bem maiores. No importa o motivo; s vezes voc pego de surpresa. A m de planejar para estes imprevistos, tente congurar sua arquitetura de armazenamento para a mxima exibilidade. Manter armazenamento reserva (se possvel) pode aliviar o impacto destes eventos no-planejados.
5.7.2. Questes de Quota de Disco

Muitas vezes, a primeira coisa que a maioria das pessoas pensa ao analisar as quotas de disco uslas para forar os usurios a manterem seus diretrios limpos. Enquanto h situaes nas quais isso funciona, tambm ajuda a observar o problema de uso do espao em disco sob outra perspectiva. E as aplicaes que, por algum motivo, consomem muito espao em disco? sabido que algumas aplicaes falham de modo a consumirem todo o espao disponvel em disco. Nestes casos, as quotas de disco podem limitar o estrago causado por estas aplicaes, forando-as a parar antes de acabar todo o espao livre no disco. A parte mais difcil da implementao e administrao das quotas de disco refere-se aos prprios limites. Quais devem ser os limites? Uma ttica simplista seria dividir o espao em disco pelo nmero de usurios e/ou grupos utilizando-o, e xar o valor resultante como a quota por usurio. Por exemplo: se o sistema tem um drive de disco de 100GB e 20 usurios, cada usurio deve receber uma quota de disco de, no mximo, 5GB. Dessa maneira, cada usurio teria a garantia de 5GB (apesar do disco estar 100% cheio neste ponto). Para os sistemas operacionais que as suportam, possvel determinar quotas temporrias um pouco mais altas digamos 7,5GB, com a quota permanente ainda em 5GB. O benefcio permitir que os usurios consumam permanentemente no mais que suas porcentagens do disco, mas ainda permitindo alguma exibilidade quando um usurio atingir (e exceder) seu limite. Ao utilizar quotas de disco dessa maneira, voc est super-comprometendo o espao disponvel em disco. A quota temporria
86
7,5GB. Se todos os usurios excederem suas quotas permanentes ao mesmo tempo e tentarem atingir suas quotas temporrias, aquele disco de 100GB teria que ter 150GB. No entanto, nem todos excedem suas quotas permanentes ao mesmo tempo, possibilitando a ttica de algum super-comprometimento. Obviamente, a seleo de quotas permanentes e temporrias cabe ao administrador de sistemas, j que cada operao e comunidade de usurios so diferentes.
5.7.3. Questes Relativas a Arquivos

Os administradores de sistemas frequentemente lidam com questes relativas a arquivos. Estas questes incluem:

Acesso a Arquivos Compartilhamento de Arquivos
5.7.3.1. Acesso a Arquivos As questes relacionadas ao acesso de arquivos tipicamente ocorrem em um cenrio um usurio no consegue acessar um arquivo que acredita poder acessar. Frequentemente, o caso do usurio 1 querendo enviar uma cpia de um arquivo ao usurio 2. Na maioria das empresas, a habilidade de um usurio acessar os arquivos de outro estritamente limitada, acarretando neste problema. H trs tticas que podem ser usadas:

O usurio 1 efetua as alteraes necessrias para permitir ao usurio 2 acessar o arquivo onde quer que esteja localizado. Cria-se uma rea de intercmbio de arquivos para esse propsito; o usurio 1 copia o arquivo ali, que ento pode ser copiado pelo usurio 2. O usurio 1 usa o e-mail para enviar uma cpia do arquivo ao usurio 2.
H um problema com a primeira ttica dependendo de como o acesso atribudo, o usurio 2 pode ter acesso total a todos os arquivos do usurio 1. Pior: pode ser feito de maneira a permitir que todos os usurios de sua empresa acessem os arquivos do usurio 1. Pior ainda: esta alterao pode no ser revertida aps o usurio 2 no querer mais o acesso, deixando os arquivos do usurio 1 permanentemente acessveis aos outros. Infelizmente, quandos os usurios se encontram nestas situaes, a segurana raramente sua prioridade mais alta. A segunda ttica elimina o problema de tornar todos os arquivos do usurio 1 acessveis aos outros. Entretanto, uma vez que o arquivo encontra-se na rea de intercmbio, este legvel (e, dependendo das permisses, at gravvel) por todos os outros usurios. Essa ttica tambm cria a possibilidade da rea de intercmbio tornanar-se cheia de arquivos, conforme os usurios esquerecem de limp-la. A terceira ttica, apesar de aparentemente bizarra, pode ser a preferida na maioria dos casos. Com o advento dos protocolos de anexos de e-mail e programas mais inteligentes, enviar todo tipo de arquivo via e-mail uma operao mais segura e no requer nenhum envolvimento do administrador de sistemas. Obviamente, existe a possibilidade de um usurio tentar enviar por e-mail um arquivo de banco de dados de 1GB para todas as 150 pessoas do departamento de nanas, portanto um pouco de educao aos usurios (e possivelmente limitaes ao tamanho do anexo) prudente. Mesmo assim, nenhuma destas tticas lidam com a situao de um ou mais usurios precisarem de acesso contnuo ao mesmo arquivo. Nestes casos, necessrio utilizar outros mtodos.
Captulo 5. Administrando o Armazenamento 5.7.3.2. Compartilhamento de Arquivos
87
Quando usurios mltiplos precisam compartilhar a mesma cpia de um arquivo, permitir o acesso ao alterar as permisses do arquivo no a melhor soluo. prefervel formalizar o estado compartilhado do arquivo. H diversas razes para isto:
Os arquivos compartilhados fora do diretrio de um usurio so vulnerveis a desaparecerem inesperadamente quando o usurio deixa a empresa ou simplesmente efetua a organizao usual de seus arquivos. Torna-se difcil manter o acesso compartilhado para mais de um ou dois usurios adicionais, levando ao problema a longo termo de trabalho desnecessrio sempre que os usurios compartilhando tiverem suas responsabilidades alteradas.
Portanto, a ttica preferida :

O usurio original abdicar da propriedade direta do arquivo Criar um grupo que ter a propriedade do arquivo Colocar o arquivo num diretrio compartilhado de propriedade do grupo Tornar todos os usurios, que precisam de acesso ao arquivo, membros do grupo
Obviamente, essa ttica funciona bem tanto com arquivos mltiplos como com um nico arquivo e pode ser usada para implementar o armazenamento compartilhado para projetos grandes e complexos.
5.7.4. Adicionando/Removendo Armazenamento

Devido a necessidade incessante de espao adicional em disco, um administrador de sistemas precisa adicionar espao ao disco frequentemente, enquanto tambm remove alguns drives menores e mais antigos. Esta seo traz uma viso geral do processo bsico de adio e remoo de armazenamento.
Nota Em diversos sistemas operacionais, os dispositivos de armazenamento em massa so nomeados de acordo com suas conexes fsicas ao sistema. Consequentemente, adicionar ou remover dispositivos de armazenamento em massa pode resultar em alteraes inesperadas nos nomes dos dispositivos. Ao adicionar ou remover armazenamento, certique-se de rever (e atualizar, se necessrio) todas as referncias de nome usadas pelo seu sistema operacional.
5.7.4.1. Adicionando Armazenamento O processo de adicionar armazenamento a um sistema relativamente simples. Aqui esto os passos bsicos: 1. Instalando o hardware 2. Particionando 3. Formatando a(s) partio(es) 4. Atualizando a congurao do sistema 5. Modicando o agendamento de backup As sees seguintes abordam cada passo em detalhes.
88 5.7.4.1.1. Instalando o Hardware
Antes de qualquer outra coisa, o novo drive de disco deve estar alocado e acessvel. Apesar de existirem muitas conguraes de hardware possveis, as sees a seguir abordam as duas situaes mais comuns adicionar um drive de disco ATA ou SCSI. Os passos bsicos aqui abordados podem ser aplicados em outras conguraes.
Dica No importa qual hardware de armazenamento voc usa; deve sempre considerar a carga que um novo drive de disco adiciona ao sub-sistema I/O de seu computador. Em geral, voc deve tentar distribuir a carga I/O do disco por todos os canais disponveis. Do ponto de visto de desempenho, isso bem melhor que colocar todos os drives de disco em um canal e deixar o outro vazio e inativo.
5.7.4.1.1.1. Adicionando Drives de Disco ATA Os drives de disco ATA so usados principalmente nos computadores de mesa (desktops) e sistemas de servidores lower-end. Praticamente todos os sistemas destas categorias tm controladores ATA embutidos com canais ATA mltiplos normalmente dois ou quatro. Cada canal pode suportar dois dispositivos um mestre e um escravo. Os dois dispositivos so conectados ao canal atravs de um nico cabo. Portanto, o primeiro passo vericar quais canais tm espao disponvel para um drive de disco adicional. Teremos uma das trs situaes:

H um canal com apenas um drive de disco conectado H um canal sem nenhum drive de disco conectado No h espao disponvel
A primeira situao geralmente a mais fcil de lidar, e provvel que o cabo j conectado tenha um conector no utilizado ao qual o novo drive de disco pode ser plugado. Entretanto, se o cabo tiver somente dois conectores (um para o canal e outro para o drive de disco j instalado), necessrio substituir o cabo existente por um modelo de trs conectores. Antes de instalar o novo drive de disco, certique-se que os dois drives de disco compartilhando o canal estejam congurados apropriadamente (um como mestre e outro como escravo). A segunda situao um pouco mais difcil somente pelo fato de que deve-se adquirir um novo cabo para poder conectar um drive de disco ao canal. O novo drive de disco pode ser congurado como mestre ou escravo (apesar do primeiro drive de disco de um canal ser normalmente congurado como mestre). Na terceira situao, no h espao remanescente para um drive de disco adicional. Sendo assim, voc deve tomar uma deciso:

Adquirir uma placa de controlador ATA e instal-la Substituir um dos drives de disco instalados por um novo e maior
Adicionar uma placa de controlador abrange vericar a compatibilidade do hardware, a capacidade fsica e a compatibilidade do software. Em suma, sua placa precisa ser compatvel com os slots dos canais de seu computador. Deve haver um slot aberto para a placa, que deve ser suportada pelo seu sistema operacional. Substituir um drive de disco instalado traz um problema: o que fazer com os dados do disco? H algumas tticas possveis:
Gravar os dados num dispositivo de backup e recuper-los aps instalar o novo drive de disco
89
Usar sua rede para copiar os dados para outro sistema com espao livre suciente, recuperando os dados aps instalar o novo drive de disco Usar o espao sicamente ocupado por um terceiro drive de disco ao: 1. Remover temporariamente o terceiro drive de disco 2. Instalar temporariamente o novo drive de disco em seu lugar 3. Copiar os dados no novo drive de disco 4. Remover o drive de disco antigo 5. Substitu-lo pelo novo drive de disco 6. Reinstalar o terceiro drive de disco removido temporariamente
Instalar temporariamente o drive de disco original e o novo drive de disco num outro computador, copiar os dados no novo drive de disco e ento instalar o novo drive de disco no computador original
Como voc pode observar, s vezes necessrio um pouco de trabalho para trazer os dados (e o novo hardware) onde devem estar. 5.7.4.1.1.2. Adicionando Drives de Disco SCSI Os drives de disco SCSI so normalmente usados em estaes de trabalho e sistemas de servidores mais avanados. Ao contrrio dos sistemas baseados no ATA, os sistemas SCSI podem ou no ter controladores SCSI embutidos. Alguns tm, mas outros usam uma placa de controlador SCSI separada. As capacidades dos controladores SCSI (embutidos ou no) tambm variam imensamente. Podem prover um canal SCSI estreito ou largo. A velocidade do canal pode ser normal, rpida, ultra, ultra2 ou ultra160. Se estes termos no lhe forem familiares (brevemente abordados na Seo 5.3.2.2), voc deve determinar as capacidades da sua congurao de hardware e selecionar um novo drive de disco apropriado. A melhor fonte para estas informaes a documentao de seu sistema e/ou do adaptador SCSI. Ento, voc deve determinar quantos canais SCSI esto disponveis em seu sistema, e quais tm espao disponvel para um novo drive de disco. O nmero de dispositivos suportados por um canal SCSI varia de acordo com sua largura:

Canal SCSI estreito (8 bits) 7 dispositivos (mais controlador) Canal SCSI largo (16 bits) 15 dispositivos (mais controlador)
O primeiro passo vericar quais canais tm espao disponvel para um drive de disco adicional. Voc ter uma destas trs situaes:

H um canal com um nmero de drives de disco conectados menor que o mximo H um canal sem nenhum drive de disco conectado No h espao disponvel em nenhum dos canais
A primeira situao geralmente a mais fcil, j que provavelmente o cabo existente tem um conector no-utilizado ao qual o novo drive de disco pode ser plugado. No entanto, se este no for o caso, necessrio substituir o cabo por outro que tenha, no mnimo, mais um conector. A segunda situao um pouco mais difcil, somente pelo fato de que o cabo deve ser adquirido para poder conectar o drive de disco ao canal. Se no h espao para um drive de disco adicional, voc deve tomar uma deciso. Voc:
90 Compra e instala uma placa de controlador SCSI
Substitui um dos drives de disco instalado pelo novo e maior
Adicionar uma placa de controlador abrange vericar a compatibilidade do hardware, a capacidade fsica e a compatibilidade do software. Em suma, a placa deve ser suportada pelo seu sistema operacional, compatvel com os slots dos canais de seu computador e deve haver um slot aberto para esta. Substituir um drive de disco instalado apresenta somente um problema: o que fazer com os dados do disco? H algumas tticas possveis:

Gravar os dados num dispositivo de backup e recuper-los aps instalar o novo drive de disco Usar sua rede para copiar os dados em outro sistema com espao livre suciente, e recuper-los aps instalar o novo drive de disco Usar o espao sicamente ocupado por um terceiro drive de disco ao: 1. Remover temporariamente o terceiro drive de disco 2. Instalar temporariamente o novo drive de disco em seu lugar 3. Copiar os dados no novo drive de disco 4. Remover o drive de disco antigo 5. Substitu-lo pelo novo drive de disco 6. Reinstalar o terceiro drive de disco removido temporariamente
Instalar temporariamente o drive de disco original e o novo drive de disco num outro computador, copiar os dados no novo drive de disco e ento instalar o novo drive de disco no computador original
Uma vez que h um conector disponvel ao qual plugar o novo drive de disco, voc deve garantir que o ID SCSI do drive esteja congurado apropriadamente. Para fazer isso, necessrio saber o que todos os dispositivos do canal (inclusive o controlador) esto usando como seus IDs SCSI. O modo mais fcil acessar o BIOS do controlador SCSI. Isto feito normalmente ao pressionar uma sequncia especca de teclas durante a inicializao do sistema. Ento, voc pode visualizar a congurao do controlador SCSI, juntamente aos dispositivos ligados a todos os seus canais. Em seguida, voc deve considerar a terminao apropriada do canal. Ao adicionar um novo drive de disco, a regra bem simples se o novo drive de disco o ltimo (ou nico) dispositivo no canal, deve ter a terminao ativada. Caso contrrio, a terminao deve ser desativada. Neste ponto, voc pode passar para o prximo passo do processo particionar seu novo drive de disco.
5.7.4.1.2. Particionando Uma vez instalado o drive de disco, hora de criar uma ou mais parties para disponibilizar espao para seu sistema operacional. Apesar das ferramentas variarem de acordo com o sistema operacional, os passos bsicos so os mesmos: 1. Selecione o novo drive de disco 2. Visualize a tabela de partio atual para garantir que o drive de disco a ser particionado seja, de fato, o correto 3. Apague quaisquer parties indesejadas que possam estar presentes no novo drive de disco
91
4. Crie a(s) nova(s) partio(es), sem esquecer de especicar o tamanho e tipo de partio desejados 5. Salve suas alteraes e saia do programa de particionamento
Ateno Ao particionar um novo drive de disco, vital garantir que esteja particionando o correto. Caso contrrio, voc pode particionar inadvertidamente um drive de disco j em uso, resultando na perda de dados. Tambm certique-se de optar pelo melhor tamanho de partio. Sempre d ateno a essa questo, porque alterar este valor posteriormente bem mais difcil que gastar um tempinho para pensar nisso agora.
5.7.4.1.3. Formatando a(s) partio(es) Neste ponto, o novo drive de disco tem uma ou mais parties criadas. Entretanto, antes de usar o espao contido nestas parties, estas precisam ser formatadas. Ao formatar, voc seleciona um sistema de arquivo especco a ser usado em cada partio. Sendo assim, esse um momento crucial na vida do drive de disco; as opes que voc zer agora no podem ser alteradas sem uma grande quantidade de trabalho. O processo de formatao feito ao rodar um utilitrio; os passos envolvidos nisso variam de acordo com o sistema operacional. Aps completar a formatao, o drive de disco est congurado apropriadamente para uso. Antes de continuar, sempre melhor rever seu trabalho acessando a(s) partio(es) e garantindo que tudo esteja em ordem. 5.7.4.1.4. Atualizando a Congurao do Sistema Se o seu sistema operacional requer alteraes na congurao para usar o novo armazenamento que voc adicionou, agora hora de execut-las. Neste ponto, voc pode sentir-se relativamente conante que o sistema operacional est congurado apropriadamente para disponibilizar o novo armazenamento toda vez que o sistema inicializar (mas, se voc puder efetuar uma breve reinicializao para garantir melhor ainda). A prxima seo aborda um dos passos mais comumente esquecidos no processo de adio de novo armazenamento. 5.7.4.1.5. Alterando o Agendamento de Backup Assumindo que o novo armazenamento esteja com dados que devem ser guardados, essa a hora de efetuar as alteraes necessrias em seu procedimento de backup e garantir que o novo armazenamento tenha, de fato, um backup. A natureza exata do que voc deve fazer para tanto depende da maneira atravs da qual os backups so feitos em seu sistema. No entanto, aqui esto algumas dicas para ter em mente ao efetuar as alteraes necessrias:

Considere qual deve ser a melhor frequncia de backup Determine qual estilo de backup mais apropriado (somente backups completos, completos com incrementos, completos com diferenciais, etc)
92
Captulo 5. Administrando o Armazenamento Considere o impacto do armazenamento adicional no uso de sua mdia de backup, especialmente conforme car cheia Julgue se o backup adicional pode fazer com que os backups demorem muito e comecem a utilizar o tempo alm daquele determinado para sua janela de backup Garanta de comunicar estas alteraes s pessoas que precisam saber (outros administradores de sistemas, pessoal de operaes, etc)
Feito isso, seu novo armazenamento est pronto para ser usado.
5.7.4.2. Removendo Armazenamento Remover espao em disco de um sistema simples; a maioria dos passos so parecidos com a sequncia de instalao: 1. Retire do drive de disco quaisquer dados a serem salvos 2. Altere o agendamento de backup para que o drive de disco no tenha mais procedimento de backup 3. Atualize a congurao do sistema 4. Apague o contedo do drive de disco 5. Remova o drive de disco Como voc pode observar, h alguns passos extras em relao ao processo de instalao. Estes passos so abordados nas prximas sees. 5.7.4.2.1. Removendo Dados do Drive de Disco Se houver dados no drive de disco que devem ser salvos, a primeira coisa a fazer determinar para onde os dados devem ir. Esta deciso depende principalmente no que ser feito com estes dados. Por exemplo: se estes no forem utilizados ativamente, devem ser arquivados, provavelmente da mesma maneira que os backups de seu sistema. Isso signica que essa a hora de considerar os perodos de reteno para este backup nal.
Dica Tenha em mente que, alm das regras de reteno de dados que sua empresa tenha, tambm deve haver requisitos legais para a reteno de dados por um certo perodo de tempo. Sendo assim, certique-se de consultar o departamento responsvel pelos dados enquanto eram utilizados; eles devem saber o perodo de reteno apropriado.
Por outro lado, se os dados ainda esto em uso, ento devem residir no sistema mais apropriado para este uso. Obviamente, se este for o caso, talvez seja mais fcil mover os dados ao reinstalar o drive de disco no novo sistema. Se optar por isso, voc deve antes fazer um backup completo do dados muitas pessoas derrubaram drives de disco cheios de dados valiosos (perdendo tudo) enquanto simplesmente andavam pelo centro de dados.
Captulo 5. Administrando o Armazenamento 5.7.4.2.2. Apague o Contedo do Drive de Disco
93
No importa se o drive de disco contm dados valiosos ou no; sempre uma boa idia apagar todo o contedo de um drive de disco antes de reatribuir ou abdicar de seu controle. Apesar do principal motivo ser garantir que nenhuma informo delicada permanea no drive de disco, tambm uma boa hora para vericar sua sade executando um teste de acesso-gravao para blocos ruins por todo o drive de disco.
Importante Muitas empresas (e agncias do governo) tm mtodos especcos para apagar dados de drives de disco e outras mdias de armazenamento de dados. Voc sempre deve garantir que entende e cumpre estes requisitos; muitas vezes, h consequncias legais caso voc no os cumpra. O exemplo acima no deve, de modo algum, ser considerado o melhor mtodo de limpar um drive de disco. Alm disso, as empresas que trabalham com dados ordenados podem descobrir que a disposio nal do drive de disco est sujeita a alguns procedimentos legais obrigatrios (tais como a destruio fsica do drive de disco). Nestes casos, o departamento de segurana de sua empresa deve ser capaz de oferecer-lhe aconselhamento.
5.8. Um Pouco Sobre Backups. . .

Os backups so um dos fatores mais importantes quando pensamos em armazenamento de disco. No detalhamos a questo aqui, pois h uma seo (Seo 8.2) mais aprofundada e dedicada ao assunto.

Dependendo de sua experincia anterior como administrador de sistemas, administrar o armazenamento sob o Red Hat Enterprise Linux pode ser familiar ou completamente estranho. Esta seo aborda os aspectos de armazenamento especcos ao Red Hat Enterprise Linux.
5.9.1. Conveno de Nomenclatura de Dispositivos

Assim como todos os sistemas operacionais parecidos com o Linux, o Red Hat Enterprise Linux usa arquivos de dispositivo para acessar todo o hardware (incluindo drives de disco). No entanto as convenes de nomenclatura para dispositvos de armazenamento anexos variam ligeiramente entre as diversas implementaes do Linux e parecidas com o Linux. Aqui esto os nomes destes arquivos de dispositivo sob o Red Hat Enterprise Linux:
Nota Os nomes dos dispositivos sob o Red Hat Enterprise Linux so determinados no momento da inicializao (boot time). Consequentemente, as alteraes efetuadas na congurao do hardware de um sistema podem resultar na alterao dos nomes dos dispositivos quando o sistema reinicializar. Por causa disso, os problemas podem ocorrer, caso as referncias dos nomes dos dispositivos no forem adequadamente atualizadas nos arquivos de congurao do sistema.
94 5.9.1.1. Arquivos de Dispositivos
Sob o Red Hat Enterprise Linux, os arquivos dos dispositivos para drives de disco aparecem no diretrio /dev/. O formato do nome de cada arquivo depende de diversos aspectos do hardware existente e como este foi congurado. Os pontos importantes so:

Tipo de dispositivo Unidade Partio
5.9.1.1.1. Tipo de Dispositivo As primeiras duas letras do nome do arquivo do dispositivo referem-se ao tipo especco do dispositivo. Para drives de disco, h dois tipos de dispositivos mais comuns:
sd hd
O dispositivo baseado na SCSI O dispositivo baseado na ATA
Para mais informaes sobre ATA e SCSI, consulte a Seo 5.3.2. 5.9.1.1.2. Unidade Na sequncia das duas letras do tipo de dispositivo, h uma ou duas letras que especicam a unidade. A letra que designa a unidade comea com "a" para a primeira unidade, "b" para a segunda e assim por diante. Consequentemente, o primeiro disco rgido de seu sistema pode aparecer como hda ou sda.
Dica A habilidade do SCSI em lidar com um nmero grande de dispositivos precisou da adio de um segundo caractere de unidade para suportar sistemas com mais de 26 dispositivos SCSI anexos. Sendo assim, os primeiros 26 discos rgidos SCSI de um sistema seriam nomeados de sda a sdz, os prximos 26 seriam nomeados de sdaa a sdaz e assim por diante.
5.9.1.1.3. Partio A parte nal do nome do arquivo de dispositivo um nmero representando uma partio especca no dispositivo, comeando por "1." O nmero pode ter um ou dois dgitos, dependendo do nmero de parties gravadas no dispositivo especco. Uma vez conhecido o formato do nome do arquivo de dispositivo, fcil entender as referncias de cada um. Aqui esto alguns exemplos:
/dev/hda1
A primeira partio do primeiro drive ATA A dcima-segunda partio do segundo drive SCSI A quarta partio do trigsimo drive SCSI
/dev/sdb12 /dev/sdad4
Captulo 5. Administrando o Armazenamento 5.9.1.1.4. Acesso ao Dispositivo Inteiro
95
H situaes nas quais necessrio acessar o dispositivo inteiro e no somente uma partio. Isso normalmente feito quando o dispositivo no est particionado ou quando no suporta parties padro (como o drive de CD-ROM). Nestes casos, o nmero da partio omitido:
/dev/hdc /dev/sdb
O terceiro dispositivo ATA inteiro O segundo dispositivo SCSI inteiro
No entanto, a maioria dos drives de disco usa parties (mais informaes sobre o particionamento sob o Red Hat Enterprise Linux podem ser encontradas na Seo 5.9.6.1).
5.9.1.2. Alternativas aos Nomes de Arquivo dos Dispositivos Como a adio ou remoo de dispositivos de armazenamento em massa pode resultar em alteraes nos nomes de arquivo dos dispositivos existentes, existe o risco do armazenamento no estar disponvel quando o sistema reinicializar. Eis um exemplo da sequncia de eventos acarretando este problema: 1. O administrador de sistemas adiciona um novo controlador SCSI para poder adicionar dois novos drives SCSI ao sistema (o canal SCSI existente est totalmente cheio) 2. Os drives SCSI originais (incluindo o primeiro drive do canal: /dev/sda) no so alterados de modo algum 3. O sistema reinicializado 4. Agora, o drive SCSI previamente conhecido como /dev/sda, tem um novo nome porque o primeiro drive SCSI do novo controlador o /dev/sda Na teoria, este parece ser um grande problema. Entretanto, na prtica, isso raramente um problema por diversas razes. Primeiro: reconguraes do hardware desse tipo raramente acontecem. Segundo: provvel que o administrador de sistemas tenha agendado um tempo fora do ar (downtime) para efetuar as alteraes necessrias; o tempo fora do ar requer um planejamento cuidadoso para garantir que o trabalho sendo feito no leve mais que o tempo alocado. Esse planejamento tem o benefcio colateral de trazer tona todas as questes relativas s alteraes de nomes dos dispositivos. Entretanto, algumas empresas e suas conguraes de sistemas tem maior probabilidade de passar por essa situao. As empresas que requerem reconguraes frequentes do armazenamento para atender s suas necessidades frequentemente usam hardware capaz de recongurao sem a necessidade de tempo fora do ar. Tal hardware, conhecido como hotpluggable, facilita a adio ou remoo de armazenamento. Porm, sob tais circunstncias, as questes de nomenclatura de dispositivos podem tornar-se um problema. Felizmente, o Red Hat Enterprise Linux contm funcionalidades que amenizam o problema das alteraes nos nomes dos dispositivos. 5.9.1.2.1. Etiquetas do Sistema de Arquivo Alguns sistemas de arquivo (abordados na Seo 5.9.2) tm a habilidade de armazenar uma etiqueta uma sequncia de caracteres que pode ser usada para identicar unicamente os dados contidos no sistema de arquivo. As etiquetas podem ser usadas ao montar o sistema de arquivo, eliminando a necessidade do uso do nome do dispositivo. As etiquetas de sistema de arquivo funcionam bem; no entanto, devem ser nicas em todo o sistema. Se houver mais de um sistema de arquivo com a mesma etiqueta, talvez voc no consiga acessar o sistema de arquivo desejado. Note tambm que as conguraes do sistema que no utilizam sistemas de arquivo (alguns bancos de dados, por exemplo) no podem usufruir das etiquetas de sistema de arquivo.
96 5.9.1.2.2. Usando o devlabel
O software devlabel tenta resolver a questo da nomenclatura de dispositivos de maneira diferente que as etiquetas do sistema de arquivo. O software devlabel executado pelo Red Hat Enterprise Linux sempre que o sistema reinicializa (e sempre que dispositivos hotpluggable so inseridos ou removidos). Quando o devlabel executado, l o arquivo de congurao (/etc/sysconfig/devlabel) para obter a lista dos dispositivos pelos quais responsvel. Para cada dispositivo da lista, h uma ligao simblica, ou symbolic link, (escolhida pelo administrador de sistemas) e o UUID (IDenticador nico Universal) do dispositivo. O comando devlabel garante que a ligao simblica sempre refere ao dispositivo originalmente especicado mesmo que o nome deste dispositivo tenha mudado. Dessa maneira, um administrador de sistemas pode congurar um sistema para referir ao /dev/projdisk ao invs do /dev/sda12, por exemplo. Como o UUID obtido diretamente pelo dispositivo, o devlabel deve somente procurar pelo UUID correspondente no sistema e atualizar a ligao simblica apropriadamente. Para mais informaes sobre o devlabel, consulte o Guia de Administrao de Sistemas Red Hat Enterprise Linux.
5.9.2. Conceitos Bsicos do Sistema de Arquivo

O Red Hat Enterprise Linux inclui suporte para muitos sistemas de arquivo conhecidos, possibilitando acessar facilmente os sistemas de arquivo de outros sistemas operacionais. Isso especialmente til em cenrios de boot duplo e ao migrar arquivos de um sistema operacional para outro. Os sistemas de arquivo suportados incluem (mas no esto limitados a):

EXT2 EXT3 NFS ISO 9660 MSDOS VFAT
Os cenrios seguintes exploram os sistemas de arquivo mais conhecidos em detalhes. 5.9.2.1. EXT2 At recentemente, o sistema de arquivo ext2 foi o sistema de arquivo padro para o Linux. Como tal, recebeu testes intensivos e considerado um dos sistemas de arquivo mais robustos em uso. No entanto, no existe um sistema de arquivo perfeito e o ext2 no uma exceo. Um problema comumente reportado que o sistema de arquivo ext2 deve passar por uma vericao de integridade muito longa, caso o sistema no tenha sido desligado apropriadamente. Apesar deste requisito no ser exclusivo do ext2, sua popularidade, combinada com o advento de drives de disco maiores, signicou que a vericao de integridade estava levando muito tempo. Algo devia ser feito. A prxima seo aborda a ttica adotada para resolver esta questo sob o Red Hat Enterprise Linux.
Captulo 5. Administrando o Armazenamento 5.9.2.2. EXT3
97
O sistema de arquivo ext3 adicionou as capacidades de journaling sobre a base de cdigo j provada do ext2. Com o journaling, o ext3 sempre mantm o sistema de arquivo num estado consistente, eliminando a necessidade de longas vericaes de integridade no sistema de arquivo. Isso feito ao gravar todas as alteraes do sistema de arquivo num registro em disco, que alimentado frequentemente. Aps um evento inesperado no sistema (tal como falta de energia ou queda do sistema), a nica operao que precisa ocorrer antes de disponibilizar o sistema de arquivo processar o contedo do registro; na maioria dos casos isso leva aproximadamente um segundo. Como o formato dos dados do ext3 em disco baseado no ext2, possvel acessar um sistema de arquivo ext3 em qualquer sistema capaz de acessar e gravar um sistema de arquivo ext2 (porm sem o benefcio do journaling). Este pode ser um excelente benefcio em empresas que utilizam alguns sistemas com ext3 e outros com ext2. 5.9.2.3. ISO 9660 Em 1987, a Organizao Internacional para a Padronizao (conhecida como ISO, International Organization for Standardization) lanou o padro 9660. O ISO 9660 dene como os arquivos so representados nos CD-ROMs. Os administradores de sistemas Red Hat Enterprise Linux provavelmente vero dados no formato ISO 9660 em dois lugares:

CD-ROMs Arquivos (geralmente referenciados como imagens ISO) contendo sistemas de arquivo ISO 9660 completos, a serem gravados em mdia CD-R ou CD-RW.
O padro ISO 9660 bsico limitado em funcionalidade, especialmente se comparado com sistemas de arquivo mais modernos. Os nomes de arquivos podem ter no mximo oito caracteres e extenso at trs caracteres. No entanto, diversas extenses do padro tornaram-se conhecidas, incluindo:
Rock Ridge Usa alguns campos indenidos no ISO 9660 para oferecer suporte para funcionalidades como nomes de arquivo longos misturando letras maisculas e minsculas, para ligaes simblicas e diretrios embutidos (ou seja, diretrios que podem conter outros diretrios) Joliet Uma extenso do padro ISO 9660, desenvolvida pela Microsoft para permitir que CDROMs contenham nomes de arquivo longos, usando o conjunto de caracteres Unicode
O Red Hat Enterprise Linux capaz de interpretar corretamente os sistemas de arquivo ISO 9660 usando ambas extenses, Rock Ridge e Joliet. 5.9.2.4. MSDOS O Red Hat Enterprise Linux tambm suporta os sistemas de arquivo de outros sistemas operacionais. Como o nome do sistema de arquivo msdos implica, o sistema operacional que originalmente o suportava era o MS-DOS da Microsoft. Assim como no MS-DOS, um sistema Red Hat Enterprise Linux acessando um sistema de arquivo msdos est limitado aos nomes de arquivo 8.3. Da mesma forma, outros atributos do arquivo, como permisses e propriedade, no podem ser alterados. Entretanto, do ponto de vista de intercmbio de arquivos, o sistema de arquivo msdos mais que suciente para executar o trabalho. 5.9.2.5. VFAT O sistema de arquivo vfat foi usado pela primeira vez pelo sistema operacional Windows 95 da Microsoft. Trouxe uma melhoria sobre o sistema de arquivo msdos; os nomes de arquivo num sistema
98
vfat podem ser mais longos que o formato 8.3. No entanto, as permisses e propriedade ainda no podem ser alterados.
5.9.3. Montando Sistemas de Arquivo

Para acessar qualquer sistema de arquivo, preciso primeiro mont-lo (mount). Ao montar um sistema de arquivo, voc direciona o Red Hat Enterprise Linux a disponibilizar uma partio especca (num dispositivo especco) ao sistema. Da mesma forma, ao acessar um determinado sistema de arquivo que no mais desejado, necessrio desmont-lo (umount). Para montar um sistema de arquivo, preciso especicar dois tipos de informao:

Um meio de identicar unicamente o drive de disco e partio desejados, como o nome do arquivo do dispositivo, a etiqueta do sistema de arquivo ou a ligao simblica administrada pelo devlabel Um diretrio sob o qual o sistema de arquivo montado ser disponibilizado (conhecido como ponto de montagem)
As sees seguintes abordam os pontos de montagem mais detalhadamente. 5.9.3.1. Pontos de Montagem A no ser que voc esteja acostumado com o sistema operacional Linux (ou outros parecidos), o conceito do ponto de montagem pode parecer estranho primeira vista. Entretanto, um dos mtodos mais poderosos e exveis de administrao de sistemas de arquivo. Em muitos outros sistemas operacionais, a especicao completa de um arquivo inclui seu nome, algum meio de identicar o diretrio especco no qual reside e um meio de identicar o dispositivo fsico no qual o arquivo pode ser encontrado. O Red Hat Enterprise Linux usa uma ttica ligeiramente diferente. Assim como ocorre em outros sistemas operacionais, uma especicao completa inclui o nome do arquivo e o diretrio no qual reside. No entanto, no h um identicador explcito do dispositivo. A razo dessa aparente decincia o ponto de montagem. Em outros sistemas operacionais, h uma hierarquia de diretrios para cada partio. Mas, em sistemas parecidos com o Linux, h somente uma hierarquia de diretrio para o sistema todo, que pode extender-se a parties mltiplas. A chave o ponto de montagem. Ao montar um sistema de arquivo, este disponibilizado como um conjunto de sub-diretrios sob o ponto de montagem especicado. Essa aparente decincia , na verdade, uma vantagem. Signica que possvel expandir suavemente um sistema de arquivo Linux, com todos os diretrios capazes de agirem como um ponto de montagem para espao adicional em disco. Como um exemplo, assuma que um sistema Red Hat Enterprise Linux contenha um diretrio foo em seu diretrio root; a localidade completa do diretrio seria /foo/. Em seguida, assuma que este sistema tem uma partio a ser montada e seu ponto de montagem deve ser /foo/. Se esta partio tivesse um arquivo de nome bar.txt no nvel superior de seu diretrio, voc poderia acess-lo aps montar a partio, com a especicao seguinte:
/foo/bar.txt
Em outras palavras, uma vez montada a partio, qualquer arquivo que acessado ou gravado em qualquer localidade sob o diretrio /foo/, ser acessado ou salvo nessa partio. Um ponto de montagem comumente usado em muitos sistemas Red Hat Enterprise Linux /home/ isso ocorre porque os diretrios de login para todas as contas de usurio normalmente esto localizadas sob /home/. Se /home/ for usado como ponto de montagem, os arquivos de todos os usurios so salvos numa partio dedicada e no lotaro o sistema de arquivo do sistema operacional.
99
Dica Como o ponto de montagem somente um diretrio comum, possvel salvar arquivos num diretrio posteriormente usado como ponto de montagem. Se isso acontecer, o que ocorre com os arquivos que estavam originalmente no diretrio? Contanto que a partio seja montada no diretrio, os arquivos no estaro acessveis (o sistema de arquivo montado aparece no lugar do contedo do diretrio). No entanto, os arquivos no sero danicados e podem ser acessados aps a partio ser desmontada.
5.9.3.2. Visualizando O Que est Montado Alm de montar e desmontar espao em disco, possvel visualizar o que est montado. H diversas maneiras diferentes de fazer isso:

Visualizar o /etc/mtab Visualizar o /proc/mounts Atribuindo o comando df
5.9.3.2.1. Visualizar o /etc/mtab O arquivo /etc/mtab um arquivo normal atualizado pelo programa mount sempre que os sistemas de arquivo so montados ou desmontados. Aqui est uma amostra do /etc/mtab:
/dev/sda3 / ext3 rw 0 0 none /proc proc rw 0 0 usbdevfs /proc/bus/usb usbdevfs rw 0 0 /dev/sda1 /boot ext3 rw 0 0 none /dev/pts devpts rw,gid=5,mode=620 0 0 /dev/sda4 /home ext3 rw 0 0 none /dev/shm tmpfs rw 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
Nota O arquivo /etc/mtab deve ser usado para visualizar somente o status dos sistemas de arquivo correntemente montados. No deve ser modicado manunalmente.
Cada linha representa um sistema de arquivo correntemente montado e contm os seguintes campos (da esquerda para a direita):

A especicao do dispositivo O ponto de montagem O tipo de sistema de arquivo Se o sistema de arquivo est montado como somente-leitura (ro, read-only) ou leitura e gravao (rw, read-write), junto s outras opes do ponto de montagem Dois campos no-usados contendo zeros (para saber sobre a compatibilidade com /etc/fstab 11)
11. Consulte a Seo 5.9.5 para mais informaes.
100 5.9.3.2.2. Visualizar o /proc/mounts
O arquivo /proc/mounts parte do sistema de arquivo virtual proc. Assim como os outros arquivos sob /proc/, o "arquivo" mounts no existe em nenhum drive de disco de seu sistema Red Hat Enterprise Linux. De fato, nem um arquivo, mas uma representao do status do sistema disponibilizado (pelo kernel do Linux) no formato de arquivo. Usando o comando cat /proc/mounts podemos visualizar o status de todos os sistemas de arquivo montados:
rootfs / rootfs rw 0 0 /dev/root / ext3 rw 0 0 /proc /proc proc rw 0 0 usbdevfs /proc/bus/usb usbdevfs rw 0 0 /dev/sda1 /boot ext3 rw 0 0 none /dev/pts devpts rw 0 0 /dev/sda4 /home ext3 rw 0 0 none /dev/shm tmpfs rw 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
Como podemos observar no exemplo anterior, o formato do /proc/mounts muito similar ao formato do /etc/mtab. H diversos sistemas de arquivo montados que no tm nenhuma relao com drives de disco. Dentre estes, temos o prprio sistema de arquivo /proc/ (junto a dois outros sistemas operacionais montados sob /proc/), pseudo-ttys e memria compartilhada. Apesar do formato no ser muito amigvel, observar o /proc/mounts a melhor maneira de estar 100% certo de ver o que est montado em seu sistema Red Hat Enterprise Linux, j que o kernel provm estas informaes. Outros mtodos podem, sob raras circunstncias, serem incorretos. Entretanto, na maior parte do tempo voc provavelmente utilizar um comando com output de leitura mais fcil (e til). A seo seguinte descreve este comando. 5.9.3.2.3. Atribuindo o Comando df Apesar do uso do /etc/mtab ou do /proc/mounts trazer as informaes sobre quais sistemas de arquivo esto montados, fazem pouco alm disso. Na maior parte do tempo voc estar interessado num aspecto especco dos sistemas de arquivo correntemente montados a quantidade de espao livre nestes. Para isso, podemos usar o comando df. Aqui est uma amostra do output do df:
Filesystem /dev/sda3 /dev/sda1 /dev/sda4 none 1k-blocks 8428196 124427 8428196 644600 Used Available Use% Mounted on 4280980 3719084 54% / 18815 99188 16% /boot 4094232 3905832 52% /home 0 644600 0% /dev/shm
Nota-se imediatamente diversas diferenas com o /etc/mtab e /proc/mount:

A exibio de um cabealho de fcil leitura Com exceo do sistema de arquivo com memria compartilhada, so exibidos somente sistemas de arquivo baseados no disco So exibidos o tamanho total, o espao utilizado, o espao livre e a porcentagem em nmeros
Esse ltimo ponto provavelmente o mais importante, pois todo administrador de sistemas eventualmente precisa lidar com um sistema que atingiu todo seu espao em disco. Com o df muito fcil visualizar onde est o problema.
101
5.9.4. Armazenamento Acessvel pela Rede Sob o Red Hat Enterprise Linux
H duas tecnologias principais usadas para implementar o armazenamento acessvel pela rede sob o Red Hat Enterprise Linux:

NFS SMB
As sees seguintes abordam estas tecnologias. 5.9.4.1. NFS Como o nome infere, o Network File System (mais comumente conhecido como NFS ou Sistema de Arquivo de Rede) um sistema de arquivo que pode ser acessado atravs de uma conexo de rede. Em outros sistemas de arquivo, o dispositivo de armazenamento deve ser diretamente ligado ao sistema local. No entanto, este no um requisito do NFS, o que possibilita uma variedade de conguraes diferentes - de servidores centralizados de sistema de arquivo a sistemas de computadores inteiramente sem discos. Porm, ao contrrio de outros sistemas de arquivo, o NFS no dita um formato especco em disco. Ao invs disso, conta com o suporte do sistema de arquivo nativo do sistema operacional do servidor para controlar as I/Os correntes para o(s) drive(s) local(is). Ento, o NFS disponibiliza o sistema de arquivo para qualquer sistema operacional rodando um cliente NFS compatvel. Apesar de ser uma tecnologia primariamente do Linux e UNIX, importante notar a existncia de implementaes de clientes NFS para outros sistemas operacionais, viabilizando sua tcnica para compartilhar arquivos dentre diversas plataformas diferentes. Os sistemas de arquivo que o NFS disponibiliza para clientes so controlados pelo arquivo de congurao /etc/exports. Para mais informaes, consulte a pgina man exports(5) e o Guia de Administrao de Sistemas Red Hat Enterprise Linux. 5.9.4.2. SMB SMB signica Server Message Block (Bloco de Mensagens do Servidor) e o nome do protocolo de comunicaes usado por vrios sistemas operacionais produzidos pela Microsoft ao longo dos anos. O SMB possibilita compartilhar armazenamento atravs de uma rede. As implementaes de hoje frequentemente usam o TCP/IP como o transporte fundamental; o transporte prvio era o NetBEUI. O Red Hat Enterprise Linux suporta o SMB atravs do programa de servidor Samba. O Guia de Administrao de Sistemas Red Hat Enterprise Linux contm informaes sobre a congurao do Samba.
5.9.5. Montando Sistemas de Arquivo Automaticamente com /etc/fstab

Quando um sistema Red Hat Enterprise Linux recm-instalado, todas as parties de disco denidas e/ou criadas durante a instalao so conguradas para serem montadas automaticamente sempre que o sistema reinicializar. Porm, o que acontece quando adicionamos drives de disco num sistema aps completa a instalao? A resposta "nada", porque o sistema no foi congurado para mont-las automaticamente. No entanto, fcil mudar isso. A resposta est no arquivo /etc/fstab. Este arquivo usado para controlar quais sistemas de arquivo so montados quando o sistema inicializa, e tambm para prover valores default para outros sistemas de arquivo que possam ser montados manualmente ao longo do tempo. Aqui est uma amostra do arquivo /etc/fstab:
LABEL=/ / ext3 defaults 1 1
102
/dev/sda1 /dev/cdrom /dev/homedisk /dev/sda2
/boot /mnt/cdrom /home swap
ext3 iso9660 ext3 swap
defaults 1 2 noauto,owner,kudzu,ro 0 0 defaults 1 2 defaults 0 0
Cada linha representa um sistema de arquivo e contm os seguintes campos:
Especicador do sistema de arquivo Para sistemas de arquivo baseados em disco, o nome de um dispositivo (/dev/sda1), a etiqueta do sistema de arquivo (LABEL=/) ou uma ligao simblica administrada pelo devlabel (/dev/homedisk) Ponto de montagem Exceto as parties swap, este campo especica o ponto de montagem a ser usado quando o sistema de arquivo estiver montado (/boot) Tipo de sistema de arquivo O tipo de sistema de arquivo presente no dispositivo especicado (note que auto pode ser especicado para selecionar a deteco automtica do sistema de arquivo a ser montado, o que prtico para unidades de mdia removvel como drives de disquete) Opes de montagem Uma lista de opes, separadas por vrgulas, que podem ser usadas para controlar o comportamento do mount (noauto,owner,kudzu) Frequncia do dump Se o utilitrio de backup dump for usado, o nmero deste campo controla como o dump lida com o sistema de arquivo especicado Ordem de vericao do sistema de arquivo Controla a ordem na qual o fsck verica a integridade dos sistemas de arquivo
5.9.6. Adicionando/Removendo Armazenamento

Apesar da maioria dos passos necessrios para adicionar ou remover armazenamento dependerem mais do hardware que do software do sistema, h aspectos do procedimento especcos ao seu ambiente operacional. Esta seo explora os passos especcos ao Red Hat Enterprise Linux necessrios para adicionar e remover armazenamento. 5.9.6.1. Adicionando Armazenamento O processo de adio de armazenamento relativamente simples. Aqui esto os passos especcos ao Red Hat Enterprise Linux:

Particionando Formatando a(s) partio(es) Atualizar o /etc/fstab
As sees seguintes abordam cada passo em detalhes. 5.9.6.1.1. Particionando Uma vez instalado o drive de disco, hora de criar uma ou mais parties a m de disponibilizar espao para o Red Hat Enterprise Linux. H mais de uma maneira de fazer isso:

Usando o utilitrio fdisk na janela de comandos Usando o parted, um outro utilitrio da linha de comandos
Apesar das ferramentas serem diferentes, os passos bsicos so os mesmos. O exemplo a seguir inclui os comandos necessrios para executar estes passos usando fdisk:
103
1. Selecione o novo drive de disco (o nome do drive pode ser identicado atravs das convenes de nomenclatura dos dispositivos descritas na Seo 5.9.1). Usando o fdisk, isso feito incluindo o nome do dispositivo ao iniciar o fdisk:
fdisk /dev/hda
2. Visualize a tabela de partio do drive de disco para garantir que o drive a ser particionado seja, de fato, o correto. Em nosso exemplo, o fdisk exibe a tabela de partio usando o comando p:
Command (m for help): p Disk /dev/hda: 255 heads, 63 sectors, 1244 cylinders Units = cylinders of 16065 * 512 bytes Device Boot /dev/hda1 * /dev/hda2 /dev/hda3 /dev/hda4 Start 1 18 84 476 End 17 83 475 1244 Blocks 136521 530145 3148740 6176992+ Id 83 82 83 83 System Linux Linux swap Linux Linux
3. Apague todas as parties indesejadas que possam estar no novo drive de disco. Isso feito usando o comando d no fdisk:
Command (m for help): d Partition number (1-4): 1
O processo deve ser repetido para todas as parties desnecessrias presentes no drive de disco. 4. Crie nova(s) partio(es), certicando-se de especicar o tamanho e tipo de sistema de arquivo desejados. Usando o fdisk, este um processo de dois passos primeiro: criar a partio (usando o comando n):
Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-767): 1 Last cylinder or +size or +sizeM or +sizeK: +512M
Command (m for help): t Partition number (1-4): 1 Hex code (type L to list codes): 82
Segundo: determinar o tipo de sistema de arquivo (usando o comando t):
A partio do tipo 82 representa uma partio Linux swap. 5. Salve suas alteraes e saia do programa de particionamento. Isso feito no fdisk usando o comando w:
Command (m for help): w
104
Ateno Ao particionar um novo drive de disco, vital garantir que esteja particionando o correto. Caso contrrio, voc pode particionar inadvertidamente um drive de disco j em uso, resultando na perda de dados. Tambm certique-se de optar pelo melhor tamanho de partio. Sempre d ateno a essa questo, porque alterar este valor posteriormente bem mais difcil que gastar um tempinho para pensar nisso agora.
5.9.6.1.2. Formatando a(s) partio(es) A formatao de parties sob o Red Hat Enterprise Linux feita com o utilitrio mkfs. Na realidade, o mkfs no executa o trabalho de gravar as informaes especcas do sistema de arquivo num drive de disco; ao invs disso, passa o controle para um dos diversos outros programas que realmente criam o sistema de arquivo. Essa a hora de observar a pgina man mkfs. fstype do sistema de arquivo que voc selecionou. Por exemplo: veja a pgina man mkfs.ext3 para vericar as opes disponveis ao criar um novo sistema de arquivo ext3. Em geral, os programas mkfs. fstype oferecem defaults razoveis para a maioria das conguraes, mas aqui esto algumas opes que os administradores de sistemas comumente alteram:

Determinar uma etiqueta de volume para uso posterior no /etc/fstab Em discos rgidos muito grandes, determinar uma porcentagem mais baixa para o espao reservado para o super-usurio Determinar um tamanho de bloco fora do padro e/ou bytes por inode para conguraes que devem suportar arquivos muito grandes ou muito pequenos Vericar os blocos ruins antes de formatar
Uma vez criados os sistemas de arquivo nas parties apropriadas, o drive de disco est congurado corretamente para o uso. Em seguida, sempre melhor vericar novamente seu trabalho montando manualmente a(s) partio(es) e garantindo que est tudo em ordem. Aps a segunda vericao, hora de congurar seu sistema Red Hat Enterprise Linux para montar automaticamente o(s) novo(s) sistema(s) de arquivo sempre que inicializar. 5.9.6.1.3. Atualizar o /etc/fstab Conforme a Seo 5.9.5, voc deve adicionar a(s) linha(s) necessria(s) ao /etc/fstab para garantir que o(s) novo(s) sistema(s) de arquivo seja montado sempre que o sistema reinicializar. Aps atualizar o /etc/fstab, teste seu trabalho atribuindo um comando mount "incompleto", especicando somente o dispositivo ou ponto de montagem. Algo similar a um dos seguintes comandos suciente:
mount /home mount /dev/hda3
(Substituir /home ou /dev/hda3 pelo ponto de montagem ou dispositivo para sua situao especca.) Se a entrada apropriada do /etc/fstab estiver correta, o mount obtm as informaes faltantes e completa a operao de montagem.
105
Neste ponto voc pode estar relativamente conante que o /etc/fstab est congurado apropriadamente para montar automaticamente o novo armazenamento sempre que o sistema inicializar (mas, se voc puder efetuar uma reinicializao rpida para garantir melhor ainda).
5.9.6.2. Removendo Armazenamento O processo de remoo de armazenamento de um sistema Red Hat Enterprise Linux relativamente simples. Aqui esto os passos especcos ao Red Hat Enterprise Linux:

Remova as parties do drive de disco de /etc/fstab Desmonte as parties ativas do drive de disco Apague o contedo do drive de disco
As sees seguintes cobrem estes tpicos em detalhes. 5.9.6.2.1. Remover as Parties do Drive de Disco do /etc/fstab Usando seu editor de texto preferido, remova a(s) linha(s) correspondente(s) (s) partio(es) do drive de disco do arquivo /etc/fstab. Voc pode identicar as linhas apropriadas atravs de um dos mtodos seguintes:

Encontrando o ponto de montagem correspondente partio nos diretrios da segunda coluna do

/etc/fstab
Encontrando o nome do dispositivo correspondente nos nomes de arquivo da primeira coluna do

/etc/fstab
Dica Certique-se de procurar por todas as linhas do /etc/fstab que identicam parties swap no drive de disco a ser removido; estas podem passar desapercebidas facilmente.
5.9.6.2.2. Finalizando o Acesso Com umount Em seguida, todo acesso ao drive de disco deve ser nalizado. Para parties contendo sistemas de arquivo ativos, isso feito usando o comando umount. Se houver uma partio swap no drive de disco, deve ser desativada com o comando swapoff ou o sistema deve ser reinicializado. Para desmontar parties com o comando umount necessrio especicar o nome do arquivo do dispositivo ou o ponto de montagem da partio:
umount /dev/hda2 umount /home
Uma partio s pode ser desmontada se no estiver em uso. Se a partio no puder ser desmontada no nvel de execuo normal, reinicialize no modo de recuperao e remova a entrada /etc/fstab da partio. Ao usar o swapoff para desabilitar o swapping numa partio, voc deve especicar o nome do arquivo do dispositivo representando a partio swap:
106
swapoff /dev/hda4
Se o swapping no puder ser desabilitado de uma partio swap usando o swapoff, inicialize no modo de recuperao e remova a entrada /etc/fstab da partio. 5.9.6.2.3. Apague o Contedo do Drive de Disco Apagar o contedo de um drive de disco sob o Red Hat Enterprise Linux um procedimento simples. Aps desmontar todas as parties do drive de disco, atribua o seguinte comando (como root):
badblocks -ws device-name
Onde device-name representa o nome do arquivo do drive de disco que voc deseja apagar, excluindo o nmero da partio. Por exemplo: /dev/hdb para o segundo disco rgido ATA. O seguinte output apresentado enquanto o badblocks executado:
Writing Reading Writing Reading Writing Reading Writing Reading pattern 0xaaaaaaaa: and comparing: done pattern 0x55555555: and comparing: done pattern 0xffffffff: and comparing: done pattern 0x00000000: and comparing: done done done done done
Tenha em mente que o badblocks est, na realidade, gravando quatro padres de dados diferentes em cada bloco do drive de disco. Para drives de disco grandes, este processo pode levar bastante tempo frequentemente diversas horas.
Importante Muitas empresas (e agncias do governo) tm mtodos especcos para apagar dados de drives de disco e outras mdias de armazenamento de dados. Voc sempre deve garantir que entende e cumpre estes requisitos; muitas vezes, h consequncias legais caso voc no os cumpra. O exemplo acima no deve, de modo algum, ser considerado o melhor mtodo de limpar um drive de disco. No entanto, bem mais eciente que usar o comando rm, porqu quando voc apaga um arquivo usando rm, este arquivo marcado como apagado (deleted) no apaga o contedo do arquivo.
5.9.7. Implementando Quotas de Disco

O Red Hat Enterprise Linux capaz de manter registro do uso do espao em disco por usurio e por grupo atravs da utilizao das quotas de disco. A seo seguinte provm uma viso geral das funcionalidades presentes nas quotas de disco sob o Red Hat Enterprise Linux.
Captulo 5. Administrando o Armazenamento 5.9.7.1. Informaes Bsicas sobre as Quotas de Disco As quotas de disco tm as seguintes funcionalidades sob o Red Hat Enterprise Linux:

107
Implementao por sistema de arquivo Contabilidade do espao por usurio Contabilidade do espao por grupo Registro do uso do bloco de disco Registro do uso do inode do disco Limites rgidos (hard limits) Limites suaves (soft limits) Perodos de carncia (grace periods)
As sees seguintes descrevem cada funcionalidade em detalhes. 5.9.7.1.1. Implementao Por Sistema de Arquivo As quotas de disco sob o Red Hat Enterprise Linux podem ser usadas por sistema de arquivo. Em outras palavras, as quotas de disco podem ser ativadas ou desativadas para cada sistema de arquivo separadamente. Isso oferece grande exibilidade ao administrador de sistemas. Por exemplo: se o diretrio /home/ estava em seu prprio sistema de arquivo, as quotas de disco poderiam ser ativadas ali, garantindo o uso igualitrio do disco por todos os usurios. No entanto, o sistema de arquivo root poderia ser deixado sem quotas de disco, eliminando a complexidade de manter quotas de disco num sistema de arquivo que contm apenas o prprio sistema operacional. 5.9.7.1.2. Contabilidade do Espao Por Usurio As quotas de disco podem efetuar a contabilidade por usurio. Isso signica que o uso do espao por cada usurio registrado individualmente. Tambm signica que as limitaes de uso (abordadas em sees posteriores) tambm so determinadas por usurio. A exibilidade de registrar e garantir o uso do disco para cada usurio individualmente possibilita a um administrador de sistemas atribuir limites diferentes aos usurios, de acordo com suas responsabilidades e necessidades de armazenamento. 5.9.7.1.3. Contabilidade do Espao Por Grupo As quotas de disco tambm podem registrar o uso do disco por grupo. Isso ideal para aquelas empresas que utilizam os grupos como um meio de combinar os diferentes usurios num nico recurso para um projeto. Ao determinar quotas de disco para um grupo, os administradores de sistemas podem gerenciar de perto a utilizao do armazenamento, atribuindo a usurios individuais somente a quota de disco necessria para seu uso pessoal e determinando quotas maiores. 5.9.7.1.4. Registro do Uso do Bloco do Disco As quotas de disco registram o uso do bloco de disco. Como todos os dados de um sistema de arquivo so armazenados em blocos, as quotas de disco so capazes de correlacionar diretamente os arquivos criados e apagados de um sistema de arquivo com a quantidade de armazenamento que estes arquivos ocupam.
108 5.9.7.1.5. Registro do Uso do Inode de Disco
Alm de registrar o uso do bloco de disco, as quotas tambm podem registrar o uso do inode. Sob o Red Hat Enterprise Linux, os inodes so usados para armazenar vrias partes do sistema de arquivo, mas acima de tudo, os inodes guardam as informaes de cada arquivo. Consequentemente, ao registrar (e controlar) o uso do inode, possvel controlar a criao de novos arquivos. 5.9.7.1.6. Limites Rgidos Um limite rgido o nmero mximo absoluto de blocos (ou inodes) de disco que podem ser temporariamente usados por um usurio (ou grupo). Todas as tentativas de usar um bloco ou inode acima do limite rgido falharo. 5.9.7.1.7. Limites Suaves Um limite suave o nmero mximo de blocos do disco (ou inodes) que podem ser usados permanentemente por um usurio (ou grupo). O limite suave determinado abaixo do limite rgido. Isso permite aos usurios temporariamente exceder o limite suave, de modo que possam acabar o que esto fazendo e tenham tempo de observar seus arquivos e reduzir seu uso abaixo do limite suave. 5.9.7.1.8. Perodos de Carncia Conforme armado anteriormente, todo uso do disco acima do limite suave temporrio. O perodo de carncia que determina o tempo em que um usurio (ou grupo) pode extender seu uso alm de seus limites suaves e rumo a seus limites rgidos. Se um usurio continuar a usar mais que seu limite suave e o perodo de carncia expirar, no lhe ser permitido usar espao adicional at que ele (ou o grupo) tenha reduzido seu uso para uma marca abaixo do limite suave. O perodo de carncia pode ser estabelecido em segundos, minutos, horas, dias, semanas ou meses, oferecendo ao administrador de sistemas bastante liberdade para determinar quanto tempo seus usurios tero para reduzir seus usos de disco abaixo dos limites suaves.
5.9.7.2. Ativando Quotas de Disco
Nota As sees a seguir oferecem uma breve viso geral dos passos necessrios para ativar as quotas de disco sob o Red Hat Enterprise Linux. Para obter uma abordagem mais profunda deste assunto, consulte o captulo sobre quotas de disco no Guia de Administrao de Sistemas Red Hat Enterprise Linux.
Para usar as quotas de disco, voc deve ativ-las primeiro. Este processo envolve diversos passos: 1. Modicando o /etc/fstab 2. Remontando o(s) sistema(s) de arquivo 3. Executando o quotacheck
Captulo 5. Administrando o Armazenamento 4. Atribuindo quotas
109
O arquivo /etc/fstab controla a montagem de sistemas de arquivo sob o Red Hat Enterprise Linux. Como as quotas de disco so implementadas por sistema de arquivo, h duas opes usrquota e grpquota que devem ser adicionadas a este arquivo para ativar as quotas de disco. A opo usrquota ativa as quotas de disco do usurio, enquanto a opo grpquota ativa as quotas de disco do grupo. Uma ou ambas opes podem ser ativadas ao inser-las no campo de opes para o sistema de arquivo desejado. O(s) sistema(s) de arquivo afetado(s) deve(m) ento ser desmontado(s) e remontado(s) para que as opes relativas s quotas de disco tenham efeito. Em seguida, o comando quotacheck usado para criar a quota de disco e para coletar as informaes de uso corrente de arquivos j existentes. Os arquivos de quota de disco (nomeados aquota.user e aquota.group, para quotas de usurio e de grupo) contm as informaes necessrias relativas s quotas e residem no diretrio root do sistema de arquivo. O comando edquota usado para atribuir quotas de disco. Este utilitrio usa um editor de texto para exibir as informaes de quota para usurio ou grupo, especicadas como parte do comando edquota. Aqui est um exemplo:
Disk quotas for user matt (uid 500): Filesystem blocks soft /dev/md3 6618000 0 hard 0 inodes 17397 soft 0 hard 0
Isso nos mostra que o usurio matt est usando mais que 6GB de espao em disco e mais que 17.000 inodes. Nenhuma quota (suave ou rgida) foi determinada para blocos ou inodes do disco, o que signica que no h limite para o espao ou inodes em disco que este usurio pode utilizar no momento. Usando o editor de texto que apresenta as informaes de quota de disco, o administrador de sistemas pode ento modicar os limites suaves e rgidos conforme desejar:
Disk quotas for user matt (uid 500): Filesystem blocks soft /dev/md3 6618000 6900000 hard 7000000 inodes 17397 soft 0 hard 0
Neste exemplo, o usurio matt recebeu um limite suave de 6.9GB e um limite rgido de 7GB. No foram determinados limites suave ou rgido nos inodes para este usurio.
Dica O programa edquota tambm pode ser usado para determinar o perodo de carncia por sistema de arquivo, usando a opo -t.
5.9.7.3. Administrando Quotas de Disco Na realidade, h pouco trabalho administrativo para suportar as quotas de disco sob o Red Hat Enterprise Linux. Essencialmente, necessrio:

Gerar relatrios do uso do disco em intervalos regulares (e acompanhar os usurios que parecem ter problemas em administrar efetivamente seu espao alocado no disco) Garantir que as quotas de disco permaneam corretas
Criar um relatrio do uso do disco implica rodar o utilitrio repquota. Usar o comando repquota /home produz este output:
110
*** Report for user quotas on device /dev/md3 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------root -32836 0 0 4 0 0 matt -- 6618000 6900000 7000000 17397 0 0
Mais informaes sobre o repquota podem ser encontradas no Guia de Administrao de Sistemas Red Hat Enterprise Linux, no captulo sobre quotas de disco. Sempre que um sistema de arquivo no desmontado de maneira limpa (devido uma queda do sistema, por exemplo), necessrio rodar o quotacheck. No entanto, muitos administradores de sistemas recomendam rodar o quotacheck regularmente, mesmo que o sistema no tenha sofrido uma queda. O processo similar ao uso inicial do quotacheck ao ativar as quotas de disco. Aqui est um exemplo do comando quotacheck:
quotacheck -avug
A maneira mais fcil de executar o quotacheck regularmente usar o cron. A maioria dos administradores de sistemas executam o quotacheck uma vez por semana, mas pode haver motivos racionais para usar um intervalo mais longo ou mais curto, dependendo de suas condies especcas.
5.9.8. Criando Conjuntos RAID

Alm de suportar as solues RAID de hardware, o Red Hat Enterprise Linux tambm suporta o RAID de software. H duas maneiras de criar conjuntos RAID de software:

Ao instalar o Red Hat Enterprise Linux Aps o Red Hat Enterprise Linux ter sido instalado
As sees seguintes trazem uma reviso destes dois mtodos. 5.9.8.1. Ao Instalar o Red Hat Enterprise Linux Durante o processo normal de instalao do Red Hat Enterprise Linux, os conjuntos RAID podem ser criados. Isso feito durante a fase de particionamento do disco na instalao. Para comear, voc deve particionar manualmente seus drives de disco usando o Disco Druid. Primeiro, voc deve criar uma nova partio do tipo "RAID de software." Em seguida, selecione os drives de disco que comporo o conjunto RAID no campo Discos Permitidos. Continue o processo selecionando o tamanho desejado e se voc deseja que a partio seja primria. Uma vez criadas todas as parties necessrias para o(s) conjunto(s) RAID que voc deseja criar, use o boto RAID para realmente criar os conjuntos. Lhe ser apresentada uma caixa de dilogo na qual voc pode selecionar o ponto de montagem do conjunto, o tipo do sistema de arquivo, o nome do dispositivo RAID e as parties "RAID de software" nas quais este conjunto ser baseado. Uma vez criados os conjuntos desejados, o processo de instalao continua normalmente.
111
Dica Para mais informaes sobre a criao de conjuntos RAID de software durante o processo de instalao do Red Hat Enterprise Linux, consulte o Guia de Administrao de Sistemas Red Hat Enterprise Linux.
5.9.8.2. Aps o Red Hat Enterprise Linux Ser Instalado Criar um conjunto RAID aps a instalao do Red Hat Enterprise Linux um pouco mais complexo. Assim como a adio de qualquer tipo de armazenamento de disco, necessrio primeiro instalar o hardware e congur-lo corretamente. O particionamento um pouco diferente para o RAID do que para drives de disco. Ao invs de selecionar um tipo de partio "Linux" (tipo 83) ou "Linux swap" (tipo 82), todas as parties que faro parte do conjunto RAID devem ser do tipo "Linux raid auto" (tipo fd). Em seguida, necessrio criar o arquivo /etc/raidtab. Esse arquivo responsvel pela congurao apropriada de todos os conjuntos RAID no seu sistema. O formato do arquivo (documentado na pgina man raidtab(5)) relativamente simples. Eis um exemplo de entrada /etc/raidtab para um conjunto RAID 1:
raiddev /dev/md0 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 nr-spare-disks 0 device /dev/hda2 raid-disk 0 device /dev/hdc2 raid-disk 1
Algumas das sees mais notveis desta seo so:

raiddev
Exibe o nome do arquivo do dispositivo para o conjunto RAID 12 Dene o nvel do RAID a ser usado por este conjunto Indica quantas parties fsicas de disco devem fazer parte deste conjunto
raid-level
nr-raid-disks nr-spare-disks
O RAID de software sob o Red Hat Enterprise Linux permite a denio de uma ou mais parties reservas; estas parties podem tomar o lugar de um disco com mau funcionamento automaticamente Juntos, denem as parties fsicas do disco que compoem o conjunto
device, raid-disk
RAID
Em seguida, necessrio realmente criar o conjunto RAID. Isso feito no programa mkraid. Usando nosso arquivo /etc/raidtab exemplo, podemos criar o conjunto RAID /dev/md0 com o seguinte comando:
mkraid /dev/md0
O conjunto RAID /dev/md0 agora est pronto para ser formatado e montado. Neste ponto, o processo no diferente de formatar e montar um nico drive de disco.
12. Note que, como o conjunto RAID composto de espao particionado em disco, o nome do arquivo do dispositivo de um conjunto RAID no reete nenhuma informao no nvel da partio.
112
5.9.9. Administrao Diria de Conjuntos RAID

H pouco a ser feito para manter um conjunto RAID operante. Contanto que no ocorram problemas de hardware, o conjunto deve funcionar como se fosse um nico drive de disco fsico. No entanto, assim como um administrador de sistemas deve vericar periodicamente o status de todos os drives de disco do sistema, o status dos conjuntos RAID tambm deve ser vericado. 5.9.9.1. Vericando o Status do Conjunto Com /proc/mdstat O arquivo /proc/mdstat a maneira mais fcil de vericar o status de todos os conjuntos RAID de um determinado sistema. Aqui est uma amostra do mdstat (visualize com o comando cat /proc/mdstat):
Personalities : [raid1] read_ahead 1024 sectors md1 : active raid1 hda3[0] hdc3[1] 522048 blocks [2/2] [UU] md0 : active raid1 hda2[0] hdc2[1] 4192896 blocks [2/2] [UU] md2 : active raid1 hda1[0] hdc1[1] 128384 blocks [2/2] [UU] unused devices: none
Neste sistema, h trs conjuntos RAID (todos RAID 1). Cada conjunto RAID tem sua prpria seo no /proc/mdstat e contm as seguntes informaes:

O nome do dispositivo do conjunto RAID (excluindo a parte /dev/) O status do conjunto RAID O nvel RAID do conjunto RAID As parties fsicas que formam o conjunto (seguidas pelo nmero da unidade do conjunto da partio) O tamanho do conjunto O nmero de dispositivos conugrados versus o nmero de dispositivos operantes no conjunto O status de cada dispositivo congurado do conjunto (U signica que o dispositivo est OK e _ indica que o dispositivo falhou)
5.9.9.2. Recriando um conjunto RAID com o raidhotadd Caso o /proc/mdstat indique que h um problema com um dos conjuntos RAID, o utilitrio raidhotadd deve ser usado para recriar o conjunto. Aqui esto os passos a seguir: 1. Determinar qual drive de disco contm a partio falha 2. Corrigir o problema que causou a falha (provavelmente substituindo o drive) 3. Particionar o novo drive para que as parties contidas neste sejam idnticas quelas do(s) outro(s) drive(s) do conjunto
raidhotadd raid-device disk-partition
5. Monitorar o /proc/mdstat para observar a recriao ocorrendo

4. Atribuir o seguinte comando:
113
Dica Aqui est um comando que pode ser usado para observar a recriao conforme ocorre:
watch -n1 cat /proc/mdstat
Esse comando exibe o contedo do /proc/mdstat, atualizando-o a cada segundo
5.9.10. Administrao de Volume Lgico (Logical Volume Management)

O Red Hat Enterprise Linux inclui suporte ao LVM. O LVM pode ser congurado durante a instalao do Red Hat Enterprise Linux, ou aps a instalao. O LVM sob o Red Hat Enterprise Linux suporta o agrupamento de armazenamento fsico, redimensionamento de volume lgico e a migrao de dados de um determinado volume fsico. Para mais informaes sobre o LVM, consulte o Guia de Administrao de Sistemas Red Hat Enterprise Linux.

Esta seo inclui diversos recursos que podem ser usados para aprender mais sobre tecnologias de armazenamento e sua relao com o Red Hat Enterprise Linux.

Os recursos seguintes so instalados no decorrer de uma tpica instalao do Red Hat Enterprise Linux e podem ajud-lo a aprender mais sobre o assunto abordado neste captulo.

Pgina man exports(5) Aprenda mais sobre o formato do arquivo de congurao do NFS. Pgina man fstab(5) Aprenda mais sobre o formato do arquivo de congurao das informaes do sistema de arquivo. Pgina man swapoff(8) Aprenda a desativar parties swap. Pina man df(1) Aprenda a visualizar o uso do espao em disco em sistemas de arquivo montados. Pgina man fdisk(8) Aprenda sobre este programa de manuteno da tabela de parties. Pginas man mkfs(8) e mke2fs(8) Aprenda sobre estes utilitrios de criao de sistemas de arquivo. Pgina man badblocks(8) Aprenda como vericar os blocos ruins de um dispositivo. Pgina man quotacheck(8) Aprenda a vericar o uso de blocos e inodes por usurios e grupos, e opcionalmente criar arquivos de quota de disco. Pgina man edquota(8) Aprenda sobre este utilitrio de manuteno das quotas de disco. Pgina man repquota(8) Aprenda sobre este utilitrio de relatrio sobre quotas de disco. Pgina man raidtab(5) Aprenda sobre o formato do arquivo de congurao do RAID de software. Pgina man mkraid(8) Aprenda mais sobre este utilitrio de criao do conjunto RAID de software.
114
Pgina man mdadm(8) Aprenda sobre este utilitrio de administrao do conjunto RAID de software. Pgina man lvm(8) Aprenda sobre a Administrao do Volume Lgico (Logical Volume Management, LVM). Pgina man devlabel(8) Aprenda sobre o acesso ao dispositivo de armazenamento persistente.
5.10.2. Sites teis

http://www.pcguide.com/ Um bom site para todo tipo de informao sobre diversas tecnologias de armazenamento. http://www.tldp.org/ O Projeto de Documentao do Linux tem HOWTOs e mini-HOWTOs que oferecem uma boa viso geral das tecnologias de armazenamento e seu relacionamento com o Linux.

Os livros seguintes abordam diversas questes relacionadas ao armazenamento e so bons recursos para administradores de sistemas Red Hat Enterprise Linux.
O Guia de Instalao do Red Hat Enterprise Linux; Red Hat, Inc. Contm instrues para particionar discos rgidos durante a instalao do Red Hat Enterprise Linux assim como uma viso geral das parties de disco. O Guia de Referncia do Red Hat Enterprise Linux; Red Hat, Inc. Contm informaes detalhadas sobre a estrutura de diretrios usada no Red Hat Enterprise Linux e uma viso geral do NFS. O Guia de Administrao de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. Inclui captulos sobre sistemas de arquivo, RAID, LVM, devlabel, particionamento, quotas de disco, NFS e Samba. Linux System Administration: A Users Guide de Marcel Gagne; Addison Wesley Professional Contm informaes sobre permisses de usurio e grupo, sistemas de arquivo e quotas de disco, NFS e Samba. Linux Performance Tuning and Capacity Planning de Jason R. Fink e Matthew D. Sherer; Sams Contm informaes sobre o desempenho do disco, RAID e NFS. Linux Administration Handbook de Evi Nemeth, Garth Snyder e Trent R. Hein; Prentice Hall Contm informaes sobre sistemas de arquivo, atividades dos drives de disco, NFS e Samba.
Captulo 6.
Administrando Contas de Usurio e Acesso a Recursos
Administrar contas de usurio e grupos uma parte essencial da administrao de sistemas em uma empresa. Para execut-la de maneira ecaz, um bom administrador de sistemas deve primeiramente entender o que so contas de usurio, grupos e como eles funcionam. A principal razo da existncia de contas de usurio a vericao da identidade de cada indivduo usando um computador. Uma razo secundria (mas importante) permitir a personalizao de recursos e privilgios de acesso por indivduo. Os recursos podem incluir arquivos, diretrios e dispositivos. Controlar o acesso a estes recursos uma grande parte da rotina diria de um administrador de sistemas. Frequentemente o acesso a um recurso controlado por grupos. Grupos so formaes lgicas que podem ser usadas para agrupar contas de usurios para um propsito comum. Por exemplo: se uma empresa tem diversos administradores de sistemas, eles podem ser alocados em um grupos de administradores de sistemas. O grupo, ento, pode receber permisses para acessar recursos sensveis do sistema. Desta maneira, os grupos podem ser uma ferramenta poderosa para administrar recursos e acesso. As sees seguintes abordam contas de usurio e grupos com mais detalhes.
6.1. Administrando Contas de Usurio

Como mencionado anteriormente, as contas de usurio so o mtodo atravs do qual um indivduo identicado e autenticado no sistema. As contas de usurio tm diversos componentes. Primeiro, h um nome de usurio (username). Em seguida, a senha (password), seguida pelas informaes de controle de acesso. As sees seguintes exploram cada um destes componentes com mais detalhes.
6.1.1. O Nome de Usurio

Do ponto de vista do sistema, o nome de usurio a resposta pergunta: "quem voc?" Como tal, o nome de usurio tem um requisito principal deve ser nico. Em outras palavras, cada usurio deve ter um nome de usurio diferente de todos os outros nomes de usurios no sistema. Em funo deste requisito, vital determinar com antecedncia como os nomes de usurio devem ser criados. Caso contrrio, voc pode se ver obrigado a intervir cada vez que um novo usurio requisitar uma conta. Voc precisa de uma conveno de nomenclatura para suas contas de usurio. 6.1.1.1. Convenes de Nomenclatura Ao criar uma conveno de nomenclatura para nomes de usurio, voc pode evitar diversos problemas. Ao invs de inventar nomes ao longo do curso (e enfrentar a diculdade de inventar um nome razovel toda vez), voc antecipa seu trabalho e impe uma conveno a ser usada para todas as contas de usurio subsequentes. Sua conveno de nomenclatura pode ser muito simples ou ento, apenas sua descrio, pode ter diversas pginas documentadas. A natureza da sua conveno de nomenclatura deve considerar diversos fatores:

O tamanho de sua empresa A estrutura de sua empresa
116 A natureza de sua empresa
Captulo 6. Administrando Contas de Usurio e Acesso a Recursos
O tamanho de sua empresa importa, pois dita quantos usurios sua conveno de nomenclatura deve suportar. Por exemplo: numa micro empresa pode ser possvel que todos usem seu primeiro nome. Para uma empresa bem maior, essa conveno de nomenclatura no funcionar. A estrutura de uma empresa tambm pode inuenciar a conveno de nomenclatura mais apropriada. Em empresas com estruturas rgidas, pode ser apropriado incluir elementos da estrutura na conveno de nomenclatura. Por exemplo: voc pode incluir os cdigos dos departamentos de sua empresa como parte de cada nome de usurio. A natureza da sua empresa tambm pode signicar que algumas convenes de nomenclatura so mais apropriadas que outras. Um empresa que lida com dados altamente ordenados pode escolher uma conveno de nomenclatura que elimina quaisquer laos de identicao pessoal entre o indivduo e seu nome. Numa empresa deste tipo, o nome de usurio Joo da Silva poderia ser LUH3417. Aqui esto algumas convenes de nomenclatura que outras empresas utilizaram:

Primeiro nome (joo, paulo, jorge, etc.) ltimo nome (silva, pereira, pontes, etc.) Primeira inicial, seguida do ltimo nome (jsilva, ppereira, jpontes, etc.) ltimo nome, seguido do cdigo do departamento (silva029, pereira454, pontes191, etc.)
Dica Ateno: se a sua conveno de nomenclatura inclui a juno de dados diferentes para formar um nome de usurio, existe a possibilidade do resultado ser hilrio ou ofensivo. Portanto, mesmo se voc tiver automatizado a criao dos nomes de usurio, aconselhvel ter algum tipo de reviso no processo.
As convenes de nomenclatura abordadas aqui tm em comum a possibilidade de existirem dois indivduos que, de acordo com a conveno, devem ter os mesmos nomes de usurio. Isto conhecido como uma coliso. Como cada nome de usurio deve ser nico, necessrio resolver a questo das colises. A seo seguinte aborda este assunto. 6.1.1.1.1. Resolvendo as Colises Colises ocorrem de fato no importa o quanto voc tenta, ocasionalmente voc dever resolvlas. Voc deve planejar como lidar com as colises em sua conveno de nomenclatura. H diversas maneiras de fazer isso:

Adicionar nmeros sequenciais ao nome de usurio colidido (silva, silva1, silva2, etc.) Adicionar dados especcos do usurio ao nome de usurio colidido (silva, esilva, eksilva, etc.) Adicionar informaes da empresa ao nome de usurio colidido (silva, silva029, silva454, etc.)
Ter algum mtodo de resolver colises uma parte necessria de qualquer conveno de nomenclatura. No entanto, esta diculta que algum de fora da empresa determine o nome de usurio de um indivduo corretamente. Portanto, a desvantagem da maioria das convenes de nomenclatura a maior probabilidade do envio incorreto de e-mails.
Captulo 6. Administrando Contas de Usurio e Acesso a Recursos 6.1.1.2. Resolvendo Alteraes de Nome
117
Se a sua empresa utiliza uma conveno de nomenclatura baseada no nome de cada usurio, certeza que voc ter que lidar com alteraes de nome em algum momento. Mesmo que o nome verdadeiro de uma pessoa no mude, ser necessrio alterar alguns nomes de usurios de tempos em tempos. As razes podem variar; desde o usurio no estar satisfeito com seu nome de usurio at o fato do usurio ser um gerente snior da empresa e querer usar sua inuncia para obter um nome de usurio "mais apropriado". Independente da razo, h diversas questes a considerar ao alterar um nome de usurio:

Efetue a alterao em todos os sistemas afetados Mantenha quaisquer identicaes do usurio constantes Altere a propriedade (ownership) de todos os arquivos e outros recursos especcos do usurio (se necessrio) Resolva questes relacionadas a e-mail
Primeiramente, importante garantir que o novo nome de usurio seja propagado para todos os sistemas nos quais o nome de usurio original foi usado. Caso contrrio, qualquer funo do sistema operacional baseada no nome do usurio pode funcionar em alguns sistemas e no funcionar em outros. Determinados sistemas operacionais utilizam tcnicas de controle de acesso baseadas em nomes de usurio; tais sistemas tm uma vulnerabilidade relacionada a problemas originados a partir de um nome de usurio alterado. Muitos sistemas operacionais utilizam alguma espcie nmero de identicao do usurio para a maioria do processamento especco ao usurio. Para minimizar os problemas oriundos da alterao de um nome de usurio, tente manter este nmero de identicao constante entre os nomes do usurio novo e velho. Caso contrrio, provvel ter um cenrio no qual o usurio no consegue mais acessar arquivos e outros recursos que previamente possua sob o nome de usurio original. Se o nmero de identicao do usurio deve ser alterado, necessrio alterar a propriedade (ownership) de todos os arquivos e recursos especcos ao usurio para reetir a nova identicao do usurio. Este pode ser um processo propenso a erros, j que parece que sempre h algo esquecido em algum canto que acaba sendo negligenciado. As questes relacionadas a e-mails provavelmente representam a rea mais difcil para uma alterao de nome de usurio. A razo disto que, a no ser que sejam tomadas aes para contra-atacar, os e-mails destinados ao nome de usurio velho no sero entregues ao nome de usurio novo. Infelizmente, as questes que permeam o impacto das alteraes de nome de usurio em e-mails so multi-dimensionais. No mnimo, uma alterao de nome de usurio signica que as pessoas no sabem mais o nome de usurio correto da pessoa. primeira vista, este no parece ser um grande problema noticar a todos de sua empresa sobre a alterao. Mas, e quanto s pessoas fora da empresa que enviaram e-mails para esta pessoa? Como elas devem ser noticadas? E as listas de discusso (internas e externas)? Como elas podem ser atualizadas? No h uma resposta simples para estas questes. A melhor resposta talvez seja criar um codenome de e-mail, de modo que todos os e-mails enviados ao nome de usurio velho sejam automaticamente encaminhados ao novo nome de usurio. O usurio pode ser aconselhado a alertar todos que enviam e-mails para ele, que seu nome de usurio foi alterado. Com o passar do tempo, menos e-mails sero entregues usando o codenome; eventualmente o codenome pode ser removido. Enquanto o uso de codenome, de alguma maneira, perpetua uma suposio incorreta (de que o usurio agora conhecido como esilva ainda conhecido como jpontes), a nica maneira de garantir que o e-mail seja entregue pessoa correta.
118
Importante Se voc usar codenome de e-mail, certique-se de executar todos os passos necessrios para proteger o nome de usurio velho de re-utilizao. Se voc no zer isso e um novo usurio receber o nome de usurio velho, a entrega de e-mails (para ambos, o usurio original ou o novo) pode ser interrompida. A razo exata da interrupo depende de como a entrega de e-mails implementada em seu sistema operacional, mas os dois sintomas mais provveis so:
O novo usurio nunca recebe nenhum e-mail todos so entregues para o usurio original. O usurio original para de receber e-mails repentinamente todos so entregues para o novo
usurio.
6.1.2. Senhas
Se o nome de usurio oferece uma resposta para a pergunta "quem voc?", a senha a resposta para o pedido que segue inevitavelmente: "Prove!" Em termos mais formais, uma senha oferece um meio de provar a autenticidade da armao de uma pessoa ser o usurio indicado pelo nome de usurio. A ecincia de um esquema de autenticao com senha baseia-se em diversos aspectos da senha:

A discrio de senha A resistncia da senha em ser descoberta A resistncia da senha a um ataque brute-force
As senhas que atendem estes requisitos so chamadas de fortes, enquanto aquelas que no atendem um ou mais requisitos so chamadas de fracas. importante criar senhas fortes para a segurana da empresa, j que este tipo de senha tem menor probabilidade de ser descoberta. H duas opes para reforar o uso de senhas fortes:

O administrador de sistemas pode criar senhas para todos os usurios. O administrador de sistemas pode deixar que os usurios criem suas prprias senhas, enquanto verica se as senhas so aceitveis.
Criar senhas para todos os usurios garante que sejam fortes, mas torna-se uma tarefa desanimadora conforme a empresa cresce. Tambm aumenta o risco dos usurios anotarem suas senhas. Por estes motivos, a maioria dos administradores de sistemas preferem que seus usurios criem suas prprias senhas. Entretanto, um bom administrador de sistemas executa alguns passos para garantir que as senhas sejam fortes. Para obter instrues sobre a criao de senhas fortes, veja o captulo intitulado Segurana da Estao de Trabalho no Guia de Segurana do Red Hat Enterprise Linux. A necessidade de manter as senhas secretas deve ser uma parte intrnseca da mentalidade de todo administrador de sistemas. No entanto, este aspecto frequentemente esquecido por muitos usurios. De fato, muitos usurios no entendem a diferena entre nomes de usurios e senhas. Portanto, vital oferecer alguma forma de educao neste aspecto para os usurios, para que eles entendam que suas senhas devem ser to bem guardadas quanto seus holeriths. As senhas devem ser o mais difcil possvel de serem descobertas. Uma senha forte aquela que o atacante no consegue descobrir, mesmo que ele tambm conhea o usurio.
119
Um ataque brute-force a uma senha envolve tentar metodicamente (geralmente atravs de um programa conhecido como password-cracker) todas as combinaes possveis de caracteres na esperana de que a senha correta seja eventualmente encontrada. Uma senha forte deve ser construda de maneira a tornar o nmero de senhas a testar muito grande, forando o atacante a levar bastante tempo na procura da senha. As senhas fortes e fracas so abordadas detalhadamente nas sees seguintes. 6.1.2.1. Senhas Fracas Como explanado anteriormente, uma senha fraca falha em um destes trs testes:

secreta resistente a ser descoberta resistente a um ataque brute-force
As sees seguintes mostram como as senhas podem ser fracas. 6.1.2.1.1. Senhas Curtas Um senha curta (breve) fraca porque mais suscetvel a um ataque brute-force. Para ilustrar isto, considere a tabela seguinte, onde o nmero de senhas potenciais que devem ser testadas num ataque brute-force exibido. (Assume-se que as senhas consistem somente de letras em caixa baixa.) Tamanho da Senha 1 2 3 4 5 6 Senhas Potenciais 26 676 17.576 456.976 11.881.376 308.915.776
Tabela 6-1. Tamanho da Senha Versus o Nmero de Senhas Potenciais Como voc pode ver, o nmero de senhas possveis aumenta dramaticamente conforme seu tamanho aumenta.
Nota Apesar desta tabela terminar com seis caracteres, isto no uma armao de que senhas de seis caracteres sejam longas o suciente para uma boa segurana. Em geral, quanto mais longa a senha, melhor.
6.1.2.1.2. Conjunto de Caracteres Limitado O nmero de caracteres diferentes que podem compor uma senha tem um alto impacto na habilidade de um atacante conduzir um ataque brute-force. Por exemplo: ao invs de 26 caracteres diferentes que podem ser usados numa senha composta apenas de caixa baixa, por que no usamos tambm dgitos? Isto signica que cada caractere de uma senha pode ser um dos 36 caracteres ao invs de apenas 26.
120
No caso de uma senha de seis caracteres, isto aumenta o nmero de senhas possveis de 308.915.776 para 2.176.782.336. Ainda h mais que pode ser feito. Se ns tambm incluirmos caixa alta e baixa nas senhas alfanumricas (para aqueles sistemas operacionais que as suportam), o nmero de senhas possveis de seis caracateres aumenta para 56.800.235.584. Adicionando outros caracteres (tais como pontuao) aumenta ainda mais o nmero de senhas possveis, tornando ainda mais difcil um ataque brute-force. No entanto, tenha em mente que nem todo ataque contra uma senha um ataque brute-force. As sees seguintes descrevem outros atributos que podem formar uma senha fraca. 6.1.2.1.3. Palavras Reconhecveis Muitos ataques contra senhas so baseados no fato da maioria das pessoas se sentirem mais confortveis com senhas que possam lembrar. E, para a maioria das pessoas as senhas memorveis so aquelas que contm palavras. Consequentemente, a maioria dos ataques a senhas so baseados no dicionrio. Em outras palavras, o atacante utiliza dicionrios de palavras para tentar encontrar a palavra ou palavras que formam uma senha.
Nota Muitos programas de ataque a senhas baseadas em dicionrio usam dicionrios de mltiplos idiomas. Consequentemente, voc no pode acreditar que tem uma senha forte apenas porque utilizou palavras no inglesas na sua senha.
6.1.2.1.4. Informaes Pessoais Senhas que contm informaes pessoais (o nome ou data de aniversrio de uma pessoa querida, de um animal de estimao ou um nmero de identicao pessoal) podem ou no ser pegas por um ataque a senha baseada em dicionrio. No entanto, se o atacante te conhece pessoalmente (ou est sucientemente motivado a pesquisar sua vida pessoal), ele pode ser capaz de adivinhar sua senha com nenhuma ou pouca diculdade. Alm dos dicionrios, muitos crackers de senhas incluem nomes comuns, datas e outras informaes deste tipo em suas procuras por senhas. Portanto, mesmo que o atacante no saiba que o nome do seu cachorro Duque, ainda podem descobrir que sua senha "meucaoduque" com um bom cracker de senhas. 6.1.2.1.5. Truques com Palavras Simples Usar quaisquer das informaes abordadas anteriormente a base de uma senha, mas inverter a ordem dos caracteres no torna uma senha fraca numa senha forte. Muitos crackers de senhas executam este tipo de truques em senhas possveis. Isto inclui substituir determinados nmeros por letras em palavras comuns. Aqui esto alguns exemplos:

drowssaPdaB1 R3allyP00r
Captulo 6. Administrando Contas de Usurio e Acesso a Recursos 6.1.2.1.6. A Mesma Senha para Mltiplos Sistemas
121
Mesmo que voc tenha uma senha forte, uma m idia usar exatamente a mesma senha em mais de um sistema. Obviamente, h pouco a ser feito se os sistemas esto congurados para usar algum tipo de servidor de autenticao central, mas em todos os outros casos, deve-se usar senhas diferentes para cada sistema. 6.1.2.1.7. Senhas no Papel Uma outra maneira de enfraquecer uma senha anot-la. Ao escrever uma senha num papel, voc no tem mais um problema de discrio, mas sim um problema de segurana fsica agora voc deve proteger um pedao de papel. Consequentemente, anotar uma senha nunca uma boa idia. No entanto, algumas empresas tm uma necessidade legtima de senhas escritas. Por exemplo: algumas empresas tm senhas escritas como parte do procedimento de recuperao aps a perda de funcionrios chave (tais como administradores de sistemas). Nestes casos, o papel contendo as senhas armazenado num local protegido sicamente, que requer a cooperao de diversas pessoas para acessar o papel. Passagens com vrios cadeados e cofres de banco so frequentemente usados. Qualquer empresa que utiliza este mtodo de armazenar senhas para emergncias deve estar ciente de que a existncia de senhas escritas adiciona um elemento de risco segurana de seus sistemas. No importa o quo protegidas estejam as senhas escritas, principalmente se de conhecimento geral que as senhas esto escritas (e onde esto armazenadas). Infelizmente, as senhas escritas frequentemente no fazem parte de um plano de recuperao e no so armazenadas com segurana, mas so senhas de usurios comuns, armazenadas nos seguintes locais:

Na gaveta da mesa (trancada ou no) Em baixo de um teclado Numa carteira Anexo ao lado de um monitor
Nenhum destes locais so apropriados para armazenar uma senha escrita.
6.1.2.2. Senhas Fortes Ns j vimos como se parecem as senhas fracas; as sees seguintes abordam caractersticas presentes em todas as senhas fortes 6.1.2.2.1. Senhas Mais Longas Quanto mais longa a senha, menor a possibilidade de um ataque brute-force ser bem sucedido. Consequentemente, se o seu sistema operacional a suporta, dena um tamanho mnimo relativamente grande para as senhas de seus usurios. 6.1.2.2.2. Conjunto de Caracteres Expandido Estimule o uso de caixas alta e baixa, senhas alfa-numricas e recomende fortemente a adio de pelo menos um caracter no alfa-numrico em todas as senhas:

t1Te-Bf,te Lb@lbhom
122 6.1.2.2.3. Memorvel
Uma senha forte se pode ser lembrada. Entretanto, ser memorvel e de fcil descoberta frequentemente andam juntas. Sendo assim, oferea sua comunidade de usurios algumas dicas para a criao de senhas memorveis que no podem ser facilmente descobertas. Por exemplo: pense numa frase ou ditado favorito e use as primeiras letras de cada palavra como o ponto de partida para a criao de uma nova senha. O resultado memorvel (porque a frase na qual baseia-se memorvel), mas no contm palavras.
Nota Tenha em mente que usar apenas as primeiras letras de cada palavra de frase no o suciente para criar uma senha forte. Certique-se de sempre aumentar o conjunto de caracteres da senha, incluindo caracteres alfa-numricos em caixas alta e baixa e, pelo menos, um caracter especial tambm.
6.1.2.3. Expirao de Senhas Se for possvel, implemente a expirao de senhas na sua empresa. A expirao de senhas uma funcionalidade (disponvel em diversos sistemas operacionais) que dene limites de tempo para uma senha ser considerada vlida. No m da vida de uma senha, o usurio deve inserir uma nova senha, que pode ser usada at que (esta tambm) expire. A principal questo relacionada expirao de senhas vivenciada por muitos administradores de sistemas o tempo de vida da senha. Quo longo deve ser? H duas questes cruciais e opostas relacionadas expirao de senhas:

Convenincia do usurio Segurana
Em um extremo, o tempo de vida de uma senha de 99 anos apresentaria pouca (ou nenhuma) inconvenincia para o usurio. No entanto, ofereceria muito pouca (ou nenhuma) melhoria na segurana. No outro extremo, uma senha com tempo de vida de 99 minutos seria uma grande inconvenincia para seus usurios. Entretanto, a segurana seria bem maior. A idia encontrar um equilbrio entre a convenincia requerida por seus usurios e a necessidade de segurana de sua empresa. Para a maioria das empresas, o tempo de vida da senha no intervalo de semanas a meses o mais comum.
6.1.3. Informaes de Controle de Acesso

Juntamente ao nome de usurio e senha, as contas de usurio contm informaes de controle de acesso. Estas informaes tm formatos diferentes de acordo com o sistema operacional. No entanto, os tipos de informao geralmente incluem:

Identicao especca do usurio para todo o sistema Identicao especca do grupo para todo o sistema Listas de grupos/funcionalidades adicionais s quais o usurio pertence
123
Informaes de acesso default a serem aplicadas para todos os arquivos e recursos criados pelo usurio
Em algumas empresas, as informaes de controle de acesso do usurio talvez nunca precisem ser alteradas. Isto mais frequente nos casos com standalone e estaes de trabalho pessoais, por exemplo. Outras empresas, especialmente aquelas que utilizam extensivamente o compartilhamento de recursos entre diferentes grupos de usurios atravs da rede, requerem que as informaes de controle de acesso do usurio sejam bastante modicadas. A carga de trabalho necessria para manter corretamente as informaes de controle de acesso do usurio varia de acordo com a escala do uso que sua empresa faz das funcionalidades de controle de acesso do sistema operacional. Apesar de no ser ruim conar veementemente nestas funcionalidades (talvez seja inevitvel), signica que o ambiente de seu sistema pode precisar de um esforo maior para ser mantido, e que todas as contas de usurio tm maior probabilidade de serem conguradas incorretamente. Consequentemente, se sua empresa requer este tipo de ambiente, voc deve certicar-se de documentar exatamente os passos necessrios para criar e congurar corretamente a conta de usurio. De fato, se h tipos diferentes de contas de usurio, voc deve documentar cada uma delas (como criar uma nova conta de usurio da rea nanceira, da rea de operaes, etc.).
6.1.4. Administrando Contas e Acesso a Recursos no Dia-a-Dia

Como diz o velho ditado: a nica constante a mudana. E no diferente ao lidar com sua comunidade de usurios. Pessoas vm e vo, mudam de um conjunto de responsabilidades para outro. Sendo assim, administradores de sistemas devem ser capazes de responder s mudanas, muito comuns no dia-a-dia das empresas. 6.1.4.1. Novas Contrataes Quando uma nova pessoa contratada pela empresa, normalmente recebe acesso a vrios recursos (de acordo com suas responsabilidades). Provavelmente, ela recebe uma mesa para trabalhar, um aparelho de telefone e uma chave da porta principal. Talvez ela tambm receba acesso a um ou mais computadores de sua empresa. Como administrador de sistemas, sua responsabilidade executar esta tarefa rpida e apropriadamente. Como voc deve fazer isso? Antes de qualquer coisa, voc deve estar ciente da chegada desta pessoa. Isto feito de maneiras diferentes em empresas diversas. Aqui esto algumas possibilidades:

Crie um processo no qual o departamento de recursos humanos de sua empresa te notica a chegada de um novo funcionrio. Crie um formulrio a ser preenchido pelo supervisor do novo funcionrio e usado para requerer uma nova conta.
Empresas diferentes requerem tticas diferentes. Independentemente de como feito, vital que voc tenha um processo altamente convel que possa alert-lo sobre qualquer tarefa relacionada a contas a ser executada. 6.1.4.2. Desligamentos fato que algumas pessoas deixaro sua empresa. s vezes, isto ocorre sob circunstncias felizes e outras vezes no. Em ambos os casos, vital que voc seja noticado da situao, para que possa executar as aes apropriadas. No mnimo, as aes apropriadas incluem:
124
Desabilitar o acesso do usurio a todos os sistemas e recursos relacionados (geralmente alterando/bloqueando a senha do usurio) Fazer um backup dos arquivos do usurio, caso contenham alguma informao futuramente necessria Coordenar o acesso aos arquivos do usurio junto ao seu gerente
A prioridade principal proteger seus sistemas contra o funcionrio recm-desligado. Isto importante principalmente se o usurio foi desligado sob condies que o faam sentir-se prejudicado pela empresa. Entretanto, mesmo se as condies no forem to ruins, do interesse de sua empresa que voc desabilite o acesso desta pessoa de maneira rpida e convel. Isto indica a necessidade de um processo que te alerte sobre todos os desligamentos de preferncia, at antes do desligamento ocorrer. Sendo assim, aconselhvel voc trabalhar junto ao departamento de recursos humanos de sua empresa para garantir que seja alertado sobre futuros desligamentos.
Dica Quando voc enfrentar "lock-downs" do sistema em virtude de desligamentos, importante agir rapidamente. Se o lock-down ocorrer aps terminar o processo de desligamento, existe a possibilidade de acesso no-autorizado do funcionrio recm-desligado. Por outro lado, se o lock-down ocorrer antes do incio do processo de desligamento, pode alertar o funcionrio sobre seu possvel desligamento e dicultar o processo para todas as partes envolvidas. O processo de desligamento geralmente iniciado numa reunio entre o funcionrio a ser desligado, seu gerente e um representante do departamento de recursos humanos da empresa. Sendo assim, estabelecer um processo que te alerte sobre o desligamento quando esta reunio comear, garante que o lock-down seja feito oportunamente.
Aps desabilitar o acesso, hora de fazer uma cpia backup dos arquivos do funcionrio recmdesligado. Este backup pode ser parte do padro de backups de sua empresa, ou pode ser um procedimento de backup dedicado a contas velhas de usurios. A maneira mais apropriada de lidar com backups abrange regulamentao de reteno, preservar evidncias nos casos de desligamentos atravs de processos jurdicos e outros. Em todos os casos, bom fazer o backup j que o prximo passo (acesso do gerente aos arquivos do funcionrio recm-desligado) pode resultar acidentalmente na remoo de arquivos. Nestas circunstncias, ter um backup possibilita recuperar os arquivos facilmente, facilitando o processo para o gerente e para voc. Neste ponto, voc deve determinar qual tipo de acesso o gerente do funcionrio recm-desligado deve ter aos arquivos. Dependendo da empresa e da natureza das responsabilidades do ex-funcionrio, pode no ser necessrio nenhum acesso, ou ento acesso a tudo. Se o ex-funcionrio usou seus sistemas para algo alm de e-mails ocasionais, provvel que o gerente tenha que examinar os arquivos, determinar o que deve ser guardado e o que deve ser descartado. Ao trmino deste processo, ao menos alguns destes arquivos devem ser dados pessoa ou pessoas assumindo as responsabilidades do ex-funcionrio. Talvez sua ajuda seja necessria neste ltimo passo do processo, ou talvez o gerente possa resolv-lo sozinho. Tudo depende dos arquivos e da natureza do trabalho de sua empresa. 6.1.4.3. Alteraes de Funo Responder aos pedidos de criao de contas para novos usurios e lidar com a sequncia de eventos necessria para bloquear (lock-down) uma conta quando a pessoa desligada so processos relativamente simples. No entanto, no to simples quando as responsabilidades de uma pessoa so alteradas dentro da empresa. s vezes, a pessoa pode precisar de alteraes em sua conta, outras vezes no.
125
Haver ao menos trs pessoas envolvidas para garantir que a conta do usurio seja recongurada corretamente para reetir suas novas responsabilidades:

Voc O gerente original do usurio O novo gerente do usurio
Dentre vocs trs, deve ser possvel determinar o que deve ser feito para encerrar de forma clara as responsabilidades velhas do usurio e as aes para preparar a conta do usurio para suas novas responsabilidades. Sob vrios aspectos, este processo pode ser equiparado a encerrar uma conta de usurio existente e criar uma nova conta. De fato, algumas empresas fazem isto para todas as mudanas de responsabilidade. Entretanto, mais provvel que a conta do usurio seja mantida e alterada apropriadamente para suportar suas novas responsabilidades. Esta ttica signica que voc precisa rever cuidadosamente a conta para garantir que tenha somente aqueles recursos e privilgios apropriados s novas responsabilidades da pessoa. Para complicar um pouco mais a situao, frequentemente existe um perodo de transio, no qual o usurio executa tarefas relacionadas aos dois conjuntos de responsabilidades. neste ponto que os gerentes antigo e novo do usurio podem ajud-lo, oferecendo-lhe um prazo para este perodo de transio.
6.2. Administrando Recursos do Usurio

Criar contas de usurio somente uma parte do trabalho de um administrador de sistemas. A administrao dos recursos dos usurios tambm essencial. Sendo assim, devemos considerar trs pontos:

Quem pode acessar os dados compartilhados Onde os usurios acessam estes dados Quais so as barreiras para evitar o abuso de recursos
As sees seguintes trazem uma breve reviso destes tpicos.
6.2.1. Quem Pode Acessar Dados Compartilhados

O acesso de um usurio a uma determinada aplicao, arquivo ou diretrio determinado pelas permisses dadas aplicao, ao arquivo ou ao diretrio. Alm disso, geralmente til conceder permisses diferentes a categorias diferentes de usurios. Por exemplo: o armazenamento temporrio compartilhado deve ser capaz de evitar remoes acidentais (ou malcas) dos arquivos de um usurio por outros usurios, enquanto deve permitir acesso completo ao proprietrio (owner). Um outro exemplo o acesso atribudo ao diretrio home de um usurio. Somente o proprietrio (owner) do diretrio home deve ser capaz de criar ou visualizar arquivos ali. Os outros usurios devem ter todo o acesso negado (a no ser que o usurio queira o contrrio). Isto aumenta a privacidade do usurio e evita a possvel desapropriao de arquivos pessoais. No obstante, h diversas situaes nas quais usurios mltiplos precisam de acesso aos mesmos recursos de uma mquina. Nestes casos, pode ser necessrio criar grupos compartilhados cuidadosamente.
126
6.2.1.1. Grupos Compartilhados e Dados Conforme mencionado na introduo, grupos so construes lgicas que podem ser usadas para agrupar contas de usurios para um propsito especco. Ao administrar os usurios de uma empresa, bom identicar quais dados devem ser acessados por determinados departamentos, quais dados devem ser negados aos outros, e quais dados devem ser compartilhados entre todos. Determinar estas questes auxilia na criao de uma estrutura apropriada de grupos, juntamente s permisses apropriadas para os dados compartilhados. Por exemplo: assuma que o departamento de contas a receber deve manter uma lista das contas inadimplentes de seus pagamentos. Eles tambm devem compartilhar esta lista com o departamento de cobrana. Se as contas dos funcionrios de ambos departamentos, contas a pagar e cobrana, so membros de um grupo chamado contas, estas informaes podem ser inseridas num diretrio compartilhado (de propriedade do grupo contas) com permisses de leitura e gravao (read and write) para o grupo no diretrio. 6.2.1.2. Determinando a Estrutura dos Grupos Aqui esto alguns dos desaos enfrentados pelos administradores de sistemas ao criar os grupos:

Quais grupos criar Quem deve ser inserido num determinado grupo Que tipos de permisses estes recursos compartilhados devem ter
muito til estabelecer uma estratgia de bom senso para estas questes. Uma das possibilidades espelhar a estrutura de sua empresa na criao dos grupos. Por exemplo: se h um departamento de nanas, crie um grupo chamado finanas e torne todos os funcionrios do departamento de nanas membros deste grupo. Se as informaes nanceiras so muito delicadas para a empresa como um todo, mas essenciais para os gerentes sniors da empresa, ento d a eles permisses de grupo para acessar os diretrios e dados usados pelo departamento de nanas, adicionando todos os gerentes sniors ao grupo finanas. Tambm aconselhvel ser cuidadoso ao conceder permisses aos usurios. Desta maneira, as informaes delicadas tm menor probabilidade de cair em mos erradas. Ao criar a estrutura de grupos de sua empresa desta maneira, possvel atender s necessidades de acesso a dados compartilhados de forma segura e ecaz.
6.2.2. Onde os Usurios Acessam os Dados Compartilhados

Ao compartilhar dados entre usurios, comum ter um servidor central (ou um grupo de servidores) que disponibiliza determinados diretrios para outras mquinas da rede. Desta maneira, os dados so armazenados em um lugar; no necessrio sincronizar os dados entre diversas mquinas. Antes de adotar esta estratgia, voc deve primeiro determinar quais sistemas devem ter acesso aos dados armazenados centralmente. Ao fazer isso, anote os sistemas operacionais usados pelos sistemas. Estas informaes so importantes para sua habilidade em implementar uma estratgia como esta, pois seu servidor de armazenamento deve ser capaz de servir seus dados para cada um dos sistemas operacionais utilizados na sua empresa. Infelizmente, uma vez que os dados so compartilhados entre os diversos computadores de uma rede, o potencial de conitos pela propriedade do arquivo pode aumentar.
Captulo 6. Administrando Contas de Usurio e Acesso a Recursos 6.2.2.1. Questes de Propriedade (ownership) Global
127
H benefcios no caso dos dados serem armazenados centralmente e acessados por diversos computadores atravs de uma rede. Entretanto, assuma por um momento que cada um destes computadores tem uma lista de contas de usurios mantida localmente. E se a lista de usurios em cada um destes sistemas no for consistente com a lista de usurios no servidor central? Pior ainda, e se as listas de usurios em cada um destes sistemas no forem consistentes nem mesmo entre si? Muitas destas questes dependem de como os usurios e as permisses de acesso so implementadas em cada sistema, mas em alguns casos possvel o usurio A de um sistema ser conhecido como usurio B em outro sistema. Isto torna-se um problema latente quando os dados so armazenados entre estes dois sistemas, j que os dados que o usurio A tem permisso para acessar de um sistema tambm podem ser lidos pelo usuro B de outro sistema. Por este motivo, muitas empresas usam algum tipo de banco de dados central dos usurios. Isto garante que no ocorra sobreposies entre as listas de usurios de sistemas diferentes. 6.2.2.2. Diretrios Home Uma outra questo enfrentada por administradores de sistemas decidir se os usurios devem ou no ter diretrios home armazenados centralmente. A principal vantagem dos diretrios home centralizados num servidor ligado rede que, se o usurio se autenticar em qualquer mquina da rede, ele poder acessar os arquivos de seu diretrio home. A desvantagem que, se a rede cair, os usurios da empresa toda no podero acessar seus arquivos. Em algumas situaes (como em empresas que adotam o uso geral de laptops), talvez no seja quisto ter diretrios home centralizados. Mas, se faz sentido para sua empresa, implementar diretrios home centralizados pode facilitar bastante a vida do administrador de sistemas.
6.2.3. Quais so as Barreiras Adotadas para Evitar o Abuso de Recursos

A organizao de grupos e a atribuio de permisses para recursos compartilhados feitos de maneira cuidadosa esto dentre as coisas mais importantes que um administrador de sistemas pode fazer para evitar o abuso de recursos dentre os usurios de uma empresa. Desta maneira, aqueles que no devem ter acesso aos recursos delicados tm o acesso negado. No importa como a sua empresa se comporta; a melhor proteo contra o abuso de recursos sempre a vigilncia por parte do administrador de sistemas. Manter seus olhos bem abertos frequentemente a nica maneira de evitar uma surpresa desagradvel esperando por voc em sua mesa.

As sees seguintes abordam as diversas funcionalidades especcas do Red Hat Enterprise Linux, relacionadas administrao de contas de usurio e recursos associados.
6.3.1. Contas de Usurio, Grupos e Permisses

Sob o Red Hat Enterprise Linux, um usurio pode se autenticar no sistema e usar qualquer aplicao ou arquivo que tenha permisso para acessar, aps a criao de uma conta de usurio normal. O Red Hat Enterprise Linux determina se um usurio ou grupo pode acessar estes recursos baseado nas permisses atribudas a eles.
128
H trs tipos diferentes de permisses para arquivos, diretrios e aplicaes. Estas permisses so usadas para controlar os tipos de acesso permitidos. So usados smbolos diferentes de um caractere cada para descrever cada permisso em uma listagem de diretrios. Os seguintes smbolos so usados:
r w x
Indica que uma determinada categoria de usurios pode ler (read) o arquivo. Indica que uma determinada categoria de usurios pode gravar/escrever (write) no arquivo.
Indica que uma determinada categoria de usurios pode executar (execute) o contedo de um arquivo.
Um quarto smbolo (-) indica que nenhum acesso permitido. Cada uma das trs permisses atribuda a trs categorias diferentes de usurios. As categorias so:

proprietrio (owner) O proprietrio do arquivo ou aplicao. grupo (group) O grupo que detm o arquivo ou aplicao. todos (everyone) Todos os usurios com acesso ao sistema.
Conforme exposto anteriormente, possvel visualizar as permisses de um arquivo invocando uma listagem de formato longo com o comando ls -l. Por exemplo: se o usurio juan criar um arquivo executvel chamado foo, o output do comando ls -l foo seria parecido com:
-rwxrwxr-x 1 juan juan 0 Sep 26 12:25 foo
As permisses deste arquivo esto listadas no incio da linha, comeando com rwx. O primeiro conjunto de smbolos dene o acesso do proprietrio neste exemplo, o proprietrio juan tem acesso total e pode ler (read), gravar (write) e executar (execute) o arquivo. O prximo conjunto de smbolos rwx dene o acesso do grupo (novamente, acesso total), enquanto o ltimo conjunto de smbolos dene os tipos de acesso para todos os outros usurios. Aqui, todos os outros usurios podem ler (read) e executar (execute) o arquivo, mas no podem modic-lo de maneira alguma. Um ponto importante para ter em mente em relao s permisses e contas de usurio que toda aplicao que roda no Red Hat Enterprise Linux, roda no contexto de um usurio especco. Isto signica que, se o usurio juan inicia uma aplicao, ela roda usando o contexto do usurio juan. No entanto, em alguns casos a aplicao pode precisar de um nvel de acesso mais privilegiado para completar a tarefa. Este tipo de aplicao inclui aquelas que editam conguraes do sistema ou autenticam usurios. Por esta razo, foram criadas permisses especiais. H trs tipos de permisses especiais no Red Hat Enterprise Linux:
setuid usada somente para aplicaes, esta permisso indica que a aplicao deve rodar como o proprietrio do arquivo e no como o usurio executando a aplicao. indicado pelo caractere s no lugar do x na categoria proprietrio. Se o proprietrio do arquivo no tem permisses para executar, o S torna-se maisculo para reetir este fato. setgid usado principalmente para aplicaes, esta permisso indica que a aplicao deve rodar como o grupo que detm o arquivo, e no como o grupo do usurio executando a aplicao. Se aplicada a um diretrio, todos os arquivos criados dentro do diretrio so de propriedade do grupo que detm o diretrio, e no do grupo do usurio criando o arquivo. A permisso setgid indicada pelo caractere s no lugar do x na categoria grupo. Se o grupo proprietrio do arquivo no tem permisso para executar, o S torna-se maisculo para reetir este fato.
sticky bit usado principalmente em diretrios, este bit dita que um arquivo criado no diretrio pode ser removido somente pelo usurio que criou o arquivo. indicado pelo caractere t no lugar do x na categoria todos (everyone). Se a categoria todos no tem permisso para executar, o T torna-se maisculo para reetir este fato.
129
Sob o Red Hat Enterprise Linux, o sticky bit denido por default no diretrio /tmp/ exatamente por este motivo. 6.3.1.1. Nomes de Usurio e UIDs, Grupos e GIDs No Red Hat Enterprise Linux, as contas de usurio e nomes dos grupos so usadas principalmente para a convenincia das pessoas. Internamente, o sistema usa identicadores numricos. Para os usurios, este identicador conhecido como UID, enquanto que para os grupos, o identicador conhecido como GID. Os programas que disponibilizam as informaes do usurio ou grupo aos usurios traduzem os valores UID/GID para seus paralelos mais legveis por humanos.
Importante UIDs e GIDs devem ser globalmente nicos dentro da empresa, se voc pretende compartilhar arquivos atravs da rede. Caso contrrio, quaisquer controles de acesso que voc tente implantar no funcionaro apropriadamente, j que so baseados nos UIDs e GIDs, e no nos nomes de usurios e grupos. Especicamente, se os arquivos /etc/passwd e /etc/group de um servidor de arquivos e de uma estao de trabalho de um usurio diferem nos UIDs ou GIDs que contm, a atribuio inapropriada de permisses pode acarretar em problemas de segurana. Por exemplo: se o usurio juan tem um UID de 500 em um computador, os arquivos que juan criar num servidor de arquivos tero o UID 500 no proprietrio. Entretanto, se o usurio bob se autenticar localmente ao servidor de arquivos (ou mesmo num outro computador), e a conta do bob tambm tiver um UID de 500, bob ter acesso total aos arquivos de juan e vice-versa. Consequentemente, as colises de UID e GID devem ser evitadas a todo custo.
H duas instncias nas quais o valor numrico corrente de um UID ou GID tem algum signicado especco. Um UID e GID de zero (0) so usados para o usurio root e so tratados especialmente pelo Red Hat Enterprise Linux o acesso total atribudo automaticamente. A segunda instncia que UIDs e GIDs abaixo de 500 so reservados para uso do sistema. Ao contrrio do UID/GID zero (0), UIDs e GIDs abaixo de 400 no so tratados especialmente pelo Red Hat Enterprise Linux. No entanto, estes UIDs/GIDs nunca devem ser atribudos a um usurio, j que provavelmente algum componente do sistema usa ou usar estes UIDs/GIDs am algum momento no futuro. Para mais informaes sobre estes usurios e grupos padro, consulte o captulo Usurios e Grupos no Guia de Referncia do Red Hat Enterprise Linux. Quando so adicionadas novas contas de usurios usando as ferramentas padro de criao de usurios do Red Hat Enterprise Linux, estas contas recebem os primeiros UID e GID disponveis a partir de 500. O prximo usurio novo recebe o UID/GID 501, seguido pelo UID/GID 502 e assim por diante. Mais adiante ainda neste captulo abordamos uma breve descrio das diversas ferramentas de criao de usurios disponveis sob o Red Hat Enterprise Linux. Mas, antes de rever estas ferramentas, a prxima seo aborda os arquivos que o Red Hat Enterprise Linux usa para denir as contas e grupos do sistema.
6.3.2. Arquivos que Controlam Contas de Usurio e Grupos

No Red Hat Enterprise Linux, as informaes sobre contas de usurio e grupos so armazenadas em diversos arquivos texto dentro do diretrio /etc/. Quando um administrador de sistemas cria novas contas de usurio, necessrio editar estes arquivos manualmente ou usar aplicaes para efetuar as alteraes necessrias.
130
A seo seguinte documenta os arquivos do diretrio /etc/ que armazenam informaes sobre usurios e grupos no Red Hat Enterprise Linux. 6.3.2.1. /etc/passwd O arquivo /etc/passwd pode ser lido por todos e contm uma lista de usurios, cada um numa linha separada. Em cada linha, h uma lista delimitada por dois pontos contendo as seguintes informaes:

Noime de usurio (username) O nome que o usurio digita ao se autenticar no sistema. Senha (password) Contm a senha criptografada (ou um x se estiver usando senhas shadow conra mais detalhes posteriormente). ID do usurio (UID) O equivalente numrico do nome de usurio, referenciado pelo sistema e aplicaes ao determinar privilgios de acesso. ID do grupo (GID) O equivalente numrico do nome do grupo principal, referenciado pelo sistema e aplicaes ao determinar privilgios de acesso. GECOS Nomeado por motivos histricos, o campo GECOS1 opcional e usado para armazenar informaes extras (como o nome completo do usurio). Mltiplas entradas podem ser armazenadas aqui na lista delimitada por dois pontos. Utilitrios como o finger acessam este campo para prover informaes adicionais do usurio. Diretrio home A localizao absoluta do diretrio home do usurio, tal como /home/juan/. Shell O programa iniciado automaticamente sempre que um usurio se autentica. , geralmente, um interpretador de comandos (frequentemente chamado de shell). No Red Hat Enterprise Linux, o valor default /bin/bash. Se o campo for deixado em branco, /bin/sh usado. Se for congurado para um arquivo inexistente, o usurio no poder se autenticar no sistema.
Aqui est um exemplo de uma entrada do /etc/passwd:

root:x:0:0:root:/root:/bin/bash
Esta linha mostra que o usurio root tem uma senha shadow, assim como um UID e GID de 0. O usurio root tem /root/ como um diretrio home, e usa /bin/bash para uma shell. Para mais informaes sobre o /etc/passwd, veja a pgina man do passwd(5). 6.3.2.2. /etc/shadow Como o arquivo /etc/passwd deve ser legvel por todos (world-readable - a principal razo que este arquivo usado para efetuar a traduo do UID para o nome do usurio), h um risco envolvido em armazenar a senha de todos no /etc/passwd. verdade que as senhas so criptografadas, mas possvel executar ataques contra senhas se a senha criptografada estiver disponvel. Se um atacante conseguir uma cpia do /etc/passwd, poder efetuar um ataque, se planejado silenciosamente. Ao invs de arriscar ser detectado ao tentar se autenticar com todas as senhas possveis geradas pelo cracker de senhas, um atacante pode usar o cracker de senhas da seguinte forma:

Um programa cracker de senhas gera as senhas possveis Cada senha possvel ento criptografada usando o mesmo algoritmo que o sistema utiliza
GECOS signica General Electric Comprehensive Operating Supervisor. Este campo era usado nos lab-
1.
oratrios da Bell, na implementao original do UNIX. O laboratrio tinha muitos computadores diferentes, incluindo um que rodava o GECOS. Este campo era usado para armazenar informaes quando o sistema UNIX enviava tarefas batch e de impresso ao sistema GECOS.
Captulo 6. Administrando Contas de Usurio e Acesso a Recursos A possvel senha criptografada ento comparada s senhas criptografadas no /etc/passwd
131
O aspecto mais perigoso deste ataque que pode ocorrer num sistema distante de sua empresa. Sendo assim, o atacante pode usar o hardware de melhor desempenho disponvel no mercado, possibilitando testar um nmero enorme de senhas muito rapidamente. Consequentemente, o arquivo /etc/shadow legvel somente pelo usurio root e contm as senhas (e informaes opcionais de expirao das senhas) de cada usurio. Assim como no arquivo /etc/passwd, as informaes de cada usurio esto numa linha separada. Cada uma destas linhas uma lista delimitada por dois pontos, incluindo as seguintes informaes:

Nome de usurio (username) O nome que o usurio digita ao se autenticar no sistema. Isso permite que a aplicao login recupere a senha do usurio (e informaes relacionadas a este usurio). Senha criptografada A senha de 13 a 24 caracteres. A senha criptografada usando a funo crypt(3) da biblioteca ou o algoritmo hash md5. Neste campo, os valores alm de uma senha hash ou criptografada formatada de maneira vlida so usados para controlar as autenticaes do usurio e exibir o status da senha. Por exemplo: se o valor ! ou *, a conta est bloqueada e o usurio no pode se autenticar. Se o valor !!, a senha ainda no foi determinada (e, consequentemente, o usurio no poder se autenticar). Data da ltima alterao da senha O nmero de dias desde 1o. de Janeiro de 1970 (tambm chamado de perodo) em que a senha foi alterada pela ltima vez. Esta informao usada junto aos campos de expirao da senha que seguem. Nmero de dias antes que a senha possa ser alterada O nmero mnimo de dias antes que a senha possa ser alterada. Nmero de dias antes que uma alterao de senha seja solicitada O nmero de dias antes da senha ser alterada. Nmero de dias do aviso antes da alterao da senha O nmero de dias antes da expirao da senha durante os quais o usurio avisado da expirao iminente. Nmero de dias antes da desabilitao da conta O nmero de dias aps a senha expirar antes da conta ser desabilitada. Data desde a desabilitao da conta A data (armazenada como o nmero de dias desde o perodo) desde que a conta do usurio foi desabilitada. Um campo reservado Um campo ignorado no Red Hat Enterprise Linux.
Aqui est um exemplo do /etc/shadow:

juan:$1$.QKDPc5E$SWlkjRWexrXYgc98F.:12825:0:90:5:30:13096:
Esta linha exibe as seguintes informaes do usurio juan:

A senha foi alterada pela ltima vez no dia 11 de Fevereiro de 2005 No h tempo mnimo denido antes que a senha possa ser alterada A senha deve ser alterada a cada 90 dias O usurio receber um aviso cinco dias antes de que a senha deve ser alterada A conta ser desabilitada 30 dias aps a senha expirar, se no houver tentativas de autenticao A conta expirar no dia 09 de Novembro de 2005
Para mais informaes sobre o arquivo /etc/shadow, veja a pgina man do shadow(5).
132 6.3.2.3. /etc/group
O arquivo /etc/group legvel por todos (world-readable) e contm uma lista de grupos, cada um numa linha separada. Cada linha tem quatro campos separados por dois pontos, incluindo as seguintes informaes:

Nome do grupo O nome do grupo. Usado por vrios utilitrios como um identicador do grupo legvel por humanos. Senha do grupo Se determinada, esta permite aos usurios que no fazem parte do grupo juntarse a ele usando o comando newgrp e digitando a senha armazenada aqui. Se houver um x em caixa baixa neste campo, as senhas do grupo shadow esto em uso. ID do grupo (GID) O equivalente numrico do nome do grupo. usado pelo sistema operacional e aplicaes ao determinar os privilgios de acesso. Lista de membros Uma lista de usurios pertencentes ao grupo, separados por vrgulas.
Aqui est um exemplo do /etc/group:

general:x:502:juan,shelley,bob
Esta linha mostra que o grupo general est usando senhas shadow, tem um GID de 502 e que juan, shelley e bob so membros. Para mais informaes sobre o /etc/group, veja a pgina man do group(5). 6.3.2.4. /etc/gshadow O arquivo /etc/gshadow legvel/acessvel somente pelo usurio root e contm uma senha criptografada para cada grupo, assim como informaes sobre os membros e administrador. Como no arquivo /etc/group, as informaes de cada grupo esto numa linha separada. Cada uma destas linhas uma lista separada por vrgulas, contendo as seguintes informaes:

Nome do grupo O nome do grupo. Usado por vrios utilitrios como um identicador do grupo legvel por humanos. Senha criptografada A senha criptografada do grupo. Se determinada, usurios no membros do grupo podem juntar-se a ele digitando a senha deste grupo usando o comando newgrp. Se o valor deste campo !, nenhum usurio pode acessar o grupo usando o comando newgrp. O valor !! tratado da mesma maneira como o valor ! no entanto, tambm indica que nenhuma senha foi determinada anteriormente. Se o valor zero, somente os membros do grupo podem nele se autenticar (log in). Administradores do grupo Os membros do grupo aqui listados (numa lista delimitada por vrgulas) podem adicionar ou remover membros do grupo usando o comando gpasswd. Membros do grupo Os membros do grupo aqui listados (numa lista separada por vrgulas) so membros regulares e no-administrativos do grupo.
Aqui est um exemplo do /etc/gshadow:

general:!!:shelley:juan,bob
Esta linha mostra que o grupo general no tem senha e no permite o ingresso de no membros usando o comando newgrp. Alm disso, shelley uma administradora do grupo, e juan e bob so membros regulares e no administrativos. J que editar estes arquivos aumenta o risco de erros de sintaxe, recomendado usar as aplicaes providas pelo Red Hat Enterprise Linux para este propsito. A prxima seo traz uma reviso das principais ferramentas para executar estas tarefas.
133
6.3.3. Aplicaes de Conta de Usurio e Grupo

H dois tipos bsicos de aplicaes que podem ser usadas para administrar contas de usurios e grupos nos sistemas Red Hat Enterprise Linux:

A aplicao grca Administrador de Usurios Um conjunto de ferramentas de linha de comando
Para obter instrues detalhadas sobre o uso do Administrador de Usurios, consulte o captulo Congurao de Usurio e Grupo no Guia de Administrao de Sistemas Red Hat Enterprise Linux. Apesar da aplicao Administrador de Usurios e dos utilitrios de linha de comando executarem essencialmente a mesma tarefa, as ferramentas de linha de comando tm a vantagem de serem alterveis por scripts e, consequentemente, mais fceis de serem automatizadas. A tabela seguinte descreve algumas das ferramentas de linha de comando mais comuns usadas para criar e administrar contas de usurio e grupos: Aplicao
/usr/sbin/useradd /usr/sbin/userdel /usr/sbin/usermod
Funo Adiciona contas de usurios. Esta ferramenta usada tambm para especicar os membros principais e secundrios do grupo. Apaga contas de usurios. Edita os atributos da conta incluindo algumas funes relacionadas expirao da senha. Para os ajustes nos, use o comando passwd. O usermod tambm usado para especicar os membros principais e secundrios do grupo. Dene senhas. Apesar de ser usado principalmente para alterar a senha de um usurio, tambm controla todos os aspectos da expirao da senha. Acessa um arquivo contendo pares de nome de usurio e senha e atualiza a senha de cada usurio de acordo. Altera a poltica de expirao da senha de um usurio. O comando passwd tambm pode ser usado para este propsito. Altera as informaes GECOS do usurio, Altera a shell default do usurio.
passwd
/usr/sbin/chpasswd chage chfn chsh
Tabela 6-2. Ferramentas de Linha de Comando para Administrao de Usurios A tabela a seguir descreve algumas das ferramentas de linha de comando mais comuns usadas para criar e administrar grupos: Aplicao
/usr/sbin/groupadd
Funo Adiciona grupos, mas no atribui usurios para estes grupos. Os programas useradd e usermod devem ento ser usados para atribuir usurios a um determinado grupo. Apaga grupos. Modifca os nomes ou GIDs do grupo, mas no altera os membros do grupo. Os programas useradd e usermod devem ser usados para atribuir usurios a um determinado grupo.
/usr/sbin/groupdel /usr/sbin/groupmod
134 Aplicao
gpasswd
Captulo 6. Administrando Contas de Usurio e Acesso a Recursos Funo Altera os membros do grupo e determina senhas para permitir que usurios no membros do grupo, que conheam o grupo, a juntem-se a ele. Tambm usado para especicar os administradores do grupo. Verica a integridade dos arquivos /etc/group e /etc/gshadow.
/usr/sbin/grpck
Tabela 6-3. Ferramentas de Linha de Comando para Administrao de Grupos As ferramentas listadas oferecem uma grande exibilidade em controlar todos os aspectos das contas de usurio e associao a grupos. Para aprender mais sobre como estas funcionam, consulte a pgina man de cada uma delas. No entanto, estas aplicaes no determinam sobre quais recursos estes usurios e grupos tm controle. Para isso, o administrador de sistemas precisa usar as aplicaes para permisso de arquivos. 6.3.3.1. Aplicaes para Permisso de Arquivos As permisses de arquivo so uma parte integral da administrao de recursos dentro de uma empresa. A tabela seguinte aborda as ferramentas de linha de comando mais comuns utilizadas para este propsito. Aplicao
chgrp chmod chown
Funo Altera o grupo (ownership) que detm um determinado arquivo. Altera as permisses de um determinado arquivo. Tambm capaz de atribuir permisses especiais. Altera a propriedade (ownership) de um arquivo e tambm pode alterar o grupo.
Tabela 6-4. Ferramentas de Linha de Comando para Administrao de Permisses Tambm possvel alterar estes atributos nos ambientes grcos do GNOME e KDE. Clique com o boto direito no cone do arquivo (por exemplo: enquanto o cone exibido num visualizador grco de arquivos ou na rea de trabalho) e selecione Propriedades.

Esta seo inclui vrios recursos que podem ser usados para aprender mais sobre a admninistrao de contas e recursos, inclusive informaes especcas sobre o assunto relacionadas ao Red Hat Enterprise Linux neste captulo.

Os seguintes recursos so instalados no decorrer de uma instalao tpica do Red Hat Enterprise Linux e podem ajud-lo a aprender mais sobre o assunto abordado neste captulo.

Item Help do menu da Administrador de Usurios Aprenda a administrar contas de usurio e grupos. Pgina man passwd(5) Saiba mais informaes sobre o formato do arquivo /etc/passwd. Pgina man group(5) Informaes sobre o formato do arquivo /etc/group.
Captulo 6. Administrando Contas de Usurio e Acesso a Recursos Pgina man shadow(5) Informaes sobre o formato do arquivo /etc/shadow. Pgina man useradd(8) Aprenda como criar ou atualizar contas de usurios. Pgina man userdel(8) Aprenda como apagar contas de usurios. Pgina man usermod(8) Aprenda como modicar contas de usurios. Pgina man passwd(1) Aprenda como atualizar a senha de um usurio.
135
Pgina man chpasswd(8) Aprenda como atualizar as senhas de diversos usurios de uma s vez. Pgina man chage(1) Aprenda como alterar as informaes de expirao da senha de um usurio. Pgina man chfn(1) Aprenda como alterar as informaes GECOS (finger) de um usurio. Pgina man chsh(1) Aprenda a alterar a shell de autenticao de um usurio. Pgina man groupadd(8) Aprenda a criar um novo grupo. Pgina man groupdel(8) Aprenda como apagar um grupo. Pgina man groupmod(8) Aprenda a modicar um grupo. Pgina man gpasswd(1) Aprenda a administrar os arquivos /etc/group e /etc/gshadow. Pgina man grpck(1) Aprenda a vericar a integridade dos arquivos /etc/group e /etc/gshadow. Pgina man chgrp(1) Aprenda como alterar a propriedade em nvel de grupo. Pgina man chmod(1) Aprenda a alterar as permisses de acesso de um arquivo. Pgina man chown(1) Aprenda a alterar o proprietrio e o grupo de um arquivo.
6.4.2. Sites teis

http://www.bergen.org/ATC/Course/InfoTech/passwords.html Um bom exemplo de documento que abrange informaes sobre a segurana da senha para os usurios de uma empresa. http://www.crypticide.org/users/alecm/ Home page do autor de um dos programas mais famosos de cracking de senhas (Crack). Voc pode fazer o download do Crack a partir deste site e vericar quantos de seus usurios tm senhas fracas. http://www.linuxpowered.com/html/editorials/le.html uma boa viso geral sobre as permisses de arquivos no Linux.

Os livros a seguir abordam diversas questes relacionadas administrao de contas e recursos e so boas fontes de informao para administradores de sistemas Red Hat Enterprise Linux.

O Guia de Segurana do Red Hat Enterprise Linux; Red Hat, Inc. Oferece uma viso geral dos aspectos relacionados segurana de contas de usurios, enfaticamente sobre senhas fortes. O Guia de Referncia do Red Hat Enterprise Linux; Red Hat, Inc. Contm informaes detalhadas sobre usurios e grupos presentes no Red Hat Enterprise Linux. O Guia de Administrao de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. Inclui um captulo sobre a congurao de usurios e grupos.
136
Linux Administration Handbook de autoria de Evi Nemeth, Garth Snyder e Trent R. Hein; Prentice Hall Traz um captulo sobre a manuteno de contas de usurios, uma seo sobre segurana j que relacionado aos arquivos de contas de usurios, e uma seo sobre permisses e atributos de arquivos.
Captulo 7.
Impressoras e Impresso
As impressoras so um recurso essencial para criar uma verso em cpia impressa uma descrio fsica dos dados em papel de documentos e materiais para negcios, estudos acadmicos e uso domstico. As impressoras tornaram-se um perifrico indispensvel em todos os nveis de empresas e computao institucional. Este captulo aborda as diversas impressoras disponveis e compara seus usos em ambientes computacionais diferentes. Ento, descreve como a impresso suportada pelo Red Hat Enterprise Linux.
7.1. Tipos de Impressoras

Assim como qualquer outro perifrico, h diversos tipos de impressora disponveis. Algumas impressoras empregam tecnologias que imitam a funcionalidade do estilo da mquina de escrever, enquanto outras utilizam jato de tinta ou ento laser para gerar uma imagem da pgina sendo impressa. O hardware da impressora interage com um PC ou rede usando protocolos paralelos, seriais ou de rede de dados. H diversos fatores a considerar quando voc for avaliar impressoras para compra e uso em seu ambiente computacional. As sees seguintes abordam vrios tipos de impressoras e os protocolos que utilizam para comunicarem-se com computadores.
7.1.1. Consideraes de Impresso

H diversos aspectos relevantes para a avaliao de uma impressora. Veja a seguir alguns dos critrios mais comuns para avaliar suas necessidades de impresso. 7.1.1.1. Funo Avaliar as necessidades de sua empresa e como uma impressora serve a estas necessidades essencial para determinar o tipo de impressora mais apropriado para o seu ambiente. A questo mais importante "O que precisamos imprimir?" Como h impressoras especializadas em texto, imagens ou variaes destas, voc deve garantir de adquirir a ferramenta correta para seus propsitos. Por exemplo: se as suas necessidades exigem imagens coloridas de alta qualidade em papel glossy prossional, recomendado usar uma impressora colorida com tecnologia dye-sublimation ou transferncia trmica de cera (thermal wax transfer) ao invs de uma impressora laser ou de impacto. Por outro lado, as impressoras a laser e jato de tinta so mais apropriadas para imprimir esboos ou documentos para distribuio interna (tais impressoras de alto volume so chamadas de impressoras workgroup). Estudar as necessidades dirias dos usurios permite ao administrador determinar a impressora correta. H ainda outros fatores a considerar, como o duplexing a habilidade de imprimir nos dois lados de uma folha de papel. Tradicionalmente, as impressoras podiam imprimir somente num lado da pgina (impresso simplex). A maioria dos modelos simples de impressora no tem duplexing por default (mas talvez possam efetuar um duplexing manual, o que requer que o usurio vire o papel). Alguns modelos oferecem a possibilidade de adicionar hardware para executar o duplexing; tais adies podem elevar os custos consideravelmente. Entretanto, a impresso duplex pode reduzir custos a longo prazo, reduzindo a quantidade de papel usada para imprimir documentos e, consequentemente reduzindo o custo de consumveis principalmente papel. Um outro fator a considerar o tamanho do papel. A maioria das impressoras podem lidar com os tamanhos mais comuns de papel:
138 letter (8 1/2" x 11") A4 (210mm x 297mm) JIS B5 (182mm x 257mm) legal (8 1/2" x 14")
Captulo 7. Impressoras e Impresso
Se determinados departamentos (como marketing ou design) tm necessidades especcas, como a criao de psters ou banners, h impressoras de formato grande capazes de usar papel tamanho A3 (297mm x 420mm) ou tablide (11" x 17"). Alm dessas, h impressoras para tamanhos de papel ainda maiores, mas so usadas apenas para ns especcos, como para a impresso blueprint (mapas, planos arquitetnicos, etc.) As funcionalidades mais complexas, como mdulos de rede para impresso workgroup e site remoto tambm devem ser consideradas durante a avaliao. 7.1.1.2. Custo O custo outro fator a considerar. No entanto, determinar o custo nico associado compra da impressora no suciente. H outros custos envolvidos, como os consumveis, peas, manuteno e hardware adicionais. Como a palavra implica, consumveis um termo usado para descrever o material usado durante o processo de impresso. Os consumveis, neste caso, so mdia e tinta. A mdia o material no qual o texto ou imagem impresso. A escolha da mdia depende muito do tipo de informao sendo impressa. Por exemplo: criar uma impresso exata de uma imagem digital requer um papel glossy especial que resista exposio prolongada de luz natural ou articial, e tambm garantir a acuracidade da reproduo de cores. Estas qualidades so chamadas de rapidez de cor. Para imprimr documentos com qualidade de arquivo que requerem durabilidade e um nvel prossional de legibilidade (como contratos, curriculuns e registros permanentes), necessrio usar papel matte (ou no-glossy). A gramatura (ou grossura) do papel tambm importante, j que algumas impressoras possuem um caminho no-linear do papel. O uso de papel muito no ou muito grosso pode resultar em obstrues (paper jams). Algumas impressoras tambm podem imprimir em transparncias, permitindo que a informao seja projetada numa tela durante apresentaes. As mdias especializadas, como as mencionadas aqui, podem alterar o custo dos consumveis, e devem ser levadas em considerao ao avaliar as necessidades de impresso. Tinta um termo genrico, j que nem todas as impressoras usam tintas lquidas. Por exemplo: as impressoras laser usam um p conhecido como toner, enquanto impressoras de impacto usam tas saturadas com tinta. H impressoras especializadas que aquecem a tinta durante o processo de impresso, enquanto outras espirram gotas de tinta na mdia. Os custos de reposio da tinta variam amplamente e dependem do fato se o repositrio de tinta pode ser recarregado (com rel) ou se o cartucho de tinta precisa ser completamente substitudo.
7.2. Impressoras de Impacto

As impressoras de impacto representam a tecnologia mais antiga ainda em produo. Alguns dos maiores fabricantes de impressoras continuam a produz-las, vend-las e suportar as impressoras, peas e suprimentos. As impressoras de impacto so mais funcionais em ambientes especializados, nos quais o baixo custo de impresso essencial. Os trs tipos mais comuns de impressoras de impacto so matricial, margarida e impressoras de linha.
139
7.2.1. Impressoras Matriciais

A tecnologia por trs da impresso matricial bem simples. O papel pressionado contra um tambor (um cilindro coberto de borracha) e intermitentemente puxado para frente ao longo da impresso. A cabea de impresso move-se eletromagneticamente ao longo do papel e atinge a ta de impresso situada entre o papel e o pino da cabea. O impacto da cabea de impresso contra o tambor lana pontos de tinta, que formam caracteres humanamente legveis no papel. As impressoras matriciais variam na resoluo e na qualidade geral, com cabeas de impresso de 9 ou de 24 pinos. Quanto mais pinos por polegada, maior a resoluo da impresso. A maioria das impressoras matriciais tem resoluo mxima de, aproximadamente, 240 dpi (dots per inch, pontos por polegada). Apesar desta resoluo no ser to alta quanto aquelas possveis em impressoras jato de tinta ou laser, no h uma vantagem distinta para as impresses matriciais (ou de qualquer forma de impacto). Como a cabea de impresso deve atingir a superfcie do papel com fora suciente para transferir tinta de uma ta para a pgina, uma boa opo para empresas que precisam produzir cpias carbono atravs do uso de documentos multi-partes especiais. Estes documentos tm carbono (ou outro material sensvel presso) no lado de baixo e criam uma marca na pgina de baixo quando a presso aplicada. Lojas de varejo e pequenas empresas frequentemente usam cpias carbono como recibos ou notas de vendas.
7.2.2. Impressoras Margarida

Se voc j trabalhou com uma mquina de escrever manual antes, ento entende o conceito tecnolgico por trs das impressoras margarida. Estas impressoras tm cabeas de impresso compostas de rodas metlicas ou plsticas cortadas no formato de ptalas. Cada ptala tem a forma de uma letra (em caixa alta e baixa), nmero ou pontuao. Quando a ptala pressionada sobre a ta de impresso, a forma resultante fora a tinta sobre o papel. As impressoras margarida so barulhentas e lentas. No podem imprimir grcos, e no podem alterar a fonte, a no ser que a roda de impresso seja sicamente substituda. Com o advento das impressoras laser, as impressoras margarida geralmente no so mais usadas nos ambientes computacionais modernos.
7.2.3. Impressoras de Linha

Um outro tipo de impressora de certa maneira similar margarida a impressora de linha. Entretanto, ao invs de uma roda de impresso, as impressoras de linha tm um mecanismo que permite imprimir caracteres mltiplos na mesma linha. O mecanismo pode usar tambor de impresso rotativo ou uma correia de impresso em loop. Conforme o tambor ou correia rotacionada sobre a superfcie do papel, martelos eletromagnticos empurram o papel por trs (junto ta) sobre a superfcie do tambor ou correia, marcando o papel com a forma do caractere no tambor ou correia. Devido natureza do mecanismo de impresso, as impressoras de linha so bem mais rpidas que as impressoras matriciais ou margarida. Entretanto, tendem a ser muito barulhentas, ter capacidade limitada de fontes mltiplas e frequentemente produzir impresses de qualidade inferior que as tecnologias de impresso mais recentes. Como as impressoras de linha so usadas para a sua velocidade, utilizam papel especial alimentado por trao com buracos pr-furados de cada lado. Esta combinao possibilita a impresso contnua de alta velocidade sem superviso, parando somente quando uma caixa de papel acaba.
7.2.4. Consumveis de Impressoras de Impacto

Dentre todos os tipos de impressoras, as impressoras de impacto tm custos de consumveis relativamente baixos. Fitas de tinta e papel so os custos recorrentes principais. Algumas impressoras de impacto (geralmente de linha e matriciais) requerem papel alimentado por trao, o que pode aumentar um pouco o custo da operao.
140
7.3. Impressoras Jato de Tinta

Um impressora jato de tinta usa uma das tecnologias de impresso mais conhecidas de hoje. O custo relativamente baixo e as habilidades de impresso das impressoras jato de tinta fazem deste tipo uma boa opo para pequenas empresas e escritrios residenciais. As impressoras jato de tinta usam tintas baseadas em gua e rpidas de secar, e uma cabea de impresso com uma srie de pequenos bocais, que lanam tinta na superfcie do papel. O conjunto da cabea de impresso movido por um motor com polia, que move a cabea ao longo do papel. As impressoras jato de tinta eram originalmente fabricadas para imprimir somente em papel monocromtico (preto e branco). No entanto, desde ento, a cabea de impresso foi expandida e os bocais aumentados para acomodar as cores cyan, magenta, amarelo e preto. Essa combinao de cores (chamada CMYK) permite a impresso de imagens com quase a mesma qualidade de um laboratrio fotogrco (quando usada com determinados tipos de papel composto). Quando combinadas com qualidade de impresso de texto altamente legvel, as impressoras jato de tinta so uma tima opo para necessidades de impresso monocromticas ou coloridas.
7.3.1. Consumveis das Impressoras Jato de Tinta

As impressoras jato de tinta tendem a ter custo baixo e caractersticas de impresso um pouco elevadas em relao qualidade, funes extras e habilidade de imprimir em formatos maiores que os tamanhos de papel legal ou letter padres. Apesar do custo nico de adquirir uma impressora jato de tinta ser menor que outros tipos de impressora, o fator dos consumveis deve ser considerado. Como a demanda por impressoras jato de tinta grande e atinge todo o espectro da computao - do lar s grandes corporaes - a compra de consumveis pode ser custosa.
Nota Quando for comprar uma impressora jato de tinta, saiba que tipo de cartucho(s) de tinta esta precisa. Isso crucial para as unidades coloridas. As impressoras jato de tinta CMYK requerem tintas para cada cor; no entanto, o ponto central saber se cada cor armazenada num cartucho separado ou no. Algumas impressoras usam um cartucho multi-cmara. A no ser que seja possvel algum mtodo de rel, assim que a tinta de uma cor acaba, todo o cartucho dever ser substitudo. Outras impressoras utilizam um cartucho multi-cmara para cyan, magenta e amarelo, mas tm um cartucho separado para a cor preta. Em ambientes onde so impressas grandes quantidades de texto, este tipo de congurao pode ser indicado. No entanto, a melhor soluo encontrar uma impressora com cartuchos separados para cada cor, assim voc pode substitu-los facilmente quando uma das cores acabar.
Alguns fabricantes de impressoras jato de tinta requerem que voc use papel especialmente tratado para imagens e documentos de alta qualidade. Tais papis possuem uma cobertura moderada a alta, formulada para absorver tintas coloridas, o que evita a coagulao (tendncia das tintas baseadas em gua em concentrarem-se em reas onde as cores se misturam, causando umedecimento ou pontos de tinta seca) ou o estiramento (no qual o output da impresso apresenta uma padro estirado de linhas esquisitas na pgina impressa). Consulte a documentao de sua impressora para outras informaes relevantes.
7.4. Impressoras Laser

Baseada numa tecnologia mais antiga que a jato de tinta, as impressoras laser so uma outra alternativa conhecida da impresso de impacto legada. As impressoras laser so conhecidas por seu grande
141
volume de output a um baixo custo-por-pgina. So geralmente empregadas em empresas como um centro de impresso departamental ou workgroup, nos quais desempenho, durabilidade e requisitos de output so prioridades. Como as impressoras laser atendem prontamente a estas necessidades (a um custo-por-pgina razovel), a tecnologia altamente conceituada como o cavalo de batalha da impresso empresarial. As impressoras laser compartilham de grande parte da tecnologia das fotocopiadoras. Os rolamentos puxam uma folha de papel de uma bandeja e atravs de um rolamento de carga, que passa uma carga eletrosttica ao papel. Ao mesmo tempo, um tabor de impresso recebe a carga oposta. A superfcie do tambor scaneada por um laser, descarregando a superfcie do tambor e deixando com carga apenas aqueles pontos correspondentes ao texto ou imagem desejada. Essa carga ento usada para forar o toner a ser aderido pela superfcie do tambor. O papel e o tambor entram em contato; suas cargars diferentes fazem com que o toner seja aderido pelo papel. Finalmente, o papel viaja entre rolamentos de fuso, que esquentam o papel e derretem o toner, fundindo-o na superfcie do papel.
7.4.1. Impressoras Laser Coloridas

As impressoras laser coloridas pretendem combinar as melhores caractersticas das tecnologias laser e jato de tinta em um pacote de impresso multi-funcional. A tecnologia baseada na impresso laser monocromtica tradicional, mas utiliza componentes adicionais para criar imagens e documentos coloridos. Ao invs de usar somente toner preto, as impressoras laser coloridas usam uma combinao de toner CMYK. O tambor de impresso pode: rotacionar cada cor e derramar o toner de uma cor por vez, ou ento derramar todas as quatro cores em um prato e ento passar o papel pelo tambor, transferindo a imagem completa para o papel. As impressoras laser coloridas tambm empregam leo fusor ao longo dos rolamentos de fuso aquecidos, o que por sua vez junta o toner colorido ao papel e pode proporcionar diferentes graus de gramatura imagem nal. Devido o maior nmero de funcionalidades, as impressoras laser coloridas tipicamente custam o dobro (ou mais) do que as impressoras laser monocromticas. Ao calcular o custo total de propriedade em relao aos recursos de impresso, alguns administradores talvez queiram separar as funcionalidades monocromtica (texto) e colorida (imagem) para uma impressora laser monocromtica e uma impressora laser (ou jato de tinta) colorida, respectivamente.
7.4.2. Consumveis da Impressora Laser

Dependendo do tipo da impressora laser empregada, os custos de consumveis geralmente so proporcionais ao volume de impresso. O toner vem em cartuchos geralmente substitudos prontamente; no entanto, alguns modelos acompanham cartuchos recarregveis. As impressoras laser coloridas requerem um cartucho de toner para cada uma das quatro cores. Alm disso, requerem leos fusores para aplicar o toner sobre o papel e desperdiam garrafas de toner para capturar o excesso de toner. Estes suprimentos aumentam o custo dos consumveis das impressoras laser coloridas; no entanto, importante notar que estes consumveis duram, em mdia, em torno de 6000 pginas, um nmero bem maior se comparado com a durao dos consumveis das impressoras de impacto ou jato de tinta. O tipo de papel um problema menor nas impressoras laser, o que signica que uma compra grande de papel xerogrco ou de fotocpia comuns aceitvel para a maioria dos trabalhos de impresso. Entretanto, se voc pretende imprimir imagens de alta qualidade, deve optar por papel fotogrco (glossy) para obter uma nalizao prossional.
7.5. Outros Tipos de Impressora

H outros tipos de impressora disponveis, que tm, em sua maioria, propsitos especiais para grcos prossionais ou empresas de publicaes. No entanto, estas impressoras no so indicadas para uso
142
genrico. Como so delegadas para este nicho, seus preos (ambos, os custos nico e os recorrentes dos consumveis) tendem a ser mais altos que os preos das unidades predominantes. Impressoras de Cera Trmica Estas impressoras so mais usadas para transparncias em apresentaes empresariais e para prova de cor (criao de documentos e imagens teste para uma inspeo de qualidade antes do envio dos documentos mestre para serem impressos em impressoras industriais offset de quatro cores). As impressoras de cera trmica utilizam tambores CMYK direcionados por uma ta, e papel ou transparncia especialmente cobertos. A cabea de impresso contm elementos quentes que derretem cada cor de cera no papel conforme ele rola pela impressora. Impressoras Dye-Sublimation Usadas em empresas como agncias de servio onde a qualidade prossional dos documentos, panetos e apresentaes mais importante que o custo dos consumveis as impressoras dye-sublimation (ou dye-sub) so os cavalos de batalha da impresso CMYK de qualidade. Os conceitos por trs das impressoras dye-sublimation so similares aos das impressoras de cera trmica, exceto pelo uso de lme dye plstico difusivo ao invs de cera colorida. A cabea de impresso aquece o lme colorido e vaporiza a imagem em papel especialmente coberto. A dye-sub bastante conhecida no mundo do design e publicaes, assim como no campo da pesquisa cientca, onde necessrio ter preciso e detalhes. Tais detalhes e qualidade de impresso tm um preo, j que as impressoras dye-sub tambm so conhecidas por seus altos custos-por-pgina. Impressoras de Tinta Slida Usadas principalmente nos setores de embalagens e design industrial, as impressoras de tinta slida so famosas por imprimir numa variedade de tipos de papel. As impressoras de tinta slida, como o nome implica, usam espetos de tinta endurecidos, que so derretidos e espirrados atravs de pequenos bocais na cabea de impresso. O papel ento enviado atravs de um rolamento fusor, que por sua vez fora a tinta sobre o papel. A impressora de tinta slida ideal para provas e prottipos de novos designs de embalagens de produtos. Sendo assim, a maioria das empresas de servios no tem necessidade deste tipo de impressora.
7.6. Linguagens e Tecnologias de Impressoras

Antes do advento das tecnologias laser e jato de tinta, as impressoras de impacto podiam imprimir somente texto padro e justicado, sem nenhuma variao no tipo ou tamanho da fonte. Hoje em dia, as impressoras so capazes de processar documentos complexos com imagens, grcos e tabelas integrados, em diversos moldes e linguagens; tudo numa s pgina. Tal complexidade deve aderir lgumas convenes de formato. Foi isso que acelerou o desenvolvimento da linguagem de descrio da pgina (ou PDL - page description language) uma linguagem especializada de formatao de documentos criada especialmente para a comunicao de computadores com impressoras. Ao longo dos anos, os fabricantes de impressoras desenvolveram suas prprias linguagens proprietrias para descrever os formatos de documentos. No entanto, tais linguagens proprietrias se aplicavam somente s impressoras criadas pelos prprios fabricantes. Se, por exemplo, voc tivesse que enviar um arquivo pronto para impresso usando uma PDL proprietria para um jornalista prossional, no havia garantia de que seu arquivo seria compatvel com as mquinas da impressora. Veio ento a questo da portatibilidade. A Xerox desenvolveu o protocolo Interpress para a sua linha de impressoras, mas a adoo total desta linguagem pelo resto da indstria da impresso nunca ocorreu. Dois desenvolvedores do Interpress original deixaram a Xerox e formaram a Adobe, uma empresa de software dedicada basicamente aos grcos eletrnicos e prossionais de documentao. Na Adobe, desenvolveram uma
143
PDL amplamente adotada, chamada PostScript, que usa uma linguagem markup para descrever a formatao de texto e informaes da imagem que podiam ser processadas por impressoras. Ao mesmo tempo, a empresa Hewlett-Packard desenvolveu a Printer Control Language (Linguagem de Controle de Impresso ou PCL) para o uso em toda a sua linha de impressoras laser e jato de tinta. A PostScript e a PCL so PDLs amplamente adotadas agora e suportadas pela maioria dos fabricantes de impressoras. As PDLs funcionam sob o mesmo princpio das linguagens de programao de computador. Quando um documento est pronto para impresso, o PC ou estao de trabalho pega as imagens, as informaes tipogrcas e o layout do documento, e os utiliza como objetos que formam instrues para a impressora processar. A impressora ento traduz estes objetos em rasters, uma srie de linhas scaneadas que formam uma imagem do documento (chamado Raster Image Processing ou RIP), e imprime o output na pgina como uma imagem completa, com texto e grcos inclusos. Este processo torna a impresso de documentos mais consistente, resultando em pouca ou nenhuma variao ao imprimir o mesmo documento em modelos diferentes de impressora. As PDLs so desenvolvidas para serem portveis a qualquer formato e escalveis para caberem em formatos diferentes de papel. A escolha da impressora apropriada uma questo de determinar quais os padres adotados pelos diversos departamentos da sua empresa para suas necessidades. A maioria dos departamentos usa processadores de texto e outros software de produtividade que utilizam a linguagem PostScript para o envio s impressoras. No entanto, se o seu departamento grco requer uma PCL ou alguma forma de impresso proprietria, voc tambm deve levar isso em considerao.
7.7. Impressoras em Rede Versus Locais

Dependendo das necessidades, pode ser desnecessrio atribuir uma impressora para cada funcionrio de sua empresa. Tal despesa pode abocanhar grandes pores do seu oramento, deixando menos capital para as outras necessidades. Apesar das impressoras locais conectadas atravs de um cabo paralelo ou USB a cada estao de trabalho serem uma soluo ideal para o usurio, geralmente no economicamente vivel. Os fabricantes de impressoras resolveram esta questo ao desenvolver impressoras departamentais (ou workgroup). Estas mquinas so geralmente durveis, rpidas e tm consumveis de longa durao. As impressoras workgroup so frequentemente conectadas a um servidor de impresso (como uma estao de trabalho recongurada), que direciona o output para a impressora apropriada quando disponvel. Impressoras departamentais mais recentes incluem interfaces de rede integradas ou anexas que eliminam a necessidade de um servidor de impresso dedicado.

Veja a seguir as descries das diversas funcionalidades relacionadas s impressoras e impresso, especcas ao Red Hat Enterprise Linux. A Ferramenta de Congurao da Impressora permite aos usurios congurar uma impressora. Esta ferramenta ajuda a manter o arquivo de congurao da impressora, os diretrios spool e ltros de impresso. O Red Hat Enterprise Linux 4 usa o sistema de impresso CUPS. Se foi executado um upgrade de uma verso anterior do Red Hat Enterprise Linux que usava o CUPS, o processo de upgrade preservou as las conguradas. Usar a Ferramenta de Congurao da Impressora requer privilgios root. Para iniciar a aplicao, selecione Boto do Menu Principal (no Painel) => Conguraes do Sistema => Impresso, ou digite o comando system-config-printer. Este comando determina automaticamente se deve rodar a verso grca ou texto, dependendo se o comando executado no ambiente grco ou a partir de um console de texto.
144
Para forar a Ferramenta de Congurao da Impressora a rodar no modo texto, execute o comando system-config-printer-tui em uma janela de comandos.
Importante No edite o arquivo /etc/printcap ou os arquivos do diretrio /etc/cups/. A cada vez que o daemon da impressora (cups) iniciado ou reiniciado, so criados novos arquivos de congurao dinamicamente. Estes arquivos so criados dinamicamente tambm quando as alteraes so aplicadas Ferramenta de Congurao da Impressora.
Figura 7-1. Ferramenta de Congurao da Impressora Os seguintes tipos de las de impresso podem ser congurados:

Conectada localmente uma impressora ligada diretamente ao computador atravs de uma porta paralela ou USB. CUPS em Rede (IPP) uma impressora que pode ser acessada atravs de uma rede TCP/IP pelo Protocolo de Impresso da Internet, tambm conhecido como IPP (ex.: uma impressora conectada a um outro sistema Red Hat Enterprise Linux rodando o CUPS na rede). UNIX em Rede (LPD) uma impressora conectada a um sistema UNIX diferente, que pode ser acessado atravs de uma rede TCP/IP (ex.: uma impressora conectada a um outro sistema Red Hat Enterprise Linux rodando LPD na rede). Windows em Rede (SMB) uma impressora conectada a um sistema diferente, que compartilha uma impressora atravs de uma rede SMB (ex.: uma impressora conectada a uma mquina com Microsoft Windows). Novell em Rede (NCP) uma impressora conectada a um sistema diferente que usa a tecnologia de rede NetWare da Novell. JetDirect em Rede uma impressora conectada diretamente rede, atravs da HP JetDirect, ao invs de conectada ao computador.
145
Importante Se voc adicionar uma nova la de impresso ou modicar uma la existente, deve aplicar as alteraes para que estas tenham efeito.
Clicar no boto Aplicar salva quaisquer alteraes feitas e reinicia o daemon de impresso. As alteraes no so gravadas no arquivo de congurao at que o daemon de impresso seja reiniciado. Alternativamente, voc pode clicar em Ao (Action) => Aplicar (Apply). Para mais informaes sobre a congurao de impressoras sob o Red Hat Enterprise Linux, consulte o Guia de Administrao de Sistemas Red Hat Enterprise Linux.

A congurao da impresso e impresso em rede so tpicos abrangentes que requerem conhecimento e experincia em hardware, rede e administrao de sistemas. Para informaes mais detalhadas sobre o emprego de servios de impresso em seus ambientes, consulte os seguintes recursos.

Pgina man lpr(1) Aprenda a imprimir arquivos selecionados na sua impressora predileta. Pgina man lprm(1) Aprenda a remover trabalhos de impresso da la de impresso. Pgina man cupsd(8) Aprenda sobre o daemon de impresso CUPS. Pgina man cupsd.conf(5) Aprenda sobre o formato do arquivo de congurao do daemon de impresso CUPS. Pgina man classes.conf(5) Aprenda sobre o formato do arquivo de congurao da classe CUPS. Arquivos do diretrio /usr/share/doc/cups- version Aprenda mais sobre o sistema de impresso CUPS.
7.9.2. Sites teis

http://www.webopedia.com/TERM/p/printer.html Denies gerais das impressoras e descries dos tipos de impressora. http://www.linuxprinting.org/ Um banco de dados com documentos sobre impresso, juntamente a um banco de dados com aproximadamente 1000 impressoras compatveis com as funcionalidades de impresso do Linux. http://www.cups.org/ Documentao, FAQ e grupos de discusso sobre o CUPS.
Network Printing de Matthew Gast e Todd Radermacher; OReilly & Associates, Inc. Informaes detalhadas sobre o uso do Linux como um servidor de impresso em ambientes heterogneos. O Guia de Administrao de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. Inclui um captulo sobre a congurao da impressora.
"
146
Captulo 8.
Planejamento para Desastres
O planejamento para desastres um assunto fcil de esquecer para um administrador de sistemas no prazeroso e parece que sempre h algo mais urgente a fazer. No entanto, deixar o planejamento para desastres escapar uma das piores coisas que o administrador de sistemas pode fazer. Apesar dos desastres mais dramticos (tais como incndio, enchente ou tempestade) serem os primeiros a virem tona, os problemas mais comuns (como pees de obra cortarem cabos ou at mesmo uma pia transbordada) tambm podem ser motivos de interrupo. Sendo assim, a denio de desastre que um administrador de sistemas deve ter em mente qualquer evento no planejado que interrompe a operao normal da empresa. Apesar de ser possvel listar todos os tipos diferentes de desastres que podem acontecer, esta seo examina os principais fatores que fazem parte de cada tipo de desastre, para que cada possvel exposio seja examinada como um fator que pode levar a um desastre, e no em termos de sua probabilidade.
8.1. Tipos de Desastres

Em geral, h quatro fatores diferentes que podem acarretar num desastre. Estes fatores so:

Falhas de hardware Falhas de software Falhas de ambiente Erros humanos
8.1.1. Falhas de Hardware

As falhas de hardware so fceis de entender o hardware falha e o trabalho sofre uma parada. O que mais difcil de entender a natureza das falhas e como minimizar sua exposio a elas. Aqui esto algumas tticas que voc pode usar: 8.1.1.1. Guardar Hardware Reserva Simplisticamente, a exposio a falhas de hardware pode ser reduzida ao guardar hardware reserva. Obviamente, esta ttica assume duas coisas:

Algum dentro do escritrio tem as habilidades necessrias para diagnosticar o problema, identicar o hardware falho e substitu-lo. possvel substituir o hardware falho.
Estas questes esto detalhadas nas prximas sees. 8.1.1.1.1. Ter as Habilidades Dependendo de sua experincia e do hardware envolvido, ter as habilidades necessrias pode no ser um problema. No entanto, se voc nunca trabalhou com hardware antes, pode pensar em pesquisar cursos introdutrios sobre reparos em PCs. Apesar de cursos deste tipo no serem insucientes para prepar-lo para resolver problemas em um servidor de nvel corporativo, uma boa maneira de aprender o bsico (uso apropriado de ferramentas e componentes, procedimentos para diagnstico bsico e assim por diante).
148
Captulo 8. Planejamento para Desastres
Dica Antes de voc experimentar reparar o hardware sozinho, certique-se de que o hardware em questo:
No esteja mais sob garantia No esteja sob algum tipo de contrato de servio/manuteno
Se voc tentar reparar um componente de hardware coberto por uma garantia e/ou contrato de servio, provavelmente estar violando os termos destes acordos e prejudicando sua cobertura contnua.
Entretanto, mesmo com habilidades mnimas, pode ser possvel diagnosticar e substituir efetivamente o hardware falho se voc escolher seu estoque de hardware de substituio apropriadamente. 8.1.1.1.2. O Que Estocar? Esta questo ilustra a natureza complexa de qualquer coisa relativa recuperao de desastres. Quando considerar qual hardware estocar, aqui esto algumas questes a considerar:

Tempo Mximo Permitido Fora do Ar A habilidade necessria para efetuar o reparo Disponibilidade de verba para os reservas Espao de armazenamento necessrio para os reservas Outros componentes de hardware que poderiam utilizar os mesmos reservas
Cada uma destas questes tem um desenrolar nos tipos de reservas que devem ser estocados. Por exemplo: estocar sistemas completos tenderia a minimizar o tempo fora do ar e requerer habilidades mnimas para instalar, mas seria muito mais caro do que ter uma CPU ou mdulo RAM reserva na prateleira. No entanto, essa despesa pode valer a pena se a sua empresa tem dzias de servidores idnticos que podem beneciar de um sistema reserva. Independente da deciso nal, a seguinte questo inevitvel e abordada a seguir. 8.1.1.1.2.1. Quanto Estoque? A pergunta sobre os nveis de estoque reserva tambm tem vrias facetas. Aqui esto as principais questes:

Tempo Mximo Permitido Fora do Ar Taxa projetada de falhas Tempo estimado para reabastecer o estoque Disponibilidade de verba para os reservas Espao de armazenamento necessrio para os reservas Outros componentes de hardware que poderiam utilizar os mesmos reservas
Por um lado, para um sistema que pode estar fora do ar por no mximo dois dias, e cuja pea reserva talvez seja usada uma vez por ano e pode ser reabastecida em um dia, faria sentido ter apenas uma reserva (ou talvez nenhuma, se voc estiver certo de conseguir uma reserva em 24 horas).
149
Por outro lado, um sistema que no pode estar fora do ar por mais de alguns minutos, e uma reserva que talvez seja usada uma vez por ms (e pode levar diversas semanas para repr) pode signicar que meia dzia de reservas (ou mais) devem estar na prateleira.
8.1.1.1.3. Reservas Que No So Reservas Quando uma pea reserva no reserva? Quando um componente de hardware utilizado no cotidiano, mas tambm pode ser um componente reserva para um sistema mais prioritrio, se necessrio. Esta ttica tem alguns benefcios:

Menos dinheiro direcionado a peas reservas "no-produtivas" Sabe-se que o hardware operante
H, no entanto, algumas desvantagens nesta ttica:

A produo normal da tarefa de prioridade mais baixa interrompida H uma expoiso caso o hardware de baixa prioridade falhe (no sobra um componente reserva para o hardware de alta prioridade)
Dadas estas questes, o uso de um outro sistema de produo como reserva pode funcionar, mas o sucesso dessa ttica se desdobra na carga de trabalho especca do sistema e no impacto que a ausncia do sistema tem nas operaes gerais do centro de dados.
8.1.1.2. Contratos de Servio Os contratos de servio transferem o problema de falhas no hardware para outra pessoa. Tudo o que voc deve fazer conrmar que a falha, de fato, ocorreu e que parece no ser uma causa relativa ao software. Ento, voc faz uma ligao telefnica e aparece algum para resolver a situao. Parece muito simples. Mas, como a maioria das coisas na vida, h muito mais a observar do que o que vemos primeira vista. Aqui esto algumas questes que voc deve considerar ao analisar um contrato de servio:

Horas de cobertura Tempo de resposta Disponibilidade de peas Oramento disponvel Hardware a ser coberto
Ns exploramos cada um destes itens detalhadamente nas prximas sees. 8.1.1.2.1. Horas de Cobertura Contratos de servio diferentes so feitos para atender a diferentes necessidades; uma das maiores variveis entre contratos diferentes so as horas de cobertura. A no ser que voc queira pagar caro pelo privilgio, voc no pode simplesmente ligar a qualquer hora e esperar que um tcnico aparea rapidamente. Ao invs disso, dependendo do seu contrato, talvez voc descubra que nem pode ligar para a empresa de servios at uma certa data/hora, ou se puder, eles no enviaro um tcnico at a data/hora especicada no seu contrato.
150
A maioria das horas de cobertura so denidas em horas ou dias durante os quais um tcnico ser enviado. Algumas das horas de cobertura comuns so:

Segunda a Sexta, das 09:00 s 17:00 Segunda a Sexta, 12/18/24 horas por dia (com horas de incio e m concordadas entre as partes) Segunda a Sbado (ou Segunda a Domingo), mesmo horrio mencionado acima
Como de se esperar, o custo de um contrato aumenta com as horas de cobertura. Em geral, extender a cobertura de Segunda a Sexta tende a custar menos que adicionar cobertura aos Sbados e Domingos. Mas aqui tambm possvel reduzir custos se voc quiser executar algum trabalho. 8.1.1.2.1.1. Servio de Depsito Se a sua situao no requer nada mais que a disponibilidade de um tcnico durante o horrio comercial convencional e voc tem experincia suciente para poder determinar o que est quebrado, voc pode considerar o servio de depsito. Conhecido por muitos nomes (incluindo servio walk-in e servio drop-off ), os fabricantes talvez tenham depsitos de servio onde os tcnicos trabalham no hardware trazido pelos clientes. O servio de depsito tem o benefcio de ser to rpido quanto voc. Voc no precisa esperar que um tcnico esteja disponvel e aparea em sua empresa. Tcnicos de depsitos no atendem ligaes de clientes, o que signica que haver algum para trabalhar no seu hardware assim que voc chegar no depsito. Como o servio de depsito feito numa localidade central, h grandes chances de ter qualquer pea necessria. Isto pode eliminar a necessidade de um despacho que leva dias ou esperar que a pea seja encaminhada de um escritrio para outro h centenas de quilmetros de distncia. No entanto, h algumas desvantagens. A mais bvia que voc no pode escolher as horas de servio voc obtm o servio quando o depsito est aberto. Um outro aspecto que os tcnicos no trabalham depois de seu expediente, portanto se o seu sistema falhou s 16:30 de uma sexta-feira e voc entregou o sistema ao depsito s 17:00, ele no ser analisado at que os tcnicos cheguem ao trabalho na manh da segunda-feira seguinte. Uma outra desvantagem que o servio de depsito depende da existncia de um depsito prximo. Se a sua empresa est localizada na rea metropolitana, este provavelmente no um problema. Entretanto, as empresas localizadas em zonas rurais podem descobrir que o depsito ca muito longe de sua sede.
Dica Ao considerar o servio de depsito, pare um pouco e pense na logstica de trazer o hardware para o depsito. Voc usar um veculo da empresa ou o seu? Se for usar o seu, ele tem o espao e capacidade de carga necessrios? E o seguro? Ser necessrio mais de uma pessoa para carregar e descarregar o hardware? Apesar de serem preocupaes simples, elas devem ser analisadas antes de tomar a deciso de usar um servio de depsito.
8.1.1.2.2. Tempo de Resposta Alm das horas de cobertura, muitos contratos de servio especicam um nvel de tempo de resposta. Em outras palavras, quanto demora para o tcnico chegar aps ligar requisitando o servio? Como voc pode imaginar, um tempo de resposta mais rpido acarreta num acordo de servio mais caro.
151
H limites variveis para o tempo de resposta. Por exemplo: o tempo de viagem do escritrio do fabricante sua empresa tem uma grande inuncia nos tempos de resposta possveis 1 . Os tempos de resposta at quatro horas so geralmente inclusos nas ofertas mais rpidas. Os tempos de resposta mais lentos variam entre oito horas (o que efetivamente torna-se o servio do "dia seguinte" num acordo baseado no horrio comercial padro), a 24 horas. Assim como com qualquer outro aspecto de um contrato de servio, at mesmo estes tempos so negociveis pelo preo correto.
Nota Apesar de no ser uma ocorrncia comum, voc deve estar ciente que contratos de servio com clusulas de tempo de resposta podem, s vezes, estressar o departamento de servios de uma empresa alm de sua capacidade de resposta. No se sabe de nenhuma empresa de servios ocupada que tenha enviado algum ningum numa chamada de servio com tempo de resposta curto somente para cumprir seu comprometimento com o tempo de resposta. Esta pessoa aparentemente diagnostica o problema, ligando para o "escritrio" para que algum traga a "pea correta." De fato, eles esto apenas esperando chegar algum que seja capaz de atender chamada. Apesar de ser compreensvel observar isto sob curcunstncias extraordinrias (tais como problemas de energia que tenham afetado diversos sistemas em sua rea de servio), se este for um mtodo de operao constante, voc deve contatar o gerente de servios e pedir uma explicao.
Se a necessidade de seu tempo de resposta for restrita (e seu oramento for adequadamente grande), h uma ttica que pode reduzir ainda mais seu tempo de resposta para zero. 8.1.1.2.2.1. Tempo de Resposta Zero Ter um Tcnico Interno Dada a situao apropriada (voc um dos maiores clientes na rea), necessidades sucientes (qualquer tempo fora do ar inaceitvel) e recursos nanceiros (se voc precisa perguntar o preo, provavelmente no pode pagar), voc pode precisar de um tcnico interno por tempo integral. Os benefcios de ter um tcnico sempre presente so bvios:

Resposta instantnea a qualquer problema Uma ttica mais pr-ativa para a manuteno do sistema
Como esperado, esta opo pode ser muito cara, especialmente se voc requer um tcnico interno 24 horas por dia, 7 dias por semana. Mas, se esta ttica apropriada para sua empresa, voc deve ter alguns pontos em mente para tirar o mximo proveito. Primeiramente, tcnicos internos precisam de muitos dos recursos dos funcionrios regulares, como uma mesa de trabalho, telefone, cartes e/ou chaves de acesso apropriados e assim por diante. Os tcnicos internos no so muito teis se no tiverem as peas apropriadas. Sendo assim, certiquese de ter um armazenamento seguro parte para as peas do tcnico. Alm disso, assegure que o tcnico mantenha um estoque das peas apropriado para a sua congurao e que estas peas no sejam "canibalizadas" rotineiramente por outros tcnicos.
1.
E isto provavelmente seria o tempo de resposta na melhor das hipteses, j que os tcnicos geralmente so
responsveis por territrios que abrangem longas distncias em todas as direes. Se voc est numa extremidade do territrio e o nico tcnico disponvel est na outra extremidade, o tempo de resposta ser ainda mais longo.
152 8.1.1.2.3. Disponibilidade das Peas
Obviamente, a disponibilidade das peas tem um papel fundamental na limitao das falhas de hardware da sua empresa. No contexto de um contrato de servio, a disponibilidade das peas toma outra dimenso, j que aplica-se no somente sua empresa, mas a todos os outros clientes que tambm possam precisar destas peas no territrio do fabricante. Uma empresa, que tenha comprado mais hardware do fabricante que voc, pode receber tratamento preferencial no momento de obter peas (e tcnicos, por este motivo). Infelizmente, h pouco a fazer nestas circunstncias, alm de tentar resolver o problema com o gerente de servios. 8.1.1.2.4. Oramento Disponvel Conforme esplanado anteriormente, os contratos de servio variam de preo de acordo com a natureza dos servios oferecidos. Tenha em mente que os custos associados ao contrato de servio so despesas recorrentes; voc deve negociar um novo contrato e pagar novamente cada vez que o contrato estiver prestes a expirar. 8.1.1.2.5. Hardware a ser Coberto Esta uma rea na qual voc pode manter custos mnimos. Considere por um momento que voc negociou um contrato de servio que inclua um tcnico interno 24x7, peas reservas na empresa voc decide. Cada componente de hardware que voc comprou desta empresa coberto, incluindo o PC que a recepcionista utiliza para executar tarefas do cotidiano. Este PC precisa realmente ter algum interno 24x7? Mesmo que o PC seja vital para o trabalho da recepcionista, ela s trabalha das 9:00 s 17:00. muito improvvel que:

O PC esteja em uso das 17:00 s 9:00 da manh seguinte (sem falar nos nais de semana) Uma falha deste PC seja notada, exceto entre 9:00 e 17:00.
Sendo assim, pagar pela possibilidade deste PC precisar de servios num sbado noite um desperdcio de dinheiro. A melhor coisa a fazer dividir o contrato de servios de maneira que o hardware no crtico seja agrupado separadamente do hardware mais crtico. Desta maneira, os custos podem ser mantidos o mais baixos possvel.
Nota Se voc tem vinte servidores congurados identicamente que so crticos para sua empresa, voc pode ter um contrato de servios de alto nvel escrito para somente um ou dois, com o resto coberto por um contrato bem mais barato. Ento, seguindo este raciocnio, independente de qual servidor falhar num nal de semana, voc dir que aquele com servio de alto nvel. No faa isso. No apenas desonesto, mas a maioria dos fabricantes mantm registro destas coisas usando os nmeros de srie. Mesmo se voc descobrir uma maneira de burlar estas vericaes, gastar bem mais depois que for descoberto do que se for honesto e pagar pelo servio que realmente precisa.
153
8.1.2. Falhas de Software

Falhas de software podem resultar em tempos fora do ar mais longos. Por exemplo: os proprietrios de uma determinada marca computadores notvel por suas caractersticas de alta disponibilidade recentemente passaram por isso. Um erro (bug) no cdigo de time handling do sistema operacional do computador resultou na queda dos sistemas de cada um dos clientes numa determinada hora num certo dia. Apesar desta situao ser o exemplo mais espetacular de uma falha de software, outras falhas relativas ao software podem ser menos dramticas, mas to devastadoras quanto. As falhas de software podem ocorrer em uma destas duas reas:

Sistema operacional Aplicaes
Cada tipo de falha tem seus prprios impactos e explorada detalhadamente nas sees seguintes. 8.1.2.1. Falhas no Sistema Operacional Neste tipo de falha, o sistema operacional responsvel pelo rompimento do servio. As falhas no sistema operacional vm de duas reas:

Quedas Pendncias
A principal coisa a ter em mente sobre as falhas no sistema operacional que elas removem tudo que o computador estava rodando no momento da falha. Sendo assim, as falhas no sistema operacional podem ser devastadoras para a produo. 8.1.2.1.1. Quedas As quedas ocorrem quando o sistema operacional passa por uma condio de erro do qual no pode se recuperar. As razes de quedas podem variar da inabilidade de resolver um problema bsico de hardware a um erro (bug) no cdigo do kernel comprometendo o sistema operacional. Quando um sistema operacional cai, o sistema deve ser reinicializado para poder continuar a produo. 8.1.2.1.2. Pendncias Quando o sistema operacional para de executar os eventos do sistema, o sistema leva a uma parada. Isto conhecido como pendncia. As pendncias podem ser causadas por deadlocks (dois consumidores de recursos competindo por recursos que um outro possui) e livelocks (dois ou mais processos respondendo s atividades do outro, mas sem executar nenhum trabalho til), mas o resultado nal o mesmo uma falta de produtividade total.
8.1.2.2. Falhas nas Aplicaes Ao contrrio das falhas no sistema operacional, as falhas nas aplicaes podem ser mais limitadas no escopo de seu estrago. Uma nica aplicao falha, dependendo da aplicao, pode impactar somente uma pessoa. Por outro lado, se for uma aplicao de servidor servindo uma gama de aplicaes clientes, as consequncias de uma falha podem ser mais alastradas. As falhas nas aplicaes, assim como as do sistema operacional, podem acarretar em pendncias e quedas; a nica diferena que aqui a aplicao que est pendente ou caindo.
154 8.1.2.3. Obtendo Ajuda Suporte a Software
Assim como os fabricantes de hardware oferecem suporte para seus produtos, muitos fabricantes de software disponibilizam pacotes de suporte para seus clientes. Exceto pelas diferenas bvias (no necessrio hardware reserva e a maior parte do trabalho pode ser feito pelo pessoal do suporte atravs do telefone), os contratos de suporte a software podem ser bem parecidos aos de suporte a hardware. O nvel de suporte oferecido por um fabricante de software pode variar. Aqui esto algumas das estratgias de suporte mais comuns aplicadas hoje:

Documentao Auto-suporte Suporte via Internet ou e-mail Suporte telefnico Suporte na empresa (on-site)
Cada tipo de suporte descrito mais detalhadamente nas sees seguintes. 8.1.2.3.1. Documentao Apesar de frequentemente negligenciada, a documentao do software pode servir como uma ferramenta de suporte de primeiro nvel. Sendo online ou impressa, a documentao geralmente contm as informaes necessrias para resolver muitas questes. 8.1.2.3.2. Auto-suporte O auto-suporte baseia-se no cliente usar recursos online para resolver suas prprias questes relativas a software. Frequentemente, estes recursos tomam a forma de FAQs (Perguntas e Respostas Frequentes) na Internet ou bases de conhecimento (knowledge bases). Os FAQs geralmente tm pouca ou nenhuma capacidade de seleo, o que faz com que o cliente tenha que rolar de questo em questo na esperana de achar uma que atenda ao seu problema. As bases de conhecimento tendem a ser mais sosticadas de certa maneira, permitindo a insero de termos de procura. As bases de conhecimento tambm podem ser bastante extensas, tornando-as uma boa ferramenta para a soluo de problemas. 8.1.2.3.3. Suporte via Internet ou E-mail Muitas vezes, o que parece ser um site de auto-suporte tambm inclui formulrios baseados na Internet ou endereos de e-mail que possibilitam enviar perguntas ao pessoal do suporte. Apesar de, primeira vista, isto parecer uma melhoria de um bom site de auto-suporte, realmente depende das pessoas respondendo os e-mails. Se o pessoal do suporte est sobrecarregado, difcil obter as informaes necessrias atravs deles, j que sua preocupao principal responder rapidamente cada e-mail e seguir para o prximo. A razo disso que praticamente todos os funcionrios de suporte so avaliados pelo nmero de problemas que resolvem. difcil explicitar a intensidade das questes, pois h pouco a ser feito num e-mail para estimular respostas rpidas e teis especialmente quando a pessoa lendo seu e-mail est apressada para seguir ao prximo e-mail. A maneira de obter o melhor servio garantir que seu e-mail aborde todas as questes que um tcnico de suporte possa perguntar, tais como:

Descreva claramente a natureza do problema Inclua todos os nmeros de verses pertinentes
155
Descreva o que voc j fez para tentar resolver o problema (aplicou os ltimos consertos, reinicializou a mquina na congurao mnima, etc.)
Ao oferecer mais informaes ao tcnico de suporte, voc tem mais chances de obter o suporte que necessita. 8.1.2.3.4. Suporte Telefnico Como o nome implica, o suporte telefnico signica conversar com um tcnico de suporte via telefone. Este estilo de suporte mais parecido com o suporte a hardware; pode haver diversos nveis de suporte disponveis (com horas de cobertura e tempos de resposta diferentes, etc.). 8.1.2.3.5. Suporte na Empresa (on-site) Tambm conhecido como consultoria on-site, o suporte on-site ao software normalmente reservado para resolver as questes especcas ou efetuar mudanas crticas, como instalao e congurao do software inicial, grandes atualizaes e assim por diante. Como esperado, este o tipo mais caro de suporte ao software disponvel. Mesmo assim, h situaes em que o suporte na empresa (on-site) faz sentido. Como exemplo, considere uma empresa pequena com somente um administrador de sistemas. A empresa empregar seu primeiro servidor de banco de dados, mas a aplicao (e a empresa) no grande o suciente para justicar a contratao de um administrador de banco de dados dedicado. Nesta situao, pode ser mais barato trazer um especialista do fabricante de banco de dados para efetuar a aplicao inicial (e, talvez mais adiante, conforme a necessidade surgir) e ento treinar o administrador de sistemas para uma tcnica que ser usada raramente.
8.1.3. Falhas no Ambiente

Mesmo que o hardware esteja rodando perfeitamente, que o software esteja congurado corretamente e funcionando como deveria, os problemas ainda podem ocorrer. Os problemas mais comuns que ocorrem fora do prprio sistema tm relao com o ambiente fsico no qual o sistema reside. As questes ambientais podem ser divididas em quatro categorias principais:

Integridade da construo Eletricidade Ar condicionado Clima e o mundo externo
8.1.3.1. Integridade da Construo Para uma estrutura aparentemente simples, uma construo desempenha diversas funes. Oferece proteo dos elementos. Oferece o micro-clima adequado para o contedo do prdio. Tem mecanismos para oferecer energia e para proteger contra incndios, roubos e vandalismo. Desempenhando todas estas funes, no surpreendente o que pode dar errado com um prdio. Aqui esto algumas possibilidades a considerar:

Vazamentos no telhado podem alagar centros de dados. Diversos sistemas do prdio (como gua ou sistema de ar) podem falhar, tornando o edifcio inabitvel.
156
O cho pode ter capacidade de carga insuciente para suportar o equipamento que voc pretende colocar no centro de dados.
importante ter uma mente criativa ao pensar nas diversas maneiras que um edifcio pode falhar. A lista acima apenas pretende que voc comece a seguir esta linha de raciocnio. 8.1.3.2. Eletricidade Como a eletricidade o que move qualquer sistema de computador, as questes relacionadas energia so primordiais para a mente dos administradores de sistemas em todo lugar. H diversos aspectos diferentes da energia, que so abordados em detalhes nas sees seguintes. 8.1.3.2.1. A Segurana de Sua Energia Primeiramente, necessrio determinar o quo seguro seu abastecimento de energia deve ser. Assim como em quase todos os outros centros de dados, voc obtm sua energia de uma empresa local atravs de linhas transmissoras de energia. Por causa disso, h limites no que voc pode fazer para garantir que seu abastecimento principal de energia seja o mais seguro possvel.
Dica As empresas localizadas prximas aos limites de uma companhia energtica talvez possam negociar as conexes em duas sees de energia:
Aquela prestando servios na sua rea Aquela da companhia energtica vizinha
Os custos envolvidos em usar linhas de energia pela companhia energtica vizinha so grandes, tornando esta opo vivel somente para empresas grandes. No entanto, estas empresas descobrem que a redundncia obtida compensa os custos em muitos casos.
As principais coisas a vericar so os mtodos atravs dos quais a energia trazida at a sede de sua empresa e para dentro do edifcio. As linhas de transmisso esto acima ou abaixo do solo? Linhas acima do solo so suscetveis a:

Danos provocados por condies climticas extremas (geadas, ventos, relmpagos) Acidentes de trnsito que danicam os postes e/ou transformadores Animais que vagueiam nos lugares indevidos e provocam curto-circuitos nas linhas
Por outro lado, as linhas abaixo do solo tm suas prprias desvantagens:

Danos provocados por construtores escavando em lugares indevidos Enchente Relmpago (apesar de menos perigoso para linhas acima do solo)
Continue seguindo as linhas de energia para dentro de seu edifcio. Elas passam primeiro por um transformador externo? Este transformador est protegido dos carros ou rvores que possam cair? Todos os interruptores expostos esto protegidos contra o uso no autorizado? Uma vez dentro do edifcio, as linhas de energia (ou os painis aos quais esto ligadas) podem ter outros problemas? Por exemplo: um problema de encanamento pode inundar o quadro eltrico? Continue seguindo a energia para dentro do centro de dados. H algo mais que possa interromper o suprimento de energia inesperadamente? Por exemplo: o centro de dados divide um ou mais circuitos
157
com cargas que no pertenam a este? Se assim for, a carga externa pode, um dia, passar pela proteo de sobrecarga do circuito, derrubando tambm o centro de dados. 8.1.3.2.2. Qualidade da Energia No suciente garantir que a fonte de energia do centro de dados seja o mais segura possvel. Voc tambm deve preocupar-se com a qualidade da energia sendo distribuda pelo centro de dados. H diversos fatores que devem ser considerados: Voltagem A voltagem da energia de entrada deve ser estvel, sem redues de voltagem (frequentemente chamadas de quedas, abatimentos ou brownouts) ou aumentos de voltagem (geralmente conhecidos como picos e surges). Formato da onda O formato da onda deve ser limpo, com THD (Distoro Harmnica Total) mnima. Frequncia A frequncia deve ser estvel (a maioria dos pases utiliza a frequncia de 50Hz ou 60Hz). Rudo A energia no pode incluir nenhum rudo RFI (Interferncia na Frequncia de Rdio) ou EMI (Interferncia Eletro-Magntica). Corrente A energia deve ser suprida a uma taxa de corrente suciente para rodar o centro de dados. A energia suprida diretamente pela companhia energtica geralmente no atende aos padres necessrios para um centro de dados. Sendo assim, preciso algum nvel de condicionamento da energia. H diversas tticas possveis: Protetores contra picos de energia Protetores contra picos de energia fazem exatamente o que o nome implica eles ltram os picos do suprimento de energia. A maioria no faz mais nada, deixando o equipamento vulnervel aos danos de outros problemas relativos energia. Condicionadores de Energia Os condicionadores de energia tentam uma ttica mais detalhada. Dependendo da sosticao da unidade, os condicionadores de energia frequentemente podem resolver a maioria dos problemas citados acima. Gerador Um gerador basicamente um grande motor eltrico movido pelo seu suprimento de energia normal. O motor ligado a uma grande hlice, que por sua vez ligada a um gerador. O motor roda a hlice e o gerador, que gera eletricidade suciente para rodar o centro de dados. Desta maneira, a energia do centro de dados isolada eletricamente da energia externa, eliminando a maioria dos problemas relativos energia. A hlice tambm oferece a habilidade de manter a energia durante a falta de eletricidade, j que leva vrios segundos para a hlice reduzir sua velocidade at o ponto no qual no pode mais gerar energia.
158 Suprimentos de Energia Ininterruptos
Alguns Suprimentos de Energia Ininterruptos (mais comumente conhecidos como UPSs) incluem a maioria (se no todas) das funes de proteo de um condicionador de energia 2 . Com as duas tecnologias listadas acima, ns iniciamos o tpico no qual a maioria das pessoas pensa ao falar sobre energia energia backup. Na prxima seo, exploraremos tticas diferentes para prover energia backup. 8.1.3.2.3. Energia Backup H um termo relativo energia no qual quase todos j ouviram falar blackout. Um blackout a perda total da energia eltrica e pode durar de uma frao de segundo a semanas. Como a durao do blackout pode variar drasticamente, necessrio utilizar a ttica de prover energia backup usando tecnologias diferentes para faltas de energia de duraes diferentes.
Dica Os blackouts mais frequentes duram, em mdia, alguns segundos; faltas de energia mais longas so menos frequentes. Sendo assim, concentre primeiro em proteger seus sistemas contra blackouts de alguns segundos de durao, e ento trabalhe nos mtodos para reduzir sua exposio faltas mais longas.
8.1.3.2.3.1. Provendo Energia Para os Prximos Segundos J que a maioria das faltas de energia duram somente alguns segundos, sua soluo de energia backup deve ter duas caractersticas principais:

Tempo bem curto para trocar para energia backup (conhecido como tempo de transferncia) Um tempo de execuo (o tempo que a energia backup durar) medido de segundos a minutos
As solues de energia backup que atendem a estas caractersticas so os geradores e UPSs. A hlice do gerador permite que este continue produzindo eletricidade por tempo suciente para faltas de energia de aproximadamente um segundo. Os geradores tendem a ser bem grandes e caros, o que os torna prticos para empresas de mdio e grande porte. Entretanto, uma outra tecnologia chamada UPS pode servir para situaes nas quais o gerador muito caro. O UPS tambm pode lidar com faltas de energia mais longas. 8.1.3.2.3.2. Provendo Energia Para os Prximos Minutos Os UPSs podem ser adquiridos em diversos tamanhos sucientemente pequeno para rodar um PC por cinco minutos ou sucientemente grande para prover energia para um centro de dados inteiro por uma hora ou mais. Os UPSs so compostos das seguintes partes:

Um interruptor de transferncia para mudar da fonte de energia principal para a fonte de energia backup Uma bateria, para prover energia backup
A tecnologia UPS abordada em mais detalhes na Seo 8.1.3.2.3.2.
2.
159
Um conversor, que converte a corrente DC da bateria em corrente AC necessria para o hardware do centro de dados
Alm do tamanho e capacidade da bateria da unidade, os UPSs tm dois tipos bsicos:

O UPS ofine usa seu conversor para gerar energia somente quando o suprimento de energia principal falhar. O UPS online usa seu conversor para gerar energia o tempo todo, provendo energia para seu conversor atravs de sua bateria somente quando o suprimento de energia principal falhar.
Cada tipo tem suas vantagens e desvantagens. O UPS ofine geralmente mais barato, porque o conversor no precisa ser construdo para operao em tempo integral. No entanto, um problema no conversor de um UPS ofine passar desapercebido (ou seja, at a prxima falta de energia). Os UPSs online tendem a ser melhores em prover energia limpa para o seu centro de dados; anal de contas, um UPS online basicamente gera energia o tempo todo para voc. Independente do tipo de UPS que voc escolher, necessrio dimension-lo corretamente para sua carga antecipada (assim garantindo que o UPS tenha capacidade suciente para produzir eletricidade na voltagem e corrente necessrias) e voc deve determinar durante quanto tempo deseja ter a habilidade de rodar seu centro de dados com a energia da bateria. Para determinar esta informao, voc deve primeiramente identicar as cargas que sero servidas pelo UPS. Verique em cada componente do equipamento o montante de energia que gasta (isto normalmente especicado numa etiqueta prximo ao cabo de energia). Anote a voltagem, watts e/ou amps. Quando voc tiver estes dados para todos os componentes de hardware, deve convertlos para VA (Volt-Amps). Se voc tiver um nmero de watts, pode us-lo como o VA; se tiver amps, multiplique-o por volts para obter o VA. Ao adicionar os valores VA, possvel obter a taxa VA aproximada necessria para o UPS.
Nota Na verdade, esta ttica para calcular o VA no est totalmente correta; no entanto, para obter o VA verdadeiro necessrio saber o fator de energia de cada unidade, e esta informao raramente provida. Em todo caso, os nmeros VA obtidos com esta ttica reetem os valores nas piores situaes, deixando uma grande margem de erro para segurana.
Determinar o tempo de execuo uma questo mais de negcios que tcnica contra quais tipos de queda voc deseja se proteger e quanto pretende gastar para tanto? A maioria das empresas seleciona tempos de execuo menores que uma ou duas horas no mximo, pois a energia backup provida pela bateria torna-se muito cara alm deste ponto. 8.1.3.2.3.3. Provendo Energia Para as Prximas Horas (e Alm) Quando atingirmos as quedas de energia medidas em dias, as opes tornam-se ainda mais caras. As tecnologias com capacidade de lidar com quedas de energia de longo prazo so limitadas a geradores movidos por algum tipo de motor principalmente, a diesel e turbina a gs.
Nota Tenha em mente que os geradores movidos a motores requerem o reabastecimento constante enquanto esto ligados. Voc deve saber qual a taxa de "consumo" de combustvel do seu gerador na capacidade mxima e coordenar a entrega apropriada de combustvel.
160
Neste ponto, voc tem um grande leque de opes, assumindo que sua empresa tenha o oramento necessrio. Esta tambm uma rea na qual os peritos devem ajud-lo a determinar a melhor soluo para a empresa. Somente alguns administradores de sistemas tem o conhecimento especializado necessrio para planejar a aquisio e aplicao destes tipos de sistemas de gerao de energia.
Dica Geradores portteis de todos os tamanhos podem ser alugados, possibilitando ter os benefcios da energia do gerador sem a despesa inicial para adquirir um. No entanto, tenha em mente que nos desastres que afetam sua vizinhana em geral, os geradores podero estar em falta para alugar e muito caros.
8.1.3.2.4. Planejamento para Quedas Extensas Enquanto um blackout de cinco minutos algo mais do que um inconveniente para os funcionrios num escritrio escuro, o que ocorre com uma queda de uma hora? E de cinco horas? Um dia? Uma semana? De fato, mesmo se o centro de dados estiver operando normalmente, uma queda de energia extensa poder afetar sua empresa em algum momento. Considere os seguintes pontos:

E se no houver energia para manter o controle ambiental no centro de dados? E se no houver energia para manter o controle ambiental no edifcio inteiro? E se no houver energia para operar estaes de trabalho, sistema de telefonia e/ou luzes?
A questo determinar at que ponto uma queda deve ser tolerada em sua empresa. Ou, se esta no for uma opo, sua empresa deve considerar operar completamente independente da energia dentro da empresa por perodos extensos, o que signica que geradores muito grandes sero necessrios para prover energia para o edifcio inteiro. Obviamente, mesmo esse nvel de planejamento no pode ser feito do nada. muito provvel que o que causou a queda extensa tambm est afetando o mundo externo sua empresa, e que o mundo externo comear a afetar a habilidade da sua empresa em continuar operando, mesmo que tenha capacidade ilimitada de gerao de energia.
8.1.3.3. Aquecimento, Ventilao e Ar Condicionado Os sistemas de Aquecimento, Ventilao e Ar Condicionado (Heating, Ventilation, and Air Conditioning - HVAC) usados nos edifcios hoje em dia so incrivelmente sosticados. Geralmente controlado por computadores, o sistema HVAC vital para prover um ambiente de trabalho confortvel. Os centros de dados geralmente possuem equipamento prprio de refrigerao, principalmente para remover o calor gerado pelos diversos computadores e outros equipamentos. As falhas no sistema HVAC podem ser devastadoras para a operao contnua de um centro de dados. Dada sua complexidade e natureza eletro-mecnica, as possibilidades de falha so muitas e variadas. Aqui esto alguns exemplos:
As unidades de refrigerao (basicamente ventiladores grandes movidos por grandes motores eltricos) podem falhar devido a sobrecarga eltrica, falha no rolamento, falha na correia/roldana, etc.
161
As unidades de refrigerao (frequentemente chamadas de chillers) podem perder sua refrigerao devido a vazamentos, ou a problemas em seus motores e/ou compressores.
O reparo e a manuteno do sistema HVAC so reas muito especializadas reas que um administrador de sistemas deve deixar para os peritos. De qualquer maneira, um administrador de sistemas deve garantir que o equipamento HVAC do centro de dados seja vericado diariamente (ou com mais frequncia) e seja mantido de acordo com as intrues do fabricante. 8.1.3.4. Fatores Climticos e o Mundo Externo H alguns fatores climticos que podem causar problemas ao administrador de sistemas:
Muita neve e gelo podem impedir que funcionrios cheguem ao centro de dados, e podem inclusive entupir os condensadores do ar condicionado, resultando em temperaturas elevadas no centro de dados exatamente quando ningum consegue chegar at l para tomar as devidas providncias. Ventos fortes podem interromper a energia e as comunicaes; ventos muito fortes podem, na realidade, danicar o prprio edifcio.
H outros fatores climticos que podem causar problemas. Por exemplo: temperaturas excessivamente altas podem resultar em sistemas de refrigerao sobrecarregados, brownouts ou blackouts, conforme o consumo de energia ca sobrecarregado. Apesar de no haver muito a fazer sobre os fatores climticos, saber como eles podem afetar as operaes de seu centro de dados pode ajud-lo a mant-lo em funcionamento mesmo quando o clima estiver muito ruim.
8.1.4. Erros Humanos

J foi dito que os computadores realmente so perfeitos. A razo dessa armao , que se voc investigar a fundo, descobrir um erro humano por trs de todo erro do computador. Nesta seo, exploramos os tipos de erros humanos mais comuns e seus impactos. 8.1.4.1. Erros de Usurios Finais Os usurios de um computador podem cometer erros com srios impactos. No entanto, devido seu ambiente operacional normalmente desprivilegiado, os erros de usurios tendem a ser localizados. Como a maioria dos usurios interage com um computador exclusivamente atravs de uma ou mais aplicaes, dentro das aplicaes que a maioria dos erros de usurios nais ocorre. 8.1.4.1.1. Uso Imprprio das Aplicaes Quando as aplicaes so usadas impropriamente, vrios problemas podem ocorrer:

Arquivos sobrescritos inadvertidamente Dados errados usados como input numa aplicao Arquivos nomeados e organizados de maneira confusa Arquivos apagados acidentalmente
Poderamos continuar esta lista, mas isso suciente para ilustrar a questo. Devido o fato de usurios no terem privilgios de super-usurio, os erros cometidos por eles geralmente limitam-se aos seus prprios arquivos. Sendo assim, a malhor ttica bifurcada:
Educar os usurios no uso apropriado de suas aplicaes e tcnicas de administrao de arquivos
162
Garantir que os backups dos arquivos dos usurios sejam feitos regularmente e que o processo de restaurao seja o mais simples e rpido possvel
Alm disso, h pouco a fazer para limitar os erros dos usurios.
8.1.4.2. Erros de Funcionrios Operacionais Os operadores tem uma relao mais profunda com os computadores da empresa que os usurios nais. Enquanto os usurios nais tendem a se basear nas aplicaes, os operadores tendem a executar um leque de tarefas mais abrangente. Mesmo que a natureza das tarefas tenha sido ditada por outras pessoas, algumas das tarefas podem incluir o uso de utilitrios a nvel do sistema, onde maior o potencial de grandes danos por causa de erros. Consequentemente, os tipos de erros que podem ser cometidos por um operador baseiam-se na sua habilidade em seguir os procedimentos desenvolvidos para este uso. 8.1.4.2.1. Falha em Seguir Procedimentos Os operadores devem ter conjuntos de procedimentos documentados e disponveis para praticamente todas as aes que executam 3. Pode acontecer de um operador no seguir os procedimentos conforme so apresentados. Podem haver diversas razes para isso:
O ambiente foi alterado em algum momento do passado e os procedimentos no foram atualizados. Agora o ambiente mudou novamente, tornando invlidos os procedimentos memorizados pelo operador. Neste ponto, mesmo que os procedimentos tenham sido atualizados (o que improvvel, j que no foram atualizados anteriormente), o operador no estar ciente disso. O ambiente foi alterado e no h procedimentos. Esta uma situao ainda mais fora de controle que a anterior. Os procedimentos existem e esto corretos, mas o operador no os seguir (ou no poder segulos).
Dependendo da estrutura gerencial de sua empresa, talvez voc no possa fazer nada alm de comunicar suas preocupaes ao gerente apropriado. Em todo caso, a melhor ttica colocar-se disposio para fazer o que puder para resolver o problema. 8.1.4.2.2. Erros Cometidos Durante os Procedimentos Mesmo se o operador seguir os procedimentos, e mesmo que os procedimentos estejam corretos, ainda possvel que erros ocorram. Se isto acontecer, existe a possibilidade do operador ter sido displicente (neste caso a gerncia do operador deve ser envolvida). Uma outra explicao que foi apenas um erro. Nestes casos, os melhores operadores percebem que algo est errado e procuram por ajuda. bom sempre encorajar os operadores com quem voc trabalha a contatar as pessoas apropriadas imediatamente, se suspeitarem que algo est errado. Apesar de alguns operadores serem altamente qualicados e capazes de resolverem muitos problemas sozinhos, o fato que este no o trabalho deles. A boa vontade do operador pode piorar o problema, prejudicar a carreira dele e tambm a sua habilidade em resolver rapidamente o que, originalmente, talvez fosse um pequeno problema.
3.
Se os operadores de sua empresa no possuem um conjunto de procedimentos operacionais, trabalhe com
eles, com a gerncia e com seu usurios para cri-los. Sem eles, um centro de dados est fora de controle e propenso a ter problemas srios no dia-a-dia das operaes.
Captulo 8. Planejamento para Desastres 8.1.4.3. Erros do Administrador de Sistemas
163
Ao contrrio dos operadores, os administradores de sistemas executam uma grande variedade de tarefas usando os computadores de uma empresa, e estas tarefas frequentemente no so baseadas em procedimentos documentados. Consequentemente, os administradores de sistemas algumas vezes executam trabalho desnecessrio quando no tomam cuidado com o que fazem. No curso de suas responsabilidades do dia-a-dia, os administradores de sistemas tm suciente acesso aos sistemas (sem mencionar seus privilgios de super-usurio) para derrub-los por engano. Os administradores de sistemas cometem erros de m congurao ou erros durante a manuteno. 8.1.4.3.1. Erros de M Congurao Os administradores de sistemas frequentemente precisam congurar vrios aspectos de um sistema. Esta congurao pode incluir:

E-mail Contas de usurios Rede Aplicaes
A lista poderia continuar. A tarefa de congurar em si varia enormemente; algumas requerem editar um arquivo texto (usando qualquer uma das centenas de sintaxes diferentes do arquivo de congurao), enquanto outras tarefas requerem executar um utilitrio de congurao. O fato de estas tarefas serem feitas de maneiras diferentes simplesmente um desao adicional ao fato de cada tarefa de congurao requerer um conhecimento diferente. Por exemplo: o conhecimento necessrio para congurar um agente de transportte de correio (mail transport agent) fundamentalmente diferente de congurar uma nova conexo de rede. Sendo assim, talvez seja surpreendente que apenas alguns erros sejam cometidos. De qualquer maneira, a congurao , e continuar sendo, um desao para administradores de sistemas. H algo a fazer para tornar o processo menos suscetvel a erros? 8.1.4.3.1.1. Controle de Mudanas Um aspecto comum de toda congurao que sempre h alteraes. Independente de ser uma pequena ou grande alterao, deve ser tratada de maneira especca. Muitas empresas implementam algum tipo de processo de controle de alteraes. A inteno auxiliar administradores de sistemas (e todas as partes afetadas pela alterao) a gerenciar o processo de alterao e reduzir a exposio da empresa a erros que possam ocorrer. Um processo de controle de alteraes geralmente divide a alterao em dois passos. Aqui est um exemplo: Pesquisa preliminar Tentativas de pesquisa preliminar para denir claramente:

A natureza da alterao a ocorrer Seu impacto, caso a alterao realmente ocorra Uma posio de resguarda, se a alterao falhar Uma avaliao dos possveis tipos de falha
164
Captulo 8. Planejamento para Desastres A pesquisa preliminar pode incluir testes da alterao proposta durante um tempo fora do ar agendado, ou pode incluir a implementao da alterao primeiramente num ambiente de teste especial executado em hardware de teste.
Agendamento A alterao examinada tendo em mente a mecnica da implementao. O agendamento inclui apontar a sequncia e o tempo da alterao (juntamente a sequncias e tempos de quaisquer passos necessrios para retornar ao estado original caso ocorra algum problema), e tambm garantir que o tempo alocado para a alterao suciente e no conitante com nenhuma outra atividade no nvel do sistema. O produto deste processo frequentemente uma lista de passos para o administrador de sistemas usar enquanto executa a alterao. Juntamente a cada um dos passos, incluimos as instrues para retornar ao estado original, caso a alterao falhar. Os tempos estimados tambm so inclusos, facilitando ao administrador de sistemas determinar se o trabalho est dentro do prazo ou no. Execuo Neste ponto, a execuo dos passos necessrios para implementar a alterao deve ser simples e anti-climtica. A alterao ento implementada ou, se houver problemas, abortada. Monitoramento Independente da alterao ser implementada ou no, o ambiente monitorado para garantir que tudo est sendo operado devidamente. Documentando Se a alterao foi implementada, toda a documentao existente deve ser atualizada para reetir a congurao alterada. Obviamente, nem todas as alteraes requerem este nvel de detalhe. Criar uma nova conta de usurio no deve requerer nenhuma pesquisa preliminar e o agendamento deve consistir em determinar se o administrador de sistemas tem um tempinho para criar a conta. A execuo tambm deve ser rpida; o monitoramento deve se restringir a garantir que a conta utilizvel e a documentao provavelmente seria enviar um e-mail ao gerente do novo usurio. Mas, conforme as alteraes de congurao tornam-se mais complexas, necessrio ter um processo de controle de alteraes mais formal.
8.1.4.3.2. Erros Cometidos Durante a Manuteno Este tipo de erro pode ser malco porque geralmente h muito pouco planejamento e registro feitos durante a manuteno diria. Os administradores de sistemas vem diariamente os resultados deste tipo de erro, especialmente cometidos por muitos usurios que juram no alterarem nada o computador simplesmente quebrou. O usurio que diz isso geralmente no lembra o que fez, e quando o mesmo acontece com voc, provavelmente voc tambm no lembrar. A principal questo que voc deve ser capaz de lembrar das alteraes efetuadas durante a manuteno, se for capaz de resolver qualquer problema rapidamente. Um processo de controle completo no adequado para as centenas de coisas pequenas feitas ao longo do dia. O que pode ser feito para manter o registro das 1001 coisas pequenas que um administrador de sistemas faz todos os dias? A resposta simples tome nota. Independentemente de ser anotado num caderno, num PDA ou como comentrios nos arquivos afetados, anote! Ao registrar o que voc fez, tem maiores chances de relacionar uma falha a uma alterao recentemente efetuada.
Captulo 8. Planejamento para Desastres 8.1.4.4. Erros do Tcnico de Servio
165
s vezes, as pessoas que supostamente te ajudariam a manter seus sistemas rodando conavelmente, podem tornar as coisas piores. Isto no se deve a nenhuma conspirao; simplesmente qualquer um trabalhando em alguma espcie de tecnologia tem o risco de tornar esta tecnologia inoperante. O mesmo efeito pode ocorrer no ambiente de trabalho, quando os programadores consertam um bug e acabam criando outro. 8.1.4.4.1. Hardware Consertado Inapropriadamente Neste caso, o tcnico falhou em diagnosticar o problema corretamente e efetuou um conserto desnecessrio (e intil), ou o diagnstico estava correto, mas o conserto no foi efetuado apropriadamente. Pode ser que a pea substituda estava com defeito, ou que o procedimento apropriado no foi seguido durante o conserto. Por isso importante estar ciente do que os tcnicos esto fazendo todo o tempo. Ao fazer isso, voc pode estar atento a falhas que parecem estar relacionadas ao problema original de alguma maneira. Isto mantm o registro do tcnico caso haja algum problema; caso contrrio h uma chance do tcnico ver esta falha como nova e no relacionada quela supostamente consertada. Desta maneira, no perde-se tempo vericando o problema errado. 8.1.4.4.2. Consertando Uma Coisa e Quebrando Outra s vezes, mesmo que o problema seja diagnosticado e consertado com sucesso, aparece outro problema para tomar seu lugar. O mdulo da CPU foi substitudo, mas o saco anti-esttico no qual ele estava embrulhado foi deixado dentro do cabinete, bloqueando o ventilador e causando um desligamento por causa da temperatura elevada. Ou ento o drive falho do disco no conjunto RAID foi substitudo, mas como um conector em outro drive foi esbarrado e acidentalmente desconectado, o conjunto ainda est com problemas. No importa se estas coisas so resultado de descuido crnico ou simplesmente um erro honesto. Voc deve sempre rever cuidadosamente os consertos feitos pelo tcnico e garantir que o sistema esteja funcionando corretamente antes que o tcnico v embora.
8.2. Backups
Os backups tem dois objetivos principais:

Permitir a recuperao de arquivos individuais Permitir a recuperao de sistemas de arquivo inteiros de uma s vez
O primeiro objetivo a base do tpico pedido de recuperao de arquivo: um usurio apaga acidentalmente um arquivo e pede que seja recuperado pelo ltimo backup. As circunstncias exatas podem variar, mas este o uso cotidiano mais comum para backups. A segunda situao o pior pesadelo do administrador de sistemas: por alguma razo, o administrador de sistemas est mexendo no hardware que era uma parte produtiva do centro de dados. Agora, algo mais do que um pedao de ao e silicone. O que falta so todos os software e dados que voc e seus usurios vem desenvolvendo ao longo dos anos. Supostamente, h backup de tudo. A questo : h realmente este backup? E se houver, voc capaz de recuper-lo?
166
8.2.1. Dados Diferentes: Necessidades Diferentes de Backup

Atente para os tipos de dados4 processados e armazenados por um sistema de computador tpico. Note que alguns dados quase nunca mudam, e outros esto em mudana constante. A velocidade na qual os dados so alterados crucial para desenvolver um procedimento de backup. H duas razes para isso:

Um backup nada mais do que uma imagem instantnea dos dados sendo copiados. um reexo dos dados em um determinado momento. Dados que so alterados com pouca frequncia podem ter backups com pouca frequncia, enquanto dados com alteraes frequentes devem ter backups mais frequentes.
Os administradores de sistemas que tm um bom conhecimento de seus sistemas, usurios e aplicaes devem ser capazes de agrupar os dados em categorias diferentes nos seus sistemas. No entanto, aqui esto alguns exemplos para que voc possa comear: Sistema Operacional Estes dados so normalmente alterados somente durante atualizaes (upgrades), instalaes de consertos de erros (bug xes) e quaisquer modicaes especcas da empresa.
Dica Voc deve se importar com backups do sistema operacional? Esta uma questo que muitos administradores de sistemas vm ponderando ao longo dos anos. De um lado, se o processo de instalao relativamente fcil, e se a aplicao de consertos de erros e personalizaes so bem documentadas e de fcil reproduo, reinstalar o sistema operacional pode ser uma opo vivel. Por outro lado, se h alguma dvida que uma nova instalao pode recriar o ambiente do sistema operacional original, fazer backup do sistema operacional a melhor opo, mesmo que os backups sejam feitos com menor frequncia que os backups dos dados de produo. Backups ocasionais do sistema operacional tambm podem ser prticos quando apenas alguns arquivos do sistema precisarem ser restaurados (ex.: devido remoo acidental de arquivos).
Software da Aplicao Estes dados so alterados sempre que as aplicaes so instaladas, atualizadas ou removidas. Dados das Aplicaes Estes dados so alterados com a mesma frequncia que as aplicaes so utilizadas. Dependendo da aplicaco e da sua empresa, isto pode signicar que as alteraes ocorrem a cada segundo ou uma vez no nal de cada ano scal. Dados dos Usurios Estes dados alteram de acordo com os padres de uso da sua comunidade de usurios. Na maioria das empresas, isto signica que as alteraes ocorrem toda hora. Baseando-se nestas categorias (e outras especcas sua empresa), voc deve ter uma boa idia sobre a natureza dos backups necessrios para proteger seus dados.
4.
Estamos usando o termo dados nesta seo para descrever tudo o que processado atravs do software de
backup. Isto inclui o software do sistema operacional, o software da aplicao e tambm os dados atuais. No importa o que so; desde que a preocupao seja software de backup, tudo so dados.
167
Nota Voc deve ter em mente que a maioria dos software de backup lida com os dados no nvel do diretrio ou sistema de arquivo. Em outras palavras, a estrutura dos diretrios de seu sistema inuenciam o modo como os backups sero feitos. Esta uma outra razo para pensar cuidadosamente na melhor estrutura de diretrios para um novo sistema e agrupar arquivos e diretrios de acordo com seu uso antecipado.
8.2.2. Software de Backup: Comprar versus Criar

Para executar backups, necessrio ter primeiramente o software apropriado. Este software deve no somente executar a tarefa bsica de copiar bits em mdia de backup, mas tambm interagir claramente com os funcionrios e necessidades de sua empresa. Aqui esto algumas caractersticas a considerar ao analisar o software de backup:

Agenda os backups para rodarem num horrio apropriado Administra a localizao, rotao e o uso da mdia de backup Trabalha com operadores (e/ou com alteradores de mdia robtica) para garantir que a mdia apropriada est disponvel Auxilia os operadores na localizao da mdia contendo o backup especco de um determinado arquivo
Como voc pode ver, uma boa soluo de backup signica bem mais do que somente enviar bits para sua mdia de backup. Neste ponto, a maioria dos administradores de sistemas procura por uma das duas solues:

Comprar uma soluo desenvolvida comercialmente Criar um sistema de backup internamente do zero (possivelmente intergrando uma ou mais tecnologias open source)
Cada uma destas tticas tem seus pontos fortes e fracos. Dada a complexidade do trabalho, uma soluo criada internamente provavelmente no atender alguns aspectos (como administrao da mdia ou ter documentao detalhada e suporte tcnico) apropriadamente. Entretanto, para algumas empresas, isto pode no ser uma desvantagem. Uma soluo desenvolvida comercialmente provavelmente altamente funcional, mas tambm pode ser muito complexa para as necessidades atuais da empresa. Sendo assim, a complexidade pode possibilitar continuar com a mesma soluo conforme a empresa crescer. Portanto, no existe um sistema de backup claramente indicado para todos os casos. A nica dica pedir que voc considere estes pontos:
Mudar o software de backup difcil; uma vez implementado, voc o utilizar por um bom tempo. Acima de tudo, voc ter backups arquivados por um longo tempo que possa ler. Mudar o software de backup signica que voc ter que manter o software original (para acessar os backups arquivados), ou dever converter seus backups arquivados para serem compatveis com o software novo. Dependendo do software de backup, o esforo envolvido em converter os backups arquivados pode ser to simples (mas demorado) quanto rodar os backups atravs de um programa de converso j existente, ou pode ser necessria engenharia reversa no formato do backup e desenvolver software personalizado para executar a tarefa.
168
O software deve ser 100% convel deve fazer o backup do que for necessrio e quando for necessrio. Quando chegar o momento de restaurar quaisquer dados seja um arquivo ou um sistema de arquivos inteiro o software de backup deve ser 100% convel.
8.2.3. Tipos de Backups

Se voc perguntar a algum que no familiarizado com backups, a maioria pensar que um backup somente uma cpia idntica de todos os dados do computador. Em outras palavras, se um backup foi criado na noite de tera-feira, e nada mudou no computador durante o dia todo na quarta-feira, o backup criado na noite de quarta seria idntico quele criado na tera. Apesar de ser possvel congurar backups desta maneira, mais provvel que voc no o faa. Para entender mais sobre este assunto, devemos primeiro entender os tipos diferentes de backup que podem ser criados. Estes so:

Backups completos Backups incrementais Backups diferenciais
8.2.3.1. Backups Completos O tipo de backup abordado no incio desta seo conhecido como um backup completo. Este tipo consiste no backup de todos os arquivos para a mdia de backup. Conforme mencionado anteriormente, se os dados sendo copiados nunca mudam, cada backup completo ser igual aos outros. Esta similaridade ocorre devido o fato que um backup completo no verica se o arquivo foi alterado desde o ltimo backup; copia tudo indiscriminadamente para a mdia de backup, tendo modicaes ou no. Esta a razo pela qual os backups completos no so feitos o tempo todo todos os arquivos so gravados na mdia de backup. Isto signica que uma grande parte da mdia de backup usada mesmo que nada tenha sido alterado. Fazer backup de 100 gigabytes de dados todas as noites quando talvez 10 gigabytes de dados foram alterados no uma boa prtica; por este motivo os backups incrementais foram criados. 8.2.3.2. Backups Incrementais Ao contrrio dos backups completos, os backups incrementais primeiro vericam se o horrio de alterao de um arquivo mais recente que o horrio de seu ltimo backup. Se no for, o arquivo no foi modicado desde o ltimo backup e pode ser ignorado desta vez. Por outro lado, se a data de modicao mais recente que a data do ltimo backup, o arquivo foi modicado e deve ter seu backup feito. Os backups incrementais so usados em conjunto com um backup completo frequente (ex.: um backup completo semanal, com incrementais dirios). A vantagem principal em usar backups incrementais que rodam mais rpido que os backups completos. A principal desvantagem dos backups incrementais que para restaurar um determinado arquivo, pode ser necessrio procurar em um ou mais backups incrementais at encontrar o arquivo. Para restaurar um sistema de arquivo completo, necessrio restaurar o ltimo backup completo e todos os backups incrementais subsequentes. Numa tentativa de diminuir a necessidade de procurar em todos os backups incrementais, foi implementada uma ttica ligeiramente diferente. Esta conhecida como backup diferencial.
Captulo 8. Planejamento para Desastres 8.2.3.3. Backups Diferenciais
169
Backups diferenciais so similares aos backups incrementais pois ambos podem fazer backup somente de arquivos modicados. No entanto, os backups diferenciais so acumulativos em outras palavras, no caso de um backup diferencial, uma vez que um arquivo foi modicado, este continua a ser incluso em todos os backups diferenciais (obviamente, at o prximo backup completo). Isto signica que cada backup diferencial contm todos os arquivos modicados desde o ltimo backup completo, possibilitando executar uma restaurao completa somente com o ltimo backup completo e o ltimo backup diferencial. Assim como a estratgia utilizada nos backups incrementais, os backups diferenciais normalmente seguem a mesma ttica: um nico backup completo peridico seguido de backups diferenciais mais frequentes. O efeito de usar backups diferenciais desta maneira que estes tendem a crescer um pouco ao longo do tempo (assumindo que arquivos diferentes foram modicados entre os backups completos). Isto posiciona os backups diferenciais em algum ponto entre os backups incrementais e os completos em termos de velocidade e utilizao da mdia de backup, enquanto geralmente oferecem restauraes completas e de arquivos mais rpidas (devido o menor nmero de backups onde procurar e restaurar). Dadas estas caractersticas, os backups diferenciais merecem uma considerao cuidadosa.
8.2.4. Mdia de Backup

Ns fomos muito cuidadosos ao usar o termo "mdia de backup" no decorrer das sees anteriores. H uma razo para isso. A maioria dos administradores de sistemas experientes geralmente pensam em backups em termos de leitura e gravao de tas, mas atualmente h outras opes. Houve um tempo em que os dispositivos de ta eram os nicos dispositivos de mdia removveis que podiam ser usados para backups. No entanto, isto mudou. Nas sees seguintes, veremos as mdias de backup mais conhecidas e assim como suas vantagens e desvantagens. 8.2.4.1. Fita A ta foi o primeiro meio de armazenamento de dados removvel amplamente utilizado. Tem os benefcios de custo baixo e uma capacidade razoavelmente boa de armazenamento. Entretanto, a ta tem algumas desvantagens est sujeita ao desgaste e o acesso aos dados na ta sequencial por natureza. Estes fatores signicam que necessrio manter o registro do uso das tas (aposent-las ao atingirem o m de suas vidas teis) e tambm que a procura por um arquivo especco nas tas pode ser uma tarefa longa. Por outro lado, a ta uma das mdias de armazenamento em massa mais baratas e carrega uma longa reputao de conabilidade. Isto signica que criar uma biblioteca de tas de tamanho razovel no abocanha uma parcela grande de seu oramento, e voc pode conar no seu uso atual e futuro. 8.2.4.2. Disco Nos ltimos anos, os drives de disco nunca seriam usados como um meio de backup. No entanto, os preos de armazenamento caram a um ponto que, em alguns casos, usar drives de disco para armazenamento de backup faz sentido. A razo principal para usar drives de disco como um meio de backup a velocidade. No h um meio de armazenamento em massa mais rpido. A velocidade pode ser um fator crtico quando a janela de backup do seu centro de dados curta e a quantidade de dados a serem copiados grande. Mas o armazenamento em disco no o meio ideal de backup, por diversas razes:
170
Os drives de disco normalmente no so removveis. Um fator essencial para uma estratgia de backup efetiva ter os backups fora do seu centro de dados e mant-los em alguma forma de armazenamento fora da emrpesa. Um backup do seu banco de dados de produo h um metro de distncia do banco de dados propriamente dito no um backup; uma cpia. As cpias no so muito teis, caso o centro de dados e seu contedo (incluindo suas cpias) seja danicado ou destrudo por um conjunto de infortnios. Os drives de disco so caros (ao menos se comparados a outras mdias de backup). Pode haver situaes onde o dinheiro no o problema, mas em todas as outras situaes, as despesas associadas ao uso de drives de disco para backup signicam que o nmero de cpias de backup deve ser baixo para manter o custo total dos backups tambm baixo. Um nmero menor de cpias de backup signica redundncia menor, caso um backup no seja legvel por alguma razo. Os drives de disco so frgeis. Mesmo se voc gastar dinheiro extra com drives de disco removveis, sua fragilidade pode ser um problema. Se voc derrubar um drive de disco no cho, perde seu backup. possvel adquirir estojos especiais que podem reduzir (mas no eliminar totalmente) este problema, mas isto encarece ainda mais esta opo. Os drives de disco no so mdia de arquivamento. Mesmo assumindo que voc seja capaz de resolver todos os outros problemas associados aos backups em drives de disco, voc deve considerar o seguinte. A maioria das empresas tem requisitos legais bastante severos para a manuteno de registros disponveis por determinados perodos de tempo. A chance de obter dados utilizveis de uma ta de 20 anos atrs muito maior que a chance de obter dados utilizveis de um drive de disco de 20 anos. Por exemplo: voc ainda teria o hardware necessrio para conect-lo ao seu sistema? Outra coisa a considerar que um drive de disco muito mais complexo que um cartucho de ta. Qual a chance de um motor de 20 anos rodar um drive de disco de 20 anos, acessando as heads de leitura e gravao de 20 anos sem que nenhum componente apresente problemas aps estarem ociosos por estes 20 anos?
Nota Alguns centros de dados fazem backup para drives de disco e ento, quando os backups esto completos, so gravados em ta para propsitos de arquivamento. Isto permite o backup mais rpido possvel durante a janela de backup. A gravao dos backups em ta pode ser feita durante o resto do dia til; se a gravao acabar antes dos backups do dia seguinte serem feitos, tempo no problema.
Mesmo assim, ainda h alguns casos nos quais faz sentido ter backup em drives de disco. Na prxima seo veremos como eles podem ser combinados com uma rede para formar uma soluo de backup vivel (mas custosa). 8.2.4.3. Rede Uma rede no pode agir como uma mdia de backup isoladamente. Mas, se combinada a tecnologias de armazenamento em massa, pode funcionar muito bem. Por exemplo: ao combinar um link de rede de alta velocidade a um centro de dados remoto contendo grandes quantidades de armazenamento em disco, as desvantagens mencionadas anteriormente de fazer backup em discos no so mais desvantagens. Ao fazer backup atravs de uma rede, os drives de disco j esto fora da empresa, portanto no h necessidade de transportar drives de disco frgeis a lugar algum. Com largura de banda suciente, possvel manter a vantagem da velocidade que voc pode obter ao fazer backups em drives de disco. No entanto, esta ttica no resolve a questo do armazenamento em arquivos (apesar de poder usar a mesma estratgia de passar para a ta aps o backup). Alm disso, os custos de um centro de dados remoto com um link de alta velocidade ao centro de dados principal encarecem demais esta soluo.
171
Mas, para as empresas que precisam das caractersticas que esse tipo de soluo pode oferecer, um custo com o qual elas arcam com prazer.
8.2.5. Armazenamento de Backups

O que acontece aps completar os backups? A resposta bvia que os backups devem ser armazenados. Entretanto, no to bvio o que deve ser armazenado e onde. Para responder a estas questes, devemos considerar primeiro sob quais circunstncias os backups devem ser usados. H trs situaes principais: 1. Pequenos e rpidos pedidos de restaurao dos usurios 2. Grandes restauraes para recuperar de um desastre 3. Armazenamento em arquivos, pouco provvel de ser usado novamente Infelizmente, h diferenas irreconciliveis entre os nmeros 1 e 2. Quando um usurio apaga um arquivo acidentalmente, ele pretende recuper-lo imediatamente. Isto siginifca que a mdia de backup no pode estar h mais de dois passos distante do sistema para o qual os dados devem ser restaurados. No caso de um desastre que precisa de uma restaurao completa de um ou mais computadores do seu centro de dados, se o desastre foi de natureza fsica, o que quer que tenha destrudo seus computadores, tambm destruiria os backups localizados prximos dos computadores. Isto seria uma situao terrvel. O armazenamento em arquivos menos controverso. J que a chance de ser utilizado para qualquer propsito baixa, no haveria problema se a mdia de backup estivesse localizada h quilmetros de distncia do centro de dados. As tticas para resolver estas diferenas variam de acordo com as necessidades da empresa em questo. Uma ttica possvel armazenar o backup de diversos dias na empresa; estes backups so ento levados para um local de armazenamento mais seguro fora da empresa quando os backups dirios mais novos forem criados. Uma outra ttica seria manter dois conjuntos diferentes de mdia:

Um conjunto no centro de dados estritamente para pedidos imediatos de restaurao Um conjunto fora da empresa para armazenamento externo e recuperao de desastres
Obviamente, ter dois conjuntos signica ter a necessidade de rodar todos os backups duas vezes para fazer uma cpia dos backups. Isto pode ser feito, mas backups duplos podem levar muito tempo e copiar requer diversos drives de backup para processar (e provavelmente um sistema dedicado a executar as cpias). O desao do administrador de sistemas encontrar um equilbrio que atenda adequadamente s necessidades de todos, e tambm assegurar que os backups estejam disponveis para a pior das situaes.
8.2.6. Questes de Restaurao

Enquanto os backups so uma ocorrncia diria, as restauraes normalmente representam um evento menos frequente. No entanto, as restauraes so inevitveis; elas sero necessrias, portanto melhor estar preparado. importante atentar para os vrios cenrios de restaurao detalhados ao longo desta seo e determinar maneiras para testar sua habilidade em resolv-los. E tenha em mente que o mais dcil de testar tambm o mais crtico.
172 8.2.6.1. Restaurando do Zero
"Restaurar do zero" signica restaurar um backup de sistema completo em um computador com absolutamente nenhum dado de nenhum tipo sem sistema operacional, sem aplicaes; nada. Em geral, h duas tticas bsicas para restauraes do zero: Reinstalar, seguido de restaurao Aqui o sistema operacional base instalado como se um computador novo estivesse sendo congurado. Aps instalar e congurar o sistema operacional, os drives de disco restantes podem ser particionados e formatados, e todos os backups restaurados pela mdia de backup. Discos de recuperao do sistema Um disco de recuperao do sistema uma mdia inicivel (bootable) de algum tipo (geralmente um CD) que contm um ambiente de sistema mnimo, capaz de executar as tarefas mais bsicas de administrao de sistemas. O ambiente de recuperao contm os utilitrios necessrios para particionar e formatar os drives de disco, os drives de dispositivo necessrios para acessar o dispositivo de backup e o software necessrio para restaurar os dados pela mdia de backup.
Nota Alguns computadores tm a habilidade de criar tas de backup iniciveis e de inicializar atravs delas para comear o processo de restaurao. No entanto, esta capacidade no est disponvel em todos os computadores. Notavelmente, os computadores baseados na arquitetura PC no permitem est ttica.
8.2.6.2. Testando Backups Todos os tipos de backup devem ser testados periodicamente para garantir que os dados podem ser lidos atravs deles. fato que, s vezes, os backups executados so por algum motivo ilegveis. O pior que muitas vezes isto s percebido quando os dados foram perdidos e devem ser restaurados pelo backup. As razes para isto ocorrer podem variar desde alteraes no alinhamento do cabeote do drive de ta, software de backup mal-congurado a um erro do operador. Independente da causa, sem o teste peridico voc no pode garantir que est gerando backups atravs dos quais poder restaurar dados no futuro.
8.3. Recuperao de Desastres

Como um experimento rpido, na prxima vez em que voc estiver no seu centro de dados, olhe ao redor e imagine por um momento que este se foi. No s os computadores, mas imagine que o prdio todo no existe mais. Em seguida, imagine que seu trabalho executar a maior parte das tarefas que eram executadas no centro de dados da mesma forma, em outro lugar, o mais rpido possvel. O que voc faria? Ao pensar nisso, voc tomou o pirmeiro passo da recuperao de desastres. A recuperao de desastres a habilidade de recuperar a sua empresa de um evento que impactou o funcionamento do seu centro de dados o mais competente e rapidamente possvel. O tipo de desastre pode variar, mas o objetivo nal sempre o mesmo.
173
Os passos envolvidos na recuperao de desastres so diversos e abrangentes. Aqui est uma viso geral do processo, juntamente a pontos-chave para ter em mente.
8.3.1. Criando, Testando e Implementando um Plano de Recuperao de Desastres

Um local de backup vital, mas intil sem um plano de recuperaco de desastres. Um plano de recuperaco de desastres determina cada faceta do processo de recuperaco de desastres, incluindo, mas no limitado a:

Quais eventos denotam possveis desastres Quais pessoas na empresa tm autorizao para declarar um desastre e, consequentemente, colocar o plano em ao A sequncia de eventos necessria para preparar o local de backup, uma vez declarado o desastre As funes e responsabilidades de todo o pessoal envolvido na execuo do plano Um inventrio do hardware e software necessrios para restaurar a produo Um cronograma listando os membros da equipe que compoem o local de backup, incluindo um cronograma de rotao para suportar a continuao das operaes sem estressar os membros da equipe A sequncia de eventos necessria para mover as operaes do local de backup para o centro de dados novo/restaurado
Os planos de recuperao de desastres frequentemente servem o propsito de juntar todos os detalhes. Este nvel de detalhe vital porque, no caso de uma emergncia, o plano pode ser a nica coisa que restou do seu centro de dados anterior (obviamente, alm dos backups externos) para ajud-lo na reconstruo e restaurao das operaes.
Dica Os planos de recuperao de desastres estarem prontamente disponveis no seu ambiente de trabalho, mas tambm necessrio ter cpias externas. Desta maneira, um desastre que destrua seu ambiente de trabalho no atingir todas as cpias do plano de recuperao de desastres. Um bom lugar para guardar esta cpia o local de armazenamento dos backups externos. Se no for violar as normas de segurana da sua empresa, as cpias tambm podem ser guardadas nas casas de membros-chave da equipe, prontas para uso imediato.
Um documento importante como este merece seriedade (e possivelmente assistncia prossional para ser criado). Uma vez criado este documento importante, o conhecimento nele contido deve ser periodicamente testado. Testar um plano de recuperao de desastres signica percorrer os passos do plano: ir ao local do backup e criar um centro de dados temporrio, rodar aplicaes remotamente e retornar s operaes normais aps o m do "desastre". A maioria dos testes no tenta executar 100% das tarefas contidas no plano; ao invs disso, um sistema e uma aplicao representativos so selecionadas e realocadas ao local do backup, colocadas em produo por um perodo e retornadas operao normal no m do teste.
Nota Apesar de ser uma frase batida, um plano de recuperao de desastres deve ser um documento vivo; conforme o centro de dados sofre mudanas, o plano deve ser atualizado para reetir estas
174

alteraes. De muitas maneiras, um plano de recuperao de desastres desatualizado pode ser pior que no ter plano algum, portanto se organize para executar revises e atualizaes regulares (a cada trs meses, por exemplo) no plano.
8.3.2. Locais de Backup: Frios, Mornos e Quentes

Um dos aspectos mais importantes da recuperao de um desastre ter o local a partir do qual a recuperao pode ser feita. Este local tambm conhecido como um site de backup. No caso de um desastre, um site de backup onde seu centro de dados ser recriado, e de onde voc estar operando durante o desastre. H trs tipos diferentes de sites de backup:

Sites de backup frios Sites de backup mornos Sites de backup quentes
Obviamente, estes termos no fazem referncia temperatura do site de backup. Mas sim ao esforo necessrio para iniciar as operaes no site de backup, caso ocorra um desastre. Um site de backup frio um pouco mais do que um espao congurado apropriadamente num prdio. Tudo o que necessrio para restaurar o servio para seus usurios deve ser obtido e entregue ao site antes de comear o processo de recuperao. Como voc pode imaginar, a demora na transformao de um site de backup frio numa operao completa pode ser substancial. Sites de backup frios so os mais baratos. Um site de backup morno j estocado com hardware parecido com o que voc tem no seu centro de dados. Para recuperar o servio, os ltimos backups do seu local de armazenamento externo devem ser entregues e uma restaurao do zero deve ser completa, antes de realmente iniciar a recuperao. Sites de backup quentes tem uma imagem espelho virtual de seu centro de dados atual, com todos os sistemas congurados e aguardando somente os ltimos backups dos dados de seus usurios vindos do local de armazenamento externo. Como voc pode imaginar, um site de backup quente pode ser transformado num local de produo completo em apenas algumas horas. Um site de backup quente a ttica mais cara de recuperao de desastres. Os sites de backup podem ter trs origens diferentes:

Empresas especializadas em oferecer servios de recuperao de desastres Outros locais de propriedade de sua empresa e operados pela mesma Um acordo com uma outra empresa para compartilhar as instalaes do centro de dados no caso de um desastre
Cada ttica tem seus pontos fortes e fracos. Por exemplo: contratar uma empresa de recuperao de desastres frequentemente lhe d acesso a prossionais qualicados para direcionar as empresas atravs do processo de criao, testes e implementao de um plano de recuperao de desastres. Como voc pode imaginar, estes servios no so de graa. Usar um espao em outra localidade de propriedade e operada pela sua empresa pode ser uma opo com custo zero, mas estocar o site de backup e manter sua prontido ainda uma opo cara. Desenvolver um acordo para compartilhar centros de dados com uma outra empresa pode ser bem barato, mas geralmente no possvel tocar operaes a longo prazo sob estes termos, j que o proprietrio do centro de dados ainda deve manter sua produo normal.
175
No nal das contas, a escolha do site de backup um balano entre os custos e a necessidade de sua empresa na produo contnua.
8.3.3. Disponibilidade de Hardware e Software

Seu plano de recuperao de desastres deve incluir mtodos para obter o hardware e software necessrios para as operaes do site de backup. Um site de backup gerido prossionalmente talvez j tenha tudo o que voc precisa (ou talvez voc precise providenciar a obteno e entrega de materiais especiais que o site no tenha). Por outro lado, um site de backup frio implica na identicao de uma fonte convel para a obteno de cada um dos itens. Frequentemente, empresas trabalham com fabricantes para criar acordos para a rpida entrega de hardware e/ou software no caso de um desastre.
8.3.4. Disponibilidade de Backups

Quando um desastre declarado, necessrio noticar o seu local de armazenamento externo por duas razes:

Para levar os ltimos backups ao site de backup Para organizar a retirada e entrega dos backups ao site de backup (como suporte aos backups normais do site de backup)
Dica No caso de um desastre, os ltimos backups de seu antigo centro de dados que voc tiver so vitalmente importantes. Considere fazer cpias antes de mais nada, e retirar os originais novamente da empresa o quanto antes.
8.3.5. Conectividade de Rede ao Site de Backup

Um centro de dados no tem muita utilidade se estiver totalmente desconectado do que resto da empresa. Dependendo do plano de recuperao de desastres e da natureza do desastre, sua comunidade de usurios pode estar localizada h quilmetros de distncia do site de backup. Nestes casos, uma boa conectividade essencial para restaurar a produo. Um outro tipo de conectividade para ter em mente a telefnica. Voc deve assegurar que h linhas telefnicas disponveis sucientes para suportar toda a comunicao verbal com seus usurios. O que pode ter sido um simples grito por cima de uma divisria pode ser agora uma conversa telefnica de longa distncia. Portanto, planeje mais conectividade telefnica do que parea necessrio numa primeira instncia.
8.3.6. Funcionrios do Site de Backup

A questo dos funcionrios do site de backup tem diversas dimenses. Um dos aspectos determinar os funcionrios necessrios para rodar o centro de dados backup pelo tempo necessrio. Apesar de um nmero pequeno de funcionrios poder manter as coisas funcionando por um curto perodo, conforme o desastre se desenrolar, sero necessrias mais pessoas para tocar as operaes sob as circunstncias extraordinrias que permeam um desastre.
176
Isto inclui garantir que os funcionrios tenham tempo livre suciente para descansar e voltar para seus lares. Se as consequncias do desastre foram abrangentes de modo que afetaram os lares e famlias das pessoas, necessrio alocar tempo para que elas possam lidar com suas recuperaes particulares do desastre. Tambm necessria acomodao prxima ao site de backup, assim como transporte para trazer as pessoas para o site de backup e lev-las de volta. Frequentemente, um plano de recuperao de desastres inclui representantes de todas as partes da comunidade de usurios da empresa. Isto depende da habilidade da sua empresa em operar com um centro de dados remoto. Se os representantes dos usurios devem trabalhar no site de backup, tambm necessrio prover-lhes acomodao.
8.3.7. Voltando Normalidade

Eventualmente, todos os desastres terminam. O plano de recuperao de desastres tambm deve abordar esta fase. O novo centro de dados deve estar equipado com todo o hardware e software necessrio. Apesar desta fase no ter a mesma natureza crtica de tempo dos preparativos quando o desastre foi declarado, os sites de backup custam dinheiro todos os dias em que esto em uso. Portanto, devido s questes econmicas, devemos retornar normalidade o mais rpido possvel. Deve-se fazer os ltimos backups do site de backup e envi-los ao novo centro de dados. Aps serem restaurados no novo hardware, a produo pode ser iniciada no novo centro de dados. Neste ponto, o centro de dados backup pode ser descomissionado, com a disposio de todo o hardware temporrio determinada pela seo nal do plano. Finalmente, deve ser feita uma reviso da eccia do plano e integrar as alteraes recomendadas pelo comit revisor numa verso atualizada do plano.

H poucas informaes sobre os tpicos desastre e recuperao de desastre relacionadas a um sistema operacional especco. Anal de contas, os computadores de um centro de dados inundado estaro inoperantes, independente de rodarem o Red Hat Enterprise Linux ou outro sistema operacional. No entanto, h partes do Red Hat Enterprise Linux relacionadas a determinados aspectos da recuperao de um desastre. Estas so abordadas na prxima seo.
8.4.1. Suporte ao Software

Como fabricante de software, a Red Hat oferece suporte para seus produtos, incluindo o Red Hat Enterprise Linux. Voc est usando a forma mais bsica de suporte agora mesmo, ao ler este manual. A documentao do Red Hat Enterprise Linux est disponvel no CD de Documentao do Red Hat Enterprise Linux (que tambm pode ser instalado no seu sistema para acesso rpido), no formato impresso e tambm no site da Red Hat http://www.redhat.com/docs/. Opes de auto suporte podem ser acessadas atravs das diversas listas de discusso hospedadas pela Red Hat (visite o site https://listman.redhat.com/mailman/listinfo/). Estas listas trazem o conhecimento da comunidade de usurios Red Hat e, muitas delas so monitoradas por funcionrios da Red Hat, que tambm contribuem de acordo com sua disponibilidade. Outros recursos podem ser acessados atravs da pgina principal de suporte da Red Hat: http://www.redhat.com/apps/support/. H opes de suporte mais detalhado. Para maiores informaes, consulte o site da Red Hat.
177
8.4.2. Tecnologias de Backup

O Red Hat Enterprise Linux traz diversos programas diferentes para fazer backup e restaurar dados. Estes programas por si s no constituem uma soluo completa de backup. Entretanto, eles podem ser usados como o ncleo de tal soluo.
Nota Como mencionado na Seo 8.2.6.1, a maioria dos computadores baseados na arquitetura PC padro no possuem a funcionalidade necessria para inicializar a partir de uma ta de backup. Consequentemente, o Red Hat Enterprise Linux no capaz de executar uma inicializao pela ta quando rodar em hardware deste tipo. No entanto, tambm possvel usar o seu CD-ROM do Red Hat Enterprise Linux como um ambiente de recuperao do sistema. Para mais informaes, veja o captulo sobre recuperao bsica de sistemas no Guia de Administrao de Sistemas Red Hat Enterprise Linux.
8.4.2.1. tar O utilitrio tar bem conhecido dentre os administradores de sistemas UNIX. o mtodo de arquivamento preferido para compartilhar partes do cdigo fonte e arquivos entre sistemas. A implementao do tar inclusa no Red Hat Enterprise Linux o tar do GNU, uma das implementaes tar mais ricas em funcionalidades. Usar o tar para fazer backup do contedo de um diretrio pode ser to simples quanto invocar um comando similar a:
tar cf /mnt/backup/home-backup.tar /home/
Este comando cria um arquivo chamado home-backup.tar no diretrio /mnt/backup/. O arquivo contm o contedo do diretrio /home/. O arquivo resultante ser quase to grande quanto os dados sendo copiados para backup. Dependendo do tipo de dados sendo copiados, comprimir o arquivo pode signicar uma grande reduo no tamanho. O arquivo pode ser comprimido adicionando apenas uma opo ao comando anterior:
tar czf /mnt/backup/home-backup.tar.gz /home/
O arquivo home-backup.tar.gz resultante agora foi comprimido pelo gzip 5. H muitas outras opes para o tar; para saber mais, leia a pgina man do tar(1). 8.4.2.2. cpio O utilitrio cpio outro programa tradicional do UNIX. um programa excelente para mover dados de uma localidade a outra e, como tal, pode servir tambm como programa de backup. O comportamento do cpio um pouco diferente do tar. Ao contrrio do tar, o cpio l os nomes dos arquivos que deve processar atravs do input padro (standard input). Um mtodo comum para gerar uma lista de arquivos para o cpio usar programas como o find, cujo output ento enviado (piped) ao cpio:
find /home/ | cpio -o
5.
A extenso .gz usada tradicionalmente para conotar que o arquivo foi comprimido com o gzip. s vezes,
o .tar.gz encurtado para .tgz a m de manter os nomes de arquivos razoavelmente curtos.
/mnt/backup/home-backup.cpio
178
Este comando cria um arquivo cpio (contendo todos os dados de /home/) chamado home-backup.cpio e localizado no diretrio /mnt/backup/.
Dica Como o find tem uma variedade de testes de seleo de arquivos, fcil criar backups sosticados. Por exemplo: o comando seguinte faz um backup somente dos arquivos que no foram acessados no ltimo ano:
find /home/ -atime +365 | cpio -o
H muitas outras opes para o cpio (e para o find). Para aprender mais sobre elas, leia as pginas man do cpio(1) e do find(1). 8.4.2.3. dump/restore: No Recomendado para Sistemas de Arquivo Montados! Os programas Linux dump e restore so equivalentes aos programas UNIX de mesmo nome. Sendo assim, muitos administradores de sistemas com experincia no UNIX podem pensar que o dump e o restore so boas opes para um programa de backup sob o Red Hat Enterprise Linux. No entanto, um dos mtodos de uso do dump pode causar problemas. Aqui est o comentrio de Linus Torvald sobre o assunto:
From: Linus Torvalds To: Neil Conway Subject: Re: [PATCH] SMP race in ext2 - metadata corruption. Date: Fri, 27 Apr 2001 09:59:46 -0700 (PDT) linux-kernel At vger Dot kernel Dot org Cc: Kernel Mailing List [ linux-kernel added back as a cc ]
On Fri, 27 Apr 2001, Neil Conway wrote: Im surprised that dump is deprecated (by you at least ;-)). What to use instead for backups on machines that cant umount disks regularly?
Note that dump simply wont work reliably at all even in 2.4.x: the buffer cache and the page cache (where all the actual data is) are not coherent. This is only going to get even worse in 2.5.x, when the directories are moved into the page cache as well. So anybody who depends on "dump" getting backups right is already playing Russian roulette with their backups. Its not at all guaranteed to get the right results - you may end up having stale data in the buffer cache that ends up being "backed up". Dump was a stupid program in the first place. Leave it behind.
Ive always thought "tar" was a bit undesirable (updates atimes or ctimes for example).
Right now, the cpio/tar/xxx solutions are definitely the best ones, and will work on multiple filesystems (another limitation of "dump"). Whatever problems they have, they are still better than the _guaranteed_(*) data corruptions of "dump". However, it may be that in the long run it would be advantageous to have a
/mnt/backup/home-backup.cpio
$ &$$ $$
179
"filesystem maintenance interface" for doing things like backups and defragmentation.. Linus (*) Dump may work fine for you a thousand times. But it _will_ fail under the right circumstances. And there is nothing you can do about it.
Dado este problema, o uso do dump/restore em sistemas de arquivo montados no recomendado. Entretanto, o dump foi originalmente desenvolvido para fazer backup de sistemas de arquivo no montados; consequentemente, em situaes nas quais possvel tornar um sistema de arquivo ofine com o umount, o dump continua sendo uma tecnologia vivel para backup. 8.4.2.4. O Arquivador de Disco de Rede Automtico Maryland Avanado (AMANDA, The Advanced Maryland Automatic Network Disk Archiver) AMANDA uma aplicao de backup baseada no cliente/servidor produzida pela Universidade de Maryland. Por ter uma arquitetura cliente/servidor, um nico servidor de backup (normalmente, um sistema bastante poderoso com bastante espao livre nos discos rpidos e congurado com o dispositivo de backup desejado) pode fazer backup de muitos sistemas cliente, que no precisam mais do que o software cliente AMANDA. Esta ttica de backup faz muito sentido, pois concentra estes recursos necessrios para backups em um nico sistema, ao invs de precisar de hardware adicional para cada sistema que requerer servios de backup. O design do AMANDA tambm serve para centralizar a gesto dos backups, facilitando bastante a vida do administrador de sistemas. O servidor do AMANDA administra uma srie de mdias de backup e alterna o uso entre elas para garantir que todos os backups sejam retidos pelo perodo de reteno determinado pelo administrador. Todas as mdias so pr-formatadas com dados que permitem ao AMANDA detectar se a mdia apropriada est disponvel ou no. Alm disso, o AMANDA pode interfacear com mdia robtica alterando unidades, possibilitando automatizar os backups completamente. O AMANDA pode usar o tar ou o dump para fazer os backups ( prefervel usar o tar sob o Red Hat Enterprise Linux devido s questes do dump abordadas na Seo 8.4.2.3). Sendo assim, os backups do AMANDA no requerem o AMANDA para restaurar os arquivos um valor agregado. Em operao, o AMANDA normalmente agendado para rodar uma vez por dia durante a janela de backup do centro de dados. O servidor do AMANDA conecta aos sistemas cliente e os direciona a produzir tamanhos estimados dos backups a serem feitos. Uma vez disponibilizadas as estimativas, o servidor cria uma agenda, determinando automaticamente a ordem na qual os sistemas tero seus backups feitos. Aps os backups iniciarem, os dados so enviados atravs da rede, do cliente para o servidor, onde so armazenados em um disco de espera. Uma vez completo o backup, o servidor comea a gravlo pelo disco de espera na mdia de backup. Ao mesmo tempo, outros clientes esto enviando seus backups ao servidor para serem armazenados no disco de espera. Isto resulta num uxo de dados contnuo disponvel para gravao na mdia de backup. Conforme os backups so gravados na mdia de backup, so apagados do disco de espera do servidor. Uma vez completos todos os backups, o administrador de sistemas recebe um e-mail com um relatrio descrevendo o status dos backups, facilitando e dinamizando a reviso. Se for necessrio restaurar dados, o AMANDA contm um programa que permite ao operador identicar o sistema de arquivo, data e nome(s) do(s) arquivo(s). Aps fazer isso, o AMANDA identica a mdia de backup correta e ento localiza e restaura os dados desejados. Conforme mencionado anteriormente, o design do AMANDA tambm possibilita restaurar dados mesmo sem a assistncia do AMANDA, apesar da identicao da mdia correta ocorrer mais lentamente e manualmente.
180
Esta seo cobriu apenas os conceitos mais bsicos do AMANDA. Para pesquisar mais sobre o AMANDA, comece pela pgina man amanda(8).

Esta seo inclui diversos recursos para aprender mais sobre a recuperao de desastres e o assunto especco ao Red Hat Enterprise Linux abordado neste captulo.

Os recursos seguintes so instalados no decorrer de uma instalao tpica do Red Hat Enterprise Linux e podem ajud-lo a saber mais sobre o assunto aqui abordado.

Pgina man tar(1) Aprenda a arquivar dados. Pgina man dump(8) Aprenda a fazer dump do contedo do sistema de arquivo. Pgina man restore(8) Aprenda a recuperar o contedo do sistema de arquivo salvo pelo
dump
Pgina man cpio(1) Aprenda a copiar arquivos para e de arquivamentos. Pgina man find(1) Aprenda a procurar arquivos. Pgina man amanda(8) Aprenda mais sobre os comandos que fazem parte do sistema de backup AMANDA. Arquivos do diretrio /usr/share/doc/amanda-server- version / Aprenda mais sobre o AMANDA revendo este diversos documentos e arquivos de exemplo.
8.5.2. Sites teis

http://www.redhat.com/apps/support/ A pgina de suporte da Red Hat oferece fcil acesso aos diversos recursos relacionados ao suporte do Red Hat Enterprise Linux. http://www.disasterplan.com/ Um site interessante com links para vrios outros sites relacionados recuperao de desastres. Inclui uma amostra de plano de recuperao de desastres. http://web.mit.edu/security/www/isorecov.htm O site do Massachusetts Institute of Technology Information Systems Business Continuity Planning contm diversos links informativos. http://www.linux-backup.net/ Uma viso geral interessante de diversas questes relativas a backups. http://www.linux-mag.com/1999-07/guru_01.html Um artigo interessante da Linux Magazine sobre os aspectos mais tcnicos da produo de backups sob o Linux. http://www.amanda.org/ O site do AMANDA (The Advanced Maryland Automatic Network Disk Archiver). Contm indicaes sobre as diversas listas de discusso relacionadas ao AMANDA e outros recursos online.

Os livros a seguir abordam diversas questes relativas recuperao de desastres e so bons recursos para os administradores de sistemas Red Hat Enterprise Linux.
'
181
O Guia de Administrao de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. Inclui um captulo sobre recuperao de sistemas, que pode ser til nas restauraes a partir do zero. Unix Backup & Recovery de W. Curtis Preston; OReilly & Associates Apesar de no ser escrito especicamente para sistemas Linux, este livro oferece uma cobertura profunda de diversas questes relacionadas a backups, inclusive um captulo sobre a recuperao de desastres.
182
ndice Remissivo
Smbolos
/etc/cups/, 144 /etc/printcap, 144
A
abuso de recursos, 127 abuso, recurso, 127 Administrador de Pacotes RPM (Ver RPM) administrando impressoras, 137 administrao de sistemas losoa da, 1 automao, 1 comunicao, 3 documentao, 2 engenharia social, riscos da, 7 negcio, 6 ocorrncias inesperadas, 8 planejamento, 8 recursos, 5 segurana, 6 usurios, 6 administrao de volume lgico (Ver LVM) armazenamento acessvel via rede, 75, 101 NFS, 101 SMB, 101 adicionando, 87, 102 /etc/fstab, atualizando, 104 agendamento de backup, alterando, 91 congurao, atualizando, 91 drive de disco ATA, 88 drive de disco SCSI, 89 formatando, 91, 104 hardware, instalando, 88 particionando, 90, 102 administrao do, 59, 82 crescimento, normal, 85 monitoramento do espao livre, 83 questes de usurio, 83 uso da aplicao, 84 uso excessivo do, 83 baseado no RAID (Ver RAID) dispositivos de armazenamento em massa braos de acesso, 60 cabea, 62 cabeas (heads), 60
cabeas acessando, 68 cabeas gravando, 68 cargas I/O, acessos, 69 cargas I/O, desempenho, 69 cargas I/O, gravaes, 69 cilindro, 62 conceitos de endereamento, 61 desempenho do, 67 geometria, problemas com, 62 interface IDE, 64 interface SCSI, 65 interfaces do, 63 interfaces padro, 64 interfaces, histrico, 63 interfaces, padro, 64 latncia rotacional, 68 latncia, rotacional, 68 leitores versus gravadores, 69 limitaes eltricas do, 67 limitaes mecnicas do, 67 localidade I/O, 70 mapeamento baseado na geometria, 61 mapeamento baseado no bloco, 63 mapeamento, baseado na geometria, 61 mapeamento, baseado no bloco, 63 movimento do brao de acesso, 68 movimento, brao de acesso, 68 pratos de disco, 59 pratos, disco, 59 processamento de comandos, 68 processamento, comandos, 68 setor, 62 viso geral do, 59 empregando, 70 monitoramento da, 17 padres de acesso, 45 partio atributos das, 70 campo do tipo, 71 extendidas, 71 geometria da, 71 lgicas, 71 primrias, 71 tipo da, 71 viso geral do, 70 questes relativas a arquivos, 86 acesso a arquivos, 86 compartilhamento de arquivos, 87 quotas de disco, 85 (Ver quotas de disco) removendo, 92, 105 /etc/fstab, removendo do, 105 apagando contedo, 93, 106 comando umount, uso do, 105 dados, removendo, 92 sistema de arquivo, 72, 96
184
arquivo /etc/mtab, 99 arquivo /proc/mounts, 100 baseado em arquivo, 72 comando df, usando, 100 contabilidade do espao, 73 contabilidade, espao, 73 controle de acesso, 73 diretrio hierrquico, 72 diretrios, 72 estrutura, diretrio, 74 EXT2, 96 EXT3, 97 habilitando acesso ao, 74 hora de acesso, 73 hora de criao, 73 hora de modicao, 73 ISO 9660, 97 montando, 98 montando com o arquivo /etc/fstab, 101 MSDOS, 97 ponto de montagem, 98 VFAT, 97 visualizao da montagem, 99 tecnologias, 45 armazenamento de backup, 49 armazenamento off-line, 49 cache L1, 47 cache L2, 47 disco rgido, 48 drive de disco, 48 memria cache, 46 memria principal, 47 RAM, 47 Registradores de CPU, 46 tecnologias, avanadas, 75 arquivo /etc/fstab atualizando, 104 montando sistemas de arquivo com, 101 arquivo /etc/group conta de usurio, funo no, 132 grupo, funo no, 132 arquivo /etc/gshadow conta de usurio, funo no, 132 grupo, funo no, 132 arquivo /etc/mtab, 99 arquivo /etc/passwd conta de usurio, funo no, 130 grupo, funo no, 130 arquivo /etc/shadow conta de usurio, funo no, 130 grupo, funo no, 130 arquivo /proc/mdstat, 112 arquivo /proc/mounts, 100 ative sua assinatura, iv automao, 8 viso geral da, 1
B
backups agendamento, alterando, 91 armazenamento de, 171 comprando software, 167 criando software, 167 introduo a, 165 questes de restaurao, 171 restauraes do zero, 172 testando a restaurao, 172 questes relaciondas aos dados, 166 software de backup AMANDA, 179 tecnologias usadas, 177 cpio, 177 dump, 178 tar, 177 tipos de, 168 backups completos, 168 backups diferenciais, 169 backups incrementais, 168 tipos de mdia, 169 disco, 169 ta, 169 rede, 170
C
CD-ROM sistema de arquivo (Ver Sistema de arquivo ISO 9660) comando df, 100 comando free, 19, 54 comando gnome-system-monitor, 20 comando iostat, 23, 38 comando mpstat, 23 comando raidhotadd, uso do, 112 comando sa1, 23 comando sa2, 23 comando sadc, 23 comando sar, 23, 25, 39, 41, 55 relatrios, acessando, 25 comando top, 18, 19, 40 comando vmstat, 18, 21, 38, 41, 54 comando watch, 19 comunicao informaes especcas ao Red Hat Enterprise Linux, 9 necessidade de, 3 congurao da impressora, 143 aplicao baseada em texto, 143 CUPS, 143 conjunto de trabalho, 52 conta
185
(Ver conta de usurio) conta de usurio acesso a dados compartilhados, 125 administrao da, 115, 115, 123 alteraes de funo, 124 desligamentos, 123 novas contrataes, 123 arquivos que controlam, 129 /etc/group, 132 /etc/gshadow, 132 /etc/passwd, 130 /etc/shadow, 130 controle de acesso, 122 diretrio home centralizado, 127 ferramentas de administrao, 133 o comando chage, 133 o comando chfn, 133 o comando chpasswd, 133 o comando passwd, 133 o comando useradd, 133 o comando userdel, 133 o comando usermod, 133 GID, 129 GIDs do sistema, 129 nome de usurio, 115 alteraes do, 117 colises na nomenclatura, 116 conveno de nomenclatura, 115 permisses relacionadas a, 127 execuo (execute), 127 gravao (write), 127 leitura (read), 127 setgid (id do grupo), 127 setuid (id do usurio), 127 sticky bit, 127 recursos, administrao dos, 125 senha, 118 brevidade da, 119 conjunto de caracteres grande usado na, 121 escritas, 121 expirao, 122 fortes, 121 fraca, 119 informaes pessoais usadas na, 120 mais longas, 121 memorvel, 122 palavras usadas na, 120 pequeno conjunto de caracteres usado na, 119 truques com palavras usados na, 120 usada repetidamente, 121 UID, 129 UIDs do sistema, 129 controle de mudanas, 163 convenes documentos, ii CUPS, 143
D
dados acesso compartilhados aos, 125, 126 questes de propriedade (ownership) global, 127 devlabel, 96 diretrio home centralizado, 127 diretrio home centralizado, 127 discos rgidos, 48 dispositivo acesso ao dispositivo inteiro, 95 alternativas aos nomes dos dispositivos, 95 conveno de nomenclatura, 93 devlabel, nomeando com o, 96 etiquetas do sistema de arquivo, 95 etiquetas, sistema de arquivo, 95 nomeando com o devlabel, 96 nomes de dispositivos, alternativas para, 95 nomes dos arquivos, 94 partio, 94 tipo, 94 unidade, 94 documentao informaes especcas ao Red Hat Enterprise Linux, 9 documentao, necessidade de, 2 drive de disco ATA adicionando, 88 drive de disco SCSI adicionando, 89 drives de disco, 48
E
engenharia social, riscos da, 7 engenharia, social, 7 espao de endereo virtual, 51 espao em disco (Ver armazenamento)
186
F
falhas de pgina, 51 Ferramenta de Congurao da Impressora (Ver congurao da impressora) ferramentas contas de usurio, administrao (Ver conta de usurio, ferramentas de administrao) grupos, administrao (Ver grupo, ferramentas de administrao) monitoramento de recursos, 18 free, 19 iostat, 23 Monitor GNOME do Sistema, 20 mpstat, 23 OProle, 26 sa1, 23 sa2, 23 sadc, 23 sar, 23, 25 Sysstat, 23 top, 19 vmstat, 21 losoa da administrao de sistemas, 1
H
hardware contratos de servio, 149 disponibilidade das peas, 152 hardware coberto, 152 horas de cobertura, 149 oramento para, 152 servio de depsito, 150 servio drop-off, 150 servio walk-in, 150 tempo de resposta, 150 tcnico interno, 151 falhas de, 147 habilidades necessrias para o reparo, 147 reservas estoque, quantidades, 148 estoque, seleo do, 148 guardar, 147 trocando hardware, 149
I
ID do grupo (Ver GID) ID do usurio (Ver UID) impressoras administrando, 137 consideraes, 137 cor, 140 CMYK, 140 jato de tinta, 140 laser, 141 duplex, 137 em rede, 143 linguagens (Ver linguagens de descrio da pgina (PDL)) local, 143 recursos adicionais, 145 tipos, 137 cera trmica, 141 de linha, 138 dye-sublimation, 141 impacto, 138 jato de tinta, 140 laser, 140 laser coloridas, 141 margarida (daisy-wheel), 138 matricial (dot-matrix), 138 tinta slida, 141 impressoras de impacto, 138 consumveis, 139 de linha, 138
G
GID, 129 grupo acesso a dados compartilhados usando, 126 administrao da, 115 arquivos que controlam, 129 /etc/group, 132 /etc/gshadow, 132 /etc/passwd, 130 /etc/shadow, 130 estrutura, determinando, 126 ferramentas de administrao, 133 o comando gpasswd, 133 o comando groupadd, 133 o comando groupdel, 133 o comando groupmod, 133 o comando grpck, 133 GID, 129 GIDs do sistema, 129 permisses relacionadas a, 127 execuo (execute), 127 gravao (write), 127 leitura (read), 127 setgid (id do grupo), 127 setuid (id do usurio), 127 sticky bit, 127 UID, 129 UIDs do sistema, 129
187
margarida (daisy-wheel), 138 matricial (dot-matrix), 138 impressoras de linha (Ver impressoras de impacto) impressoras laser coloridas, 141 impressoras margarida (Ver impressoras de impacto) impressoras matriciais (Ver impressoras de impacto) impressoras jato de tinta, 140 consumveis, 140 impressoras laser, 140 consumveis, 141 cor, 141 inesperado, preparao para o, 8 informaes especcas ao Red Hat Enterprise Linux automao, 8 comunicao, 9 documentao, 9 janela de comandos bash, 8 PAM, 10 perl, 8 RPM, 10 scripts da janela de comandos, 8 segurana, 10 sistemas de deteco de intruso, 10 informaes especcas do Red Hat Enterprise Linux ferramentas de monitoramento de recursos iostat, 38 sar, 39, 41 top, 40 vmstat, 38, 41 ferramentas de monitoramento dos recursos, 18 free, 18, 54 OProle, 18 sar, 55 Sysstat, 18 top, 18 vmstat, 18, 54 monitoramento de recursos largura de banda, 38 memria, 54 poder da CPU, 38 recuperao de desastres, 176 suporte ao software, 176 suporte, software, 176 tecnologias de backup AMANDA, 179 cpio, 177 dump, 178 tar, 177 viso geral das, 177 interface IDE viso geral do, 64 interface SCSI viso geral do, 65
J
janela de comandos bash, automao e, 8
L
linguagens de descrio da pgina (PDL), 142 Interpress, 142 PCL, 142 PostScript, 142 lpd, 145 LVM agrupamento de armazenamento, 81 contrastada com o RAID, 82 migrao de dados, 82 migrao, dados, 82 redimensionamento do volume lgico, 81 redimensionamento, volume lgico, 81 viso geral do, 81
M
memria memria virtual, 49 backing store, 50 conjunto de trabalho, 52 desempenho da, 53 desempenho, melhor caso, 53 desempenho, pior caso, 53 espao de endereo virtual, 51 falhas de pgina, 51 swapping, 52 viso geral da, 50 monitoramento da, 17 utilizao dos recursos de, 45 memria cache, 46 memria fsica (Ver memria) memria virtual (Ver memria) monitoramento desempenho do sistema, 14 recursos, 13 monitoramento de recursos, 13 armazenamento, 17 capacidade do sistema, 14 conceitos bsicos, 13 desempenho do sistema, 14 Energia da CPU, 15 ferramentas free, 19 iostat, 23 Monitor GNOME do Sistema, 20 mpstat, 23
188
OProle, 26 sa1, 23 sa2, 23 sadc, 23 sar, 23, 25 Sysstat, 23 top, 19 vmstat, 21 ferramentas usadas, 18 largura de banda, 16 memria, 17 o que monitorar, 15 planejamento da capacidade, 14 monitoramento do desempenho do sistema, 14 monitorando estatsticas relacionada ao armazenamento, 17 relacionada memria, 17 relacionado largura de banda, 16 relativa CPU, 15 seleo de, 15 montando sistemas de arquivo (Ver armazenamento, sistema de arquivo, montando) multiprocessamento simtrico, 37 Mdulos de Autenticao Plugveis (Pluggable Authentication Modules) (Ver PAM) o comando usermod, 133 OProle, 18, 26
P
PAM, 10 partio, 94 atributos das, 70 campo do tipo, 71 geometria, 71 tipo, 71 criao de, 90, 102 extendidas, 71 lgicas, 71 primrias, 71 viso geral do, 70 perl, automao e, 8 permisso de execuo (execute), 127 permisso de gravao (write), 127 permisso de leitura (read), 127 permisso setgid, 10 permisso setgid (id do grupo), 127 permisso setuid, 10 permisso setuid (id do usurio), 127 permisso sticky bit, 127 permisses, 127 ferramentas de administrao o comando chgrp, 134 o comando chmod, 134 o comando chown, 134 planejamento da capacidade, 14 planejamento para desastres, 147 energia, backup, 158 gerador, 158, 159 quedas, extensas, 160 UPS, 158 tipos de desastres, 147 aplicaes usadas impropriamente, 161 aquecimento, 160 ar condicionado, 160 eletricidade, qualidade da, 157 eletricidade, segurana da, 156 eltrico, 156 erros de m congurao, 163 erros de operadores, 162 erros de procedimento, 162 erros de usurios, 161 erros do administrador de sistemas, 163 erros do tcnico de servio, 165 erros durante procedimentos, 162 erros humanos, 161 erros relacionados manuteno, 164 falhas de hardware, 147 falhas de software, 153 falhas nas aplicaes, 153
N
negcio, conhecimento do, 6 NFS, 101 nome de usurio, 115 alterando, 117 colises entre, 116 conveno de nomenclatura, 115 nomes dos arquivos dispositivo, 94
O
o comando chage, 133 o comando chfn, 133 o comando chgrp, 134 o comando chmod, 134 o comando chown, 134 o comando chpasswd, 133 o comando gpasswd, 133 o comando groupadd, 133 o comando groupdel, 133 o comando groupmod, 133 o comando grpck, 133 o comando passwd, 133 o comando useradd, 133 o comando userdel, 133
189
falhas no ambiente, 155 falhas no sistema operacional, 153 fatores climticos, 161 HVAC, 160 integridade da construo, 155 pendncias do sistema operacional, 153 quedas do sistema operacional, 153 reparos inapropriados, 165 ventilao, 160 planejamento, importncia do, 8 poder da CPU (Ver recursos, sistema, poder de processamento) poder de processamento, recursos relacionados ao (Ver recursos, sistema, poder de processamento) pontos de montagem (Ver armazenamento, sistema de arquivo, ponto de montagem) printconf (Ver congurao da impressora) printtool (Ver congurao da impressora) RAID de hardware, 80 RAID de software, 81 introduo ao, 76 nveis do, 77 RAID 0, 77 RAID 0, desvantagens do, 77 RAID 0, vantagens do, 77 RAID 1, 78 RAID 1, desvantagens do, 78 RAID 1, vantagens do, 78 RAID 5, 78 RAID 5, desvantagens do, 79 RAID 5, vantagens do, 79 RAID embutido, 79 RAID embutido, 79 viso geral do, 76 RAM, 47 recuperao de desastres backups, disponibilidade de, 175 disponibilidade de hardware, 175 disponibilidade de software, 175 m do, 176 introduo a, 172 local de backup, 174 conectividade de rede ao, 175 funcionrios do, 175 planejar, criar, testar, implementar, 173 recursos do sistema (Ver recursos, sistema) recursos relacionados largura de banda (Ver recursos, sistema, largura de banda) recursos, importncia dos, 5 recursos, sistema armazenamento (Ver armazenamento) energia de processamento monitoramento da, 15 largura de banda, 31 a funo dos canais na, 31 canais, exemplos de, 32 capacidade, aumento, 33 carga, distribuio, 33 carga, reduo, 33 centrais de dados (datapaths), exemplos de, 32 centrais de dados (datapaths), funo no, 32 monitoramento da, 16 problemas relacionados a, 32 solues de problemas com a, 33 viso geral da, 31 memria (Ver memria) poder de processamento, 31 aplicaes, eliminar, 36 atualizando, 37 capacidade, aumento, 37 carga, reduo, 36
Q
quota, disco (Ver quotas de disco) quotas de disco administrao do, 109 ativando, 108 introduo ao, 106 viso geral do, 107 especco ao grupo, 107 especco ao sistema de arquivo, 107 especco ao usurio, 107 limites rgidos, 108 limites suaves, 108 perodo de carncia, 108 registro do uso do bloco, 107 registro do uso do inode, 108
R
RAID conjuntos administrao do, 112 comando raidhotadd, uso do, 112 recriando, 112 status, vericando, 112 conjuntos, criando, 110 aps a instalao, 111 na hora da instalao, 110 contrastada com o LVM, 82 criando conjuntos (Ver RAID, conjuntos, criando) implementaes do, 80
190
consumidores do, 34 CPU, atualizando, 37 falta da, suprindo, 35 fatos relacionados ao, 34 multiprocessamento simtrico, 37 o uso da aplicao do, 35 o uso do sistema operacional do, 35 SMP, 37 sobrecarga das aplicaes, reduzir, 36 sobrecarga do S/O, reduzir, 36 viso geral da, 34 registre sua assinatura, iv registro da assinatura, iv repetio (Ver repetio) RPM, 10 Suporte via Internet, 154 viso geral, 154 swapping, 52 Sysstat, 18, 23 system-cong-printer (Ver congurao da impressora)
U
UID, 129 usurios importncia dos, 6
S
scripts da janela de comandos, 8 segurana importncia dos, 6 informaes especcas ao Red Hat Enterprise Linux, 10 senha, 118 brevidade da, 119 conjunto de caracteres grande usado na, 121 escritas, 121 expirao, 122 fortes, 121 fraca, 119 informaes pessoais usadas na, 120 mais longas, 121 memorvel, 122 palavras usadas na, 120 pequeno conjunto de caracteres usado na, 119 truques com palavras usados na, 120 usada repetidamente, 121 sistema de arquivo etiquetas, 95 Sistema de arquivo EXT2, 96 Sistema de arquivo ext3, 97 Sistema de arquivo ISO 9660, 97 Sistema de arquivo MSDOS, 97 Sistema de arquivo VFAT, 97 sistemas de deteco de intruso, 10 SMB, 101 SMP, 37 software suporte a auto-suporte, 154 documentao, 154 suporte na empresa (on-site), 155 suporte telefnico, 155 suporte via e-mail, 154
Consideraes nais
Os manuais so escritos no formato DocBook SGML verso 4.1. Os formatos HTML e PDF so produzidos usando stylesheets DSSSL personalizadas e scripts jade wrapper personalizados. Os arquivos SGML do DocBook so escritos em Emacs com o auxlio do modo PSGML. Garrett LeSage criou as imagens de alerta (nota, dica, importante, ateno e aviso). Elas podem ser distribudas livremente com a documentao da Red Hat. A Equipe de Documentao de Produtos da Red Hat Linux composta pelas seguintes pessoas: Sandra A. Moore Autora Principal/Mantenedora do Red Hat Enterprise Linux Guia de Instalao para sistemas x86, Itanium, AMD64 e Intel Extended Memory 64 Technology (EM64T da Intel); Autora Principal/Mantenedora do Red Hat Enterprise Linux Guia de Instalao para Arquitetura POWER da IBM; Autora Principal/Mantenedora do Red Hat Enterprise Linux Guia de Instalao para as Arquiteturas IBM S/390 e IBM eServer zSeries John Ha Autor Principal/Mantenedor do Congurando e Administrando um Cluster do Red Hat Cluster Suite; Co-autor/Co-mantenedor do Guia de Segurana do Red Hat Enterprise Linux; Mantenedor dos stylesheets e scripts DocBook personalizados Edward C. Bailey Autor Principal/Mantenedor do Introduo Administrao de Sistemas Red Hat Enterprise Linux; Autor Principal/Mantenedor das Notas de Verso; Autor contribuinte do Guia de Instalao para sistemas x86, Itanium, AMD64 e Intel Extended Memory 64 Technology (EM64T da Intel) do Red Hat Enterprise Linux Karsten Wade Autora Principal/Mantenedora do Red Hat SELinux Guia do Desenvolvimento de Aplicaes; Autora Principal/Mantenedora do Red Hat SELinux Guia das Normas de Escrita Andrius Benokraitis Autor Principal/Mantenedor do Guia de Referncia do Red Hat Enterprise Linux; Co-autor/Co-mantenedor do Guia de Segurana do Red Hat Enterprise Linux; Autor Contribuinte do Guia de Administrao de Sistemas Red Hat Enterprise Linux Paul Kennedy Autor Principal/Mantenedor do Guia do Administrador do Red Hat GFS; Autor Contribuinte do Congurando e Administrando um Cluster do Red Hat Cluster Suite Mark Johnson Autor Principal/Mantenedor do Guia de Administrao e Congurao do Desktop Red Hat Enterprise Linux Melissa Goldin Autora Principal/Mantenedora do Guia Passo a Passo do Red Hat Enterprise Linux A Equipe de Internacionalizao da Red Hat composta pelas seguintes pessoas: Amanpreet Singh Alam tradues para Punjabi Jean-Paul Aubry tradues para o Francs David Barzilay tradues para o Portugus Brasileiro Runa Bhattacharjee tradues para Bengali Chester Cheng tradues para o Chins Tradicional Verena Fuehrer tradues para o Alemo Kiyoto Hashida tradues para o Japons N. Jayaradha tradues para Tamil Michelle Jiyeen Kim tradues para o Coreano Yelitza Louze tradues para o Espanhol Noriko Mizumoto tradues para o Japons Ankitkumar Rameshchandra Patel tradues para Gujarati Rajesh Ranjan tradues para Hindi
192 Nadine Richter tradues para o Alemo Audrey Simons tradues para o Francs Francesco Valente tradues para o Italiano Sarah Wang tradues para o Chins Simplicado Ben Hung-Pin Wu tradues para o Chins Tradicional

Rhel Isa PT BR

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Rhel Isa PT BR

Enviado por

Direitos autorais:

Formatos disponíveis

Red Hat Enterprise Linux 4

Introduo Administrao de Sistemas

1. Informaes especcas da arquitetura

Introduo nvel superior de um menu em uma tela ou janela GUI

3. Ative Sua Assinatura

3.1. Prover um Login para a Red Hat

Um login da Red Hat habilita seu acesso a:

3.2. Prover Seu Nmero de Assinatura

3.3. Conectar Seu Sistema

4. Mais por Vir

4.1. Envie-nos Seu Feedback

As sees seguintes exploram cada uma das questes em detalhes.

1.1. Automatizar Tudo

Captulo 1. A Filosoa da Administrao de Sistemas

1.2. Documentar Tudo

Captulo 1. A Filosoa da Administrao de Sistemas Alteraes

O nome ou as iniciais da pessoa efetuando a alterao A data da alterao A razo da alterao

1.3. Comunique o Mximo Possvel

1.3.1. Informe aos Seus Usurios o Que Voc Far

Atualizao do Sistema na Sexta Noite

Alguns pontos devem ser lembrados:

1.3.2. Informe aos Seus Usurios O Que Voc Est Fazendo

Atualizao do Sistema Programada para Hoje Noite

Captulo 1. A Filosoa da Administrao de Sistemas

1.3.3. Informe aos Seus Usurios O Que Voc Fez

Atualizao do Sistema Completa

1.4. Conhea Seus Recursos

Mas alguns no so to bvios:

1.5. Conhea Seus Usurios

1.6. Conhea Seu Negcio

1.7. A Segurana No Pode ser Postergada

A natureza de possveis ameaas a cada um dos sistemas sob seus cuidados

1.7.1. Os Riscos da Engenharia Social

Captulo 1. A Filosoa da Administrao de Sistemas

1.8. Planejar com Antecedncia

1.9. Espere o Inesperado

1.10. Informaes Especcas do Red Hat Enterprise Linux

Captulo 1. A Filosoa da Administrao de Sistemas

O comando de linha bash A linguagem de script perl A linguagem de script python

1.10.2. Documentao e Comunicao

O editor de texto gedit O editor de texto Emacs O editor de texto Vim

Captulo 1. A Filosoa da Administrao de Sistemas

Captulo 1. A Filosoa da Administrao de Sistemas

1.11. Recursos Adicionais

1.11.1. Documentao Instalada

1.11.2. Sites teis

Aprenda a admin Aprenda como fun-

Captulo 1. A Filosoa da Administrao de Sistemas

1.11.3. Livros Relacionados

2.1. Conceitos Bsicos

Energia da CPU Largura de banda (bandwidth) Memria Armazenamento

Captulo 2. Monitoramento de Recursos

2.2. Monitoramento do Desempenho do Sistema

2.3. Monitorando a Capacidade do Sistema

O monitoramento feito quase continuamente O monitoramento geralmente no to detalhado

Captulo 2. Monitoramento de Recursos

2.4. O Que Monitorar?

2.4.1. Monitorando a Energia da CPU

16 Processos Executveis (runnable)

Captulo 2. Monitoramento de Recursos

Um processo pode estar em estados diferentes, como:

2.4.2. Monitorando a Largura de Banda

Captulo 2. Monitoramento de Recursos Transferncias por Segundo