Rede 10G — SP

Rede 10G — SP (LINSTOR/DRBD)

Rede dedicada 10 Gbps para replicacao DRBD entre os nodes Proxmox de SP. Usada exclusivamente pelo LINSTOR para replicacao sincrona de discos de VMs.

Detalhes dos switches (UniFi US-16-XG, USW Pro Aggregation, TP-Link SG2218), UniFi Controller, mapa de portas, acesso via terminal e runbooks de migracao: ver switches-sp.md.

Topologia

ippri-31 (controller UniFi, 10.10.20.31/24 em bond1)
        │
        │ LAG 1 = 2×10G = 20 GbE
        │ (enp5s0f0+enp5s0f1 → XG 15+16)
        ▼
   US-16-XG  ─── LAG 3 (11+12) ──── ippri-32 (bond1) 10.10.20.32
   10.10.20.2 ─── LAG 4 (13+14) ──── ippri-33 (bond1) 10.10.20.33
        │
        │ LAG 2 = 3×10G = 30 GbE
        │ (XG 2/4/6 ↔ Pro Agg 26/27/28)
        ▼
  USW Pro Aggregation ─── port 23 ─── ippri-11 (ens3f0) 10.10.20.11
  10.10.20.3          ─── port 25 ─── ippri-12 (ens6f1) 10.10.20.12

Enderecamento

Node	Interface	IP	Tipo	Switch	Porta
pve-ippri-11	ens3f0	10.10.20.11/24	standalone	USW Pro Agg	23
pve-ippri-12	ens6f1	10.10.20.12/24	standalone	USW Pro Agg	25
pve-ippri-31	bond1 (enp5s0f0+enp5s0f1)	10.10.20.31/24	LACP 802.3ad	US-16-XG	15+16 (LAG 1)
pve-ippri-32	bond1	10.10.20.32/24	LACP 802.3ad	US-16-XG	11+12 (LAG 3)
pve-ippri-33	bond1 (enp5s0f0+enp5s0f1)	10.10.20.33/24	LACP 802.3ad	US-16-XG	13+14 (LAG 4)

LAGs

LAG	Extremos	Portas (switch-side)	Throughput
LAG 1	ippri-31 bond1 ↔ US-16-XG	XG 15, 16	2×10G = 20 Gbps
LAG 2	USW Pro Agg ↔ US-16-XG	Pro Agg 26/27/28 ↔ XG 2/4/6	3×10G = 30 Gbps
LAG 3	ippri-32 bond1 ↔ US-16-XG	XG 11, 12	2×10G = 20 Gbps
LAG 4	ippri-33 bond1 ↔ US-16-XG	XG 13, 14	2×10G = 20 Gbps

Todos em LACP 802.3ad (xmit_hash_policy layer3+4 no bond). Detalhes de portas por switch em switches-sp.md.

NICs dos nodes

pve-ippri-11

Interface	Driver	Tipo	Max	Uso
eno1	igb	RJ45	1G	vmbr1 (management)
eno2	igb	RJ45	1G	vmbr0
ens1	r8169	RJ45	1G	vmbr3 (sem uso)
ens3f0	bnx2x (BCM57810)	RJ45	10G	LINSTOR 10.10.20.11
ens3f1	bnx2x (BCM57810)	RJ45	10G	sem uso

pve-ippri-12

Interface	Driver	Tipo	Max	Uso
eno1	tg3	RJ45	1G	vmbr0 (down)
eno2	tg3	RJ45	1G	vmbr1 (management)
ens2	r8169	RJ45	1G	sem uso
ens6f0	qlcnic	SFP+	10G	sem uso
ens6f1	qlcnic	SFP+	10G	LINSTOR 10.10.20.12

pve-ippri-31

Interface	Driver	Tipo	Max	Uso
enp5s0f0	bnx2x (BCM57810)	RJ45	10G	bond1 slave (LINSTOR)
enp5s0f1	bnx2x (BCM57810)	RJ45	10G	bond1 slave (LINSTOR)
enp6s0f0	igb	RJ45	1G	sem uso
enp6s0f1	igb	RJ45	1G	sem uso
enp8s0	—	RJ45	1G	desativada 2026-04-20 (era mgmt do XG em 192.168.11.19)
enp9s0	—	RJ45	1G	vmbr1 (management)

Performance medida (iperf3)

Rota	Velocidade	Retransmissoes
ippri-11 ↔ ippri-12	9.09 Gbps	0
ippri-31 → ippri-11	9.40 Gbps	0
ippri-12 → ippri-31	9.20 Gbps (pico)	369
ippri-31 → ippri-12	8.09 Gbps	718

