quinta-feira, 5 de abril de 2012

LVM2 em servidores: obrigatório!



Particionar um disco, formatar uma partição e acessar seu sistema de arquivos é a forma mais rápida de utilizar o armazenamento em qualquer computador, seja ele um laptop, desktop ou servidor. No entanto, para qualquer tarefa que envolva o deslocamento desse sistema de arquivos ou dessa partição, será obrigatório parar o disco rígido e interromper todos os serviços que dependam dele. Para evitar isso existe o LVM2, e eu proponho fortemente que você o use sempre.

Já faz vários anos desde que o LVM2 começou a ser usado no Linux. Desenvolvido pela empresa britânica Sistina Software — a mesma que desenvolveu o sistema de arquivos para clusters GFS e depois foi adquirida pelaRed Hat— o LVM foi integrado ao kernel Linux desde o princípio. No kernel 2.4, ele foi implementado em sua encarnação LVM1. O LVM1 residia inteiramente no kernel e dependia de alguns programas de espaço de usuário para o gerenciamento.

O kernel 2.6 recebeu a excelente adição do device mapper, um subsistema capaz de abstrair trechos de qualquer dispositivo de armazenamento e representá-los em dispositivos virtuais (geralmente localizados sob /dev/mapper/). O LVM2, nova implementação que surgiu no espaço de usuário, emprega unicamente o device mapper para criar, gerenciar e apagar volumes LVM.

O mesmo device mapper é usado para implementar o recurso de multipath de dispositivos de armazenamento em sistemas Linux, o que confirma sua versatilidade.

