LINSTOR — conceitos operacionais

Resumo pratico sobre LINSTOR/DRBD aplicado aos clusters SP e Franca. Complementa rede-sp.md (topologia) e storage-strategy.md (decisoes de arquitetura: por que LVM_THIN, cross-site SP↔Franca, alternativas).

O que e LINSTOR

LINSTOR e um orquestrador de storage replicado. Abaixo dele roda DRBD (block-level replication no kernel Linux). O modelo mental:

DRBD = “RAID 1 pela rede” — bloco a bloco, sincrono
LINSTOR = painel de controle que gerencia quais blocks vao em quais nodes

Nao e tipo ZFS (dado “mora” num node). E mais parecido com SAN — um volume logico acessivel por qualquer node autorizado.

Componentes

Componente	O que faz
Controller	Cerebro — metadados, API, decisoes de placement. Roda em 1-3 nodes (HA)
Satellite	Agente em cada node — cria LVs, gerencia DRBD local
Storage pool	Pool de espaco (LVM thin, ZFS, etc.) que satellite gerencia
Resource group	Template — define place_count, que pool usar, quais nodes candidatos
Resource	Instancia — o volume real (ex: disco de uma VM)

No SP temos controller HA em VIP 10.10.10.1 (rede LINSTOR dedicada).

Pools no SP

Estado atual (em producao):

Pool	Nodes	VG/Pool	Rede	Uso
`ssd-pool`	pve-ippri-11, 12, 31	`linstor_ssd/thinpool`	10.10.10.0/24	Ativo, todas VMs criticas
`DfltDisklessStorPool`	todos os COMBINED	(sem disco)	—	Default LINSTOR

Planejado (cluster NVMe expandindo o servico — ver linstor-sp.md):

Pool	Nodes	Status
`nvme-pool`	pve-ippri-31, 33, 34	nao deployado

Resource groups em producao:

sp-ssd-replicated — PlaceCount: 2, StoragePool(s): ssd-pool, ReplicasOnDifferent: ['Aux/Aux/floor']
DfltRscGrp — default, PlaceCount: 2

Modos de presenca de um resource num node

Um resource (volume) pode ter 3 representacoes num node:

1. Diskful (UpToDate)

Tem copia fisica completa do volume no pool local
Le do disco local (rapido)
Recebe writes pela rede e escreve no disco
Custo: espaco fisico

2. TieBreaker

Volume “diskless” mas participa de quorum (votacao)
Nao consome espaco significativo (~4 MiB)
Serve so pra evitar split-brain quando so tem 2 peers diskful

3. Diskless

Sem copia fisica — cliente DRBD puro
Le/escreve pela rede em peers diskful
Cria-se em milisegundos (so metadados)
Consume zero espaco

Writes sao sempre sincronos em todos os diskful

VM faz write
    |
    v
DRBD no node da VM
    |
    +--> disco local (se diskful) -----+
    +--> rede --> peer 1 diskful ------|
    +--> rede --> peer 2 diskful ------|
                                       |
    <------ ACK de todos <-------------+
    |
    v
Write completa

Implicacoes:

Write e tao lento quanto o peer mais lento
Misturar NVMe + SSD no mesmo pool = performance de SSD em writes
Rede 10G saturada = catastrofe (fallback pra 1G devastador)

Reads sao locais (quando possivel)

Node diskful: le do proprio disco
Node diskless: pede pra um peer diskful (sempre pela rede)

Live migration entre nodes

Sem LINSTOR (ZFS local): precisa mandar o disco todo pelo wire — minutos/horas.

Com LINSTOR: disco ja “esta” em todos os nodes que participam do cluster. So migra RAM/CPU.

Para node sem replica ainda (ex: migrar para node diskless novo)

LINSTOR cria diskless replica no destino (~50ms, zero dados)
DRBD client conecta aos peers diskful via rede
Proxmox vive-migrate a VM (RAM)
Pronto — VM agora roda no novo node, I/O vai pela rede

Se habilitar auto-diskless no Proxmox plugin, o passo 1 e automatico.

Mistura de storage types e tamanhos

Tamanhos diferentes no mesmo pool

Nao e problema — LINSTOR aloca por volume, respeitando espaco disponivel. Um volume de 2 TiB nao vai para um node com pool de 1 TiB.

Unico cuidado: thin provisioning pode mascarar superprovisionamento.

NVMe + SSD no mesmo pool

Funciona, mas:

Writes: velocidade do mais lento (SSD)
Reads: node NVMe le rapido local; node SSD le rapido local; diskless le pela rede
Sem ganho claro de performance

Melhor: pools separados com resource groups diferentes, workloads escolhem.

Pools conversam entre si

Um resource group pode listar multiplos pools:

StoragePool(s): ssd-pool, nvme-pool

LINSTOR escolhe 2 nodes que tenham qualquer desses pools. Pode colocar uma replica em ssd-pool de ippri-11 e outra em nvme-pool de ippri-32.

Resiliencia: quorum e split-brain

Por que quorum existe

DRBD/LINSTOR e CP em CAP — prefere parar I/O a aceitar dados divergentes. Quorum e o mecanismo que decide qual lado de uma particao tem direito de escrever.

Sem quorum, dois lados de uma particao podem virar primary simultaneamente. Quando a rede se reconecta, dados divergiram e DRBD precisa descartar um lado (perda silenciosa).

O cenario “particao parece morte”

