LINSTOR — troubleshooting

LINSTOR — troubleshooting, integridade e monitoring

Playbook de incidentes + integridade online (DRBD verify) + observabilidade. Complementa linstor-conceitos.md (conceitos) e linstor-operacoes.md (operacao cotidiana).

Antes de qualquer acao destrutiva: snapshot. Antes de comandos --discard-my-data: backup. Memoria do projeto: feedback_linstor_delete — linstor resource delete apaga o LV de baixo, sem lixeira.

Indice

• Troubleshooting playbook
  • Resource em Inconsistent ou Outdated
  • Diskful que perdeu o LV (apos troca de disco)
  • Connection refused / StandAlone entre satellites
  • Resync travado ou muito lento
  • Controller inalcancavel via VIP
  • Storage pool nao alcanca capacidade real
  • Thin pool prestes a estourar
  • Satellite OFFLINE(OTHER_CONTROLLER)
  • Incidente Franca — 2026-05-09
• linstor_storage sumiu da interface Proxmox
• DRBD verify (integridade online)
• Monitoring e observabilidade
• DR drill (teste de recuperacao)

Troubleshooting playbook

Resource em Inconsistent ou Outdated

Sintoma: drbdadm status mostra disk:Inconsistent ou disk:Outdated num peer.

res-x role:Secondary
  disk:Inconsistent open:no
  pve-ippri-12 role:Secondary
    peer-disk:UpToDate

Diagnostico:

# Ver progresso de sync (se em curso)
drbdadm status <resource>

# Ver eventos historicos
journalctl --since "1 hour ago" | grep -E 'drbd|<resource>'

# Ver activity log status
drbdsetup status --verbose <resource>

Causas comuns:

Causa	Sinal
Sync em curso (normal apos reboot/reconnect)	Inconsistent com peer-disk:UpToDate e progresso aumentando
Sync travado	Mesma porcentagem por > 5 min
Peer foi marcado como Outdated por causa de verify mismatch	Logs com Online verify found ... mismatches
Disco fisico do peer diskful esta com problema	Erros I/O no kernel (dmesg)

Acoes:

# A) Sync em curso — aguardar. Monitorar:
watch -n 5 'drbdadm status <resource>'

# B) Sync travado — forcar (cuidado):
drbdadm disconnect <resource>
drbdadm connect <resource>

# C) Se o lado Inconsistent e o que voce confia (UpToDate antigo agora ficou Inconsistent):
#    Promote-lo manualmente NAO e seguro sem analisar logs primeiro.
#    Restaurar do backup PBS e mais previsivel.

# D) Forcar resync completo a partir do peer UpToDate (perde dados do Inconsistent):
drbdadm invalidate <resource>          # marca este lado como vazio
# DRBD vai resincronizar tudo do peer UpToDate

Diskful que perdeu o LV (apos troca de disco)

Sintoma: trocou disco fisico no node, recriou VG/thinpool, mas LINSTOR ainda lista o resource como UpToDate no node — quando na verdade o LV nao existe mais.

Diagnostico:

# No node afetado:
lvs linstor_ssd/                     # LV nao aparece
ls /dev/drbd*                        # device DRBD some
drbdadm status <resource>            # erro

Solucao — toggle-disk para diskless e de volta para diskful:

# 1. Marcar resource como diskless no node afetado (libera o tracking)
linstor resource toggle-disk <node> <resource> --diskless

# 2. Confirmar:
linstor resource list | grep <resource>
# Deve mostrar Diskless no node afetado

# 3. Recriar como diskful — LINSTOR cria LV novo + ressincroniza do peer
linstor resource toggle-disk <node> <resource> --storage-pool ssd-pool

# 4. Acompanhar resync
watch -n 5 'drbdadm status <resource>'

Se houver muitos resources no node, fazer 1 por vez pra nao saturar a rede.

Connection refused / StandAlone entre satellites

Sintoma: peers DRBD em connection:Connecting ou StandAlone permanente; logs com “Connection refused” ou “No route to host”.

Diagnostico camada por camada:

# 1. Ping (rede basica)
ping -c 3 <ip-peer-na-rede-linstor>

