Skip to content
CPPS Docs

LINSTOR SP

LINSTOR — Cluster SP NVMe (planejado)

Status: cluster NVMe planejado, NAO deployado ainda. Este doc descreve a topologia alvo do cluster nvme-pool em pve-ippri-31/33/34.

O cluster SP em producao hoje e o SSD: pve-ippri-11/12/31, pool ssd-pool (LVM_THIN sobre linstor_ssd/thinpool), VIP 10.10.10.1. Para topologia atual, ver linstor-conceitos.md#pools-no-sp. Para conceitos gerais e troubleshooting, ver linstor-conceitos.md. Para decisoes de arquitetura, storage-strategy.md.

O que e LINSTOR

LINSTOR e um sistema de storage distribuido que gerencia volumes replicados via DRBD. Em termos simples: cria discos virtuais que existem simultaneamente em 2+ nodes, sincronizados em tempo real. Se um node cai, o disco continua acessivel no outro.

Por que usar

Sem LINSTOR, cada VM vive no disco local de 1 node. Se o node cai, a VM fica inacessivel ate o node voltar. Live migration entre nodes tambem nao funciona (o disco nao esta disponivel no destino).

Com LINSTOR + DRBD:

  • Alta disponibilidade: VM continua rodando mesmo se 1 node cair
  • Live migration: mover VMs entre nodes sem downtime (o disco ja esta replicado)
  • Thin provisioning: disco de 100G so ocupa espaco conforme dados sao escritos
  • Integrado com Proxmox: aparece como storage nativo na UI

Como funciona (simplificado)

                    LINSTOR Controller (gerencia metadados)
                    ┌───────────────────────────────────┐
                    │ Sabe onde cada volume esta,       │
                    │ quantas replicas, em quais nodes   │
                    └───────────┬───────────────────────┘
                                │
              ┌─────────────────┼─────────────────┐
              ▼                 ▼                  ▼
        ┌──────────┐     ┌──────────┐      ┌──────────┐
        │ ippri-31 │     │ ippri-33 │      │ ippri-34 │
        │ Satellite│     │ Satellite│      │ Satellite│
        │          │     │          │      │          │
        │ NVMe 1 ──┤     │ NVMe 1 ──┤      │ NVMe 1 ──┤
        │ NVMe 2 ──┤     │ NVMe 2 ──┤      │ NVMe 2 ──┤
        │ 7.2 TiB  │     │ 7.2 TiB  │      │ 7.2 TiB  │
        └──────────┘     └──────────┘      └──────────┘
              │                 │                  │
              └────── DRBD ────┴──── DRBD ────────┘
                   (replicacao sincrona via 10.10.20.0/24)

Quando uma VM escreve no disco:

  1. A escrita vai para o NVMe local (rapido)
  2. DRBD replica a escrita para o 2° node via rede dedicada (sincrono)
  3. So confirma a escrita quando ambos nodes gravaram
  4. Se 1 node cai, o outro tem copia identica — sem perda de dados desde que pelo menos 1 peer estivesse UpToDate no momento da queda

Topologia do Cluster SP NVMe (planejado)

Este cluster nao esta deployado. Os IPs de rede LINSTOR (10.10.20.x) ainda nao foram aplicados — a decisao final entre coexistir com a rede do cluster SSD (10.10.10.x) ou usar uma rede paralela e parte do design pendente.

Nodes

NodeIP principalIP LINSTOR (planejado)NVMePoolPapel
pve-ippri-31192.168.10.3110.10.20.312x 3.6T7.2 TiBCombined (controller + satellite)
pve-ippri-33192.168.10.3310.10.20.332x 3.6T7.2 TiBCombined (controller + satellite)
pve-ippri-34192.168.10.3410.10.20.342x 3.6T7.2 TiBCombined (controller + satellite)

Nota: pve-ippri-31 ja participa do cluster SSD em producao (em 10.10.10.31). O design precisa decidir se o NVMe pool reusa a mesma interface 10G do SSD ou se ganha NIC separada.