DRBD nao tem como saber, do ponto de vista de um node, se a rede caiu ou se os outros nodes morreram. Os sintomas sao identicos: peers param de responder.

Estado normal:
  A <==> B <==> C        todos se enxergam
  primary  secondary  tiebreaker

Cabo de A solta (mas A continua vivo):
  A          B <==> C    A acha que B,C morreram
                         B,C acham que A morreu

Sem quorum, A continua aceitando writes em primary. B/C podem promover B a primary tambem (HA). Os dois aceitam writes diferentes. Quando rede volta — split-brain.

Com quorum (maioria de 3 = 2):

A sozinho: 1/3 nao e maioria → A bloqueia I/O (io-error)
B+C juntos: 2/3 e maioria → B vira primary, aceita writes
Quando A volta: A vira secondary, sincroniza de B (sem perda)

Formula da maioria estrita

Votantes	Quorum	Tolerancia a falhas
2	2	0 (qualquer falha trava)
3	2	1
4	3	1 (mesma do 3 — par nao ajuda)
5	3	2
7	4	3

Numero impar e sempre mais eficiente.

Duas camadas de quorum

DRBD aplica quorum em dois lugares independentes:

Por volume — cada resource (PlaceCount + tiebreaker) precisa de maioria pra aceitar writes
Controller LINSTOR — o database (linstor_db) e replicado via DRBD; precisa de maioria pra o controller funcionar

Ambos podem perder quorum simultaneamente, mas tem mecanismos independentes pra sobreviver.

Configuracao de comportamento sem quorum

DRBD options (global ou por resource):
  on-no-quorum io-error      # I/O retorna erro imediato (default SP)
  on-no-quorum suspend-io    # I/O pendurado ate quorum voltar
  on-no-quorum freeze        # I/O para, recurso vira read-only

io-error e honesto mas pode trigger timeout/abort em apps. suspend-io e melhor pra apps que retomam sozinhas (DBs transacionais que reconectam).

Split-brain: o que e e como recuperar

Definicao

Dois ou mais nodes acreditam ser primary do mesmo recurso simultaneamente e aceitam writes independentes. Quando reconectam, DRBD detecta via “generations id” (UUID por write) e refuse a sincronizar automaticamente.

Como detectar

drbdadm status mostra:

<resource> connection:Connecting role:Secondary
  peer-node connection:StandAlone role:Primary  # SPLIT-BRAIN

Logs mostram Split-Brain detected, dropping connection!.

Recovery manual (perde dados de um lado)

# 1. Decide quem perde (geralmente o lado com menos writes recentes)

# 2. No node "perdedor":
drbdadm disconnect <resource>
drbdadm secondary <resource>                  # se ainda primary
drbdadm -- --discard-my-data connect <resource>

# 3. No node "vencedor":
drbdadm connect <resource>                    # aceita o resync

Atencao: o lado descartado perde todas as escritas durante a particao. Sempre snapshot antes.

LINSTOR oferece after-sb-Xpri policies pra automatizar a escolha (ex: discard-younger-primary), mas pra dados criticos a recomendacao e split-brain ser incidente humano, nao automatico.

Tres saidas pra sobreviver com 1 node

Padrao quorum-majority em cluster de 3 trava com 2 falhas. Pra mudar isso ha 3 caminhos. Cada um e um tradeoff CAP diferente.

Opcao 1: STONITH (fencing)

Antes de virar primary sozinho, o sobrevivente mata os outros via canal independente (IPMI, iDRAC, PDU gerenciada, switch port). Se confirmar morte, sabe que pode escrever sem split-brain.

DRBD config:
  fencing resource-and-stonith;
  handlers {
    fence-peer /usr/lib/drbd/crm-fence-peer.9.sh;
    after-resync-target /usr/lib/drbd/crm-unfence-peer.9.sh;
  }

Requisitos:

IPMI/iDRAC configurado em todos os PVE
Rota IPMI separada da rede de cluster (senao a particao cobre IPMI tambem)
Handler testado regularmente — fencing quebrado e pior que sem fencing (falsa seguranca)

Modelo CAP: continua CP, mas com C+A=disponibilidade total se IPMI funcionar. Custo: complexidade e disciplina operacional.

Opcao 2: Arbiters distribuidos

Adicionar TieBreakers leves (sem dados) em locais separados do dominio de falha principal. Exemplo: 4 nodes com NVMe + 2 arbiters em VMs/containers em rede ou rack distinto.

linstor node create arbiter-01 <ip> --node-type auxiliary
linstor node create arbiter-02 <ip> --node-type auxiliary

Com 5 votantes (3 storage + 2 arbiters):

Quorum = 3
1 storage node + 2 arbiters = 3 ✓ (sobrevive a 2 storage caidos)

LINSTOR suporta Auxiliary — node so de voto, zero storage local, custo minimo.

Modelo CAP: continua CP, mas move a fronteira pra “preciso perder 3 votantes”. Custo: hosts adicionais (leves), redes distintas.

Opcao 3: `quorum off`

DRBD options:
  quorum off

1 node sempre aceita escrita, mesmo sozinho. Aceita split-brain silencioso: quando particao cura, DRBD escolhe um lado pelo after-sb-Xpri policy e descarta o outro — perda de dados sem aviso.

Modelo CAP: vira AP — disponibilidade prioritaria, consistencia eventual com perda. Aceitavel pra labs, inadequado pra dados que importam.

Comparacao final

