Придатне для використання сховище після RAID

01

Нормалізуйте байти, TB та TiB

Мітки дисків і каталог 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 залишається в межах одного шасі; вона не захищає від видалення, компрометації або втрати сервера.

Очікуваний результат — це відтворюваний робочий аркуш ємності, який інший оператор може перерахувати з байтів пристрою та топології. Використовуйте калькулятор для короткого списку, потім замініть його оцінку спостережуваними властивостями з розгорнутого пулу перед пропонуванням ємності додатку.