Storage não é apenas capacidade em terabytes. É uma disciplina de risco: disponibilidade, consistência, desempenho, recuperabilidade, segurança e custo ao longo do ciclo de vida precisam ser projetados em conjunto. Este guia percorre os fundamentos de DAS, NAS e SAN, os protocolos de bloco, a arquitetura de alta disponibilidade, o TrueNAS e o OpenZFS, dimensionamento, segurança, continuidade, hardware, operação, TCO e arquiteturas de referência.
Sobre este material: valores de desempenho são referências de engenharia, não garantias. O resultado real depende de discos, controladoras, rede, padrão de I/O, firmware, sistema operacional e testes de aceitação. Recursos e licenciamento do TrueNAS podem mudar — confirme a documentação e a matriz de suporte antes da compra.
Sumário executivo
A decisão de storage deve começar pelo impacto da indisponibilidade e da perda de dados, não pelo preço por terabyte. A diretoria precisa decidir quais aplicações são críticas e qual o custo por hora de parada, qual RPO (perda máxima de dados) e RTO (tempo máximo de recuperação) o negócio aceita, se a operação exige controladoras redundantes, suporte 24x7 e peças em SLA, se a carga é dominada por capacidade, IOPS, throughput ou latência, e se o crescimento será vertical (expansão do pool) ou horizontal (novos sistemas).
| Decisão | Pergunta-chave | Impacto |
|---|---|---|
| Disponibilidade | Controladora única ou HA? | CAPEX versus risco operacional |
| Mídia | HDD, SSD ou NVMe? | Custo/TB, latência e endurance |
| Protocolo | FC, iSCSI, NVMe-oF, NFS ou SMB? | Integração e complexidade |
| Proteção | Snapshot, réplica e backup? | RPO/RTO e resiliência a ransomware |
| Suporte | Community ou Enterprise? | Responsabilidade e tempo de recuperação |
Recomendação executiva: para produção crítica, trate HA, multipath, backup imutável ou isolado, monitoramento e teste de restauração como requisitos básicos, não opcionais.
Fundamentos: DAS, NAS e SAN
Os três modelos podem coexistir. A diferença principal é onde o armazenamento é apresentado e quem controla o sistema de arquivos.
| Modelo | Apresentação | Protocolos comuns | Melhor uso |
|---|---|---|---|
| DAS | Disco/bloco local | SAS, SATA, NVMe | Baixa complexidade; host único |
| NAS | Arquivo compartilhado | SMB, NFS | Colaboração, home directories, repositórios |
| SAN | Bloco remoto | FC, iSCSI, NVMe-oF | Virtualização, bancos, clusters |
Os conceitos essenciais: LUN/namespace é a unidade lógica apresentada ao host; initiator é o cliente que inicia a sessão, target é o storage que entrega o bloco; fabric é o conjunto redundante de switches e enlaces de uma SAN FC; zoning limita a visibilidade na fabric, masking limita quais hosts acessam cada LUN; e MPIO mantém múltiplos caminhos e pode balancear I/O conforme a política.
Erro clássico: SAN não substitui backup. Um LUN replicado pode replicar corrupção, exclusão, criptografia maliciosa e erros humanos.
Protocolos de bloco em profundidade
Escolher o protocolo é escolher um ecossistema de latência, rede, operação e compatibilidade.
| Critério | Fibre Channel | iSCSI | NVMe-oF |
|---|---|---|---|
| Transporte | Fabric FC dedicada | Ethernet/TCP | TCP ou RDMA |
| Latência | Baixa e previsível | Boa; depende da pilha TCP | Muito baixa, especialmente RDMA |
| Operação | Especializada | Familiar à equipe IP | Exige maturidade e compatibilidade |
| Custo | Maior | Menor/gradual | Variável; rede de alto desempenho |
| Uso típico | Core corporativo | Virtualização e midmarket | All-flash e workloads exigentes |
Fibre Channel usa WWPNs, HBAs, switches e fabrics independentes A/B. O desenho recomendado evita qualquer componente único: cada host possui caminhos para ambas as fabrics e cada controladora do storage se conecta às duas. Zoning single-initiator/single-target reduz o domínio de falha e simplifica o diagnóstico.
iSCSI transporta comandos SCSI sobre TCP/IP. Separe o tráfego de storage em VLANs/sub-redes próprias, distribua sessões por switches distintos e implemente MPIO — LACP não substitui multipath para disponibilidade de caminhos fim a fim. NVMe over Fabrics leva as filas paralelas do NVMe pela rede, podendo usar TCP ou RDMA; valide a compatibilidade de toda a pilha.
Arquitetura SAN: alta disponibilidade
Disponibilidade real depende da eliminação de pontos únicos no caminho completo. Os princípios de desenho: duas fabrics totalmente independentes, sem interligar Fabric A e B; dois HBAs ou duas portas independentes por host, preferencialmente em barramentos distintos; controladoras de storage redundantes e caminhos ativos testados; fontes, PDUs, UPS e circuitos A/B, com monitoramento da cadeia elétrica; zoning e LUN masking documentados por host/cluster; e teste de falha de cabo, porta, switch e controladora antes da produção.
| Falha simulada | Resultado esperado | Evidência |
|---|---|---|
| Cabo/HBA | I/O continua pelo caminho alternativo | Log MPIO + latência |
| Switch de fabric | Sem perda de volume | Alarme e failover |
| Controladora | Trespasse dentro do SLA | Tempo e eventos |
| Disco/vdev | Pool permanece online/degradado | Alerta + resilver |
| Energia A | Operação via alimentação B | Telemetria PDU/UPS |
Desempenho e sizing
Capacidade útil e desempenho devem ser calculados separadamente — um pool pode ter muitos terabytes e ainda ser inadequado para o perfil de I/O. Quatro métricas centrais: IOPS (operações por segundo, importante para I/O pequeno e aleatório), throughput (MB/s ou GB/s, importante para streaming, backup e mídia), latência (tempo por operação, avaliada em média e percentis p95/p99), e fila (profundidade de comandos simultâneos, que pode elevar throughput e também esconder saturação).
Relação aproximada: IOPS = throughput / tamanho médio do bloco. Exemplo: 1 GB/s com blocos de 128 KiB representa cerca de 8.000 IOPS. Para HDDs, espelhos entregam mais IOPS aleatórios que RAIDZ com o mesmo número de discos; para SSD/NVMe, controladora, CPU, PCIe e rede frequentemente tornam-se o gargalo.
| Camada | Coletar | Por quê |
|---|---|---|
| Aplicação | IOPS, bloco, leitura/escrita, sync | Define o comportamento real |
| Host | fila, latência, multipath | Detecta caminho/gargalo |
| Rede | utilização, drops, retransmissões | Valida transporte |
| Storage | ARC, discos, pool, CPU | Localiza saturação |
| Proteção | snapshots, réplica, scrub | Inclui carga de manutenção |
Regra de capacidade: planeje espaço livre operacional. Pools muito cheios perdem flexibilidade e podem degradar; adote alertas e uma política de expansão antes do limite.
TrueNAS e seu papel
TrueNAS transforma hardware compatível em uma plataforma de storage baseada em OpenZFS, com serviços de arquivo, bloco, proteção de dados, integração e automação.
| Edição | Posicionamento | Uso recomendado |
|---|---|---|
| Community Edition | Software aberto, implantação autogerida | Lab, edge, backup e produção com risco aceito |
| Enterprise | Appliances validados, recursos empresariais e suporte | Missão crítica, HA e responsabilidade de fabricante |
Os serviços e integrações incluem bloco (iSCSI; Fibre Channel e NVMe-oF dependem da edição, release, hardware e licenciamento suportados), arquivo (SMB e NFS, com ACLs e integração a serviços de diretório), objeto e aplicações (capacidades variam por versão — separe workloads de apps do storage crítico), proteção (snapshots ZFS, replicação, rsync e tarefas de sincronização em nuvem) e gestão (interface web, alertas, API e integração com TrueCommand conforme o cenário).
Decisão de governança: "funciona em hardware genérico" não equivale a "possui suporte fim a fim". Para workloads críticos, valide HCL, firmware, controladoras, NICs/HBAs, enclosure e SLA.
OpenZFS: integridade por projeto
ZFS combina gerenciador de volumes e sistema de arquivos. Seu modelo copy-on-write evita sobrescrever blocos ativos e permite snapshots consistentes no nível do storage. Os componentes: pool (conjunto de vdevs — a falha de um vdev de dados pode comprometer todo o pool), vdev (unidade de redundância: mirror, RAIDZ1, RAIDZ2 ou RAIDZ3), dataset (sistema de arquivos com propriedades próprias), zvol (volume de bloco, normalmente usado para iSCSI/FC), checksum (detecta corrupção; a redundância permite autorreparo) e scrub (leitura/verificação periódica de dados e metadados).
| Layout | Tolerância por vdev | Ponto forte | Atenção |
|---|---|---|---|
| Mirror | 1 disco por par (típico) | IOPS e rebuild rápido | 50% de eficiência bruta |
| RAIDZ1 | 1 disco | Capacidade em grupos menores | Margem reduzida em discos grandes |
| RAIDZ2 | 2 discos | Equilíbrio capacidade/proteção | Menos IOPS aleatórios |
| RAIDZ3 | 3 discos | Proteção elevada | Maior overhead |
A capacidade e o desempenho agregam por vdev, mas a redundância é local a cada vdev. Expansão deve preservar simetria e previsibilidade. Evite misturar discos de capacidades, desempenho e endurance muito diferentes sem uma justificativa testada.
ARC, L2ARC, ZIL, SLOG e special vdev
Os dispositivos auxiliares do ZFS resolvem problemas específicos. Adicioná-los sem medir pode reduzir desempenho ou criar risco.
| Recurso | Função | Quando ajuda | Risco/observação |
|---|---|---|---|
| ARC | Cache primário em RAM | Quase sempre | RAM é mais rápida que L2ARC |
| L2ARC | Cache secundário de leitura | Working set maior que ARC | Consome RAM para metadados |
| ZIL | Log de writes síncronos | Semântica de sync | Existe no pool mesmo sem SLOG |
| SLOG | Dispositivo separado do ZIL | Writes síncronos intensos | Exige baixa latência e PLP |
| Special vdev | Metadados e opcionalmente blocos pequenos | Pools de arquivos/metadados | Deve ter redundância robusta |
SLOG não é cache geral de escrita e não acelera writes assíncronos — o requisito crítico é persistência segura sob perda de energia, baixa latência e endurance. L2ARC só deve ser adotado após confirmar misses relevantes no ARC e working set reutilizável.
Cuidado crítico: a perda irrecuperável de um special vdev pode comprometer o pool. Espelhe-o adequadamente e trate-o como parte dos dados, não como cache descartável.
TrueNAS como SAN iSCSI
Para apresentar bloco, o TrueNAS cria um zvol ou extent e o associa a target, portal e initiators autorizados.
O fluxo lógico: criar pool e zvol com volblocksize alinhado ao workload; configurar o portal em interfaces/VLANs de storage; definir initiators e autenticação quando aplicável; criar target, extent e a associação target-extent; apresentar múltiplos caminhos e configurar MPIO no host; e criar o filesystem/datastore no host — nunca montar o mesmo LUN em múltiplos hosts sem filesystem de cluster.
| Rede | Subnet | Uso |
|---|---|---|
| Storage A | 10.20.10.0/24 | Caminho iSCSI A |
| Storage B | 10.20.20.0/24 | Caminho iSCSI B |
| Gestão | 10.20.30.0/24 | GUI, API, monitoramento |
| Replicação | 10.20.40.0/24 | Tráfego entre storages |
Jumbo frames: MTU 9000 só traz benefício quando configurado e validado de ponta a ponta. Inconsistência de MTU causa falhas difíceis de diagnosticar; MTU 1500 bem projetado é preferível a jumbo parcial.
Rede Ethernet para storage
A rede deve ser não bloqueante no tráfego esperado e previsível durante falhas e manutenção. Boas práticas: use switches redundantes e caminhos IP distintos para MPIO; separe gestão, dados, replicação e clientes quando o risco justificar; dimensione buffers e uplinks para microbursts e oversubscription; monitore drops, erros, retransmissões, pause frames e latência; RSS/multiqueue e afinidade de CPU podem importar em 25/40/100 GbE; e evite alterar flow control, offloads ou congestion control sem baseline e teste.
| Link nominal | Útil teórico aproximado | Aplicação típica |
|---|---|---|
| 10 GbE | ~1,1 GB/s | HDD híbrido, backup, midmarket |
| 25 GbE | ~2,8 GB/s | All-flash e virtualização |
| 40 GbE | ~4,5 GB/s | Agregação/legado de alta banda |
| 100 GbE | ~11 GB/s | NVMe, IA, consolidação |
Os valores úteis são aproximações e variam com overhead, MTU, CPU, protocolo e padrão de I/O. Dois links não significam automaticamente o dobro por fluxo — valide o comportamento do MPIO e o número de sessões.
Segurança, identidade e ransomware
A estratégia deve impedir que uma credencial comprometida destrua produção, snapshots e backups ao mesmo tempo. Os controles prioritários: MFA para administração e contas nominativas com menor privilégio; rede de gestão restrita, com acesso via bastion/VPN e logs centralizados; CHAP em iSCSI quando aplicável, zoning/masking rigorosos em FC; criptografia em trânsito e em repouso conforme risco e compliance; snapshots com retenção definida, réplica para domínio administrativo distinto e cópia offline/imutável; backups de configuração e chaves de criptografia testados; e atualização por janela, revisão de advisories e rollback planejado.
| Camada | Controle | Teste |
|---|---|---|
| Prevenção | segmentação, MFA, hardening | revisão trimestral |
| Detecção | alertas, SIEM, anomalias | simulação controlada |
| Contenção | credenciais e rede separadas | tabletop exercise |
| Recuperação | 3-2-1-1-0 e runbook | restore periódico |
3-2-1-1-0: três cópias, duas mídias, uma externa, uma offline/imutável e zero erros verificados após testes. Snapshot local é uma camada, não toda a estratégia.
Continuidade: RPO, RTO e DR
Recuperação é uma capacidade operacional comprovada, não a existência de uma réplica.
| Mecanismo | Protege contra | Não resolve sozinho |
|---|---|---|
| RAID/ZFS | falha de mídia | exclusão, ransomware, desastre |
| Snapshot | erro lógico e rollback rápido | perda do mesmo sistema |
| Réplica | falha de site/storage | corrupção replicada |
| Backup imutável | ataque e retenção | RTO sem automação |
| DR orquestrado | indisponibilidade ampla | dados sem proteção adequada |
O runbook mínimo: declarar o evento e congelar mudanças; confirmar o último ponto íntegro e o escopo afetado; isolar a origem do incidente; promover a réplica ou restaurar em ambiente limpo; validar consistência técnica e da aplicação; redirecionar clientes e monitorar; e registrar tempos reais, lacunas e ações corretivas.
RPO de 15 minutos exige frequência e transporte compatíveis. RTO de 2 horas inclui detecção, decisão, provisionamento, restauração, validação e retorno do serviço — não apenas copiar bytes.
Hardware: desenho de plataforma
Storage é um sistema integrado. CPU, memória, PCIe, HBA, backplane, enclosure, discos e firmware precisam formar uma configuração validada.
| Componente | Critério |
|---|---|
| CPU | clock por thread, núcleos, PCIe lanes, criptografia/compressão |
| RAM ECC | ARC, metadados, dedup e margem operacional |
| HBA SAS | modo adequado/JBOD, firmware compatível, filas |
| NIC/HBA FC | velocidade, offloads, drivers, transceivers |
| Discos HDD | CMR, vibração, URE, workload rating |
| SSD/NVMe | DWPD/TBW, latência sustentada, PLP, térmica |
| Boot | dispositivo dedicado; espelhamento conforme criticidade |
| Enclosure | SAS dual-path, expander, SES, cooling e PSU A/B |
A documentação atual do TrueNAS informa mínimo de 8 GB de RAM, SSD de boot de 20 GB e dois dispositivos de mesmo tamanho para um pool básico — isso é mínimo funcional, não sizing de produção. A própria orientação oficial desaconselha mídia SMR para ZFS e destaca PLP para SLOG.
ECC: reduz o risco de corrupção silenciosa na memória e é fortemente recomendada em storage corporativo. Ela não substitui checksum, redundância ou backup.
Operação, monitoramento e manutenção
O objetivo é detectar degradação antes que ela vire indisponibilidade e executar manutenção sem improviso. Os indicadores: capacidade lógica/física, tendência e taxa de mudança; latência média/p95/p99, IOPS, throughput e filas; ARC hit ratio contextualizado, uso de RAM e CPU; SMART/NVMe health, temperatura, wear, erros SAS e checksum; estado do pool, scrub, resilver e snapshots; sessões, caminhos MPIO, erros de fabric/rede e drops; e sucesso, atraso e duração de backup/replicação.
| Periodicidade | Rotina |
|---|---|
| Contínua | alertas, saúde, capacidade, caminhos |
| Semanal | falhas de jobs, tendências, tickets |
| Mensal | scrub conforme política, revisão de capacidade |
| Trimestral | teste de failover e restore amostral |
| Semestral | DR, firmware, matriz de compatibilidade |
| Anual | revisão de arquitetura e ciclo de vida |
Nas mudanças, mantenha inventário, diagrama, matriz host-LUN-WWPN/IQN, baseline, backup de configuração, plano de rollback e critérios de sucesso. Atualizações de storage devem respeitar a matriz combinada de firmware, sistema, HBA/NIC, switch e multipath.
TCO, licenciamento e modelo de decisão
O menor CAPEX pode produzir maior custo total quando transfere risco e esforço para a equipe interna.
| Componente TCO | Incluir |
|---|---|
| Aquisição | chassis, discos, NIC/HBA, switches, ópticos, licenças |
| Operação | energia, refrigeração, rack, monitoramento, pessoal |
| Proteção | segundo storage, backup, nuvem, mídia externa |
| Suporte | SLA, peças, atualização e assistência |
| Risco | downtime, perda de dados, reputação e penalidades |
| Ciclo de vida | expansão, migração, descarte e renovação |
Na pontuação sugerida, atribua peso de 1 a 5 para disponibilidade, desempenho, capacidade, integração, segurança, suporte, expansão e TCO; pontue cada alternativa de 1 a 5, multiplique pelo peso e registre evidências; reprove previamente qualquer solução que não cumpra requisitos eliminatórios.
TrueNAS versus SAN proprietária: o TrueNAS pode oferecer excelente economia e flexibilidade; uma SAN de fabricante pode reduzir integração, suporte e risco operacional. A comparação correta é por SLA e ciclo de vida, não apenas R$/TB.
Implantação passo a passo
Uma implantação segura avança por gates: requisitos, desenho, build, teste, migração e estabilização.
| Fase | Entregáveis | Gate |
|---|---|---|
| Descoberta | inventário, workload, RPO/RTO | requisitos aprovados |
| HLD | topologia, capacidade, HA, segurança | arquitetura aprovada |
| LLD | portas, VLANs, zoning, LUNs, nomes | revisão técnica |
| Build | firmware, pool, serviços, alertas | baseline limpo |
| Teste | FAT/SAT, desempenho, falhas, restore | aceite assinado |
| Migração | ondas, rollback, comunicação | go/no-go |
| Operação | runbook, treinamento, as-built | handover |
Os critérios de aceite: capacidade útil e reserva confirmadas; desempenho sustentado com perfil representativo e latência dentro do SLO; falhas de caminho, switch, disco e controladora testadas; restauração de dados e configuração comprovada; alertas recebidos pelo NOC/equipe responsável; e documentação as-built e matriz de responsabilidade entregues.
Arquiteturas de referência
Os exemplos abaixo são pontos de partida e devem ser ajustados ao workload e ao domínio de falha.
A. PME / backup e arquivos: TrueNAS com um controlador, boot espelhado, pool RAIDZ2 em HDD CMR, RAM ECC, NICs 10/25 GbE, snapshots e réplica para segundo equipamento. Adequado quando a interrupção para manutenção é aceitável.
B. Virtualização crítica: TrueNAS Enterprise HA ou storage equivalente com controladoras redundantes, SSD/all-flash ou mirrors dimensionados, rede iSCSI A/B 25 GbE, MPIO em todos os hosts, gestão separada e réplica externa. SLOG apenas se os testes mostrarem benefício para writes síncronos.
C. SAN Fibre Channel: hosts com HBAs dual-port, duas fabrics FC independentes, zoning single-initiator/single-target, storage HA, LUN masking, multipath homologado, backup LAN-free quando justificado e monitoramento da fabric.
D. Repositório de alta capacidade: vários vdevs RAIDZ2/3 em HDD NL-SAS/CMR, metadados avaliados para special vdev redundante, rede de 25/100 GbE, políticas de lifecycle e cópia externa. Priorize throughput sequencial e tempo de rebuild.
Riscos e anti-padrões
A maioria dos incidentes graves nasce de decisões simples que não foram testadas.
| Anti-padrão | Consequência | Correção |
|---|---|---|
| Um único vdev RAIDZ enorme | rebuild longo e baixa flexibilidade | vários vdevs equilibrados |
| RAIDZ1 com discos grandes críticos | janela de vulnerabilidade | RAIDZ2/3 ou mirrors |
| LACP como "MPIO" | falha fim a fim mal coberta | sub-redes/caminhos distintos |
| SLOG sem PLP | risco em perda de energia | dispositivo enterprise com PLP |
| Dedup por padrão | pressão severa de RAM/CPU | medir antes; compressão primeiro |
| Pool quase cheio | fragmentação e queda de desempenho | alerta e expansão antecipada |
| Snapshots no mesmo storage apenas | perda no desastre/ataque | réplica + backup isolado |
| Sem teste de restore | RPO/RTO fictícios | exercícios periódicos |
Go/No-Go: não entre em produção se failover, restore, alertas, rollback e documentação não tiverem sido validados.
Checklist de levantamento
Use este roteiro em workshops técnicos e comerciais. Em negócio e SLA: aplicações, proprietários e criticidade; RPO, RTO, janela de manutenção e custo de parada; retenção, compliance, soberania e auditoria. Em workload: capacidade atual, crescimento mensal/anual e compressibilidade; IOPS, throughput, latência p95/p99, bloco e read/write; protocolos, hosts, versões, clusters e multipath; picos, backup, batch, scrub, replicação e migração.
Em infraestrutura: rack, energia A/B, kVA, refrigeração e peso; portas, velocidades, ópticos, cabos, VLANs e IPs; equipe, monitoramento, suporte, peças e site remoto. No aceite: workload sintético e aplicação real; falhas injetadas e tempo de recuperação; restore, DR e evidências; treinamento e documentação as-built.
Comandos e validações
Exemplos para diagnóstico — execute mudanças somente sob procedimento aprovado. Para a saúde do pool e eventos: zpool status -v, zpool list, zpool events -v, zpool iostat -v 2. Para datasets, snapshots e propriedades: zfs list -o name,used,avail,refer,mountpoint,compression, zfs get -r recordsize,compression,sync,atime POOL, zfs list -t snapshot -o name,creation,used -s creation. Para rede e iSCSI no host Linux: ip -s link, ss -ti, iscsiadm -m session -P 3, multipath -ll, iostat -x 2.
Boas práticas: colete baseline antes e depois de qualquer ajuste. Mude uma variável por vez e registre workload, horário e resultado.
Glossário
- ARC: cache adaptativo do ZFS em memória.
- L2ARC: cache secundário de leitura em dispositivo rápido.
- ZIL: mecanismo de log para writes síncronos.
- SLOG: dispositivo separado que armazena o ZIL.
- Vdev: unidade de redundância e desempenho de um pool.
- Zvol: volume de bloco criado sobre ZFS.
- LUN: unidade lógica apresentada por SCSI.
- WWPN: identificador de porta Fibre Channel.
- IQN: nome qualificado de initiator/target iSCSI.
- MPIO: multipath I/O com caminhos redundantes.
- RPO: perda máxima de dados tolerada.
- RTO: tempo máximo para restaurar o serviço.
- PLP: proteção contra perda de energia em SSD/NVMe.
- DWPD: gravações completas por dia durante a garantia.
Conclusão
Storage corporativo bem projetado trata disponibilidade, desempenho, proteção de dados, segurança e custo como um único sistema de decisões, não como escolhas isoladas. Fibre Channel, iSCSI e NVMe-oF cada um traz seu ecossistema de latência e complexidade; o TrueNAS sobre OpenZFS oferece um caminho flexível do laboratório à produção crítica, desde que hardware, rede e operação sejam validados com o mesmo rigor de uma SAN proprietária.
O critério final não é o preço por terabyte, mas a pergunta que deve anteceder qualquer arquitetura: qual falha o negócio precisa sobreviver, e em quanto tempo — e essa resposta só é confiável depois de testada, não apenas projetada no papel.
Este conteúdo é um resumo técnico consolidado a partir da documentação oficial do TrueNAS, OpenZFS, SNIA e NVM Express, com data de corte em setembro de 2026. A documentação de produto é dinâmica — utilize a versão estável aplicável ao seu ambiente antes de qualquer contratação ou projeto de implantação.