# 2. Porta DRBD aberta? (porta varia por resource: 7000+)
ss -tnlp | grep -E ':70[0-9][0-9]'

# 3. Firewall local
iptables -L -n | grep -E '70[0-9][0-9]|10\.10\.10'

# 4. MTU mismatch (frequente com jumbo frames)
ping -M do -s 8972 <ip-peer>          # se falhar, MTU < 9000 em algum hop

# 5. Logs do satellite local
journalctl -u linstor-satellite --since "30 min ago" | tail -50

# 6. Estado da interface
ip -br addr show | grep 10\.10\.10
ip link show <interface-linstor>

Acoes:

# Reconectar manualmente (apos resolver causa raiz)
drbdadm disconnect <resource>
drbdadm connect <resource>

# Reiniciar satellite (so se necessario — interrompe TODOS os resources locais)
systemctl restart linstor-satellite

Resync travado ou muito lento

Sintoma: drbdadm status mostra progresso mas a velocidade caiu (ex: 1 MB/s onde a rede aguenta 1 GB/s).

Diagnostico:

# Ver rate atual
drbdsetup status --statistics <resource>
# Olhar "rs_total_in_flight" e "rs_in_flight"

# Sync rate configurado
drbdadm dump <resource> | grep -E 'c-max-rate|c-min-rate|c-fill-target'

# Rede saturada?
iftop -i <interface-linstor>           # ou nload, bmon

Tuning de sync rate (DRBD 9 — adaptativo):

# Ajustar dinamicamente (nao precisa restart)
drbdadm net-options --c-max-rate=400M --c-fill-target=1M <resource>

# Ou globalmente via LINSTOR
linstor controller drbd-options --c-max-rate=400M

Parametro	Funcao	Default
c-max-rate	Limite superior de sync rate	100M
c-min-rate	Limite inferior (garantia)	250K
c-fill-target	Buffer alvo (latencia vs throughput)	50K
c-plan-ahead	Janela de planejamento adaptativo	20 (10ths sec)

Em rede 10G dedicada, c-max-rate=600M e razoavel. Em 1G compartilhada, ficar < 100M pra nao sufocar VMs.

Controller inalcancavel via VIP

Sintoma: linstor node list falha com “Unable to connect to linstor://10.10.10.1”.

Diagnostico:

# 1. Quem deveria ter o VIP?
ssh <node1> 'ip addr show | grep -E "10\.10\.10\.1\b"'
ssh <node2> 'ip addr show | grep -E "10\.10\.10\.1\b"'
ssh <node3> 'ip addr show | grep -E "10\.10\.10\.1\b"'
# Deve aparecer em exatamente 1 (controller ativo)

# 2. Controller esta rodando nesse node?
ssh <node-com-vip> 'systemctl status linstor-controller'

# 3. linstor_db DRBD esta UpToDate?
ssh <node-com-vip> 'drbdadm status linstor_db'

# 4. Log
ssh <node-com-vip> 'journalctl -u linstor-controller --since "30 min ago" | tail -50'

Cenarios:

Cenario	Acao
Nenhum node tem o VIP	Ativar manualmente no node com linstor_db UpToDate (ou esperar drbd-reactor se configurado)
Mais de 1 node tem o VIP	Conflito — desativar nos extras imediatamente, depois investigar
VIP esta em node onde controller nao subiu	systemctl start linstor-controller
Controller sobe mas erra ao montar linstor_db	DRBD do linstor_db nao esta Primary — drbdadm primary linstor_db

Storage pool nao alcanca capacidade real

Sintoma: linstor storage-pool list mostra capacidade muito menor que o thin pool real.

| ssd-pool | pve-ippri-31 | LVM_THIN | linstor_ssd/thinpool | 100 GiB | 100 GiB |
                                                              ^^^ deveria ser 3.46 TiB

Diagnostico:

# Capacidade real do VG
ssh <node> 'vgs linstor_ssd'
ssh <node> 'lvs linstor_ssd'

# LINSTOR esta lendo o pool corretamente?
linstor storage-pool list-properties <node> <pool>

Causas comuns:

