Escolar Documentos
Profissional Documentos
Cultura Documentos
Introdução à Administração de
Sistemas
Red Hat Enterprise Linux 4: Introdução à Administração de Sistemas
Copyright © 2005 por 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/.
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.
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.
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/.
https://www.redhat.com/apps/activate/newlogin.html
https://rhn.redhat.com/help/forgot_password.pxt
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.
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.
"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)
• 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
• 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.
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
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. 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
• 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ê.
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.
• 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.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
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
• 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-
• 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.
• 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
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.
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
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.
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.
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:
• free
• top (e Monitor GNOME do Sistema, uma versão mais gráfica do top)
• vmstat
2.5.1. free
O comando free apresenta a utilização da memória do sistema. Aqui está um exemplo de seu output:
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
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:
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).
É 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:
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:
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.
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:
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).
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:
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.
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.
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.
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:
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.
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.
opcontrol \
--vmlinux=/boot/vmlinux-‘uname -r‘ \
--ctr0-event=CPU_CLK_UNHALTED \
--ctr0-count=6000
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:
(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.
...
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.
• 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.
• 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.
• Canais (buses)
• Centrais de Dados (Datapaths)
As seções a seguir exploram cada um em detalhes.
• 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
• 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
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.
• Distribuir a carga
• Reduzir a carga
• Aumentar a capacidade
As seções seguinites exploram cada uma das táticas detalhadamente.
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.
• 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.
• Reduzir a carga
• Aumentar a capacidade
36 Capítulo 3. Largura de Banda e Poder de Processamento
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
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.
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:
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
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):
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:
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:
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.
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:
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
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:
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:
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:
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":
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):
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:
para esta:
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
• 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.
• 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.
• 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 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.
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.
• 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:
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.
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.
• 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.
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.
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.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:
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.
• 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.
• 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).
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:
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:
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:
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:
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:
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
• 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.
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
• 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.
• 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.
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.
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.
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.
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.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.
• 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).
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.
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.
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.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.
• 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.
• 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.
• 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:
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.
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.
• 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:
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.
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.
• 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:
• 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:
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
• 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.
• 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
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.
• 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.
• 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.
• 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.
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.
• Acesso a Arquivos
• Compartilhamento de Arquivos
• 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
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.
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
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.
• 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.
• 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:
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.
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
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.
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
• Tipo de dispositivo
• Unidade
• Partição
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:
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.
• 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.
• 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.
• 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.
/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.
• Visualizar o /etc/mtab
• Visualizar o /proc/mounts
• Atribuindo o comando df
/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)
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.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.
• 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:
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
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)
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.
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:
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).
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.
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.
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.
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:
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:
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.
• 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
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.
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.
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
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
Personalities : [raid1]
read_ahead 1024 sectors
md1 : active raid1 hda3[0] hdc3[1]
522048 blocks [2/2] [UU]
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:
• 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.
• 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.
• 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.
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.
• 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
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:
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.
• É secreta
• É resistente a ser descoberta
• É resistente a um ataque brute-force
As seções seguintes mostram como as senhas podem ser fracas.
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.
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.
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.
• drowssaPdaB1
• R3allyP00r
Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 121
• 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.
• 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.
• 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.).
• 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
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.
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.
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:
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.
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.
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:
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:
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
• 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:
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
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.
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.
• 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.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
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.
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.
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 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.
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.
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.
• 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.
• 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.
• 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.
• Falhas de hardware
• Falhas de software
• Falhas de ambiente
• Erros humanos
• 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.
Dica
Antes de você experimentar reparar o hardware sozinho, certifique-se de que o hardware em
questão:
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.
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.
• 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.
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:
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.
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.
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
• 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
• Sistema operacional
• Aplicações
Cada tipo de falha tem seus próprios impactos e é explorada detalhadamente nas seções seguintes.
• 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.
• 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.
• 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.
• Integridade da construção
• Eletricidade
• Ar condicionado
• Clima e o mundo externo
• 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.
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:
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:
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.
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:
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
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.
• 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.
• Um interruptor de transferência para mudar da fonte de energia principal para a fonte de energia
backup
• Uma bateria, para prover energia backup
• 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.
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.
• 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
• 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.
• 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.
• 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.
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
• 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?
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.2. Backups
Os backups tem dois objetivos principais:
• 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.
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.
• 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.
• Backups completos
• Backups incrementais
• Backups diferenciais
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.
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.
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.
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.
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.
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.
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.
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:
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:
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:
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).
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.
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".
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.
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).
• 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
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
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