Nos percalços da administração de sistemas, encontrei um problema interessante para resolver. Precisava instalar um RHEL 5.8 em um servidor com 6 discos de 600MB em RAID 5. Fácil? Nem tanto. Vamos aos problemas.
Em uma configuração de RAID 5, um dos discos é usado para paridade. Neste caso, temos 5x600MB ou 3TB de espaço líquido. Como o RAID é implementado por uma controladora, o processo é mais simples. Tudo é apresentado transparentemente para o sistema operacional como um disco único de 3TB. Porém, justamente este é o problema.
Normalmente é utilizado nos discos uma tabela de partição no formato DOS, aquela com MBR, 4 partições primárias, partições estendidas. Contudo, este formato desenvolvido na época dos Megabytes não lida muito bem com o mundo dos Terabytes. O tamanho máximo representável de disco é de 2.2 TB. No meu caso, tenho 3 TB. E agora José? A solução curta e grossa é dividir os discos em 2 RAID 5, cada um com 3 discos. Porém, neste caso, eu perderia 2 discos e não 1 com paridade. Como sempre, alguém já encontrou uma solução: um novo formato de partições chamado de "GUID Partition Table", ou para os mais íntimos, GPT.
O formato GPT faz parte do padrão (U)EFI que busca substituir a BIOS hoje presente na maioria dos computadores. Os servidores e sistemas operacionais mais novos suportam estes padrão. Bem, ai chegamos a outro problema. O RedHat Enterprise Linux (RHEL) versão 5.8 não suporta UEFI para ambientes x86. Se fosse na versão 6, o suporte é nativo. Como isto é um requisito do projeto, preciso resolver ainda com o RHEL v5.8.
O primeiro passo foi investigar o que cada componente deste ambiente suporta que recurso. Cheguei a este resultado:
- Servidor:
- Suporta BIOS e UEFI
- Suporta GPT tanto em BIOS como UEFI
Isto já é um ótimo começo. O uso do UEFI não é requisito para a BIOS usar discos GPT. Quanto ao RHEL v5.8:
- RHEL
- Grub (gerenciador de BOOT)
- Suporta somente formato DOS
- Kernel
- Suporta GPT mas não EFI
- Ferramentas
- Exceto o fdisk, suportam GPT e DOS
Tanto o grub quanto o kernel não suportam EFI. O grub nem mesmo suporta o GTP. Buscando um denominador comum, podemos utilizar o modo BIOS, disco com GPT mas empacamos no gerenciador de BOOT (obs: grub2 suporta GPT). A BIOS pode ler o gerenciador de BOOT, ele roda mas não encontra seus arquivos. Se conseguisse carregar o kernel e o INITRD, o problema estava resolvido. Precisamos, portanto, de alguma alternativa de BOOT ou alguma bruxaria para fazer o grub funcionar.
A primeira alternativa mais simples é utilizar um disco DOS para armazenar os arquivos do grub. Isto seria o diretório /boot. Nos meus testes, utilizei um pendrive e durante o processo de instalação configurei o /boot para usar o pendrive utilizando o formato DOS. Instalação sem problemas do início ao fim. Sistema iniciou e desligou sem erros. Mas este pendrive não ficou muito interessante... e se alguém retirar o pendrive? Só irei notar a falta dele quando reiniciar o servidor e aí, já é tarde.
Buscando mais alternativas para casos similares, encontrei o caso de máquinas MacBook, que usam UEFI e GPT, e onde era instalado o Windows XP. O GPT, para evitar problemas com softwares particionadores antigos, mantém uma tabela de partição no formato DOS. O primeiro setor do disco possui uma configuração de uma partição que ocupa toda a extensão do disco e do tipo "GPT EFI". O fdisk, que não suporta GPT, mostra esta informação. Note que o primeiro setor usado é o 1 e não o 63 como em discos DOS convencionais.
# fdisk -u -lWARNING: GPT (GUID Partition Table) detected on 'sda'! The util fdisk doesn't support GPT. Use GNU Parted.(...)
Device Boot Start End Blocks Id System
sda1 1 4294967295 2147483647+ ee GPT
O grub, e outros que não suportam GPT, também busca a informação onde estaria a MBR de um disco em formato DOS. A solução é (ab)usar desta configuração para informar ao grub onde ele poderia encontrar a partição /boot e seus respectivos arquivos. Isto é chamado de MBR híbrida, por conter informações do GPT e os dados de algumas partições ainda em formato DOS.
Agora, é necessário editar a tabela de partição da MBR e colocar as informações necessárias. Tentei utilizar o fdisk mas ele acabou destruindo todas as partições GPT, que tive que caçar bits para recriá-las. Googlando mais um pouco, encontrei o projeto GPT fdisk. Este projeto busca implementar um fdisk para formato GPT e algumas funcionalidades como a construção de uma MBR híbrida. Vamos ao roteiro completo.
Roteiro de instalação para o uso de MBR híbrida
Estas são instruções para o RHEL mas que, com pequenas adaptações, podem ser aproveitadas em outros ambientes.
Como primeiro passo, insira uma unidade de armazenamento temporária no servidor e dispare a instalação normalmente. Durante a fase de formatação de discos, vá para o terminal (CTRL+ALT+F2) e crie a tabela de partição em formato GPT:
# parted
(parted) mktable
... yes
... gpt
(parted) quit(parted) mktable
... yes
... gpt
Retorne ao instalador gráfico (CTRL+ALT+F6). Opte por um particionamento personalizado e utilize a seguinte disposição:
Dica: marque a partição PAD como "forçada como primária" para que ela fique como a primeira.
Atenção: a ordem é importante!
Dica: marque a partição PAD como "forçada como primária" para que ela fique como a primeira.
Atenção: a ordem é importante!
- sda (GPT) - disco RAID 5
- partição ext3 PAD (2 MB) (não montada ou em diretório não usado como /pad)
- partição ext3 para o /boot2 (que se tornará /boot)
- PV LVM
- partição ext3 para /
- partição swap
- (demais partições...)
- sdb (DOS) - pendrive
- partição ext3 para /boot
Siga a instalação normalmente. O gerenciador de BOOT deve ser instalado no disco sda, que é a opção padrão. A função da partição PAD irei explicar mais adiante.
O arranjo final dos discos fica desta forma:
# fdisk -u -l
Device Boot Start End Blocks Id System
sda1 1 4294967295 2147483647+ ee GPT# parted(parted) unit s
(parted) print
Model: DELL PERC H700 (scsi)
Disk /dev/sda: 5854986239s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Sinalizador
1 32s 4129s 4067s ext2 ext3
2 4130s 1028129s 1024000s ext3 ext3
3 1028130s 5854986206s 5853958077s lvm
O instalador não configura corretamente o boot no pendrive. Reinicie novamente usando a mídia de instalação da máquina. Porém, ainda no gerenciador de boot do DVD, entre no modo de recuperação: "linux rescue". No modo de recuperação, ele oferecerá a possibilidade de montar o sistema instalado. Permita a montagem. No shell, execute:
Agora, o sistema deverá iniciar normalmente. Efetue os passos finais da instalação.
Se a presença perpétua da unidade de armazenamento "temporária" não é um problema para o seu caso, você pode parar neste ponto. Neste caso, as partições sda1 e sda2 também não seriam necessárias. Para os demais casos, vamos a etapa retirar a dependência desta unidade de arO instalador não considera o boot no pendrive. Reinicie mazenamento temporária.
# chroot /mnt/sysiimage/# grub-install --recheck /dev/sda# exit# reboot
Agora, o sistema deverá iniciar normalmente. Efetue os passos finais da instalação.
Se a presença perpétua da unidade de armazenamento "temporária" não é um problema para o seu caso, você pode parar neste ponto. Neste caso, as partições sda1 e sda2 também não seriam necessárias. Para os demais casos, vamos a etapa retirar a dependência desta unidade de arO instalador não considera o boot no pendrive. Reinicie mazenamento temporária.
No sistema, instale o programa gdisk.
# wget http://apt.sw.be/redhat/el5/en/x86_64/rpmforge/RPMS/gdisk-0.6.10-1.el5.rf.x86_64.rpm# rpm -i gdisk-0.6.10-1.el5.rf.x86_64.rpm
Agora precisamos criar a configuração híbrida:
# gdisk /dev/sda... r... h... 2... Y... 83... N... N... w
Normalmente seria interessante criar uma partição para ocupar todo o restante do disco (última pergunta, penúltimo comando). Porém, por algum BUG deste programa, ele entra em uma live lock, provavelmente por causa do disco com tamanho maior que o limite da MBR. Só não alternar novamente as partições que tudo ficará bem.
É possível que a partição /pad seja corrompida neste processo. Qualquer coisa, recrie o sistema de arquivos do /pad
# mkfs.ext3 /dev/sda1 -L /pad
O disco, quando observado pelo fdisk fica desta forma:
Disk /dev/sda: 2997.7 GB, 2997752954880 bytes
255 heads, 63 sectors/track, 364456 cylinders, total 5854986240 sectors
Units = setores of 1 * 512 = 512 bytes
Dispositivo Boot Start End Blocks Id System
/dev/sda1 1 4129 2064+ ee EFI GPT
Partition 1 does not end on cylinder boundary.
/dev/sda2 4130 1028129 512000 83 Linux
Partition 2 does not end on cylinder boundary.
Note que o início e o fim da partição sda2, como esperado, é o mesmo do apresentado pelo parted. Agora voltamos a questão em aberto da partição PAD. A partição de PAD possui duas funções. A primeira é manter o número dos dispositivos sincronizados entre a GPT e a DOS. Como necessariamente teremos uma partição "GPT EFI" como sda1 do formato DOS, a primeira partição possível seria a sda2 que, coincidentemente, é a partição de interesse para o grub. O outro motivo é preventivo. A primeira posição válida para uma partição no GPT é no setor 32 (observe o parted). No caso do formato DOS, a primeira partição começa no setor 63. Desta forma, se algum programa estiver protegendo ou validando os setores "de controle" abaixo de 63, como o fdisk faz, eles não acessariam o começo de uma partição no setor 34.
Agora basta realizar a migração dos dados e configurações de /boot para /boot2.
- Edite o /boot/grub/menu.lst e troque todas as referências de "hd1,0" (sdb1) para "hd0,1" (sda2).
- Copie todo o conteúdo de /boot para /boot2 (cp -a /boot/* /boot)
- Desmonte ambas as partições (umount /boot /boot2)
- Remova a entrada de /boot2 no /etc/fstab. Note que a chamada da partição é pelo LABEL. Para trocar, atualize o label das duas partições:
- e2label /dev/sda2 /boot
- e2label /dev/sdb1 xxxx
- Remonte a partição (mount /boot)
- Remova a unidade de armazenamento temporária
- Reinstale o gerenciador de boot (grub-install --recheck /dev/sda)
- Se tudo ocorrer bem, reinicie o sistema.
Somente para reforçar a ideia, se seu sistema não tem discos de mais de 2.2TB, esqueça tudo que eu escrevi. Se tudo possui suporte nativo ao GPT (BIOS, kernel e gerenciador de boot e ferramentas) não use a MBR híbrida. E, se for necessário, mude para UEFI. Somente em último caso faça o que eu escrevi neste artigo.
Agora, basta cuidar para atualizar os dados da MBR com o gdisk caso seja alterado a posição ou tamanho da partição sda2. Criar ou alterar volumes lógicos não tem problemas.
Até a próxima.