As ferramentas do LVM2, portanto, funcionam unicamente como interface para interagirmos com o subsistema device mapper. Outra forma de interagir com o device mapper é por meio do comando   [dmsetup http://docs.redhat.com/docs/pt-BR/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/dmsetup.html] , mas isto requer uma maior intimidade com essa ferramenta e vai muito além do uso do LVM2.

Resistência
Mesmo com suas diversas vantagens e facilidades de gerenciamento, no entanto, o LVM2 ainda encontra resistência entre alguns administradores. "Aumenta a complexidade", já ouvi alguns dizerem, ou "diminui o desempenho do disco". Eu mesmo já tive "medo do LVM2" durante algum tempo, até me familiarizar melhor com ele.

Segundo medições abrangentes, a perda de desempenho causada pelo emprego do LVM2, em comparação com a escrita direta no disco rígido, é de 10%. No entanto, medições mais recentes apontam para um ganho de desempenho ao usar LVM2 em sistemas Fedora. Segundo os autores dos benchmarks, esta diferença a favor do LVM2 deve ter sua causa na inativação das write barriers pelo LVM2nessa distribuição — algo que compromete potencialmente a confiabilidade dos dados armazenados nesses volumes.

Independentemente da velocidade de leitura ou gravação, algumas tarefas com LVM2 se tornam tão mais rápidas e fáceis, com frequentes vantagens operacionais, que o saldo é visivelmente positivo.
Vejamos alguns exemplos de casos em que o uso do LVM2 cai como uma luva.

Cenário 1: Migração de dispositivo
Digamos que você precise migrar os dados armazenados no seu servidor de um disco para outro. Para dar nomes, você deseja transferir tudo de sda5 para sdb2, por exemplo. E a aplicação afetada por isso é o Apache, que usa esse sistema de arquivos (um ext4) para abrigar seu document root.
Sem LVM2, você precisará parar a aplicação (o Apache) que utiliza esses dados, formatar o novo sistema de arquivos ( sdb2 ) transferir os dados do sistema de arquivos original ( sda5 ) para o  sdb2 (via  rsync ,  dd ou qualquer outro utilitário que você desejar), desmontar o sistema de arquivos  /dev/sda5  onde eles estão armazenados, acrescentar ao /etc/fstab  o registro do novo sistema de arquivos e retirar dele o registro do antigo.

Com LVM2, basta você formatar sdb2  como volume físico ( pvcreate /dev/sdb2 ), adicioná-lo ao grupo de volumes já existente ( vgextend nome_do_vg /dev/sdb2 ) e migrar os extents de  sda5  para  sdb2  ( pvmove /dev/sda5 /dev/sdb2 ). Seu Apache não precisa sair do ar — ele nem sequer vai perceber que os dados estão "em trânsito" de um disco para outro. Ao final do processo, basta retirar o disco antigo do grupo de volumes ( vgreduce nome_do_vg /dev/sda5 ). Nada de alterar o fstab, parar aplicação, desmontar sistema de arquivos etc. Muito mais simples.

Cenário 2: Crescimento de sistema de arquivos em disco com espaço disponível
Digamos que seu servidor de e-mail precise de mais espaço para armazenar as caixas de mensagem. Como o número de mensagens armazenadas sempre tende a crescer indefinidamente, servidores de e-mail são uma vítima comum deste tipo de problema.

Sem LVM2, você precisará desmontar o sistema de arquivos que abriga os e-mails, editar a tabela de partições do disco rígido onde ele reside (um risco sempre muito grande), remontar o sistema de arquivos e estendê-lo ( resize2fs , no caso do ext2/3/4).

Com LVM2, você talvez ainda tenha espaço no seu VG (grupo de volumes) para aumentar o LV (volume lógico) que abriga os e-mails. Se esse for o caso, basta estender o LV ( lvextend ) e depois estender o sistema de arquivos residente nele ( resize2fs ). Nada de parar o servidor de e-mails, nada de manipular a tabela de partições, nada de desmontar sistemas de arquivos. Tudo é feito sem parar o serviço.

Ainda com LVM2, se o VG que abriga seu LV estiver esgotado, você pode simplesmente usar outro PV (do mesmo disco ou de outro) para estender esse VG ( vgextend ) e em seguida estender o LV ( lvextend ) e seu sistema de arquivos ( resize2fs ). Novamente, nada de parar o serviço, desmontar o sistema de arquivos ou redimensionar partições. Talvez você ainda precise editar a tabela de partições do disco caso precise criar uma nova partição para agir como PV (volume físico) ou alterar o tipo de uma partição já existente (para 8e, o tipo Linux LVM2).

Cenário 3: Backup de um serviço com dados muito dinâmicos
Imagine que o seu servidor de e-mail tenha tráfego intenso: centenas de mensagens por minuto. Você precisa fazer backup das mensagens armazenadas no servidor, mas é muito problemático efetuar isso com o serviço em execução, já que as mensagens em constante alteração se tornam um "alvo móvel".

Sem LVM2, você teria que interromper o recebimento de mensagens — ou, se preferir, parar o servidor de e-mail completamente — e realizar o backup. Em seguida, você restauraria o funcionamento do servidor e as mensagens voltariam a circular normalmente.

Com LVM2, adivinhe: nada de parar o servidor de e-mail nem de interromper o recebimento das mensagens. Bastaria você criar um snapshot do LV que abriga as mensagens, realizar o backup apontando a origem como o snapshot (que é estático) e, ao final, destruir o snapshot sem cerimônia. Mais uma vez, o serviço permaneceu no ar sem sequer perceber que algo estava sendo feito com suas mensagens.
Adoção

Sem surpresa nenhuma, volumes LVM2 já são usados por padrão em várias distribuições GNU/Linux. No Fedora, por exemplo, o esquema automático de particionamento durante a instalação já põe até mesmo o sistema de arquivos raiz sobre um volume lógico LVM2.

Conclusão
O LVM2 oferece vantagens significativas no gerenciamento de storage. Desde o planejamento inicial dos volumes — é possível criar e redimensionar volumes a qualquer momento — até todos os tipos de manipulação que se desejar, o LVM2 é um ótimo recurso para servidores e até para alguns desktops e laptops.

 Artigo de Pablo Hess - phess@redhat.com, gentilmente cedido para nosso blog.

quarta-feira, 4 de abril de 2012

Frase do Dia

"Você pode descobrir mais sobre uma pessoa em uma hora de brincadeira,
 do que em um ano de conversa"
Platão

Respostas do Exercício 4 - Shell - Particularidades e Configurações


Se você ainda não fez o Exercício, acesse ele neste link e faça antes de ver as respostas:

Toda a teoria necessária para a realização deste exercício encontra-se no link
abaixo:

Você pode encontrar todos os resumos de aula no link abaixo:


1 - Quando o usuário root logar, deverá aparecer uma vaquinha (programa cowsay) dando as boas vindas junto com a hora e data.

Resposta:
Primeiro vamos instalar a simpatica vaquinha
# apt-get instsall cowsay
ou
# yum install cowsay

Faça um teste:
# cowsay "Eu sei falar!"

Caso não funcione, tente assim:
# /usg/games/cowsay "Eu sei falar!"

Para o root receber as boas vidas toda vez que logar, coloque a mensagem no /root.bashrc

# vi /root/.bashrc
Ao final do arquivo, insira:

# A variável HORAS irá armazenar a hora a Variável Minuto o minuto atual
HORAS=`date +%H`
MINUTOS=`date +%M`
DIA=`date +%d`
MES=`date +%B`
ANO=`date +%Y`

/usr/games/cowsay "Olá $LOGNAME. $DIA, de $MES de $ANO. São $HORAS horas e $MINUTOS Minutos"

Salve o arquivo e teste com o comando:

# source /root/.bashrc

2 - Para fazer o registro do logon
# vi /root/.bashrc

echo "O Usuário $LOGNAME fez logon: `date`" >> /etc/cartaodeponto.log

Salve o arquivo e teste com o comando:

# source /root/.bashrc

Depois confira com cat /etc/cartaodeponto.log se a data e hora foi gerado.

Para fazer o registro do logout
# vi /root/bash_logout

Salve o arquivo e teste com o comando:

# source /root/.bashrc

echo "O Usuário $LOGNAME fez logoff: `date`" >> /etc/cartaodeponto.log

Salve o arquivo e teste com o comando:

# source /root/.bashrc

Depois confira com cat /etc/cartaodeponto.log se a data e hora foi gerado.


3 - Para fazer o registro de que o servidor foi ligado, vamos editar o arquivo /etc/rc.local ou /etc/bash.bashrc (No Debian) ou ainda /etc/bashrc (No Redhat, Fedora)

# vi /etc/bash.bashrc

Insira esta linha:

echo "O Servidor foi ligado as `date +%T` hs do dia `date +%D`" >> /etc/servidor.log

Salve o arquivo e teste com o comando:

# source /etc/bash.bashrc

Depois confira com cat /etc/servidor.log se a data e hora foi gerado.

Ao final de tudo, reinicie a máquina e faça todos os testes sempre checando com os comandos

# cat /etc/cartaodeponto.log
# cat /etc/servidor.log

Exercício da Aula 4 - Shell


Exercício da Aula 4 - Shell

Toda a teoria necessária para a realização deste exercício encontra-se no link abaixo:
http://dailson.blogspot.com.br/2012/04/aula-4-shell-particularidades-e.html

Você pode encontrar todos os resumos de aula no link abaixo:
http://www.dailson.com.br/2009/05/indice-mini-tutoriais-usados-em-aula.html

Dica para este exercício: 
Exemplos de Personalização:
echo "São `date +%H` horas e `date +%M` minutos"
echo "Recife, `date +%d`, de `date +%B` de `date +%Y`"

1 - Quando o usuário root logar, deverá aparecer uma vaquinha (programa cowsay) dando as boas vindas junto com a hora e data.

2 - Crie um log de registros de entradas e saídas do usuário root da seguinte forma:
O usuário root fez logon  às 10:00hs do dia 22/03/2012
O usuário root fez logoff às 10:00hs do dia 22/03/2012
Este log deve ser gravado no arquivo /etc/cartaodeponto.log

3 - Faça um log no arquivo /etc/servidor.log registrando todas as vezes que o servidor é ligado, usando o seguinte modelo:

O Servidor foi ligado as 10:00hs do dia 22/03/2012

Obs: Testar tudo sem ter que reiniciar a máquina e nem logar

Aula 4 - Shell - Particularidades e Configurações


Segue o resumo de comandos e conceitos vistos em Sala de Aula.
Este é um material de apoio aos meus alunos que tem todo embasamento durante as aulas presenciais.

O Exercício de fixação desta aula, pode ser acessado no seguinte link:
http://dailson.blogspot.com.br/2012/04/exercicio-da-aula-4-shell.html

Existem diversos arquivos no Linux que fazem o controle de algumas funções pertinentes ao Shell e a interatividade com o usuário.

Citaremos alguns deles, a função e a localização deles.

Para visualizar estes arquivos, use editores como o vi, mcedit ou nano.

1 - Arquivos de Mensagens:

Mensagem da tela de login
/etc/issue

Mensagem quando o usuário loga pela rede como por exemplo via SSH
/etc/issue.net

Exibe uma mensagem quando o usuário loga:
/etc/motd
Obs: motd quer dizer - Message of Today (Mensagem do dia)

2 - Arquivos do Diretório do Usuário

Quando o usuário faz logon, os seguintes arquivos são executados:

.profile ou .bash_profile --> Perfil do usuário (variáveis...)
.bashrc --> bash RC - run commands

Quando o usuário faz logout o seguinte arquivo é executado:
.bash_logout

Guarda o histórico de comandos executados pelo usuário
.bash_history

3 - Na inicialização da Máquina.

Quando a máquina é ligada, os seguintes arquivos são executados:

/etc/profile -> Usado para carregar perfil, Path entre outros

/etc/bash.bashrc -> Usado para executar comandos, preparar alias, autocompletar

/etc/rc.local -> Usado para iniciar comandos.

/etc/environment --> Usado para carregar o PATH e também o idioma do shell
Ex: 
 LANG=pt_BR
 LC_ALL=pt_BR
 LC_MESSAGES=pt_BR

4º Outros Arquivos
/etc/bash_completion - Ativar o autocomplet­ar comandos.

/etc/nologin --> Se criado, impede que qualquer usuário logue no sistema.

NO Debian:
/etc/init.d/bootmisc.sh --> Script de inicialização. Neste arquivo você pode colocar serviços para ser iniciados.

Resumindo...

~/.bashrc - Executa comandos, alias, autocompletar ... Mas só é executado quando o usuário loga. A Vantagem de usar o .bashrc ao invés do .bash_bashrc é porque o .bashrc é executado mesmo na interface gráfica ao abrir um terminal.

~/.profile - Carrega ítens relativo ao perfil. Mas só é executado quando o usuário loga.

/etc/profile  - Carrega ítens relativo ao perfil. É executado quando a máquina é ligada.

/etc/bash.bashrc - Executa comandos, alias, autocompletar ... É executado quando a máquina é ligada.

/etc/rc.local -. Executa comandos. É executado quando a máquina é ligada.

Obs: Os caracteres ~/. indicam que é o arquivo no diretório do usuário.

Vejam nas duas principais distribuições do mercado, como os arquivos são executados:

No Debian e Derivados:
1º /etc/init.d/bootmisc.sh
2º /etc/rc.local
3º /etc/bash.bashrc
4º /etc/profile
5º ~/.bashrc
6º ~/.profile

No Redhat e derivados:
1º /etc/rc.local
2º /etc/profile
3º ~/.bash_profile 
4º ~/.bashrc
5º /etc/bashrc

Note as difereça dos nomes dos arquivos entre as duas distribuições:

Debian
Redhat
/etc/profile
/etc/profile
/etc/bash.bashrc
/etc/bashrc
/etc/rc.local
/etc/rc.local
~/.bashrc
~/.bashrc
/ .profile
~/.bash_profile

Os arquivos .bash_profile pode ter o seu conteúdo modificado conforme as necessidades (preferências) de cada usuário. As alterações não ocorrem até que o arquivo seja lido novamente pelo shell. Para isto, devemos deslogar e logar novamente ou executar o seguinte comando:

# source
ou
# .

Veja os exemplos abaixo:

source .bashrc
source .profile
source .bash_logout
source /etc/bash.bashrc
source /etc/profile
source /etc/bash_completion
ou através do comando .
. .bashrc
. .profile
. .bash_logout
. /etc/bash.bashrc
. /etc/profile
. /etc/bash_completion

Fontes:

Infra-estrutura (FreeBSD) Unix no (Mac) OS X



Excelente Artigo sobre Sistemas Operacionais, Kernel, MicroKernel, Unix e Mac OS.

Recomendadíssimo!

http://www.fug.com.br/content/view/738/9/