As retransmissoes no caminho ippri-12 ↔ ippri-31 sao normais — o trafego passa por 2 switches com LAG. O throughput efetivo de 8-9 Gbps e mais que suficiente para DRBD com SSDs.

UniFi Controller e acesso aos switches

Gerencia dos switches UniFi via controller self-hosted em pve-ippri-31. Acesso, instalacao, mca-cli-op, migracao de mgmt e troubleshooting dos switches documentados em switches-sp.md.

UniFi Web UI: https://192.168.10.31:8443 (LAN) — https://10.10.20.31:8443 (10G)
Inform URL atual dos switches: http://10.10.20.31:8080/inform
Bug VLAN 1 tagged nos LAGs: resolvido 2026-04-21 (Native VLAN = default) — ver historico em switches-sp.md.

Verificar estado da rede 10G

# Nos nodes:
ethtool ens3f0                  # ippri-11
ethtool ens6f1                  # ippri-12
cat /proc/net/bonding/bond1     # ippri-31, ippri-32

# O que procurar no bond:
#   Number of ports: 2
#   Partner Mac Address: 74:83:c2:07:05:25  (MAC do US-16-XG)
#   Partner Churn State: monitoring ou none (nunca 'churned')

# Teste de velocidade:
iperf3 -s -D --bind 10.10.20.X   # no destino
iperf3 -c 10.10.20.X -t 10       # na origem

Verificacao no switch-side e troubleshooting de LAG/LACP/STP: ver switches-sp.md.

LINSTOR Cluster

Componentes

Componente	Descricao
Controller	Gerencia metadados (qual volume esta onde, replicacao). 1 ativo por vez
Satellite	Gerencia storage local (SSDs, LVM thin pool). Ativo nos 3 nodes
DRBD	Replicacao sincrona de discos entre nodes via rede 10G
drbd-reactor	Monitora DRBD e gerencia failover automatico do controller

Storage

Node	Devices	VG	Thin Pool	Capacidade
pve-ippri-11	/dev/sdd, /dev/sde	linstor_ssd	thinpool	3.46 TiB
pve-ippri-12	/dev/sdb, /dev/sdc	linstor_ssd	thinpool	3.46 TiB
pve-ippri-31	/dev/sdc, /dev/sdd	linstor_ssd	thinpool	3.46 TiB

Raw total: ~10.38 TiB
Efetivo (replicacao 2x): ~5.19 TiB
Resource group: sp-ssd-replicated, PlaceCount 2
Proxmox storage: linstor-ssd-01

Controller HA

O controller roda em 1 node por vez. O DB esta num volume DRBD (linstor_db) replicado nos 3 nodes. O failover e automatico via drbd-reactor.

                    Controller DB (DRBD linstor_db, 500MB)
                    Replicado nos 3 nodes
                    ┌─────────────────────────────┐
                    │    Só 1 node é Primary       │
                    │    VIP: 10.10.20.1           │
                    └─────────────┬───────────────┘
                                  │
              ┌───────────────────┼───────────────────┐
              ▼                   ▼                    ▼
        ┌──────────┐       ┌──────────┐        ┌──────────┐
        │ ippri-11 │       │ ippri-12 │        │ ippri-31 │
        │ COMBINED │       │ COMBINED │        │ COMBINED │
        │ Satellite│       │ Satellite│        │ Satellite│
        │ SSD 3.46T│       │ SSD 3.46T│        │ SSD 3.46T│
        └──────────┘       └──────────┘        └──────────┘

VIP (IP Virtual): 10.10.20.1 — sempre aponta para o node com controller ativo. Todos os clients (linstor-client, Proxmox plugin) usam o VIP.

Servicos por node:

Servico	Funcao	Estado
linstor-satellite	Storage local	Sempre ativo nos 3
linstor-controller	Gestao do cluster	Ativo no node Primary
drbd-reactor	Monitora DRBD, promove/demote	Sempre ativo nos 3
linstor-vip	IP virtual 10.10.20.1	Ativo no node Primary

Configs:

Arquivo	Conteudo
/etc/linstor/linstor-client.conf	`controllers=10.10.20.1` (VIP)
/etc/pve/storage.cfg	`controller 10.10.20.1`
/etc/drbd-reactor.d/linstor-controller.toml	Promoter: mount + VIP + controller
/etc/systemd/system/linstor-vip.service	Adiciona/remove VIP na interface
/etc/drbd.d/linstor_db.res	Config DRBD manual (minor 999, auto-promote=no)
/etc/cron.d/linstor-backup	Backup DB a cada 30min (retencao 7 dias)

