Servidor NAS

1. Resumo

Servidor NAS virtualizado desenvolvido para estudo de infraestrutura Linux, armazenamento redundante e administração de sistemas. O projeto utiliza QEMU/KVM com Debian minimal, RAID10 via mdadm, LVM, Btrfs, SSH e automação básica via shell script.

O objetivo do laboratório é explorar arquitetura de storage em Linux de forma prática, analisando redundância de dados, virtualização leve, gerenciamento de volumes, snapshots e compartilhamento de arquivos em rede. Durante o desenvolvimento foram avaliadas diferentes abordagens de RAID, incluindo LVM RAID e mdadm, além da estrutura interna do RAID10 em nível de blocos.

A infraestrutura foi construída de forma minimalista e modular, priorizando controle operacional, entendimento da stack e redução de abstrações desnecessárias.

2. Escolha do sistema operacional

A escolha do sistema operacional foi baseada principalmente em estabilidade, já que servidores precisam operar continuamente por longos períodos. Um sistema com alta frequência de mudanças ou necessidade constante de atualizações pode reduzir a previsibilidade e confiabilidade da infraestrutura.

O Debian é uma excelente escolha para esse cenário por possuir um ecossistema extremamente estável, atualizações conservadoras e foco em segurança e confiabilidade. É uma distribuição com um propósito muito bem definido dentro da infraestrutura Linux.

3. Objetivo do laboratório

Há alguns meses venho me interessando bastante por armazenamento, redundância de dados e estratégias de backup em ambientes Linux. Já possuía certa familiaridade com ferramentas como LVM, Btrfs, RAID e mdadm, então decidi colocar esse conhecimento em prática de forma mais profissional através da criação de um servidor NAS virtualizado.

O objetivo principal do laboratório é aprofundar conhecimentos em infraestrutura Linux, armazenamento redundante e compartilhamento de recursos em rede, utilizando uma abordagem prática baseada em testes, tentativa e erro e análise do comportamento real das tecnologias utilizadas.

4. Virtualização com QEMU/KVM

Inicialmente considerei utilizar o virt-manager para realizar toda a configuração da máquina virtual, porém após alguns testes percebi que para este laboratório a melhor escolha seria utilizar QEMU/KVM diretamente pela linha de comando.

Apesar do virt-manager ser uma ferramenta extremamente completa e muito utilizada em ambientes virtualizados, ele adiciona algumas camadas extras de abstração que não faziam sentido para o objetivo do projeto. Como a ideia do laboratório é estudar infraestrutura, armazenamento e comportamento do sistema de forma mais próxima possível do ambiente real, optei por utilizar o QEMU nativo para ter controle mais direto sobre hardware virtual, discos, rede e parâmetros da máquina.

Além disso, a configuração via terminal permite um controle muito mais fino sobre a virtualização e facilita entender exatamente o que está sendo executado pela VM.

4.1 Criação das imagens de disco

Utilizei o comando qemu-img para criar todas as imagens necessárias, esta parte do codigo em especifico “> /dev/null” eu usei porque a saída do comando polui muito a tela e fica ruim de mostrar, e não influencia em nada no resultado final da criação das imagens.

como podemos ver foram criadas sete imagens no total uma com 10 GB para a instalação do Debian e seis com 2GB para a simulação de HDs em um servidor NAS fisico.

4.2 Script QEMU

Este é script inicial voltado a iniciar o boot pela imagem de instalação do Debian:

#!/bin/bash

qemu-system-x86_64 \
  -enable-kvm \
  -m 1024 \
  -smp 2 \
  -boot d \
  -cdrom debian-13.4.0-amd64-netinst.iso \
  -drive file=debian.qcow2,if=virtio \
  -drive file=hd0.qcow2,if=virtio \
  -drive file=hd1.qcow2,if=virtio \
  -drive file=hd2.qcow2,if=virtio \
  -drive file=hd3.qcow2,if=virtio \
  -drive file=hd4.qcow2,if=virtio \
  -drive file=hd5.qcow2,if=virtio \
  -nic user,hostfwd=tcp::2222-:22,model=virtio \