Modo	C	A	P	Quando
Quorum default (3 nodes)	✓	parcial	✓	Producao “padrao”, perde 1 OK
STONITH	✓	✓	✓	Producao critica, n-1 OK se IPMI ok
Arbiters extras	✓	parcial+	✓	Producao com mais redundancia distribuida
`quorum off`	✗	✓	✓	Lab, dados nao-criticos

SP atual: quorum default. Franca pos-reset (recomendado): arbiters extras (.33 + 1-2 leves), ou STONITH se IPMI esta configurado.

Outras caracteristicas centrais

Anti-afinidade automatica

ReplicasOnDifferent: Aux/<chave> impede que duas replicas de um volume caiam no mesmo “andar”/rack/zona. Cada node recebe uma chave auxiliary, e o resource group enforça diversidade.

# Marcar nodes por andar (usa-se "Aux/floor" — o "Aux/" e o namespace)
linstor node set-property pve-ippri-31 Aux/floor 1
linstor node set-property pve-ippri-32 Aux/floor 1
linstor node set-property pve-ippri-11 Aux/floor 0
linstor node set-property pve-ippri-12 Aux/floor 0

# Aplicar restricao no resource group
linstor resource-group modify sp-ssd-replicated \
  --replicas-on-different=Aux/floor

Nota sobre o display: ao listar linstor resource-group list, a coluna mostra ReplicasOnDifferent: ['Aux/Aux/floor'] — duplica o Aux/ por como o LINSTOR exibe o full path da property. Voce define Aux/floor, mas ve Aux/Aux/floor. E o mesmo valor.

Resultado: nenhum volume coloca ambas as replicas em nodes do mesmo andar. Reduz risco de queda do andar inteiro (energia, switch, refrigeracao) — nao elimina, depende da configuracao fisica real.

Em SP isso esta ativo. Em Franca pos-reset, configurar.

AutoEvict

Quando um node fica offline por tempo configuravel, LINSTOR pode automatically remove-lo dos resources e recriar replicas em outro node disponivel:

controller props:
  DrbdOptions/AutoEvictAfterTime          30      # minutos offline
  DrbdOptions/AutoEvictAllowEviction      True
  DrbdOptions/AutoEvictMaxDisconnectedNodes  1    # quantos pode evictar simultaneamente
  DrbdOptions/AutoEvictMinReplicaCount    2       # nao deixa ficar abaixo disso

Util pra self-healing. Cuidado: se o node “morto” voltar com seu disco intacto, vai chegar com uma replica que LINSTOR ja considera obsoleta — precisa intervir manualmente (linstor resource delete no node retornado, depois recriar — ou usar fluxo de toggle-disk).

Auto-Tiebreaker

DrbdOptions/auto-add-quorum-tiebreaker: True — quando voce cria resource com PlaceCount 2 em cluster de 3+ nodes, LINSTOR automaticamente cria o TieBreaker no terceiro node (sem dados, ~4 MiB de metadata).

Sem isso, voce teria 2 votantes pra cada resource — paridade, qualquer falha trava. Com TieBreaker virtua-livre, 3 votantes — aguenta 1 falha.

Modo COMBINED vs satellite-only vs auxiliary

Tipo	Roda controller?	Roda satellite?	Tem storage?	Uso
Combined	sim (em HA com peers)	sim	sim	Padrao em clusters pequenos (3-5)
Controller	sim	nao	nao	Controller dedicado (cluster grande)
Satellite	nao	sim	sim	Storage-only
Auxiliary	nao	nao	nao	So vota — arbiters

SP e Franca usam Combined — controller HA sai de graca, sem VM/container extra.

Controller HA via VIP DRBD-replicado

O linstor-controller armazena estado em banco H2 embutido (linstordb.mv.db — formato .mv.db e do H2, escrito em Java). Em modo HA, esse arquivo vive num resource DRBD especial (linstor_db), replicado entre os nodes combined. O controller ativo monta o resource como primary; se cair, outro node detecta e promove sua replica a primary, e sobe o controller.

O VIP (10.10.10.1 em SP) flutua junto — clientes (Proxmox, CLI) sempre falam com o IP unico, sem saber qual node esta ativo.

Em Franca atual: controller fixo no .31 sem VIP — ponto unico de falha. Reset deve criar VIP HA.

O failover automatico do controller pode ser orquestrado por drbd-reactor (componente separado da LINBIT) que monitora estado DRBD e dispara systemctl start linstor-controller no novo primary. Em SP nao usamos ainda — failover atual e manual quando o nó dono cai. Ver “drbd-reactor” em Outras caracteristicas.

Storage pool drivers

LINSTOR suporta varios providers — escolhe-se um por pool:

Driver	Provisioning	Quando usar
LVM_THIN	thin	Padrao recomendado — overcommit, snapshots CoW eficientes
LVM	thick	IOPS predicaveis, sem overcommit (DBs sensiveis a latencia)
ZFS_THIN / ZFS	thin/thick	ZFS native snapshots, mas conflita com DRBD sync (raro)
FILE / FILE_THIN	loop file	Lab/dev — volume em arquivo, baixa performance
DISKLESS	—	Cliente DRBD puro (sem disco local)
SPDK	thick	NVMe-oF / userspace, alto desempenho (raro)
EBS / OPENFLEX / EXOS	—	Storage gerenciado externo (cloud/array)

Camadas de cache podem ser combinadas com qualquer dos drivers acima:

dm-cache — cache de leitura/escrita em SSD/NVMe sobre disco lento (write-back ou write-through)
dm-writecache — so cache de escrita (sem cache de leitura)
bcache — equivalente kernel-side, mais maduro pra cache hibrido