Fluxo de failover (automatico)

1. Node com controller cai (ex: ippri-11)
   │
2. DRBD detecta perda do peer, verifica quorum (2/3 vivos = OK)
   │
3. drbd-reactor no ippri-12 ou ippri-31 promove linstor_db para Primary
   │
4. Sequencia automatica (drbd-reactor promoter):
   ├── mount /var/lib/linstor (DB no DRBD)
   ├── ativa linstor-vip.service (VIP 10.10.20.1 na interface local)
   └── inicia linstor-controller
   │
5. Todos os clients continuam acessando 10.10.20.1 (VIP)
   │
6. Proxmox HA detecta node down (~30s)
   └── reinicia VMs do node caido em outro node
       (disco ja replicado via DRBD, sem copiar dados)

Quando o node volta:

Satellite reconecta ao controller (via VIP)
DRBD resincroniza automaticamente os dados
Controller NÃO volta para o node original (evita ping-pong)
O controller so migra se o node atual cair

Proxmox HA e modos de operacao

Todas as VMs podem usar o storage linstor-ssd-01 (disco replicado via DRBD). O HA e opcional e configurado por VM — voce escolhe individualmente quais VMs tem failover automatico e quais sao manuais.

Modo 1: VM com HA (automatica)

Disco no linstor-ssd-01 (replicado em 2 nodes)
Adicionada ao Proxmox HA
Se o node cai: VM reinicia automaticamente em outro node (~1-2 min)
Live migration funciona (disco ja replicado, so copia RAM)
Ideal para: servidores de producao, servicos criticos

# Adicionar VM ao HA
ha-manager add vm:<VMID> --state started --max-restart 3 --max-relocate 2

# Restringir aos nodes LINSTOR
ha-manager rules add node-affinity linstor-nodes \
  --nodes pve-ippri-11,pve-ippri-12,pve-ippri-31 \
  --strict 1 \
  --resources vm:<VMID> \
  --comment "VMs LINSTOR: apenas nodes com storage linstor-ssd-01"

Ou pela web UI: Datacenter → HA → Add → selecionar VM

Modo 2: VM sem HA (manual)

Disco no linstor-ssd-01 (replicado igualmente!)
NAO adicionada ao Proxmox HA
Se o node cai: VM para, mas o disco continua seguro no outro node
Voce decide quando e onde reiniciar manualmente
Live migration funciona normalmente (sob demanda)
Ideal para: desktops, VMs de teste, workloads GPU que precisam de node especifico

Para usar este modo: basta criar a VM com storage linstor-ssd-01 e NAO adicionar ao HA.

Comparacao

Aspecto	Com HA	Sem HA
Storage	linstor-ssd-01 (DRBD)	linstor-ssd-01 (DRBD)
Disco replicado	Sim (2 nodes)	Sim (2 nodes)
Protecao contra perda de dados	Sim	Sim
Live migration	Sim (automatica ou manual)	Sim (manual)
Node cai → VM reinicia	Automatico (~1-2 min)	Manual (voce decide)
GPU passthrough	Dificil (HA pode migrar para node sem GPU)	Ideal (voce controla o node)
Exemplo de uso	Servidor web, banco de dados	Desktop remoto, ML com GPU

Os dois modos convivem no mesmo cluster e no mesmo storage sem conflito.

Cenarios de falha:

Cenario	VMs HA no node caido	VMs manuais no node caido	VMs nos outros nodes	Controller
1 node cai	Reiniciam em outro node	Param (aguardam acao manual)	Continuam rodando	Migra automaticamente
2 nodes caem	Param (sem quorum)	Param (sem quorum)	Para
Rede 10G cai	DRBD pausa replicacao	Continuam (dados locais)	Pode perder acesso

Manutencao programada

Desligar 1 node

# 1. Migrar VMs para outro node (live migration, sem downtime)
qm migrate <VMID> <destino> --online

# 2. Verificar que nao ha VMs rodando
qm list

# 3. Desligar
shutdown -h now

# Ao religar: satellite reconecta, DRBD resincroniza automaticamente

Desligar 2 nodes

# 1. Migrar TODAS as VMs para o node que vai ficar ligado
qm migrate <VMID> <destino> --online

# 2. Desligar o node SEM controller primeiro
ssh root@<node-sem-controller> shutdown -h now

