Estratégia de Storage

Estrategia de storage — SP, Franca e cross-site

Documento de decisao sobre escolha de tecnologias de storage pra infra UNESP CPPS/IPPRI: por que usamos o que usamos, quando faria sentido trocar, e como replicar entre os 2 sites.

Complementa linstor-conceitos.md (conceitos tecnicos) e rede-sp.md (topologia).

Contexto

Dois sites Proxmox em UNESP:

SP (clusterippri, 6 nos): infraestrutura central, GPU labs, OpenEdX, CPPS apps, workstations
Franca (cluster-labri, 7-8 nos): laboratorio de pesquisa, gateway, servicos descentralizados

Workloads:

VMs gerais (web, app servers, gateways)
DBs nao-criticos (Postgres, MySQL pra apps academicos)
GPU/ML (training, inference)
File serving (NextCloud)
Containers/K8s control plane (planejado)

Caracteristicas da equipe e contexto:

Equipe pequena, prioriza simplicidade
Orcamento academico — preferir open-source sem subscricao
RPO/RTO toleravel: minutos a horas (nao e high-frequency trading)
Compliance: dados de pesquisa (LGPD) — encriptacao seletiva quando aplicavel

LVM_THIN — por que e a escolha certa pra nos

LINSTOR suporta varios storage providers (ver linstor-conceitos.md#storage-pool-drivers). Pra nosso cenario, LVM_THIN e o padrao adotado.

A favor

Ponto	Por que importa pra nos
Padrao LINBIT — caminho mais testado	Equipe pequena nao tem tempo pra debugar caminhos exoticos
Maturidade no kernel ha anos	Estabilidade > novidade
Snapshots CoW eficientes	Permite rollback rapido em upgrades, testes
Thin provisioning (overcommit)	Util em lab — alocar 200G pra VM que usa 30G
Integra nativo com Proxmox	PVE ja usa LVM em todo lugar — operadores ja conhecem
Operacao simples	`lvs`, `vgs`, `lvextend` — comandos triviais
Performance proxima ao raw NVMe/SSD	Sem overhead significativo do thin layer

Limites a monitorar

Limite	Impacto se ignorado	Mitigacao
Thin pool pode estourar	Todas VMs no pool travam — recovery dolorosa	Alarme em 70-80% + `MaxOversubscriptionRatio` no LINSTOR
Sem checksums	Corrupcao silenciosa nao detectada	Backup com checksum (PBS faz)
Sem dedup	VMs identicas ocupam 1x cada (sem economia)	Aceitar — dedup vive na camada de backup (PBS)
Snapshots crescem linear	Reter muitos snapshots no pool consome espaco	Politica de retencao curta (7 dias local)

Quando outras opcoes caberiam (e por que nao no nosso caso)

Alternativa	Cenario que justificaria	Aplicavel a nos?
LVM thick	DB transacional sensivel a latencia cauda (trading, telecom)	Nao — workloads acadamicos toleram thin
ZFS_THIN	Quer dedup, checksums, snapshots avancados	Nao — sync semantics do ZFS interagem mal com DRBD sync (workarounds existem mas LINBIT recomenda LVM_THIN); complexidade operacional adicional sem ganho claro pra nosso perfil
dm-cache / bcache	Mix HDD + NVMe pra reduzir custo $/TiB	Nao hoje — parque so NVMe/SSD. Reconsiderar se entrar HDD pra archive
SPDK	Latencia sub-microssegundo userspace	Overkill — academico nao precisa
EXOS / EBS / OPENFLEX	Storage array gerenciado externo	Nao — nao temos esse hardware

Veredito: LVM_THIN. Nao ha ganho real em trocar. Risco principal e o thin pool estourar — ja documentado em linstor-conceitos.md#over-provisioning-ratios.

LINSTOR cross-site SP↔Franca — 3 modos possiveis

Distancia: ~440 km. Link UNESP via RNP/IPÊ. RTT estimado 5-15ms (medir antes de dimensionar). Banda: provavel 1G compartilhado.

Modo A — Cluster LINSTOR unico cross-site (sync)

Nao funciona pra producao. Razoes:

DRBD Protocolo C (sync) exige RTT baixo. WAN 5-15ms vs LAN 0.05ms = writes 100-300x mais lentos.
Cada commit em DB transacional fica esperando ack remoto — latencia se acumula.
Quorum cross-site fragil — particao de WAN partiona o cluster (split-brain entre sites).
Corosync/Proxmox cluster nao foi desenhado pra WAN.

Veredito: descartar.

Modo B — 2 clusters LINSTOR + DRBD Proxy (async, comercial)

Funciona tecnicamente. Comercial.

DRBD Proxy e um daemon que:

Bufferiza writes localmente em RAM
Comprime + envia em batch via WAN
Opera em Protocolo A (async) — ack apos buffer local
Tolera glitches de rede sem disconnect

Resultado:

Cada site tem cluster proprio (HA local independente)
Resources selecionados sao replicados async pro outro site
RPO de minutos, RTO de minutos (failover assistido)

Custo: DRBD Proxy e parte do LINBIT SDS pago (subscricao anual por node). Nao e gratuito.

Veredito: descartar por custo. Reconsiderar se UNESP comprar subscricao LINBIT pra producao critica.

Modo C — 2 clusters LINSTOR + snapshot shipping (free)

Funciona, recomendado pra nos. Cada site e um cluster LINSTOR independente; snapshots sao enviados periodicamente pro outro:

SP cluster ─── snapshot ship (cron 6h) ──→ Franca cluster
                                              (storage cold/DR)
Franca cluster ─── snapshot ship ──────────→ SP cluster

Como funciona (sintaxe validada no client v1.27):

# 1. Configurar remote no SP apontando pra Franca (URL HTTP do controller remoto)
linstor remote create linstor franca-cluster http://<ip-controller-franca>:3370

# 2. Criar schedule (full_cron e POSITIONAL, nao --full-cron)
linstor schedule create dr-franca "0 2 * * 0" \
  -i "0 */6 * * *" \
  -l 7 -r 14 \
  --on-failure RETRY --max-retries 3

# 3. Aplicar ao resource group de VMs criticas
#    Sintaxe: backup schedule enable <remote_name> <schedule_name> --rg <rg>
linstor backup schedule enable franca-cluster dr-franca --rg sp-ssd-replicated

Caracteristicas:

RPO: definido pelo cron (6h, 24h, etc.)
RTO: tempo pra importar snapshot + subir VM (~minutos a horas)
Custo: zero (feature open-source LINSTOR)
Banda: incremental + compressao — transfere so delta
Robustez: tolera glitches WAN — snapshot e atomico, retry trivial
Nao exige link sempre-on

Limites:

Nao e RPO 0 — janela de perda igual ao intervalo
Restore exige passos manuais (importar, criar resource, anexar a VM)
Nao testa automaticamente — precisa drill periodico

Veredito: implementar este modo pra DR de VMs criticas (CPPS, gateway, OpenEdX).

Comparacao das 3 opcoes

Opcao	RPO	RTO	Custo	Quando
A Sync cross-site	0	imediato	inviavel tecnicamente	nunca
B DRBD Proxy async	minutos	minutos	$$$ subscricao	producao critica + budget
C Snapshot shipping	horas	horas	$0	nosso caso

Outras tecnologias — onde se encaixam

Categorizando alternativas por funcao:

Block storage primario (substituir LINSTOR)

Tecnologia	Pros	Contras	Quando trocariamos
Ceph	Madurissimo, S3+block+FS, scale a PB, erasure coding	Complexidade alta, RAM/CPU pesado, latencia maior	Cluster passar de ~5 nodes E equipe se tornar familiar com Ceph
GlusterFS	Simples, scale-out	Performance inferior, suporte Red Hat reduzido	Nao consideraria mais
OpenEBS / Longhorn	K8s-native	So pra K8s, nao serve VMs Proxmox	So se migrar tudo pra K8s
MooseFS / LizardFS / SeaweedFS	Simples, niche	Adocao baixa, ecossistema pequeno	Nicho, nao recomendo
PVE Storage Replication (ZFS-based)	Built-in PVE, simples (`zfs send/receive`)	Async only, sem HA real, RPO ~1min	Substituiria LINSTOR se simplicidade > HA online

Realidade: LINSTOR cobre block storage HA pra VMs muito bem no nosso tamanho. Ceph seria a unica substituicao “completa” e so compensa em escala bem maior (10+ nodes, multi-PB).

Backup (camada 3 do 3-2-1)

Tecnologia	Pros	Contras	Recomendacao
Proxmox Backup Server (PBS)	Native PVE, dedup, incremental forever, restore granular, sync entre PBS	Mais um servico pra operar	Padrao recomendado — adotar
vzdump + S3	Simples, sem servico extra	Sem dedup, restore lento, full a cada vez	Aceitavel pra escala pequena
Borg/Restic + S3	Dedup, encryption, off-site	Pra arquivos, nao block VMs	Complementa PBS pra dados nao-VM
Velero (K8s)	K8s-native	So K8s	Nao se aplica

Object storage (S3-compativel)

Tecnologia	Pros	Contras	Quando
MinIO local	S3 puro, simples, performante, single binary	Mais um servico	Datasets pesquisa, NextCloud, backup PBS off-site
Ceph RGW	Junto com Ceph block	So se ja tem Ceph	Nao recomendaria implantar Ceph so por isto
AWS S3 / Wasabi / Backblaze B2	Off-site real, sem operacao	Custo recorrente, banda	Backup imutavel cross-region (compliance)
SeaweedFS	Object + filer leve	Maturidade menor	Lab, evitar em producao

Filesystem distribuido (NFS/POSIX)

Tecnologia	Pros	Contras	Quando
NFS classico	Universal, simples	Single-server, nao HA por padrao	Shares pequenos entre VMs
CephFS	POSIX HA, scale	Requer Ceph cluster	So se ja tem Ceph
GlusterFS	Scale-out POSIX	Suporte reduzido	Nao recomendo novos deploys
JuiceFS	POSIX sobre object storage	Latencia metadata	Lab, casos especificos

Network/CNI (nao e storage)

Cilium e CNI Kubernetes (eBPF-based). Resolve conectividade entre pods, nao storage. Confusao comum porque tem features de mesh.

Feature Cilium	Resolve o que	Substitui LINSTOR?
ClusterMesh	Interconectar clusters K8s, replicar services	Nao — services, nao volumes
Hubble	Observability de rede	Nao — diagnostico, nao storage
Service Mesh	mTLS, policies entre apps	Nao — rede

Cross-site networking (separado de storage) usaria: WireGuard / IPSec / OpenVPN site-to-site, ou link MPLS dedicado da RNP. Independente da decisao de storage.

Arquitetura recomendada

Stack alvo pra SP + Franca:

SITE SP                                  SITE FRANCA
─────────────────────────                ─────────────────────────

LINSTOR cluster SSD (atual)              LINSTOR cluster NVMe (apos reset)
  pve-ippri-11/12/31 COMBINED              pve-labri-21/22/31[/33] COMBINED
  HA via VIP 10.10.10.1                    HA via VIP 10.10.10.1 (sera criado)
  rede 10G dedicada 10.10.10.0/24          rede 10G dedicada 10.10.10.0/24
  PlaceCount 2 + TieBreaker                PlaceCount 2 + TieBreaker
  LVM_THIN (linstor_ssd/thinpool)          LVM_THIN (linstor_franca/thinpool)
       │                                          │
       │     LINSTOR snapshot shipping            │
       │     (cron 6h-24h, incremental)           │
       │  ◄────────────────────────────────────►  │
       │                                          │
       │                                          │
PBS (Proxmox Backup Server)              PBS (Proxmox Backup Server)
  VM dedicada com storage HDD              VM dedicada com storage HDD
  Backup diario de VMs criticas            Backup diario de VMs criticas
       │                                          │
       │       PBS sync (nativo)                  │
       │  ◄────────────────────────────────────►  │
       │                                          │
       │                                          │
MinIO (opcional, pra datasets)           MinIO (opcional, pra datasets)
  Buckets: pesquisa, modelos-ml,           Buckets: pesquisa, modelos-ml,
  nextcloud-objstore, pbs-cold             nextcloud-objstore, pbs-cold
       │                                          │
       └──── PBS pode dump em S3/MinIO ───────────┘
              (camada 4 — backup imutavel
               cross-site retencao longa)

O que isso entrega

Cenario de falha	Protege?	Como
1 disco falha	✓	DRBD replica no peer
1 node morre	✓	LINSTOR HA, VIP migra, VMs continuam
2 nodes morrem mesmo site	parcial	I/O bloqueia ate 1 voltar (quorum). Sem perda de dados
Site SP inteiro cai	✓	Snapshot shipping em Franca → restaurar VMs criticas; PBS sync tem backup completo
Ransomware na infra Proxmox	✓	PBS com `--no-overwrite` + retencao longa em MinIO/S3
Operador apaga VM	✓	PBS retem dump diario + LINSTOR snapshots locais
Bug que corrompe DB	✓	LINSTOR snapshots locais (rollback rapido) + PBS (granular)
`rm -rf` dentro da VM	✓	PBS restore do dia anterior

Custo de implementacao

Item	Trabalho	Quando
Reset LINSTOR Franca alinhado a SP	medio (1-2 dias)	em andamento (`feat/renumeracao-sp`)
Configurar VIP HA controller Franca	baixo (horas)	parte do reset
Criar resource groups + anti-afinidade Franca	baixo	parte do reset
Subir PBS em SP e Franca	medio (1 dia cada)	apos reset
Configurar snapshot shipping LINSTOR cross-site	baixo (horas)	apos PBS
Configurar PBS sync cross-site	baixo	apos PBS
MinIO local (opcional)	baixo	quando precisar
Drill de DR (testar restore)	medio (1 dia)	trimestral

Total: ~1 semana de trabalho pra estado-alvo, distribuido em fases.

Decisoes pendentes (a confirmar)

Numero de nodes COMBINED em Franca: 3 (.21, .22, .31) ou 4 (incluir .33)?
- 3 = aguenta 1 falha, paridade com SP
- 4 = aguenta 1 falha por volume, mas controller-DB pode ir a PlaceCount 3 (aguenta 2 falhas no controle)
Esquema de IPs LINSTOR Franca: padronizar 10.10.10.{node-id} (alinhar com SP) ou manter atual (.5/.6/.7)?
Onde vai morar o PBS em cada site? VM dedicada num node especifico? Hardware separado?
MinIO: implantar agora ou adiar ate primeiro use case (NextCloud ou similar)?
Encriptacao LUKS: aplicar em algum pool especifico (dados pesquisa LGPD)?
DR drill cadence: trimestral, semestral?

Referencias

linstor-conceitos.md — conceitos LINSTOR/DRBD detalhados
linstor-sp.md — topologia LINSTOR SP atual
rede-sp.md, rede-10g-sp.md — topologia de rede SP
linstor-operacoes.md — runbook operacional
LINBIT user guide: https://linbit.com/drbd-user-guide/linstor-guide-1_0-en/
LINSTOR backup shipping: https://linbit.com/drbd-user-guide/linstor-guide-1_0-en/#s-linstor-snapshots
DRBD Proxy (comercial): https://linbit.com/drbd-user-guide/drbd-proxy-3_0-en/
Proxmox Backup Server: https://pbs.proxmox.com/docs/
MinIO: https://min.io/docs/minio/linux/index.html