LINSTOR cria/gerencia esses pools combinados (ver secao “Tipos de midia”).

SP e Franca usam LVM_THIN com thinpool sobre VG dedicado, sem cache.

Snapshots LINSTOR

linstor snapshot create <resource> <snap-name>
linstor snapshot list
linstor snapshot rollback <resource> <snap-name>
linstor snapshot delete <resource> <snap-name>

Snapshots sao consistentes multi-volume (todos os volumes do resource snapshot ao mesmo tempo) e atomicos com pmxcfs. Sao CoW no thin pool — usam espaco proporcional ao delta.

Diferente de qm snapshot (Proxmox) que opera no nivel do qcow2/raw — LINSTOR snapshot e block-level, mais rapido e nao precisa parar a VM.

Protocolos DRBD

Protocolo	Write retorna ack quando	Risco	Quando
A (async)	Local + enviado ao buffer de rede	Crash do primary perde writes nao chegados ao peer	DR cross-site
B (semi-sync)	Local + peer recebeu (mas nao gravou)	Crash do peer perde writes em buffer	Compromisso
C (sync)	Local + peer gravou	Zero perda	Padrao LINSTOR

LINSTOR usa Protocolo C por padrao em todos os pares. Latencia maior, garantia maxima — write so confirma quando ambos os lados tem o dado em disco.

`auto-diskless-allow-cleanup` e `auto-resync-after-disable`

auto-diskless-allow-cleanup: quando node fica diskless (manualmente ou via auto-evict), LINSTOR libera o LV automaticamente — recupera espaco no thin pool.
auto-resync-after-disable: quando resource desabilitado e re-habilitado, LINSTOR dispara resync automatico em vez de esperar comando manual.

Ambos sao True em SP — operacao mais self-service.

LINSTOR GUI (interface web)

LINSTOR tem interface web open-source desde 2022 — pacote linstor-gui, repo https://github.com/LINBIT/linstor-gui.

Cobertura:

Listagem de nodes, storage pools, resource definitions, resources
Snapshots e schedules de backup
Error reports e events
Properties de nodes/resources (read-mostly — algumas operacoes complexas so via CLI)

Stack: React frontend + REST API do controller. Distribuido como pacote Debian no repo LINBIT.

# Instalar (LINBIT repo ja configurado)
apt install linstor-gui

# Servido pelo proprio controller na porta 3370
# http://10.10.10.1:3370/   (em SP)
# http://<vip-controller>:3370/   (em geral)

Limitacoes:

Nao substitui o CLI pra operacao complexa (placement custom, properties avancadas, troubleshooting)
Em evolucao — algumas releases do LINSTOR core saem antes da GUI suportar features novas
Sem auth nativa robusta — depende do controller ter REST configurado com TLS+auth se exposto fora da rede de gestao

Recomendado pra: observability cotidiana, status checks rapidos, dashboards pra equipe nao-operadora. Nao recomendado como unica interface.

drbd-reactor (failover automatico do controller)

drbd-reactor e um daemon que monitora estado DRBD e dispara acoes em resposta. Os 3 plugins principais:

Plugin	Funcao
promoter	Quando DRBD vira Primary num node, sobe automaticamente um servico associado (ex: `linstor-controller`, NFS server)
prometheus	Exporta metricas DRBD pra Prometheus (resource state, replication lag, etc.)
debugger	Loga eventos DRBD pra troubleshooting

Caso de uso classico: HA do controller LINSTOR sem precisar de Pacemaker.

[[promoter]]
[promoter.resources.linstor_db]
start = ["linstor-controller.service"]
on-stop-failure = "exit"

Quando linstor_db vira Primary num node, drbd-reactor sobe linstor-controller. Se o node cair, outro vira Primary e o controller migra junto.

Em SP/Franca atual: nao usado. Failover de controller e manual quando o nó dono cai. Adicionar drbd-reactor esta em storage-strategy.md como melhoria P3.

Mais info: https://github.com/LINBIT/drbd-reactor

Placement strategies

Ao criar resource, LINSTOR decide em quais nodes colocar replicas. Estrategias disponiveis (em linstor resource-group create --place-count ou via --storage-pool):

Estrategia	Comportamento
MaxFreeSpace (default)	Escolhe nodes com mais espaco livre — equaliza uso
MinRscCount	Escolhe nodes com menos recursos — equaliza numero de volumes
MinReservedSpace	Considera overcommit thin — mais conservador
OldestSatellite	Nodes adicionados primeiro tem prioridade

Combinaveis com --replicas-on-same/--replicas-on-different (anti-afinidade) e --storage-pool (filtros de pool).

QoS por volume

LINSTOR pode aplicar limites de IOPS/bandwidth via blkio cgroup:

linstor volume-definition set-property <res> 0 \
  Sys/fs/blkio_throttle_read 50000000          # 50 MB/s read
linstor volume-definition set-property <res> 0 \
  Sys/fs/blkio_throttle_write 30000000         # 30 MB/s write

Util pra evitar que VM “barulhenta” sufoque vizinhas no mesmo node.

Over-provisioning ratios

Em LVM_THIN, voce pode alocar volumes somando mais do que existe fisicamente (thin overcommit). LINSTOR oferece guard-rails:

controller props:
  StorDriver/MaxOversubscriptionRatio  20       # max 20x o tamanho fisico
  StorDriver/MaxOversubscription       True     # ativa

