01
Normalisez les octets, TB et TiB
Les étiquettes de disque et le catalogue Tungsto utilisent des unités décimales : un TB vaut 1,000,000,000,000 octets. Un TiB vaut 1,099,511,627,776 octets. Le même nombre d'octets apparaît donc comme un nombre plus petit en TiB. Convertissez à partir des octets sources plutôt que d'appliquer un pourcentage arrondi de manière répétée, et étiquetez chaque colonne de feuille de calcul avec son unité.
Par exemple, le tableau du catalogue 12 × 16 TB contient 192 TB bruts avant redondance, tandis que 24 × 20 TB contient 480 TB bruts. Ces chiffres excluent la paire de démarrage séparée NVMe. Ce sont des faits d'inventaire, pas des affirmations sur la capacité visible par le système de fichiers ou inscriptible.
Normalisez les octets, TB et TiB| Étape | Entrée de calcul | Sortie à conserver |
|---|
| Inventaire | Nombre × octets du plus petit disque participant | Octets bruts et TB décimal |
|---|
| Redondance | Topologie miroir ou parité | Capacité approximative du tableau ou du pool |
|---|
| Opérations | Pièces de rechange à chaud et politique de remplacement | Capacité réellement affectée aux vdevs de données ou à la matrice |
|---|
| Système de fichiers | Métadonnées, réservations et propriétés actuelles | Capacité inscriptible signalée |
|---|
| Application | Instantanés, rétention et marge de sécurité | Capacité disponible pour les données planifiées |
|---|
02
Modélisez la topologie réelle, pas une seule ligne agrégée
Utilisez la plus petite taille de périphérique participant lorsque les membres diffèrent, sauf si la documentation de l'implémentation sélectionnée indique le contraire ; des portions plus grandes peuvent rester inutilisables. Séparez les périphériques de démarrage, de cache, de journal, de réserve et de données. Pour ZFS, identifiez chaque vdev de niveau supérieur et sa redondance. Les données sont réparties sur les vdev de niveau supérieur, donc un vdev non redondant peut rendre un pool autrement en miroir vulnérable à ce périphérique unique.
La formule de parité simple approxime un groupe RAIDZ comme le nombre de périphériques de données multiplié par la taille du périphérique, mais l'allocation réelle dépend de la taille des enregistrements, de la géométrie des secteurs et du comportement de la parité. OpenZFS décrit donc sa propriété de pool utilisable comme une heuristique, pas comme une promesse exacte.
03
Appliquez une cascade de capacité
Commencez par les octets bruts, soustrayez la redondance et les éventuels disques de rechange à chaud dédiés, puis lisez la propriété disponible du système de fichiers ou du pool créé. De ce résultat, réservez l'espace requis par la politique, les instantanés, le comportement de copie sur écriture, la réplication temporaire ou les travaux de restauration et la croissance de l'application. Ne supposez pas d'économies de compression ou de déduplication ; les deux dépendent des données et de la configuration et peuvent disparaître d'une prévision prudente.
Conservez deux sorties : la capacité théorique pour comparer les configurations et la capacité opérationnelle pour admettre les données. La seconde doit inclure un seuil d'alerte et un seuil d'arrêt d'admission choisis par l'opérateur. Un système de fichiers se remplissant jusqu'à son dernier octet signalé peut nuire à la maintenance et à la récupération même si l'arithmétique semblait initialement correcte.
04
Validez le pool créé avant d'y engager des données
Après avoir créé la disposition sélectionnée, enregistrez l'appartenance des périphériques, la redondance, la santé et la capacité disponible rapportée par l'implémentation. Sur ZFS, distinguez les estimations au niveau du pool de la disponibilité des jeux de données, car les quotas, réservations et parité peuvent les faire différer. Le calculateur de capacité TrueNAS est utile pour planifier la géométrie ZFS, mais ses entrées doivent correspondre aux disques réels, à l'ashift, à la taille d'enregistrement, aux disques de rechange et à la politique de réservation.
Créez un enregistrement d'acceptation avant la production : octets bruts, schéma de disposition, valeur calculée, valeur rapportée, réserve, politique de snapshot et destination de sauvegarde. Enquêtez sur tout écart inexpliqué plutôt que de changer d'unités jusqu'à ce que les chiffres semblent correspondre.
05
Gardez la capacité et la récupération séparées
Un chiffre utilisable plus élevé ne prouve pas une conception plus sûre. Indiquez les pannes de périphériques tolérées, la surveillance, la procédure de rechange, la politique de scrub ou de vérification de cohérence et la source de restauration à côté du résultat de capacité. La redondance RAID et ZFS reste à l'intérieur d'un châssis ; elle ne protège pas contre la suppression, la compromission ou la perte du serveur.
Le résultat attendu est une feuille de calcul de capacité reproductible qu'un autre opérateur peut recalculer à partir des octets des périphériques et de la topologie. Utilisez le calculateur pour une liste restreinte, puis remplacez son estimation par les propriétés observées du pool déployé avant d'offrir une capacité applicative.
Réponses directes
Questions sur ce guide
Pourquoi un serveur brut 192 TB affiche-t-il moins de TiB ?
TB et TiB divisent les mêmes octets par des tailles d'unité différentes, et RAID plus les couches du système de fichiers réduisent encore le résultat. Conservez les octets comme valeur source et étiquetez chaque conversion.
La compression attendue doit-elle être ajoutée à la capacité utilisable ?
Pas en tant que capacité garantie. La compression dépend des données et des paramètres. Traitez toute réduction mesurée comme un scénario distinct tout en conservant un plan d'admission non compressé.