Capacidade

Raw total:         21.6 TiB (6x 3.6T NVMe)
Com replicacao 2x: 10.8 TiB efetivos
Com replicacao 3x:  7.2 TiB efetivos (se configurado)

Rede dedicada

Subnet:    10.10.20.0/24
Interface: enp5s0f0 (ippri-31), enp5s0f1 (ippri-33), TBD (ippri-34)
Uso:       Exclusivo para replicacao DRBD (nao passa trafego de gestao/VMs)

Separar a rede e critico — replicacao DRBD e trafego intenso (cada escrita de VM gera trafego de rede). Se usasse a rede principal (192.168.10.x), saturaria a rede de gestao e a UI do Proxmox ficaria lenta.

Camadas de Storage

Entender as camadas ajuda a debugar problemas:

┌─────────────────────────────────────────────┐
│ Proxmox (cria VMs com disco "linstor-ssd-01") │  ← UI/API do Proxmox
├─────────────────────────────────────────────┤
│ LINSTOR (gerencia volumes, replicas, nodes) │  ← linstor CLI
├─────────────────────────────────────────────┤
│ DRBD (replicacao sincrona entre nodes)      │  ← drbdadm / /proc/drbd
├─────────────────────────────────────────────┤
│ LVM thin pool (thin provisioning local)     │  ← lvs, vgs
├─────────────────────────────────────────────┤
│ NVMe fisico (/dev/nvme0n1, /dev/nvme1n1)   │  ← hardware
└─────────────────────────────────────────────┘

Storage por Node (detalhado)

Em cada node, os 2 NVMe sao combinados em 1 Volume Group (VG) do LVM:

/dev/nvme0n1 (3.6T) ─── pvcreate ──┐
                                     ├── VG "linstor_nvme" ── LV "thinpool" (thin)
/dev/nvme1n1 (3.6T) ─── pvcreate ──┘

Nomenclatura: o cluster SSD em producao usa VG linstor_ssd (ja deployado). O cluster NVMe planejado deve usar VG linstor_nvme para diferenciacao clara — escolher antes de provisionar.

Por que 1 VG com 2 PVs (e nao 2 VGs separados)?

  • Simplicidade: LINSTOR gerencia 1 pool por node, nao 2
  • Flexibilidade: volumes podem usar espaco de qualquer NVMe
  • Sem RAID: nao e RAID 0 (stripe). LVM aloca extents linearmente. Se quiser stripe para mais throughput, usar --stripes 2 no lvcreate. Mas para VMs, throughput de 1 NVMe (~3 GB/s) ja e mais que suficiente.

Por que LVM_THIN (e nao LVM normal)?

  • Thin provisioning: VM com disco de 200G ocupa so o espaco real dos dados (ex: 30G)
  • Overcommit: pode alocar mais capacidade logica que fisica (ex: 15 TiB logico em 7.2 TiB fisico)
  • Snapshots: copy-on-write, eficiente para backups
  • Padrao LINBIT: recomendado oficialmente para LINSTOR

Replicacao e Alta Disponibilidade

place_count = 2

Cada volume (disco de VM) e replicado em 2 nodes. O 3° node atua como TieBreaker (sem dados, so voto de desempate em caso de split-brain).

Exemplo: VM com disco de 100G


  ippri-31: [dados 100G]  ← replica 1 (leitura/escrita)
  ippri-33: [dados 100G]  ← replica 2 (sincrono)
  ippri-34: [TieBreaker]  ← sem dados, so metadata de voto

Cenarios de falha

CenarioImpactoRecuperacao
1 node caiSem downtime de VM (DRBD continua no outro peer com UpToDate)Node volta, DRBD resincroniza incrementalmente via activity log
2 nodes caemVM trava I/O (on-no-quorum: io-error) ate 1 voltarEsperar 1 node voltar — sem perda, mas indisponibilidade
NVMe falha em 1 nodeSem perda de dados se a replica esta UpToDate no peerTrocar NVMe, recriar VG/pool, LINSTOR ressyncroniza
Rede LINSTOR cai entre nodesDRBD detecta peer disconnect, lado minoritario perde quorumLado com quorum continua; lado isolado bloqueia I/O. Quando rede volta, resync incremental. Ver troubleshooting de split-brain em linstor-conceitos.md