Com MaxOversubscriptionRatio: 2: pool de 3 TiB nao pode ter mais de 6 TiB alocados. Sem o guard-rail, e facil over-allocar e estourar o thin pool — quando isso acontece, todas as VMs no pool param.

Tipos de midia: NVMe, SSD, HDD — como usar e combinar

LINSTOR e agnostico de midia — ele orquestra LVs/ZFS volumes, e o desempenho vem de baixo. Mas a forma como voce organiza pools e mistura midias muda drasticamente latencia, custo e durabilidade.

Caracteristicas por tipo

Midia	Latencia (4K)	Throughput	IOPS	Endurance	$/TiB
HDD 7.2k	5-10 ms	150-200 MB/s	100-200	alta (mecanico)	baixo
SATA SSD	0.1-0.3 ms	500 MB/s	50k-100k	media (DWPD ~0.5-1)	medio
NVMe consumer	0.05-0.1 ms	3-7 GB/s	200k-1M	baixa (DWPD ~0.1-0.3)	medio
NVMe enterprise	0.02-0.08 ms	6-14 GB/s	1M+	alta (DWPD 1-3+)	alto

DWPD = Drive Writes Per Day. NVMe consumer morre rapido sob workload de DB/DRBD sync (writes constantes em todos peers). Enterprise tem PLP (power-loss protection) e endurance suficiente.

Estrategia 1 — Pools separados por tier (recomendado, simples)

Cada tipo de midia vira um pool independente. Resource groups apontam pra pools especificos.

Node ippri-31:
  /dev/nvme0n1 + nvme1n1 → VG linstor_nvme  → pool nvme-pool
  /dev/sda + sdb         → VG linstor_ssd   → pool ssd-pool
  /dev/sdc + sdd + sde   → VG linstor_hdd   → pool hdd-pool

linstor resource-group create vms-hot --place-count 2 --storage-pool nvme-pool
linstor resource-group create vms-std --place-count 2 --storage-pool ssd-pool
linstor resource-group create archive --place-count 2 --storage-pool hdd-pool

Pros:

Performance previsivel por workload
Sem overhead de cache, sem complexidade
Falha de NVMe nao quebra HDD e vice-versa
Capacidade total = soma de tudo

Contras:

Espaco rigido — VM em hdd-pool nao usa NVMe folgado
Operador precisa decidir o pool certo na criacao
Mais SKUs pra comprar/operar

Quando usar: workloads bem definidos (DBs em NVMe, fileserver em HDD, VMs comuns em SSD). E o que SP e Franca usam (so SSD/NVMe hoje).

Estrategia 2 — Cache hibrido (NVMe sobre HDD)

Coloca NVMe pequena como cache, HDD grande como capacidade. Aplicacao “ve” um unico volume com latencia ~NVMe pra dados quentes e capacidade de HDD pra arquivamento.

Tres tecnologias suportadas pelo LINSTOR:

Tecnologia	Cache de	Quando usar
dm-cache	leitura e escrita	Workload misto, hot data identificavel
dm-writecache	so escrita	Apps write-heavy onde leitura ja vem rapida
bcache	leitura e escrita	Mais maduro, requer formatar disco backing

Configuracao no LINSTOR:

# Pool com dm-cache: precisa criar 2 LVs (origin + cache) e LINSTOR junta
linstor storage-pool create lvm-thin <node> hdd-cached \
  linstor_hdd/thinpool \
  --shared-space hdd-cached
# Property no node aponta o cache LV
linstor node set-property <node> StorDriver/<pool>/CacheDevice  /dev/nvme0n1p1
linstor node set-property <node> StorDriver/<pool>/CachePolicy  writeback

Pros:

“Melhor dos dois mundos” — latencia NVMe + capacidade HDD
Aproveita hot data (~80% dos accessos em ~20% dos dados)
Custo por TiB efetivo bem menor que NVMe puro

Contras:

Complexidade — uma camada extra a debugar
Falha do NVMe-cache pode comprometer integridade se write-back e cache nao replicado
Cold reads (primeira vez) ainda vao no HDD — latencia variavel
Sob pressao de write sustentado (>capacidade do cache), degrada pra HDD-puro
Endurance do NVMe-cache acelera (e cache, escreve muito)

Quando usar: arquivamento ativo (NextCloud, file server), backup repository, workloads cold/warm. Nao usar pra DB transacional — latencia nao e previsivel.

Estrategia 3 — Mistura no mesmo pool (geralmente NAO)

LVM permite criar VG com PVs heterogeneos (NVMe + SSD + HDD juntos), e LINSTOR aceita esse pool. Geralmente e ruim:

LVM aloca extents linearmente — primeiro PV ate encher, depois proximo. Resultado: alguns LVs caem em NVMe, outros em HDD, sem controle.
DRBD sync sera limitado pelo peer mais lento envolvido na escrita — se a replica caiu em HDD num node, todo write da VM espera HDD.
Diagnostico de performance vira loteria.

Excecao razoavel: stripe controlado (lvcreate --stripes) entre 2 NVMe identicos pra dobrar throughput. Mas nunca misture tipos diferentes.

Estrategia 4 — Diskless + diskful seletivo

Nem todo node precisa de disco. Em cluster com 6 PVE mas so 3 com NVMe:

3 nodes diskful (storage real, contribuem pro pool)
3 nodes diskless (so clientes DRBD via 10G)