# 3. Desligar o node COM controller
#    O ultimo node fica sem quorum — VMs rodando continuam,
#    mas nao da para criar/mover volumes

# Ao religar: ligar os 2 nodes, aguardar DRBD resincronizar

Desligar os 3 nodes (manutencao completa)

# 1. Parar todas as VMs
qm shutdown <VMID>     # para cada VM

# 2. Verificar quem e o controller (onde esta o VIP)
ip addr show | grep 10.10.20.1

# 3. Desligar na ordem:
#    a) Nodes SEM controller primeiro
#    b) Node COM controller por ultimo

# 4. Religar na ordem INVERSA:
#    a) Node que era controller primeiro
#    b) Aguardar DRBD linstor_db ficar UpToDate
#    c) Verificar controller: linstor node list
#    d) Ligar os outros nodes
#    e) Aguardar: drbdadm status all (todos UpToDate)
#    f) Iniciar VMs

# 5. Verificacao pos-manutencao:
linstor node list              # 3 nodes Online
linstor storage-pool list      # ssd-pool Ok nos 3
linstor resource list          # todos UpToDate
drbdadm status all             # UpToDate em todos
pvesm status | grep linstor    # active
ha-manager status              # quorum OK

Operacao

# Ver estado do cluster
linstor node list
linstor storage-pool list
linstor resource list

# Ver quem e o controller (onde esta o VIP)
ip addr show | grep 10.10.20.1

# Ver estado DRBD
drbdadm status all

# Ver estado HA Proxmox
ha-manager status

# Testar velocidade entre nodes
iperf3 -s -D --bind 10.10.20.X   # no destino
iperf3 -c 10.10.20.X -t 10       # na origem

Troubleshooting LINSTOR

Problema	Diagnostico	Solucao
Controller offline	`systemctl status linstor-controller` nos 3 nodes	drbd-reactor deve promover automaticamente. Se nao, verificar `journalctl -u drbd-reactor`
VIP nao migrou	`ip addr show \| grep 10.10.20.1` nos 3 nodes	`systemctl restart drbd-reactor` no node Primary
Node OFFLINE no linstor	`linstor node list`	Verificar satellite: `systemctl status linstor-satellite`
Resource Inconsistent	`drbdadm status all`	Aguardar sync. Se persistir: `drbdadm connect <resource>`
Proxmox storage inactive	`pvesm status`	Verificar VIP e controller: `linstor --controllers=10.10.20.1 node list`
DRBD 8.x carregado em vez de 9.x	`cat /proc/drbd` (mostra 8.4.x)	`rmmod drbd && modprobe drbd` e reiniciar satellite
Minor conflict linstor_db	`drbdadm up linstor_db` falha com “minor already in use”	linstor_db usa minor 999 fixo. Se LINSTOR alocar 999, trocar no .res e recriar metadata

DRBD linstor_db — detalhes tecnicos

O recurso linstor_db e gerenciado manualmente (fora do LINSTOR controller) porque ele armazena o proprio banco de dados do controller.

Arquivo .res:    /etc/drbd.d/linstor_db.res  (NAO /var/lib/linstor.d/ — satellite apaga)
Minor:           999 (fixo, fora do range 1000+ alocado pelo LINSTOR)
Porta:           7790
Backing device:  /dev/linstor_ssd/linstor_db (LV thin 500MB)
Filesystem:      ext4
Mount point:     /var/lib/linstor (via var-lib-linstor.mount)
Replicacao:      3 nodes, protocol C, quorum majority
connection-mesh: pve-ippri-11, pve-ippri-12, pve-ippri-31

Importante: O .res deve ficar em /etc/drbd.d/ e NAO em /var/lib/linstor.d/. O satellite do LINSTOR regenera /var/lib/linstor.d/*.res a partir do controller DB e apaga qualquer arquivo que nao corresponda a um recurso gerenciado.

Backup do controller DB

Cron em /etc/cron.d/linstor-backup nos 3 nodes (so executa no node com controller ativo):

Frequencia: a cada 30 minutos
Destino: /var/lib/linstor/backups/linstordb.mv.db.YYYYMMDD-HHMM
Retencao: 7 dias (backups mais antigos sao removidos automaticamente)
Tamanho: DB ~800KB, ~48 backups/dia = ~38MB/dia

Restaurar backup:

# 1. Parar controller
systemctl stop linstor-controller

# 2. Copiar backup
cp /var/lib/linstor/backups/linstordb.mv.db.<timestamp> /var/lib/linstor/linstordb.mv.db

# 3. Reiniciar controller
systemctl start linstor-controller