Causa	Sinal
VG/thinpool foi expandido mas LINSTOR nao detectou	Refresh: reiniciar satellite no node
Property StorDriver/AllocationGranularity configurada errada	Listar properties; remover propriedade incorreta
Mismatch de unidades (KiB vs MB)	LINSTOR mostra em MiB/GiB sempre — checar contra lvs --units g

Thin pool prestes a estourar

Sintoma critico: lvs <vg>/thinpool mostra Data% > 80%.

Por que e critico: thin pool 100% = todas as VMs no pool travam I/O em segundos. Recovery exige expandir antes que ocorra.

Diagnostico:

# Ver uso real
ssh <node> 'lvs -o lv_name,lv_size,data_percent,metadata_percent linstor_ssd/thinpool'

# Ver volumes maiores
ssh <node> 'lvs -o lv_name,lv_size,data_percent --sort -data_percent linstor_ssd | head -20'

# Snapshots ocupando espaco?
linstor snapshot list

Acoes em ordem de preferencia:

# A) Apagar snapshots antigos (verifica nao-criticos primeiro)
linstor snapshot delete <resource> <snap-name>

# B) Apagar resources orfaos (sem VM associada)
#    CUIDADO: confirmar com qm config / pct config primeiro
linstor resource list | awk '/Unused/ {print $2, $4}'

# C) Expandir thinpool (se tem espaco no VG)
ssh <node> 'lvextend -L +500G linstor_ssd/thinpool'
ssh <node> 'systemctl restart linstor-satellite'   # detecta mudanca

# D) Adicionar PV ao VG (se tem disco fisico livre)
ssh <node> 'pvcreate /dev/nvmeXn1'
ssh <node> 'vgextend linstor_ssd /dev/nvmeXn1'
ssh <node> 'lvextend -L +X linstor_ssd/thinpool'

# E) Migrar resource pra outro pool com espaco
linstor resource toggle-disk <node-cheio> <resource> --diskless
linstor resource toggle-disk <node-folgado> <resource> --storage-pool ssd-pool