Live Migration

Com LINSTOR, live migration de VMs no Proxmox funciona nativamente:

  1. Admin clica “Migrate” na UI (ou qm migrate)
  2. Proxmox verifica que o disco esta replicado no destino (DRBD ja tem os dados)
  3. Copia so a RAM da VM (~ms de downtime)
  4. VM continua rodando no novo node

Sem LINSTOR, migracao exige copiar o disco inteiro pela rede (horas para discos grandes).

Comparacao com Franca

AspectoFranca (existente)SP (novo)
Nodes4 satellites + 3 controllers3 combined
Rede10.10.20.0/2410.10.20.0/24
NVMe por node1x 3.6T2x 3.6T
Total raw~13 TiB~21.6 TiB
Efetivo (2x)~6.5 TiB~10.8 TiB
Controller HA3 controllers (quorum)3 combined (quorum)
Cross-siteNao (latencia WAN)Nao

Operacao

Comandos frequentes

Terminal window
# Ver todos os nodes e seu estado
linstor node list


# Ver storage pools (capacidade, uso)
linstor storage-pool list


# Ver todos os volumes/resources
linstor resource list


# Ver estado DRBD (replicacao)
drbdadm status all


# Criar volume manualmente (normalmente via Proxmox UI)
linstor resource-group spawn-resources sp-nvme-replicated meu-volume 100G


# Ver resource groups
linstor resource-group list


# Ver storage no Proxmox
pvesm status

Monitoramento

Terminal window
# DRBD sync status (deve mostrar UpToDate em todos)
cat /proc/drbd


# Espaco thin pool (cluster SSD em producao usa linstor_ssd; o NVMe planejado seria linstor_nvme)
lvs -o lv_name,lv_size,data_percent linstor_ssd/thinpool


# I/O no DRBD
drbdsetup events2 --statistics --now

Troubleshooting (resumo)

ProblemaDiagnostico inicialOnde resolver
Node “OFFLINE” no linstor node listVerificar rede LINSTOR, systemctl status linstor-satelliteReiniciar satellite ou diagnosticar conectividade. Mais detalhes: linstor-conceitos.md#manutencao
Resource “Inconsistent”drbdadm status mostra estado e progressoGeralmente sync em curso apos reboot/reconnect — aguardar. Se travado, ver troubleshooting profundo (TBD)
Thin pool > 80%lvs linstor_ssd/thinpool (ou linstor_nvme/thinpool)Expandir VG/thinpool, limpar volumes orfaos, ou ajustar MaxOversubscriptionRatio
Split-braindrbdadm status mostra StandAlone ou Connecting em ambos os ladosNao tentar disconnect/connect direto sem analise. Procedimento completo (--discard-my-data, escolha do lado perdedor) em linstor-conceitos.md#split-brain-o-que-e-e-como-recuperar
Controller inalcancavellinstor node list falhaVerificar VIP, controller ativo, journalctl -u linstor-controller. Em SP o VIP e 10.10.10.1

Pre-requisitos para Instalacao

  • PVE 9 nos 3 nodes (em andamento — ippri-31, 33)
  • PVE 9 no ippri-34
  • Destruir ZFS pools nos NVMe do ippri-33 e ippri-34
  • Configurar rede 10.10.20.34 no ippri-34
  • Migrar/redimensionar VM desktop do ippri-34 (liberar RAM)

Instalacao via Ansible

Terminal window
# Instalar LINSTOR nos 3 nodes SP
make pve-linstor TARGET=linstor_sp


# Ou node individual (debug/teste)
make pve-linstor TARGET=pve-ippri-31

O playbook e idempotente — pode rodar varias vezes sem efeito colateral.

Arquivos relevantes

