01
Normaliza bytes, TB y TiB
Las etiquetas de las unidades y el catálogo Tungsto utilizan unidades decimales: un TB equivale a 1,000,000,000,000 bytes. Un TiB equivale a 1,099,511,627,776 bytes. Por lo tanto, el mismo número de bytes aparece como una cifra menor en TiB. Convierta a partir de los bytes de origen en lugar de aplicar repetidamente un porcentaje redondeado, y etiquete cada columna de la hoja de cálculo con su unidad.
Por ejemplo, la matriz de catálogo 12 × 16 TB contiene 192 TB brutos antes de redundancia, mientras que 24 × 20 TB contiene 480 TB brutos. Esas cifras excluyen el par de arranque NVMe separado. Son hechos de inventario, no afirmaciones sobre capacidad visible o escribible del sistema de archivos.
Normaliza bytes, TB y TiB| Etapa | Entrada de cálculo | Salida a conservar |
|---|
| Inventario | Recuento × bytes de la unidad participante más pequeña | Bytes sin procesar y TB decimal |
|---|
| Redundancia | Topología de espejo o paridad | Capacidad aproximada del arreglo o pool |
|---|
| Operaciones | Repuestos en caliente y política de reemplazo | Capacidad realmente asignada a vdevs de datos o matriz |
|---|
| Sistema de archivos | Metadatos, reservas y propiedades actuales | Capacidad grabable informada |
|---|
| Aplicación | Instantáneas, retención y margen de seguridad | Capacidad disponible para los datos planificados |
|---|
02
Modele la topología real, no una fila agregada
Utilice el tamaño del dispositivo participante más pequeño cuando los miembros difieran, a menos que la implementación seleccionada documente lo contrario; las porciones más grandes pueden quedar inutilizables. Separe los dispositivos de arranque, caché, registro, repuesto y datos. Para ZFS, identifique cada vdev de nivel superior y su redundancia. Los datos se distribuyen en franjas entre los vdev de nivel superior, por lo que un vdev no redundante puede hacer que un grupo por lo demás reflejado sea vulnerable a ese único dispositivo.
La fórmula de paridad simple aproxima un grupo RAIDZ como dispositivos de datos multiplicados por el tamaño del dispositivo, pero la asignación real depende del tamaño del registro, la geometría del sector y el comportamiento de la paridad. Por lo tanto, OpenZFS describe su propiedad de grupo utilizable como una heurística, no como una promesa exacta.
03
Aplique una cascada de capacidad
Comience con los bytes brutos, reste la redundancia y cualquier repuesto activo dedicado, y luego lea la propiedad disponible del sistema de archivos o pool creado. De ese resultado, reserve el espacio requerido por la política, las instantáneas, el comportamiento de copia en escritura, la replicación temporal o el trabajo de restauración y el crecimiento de la aplicación. No asuma ahorros por compresión o deduplicación; ambos dependen de los datos y la configuración y pueden desaparecer de una previsión conservadora.
Mantenga dos resultados: capacidad teórica para comparar diseños y capacidad operativa para admitir datos. El segundo debe incluir un umbral de alerta y un umbral de detención de admisión elegidos por el operador. Un sistema de archivos que se llena hasta su último byte informado puede perjudicar el mantenimiento y la recuperación incluso si la aritmética originalmente parecía correcta.
04
Valide el pool creado antes de confirmar los datos
Después de crear el diseño seleccionado, registre la pertenencia de dispositivos, la redundancia, el estado y la capacidad disponible informada por la implementación. En ZFS, distinga las estimaciones a nivel de pool de la disponibilidad del dataset porque las cuotas, reservas y paridad pueden hacer que difieran. La calculadora de capacidad TrueNAS es útil para planificar la geometría ZFS, pero sus entradas aún deben coincidir con los discos reales, ashift, tamaño de registro, repuestos y política de reservas.
Cree un registro de aceptación antes de la producción: bytes sin procesar, diagrama de diseño, valor calculado, valor informado, reserva, política de instantáneas y destino de respaldo. Investigue cualquier brecha inexplicable en lugar de cambiar unidades hasta que los números parezcan coincidir.
05
Mantenga la capacidad y la recuperación por separado
Una cifra utilizable mayor no demuestra un diseño más seguro. Indique las fallas de dispositivos toleradas, la supervisión, el procedimiento de repuesto, la política de scrub o verificación de consistencia y la fuente de restauración junto con el resultado de capacidad. La redundancia RAID y ZFS permanece dentro de un chasis; no protege contra eliminación, compromiso o pérdida del servidor.
El resultado esperado es una hoja de cálculo de capacidad reproducible que otro operador pueda recalcular a partir de los bytes del dispositivo y la topología. Use la calculadora para una lista corta y luego reemplace su estimación con propiedades observadas del grupo implementado antes de ofrecer capacidad de aplicación.
Respuestas directas
Preguntas sobre esta guía
¿Por qué un servidor sin procesar 192 TB muestra menos TiB?
TB y TiB dividen los mismos bytes por tamaños de unidad diferentes, y RAID más las capas del sistema de archivos reducen aún más el resultado. Conserve los bytes como valor de origen y etiquete cada conversión.
¿Debe añadirse la compresión esperada a la capacidad utilizable?
No como capacidad garantizada. La compresión depende de los datos y la configuración. Trate cualquier reducción medida como un escenario separado manteniendo un plan de admisión sin comprimir.