VMs podem rodar em qualquer um dos 6 — diskless le/escreve via rede no peer diskful. SP usa esse padrao (ippri-33/34 sao GPU, nao tem SSD-pool, mas sao diskless do linstor-ssd-01).

Pros: aproveita nodes que tem CPU/GPU/RAM mas nao tem disco bom. Live migration entre todos.

Contras: I/O da VM diskless saturra rede 10G facil — limita ao throughput da NIC.

Recomendacao por workload

Workload	Estrategia	Pool sugerido
DB transacional (Postgres, MySQL)	Pool dedicado, NVMe enterprise	`nvme-db-pool`, sem overcommit
VMs gerais (web, app servers)	Pool padrao	`ssd-pool` ou `nvme-pool` LVM_THIN
File server / NextCloud	Cache hibrido	`hdd-pool` com dm-cache em NVMe
Backup repository	HDD puro	`hdd-pool` LVM_THIN, sem cache
AI/ML training (dataset grande, leitura sequencial)	NVMe puro, diskless onde for treinar	`nvme-pool`
Cold archive	HDD puro, replication 2x	`hdd-pool`

Custo da replicacao por tier

DRBD escreve em N replicas — duplica/triplica IOPS de escrita no cluster. Em NVMe enterprise, isso e absorvido. Em SSD consumer, voce queima o disco em 1-2 anos. Em HDD, a latencia se acumula (cada peer ack adiciona ~5-10ms).

Por isso producao seria bom em NVMe enterprise com PLP mesmo sendo mais caro — DRBD-sync precisa de baixa latencia e endurance alta.

LINSTOR e backup: replicacao nao e backup

Erro comum: tratar DRBD/LINSTOR como backup. Nao e.

Por que replicacao != backup

Cenario	Replicacao DRBD	Backup
1 disco falha	Protege ✓	Protege ✓
1 node morre	Protege ✓	Protege (mais lento) ✓
`rm -rf /` na VM	Replica o `rm` instantaneamente ✗	Protege ✓
Ransomware criptografa dados	Replica a criptografia ✗	Protege (se backup imutavel) ✓
Bug que corrompe DB	Replica a corrupcao ✗	Protege ✓
Operador apaga VM (`qm destroy`)	Apaga em todas as replicas ✗	Protege ✓
Datacenter pega fogo	Tudo no mesmo lugar fisico ✗	Protege (se off-site) ✓
Update do Proxmox quebra storage layer	Possivelmente corrompe replicas	Protege ✓

DRBD replica eventos, nao estados consistentes no tempo. Qualquer dano logico vai pras replicas no mesmo segundo.

O que LINSTOR oferece pra backup (limites e usos)

LINSTOR tem features de backup, mas com escopo especifico:

1. Snapshots LINSTOR (point-in-time local)

linstor snapshot create <resource> snap-2026-04-29

CoW no thin pool, instantaneo
Permite rollback rapido (dia anterior, etc.)
Mora no mesmo storage — nao protege de falha do storage, datacenter, etc.
Bom pra: testes, upgrades reversiveis, “ctrl-z” curto.
Nao serve como backup independente.

2. Snapshot shipping (cluster→cluster)

LINSTOR pode “enviar” snapshots de um cluster pra outro (LINSTOR remoto), mantendo replica off-site.

Sintaxe (validada no client v1.27):

# 1. Registrar o cluster remoto como "remote"
linstor remote create linstor franca-cluster http://10.10.10.99:3370

# 2. Enviar um backup pontual (gera snapshot + envia)
linstor backup create franca-cluster <resource>

# Ou enviar via ship explicito (com mais opcoes)
linstor backup ship franca-cluster <source-resource> <target-resource>

Requisitos:

Cluster destino tambem rodando LINSTOR
Controller remoto alcancavel via HTTP (porta 3370)
Storage pools compativeis no destino (mesmo nome OU usar --storpool-rename)

Use case: replicar Franca → SP (ou vice-versa) periodicamente. Funciona como DR async.

3. Scheduled backup shipping (S3, agendado)

LINSTOR tem agendador nativo pra exportar snapshots periodicamente. Sintaxe validada (v1.27):

# 1. Registrar remote S3 (MinIO ou AWS)
linstor remote create s3 my-s3 \
  https://s3.example.com bucket-name region-name <access-key>
# Solicitara secret-key interativamente; ou passar como ultimo arg

# 2. Criar schedule (full_cron e POSITIONAL)
linstor schedule create daily-backup "0 2 * * 0" \
  -i "0 2 * * 1-6" \
  -l 7 -r 30 \
  --on-failure RETRY --max-retries 3

# 3. Enable schedule pra um resource (--rd) ou resource group (--rg)
linstor backup schedule enable my-s3 daily-backup --rg sp-ssd-replicated
# Ou pra um resource especifico:
# linstor backup schedule enable my-s3 daily-backup --rd vm-103-disk-0

Suporta:

S3 (AWS, MinIO, Wasabi, etc.) — ou cluster LINSTOR remoto
Full + incremental
Retencao local e remota separadas
Compressao + (opcional) encriptacao

Esse e o caminho mais proximo de “LINSTOR como backup” — exporta volumes pra storage remoto independente.

Limites do LINSTOR como backup

Mesmo com shipping pra S3, LINSTOR nao substitui uma estrategia 3-2-1 completa:

