Fundamentos do RAID

RAID (Redundant Array of Independent Disks) é uma técnica de virtualização de armazenamento que agrupa vários discos físicos em uma única unidade lógica. A combinação visa aumentar a capacidade, elevar o desempenho de leitura e escrita ou introduzir redundância para tolerância a falhas. A implementação pode ocorrer por meio de uma controladora dedicada (RAID por hardware) ou diretamente pelo sistema operacional, utilizando ferramentas como o mdadm no Linux (RAID por software).

O RAID reduz o risco de indisponibilidade causada por falha isolada de um disco, mas não elimina a necessidade de backups. Perdas por corrupção lógica, erros humanos, malware ou falhas simultâneas ainda podem ocorrer, por isso um plano de cópias de segurança externas permanece indispensável.

Níveis de RAID mais utilizados

Pilares do RAID

• Mirroring (espelhamento): grava cópias idênticas dos dados em discos distintos. Se um falhar, o outro mantém as informações acessíveis.
• Striping: divide os dados em fatias (chunks) distribuídas entre os discos, permitindo leituras e escritas paralelas.
• Paridade: cálculo matemático adicional (baseado em XOR) armazenado nos discos. Possibilita a reconstrução do conteúdo quando um disco é perdido.

Implementação por hardware ou por software

Em servidores físicos, o RAID por hardware depende de uma controladora dedicada, que gerencia os discos e expõe um único volume lógico ao sistema operacional. Já o RAID por software é gerenciado pelo kernel Linux através do módulo md (multiple devices), com auxílio da ferramenta mdadm. Em ambientes de nuvem, a redundância geralmente é abstraída pelo provedor, reduzindo a necessidade de configurar arrays manualmente.

Uma pergunta comum em entrevistas é: ao usar RAID por hardware, deve-se criar o array antes ou depois de instalar o sistema? A resposta é antes: a controladora precisa apresentar o volume lógico já configurado para que o instalador do SO o reconheça.

Tratamento de falhas em disco

• Hot Spare: disco ocioso inserido no array que entra automaticamente em ação quando outro disco falha. Pode ser global, compartilhado entre vários arrays, ou dedicado, reservado a um único array.
• Hot Swap: capacidade de substituir fisicamente um disco defeituoso sem interromper o funcionamento do sistema.

Comandos essenciais do mdadm

Laboratório: criando um array RAID 10

Neste exemplo, quatro novos discos foram conectados à máquina. O volume lógico receberá o nome /dev/md10, será formatado com XFS e montado em /dados/raid10.

# Listando os dispositivos disponíveis
[root@lab ~]# ls /dev/sd*
/dev/sda  /dev/sda1  /dev/sda2  /dev/sdf  /dev/sdg  /dev/sdh  /dev/sdi

# Instalando o mdadm
[root@lab ~]# dnf install mdadm -y

# Criando o array RAID 10
[root@lab ~]# mdadm --create /dev/md10 --level=10 --raid-devices=4 /dev/sdf /dev/sdg /dev/sdh /dev/sdi
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md10 started.

# Formatando o volume com XFS
[root@lab ~]# mkfs.xfs /dev/md10
meta-data=/dev/md10              isize=512    agcount=16, agsize=655360 blks
data     =                       bsize=4096   blocks=10485760, imaxpct=25
         =                       sunit=128    swidth=256 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=5120, version=2
         =                       sectsz=512   sunit=8 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

# Criando o ponto de montagem e montando
[root@lab ~]# mkdir -p /dados/raid10
[root@lab ~]# mount /dev/md10 /dados/raid10

# Persistindo no /etc/fstab
[root@lab ~]# echo '/dev/md10 /dados/raid10 xfs defaults 0 0' >> /etc/fstab

Para verificar o progresso da sincronização e o estado dos discos:

[root@lab ~]# mdadm --detail /dev/md10

Simulando falha e recuperando o RAID 10

Para testar a resiliência do array, marque um disco como defeituoso, remova-o e adicione um novo disco para reconstrução.

# Marcando /dev/sdf como falho
[root@lab ~]# mdadm --manage /dev/md10 --fail /dev/sdf
mdadm: set /dev/sdf faulty in /dev/md10

# Removendo o disco defeituoso
[root@lab ~]# mdadm --manage /dev/md10 --remove /dev/sdf
mdadm: hot removed /dev/sdf from /dev/md10