inventory/hosts.yaml                    ← grupo linstor_sp com vars por host
config/roles/linstor/defaults/main.yaml ← valores padrao (documentados)
config/roles/linstor/tasks/main.yaml    ← tasks (5 fases, documentadas)
config/proxmox/linstor.yaml             ← playbook orquestrador
docs/linstor-sp.md                      ← este documento

Migracao de storage ID em producao (linstor-ssd → linstor-ssd-01)

Procedimento para renomear o storage Proxmox do nome legado linstor-ssd para a convencao escalavel linstor-ssd-01. Faz parte da janela de renumeracao SP (decisao caminho B). A operacao mexe em VMs ativas — exige janela de manutencao curta (~15-30min) e cuidado com snapshots.

Pre-requisitos

  • Branch feat/renumeracao-sp ja aplicado (codigo + scripts apontando para novo nome)
  • Backup VyOS feito (ver backup-vyos-sp.md)
  • Snapshot Proxmox de cada VM critica que usa linstor-ssd

Passos

  1. Inventariar VMs que usam o storage:

    Terminal window
    for vmid in $(qm list | awk 'NR>1 {print $1}'); do
      if qm config "$vmid" 2>/dev/null | grep -q "linstor-ssd:"; then
        echo "VM $vmid usa linstor-ssd"
      fi
    done

  2. Adicionar novo storage ID apontando pro mesmo LINSTOR pool (Proxmox aceita 2 storages backend para o mesmo pool sem conflito):

    Terminal window
    pvesm add drbd linstor-ssd-01 \
      --resourcegroup sp-ssd-replicated \
      --controller 10.10.10.1 \
      --content images,rootdir

    Validar:

    Terminal window
    pvesm status | grep linstor
    # linstor-ssd     drbd  active  ...
    # linstor-ssd-01  drbd  active  ...  (novo)

  3. Para cada VM, atualizar refs no qm config (sem precisar mover dados — so muda o nome do backend):

    Terminal window
    for vmid in <VMIDs identificados no passo 1>; do
      # Para cada disco scsiN/virtioN/ideN que usa linstor-ssd:
      # Editar /etc/pve/qemu-server/<vmid>.conf substituindo
      #   "linstor-ssd:vm-<vmid>-disk-<N>"
      # por
      #   "linstor-ssd-01:vm-<vmid>-disk-<N>"
      #
      # Idealmente com sed (atomico via pmxcfs):
      sed -i 's|linstor-ssd:vm-|linstor-ssd-01:vm-|g' \
        /etc/pve/qemu-server/${vmid}.conf
    done

    Nota: editar /etc/pve/qemu-server/*.conf em VM running e seguro — pmxcfs replica atomicamente. A VM continua usando o disco DRBD ativo (so o nome no config muda; o LV thin pool DRBD subjacente e o mesmo).

  4. Validar que VMs respondem:

    Terminal window
    qm list  # todas as VMs reportadas
    for vmid in <lista>; do
      qm status "$vmid"  # running esperado
    done

  5. Remover storage antigo (so depois de validar todas as VMs):

    Terminal window
    pvesm remove linstor-ssd

  6. Validar scripts atualizados:

    Terminal window
    bash config/scripts/linstor-healthcheck.sh
    # Deve reportar "linstor-ssd-01 ativo no Proxmox"

Rollback

Se algo der errado nos passos 2-5, reverter o qm config para linstor-ssd: e remover o storage linstor-ssd-01. O storage antigo continua ativo enquanto nao for explicitamente removido.

Por que essa abordagem (vs alternativas)

  • Renomear /etc/pve/storage.cfg direto: rapido, mas Proxmox cacheia metadados — pode ficar inconsistente. Adicionar+remover e mais limpo.
  • Mover dados (DRBD): desnecessario — o storage backend so muda de nome, o pool LINSTOR e os volumes DRBD permanecem identicos.
  • Esperar uma janela separada: aceita inconsistencia entre codigo (linstor-ssd-01) e producao (linstor-ssd). Nao recomendado — scripts ja atualizados quebrariam.