Granularidade e o resource inteiro — pra recuperar 1 arquivo, voce restaura o volume todo, monta, copia o arquivo. Lento.
Sem deduplicacao cross-volume — backup de 10 VMs identicas ocupa 10x espaco.
Sem indice de conteudo — voce nao busca “qual VM tinha o arquivo X em Y data”.
Pra VMs Proxmox, vzdump complementa — gera arquivos .vma granulares, integrados com agendamento Proxmox/PBS.

Estrategia recomendada (3-2-1 adaptado)

Camada 1 (replicacao online):
  DRBD/LINSTOR — protege de falha de hardware
  → 1-2 falhas concorrentes sem downtime

Camada 2 (snapshots locais):
  LINSTOR snapshots agendados — protege de erro humano/bug recente
  → rollback rapido (minutos), retencao curta (7 dias)

Camada 3 (backup off-site):
  Proxmox Backup Server (PBS) ou vzdump → S3/PBS remoto
  → protege de ransomware, dano logico, perda do site
  → retencao longa (30-365 dias), imutabilidade quando possivel

PBS faz dedup, indice, restore granular — e o complemento natural ao LINSTOR. Em SP/Franca, recomenda-se PBS ou vzdump+S3 pra camada 3, alem dos snapshots LINSTOR pra camada 2.

LINSTOR backup ship pra S3 substitui camada 3 se voce nao precisa de granularidade de arquivo (ex: VMs que voce trata como pets/imutaveis).

Replicacao remota e disaster recovery

DRBD Proxy (sync sob latencia)

DRBD sync padrao (Protocolo C) precisa de latencia baixa entre peers (~ms). Cross-site (SP↔Franca, ~5-15ms RTT), o write fica esperando a confirmacao remota — performance despenca.

DRBD Proxy e um daemon (entre o DRBD primary e o link WAN) que:

Bufera writes localmente em RAM
Comprime + envia em batch pelo WAN
Trabalha em modo async (Protocolo A) — write retorna apos buffer local, peer remoto recebe depois
Sobrevive a glitches de rede sem disconnect

Use case: DR ativo entre 2 sites. Site B mantem replica “minutos atrasada” do A. Falha do A → promove B (perde-se ~RPO de minutos).

Limites:

Nao e free — DRBD Proxy e parte do LINBIT SDS comercial (subscricao)
Async = aceita perda de janela curta de writes
Requer banda dedicada e tuning

Alternativas livres: snapshot shipping LINSTOR (cobertura mais grossa, RPO de horas, mas gratuito).

Estrategia DR para SP↔Franca

Mecanismo	RPO	RTO	Custo
DRBD Proxy SP↔Franca	minutos	minutos (failover)	$$$, banda dedicada
Snapshot shipping diario	24h	horas (restore + reconfig)	$, agendamento
Backup PBS cross-site	24h	horas-dia	$, simples
Sem DR	∞	∞	0

Pra labs/pesquisa academica, snapshot shipping diario + backup PBS e usualmente suficiente.

Encriptacao em repouso (LUKS)

LINSTOR integra LUKS (dm-crypt) pra encriptar volumes em repouso:

# 1. Definir master passphrase no controller (uma vez)
linstor encryption create-passphrase

# 2. Criar resource encriptado
linstor resource-definition create encrypted-vm
linstor volume-definition create encrypted-vm 100G --encrypt
linstor resource create --auto-place 2 encrypted-vm

Operacao:

Cada write/read passa por dm-crypt no kernel — overhead de CPU (5-15% sob carga write-heavy)
Master passphrase precisa ser fornecida ao controller a cada start (linstor encryption enter-passphrase)
LUKS default: AES-128, HMAC-SHA-512, PBKDF2

Quando usar:

Compliance (LGPD, HIPAA, PCI-DSS)
Disco fisico pode ser roubado/extraviado (ex: laptop, edge)
Dados de pesquisa com IRB

Quando nao usar (overhead nao compensa):

Datacenter fisicamente seguro com discos descartados via wipe + destruicao
Workload latency-critical onde 5-15% CPU importa

Em SP/Franca: nao usado (datacenter controlado, dados nao-sensiveis em repouso).

Manutencao

Operacao	Como
Adicionar disco no node	`vgextend` VG + `lvextend` thinpool — LINSTOR detecta
Adicionar novo node	`linstor node create` + `storage-pool create` + satellite
Remover node	Evacuar resources primeiro (`resource create` em outro, depois delete)
Trocar disco com falha	Replace no VG — LINSTOR refaz DRBD sync automatico
Promover diskless a diskful	`linstor resource toggle-disk <node> <resource> --storage-pool <pool>`
Mudar resource group de um resource	`linstor resource-definition modify <res> --resource-group <novo>`

Tudo online. VMs nao param.

Performance — numeros aproximados

Operacao	Diskful (local)	Diskless (via 10G)
Read latency	~0.1ms	~0.2ms
Read throughput	~500 MB/s (SSD SATA)	~1.2 GB/s (10G cap)
Write latency	~0.3ms (sync todos peers)	~0.3ms
Write throughput	Limitado pelo peer mais lento	Igual

Para a maioria dos workloads (VyOS, Traefik, K3s control-plane) a diferenca diskful vs diskless nao e perceptivel.

Workloads I/O-bound (DB hot, AI training com dataset local): preferir diskful no node que roda a VM.

Gargalos em ordem de impacto

Rede 10G saturada
CPU do peer diskful (DRBD consome 5-10% sob carga)
Disco do peer mais lento
Fragmentacao thin LVM (longo prazo)

Por que aparece ”?” em alguns nodes do Proxmox