# Adicionando um disco novo
[root@lab ~]# mdadm --manage /dev/md10 --add /dev/sdn
mdadm: added /dev/sdn

Ao executar novamente mdadm --detail /dev/md10, será possível observar o processo de rebuild, indicando que o array está sendo reconstruído com os dados do disco recém-inserido.

Laboratório: RAID 5 com disco hot spare

Para montar um RAID 5 com um disco de reserva automática, são necessários três discos ativos e um disco reserva. Neste exemplo usaremos /dev/md5.

# Criando RAID 5 com 1 hot spare
[root@lab ~]# mdadm --create /dev/md5 --level=5 --raid-devices=3 --spare-devices=1 /dev/sdj /dev/sdk /dev/sdl /dev/sdm
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md5 started.

# Formatando e montando
[root@lab ~]# mkfs.xfs /dev/md5
[root@lab ~]# mkdir -p /dados/raid5
[root@lab ~]# mount /dev/md5 /dados/raid5

# Verificando o estado (note o disco spare)
[root@lab ~]# mdadm --detail /dev/md5
...
    Number   Major   Minor   RaidDevice State
       0       8      112        0      active sync   /dev/sdj
       1       8      128        1      active sync   /dev/sdk
       2       8      144        2      active sync   /dev/sdl

       3       8      160        -      spare   /dev/sdm

Ao simular a falha de um dos discos ativos, o disco spare entra automaticamente em ação e inicia a reconstrução do array:

[root@lab ~]# mdadm --manage /dev/md5 --fail /dev/sdj
[root@lab ~]# mdadm --detail /dev/md5 | grep -E "State|Rebuild"
             State : active, degraded, recovering
    Rebuild Status : 4% complete

Processo de inicialização do CentOS 7

A sequência de boot de um sistema CentOS 7 pode ser dividida nas seguintes etapas:

1. POST e firmware: após ligar a máquina, UEFI ou BIOS executa o Power-On Self Test, verificando memória, processador e dispositivos essenciais. Em seguida, localiza o dispositivo de boot.
2. Carregamento do bootloader: em sistemas BIOS, o setor inicial do disco (MBR, 446 bytes iniciais) é carregado; em sistemas UEFI, o firmware executa o arquivo /EFI/centos/grubx64.efi da partição ESP (EFI System Partition).
3. GRUB 2: o estágio 1 localiza e carrega o estágio 1.5 (driver do sistema de arquivos da partição /boot), que por sua vez carrega o estágio 2. Este lê /boot/grub2/grub.cfg e exibe o menu de seleção do kernel.
4. Carregamento do kernel e initramfs: o kernel selecionado é descompactado na memória, acompanhado da imagem initramfs, que contém módulos e scripts necessários para montar o sistema de arquivos raiz.
5. Transição para o root real: após montar o root real a partir do disco, o controle é passado ao processo /sbin/init, que no CentOS 7 é um link simbólico para o systemd.

Targets do systemd e runlevels legados

O CentOS 7 substituiu os runlevels tradicionais por targets. O target padrão é definido pelo link simbólico /etc/systemd/system/default.target. A equivalência aproximada com os runlevels anteriores é:

Sequência de inicialização do systemd

Após assumir o controle, o systemd executa os targets na seguinte ordem lógica:

1. initrd.target: finaliza a montagem dos sistemas de arquivos definidos em /etc/fstab ainda dentro do initramfs.
2. Transição do ambiente initramfs para o sistema de arquivos raiz real do disco.
3. sysinit.target: inicializa configurações básicas, como hostname, relógio do sistema, teclado e variáveis de ambiente.
4. basic.target: prepara o ambiente operacional mínimo.
5. multi-user.target: inicia serviços de rede, consoles virtuais e executa scripts em /etc/rc.d/rc.local, quando habilitado.
6. graphical.target: carrega o ambiente gráfico, caso o sistema esteja configurado para iniciar em modo GUI.

Diferenças entre CentOS 6 e CentOS 7 no boot

O CentOS 6 utilizava o processo init baseado em SysV, onde serviços eram iniciados sequencialmente por scripts localizados em /etc/rc.d/rc*.d. O CentOS 7 adotou o systemd, que paraleliza a inicialização, gerencia dependências por meio de units e oferece recursos como systemctl para controle de serviços, journalctl para consulta de logs e gerenciamento de recursos por cgroups.