Полезное хранилище после RAID

01

Нормализуйте байты, TB и ТиБ

Метки дисков и каталог Tungsto используют десятичные единицы: один TB равен 1,000,000,000,000 байт. Один ТиБ равен 1,099,511,627,776 байт. Поэтому то же количество байт отображается меньшим числом в ТиБ. Конвертируйте из исходных байт, а не применяйте округлённый процент повторно, и помечайте каждый столбец таблицы его единицей измерения.

Например, массив каталога 12 × 16 TB содержит 192 TB сырой емкости до избыточности, а 24 × 20 TB содержит 480 TB сырой. Эти цифры исключают отдельную загрузочную пару NVMe. Это факты инвентаря, а не заявления о видимой файловой системе или записываемой емкости.

02

Моделируйте реальную топологию, а не одну агрегированную строку

Используйте наименьший размер участвующего устройства, если члены различаются, если в документации выбранной реализации не указано иное; большие части могут остаться неиспользуемыми. Разделяйте загрузочные, кэш-, журнальные, резервные и данные устройства. Для ZFS определите каждый vdev верхнего уровня и его избыточность. Данные распределяются по vdev верхнего уровня, поэтому один нерезервированный vdev может сделать в остальном зеркалированный пул уязвимым для этого отдельного устройства.

Простая формула чётности приблизительно оценивает группу RAIDZ как количество устройств данных, умноженное на размер устройства, но фактическое распределение зависит от размера записи, геометрии секторов и поведения чётности. Поэтому OpenZFS описывает своё свойство полезного пула как эвристику, а не точное обещание.

• ОткрытьZFS свойства ёмкости пула ↗

03

Примените каскад ёмкости

Начните с сырых байтов, вычтите избыточность и все выделенные горячие резервные диски, затем прочитайте собственное свойство доступности созданной файловой системы или пула. Из этого результата зарезервируйте пространство, требуемое политикой, снимками, поведением копирования при записи, временной репликацией или восстановительными работами и ростом приложения. Не предполагайте экономию от сжатия или дедупликации; обе зависят от данных и конфигурации и могут исчезнуть из консервативного прогноза.

Ведите два показателя: теоретическую ёмкость для сравнения компоновок и операционную ёмкость для приёма данных. Второй должен включать порог предупреждения и порог остановки приёма, выбранные оператором. Файловая система, заполненная до последнего сообщённого байта, может ухудшить обслуживание и восстановление, даже если арифметика изначально выглядела верной.

04

Проверьте созданный пул перед записью данных

После создания выбранной схемы зафиксируйте состав устройств, избыточность, состояние и сообщаемую реализацией доступную ёмкость. На ZFS различайте оценки на уровне пула и доступность наборов данных, поскольку квоты, резервирования и чётность могут делать их разными. Калькулятор ёмкости TrueNAS полезен для планирования геометрии ZFS, но его входные данные всё равно должны соответствовать фактическим дискам, ashift, размеру записи, резервным дискам и политике резервирования.

Создайте запись о приемке перед запуском в эксплуатацию: необработанные байты, схему расположения, расчетное значение, сообщенное значение, резерв, политику моментальных снимков и место назначения резервной копии. Исследуйте любое необъяснимое расхождение, а не меняйте единицы измерения, пока числа не станут совпадать.

05

Разделяйте емкость и восстановление

Большая полезная цифра не доказывает более безопасную конструкцию. Укажите допустимые отказы устройств, мониторинг, процедуру замены, политику очистки или проверки согласованности и источник восстановления рядом с результатом емкости. Избыточность RAID и ZFS остается в пределах одного шасси; она не защищает от удаления, компрометации или потери сервера.

Ожидаемый результат — воспроизводимая таблица ёмкости, которую другой оператор может пересчитать из байтов устройств и топологии. Используйте калькулятор для составления короткого списка, затем замените его оценку наблюдаемыми свойствами развёрнутого пула, прежде чем предлагать ёмкость приложениям.