You are on page 1of 204

Red Hat Enterprise Linux 4

Introdução à Administração de
Sistemas
Red Hat Enterprise Linux 4: Introdução à Administração 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 Re-
search Triangle Park NC 27709 USA

rhel-isa(PT)-4-Impressão-RHI (2004-08-25T17:11)
Copyright © 2005 Red Hat, Inc. Este material pode ser distribuído somente sob os termos e condições definidos na ’Open
Publication License’, versão 1.0 ou mais recente (a versão mais recente está disponível em
http://www.opencontent.org/openpub/).
É proibida a distribuição de versões substancialmente modificadas deste documento sem a permissão explícita do titular dos
direitos autorais.
É proibida a distribuição total ou parcial do trabalho envolvido neste manual, em qualquer formato de livro (papel), para fins
comerciais, sem a autorização prévia do titular dos direitos autorais.
Red Hat e o logo "Shadow Man" da Red Hat são marcas registradas da Red Hat, Inc. nos EUA e em outros países.
Todas as outras marcas referidas neste são de propriedade de seus respectivos titulares.
O número do código de segurança 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
Introdução ............................................................................................................................................ i
1. Informações específicas da arquitetura .................................................................................. i
2. Convenções de Documentos .................................................................................................. i
3. Ative Sua Assinatura............................................................................................................ iv
3.1. Prover um Login para a Red Hat ........................................................................... v
3.2. Prover Seu Número de Assinatura ......................................................................... v
3.3. Conectar Seu Sistema ............................................................................................ v
4. Mais por Vir .......................................................................................................................... v
4.1. Envie-nos Seu Feedback ........................................................................................ v
1. A Filosofia da Administração de Sistemas.................................................................................... 1
1.1. Automatizar Tudo .............................................................................................................. 1
1.2. Documentar Tudo .............................................................................................................. 2
1.3. Comunique o Máximo Possível ......................................................................................... 3
1.3.1. Informe aos Seus Usuários o Que Você Fará...................................................... 3
1.3.2. Informe aos Seus Usuários O Que Você Está Fazendo....................................... 4
1.3.3. Informe aos Seus Usuários O Que Você Fez ...................................................... 4
1.4. Conheça Seus Recursos ..................................................................................................... 5
1.5. Conheça Seus Usuários...................................................................................................... 6
1.6. Conheça Seu Negócio ........................................................................................................ 6
1.7. A Segurança Não Pode ser Postergada .............................................................................. 6
1.7.1. Os Riscos da Engenharia Social ......................................................................... 7
1.8. Planejar com Antecedência................................................................................................ 7
1.9. Espere o Inesperado ........................................................................................................... 8
1.10. Informações Específicas do Red Hat Enterprise Linux ................................................... 8
1.10.1. Automação ........................................................................................................ 8
1.10.2. Documentação e Comunicação......................................................................... 9
1.10.3. Segurança ........................................................................................................ 10
1.11. Recursos Adicionais....................................................................................................... 10
1.11.1. Documentação Instalada ................................................................................. 11
1.11.2. Sites Úteis ....................................................................................................... 11
1.11.3. Livros Relacionados........................................................................................ 11
2. Monitoramento de Recursos ........................................................................................................ 13
2.1. Conceitos Básicos ............................................................................................................ 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 Memória ................................................................................... 17
2.4.4. Monitorando o Armazenamento ....................................................................... 17
2.5. Informações Específicas 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. OProfile ............................................................................................................. 26
2.6. Recursos Adicionais......................................................................................................... 29
2.6.1. Documentação 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. Soluções 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. Informações Específicas 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 Utilização da CPU no Red Hat Enterprise Linux..................... 40
3.4. Recursos Adicionais......................................................................................................... 44
3.4.1. Documentação Instalada ................................................................................... 44
3.4.2. Sites Úteis ......................................................................................................... 44
3.4.3. Livros Relacionados.......................................................................................... 44
4. Memória Física e Virtual.............................................................................................................. 45
4.1. Padrões de Acesso ao Armazenamento ........................................................................... 45
4.2. O Espectro do Armazenamento ....................................................................................... 45
4.2.1. Registradores de CPU ....................................................................................... 46
4.2.2. Memória Cache................................................................................................. 46
4.2.3. Memória Principal — RAM ............................................................................. 47
4.2.4. Discos Rígidos .................................................................................................. 48
4.2.5. Armazenamento de Backup Off-Line ............................................................... 49
4.3. Conceitos da Memória Virtual Básica ............................................................................. 49
4.3.1. Memória Virtual em Termos Simples ............................................................... 49
4.3.2. Backing Store — a Doutrina Central da Memória Virtual ............................... 50
4.4. Memória Virtual: Os Detalhes ......................................................................................... 51
4.4.1. Falhas de Página ............................................................................................... 51
4.4.2. O Conjunto de Trabalho.................................................................................... 52
4.4.3. Swapping........................................................................................................... 52
4.5. Implicações ao Desempenho da Memória Virtual ........................................................... 53
4.5.1. Cenário do Desempenho no Pior Caso ............................................................. 53
4.5.2. Cenário do Desempenho no Melhor Caso ........................................................ 53
4.6. Informações Específicas do Red Hat Enterprise Linux ................................................... 54
4.7. Recursos Adicionais......................................................................................................... 56
4.7.1. Documentação Instalada ................................................................................... 57
4.7.2. Sites Úteis ......................................................................................................... 57
4.7.3. Livros Relacionados.......................................................................................... 57
5. Administrando o Armazenamento .............................................................................................. 59
5.1. Uma Visão Geral do Hardware de Armazenamento........................................................ 59
5.1.1. Pratos de Disco ................................................................................................. 59
5.1.2. Dispositivo de acesso/gravação de dados.......................................................... 59
5.1.3. Braços de Acesso .............................................................................................. 60
5.2. Conceitos de Endereçamento 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. Histórico............................................................................................................ 63
5.3.2. Interfaces Padrão de Hoje ................................................................................. 64
5.4. Características de Desempenho do Disco Rígido ............................................................ 67
5.4.1. Limitações Mecânicas/Elétricas........................................................................ 67
5.4.2. Cargas I/O e Desempenho ................................................................................ 68
5.5. Tornando o Armazenamento Utilizável ........................................................................... 70
5.5.1. Partições/Fatias ................................................................................................. 70
5.5.2. Sistemas de Arquivo ......................................................................................... 71
5.5.3. Estrutura de Diretório ....................................................................................... 74
5.5.4. Habilitando Acesso ao Armazenamento........................................................... 74
5.6. Tecnologias de Armazenamento Avançado ..................................................................... 75
5.6.1. Armazenamento Acessível via Rede ................................................................ 75
5.6.2. Armazenamento Baseado no RAID.................................................................. 76
5.6.3. Administração de Volume Lógico (Logical Volume Management) ................. 81
5.7. Administração Diária do Armazenamento....................................................................... 82
5.7.1. Monitorando Espaço Livre ............................................................................... 82
5.7.2. Questões de Quota de Disco ............................................................................. 85
5.7.3. Questões Relativas a Arquivos.......................................................................... 86
5.7.4. Adicionando/Removendo Armazenamento ...................................................... 87
5.8. Um Pouco Sobre Backups. . . ........................................................................................... 93
5.9. Informações Específicas do Red Hat Enterprise Linux ................................................... 93
5.9.1. Convenção de Nomenclatura de Dispositivos................................................... 93
5.9.2. Conceitos Básicos do Sistema de Arquivo ....................................................... 96
5.9.3. Montando Sistemas de Arquivo ........................................................................ 98
5.9.4. Armazenamento Acessível 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. Administração Diária de Conjuntos RAID ..................................................... 112
5.9.10. Administração de Volume Lógico (Logical Volume Management) ............. 113
5.10. Recursos Adicionais..................................................................................................... 113
5.10.1. Documentação Instalada ............................................................................... 113
5.10.2. Sites Úteis ..................................................................................................... 114
5.10.3. Livros Relacionados...................................................................................... 114
6. Administrando Contas de Usuário e Acesso a Recursos ......................................................... 115
6.1. Administrando Contas de Usuário ................................................................................. 115
6.1.1. O Nome de Usuário ........................................................................................ 115
6.1.2. Senhas ............................................................................................................. 118
6.1.3. Informações de Controle de Acesso ............................................................... 122
6.1.4. Administrando Contas e Acesso a Recursos no Dia-a-Dia............................. 123
6.2. Administrando Recursos do Usuário ............................................................................. 125
6.2.1. Quem Pode Acessar Dados Compartilhados .................................................. 125
6.2.2. Onde os Usuários Acessam os Dados Compartilhados .................................. 126
6.2.3. Quais são as Barreiras Adotadas para Evitar o Abuso de Recursos ............... 127
6.3. Informações Específicas do Red Hat Enterprise Linux ................................................. 127
6.3.1. Contas de Usuário, Grupos e Permissões ....................................................... 127
6.3.2. Arquivos que Controlam Contas de Usuário e Grupos................................... 129
6.3.3. Aplicações de Conta de Usuário e Grupo ....................................................... 133
6.4. Recursos Adicionais....................................................................................................... 134
6.4.1. Documentação Instalada ................................................................................. 134
6.4.2. Sites Úteis ....................................................................................................... 135
6.4.3. Livros Relacionados........................................................................................ 135
7. Impressoras e Impressão ............................................................................................................ 137
7.1. Tipos de Impressoras ..................................................................................................... 137
7.1.1. Considerações de Impressão ........................................................................... 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. Consumíveis de Impressoras de Impacto........................................................ 139
7.3. Impressoras à Jato de Tinta............................................................................................ 140
7.3.1. Consumíveis das Impressoras à Jato de Tinta................................................. 140
7.4. Impressoras à Laser........................................................................................................ 140
7.4.1. Impressoras à Laser Coloridas ........................................................................ 141
7.4.2. Consumíveis 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. Informações Específicas do Red Hat Enterprise Linux ................................................. 143
7.9. Recursos Adicionais....................................................................................................... 145
7.9.1. Documentação 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. Mídia de Backup ............................................................................................. 169
8.2.5. Armazenamento de Backups........................................................................... 171
8.2.6. Questões de Restauração................................................................................. 171
8.3. Recuperação de Desastres.............................................................................................. 172
8.3.1. Criando, Testando e Implementando um Plano de Recuperação 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. Funcionários do Site de Backup ..................................................................... 175
8.3.7. Voltando à Normalidade ................................................................................. 176
8.4. Informações Específicas 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. Documentação Instalada ................................................................................. 180
8.5.2. Sites Úteis ....................................................................................................... 180
8.5.3. Livros Relacionados........................................................................................ 180
Índice Remissivo.............................................................................................................................. 183
Considerações finais........................................................................................................................ 191
Introdução
Bem-vindo ao manual Introdução à Administração de Sistemas Red Hat Enterprise Linux.
O Introdução à Administração de Sistemas Red Hat Enterprise Linux contém informações intro-
dutórias para novos administradores de sistemas Red Hat Enterprise Linux. Este manual não ensina a
executar uma tarefa específica sob o Red Hat Enterprise Linux. Ao invés disso, traz o conhecimento
acumulado ao longo dos anos por diversos administradores de sistemas experientes.
Este manual assume que você tem uma experiência limitada como usuário do Linux, mas nenhuma
experiência como administrador de sistemas Linux. Se o Linux for completamente novo para você (e
o Red Hat Enterprise Linux especificamente), deve começar adquirindo um livro introdutório sobre o
Linux.
Cada capítulo do Introdução à Administração de Sistemas Red Hat Enterprise Linux tem a seguinte
estrutura:

• Visão geral — Esta seção aborda o tópico do capítulo sem entrar em detalhes sobre um sistema
operacional, tecnologia ou metodologia específica.
• Material específico do Red Hat Enterprise Linux — Esta seção aborda os aspectos do tópico rela-
cionados ao Linux em geral e ao Red Hat Enterprise Linux em particular.
• Recursos Adicionais para estudos mais profundos — Esta seção inclui indicadores para outros
manuais do Red Hat Enterprise Linux, sites úteis e livros contendo informações relacionadas ao
tópico.
Ao adotar uma estrutura consistente, os leitores podem acessar o Introdução à Administração de Sis-
temas 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 seções
focadas no Red Hat Enterprise Linux, enquanto um novo administrador de sistemas pode começar
lendo somente as seções de informações gerais e usar as seções específicas do Red Hat Enterprise
Linux como uma introdução a recursos mais profundos.
E por falar em recursos mais profundos, o Guia de Administração de Sistemas Red Hat Enterprise
Linux é um recurso excelente para executar tarefas específicas num ambiente Red Hat Enterprise
Linux. Os administradores que quiserem ter informações mais factuais e aprofundadas, devem con-
sultar o Guia de Referência do Red Hat Enterprise Linux.
As versões HTML, PDF e RPM dos manuais estão disponíveis no CD de Documentação do Red Hat
Enterprise Linux e online: http://www.redhat.com/docs/.

Nota
Apesar deste manual refletir as informações mais recentes possíveis, leia as Notas da Versão do Red
Hat Enterprise Linux para acessar as informações que não estavam disponíveis antes da finalização
de nossa documentação. Elas podem ser encontradas no CD 1 do Red Hat Enterprise Linux e online:
http://www.redhat.com/docs/.

1. Informações específicas da arquitetura


Exceto quando informado, todas as informações contidas neste manual se aplicam somente ao proces-
sador x86 e aos processadores com as tecnologias Intel® Extended Memory 64 Technology (EM64T
da Intel®) e AMD64. Para obter informações de arquiteturas específicas, consulte o Guia de Insta-
lação do Red Hat Enterprise Linux.
ii Introdução

2. Convenções de Documentos
Ao ler este manual, determinadas palavras estão representadas com fontes, tipos, tamanhos e pesos
diferentes. Este destaque é sistemático; palavras diferentes são representadas no mesmo estilo para
indicar sua inclusão em uma categoria específica. Os tipos de palavras representadas desta maneira
incluem as seguintes:

comando
Os comandos do Linux (e comandos de outros sistemas operacionais, quando usados) são rep-
resentados 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 contém palavras
que serão exibidas em um estilo diferente por si só (como nomes de arquivos). Nestes casos,
estas são consideradas parte do comando, e então a frase inteira será exibida como um comando.
Por exemplo:
Use o comando cat testfile para visualizar o conteúdo de um arquivo chamado testfile,
no diretório de trabalho atual.

nome do arquivo
Nomes de arquivos, diretórios, localidades de arquivos e nomes de pacotes RPM são representa-
dos desta maneira. Este estilo indica que existe um determinado arquivo ou diretório com aquele
nome no seu sistema. Exemplos:
O arquivo .bashrc do seu diretório ’home’ contém definições da janela de comandos tipo bash
e codenomes para seu uso pessoal.
O arquivo /etc/fstab contém informações sobre os dispositivos e sistemas de arquivo difer-
entes do sistema.
Instale o RPM webalizer se você quiser usar um programa de análise do arquivo de registro do
servidor Web.

aplicação
Este estilo indica que o programa é uma aplicação direcionada ao usuário final (ao contrário 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 então pressione a tecla
[Tab]. Seu terminal exibe uma lista dos arquivos contidos no diretório que começam com esta
letra.

[tecla]-[combinação]
Uma combinação de sequência de teclas é representada desta maneira. Por exemplo:
A combinação de teclas [Ctrl]-[Alt]-[Espaço] termina sua sessão gráfica, retornando à tela ou ao
console da autenticação gráfica.

texto exibido em uma interface GUI (gráfica)


Um título, palavra ou frase na tela ou janela da interface GUI é exibida neste estilo. O texto
exibido neste estilo é usado na identificação de uma tela GUI específica ou um elemento de uma
tela GUI (como o texto associado a uma caixa de verificação ou campo). Exemplo:
Selecione a caixa de verificação Solicitar Senha se você deseja que seu protetor de tela solicite
uma senha antes de ser desbloqueado.
Introdução iii

nível superior de um menu em uma tela ou janela GUI


Uma palavra neste estilo indica que a palavra está no nível superior de um menu suspenso (pull-
down menu). Se você clicar na palavra na tela GUI, o resto do menu deverá aparecer. Por exem-
plo:
Abaixo de Arquivo em um terminal do GNOME, você verá a opção Nova Aba, que permite a
você abrir diversos prompts de comando na mesma janela.
Se você precisar digitar uma sequência de comandos a partir de um menu GUI, eles são exibidos
como o exemplo a seguir:
Vá para Botão do Menu Principal (no Painel) => Programação => Emacs para iniciar o editor
de texto Emacs.

botão em uma tela ou janela GUI


Este estilo indica que o texto pode ser encontrado em um botão clicável de uma tela GUI. Por
exemplo:
Clique no botão Voltar para retornar à última página 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 conteúdo de um diretório:
Desktop about.html logs paulwesterberg.png
Mail backupfiles mail reports
O output exibido em resposta ao comando (neste caso, o conteúdo do diretório) é 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 usuário
O texto que o usuário 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 instalação em modo texto, você deve digitar o co-
mando text no prompt boot:.

substituível


Texto usado para exemplos que devem ser subtituídos com dados providos pelo usuário são
apresentados neste estilo. No exemplo a seguir, version-number é exibido neste estilo:
O
 
diretório da fonte do kernel é /usr/src/ version-number /,
version-number é a versão do kernel instalado neste sistema.
 onde

Adicionalmente, nós utilizamos diversas estratégias diferentes para chamar sua atenção a determi-
nadas partes da informação. De acordo com o quão crucial as informações são para seu sistema, elas
são apresentadas como uma nota (lembrete), dica, importante, atenção ou um aviso. Por exemplo:
iv Introdução

Nota
Lembre-se que o Linux é sensível a maiúsculas e minúsculas. Em outras palavras, uma rosa não é
uma ROSA nem uma rOsA.

Dica
O diretório /usr/share/doc/ contém documentação adicional para os pacotes instalados em seu
sistema.

Importante
Se você modificar o arquivo de configuração do DHCP, as alterações não terão efeito até que você
reinicie o daemon do DHCP.

Atenção
Não execute tarefas de rotina como root — use uma conta de usuário comum, a não ser que você
precise usar a conta root para tarefas de administração do sistema.

Aviso
Cuidado para remover somente as partições necessárias do Red Hat Enterprise Linux. Remover
outras partições pode resultar na perda de dados ou num ambiente de sistema corrompido.

3. Ative Sua Assinatura


Antes de poder acessar as informações de manutenção do software e serviços, e a documentação 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 número para a assinatura
• Conectar seu sistema
Na primeira vez que iniciar a instalação de seu Red Hat Enterprise Linux, você verá o pedido de
registro na Red Hat usando o Agente de Configuração. Se você seguir os pedidos durante o Agente
de Configuração, poderá completar os passos do registro e ativar sua assinatura.
Introdução v

Se você não puder completar o registro durante o Agente de Configuração (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 não possui um login para a Red Hat, pode criá-lo quando for solicitado no Agente de
Configuração ou online em:

https://www.redhat.com/apps/activate/newlogin.html

Um login da Red Hat habilita seu acesso a:

• Atualizações, erratas e manutenção do software através da Red Hat Network


• Recursos do suporte técnico, documentação 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 Número de Assinatura


Seu número de assinatura está localizado no pacote que acompanha seu pedido. Caso seu pacote não
inclua um número de assinatura, sua assinautra já foi ativada e, portanto, você pode pular este passo.
Você pode prover seu número de assinatura ao ser solicitado durante o Agente de Configuração ou
visitando http://www.redhat.com/register/.

3.3. Conectar Seu Sistema


O Cliente de Registro da Red Hat Network auxilia na conexão de seu sistema para que você possa
obter as atualizações e efetuar a administração de sistemas. Há três maneiras para conectar:

1. Durante o Agente de Configuração — Selecione as opções Enviar informações de hardware


e Enviar lista de pacotes do sistema quando aparecerem.
2. Após completar o Agente de Configuração — No Menu Principal, clique em Ferramentas
do Sistema, e então selecione Red Hat Network.
3. Após completar o Agente de Configuração — Invoque o seguinte na janela de comandos como
usuário root:
• /usr/bin/up2date --register

4. Mais por Vir


O Introdução à Administração de Sistemas Red Hat Enterprise Linux é parte do crescente compro-
metimento da Red Hat em prover suporte útil e oportuno aos usuários do Red Hat Enterprise Linux.
Juntamente ao lançamento de novas versões do Red Hat Enterprise Linux, nós depositamos todos os
nossos esforços para incluir documentação nova e atualizada para você.
vi Introdução

4.1. Envie-nos Seu Feedback


Se você encontrar um erro de digitação no Introdução à Administração de Sistemas Red Hat En-
terprise Linux, ou se você encontrou uma maneira de melhorar este manual, nós adoraríamos saber.
Por favor, submeta um relatório no Bugzilla (http://bugzilla.redhat.com/bugzilla) sobre o componente
rhel-isa.
Certifique-se de mencionar o identificador do manual:

rhel-isa(PT)-4-Impressão-RHI (2004-08-25T17:11)

Se você mencionar o identificador, nós saberemos exatamente qual versão do guia você possui.
Se você tiver alguma sugestão para melhorar a documentação, tente ser o mais específico possível. Se
encontrar um erro, por favor inclua o número da seção e um trecho do texto próximo ao erro para que
possamos localizá-lo facilmente.
Capítulo 1.
A Filosofia da Administração de Sistemas
Apesar das particularidades de um administrador de sistemas variarem de acordo com a plataforma,
há questões básicas que não variam. Estas questões compoem a filosofia da administração de sistemas.
As questões são:

• Automatizar tudo
• Documentar tudo
• Comunicar o máximo possível
• Conhecer seu recursos
• Conhecer seus usuários
• Conhecer seu negócio
• A segurança não pode ser postergada
• Planejar com antecedência
• Espere o inesperado
As seções seguintes exploram cada uma das questões em detalhes.

1.1. Automatizar Tudo


A maioria dos administradores de sistemas é sobrecarregado — seja pelos seus usuários, pelos seus
sistemas ou por ambos. Em muitos casos, a automação é a única saída. Em geral, qualquer atividade
executada mais de uma vez deve ser analisada como uma possível candidata para automação.
Aqui estão algumas tarefas comumente automatizadas:

• Verificação e relatório do espaço livre em disco


• Backups
• Coleta de dados sobre o desempenho do sistema
• Manutenção da conta do usuário (criação, remoção, etc)
• Funções específicas a negócios (envio de dados a um servidor Web, relatórios
mensais/quadrimestrais/anuais, etc)
Esta lista não está completa; as funções automatizadas por administradores de sistemas são limitadas
somente pela vontade do administrador em escrever os scripts necessários. Neste caso, ser preguiçoso
(e deixar todo o trabalho mundano para o computador) é uma coisa boa.
A automação também oferece aos usuários o benefício extra de prever melhor a consistência dos
serviços.

Dica
Tenha em mente que, se você tiver que automatizar uma tarefa, é provável que você não seja o
primeiro administrador de sistemas com essa necessidade. É aqui que os benefícios do software
livre se sobressaem — você pode alavancar o trabalho que outra pessoa teve em automatizar o
2 Capítulo 1. A Filosofia da Administração 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 opção de instalar um servidor novinho ou escrever um documento de procedimentos sobre
a execução 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 razões:

"Mais tarde eu faço."


Infelizmente, isto não é verdade na maioria das vezes. Mesmo se o administrador de sistemas não
estiver brincando, a natureza do trabalho faz com que as atividades do cotidiano tornem-se muito
caóticas para "fazer mais tarde." Pior ainda, quanto mais a tarefa é adiada, mais é esquecida,
levando à produção de um documento menos detalhado (e portanto menos útil).

"Por quê anotar? Eu vou lembrar."


A não ser que você seja uma daquelas pessoas com memória fotográfica, você não lembrará. Ou
pior, lembrará somente metade, sem perceber que está esquecendo a história 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 situação.

"Seu eu manter na minha mente, eles não poderão me despedir — terei estabilidade no emprego!"
Apesar disto poder funcionar por um tempo, invariavelmente acarreta em menor — e não maior
— estabilidade de emprego. Por um momento, pense no que pode ocorrer durante uma emergên-
cia. Você pode não estar disponível; sua documentação pode salvar o dia se instruir alguém a
resolver o problema durante sua ausência. E lembre-se que as emergências tendem a ocorrer com
mais frequência quando a alta gerência presta atenção. Nestes casos, é melhor sua documentação
ser parte da solução do que sua ausência ser parte do problema.
Além disso, se você faz parte de uma pequena empresa em expansão, pode surgir a necessidade
de outro administrador de sistemas. Como esta pessoa pode aprender a te cobrir se está tudo
na sua cabeça? Pior ainda, sem documentação, você pode ser tão indispensável a ponto de não
poder avançar na sua carreira. Você pode acabar trabalhando para aquela pessoa que contratou
para ajudá-lo.
Esperamos que agora você esteja convencido dos benefícios da documentação de sistemas. Isto nos
leva à questão seguinte: O quê você deve documentar? Aqui está uma lista parcial:

Normas
As normas são elaboradas para formalizar e clarificar sua relação com a comunidade de usuários.
Elas explicam aos seus usuários como você lida com seus pedidos de recursos e/ou assistência.
A natureza, o estilo e o método de disseminação das normas para sua comunidade variam de
empresa a empresa.

Procedimentos
Os procedimentos são qualquer sequência passo-a-passo das ações para realizar uma determi-
nada tarefa. Os procedimentos a serem documentados podem incluir procedimentos de backup,
procedimentos para administração de contas de usuários, procedimentos para relatório de prob-
lemas e assim por diante. Como na automação, se um procedimento é seguido mais de uma vez,
é uma boa idéia documentá-lo.
Capítulo 1. A Filosofia da Administração de Sistemas 3

Alterações
Uma grande parte da carreira de um administrador de sistemas é dedicada às alterações — con-
figurar sistemas para o máximo desempenho, ajustar scripts, modificar arquivos de configuração
e assim por diante. Todas estas alterações devem ser documentadas de alguma forma. Caso con-
trário, você pode encontrar-se numa situação muito confusa devido uma alteração feita há vários
meses.
Algumas empresas utilizam métodos mais complexos para registrar as alterações, mas, muitas
vezes, basta apenas ter uma revisão da história no início do arquivo sendo modificado. Cada
entrada da história revisada deve conter, no mínimo:
• O nome ou as iniciais da pessoa efetuando a alteração
• A data da alteração
• A razão da alteração
Isso resulta em entradas concisas, porém úteis:
ECB, 12-Junho-2002 — Item atualizado para a nova impressora de Contabilidade (para suportar
a substituição da habilidade em imprimir duplex)

1.3. Comunique o Máximo Possível


Quando se trata de seus usuários, não há comunicação demasiada. Tenha em mente que pequenas
alterações de sistemas que você pensa ser ínfimas podem confundir totalmente o assistente adminis-
trativo de Recursos Humanos.
O método através do qual você se comunica com seus usuários 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 é suficiente colocar um comunicado no mural da sala de funcionários.
Em qualquer um dos casos, use o(s) método(s) eficaz(es) em sua organização.
Em geral, é melhor utilizar esta tática usada para escrever artigos de jornal:

1. Informe aos seus usuários o que você fará


2. Informe aos seus usuários o que você está fazendo
3. Informe aos seus usuários o que você fez
As seções a seguir trazem mais detalhes sobre estes passos.

1.3.1. Informe aos Seus Usuários o Que Você Fará


Certifique-se de prover suficiente avisos aos seus usuários antes de fazer qualquer coisa. A quantidade
de avisos varia necessariamente de acordo com o tipo de alteração (fazer o upgrade de um sistema
operacional demanda mais tempo que alterar a cor default da tela de login do sistema), e também com
a natureza da sua comunidade de usuários (usuários com perfil mais técnico geralmente adaptam-se
mais rapidamente às alterações que usuários com poucas ou nenhuma característica técnica.)
Você deve descrever, no mínimo:

• A natureza da alteração
• Quando a alteração ocorrerá
• Porque está ocorrendo
• Quanto tempo deve levar, aproximadamente
• O impacto (se houver) que os usuários podem esperar devido a alteração
4 Capítulo 1. A Filosofia da Administração de Sistemas

• Informações de contato caso tenham dúvidas ou problemas


Eis uma situação hipotética. O departamento de finanças está enfrentando problemas de lentidão em
seu servidor de banco de dados. Você desligará o servidor, atualizará (upgrade) o módulo da CPU para
um modelo mais veloz e o reinicializará. Uma vez terminado, você moverá o banco de dados para um
armazenamento mais rápido baseado no RAID. Aqui está um possível comunicado para essa situação:

Atualização do Sistema na Sexta à Noite


A partir desta sexta-feira às 18hs (meia-noite para nossos funcionários do escritório em Berlim), todas as
aplicações financeiras estarão indisponíveis por aproximadamente quatro horas.
Durante este período, serão executadas alterações no hardware e software do banco de dados de finanças.
Estas alterações devem reduzir drasticamente o tempo necessário para rodar as aplicações de Contas a
Pagar, Contas a Receber, e também o relatório de Balanço Semanal.
Além do tempo fora do ar, a maioria das pessoas não deve notar outras alterações. No entanto, aqueles que
elaboraram suas próprias consultas ao SQL devem estar cientes que o layout de alguns índices será alterado.
Estas alterações estão documentadas na intranet da empresa, na página de Finanças.
Caso vocês tenham alguma dúvida ou comentário, favor contatar o Administrador de Sistemas no ramal
4321.

Alguns pontos devem ser lembrados:

• Comunique efetivamente o início e a duração de qualquer tempo fora do ar que possa estar en-
volvido na alteração.
• Certifique-se de informar a hora da alteração de maneira eficaz a todos os usuários, independente
de suas localidades.
• Use termos que seus usuários entendam. As pessoas impactadas por esta mudança não se importam
se o novo modelo da CPU é uma unidade de 2GHz com o dobro de memória cache L2, ou se o
banco de dados é alocado num volume lógico RAID 5.

1.3.2. Informe aos Seus Usuários O Que Você Está Fazendo


Este passo é basicamente um aviso de última hora da alteração prestes a ocorrer e, como tal, deve
ser uma breve repetição da primeira mensagem, porém com a iminência da alteração mais aparente
("A atualização do sistema ocorrerá HOJE À NOITE."). Esta também é uma boa oportunidade para
responder publicamente quaisquer perguntas que você tenha recebido como resultado da primeira
mensagem.
Dando continuidade ao nosso exemplo hipotético, aqui está uma sugestão para o aviso de última hora:

Atualização do Sistema Programada para Hoje à Noite


Lembrete: A atualização anunciada na última segunda-feira ocorrerá conforme programada, hoje às 18hs
(meia-noite para o escritório de Berlim). Você pode conferir o comunicado original na intranet, na página
de Administração de Sistemas.
Diversas pessoas perguntaram se deveriam parar de trabalhar mais cedo hoje à noite para garantir que seus
trabalhos tenham backup antes da atualização. Isto não será necessário, visto que a atualização dos sistemas
de hoje à noite não impactará nenhuma tarefa efetuada em suas estações de trabalho.
Lembrem-se: aqueles que elaboraram suas próprias consultas ao SQL devem saber que o layout de alguns
índices será alterado. Isto está documentado na intranet da empresa, na página de Finanças.

Seus usuários foram alertados; agora você está pronto para efetuar a atualização em si.
Capítulo 1. A Filosofia da Administração de Sistemas 5

1.3.3. Informe aos Seus Usuários O Que Você Fez


Após finalizar suas alterações, você deve informar aos seus usuários o que você fez. Novamente, esta
deve ser um resumo das suas mensagens anteriores (com certeza, alguém deixou de lê-las.) 1
Entretanto, há algo importante a acrescentar. É vital informar seus usuários sobre o estado atual do
sistema. A atualização não ocorreu conforme esperado? O novo servidor de armazenamento serve
apenas sistemas de Engenharia e não de Finanças? Este tipo de questões deve ser mencionado aqui.
Obviamente, se o estado atual difere do que você comunicou anteriormente, você deve clarificar este
ponto e descrever o que será feito (se houver medidas determinadas) para atingir a solução final.
Em nossa situação hipotética, a atualização teve alguns problemas. O novo modelo de CPU não fun-
cionou; uma ligação ao fabricante revelou que é necessária uma nova versão do módulo para atualiza-
ções deste tipo. No aspecto positivo, a migração do banco de dados ao volume RAID foi executada
com sucesso (apesar de ter demorado um pouco mais devido a problemas com o módulo da CPU.)
Aqui está uma sugestão de comunicado:

Atualização do Sistema Completa


A atualização de sistema programada para sexta-feira à noite (consulte a página de Administração de Sis-
temas na intranet) foi completa. Infelizmente, questões relacionadas ao hardware impediram que uma das
tarefas fosse completa. Devido este problema, as outras tarefas demoraram mais que as quatro horas orig-
inalmente programadas. Portanto, todos os sistemas estavam de volta à produção à meia-noite (às 6hs do
sábado para o escritório de Berlim).
Devido às questões remanescentes de hardware, o desempenho da AP, AR e do relatório de Balanço Se-
manal será ligeiramente melhor, mas não tanto quanto planejado originalmente. Uma segunda atualização
será comunicada e programada assim que resolvermos as questões que impossibilitaram a conclusão da
tarefa.
Favor notar que a atualização alterou alguns índices de banco de dados; as pessoas que elaboraram suas
própiras consultas ao SQL devem verificar a página de Finanças na intranet da empresa.
No caso de dúvidas, favor contatar a Administração de Sistemas no ramal 4321.

Com este tipo de informação, seus usuários terão conhecimento suficiente para continuarem seus
trabalhos e entenderem como as alterações os impactam.

1.4. Conheça Seus Recursos


A administração de sistemas consiste basicamente em balancear recursos entre as pessoas e os pro-
gramas que os utilizam. Consequentemente, sua carreira como administrador de sistemas será curta e
estressante se você não entender perfeitamente os recursos à sua disposição.
Alguns destes recursos parecem bastante óbvios:

• Recursos de sistema, como o poder de processamento, a memória e o espaço disponível em disco


• Largura de banda de rede (network bandwidth)
• Dinheiro disponível no orçamento de TI
Mas alguns não são tão óbvios:

1. Certifique-se de enviar esta mensagem assim que o trabalho estiver concluído, antes de ir para casa. Após
sair do escritório, é muito fácil esquecer, deixando seus usuários sem saber se podem usar o sistema ou não.
6 Capítulo 1. A Filosofia da Administração de Sistemas

• Os serviços dos funcionários de operações, outros administradores de sistemas ou até mesmo um


assistente administrativo
• Tempo (geralmente de suma importância, principalmente quando envolve o tempo durante o qual
serão feitos backups do sistema)
• Conhecimento (seja armazenado em livros, na documentação do sistema ou na mente de uma pessoa
que trabalhou para a empresa nos últimos 20 anos)
É importante notar o valor de elaborar um inventário completo destes recursos disponíveis e mantê-lo
atualizado — a falta de "consciência da situação" dos recursos pode ser pior que consciência nenhuma.

1.5. Conheça Seus Usuários


Apesar de algumas pessoas se incomodarem com o termo "usuários" (talvez devido ao uso do termo
por algum administrador de sistemas de forma pejorativa), é usado aqui sem esta conotação. Usuários
são as pessoas que utilizam os sistemas e recursos pelos quais você é responsável — nem mais, nem
menos. Como tais, eles são centrais para sua habilidade em administrar seus sistemas adequadamente.
Sem entender seus usuários, 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 apli-
cações estritamente definido e requer pouco dos recursos de sistema. Um engenheiro de software, por
outro lado, usa muitas aplicações diferentes e sempre agradece mais recursos de sistema (para tempos
de criação mais rápidos). Dois usuários completamente diferentes com necessidades completamente
diferentes.
Certifique-se de aprender o máximo possível a respeito de seus usuários.

1.6. Conheça Seu Negócio


Mesmo se você trabalha para uma empresa grande e multinacional, ou então para uma pequena escola
comunitária, deve entender a natureza do ambiente de negócios no qual você trabalha. Isto pode ser
resumido em uma questão:
Qual é o propósito dos sistemas que você administra?
O ponto central aqui é entender o propósito de seus sistemas sob um aspecto mais global:

• As aplicações que devem rodar num determinado período de tempo, como o fim de um mês, de um
quadrimestre ou de um ano
• Os períodos durante os quais deve ser feita a manutenção do sistema
• As novas tecnologias que podem ser usadas para resolver antigos problemas do negócio
Levando em consideração o negócio da sua empresa, você tomará melhores decisões diárias para seus
usuários e para você.

1.7. A Segurança Não Pode ser Postergada


Não importa o que você pensa sobre o ambiente no qual seus sistemas rodam; você não pode ignorar
o fator segurança. Mesmo sistemas standalone não conectados à Internet podem estar em risco (apesar
dos riscos serem obviamente diferentes de um sistema que tem conexões com o mundo externo).
Consequentemente, é extremamente importante considerar as implicações de segurança em tudo que
você fizer. A lista seguinte ilustra os tipos de questões que você deve considerar:

• A natureza de possíveis ameaças a cada um dos sistemas sob seus cuidados


Capítulo 1. A Filosofia da Administração de Sistemas 7

• A localidade, o tipo e o valor dos dados nestes sistemas


• O tipo e a frequência de acesso autorizado a estes sistemas
Quando pensar em segurança, não cometa o erro de assumir que os possíveis ataques a seus sistemas
virão apenas de fora da empresa. Muitas vezes, o invasor é alguém de dentro da empresa. Portanto,
na próxima vez que você caminhar pelo escritório, observe as pessoas ao seu redor e pergunte a si
mesmo:
O que aconteceria se esta pessoa tentasse sabotar nossa segurança?

Nota
Isso não significa 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 segurança que
uma pessoa naquela função poderia perpetrar, caso tivesse essa vontade.

1.7.1. Os Riscos da Engenharia Social


Apesar da primeira reação da maioria dos administradores de sistemas quando pensa na segurança ser
concentrar nos aspectos tecnológicos, é importante manter a perspectiva. Frequentemente, as brechas
na segurança não são originadas na tecnologia, mas na natureza humana.
Pessoas interessadas nas brechas de segurança frequentemente usam a natureza humana para burlar
inteiramente os controles de acesso tecnológico. Isso é conhecido como engenharia social. Eis um
exemplo:
O operador do segundo turno recebe uma ligação externa. A pessoa que ligou clama ser o Diretor
Financeiro da empresa (seu nome e informações foram obtidos no site da empresa, na página "Equipe
de Gerência").
A pessoa que ligou clama estar em algum lugar do outro lado do globo (talvez esta parte da história
seja ficção total, ou talvez o site de sua empresa tenha publicado uma nota de imprensa mencionando
a presença do diretor numa feira internacional).
A pessoa que ligou conta uma fábula: seu laptop foi roubado no aeroporto, ele está com um cliente
importante e, portanto, precisa de acesso à intranet corporativa para verificar a conta deste cliente.
Será que o operador deve ser bonzinho e dar as informações de acesso a ele?
Você sabe o que seu operador faria? A não ser que ele tenha instruções (na forma de normas e proces-
sos), você provavelmente não sabe o que aconteceria.
Assim como as luzes de um semáforo, o objetivo das normas e procedimentos é prover instruções
explícitas sobre o que é e o que não é comportamento adequado. No entanto, assim como as luzes
do semáforo, as normas e procedimentos funcionam somente se todos os seguem. Aqui está o X da
questão — é improvável que todos sigam suas normas e procedimentos. Na realidade, dependendo
da natureza de sua empresa, é possível que você nem tenha autoridade suficiente para definir normas,
muito menos para reforçá-las. O que fazer então?
Infelizmente, não há respostas fáceis. A educação dos usuários pode ajudar: faça tudo que você puder
para alertar sua comunidade de usuários sobre a segurança e engenharia social. Minstre apresentações
sobre segurança no horário de almoço. Envie links de artigos sobre segurança nas listas de discussão
da empresa. Enfatize sua disponibilidade para as perguntas de seus usuários sobre coisas que não
parecem corretas.
Em suma, envie sua mensagem aos usuários de todas as formas que puder.
8 Capítulo 1. A Filosofia da Administração de Sistemas

1.8. Planejar com Antecedência


Os administradores de sistemas que absorveram todo este aconselhamento e fizeram o possível para
seguí-lo à risca, serão ótimos administradores de sistemas — por um dia. Eventualmente, o ambiente
mudará e nosso administrador fantástico será pego de surpresa. Por que? Nosso fantástico admin-
istrador falhou em planejar com antecedência.
Certamente, ninguém pode predizer o futuro com 100% de acuracidade. No entanto, com um pouco
de consciência, fica fácil ler os sinais de muitas mudanças:

• Uma simples menção de um novo projeto durante aquela reunião semanal sacal é, certamente, um
sinal certeiro de que você provavelmente precisará suportar seus usuários no futuro próximo.
• Uma conversa sobre uma aquisição iminente significa que você talvez acabe sendo responsável por
sistemas novos (e possivelmente incompatíveis) 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 usuários.

1.9. Espere o Inesperado


Apesar da frase "esperar o inesperado" ser clichê, reflete uma verdade elementar que todos os admin-
istradores de sistemas devem entender:
Haverá momentos em que você será pego de surpresa.
Após estar confortável com este fato desconfortante, o que um administrador de sistemas engajado
pode fazer? A resposta está na flexibilidade; executando seu trabalho de maneira a oferecer a você (e
aos seus usuários) o maior número de opções possível. Abordemos, por exemplo, a questão do espaço
em disco. Dado que nunca ter espaço suficiente em disco parece ser uma lei mais física do que a lei
da gravidade, é razoável assumir que, em algum ponto, você será confrontado por uma necessidade
desesperada imediata de espaço adicional em disco.
O que faria um administrador de sistemas que espera o inesperado? Talvez seja possível manter alguns
drives de disco reservas na prateleira no caso de problemas com o hardware 2 . Uma peça reserva
deste tipo pode ser empregada rapidamente3 temporariamente para resolver a necessidade imediata
de espaço em disco, alocando mais tempo para a solução definitiva (seguindo o procedimento padrão
para a obtenção de drives de disco adicionais, por exemplo).
Ao tentar antecipar os problemas antes de ocorrerem, você será capaz de responder mais rápida e
efetivamente do que se você deixar se surpreender.

1.10. Informações Específicas do Red Hat Enterprise Linux


Esta seção aborda as informações relacionadas à filosofia da administração de sistemas específicas ao
Red Hat Enterprise Linux.

1.10.1. Automação
A automação de tarefas executadas frequentemente sob o Red Hat Enterprise Linux requer o conhec-
imento de diversos tipos de tecnologia. Primeiro, os comandos que controlam o tempo do comando
ou a execução do script. Os comandos cron e at são os mais usados para estas funções.

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 crítico durante a produção.
3. Novamente: os administradores de sistemas que pensam pró-ativamente configuram seus sistemas de forma
a facilitar o máximo possível a adição de um novo drive de disco ao sistema.
Capítulo 1. A Filosofia da Administração de Sistemas 9

Incorporando um sistema de especificação de tempo bastante flexível, mas de fácil entendimento, o


cron pode agendar a execução 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 execução.
O comando at (e o comando batch relacionado) é mais apropriado para agendar a execução de
scripts ou comandos para uma única ocorrência. Estes comandos implementam um sub-sistema batch
rudimentar que consiste de múltiplas filas com prioridades de agendamento variadas. As prioridades
são conhecidas como níveis de niceness (devido o nome do comando — nice). Ambos os comandos,
at e batch, são perfeitos para tarefas que devem ocorrer com horário de início determinado, mas não
são críticas em seu tempo de término.
Em seguida, estão as diversas linguagens de script. Estas são as "linguagens de programação", usadas
pelo administrador de sistemas comum para automatizar operações manuais. Há muitas linguagens de
script (e cada administrador de sistemas geralmente tem sua favorita), mas as que seguem são as mais
comuns no momento:

• O comando de linha bash


• A linguagem de script perl
• A linguagem de script python
Além das diferenças óbvias entre estas linguagens, a maior diferença é a maneira através 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 utilitários (por exemplo:
para efetuar a manipulação dos strings de caracteres), enquanto os scripts perl executam mais esse
tipo de operação usando funcionalidades integradas na própria linguagem. Um script escrito usando
o python pode explorar totalmente as capacidades orientadas a objetos da linguagem, tornando os
scripts mais complexos facilmente extensíveis.
Isto significa que, para conhecer bem o script da janela de comandos, você deve se familiarizar com
os diversos programas de utilitários (como grep e sed) que são parte do Red Hat Enterprise Linux.
Aprender perl (e python), por outro lado, tende ser um processo mais "auto-suficiente". No entanto,
muitas construções da linguagem perl são baseadas na sintaxe de diversos programas de utilitários
tradicionais do UNIX, e portanto são familiares aos administradores de sistemas Red Hat Enterprise
Linux com experência em scripts de janela de comandos.

1.10.2. Documentação e Comunicação


Nas áreas de documentação e comunicação há poucas coisas específicas ao Red Hat Enterprise Linux.
Como documentação e comunicação podem consistir de qualquer coisa, de adicionar comentários a
um arquivo-texto de configuração a atualizar uma página 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 disponíveis 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 aplicação estritamente gráfica (ou seja, requer um ambiente do Sistema
X Window), enquanto vim e Emacs são baseados em texto por natureza.
10 Capítulo 1. A Filosofia da Administração de Sistemas

A questão sobre qual é o melhor editor de texto tem sido um debate quase tão longo quanto a existência
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 função Composer do
navegador web Mozilla. Obviamente, alguns administradores de sistemas preferem codificar seu
HTML manualmente, o que torna um editor de texto comum uma ferramenta perfeitamente aceitável.
Em relação a e-mail, o Red Hat Enterprise Linux inclui o cliente gráfico de e-mail Evolution, o cliente
de e-mail Mozilla (também gráfico) 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. Segurança
Como mencionado anteriormente neste capítulo, a segurança não pode ser um pensamento posterior,
e a segurança sob o Red Hat Enterprise Linux não é superficial. Os controles de acesso e autenticação
são profundamente integrados ao sistema operacional e baseados em designs extraídos de longos anos
de experiência da comunidade UNIX.
Para autenticação, o Red Hat Enterprise Linux usa o PAM — Módulos de Autenticação Plugáveis.
O PAM possibilita o ajuste fino da autenticação de usuários através da configuração de bibliotecas
compartilhadas, usadas por todas as aplicações que baseiam sua autenticação no PAM. Tudo isso é
feito sem a necessidade de alterações nas aplicações.
O controle de acesso sob o Red Hat Enterprise Linux usa permissões tradicionais do estilo UNIX
(ler/acessar, gravar e executar) para as classes usuário, grupo e "outros". Como no UNIX, o Red Hat
Enterprise Linux também usa os bits setuid e setgid para conferir direitos de acesso expandido a
processos rodando um programa específico, baseado na propriedade do arquivo do programa. Ob-
viamente, isto traz a necessidade de auditar cuidadosamente qualquer programa que vá rodar com
privilégios setuid ou setgid para garantir que não há vulnerabilidades exploráveis.
O Red Hat Enterprise Linux também 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 usuários
ou grupos podem acessar um arquivo ou diretório. Por exemplo: as permissões de um arquivo podem
restringir todos os acessos de qualquer pessoa além do proprietário (owner) do arquivo. Além disso,
a ACL do arquivo pode ser configurada para permitir somente ao usuário zé gravar/salvar e ao grupo
finanças ler/acessar o arquivo.
Um outro aspecto da segurança é a habilidade de registrar as atividades do sistema. O Red Hat En-
terprise Linux usa extensivamente os registros, nos níveis do kernel e da aplicação. O registro é con-
trolado pelo daemon de registro do sistema, syslogd, que pode registrar informações do sistema
localmente (normalmente em arquivos do diretório /var/log/) ou num sistema remoto (que atua
como um servidor de registros dedicado para múltiplos computadores.)
Os sistemas de detecção de intrusão (IDS) são ferramentas poderosas para qualquer administrador de
sistemas Red Hat Enterprise Linux. Um IDS possibilita que administradores de sistemas determinem
se foram feitas alterações não-autorizadas em um ou mais sistemas. O design do próprio sistema
operacional inclui uma funcionalidade igual à do IDS.
Como o Red Hat Enterprise Linux é instalado usando o Administrador de Pacotes RPM (RPM), é
possível usá-lo para verificar se foram feitas alterações nos pacotes que constituem o sistema opera-
cional. No entanto, como o RPM é essencialmente uma ferramenta de administração de pacotes, suas
habilidades como um IDS são de certa forma limitadas. Mesmo assim, pode ser um bom primeiro
passo para monitorar um sistema Red Hat Enterprise Linux e verificar modificações não-autorizadas.
Capítulo 1. A Filosofia da Administração de Sistemas 11

1.11. Recursos Adicionais


Esta seção inclui diversos recursos que podem ser usados para aprender mais sobre a filosofia da
administração de sistemas e sua relação específica com o Red Hat Enterprise Linux.

1.11.1. Documentação Instalada


Os recursos a seguir são instalados no decorrrer de uma instalação típica do Red Hat Enterprise Linux
e podem ajudá-lo a aprender mais sobre o assunto abordado neste capítulo.

• Páginas man crontab(1) e crontab(5) — Aprenda como agendar comandos e scripts para
execução automática em intervalos regulares.
• Página man at(1) — Aprenda a agendar comandos e scripts para execução posterior.
• Página man bash(1) — Aprenda mais sobre a janela de comandos (shell) default e como escrever
scripts nesta.
• Página man perl(1) — Indicações de diversos sites que compoem a documentação online do perl.
• Página man python(1) — Aprenda mais sobre as opções, arquivos e variáveis de ambiente que
controlam o interpretador Python.
• Página man gedit(1) e item Help do menu — Aprenda a editar arquivos-texto com este editor de
texto gráfico.
• Página man emacs(1) — Aprenda mais sobre este editor de texto altamente flexível, inclusive
como rodar seu tutorial online.
• Página 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.
• Página man evolution(1) e item Help do menu — Aprenda a administrar seus e-mails com
cliente gráfico de e-mail.
• Página man mutt(1) e arquivos em /usr/share/doc/mutt- versão
istrar seus e-mails com este cliente de e-mail baseado em texto.
  — Aprenda a admin-

• Página man pam(8) e arquivos em /usr/share/doc/pam- versão


ciona a autenticação sob o Red Hat Enterprise Linux.
  — Aprenda como fun-

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 organização profissional dedicada a re-
unir profissionais da computação de todos os tipos, fomentando a melhoria da comunicação e ino-
vação.
• http://www.sage.org/ — A homepage da Associação dos Administradores de Sistemas (System
Administrators Guild). Um grupo técnico especial da USENIX que representa um bom recurso
para todos os administradores responsáveis 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 começar 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.
12 Capítulo 1. A Filosofia da Administração de Sistemas

1.11.3. Livros Relacionados


A maioria dos livros sobre administração de sistemas não aborda a questão filosófica por trás do
trabalho. Entretanto, os livros a seguir têm seções que trazem um pouco mais de profundidade às
questões aqui abordadas:

• O Guia de Referência do Red Hat Enterprise Linux; Red Hat, Inc. — Provém uma visão geral das
localidades de arquivos de sistema importantes, configurações de usuário e grupo e configuração
do PAM.
• O Guia de Segurança do Red Hat Enterprise Linux; Red Hat, Inc. — Contém uma discussão detal-
hada sobre diversas questões relacionadas à segurança para administradores de sistemas Red Hat
Enterprise Linux.
• O Guia de Administração de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. — Inclui capítulos
sobre a administração de usuários e grupos, automação de tarefas e administração de arquivos de
registro (log files).
• Linux Administration Handbook de Evi Nemeth, Garth Snyder e Trent R. Hein; Prentice Hall —
Provém uma boa seção sobre as normas e o lado político da administração de sistemas, incluindo
diversas discussões hipotéticas sobre ética.
• Linux System Administration: A User’s Guide de Marcel Gagne; Addison Wesley Professional —
Contém um capítulo sobre a automação de diversas tarefas.
• Solaris System Management de John Philcox; New Riders Publishing — Apesar de não ser escrito
especificamente para o Red Hat Enterprise Linux (nem mesmo para o Linux em geral) e usar o
termo "gerente de sistemas" ao invés de "administrador de sistemas", este livro traz uma visão geral
de 70 páginas sobre as diversas funções exercidas pelo administrador de sistemas numa empresa.
Capítulo 2.
Monitoramento de Recursos
Como mencionado anteriormente, grande parte dos administradores de sistemas conta com os recursos
e seu uso eficiente. Ao balancear vários recursos através dos indivíduos e programas que os utilizam,
você desperdiça menos dinheiro e deixa seus usuários contentes. No entanto, isto traz duas questões:
O que são recursos?
e:
Como é possível saber quais recursos são utilizados (e o quanto deles é utilizado)?
O propósito desse capítulo é capacitá-lo a responder estas questões ajudando-o a apender mais sobre
os recursos e seu monitoramento.

2.1. Conceitos Básicos


Antes de monitorar os recursos, você deve saber quais os recursos existentes para monitorar. Todos os
sistemas têm os seguintes recursos disponíveis:

• Energia da CPU
• Largura de banda (bandwidth)
• Memória
• Armazenamento
Estes recursos são cobertos em mais detalhes nos capítulos seguintes. No entanto, tudo o que você
precisa ter em mente por enquanto é que estes recursos têm um impacto direto no desempenho do
sistema e, consequentemente, na produtividade e bem-estar de seus usuários.
Simplisticamente, o monitoramento de recursos é nada mais que a obtenção de informações sobre a
utilização de um ou mais recursos do sistema.
Entretanto, raramente é tão simples. Primeiramente, deve-se considerar os recursos a serem moni-
torados. Então, é necessário examinar cada sistema a ser monitorado, prestando atenção especial à
situação de cada um deles.
Os sistemas que você monitorará estão 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 significa 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 próprios requerimentos únicos, as seções seguintes exploram cada
categoria em maior profundidade.
14 Capítulo 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) não rodam de jeito nenhum. Em ambos os casos, o monitoramento do
desempenho é normalmente feito como o primeiro e último passos de um processo de três etapas:

1. Monitorar para identificar a natureza e escopo da redução de recursos que causam os problemas
de desempenho
2. Os dados obtidos através do monitoramento são analisados e é tomada uma sequência de ações
(normalmente, o ajuste de desempenho e/ou a aquisição 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 duração 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 fim de atingir o melhor desepenho possível do sistema. A
principal razão disso é que os recursos do sistema e sua utilização tendem ser altamente relaciona-
dos, ou seja, a eliminação 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 mudança na utilização dos recursos do sistema. Uma vez conhecidas estas taxas de mudança,
é possível conduzir um planejamento mais preciso a longo prazo em relação à compra de recursos
adicionais.
O monitoramento da capacidade com o propósito de planejamento é diferente do monitoramento do
desempenho de duas maneiras:

• O monitoramento é feito quase continuamente


• O monitoramento geralmente não é tão detalhado
A razão destas diferenças baseia-se nos objetivos de um programa de planejamento da capacidade. O
planejamento da capacidade requer um ponto de vista "macro"; o uso anômalo ou de curto prazo dos
recursos tem pouca importância. Ao invés, os dados são coletados ao longo de um período, possibili-
tando classificar a utilização dos recursos em termos de alterações da carga de trabalho. Em ambientes
mais restritos (onde somente roda uma aplicação, por exemplo), é possível modelar o impacto da apli-
cação nos recursos do sistema. Isto pode ser feito com precisão suficiente para poder determinar, por
exemplo, o impacto da adição de cinco funcionários de atendimento ao cliente rodando a aplicação de
CRM durante o período mais intenso (ocupado) do dia.
Capítulo 2. Monitoramento de Recursos 15

2.4. O Que Monitorar?


Conforme dito antes, os recursos presentes em todos os sistemas são energia da CPU, largura de
banda, memória e armazenamento. À primeira vista, pode parecer que o monitoramento consistiria
apenas da avaliação destes quatro fatores distintos.
Infelizmente, não é tão simples. Por exemplo: considere um drive de disco. Quais as coisas que você
gostaria de saber sobre seu desempenho?

• Quanto há de espaço livre?


• Quantas operações I/O por segundo executa em média?
• Quanto tempo leva para completar cada operação I/O em média?
• Quantas destas operações I/O são acessos (reads)? Quantas são gravações (writes)?
• Qual a quantidade média de dados acessados/gravados em cada I/O?
Há outras maneiras de estudar o desempenho do drive de disco; estes pontos apenas abrangem a
superfície. O conceito principal é ter em mente que há muitos tipos diferentes de dados para cada
recurso.
As seções seguintes exploram os tipos de utilização das informações ú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 utilização da CPU
atinge, em algum momento, 100%. Se a utilização da CPU traz algo abaixo de 100%, não importa o
que o sistema está fazendo, há energia de processamento disponível para mais carga de trabalho.
Entretanto, é raro um sistema que não atinge 100% de utilização da CPU em pelo menos parte do
tempo. Neste ponto é importante examinar os dados de utilização mais detalhadamente. Ao fazer
isso, é possível começar a determinar onde a maioria da sua energia de processamento está sendo
consumida. Aqui estão algumas das estatísticas mais comuns de utilização da CPU:

Usuários Versus Sistema


A porcentagem de tempo gasto com o processamento a nível de usuário versus o processamento
a nível do sistema pode indicar se a carga de um sistema deve-se à execução de aplicações ou à
sobrecarga do sistema operacional. As altas porcentagens a nível de usuário tendem a ser boas
(assumindo que os usuários tenham desempenho satisfatório), enquanto as altas porcentagens a
nível de sistema tendem a indicar problemas que requerem uma investigação mais profunda.

Mudanças de Contexto
Uma mudança de contexto ocorre quando a CPU para de rodar um processo e começa a rodar
outro. Como cada mudança de contexto requer que o sistema operacional tome o controle da
CPU, mudanças de contexto excessivas e altos níveis de consumo da CPU a nível de sistema
tendem a caminhar juntos.

Interrupções
Como o nome implica, as interrupções são situações nas quais o processo desempenhado pela
CPU é alterado abruptamente. As interrupções geralmente ocorrem devido a atividade do hard-
ware (como um dispositivo I/O completando uma operação I/O) ou devido a software (como
interrupções do software que controla o processamento da aplicação). Como as interrupções de-
vem ser resolvidas a nível do sistema, altas taxas de interrupção levam a um consumo maior da
CPU a nível do sistema.
16 Capítulo 2. Monitoramento de Recursos

Processos Executáveis (runnable)


Um processo pode estar em estados diferentes, como:
• Aguardando a finalização de uma operação I/O
• Aguardando o sub-sistema de administração da memória resolver uma falha de página
Nestes casos, o processo não precisa da CPU.
No entanto, o processo sofre mudanças eventualmente e torna-se executável. Como o nome im-
plica, um processo executável é capaz de executar o trabalho assim que estiver agendado para
receber tempo da CPU. Entretanto, se mais de um processo for executável numa determinada
hora, todos os processos executáveis menos um1 devem esperar pela sua vez na CPU. Ao moni-
torar o número de processos executáveis, é possível determinar o quanto seu sistema depende da
CPU.
Outras medidas de desempenho que refletem um impacto na utilização da CPU tendem a incluir
serviços diferentes que o sistema operacional oferece aos processos. Podem incluir estatísticas da ad-
ministração da memória, do processamento I/O e assim por diante. Estas estatísticas também revelam
que, quando o desempenho do sistema é monitorado, não há limites entre as estatísiticas diferentes.
Em outras palavras: as estatísticas de utilização da CPU podem terminar apontando para um problema
no sub-sistema I/O ou as estatísticas de utilização da memória podem revelar uma falha no design da
aplicação.
Consequentemente, ao monitorar o desempenho do sistema, não é possível examinar nenhuma es-
tatística isoladamente; só é possível extrair informações significativas ao examinar o quadro geral de
quaisquer estatísticas que você coletar.

2.4.2. Monitorando a Largura de Banda


Monitorar a largura de banda é mais difícil que monitorar outros recursos aqui descritos. A razão disso
deve-se ao fato que as estatísticas de desempenho geralmente baseiam-se nos dispositivos, enquanto
a maioria dos lugares onde a largura de banda é importante são os canais que conectam dispositivos.
Nestes casos, onde mais de um dispositivo compartilha um canal em comum, você deve observar
estatísticas razoáveis para cada dispositivo, mas a carga agregada imposta por estes dispositivos no
canal seria bem maior.
Um outro desafio ao monitorar a largura de banda: pode haver circunstâncias nas quais as estatísticas
dos dispositivos podem não estar disponíveis. Isto é particularmente verdadeiro para canais de expan-
são do sistema e caminhos de dados2. No entanto, mesmo que as estatísticas relacionadas à largura de
banda não estejam 100% corretas, frequentemente há informações necessárias para possibilitar algum
nível de análise, particularmente ao considerar as estatísticas relacionadas.
Estas são algumas das estatísticas mais comuns relacionadas à largura de banda:

Bytes recebidos/enviados
As estatísticas da interface de rede oferecem um indicador da utilização da largura de banda de
um dos canais mais visíveis — a rede.

Contagens e taxas da interface


Estas estatísticas relacionadas à rede podem indicar colisões excessivas, transmitir e receber
erros, entre outros. Através do uso destas estatísticas (particularmente, se houver estatísticas
para mais de um sistema em sua rede), é possível solucionar um mínimo de problemas de rede,
mesmo antes de usar as ferramentas de diagnóstico de rede mais comuns.

1. Assumindo um sistema com processador único.


2. Mais informações sobre canais, caminhos de dados e largura de banda podem ser encontradas no Capítulo 3.
Capítulo 2. Monitoramento de Recursos 17

Transferências por Segundo


Normalmente coletada para dispositivos I/O de bloco, como drives de fita de alto desempenho
e drives de disco, esta estatística é uma boa maneira de determinar se a largura de banda de um
determinado dispositivo atingiu seu limite. Devido sua natureza eletromecânica, os drives de fita
e de disco podem executar somente um determinado número de operações I/O a cada segundo;
seu desempenho decai rapidamente quando esse limite é atingido.

2.4.3. Monitorando a Memória


Se existe alguma área onde podemos encontrar uma riqueza de estatísticas de desempenho, essa área
é o monitoramento da utilização da memória. Devido à complexidade inerente dos sistemas opera-
cionais com memória virtual paginada por demanda, as estatísticas de utilização da memória são
muitas e variadas. É aqui que reside a maioria do trabalho do administrador de sistemas com a admin-
istração dos recursos.
Os dados seguintes representam uma visão geral superficial das estatísticas comumente encontradas
sobre a administração da memória:

Páginas Dentro/Páginas Fora (Page Ins/Page Outs)


Estas estatísticas possibilitam medir o fluxo de páginas da memória do sistema para os dispos-
itivos de armazenamento em massa anexos (geralmente drives de disco). Taxas altas de ambas
estatísticas podem significar que o sistema tem pouca memória física e está com thrashing, ou
seja, gastando mais recursos do sistema para mover páginas para dentro e para fora da memória
que para rodar aplicações.

Páginas Ativas/Inativas (Active/Inactive Pages)


Estes dados mostram como são usadas as páginas altamente residentes na memória. Uma falta
de páginas inativas pode indicar a falta de memória física.

Páginas Livres, Compartilhadas, no Buffer e no Cache (Free, Shared, Buffered, and Cached Pages)
Estes dados oferecem detalhes adicionais sobre as estatísticas de páginas inativas/ativas mais sim-
plistas. Ao usar estas estatísticas, é possível determinar a mistura geral da utilização da memória.

Swap Dentro/Swap Fora (Swap Ins/Swap Outs)


Estes dados mostram o comportamento da memória swap do sistema. Altas taxas podem indicar
a falta de memória física.
O bom monitoramento da utilização da memória requer um bom entendimento de como funcionam os
sistemas operacionais com memória virtual paginada por demanda. Apesar do assunto isoladamente
poder ocupar um livro inteiro, seus conceitos básicos estão abordados no Capítulo 4. Este capítulo,
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 níveis diferentes:

• Monitoramento de espaço suficiente em disco


• Monitoramento de problemas de desempenho relacionados ao armazenamento
A razão disto: é possível ter problemas sérios em uma área e nenhum problema em outra. Por exemplo:
é possível fazer com que um drive de disco esgote seu espaço sem causar nenhum tipo de problema
18 Capítulo 2. Monitoramento de Recursos

relacionado ao desempenho. Da mesma forma, é possível ter um drive de disco com 99% de espaço
livre com seus limites de desempemnho sendo forçados.
Entretanto, é mais provável que o sistema mediano experimente vários graus de falta de recursos em
ambas áreas. Por causa disso, também é provável que — até certo ponto — os problemas de uma
área impactem noutra área. Frequentemente, esse tipo de interação toma a forma de desempenho I/O
descendente, conforme o drive de disco se aproxima de 0% de espaço livre; não obstante, nos casos
de cargas I/O extremas, pode ser possível diminuir I/O para um nível no qual as aplicações não mais
rodam apropriadamente.
Em qualquer caso, as estatísticas a seguir são úteis para monitorar o armazenamento:

Espaço Livre (Free Space)


Espaço livre é provavelmente o recurso que todos os administradores de sistemas monitoram de
perto; seria raro um administrador de sistemas que nunca verifica o espaço livre (ou que não
tenha uma maneira automatizada de fazê-lo).

Estatísticas Relaciondas ao Sistema de Arquivo


Estas estatísticas (como número de arquivos/diretórios, tamanho médio de arquivo, etc) oferecem
detalhes adicionais sobre a simples porcentagem de espaço livre. Como tais, estas estatísticas
possibilitam aos administradores configurar o sistema para o melhor desempenho, já que a carga
I/O imposta por um sistema de arquivo com muitos arquivos pequenos não é a mesma que àquela
imposta por um sistema de arquivo com um único arquivo enorme.

Transferências por Segundo


Esta estatística é uma boa maneira de determinar se os limites de largura de banda de um deter-
minado dispositivo foram atingidos.

Acessos/Gravações por Segundo (Reads/Writes per Second)


Uma análise um pouco mais detalhada das transferências por segundo, estas estatísticas permitem
ao administrador de sistemas entender melhor a natureza das cargas I/O experimentadas por um
dispositivo de armazenamento. Isto pode ser crítico já que algumas tecnologias de armazena-
mento têm características de desempenho bem diferentes para operações de acesso (read) e para
operações de gravação (write).

2.5. Informações Específicas do Red Hat Enterprise Linux


O Red Hat Enterprise Linux traz diversas ferramentas de monitoramento dos recursos. Apesar de
existir mais ferramentas que as listadas aqui, essas são as mais representativas em termos de fun-
cionalidade:

• free
• top (e Monitor GNOME do Sistema, uma versão mais gráfica do top)
• vmstat

• O pacote Sysstat de ferramentas de monitoramento dos recursos


• O perfilador do sistema OProfile
Vamos examinar cada um mais detalhadamente.
Capítulo 2. Monitoramento de Recursos 19

2.5.1. free
O comando free apresenta a utilização da memória do sistema. Aqui está um exemplo de seu output:

total used free shared buffers cached


Mem: 255508 240268 15240 0 7592 86188
-/+ buffers/cache: 146488 109020
Swap: 530136 26268 503868

A linha Mem: apresenta a utilização da memória física, enquanto a linha Swap: apresenta a utilização
do espaço swap do sistema, e a linha -/+ buffers/cache: traz a quantidade de memória física
corrente dedicada aos buffers do sistema.
Como o free apresenta as informações de utilização da memória uma só vez por default, é útil
somente para monitoramento de curto prazo, ou para determinar rapidamente se um problema relativo
à memória está ocorrendo no momento. Apesar do free ter a habilidade de apresentar a utilização da
memória repetidamente através de sua opção -s, seu output se estende ao longo da tela, dificultando
detectar as alterações na utilização da memória.

Dica
Uma solução melhor que o uso do free -s seria executar o free usando o comando watch. Por
exemplo: para trazer a utilização da memória 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 alterações na utilização da memória
ao longo do tempo, já que o watch cria uma única visualização atualizada sem scrolling. Você pode
controlar o intervalo entre as atualizações usando a opção -n e fazer com que quaisquer alterações
entre as atualizações sejam destacadas, usando a opção -d, conforme o comando seguinte:

watch -n 1 -d free

Para mais informações , consulte a página 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 situações.

2.5.2. top
Enquanto o free apresenta somente informações relativas à memória, o comando top faz um pouco
de tudo. A utilização da CPU, as estatísticas de processo, a utilização da memória — o top monitora
tudo. Além disso, ao contrário do comando free, o comportamento defalut do top é rodar continua-
mente; não 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 Capítulo 2. Monitoramento de Recursos

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
17578 root 15 0 13456 13M 9020 S 18.5 1.3 26:35 1 rhn-applet-gu
19154 root 20 0 1176 1176 892 R 0.9 0.1 0:00 1 top
1 root 15 0 168 160 108 S 0.0 0.0 0:09 0 init
2 root RT 0 0 0 0 SW 0.0 0.0 0:00 0 migration/0
3 root RT 0 0 0 0 SW 0.0 0.0 0:00 1 migration/1
4 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 keventd
5 root 34 19 0 0 0 SWN 0.0 0.0 0:00 0 ksoftirqd/0
6 root 35 19 0 0 0 SWN 0.0 0.0 0:00 1 ksoftirqd/1
9 root 15 0 0 0 0 SW 0.0 0.0 0:07 1 bdflush
7 root 15 0 0 0 0 SW 0.0 0.0 1:19 0 kswapd
8 root 15 0 0 0 0 SW 0.0 0.0 0:14 1 kscand
10 root 15 0 0 0 0 SW 0.0 0.0 0:03 1 kupdated
11 root 25 0 0 0 0 SW 0.0 0.0 0:00 0 mdrecoveryd

O resultado é dividido em duas seções. A seção superior contém informações relativas ao estado
geral do sistema — tempo ligado (uptime), carga média, contagens de processos, estado da CPU e
estatísticas de utilização da memória e do espaço swap. A seção inferior apresenta estatísticas no
nível do processo. É possível alterar a exibição 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 exibição default.

Aviso
Apesar do top aparecer como um simples programa de apresentação, este não é o caso. Isso ocorre
porque o top usa comandos de caractere simples para executar várias operações. Por exemplo: se
você está autenticado como root, é possível 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 gráfico


Se você prefere utilizar interfaces gráficas de usuário, o Monitor GNOME do Sistema pode ser a
sua escolha. Como o top, o Monitor GNOME do Sistema apresenta as informações relacionadas ao
estado geral do sistema, contagens de processos, utilização da memória e swap e também estatísticas
a nível de processo.
No entanto, o Monitor GNOME do Sistema vai um passo além, incluindo também representações
gráficas da utilização da CPU, da memória e de swap, juntamente a uma listagem da utilização do es-
paço em disco em forma de tabela. Veja um exemplo da Listagem de Processos do Monitor GNOME
do Sistema na Figura 2-1.
Capítulo 2. Monitoramento de Recursos 21

Figura 2-1. A Apresentação da Listagem de Processos do Monitor GNOME do Sistema

É possível apresentar informações adicionais para processos específicos; primeiro clique no processo
desejado e então clique no botão Mais Informações (More Info).
Para apresentar as estatísticas da CPU, memória 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, é
possível obter uma visão geral dos processos, memória, swap, I/O, sistema e das atividades da CPU
numa linha de números:

procs memory swap io system cpu


r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 5276 315000 130744 380184 1 1 2 24 14 50 1 1 47 0
22 Capítulo 2. Monitoramento de Recursos

A primeira linha divide os campos em seis categorias, incluindo estatísticas do processo, da memória,
swap, I/O, do sistema e da CPU. A segunda linha identifica o conteúdo de cada campo, facilitando a
busca de dados para estatísticas específicas.
Os campos relativos ao processo são:

• r — O número de processos executáveis (runnable processes) aguardando para acessar a CPU


• b — O número de processos num estado de dormência contínua
Os campos relativos à memória são:

• swpd — A quantidade de memória virtual usada


• free — A quantidade de memória livre
• buff — A quantidade de memória usada para buffers
• cache — A quantidade de memória usada para cache
Os campos relativos à swap são:

• si — A quantidade de memória enviada para swap pelo disco


• so — A quantidade de memória retirada de swap para o disco
Os campos relativos a I/O são:

• bi — Blocos enviados a um dispositivo de bloco


• bo — Blocos recebidos de um dispositivo de bloco
Os campos relativos ao sistema são:

• in — O número de interrupções por segundo


• cs — O número de mudanças de contexto por segundo
Os campos relativos à CPU são:

• us — A porcentagem de tempo em que a CPU rodou código a nível do usuário


• sy — A porcentagem de tempo em que a CPU rodou código a nível do sistema
• id — A porcentagem de tempo em que a CPU estava osciosa
• wa — espera das I/O
Quando o vmstat é executado sem nenhuma opção, apresenta somente uma linha. Essa linha contém
médias, calculadas desde a hora em que o sistema foi inicializado pela última vez.
Entretanto, a maioria dos administradores de sistema não confia nas informações dessa linha, já que
varia o tempo ao longo do qual foram coletadas. Ao invés disso, a maioria dos administradores
aproveita a habilidade do vmstat em apresentar repetidamente os dados de utilização dos recur-
sos em intervalos determinados. Por exemplo: o comando vmstat 1 apresenta uma nova linha com
informações de utilização a cada segundo, enquanto o comando vmstat 1 10 apresenta uma nova
linha por segundo, mas apenas nos próximos dez segundos.
Nas mãos de um administrador experiente, o vmstat pode ser usado para determinar rapidamente as
questões de desempenho e utilização de recursos. Mas, para ter mais conhecimento destas questões, é
necessário usar um tipo diferente de ferramenta — uma ferramenta capaz de coletar e analisar dados
mais profundos.
Capítulo 2. Monitoramento de Recursos 23

2.5.4. O Pacote Sysstat de Ferramentas de Monitoramento dos Recursos


Enquanto as ferramentas anteriores são úteis para obter mais conhecimento sobre o desempenho do
sistema ao longo de períodos de tempo curtos, têm pouco uso além de prover uma rápida visualização
da utilização dos recursos. Além disso, há aspectos do desempenho do sistema que não podem ser
facilmente monintorados com ferramentas simplistas como estas.
Sendo assim, é necessário uma ferramenta mais sofisticada. Sysstat é essa ferramenta.
Sysstat contém as seguintes ferramentas relacionadas à obtenção de estatísticas de I/O e CPU:

iostat
Apresenta uma visão geral da utilização da CPU, junto às estatísticas de I/O de um ou mais drives
de disco.

mpstat
Apresenta estatísticas mais profundas da CPU.
Sysstat também contém ferramentas que coletam dados de utilização dos recursos do sistema e criam
relatórios diários baseados nestes dados. Estas ferramentas são:

sadc
Conhecido como o coletor de dados de atividade do sistema, o sadc coleta informações da
utilização dos recursos do sistema e as grava num arquivo.

sar
Os relatórios do sar são criados a partir de arquivos do sadc, e podem ser gerados interativa-
mente ou gravados num arquivo para uma análise mais intensa.
As seções seguintes exploram cada uma destas ferramentas mais detalhadamente.

2.5.4.1. O comando iostat


O comando iostat, em sua forma mais básica, oferece uma visão geral das estatísticas da CPU e
operações I/O do disco:

Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 07/11/2003

avg-cpu: %user %nice %sys %idle


6.11 2.56 2.15 89.18

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn


dev3-0 1.68 15.69 22.42 31175836 44543290

Abaixo da primeira linha (que contém a versão do kernel do sistema e o nome da máquina, junto à
data corrente), o iostat apresenta uma visão geral da utilização média da CPU do sistema desde a
última inicialização. O relatório de utilização da CPU inclui as seguintes porcentagens:

• Porcentagem do tempo gasto no modo usuário (rodando aplicações, etc)


• Porcentagem do tempo gasto no modo usuário (para processos que alteraram suas prioridades de
agendamento usando o nice(2))
• Porcentagem do tempo gasto no modo kernel
• Porcentagem do tempo inativo
24 Capítulo 2. Monitoramento de Recursos

O relatório de utilização do dispositivo está abaixo do relatório de utilização da CPU. Este relatório
contém uma linha para cada dispositivo de disco ativo no sistema e inclui as seguintes informações:

• A
 especificação
 do
dev maior-número -número-sequencial,

dispositivo
onde
é o maior número do dispositivo3 e número-sequencial
é

 
apresentada como
maior-número
é um número sequencial

começando por zero.
• O número de transferências (ou operações I/O) por segundo.
• O número de blocos de 512 bytes acessados por segundo.
• O número de blocos de 512 bytes gravados por segundo.
• O número total de blocos de 512 bytes acessados.
• O número total de blocos de 512 bytes gravados.
Esta é apneas uma amostra das informações que podem ser obtidas usando o iostat. Para mais
informações, consulte a página man iostat(1).

2.5.4.2. O comando mpstat


À primeira vista, o comando mpstat não parece ser diferente do relatório de utilização da CPU
produzido pelo iostat:

Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 07/11/2003

07:09:26 PM CPU %user %nice %system %idle intr/s


07:09:26 PM all 6.40 5.84 3.29 84.47 542.47

Além da coluna adicional com as interrupções por segundo resolvidas pela CPU, não há diferença
real. No entanto, a situação muda se a opção -P ALL do mpstat for usada:

Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 07/11/2003

07:13:03 PM CPU %user %nice %system %idle intr/s


07:13:03 PM all 6.40 5.84 3.29 84.47 542.47
07:13:03 PM 0 6.36 5.80 3.29 84.54 542.47
07:13:03 PM 1 6.43 5.87 3.29 84.40 542.47

Em sistemas com multi-processadores, o mpstat permite exibir a utilização de cada CPU separada-
mente, possibilitando determinar o quão efetivamente cada CPU é usada.

2.5.4.3. O comando sadc


Conforme mencionado anteriormente, o comando sadc coleta dados de utilização do sistema e os

   
grava num arquivo para análise posterior. Por default, os dados são gravados em arquivos no diretório
/var/log/sa/. Os arquivos são nomeados como sa dd , onde dd é a data do dia corrente em
dois dígitos.
O sadc é normalmente executado pelo script do sa1. Esse script é periodicamente invocado pelo
cron através do arquivo sysstat, localizado em /etc/cron.d/. O script sa1 invoca o sadc para

3. Os números maiores do dispositivos podem ser obtidos usando ls -l para exibir o arquivo do dispositivo
desejado em /dev/. O maior número aparece após a especificação do grupo do dispositivo.
Capítulo 2. Monitoramento de Recursos 25


um único intervalo de medição 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 relatórios de utilização do sistema baseados nos dados coletados pelo sadc.
Conforme configurado no Red Hat Enterprise Linux, o sar é automaticamente executado para pro-

 
cessar os arquivos automaticamente coletados pelo sadc. Os arquivos de relatórios são gravados em
/var/log/sa/ e são nomeados como sar dd , onde dd é a representação de dois dígitos da
data do dia anterior.
O sar é normalmente executado pelo script do sa2. Esse script é periodicamente invocado pelo cron
através 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 relatório com os dados do dia todo.

2.5.4.4.1. Acessando Relatórios do sar


O formato de um relatório do sar produzido pela configuração default do Red Hat Enterprise Linux
consiste de seções múltiplas, e cada seção contém um tipo de dado específico, ordenado pela hora do
dia em que o dado foi coletado. Como o sadc é configurado para efetuar um intervalo de medição de
um segundo a cada dez minutos, o relatório default do sar contém dados em blocos de dez minutos,
de 00:00 a 23:504.
Cada seção do relatório inicia com um cabeçalho descrevendo os dados contidos na seção. O
cabeçalho é repetido em intervalos regulares ao longo da seção, facilitando interpretar os dados
enquanto navegamos no relatório. Cada seção termina com uma linha contendo a média dos dados
reportados na seção.
Veja um exemplo de seção do relatório do sar, com os dados de 00:30 a 23:40 removidos para
economizar espaço:

00:00:01 CPU %user %nice %system %idle


00:10:00 all 6.39 1.96 0.66 90.98
00:20:01 all 1.61 3.16 1.09 94.14
...
23:50:01 all 44.07 0.02 0.77 55.14
Average: all 5.80 4.99 2.87 86.34

Nesta seção são apresentadas as informações de utilização da CPU. Estas são bem similares às infor-
mações apresentadas pelo iostat.
Outras seções talvez tenham mais de uma linha de dados por vez, conforme exibido nesta seção gerada
a partir dos dados de utilização da CPU, coletados num sistema de processador duplo:

00:00:01 CPU %user %nice %system %idle


00:10:00 0 4.19 1.75 0.70 93.37
00:10:00 1 8.59 2.18 0.63 88.60
00:20:01 0 1.87 3.21 1.14 93.78
00:20:01 1 1.35 3.12 1.04 94.49
...
23:50:01 0 42.84 0.03 0.80 56.33
23:50:01 1 45.29 0.01 0.74 53.95
Average: 0 6.00 5.01 2.74 86.25
Average: 1 5.61 4.97 2.99 86.43

4. Devido à dinâmica das cargas de sistema, a hora real na qual os dados foram coletados pode variar em um
segundo ou dois.
26 Capítulo 2. Monitoramento de Recursos

Há um total de dezessete seções diferentes presentes nos relatórios gerados pela configuração default
do sar no Red Hat Enterprise Linux. Algumas destas seções são abordadas nos próximos capítulos.
Para mais informações sobre os dados contidos em cada seção, consulte a página man sar(1).

2.5.5. OProfile
O perfilador do sistema OProfile é uma ferramenta de monitoramento de baixa sobrecarga. O OProfile
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 próprio processador. Tem a forma de um
contador especial, aumentando cada vez que um determinado evento (como o processador estar ativo
ou os dados desejados não serem enviados ao cache) ocorre. Alguns processadores tem mais de um
contador como esse, e permitem a seleção de tipos de eventos diferentes para cada contador.
Os contadores podem ser carregados com um valor inicial e produzir uma interrupção sempre que
o contador ultrapassar o limite. Ao carregar um contador com valores iniciais diferentes, é possível
variar a taxa de produção de interrupções. Dessa maneira, é possível controlar a taxa de controle e,
consequentemente, o nível de detalhe obtido através dos dados coletados.
Em um extremo, ajustar o contador para gerar uma interrupção 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 número de interrupções possível, oferece apenas uma
visão genérica do desempenho do sistema (com praticamente nenhuma sobrecarga). O segredo do
monitoramento efetivo é a seleção de uma taxa limite suficientemente alta para capturar os dados
necessários, mas não tão alta a ponto de sobrecarregar o sistema com a sobrecarga de monitoramento
do desempenho.

Aviso
Você poode configurar o OProfile para produzir sobrecarga suficiente a fim de tornar o sistema
inutilizável. Consequentemente, você deve tomar cuidado ao selecionar os valores limite. Por este
motivo, o comando opcontrol suporta a opção --list-events, que apresenta os tipos de evento
disponíveis para o processador instalado, junto a valores limite mínimos sugeridos para cada evento.

É importante ter em mente a dificuldade de equilíbrio entre a taxa limite e a sobrecarga ao usar o
OProfile.

2.5.5.1. Componentes do OProfile


O Oprofile consiste dos seguintes componentes:

• Software de coleta de dados


• Software de análise de dados
• Software de interface administrativa
O software de coleta de dados consiste do módulo oprofile.o do kernel e do daemon oprofiled.
O software de análise de dados inclui os seguintes programas:

5. O OProfile também pode usar um mecanismo de fallback (conhecido como TIMER_INT) para aquelas
arquiteturas de sistema que não têm hardware de monitoramento do desempenho.
Capítulo 2. Monitoramento de Recursos 27

op_time
Exibe o número e porcentagens relativas de amostras obtidas para cada arquivo executável

oprofpp
Exibe o número e porcentagem relativa obtida pela instrução individual ou pelo output no estilo
do gprof.

op_to_source
Exibe o código fonte comentado e/ou as listagens de código do assembly

op_visualise
Exibe graficamente 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 especificação
dos eventos a serem monitorados ao início e parada da própria coleta. Isso é feito usando o comando
opcontrol.

2.5.5.2. Uma Amostra de Sessão do OProfile


Esta amostra exibe uma sessão de monitoramento e análise de dados da configuração inicial à análise
de dados final. É apenas uma visão geral introdutória; para mais informações, consulte o Guia de
Administração de Sistemas Red Hat Enterprise Linux.
Use o opcontrol para configurar 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 opções usadas aqui direcionam o opcontrol para:

• Direcionar o OProfile para uma cópia do kernel rodando no momento


(--vmlinux=/boot/vmlinux-‘uname -r‘)
• Especificar que o contador 0 do processador deve ser usado e que o evento a ser monitorado é o
tempo em que a CPU está executando instruções (--ctr0-event=CPU_CLK_UNHALTED)
• Especificar que o OProfile deve coletar amostras a cada 6000 vezes que o evento especificado
ocorrer (--ctr0-count=6000)
Em seguida, verifique se o módulo oprofile do kernel está carregado usando o comando lsmod:

Module Size Used by Not tainted


oprofile 75616 1
...

Confirme se o sistema de arquivo do OProfile (localizado em /dev/oprofile/) está montado com


o comando ls /dev/oprofile/:

0 buffer buffer_watershed cpu_type enable stats


1 buffer_size cpu_buffer_size dump kernel_only

(O número exato de arquivos varia de acordo com o tipo de processador.)


28 Capítulo 2. Monitoramento de Recursos

Neste ponto, o arquivo /root/.oprofile/daemonrc contém os ajustes necessários 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 ? S 0:00 /usr/bin/oprofiled --separate-lib-samples=0 ...


32021 pts/0 S 0:00 grep -i oprofiled

(A linha de comando oprofiled apresentada pelo ps é bem mais longa; no entanto, foi truncada
aqui por motivos de formatação.)
Agora o sistema está sendo monitorado, com coleta de dados para todos os executáveis presentes
no sistema. Os dados são armazenados no diretório /var/lib/oprofile/samples/. Os arquivos
desse diretório seguem uma convenção de nomes fora do comum. Aqui está um exemplo:

}usr}bin}less#0

A convenção de nomes usa a localidade absoluta de cada arquivo contendo código executável, com os
caracteres barra (/) substituídos por chaves finais (}), e terminando com um jogo da velha (#) seguido
por um número (0, neste caso.) Consequentemente, o arquivo usado neste exemplo representa os
dados coletados enquanto o /usr/bin/less estava rodando.
Após a coleta dos dados, use uma das ferramentas de análise para exibí-los. O OProfile tem a van-
tagem de não precisar parar a coleta de dados antes de executar a análise 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 forçar as amostras no disco.
No exemplo a seguir, o op_time é usado para exibir (em ordem inversa — do maior número de
amostras ao menor) as amostras que foram coletadas.

3321080 48.8021 0.0000 /boot/vmlinux-2.4.21-1.1931.2.349.2.2.entsmp


761776 11.1940 0.0000 /usr/bin/oprofiled
368933 5.4213 0.0000 /lib/tls/libc-2.3.2.so
293570 4.3139 0.0000 /usr/lib/libgobject-2.0.so.0.200.2
205231 3.0158 0.0000 /usr/lib/libgdk-x11-2.0.so.0.200.2
167575 2.4625 0.0000 /usr/lib/libglib-2.0.so.0.200.2
123095 1.8088 0.0000 /lib/libcrypto.so.0.9.7a
105677 1.5529 0.0000 /usr/X11R6/bin/XFree86
Capítulo 2. Monitoramento de Recursos 29

...

Usar less é uma boa idéia ao produzir um relatório interativamente, já que este pode ter centenas de
linhas. O exemplo ilustrado aqui foi truncado por este motivo.
O formato desse relatório específico consiste na produção de uma linha para cada arquivo executável
dos quais as amostras foram retiradas. Cada linha segue este formato:

sample-count
sample-percent
unused-field
executable-name
Onde:






sample-count
sample-percent
representa o número de amostras coletadas
representa a porcentagem de todas as amostras coletadas para esse exe-

cutável específico




campo-não-usado
executable-name
é um campo que não está usado
representa o nome do arquivo contendo código executável para o qual as
amostras foram coletadas.
Esse relatório (produzido num sistema inativo na maior parte do tempo) mostra que quase metade
das amostras foram coletadas enquanto a CPU estava rodando código dentro do próprio kernel. Em
seguida, na linha, está o dameon de coleta de dados do OProfile, seguido por diversas bibliotecas e
do servidor do Sistema X Window, o XFree86. Vale notar que, para o sistema rodar essa seção de
amostra, o valor de 6000 usado no contador representa o valor mínimo recomendado pelo opcontrol
--list-events. Isso significa que — pelo menos para este sistema em particular — a sobrecarga
do OProfile no seu ápice consome aproximadamente 11% da CPU.

2.6. Recursos Adicionais


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

2.6.1. Documentação Instalada


Os seguintes recursos são instalados no decorrer de uma instalação típica do Red Hat Enterprise Linux.

• Página man free(1) — Aprenda a exibir as estatísticas de memória livre e usada.


• Página man top(1) — Aprenda a exibir as estatísticas no nível de processo e de utilização da CPU.
• Página man watch(1) — Aprenda a executar periodicamente o programa especificado pelo
usuário, exibindo output na tela inteira.
• Entrada Help no menu do Monitor GNOME do Sistema — Aprenda a exibir graficamente as
estatísticas de processos, utilização da CPU, memória e de espaço em disco.
• Página man vmstat(8) — Aprenda a exibir uma visão geral concisa dos processos, memória,
swap, I/O, sistema e utilização da CPU.
• Página man iostat(1) — Aprenda a exibir as estatísticas da CPU e I/O.
• Página man mpstat(1) — Aprenda a exibir as estatísticas das CPUs separadamente em sistemas
multi-processadores.
• Página man sadc(8) — Aprenda a coletar dados de utilização do sistema.
• Página man sa1(8) — Aprenda sobre um script que roda o sadc periodicamente.
30 Capítulo 2. Monitoramento de Recursos

• Página man sar(1) — Aprenda como produzir relatórios de utilização dos recursos do sistema.
• Página man sa2(8) — Aprenda a produzir arquivos com relatórios diários de utilização dos recur-
sos do sistema.
• Página man nice(1) — Aprenda como alterar a prioridade de agendamento do processo.
• Página man oprofile(1) — Aprenda a traçar o perfil do desempenho do sistema.
• Página man op_visualise(1) — Aprenda a exibir graficamente os dados do OProfile.

2.6.2. Sites Úteis

• http://people.redhat.com/alikins/system_tuning.html — Informações de Ajuste do Sistema para


Servidores Linux. Uma tática conscienciosa para o ajuste do desempenho e monitoramento de
recursos em servidores.
• http://www.linuxjournal.com/article.php?sid=2396 — Ferramentas de Monitoramento do Desem-
penho para Linux. Mais direcionada ao administrador interessado em elaborar uma solução gráfica
de desempenho personalizada. Como foi escrita há muitos anos, alguns de seus detalhes talvez
estejam obsoletos, mas o conceito e execução gerais ainda funcionam.
• http://oprofile.sourceforge.net/ — O site do projeto OProfile. Inclui recursos valiosos do OProfile,
incluindo links para listas de discussão e para o canal IRC do #oprofile.

2.6.3. Livros Relacionados


Os livros seguintes abordam diversas questões relativas ao monitoramento de recursos e são boas
fontes para administradores de sistemas Red Hat Enterprise Linux:

• O Guia de Administração de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. — Inclui infor-
mações sobre muitas das ferramentas de monitoramento de recursos descritas aqui, incluindo o
OProfile.
• Linux Performance Tuning and Capacity Planning de Jason R. Fink e Matthew D. Sherer; Sams
— Oferece visões mais profundas das ferramentas de monitoramento de recursos aqui abordadas e
inclui outras que podem ser mais apropriadas para necessidades específicas de monitoramento de
recursos.
• Red Hat Linux Security and Optimization de Mohammed J. Kabir; Red Hat Press — Aproximada-
mente, as primeiras 150 páginas desse livro abordam questões relativas ao desempenho. Isso inclui
capítulos dedicados às questões de desempenho específicas 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 capítulo curto com escopo similar ao desse livro, mas inclui uma seção interessante
sobre o diagnóstico de um sistema que apresenta lentidão repentinamente.
• Linux System Administration: A User’s Guide de Marcel Gagne; Addison Wesley Professional —
Contém um pequeno capítulo sobre o monitoramento e ajuste do desemepenho.
Capítulo 3.
Largura de Banda e Poder de Processamento
Dentre os dois recursos abordados neste capítulo, um (largura de banda) é, frequentemente, de difícil
compreensão para administradores de sistemas, enquanto o outro (poder de processamento) é um
conceito geralmente fácil de entender.
Aparentemente, estes dois recursos não tem nenhuma relação próxima — por que juntá-los?
A razão para abordar ambos recursos conjuntamente é que os dois são baseados no hardware direta-
mente ligado à habilidade do computador em mover e processar dados. Sendo assim, suas funções são
frequentemente relacionadas.

3.1. Largura de Banda


Basicamente, largura de banda é a capacidade de transferência de dados — em outras palavras, a
quantidade de dados que pode ser movida de um ponto a outro num determinado período de tempo.
Ter comunicação ponto-a-ponto implica em duas coisas:

• Um conjunto de condutores elétricos usado para possiblitar a comunicação de nível baixo


• Um protocolo para facilitar a comunicação de dados eficiente e confiável
Há dois tipos de componentes de sistema que atendem estes requisitos:

• Canais (buses)
• Centrais de Dados (Datapaths)
As seções a seguir exploram cada um em detalhes.

3.1.1. Canais (buses)


Conforme explanado anteriormente, os canais possibilitam a comunicação ponto-a-ponto e utilizam
alguma espécie de protocolo para garantir que toda a comunicação ocorra de forma controlada. No
entanto, os canais têm outras características distintas:

• Características elétricas padronizadas (tais como número de condutores, níveis de voltagem, ve-
locidades de sinalização, etc.)
• Características mecânicas padronizadas (tais como tipo de conector, tamanho da placa, aparência
física, etc.)
• Protocolo padronizado
A palavra "padronizado" é importante porque os canais são a principal forma de conexão entre difer-
entes componentes do sistema.
Em muitos casos, os canais (buses) permitem interconectar hardware produzido por diversos fabri-
cantes; sem a padronização, isto não seria possível. No entanto, mesmo nas situações onde um canal
é de propriedade de um fabricante, a padronização possibilita que este fabricante implemente outros
componentes facilmente, usando uma interface comum — o próprio canal.
32 Capítulo 3. Largura de Banda e Poder de Processamento

3.1.1.1. Exemplos de Canais


Não importa o local do sistema em questão; sempre há canais. Aqui estão alguns dos canais mais
comuns:

• Canais de armazenamento em massa (ATA e SCSI)


• Redes1 (Ethernet e Token Ring)
• Canais de memória (PC133 e Rambus®)
• Canais de expansão (PCI, ISA, USB)

3.1.2. Centrais de Dados (Datapaths)


As centrais de dados (datapaths) podem ser mais difíceis de identificar, mas, assim como os canais,
elas estão em todo lugar. Como os canais, elas também possibilitam a comunicação ponto-a-ponto.
Entretanto, ao contrário dos canais, as centrais de dados:

• Usam um protocolo mais simples (se houver)


• Têm pouca (ou nenhuma) padronização mecânica
A razão destas diferenças é que as centrais de dados (datapaths) normalmente fazem parte de algum
componente do sistema e não são usadas para facilitar a interconexão improvisada de diferentes com-
ponentes. Como tais, as centrais de dados são altamente otimizadas para uma situação específica, na
qual a velocidade e o baixo custo têm prioridade sobre a lentidão e flexibilidade de componentes mais
caros.

3.1.2.1. Exemplos de Centrais de Dados (Datapaths)


Aqui estão algumas centrais de dados típicas:

• central de dados da CPU para cache no chip (CPU to on-chip cache datapath)
• Processador gráfico para a central de dados da memória de vídeo

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
níveis de contenção do canal reduzem a largura de banda efetivamente disponível 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 disponível para
qualquer outro dispositivo no mesmo canal. O resultado final é que todas as I/O de qualquer dis-
positivo neste canal são lentas, mesmo que cada dispositivo no canal não esteja sobrecarregado.
2. O canal ou central de dados (datapath) pode ser um recurso dedicado com um número fixo
de dispositivos anexos. Neste caso, as características elétricas do canal (e até certo ponto, a
natureza do protocolo utilizado) limitam a banda disponível. Este caso geralmente ocorre mais

1. Ao invés de um canal intra-sistema, as redes podem ser encaradas como um canal inter-sistema.
Capítulo 3. Largura de Banda e Poder de Processamento 33

frequentemente com centrais de dados que com canais. Esta é uma das razões pelas quais os
adaptadores gráficos tendem a operar mais lentamente com definição e resolução de cores mais
altas — para cada recarregamento da tela (refresh), há mais dados a serem passados através da
central de dados conectando a memória de vídeo e o processador gráfico.

3.1.4. Soluções Potenciais Relacionadas à Largura de Banda (Bandwidth)


Felizmente, os problemas relacionados à largura de banda podem ser solucionados. Na realidade, há
diversas táticas para isso:

• Distribuir a carga
• Reduzir a carga
• Aumentar a capacidade
As seções seguinites exploram cada uma das táticas detalhadamente.

3.1.4.1. Distribuir a Carga


A primeira tática é distribuir a atividade do canal de forma mais balanceada. Em outras palavras, se
um canal está sobrecarregado e um outro está ocioso, a situação pode ser melhorada ao mover parte
da carga para o canal ocioso.
Como administrador de sistemas, esta é a primeira tática 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 configuração de seu sistema não incluir canais adicionais, distribuir a carga ainda é uma
tática razoável. Os custos de hardware para isso são menores que os custos de uma substituição 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. Afinal de contas,
quando alguém distribui a carga, age para a redução da mesma (ao menos no canal sobrecarregado),
certo?
Apesar deste ponto de vista ser correto, não é o mesmo que reduzir a carga globalmente. A questão
aqui é determinar se há algum aspecto da carga do sistema que esteja causando a sobrecarga do
canal específico. Por exemplo: uma rede está altamente carregada devido a atividades desnecessárias?
Talvez, um pequeno arquivo temporário seja o recipiente de ações de leitura/gravação I/O pesadas. Se
este arquivo temporário reside num servidor de arquivos em rede, uma grande quantidade de tráfego
de rede pode ser eliminada ao trabalhar com o arquivo localmente.

3.1.4.3. Aumentar a Capacidade


A solução óbvia para banda insuficiente é aumentá-la de alguma maneira. No entanto, esta é uma
alterantiva cara. Considere, por exemplo, um controlador SCSI e seu canal sobrecarregado. Para au-
mentar sua banda, o controlador SCSI (e provavelmente todos os dispositivos anexos) precisará ser
trocado por hardware mais rápido. Se o controlador SCSI for uma placa separada, este será um pro-
cesso relativamente simples, mas se o controlador SCSI for parte da placa-mãe do sistema, será mais
difícil justificar a economia desta troca.
34 Capítulo 3. Largura de Banda e Poder de Processamento

3.1.5. Em Suma. . .
Todos os administradores de sistemas devem estar cientes da largura de banda (bandwidth) e de como
a configuração e o uso do sistema impactam na banda disponível. Infelizmente, nem sempre é aparente
o que é um problema relacionado à largura de banda e o que não é. Às vezes, o problema não é o canal,
mas um dos componentes anexos a este.
Por exemplo: considere um adaptador SCSI conectado a um canal PCI. Se há problemas de desem-
penho com o disco I/O SCSI, pode ser resultado de um adaptador SCSI com baixo desempenho,
mesmo que os canais SCSI e PCI não estejam próximos de suas capacidades de largura de banda.

3.2. Poder de Processamento


Frequentemente conhecido como poder da CPU, ciclos da CPU e vários 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 relógio) da CPU — geralmente, as CPUs com velocidades
de relógio maiores que suportam tamanhos de palavra maiores têm maior poder de processamento que
as CPUs mais lentas suportando tamanhos de palavra menores.

3.2.1. Fatos Sobre o Poder de Processamento


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

• O poder de processamento é fixo


• O poder de processamento não pode ser armazenado
O poder de processamento é fixo, de modo que a CPU só pode atingir tal velocidade. Por exemplo: se
você precisa adicionar dois números (uma operação que requer apenas uma instrução para a máquina,
na maioria das arquiteturas), uma determinada CPU pode fazê-la somente a uma velocidade. Com
raras exceções, não é possível diminuir a taxa com a qual a CPU processa as instruções, muito menos
aumentá-la.
O poder de processamento é fixo também de uma outra maneira: é finito. Ou seja, há limites para os
tipos de CPUs que podem ser conectadas a um determinado computador. Alguns sistemas são capazes
de suportar uma grande variedade de CPUs com velocidades diferentes, enquanto outros podem não
ser atualizáveis (upgradeable)2 .
O poder de processamento não pode ser armazenado para uso posterior. Em outras palavras, se uma
CPU pode processar 100 milhões de instruções em um segundo, um segundo de tempo ocioso equiv-
alem a 100 milhões de instruções de processamento que foram disperdiçadas.
Se examinarmos estes fatos sob uma perspectiva ligeiramente diferente, uma CPU "produz" um fluxo
de instruções executadas a uma taxa fixa. E, se a CPU "produz" instruções executadas, isto siginifca
que alguma outra coisa deve "consumí-las". A próxima seção define estes consumidores.

3.2.2. Consumidores do Poder de Processamento


Há dois consumidores principais do poder de processamento:

• Aplicações
• O próprio sistema operacional

2. Esta situação acarreta no que é chamado de forklift upgrade, o que significa uma troca completa de um
computador.
Capítulo 3. Largura de Banda e Poder de Processamento 35

3.2.2.1. Aplicações
Os consumidores mais óbvios do poder de processamento são as aplicações e os programas que você
quer que o computador rode. De uma planilha de cáculo a um banco de dados, as aplicações são as
razões pelas quais você tem um computador.
Um sistema com uma CPU pode fazer apenas uma coisa de cada vez. Consequentemente, se a sua
aplicação está rodando, todo o resto do sistema não está. Obviamente, o contrário também é verdade
— se alguma outra coisa além da sua aplicação está rodando, então sua aplicação não está fazendo
nada.
Mas, como é que muitas aplicações diferentes aparentemente rodam ao mesmo tempo num sistema
operacional moderno? A resposta é que estes são sistemas operacionais multi-tarefas. Em outras
palavras, eles criam a ilusão de que muitas coisas diferentes estão acontecendo simultaneamente,
apesar de isto não ser possível de fato. O truque é dar a cada processo o tempo rodando na CPU de
uma fração de segundo antes de dar a próxima fração de um segundo a um outro processo. Se estas
trocas de contexto ocorrerem com bastante frequência, tem-se a ilusão de que múltiplas aplicações
estão rodando simultaneamente.
Obviamente, as aplicações fazem outras coisas além de manipular dados usando a CPU. Elas podem
esperar pelo input do usuário, assim como desempenhar I/O a dispositivos como drives de disco e
displays gráficos. Quando estes eventos ocorrem, a aplicação não precisa mais da CPU. Nestas horas,
a CPU pode ser usada para outros processos rodando outras aplicações, sem atrasar a aplicação em
espera.
Além disso, a CPU pode ser usada por um outro consumidor do poder de processamento: o próprio
sistema operacional.

3.2.2.2. O Sistema Operacional


É difícil determinar o quanto de poder de processamento é consumido pelo sistema operacional porque
este utiliza uma mistura de códigos a nível de processo e a nível de sistema para desempenhar seu
trabalho. Apesar de ser fácil, por exemplo, usar um monitor de processos para determinar o que os
processos rodando um daemon ou serviço estão fazendo, não é fácil determinar o quanto de poder de
processamento está sendo consumido pelo processamento relacionado a I/O a nível do sistema (o que
normalmente é feito no contexto do processo requisitando a I/O.)
Em geral, é possível dividir esta espécie de sobrecarga do sistema em dois tipos:

• Manutenção (housekeeping) do sistema operacional


• Atividades relacionadas a processos
A manutenção do sistema operacional inclui atividades como o agendamento de processos e a admin-
istração da memória, 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 insuficiente para o trabalho que precisa ser feito, você tem duas
opções:

• Reduzir a carga
• Aumentar a capacidade
36 Capítulo 3. Largura de Banda e Poder de Processamento

3.2.3.1. Reduzir a Carga


Reduzir a carga da CPU é algo que pode ser feito sem nenhum custo adicional. Basta identificar os
aspectos da carga do sistema sob seu controle que podem ser reduzidos. Há três áreas nas quais focar:

• Reduzir a sobrecarga do sistema operacional


• Reduzir a sobrecarga das aplicações
• Eliminar as aplicações inteiramente

3.2.3.1.1. Reduzir a Sobrecarga do Sistema Operacional


Para reduzir a sobrecarga do sistema operacional, é necessário 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
Não espere milagres; num sistema razoavelmente bem configurado, é improvável 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 configurado, por definição, resulta numa quantidade mínima
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 Aplicações


Reduzir a sobrecarga de uma aplicação significa garantir que esta tenha tudo o que precisa para rodar
bem. Algumas aplicações apresentam comportamentos bem diferentes sob ambientes diferentes —
por exemplo: uma aplicação pode tornar-se altamente integrada ao computador ao processar certos
tipos de dados, e com outros dados não.
Deve-se manter em mente que você precisa entender sobre as aplicações rodando no seu sistema se
pretende que elas rodem da maneira mais eficiente possível. Frequentemente, isto inclui trabalhar com
seus usuários, e/ou com os desenvolvedores da sua empresa, para ajudar a descobrir maneiras pelas
quais as aplicações podem rodar mais eficientemente.

3.2.3.1.3. Eliminar Aplicações Inteiramente


Dependendo da sua empresa, esta tática pode não estar disponível, já que frequentemente não é de
responsabilidade do administrador de sistemas ditar quais aplicações devem ou não rodar. Entretanto,
se você puder identificar aplicações que são "CPU hogs" conhecidas, pode influenciar os tomadores
de decisão a aposentá-las.
Executar esta tarefa provavelmente envolverá mais alguém além de você. Os usuários afetados devem
certamente fazer parte deste processo; em muitos casos eles talvez tenham o conhecimento e o poder
político para efetuar as mudanças no âmbito das aplicações.

Dica
Tenha em mente que uma aplicação talvez não precise ser eliminada de todos os sistemas de sua
empresa. Você pode transferir uma determinada aplicação que requer muito da CPU de um sistema
sobrecarregado para outro sistema quase ocioso.
Capítulo 3. Largura de Banda e Poder de Processamento 37

3.2.3.2. Aumentar a Capacidade


Obviamente, se não for possível reduzir a demanda de poder de processamento, você deve encontrar
outras maneiras de aumentá-lo. É necessário dinheiro para fazer isso, mas pode ser feito.

3.2.3.2.1. Atualizando a CPU (upgrade)


A tática 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) têm CPUs
soldadas, impossibilitando uma atualização. O resto, no entanto, tem CPUs anexas, o que possibilita
as atualizações — pelo menos em tese.
Em seguida, você deve pesquisar se existe uma CPU mais rápida para a configuração de seu sistema.
Por exemplo: se você tem uma CPU de 1GHz e há uma unidade de 2GHz do mesmo tipo, pode ser
possível efetuar a atualização.
Finalmente, você deve determinar a velocidade máxima do relógio suportada pelo seu sistema. Con-
tinuando o exemplo acima, mesmo se existir uma CPU do tipo apropriado de 2GHz, não será possível
trocar a CPU se seu sistema suportar somente processadores de 1GHz ou menos.
Se você concluir que não é possível instalar uma CPU mais rápida no seu sistema, suas opções talvez
estejam limitadas à troca de placas-mãe ou até mesmo ao forklift upgrade (troca completa do com-
putador) mencionado anteriormente.
No entanto, algumas configurações do sistema possibilitam uma tática ligeiramente diferente. Ao
invés de trocar a CPU atual, por que não adicionar outra?

3.2.3.2.2. Será que o Multiprocessamento Simétrico (Symmetric Multiprocessing) Serve


para Você?
O multiprocessamento simétrico (também conhecido como SMP, Symmetric Multiprocessing) possi-
bilita que um sistema de computador tenha mais de uma CPU compartilhando todos os recursos do
sistema. Isto significa que, ao contrário 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 não exista CPUs com veloci-
dades de relógio maiores — basta adicionar outra CPU. Entretanto, esta flexibilidade traz algumas
desvantagens.
A primeira desvantagem é que nem todos os sistemas são capazes de efetuar a operação SMP. Seu
sistema precisa ter uma placa-mãe desenvolvida para suportar processadores múltiplos. Se não for o
caso, será necessário uma atualização da placa-mãe (no mínimo).
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 múltiplas, pode haver mais contenção dos recursos
do sistema. Devido estes fatores, atualizar um sistema com dois processadores para uma unidade de
quatro processadores não resulta num aumento de 100% do poder da CPU. De fato, dependendo do
hardware atual, da carga e da arquitetura do processador, é possível atingir um estágio no qual a adição
de um outro processador pode, na realidade, reduzir o desempenho do sistema.
Um outro aspecto para ter em mente é que o SMP não ajuda cargas de trabalho que consistem de uma
aplicação monolítica com um fluxo de execução. Ou seja, se um programa de simulação integrado ao
computador roda como um processo e sem encadeamentos, não rodará mais rápido em um sistema
SMP do que numa máquina 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 fluxo. Isto oferece
o melhor poder de CPU com o menor número de restrições sobre seu uso.
38 Capítulo 3. Largura de Banda e Poder de Processamento

Apesar desta discussão parecer indicar que o SMP nunca é uma boa idéia, há ocasiões nas quais
faz sentido. Por exemplo: ambientes que rodam múltiplas aplicações integradas ao computador são
boas candidatas para o SMP. O motivo é que as aplicações, que não fazem nada além de computar
por períodos longos de tempo, mantêm a contenção entre processos ativos (e, consequentemente,
a sobrecarga do sistema operacional) a um mínimo, enquanto os processos mantêm 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-usuário, já que o mix de processos em constante alteração pode
impactar menos a carga do sistema todo em uma máquina com multi-processador.

3.3. Informações Específicas do Red Hat Enterprise Linux


Monitorar a largura de banda e utilização da CPU sob o Red Hat Enterprise Linux implica usar as
ferramentas abordadas no Capítulo 2; portanto, se você ainda não leu este capítulo, deve fazê-lo antes
de prosseguir.

3.3.1. Monitorando a Largura de Banda no Red Hat Enterprise Linux


Conforme apresentado na Seção 2.4.2, é difícil monitorar diretamente a utilização da banda (band-
width). No entanto, ao examinar as estatísticas a nível dos dispositivos, é possível detectar se a banda
insuficiente é um problema em seu sistema.
Usando o vmstat, é possível 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:

procs memory swap io system cpu


r b w swpd free buff cache si so bi bo in cs us sy id
1 0 0 0 248088 158636 480804 0 0 2 6 120 120 10 3 87

Neste exemplo, o campo bi mostra dois blocos/segundo gravados nos dispositivos de bloco (princi-
palmente 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 é possível ter mais algumas pistas sobre as atividades relacionadas ao disco:

Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) 07/21/2003

avg-cpu: %user %nice %sys %idle


5.34 4.60 2.83 87.24

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn


dev8-0 1.10 6.21 25.08 961342 3881610
dev8-1 0.00 0.00 0.00 16 0

Este output nos mostra que o dispositivo com maior número 8 (/dev/sda, o primeiro disco SCSI)
teve média um pouco acima de uma operação I/O por segundo (o campo tsp). A maior parte das
atividades I/O deste dispositivo foram gravações (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 opção -x do iostat:
Capítulo 3. Largura de Banda e Poder de Processamento 39

Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) 07/21/2003

avg-cpu: %user %nice %sys %idle


5.37 4.54 2.81 87.27

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz
/dev/sda 13.57 2.86 0.36 0.77 32.20 29.05 16.10 14.53 54.52
/dev/sda1 0.17 0.00 0.00 0.00 0.34 0.00 0.17 0.00 133.40
/dev/sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11.56
/dev/sda3 0.31 2.11 0.29 0.62 4.74 21.80 2.37 10.90 29.42
/dev/sda4 0.09 0.75 0.04 0.15 1.06 7.24 0.53 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 estatísticas por partição. Usando o df para associar os pontos
de montagem aos nomes dos dispositivos, é possível usar este relatório para determinar, por exemplo,
se a partição contendo o /home/ está sobrecarregada de trabalho.
Na verdade, cada linha do output do iostat -x é mais longa e contém mais informações que esta.
Aqui está o resto de cada linha (com a adição da coluna dos dispositivos para facilitar a leitura):

Device: avgqu-sz await svctm %util


/dev/sda 0.24 20.86 3.80 0.43
/dev/sda1 0.00 141.18 122.73 0.03
/dev/sda2 0.00 6.00 6.00 0.00
/dev/sda3 0.12 12.84 2.68 0.24
/dev/sda4 0.11 57.47 8.94 0.17

Neste exemplo é interessante notar que /dev/sda2 é a partição swap do sistema. É óbvio que o
swapping não é um problema neste sistema, devido os diversos campos apresentando 0.00 para esta
partição.
Um outro ponto interessante é o /dev/sda1. As estatísticas desta partição são incomuns - a atividade
geral parece baixa, mas por que o tamanho médio do pedido I/O (o campo avgrq-sz), o tempo médio
de espera (o campo await) e o tempo médio de serviço (o campo svctm) são tão maiores que os das
outras partições? A resposta é que a partição contém o diretório /boot/, onde o kernel e o disco
ram inicial estão armazenados. Quando o sistema inicializar, as I/Os de leitura (note que somente os
campos rsec/s e rkB/s são diferentes de zero; nenhuma gravação é feita aqui regularmente) usados
durante o processo de inicialização são destinados a números grandes de blocos, resultando na espera
e tempos de serviço relativamente longos apresentados pelo iostat.
É possível usar o sar para uma visão geral mais longa das estatísticas I/O. Por exemplo: o sar -b
apresenta um relatório geral de I/O:

Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) 07/21/2003

12:00:00 AM tps rtps wtps bread/s bwrtn/s


12:10:00 AM 0.51 0.01 0.50 0.25 14.32
12:20:01 AM 0.48 0.00 0.48 0.00 13.32
...
06:00:02 PM 1.24 0.00 1.24 0.01 36.23
Average: 1.11 0.31 0.80 68.14 34.79

Aqui, assim como na apresentação inicial do iostat, as estatísticas são agrupdas para todos os dis-
positivos de bloco.
Um outro relatório 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 Capítulo 3. Largura de Banda e Poder de Processamento

12:00:00 AM DEV tps sect/s


12:10:00 AM dev8-0 0.51 14.57
12:10:00 AM dev8-1 0.00 0.00
12:20:01 AM dev8-0 0.48 13.32
12:20:01 AM dev8-1 0.00 0.00
...
06:00:02 PM dev8-0 1.24 36.25
06:00:02 PM dev8-1 0.00 0.00
Average: dev8-0 1.11 102.93
Average: dev8-1 0.00 0.00

Este relatório oferece informações por dispositivo, mas com poucos detalhes.
Apesar de não haver estatísticas explícitas sobre a utilização da banda para um determinado canal ou
central de dados, nós podemos pelo menos determinar o que os dispositivos estão fazendo e usar suas
atividades para determinar indiretamente a carga do canal.

3.3.2. Monitorando a Utilização da CPU no Red Hat Enterprise Linux


Ao contrário da banda, monitorar a utilização da CPU é bem mais simples. Desde uma porcentagem
da utilização da CPU no Sistema de Monitoramento GNOME às estatísticas mais aprofundadas
reportadas pelo sar, é possível determinar com acuracidade o quanto de poder da CPU está sendo
consumido e pelo que.
Além do Sistema de Monitoramento GNOME, o top é a primeira ferramenta de monitoramento
de recursos abordada no Capítulo 2 para oferecer uma representação mais profunda da utilização da
CPU. Aqui está um relatório do top sobre uma estação 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 USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
30997 ed 16 0 1100 1100 840 R 1.7 0.0 0:00 top
1120 root 5 -10 249M 174M 71508 S < 0.9 13.8 254:59 X
1260 ed 15 0 54408 53M 6864 S 0.7 4.2 12:09 gnome-terminal
888 root 15 0 2428 2428 1796 S 0.1 0.1 0:06 sendmail
1264 ed 15 0 16336 15M 9480 S 0.1 1.2 1:58 rhn-applet-gui
1 root 15 0 476 476 424 S 0.0 0.0 0:05 init
2 root 0K 0 0 0 0 SW 0.0 0.0 0:00 migration_CPU0
3 root 0K 0 0 0 0 SW 0.0 0.0 0:00 migration_CPU1
4 root 15 0 0 0 0 SW 0.0 0.0 0:01 keventd
5 root 34 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU0
6 root 34 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU1
7 root 15 0 0 0 0 SW 0.0 0.0 0:05 kswapd
8 root 15 0 0 0 0 SW 0.0 0.0 0:00 bdflush
9 root 15 0 0 0 0 SW 0.0 0.0 0:01 kupdated
10 root 25 0 0 0 0 SW 0.0 0.0 0:00 mdrecoveryd

A primeira informação relativa a CPU está na primeira linha: a média de carga (load average). A
média de carga corresponde ao número médio de processos executáveis no sistema. A média de carga
é frequentemente listada como um conjunto de três números (como o top faz), que representam a
média da carga nos últimos 1, 5 e 15 minutos, indicando que o sistema não estava muito ocupado
neste exemplo.
Capítulo 3. Largura de Banda e Poder de Processamento 41

A próxima linha, apesar de não ser restritamente relativa à utilização da CPU, tem uma relação in-
direta, pois mostra o número de processos executáveis (aqui, somente um - lembre este número pois
significa algo especial neste exemplo). O número de processos executáveis é um bom indicador do
quão intregrado à CPU o sistema deve ser.
Em seguida, há duas linhas apresentando a utilização corrente de cada uma das duas CPU no sistema.
As estatísticas de utilização estão detalhadas para mostrar se os ciclos da CPU foram gastos para
processamento no nível de usuário ou no nível do sistema. Também há estatísticas que mostram quanto
tempo de CPU foi gasto com processos com prioridades de agendamento alteradas. Finalmente, há
uma estatística de tempo ocioso.
Um pouco mais abaixo, na seção relativa a processos, nós podemos observar que o processo usando a
maior parte do poder da CPU é o próprio top; ou seja, o único processo executável neste sistema era
o top tirando uma "foto" de si mesmo.

Dica
É importante lembrar que o próprio ato de rodar o monitoramento do sistema afeta as estatísticas
de utilização dos recursos que você recebe. Todos os monitores baseados em software fazem isso
de alguma maneira.

Para obter um conhecimento mais detalhado sobre a utilização da CPU, nós devemos mudar de ferra-
mentas. Se examinarmos o output do vmstat, obteremos um entendimento ligeiramente diferente de
nosso sistema exemplo:

procs memory swap io system cpu


r b w swpd free buff cache si so bi bo in cs us sy id
1 0 0 0 233276 146636 469808 0 0 7 7 14 27 10 3 87
0 0 0 0 233276 146636 469808 0 0 0 0 523 138 3 0 96
0 0 0 0 233276 146636 469808 0 0 0 0 557 385 2 1 97
0 0 0 0 233276 146636 469808 0 0 0 0 544 343 2 0 97
0 0 0 0 233276 146636 469808 0 0 0 0 517 89 2 0 98
0 0 0 0 233276 146636 469808 0 0 0 32 518 102 2 0 98
0 0 0 0 233276 146636 469808 0 0 0 0 516 91 2 1 98
0 0 0 0 233276 146636 469808 0 0 0 0 516 72 2 0 98
0 0 0 0 233276 146636 469808 0 0 0 0 516 88 2 0 97
0 0 0 0 233276 146636 469808 0 0 0 0 516 81 2 0 97

Usamos aqui o comando vmstat 1 10 para examinar o sistema a todo segundo por dez vezes.
Primeiramente, as estatísticas relativas à CPU (os campos us, sy e id) parecem similares ao out-
put do top, e pode até parecer um pouco menos detalhado. No entanto, ao contrário do top, nós
também podemos obter alguma pista sobre como a CPU está sendo utilizada.
Se examinarmos os campos do system, percebemos que a CPU está tendo em média aproximada-
mente 500 interrupções por segundo e está alternando entre processos entre 80 e 400 vezes por se-
gundo. Se você acha que isto parece muito ativo, pense novamente, pois o processamento a nível do
usuário (o campo us) está apenas na média de 2%, enquanto o processamento a nível 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 pou-
cas informações adicionais em relação ao que vimos anteriormente com top e vmstat. Entretanto, o
sar produz uma variedade de relatórios muito úteis ao monitorar a utilização da CPU.
O primeiro relatório é obtido através do comando sar -q, que apresenta o comprimento da fila de
execução, o número total de processos e as médias de carga nos últimos um e cinco minutos. Eis uma
exemplo:
42 Capítulo 3. Largura de Banda e Poder de Processamento

Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 07/21/2003

12:00:01 AM runq-sz plist-sz ldavg-1 ldavg-5


12:10:00 AM 3 122 0.07 0.28
12:20:01 AM 5 123 0.00 0.03
...
09:50:00 AM 5 124 0.67 0.65
Average: 4 123 0.26 0.26

Neste exemplo, o sistema está sempre ocupado (dado que mais de um processo é executável ao mesmo
tempo), mas não está sobrecarregado (devido o fato que este sistema em particular tem mais de um
processador).
O próximo relatório do sar relativo à CPU é produzido pelo comando sar -u:

Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 07/21/2003

12:00:01 AM CPU %user %nice %system %idle


12:10:00 AM all 3.69 20.10 1.06 75.15
12:20:01 AM all 1.73 0.22 0.80 97.25
...
10:00:00 AM all 35.17 0.83 1.06 62.93
Average: all 7.47 4.85 3.87 83.81

As estatísticas contidas neste relatório não são diferentes daquelas produzidas por muitas das outras
ferramentas. O maior benefício deste é que o sar disponibiliza os dados intermitentemente e, por-
tanto, é mais útil para obter médias a longo prazo ou para a produção de gráficos de utilização da
CPU.
Em sistemas com multi-processadores, o comando sar -U pode produzir estatísticas para um deter-
minado 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) 07/21/2003

12:00:01 AM CPU %user %nice %system %idle


12:10:00 AM 0 3.46 21.47 1.09 73.98
12:10:00 AM 1 3.91 18.73 1.03 76.33
12:20:01 AM 0 1.63 0.25 0.78 97.34
12:20:01 AM 1 1.82 0.20 0.81 97.17
...
10:00:00 AM 0 39.12 0.75 1.04 59.09
10:00:00 AM 1 31.22 0.92 1.09 66.77
Average: 0 7.61 4.91 3.86 83.61
Average: 1 7.33 4.78 3.88 84.02

O comando sar -w reporta o número de alternações de contexto por segundo, possibilitando obter
pistas adicionais sobre onde os ciclos da CPU estão sendo gastos:

Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 07/21/2003

12:00:01 AM cswch/s
12:10:00 AM 537.97
12:20:01 AM 339.43
...
10:10:00 AM 319.42
Average: 1158.25
Capítulo 3. Largura de Banda e Poder de Processamento 43

Também é possível produzir dois relatórios diferentes do sar sobre a atividade da interrupção. O
primeiro (produzido usando o comando sar -I SUM) apresenta apenas uma estatística de "inter-
rupções por segundo":

Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 07/21/2003

12:00:01 AM INTR intr/s


12:10:00 AM sum 539.15
12:20:01 AM sum 539.49
...
10:40:01 AM sum 539.10
Average: sum 541.00

Usando o comando sar -I PROC, é possível detalhar a atividade por processo (em sistemas com
multi-processadores) e por nível de interrupção (de 0 a 15):

Linux 2.4.21-1.1931.2.349.2.2.entsmp (pigdog.example.com) 07/21/2003

12:00:00 AM CPU i000/s i001/s i002/s i008/s i009/s i011/s i012/s


12:10:01 AM 0 512.01 0.00 0.00 0.00 3.44 0.00 0.00

12:10:01 AM CPU i000/s i001/s i002/s i008/s i009/s i011/s i012/s


12:20:01 AM 0 512.00 0.00 0.00 0.00 3.73 0.00 0.00
...
10:30:01 AM CPU i000/s i001/s i002/s i003/s i008/s i009/s i010/s
10:40:02 AM 0 512.00 1.67 0.00 0.00 0.00 15.08 0.00
Average: 0 512.00 0.42 0.00 N/A 0.00 6.03 N/A

Este relatório (que foi truncado horizontalmente para caber na página) inclui uma coluna para cada
nível de interrupção (ex.: o campo i002/s ilustrando a taxa do nível 2 de interrupção). Se este fosse
um sistema com multi-processador, haveria uma linha por período de amostra para cada CPU.
Um outro ponto importante a notar sobre este relatório é que o sar adiciona ou remove campos de
interrupção específicos se não houver dados coletados parta este campo. O relatório exibido acima
oferece um exemplo disto - o fim do relatório inclui os níveis de interrupção (3 e 10) que não estavam
presentes no início do período de amostragem.

Nota
Há outros dois relatórios do sar relativos à interrupções — sar -I ALL e sar -I XALL. No en-
tanto, a configuração default do utilitário de levantamento de dados sadc não coleta as informações
necessárias para estes relatórios. 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 alteração faz com que o sadc levante informações adicionais, resultando
em tamanhos maiores de arquivos de dados. Portanto, assegure que a configuração de seu sistema
possa suportar o consumo de espaço adicional.
44 Capítulo 3. Largura de Banda e Poder de Processamento

3.4. Recursos Adicionais


Esta seção inclui diversos recursos especificamente relacionados ao Red Hat Enterprise Linux que
podem ser usados para aprender mais sobre o assunto discutido neste capítulo.

3.4.1. Documentação Instalada


O recursos seguintes são instalados no decorrer de uma instalação típica do Red Hat Enterprise Linux
e podem ajudá-lo a aprender mais sobre o assunto abordado neste capítulo.

• Página man vmstat(8) — Aprenda a exibir uma visão geral concisa do processo, memória, swap,
I/O, sistema e utilização da CPU.
• Página man iostat(1) — Aprenda a exibir as estatísticas da CPU e I/O.
• Página man sar(1) — Aprenda a produzir relatórios da utilização de recursos do sistema.
• Página man sadc(8) — Aprenda a coletar dados da utilização do sistema.
• Página man sa1(8) — Aprenda sobre um script que roda o sadc periodicamente.
• Página man top(1) — Aprenda a exibir a utilização e estatísticas no nível de processo da CPU.

3.4.2. Sites Úteis

• http://people.redhat.com/alikins/system_tuning.html — Informações de Ajuste para Servidores


Linux (System Tuning Info for Linux Servers). Uma tática para ajustar o desempenho e
monitoramento de recursos para servidores.
• http://www.linuxjournal.com/article.php?sid=2396 — Ferramentas de Monitoramento de Desem-
penho para Linux (Performance Monitoring Tools for Linux). Esta página é mais direcionada ao
administrador interessado em elaborar uma solução gráfica customizada de desempenho. Como foi
elaborado há muitos anos atrás, alguns dos detalhes talvez não possam mais ser aplicados, mas o
conceito e execução geral ainda funcionam.

3.4.3. Livros Relacionados


Os livros seguintes abordam várias questões relacionadas ao monitoramento de recursos e são boas
fontes para administradores de sistemas Red Hat Enterprise Linux.

• O Guia de Administração de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. — Inclui um capí-
tulo 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 visão mais profunda das ferramentas de monitoramento de recursos apresentadas aqui
e inclui outras que podem ser apropriadas para necessidades mais específicas de monitoramento
dos recursos.
• Linux Administration Handbook de Evi Nemeth, Garth Snyder, e Trent R. Hein; Prentice Hall —
Oferece um capítulo curto com escopo similar ao deste manual, que inclui uma seção interessante
sobre como diagnosticar um sistema que ficou mais lento repentinamente.
• Linux System Administration: A User’s Guide de Marcel Gagne; Addison Wesley Professional —
Contém um pequeno capítulo sobre o monitoramento e ajuste de desempenho.
Capítulo 4.
Memória Física e Virtual
Hoje em dia, todos os computadores de uso geral são do tipo conhecido como computadores de pro-
gramas armazenados. Como o nome implica, os computadores de programas armazenados carregam
as instruções (os blocos construtores dos programas) em algum tipo de armazenamento interno, onde
subsequentemente executam estas intruções.
Os computadores de programas armazenados também usam o mesmo armazenamento para dados. Isto
contrasta com os computadores que usam a configuração de seu hardware para controlar sua operação
(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 cátodo à
pressão em colunas de mercúrio. Felizmente, os computadores de hoje usam tecnologias com maior
capacidade de armazenamento e tamanhos como nunca vistos antes.

4.1. Padrões de Acesso ao Armazenamento


Algo para ter em mente ao longo deste capítulo é que os computadores tendem a acessar o armazena-
mento 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 significa que, se o endereço N é acessado pela CPU, é bem provável que o endereço
N +1 seja acessado em seguida. Isto faz sentido, já que a maioria dos programas consiste de grandes
seções de instruções que são executadas — em ordem — uma após a outra.
Acesso localizado significa que, se o endereço X é acessado, é provável que outros endereços próxi-
mos ao X também sejam acessados no futuro.
Estes atributos são cruciais porque permitem que um armazenamento menor e mais rápido carregue
um armazenamento maior e mais lento. Esta é a base para a implementação da memória virtual. Mas,
antes de abordarmos a memória virtual, precisamos examinar as diversas tecnologias de armazena-
mento em uso no momento.

4.2. O Espectro do Armazenamento


Os computadores atuais usam diversas tecnologias de armazenamento. Cada tecnologia é direcionada
a uma função específica, com velocidades e capacidades correspondentes.
Estas tecnologias são:

• Registradores de CPU
• Memória cache
• RAM
• Discos rígidos
• Armazenamento de backup off-line (fita, disco ótico, etc)
46 Capítulo 4. Memória Física e Virtual

Em termos de capacidades e custos, estas tecnologias compoem um espectro. Por exemplo: os reg-
istradores da CPU são:

• Muito rápido (tempos de acesso de alguns nanossegundos)


• Baixa capacidade (geralmente menor que 200 bytes)
• Capacidade de expansão muito limitada (seria necessária uma mudança na arquitetura da CPU)
• Caro (mais de um dólar 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 mídia de backup tenha que
ser enviada através de distâncias longas)
• Capacidade muito alta (10s - 100s de gigabytes)
• Capacidades de expansão essencialmente ilimitadas (limitadas apenas pelo espaço no chão
necessário para comportar a mídia de backup)
• Muito barato (frações de centavos por byte)
Ao utilizar tecnologias diferentes com capacidades diferentes, é possível ajustar o design do sistema
para um desepenho máximo com o menor custo possível. As seções seguintes exploram cada tecnolo-
gia dentro do espectro de armazenamento.

4.2.1. Registradores de CPU


Cada CPU atual inclui registradores para uma gama de propósitos, desde armazenar endereços da
instrução sendo executada ao armazenamento e manipulação de dados para propósitos genéricos.
Os registradores da CPU rodam na mesma velocidade que o resto da CPU; caso contrário, seriam
um sério gargalo para o desempenho geral do sistema. A razão disso é que praticamente todas as
operações desempenhadas pela CPU envolvem os registradores de alguma forma.
O número de registradores da CPU (e seus usos) é estritamente dependente do design arquitetônico
da CPU. Não há maneira de alterar o número de registradores da CPU, além de migrar para uma CPU
com arquitetura diferente. Por estes motivos, o número de registradores da CPU pode ser considerado
uma constante, já que são alteráveis somente com muito esforço e custo.

4.2.2. Memória Cache


O propósito da memória cache é atuar como um buffer entre os registradores da CPU, muito limitados
e de alta velocidade, e a memória principal do sistema, relativamente mais lenta e maior — geralmente
referida como RAM1. A memória cache tem uma velocidade operacional similar à da própria CPU,
portanto, quando a CPU acessa os dados no cache, não fica esperando os dados.
A memória cache é configurada de maneira que, sempre que os dados forem acessados pela RAM, o
hardware do sistema primeiro verifica se os dados desejados estão no cache. Se os dados estiverem
no cache, são rapidamente recuperados e usados pela CPU. Mas, se os dados não estão no cache, são
acessados pela RAM e, enquanto são transferidos para a CPU, também são alocadas no cache (caso
sejam novamente necessários mais tarde). Da perspectiva da CPU, tudo isso é feito transparentemente,
de modo que a única diferença 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, é necessário dividir o

1. Apesar de "RAM" ser o acrônimo de "Random Access Memory," e um termo que poderia ser facilmente
aplicado a qualquer tecnologia de armazenamento, permitindo o acesso não-sequencial de dados armazenados,
quando os administradores de sistemas falam sobre RAM, referem-se à memória principal do sistema.
Capítulo 4. Memória Física e Virtual 47

cache em seções que podem ser usadas para armazenar áreas diferentes da memória RAM e também
ter um mecanismo que permite a cada área do cache armazenar áreas diferentes de RAM em horas
diferentes. Mesmo com a diferença de tamanho entre cache e RAM, dada a natureza sequencial e lo-
calizada do acesso ao armazenamento, uma pequena quantidade de cache pode, efetivamente, acelerar
o acesso a uma grande quantidade de memória RAM.
Ao gravar dados pela CPU, as coisas podem complicar um pouco. Há duas táticas diferentes que
podem ser usadas. Em ambos os casos os dados são gravados primeiro no cache. No entanto, como
o propósito do cache é funcionar como uma cópia muito rápida do conteúdo de porções selecionadas
da RAM, sempre que algum dado é alterado, deve ser gravado em ambos, na memória cache e na
memória RAM. Caso contrário, os dados do cache e os dados da RAM não coincidiriam.
As duas táticas diferem no processo de como isso é feito. Uma tática, conhecida como cache de
gravação direta, grava os dados modificados imediatamente na RAM. O cache de gravação reversa,
no entanto, atrasa a gravação dos dados modificados de volta à RAM. A razão disto é reduzir o número
de vezes que um dado frequentemente modificado deve ser gravado de volta à RAM.
O cache de gravação direta é um pouco mais simples para implementar e, por este motivo, é mais
comum. O cache de gravação reversa é um pouco mais difícil de implementar; além de armazenar os
dados reais, é necessário manter alguma espécie de mecanismo capaz de avisar se os dados do cache
estão limpos (quando os dados do cache são os mesmos que os dados da RAM) ou sujos (quando os
dados do cache foram modificados, o que significa que os dados da RAM não estão mais atualizados).
Também é necessário implementar uma maneira de enviar periodicamente entradas sujas do cache de
volta à RAM.

4.2.2.1. Níveis do Cache


Os sub-sistemas do cache nos designs dos compudatores de hoje podem ser multi-níveis; ou seja,
pode existir mais de um conjunto de cache entre a CPU e a memória principal. Os níveis do cache
frequentemente são numerados, com os números menores mais próximos à CPU. Muitos sistemas têm
dois níveis 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 módulo da CPU, roda nas mesmas velocidades (ou
próximas) da CPU, e geralmente é um pouco maior e mais lento que o cache L1.
Alguns sistemas (normalmente, os servidores de alto desempenho) também tem o cache L3, que geral-
mente é parte da placa-mãe 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 nível simples ou
multi-nível — é reduzir o tempo médio de acesso à memória RAM.

4.2.3. Memória Principal — RAM


A RAM representa o armazenamento eletrônico em massa nos computadores de hoje. É usada como
armazenamento para dados e programas, enquanto estes estão em uso. A velocidade da RAM na
maioria dos sistemas de hoje fica entre a velocidade da memória cache e a dos discos rígidos; bem
mais próxima à da memória cache.
A operação básica da RAM é, na verdade, bem simples. No nível mais baixo há chips da RAM
— circuitos integrados que executam a "memorização" de verdade. Estes chips têm quatro tipos de
conexões com o mundo externo:

• Conexões de eletricidade (para operar os circuitos dentro do chip)


48 Capítulo 4. Memória Física e Virtual

• Conexões de dados (para permitir a transferência de dados para dentro ou para fora do chip)
• Conexões de leitura/gravação (para controlar se os dados devem ser armazenados no ou recuperados
pelo chip)
• Conexões de endereço (para determinar onde os dados devem ser lidos/gravados dentro do chip)
Aqui estão os passos para armazenar dados na RAM:

1. Os dados a serem armazenados são apresentados às conexões de dados.


2. O endereço no qual os dados devem ser armazenados é apresentado às conexões de endereço.
3. A conexão leitura/gravação está ajustada no modo gravação (write).
Recuperar dados também é simples:

1. O endereço dos dados desejados é apresentado às conexões de endereço.


2. A conexão leitura/gravação é ajustada no modo leitura (read).
3. Os dados desejados são lidos (acessados) pelas conexões 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 são vendidos como módulos. Cada módulo con-
siste de diversos chips de RAM ligados a uma pequena placa de circuito. A disposição mecânica e
elétrica do módulo adere aos diversos padrões do setor, possibilitando adquirir memória de fabricantes
variados.

Nota
O principal benefício de um sistema usando módulos RAM padronizados é que custo da RAM tende
a manter-se baixo, devido à possibilidade de adquirir módulos de mais de um fabricante de sistemas.
Apesar da maioria dos computadores usar módulos RAM padronizados, há exceções. A mais notável
é o laptop (e mesmo aqui já vem ocorrendo alguma padronização) e servidores high-end. No entanto,
mesmo nestes casos, é provável que exista módulos de terceiros, assumindo que o sistema seja
relativamente conhecido e que não seja um design completamente inovador.

4.2.4. Discos Rígidos


Todas as tecnologias abordadas até então são de natureza volátil. Em outras palavras, os dados conti-
dos no armazenamento volátil são perdidos quando a energia é desligada.
Por outro lado, os discos rígidos são não-voláteis — os dados que eles contêm continuam lá, mesmo
após a energia ser desligada. Por este motivo, os discos rígidos ocupam uma posição especial no
espectro de armazenamento. Sua natureza não-volátil torna-os ideais para armazenar programas e
dados para uso a longo prazo. Um outro aspecto único aos discos rígidos é que, ao contrário da
memória RAM e do cache, não é possível executar programas diretamente quando estão armazenados
em discos rígidos. Ao invés disso, eles precisam ser acessados primeiro pela memória RAM.
Também diferentemente das memórias RAM e cache, é a velocidade de armazenamnto e recuperação
dos discos rígidos - pelo menos uma ordem de magnitude mais lentos que as tecnologias totalmente
eletrônicas usadas para cache e RAM. A diferença de velocidades existe devido, principalmente, à sua
natureza eletromecânica. Há quatro fases diferentes durante cada transferência para ou de um disco
rígido. A lista seguinte ilustra estas fases, juntamente ao tempo que levaria a um drive típico de alto
desempenho, em média, para completar cada fase:
Capítulo 4. Memória Física e Virtual 49

• Movimento de acesso com o braço (5,5 milissegundos)


• Rotação do disco (0,1 milissegundos)
• Heads acessando/gravando dados (0,00014 milissegundos)
• Transferência de dados de/para os eletrônicos do drive (0,003 milissegundos)
Dentre estas, somente a última fase não é dependente de nenhuma operação mecânica.

Nota
Apesar de haver muito mais a aprender sobre discos rígidos, as tecnologias de armazenamento em
disco são abordadas com maior profundidade no Capítulo 5. Por enquanto, é necessário somente ter
em mente a diferença enorme de velocidades entre as tecnologias baseadas em disco e baseadas
na memória 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 além do armazenamento no disco rígido em termos
de capacidadade (maior) e velocidade (mais lenta). Aqui as capacidades são efetivamente limitadas
somente pela sua capacidade em obter e armazenar a mídia removível.
As tecnologias usadas nestes dispositivos variam amplamente. Aqui estão os tipos mais conhecidos:

• Fita magnética
• Disco ótico
Obviamente, ter mídia removível significa que os tempos de acesso tornam-se ainda mais longos, par-
ticularmente quando os dados desejados estão numa mídia ainda não carregada pelo dispositivo de
armazenamento. Esta situação é amenizada pelo uso de dispositivos robóticos capazes de carregar e
descarregar mídia automaticamente, mas as capacidades do armazenamento de mídia destes dispos-
itivos ainda é finita. Mesmo no melhor dos casos, os tempos de acesso são medidos em segundos, o
que é bem mais longo que os tempos de acesso relativamente lentos de multi milissegundos de um
disco rígido de alto desempenho.
Agora, após analisar rapidamente as diversas tecnologias de armazenamento usadas atualmente, va-
mos explorar os conceitos da memória virtual básica.

4.3. Conceitos da Memória Virtual Básica


Apesar da tecnologia por trás da construção de várias tecnologias de armazenamento atuais ser muito
impressionante, o administrador de sistemas mediano não precisa saber dos detalhes. De fato, há
somente uma questão que os administradores de sistemas precisam ter em mente:
Nunca há memória RAM suficiente.
Apesar desta evidência parecer humorística, muitos desenvolvedores de sistemas operacionais levaram
bastante tempo tentando reduzir o impacto desta deficiência real. Eles implementaram a memória
virtual — uma maneira de combinar RAM com armazenamento mais lento para dar a um sistema a
impressão de ter mais memória RAM do que realmente há instalada.
50 Capítulo 4. Memória Física e Virtual

4.3.1. Memória Virtual em Termos Simples


Vamos começar com uma aplicação hipotética. O código da máquina criando esta aplicação tem
tamanho de 10000 bytes. Também requer outros 5000 bytes para armazenamento de dados e buffers
de I/O. Isto significa que, para rodar esta aplicação, deve haver 15000 bytes de RAM disponíveis. Se
houver um byte a menos, a aplicação não será executada.
Este requisito de 15000 bytes é conhecido como o espaço de endereço da aplicação. É o número
de endereços únicos necessários para armazenar ambos, a aplicação e seus dados. Nos primeiros
computadores, a quantidade de RAM disponível tinha que ser maior que o espaço de endereço da
maior aplicação a rodar; caso contrário, a aplicação falharia com um erro de "falta de memória".
Uma última tática, conhecida como sobreposição (overlaying), tentou amenizar o problema per-
mitindo que programadores ditassem quais partes de sua aplicação precisavam estar residindo na
memória em uma determinada hora. Desta maneira, o código necessário uma vez para propósitos de
inicialização pôde ser sobreposto (overlayed) com código que seria utilizado mais tarde. Apesar da
sobreposição ter facilitado a redução de memória, era um processo muito complexo e suscetível a
erros. As sobrepopsições também falharam em resolver a questão da redução de memória de todo o
sistema no tempo de execução (runtime). Em outras palavras, um programa sobreposto pode precisar
de menos memória para rodar que um programa não sobreposto, mas se o sistema ainda não tiver
memória suficiente para o programa sobreposto, o resultado final é o mesmo — um erro de falta de
memória.
A memória virtual altera o conceito do espaço de endereço de uma aplicação. Ao invés de concentrar
no quanto de memória uma aplicação precisa para rodar, um sistema operacional com memória vir-
tual tenta continuamente responder à pergunta: "quão pequena é a memória precisa para rodar uma
aplicação?"
Apesar de, à primeira vista, parecer que nossa aplicação hipotética precisa de 15000 bytes para rodar,
pense em nossa abordagem na Seção 4.1 — o acesso à memória tende ser sequencial e localizado.
Por este motivo, a quantidade de memória precisa para executar a aplicação numa determinada hora
é menor que 15000 bytes — geralmente muito menor. Considere os tipos de acessos à memória
necessários para executar uma única instrução da máquina:

• As instruções são lidas da memória.


• Os dados necessários pelas instruções são acessados da memória.
• Após completar as instruções, os resultados das instruções são gravados de volta na memória.
O número real de bytes necessários para cada acesso à memória varia de acordo com a arquitetura
da CPU, com as instruções em si e com o tipo de dados. No entanto, mesmo se uma instrução pre-
cisasse de 100 bytes de memória para cada tipo de acesso à memória, os 300 bytes necessários seriam
bem menos que todo o espaço de endereço de 15000 bytes da aplicação. Se pudermos encontrar
uma maneira de manter o registro das necessidades de memória de uma aplicação enquanto roda,
poderíamos manter a aplicação rodando enquanto usaríamos menos memória que aquela ditada pelo
seu espaço de endereço.
Mas isso nos traz uma pergunta:
Se somente uma parte da aplicação está na memória em uma determinada hora, onde está o resto dela?

4.3.2. Backing Store — a Doutrina Central da Memória Virtual


A resposta rápida para esta pergunta é que o resto da aplicação 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 rápido. À primeira vista, isto pode
parecer um grande problema de desempenho — acima de tudo, os drives de disco são bem mais lentos
que a RAM.
Capítulo 4. Memória Física e Virtual 51

Apesar disso ser verdade, é possível tirar proveito do comportamento de acesso sequencial e localizado
das aplicações e eliminar a maioria das implicações do uso de drives de disco como backing store da
memória RAM. Isto é feito ao estruturar o sub-sistema da memória virtual, para que tente garantir que
aquelas partes da aplicação necessárias no momento — ou que, provavelmente, serão necessárias no
futuro próximo — sejam mantidas na RAM somente enquanto forem realmente necessárias.
De muitas maneiras, isso é parecido com a relação entre a memória cache e a memória RAM: fazer
com que uma pequena quantidade de armazenamento rápido junto à uma grande quantidade de ar-
mazenamento lento atuem como uma grande quantidade de armazenamento rápido.
Com isso em mente, vamos explorar o processo mais detalhadamente.

4.4. Memória Virtual: Os Detalhes


Primeiro, devemos introduzir um novo conceito: espaço de endereço virtual. O espaço de endereço
virtual (virtual address space) é a quantidade máxima de espaço de endereço disponível para uma
aplicação. O espaço de endereço virtual varia de acordo com a arquitetura e sistema operacional da
máquina. O espaço de endereço virtual depende da arquitetura porque é esta que define quantos bits
estão disponíveis para propósitos de endereçamento. O espaço de endereço virtual também depende
do sistema operacional porque a maneira através da qual este foi implementado pode introduzir limites
adicionais além ou aquém daqueles impostos pela arquitetura.
A palavra "virtual" do espaço de endereço virtual significa que este é o número total das localidades da
memória disponíveis para uma aplicação que podem ser exclusivamente endereçadas, e não a quanti-
dade de memória física instalada no sistema, nem dedicada à aplicação num determinado momento.
No caso de nossa aplicação exemplo, seu espaço de endereço virtual é 15000 bytes.
Para implementar a memória virtual é necessário que o sistema do computador tenha hardware para a
administração de memória especial. Este hardware é geralmente conhecido como uma MMU (Mem-
ory Management Unit ou Unidade de Administração de Memória). Sem uma MMU, quando a CPU
acessa a memória RAM, as localidades reais da RAM nunca mudam — o endereço de memória 123
é sempre a mesma localidade física dentro da RAM.
No entanto, com uma MMU, os endereços de memória passam por uma fase de tradução antes de cada
acesso à memória. Isso significa que o endereço de memória 123 pode ser direcionado ao endereço
físico 82043 uma vez e ao endereço físico 20468 na próxima vez. No desenrolar do processo, a
sobrecarga de registrar individualmente as traduções dos bilhões de bytes de memória de virtual para
físico seria muito grande. Ao invés disso, a MMU divide a RAM em páginas — seções contíguas de
memória de tamanho determinado, que são encaradas pela MMU como entidades separadas.
Manter o registro destas páginas e de suas traduções de endereços pode soar como um passo adicional
desnecessário e confuso. No entanto é crucial para implementar a memória virtual. Por este motivo,
considere o seguinte ponto:
Se pegarmos nossa aplicação hipotética com 15000 bytes de espaço de endereço virtual, assuma que os
primeiros dados de acesso à instrução da aplicação estão armazenados no endereço 12374. Entretanto,
assuma também que nosso computador tenha somente 12288 bytes de memória RAM física. O que
acontece quando a CPU tenta acessar o endereço 12374?
O que acontece é conhecido como uma falha de página (page fault).

4.4.1. Falhas de Página


Uma falha de página é a sequência de eventos que ocorre quando um programa tenta acessar os dados
(ou código) que está em seu espaço de endereço, mas não está localizada na RAM do sistema no
momento. O sistema operacional deve resolver as falhas de página tornando a memória dos dados
acessados residente de alguma maneira, permitindo ao programa continuar a operação como se a
falha de página nunca tivesse ocorrido.
52 Capítulo 4. Memória Física e Virtual

No caso de nossa aplicação hipotética, a CPU apresenta primeiro o endereço desejado (12374) à
MMU. No entanto, a MMU não possui tradução para este endereço. Sendo assim, interrompe a CPU
e faz com que o software, conhecido como ’fault handler’, seja executado. O fault handler então
determina o que deve ser feito para resolver esta falha de página. É possível:

• Encontrar onde a página desejada reside no disco e acessá-la (normalmente, este é o caso se a falha
for de uma página de código)
• Determinar que a página desejada já esteja na RAM (mas não localizada para o processo corrente)
e reconfigurar a MMU para apontar para esta
• Apontar para uma página especial contendo somente zeros e alocar uma nova página para o pro-
cesso, somente se o processo tentar gravar na página especial (isso é chamado de uma página cópia
na gravação - ou copy on write - e é frequentemente usada para páginas contendo dados iniciados
com zero)
• Obter a página desejada de algum outro lugar (abordado em mais detalhes posterirmente)
Apesar das três primeiras ações serem relativamente simples, a última não é. Para esta precisamos
cobrir alguns tópicos adicionais.

4.4.2. O Conjunto de Trabalho


O grupo de páginas de memória física correntemente dedicado a um processo específico é conhecido
como grupo de trabalho (ou working set) para este processo. O número de páginas do grupo de
trabalho pode aumentar e diminuir, dependendo da disponibilidade geral das páginas do sistema todo.
O grupo de trabalho aumenta com as falhas de página de um processo. O grupo de trabalho diminui
conforme a quantidade de páginas livres diminui. Para impedir que a memória acabe completamente,
as páginas devem ser removidas dos conjuntos de trabalho do processo e transformadas em páginas
livres, disponíveis para uso posterior. O sistema operacional diminui os conjuntos de trabalho dos
processos ao:

• Gravar páginas modificadas numa área dedicada de um dispositivo de armazenamento em massa


(geralmente conhecido como espaço de swapping ou paging)
• Marcar páginas não modificadas como livres (não há necessidade de gravar estas páginas em disco
já que não foram alteradas)
Para determinar os conjuntos de trabalho apropriados para todos os processos, o sistema operacional
precisa registrar as informações de uso de todas as páginas. Desta maneira, o sistema operacional
determina quais páginas estão sendo ativamente usadas (e devem permanecer residentes na memória).
Na maioria dos casos, algum tipo de algoritmo recém-usado determina quais páginas são removíveis
dos conjuntos de trabalho do processo.

4.4.3. Swapping
Apesar do swapping (gravar páginas modificadas no espaço swap do sistema) ser uma parte normal
da operação de um sistema, é possível que haja swapping em demasia. A razão para ficar atento para
o swapping excessivo é que a situação a seguir pode ocorrer facilmente, diversas vezes:

• As páginas de um processo são gravadas no espaço swap


• O processo torna-se inexecutável e tenta acessar uma página no espaço swap
• A página é retornada à memória (provavelmente forçando páginas de outros processos a serem
gravadas no espaço swap)
• Pouco tempo depois, a página é novamente gravada no espaço swap
Capítulo 4. Memória Física e Virtual 53

Se esta sequência de eventos for espalhada, é conhecida como thrashing e é um sinal de memória
RAM insuficiente para a atual carga de trabalho. O thrashing é extremamente prejudicial ao desem-
penho do sistema, já que a carga da CPU e I/O que pode ser gerada numa situação como esta rapi-
damente compensa a carga imposta pelo trabalho real de um sistema. Em casos extremos, o sistema
talvez não execute nenhum trabalho útil, gastando todos os seus recursos movendo páginas da e para
a memória.

4.5. Implicações ao Desempenho da Memória Virtual


Apesar da memória virtual possibilitar que os computadores rodem aplicações maiores e mais com-
plexas com mais facilidade, assim como com qualquer outra ferramenta poderosa, ela tem um preço.
Neste caso, o preço é refletido no desempenho — um sistema operacional com memória virtual tem
muito mais a fazer do que um sistema operacional incapaz de suportar a memória virtual. Isto significa
que o desempenho de uma aplicação com memória virtual nunca é tão bom quanto o desempenho da
mesma aplicação com 100% residente na memória.
No entanto, isto não é motivo para desistência. Os benefícios da memória virtual são muito bons para
fazer isso. Com um pouco de esforço, é possível obter um bom desempenho. O que deve ser feito é
analisar os recursos do sistema impactados pelo alto uso do sub-sistema da memória virtual.

4.5.1. Cenário do Desempenho no Pior Caso


Por um momento, lembre-se do que você leu neste capítulo e considere quais recursos do sistema são
usados por atividades extremamente pesadas de swapping e de falha de página:

• RAM — a razão pela qual a RAM disponível está baixa (caso contrário, não haveria necessidade
de falha de página ou swap).
• Disco — O espaço em disco talvez não 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 necessário para suportar a administração da
memória e a configuração das operações 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 memória RAM, alto índice de falhas de página e um
sistema rodando próximo de seus limites em termos de I/O do disco ou CPU. Neste ponto, o sistema
está com thrashing, com baixo desempenho como resultado inevitável.

4.5.2. Cenário do Desempenho no Melhor Caso


No melhor dos casos, a sobrecarga do suporte à memória virtual apresenta uma carga extra mínima
em um sistema bem configurado:

• RAM — RAM suficiente para todos os conjuntos de trabalho com um restinho de memória capaz
de resolver quaisquer falhas de página2
• Disco — Devido a atividade limitada da falha de página, a largura de banda I/O seria minimamente
impactada

2. Um sistema razoavelmente ativo sempre tem um certo nível de atividades relacionadas a falhas de página,
devido às falhas de página ocorridas com a incursão de aplicações recém-lançadas na memória.
54 Capítulo 4. Memória Física e Virtual

• CPU — A maioria dos cliclos de CPU são, na verdade, dedicados a rodar aplicações, ao invés de
rodar o código de administração de memória do sistema operacional
Sendo assim, temos que ter em mente que o impacto de desempenho da memória virtual é mínimo
quando é usada o menos possível. Isto siginifica que o fator determinante para um bom desempenho
do sub-sistema de memória virtual é ter memória RAM suficiente.
A seguir (mas bem abaixo em termos de importância relativa) está a capacidade da CPU e I/O do
disco. No entanto, tenha em mente que estes recursos ajudam somente na degradação do desempenho
do sistema devido a muitas falhas e swapping de maneira mais graciosa; fazem pouco para ajudar o
desempenho do sub-sistema da memória virtual (apesar de poderem desempenhar uma função maior
no desempenho do sistema todo).

4.6. Informações Específicas do Red Hat Enterprise Linux


Devido à complexidade inerente de um sistema operacional com memória virtual de páginas sob
demanda, monitorar os recursos relacionados à memória sob o Red Hat Enterprise Linux pode ser
confuso. Consequentemente, é melhor começar pelas ferramentas mais simples e seguir adiante.
Usando o free, é possível obter uma visão geral concisa (e de certa maneira simplista) da utilização
da memória e de swap. Veja aqui um exemplo:

total used free shared buffers cached


Mem: 1288720 361448 927272 0 27844 187632
-/+ buffers/cache: 145972 1142748
Swap: 522104 0 522104

Nós percebemos que este sistema tem 1.2GB de RAM, dos quais somente 350MB estão em uso.
Como esperado num sistema com tanta memória RAM livre, nenhuma das partições swap de 500MB
está em uso.
Contraste aquele exemplo com esse:

total used free shared buffers cached


Mem: 255088 246604 8484 0 6492 111320
-/+ buffers/cache: 128792 126296
Swap: 530136 111308 418828

Esse sistema tem em torno de 256MB de RAM e a maioria está em uso, deixando apenas 8MB livres.
Mais de 100MB da partição swap de 500MB estão em uso. Apesar desse sistema ser mais limitado que
o primeiro em termos de memória, temos que investigar um pouco mais para saber se esta limitação
de memória está causando problemas de desempenho.
Apesar de ser mais secreto que o free, o vmstat tem o benefício de apresentar mais que apenas
estatísticas de utilização da memória. Aqui está o output de vmstat 1 10:

procs memory swap io system cpu


r b w swpd free buff cache si so bi bo in cs us sy id
2 0 0 111304 9728 7036 107204 0 0 6 10 120 24 10 2 89
2 0 0 111304 9728 7036 107204 0 0 0 0 526 1653 96 4 0
1 0 0 111304 9616 7036 107204 0 0 0 0 552 2219 94 5 1
1 0 0 111304 9616 7036 107204 0 0 0 0 624 699 98 2 0
2 0 0 111304 9616 7052 107204 0 0 0 48 603 1466 95 5 0
3 0 0 111304 9620 7052 107204 0 0 0 0 768 932 90 4 6
3 0 0 111304 9440 7076 107360 92 0 244 0 820 1230 85 9 6
2 0 0 111304 9276 7076 107368 0 0 0 0 832 1060 87 6 7
3 0 0 111304 9624 7092 107372 0 0 16 0 813 1655 93 5 2
Capítulo 4. Memória Física e Virtual 55

2 0 2 111304 9624 7108 107372 0 0 0 972 1189 1165 68 9 23

Durante essa amostra de 10 segundos, a quantidade de memória livre (o campo free) varia ligeira-
mente, 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
utilização de memória corrente.
Quando pesquisamos questões relativas à memória, frequentemente é necessário determinar como o
sub-sistema de memória virtual do Red Hat Enterprise Linux está usando a memória do sistema. Ao
usar o sar, é possível examinar o aspecto do desempenho do sistema em mais detalhes.
Ao rever o relatório do sar -r, podemos examinar a utilização da memória e de swap mais de perto:

Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 07/22/2003

12:00:01 AM kbmemfree kbmemused %memused kbmemshrd kbbuffers kbcached


12:10:00 AM 240468 1048252 81.34 0 133724 485772
12:20:00 AM 240508 1048212 81.34 0 134172 485600
...
08:40:00 PM 934132 354588 27.51 0 26080 185364
Average: 324346 964374 74.83 0 96072 467559

Os campos kbmemfree e kbmemused exibem as estatísticas típicas de memória usada e memória


livre, com a porcentagem de memória utilizada exibida no campo %memused. Os campos kbbuffers
e kbcached mostram quantos kilobytes de memória estão 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 relatório foram quebradas para caber na página. Aqui está o restante de cada linha,
com o timestamp adicionado à esquerda para facilitar a leitura:

12:00:01 AM kbswpfree kbswpused %swpused


12:10:00 AM 522104 0 0.00
12:20:00 AM 522104 0 0.00
...
08:40:00 PM 522104 0 0.00
Average: 522104 0 0.00

Para a utilização da memória swap, os campos kbswpfree e kbswpused exibem as quantidades de


swap livre e de espaço swap usado, em kilobytes, com o campo %swpused exibindo o espaço swap
utilizado em porcentagem.
Para aprender mais sobre a atividade de swapping ocorrendo, use o relatório sar -W. Aqui está um
exemplo:

Linux 2.4.20-1.1931.2.231.2.10.entsmp (raptor.example.com) 07/22/2003

12:00:01 AM pswpin/s pswpout/s


12:10:01 AM 0.15 2.56
12:20:00 AM 0.00 0.00
...
03:30:01 PM 0.42 2.56
Average: 0.11 0.37

Percebemos aqui que, em média, houve três vezes menos páginas trazidas de swap (pswpin/s) que
páginas indo para swap (pswpout/s).
56 Capítulo 4. Memória Física e Virtual

Para entender melhor como as páginas estão sendo usadas, consulte o relatório sar -B:

Linux 2.4.20-1.1931.2.231.2.10.entsmp (raptor.example.com) 07/22/2003

12:00:01 AM pgpgin/s pgpgout/s activepg inadtypg inaclnpg inatarpg


12:10:00 AM 0.03 8.61 195393 20654 30352 49279
12:20:00 AM 0.01 7.51 195385 20655 30336 49275
...
08:40:00 PM 0.00 7.79 71236 1371 6760 15873
Average: 201.54 201.54 169367 18999 35146 44702

Aqui podemos determinar quantos blocos por segundo são paginados do (paged in) disco (pgpgin/s)
e paginados para o (paged out) disco (pgpgout/s). Estas estatísticas servem como um barômetro da
atividade geral da memória virtual.
Entretanto, pode-se obter mais conhecimento ao examinar os outros campos deste relatório. O kernel
do Red Hat Enterprise Linux marca todas as páginas como ativas ou inativas. Como o nome implica,
as páginas ativas estão em uso corrente de alguma forma (como processos ou páginas de buffer, por
exemplo), enquanto as páginas inativas não estão. Este relatório-exemplo mostra que a lista de páginas
ativas (o campo activepg) tem, em média, aproximadamente 660MB 3.
Os campos restantes deste relatório concentram-se na lista inativa — páginas que, por alguma razão,
não foram utilizadas recentemente. O campo inadtypg mostra quantas páginas inativas estão su-
jas (alteradas) e talvez precisem ser gravadas no disco. O campo inaclnpg, por outro lado, mostra
quantas páginas inativas estão limpas (inalteradas) e não 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 suficiente para atuar como
um pool de substituição de páginas.
Para mais dicas sobre o status de páginas (especificamente, a frequência de alteração de status), use o
relatório sar -R. Aqui está uma amostra:

Linux 2.4.20-1.1931.2.231.2.10.entsmp (raptor.example.com) 07/22/2003

12:00:01 AM frmpg/s shmpg/s bufpg/s campg/s


12:10:00 AM -0.10 0.00 0.12 -0.07
12:20:00 AM 0.02 0.00 0.19 -0.07
...
08:50:01 PM -3.19 0.00 0.46 0.81
Average: 0.01 0.00 -0.00 -0.00

As estatísticas deste relatório sar específico são únicas, pois podem ser positivas, negativas ou zero.
Quando positivas, o valor indica a frequência com a qual as páginas desse tipo estão aumentando.
Quando negativas, o valor indica a frequência com a qual as páginas desse tipo estão diminuindo. O
valor zero indica que páginas desse tipo não estão aumentando nem diminuindo.
Nesse exemplo, a última amostra exibe um pouco mais de três páginas por segundo sendo alocadas
da lista de páginas livres (o campo frmpg/s) e aproximadamente uma página por segundo sendo
adicionada ao cache de páginas (o campo campg/s). A lista de páginas usadas como buffers (o campo
bufpg/s) ganhou aproximadamente uma página a cada dois segundos, enquanto a lista de páginas da
memória compartilhada (o campo shmpg/s) não ganhou nem perdeu páginas.

3. O tamanho de página sob o Red Hat Enterprise Linux no sistema x86 usado neste exemplo é 4096 bytes.
Sistemas baseados em outras arquiteturas podem ter tamanhos de página diferentes.
Capítulo 4. Memória Física e Virtual 57

4.7. Recursos Adicionais


Esta seção inclui várias fontes que podem ser usadas para aprender mais sobre o monitoramento de
recursos e sobre o assunto abordado neste capítulo relativo ao Red Hat Enterprise Linux.

4.7.1. Documentação Instalada


Os seguintes recursos são instalados no decorrer de uma típica instalação do Red Hat Enterprise Linux
e podem ajudá-lo a aprender mais sobre o assunto abordado neste capítulo.

• Página man free(1) — Aprenda a exibir as estatísticas da memória livre e usada.


• Página man vmstat(8) — Aprenda a exibir uma visão geral concisa de processos, memória, swap,
I/O, sistema e utilização da CPU.
• Página man sar(1) — Aprenda a produzis relatórios de utilização dos recursos do sistema.
• Página man sa2(8) — Aprenda a produzir arquivos diários do relatório de utilização dos recursos
do sistema.

4.7.2. Sites Úteis

• http://people.redhat.com/alikins/system_tuning.html — Informação 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 Desem-
penho para Linux. Essa página é mais direcionada ao administrador interessado em elaborar uma
solução gráfica personalizada de desempenho. Escrita há muitos anos atrás, alguns detalhes talvez
não se apliquem mais, mas o conceito e execução gerais ainda funcionam.

4.7.3. Livros Relacionados


Os livros a seguir abordam várias questões relacionadas ao monitoramento de recursos e são boas
fontes de informação para administradores de sistemas Red Hat Enterprise Linux.

• O Guia de Administração de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. — Inclui um capí-
tulo 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 visões mais aprofundadas das ferramentas de monitoramento de recursos abordadas aqui e
inclui outras que podem ser apropriadas para necessidades de monitoramento mais específicas.
• Red Hat Linux Security and Optimization de Mohammed J. Kabir; Red Hat Press — Aproximada-
mente, as 150 primeiras páginas deste livro abordam questões relativas ao desempenho. Isso inclui
capítulos dedicados a questões de desempenho específicas à 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 capítulo com escopo similar ao deste livro, mas inclui uma seção interessante
sobre o diagnóstico de um sistema que ficou lento repentinamente.
• Linux System Administration: A User’s Guide de Marcel Gagne; Addison Wesley Professional —
Contém um pequeno capítulo sobre o monitoramento e ajuste de desempenho.
• Essential System Administration (3a Edição) de Aeleen Frisch; O’Reilly & Associates — O capítulo
sobre a administração de recursos do sistema contém boas informações genéricas, com algumas
específicas ao Linux.
58 Capítulo 4. Memória Física e Virtual

• System Performance Tuning (2a Edição) de Gian-Paolo D. Musumeci e Mike Loukides; O’Reilly &
Associates — Apesar de ser altamente direcionado a implementações mais tradicionais do UNIX,
há muitas referências específicas ao Linux ao longo do livro.
Capítulo 5.
Administrando o Armazenamento
Se há alguma atividade que toma a maior parte do dia de um administrador de sistemas, esta deve
ser a administração do armazenamento. Parece que os discos estão sempre sem espaço livre, sendo
sobrecarregados por muitas atividades I/O ou falhando inesperadamente. Sendo assim, é vital ter um
conhecimento sólido do armazenamento em disco para ser um administrador de sistemas competente.

5.1. Uma Visão Geral do Hardware de Armazenamento


Antes de administrar o armazenamento, é preciso entender o hardware no qual os dados são armazena-
dos. A não ser que você já tenha algum conhecimento sobre a operação do dispositivo de armazena-
mento em massa, poderá se ver numa situação com um problema relativo ao armazenamento, mas
não possuirá o conhecimento elementar para interpretar o que está vendo. Ao obter um pouco de
conhecimento da operação do respectivo hardware, você poderá determinar se o sub-sistema de ar-
mazenamento de seu computador está operando apropriadamente.
A grande maioria dos dispositivos de armazenamento em massa usam alguma forma de mídia rotativa
e suporta o acesso randômico aos dados nesta mídia. Isso significa que os seguintes componentes
estão presentes de alguma forma em praticamente todos os dispositivos de armazenamento em massa:

• Pratos de disco (disk platters)


• Dispositivo de acesso/gravação de dados
• Braços de acesso
As seções seguintes exploram cada um destes componentes em mais detalhes.

5.1.1. Pratos de Disco


A mídia 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 alumínio, vidro e policarbonato.
A superfície 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 são cobertos de um
componente que exibe boas características magnéticas.
Uma outra tecnologia comum de armazenamento é baseada nos princípios ópticos; nestes casos, os
pratos são cobertos por materiais cujas propriedades ópticas podem ser modificadas, assim permitindo
armazenar os dados opticamente1 .
Não importa a tecnologia de armazenamento em uso; os pratos de disco são torcidos, permitindo à
sua superfície inteira varrer um outro componente — o dispositivo de acesso/gravação de dados.

1. Alguns dispositivos ópticos — notadamente os drives de CD-ROM— usam táticas um pouco diferentes para
o armazenamento de dados; estas diferenças são apontadas ao longo do capítulo.
60 Capítulo 5. Administrando o Armazenamento

5.1.2. Dispositivo de acesso/gravação de dados


O dispositivo de acesso/gravação é o componente que leva os bits e bytes no qual opera um sistema
de computador e os transforma em variações magnéticas ou ópticas, necessárias para interagir com os
materiais que cobrem a superfície dos pratos de disco.
Às vezes, as condições sob as quais estes dispositivos devem operar são desafiadoras. Por exemplo:
num armazenamento em massa magneticamente baseado, os dispositivos de acesso/gravação (con-
hecidos como cabeças) devem estar bem próximos à superfície do prato. No entanto, se a cabeça e
a superfície do prato do disco tivessem contato, a fricção resultante danificaria ambos seriamente.
Sendo assim, as superfícies da cabeça e do prato são polidas cuidadosamente, e a cabeça usa pressão
do ar exercida pelos pratos giratórios para flutuar sobre a superfície do prato, "voando" há uma altitude
mais fina que um fio de cabelo. É por este motivo que os drives de disco magnéticos são sensíveis a
choque, alterações de temperatura repentinas e quaisquer contaminações do ar.
Os desafios enfrentados pelas cabeças ópticas são de certa forma diferentes daqueles enfrentados
pelas cabeças magnéticas — aqui, o grupo da cabeça deve permanecer há uma distância relativamente
constante da superfície do prato. Caso contrário, as lentes usadas para focar no prato não produzem
uma imagem suficientemente definida.
Em qualquer um dos casos, as cabeças usam uma quantidade muito pequena da área da superfície
do prato para o armazenamento de dados. Conforme o prato gira abaixo das cabeças, essa área da
superfície toma a forma de uma linha circular muito fina.
Se essa fosse a maneira como os dispositivos de massa funcionam, significaria que mais de 99% da
área da superfície do prato seria desperdiçada. Poderia-se montar cabeças adicionais sobre o prato,
mas, para utilizar totalmente a área da superfície do prato, seriam necessárias mais de mil cabeças. Se
faz necessário um método para mover a cabeça sobre a superfície do prato.

5.1.3. Braços de Acesso


Ao usar uma cabeça conectada a um braço capaz de varrer toda a superfície do prato, é possível usar
o prato totalmente para o armazenamento de dados. Entretanto, o braço de acesso deve ser capaz de
duas coisas:

• Mover-se rapidamente
• Mover-se com muita precisão
O braço de acesso deve mover-se o mais rápido possível porque o tempo gasto movendo a cabeça de
uma posição a outra é tempo desperdiçado. Isso ocorre porque não é possível acessar nenhum dado
até que o braço de acesso pare de mover2.
O braço de acesso deve ser capaz de mover-se com grande precisão porque, conforme afirmado an-
teriormente, a área da superfície usada pelas cabeças é muito pequena. Sendo assim, para usar a
capacidade de armazenamento do prato eficientemente, é necessário mover as cabeças somente o sufi-
ciente para garantir que todos os dados gravados na nova posição não sobrescrevam os dados gravados
numa posição anterior. Isso tem o efeito de dividir conceitualmente a superfície do prato em mil ou
mais "anéis" concêntricos ou faixas. O movimento do braço de acesso de uma faixa para outra é fre-
quentemente referido como busca, e o tempo que leva para o braço 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 braço de acesso move-se continuamente,
fazendo com que o grupo da cabeça faça um movimento espiral ao longo da superfície do prato. Essa é uma
diferença fundamental de como o meio de armazenamento é usado, e reflete a origem do CD-ROM como um
meio de armazenamento para música, onde a recuperação contínua de dados é uma operação mais comum que a
busca de um ponto de dados específico.
Capítulo 5. Administrando o Armazenamento 61

Quando há pratos múltiplos (ou um prato com ambas superfícies utilizadas para o armazenamento
de dados), os braços de cada superfície ficam empilhados, permitindo que a mesma faixa de cada
superfície seja acessada simultaneamente. Se as faixas de cada superfície pudessem ser visualizadas
com o acesso estático sobre uma determinada faixa, elas pareceriam estar empilhadas uma sobre
a outra, formando um formato cilíndrico. Consequentemente, o conjunto de faixas acessível numa
determinada posição dos braços de acesso são conhecidas como cilindro.

5.2. Conceitos de Endereçamento do Armazenamento


A configuração dos pratos de disco, cabeças e dos braços de acesso possibilita posicionar a cabeça
sobre qualquer parte de qualquer superfície de qualquer prato no dispositivo de armazenamento em
massa. No entanto, isso não é suficiente; para usar essa capacidade de armazenamento devemos ter
algum método para atribuir endereços a partes uniformemente dimensionadas do armazenamento
disponível.
Há um aspecto final necessário a este processo. Considere todas as faixas dos diversos cilindros pre-
sentes em um típico dispositivo de armazenamento em massa. Como as faixas têm diâmetros variados,
suas circunferências também variam. Sendo assim, se o armazenamento estivesse endereçado somente
ao nível da faixa, cada faixa teria quantidades diferentes de dados — a faixa #0 (a mais próxima do
centro do prato) pode ter 10.827 bytes, enquanto a faixa #1.258 (próxima à extremidade externa do
prato) pode ter 15.382 bytes.
A solução é dividir cada faixa em diversos setores ou blocos de segmentos de armazenamento de
tamanho consistente (geralmente 512 bytes). O resultado é que cada faixa contém um número
definido3 de setores.
Um efeito colateral disso é que cada faixa contém espaço não-usado — o espaço entre setores. Apesar
do número constante de stores em cada faixa, a quantidade de espaço não-usado varia — há relativa-
mente pouco espaço não-usado nas faixas de dentro e uma quantidade bem maior de espaço não-usado
nas faixas de fora. Em ambos os casos, este espaço não-usado é desperdiçado, já que não é possível
armazenar dados ali.
Em contrapartida, a vantagem deste espaço desperdiçado é que agora é possível mapear efetivamente
o armazenamento para um dispositivo de massa. De fato, há dois métodos de mapeamento — mapea-
mento 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 físico específico no meio de armazenamento.
No caso dos dispositivos aqui descritos, isto refere-se a três itens específicos que definem um ponto
específico nos pratos do disco do dispositivo:

• Cilindro
• Cabeça
• Setor
As seções a seguir explicam como um endereço hipotético pode descrever uma localidade física es-
pecífica no meio de armazenamento.

3. Enquanto os dispositivos de armazenamento em massa mais antigos usam o mesmo número de setores para
todas as faixas, os dispositivos mais recentes dividiram a gama de cilindros em "zonas" diferentes, com cada zona
contendo um número diferente de setores por faixa. O motivo é tirar proveito do espaço adicional entre os setores
nos cilindros mais externos, onde há mais espaço não-utilizado entre os setores.
62 Capítulo 5. Administrando o Armazenamento

5.2.1.1. Cilindro
Como afirmado anteriormente, o cilindro indica uma posição específica do braço de acesso (e, por-
tanto, as cabeças de acesso/gravação). Ao especificar um determinado cilindro, estamos eliminando
todos os outros cilindros, reduzindo nossa busca a apenas uma faixa de cada superfície no dispositivo
de armazenamento em massa.

Cilindro Cabeça Setor


1014 X X
Tabela 5-1. Mapeamento do Armazenamento

Na Tabela 5-1, a primeira parte de um endereço baseado na geometria foi preenchido. Ainda há dois
componentes indefinidos neste endereço — a cabeça e o setor.

5.2.1.2. Cabeça
Nós estamos estritamente selecionando um prato específico do disco, mas, como cada superfície tem
uma cabeça de acesso/gravação dedicada a ela, é mais fácil pensar em termos de interação com uma
determinada cabeça. Na realidade, a essência eletrônica do dispositivo seleciona uma cabeça e —
desseleciona o resto — somente interage com a cabeça selecionada durante a operação I/O. Todas as
outras faixas que formam o cilindro corrente agora foram eliminadas.

Cilindro Cabeça Setor


1014 2 X
Tabela 5-2. Mapeamento do Armazenamento

Na Tabela 5-2, as duas primeiras partes do endereço baseado na geometria foram preenchidos. Ainda
há um componente final faltando neste endereço — o setor.

5.2.1.3. Setor
Ao especificar um determinado setor, completamos o mapeamento e identificamos unicamente o bloco
de dados desejado.

Cilindro Cabeça Setor


1014 2 12
Tabela 5-3. Mapeamento do Armazenamento

Na Tabela 5-3, o endereço baseado na geometria completo foi preenchido. Este endereço identifica a
localidade de um bloco específico 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 numeração dos cilindros, cabeças e setores.
É verdade que cada endereço baseado na geometria identifica unicamente um bloco de dados especí-
fico, mas isto se aplica somente se o esquema de numeração dos cilindros, cabeças e setores não
Capítulo 5. Administrando o Armazenamento 63

for alterado. Se o esquema de numeração mudar (como mudar o hardware/software interagindo com
o dispositivo de armazenamento), então o mapeamento entre os endereços 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 tática de mapeamento. A próx-
ima seção 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 número único. Esse número é passado
do computador para o dispositivo de armazenamento em massa, que executa a conversão internamente
para o endereço baseado na geometria, necessário pelo circuito de controle do dispositivo.
Como a conversão para um endereço baseado na geometria é sempre feita pelo próprio 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 conexão é conhecido como uma interface. Os dispositivos de armazena-
mento em massa não são diferentes — também têm interfaces. É importante saber sobre as interfaces
por duas razões:

• Há muitas interfaces diferentes (na maioria incompatíveis)


• Interfaces diferentes têm características de desempenho e preços diferentes
Infelizmente, não 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 contrário, há um risco real
de adquirir o hardware errado ao planejar uma atualização (upgrade) dos sistemas.
Interfaces diferentes têm capacidades de desempenho diferentes, o que torna algumas interfaces mais
indicadas para determinados ambientes. Por exemplo: interfaces capazes de suportar dispositivos de
alta velocidade são mais indicadas para ambientes de servidores, enquanto interfaces mais lentas são
mais indicadas para o uso leve do desktop. Tais diferenças de desempenho também trazem diferenças
nos preços, portanto você — como sempre — obtém aquilo que pagou. A computação de alto desem-
penho não é barata.

5.3.1. Histórico
Ao longo dos anos, houve muitas interfaces diferentes criadas para dispositivos de armazenamento
em massa. Algumas foram deixadas de lado e outras ainda estão em uso. No entanto, a seguinte lista é
provida para se ter uma idéia 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 floppy 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 Capítulo 5. Administrando o Armazenamento

SA-400
Uma outra interface de drive de disco floppy (desta vez, desenvolvida originalmente no fim dos
anos 70 para o então novo drive de floppy de 5,25 polegadas). Usava um cabo condutor 34 com
um conector socket padrão. Uma versão ligeiramente modificada desta interface ainda é usada
hoje em dia para drives de disquetes de 5,25 e 3,5 polegadas.

IPI
Significa ’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 rígidos de mini-
computadores de 8 e 14 polegadas nos anos 70 e 80.

ST506/412
Uma interface de disco rígido do início dos anos 80. Usada em muitos computadores pessoais da
época, essa interface usava dois cabos — um condutor 34 e um condutor 20.

ESDI
Significa Interface Aprimorada de Dispositivo Pequeno (’Enhanced Small Device Interface’).
Essa interface foi considerada sucessora da ST506/412 com taxas de transferência mais rápidas e
tamanhos maiores de drives suportados. Datada de meados dos anos 80, a ESDI usava o mesmo
esquema de conexão de dois cabos de sua antecessora.
Havia também interfaces proprietárias dos maiores fabricantes de computadores da época (IBM e
DEC, principalmente). A intenção por trás da criação destas interfaces era tentar proteger o negócio
extremamente lucrativo dos periféricos para seus computadores. Entretanto, devido sua natureza pro-
prietária, os dispositivos compatíveis com estas interfaces eram mais caros que seus dispositivos não
proprietários equivalentes. Por causa disso, estas interfaces não tiveram popularidade à longo prazo.
Apesar das interfaces proprietárias terem desaparecido em sua maioria, e as interfaces descritas no
início desta seção não terem muito ou nenhum market share, é importante saber sobre estas interfaces
que não são mais usadas, pois provam uma questão — nada permanece por muito tempo na indústria
de computadores. Portanto, fique 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 Padrão de Hoje


Ao contrário das interfaces proprietárias mencionadas na seção anterior, algumas interfaces foram
mais amplamente adotadas e transformaram-se nos padrões da indústria. Duas interfaces em particular
sofreram essa transição e são o coração da indústria de armazenamento de hoje:

• IDE/ATA
• SCSI

5.3.2.1. IDE/ATA
IDE significa ’Integrated Drive Electronics’. Essa interface tem origem no fim dos anos 80 e usa um
conector de 40 pinos.
Capítulo 5. Administrando o Armazenamento 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 compatível com a ATA)
ainda é usado. No entanto, o restante desta seção usa o nome apropriado da interface — ATA.

A ATA implementa uma topologia de canal, com cada canal suportando dois dispositivos de armazena-
mento em massa - o mestre e o escravo. Estes termos podem ser mal-interpretados, pois implicam
algum tipo de relação entre os dispositivos, mas este não é o caso. A seleção de qual dispositivo é o
mestre e qual é o escravo é feita normalmente através do uso de blocos jumper em cada dispositivo.

Nota
Uma inovação mais recente é a introdução das capacidades de seleção do cabo à ATA. Essa in-
ovação requer o uso de um cabo especial, um controlador ATA e dispositivos de armazenamento
em massa que suportam a seleção de cabo (normalmente, através de uma configuração "cable se-
lect" do jumper.) Quando configurada apropriadamente, a seleção de cabo elimina a necessidade
de alterar os jumpers movendo dispositivos; ao invés disso, a posição do dispositivo no cabo da ATA
denota se é mestre ou escravo.

Uma variação desta interface ilustra a única maneira através da qual as tecnologias podem ser
mescladas e também introduz nossa próxima interface padrão. A ATAPI é uma variação da interface
ATA e sua sigla significa ’AT Attachment Packet Interface’. Usada principalmente por drives de
CD-ROM, a ATAPI obedece aos aspectos elétrico e mecânico da interface ATA, mas usa o protocolo
de comunicação da próxima 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 início dos anos 80 e declarada como padrão em 1986. Assim como a ATA, a SCSI usa
uma topologia de canal, mas estas são as únicas similaridades.
Usar uma topologia de canal significa que cada dispositivo do canal deve ser unicamente identificável
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 endereço numérico
único ou ID SCSI. Cada dispositivo num canal SCSI deve ser configurado (geralmente por jumpers
ou interruptores4 ) para responder ao seu ID SCSI.
Antes de continuar esta explanação, é importante notar que o padrão SCSI não representa uma única
interface, mas uma família de interfaces. Há diversas áreas nas quais a SCSI varia:

• Largura do canal
• Velocidade do canal
• Características elétricas
O padrão SCSI original descrevia uma topologia de canal na qual oito linhas do canal eram usadas
para transferência de dados. Isto significa que os primeiros dispositivos SCSI podiam transferir um
byte de dados por vez. Nos anos seguintes, o padrão foi expandido para permitir implementações

4. Alguns hardware de armazenamento (geralmente aqueles que incorporam "portadores" de drives removíveis)
são desenvolvidos de modo que o ato de plugar um módulo automaticamente ajusta o ID SCSI para um valor
apropriado.
66 Capítulo 5. Administrando o Armazenamento

nas quais dezesseis linhas podiam ser usadas, duplicando a quantidade de dados que os dispositivos
podiam transferir. As implementações originais de "8 bits" foram então referidas como SCSI estreitos,
enquanto as implementações 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 trans-
ferência de 5MB/segundo no canal SCSI original de 8 bits. No entanto, as revisões subsequentes do
padrão 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 alterações de velocidade
do canal também receberam novos nomes; a velocidade de 10MHz do canal foi chamada rápida. As
melhorias subsequentes trouxeram as velocidades de canal para ultra (20MHz), rápida40 (40MHz),
e rápida805 . Outros aumentos nas taxas de transferência trouxeram diversas versões diferentes da
velocidade de canal ultra160.
Combinando estes termos, é possível nomear concisamente várias configurações do SCSI. Por exem-
plo: "SCSI ultra largo" refere-se a um canal SCSI de 16 bits rodando a 20MHz.
O padrão SCSI original usava sinalização single-ended; esta é uma configuração na qual somente um
condutor é usado para passar um sinal elétrico. Implementações posteriores também permitiram o uso
da sinalização diferencial, na qual dois condutores são usados para passar um sinal. O SCSI diferencial
(mais tarde renomeado como diferencial de alta voltagem ou SCSI HVD) tinha o benefício de sensi-
bilidade reduzida a barulho elétrico e permitia comprimentos maiores de cabo, mas nunca tornou-se
popular no mercado convencional da computação. Uma implementação posterior, conhecida como
diferencial de baixa voltagem (LVD), finalmente infiltrou o mercado convencional e é um requisito
para velocidades de canal mais altas.
A largura de um canal SCSI não dita somente a quantidade de dados que pode ser transferida com cada
ciclo do relógio, mas também determina quantos dispositivos podem ser conectados a um canal. O
SCSI normal suporta 8 dispositivos endereçados unicamente, enquanto o SCSI largo suporta 16. Nos
dois casos, é necessário garantir que todos os dispositivos estejam ajustados para usar um único ID
SCSI. Dois dispositivos compartilhando um único ID causam problemas que podem levar à corrupção
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 também significa que, na
prática, 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 implementações SCSI inclui alguns meios de scanear o canal SCSI; isso é frequente-
mente usado para confirmar se todos os dispositivos estão configurados apropriadamente. Se o
scan de um canal retornar o mesmo dispositivo para todos os IDs SCSI, este dispositivo foi ajus-
tado incorretamente para o mesmo ID SCSI que o controlador SCSI. Para resolver este problema,
reconfigure o dispositivo para usar um ID SCSI diferente (e único).

Como a arquitetura do SCSI é orientada ao canal, é necessário terminar apropriadamente ambas


extremidades do canal. A terminação é feita ao alocar uma carga de impedância correta em cada
condutor que compõe o canal SCSI. A terminação é um requisito elétrico; sem ela, os diversos sinais
presentes no canal seriam perdidos pelas extremidades, distorcendo toda a comunicação.
Muitos (mas não todos) dispositivos SCSI vêm com terminadores internos que podem ser ativados ou
desativados usando interruptores ou jumpers. Terminadores externos também estão disponíveis.

5. A Rápida80 não representa uma mudança técnica na velocidade do canal; o canal de 40MHz foi mantido,
mas os dados foram inseridos no início e fim de cada pulso do relógio, efetivamente dobrando o output.
Capítulo 5. Administrando o Armazenamento 67

Uma última coisa para ter em mente sobre o SCSI — não é apenas um padrão de interface para
dispositivos de armazenamento em massa. Muitos outros dispositivos (como scanners, impressoras
e dispositivos de comunicação) usam SCSI. Apesar de serem menos comuns que os dispositivos de
armazenamento em massa SCSI, eles existem. No entanto, é provável 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 também estão começando suas incursões na arena do armazena-
mento em massa; no entanto, não existe nenhum dispositivo de armazenamento em massa USB ou
IEEE-1394 no momento. As ofertas de hoje são baseadas nos dispositivos ATA ou SCSI com circuito
de conversão externa.

Não importa qual interface um dispositivo de armazenamento em massa usa; o funcionamento interno
do dispositivo determina seu desempenho. A seção seguinte explora esta questão importante.

5.4. Características de Desempenho do Disco Rígido


As características de desempenho do disco rígido foram introduzidas na Seção 4.2.4. Esta seção
aborda a questão com maior profundidade. É importante que os administradores de sistemas a com-
preendam porque, sem o mínimo conhecimento básico de como os discos rígidos operam, é possível
alterar a configuração de seu sistema inadvertidamente de modo a impactar negativamente seu desem-
penho.
O tempo que leva para um disco rígido responder a e completar um pedido I/O depende de duas coisas:

• As limitações mecânicas e elétricas do disco rígido


• A carga I/O imposta pelo sistema
As seções seguintes exploram estes aspectos do desempenho do disco rígido com mais detalhes.

5.4.1. Limitações Mecânicas/Elétricas


Como os discos rígidos são dispositivos eletro-mecânicos, estão sujeitos a várias limitações em suas
velocidades e desempenhos. Todo pedido I/O requer que os vários componentes do disco trabalhem
juntos para satisfazê-lo. Já que cada um destes componentes têm características diferentes de desem-
penho, o desempenho geral do disco rígido é determinado pela soma do desempenho individual dos
componentes.
Entretanto, os componentes eletrônicos são pelo menos uma ordem de magnitude mais rápidos que
os componentes mecânicos. Portanto, são os componentes mecânicos que têm o maior impacto no
desempenho geral do disco rígido.

Dica
A maneira mais eficaz de melhorar o desempenho do disco rígido é reduzir sua atividade mecânica
o máximo possível.
68 Capítulo 5. Administrando o Armazenamento

O tempo médio de acesso de um disco rígido típico é aproximadamente 8,5 milissegundos. As seções
a seguir explicam melhor este número, mostrando como cada componente impacta no desempenho
geral do disco rígido.

5.4.1.1. Tempo de Processamento de Comandos


Todos os discos rígidos produzidos hoje têm sistemas integrados controlando sua operação. Estes
sistemas de computador executam as seguintes tarefas:

• Interação com o mundo externo através da interface do disco rígido


• Controle da operação do resto dos componentes do disco rígido e recuperação de quaisquer
condições de erro que possam ocorrer
• Processamento dos dados acessados da e gravados na mídia de armazenamento
Mesmo que os microprocessadores usados nos discos rígidos sejam relativamente poderosos, as tare-
fas atribuídas a estes levam tempo para serem completas. Em média, este tempo é próximo a 0,003
milissegundos.

5.4.1.2. Cabeças Acessando/Gravando Dados


As cabeças de acesso/gravação do disco rígido funcionam somente quando os pratos do disco sobre os
quais elas "voam" estão rodando. Como é o movimento da mídia sob as cabeças que permite acessar
ou ler os dados, o tempo que leva para a mídia contendo o setor desejado passar completamente por
baixo da cabeça é o único determinante da contribuição da cabeça para o tempo total de acesso. A
média é de 0,0086 milissegundos para um drive de 10.000 RPM com 700 setores por faixa.

5.4.1.3. Latência Rotacional


Como os pratos do disco rígido estão girando continuamente, quando o pedido I/O chega, é pouco
provável que o prato esteja exatamante no ponto certo de sua rotação para acessar o setor desejado.
Consequentemente, mesmo que o resto do disco esteja pronto para acessar aquele setor, é necessário
esperar até o prato girar, trazendo o setor desejado em posição sob a cabeça de acesso/gravação.
Este é o motivo pelo qual os discos rígidos de alto desempenho tipicamente giram seus pratos a ve-
locidades maiores. Hoje, as velocidades de 15.000 RPM são reservadas para os drives de desempenho
mais alto, enquanto 5.400 RPM é considerada adequada somente para drives de nível básico. A ve-
locidade média é de aproximadamente 3 milissegundos para um disco de 10.000 RPM.

5.4.1.4. Movimento do Braço de Acesso


Se há um componente dos discos rígidos considerado o Tendão de Aquiles, este é o braço de acesso.
O braço deve mover muito rápida e corretamente através de distâncias relativamente longas. Além
disso, o movimento do braço de acesso não é contínuo — deve acelerar rapidamente ao se aproximar
do cilindro desejado e então desacelerar rapidamente para evitar passar do ponto. Consequentemente,
o braço de acesso deve ser forte (para suportar as forças violentas provocadas pela necessidade de
movimentos rápidos) e leve ao mesmo tempo (para que haja menor massa para acelerar/desacelerar).
É difícil atingir estes objetivos conflitantes, fato demonstrado pelo tempo relativamente longo que o
movimento do braço de acesso leva quando comparado com o tempo que outros componentes levam.
Sendo assim, o movimento do braço de acesso é o fator determinante principal do desempenho geral
de um disco rígido; 5,5 milissegundos, em média.
Capítulo 5. Administrando o Armazenamento 69

5.4.2. Cargas I/O e Desempenho


Um outro fator que controla o desempenho do disco rígido é a carga I/O à qual o disco rígido é
submetido. Veja alguns dos aspectos específicos à carga I/O:

• A quantidade de acessos versus gravações


• O número de leitores/gravadores corrente
• A localidade dos acessos/gravações
Estas questões são abordadas em detalhes nas próximas seções.

5.4.2.1. Acessos Versus Gravações


No disco rígido comum usando mídia magnética para armazenamento de dados, o número de oper-
ações I/O de acesso (leitura) versus o número de operações I/O de gravação não é um fator preocu-
pante, já que acessar e gravar dados leva o mesmo tempo6. Entretanto, outras tecnologias de armazena-
mento em massa levam tempos diferentes para processar acessos e gravações 7 .
O impacto disso é que os dispositivos que levam um tempo mais longo para processar operações de
acesso I/O (por exemplo) são capazes de lidar com menos I/Os de gravação que I/Os de acesso. Ou
seja, uma I/O de gravação consome mais da habilidade do dispositivo em processar pedidos I/O que a
I/O de acesso.

5.4.2.2. Leitores/Gravadores Múltiplos


Um disco rígido que processa pedidos I/O a partir de fontes múltiplas tem uma carga diferente que
um disco rígido que atende aos pedidos I/O a partir de somente uma fonte. A principal razão deve-se
ao fato de que os solicitantes I/O múltiplos têm o potencial de trazer cargas I/O maiores para serem
conduzidas num disco rígido 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 necessário para esta determinação leva tempo, há um limite máximo para a
carga I/O que qualquer solicitante pode gerar— somente uma CPU mais rápida pode aumentá-lo. Esta
limitação 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 múltiplos. Contanto que haja
disponibilidade de energia suficiente da CPU para suportar o processamento necessário para gerar os
pedidos I/O, adicionar mais solicitantes I/O aumenta a carga I/O resultante.
No entanto, há outro aspecto que também influencia na carga I/O resultante. Isso é abordado na próx-
ima seção.

6. Esta não é uma verdade absoluta. Todos os discos rígidos incluem alguma quantidade de memória 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 fisicamente os dados pelo meio de armazenamento. Isso significa que, enquanto
o cache pode aliviar os problemas de desempenho de acesso I/O, nunca pode eliminar o tempo necessário para
acessar os dados fisicamente pelo meio de armazenamento.
7. Alguns drives de disco óptico apresentam este comportamento devido questões físicas das tecnologias usadas
para implementar o armazenamento de dados óptico.
70 Capítulo 5. Administrando o Armazenamento

5.4.2.3. Localidade de Acessos/Gravações


Apesar de não ser estritamente restrito a um ambiente multi-solicitante, este aspecto do desempenho
do disco rígido tende a aparecer mais neste tipo de ambiente. A questão é se os pedidos I/O feitos de
um disco rígido são de dados fisicamente próximos a outros dados que também estão sendo solicita-
dos.
A razão de sua importância torna-se aparente se a natureza eletromecânica do diso rígido é mantida
em mente. O componente mais lento de qualquer disco rígido é o braço de acesso. Sendo assim, se os
dados acessados pelos pedidos I/O de entrada não requerem movimentos do braço de acesso, o disco
rígido é capaz de atender mais pedidos I/O do que se os dados estivessem espalhados por todo o disco,
requerendo bastante movimento do braço de acesso.
Isto pode ser ilustrado ao observar as especificações de desempenho do disco rígido. Estas especi-
ficações frequentemente incluem tempos de busca ao cilindro adjacente (onde o braço de acesso é
pouco movido — somente para o próximo cilindro), e tempos de busca com força total (onde o braço
de acesso é movido do primeiro cilindro ao último). Por exemplo: aqui estão os tempos de busca de
um disco rígido de alto desempenho:

Cilindro Adjacente Força Total


0.6 8.2
Tabela 5-4. Tempos de Busca ao Cilindro Adjacente e com Força Total (em Milissegundos)

5.5. Tornando o Armazenamento Utilizável


Uma vez estabelecido um dispositivo de armazenamento em massa, há poucos fins para utilizá-lo. É
verdade que os dados podem ser gravados neste e acessados deste, mas sem nenhuma estrutura básica,
o acesso de dados só é possível ao usar endereços de setor (geométricos ou lógicos).
São necessários métodos para facilitar a utilização do armazenamento não-processado provido pelo
disco rígido. As seções seguintes exploram algumas técnicas comumente usadas para fazer isso.

5.5.1. Partições/Fatias
Frequentemente, a primeira coisa que intriga um administrador de sistemas é que o tamanho do disco
rígido pode ser bem maior que o necessário para uma determinada tarefa. Como resultado, muitos
sistemas operacionais têm a capacidade de dividir o espaço de um disco rígido em várias partições ou
fatias.
Como são separadas umas das outras, as partições podem ter quantidades de espaço utilizado difer-
entes, e o espaço utilizado de uma partição não tem impacto na outra. Por exemplo: a partição con-
tendo os arquivos que compoem o sistema operacional não é afetada pela partição contendo os ar-
quivos do usuário, mesmo se esta estiver cheia. O sistema operacional continua com espaço livre para
seu próprio uso.
Apesar de ser um pouco simplista, você pode pensar nas partições como se fossem drives de disco
separados. De fato, alguns sistemas operacionais referem-se às partições como "drives". No entanto,
este ponto de vista não é totalmente correto; portanto é importante entendermos melhor as partições.

5.5.1.1. Atributos das Partições


As partições são definidas pelos seguintes atributos:
Capítulo 5. Administrando o Armazenamento 71

• Geometria da partição
• Tipo da partição
• Campo do tipo da partição
Estes atributos são explorados com mais detalhes nas seções a seguir.

5.5.1.1.1. Geometria
A geometria de uma partição refere-se à sua localização física num disco rígido. A geometria pode
ser especificada em termos de cilindros inicial e final, cabeças e setores, mas geralmente as partições
começam e terminam nos limites dos cilindros. O tamanho de uma partição é então definido como a
quantidade de armazenamento entre os cilindros inicial e final.

5.5.1.1.2. Tipo da Partição


O tipo da partição refere-se à sua relação com as outras partições no disco rígido. Há três tipos difer-
entes de partições:

• Partições primárias
• Partições extendidas
• Partições lógicas
Veja a descrição de cada tipo de partição nas próximas seções.

5.5.1.1.2.1. Partições Primárias


As partições primárias são aquelas que ocupam um dos quatro slots primários na tabela de partições
do disco rígido.

5.5.1.1.2.2. Partições Extendidas


As partições extendidas foram desenvolvidas em resposta à necessidade de existir mais de quatro par-
tições num disco rígido. Uma partição extendida pode conter diversas partições nela mesma, aumen-
tando significativamente o número de partições possíveis num único disco. A introdução das partições
extendidas foi movida pelas sempre crescentes capacidades de novos drives de disco.

5.5.1.1.2.3. Partições Lógicas


As partições lógicas são aquelas contidas numa partição extendida. Em termos de uso, são iguais a
uma partição primária não-extendida.

5.5.1.1.3. Campo do Tipo da Partição


Cada partição tem um campo de tipo que contém um código indicando seu uso antecipado. O campo
do tipo pode ou não refletir o sistema operacional do computador, mas reflete como os dados devem
ser armazenados dentro da partição. A seção seguinte contém mais informações sobre isso.
72 Capítulo 5. Administrando o Armazenamento

5.5.2. Sistemas de Arquivo


Mesmo tendo o dispositivo de armazenamento em massa apropriado, configurado corretamente e
particionado apropriadamente, não poderíamos armazenar e recuperar informações facilmente — falta
uma maneira de estruturar e organizar estas informações. Precisamos de um sistema de arquivo.
O conceito de um sistema de arquivo é tão fundamental para o uso dos dispositivos de armazenamento
em massa, que o usuário comum de computador geralmente não distingue um do outro. Entretanto,
os administradores de sistemas não podem ignorar os sistemas de arquivo e seu impacto no trabalho
do dia-a-dia.
Um sistema de arquivo é um método de representação de dados num dispositivo de armazenamento
em massa. Os sistemas de arquivo geralmente possuem as seguintes características:

• Armazenamento de dados baseado em arquivos


• Estrutura hierárquica de diretório (às vezes chamada de "pasta")
• Registro de criação de arquivos, hora de acessos e de modificações.
• Algum nível de controle sobre o tipo de acesso permitido a um determinado arquivo
• Alguns conceitos sobre propriedade de arquivos (file ownership)
• Contabilidade do espaço utilizado
Nem todos os sistemas de arquivo possuem todas estas características. Por exemplo: um sistema de
arquivo construído para um sistema operacional com um usuário único poderia facilmente utilizar um
método de controle de acesso simplificado, 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 diária. Ao garantir que o sistema de arquivo usado na sua empresa atende aos
seus requisitos funcionais, você pode assegurar não somente que o sistema de arquivo é apropriado
para a tarefa, mas também que é mais fácil e eficientemente mantido.
Com isso em mente, as seções seguintes exploram estas características mais a fundo.

5.5.2.1. Armazenamento Baseado em Arquivo


Apesar dos sistemas de arquivo que usam a metáfora do arquivo para armazenamento de dados serem
quase tão universais a ponto de não serem valorizados, ainda há alguns aspectos a serem considerados.
Primeiro, deve-se estar ciente de quaisquer restrições nos nomes dos arquivos. Por exemplo: quais
os caracteres permitidos nos nomes de arquivos? Qual o tamanho máximo para o nome do arquivo?
Estas questões são importantes, já que ditam os nomes de arquivos que podem ou não ser usados. Sis-
temas operacionais mais antigos com sistemas de arquivos mais primitivos frequentemente permitiam
somente caracteres alfanuméricos (em caixa alta) e nomes de arquivo 8.3 tradicional (um nome de
arquivo de 8 caracteres, seguido por uma extensão de arquivo de 3 caracteres).

5.5.2.2. Estrutura Hierárquica de Diretório


Enquanto os sistemas de arquivo usados em alguns sistemas operacionais muito antigos não incluíam
o conceito de diretórios, todos os sistemas de arquivo comumente usados hoje incluem esta caracterís-
tica. Os próprios diretórios são implementados como arquivos; o que significa que não é necessário
nenhum utilitário especial para mantê-los.
Além disso, como os diretórios são arquivos em si, e contém arquivos, também podem conter outros
diretórios, possibilitando uma hierarquia de diretórios multi-nível. Este é um conceito essencial com
o qual todos os administradores de sistemas devem ser famliarizados - usar hierarquias de diretórios
multi-nível pode facilitar a administração de arquivos para você e seus usuários.
Capítulo 5. Administrando o Armazenamento 73

5.5.2.3. Registro de Criação, Acessos e Hora de Modificação de Arquivos


A maioria dos sistemas de arquivo mantém o registro da hora na qual o arquivo foi criado; alguns
também registram a hora de modificação e de acesso. Além da conveniência de poder determinar
quando um determinado arquivo foi criado, acessado ou modificado, estas datas são vitais para a
operação apropriada de backups adicionais.
Mais informações sobre como os backups utilizam estas características do sistema de arquivo podem
ser encontradas na Seção 8.2.

5.5.2.4. Controle de Acesso


O controle de acesso é uma área na qual os sistemas de arquivo diferem drasticamente. Alguns sis-
temas de arquivo não têm um modelo de controle simples, enquanto outros são bem mais sofistica-
dos. Em termos gerais, os sistemas de arquivo mais modernos combinam dois componentes numa
metodologia de controle de acesso coesa:

• Identificação do usuário
• Lista de ações permitidas
Identificação do usuário significa que o sistema de arquivo, e seu sistema operacional, devem ser
capazes de identificar unicamente usuários individuais. Isso possibilita ter responsabilidade total em
relação a qualquer operação a nível do sistema. Uma outra característica muitas vezes útil é a dos
grupos de usuários — criar conjuntos de usuários conforme as necessidades. Os grupos são geralmente
mais usados por empresas nas quais os usuários podem ser membros de um ou mais projetos. Uma
outra característica suportada por alguns sistemas de arquivo é a criação de identificadores genéricos
que podem ser atribuídos a um ou mais usuários.
Em seguida, o sistema de arquivo deve ser capaz de manter listas de ações permitidas (ou proibidas)
em cada arquivo. As ações mais comuns são:

• Acessar (ler) o arquivo


• Gravar (escrever no) arquivo
• Executar o arquivo
Vários sistemas de arquivo talvez extendam a lista para incluir outras ações como exclusão (deleção),
ou até mesmo a habilidade de alterar opções no controle de acesso de um arquivo.

5.5.2.5. Contabilidade do Espaço Utilizado


Uma constante na vida de um administrador de sistemas é que nunca há espaço livre suficiente e, se
houver, não permanecerá assim por muito tempo. Sendo assim, um administrador de sistemas deve
pelo menos determinar facilmente o nível de espaço livre disponível para cada sistema de arquivo.
Além disso, os sistemas de arquivo com capacidades de identificação de usuários bem definidas,
geralmente incluem a capacidade de exibir a quantidade de espaço consumido por um determinado
usuário.
Esta funcionalidade é vital em ambientes grandes de multi-usuários, já que infelizmente a regra 80/20
geralmente se aplica ao espaço em disco — 20 porcento de seus usuários serão responsáveis por
consumir 80 porcento do seu espaço disponível em disco. Ao determinar quais usuários estão nestes
20 porcento, fica mais fácil administrar seus bens de armazenamento efetivamente.
Levando isso mais adiante, alguns sistemas de arquivo incluem a habilidade de determinar limites
por usuário (geralmente conhecidos como quotas de disco) sobre a quantidade de espaço em disco
que pode ser consumida. As especificações podem variar em diferentes sistemas de arquivo, mas em
geral é possível atribuir a cada usuário uma determinada quantidade de armazenamento. Além disso,
74 Capítulo 5. Administrando o Armazenamento

vários sistemas de arquivo diferem. Alguns permitem ao usuário exceder seu limite somente uma vez,
enquanto outros implementam um "período de carência", durante o qual um segundo limite é aplicado.

5.5.3. Estrutura de Diretório


Muitos administradores de sistemas não se importam como o armazenamento disponibilizado hoje
será usado pelos seus usuários amanhã. No entanto, um pouco de foco nesta questão, antes de disponi-
bilizar o armazenamento para os usuários, pode poupar bastante esforço desnecessário no futuro.
A principal coisa que o administrador deve fazer é usar os diretórios e sub-diretórios para estruturar o
armazenamento disponível de maneira inteligível. Há diversos benefícios nesta tática:

• Mais fácilmente entendido


• Mais flexibilidade no futuro
Ao forçar um certo nível de estrutura no seu armazenamento, este pode ser mais facilmente entendido.
Por exemplo: considere um grande sistema de multi-usuários. Ao invés de inserir todos os diretórios
dos usuários em um diretório grande, pode fazer mais sentido usar sub-diretórios que espelham a es-
trutura de sua empresa. Dessa maneira, as pessoas que trabalham na contabilidade têm seus diretórios
sob um outro diretório chamado contabilidade, as pessoas que trabalham na engenharia teriam
seus diretórios sob engenharia e assim por diante.
O benefício dessa tática é a facilidade de manter o registro diário de necessidades (e uso) do armazena-
mento de cada parte da sua empresa. Obter uma lista de arquivos usados por todos os funcionários dos
recursos humanos é simples. Fazer o backup de todos os arquivos usados pelo departamento jurídico
é fácil.
Com a estrutura apropriada, a flexibilidade 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 serão contratados em breve. Entretanto, no momento não há
armazenamento livre disponível para suportar as adições esperadas à engenharia.
Mas, como todas as pessoas da engenharia têm seus arquivos armazenados sob o diretório
engenharia, será um processo simples para:

• Adquirir o armazenamento adicional necessário para suportar a engenharia


• Fazer backup de tudo sob o diretório engenharia
• Restaurar o backup para o novo armazenamento
• Renomear o diretório engenharia no armazenamento original para algo como
engenharia-arquivo (antes de apagá-lo inteiramente e após trabalhar sem problemas com a
nova configuração por um mês)
• Fazer as alterações necessárias para que todo o pessoal de engenharia possa acessar seus arquivos
no novo armazenamento
Obviamente, essa tática também tem suas desvantagens. Por exemplo: se as pessoas mudam de depar-
tamentos com frequência, você deve ter uma maneira de manter-se informado sobre estas transferên-
cias e então modificar a estrutura de diretório de acordo. Caso contrário, a estrutura não mais refletirá
a realidade, aumentando o seu trabalho — e não 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á disponível para o uso geral.
Capítulo 5. Administrando o Armazenamento 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 imedi-
atamente sem nenhum esforço 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 nor-
mal do armazenamento é feita através de um utilitário ou programa especial e requer que o dispositivo
de aremazenamento em massa (e possivelmente a partição também) seja explicitamente identificada.

5.6. Tecnologias de Armazenamento Avançado


Apesar de tudo ser apresentado neste capítulo referenciando somente discos rígidos simples dire-
tamente ligados a um sistema, há outras opções mais avançadas que você pode explorar. A seções
seguintes descrevem algumas das táticas mais comuns para expandir as opções de seu armazenamento
em massa.

5.6.1. Armazenamento Acessível via Rede


Combinar as tecnologias de rede com o armazenamento em massa pode resultar em grande flexibili-
dade para administradores de sistemas. Há dois benefícios atingíveis com esse tipo de configuração:

• Consolidação do armazenamento
• Administração simplificada
O armazenamento pode ser consolidado ao empregar servidores de alto desempenho com conectivi-
dade de rede de alta velocidade e configurados com grandes quantidades de armazenamento rápido.
Com uma configuração apropriada, é possível prover acesso ao armazenamento a velocidades com-
paráveis com o armazenamento local. Sendo assim, a natureza compartilhada de tal configuração
frequentemente possibilita reduzir custos, já que os gastos de um armazenamento compartilhado cen-
tralizado podem ser menores que os gastos do armazenamento equivalente para cada um dos clientes.
Além disso, o espaço livre é consolidado, ao invés de estar espalhado (e não amplamente utilizável)
pelos diversos clientes.
Os servidores de armazenamento centralizado também podem facilitar muitas tarefas administrativas.
Por exemplo: monitorar o espaço livre é bem mais fácil quando o armazenamento a ser monitorado
existe num servidor de armazenamento centralizado. Os backups podem ser bastante simplificados
usando um servidor de armazenamento centralizado. É possível efetuar backups da rede para clientes
múltiplos, mas requerem mais trabalho para configurar e manter.
Há diversas tecnologias de armazenamento em rede disponíveis; escolher uma pode ser uma tarefa
difícil. Quase todos os sistemas operacionais do mercado de hoje incluem alguns meios de acessar o
armazenamento acessível pela rede, mas as diferentes tecnologias não são compatíveis umas com as
outras. Qual é a melhor tática para determinar a tecnologia a empregar?
A tática que geralmente traz os melhores resultados é deixar as capacidades embutidas do cliente
decidirem a questão. Há inúmeras razões para isso:

• Problemas minimizados com a integração de clientes


• Trabalho minimizado em cada sistema cliente
• Baixo custo inicial por cliente
Tenha em mente que todas as questões relativas aos clientes são multiplicadas pelo número de clientes
de sua empresa. Ao utilizar as capacidades embutidas dos clientes, você não precisa instalar nenhum
software adicional em cada cliente (custo adicional zero com a compra de software). E você também
tem a melhor chance de obter um bom suporte e integração com o sistema operacional do cliente.
76 Capítulo 5. Administrando o Armazenamento

No entanto, há uma desvantagem. Isso significa que o ambiente de servidor deve estar apto a prover um
bom suporte para as tecnologias de armazenamento acessíveis pela rede requisitadas pelos clientes.
Nos casos em que os sistemas operacionais do servidor e dos clientes são um e o mesmo, normalmente
não há prolemas. Caso contrário, será necessário investir tempo e trabalho em fazer com que o servidor
"fale" a linguagem dos clientes. Entretranto, essa desvantagem é geralmente justificável.

5.6.2. Armazenamento Baseado no RAID


Uma habilidade a ser cultivada pelo administrador de sistemas é poder olhar para configurações de
sistemas complexos e observar as deficiências inerentes de cada configuração. Apesar de, à primeira
vista, este parecer um ponto de vista negativo, pode ser uma grande maneira de analisar além das
caixas brilhantes e visualizar uma noite de sábado com toda a produção derrubada devido uma falha
que poderia ser facilmente evitada com um pouco de precaução.
Com isso em mente, vamos usar o que sabemos agora sobre o armazenamento baseado no disco
e verificar 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 partições tem uma pane geral: o que acontece com os dados contidos
nestas partições?
Ficam imediatamente indisponíveis (pelo menos até que a unidade falha possa ser substituída e os
dados recuperados de um backup recente).
Um drive de disco com uma única partição está operando em seus limites devido a enormes cargas
I/O: o que acontece com as aplicações que requerem acesso aos dados dessa partição?
As aplicações ficam lentas pois o drive de disco não pode processar os acessos e gravações 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 então?
O drive de disco é totalmente preenchido, o arquivo de dados para de aumentar e suas aplicações
associadas param de rodar.
Apenas um destes problemas poderia incapacitar um centro de dados, mesmo assim os
administradores precisam enfrentar esse tipo de situação todos os dias. O que pode ser feito?
Felizmente, há uma tecnologia que pode resolver cada uma destas questões. O nome dessa tecnologia
é RAID.

5.6.2.1. Conceitos Básicos


RAID é um acrônimo para Redundant Array of Independent Disks (Conjunto Redundante de Discos
Independentes)8 . Como o nome implica, RAID é uma maneira para que drives múltiplos de disco
atuem como se fossem um único drive de disco.
As técnicas RAID foram primeiramente desenvolvidas por pesquisadores da Universidade de Berke-
ley, Califórnia, em meados dos anos 80. Ao mesmo tempo, havia uma diferença maior de preço entre
os drives de disco de alto desempenho usados em grandes instalações de computadores da época, e
drives de disco menores e mais lentos usados nos idos da indústria da computação. O RAID era visto
como um método de substituir uma unidade de drive de disco cara por diversos drives de disco mais
baratos.

8. No início das pesquisas sobre o RAID, o acrônimo significava 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 significado da comparação de preços.
Capítulo 5. Administrando o Armazenamento 77

Ainda mais importante: os conjuntos RAID podem ser construídos de diversas maneiras, resultando
em características diferentes dependendo da configuração final. Vamos observar as diferentes config-
urações (conhecidos como níveis do RAID) com mais detalhes.

5.6.2.1.1. Níveis do RAID


Os pesquisadores de Berkeley originalmente definiram cinco níveis diferentes do RAID e os numer-
aram de "1" a "5." Além disso, níveis adicionais do RAID foram definidos por outros pesquisadores
e membros da indústria de armazenamento. Nem todos os níveis do RAID eram igualmente úteis;
alguns interessavam somente aos propósitos dos pesquisadores, enquanto outros não eram economi-
camente viáveis.
No final, apenas três níveis do RAID foram adotados para o uso geral:

• Nível 0
• Nível 1
• Nível 5
As seções seguintes abordam cada um destes níveis em detalhes.

5.6.2.1.1.1. RAID 0
A configuração de disco conhecida como RAID nível 0 é um pouco confusa, já que é o único nível do
RAID que não emprega nenhuma redundância. No entanto, mesmo que o RAID 0 não tenha vantagens
sob o aspecto de confiabilidade, possui outros benefícios.
Um conjunto RAID 0 consiste de dois ou mais drives de disco. A capacidade de armazenamento de
cada drive é dividida em pedaços, que representam alguns múltiplos do tamanho de bloco nativo do
drive. Os dados são gravados, pedaço por pedaço, em cada drive do conjunto. Os pedaços podem ser
encarados como tiras (stripes, em inglês) 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 pedaços com 4KB de tamanho, gravar 12KB de dados
no conjunto resultaria na gravação de três pedaços de 4KB nos seguintes drives:

• Os primeiros 4KB seriam gravados no primeiro pedaço do primeiro drive


• Os 4KB seguintes seriam gravados no primeiro pedaço do segundo drive
• Os últimos 4KB seriam gravados no segundo pedaço 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 construídos para serem maiores que um
drive de disco único, facilitando armazenar maiores arquivos de dados
• Melhor desempenho de acesso/gravação — A carga I/O num conjunto RAID 0 é espalhada igual-
mente por todos os drives do conjunto (assuimndo que todas I/O não estejam concentradas num
único pedaço)
• Sem espaço desperdiçado — Todo o armazenamento de todos os drives do conjunto estão
disponíveis para o armazenamento de dados
Comparado a um drive de disco único, o RAID 0 tem a seguinte desvantagem:

• Menos confiabilidade — Todo drive de um conjunto de RAID 0 deve estar operante para o conjunto
estar disponível. Uma única falha no conjunto RAID 0 drive-N resulta na remoção de 1/N de todos
os dados, inutilizando o conjunto
78 Capítulo 5. Administrando o Armazenamento

Dica
Se você tiver problemas em memorizar os diferentes níveis do RAID, lembre-se apenas que o RAID
0 tem zero porcento de redundância.

5.6.2.1.1.2. RAID 1
O RAID 1 usa dois (apesar de algumas implementações suportarem mais) drives de disco idênticos.
Todos os dados são gravados nos dois drives, tornando-os imagem espelho um do outro. Por isso, o
RAID 1 é comumente conhecido como mirroring.
Sempre que os dados são gravados num conjunto de RAID 1, ocorrem duas gravações físicas: 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 redundância — Mesmo se um drive do conjunto falhar, os dados ainda estarão acessíveis
• 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 máximo do conjunto é limitado pelo maior drive disponível.


• Desempenho de gravação reduzido — Como os dois drives devem ser mantidos atualizados, todas
as I/Os devem ser desempenhadas pelos dois drives, atrasando o processo geral de gravação de
dados no conjunto
• Relação custo/eficiência reduzida — Com um drive inteiro dedicado à redundância, o custo de um
conjunto de RAID 1 é, no mínimo, o dobro de um único drive

Dica
Se você tiver problemas em memorizar os diferentes níveis do RAID, lembre-se que o RAID 1 tem
cem porcento de redundância.

5.6.2.1.1.3. RAID 5
O RAID 5 tenta combinar os benefícios do RAID 0 e do RAID 1 e minimizar suas respectivas desvan-
tagens.
Como o RAID 0, um conjunto de RAID 5 consiste de drives de discos múltiplos, cada um dividido
em pedaços. 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 espaço do disco de maneira
redundante, aumentando a confiabilidade.
Entretanto, o modo de operação do RAID 5 é diferente do RAID 0 e do RAID 1.
Um conjunto de RAID 5 deve consistir de, no mínimo, três drives de disco de tamanho idêntico (talvez
mais drives sejam usados). Cada drive é dividido em pedaços e os dados são gravados nos pedaços em
ordem. No entanto, nem todo pedaço é dedicado ao armazenamento de dados como no RAID 0. Ao
invés disso, num conjunto com n drives de disco, todo pedaço de número n é dedicado à paridade.
Capítulo 5. Administrando o Armazenamento 79

Os pedaços contendo paridade possibilitam recuperar dados caso um dos drives do conjunto falhe.
A paridade no pedaço x é calculada combinando matematicamente os dados de cada pedaço x ar-
mazenado em todos os drives do conjunto. Se os dados de um pedaço são atualizados, o pedaço de
paridade correspondente deve ser recalculado e atualizado também.
Isso também significa que, cada vez que os dados são gravados no conjunto, pelo menos dois drives
são gravados: o drive contendo os dados e o drive contendo o pedaço de paridade.
Uma coisa importante para ter em mente é que os pedaços de paridade não estão concentrados em nen-
hum drive do conjunto, mas estão espalhados igualmente por todos os drives. Apesar de ser possível
dedicar um drive específico para conter apenas paridade (de fato, esta configuração é conhecida como
RAID nível 4), a atualização constante da paridade conforme os dados são gravados no conjunto pode
transformar o drive de paridade num gargalo de desempenho. Ao espalhar as informações 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 informações de paridade sejam espalhadas igualmente por todos os drives
do conjunto, a quantidade de armazenamento disponível é reduzida para o tamanho de um drive.
Comparado a um drive de disco único, o conjunto de RAID 5 tem as seguintes vantagens:

• Mais redundância — Se um drive do conjunto falhar, as informações de paridade podem ser usadas
para reconstruir os pedaços de dados faltando, enquanto mantém-se o conjunto disponível para uso 9
• Melhor desempenho de acesso — Devido sua semelhança com o RAID 0, os dados são divididos
entre os drives do conjunto e a atividade de acesso I/O é espalhada igualmente por todos os drives
• Relação custo/eficiência razoavelmente boa — Em um conjunto de RAID 5 com n drives, somente
1/n do armazenamento total é dedicado à redundância.
Comparado a um drive único, um conjunto de RAID 5 tem a seguinte desvantagem:

• Desempenho de gravação reduzido — Como cada gravação no conjunto resulta em pelo menos duas
gravações nos drives físicos (uma gravação para os dados e outra para a paridade), o desempenho
de gravação é pior do que num drive único10

5.6.2.1.1.4. Níveis Embutidos do RAID


A partir da abordagem dos vários níveis do RAID, fica claro que cada nível tem suas próprias van-
tagens e desvantagens. Pouco tempo depois que o armazenamento baseado no RAID começou a ser
usado, as pessoas começaram a pensar em combinar os diferentes níveis do RAID, produzindo con-
juntos com todas as vantagens e nenhuma desvantagem dos níveis 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 confiabilidade do RAID 1.
Esse é o tipo de coisa que pode ser feita. Aqui estão os níveis embutidos de RAID mais comuns:

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

9. O desempenho I/O é reduzido enquanto operar com um drive indisponível, devido à sobrecarga envolvida na
reconstrução dos dados faltantes.
10. Também há impacto dos cálculos de paridade necessários para cada gravação. Mas, dependendo da imple-
mentação específica do RAID 5 (especialmente, em que localidade do sistema os cálculos de paridade ocorrem),
este impacto pode variar de um tamanho considerável a quase inexistente.
80 Capítulo 5. Administrando o Armazenamento

Como o RAID embutido é usado em ambientes mais especializados, não 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 níveis do RAID são embutidos pode ter um grande impacto
na confiabilidade. Em outras palavras, o RAID 1+0 e o RAID 0+1 não são o mesmo.
• Os custos podem ser altos — Se há alguma desvantagem comum a todas as implementações embu-
tidas de RAID, essa é o custo. Por exemplo: o menor conjunto de RAID 5+1 consiste de seis drives
de disco (são necessários ainda mais drives para conjuntos maiores).
Agora que explicamos os conceitos por trás do RAID, vejamos como pode ser implementado.

5.6.2.1.2. Implementações do RAID


Em comparação com as seções anteriores, é óbvio que o RAID requer mais "conhecimento" que o
processamento I/O de disco comum para drives individuais. No mínimo, 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 ações caso um deles falhar
• Controlar a recriação de um disco separado no conjunto, quando este disco for substituído ou
reparado
• Prover uma maneira para os administradores manterem o conjunto (remover ou adicionar drives,
iniciar e terminar recriações, etc.)
Há dois métodos principais que podem ser usados para completar estas tarefas. As próximas duas
seções descrevem-nos em detalhes.

5.6.2.1.2.1. RAID de Hardware


Uma implementação de RAID de hardware geralmente toma a forma de uma placa especializada
de controle do disco. A placa executa todas as funções 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 máquina.
A maioria das placas de controlador de RAID funcionam com drives SCSI, mas há também contro-
ladores RAID baseados na ATA. Em qualquer caso, a interface administrativa é geralmente imple-
mentada de uma destas três maneiras:

• Utilitários especializados, que rodam como aplicações sob o sistema operacional da máquina, ap-
resentando uma interface de software à placa do controlador
• Uma interface da placa usando uma porta serial, que é acessada através de um emulador de terminal
• Uma interface parecida com o BIOS, acessível somente durante o teste de inicialização do sistema
Alguns controladores RAID têm mais de um tipo de interface administrativa. Por motivos óbvios, uma
interface de software provém mais flexibilidade, já que permite funções administrativas enquanto o
sistema operacional está rodando. No entanto, se você inicializar um sistema operacional a partir de
um controlador RAID, é necessária uma interface que não requer um sistema operacional rodando.
Como há diversas placas de controlador RAID diferentes no mercado, é impossível entrar em mais
detalhes aqui. O melhor a fazer é ler a documentação do fabricante para mais informações.
Capítulo 5. Administrando o Armazenamento 81

5.6.2.1.2.2. RAID de Software


O RAID de software é o RAID implementado como um kernel - ou software de nível de driver
para um sistema operacional específico. Como tal, provém mais flexibilidade em termos de suporte
a hardware — desde que o hardware seja suportado pelo sistema operacional, os conjuntos RAID
podem ser configurados 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 disponível para os cálculos de paridade do RAID de
software excede o poder de processamento presente numa placa de controlador RAID. Consequente-
mente, algumas implementações de RAID de software têm, na verdade, a capacidade de desempenho
superior que implementações de RAID de hardware.
Entretanto, o RAID de software tem limitações 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 inicialização, já que o BIOS do
computador não sabe do RAID. Como um drive único de um conjunto de RAID 1 é indiferenciável
de um dispositivo de inicialização não-RAID, o BIOS pode iniciar o processo de inicialização; então,
o sistema operacional pode alternar para a operação de RAID de software quando obtiver o controle
do sistema.

5.6.3. Administração de Volume Lógico (Logical Volume Management)


Uma outra tecnologia avançada de armazenamento é a administração de volume lógico (logical vol-
ume management - LVM). O LVM possibilita tratar dispositivos físicos de armazenamento em massa
como blocos de construção de nível baixo, nos quais são criadas configurações de armazenamento
diferentes. As capacidades exatas variam de acordo com a implementação específica, mas podem
incluir agrupamento de armazenamento físico, redimensionamento de volume lógico e migração de
dados.

5.6.3.1. Agrupamento de Armazenamento Físico


Apesar do nome dado a esta capacidade variar, o agrupamento de armazenamento físico é a base de
todas as implementações do LVM. Como o nome implica, os dispositivos físicos de armazenamento
em massa podem ser agrupados de maneira a criar um ou mais dipositivos lógicos de armazenamento
em massa. Os dispositivos lógicos de armazenamento em massa (ou volumes lógicos) podem ter
capacidade maior que a maior capacidade de qualquer um dos dispositivos físicos de armazenamento
em massa que compõe o volume.
Por exemplo: dados dois drives de 100GB, pode-se criar um volume lógico de 200GB. No entanto,
também pode-se criar um volume lógico de 150GB e um de 50GB. Qualquer combinação de volumes
lógicos igual ou menor que a capacidade total (200GB nestes exemplo) é possível. As alternativas são
limitadas apenas pelas necessidades da sua empresa.
Isso possibilita a um administrador de sistemas tratar todo o armazenamento como parte de um con-
junto, disponível para uso em qualquer quantidade. Além disso, os drives podem ser adicionados
posteriormente ao conjunto, facilitando o processo de antecipar a demanda de armazenamento de
seus usuários.

5.6.3.2. Redimensionamento do Volume Lógico


A característica do LVM admirada pela maioria dos administradores de sistemas é sua habilidade em
direcionar armazenamento facilmente onde é necessário. Numa configuração de sistema sem LVM,
estar sem espaço significa — no melhor dos casos — mover arquivos do dispositivo cheio para outro
82 Capítulo 5. Administrando o Armazenamento

com espaço disponível. Isto pode significar reconfigurar os dispositivos de armazenamento em massa
de seu sistema; uma tarefa a ser executada após o horário comercial.
Entretanto, o LVM possibilita aumentar o tamanho de um volume lógico. Assuma por um momento
que nosso conjunto de armazenamento de 200GB foi usado para criar um volume lógico de 150GB,
com os 50GB restantes na reserva. Se o volume lógico de 150GB ficar cheio, o LVM possibilita
aumentar esse tamanho (digamos em 10GB) sem nenhuma reconfiguração física. Dependendo do
ambiente do sistema operacional, pode ser possível fazer isso dinamicamente ou pode ser necessário
deixar o sistema fora do ar por pouco tempo para executar o redimensionamento.

5.6.3.3. Migração de Dados


A maioria dos administradores de sistemas experientes ficariam impressionados com as capacidades
do LVM, mas também se perguntaria a seguinte questão:
O que acontece se um dos drives que compõe o volume lógico começa a falhar?
A boa notícia é que a maioria das implementações do LVM incluem a habilidade de migrar dados
de um drive físico específico. Para que isso funcione, deve haver capacidade reserva suficiente para
absorver a perda do drive falho. Uma vez completa a migração dos dados, o drive falho pode ser
substituído ou trazido de volta ao conjunto de armazenamento disponível.

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 não po-
dem ser atingidas pelas maioria das implementações do RAID (como a habilidade de adicionar ar-
mazenamento 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 são tecnologias complementares que
podem ser usadas em conjunto (similar ao uso dos níveis embutidos do RAID), possibilitando obter o
melhor de cada uma.

5.7. Administração Diária do Armazenamento


Os administradores de sistemas devem estar atentos ao armazenamento no curso de suas rotinas
diárias. Há diversas questões para ter em mente:

• Monitorar espaço livre


• Questões de quota de disco
• Questões relativas a arquivos
• Questões relativas a diretórios
• Questões relativas a backups
• Questões relativas a desempenho
• Adicionando/removendo armazenamento
As seções seguintes abordam cada uma destas questões com detalhes.
Capítulo 5. Administrando o Armazenamento 83

5.7.1. Monitorando Espaço Livre


Garantir que haja suficiente espaço livre disponível deve estar no topo da lista de tarefas diárias de um
administrador de sistemas. A razão da verificação frequente e regular do espaço livre é tão importante
porque o espaço livre é muito dinâmico; pode haver mais do que o espaço suficiente num momento, e
praticamente nenhum em seguida.
Em geral, há três razões para espaço livre insuficiente:

• Uso excessivo por um usuário


• Uso excessivo por uma aplicação
• Crescimento normal de uso
Estas razões são abordadas em detalhes nas próximas seções.

5.7.1.1. Uso Excessivo por um Usuário


Pessoas diferentes têm níveis diferentes de organização. Algumas pessoas ficariam aterrorizadas em
ver um pouco de pó sobre uma mesa, enquanto outras não 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 são muito frugais no uso de seu armazenamento e nunca largam arquivos
desnecessários por aí.
• Algumas pessoas parecem nunca encontrar tempo para livrar-se dos arquivos de que não mais
precisam.
Muitas vezes, quando um usuário usa grandes quantidades de armazenamento, o segundo tipo de
pessoa é a responsável.

5.7.1.1.1. Resolvendo o Uso Excessivo por um Usuário


Essa é uma área na qual o administrador de sistemas precisa usar toda a diplomacia e habilidades
sociais que puder obter. Frequentemente, as discussões sobre espaço em disco tornam-se emocionais,
já que as pessoas encaram as restrições de uso do disco como um fator limitante para seu trabalho,
dizem que as restrições são pequenas ou que simplesmente não têm tempo de fazer uma limpeza em
seus arquivos.
Os melhores administradores de sistemas consideram muitos fatores numa situação como essa. As
restrições são razoáveis e justas para o tipo de trabalho que essa pessoa executa? Essa pessoa parece
usar seu espaço 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 alguém que não precisa de tanto espaço esteja limpando seus arquivos.
Em qualquer dos casos, a melhor coisa a fazer é manter uma conversa em nível profissional e fac-
tual. Tente resolver os problemas do usuário de uma maneira educada ("Eu entendo que você esteja
muito ocupado, mas todos em seu departamento têm a mesma responsabilidade em não desperdiçar
espaço de armazenamento, e a média de uso é menos que a metade do seu.") enquanto encaminha a
conversa para a questão. Certifique-se de oferecer ajuda caso a falta de conhecimento/experiência for
um problema.
Lidar com a situação de maneira sensível porém firme, geralmente é melhor que usar sua autori-
dade como administrador de sistemas para forçar um resultado. Por exemplo: talvez você acredite ser
necessária uma concessão entre você e o usuário. Essa concessão pode ter uma destas três formas:

• Prover espaço temporário


• Criar backups de arquivamento
84 Capítulo 5. Administrando o Armazenamento

• Desistir
Talvez você acredite que o usuário possa reduzir seu uso se tiver alguma quantidade de espaço tem-
porário que possa usar sem restrições. As pessoas que geralmente se aproveitam desta situação de-
scobrem que é possível trabalhar sem se preocupar com espaço até atingirem um ponto final lógico,
quando podem fazer uma limpeza e determinar quais arquivos do armazenamento temporário são
realmente necessários.

Atenção
Se você oferecer esta opção a um usuário, não permita que esse espaço temporário torne-se perma-
nente. Deixe bem claro que o espaço oferecido é temporário e que não há possibilidade de garantir
datas de retenção dos arquivos; backups de dados em espaço temporário nunca são feitos.
Na verdade, muitos administradores de sistemas frequentemente enfatizam esse fato apagando
automaticamente todos os arquivos em armazenamento temporário com mais de uma determinada
idade (uma semana, por exemplo).

Em outros casos, o usuário pode ter muitos arquivos obviamente antigos que provavelmente não
precisa acessar continuamente. Garanta de comunicar essa questão se for o caso. Às vezes, alguns
usuários são responsáveis 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á situações nas quais os dados têm valor dúbio. Nestes casos, talvez você ache melhor
oferecer a produção de um backup especial para eles. Então, você faz o backup dos dados antigos e
entrega a mídia de backup ao usuário, explicando que ele é responsável por mantê-la segura e que, se
precisar acessar quaisquer dados, peça a você (ou aos funcionários de operações — o que for melhor
para a empresa) para recuperá-los.
Há algumas coisas para manter em mente para que a situação não se oponha a você. Primeiro e
mais importante: não inclua arquivos que provavelmente precisarão de recuperação; não selecione
arquivos muito novos. Em seguida, certifique-se da capacidade de executar uma recuperação caso seja
necessária algum dia. Isso significa que a mídia de backup deve ser de um tipo a ser usado pelo seu
centro de dados no futuro.

Dica
Sua escolha da mídia de backup também deve considerar as tecnologias que possibilitam aos
próprios usuários executar a recuperação 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 enviá-
los a um cartucho de filta de 20GB, considere que o usuário pode acessar os dados do CD-ROM
quando quiser — sem precisar do seu envolvimento.

5.7.1.2. Uso Excessivo por uma Aplicação


Às vezes, uma aplicação é responsável por uso excessivo. As razões podem variar, mas podem incluir:

• Melhorias na funcionalidade da aplicação requerem mais armazenamento


• Um aumento do número de usuários que usam a aplicação
• A aplicação falha em fazer a limpeza após terminada, deixando arquivos temporários desnecessários
no disco
Capítulo 5. Administrando o Armazenamento 85

• A aplicação está com código 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 situação. Estar ciente do status
das aplicações usadas em seu centro de dados deve ajudá-lo a eliminar diversos motivos, assim como
deve acontecer com a ciência dos hábitos de processamento de seus usuários. 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 ações apropriadas, seja adicionar armazenamento para suportar uma
aplicação de uso crescente, contatar os desenvolvedores da aplicação para debater sobre suas carac-
terísticas de processamento, ou escrever scripts para efetuar a limpeza após a aplicação.

5.7.1.3. Crescimento Normal do Uso


A maioria das empresas vivencia algum nível de crescimento ao longo do tempo. Por causa disso,
é normal esperar que a utilização do armazenamento aumente numa velocidade similar. Em pratica-
mente todas as circunstâncias, o monitoramento constante pode revelar a taxa média da utilização do
armazenamento em sua empresa; essa taxa pode então ser usada para determinar o tempo no qual o
armazenamento adicional deve ser adquirido antes que seu espaço livre acabe.
Se acontecer de acabar seu espaço livre inesperadamente devido o crescimento normal, você não fez
seu trabalho corretamente.
No entanto, podem ocorrer grandes demandas adicionais ao armazenamento de seus sistemas inesper-
adamente. Sua empresa pode ter sido unida com outra, requerendo alterações rápidas na infra-estrutura
de TI (e, portanto, no armazenamento). Um novo projeto de alta prioridade pode ter surgido durante
a noite. As alterações numa aplicação existente podem resultar em necessidades de armazenamento
bem maiores.
Não importa o motivo; às vezes você é pego de surpresa. A fim de planejar para estes imprevistos, tente
configurar sua arquitetura de armazenamento para a máxima flexibilidade. Manter armazenamento
reserva (se possível) pode aliviar o impacto destes eventos não-planejados.

5.7.2. Questões de Quota de Disco


Muitas vezes, a primeira coisa que a maioria das pessoas pensa ao analisar as quotas de disco é usá-
las para forçar os usuários a manterem seus diretórios limpos. Enquanto há situações nas quais isso
funciona, também ajuda a observar o problema de uso do espaço em disco sob outra perspectiva.
E as aplicações que, por algum motivo, consomem muito espaço em disco? É sabido que algumas
aplicações falham de modo a consumirem todo o espaço disponível em disco. Nestes casos, as quotas
de disco podem limitar o estrago causado por estas aplicações, forçando-as a parar antes de acabar
todo o espaço livre no disco.
A parte mais difícil da implementação e administração das quotas de disco refere-se aos próprios
limites. Quais devem ser os limites? Uma tática simplista seria dividir o espaço em disco pelo número
de usuários e/ou grupos utilizando-o, e fixar o valor resultante como a quota por usuário. Por exemplo:
se o sistema tem um drive de disco de 100GB e 20 usuários, cada usuário deve receber uma quota de
disco de, no máximo, 5GB. Dessa maneira, cada usuário teria a garantia de 5GB (apesar do disco estar
100% cheio neste ponto).
Para os sistemas operacionais que as suportam, é possível determinar quotas temporárias um pouco
mais altas — digamos 7,5GB, com a quota permanente ainda em 5GB. O benefício é permitir que os
usuários consumam permanentemente não mais que suas porcentagens do disco, mas ainda permitindo
alguma flexibilidade quando um usuário atingir (e exceder) seu limite. Ao utilizar quotas de disco
dessa maneira, você está super-comprometendo o espaço disponível em disco. A quota temporária é
86 Capítulo 5. Administrando o Armazenamento

7,5GB. Se todos os usuários excederem suas quotas permanentes ao mesmo tempo e tentarem atingir
suas quotas temporárias, aquele disco de 100GB teria que ter 150GB.
No entanto, nem todos excedem suas quotas permanentes ao mesmo tempo, possibilitando a tática de
algum super-comprometimento. Obviamente, a seleção de quotas permanentes e temporárias cabe ao
administrador de sistemas, já que cada operação e comunidade de usuários são diferentes.

5.7.3. Questões Relativas a Arquivos


Os administradores de sistemas frequentemente lidam com questões relativas a arquivos. Estas
questões incluem:

• Acesso a Arquivos
• Compartilhamento de Arquivos

5.7.3.1. Acesso a Arquivos


As questões relacionadas ao acesso de arquivos tipicamente ocorrem em um cenário — um usuário
não consegue acessar um arquivo que acredita poder acessar.
Frequentemente, é o caso do usuário 1 querendo enviar uma cópia de um arquivo ao usuário 2. Na
maioria das empresas, a habilidade de um usuário acessar os arquivos de outro é estritamente limitada,
acarretando neste problema.
Há três táticas que podem ser usadas:

• O usuário 1 efetua as alterações necessárias para permitir ao usuário 2 acessar o arquivo onde quer
que esteja localizado.
• Cria-se uma área de intercâmbio de arquivos para esse propósito; o usuário 1 copia o arquivo ali,
que então pode ser copiado pelo usuário 2.
• O usuário 1 usa o e-mail para enviar uma cópia do arquivo ao usuário 2.
Há um problema com a primeira tática — dependendo de como o acesso é atribuído, o usuário 2
pode ter acesso total a todos os arquivos do usuário 1. Pior: pode ser feito de maneira a permitir
que todos os usuários de sua empresa acessem os arquivos do usuário 1. Pior ainda: esta alteração
pode não ser revertida após o usuário 2 não querer mais o acesso, deixando os arquivos do usuário
1 permanentemente acessíveis aos outros. Infelizmente, quandos os usuários se encontram nestas
situações, a segurança raramente é sua prioridade mais alta.
A segunda tática elimina o problema de tornar todos os arquivos do usuário 1 acessíveis aos outros.
Entretanto, uma vez que o arquivo encontra-se na área de intercâmbio, este é legível (e, dependendo
das permissões, até gravável) por todos os outros usuários. Essa tática também cria a possibilidade da
área de intercâmbio tornanar-se cheia de arquivos, conforme os usuários esquerecem de limpá-la.
A terceira tática, 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 operação mais segura e não requer nenhum envolvimento do administrador
de sistemas. Obviamente, existe a possibilidade de um usuário tentar enviar por e-mail um arquivo de
banco de dados de 1GB para todas as 150 pessoas do departamento de finanças, portanto um pouco de
educação aos usuários (e possivelmente limitações ao tamanho do anexo) é prudente. Mesmo assim,
nenhuma destas táticas lidam com a situação de um ou mais usuários precisarem de acesso contínuo
ao mesmo arquivo. Nestes casos, é necessário utilizar outros métodos.
Capítulo 5. Administrando o Armazenamento 87

5.7.3.2. Compartilhamento de Arquivos


Quando usuários múltiplos precisam compartilhar a mesma cópia de um arquivo, permitir o acesso ao
alterar as permissões do arquivo não é a melhor solução. É preferível formalizar o estado compartil-
hado do arquivo. Há diversas razões para isto:

• Os arquivos compartilhados fora do diretório de um usuário são vulneráveis a desaparecerem in-


esperadamente quando o usuário deixa a empresa ou simplesmente efetua a organização usual de
seus arquivos.
• Torna-se difícil manter o acesso compartilhado para mais de um ou dois usuários adicionais,
levando ao problema a longo termo de trabalho desnecessário sempre que os usuários
compartilhando tiverem suas responsabilidades alteradas.
Portanto, a tática preferida é:

• O usuário original abdicar da propriedade direta do arquivo


• Criar um grupo que terá a propriedade do arquivo
• Colocar o arquivo num diretório compartilhado de propriedade do grupo
• Tornar todos os usuários, que precisam de acesso ao arquivo, membros do grupo
Obviamente, essa tática funciona bem tanto com arquivos múltiplos 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 espaço adicional em disco, um administrador de sistemas precisa
adicionar espaço ao disco frequentemente, enquanto também remove alguns drives menores e mais
antigos. Esta seção traz uma visão geral do processo básico de adição e remoção de armazenamento.

Nota
Em diversos sistemas operacionais, os dispositivos de armazenamento em massa são nomeados
de acordo com suas conexões físicas ao sistema. Consequentemente, adicionar ou remover disposi-
tivos de armazenamento em massa pode resultar em alterações inesperadas nos nomes dos dispos-
itivos. Ao adicionar ou remover armazenamento, certifique-se de rever (e atualizar, se necessário)
todas as referências de nome usadas pelo seu sistema operacional.

5.7.4.1. Adicionando Armazenamento


O processo de adicionar armazenamento a um sistema é relativamente simples. Aqui estão os passos
básicos:

1. Instalando o hardware
2. Particionando
3. Formatando a(s) partição(ões)
4. Atualizando a configuração do sistema
5. Modificando o agendamento de backup
As seções seguintes abordam cada passo em detalhes.
88 Capítulo 5. Administrando o Armazenamento

5.7.4.1.1. Instalando o Hardware


Antes de qualquer outra coisa, o novo drive de disco deve estar alocado e acessível. Apesar de exis-
tirem muitas configurações de hardware possíveis, as seções a seguir abordam as duas situações mais
comuns — adicionar um drive de disco ATA ou SCSI. Os passos básicos aqui abordados podem ser
aplicados em outras configurações.

Dica
Não 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 disponíveis. 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 são usados principalmente nos computadores de mesa (desktops) e sistemas
de servidores lower-end. Praticamente todos os sistemas destas categorias têm controladores ATA
embutidos com canais ATA múltiplos — normalmente dois ou quatro.
Cada canal pode suportar dois dispositivos — um mestre e um escravo. Os dois dispositivos são
conectados ao canal através de um único cabo. Portanto, o primeiro passo é verificar quais canais têm
espaço disponível para um drive de disco adicional. Teremos uma das três situações:

• Há um canal com apenas um drive de disco conectado


• Há um canal sem nenhum drive de disco conectado
• Não há espaço disponível
A primeira situação geralmente é a mais fácil de lidar, e é provável que o cabo já conectado tenha
um conector não 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), é necessário
substituir o cabo existente por um modelo de três conectores.
Antes de instalar o novo drive de disco, certifique-se que os dois drives de disco compartilhando o
canal estejam configurados apropriadamente (um como mestre e outro como escravo).
A segunda situação é um pouco mais difícil 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 configurado como
mestre ou escravo (apesar do primeiro drive de disco de um canal ser normalmente configurado como
mestre).
Na terceira situação, não há espaço remanescente para um drive de disco adicional. Sendo assim, você
deve tomar uma decisão:

• 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 verificar a compatibilidade do hardware, a capacidade
física e a compatibilidade do software. Em suma, sua placa precisa ser compatível 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 táticas possíveis:

• Gravar os dados num dispositivo de backup e recuperá-los após instalar o novo drive de disco
Capítulo 5. Administrando o Armazenamento 89

• Usar sua rede para copiar os dados para outro sistema com espaço livre suficiente, recuperando os
dados após instalar o novo drive de disco
• Usar o espaço fisicamente 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 então instalar o novo drive de disco no computador original
Como você pode observar, às vezes é necessário 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 são normalmente usados em estações de trabalho e sistemas de servidores
mais avançados. Ao contrário dos sistemas baseados no ATA, os sistemas SCSI podem ou não ter con-
troladores SCSI embutidos. Alguns têm, mas outros usam uma placa de controlador SCSI separada.
As capacidades dos controladores SCSI (embutidos ou não) também variam imensamente. Podem
prover um canal SCSI estreito ou largo. A velocidade do canal pode ser normal, rápida, ultra, ultra2
ou ultra160.
Se estes termos não lhe forem familiares (brevemente abordados na Seção 5.3.2.2), você deve determi-
nar as capacidades da sua configuração de hardware e selecionar um novo drive de disco apropriado.
A melhor fonte para estas informações é a documentação de seu sistema e/ou do adaptador SCSI.
Então, você deve determinar quantos canais SCSI estão disponíveis em seu sistema, e quais têm espaço
disponível para um novo drive de disco. O número 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 é verificar quais canais têm espaço disponível para um drive de disco adicional.
Você terá uma destas três situações:

• Há um canal com um número de drives de disco conectados menor que o máximo


• Há um canal sem nenhum drive de disco conectado
• Não há espaço disponível em nenhum dos canais
A primeira situação geralmente é a mais fácil, já que provavelmente o cabo existente tem um conector
não-utilizado ao qual o novo drive de disco pode ser plugado. No entanto, se este não for o caso, é
necessário substituir o cabo por outro que tenha, no mínimo, mais um conector.
A segunda situação é um pouco mais difícil, somente pelo fato de que o cabo deve ser adquirido para
poder conectar o drive de disco ao canal.
Se não há espaço para um drive de disco adicional, você deve tomar uma decisão. Você:
90 Capítulo 5. Administrando o Armazenamento

• 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 verificar a compatibilidade do hardware, a capacidade
física e a compatibilidade do software. Em suma, a placa deve ser suportada pelo seu sistema op-
eracional, compatível 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 táticas possíveis:

• Gravar os dados num dispositivo de backup e recuperá-los após instalar o novo drive de disco
• Usar sua rede para copiar os dados em outro sistema com espaço livre suficiente, e recuperá-los
após instalar o novo drive de disco
• Usar o espaço fisicamente 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 então instalar o novo drive de disco no computador original
Uma vez que há um conector disponível ao qual plugar o novo drive de disco, você deve garantir que o
ID SCSI do drive esteja configurado apropriadamente. Para fazer isso, é necessário saber o que todos
os dispositivos do canal (inclusive o controlador) estão usando como seus IDs SCSI. O modo mais
fácil é acessar o BIOS do controlador SCSI. Isto é feito normalmente ao pressionar uma sequência
específica de teclas durante a inicialização do sistema. Então, você pode visualizar a configuração do
controlador SCSI, juntamente aos dispositivos ligados a todos os seus canais.
Em seguida, você deve considerar a terminação 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 terminação ativada. Caso contrário, a terminação deve ser desativada.
Neste ponto, você pode passar para o próximo 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 partições para disponibilizar espaço
para seu sistema operacional. Apesar das ferramentas variarem de acordo com o sistema operacional,
os passos básicos são os mesmos:

1. Selecione o novo drive de disco


2. Visualize a tabela de partição atual para garantir que o drive de disco a ser particionado seja, de
fato, o correto
3. Apague quaisquer partições indesejadas que possam estar presentes no novo drive de disco
Capítulo 5. Administrando o Armazenamento 91

4. Crie a(s) nova(s) partição(ões), sem esquecer de especificar o tamanho e tipo de partição dese-
jados
5. Salve suas alterações e saia do programa de particionamento

Atenção
Ao particionar um novo drive de disco, é vital garantir que esteja particionando o correto. Caso
contrário, você pode particionar inadvertidamente um drive de disco já em uso, resultando na perda
de dados.
Também certifique-se de optar pelo melhor tamanho de partição. Sempre dê atenção a essa questão,
porque alterar este valor posteriormente é bem mais difícil que gastar um tempinho para pensar nisso
agora.

5.7.4.1.3. Formatando a(s) partição(ões)


Neste ponto, o novo drive de disco tem uma ou mais partições criadas. Entretanto, antes de usar
o espaço contido nestas partições, estas precisam ser formatadas. Ao formatar, você seleciona um
sistema de arquivo específico a ser usado em cada partição. Sendo assim, esse é um momento crucial
na vida do drive de disco; as opções que você fizer agora não podem ser alteradas sem uma grande
quantidade de trabalho.
O processo de formatação é feito ao rodar um utilitário; os passos envolvidos nisso variam de acordo
com o sistema operacional. Após completar a formatação, o drive de disco está configurado apropri-
adamente para uso.
Antes de continuar, é sempre melhor rever seu trabalho acessando a(s) partição(ões) e garantindo que
tudo esteja em ordem.

5.7.4.1.4. Atualizando a Configuração do Sistema


Se o seu sistema operacional requer alterações na configuração para usar o novo armazenamento que
você adicionou, agora é hora de executá-las.
Neste ponto, você pode sentir-se relativamente confiante que o sistema operacional está configurado
apropriadamente para disponibilizar o novo armazenamento toda vez que o sistema inicializar (mas,
se você puder efetuar uma breve reinicialização para garantir — melhor ainda).
A próxima seção aborda um dos passos mais comumente esquecidos no processo de adição 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 alterações necessárias em seu procedimento de backup e garantir que o novo armazena-
mento tenha, de fato, um backup. A natureza exata do que você deve fazer para tanto depende da
maneira através da qual os backups são feitos em seu sistema. No entanto, aqui estão algumas dicas
para ter em mente ao efetuar as alterações necessárias:

• Considere qual deve ser a melhor frequência de backup


• Determine qual estilo de backup é mais apropriado (somente backups completos, completos com
incrementos, completos com diferenciais, etc)
92 Capítulo 5. Administrando o Armazenamento

• Considere o impacto do armazenamento adicional no uso de sua mídia de backup, especialmente


conforme ficar cheia
• Julgue se o backup adicional pode fazer com que os backups demorem muito e comecem a utilizar
o tempo além daquele determinado para sua janela de backup
• Garanta de comunicar estas alterações às pessoas que precisam saber (outros administradores de
sistemas, pessoal de operações, etc)
Feito isso, seu novo armazenamento está pronto para ser usado.

5.7.4.2. Removendo Armazenamento


Remover espaço em disco de um sistema é simples; a maioria dos passos são parecidos com a sequên-
cia de instalação:

1. Retire do drive de disco quaisquer dados a serem salvos


2. Altere o agendamento de backup para que o drive de disco não tenha mais procedimento de
backup
3. Atualize a configuração do sistema
4. Apague o conteúdo do drive de disco
5. Remova o drive de disco
Como você pode observar, há alguns passos extras em relação ao processo de instalação. Estes passos
são abordados nas próximas seções.

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 decisão depende principalmente no que será feito com estes dados. Por
exemplo: se estes não forem utilizados ativamente, devem ser arquivados, provavelmente da mesma
maneira que os backups de seu sistema. Isso significa que essa é a hora de considerar os períodos de
retenção para este backup final.

Dica
Tenha em mente que, além das regras de retenção de dados que sua empresa tenha, também deve
haver requisitos legais para a retenção de dados por um certo período de tempo. Sendo assim,
certifique-se de consultar o departamento responsável pelos dados enquanto eram utilizados; eles
devem saber o período de retenção apropriado.

Por outro lado, se os dados ainda estão em uso, então devem residir no sistema mais apropriado para
este uso. Obviamente, se este for o caso, talvez seja mais fácil 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.
Capítulo 5. Administrando o Armazenamento 93

5.7.4.2.2. Apague o Conteúdo do Drive de Disco


Não importa se o drive de disco contém dados valiosos ou não; é sempre uma boa idéia apagar todo
o conteúdo de um drive de disco antes de reatribuir ou abdicar de seu controle. Apesar do principal
motivo ser garantir que nenhuma informção delicada permaneça no drive de disco, também é uma boa
hora para verificar sua saúde executando um teste de acesso-gravação para blocos ruins por todo o
drive de disco.

Importante
Muitas empresas (e agências do governo) têm métodos específicos para apagar dados de drives
de disco e outras mídias de armazenamento de dados. Você sempre deve garantir que entende
e cumpre estes requisitos; muitas vezes, há consequências legais caso você não os cumpra. O
exemplo acima não deve, de modo algum, ser considerado o melhor método de limpar um drive de
disco.
Além disso, as empresas que trabalham com dados ordenados podem descobrir que a disposição
final do drive de disco está sujeita a alguns procedimentos legais obrigatórios (tais como a destruição
física do drive de disco). Nestes casos, o departamento de segurança de sua empresa deve ser
capaz de oferecer-lhe aconselhamento.

5.8. Um Pouco Sobre Backups. . .


Os backups são um dos fatores mais importantes quando pensamos em armazenamento de disco. Não
detalhamos a questão aqui, pois há uma seção (Seção 8.2) mais aprofundada e dedicada ao assunto.

5.9. Informações Específicas do Red Hat Enterprise Linux


Dependendo de sua experiência anterior como administrador de sistemas, administrar o armazena-
mento sob o Red Hat Enterprise Linux pode ser familiar ou completamente estranho. Esta seção
aborda os aspectos de armazenamento específicos ao Red Hat Enterprise Linux.

5.9.1. Convenção 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
convenções de nomenclatura para dispositvos de armazenamento anexos variam ligeiramente entre as
diversas implementações do Linux e parecidas com o Linux. Aqui estão os nomes destes arquivos de
dispositivo sob o Red Hat Enterprise Linux:

Nota
Os nomes dos dispositivos sob o Red Hat Enterprise Linux são determinados no momento da ini-
cialização (boot time).
Consequentemente, as alterações efetuadas na configuração do hardware de um sistema podem
resultar na alteração dos nomes dos dispositivos quando o sistema reinicializar. Por causa disso,
os problemas podem ocorrer, caso as referências dos nomes dos dispositivos não forem adequada-
mente atualizadas nos arquivos de configuração do sistema.
94 Capítulo 5. Administrando o Armazenamento

5.9.1.1. Arquivos de Dispositivos


Sob o Red Hat Enterprise Linux, os arquivos dos dispositivos para drives de disco aparecem no di-
retório /dev/. O formato do nome de cada arquivo depende de diversos aspectos do hardware exis-
tente e como este foi configurado. Os pontos importantes são:

• Tipo de dispositivo
• Unidade
• Partição

5.9.1.1.1. Tipo de Dispositivo


As primeiras duas letras do nome do arquivo do dispositivo referem-se ao tipo específico do disposi-
tivo. Para drives de disco, há dois tipos de dispositivos mais comuns:

• sd — O dispositivo é baseado na SCSI


• hd — O dispositivo é baseado na ATA
Para mais informações sobre ATA e SCSI, consulte a Seção 5.3.2.

5.9.1.1.2. Unidade
Na sequência das duas letras do tipo de dispositivo, há uma ou duas letras que especificam a unidade.
A letra que designa a unidade começa com "a" para a primeira unidade, "b" para a segunda e assim
por diante. Consequentemente, o primeiro disco rígido de seu sistema pode aparecer como hda ou
sda.

Dica
A habilidade do SCSI em lidar com um número grande de dispositivos precisou da adição de um
segundo caractere de unidade para suportar sistemas com mais de 26 dispositivos SCSI anexos.
Sendo assim, os primeiros 26 discos rígidos SCSI de um sistema seriam nomeados de sda a sdz,
os próximos 26 seriam nomeados de sdaa a sdaz e assim por diante.

5.9.1.1.3. Partição
A parte final do nome do arquivo de dispositivo é um número representando uma partição específica
no dispositivo, começando por "1." O número pode ter um ou dois dígitos, dependendo do número de
partições gravadas no dispositivo específico. Uma vez conhecido o formato do nome do arquivo de
dispositivo, é fácil entender as referências de cada um. Aqui estão alguns exemplos:

• /dev/hda1 — A primeira partição do primeiro drive ATA


• /dev/sdb12 — A décima-segunda partição do segundo drive SCSI
• /dev/sdad4 — A quarta partição do trigésimo drive SCSI
Capítulo 5. Administrando o Armazenamento 95

5.9.1.1.4. Acesso ao Dispositivo Inteiro


Há situações nas quais é necessário acessar o dispositivo inteiro e não somente uma partição. Isso
normalmente é feito quando o dispositivo não está particionado ou quando não suporta partições
padrão (como o drive de CD-ROM). Nestes casos, o número da partição é omitido:

• /dev/hdc — O terceiro dispositivo ATA inteiro


• /dev/sdb — O segundo dispositivo SCSI inteiro
No entanto, a maioria dos drives de disco usa partições (mais informações sobre o particionamento
sob o Red Hat Enterprise Linux podem ser encontradas na Seção 5.9.6.1).

5.9.1.2. Alternativas aos Nomes de Arquivo dos Dispositivos


Como a adição ou remoção de dispositivos de armazenamento em massa pode resultar em alter-
ações nos nomes de arquivo dos dispositivos existentes, existe o risco do armazenamento não estar
disponível quando o sistema reinicializar. Eis um exemplo da sequência 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) não são 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 prática, isso raramente é um problema
por diversas razões. Primeiro: reconfigurações do hardware desse tipo raramente acontecem. Segundo:
é provável que o administrador de sistemas tenha agendado um tempo fora do ar (downtime) para
efetuar as alterações necessárias; o tempo fora do ar requer um planejamento cuidadoso para garantir
que o trabalho sendo feito não leve mais que o tempo alocado. Esse planejamento tem o benefício
colateral de trazer à tona todas as questões relativas às alterações de nomes dos dispositivos.
Entretanto, algumas empresas e suas configurações de sistemas tem maior probabilidade de passar
por essa situação. As empresas que requerem reconfigurações frequentes do armazenamento para
atender às suas necessidades frequentemente usam hardware capaz de reconfiguração sem a necessi-
dade de tempo fora do ar. Tal hardware, conhecido como hotpluggable, facilita a adição ou remoção
de armazenamento. Porém, sob tais circunstâncias, as questões de nomenclatura de dispositivos po-
dem tornar-se um problema. Felizmente, o Red Hat Enterprise Linux contém funcionalidades que
amenizam o problema das alterações nos nomes dos dispositivos.

5.9.1.2.1. Etiquetas do Sistema de Arquivo


Alguns sistemas de arquivo (abordados na Seção 5.9.2) têm a habilidade de armazenar uma etiqueta
— uma sequência de caracteres que pode ser usada para identificar 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ê não consiga acessar o
sistema de arquivo desejado. Note também que as configurações do sistema que não utilizam sistemas
de arquivo (alguns bancos de dados, por exemplo) não podem usufruir das etiquetas de sistema de
arquivo.
96 Capítulo 5. Administrando o Armazenamento

5.9.1.2.2. Usando o devlabel


O software devlabel tenta resolver a questão 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 são inseridos ou
removidos).
Quando o devlabel é executado, lê o arquivo de configuração (/etc/sysconfig/devlabel) para
obter a lista dos dispositivos pelos quais é responsável. Para cada dispositivo da lista, há uma ligação
simbólica, ou symbolic link, (escolhida pelo administrador de sistemas) e o UUID (IDentificador
Único Universal) do dispositivo.
O comando devlabel garante que a ligação simbólica sempre refere ao dispositivo originalmente
especificado — mesmo que o nome deste dispositivo tenha mudado. Dessa maneira, um administrador
de sistemas pode configurar um sistema para referir ao /dev/projdisk ao invés 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 ligação simbólica apropriadamente.
Para mais informações sobre o devlabel, consulte o Guia de Administração de Sistemas Red Hat
Enterprise Linux.

5.9.2. Conceitos Básicos 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 cenários de boot duplo e ao migrar arquivos de um sistema operacional
para outro.
Os sistemas de arquivo suportados incluem (mas não estão limitados a):

• EXT2
• EXT3
• NFS
• ISO 9660
• MSDOS
• VFAT
Os cenários 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 padrão para o Linux. Como tal,
recebeu testes intensivos e é considerado um dos sistemas de arquivo mais robustos em uso.
No entanto, não existe um sistema de arquivo perfeito e o ext2 não é uma exceção. Um problema
comumente reportado é que o sistema de arquivo ext2 deve passar por uma verificação de integridade
muito longa, caso o sistema não tenha sido desligado apropriadamente. Apesar deste requisito não ser
exclusivo do ext2, sua popularidade, combinada com o advento de drives de disco maiores, significou
que a verificação de integridade estava levando muito tempo. Algo devia ser feito.
A próxima seção aborda a tática adotada para resolver esta questão sob o Red Hat Enterprise Linux.
Capítulo 5. Administrando o Armazenamento 97

5.9.2.2. EXT3
O sistema de arquivo ext3 adicionou as capacidades de journaling sobre a base de código já provada
do ext2. Com o journaling, o ext3 sempre mantém o sistema de arquivo num estado consistente,
eliminando a necessidade de longas verificações de integridade no sistema de arquivo.
Isso é feito ao gravar todas as alterações do sistema de arquivo num registro em disco, que é alimen-
tado frequentemente. Após um evento inesperado no sistema (tal como falta de energia ou queda do
sistema), a única operação que precisa ocorrer antes de disponibilizar o sistema de arquivo é processar
o conteúdo do registro; na maioria dos casos isso leva aproximadamente um segundo.
Como o formato dos dados do ext3 em disco é baseado no ext2, é possível acessar um sistema de
arquivo ext3 em qualquer sistema capaz de acessar e gravar um sistema de arquivo ext2 (porém sem
o benefício do journaling). Este pode ser um excelente benefício em empresas que utilizam alguns
sistemas com ext3 e outros com ext2.

5.9.2.3. ISO 9660


Em 1987, a Organização Internacional para a Padronização (conhecida como ISO, International Or-
ganization for Standardization) lançou o padrão 9660. O ISO 9660 define como os arquivos são rep-
resentados nos CD-ROMs. Os administradores de sistemas Red Hat Enterprise Linux provavelmente
verão 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 mídia CD-R ou CD-RW.
O padrão ISO 9660 básico é limitado em funcionalidade, especialmente se comparado com sistemas
de arquivo mais modernos. Os nomes de arquivos podem ter no máximo oito caracteres e extensão até
três caracteres. No entanto, diversas extensões do padrão tornaram-se conhecidas, incluindo:

• Rock Ridge — Usa alguns campos indefinidos no ISO 9660 para oferecer suporte para funcional-
idades como nomes de arquivo longos misturando letras maiúsculas e minúsculas, para ligações
simbólicas e diretórios embutidos (ou seja, diretórios que podem conter outros diretórios)
• Joliet — Uma extensão do padrão ISO 9660, desenvolvida pela Microsoft para permitir que CD-
ROMs 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 extensões, Rock Ridge e Joliet.

5.9.2.4. MSDOS
O Red Hat Enterprise Linux também suporta os sistemas de arquivo de outros sistemas operacionais.
Como o nome do sistema de arquivo msdos implica, o sistema operacional que originalmente o supor-
tava 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 permissões e propriedade, não podem ser alterados. Entretanto, do
ponto de vista de intercâmbio de arquivos, o sistema de arquivo msdos é mais que suficiente 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 Capítulo 5. Administrando o Armazenamento

vfat podem ser mais longos que o formato 8.3. No entanto, as permissões e propriedade ainda não
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 partição específica (num
dispositivo específico) ao sistema. Da mesma forma, ao acessar um determinado sistema de arquivo
que não é mais desejado, é necessário desmontá-lo (umount).
Para montar um sistema de arquivo, é preciso especificar dois tipos de informação:

• Um meio de identificar unicamente o drive de disco e partição desejados, como o nome do arquivo
do dispositivo, a etiqueta do sistema de arquivo ou a ligação simbólica administrada pelo devlabel
• Um diretório sob o qual o sistema de arquivo montado será disponibilizado (conhecido como ponto
de montagem)
As seções seguintes abordam os pontos de montagem mais detalhadamente.

5.9.3.1. Pontos de Montagem


A não 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 méto-
dos mais poderosos e flexíveis de administração de sistemas de arquivo. Em muitos outros sistemas
operacionais, a especificação completa de um arquivo inclui seu nome, algum meio de identificar o
diretório específico no qual reside e um meio de identificar o dispositivo físico no qual o arquivo pode
ser encontrado.
O Red Hat Enterprise Linux usa uma tática ligeiramente diferente. Assim como ocorre em outros
sistemas operacionais, uma especificação completa inclui o nome do arquivo e o diretório no qual
reside. No entanto, não há um identificador explícito do dispositivo.
A razão dessa aparente deficiência é o ponto de montagem. Em outros sistemas operacionais, há uma
hierarquia de diretórios para cada partição. Mas, em sistemas parecidos com o Linux, há somente uma
hierarquia de diretório para o sistema todo, que pode extender-se a partições múltiplas. A chave é o
ponto de montagem. Ao montar um sistema de arquivo, este é disponibilizado como um conjunto de
sub-diretórios sob o ponto de montagem especificado.
Essa aparente deficiência é, na verdade, uma vantagem. Significa que é possível expandir suavemente
um sistema de arquivo Linux, com todos os diretórios capazes de agirem como um ponto de montagem
para espaço adicional em disco.
Como um exemplo, assuma que um sistema Red Hat Enterprise Linux contenha um diretório foo
em seu diretório root; a localidade completa do diretório seria /foo/. Em seguida, assuma que este
sistema tem uma partição a ser montada e seu ponto de montagem deve ser /foo/. Se esta partição
tivesse um arquivo de nome bar.txt no nível superior de seu diretório, você poderia acessá-lo após
montar a partição, com a especificação seguinte:

/foo/bar.txt

Em outras palavras, uma vez montada a partição, qualquer arquivo que é acessado ou gravado em
qualquer localidade sob o diretório /foo/, será acessado ou salvo nessa partição.
Um ponto de montagem comumente usado em muitos sistemas Red Hat Enterprise Linux é /home/ —
isso ocorre porque os diretórios de login para todas as contas de usuário normalmente estão localizadas
sob /home/. Se /home/ for usado como ponto de montagem, os arquivos de todos os usuários são
salvos numa partição dedicada e não lotarão o sistema de arquivo do sistema operacional.
Capítulo 5. Administrando o Armazenamento 99

Dica
Como o ponto de montagem é somente um diretório comum, é possível salvar arquivos num diretório
posteriormente usado como ponto de montagem. Se isso acontecer, o que ocorre com os arquivos
que estavam originalmente no diretório?
Contanto que a partição seja montada no diretório, os arquivos não estarão acessíveis (o sistema
de arquivo montado aparece no lugar do conteúdo do diretório). No entanto, os arquivos não serão
danificados e podem ser acessados após a partição ser desmontada.

5.9.3.2. Visualizando O Que está Montado


Além de montar e desmontar espaço em disco, é possível 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 são 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. Não deve ser modificado manunalmente.

Cada linha representa um sistema de arquivo correntemente montado e contém os seguintes campos
(da esquerda para a direita):

• A especificação 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 gravação
(rw, read-write), junto às outras opções do ponto de montagem
• Dois campos não-usados contendo zeros (para saber sobre a compatibilidade com /etc/fstab 11)

11. Consulte a Seção 5.9.5 para mais informações.


100 Capítulo 5. Administrando o Armazenamento

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 não existe em nenhum drive de disco de seu sistema Red Hat
Enterprise Linux.
De fato, nem é um arquivo, mas uma representação 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 for-
mato do /etc/mtab. Há diversos sistemas de arquivo montados que não têm nenhuma relação com
drives de disco. Dentre estes, temos o próprio sistema de arquivo /proc/ (junto a dois outros sistemas
operacionais montados sob /proc/), pseudo-ttys e memória compartilhada.
Apesar do formato não ser muito amigável, 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
provém estas informações. Outros métodos podem, sob raras circunstâncias, serem incorretos.
Entretanto, na maior parte do tempo você provavelmente utilizará um comando com output de leitura
mais fácil (e útil). A seção 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 informações sobre quais sistemas de
arquivo estão montados, fazem pouco além disso. Na maior parte do tempo você estará interessado
num aspecto específico dos sistemas de arquivo correntemente montados — a quantidade de espaço
livre nestes.
Para isso, podemos usar o comando df. Aqui está uma amostra do output do df:

Filesystem 1k-blocks Used Available Use% Mounted on


/dev/sda3 8428196 4280980 3719084 54% /
/dev/sda1 124427 18815 99188 16% /boot
/dev/sda4 8428196 4094232 3905832 52% /home
none 644600 0 644600 0% /dev/shm

Nota-se imediatamente diversas diferenças com o /etc/mtab e /proc/mount:

• A exibição de um cabeçalho de fácil leitura


• Com exceção do sistema de arquivo com memória compartilhada, são exibidos somente sistemas
de arquivo baseados no disco
• São exibidos o tamanho total, o espaço utilizado, o espaço livre e a porcentagem em números
Esse último ponto é provavelmente o mais importante, pois todo administrador de sistemas eventual-
mente precisa lidar com um sistema que atingiu todo seu espaço em disco. Com o df é muito fácil
visualizar onde está o problema.
Capítulo 5. Administrando o Armazenamento 101

5.9.4. Armazenamento Acessível pela Rede Sob o Red Hat Enterprise Linux
Há duas tecnologias principais usadas para implementar o armazenamento acessível pela rede sob o
Red Hat Enterprise Linux:

• NFS
• SMB
As seções 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 através de uma conexão de rede. Em
outros sistemas de arquivo, o dispositivo de armazenamento deve ser diretamente ligado ao sistema
local. No entanto, este não é um requisito do NFS, o que possibilita uma variedade de configurações
diferentes - de servidores centralizados de sistema de arquivo a sistemas de computadores inteiramente
sem discos.
Porém, ao contrário de outros sistemas de arquivo, o NFS não dita um formato específico em disco.
Ao invés 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). Então, o NFS disponibiliza o sistema de
arquivo para qualquer sistema operacional rodando um cliente NFS compatível.
Apesar de ser uma tecnologia primariamente do Linux e UNIX, é importante notar a existência de
implementações de clientes NFS para outros sistemas operacionais, viabilizando sua técnica para
compartilhar arquivos dentre diversas plataformas diferentes.
Os sistemas de arquivo que o NFS disponibiliza para clientes são controlados pelo arquivo de con-
figuração /etc/exports. Para mais informações, consulte a página man exports(5) e o Guia de
Administração de Sistemas Red Hat Enterprise Linux.

5.9.4.2. SMB
SMB significa Server Message Block (Bloco de Mensagens do Servidor) e é o nome do protocolo de
comunicações usado por vários sistemas operacionais produzidos pela Microsoft ao longo dos anos.
O SMB possibilita compartilhar armazenamento através de uma rede. As implementações de hoje
frequentemente usam o TCP/IP como o transporte fundamental; o transporte prévio era o NetBEUI.
O Red Hat Enterprise Linux suporta o SMB através do programa de servidor Samba. O Guia de
Administração de Sistemas Red Hat Enterprise Linux contém informações sobre a configuração do
Samba.

5.9.5. Montando Sistemas de Arquivo Automaticamente com /etc/fstab


Quando um sistema Red Hat Enterprise Linux é recém-instalado, todas as partições de disco definidas
e/ou criadas durante a instalação são configuradas para serem montadas automaticamente sempre que
o sistema reinicializar. Porém, o que acontece quando adicionamos drives de disco num sistema após
completa a instalação? A resposta é "nada", porque o sistema não foi configurado para montá-las
automaticamente. No entanto, é fácil mudar isso.
A resposta está no arquivo /etc/fstab. Este arquivo é usado para controlar quais sistemas de arquivo
são montados quando o sistema inicializa, e também 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 Capítulo 5. Administrando o Armazenamento

/dev/sda1 /boot ext3 defaults 1 2


/dev/cdrom /mnt/cdrom iso9660 noauto,owner,kudzu,ro 0 0
/dev/homedisk /home ext3 defaults 1 2
/dev/sda2 swap swap defaults 0 0

Cada linha representa um sistema de arquivo e contém os seguintes campos:

• Especificador 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 ligação simbólica
administrada pelo devlabel (/dev/homedisk)
• Ponto de montagem — Exceto as partições swap, este campo especifica 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 especificado
(note que auto pode ser especificado para selecionar a detecção automática do sistema de arquivo
a ser montado, o que é prático para unidades de mídia removível como drives de disquete)
• Opções de montagem — Uma lista de opções, separadas por vírgulas, que podem ser usadas para
controlar o comportamento do mount (noauto,owner,kudzu)
• Frequência do dump — Se o utilitário de backup dump for usado, o número deste campo controla
como o dump lida com o sistema de arquivo especificado
• Ordem de verificação do sistema de arquivo — Controla a ordem na qual o fsck verifica a integri-
dade dos sistemas de arquivo

5.9.6. Adicionando/Removendo Armazenamento


Apesar da maioria dos passos necessários para adicionar ou remover armazenamento dependerem
mais do hardware que do software do sistema, há aspectos do procedimento específicos ao seu ambi-
ente operacional. Esta seção explora os passos específicos ao Red Hat Enterprise Linux necessários
para adicionar e remover armazenamento.

5.9.6.1. Adicionando Armazenamento


O processo de adição de armazenamento é relativamente simples. Aqui estão os passos específicos ao
Red Hat Enterprise Linux:

• Particionando
• Formatando a(s) partição(ões)
• Atualizar o /etc/fstab
As seções 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 partições a fim de disponibilizar
espaço para o Red Hat Enterprise Linux.
Há mais de uma maneira de fazer isso:

• Usando o utilitário fdisk na janela de comandos


• Usando o parted, um outro utilitário da linha de comandos
Apesar das ferramentas serem diferentes, os passos básicos são os mesmos. O exemplo a seguir inclui
os comandos necessários para executar estes passos usando fdisk:
Capítulo 5. Administrando o Armazenamento 103

1. Selecione o novo drive de disco (o nome do drive pode ser identificado através das convenções
de nomenclatura dos dispositivos descritas na Seção 5.9.1). Usando o fdisk, isso é feito in-
cluindo o nome do dispositivo ao iniciar o fdisk:
fdisk /dev/hda

2. Visualize a tabela de partição 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 partição 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 Start End Blocks Id System


/dev/hda1 * 1 17 136521 83 Linux
/dev/hda2 18 83 530145 82 Linux swap
/dev/hda3 84 475 3148740 83 Linux
/dev/hda4 476 1244 6176992+ 83 Linux

3. Apague todas as partições 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 partições desnecessárias presentes no drive de disco.
4. Crie nova(s) partição(ões), certificando-se de especificar o tamanho e tipo de sistema de arquivo
desejados. Usando o fdisk, este é um processo de dois passos — primeiro: criar a partição
(usando o comando n):
Command (m for help): n
Command action
e extended
p primary partition (1-4)

Partition number (1-4): 1


First cylinder (1-767): 1
Last cylinder or +size or +sizeM or +sizeK: +512M

Segundo: determinar o tipo de sistema de arquivo (usando o comando t):


Command (m for help): t
Partition number (1-4): 1
Hex code (type L to list codes): 82

A partição do tipo 82 representa uma partição Linux swap.


5. Salve suas alterações e saia do programa de particionamento. Isso é feito no fdisk usando o
comando w:
Command (m for help): w
104 Capítulo 5. Administrando o Armazenamento

Atenção
Ao particionar um novo drive de disco, é vital garantir que esteja particionando o correto. Caso
contrário, você pode particionar inadvertidamente um drive de disco já em uso, resultando na perda
de dados.
Também certifique-se de optar pelo melhor tamanho de partição. Sempre dê atenção a essa questão,
porque alterar este valor posteriormente é bem mais difícil que gastar um tempinho para pensar nisso
agora.

5.9.6.1.2. Formatando a(s) partição(ões)


A formatação de partições sob o Red Hat Enterprise Linux é feita com o utilitário mkfs. Na realidade,
o mkfs não executa o trabalho de gravar as informações específicas do sistema de arquivo num drive
de disco; ao invés disso, passa o controle para um dos diversos outros programas que realmente criam
o sistema de arquivo.

Essa é a hora de observar a página man mkfs. fstype do sistema de arquivo que você sele-


cionou. Por exemplo: veja a página man mkfs.ext3 para verificar as opções disponíveis ao criar um
novo sistema de arquivo ext3. Em geral, os programas mkfs. fstype oferecem defaults razoáveis
para a maioria das configurações, mas aqui estão algumas opções que os administradores de sistemas
comumente alteram:

• Determinar uma etiqueta de volume para uso posterior no /etc/fstab


• Em discos rígidos muito grandes, determinar uma porcentagem mais baixa para o espaço reservado
para o super-usuário
• Determinar um tamanho de bloco fora do padrão e/ou bytes por inode para configurações que devem
suportar arquivos muito grandes ou muito pequenos
• Verificar os blocos ruins antes de formatar
Uma vez criados os sistemas de arquivo nas partições apropriadas, o drive de disco está configurado
corretamente para o uso.
Em seguida, é sempre melhor verificar novamente seu trabalho montando manualmente a(s) par-
tição(ões) e garantindo que está tudo em ordem. Após a segunda verificação, é hora de configurar
seu sistema Red Hat Enterprise Linux para montar automaticamente o(s) novo(s) sistema(s) de ar-
quivo sempre que inicializar.

5.9.6.1.3. Atualizar o /etc/fstab


Conforme a Seção 5.9.5, você deve adicionar a(s) linha(s) necessária(s) ao /etc/fstab para garantir
que o(s) novo(s) sistema(s) de arquivo seja montado sempre que o sistema reinicializar. Após atu-
alizar o /etc/fstab, teste seu trabalho atribuindo um comando mount "incompleto", especificando
somente o dispositivo ou ponto de montagem. Algo similar a um dos seguintes comandos é suficiente:

mount /home
mount /dev/hda3

(Substituir /home ou /dev/hda3 pelo ponto de montagem ou dispositivo para sua situação especí-
fica.)
Se a entrada apropriada do /etc/fstab estiver correta, o mount obtém as informações faltantes e
completa a operação de montagem.
Capítulo 5. Administrando o Armazenamento 105

Neste ponto você pode estar relativamente confiante que o /etc/fstab está configurado apropriada-
mente para montar automaticamente o novo armazenamento sempre que o sistema inicializar (mas, se
você puder efetuar uma reinicialização rápida para garantir — melhor ainda).

5.9.6.2. Removendo Armazenamento


O processo de remoção de armazenamento de um sistema Red Hat Enterprise Linux é relativamente
simples. Aqui estão os passos específicos ao Red Hat Enterprise Linux:

• Remova as partições do drive de disco de /etc/fstab


• Desmonte as partições ativas do drive de disco
• Apague o conteúdo do drive de disco
As seções seguintes cobrem estes tópicos em detalhes.

5.9.6.2.1. Remover as Partições do Drive de Disco do /etc/fstab


Usando seu editor de texto preferido, remova a(s) linha(s) correspondente(s) à(s) partição(ões) do
drive de disco do arquivo /etc/fstab. Você pode identificar as linhas apropriadas através de um dos
métodos seguintes:

• Encontrando o ponto de montagem correspondente à partição nos diretórios da segunda coluna do


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

Dica
Certifique-se de procurar por todas as linhas do /etc/fstab que identificam partições 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 finalizado. Para partições contendo sistemas de
arquivo ativos, isso é feito usando o comando umount. Se houver uma partição swap no drive de
disco, deve ser desativada com o comando swapoff ou o sistema deve ser reinicializado.
Para desmontar partições com o comando umount é necessário especificar o nome do arquivo do
dispositivo ou o ponto de montagem da partição:

umount /dev/hda2
umount /home

Uma partição só pode ser desmontada se não estiver em uso. Se a partição não puder ser desmontada
no nível de execução normal, reinicialize no modo de recuperação e remova a entrada /etc/fstab
da partição.
Ao usar o swapoff para desabilitar o swapping numa partição, você deve especificar o nome do
arquivo do dispositivo representando a partição swap:
106 Capítulo 5. Administrando o Armazenamento

swapoff /dev/hda4

Se o swapping não puder ser desabilitado de uma partição swap usando o swapoff, inicialize no
modo de recuperação e remova a entrada /etc/fstab da partição.

5.9.6.2.3. Apague o Conteúdo do Drive de Disco


Apagar o conteúdo de um drive de disco sob o Red Hat Enterprise Linux é um procedimento simples.
Após desmontar todas as partições 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 número da partição. Por exemplo: /dev/hdb para o segundo disco rígido ATA.
O seguinte output é apresentado enquanto o badblocks é executado:

Writing pattern 0xaaaaaaaa: done


Reading and comparing: done
Writing pattern 0x55555555: done
Reading and comparing: done
Writing pattern 0xffffffff: done
Reading and comparing: done
Writing pattern 0x00000000: done
Reading and comparing: done

Tenha em mente que o badblocks está, na realidade, gravando quatro padrões 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 agências do governo) têm métodos específicos para apagar dados de drives
de disco e outras mídias de armazenamento de dados. Você sempre deve garantir que entende
e cumpre estes requisitos; muitas vezes, há consequências legais caso você não os cumpra. O
exemplo acima não deve, de modo algum, ser considerado o melhor método de limpar um drive de
disco.
No entanto, é bem mais eficiente que usar o comando rm, porquê quando você apaga um arquivo
usando rm, este arquivo é marcado como apagado (deleted) — não apaga o conteúdo do arquivo.

5.9.7. Implementando Quotas de Disco


O Red Hat Enterprise Linux é capaz de manter registro do uso do espaço em disco por usuário e
por grupo através da utilização das quotas de disco. A seção seguinte provém uma visão geral das
funcionalidades presentes nas quotas de disco sob o Red Hat Enterprise Linux.
Capítulo 5. Administrando o Armazenamento 107

5.9.7.1. Informações Básicas sobre as Quotas de Disco


As quotas de disco têm as seguintes funcionalidades sob o Red Hat Enterprise Linux:

• Implementação por sistema de arquivo


• Contabilidade do espaço por usuário
• Contabilidade do espaço por grupo
• Registro do uso do bloco de disco
• Registro do uso do inode do disco
• Limites rígidos (hard limits)
• Limites suaves (soft limits)
• Períodos de carência (grace periods)
As seções seguintes descrevem cada funcionalidade em detalhes.

5.9.7.1.1. Implementação 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 flexibilidade ao administrador de sistemas. Por exemplo: se o diretório /home/
estava em seu próprio sistema de arquivo, as quotas de disco poderiam ser ativadas ali, garantindo
o uso igualitário do disco por todos os usuários. 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 contém apenas o próprio sistema operacional.

5.9.7.1.2. Contabilidade do Espaço Por Usuário


As quotas de disco podem efetuar a contabilidade por usuário. Isso significa que o uso do espaço por
cada usuário é registrado individualmente. Também significa que as limitações de uso (abordadas em
seções posteriores) também são determinadas por usuário.
A flexibilidade de registrar e garantir o uso do disco para cada usuário individualmente possibilita a
um administrador de sistemas atribuir limites diferentes aos usuários, de acordo com suas respons-
abilidades e necessidades de armazenamento.

5.9.7.1.3. Contabilidade do Espaço Por Grupo


As quotas de disco também podem registrar o uso do disco por grupo. Isso é ideal para aquelas
empresas que utilizam os grupos como um meio de combinar os diferentes usuários num único recurso
para um projeto.
Ao determinar quotas de disco para um grupo, os administradores de sistemas podem gerenciar de
perto a utilização do armazenamento, atribuindo a usuários individuais somente a quota de disco
necessária 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
são armazenados em blocos, as quotas de disco são capazes de correlacionar diretamente os arquivos
criados e apagados de um sistema de arquivo com a quantidade de armazenamento que estes arquivos
ocupam.
108 Capítulo 5. Administrando o Armazenamento

5.9.7.1.5. Registro do Uso do Inode de Disco


Além de registrar o uso do bloco de disco, as quotas também podem registrar o uso do inode. Sob
o Red Hat Enterprise Linux, os inodes são usados para armazenar várias partes do sistema de ar-
quivo, mas acima de tudo, os inodes guardam as informações de cada arquivo. Consequentemente, ao
registrar (e controlar) o uso do inode, é possível controlar a criação de novos arquivos.

5.9.7.1.6. Limites Rígidos


Um limite rígido é o número máximo absoluto de blocos (ou inodes) de disco que podem ser tempo-
rariamente usados por um usuário (ou grupo). Todas as tentativas de usar um bloco ou inode acima do
limite rígido falharão.

5.9.7.1.7. Limites Suaves


Um limite suave é o número máximo de blocos do disco (ou inodes) que podem ser usados perma-
nentemente por um usuário (ou grupo).
O limite suave é determinado abaixo do limite rígido. Isso permite aos usuários temporariamente
exceder o limite suave, de modo que possam acabar o que estão fazendo e tenham tempo de observar
seus arquivos e reduzir seu uso abaixo do limite suave.

5.9.7.1.8. Períodos de Carência


Conforme afirmado anteriormente, todo uso do disco acima do limite suave é temporário. O período
de carência é que determina o tempo em que um usuário (ou grupo) pode extender seu uso além de
seus limites suaves e rumo a seus limites rígidos.
Se um usuário continuar a usar mais que seu limite suave e o período de carência expirar, não lhe
será permitido usar espaço adicional até que ele (ou o grupo) tenha reduzido seu uso para uma marca
abaixo do limite suave.
O período de carência pode ser estabelecido em segundos, minutos, horas, dias, semanas ou meses,
oferecendo ao administrador de sistemas bastante liberdade para determinar quanto tempo seus
usuários terão para reduzir seus usos de disco abaixo dos limites suaves.

5.9.7.2. Ativando Quotas de Disco

Nota
As seções a seguir oferecem uma breve visão geral dos passos necessários para ativar as quotas
de disco sob o Red Hat Enterprise Linux. Para obter uma abordagem mais profunda deste assunto,
consulte o capítulo sobre quotas de disco no Guia de Administração de Sistemas Red Hat Enterprise
Linux.

Para usar as quotas de disco, você deve ativá-las primeiro. Este processo envolve diversos passos:

1. Modificando o /etc/fstab
2. Remontando o(s) sistema(s) de arquivo
3. Executando o quotacheck
Capítulo 5. Administrando o Armazenamento 109

4. Atribuindo quotas
O arquivo /etc/fstab controla a montagem de sistemas de arquivo sob o Red Hat Enterprise Linux.
Como as quotas de disco são implementadas por sistema de arquivo, há duas opções — usrquota e
grpquota — que devem ser adicionadas a este arquivo para ativar as quotas de disco.
A opção usrquota ativa as quotas de disco do usuário, enquanto a opção grpquota ativa as quotas
de disco do grupo. Uma ou ambas opções podem ser ativadas ao inserí-las no campo de opções para
o sistema de arquivo desejado.
O(s) sistema(s) de arquivo afetado(s) deve(m) então ser desmontado(s) e remontado(s) para que as
opções relativas às quotas de disco tenham efeito.
Em seguida, o comando quotacheck é usado para criar a quota de disco e para coletar as informações
de uso corrente de arquivos já existentes. Os arquivos de quota de disco (nomeados aquota.user e
aquota.group, para quotas de usuário e de grupo) contém as informações necessárias relativas às
quotas e residem no diretório root do sistema de arquivo.
O comando edquota é usado para atribuir quotas de disco.
Este utilitário usa um editor de texto para exibir as informações de quota para usuário ou grupo,
especificadas como parte do comando edquota. Aqui está um exemplo:

Disk quotas for user matt (uid 500):


Filesystem blocks soft hard inodes soft hard
/dev/md3 6618000 0 0 17397 0 0

Isso nos mostra que o usuário matt está usando mais que 6GB de espaço em disco e mais que 17.000
inodes. Nenhuma quota (suave ou rígida) foi determinada para blocos ou inodes do disco, o que sig-
nifica que não há limite para o espaço ou inodes em disco que este usuário pode utilizar no momento.
Usando o editor de texto que apresenta as informações de quota de disco, o administrador de sistemas
pode então modificar os limites suaves e rígidos conforme desejar:

Disk quotas for user matt (uid 500):


Filesystem blocks soft hard inodes soft hard
/dev/md3 6618000 6900000 7000000 17397 0 0

Neste exemplo, o usuário matt recebeu um limite suave de 6.9GB e um limite rígido de 7GB. Não
foram determinados limites suave ou rígido nos inodes para este usuário.

Dica
O programa edquota também pode ser usado para determinar o período de carência por sistema
de arquivo, usando a opção -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 Enter-
prise Linux. Essencialmente, é necessário:

• Gerar relatórios do uso do disco em intervalos regulares (e acompanhar os usuários que parecem
ter problemas em administrar efetivamente seu espaço alocado no disco)
• Garantir que as quotas de disco permaneçam corretas
Criar um relatório do uso do disco implica rodar o utilitário repquota. Usar o comando repquota
/home produz este output:
110 Capítulo 5. Administrando o Armazenamento

*** 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 informações sobre o repquota podem ser encontradas no Guia de Administração de Sistemas
Red Hat Enterprise Linux, no capítulo sobre quotas de disco.
Sempre que um sistema de arquivo não é desmontado de maneira limpa (devido uma queda do sistema,
por exemplo), é necessário rodar o quotacheck. No entanto, muitos administradores de sistemas
recomendam rodar o quotacheck regularmente, mesmo que o sistema não 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 fácil de executar o quotacheck regularmente é usar o cron. A maioria dos ad-
ministradores 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 condições específicas.

5.9.8. Criando Conjuntos RAID


Além de suportar as soluções RAID de hardware, o Red Hat Enterprise Linux também suporta o
RAID de software. Há duas maneiras de criar conjuntos RAID de software:

• Ao instalar o Red Hat Enterprise Linux


• Após o Red Hat Enterprise Linux ter sido instalado
As seções seguintes trazem uma revisão destes dois métodos.

5.9.8.1. Ao Instalar o Red Hat Enterprise Linux


Durante o processo normal de instalação do Red Hat Enterprise Linux, os conjuntos RAID podem ser
criados. Isso é feito durante a fase de particionamento do disco na instalação.
Para começar, você deve particionar manualmente seus drives de disco usando o Disco Druid.
Primeiro, você deve criar uma nova partição do tipo "RAID de software." Em seguida, selecione os
drives de disco que comporão o conjunto RAID no campo Discos Permitidos. Continue o processo
selecionando o tamanho desejado e se você deseja que a partição seja primária.
Uma vez criadas todas as partições necessárias para o(s) conjunto(s) RAID que você deseja criar, use
o botão RAID para realmente criar os conjuntos. Lhe será apresentada uma caixa de diálogo na qual
você pode selecionar o ponto de montagem do conjunto, o tipo do sistema de arquivo, o nome do
dispositivo RAID e as partições "RAID de software" nas quais este conjunto será baseado.
Uma vez criados os conjuntos desejados, o processo de instalação continua normalmente.
Capítulo 5. Administrando o Armazenamento 111

Dica
Para mais informações sobre a criação de conjuntos RAID de software durante o processo de in-
stalação do Red Hat Enterprise Linux, consulte o Guia de Administração de Sistemas Red Hat
Enterprise Linux.

5.9.8.2. Após o Red Hat Enterprise Linux Ser Instalado


Criar um conjunto RAID após a instalação do Red Hat Enterprise Linux é um pouco mais complexo.
Assim como a adição de qualquer tipo de armazenamento de disco, é necessário primeiro instalar o
hardware e configurá-lo corretamente.
O particionamento é um pouco diferente para o RAID do que para drives de disco. Ao invés de
selecionar um tipo de partição "Linux" (tipo 83) ou "Linux swap" (tipo 82), todas as partições que
farão parte do conjunto RAID devem ser do tipo "Linux raid auto" (tipo fd).
Em seguida, é necessário criar o arquivo /etc/raidtab. Esse arquivo é responsável pela configu-
ração apropriada de todos os conjuntos RAID no seu sistema. O formato do arquivo (documentado na
página 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 seções mais notáveis desta seção são:

• raiddev — Exibe o nome do arquivo do dispositivo para o conjunto RAID 12


• raid-level — Define o nível do RAID a ser usado por este conjunto
• nr-raid-disks — Indica quantas partições físicas de disco devem fazer parte deste conjunto
• nr-spare-disks — O RAID de software sob o Red Hat Enterprise Linux permite a definição
de uma ou mais partições reservas; estas partições podem tomar o lugar de um disco com mau
funcionamento automaticamente
• device, raid-disk — Juntos, definem as partições físicas do disco que compoem o conjunto
RAID
Em seguida, é necessário 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
não é diferente de formatar e montar um único drive de disco.

12. Note que, como o conjunto RAID é composto de espaço particionado em disco, o nome do arquivo do
dispositivo de um conjunto RAID não reflete nenhuma informação no nível da partição.
112 Capítulo 5. Administrando o Armazenamento

5.9.9. Administração Diária de Conjuntos RAID


Há pouco a ser feito para manter um conjunto RAID operante. Contanto que não ocorram problemas
de hardware, o conjunto deve funcionar como se fosse um único drive de disco físico. No entanto,
assim como um administrador de sistemas deve verificar periodicamente o status de todos os drives
de disco do sistema, o status dos conjuntos RAID também deve ser verificado.

5.9.9.1. Verificando o Status do Conjunto Com /proc/mdstat


O arquivo /proc/mdstat é a maneira mais fácil de verificar 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á três conjuntos RAID (todos RAID 1). Cada conjunto RAID tem sua própria seção
no /proc/mdstat e contém as seguntes informações:

• O nome do dispositivo do conjunto RAID (excluindo a parte /dev/)


• O status do conjunto RAID
• O nível RAID do conjunto RAID
• As partições físicas que formam o conjunto (seguidas pelo número da unidade do conjunto da
partição)
• O tamanho do conjunto
• O número de dispositivos confiugrados versus o número de dispositivos operantes no conjunto
• O status de cada dispositivo configurado do conjunto (U significa 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 utilitário
raidhotadd deve ser usado para recriar o conjunto. Aqui estão os passos a seguir:

1. Determinar qual drive de disco contém a partição falha


2. Corrigir o problema que causou a falha (provavelmente substituindo o drive)
3. Particionar o novo drive para que as partições contidas neste sejam idênticas àquelas do(s)
outro(s) drive(s) do conjunto


4. Atribuir o seguinte comando:
raidhotadd raid-device  disk-partition 
5. Monitorar o /proc/mdstat para observar a recriação ocorrendo
Capítulo 5. Administrando o Armazenamento 113

Dica
Aqui está um comando que pode ser usado para observar a recriação conforme ocorre:

watch -n1 cat /proc/mdstat

Esse comando exibe o conteúdo do /proc/mdstat, atualizando-o a cada segundo

5.9.10. Administração de Volume Lógico (Logical Volume Management)


O Red Hat Enterprise Linux inclui suporte ao LVM. O LVM pode ser configurado durante a instalação
do Red Hat Enterprise Linux, ou após a instalação. O LVM sob o Red Hat Enterprise Linux suporta o
agrupamento de armazenamento físico, redimensionamento de volume lógico e a migração de dados
de um determinado volume físico.
Para mais informações sobre o LVM, consulte o Guia de Administração de Sistemas Red Hat Enter-
prise Linux.

5.10. Recursos Adicionais


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

5.10.1. Documentação Instalada


Os recursos seguintes são instalados no decorrer de uma típica instalação do Red Hat Enterprise Linux
e podem ajudá-lo a aprender mais sobre o assunto abordado neste capítulo.

• Página man exports(5) — Aprenda mais sobre o formato do arquivo de configuração do NFS.
• Página man fstab(5) — Aprenda mais sobre o formato do arquivo de configuração das infor-
mações do sistema de arquivo.
• Página man swapoff(8) — Aprenda a desativar partições swap.
• Pina man df(1) — Aprenda a visualizar o uso do espaço em disco em sistemas de arquivo monta-
dos.
• Página man fdisk(8) — Aprenda sobre este programa de manutenção da tabela de partições.
• Páginas man mkfs(8) e mke2fs(8) — Aprenda sobre estes utilitários de criação de sistemas de
arquivo.
• Página man badblocks(8) — Aprenda como verificar os blocos ruins de um dispositivo.
• Página man quotacheck(8) — Aprenda a verificar o uso de blocos e inodes por usuários e grupos,
e opcionalmente criar arquivos de quota de disco.
• Página man edquota(8) — Aprenda sobre este utilitário de manutenção das quotas de disco.
• Página man repquota(8) — Aprenda sobre este utilitário de relatório sobre quotas de disco.
• Página man raidtab(5) — Aprenda sobre o formato do arquivo de configuração do RAID de
software.
• Página man mkraid(8) — Aprenda mais sobre este utilitário de criação do conjunto RAID de
software.
114 Capítulo 5. Administrando o Armazenamento

• Página man mdadm(8) — Aprenda sobre este utilitário de administração do conjunto RAID de
software.
• Página man lvm(8) — Aprenda sobre a Administração do Volume Lógico (Logical Volume Man-
agement, LVM).
• Página man devlabel(8) — Aprenda sobre o acesso ao dispositivo de armazenamento persis-
tente.

5.10.2. Sites Úteis

• http://www.pcguide.com/ — Um bom site para todo tipo de informação sobre diversas tecnologias
de armazenamento.
• http://www.tldp.org/ — O Projeto de Documentação do Linux tem HOWTOs e mini-HOWTOs
que oferecem uma boa visão geral das tecnologias de armazenamento e seu relacionamento com o
Linux.

5.10.3. Livros Relacionados


Os livros seguintes abordam diversas questões relacionadas ao armazenamento e são bons recursos
para administradores de sistemas Red Hat Enterprise Linux.

• O Guia de Instalação do Red Hat Enterprise Linux; Red Hat, Inc. — Contém instruções para
particionar discos rígidos durante a instalação do Red Hat Enterprise Linux assim como uma visão
geral das partições de disco.
• O Guia de Referência do Red Hat Enterprise Linux; Red Hat, Inc. — Contém informações de-
talhadas sobre a estrutura de diretórios usada no Red Hat Enterprise Linux e uma visão geral do
NFS.
• O Guia de Administração de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. — Inclui capítu-
los sobre sistemas de arquivo, RAID, LVM, devlabel, particionamento, quotas de disco, NFS e
Samba.
• Linux System Administration: A User’s Guide de Marcel Gagne; Addison Wesley Professional —
Contém informações sobre permissões de usuário 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 —
Contém informações sobre o desempenho do disco, RAID e NFS.
• Linux Administration Handbook de Evi Nemeth, Garth Snyder e Trent R. Hein; Prentice Hall —
Contém informações sobre sistemas de arquivo, atividades dos drives de disco, NFS e Samba.
Capítulo 6.
Administrando Contas de Usuário e Acesso a
Recursos
Administrar contas de usuário e grupos é uma parte essencial da administração de sistemas em uma
empresa. Para executá-la de maneira eficaz, um bom administrador de sistemas deve primeiramente
entender o que são contas de usuário, grupos e como eles funcionam.
A principal razão da existência de contas de usuário é a verificação da identidade de cada indivíduo us-
ando um computador. Uma razão secundária (mas importante) é permitir a personalização de recursos
e privilégios de acesso por indivíduo.
Os recursos podem incluir arquivos, diretórios e dispositivos. Controlar o acesso a estes recursos é uma
grande parte da rotina diária de um administrador de sistemas. Frequentemente o acesso a um recurso
é controlado por grupos. Grupos são formações lógicas que podem ser usadas para agrupar contas
de usuários para um propósito comum. Por exemplo: se uma empresa tem diversos administradores
de sistemas, eles podem ser alocados em um grupos de administradores de sistemas. O grupo, então,
pode receber permissões para acessar recursos sensíveis do sistema. Desta maneira, os grupos podem
ser uma ferramenta poderosa para administrar recursos e acesso.
As seções seguintes abordam contas de usuário e grupos com mais detalhes.

6.1. Administrando Contas de Usuário


Como mencionado anteriormente, as contas de usuário são o método através do qual um indivíduo
é identificado e autenticado no sistema. As contas de usuário têm diversos componentes. Primeiro,
há um nome de usuário (username). Em seguida, a senha (password), seguida pelas informações de
controle de acesso.
As seções seguintes exploram cada um destes componentes com mais detalhes.

6.1.1. O Nome de Usuário


Do ponto de vista do sistema, o nome de usuário é a resposta à pergunta: "quem é você?" Como tal, o
nome de usuário tem um requisito principal — deve ser único. Em outras palavras, cada usuário deve
ter um nome de usuário diferente de todos os outros nomes de usuários no sistema.
Em função deste requisito, é vital determinar — com antecedência — como os nomes de usuário
devem ser criados. Caso contrário, você pode se ver obrigado a intervir cada vez que um novo usuário
requisitar uma conta.
Você precisa de uma convenção de nomenclatura para suas contas de usuário.

6.1.1.1. Convenções de Nomenclatura


Ao criar uma convenção de nomenclatura para nomes de usuário, você pode evitar diversos problemas.
Ao invés de inventar nomes ao longo do curso (e enfrentar a dificuldade de inventar um nome razoável
toda vez), você antecipa seu trabalho e impõe uma convenção a ser usada para todas as contas de
usuário subsequentes. Sua convenção de nomenclatura pode ser muito simples ou então, apenas sua
descrição, pode ter diversas páginas documentadas.
A natureza da sua convenção de nomenclatura deve considerar diversos fatores:

• O tamanho de sua empresa


• A estrutura de sua empresa
116 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos

• A natureza de sua empresa


O tamanho de sua empresa importa, pois dita quantos usuários sua convenção de nomenclatura deve
suportar. Por exemplo: numa micro empresa pode ser possível que todos usem seu primeiro nome.
Para uma empresa bem maior, essa convenção de nomenclatura não funcionará.
A estrutura de uma empresa também pode influenciar a convenção de nomenclatura mais apropriada.
Em empresas com estruturas rígidas, pode ser apropriado incluir elementos da estrutura na convenção
de nomenclatura. Por exemplo: você pode incluir os códigos dos departamentos de sua empresa como
parte de cada nome de usuário.
A natureza da sua empresa também pode significar que algumas convenções de nomenclatura são
mais apropriadas que outras. Um empresa que lida com dados altamente ordenados pode escolher uma
convenção de nomenclatura que elimina quaisquer laços de identificação pessoal entre o indivíduo e
seu nome. Numa empresa deste tipo, o nome de usuário João da Silva poderia ser LUH3417.
Aqui estão algumas convenções de nomenclatura que outras empresas utilizaram:

• Primeiro nome (joão, paulo, jorge, etc.)


• Último nome (silva, pereira, pontes, etc.)
• Primeira inicial, seguida do último nome (jsilva, ppereira, jpontes, etc.)
• Último nome, seguido do código do departamento (silva029, pereira454, pontes191, etc.)

Dica
Atenção: se a sua convenção de nomenclatura inclui a junção de dados diferentes para formar um
nome de usuário, existe a possibilidade do resultado ser hilário ou ofensivo. Portanto, mesmo se
você tiver automatizado a criação dos nomes de usuário, é aconselhável ter algum tipo de revisão
no processo.

As convenções de nomenclatura abordadas aqui têm em comum a possibilidade de existirem dois


indivíduos que, de acordo com a convenção, devem ter os mesmos nomes de usuário. Isto é conhecido
como uma colisão. Como cada nome de usuário deve ser único, é necessário resolver a questão das
colisões. A seção seguinte aborda este assunto.

6.1.1.1.1. Resolvendo as Colisões


Colisões ocorrem de fato — não importa o quanto você tenta, ocasionalmente você deverá resolvê-
las. Você deve planejar como lidar com as colisões em sua convenção de nomenclatura. Há diversas
maneiras de fazer isso:

• Adicionar números sequenciais ao nome de usuário colidido (silva, silva1, silva2, etc.)
• Adicionar dados específicos do usuário ao nome de usuário colidido (silva, esilva, eksilva, etc.)
• Adicionar informações da empresa ao nome de usuário colidido (silva, silva029, silva454, etc.)
Ter algum método de resolver colisões é uma parte necessária de qualquer convenção de nomen-
clatura. No entanto, esta dificulta que alguém de fora da empresa determine o nome de usuário de
um indivíduo corretamente. Portanto, a desvantagem da maioria das convenções de nomenclatura é a
maior probabilidade do envio incorreto de e-mails.
Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 117

6.1.1.2. Resolvendo Alterações de Nome


Se a sua empresa utiliza uma convenção de nomenclatura baseada no nome de cada usuário, é certeza
que você terá que lidar com alterações de nome em algum momento. Mesmo que o nome verdadeiro
de uma pessoa não mude, será necessário alterar alguns nomes de usuários de tempos em tempos.
As razões podem variar; desde o usuário não estar satisfeito com seu nome de usuário até o fato do
usuário ser um gerente sênior da empresa e querer usar sua influência para obter um nome de usuário
"mais apropriado".
Independente da razão, há diversas questões a considerar ao alterar um nome de usuário:

• Efetue a alteração em todos os sistemas afetados


• Mantenha quaisquer identificações do usuário constantes
• Altere a propriedade (ownership) de todos os arquivos e outros recursos específicos do usuário (se
necessário)
• Resolva questões relacionadas a e-mail
Primeiramente, é importante garantir que o novo nome de usuário seja propagado para todos os sis-
temas nos quais o nome de usuário original foi usado. Caso contrário, qualquer função do sistema
operacional baseada no nome do usuário pode funcionar em alguns sistemas e não funcionar em out-
ros. Determinados sistemas operacionais utilizam técnicas de controle de acesso baseadas em nomes
de usuário; tais sistemas têm uma vulnerabilidade relacionada a problemas originados a partir de um
nome de usuário alterado.
Muitos sistemas operacionais utilizam alguma espécie número de identificação do usuário para a
maioria do processamento específico ao usuário. Para minimizar os problemas oriundos da alteração
de um nome de usuário, tente manter este número de identificação constante entre os nomes do usuário
novo e velho. Caso contrário, é provável ter um cenário no qual o usuário não consegue mais acessar
arquivos e outros recursos que previamente possuía sob o nome de usuário original.
Se o número de identificação do usuário deve ser alterado, é necessário alterar a propriedade (own-
ership) de todos os arquivos e recursos específicos ao usuário para refletir a nova identificação do
usuário. Este pode ser um processo propenso a erros, já que parece que sempre há algo esquecido em
algum canto que acaba sendo negligenciado.
As questões relacionadas a e-mails provavelmente representam a área mais difícil para uma alteração
de nome de usuário. A razão disto é que, a não ser que sejam tomadas ações para contra-atacar, os
e-mails destinados ao nome de usuário velho não serão entregues ao nome de usuário novo.
Infelizmente, as questões que permeam o impacto das alterações de nome de usuário em e-mails são
multi-dimensionais. No mínimo, uma alteração de nome de usuário significa que as pessoas não sabem
mais o nome de usuário correto da pessoa. À primeira vista, este não parece ser um grande problema
— notificar a todos de sua empresa sobre a alteração. Mas, e quanto às pessoas fora da empresa que
enviaram e-mails para esta pessoa? Como elas devem ser notificadas? E as listas de discussão (internas
e externas)? Como elas podem ser atualizadas?
Não há uma resposta simples para estas questões. A melhor resposta talvez seja criar um codenome
de e-mail, de modo que todos os e-mails enviados ao nome de usuário velho sejam automaticamente
encaminhados ao novo nome de usuário. O usuário pode ser aconselhado a alertar todos que enviam
e-mails para ele, que seu nome de usuário foi alterado. Com o passar do tempo, menos e-mails serão
entregues usando o codenome; eventualmente o codenome pode ser removido.
Enquanto o uso de codenome, de alguma maneira, perpetua uma suposição incorreta (de que o usuário
agora conhecido como esilva ainda é conhecido como jpontes), é a única maneira de garantir que o
e-mail seja entregue à pessoa correta.
118 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos

Importante
Se você usar codenome de e-mail, certifique-se de executar todos os passos necessários para
proteger o nome de usuário velho de re-utilização. Se você não fizer isso e um novo usuário receber
o nome de usuário velho, a entrega de e-mails (para ambos, o usuário original ou o novo) pode ser
interrompida. A razão exata da interrupção depende de como a entrega de e-mails é implementada
em seu sistema operacional, mas os dois sintomas mais prováveis são:

• O novo usuário nunca recebe nenhum e-mail — todos são entregues para o usuário original.
• O usuário original para de receber e-mails repentinamente — todos são entregues para o novo
usuário.

6.1.2. Senhas
Se o nome de usuário 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 afirmação de uma
pessoa ser o usuário indicado pelo nome de usuário. A eficiência de um esquema de autenticação com
senha baseia-se em diversos aspectos da senha:

• A discrição de senha
• A resistência da senha em ser descoberta
• A resistência da senha a um ataque brute-force
As senhas que atendem estes requisitos são chamadas de fortes, enquanto aquelas que não atendem
um ou mais requisitos são chamadas de fracas. É importante criar senhas fortes para a segurança da
empresa, já que este tipo de senha tem menor probabilidade de ser descoberta. Há duas opções para
reforçar o uso de senhas fortes:

• O administrador de sistemas pode criar senhas para todos os usuários.


• O administrador de sistemas pode deixar que os usuários criem suas próprias senhas, enquanto
verifica se as senhas são aceitáveis.
Criar senhas para todos os usuários garante que sejam fortes, mas torna-se uma tarefa desanimadora
conforme a empresa cresce. Também aumenta o risco dos usuários anotarem suas senhas.
Por estes motivos, a maioria dos administradores de sistemas preferem que seus usuários criem suas
próprias senhas. Entretanto, um bom administrador de sistemas executa alguns passos para garantir
que as senhas sejam fortes.
Para obter instruções sobre a criação de senhas fortes, veja o capítulo intitulado Segurança da Estação
de Trabalho no Guia de Segurança do Red Hat Enterprise Linux.
A necessidade de manter as senhas secretas deve ser uma parte intrínseca da mentalidade de todo
administrador de sistemas. No entanto, este aspecto é frequentemente esquecido por muitos usuários.
De fato, muitos usuários não entendem a diferença entre nomes de usuários e senhas. Portanto, é vital
oferecer alguma forma de educação neste aspecto para os usuários, para que eles entendam que suas
senhas devem ser tão bem guardadas quanto seus holeriths.
As senhas devem ser o mais difícil possível de serem descobertas. Uma senha forte é aquela que o
atacante não consegue descobrir, mesmo que ele também conheça o usuário.
Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 119

Um ataque brute-force a uma senha envolve tentar metodicamente (geralmente através de um pro-
grama conhecido como password-cracker) todas as combinações possíveis de caracteres na esperança
de que a senha correta seja eventualmente encontrada. Uma senha forte deve ser construída de maneira
a tornar o número de senhas a testar muito grande, forçando o atacante a levar bastante tempo na
procura da senha.
As senhas fortes e fracas são abordadas detalhadamente nas seções seguintes.

6.1.2.1. Senhas Fracas


Como explanado anteriormente, uma senha fraca falha em um destes três testes:

• É secreta
• É resistente a ser descoberta
• É resistente a um ataque brute-force
As seções seguintes mostram como as senhas podem ser fracas.

6.1.2.1.1. Senhas Curtas


Um senha curta (breve) é fraca porque é mais suscetível a um ataque brute-force. Para ilustrar isto,
considere a tabela seguinte, onde o número 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 Senhas Potenciais


1 26
2 676
3 17.576
4 456.976
5 11.881.376
6 308.915.776
Tabela 6-1. Tamanho da Senha Versus o Número de Senhas Potenciais

Como você pode ver, o número de senhas possíveis aumenta dramaticamente conforme seu tamanho
aumenta.

Nota
Apesar desta tabela terminar com seis caracteres, isto não é uma afirmação de que senhas de seis
caracteres sejam longas o suficiente para uma boa segurança. Em geral, quanto mais longa a senha,
melhor.

6.1.2.1.2. Conjunto de Caracteres Limitado


O número 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 invés de 26 caracteres diferentes que
podem ser usados numa senha composta apenas de caixa baixa, por que não usamos também dígitos?
Isto significa que cada caractere de uma senha pode ser um dos 36 caracteres ao invés de apenas 26.
120 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos

No caso de uma senha de seis caracteres, isto aumenta o número de senhas possíveis de 308.915.776
para 2.176.782.336.
Ainda há mais que pode ser feito. Se nós também incluirmos caixa alta e baixa nas senhas alfa-
numéricas (para aqueles sistemas operacionais que as suportam), o número de senhas possíveis de
seis caracateres aumenta para 56.800.235.584. Adicionando outros caracteres (tais como pontuação)
aumenta ainda mais o número de senhas possíveis, tornando ainda mais difícil um ataque brute-force.
No entanto, tenha em mente que nem todo ataque contra uma senha é um ataque brute-force. As
seções seguintes descrevem outros atributos que podem formar uma senha fraca.

6.1.2.1.3. Palavras Reconhecíveis


Muitos ataques contra senhas são baseados no fato da maioria das pessoas se sentirem mais con-
fortáveis com senhas que possam lembrar. E, para a maioria das pessoas as senhas memoráveis são
aquelas que contêm palavras. Consequentemente, a maioria dos ataques a senhas são baseados no di-
cionário. Em outras palavras, o atacante utiliza dicionários de palavras para tentar encontrar a palavra
ou palavras que formam uma senha.

Nota
Muitos programas de ataque a senhas baseadas em dicionário usam dicionários de múltiplos id-
iomas. Consequentemente, você não pode acreditar que tem uma senha forte apenas porque utilizou
palavras não inglesas na sua senha.

6.1.2.1.4. Informações Pessoais


Senhas que contêm informações pessoais (o nome ou data de aniversário de uma pessoa querida, de
um animal de estimação ou um número de identificação pessoal) podem ou não ser pegas por um
ataque a senha baseada em dicionário. No entanto, se o atacante te conhece pessoalmente (ou está
suficientemente motivado a pesquisar sua vida pessoal), ele pode ser capaz de adivinhar sua senha
com nenhuma ou pouca dificuldade.
Além dos dicionários, muitos crackers de senhas incluem nomes comuns, datas e outras informações
deste tipo em suas procuras por senhas. Portanto, mesmo que o atacante não 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 informações abordadas anteriormente é a base de uma senha, mas inverter a ordem
dos caracteres não torna uma senha fraca numa senha forte. Muitos crackers de senhas executam este
tipo de truques em senhas possíveis. Isto inclui substituir determinados números por letras em palavras
comuns. Aqui estão alguns exemplos:

• drowssaPdaB1
• R3allyP00r
Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 121

6.1.2.1.6. A Mesma Senha para Múltiplos Sistemas


Mesmo que você tenha uma senha forte, é uma má idéia usar exatamente a mesma senha em mais de
um sistema. Obviamente, há pouco a ser feito se os sistemas estão configurados para usar algum tipo
de servidor de autenticação 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ê não
tem mais um problema de discrição, mas sim um problema de segurança física — agora você deve
proteger um pedaço de papel. Consequentemente, anotar uma senha nunca é uma boa idéia.
No entanto, algumas empresas têm uma necessidade legítima de senhas escritas. Por exemplo: al-
gumas empresas têm senhas escritas como parte do procedimento de recuperação após a perda de
funcionários chave (tais como administradores de sistemas). Nestes casos, o papel contendo as sen-
has é armazenado num local protegido fisicamente, que requer a cooperação de diversas pessoas para
acessar o papel. Passagens com vários cadeados e cofres de banco são frequentemente usados.
Qualquer empresa que utiliza este método de armazenar senhas para emergências deve estar ciente de
que a existência de senhas escritas adiciona um elemento de risco à segurança de seus sistemas. Não
importa o quão protegidas estejam as senhas escritas, principalmente se é de conhecimento geral que
as senhas estão escritas (e onde estão armazenadas).
Infelizmente, as senhas escritas frequentemente não fazem parte de um plano de recuperação e não são
armazenadas com segurança, mas são senhas de usuários comuns, armazenadas nos seguintes locais:

• Na gaveta da mesa (trancada ou não)


• Em baixo de um teclado
• Numa carteira
• Anexo ao lado de um monitor
Nenhum destes locais são apropriados para armazenar uma senha escrita.

6.1.2.2. Senhas Fortes


Nós já vimos como se parecem as senhas fracas; as seções seguintes abordam características 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. Conse-
quentemente, se o seu sistema operacional a suporta, defina um tamanho mínimo relativamente grande
para as senhas de seus usuários.

6.1.2.2.2. Conjunto de Caracteres Expandido


Estimule o uso de caixas alta e baixa, senhas alfa-numéricas e recomende fortemente a adição de pelo
menos um caracter não alfa-numérico em todas as senhas:

• t1Te-Bf,te
• Lb@lbhom
122 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos

6.1.2.2.3. Memorável
Uma senha é forte se pode ser lembrada. Entretanto, ser memorável e de fácil descoberta frequente-
mente andam juntas. Sendo assim, ofereça à sua comunidade de usuários algumas dicas para a criação
de senhas memoráveis que não 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 criação de uma nova senha. O resultado é memorável (porque a frase na qual
baseia-se é memorável), mas não contém palavras.

Nota
Tenha em mente que usar apenas as primeiras letras de cada palavra de frase não é o suficiente
para criar uma senha forte. Certifique-se de sempre aumentar o conjunto de caracteres da senha,
incluindo caracteres alfa-numéricos em caixas alta e baixa e, pelo menos, um caracter especial
também.

6.1.2.3. Expiração de Senhas


Se for possível, implemente a expiração de senhas na sua empresa. A expiração de senhas é uma
funcionalidade (disponível em diversos sistemas operacionais) que define limites de tempo para uma
senha ser considerada válida. No fim da vida de uma senha, o usuário deve inserir uma nova senha,
que pode ser usada até que (esta também) expire.
A principal questão relacionada à expiração de senhas vivenciada por muitos administradores de sis-
temas é o tempo de vida da senha. Quão longo deve ser?
Há duas questões cruciais e opostas relacionadas à expiração de senhas:

• Conveniência do usuário
• Segurança
Em um extremo, o tempo de vida de uma senha de 99 anos apresentaria pouca (ou nenhuma) incon-
veniência para o usuário. No entanto, ofereceria muito pouca (ou nenhuma) melhoria na segurança.
No outro extremo, uma senha com tempo de vida de 99 minutos seria uma grande inconveniência para
seus usuários. Entretanto, a segurança seria bem maior.
A idéia é encontrar um equilíbrio entre a conveniência requerida por seus usuários e a necessidade
de segurança 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. Informações de Controle de Acesso


Juntamente ao nome de usuário e senha, as contas de usuário contêm informações de controle de
acesso. Estas informações têm formatos diferentes de acordo com o sistema operacional. No entanto,
os tipos de informação geralmente incluem:

• Identificação específica do usuário para todo o sistema


• Identificação específica do grupo para todo o sistema
• Listas de grupos/funcionalidades adicionais às quais o usuário pertence
Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 123

• Informações de acesso default a serem aplicadas para todos os arquivos e recursos criados pelo
usuário
Em algumas empresas, as informações de controle de acesso do usuário talvez nunca precisem ser
alteradas. Isto é mais frequente nos casos com standalone e estações de trabalho pessoais, por exemplo.
Outras empresas, especialmente aquelas que utilizam extensivamente o compartilhamento de recursos
entre diferentes grupos de usuários através da rede, requerem que as informações de controle de acesso
do usuário sejam bastante modificadas.
A carga de trabalho necessária para manter corretamente as informações de controle de acesso do
usuário varia de acordo com a escala do uso que sua empresa faz das funcionalidades de controle de
acesso do sistema operacional. Apesar de não ser ruim confiar veementemente nestas funcionalidades
(talvez seja inevitável), significa que o ambiente de seu sistema pode precisar de um esforço maior
para ser mantido, e que todas as contas de usuário têm maior probabilidade de serem configuradas
incorretamente.
Consequentemente, se sua empresa requer este tipo de ambiente, você deve certificar-se de documen-
tar exatamente os passos necessários para criar e configurar corretamente a conta de usuário. De fato,
se há tipos diferentes de contas de usuário, você deve documentar cada uma delas (como criar uma
nova conta de usuário da área financeira, da área de operações, etc.).

6.1.4. Administrando Contas e Acesso a Recursos no Dia-a-Dia


Como diz o velho ditado: a única constante é a mudança. E não é diferente ao lidar com sua comu-
nidade de usuários. Pessoas vêm e vão, mudam de um conjunto de responsabilidades para outro. Sendo
assim, administradores de sistemas devem ser capazes de responder às mudanças, muito comuns no
dia-a-dia das empresas.

6.1.4.1. Novas Contratações


Quando uma nova pessoa é contratada pela empresa, normalmente recebe acesso a vários 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 também receba acesso a um ou mais computadores de sua empresa. Como administrador
de sistemas, é sua responsabilidade executar esta tarefa rápida 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 estão algumas possibilidades:

• Crie um processo no qual o departamento de recursos humanos de sua empresa te notifica a chegada
de um novo funcionário.
• Crie um formulário a ser preenchido pelo supervisor do novo funcionário e usado para requerer
uma nova conta.
Empresas diferentes requerem táticas diferentes. Independentemente de como é feito, é vital que você
tenha um processo altamente confiável que possa alertá-lo sobre qualquer tarefa relacionada a contas
a ser executada.

6.1.4.2. Desligamentos
É fato que algumas pessoas deixarão sua empresa. Às vezes, isto ocorre sob circunstâncias felizes e
outras vezes não. Em ambos os casos, é vital que você seja notificado da situação, para que possa
executar as ações apropriadas.
No mínimo, as ações apropriadas incluem:
124 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos

• Desabilitar o acesso do usuário a todos os sistemas e recursos relacionados (geralmente


alterando/bloqueando a senha do usuário)
• Fazer um backup dos arquivos do usuário, caso contenham alguma informação futuramente
necessária
• Coordenar o acesso aos arquivos do usuário junto ao seu gerente
A prioridade principal é proteger seus sistemas contra o funcionário recém-desligado. Isto é impor-
tante principalmente se o usuário foi desligado sob condições que o façam sentir-se prejudicado pela
empresa. Entretanto, mesmo se as condições não forem tão ruins, é do interesse de sua empresa que
você desabilite o acesso desta pessoa de maneira rápida e confiável.
Isto indica a necessidade de um processo que te alerte sobre todos os desligamentos — de preferência,
até antes do desligamento ocorrer. Sendo assim, é aconselhável 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 rap-
idamente. Se o lock-down ocorrer após terminar o processo de desligamento, existe a possibilidade
de acesso não-autorizado do funcionário recém-desligado. Por outro lado, se o lock-down ocorrer
antes do início do processo de desligamento, pode alertar o funcionário sobre seu possível desliga-
mento e dificultar o processo para todas as partes envolvidas.
O processo de desligamento geralmente é iniciado numa reunião entre o funcionário 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 reunião começar, garante
que o lock-down seja feito oportunamente.

Após desabilitar o acesso, é hora de fazer uma cópia backup dos arquivos do funcionário recém-
desligado. Este backup pode ser parte do padrão de backups de sua empresa, ou pode ser um pro-
cedimento de backup dedicado a contas velhas de usuários. A maneira mais apropriada de lidar com
backups abrange regulamentação de retenção, preservar evidências nos casos de desligamentos através
de processos jurídicos e outros.
Em todos os casos, é bom fazer o backup já que o próximo passo (acesso do gerente aos arquivos
do funcionário recém-desligado) pode resultar acidentalmente na remoção de arquivos. Nestas cir-
cunstâncias, 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 funcionário recém-desligado deve
ter aos arquivos. Dependendo da empresa e da natureza das responsabilidades do ex-funcionário, pode
não ser necessário nenhum acesso, ou então acesso a tudo.
Se o ex-funcionário usou seus sistemas para algo além de e-mails ocasionais, é provável que o gerente
tenha que examinar os arquivos, determinar o que deve ser guardado e o que deve ser descartado.
Ao término deste processo, ao menos alguns destes arquivos devem ser dados à pessoa ou pessoas
assumindo as responsabilidades do ex-funcionário. Talvez sua ajuda seja necessária 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. Alterações de Função


Responder aos pedidos de criação de contas para novos usuários e lidar com a sequência de eventos
necessária para bloquear (lock-down) uma conta quando a pessoa é desligada são processos relativa-
mente simples. No entanto, não é tão simples quando as responsabilidades de uma pessoa são alteradas
dentro da empresa. Às vezes, a pessoa pode precisar de alterações em sua conta, outras vezes não.
Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 125

Haverá ao menos três pessoas envolvidas para garantir que a conta do usuário seja reconfigurada
corretamente para refletir suas novas responsabilidades:

• Você
• O gerente original do usuário
• O novo gerente do usuário
Dentre vocês três, deve ser possível determinar o que deve ser feito para encerrar de forma clara
as responsabilidades velhas do usuário e as ações para preparar a conta do usuário para suas novas
responsabilidades. Sob vários aspectos, este processo pode ser equiparado a encerrar uma conta de
usuário existente e criar uma nova conta. De fato, algumas empresas fazem isto para todas as mudanças
de responsabilidade.
Entretanto, é mais provável que a conta do usuário seja mantida e alterada apropriadamente para su-
portar suas novas responsabilidades. Esta tática significa que você precisa rever cuidadosamente a
conta para garantir que tenha somente aqueles recursos e privilégios apropriados às novas respons-
abilidades da pessoa.
Para complicar um pouco mais a situação, frequentemente existe um período de transição, no qual
o usuário executa tarefas relacionadas aos dois conjuntos de responsabilidades. É neste ponto que
os gerentes antigo e novo do usuário podem ajudá-lo, oferecendo-lhe um prazo para este período de
transição.

6.2. Administrando Recursos do Usuário


Criar contas de usuário é somente uma parte do trabalho de um administrador de sistemas. A admin-
istração dos recursos dos usuários também é essencial. Sendo assim, devemos considerar três pontos:

• Quem pode acessar os dados compartilhados


• Onde os usuários acessam estes dados
• Quais são as barreiras para evitar o abuso de recursos
As seções seguintes trazem uma breve revisão destes tópicos.

6.2.1. Quem Pode Acessar Dados Compartilhados


O acesso de um usuário a uma determinada aplicação, arquivo ou diretório é determinado pelas per-
missões dadas à aplicação, ao arquivo ou ao diretório.
Além disso, geralmente é útil conceder permissões diferentes a categorias diferentes de usuários. Por
exemplo: o armazenamento temporário compartilhado deve ser capaz de evitar remoções acidentais
(ou maléficas) dos arquivos de um usuário por outros usuários, enquanto deve permitir acesso com-
pleto ao proprietário (owner).
Um outro exemplo é o acesso atribuído ao diretório home de um usuário. Somente o proprietário
(owner) do diretório home deve ser capaz de criar ou visualizar arquivos ali. Os outros usuários devem
ter todo o acesso negado (a não ser que o usuário queira o contrário). Isto aumenta a privacidade do
usuário e evita a possível desapropriação de arquivos pessoais.
Não obstante, há diversas situações nas quais usuários múltiplos precisam de acesso aos mesmos
recursos de uma máquina. Nestes casos, pode ser necessário criar grupos compartilhados cuidadosa-
mente.
126 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos

6.2.1.1. Grupos Compartilhados e Dados


Conforme mencionado na introdução, grupos são construções lógicas que podem ser usadas para
agrupar contas de usuários para um propósito específico.
Ao administrar os usuários de uma empresa, é bom identificar 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 questões auxilia na criação de uma estrutura apropriada
de grupos, juntamente às permissões 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 também devem compartilhar esta lista com o departamento
de cobrança. Se as contas dos funcionários de ambos departamentos, contas a pagar e cobrança, são
membros de um grupo chamado contas, estas informações podem ser inseridas num diretório com-
partilhado (de propriedade do grupo contas) com permissões de leitura e gravação (read and write)
para o grupo no diretório.

6.2.1.2. Determinando a Estrutura dos Grupos


Aqui estão alguns dos desafios enfrentados pelos administradores de sistemas ao criar os grupos:

• Quais grupos criar


• Quem deve ser inserido num determinado grupo
• Que tipos de permissões estes recursos compartilhados devem ter
É muito útil estabelecer uma estratégia de bom senso para estas questões. Uma das possibilidades
é espelhar a estrutura de sua empresa na criação dos grupos. Por exemplo: se há um departamento
de finanças, crie um grupo chamado finanças e torne todos os funcionários do departamento de
finanças membros deste grupo. Se as informações financeiras são muito delicadas para a empresa
como um todo, mas essenciais para os gerentes sêniors da empresa, então dê a eles permissões de
grupo para acessar os diretórios e dados usados pelo departamento de finanças, adicionando todos os
gerentes sêniors ao grupo finanças.
Também é aconselhável ser cuidadoso ao conceder permissões aos usuários. Desta maneira, as infor-
mações delicadas têm menor probabilidade de cair em mãos erradas.
Ao criar a estrutura de grupos de sua empresa desta maneira, é possível atender às necessidades de
acesso a dados compartilhados de forma segura e eficaz.

6.2.2. Onde os Usuários Acessam os Dados Compartilhados


Ao compartilhar dados entre usuários, é comum ter um servidor central (ou um grupo de servidores)
que disponibiliza determinados diretórios para outras máquinas da rede. Desta maneira, os dados são
armazenados em um lugar; não é necessário sincronizar os dados entre diversas máquinas.
Antes de adotar esta estratégia, você deve primeiro determinar quais sistemas devem ter acesso aos
dados armazenados centralmente. Ao fazer isso, anote os sistemas operacionais usados pelos sistemas.
Estas informações são importantes para sua habilidade em implementar uma estratégia 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 são compartilhados entre os diversos computadores de uma rede,
o potencial de conflitos pela propriedade do arquivo pode aumentar.
Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 127

6.2.2.1. Questões de Propriedade (ownership) Global


Há benefícios no caso dos dados serem armazenados centralmente e acessados por diversos computa-
dores através de uma rede. Entretanto, assuma por um momento que cada um destes computadores
tem uma lista de contas de usuários mantida localmente. E se a lista de usuários em cada um destes
sistemas não for consistente com a lista de usuários no servidor central? Pior ainda, e se as listas de
usuários em cada um destes sistemas não forem consistentes nem mesmo entre si?
Muitas destas questões dependem de como os usuários e as permissões de acesso são implementadas
em cada sistema, mas em alguns casos é possível o usuário A de um sistema ser conhecido como
usuário B em outro sistema. Isto torna-se um problema latente quando os dados são armazenados
entre estes dois sistemas, já que os dados que o usuário A tem permissão para acessar de um sistema
também podem ser lidos pelo usuáro B de outro sistema.
Por este motivo, muitas empresas usam algum tipo de banco de dados central dos usuários. Isto garante
que não ocorra sobreposições entre as listas de usuários de sistemas diferentes.

6.2.2.2. Diretórios Home


Uma outra questão enfrentada por administradores de sistemas é decidir se os usuários devem ou não
ter diretórios home armazenados centralmente.
A principal vantagem dos diretórios home centralizados num servidor ligado à rede é que, se o usuário
se autenticar em qualquer máquina da rede, ele poderá acessar os arquivos de seu diretório home.
A desvantagem é que, se a rede cair, os usuários da empresa toda não poderão acessar seus arquivos.
Em algumas situações (como em empresas que adotam o uso geral de laptops), talvez não seja quisto
ter diretórios home centralizados. Mas, se faz sentido para sua empresa, implementar diretórios home
centralizados pode facilitar bastante a vida do administrador de sistemas.

6.2.3. Quais são as Barreiras Adotadas para Evitar o Abuso de Recursos


A organização de grupos e a atribuição de permissões para recursos compartilhados feitos de maneira
cuidadosa estão dentre as coisas mais importantes que um administrador de sistemas pode fazer para
evitar o abuso de recursos dentre os usuários de uma empresa. Desta maneira, aqueles que não devem
ter acesso aos recursos delicados têm o acesso negado.
Não importa como a sua empresa se comporta; a melhor proteção contra o abuso de recursos é sempre
a vigilância por parte do administrador de sistemas. Manter seus olhos bem abertos frequentemente é
a única maneira de evitar uma surpresa desagradável esperando por você em sua mesa.

6.3. Informações Específicas do Red Hat Enterprise Linux


As seções seguintes abordam as diversas funcionalidades específicas do Red Hat Enterprise Linux,
relacionadas à administração de contas de usuário e recursos associados.

6.3.1. Contas de Usuário, Grupos e Permissões


Sob o Red Hat Enterprise Linux, um usuário pode se autenticar no sistema e usar qualquer aplicação
ou arquivo que tenha permissão para acessar, após a criação de uma conta de usuário normal. O Red
Hat Enterprise Linux determina se um usuário ou grupo pode acessar estes recursos baseado nas
permissões atribuídas a eles.
128 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos

Há três tipos diferentes de permissões para arquivos, diretórios e aplicações. Estas permissões são
usadas para controlar os tipos de acesso permitidos. São usados símbolos diferentes de um caractere
cada para descrever cada permissão em uma listagem de diretórios. Os seguintes símbolos são usados:

• r — Indica que uma determinada categoria de usuários pode ler (read) o arquivo.
• w — Indica que uma determinada categoria de usuários pode gravar/escrever (write) no arquivo.
• x — Indica que uma determinada categoria de usuários pode executar (execute) o conteúdo de um
arquivo.
Um quarto símbolo (-) indica que nenhum acesso é permitido.
Cada uma das três permissões é atribuída a três categorias diferentes de usuários. As categorias são:

• proprietário (owner) — O proprietário do arquivo ou aplicação.


• grupo (group) — O grupo que detém o arquivo ou aplicação.
• todos (everyone) — Todos os usuários com acesso ao sistema.
Conforme exposto anteriormente, é possível visualizar as permissões de um arquivo invocando uma
listagem de formato longo com o comando ls -l. Por exemplo: se o usuário juan criar um arquivo
executável chamado foo, o output do comando ls -l foo seria parecido com:

-rwxrwxr-x 1 juan juan 0 Sep 26 12:25 foo

As permissões deste arquivo estão listadas no início da linha, começando com rwx. O primeiro con-
junto de símbolos define o acesso do proprietário — neste exemplo, o proprietário juan tem acesso
total e pode ler (read), gravar (write) e executar (execute) o arquivo. O próximo conjunto de símbolos
rwx define o acesso do grupo (novamente, acesso total), enquanto o último conjunto de símbolos de-
fine os tipos de acesso para todos os outros usuários. Aqui, todos os outros usuários podem ler (read)
e executar (execute) o arquivo, mas não podem modificá-lo de maneira alguma.
Um ponto importante para ter em mente em relação às permissões e contas de usuário é que toda
aplicação que roda no Red Hat Enterprise Linux, roda no contexto de um usuário específico. Isto
significa que, se o usuário juan inicia uma aplicação, ela roda usando o contexto do usuário juan.
No entanto, em alguns casos a aplicação pode precisar de um nível de acesso mais privilegiado para
completar a tarefa. Este tipo de aplicação inclui aquelas que editam configurações do sistema ou
autenticam usuários. Por esta razão, foram criadas permissões especiais.
Há três tipos de permissões especiais no Red Hat Enterprise Linux:

• setuid — usada somente para aplicações, esta permissão indica que a aplicação deve rodar como
o proprietário do arquivo e não como o usuário executando a aplicação. É indicado pelo caractere
s no lugar do x na categoria proprietário. Se o proprietário do arquivo não tem permissões para
executar, o S torna-se maiúsculo para refletir este fato.
• setgid — usado principalmente para aplicações, esta permissão indica que a aplicação deve rodar
como o grupo que detém o arquivo, e não como o grupo do usuário executando a aplicação.
Se aplicada a um diretório, todos os arquivos criados dentro do diretório são de propriedade do
grupo que detém o diretório, e não do grupo do usuário criando o arquivo. A permissão setgid é
indicada pelo caractere s no lugar do x na categoria grupo. Se o grupo proprietário do arquivo não
tem permissão para executar, o S torna-se maiúsculo para refletir este fato.
• sticky bit — usado principalmente em diretórios, este bit dita que um arquivo criado no diretório
pode ser removido somente pelo usuário que criou o arquivo. É indicado pelo caractere t no lugar
do x na categoria todos (everyone). Se a categoria todos não tem permissão para executar, o T
torna-se maiúsculo para refletir este fato.
Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 129

Sob o Red Hat Enterprise Linux, o sticky bit é definido por default no diretório /tmp/ exatamente
por este motivo.

6.3.1.1. Nomes de Usuário e UIDs, Grupos e GIDs


No Red Hat Enterprise Linux, as contas de usuário e nomes dos grupos são usadas principalmente
para a conveniência das pessoas. Internamente, o sistema usa identificadores numéricos. Para os
usuários, este identificador é conhecido como UID, enquanto que para os grupos, o identificador é
conhecido como GID. Os programas que disponibilizam as informações do usuário ou grupo aos
usuários traduzem os valores UID/GID para seus paralelos mais legíveis por humanos.

Importante
UIDs e GIDs devem ser globalmente únicos dentro da empresa, se você pretende compartilhar
arquivos através da rede. Caso contrário, quaisquer controles de acesso que você tente implantar
não funcionarão apropriadamente, já que são baseados nos UIDs e GIDs, e não nos nomes de
usuários e grupos.
Especificamente, se os arquivos /etc/passwd e /etc/group de um servidor de arquivos e de uma
estação de trabalho de um usuário diferem nos UIDs ou GIDs que contêm, a atribuição inapropriada
de permissões pode acarretar em problemas de segurança.
Por exemplo: se o usuário juan tem um UID de 500 em um computador, os arquivos que juan criar
num servidor de arquivos terão o UID 500 no proprietário. Entretanto, se o usuário bob se autenticar
localmente ao servidor de arquivos (ou mesmo num outro computador), e a conta do bob também
tiver um UID de 500, bob terá acesso total aos arquivos de juan e vice-versa.
Consequentemente, as colisões de UID e GID devem ser evitadas a todo custo.

Há duas instâncias nas quais o valor numérico corrente de um UID ou GID tem algum significado
específico. Um UID e GID de zero (0) são usados para o usuário root e são tratados especialmente
pelo Red Hat Enterprise Linux — o acesso total é atribuído automaticamente.
A segunda instância é que UIDs e GIDs abaixo de 500 são reservados para uso do sistema. Ao con-
trário do UID/GID zero (0), UIDs e GIDs abaixo de 400 não são tratados especialmente pelo Red
Hat Enterprise Linux. No entanto, estes UIDs/GIDs nunca devem ser atribuídos a um usuário, já que
provavelmente algum componente do sistema usa ou usará estes UIDs/GIDs am algum momento no
futuro. Para mais informações sobre estes usuários e grupos padrão, consulte o capítulo Usuários e
Grupos no Guia de Referência do Red Hat Enterprise Linux.
Quando são adicionadas novas contas de usuários usando as ferramentas padrão de criação de usuários
do Red Hat Enterprise Linux, estas contas recebem os primeiros UID e GID disponíveis a partir de
500. O próximo usuário novo recebe o UID/GID 501, seguido pelo UID/GID 502 e assim por diante.
Mais adiante ainda neste capítulo abordamos uma breve descrição das diversas ferramentas de criação
de usuários disponíveis sob o Red Hat Enterprise Linux. Mas, antes de rever estas ferramentas, a
próxima seção aborda os arquivos que o Red Hat Enterprise Linux usa para definir as contas e grupos
do sistema.

6.3.2. Arquivos que Controlam Contas de Usuário e Grupos


No Red Hat Enterprise Linux, as informações sobre contas de usuário e grupos são armazenadas em
diversos arquivos texto dentro do diretório /etc/. Quando um administrador de sistemas cria novas
contas de usuário, é necessário editar estes arquivos manualmente ou usar aplicações para efetuar as
alterações necessárias.
130 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos

A seção seguinte documenta os arquivos do diretório /etc/ que armazenam informações sobre
usuários e grupos no Red Hat Enterprise Linux.

6.3.2.1. /etc/passwd
O arquivo /etc/passwd pode ser lido por todos e contém uma lista de usuários, cada um numa linha
separada. Em cada linha, há uma lista delimitada por dois pontos contendo as seguintes informações:

• Noime de usuário (username) — O nome que o usuário digita ao se autenticar no sistema.


• Senha (password) — Contém a senha criptografada (ou um x se estiver usando senhas shadow —
confira mais detalhes posteriormente).
• ID do usuário (UID) — O equivalente numérico do nome de usuário, referenciado pelo sistema e
aplicações ao determinar privilégios de acesso.
• ID do grupo (GID) — O equivalente numérico do nome do grupo principal, referenciado pelo
sistema e aplicações ao determinar privilégios de acesso.
• GECOS — Nomeado por motivos históricos, o campo GECOS1 é opcional e é usado para armazenar
informações extras (como o nome completo do usuário). Múltiplas entradas podem ser armazenadas
aqui na lista delimitada por dois pontos. Utilitários como o finger acessam este campo para prover
informações adicionais do usuário.
• Diretório home — A localização absoluta do diretório home do usuário, tal como /home/juan/.
• Shell — O programa iniciado automaticamente sempre que um usuário 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 config-
urado para um arquivo inexistente, o usuário não 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 usuário root tem uma senha shadow, assim como um UID e GID de 0. O
usuário root tem /root/ como um diretório home, e usa /bin/bash para uma shell.
Para mais informações sobre o /etc/passwd, veja a página man do passwd(5).

6.3.2.2. /etc/shadow
Como o arquivo /etc/passwd deve ser legível por todos (world-readable - a principal razão é que
este arquivo é usado para efetuar a tradução do UID para o nome do usuário), há um risco envolvido
em armazenar a senha de todos no /etc/passwd. É verdade que as senhas são criptografadas, mas é
possível executar ataques contra senhas se a senha criptografada estiver disponível.
Se um atacante conseguir uma cópia do /etc/passwd, poderá efetuar um ataque, se planejado silen-
ciosamente. Ao invés de arriscar ser detectado ao tentar se autenticar com todas as senhas possíveis
geradas pelo cracker de senhas, um atacante pode usar o cracker de senhas da seguinte forma:

• Um programa cracker de senhas gera as senhas possíveis


• Cada senha possível é então criptografada usando o mesmo algoritmo que o sistema utiliza

1. GECOS significa General Electric Comprehensive Operating Supervisor. Este campo era usado nos lab-
oratórios da Bell, na implementação original do UNIX. O laboratório tinha muitos computadores diferentes,
incluindo um que rodava o GECOS. Este campo era usado para armazenar informações quando o sistema UNIX
enviava tarefas batch e de impressão ao sistema GECOS.
Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 131

• A possível senha criptografada é então comparada às senhas criptografadas no /etc/passwd


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 disponível no mercado, possibilitando
testar um número enorme de senhas muito rapidamente.
Consequentemente, o arquivo /etc/shadow é legível somente pelo usuário root e contém as sen-
has (e informações opcionais de expiração das senhas) de cada usuário. Assim como no arquivo
/etc/passwd, as informações de cada usuário estão numa linha separada. Cada uma destas linhas é
uma lista delimitada por dois pontos, incluindo as seguintes informações:

• Nome de usuário (username) — O nome que o usuário digita ao se autenticar no sistema. Isso per-
mite que a aplicação login recupere a senha do usuário (e informações relacionadas a este usuário).
• Senha criptografada — A senha de 13 a 24 caracteres. A senha é criptografada usando a função
crypt(3) da biblioteca ou o algoritmo hash md5. Neste campo, os valores além de uma senha hash
ou criptografada formatada de maneira válida são usados para controlar as autenticações do usuário
e exibir o status da senha. Por exemplo: se o valor é ! ou *, a conta está bloqueada e o usuário
não pode se autenticar. Se o valor é !!, a senha ainda não foi determinada (e, consequentemente, o
usuário não poderá se autenticar).
• Data da última alteração da senha — O número de dias desde 1o. de Janeiro de 1970 (também
chamado de período) em que a senha foi alterada pela última vez. Esta informação é usada junto
aos campos de expiração da senha que seguem.
• Número de dias antes que a senha possa ser alterada — O número mínimo de dias antes que a
senha possa ser alterada.
• Número de dias antes que uma alteração de senha seja solicitada — O número de dias antes da
senha ser alterada.
• Número de dias do aviso antes da alteração da senha — O número de dias antes da expiração da
senha durante os quais o usuário é avisado da expiração iminente.
• Número de dias antes da desabilitação da conta — O número de dias após a senha expirar antes da
conta ser desabilitada.
• Data desde a desabilitação da conta — A data (armazenada como o número de dias desde o
período) desde que a conta do usuário 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 informações do usuário juan:

• A senha foi alterada pela última vez no dia 11 de Fevereiro de 2005


• Não há tempo mínimo definido antes que a senha possa ser alterada
• A senha deve ser alterada a cada 90 dias
• O usuário receberá um aviso cinco dias antes de que a senha deve ser alterada
• A conta será desabilitada 30 dias após a senha expirar, se não houver tentativas de autenticação
• A conta expirará no dia 09 de Novembro de 2005
Para mais informações sobre o arquivo /etc/shadow, veja a página man do shadow(5).
132 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos

6.3.2.3. /etc/group
O arquivo /etc/group é legível por todos (world-readable) e contém uma lista de grupos, cada um
numa linha separada. Cada linha tem quatro campos separados por dois pontos, incluindo as seguintes
informações:

• Nome do grupo — O nome do grupo. Usado por vários utilitários como um identificador do grupo
legível por humanos.
• Senha do grupo — Se determinada, esta permite aos usuários que não fazem parte do grupo juntar-
se 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 estão em uso.
• ID do grupo (GID) — O equivalente numérico do nome do grupo. É usado pelo sistema operacional
e aplicações ao determinar os privilégios de acesso.
• Lista de membros — Uma lista de usuários pertencentes ao grupo, separados por vírgulas.
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 são membros.
Para mais informações sobre o /etc/group, veja a página man do group(5).

6.3.2.4. /etc/gshadow
O arquivo /etc/gshadow é legível/acessível somente pelo usuário root e contém uma senha crip-
tografada para cada grupo, assim como informações sobre os membros e administrador. Como no
arquivo /etc/group, as informações de cada grupo estão numa linha separada. Cada uma destas
linhas é uma lista separada por vírgulas, contendo as seguintes informações:

• Nome do grupo — O nome do grupo. Usado por vários utilitários como um identificador do grupo
legível por humanos.
• Senha criptografada — A senha criptografada do grupo. Se determinada, usuários não membros
do grupo podem juntar-se a ele digitando a senha deste grupo usando o comando newgrp. Se o
valor deste campo é !, nenhum usuário pode acessar o grupo usando o comando newgrp. O valor
!! é tratado da mesma maneira como o valor ! — no entanto, também 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 vírgu-
las) podem adicionar ou remover membros do grupo usando o comando gpasswd.
• Membros do grupo — Os membros do grupo aqui listados (numa lista separada por vírgulas) são
membros regulares e não-administrativos do grupo.
Aqui está um exemplo do /etc/gshadow:

general:!!:shelley:juan,bob

Esta linha mostra que o grupo general não tem senha e não permite o ingresso de não membros
usando o comando newgrp. Além disso, shelley é uma administradora do grupo, e juan e bob são
membros regulares e não administrativos.
Já que editar estes arquivos aumenta o risco de erros de sintaxe, é recomendado usar as aplicações
providas pelo Red Hat Enterprise Linux para este propósito. A próxima seção traz uma revisão das
principais ferramentas para executar estas tarefas.
Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 133

6.3.3. Aplicações de Conta de Usuário e Grupo


Há dois tipos básicos de aplicações que podem ser usadas para administrar contas de usuários e grupos
nos sistemas Red Hat Enterprise Linux:

• A aplicação gráfica Administrador de Usuários


• Um conjunto de ferramentas de linha de comando
Para obter instruções detalhadas sobre o uso do Administrador de Usuários, consulte o capítulo
Configuração de Usuário e Grupo no Guia de Administração de Sistemas Red Hat Enterprise Linux.
Apesar da aplicação Administrador de Usuários e dos utilitários de linha de comando executarem
essencialmente a mesma tarefa, as ferramentas de linha de comando têm a vantagem de serem al-
teráveis por scripts e, consequentemente, mais fáceis de serem automatizadas.
A tabela seguinte descreve algumas das ferramentas de linha de comando mais comuns usadas para
criar e administrar contas de usuário e grupos:

Aplicação Função
/usr/sbin/useradd Adiciona contas de usuários. Esta ferramenta é usada também para
especificar os membros principais e secundários do grupo.
/usr/sbin/userdel Apaga contas de usuários.
/usr/sbin/usermod Edita os atributos da conta incluindo algumas funções relacionadas à
expiração da senha. Para os ajustes finos, use o comando passwd. O
usermod também é usado para especificar os membros principais e
secundários do grupo.
passwd Define senhas. Apesar de ser usado principalmente para alterar a
senha de um usuário, também controla todos os aspectos da expiração
da senha.
/usr/sbin/chpasswd Acessa um arquivo contendo pares de nome de usuário e senha e
atualiza a senha de cada usuário de acordo.
chage Altera a política de expiração da senha de um usuário. O comando
passwd também pode ser usado para este propósito.
chfn Altera as informações GECOS do usuário,
chsh Altera a shell default do usuário.
Tabela 6-2. Ferramentas de Linha de Comando para Administração de Usuários

A tabela a seguir descreve algumas das ferramentas de linha de comando mais comuns usadas para
criar e administrar grupos:

Aplicação Função
/usr/sbin/groupadd Adiciona grupos, mas não atribui usuários para estes grupos. Os
programas useradd e usermod devem então ser usados para atribuir
usuários a um determinado grupo.
/usr/sbin/groupdel Apaga grupos.
/usr/sbin/groupmod Modifca os nomes ou GIDs do grupo, mas não altera os membros do
grupo. Os programas useradd e usermod devem ser usados para
atribuir usuários a um determinado grupo.
134 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos

Aplicação Função
gpasswd Altera os membros do grupo e determina senhas para permitir que
usuários não membros do grupo, que conheçam o grupo, a juntem-se
a ele. Também é usado para especificar os administradores do grupo.
/usr/sbin/grpck Verifica a integridade dos arquivos /etc/group e /etc/gshadow.
Tabela 6-3. Ferramentas de Linha de Comando para Administração de Grupos

As ferramentas listadas oferecem uma grande flexibilidade em controlar todos os aspectos das contas
de usuário e associação a grupos. Para aprender mais sobre como estas funcionam, consulte a página
man de cada uma delas.
No entanto, estas aplicações não determinam sobre quais recursos estes usuários e grupos têm cont-
role. Para isso, o administrador de sistemas precisa usar as aplicações para permissão de arquivos.

6.3.3.1. Aplicações para Permissão de Arquivos


As permissões de arquivo são uma parte integral da administração de recursos dentro de uma em-
presa. A tabela seguinte aborda as ferramentas de linha de comando mais comuns utilizadas para este
propósito.

Aplicação Função
chgrp Altera o grupo (ownership) que detém um determinado arquivo.
chmod Altera as permissões de um determinado arquivo. Também é capaz de
atribuir permissões especiais.
chown Altera a propriedade (ownership) de um arquivo e também pode
alterar o grupo.
Tabela 6-4. Ferramentas de Linha de Comando para Administração de Permissões

Também é possível alterar estes atributos nos ambientes gráficos do GNOME e KDE. Clique com o
botão direito no ícone do arquivo (por exemplo: enquanto o ícone é exibido num visualizador gráfico
de arquivos ou na área de trabalho) e selecione Propriedades.

6.4. Recursos Adicionais


Esta seção inclui vários recursos que podem ser usados para aprender mais sobre a admninistração de
contas e recursos, inclusive informações específicas sobre o assunto relacionadas ao Red Hat Enter-
prise Linux neste capítulo.

6.4.1. Documentação Instalada


Os seguintes recursos são instalados no decorrer de uma instalação típica do Red Hat Enterprise Linux
e podem ajudá-lo a aprender mais sobre o assunto abordado neste capítulo.

• Item Help do menu da Administrador de Usuários — Aprenda a administrar contas de usuário e


grupos.
• Página man passwd(5) — Saiba mais informações sobre o formato do arquivo /etc/passwd.
• Página man group(5) — Informações sobre o formato do arquivo /etc/group.
Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 135

• Página man shadow(5) — Informações sobre o formato do arquivo /etc/shadow.


• Página man useradd(8) — Aprenda como criar ou atualizar contas de usuários.
• Página man userdel(8) — Aprenda como apagar contas de usuários.
• Página man usermod(8) — Aprenda como modificar contas de usuários.
• Página man passwd(1) — Aprenda como atualizar a senha de um usuário.
• Página man chpasswd(8) — Aprenda como atualizar as senhas de diversos usuários de uma só
vez.
• Página man chage(1) — Aprenda como alterar as informações de expiração da senha de um
usuário.
• Página man chfn(1) — Aprenda como alterar as informações GECOS (finger) de um usuário.
• Página man chsh(1) — Aprenda a alterar a shell de autenticação de um usuário.
• Página man groupadd(8) — Aprenda a criar um novo grupo.
• Página man groupdel(8) — Aprenda como apagar um grupo.
• Página man groupmod(8) — Aprenda a modificar um grupo.
• Página man gpasswd(1) — Aprenda a administrar os arquivos /etc/group e /etc/gshadow.
• Página man grpck(1) — Aprenda a verificar a integridade dos arquivos /etc/group e
/etc/gshadow.
• Página man chgrp(1) — Aprenda como alterar a propriedade em nível de grupo.
• Página man chmod(1) — Aprenda a alterar as permissões de acesso de um arquivo.
• Página man chown(1) — Aprenda a alterar o proprietário 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 informações sobre a segurança da senha para os usuários 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 verificar
quantos de seus usuários têm senhas fracas.
• http://www.linuxpowered.com/html/editorials/file.html — uma boa visão geral sobre as permissões
de arquivos no Linux.

6.4.3. Livros Relacionados


Os livros a seguir abordam diversas questões relacionadas à administração de contas e recursos e são
boas fontes de informação para administradores de sistemas Red Hat Enterprise Linux.

• O Guia de Segurança do Red Hat Enterprise Linux; Red Hat, Inc. — Oferece uma visão geral dos
aspectos relacionados à segurança de contas de usuários, enfaticamente sobre senhas fortes.
• O Guia de Referência do Red Hat Enterprise Linux; Red Hat, Inc. — Contém informações detal-
hadas sobre usuários e grupos presentes no Red Hat Enterprise Linux.
• O Guia de Administração de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. — Inclui um capí-
tulo sobre a configuração de usuários e grupos.
136 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos

• Linux Administration Handbook de autoria de Evi Nemeth, Garth Snyder e Trent R. Hein; Prentice
Hall — Traz um capítulo sobre a manutenção de contas de usuários, uma seção sobre segurança já
que é relacionado aos arquivos de contas de usuários, e uma seção sobre permissões e atributos de
arquivos.
Capítulo 7.
Impressoras e Impressão
As impressoras são um recurso essencial para criar uma versão em cópia impressa — uma descrição
física dos dados em papel — de documentos e materiais para negócios, estudos acadêmicos e uso
doméstico. As impressoras tornaram-se um periférico indispensável em todos os níveis de empresas e
computação institucional.
Este capítulo aborda as diversas impressoras disponíveis e compara seus usos em ambientes computa-
cionais diferentes. Então, descreve como a impressão é suportada pelo Red Hat Enterprise Linux.

7.1. Tipos de Impressoras


Assim como qualquer outro periférico, há diversos tipos de impressora disponíveis. Algumas impres-
soras empregam tecnologias que imitam a funcionalidade do estilo da máquina de escrever, enquanto
outras utilizam jato de tinta ou então laser para gerar uma imagem da página sendo impressa. O hard-
ware 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 seções seguintes abordam vários tipos de impressoras e os protocolos que utilizam para
comunicarem-se com computadores.

7.1.1. Considerações de Impressão


Há diversos aspectos relevantes para a avaliação de uma impressora. Veja a seguir alguns dos critérios
mais comuns para avaliar suas necessidades de impressão.

7.1.1.1. Função
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 questão mais importante
é "O que precisamos imprimir?" Como há impressoras especializadas em texto, imagens ou variações
destas, você deve garantir de adquirir a ferramenta correta para seus propósitos.
Por exemplo: se as suas necessidades exigem imagens coloridas de alta qualidade em papel glossy
profissional, é recomendado usar uma impressora colorida com tecnologia dye-sublimation ou trans-
ferência térmica de cera (thermal wax transfer) ao invés de uma impressora à laser ou de impacto.
Por outro lado, as impressoras a laser e jato de tinta são mais apropriadas para imprimir esboços ou
documentos para distribuição interna (tais impressoras de alto volume são chamadas de impresso-
ras workgroup). Estudar as necessidades diárias dos usuários 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 página
(impressão simplex). A maioria dos modelos simples de impressora não tem duplexing por default
(mas talvez possam efetuar um duplexing manual, o que requer que o usuário vire o papel). Alguns
modelos oferecem a possibilidade de adicionar hardware para executar o duplexing; tais adições po-
dem elevar os custos consideravelmente. Entretanto, a impressão duplex pode reduzir custos a longo
prazo, reduzindo a quantidade de papel usada para imprimir documentos e, consequentemente re-
duzindo o custo de consumíveis — 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 Capítulo 7. Impressoras e Impressão

• letter — (8 1/2" x 11")


• A4 — (210mm x 297mm)
• JIS B5 — (182mm x 257mm)
• legal — (8 1/2" x 14")
Se determinados departamentos (como marketing ou design) têm necessidades específicas, como a
criação de pôsters ou banners, há impressoras de formato grande capazes de usar papel tamanho A3
(297mm x 420mm) ou tablóide (11" x 17"). Além dessas, há impressoras para tamanhos de papel
ainda maiores, mas são usadas apenas para fins específicos, como para a impressão blueprint (mapas,
planos arquitetônicos, etc.)
As funcionalidades mais complexas, como módulos de rede para impressão workgroup e site remoto
também devem ser consideradas durante a avaliação.

7.1.1.2. Custo
O custo é outro fator a considerar. No entanto, determinar o custo único associado à compra da im-
pressora não é suficiente. Há outros custos envolvidos, como os consumíveis, peças, manutenção e
hardware adicionais.
Como a palavra implica, consumíveis é um termo usado para descrever o material usado durante o
processo de impressão. Os consumíveis, neste caso, são mídia e tinta.
A mídia é o material no qual o texto ou imagem é impresso. A escolha da mídia depende muito do
tipo de informação sendo impressa.
Por exemplo: criar uma impressão exata de uma imagem digital requer um papel glossy especial que
resista à exposição prolongada de luz natural ou artificial, e também garantir a acuracidade da repro-
dução de cores. Estas qualidades são chamadas de rapidez de cor. Para imprimr documentos com qual-
idade de arquivo que requerem durabilidade e um nível profissional de legibilidade (como contratos,
curriculuns e registros permanentes), é necessário usar papel matte (ou não-glossy). A gramatura (ou
grossura) do papel também é importante, já que algumas impressoras possuem um caminho não-linear
do papel. O uso de papel muito fino ou muito grosso pode resultar em obstruções (paper jams). Al-
gumas impressoras também podem imprimir em transparências, permitindo que a informação seja
projetada numa tela durante apresentações.
As mídias especializadas, como as mencionadas aqui, podem alterar o custo dos consumíveis, e devem
ser levadas em consideração ao avaliar as necessidades de impressão.
Tinta é um termo genérico, já que nem todas as impressoras usam tintas líquidas. Por exemplo: as
impressoras laser usam um pó conhecido como toner, enquanto impressoras de impacto usam fitas
saturadas com tinta. Há impressoras especializadas que aquecem a tinta durante o processo de im-
pressão, enquanto outras espirram gotas de tinta na mídia. Os custos de reposição da tinta variam
amplamente e dependem do fato se o repositório de tinta pode ser recarregado (com refil) ou se o
cartucho de tinta precisa ser completamente substituído.

7.2. Impressoras de Impacto


As impressoras de impacto representam a tecnologia mais antiga ainda em produção. Alguns dos
maiores fabricantes de impressoras continuam a produzí-las, vendê-las e suportar as impressoras,
peças e suprimentos. As impressoras de impacto são mais funcionais em ambientes especializados,
nos quais o baixo custo de impressão é essencial. Os três tipos mais comuns de impressoras de impacto
são matricial, margarida e impressoras de linha.
Capítulo 7. Impressoras e Impressão 139

7.2.1. Impressoras Matriciais


A tecnologia por trás da impressão matricial é bem simples. O papel é pressionado contra um tambor
(um cilindro coberto de borracha) e é intermitentemente puxado para frente ao longo da impressão.
A cabeça de impressão move-se eletromagneticamente ao longo do papel e atinge a fita de impressão
situada entre o papel e o pino da cabeça. O impacto da cabeça de impressão contra o tambor lança
pontos de tinta, que formam caracteres humanamente legíveis no papel.
As impressoras matriciais variam na resolução e na qualidade geral, com cabeças de impressão de
9 ou de 24 pinos. Quanto mais pinos por polegada, maior a resolução da impressão. A maioria das
impressoras matriciais tem resolução máxima de, aproximadamente, 240 dpi (dots per inch, pontos
por polegada). Apesar desta resolução não ser tão alta quanto aquelas possíveis em impressoras jato
de tinta ou laser, não há uma vantagem distinta para as impressões matriciais (ou de qualquer forma
de impacto). Como a cabeça de impressão deve atingir a superfície do papel com força suficiente
para transferir tinta de uma fita para a página, é uma boa opção para empresas que precisam produzir
cópias carbono através do uso de documentos multi-partes especiais. Estes documentos têm carbono
(ou outro material sensível à pressão) no lado de baixo e criam uma marca na página de baixo quando
a pressão é aplicada. Lojas de varejo e pequenas empresas frequentemente usam cópias carbono como
recibos ou notas de vendas.

7.2.2. Impressoras Margarida


Se você já trabalhou com uma máquina de escrever manual antes, então entende o conceito tec-
nológico por trás das impressoras margarida. Estas impressoras têm cabeças de impressão compostas
de rodas metálicas ou plásticas cortadas no formato de pétalas. Cada pétala tem a forma de uma letra
(em caixa alta e baixa), número ou pontuação. Quando a pétala é pressionada sobre a fita de impressão,
a forma resultante força a tinta sobre o papel. As impressoras margarida são barulhentas e lentas. Não
podem imprimir gráficos, e não podem alterar a fonte, a não ser que a roda de impressão seja fisica-
mente substituída. Com o advento das impressoras à laser, as impressoras margarida geralmente não
são 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 invés de uma roda de impressão, as impressoras de linha têm um mecanismo que permite imprimir
caracteres múltiplos na mesma linha. O mecanismo pode usar tambor de impressão rotativo ou uma
correia de impressão em loop. Conforme o tambor ou correia é rotacionada sobre a superfície do
papel, martelos eletromagnéticos empurram o papel por trás (junto à fita) sobre a superfície do tambor
ou correia, marcando o papel com a forma do caractere no tambor ou correia.
Devido à natureza do mecanismo de impressão, as impressoras de linha são bem mais rápidas que
as impressoras matriciais ou margarida. Entretanto, tendem a ser muito barulhentas, ter capacidade
limitada de fontes múltiplas e frequentemente produzir impressões de qualidade inferior que as tec-
nologias de impressão mais recentes.
Como as impressoras de linha são usadas para a sua velocidade, utilizam papel especial alimentado
por tração com buracos pré-furados de cada lado. Esta combinação possibilita a impressão contínua
de alta velocidade sem supervisão, parando somente quando uma caixa de papel acaba.

7.2.4. Consumíveis de Impressoras de Impacto


Dentre todos os tipos de impressoras, as impressoras de impacto têm custos de consumíveis relati-
vamente baixos. Fitas de tinta e papel são os custos recorrentes principais. Algumas impressoras de
impacto (geralmente de linha e matriciais) requerem papel alimentado por tração, o que pode aumen-
tar um pouco o custo da operação.
140 Capítulo 7. Impressoras e Impressão

7.3. Impressoras à Jato de Tinta


Um impressora à jato de tinta usa uma das tecnologias de impressão mais conhecidas de hoje. O custo
relativamente baixo e as habilidades de impressão das impressoras à jato de tinta fazem deste tipo uma
boa opção para pequenas empresas e escritórios residenciais.
As impressoras à jato de tinta usam tintas baseadas em água e rápidas de secar, e uma cabeça de
impressão com uma série de pequenos bocais, que lançam tinta na superfície do papel. O conjunto da
cabeça de impressão é movido por um motor com polia, que move a cabeça ao longo do papel.
As impressoras à jato de tinta eram originalmente fabricadas para imprimir somente em papel
monocromático (preto e branco). No entanto, desde então, a cabeça de impressão foi expandida e os
bocais aumentados para acomodar as cores cyan, magenta, amarelo e preto. Essa combinação
de cores (chamada CMYK) permite a impressão de imagens com quase a mesma qualidade de
um laboratório fotográfico (quando usada com determinados tipos de papel composto). Quando
combinadas com qualidade de impressão de texto altamente legível, as impressoras à jato de tinta são
uma ótima opção para necessidades de impressão monocromáticas ou coloridas.

7.3.1. Consumíveis das Impressoras à Jato de Tinta


As impressoras à jato de tinta tendem a ter custo baixo e características de impressão um pouco
elevadas em relação à qualidade, funções extras e habilidade de imprimir em formatos maiores que os
tamanhos de papel legal ou letter padrões. Apesar do custo único de adquirir uma impressora à jato de
tinta ser menor que outros tipos de impressora, o fator dos consumíveis deve ser considerado. Como
a demanda por impressoras à jato de tinta é grande e atinge todo o espectro da computação - do lar às
grandes corporações - a compra de consumíveis 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 não.
Algumas impressoras usam um cartucho multi-câmara. A não ser que seja possível algum método de
refil, assim que a tinta de uma cor acaba, todo o cartucho dever ser substituído. Outras impressoras
utilizam um cartucho multi-câmara para cyan, magenta e amarelo, mas têm um cartucho separado
para a cor preta. Em ambientes onde são impressas grandes quantidades de texto, este tipo de
configuração pode ser indicado. No entanto, a melhor solução é 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 papéis possuem uma cobertura moderada a alta,
formulada para absorver tintas coloridas, o que evita a coagulação (tendência 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 impressão apresenta uma padrão estirado de linhas
esquisitas na página impressa). Consulte a documentação de sua impressora para outras informações
relevantes.

7.4. Impressoras à Laser


Baseada numa tecnologia mais antiga que a jato de tinta, as impressoras à laser são uma outra alterna-
tiva conhecida da impressão de impacto legada. As impressoras à laser são conhecidas por seu grande
Capítulo 7. Impressoras e Impressão 141

volume de output a um baixo custo-por-página. São geralmente empregadas em empresas como um


centro de impressão departamental ou workgroup, nos quais desempenho, durabilidade e requisitos
de output são prioridades. Como as impressoras à laser atendem prontamente a estas necessidades
(a um custo-por-página razoável), a tecnologia é altamente conceituada como o cavalo de batalha da
impressão empresarial.
As impressoras à laser compartilham de grande parte da tecnologia das fotocopiadoras. Os rolamentos
puxam uma folha de papel de uma bandeja e através de um rolamento de carga, que passa uma carga
eletrostática ao papel. Ao mesmo tempo, um tabor de impressão recebe a carga oposta. A superfície do
tambor é scaneada por um laser, descarregando a superfície do tambor e deixando com carga apenas
aqueles pontos correspondentes ao texto ou imagem desejada. Essa carga é então usada para forçar o
toner a ser aderido pela superfície 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 fusão, que esquentam o papel e derretem o
toner, fundindo-o na superfície do papel.

7.4.1. Impressoras à Laser Coloridas


As impressoras à laser coloridas pretendem combinar as melhores características das tecnologias laser
e jato de tinta em um pacote de impressão multi-funcional. A tecnologia é baseada na impressão à laser
monocromática tradicional, mas utiliza componentes adicionais para criar imagens e documentos col-
oridos. Ao invés de usar somente toner preto, as impressoras à laser coloridas usam uma combinação
de toner CMYK. O tambor de impressão pode: rotacionar cada cor e derramar o toner de uma cor
por vez, ou então derramar todas as quatro cores em um prato e então passar o papel pelo tambor,
transferindo a imagem completa para o papel. As impressoras à laser coloridas também empregam
óleo fusor ao longo dos rolamentos de fusão aquecidos, o que por sua vez junta o toner colorido ao
papel e pode proporcionar diferentes graus de gramatura à imagem final.
Devido o maior número de funcionalidades, as impressoras à laser coloridas tipicamente custam o do-
bro (ou mais) do que as impressoras à laser monocromáticas. Ao calcular o custo total de propriedade
em relação aos recursos de impressão, alguns administradores talvez queiram separar as funcionali-
dades monocromática (texto) e colorida (imagem) para uma impressora à laser monocromática e uma
impressora à laser (ou jato de tinta) colorida, respectivamente.

7.4.2. Consumíveis da Impressora à Laser


Dependendo do tipo da impressora à laser empregada, os custos de consumíveis geralmente são pro-
porcionais ao volume de impressão. O toner vem em cartuchos geralmente substituídos prontamente;
no entanto, alguns modelos acompanham cartuchos recarregáveis. As impressoras à laser coloridas
requerem um cartucho de toner para cada uma das quatro cores. Além disso, requerem óleos fusores
para aplicar o toner sobre o papel e desperdiçam garrafas de toner para capturar o excesso de toner.
Estes suprimentos aumentam o custo dos consumíveis das impressoras à laser coloridas; no entanto,
é importante notar que estes consumíveis duram, em média, em torno de 6000 páginas, um número
bem maior se comparado com a duração dos consumíveis das impressoras de impacto ou jato de tinta.
O tipo de papel é um problema menor nas impressoras à laser, o que significa que uma compra grande
de papel xerográfico ou de fotocópia comuns é aceitável para a maioria dos trabalhos de impressão.
Entretanto, se você pretende imprimir imagens de alta qualidade, deve optar por papel fotográfico
(glossy) para obter uma finalização profissional.

7.5. Outros Tipos de Impressora


Há outros tipos de impressora disponíveis, que têm, em sua maioria, propósitos especiais para gráficos
profissionais ou empresas de publicações. No entanto, estas impressoras não são indicadas para uso
142 Capítulo 7. Impressoras e Impressão

genérico. Como são delegadas para este nicho, seus preços (ambos, os custos único e os recorrentes
dos consumíveis) tendem a ser mais altos que os preços das unidades predominantes.

Impressoras de Cera Térmica


Estas impressoras são mais usadas para transparências em apresentações empresariais e para
prova de cor (criação de documentos e imagens teste para uma inspeção de qualidade antes do
envio dos documentos mestre para serem impressos em impressoras industriais offset de quatro
cores). As impressoras de cera térmica utilizam tambores CMYK direcionados por uma fita, e
papel ou transparência especialmente cobertos. A cabeça de impressão contém elementos quentes
que derretem cada cor de cera no papel conforme ele rola pela impressora.

Impressoras Dye-Sublimation
Usadas em empresas como agências de serviço — onde a qualidade profissional dos documentos,
panfletos e apresentações é mais importante que o custo dos consumíveis — as impressoras
dye-sublimation (ou dye-sub) são os cavalos de batalha da impressão CMYK de qualidade. Os
conceitos por trás das impressoras dye-sublimation são similares aos das impressoras de cera
térmica, exceto pelo uso de filme dye plástico difusivo ao invés de cera colorida. A cabeça de
impressão aquece o filme colorido e vaporiza a imagem em papel especialmente coberto.
A dye-sub é bastante conhecida no mundo do design e publicações, assim como no campo da
pesquisa científica, onde é necessário ter precisão e detalhes. Tais detalhes e qualidade de im-
pressão têm um preço, já que as impressoras dye-sub também são conhecidas por seus altos
custos-por-página.

Impressoras de Tinta Sólida


Usadas principalmente nos setores de embalagens e design industrial, as impressoras de tinta
sólida são famosas por imprimir numa variedade de tipos de papel. As impressoras de tinta sólida,
como o nome implica, usam espetos de tinta endurecidos, que são derretidos e espirrados através
de pequenos bocais na cabeça de impressão. O papel é então enviado através de um rolamento
fusor, que por sua vez força a tinta sobre o papel.
A impressora de tinta sólida é ideal para provas e protótipos de novos designs de embalagens de
produtos. Sendo assim, a maioria das empresas de serviços não 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 padrão e justificado, sem nenhuma variação no tipo ou tamanho da fonte. Hoje em
dia, as impressoras são capazes de processar documentos complexos com imagens, gráficos e tabelas
integrados, em diversos moldes e linguagens; tudo numa só página. Tal complexidade deve aderir
àlgumas convenções de formato. Foi isso que acelerou o desenvolvimento da linguagem de descrição
da página (ou PDL - page description language) — uma linguagem especializada de formatação de
documentos criada especialmente para a comunicação de computadores com impressoras.
Ao longo dos anos, os fabricantes de impressoras desenvolveram suas próprias linguagens propri-
etárias para descrever os formatos de documentos. No entanto, tais linguagens proprietárias se apli-
cavam somente às impressoras criadas pelos próprios fabricantes. Se, por exemplo, você tivesse que
enviar um arquivo pronto para impressão usando uma PDL proprietária para um jornalista profis-
sional, não havia garantia de que seu arquivo seria compatível com as máquinas da impressora. Veio
então a questão da portatibilidade.
A Xerox® desenvolveu o protocolo Interpress™ para a sua linha de impressoras, mas a adoção to-
tal desta linguagem pelo resto da indústria da impressão nunca ocorreu. Dois desenvolvedores do
Interpress original deixaram a Xerox e formaram a Adobe®, uma empresa de software dedicada ba-
sicamente aos gráficos eletrônicos e profissionais de documentação. Na Adobe, desenvolveram uma
Capítulo 7. Impressoras e Impressão 143

PDL amplamente adotada, chamada PostScript™, que usa uma linguagem markup para descrever
a formatação de texto e informações da imagem que podiam ser processadas por impressoras. Ao
mesmo tempo, a empresa Hewlett-Packard® desenvolveu a Printer Control Language™ (Linguagem
de Controle de Impressão ou PCL) para o uso em toda a sua linha de impressoras à laser e jato de tinta.
A PostScript e a PCL são PDLs amplamente adotadas agora e suportadas pela maioria dos fabricantes
de impressoras.
As PDLs funcionam sob o mesmo princípio das linguagens de programação de computador. Quando
um documento está pronto para impressão, o PC ou estação de trabalho pega as imagens, as in-
formações tipográficas e o layout do documento, e os utiliza como objetos que formam instruções
para a impressora processar. A impressora então traduz estes objetos em rasters, uma série de linhas
scaneadas que formam uma imagem do documento (chamado Raster Image Processing ou RIP), e
imprime o output na página como uma imagem completa, com texto e gráficos inclusos. Este pro-
cesso torna a impressão de documentos mais consistente, resultando em pouca ou nenhuma variação
ao imprimir o mesmo documento em modelos diferentes de impressora. As PDLs são desenvolvidas
para serem portáveis a qualquer formato e escaláveis para caberem em formatos diferentes de papel.
A escolha da impressora apropriada é uma questão de determinar quais os padrões 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 gráfico requer uma PCL ou alguma forma
de impressão proprietária, você também deve levar isso em consideração.

7.7. Impressoras em Rede Versus Locais


Dependendo das necessidades, pode ser desnecessário atribuir uma impressora para cada funcionário
de sua empresa. Tal despesa pode abocanhar grandes porções do seu orçamento, deixando menos
capital para as outras necessidades. Apesar das impressoras locais conectadas através de um cabo
paralelo ou USB a cada estação de trabalho serem uma solução ideal para o usuário, geralmente não
é economicamente viável.
Os fabricantes de impressoras resolveram esta questão ao desenvolver impressoras departamentais
(ou workgroup). Estas máquinas são geralmente duráveis, rápidas e têm consumíveis de longa du-
ração. As impressoras workgroup são frequentemente conectadas a um servidor de impressão (como
uma estação de trabalho reconfigurada), que direciona o output para a impressora apropriada quando
disponível. Impressoras departamentais mais recentes incluem interfaces de rede integradas ou anexas
que eliminam a necessidade de um servidor de impressão dedicado.

7.8. Informações Específicas do Red Hat Enterprise Linux


Veja a seguir as descrições das diversas funcionalidades relacionadas às impressoras e impressão,
específicas ao Red Hat Enterprise Linux.
A Ferramenta de Configuração da Impressora permite aos usuários configurar uma impressora.
Esta ferramenta ajuda a manter o arquivo de configuração da impressora, os diretórios spool e filtros
de impressão.
O Red Hat Enterprise Linux 4 usa o sistema de impressão CUPS. Se foi executado um upgrade de
uma versão anterior do Red Hat Enterprise Linux que usava o CUPS, o processo de upgrade preservou
as filas configuradas.
Usar a Ferramenta de Configuração da Impressora requer privilégios root. Para iniciar a aplicação,
selecione Botão do Menu Principal (no Painel) => Configurações do Sistema => Impressão, ou
digite o comando system-config-printer. Este comando determina automaticamente se deve
rodar a versão gráfica ou texto, dependendo se o comando é executado no ambiente gráfico ou a partir
de um console de texto.
144 Capítulo 7. Impressoras e Impressão

Para forçar a Ferramenta de Configuração da Impressora a rodar no modo texto, execute o co-
mando system-config-printer-tui em uma janela de comandos.

Importante
Não edite o arquivo /etc/printcap ou os arquivos do diretório /etc/cups/. A cada vez que o
daemon da impressora (cups) é iniciado ou reiniciado, são criados novos arquivos de configuração
dinamicamente. Estes arquivos são criados dinamicamente também quando as alterações são apli-
cadas à Ferramenta de Configuração da Impressora.

Figura 7-1. Ferramenta de Configuração da Impressora

Os seguintes tipos de filas de impressão podem ser configurados:

• Conectada localmente — uma impressora ligada diretamente ao computador através de uma porta
paralela ou USB.
• CUPS em Rede (IPP) — uma impressora que pode ser acessada através de uma rede TCP/IP pelo
Protocolo de Impressão da Internet, também 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 através 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 através de uma rede SMB (ex.: uma impressora conectada a uma máquina 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, através da HP JetDirect, ao
invés de conectada ao computador.
Capítulo 7. Impressoras e Impressão 145

Importante
Se você adicionar uma nova fila de impressão ou modificar uma fila existente, deve aplicar as alter-
ações para que estas tenham efeito.

Clicar no botão Aplicar salva quaisquer alterações feitas e reinicia o daemon de impressão. As alter-
ações não são gravadas no arquivo de configuração até que o daemon de impressão seja reiniciado.
Alternativamente, você pode clicar em Ação (Action) => Aplicar (Apply).
Para mais informações sobre a configuração de impressoras sob o Red Hat Enterprise Linux, consulte
o Guia de Administração de Sistemas Red Hat Enterprise Linux.

7.9. Recursos Adicionais


A configuração da impressão e impressão em rede são tópicos abrangentes que requerem conheci-
mento e experiência em hardware, rede e administração de sistemas. Para informações mais detalhadas
sobre o emprego de serviços de impressão em seus ambientes, consulte os seguintes recursos.

7.9.1. Documentação Instalada

• Página man lpr(1) — Aprenda a imprimir arquivos selecionados na sua impressora predileta.
• Página man lprm(1) — Aprenda a remover trabalhos de impressão da fila de impressão.
• Página man cupsd(8) — Aprenda sobre o daemon de impressão CUPS.
• Página man cupsd.conf(5) — Aprenda sobre o formato do arquivo de configuração do daemon
de impressão CUPS.
• Página man classes.conf(5) — Aprenda sobre o formato do arquivo de configuração da classe
CUPS.
•  
Arquivos do diretório /usr/share/doc/cups- version — Aprenda mais sobre o sistema de
impressão CUPS.

7.9.2. Sites Úteis

• http://www.webopedia.com/TERM/p/printer.html — Definições gerais das impressoras e


descrições dos tipos de impressora.
• http://www.linuxprinting.org/ — Um banco de dados com documentos sobre impressão, juntamente
a um banco de dados com aproximadamente 1000 impressoras compatíveis com as funcionalidades
de impressão do Linux.
• http://www.cups.org/ — Documentação, FAQ e grupos de discussão sobre o CUPS.

7.9.3. Livros Relacionados

• Network Printing de Matthew Gast e Todd Radermacher; O’Reilly & Associates, Inc. — Infor-
mações detalhadas sobre o uso do Linux como um servidor de impressão em ambientes heterogê-
neos.
• O Guia de Administração de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. — Inclui um capí-
tulo sobre a configuração da impressora.
146 Capítulo 7. Impressoras e Impressão
Capítulo 8.
Planejamento para Desastres
O planejamento para desastres é um assunto fácil de esquecer para um administrador de sistemas —
não é 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 dramáticos (tais como incêndio, enchente ou tempestade) serem os
primeiros a virem à tona, os problemas mais comuns (como peões de obra cortarem cabos ou até
mesmo uma pia transbordada) também podem ser motivos de interrupção. Sendo assim, a definição
de desastre que um administrador de sistemas deve ter em mente é qualquer evento não planejado
que interrompe a operação normal da empresa.
Apesar de ser possível listar todos os tipos diferentes de desastres que podem acontecer, esta seção ex-
amina os principais fatores que fazem parte de cada tipo de desastre, para que cada possível exposição
seja examinada como um fator que pode levar a um desastre, e não em termos de sua probabilidade.

8.1. Tipos de Desastres


Em geral, há quatro fatores diferentes que podem acarretar num desastre. Estes fatores são:

• Falhas de hardware
• Falhas de software
• Falhas de ambiente
• Erros humanos

8.1.1. Falhas de Hardware


As falhas de hardware são fáceis de entender — o hardware falha e o trabalho sofre uma parada. O
que é mais difícil de entender é a natureza das falhas e como minimizar sua exposição a elas. Aqui
estão algumas táticas que você pode usar:

8.1.1.1. Guardar Hardware Reserva


Simplisticamente, a exposição a falhas de hardware pode ser reduzida ao guardar hardware reserva.
Obviamente, esta tática assume duas coisas:

• Alguém dentro do escritório tem as habilidades necessárias para diagnosticar o problema, identi-
ficar o hardware falho e substituí-lo.
• É possível substituir o hardware falho.
Estas questões estão detalhadas nas próximas seções.

8.1.1.1.1. Ter as Habilidades


Dependendo de sua experiência e do hardware envolvido, ter as habilidades necessárias pode não ser
um problema. No entanto, se você nunca trabalhou com hardware antes, pode pensar em pesquisar
cursos introdutórios sobre reparos em PCs. Apesar de cursos deste tipo não serem insuficientes para
prepará-lo para resolver problemas em um servidor de nível corporativo, é uma boa maneira de apren-
der o básico (uso apropriado de ferramentas e componentes, procedimentos para diagnóstico básico e
assim por diante).
148 Capítulo 8. Planejamento para Desastres

Dica
Antes de você experimentar reparar o hardware sozinho, certifique-se de que o hardware em
questão:

• Não esteja mais sob garantia


• Não esteja sob algum tipo de contrato de serviço/manutenção
Se você tentar reparar um componente de hardware coberto por uma garantia e/ou contrato de
serviço, provavelmente estará violando os termos destes acordos e prejudicando sua cobertura con-
tínua.

Entretanto, mesmo com habilidades mínimas, pode ser possível diagnosticar e substituir efetivamente
o hardware falho — se você escolher seu estoque de hardware de substituição apropriadamente.

8.1.1.1.2. O Que Estocar?


Esta questão ilustra a natureza complexa de qualquer coisa relativa à recuperação de desastres. Quando
considerar qual hardware estocar, aqui estão algumas questões a considerar:

• Tempo Máximo Permitido Fora do Ar


• A habilidade necessária para efetuar o reparo
• Disponibilidade de verba para os reservas
• Espaço de armazenamento necessário para os reservas
• Outros componentes de hardware que poderiam utilizar os mesmos reservas
Cada uma destas questões 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
mínimas para instalar, mas seria muito mais caro do que ter uma CPU ou módulo RAM reserva na
prateleira. No entanto, essa despesa pode valer a pena se a sua empresa tem dúzias de servidores
idênticos que podem beneficiar de um sistema reserva.
Independente da decisão final, a seguinte questão é inevitável e é abordada a seguir.

8.1.1.1.2.1. Quanto Estoque?


A pergunta sobre os níveis de estoque reserva também tem várias facetas. Aqui estão as principais
questões:

• Tempo Máximo Permitido Fora do Ar


• Taxa projetada de falhas
• Tempo estimado para reabastecer o estoque
• Disponibilidade de verba para os reservas
• Espaço de armazenamento necessário 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 máximo dois dias, e cuja peça 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).
Capítulo 8. Planejamento para Desastres 149

Por outro lado, um sistema que não pode estar fora do ar por mais de alguns minutos, e uma reserva
que talvez seja usada uma vez por mês (e pode levar diversas semanas para repôr) pode significar que
meia dúzia de reservas (ou mais) devem estar na prateleira.

8.1.1.1.3. Reservas Que Não São Reservas


Quando uma peça reserva não é reserva? Quando é um componente de hardware utilizado no cotid-
iano, mas também pode ser um componente reserva para um sistema mais prioritário, se necessário.
Esta tática tem alguns benefícios:

• Menos dinheiro direcionado a peças reservas "não-produtivas"


• Sabe-se que o hardware é operante
Há, no entanto, algumas desvantagens nesta tática:

• A produção normal da tarefa de prioridade mais baixa é interrompida


• Há uma expoisção caso o hardware de baixa prioridade falhe (não sobra um componente reserva
para o hardware de alta prioridade)
Dadas estas questões, o uso de um outro sistema de produção como reserva pode funcionar, mas
o sucesso dessa tática se desdobra na carga de trabalho específica do sistema e no impacto que a
ausência do sistema tem nas operações gerais do centro de dados.

8.1.1.2. Contratos de Serviço


Os contratos de serviço transferem o problema de falhas no hardware para outra pessoa. Tudo o que
você deve fazer é confirmar que a falha, de fato, ocorreu e que parece não ser uma causa relativa ao
software. Então, você faz uma ligação telefônica e aparece alguém para resolver a situação.
Parece muito simples. Mas, como a maioria das coisas na vida, há muito mais a observar do que o
que vemos à primeira vista. Aqui estão algumas questões que você deve considerar ao analisar um
contrato de serviço:

• Horas de cobertura
• Tempo de resposta
• Disponibilidade de peças
• Orçamento disponível
• Hardware a ser coberto
Nós exploramos cada um destes itens detalhadamente nas próximas seções.

8.1.1.2.1. Horas de Cobertura


Contratos de serviço diferentes são feitos para atender a diferentes necessidades; uma das maiores
variáveis entre contratos diferentes são as horas de cobertura. A não ser que você queira pagar caro
pelo privilégio, você não pode simplesmente ligar a qualquer hora e esperar que um técnico apareça
rapidamente.
Ao invés disso, dependendo do seu contrato, talvez você descubra que nem pode ligar para a em-
presa de serviços até uma certa data/hora, ou se puder, eles não enviarão um técnico até a data/hora
especificada no seu contrato.
150 Capítulo 8. Planejamento para Desastres

A maioria das horas de cobertura são definidas em horas ou dias durante os quais um técnico será
enviado. Algumas das horas de cobertura comuns são:

• Segunda a Sexta, das 09:00 às 17:00


• Segunda a Sexta, 12/18/24 horas por dia (com horas de início e fim concordadas entre as partes)
• Segunda a Sábado (ou Segunda a Domingo), mesmo horário 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 Sábados e Domingos.
Mas aqui também é possível reduzir custos se você quiser executar algum trabalho.

8.1.1.2.1.1. Serviço de Depósito


Se a sua situação não requer nada mais que a disponibilidade de um técnico durante o horário com-
ercial convencional e você tem experiência suficiente para poder determinar o que está quebrado,
você pode considerar o serviço de depósito. Conhecido por muitos nomes (incluindo serviço walk-in
e serviço drop-off ), os fabricantes talvez tenham depósitos de serviço onde os técnicos trabalham no
hardware trazido pelos clientes.
O serviço de depósito tem o benefício de ser tão rápido quanto você. Você não precisa esperar que um
técnico esteja disponível e apareça em sua empresa. Técnicos de depósitos não atendem ligações de
clientes, o que significa que haverá alguém para trabalhar no seu hardware assim que você chegar no
depósito.
Como o serviço de depósito é feito numa localidade central, há grandes chances de ter qualquer peça
necessária. Isto pode eliminar a necessidade de um despacho que leva dias ou esperar que a peça seja
encaminhada de um escritório para outro há centenas de quilômetros de distância.
No entanto, há algumas desvantagens. A mais óbvia é que você não pode escolher as horas de serviço
— você obtém o serviço quando o depósito está aberto. Um outro aspecto é que os técnicos não
trabalham depois de seu expediente, portanto se o seu sistema falhou às 16:30 de uma sexta-feira e
você entregou o sistema ao depósito às 17:00, ele não será analisado até que os técnicos cheguem ao
trabalho na manhã da segunda-feira seguinte.
Uma outra desvantagem é que o serviço de depósito depende da existência de um depósito próximo.
Se a sua empresa está localizada na área metropolitana, este provavelmente não é um problema. En-
tretanto, as empresas localizadas em zonas rurais podem descobrir que o depósito fica muito longe de
sua sede.

Dica
Ao considerar o serviço de depósito, pare um pouco e pense na logística de trazer o hardware para
o depósito. Você usará um veículo da empresa ou o seu? Se for usar o seu, ele tem o espaço e
capacidade de carga necessários? E o seguro? Será necessário mais de uma pessoa para carregar
e descarregar o hardware?
Apesar de serem preocupações simples, elas devem ser analisadas antes de tomar a decisão de
usar um serviço de depósito.

8.1.1.2.2. Tempo de Resposta


Além das horas de cobertura, muitos contratos de serviço especificam um nível de tempo de resposta.
Em outras palavras, quanto demora para o técnico chegar após ligar requisitando o serviço? Como
você pode imaginar, um tempo de resposta mais rápido acarreta num acordo de serviço mais caro.
Capítulo 8. Planejamento para Desastres 151

Há limites variáveis para o tempo de resposta. Por exemplo: o tempo de viagem do escritório do
fabricante à sua empresa tem uma grande influência nos tempos de resposta possíveis 1 . Os tempos
de resposta até quatro horas são geralmente inclusos nas ofertas mais rápidas. Os tempos de resposta
mais lentos variam entre oito horas (o que efetivamente torna-se o serviço do "dia seguinte" num
acordo baseado no horário comercial padrão), a 24 horas. Assim como com qualquer outro aspecto de
um contrato de serviço, até mesmo estes tempos são negociáveis — pelo preço correto.

Nota
Apesar de não ser uma ocorrência comum, você deve estar ciente que contratos de serviço com
cláusulas de tempo de resposta podem, às vezes, estressar o departamento de serviços de uma
empresa além de sua capacidade de resposta. Não se sabe de nenhuma empresa de serviços
ocupada que tenha enviado alguém — ninguém — numa chamada de serviço com tempo de re-
sposta curto somente para cumprir seu comprometimento com o tempo de resposta. Esta pessoa
aparentemente diagnostica o problema, ligando para o "escritório" para que alguém traga a "peça
correta."
De fato, eles estão apenas esperando chegar alguém que seja capaz de atender à chamada.
Apesar de ser compreensível observar isto sob curcunstâncias extraordinárias (tais como problemas
de energia que tenham afetado diversos sistemas em sua área de serviço), se este for um método
de operação constante, você deve contatar o gerente de serviços e pedir uma explicação.

Se a necessidade de seu tempo de resposta for restrita (e seu orçamento for adequadamente grande),
há uma tática que pode reduzir ainda mais seu tempo de resposta — para zero.

8.1.1.2.2.1. Tempo de Resposta Zero — Ter um Técnico Interno


Dada a situação apropriada (você é um dos maiores clientes na área), necessidades suficientes
(qualquer tempo fora do ar é inaceitável) e recursos financeiros (se você precisa perguntar o preço,
provavelmente não pode pagar), você pode precisar de um técnico interno por tempo integral. Os
benefícios de ter um técnico sempre presente são óbvios:

• Resposta instantânea a qualquer problema


• Uma tática mais pró-ativa para a manutenção do sistema
Como esperado, esta opção pode ser muito cara, especialmente se você requer um técnico interno 24
horas por dia, 7 dias por semana. Mas, se esta tática é apropriada para sua empresa, você deve ter
alguns pontos em mente para tirar o máximo proveito.
Primeiramente, técnicos internos precisam de muitos dos recursos dos funcionários regulares, como
uma mesa de trabalho, telefone, cartões e/ou chaves de acesso apropriados e assim por diante.
Os técnicos internos não são muito úteis se não tiverem as peças apropriadas. Sendo assim, certifique-
se de ter um armazenamento seguro à parte para as peças do técnico. Além disso, assegure que o
técnico mantenha um estoque das peças apropriado para a sua configuração e que estas peças não
sejam "canibalizadas" rotineiramente por outros técnicos.

1. E isto provavelmente seria o tempo de resposta na melhor das hipóteses, já que os técnicos geralmente são
responsáveis por territórios que abrangem longas distâncias em todas as direções. Se você está numa extremidade
do território e o único técnico disponível está na outra extremidade, o tempo de resposta será ainda mais longo.
152 Capítulo 8. Planejamento para Desastres

8.1.1.2.3. Disponibilidade das Peças


Obviamente, a disponibilidade das peças tem um papel fundamental na limitação das falhas de hard-
ware da sua empresa. No contexto de um contrato de serviço, a disponibilidade das peças toma outra
dimensão, já que aplica-se não somente à sua empresa, mas a todos os outros clientes que também
possam precisar destas peças no território do fabricante. Uma empresa, que tenha comprado mais
hardware do fabricante que você, pode receber tratamento preferencial no momento de obter peças (e
técnicos, por este motivo).
Infelizmente, há pouco a fazer nestas circunstâncias, além de tentar resolver o problema com o gerente
de serviços.

8.1.1.2.4. Orçamento Disponível


Conforme esplanado anteriormente, os contratos de serviço variam de preço de acordo com a natureza
dos serviços oferecidos. Tenha em mente que os custos associados ao contrato de serviço são 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 mínimos. Considere por um momento que você
negociou um contrato de serviço que inclua um técnico interno 24x7, peças 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 alguém interno 24x7? Mesmo que o PC seja vital para o trabalho da
recepcionista, ela só trabalha das 9:00 às 17:00. É muito improvável que:

• O PC esteja em uso das 17:00 às 9:00 da manhã seguinte (sem falar nos finais de semana)
• Uma falha deste PC seja notada, exceto entre 9:00 e 17:00.
Sendo assim, pagar pela possibilidade deste PC precisar de serviços num sábado à noite é um des-
perdício de dinheiro.
A melhor coisa a fazer é dividir o contrato de serviços de maneira que o hardware não crítico seja
agrupado separadamente do hardware mais crítico. Desta maneira, os custos podem ser mantidos o
mais baixos possível.

Nota
Se você tem vinte servidores configurados identicamente que são críticos para sua empresa, você
pode ter um contrato de serviços de alto nível escrito para somente um ou dois, com o resto coberto
por um contrato bem mais barato. Então, seguindo este raciocínio, independente de qual servidor
falhar num final de semana, você dirá que é aquele com serviço de alto nível.
Não faça isso. Não é apenas desonesto, mas a maioria dos fabricantes mantém registro destas
coisas usando os números de série. Mesmo se você descobrir uma maneira de burlar estas verifi-
cações, gastará bem mais depois que for descoberto do que se for honesto e pagar pelo serviço que
realmente precisa.
Capítulo 8. Planejamento para Desastres 153

8.1.2. Falhas de Software


Falhas de software podem resultar em tempos fora do ar mais longos. Por exemplo: os proprietários
de uma determinada marca computadores notável por suas características de alta disponibilidade re-
centemente passaram por isso. Um erro (bug) no código 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 situação ser o exemplo mais espetacular de uma falha de software, outras
falhas relativas ao software podem ser menos dramáticas, mas tão devastadoras quanto.
As falhas de software podem ocorrer em uma destas duas áreas:

• Sistema operacional
• Aplicações
Cada tipo de falha tem seus próprios impactos e é explorada detalhadamente nas seções seguintes.

8.1.2.1. Falhas no Sistema Operacional


Neste tipo de falha, o sistema operacional é responsável pelo rompimento do serviço. As falhas no
sistema operacional vêm de duas áreas:

• Quedas
• Pendências
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 produção.

8.1.2.1.1. Quedas
As quedas ocorrem quando o sistema operacional passa por uma condição de erro do qual não pode
se recuperar. As razões de quedas podem variar da inabilidade de resolver um problema básico de
hardware a um erro (bug) no código do kernel comprometendo o sistema operacional. Quando um
sistema operacional cai, o sistema deve ser reinicializado para poder continuar a produção.

8.1.2.1.2. Pendências
Quando o sistema operacional para de executar os eventos do sistema, o sistema leva a uma parada.
Isto é conhecido como pendência. As pendências podem ser causadas por deadlocks (dois consumi-
dores 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 final é
o mesmo — uma falta de produtividade total.

8.1.2.2. Falhas nas Aplicações


Ao contrário das falhas no sistema operacional, as falhas nas aplicações podem ser mais limitadas
no escopo de seu estrago. Uma única aplicação falha, dependendo da aplicação, pode impactar so-
mente uma pessoa. Por outro lado, se for uma aplicação de servidor servindo uma gama de aplicações
clientes, as consequências de uma falha podem ser mais alastradas.
As falhas nas aplicações, assim como as do sistema operacional, podem acarretar em pendências e
quedas; a única diferença é que aqui é a aplicação que está pendente ou caindo.
154 Capítulo 8. Planejamento para Desastres

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 diferenças óbvias (não é
necessário hardware reserva e a maior parte do trabalho pode ser feito pelo pessoal do suporte através
do telefone), os contratos de suporte a software podem ser bem parecidos aos de suporte a hardware.
O nível de suporte oferecido por um fabricante de software pode variar. Aqui estão algumas das
estratégias de suporte mais comuns aplicadas hoje:

• Documentação
• Auto-suporte
• Suporte via Internet ou e-mail
• Suporte telefônico
• Suporte na empresa (on-site)
Cada tipo de suporte é descrito mais detalhadamente nas seções seguintes.

8.1.2.3.1. Documentação
Apesar de frequentemente negligenciada, a documentação do software pode servir como uma ferra-
menta de suporte de primeiro nível. Sendo online ou impressa, a documentação geralmente contém as
informações necessárias para resolver muitas questões.

8.1.2.3.2. Auto-suporte
O auto-suporte baseia-se no cliente usar recursos online para resolver suas próprias questões 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 têm pouca ou nenhuma capacidade de seleção, o que faz com que o cliente tenha
que rolar de questão em questão na esperança de achar uma que atenda ao seu problema. As bases
de conhecimento tendem a ser mais sofisticadas de certa maneira, permitindo a inserção de termos
de procura. As bases de conhecimento também podem ser bastante extensas, tornando-as uma boa
ferramenta para a solução de problemas.

8.1.2.3.3. Suporte via Internet ou E-mail


Muitas vezes, o que parece ser um site de auto-suporte também inclui formulários baseados na Internet
ou endereços 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, é difícil obter as informações necessárias através deles, já
que sua preocupação principal é responder rapidamente cada e-mail e seguir para o próximo. A razão
disso é que praticamente todos os funcionários de suporte são avaliados pelo número de problemas
que resolvem. É difícil explicitar a intensidade das questões, pois há pouco a ser feito num e-mail para
estimular respostas rápidas e úteis — especialmente quando a pessoa lendo seu e-mail está apressada
para seguir ao próximo e-mail.
A maneira de obter o melhor serviço é garantir que seu e-mail aborde todas as questões que um técnico
de suporte possa perguntar, tais como:

• Descreva claramente a natureza do problema


• Inclua todos os números de versões pertinentes
Capítulo 8. Planejamento para Desastres 155

• Descreva o que você já fez para tentar resolver o problema (aplicou os últimos consertos, reinicial-
izou a máquina na configuração mínima, etc.)
Ao oferecer mais informações ao técnico de suporte, você tem mais chances de obter o suporte que
necessita.

8.1.2.3.4. Suporte Telefônico


Como o nome implica, o suporte telefônico significa conversar com um técnico de suporte via telefone.
Este estilo de suporte é mais parecido com o suporte a hardware; pode haver diversos níveis de suporte
disponíveis (com horas de cobertura e tempos de resposta diferentes, etc.).

8.1.2.3.5. Suporte na Empresa (on-site)


Também conhecido como consultoria on-site, o suporte on-site ao software normalmente é reservado
para resolver as questões específicas ou efetuar mudanças críticas, como instalação e configuração do
software inicial, grandes atualizações e assim por diante. Como esperado, este é o tipo mais caro de
suporte ao software disponível.
Mesmo assim, há situações em que o suporte na empresa (on-site) faz sentido. Como exemplo, con-
sidere uma empresa pequena com somente um administrador de sistemas. A empresa empregará seu
primeiro servidor de banco de dados, mas a aplicação (e a empresa) não é grande o suficiente para
justificar a contratação de um administrador de banco de dados dedicado. Nesta situação, pode ser
mais barato trazer um especialista do fabricante de banco de dados para efetuar a aplicação inicial (e,
talvez mais adiante, conforme a necessidade surgir) e então treinar o administrador de sistemas para
uma técnica que será usada raramente.

8.1.3. Falhas no Ambiente


Mesmo que o hardware esteja rodando perfeitamente, que o software esteja configurado corretamente
e funcionando como deveria, os problemas ainda podem ocorrer. Os problemas mais comuns que
ocorrem fora do próprio sistema têm relação com o ambiente físico no qual o sistema reside.
As questões ambientais podem ser divididas em quatro categorias principais:

• Integridade da construção
• Eletricidade
• Ar condicionado
• Clima e o mundo externo

8.1.3.1. Integridade da Construção


Para uma estrutura aparentemente simples, uma construção desempenha diversas funções. Oferece
proteção dos elementos. Oferece o micro-clima adequado para o conteúdo do prédio. Tem mecanis-
mos para oferecer energia e para proteger contra incêndios, roubos e vandalismo. Desempenhando
todas estas funções, não é surpreendente o que pode dar errado com um prédio. Aqui estão algumas
possibilidades a considerar:

• Vazamentos no telhado podem alagar centros de dados.


• Diversos sistemas do prédio (como água ou sistema de ar) podem falhar, tornando o edifício in-
abitável.
156 Capítulo 8. Planejamento para Desastres

• O chão pode ter capacidade de carga insuficiente para suportar o equipamento que você pretende
colocar no centro de dados.
É importante ter uma mente criativa ao pensar nas diversas maneiras que um edifício pode falhar. A
lista acima apenas pretende que você comece a seguir esta linha de raciocínio.

8.1.3.2. Eletricidade
Como a eletricidade é o que move qualquer sistema de computador, as questões relacionadas à energia
são primordiais para a mente dos administradores de sistemas em todo lugar. Há diversos aspectos
diferentes da energia, que são abordados em detalhes nas seções seguintes.

8.1.3.2.1. A Segurança de Sua Energia


Primeiramente, é necessário determinar o quão seguro seu abastecimento de energia deve ser. Assim
como em quase todos os outros centros de dados, você obtém sua energia de uma empresa local através
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 possível.

Dica
As empresas localizadas próximas aos limites de uma companhia energética talvez possam negociar
as conexões em duas seções de energia:

• Aquela prestando serviços na sua área


• Aquela da companhia energética vizinha
Os custos envolvidos em usar linhas de energia pela companhia energética vizinha são grandes, tor-
nando esta opção viável somente para empresas grandes. No entanto, estas empresas descobrem
que a redundância obtida compensa os custos em muitos casos.

As principais coisas a verificar são os métodos através dos quais a energia é trazida até a sede de sua
empresa e para dentro do edifício. As linhas de transmissão estão acima ou abaixo do solo? Linhas
acima do solo são suscetíveis a:

• Danos provocados por condições climáticas extremas (geadas, ventos, relâmpagos)


• Acidentes de trânsito que danificam 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 têm suas próprias desvantagens:

• Danos provocados por construtores escavando em lugares indevidos


• Enchente
• Relâmpago (apesar de menos perigoso para linhas acima do solo)
Continue seguindo as linhas de energia para dentro de seu edifício. Elas passam primeiro por um
transformador externo? Este transformador está protegido dos carros ou árvores que possam cair?
Todos os interruptores expostos estão protegidos contra o uso não autorizado?
Uma vez dentro do edifício, as linhas de energia (ou os painéis aos quais estão ligadas) podem ter
outros problemas? Por exemplo: um problema de encanamento pode inundar o quadro elétrico?
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
Capítulo 8. Planejamento para Desastres 157

com cargas que não pertençam a este? Se assim for, a carga externa pode, um dia, passar pela proteção
de sobrecarga do circuito, ’derrubando’ também o centro de dados.

8.1.3.2.2. Qualidade da Energia


Não é suficiente garantir que a fonte de energia do centro de dados seja o mais segura possível. Você
também deve preocupar-se com a qualidade da energia sendo distribuída pelo centro de dados. Há
diversos fatores que devem ser considerados:

Voltagem
A voltagem da energia de entrada deve ser estável, sem reduções de voltagem (frequentemente
chamadas de quedas, abatimentos ou brownouts) ou aumentos de voltagem (geralmente conheci-
dos como picos e surges).

Formato da onda
O formato da onda deve ser limpo, com THD (Distorção Harmônica Total) mínima.

Frequência
A frequência deve ser estável (a maioria dos países utiliza a frequência de 50Hz ou 60Hz).

Ruído
A energia não pode incluir nenhum ruído RFI (Interferência na Frequência de Rádio) ou EMI
(Interferência Eletro-Magnética).

Corrente
A energia deve ser suprida a uma taxa de corrente suficiente para rodar o centro de dados.
A energia suprida diretamente pela companhia energética geralmente não atende aos padrões
necessários para um centro de dados. Sendo assim, é preciso algum nível de condicionamento da
energia. Há diversas táticas possíveis:

Protetores contra picos de energia


Protetores contra picos de energia fazem exatamente o que o nome implica — eles filtram os
picos do suprimento de energia. A maioria não faz mais nada, deixando o equipamento vulnerável
aos danos de outros problemas relativos à energia.

Condicionadores de Energia
Os condicionadores de energia tentam uma tática mais detalhada. Dependendo da sofisticação da
unidade, os condicionadores de energia frequentemente podem resolver a maioria dos problemas
citados acima.

Gerador
Um gerador é basicamente um grande motor elétrico movido pelo seu suprimento de energia
normal. O motor é ligado a uma grande hélice, que por sua vez é ligada a um gerador. O motor
roda a hélice e o gerador, que gera eletricidade suficiente 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 hélice também oferece a habilidade de manter
a energia durante a falta de eletricidade, já que leva vários segundos para a hélice reduzir sua
velocidade até o ponto no qual não pode mais gerar energia.
158 Capítulo 8. Planejamento para Desastres

Suprimentos de Energia Ininterruptos


Alguns Suprimentos de Energia Ininterruptos (mais comumente conhecidos como UPSs) in-
cluem a maioria (se não todas) das funções de proteção de um condicionador de energia 2 .
Com as duas tecnologias listadas acima, nós iniciamos o tópico no qual a maioria das pessoas pensa ao
falar sobre energia — energia backup. Na próxima seção, exploraremos táticas 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 elétrica e pode durar de uma fração de segundo a semanas.
Como a duração do blackout pode variar drasticamente, é necessário utilizar a tática de prover energia
backup usando tecnologias diferentes para faltas de energia de durações diferentes.

Dica
Os blackouts mais frequentes duram, em média, alguns segundos; faltas de energia mais longas são
menos frequentes. Sendo assim, concentre primeiro em proteger seus sistemas contra blackouts de
alguns segundos de duração, e então trabalhe nos métodos para reduzir sua exposição à faltas mais
longas.

8.1.3.2.3.1. Provendo Energia Para os Próximos Segundos


Já que a maioria das faltas de energia duram somente alguns segundos, sua solução de energia backup
deve ter duas características principais:

• Tempo bem curto para trocar para energia backup (conhecido como tempo de transferência)
• Um tempo de execução (o tempo que a energia backup durará) medido de segundos a minutos
As soluções de energia backup que atendem a estas características são os geradores e UPSs. A hélice
do gerador permite que este continue produzindo eletricidade por tempo suficiente para faltas de
energia de aproximadamente um segundo. Os geradores tendem a ser bem grandes e caros, o que os
torna práticos para empresas de médio e grande porte.
Entretanto, uma outra tecnologia — chamada UPS — pode servir para situações nas quais o gerador
é muito caro. O UPS também pode lidar com faltas de energia mais longas.

8.1.3.2.3.2. Provendo Energia Para os Próximos Minutos


Os UPSs podem ser adquiridos em diversos tamanhos — suficientemente pequeno para rodar um PC
por cinco minutos ou suficientemente grande para prover energia para um centro de dados inteiro por
uma hora ou mais.
Os UPSs são compostos das seguintes partes:

• Um interruptor de transferência para mudar da fonte de energia principal para a fonte de energia
backup
• Uma bateria, para prover energia backup

2. A tecnologia UPS é abordada em mais detalhes na Seção 8.1.3.2.3.2.


Capítulo 8. Planejamento para Desastres 159

• Um conversor, que converte a corrente DC da bateria em corrente AC necessária para o hardware


do centro de dados
Além do tamanho e capacidade da bateria da unidade, os UPSs têm dois tipos básicos:

• O UPS offline usa seu conversor para gerar energia somente quando o suprimento de energia prin-
cipal falhar.
• O UPS online usa seu conversor para gerar energia o tempo todo, provendo energia para seu con-
versor através de sua bateria somente quando o suprimento de energia principal falhar.
Cada tipo tem suas vantagens e desvantagens. O UPS offline geralmente é mais barato, porque o
conversor não precisa ser construído para operação em tempo integral. No entanto, um problema no
conversor de um UPS offline passará desapercebido (ou seja, até a próxima falta de energia).
Os UPSs online tendem a ser melhores em prover energia limpa para o seu centro de dados; afinal de
contas, um UPS online basicamente gera energia o tempo todo para você.
Independente do tipo de UPS que você escolher, é necessário dimensioná-lo corretamente para sua
carga antecipada (assim garantindo que o UPS tenha capacidade suficiente para produzir eletricidade
na voltagem e corrente necessárias) e você deve determinar durante quanto tempo deseja ter a habili-
dade de rodar seu centro de dados com a energia da bateria.
Para determinar esta informação, você deve primeiramente identificar as cargas que serão servidas
pelo UPS. Verifique em cada componente do equipamento o montante de energia que gasta (isto
é normalmente especificado numa etiqueta próximo ao cabo de energia). Anote a voltagem, watts
e/ou amps. Quando você tiver estes dados para todos os componentes de hardware, deve convertê-
los para VA (Volt-Amps). Se você tiver um número de watts, pode usá-lo como o VA; se tiver amps,
multiplique-o por volts para obter o VA. Ao adicionar os valores VA, é possível obter a taxa VA
aproximada necessária para o UPS.

Nota
Na verdade, esta tática para calcular o VA não está totalmente correta; no entanto, para obter o
VA verdadeiro é necessário saber o fator de energia de cada unidade, e esta informação é rara-
mente provida. Em todo caso, os números VA obtidos com esta tática refletem os valores nas piores
situações, deixando uma grande margem de erro para segurança.

Determinar o tempo de execução é uma questão mais de negócios que técnica — contra quais tipos de
queda você deseja se proteger e quanto pretende gastar para tanto? A maioria das empresas seleciona
tempos de execução menores que uma ou duas horas no máximo, pois a energia backup provida pela
bateria torna-se muito cara além deste ponto.

8.1.3.2.3.3. Provendo Energia Para as Próximas Horas (e Além)


Quando atingirmos as quedas de energia medidas em dias, as opções tornam-se ainda mais caras. As
tecnologias com capacidade de lidar com quedas de energia de longo prazo são limitadas a geradores
movidos por algum tipo de motor — principalmente, a diesel e turbina a gás.

Nota
Tenha em mente que os geradores movidos a motores requerem o reabastecimento constante en-
quanto estão ligados. Você deve saber qual é a taxa de "consumo" de combustível do seu gerador
na capacidade máxima e coordenar a entrega apropriada de combustível.
160 Capítulo 8. Planejamento para Desastres

Neste ponto, você tem um grande leque de opções, assumindo que sua empresa tenha o orçamento
necessário. Esta também é uma área na qual os peritos devem ajudá-lo a determinar a melhor solução
para a empresa. Somente alguns administradores de sistemas tem o conhecimento especializado
necessário para planejar a aquisição e aplicação destes tipos de sistemas de geração de energia.

Dica
Geradores portáteis de todos os tamanhos podem ser alugados, possibilitando ter os benefícios da
energia do gerador sem a despesa inicial para adquirir um. No entanto, tenha em mente que nos
desastres que afetam sua vizinhança em geral, os geradores poderão 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 funcionários
num escritório 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 não houver energia para manter o controle ambiental no centro de dados?


• E se não houver energia para manter o controle ambiental no edifício inteiro?
• E se não houver energia para operar estações de trabalho, sistema de telefonia e/ou luzes?
A questão é determinar até que ponto uma queda deve ser tolerada em sua empresa. Ou, se esta não
for uma opção, sua empresa deve considerar operar completamente independente da energia dentro
da empresa por períodos extensos, o que significa que geradores muito grandes serão necessários para
prover energia para o edifício inteiro.
Obviamente, mesmo esse nível de planejamento não pode ser feito do nada. É muito provável que o
que causou a queda extensa também está afetando o mundo externo à sua empresa, e que o mundo
externo começará a afetar a habilidade da sua empresa em continuar operando, mesmo que tenha
capacidade ilimitada de geração de energia.

8.1.3.3. Aquecimento, Ventilação e Ar Condicionado


Os sistemas de Aquecimento, Ventilação e Ar Condicionado (Heating, Ventilation, and Air Condition-
ing - HVAC) usados nos edifícios hoje em dia são incrivelmente sofisticados. Geralmente controlado
por computadores, o sistema HVAC é vital para prover um ambiente de trabalho confortável.
Os centros de dados geralmente possuem equipamento próprio de refrigeração, principalmente para
remover o calor gerado pelos diversos computadores e outros equipamentos. As falhas no sistema
HVAC podem ser devastadoras para a operação contínua de um centro de dados. Dada sua complex-
idade e natureza eletro-mecânica, as possibilidades de falha são muitas e variadas. Aqui estão alguns
exemplos:

• As unidades de refrigeração (basicamente ventiladores grandes movidos por grandes motores elétri-
cos) podem falhar devido a sobrecarga elétrica, falha no rolamento, falha na correia/roldana, etc.
Capítulo 8. Planejamento para Desastres 161

• As unidades de refrigeração (frequentemente chamadas de chillers) podem perder sua refrigeração


devido a vazamentos, ou a problemas em seus motores e/ou compressores.
O reparo e a manutenção do sistema HVAC são áreas muito especializadas — áreas que um admin-
istrador 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 verificado diariamente (ou com mais
frequência) e seja mantido de acordo com as intruções do fabricante.

8.1.3.4. Fatores Climáticos e o Mundo Externo


Há alguns fatores climáticos que podem causar problemas ao administrador de sistemas:

• Muita neve e gelo podem impedir que funcionários cheguem ao centro de dados, e podem inclusive
entupir os condensadores do ar condicionado, resultando em temperaturas elevadas no centro de
dados exatamente quando ninguém consegue chegar até lá para tomar as devidas providências.
• Ventos fortes podem interromper a energia e as comunicações; ventos muito fortes podem, na real-
idade, danificar o próprio edifício.
Há outros fatores climáticos que podem causar problemas. Por exemplo: temperaturas excessivamente
altas podem resultar em sistemas de refrigeração sobrecarregados, ’brownouts’ ou blackouts, con-
forme o consumo de energia fica sobrecarregado.
Apesar de não haver muito a fazer sobre os fatores climáticos, saber como eles podem afetar as
operações 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 são perfeitos. A razão dessa afirmação é, que se você
investigar a fundo, descobrirá um erro humano por trás de todo erro do computador. Nesta seção,
exploramos os tipos de erros humanos mais comuns e seus impactos.

8.1.4.1. Erros de Usuários Finais


Os usuários de um computador podem cometer erros com sérios impactos. No entanto, devido seu
ambiente operacional normalmente desprivilegiado, os erros de usuários tendem a ser localizados.
Como a maioria dos usuários interage com um computador exclusivamente através de uma ou mais
aplicações, é dentro das aplicações que a maioria dos erros de usuários finais ocorre.

8.1.4.1.1. Uso Impróprio das Aplicações


Quando as aplicações são usadas impropriamente, vários problemas podem ocorrer:

• Arquivos sobrescritos inadvertidamente


• Dados errados usados como input numa aplicação
• Arquivos nomeados e organizados de maneira confusa
• Arquivos apagados acidentalmente
Poderíamos continuar esta lista, mas isso é suficiente para ilustrar a questão. Devido o fato de usuários
não terem privilégios de super-usuário, os erros cometidos por eles geralmente limitam-se aos seus
próprios arquivos. Sendo assim, a malhor tática é bifurcada:

• Educar os usuários no uso apropriado de suas aplicações e técnicas de administração de arquivos


162 Capítulo 8. Planejamento para Desastres

• Garantir que os backups dos arquivos dos usuários sejam feitos regularmente e que o processo de
restauração seja o mais simples e rápido possível
Além disso, há pouco a fazer para limitar os erros dos usuários.

8.1.4.2. Erros de Funcionários Operacionais


Os operadores tem uma relação mais profunda com os computadores da empresa que os usuários
finais. Enquanto os usuários finais tendem a se basear nas aplicações, 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 utilitários a nível 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 disponíveis para praticamente
todas as ações que executam 3. Pode acontecer de um operador não seguir os procedimentos conforme
são apresentados. Podem haver diversas razões para isso:

• O ambiente foi alterado em algum momento do passado e os procedimentos não foram atualizados.
Agora o ambiente mudou novamente, tornando inválidos os procedimentos memorizados pelo op-
erador. Neste ponto, mesmo que os procedimentos tenham sido atualizados (o que é improvável, já
que não foram atualizados anteriormente), o operador não estará ciente disso.
• O ambiente foi alterado e não há procedimentos. Esta é uma situação ainda mais fora de controle
que a anterior.
• Os procedimentos existem e estão corretos, mas o operador não os seguirá (ou não poderá seguí-
los).
Dependendo da estrutura gerencial de sua empresa, talvez você não possa fazer nada além de comu-
nicar suas preocupações ao gerente apropriado. Em todo caso, a melhor tática é colocar-se à disposição
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
é possível que erros ocorram. Se isto acontecer, existe a possibilidade do operador ter sido displicente
(neste caso a gerência do operador deve ser envolvida).
Uma outra explicação é 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 qualificados e capazes de resolverem muitos problemas sozinhos,
o fato é que este não é o trabalho deles. A boa vontade do operador pode piorar o problema, prejudicar
a carreira dele e também a sua habilidade em resolver rapidamente o que, originalmente, talvez fosse
um pequeno problema.

3. Se os operadores de sua empresa não possuem um conjunto de procedimentos operacionais, trabalhe com
eles, com a gerência e com seu usuários para criá-los. Sem eles, um centro de dados está fora de controle e
propenso a ter problemas sérios no dia-a-dia das operações.
Capítulo 8. Planejamento para Desastres 163

8.1.4.3. Erros do Administrador de Sistemas


Ao contrário dos operadores, os administradores de sistemas executam uma grande variedade de tare-
fas usando os computadores de uma empresa, e estas tarefas frequentemente não são baseadas em
procedimentos documentados.
Consequentemente, os administradores de sistemas algumas vezes executam trabalho desnecessário
quando não tomam cuidado com o que fazem. No curso de suas responsabilidades do dia-a-dia, os
administradores de sistemas têm suficiente acesso aos sistemas (sem mencionar seus privilégios de
super-usuário) para derrubá-los por engano.
Os administradores de sistemas cometem erros de má configuração ou erros durante a manutenção.

8.1.4.3.1. Erros de Má Configuração


Os administradores de sistemas frequentemente precisam configurar vários aspectos de um sistema.
Esta configuração pode incluir:

• E-mail
• Contas de usuários
• Rede
• Aplicações
A lista poderia continuar. A tarefa de configurar em si varia enormemente; algumas requerem editar
um arquivo texto (usando qualquer uma das centenas de sintaxes diferentes do arquivo de configu-
ração), enquanto outras tarefas requerem executar um utilitário de configuração.
O fato de estas tarefas serem feitas de maneiras diferentes é simplesmente um desafio adicional ao fato
de cada tarefa de configuração requerer um conhecimento diferente. Por exemplo: o conhecimento
necessário para configurar um agente de transportte de correio (mail transport agent) é fundamental-
mente diferente de configurar uma nova conexão de rede.
Sendo assim, talvez seja surpreendente que apenas alguns erros sejam cometidos. De qualquer
maneira, a configuração é, e continuará sendo, um desafio para administradores de sistemas. Há algo
a fazer para tornar o processo menos suscetível a erros?

8.1.4.3.1.1. Controle de Mudanças


Um aspecto comum de toda configuração é que sempre há alterações. Independente de ser uma pe-
quena ou grande alteração, deve ser tratada de maneira específica.
Muitas empresas implementam algum tipo de processo de controle de alterações. A intenção é auxiliar
administradores de sistemas (e todas as partes afetadas pela alteração) a gerenciar o processo de
alteração e reduzir a exposição da empresa a erros que possam ocorrer.
Um processo de controle de alterações geralmente divide a alteração em dois passos. Aqui está um
exemplo:

Pesquisa preliminar
Tentativas de pesquisa preliminar para definir claramente:
• A natureza da alteração a ocorrer
• Seu impacto, caso a alteração realmente ocorra
• Uma posição de resguarda, se a alteração falhar
• Uma avaliação dos possíveis tipos de falha
164 Capítulo 8. Planejamento para Desastres

A pesquisa preliminar pode incluir testes da alteração proposta durante um tempo fora do ar
agendado, ou pode incluir a implementação da alteração primeiramente num ambiente de teste
especial executado em hardware de teste.

Agendamento
A alteração é examinada tendo em mente a mecânica da implementação. O agendamento inclui
apontar a sequência e o tempo da alteração (juntamente a sequências e tempos de quaisquer pas-
sos necessários para retornar ao estado original caso ocorra algum problema), e também garantir
que o tempo alocado para a alteração é suficiente e não conflitante com nenhuma outra atividade
no nível do sistema.
O produto deste processo é frequentemente uma lista de passos para o administrador de sistemas
usar enquanto executa a alteração. Juntamente a cada um dos passos, incluimos as instruções para
retornar ao estado original, caso a alteração falhar. Os tempos estimados também são inclusos,
facilitando ao administrador de sistemas determinar se o trabalho está dentro do prazo ou não.

Execução
Neste ponto, a execução dos passos necessários para implementar a alteração deve ser simples e
anti-climática. A alteração é então implementada ou, se houver problemas, abortada.

Monitoramento
Independente da alteração ser implementada ou não, o ambiente é monitorado para garantir que
tudo está sendo operado devidamente.

Documentando
Se a alteração foi implementada, toda a documentação existente deve ser atualizada para refletir
a configuração alterada.
Obviamente, nem todas as alterações requerem este nível de detalhe. Criar uma nova conta de usuário
não 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 execução também deve ser rápida; o
monitoramento deve se restringir a garantir que a conta é utilizável e a documentação provavelmente
seria enviar um e-mail ao gerente do novo usuário.
Mas, conforme as alterações de configuração tornam-se mais complexas, é necessário ter um processo
de controle de alterações mais formal.

8.1.4.3.2. Erros Cometidos Durante a Manutenção


Este tipo de erro pode ser maléfico porque geralmente há muito pouco planejamento e registro feitos
durante a manutenção diária.
Os administradores de sistemas vêem diariamente os resultados deste tipo de erro, especialmente
cometidos por muitos usuários que juram não alterarem nada — o computador simplesmente quebrou.
O usuário que diz isso geralmente não lembra o que fez, e quando o mesmo acontece com você,
provavelmente você também não lembrará.
A principal questão é que você deve ser capaz de lembrar das alterações efetuadas durante a
manutenção, se for capaz de resolver qualquer problema rapidamente. Um processo de controle
completo não é 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 comentários nos arquivos afetados, anote! Ao registrar o que você fez, tem maiores chances de
relacionar uma falha a uma alteração recentemente efetuada.
Capítulo 8. Planejamento para Desastres 165

8.1.4.4. Erros do Técnico de Serviço


Às vezes, as pessoas que supostamente te ajudariam a manter seus sistemas rodando confiavelmente,
podem tornar as coisas piores. Isto não se deve a nenhuma conspiração; simplesmente qualquer um
trabalhando em alguma espécie 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 técnico falhou em diagnosticar o problema corretamente e efetuou um conserto
desnecessário (e inútil), ou o diagnóstico estava correto, mas o conserto não foi efetuado
apropriadamente. Pode ser que a peça substituída estava com defeito, ou que o procedimento
apropriado não foi seguido durante o conserto.
Por isso é importante estar ciente do que os técnicos estão fazendo todo o tempo. Ao fazer isso, você
pode estar atento a falhas que parecem estar relacionadas ao problema original de alguma maneira. Isto
mantém o registro do técnico caso haja algum problema; caso contrário há uma chance do técnico ver
esta falha como nova e não relacionada àquela supostamente consertada. Desta maneira, não perde-se
tempo verificando 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 prob-
lema para tomar seu lugar. O módulo da CPU foi substituído, mas o saco anti-estático no qual ele
estava embrulhado foi deixado dentro do cabinete, bloqueando o ventilador e causando um desliga-
mento por causa da temperatura elevada. Ou então o drive falho do disco no conjunto RAID foi
substituído, mas como um conector em outro drive foi esbarrado e acidentalmente desconectado, o
conjunto ainda está com problemas.
Não importa se estas coisas são resultado de descuido crônico ou simplesmente um erro honesto.
Você deve sempre rever cuidadosamente os consertos feitos pelo técnico e garantir que o sistema
esteja funcionando corretamente antes que o técnico vá embora.

8.2. Backups
Os backups tem dois objetivos principais:

• Permitir a recuperação de arquivos individuais


• Permitir a recuperação de sistemas de arquivo inteiros de uma só vez
O primeiro objetivo é a base do típico pedido de recuperação de arquivo: um usuário apaga aciden-
talmente um arquivo e pede que seja recuperado pelo último backup. As circunstâncias exatas podem
variar, mas este é o uso cotidiano mais comum para backups.
A segunda situação é o pior pesadelo do administrador de sistemas: por alguma razão, o administrador
de sistemas está mexendo no hardware que era uma parte produtiva do centro de dados. Agora, é algo
mais do que um pedaço de aço e silicone. O que falta são todos os software e dados que você e seus
usuários vem desenvolvendo ao longo dos anos. Supostamente, há backup de tudo. A questão é: há
realmente este backup?
E se houver, você é capaz de recuperá-lo?
166 Capítulo 8. Planejamento para Desastres

8.2.1. Dados Diferentes: Necessidades Diferentes de Backup


Atente para os tipos de dados4 processados e armazenados por um sistema de computador típico. Note
que alguns dados quase nunca mudam, e outros estão em mudança constante.
A velocidade na qual os dados são alterados é crucial para desenvolver um procedimento de backup.
Há duas razões para isso:

• Um backup nada mais é do que uma imagem instantânea dos dados sendo copiados. É um reflexo
dos dados em um determinado momento.
• Dados que são alterados com pouca frequência podem ter backups com pouca frequência, enquanto
dados com alterações frequentes devem ter backups mais frequentes.
Os administradores de sistemas que têm um bom conhecimento de seus sistemas, usuários e aplicações
devem ser capazes de agrupar os dados em categorias diferentes nos seus sistemas. No entanto, aqui
estão alguns exemplos para que você possa começar:

Sistema Operacional
Estes dados são normalmente alterados somente durante atualizações (upgrades), instalações de
consertos de erros (bug fixes) e quaisquer modificações específicas da empresa.

Dica
Você deve se importar com backups do sistema operacional? Esta é uma questão que muitos
administradores de sistemas vêm ponderando ao longo dos anos. De um lado, se o processo
de instalação é relativamente fácil, e se a aplicação de consertos de erros e personalizações
são bem documentadas e de fácil reprodução, reinstalar o sistema operacional pode ser uma
opção viável.
Por outro lado, se há alguma dúvida que uma nova instalação pode recriar o ambiente do
sistema operacional original, fazer backup do sistema operacional é a melhor opção, mesmo
que os backups sejam feitos com menor frequência que os backups dos dados de produção.
Backups ocasionais do sistema operacional também podem ser práticos quando apenas alguns
arquivos do sistema precisarem ser restaurados (ex.: devido à remoção acidental de arquivos).

Software da Aplicação
Estes dados são alterados sempre que as aplicações são instaladas, atualizadas ou removidas.

Dados das Aplicações


Estes dados são alterados com a mesma frequência que as aplicações são utilizadas. Dependendo
da aplicacão e da sua empresa, isto pode significar que as alterações ocorrem a cada segundo ou
uma vez no final de cada ano fiscal.

Dados dos Usuários


Estes dados alteram de acordo com os padrões de uso da sua comunidade de usuários. Na maioria
das empresas, isto significa que as alterações ocorrem toda hora.
Baseando-se nestas categorias (e outras específicas à sua empresa), você deve ter uma boa idéia sobre
a natureza dos backups necessários para proteger seus dados.

4. Estamos usando o termo dados nesta seção para descrever tudo o que é processado através do software de
backup. Isto inclui o software do sistema operacional, o software da aplicação e também os dados atuais. Não
importa o que são; desde que a preocupação seja software de backup, tudo são dados.
Capítulo 8. Planejamento para Desastres 167

Nota
Você deve ter em mente que a maioria dos software de backup lida com os dados no nível do diretório
ou sistema de arquivo. Em outras palavras, a estrutura dos diretórios de seu sistema influenciam o
modo como os backups serão feitos. Esta é uma outra razão para pensar cuidadosamente na melhor
estrutura de diretórios para um novo sistema e agrupar arquivos e diretórios de acordo com seu uso
antecipado.

8.2.2. Software de Backup: Comprar versus Criar


Para executar backups, é necessário ter primeiramente o software apropriado. Este software deve não
somente executar a tarefa básica de copiar bits em mídia de backup, mas também interagir claramente
com os funcionários e necessidades de sua empresa. Aqui estão algumas características a considerar
ao analisar o software de backup:

• Agenda os backups para rodarem num horário apropriado


• Administra a localização, rotação e o uso da mídia de backup
• Trabalha com operadores (e/ou com alteradores de mídia robótica) para garantir que a mídia apro-
priada está disponível
• Auxilia os operadores na localização da mídia contendo o backup específico de um determinado
arquivo
Como você pode ver, uma boa solução de backup significa bem mais do que somente enviar bits para
sua mídia de backup.
Neste ponto, a maioria dos administradores de sistemas procura por uma das duas soluções:

• Comprar uma solução desenvolvida comercialmente


• Criar um sistema de backup internamente do zero (possivelmente intergrando uma ou mais tecnolo-
gias open source)
Cada uma destas táticas tem seus pontos fortes e fracos. Dada a complexidade do trabalho, uma
solução criada internamente provavelmente não atenderá alguns aspectos (como administração da
mídia ou ter documentação detalhada e suporte técnico) apropriadamente. Entretanto, para algumas
empresas, isto pode não ser uma desvantagem.
Uma solução desenvolvida comercialmente provavelmente é altamente funcional, mas também pode
ser muito complexa para as necessidades atuais da empresa. Sendo assim, a complexidade pode pos-
sibilitar continuar com a mesma solução conforme a empresa crescer.
Portanto, não 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 é difícil; 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 soft-
ware de backup significa que você terá que manter o software original (para acessar os backups
arquivados), ou deverá converter seus backups arquivados para serem compatíveis com o software
novo.
Dependendo do software de backup, o esforço envolvido em converter os backups arquivados pode
ser tão simples (mas demorado) quanto rodar os backups através de um programa de conversão já
existente, ou pode ser necessária engenharia reversa no formato do backup e desenvolver software
personalizado para executar a tarefa.
168 Capítulo 8. Planejamento para Desastres

• O software deve ser 100% confiável — deve fazer o backup do que for necessário e quando for
necessário.
• Quando chegar o momento de restaurar quaisquer dados — seja um arquivo ou um sistema de
arquivos inteiro — o software de backup deve ser 100% confiável.

8.2.3. Tipos de Backups


Se você perguntar a alguém que não é familiarizado com backups, a maioria pensará que um backup
é somente uma cópia idêntica de todos os dados do computador. Em outras palavras, se um backup
foi criado na noite de terça-feira, e nada mudou no computador durante o dia todo na quarta-feira, o
backup criado na noite de quarta seria idêntico àquele criado na terça.
Apesar de ser possível configurar backups desta maneira, é mais provável que você não o faça. Para
entender mais sobre este assunto, devemos primeiro entender os tipos diferentes de backup que podem
ser criados. Estes são:

• Backups completos
• Backups incrementais
• Backups diferenciais

8.2.3.1. Backups Completos


O tipo de backup abordado no início desta seção é conhecido como um backup completo. Este tipo
consiste no backup de todos os arquivos para a mídia de backup. Conforme mencionado anterior-
mente, se os dados sendo copiados nunca mudam, cada backup completo será igual aos outros.
Esta similaridade ocorre devido o fato que um backup completo não verifica se o arquivo foi alterado
desde o último backup; copia tudo indiscriminadamente para a mídia de backup, tendo modificações
ou não.
Esta é a razão pela qual os backups completos não são feitos o tempo todo — todos os arquivos são
gravados na mídia de backup. Isto significa que uma grande parte da mídia 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 não é uma boa prática; por este motivo os backups incrementais
foram criados.

8.2.3.2. Backups Incrementais


Ao contrário dos backups completos, os backups incrementais primeiro verificam se o horário de
alteração de um arquivo é mais recente que o horário de seu último backup. Se não for, o arquivo
não foi modificado desde o último backup e pode ser ignorado desta vez. Por outro lado, se a data
de modificação é mais recente que a data do último backup, o arquivo foi modificado e deve ter seu
backup feito.
Os backups incrementais são usados em conjunto com um backup completo frequente (ex.: um backup
completo semanal, com incrementais diários).
A vantagem principal em usar backups incrementais é que rodam mais rápido que os backups comple-
tos. A principal desvantagem dos backups incrementais é que para restaurar um determinado arquivo,
pode ser necessário procurar em um ou mais backups incrementais até encontrar o arquivo. Para
restaurar um sistema de arquivo completo, é necessário 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 imple-
mentada uma tática ligeiramente diferente. Esta é conhecida como backup diferencial.
Capítulo 8. Planejamento para Desastres 169

8.2.3.3. Backups Diferenciais


Backups diferenciais são similares aos backups incrementais pois ambos podem fazer backup somente
de arquivos modificados. No entanto, os backups diferenciais são acumulativos — em outras palavras,
no caso de um backup diferencial, uma vez que um arquivo foi modificado, este continua a ser incluso
em todos os backups diferenciais (obviamente, até o próximo backup completo).
Isto significa que cada backup diferencial contém todos os arquivos modificados desde o último
backup completo, possibilitando executar uma restauração completa somente com o último backup
completo e o último backup diferencial.
Assim como a estratégia utilizada nos backups incrementais, os backups diferenciais normalmente
seguem a mesma tática: um único backup completo periódico 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 modificados entre os backups completos). Isto
posiciona os backups diferenciais em algum ponto entre os backups incrementais e os completos em
termos de velocidade e utilização da mídia de backup, enquanto geralmente oferecem restaurações
completas e de arquivos mais rápidas (devido o menor número de backups onde procurar e restaurar).
Dadas estas características, os backups diferenciais merecem uma consideração cuidadosa.

8.2.4. Mídia de Backup


Nós fomos muito cuidadosos ao usar o termo "mídia de backup" no decorrer das seções anteriores.
Há uma razão para isso. A maioria dos administradores de sistemas experientes geralmente pensam
em backups em termos de leitura e gravação de fitas, mas atualmente há outras opções.
Houve um tempo em que os dispositivos de fita eram os únicos dispositivos de mídia removíveis que
podiam ser usados para backups. No entanto, isto mudou. Nas seções seguintes, veremos as mídias de
backup mais conhecidas e assim como suas vantagens e desvantagens.

8.2.4.1. Fita
A fita foi o primeiro meio de armazenamento de dados removível amplamente utilizado. Tem os
benefícios de custo baixo e uma capacidade razoavelmente boa de armazenamento. Entretanto, a fita
tem algumas desvantagens — está sujeita ao desgaste e o acesso aos dados na fita é sequencial por
natureza.
Estes fatores significam que é necessário manter o registro do uso das fitas (aposentá-las ao atingirem
o fim de suas vidas úteis) e também que a procura por um arquivo específico nas fitas pode ser uma
tarefa longa.
Por outro lado, a fita é uma das mídias de armazenamento em massa mais baratas e carrega uma longa
reputação de confiabilidade. Isto significa que criar uma biblioteca de fitas de tamanho razoável não
abocanha uma parcela grande de seu orçamento, e você pode confiar 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 preços de armazenamento caíram a um ponto que, em alguns casos, usar drives de disco para
armazenamento de backup faz sentido.
A razão principal para usar drives de disco como um meio de backup é a velocidade. Não há um meio
de armazenamento em massa mais rápido. A velocidade pode ser um fator crítico 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 não é o meio ideal de backup, por diversas razões:
170 Capítulo 8. Planejamento para Desastres

• Os drives de disco normalmente não são removíveis. Um fator essencial para uma estratégia 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 produção há um metro
de distância do banco de dados propriamente dito não é um backup; é uma cópia. As cópias não
são muito úteis, caso o centro de dados e seu conteúdo (incluindo suas cópias) seja danificado ou
destruído por um conjunto de infortúnios.
• Os drives de disco são caros (ao menos se comparados a outras mídias de backup). Pode haver
situações onde o dinheiro não é o problema, mas em todas as outras situações, as despesas associ-
adas ao uso de drives de disco para backup significam que o número de cópias de backup deve ser
baixo para manter o custo total dos backups também baixo. Um número menor de cópias de backup
significa redundância menor, caso um backup não seja legível por alguma razão.
• Os drives de disco são frágeis. Mesmo se você gastar dinheiro extra com drives de disco removíveis,
sua fragilidade pode ser um problema. Se você derrubar um drive de disco no chão, perde seu
backup. É possível adquirir estojos especiais que podem reduzir (mas não eliminar totalmente) este
problema, mas isto encarece ainda mais esta opção.
• Os drives de disco não são mídia 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 manutenção de
registros disponíveis por determinados períodos de tempo. A chance de obter dados utilizáveis de
uma fita de 20 anos atrás é muito maior que a chance de obter dados utilizáveis de um drive de disco
de 20 anos. Por exemplo: você ainda teria o hardware necessário para conectá-lo ao seu sistema?
Outra coisa a considerar é que um drive de disco é muito mais complexo que um cartucho de fita.
Qual é a chance de um motor de 20 anos rodar um drive de disco de 20 anos, acessando as heads
de leitura e gravação de 20 anos sem que nenhum componente apresente problemas após estarem
ociosos por estes 20 anos?

Nota
Alguns centros de dados fazem backup para drives de disco e então, quando os backups estão
completos, são gravados em fita para propósitos de arquivamento. Isto permite o backup mais
rápido possível durante a janela de backup. A gravação dos backups em fita pode ser feita durante
o resto do dia útil; se a gravação acabar antes dos backups do dia seguinte serem feitos, tempo
não é problema.

Mesmo assim, ainda há alguns casos nos quais faz sentido ter backup em drives de disco. Na próxima
seção veremos como eles podem ser combinados com uma rede para formar uma solução de backup
viável (mas custosa).

8.2.4.3. Rede
Uma rede não pode agir como uma mídia 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 não são mais desvanta-
gens.
Ao fazer backup através de uma rede, os drives de disco já estão fora da empresa, portanto não há
necessidade de transportar drives de disco frágeis a lugar algum. Com largura de banda suficiente, é
possível manter a vantagem da velocidade que você pode obter ao fazer backups em drives de disco.
No entanto, esta tática não resolve a questão do armazenamento em arquivos (apesar de poder usar a
mesma estratégia de passar para a fita após o backup). Além disso, os custos de um centro de dados
remoto com um link de alta velocidade ao centro de dados principal encarecem demais esta solução.
Capítulo 8. Planejamento para Desastres 171

Mas, para as empresas que precisam das características que esse tipo de solução pode oferecer, é um
custo com o qual elas arcam com prazer.

8.2.5. Armazenamento de Backups


O que acontece após completar os backups? A resposta óbvia é que os backups devem ser armazena-
dos. Entretanto, não é tão óbvio o que deve ser armazenado — e onde.
Para responder a estas questões, devemos considerar primeiro sob quais circunstâncias os backups
devem ser usados. Há três situações principais:

1. Pequenos e rápidos pedidos de restauração dos usuários


2. Grandes restaurações para recuperar de um desastre
3. Armazenamento em arquivos, pouco provável de ser usado novamente
Infelizmente, há diferenças irreconciliáveis entre os números 1 e 2. Quando um usuário apaga um
arquivo acidentalmente, ele pretende recuperá-lo imediatamente. Isto siginifca que a mídia de backup
não 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 restauração completa de um ou mais computadores do
seu centro de dados, se o desastre foi de natureza física, o que quer que tenha destruído seus computa-
dores, também destruiria os backups localizados próximos dos computadores. Isto seria uma situação
terrível.
O armazenamento em arquivos é menos controverso. Já que a chance de ser utilizado para qualquer
propósito é baixa, não haveria problema se a mídia de backup estivesse localizada há quilômetros de
distância do centro de dados.
As táticas para resolver estas diferenças variam de acordo com as necessidades da empresa em
questão. Uma tática possível é armazenar o backup de diversos dias na empresa; estes backups são en-
tão levados para um local de armazenamento mais seguro fora da empresa quando os backups diários
mais novos forem criados.
Uma outra tática seria manter dois conjuntos diferentes de mídia:

• Um conjunto no centro de dados estritamente para pedidos imediatos de restauração


• Um conjunto fora da empresa para armazenamento externo e recuperação de desastres
Obviamente, ter dois conjuntos significa ter a necessidade de rodar todos os backups duas vezes para
fazer uma cópia 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 cópias).
O desafio do administrador de sistemas é encontrar um equilíbrio que atenda adequadamente às ne-
cessidades de todos, e também assegurar que os backups estejam disponíveis para a pior das situações.

8.2.6. Questões de Restauração


Enquanto os backups são uma ocorrência diária, as restaurações normalmente representam um evento
menos frequente. No entanto, as restaurações são inevitáveis; elas serão necessárias, portanto é melhor
estar preparado.
É importante atentar para os vários cenários de restauração detalhados ao longo desta seção e determi-
nar maneiras para testar sua habilidade em resolvê-los. E tenha em mente que o mais dfiícil de testar
também é o mais crítico.
172 Capítulo 8. Planejamento para Desastres

8.2.6.1. Restaurando do Zero


"Restaurar do zero" significa restaurar um backup de sistema completo em um computador com ab-
solutamente nenhum dado de nenhum tipo — sem sistema operacional, sem aplicações; nada.
Em geral, há duas táticas básicas para restaurações do zero:

Reinstalar, seguido de restauração


Aqui o sistema operacional base é instalado como se um computador novo estivesse sendo con-
figurado. Após instalar e configurar o sistema operacional, os drives de disco restantes podem ser
particionados e formatados, e todos os backups restaurados pela mídia de backup.

Discos de recuperação do sistema


Um disco de recuperação do sistema é uma mídia iniciável (bootable) de algum tipo (geralmente
um CD) que contém um ambiente de sistema mínimo, capaz de executar as tarefas mais básicas
de administração de sistemas. O ambiente de recuperação contém os utilitários necessários para
particionar e formatar os drives de disco, os drives de dispositivo necessários para acessar o
dispositivo de backup e o software necessário para restaurar os dados pela mídia de backup.

Nota
Alguns computadores têm a habilidade de criar fitas de backup iniciáveis e de inicializar através delas
para começar o processo de restauração. No entanto, esta capacidade não está disponível em todos
os computadores. Notavelmente, os computadores baseados na arquitetura PC não permitem está
tática.

8.2.6.2. Testando Backups


Todos os tipos de backup devem ser testados periodicamente para garantir que os dados podem ser
lidos através deles. É fato que, às vezes, os backups executados são por algum motivo ilegíveis. O pior
é que muitas vezes isto só é percebido quando os dados foram perdidos e devem ser restaurados pelo
backup.
As razões para isto ocorrer podem variar desde alterações no alinhamento do cabeçote do drive de
fita, software de backup mal-configurado a um erro do operador. Independente da causa, sem o teste
periódico você não pode garantir que está gerando backups através dos quais poderá restaurar dados
no futuro.

8.3. Recuperação de Desastres


Como um experimento rápido, na próxima vez em que você estiver no seu centro de dados, olhe ao
redor e imagine por um momento que este se foi. Não só os computadores, mas imagine que o prédio
todo não 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 rápido possível. O que
você faria?
Ao pensar nisso, você tomou o pirmeiro passo da recuperação de desastres. A recuperação 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 possível. O tipo de desastre pode variar, mas o objetivo
final é sempre o mesmo.
Capítulo 8. Planejamento para Desastres 173

Os passos envolvidos na recuperação de desastres são diversos e abrangentes. Aqui está uma visão
geral do processo, juntamente a pontos-chave para ter em mente.

8.3.1. Criando, Testando e Implementando um Plano de Recuperação de


Desastres
Um local de backup é vital, mas é inútil sem um plano de recuperacão de desastres. Um plano de
recuperacão de desastres determina cada faceta do processo de recuperacão de desastres, incluindo,
mas não limitado a:

• Quais eventos denotam possíveis desastres


• Quais pessoas na empresa têm autorização para declarar um desastre e, consequentemente, colocar
o plano em ação
• A sequência de eventos necessária para preparar o local de backup, uma vez declarado o desastre
• As funções e responsabilidades de todo o pessoal envolvido na execução do plano
• Um inventário do hardware e software necessários para restaurar a produção
• Um cronograma listando os membros da equipe que compoem o local de backup, incluindo um
cronograma de rotação para suportar a continuação das operações sem estressar os membros da
equipe
• A sequência de eventos necessária para mover as operações do local de backup para o centro de
dados novo/restaurado
Os planos de recuperação de desastres frequentemente servem o propósito de juntar todos os detalhes.
Este nível de detalhe é vital porque, no caso de uma emergência, o plano pode ser a única coisa que
restou do seu centro de dados anterior (obviamente, além dos backups externos) para ajudá-lo na
reconstrução e restauração das operações.

Dica
Os planos de recuperação de desastres estarem prontamente disponíveis no seu ambiente de tra-
balho, mas também é necessário ter cópias externas. Desta maneira, um desastre que destrua seu
ambiente de trabalho não atingirá todas as cópias do plano de recuperação de desastres. Um bom
lugar para guardar esta cópia é o local de armazenamento dos backups externos. Se não for violar
as normas de segurança da sua empresa, as cópias também podem ser guardadas nas casas de
membros-chave da equipe, prontas para uso imediato.

Um documento importante como este merece seriedade (e possivelmente assistência profissional para
ser criado).
Uma vez criado este documento importante, o conhecimento nele contido deve ser periodicamente
testado. Testar um plano de recuperação de desastres significa percorrer os passos do plano: ir ao
local do backup e criar um centro de dados temporário, rodar aplicações remotamente e retornar às
operações normais após o fim do "desastre". A maioria dos testes não tenta executar 100% das tarefas
contidas no plano; ao invés disso, um sistema e uma aplicação representativos são selecionadas e
realocadas ao local do backup, colocadas em produção por um período e retornadas à operação normal
no fim do teste.

Nota
Apesar de ser uma frase batida, um plano de recuperação de desastres deve ser um documento
vivo; conforme o centro de dados sofre mudanças, o plano deve ser atualizado para refletir estas
174 Capítulo 8. Planejamento para Desastres

alterações. De muitas maneiras, um plano de recuperação de desastres desatualizado pode ser pior
que não ter plano algum, portanto se organize para executar revisões e atualizações regulares (a
cada três meses, por exemplo) no plano.

8.3.2. Locais de Backup: Frios, Mornos e Quentes


Um dos aspectos mais importantes da recuperação de um desastre é ter o local a partir do qual a
recuperação pode ser feita. Este local também é 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á três tipos diferentes de sites de backup:

• Sites de backup frios


• Sites de backup mornos
• Sites de backup quentes
Obviamente, estes termos não fazem referência à temperatura do site de backup. Mas sim ao esforço
necessário para iniciar as operações no site de backup, caso ocorra um desastre.
Um site de backup frio é um pouco mais do que um espaço configurado apropriadamente num prédio.
Tudo o que é necessário para restaurar o serviço para seus usuários deve ser obtido e entregue ao site
antes de começar o processo de recuperação. Como você pode imaginar, a demora na transformação
de um site de backup frio numa operação completa pode ser substancial.
Sites de backup frios são 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 serviço, os últimos backups do seu local de armazenamento externo devem
ser entregues e uma restauração do zero deve ser completa, antes de realmente iniciar a recuperação.
Sites de backup quentes tem uma imagem espelho virtual de seu centro de dados atual, com todos os
sistemas configurados e aguardando somente os últimos backups dos dados de seus usuários vindos
do local de armazenamento externo. Como você pode imaginar, um site de backup quente pode ser
transformado num local de produção completo em apenas algumas horas.
Um site de backup quente é a tática mais cara de recuperação de desastres.
Os sites de backup podem ter três origens diferentes:

• Empresas especializadas em oferecer serviços de recuperação de desastres


• Outros locais de propriedade de sua empresa e operados pela mesma
• Um acordo com uma outra empresa para compartilhar as instalações do centro de dados no caso de
um desastre
Cada tática tem seus pontos fortes e fracos. Por exemplo: contratar uma empresa de recuperação de
desastres frequentemente lhe dá acesso a profissionais qualificados para direcionar as empresas através
do processo de criação, testes e implementação de um plano de recuperação de desastres. Como você
pode imaginar, estes serviços não são de graça.
Usar um espaço em outra localidade de propriedade e operada pela sua empresa pode ser uma opção
com custo zero, mas estocar o site de backup e manter sua prontidão ainda é uma opção cara.
Desenvolver um acordo para compartilhar centros de dados com uma outra empresa pode ser bem
barato, mas geralmente não é possível tocar operações a longo prazo sob estes termos, já que o pro-
prietário do centro de dados ainda deve manter sua produção normal.
Capítulo 8. Planejamento para Desastres 175

No final das contas, a escolha do site de backup é um balanço entre os custos e a necessidade de sua
empresa na produção contínua.

8.3.3. Disponibilidade de Hardware e Software


Seu plano de recuperação de desastres deve incluir métodos para obter o hardware e software
necessários para as operações do site de backup. Um site de backup gerido profissionalmente
talvez já tenha tudo o que você precisa (ou talvez você precise providenciar a obtenção e entrega
de materiais especiais que o site não tenha). Por outro lado, um site de backup frio implica na
identificação de uma fonte confiável para a obtenção de cada um dos itens. Frequentemente,
empresas trabalham com fabricantes para criar acordos para a rápida entrega de hardware e/ou
software no caso de um desastre.

8.3.4. Disponibilidade de Backups


Quando um desastre é declarado, é necessário notificar o seu local de armazenamento externo por
duas razões:

• 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 nor-
mais do site de backup)

Dica
No caso de um desastre, os últimos backups de seu antigo centro de dados que você tiver são
vitalmente importantes. Considere fazer cópias 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 não tem muita utilidade se estiver totalmente desconectado do que resto da em-
presa. Dependendo do plano de recuperação de desastres e da natureza do desastre, sua comunidade
de usuários pode estar localizada há quilômetros de distância do site de backup. Nestes casos, uma
boa conectividade é essencial para restaurar a produção.
Um outro tipo de conectividade para ter em mente é a telefônica. Você deve assegurar que há linhas
telefônicas disponíveis suficientes para suportar toda a comunicação verbal com seus usuários. O que
pode ter sido um simples grito por cima de uma divisória pode ser agora uma conversa telefônica
de longa distância. Portanto, planeje mais conectividade telefônica do que pareça necessário numa
primeira instância.

8.3.6. Funcionários do Site de Backup


A questão dos funcionários do site de backup tem diversas dimensões. Um dos aspectos é determinar
os funcionários necessários para rodar o centro de dados backup pelo tempo necessário. Apesar de um
número pequeno de funcionários poder manter as coisas funcionando por um curto período, conforme
o desastre se desenrolar, serão necessárias mais pessoas para tocar as operações sob as circunstâncias
extraordinárias que permeam um desastre.
176 Capítulo 8. Planejamento para Desastres

Isto inclui garantir que os funcionários tenham tempo livre suficiente para descansar e voltar para seus
lares. Se as consequências do desastre foram abrangentes de modo que afetaram os lares e famílias
das pessoas, é necessário alocar tempo para que elas possam lidar com suas recuperações particulares
do desastre. Também é necessária acomodação próxima 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 recuperação de desastres inclui representantes de todas as partes da
comunidade de usuários da empresa. Isto depende da habilidade da sua empresa em operar com um
centro de dados remoto. Se os representantes dos usuários devem trabalhar no site de backup, também
é necessário prover-lhes acomodação.

8.3.7. Voltando à Normalidade


Eventualmente, todos os desastres terminam. O plano de recuperação de desastres também deve abor-
dar esta fase. O novo centro de dados deve estar equipado com todo o hardware e software necessário.
Apesar desta fase não ter a mesma natureza crítica de tempo dos preparativos quando o desastre foi
declarado, os sites de backup custam dinheiro todos os dias em que estão em uso. Portanto, devido às
questões econômicas, devemos retornar à normalidade o mais rápido possível.
Deve-se fazer os últimos backups do site de backup e enviá-los ao novo centro de dados. Após serem
restaurados no novo hardware, a produção pode ser iniciada no novo centro de dados.
Neste ponto, o centro de dados backup pode ser descomissionado, com a disposição de todo o hard-
ware temporário determinada pela seção final do plano. Finalmente, deve ser feita uma revisão da
eficácia do plano e integrar as alterações recomendadas pelo comitê revisor numa versão atualizada
do plano.

8.4. Informações Específicas do Red Hat Enterprise Linux


Há poucas informações sobre os tópicos desastre e recuperação de desastre relacionadas a um sistema
operacional específico. Afinal de contas, os computadores de um centro de dados inundado estarão
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 recuperação
de um desastre. Estas são abordadas na próxima seção.

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 básica de suporte agora mesmo, ao ler este manual.
A documentação do Red Hat Enterprise Linux está disponível no CD de Documentação do Red Hat
Enterprise Linux (que também pode ser instalado no seu sistema para acesso rápido), no formato
impresso e também no site da Red Hat http://www.redhat.com/docs/.
Opções de auto suporte podem ser acessadas através das diversas listas de discussão hospedadas pela
Red Hat (visite o site https://listman.redhat.com/mailman/listinfo/). Estas listas trazem o conheci-
mento da comunidade de usuários Red Hat e, muitas delas são monitoradas por funcionários da Red
Hat, que também contribuem de acordo com sua disponibilidade. Outros recursos podem ser acessa-
dos através da página principal de suporte da Red Hat: http://www.redhat.com/apps/support/.
Há opções de suporte mais detalhado. Para maiores informações, consulte o site da Red Hat.
Capítulo 8. Planejamento para Desastres 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ó não constituem uma solução completa de backup. Entretanto, eles podem
ser usados como o núcleo de tal solução.

Nota
Como mencionado na Seção 8.2.6.1, a maioria dos computadores baseados na arquitetura PC
padrão não possuem a funcionalidade necessária para inicializar a partir de uma fita de backup.
Consequentemente, o Red Hat Enterprise Linux não é capaz de executar uma inicialização pela fita
quando rodar em hardware deste tipo.
No entanto, também é possível usar o seu CD-ROM do Red Hat Enterprise Linux como um ambiente
de recuperação do sistema. Para mais informações, veja o capítulo sobre recuperação básica de
sistemas no Guia de Administração de Sistemas Red Hat Enterprise Linux.

8.4.2.1. tar
O utilitário tar é bem conhecido dentre os administradores de sistemas UNIX. É o método de arquiva-
mento preferido para compartilhar partes do código fonte e arquivos entre sistemas. A implementação
do tar inclusa no Red Hat Enterprise Linux é o tar do GNU, uma das implementações tar mais
ricas em funcionalidades.
Usar o tar para fazer backup do conteúdo de um diretório pode ser tão 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 diretório /mnt/backup/. O arquivo


contém o conteúdo do diretório /home/.
O arquivo resultante será quase tão grande quanto os dados sendo copiados para backup. Depen-
dendo do tipo de dados sendo copiados, comprimir o arquivo pode significar uma grande redução no
tamanho. O arquivo pode ser comprimido adicionando apenas uma opção 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 opções para o tar; para saber mais, leia a página man do tar(1).

8.4.2.2. cpio
O utilitário cpio é outro programa tradicional do UNIX. É um programa excelente para mover dados
de uma localidade a outra e, como tal, pode servir também como programa de backup.
O comportamento do cpio é um pouco diferente do tar. Ao contrário do tar, o cpio lê os nomes
dos arquivos que deve processar através do input padrão (standard input). Um método comum para
gerar uma lista de arquivos para o cpio é usar programas como o find, cujo output é então enviado
(piped) ao cpio:

find /home/ | cpio -o  /mnt/backup/home-backup.cpio

5. A extensão .gz é usada tradicionalmente para conotar que o arquivo foi comprimido com o gzip. Às vezes,
o .tar.gz é encurtado para .tgz a fim de manter os nomes de arquivos razoavelmente curtos.
178 Capítulo 8. Planejamento para Desastres

Este comando cria um arquivo cpio (contendo todos os dados de /home/) chamado
home-backup.cpio e localizado no diretório /mnt/backup/.

Dica
Como o find tem uma variedade de testes de seleção de arquivos, é fácil criar backups sofisticados.
Por exemplo: o comando seguinte faz um backup somente dos arquivos que não foram acessados
no último ano:

find /home/ -atime +365 | cpio -o  /mnt/backup/home-backup.cpio

Há muitas outras opções para o cpio (e para o find). Para aprender mais sobre elas, leia as páginas
man do cpio(1) e do find(1).

8.4.2.3. dump/restore: Não Recomendado para Sistemas de Arquivo Montados!


Os programas Linux dump e restore são equivalentes aos programas UNIX de mesmo nome. Sendo
assim, muitos administradores de sistemas com experiência no UNIX podem pensar que o dump e o
restore são boas opções para um programa de backup sob o Red Hat Enterprise Linux. No entanto,
um dos métodos de uso do dump pode causar problemas. Aqui está o comentário 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)
Cc: Kernel Mailing List linux-kernel At vger Dot kernel Dot org 
[ linux-kernel added back as a cc ]

 
On Fri, 27 Apr 2001, Neil Conway wrote:
I’m surprised that dump is deprecated (by you at least ;-)). What to
use instead for backups on machines that can’t umount disks regularly?

Note that dump simply won’t 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. It’s 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.

 I’ve 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


Capítulo 8. Planejamento para Desastres 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 não é recomendado.
Entretanto, o dump foi originalmente desenvolvido para fazer backup de sistemas de arquivo não
montados; consequentemente, em situações nas quais é possível tornar um sistema de arquivo offline
com o umount, o dump continua sendo uma tecnologia viável para backup.

8.4.2.4. O Arquivador de Disco de Rede Automático Maryland Avançado (AMANDA,


The Advanced Maryland Automatic Network Disk Archiver)
AMANDA é uma aplicação 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 espaço livre nos discos rápidos e configurado com o disposi-
tivo de backup desejado) pode fazer backup de muitos sistemas cliente, que não precisam mais do que
o software cliente AMANDA.
Esta tática de backup faz muito sentido, pois concentra estes recursos necessários para backups em
um único sistema, ao invés de precisar de hardware adicional para cada sistema que requerer serviços
de backup. O design do AMANDA também serve para centralizar a gestão dos backups, facilitando
bastante a vida do administrador de sistemas.
O servidor do AMANDA administra uma série de mídias de backup e alterna o uso entre elas para
garantir que todos os backups sejam retidos pelo período de retenção determinado pelo administrador.
Todas as mídias são pré-formatadas com dados que permitem ao AMANDA detectar se a mídia apro-
priada está disponível ou não. Além disso, o AMANDA pode interfacear com mídia robótica alterando
unidades, possibilitando automatizar os backups completamente.
O AMANDA pode usar o tar ou o dump para fazer os backups (é preferível usar o tar sob o Red Hat
Enterprise Linux devido às questões do dump abordadas na Seção 8.4.2.3). Sendo assim, os backups
do AMANDA não requerem o AMANDA para restaurar os arquivos — um valor agregado.
Em operação, 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 terão seus
backups feitos.
Após os backups iniciarem, os dados são enviados através da rede, do cliente para o servidor, onde
são armazenados em um disco de espera. Uma vez completo o backup, o servidor começa a gravá-
lo pelo disco de espera na mídia de backup. Ao mesmo tempo, outros clientes estão enviando seus
backups ao servidor para serem armazenados no disco de espera. Isto resulta num fluxo de dados
contínuo disponível para gravação na mídia de backup. Conforme os backups são gravados na mídia
de backup, são apagados do disco de espera do servidor.
Uma vez completos todos os backups, o administrador de sistemas recebe um e-mail com um relatório
descrevendo o status dos backups, facilitando e dinamizando a revisão.
Se for necessário restaurar dados, o AMANDA contém um programa que permite ao operador iden-
tificar o sistema de arquivo, data e nome(s) do(s) arquivo(s). Após fazer isso, o AMANDA identifica
a mídia de backup correta e então localiza e restaura os dados desejados. Conforme mencionado an-
teriormente, o design do AMANDA também possibilita restaurar dados mesmo sem a assistência do
AMANDA, apesar da identificação da mídia correta ocorrer mais lentamente e manualmente.
180 Capítulo 8. Planejamento para Desastres

Esta seção cobriu apenas os conceitos mais básicos do AMANDA. Para pesquisar mais sobre o
AMANDA, comece pela página man amanda(8).

8.5. Recursos Adicionais


Esta seção inclui diversos recursos para aprender mais sobre a recuperação de desastres e o assunto
específico ao Red Hat Enterprise Linux abordado neste capítulo.

8.5.1. Documentação Instalada


Os recursos seguintes são instalados no decorrer de uma instalação típica do Red Hat Enterprise Linux
e podem ajudá-lo a saber mais sobre o assunto aqui abordado.

• Página man tar(1) — Aprenda a arquivar dados.


• Página man dump(8) — Aprenda a fazer dump do conteúdo do sistema de arquivo.
• Página man restore(8) — Aprenda a recuperar o conteúdo do sistema de arquivo salvo pelo
dump
• Página man cpio(1) — Aprenda a copiar arquivos para e de arquivamentos.
• Página man find(1) — Aprenda a procurar arquivos.
• Página man amanda(8) — Aprenda mais sobre os comandos que fazem parte do sistema de backup
AMANDA.
•  
Arquivos do diretório /usr/share/doc/amanda-server- version / — Aprenda mais so-
bre o AMANDA revendo este diversos documentos e arquivos de exemplo.

8.5.2. Sites Úteis

• http://www.redhat.com/apps/support/ — A página de suporte da Red Hat oferece fácil acesso aos


diversos recursos relacionados ao suporte do Red Hat Enterprise Linux.
• http://www.disasterplan.com/ — Um site interessante com links para vários outros sites relaciona-
dos à recuperação de desastres. Inclui uma amostra de plano de recuperação de desastres.
• http://web.mit.edu/security/www/isorecov.htm — O site do Massachusetts Institute of Technology
Information Systems Business Continuity Planning contém diversos links informativos.
• http://www.linux-backup.net/ — Uma visão geral interessante de diversas questões relativas a back-
ups.
• http://www.linux-mag.com/1999-07/guru_01.html — Um artigo interessante da Linux Magazine
sobre os aspectos mais técnicos da produção de backups sob o Linux.
• http://www.amanda.org/ — O site do AMANDA (The Advanced Maryland Automatic Network
Disk Archiver). Contém indicações sobre as diversas listas de discussão relacionadas ao AMANDA
e outros recursos online.

8.5.3. Livros Relacionados


Os livros a seguir abordam diversas questões relativas à recuperação de desastres e são bons recursos
para os administradores de sistemas Red Hat Enterprise Linux.
Capítulo 8. Planejamento para Desastres 181

• O Guia de Administração de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. — Inclui um capí-
tulo sobre recuperação de sistemas, que pode ser útil nas restaurações a partir do zero.
• Unix Backup & Recovery de W. Curtis Preston; O’Reilly & Associates — Apesar de não ser es-
crito especificamente para sistemas Linux, este livro oferece uma cobertura profunda de diversas
questões relacionadas a backups, inclusive um capítulo sobre a recuperação de desastres.
182 Capítulo 8. Planejamento para Desastres
Índice Remissivo cabeças acessando, 68
cabeças gravando, 68
cargas I/O, acessos, 69
cargas I/O, desempenho, 69
Símbolos cargas I/O, gravações, 69
/etc/cups/, 144 cilindro, 62
/etc/printcap, 144 conceitos de endereçamento, 61
desempenho do, 67
geometria, problemas com, 62
A interface IDE, 64
interface SCSI, 65
abuso de recursos, 127 interfaces do, 63
abuso, recurso, 127 interfaces padrão, 64
Administrador de Pacotes RPM interfaces, histórico, 63
(Ver RPM) interfaces, padrão, 64
administrando latência rotacional, 68
impressoras, 137 latência, rotacional, 68
administração de sistemas leitores versus gravadores, 69
filosofia da, 1 limitações elétricas do, 67
automação, 1 limitações mecânicas do, 67
comunicação, 3 localidade I/O, 70
documentação, 2 mapeamento baseado na geometria, 61
engenharia social, riscos da, 7 mapeamento baseado no bloco, 63
negócio, 6 mapeamento, baseado na geometria, 61
ocorrências inesperadas, 8 mapeamento, baseado no bloco, 63
planejamento, 8 movimento do braço de acesso, 68
recursos, 5 movimento, braço de acesso, 68
segurança, 6 pratos de disco, 59
usuários, 6 pratos, disco, 59
administração de volume lógico processamento de comandos, 68
(Ver LVM) processamento, comandos, 68
armazenamento setor, 62
acessível via rede, 75, 101 visão geral do, 59
NFS, 101 empregando, 70
SMB, 101 monitoramento da, 17
adicionando, 87, 102 padrões de acesso, 45
/etc/fstab, atualizando, 104 partição
agendamento de backup, alterando, 91 atributos das, 70
configuração, atualizando, 91 campo do tipo, 71
drive de disco ATA, 88 extendidas, 71
drive de disco SCSI, 89 geometria da, 71
formatando, 91, 104 lógicas, 71
hardware, instalando, 88 primárias, 71
particionando, 90, 102 tipo da, 71
administração do, 59, 82 visão geral do, 70
crescimento, normal, 85 questões relativas a arquivos, 86
monitoramento do espaço livre, 83 acesso a arquivos, 86
questões de usuário, 83 compartilhamento de arquivos, 87
uso da aplicação, 84 quotas de disco, 85
uso excessivo do, 83 (Ver quotas de disco)
baseado no RAID removendo, 92, 105
(Ver RAID) /etc/fstab, removendo do, 105
dispositivos de armazenamento em massa apagando conteúdo, 93, 106
braços de acesso, 60 comando umount, uso do, 105
cabeça, 62 dados, removendo, 92
cabeças (heads), 60 sistema de arquivo, 72, 96
184

arquivo /etc/mtab, 99 B
arquivo /proc/mounts, 100
backups
baseado em arquivo, 72
comando df, usando, 100 agendamento, alterando, 91
contabilidade do espaço, 73 armazenamento de, 171
contabilidade, espaço, 73 comprando software, 167
controle de acesso, 73 criando software, 167
diretório hierárquico, 72 introdução a, 165
diretórios, 72 questões de restauração, 171
estrutura, diretório, 74 restaurações do zero, 172
EXT2, 96 testando a restauração, 172
EXT3, 97 questões relaciondas aos dados, 166
habilitando acesso ao, 74 software de backup AMANDA, 179
hora de acesso, 73 tecnologias usadas, 177
hora de criação, 73 cpio, 177
hora de modificação, 73 dump, 178
ISO 9660, 97 tar, 177
montando, 98 tipos de, 168
montando com o arquivo /etc/fstab, 101 backups completos, 168
MSDOS, 97 backups diferenciais, 169
ponto de montagem, 98 backups incrementais, 168
VFAT, 97 tipos de mídia, 169
visualização da montagem, 99 disco, 169
tecnologias, 45 fita, 169
armazenamento de backup, 49 rede, 170
armazenamento off-line, 49
cache L1, 47
cache L2, 47
disco rígido, 48
C
drive de disco, 48 CD-ROM
memória cache, 46 sistema de arquivo
memória principal, 47 (Ver Sistema de arquivo ISO 9660)
RAM, 47 comando df, 100
Registradores de CPU, 46 comando free, 19, 54
tecnologias, avançadas, 75 comando gnome-system-monitor, 20
arquivo /etc/fstab comando iostat, 23, 38
atualizando, 104 comando mpstat, 23
montando sistemas de arquivo com, 101
comando raidhotadd, uso do, 112
arquivo /etc/group
comando sa1, 23
conta de usuário, função no, 132
comando sa2, 23
grupo, função no, 132
comando sadc, 23
arquivo /etc/gshadow
comando sar, 23, 25, 39, 41, 55
conta de usuário, função no, 132
grupo, função no, 132 relatórios, acessando, 25
arquivo /etc/mtab, 99 comando top, 18, 19, 40
arquivo /etc/passwd comando vmstat, 18, 21, 38, 41, 54
conta de usuário, função no, 130 comando watch, 19
grupo, função no, 130 comunicação
arquivo /etc/shadow informações específicas ao Red Hat Enterprise
conta de usuário, função no, 130 Linux, 9
grupo, função no, 130 necessidade de, 3
arquivo /proc/mdstat, 112 configuração da impressora, 143
arquivo /proc/mounts, 100 aplicação baseada em texto, 143
ative sua assinatura, iv CUPS, 143
automação, 8 conjunto de trabalho, 52
visão geral da, 1 conta
185

(Ver conta de usuário) CUPS, 143


conta de usuário
acesso a dados compartilhados, 125
administração da, 115, 115, 123
alterações de função, 124 D
desligamentos, 123
novas contratações, 123 dados
arquivos que controlam, 129 acesso compartilhados aos, 125, 126
/etc/group, 132 questões de propriedade (ownership) global, 127
/etc/gshadow, 132
devlabel, 96
/etc/passwd, 130
/etc/shadow, 130 diretório home
controle de acesso, 122 centralizado, 127
diretório home diretório home centralizado, 127
centralizado, 127
ferramentas de administração, 133 discos rígidos, 48
o comando chage, 133 dispositivo
o comando chfn, 133 acesso ao dispositivo inteiro, 95
o comando chpasswd, 133
alternativas aos nomes dos dispositivos, 95
o comando passwd, 133
o comando useradd, 133 convenção de nomenclatura, 93
o comando userdel, 133 devlabel, nomeando com o, 96
o comando usermod, 133 etiquetas do sistema de arquivo, 95
GID, 129
GIDs do sistema, 129 etiquetas, sistema de arquivo, 95
nome de usuário, 115 nomeando com o devlabel, 96
alterações do, 117 nomes de dispositivos, alternativas para, 95
colisões na nomenclatura, 116
nomes dos arquivos, 94
convenção de nomenclatura, 115
permissões relacionadas a, 127 partição, 94
execução (execute), 127 tipo, 94
gravação (write), 127 unidade, 94
leitura (read), 127
documentação
setgid (id do grupo), 127
setuid (id do usuário), 127 informações específicas ao Red Hat Enterprise
sticky bit, 127 Linux, 9
recursos, administração dos, 125 documentação, necessidade de, 2
senha, 118
drive de disco ATA
brevidade da, 119
conjunto de caracteres grande usado na, 121 adicionando, 88
escritas, 121 drive de disco SCSI
expiração, 122 adicionando, 89
fortes, 121
drives de disco, 48
fraca, 119
informações pessoais usadas na, 120
mais longas, 121
memorável, 122
E
palavras usadas na, 120
pequeno conjunto de caracteres usado na, 119 engenharia social, riscos da, 7
truques com palavras usados na, 120
engenharia, social, 7
usada repetidamente, 121
UID, 129 espaço de endereço virtual, 51
UIDs do sistema, 129 espaço em disco
controle de mudanças, 163 (Ver armazenamento)
convenções
documentos, ii
186

F H
falhas de página, 51 hardware
Ferramenta de Configuração da Impressora contratos de serviço, 149
(Ver configuração da impressora) disponibilidade das peças, 152
ferramentas hardware coberto, 152
contas de usuário, administração horas de cobertura, 149
(Ver conta de usuário, ferramentas de admin- orçamento para, 152
istração) serviço de depósito, 150
grupos, administração serviço drop-off, 150
(Ver grupo, ferramentas de administração) serviço walk-in, 150
monitoramento de recursos, 18 tempo de resposta, 150
free, 19 técnico interno, 151
iostat, 23 falhas de, 147
Monitor GNOME do Sistema, 20 habilidades necessárias para o reparo, 147
mpstat, 23 reservas
OProfile, 26 estoque, quantidades, 148
sa1, 23 estoque, seleção do, 148
sa2, 23 guardar, 147
sadc, 23 trocando hardware, 149
sar, 23, 25
Sysstat, 23
top, 19
vmstat, 21
I
filosofia da administração de sistemas, 1 ID do grupo
(Ver GID)
ID do usuário
G (Ver UID)
impressoras
GID, 129
administrando, 137
grupo
considerações, 137
acesso a dados compartilhados usando, 126
cor, 140
administração da, 115
arquivos que controlam, 129 CMYK, 140
/etc/group, 132 jato de tinta, 140
/etc/gshadow, 132 laser, 141
/etc/passwd, 130 duplex, 137
/etc/shadow, 130 em rede, 143
estrutura, determinando, 126 linguagens
ferramentas de administração, 133 (Ver linguagens de descrição da página
o comando gpasswd, 133 (PDL))
o comando groupadd, 133 local, 143
o comando groupdel, 133 recursos adicionais, 145
o comando groupmod, 133 tipos, 137
o comando grpck, 133 cera térmica, 141
GID, 129 de linha, 138
GIDs do sistema, 129 dye-sublimation, 141
permissões relacionadas a, 127 impacto, 138
execução (execute), 127 jato de tinta, 140
gravação (write), 127 laser, 140
leitura (read), 127 laser coloridas, 141
setgid (id do grupo), 127 margarida (daisy-wheel), 138
setuid (id do usuário), 127 matricial (dot-matrix), 138
sticky bit, 127 tinta sólida, 141
UID, 129 impressoras de impacto, 138
UIDs do sistema, 129 consumíveis, 139
de linha, 138
187

margarida (daisy-wheel), 138 J


matricial (dot-matrix), 138
janela de comandos bash, automação e, 8
impressoras de linha
(Ver impressoras de impacto)
impressoras laser coloridas, 141
impressoras margarida L
(Ver impressoras de impacto) linguagens de descrição da página (PDL), 142
impressoras matriciais Interpress, 142
(Ver impressoras de impacto) PCL, 142
impressoras à jato de tinta, 140 PostScript, 142
consumíveis, 140 lpd, 145
impressoras à laser, 140 LVM
consumíveis, 141 agrupamento de armazenamento, 81
cor, 141
contrastada com o RAID, 82
inesperado, preparação para o, 8
migração de dados, 82
informações específicas ao Red Hat Enterprise Linux
migração, dados, 82
automação, 8
redimensionamento do volume lógico, 81
comunicação, 9
redimensionamento, volume lógico, 81
documentação, 9
visão geral do, 81
janela de comandos bash, 8
PAM, 10
perl, 8
RPM, 10 M
scripts da janela de comandos, 8 memória
segurança, 10 memória virtual, 49
sistemas de detecção de intrusão, 10 backing store, 50
informações específicas do Red Hat Enterprise Linux conjunto de trabalho, 52
ferramentas de monitoramento de recursos desempenho da, 53
iostat, 38 desempenho, melhor caso, 53
sar, 39, 41 desempenho, pior caso, 53
top, 40 espaço de endereço virtual, 51
vmstat, 38, 41
falhas de página, 51
ferramentas de monitoramento dos recursos, 18
swapping, 52
free, 18, 54
visão geral da, 50
OProfile, 18
monitoramento da, 17
sar, 55
utilização dos recursos de, 45
Sysstat, 18
memória cache, 46
top, 18
memória física
vmstat, 18, 54
(Ver memória)
monitoramento de recursos
largura de banda, 38 memória virtual
memória, 54 (Ver memória)
poder da CPU, 38 monitoramento
recuperação de desastres, 176 desempenho do sistema, 14
suporte ao software, 176 recursos, 13
suporte, software, 176 monitoramento de recursos, 13
tecnologias de backup armazenamento, 17
AMANDA, 179 capacidade do sistema, 14
cpio, 177 conceitos básicos, 13
dump, 178 desempenho do sistema, 14
tar, 177 Energia da CPU, 15
visão geral das, 177 ferramentas
interface IDE free, 19
visão geral do, 64 iostat, 23
interface SCSI Monitor GNOME do Sistema, 20
visão geral do, 65 mpstat, 23
188

OProfile, 26 o comando usermod, 133


sa1, 23 OProfile, 18, 26
sa2, 23
sadc, 23
sar, 23, 25 P
Sysstat, 23
top, 19 PAM, 10
vmstat, 21 partição, 94
ferramentas usadas, 18 atributos das, 70
largura de banda, 16 campo do tipo, 71
memória, 17 geometria, 71
o que monitorar, 15 tipo, 71
planejamento da capacidade, 14 criação de, 90, 102
monitoramento do desempenho do sistema, 14 extendidas, 71
monitorando estatísticas lógicas, 71
relacionada ao armazenamento, 17 primárias, 71
relacionada à memória, 17 visão geral do, 70
relacionado à largura de banda, 16 perl, automação e, 8
relativa à CPU, 15 permissão de execução (execute), 127
seleção de, 15 permissão de gravação (write), 127
montando sistemas de arquivo permissão de leitura (read), 127
(Ver armazenamento, sistema de arquivo, mon- permissão setgid, 10
tando) permissão setgid (id do grupo), 127
multiprocessamento simétrico, 37 permissão setuid, 10
Módulos de Autenticação Plugáveis (Pluggable Au- permissão setuid (id do usuário), 127
thentication Modules) permissão sticky bit, 127
(Ver PAM) permissões, 127
ferramentas de administração
o comando chgrp, 134
N o comando chmod, 134
o comando chown, 134
negócio, conhecimento do, 6 planejamento da capacidade, 14
NFS, 101 planejamento para desastres, 147
nome de usuário, 115 energia, backup, 158
alterando, 117 gerador, 158, 159
colisões entre, 116 quedas, extensas, 160
convenção de nomenclatura, 115 UPS, 158
nomes dos arquivos tipos de desastres, 147
dispositivo, 94 aplicações usadas impropriamente, 161
aquecimento, 160
ar condicionado, 160
O eletricidade, qualidade da, 157
o comando chage, 133 eletricidade, segurança da, 156
o comando chfn, 133 elétrico, 156
o comando chgrp, 134 erros de má configuração, 163
o comando chmod, 134 erros de operadores, 162
o comando chown, 134 erros de procedimento, 162
o comando chpasswd, 133 erros de usuários, 161
o comando gpasswd, 133 erros do administrador de sistemas, 163
o comando groupadd, 133 erros do técnico de serviço, 165
o comando groupdel, 133 erros durante procedimentos, 162
o comando groupmod, 133 erros humanos, 161
o comando grpck, 133 erros relacionados à manutenção, 164
o comando passwd, 133 falhas de hardware, 147
o comando useradd, 133 falhas de software, 153
o comando userdel, 133 falhas nas aplicações, 153
189

falhas no ambiente, 155 RAID de hardware, 80


falhas no sistema operacional, 153 RAID de software, 81
fatores climáticos, 161 introdução ao, 76
HVAC, 160 níveis do, 77
integridade da construção, 155 RAID 0, 77
pendências do sistema operacional, 153 RAID 0, desvantagens do, 77
quedas do sistema operacional, 153 RAID 0, vantagens do, 77
reparos inapropriados, 165 RAID 1, 78
ventilação, 160 RAID 1, desvantagens do, 78
planejamento, importância do, 8 RAID 1, vantagens do, 78
poder da CPU RAID 5, 78
(Ver recursos, sistema, poder de processamento) RAID 5, desvantagens do, 79
poder de processamento, recursos relacionados ao RAID 5, vantagens do, 79
(Ver recursos, sistema, poder de processamento) RAID embutido, 79
pontos de montagem RAID embutido, 79
(Ver armazenamento, sistema de arquivo, ponto de visão geral do, 76
montagem) RAM, 47
printconf recuperação de desastres
(Ver configuração da impressora) backups, disponibilidade de, 175
printtool disponibilidade de hardware, 175
(Ver configuração da impressora) disponibilidade de software, 175
fim do, 176
introdução a, 172
Q local de backup, 174
conectividade de rede ao, 175
quota, disco
funcionários do, 175
(Ver quotas de disco)
planejar, criar, testar, implementar, 173
quotas de disco
recursos do sistema
administração do, 109
(Ver recursos, sistema)
ativando, 108
recursos relacionados à largura de banda
introdução ao, 106
(Ver recursos, sistema, largura de banda)
visão geral do, 107
recursos, importância dos, 5
específico ao grupo, 107
recursos, sistema
específico ao sistema de arquivo, 107
armazenamento
específico ao usuário, 107
(Ver armazenamento)
limites rígidos, 108
energia de processamento
limites suaves, 108
monitoramento da, 15
período de carência, 108
largura de banda, 31
registro do uso do bloco, 107
a função dos canais na, 31
registro do uso do inode, 108
canais, exemplos de, 32
capacidade, aumento, 33
carga, distribuição, 33
R carga, redução, 33
RAID centrais de dados (datapaths), exemplos de, 32
conjuntos centrais de dados (datapaths), função no, 32
administração do, 112 monitoramento da, 16
comando raidhotadd, uso do, 112 problemas relacionados a, 32
recriando, 112 soluções de problemas com a, 33
status, verificando, 112 visão geral da, 31
conjuntos, criando, 110 memória
após a instalação, 111 (Ver memória)
na hora da instalação, 110 poder de processamento, 31
contrastada com o LVM, 82 aplicações, eliminar, 36
criando conjuntos atualizando, 37
(Ver RAID, conjuntos, criando) capacidade, aumento, 37
implementações do, 80 carga, redução, 36
190

consumidores do, 34 Suporte via Internet, 154


CPU, atualizando, 37 visão geral, 154
falta da, suprindo, 35 swapping, 52
fatos relacionados ao, 34 Sysstat, 18, 23
multiprocessamento simétrico, 37 system-config-printer
o uso da aplicação do, 35 (Ver configuração da impressora)
o uso do sistema operacional do, 35
SMP, 37
sobrecarga das aplicações, reduzir, 36 U
sobrecarga do S/O, reduzir, 36
UID, 129
visão geral da, 34 usuários
registre sua assinatura, iv importância dos, 6
registro da assinatura, iv
repetição
(Ver repetição)
RPM, 10

S
scripts da janela de comandos, 8
segurança
importância dos, 6
informações específicas ao Red Hat Enterprise
Linux, 10
senha, 118
brevidade da, 119
conjunto de caracteres grande usado na, 121
escritas, 121
expiração, 122
fortes, 121
fraca, 119
informações pessoais usadas na, 120
mais longas, 121
memorável, 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 detecção de intrusão, 10
SMB, 101
SMP, 37
software
suporte a
auto-suporte, 154
documentação, 154
suporte na empresa (on-site), 155
suporte telefônico, 155
suporte via e-mail, 154
Considerações finais
Os manuais são escritos no formato DocBook SGML versão 4.1. Os formatos HTML e PDF são pro-
duzidos usando stylesheets DSSSL personalizadas e scripts jade wrapper personalizados. Os arquivos
SGML do DocBook são escritos em Emacs com o auxílio do modo PSGML.
Garrett LeSage criou as imagens de alerta (nota, dica, importante, atenção e aviso). Elas podem ser
distribuídas livremente com a documentação da Red Hat.
A Equipe de Documentação de Produtos da Red Hat Linux é composta pelas seguintes pessoas:
Sandra A. Moore — Autora Principal/Mantenedora do Red Hat Enterprise Linux Guia de Instalação
para sistemas x86, Itanium™, AMD64 e Intel® Extended Memory 64 Technology (EM64T da Intel®);
Autora Principal/Mantenedora do Red Hat Enterprise Linux Guia de Instalação para Arquitetura
POWER da IBM®; Autora Principal/Mantenedora do Red Hat Enterprise Linux Guia de Instalação
para as Arquiteturas IBM® S/390® e IBM® eServer™ zSeries®
John Ha — Autor Principal/Mantenedor do Configurando e Administrando um Cluster do Red Hat
Cluster Suite; Co-autor/Co-mantenedor do Guia de Segurança do Red Hat Enterprise Linux; Man-
tenedor dos stylesheets e scripts DocBook personalizados
Edward C. Bailey — Autor Principal/Mantenedor do Introdução à Administração de Sistemas Red Hat
Enterprise Linux; Autor Principal/Mantenedor das Notas de Versão; Autor contribuinte do Guia de
Instalação 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
Aplicações; Autora Principal/Mantenedora do Red Hat SELinux Guia das Normas de Escrita
Andrius Benokraitis — Autor Principal/Mantenedor do Guia de Referência do Red Hat Enterprise
Linux; Co-autor/Co-mantenedor do Guia de Segurança do Red Hat Enterprise Linux; Autor Con-
tribuinte do Guia de Administração de Sistemas Red Hat Enterprise Linux
Paul Kennedy — Autor Principal/Mantenedor do Guia do Administrador do Red Hat GFS; Autor
Contribuinte do Configurando e Administrando um Cluster do Red Hat Cluster Suite
Mark Johnson — Autor Principal/Mantenedor do Guia de Administração e Configuração do Desktop
Red Hat Enterprise Linux
Melissa Goldin — Autora Principal/Mantenedora do Guia Passo a Passo do Red Hat Enterprise Linux
A Equipe de Internacionalização da Red Hat é composta pelas seguintes pessoas:
Amanpreet Singh Alam — traduções para Punjabi
Jean-Paul Aubry — traduções para o Francês
David Barzilay — traduções para o Português Brasileiro
Runa Bhattacharjee — traduções para Bengali
Chester Cheng — traduções para o Chinês Tradicional
Verena Fuehrer — traduções para o Alemão
Kiyoto Hashida — traduções para o Japonês
N. Jayaradha — traduções para Tamil
Michelle Jiyeen Kim — traduções para o Coreano
Yelitza Louze — traduções para o Espanhol
Noriko Mizumoto — traduções para o Japonês
Ankitkumar Rameshchandra Patel — traduções para Gujarati
Rajesh Ranjan — traduções para Hindi
192

Nadine Richter — traduções para o Alemão


Audrey Simons — traduções para o Francês
Francesco Valente — traduções para o Italiano
Sarah Wang — traduções para o Chinês Simplificado
Ben Hung-Pin Wu — traduções para o Chinês Tradicional

You might also like