Storage LINSTOR e definido cluster-wide em /etc/pve/storage.cfg. Nodes que nao alcancam o controller (10.10.10.1 em SP) veem ”?” — isso significa “storage existe mas esta inacessivel daqui”.

Fix: conectar node a rede 10G + configurar IP em 10.10.20.x + instalar satellite + linstor node create.

Depois disso, o node pode usar o storage mesmo sem disco local (diskless).

Diskless — vantagem concreta

Cenario: cluster SP tem 6 nodes Proxmox. So 3 tem disco no ssd-pool.

Sem diskless: so 3 nodes rodam VMs no linstor-ssd-01. Os outros 3 (incluindo ippri-33/34 com GPU A5000) ficam trancados fora.

Com diskless: todos os 6 rodam VMs. CPU/RAM ficam no node onde a VM esta; I/O vai pela rede 10G para os peers com disco.

Ganhos:

Live migration entre qualquer par de nodes
HA — VM pode reiniciar em qualquer node se um falhar
Aproveita hardware (GPUs em 33/34) sem comprar SSD para todos

Referencias

Documentos internos

Estrategia de storage e cross-site: storage-strategy.md
Operacoes cotidianas: linstor-operacoes.md
Troubleshooting + DRBD verify + monitoring: linstor-troubleshooting.md
Cluster NVMe planejado SP: linstor-sp.md
Topologia rede: rede-sp.md, rede-10g-sp.md
Inventario: inventory/hosts.yaml (grupos linstor_sp, linstor_sp_ssd)
Roles Ansible: config/roles/linstor/
Recovery: memory project_linstor_recovery.md

Documentacao upstream LINBIT

User Guide raiz: https://linbit.com/drbd-user-guide/linstor-guide-1_0-en/
Storage providers: https://linbit.com/drbd-user-guide/linstor-guide-1_0-en/#s-storage_providers
Snapshots e backup shipping: https://linbit.com/drbd-user-guide/linstor-guide-1_0-en/#s-linstor-snapshots
DRBD Proxy (DR): https://linbit.com/drbd-user-guide/linstor-guide-1_0-en/#s-linstor_drbd_proxy
Encrypted volumes (LUKS): https://linbit.com/drbd-user-guide/linstor-guide-1_0-en/#s-encrypted_volumes
DRBD 9 user guide: https://linbit.com/drbd-user-guide/drbd-guide-9_0-en/ (quorum, fencing, protocolos)
dm-cache / dm-writecache / bcache: kernel docs em Documentation/admin-guide/device-mapper/ e Documentation/admin-guide/bcache.rst

LINSTOR — conceitos operacionais

LINSTOR — conceitos operacionais

O que e LINSTOR

Componentes

Pools no SP

Modos de presenca de um resource num node

1. Diskful (UpToDate)

2. TieBreaker

3. Diskless

Writes sao sempre sincronos em todos os diskful

Reads sao locais (quando possivel)

Live migration entre nodes

Para node sem replica ainda (ex: migrar para node diskless novo)

Mistura de storage types e tamanhos

Tamanhos diferentes no mesmo pool

NVMe + SSD no mesmo pool

Pools conversam entre si

Resiliencia: quorum e split-brain

Por que quorum existe

O cenario “particao parece morte”

Formula da maioria estrita

Duas camadas de quorum

Configuracao de comportamento sem quorum

Split-brain: o que e e como recuperar

Definicao

Como detectar

Recovery manual (perde dados de um lado)

Tres saidas pra sobreviver com 1 node

Opcao 1: STONITH (fencing)

Opcao 2: Arbiters distribuidos

Opcao 3: quorum off

Comparacao final

Outras caracteristicas centrais

Anti-afinidade automatica

AutoEvict

Auto-Tiebreaker

Modo COMBINED vs satellite-only vs auxiliary

Controller HA via VIP DRBD-replicado

Storage pool drivers

Snapshots LINSTOR

Protocolos DRBD

auto-diskless-allow-cleanup e auto-resync-after-disable

LINSTOR GUI (interface web)

drbd-reactor (failover automatico do controller)

Placement strategies

QoS por volume

Over-provisioning ratios

Tipos de midia: NVMe, SSD, HDD — como usar e combinar

Caracteristicas por tipo

Estrategia 1 — Pools separados por tier (recomendado, simples)

Estrategia 2 — Cache hibrido (NVMe sobre HDD)

Estrategia 3 — Mistura no mesmo pool (geralmente NAO)

Estrategia 4 — Diskless + diskful seletivo

Recomendacao por workload

Custo da replicacao por tier

LINSTOR e backup: replicacao nao e backup

Por que replicacao != backup

O que LINSTOR oferece pra backup (limites e usos)

1. Snapshots LINSTOR (point-in-time local)

2. Snapshot shipping (cluster→cluster)

3. Scheduled backup shipping (S3, agendado)

Limites do LINSTOR como backup

Estrategia recomendada (3-2-1 adaptado)

Replicacao remota e disaster recovery

DRBD Proxy (sync sob latencia)

Estrategia DR para SP↔Franca

Encriptacao em repouso (LUKS)

Manutencao

Performance — numeros aproximados

Gargalos em ordem de impacto

Por que aparece ”?” em alguns nodes do Proxmox

Diskless — vantagem concreta

Referencias

Documentos internos

Documentacao upstream LINBIT

Opcao 3: `quorum off`

`auto-diskless-allow-cleanup` e `auto-resync-after-disable`