Após a instalação removi o boot via imagem ISO e o script final ficou assim:

#!/bin/bash

qemu-system-x86_64 \
  -enable-kvm \
  -m 1024 \
  -smp 2 \
  -drive file=debian.qcow2,if=virtio \
  -drive file=hd0.qcow2,if=virtio \
  -drive file=hd1.qcow2,if=virtio \
  -drive file=hd2.qcow2,if=virtio \
  -drive file=hd3.qcow2,if=virtio \
  -drive file=hd4.qcow2,if=virtio \
  -drive file=hd5.qcow2,if=virtio \
  -nic user,hostfwd=tcp::2222-:22,model=virtio \
4.2.1 Explicão do script

O script utilizado para iniciar a máquina virtual foi mantido de forma propositalmente simples para facilitar entendimento e controle da infraestrutura.

A flag `-enable-kvm` ativa aceleração por hardware utilizando KVM, reduzindo overhead da virtualização e aproximando o desempenho da VM ao hardware real. A configuração `-m 1024` define 1 GB de memória RAM para o sistema virtualizado, quantidade mais do que suficiente para um laboratório NAS minimalista. Já `-smp 2` disponibiliza dois núcleos de processamento para a máquina virtual.

Os parâmetros `-drive` são responsáveis por conectar os discos virtuais ao sistema. Foi utilizado um disco principal para instalação do Debian e outros seis discos adicionais destinados ao armazenamento e criação do array RAID10. Todos foram configurados utilizando VirtIO para reduzir overhead e melhorar desempenho de I/O.

A configuração de rede foi feita utilizando `-nic user` com redirecionamento da porta SSH através de `hostfwd=tcp::2222-:22`, permitindo acesso remoto ao servidor pela máquina host sem necessidade inicial de bridge de rede mais complexa.

5. Processo de instalação do Debian

Iniciei o processo de instalação nas opções avançadas e utilizando o Expert install para máximo controle sobre oque estamos instalando:

Agora podemos ver no Partman que foram reconhecidas corretamente todas as sete imagens de disco:

Muito importante nessa parte escolher apenas o serviço SSH, pois ambientes gráficos são completamente desnecessários para um servidor NAS.

Após a instalação completa e com a maquina desligada realizei um backup da imagem qcow2 do Debian já instalado, o objetivo é não ter que reiniciar completamente a instalação por algum erro que eu possa cometer. Recursos de snapshots usando qemu puro como estou usando são bons mas muito complexos de gerenciar fora do virt-manager então utilizei o seguinte comando:

cp debian.qcow2 debian.qcow2.bak
6. Configurações do array RAID 10

Após acessar a maquina via SSH comecei o processo de configuração do RAID

6.1. Instalação do pacotes necessários

Após todas as configurações do sistema operacional estarem minimamente prontas iniciei o processo de instalação dos pacotes necessários para o RAID e sistema de arquivos neste caso o lvm2 e btrfs-progs. Após a instalação reiniciei a maquina pois esses pacotes carregam módulos junto ao kernel e apenas uma reinicialização completa deixa o sistema completamente operacional

apt install lvm2 btrfs-progs
6.2. Criação dos volumes físicos LVM

Utilizando o comando pvcreate defini cada um dos nossos HDs virtuais como volumes físicos no LVM. Esse processo grava cabeçalhos LVM nos discos com meta dados.

pvcreate /dev/vdb /dev/vdc /dev/vdd /dev/vde /dev/vdf /dev/vdg
6.2.1. Definição do grupo de volumes

Agora definindo o grupo de volumes vg_storage onde configuraremos o RAID com todos os HDs.

vgcreate vg_storage /dev/vdb /dev/vdc /dev/vdd /dev/vde /dev/vdf /dev/vdg
6.2.2. Verificando o status dos volumes físicos e grupos de volumes

