Posts tagged ‘linux’
-
hugepages
Estudando o sistema de gerenciamento de memória do Linux, encontrei um recurso interessante para uso mais eficiente de memória.Para ficar claro, explicarei brevemente como funciona o gerenciamento de memória do Linux.
Paginação
O Linux, na sua inicialização, verifica a quantidade de memória disponível e mapeia o endereçamento. Isto é feito pela MMU (Memory Management Unit) que atribui endereços virtuais para melhor gerenciamento. Assim é possível uso de swaping e transparência para os processos. Mais detalhes serão abordados em outro post.
Quando um processo faz uma requisição de memória ao Linux, este aloca o espaço solicitado em forma de páginas. As páginas, numa rápida analogia, é o mesmo que os blocos nas partições. Eles tem um cabeçalho e a área de dados propriamente dita. As páginas, em arquitetura x86, têm o tamanho de 4KB. Isto indica que quando precisamos de 12KB, o sistema aloca 3 páginas e entrega ao processo.
Hugepages
Este é um método bacana de estender as páginas para um tamanho maior. Como vimos, o Linux entrega páginas de tamanho fixo, e isso pode gerar um certo desperdício. Vejo isso em dois aspectos: overhead e uso real não múltiplo de 4.
Caso eu queira 10KB de memória, o sistema me entregará o maior múltiplo imediato para mim, ou seja, 12KB. Ou então, mesmo que eu use exatamente um múltiplo de 4, ao requisitar 120MB, terei 30720 páginas. Isso significa 30720 cabeçalhos, que mesmo que pequenos, representam uma perda.
Hugepages permite uso de páginas de 4MB em sistemas x86 de 32 bit e 2MB de 64bit. Assim, há um uso mais eficiente da memória quando é necessário um grande volume de memória. Outra característica também é que esse tipo de páginas não pode ser movida para a área swap.
Ativação e uso
Para tirar proveito desse tipo de paginação, é preciso que o kernel esteja preparado antes. Para isso, certifique que seu kernel tenha as seguintes opções ativadas:
CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y
Através do ‘make menuconfig’ vá em File Systems -> Pseudo filesystems -> HugeTLB file system support.
Depois de compilado e instalado o kernel, verifique se foi devidamente ativado:
grep -i huge /proc/meminfo HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB
Se apareceu algo parecido com isso, agora só falta alocar as páginas. Para isto, é necessário que haja espaço contíguo disponível para a quantidade que será alocada. Desta forma, é mais interessante alocar logo na inicialização do sistema. Para isto, acrescente a seguinte linha no arquivo /etc/sysctl.conf:
vm.nr_hugepages=256
Isto dirá ao kernel na inicialização alocar 256 páginas de tamanho 2048KB (no meu sistema 64 bit), Assim totalizando 512MB (256 * 2048KB = 512MB). Para tomar efeito, será preciso reinicializar o sistema.
Depois de reinicializado, certifique que tudo correu bem:
grep -i huge /proc/meminfo HugePages_Total: 256 HugePages_Free: 256 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB
Veja que nenhuma página foi usada. Um processo que queira fazer isto, deverá requisitar explicitamente por hugepages. Para criar uma interface de acesso, é preciso montar uma pseudo partição hugetlb. Acrescente no seu fstab:
hugetlbfs /dev/hugepages hugetlbfs defaults 0 0
Como o diretório /dev/hugepages não existe, é preciso criá-lo também antes de montar.
Uma boa aplicação para isto são máquinas virtuais baseadas em KVM, como descreverá o próximo post.
-
Converter discos virtuais
Há uma diversidade de hypervisiors no mercado, e com isso, há também uma diversidade de formatos de discos virtuais (vdi, vmdk, qcow, raw…) e muitas precisamos portar uma para a outra.
Uma forma prática e fácil de converter imagens é usando o qemu-img. Este utilitário acompanha o pacote qemu-kvm, que pode ser baixado e usado livremente. Veja alguns exemplos para converter discos:
vdi -> qcow
qemu-img convert -f vdi -O qcow origem.img destino.img
vmdk -> qcow
qemu-img convert -f vmdk -O qcow origem.img destino.img
vmdk -> vdi
qemu-img convert -f vmdk -O vdi origem.img destino.img
qcow -> raw
qemu-img convert -f qcow -O raw origem.img destino.img
raw -> qcow2
qemu-img convert -f raw -O qcow2 origem.img destino.img
qcow2 -> volume lógico (já citado em “Convertendo arquivos de imagens em volumes lógicos“)
qemu-img convert -f qcow2 -O host_device origem.img /dev/logical/destino
No final de contas, essa brincadeira pode ser feita entre todos estes formatos: cow qcow vdi vmdk cloop dmg bochs vpc vvfat qcow2 parallels nbd host_cdrom host_floppy host_device raw tftp ftps ftp https http
Mais informações sempre podem ser encontradas no manual.
man qemu-img
-
VirtualBox e usb
O VirtualBox tem um recurso de acesso à dispositivos USB da máquina host, mas nem sempre é fácil usá-lo. No meu caso, o host é um Slackware 13.1 Linux. O problema é de permissão e simples de se resolver. No início, quando o sistema de arquivos USB (usbfs) é montado, ele normalmente coloca tudo para apenas o root ter controle. A mágica está em alterar isto, usando o grupo plugdev, que no Slackware é usado para dispositivos removíveis.
Primeiramente seu usuário deve estar no grupo. Adicione o usuário que vai usar o VirtualBox no grupo com o seguinte comando, no meu caso, usuário eduardo:usermod -a -G plugdev eduardo
Agora basta uma alteração no fstab. Acrescente a seguinte linha:
usbfs /proc/bus/usb usbfs devgid=83,devmode=660 0 0
Isso fará com que o sistema no início monte o usbfs sendo do grupo do plugdev também, e dando permissão de leitura e escrita para seus membros.
Para resolver isso rapidamente sem reinicializar o sistema, use o seguinte:
mount -o remount,devgid=83,devmode=660 /proc/bus/usb
-
Dicas rápidas
Nessa ultima semana, descobri dois comandos que me foram bastante úteis. Esses são at e ionice. Abaixo segue um brief sobre ambos.
At
Esse comando é um agendador de tarefas. Semelhante ao cron, porém este não é cíclico. Agendar uma tarefa é fácil, basta informar ao at o arquivo que contém os comandos que serão executados e a hora e data. Talvez assim tenha ficado um pouco vago. Vou dar um exemplo. Crie um arquivo contendo o seguinte:
#/bin/sh touch /tmp/teste-at
Assumindo que o arquivo criado seja o ~/job.txt, vamos agendar a execução desse programa:
at -f ~/job.txt 3pm tomorrow
Se tudo ocorrer bem, aparecerá uma mensagem semelhante à essa:
job 1 at Thu Jul 29 15:00:00 2010
A notação de hora e data do at é um tanto flexível. Neste exemplo, poderíamos definir como 15:00 Jul 29 2010, ou então15:00 07/29/10. O resultado seria o mesmo. Para melhor detalhamento, consulte o manual do comando: man at. Para consultar os jobs que já foram agendados, use o comando primo atq, e para remover/cancelar um job, use o atrm fornecendo o id do job como primeiro argumento.
ionice
Assim como o comando nice, ele estabelece prioridades para os processos, mas este, se limita às operações de disco (I/O). Sua sintaxe é semelhante do seu primo nice. Dois argumentos eu enfatizo: -c e -p. O primeiro define o número da classe de prioridade e o segundo o número do PID que sofrerá a modificação.
As classes podem ser:
Idle: O processo só usará o processador para I/O se nenhum outro processo estiver usando.
Best effort: O processo concorrerá o processador em níveis de prioridade que podem ser definidas entre 0 e 7, sendo 0 (zero) a maior prioridade. Para definir esse valor, use a opção -n. Vale lembrar que qualquer que seja o nível de prioridadem ele sempre passará na frente de processos da classe Idle.
Real-time: Esse é para processos que realmente necessitem de atenção de I/O. Assim como a classe Best effort, esse é dividido em 8 níveis de prioridades e sua definição é idêntica. Vale lembrar que qualquer processo dessa classe, mesmo que seja prioridade 7, passará na frente de processos Best effort e Idle.
O número das classes Idle, Best effort e Real-time são respectivamente 3, 2 e 1. 0 (zero) significa que não pertence a classe alguma. Caso queira já iniciar o processo com ionice definido, troque o argumento -p pelo comando em si, como por exemplo:
ionice -c 3 cp ~/hugefile.img /tmp
Ou seja, defina classe Idle para o processo que executará a cópia do arquivo hugefile.img.
Para maior detalhamento, consulte o manual do comando, man ioince.
-
swapfile
Para usuários GNU/Linux, é muito comum o termo swap, ou partição swap. Em poucas palavras, ele diz respeito à técnica de extender a memória física, que as vezes não é suficiente, para o disco rígido. No Linux, o subsistema de memória usa um mapeamento virtual da memória, que permite um programa da userspace gravar na memória sem se preocupar onde está fisicamente. Mas este já é assunto para outro post.
Como de costume, logo na instalação de uma distribuição já particionamos o disco de uma tal maneira que uma parte fica reservada para a área de troca, que é a tradução de swap. Alguns usam partições primárias para isto, outros lógicas… Alguns seguem uma regra que diz que “a capacidade do swap deve ser o dobro da memória física”… mas no final, isso fica mesmo é a critério do administrador do sistema.
O problema da partição é que complica no caso de precisar aumentar seu espaço. Para isto, poderia criar outra partição e ativá-la no sistema, mas seria necessário espaço em disco não particionado.
Uma solução rápida para isto seria criar um arquivo de swap, ou swapfile. Para criá-lo é quase igual à uma partição, já que para o Linux, os dispositivos de block são representados como arquivos e, cá entre nós, uma partição nada mais é que um conteiner grande de dados (um arquivão!). Na prática, sua criação ficaria assim:
Gerar um arquivo do tamanho de 512 * 100.000 bytes (100.000 blocos de 512 bytes) contendo apenas zeros:
dd if=/dev/zero of=/tmp/swapfile bs=512 count=100000
Definir o arquivo criado como swap:
mkswap /tmp/swapfile
Ativar o novo arquivo no pool de swap do sistema com prioridade 0 (zero):
swapon -p 0 /tmp/swapfile
Verificar o pool swap do sistema:
swapon -s
Desativar um dispositivo/arquivo swap do sistema:
swapoff /tmp/swapfile
Quanto à performance e aplicabilidade em ambiente de produção, prefiro não opinar, mas acredito ser uma alternativa mais rápida e simples para o aumento da área de troca, swap.
-
ssh com chave privada
No mundo Linux o protocolo ssh é muito utilizado para administração remota e transferência segura de arquivos entre hosts, sendo na maioria servidores. Acredito que sua ampla adoção se deve à simplicidade, velocidade e segurança. Por padrão, na maioria das distribuições Linux ele usa autenticação por senha e um par de chaves públicas.
Outro método de autenticação seria por meio de um par de chaves pública e privada. Nesse método, cada cliente possui uma chave privada que o identifica e deve ser protegida. O servidor recebe a chave pública correspondente de cada cliente para autenticar. Desta forma, não há, à princípio, necessidade de senha. Porém, o próprio certificado pode exigir uma senha para ser acessado, mas assim, ele será único para todos os servidores e não haverá tráfego de senha entre servidor e cliente. Vejamos como fazer isto:
No cliente, é preciso gerar as chaves com o seguinte comando:
ssh-keygen
Ele perguntará por uma senha. Caso queira fornecer, digite-a. Caso queira que o acesso seja direto, deixe em branco. Por padrão, ele gerará dois arquivos: ~/.ssh/id_rsa e ~/.ssh/id_rsa.pub. Respectivamente eles são a chave privada e pública em algorítmo RSA. Copie a chave pública para o servidor (assumindo que o IP dele é 10.0.0.8):
scp ~/.ssh/id_rsa.pub 10.0.0.8:~
No servidor, insira a chave pública recém recebida na lista de chaves autorizadas:
cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
Feito isto, basta alterar o modo de autenticação do servidor. Acesse o arquivo de configuração /etc/ssh/sshd_config e altere, acrescente ou descomente as seguintes opções para que confira com o modelo:
# Define autenticação por chave pública RSA. RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys # Desabilita autenticação por senha PasswordAuthentication no PermitEmptyPasswords no
Reinicialize o serviço do ssh. No Slackware execute /etc/rc.d/rc.sshd restart. Agora está pronto, basta testar. No cliente, pode-ser conectar usando duas sintaxes:
ssh 10.0.0.8
Use o exemplo acima caso o nome do arquivo e caminho da chave seja o padrão, ~/.ssh/id_rsa. Se for diferente, a seguinte sintaxe será necessária:
ssh -i <caminho completo para chave privada> 10.0.0.8
Para mais informações, o bom e velho man sempre ajuda.
-
libvirt e LVM2
Uma ótima forma de criar uma estrutura para suportar máquinas virtuais é a parceria entre libvirt e LVM2. No meu caso em específico, uso o emulador qemu-kvm para rodar minhas máquinas virtuais. A seguir, apresentarei como se cria um pool de volumes lógicos no libvirt e como converter máquinas já criadas em arquivos de imagens.
Antes de tudo, é necessário que já tenha sido criado um grupo virtual. Como isso não está no escopo do post, recomendo navegar por esse howto. Com o grupo criado e ativado, vamos criar a definição do pool para o libvirt. Abra um editor de texto, como o vim, e coloque nele o seguinte texto:
<pool type='logical'> <name>logical</name> <source> <device path='/dev/sdb1'/> <name>logical</name> <format type='lvm2'/> </source> <target> <path>/dev/logical</path> </target></pool>
Nesse exemplo, vamos assumir que a partição que compõe o grupo logico é o /dev/sdb1. Após, salve com um nome sugestivo, como por exemplo logical.xml. Agora só resta registrar no libvirt.
virsh pool-define logical.xml
Mesmo registrado, o sistema ainda não ativou o pool. É recomendado que ele seja marcado como autostart, para que caso o libvirt pare, ele ative automaticamente o pool. Para isto, basta os seguintes comandos:
virsh pool-autostart logical virsh pool-start logical
Com o pool inicializado, agora só resta criar um volume lógico dentro dele:
virsh vol-create-as logical disco_teste 10GB
Este comando criará um volume lógico de nome disco_teste no grupo logical tendo como capacidade 10GiB
Convertendo arquivos de imagens em volumes lógicos
Caso já tenha uma máquina virtual configurada em um arquivo de imagem nos formatos suportados pelo qemu, basta convertê-lo usando o próprio qemu-img para o formato desejado. Na versão 0.12.4 os formatos suportados são: cow, qcow, vdi, vmdk, cloop, dmg, bochs, qcow2, host_device, raw entre outros.
Antes de começar, é preciso criar um volume lógico com o mesmo tamanho da imagem existente. Para ter o valor correto, use a ferramenta qemu-img para saber o tamanho total da imagem:
qemu-img info disco.img
Ele retornará algo como:
image: disco.img file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 4.0G cluster_size: 65536
Veja que, embora o arquivo tenha tamanho de 4GB, ele pode crescer até o tamanho virtual, que é de 10GB para esta imagem. Agora, crie um volume lógico com este tamanho seguindo o modelo logo acima.
Eu conheço duas formas de levar o arquivo de imagem para um volume lógico. A primeira é usando o qemu-img para já gravar a imagem no volume:
qemu-img convert -f qcow2 -O host_device disco.img /dev/logical/disco_teste
Ou então, com uma etapa a mais, e portanto mais demorada, transformando a imagem do formato nativo para raw e depois transferindo os dados de forma bruta para o volume com o dd:
qemu-img convert -f qcow2 -O raw disco.img disco.raw dd if=disco.raw of=/dev/logical/disco_teste
O resultado de ambos é o mesmo. Desde que tenha um domínio registrado com esse disco, agora é só usar o volume lógico recém criado. A definição de um disco em volume lógico segue o modelo:
<devices> ... <disk type='block' device='disk'> <source dev='/dev/logical/disco_teste'/> <target dev='sdc' bus='scsi'/> </disk> ... </devices>
-
LVM2 Snapshot
Nessas ultimas semanas andei procurando por uma solução eficiente para backups de discos, se possível, usando imagens. Eis que conheço o recurso de snapshot do LVM2. Ele é bastante fácil de usar, mas, é lógico, você precisa de uma partição no seu disco do tipo LVM, tipo 8e.
Tendo isto em mãos, basta criar um grupo de volumes lógicos do tamanho desejado na nova partição LVM. Isso pode ser feito com o seguinte comando:
vgcreate logical /dev/sdb1
No meu caso, eu não especifiquei o tamanho máximo do grupo, portanto ele pega todo o espaço disponível em sdb1. A grosso modo, o grupo de volumes lógicos está para um disco físico assim como os volumes lógicos estão para as partições. A diferença é que a virtualização do disco permite um ambiente mais flexível e simples.
Com o grupo pronto, basta adicionar os volumes. Meu disco tem 80GB, e para teste vou gerar um volume de 10GB chamado teste no grupo logical:
lvcreate -L10G -n teste logical
Pronto! Agora pode verificar que existe um dispositivo de bloco criado em /dev/logical/teste. Ele representa o volume lógico. Ele se comporta como um dispositivo de bloco comum, e portanto, pode ser tratado como um. Para conseguir usar, esse volume precisa ser formatado. Eu costumo usar o raiserfs, mas pode ser usado ext3, ext4, xfs…
mkreiserfs /dev/logical/teste mount -t reiserfs /dev/logical/teste /mnt/tmp
O volume agora pode ser usado normalmente. É só acessar o ponto de montagem /mnt/tmp. Com o ambiente todo pronto, agora vamos ao que interessa, o snapshot. Assumindo que o volume está em plena produção, vamos simular uma situação de backup online, que é a aplicação mais óbvia que vejo neste recurso. Para melhor entendimento, vamos analisando os passos seguintes:
lvcreate -L 500M -s -n backup /dev/logical/teste
Isso fará com que seja criado um volume lógico de 500MB, de nome backup e tipo snapshot do volume já existente /dev/logical/teste. O tamanho do snapshot é claramente menor que o volume original, e isso não está errado. No momento em que o snaphot é criado, o sistema ‘congela’ o volume original para que possamos trabalhar com ele sem que haja alterações, e o tamanho do snapshot representa o volume de alterações que ele permitirá que o sistema em produção faça nesse volume sem que seja prejudicado. A grosso modo, é como se fosse um buffer de alterações, que são armazenadas sem serem efetivadas no volume original. Para aqueles que conhecem o sistema de arquivamento e hotbackup de SGBDs, é a mesma coisa.
Muitos dão exemplos de backups usando snapshots montando o volume snapshot e copiando os arquivos com cp, compactando com tar e gz, mas eu normalmente crio uma imagem completa com o dd. De qualquer forma, apresentarei ambos abaixo:
Tar e gz
mount -t reiserfs /dev/logical/backup /mnt/tmp0 tar cf ~/backup.tar.gz /mnt/tmp0
dd
dd if=/dev/logical/backup of=~/backup.img
Depois do backup, basta remover o snapshot que as alterações serão aplicadas.
lvremove -f /dev/logical/backup
-
libvirt no Slackware 13.1
Libvirt é um ótimo utilitário para gerenciamento de máquinas virtuais de algumas plataformas de virtualização, como Xen, KVM, VMWare ESX, VirtualBox, OpenVZ, entre outros. Neste post farei um guia rápido para instação dele.
Como estou usando a distribuição Slackware, é interessante compilar o libvirt e gerar um pacote txz, no padrão da distribuição. Como o pessoal da slackbuilds.org já disponibilizou o script SlackBuild para ele, vamos aproveitar. Acesse esse link que mostrará o resultado da busca por libvirt no repositório. Como resultado, aparecerá o link para a página de download da versão mais atual que estiver no repositório. Clique no link.
Quando escrevi este post, a versão que estava lá era a 0.7.6, mas eu abordarei aqui a versão 0.8.1 por causa de novos recursos. Portanto, o único pacote necessário será o libvirt.tar.gz. Baixe-o clicando no link da página. O código fonte da versão 0.8.1 você encontrará neste endereço.
Dentre vários recursos desta versão, uma em especial eu gostaria de colocar em evidência: o suporte ao módulo macvtap. A grosso modo, isto possibilita anexar uma interface virtual tap em uma interface real. Assim é possível que o sistema operacional hóspede se integre à LAN real da máquina hospedeira. Este recurso está disponível a partir da versão 2.6.34 do kernel do Linux. Desta maneira, será necessário atualizar o kernel para esta versão. Como compilar o kernel não está no escopo do artigo, deixo apenas a informação de habilitar o recurso de macvtap na seção Device Drivers->Network device support->MAC-VLAN support e MAC-VLAN based tap device.
Supondo que os pacotes do libvirt foram salvos no diretório ~/libvirt, execute os seguintes passos:
cd ~/libvirt tar xvf libvirt.tar.gz mv libvirt/* .
Edite o arquivo libvirt.SlackBuild para alterar a versão de 0.7.6 para 0.8.1. Salve e vamos compilar:
ARCH=`uname -m` ./libvirt.SlackBuild
Aguarde terminar e após instale o pacote:
installpkg /tmp/libvirt-0.8.1-x86_64-1.tar.gz
Configuração básica
Verifique neste post um exemplo de script de inicialização para o serviço do libvirt. Copie o script para um arquivo chamado rc.libvirtd na pasta /etc/rc.d/. Devo lembrar de acrescentar sua chamada dentro do script rc.local, caso queira que ele suba automaticamente com o sistema, quando iniciado.
Por default, o servidor do libvirt abrirá um socket tls para acesso tcp, e para isto, é necessário gerar um certificado. Com a finalidade apenas de teste, não creio ser necessário isto, já que o acesso normalmente será feito pelo socket unix mesmo. Altere a opção listen_tls=1 para listen_tls=0 no arquivo /etc/libvirt/libvirtd.conf. Não adianta só comentar esta linha, já que o default é habilitado.
-
The recovery
Continuando o post anterior…
Quando vi que nada funcionava bateu aquele gelo: PUTZ! COMO FUI FAZER ISSO?! Logo pensei: preciso ficar frio e encarar este desafio agora, recuperar o sistema… Já abri uma VM que tenho aqui de testes e dei o mesmo comando suicida, para representar o cenário e propor uma solução. Logo pensei: vou isolar esse disco virtual e trabalhar com ele em secudário, já que ele zuado não iniciará. Como eu estava trabalhando com um Slackware, em ambos sistemas, já resolvi inicializar via DVD de instalação, já que o Slackware entrega um bash no início da instalação.
Depois de inicializado pelo DVD, montei a partição / da instalação estragada no diretório virtual /mnt (virtual sim porque inicializei via DVD). Montou sem problemas, mas é claro, não estraguei a partição, e sim o sistema. Fui até o diretório que foi promovido ao novo /, o /mnt/usr/src/twolame, e verifiquei que todas as pastas movidas estavam lá, e totalmente acessíveis e com as permissões originais. Simplesmente executei o comando inverso da cagada:
mv /mnt/usr/src/twolame/* /mnt
Pronto, sem mensagens de erro. Para ver se tive êxito, reinicializei o sistema, mas procurando o boot no disco da VM. Simpirilim! Funcionou. Parace que o sistema nunca passou pelo que passou. Tudo em seu devido lugar, apenas parti para a máquina física que foi abençoada com meu comando mortal para fazer o mesmo.
Resumindo… tudo resolvido. UFA!
Tags
- There was a problem connecting to Twitter, or no public messages were found.
Recentes
Estou lendo
Wish list
Blog
- Carlos Feichas
- Debugging Consultoria
- Fabiano Xavier
- Fábio Arezi
- Felipe Molina
- Lucas Catón
- Mateus Penha
- Tiago Mathidios
Lista de Links
- Asterisk Asterisk PBX
- Debugging Consultoria Debugging Consultoria
- LPI
- Slackbuilds Repositório Slackbuilds
- Slackware Site oficial Slackware
- Viva o Linux Comunidade Viva o Linux
- Voip-Info Wiki VoIP