01
Normalize bytes, TB e TiB
As etiquetas das unidades e o catálogo Tungsto utilizam unidades decimais: um TB equivale a 1,000,000,000,000 bytes. Um TiB equivale a 1,099,511,627,776 bytes. A mesma contagem de bytes aparece, portanto, como um número menor em TiB. Converta a partir dos bytes de origem em vez de aplicar repetidamente uma percentagem arredondada e rotule cada coluna da folha de cálculo com a sua unidade.
Por exemplo, o array de catálogo 12 × 16 TB contém 192 TB brutos antes da redundância, enquanto 24 × 20 TB contém 480 TB brutos. Esses valores excluem o par de arranque separado NVMe. São factos de inventário, não alegações sobre capacidade visível ou gravável pelo sistema de ficheiros.
Normalize bytes, TB e TiB| Fase | Entrada de cálculo | Saída a reter |
|---|
| Inventário | Contagem × bytes da unidade participante mais pequena | Bytes brutos e TB decimal |
|---|
| Redundância | Topologia de espelho ou paridade | Capacidade aproximada da matriz ou pool |
|---|
| Operações | Peças sobressalentes quentes e política de substituição | Capacidade realmente atribuída a vdevs de dados ou array |
|---|
| Sistema de ficheiros | Metadados, reservas e propriedades atuais | Capacidade gravável reportada |
|---|
| Aplicação | Instantâneos, retenção e margem de segurança | Capacidade disponível para dados planeados |
|---|
02
Modele a topologia real, não uma linha agregada
Utilize o tamanho do dispositivo participante mais pequeno quando os membros diferirem, a menos que a implementação selecionada documente o contrário; porções maiores podem permanecer inutilizáveis. Separe dispositivos de arranque, cache, registo, sobressalentes e dados. Para ZFS, identifique cada vdev de nível superior e a sua redundância. Os dados são distribuídos por vdevs de nível superior, pelo que um vdev não redundante pode tornar um pool de outra forma espelhado vulnerável a esse único dispositivo.
A fórmula de paridade simples aproxima um grupo RAIDZ como dispositivos de dados vezes o tamanho do dispositivo, mas a alocação real depende do tamanho do registo, geometria do setor e comportamento de paridade. O OpenZFS descreve, portanto, a sua propriedade de pool utilizável como uma heurística, não uma promessa exata.
03
Aplique uma cascata de capacidade
Comece com os bytes brutos, subtraia a redundância e quaisquer hot spares dedicados e leia depois a propriedade disponível do próprio sistema de ficheiros ou pool criado. Desse resultado, reserve o espaço exigido pela política, instantâneos, comportamento copy-on-write, replicação temporária ou trabalho de restauro e crescimento da aplicação. Não assuma poupanças de compressão ou deduplicação; ambas dependem dos dados e da configuração e podem desaparecer de uma previsão conservadora.
Mantenha dois resultados: capacidade teórica para comparar layouts e capacidade operacional para admitir dados. O segundo deve incluir um limiar de alerta e um limiar de paragem de admissão escolhidos pelo operador. Um sistema de ficheiros a encher até ao último byte reportado pode prejudicar a manutenção e a recuperação, mesmo que a aritmética originalmente parecesse correta.
04
Valide o pool criado antes de confiar dados
Após criar o layout selecionado, registe a associação de dispositivos, redundância, saúde e a capacidade disponível reportada pela implementação. Em ZFS, distinga estimativas ao nível do pool da disponibilidade do dataset, porque quotas, reservas e paridade podem fazê-las diferir. A calculadora de capacidade TrueNAS é útil para planear a geometria ZFS, mas as suas entradas ainda precisam de corresponder aos discos reais, ashift, tamanho do registo, sobresselentes e política de reserva.
Crie um registo de aceitação antes da produção: bytes brutos, diagrama de layout, valor calculado, valor reportado, reserva, política de snapshots e destino de backup. Investigue qualquer lacuna inexplicada em vez de alterar unidades até que os números pareçam corresponder.
05
Mantenha a capacidade e a recuperação separadas
Um valor utilizável maior não prova um design mais seguro. Indique as falhas de dispositivos toleradas, monitorização, procedimento de reserva, política de scrub ou verificação de consistência e fonte de restauro juntamente com o resultado da capacidade. A redundância RAID e ZFS permanece dentro de um chassis; não protege contra eliminação, comprometimento ou perda do servidor.
O resultado esperado é uma folha de cálculo de capacidade reproduzível que outro operador possa recalcular a partir dos bytes do dispositivo e da topologia. Use a calculadora para uma lista curta e depois substitua a sua estimativa pelas propriedades observadas do pool implementado antes de oferecer capacidade de aplicação.
Respostas diretas
Perguntas sobre este guia
Porque é que um servidor bruto 192 TB mostra menos TiB?
TB e TiB dividem os mesmos bytes por tamanhos de unidade diferentes, e RAID mais camadas de sistema de ficheiros reduzem ainda mais o resultado. Preserve os bytes como valor de origem e rotule cada conversão.
Deve a compressão esperada ser adicionada à capacidade utilizável?
Não como capacidade garantida. A compressão depende dos dados e das definições. Trate qualquer redução medida como um cenário separado, mantendo um plano de admissão sem compressão.