Com os comandos pvs e vgs verifiquei o status de todas as configurações feitas até o momento no LVM. Como podemos ver na imagem todos os seis HDs estão definidos como volumes físicos e atribuídos ao grupo de volumes vg_storage. O grupo de volumes tem um total de 11.98gb livres e isso é esperado pois há cabeçalhos LVM contendo meta dados em todos os discos.

6.2.3. Configuração LVM RAID

Usei este comando para criar o RAID.

lvcreate \
  --type raid1 \
  -m1 \
  -L 2G \
  -n lv_data \
vg_storage

E verifiquei o estado do RAID com este outro comando.

lvs -a -o +devices

A saída do comando foi pouco clara para mim, o LVM é poderoso mas acredito que não seja a melhor saída para o meu objetivo.

6.3. Mudança de LVM para MDADM
6.3.1 Motivos da decisão

Após um longa pesquisa usando IA  Wikipedia e analisando um pouco da documentação do MDADM percebi que está é a ferramenta correta para o meu objetivo, é simples a implementação e bem mais didático para mim que estou aprendendo storage em Linux. Devido a ideia por trás do projeto ser algo muito simples e funcional com o minimo de pontos de falha possível o MDADM se mostra mais robusto, visto que LVM é muito complexo.

6.3.2 Implementação RAID com MDADM.

Com apenas esse único comando foi possível criar toda a estrutura RAID 10.

mdadm --create /dev/md0 \
    --level=10 \
    --raid-devices=6 \
    /dev/vdb /dev/vdc \
    /dev/vdd /dev/vde \
    /dev/vdf /dev/vdg

Analisei o status do RAID, no momento do print o MDADM estava sincronizando os bits entre os discos. Ao analisar a imagem podemos ver [UUUUUU] no caso cada "U" significa que cada um dos seis discos do array em estado operacional. 

cat /proc/mdstat

Analisei mais afundo a estrutura do RAID 10 que acabei de criar, procurando mais entendimento, e foi nesse momento que descobri algo muito interessante sobre a estrutura toda. Eu anteriormente imaginava que essa configuração haveria redundância dos dados a nível de dispositivo de armazenamento, sendo um disco um espelho idêntico do outro. Pesquisando mais afundo descobri que essa configuração a redundância funciona a nível de blocos, ou seja um mesmo arquivo pode ter blocos de dados divididos em todos os seis discos.

 Essa é um explicação simples e mais detalhes você pode conferir no link abaixo.

https://en.wikipedia.org/wiki/Non-standard_RAID_levels

7. Implementação do sistema de arquivos BTRFS

A escolha do BTRFS como sistema de arquivos se deve a minha experiencia com ele em testes que fiz anteriormente e muita pesquisa sobre subvolumes, snapshots e rotinas de backup. A robustes e modulariedade do BTRFS são pontos cruciais para o intuito do meu projeto.

7.1 formatação do volume RAID e criação do subvolume principal.

Utilizando o este comando formatei o array.

mkfs.bttrfs /dev/md0

Criei um diretório na raiz do sistema montei o  array e criei o subvolume principal

mkdir /storage
mount /dev/md0 /storage
btrfs subvolume create /storage/@main

Verifiquei o estado do subvolume

btrfs subvolume show @main

8. Conclusão dos processos realizado até o momento e próximos passos

Até o momento atual vejo pontos positivos e negativos sobre todo o projeto, a escolha do Debian foi uma coisa que me questionei bastante, devido ao systemd ser algo muito complexo para um servidor NAS que possivelmente terá apenas quatro serviços rodando e o RAID.
A escolha do BTRFS foi pessoal pelo o motivo de eu conhecer esse sistema muito bem, acredito ZSF seja mais robusto.

Os próximos passos envolvem:

  • Criação de um script Bash para rotinas de snapshots
  • Agendamento via Cron de snapshots
  • Configuração do serviço NFS para compartilhamento de arquivos Linux
  • Configuração do serviço SMB para compartilhamento de arquivos Windows
  • Configuração do UFW para mais segurança a ataques hackers