Проблеми та рішення Usable Space
Системи зберігання даних як предмет розмови
Проблеми та рішення Usable Space. Частина 3
??так, у попередніх двох постах цієї теми (частина 1, частина 2) я постарався показати, що таке usable space порівняно з raw space, чому перше завжди менше ніж друге, і чому ми, заплативши за повноважні терабайти, отримуємо на виході нібито зовсім не ті терабайти, за які ми заплатили.
Процес переходу від raw до usable є процес отримання з тупих байтів якогось функціоналу, "обмін байтів на додаткові можливості та захист даних". Зазвичай чим більше ми втрачаємо в байтах, тим більше отримуємо у функціоналі (звичайно якщо це правильна система зберігання ;)
Один із блогерів NetApp, якого я постійно читаю, Костадіс українсос, використовує у своїх постах, особливо у своїх суперечках з EMC, терміни “Real Fibre Channel” (який так люблять Наші Шановні Конкуренти) та “Better Than Real FibreChannel” :)
Давайте подивимося, де NetApp є “Better Than Real FibreChannel”.
Пост планується довгий, я розбив його на кілька частин, які будуть йти в кілька прийомів, так що готуйте каву;)
Як зменшується простір по шляху від “raw data” до “usable data + функціонал”?
Перший аспект відноситься швидше не до нашої нагоди, але перерахуємо і його. Це звані “маркетингові байти”. Більшість із читачів знає, що сто років тому існує проблема переведення з “двійкових” у “десяткові” байти. Тобто "кілобайт" це не 1000 байт, а 1024 байти.
Бородатий анекдот: "Шофер думає, що в кілобайті 1000 байт, а програміст - що в кілометрі - 1024 метри"
Так от, ємність у "двійкових байтах" виходить більше, що дуже подобається маркетерам компаній з виробництважорстких дисків: "А в папугах я набагато довше!" (с) Удав
Строго кажучи вже в обід як сто років прийнято рішення ISO (International Standartization Organisation) для "двійкових байт" використовувати спеціальні приставки, щоб відрізняти двійкові та десяткові множники, звучать вони незвично, і трохи смішно: не кіло-а кібі-(бі - " бінарні”, двійкові одиниці), “мега” – “мебі”, тощо. Але поки що є, і з диска на один “терабайт” (як називає його виробник), який насправді “тебібайт”, “зникає” за рахунок цього майже сто мегабайт.
Аспект номер два - сектор 520 байт на 8 байт більше, ніж зазвичай використовується. Навіщо це так зроблено, я писав тут і тут. Це зменшує ємність диска приблизно на 1/64 частку, підвищуючи надійність зберігання та дозволяючи використовувати дедуплікацію.
Далі переходимо до RAID-ам. Як ви вже знаєте, на системах NetApp використовується RAID тип 4 (чергування з парністю, з виділеним диском парності), який має ємність X*N-X, де X - це ємність одного диска, а N це число дисків у RAID-групі, тобто на забезпечення стійкості до відмови займається один диск. Другий тип RAID, що використовується, це варіант RAID-6 під назвою RAID-DP, в ньому на забезпечення відмовостійкості займається два диски (X * N-2X). Такий тип RAID рекомендується використовувати за промовчанням.
Максимальний розмір RAID для дисків FC та SAS – 28 дисків. Для SATA - 16. Менший розмір RAID у разі SATA диктується меншою надійністю дисків, вищою ймовірністю виходу з ладу та помилок, що вимагало обмежити розмір RAID. Крім того, швидкість rebuild на довгому RAID для відносно повільних дисків SATA може бути неприйнятно низькою. При необхідності використовувати більше дисків необхідно створювати дві і більше групи, на кожну з якихбуде витрачено по 2 диски парності (у разі RAID-DP). Зверніть увагу, що максимальний розмір RAID для групи типу RAID-4 вдвічі менший, тобто 16 для SAS та FC, і 8 для SATA! Велика дозволена довжина RAID-DP також пов'язана з його більш високою надійністю і відмовостійкістю.
Наступний етап – диски hot spare. Система NetApp призначає всі диски, що не використовуються в RAID-групах, в Hot Spare. Потім з пула hotpare-дисків ви можете їх забрати, створюючи RAID-и, aggregates томи. Більше того, експлуатація системи без дисків Hot Spare взагалі - настійно не рекомендується. Це, в принципі, напевно можливо (наприклад, якась тестова інсталяція з абсолютно нецінними даними, але обмежена за дисковими ресурсами), але це має бути усвідомлене рішення, ризик якого повністю покладається на адміністратора системи. Для відключення дуже набридливого повідомлення про роботу без hot spare необхідно встановити одну із системних опцій в налаштуваннях (паліть мани, якщо що - я ні до чого.). Але це, повторюся, не рекомендується, і є позаштатним та ризикованим режимом. У нормальному стані необхідний один hot spare на кожен контролер кластера, причому для кожного типу дисків, що використовується. Наприклад, якщо у вас “двоголова”, двоконтролерна кластерна система, в якій використовується два типи дисків, наприклад 300GB та 450GB FC, або 300GB SAS та 750GB SATA, то вам потрібно буде мати spare кожного з типів, тобто окремо 300 та окремо 450, або окремо 300 SAS, та 750 SATA.
З деяких пір Data ONTAP пропонує мати два hot spare на контролер мінімум. Це пов'язано з деякими внутрішніми "маневрами" системи, і в принципі, як і у випадку з роботою без hot spare взагалі, це може бути відключено в системних опціях ONTAP. Особисто ось мені, як приватній особі, здається, що тримати _чотири_ hot spare на систему (по 2 на контролер) це вже відвертий перебір, навіть для досить великої системи, що вже говорити про найбільш популярні у нас “голова плюс одна чи дві полиці”.
* Змінити установку за замовчуванням в 2 spare можна встановивши опцію raid.min_spare_count в 1, проте додавати диски в aggreate доведеться в командному рядку, так як для FilerView установку в 2 spare для ONTAP вище 7.3 змінити не вдається (вона просто не дасть вам у GUI використовувати дисків більше, ніж “всі диски голови мінус два”). > aggr add [aggrname] -d [diskname]