Preventivo: configurar MaxOversubscriptionRatio no controller pra impedir alocacao alem do limite (ver linstor-conceitos.md#over-provisioning-ratios).

Satellite OFFLINE(OTHER_CONTROLLER)

Sintoma: linstor node list mostra um ou mais nodes como OFFLINE(OTHER_CONTROLLER).

Significado: o satellite conectou a um controller diferente. O controller atual parou de tentar reconectar.

Diagnostico:

# Confirmar que e realmente OTHER_CONTROLLER (nao so OFFLINE)
linstor node list

# Ver quando o controller parou de reconectar
journalctl -u linstor-controller | grep -E "OTHER_CONTROLLER|ONLINE|OFFLINE" | tail -20

# Checar se ha outro controller ativo na rede LINSTOR
# (porta 3370 = API REST do controller)
for ip in 10.10.10.{1..20}; do
  timeout 1 bash -c "echo > /dev/tcp/$ip/3370" 2>/dev/null && echo "$ip:3370 aberto"
done

# No satellite, ver conexoes TCP ativas
ssh <node-satellite> 'ss -tn | grep -E ":3366|:3370"'

Solucao rapida — reiniciar o controller principal:

Quando o controller concorrente ja nao esta mais ativo (ex: node com falha de hardware), reiniciar o controller limpa o estado travado e forca reconexao a todos os satellites. Satellites recem-reiniciados aceitam a nova conexao imediatamente.

# No node do controller principal
systemctl restart linstor-controller

# Aguardar ~10 segundos e verificar
sleep 10
linstor node list
# Nodes devem aparecer Online ou Connected

Quando a solucao rapida nao funciona (outro controller ainda ativo):

# 1. Parar o controller concorrente
ssh <node-controller-concorrente> 'systemctl stop linstor-controller'

# 2. Reiniciar o controller correto
systemctl restart linstor-controller

# 3. Validar
linstor node list

Solucao destrutiva (ultimo recurso — re-registrar o node):

# 1. Deletar o registro do node (so metadata, nao apaga DRBD/LV)
linstor node delete <node>

# 2. No satellite, parar o servico
ssh <node> 'systemctl stop linstor-satellite'

# 3. Recriar o node no controller
linstor node create <node> <ip-linstor> --node-type combined

# 4. Recriar storage-pool
linstor storage-pool create lvmthin <node> ssd-pool linstor_ssd/thinpool

# 5. Subir satellite
ssh <node> 'systemctl start linstor-satellite'

# 6. Validar
linstor node list

Resources DRBD existentes podem precisar de recriacao no banco do novo controller.

Incidente Franca — 2026-05-09

Causa raiz: o node pve-labri-32 (IP LINSTOR 10.10.10.8) tinha linstor-controller habilitado. Em 2026-04-22 ele voltou online brevemente e todos os satellites do cluster Franca (21, 22, 31) reconectaram a ele. O controller do pve-labri-31 marcou todos como OTHER_CONTROLLER e parou de reconectar indefinidamente.

Quando pve-labri-32 foi desligado definitivamente (falha de SSD), os satellites ficaram sem controller. Os DRBD devices continuaram ativos no kernel ate o reboot do pve-labri-21 em 2026-05-09, quando o satellite subiu limpo mas nao encontrou controller.

Sintomas observados:

• linstor node list → todos OFFLINE(OTHER_CONTROLLER) ha 17 dias
• linstor resource list --faulty → pm-0b7aea23, vm-103-cloudinit em Unknown
• linstor_storage desapareceu da interface Proxmox (ver secao abaixo)
• drbdadm status no pve-labri-21 → No currently configured DRBD found

Resolucao:

# No pve-labri-31 (controller principal do cluster Franca)
systemctl restart linstor-controller

# Resultado apos ~10s:
# pve-labri-21 → Online
# pve-labri-22 → Connected → Online
# pve-labri-31 → Online
# Recursos com falha → nenhum

Licao: desabilitar linstor-controller em nodes que nao sao o controller designado. Em Franca, so pve-labri-31 deve ter o servico habilitado.

# Em pve-labri-32 apos reinstalacao (e qualquer node nao-controller)
ssh root@192.168.0.32 'systemctl disable --now linstor-controller'

linstor_storage sumiu da interface Proxmox

Sintoma: o storage linstor_storage nao aparece no Datacenter > Storage da interface web do Proxmox. VMs que usam esse storage aparecem com disco inacessivel.

Causa: a entrada linstor_storage foi removida (ou nunca foi adicionada) de /etc/pve/storage.cfg. O plugin linstor-proxmox (tipo drbd no Proxmox) precisa estar registrado via pvesm.

Verificar:

# No qualquer node do cluster Franca (nao no jump host pve-labri-25)
pvesm status | grep linstor

# Ver storage.cfg
grep -A8 linstor /etc/pve/storage.cfg

Atenção: ao rodar pvesm status de um node que nao esta na lista nodes: do storage, ele aparece como disabled. Isso nao e erro — rodar de pve-labri-21, 22 ou 31.

Adicionar o storage de volta (cluster Franca):

pvesm add drbd linstor_storage \
  --controller 10.10.10.7 \
  --resourcegroup pve-rg \
  --content images \
  --nodes pve-labri-21,pve-labri-22,pve-labri-31

Parametros do cluster Franca:

Parametro	Valor
tipo	drbd (nome do plugin linstor-proxmox)
storage ID	linstor_storage
controller	10.10.10.7 (pve-labri-31)
resource group	pve-rg
nodes	pve-labri-21, pve-labri-22, pve-labri-31

Validar:

# Deve mostrar "active" com capacidade
ssh root@192.168.0.21 'pvesm status | grep linstor'
# linstor_storage  drbd  active  3515449344  ...

DRBD verify (integridade online)

O que e: DRBD compara checksums de blocos entre peers em background, sem interromper I/O. Detecta bit-rot silencioso (NVMe/SSD podem corromper blocos sem o controller reportar erro).

Por que importa: replicacao protege contra falha de disco/node, mas nao detecta corrupcao silenciosa — se 1 bloco vira ruido, DRBD replica esse ruido pros peers. verify e o unico mecanismo nativo pra detectar isso.

Disparar verify manual

# Verifica 1 resource (compara entre todos os peers diskful)
drbdadm verify <resource>

# Acompanhar progresso
drbdadm status <resource>
# Mostra "verified:X.XX%"

# Logs com mismatches detectados
journalctl --since "1 hour ago" | grep -E 'verify|out-of-sync'

Interpretar resultado

[node1] kernel: drbd <resource>/0 drbd1002: Online verify found 0 4k blocks out of sync

• 0 blocks out of sync → integridade OK
• > 0 blocks out of sync → corrupcao silenciosa detectada, blocos divergem entre peers

Resolver mismatches

Quando verify encontra blocos divergentes, DRBD nao corrige automaticamente — apenas reporta. Voce precisa decidir qual lado e o “verdadeiro” e ressincronizar:

# 1. Identificar qual peer tem dados confiaveis (geralmente o Primary, ou comparar com backup)

# 2. Forcar resync a partir desse peer (perde os mismatches do outro lado)
# No lado "perdedor":
drbdadm invalidate <resource>
# DRBD vai ressincronizar tudo do peer

# 3. Apos resync, rodar verify de novo pra confirmar
drbdadm verify <resource>

Schedule recomendado

LINBIT recomenda verify semanal ou mensal. Pode rodar via cron no controller:

/etc/cron.d/drbd-verify

# Toda terca-feira as 3h, verify de todos os resources
0 3 * * 2 root for r in $(linstor resource list-volumes -p | awk -F'|' 'NR>1 && /UpToDate/ {print $2}' | sort -u); do drbdadm verify "$r"; sleep 60; done

Verify consome banda na rede LINSTOR (~10-30% do c-max-rate). Rodar em janela de baixo I/O.

Algoritmo de verify

DRBD suporta varios algoritmos hash:

# Configurado em SP (LINSTOR controller property)
linstor controller list-properties | grep verify-algo
# DrbdOptions/auto-verify-algo-allowed-list: crct10dif;crc32c;sha384;sha512;sha256;sha1;md5;windrbd

# Forcar algoritmo especifico (se quiser FIPS-compliant)
drbdadm net-options --verify-alg=sha256 <resource>

crc32c e default — rapido em CPU moderno, sensitividade boa pra detectar bit-rot. sha256 e mais forte mas custa mais CPU.

Monitoring e observabilidade

Metricas criticas pra alarmar

Metrica	Threshold critico	Por que importa
Thin pool Data%	> 80%	Estourar = todas VMs no pool travam
Thin pool Metadata%	> 80%	Estourar = pool travado
Resource em estado Inconsistent	> 5 min	Sync travado, divergencia
Resource em estado StandAlone	> 1 min	Peer disconnect, perda redundancia
Peer disconnect_count	aumenta	Rede instavel
Controller linstor-controller.service	inactive	Cluster sem controle
Quorum DRBD perdido	qualquer	Resource bloqueado, VMs em I/O timeout
drbdadm verify mismatch	> 0 blocks	Corrupcao silenciosa
Replication lag	> N segundos	Possivel async ou rede lenta

LINSTOR Prometheus exporter

LINSTOR controller expoe metricas via /metrics na porta REST API (3370 default):

# Habilitar (se ainda nao ativo)
linstor controller set-property StorDriver/PrometheusEnabled true

# Verificar
curl http://10.10.10.1:3370/metrics | head -30

Metricas expostas (entre outras):

• linstor_resource_state{resource, node} — UpToDate, Inconsistent, etc.
• linstor_storage_pool_capacity_total_bytes
• linstor_storage_pool_capacity_free_bytes
• linstor_node_state{node} — Online, Offline
• linstor_volume_allocated_bytes

DRBD Prometheus exporter

Via drbd-reactor (plugin prometheus) ou drbd_exporter:

# drbd-reactor com plugin prometheus
apt install drbd-reactor
cat > /etc/drbd-reactor.d/prometheus.toml <<EOF
[[prometheus]]
enums = true
address = "0.0.0.0:9942"
EOF
systemctl enable --now drbd-reactor

Metricas DRBD expostas:

• drbd_resource_role
• drbd_peer_disk_state
• drbd_connection_state
• drbd_replication_state
• drbd_oos_blocks (out-of-sync blocks — sinaliza verify mismatch)

Integracao com OpenObserve (ja no parque)

Memory project_infra registra OpenObserve como stack de logs/metricas. Como integrar:

# Em vez de Prometheus puro, usar Vector ou Telegraf que escreve em OpenObserve
# Vector config exemplo:
[sources.linstor]
type = "prometheus_scrape"
endpoints = ["http://10.10.10.1:3370/metrics"]
scrape_interval_secs = 60

[sources.drbd]
type = "prometheus_scrape"
endpoints = ["http://10.10.10.11:9942", "http://10.10.10.12:9942", "http://10.10.10.31:9942"]
scrape_interval_secs = 60

[sinks.openobserve]
type = "http"
inputs = ["linstor", "drbd"]
uri = "https://openobserve.cpps/api/default/_json"
encoding.codec = "json"
auth.strategy = "basic"
auth.user = "..."
auth.password = "..."

Healthcheck script existente

config/scripts/linstor-healthcheck.sh ja existe — verifica:

• Storage Proxmox linstor-ssd-01 ativo
• Nodes LINSTOR Online
• Resources com estado nao-OK

Roda via cron, alerta no Telegraf/OpenObserve. Manter atualizado.

Alertas recomendados (prom rules)

/etc/prometheus/rules/linstor.yml

groups:
- name: linstor
  rules:
  - alert: LinstorThinPoolHigh
    expr: (linstor_storage_pool_capacity_total_bytes - linstor_storage_pool_capacity_free_bytes) / linstor_storage_pool_capacity_total_bytes > 0.8
    for: 10m
    annotations:
      summary: "Thin pool {{ $labels.storage_pool }} > 80% no {{ $labels.node }}"

  - alert: LinstorResourceNotUpToDate
    expr: linstor_resource_state{state!="UpToDate"} == 1
    for: 5m
    annotations:
      summary: "Resource {{ $labels.resource }} em {{ $labels.state }} no {{ $labels.node }}"

  - alert: LinstorNodeOffline
    expr: linstor_node_state{state="Offline"} == 1
    for: 2m
    annotations:
      summary: "Node LINSTOR {{ $labels.node }} offline"

  - alert: DRBDOutOfSyncBlocks
    expr: drbd_oos_blocks > 0
    for: 1m
    annotations:
      summary: "DRBD verify detectou {{ $value }} blocks out-of-sync em {{ $labels.resource }}"

DR drill (teste de recuperacao)

Backup nao testado nao e backup. Cadencia recomendada: trimestral.

Procedimento minimo

1. Escolher 1 resource nao-critico (VM de teste, nao prod)
2. Confirmar shipping recente:

   linstor backup list <remote-name>
   # Procurar timestamp dentro do RPO esperado

3. Restaurar no destino:

   # Destino LINSTOR cluster:
   linstor backup restore <remote> <target-node> \
     --resource <new-resource-name> \
     --target-storage-pool ssd-pool
   
   # Destino S3:
   linstor backup restore <remote> <target-node> \
     --resource <new-resource-name> \
     --id <backup-id-do-S3>

4. Validar: criar VM Proxmox apontando pro novo resource, bootar, verificar dados
5. Documentar tempos: RPO real vs esperado, RTO real
6. Limpar: remover resource temporario apos drill

Template de relato (preencher trimestralmente)

## DR drill YYYY-MM-DD

**Resource testado**: <res>
**Origem**: <cluster A>
**Destino**: <cluster B>
**RPO esperado**: 6h     **RPO real**: __h __min
**RTO esperado**: 30min  **RTO real**: __min
**Falhas encontradas**: <lista>
**Acoes corretivas**: <lista>
**Proximo drill**: YYYY-MM-DD

Referencias

• Conceitos: linstor-conceitos.md
• Operacao cotidiana: linstor-operacoes.md
• Estrategia: storage-strategy.md
• DRBD verify upstream: https://linbit.com/drbd-user-guide/drbd-guide-9_0-en/#s-online-verify
• drbd-reactor: https://github.com/LINBIT/drbd-reactor
• LINSTOR REST API: https://linbit.com/drbd-user-guide/linstor-guide-1_0-en/#s-rest_api