Red Hat Enterprise Linux 4 Introdução à Administração de
Transcrição
Red Hat Enterprise Linux 4 Introdução à Administração de
Red Hat Enterprise Linux 4 Introdução à Administração de Sistemas Red Hat Enterprise Linux 4: Introdução à Administração de Sistemas Copyright © 2005 por Red Hat, Inc. Red Hat, Inc. 1801 Varsity Drive Raleigh NC 27606-2072 USA Telefone: +1 919 754 3700 Telefone: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Research 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 [email protected] é: 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 introdutó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 relacionados 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 Sistemas Red Hat Enterprise Linux da forma que quiserem. Por exemplo: um administrador de sistemas experiente com pouco conhecimento do Red Hat Enterprise Linux, pode abordar somente as 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 consultar o Guia de Referência do Red Hat Enterprise Linux. As versões HTML, PDF e RPM dos manuais estão disponíveis no CD de Documentação do Red Hat Enterprise Linux e online: http://www.redhat.com/docs/. Nota Apesar deste manual refletir as informações mais recentes possíveis, leia as Notas da Versão do Red Hat Enterprise Linux para acessar as informações que não estavam disponíveis antes da finalização de nossa documentação. Elas podem ser encontradas no CD 1 do Red Hat Enterprise Linux e online: http://www.redhat.com/docs/. 1. Informações específicas da arquitetura Exceto quando informado, todas as informações contidas neste manual se aplicam somente ao processador x86 e aos processadores com as tecnologias Intel® Extended Memory 64 Technology (EM64T da Intel®) e AMD64. Para obter informações de arquiteturas específicas, consulte o Guia de Instalação do Red Hat Enterprise Linux. ii Introdução 2. Convenções de Documentos Ao ler este manual, determinadas palavras estão representadas com fontes, tipos, tamanhos e pesos diferentes. Este destaque é sistemático; palavras diferentes são representadas no mesmo estilo para indicar sua inclusão em uma categoria específica. Os tipos de palavras representadas desta maneira incluem as seguintes: comando Os comandos do Linux (e comandos de outros sistemas operacionais, quando usados) são representados desta maneira. Este estilo indica que você pode digitar a palavra ou frase na linha de comandos e pressionar [Enter] para invocar um comando. Às vezes o comando 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 representados 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 diferentes do sistema. Instale o RPM webalizer se você quiser usar um programa de análise do arquivo de registro do servidor Web. aplicação Este estilo indica que o programa é uma aplicação direcionada ao usuário final (ao contrário do software do sistema). Por exemplo: Use o Mozilla para navegar na Web. [tecla] Uma tecla do teclado é exibida neste estilo. Por exemplo: Para usar a tecla complementar [Tab] num terminal, digite um caractere e então pressione a tecla [Tab]. Seu terminal exibe uma lista dos arquivos contidos no diretório que começam com esta letra. [tecla]-[combinação] Uma combinação de sequência de teclas é representada desta maneira. Por exemplo: A combinação de teclas [Ctrl]-[Alt]-[Espaço] termina sua sessão gráfica, retornando à tela ou ao console da autenticação gráfica. texto exibido em uma interface GUI (gráfica) Um título, palavra ou frase na tela ou janela da interface GUI é exibida neste estilo. O texto exibido neste estilo é usado na identificação de uma tela GUI específica ou um elemento de uma tela GUI (como o texto associado a uma caixa de verificação ou campo). Exemplo: Selecione a caixa de verificação Solicitar Senha se você deseja que seu protetor de tela solicite uma senha antes de ser desbloqueado. Introdução iii nível superior de um menu em uma tela ou janela GUI Uma palavra neste estilo indica que a palavra está no nível superior de um menu suspenso (pulldown menu). Se você clicar na palavra na tela GUI, o resto do menu deverá aparecer. Por exemplo: Abaixo de Arquivo em um terminal do GNOME, você verá a opção Nova Aba, que permite a você abrir diversos prompts de comando na mesma janela. Se você precisar digitar uma sequência de comandos a partir de um menu GUI, eles são exibidos como o exemplo a seguir: Vá para Botão do Menu Principal (no Painel) => Programação => Emacs para iniciar o editor de texto Emacs. botão em uma tela ou janela GUI Este estilo indica que o texto pode ser encontrado em um botão clicável de uma tela GUI. Por exemplo: Clique no botão Voltar para retornar à última página web que você visitou. output do computador Texto neste estilo indica o texto exibido em uma janela de comandos, como mensagens de erro e respostas a comandos. Por exemplo: O comando ls exibe o conteúdo de um diretório: Desktop Mail about.html backupfiles logs mail paulwesterberg.png 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 comando 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 determinadas partes da informação. De acordo com o quão crucial as informações são para seu sistema, elas são apresentadas como uma nota (lembrete), dica, importante, atenção ou um aviso. Por exemplo: iv Introdução Nota Lembre-se que o Linux é sensível a maiúsculas e minúsculas. Em outras palavras, uma rosa não é uma ROSA nem uma rOsA. Dica O diretório /usr/share/doc/ contém documentação adicional para os pacotes instalados em seu sistema. Importante Se você modificar o arquivo de configuração do DHCP, as alterações não terão efeito até que você reinicie o daemon do DHCP. Atenção Não execute tarefas de rotina como root — use uma conta de usuário comum, a não ser que você precise usar a conta root para tarefas de administração do sistema. Aviso Cuidado para remover somente as partições necessárias do Red Hat Enterprise Linux. Remover outras partições pode resultar na perda de dados ou num ambiente de sistema corrompido. 3. Ative Sua Assinatura Antes de poder acessar as informações de manutenção do software e serviços, e a documentação de suporte inclusa em sua assinatura, você deve ativar sua assinautra registrando-a na Red Hat. O registro inclui estes passos simples: • Prover um login para a Red Hat • Prover um número para a assinatura • Conectar seu sistema Na primeira vez que iniciar a instalação de seu Red Hat Enterprise Linux, você verá o pedido de registro na Red Hat usando o Agente de Configuração. Se você seguir os pedidos durante o Agente de Configuração, poderá completar os passos do registro e ativar sua assinatura. Introdução v Se você não puder completar o registro durante o Agente de Configuração (que requer acesso à rede), pode, alternativamente, completar o processo de registro da Red Hat online: http://www.redhat.com/register/. 3.1. Prover um Login para a Red Hat Se você ainda não possui um login para a Red Hat, pode criá-lo quando for solicitado no Agente de Configuração ou online em: https://www.redhat.com/apps/activate/newlogin.html Um login da Red Hat habilita seu acesso a: • Atualizações, erratas e manutenção do software através da Red Hat Network • Recursos do suporte técnico, documentação e base de dados de conhecimento (knowledgebase) da Red Hat Se você esqueceu seu login da Red Hat, pode fazer uma busca online em: https://rhn.redhat.com/help/forgot_password.pxt 3.2. Prover Seu Número de Assinatura Seu número de assinatura está localizado no pacote que acompanha seu pedido. Caso seu pacote não inclua um número de assinatura, sua assinautra já foi ativada e, portanto, você pode pular este passo. Você pode prover seu número de assinatura ao ser solicitado durante o Agente de Configuração ou visitando http://www.redhat.com/register/. 3.3. Conectar Seu Sistema O Cliente de Registro da Red Hat Network auxilia na conexão de seu sistema para que você possa obter as atualizações e efetuar a administração de sistemas. Há três maneiras para conectar: 1. Durante o Agente de Configuração — Selecione as opções Enviar informações de hardware e Enviar lista de pacotes do sistema quando aparecerem. 2. Após completar o Agente de Configuração — No Menu Principal, clique em Ferramentas do Sistema, e então selecione Red Hat Network. 3. Após completar o Agente de Configuração — Invoque o seguinte na janela de comandos como usuário root: • /usr/bin/up2date --register 4. Mais por Vir O Introdução à Administração de Sistemas Red Hat Enterprise Linux é parte do crescente comprometimento da Red Hat em prover suporte útil e oportuno aos usuários do Red Hat Enterprise Linux. Juntamente ao lançamento de novas versões do Red Hat Enterprise Linux, nós depositamos todos os nossos esforços para incluir documentação nova e atualizada para você. vi Introdução 4.1. Envie-nos Seu Feedback Se você encontrar um erro de digitação no Introdução à Administração de Sistemas Red Hat Enterprise Linux, ou se você encontrou uma maneira de melhorar este manual, nós adoraríamos saber. Por favor, submeta um relatório no Bugzilla (http://bugzilla.redhat.com/bugzilla) sobre o componente rhel-isa. Certifique-se de mencionar o identificador do manual: rhel-isa(PT)-4-Impressão-RHI (2004-08-25T17:11) Se você mencionar o identificador, nós saberemos exatamente qual versão do guia você possui. Se você tiver alguma sugestão para melhorar a documentação, tente ser o mais específico possível. Se encontrar um erro, por favor inclua o número da seção e um trecho do texto próximo ao erro para que possamos localizá-lo facilmente. Capítulo 1. A Filosofia da Administração de Sistemas Apesar das particularidades de um administrador de sistemas variarem de acordo com a plataforma, há questões básicas que não variam. Estas questões compoem a filosofia da administração de sistemas. As questões são: • Automatizar tudo • Documentar tudo • Comunicar o máximo possível • Conhecer seu recursos • Conhecer seus usuários • Conhecer seu negócio • A segurança não pode ser postergada • Planejar com antecedência • Espere o inesperado As seções seguintes exploram cada uma das questões em detalhes. 1.1. Automatizar Tudo A maioria dos administradores de sistemas é sobrecarregado — seja pelos seus usuários, pelos seus sistemas ou por ambos. Em muitos casos, a automação é a única saída. Em geral, qualquer atividade executada mais de uma vez deve ser analisada como uma possível candidata para automação. Aqui estão algumas tarefas comumente automatizadas: • Verificação e relatório do espaço livre em disco • Backups • Coleta de dados sobre o desempenho do sistema • Manutenção da conta do usuário (criação, remoção, etc) • Funções específicas a negócios mensais/quadrimestrais/anuais, etc) (envio de dados a um servidor Web, relatórios Esta lista não está completa; as funções automatizadas por administradores de sistemas são limitadas somente pela vontade do administrador em escrever os scripts necessários. Neste caso, ser preguiçoso (e deixar todo o trabalho mundano para o computador) é uma coisa boa. A automação também oferece aos usuários o benefício extra de prever melhor a consistência dos serviços. Dica Tenha em mente que, se você tiver que automatizar uma tarefa, é provável que você não seja o primeiro administrador de sistemas com essa necessidade. É aqui que os benefícios do software livre se sobressaem — você pode alavancar o trabalho que outra pessoa teve em automatizar o 2 Capítulo 1. A Filosofia da Administração de Sistemas trabalho manual que atualmente consome seu tempo. Portanto, sempre busque na Internet antes de escrever qualquer coisa mais complexa que um script Perl. 1.2. Documentar Tudo Se tivesse a opção de instalar um servidor novinho ou escrever um documento de procedimentos sobre a execução de backups do sistema, o administrador de sistemas mediano instalaria o servidor novo toda vez. Apesar disso ser bastante comum, você deve documentar o que faz. Muitos administradores de sistemas deixam de documentar seus procedimentos por diversas razões: "Mais tarde eu faço." Infelizmente, isto não é verdade na maioria das vezes. Mesmo se o administrador de sistemas não estiver brincando, a natureza do trabalho faz com que as atividades do cotidiano tornem-se muito caóticas para "fazer mais tarde." Pior ainda, quanto mais a tarefa é adiada, mais é esquecida, levando à produção de um documento menos detalhado (e portanto menos útil). "Por quê anotar? Eu vou lembrar." A não ser que você seja uma daquelas pessoas com memória fotográfica, você não lembrará. Ou pior, lembrará somente metade, sem perceber que está esquecendo a história toda. Isto acarreta em tempo perdido na tentativa de re-aprender o que você esqueceu ou consertar o que você quebrou devido a seu entendimento incompleto da situação. "Seu eu manter na minha mente, eles não poderão me despedir — terei estabilidade no emprego!" Apesar disto poder funcionar por um tempo, invariavelmente acarreta em menor — e não maior — estabilidade de emprego. Por um momento, pense no que pode ocorrer durante uma emergência. 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 determinada 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 problemas 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 — configurar 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 contrário, você pode encontrar-se numa situação muito confusa devido uma alteração feita há vários meses. Algumas empresas utilizam métodos mais complexos para registrar as alterações, mas, muitas vezes, basta apenas ter uma revisão da história no início do arquivo sendo modificado. Cada entrada da história revisada deve conter, no mínimo: • O nome ou as iniciais da pessoa efetuando a alteração • A data da alteração • A razão da alteração Isso resulta em entradas concisas, porém úteis: ECB, 12-Junho-2002 — Item atualizado para a nova impressora de Contabilidade (para suportar a substituição da habilidade em imprimir duplex) 1.3. Comunique o Máximo Possível Quando se trata de seus usuários, não há comunicação demasiada. Tenha em mente que pequenas alterações de sistemas que você pensa ser ínfimas podem confundir totalmente o assistente administrativo de Recursos Humanos. O método através do qual você se comunica com seus usuários pode variar de acordo com a sua empresa. Agumas empresas usam e-mail; outras usam um site interno. Algumas ainda utilizam Usenet ou IRC. Em algumas empresas é suficiente colocar um comunicado no mural da sala de funcionários. Em qualquer um dos casos, use o(s) método(s) eficaz(es) em sua organização. Em geral, é melhor utilizar esta tática usada para escrever artigos de jornal: 1. Informe aos seus usuários o que você fará 2. Informe aos seus usuários o que você está fazendo 3. Informe aos seus usuários o que você fez As seções a seguir trazem mais detalhes sobre estes passos. 1.3.1. Informe aos Seus Usuários o Que Você Fará Certifique-se de prover suficiente avisos aos seus usuários antes de fazer qualquer coisa. A quantidade de avisos varia necessariamente de acordo com o tipo de alteração (fazer o upgrade de um sistema operacional demanda mais tempo que alterar a cor default da tela de login do sistema), e também com a natureza da sua comunidade de usuários (usuários com perfil mais técnico geralmente adaptam-se mais rapidamente às alterações que usuários com poucas ou nenhuma característica técnica.) Você deve descrever, no mínimo: • A natureza da alteração • Quando a alteração ocorrerá • Porque está ocorrendo • Quanto tempo deve levar, aproximadamente • O impacto (se houver) que os usuários podem esperar devido a alteração 4 • Capítulo 1. A Filosofia da Administração de Sistemas Informações de contato caso tenham dúvidas ou problemas Eis uma situação hipotética. O departamento de finanças está enfrentando problemas de lentidão em seu servidor de banco de dados. Você desligará o servidor, atualizará (upgrade) o módulo da CPU para um modelo mais veloz e o reinicializará. Uma vez terminado, você moverá o banco de dados para um armazenamento mais rápido baseado no RAID. Aqui está um possível comunicado para essa situação: Atualização do Sistema na Sexta à Noite A partir desta sexta-feira às 18hs (meia-noite para nossos funcionários do escritório em Berlim), todas as aplicações financeiras estarão indisponíveis por aproximadamente quatro horas. Durante este período, serão executadas alterações no hardware e software do banco de dados de finanças. Estas alterações devem reduzir drasticamente o tempo necessário para rodar as aplicações de Contas a Pagar, Contas a Receber, e também o relatório de Balanço Semanal. Além do tempo fora do ar, a maioria das pessoas não deve notar outras alterações. No entanto, aqueles que elaboraram suas próprias consultas ao SQL devem estar cientes que o layout de alguns índices será alterado. Estas alterações estão documentadas na intranet da empresa, na página de Finanças. Caso vocês tenham alguma dúvida ou comentário, favor contatar o Administrador de Sistemas no ramal 4321. Alguns pontos devem ser lembrados: • Comunique efetivamente o início e a duração de qualquer tempo fora do ar que possa estar envolvido na alteração. • Certifique-se de informar a hora da alteração de maneira eficaz a todos os usuários, independente de suas localidades. • Use termos que seus usuários entendam. As pessoas impactadas por esta mudança não se importam se o novo modelo da CPU é uma unidade de 2GHz com o dobro de memória cache L2, ou se o banco de dados é alocado num volume lógico RAID 5. 1.3.2. Informe aos Seus Usuários O Que Você Está Fazendo Este passo é basicamente um aviso de última hora da alteração prestes a ocorrer e, como tal, deve ser uma breve repetição da primeira mensagem, porém com a iminência da alteração mais aparente ("A atualização do sistema ocorrerá HOJE À NOITE."). Esta também é uma boa oportunidade para responder publicamente quaisquer perguntas que você tenha recebido como resultado da primeira mensagem. Dando continuidade ao nosso exemplo hipotético, aqui está uma sugestão para o aviso de última hora: Atualização do Sistema Programada para Hoje à Noite Lembrete: A atualização anunciada na última segunda-feira ocorrerá conforme programada, hoje às 18hs (meia-noite para o escritório de Berlim). Você pode conferir o comunicado original na intranet, na página de Administração de Sistemas. Diversas pessoas perguntaram se deveriam parar de trabalhar mais cedo hoje à noite para garantir que seus trabalhos tenham backup antes da atualização. Isto não será necessário, visto que a atualização dos sistemas de hoje à noite não impactará nenhuma tarefa efetuada em suas estações de trabalho. Lembrem-se: aqueles que elaboraram suas próprias consultas ao SQL devem saber que o layout de alguns índices será alterado. Isto está documentado na intranet da empresa, na página de Finanças. Seus usuários foram alertados; agora você está pronto para efetuar a atualização em si. Capítulo 1. A Filosofia da Administração de Sistemas 5 1.3.3. Informe aos Seus Usuários O Que Você Fez Após finalizar suas alterações, você deve informar aos seus usuários o que você fez. Novamente, esta deve ser um resumo das suas mensagens anteriores (com certeza, alguém deixou de lê-las.) 1 Entretanto, há algo importante a acrescentar. É vital informar seus usuários sobre o estado atual do sistema. A atualização não ocorreu conforme esperado? O novo servidor de armazenamento serve apenas sistemas de Engenharia e não de Finanças? Este tipo de questões deve ser mencionado aqui. Obviamente, se o estado atual difere do que você comunicou anteriormente, você deve clarificar este ponto e descrever o que será feito (se houver medidas determinadas) para atingir a solução final. Em nossa situação hipotética, a atualização teve alguns problemas. O novo modelo de CPU não funcionou; uma ligação ao fabricante revelou que é necessária uma nova versão do módulo para atualizações deste tipo. No aspecto positivo, a migração do banco de dados ao volume RAID foi executada com sucesso (apesar de ter demorado um pouco mais devido a problemas com o módulo da CPU.) Aqui está uma sugestão de comunicado: Atualização do Sistema Completa A atualização de sistema programada para sexta-feira à noite (consulte a página de Administração de Sistemas na intranet) foi completa. Infelizmente, questões relacionadas ao hardware impediram que uma das tarefas fosse completa. Devido este problema, as outras tarefas demoraram mais que as quatro horas originalmente programadas. Portanto, todos os sistemas estavam de volta à produção à meia-noite (às 6hs do sábado para o escritório de Berlim). Devido às questões remanescentes de hardware, o desempenho da AP, AR e do relatório de Balanço Semanal será ligeiramente melhor, mas não tanto quanto planejado originalmente. Uma segunda atualização será comunicada e programada assim que resolvermos as questões que impossibilitaram a conclusão da tarefa. Favor notar que a atualização alterou alguns índices de banco de dados; as pessoas que elaboraram suas própiras consultas ao SQL devem verificar a página de Finanças na intranet da empresa. No caso de dúvidas, favor contatar a Administração de Sistemas no ramal 4321. Com este tipo de informação, seus usuários terão conhecimento suficiente para continuarem seus trabalhos e entenderem como as alterações os impactam. 1.4. Conheça Seus Recursos A administração de sistemas consiste basicamente em balancear recursos entre as pessoas e os programas que os utilizam. Consequentemente, sua carreira como administrador de sistemas será curta e estressante se você não entender perfeitamente os recursos à sua disposição. Alguns destes recursos parecem bastante óbvios: • Recursos de sistema, como o poder de processamento, a memória e o espaço disponível em disco • Largura de banda de rede (network bandwidth) • Dinheiro disponível no orçamento de TI Mas alguns não são tão óbvios: 1. Certifique-se de enviar esta mensagem assim que o trabalho estiver concluído, antes de ir para casa. Após sair do escritório, é muito fácil esquecer, deixando seus usuários sem saber se podem usar o sistema ou não. 6 Capítulo 1. A Filosofia da Administração de Sistemas • Os serviços dos funcionários de operações, outros administradores de sistemas ou até mesmo um assistente administrativo • Tempo (geralmente de suma importância, principalmente quando envolve o tempo durante o qual serão feitos backups do sistema) • Conhecimento (seja armazenado em livros, na documentação do sistema ou na mente de uma pessoa que trabalhou para a empresa nos últimos 20 anos) É importante notar o valor de elaborar um inventário completo destes recursos disponíveis e mantê-lo atualizado — a falta de "consciência da situação" dos recursos pode ser pior que consciência nenhuma. 1.5. Conheça Seus Usuários Apesar de algumas pessoas se incomodarem com o termo "usuários" (talvez devido ao uso do termo por algum administrador de sistemas de forma pejorativa), é usado aqui sem esta conotação. Usuários são as pessoas que utilizam os sistemas e recursos pelos quais você é responsável — nem mais, nem menos. Como tais, eles são centrais para sua habilidade em administrar seus sistemas adequadamente. Sem entender seus usuários, como você pode entender os recursos de sistema solicitados por eles? Por exemplo: imagine um operador de caixa de banco. Um caixa de banco utiliza um conjunto de aplicações estritamente definido e requer pouco dos recursos de sistema. Um engenheiro de software, por outro lado, usa muitas aplicações diferentes e sempre agradece mais recursos de sistema (para tempos de criação mais rápidos). Dois usuários completamente diferentes com necessidades completamente diferentes. Certifique-se de aprender o máximo possível a respeito de seus usuários. 1.6. Conheça Seu Negócio Mesmo se você trabalha para uma empresa grande e multinacional, ou então para uma pequena escola comunitária, deve entender a natureza do ambiente de negócios no qual você trabalha. Isto pode ser resumido em uma questão: Qual é o propósito dos sistemas que você administra? O ponto central aqui é entender o propósito de seus sistemas sob um aspecto mais global: • As aplicações que devem rodar num determinado período de tempo, como o fim de um mês, de um quadrimestre ou de um ano • Os períodos durante os quais deve ser feita a manutenção do sistema • As novas tecnologias que podem ser usadas para resolver antigos problemas do negócio Levando em consideração o negócio da sua empresa, você tomará melhores decisões diárias para seus usuários e para você. 1.7. A Segurança Não Pode ser Postergada Não importa o que você pensa sobre o ambiente no qual seus sistemas rodam; você não pode ignorar o fator segurança. Mesmo sistemas standalone não conectados à Internet podem estar em risco (apesar dos riscos serem obviamente diferentes de um sistema que tem conexões com o mundo externo). Consequentemente, é extremamente importante considerar as implicações de segurança em tudo que você fizer. A lista seguinte ilustra os tipos de questões que você deve considerar: • A natureza de possíveis ameaças a cada um dos sistemas sob seus cuidados Capítulo 1. A Filosofia da Administração de Sistemas • A localidade, o tipo e o valor dos dados nestes sistemas • O tipo e a frequência de acesso autorizado a estes sistemas 7 Quando pensar em segurança, não cometa o erro de assumir que os possíveis ataques a seus sistemas virão apenas de fora da empresa. Muitas vezes, o invasor é alguém de dentro da empresa. Portanto, na próxima vez que você caminhar pelo escritório, observe as pessoas ao seu redor e pergunte a si mesmo: O que aconteceria se esta pessoa tentasse sabotar nossa segurança? Nota Isso não significa que você deve tratar seus colegas de trabalho como criminosos. Mas que você deve observar o tipo de trabalho de cada um e determinar os tipos de brechas na segurança que uma pessoa naquela função poderia perpetrar, caso tivesse essa vontade. 1.7.1. Os Riscos da Engenharia Social Apesar da primeira reação da maioria dos administradores de sistemas quando pensa na segurança ser concentrar nos aspectos tecnológicos, é importante manter a perspectiva. Frequentemente, as brechas na segurança não são originadas na tecnologia, mas na natureza humana. Pessoas interessadas nas brechas de segurança frequentemente usam a natureza humana para burlar inteiramente os controles de acesso tecnológico. Isso é conhecido como engenharia social. Eis um exemplo: O operador do segundo turno recebe uma ligação externa. A pessoa que ligou clama ser o Diretor Financeiro da empresa (seu nome e informações foram obtidos no site da empresa, na página "Equipe de Gerência"). A pessoa que ligou clama estar em algum lugar do outro lado do globo (talvez esta parte da história seja ficção total, ou talvez o site de sua empresa tenha publicado uma nota de imprensa mencionando a presença do diretor numa feira internacional). A pessoa que ligou conta uma fábula: seu laptop foi roubado no aeroporto, ele está com um cliente importante e, portanto, precisa de acesso à intranet corporativa para verificar a conta deste cliente. Será que o operador deve ser bonzinho e dar as informações de acesso a ele? Você sabe o que seu operador faria? A não ser que ele tenha instruções (na forma de normas e processos), você provavelmente não sabe o que aconteceria. Assim como as luzes de um semáforo, o objetivo das normas e procedimentos é prover instruções explícitas sobre o que é e o que não é comportamento adequado. No entanto, assim como as luzes do semáforo, as normas e procedimentos funcionam somente se todos os seguem. Aqui está o X da questão — é improvável que todos sigam suas normas e procedimentos. Na realidade, dependendo da natureza de sua empresa, é possível que você nem tenha autoridade suficiente para definir normas, muito menos para reforçá-las. O que fazer então? Infelizmente, não há respostas fáceis. A educação dos usuários pode ajudar: faça tudo que você puder para alertar sua comunidade de usuários sobre a segurança e engenharia social. Minstre apresentações sobre segurança no horário de almoço. Envie links de artigos sobre segurança nas listas de discussão da empresa. Enfatize sua disponibilidade para as perguntas de seus usuários sobre coisas que não parecem corretas. Em suma, envie sua mensagem aos usuários de todas as formas que puder. 8 Capítulo 1. A Filosofia da Administração de Sistemas 1.8. Planejar com Antecedência Os administradores de sistemas que absorveram todo este aconselhamento e fizeram o possível para seguí-lo à risca, serão ótimos administradores de sistemas — por um dia. Eventualmente, o ambiente mudará e nosso administrador fantástico será pego de surpresa. Por que? Nosso fantástico administrador falhou em planejar com antecedência. Certamente, ninguém pode predizer o futuro com 100% de acuracidade. No entanto, com um pouco de consciência, fica fácil ler os sinais de muitas mudanças: • Uma simples menção de um novo projeto durante aquela reunião semanal sacal é, certamente, um sinal certeiro de que você provavelmente precisará suportar seus usuários no futuro próximo. • Uma conversa sobre uma aquisição iminente significa que você talvez acabe sendo responsável por sistemas novos (e possivelmente incompatíveis) em uma ou mais localidades remotas. Ser capaz de ler estes sinais (e responder a eles efetivamente) facilita a sua vida e a de seus usuários. 1.9. Espere o Inesperado Apesar da frase "esperar o inesperado" ser clichê, reflete uma verdade elementar que todos os administradores de sistemas devem entender: Haverá momentos em que você será pego de surpresa. Após estar confortável com este fato desconfortante, o que um administrador de sistemas engajado pode fazer? A resposta está na flexibilidade; executando seu trabalho de maneira a oferecer a você (e aos seus usuários) o maior número de opções possível. Abordemos, por exemplo, a questão do espaço em disco. Dado que nunca ter espaço suficiente em disco parece ser uma lei mais física do que a lei da gravidade, é razoável assumir que, em algum ponto, você será confrontado por uma necessidade desesperada imediata de espaço adicional em disco. O que faria um administrador de sistemas que espera o inesperado? Talvez seja possível manter alguns drives de disco reservas na prateleira no caso de problemas com o hardware 2 . Uma peça reserva deste tipo pode ser empregada rapidamente3 temporariamente para resolver a necessidade imediata de espaço em disco, alocando mais tempo para a solução definitiva (seguindo o procedimento padrão para a obtenção de drives de disco adicionais, por exemplo). Ao tentar antecipar os problemas antes de ocorrerem, você será capaz de responder mais rápida e efetivamente do que se você deixar se surpreender. 1.10. Informações Específicas do Red Hat Enterprise Linux Esta seção aborda as informações relacionadas à filosofia da administração de sistemas específicas ao Red Hat Enterprise Linux. 1.10.1. Automação A automação de tarefas executadas frequentemente sob o Red Hat Enterprise Linux requer o conhecimento de diversos tipos de tecnologia. Primeiro, os comandos que controlam o tempo do comando ou a execução do script. Os comandos cron e at são os mais usados para estas funções. 2. E, obviamente, um administrador de sistemas que espera o inesperado naturalmente usaria o RAID (ou tecnologias relacionadas) para amenizar o impacto da falha de um drive de disco crítico durante a produção. 3. Novamente: os administradores de sistemas que pensam pró-ativamente configuram seus sistemas de forma a facilitar o máximo possível a adição de um novo drive de disco ao sistema. Capítulo 1. A Filosofia da Administração de Sistemas 9 Incorporando um sistema de especificação de tempo bastante flexível, mas de fácil entendimento, o cron pode agendar a execução de comandos ou scripts em intervalos recorrentes, variando de minutos a meses. O comando crontab é usado para manipular os arquivos que controlam o daemon do cron, que na verdade agendam cada tarefa do cron para a execução. O comando at (e o comando batch relacionado) é mais apropriado para agendar a execução de scripts ou comandos para uma única ocorrência. Estes comandos implementam um sub-sistema batch rudimentar que consiste de múltiplas filas com prioridades de agendamento variadas. As prioridades são conhecidas como níveis de niceness (devido o nome do comando — nice). Ambos os comandos, at e batch, são perfeitos para tarefas que devem ocorrer com horário de início determinado, mas não são críticas em seu tempo de término. Em seguida, estão as diversas linguagens de script. Estas são as "linguagens de programação", usadas pelo administrador de sistemas comum para automatizar operações manuais. Há muitas linguagens de script (e cada administrador de sistemas geralmente tem sua favorita), mas as que seguem são as mais comuns no momento: • O comando de linha bash • A linguagem de script perl • A linguagem de script python Além das diferenças óbvias entre estas linguagens, a maior diferença é a maneira através da qual interagem com outros programas em um sistema Red Hat Enterprise Linux. Os scripts escritos com a janela de comandos bash tendem a utilizar mais extensivamente os diversos utilitários (por exemplo: para efetuar a manipulação dos strings de caracteres), enquanto os scripts perl executam mais esse tipo de operação usando funcionalidades integradas na própria linguagem. Um script escrito usando o python pode explorar totalmente as capacidades orientadas a objetos da linguagem, tornando os scripts mais complexos facilmente extensíveis. Isto significa que, para conhecer bem o script da janela de comandos, você deve se familiarizar com os diversos programas de utilitários (como grep e sed) que são parte do Red Hat Enterprise Linux. Aprender perl (e python), por outro lado, tende ser um processo mais "auto-suficiente". No entanto, muitas construções da linguagem perl são baseadas na sintaxe de diversos programas de utilitários tradicionais do UNIX, e portanto são familiares aos administradores de sistemas Red Hat Enterprise Linux com experência em scripts de janela de comandos. 1.10.2. Documentação e Comunicação Nas áreas de documentação e comunicação há poucas coisas específicas ao Red Hat Enterprise Linux. Como documentação e comunicação podem consistir de qualquer coisa, de adicionar comentários a um arquivo-texto de configuração a atualizar uma página web ou enviar um e-mail, um administrador de sistemas usando o Red Hat Enterprise Linux deve ter acesso a editores de texto, editores HTML e clientes de e-mail. Eis aqui uma pequena amostra dos diversos editores de texto disponíveis sob o Red Hat Enterprise Linux: • O editor de texto gedit • O editor de texto Emacs • O editor de texto Vim O editor de texto gedit é uma aplicação estritamente gráfica (ou seja, requer um ambiente do Sistema X Window), enquanto vim e Emacs são baseados em texto por natureza. 10 Capítulo 1. A Filosofia da Administração de Sistemas A questão sobre qual é o melhor editor de texto tem sido um debate quase tão longo quanto a existência dos computadores e continuará assim por um bom tempo. Consequentemente, o melhor a fazer é experimentar cada um dos editores e utilizar aquele que mais te agrada. Em termos de editores HTML, os administradores de sistemas podem usar a função Composer do navegador web Mozilla. Obviamente, alguns administradores de sistemas preferem codificar seu HTML manualmente, o que torna um editor de texto comum uma ferramenta perfeitamente aceitável. Em relação a e-mail, o Red Hat Enterprise Linux inclui o cliente gráfico de e-mail Evolution, o cliente de e-mail Mozilla (também gráfico) e o mutt, que é baseado em texto. Para os editores de texto, a escolha de um cliente de e-mail tende ser pessoal; portanto, o melhor a fazer é experimentar cada um dos clientes e usar o que funciona melhor para você. 1.10.3. Segurança Como mencionado anteriormente neste capítulo, a segurança não pode ser um pensamento posterior, e a segurança sob o Red Hat Enterprise Linux não é superficial. Os controles de acesso e autenticação são profundamente integrados ao sistema operacional e baseados em designs extraídos de longos anos de experiência da comunidade UNIX. Para autenticação, o Red Hat Enterprise Linux usa o PAM — Módulos de Autenticação Plugáveis. O PAM possibilita o ajuste fino da autenticação de usuários através da configuração de bibliotecas compartilhadas, usadas por todas as aplicações que baseiam sua autenticação no PAM. Tudo isso é feito sem a necessidade de alterações nas aplicações. O controle de acesso sob o Red Hat Enterprise Linux usa permissões tradicionais do estilo UNIX (ler/acessar, gravar e executar) para as classes usuário, grupo e "outros". Como no UNIX, o Red Hat Enterprise Linux também usa os bits setuid e setgid para conferir direitos de acesso expandido a processos rodando um programa específico, baseado na propriedade do arquivo do programa. Obviamente, 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 Enterprise Linux usa extensivamente os registros, nos níveis do kernel e da aplicação. O registro é controlado 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 operacional. No entanto, como o RPM é essencialmente uma ferramenta de administração de pacotes, suas habilidades como um IDS são de certa forma limitadas. Mesmo assim, pode ser um bom primeiro passo para monitorar um sistema Red Hat Enterprise Linux e verificar modificações não-autorizadas. Capítulo 1. A Filosofia da Administração de Sistemas 11 1.11. Recursos Adicionais Esta seção inclui diversos recursos que podem ser usados para aprender mais sobre a filosofia da administração de sistemas e sua relação específica com o Red Hat Enterprise Linux. 1.11.1. Documentação Instalada Os recursos a seguir são instalados no decorrrer de uma instalação típica do Red Hat Enterprise Linux e podem ajudá-lo a aprender mais sobre o assunto abordado neste capítulo. • Páginas man crontab(1) e crontab(5) — Aprenda como agendar comandos e scripts para execução automática em intervalos regulares. • Página man at(1) — Aprenda a agendar comandos e scripts para execução posterior. • Página man bash(1) — Aprenda mais sobre a janela de comandos (shell) default e como escrever scripts nesta. • Página man perl(1) — Indicações de diversos sites que compoem a documentação online do perl. • Página man python(1) — Aprenda mais sobre as opções, arquivos e variáveis de ambiente que controlam o interpretador Python. • Página man gedit(1) e item Help do menu — Aprenda a editar arquivos-texto com este editor de texto gráfico. • Página man emacs(1) — Aprenda mais sobre este editor de texto altamente flexível, inclusive como rodar seu tutorial online. • Página man vim(1) — Aprenda a usar este editor de texto poderoso. • O item Help Contents do menu do Mozilla — Aprenda a editar arquivos HTML, ler e-mails e navegar na web. • Página man evolution(1) e item Help do menu — Aprenda a administrar seus e-mails com cliente gráfico de e-mail. • Página man mutt(1) e arquivos em /usr/share/doc/mutt- versão istrar seus e-mails com este cliente de e-mail baseado em texto. • Página man pam(8) e arquivos em /usr/share/doc/pam- versão ciona a autenticação sob o Red Hat Enterprise Linux. — Aprenda a admin— Aprenda como fun- 1.11.2. Sites Úteis • http://www.kernel.org/pub/linux/libs/pam/ — A homepage do projeto Linux-PAM. • http://www.usenix.org/ — A homepage do USENIX. Uma organização profissional dedicada a reunir profissionais da computação de todos os tipos, fomentando a melhoria da comunicação e inovação. • http://www.sage.org/ — A homepage da Associação dos Administradores de Sistemas (System Administrators Guild). Um grupo técnico especial da USENIX que representa um bom recurso para todos os administradores responsáveis por sistemas Linux (ou parecidos com o Linux). • http://www.python.org/ — O site da Linguagem Python, excelente para aprender mais sobre esta. • http://www.perl.org/ — O site dos entusiastas do Perl; um bom lugar para começar a aprender sobre a linguagem e interagir com a comunidade Perl. • http://www.rpm.org/ — A homepage do Administrador de Pacotes RPM. O site mais detalhado sobre o RPM. 12 Capítulo 1. A Filosofia da Administração de Sistemas 1.11.3. Livros Relacionados A maioria dos livros sobre administração de sistemas não aborda a questão filosófica por trás do trabalho. Entretanto, os livros a seguir têm seções que trazem um pouco mais de profundidade às questões aqui abordadas: • O Guia de Referência do Red Hat Enterprise Linux; Red Hat, Inc. — Provém uma visão geral das localidades de arquivos de sistema importantes, configurações de usuário e grupo e configuração do PAM. • O Guia de Segurança do Red Hat Enterprise Linux; Red Hat, Inc. — Contém uma discussão detalhada sobre diversas questões relacionadas à segurança para administradores de sistemas Red Hat Enterprise Linux. • O Guia de Administração de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. — Inclui capítulos sobre a administração de usuários e grupos, automação de tarefas e administração de arquivos de registro (log files). • Linux Administration Handbook de Evi Nemeth, Garth Snyder e Trent R. Hein; Prentice Hall — Provém uma boa seção sobre as normas e o lado político da administração de sistemas, incluindo diversas discussões hipotéticas sobre ética. • Linux System Administration: A User’s Guide de Marcel Gagne; Addison Wesley Professional — Contém um capítulo sobre a automação de diversas tarefas. • Solaris System Management de John Philcox; New Riders Publishing — Apesar de não ser escrito especificamente para o Red Hat Enterprise Linux (nem mesmo para o Linux em geral) e usar o termo "gerente de sistemas" ao invés de "administrador de sistemas", este livro traz uma visão geral de 70 páginas sobre as diversas funções exercidas pelo administrador de sistemas numa empresa. Capítulo 2. Monitoramento de Recursos Como mencionado anteriormente, grande parte dos administradores de sistemas conta com os recursos e seu uso eficiente. Ao balancear vários recursos através dos indivíduos e programas que os utilizam, você desperdiça menos dinheiro e deixa seus usuários contentes. No entanto, isto traz duas questões: O que são recursos? e: Como é possível saber quais recursos são utilizados (e o quanto deles é utilizado)? O propósito desse capítulo é capacitá-lo a responder estas questões ajudando-o a apender mais sobre os recursos e seu monitoramento. 2.1. Conceitos Básicos Antes de monitorar os recursos, você deve saber quais os recursos existentes para monitorar. Todos os sistemas têm os seguintes recursos disponíveis: • Energia da CPU • Largura de banda (bandwidth) • Memória • Armazenamento Estes recursos são cobertos em mais detalhes nos capítulos seguintes. No entanto, tudo o que você precisa ter em mente por enquanto é que estes recursos têm um impacto direto no desempenho do sistema e, consequentemente, na produtividade e bem-estar de seus usuários. Simplisticamente, o monitoramento de recursos é nada mais que a obtenção de informações sobre a utilização de um ou mais recursos do sistema. Entretanto, raramente é tão simples. Primeiramente, deve-se considerar os recursos a serem monitorados. Então, é necessário examinar cada sistema a ser monitorado, prestando atenção especial à situação de cada um deles. Os sistemas que você monitorará estão em uma destas duas categorias: • No momento, o sistema está tendo problemas de desempenho parte do tempo e você deseja melhorar seu desempenho. • O sistema está OK no momento e você deseja que continue assim. A primeira categoria significa que você deve monitorar os recursos sob a perspectiva de desempenho do sistema, enquanto na segunda você deve monitorar os recursos do sistema sob a perspectiva do planejamento de capacidades. Como cada perspectiva tem seus próprios requerimentos únicos, as seções seguintes exploram cada categoria em maior profundidade. 14 Capítulo 2. Monitoramento de Recursos 2.2. Monitoramento do Desempenho do Sistema Conforme mencionado anteriormente, o monitoramento do desempenho do sistema é normalmente feito em resposta a um problema de desempenho. Ou o sistema está muito lento ou os programas (e, às vezes, o sistema todo) não rodam de jeito nenhum. Em ambos os casos, o monitoramento do desempenho é normalmente feito como o primeiro e último passos de um processo de três etapas: 1. Monitorar para identificar a natureza e escopo da redução de recursos que causam os problemas de desempenho 2. Os dados obtidos através do monitoramento são analisados e é tomada uma sequência de ações (normalmente, o ajuste de desempenho e/ou a aquisição de hardware adicional) para resolver o problema 3. Monitorar para garantir que o problema de desempenho foi resolvido Por causa disso, o montoramento do desempenho tende ter uma duração relativamente pequena e um escopo mais detalhado. Nota O monitoramento do desempenho do sistema frequentemente é um processo repetitivo, com estes passos sendo repetidos diversas vezes a fim de atingir o melhor desepenho possível do sistema. A principal razão disso é que os recursos do sistema e sua utilização tendem ser altamente relacionados, ou seja, a eliminação do gargalo de um recurso frequentemente revela outro. 2.3. Monitorando a Capacidade do Sistema O monitoramento da capacidade do sistema é parte de um programa intermitente de planejamento da capacidade. Este planejamento usa o monitoramento de recursos a longo prazo para determinar as taxas de mudança na utilização dos recursos do sistema. Uma vez conhecidas estas taxas de mudança, é possível conduzir um planejamento mais preciso a longo prazo em relação à compra de recursos adicionais. O monitoramento da capacidade com o propósito de planejamento é diferente do monitoramento do desempenho de duas maneiras: • O monitoramento é feito quase continuamente • O monitoramento geralmente não é tão detalhado A razão destas diferenças baseia-se nos objetivos de um programa de planejamento da capacidade. O planejamento da capacidade requer um ponto de vista "macro"; o uso anômalo ou de curto prazo dos recursos tem pouca importância. Ao invés, os dados são coletados ao longo de um período, possibilitando classificar a utilização dos recursos em termos de alterações da carga de trabalho. Em ambientes mais restritos (onde somente roda uma aplicação, por exemplo), é possível modelar o impacto da aplicação nos recursos do sistema. Isto pode ser feito com precisão suficiente para poder determinar, por exemplo, o impacto da adição de cinco funcionários de atendimento ao cliente rodando a aplicação de CRM durante o período mais intenso (ocupado) do dia. Capítulo 2. Monitoramento de Recursos 15 2.4. O Que Monitorar? Conforme dito antes, os recursos presentes em todos os sistemas são energia da CPU, largura de banda, memória e armazenamento. À primeira vista, pode parecer que o monitoramento consistiria apenas da avaliação destes quatro fatores distintos. Infelizmente, não é tão simples. Por exemplo: considere um drive de disco. Quais as coisas que você gostaria de saber sobre seu desempenho? • Quanto há de espaço livre? • Quantas operações I/O por segundo executa em média? • Quanto tempo leva para completar cada operação I/O em média? • Quantas destas operações I/O são acessos (reads)? Quantas são gravações (writes)? • Qual a quantidade média de dados acessados/gravados em cada I/O? Há outras maneiras de estudar o desempenho do drive de disco; estes pontos apenas abrangem a superfície. O conceito principal é ter em mente que há muitos tipos diferentes de dados para cada recurso. As seções seguintes exploram os tipos de utilização das informações úteis para cada tipo de recurso principal. 2.4.1. Monitorando a Energia da CPU Na sua forma mais simples, monitorar a energia da CPU consiste em determinar se a utilização da CPU atinge, em algum momento, 100%. Se a utilização da CPU traz algo abaixo de 100%, não importa o que o sistema está fazendo, há energia de processamento disponível para mais carga de trabalho. Entretanto, é raro um sistema que não atinge 100% de utilização da CPU em pelo menos parte do tempo. Neste ponto é importante examinar os dados de utilização mais detalhadamente. Ao fazer isso, é possível começar a determinar onde a maioria da sua energia de processamento está sendo consumida. Aqui estão algumas das estatísticas mais comuns de utilização da CPU: Usuários Versus Sistema A porcentagem de tempo gasto com o processamento a nível de usuário versus o processamento a nível do sistema pode indicar se a carga de um sistema deve-se à execução de aplicações ou à sobrecarga do sistema operacional. As altas porcentagens a nível de usuário tendem a ser boas (assumindo que os usuários tenham desempenho satisfatório), enquanto as altas porcentagens a nível de sistema tendem a indicar problemas que requerem uma investigação mais profunda. Mudanças de Contexto Uma mudança de contexto ocorre quando a CPU para de rodar um processo e começa a rodar outro. Como cada mudança de contexto requer que o sistema operacional tome o controle da CPU, mudanças de contexto excessivas e altos níveis de consumo da CPU a nível de sistema tendem a caminhar juntos. Interrupções Como o nome implica, as interrupções são situações nas quais o processo desempenhado pela CPU é alterado abruptamente. As interrupções geralmente ocorrem devido a atividade do hardware (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 devem ser resolvidas a nível do sistema, altas taxas de interrupção levam a um consumo maior da CPU a nível do sistema. 16 Capítulo 2. Monitoramento de Recursos Processos Executáveis (runnable) Um processo pode estar em estados diferentes, como: • Aguardando a finalização de uma operação I/O • Aguardando o sub-sistema de administração da memória resolver uma falha de página Nestes casos, o processo não precisa da CPU. No entanto, o processo sofre mudanças eventualmente e torna-se executável. Como o nome implica, um processo executável é capaz de executar o trabalho assim que estiver agendado para receber tempo da CPU. Entretanto, se mais de um processo for executável numa determinada hora, todos os processos executáveis menos um1 devem esperar pela sua vez na CPU. Ao monitorar o número de processos executáveis, é possível determinar o quanto seu sistema depende da CPU. Outras medidas de desempenho que refletem um impacto na utilização da CPU tendem a incluir serviços diferentes que o sistema operacional oferece aos processos. Podem incluir estatísticas da administração da memória, do processamento I/O e assim por diante. Estas estatísticas também revelam que, quando o desempenho do sistema é monitorado, não há limites entre as estatísiticas diferentes. Em outras palavras: as estatísticas de utilização da CPU podem terminar apontando para um problema no sub-sistema I/O ou as estatísticas de utilização da memória podem revelar uma falha no design da aplicação. Consequentemente, ao monitorar o desempenho do sistema, não é possível examinar nenhuma estatística isoladamente; só é possível extrair informações significativas ao examinar o quadro geral de quaisquer estatísticas que você coletar. 2.4.2. Monitorando a Largura de Banda Monitorar a largura de banda é mais difícil que monitorar outros recursos aqui descritos. A razão disso deve-se ao fato que as estatísticas de desempenho geralmente baseiam-se nos dispositivos, enquanto a maioria dos lugares onde a largura de banda é importante são os canais que conectam dispositivos. Nestes casos, onde mais de um dispositivo compartilha um canal em comum, você deve observar estatísticas razoáveis para cada dispositivo, mas a carga agregada imposta por estes dispositivos no canal seria bem maior. Um outro desafio ao monitorar a largura de banda: pode haver circunstâncias nas quais as estatísticas dos dispositivos podem não estar disponíveis. Isto é particularmente verdadeiro para canais de expansão do sistema e caminhos de dados2. No entanto, mesmo que as estatísticas relacionadas à largura de banda não estejam 100% corretas, frequentemente há informações necessárias para possibilitar algum nível de análise, particularmente ao considerar as estatísticas relacionadas. Estas são algumas das estatísticas mais comuns relacionadas à largura de banda: Bytes recebidos/enviados As estatísticas da interface de rede oferecem um indicador da utilização da largura de banda de um dos canais mais visíveis — a rede. Contagens e taxas da interface Estas estatísticas relacionadas à rede podem indicar colisões excessivas, transmitir e receber erros, entre outros. Através do uso destas estatísticas (particularmente, se houver estatísticas para mais de um sistema em sua rede), é possível solucionar um mínimo de problemas de rede, mesmo antes de usar as ferramentas de diagnóstico de rede mais comuns. 1. 2. Assumindo um sistema com processador único. Mais informações sobre canais, caminhos de dados e largura de banda podem ser encontradas no Capítulo 3. Capítulo 2. Monitoramento de Recursos 17 Transferências por Segundo Normalmente coletada para dispositivos I/O de bloco, como drives de fita de alto desempenho e drives de disco, esta estatística é uma boa maneira de determinar se a largura de banda de um determinado dispositivo atingiu seu limite. Devido sua natureza eletromecânica, os drives de fita e de disco podem executar somente um determinado número de operações I/O a cada segundo; seu desempenho decai rapidamente quando esse limite é atingido. 2.4.3. Monitorando a Memória Se existe alguma área onde podemos encontrar uma riqueza de estatísticas de desempenho, essa área é o monitoramento da utilização da memória. Devido à complexidade inerente dos sistemas operacionais com memória virtual paginada por demanda, as estatísticas de utilização da memória são muitas e variadas. É aqui que reside a maioria do trabalho do administrador de sistemas com a administração dos recursos. Os dados seguintes representam uma visão geral superficial das estatísticas comumente encontradas sobre a administração da memória: Páginas Dentro/Páginas Fora (Page Ins/Page Outs) Estas estatísticas possibilitam medir o fluxo de páginas da memória do sistema para os dispositivos de armazenamento em massa anexos (geralmente drives de disco). Taxas altas de ambas estatísticas podem significar que o sistema tem pouca memória física e está com thrashing, ou seja, gastando mais recursos do sistema para mover páginas para dentro e para fora da memória que para rodar aplicações. Páginas Ativas/Inativas (Active/Inactive Pages) Estes dados mostram como são usadas as páginas altamente residentes na memória. Uma falta de páginas inativas pode indicar a falta de memória física. Páginas Livres, Compartilhadas, no Buffer e no Cache (Free, Shared, Buffered, and Cached Pages) Estes dados oferecem detalhes adicionais sobre as estatísticas de páginas inativas/ativas mais simplistas. Ao usar estas estatísticas, é possível determinar a mistura geral da utilização da memória. Swap Dentro/Swap Fora (Swap Ins/Swap Outs) Estes dados mostram o comportamento da memória swap do sistema. Altas taxas podem indicar a falta de memória física. O bom monitoramento da utilização da memória requer um bom entendimento de como funcionam os sistemas operacionais com memória virtual paginada por demanda. Apesar do assunto isoladamente poder ocupar um livro inteiro, seus conceitos básicos estão abordados no Capítulo 4. Este capítulo, juntamente ao tempo gasto com o monitoramento de um sistema real, oferece a base para aprender mais sobre o assunto. 2.4.4. Monitorando o Armazenamento O monitoramento do armazenamento geralmente ocorre em dois níveis diferentes: • Monitoramento de espaço suficiente em disco • Monitoramento de problemas de desempenho relacionados ao armazenamento A razão disto: é possível ter problemas sérios em uma área e nenhum problema em outra. Por exemplo: é possível fazer com que um drive de disco esgote seu espaço sem causar nenhum tipo de problema 18 Capítulo 2. Monitoramento de Recursos relacionado ao desempenho. Da mesma forma, é possível ter um drive de disco com 99% de espaço livre com seus limites de desempemnho sendo forçados. Entretanto, é mais provável que o sistema mediano experimente vários graus de falta de recursos em ambas áreas. Por causa disso, também é provável que — até certo ponto — os problemas de uma área impactem noutra área. Frequentemente, esse tipo de interação toma a forma de desempenho I/O descendente, conforme o drive de disco se aproxima de 0% de espaço livre; não obstante, nos casos de cargas I/O extremas, pode ser possível diminuir I/O para um nível no qual as aplicações não mais rodam apropriadamente. Em qualquer caso, as estatísticas a seguir são úteis para monitorar o armazenamento: Espaço Livre (Free Space) Espaço livre é provavelmente o recurso que todos os administradores de sistemas monitoram de perto; seria raro um administrador de sistemas que nunca verifica o espaço livre (ou que não tenha uma maneira automatizada de fazê-lo). Estatísticas Relaciondas ao Sistema de Arquivo Estas estatísticas (como número de arquivos/diretórios, tamanho médio de arquivo, etc) oferecem detalhes adicionais sobre a simples porcentagem de espaço livre. Como tais, estas estatísticas possibilitam aos administradores configurar o sistema para o melhor desempenho, já que a carga I/O imposta por um sistema de arquivo com muitos arquivos pequenos não é a mesma que àquela imposta por um sistema de arquivo com um único arquivo enorme. Transferências por Segundo Esta estatística é uma boa maneira de determinar se os limites de largura de banda de um determinado dispositivo foram atingidos. Acessos/Gravações por Segundo (Reads/Writes per Second) Uma análise um pouco mais detalhada das transferências por segundo, estas estatísticas permitem ao administrador de sistemas entender melhor a natureza das cargas I/O experimentadas por um dispositivo de armazenamento. Isto pode ser crítico já que algumas tecnologias de armazenamento têm características de desempenho bem diferentes para operações de acesso (read) e para operações de gravação (write). 2.5. Informações Específicas do Red Hat Enterprise Linux O Red Hat Enterprise Linux traz diversas ferramentas de monitoramento dos recursos. Apesar de existir mais ferramentas que as listadas aqui, essas são as mais representativas em termos de funcionalidade: • free • top (e Monitor GNOME do Sistema, uma versão mais gráfica do top) • vmstat • O pacote Sysstat de ferramentas de monitoramento dos recursos • O perfilador do sistema OProfile Vamos examinar cada um mais detalhadamente. Capítulo 2. Monitoramento de Recursos 19 2.5.1. free O comando free apresenta a utilização da memória do sistema. Aqui está um exemplo de seu output: total Mem: 255508 -/+ buffers/cache: Swap: 530136 used 240268 146488 26268 free 15240 109020 503868 shared 0 buffers 7592 cached 86188 A linha Mem: apresenta a utilização da memória física, enquanto a linha Swap: apresenta a utilização do espaço swap do sistema, e a linha -/+ buffers/cache: traz a quantidade de memória física corrente dedicada aos buffers do sistema. Como o free apresenta as informações de utilização da memória uma só vez por default, é útil somente para monitoramento de curto prazo, ou para determinar rapidamente se um problema relativo à memória está ocorrendo no momento. Apesar do free ter a habilidade de apresentar a utilização da memória repetidamente através de sua opção -s, seu output se estende ao longo da tela, dificultando detectar as alterações na utilização da memória. Dica Uma solução melhor que o uso do free -s seria executar o free usando o comando watch. Por exemplo: para trazer a utilização da memória a cada dois segundos (o intervalo default de display do watch), use esse comando: watch free O comando watch submete o comando free a cada dois segundos, limpando a tela e exibindo o novo output na mesma localidade. Isso facilita determinar as alterações na utilização da memória ao longo do tempo, já que o watch cria uma única visualização atualizada sem scrolling. Você pode controlar o intervalo entre as atualizações usando a opção -n e fazer com que quaisquer alterações entre as atualizações sejam destacadas, usando a opção -d, conforme o comando seguinte: watch -n 1 -d free Para mais informações , consulte a página man watch. O comando watch roda continuamente até ser interrompido por [Ctrl]-[C]. O comando watch é algo para ter em mente, pois pode ser útil em diversas situações. 2.5.2. top Enquanto o free apresenta somente informações relativas à memória, o comando top faz um pouco de tudo. A utilização da CPU, as estatísticas de processo, a utilização da memória — o top monitora tudo. Além disso, ao contrário do comando free, o comportamento defalut do top é rodar continuamente; não há necessidade de usar o comando watch. Aqui está uma amostra: 14:06:32 up 4 days, 21:20, 4 users, load average: 0.00, 0.00, 0.00 77 processes: 76 sleeping, 1 running, 0 zombie, 0 stopped CPU states: cpu user nice system irq softirq iowait idle total 19.6% 0.0% 0.0% 0.0% 0.0% 0.0% 180.2% cpu00 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 100.0% cpu01 19.6% 0.0% 0.0% 0.0% 0.0% 0.0% 80.3% Mem: 1028548k av, 716604k used, 311944k free, 0k shrd, 131056k buff 324996k actv, 108692k in_d, 13988k in_c Swap: 1020116k av, 5276k used, 1014840k free 382228k cached 20 Capítulo 2. Monitoramento de Recursos PID 17578 19154 1 2 3 4 5 6 9 7 8 10 11 USER root root root root root root root root root root root root root PRI 15 20 15 RT RT 15 34 35 15 15 15 15 25 NI SIZE RSS SHARE STAT %CPU %MEM 0 13456 13M 9020 S 18.5 1.3 0 1176 1176 892 R 0.9 0.1 0 168 160 108 S 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0 19 0 0 0 SWN 0.0 0.0 19 0 0 0 SWN 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0 TIME CPU COMMAND 26:35 1 rhn-applet-gu 0:00 1 top 0:09 0 init 0:00 0 migration/0 0:00 1 migration/1 0:00 0 keventd 0:00 0 ksoftirqd/0 0:00 1 ksoftirqd/1 0:07 1 bdflush 1:19 0 kswapd 0:14 1 kscand 0:03 1 kupdated 0:00 0 mdrecoveryd O resultado é dividido em duas seções. A seção superior contém informações relativas ao estado geral do sistema — tempo ligado (uptime), carga média, contagens de processos, estado da CPU e estatísticas de utilização da memória e do espaço swap. A seção inferior apresenta estatísticas no nível do processo. É possível alterar a exibição enquanto o top está rodando. Por exemplo: o top apresenta processos inativos e ativos por default. Para exibir somente os processos ativos, pressione [i]; pressionar novamente retorna ao modo de exibição default. Aviso Apesar do top aparecer como um simples programa de apresentação, este não é o caso. Isso ocorre porque o top usa comandos de caractere simples para executar várias operações. Por exemplo: se você está autenticado como root, é possível alterar a prioridade e até mesmo terminar quaisquer processos de seu sistema. Consequentemente, até que você reveja a tela de ajuda do top (digite [?] para apresentá-la), é mais seguro digitar somente [q] (que sai do comando top). 2.5.2.1. O Monitor GNOME do Sistema — Um top gráfico Se você prefere utilizar interfaces gráficas de usuário, o Monitor GNOME do Sistema pode ser a sua escolha. Como o top, o Monitor GNOME do Sistema apresenta as informações relacionadas ao estado geral do sistema, contagens de processos, utilização da memória e swap e também estatísticas a nível de processo. No entanto, o Monitor GNOME do Sistema vai um passo além, incluindo também representações gráficas da utilização da CPU, da memória e de swap, juntamente a uma listagem da utilização do espaço em disco em forma de tabela. Veja um exemplo da Listagem de Processos do Monitor GNOME do Sistema na Figura 2-1. Capítulo 2. Monitoramento de Recursos 21 Figura 2-1. A Apresentação da Listagem de Processos do Monitor GNOME do Sistema É possível apresentar informações adicionais para processos específicos; primeiro clique no processo desejado e então clique no botão Mais Informações (More Info). Para apresentar as estatísticas da CPU, memória e uso do disco, clique na aba Monitor do Sistema (System Monitor). 2.5.3. vmstat Para um entendimento mais conciso do desempenho do sistema, tente o vmstat. Com o vmstat, é possível obter uma visão geral dos processos, memória, swap, I/O, sistema e das atividades da CPU numa linha de números: procs r b 0 0 memory swpd free buff cache 5276 315000 130744 380184 si 1 swap so 1 bi 2 io bo 24 in 14 system cpu cs us sy id wa 50 1 1 47 0 22 Capítulo 2. Monitoramento de Recursos A primeira linha divide os campos em seis categorias, incluindo estatísticas do processo, da memória, swap, I/O, do sistema e da CPU. A segunda linha identifica o conteúdo de cada campo, facilitando a busca de dados para estatísticas específicas. Os campos relativos ao processo são: • r — O número de processos executáveis (runnable processes) aguardando para acessar a CPU • b — O número de processos num estado de dormência contínua Os campos relativos à memória são: • swpd — A quantidade de memória virtual usada • free — A quantidade de memória livre • buff — A quantidade de memória usada para buffers • cache — A quantidade de memória usada para cache Os campos relativos à swap são: • si — A quantidade de memória enviada para swap pelo disco • so — A quantidade de memória retirada de swap para o disco Os campos relativos a I/O são: • bi — Blocos enviados a um dispositivo de bloco • bo — Blocos recebidos de um dispositivo de bloco Os campos relativos ao sistema são: • in — O número de interrupções por segundo • cs — O número de mudanças de contexto por segundo Os campos relativos à CPU são: • us — A porcentagem de tempo em que a CPU rodou código a nível do usuário • sy — A porcentagem de tempo em que a CPU rodou código a nível do sistema • id — A porcentagem de tempo em que a CPU estava osciosa • wa — espera das I/O Quando o vmstat é executado sem nenhuma opção, apresenta somente uma linha. Essa linha contém médias, calculadas desde a hora em que o sistema foi inicializado pela última vez. Entretanto, a maioria dos administradores de sistema não confia nas informações dessa linha, já que varia o tempo ao longo do qual foram coletadas. Ao invés disso, a maioria dos administradores aproveita a habilidade do vmstat em apresentar repetidamente os dados de utilização dos recursos em intervalos determinados. Por exemplo: o comando vmstat 1 apresenta uma nova linha com informações de utilização a cada segundo, enquanto o comando vmstat 1 10 apresenta uma nova linha por segundo, mas apenas nos próximos dez segundos. Nas mãos de um administrador experiente, o vmstat pode ser usado para determinar rapidamente as questões de desempenho e utilização de recursos. Mas, para ter mais conhecimento destas questões, é necessário usar um tipo diferente de ferramenta — uma ferramenta capaz de coletar e analisar dados mais profundos. Capítulo 2. Monitoramento de Recursos 23 2.5.4. O Pacote Sysstat de Ferramentas de Monitoramento dos Recursos Enquanto as ferramentas anteriores são úteis para obter mais conhecimento sobre o desempenho do sistema ao longo de períodos de tempo curtos, têm pouco uso além de prover uma rápida visualização da utilização dos recursos. Além disso, há aspectos do desempenho do sistema que não podem ser facilmente monintorados com ferramentas simplistas como estas. Sendo assim, é necessário uma ferramenta mais sofisticada. Sysstat é essa ferramenta. Sysstat contém as seguintes ferramentas relacionadas à obtenção de estatísticas de I/O e CPU: iostat Apresenta uma visão geral da utilização da CPU, junto às estatísticas de I/O de um ou mais drives de disco. mpstat Apresenta estatísticas mais profundas da CPU. Sysstat também contém ferramentas que coletam dados de utilização dos recursos do sistema e criam relatórios diários baseados nestes dados. Estas ferramentas são: sadc Conhecido como o coletor de dados de atividade do sistema, o sadc coleta informações da utilização dos recursos do sistema e as grava num arquivo. sar Os relatórios do sar são criados a partir de arquivos do sadc, e podem ser gerados interativamente ou gravados num arquivo para uma análise mais intensa. As seções seguintes exploram cada uma destas ferramentas mais detalhadamente. 2.5.4.1. O comando iostat O comando iostat, em sua forma mais básica, oferece uma visão geral das estatísticas da CPU e operações I/O do disco: Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) avg-cpu: Device: dev3-0 %user 6.11 %nice 2.56 tps 1.68 %sys 2.15 07/11/2003 %idle 89.18 Blk_read/s 15.69 Blk_wrtn/s 22.42 Blk_read 31175836 Blk_wrtn 44543290 Abaixo da primeira linha (que contém a versão do kernel do sistema e o nome da máquina, junto à data corrente), o iostat apresenta uma visão geral da utilização média da CPU do sistema desde a última inicialização. O relatório de utilização da CPU inclui as seguintes porcentagens: • Porcentagem do tempo gasto no modo usuário (rodando aplicações, etc) • Porcentagem do tempo gasto no modo usuário (para processos que alteraram suas prioridades de agendamento usando o nice(2)) • Porcentagem do tempo gasto no modo kernel • Porcentagem do tempo inativo 24 Capítulo 2. Monitoramento de Recursos O relatório de utilização do dispositivo está abaixo do relatório de utilização da CPU. Este relatório contém uma linha para cada dispositivo de disco ativo no sistema e inclui as seguintes informações: • A especificação começando por zero. • do dispositivo é onde dev maior-número -número-sequencial, é o maior número do dispositivo3 e número-sequencial apresentada como maior-número é um número sequencial O número de transferências (ou operações I/O) por segundo. • O número de blocos de 512 bytes acessados por segundo. • O número de blocos de 512 bytes gravados por segundo. • O número total de blocos de 512 bytes acessados. • O número total de blocos de 512 bytes gravados. Esta é apneas uma amostra das informações que podem ser obtidas usando o iostat. Para mais informações, consulte a página man iostat(1). 2.5.4.2. O comando mpstat À primeira vista, o comando mpstat não parece ser diferente do relatório de utilização da CPU produzido pelo iostat: Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 07:09:26 PM 07:09:26 PM CPU all %user 6.40 %nice %system 5.84 3.29 %idle 84.47 07/11/2003 intr/s 542.47 Além da coluna adicional com as interrupções por segundo resolvidas pela CPU, não há diferença real. No entanto, a situação muda se a opção -P ALL do mpstat for usada: Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 07:13:03 07:13:03 07:13:03 07:13:03 PM PM PM PM CPU all 0 1 %user 6.40 6.36 6.43 %nice %system 5.84 3.29 5.80 3.29 5.87 3.29 %idle 84.47 84.54 84.40 07/11/2003 intr/s 542.47 542.47 542.47 Em sistemas com multi-processadores, o mpstat permite exibir a utilização de cada CPU separadamente, possibilitando determinar o quão efetivamente cada CPU é usada. 2.5.4.3. O comando sadc Conforme mencionado anteriormente, o comando sadc coleta dados de utilização do sistema e os grava num arquivo para análise posterior. Por default, os dados são gravados em arquivos no diretório /var/log/sa/. Os arquivos são nomeados como sa dd , onde dd é a data do dia corrente em dois dígitos. O sadc é normalmente executado pelo script do sa1. Esse script é periodicamente invocado pelo cron através do arquivo sysstat, localizado em /etc/cron.d/. O script sa1 invoca o sadc para 3. Os números maiores do dispositivos podem ser obtidos usando ls -l para exibir o arquivo do dispositivo desejado em /dev/. O maior número aparece após a especificação do grupo do dispositivo. Capítulo 2. Monitoramento de Recursos 25 um único intervalo de medição de um segundo. Por default, o cron roda o sa1 a cada 10 minutos, adicionando os dados coletados durante cada intervalo ao arquivo /var/log/sa/sa dd corrente. 2.5.4.4. O comando sar O comando sar produz relatórios de utilização do sistema baseados nos dados coletados pelo sadc. Conforme configurado no Red Hat Enterprise Linux, o sar é automaticamente executado para processar os arquivos automaticamente coletados pelo sadc. Os arquivos de relatórios são gravados em /var/log/sa/ e são nomeados como sar dd , onde dd é a representação de dois dígitos da data do dia anterior. O sar é normalmente executado pelo script do sa2. Esse script é periodicamente invocado pelo cron através do arquivo sysstat, localizado em /etc/cron.d/. Por default, o cron roda o sa2 uma vez por dia, às 23:53, permitindo que produza um relatório com os dados do dia todo. 2.5.4.4.1. Acessando Relatórios do sar O formato de um relatório do sar produzido pela configuração default do Red Hat Enterprise Linux consiste de seções múltiplas, e cada seção contém um tipo de dado específico, ordenado pela hora do dia em que o dado foi coletado. Como o sadc é configurado para efetuar um intervalo de medição de um segundo a cada dez minutos, o relatório default do sar contém dados em blocos de dez minutos, de 00:00 a 23:504. Cada seção do relatório inicia com um cabeçalho descrevendo os dados contidos na seção. O cabeçalho é repetido em intervalos regulares ao longo da seção, facilitando interpretar os dados enquanto navegamos no relatório. Cada seção termina com uma linha contendo a média dos dados reportados na seção. Veja um exemplo de seção do relatório do sar, com os dados de 00:30 a 23:40 removidos para economizar espaço: 00:00:01 00:10:00 00:20:01 ... 23:50:01 Average: CPU all all %user 6.39 1.61 %nice 1.96 3.16 %system 0.66 1.09 %idle 90.98 94.14 all all 44.07 5.80 0.02 4.99 0.77 2.87 55.14 86.34 Nesta seção são apresentadas as informações de utilização da CPU. Estas são bem similares às informações apresentadas pelo iostat. Outras seções talvez tenham mais de uma linha de dados por vez, conforme exibido nesta seção gerada a partir dos dados de utilização da CPU, coletados num sistema de processador duplo: 00:00:01 00:10:00 00:10:00 00:20:01 00:20:01 ... 23:50:01 23:50:01 Average: Average: 4. CPU 0 1 0 1 %user 4.19 8.59 1.87 1.35 %nice 1.75 2.18 3.21 3.12 %system 0.70 0.63 1.14 1.04 %idle 93.37 88.60 93.78 94.49 0 1 0 1 42.84 45.29 6.00 5.61 0.03 0.01 5.01 4.97 0.80 0.74 2.74 2.99 56.33 53.95 86.25 86.43 Devido à dinâmica das cargas de sistema, a hora real na qual os dados foram coletados pode variar em um segundo ou dois. 26 Capítulo 2. Monitoramento de Recursos Há um total de dezessete seções diferentes presentes nos relatórios gerados pela configuração default do sar no Red Hat Enterprise Linux. Algumas destas seções são abordadas nos próximos capítulos. Para mais informações sobre os dados contidos em cada seção, consulte a página man sar(1). 2.5.5. OProfile O perfilador do sistema OProfile é uma ferramenta de monitoramento de baixa sobrecarga. O OProfile utiliza o hardware de monitoramento do desempenho do processador 5 para determinar a natureza de problemas relativos ao desempenho. O hardware de monitoramento do desempenho é parte do próprio processador. Tem a forma de um contador especial, aumentando cada vez que um determinado evento (como o processador estar ativo ou os dados desejados não serem enviados ao cache) ocorre. Alguns processadores tem mais de um contador como esse, e permitem a seleção de tipos de eventos diferentes para cada contador. Os contadores podem ser carregados com um valor inicial e produzir uma interrupção sempre que o contador ultrapassar o limite. Ao carregar um contador com valores iniciais diferentes, é possível variar a taxa de produção de interrupções. Dessa maneira, é possível controlar a taxa de controle e, consequentemente, o nível de detalhe obtido através dos dados coletados. Em um extremo, ajustar o contador para gerar uma interrupção de sobrecarga com todos os eventos, oferece dados de desempenho extremamente detalhados (mas com sobrecarga massiva). No outro extremo, ajustar o contador para gerar o menor número de interrupções possível, oferece apenas uma visão genérica do desempenho do sistema (com praticamente nenhuma sobrecarga). O segredo do monitoramento efetivo é a seleção de uma taxa limite suficientemente alta para capturar os dados necessários, mas não tão alta a ponto de sobrecarregar o sistema com a sobrecarga de monitoramento do desempenho. Aviso Você poode configurar o OProfile para produzir sobrecarga suficiente a fim de tornar o sistema inutilizável. Consequentemente, você deve tomar cuidado ao selecionar os valores limite. Por este motivo, o comando opcontrol suporta a opção --list-events, que apresenta os tipos de evento disponíveis para o processador instalado, junto a valores limite mínimos sugeridos para cada evento. É importante ter em mente a dificuldade de equilíbrio entre a taxa limite e a sobrecarga ao usar o OProfile. 2.5.5.1. Componentes do OProfile O Oprofile consiste dos seguintes componentes: • Software de coleta de dados • Software de análise de dados • Software de interface administrativa O software de coleta de dados consiste do módulo oprofile.o do kernel e do daemon oprofiled. O software de análise de dados inclui os seguintes programas: 5. O OProfile também pode usar um mecanismo de fallback (conhecido como TIMER_INT) para aquelas arquiteturas de sistema que não têm hardware de monitoramento do desempenho. Capítulo 2. Monitoramento de Recursos 27 op_time Exibe o número e porcentagens relativas de amostras obtidas para cada arquivo executável oprofpp Exibe o número e porcentagem relativa obtida pela instrução individual ou pelo output no estilo do gprof. op_to_source Exibe o código fonte comentado e/ou as listagens de código do assembly op_visualise Exibe graficamente os dados coletados Estes programas possibilitam exibir os dados coletados de diversas formas. O software de interface administrativa controla todos os aspectos da coleta de dados, da especificação dos eventos a serem monitorados ao início e parada da própria coleta. Isso é feito usando o comando opcontrol. 2.5.5.2. Uma Amostra de Sessão do OProfile Esta amostra exibe uma sessão de monitoramento e análise de dados da configuração inicial à análise de dados final. É apenas uma visão geral introdutória; para mais informações, consulte o Guia de Administração de Sistemas Red Hat Enterprise Linux. Use o opcontrol para configurar o tipo de dados a serem coletados com o seguinte comando: opcontrol \ --vmlinux=/boot/vmlinux-‘uname -r‘ \ --ctr0-event=CPU_CLK_UNHALTED \ --ctr0-count=6000 As opções usadas aqui direcionam o opcontrol para: • Direcionar o OProfile para uma cópia (--vmlinux=/boot/vmlinux-‘uname -r‘) do kernel rodando no momento • Especificar que o contador 0 do processador deve ser usado e que o evento a ser monitorado é o tempo em que a CPU está executando instruções (--ctr0-event=CPU_CLK_UNHALTED) • Especificar que o OProfile deve coletar amostras a cada 6000 vezes que o evento especificado ocorrer (--ctr0-count=6000) Em seguida, verifique se o módulo oprofile do kernel está carregado usando o comando lsmod: Module oprofile ... Size 75616 Used by 1 Not tainted Confirme se o sistema de arquivo do OProfile (localizado em /dev/oprofile/) está montado com o comando ls /dev/oprofile/: 0 1 buffer buffer_size buffer_watershed cpu_buffer_size cpu_type dump enable kernel_only stats (O número exato de arquivos varia de acordo com o tipo de processador.) 28 Capítulo 2. Monitoramento de Recursos Neste ponto, o arquivo /root/.oprofile/daemonrc contém os ajustes necessários para o software de coleta de dados: CTR_EVENT[0]=CPU_CLK_UNHALTED CTR_COUNT[0]=6000 CTR_KERNEL[0]=1 CTR_USER[0]=1 CTR_UM[0]=0 CTR_EVENT_VAL[0]=121 CTR_EVENT[1]= CTR_COUNT[1]= CTR_KERNEL[1]=1 CTR_USER[1]=1 CTR_UM[1]=0 CTR_EVENT_VAL[1]= one_enabled=1 SEPARATE_LIB_SAMPLES=0 SEPARATE_KERNEL_SAMPLES=0 VMLINUX=/boot/vmlinux-2.4.21-1.1931.2.349.2.2.entsmp Em seguida, use opcontrol para iniciar a coleta de dados com o comando opcontrol --start: Using log file /var/lib/oprofile/oprofiled.log Daemon started. Profiler running. Verifque se o daemon oprofiled está rodando com o comando ps x | grep -i oprofiled: 32019 ? 32021 pts/0 S S 0:00 /usr/bin/oprofiled --separate-lib-samples=0 ... 0:00 grep -i oprofiled (A linha de comando oprofiled apresentada pelo ps é bem mais longa; no entanto, foi truncada aqui por motivos de 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 vantagem de não precisar parar a coleta de dados antes de executar a análise de dados. No entanto, você deve esperar que pelo menos um conjunto de amostras seja gravado no disco, ou use o comando opcontrol --dump para forçar as amostras no disco. No exemplo a seguir, o op_time é usado para exibir (em ordem inversa — do maior número de amostras ao menor) as amostras que foram coletadas. 3321080 761776 368933 293570 205231 167575 123095 105677 48.8021 11.1940 5.4213 4.3139 3.0158 2.4625 1.8088 1.5529 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 /boot/vmlinux-2.4.21-1.1931.2.349.2.2.entsmp /usr/bin/oprofiled /lib/tls/libc-2.3.2.so /usr/lib/libgobject-2.0.so.0.200.2 /usr/lib/libgdk-x11-2.0.so.0.200.2 /usr/lib/libglib-2.0.so.0.200.2 /lib/libcrypto.so.0.9.7a /usr/X11R6/bin/XFree86 Capítulo 2. Monitoramento de Recursos 29 ... Usar less é uma boa idéia ao produzir um relatório interativamente, já que este pode ter centenas de linhas. O exemplo ilustrado aqui foi truncado por este motivo. O formato desse relatório específico consiste na produção de uma linha para cada arquivo executável dos quais as amostras foram retiradas. Cada linha segue este formato: sample-count Onde: sample-count • • • • sample-percent unused-field executable-name representa o número de amostras coletadas sample-percent cutável específico campo-não-usado representa a porcentagem de todas as amostras coletadas para esse exeé um campo que não está usado representa o nome do arquivo contendo código executável para o qual as amostras foram coletadas. executable-name Esse relatório (produzido num sistema inativo na maior parte do tempo) mostra que quase metade das amostras foram coletadas enquanto a CPU estava rodando código dentro do próprio kernel. Em seguida, na linha, está o dameon de coleta de dados do OProfile, seguido por diversas bibliotecas e do servidor do Sistema X Window, o XFree86. Vale notar que, para o sistema rodar essa seção de amostra, o valor de 6000 usado no contador representa o valor mínimo recomendado pelo opcontrol --list-events. Isso significa que — pelo menos para este sistema em particular — a sobrecarga do OProfile no seu ápice consome aproximadamente 11% da CPU. 2.6. Recursos Adicionais Esta seção inclui diversas fontes que podem ser usadas para aprender mais sobre o monitoramento de recursos do sistema e suas especificidades no Red Hat Enterprise Linux. 2.6.1. Documentação Instalada Os seguintes recursos são instalados no decorrer de uma instalação típica do Red Hat Enterprise Linux. • Página man free(1) — Aprenda a exibir as estatísticas de memória livre e usada. • Página man top(1) — Aprenda a exibir as estatísticas no nível de processo e de utilização da CPU. • Página man watch(1) — Aprenda a executar periodicamente o programa especificado pelo usuário, exibindo output na tela inteira. • Entrada Help no menu do Monitor GNOME do Sistema — Aprenda a exibir graficamente as estatísticas de processos, utilização da CPU, memória e de espaço em disco. • Página man vmstat(8) — Aprenda a exibir uma visão geral concisa dos processos, memória, swap, I/O, sistema e utilização da CPU. • Página man iostat(1) — Aprenda a exibir as estatísticas da CPU e I/O. • Página man mpstat(1) — Aprenda a exibir as estatísticas das CPUs separadamente em sistemas multi-processadores. • Página man sadc(8) — Aprenda a coletar dados de utilização do sistema. • Página man sa1(8) — Aprenda sobre um script que roda o sadc periodicamente. 30 Capítulo 2. Monitoramento de Recursos • Página man sar(1) — Aprenda como produzir relatórios de utilização dos recursos do sistema. • Página man sa2(8) — Aprenda a produzir arquivos com relatórios diários de utilização dos recursos do sistema. • Página man nice(1) — Aprenda como alterar a prioridade de agendamento do processo. • Página man oprofile(1) — Aprenda a traçar o perfil do desempenho do sistema. • Página man op_visualise(1) — Aprenda a exibir graficamente os dados do OProfile. 2.6.2. Sites Úteis • http://people.redhat.com/alikins/system_tuning.html — Informações de Ajuste do Sistema para Servidores Linux. Uma tática conscienciosa para o ajuste do desempenho e monitoramento de recursos em servidores. • http://www.linuxjournal.com/article.php?sid=2396 — Ferramentas de Monitoramento do Desempenho para Linux. Mais direcionada ao administrador interessado em elaborar uma solução gráfica de desempenho personalizada. Como foi escrita há muitos anos, alguns de seus detalhes talvez estejam obsoletos, mas o conceito e execução gerais ainda funcionam. • http://oprofile.sourceforge.net/ — O site do projeto OProfile. Inclui recursos valiosos do OProfile, incluindo links para listas de discussão e para o canal IRC do #oprofile. 2.6.3. Livros Relacionados Os livros seguintes abordam diversas questões relativas ao monitoramento de recursos e são boas fontes para administradores de sistemas Red Hat Enterprise Linux: • O Guia de Administração de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. — Inclui informaçõ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 — Aproximadamente, 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 diretamente ligado à habilidade do computador em mover e processar dados. Sendo assim, suas funções são frequentemente relacionadas. 3.1. Largura de Banda Basicamente, largura de banda é a capacidade de transferência de dados — em outras palavras, a quantidade de dados que pode ser movida de um ponto a outro num determinado período de tempo. Ter comunicação ponto-a-ponto implica em duas coisas: • Um conjunto de condutores elétricos usado para possiblitar a comunicação de nível baixo • Um protocolo para facilitar a comunicação de dados eficiente e confiável Há dois tipos de componentes de sistema que atendem estes requisitos: • Canais (buses) • Centrais de Dados (Datapaths) As seções a seguir exploram cada um em detalhes. 3.1.1. Canais (buses) Conforme explanado anteriormente, os canais possibilitam a comunicação ponto-a-ponto e utilizam alguma espécie de protocolo para garantir que toda a comunicação ocorra de forma controlada. No entanto, os canais têm outras características distintas: • Características elétricas padronizadas (tais como número de condutores, níveis de voltagem, velocidades 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 diferentes componentes do sistema. Em muitos casos, os canais (buses) permitem interconectar hardware produzido por diversos fabricantes; sem a padronização, isto não seria possível. No entanto, mesmo nas situações onde um canal é de propriedade de um fabricante, a padronização possibilita que este fabricante implemente outros componentes facilmente, usando uma interface comum — o próprio canal. 32 Capítulo 3. Largura de Banda e Poder de Processamento 3.1.1.1. Exemplos de Canais Não importa o local do sistema em questão; sempre há canais. Aqui estão alguns dos canais mais comuns: • Canais de armazenamento em massa (ATA e SCSI) • Redes1 (Ethernet e Token Ring) • Canais de memória (PC133 e Rambus®) • Canais de expansão (PCI, ISA, USB) 3.1.2. Centrais de Dados (Datapaths) As centrais de dados (datapaths) podem ser mais difíceis de identificar, mas, assim como os canais, elas estão em todo lugar. Como os canais, elas também possibilitam a comunicação ponto-a-ponto. Entretanto, ao contrário dos canais, as centrais de dados: • Usam um protocolo mais simples (se houver) • Têm pouca (ou nenhuma) padronização mecânica A razão destas diferenças é que as centrais de dados (datapaths) normalmente fazem parte de algum componente do sistema e não são usadas para facilitar a interconexão improvisada de diferentes componentes. Como tais, as centrais de dados são altamente otimizadas para uma situação específica, na qual a velocidade e o baixo custo têm prioridade sobre a lentidão e flexibilidade de componentes mais caros. 3.1.2.1. Exemplos de Centrais de Dados (Datapaths) Aqui estão algumas centrais de dados típicas: • central de dados da CPU para cache no chip (CPU to on-chip cache datapath) • Processador gráfico para a central de dados da memória de vídeo 3.1.3. Problemas Potenciais Relacionados à Largura de Banda Os problemas relacionados à largura de banda podem ocorrer de duas maneiras (para ambos, canais ou centrais de dados): 1. O canal ou central de dados pode representar um recurso compartilhado. Neste caso, os altos níveis de contenção do canal reduzem a largura de banda efetivamente disponível para todos os dispositivos no canal. Um canal SCSI com diversos drives de disco altamente ativos seria um bom exemplo disto. Os drives de disco altamente ativos saturam o canal SCSI, deixando pouca banda disponível para qualquer outro dispositivo no mesmo canal. O resultado final é que todas as I/O de qualquer dispositivo neste canal são lentas, mesmo que cada dispositivo no canal não esteja sobrecarregado. 2. O canal ou central de dados (datapath) pode ser um recurso dedicado com um número fixo de dispositivos anexos. Neste caso, as características elétricas do canal (e até certo ponto, a natureza do protocolo utilizado) limitam a banda disponível. Este caso geralmente ocorre mais 1. Ao invés de um canal intra-sistema, as redes podem ser encaradas como um canal inter-sistema. Capítulo 3. Largura de Banda e Poder de Processamento 33 frequentemente com centrais de dados que com canais. Esta é uma das razões pelas quais os adaptadores gráficos tendem a operar mais lentamente com definição e resolução de cores mais altas — para cada recarregamento da tela (refresh), há mais dados a serem passados através da central de dados conectando a memória de vídeo e o processador gráfico. 3.1.4. Soluções Potenciais Relacionadas à Largura de Banda (Bandwidth) Felizmente, os problemas relacionados à largura de banda podem ser solucionados. Na realidade, há diversas táticas para isso: • Distribuir a carga • Reduzir a carga • Aumentar a capacidade As seções seguinites exploram cada uma das táticas detalhadamente. 3.1.4.1. Distribuir a Carga A primeira tática é distribuir a atividade do canal de forma mais balanceada. Em outras palavras, se um canal está sobrecarregado e um outro está ocioso, a situação pode ser melhorada ao mover parte da carga para o canal ocioso. Como administrador de sistemas, esta é a primeira tática a considerar, já que há canais adicionais frequentemente presentes em seu sistema. Por exemplo: a maioria dos PCs incluem ao menos dois canais ATA. Se você tiver dois drives de disco ATA e dois canais ATA, por que os dois drives devem estar no mesmo canal? Mesmo se a configuração de seu sistema não incluir canais adicionais, distribuir a carga ainda é uma tática razoável. Os custos de hardware para isso são menores que os custos de uma substituição de um canal existente por hardware de capacidade maior. 3.1.4.2. Reduzir a Carga À primeira vista, reduzir e distribuir a carga parecem ser dois lados da mesma moeda. Afinal de contas, quando alguém distribui a carga, age para a redução da mesma (ao menos no canal sobrecarregado), certo? Apesar deste ponto de vista ser correto, não é o mesmo que reduzir a carga globalmente. A questão aqui é determinar se há algum aspecto da carga do sistema que esteja causando a sobrecarga do canal específico. Por exemplo: uma rede está altamente carregada devido a atividades desnecessárias? Talvez, um pequeno arquivo temporário seja o recipiente de ações de leitura/gravação I/O pesadas. Se este arquivo temporário reside num servidor de arquivos em rede, uma grande quantidade de tráfego de rede pode ser eliminada ao trabalhar com o arquivo localmente. 3.1.4.3. Aumentar a Capacidade A solução óbvia para banda insuficiente é aumentá-la de alguma maneira. No entanto, esta é uma alterantiva cara. Considere, por exemplo, um controlador SCSI e seu canal sobrecarregado. Para aumentar sua banda, o controlador SCSI (e provavelmente todos os dispositivos anexos) precisará ser trocado por hardware mais rápido. Se o controlador SCSI for uma placa separada, este será um processo relativamente simples, mas se o controlador SCSI for parte da placa-mãe do sistema, será mais difícil justificar a economia desta troca. 34 Capítulo 3. Largura de Banda e Poder de Processamento 3.1.5. Em Suma. . . Todos os administradores de sistemas devem estar cientes da largura de banda (bandwidth) e de como a configuração e o uso do sistema impactam na banda disponível. Infelizmente, nem sempre é aparente o que é um problema relacionado à largura de banda e o que não é. Às vezes, o problema não é o canal, mas um dos componentes anexos a este. Por exemplo: considere um adaptador SCSI conectado a um canal PCI. Se há problemas de desempenho com o disco I/O SCSI, pode ser resultado de um adaptador SCSI com baixo desempenho, mesmo que os canais SCSI e PCI não estejam próximos de suas capacidades de largura de banda. 3.2. Poder de Processamento Frequentemente conhecido como poder da CPU, ciclos da CPU e vários outros nomes, poder de processamento é a habilidade do computador em manipular dados. O poder de processamento varia de acordo com a arquitetura (e velocidade do relógio) da CPU — geralmente, as CPUs com velocidades de relógio maiores que suportam tamanhos de palavra maiores têm maior poder de processamento que as CPUs mais lentas suportando tamanhos de palavra menores. 3.2.1. Fatos Sobre o Poder de Processamento Aqui estão os dois principais fatos sobre o poder de processamento que você deve ter em mente: • O poder de processamento é fixo • O poder de processamento não pode ser armazenado O poder de processamento é fixo, de modo que a CPU só pode atingir tal velocidade. Por exemplo: se você precisa adicionar dois números (uma operação que requer apenas uma instrução para a máquina, na maioria das arquiteturas), uma determinada CPU pode fazê-la somente a uma velocidade. Com raras exceções, não é possível diminuir a taxa com a qual a CPU processa as instruções, muito menos aumentá-la. O poder de processamento é fixo também de uma outra maneira: é finito. Ou seja, há limites para os tipos de CPUs que podem ser conectadas a um determinado computador. Alguns sistemas são capazes de suportar uma grande variedade de CPUs com velocidades diferentes, enquanto outros podem não ser atualizáveis (upgradeable)2 . O poder de processamento não pode ser armazenado para uso posterior. Em outras palavras, se uma CPU pode processar 100 milhões de instruções em um segundo, um segundo de tempo ocioso equivalem a 100 milhões de instruções de processamento que foram disperdiçadas. Se examinarmos estes fatos sob uma perspectiva ligeiramente diferente, uma CPU "produz" um fluxo de instruções executadas a uma taxa fixa. E, se a CPU "produz" instruções executadas, isto siginifca que alguma outra coisa deve "consumí-las". A próxima seção define estes consumidores. 3.2.2. Consumidores do Poder de Processamento Há dois consumidores principais do poder de processamento: • Aplicações • O próprio sistema operacional 2. Esta situação acarreta no que é chamado de forklift upgrade, o que significa uma troca completa de um computador. Capítulo 3. Largura de Banda e Poder de Processamento 35 3.2.2.1. Aplicações Os consumidores mais óbvios do poder de processamento são as aplicações e os programas que você quer que o computador rode. De uma planilha de cáculo a um banco de dados, as aplicações são as razões pelas quais você tem um computador. Um sistema com uma CPU pode fazer apenas uma coisa de cada vez. Consequentemente, se a sua aplicação está rodando, todo o resto do sistema não está. Obviamente, o contrário também é verdade — se alguma outra coisa além da sua aplicação está rodando, então sua aplicação não está fazendo nada. Mas, como é que muitas aplicações diferentes aparentemente rodam ao mesmo tempo num sistema operacional moderno? A resposta é que estes são sistemas operacionais multi-tarefas. Em outras palavras, eles criam a ilusão de que muitas coisas diferentes estão acontecendo simultaneamente, apesar de isto não ser possível de fato. O truque é dar a cada processo o tempo rodando na CPU de uma fração de segundo antes de dar a próxima fração de um segundo a um outro processo. Se estas trocas de contexto ocorrerem com bastante frequência, tem-se a ilusão de que múltiplas aplicações estão rodando simultaneamente. Obviamente, as aplicações fazem outras coisas além de manipular dados usando a CPU. Elas podem esperar pelo input do usuário, assim como desempenhar I/O a dispositivos como drives de disco e displays gráficos. Quando estes eventos ocorrem, a aplicação não precisa mais da CPU. Nestas horas, a CPU pode ser usada para outros processos rodando outras aplicações, sem atrasar a aplicação em espera. Além disso, a CPU pode ser usada por um outro consumidor do poder de processamento: o próprio sistema operacional. 3.2.2.2. O Sistema Operacional É difícil determinar o quanto de poder de processamento é consumido pelo sistema operacional porque este utiliza uma mistura de códigos a nível de processo e a nível de sistema para desempenhar seu trabalho. Apesar de ser fácil, por exemplo, usar um monitor de processos para determinar o que os processos rodando um daemon ou serviço estão fazendo, não é fácil determinar o quanto de poder de processamento está sendo consumido pelo processamento relacionado a I/O a nível do sistema (o que normalmente é feito no contexto do processo requisitando a I/O.) Em geral, é possível dividir esta espécie de sobrecarga do sistema em dois tipos: • Manutenção (housekeeping) do sistema operacional • Atividades relacionadas a processos A manutenção do sistema operacional inclui atividades como o agendamento de processos e a administração da memória, enquanto as atividades relacionadas a processos incluem quaisquer processos que suportam o sistema operacional, tais como o registro de eventos do sistema ou nivelamento do cache I/O. 3.2.3. Suprindo a Falta da uma CPU Quando há poder de processamento insuficiente para o trabalho que precisa ser feito, você tem duas opções: • Reduzir a carga • Aumentar a capacidade 36 Capítulo 3. Largura de Banda e Poder de Processamento 3.2.3.1. Reduzir a Carga Reduzir a carga da CPU é algo que pode ser feito sem nenhum custo adicional. Basta identificar os aspectos da carga do sistema sob seu controle que podem ser reduzidos. Há três áreas nas quais focar: • Reduzir a sobrecarga do sistema operacional • Reduzir a sobrecarga das aplicações • Eliminar as aplicações inteiramente 3.2.3.1.1. Reduzir a Sobrecarga do Sistema Operacional Para reduzir a sobrecarga do sistema operacional, é necessário examinar a carga atual do sistema e determinar quais aspectos desta resultam em quantidades desordenadas de sobrecarga. Estas áreas podem incluir: • Reduzir a necessidade do agendamento de processos frequente • Reduzir a quantidade das I/O desempenhadas Não espere milagres; num sistema razoavelmente bem configurado, é improvável notar um grande aumento de desempenho ao tentar reduzir a sobrecarga do sistema operacional. Isto se deve ao fato de que um sistema razoavelmente bem configurado, por definição, resulta numa quantidade mínima de sobrecarga. No entanto, se o seu sistema está rodando com muito pouca RAM, por exemplo, você talvez consiga reduzir a sobrecarga aliviando a falta de RAM. 3.2.3.1.2. Reduzir a Sobrecarga das Aplicações Reduzir a sobrecarga de uma aplicação significa garantir que esta tenha tudo o que precisa para rodar bem. Algumas aplicações apresentam comportamentos bem diferentes sob ambientes diferentes — por exemplo: uma aplicação pode tornar-se altamente integrada ao computador ao processar certos tipos de dados, e com outros dados não. Deve-se manter em mente que você precisa entender sobre as aplicações rodando no seu sistema se pretende que elas rodem da maneira mais eficiente possível. Frequentemente, isto inclui trabalhar com seus usuários, e/ou com os desenvolvedores da sua empresa, para ajudar a descobrir maneiras pelas quais as aplicações podem rodar mais eficientemente. 3.2.3.1.3. Eliminar Aplicações Inteiramente Dependendo da sua empresa, esta tática pode não estar disponível, já que frequentemente não é de responsabilidade do administrador de sistemas ditar quais aplicações devem ou não rodar. Entretanto, se você puder identificar aplicações que são "CPU hogs" conhecidas, pode influenciar os tomadores de decisão a aposentá-las. Executar esta tarefa provavelmente envolverá mais alguém além de você. Os usuários afetados devem certamente fazer parte deste processo; em muitos casos eles talvez tenham o conhecimento e o poder político para efetuar as mudanças no âmbito das aplicações. Dica Tenha em mente que uma aplicação talvez não precise ser eliminada de todos os sistemas de sua empresa. Você pode transferir uma determinada aplicação que requer muito da CPU de um sistema sobrecarregado para outro sistema quase ocioso. Capítulo 3. Largura de Banda e Poder de Processamento 37 3.2.3.2. Aumentar a Capacidade Obviamente, se não for possível reduzir a demanda de poder de processamento, você deve encontrar outras maneiras de aumentá-lo. É necessário dinheiro para fazer isso, mas pode ser feito. 3.2.3.2.1. Atualizando a CPU (upgrade) A tática mais simples é determinar se a CPU do seu sistema pode ser atualizada. O primeiro passo é determinar se a CPU atual pode ser removida. Alguns sistemas (principalmente laptops) têm CPUs soldadas, impossibilitando uma atualização. O resto, no entanto, tem CPUs anexas, o que possibilita as atualizações — pelo menos em tese. Em seguida, você deve pesquisar se existe uma CPU mais rápida para a configuração de seu sistema. Por exemplo: se você tem uma CPU de 1GHz e há uma unidade de 2GHz do mesmo tipo, pode ser possível efetuar a atualização. Finalmente, você deve determinar a velocidade máxima do relógio suportada pelo seu sistema. Continuando o exemplo acima, mesmo se existir uma CPU do tipo apropriado de 2GHz, não será possível trocar a CPU se seu sistema suportar somente processadores de 1GHz ou menos. Se você concluir que não é possível instalar uma CPU mais rápida no seu sistema, suas opções talvez estejam limitadas à troca de placas-mãe ou até mesmo ao forklift upgrade (troca completa do computador) mencionado anteriormente. No entanto, algumas configurações do sistema possibilitam uma tática ligeiramente diferente. Ao invés de trocar a CPU atual, por que não adicionar outra? 3.2.3.2.2. Será que o Multiprocessamento Simétrico (Symmetric Multiprocessing) Serve para Você? O multiprocessamento simétrico (também conhecido como SMP, Symmetric Multiprocessing) possibilita que um sistema de computador tenha mais de uma CPU compartilhando todos os recursos do sistema. Isto significa que, ao contrário do sistema com um processador, um sistema SMP pode ter mais de um processo rodando ao mesmo tempo. À primeira vista, este parece ser um sonho para o administrador de sistemas. Antes de mais nada, o SMP possibilita aumentar o poder da CPU de um sistema, mesmo que não exista CPUs com velocidades de relógio maiores — basta adicionar outra CPU. Entretanto, esta flexibilidade traz algumas desvantagens. A primeira desvantagem é que nem todos os sistemas são capazes de efetuar a operação SMP. Seu sistema precisa ter uma placa-mãe desenvolvida para suportar processadores múltiplos. Se não for o caso, será necessário uma atualização da placa-mãe (no mínimo). A segunda desvantagem é que o SMP aumenta a sobrecarga do sistema. Isto faz sentido se pararmos para pensar - tendo mais CPUs para agendar trabalho, o sistema operacional requer mais ciclos da CPU para a sobrecarga. Outro aspecto é que, com CPUs múltiplas, pode haver mais contenção dos recursos do sistema. Devido estes fatores, atualizar um sistema com dois processadores para uma unidade de quatro processadores não resulta num aumento de 100% do poder da CPU. De fato, dependendo do hardware atual, da carga e da arquitetura do processador, é possível atingir um estágio no qual a adição de um outro processador pode, na realidade, reduzir o desempenho do sistema. Um outro aspecto para ter em mente é que o SMP não ajuda cargas de trabalho que consistem de uma aplicação monolítica com um fluxo de execução. Ou seja, se um programa de simulação integrado ao computador roda como um processo e sem encadeamentos, não rodará mais rápido em um sistema SMP do que numa máquina com um processador. De fato, pode até rodar um pouco mais lentamente, devido ao aumento de sobrecarga trazido pelo SMP. Por estes motivos, muitos administradores de sistemas acreditam que o melhor caminho é usar o poder de processamento de um fluxo. Isto oferece o melhor poder de CPU com o menor número de restrições sobre seu uso. 38 Capítulo 3. Largura de Banda e Poder de Processamento Apesar desta discussão parecer indicar que o SMP nunca é uma boa idéia, há ocasiões nas quais faz sentido. Por exemplo: ambientes que rodam múltiplas aplicações integradas ao computador são boas candidatas para o SMP. O motivo é que as aplicações, que não fazem nada além de computar por períodos longos de tempo, mantêm a contenção entre processos ativos (e, consequentemente, a sobrecarga do sistema operacional) a um mínimo, enquanto os processos mantêm todas as CPUs ocupadas. Outra coisa sobre o SMP para ter em mente é que o desempenho de um sistema SMP tende a degradar mais graciosamente conforme aumenta a carga do sistema. Isto torna os sistemas SMP conhecidos nos ambientes de servidor e multi-usuário, já que o mix de processos em constante alteração pode impactar menos a carga do sistema todo em uma máquina com multi-processador. 3.3. Informações Específicas do Red Hat Enterprise Linux Monitorar a largura de banda e utilização da CPU sob o Red Hat Enterprise Linux implica usar as ferramentas abordadas no Capítulo 2; portanto, se você ainda não leu este capítulo, deve fazê-lo antes de prosseguir. 3.3.1. Monitorando a Largura de Banda no Red Hat Enterprise Linux Conforme apresentado na Seção 2.4.2, é difícil monitorar diretamente a utilização da banda (bandwidth). No entanto, ao examinar as estatísticas a nível dos dispositivos, é possível detectar se a banda insuficiente é um problema em seu sistema. Usando o vmstat, é possível determinar se a atividade geral dos dispositivos é excessiva, examinando os campos bi e bo. Anotar os campos si e so dá mais algumas pistas sobre o quanto de atividade do disco está designada a atividades I/O relacionadas a swap: r 1 procs b w 0 0 memory swpd free buff cache 0 248088 158636 480804 si 0 swap so 0 io bo 6 bi 2 in 120 system cs 120 us 10 sy 3 cpu id 87 Neste exemplo, o campo bi mostra dois blocos/segundo gravados nos dispositivos de bloco (principalmente drives de disco), enquanto o campo bo mostra seis blocos/segundo lidos pelos dispositivos de bloco. Podemos determinar que nenhuma destas atividades era relacionada ao swapping, já que ambos campos si e so mostram uma taxa de zero kilobytes/segundo de I/O relacionada a swap. Usando o iostat é possível ter mais algumas pistas sobre as atividades relacionadas ao disco: Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) avg-cpu: Device: dev8-0 dev8-1 %user 5.34 %nice 4.60 tps 1.10 0.00 %sys 2.83 07/21/2003 %idle 87.24 Blk_read/s 6.21 0.00 Blk_wrtn/s 25.08 0.00 Blk_read 961342 16 Blk_wrtn 3881610 0 Este output nos mostra que o dispositivo com maior número 8 (/dev/sda, o primeiro disco SCSI) teve média um pouco acima de uma operação I/O por segundo (o campo tsp). A maior parte das atividades I/O deste dispositivo foram gravações (o campo Blk_wrtn), com um pouco mais de 25 blocos gravados a cada segundo (o campo Blk_wrtn/s). Se você precisar de mais detalhes, use a opção -x do iostat: Capítulo 3. Largura de Banda e Poder de Processamento 39 Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) avg-cpu: %user 5.37 Device: /dev/sda /dev/sda1 /dev/sda2 /dev/sda3 /dev/sda4 %nice 4.54 rrqm/s wrqm/s 13.57 2.86 0.17 0.00 0.00 0.00 0.31 2.11 0.09 0.75 %sys 2.81 r/s 0.36 0.00 0.00 0.29 0.04 07/21/2003 %idle 87.27 w/s 0.77 0.00 0.00 0.62 0.15 rsec/s 32.20 0.34 0.00 4.74 1.06 wsec/s 29.05 0.00 0.00 21.80 7.24 rkB/s 16.10 0.17 0.00 2.37 0.53 wkB/s avgrq-sz 14.53 54.52 0.00 133.40 0.00 11.56 10.90 29.42 3.62 43.01 Sobre e acima das linhas mais longas contendo mais campos, a primeira coisa para ter em mente é que este output do iostat agora mostra as estatísticas por partição. Usando o df para associar os pontos de montagem aos nomes dos dispositivos, é possível usar este relatório para determinar, por exemplo, se a partição contendo o /home/ está sobrecarregada de trabalho. Na verdade, cada linha do output do iostat -x é mais longa e contém mais informações que esta. Aqui está o resto de cada linha (com a adição da coluna dos dispositivos para facilitar a leitura): Device: /dev/sda /dev/sda1 /dev/sda2 /dev/sda3 /dev/sda4 avgqu-sz 0.24 0.00 0.00 0.12 0.11 await svctm 20.86 3.80 141.18 122.73 6.00 6.00 12.84 2.68 57.47 8.94 %util 0.43 0.03 0.00 0.24 0.17 Neste exemplo é interessante notar que /dev/sda2 é a partição swap do sistema. É óbvio que o swapping não é um problema neste sistema, devido os diversos campos apresentando 0.00 para esta partição. Um outro ponto interessante é o /dev/sda1. As estatísticas desta partição são incomuns - a atividade geral parece baixa, mas por que o tamanho médio do pedido I/O (o campo avgrq-sz), o tempo médio de espera (o campo await) e o tempo médio de serviço (o campo svctm) são tão maiores que os das outras partições? A resposta é que a partição contém o diretório /boot/, onde o kernel e o disco ram inicial estão armazenados. Quando o sistema inicializar, as I/Os de leitura (note que somente os campos rsec/s e rkB/s são diferentes de zero; nenhuma gravação é feita aqui regularmente) usados durante o processo de inicialização são destinados a números grandes de blocos, resultando na espera e tempos de serviço relativamente longos apresentados pelo iostat. É possível usar o sar para uma visão geral mais longa das estatísticas I/O. Por exemplo: o sar -b apresenta um relatório geral de I/O: Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) 12:00:00 12:10:00 12:20:01 ... 06:00:02 Average: AM AM AM tps 0.51 0.48 rtps 0.01 0.00 wtps 0.50 0.48 bread/s 0.25 0.00 bwrtn/s 14.32 13.32 PM 1.24 1.11 0.00 0.31 1.24 0.80 0.01 68.14 36.23 34.79 07/21/2003 Aqui, assim como na apresentação inicial do iostat, as estatísticas são agrupdas para todos os dispositivos de bloco. Um outro relatório relacionado a I/O é produzido usando o sar -d: Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) 07/21/2003 40 Capítulo 3. Largura de Banda e Poder de Processamento 12:00:00 12:10:00 12:10:00 12:20:01 12:20:01 ... 06:00:02 06:00:02 Average: Average: AM AM AM AM AM DEV dev8-0 dev8-1 dev8-0 dev8-1 tps 0.51 0.00 0.48 0.00 sect/s 14.57 0.00 13.32 0.00 PM PM dev8-0 dev8-1 dev8-0 dev8-1 1.24 0.00 1.11 0.00 36.25 0.00 102.93 0.00 Este relatório oferece informações por dispositivo, mas com poucos detalhes. Apesar de não haver estatísticas explícitas sobre a utilização da banda para um determinado canal ou central de dados, nós podemos pelo menos determinar o que os dispositivos estão fazendo e usar suas atividades para determinar indiretamente a carga do canal. 3.3.2. Monitorando a Utilização da CPU no Red Hat Enterprise Linux Ao contrário da banda, monitorar a utilização da CPU é bem mais simples. Desde uma porcentagem da utilização da CPU no Sistema de Monitoramento GNOME às estatísticas mais aprofundadas reportadas pelo sar, é possível determinar com acuracidade o quanto de poder da CPU está sendo consumido e pelo que. Além do Sistema de Monitoramento GNOME, o top é a primeira ferramenta de monitoramento de recursos abordada no Capítulo 2 para oferecer uma representação mais profunda da utilização da CPU. Aqui está um relatório do top sobre uma estação de trabalho com processador duplo: 9:44pm up 2 days, 2 min, 1 user, load average: 0.14, 0.12, 0.09 90 processes: 82 sleeping, 1 running, 7 zombie, 0 stopped CPU0 states: 0.4% user, 1.1% system, 0.0% nice, 97.4% idle CPU1 states: 0.5% user, 1.3% system, 0.0% nice, 97.1% idle Mem: 1288720K av, 1056260K used, 232460K free, 0K shrd, 145644K buff Swap: 522104K av, 0K used, 522104K free 469764K cached PID 30997 1120 1260 888 1264 1 2 3 4 5 6 7 8 9 10 USER ed root ed root ed root root root root root root root root root root PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 16 0 1100 1100 840 R 1.7 0.0 0:00 top 5 -10 249M 174M 71508 S < 0.9 13.8 254:59 X 15 0 54408 53M 6864 S 0.7 4.2 12:09 gnome-terminal 15 0 2428 2428 1796 S 0.1 0.1 0:06 sendmail 15 0 16336 15M 9480 S 0.1 1.2 1:58 rhn-applet-gui 15 0 476 476 424 S 0.0 0.0 0:05 init 0K 0 0 0 0 SW 0.0 0.0 0:00 migration_CPU0 0K 0 0 0 0 SW 0.0 0.0 0:00 migration_CPU1 15 0 0 0 0 SW 0.0 0.0 0:01 keventd 34 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU0 34 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU1 15 0 0 0 0 SW 0.0 0.0 0:05 kswapd 15 0 0 0 0 SW 0.0 0.0 0:00 bdflush 15 0 0 0 0 SW 0.0 0.0 0:01 kupdated 25 0 0 0 0 SW 0.0 0.0 0:00 mdrecoveryd A primeira 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 indireta, 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 ferramentas. Se examinarmos o output do vmstat, obteremos um entendimento ligeiramente diferente de nosso sistema exemplo: r 1 0 0 0 0 0 0 0 0 0 procs b w 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 swpd 0 0 0 0 0 0 0 0 0 0 free 233276 233276 233276 233276 233276 233276 233276 233276 233276 233276 buff 146636 146636 146636 146636 146636 146636 146636 146636 146636 146636 memory cache 469808 469808 469808 469808 469808 469808 469808 469808 469808 469808 si 0 0 0 0 0 0 0 0 0 0 swap so 0 0 0 0 0 0 0 0 0 0 bi 7 0 0 0 0 0 0 0 0 0 io bo 7 0 0 0 0 32 0 0 0 0 in 14 523 557 544 517 518 516 516 516 516 system cs 27 138 385 343 89 102 91 72 88 81 us 10 3 2 2 2 2 2 2 2 2 sy 3 0 1 0 0 0 1 0 0 0 cpu id 87 96 97 97 98 98 98 98 97 97 Usamos aqui o comando vmstat 1 10 para examinar o sistema a todo segundo por dez vezes. Primeiramente, as estatísticas relativas à CPU (os campos us, sy e id) parecem similares ao output do top, e pode até parecer um pouco menos detalhado. No entanto, ao 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 aproximadamente 500 interrupções por segundo e está alternando entre processos entre 80 e 400 vezes por segundo. Se você acha que isto parece muito ativo, pense novamente, pois o processamento a 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 poucas informações adicionais em relação ao que vimos anteriormente com top e vmstat. Entretanto, o sar produz uma variedade de relatórios muito úteis ao monitorar a utilização da CPU. O primeiro relatório é obtido através do comando sar -q, que apresenta o comprimento da fila de execução, o número total de processos e as médias de carga nos últimos um e cinco minutos. Eis uma exemplo: 42 Capítulo 3. Largura de Banda e Poder de Processamento Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 12:00:01 12:10:00 12:20:01 ... 09:50:00 Average: AM AM AM runq-sz 3 5 plist-sz 122 123 ldavg-1 0.07 0.00 ldavg-5 0.28 0.03 AM 5 4 124 123 0.67 0.26 0.65 0.26 07/21/2003 Neste exemplo, o sistema está sempre ocupado (dado que mais de um processo é executável ao mesmo tempo), mas não está sobrecarregado (devido o fato que este sistema em particular tem mais de um processador). O próximo relatório do sar relativo à CPU é produzido pelo comando sar -u: Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 12:00:01 12:10:00 12:20:01 ... 10:00:00 Average: AM AM AM CPU all all %user 3.69 1.73 %nice 20.10 0.22 %system 1.06 0.80 %idle 75.15 97.25 AM all all 35.17 7.47 0.83 4.85 1.06 3.87 62.93 83.81 07/21/2003 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, portanto, é 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 determinado processador ou para todos os processadores. Aqui está um exemplo do output do sar -U ALL: Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 12:00:01 12:10:00 12:10:00 12:20:01 12:20:01 ... 10:00:00 10:00:00 Average: Average: AM AM AM AM AM CPU 0 1 0 1 %user 3.46 3.91 1.63 1.82 %nice 21.47 18.73 0.25 0.20 %system 1.09 1.03 0.78 0.81 %idle 73.98 76.33 97.34 97.17 AM AM 0 1 0 1 39.12 31.22 7.61 7.33 0.75 0.92 4.91 4.78 1.04 1.09 3.86 3.88 59.09 66.77 83.61 84.02 07/21/2003 O comando sar -w reporta o número de alternações de contexto por segundo, possibilitando obter pistas adicionais sobre onde os ciclos da CPU estão sendo gastos: Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 12:00:01 12:10:00 12:20:01 ... 10:10:00 Average: AM AM AM cswch/s 537.97 339.43 AM 319.42 1158.25 07/21/2003 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 "interrupções por segundo": Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 12:00:01 12:10:00 12:20:01 ... 10:40:01 Average: AM AM AM INTR sum sum intr/s 539.15 539.49 AM sum sum 539.10 541.00 07/21/2003 Usando o comando sar -I PROC, é possível detalhar a atividade por processo (em sistemas com multi-processadores) e por nível de interrupção (de 0 a 15): Linux 2.4.21-1.1931.2.349.2.2.entsmp (pigdog.example.com) 07/21/2003 12:00:00 AM 12:10:01 AM CPU 0 i000/s 512.01 i001/s 0.00 i002/s 0.00 i008/s 0.00 i009/s 3.44 i011/s 0.00 i012/s 0.00 12:10:01 12:20:01 ... 10:30:01 10:40:02 Average: AM AM CPU 0 i000/s 512.00 i001/s 0.00 i002/s 0.00 i008/s 0.00 i009/s 3.73 i011/s 0.00 i012/s 0.00 AM AM CPU 0 0 i000/s 512.00 512.00 i001/s 1.67 0.42 i002/s 0.00 0.00 i003/s 0.00 N/A i008/s 0.00 0.00 i009/s 15.08 6.03 i010/s 0.00 N/A Este relatório (que foi truncado horizontalmente para caber na página) inclui uma coluna para cada nível de interrupção (ex.: o campo i002/s ilustrando a taxa do nível 2 de interrupção). Se este fosse um sistema com multi-processador, haveria uma linha por período de amostra para cada CPU. Um outro ponto importante a notar sobre este relatório é que o sar adiciona ou remove campos de interrupção específicos se não houver dados coletados parta este campo. O relatório exibido acima oferece um exemplo disto - o fim do relatório inclui os níveis de interrupção (3 e 10) que não estavam presentes no início do período de amostragem. Nota Há outros dois relatórios do sar relativos à interrupções — sar -I ALL e sar -I XALL. No entanto, a configuração default do utilitário de levantamento de dados sadc não coleta as informações necessárias para estes relatórios. Isto pode ser alterado ao editar o arquivo /etc/cron.d/sysstat e alterar esta linha: */10 * * * * root /usr/lib/sa/sa1 1 1 para esta: */10 * * * * root /usr/lib/sa/sa1 -I 1 1 Tenha em mente que esta alteração faz com que o sadc levante informações adicionais, resultando em tamanhos maiores de arquivos de dados. Portanto, assegure que a configuração de seu sistema possa suportar o consumo de espaço adicional. 44 Capítulo 3. Largura de Banda e Poder de Processamento 3.4. Recursos Adicionais Esta seção inclui diversos recursos especificamente relacionados ao Red Hat Enterprise Linux que podem ser usados para aprender mais sobre o assunto discutido neste capítulo. 3.4.1. Documentação Instalada O recursos seguintes são instalados no decorrer de uma instalação típica do Red Hat Enterprise Linux e podem ajudá-lo a aprender mais sobre o assunto abordado neste capítulo. • Página man vmstat(8) — Aprenda a exibir uma visão geral concisa do processo, memória, swap, I/O, sistema e utilização da CPU. • Página man iostat(1) — Aprenda a exibir as estatísticas da CPU e I/O. • Página man sar(1) — Aprenda a produzir relatórios da utilização de recursos do sistema. • Página man sadc(8) — Aprenda a coletar dados da utilização do sistema. • Página man sa1(8) — Aprenda sobre um script que roda o sadc periodicamente. • Página man top(1) — Aprenda a exibir a utilização e estatísticas no nível de processo da CPU. 3.4.2. Sites Úteis • http://people.redhat.com/alikins/system_tuning.html — Informações de Ajuste para Servidores Linux (System Tuning Info for Linux Servers). Uma tática para ajustar o desempenho e monitoramento de recursos para servidores. • http://www.linuxjournal.com/article.php?sid=2396 — Ferramentas de Monitoramento de Desempenho para Linux (Performance Monitoring Tools for Linux). Esta página é mais direcionada ao administrador interessado em elaborar uma solução gráfica customizada de desempenho. Como foi elaborado há muitos anos atrás, alguns dos detalhes talvez não possam mais ser aplicados, mas o conceito e execução geral ainda funcionam. 3.4.3. Livros Relacionados Os livros seguintes abordam várias questões relacionadas ao monitoramento de recursos e são boas fontes para administradores de sistemas Red Hat Enterprise Linux. • O Guia de Administração de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. — Inclui um capítulo sobre muitas das ferramentas de monitoramento dos recursos abordadas aqui. • Linux Performance Tuning and Capacity Planning de Jason R. Fink e Matthew D. Sherer; Sams — Oferece uma visão mais profunda das ferramentas de monitoramento de recursos apresentadas aqui e inclui outras que podem ser apropriadas para necessidades mais específicas de monitoramento dos recursos. • Linux Administration Handbook de Evi Nemeth, Garth Snyder, e Trent R. Hein; Prentice Hall — Oferece um capítulo curto com escopo similar ao deste manual, que inclui uma seção interessante sobre como diagnosticar um sistema que ficou mais lento repentinamente. • Linux System Administration: A User’s Guide de Marcel Gagne; Addison Wesley Professional — Contém um pequeno capítulo sobre o monitoramento e ajuste de desempenho. Capítulo 4. Memória Física e Virtual Hoje em dia, todos os computadores de uso geral são do tipo conhecido como computadores de programas armazenados. Como o nome implica, os computadores de programas armazenados carregam as instruções (os blocos construtores dos programas) em algum tipo de armazenamento interno, onde subsequentemente executam estas intruções. Os computadores de programas armazenados também usam o mesmo armazenamento para dados. Isto contrasta com os computadores que usam a configuração de seu hardware para controlar sua operação (tais como computadores antigos baseados no plugboard). O local onde os progrmas eram armazenados nos primeiros computadores de programas armazenados tinha nomes variados e usava diversas tecnologias diferentes, desde pontos num tubo de raio cátodo à pressão em colunas de mercúrio. Felizmente, os computadores de hoje usam tecnologias com maior capacidade de armazenamento e tamanhos como nunca vistos antes. 4.1. Padrões de Acesso ao Armazenamento Algo para ter em mente ao longo deste capítulo é que os computadores tendem a acessar o armazenamento de determinadas maneiras. De fato, a maioria do acesso ao armazenamento tende a exibir um (ou ambos) dos seguintes atributos: • O acesso tende ser sequencial • O acesso tende ser localizado Acesso sequencial significa que, se o endereço N é acessado pela CPU, é bem provável que o endereço N +1 seja acessado em seguida. Isto faz sentido, já que a maioria dos programas consiste de grandes seções de instruções que são executadas — em ordem — uma após a outra. Acesso localizado significa que, se o endereço X é acessado, é provável que outros endereços próximos ao X também sejam acessados no futuro. Estes atributos são cruciais porque permitem que um armazenamento menor e mais rápido carregue um armazenamento maior e mais lento. Esta é a base para a implementação da memória virtual. Mas, antes de abordarmos a memória virtual, precisamos examinar as diversas tecnologias de armazenamento em uso no momento. 4.2. O Espectro do Armazenamento Os computadores atuais usam diversas tecnologias de armazenamento. Cada tecnologia é direcionada a uma função específica, com velocidades e capacidades correspondentes. Estas tecnologias são: • Registradores de CPU • Memória cache • RAM • Discos rígidos • Armazenamento de backup off-line (fita, disco ótico, etc) 46 Capítulo 4. Memória Física e Virtual Em termos de capacidades e custos, estas tecnologias compoem um espectro. Por exemplo: os registradores da CPU são: • Muito rápido (tempos de acesso de alguns nanossegundos) • Baixa capacidade (geralmente menor que 200 bytes) • Capacidade de expansão muito limitada (seria necessária uma mudança na arquitetura da CPU) • Caro (mais de um dólar US por byte) No entanto, na outra extremidade do espectro, o armazenamento de backup off-line é: • Muito lento (os tempos de acesso podem ser medidos em dias, caso a mídia de backup tenha que ser enviada através de distâncias longas) • Capacidade muito alta (10s - 100s de gigabytes) • Capacidades de expansão essencialmente ilimitadas (limitadas apenas pelo espaço no chão necessário para comportar a mídia de backup) • Muito barato (frações de centavos por byte) Ao utilizar tecnologias diferentes com capacidades diferentes, é possível ajustar o design do sistema para um desepenho máximo com o menor custo possível. As seções seguintes exploram cada tecnologia dentro do espectro de armazenamento. 4.2.1. Registradores de CPU Cada CPU atual inclui registradores para uma gama de propósitos, desde armazenar endereços da instrução sendo executada ao armazenamento e manipulação de dados para propósitos genéricos. Os registradores da CPU rodam na mesma velocidade que o resto da CPU; caso contrário, seriam um sério gargalo para o desempenho geral do sistema. A razão disso é que praticamente todas as operações desempenhadas pela CPU envolvem os registradores de alguma forma. O número de registradores da CPU (e seus usos) é estritamente dependente do design arquitetônico da CPU. Não há maneira de alterar o número de registradores da CPU, além de migrar para uma CPU com arquitetura diferente. Por estes motivos, o número de registradores da CPU pode ser considerado uma constante, já que são alteráveis somente com muito esforço e custo. 4.2.2. Memória Cache O propósito da memória cache é atuar como um buffer entre os registradores da CPU, muito limitados e de alta velocidade, e a memória principal do sistema, relativamente mais lenta e maior — geralmente referida como RAM1. A memória cache tem uma velocidade operacional similar à da própria CPU, portanto, quando a CPU acessa os dados no cache, não fica esperando os dados. A memória cache é configurada de maneira que, sempre que os dados forem acessados pela RAM, o hardware do sistema primeiro verifica se os dados desejados estão no cache. Se os dados estiverem no cache, são rapidamente recuperados e usados pela CPU. Mas, se os dados não estão no cache, são acessados pela RAM e, enquanto são transferidos para a CPU, também são alocadas no cache (caso sejam novamente necessários mais tarde). Da perspectiva da CPU, tudo isso é feito transparentemente, de modo que a única diferença entre acessar os dados no cache e na RAM é o tempo de resposta. Em termos de capacidade de armazenamento, o cache é bem menor que a RAM. Consequentemente, nem todo byte da RAM pode ter sua localidade única no cache. Sendo assim, é necessário dividir o 1. Apesar de "RAM" ser o acrônimo de "Random Access Memory," e um termo que poderia ser facilmente aplicado a qualquer tecnologia de armazenamento, permitindo o acesso não-sequencial de dados armazenados, quando os administradores de sistemas falam sobre RAM, referem-se à memória principal do sistema. Capítulo 4. Memória Física e Virtual 47 cache em seções que podem ser usadas para armazenar áreas diferentes da memória RAM e também ter um mecanismo que permite a cada área do cache armazenar áreas diferentes de RAM em horas diferentes. Mesmo com a diferença de tamanho entre cache e RAM, dada a natureza sequencial e localizada do acesso ao armazenamento, uma pequena quantidade de cache pode, efetivamente, acelerar o acesso a uma grande quantidade de memória RAM. Ao gravar dados pela CPU, as coisas podem complicar um pouco. Há duas táticas diferentes que podem ser usadas. Em ambos os casos os dados são gravados primeiro no cache. No entanto, como o propósito do cache é funcionar como uma cópia muito rápida do conteúdo de porções selecionadas da RAM, sempre que algum dado é alterado, deve ser gravado em ambos, na memória cache e na memória RAM. Caso contrário, os dados do cache e os dados da RAM não coincidiriam. As duas táticas diferem no processo de como isso é feito. Uma tática, conhecida como cache de gravação direta, grava os dados modificados imediatamente na RAM. O cache de gravação reversa, no entanto, atrasa a gravação dos dados modificados de volta à RAM. A razão disto é reduzir o número de vezes que um dado frequentemente modificado deve ser gravado de volta à RAM. O cache de gravação direta é um pouco mais simples para implementar e, por este motivo, é mais comum. O cache de gravação reversa é um pouco mais difícil de implementar; além de armazenar os dados reais, é necessário manter alguma espécie de mecanismo capaz de avisar se os dados do cache estão limpos (quando os dados do cache são os mesmos que os dados da RAM) ou sujos (quando os dados do cache foram modificados, o que significa que os dados da RAM não estão mais atualizados). Também é necessário implementar uma maneira de enviar periodicamente entradas sujas do cache de volta à RAM. 4.2.2.1. Níveis do Cache Os sub-sistemas do cache nos designs dos compudatores de hoje podem ser multi-níveis; ou seja, pode existir mais de um conjunto de cache entre a CPU e a memória principal. Os níveis do cache frequentemente são numerados, com os números menores mais próximos à CPU. Muitos sistemas têm dois níveis de cache: • O cache L1 (level 1) frequentemente é localizado diretamente no chip da CPU e roda na mesma velocidade que a CPU. • O cache L2 (level 2) frequentemente é parte do módulo da CPU, roda nas mesmas velocidades (ou próximas) da CPU, e geralmente é um pouco maior e mais lento que o cache L1. Alguns sistemas (normalmente, os servidores de alto desempenho) também tem o cache L3, que geralmente é parte da placa-mãe do sistema. Conforme esperado, o cache L3 seria maior (e provavelmente mais lento) que o cache L2. Em qualquer um dos casos, o objetivo de todos os sub-sistemas de cache — seja de nível simples ou multi-nível — é reduzir o tempo médio de acesso à memória RAM. 4.2.3. Memória Principal — RAM A RAM representa o armazenamento eletrônico em massa nos computadores de hoje. É usada como armazenamento para dados e programas, enquanto estes estão em uso. A velocidade da RAM na maioria dos sistemas de hoje fica entre a velocidade da memória cache e a dos discos rígidos; bem mais próxima à da memória cache. A operação básica da RAM é, na verdade, bem simples. No nível mais baixo há chips da RAM — circuitos integrados que executam a "memorização" de verdade. Estes chips têm quatro tipos de conexões com o mundo externo: • Conexões de eletricidade (para operar os circuitos dentro do chip) 48 Capítulo 4. Memória Física e Virtual • Conexões de dados (para permitir a transferência de dados para dentro ou para fora do chip) • Conexões de leitura/gravação (para controlar se os dados devem ser armazenados no ou recuperados pelo chip) • Conexões de endereço (para determinar onde os dados devem ser lidos/gravados dentro do chip) Aqui estão os passos para armazenar dados na RAM: 1. Os dados a serem armazenados são apresentados às conexões de dados. 2. O endereço no qual os dados devem ser armazenados é apresentado às conexões de endereço. 3. A conexão leitura/gravação está ajustada no modo gravação (write). Recuperar dados também é simples: 1. O endereço dos dados desejados é apresentado às conexões de endereço. 2. A conexão leitura/gravação é ajustada no modo leitura (read). 3. Os dados desejados são lidos (acessados) pelas conexões de dados. Apesar destes passos parecerem simples, acontecem a velocidades muito altas, e o tempo gasto com cada passo é medido em nanossegundos. Praticamente todos os chips de RAM criados hoje são vendidos como módulos. Cada módulo consiste de diversos chips de RAM ligados a uma pequena placa de circuito. A disposição mecânica e elétrica do módulo adere aos diversos padrões do setor, possibilitando adquirir memória de fabricantes variados. Nota O principal benefício de um sistema usando módulos RAM padronizados é que custo da RAM tende a manter-se baixo, devido à possibilidade de adquirir módulos de mais de um fabricante de sistemas. Apesar da maioria dos computadores usar módulos RAM padronizados, há exceções. A mais notável é o laptop (e mesmo aqui já vem ocorrendo alguma padronização) e servidores high-end. No entanto, mesmo nestes casos, é provável que exista módulos de terceiros, assumindo que o sistema seja relativamente conhecido e que não seja um design completamente inovador. 4.2.4. Discos Rígidos Todas as tecnologias abordadas até então são de natureza volátil. Em outras palavras, os dados contidos no armazenamento volátil são perdidos quando a energia é desligada. Por outro lado, os discos rígidos são não-voláteis — os dados que eles contêm continuam lá, mesmo após a energia ser desligada. Por este motivo, os discos rígidos ocupam uma posição especial no espectro de armazenamento. Sua natureza não-volátil torna-os ideais para armazenar programas e dados para uso a longo prazo. Um outro aspecto único aos discos rígidos é que, ao contrário da memória RAM e do cache, não é possível executar programas diretamente quando estão armazenados em discos rígidos. Ao invés disso, eles precisam ser acessados primeiro pela memória RAM. Também diferentemente das memórias RAM e cache, é a velocidade de armazenamnto e recuperação dos discos rígidos - pelo menos uma ordem de magnitude mais lentos que as tecnologias totalmente eletrônicas usadas para cache e RAM. A diferença de velocidades existe devido, principalmente, à sua natureza eletromecânica. Há quatro fases diferentes durante cada transferência para ou de um disco rígido. A lista seguinte ilustra estas fases, juntamente ao tempo que levaria a um drive típico de alto desempenho, em média, para completar cada fase: Capítulo 4. Memória Física e Virtual • Movimento de acesso com o braço (5,5 milissegundos) • Rotação do disco (0,1 milissegundos) • Heads acessando/gravando dados (0,00014 milissegundos) • Transferência de dados de/para os eletrônicos do drive (0,003 milissegundos) 49 Dentre estas, somente a última fase não é dependente de nenhuma operação mecânica. Nota Apesar de haver muito mais a aprender sobre discos rígidos, as tecnologias de armazenamento em disco são abordadas com maior profundidade no Capítulo 5. Por enquanto, é necessário somente ter em mente a diferença enorme de velocidades entre as tecnologias baseadas em disco e baseadas na memória RAM, e que sua capacidade de armazenamento geralmente excede a da RAM em pelo menos 10 vezes, e frequentemente 100 vezes ou mais. 4.2.5. Armazenamento de Backup Off-Line O armazenamento de backup off-line vai um passo além do armazenamento no disco rígido em termos de capacidadade (maior) e velocidade (mais lenta). Aqui as capacidades são efetivamente limitadas somente pela sua capacidade em obter e armazenar a mídia removível. As tecnologias usadas nestes dispositivos variam amplamente. Aqui estão os tipos mais conhecidos: • Fita magnética • Disco ótico Obviamente, ter mídia removível significa que os tempos de acesso tornam-se ainda mais longos, particularmente 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 dispositivos 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, vamos explorar os conceitos da memória virtual básica. 4.3. Conceitos da Memória Virtual Básica Apesar da tecnologia por trás da construção de várias tecnologias de armazenamento atuais ser muito impressionante, o administrador de sistemas mediano não precisa saber dos detalhes. De fato, há somente uma questão que os administradores de sistemas precisam ter em mente: Nunca há memória RAM suficiente. Apesar desta evidência parecer humorística, muitos desenvolvedores de sistemas operacionais levaram bastante tempo tentando reduzir o impacto desta deficiência real. Eles implementaram a memória virtual — uma maneira de combinar RAM com armazenamento mais lento para dar a um sistema a impressão de ter mais memória RAM do que realmente há instalada. 50 Capítulo 4. Memória Física e Virtual 4.3.1. Memória Virtual em Termos Simples Vamos começar com uma aplicação hipotética. O código da máquina criando esta aplicação tem tamanho de 10000 bytes. Também requer outros 5000 bytes para armazenamento de dados e buffers de I/O. Isto significa que, para rodar esta aplicação, deve haver 15000 bytes de RAM disponíveis. Se houver um byte a menos, a aplicação não será executada. Este requisito de 15000 bytes é conhecido como o espaço de endereço da aplicação. É o número de endereços únicos necessários para armazenar ambos, a aplicação e seus dados. Nos primeiros computadores, a quantidade de RAM disponível tinha que ser maior que o espaço de endereço da maior aplicação a rodar; caso contrário, a aplicação falharia com um erro de "falta de memória". Uma última tática, conhecida como sobreposição (overlaying), tentou amenizar o problema permitindo que programadores ditassem quais partes de sua aplicação precisavam estar residindo na memória em uma determinada hora. Desta maneira, o código necessário uma vez para propósitos de inicialização pôde ser sobreposto (overlayed) com código que seria utilizado mais tarde. Apesar da sobreposição ter facilitado a redução de memória, era um processo muito complexo e suscetível a erros. As sobrepopsições também falharam em resolver a questão da redução de memória de todo o sistema no tempo de execução (runtime). Em outras palavras, um programa sobreposto pode precisar de menos memória para rodar que um programa não sobreposto, mas se o sistema ainda não tiver memória suficiente para o programa sobreposto, o resultado final é o mesmo — um erro de falta de memória. A memória virtual altera o conceito do espaço de endereço de uma aplicação. Ao invés de concentrar no quanto de memória uma aplicação precisa para rodar, um sistema operacional com memória virtual tenta continuamente responder à pergunta: "quão pequena é a memória precisa para rodar uma aplicação?" Apesar de, à primeira vista, parecer que nossa aplicação hipotética precisa de 15000 bytes para rodar, pense em nossa abordagem na Seção 4.1 — o acesso à memória tende ser sequencial e localizado. Por este motivo, a quantidade de memória precisa para executar a aplicação numa determinada hora é menor que 15000 bytes — geralmente muito menor. Considere os tipos de acessos à memória necessários para executar uma única instrução da máquina: • As instruções são lidas da memória. • Os dados necessários pelas instruções são acessados da memória. • Após completar as instruções, os resultados das instruções são gravados de volta na memória. O número real de bytes necessários para cada acesso à memória varia de acordo com a arquitetura da CPU, com as instruções em si e com o tipo de dados. No entanto, mesmo se uma instrução precisasse de 100 bytes de memória para cada tipo de acesso à memória, os 300 bytes necessários seriam bem menos que todo o espaço de endereço de 15000 bytes da aplicação. Se pudermos encontrar uma maneira de manter o registro das necessidades de memória de uma aplicação enquanto roda, poderíamos manter a aplicação rodando enquanto usaríamos menos memória que aquela ditada pelo seu espaço de endereço. Mas isso nos traz uma pergunta: Se somente uma parte da aplicação está na memória em uma determinada hora, onde está o resto dela? 4.3.2. Backing Store — a Doutrina Central da Memória Virtual A resposta rápida para esta pergunta é que o resto da aplicação continua no disco. Em outras palavras, o disco atua como o backing store da RAM; um meio de armazenamento maior e mais lento atuando como um "backup" de um meio de armazenamento menor e mais rápido. À primeira vista, isto pode parecer um grande problema de desempenho — acima de tudo, os drives de disco são bem mais lentos que a RAM. Capítulo 4. Memória Física e Virtual 51 Apesar disso ser verdade, é possível tirar proveito do comportamento de acesso sequencial e localizado das aplicações e eliminar a maioria das implicações do uso de drives de disco como backing store da memória RAM. Isto é feito ao estruturar o sub-sistema da memória virtual, para que tente garantir que aquelas partes da aplicação necessárias no momento — ou que, provavelmente, serão necessárias no futuro próximo — sejam mantidas na RAM somente enquanto forem realmente necessárias. De muitas maneiras, isso é parecido com a relação entre a memória cache e a memória RAM: fazer com que uma pequena quantidade de armazenamento rápido junto à uma grande quantidade de armazenamento lento atuem como uma grande quantidade de armazenamento rápido. Com isso em mente, vamos explorar o processo mais detalhadamente. 4.4. Memória Virtual: Os Detalhes Primeiro, devemos introduzir um novo conceito: espaço de endereço virtual. O espaço de endereço virtual (virtual address space) é a quantidade máxima de espaço de endereço disponível para uma aplicação. O espaço de endereço virtual varia de acordo com a arquitetura e sistema operacional da máquina. O espaço de endereço virtual depende da arquitetura porque é esta que define quantos bits estão disponíveis para propósitos de endereçamento. O espaço de endereço virtual também depende do sistema operacional porque a maneira através da qual este foi implementado pode introduzir limites adicionais além ou aquém daqueles impostos pela arquitetura. A palavra "virtual" do espaço de endereço virtual significa que este é o número total das localidades da memória disponíveis para uma aplicação que podem ser exclusivamente endereçadas, e não a quantidade de memória física instalada no sistema, nem dedicada à aplicação num determinado momento. No caso de nossa aplicação exemplo, seu espaço de endereço virtual é 15000 bytes. Para implementar a memória virtual é necessário que o sistema do computador tenha hardware para a administração de memória especial. Este hardware é geralmente conhecido como uma MMU (Memory Management Unit ou Unidade de Administração de Memória). Sem uma MMU, quando a CPU acessa a memória RAM, as localidades reais da RAM nunca mudam — o endereço de memória 123 é sempre a mesma localidade física dentro da RAM. No entanto, com uma MMU, os endereços de memória passam por uma fase de tradução antes de cada acesso à memória. Isso significa que o endereço de memória 123 pode ser direcionado ao endereço físico 82043 uma vez e ao endereço físico 20468 na próxima vez. No desenrolar do processo, a sobrecarga de registrar individualmente as traduções dos bilhões de bytes de memória de virtual para físico seria muito grande. Ao invés disso, a MMU divide a RAM em páginas — seções contíguas de memória de tamanho determinado, que são encaradas pela MMU como entidades separadas. Manter o registro destas páginas e de suas traduções de endereços pode soar como um passo adicional desnecessário e confuso. No entanto é crucial para implementar a memória virtual. Por este motivo, considere o seguinte ponto: Se pegarmos nossa aplicação hipotética com 15000 bytes de espaço de endereço virtual, assuma que os primeiros dados de acesso à instrução da aplicação estão armazenados no endereço 12374. Entretanto, assuma também que nosso computador tenha somente 12288 bytes de memória RAM física. O que acontece quando a CPU tenta acessar o endereço 12374? O que acontece é conhecido como uma falha de página (page fault). 4.4.1. Falhas de Página Uma falha de página é a sequência de eventos que ocorre quando um programa tenta acessar os dados (ou código) que está em seu espaço de endereço, mas não está localizada na RAM do sistema no momento. O sistema operacional deve resolver as falhas de página tornando a memória dos dados acessados residente de alguma maneira, permitindo ao programa continuar a operação como se a falha de página nunca tivesse ocorrido. 52 Capítulo 4. Memória Física e Virtual No caso de nossa aplicação hipotética, a CPU apresenta primeiro o endereço desejado (12374) à MMU. No entanto, a MMU não possui tradução para este endereço. Sendo assim, interrompe a CPU e faz com que o software, conhecido como ’fault handler’, seja executado. O fault handler então determina o que deve ser feito para resolver esta falha de página. É possível: • Encontrar onde a página desejada reside no disco e acessá-la (normalmente, este é o caso se a falha for de uma página de código) • Determinar que a página desejada já esteja na RAM (mas não localizada para o processo corrente) e reconfigurar a MMU para apontar para esta • Apontar para uma página especial contendo somente zeros e alocar uma nova página para o processo, somente se o processo tentar gravar na página especial (isso é chamado de uma página cópia na gravação - ou copy on write - e é frequentemente usada para páginas contendo dados iniciados com zero) • Obter a página desejada de algum outro lugar (abordado em mais detalhes posterirmente) Apesar das três primeiras ações serem relativamente simples, a última não é. Para esta precisamos cobrir alguns tópicos adicionais. 4.4.2. O Conjunto de Trabalho O grupo de páginas de memória física correntemente dedicado a um processo específico é conhecido como grupo de trabalho (ou working set) para este processo. O número de páginas do grupo de trabalho pode aumentar e diminuir, dependendo da disponibilidade geral das páginas do sistema todo. O grupo de trabalho aumenta com as falhas de página de um processo. O grupo de trabalho diminui conforme a quantidade de páginas livres diminui. Para impedir que a memória acabe completamente, as páginas devem ser removidas dos conjuntos de trabalho do processo e transformadas em páginas livres, disponíveis para uso posterior. O sistema operacional diminui os conjuntos de trabalho dos processos ao: • Gravar páginas modificadas numa área dedicada de um dispositivo de armazenamento em massa (geralmente conhecido como espaço de swapping ou paging) • Marcar páginas não modificadas como livres (não há necessidade de gravar estas páginas em disco já que não foram alteradas) Para determinar os conjuntos de trabalho apropriados para todos os processos, o sistema operacional precisa registrar as informações de uso de todas as páginas. Desta maneira, o sistema operacional determina quais páginas estão sendo ativamente usadas (e devem permanecer residentes na memória). Na maioria dos casos, algum tipo de algoritmo recém-usado determina quais páginas são removíveis dos conjuntos de trabalho do processo. 4.4.3. Swapping Apesar do swapping (gravar páginas modificadas no espaço swap do sistema) ser uma parte normal da operação de um sistema, é possível que haja swapping em demasia. A razão para ficar atento para o swapping excessivo é que a situação a seguir pode ocorrer facilmente, diversas vezes: • As páginas de um processo são gravadas no espaço swap • O processo torna-se inexecutável e tenta acessar uma página no espaço swap • A página é retornada à memória (provavelmente forçando páginas de outros processos a serem gravadas no espaço swap) • Pouco tempo depois, a página é novamente gravada no espaço swap Capítulo 4. Memória Física e Virtual 53 Se esta sequência de eventos for espalhada, é conhecida como thrashing e é um sinal de memória RAM insuficiente para a atual carga de trabalho. O thrashing é extremamente prejudicial ao desempenho do sistema, já que a carga da CPU e I/O que pode ser gerada numa situação como esta rapidamente compensa a carga imposta pelo trabalho real de um sistema. Em casos extremos, o sistema talvez não execute nenhum trabalho útil, gastando todos os seus recursos movendo páginas da e para a memória. 4.5. Implicações ao Desempenho da Memória Virtual Apesar da memória virtual possibilitar que os computadores rodem aplicações maiores e mais complexas com mais facilidade, assim como com qualquer outra ferramenta poderosa, ela tem um preço. Neste caso, o preço é refletido no desempenho — um sistema operacional com memória virtual tem muito mais a fazer do que um sistema operacional incapaz de suportar a memória virtual. Isto significa que o desempenho de uma aplicação com memória virtual nunca é tão bom quanto o desempenho da mesma aplicação com 100% residente na memória. No entanto, isto não é motivo para desistência. Os benefícios da memória virtual são muito bons para fazer isso. Com um pouco de esforço, é possível obter um bom desempenho. O que deve ser feito é analisar os recursos do sistema impactados pelo alto uso do sub-sistema da memória virtual. 4.5.1. Cenário do Desempenho no Pior Caso Por um momento, lembre-se do que você leu neste capítulo e considere quais recursos do sistema são usados por atividades extremamente pesadas de swapping e de falha de página: • RAM — a razão pela qual a RAM disponível está baixa (caso contrário, não haveria necessidade de falha de página ou swap). • Disco — O espaço em disco talvez não seja impactado, mas a largura de banda I/O seria (devido ao alto índice de paging e swapping). • CPU — A CPU está gastando ciclos no processamento necessário para suportar a administração da memória e a configuração das operações I/O para o paging e swapping. A natureza interrelacionada destas cargas facilita o entendimento de como a falta de recursos pode acarretar em problemas severos de desempenho. Tudo o que precisamos é um sistema com pouca memória RAM, alto índice de falhas de página e um sistema rodando próximo de seus limites em termos de I/O do disco ou CPU. Neste ponto, o sistema está com thrashing, com baixo desempenho como resultado inevitável. 4.5.2. Cenário do Desempenho no Melhor Caso No melhor dos casos, a sobrecarga do suporte à memória virtual apresenta uma carga extra mínima em um sistema bem configurado: • RAM — RAM suficiente para todos os conjuntos de trabalho com um restinho de memória capaz de resolver quaisquer falhas de página2 • Disco — Devido a atividade limitada da falha de página, a largura de banda I/O seria minimamente impactada 2. Um sistema razoavelmente ativo sempre tem um certo nível de atividades relacionadas a falhas de página, devido às falhas de página ocorridas com a incursão de aplicações recém-lançadas na memória. 54 Capítulo 4. Memória Física e Virtual CPU — A maioria dos cliclos de CPU são, na verdade, dedicados a rodar aplicações, ao invés de rodar o código de administração de memória do sistema operacional • Sendo assim, temos que ter em mente que o impacto de desempenho da memória virtual é mínimo quando é usada o menos possível. Isto siginifica que o fator determinante para um bom desempenho do sub-sistema de memória virtual é ter memória RAM suficiente. A seguir (mas bem abaixo em termos de importância relativa) está a capacidade da CPU e I/O do disco. No entanto, tenha em mente que estes recursos ajudam somente na degradação do desempenho do sistema devido a muitas falhas e swapping de maneira mais graciosa; fazem pouco para ajudar o desempenho do sub-sistema da memória virtual (apesar de poderem desempenhar uma função maior no desempenho do sistema todo). 4.6. Informações Específicas do Red Hat Enterprise Linux Devido à complexidade inerente de um sistema operacional com memória virtual de páginas sob demanda, monitorar os recursos relacionados à memória sob o Red Hat Enterprise Linux pode ser confuso. Consequentemente, é melhor começar pelas ferramentas mais simples e seguir adiante. Usando o free, é possível obter uma visão geral concisa (e de certa maneira simplista) da utilização da memória e de swap. Veja aqui um exemplo: total Mem: 1288720 -/+ buffers/cache: Swap: 522104 used 361448 145972 0 free 927272 1142748 522104 shared 0 buffers 27844 cached 187632 Nós percebemos que este sistema tem 1.2GB de RAM, dos quais somente 350MB estão em uso. Como esperado num sistema com tanta memória RAM livre, nenhuma das partições swap de 500MB está em uso. Contraste aquele exemplo com esse: total Mem: 255088 -/+ buffers/cache: Swap: 530136 used 246604 128792 111308 free 8484 126296 418828 shared 0 buffers 6492 cached 111320 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: r 2 2 1 1 2 3 3 2 3 procs b w 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 swpd 111304 111304 111304 111304 111304 111304 111304 111304 111304 free 9728 9728 9616 9616 9616 9620 9440 9276 9624 buff 7036 7036 7036 7036 7052 7052 7076 7076 7092 memory cache 107204 107204 107204 107204 107204 107204 107360 107368 107372 si 0 0 0 0 0 0 92 0 0 swap so 0 0 0 0 0 0 0 0 0 bi 6 0 0 0 0 0 244 0 16 io bo 10 0 0 0 48 0 0 0 0 in 120 526 552 624 603 768 820 832 813 system cs 24 1653 2219 699 1466 932 1230 1060 1655 us 10 96 94 98 95 90 85 87 93 sy 2 4 5 2 5 4 9 6 5 cpu id 89 0 1 0 0 6 6 7 2 Capítulo 4. Memória Física e Virtual 2 0 2 111304 9624 55 7108 107372 0 0 0 972 1189 1165 68 9 23 Durante essa amostra de 10 segundos, a quantidade de memória livre (o campo free) varia ligeiramente, e há um pouco de I/O relacionada a swap (os campos si e so), mas, no geral, esse sistema está funcionando bem. No entanto, é duvidoso o quanto de trabalho adicional pode suportar, dada a utilização de memória corrente. Quando pesquisamos questões relativas à memória, frequentemente é necessário determinar como o sub-sistema de memória virtual do Red Hat Enterprise Linux está usando a memória do sistema. Ao usar o sar, é possível examinar o aspecto do desempenho do sistema em mais detalhes. Ao rever o relatório do sar -r, podemos examinar a utilização da memória e de swap mais de perto: Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 12:00:01 12:10:00 12:20:00 ... 08:40:00 Average: AM kbmemfree kbmemused AM 240468 1048252 AM 240508 1048212 PM 934132 324346 07/22/2003 %memused kbmemshrd kbbuffers 81.34 0 133724 81.34 0 134172 354588 964374 27.51 74.83 0 0 26080 96072 kbcached 485772 485600 185364 467559 Os campos kbmemfree e kbmemused exibem as estatísticas típicas de memória usada e memória livre, com a porcentagem de memória utilizada exibida no campo %memused. Os campos kbbuffers e kbcached mostram quantos kilobytes de memória estão alocadas para buffers e para o cache de dados do sistema todo. O campo kbmemshrd é sempre zero para sistemas usando o kernel 2.4 do Linux (como o Red Hat Enterprise Linux). As linhas deste relatório foram quebradas para caber na página. Aqui está o restante de cada linha, com o timestamp adicionado à esquerda para facilitar a leitura: 12:00:01 12:10:00 12:20:00 ... 08:40:00 Average: AM AM AM PM kbswpfree kbswpused 522104 0 522104 0 522104 522104 0 0 %swpused 0.00 0.00 0.00 0.00 Para a utilização da memória swap, os campos kbswpfree e kbswpused exibem as quantidades de swap livre e de espaço swap usado, em kilobytes, com o campo %swpused exibindo o espaço swap utilizado em porcentagem. Para aprender mais sobre a atividade de swapping ocorrendo, use o relatório sar -W. Aqui está um exemplo: Linux 2.4.20-1.1931.2.231.2.10.entsmp (raptor.example.com) 12:00:01 12:10:01 12:20:00 ... 03:30:01 Average: AM AM AM PM 07/22/2003 pswpin/s pswpout/s 0.15 2.56 0.00 0.00 0.42 0.11 2.56 0.37 Percebemos aqui que, em média, houve três vezes menos páginas trazidas de swap (pswpin/s) que páginas indo para swap (pswpout/s). 56 Capítulo 4. Memória Física e Virtual Para entender melhor como as páginas estão sendo usadas, consulte o relatório sar -B: Linux 2.4.20-1.1931.2.231.2.10.entsmp (raptor.example.com) 12:00:01 12:10:00 12:20:00 ... 08:40:00 Average: AM AM AM PM pgpgin/s pgpgout/s 0.03 8.61 0.01 7.51 0.00 201.54 7.79 201.54 07/22/2003 activepg 195393 195385 inadtypg 20654 20655 inaclnpg 30352 30336 inatarpg 49279 49275 71236 169367 1371 18999 6760 35146 15873 44702 Aqui podemos determinar quantos blocos por segundo são paginados do (paged in) disco (pgpgin/s) e paginados para o (paged out) disco (pgpgout/s). Estas estatísticas servem como um barômetro da atividade geral da memória virtual. Entretanto, pode-se obter mais conhecimento ao examinar os outros campos deste relatório. O kernel do Red Hat Enterprise Linux marca todas as páginas como ativas ou inativas. Como o nome implica, as páginas ativas estão em uso corrente de alguma forma (como processos ou páginas de buffer, por exemplo), enquanto as páginas inativas não estão. Este relatório-exemplo mostra que a lista de páginas ativas (o campo activepg) tem, em média, aproximadamente 660MB 3. Os campos restantes deste relatório concentram-se na lista inativa — páginas que, por alguma razão, não foram utilizadas recentemente. O campo inadtypg mostra quantas páginas inativas estão sujas (alteradas) e talvez precisem ser gravadas no disco. O campo inaclnpg, por outro lado, mostra quantas páginas inativas estão limpas (inalteradas) e não precisam ser gravadas no disco. O campo inatarpg representa o tamanho desejado da lista inativa. Esse valor é calculado pelo kernel do Linux e é dimensionado de tal forma que a lista inativa continua grande o suficiente para atuar como um pool de substituição de páginas. Para mais dicas sobre o status de páginas (especificamente, a frequência de alteração de status), use o relatório sar -R. Aqui está uma amostra: Linux 2.4.20-1.1931.2.231.2.10.entsmp (raptor.example.com) 12:00:01 12:10:00 12:20:00 ... 08:50:01 Average: AM AM AM frmpg/s -0.10 0.02 shmpg/s 0.00 0.00 bufpg/s 0.12 0.19 campg/s -0.07 -0.07 PM -3.19 0.01 0.00 0.00 0.46 -0.00 0.81 -0.00 07/22/2003 As estatísticas deste relatório sar específico são únicas, pois podem ser positivas, negativas ou zero. Quando positivas, o valor indica a frequência com a qual as páginas desse tipo estão aumentando. Quando negativas, o valor indica a frequência com a qual as páginas desse tipo estão diminuindo. O valor zero indica que páginas desse tipo não estão aumentando nem diminuindo. Nesse exemplo, a última amostra exibe um pouco mais de três páginas por segundo sendo alocadas da lista de páginas livres (o campo frmpg/s) e aproximadamente uma página por segundo sendo adicionada ao cache de páginas (o campo campg/s). A lista de páginas usadas como buffers (o campo bufpg/s) ganhou aproximadamente uma página a cada dois segundos, enquanto a lista de páginas da memória compartilhada (o campo shmpg/s) não ganhou nem perdeu páginas. 3. O tamanho de página sob o Red Hat Enterprise Linux no sistema x86 usado neste exemplo é 4096 bytes. Sistemas baseados em outras arquiteturas podem ter tamanhos de página diferentes. Capítulo 4. Memória Física e Virtual 57 4.7. Recursos Adicionais Esta seção inclui várias fontes que podem ser usadas para aprender mais sobre o monitoramento de recursos e sobre o assunto abordado neste capítulo relativo ao Red Hat Enterprise Linux. 4.7.1. Documentação Instalada Os seguintes recursos são instalados no decorrer de uma típica instalação do Red Hat Enterprise Linux e podem ajudá-lo a aprender mais sobre o assunto abordado neste capítulo. • Página man free(1) — Aprenda a exibir as estatísticas da memória livre e usada. • Página man vmstat(8) — Aprenda a exibir uma visão geral concisa de processos, memória, swap, I/O, sistema e utilização da CPU. • Página man sar(1) — Aprenda a produzis relatórios de utilização dos recursos do sistema. • Página man sa2(8) — Aprenda a produzir arquivos diários do relatório de utilização dos recursos do sistema. 4.7.2. Sites Úteis • http://people.redhat.com/alikins/system_tuning.html — Informação de Ajuste do Sistema para Servidores Linux. Uma abordagem consciente do ajuste de desempenho e monitoramento de recursos para servidores. • http://www.linuxjournal.com/article.php?sid=2396 — Ferramentas de Monitoramento de Desempenho para Linux. Essa página é mais direcionada ao administrador interessado em elaborar uma solução gráfica personalizada de desempenho. Escrita há muitos anos atrás, alguns detalhes talvez não se apliquem mais, mas o conceito e execução gerais ainda funcionam. 4.7.3. Livros Relacionados Os livros a seguir abordam várias questões relacionadas ao monitoramento de recursos e são boas fontes de informação para administradores de sistemas Red Hat Enterprise Linux. • O Guia de Administração de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. — Inclui um capítulo sobre diversas ferramentas de monitoramento de recursos abordadas aqui. • Linux Performance Tuning and Capacity Planning de Jason R. Fink e Matthew D. Sherer; Sams — Oferece visões mais aprofundadas das ferramentas de monitoramento de recursos abordadas aqui e inclui outras que podem ser apropriadas para necessidades de monitoramento mais específicas. • Red Hat Linux Security and Optimization de Mohammed J. Kabir; Red Hat Press — Aproximadamente, as 150 primeiras páginas deste livro abordam questões relativas ao desempenho. Isso inclui capítulos dedicados a questões de desempenho específicas à rede, Internet, e-mail e servidores de arquivos. • Linux Administration Handbook de Evi Nemeth, Garth Snyder, e Trent R. Hein; Prentice Hall — Oferece um pequeno capítulo com escopo similar ao deste livro, mas inclui uma seção interessante sobre o diagnóstico de um sistema que ficou lento repentinamente. • Linux System Administration: A User’s Guide de Marcel Gagne; Addison Wesley Professional — Contém um pequeno capítulo sobre o monitoramento e ajuste de desempenho. • Essential System Administration (3a Edição) de Aeleen Frisch; O’Reilly & Associates — O capítulo sobre a administração de recursos do sistema contém boas informações genéricas, com algumas específicas ao Linux. 58 • Capítulo 4. Memória Física e Virtual System Performance Tuning (2a Edição) de Gian-Paolo D. Musumeci e Mike Loukides; O’Reilly & Associates — Apesar de ser altamente direcionado a implementações mais tradicionais do UNIX, há muitas referências específicas ao Linux ao longo do livro. Capítulo 5. Administrando o Armazenamento Se há alguma atividade que toma a maior parte do dia de um administrador de sistemas, esta deve ser a administração do armazenamento. Parece que os discos estão sempre sem espaço livre, sendo sobrecarregados por muitas atividades I/O ou falhando inesperadamente. Sendo assim, é vital ter um conhecimento sólido do armazenamento em disco para ser um administrador de sistemas competente. 5.1. Uma Visão Geral do Hardware de Armazenamento Antes de administrar o armazenamento, é preciso entender o hardware no qual os dados são armazenados. A não ser que você já tenha algum conhecimento sobre a operação do dispositivo de armazenamento em massa, poderá se ver numa situação com um problema relativo ao armazenamento, mas não possuirá o conhecimento elementar para interpretar o que está vendo. Ao obter um pouco de conhecimento da operação do respectivo hardware, você poderá determinar se o sub-sistema de armazenamento de seu computador está operando apropriadamente. A grande maioria dos dispositivos de armazenamento em massa usam alguma forma de mídia rotativa e suporta o acesso randômico aos dados nesta mídia. Isso significa que os seguintes componentes estão presentes de alguma forma em praticamente todos os dispositivos de armazenamento em massa: • Pratos de disco (disk platters) • Dispositivo de acesso/gravação de dados • Braços de acesso As seções seguintes exploram cada um destes componentes em mais detalhes. 5.1.1. Pratos de Disco A mídia rotativa usada para quase todos os dispositivos de armazenamento em massa tem a forma de um ou mais pratos circulares e achatados. O prato pode ser composto de diversos materiais diferentes, como alumínio, vidro e policarbonato. A superfície de cada prato é tratada de maneira a possibilitar o armazenamento de dados. A natureza exata desse tratamento depende da tecnologia de armazenamento de dados utilizada. A tecnologia mais comum é baseada na propriedade do magnetismo; nestes casos os pratos são cobertos de um componente que exibe boas características magnéticas. Uma outra tecnologia comum de armazenamento é baseada nos princípios ópticos; nestes casos, os pratos são cobertos por materiais cujas propriedades ópticas podem ser modificadas, assim permitindo armazenar os dados opticamente1 . Não importa a tecnologia de armazenamento em uso; os pratos de disco são torcidos, permitindo à sua superfície inteira varrer um outro componente — o dispositivo de acesso/gravação de dados. 1. Alguns dispositivos ópticos — notadamente os drives de CD-ROM— usam táticas um pouco diferentes para o armazenamento de dados; estas diferenças são apontadas ao longo do capítulo. 60 Capítulo 5. Administrando o Armazenamento 5.1.2. Dispositivo de acesso/gravação de dados O dispositivo de acesso/gravação é o componente que leva os bits e bytes no qual opera um sistema de computador e os transforma em variações magnéticas ou ópticas, necessárias para interagir com os materiais que cobrem a superfície dos pratos de disco. Às vezes, as condições sob as quais estes dispositivos devem operar são desafiadoras. Por exemplo: num armazenamento em massa magneticamente baseado, os dispositivos de acesso/gravação (conhecidos como cabeças) devem estar bem próximos à superfície do prato. No entanto, se a cabeça e a superfície do prato do disco tivessem contato, a fricção resultante danificaria ambos seriamente. Sendo assim, as superfícies da cabeça e do prato são polidas cuidadosamente, e a cabeça usa pressão do ar exercida pelos pratos giratórios para flutuar sobre a superfície do prato, "voando" há uma altitude mais fina que um fio de cabelo. É por este motivo que os drives de disco magnéticos são sensíveis a choque, alterações de temperatura repentinas e quaisquer contaminações do ar. Os desafios enfrentados pelas cabeças ópticas são de certa forma diferentes daqueles enfrentados pelas cabeças magnéticas — aqui, o grupo da cabeça deve permanecer há uma distância relativamente constante da superfície do prato. Caso contrário, as lentes usadas para focar no prato não produzem uma imagem suficientemente definida. Em qualquer um dos casos, as cabeças usam uma quantidade muito pequena da área da superfície do prato para o armazenamento de dados. Conforme o prato gira abaixo das cabeças, essa área da superfície toma a forma de uma linha circular muito fina. Se essa fosse a maneira como os dispositivos de massa funcionam, significaria que mais de 99% da área da superfície do prato seria desperdiçada. Poderia-se montar cabeças adicionais sobre o prato, mas, para utilizar totalmente a área da superfície do prato, seriam necessárias mais de mil cabeças. Se faz necessário um método para mover a cabeça sobre a superfície do prato. 5.1.3. Braços de Acesso Ao usar uma cabeça conectada a um braço capaz de varrer toda a superfície do prato, é possível usar o prato totalmente para o armazenamento de dados. Entretanto, o braço de acesso deve ser capaz de duas coisas: • Mover-se rapidamente • Mover-se com muita precisão O braço de acesso deve mover-se o mais rápido possível porque o tempo gasto movendo a cabeça de uma posição a outra é tempo desperdiçado. Isso ocorre porque não é possível acessar nenhum dado até que o braço de acesso pare de mover2. O braço de acesso deve ser capaz de mover-se com grande precisão porque, conforme afirmado anteriormente, 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 suficiente 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 é frequentemente referido como busca, e o tempo que leva para o braço de acesso mover-se de uma faixa a outra é conhecido como tempo de busca. 2. Em alguns dispositivos ópticos (como drives de CD-ROM), o braço de acesso move-se continuamente, fazendo com que o grupo da cabeça faça um movimento espiral ao longo da superfície do prato. Essa é uma diferença fundamental de como o meio de armazenamento é usado, e reflete a origem do CD-ROM como um meio de armazenamento para música, onde a recuperação contínua de dados é uma operação mais comum que a busca de um ponto de dados específico. Capítulo 5. Administrando o Armazenamento 61 Quando há pratos múltiplos (ou um prato com ambas superfícies utilizadas para o armazenamento de dados), os braços de cada superfície ficam empilhados, permitindo que a mesma faixa de cada superfície seja acessada simultaneamente. Se as faixas de cada superfície pudessem ser visualizadas com o acesso estático sobre uma determinada faixa, elas pareceriam estar empilhadas uma sobre a outra, formando um formato cilíndrico. Consequentemente, o conjunto de faixas acessível numa determinada posição dos braços de acesso são conhecidas como cilindro. 5.2. Conceitos de Endereçamento do Armazenamento A configuração dos pratos de disco, cabeças e dos braços de acesso possibilita posicionar a cabeça sobre qualquer parte de qualquer superfície de qualquer prato no dispositivo de armazenamento em massa. No entanto, isso não é suficiente; para usar essa capacidade de armazenamento devemos ter algum método para atribuir endereços a partes uniformemente dimensionadas do armazenamento disponível. Há um aspecto final necessário a este processo. Considere todas as faixas dos diversos cilindros presentes em um típico dispositivo de armazenamento em massa. Como as faixas têm diâmetros variados, suas circunferências também variam. Sendo assim, se o armazenamento estivesse endereçado somente ao nível da faixa, cada faixa teria quantidades diferentes de dados — a faixa #0 (a mais próxima do centro do prato) pode ter 10.827 bytes, enquanto a faixa #1.258 (próxima à extremidade externa do prato) pode ter 15.382 bytes. A solução é dividir cada faixa em diversos setores ou blocos de segmentos de armazenamento de tamanho consistente (geralmente 512 bytes). O resultado é que cada faixa contém um número definido3 de setores. Um efeito colateral disso é que cada faixa contém espaço não-usado — o espaço entre setores. Apesar do número constante de stores em cada faixa, a quantidade de espaço não-usado varia — há relativamente pouco espaço não-usado nas faixas de dentro e uma quantidade bem maior de espaço não-usado nas faixas de fora. Em ambos os casos, este espaço não-usado é desperdiçado, já que não é possível armazenar dados ali. Em contrapartida, a vantagem deste espaço desperdiçado é que agora é possível mapear efetivamente o armazenamento para um dispositivo de massa. De fato, há dois métodos de mapeamento — mapeamento baseado na geometria e mapeamento baseado no bloco. 5.2.1. Mapeamento Baseado na Geometria O termo mapeamento baseado na geometria refere-se ao fato dos dispositivos de armazenamento em massa realmente armazenarem dados num ponto físico específico no meio de armazenamento. No caso dos dispositivos aqui descritos, isto refere-se a três itens específicos que definem um ponto específico nos pratos do disco do dispositivo: • Cilindro • Cabeça • Setor As seções a seguir explicam como um endereço hipotético pode descrever uma localidade física especí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, portanto, as cabeças de acesso/gravação). Ao especificar um determinado cilindro, estamos eliminando todos os outros cilindros, reduzindo nossa busca a apenas uma faixa de cada superfície no dispositivo de armazenamento em massa. Cilindro Cabeça Setor 1014 X X Tabela 5-1. Mapeamento do Armazenamento Na Tabela 5-1, a primeira parte de um endereço baseado na geometria foi preenchido. Ainda há dois componentes indefinidos neste endereço — a cabeça e o setor. 5.2.1.2. Cabeça Nós estamos estritamente selecionando um prato específico do disco, mas, como cada superfície tem uma cabeça de acesso/gravação dedicada a ela, é mais fácil pensar em termos de interação com uma determinada cabeça. Na realidade, a essência eletrônica do dispositivo seleciona uma cabeça e — desseleciona o resto — somente interage com a cabeça selecionada durante a operação I/O. Todas as outras faixas que formam o cilindro corrente agora foram eliminadas. Cilindro Cabeça Setor 1014 2 X Tabela 5-2. Mapeamento do Armazenamento Na Tabela 5-2, as duas primeiras partes do endereço baseado na geometria foram preenchidos. Ainda há um componente final faltando neste endereço — o setor. 5.2.1.3. Setor Ao especificar um determinado setor, completamos o mapeamento e identificamos unicamente o bloco de dados desejado. Cilindro Cabeça Setor 1014 2 12 Tabela 5-3. Mapeamento do Armazenamento Na Tabela 5-3, o endereço baseado na geometria completo foi preenchido. Este endereço identifica a localidade de um bloco específico dentre todos os blocos deste dispositivo. 5.2.1.4. Problemas com Mapeamento Baseado na Geometria Apesar do mapeamento baseado na geometria ser simples, há uma área de ambiguidade que causa problemas — a numeração dos cilindros, cabeças e setores. É verdade que cada endereço baseado na geometria identifica unicamente um bloco de dados específico, mas isto se aplica somente se o esquema de numeração dos cilindros, cabeças e setores não Capítulo 5. Administrando o Armazenamento 63 for alterado. Se o esquema de numeração mudar (como mudar o hardware/software interagindo com o dispositivo de armazenamento), então o mapeamento entre os endereços baseados na geometria e seus blocos de dados correspondentes pode mudar, impossibilitando o acesso aos dados desejados. Devido esse potencial para ambiguidades, foi desenvolvida uma nova tática de mapeamento. A próxima seção descreve-a com mais detalhes. 5.2.2. Mapeamento Baseado no Bloco O mapeamento baseado no bloco é bem mais simples que o mapeamento baseado na geometria. No mapeamento baseado no bloco, cada bloco de dados recebe um número único. Esse número é passado do computador para o dispositivo de armazenamento em massa, que executa a conversão internamente para o endereço baseado na geometria, necessário pelo circuito de controle do dispositivo. Como a conversão para um endereço baseado na geometria é sempre feita pelo próprio dispositivo, é sempre consistente e elimina o problema de dar o mapeamento baseado na geometria ao dispositivo. 5.3. Interfaces do Dispositivo de Armazenamento em Massa Cada dispositivo usado num sistema de computador deve ter alguns meios de conectar-se ao sistema do computador. Esse ponto de conexão é conhecido como uma interface. Os dispositivos de armazenamento em massa não são diferentes — também têm interfaces. É importante saber sobre as interfaces por duas razões: • Há muitas interfaces diferentes (na maioria incompatíveis) • Interfaces diferentes têm características de desempenho e preços diferentes Infelizmente, não há uma única interface de dispositivo universal e muito menos uma única interface de dispositivo de armazenamento em massa. Sendo assim, os administradores de sistemas devem estar cientes da(s) interface(s) suportada(s) pelos sistemas de sua empresa. Caso contrário, há um risco real de adquirir o hardware errado ao planejar uma atualização (upgrade) dos sistemas. Interfaces diferentes têm capacidades de desempenho diferentes, o que torna algumas interfaces mais indicadas para determinados ambientes. Por exemplo: interfaces capazes de suportar dispositivos de alta velocidade são mais indicadas para ambientes de servidores, enquanto interfaces mais lentas são mais indicadas para o uso leve do desktop. Tais diferenças de desempenho também trazem diferenças nos preços, portanto você — como sempre — obtém aquilo que pagou. A computação de alto desempenho não é barata. 5.3.1. Histórico Ao longo dos anos, houve muitas interfaces diferentes criadas para dispositivos de armazenamento em massa. Algumas foram deixadas de lado e outras ainda estão em uso. No entanto, a seguinte lista é provida para se ter uma idéia do escopo do desenvolvimento das interfaces ao longo dos últimos trinta anos e para oferecer uma perspectiva das interfaces usadas hoje. FD-400 Uma interface originalmente desenvolvida para os drives de disco floppy de 8 polegadas em meados dos anos 70. Usava um cabo condutor 44 com um conector ’circuit board edge’ que fornecia energia e dados. 64 Capítulo 5. Administrando o Armazenamento SA-400 Uma outra interface de drive de disco floppy (desta vez, desenvolvida originalmente no fim dos anos 70 para o então novo drive de floppy de 5,25 polegadas). Usava um cabo condutor 34 com um conector socket padrão. Uma versão ligeiramente modificada desta interface ainda é usada hoje em dia para drives de disquetes de 5,25 e 3,5 polegadas. IPI Significa ’Intelligent Peripheral Interface’. Essa interface foi usada nos drives de disco de 8 e 14 polegadas, empregados em mini-computadores dos anos 70. SMD Um sucessor da IPI, o SMD (’Storage Module Device’) foi usado em discos rígidos de minicomputadores 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 proprietária, os dispositivos compatíveis com estas interfaces eram mais caros que seus dispositivos não proprietários equivalentes. Por causa disso, estas interfaces não tiveram popularidade à longo prazo. Apesar das interfaces proprietárias terem desaparecido em sua maioria, e as interfaces descritas no início desta seção não terem muito ou nenhum market share, é importante saber sobre estas interfaces que não são mais usadas, pois provam uma questão — nada permanece por muito tempo na indústria de computadores. Portanto, fique atento às novas tecnologias de interface. Um dia você pode descobrir que uma delas pode ser melhor para suas necessidades do que aquelas mais tradicionais que você usa. 5.3.2. Interfaces Padrão de Hoje Ao contrário das interfaces proprietárias mencionadas na seção anterior, algumas interfaces foram mais amplamente adotadas e transformaram-se nos padrões da indústria. Duas interfaces em particular sofreram essa transição e são o coração da indústria de armazenamento de hoje: • IDE/ATA • SCSI 5.3.2.1. IDE/ATA IDE significa ’Integrated Drive Electronics’. Essa interface tem origem no fim dos anos 80 e usa um conector de 40 pinos. Capítulo 5. Administrando o Armazenamento 65 Nota Na realidade, o nome apropriado dessa interface é "AT Attachment" (ou ATA), mas o termo "IDE" (que, na verdade, refere-se a um dispositivo de armazenamento em massa compatível com a ATA) ainda é usado. No entanto, o restante desta seção usa o nome apropriado da interface — ATA. A ATA implementa uma topologia de canal, com cada canal suportando dois dispositivos de armazenamento 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 inovaçã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 select" 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 transferê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 exemplo: "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 sensibilidade 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 é frequentemente 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 ajustado incorretamente para o mesmo ID SCSI que o controlador SCSI. Para resolver este problema, reconfigure o dispositivo para usar um ID SCSI diferente (e único). Como a arquitetura do SCSI é orientada ao canal, é necessário terminar apropriadamente ambas extremidades do canal. A terminação é feita ao alocar uma carga de impedância correta em cada condutor que compõe o canal SCSI. A terminação é um requisito elétrico; sem ela, os diversos sinais presentes no canal seriam perdidos pelas extremidades, distorcendo toda a comunicação. Muitos (mas não todos) dispositivos SCSI vêm com terminadores internos que podem ser ativados ou desativados usando interruptores ou jumpers. Terminadores externos também estão disponíveis. 5. A Rápida80 não representa uma mudança técnica na velocidade do canal; o canal de 40MHz foi mantido, mas os dados foram inseridos no início e fim de cada pulso do relógio, efetivamente dobrando o output. Capítulo 5. Administrando o Armazenamento 67 Uma última coisa para ter em mente sobre o SCSI — não é apenas um padrão de interface para dispositivos de armazenamento em massa. Muitos outros dispositivos (como scanners, impressoras e dispositivos de comunicação) usam SCSI. Apesar de serem menos comuns que os dispositivos de armazenamento em massa SCSI, eles existem. No entanto, é provável que, com o advento do USB e IEEE-1394 (frequentemente chamado de Firewire), estas interfaces sejam mais usadas para este tipo de dispositivo no futuro. Dica As interfaces USB e IEEE-1394 também estão começando suas incursões na arena do armazenamento em massa; no entanto, não existe nenhum dispositivo de armazenamento em massa USB ou IEEE-1394 no momento. As ofertas de hoje são baseadas nos dispositivos ATA ou SCSI com circuito de conversão externa. Não importa qual interface um dispositivo de armazenamento em massa usa; o funcionamento interno do dispositivo determina seu desempenho. A seção seguinte explora esta questão importante. 5.4. Características de Desempenho do Disco Rígido As características de desempenho do disco rígido foram introduzidas na Seção 4.2.4. Esta seção aborda a questão com maior profundidade. É importante que os administradores de sistemas a compreendam porque, sem o mínimo conhecimento básico de como os discos rígidos operam, é possível alterar a configuração de seu sistema inadvertidamente de modo a impactar negativamente seu desempenho. O tempo que leva para um disco rígido responder a e completar um pedido I/O depende de duas coisas: • As limitações mecânicas e elétricas do disco rígido • A carga I/O imposta pelo sistema As seções seguintes exploram estes aspectos do desempenho do disco rígido com mais detalhes. 5.4.1. Limitações Mecânicas/Elétricas Como os discos rígidos são dispositivos eletro-mecânicos, estão sujeitos a várias limitações em suas velocidades e desempenhos. Todo pedido I/O requer que os vários componentes do disco trabalhem juntos para satisfazê-lo. Já que cada um destes componentes têm características diferentes de desempenho, o desempenho geral do disco rígido é determinado pela soma do desempenho individual dos componentes. Entretanto, os componentes eletrônicos são pelo menos uma ordem de magnitude mais rápidos que os componentes mecânicos. Portanto, são os componentes mecânicos que têm o maior impacto no desempenho geral do disco rígido. Dica A maneira mais eficaz de melhorar o desempenho do disco rígido é reduzir sua atividade mecânica o máximo possível. 68 Capítulo 5. Administrando o Armazenamento O tempo médio de acesso de um disco rígido típico é aproximadamente 8,5 milissegundos. As seções a seguir explicam melhor este número, mostrando como cada componente impacta no desempenho geral do disco rígido. 5.4.1.1. Tempo de Processamento de Comandos Todos os discos rígidos produzidos hoje têm sistemas integrados controlando sua operação. Estes sistemas de computador executam as seguintes tarefas: • Interação com o mundo externo através da interface do disco rígido • Controle da operação do resto dos componentes do disco rígido e recuperação de quaisquer condições de erro que possam ocorrer • Processamento dos dados acessados da e gravados na mídia de armazenamento Mesmo que os microprocessadores usados nos discos rígidos sejam relativamente poderosos, as tarefas atribuídas a estes levam tempo para serem completas. Em média, este tempo é próximo a 0,003 milissegundos. 5.4.1.2. Cabeças Acessando/Gravando Dados As cabeças de acesso/gravação do disco rígido funcionam somente quando os pratos do disco sobre os quais elas "voam" estão rodando. Como é o movimento da mídia sob as cabeças que permite acessar ou ler os dados, o tempo que leva para a mídia contendo o setor desejado passar completamente por baixo da cabeça é o único determinante da contribuição da cabeça para o tempo total de acesso. A média é de 0,0086 milissegundos para um drive de 10.000 RPM com 700 setores por faixa. 5.4.1.3. Latência Rotacional Como os pratos do disco rígido estão girando continuamente, quando o pedido I/O chega, é pouco provável que o prato esteja exatamante no ponto certo de sua rotação para acessar o setor desejado. Consequentemente, mesmo que o resto do disco esteja pronto para acessar aquele setor, é necessário esperar até o prato girar, trazendo o setor desejado em posição sob a cabeça de acesso/gravação. Este é o motivo pelo qual os discos rígidos de alto desempenho tipicamente giram seus pratos a velocidades maiores. Hoje, as velocidades de 15.000 RPM são reservadas para os drives de desempenho mais alto, enquanto 5.400 RPM é considerada adequada somente para drives de nível básico. A velocidade média é de aproximadamente 3 milissegundos para um disco de 10.000 RPM. 5.4.1.4. Movimento do Braço de Acesso Se há um componente dos discos rígidos considerado o Tendão de Aquiles, este é o braço de acesso. O braço deve mover muito rápida e corretamente através de distâncias relativamente longas. Além disso, o movimento do braço de acesso não é contínuo — deve acelerar rapidamente ao se aproximar do cilindro desejado e então desacelerar rapidamente para evitar passar do ponto. Consequentemente, o braço de acesso deve ser forte (para suportar as forças violentas provocadas pela necessidade de movimentos rápidos) e leve ao mesmo tempo (para que haja menor massa para acelerar/desacelerar). É difícil atingir estes objetivos conflitantes, fato demonstrado pelo tempo relativamente longo que o movimento do braço de acesso leva quando comparado com o tempo que outros componentes levam. Sendo assim, o movimento do braço de acesso é o fator determinante principal do desempenho geral de um disco rígido; 5,5 milissegundos, em média. Capítulo 5. Administrando o Armazenamento 69 5.4.2. Cargas I/O e Desempenho Um outro fator que controla o desempenho do disco rígido é a carga I/O à qual o disco rígido é submetido. Veja alguns dos aspectos específicos à carga I/O: • A quantidade de acessos versus gravações • O número de leitores/gravadores corrente • A localidade dos acessos/gravações Estas questões são abordadas em detalhes nas próximas seções. 5.4.2.1. Acessos Versus Gravações No disco rígido comum usando mídia magnética para armazenamento de dados, o número de operações I/O de acesso (leitura) versus o número de operações I/O de gravação não é um fator preocupante, já que acessar e gravar dados leva o mesmo tempo6. Entretanto, outras tecnologias de armazenamento em massa levam tempos diferentes para processar acessos e gravações 7 . O impacto disso é que os dispositivos que levam um tempo mais longo para processar operações de acesso I/O (por exemplo) são capazes de lidar com menos I/Os de gravação que I/Os de acesso. Ou seja, uma I/O de gravação consome mais da habilidade do dispositivo em processar pedidos I/O que a I/O de acesso. 5.4.2.2. Leitores/Gravadores Múltiplos Um disco rígido que processa pedidos I/O a partir de fontes múltiplas tem uma carga diferente que um disco rígido que atende aos pedidos I/O a partir de somente uma fonte. A principal razão deve-se ao fato de que os solicitantes I/O múltiplos têm o potencial de trazer cargas I/O maiores para serem conduzidas num disco rígido que um único solicitante I/O. Isso ocorre porque o solicitante I/O deve executar um pouco de processamento antes que a I/O ocorra. Acima de tudo, o solicitante deve determinar a natureza do pedido I/O antes que possa ser executado. Como o processamento necessário para esta determinação leva tempo, há um limite máximo para a carga I/O que qualquer solicitante pode gerar— somente uma CPU mais rápida pode aumentá-lo. Esta limitação torna-se mais pronunciada se o solicitante requerer input humano antes de executar uma I/O. Entretanto, cargas I/O mais altas podem ser sustentadas com solicitantes múltiplos. Contanto que haja disponibilidade de energia suficiente da CPU para suportar o processamento necessário para gerar os pedidos I/O, adicionar mais solicitantes I/O aumenta a carga I/O resultante. No entanto, há outro aspecto que também influencia na carga I/O resultante. Isso é abordado na próxima seção. 6. Esta não é uma verdade absoluta. Todos os discos rígidos incluem alguma quantidade de memória cache na placa, usada para melhorar o desempenho de acesso. No entanto, qualquer pedido I/O para acessar dados deve, eventualmente, ser atendido ao ler fisicamente os dados pelo meio de armazenamento. Isso significa que, enquanto o cache pode aliviar os problemas de desempenho de acesso I/O, nunca pode eliminar o tempo necessário para acessar os dados fisicamente pelo meio de armazenamento. 7. Alguns drives de disco óptico apresentam este comportamento devido questões físicas das tecnologias usadas para implementar o armazenamento de dados óptico. 70 Capítulo 5. Administrando o Armazenamento 5.4.2.3. Localidade de Acessos/Gravações Apesar de não ser estritamente restrito a um ambiente multi-solicitante, este aspecto do desempenho do disco rígido tende a aparecer mais neste tipo de ambiente. A questão é se os pedidos I/O feitos de um disco rígido são de dados fisicamente próximos a outros dados que também estão sendo solicitados. A razão de sua importância torna-se aparente se a natureza eletromecânica do diso rígido é mantida em mente. O componente mais lento de qualquer disco rígido é o braço de acesso. Sendo assim, se os dados acessados pelos pedidos I/O de entrada não requerem movimentos do braço de acesso, o disco rígido é capaz de atender mais pedidos I/O do que se os dados estivessem espalhados por todo o disco, requerendo bastante movimento do braço de acesso. Isto pode ser ilustrado ao observar as especificações de desempenho do disco rígido. Estas especificações frequentemente incluem tempos de busca ao cilindro adjacente (onde o braço de acesso é pouco movido — somente para o próximo cilindro), e tempos de busca com força total (onde o braço de acesso é movido do primeiro cilindro ao último). Por exemplo: aqui estão os tempos de busca de um disco rígido de alto desempenho: Cilindro Adjacente Força Total 0.6 8.2 Tabela 5-4. Tempos de Busca ao Cilindro Adjacente e com Força Total (em Milissegundos) 5.5. Tornando o Armazenamento Utilizável Uma vez estabelecido um dispositivo de armazenamento em massa, há poucos fins para utilizá-lo. É verdade que os dados podem ser gravados neste e acessados deste, mas sem nenhuma estrutura básica, o acesso de dados só é possível ao usar endereços de setor (geométricos ou lógicos). São necessários métodos para facilitar a utilização do armazenamento não-processado provido pelo disco rígido. As seções seguintes exploram algumas técnicas comumente usadas para fazer isso. 5.5.1. Partições/Fatias Frequentemente, a primeira coisa que intriga um administrador de sistemas é que o tamanho do disco rígido pode ser bem maior que o necessário para uma determinada tarefa. Como resultado, muitos sistemas operacionais têm a capacidade de dividir o espaço de um disco rígido em várias partições ou fatias. Como são separadas umas das outras, as partições podem ter quantidades de espaço utilizado diferentes, e o espaço utilizado de uma partição não tem impacto na outra. Por exemplo: a partição contendo os arquivos que compoem o sistema operacional não é afetada pela partição contendo os arquivos do usuário, mesmo se esta estiver cheia. O sistema operacional continua com espaço livre para seu próprio uso. Apesar de ser um pouco simplista, você pode pensar nas partições como se fossem drives de disco separados. De fato, alguns sistemas operacionais referem-se às partições como "drives". No entanto, este ponto de vista não é totalmente correto; portanto é importante entendermos melhor as partições. 5.5.1.1. Atributos das Partições As partições são definidas pelos seguintes atributos: Capítulo 5. Administrando o Armazenamento • Geometria da partição • Tipo da partição • Campo do tipo da partição 71 Estes atributos são explorados com mais detalhes nas seções a seguir. 5.5.1.1.1. Geometria A geometria de uma partição refere-se à sua localização física num disco rígido. A geometria pode ser especificada em termos de cilindros inicial e final, cabeças e setores, mas geralmente as partições começam e terminam nos limites dos cilindros. O tamanho de uma partição é então definido como a quantidade de armazenamento entre os cilindros inicial e final. 5.5.1.1.2. Tipo da Partição O tipo da partição refere-se à sua relação com as outras partições no disco rígido. Há três tipos diferentes de partições: • Partições primárias • Partições extendidas • Partições lógicas Veja a descrição de cada tipo de partição nas próximas seções. 5.5.1.1.2.1. Partições Primárias As partições primárias são aquelas que ocupam um dos quatro slots primários na tabela de partições do disco rígido. 5.5.1.1.2.2. Partições Extendidas As partições extendidas foram desenvolvidas em resposta à necessidade de existir mais de quatro partições num disco rígido. Uma partição extendida pode conter diversas partições nela mesma, aumentando significativamente o número de partições possíveis num único disco. A introdução das partições extendidas foi movida pelas sempre crescentes capacidades de novos drives de disco. 5.5.1.1.2.3. Partições Lógicas As partições lógicas são aquelas contidas numa partição extendida. Em termos de uso, são iguais a uma partição primária não-extendida. 5.5.1.1.3. Campo do Tipo da Partição Cada partição tem um campo de tipo que contém um código indicando seu uso antecipado. O campo do tipo pode ou não refletir o sistema operacional do computador, mas reflete como os dados devem ser armazenados dentro da partição. A seção seguinte contém mais informações sobre isso. 72 Capítulo 5. Administrando o Armazenamento 5.5.2. Sistemas de Arquivo Mesmo tendo o dispositivo de armazenamento em massa apropriado, configurado corretamente e particionado apropriadamente, não poderíamos armazenar e recuperar informações facilmente — falta uma maneira de estruturar e organizar estas informações. Precisamos de um sistema de arquivo. O conceito de um sistema de arquivo é tão fundamental para o uso dos dispositivos de armazenamento em massa, que o usuário comum de computador geralmente não distingue um do outro. Entretanto, os administradores de sistemas não podem ignorar os sistemas de arquivo e seu impacto no trabalho do dia-a-dia. Um sistema de arquivo é um método de representação de dados num dispositivo de armazenamento em massa. Os sistemas de arquivo geralmente possuem as seguintes características: • Armazenamento de dados baseado em arquivos • Estrutura hierárquica de diretório (às vezes chamada de "pasta") • Registro de criação de arquivos, hora de acessos e de modificações. • Algum nível de controle sobre o tipo de acesso permitido a um determinado arquivo • Alguns conceitos sobre propriedade de arquivos (file ownership) • Contabilidade do espaço utilizado Nem todos os sistemas de arquivo possuem todas estas características. Por exemplo: um sistema de arquivo construído para um sistema operacional com um usuário único poderia facilmente utilizar um método de controle de acesso simplificado, e possivelmente acabar completamente com o suporte à propriedade de arquivo. Um ponto para ter em mente é que o sistema de arquivo usado pode ter um grande impacto na natureza da sua carga de trabalho diária. Ao garantir que o sistema de arquivo usado na sua empresa atende aos seus requisitos funcionais, você pode assegurar não somente que o sistema de arquivo é apropriado para a tarefa, mas também que é mais fácil e eficientemente mantido. Com isso em mente, as seções seguintes exploram estas características mais a fundo. 5.5.2.1. Armazenamento Baseado em Arquivo Apesar dos sistemas de arquivo que usam a metáfora do arquivo para armazenamento de dados serem quase tão universais a ponto de não serem valorizados, ainda há alguns aspectos a serem considerados. Primeiro, deve-se estar ciente de quaisquer restrições nos nomes dos arquivos. Por exemplo: quais os caracteres permitidos nos nomes de arquivos? Qual o tamanho máximo para o nome do arquivo? Estas questões são importantes, já que ditam os nomes de arquivos que podem ou não ser usados. Sistemas operacionais mais antigos com sistemas de arquivos mais primitivos frequentemente permitiam somente caracteres alfanuméricos (em caixa alta) e nomes de arquivo 8.3 tradicional (um nome de arquivo de 8 caracteres, seguido por uma extensão de arquivo de 3 caracteres). 5.5.2.2. Estrutura Hierárquica de Diretório Enquanto os sistemas de arquivo usados em alguns sistemas operacionais muito antigos não incluíam o conceito de diretórios, todos os sistemas de arquivo comumente usados hoje incluem esta característica. Os próprios diretórios são implementados como arquivos; o que significa que não é necessário nenhum utilitário especial para mantê-los. Além disso, como os diretórios são arquivos em si, e contém arquivos, também podem conter outros diretórios, possibilitando uma hierarquia de diretórios multi-nível. Este é um conceito essencial com o qual todos os administradores de sistemas devem ser famliarizados - usar hierarquias de diretórios multi-nível pode facilitar a administração de arquivos para você e seus usuários. Capítulo 5. Administrando o Armazenamento 73 5.5.2.3. Registro de Criação, Acessos e Hora de Modificação de Arquivos A maioria dos sistemas de arquivo mantém o registro da hora na qual o arquivo foi criado; alguns também registram a hora de modificação e de acesso. Além da conveniência de poder determinar quando um determinado arquivo foi criado, acessado ou modificado, estas datas são vitais para a operação apropriada de backups adicionais. Mais informações sobre como os backups utilizam estas características do sistema de arquivo podem ser encontradas na Seção 8.2. 5.5.2.4. Controle de Acesso O controle de acesso é uma área na qual os sistemas de arquivo diferem drasticamente. Alguns sistemas de arquivo não têm um modelo de controle simples, enquanto outros são bem mais sofisticados. Em termos gerais, os sistemas de arquivo mais modernos combinam dois componentes numa metodologia de controle de acesso coesa: • Identificação do usuário • Lista de ações permitidas Identificação do usuário significa que o sistema de arquivo, e seu sistema operacional, devem ser capazes de identificar unicamente usuários individuais. Isso possibilita ter responsabilidade total em relação a qualquer operação a nível do sistema. Uma outra característica muitas vezes útil é a dos grupos de usuários — criar conjuntos de usuários conforme as necessidades. Os grupos são geralmente mais usados por empresas nas quais os usuários podem ser membros de um ou mais projetos. Uma outra característica suportada por alguns sistemas de arquivo é a criação de identificadores genéricos que podem ser atribuídos a um ou mais usuários. Em seguida, o sistema de arquivo deve ser capaz de manter listas de ações permitidas (ou proibidas) em cada arquivo. As ações mais comuns são: • Acessar (ler) o arquivo • Gravar (escrever no) arquivo • Executar o arquivo Vários sistemas de arquivo talvez extendam a lista para incluir outras ações como exclusão (deleção), ou até mesmo a habilidade de alterar opções no controle de acesso de um arquivo. 5.5.2.5. Contabilidade do Espaço Utilizado Uma constante na vida de um administrador de sistemas é que nunca há espaço livre suficiente e, se houver, não permanecerá assim por muito tempo. Sendo assim, um administrador de sistemas deve pelo menos determinar facilmente o nível de espaço livre disponível para cada sistema de arquivo. Além disso, os sistemas de arquivo com capacidades de identificação de usuários bem definidas, geralmente incluem a capacidade de exibir a quantidade de espaço consumido por um determinado usuário. Esta funcionalidade é vital em ambientes grandes de multi-usuários, já que infelizmente a regra 80/20 geralmente se aplica ao espaço em disco — 20 porcento de seus usuários serão responsáveis por consumir 80 porcento do seu espaço disponível em disco. Ao determinar quais usuários estão nestes 20 porcento, fica mais fácil administrar seus bens de armazenamento efetivamente. Levando isso mais adiante, alguns sistemas de arquivo incluem a habilidade de determinar limites por usuário (geralmente conhecidos como quotas de disco) sobre a quantidade de espaço em disco que pode ser consumida. As especificações podem variar em diferentes sistemas de arquivo, mas em geral é possível atribuir a cada usuário uma determinada quantidade de armazenamento. Além disso, 74 Capítulo 5. Administrando o Armazenamento vários sistemas de arquivo diferem. Alguns permitem ao usuário exceder seu limite somente uma vez, enquanto outros implementam um "período de carência", durante o qual um segundo limite é aplicado. 5.5.3. Estrutura de Diretório Muitos administradores de sistemas não se importam como o armazenamento disponibilizado hoje será usado pelos seus usuários amanhã. No entanto, um pouco de foco nesta questão, antes de disponibilizar o armazenamento para os usuários, pode poupar bastante esforço desnecessário no futuro. A principal coisa que o administrador deve fazer é usar os diretórios e sub-diretórios para estruturar o armazenamento disponível de maneira inteligível. Há diversos benefícios nesta tática: • Mais fácilmente entendido • Mais flexibilidade no futuro Ao forçar um certo nível de estrutura no seu armazenamento, este pode ser mais facilmente entendido. Por exemplo: considere um grande sistema de multi-usuários. Ao invés de inserir todos os diretórios dos usuários em um diretório grande, pode fazer mais sentido usar sub-diretórios que espelham a estrutura de sua empresa. Dessa maneira, as pessoas que trabalham na contabilidade têm seus diretórios sob um outro diretório chamado contabilidade, as pessoas que trabalham na engenharia teriam seus diretórios sob engenharia e assim por diante. O benefício dessa tática é a facilidade de manter o registro diário de necessidades (e uso) do armazenamento de cada parte da sua empresa. Obter uma lista de arquivos usados por todos os funcionários dos recursos humanos é simples. Fazer o backup de todos os arquivos usados pelo departamento jurídico é fácil. Com a estrutura apropriada, a flexibilidade aumenta. Continuando o exemplo anterior, assuma por um momento que o departamento de engenharia está prestes a assumir novos projetos grandes. Por causa disso, muitos novos engenheiros serão contratados em breve. Entretanto, no momento não há armazenamento livre disponível para suportar as adições esperadas à engenharia. Mas, como todas as pessoas da engenharia têm seus arquivos armazenados sob o diretório engenharia, será um processo simples para: • Adquirir o armazenamento adicional necessário para suportar a engenharia • Fazer backup de tudo sob o diretório engenharia • Restaurar o backup para o novo armazenamento • Renomear • Fazer as alterações necessárias para que todo o pessoal de engenharia possa acessar seus arquivos no novo armazenamento o diretório engenharia no armazenamento original para algo como engenharia-arquivo (antes de apagá-lo inteiramente e após trabalhar sem problemas com a nova configuração por um mês) Obviamente, essa tática também tem suas desvantagens. Por exemplo: se as pessoas mudam de departamentos com frequência, você deve ter uma maneira de manter-se informado sobre estas transferências e então modificar a estrutura de diretório de acordo. Caso contrário, a estrutura não mais refletirá a realidade, aumentando o seu trabalho — e não diminuindo-o — a longo prazo. 5.5.4. Habilitando Acesso ao Armazenamento Uma vez que o dispositivo de armazenamento em massa foi particionado apropriadamente, e um sistema de arquivo foi gravado no mesmo, o armazenamento está disponível para o uso geral. Capítulo 5. Administrando o Armazenamento 75 Isto é verdade para alguns sistemas operacionais. Desde que o mesmo detecte o novo dispositivo de armazenamento em massa, pode ser formatado pelo administrador de sistemas e ser acessado imediatamente 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 normal do armazenamento é feita através de um utilitário ou programa especial e requer que o dispositivo de aremazenamento em massa (e possivelmente a partição também) seja explicitamente identificada. 5.6. Tecnologias de Armazenamento Avançado Apesar de tudo ser apresentado neste capítulo referenciando somente discos rígidos simples diretamente ligados a um sistema, há outras opções mais avançadas que você pode explorar. A seções seguintes descrevem algumas das táticas mais comuns para expandir as opções de seu armazenamento em massa. 5.6.1. Armazenamento Acessível via Rede Combinar as tecnologias de rede com o armazenamento em massa pode resultar em grande flexibilidade para administradores de sistemas. Há dois benefícios atingíveis com esse tipo de configuração: • Consolidação do armazenamento • Administração simplificada O armazenamento pode ser consolidado ao empregar servidores de alto desempenho com conectividade 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 compará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 centralizado podem ser menores que os gastos do armazenamento equivalente para cada um dos clientes. Além disso, o espaço livre é consolidado, ao invés de estar espalhado (e não amplamente utilizável) pelos diversos clientes. Os servidores de armazenamento centralizado também podem facilitar muitas tarefas administrativas. Por exemplo: monitorar o espaço livre é bem mais fácil quando o armazenamento a ser monitorado existe num servidor de armazenamento centralizado. Os backups podem ser bastante simplificados usando um servidor de armazenamento centralizado. É possível efetuar backups da rede para clientes múltiplos, mas requerem mais trabalho para configurar e manter. Há diversas tecnologias de armazenamento em rede disponíveis; escolher uma pode ser uma tarefa difícil. Quase todos os sistemas operacionais do mercado de hoje incluem alguns meios de acessar o armazenamento acessível pela rede, mas as diferentes tecnologias não são compatíveis umas com as outras. Qual é a melhor tática para determinar a tecnologia a empregar? A tática que geralmente traz os melhores resultados é deixar as capacidades embutidas do cliente decidirem a questão. Há inúmeras razões para isso: • Problemas minimizados com a integração de clientes • Trabalho minimizado em cada sistema cliente • Baixo custo inicial por cliente Tenha em mente que todas as questões relativas aos clientes são multiplicadas pelo número de clientes de sua empresa. Ao utilizar as capacidades embutidas dos clientes, você não precisa instalar nenhum software adicional em cada cliente (custo adicional zero com a compra de software). E você também tem a melhor chance de obter um bom suporte e integração com o sistema operacional do cliente. 76 Capítulo 5. Administrando o Armazenamento No entanto, há uma desvantagem. Isso significa que o ambiente de servidor deve estar apto a prover um bom suporte para as tecnologias de armazenamento acessíveis pela rede requisitadas pelos clientes. Nos casos em que os sistemas operacionais do servidor e dos clientes são um e o mesmo, normalmente não há prolemas. Caso contrário, será necessário investir tempo e trabalho em fazer com que o servidor "fale" a linguagem dos clientes. Entretranto, essa desvantagem é geralmente justificável. 5.6.2. Armazenamento Baseado no RAID Uma habilidade a ser cultivada pelo administrador de sistemas é poder olhar para configurações de sistemas complexos e observar as deficiências inerentes de cada configuração. Apesar de, à primeira vista, este parecer um ponto de vista negativo, pode ser uma grande maneira de analisar além das caixas brilhantes e visualizar uma noite de sábado com toda a produção derrubada devido uma falha que poderia ser facilmente evitada com um pouco de precaução. Com isso em mente, vamos usar o que sabemos agora sobre o armazenamento baseado no disco e verificar se podemos determinar as maneiras como os drives de disco podem causar problemas. Primeiro, considere uma falha completa no hardware: Um drive de disco com quatro partições tem uma pane geral: o que acontece com os dados contidos nestas partições? Ficam imediatamente indisponíveis (pelo menos até que a unidade falha possa ser substituída e os dados recuperados de um backup recente). Um drive de disco com uma única partição está operando em seus limites devido a enormes cargas I/O: o que acontece com as aplicações que requerem acesso aos dados dessa partição? As aplicações ficam lentas pois o drive de disco não pode processar os acessos e gravações mais rapidamente. Você tem um grande arquivo de dados aumentando de tamanho lentamente; em breve, será maior que o maior drive de disco no seu sistema. O que acontece então? O drive de disco é totalmente preenchido, o arquivo de dados para de aumentar e suas aplicações associadas param de rodar. Apenas um destes problemas poderia incapacitar um centro de dados, mesmo assim os administradores precisam enfrentar esse tipo de situação todos os dias. O que pode ser feito? Felizmente, há uma tecnologia que pode resolver cada uma destas questões. O nome dessa tecnologia é RAID. 5.6.2.1. Conceitos Básicos RAID é um acrônimo para Redundant Array of Independent Disks (Conjunto Redundante de Discos Independentes)8 . Como o nome implica, RAID é uma maneira para que drives múltiplos de disco atuem como se fossem um único drive de disco. As técnicas RAID foram primeiramente desenvolvidas por pesquisadores da Universidade de Berkeley, Califórnia, em meados dos anos 80. Ao mesmo tempo, havia uma diferença maior de preço entre os drives de disco de alto desempenho usados em grandes instalações de computadores da época, e drives de disco menores e mais lentos usados nos idos da indústria da computação. O RAID era visto como um método de substituir uma unidade de drive de disco cara por diversos drives de disco mais baratos. 8. No início das pesquisas sobre o RAID, o acrônimo significava Redundant Array of Inexpensive Disks (Discos Baratos), mas ao longo do tempo, os discos "independentes" que o RAID pretendia suplantar tornaram-se cada vez mais baratos, assim perdendo o significado da comparação de preços. Capítulo 5. Administrando o Armazenamento 77 Ainda mais importante: os conjuntos RAID podem ser construídos de diversas maneiras, resultando em características diferentes dependendo da configuração final. Vamos observar as diferentes configurações (conhecidos como níveis do RAID) com mais detalhes. 5.6.2.1.1. Níveis do RAID Os pesquisadores de Berkeley originalmente definiram cinco níveis diferentes do RAID e os numeraram de "1" a "5." Além disso, níveis adicionais do RAID foram definidos por outros pesquisadores e membros da indústria de armazenamento. Nem todos os níveis do RAID eram igualmente úteis; alguns interessavam somente aos propósitos dos pesquisadores, enquanto outros não eram economicamente viáveis. No final, apenas três níveis do RAID foram adotados para o uso geral: • Nível 0 • Nível 1 • Nível 5 As seções seguintes abordam cada um destes níveis em detalhes. 5.6.2.1.1.1. RAID 0 A configuração de disco conhecida como RAID nível 0 é um pouco confusa, já que é o único nível do RAID que não emprega nenhuma redundância. No entanto, mesmo que o RAID 0 não tenha vantagens sob o aspecto de confiabilidade, possui outros benefícios. Um conjunto RAID 0 consiste de dois ou mais drives de disco. A capacidade de armazenamento de cada drive é dividida em pedaços, que representam alguns múltiplos do tamanho de bloco nativo do drive. Os dados são gravados, pedaço por pedaço, em cada drive do conjunto. Os pedaços podem ser encarados como tiras (stripes, em inglês) ao longo de cada drive do conjunto; daí vem o outro termo para o RAID 0: striping. Por exemplo: com um conjunto de dois drives e pedaços com 4KB de tamanho, gravar 12KB de dados no conjunto resultaria na gravação de três pedaços de 4KB nos seguintes drives: • Os primeiros 4KB seriam gravados no primeiro pedaço do primeiro drive • Os 4KB seguintes seriam gravados no primeiro pedaço do segundo drive • Os últimos 4KB seriam gravados no segundo pedaço do primeiro drive Comparado a um drive de disco único, as vantagens do RAID 0 incluem: • Maior tamanho total — os conjuntos de RAID 0 podem ser construídos para serem maiores que um drive de disco único, facilitando armazenar maiores arquivos de dados • Melhor desempenho de acesso/gravação — A carga I/O num conjunto RAID 0 é espalhada igualmente por todos os drives do conjunto (assuimndo que todas I/O não estejam concentradas num único pedaço) • Sem espaço desperdiçado — Todo o armazenamento de todos os drives do conjunto estão disponíveis para o armazenamento de dados Comparado a um drive de disco único, o RAID 0 tem a seguinte desvantagem: • Menos confiabilidade — Todo drive de um conjunto de RAID 0 deve estar operante para o conjunto estar disponível. Uma única falha no conjunto RAID 0 drive-N resulta na remoção de 1/N de todos os dados, inutilizando o conjunto 78 Capítulo 5. Administrando o Armazenamento Dica Se você tiver problemas em memorizar os diferentes níveis do RAID, lembre-se apenas que o RAID 0 tem zero porcento de redundância. 5.6.2.1.1.2. RAID 1 O RAID 1 usa dois (apesar de algumas implementações suportarem mais) drives de disco idênticos. Todos os dados são gravados nos dois drives, tornando-os imagem espelho um do outro. Por isso, o RAID 1 é comumente conhecido como mirroring. Sempre que os dados são gravados num conjunto de RAID 1, ocorrem duas gravações físicas: uma no primeiro drive e outra no segundo drive. Por outro lado, o acesso aos dados precisa ocorrer somente uma vez em qualquer drive do conjunto. Comparado a um drive de disco único, o conjunto de RAID 1 tem as seguintes vantagens: • Melhor redundância — Mesmo se um drive do conjunto falhar, os dados ainda estarão acessíveis • Melhor desempenho de acesso — Com ambos drives operantes, os acessos podem ser divididos igualmente entre eles, reduzindo as cargas I/O por drive Quando comparado a um drive de disco único, o conjunto de RAID 1 tem algumas desvantagens: • O tamanho máximo do conjunto é limitado pelo maior drive disponível. • Desempenho de gravação reduzido — Como os dois drives devem ser mantidos atualizados, todas as I/Os devem ser desempenhadas pelos dois drives, atrasando o processo geral de gravação de dados no conjunto • Relação custo/eficiência reduzida — Com um drive inteiro dedicado à redundância, o custo de um conjunto de RAID 1 é, no mínimo, o dobro de um único drive Dica Se você tiver problemas em memorizar os diferentes níveis do RAID, lembre-se que o RAID 1 tem cem porcento de redundância. 5.6.2.1.1.3. RAID 5 O RAID 5 tenta combinar os benefícios do RAID 0 e do RAID 1 e minimizar suas respectivas desvantagens. 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 armazenado 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 nenhum drive do conjunto, mas estão espalhados igualmente por todos os drives. Apesar de ser possível dedicar um drive específico para conter apenas paridade (de fato, esta configuração é conhecida como RAID nível 4), a atualização constante da paridade conforme os dados são gravados no conjunto pode transformar o drive de paridade num gargalo de desempenho. Ao espalhar as informações de paridade igualmente pelo conjunto, este impacto é reduzido. No entanto, é importante ter em mente o impacto da paridade na capacidade de armazenamento total do conjunto. Mesmo que as informações de paridade sejam espalhadas igualmente por todos os drives do conjunto, a quantidade de armazenamento disponível é reduzida para o tamanho de um drive. Comparado a um drive de disco único, o conjunto de RAID 5 tem as seguintes vantagens: • Mais redundância — Se um drive do conjunto falhar, as informações de paridade podem ser usadas para reconstruir os pedaços de dados faltando, enquanto mantém-se o conjunto disponível para uso 9 • Melhor desempenho de acesso — Devido sua semelhança com o RAID 0, os dados são divididos entre os drives do conjunto e a atividade de acesso I/O é espalhada igualmente por todos os drives • Relação custo/eficiência razoavelmente boa — Em um conjunto de RAID 5 com n drives, somente 1/n do armazenamento total é dedicado à redundância. Comparado a um drive único, um conjunto de RAID 5 tem a seguinte desvantagem: • Desempenho de gravação reduzido — Como cada gravação no conjunto resulta em pelo menos duas gravações nos drives físicos (uma gravação para os dados e outra para a paridade), o desempenho de gravação é pior do que num drive único10 5.6.2.1.1.4. Níveis Embutidos do RAID A partir da abordagem dos vários níveis do RAID, fica claro que cada nível tem suas próprias vantagens e desvantagens. Pouco tempo depois que o armazenamento baseado no RAID começou a ser usado, as pessoas começaram a pensar em combinar os diferentes níveis do RAID, produzindo conjuntos com todas as vantagens e nenhuma desvantagem dos níveis originais. Por exemplo: e se os drives de disco de um conjunto de RAID 0 fossem, na verdade, conjuntos de RAID 1? Isso traria as vantagens de velocidade do RAID 0, com a confiabilidade do RAID 1. Esse é o tipo de coisa que pode ser feita. Aqui estão os níveis embutidos de RAID mais comuns: • RAID 1+0 • RAID 5+0 • RAID 5+1 9. O desempenho I/O é reduzido enquanto operar com um drive indisponível, devido à sobrecarga envolvida na reconstrução dos dados faltantes. 10. Também há impacto dos cálculos de paridade necessários para cada gravação. Mas, dependendo da implementaçã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 embutidas de RAID, essa é o custo. Por exemplo: o menor conjunto de RAID 5+1 consiste de seis drives de disco (são necessários ainda mais drives para conjuntos maiores). Agora que explicamos os conceitos por trás do RAID, vejamos como pode ser implementado. 5.6.2.1.2. Implementações do RAID Em comparação com as seções anteriores, é óbvio que o RAID requer mais "conhecimento" que o processamento I/O de disco comum para drives individuais. No mínimo, as seguintes tarefas devem ser executadas: • Dividir os pedidos I/O de entrada entre os discos do conjunto • Para o RAID 5, calcular a paridade e gravá-la no drive apropriado no conjunto • Monitorar os discos separadamente no conjunto e tomar as devidas ações caso um deles falhar • Controlar a recriação de um disco separado no conjunto, quando este disco for substituído ou reparado • Prover uma maneira para os administradores manterem o conjunto (remover ou adicionar drives, iniciar e terminar recriações, etc.) Há dois métodos principais que podem ser usados para completar estas tarefas. As próximas duas seções descrevem-nos em detalhes. 5.6.2.1.2.1. RAID de Hardware Uma implementação de RAID de hardware geralmente toma a forma de uma placa especializada de controle do disco. A placa executa todas as funções relativas ao RAID e controla diretamente os drives separadamente nos conjuntos conectados a esta. Com o driver apropriado, os conjuntos administrados por uma placa de RAID de hardware aparecem como drives de disco comuns para o sistema operacional da máquina. A maioria das placas de controlador de RAID funcionam com drives SCSI, mas há também controladores RAID baseados na ATA. Em qualquer caso, a interface administrativa é geralmente implementada de uma destas três maneiras: • Utilitários especializados, que rodam como aplicações sob o sistema operacional da máquina, apresentando uma interface de software à placa do controlador • Uma interface da placa usando uma porta serial, que é acessada através de um emulador de terminal • Uma interface parecida com o BIOS, acessível somente durante o teste de inicialização do sistema Alguns controladores RAID têm mais de um tipo de interface administrativa. Por motivos óbvios, uma interface de software provém mais flexibilidade, já que permite funções administrativas enquanto o sistema operacional está rodando. No entanto, se você inicializar um sistema operacional a partir de um controlador RAID, é necessária uma interface que não requer um sistema operacional rodando. Como há diversas placas de controlador RAID diferentes no mercado, é impossível entrar em mais detalhes aqui. O melhor a fazer é ler a documentação do fabricante para mais informações. Capítulo 5. Administrando o Armazenamento 81 5.6.2.1.2.2. RAID de Software O RAID de software é o RAID implementado como um kernel - ou software de nível de driver para um sistema operacional específico. Como tal, provém mais flexibilidade em termos de suporte a hardware — desde que o hardware seja suportado pelo sistema operacional, os conjuntos RAID podem ser configurados e empregados. Isto pode reduzir o custo de emprego do RAID drasticamente, eliminando a necessidade de hardware caro especializado de RAID. Frequentemente, o excesso de energia da CPU disponível para os cálculos de paridade do RAID de software excede o poder de processamento presente numa placa de controlador RAID. Consequentemente, algumas implementações de RAID de software têm, na verdade, a capacidade de desempenho superior que implementações de RAID de hardware. Entretanto, o RAID de software tem limitações ausentes do RAID de hardware. A mais importante a considerar é o suporte para inicializar a partir de um conjunto de RAID de software. Na maioria dos casos, somente os conjuntos RAID 1 podem ser usados para inicialização, já que o BIOS do computador não sabe do RAID. Como um drive único de um conjunto de RAID 1 é indiferenciável de um dispositivo de inicialização não-RAID, o BIOS pode iniciar o processo de inicialização; então, o sistema operacional pode alternar para a operação de RAID de software quando obtiver o controle do sistema. 5.6.3. Administração de Volume Lógico (Logical Volume Management) Uma outra tecnologia avançada de armazenamento é a administração de volume lógico (logical volume management - LVM). O LVM possibilita tratar dispositivos físicos de armazenamento em massa como blocos de construção de nível baixo, nos quais são criadas configurações de armazenamento diferentes. As capacidades exatas variam de acordo com a implementação específica, mas podem incluir agrupamento de armazenamento físico, redimensionamento de volume lógico e migração de dados. 5.6.3.1. Agrupamento de Armazenamento Físico Apesar do nome dado a esta capacidade variar, o agrupamento de armazenamento físico é a base de todas as implementações do LVM. Como o nome implica, os dispositivos físicos de armazenamento em massa podem ser agrupados de maneira a criar um ou mais dipositivos lógicos de armazenamento em massa. Os dispositivos lógicos de armazenamento em massa (ou volumes lógicos) podem ter capacidade maior que a maior capacidade de qualquer um dos dispositivos físicos de armazenamento em massa que compõe o volume. Por exemplo: dados dois drives de 100GB, pode-se criar um volume lógico de 200GB. No entanto, também pode-se criar um volume lógico de 150GB e um de 50GB. Qualquer combinação de volumes lógicos igual ou menor que a capacidade total (200GB nestes exemplo) é possível. As alternativas são limitadas apenas pelas necessidades da sua empresa. Isso possibilita a um administrador de sistemas tratar todo o armazenamento como parte de um conjunto, disponível para uso em qualquer quantidade. Além disso, os drives podem ser adicionados posteriormente ao conjunto, facilitando o processo de antecipar a demanda de armazenamento de seus usuários. 5.6.3.2. Redimensionamento do Volume Lógico A característica do LVM admirada pela maioria dos administradores de sistemas é sua habilidade em direcionar armazenamento facilmente onde é necessário. Numa configuração de sistema sem LVM, estar sem espaço significa — no melhor dos casos — mover arquivos do dispositivo cheio para outro 82 Capítulo 5. Administrando o Armazenamento com espaço disponível. Isto pode significar reconfigurar os dispositivos de armazenamento em massa de seu sistema; uma tarefa a ser executada após o horário comercial. Entretanto, o LVM possibilita aumentar o tamanho de um volume lógico. Assuma por um momento que nosso conjunto de armazenamento de 200GB foi usado para criar um volume lógico de 150GB, com os 50GB restantes na reserva. Se o volume lógico de 150GB ficar cheio, o LVM possibilita aumentar esse tamanho (digamos em 10GB) sem nenhuma reconfiguração física. Dependendo do ambiente do sistema operacional, pode ser possível fazer isso dinamicamente ou pode ser necessário deixar o sistema fora do ar por pouco tempo para executar o redimensionamento. 5.6.3.3. Migração de Dados A maioria dos administradores de sistemas experientes ficariam impressionados com as capacidades do LVM, mas também se perguntaria a seguinte questão: O que acontece se um dos drives que compõe o volume lógico começa a falhar? A boa notícia é que a maioria das implementações do LVM incluem a habilidade de migrar dados de um drive físico específico. Para que isso funcione, deve haver capacidade reserva suficiente para absorver a perda do drive falho. Uma vez completa a migração dos dados, o drive falho pode ser substituído ou trazido de volta ao conjunto de armazenamento disponível. 5.6.3.4. Com LVM, por que usar RAID? Dado que o LVM tem algumas funcionalidades similares às do RAID (a habilidade de substituir drives falhos dinamicamente, por exemplo), e algumas funcionalidades provendo capacidades que não podem ser atingidas pelas maioria das implementações do RAID (como a habilidade de adicionar armazenamento dinamicamente a um conjunto de armazenamento central), muitas pessoas questionam se o RAID ainda é importante. Nada poderia estar mais distante da verdade. RAID e LVM são tecnologias complementares que podem ser usadas em conjunto (similar ao uso dos níveis embutidos do RAID), possibilitando obter o melhor de cada uma. 5.7. Administração Diária do Armazenamento Os administradores de sistemas devem estar atentos ao armazenamento no curso de suas rotinas diárias. Há diversas questões para ter em mente: • Monitorar espaço livre • Questões de quota de disco • Questões relativas a arquivos • Questões relativas a diretórios • Questões relativas a backups • Questões relativas a desempenho • Adicionando/removendo armazenamento As seções seguintes abordam cada uma destas questões com detalhes. Capítulo 5. Administrando o Armazenamento 83 5.7.1. Monitorando Espaço Livre Garantir que haja suficiente espaço livre disponível deve estar no topo da lista de tarefas diárias de um administrador de sistemas. A razão da verificação frequente e regular do espaço livre é tão importante porque o espaço livre é muito dinâmico; pode haver mais do que o espaço suficiente num momento, e praticamente nenhum em seguida. Em geral, há três razões para espaço livre insuficiente: • Uso excessivo por um usuário • Uso excessivo por uma aplicação • Crescimento normal de uso Estas razões são abordadas em detalhes nas próximas seções. 5.7.1.1. Uso Excessivo por um Usuário Pessoas diferentes têm níveis diferentes de organização. Algumas pessoas ficariam aterrorizadas em ver um pouco de pó sobre uma mesa, enquanto outras não pensariam duas vezes em ter uma pilha de caixas de pizza do ano passado ao lado do sofá. O mesmo ocorre com o armazenamento: • Algumas pessoas são muito frugais no uso de seu armazenamento e nunca largam arquivos desnecessários por aí. • Algumas pessoas parecem nunca encontrar tempo para livrar-se dos arquivos de que não mais precisam. Muitas vezes, quando um usuário usa grandes quantidades de armazenamento, o segundo tipo de pessoa é a responsável. 5.7.1.1.1. Resolvendo o Uso Excessivo por um Usuário Essa é uma área na qual o administrador de sistemas precisa usar toda a diplomacia e habilidades sociais que puder obter. Frequentemente, as discussões sobre espaço em disco tornam-se emocionais, já que as pessoas encaram as restrições de uso do disco como um fator limitante para seu trabalho, dizem que as restrições são pequenas ou que simplesmente não têm tempo de fazer uma limpeza em seus arquivos. Os melhores administradores de sistemas consideram muitos fatores numa situação como essa. As restrições são razoáveis e justas para o tipo de trabalho que essa pessoa executa? Essa pessoa parece usar seu espaço em disco apropriadamente? Você pode ajudá-la a reduzir o uso do disco de alguma maneira (criando um CD-ROM com backup de todos os e-mails com mais de um ano, por exemplo)? O seu trabalho durante as conversas é tentar descobrir se este é realmente o caso, enquanto garante que alguém que não precisa de tanto espaço esteja limpando seus arquivos. Em qualquer dos casos, a melhor coisa a fazer é manter uma conversa em nível profissional e factual. Tente resolver os problemas do usuário de uma maneira educada ("Eu entendo que você esteja muito ocupado, mas todos em seu departamento têm a mesma responsabilidade em não desperdiçar espaço de armazenamento, e a média de uso é menos que a metade do seu.") enquanto encaminha a conversa para a questão. Certifique-se de oferecer ajuda caso a falta de conhecimento/experiência for um problema. Lidar com a situação de maneira sensível porém firme, geralmente é melhor que usar sua autoridade como administrador de sistemas para forçar um resultado. Por exemplo: talvez você acredite ser necessária uma concessão entre você e o usuário. Essa concessão pode ter uma destas três formas: • Prover espaço temporário • Criar backups de arquivamento 84 • Capítulo 5. Administrando o Armazenamento Desistir Talvez você acredite que o usuário possa reduzir seu uso se tiver alguma quantidade de espaço temporário que possa usar sem restrições. As pessoas que geralmente se aproveitam desta situação descobrem 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 permanente. Deixe bem claro que o espaço oferecido é temporário e que não há possibilidade de garantir datas de retenção dos arquivos; backups de dados em espaço temporário nunca são feitos. Na verdade, muitos administradores de sistemas frequentemente enfatizam esse fato apagando automaticamente todos os arquivos em armazenamento temporário com mais de uma determinada idade (uma semana, por exemplo). Em outros casos, o usuário pode ter muitos arquivos obviamente antigos que provavelmente não precisa acessar continuamente. Garanta de comunicar essa questão se for o caso. Às vezes, alguns usuários são responsáveis por manter um arquivo com dados antigos; nestes casos, você deve ajudá-los nessa tarefa provendo diversos backups tratados de maneira diferente que os backups de arquivamento de seu centro de dados. Entretanto, há situações nas quais os dados têm valor dúbio. Nestes casos, talvez você ache melhor oferecer a produção de um backup especial para eles. Então, você faz o backup dos dados antigos e entrega a mídia de backup ao usuário, explicando que ele é responsável por mantê-la segura e que, se precisar acessar quaisquer dados, peça a você (ou aos funcionários de operações — o que for melhor para a empresa) para recuperá-los. Há algumas coisas para manter em mente para que a situação não se oponha a você. Primeiro e mais importante: não inclua arquivos que provavelmente precisarão de recuperação; não selecione arquivos muito novos. Em seguida, certifique-se da capacidade de executar uma recuperação caso seja necessária algum dia. Isso significa que a mídia de backup deve ser de um tipo a ser usado pelo seu centro de dados no futuro. Dica Sua escolha da mídia de backup também deve considerar as tecnologias que possibilitam aos próprios usuários executar a recuperação dos dados. Por exemplo: mesmo que fazer o backup de muitos gigabytes em um CD-ROM seja mais trabalhoso que invocar um simples comando e enviálos a um cartucho de filta de 20GB, considere que o usuário pode acessar os dados do CD-ROM quando quiser — sem precisar do seu envolvimento. 5.7.1.2. Uso Excessivo por uma Aplicação Às vezes, uma aplicação é responsável por uso excessivo. As razões podem variar, mas podem incluir: • Melhorias na funcionalidade da aplicação requerem mais armazenamento • Um aumento do número de usuários que usam a aplicação • A aplicação falha em fazer a limpeza após terminada, deixando arquivos temporários desnecessários no disco Capítulo 5. Administrando o Armazenamento • 85 A aplicação está com código quebrado e o erro faz com que esta use mais armazenamento do que deveria Sua tarefa é determinar quais dos motivos dessa lista se aplicam à sua situação. Estar ciente do status das aplicações usadas em seu centro de dados deve ajudá-lo a eliminar diversos motivos, assim como deve acontecer com a ciência dos hábitos de processamento de seus usuários. O que resta a fazer frequentemente é um pouco de trabalho de detetive para descobrir para onde foi o armazenamento. Isso deve reduzir substancialmente o campo. Neste ponto, você deve tomar as ações apropriadas, seja adicionar armazenamento para suportar uma aplicação de uso crescente, contatar os desenvolvedores da aplicação para debater sobre suas características de processamento, ou escrever scripts para efetuar a limpeza após a aplicação. 5.7.1.3. Crescimento Normal do Uso A maioria das empresas vivencia algum nível de crescimento ao longo do tempo. Por causa disso, é normal esperar que a utilização do armazenamento aumente numa velocidade similar. Em praticamente todas as circunstâncias, o monitoramento constante pode revelar a taxa média da utilização do armazenamento em sua empresa; essa taxa pode então ser usada para determinar o tempo no qual o armazenamento adicional deve ser adquirido antes que seu espaço livre acabe. Se acontecer de acabar seu espaço livre inesperadamente devido o crescimento normal, você não fez seu trabalho corretamente. No entanto, podem ocorrer grandes demandas adicionais ao armazenamento de seus sistemas inesperadamente. Sua empresa pode ter sido unida com outra, requerendo alterações rápidas na infra-estrutura de TI (e, portanto, no armazenamento). Um novo projeto de alta prioridade pode ter surgido durante a noite. As alterações numa aplicação existente podem resultar em necessidades de armazenamento bem maiores. Não importa o motivo; às vezes você é pego de surpresa. A fim de planejar para estes imprevistos, tente configurar sua arquitetura de armazenamento para a máxima flexibilidade. Manter armazenamento reserva (se possível) pode aliviar o impacto destes eventos não-planejados. 5.7.2. Questões de Quota de Disco Muitas vezes, a primeira coisa que a maioria das pessoas pensa ao analisar as quotas de disco é usálas para forçar os usuários a manterem seus diretórios limpos. Enquanto há situações nas quais isso funciona, também ajuda a observar o problema de uso do espaço em disco sob outra perspectiva. E as aplicações que, por algum motivo, consomem muito espaço em disco? É sabido que algumas aplicações falham de modo a consumirem todo o espaço disponível em disco. Nestes casos, as quotas de disco podem limitar o estrago causado por estas aplicações, forçando-as a parar antes de acabar todo o espaço livre no disco. A parte mais difícil da implementação e administração das quotas de disco refere-se aos próprios limites. Quais devem ser os limites? Uma tática simplista seria dividir o espaço em disco pelo número de usuários e/ou grupos utilizando-o, e fixar o valor resultante como a quota por usuário. Por exemplo: se o sistema tem um drive de disco de 100GB e 20 usuários, cada usuário deve receber uma quota de disco de, no máximo, 5GB. Dessa maneira, cada usuário teria a garantia de 5GB (apesar do disco estar 100% cheio neste ponto). Para os sistemas operacionais que as suportam, é possível determinar quotas temporárias um pouco mais altas — digamos 7,5GB, com a quota permanente ainda em 5GB. O benefício é permitir que os usuários consumam permanentemente não mais que suas porcentagens do disco, mas ainda permitindo alguma flexibilidade quando um usuário atingir (e exceder) seu limite. Ao utilizar quotas de disco dessa maneira, você está super-comprometendo o espaço disponível em disco. A quota temporária é 86 Capítulo 5. Administrando o Armazenamento 7,5GB. Se todos os usuários excederem suas quotas permanentes ao mesmo tempo e tentarem atingir suas quotas temporárias, aquele disco de 100GB teria que ter 150GB. No entanto, nem todos excedem suas quotas permanentes ao mesmo tempo, possibilitando a tática de algum super-comprometimento. Obviamente, a seleção de quotas permanentes e temporárias cabe ao administrador de sistemas, já que cada operação e comunidade de usuários são diferentes. 5.7.3. Questões Relativas a Arquivos Os administradores de sistemas frequentemente lidam com questões relativas a arquivos. Estas questões incluem: • Acesso a Arquivos • Compartilhamento de Arquivos 5.7.3.1. Acesso a Arquivos As questões relacionadas ao acesso de arquivos tipicamente ocorrem em um cenário — um usuário não consegue acessar um arquivo que acredita poder acessar. Frequentemente, é o caso do usuário 1 querendo enviar uma cópia de um arquivo ao usuário 2. Na maioria das empresas, a habilidade de um usuário acessar os arquivos de outro é estritamente limitada, acarretando neste problema. Há três táticas que podem ser usadas: • O usuário 1 efetua as alterações necessárias para permitir ao usuário 2 acessar o arquivo onde quer que esteja localizado. • Cria-se uma área de intercâmbio de arquivos para esse propósito; o usuário 1 copia o arquivo ali, que então pode ser copiado pelo usuário 2. • O usuário 1 usa o e-mail para enviar uma cópia do arquivo ao usuário 2. Há um problema com a primeira tática — dependendo de como o acesso é atribuído, o usuário 2 pode ter acesso total a todos os arquivos do usuário 1. Pior: pode ser feito de maneira a permitir que todos os usuários de sua empresa acessem os arquivos do usuário 1. Pior ainda: esta alteração pode não ser revertida após o usuário 2 não querer mais o acesso, deixando os arquivos do usuário 1 permanentemente acessíveis aos outros. Infelizmente, quandos os usuários se encontram nestas situações, a segurança raramente é sua prioridade mais alta. A segunda tática elimina o problema de tornar todos os arquivos do usuário 1 acessíveis aos outros. Entretanto, uma vez que o arquivo encontra-se na área de intercâmbio, este é legível (e, dependendo das permissões, até gravável) por todos os outros usuários. Essa tática também cria a possibilidade da área de intercâmbio tornanar-se cheia de arquivos, conforme os usuários esquerecem de limpá-la. A terceira tática, apesar de aparentemente bizarra, pode ser a preferida na maioria dos casos. Com o advento dos protocolos de anexos de e-mail e programas mais inteligentes, enviar todo tipo de arquivo via e-mail é uma operação mais segura e não requer nenhum envolvimento do administrador de sistemas. Obviamente, existe a possibilidade de um usuário tentar enviar por e-mail um arquivo de banco de dados de 1GB para todas as 150 pessoas do departamento de finanças, portanto um pouco de educação aos usuários (e possivelmente limitações ao tamanho do anexo) é prudente. Mesmo assim, nenhuma destas táticas lidam com a situação de um ou mais usuários precisarem de acesso contínuo ao mesmo arquivo. Nestes casos, é necessário utilizar outros métodos. Capítulo 5. Administrando o Armazenamento 87 5.7.3.2. Compartilhamento de Arquivos Quando usuários múltiplos precisam compartilhar a mesma cópia de um arquivo, permitir o acesso ao alterar as permissões do arquivo não é a melhor solução. É preferível formalizar o estado compartilhado do arquivo. Há diversas razões para isto: • Os arquivos compartilhados fora do diretório de um usuário são vulneráveis a desaparecerem inesperadamente quando o usuário deixa a empresa ou simplesmente efetua a organização usual de seus arquivos. • Torna-se difícil manter o acesso compartilhado para mais de um ou dois usuários adicionais, levando ao problema a longo termo de trabalho desnecessário sempre que os usuários compartilhando tiverem suas responsabilidades alteradas. Portanto, a tática preferida é: • O usuário original abdicar da propriedade direta do arquivo • Criar um grupo que terá a propriedade do arquivo • Colocar o arquivo num diretório compartilhado de propriedade do grupo • Tornar todos os usuários, que precisam de acesso ao arquivo, membros do grupo Obviamente, essa tática funciona bem tanto com arquivos múltiplos como com um único arquivo e pode ser usada para implementar o armazenamento compartilhado para projetos grandes e complexos. 5.7.4. Adicionando/Removendo Armazenamento Devido a necessidade incessante de espaço adicional em disco, um administrador de sistemas precisa adicionar espaço ao disco frequentemente, enquanto também remove alguns drives menores e mais antigos. Esta seção traz uma visão geral do processo básico de adição e remoção de armazenamento. Nota Em diversos sistemas operacionais, os dispositivos de armazenamento em massa são nomeados de acordo com suas conexões físicas ao sistema. Consequentemente, adicionar ou remover dispositivos de armazenamento em massa pode resultar em alterações inesperadas nos nomes dos dispositivos. Ao adicionar ou remover armazenamento, certifique-se de rever (e atualizar, se necessário) todas as referências de nome usadas pelo seu sistema operacional. 5.7.4.1. Adicionando Armazenamento O processo de adicionar armazenamento a um sistema é relativamente simples. Aqui estão os passos básicos: 1. Instalando o hardware 2. Particionando 3. Formatando a(s) partição(ões) 4. Atualizando a configuração do sistema 5. Modificando o agendamento de backup As seções seguintes abordam cada passo em detalhes. 88 Capítulo 5. Administrando o Armazenamento 5.7.4.1.1. Instalando o Hardware Antes de qualquer outra coisa, o novo drive de disco deve estar alocado e acessível. Apesar de existirem muitas configurações de hardware possíveis, as seções a seguir abordam as duas situações mais comuns — adicionar um drive de disco ATA ou SCSI. Os passos básicos aqui abordados podem ser aplicados em outras configurações. Dica Não importa qual hardware de armazenamento você usa; deve sempre considerar a carga que um novo drive de disco adiciona ao sub-sistema I/O de seu computador. Em geral, você deve tentar distribuir a carga I/O do disco por todos os canais disponíveis. Do ponto de visto de desempenho, isso é bem melhor que colocar todos os drives de disco em um canal e deixar o outro vazio e inativo. 5.7.4.1.1.1. Adicionando Drives de Disco ATA Os drives de disco ATA são usados principalmente nos computadores de mesa (desktops) e sistemas de servidores lower-end. Praticamente todos os sistemas destas categorias têm controladores ATA embutidos com canais ATA múltiplos — normalmente dois ou quatro. Cada canal pode suportar dois dispositivos — um mestre e um escravo. Os dois dispositivos são conectados ao canal através de um único cabo. Portanto, o primeiro passo é verificar quais canais têm espaço disponível para um drive de disco adicional. Teremos uma das três situações: • Há um canal com apenas um drive de disco conectado • Há um canal sem nenhum drive de disco conectado • Não há espaço disponível A primeira situação geralmente é a mais fácil de lidar, e é provável que o cabo já conectado tenha um conector não utilizado ao qual o novo drive de disco pode ser plugado. Entretanto, se o cabo tiver somente dois conectores (um para o canal e outro para o drive de disco já instalado), é necessário substituir o cabo existente por um modelo de três conectores. Antes de instalar o novo drive de disco, certifique-se que os dois drives de disco compartilhando o canal estejam configurados apropriadamente (um como mestre e outro como escravo). A segunda situação é um pouco mais difícil somente pelo fato de que deve-se adquirir um novo cabo para poder conectar um drive de disco ao canal. O novo drive de disco pode ser configurado como mestre ou escravo (apesar do primeiro drive de disco de um canal ser normalmente configurado como mestre). Na terceira situação, não há espaço remanescente para um drive de disco adicional. Sendo assim, você deve tomar uma decisão: • Adquirir uma placa de controlador ATA e instalá-la • Substituir um dos drives de disco instalados por um novo e maior Adicionar uma placa de controlador abrange verificar a compatibilidade do hardware, a capacidade física e a compatibilidade do software. Em suma, sua placa precisa ser compatível com os slots dos canais de seu computador. Deve haver um slot aberto para a placa, que deve ser suportada pelo seu sistema operacional. Substituir um drive de disco instalado traz um problema: o que fazer com os dados do disco? Há algumas táticas possíveis: • Gravar os dados num dispositivo de backup e recuperá-los após instalar o novo drive de disco Capítulo 5. Administrando o Armazenamento 89 • Usar sua rede para copiar os dados para outro sistema com espaço livre suficiente, recuperando os dados após instalar o novo drive de disco • Usar o espaço fisicamente ocupado por um terceiro drive de disco ao: 1. Remover temporariamente o terceiro drive de disco 2. Instalar temporariamente o novo drive de disco em seu lugar 3. Copiar os dados no novo drive de disco 4. Remover o drive de disco antigo 5. Substituí-lo pelo novo drive de disco 6. Reinstalar o terceiro drive de disco removido temporariamente • Instalar temporariamente o drive de disco original e o novo drive de disco num outro computador, copiar os dados no novo drive de disco e então instalar o novo drive de disco no computador original Como você pode observar, às vezes é necessário um pouco de trabalho para trazer os dados (e o novo hardware) onde devem estar. 5.7.4.1.1.2. Adicionando Drives de Disco SCSI Os drives de disco SCSI são normalmente usados em estações de trabalho e sistemas de servidores mais avançados. Ao contrário dos sistemas baseados no ATA, os sistemas SCSI podem ou não ter controladores SCSI embutidos. Alguns têm, mas outros usam uma placa de controlador SCSI separada. As capacidades dos controladores SCSI (embutidos ou não) também variam imensamente. Podem prover um canal SCSI estreito ou largo. A velocidade do canal pode ser normal, rápida, ultra, ultra2 ou ultra160. Se estes termos não lhe forem familiares (brevemente abordados na Seção 5.3.2.2), você deve determinar as capacidades da sua configuração de hardware e selecionar um novo drive de disco apropriado. A melhor fonte para estas informações é a documentação de seu sistema e/ou do adaptador SCSI. Então, você deve determinar quantos canais SCSI estão disponíveis em seu sistema, e quais têm espaço disponível para um novo drive de disco. O número de dispositivos suportados por um canal SCSI varia de acordo com sua largura: • Canal SCSI estreito (8 bits) — 7 dispositivos (mais controlador) • Canal SCSI largo (16 bits) — 15 dispositivos (mais controlador) O primeiro passo é verificar quais canais têm espaço disponível para um drive de disco adicional. Você terá uma destas três situações: • Há um canal com um número de drives de disco conectados menor que o máximo • Há um canal sem nenhum drive de disco conectado • Não há espaço disponível em nenhum dos canais A primeira situação geralmente é a mais fácil, já que provavelmente o cabo existente tem um conector não-utilizado ao qual o novo drive de disco pode ser plugado. No entanto, se este não for o caso, é necessário substituir o cabo por outro que tenha, no mínimo, mais um conector. A segunda situação é um pouco mais difícil, somente pelo fato de que o cabo deve ser adquirido para poder conectar o drive de disco ao canal. Se não há espaço para um drive de disco adicional, você deve tomar uma decisão. Você: 90 Capítulo 5. Administrando o Armazenamento • Compra e instala uma placa de controlador SCSI • Substitui um dos drives de disco instalado pelo novo e maior Adicionar uma placa de controlador abrange verificar a compatibilidade do hardware, a capacidade física e a compatibilidade do software. Em suma, a placa deve ser suportada pelo seu sistema operacional, compatível com os slots dos canais de seu computador e deve haver um slot aberto para esta. Substituir um drive de disco instalado apresenta somente um problema: o que fazer com os dados do disco? Há algumas táticas possíveis: • Gravar os dados num dispositivo de backup e recuperá-los após instalar o novo drive de disco • Usar sua rede para copiar os dados em outro sistema com espaço livre suficiente, e recuperá-los após instalar o novo drive de disco • Usar o espaço fisicamente ocupado por um terceiro drive de disco ao: 1. Remover temporariamente o terceiro drive de disco 2. Instalar temporariamente o novo drive de disco em seu lugar 3. Copiar os dados no novo drive de disco 4. Remover o drive de disco antigo 5. Substituí-lo pelo novo drive de disco 6. Reinstalar o terceiro drive de disco removido temporariamente • Instalar temporariamente o drive de disco original e o novo drive de disco num outro computador, copiar os dados no novo drive de disco e então instalar o novo drive de disco no computador original Uma vez que há um conector disponível ao qual plugar o novo drive de disco, você deve garantir que o ID SCSI do drive esteja configurado apropriadamente. Para fazer isso, é necessário saber o que todos os dispositivos do canal (inclusive o controlador) estão usando como seus IDs SCSI. O modo mais fácil é acessar o BIOS do controlador SCSI. Isto é feito normalmente ao pressionar uma sequência específica de teclas durante a inicialização do sistema. Então, você pode visualizar a configuração do controlador SCSI, juntamente aos dispositivos ligados a todos os seus canais. Em seguida, você deve considerar a terminação apropriada do canal. Ao adicionar um novo drive de disco, a regra é bem simples — se o novo drive de disco é o último (ou único) dispositivo no canal, deve ter a terminação ativada. Caso contrário, a terminação deve ser desativada. Neste ponto, você pode passar para o próximo passo do processo — particionar seu novo drive de disco. 5.7.4.1.2. Particionando Uma vez instalado o drive de disco, é hora de criar uma ou mais partições para disponibilizar espaço para seu sistema operacional. Apesar das ferramentas variarem de acordo com o sistema operacional, os passos básicos são os mesmos: 1. Selecione o novo drive de disco 2. Visualize a tabela de partição atual para garantir que o drive de disco a ser particionado seja, de fato, o correto 3. Apague quaisquer partições indesejadas que possam estar presentes no novo drive de disco Capítulo 5. Administrando o Armazenamento 91 4. Crie a(s) nova(s) partição(ões), sem esquecer de especificar o tamanho e tipo de partição desejados 5. Salve suas alterações e saia do programa de particionamento Atenção Ao particionar um novo drive de disco, é vital garantir que esteja particionando o correto. Caso contrário, você pode particionar inadvertidamente um drive de disco já em uso, resultando na perda de dados. Também certifique-se de optar pelo melhor tamanho de partição. Sempre dê atenção a essa questão, porque alterar este valor posteriormente é bem mais difícil que gastar um tempinho para pensar nisso agora. 5.7.4.1.3. Formatando a(s) partição(ões) Neste ponto, o novo drive de disco tem uma ou mais partições criadas. Entretanto, antes de usar o espaço contido nestas partições, estas precisam ser formatadas. Ao formatar, você seleciona um sistema de arquivo específico a ser usado em cada partição. Sendo assim, esse é um momento crucial na vida do drive de disco; as opções que você fizer agora não podem ser alteradas sem uma grande quantidade de trabalho. O processo de formatação é feito ao rodar um utilitário; os passos envolvidos nisso variam de acordo com o sistema operacional. Após completar a formatação, o drive de disco está configurado apropriadamente para uso. Antes de continuar, é sempre melhor rever seu trabalho acessando a(s) partição(ões) e garantindo que tudo esteja em ordem. 5.7.4.1.4. Atualizando a Configuração do Sistema Se o seu sistema operacional requer alterações na configuração para usar o novo armazenamento que você adicionou, agora é hora de executá-las. Neste ponto, você pode sentir-se relativamente confiante que o sistema operacional está configurado apropriadamente para disponibilizar o novo armazenamento toda vez que o sistema inicializar (mas, se você puder efetuar uma breve reinicialização para garantir — melhor ainda). A próxima seção aborda um dos passos mais comumente esquecidos no processo de adição de novo armazenamento. 5.7.4.1.5. Alterando o Agendamento de Backup Assumindo que o novo armazenamento esteja com dados que devem ser guardados, essa é a hora de efetuar as alterações necessárias em seu procedimento de backup e garantir que o novo armazenamento tenha, de fato, um backup. A natureza exata do que você deve fazer para tanto depende da maneira através da qual os backups são feitos em seu sistema. No entanto, aqui estão algumas dicas para ter em mente ao efetuar as alterações necessárias: • Considere qual deve ser a melhor frequência de backup • Determine qual estilo de backup é mais apropriado (somente backups completos, completos com incrementos, completos com diferenciais, etc) 92 Capítulo 5. Administrando o Armazenamento • Considere o impacto do armazenamento adicional no uso de sua mídia de backup, especialmente conforme ficar cheia • Julgue se o backup adicional pode fazer com que os backups demorem muito e comecem a utilizar o tempo além daquele determinado para sua janela de backup • Garanta de comunicar estas alterações às pessoas que precisam saber (outros administradores de sistemas, pessoal de operações, etc) Feito isso, seu novo armazenamento está pronto para ser usado. 5.7.4.2. Removendo Armazenamento Remover espaço em disco de um sistema é simples; a maioria dos passos são parecidos com a sequência de instalação: 1. Retire do drive de disco quaisquer dados a serem salvos 2. Altere o agendamento de backup para que o drive de disco não tenha mais procedimento de backup 3. Atualize a configuração do sistema 4. Apague o conteúdo do drive de disco 5. Remova o drive de disco Como você pode observar, há alguns passos extras em relação ao processo de instalação. Estes passos são abordados nas próximas seções. 5.7.4.2.1. Removendo Dados do Drive de Disco Se houver dados no drive de disco que devem ser salvos, a primeira coisa a fazer é determinar para onde os dados devem ir. Esta decisão depende principalmente no que será feito com estes dados. Por exemplo: se estes não forem utilizados ativamente, devem ser arquivados, provavelmente da mesma maneira que os backups de seu sistema. Isso significa que essa é a hora de considerar os períodos de retenção para este backup final. Dica Tenha em mente que, além das regras de retenção de dados que sua empresa tenha, também deve haver requisitos legais para a retenção de dados por um certo período de tempo. Sendo assim, certifique-se de consultar o departamento responsável pelos dados enquanto eram utilizados; eles devem saber o período de retenção apropriado. Por outro lado, se os dados ainda estão em uso, então devem residir no sistema mais apropriado para este uso. Obviamente, se este for o caso, talvez seja mais fácil mover os dados ao reinstalar o drive de disco no novo sistema. Se optar por isso, você deve antes fazer um backup completo do dados — muitas pessoas derrubaram drives de disco cheios de dados valiosos (perdendo tudo) enquanto simplesmente andavam pelo centro de dados. Capítulo 5. Administrando o Armazenamento 93 5.7.4.2.2. Apague o Conteúdo do Drive de Disco Não importa se o drive de disco contém dados valiosos ou não; é sempre uma boa idéia apagar todo o conteúdo de um drive de disco antes de reatribuir ou abdicar de seu controle. Apesar do principal motivo ser garantir que nenhuma informção delicada permaneça no drive de disco, também é uma boa hora para verificar sua saúde executando um teste de acesso-gravação para blocos ruins por todo o drive de disco. Importante Muitas empresas (e agências do governo) têm métodos específicos para apagar dados de drives de disco e outras mídias de armazenamento de dados. Você sempre deve garantir que entende e cumpre estes requisitos; muitas vezes, há consequências legais caso você não os cumpra. O exemplo acima não deve, de modo algum, ser considerado o melhor método de limpar um drive de disco. Além disso, as empresas que trabalham com dados ordenados podem descobrir que a disposição final do drive de disco está sujeita a alguns procedimentos legais obrigatórios (tais como a destruição física do drive de disco). Nestes casos, o departamento de segurança de sua empresa deve ser capaz de oferecer-lhe aconselhamento. 5.8. Um Pouco Sobre Backups. . . Os backups são um dos fatores mais importantes quando pensamos em armazenamento de disco. Não detalhamos a questão aqui, pois há uma seção (Seção 8.2) mais aprofundada e dedicada ao assunto. 5.9. Informações Específicas do Red Hat Enterprise Linux Dependendo de sua experiência anterior como administrador de sistemas, administrar o armazenamento sob o Red Hat Enterprise Linux pode ser familiar ou completamente estranho. Esta seção aborda os aspectos de armazenamento específicos ao Red Hat Enterprise Linux. 5.9.1. Convenção de Nomenclatura de Dispositivos Assim como todos os sistemas operacionais parecidos com o Linux, o Red Hat Enterprise Linux usa arquivos de dispositivo para acessar todo o hardware (incluindo drives de disco). No entanto as convenções de nomenclatura para dispositvos de armazenamento anexos variam ligeiramente entre as diversas implementações do Linux e parecidas com o Linux. Aqui estão os nomes destes arquivos de dispositivo sob o Red Hat Enterprise Linux: Nota Os nomes dos dispositivos sob o Red Hat Enterprise Linux são determinados no momento da inicializaçã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 adequadamente atualizadas nos arquivos de configuração do sistema. 94 Capítulo 5. Administrando o Armazenamento 5.9.1.1. Arquivos de Dispositivos Sob o Red Hat Enterprise Linux, os arquivos dos dispositivos para drives de disco aparecem no diretório /dev/. O formato do nome de cada arquivo depende de diversos aspectos do hardware existente e como este foi configurado. Os pontos importantes são: • Tipo de dispositivo • Unidade • Partição 5.9.1.1.1. Tipo de Dispositivo As primeiras duas letras do nome do arquivo do dispositivo referem-se ao tipo específico do dispositivo. Para drives de disco, há dois tipos de dispositivos mais comuns: • sd — O dispositivo é baseado na SCSI • hd — O dispositivo é baseado na ATA Para mais informações sobre ATA e SCSI, consulte a Seção 5.3.2. 5.9.1.1.2. Unidade Na sequência das duas letras do tipo de dispositivo, há uma ou duas letras que especificam a unidade. A letra que designa a unidade começa com "a" para a primeira unidade, "b" para a segunda e assim por diante. Consequentemente, o primeiro disco rígido de seu sistema pode aparecer como hda ou sda. Dica A habilidade do SCSI em lidar com um número grande de dispositivos precisou da adição de um segundo caractere de unidade para suportar sistemas com mais de 26 dispositivos SCSI anexos. Sendo assim, os primeiros 26 discos rígidos SCSI de um sistema seriam nomeados de sda a sdz, os próximos 26 seriam nomeados de sdaa a sdaz e assim por diante. 5.9.1.1.3. Partição A parte final do nome do arquivo de dispositivo é um número representando uma partição específica no dispositivo, começando por "1." O número pode ter um ou dois dígitos, dependendo do número de partições gravadas no dispositivo específico. Uma vez conhecido o formato do nome do arquivo de dispositivo, é fácil entender as referências de cada um. Aqui estão alguns exemplos: • /dev/hda1 — A primeira partição do primeiro drive ATA • /dev/sdb12 — A décima-segunda partição do segundo drive SCSI • /dev/sdad4 — A quarta partição do trigésimo drive SCSI Capítulo 5. Administrando o Armazenamento 95 5.9.1.1.4. Acesso ao Dispositivo Inteiro Há situações nas quais é necessário acessar o dispositivo inteiro e não somente uma partição. Isso normalmente é feito quando o dispositivo não está particionado ou quando não suporta partições padrão (como o drive de CD-ROM). Nestes casos, o número da partição é omitido: • /dev/hdc — O terceiro dispositivo ATA inteiro • /dev/sdb — O segundo dispositivo SCSI inteiro No entanto, a maioria dos drives de disco usa partições (mais informações sobre o particionamento sob o Red Hat Enterprise Linux podem ser encontradas na Seção 5.9.6.1). 5.9.1.2. Alternativas aos Nomes de Arquivo dos Dispositivos Como a adição ou remoção de dispositivos de armazenamento em massa pode resultar em alterações nos nomes de arquivo dos dispositivos existentes, existe o risco do armazenamento não estar disponível quando o sistema reinicializar. Eis um exemplo da sequência de eventos acarretando este problema: 1. O administrador de sistemas adiciona um novo controlador SCSI para poder adicionar dois novos drives SCSI ao sistema (o canal SCSI existente está totalmente cheio) 2. Os drives SCSI originais (incluindo o primeiro drive do canal: /dev/sda) não são alterados de modo algum 3. O sistema é reinicializado 4. Agora, o drive SCSI previamente conhecido como /dev/sda, tem um novo nome porque o primeiro drive SCSI do novo controlador é o /dev/sda Na teoria, este parece ser um grande problema. Entretanto, na prática, isso raramente é um problema por diversas razões. Primeiro: reconfigurações do hardware desse tipo raramente acontecem. Segundo: é provável que o administrador de sistemas tenha agendado um tempo fora do ar (downtime) para efetuar as alterações necessárias; o tempo fora do ar requer um planejamento cuidadoso para garantir que o trabalho sendo feito não leve mais que o tempo alocado. Esse planejamento tem o benefício colateral de trazer à tona todas as questões relativas às alterações de nomes dos dispositivos. Entretanto, algumas empresas e suas configurações de sistemas tem maior probabilidade de passar por essa situação. As empresas que requerem reconfigurações frequentes do armazenamento para atender às suas necessidades frequentemente usam hardware capaz de reconfiguração sem a necessidade 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 podem tornar-se um problema. Felizmente, o Red Hat Enterprise Linux contém funcionalidades que amenizam o problema das alterações nos nomes dos dispositivos. 5.9.1.2.1. Etiquetas do Sistema de Arquivo Alguns sistemas de arquivo (abordados na Seção 5.9.2) têm a habilidade de armazenar uma etiqueta — uma sequência de caracteres que pode ser usada para identificar unicamente os dados contidos no sistema de arquivo. As etiquetas podem ser usadas ao montar o sistema de arquivo, eliminando a necessidade do uso do nome do dispositivo. As etiquetas de sistema de arquivo funcionam bem; no entanto, devem ser únicas em todo o sistema. Se houver mais de um sistema de arquivo com a mesma etiqueta, talvez você não consiga acessar o sistema de arquivo desejado. Note também que as configurações do sistema que não utilizam sistemas de arquivo (alguns bancos de dados, por exemplo) não podem usufruir das etiquetas de sistema de arquivo. 96 Capítulo 5. Administrando o Armazenamento 5.9.1.2.2. Usando o devlabel O software devlabel tenta resolver a questão da nomenclatura de dispositivos de maneira diferente que as etiquetas do sistema de arquivo. O software devlabel é executado pelo Red Hat Enterprise Linux sempre que o sistema reinicializa (e sempre que dispositivos hotpluggable são inseridos ou removidos). Quando o devlabel é executado, lê o arquivo de configuração (/etc/sysconfig/devlabel) para obter a lista dos dispositivos pelos quais é responsável. Para cada dispositivo da lista, há uma ligação simbólica, ou symbolic link, (escolhida pelo administrador de sistemas) e o UUID (IDentificador Único Universal) do dispositivo. O comando devlabel garante que a ligação simbólica sempre refere ao dispositivo originalmente especificado — mesmo que o nome deste dispositivo tenha mudado. Dessa maneira, um administrador de sistemas pode configurar um sistema para referir ao /dev/projdisk ao invés do /dev/sda12, por exemplo. Como o UUID é obtido diretamente pelo dispositivo, o devlabel deve somente procurar pelo UUID correspondente no sistema e atualizar a ligação simbólica apropriadamente. Para mais informações sobre o devlabel, consulte o Guia de Administração de Sistemas Red Hat Enterprise Linux. 5.9.2. Conceitos Básicos do Sistema de Arquivo O Red Hat Enterprise Linux inclui suporte para muitos sistemas de arquivo conhecidos, possibilitando acessar facilmente os sistemas de arquivo de outros sistemas operacionais. Isso é especialmente útil em cenários de boot duplo e ao migrar arquivos de um sistema operacional para outro. Os sistemas de arquivo suportados incluem (mas não estão limitados a): • EXT2 • EXT3 • NFS • ISO 9660 • MSDOS • VFAT Os cenários seguintes exploram os sistemas de arquivo mais conhecidos em detalhes. 5.9.2.1. EXT2 Até recentemente, o sistema de arquivo ext2 foi o sistema de arquivo padrão para o Linux. Como tal, recebeu testes intensivos e é considerado um dos sistemas de arquivo mais robustos em uso. No entanto, não existe um sistema de arquivo perfeito e o ext2 não é uma exceção. Um problema comumente reportado é que o sistema de arquivo ext2 deve passar por uma verificação de integridade muito longa, caso o sistema não tenha sido desligado apropriadamente. Apesar deste requisito não ser exclusivo do ext2, sua popularidade, combinada com o advento de drives de disco maiores, significou que a verificação de integridade estava levando muito tempo. Algo devia ser feito. A próxima seção aborda a tática adotada para resolver esta questão sob o Red Hat Enterprise Linux. Capítulo 5. Administrando o Armazenamento 97 5.9.2.2. EXT3 O sistema de arquivo ext3 adicionou as capacidades de journaling sobre a base de código já provada do ext2. Com o journaling, o ext3 sempre mantém o sistema de arquivo num estado consistente, eliminando a necessidade de longas verificações de integridade no sistema de arquivo. Isso é feito ao gravar todas as alterações do sistema de arquivo num registro em disco, que é alimentado frequentemente. Após um evento inesperado no sistema (tal como falta de energia ou queda do sistema), a única operação que precisa ocorrer antes de disponibilizar o sistema de arquivo é processar o conteúdo do registro; na maioria dos casos isso leva aproximadamente um segundo. Como o formato dos dados do ext3 em disco é baseado no ext2, é possível acessar um sistema de arquivo ext3 em qualquer sistema capaz de acessar e gravar um sistema de arquivo ext2 (porém sem o benefício do journaling). Este pode ser um excelente benefício em empresas que utilizam alguns sistemas com ext3 e outros com ext2. 5.9.2.3. ISO 9660 Em 1987, a Organização Internacional para a Padronização (conhecida como ISO, International Organization for Standardization) lançou o padrão 9660. O ISO 9660 define como os arquivos são representados nos CD-ROMs. Os administradores de sistemas Red Hat Enterprise Linux provavelmente verão dados no formato ISO 9660 em dois lugares: • CD-ROMs • Arquivos (geralmente referenciados como imagens ISO) contendo sistemas de arquivo ISO 9660 completos, a serem gravados em mídia CD-R ou CD-RW. O padrão ISO 9660 básico é limitado em funcionalidade, especialmente se comparado com sistemas de arquivo mais modernos. Os nomes de arquivos podem ter no máximo oito caracteres e extensão até três caracteres. No entanto, diversas extensões do padrão tornaram-se conhecidas, incluindo: • Rock Ridge — Usa alguns campos indefinidos no ISO 9660 para oferecer suporte para funcionalidades 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 CDROMs contenham nomes de arquivo longos, usando o conjunto de caracteres Unicode O Red Hat Enterprise Linux é capaz de interpretar corretamente os sistemas de arquivo ISO 9660 usando ambas 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 suportava era o MS-DOS® da Microsoft. Assim como no MS-DOS, um sistema Red Hat Enterprise Linux acessando um sistema de arquivo msdos está limitado aos nomes de arquivo 8.3. Da mesma forma, outros atributos do arquivo, como permissões e propriedade, não podem ser alterados. Entretanto, do ponto de vista de intercâmbio de arquivos, o sistema de arquivo msdos é mais que suficiente para executar o trabalho. 5.9.2.5. VFAT O sistema de arquivo vfat foi usado pela primeira vez pelo sistema operacional Windows® 95 da Microsoft. Trouxe uma melhoria sobre o sistema de arquivo msdos; os nomes de arquivo num sistema 98 Capítulo 5. Administrando o Armazenamento vfat podem ser mais longos que o formato 8.3. No entanto, as permissões e propriedade ainda não podem ser alterados. 5.9.3. Montando Sistemas de Arquivo Para acessar qualquer sistema de arquivo, é preciso primeiro montá-lo (mount). Ao montar um sistema de arquivo, você direciona o Red Hat Enterprise Linux a disponibilizar uma partição específica (num dispositivo específico) ao sistema. Da mesma forma, ao acessar um determinado sistema de arquivo que não é mais desejado, é necessário desmontá-lo (umount). Para montar um sistema de arquivo, é preciso especificar dois tipos de informação: • Um meio de identificar unicamente o drive de disco e partição desejados, como o nome do arquivo do dispositivo, a etiqueta do sistema de arquivo ou a ligação simbólica administrada pelo devlabel • Um diretório sob o qual o sistema de arquivo montado será disponibilizado (conhecido como ponto de montagem) As seções seguintes abordam os pontos de montagem mais detalhadamente. 5.9.3.1. Pontos de Montagem A não ser que você esteja acostumado com o sistema operacional Linux (ou outros parecidos), o conceito do ponto de montagem pode parecer estranho à primeira vista. Entretanto, é um dos métodos mais poderosos e flexíveis de administração de sistemas de arquivo. Em muitos outros sistemas operacionais, a especificação completa de um arquivo inclui seu nome, algum meio de identificar o diretório específico no qual reside e um meio de identificar o dispositivo físico no qual o arquivo pode ser encontrado. O Red Hat Enterprise Linux usa uma tática ligeiramente diferente. Assim como ocorre em outros sistemas operacionais, uma especificação completa inclui o nome do arquivo e o diretório no qual reside. No entanto, não há um identificador explícito do dispositivo. A razão dessa aparente deficiência é o ponto de montagem. Em outros sistemas operacionais, há uma hierarquia de diretórios para cada partição. Mas, em sistemas parecidos com o Linux, há somente uma hierarquia de diretório para o sistema todo, que pode extender-se a partições múltiplas. A chave é o ponto de montagem. Ao montar um sistema de arquivo, este é disponibilizado como um conjunto de sub-diretórios sob o ponto de montagem especificado. Essa aparente deficiência é, na verdade, uma vantagem. Significa que é possível expandir suavemente um sistema de arquivo Linux, com todos os diretórios capazes de agirem como um ponto de montagem para espaço adicional em disco. Como um exemplo, assuma que um sistema Red Hat Enterprise Linux contenha um diretório foo em seu diretório root; a localidade completa do diretório seria /foo/. Em seguida, assuma que este sistema tem uma partição a ser montada e seu ponto de montagem deve ser /foo/. Se esta partição tivesse um arquivo de nome bar.txt no nível superior de seu diretório, você poderia acessá-lo após montar a partição, com a especificação seguinte: /foo/bar.txt Em outras palavras, uma vez montada a partição, qualquer arquivo que é acessado ou gravado em qualquer localidade sob o diretório /foo/, será acessado ou salvo nessa partição. Um ponto de montagem comumente usado em muitos sistemas Red Hat Enterprise Linux é /home/ — isso ocorre porque os diretórios de login para todas as contas de usuário normalmente estão localizadas sob /home/. Se /home/ for usado como ponto de montagem, os arquivos de todos os usuários são salvos numa partição dedicada e não lotarão o sistema de arquivo do sistema operacional. Capítulo 5. Administrando o Armazenamento 99 Dica Como o ponto de montagem é somente um diretório comum, é possível salvar arquivos num diretório posteriormente usado como ponto de montagem. Se isso acontecer, o que ocorre com os arquivos que estavam originalmente no diretório? Contanto que a partição seja montada no diretório, os arquivos não estarão acessíveis (o sistema de arquivo montado aparece no lugar do conteúdo do diretório). No entanto, os arquivos não serão danificados e podem ser acessados após a partição ser desmontada. 5.9.3.2. Visualizando O Que está Montado Além de montar e desmontar espaço em disco, é possível visualizar o que está montado. Há diversas maneiras diferentes de fazer isso: • Visualizar o /etc/mtab • Visualizar o /proc/mounts • Atribuindo o comando df 5.9.3.2.1. Visualizar o /etc/mtab O arquivo /etc/mtab é um arquivo normal atualizado pelo programa mount sempre que os sistemas de arquivo são montados ou desmontados. Aqui está uma amostra do /etc/mtab: /dev/sda3 / ext3 rw 0 0 none /proc proc rw 0 0 usbdevfs /proc/bus/usb usbdevfs rw 0 0 /dev/sda1 /boot ext3 rw 0 0 none /dev/pts devpts rw,gid=5,mode=620 0 0 /dev/sda4 /home ext3 rw 0 0 none /dev/shm tmpfs rw 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 Nota O arquivo /etc/mtab deve ser usado para visualizar somente o status dos sistemas de arquivo correntemente montados. Não deve ser modificado manunalmente. Cada linha representa um sistema de arquivo correntemente montado e contém os seguintes campos (da esquerda para a direita): • A especificação do dispositivo • O ponto de montagem • O tipo de sistema de arquivo • Se o sistema de arquivo está montado como somente-leitura (ro, read-only) ou leitura e gravação (rw, read-write), junto às outras opções do ponto de montagem • Dois campos não-usados contendo zeros (para saber sobre a compatibilidade com /etc/fstab 11) 11. Consulte a Seção 5.9.5 para mais informações. 100 Capítulo 5. Administrando o Armazenamento 5.9.3.2.2. Visualizar o /proc/mounts O arquivo /proc/mounts é parte do sistema de arquivo virtual proc. Assim como os outros arquivos sob /proc/, o "arquivo" mounts não existe em nenhum drive de disco de seu sistema Red Hat Enterprise Linux. De fato, nem é um arquivo, mas uma representação do status do sistema disponibilizado (pelo kernel do Linux) no formato de arquivo. Usando o comando cat /proc/mounts podemos visualizar o status de todos os sistemas de arquivo montados: rootfs / rootfs rw 0 0 /dev/root / ext3 rw 0 0 /proc /proc proc rw 0 0 usbdevfs /proc/bus/usb usbdevfs rw 0 0 /dev/sda1 /boot ext3 rw 0 0 none /dev/pts devpts rw 0 0 /dev/sda4 /home ext3 rw 0 0 none /dev/shm tmpfs rw 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 Como podemos observar no exemplo anterior, o formato do /proc/mounts é muito similar ao formato do /etc/mtab. Há diversos sistemas de arquivo montados que não têm nenhuma relação com drives de disco. Dentre estes, temos o próprio sistema de arquivo /proc/ (junto a dois outros sistemas operacionais montados sob /proc/), pseudo-ttys e memória compartilhada. Apesar do formato não ser muito amigável, observar o /proc/mounts é a melhor maneira de estar 100% certo de ver o que está montado em seu sistema Red Hat Enterprise Linux, já que o kernel provém estas informações. Outros métodos podem, sob raras circunstâncias, serem incorretos. Entretanto, na maior parte do tempo você provavelmente utilizará um comando com output de leitura mais fácil (e útil). A seção seguinte descreve este comando. 5.9.3.2.3. Atribuindo o Comando df Apesar do uso do /etc/mtab ou do /proc/mounts trazer as informações sobre quais sistemas de arquivo estão montados, fazem pouco além disso. Na maior parte do tempo você estará interessado num aspecto específico dos sistemas de arquivo correntemente montados — a quantidade de espaço livre nestes. Para isso, podemos usar o comando df. Aqui está uma amostra do output do df: Filesystem /dev/sda3 /dev/sda1 /dev/sda4 none 1k-blocks 8428196 124427 8428196 644600 Used Available Use% Mounted on 4280980 3719084 54% / 18815 99188 16% /boot 4094232 3905832 52% /home 0 644600 0% /dev/shm Nota-se imediatamente diversas diferenças com o /etc/mtab e /proc/mount: • A exibição de um cabeçalho de fácil leitura • Com exceção do sistema de arquivo com memória compartilhada, são exibidos somente sistemas de arquivo baseados no disco • São exibidos o tamanho total, o espaço utilizado, o espaço livre e a porcentagem em números Esse último ponto é provavelmente o mais importante, pois todo administrador de sistemas eventualmente precisa lidar com um sistema que atingiu todo seu espaço em disco. Com o df é muito fácil visualizar onde está o problema. Capítulo 5. Administrando o Armazenamento 101 5.9.4. Armazenamento Acessível pela Rede Sob o Red Hat Enterprise Linux Há duas tecnologias principais usadas para implementar o armazenamento acessível pela rede sob o Red Hat Enterprise Linux: • NFS • SMB As seções seguintes abordam estas tecnologias. 5.9.4.1. NFS Como o nome infere, o Network File System (mais comumente conhecido como NFS ou Sistema de Arquivo de Rede) é um sistema de arquivo que pode ser acessado através de uma conexão de rede. Em outros sistemas de arquivo, o dispositivo de armazenamento deve ser diretamente ligado ao sistema local. No entanto, este não é um requisito do NFS, o que possibilita uma variedade de configurações diferentes - de servidores centralizados de sistema de arquivo a sistemas de computadores inteiramente sem discos. Porém, ao contrário de outros sistemas de arquivo, o NFS não dita um formato específico em disco. Ao invés disso, conta com o suporte do sistema de arquivo nativo do sistema operacional do servidor para controlar as I/Os correntes para o(s) drive(s) local(is). Então, o NFS disponibiliza o sistema de arquivo para qualquer sistema operacional rodando um cliente NFS compatível. Apesar de ser uma tecnologia primariamente do Linux e UNIX, é importante notar a existência de implementações de clientes NFS para outros sistemas operacionais, viabilizando sua técnica para compartilhar arquivos dentre diversas plataformas diferentes. Os sistemas de arquivo que o NFS disponibiliza para clientes são controlados pelo arquivo de configuração /etc/exports. Para mais informações, consulte a página man exports(5) e o Guia de Administração de Sistemas Red Hat Enterprise Linux. 5.9.4.2. SMB SMB significa Server Message Block (Bloco de Mensagens do Servidor) e é o nome do protocolo de comunicações usado por vários sistemas operacionais produzidos pela Microsoft ao longo dos anos. O SMB possibilita compartilhar armazenamento através de uma rede. As implementações de hoje frequentemente usam o TCP/IP como o transporte fundamental; o transporte prévio era o NetBEUI. O Red Hat Enterprise Linux suporta o SMB através do programa de servidor Samba. O Guia de Administração de Sistemas Red Hat Enterprise Linux contém informações sobre a configuração do Samba. 5.9.5. Montando Sistemas de Arquivo Automaticamente com /etc/fstab Quando um sistema Red Hat Enterprise Linux é recém-instalado, todas as partições de disco definidas e/ou criadas durante a instalação são configuradas para serem montadas automaticamente sempre que o sistema reinicializar. Porém, o que acontece quando adicionamos drives de disco num sistema após completa a instalação? A resposta é "nada", porque o sistema não foi configurado para montá-las automaticamente. No entanto, é fácil mudar isso. A resposta está no arquivo /etc/fstab. Este arquivo é usado para controlar quais sistemas de arquivo são montados quando o sistema inicializa, e também para prover valores default para outros sistemas de arquivo que possam ser montados manualmente ao longo do tempo. Aqui está uma amostra do arquivo /etc/fstab: LABEL=/ / ext3 defaults 1 1 102 /dev/sda1 /dev/cdrom /dev/homedisk /dev/sda2 Capítulo 5. Administrando o Armazenamento /boot /mnt/cdrom /home swap ext3 iso9660 ext3 swap defaults 1 2 noauto,owner,kudzu,ro 0 0 defaults 1 2 defaults 0 0 Cada linha representa um sistema de arquivo e contém os seguintes campos: • Especificador do sistema de arquivo — Para sistemas de arquivo baseados em disco, é o nome de um dispositivo (/dev/sda1), a etiqueta do sistema de arquivo (LABEL=/) ou uma ligação simbólica administrada pelo devlabel (/dev/homedisk) • Ponto de montagem — Exceto as partições swap, este campo especifica o ponto de montagem a ser usado quando o sistema de arquivo estiver montado (/boot) • Tipo de sistema de arquivo — O tipo de sistema de arquivo presente no dispositivo especificado (note que auto pode ser especificado para selecionar a detecção automática do sistema de arquivo a ser montado, o que é prático para unidades de mídia removível como drives de disquete) • Opções de montagem — Uma lista de opções, separadas por vírgulas, que podem ser usadas para controlar o comportamento do mount (noauto,owner,kudzu) • Frequência do dump — Se o utilitário de backup dump for usado, o número deste campo controla como o dump lida com o sistema de arquivo especificado • Ordem de verificação do sistema de arquivo — Controla a ordem na qual o fsck verifica a integridade dos sistemas de arquivo 5.9.6. Adicionando/Removendo Armazenamento Apesar da maioria dos passos necessários para adicionar ou remover armazenamento dependerem mais do hardware que do software do sistema, há aspectos do procedimento específicos ao seu ambiente operacional. Esta seção explora os passos específicos ao Red Hat Enterprise Linux necessários para adicionar e remover armazenamento. 5.9.6.1. Adicionando Armazenamento O processo de adição de armazenamento é relativamente simples. Aqui estão os passos específicos ao Red Hat Enterprise Linux: • Particionando • Formatando a(s) partição(ões) • Atualizar o /etc/fstab As seções seguintes abordam cada passo em detalhes. 5.9.6.1.1. Particionando Uma vez instalado o drive de disco, é hora de criar uma ou mais partições a fim de disponibilizar espaço para o Red Hat Enterprise Linux. Há mais de uma maneira de fazer isso: • Usando o utilitário fdisk na janela de comandos • Usando o parted, um outro utilitário da linha de comandos Apesar das ferramentas serem diferentes, os passos básicos são os mesmos. O exemplo a seguir inclui os comandos necessários para executar estes passos usando fdisk: Capítulo 5. Administrando o Armazenamento 103 1. Selecione o novo drive de disco (o nome do drive pode ser identificado através das convenções de nomenclatura dos dispositivos descritas na Seção 5.9.1). Usando o fdisk, isso é feito incluindo o nome do dispositivo ao iniciar o fdisk: fdisk /dev/hda 2. Visualize a tabela de partição do drive de disco para garantir que o drive a ser particionado seja, de fato, o correto. Em nosso exemplo, o fdisk exibe a tabela de partição usando o comando p: Command (m for help): p Disk /dev/hda: 255 heads, 63 sectors, 1244 cylinders Units = cylinders of 16065 * 512 bytes Device Boot /dev/hda1 * /dev/hda2 /dev/hda3 /dev/hda4 Start 1 18 84 476 End 17 83 475 1244 Blocks 136521 530145 3148740 6176992+ Id 83 82 83 83 System Linux Linux swap Linux Linux 3. Apague todas as 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) p Partition number (1-4): 1 First cylinder (1-767): 1 Last cylinder or +size or +sizeM or +sizeK: +512M Segundo: determinar o tipo de sistema de arquivo (usando o comando t): Command (m for help): t Partition number (1-4): 1 Hex code (type L to list codes): 82 A partição do tipo 82 representa uma partição Linux swap. 5. Salve suas alterações e saia do programa de particionamento. Isso é feito no fdisk usando o comando w: Command (m for help): w 104 Capítulo 5. Administrando o Armazenamento Atenção Ao particionar um novo drive de disco, é vital garantir que esteja particionando o correto. Caso contrário, você pode particionar inadvertidamente um drive de disco já em uso, resultando na perda de dados. Também certifique-se de optar pelo melhor tamanho de partição. Sempre dê atenção a essa questão, porque alterar este valor posteriormente é bem mais difícil que gastar um tempinho para pensar nisso agora. 5.9.6.1.2. Formatando a(s) partição(ões) A formatação de partições sob o Red Hat Enterprise Linux é feita com o utilitário mkfs. Na realidade, o mkfs não executa o trabalho de gravar as informações específicas do sistema de arquivo num drive de disco; ao invés disso, passa o controle para um dos diversos outros programas que realmente criam o sistema de arquivo. Essa é a hora de observar a página man mkfs. fstype do sistema de arquivo que você selecionou. Por exemplo: veja a página man mkfs.ext3 para verificar as opções disponíveis ao criar um novo sistema de arquivo ext3. Em geral, os programas mkfs. fstype oferecem defaults razoáveis para a maioria das configurações, mas aqui estão algumas opções que os administradores de sistemas comumente alteram: • Determinar uma etiqueta de volume para uso posterior no /etc/fstab • Em discos rígidos muito grandes, determinar uma porcentagem mais baixa para o espaço reservado para o super-usuário • Determinar um tamanho de bloco fora do padrão e/ou bytes por inode para configurações que devem suportar arquivos muito grandes ou muito pequenos • Verificar os blocos ruins antes de formatar Uma vez criados os sistemas de arquivo nas partições apropriadas, o drive de disco está configurado corretamente para o uso. Em seguida, é sempre melhor verificar novamente seu trabalho montando manualmente a(s) partição(ões) e garantindo que está tudo em ordem. Após a segunda verificação, é hora de configurar seu sistema Red Hat Enterprise Linux para montar automaticamente o(s) novo(s) sistema(s) de arquivo sempre que inicializar. 5.9.6.1.3. Atualizar o /etc/fstab Conforme a Seção 5.9.5, você deve adicionar a(s) linha(s) necessária(s) ao /etc/fstab para garantir que o(s) novo(s) sistema(s) de arquivo seja montado sempre que o sistema reinicializar. Após atualizar o /etc/fstab, teste seu trabalho atribuindo um comando mount "incompleto", especificando somente o dispositivo ou ponto de montagem. Algo similar a um dos seguintes comandos é suficiente: mount /home mount /dev/hda3 (Substituir /home ou /dev/hda3 pelo ponto de montagem ou dispositivo para sua situação específica.) Se a entrada apropriada do /etc/fstab estiver correta, o mount obtém as informações faltantes e completa a operação de montagem. Capítulo 5. Administrando o Armazenamento 105 Neste ponto você pode estar relativamente confiante que o /etc/fstab está configurado apropriadamente para montar automaticamente o novo armazenamento sempre que o sistema inicializar (mas, se você puder efetuar uma reinicialização rápida para garantir — melhor ainda). 5.9.6.2. Removendo Armazenamento O processo de remoção de armazenamento de um sistema Red Hat Enterprise Linux é relativamente simples. Aqui estão os passos específicos ao Red Hat Enterprise Linux: • Remova as partições do drive de disco de /etc/fstab • Desmonte as partições ativas do drive de disco • Apague o conteúdo do drive de disco As seções seguintes cobrem estes tópicos em detalhes. 5.9.6.2.1. Remover as Partições do Drive de Disco do /etc/fstab Usando seu editor de texto preferido, remova a(s) linha(s) correspondente(s) à(s) partição(ões) do drive de disco do arquivo /etc/fstab. Você pode identificar as linhas apropriadas através de um dos métodos seguintes: • Encontrando o ponto de montagem correspondente à partição nos diretórios da segunda coluna do • Encontrando o nome do dispositivo correspondente nos nomes de arquivo da primeira coluna do /etc/fstab /etc/fstab Dica Certifique-se de procurar por todas as linhas do /etc/fstab que identificam partições swap no drive de disco a ser removido; estas podem passar desapercebidas facilmente. 5.9.6.2.2. Finalizando o Acesso Com umount Em seguida, todo acesso ao drive de disco deve ser finalizado. Para partições contendo sistemas de arquivo ativos, isso é feito usando o comando umount. Se houver uma partição swap no drive de disco, deve ser desativada com o comando swapoff ou o sistema deve ser reinicializado. Para desmontar partições com o comando umount é necessário especificar o nome do arquivo do dispositivo ou o ponto de montagem da partição: umount /dev/hda2 umount /home Uma partição só pode ser desmontada se não estiver em uso. Se a partição não puder ser desmontada no nível de execução normal, reinicialize no modo de recuperação e remova a entrada /etc/fstab da partição. Ao usar o swapoff para desabilitar o swapping numa partição, você deve especificar o nome do arquivo do dispositivo representando a partição swap: 106 Capítulo 5. Administrando o Armazenamento swapoff /dev/hda4 Se o swapping não puder ser desabilitado de uma partição swap usando o swapoff, inicialize no modo de recuperação e remova a entrada /etc/fstab da partição. 5.9.6.2.3. Apague o Conteúdo do Drive de Disco Apagar o conteúdo de um drive de disco sob o Red Hat Enterprise Linux é um procedimento simples. Após desmontar todas as partições do drive de disco, atribua o seguinte comando (como root): badblocks -ws device-name Onde device-name representa o nome do arquivo do drive de disco que você deseja apagar, excluindo o número da partição. Por exemplo: /dev/hdb para o segundo disco rígido ATA. O seguinte output é apresentado enquanto o badblocks é executado: Writing Reading Writing Reading Writing Reading Writing Reading pattern 0xaaaaaaaa: and comparing: done pattern 0x55555555: and comparing: done pattern 0xffffffff: and comparing: done pattern 0x00000000: and comparing: done done done done done Tenha em mente que o badblocks está, na realidade, gravando quatro padrões de dados diferentes em cada bloco do drive de disco. Para drives de disco grandes, este processo pode levar bastante tempo — frequentemente diversas horas. Importante Muitas empresas (e agências do governo) têm métodos específicos para apagar dados de drives de disco e outras mídias de armazenamento de dados. Você sempre deve garantir que entende e cumpre estes requisitos; muitas vezes, há consequências legais caso você não os cumpra. O exemplo acima não deve, de modo algum, ser considerado o melhor método de limpar um drive de disco. No entanto, é bem mais eficiente que usar o comando rm, porquê quando você apaga um arquivo usando rm, este arquivo é marcado como apagado (deleted) — não apaga o conteúdo do arquivo. 5.9.7. Implementando Quotas de Disco O Red Hat Enterprise Linux é capaz de manter registro do uso do espaço em disco por usuário e por grupo através da utilização das quotas de disco. A seção seguinte provém uma visão geral das funcionalidades presentes nas quotas de disco sob o Red Hat Enterprise Linux. Capítulo 5. Administrando o Armazenamento 107 5.9.7.1. Informações Básicas sobre as Quotas de Disco As quotas de disco têm as seguintes funcionalidades sob o Red Hat Enterprise Linux: • Implementação por sistema de arquivo • Contabilidade do espaço por usuário • Contabilidade do espaço por grupo • Registro do uso do bloco de disco • Registro do uso do inode do disco • Limites rígidos (hard limits) • Limites suaves (soft limits) • Períodos de carência (grace periods) As seções seguintes descrevem cada funcionalidade em detalhes. 5.9.7.1.1. Implementação Por Sistema de Arquivo As quotas de disco sob o Red Hat Enterprise Linux podem ser usadas por sistema de arquivo. Em outras palavras, as quotas de disco podem ser ativadas ou desativadas para cada sistema de arquivo separadamente. Isso oferece grande flexibilidade ao administrador de sistemas. Por exemplo: se o diretório /home/ estava em seu próprio sistema de arquivo, as quotas de disco poderiam ser ativadas ali, garantindo o uso igualitário do disco por todos os usuários. No entanto, o sistema de arquivo root poderia ser deixado sem quotas de disco, eliminando a complexidade de manter quotas de disco num sistema de arquivo que contém apenas o próprio sistema operacional. 5.9.7.1.2. Contabilidade do Espaço Por Usuário As quotas de disco podem efetuar a contabilidade por usuário. Isso significa que o uso do espaço por cada usuário é registrado individualmente. Também significa que as limitações de uso (abordadas em seções posteriores) também são determinadas por usuário. A flexibilidade de registrar e garantir o uso do disco para cada usuário individualmente possibilita a um administrador de sistemas atribuir limites diferentes aos usuários, de acordo com suas responsabilidades e necessidades de armazenamento. 5.9.7.1.3. Contabilidade do Espaço Por Grupo As quotas de disco também podem registrar o uso do disco por grupo. Isso é ideal para aquelas empresas que utilizam os grupos como um meio de combinar os diferentes usuários num único recurso para um projeto. Ao determinar quotas de disco para um grupo, os administradores de sistemas podem gerenciar de perto a utilização do armazenamento, atribuindo a usuários individuais somente a quota de disco necessária para seu uso pessoal e determinando quotas maiores. 5.9.7.1.4. Registro do Uso do Bloco do Disco As quotas de disco registram o uso do bloco de disco. Como todos os dados de um sistema de arquivo são armazenados em blocos, as quotas de disco são capazes de correlacionar diretamente os arquivos criados e apagados de um sistema de arquivo com a quantidade de armazenamento que estes arquivos ocupam. 108 Capítulo 5. Administrando o Armazenamento 5.9.7.1.5. Registro do Uso do Inode de Disco Além de registrar o uso do bloco de disco, as quotas também podem registrar o uso do inode. Sob o Red Hat Enterprise Linux, os inodes são usados para armazenar várias partes do sistema de arquivo, mas acima de tudo, os inodes guardam as informações de cada arquivo. Consequentemente, ao registrar (e controlar) o uso do inode, é possível controlar a criação de novos arquivos. 5.9.7.1.6. Limites Rígidos Um limite rígido é o número máximo absoluto de blocos (ou inodes) de disco que podem ser temporariamente usados por um usuário (ou grupo). Todas as tentativas de usar um bloco ou inode acima do limite rígido falharão. 5.9.7.1.7. Limites Suaves Um limite suave é o número máximo de blocos do disco (ou inodes) que podem ser usados permanentemente por um usuário (ou grupo). O limite suave é determinado abaixo do limite rígido. Isso permite aos usuários temporariamente exceder o limite suave, de modo que possam acabar o que estão fazendo e tenham tempo de observar seus arquivos e reduzir seu uso abaixo do limite suave. 5.9.7.1.8. Períodos de Carência Conforme afirmado anteriormente, todo uso do disco acima do limite suave é temporário. O período de carência é que determina o tempo em que um usuário (ou grupo) pode extender seu uso além de seus limites suaves e rumo a seus limites rígidos. Se um usuário continuar a usar mais que seu limite suave e o período de carência expirar, não lhe será permitido usar espaço adicional até que ele (ou o grupo) tenha reduzido seu uso para uma marca abaixo do limite suave. O período de carência pode ser estabelecido em segundos, minutos, horas, dias, semanas ou meses, oferecendo ao administrador de sistemas bastante liberdade para determinar quanto tempo seus usuários terão para reduzir seus usos de disco abaixo dos limites suaves. 5.9.7.2. Ativando Quotas de Disco Nota As seções a seguir oferecem uma breve visão geral dos passos necessários para ativar as quotas de disco sob o Red Hat Enterprise Linux. Para obter uma abordagem mais profunda deste assunto, consulte o capítulo sobre quotas de disco no Guia de Administração de Sistemas Red Hat Enterprise Linux. Para usar as quotas de disco, você deve ativá-las primeiro. Este processo envolve diversos passos: 1. Modificando o /etc/fstab 2. Remontando o(s) sistema(s) de arquivo 3. Executando o quotacheck Capítulo 5. Administrando o Armazenamento 109 4. Atribuindo quotas O arquivo /etc/fstab controla a montagem de sistemas de arquivo sob o Red Hat Enterprise Linux. Como as quotas de disco são implementadas por sistema de arquivo, há duas opções — usrquota e grpquota — que devem ser adicionadas a este arquivo para ativar as quotas de disco. A opção usrquota ativa as quotas de disco do usuário, enquanto a opção grpquota ativa as quotas de disco do grupo. Uma ou ambas opções podem ser ativadas ao inserí-las no campo de opções para o sistema de arquivo desejado. O(s) sistema(s) de arquivo afetado(s) deve(m) então ser desmontado(s) e remontado(s) para que as opções relativas às quotas de disco tenham efeito. Em seguida, o comando quotacheck é usado para criar a quota de disco e para coletar as informações de uso corrente de arquivos já existentes. Os arquivos de quota de disco (nomeados aquota.user e aquota.group, para quotas de usuário e de grupo) contém as informações necessárias relativas às quotas e residem no diretório root do sistema de arquivo. O comando edquota é usado para atribuir quotas de disco. Este utilitário usa um editor de texto para exibir as informações de quota para usuário ou grupo, especificadas como parte do comando edquota. Aqui está um exemplo: Disk quotas for user matt (uid 500): Filesystem blocks soft /dev/md3 6618000 0 hard 0 inodes 17397 soft 0 hard 0 Isso nos mostra que o usuário matt está usando mais que 6GB de espaço em disco e mais que 17.000 inodes. Nenhuma quota (suave ou rígida) foi determinada para blocos ou inodes do disco, o que significa que não há limite para o espaço ou inodes em disco que este usuário pode utilizar no momento. Usando o editor de texto que apresenta as informações de quota de disco, o administrador de sistemas pode então modificar os limites suaves e rígidos conforme desejar: Disk quotas for user matt (uid 500): Filesystem blocks soft /dev/md3 6618000 6900000 hard 7000000 inodes 17397 soft 0 hard 0 Neste exemplo, o usuário matt recebeu um limite suave de 6.9GB e um limite rígido de 7GB. Não foram determinados limites suave ou rígido nos inodes para este usuário. Dica O programa edquota também pode ser usado para determinar o período de carência por sistema de arquivo, usando a opção -t. 5.9.7.3. Administrando Quotas de Disco Na realidade, há pouco trabalho administrativo para suportar as quotas de disco sob o Red Hat Enterprise Linux. Essencialmente, é necessário: • Gerar relatórios do uso do disco em intervalos regulares (e acompanhar os usuários que parecem ter problemas em administrar efetivamente seu espaço alocado no disco) • Garantir que as quotas de disco permaneçam corretas Criar um relatório do uso do disco implica rodar o utilitário repquota. Usar o comando repquota /home produz este output: 110 Capítulo 5. Administrando o Armazenamento *** Report for user quotas on device /dev/md3 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------root -32836 0 0 4 0 0 matt -- 6618000 6900000 7000000 17397 0 0 Mais informações sobre o repquota podem ser encontradas no Guia de Administração de Sistemas Red Hat Enterprise Linux, no capítulo sobre quotas de disco. Sempre que um sistema de arquivo não é desmontado de maneira limpa (devido uma queda do sistema, por exemplo), é necessário rodar o quotacheck. No entanto, muitos administradores de sistemas recomendam rodar o quotacheck regularmente, mesmo que o sistema não tenha sofrido uma queda. O processo é similar ao uso inicial do quotacheck ao ativar as quotas de disco. Aqui está um exemplo do comando quotacheck: quotacheck -avug A maneira mais fácil de executar o quotacheck regularmente é usar o cron. A maioria dos administradores de sistemas executam o quotacheck uma vez por semana, mas pode haver motivos racionais para usar um intervalo mais longo ou mais curto, dependendo de suas condições específicas. 5.9.8. Criando Conjuntos RAID Além de suportar as soluções RAID de hardware, o Red Hat Enterprise Linux também suporta o RAID de software. Há duas maneiras de criar conjuntos RAID de software: • Ao instalar o Red Hat Enterprise Linux • Após o Red Hat Enterprise Linux ter sido instalado As seções seguintes trazem uma revisão destes dois métodos. 5.9.8.1. Ao Instalar o Red Hat Enterprise Linux Durante o processo normal de instalação do Red Hat Enterprise Linux, os conjuntos RAID podem ser criados. Isso é feito durante a fase de particionamento do disco na instalação. Para começar, você deve particionar manualmente seus drives de disco usando o Disco Druid. Primeiro, você deve criar uma nova partição do tipo "RAID de software." Em seguida, selecione os drives de disco que comporão o conjunto RAID no campo Discos Permitidos. Continue o processo selecionando o tamanho desejado e se você deseja que a partição seja primária. Uma vez criadas todas as partições necessárias para o(s) conjunto(s) RAID que você deseja criar, use o botão RAID para realmente criar os conjuntos. Lhe será apresentada uma caixa de diálogo na qual você pode selecionar o ponto de montagem do conjunto, o tipo do sistema de arquivo, o nome do dispositivo RAID e as partições "RAID de software" nas quais este conjunto será baseado. Uma vez criados os conjuntos desejados, o processo de instalação continua normalmente. Capítulo 5. Administrando o Armazenamento 111 Dica Para mais informações sobre a criação de conjuntos RAID de software durante o processo de instalação do Red Hat Enterprise Linux, consulte o Guia de Administração de Sistemas Red Hat Enterprise Linux. 5.9.8.2. Após o Red Hat Enterprise Linux Ser Instalado Criar um conjunto RAID após a instalação do Red Hat Enterprise Linux é um pouco mais complexo. Assim como a adição de qualquer tipo de armazenamento de disco, é necessário primeiro instalar o hardware e configurá-lo corretamente. O particionamento é um pouco diferente para o RAID do que para drives de disco. Ao invés de selecionar um tipo de partição "Linux" (tipo 83) ou "Linux swap" (tipo 82), todas as partições que farão parte do conjunto RAID devem ser do tipo "Linux raid auto" (tipo fd). Em seguida, é necessário criar o arquivo /etc/raidtab. Esse arquivo é responsável pela configuração apropriada de todos os conjuntos RAID no seu sistema. O formato do arquivo (documentado na página man raidtab(5)) é relativamente simples. Eis um exemplo de entrada /etc/raidtab para um conjunto RAID 1: raiddev /dev/md0 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 nr-spare-disks 0 device /dev/hda2 raid-disk 0 device /dev/hdc2 raid-disk 1 Algumas das seções mais notáveis desta seção são: • raiddev — Exibe o nome do arquivo do dispositivo para o conjunto RAID 12 • raid-level — Define o nível do RAID a ser usado por este conjunto • nr-raid-disks — Indica quantas partições físicas de disco devem fazer parte deste conjunto — O RAID de software sob o Red Hat Enterprise Linux permite a definição de uma ou mais partições reservas; estas partições podem tomar o lugar de um disco com mau funcionamento automaticamente • nr-spare-disks • device, raid-disk RAID — Juntos, definem as partições físicas do disco que compoem o conjunto Em seguida, é necessário realmente criar o conjunto RAID. Isso é feito no programa mkraid. Usando nosso arquivo /etc/raidtab exemplo, podemos criar o conjunto RAID /dev/md0 com o seguinte comando: mkraid /dev/md0 O conjunto RAID /dev/md0 agora está pronto para ser formatado e montado. Neste ponto, o processo não é diferente de formatar e montar um único drive de disco. 12. Note que, como o conjunto RAID é composto de espaço particionado em disco, o nome do arquivo do dispositivo de um conjunto RAID não reflete nenhuma informação no nível da partição. 112 Capítulo 5. Administrando o Armazenamento 5.9.9. Administração Diária de Conjuntos RAID Há pouco a ser feito para manter um conjunto RAID operante. Contanto que não ocorram problemas de hardware, o conjunto deve funcionar como se fosse um único drive de disco físico. No entanto, assim como um administrador de sistemas deve verificar periodicamente o status de todos os drives de disco do sistema, o status dos conjuntos RAID também deve ser verificado. 5.9.9.1. Verificando o Status do Conjunto Com /proc/mdstat O arquivo /proc/mdstat é a maneira mais fácil de verificar o status de todos os conjuntos RAID de um determinado sistema. Aqui está uma amostra do mdstat (visualize com o comando cat /proc/mdstat): Personalities : [raid1] read_ahead 1024 sectors md1 : active raid1 hda3[0] hdc3[1] 522048 blocks [2/2] [UU] md0 : active raid1 hda2[0] hdc2[1] 4192896 blocks [2/2] [UU] md2 : active raid1 hda1[0] hdc1[1] 128384 blocks [2/2] [UU] unused devices: none Neste sistema, há três conjuntos RAID (todos RAID 1). Cada conjunto RAID tem sua própria seção no /proc/mdstat e contém as seguntes informações: • O nome do dispositivo do conjunto RAID (excluindo a parte /dev/) • O status do conjunto RAID • O nível RAID do conjunto RAID • As partições físicas que formam o conjunto (seguidas pelo número da unidade do conjunto da partição) • O tamanho do conjunto • O número de dispositivos confiugrados versus o número de dispositivos operantes no conjunto • O status de cada dispositivo configurado do conjunto (U significa que o dispositivo está OK e _ indica que o dispositivo falhou) 5.9.9.2. Recriando um conjunto RAID com o raidhotadd Caso o /proc/mdstat indique que há um problema com um dos conjuntos RAID, o utilitário raidhotadd deve ser usado para recriar o conjunto. Aqui estão os passos a seguir: 1. Determinar qual drive de disco contém a partição falha 2. Corrigir o problema que causou a falha (provavelmente substituindo o drive) 3. Particionar o novo drive para que as partições contidas neste sejam idênticas àquelas do(s) outro(s) drive(s) do conjunto 4. Atribuir o seguinte comando: raidhotadd raid-device disk-partition 5. Monitorar o /proc/mdstat para observar a recriação ocorrendo Capítulo 5. Administrando o Armazenamento 113 Dica Aqui está um comando que pode ser usado para observar a recriação conforme ocorre: watch -n1 cat /proc/mdstat Esse comando exibe o conteúdo do /proc/mdstat, atualizando-o a cada segundo 5.9.10. Administração de Volume Lógico (Logical Volume Management) O Red Hat Enterprise Linux inclui suporte ao LVM. O LVM pode ser configurado durante a instalação do Red Hat Enterprise Linux, ou após a instalação. O LVM sob o Red Hat Enterprise Linux suporta o agrupamento de armazenamento físico, redimensionamento de volume lógico e a migração de dados de um determinado volume físico. Para mais informações sobre o LVM, consulte o Guia de Administração de Sistemas Red Hat Enterprise Linux. 5.10. Recursos Adicionais Esta seção inclui diversos recursos que podem ser usados para aprender mais sobre tecnologias de armazenamento e sua relação com o Red Hat Enterprise Linux. 5.10.1. Documentação Instalada Os recursos seguintes são instalados no decorrer de uma típica instalação do Red Hat Enterprise Linux e podem ajudá-lo a aprender mais sobre o assunto abordado neste capítulo. • Página man exports(5) — Aprenda mais sobre o formato do arquivo de configuração do NFS. • Página man fstab(5) — Aprenda mais sobre o formato do arquivo de configuração das informaçõ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 montados. • 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 Management, LVM). • Página man devlabel(8) — Aprenda sobre o acesso ao dispositivo de armazenamento persistente. 5.10.2. Sites Úteis • http://www.pcguide.com/ — Um bom site para todo tipo de informação sobre diversas tecnologias de armazenamento. • http://www.tldp.org/ — O Projeto de Documentação do Linux tem HOWTOs e mini-HOWTOs que oferecem uma boa visão geral das tecnologias de armazenamento e seu relacionamento com o Linux. 5.10.3. Livros Relacionados Os livros seguintes abordam diversas questões relacionadas ao armazenamento e são bons recursos para administradores de sistemas Red Hat Enterprise Linux. • O Guia de Instalação do Red Hat Enterprise Linux; Red Hat, Inc. — Contém instruções para particionar discos rígidos durante a instalação do Red Hat Enterprise Linux assim como uma visão geral das partições de disco. • O Guia de Referência do Red Hat Enterprise Linux; Red Hat, Inc. — Contém informações detalhadas 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ítulos 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 usando um computador. Uma razão secundária (mas importante) é permitir a personalização de recursos e privilégios de acesso por indivíduo. Os recursos podem incluir arquivos, diretórios e dispositivos. Controlar o acesso a estes recursos é uma grande parte da rotina diária de um administrador de sistemas. Frequentemente o acesso a um recurso é controlado por grupos. Grupos são formações lógicas que podem ser usadas para agrupar contas de usuários para um propósito comum. Por exemplo: se uma empresa tem diversos administradores de sistemas, eles podem ser alocados em um grupos de administradores de sistemas. O grupo, então, pode receber permissões para acessar recursos sensíveis do sistema. Desta maneira, os grupos podem ser uma ferramenta poderosa para administrar recursos e acesso. As seções seguintes abordam contas de usuário e grupos com mais detalhes. 6.1. Administrando Contas de Usuário Como mencionado anteriormente, as contas de usuário são o método através do qual um indivíduo é identificado e autenticado no sistema. As contas de usuário têm diversos componentes. Primeiro, há um nome de usuário (username). Em seguida, a senha (password), seguida pelas informações de controle de acesso. As seções seguintes exploram cada um destes componentes com mais detalhes. 6.1.1. O Nome de Usuário Do ponto de vista do sistema, o nome de usuário é a resposta à pergunta: "quem é você?" Como tal, o nome de usuário tem um requisito principal — deve ser único. Em outras palavras, cada usuário deve ter um nome de usuário diferente de todos os outros nomes de usuários no sistema. Em função deste requisito, é vital determinar — com antecedência — como os nomes de usuário devem ser criados. Caso contrário, você pode se ver obrigado a intervir cada vez que um novo usuário requisitar uma conta. Você precisa de uma convenção de nomenclatura para suas contas de usuário. 6.1.1.1. Convenções de Nomenclatura Ao criar uma convenção de nomenclatura para nomes de usuário, você pode evitar diversos problemas. Ao invés de inventar nomes ao longo do curso (e enfrentar a dificuldade de inventar um nome razoável toda vez), você antecipa seu trabalho e impõe uma convenção a ser usada para todas as contas de usuário subsequentes. Sua convenção de nomenclatura pode ser muito simples ou então, apenas sua descrição, pode ter diversas páginas documentadas. A natureza da sua convenção de nomenclatura deve considerar diversos fatores: • O tamanho de sua empresa • A estrutura de sua empresa 116 • Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos A natureza de sua empresa O tamanho de sua empresa importa, pois dita quantos usuários sua convenção de nomenclatura deve suportar. Por exemplo: numa micro empresa pode ser possível que todos usem seu primeiro nome. Para uma empresa bem maior, essa convenção de nomenclatura não funcionará. A estrutura de uma empresa também pode influenciar a convenção de nomenclatura mais apropriada. Em empresas com estruturas rígidas, pode ser apropriado incluir elementos da estrutura na convenção de nomenclatura. Por exemplo: você pode incluir os códigos dos departamentos de sua empresa como parte de cada nome de usuário. A natureza da sua empresa também pode significar que algumas convenções de nomenclatura são mais apropriadas que outras. Um empresa que lida com dados altamente ordenados pode escolher uma convenção de nomenclatura que elimina quaisquer laços de identificação pessoal entre o indivíduo e seu nome. Numa empresa deste tipo, o nome de usuário João da Silva poderia ser LUH3417. Aqui estão algumas convenções de nomenclatura que outras empresas utilizaram: • Primeiro nome (joão, paulo, jorge, etc.) • Último nome (silva, pereira, pontes, etc.) • Primeira inicial, seguida do último nome (jsilva, ppereira, jpontes, etc.) • Último nome, seguido do código do departamento (silva029, pereira454, pontes191, etc.) Dica Atenção: se a sua convenção de nomenclatura inclui a junção de dados diferentes para formar um nome de usuário, existe a possibilidade do resultado ser hilário ou ofensivo. Portanto, mesmo se você tiver automatizado a criação dos nomes de usuário, é aconselhável ter algum tipo de revisão no processo. As convenções de nomenclatura abordadas aqui têm em comum a possibilidade de existirem dois indivíduos que, de acordo com a convenção, devem ter os mesmos nomes de usuário. Isto é conhecido como uma colisão. Como cada nome de usuário deve ser único, é necessário resolver a questão das colisões. A seção seguinte aborda este assunto. 6.1.1.1.1. Resolvendo as Colisões Colisões ocorrem de fato — não importa o quanto você tenta, ocasionalmente você deverá resolvêlas. Você deve planejar como lidar com as colisões em sua convenção de nomenclatura. Há diversas maneiras de fazer isso: • Adicionar números sequenciais ao nome de usuário colidido (silva, silva1, silva2, etc.) • Adicionar dados específicos do usuário ao nome de usuário colidido (silva, esilva, eksilva, etc.) • Adicionar informações da empresa ao nome de usuário colidido (silva, silva029, silva454, etc.) Ter algum método de resolver colisões é uma parte necessária de qualquer convenção de nomenclatura. No entanto, esta dificulta que alguém de fora da empresa determine o nome de usuário de um indivíduo corretamente. Portanto, a desvantagem da maioria das convenções de nomenclatura é a maior probabilidade do envio incorreto de e-mails. Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 117 6.1.1.2. Resolvendo Alterações de Nome Se a sua empresa utiliza uma convenção de nomenclatura baseada no nome de cada usuário, é certeza que você terá que lidar com alterações de nome em algum momento. Mesmo que o nome verdadeiro de uma pessoa não mude, será necessário alterar alguns nomes de usuários de tempos em tempos. As razões podem variar; desde o usuário não estar satisfeito com seu nome de usuário até o fato do usuário ser um gerente sênior da empresa e querer usar sua influência para obter um nome de usuário "mais apropriado". Independente da razão, há diversas questões a considerar ao alterar um nome de usuário: • Efetue a alteração em todos os sistemas afetados • Mantenha quaisquer identificações do usuário constantes • Altere a propriedade (ownership) de todos os arquivos e outros recursos específicos do usuário (se necessário) • Resolva questões relacionadas a e-mail Primeiramente, é importante garantir que o novo nome de usuário seja propagado para todos os sistemas nos quais o nome de usuário original foi usado. Caso contrário, qualquer função do sistema operacional baseada no nome do usuário pode funcionar em alguns sistemas e não funcionar em outros. Determinados sistemas operacionais utilizam técnicas de controle de acesso baseadas em nomes de usuário; tais sistemas têm uma vulnerabilidade relacionada a problemas originados a partir de um nome de usuário alterado. Muitos sistemas operacionais utilizam alguma espécie número de identificação do usuário para a maioria do processamento específico ao usuário. Para minimizar os problemas oriundos da alteração de um nome de usuário, tente manter este número de identificação constante entre os nomes do usuário novo e velho. Caso contrário, é provável ter um cenário no qual o usuário não consegue mais acessar arquivos e outros recursos que previamente possuía sob o nome de usuário original. Se o número de identificação do usuário deve ser alterado, é necessário alterar a propriedade (ownership) de todos os arquivos e recursos específicos ao usuário para refletir a nova identificação do usuário. Este pode ser um processo propenso a erros, já que parece que sempre há algo esquecido em algum canto que acaba sendo negligenciado. As questões relacionadas a e-mails provavelmente representam a área mais difícil para uma alteração de nome de usuário. A razão disto é que, a não ser que sejam tomadas ações para contra-atacar, os e-mails destinados ao nome de usuário velho não serão entregues ao nome de usuário novo. Infelizmente, as questões que permeam o impacto das alterações de nome de usuário em e-mails são multi-dimensionais. No mínimo, uma alteração de nome de usuário significa que as pessoas não sabem mais o nome de usuário correto da pessoa. À primeira vista, este não parece ser um grande problema — notificar a todos de sua empresa sobre a alteração. Mas, e quanto às pessoas fora da empresa que enviaram e-mails para esta pessoa? Como elas devem ser notificadas? E as listas de discussão (internas e externas)? Como elas podem ser atualizadas? Não há uma resposta simples para estas questões. A melhor resposta talvez seja criar um codenome de e-mail, de modo que todos os e-mails enviados ao nome de usuário velho sejam automaticamente encaminhados ao novo nome de usuário. O usuário pode ser aconselhado a alertar todos que enviam e-mails para ele, que seu nome de usuário foi alterado. Com o passar do tempo, menos e-mails serão entregues usando o codenome; eventualmente o codenome pode ser removido. Enquanto o uso de codenome, de alguma maneira, perpetua uma suposição incorreta (de que o usuário agora conhecido como esilva ainda é conhecido como jpontes), é a única maneira de garantir que o e-mail seja entregue à pessoa correta. 118 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos Importante Se você usar codenome de e-mail, certifique-se de executar todos os passos necessários para proteger o nome de usuário velho de re-utilização. Se você não fizer isso e um novo usuário receber o nome de usuário velho, a entrega de e-mails (para ambos, o usuário original ou o novo) pode ser interrompida. A razão exata da interrupção depende de como a entrega de e-mails é implementada em seu sistema operacional, mas os dois sintomas mais prováveis são: • O novo usuário nunca recebe nenhum e-mail — todos são entregues para o usuário original. • O usuário original para de receber e-mails repentinamente — todos são entregues para o novo usuário. 6.1.2. Senhas Se o nome de usuário oferece uma resposta para a pergunta "quem é você?", a senha é a resposta para o pedido que segue inevitavelmente: "Prove!" Em termos mais formais, uma senha oferece um meio de provar a autenticidade da afirmação de uma pessoa ser o usuário indicado pelo nome de usuário. A eficiência de um esquema de autenticação com senha baseia-se em diversos aspectos da senha: • A discrição de senha • A resistência da senha em ser descoberta • A resistência da senha a um ataque brute-force As senhas que atendem estes requisitos são chamadas de fortes, enquanto aquelas que não atendem um ou mais requisitos são chamadas de fracas. É importante criar senhas fortes para a segurança da empresa, já que este tipo de senha tem menor probabilidade de ser descoberta. Há duas opções para reforçar o uso de senhas fortes: • O administrador de sistemas pode criar senhas para todos os usuários. • O administrador de sistemas pode deixar que os usuários criem suas próprias senhas, enquanto verifica se as senhas são aceitáveis. Criar senhas para todos os usuários garante que sejam fortes, mas torna-se uma tarefa desanimadora conforme a empresa cresce. Também aumenta o risco dos usuários anotarem suas senhas. Por estes motivos, a maioria dos administradores de sistemas preferem que seus usuários criem suas próprias senhas. Entretanto, um bom administrador de sistemas executa alguns passos para garantir que as senhas sejam fortes. Para obter instruções sobre a criação de senhas fortes, veja o capítulo intitulado Segurança da Estação de Trabalho no Guia de Segurança do Red Hat Enterprise Linux. A necessidade de manter as senhas secretas deve ser uma parte intrínseca da mentalidade de todo administrador de sistemas. No entanto, este aspecto é frequentemente esquecido por muitos usuários. De fato, muitos usuários não entendem a diferença entre nomes de usuários e senhas. Portanto, é vital oferecer alguma forma de educação neste aspecto para os usuários, para que eles entendam que suas senhas devem ser tão bem guardadas quanto seus holeriths. As senhas devem ser o mais difícil possível de serem descobertas. Uma senha forte é aquela que o atacante não consegue descobrir, mesmo que ele também conheça o usuário. Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 119 Um ataque brute-force a uma senha envolve tentar metodicamente (geralmente através de um programa conhecido como password-cracker) todas as combinações possíveis de caracteres na esperança de que a senha correta seja eventualmente encontrada. Uma senha forte deve ser construída de maneira a tornar o número de senhas a testar muito grande, forçando o atacante a levar bastante tempo na procura da senha. As senhas fortes e fracas são abordadas detalhadamente nas seções seguintes. 6.1.2.1. Senhas Fracas Como explanado anteriormente, uma senha fraca falha em um destes três testes: • É secreta • É resistente a ser descoberta • É resistente a um ataque brute-force As seções seguintes mostram como as senhas podem ser fracas. 6.1.2.1.1. Senhas Curtas Um senha curta (breve) é fraca porque é mais suscetível a um ataque brute-force. Para ilustrar isto, considere a tabela seguinte, onde o número de senhas potenciais que devem ser testadas num ataque brute-force é exibido. (Assume-se que as senhas consistem somente de letras em caixa baixa.) Tamanho da Senha Senhas Potenciais 1 26 2 676 3 17.576 4 456.976 5 11.881.376 6 308.915.776 Tabela 6-1. Tamanho da Senha Versus o Número de Senhas Potenciais Como você pode ver, o número de senhas possíveis aumenta dramaticamente conforme seu tamanho aumenta. Nota Apesar desta tabela terminar com seis caracteres, isto não é uma afirmação de que senhas de seis caracteres sejam longas o suficiente para uma boa segurança. Em geral, quanto mais longa a senha, melhor. 6.1.2.1.2. Conjunto de Caracteres Limitado O número de caracteres diferentes que podem compor uma senha tem um alto impacto na habilidade de um atacante conduzir um ataque brute-force. Por exemplo: ao invés de 26 caracteres diferentes que podem ser usados numa senha composta apenas de caixa baixa, por que não usamos também dígitos? Isto significa que cada caractere de uma senha pode ser um dos 36 caracteres ao invés de apenas 26. 120 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos No caso de uma senha de seis caracteres, isto aumenta o número de senhas possíveis de 308.915.776 para 2.176.782.336. Ainda há mais que pode ser feito. Se nós também incluirmos caixa alta e baixa nas senhas alfanuméricas (para aqueles sistemas operacionais que as suportam), o número de senhas possíveis de seis caracateres aumenta para 56.800.235.584. Adicionando outros caracteres (tais como pontuação) aumenta ainda mais o número de senhas possíveis, tornando ainda mais difícil um ataque brute-force. No entanto, tenha em mente que nem todo ataque contra uma senha é um ataque brute-force. As seções seguintes descrevem outros atributos que podem formar uma senha fraca. 6.1.2.1.3. Palavras Reconhecíveis Muitos ataques contra senhas são baseados no fato da maioria das pessoas se sentirem mais confortáveis com senhas que possam lembrar. E, para a maioria das pessoas as senhas memoráveis são aquelas que contêm palavras. Consequentemente, a maioria dos ataques a senhas são baseados no dicionário. Em outras palavras, o atacante utiliza dicionários de palavras para tentar encontrar a palavra ou palavras que formam uma senha. Nota Muitos programas de ataque a senhas baseadas em dicionário usam dicionários de múltiplos idiomas. Consequentemente, você não pode acreditar que tem uma senha forte apenas porque utilizou palavras não inglesas na sua senha. 6.1.2.1.4. Informações Pessoais Senhas que contêm informações pessoais (o nome ou data de aniversário de uma pessoa querida, de um animal de estimação ou um número de identificação pessoal) podem ou não ser pegas por um ataque a senha baseada em dicionário. No entanto, se o atacante te conhece pessoalmente (ou está suficientemente motivado a pesquisar sua vida pessoal), ele pode ser capaz de adivinhar sua senha com nenhuma ou pouca dificuldade. Além dos dicionários, muitos crackers de senhas incluem nomes comuns, datas e outras informações deste tipo em suas procuras por senhas. Portanto, mesmo que o atacante não saiba que o nome do seu cachorro é Duque, ainda podem descobrir que sua senha é "meucaoduque" com um bom cracker de senhas. 6.1.2.1.5. Truques com Palavras Simples Usar quaisquer das informações abordadas anteriormente é a base de uma senha, mas inverter a ordem dos caracteres não torna uma senha fraca numa senha forte. Muitos crackers de senhas executam este tipo de truques em senhas possíveis. Isto inclui substituir determinados números por letras em palavras comuns. Aqui estão alguns exemplos: • drowssaPdaB1 • R3allyP00r Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 121 6.1.2.1.6. A Mesma Senha para Múltiplos Sistemas Mesmo que você tenha uma senha forte, é uma má idéia usar exatamente a mesma senha em mais de um sistema. Obviamente, há pouco a ser feito se os sistemas estão configurados para usar algum tipo de servidor de autenticação central, mas em todos os outros casos, deve-se usar senhas diferentes para cada sistema. 6.1.2.1.7. Senhas no Papel Uma outra maneira de enfraquecer uma senha é anotá-la. Ao escrever uma senha num papel, você não tem mais um problema de discrição, mas sim um problema de segurança física — agora você deve proteger um pedaço de papel. Consequentemente, anotar uma senha nunca é uma boa idéia. No entanto, algumas empresas têm uma necessidade legítima de senhas escritas. Por exemplo: algumas empresas têm senhas escritas como parte do procedimento de recuperação após a perda de funcionários chave (tais como administradores de sistemas). Nestes casos, o papel contendo as senhas é armazenado num local protegido fisicamente, que requer a cooperação de diversas pessoas para acessar o papel. Passagens com vários cadeados e cofres de banco são frequentemente usados. Qualquer empresa que utiliza este método de armazenar senhas para emergências deve estar ciente de que a existência de senhas escritas adiciona um elemento de risco à segurança de seus sistemas. Não importa o quão protegidas estejam as senhas escritas, principalmente se é de conhecimento geral que as senhas estão escritas (e onde estão armazenadas). Infelizmente, as senhas escritas frequentemente não fazem parte de um plano de recuperação e não são armazenadas com segurança, mas são senhas de usuários comuns, armazenadas nos seguintes locais: • Na gaveta da mesa (trancada ou não) • Em baixo de um teclado • Numa carteira • Anexo ao lado de um monitor Nenhum destes locais são apropriados para armazenar uma senha escrita. 6.1.2.2. Senhas Fortes Nós já vimos como se parecem as senhas fracas; as seções seguintes abordam características presentes em todas as senhas fortes 6.1.2.2.1. Senhas Mais Longas Quanto mais longa a senha, menor a possibilidade de um ataque brute-force ser bem sucedido. Consequentemente, se o seu sistema operacional a suporta, defina um tamanho mínimo relativamente grande para as senhas de seus usuários. 6.1.2.2.2. Conjunto de Caracteres Expandido Estimule o uso de caixas alta e baixa, senhas alfa-numéricas e recomende fortemente a adição de pelo menos um caracter não alfa-numérico em todas as senhas: • t1Te-Bf,te • Lb@lbhom 122 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 6.1.2.2.3. Memorável Uma senha é forte se pode ser lembrada. Entretanto, ser memorável e de fácil descoberta frequentemente andam juntas. Sendo assim, ofereça à sua comunidade de usuários algumas dicas para a criação de senhas memoráveis que não podem ser facilmente descobertas. Por exemplo: pense numa frase ou ditado favorito e use as primeiras letras de cada palavra como o ponto de partida para a criação de uma nova senha. O resultado é memorável (porque a frase na qual baseia-se é memorável), mas não contém palavras. Nota Tenha em mente que usar apenas as primeiras letras de cada palavra de frase não é o suficiente para criar uma senha forte. Certifique-se de sempre aumentar o conjunto de caracteres da senha, incluindo caracteres alfa-numéricos em caixas alta e baixa e, pelo menos, um caracter especial também. 6.1.2.3. Expiração de Senhas Se for possível, implemente a expiração de senhas na sua empresa. A expiração de senhas é uma funcionalidade (disponível em diversos sistemas operacionais) que define limites de tempo para uma senha ser considerada válida. No fim da vida de uma senha, o usuário deve inserir uma nova senha, que pode ser usada até que (esta também) expire. A principal questão relacionada à expiração de senhas vivenciada por muitos administradores de sistemas é o tempo de vida da senha. Quão longo deve ser? Há duas questões cruciais e opostas relacionadas à expiração de senhas: • Conveniência do usuário • Segurança Em um extremo, o tempo de vida de uma senha de 99 anos apresentaria pouca (ou nenhuma) inconveniência para o usuário. No entanto, ofereceria muito pouca (ou nenhuma) melhoria na segurança. No outro extremo, uma senha com tempo de vida de 99 minutos seria uma grande inconveniência para seus usuários. Entretanto, a segurança seria bem maior. A idéia é encontrar um equilíbrio entre a conveniência requerida por seus usuários e a necessidade de segurança de sua empresa. Para a maioria das empresas, o tempo de vida da senha no intervalo de semanas a meses é o mais comum. 6.1.3. Informações de Controle de Acesso Juntamente ao nome de usuário e senha, as contas de usuário contêm informações de controle de acesso. Estas informações têm formatos diferentes de acordo com o sistema operacional. No entanto, os tipos de informação geralmente incluem: • Identificação específica do usuário para todo o sistema • Identificação específica do grupo para todo o sistema • Listas de grupos/funcionalidades adicionais às quais o usuário pertence Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos • 123 Informações de acesso default a serem aplicadas para todos os arquivos e recursos criados pelo usuário Em algumas empresas, as informações de controle de acesso do usuário talvez nunca precisem ser alteradas. Isto é mais frequente nos casos com standalone e estações de trabalho pessoais, por exemplo. Outras empresas, especialmente aquelas que utilizam extensivamente o compartilhamento de recursos entre diferentes grupos de usuários através da rede, requerem que as informações de controle de acesso do usuário sejam bastante modificadas. A carga de trabalho necessária para manter corretamente as informações de controle de acesso do usuário varia de acordo com a escala do uso que sua empresa faz das funcionalidades de controle de acesso do sistema operacional. Apesar de não ser ruim confiar veementemente nestas funcionalidades (talvez seja inevitável), significa que o ambiente de seu sistema pode precisar de um esforço maior para ser mantido, e que todas as contas de usuário têm maior probabilidade de serem configuradas incorretamente. Consequentemente, se sua empresa requer este tipo de ambiente, você deve certificar-se de documentar exatamente os passos necessários para criar e configurar corretamente a conta de usuário. De fato, se há tipos diferentes de contas de usuário, você deve documentar cada uma delas (como criar uma nova conta de usuário da área financeira, da área de operações, etc.). 6.1.4. Administrando Contas e Acesso a Recursos no Dia-a-Dia Como diz o velho ditado: a única constante é a mudança. E não é diferente ao lidar com sua comunidade de usuários. Pessoas vêm e vão, mudam de um conjunto de responsabilidades para outro. Sendo assim, administradores de sistemas devem ser capazes de responder às mudanças, muito comuns no dia-a-dia das empresas. 6.1.4.1. Novas Contratações Quando uma nova pessoa é contratada pela empresa, normalmente recebe acesso a vários recursos (de acordo com suas responsabilidades). Provavelmente, ela recebe uma mesa para trabalhar, um aparelho de telefone e uma chave da porta principal. Talvez ela também receba acesso a um ou mais computadores de sua empresa. Como administrador de sistemas, é sua responsabilidade executar esta tarefa rápida e apropriadamente. Como você deve fazer isso? Antes de qualquer coisa, você deve estar ciente da chegada desta pessoa. Isto é feito de maneiras diferentes em empresas diversas. Aqui estão algumas possibilidades: • Crie um processo no qual o departamento de recursos humanos de sua empresa te notifica a chegada de um novo funcionário. • Crie um formulário a ser preenchido pelo supervisor do novo funcionário e usado para requerer uma nova conta. Empresas diferentes requerem táticas diferentes. Independentemente de como é feito, é vital que você tenha um processo altamente confiável que possa alertá-lo sobre qualquer tarefa relacionada a contas a ser executada. 6.1.4.2. Desligamentos É fato que algumas pessoas deixarão sua empresa. Às vezes, isto ocorre sob circunstâncias felizes e outras vezes não. Em ambos os casos, é vital que você seja notificado da situação, para que possa executar as ações apropriadas. No mínimo, as ações apropriadas incluem: 124 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos • Desabilitar o acesso do usuário a todos os sistemas e recursos relacionados (geralmente alterando/bloqueando a senha do usuário) • Fazer um backup dos arquivos do usuário, caso contenham alguma informação futuramente necessária • Coordenar o acesso aos arquivos do usuário junto ao seu gerente A prioridade principal é proteger seus sistemas contra o funcionário recém-desligado. Isto é importante principalmente se o usuário foi desligado sob condições que o façam sentir-se prejudicado pela empresa. Entretanto, mesmo se as condições não forem tão ruins, é do interesse de sua empresa que você desabilite o acesso desta pessoa de maneira rápida e confiável. Isto indica a necessidade de um processo que te alerte sobre todos os desligamentos — de preferência, até antes do desligamento ocorrer. Sendo assim, é aconselhável você trabalhar junto ao departamento de recursos humanos de sua empresa para garantir que seja alertado sobre futuros desligamentos. Dica Quando você enfrentar "lock-downs" do sistema em virtude de desligamentos, é importante agir rapidamente. 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 desligamento 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émdesligado. Este backup pode ser parte do padrão de backups de sua empresa, ou pode ser um procedimento 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 circunstâncias, ter um backup possibilita recuperar os arquivos facilmente, facilitando o processo para o gerente e para você. Neste ponto, você deve determinar qual tipo de acesso o gerente do funcionário recém-desligado deve ter aos arquivos. Dependendo da empresa e da natureza das responsabilidades do ex-funcionário, pode não ser necessário nenhum acesso, ou então acesso a tudo. Se o ex-funcionário usou seus sistemas para algo além de e-mails ocasionais, é provável que o gerente tenha que examinar os arquivos, determinar o que deve ser guardado e o que deve ser descartado. Ao término deste processo, ao menos alguns destes arquivos devem ser dados à pessoa ou pessoas assumindo as responsabilidades do ex-funcionário. Talvez sua ajuda seja necessária neste último passo do processo, ou talvez o gerente possa resolvê-lo sozinho. Tudo depende dos arquivos e da natureza do trabalho de sua empresa. 6.1.4.3. Alterações de Função Responder aos pedidos de criação de contas para novos usuários e lidar com a sequência de eventos necessária para bloquear (lock-down) uma conta quando a pessoa é desligada são processos relativamente simples. No entanto, não é tão simples quando as responsabilidades de uma pessoa são alteradas dentro da empresa. Às vezes, a pessoa pode precisar de alterações em sua conta, outras vezes não. Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 125 Haverá ao menos três pessoas envolvidas para garantir que a conta do usuário seja reconfigurada corretamente para refletir suas novas responsabilidades: • Você • O gerente original do usuário • O novo gerente do usuário Dentre vocês três, deve ser possível determinar o que deve ser feito para encerrar de forma clara as responsabilidades velhas do usuário e as ações para preparar a conta do usuário para suas novas responsabilidades. Sob vários aspectos, este processo pode ser equiparado a encerrar uma conta de usuário existente e criar uma nova conta. De fato, algumas empresas fazem isto para todas as mudanças de responsabilidade. Entretanto, é mais provável que a conta do usuário seja mantida e alterada apropriadamente para suportar 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 responsabilidades da pessoa. Para complicar um pouco mais a situação, frequentemente existe um período de transição, no qual o usuário executa tarefas relacionadas aos dois conjuntos de responsabilidades. É neste ponto que os gerentes antigo e novo do usuário podem ajudá-lo, oferecendo-lhe um prazo para este período de transição. 6.2. Administrando Recursos do Usuário Criar contas de usuário é somente uma parte do trabalho de um administrador de sistemas. A administração dos recursos dos usuários também é essencial. Sendo assim, devemos considerar três pontos: • Quem pode acessar os dados compartilhados • Onde os usuários acessam estes dados • Quais são as barreiras para evitar o abuso de recursos As seções seguintes trazem uma breve revisão destes tópicos. 6.2.1. Quem Pode Acessar Dados Compartilhados O acesso de um usuário a uma determinada aplicação, arquivo ou diretório é determinado pelas permissões dadas à aplicação, ao arquivo ou ao diretório. Além disso, geralmente é útil conceder permissões diferentes a categorias diferentes de usuários. Por exemplo: o armazenamento temporário compartilhado deve ser capaz de evitar remoções acidentais (ou maléficas) dos arquivos de um usuário por outros usuários, enquanto deve permitir acesso completo ao proprietário (owner). Um outro exemplo é o acesso atribuído ao diretório home de um usuário. Somente o proprietário (owner) do diretório home deve ser capaz de criar ou visualizar arquivos ali. Os outros usuários devem ter todo o acesso negado (a não ser que o usuário queira o contrário). Isto aumenta a privacidade do usuário e evita a possível desapropriação de arquivos pessoais. Não obstante, há diversas situações nas quais usuários múltiplos precisam de acesso aos mesmos recursos de uma máquina. Nestes casos, pode ser necessário criar grupos compartilhados cuidadosamente. 126 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 6.2.1.1. Grupos Compartilhados e Dados Conforme mencionado na introdução, grupos são construções lógicas que podem ser usadas para agrupar contas de usuários para um propósito específico. Ao administrar os usuários de uma empresa, é bom identificar quais dados devem ser acessados por determinados departamentos, quais dados devem ser negados aos outros, e quais dados devem ser compartilhados entre todos. Determinar estas questões auxilia na criação de uma estrutura apropriada de grupos, juntamente às permissões apropriadas para os dados compartilhados. Por exemplo: assuma que o departamento de contas a receber deve manter uma lista das contas inadimplentes de seus pagamentos. Eles também devem compartilhar esta lista com o departamento de cobrança. Se as contas dos funcionários de ambos departamentos, contas a pagar e cobrança, são membros de um grupo chamado contas, estas informações podem ser inseridas num diretório compartilhado (de propriedade do grupo contas) com permissões de leitura e gravação (read and write) para o grupo no diretório. 6.2.1.2. Determinando a Estrutura dos Grupos Aqui estão alguns dos desafios enfrentados pelos administradores de sistemas ao criar os grupos: • Quais grupos criar • Quem deve ser inserido num determinado grupo • Que tipos de permissões estes recursos compartilhados devem ter É muito útil estabelecer uma estratégia de bom senso para estas questões. Uma das possibilidades é espelhar a estrutura de sua empresa na criação dos grupos. Por exemplo: se há um departamento de finanças, crie um grupo chamado finanças e torne todos os funcionários do departamento de finanças membros deste grupo. Se as informações financeiras são muito delicadas para a empresa como um todo, mas essenciais para os gerentes sêniors da empresa, então dê a eles permissões de grupo para acessar os diretórios e dados usados pelo departamento de finanças, adicionando todos os gerentes sêniors ao grupo finanças. Também é aconselhável ser cuidadoso ao conceder permissões aos usuários. Desta maneira, as informações delicadas têm menor probabilidade de cair em mãos erradas. Ao criar a estrutura de grupos de sua empresa desta maneira, é possível atender às necessidades de acesso a dados compartilhados de forma segura e eficaz. 6.2.2. Onde os Usuários Acessam os Dados Compartilhados Ao compartilhar dados entre usuários, é comum ter um servidor central (ou um grupo de servidores) que disponibiliza determinados diretórios para outras máquinas da rede. Desta maneira, os dados são armazenados em um lugar; não é necessário sincronizar os dados entre diversas máquinas. Antes de adotar esta estratégia, você deve primeiro determinar quais sistemas devem ter acesso aos dados armazenados centralmente. Ao fazer isso, anote os sistemas operacionais usados pelos sistemas. Estas informações são importantes para sua habilidade em implementar uma estratégia como esta, pois seu servidor de armazenamento deve ser capaz de servir seus dados para cada um dos sistemas operacionais utilizados na sua empresa. Infelizmente, uma vez que os dados são compartilhados entre os diversos computadores de uma rede, o potencial de conflitos pela propriedade do arquivo pode aumentar. Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 127 6.2.2.1. Questões de Propriedade (ownership) Global Há benefícios no caso dos dados serem armazenados centralmente e acessados por diversos computadores através de uma rede. Entretanto, assuma por um momento que cada um destes computadores tem uma lista de contas de usuários mantida localmente. E se a lista de usuários em cada um destes sistemas não for consistente com a lista de usuários no servidor central? Pior ainda, e se as listas de usuários em cada um destes sistemas não forem consistentes nem mesmo entre si? Muitas destas questões dependem de como os usuários e as permissões de acesso são implementadas em cada sistema, mas em alguns casos é possível o usuário A de um sistema ser conhecido como usuário B em outro sistema. Isto torna-se um problema latente quando os dados são armazenados entre estes dois sistemas, já que os dados que o usuário A tem permissão para acessar de um sistema também podem ser lidos pelo usuáro B de outro sistema. Por este motivo, muitas empresas usam algum tipo de banco de dados central dos usuários. Isto garante que não ocorra sobreposições entre as listas de usuários de sistemas diferentes. 6.2.2.2. Diretórios Home Uma outra questão enfrentada por administradores de sistemas é decidir se os usuários devem ou não ter diretórios home armazenados centralmente. A principal vantagem dos diretórios home centralizados num servidor ligado à rede é que, se o usuário se autenticar em qualquer máquina da rede, ele poderá acessar os arquivos de seu diretório home. A desvantagem é que, se a rede cair, os usuários da empresa toda não poderão acessar seus arquivos. Em algumas situações (como em empresas que adotam o uso geral de laptops), talvez não seja quisto ter diretórios home centralizados. Mas, se faz sentido para sua empresa, implementar diretórios home centralizados pode facilitar bastante a vida do administrador de sistemas. 6.2.3. Quais são as Barreiras Adotadas para Evitar o Abuso de Recursos A organização de grupos e a atribuição de permissões para recursos compartilhados feitos de maneira cuidadosa estão dentre as coisas mais importantes que um administrador de sistemas pode fazer para evitar o abuso de recursos dentre os usuários de uma empresa. Desta maneira, aqueles que não devem ter acesso aos recursos delicados têm o acesso negado. Não importa como a sua empresa se comporta; a melhor proteção contra o abuso de recursos é sempre a vigilância por parte do administrador de sistemas. Manter seus olhos bem abertos frequentemente é a única maneira de evitar uma surpresa desagradável esperando por você em sua mesa. 6.3. Informações Específicas do Red Hat Enterprise Linux As seções seguintes abordam as diversas funcionalidades específicas do Red Hat Enterprise Linux, relacionadas à administração de contas de usuário e recursos associados. 6.3.1. Contas de Usuário, Grupos e Permissões Sob o Red Hat Enterprise Linux, um usuário pode se autenticar no sistema e usar qualquer aplicação ou arquivo que tenha permissão para acessar, após a criação de uma conta de usuário normal. O Red Hat Enterprise Linux determina se um usuário ou grupo pode acessar estes recursos baseado nas permissões atribuídas a eles. 128 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos Há três tipos diferentes de permissões para arquivos, diretórios e aplicações. Estas permissões são usadas para controlar os tipos de acesso permitidos. São usados símbolos diferentes de um caractere cada para descrever cada permissão em uma listagem de diretórios. Os seguintes símbolos são usados: • r — Indica que uma determinada categoria de usuários pode ler (read) o arquivo. • w — Indica que uma determinada categoria de usuários pode gravar/escrever (write) no arquivo. — Indica que uma determinada categoria de usuários pode executar (execute) o conteúdo de um arquivo. • x Um quarto símbolo (-) indica que nenhum acesso é permitido. Cada uma das três permissões é atribuída a três categorias diferentes de usuários. As categorias são: • proprietário (owner) — O proprietário do arquivo ou aplicação. • grupo (group) — O grupo que detém o arquivo ou aplicação. • todos (everyone) — Todos os usuários com acesso ao sistema. Conforme exposto anteriormente, é possível visualizar as permissões de um arquivo invocando uma listagem de formato longo com o comando ls -l. Por exemplo: se o usuário juan criar um arquivo executável chamado foo, o output do comando ls -l foo seria parecido com: -rwxrwxr-x 1 juan juan 0 Sep 26 12:25 foo As permissões deste arquivo estão listadas no início da linha, começando com rwx. O primeiro conjunto 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 define os tipos de acesso para todos os outros usuários. Aqui, todos os outros usuários podem ler (read) e executar (execute) o arquivo, mas não podem modificá-lo de maneira alguma. Um ponto importante para ter em mente em relação às permissões e contas de usuário é que toda aplicação que roda no Red Hat Enterprise Linux, roda no contexto de um usuário específico. Isto significa que, se o usuário juan inicia uma aplicação, ela roda usando o contexto do usuário juan. No entanto, em alguns casos a aplicação pode precisar de um nível de acesso mais privilegiado para completar a tarefa. Este tipo de aplicação inclui aquelas que editam configurações do sistema ou autenticam usuários. Por esta razão, foram criadas permissões especiais. Há três tipos de permissões especiais no Red Hat Enterprise Linux: • setuid — usada somente para aplicações, esta permissão indica que a aplicação deve rodar como o proprietário do arquivo e não como o usuário executando a aplicação. É indicado pelo caractere s no lugar do x na categoria proprietário. Se o proprietário do arquivo não tem permissões para executar, o S torna-se maiúsculo para refletir este fato. • setgid — usado principalmente para aplicações, esta permissão indica que a aplicação deve rodar como o grupo que detém o arquivo, e não como o grupo do usuário executando a aplicação. Se aplicada a um diretório, todos os arquivos criados dentro do diretório são de propriedade do grupo que detém o diretório, e não do grupo do usuário criando o arquivo. A permissão setgid é indicada pelo caractere s no lugar do x na categoria grupo. Se o grupo proprietário do arquivo não tem permissão para executar, o S torna-se maiúsculo para refletir este fato. • sticky bit — usado principalmente em diretórios, este bit dita que um arquivo criado no diretório pode ser removido somente pelo usuário que criou o arquivo. É indicado pelo caractere t no lugar do x na categoria todos (everyone). Se a categoria todos não tem permissão para executar, o T torna-se maiúsculo para refletir este fato. Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 129 Sob o Red Hat Enterprise Linux, o sticky bit é definido por default no diretório /tmp/ exatamente por este motivo. 6.3.1.1. Nomes de Usuário e UIDs, Grupos e GIDs No Red Hat Enterprise Linux, as contas de usuário e nomes dos grupos são usadas principalmente para a conveniência das pessoas. Internamente, o sistema usa identificadores numéricos. Para os usuários, este identificador é conhecido como UID, enquanto que para os grupos, o identificador é conhecido como GID. Os programas que disponibilizam as informações do usuário ou grupo aos usuários traduzem os valores UID/GID para seus paralelos mais legíveis por humanos. Importante UIDs e GIDs devem ser globalmente únicos dentro da empresa, se você pretende compartilhar arquivos através da rede. Caso contrário, quaisquer controles de acesso que você tente implantar não funcionarão apropriadamente, já que são baseados nos UIDs e GIDs, e não nos nomes de usuários e grupos. Especificamente, se os arquivos /etc/passwd e /etc/group de um servidor de arquivos e de uma estação de trabalho de um usuário diferem nos UIDs ou GIDs que contêm, a atribuição inapropriada de permissões pode acarretar em problemas de segurança. Por exemplo: se o usuário juan tem um UID de 500 em um computador, os arquivos que juan criar num servidor de arquivos terão o UID 500 no proprietário. Entretanto, se o usuário bob se autenticar localmente ao servidor de arquivos (ou mesmo num outro computador), e a conta do bob também tiver um UID de 500, bob terá acesso total aos arquivos de juan e vice-versa. Consequentemente, as colisões de UID e GID devem ser evitadas a todo custo. Há duas instâncias nas quais o valor numérico corrente de um UID ou GID tem algum significado específico. Um UID e GID de zero (0) são usados para o usuário root e são tratados especialmente pelo Red Hat Enterprise Linux — o acesso total é atribuído automaticamente. A segunda instância é que UIDs e GIDs abaixo de 500 são reservados para uso do sistema. Ao contrário do UID/GID zero (0), UIDs e GIDs abaixo de 400 não são tratados especialmente pelo Red Hat Enterprise Linux. No entanto, estes UIDs/GIDs nunca devem ser atribuídos a um usuário, já que provavelmente algum componente do sistema usa ou usará estes UIDs/GIDs am algum momento no futuro. Para mais informações sobre estes usuários e grupos padrão, consulte o capítulo Usuários e Grupos no Guia de Referência do Red Hat Enterprise Linux. Quando são adicionadas novas contas de usuários usando as ferramentas padrão de criação de usuários do Red Hat Enterprise Linux, estas contas recebem os primeiros UID e GID disponíveis a partir de 500. O próximo usuário novo recebe o UID/GID 501, seguido pelo UID/GID 502 e assim por diante. Mais adiante ainda neste capítulo abordamos uma breve descrição das diversas ferramentas de criação de usuários disponíveis sob o Red Hat Enterprise Linux. Mas, antes de rever estas ferramentas, a próxima seção aborda os arquivos que o Red Hat Enterprise Linux usa para definir as contas e grupos do sistema. 6.3.2. Arquivos que Controlam Contas de Usuário e Grupos No Red Hat Enterprise Linux, as informações sobre contas de usuário e grupos são armazenadas em diversos arquivos texto dentro do diretório /etc/. Quando um administrador de sistemas cria novas contas de usuário, é necessário editar estes arquivos manualmente ou usar aplicações para efetuar as alterações necessárias. 130 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos A seção seguinte documenta os arquivos do diretório /etc/ que armazenam informações sobre usuários e grupos no Red Hat Enterprise Linux. 6.3.2.1. /etc/passwd O arquivo /etc/passwd pode ser lido por todos e contém uma lista de usuários, cada um numa linha separada. Em cada linha, há uma lista delimitada por dois pontos contendo as seguintes informações: • Noime de usuário (username) — O nome que o usuário digita ao se autenticar no sistema. • Senha (password) — Contém a senha criptografada (ou um x se estiver usando senhas shadow — confira mais detalhes posteriormente). • ID do usuário (UID) — O equivalente numérico do nome de usuário, referenciado pelo sistema e aplicações ao determinar privilégios de acesso. • ID do grupo (GID) — O equivalente numérico do nome do grupo principal, referenciado pelo sistema e aplicações ao determinar privilégios de acesso. • GECOS — Nomeado por motivos históricos, o campo GECOS1 é opcional e é usado para armazenar informações extras (como o nome completo do usuário). Múltiplas entradas podem ser armazenadas aqui na lista delimitada por dois pontos. Utilitários como o finger acessam este campo para prover informações adicionais do usuário. • Diretório home — A localização absoluta do diretório home do usuário, tal como /home/juan/. • Shell — O programa iniciado automaticamente sempre que um usuário se autentica. É, geralmente, um interpretador de comandos (frequentemente chamado de shell). No Red Hat Enterprise Linux, o valor default é /bin/bash. Se o campo for deixado em branco, /bin/sh é usado. Se for configurado para um arquivo inexistente, o usuário não poderá se autenticar no sistema. Aqui está um exemplo de uma entrada do /etc/passwd: root:x:0:0:root:/root:/bin/bash Esta linha mostra que o usuário root tem uma senha shadow, assim como um UID e GID de 0. O usuário root tem /root/ como um diretório home, e usa /bin/bash para uma shell. Para mais informações sobre o /etc/passwd, veja a página man do passwd(5). 6.3.2.2. /etc/shadow Como o arquivo /etc/passwd deve ser legível por todos (world-readable - a principal razão é que este arquivo é usado para efetuar a tradução do UID para o nome do usuário), há um risco envolvido em armazenar a senha de todos no /etc/passwd. É verdade que as senhas são criptografadas, mas é possível executar ataques contra senhas se a senha criptografada estiver disponível. Se um atacante conseguir uma cópia do /etc/passwd, poderá efetuar um ataque, se planejado silenciosamente. Ao invés de arriscar ser detectado ao tentar se autenticar com todas as senhas possíveis geradas pelo cracker de senhas, um atacante pode usar o cracker de senhas da seguinte forma: • Um programa cracker de senhas gera as senhas possíveis • Cada senha possível é então criptografada usando o mesmo algoritmo que o sistema utiliza 1. GECOS significa General Electric Comprehensive Operating Supervisor. Este campo era usado nos lab- oratórios da Bell, na implementação original do UNIX. O laboratório tinha muitos computadores diferentes, incluindo um que rodava o GECOS. Este campo era usado para armazenar informações quando o sistema UNIX enviava tarefas batch e de impressão ao sistema GECOS. Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos • 131 A possível senha criptografada é então comparada às senhas criptografadas no /etc/passwd O aspecto mais perigoso deste ataque é que pode ocorrer num sistema distante de sua empresa. Sendo assim, o atacante pode usar o hardware de melhor desempenho disponível no mercado, possibilitando testar um número enorme de senhas muito rapidamente. Consequentemente, o arquivo /etc/shadow é legível somente pelo usuário root e contém as senhas (e informações opcionais de expiração das senhas) de cada usuário. Assim como no arquivo /etc/passwd, as informações de cada usuário estão numa linha separada. Cada uma destas linhas é uma lista delimitada por dois pontos, incluindo as seguintes informações: • Nome de usuário (username) — O nome que o usuário digita ao se autenticar no sistema. Isso permite que a aplicação login recupere a senha do usuário (e informações relacionadas a este usuário). • Senha criptografada — A senha de 13 a 24 caracteres. A senha é criptografada usando a função crypt(3) da biblioteca ou o algoritmo hash md5. Neste campo, os valores além de uma senha hash ou criptografada formatada de maneira válida são usados para controlar as autenticações do usuário e exibir o status da senha. Por exemplo: se o valor é ! ou *, a conta está bloqueada e o usuário não pode se autenticar. Se o valor é !!, a senha ainda não foi determinada (e, consequentemente, o usuário não poderá se autenticar). • Data da última alteração da senha — O número de dias desde 1o. de Janeiro de 1970 (também chamado de período) em que a senha foi alterada pela última vez. Esta informação é usada junto aos campos de expiração da senha que seguem. • Número de dias antes que a senha possa ser alterada — O número mínimo de dias antes que a senha possa ser alterada. • Número de dias antes que uma alteração de senha seja solicitada — O número de dias antes da senha ser alterada. • Número de dias do aviso antes da alteração da senha — O número de dias antes da expiração da senha durante os quais o usuário é avisado da expiração iminente. • Número de dias antes da desabilitação da conta — O número de dias após a senha expirar antes da conta ser desabilitada. • Data desde a desabilitação da conta — A data (armazenada como o número de dias desde o período) desde que a conta do usuário foi desabilitada. • Um campo reservado — Um campo ignorado no Red Hat Enterprise Linux. Aqui está um exemplo do /etc/shadow: juan:$1$.QKDPc5E$SWlkjRWexrXYgc98F.:12825:0:90:5:30:13096: Esta linha exibe as seguintes informações do usuário juan: • A senha foi alterada pela última vez no dia 11 de Fevereiro de 2005 • Não há tempo mínimo definido antes que a senha possa ser alterada • A senha deve ser alterada a cada 90 dias • O usuário receberá um aviso cinco dias antes de que a senha deve ser alterada • A conta será desabilitada 30 dias após a senha expirar, se não houver tentativas de autenticação • A conta expirará no dia 09 de Novembro de 2005 Para mais informações sobre o arquivo /etc/shadow, veja a página man do shadow(5). 132 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 6.3.2.3. /etc/group O arquivo /etc/group é legível por todos (world-readable) e contém uma lista de grupos, cada um numa linha separada. Cada linha tem quatro campos separados por dois pontos, incluindo as seguintes informações: • Nome do grupo — O nome do grupo. Usado por vários utilitários como um identificador do grupo legível por humanos. • Senha do grupo — Se determinada, esta permite aos usuários que não fazem parte do grupo juntarse a ele usando o comando newgrp e digitando a senha armazenada aqui. Se houver um x em caixa baixa neste campo, as senhas do grupo shadow 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 criptografada 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írgulas) podem adicionar ou remover membros do grupo usando o comando gpasswd. • Membros do grupo — Os membros do grupo aqui listados (numa lista separada por vírgulas) são membros regulares e não-administrativos do grupo. Aqui está um exemplo do /etc/gshadow: general:!!:shelley:juan,bob Esta linha mostra que o grupo general não tem senha e não permite o ingresso de não membros usando o comando newgrp. Além disso, shelley é uma administradora do grupo, e juan e bob são membros regulares e não administrativos. Já que editar estes arquivos aumenta o risco de erros de sintaxe, é recomendado usar as aplicações providas pelo Red Hat Enterprise Linux para este propósito. A próxima seção traz uma revisão das principais ferramentas para executar estas tarefas. Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos 133 6.3.3. Aplicações de Conta de Usuário e Grupo Há dois tipos básicos de aplicações que podem ser usadas para administrar contas de usuários e grupos nos sistemas Red Hat Enterprise Linux: • A aplicação gráfica Administrador de Usuários • Um conjunto de ferramentas de linha de comando Para obter instruções detalhadas sobre o uso do Administrador de Usuários, consulte o capítulo Configuração de Usuário e Grupo no Guia de Administração de Sistemas Red Hat Enterprise Linux. Apesar da aplicação Administrador de Usuários e dos utilitários de linha de comando executarem essencialmente a mesma tarefa, as ferramentas de linha de comando têm a vantagem de serem alteráveis por scripts e, consequentemente, mais fáceis de serem automatizadas. A tabela seguinte descreve algumas das ferramentas de linha de comando mais comuns usadas para criar e administrar contas de usuário e grupos: Aplicação Função /usr/sbin/useradd Adiciona contas de usuários. Esta ferramenta é usada também para especificar os membros principais e secundários do grupo. /usr/sbin/userdel Apaga contas de usuários. /usr/sbin/usermod Edita os atributos da conta incluindo algumas funções relacionadas à expiração da senha. Para os ajustes finos, use o comando passwd. O usermod também é usado para especificar os membros principais e secundários do grupo. passwd Define senhas. Apesar de ser usado principalmente para alterar a senha de um usuário, também controla todos os aspectos da expiração da senha. /usr/sbin/chpasswd Acessa um arquivo contendo pares de nome de usuário e senha e atualiza a senha de cada usuário de acordo. chage Altera a política de expiração da senha de um usuário. O comando passwd também pode ser usado para este propósito. chfn Altera as informações GECOS do usuário, chsh Altera a shell default do usuário. Tabela 6-2. Ferramentas de Linha de Comando para Administração de Usuários A tabela a seguir descreve algumas das ferramentas de linha de comando mais comuns usadas para criar e administrar grupos: Aplicação Função /usr/sbin/groupadd Adiciona grupos, mas não atribui usuários para estes grupos. Os programas useradd e usermod devem então ser usados para atribuir usuários a um determinado grupo. /usr/sbin/groupdel Apaga grupos. /usr/sbin/groupmod Modifca os nomes ou GIDs do grupo, mas não altera os membros do grupo. Os programas useradd e usermod devem ser usados para atribuir usuários a um determinado grupo. 134 Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos Aplicação Função gpasswd Altera os membros do grupo e determina senhas para permitir que usuários não membros do grupo, que conheçam o grupo, a juntem-se a ele. Também é usado para especificar os administradores do grupo. /usr/sbin/grpck Verifica a integridade dos arquivos /etc/group e /etc/gshadow. Tabela 6-3. Ferramentas de Linha de Comando para Administração de Grupos As ferramentas listadas oferecem uma grande flexibilidade em controlar todos os aspectos das contas de usuário e associação a grupos. Para aprender mais sobre como estas funcionam, consulte a página man de cada uma delas. No entanto, estas aplicações não determinam sobre quais recursos estes usuários e grupos têm controle. Para isso, o administrador de sistemas precisa usar as aplicações para permissão de arquivos. 6.3.3.1. Aplicações para Permissão de Arquivos As permissões de arquivo são uma parte integral da administração de recursos dentro de uma empresa. A tabela seguinte aborda as ferramentas de linha de comando mais comuns utilizadas para este propósito. Aplicação Função chgrp Altera o grupo (ownership) que detém um determinado arquivo. chmod Altera as permissões de um determinado arquivo. Também é capaz de atribuir permissões especiais. chown Altera a propriedade (ownership) de um arquivo e também pode alterar o grupo. Tabela 6-4. Ferramentas de Linha de Comando para Administração de Permissões Também é possível alterar estes atributos nos ambientes gráficos do GNOME e KDE. Clique com o botão direito no ícone do arquivo (por exemplo: enquanto o ícone é exibido num visualizador gráfico de arquivos ou na área de trabalho) e selecione Propriedades. 6.4. Recursos Adicionais Esta seção inclui vários recursos que podem ser usados para aprender mais sobre a admninistração de contas e recursos, inclusive informações específicas sobre o assunto relacionadas ao Red Hat Enterprise Linux neste capítulo. 6.4.1. Documentação Instalada Os seguintes recursos são instalados no decorrer de uma instalação típica do Red Hat Enterprise Linux e podem ajudá-lo a aprender mais sobre o assunto abordado neste capítulo. • Item Help do menu da Administrador de Usuários — Aprenda a administrar contas de usuário e grupos. • Página man passwd(5) — Saiba mais informações sobre o formato do arquivo /etc/passwd. • Página man group(5) — Informações sobre o formato do arquivo /etc/group. Capítulo 6. Administrando Contas de Usuário e Acesso a Recursos • Página man shadow(5) — Informações sobre o formato do arquivo /etc/shadow. • Página man useradd(8) — Aprenda como criar ou atualizar contas de usuários. 135 • Página man userdel(8) — Aprenda como apagar contas de usuários. • Página man usermod(8) — Aprenda como modificar contas de usuários. • Página man passwd(1) — Aprenda como atualizar a senha de um usuário. • Página man chpasswd(8) — Aprenda como atualizar as senhas de diversos usuários de uma só vez. • Página man chage(1) — Aprenda como alterar as informações de expiração da senha de um usuário. • Página man chfn(1) — Aprenda como alterar as informações GECOS (finger) de um usuário. • Página man chsh(1) — Aprenda a alterar a shell de autenticação de um usuário. • Página man groupadd(8) — Aprenda a criar um novo grupo. • Página man groupdel(8) — Aprenda como apagar um grupo. • Página man groupmod(8) — Aprenda a modificar um grupo. • Página man gpasswd(1) — Aprenda a administrar os arquivos /etc/group e /etc/gshadow. • Página man grpck(1) — Aprenda a verificar a integridade dos arquivos /etc/group e /etc/gshadow. • Página man chgrp(1) — Aprenda como alterar a propriedade em nível de grupo. • Página man chmod(1) — Aprenda a alterar as permissões de acesso de um arquivo. • Página man chown(1) — Aprenda a alterar o proprietário e o grupo de um arquivo. 6.4.2. Sites Úteis • http://www.bergen.org/ATC/Course/InfoTech/passwords.html — Um bom exemplo de documento que abrange informações sobre a segurança da senha para os usuários de uma empresa. • http://www.crypticide.org/users/alecm/ — Home page do autor de um dos programas mais famosos de cracking de senhas (Crack). Você pode fazer o download do Crack a partir deste site e verificar quantos de seus usuários têm senhas fracas. • http://www.linuxpowered.com/html/editorials/file.html — uma boa visão geral sobre as permissões de arquivos no Linux. 6.4.3. Livros Relacionados Os livros a seguir abordam diversas questões relacionadas à administração de contas e recursos e são boas fontes de informação para administradores de sistemas Red Hat Enterprise Linux. • O Guia de Segurança do Red Hat Enterprise Linux; Red Hat, Inc. — Oferece uma visão geral dos aspectos relacionados à segurança de contas de usuários, enfaticamente sobre senhas fortes. • O Guia de Referência do Red Hat Enterprise Linux; Red Hat, Inc. — Contém informações detalhadas 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 computacionais diferentes. Então, descreve como a impressão é suportada pelo Red Hat Enterprise Linux. 7.1. Tipos de Impressoras Assim como qualquer outro periférico, há diversos tipos de impressora disponíveis. Algumas impressoras empregam tecnologias que imitam a funcionalidade do estilo da máquina de escrever, enquanto outras utilizam jato de tinta ou então laser para gerar uma imagem da página sendo impressa. O hardware da impressora interage com um PC ou rede usando protocolos paralelos, seriais ou de rede de dados. Há diversos fatores a considerar quando você for avaliar impressoras para compra e uso em seu ambiente computacional. As seções seguintes abordam vários tipos de impressoras e os protocolos que utilizam para comunicarem-se com computadores. 7.1.1. Considerações de Impressão Há diversos aspectos relevantes para a avaliação de uma impressora. Veja a seguir alguns dos critérios mais comuns para avaliar suas necessidades de impressão. 7.1.1.1. Função Avaliar as necessidades de sua empresa e como uma impressora serve a estas necessidades é essencial para determinar o tipo de impressora mais apropriado para o seu ambiente. A questão mais importante é "O que precisamos imprimir?" Como há impressoras especializadas em texto, imagens ou variações destas, você deve garantir de adquirir a ferramenta correta para seus propósitos. Por exemplo: se as suas necessidades exigem imagens coloridas de alta qualidade em papel glossy profissional, é recomendado usar uma impressora colorida com tecnologia dye-sublimation ou transferê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 impressoras 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 podem 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 reduzindo 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 • letter — (8 1/2" x 11") • A4 — (210mm x 297mm) • JIS B5 — (182mm x 257mm) • legal — (8 1/2" x 14") Capítulo 7. Impressoras e Impressão Se determinados departamentos (como marketing ou design) têm necessidades específicas, como a criação de pôsters ou banners, há impressoras de formato grande capazes de usar papel tamanho A3 (297mm x 420mm) ou tablóide (11" x 17"). Além dessas, há impressoras para tamanhos de papel ainda maiores, mas são usadas apenas para fins específicos, como para a impressão blueprint (mapas, planos arquitetônicos, etc.) As funcionalidades mais complexas, como módulos de rede para impressão workgroup e site remoto também devem ser consideradas durante a avaliação. 7.1.1.2. Custo O custo é outro fator a considerar. No entanto, determinar o custo único associado à compra da impressora 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 reprodução de cores. Estas qualidades são chamadas de rapidez de cor. Para imprimr documentos com qualidade 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). Algumas 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 impressão, enquanto outras espirram gotas de tinta na mídia. Os custos de reposição da tinta variam amplamente e dependem do fato se o repositório de tinta pode ser recarregado (com refil) ou se o cartucho de tinta precisa ser completamente substituído. 7.2. Impressoras de Impacto As impressoras de impacto representam a tecnologia mais antiga ainda em produção. Alguns dos maiores fabricantes de impressoras continuam a produzí-las, vendê-las e suportar as impressoras, peças e suprimentos. As impressoras de impacto são mais funcionais em ambientes especializados, nos quais o baixo custo de impressão é essencial. Os três tipos mais comuns de impressoras de impacto são matricial, margarida e impressoras de linha. Capítulo 7. Impressoras e Impressão 139 7.2.1. Impressoras Matriciais A tecnologia por trás da impressão matricial é bem simples. O papel é pressionado contra um tambor (um cilindro coberto de borracha) e é intermitentemente puxado para frente ao longo da impressão. A cabeça de impressão move-se eletromagneticamente ao longo do papel e atinge a fita de impressão situada entre o papel e o pino da cabeça. O impacto da cabeça de impressão contra o tambor lança pontos de tinta, que formam caracteres humanamente legíveis no papel. As impressoras matriciais variam na resolução e na qualidade geral, com cabeças de impressão de 9 ou de 24 pinos. Quanto mais pinos por polegada, maior a resolução da impressão. A maioria das impressoras matriciais tem resolução máxima de, aproximadamente, 240 dpi (dots per inch, pontos por polegada). Apesar desta resolução não ser tão alta quanto aquelas possíveis em impressoras jato de tinta ou laser, não há uma vantagem distinta para as impressões matriciais (ou de qualquer forma de impacto). Como a cabeça de impressão deve atingir a superfície do papel com força suficiente para transferir tinta de uma fita para a página, é uma boa opção para empresas que precisam produzir cópias carbono através do uso de documentos multi-partes especiais. Estes documentos têm carbono (ou outro material sensível à pressão) no lado de baixo e criam uma marca na página de baixo quando a pressão é aplicada. Lojas de varejo e pequenas empresas frequentemente usam cópias carbono como recibos ou notas de vendas. 7.2.2. Impressoras Margarida Se você já trabalhou com uma máquina de escrever manual antes, então entende o conceito tecnológico por trás das impressoras margarida. Estas impressoras têm cabeças de impressão compostas de rodas metálicas ou plásticas cortadas no formato de pétalas. Cada pétala tem a forma de uma letra (em caixa alta e baixa), número ou pontuação. Quando a pétala é pressionada sobre a fita de impressão, a forma resultante força a tinta sobre o papel. As impressoras margarida são barulhentas e lentas. Não podem imprimir gráficos, e não podem alterar a fonte, a não ser que a roda de impressão seja fisicamente substituída. Com o advento das impressoras à laser, as impressoras margarida geralmente não são mais usadas nos ambientes computacionais modernos. 7.2.3. Impressoras de Linha Um outro tipo de impressora de certa maneira similar à margarida é a impressora de linha. Entretanto, ao invés de uma roda de impressão, as impressoras de linha têm um mecanismo que permite imprimir caracteres múltiplos na mesma linha. O mecanismo pode usar tambor de impressão rotativo ou uma correia de impressão em loop. Conforme o tambor ou correia é rotacionada sobre a superfície do papel, martelos eletromagnéticos empurram o papel por trás (junto à fita) sobre a superfície do tambor ou correia, marcando o papel com a forma do caractere no tambor ou correia. Devido à natureza do mecanismo de impressão, as impressoras de linha são bem mais rápidas que as impressoras matriciais ou margarida. Entretanto, tendem a ser muito barulhentas, ter capacidade limitada de fontes múltiplas e frequentemente produzir impressões de qualidade inferior que as tecnologias de impressão mais recentes. Como as impressoras de linha são usadas para a sua velocidade, utilizam papel especial alimentado por tração com buracos pré-furados de cada lado. Esta combinação possibilita a impressão contínua de alta velocidade sem supervisão, parando somente quando uma caixa de papel acaba. 7.2.4. Consumíveis de Impressoras de Impacto Dentre todos os tipos de impressoras, as impressoras de impacto têm custos de consumíveis relativamente baixos. Fitas de tinta e papel são os custos recorrentes principais. Algumas impressoras de impacto (geralmente de linha e matriciais) requerem papel alimentado por tração, o que pode aumentar um pouco o custo da operação. 140 Capítulo 7. Impressoras e Impressão 7.3. Impressoras à Jato de Tinta Um impressora à jato de tinta usa uma das tecnologias de impressão mais conhecidas de hoje. O custo relativamente baixo e as habilidades de impressão das impressoras à jato de tinta fazem deste tipo uma boa opção para pequenas empresas e escritórios residenciais. As impressoras à jato de tinta usam tintas baseadas em água e rápidas de secar, e uma cabeça de impressão com uma série de pequenos bocais, que lançam tinta na superfície do papel. O conjunto da cabeça de impressão é movido por um motor com polia, que move a cabeça ao longo do papel. As impressoras à jato de tinta eram originalmente fabricadas para imprimir somente em papel monocromático (preto e branco). No entanto, desde então, a cabeça de impressão foi expandida e os bocais aumentados para acomodar as cores cyan, magenta, amarelo e preto. Essa combinação de cores (chamada CMYK) permite a impressão de imagens com quase a mesma qualidade de um laboratório fotográfico (quando usada com determinados tipos de papel composto). Quando combinadas com qualidade de impressão de texto altamente legível, as impressoras à jato de tinta são uma ótima opção para necessidades de impressão monocromáticas ou coloridas. 7.3.1. Consumíveis das Impressoras à Jato de Tinta As impressoras à jato de tinta tendem a ter custo baixo e características de impressão um pouco elevadas em relação à qualidade, funções extras e habilidade de imprimir em formatos maiores que os tamanhos de papel legal ou letter padrões. Apesar do custo único de adquirir uma impressora à jato de tinta ser menor que outros tipos de impressora, o fator dos consumíveis deve ser considerado. Como a demanda por impressoras à jato de tinta é grande e atinge todo o espectro da computação - do lar às grandes corporações - a compra de consumíveis pode ser custosa. Nota Quando for comprar uma impressora à jato de tinta, saiba que tipo de cartucho(s) de tinta esta precisa. Isso é crucial para as unidades coloridas. As impressoras à jato de tinta CMYK requerem tintas para cada cor; no entanto, o ponto central é saber se cada cor é armazenada num cartucho separado ou não. Algumas impressoras usam um cartucho multi-câmara. A não ser que seja possível algum método de refil, assim que a tinta de uma cor acaba, todo o cartucho dever ser substituído. Outras impressoras utilizam um cartucho multi-câmara para cyan, magenta e amarelo, mas têm um cartucho separado para a cor preta. Em ambientes onde são impressas grandes quantidades de texto, este tipo de configuração pode ser indicado. No entanto, a melhor solução é encontrar uma impressora com cartuchos separados para cada cor, assim você pode substituí-los facilmente quando uma das cores acabar. Alguns fabricantes de impressoras à jato de tinta requerem que você use papel especialmente tratado para imagens e documentos de alta qualidade. Tais papéis possuem uma cobertura moderada a alta, formulada para absorver tintas coloridas, o que evita a coagulação (tendência das tintas baseadas em água em concentrarem-se em áreas onde as cores se misturam, causando umedecimento ou pontos de tinta seca) ou o estiramento (no qual o output da impressão apresenta uma padrão estirado de linhas esquisitas na página impressa). Consulte a documentação de sua impressora para outras informações relevantes. 7.4. Impressoras à Laser Baseada numa tecnologia mais antiga que a jato de tinta, as impressoras à laser são uma outra alternativa conhecida da impressão de impacto legada. As impressoras à laser são conhecidas por seu grande Capítulo 7. Impressoras e Impressão 141 volume de output a um baixo custo-por-página. São geralmente empregadas em empresas como um centro de impressão departamental ou workgroup, nos quais desempenho, durabilidade e requisitos de output são prioridades. Como as impressoras à laser atendem prontamente a estas necessidades (a um custo-por-página razoável), a tecnologia é altamente conceituada como o cavalo de batalha da impressão empresarial. As impressoras à laser compartilham de grande parte da tecnologia das fotocopiadoras. Os rolamentos puxam uma folha de papel de uma bandeja e através de um rolamento de carga, que passa uma carga eletrostática ao papel. Ao mesmo tempo, um tabor de impressão recebe a carga oposta. A superfície do tambor é scaneada por um laser, descarregando a superfície do tambor e deixando com carga apenas aqueles pontos correspondentes ao texto ou imagem desejada. Essa carga é então usada para forçar o toner a ser aderido pela superfície do tambor. O papel e o tambor entram em contato; suas cargars diferentes fazem com que o toner seja aderido pelo papel. Finalmente, o papel viaja entre rolamentos de fusão, que esquentam o papel e derretem o toner, fundindo-o na superfície do papel. 7.4.1. Impressoras à Laser Coloridas As impressoras à laser coloridas pretendem combinar as melhores características das tecnologias laser e jato de tinta em um pacote de impressão multi-funcional. A tecnologia é baseada na impressão à laser monocromática tradicional, mas utiliza componentes adicionais para criar imagens e documentos coloridos. Ao invés de usar somente toner preto, as impressoras à laser coloridas usam uma combinação de toner CMYK. O tambor de impressão pode: rotacionar cada cor e derramar o toner de uma cor por vez, ou então derramar todas as quatro cores em um prato e então passar o papel pelo tambor, transferindo a imagem completa para o papel. As impressoras à laser coloridas também empregam óleo fusor ao longo dos rolamentos de fusão aquecidos, o que por sua vez junta o toner colorido ao papel e pode proporcionar diferentes graus de gramatura à imagem final. Devido o maior número de funcionalidades, as impressoras à laser coloridas tipicamente custam o dobro (ou mais) do que as impressoras à laser monocromáticas. Ao calcular o custo total de propriedade em relação aos recursos de impressão, alguns administradores talvez queiram separar as funcionalidades monocromática (texto) e colorida (imagem) para uma impressora à laser monocromática e uma impressora à laser (ou jato de tinta) colorida, respectivamente. 7.4.2. Consumíveis da Impressora à Laser Dependendo do tipo da impressora à laser empregada, os custos de consumíveis geralmente são proporcionais ao volume de impressão. O toner vem em cartuchos geralmente substituídos prontamente; no entanto, alguns modelos acompanham cartuchos recarregáveis. As impressoras à laser coloridas requerem um cartucho de toner para cada uma das quatro cores. Além disso, requerem óleos fusores para aplicar o toner sobre o papel e desperdiçam garrafas de toner para capturar o excesso de toner. Estes suprimentos aumentam o custo dos consumíveis das impressoras à laser coloridas; no entanto, é importante notar que estes consumíveis duram, em média, em torno de 6000 páginas, um número bem maior se comparado com a duração dos consumíveis das impressoras de impacto ou jato de tinta. O tipo de papel é um problema menor nas impressoras à laser, o que significa que uma compra grande de papel xerográfico ou de fotocópia comuns é aceitável para a maioria dos trabalhos de impressão. Entretanto, se você pretende imprimir imagens de alta qualidade, deve optar por papel fotográfico (glossy) para obter uma finalização profissional. 7.5. Outros Tipos de Impressora Há outros tipos de impressora disponíveis, que têm, em sua maioria, propósitos especiais para gráficos profissionais ou empresas de publicações. No entanto, estas impressoras não são indicadas para uso 142 Capítulo 7. Impressoras e Impressão genérico. Como são delegadas para este nicho, seus preços (ambos, os custos único e os recorrentes dos consumíveis) tendem a ser mais altos que os preços das unidades predominantes. Impressoras de Cera Térmica Estas impressoras são mais usadas para transparências em apresentações empresariais e para prova de cor (criação de documentos e imagens teste para uma inspeção de qualidade antes do envio dos documentos mestre para serem impressos em impressoras industriais offset de quatro cores). As impressoras de cera térmica utilizam tambores CMYK direcionados por uma fita, e papel ou transparência especialmente cobertos. A cabeça de impressão contém elementos quentes que derretem cada cor de cera no papel conforme ele rola pela impressora. Impressoras Dye-Sublimation Usadas em empresas como agências de serviço — onde a qualidade profissional dos documentos, panfletos e apresentações é mais importante que o custo dos consumíveis — as impressoras dye-sublimation (ou dye-sub) são os cavalos de batalha da impressão CMYK de qualidade. Os conceitos por trás das impressoras dye-sublimation são similares aos das impressoras de cera térmica, exceto pelo uso de filme dye plástico difusivo ao invés de cera colorida. A cabeça de impressão aquece o filme colorido e vaporiza a imagem em papel especialmente coberto. A dye-sub é bastante conhecida no mundo do design e publicações, assim como no campo da pesquisa científica, onde é necessário ter precisão e detalhes. Tais detalhes e qualidade de impressão têm um preço, já que as impressoras dye-sub também são conhecidas por seus altos custos-por-página. Impressoras de Tinta Sólida Usadas principalmente nos setores de embalagens e design industrial, as impressoras de tinta sólida são famosas por imprimir numa variedade de tipos de papel. As impressoras de tinta sólida, como o nome implica, usam espetos de tinta endurecidos, que são derretidos e espirrados através de pequenos bocais na cabeça de impressão. O papel é então enviado através de um rolamento fusor, que por sua vez força a tinta sobre o papel. A impressora de tinta sólida é ideal para provas e protótipos de novos designs de embalagens de produtos. Sendo assim, a maioria das empresas de serviços não tem necessidade deste tipo de impressora. 7.6. Linguagens e Tecnologias de Impressoras Antes do advento das tecnologias à laser e jato de tinta, as impressoras de impacto podiam imprimir somente texto padrão e justificado, sem nenhuma variação no tipo ou tamanho da fonte. Hoje em dia, as impressoras são capazes de processar documentos complexos com imagens, gráficos e tabelas integrados, em diversos moldes e linguagens; tudo numa só página. Tal complexidade deve aderir àlgumas convenções de formato. Foi isso que acelerou o desenvolvimento da linguagem de descrição da página (ou PDL - page description language) — uma linguagem especializada de formatação de documentos criada especialmente para a comunicação de computadores com impressoras. Ao longo dos anos, os fabricantes de impressoras desenvolveram suas próprias linguagens proprietárias para descrever os formatos de documentos. No entanto, tais linguagens proprietárias se aplicavam somente às impressoras criadas pelos próprios fabricantes. Se, por exemplo, você tivesse que enviar um arquivo pronto para impressão usando uma PDL proprietária para um jornalista profissional, não havia garantia de que seu arquivo seria compatível com as máquinas da impressora. Veio então a questão da portatibilidade. A Xerox® desenvolveu o protocolo Interpress™ para a sua linha de impressoras, mas a adoção total desta linguagem pelo resto da indústria da impressão nunca ocorreu. Dois desenvolvedores do Interpress original deixaram a Xerox e formaram a Adobe®, uma empresa de software dedicada basicamente aos gráficos eletrônicos e profissionais de documentação. Na Adobe, desenvolveram uma Capítulo 7. Impressoras e Impressão 143 PDL amplamente adotada, chamada PostScript™, que usa uma linguagem markup para descrever a formatação de texto e informações da imagem que podiam ser processadas por impressoras. Ao mesmo tempo, a empresa Hewlett-Packard® desenvolveu a Printer Control Language™ (Linguagem de Controle de Impressão ou PCL) para o uso em toda a sua linha de impressoras à laser e jato de tinta. A PostScript e a PCL são PDLs amplamente adotadas agora e suportadas pela maioria dos fabricantes de impressoras. As PDLs funcionam sob o mesmo princípio das linguagens de programação de computador. Quando um documento está pronto para impressão, o PC ou estação de trabalho pega as imagens, as informaçõ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 processo torna a impressão de documentos mais consistente, resultando em pouca ou nenhuma variação ao imprimir o mesmo documento em modelos diferentes de impressora. As PDLs são desenvolvidas para serem portáveis a qualquer formato e escaláveis para caberem em formatos diferentes de papel. A escolha da impressora apropriada é uma questão de determinar quais os padrões adotados pelos diversos departamentos da sua empresa para suas necessidades. A maioria dos departamentos usa processadores de texto e outros software de produtividade que utilizam a linguagem PostScript para o envio às impressoras. No entanto, se o seu departamento gráfico requer uma PCL ou alguma forma de impressão proprietária, você também deve levar isso em consideração. 7.7. Impressoras em Rede Versus Locais Dependendo das necessidades, pode ser desnecessário atribuir uma impressora para cada funcionário de sua empresa. Tal despesa pode abocanhar grandes porções do seu orçamento, deixando menos capital para as outras necessidades. Apesar das impressoras locais conectadas através de um cabo paralelo ou USB a cada estação de trabalho serem uma solução ideal para o usuário, geralmente não é economicamente viável. Os fabricantes de impressoras resolveram esta questão ao desenvolver impressoras departamentais (ou workgroup). Estas máquinas são geralmente duráveis, rápidas e têm consumíveis de longa duração. As impressoras workgroup são frequentemente conectadas a um servidor de impressão (como uma estação de trabalho reconfigurada), que direciona o output para a impressora apropriada quando disponível. Impressoras departamentais mais recentes incluem interfaces de rede integradas ou anexas que eliminam a necessidade de um servidor de impressão dedicado. 7.8. Informações Específicas do Red Hat Enterprise Linux Veja a seguir as descrições das diversas funcionalidades relacionadas às impressoras e impressão, específicas ao Red Hat Enterprise Linux. A Ferramenta de Configuração da Impressora permite aos usuários configurar uma impressora. Esta ferramenta ajuda a manter o arquivo de configuração da impressora, os diretórios spool e filtros de impressão. O Red Hat Enterprise Linux 4 usa o sistema de impressão CUPS. Se foi executado um upgrade de uma versão anterior do Red Hat Enterprise Linux que usava o CUPS, o processo de upgrade preservou as filas configuradas. Usar a Ferramenta de Configuração da Impressora requer privilégios root. Para iniciar a aplicação, selecione Botão do Menu Principal (no Painel) => Configurações do Sistema => Impressão, ou digite o comando system-config-printer. Este comando determina automaticamente se deve rodar a versão gráfica ou texto, dependendo se o comando é executado no ambiente gráfico ou a partir de um console de texto. 144 Capítulo 7. Impressoras e Impressão Para forçar a Ferramenta de Configuração da Impressora a rodar no modo texto, execute o comando 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 aplicadas à Ferramenta de Configuração da Impressora. Figura 7-1. Ferramenta de Configuração da Impressora Os seguintes tipos de filas de impressão podem ser configurados: • Conectada localmente — uma impressora ligada diretamente ao computador através de uma porta paralela ou USB. • CUPS em Rede (IPP) — uma impressora que pode ser acessada através de uma rede TCP/IP pelo Protocolo de Impressão da Internet, também conhecido como IPP (ex.: uma impressora conectada a um outro sistema Red Hat Enterprise Linux rodando o CUPS na rede). • UNIX em Rede (LPD) — uma impressora conectada a um sistema UNIX diferente, que pode ser acessado através de uma rede TCP/IP (ex.: uma impressora conectada a um outro sistema Red Hat Enterprise Linux rodando LPD na rede). • Windows em Rede (SMB) — uma impressora conectada a um sistema diferente, que compartilha uma impressora através de uma rede SMB (ex.: uma impressora conectada a uma máquina com Microsoft Windows™). • Novell em Rede (NCP) — uma impressora conectada a um sistema diferente que usa a tecnologia de rede NetWare da Novell. • JetDirect em Rede — uma impressora conectada diretamente à rede, através da HP JetDirect, ao invés de conectada ao computador. Capítulo 7. Impressoras e Impressão 145 Importante Se você adicionar uma nova fila de impressão ou modificar uma fila existente, deve aplicar as alterações para que estas tenham efeito. Clicar no botão Aplicar salva quaisquer alterações feitas e reinicia o daemon de impressão. As alterações não são gravadas no arquivo de configuração até que o daemon de impressão seja reiniciado. Alternativamente, você pode clicar em Ação (Action) => Aplicar (Apply). Para mais informações sobre a configuração de impressoras sob o Red Hat Enterprise Linux, consulte o Guia de Administração de Sistemas Red Hat Enterprise Linux. 7.9. Recursos Adicionais A configuração da impressão e impressão em rede são tópicos abrangentes que requerem conhecimento e experiência em hardware, rede e administração de sistemas. Para informações mais detalhadas sobre o emprego de serviços de impressão em seus ambientes, consulte os seguintes recursos. 7.9.1. Documentação Instalada • Página man lpr(1) — Aprenda a imprimir arquivos selecionados na sua impressora predileta. • Página man lprm(1) — Aprenda a remover trabalhos de impressão da fila de impressão. • Página man cupsd(8) — Aprenda sobre o daemon de impressão CUPS. • Página man cupsd.conf(5) — Aprenda sobre o formato do arquivo de configuração do daemon de impressão CUPS. • Página man classes.conf(5) — Aprenda sobre o formato do arquivo de configuração da classe CUPS. • Arquivos do diretório /usr/share/doc/cups- version — Aprenda mais sobre o sistema de impressão CUPS. 7.9.2. Sites Úteis • http://www.webopedia.com/TERM/p/printer.html — Definições gerais das impressoras e descrições dos tipos de impressora. • http://www.linuxprinting.org/ — Um banco de dados com documentos sobre impressão, juntamente a um banco de dados com aproximadamente 1000 impressoras compatíveis com as funcionalidades de impressão do Linux. • http://www.cups.org/ — Documentação, FAQ e grupos de discussão sobre o CUPS. 7.9.3. Livros Relacionados • Network Printing de Matthew Gast e Todd Radermacher; O’Reilly & Associates, Inc. — Informaçõ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 examina os principais fatores que fazem parte de cada tipo de desastre, para que cada possível exposição seja examinada como um fator que pode levar a um desastre, e não em termos de sua probabilidade. 8.1. Tipos de Desastres Em geral, há quatro fatores diferentes que podem acarretar num desastre. Estes fatores são: • Falhas de hardware • Falhas de software • Falhas de ambiente • Erros humanos 8.1.1. Falhas de Hardware As falhas de hardware são fáceis de entender — o hardware falha e o trabalho sofre uma parada. O que é mais difícil de entender é a natureza das falhas e como minimizar sua exposição a elas. Aqui estão algumas táticas que você pode usar: 8.1.1.1. Guardar Hardware Reserva Simplisticamente, a exposição a falhas de hardware pode ser reduzida ao guardar hardware reserva. Obviamente, esta tática assume duas coisas: • Alguém dentro do escritório tem as habilidades necessárias para diagnosticar o problema, identificar o hardware falho e substituí-lo. • É possível substituir o hardware falho. Estas questões estão detalhadas nas próximas seções. 8.1.1.1.1. Ter as Habilidades Dependendo de sua experiência e do hardware envolvido, ter as habilidades necessárias pode não ser um problema. No entanto, se você nunca trabalhou com hardware antes, pode pensar em pesquisar cursos introdutórios sobre reparos em PCs. Apesar de cursos deste tipo não serem insuficientes para prepará-lo para resolver problemas em um servidor de nível corporativo, é uma boa maneira de aprender o básico (uso apropriado de ferramentas e componentes, procedimentos para diagnóstico básico e assim por diante). 148 Capítulo 8. Planejamento para Desastres Dica Antes de você experimentar reparar o hardware sozinho, certifique-se de que o hardware em questão: • Não esteja mais sob garantia • Não esteja sob algum tipo de contrato de serviço/manutenção Se você tentar reparar um componente de hardware coberto por uma garantia e/ou contrato de serviço, provavelmente estará violando os termos destes acordos e prejudicando sua cobertura contínua. Entretanto, mesmo com habilidades mínimas, pode ser possível diagnosticar e substituir efetivamente o hardware falho — se você escolher seu estoque de hardware de substituição apropriadamente. 8.1.1.1.2. O Que Estocar? Esta questão ilustra a natureza complexa de qualquer coisa relativa à recuperação de desastres. Quando considerar qual hardware estocar, aqui estão algumas questões a considerar: • Tempo Máximo Permitido Fora do Ar • A habilidade necessária para efetuar o reparo • Disponibilidade de verba para os reservas • Espaço de armazenamento necessário para os reservas • Outros componentes de hardware que poderiam utilizar os mesmos reservas Cada uma destas questões tem um desenrolar nos tipos de reservas que devem ser estocados. Por exemplo: estocar sistemas completos tenderia a minimizar o tempo fora do ar e requerer habilidades mínimas para instalar, mas seria muito mais caro do que ter uma CPU ou módulo RAM reserva na prateleira. No entanto, essa despesa pode valer a pena se a sua empresa tem dúzias de servidores idênticos que podem beneficiar de um sistema reserva. Independente da decisão final, a seguinte questão é inevitável e é abordada a seguir. 8.1.1.1.2.1. Quanto Estoque? A pergunta sobre os níveis de estoque reserva também tem várias facetas. Aqui estão as principais questões: • Tempo Máximo Permitido Fora do Ar • Taxa projetada de falhas • Tempo estimado para reabastecer o estoque • Disponibilidade de verba para os reservas • Espaço de armazenamento necessário para os reservas • Outros componentes de hardware que poderiam utilizar os mesmos reservas Por um lado, para um sistema que pode estar fora do ar por no máximo dois dias, e cuja peça reserva talvez seja usada uma vez por ano e pode ser reabastecida em um dia, faria sentido ter apenas uma reserva (ou talvez nenhuma, se você estiver certo de conseguir uma reserva em 24 horas). Capítulo 8. Planejamento para Desastres 149 Por outro lado, um sistema que não pode estar fora do ar por mais de alguns minutos, e uma reserva que talvez seja usada uma vez por mês (e pode levar diversas semanas para repôr) pode significar que meia dúzia de reservas (ou mais) devem estar na prateleira. 8.1.1.1.3. Reservas Que Não São Reservas Quando uma peça reserva não é reserva? Quando é um componente de hardware utilizado no cotidiano, mas também pode ser um componente reserva para um sistema mais prioritário, se necessário. Esta tática tem alguns benefícios: • Menos dinheiro direcionado a peças reservas "não-produtivas" • Sabe-se que o hardware é operante Há, no entanto, algumas desvantagens nesta tática: • A produção normal da tarefa de prioridade mais baixa é interrompida • Há uma expoisção caso o hardware de baixa prioridade falhe (não sobra um componente reserva para o hardware de alta prioridade) Dadas estas questões, o uso de um outro sistema de produção como reserva pode funcionar, mas o sucesso dessa tática se desdobra na carga de trabalho específica do sistema e no impacto que a ausência do sistema tem nas operações gerais do centro de dados. 8.1.1.2. Contratos de Serviço Os contratos de serviço transferem o problema de falhas no hardware para outra pessoa. Tudo o que você deve fazer é confirmar que a falha, de fato, ocorreu e que parece não ser uma causa relativa ao software. Então, você faz uma ligação telefônica e aparece alguém para resolver a situação. Parece muito simples. Mas, como a maioria das coisas na vida, há muito mais a observar do que o que vemos à primeira vista. Aqui estão algumas questões que você deve considerar ao analisar um contrato de serviço: • Horas de cobertura • Tempo de resposta • Disponibilidade de peças • Orçamento disponível • Hardware a ser coberto Nós exploramos cada um destes itens detalhadamente nas próximas seções. 8.1.1.2.1. Horas de Cobertura Contratos de serviço diferentes são feitos para atender a diferentes necessidades; uma das maiores variáveis entre contratos diferentes são as horas de cobertura. A não ser que você queira pagar caro pelo privilégio, você não pode simplesmente ligar a qualquer hora e esperar que um técnico apareça rapidamente. Ao invés disso, dependendo do seu contrato, talvez você descubra que nem pode ligar para a empresa de serviços até uma certa data/hora, ou se puder, eles não enviarão um técnico até a data/hora especificada no seu contrato. 150 Capítulo 8. Planejamento para Desastres A maioria das horas de cobertura são definidas em horas ou dias durante os quais um técnico será enviado. Algumas das horas de cobertura comuns são: • Segunda a Sexta, das 09:00 às 17:00 • Segunda a Sexta, 12/18/24 horas por dia (com horas de início e fim concordadas entre as partes) • Segunda a Sábado (ou Segunda a Domingo), mesmo horário mencionado acima Como é de se esperar, o custo de um contrato aumenta com as horas de cobertura. Em geral, extender a cobertura de Segunda a Sexta tende a custar menos que adicionar cobertura aos Sábados e Domingos. Mas aqui também é possível reduzir custos se você quiser executar algum trabalho. 8.1.1.2.1.1. Serviço de Depósito Se a sua situação não requer nada mais que a disponibilidade de um técnico durante o horário comercial convencional e você tem experiência suficiente para poder determinar o que está quebrado, você pode considerar o serviço de depósito. Conhecido por muitos nomes (incluindo serviço walk-in e serviço drop-off ), os fabricantes talvez tenham depósitos de serviço onde os técnicos trabalham no hardware trazido pelos clientes. O serviço de depósito tem o benefício de ser tão rápido quanto você. Você não precisa esperar que um técnico esteja disponível e apareça em sua empresa. Técnicos de depósitos não atendem ligações de clientes, o que significa que haverá alguém para trabalhar no seu hardware assim que você chegar no depósito. Como o serviço de depósito é feito numa localidade central, há grandes chances de ter qualquer peça necessária. Isto pode eliminar a necessidade de um despacho que leva dias ou esperar que a peça seja encaminhada de um escritório para outro há centenas de quilômetros de distância. No entanto, há algumas desvantagens. A mais óbvia é que você não pode escolher as horas de serviço — você obtém o serviço quando o depósito está aberto. Um outro aspecto é que os técnicos não trabalham depois de seu expediente, portanto se o seu sistema falhou às 16:30 de uma sexta-feira e você entregou o sistema ao depósito às 17:00, ele não será analisado até que os técnicos cheguem ao trabalho na manhã da segunda-feira seguinte. Uma outra desvantagem é que o serviço de depósito depende da existência de um depósito próximo. Se a sua empresa está localizada na área metropolitana, este provavelmente não é um problema. Entretanto, as empresas localizadas em zonas rurais podem descobrir que o depósito fica muito longe de sua sede. Dica Ao considerar o serviço de depósito, pare um pouco e pense na logística de trazer o hardware para o depósito. Você usará um veículo da empresa ou o seu? Se for usar o seu, ele tem o espaço e capacidade de carga necessários? E o seguro? Será necessário mais de uma pessoa para carregar e descarregar o hardware? Apesar de serem preocupações simples, elas devem ser analisadas antes de tomar a decisão de usar um serviço de depósito. 8.1.1.2.2. Tempo de Resposta Além das horas de cobertura, muitos contratos de serviço especificam um nível de tempo de resposta. Em outras palavras, quanto demora para o técnico chegar após ligar requisitando o serviço? Como você pode imaginar, um tempo de resposta mais rápido acarreta num acordo de serviço mais caro. Capítulo 8. Planejamento para Desastres 151 Há limites variáveis para o tempo de resposta. Por exemplo: o tempo de viagem do escritório do fabricante à sua empresa tem uma grande influência nos tempos de resposta possíveis 1 . Os tempos de resposta até quatro horas são geralmente inclusos nas ofertas mais rápidas. Os tempos de resposta mais lentos variam entre oito horas (o que efetivamente torna-se o serviço do "dia seguinte" num acordo baseado no horário comercial padrão), a 24 horas. Assim como com qualquer outro aspecto de um contrato de serviço, até mesmo estes tempos são negociáveis — pelo preço correto. Nota Apesar de não ser uma ocorrência comum, você deve estar ciente que contratos de serviço com cláusulas de tempo de resposta podem, às vezes, estressar o departamento de serviços de uma empresa além de sua capacidade de resposta. Não se sabe de nenhuma empresa de serviços ocupada que tenha enviado alguém — ninguém — numa chamada de serviço com tempo de resposta curto somente para cumprir seu comprometimento com o tempo de resposta. Esta pessoa aparentemente diagnostica o problema, ligando para o "escritório" para que alguém traga a "peça correta." De fato, eles estão apenas esperando chegar alguém que seja capaz de atender à chamada. Apesar de ser compreensível observar isto sob curcunstâncias extraordinárias (tais como problemas de energia que tenham afetado diversos sistemas em sua área de serviço), se este for um método de operação constante, você deve contatar o gerente de serviços e pedir uma explicação. Se a necessidade de seu tempo de resposta for restrita (e seu orçamento for adequadamente grande), há uma tática que pode reduzir ainda mais seu tempo de resposta — para zero. 8.1.1.2.2.1. Tempo de Resposta Zero — Ter um Técnico Interno Dada a situação apropriada (você é um dos maiores clientes na área), necessidades suficientes (qualquer tempo fora do ar é inaceitável) e recursos financeiros (se você precisa perguntar o preço, provavelmente não pode pagar), você pode precisar de um técnico interno por tempo integral. Os benefícios de ter um técnico sempre presente são óbvios: • Resposta instantânea a qualquer problema • Uma tática mais pró-ativa para a manutenção do sistema Como esperado, esta opção pode ser muito cara, especialmente se você requer um técnico interno 24 horas por dia, 7 dias por semana. Mas, se esta tática é apropriada para sua empresa, você deve ter alguns pontos em mente para tirar o máximo proveito. Primeiramente, técnicos internos precisam de muitos dos recursos dos funcionários regulares, como uma mesa de trabalho, telefone, cartões e/ou chaves de acesso apropriados e assim por diante. Os técnicos internos não são muito úteis se não tiverem as peças apropriadas. Sendo assim, certifiquese de ter um armazenamento seguro à parte para as peças do técnico. Além disso, assegure que o técnico mantenha um estoque das peças apropriado para a sua configuração e que estas peças não sejam "canibalizadas" rotineiramente por outros técnicos. 1. E isto provavelmente seria o tempo de resposta na melhor das hipóteses, já que os técnicos geralmente são responsáveis por territórios que abrangem longas distâncias em todas as direções. Se você está numa extremidade do território e o único técnico disponível está na outra extremidade, o tempo de resposta será ainda mais longo. 152 Capítulo 8. Planejamento para Desastres 8.1.1.2.3. Disponibilidade das Peças Obviamente, a disponibilidade das peças tem um papel fundamental na limitação das falhas de hardware da sua empresa. No contexto de um contrato de serviço, a disponibilidade das peças toma outra dimensão, já que aplica-se não somente à sua empresa, mas a todos os outros clientes que também possam precisar destas peças no território do fabricante. Uma empresa, que tenha comprado mais hardware do fabricante que você, pode receber tratamento preferencial no momento de obter peças (e técnicos, por este motivo). Infelizmente, há pouco a fazer nestas circunstâncias, além de tentar resolver o problema com o gerente de serviços. 8.1.1.2.4. Orçamento Disponível Conforme esplanado anteriormente, os contratos de serviço variam de preço de acordo com a natureza dos serviços oferecidos. Tenha em mente que os custos associados ao contrato de serviço são despesas recorrentes; você deve negociar um novo contrato e pagar novamente cada vez que o contrato estiver prestes a expirar. 8.1.1.2.5. Hardware a ser Coberto Esta é uma área na qual você pode manter custos mínimos. Considere por um momento que você negociou um contrato de serviço que inclua um técnico interno 24x7, peças reservas na empresa — você decide. Cada componente de hardware que você comprou desta empresa é coberto, incluindo o PC que a recepcionista utiliza para executar tarefas do cotidiano. Este PC precisa realmente ter alguém interno 24x7? Mesmo que o PC seja vital para o trabalho da recepcionista, ela só trabalha das 9:00 às 17:00. É muito improvável que: • O PC esteja em uso das 17:00 às 9:00 da manhã seguinte (sem falar nos finais de semana) • Uma falha deste PC seja notada, exceto entre 9:00 e 17:00. Sendo assim, pagar pela possibilidade deste PC precisar de serviços num sábado à noite é um desperdí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 verificações, gastará bem mais depois que for descoberto do que se for honesto e pagar pelo serviço que realmente precisa. Capítulo 8. Planejamento para Desastres 153 8.1.2. Falhas de Software Falhas de software podem resultar em tempos fora do ar mais longos. Por exemplo: os proprietários de uma determinada marca computadores notável por suas características de alta disponibilidade recentemente passaram por isso. Um erro (bug) no código de time handling do sistema operacional do computador resultou na queda dos sistemas de cada um dos clientes numa determinada hora num certo dia. Apesar desta situação ser o exemplo mais espetacular de uma falha de software, outras falhas relativas ao software podem ser menos dramáticas, mas tão devastadoras quanto. As falhas de software podem ocorrer em uma destas duas áreas: • Sistema operacional • Aplicações Cada tipo de falha tem seus próprios impactos e é explorada detalhadamente nas seções seguintes. 8.1.2.1. Falhas no Sistema Operacional Neste tipo de falha, o sistema operacional é responsável pelo rompimento do serviço. As falhas no sistema operacional vêm de duas áreas: • Quedas • Pendências A principal coisa a ter em mente sobre as falhas no sistema operacional é que elas removem tudo que o computador estava rodando no momento da falha. Sendo assim, as falhas no sistema operacional podem ser devastadoras para a produção. 8.1.2.1.1. Quedas As quedas ocorrem quando o sistema operacional passa por uma condição de erro do qual não pode se recuperar. As razões de quedas podem variar da inabilidade de resolver um problema básico de hardware a um erro (bug) no código do kernel comprometendo o sistema operacional. Quando um sistema operacional cai, o sistema deve ser reinicializado para poder continuar a produção. 8.1.2.1.2. Pendências Quando o sistema operacional para de executar os eventos do sistema, o sistema leva a uma parada. Isto é conhecido como pendência. As pendências podem ser causadas por deadlocks (dois consumidores de recursos competindo por recursos que um outro possui) e livelocks (dois ou mais processos respondendo às atividades do outro, mas sem executar nenhum trabalho útil), mas o resultado final é o mesmo — uma falta de produtividade total. 8.1.2.2. Falhas nas Aplicações Ao contrário das falhas no sistema operacional, as falhas nas aplicações podem ser mais limitadas no escopo de seu estrago. Uma única aplicação falha, dependendo da aplicação, pode impactar somente uma pessoa. Por outro lado, se for uma aplicação de servidor servindo uma gama de aplicações clientes, as consequências de uma falha podem ser mais alastradas. As falhas nas aplicações, assim como as do sistema operacional, podem acarretar em pendências e quedas; a única diferença é que aqui é a aplicação que está pendente ou caindo. 154 Capítulo 8. Planejamento para Desastres 8.1.2.3. Obtendo Ajuda — Suporte a Software Assim como os fabricantes de hardware oferecem suporte para seus produtos, muitos fabricantes de software disponibilizam pacotes de suporte para seus clientes. Exceto pelas diferenças óbvias (não é necessário hardware reserva e a maior parte do trabalho pode ser feito pelo pessoal do suporte através do telefone), os contratos de suporte a software podem ser bem parecidos aos de suporte a hardware. O nível de suporte oferecido por um fabricante de software pode variar. Aqui estão algumas das estratégias de suporte mais comuns aplicadas hoje: • Documentação • Auto-suporte • Suporte via Internet ou e-mail • Suporte telefônico • Suporte na empresa (on-site) Cada tipo de suporte é descrito mais detalhadamente nas seções seguintes. 8.1.2.3.1. Documentação Apesar de frequentemente negligenciada, a documentação do software pode servir como uma ferramenta de suporte de primeiro nível. Sendo online ou impressa, a documentação geralmente contém as informações necessárias para resolver muitas questões. 8.1.2.3.2. Auto-suporte O auto-suporte baseia-se no cliente usar recursos online para resolver suas próprias questões relativas a software. Frequentemente, estes recursos tomam a forma de FAQs (Perguntas e Respostas Frequentes) na Internet ou bases de conhecimento (knowledge bases). Os FAQs geralmente têm pouca ou nenhuma capacidade de seleção, o que faz com que o cliente tenha que rolar de questão em questão na esperança de achar uma que atenda ao seu problema. As bases de conhecimento tendem a ser mais sofisticadas de certa maneira, permitindo a inserção de termos de procura. As bases de conhecimento também podem ser bastante extensas, tornando-as uma boa ferramenta para a solução de problemas. 8.1.2.3.3. Suporte via Internet ou E-mail Muitas vezes, o que parece ser um site de auto-suporte também inclui formulários baseados na Internet ou endereços de e-mail que possibilitam enviar perguntas ao pessoal do suporte. Apesar de, à primeira vista, isto parecer uma melhoria de um bom site de auto-suporte, realmente depende das pessoas respondendo os e-mails. Se o pessoal do suporte está sobrecarregado, é difícil obter as informações necessárias através deles, já que sua preocupação principal é responder rapidamente cada e-mail e seguir para o próximo. A razão disso é que praticamente todos os funcionários de suporte são avaliados pelo número de problemas que resolvem. É difícil explicitar a intensidade das questões, pois há pouco a ser feito num e-mail para estimular respostas rápidas e úteis — especialmente quando a pessoa lendo seu e-mail está apressada para seguir ao próximo e-mail. A maneira de obter o melhor serviço é garantir que seu e-mail aborde todas as questões que um técnico de suporte possa perguntar, tais como: • Descreva claramente a natureza do problema • Inclua todos os números de versões pertinentes Capítulo 8. Planejamento para Desastres • 155 Descreva o que você já fez para tentar resolver o problema (aplicou os últimos consertos, reinicializou a máquina na configuração mínima, etc.) Ao oferecer mais informações ao técnico de suporte, você tem mais chances de obter o suporte que necessita. 8.1.2.3.4. Suporte Telefônico Como o nome implica, o suporte telefônico significa conversar com um técnico de suporte via telefone. Este estilo de suporte é mais parecido com o suporte a hardware; pode haver diversos níveis de suporte disponíveis (com horas de cobertura e tempos de resposta diferentes, etc.). 8.1.2.3.5. Suporte na Empresa (on-site) Também conhecido como consultoria on-site, o suporte on-site ao software normalmente é reservado para resolver as questões específicas ou efetuar mudanças críticas, como instalação e configuração do software inicial, grandes atualizações e assim por diante. Como esperado, este é o tipo mais caro de suporte ao software disponível. Mesmo assim, há situações em que o suporte na empresa (on-site) faz sentido. Como exemplo, considere uma empresa pequena com somente um administrador de sistemas. A empresa empregará seu primeiro servidor de banco de dados, mas a aplicação (e a empresa) não é grande o suficiente para justificar a contratação de um administrador de banco de dados dedicado. Nesta situação, pode ser mais barato trazer um especialista do fabricante de banco de dados para efetuar a aplicação inicial (e, talvez mais adiante, conforme a necessidade surgir) e então treinar o administrador de sistemas para uma técnica que será usada raramente. 8.1.3. Falhas no Ambiente Mesmo que o hardware esteja rodando perfeitamente, que o software esteja configurado corretamente e funcionando como deveria, os problemas ainda podem ocorrer. Os problemas mais comuns que ocorrem fora do próprio sistema têm relação com o ambiente físico no qual o sistema reside. As questões ambientais podem ser divididas em quatro categorias principais: • Integridade da construção • Eletricidade • Ar condicionado • Clima e o mundo externo 8.1.3.1. Integridade da Construção Para uma estrutura aparentemente simples, uma construção desempenha diversas funções. Oferece proteção dos elementos. Oferece o micro-clima adequado para o conteúdo do prédio. Tem mecanismos para oferecer energia e para proteger contra incêndios, roubos e vandalismo. Desempenhando todas estas funções, não é surpreendente o que pode dar errado com um prédio. Aqui estão algumas possibilidades a considerar: • Vazamentos no telhado podem alagar centros de dados. • Diversos sistemas do prédio (como água ou sistema de ar) podem falhar, tornando o edifício inabitável. 156 • Capítulo 8. Planejamento para Desastres O chão pode ter capacidade de carga insuficiente para suportar o equipamento que você pretende colocar no centro de dados. É importante ter uma mente criativa ao pensar nas diversas maneiras que um edifício pode falhar. A lista acima apenas pretende que você comece a seguir esta linha de raciocínio. 8.1.3.2. Eletricidade Como a eletricidade é o que move qualquer sistema de computador, as questões relacionadas à energia são primordiais para a mente dos administradores de sistemas em todo lugar. Há diversos aspectos diferentes da energia, que são abordados em detalhes nas seções seguintes. 8.1.3.2.1. A Segurança de Sua Energia Primeiramente, é necessário determinar o quão seguro seu abastecimento de energia deve ser. Assim como em quase todos os outros centros de dados, você obtém sua energia de uma empresa local através de linhas transmissoras de energia. Por causa disso, há limites no que você pode fazer para garantir que seu abastecimento principal de energia seja o mais seguro possível. Dica As empresas localizadas próximas aos limites de uma companhia energética talvez possam negociar as conexões em duas seções de energia: • Aquela prestando serviços na sua área • Aquela da companhia energética vizinha Os custos envolvidos em usar linhas de energia pela companhia energética vizinha são grandes, tornando esta opção viável somente para empresas grandes. No entanto, estas empresas descobrem que a redundância obtida compensa os custos em muitos casos. As principais coisas a verificar são os métodos através dos quais a energia é trazida até a sede de sua empresa e para dentro do edifício. As linhas de transmissão estão acima ou abaixo do solo? Linhas acima do solo são suscetíveis a: • Danos provocados por condições climáticas extremas (geadas, ventos, relâmpagos) • Acidentes de trânsito que danificam os postes e/ou transformadores • Animais que vagueiam nos lugares indevidos e provocam curto-circuitos nas linhas Por outro lado, as linhas abaixo do solo têm suas próprias desvantagens: • Danos provocados por construtores escavando em lugares indevidos • Enchente • Relâmpago (apesar de menos perigoso para linhas acima do solo) Continue seguindo as linhas de energia para dentro de seu edifício. Elas passam primeiro por um transformador externo? Este transformador está protegido dos carros ou árvores que possam cair? Todos os interruptores expostos estão protegidos contra o uso não autorizado? Uma vez dentro do edifício, as linhas de energia (ou os painéis aos quais estão ligadas) podem ter outros problemas? Por exemplo: um problema de encanamento pode inundar o quadro elétrico? Continue seguindo a energia para dentro do centro de dados. Há algo mais que possa interromper o suprimento de energia inesperadamente? Por exemplo: o centro de dados divide um ou mais circuitos Capítulo 8. Planejamento para Desastres 157 com cargas que não pertençam a este? Se assim for, a carga externa pode, um dia, passar pela proteção de sobrecarga do circuito, ’derrubando’ também o centro de dados. 8.1.3.2.2. Qualidade da Energia Não é suficiente garantir que a fonte de energia do centro de dados seja o mais segura possível. Você também deve preocupar-se com a qualidade da energia sendo distribuída pelo centro de dados. Há diversos fatores que devem ser considerados: Voltagem A voltagem da energia de entrada deve ser estável, sem reduções de voltagem (frequentemente chamadas de quedas, abatimentos ou brownouts) ou aumentos de voltagem (geralmente conhecidos como picos e surges). Formato da onda O formato da onda deve ser limpo, com THD (Distorção Harmônica Total) mínima. Frequência A frequência deve ser estável (a maioria dos países utiliza a frequência de 50Hz ou 60Hz). Ruído A energia não pode incluir nenhum ruído RFI (Interferência na Frequência de Rádio) ou EMI (Interferência Eletro-Magnética). Corrente A energia deve ser suprida a uma taxa de corrente suficiente para rodar o centro de dados. A energia suprida diretamente pela companhia energética geralmente não atende aos padrões necessários para um centro de dados. Sendo assim, é preciso algum nível de condicionamento da energia. Há diversas táticas possíveis: Protetores contra picos de energia Protetores contra picos de energia fazem exatamente o que o nome implica — eles filtram os picos do suprimento de energia. A maioria não faz mais nada, deixando o equipamento vulnerável aos danos de outros problemas relativos à energia. Condicionadores de Energia Os condicionadores de energia tentam uma tática mais detalhada. Dependendo da sofisticação da unidade, os condicionadores de energia frequentemente podem resolver a maioria dos problemas citados acima. Gerador Um gerador é basicamente um grande motor elétrico movido pelo seu suprimento de energia normal. O motor é ligado a uma grande hélice, que por sua vez é ligada a um gerador. O motor roda a hélice e o gerador, que gera eletricidade suficiente para rodar o centro de dados. Desta maneira, a energia do centro de dados é isolada eletricamente da energia externa, eliminando a maioria dos problemas relativos à energia. A hélice também oferece a habilidade de manter a energia durante a falta de eletricidade, já que leva vários segundos para a hélice reduzir sua velocidade até o ponto no qual não pode mais gerar energia. 158 Capítulo 8. Planejamento para Desastres Suprimentos de Energia Ininterruptos Alguns Suprimentos de Energia Ininterruptos (mais comumente conhecidos como UPSs) incluem a maioria (se não todas) das funções de proteção de um condicionador de energia 2 . Com as duas tecnologias listadas acima, nós iniciamos o tópico no qual a maioria das pessoas pensa ao falar sobre energia — energia backup. Na próxima seção, exploraremos táticas diferentes para prover energia backup. 8.1.3.2.3. Energia Backup Há um termo relativo à energia no qual quase todos já ouviram falar — blackout. Um blackout é a perda total da energia elétrica e pode durar de uma fração de segundo a semanas. Como a duração do blackout pode variar drasticamente, é necessário utilizar a tática de prover energia backup usando tecnologias diferentes para faltas de energia de durações diferentes. Dica Os blackouts mais frequentes duram, em média, alguns segundos; faltas de energia mais longas são menos frequentes. Sendo assim, concentre primeiro em proteger seus sistemas contra blackouts de alguns segundos de duração, e então trabalhe nos métodos para reduzir sua exposição à faltas mais longas. 8.1.3.2.3.1. Provendo Energia Para os Próximos Segundos Já que a maioria das faltas de energia duram somente alguns segundos, sua solução de energia backup deve ter duas características principais: • Tempo bem curto para trocar para energia backup (conhecido como tempo de transferência) • Um tempo de execução (o tempo que a energia backup durará) medido de segundos a minutos As soluções de energia backup que atendem a estas características são os geradores e UPSs. A hélice do gerador permite que este continue produzindo eletricidade por tempo suficiente para faltas de energia de aproximadamente um segundo. Os geradores tendem a ser bem grandes e caros, o que os torna práticos para empresas de médio e grande porte. Entretanto, uma outra tecnologia — chamada UPS — pode servir para situações nas quais o gerador é muito caro. O UPS também pode lidar com faltas de energia mais longas. 8.1.3.2.3.2. Provendo Energia Para os Próximos Minutos Os UPSs podem ser adquiridos em diversos tamanhos — suficientemente pequeno para rodar um PC por cinco minutos ou suficientemente grande para prover energia para um centro de dados inteiro por uma hora ou mais. Os UPSs são compostos das seguintes partes: • Um interruptor de transferência para mudar da fonte de energia principal para a fonte de energia backup • Uma bateria, para prover energia backup 2. A tecnologia UPS é abordada em mais detalhes na Seção 8.1.3.2.3.2. Capítulo 8. Planejamento para Desastres • 159 Um conversor, que converte a corrente DC da bateria em corrente AC necessária para o hardware do centro de dados Além do tamanho e capacidade da bateria da unidade, os UPSs têm dois tipos básicos: • O UPS offline usa seu conversor para gerar energia somente quando o suprimento de energia principal falhar. • O UPS online usa seu conversor para gerar energia o tempo todo, provendo energia para seu conversor 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 habilidade 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 é raramente provida. Em todo caso, os números VA obtidos com esta tática refletem os valores nas piores situações, deixando uma grande margem de erro para segurança. Determinar o tempo de execução é uma questão mais de negócios que técnica — contra quais tipos de queda você deseja se proteger e quanto pretende gastar para tanto? A maioria das empresas seleciona tempos de execução menores que uma ou duas horas no máximo, pois a energia backup provida pela bateria torna-se muito cara além deste ponto. 8.1.3.2.3.3. Provendo Energia Para as Próximas Horas (e Além) Quando atingirmos as quedas de energia medidas em dias, as opções tornam-se ainda mais caras. As tecnologias com capacidade de lidar com quedas de energia de longo prazo são limitadas a geradores movidos por algum tipo de motor — principalmente, a diesel e turbina a gás. Nota Tenha em mente que os geradores movidos a motores requerem o reabastecimento constante enquanto estão ligados. Você deve saber qual é a taxa de "consumo" de combustível do seu gerador na capacidade máxima e coordenar a entrega apropriada de combustível. 160 Capítulo 8. Planejamento para Desastres Neste ponto, você tem um grande leque de opções, assumindo que sua empresa tenha o orçamento necessário. Esta também é uma área na qual os peritos devem ajudá-lo a determinar a melhor solução para a empresa. Somente alguns administradores de sistemas tem o conhecimento especializado necessário para planejar a aquisição e aplicação destes tipos de sistemas de geração de energia. Dica Geradores portáteis de todos os tamanhos podem ser alugados, possibilitando ter os benefícios da energia do gerador sem a despesa inicial para adquirir um. No entanto, tenha em mente que nos desastres que afetam sua vizinhança em geral, os geradores poderão estar em falta para alugar e muito caros. 8.1.3.2.4. Planejamento para Quedas Extensas Enquanto um blackout de cinco minutos é algo mais do que um inconveniente para os funcionários num escritório escuro, o que ocorre com uma queda de uma hora? E de cinco horas? Um dia? Uma semana? De fato, mesmo se o centro de dados estiver operando normalmente, uma queda de energia extensa poderá afetar sua empresa em algum momento. Considere os seguintes pontos: • E se não houver energia para manter o controle ambiental no centro de dados? • E se não houver energia para manter o controle ambiental no edifício inteiro? • E se não houver energia para operar estações de trabalho, sistema de telefonia e/ou luzes? A questão é determinar até que ponto uma queda deve ser tolerada em sua empresa. Ou, se esta não for uma opção, sua empresa deve considerar operar completamente independente da energia dentro da empresa por períodos extensos, o que significa que geradores muito grandes serão necessários para prover energia para o edifício inteiro. Obviamente, mesmo esse nível de planejamento não pode ser feito do nada. É muito provável que o que causou a queda extensa também está afetando o mundo externo à sua empresa, e que o mundo externo começará a afetar a habilidade da sua empresa em continuar operando, mesmo que tenha capacidade ilimitada de geração de energia. 8.1.3.3. Aquecimento, Ventilação e Ar Condicionado Os sistemas de Aquecimento, Ventilação e Ar Condicionado (Heating, Ventilation, and Air Conditioning - HVAC) usados nos edifícios hoje em dia são incrivelmente sofisticados. Geralmente controlado por computadores, o sistema HVAC é vital para prover um ambiente de trabalho confortável. Os centros de dados geralmente possuem equipamento próprio de refrigeração, principalmente para remover o calor gerado pelos diversos computadores e outros equipamentos. As falhas no sistema HVAC podem ser devastadoras para a operação contínua de um centro de dados. Dada sua complexidade e natureza eletro-mecânica, as possibilidades de falha são muitas e variadas. Aqui estão alguns exemplos: • As unidades de refrigeração (basicamente ventiladores grandes movidos por grandes motores elétricos) podem falhar devido a sobrecarga elétrica, falha no rolamento, falha na correia/roldana, etc. Capítulo 8. Planejamento para Desastres • 161 As unidades de refrigeração (frequentemente chamadas de chillers) podem perder sua refrigeração devido a vazamentos, ou a problemas em seus motores e/ou compressores. O reparo e a manutenção do sistema HVAC são áreas muito especializadas — áreas que um administrador de sistemas deve deixar para os peritos. De qualquer maneira, um administrador de sistemas deve garantir que o equipamento HVAC do centro de dados seja verificado diariamente (ou com mais frequência) e seja mantido de acordo com as intruções do fabricante. 8.1.3.4. Fatores Climáticos e o Mundo Externo Há alguns fatores climáticos que podem causar problemas ao administrador de sistemas: • Muita neve e gelo podem impedir que funcionários cheguem ao centro de dados, e podem inclusive entupir os condensadores do ar condicionado, resultando em temperaturas elevadas no centro de dados exatamente quando ninguém consegue chegar até lá para tomar as devidas providências. • Ventos fortes podem interromper a energia e as comunicações; ventos muito fortes podem, na realidade, 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, conforme o consumo de energia fica sobrecarregado. Apesar de não haver muito a fazer sobre os fatores climáticos, saber como eles podem afetar as operações de seu centro de dados pode ajudá-lo a mantê-lo em funcionamento mesmo quando o clima estiver muito ruim. 8.1.4. Erros Humanos Já foi dito que os computadores realmente são perfeitos. A razão dessa afirmação é, que se você investigar a fundo, descobrirá um erro humano por trás de todo erro do computador. Nesta seção, exploramos os tipos de erros humanos mais comuns e seus impactos. 8.1.4.1. Erros de Usuários Finais Os usuários de um computador podem cometer erros com sérios impactos. No entanto, devido seu ambiente operacional normalmente desprivilegiado, os erros de usuários tendem a ser localizados. Como a maioria dos usuários interage com um computador exclusivamente através de uma ou mais aplicações, é dentro das aplicações que a maioria dos erros de usuários finais ocorre. 8.1.4.1.1. Uso Impróprio das Aplicações Quando as aplicações são usadas impropriamente, vários problemas podem ocorrer: • Arquivos sobrescritos inadvertidamente • Dados errados usados como input numa aplicação • Arquivos nomeados e organizados de maneira confusa • Arquivos apagados acidentalmente Poderíamos continuar esta lista, mas isso é suficiente para ilustrar a questão. Devido o fato de usuários não terem privilégios de super-usuário, os erros cometidos por eles geralmente limitam-se aos seus próprios arquivos. Sendo assim, a malhor tática é bifurcada: • Educar os usuários no uso apropriado de suas aplicações e técnicas de administração de arquivos 162 • Capítulo 8. Planejamento para Desastres Garantir que os backups dos arquivos dos usuários sejam feitos regularmente e que o processo de restauração seja o mais simples e rápido possível Além disso, há pouco a fazer para limitar os erros dos usuários. 8.1.4.2. Erros de Funcionários Operacionais Os operadores tem uma relação mais profunda com os computadores da empresa que os usuários finais. Enquanto os usuários finais tendem a se basear nas aplicações, os operadores tendem a executar um leque de tarefas mais abrangente. Mesmo que a natureza das tarefas tenha sido ditada por outras pessoas, algumas das tarefas podem incluir o uso de utilitários a nível do sistema, onde é maior o potencial de grandes danos por causa de erros. Consequentemente, os tipos de erros que podem ser cometidos por um operador baseiam-se na sua habilidade em seguir os procedimentos desenvolvidos para este uso. 8.1.4.2.1. Falha em Seguir Procedimentos Os operadores devem ter conjuntos de procedimentos documentados e disponíveis para praticamente todas as ações que executam 3. Pode acontecer de um operador não seguir os procedimentos conforme são apresentados. Podem haver diversas razões para isso: • O ambiente foi alterado em algum momento do passado e os procedimentos não foram atualizados. Agora o ambiente mudou novamente, tornando inválidos os procedimentos memorizados pelo operador. 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 comunicar suas preocupações ao gerente apropriado. Em todo caso, a melhor tática é colocar-se à disposição para fazer o que puder para resolver o problema. 8.1.4.2.2. Erros Cometidos Durante os Procedimentos Mesmo se o operador seguir os procedimentos, e mesmo que os procedimentos estejam corretos, ainda é possível que erros ocorram. Se isto acontecer, existe a possibilidade do operador ter sido displicente (neste caso a gerência do operador deve ser envolvida). Uma outra explicação é que foi apenas um erro. Nestes casos, os melhores operadores percebem que algo está errado e procuram por ajuda. É bom sempre encorajar os operadores com quem você trabalha a contatar as pessoas apropriadas imediatamente, se suspeitarem que algo está errado. Apesar de alguns operadores serem altamente qualificados e capazes de resolverem muitos problemas sozinhos, o fato é que este não é o trabalho deles. A boa vontade do operador pode piorar o problema, prejudicar a carreira dele e também a sua habilidade em resolver rapidamente o que, originalmente, talvez fosse um pequeno problema. 3. Se os operadores de sua empresa não possuem um conjunto de procedimentos operacionais, trabalhe com eles, com a gerência e com seu usuários para criá-los. Sem eles, um centro de dados está fora de controle e propenso a ter problemas sérios no dia-a-dia das operações. Capítulo 8. Planejamento para Desastres 163 8.1.4.3. Erros do Administrador de Sistemas Ao contrário dos operadores, os administradores de sistemas executam uma grande variedade de tarefas usando os computadores de uma empresa, e estas tarefas frequentemente não são baseadas em procedimentos documentados. Consequentemente, os administradores de sistemas algumas vezes executam trabalho desnecessário quando não tomam cuidado com o que fazem. No curso de suas responsabilidades do dia-a-dia, os administradores de sistemas têm suficiente acesso aos sistemas (sem mencionar seus privilégios de super-usuário) para derrubá-los por engano. Os administradores de sistemas cometem erros de má configuração ou erros durante a manutenção. 8.1.4.3.1. Erros de Má Configuração Os administradores de sistemas frequentemente precisam configurar vários aspectos de um sistema. Esta configuração pode incluir: • E-mail • Contas de usuários • Rede • Aplicações A lista poderia continuar. A tarefa de configurar em si varia enormemente; algumas requerem editar um arquivo texto (usando qualquer uma das centenas de sintaxes diferentes do arquivo de configuraçã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) é fundamentalmente diferente de configurar uma nova conexão de rede. Sendo assim, talvez seja surpreendente que apenas alguns erros sejam cometidos. De qualquer maneira, a configuração é, e continuará sendo, um desafio para administradores de sistemas. Há algo a fazer para tornar o processo menos suscetível a erros? 8.1.4.3.1.1. Controle de Mudanças Um aspecto comum de toda configuração é que sempre há alterações. Independente de ser uma pequena ou grande alteração, deve ser tratada de maneira específica. Muitas empresas implementam algum tipo de processo de controle de alterações. A intenção é auxiliar administradores de sistemas (e todas as partes afetadas pela alteração) a gerenciar o processo de alteração e reduzir a exposição da empresa a erros que possam ocorrer. Um processo de controle de alterações geralmente divide a alteração em dois passos. Aqui está um exemplo: Pesquisa preliminar Tentativas de pesquisa preliminar para definir claramente: • A natureza da alteração a ocorrer • Seu impacto, caso a alteração realmente ocorra • Uma posição de resguarda, se a alteração falhar • Uma avaliação dos possíveis tipos de falha 164 Capítulo 8. Planejamento para Desastres A pesquisa preliminar pode incluir testes da alteração proposta durante um tempo fora do ar agendado, ou pode incluir a implementação da alteração primeiramente num ambiente de teste especial executado em hardware de teste. Agendamento A alteração é examinada tendo em mente a mecânica da implementação. O agendamento inclui apontar a sequência e o tempo da alteração (juntamente a sequências e tempos de quaisquer passos necessários para retornar ao estado original caso ocorra algum problema), e também garantir que o tempo alocado para a alteração é suficiente e não conflitante com nenhuma outra atividade no nível do sistema. O produto deste processo é frequentemente uma lista de passos para o administrador de sistemas usar enquanto executa a alteração. Juntamente a cada um dos passos, incluimos as instruções para retornar ao estado original, caso a alteração falhar. Os tempos estimados também são inclusos, facilitando ao administrador de sistemas determinar se o trabalho está dentro do prazo ou não. Execução Neste ponto, a execução dos passos necessários para implementar a alteração deve ser simples e anti-climática. A alteração é então implementada ou, se houver problemas, abortada. Monitoramento Independente da alteração ser implementada ou não, o ambiente é monitorado para garantir que tudo está sendo operado devidamente. Documentando Se a alteração foi implementada, toda a documentação existente deve ser atualizada para refletir a configuração alterada. Obviamente, nem todas as alterações requerem este nível de detalhe. Criar uma nova conta de usuário não deve requerer nenhuma pesquisa preliminar e o agendamento deve consistir em determinar se o administrador de sistemas tem um tempinho para criar a conta. A execução também deve ser rápida; o monitoramento deve se restringir a garantir que a conta é utilizável e a documentação provavelmente seria enviar um e-mail ao gerente do novo usuário. Mas, conforme as alterações de configuração tornam-se mais complexas, é necessário ter um processo de controle de alterações mais formal. 8.1.4.3.2. Erros Cometidos Durante a Manutenção Este tipo de erro pode ser maléfico porque geralmente há muito pouco planejamento e registro feitos durante a manutenção diária. Os administradores de sistemas vêem diariamente os resultados deste tipo de erro, especialmente cometidos por muitos usuários que juram não alterarem nada — o computador simplesmente quebrou. O usuário que diz isso geralmente não lembra o que fez, e quando o mesmo acontece com você, provavelmente você também não lembrará. A principal questão é que você deve ser capaz de lembrar das alterações efetuadas durante a manutenção, se for capaz de resolver qualquer problema rapidamente. Um processo de controle completo não é adequado para as centenas de coisas pequenas feitas ao longo do dia. O que pode ser feito para manter o registro das 1001 coisas pequenas que um administrador de sistemas faz todos os dias? A resposta é simples — tome nota. Independentemente de ser anotado num caderno, num PDA ou como comentários nos arquivos afetados, anote! Ao registrar o que você fez, tem maiores chances de relacionar uma falha a uma alteração recentemente efetuada. Capítulo 8. Planejamento para Desastres 165 8.1.4.4. Erros do Técnico de Serviço Às vezes, as pessoas que supostamente te ajudariam a manter seus sistemas rodando confiavelmente, podem tornar as coisas piores. Isto não se deve a nenhuma conspiração; simplesmente qualquer um trabalhando em alguma espécie de tecnologia tem o risco de tornar esta tecnologia inoperante. O mesmo efeito pode ocorrer no ambiente de trabalho, quando os programadores consertam um bug e acabam criando outro. 8.1.4.4.1. Hardware Consertado Inapropriadamente Neste caso, o técnico falhou em diagnosticar o problema corretamente e efetuou um conserto desnecessário (e inútil), ou o diagnóstico estava correto, mas o conserto não foi efetuado apropriadamente. Pode ser que a peça substituída estava com defeito, ou que o procedimento apropriado não foi seguido durante o conserto. Por isso é importante estar ciente do que os técnicos estão fazendo todo o tempo. Ao fazer isso, você pode estar atento a falhas que parecem estar relacionadas ao problema original de alguma maneira. Isto mantém o registro do técnico caso haja algum problema; caso contrário há uma chance do técnico ver esta falha como nova e não relacionada àquela supostamente consertada. Desta maneira, não perde-se tempo verificando o problema errado. 8.1.4.4.2. Consertando Uma Coisa e Quebrando Outra Às vezes, mesmo que o problema seja diagnosticado e consertado com sucesso, aparece outro problema para tomar seu lugar. O módulo da CPU foi substituído, mas o saco anti-estático no qual ele estava embrulhado foi deixado dentro do cabinete, bloqueando o ventilador e causando um desligamento por causa da temperatura elevada. Ou então o drive falho do disco no conjunto RAID foi substituído, mas como um conector em outro drive foi esbarrado e acidentalmente desconectado, o conjunto ainda está com problemas. Não importa se estas coisas são resultado de descuido crônico ou simplesmente um erro honesto. Você deve sempre rever cuidadosamente os consertos feitos pelo técnico e garantir que o sistema esteja funcionando corretamente antes que o técnico vá embora. 8.2. Backups Os backups tem dois objetivos principais: • Permitir a recuperação de arquivos individuais • Permitir a recuperação de sistemas de arquivo inteiros de uma só vez O primeiro objetivo é a base do típico pedido de recuperação de arquivo: um usuário apaga acidentalmente um arquivo e pede que seja recuperado pelo último backup. As circunstâncias exatas podem variar, mas este é o uso cotidiano mais comum para backups. A segunda situação é o pior pesadelo do administrador de sistemas: por alguma razão, o administrador de sistemas está mexendo no hardware que era uma parte produtiva do centro de dados. Agora, é algo mais do que um pedaço de aço e silicone. O que falta são todos os software e dados que você e seus usuários vem desenvolvendo ao longo dos anos. Supostamente, há backup de tudo. A questão é: há realmente este backup? E se houver, você é capaz de recuperá-lo? 166 Capítulo 8. Planejamento para Desastres 8.2.1. Dados Diferentes: Necessidades Diferentes de Backup Atente para os tipos de dados4 processados e armazenados por um sistema de computador típico. Note que alguns dados quase nunca mudam, e outros estão em mudança constante. A velocidade na qual os dados são alterados é crucial para desenvolver um procedimento de backup. Há duas razões para isso: • Um backup nada mais é do que uma imagem instantânea dos dados sendo copiados. É um reflexo dos dados em um determinado momento. • Dados que são alterados com pouca frequência podem ter backups com pouca frequência, enquanto dados com alterações frequentes devem ter backups mais frequentes. Os administradores de sistemas que têm um bom conhecimento de seus sistemas, usuários e aplicações devem ser capazes de agrupar os dados em categorias diferentes nos seus sistemas. No entanto, aqui estão alguns exemplos para que você possa começar: Sistema Operacional Estes dados são normalmente alterados somente durante atualizações (upgrades), instalações de consertos de erros (bug fixes) e quaisquer modificações específicas da empresa. Dica Você deve se importar com backups do sistema operacional? Esta é uma questão que muitos administradores de sistemas vêm ponderando ao longo dos anos. De um lado, se o processo de instalação é relativamente fácil, e se a aplicação de consertos de erros e personalizações são bem documentadas e de fácil reprodução, reinstalar o sistema operacional pode ser uma opção viável. Por outro lado, se há alguma dúvida que uma nova instalação pode recriar o ambiente do sistema operacional original, fazer backup do sistema operacional é a melhor opção, mesmo que os backups sejam feitos com menor frequência que os backups dos dados de produção. Backups ocasionais do sistema operacional também podem ser práticos quando apenas alguns arquivos do sistema precisarem ser restaurados (ex.: devido à remoção acidental de arquivos). Software da Aplicação Estes dados são alterados sempre que as aplicações são instaladas, atualizadas ou removidas. Dados das Aplicações Estes dados são alterados com a mesma frequência que as aplicações são utilizadas. Dependendo da aplicacão e da sua empresa, isto pode significar que as alterações ocorrem a cada segundo ou uma vez no final de cada ano fiscal. Dados dos Usuários Estes dados alteram de acordo com os padrões de uso da sua comunidade de usuários. Na maioria das empresas, isto significa que as alterações ocorrem toda hora. Baseando-se nestas categorias (e outras específicas à sua empresa), você deve ter uma boa idéia sobre a natureza dos backups necessários para proteger seus dados. 4. Estamos usando o termo dados nesta seção para descrever tudo o que é processado através do software de backup. Isto inclui o software do sistema operacional, o software da aplicação e também os dados atuais. Não importa o que são; desde que a preocupação seja software de backup, tudo são dados. Capítulo 8. Planejamento para Desastres 167 Nota Você deve ter em mente que a maioria dos software de backup lida com os dados no nível do diretório ou sistema de arquivo. Em outras palavras, a estrutura dos diretórios de seu sistema influenciam o modo como os backups serão feitos. Esta é uma outra razão para pensar cuidadosamente na melhor estrutura de diretórios para um novo sistema e agrupar arquivos e diretórios de acordo com seu uso antecipado. 8.2.2. Software de Backup: Comprar versus Criar Para executar backups, é necessário ter primeiramente o software apropriado. Este software deve não somente executar a tarefa básica de copiar bits em mídia de backup, mas também interagir claramente com os funcionários e necessidades de sua empresa. Aqui estão algumas características a considerar ao analisar o software de backup: • Agenda os backups para rodarem num horário apropriado • Administra a localização, rotação e o uso da mídia de backup • Trabalha com operadores (e/ou com alteradores de mídia robótica) para garantir que a mídia apropriada está disponível • Auxilia os operadores na localização da mídia contendo o backup específico de um determinado arquivo Como você pode ver, uma boa solução de backup significa bem mais do que somente enviar bits para sua mídia de backup. Neste ponto, a maioria dos administradores de sistemas procura por uma das duas soluções: • Comprar uma solução desenvolvida comercialmente • Criar um sistema de backup internamente do zero (possivelmente intergrando uma ou mais tecnologias open source) Cada uma destas táticas tem seus pontos fortes e fracos. Dada a complexidade do trabalho, uma solução criada internamente provavelmente não atenderá alguns aspectos (como administração da mídia ou ter documentação detalhada e suporte técnico) apropriadamente. Entretanto, para algumas empresas, isto pode não ser uma desvantagem. Uma solução desenvolvida comercialmente provavelmente é altamente funcional, mas também pode ser muito complexa para as necessidades atuais da empresa. Sendo assim, a complexidade pode possibilitar continuar com a mesma solução conforme a empresa crescer. Portanto, não existe um sistema de backup claramente indicado para todos os casos. A única dica é pedir que você considere estes pontos: • Mudar o software de backup é difícil; uma vez implementado, você o utilizará por um bom tempo. Acima de tudo, você terá backups arquivados por um longo tempo que possa ler. Mudar o software de backup significa que você terá que manter o software original (para acessar os backups arquivados), ou deverá converter seus backups arquivados para serem compatíveis com o software novo. Dependendo do software de backup, o esforço envolvido em converter os backups arquivados pode ser tão simples (mas demorado) quanto rodar os backups através de um programa de conversão já existente, ou pode ser necessária engenharia reversa no formato do backup e desenvolver software personalizado para executar a tarefa. 168 Capítulo 8. Planejamento para Desastres • O software deve ser 100% confiável — deve fazer o backup do que for necessário e quando for necessário. • Quando chegar o momento de restaurar quaisquer dados — seja um arquivo ou um sistema de arquivos inteiro — o software de backup deve ser 100% confiável. 8.2.3. Tipos de Backups Se você perguntar a alguém que não é familiarizado com backups, a maioria pensará que um backup é somente uma cópia idêntica de todos os dados do computador. Em outras palavras, se um backup foi criado na noite de terça-feira, e nada mudou no computador durante o dia todo na quarta-feira, o backup criado na noite de quarta seria idêntico àquele criado na terça. Apesar de ser possível configurar backups desta maneira, é mais provável que você não o faça. Para entender mais sobre este assunto, devemos primeiro entender os tipos diferentes de backup que podem ser criados. Estes são: • Backups completos • Backups incrementais • Backups diferenciais 8.2.3.1. Backups Completos O tipo de backup abordado no início desta seção é conhecido como um backup completo. Este tipo consiste no backup de todos os arquivos para a mídia de backup. Conforme mencionado anteriormente, se os dados sendo copiados nunca mudam, cada backup completo será igual aos outros. Esta similaridade ocorre devido o fato que um backup completo não verifica se o arquivo foi alterado desde o último backup; copia tudo indiscriminadamente para a mídia de backup, tendo modificações ou não. Esta é a razão pela qual os backups completos não são feitos o tempo todo — todos os arquivos são gravados na mídia de backup. Isto significa que uma grande parte da mídia de backup é usada mesmo que nada tenha sido alterado. Fazer backup de 100 gigabytes de dados todas as noites quando talvez 10 gigabytes de dados foram alterados não é uma boa prática; por este motivo os backups incrementais foram criados. 8.2.3.2. Backups Incrementais Ao contrário dos backups completos, os backups incrementais primeiro verificam se o horário de alteração de um arquivo é mais recente que o horário de seu último backup. Se não for, o arquivo não foi modificado desde o último backup e pode ser ignorado desta vez. Por outro lado, se a data de modificação é mais recente que a data do último backup, o arquivo foi modificado e deve ter seu backup feito. Os backups incrementais são usados em conjunto com um backup completo frequente (ex.: um backup completo semanal, com incrementais diários). A vantagem principal em usar backups incrementais é que rodam mais rápido que os backups completos. A principal desvantagem dos backups incrementais é que para restaurar um determinado arquivo, pode ser necessário procurar em um ou mais backups incrementais até encontrar o arquivo. Para restaurar um sistema de arquivo completo, é necessário restaurar o último backup completo e todos os backups incrementais subsequentes. Numa tentativa de diminuir a necessidade de procurar em todos os backups incrementais, foi implementada uma tática ligeiramente diferente. Esta é conhecida como backup diferencial. Capítulo 8. Planejamento para Desastres 169 8.2.3.3. Backups Diferenciais Backups diferenciais são similares aos backups incrementais pois ambos podem fazer backup somente de arquivos modificados. No entanto, os backups diferenciais são acumulativos — em outras palavras, no caso de um backup diferencial, uma vez que um arquivo foi modificado, este continua a ser incluso em todos os backups diferenciais (obviamente, até o próximo backup completo). Isto significa que cada backup diferencial contém todos os arquivos modificados desde o último backup completo, possibilitando executar uma restauração completa somente com o último backup completo e o último backup diferencial. Assim como a estratégia utilizada nos backups incrementais, os backups diferenciais normalmente seguem a mesma tática: um único backup completo periódico seguido de backups diferenciais mais frequentes. O efeito de usar backups diferenciais desta maneira é que estes tendem a crescer um pouco ao longo do tempo (assumindo que arquivos diferentes foram modificados entre os backups completos). Isto posiciona os backups diferenciais em algum ponto entre os backups incrementais e os completos em termos de velocidade e utilização da mídia de backup, enquanto geralmente oferecem restaurações completas e de arquivos mais rápidas (devido o menor número de backups onde procurar e restaurar). Dadas estas características, os backups diferenciais merecem uma consideração cuidadosa. 8.2.4. Mídia de Backup Nós fomos muito cuidadosos ao usar o termo "mídia de backup" no decorrer das seções anteriores. Há uma razão para isso. A maioria dos administradores de sistemas experientes geralmente pensam em backups em termos de leitura e gravação de fitas, mas atualmente há outras opções. Houve um tempo em que os dispositivos de fita eram os únicos dispositivos de mídia removíveis que podiam ser usados para backups. No entanto, isto mudou. Nas seções seguintes, veremos as mídias de backup mais conhecidas e assim como suas vantagens e desvantagens. 8.2.4.1. Fita A fita foi o primeiro meio de armazenamento de dados removível amplamente utilizado. Tem os benefícios de custo baixo e uma capacidade razoavelmente boa de armazenamento. Entretanto, a fita tem algumas desvantagens — está sujeita ao desgaste e o acesso aos dados na fita é sequencial por natureza. Estes fatores significam que é necessário manter o registro do uso das fitas (aposentá-las ao atingirem o fim de suas vidas úteis) e também que a procura por um arquivo específico nas fitas pode ser uma tarefa longa. Por outro lado, a fita é uma das mídias de armazenamento em massa mais baratas e carrega uma longa reputação de confiabilidade. Isto significa que criar uma biblioteca de fitas de tamanho razoável não abocanha uma parcela grande de seu orçamento, e você pode confiar no seu uso atual e futuro. 8.2.4.2. Disco Nos últimos anos, os drives de disco nunca seriam usados como um meio de backup. No entanto, os preços de armazenamento caíram a um ponto que, em alguns casos, usar drives de disco para armazenamento de backup faz sentido. A razão principal para usar drives de disco como um meio de backup é a velocidade. Não há um meio de armazenamento em massa mais rápido. A velocidade pode ser um fator crítico quando a janela de backup do seu centro de dados é curta e a quantidade de dados a serem copiados é grande. Mas o armazenamento em disco não é o meio ideal de backup, por diversas razões: 170 Capítulo 8. Planejamento para Desastres • Os drives de disco normalmente não são removíveis. Um fator essencial para uma estratégia de backup efetiva é ter os backups fora do seu centro de dados e mantê-los em alguma forma de armazenamento fora da emrpesa. Um backup do seu banco de dados de produção há um metro de distância do banco de dados propriamente dito não é um backup; é uma cópia. As cópias não são muito úteis, caso o centro de dados e seu conteúdo (incluindo suas cópias) seja danificado ou destruído por um conjunto de infortúnios. • Os drives de disco são caros (ao menos se comparados a outras mídias de backup). Pode haver situações onde o dinheiro não é o problema, mas em todas as outras situações, as despesas associadas 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 desvantagens. Ao fazer backup através de uma rede, os drives de disco já estão fora da empresa, portanto não há necessidade de transportar drives de disco frágeis a lugar algum. Com largura de banda suficiente, é possível manter a vantagem da velocidade que você pode obter ao fazer backups em drives de disco. No entanto, esta tática não resolve a questão do armazenamento em arquivos (apesar de poder usar a mesma estratégia de passar para a fita após o backup). Além disso, os custos de um centro de dados remoto com um link de alta velocidade ao centro de dados principal encarecem demais esta solução. Capítulo 8. Planejamento para Desastres 171 Mas, para as empresas que precisam das características que esse tipo de solução pode oferecer, é um custo com o qual elas arcam com prazer. 8.2.5. Armazenamento de Backups O que acontece após completar os backups? A resposta óbvia é que os backups devem ser armazenados. Entretanto, não é tão óbvio o que deve ser armazenado — e onde. Para responder a estas questões, devemos considerar primeiro sob quais circunstâncias os backups devem ser usados. Há três situações principais: 1. Pequenos e rápidos pedidos de restauração dos usuários 2. Grandes restaurações para recuperar de um desastre 3. Armazenamento em arquivos, pouco provável de ser usado novamente Infelizmente, há diferenças irreconciliáveis entre os números 1 e 2. Quando um usuário apaga um arquivo acidentalmente, ele pretende recuperá-lo imediatamente. Isto siginifca que a mídia de backup não pode estar há mais de dois passos distante do sistema para o qual os dados devem ser restaurados. No caso de um desastre que precisa de uma restauração completa de um ou mais computadores do seu centro de dados, se o desastre foi de natureza física, o que quer que tenha destruído seus computadores, também destruiria os backups localizados próximos dos computadores. Isto seria uma situação terrível. O armazenamento em arquivos é menos controverso. Já que a chance de ser utilizado para qualquer propósito é baixa, não haveria problema se a mídia de backup estivesse localizada há quilômetros de distância do centro de dados. As táticas para resolver estas diferenças variam de acordo com as necessidades da empresa em questão. Uma tática possível é armazenar o backup de diversos dias na empresa; estes backups são então levados para um local de armazenamento mais seguro fora da empresa quando os backups diários mais novos forem criados. Uma outra tática seria manter dois conjuntos diferentes de mídia: • Um conjunto no centro de dados estritamente para pedidos imediatos de restauração • Um conjunto fora da empresa para armazenamento externo e recuperação de desastres Obviamente, ter dois conjuntos significa ter a necessidade de rodar todos os backups duas vezes para fazer uma cópia dos backups. Isto pode ser feito, mas backups duplos podem levar muito tempo e copiar requer diversos drives de backup para processar (e provavelmente um sistema dedicado a executar as cópias). O desafio do administrador de sistemas é encontrar um equilíbrio que atenda adequadamente às necessidades de todos, e também assegurar que os backups estejam disponíveis para a pior das situações. 8.2.6. Questões de Restauração Enquanto os backups são uma ocorrência diária, as restaurações normalmente representam um evento menos frequente. No entanto, as restaurações são inevitáveis; elas serão necessárias, portanto é melhor estar preparado. É importante atentar para os vários cenários de restauração detalhados ao longo desta seção e determinar maneiras para testar sua habilidade em resolvê-los. E tenha em mente que o mais dfiícil de testar também é o mais crítico. 172 Capítulo 8. Planejamento para Desastres 8.2.6.1. Restaurando do Zero "Restaurar do zero" significa restaurar um backup de sistema completo em um computador com absolutamente nenhum dado de nenhum tipo — sem sistema operacional, sem aplicações; nada. Em geral, há duas táticas básicas para restaurações do zero: Reinstalar, seguido de restauração Aqui o sistema operacional base é instalado como se um computador novo estivesse sendo configurado. Após instalar e configurar o sistema operacional, os drives de disco restantes podem ser particionados e formatados, e todos os backups restaurados pela mídia de backup. Discos de recuperação do sistema Um disco de recuperação do sistema é uma mídia iniciável (bootable) de algum tipo (geralmente um CD) que contém um ambiente de sistema mínimo, capaz de executar as tarefas mais básicas de administração de sistemas. O ambiente de recuperação contém os utilitários necessários para particionar e formatar os drives de disco, os drives de dispositivo necessários para acessar o dispositivo de backup e o software necessário para restaurar os dados pela mídia de backup. Nota Alguns computadores têm a habilidade de criar fitas de backup iniciáveis e de inicializar através delas para começar o processo de restauração. No entanto, esta capacidade não está disponível em todos os computadores. Notavelmente, os computadores baseados na arquitetura PC não permitem está tática. 8.2.6.2. Testando Backups Todos os tipos de backup devem ser testados periodicamente para garantir que os dados podem ser lidos através deles. É fato que, às vezes, os backups executados são por algum motivo ilegíveis. O pior é que muitas vezes isto só é percebido quando os dados foram perdidos e devem ser restaurados pelo backup. As razões para isto ocorrer podem variar desde alterações no alinhamento do cabeçote do drive de fita, software de backup mal-configurado a um erro do operador. Independente da causa, sem o teste periódico você não pode garantir que está gerando backups através dos quais poderá restaurar dados no futuro. 8.3. Recuperação de Desastres Como um experimento rápido, na próxima vez em que você estiver no seu centro de dados, olhe ao redor e imagine por um momento que este se foi. Não só os computadores, mas imagine que o prédio todo não existe mais. Em seguida, imagine que seu trabalho é executar a maior parte das tarefas que eram executadas no centro de dados da mesma forma, em outro lugar, o mais rápido possível. O que você faria? Ao pensar nisso, você tomou o pirmeiro passo da recuperação de desastres. A recuperação de desastres é a habilidade de recuperar a sua empresa de um evento que impactou o funcionamento do seu centro de dados o mais competente e rapidamente possível. O tipo de desastre pode variar, mas o objetivo final é sempre o mesmo. Capítulo 8. Planejamento para Desastres 173 Os passos envolvidos na recuperação de desastres são diversos e abrangentes. Aqui está uma visão geral do processo, juntamente a pontos-chave para ter em mente. 8.3.1. Criando, Testando e Implementando um Plano de Recuperação de Desastres Um local de backup é vital, mas é inútil sem um plano de recuperacão de desastres. Um plano de recuperacão de desastres determina cada faceta do processo de recuperacão de desastres, incluindo, mas não limitado a: • Quais eventos denotam possíveis desastres • Quais pessoas na empresa têm autorização para declarar um desastre e, consequentemente, colocar o plano em ação • A sequência de eventos necessária para preparar o local de backup, uma vez declarado o desastre • As funções e responsabilidades de todo o pessoal envolvido na execução do plano • Um inventário do hardware e software necessários para restaurar a produção • Um cronograma listando os membros da equipe que compoem o local de backup, incluindo um cronograma de rotação para suportar a continuação das operações sem estressar os membros da equipe • A sequência de eventos necessária para mover as operações do local de backup para o centro de dados novo/restaurado Os planos de recuperação de desastres frequentemente servem o propósito de juntar todos os detalhes. Este nível de detalhe é vital porque, no caso de uma emergência, o plano pode ser a única coisa que restou do seu centro de dados anterior (obviamente, além dos backups externos) para ajudá-lo na reconstrução e restauração das operações. Dica Os planos de recuperação de desastres estarem prontamente disponíveis no seu ambiente de trabalho, mas também é necessário ter cópias externas. Desta maneira, um desastre que destrua seu ambiente de trabalho não atingirá todas as cópias do plano de recuperação de desastres. Um bom lugar para guardar esta cópia é o local de armazenamento dos backups externos. Se não for violar as normas de segurança da sua empresa, as cópias também podem ser guardadas nas casas de membros-chave da equipe, prontas para uso imediato. Um documento importante como este merece seriedade (e possivelmente assistência profissional para ser criado). Uma vez criado este documento importante, o conhecimento nele contido deve ser periodicamente testado. Testar um plano de recuperação de desastres significa percorrer os passos do plano: ir ao local do backup e criar um centro de dados temporário, rodar aplicações remotamente e retornar às operações normais após o fim do "desastre". A maioria dos testes não tenta executar 100% das tarefas contidas no plano; ao invés disso, um sistema e uma aplicação representativos são selecionadas e realocadas ao local do backup, colocadas em produção por um período e retornadas à operação normal no fim do teste. Nota Apesar de ser uma frase batida, um plano de recuperação de desastres deve ser um documento vivo; conforme o centro de dados sofre mudanças, o plano deve ser atualizado para refletir estas 174 Capítulo 8. Planejamento para Desastres alterações. De muitas maneiras, um plano de recuperação de desastres desatualizado pode ser pior que não ter plano algum, portanto se organize para executar revisões e atualizações regulares (a cada três meses, por exemplo) no plano. 8.3.2. Locais de Backup: Frios, Mornos e Quentes Um dos aspectos mais importantes da recuperação de um desastre é ter o local a partir do qual a recuperação pode ser feita. Este local também é conhecido como um site de backup. No caso de um desastre, um site de backup é onde seu centro de dados será recriado, e de onde você estará operando durante o desastre. Há três tipos diferentes de sites de backup: • Sites de backup frios • Sites de backup mornos • Sites de backup quentes Obviamente, estes termos não fazem referência à temperatura do site de backup. Mas sim ao esforço necessário para iniciar as operações no site de backup, caso ocorra um desastre. Um site de backup frio é um pouco mais do que um espaço configurado apropriadamente num prédio. Tudo o que é necessário para restaurar o serviço para seus usuários deve ser obtido e entregue ao site antes de começar o processo de recuperação. Como você pode imaginar, a demora na transformação de um site de backup frio numa operação completa pode ser substancial. Sites de backup frios são os mais baratos. Um site de backup morno já é estocado com hardware parecido com o que você tem no seu centro de dados. Para recuperar o serviço, os últimos backups do seu local de armazenamento externo devem ser entregues e uma restauração do zero deve ser completa, antes de realmente iniciar a recuperação. Sites de backup quentes tem uma imagem espelho virtual de seu centro de dados atual, com todos os sistemas configurados e aguardando somente os últimos backups dos dados de seus usuários vindos do local de armazenamento externo. Como você pode imaginar, um site de backup quente pode ser transformado num local de produção completo em apenas algumas horas. Um site de backup quente é a tática mais cara de recuperação de desastres. Os sites de backup podem ter três origens diferentes: • Empresas especializadas em oferecer serviços de recuperação de desastres • Outros locais de propriedade de sua empresa e operados pela mesma • Um acordo com uma outra empresa para compartilhar as instalações do centro de dados no caso de um desastre Cada tática tem seus pontos fortes e fracos. Por exemplo: contratar uma empresa de recuperação de desastres frequentemente lhe dá acesso a profissionais qualificados para direcionar as empresas através do processo de criação, testes e implementação de um plano de recuperação de desastres. Como você pode imaginar, estes serviços não são de graça. Usar um espaço em outra localidade de propriedade e operada pela sua empresa pode ser uma opção com custo zero, mas estocar o site de backup e manter sua prontidão ainda é uma opção cara. Desenvolver um acordo para compartilhar centros de dados com uma outra empresa pode ser bem barato, mas geralmente não é possível tocar operações a longo prazo sob estes termos, já que o proprietário do centro de dados ainda deve manter sua produção normal. Capítulo 8. Planejamento para Desastres 175 No final das contas, a escolha do site de backup é um balanço entre os custos e a necessidade de sua empresa na produção contínua. 8.3.3. Disponibilidade de Hardware e Software Seu plano de recuperação de desastres deve incluir métodos para obter o hardware e software necessários para as operações do site de backup. Um site de backup gerido profissionalmente talvez já tenha tudo o que você precisa (ou talvez você precise providenciar a obtenção e entrega de materiais especiais que o site não tenha). Por outro lado, um site de backup frio implica na identificação de uma fonte confiável para a obtenção de cada um dos itens. Frequentemente, empresas trabalham com fabricantes para criar acordos para a rápida entrega de hardware e/ou software no caso de um desastre. 8.3.4. Disponibilidade de Backups Quando um desastre é declarado, é necessário notificar o seu local de armazenamento externo por duas razões: • Para levar os últimos backups ao site de backup • Para organizar a retirada e entrega dos backups ao site de backup (como suporte aos backups normais do site de backup) Dica No caso de um desastre, os últimos backups de seu antigo centro de dados que você tiver são vitalmente importantes. Considere fazer cópias antes de mais nada, e retirar os originais novamente da empresa o quanto antes. 8.3.5. Conectividade de Rede ao Site de Backup Um centro de dados não tem muita utilidade se estiver totalmente desconectado do que resto da empresa. Dependendo do plano de recuperação de desastres e da natureza do desastre, sua comunidade de usuários pode estar localizada há quilômetros de distância do site de backup. Nestes casos, uma boa conectividade é essencial para restaurar a produção. Um outro tipo de conectividade para ter em mente é a telefônica. Você deve assegurar que há linhas telefônicas disponíveis suficientes para suportar toda a comunicação verbal com seus usuários. O que pode ter sido um simples grito por cima de uma divisória pode ser agora uma conversa telefônica de longa distância. Portanto, planeje mais conectividade telefônica do que pareça necessário numa primeira instância. 8.3.6. Funcionários do Site de Backup A questão dos funcionários do site de backup tem diversas dimensões. Um dos aspectos é determinar os funcionários necessários para rodar o centro de dados backup pelo tempo necessário. Apesar de um número pequeno de funcionários poder manter as coisas funcionando por um curto período, conforme o desastre se desenrolar, serão necessárias mais pessoas para tocar as operações sob as circunstâncias extraordinárias que permeam um desastre. 176 Capítulo 8. Planejamento para Desastres Isto inclui garantir que os funcionários tenham tempo livre suficiente para descansar e voltar para seus lares. Se as consequências do desastre foram abrangentes de modo que afetaram os lares e famílias das pessoas, é necessário alocar tempo para que elas possam lidar com suas recuperações particulares do desastre. Também é necessária acomodação próxima ao site de backup, assim como transporte para trazer as pessoas para o site de backup e levá-las de volta. Frequentemente, um plano de recuperação de desastres inclui representantes de todas as partes da comunidade de usuários da empresa. Isto depende da habilidade da sua empresa em operar com um centro de dados remoto. Se os representantes dos usuários devem trabalhar no site de backup, também é necessário prover-lhes acomodação. 8.3.7. Voltando à Normalidade Eventualmente, todos os desastres terminam. O plano de recuperação de desastres também deve abordar esta fase. O novo centro de dados deve estar equipado com todo o hardware e software necessário. Apesar desta fase não ter a mesma natureza crítica de tempo dos preparativos quando o desastre foi declarado, os sites de backup custam dinheiro todos os dias em que estão em uso. Portanto, devido às questões econômicas, devemos retornar à normalidade o mais rápido possível. Deve-se fazer os últimos backups do site de backup e enviá-los ao novo centro de dados. Após serem restaurados no novo hardware, a produção pode ser iniciada no novo centro de dados. Neste ponto, o centro de dados backup pode ser descomissionado, com a disposição de todo o hardware temporário determinada pela seção final do plano. Finalmente, deve ser feita uma revisão da eficácia do plano e integrar as alterações recomendadas pelo comitê revisor numa versão atualizada do plano. 8.4. Informações Específicas do Red Hat Enterprise Linux Há poucas informações sobre os tópicos desastre e recuperação de desastre relacionadas a um sistema operacional específico. Afinal de contas, os computadores de um centro de dados inundado estarão inoperantes, independente de rodarem o Red Hat Enterprise Linux ou outro sistema operacional. No entanto, há partes do Red Hat Enterprise Linux relacionadas a determinados aspectos da recuperação de um desastre. Estas são abordadas na próxima seção. 8.4.1. Suporte ao Software Como fabricante de software, a Red Hat oferece suporte para seus produtos, incluindo o Red Hat Enterprise Linux. Você está usando a forma mais básica de suporte agora mesmo, ao ler este manual. A documentação do Red Hat Enterprise Linux está disponível no CD de Documentação do Red Hat Enterprise Linux (que também pode ser instalado no seu sistema para acesso rápido), no formato impresso e também no site da Red Hat http://www.redhat.com/docs/. Opções de auto suporte podem ser acessadas através das diversas listas de discussão hospedadas pela Red Hat (visite o site https://listman.redhat.com/mailman/listinfo/). Estas listas trazem o conhecimento da comunidade de usuários Red Hat e, muitas delas são monitoradas por funcionários da Red Hat, que também contribuem de acordo com sua disponibilidade. Outros recursos podem ser acessados através da página principal de suporte da Red Hat: http://www.redhat.com/apps/support/. Há opções de suporte mais detalhado. Para maiores informações, consulte o site da Red Hat. Capítulo 8. Planejamento para Desastres 177 8.4.2. Tecnologias de Backup O Red Hat Enterprise Linux traz diversos programas diferentes para fazer backup e restaurar dados. Estes programas por si só não constituem uma solução completa de backup. Entretanto, eles podem ser usados como o núcleo de tal solução. Nota Como mencionado na Seção 8.2.6.1, a maioria dos computadores baseados na arquitetura PC padrão não possuem a funcionalidade necessária para inicializar a partir de uma fita de backup. Consequentemente, o Red Hat Enterprise Linux não é capaz de executar uma inicialização pela fita quando rodar em hardware deste tipo. No entanto, também é possível usar o seu CD-ROM do Red Hat Enterprise Linux como um ambiente de recuperação do sistema. Para mais informações, veja o capítulo sobre recuperação básica de sistemas no Guia de Administração de Sistemas Red Hat Enterprise Linux. 8.4.2.1. tar O utilitário tar é bem conhecido dentre os administradores de sistemas UNIX. É o método de arquivamento preferido para compartilhar partes do código fonte e arquivos entre sistemas. A implementação do tar inclusa no Red Hat Enterprise Linux é o tar do GNU, uma das implementações tar mais ricas em funcionalidades. Usar o tar para fazer backup do conteúdo de um diretório pode ser tão simples quanto invocar um comando similar a: tar cf /mnt/backup/home-backup.tar /home/ Este comando cria um arquivo chamado home-backup.tar no diretório /mnt/backup/. O arquivo contém o conteúdo do diretório /home/. O arquivo resultante será quase tão grande quanto os dados sendo copiados para backup. Dependendo do tipo de dados sendo copiados, comprimir o arquivo pode significar uma grande redução no tamanho. O arquivo pode ser comprimido adicionando apenas uma opção ao comando anterior: tar czf /mnt/backup/home-backup.tar.gz /home/ O arquivo home-backup.tar.gz resultante agora foi comprimido pelo gzip 5. Há muitas outras opções para o tar; para saber mais, leia a página man do tar(1). 8.4.2.2. cpio O utilitário cpio é outro programa tradicional do UNIX. É um programa excelente para mover dados de uma localidade a outra e, como tal, pode servir também como programa de backup. O comportamento do cpio é um pouco diferente do tar. Ao contrário do tar, o cpio lê os nomes dos arquivos que deve processar através do input padrão (standard input). Um método comum para gerar uma lista de arquivos para o cpio é usar programas como o find, cujo output é então enviado (piped) ao cpio: find /home/ | cpio -o 5. /mnt/backup/home-backup.cpio A extensão .gz é usada tradicionalmente para conotar que o arquivo foi comprimido com o gzip. Às vezes, o .tar.gz é encurtado para .tgz a fim de manter os nomes de arquivos razoavelmente curtos. 178 Capítulo 8. Planejamento para Desastres Este comando cria um arquivo cpio (contendo todos os dados de /home/) chamado home-backup.cpio e localizado no diretório /mnt/backup/. Dica Como o find tem uma variedade de testes de seleção de arquivos, é fácil criar backups sofisticados. Por exemplo: o comando seguinte faz um backup somente dos arquivos que não foram acessados no último ano: find /home/ -atime +365 | cpio -o /mnt/backup/home-backup.cpio Há muitas outras opções para o cpio (e para o find). Para aprender mais sobre elas, leia as páginas man do cpio(1) e do find(1). 8.4.2.3. dump/restore: Não Recomendado para Sistemas de Arquivo Montados! Os programas Linux dump e restore são equivalentes aos programas UNIX de mesmo nome. Sendo assim, muitos administradores de sistemas com experiência no UNIX podem pensar que o dump e o restore são boas opções para um programa de backup sob o Red Hat Enterprise Linux. No entanto, um dos métodos de uso do dump pode causar problemas. Aqui está o comentário de Linus Torvald sobre o assunto: From: Linus Torvalds To: Neil Conway Subject: Re: [PATCH] SMP race in ext2 - metadata corruption. Date: Fri, 27 Apr 2001 09:59:46 -0700 (PDT) linux-kernel At vger Dot kernel Dot org Cc: Kernel Mailing List [ linux-kernel added back as a cc ] On Fri, 27 Apr 2001, Neil Conway wrote: I’m surprised that dump is deprecated (by you at least ;-)). What to use instead for backups on machines that can’t umount disks regularly? Note that dump simply won’t work reliably at all even in 2.4.x: the buffer cache and the page cache (where all the actual data is) are not coherent. This is only going to get even worse in 2.5.x, when the directories are moved into the page cache as well. So anybody who depends on "dump" getting backups right is already playing Russian roulette with their backups. It’s not at all guaranteed to get the right results - you may end up having stale data in the buffer cache that ends up being "backed up". Dump was a stupid program in the first place. Leave it behind. I’ve always thought "tar" was a bit undesirable (updates atimes or ctimes for example). Right now, the cpio/tar/xxx solutions are definitely the best ones, and will work on multiple filesystems (another limitation of "dump"). Whatever problems they have, they are still better than the _guaranteed_(*) data corruptions of "dump". However, it may be that in the long run it would be advantageous to have a Capítulo 8. Planejamento para Desastres 179 "filesystem maintenance interface" for doing things like backups and defragmentation.. Linus (*) Dump may work fine for you a thousand times. But it _will_ fail under the right circumstances. And there is nothing you can do about it. Dado este problema, o uso do dump/restore em sistemas de arquivo montados não é recomendado. Entretanto, o dump foi originalmente desenvolvido para fazer backup de sistemas de arquivo não montados; consequentemente, em situações nas quais é possível tornar um sistema de arquivo offline com o umount, o dump continua sendo uma tecnologia viável para backup. 8.4.2.4. O Arquivador de Disco de Rede Automático Maryland Avançado (AMANDA, The Advanced Maryland Automatic Network Disk Archiver) AMANDA é uma aplicação de backup baseada no cliente/servidor produzida pela Universidade de Maryland. Por ter uma arquitetura cliente/servidor, um único servidor de backup (normalmente, um sistema bastante poderoso com bastante espaço livre nos discos rápidos e configurado com o dispositivo de backup desejado) pode fazer backup de muitos sistemas cliente, que não precisam mais do que o software cliente AMANDA. Esta tática de backup faz muito sentido, pois concentra estes recursos necessários para backups em um único sistema, ao invés de precisar de hardware adicional para cada sistema que requerer serviços de backup. O design do AMANDA também serve para centralizar a gestão dos backups, facilitando bastante a vida do administrador de sistemas. O servidor do AMANDA administra uma série de mídias de backup e alterna o uso entre elas para garantir que todos os backups sejam retidos pelo período de retenção determinado pelo administrador. Todas as mídias são pré-formatadas com dados que permitem ao AMANDA detectar se a mídia apropriada está disponível ou não. Além disso, o AMANDA pode interfacear com mídia robótica alterando unidades, possibilitando automatizar os backups completamente. O AMANDA pode usar o tar ou o dump para fazer os backups (é preferível usar o tar sob o Red Hat Enterprise Linux devido às questões do dump abordadas na Seção 8.4.2.3). Sendo assim, os backups do AMANDA não requerem o AMANDA para restaurar os arquivos — um valor agregado. Em operação, o AMANDA é normalmente agendado para rodar uma vez por dia durante a janela de backup do centro de dados. O servidor do AMANDA conecta aos sistemas cliente e os direciona a produzir tamanhos estimados dos backups a serem feitos. Uma vez disponibilizadas as estimativas, o servidor cria uma agenda, determinando automaticamente a ordem na qual os sistemas terão seus backups feitos. Após os backups iniciarem, os dados são enviados através da rede, do cliente para o servidor, onde são armazenados em um disco de espera. Uma vez completo o backup, o servidor começa a graválo pelo disco de espera na mídia de backup. Ao mesmo tempo, outros clientes estão enviando seus backups ao servidor para serem armazenados no disco de espera. Isto resulta num fluxo de dados contínuo disponível para gravação na mídia de backup. Conforme os backups são gravados na mídia de backup, são apagados do disco de espera do servidor. Uma vez completos todos os backups, o administrador de sistemas recebe um e-mail com um relatório descrevendo o status dos backups, facilitando e dinamizando a revisão. Se for necessário restaurar dados, o AMANDA contém um programa que permite ao operador identificar o sistema de arquivo, data e nome(s) do(s) arquivo(s). Após fazer isso, o AMANDA identifica a mídia de backup correta e então localiza e restaura os dados desejados. Conforme mencionado anteriormente, o design do AMANDA também possibilita restaurar dados mesmo sem a assistência do AMANDA, apesar da identificação da mídia correta ocorrer mais lentamente e manualmente. 180 Capítulo 8. Planejamento para Desastres Esta seção cobriu apenas os conceitos mais básicos do AMANDA. Para pesquisar mais sobre o AMANDA, comece pela página man amanda(8). 8.5. Recursos Adicionais Esta seção inclui diversos recursos para aprender mais sobre a recuperação de desastres e o assunto específico ao Red Hat Enterprise Linux abordado neste capítulo. 8.5.1. Documentação Instalada Os recursos seguintes são instalados no decorrer de uma instalação típica do Red Hat Enterprise Linux e podem ajudá-lo a saber mais sobre o assunto aqui abordado. • Página man tar(1) — Aprenda a arquivar dados. • Página man dump(8) — Aprenda a fazer dump do conteúdo do sistema de arquivo. • Página man restore(8) — Aprenda a recuperar o conteúdo do sistema de arquivo salvo pelo dump • Página man cpio(1) — Aprenda a copiar arquivos para e de arquivamentos. • Página man find(1) — Aprenda a procurar arquivos. • Página man amanda(8) — Aprenda mais sobre os comandos que fazem parte do sistema de backup AMANDA. • Arquivos do diretório /usr/share/doc/amanda-server- version / — Aprenda mais sobre o AMANDA revendo este diversos documentos e arquivos de exemplo. 8.5.2. Sites Úteis • http://www.redhat.com/apps/support/ — A página de suporte da Red Hat oferece fácil acesso aos diversos recursos relacionados ao suporte do Red Hat Enterprise Linux. • http://www.disasterplan.com/ — Um site interessante com links para vários outros sites relacionados à recuperação de desastres. Inclui uma amostra de plano de recuperação de desastres. • http://web.mit.edu/security/www/isorecov.htm — O site do Massachusetts Institute of Technology Information Systems Business Continuity Planning contém diversos links informativos. • http://www.linux-backup.net/ — Uma visão geral interessante de diversas questões relativas a backups. • http://www.linux-mag.com/1999-07/guru_01.html — Um artigo interessante da Linux Magazine sobre os aspectos mais técnicos da produção de backups sob o Linux. • http://www.amanda.org/ — O site do AMANDA (The Advanced Maryland Automatic Network Disk Archiver). Contém indicações sobre as diversas listas de discussão relacionadas ao AMANDA e outros recursos online. 8.5.3. Livros Relacionados Os livros a seguir abordam diversas questões relativas à recuperação de desastres e são bons recursos para os administradores de sistemas Red Hat Enterprise Linux. Capítulo 8. Planejamento para Desastres 181 • O Guia de Administração de Sistemas Red Hat Enterprise Linux; Red Hat, Inc. — Inclui um capítulo sobre recuperação de sistemas, que pode ser útil nas restaurações a partir do zero. • Unix Backup & Recovery de W. Curtis Preston; O’Reilly & Associates — Apesar de não ser escrito 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 Símbolos /etc/cups/, 144 /etc/printcap, 144 A abuso de recursos, 127 abuso, recurso, 127 Administrador de Pacotes RPM (Ver RPM) administrando impressoras, 137 administração de sistemas filosofia da, 1 automação, 1 comunicação, 3 documentação, 2 engenharia social, riscos da, 7 negócio, 6 ocorrências inesperadas, 8 planejamento, 8 recursos, 5 segurança, 6 usuários, 6 administração de volume lógico (Ver LVM) armazenamento acessível via rede, 75, 101 NFS, 101 SMB, 101 adicionando, 87, 102 /etc/fstab, atualizando, 104 agendamento de backup, alterando, 91 configuração, atualizando, 91 drive de disco ATA, 88 drive de disco SCSI, 89 formatando, 91, 104 hardware, instalando, 88 particionando, 90, 102 administração do, 59, 82 crescimento, normal, 85 monitoramento do espaço livre, 83 questões de usuário, 83 uso da aplicação, 84 uso excessivo do, 83 baseado no RAID (Ver RAID) dispositivos de armazenamento em massa braços de acesso, 60 cabeça, 62 cabeças (heads), 60 cabeças acessando, 68 cabeças gravando, 68 cargas I/O, acessos, 69 cargas I/O, desempenho, 69 cargas I/O, gravações, 69 cilindro, 62 conceitos de endereçamento, 61 desempenho do, 67 geometria, problemas com, 62 interface IDE, 64 interface SCSI, 65 interfaces do, 63 interfaces padrão, 64 interfaces, histórico, 63 interfaces, padrão, 64 latência rotacional, 68 latência, rotacional, 68 leitores versus gravadores, 69 limitações elétricas do, 67 limitações mecânicas do, 67 localidade I/O, 70 mapeamento baseado na geometria, 61 mapeamento baseado no bloco, 63 mapeamento, baseado na geometria, 61 mapeamento, baseado no bloco, 63 movimento do braço de acesso, 68 movimento, braço de acesso, 68 pratos de disco, 59 pratos, disco, 59 processamento de comandos, 68 processamento, comandos, 68 setor, 62 visão geral do, 59 empregando, 70 monitoramento da, 17 padrões de acesso, 45 partição atributos das, 70 campo do tipo, 71 extendidas, 71 geometria da, 71 lógicas, 71 primárias, 71 tipo da, 71 visão geral do, 70 questões relativas a arquivos, 86 acesso a arquivos, 86 compartilhamento de arquivos, 87 quotas de disco, 85 (Ver quotas de disco) removendo, 92, 105 /etc/fstab, removendo do, 105 apagando conteúdo, 93, 106 comando umount, uso do, 105 dados, removendo, 92 sistema de arquivo, 72, 96 184 arquivo /etc/mtab, 99 arquivo /proc/mounts, 100 baseado em arquivo, 72 comando df, usando, 100 contabilidade do espaço, 73 contabilidade, espaço, 73 controle de acesso, 73 diretório hierárquico, 72 diretórios, 72 estrutura, diretório, 74 EXT2, 96 EXT3, 97 habilitando acesso ao, 74 hora de acesso, 73 hora de criação, 73 hora de modificação, 73 ISO 9660, 97 montando, 98 montando com o arquivo /etc/fstab, 101 MSDOS, 97 ponto de montagem, 98 VFAT, 97 visualização da montagem, 99 tecnologias, 45 armazenamento de backup, 49 armazenamento off-line, 49 cache L1, 47 cache L2, 47 disco rígido, 48 drive de disco, 48 memória cache, 46 memória principal, 47 RAM, 47 Registradores de CPU, 46 tecnologias, avançadas, 75 arquivo /etc/fstab atualizando, 104 montando sistemas de arquivo com, 101 arquivo /etc/group conta de usuário, função no, 132 grupo, função no, 132 arquivo /etc/gshadow conta de usuário, função no, 132 grupo, função no, 132 arquivo /etc/mtab, 99 arquivo /etc/passwd conta de usuário, função no, 130 grupo, função no, 130 arquivo /etc/shadow conta de usuário, função no, 130 grupo, função no, 130 arquivo /proc/mdstat, 112 arquivo /proc/mounts, 100 ative sua assinatura, iv automação, 8 visão geral da, 1 B backups agendamento, alterando, 91 armazenamento de, 171 comprando software, 167 criando software, 167 introdução a, 165 questões de restauração, 171 restaurações do zero, 172 testando a restauração, 172 questões relaciondas aos dados, 166 software de backup AMANDA, 179 tecnologias usadas, 177 cpio, 177 dump, 178 tar, 177 tipos de, 168 backups completos, 168 backups diferenciais, 169 backups incrementais, 168 tipos de mídia, 169 disco, 169 fita, 169 rede, 170 C CD-ROM sistema de arquivo (Ver Sistema de arquivo ISO 9660) comando df, 100 comando free, 19, 54 comando gnome-system-monitor, 20 comando iostat, 23, 38 comando mpstat, 23 comando raidhotadd, uso do, 112 comando sa1, 23 comando sa2, 23 comando sadc, 23 comando sar, 23, 25, 39, 41, 55 relatórios, acessando, 25 comando top, 18, 19, 40 comando vmstat, 18, 21, 38, 41, 54 comando watch, 19 comunicação informações específicas ao Red Hat Enterprise Linux, 9 necessidade de, 3 configuração da impressora, 143 aplicação baseada em texto, 143 CUPS, 143 conjunto de trabalho, 52 conta 185 (Ver conta de usuário) conta de usuário acesso a dados compartilhados, 125 administração da, 115, 115, 123 alterações de função, 124 desligamentos, 123 novas contratações, 123 arquivos que controlam, 129 /etc/group, 132 /etc/gshadow, 132 /etc/passwd, 130 /etc/shadow, 130 controle de acesso, 122 diretório home centralizado, 127 ferramentas de administração, 133 o comando chage, 133 o comando chfn, 133 o comando chpasswd, 133 o comando passwd, 133 o comando useradd, 133 o comando userdel, 133 o comando usermod, 133 GID, 129 GIDs do sistema, 129 nome de usuário, 115 alterações do, 117 colisões na nomenclatura, 116 convenção de nomenclatura, 115 permissões relacionadas a, 127 execução (execute), 127 gravação (write), 127 leitura (read), 127 setgid (id do grupo), 127 setuid (id do usuário), 127 sticky bit, 127 recursos, administração dos, 125 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 UID, 129 UIDs do sistema, 129 controle de mudanças, 163 convenções documentos, ii CUPS, 143 D dados acesso compartilhados aos, 125, 126 questões de propriedade (ownership) global, 127 devlabel, 96 diretório home centralizado, 127 diretório home centralizado, 127 discos rígidos, 48 dispositivo acesso ao dispositivo inteiro, 95 alternativas aos nomes dos dispositivos, 95 convenção de nomenclatura, 93 devlabel, nomeando com o, 96 etiquetas do sistema de arquivo, 95 etiquetas, sistema de arquivo, 95 nomeando com o devlabel, 96 nomes de dispositivos, alternativas para, 95 nomes dos arquivos, 94 partição, 94 tipo, 94 unidade, 94 documentação informações específicas ao Red Hat Enterprise Linux, 9 documentação, necessidade de, 2 drive de disco ATA adicionando, 88 drive de disco SCSI adicionando, 89 drives de disco, 48 E engenharia social, riscos da, 7 engenharia, social, 7 espaço de endereço virtual, 51 espaço em disco (Ver armazenamento) 186 F H falhas de página, 51 Ferramenta de Configuração da Impressora (Ver configuração da impressora) ferramentas contas de usuário, administração (Ver conta de usuário, ferramentas de administração) grupos, administração (Ver grupo, ferramentas de administração) monitoramento de recursos, 18 free, 19 iostat, 23 Monitor GNOME do Sistema, 20 mpstat, 23 OProfile, 26 sa1, 23 sa2, 23 sadc, 23 sar, 23, 25 Sysstat, 23 top, 19 vmstat, 21 filosofia da administração de sistemas, 1 hardware contratos de serviço, 149 disponibilidade das peças, 152 hardware coberto, 152 horas de cobertura, 149 orçamento para, 152 serviço de depósito, 150 serviço drop-off, 150 serviço walk-in, 150 tempo de resposta, 150 técnico interno, 151 falhas de, 147 habilidades necessárias para o reparo, 147 reservas estoque, quantidades, 148 estoque, seleção do, 148 guardar, 147 trocando hardware, 149 G GID, 129 grupo acesso a dados compartilhados usando, 126 administração da, 115 arquivos que controlam, 129 /etc/group, 132 /etc/gshadow, 132 /etc/passwd, 130 /etc/shadow, 130 estrutura, determinando, 126 ferramentas de administração, 133 o comando gpasswd, 133 o comando groupadd, 133 o comando groupdel, 133 o comando groupmod, 133 o comando grpck, 133 GID, 129 GIDs do sistema, 129 permissões relacionadas a, 127 execução (execute), 127 gravação (write), 127 leitura (read), 127 setgid (id do grupo), 127 setuid (id do usuário), 127 sticky bit, 127 UID, 129 UIDs do sistema, 129 I ID do grupo (Ver GID) ID do usuário (Ver UID) impressoras administrando, 137 considerações, 137 cor, 140 CMYK, 140 jato de tinta, 140 laser, 141 duplex, 137 em rede, 143 linguagens (Ver linguagens de descrição da página (PDL)) local, 143 recursos adicionais, 145 tipos, 137 cera térmica, 141 de linha, 138 dye-sublimation, 141 impacto, 138 jato de tinta, 140 laser, 140 laser coloridas, 141 margarida (daisy-wheel), 138 matricial (dot-matrix), 138 tinta sólida, 141 impressoras de impacto, 138 consumíveis, 139 de linha, 138 187 margarida (daisy-wheel), 138 matricial (dot-matrix), 138 impressoras de linha (Ver impressoras de impacto) impressoras laser coloridas, 141 impressoras margarida (Ver impressoras de impacto) impressoras matriciais (Ver impressoras de impacto) impressoras à jato de tinta, 140 consumíveis, 140 impressoras à laser, 140 consumíveis, 141 cor, 141 inesperado, preparação para o, 8 informações específicas ao Red Hat Enterprise Linux automação, 8 comunicação, 9 documentação, 9 janela de comandos bash, 8 PAM, 10 perl, 8 RPM, 10 scripts da janela de comandos, 8 segurança, 10 sistemas de detecção de intrusão, 10 informações específicas do Red Hat Enterprise Linux ferramentas de monitoramento de recursos iostat, 38 sar, 39, 41 top, 40 vmstat, 38, 41 ferramentas de monitoramento dos recursos, 18 free, 18, 54 OProfile, 18 sar, 55 Sysstat, 18 top, 18 vmstat, 18, 54 monitoramento de recursos largura de banda, 38 memória, 54 poder da CPU, 38 recuperação de desastres, 176 suporte ao software, 176 suporte, software, 176 tecnologias de backup AMANDA, 179 cpio, 177 dump, 178 tar, 177 visão geral das, 177 interface IDE visão geral do, 64 interface SCSI visão geral do, 65 J janela de comandos bash, automação e, 8 L linguagens de descrição da página (PDL), 142 Interpress, 142 PCL, 142 PostScript, 142 lpd, 145 LVM agrupamento de armazenamento, 81 contrastada com o RAID, 82 migração de dados, 82 migração, dados, 82 redimensionamento do volume lógico, 81 redimensionamento, volume lógico, 81 visão geral do, 81 M memória memória virtual, 49 backing store, 50 conjunto de trabalho, 52 desempenho da, 53 desempenho, melhor caso, 53 desempenho, pior caso, 53 espaço de endereço virtual, 51 falhas de página, 51 swapping, 52 visão geral da, 50 monitoramento da, 17 utilização dos recursos de, 45 memória cache, 46 memória física (Ver memória) memória virtual (Ver memória) monitoramento desempenho do sistema, 14 recursos, 13 monitoramento de recursos, 13 armazenamento, 17 capacidade do sistema, 14 conceitos básicos, 13 desempenho do sistema, 14 Energia da CPU, 15 ferramentas free, 19 iostat, 23 Monitor GNOME do Sistema, 20 mpstat, 23 188 OProfile, 26 sa1, 23 sa2, 23 sadc, 23 sar, 23, 25 Sysstat, 23 top, 19 vmstat, 21 ferramentas usadas, 18 largura de banda, 16 memória, 17 o que monitorar, 15 planejamento da capacidade, 14 monitoramento do desempenho do sistema, 14 monitorando estatísticas relacionada ao armazenamento, 17 relacionada à memória, 17 relacionado à largura de banda, 16 relativa à CPU, 15 seleção de, 15 montando sistemas de arquivo (Ver armazenamento, sistema de arquivo, montando) multiprocessamento simétrico, 37 Módulos de Autenticação Plugáveis (Pluggable Authentication Modules) (Ver PAM) N negócio, conhecimento do, 6 NFS, 101 nome de usuário, 115 alterando, 117 colisões entre, 116 convenção de nomenclatura, 115 nomes dos arquivos dispositivo, 94 O o comando chage, 133 o comando chfn, 133 o comando chgrp, 134 o comando chmod, 134 o comando chown, 134 o comando chpasswd, 133 o comando gpasswd, 133 o comando groupadd, 133 o comando groupdel, 133 o comando groupmod, 133 o comando grpck, 133 o comando passwd, 133 o comando useradd, 133 o comando userdel, 133 o comando usermod, 133 OProfile, 18, 26 P PAM, 10 partição, 94 atributos das, 70 campo do tipo, 71 geometria, 71 tipo, 71 criação de, 90, 102 extendidas, 71 lógicas, 71 primárias, 71 visão geral do, 70 perl, automação e, 8 permissão de execução (execute), 127 permissão de gravação (write), 127 permissão de leitura (read), 127 permissão setgid, 10 permissão setgid (id do grupo), 127 permissão setuid, 10 permissão setuid (id do usuário), 127 permissão sticky bit, 127 permissões, 127 ferramentas de administração o comando chgrp, 134 o comando chmod, 134 o comando chown, 134 planejamento da capacidade, 14 planejamento para desastres, 147 energia, backup, 158 gerador, 158, 159 quedas, extensas, 160 UPS, 158 tipos de desastres, 147 aplicações usadas impropriamente, 161 aquecimento, 160 ar condicionado, 160 eletricidade, qualidade da, 157 eletricidade, segurança da, 156 elétrico, 156 erros de má configuração, 163 erros de operadores, 162 erros de procedimento, 162 erros de usuários, 161 erros do administrador de sistemas, 163 erros do técnico de serviço, 165 erros durante procedimentos, 162 erros humanos, 161 erros relacionados à manutenção, 164 falhas de hardware, 147 falhas de software, 153 falhas nas aplicações, 153 189 falhas no ambiente, 155 falhas no sistema operacional, 153 fatores climáticos, 161 HVAC, 160 integridade da construção, 155 pendências do sistema operacional, 153 quedas do sistema operacional, 153 reparos inapropriados, 165 ventilação, 160 planejamento, importância do, 8 poder da CPU (Ver recursos, sistema, poder de processamento) poder de processamento, recursos relacionados ao (Ver recursos, sistema, poder de processamento) pontos de montagem (Ver armazenamento, sistema de arquivo, ponto de montagem) printconf (Ver configuração da impressora) printtool (Ver configuração da impressora) Q quota, disco (Ver quotas de disco) quotas de disco administração do, 109 ativando, 108 introdução ao, 106 visão geral do, 107 específico ao grupo, 107 específico ao sistema de arquivo, 107 específico ao usuário, 107 limites rígidos, 108 limites suaves, 108 período de carência, 108 registro do uso do bloco, 107 registro do uso do inode, 108 R RAID conjuntos administração do, 112 comando raidhotadd, uso do, 112 recriando, 112 status, verificando, 112 conjuntos, criando, 110 após a instalação, 111 na hora da instalação, 110 contrastada com o LVM, 82 criando conjuntos (Ver RAID, conjuntos, criando) implementações do, 80 RAID de hardware, 80 RAID de software, 81 introdução ao, 76 níveis do, 77 RAID 0, 77 RAID 0, desvantagens do, 77 RAID 0, vantagens do, 77 RAID 1, 78 RAID 1, desvantagens do, 78 RAID 1, vantagens do, 78 RAID 5, 78 RAID 5, desvantagens do, 79 RAID 5, vantagens do, 79 RAID embutido, 79 RAID embutido, 79 visão geral do, 76 RAM, 47 recuperação de desastres backups, disponibilidade de, 175 disponibilidade de hardware, 175 disponibilidade de software, 175 fim do, 176 introdução a, 172 local de backup, 174 conectividade de rede ao, 175 funcionários do, 175 planejar, criar, testar, implementar, 173 recursos do sistema (Ver recursos, sistema) recursos relacionados à largura de banda (Ver recursos, sistema, largura de banda) recursos, importância dos, 5 recursos, sistema armazenamento (Ver armazenamento) energia de processamento monitoramento da, 15 largura de banda, 31 a função dos canais na, 31 canais, exemplos de, 32 capacidade, aumento, 33 carga, distribuição, 33 carga, redução, 33 centrais de dados (datapaths), exemplos de, 32 centrais de dados (datapaths), função no, 32 monitoramento da, 16 problemas relacionados a, 32 soluções de problemas com a, 33 visão geral da, 31 memória (Ver memória) poder de processamento, 31 aplicações, eliminar, 36 atualizando, 37 capacidade, aumento, 37 carga, redução, 36 190 consumidores do, 34 CPU, atualizando, 37 falta da, suprindo, 35 fatos relacionados ao, 34 multiprocessamento simétrico, 37 o uso da aplicação do, 35 o uso do sistema operacional do, 35 SMP, 37 sobrecarga das aplicações, reduzir, 36 sobrecarga do S/O, reduzir, 36 visão geral da, 34 registre sua assinatura, iv registro da assinatura, iv repetição (Ver repetição) RPM, 10 S scripts da janela de comandos, 8 segurança importância dos, 6 informações específicas ao Red Hat Enterprise Linux, 10 senha, 118 brevidade da, 119 conjunto de caracteres grande usado na, 121 escritas, 121 expiração, 122 fortes, 121 fraca, 119 informações pessoais usadas na, 120 mais longas, 121 memorável, 122 palavras usadas na, 120 pequeno conjunto de caracteres usado na, 119 truques com palavras usados na, 120 usada repetidamente, 121 sistema de arquivo etiquetas, 95 Sistema de arquivo EXT2, 96 Sistema de arquivo ext3, 97 Sistema de arquivo ISO 9660, 97 Sistema de arquivo MSDOS, 97 Sistema de arquivo VFAT, 97 sistemas de detecção de intrusão, 10 SMB, 101 SMP, 37 software suporte a auto-suporte, 154 documentação, 154 suporte na empresa (on-site), 155 suporte telefônico, 155 suporte via e-mail, 154 Suporte via Internet, 154 visão geral, 154 swapping, 52 Sysstat, 18, 23 system-config-printer (Ver configuração da impressora) U UID, 129 usuários importância dos, 6 Considerações finais Os manuais são escritos no formato DocBook SGML versão 4.1. Os formatos HTML e PDF são produzidos 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; Mantenedor 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 Contribuinte do Guia de Administração de Sistemas Red Hat Enterprise Linux Paul Kennedy — Autor Principal/Mantenedor do Guia do Administrador do Red Hat GFS; Autor Contribuinte do Configurando e Administrando um Cluster do Red Hat Cluster Suite Mark Johnson — Autor Principal/Mantenedor do Guia de Administração e Configuração do Desktop Red Hat Enterprise Linux Melissa Goldin — Autora Principal/Mantenedora do Guia Passo a Passo do Red Hat Enterprise Linux A Equipe de Internacionalização da Red Hat é composta pelas seguintes pessoas: Amanpreet Singh Alam — traduções para Punjabi Jean-Paul Aubry — traduções para o Francês David Barzilay — traduções para o Português Brasileiro Runa Bhattacharjee — traduções para Bengali Chester Cheng — traduções para o Chinês Tradicional Verena Fuehrer — traduções para o Alemão Kiyoto Hashida — traduções para o Japonês N. Jayaradha — traduções para Tamil Michelle Jiyeen Kim — traduções para o Coreano Yelitza Louze — traduções para o Espanhol Noriko Mizumoto — traduções para o Japonês Ankitkumar Rameshchandra Patel — traduções para Gujarati Rajesh Ranjan — traduções para Hindi 192 Nadine Richter — traduções para o Alemão Audrey Simons — traduções para o Francês Francesco Valente — traduções para o Italiano Sarah Wang — traduções para o Chinês Simplificado Ben Hung-Pin Wu — traduções para o Chinês Tradicional