Яка версія прошивки "правильна" і "робоча"? Якщо СГД гарантує стійкість до відмови на 99,9999%, то чи означає, що і працювати вона буде безперебійно навіть без оновлення ПЗ? Або навпаки для отримання максимальної відмовостійкості потрібно завжди ставити останню прошивку? Намагатимемося відповісти на ці питання, спираючись на наш досвід.
невелике введення
Всі ми розуміємо, що в кожній версії програмного забезпечення, будь то операційна система або драйвер для якогось пристрою, найчастіше містяться недоробки/баги та інші "особливості", які можуть як не "проявитися" до кінця служби обладнання, так і " розкритися” лише за певних умов. Кількість та значимість таких нюансів залежить від складності (функціональності) ПЗ та від якості тестування при його розробці.
Найчастіше користувачі залишаються на “прошивці із заводу” (знамените – «працює, значить не лізь») або завжди ставлять останню версію (у їхньому розумінні остання означає сама робоча). Ми ж використовуємо інший підхід - дивимося реліз ноти для всього використовуваного обладнання та уважно вибираємо відповідну прошивку для кожної одиниці обладнання.
Такого висновку ми дійшли, що називається, з досвідом. На своєму прикладі експлуатації розповімо, чому обіцяні 99,9999% надійності СГД нічого не означають, якщо ви не будете своєчасно стежити за оновленням та описом ПЗ. Наш кейс підійде для користувачів СГД будь-якого вендора, оскільки подібна ситуація може статися із залізом будь-якого виробника.
Вибір нової системи зберігання даних
Наприкінці минулого року до нашої інфраструктури додалася цікава система зберігання даних: молодша модель з лінійки IBM FlashSystem 5000, яка на момент придбання іменувалася Storwize V5010e. Зараз вона продається під назвою FlashSystem 5010, але фактично це та ж апаратна база з тим самим Spectrum Virtualize всередині.
Наявність єдиної системи управління - це, до речі, і є основною відмінністю IBM FlashSystem. У моделей молодшої серії вона практично не відрізняється від моделей продуктивніших. Вибір певної моделі лише дає відповідну апаратну базу, характеристики якої дозволяють використовувати той чи інший функціонал або забезпечити більш високий рівень масштабованості. ПЗ при цьому ідентифікує апаратну частину та надає необхідний та достатній функціонал для цієї платформи.
IBM FlashSystem 5010
Коротко про нашу модель 5010. Це двоконтрольна блокова система зберігання даних початкового рівня. Вона вміє розміщувати у собі диски NLSAS, SAS, SSD. Розміщення NVMe в ній недоступне, тому що ця модель СХД позиціонується для вирішення завдань, яким не потрібна продуктивність дисків NVMe.
СГД купувалась для розміщення архівної інформації або даних, до яких не відбувається частого звернення. Тому було достатньо стандартного набору її функціоналу: тиринг (Easy Tier), Thin Provision. Продуктивність на дисках NLSAS на рівні 1000-2000 IOPS нас теж цілком влаштовувала.
Наш досвід – як ми не оновили прошивку вчасно
Тепер саме про саме оновлення ПЗ. На момент придбання система мала вже трохи застарілу версію ПЗ Spectrum Virtualize, а саме, 8.2.1.3.
Ми вивчили опис прошивок та запланували оновлення до 8.2.1.9. Якби ми були трохи спритнішими, то цієї статті не було б — на свіжішій прошивці баг би не відбувся. Проте з певних причин оновлення цієї системи було відкладено.
В результаті невелика затримка поновлення призвела до вкрай неприємної картини, як в описі за посиланням: .
Так, у прошивці тієї версії якраз був актуальним так званий APAR (Authorized Program Analysis Report) HU02104. Виявляється він в такий спосіб. Під навантаженням при певних обставинах починає переповнюватися кеш, далі система йде в захисний режим, в якому відключає введення-виведення для пулу (Pool). У нашому випадку виглядало як відключення 3-х дисків для RAID-групи в режимі RAID 6. Вимкнення відбувається на 6 хвилин. Далі доступ до Томів у Пулі відновлюється.
Якщо хтось не знайомий зі структурою та ім'ям логічних сутностей у контексті IBM Spectrum Virtualize, я зараз коротко розповім.
Структура логічних елементів СГД
Диски збираються до груп, які називаються MDisk (Managed Disk). MDisk може бути класичний RAID (0,1,10,5,6) або віртуалізований - DRAID (Distributed RAID). Використання DRAID дає змогу збільшити продуктивність масиву, т.к. будуть використовуватися всі диски групи, і зменшити час ребілда, завдяки тому, що потрібно буде відновлювати тільки певні блоки, а не всі дані з диска, що вийшов з ладу.
Розподіл блоків даних по дисках під час використання Distributed RAID (DRAID) у режимі RAID-5.
А ця схема показує логіку роботи ребілда DRAID у разі виходу з ладу одного диска:
Логіка роботи ребілда DRAID при виході з ладу одного диска
Далі один або кілька MDisk утворюють так званий Pool. У межах одного пулу не рекомендується використовувати MDisk з різним рівнем RAID/DRAID на дисках одного типу. Не будемо на це сильно заглиблюватися, т.к. ми плануємо розповісти це в рамках однієї з наступних статей. Ну і, власне, Pool ділиться на Тома (Volumes), які презентуються за тим чи іншим протоколом блокового доступу у бік хостів.
Так от, у нас, внаслідок виникнення ситуації, описаної в APAR HU02104, Через логічну відмову трьох дисків, перестав бути працездатним MDisk, який, у свою чергу, спричинив відмову в роботі Pool і відповідних Томів.
Так як ці системи досить «розумні», їх можна підключити до хмарної системи моніторингу IBM Storage Insights, яка автоматично при виникненні несправності надсилає запит на обслуговування в службу підтримки IBM. Створюється заявка та фахівці IBM у віддаленому режимі проводять діагностику та зв'язуються з користувачем системи.
Завдяки цьому питання вирішилося досить оперативно і від служби підтримки було отримано оперативну рекомендацію щодо оновлення нашої системи на вже раніше обрану нами прошивку 8.2.1.9, в якій на той момент цей момент було вже виправлено. Це підтверджує .
Підсумки та наші рекомендації
Як то кажуть: «добре те, що добре закінчується». Баг у прошивці не обернувся серйозними проблемами - роботу серверів було відновлено в найкоротші терміни і без втрати даних. У деяких клієнтів довелося перезапускати віртуальні машини, але загалом ми були готові до негативніших наслідків, оскільки щодня робимо резервні копії всіх елементів інфраструктури та клієнтських машин.
Ми отримали підтвердження, що навіть надійні системи з 99,9999% обіцяної доступності потребують уваги та своєчасного обслуговування. З ситуації ми зробили собі ряд висновків і ділимося нашими рекомендаціями:
-
Потрібно обов'язково стежити за виходом оновлень, вивчати Release Notes щодо виправлення потенційно критичних моментів і своєчасно виконувати заплановані оновлення.
Це організаційний і навіть досить очевидний момент, на якому, начебто, не варто звертати увагу. Однак, на цьому "рівному місці" можна досить легко спіткнутися. Власне, саме цей момент додав описані вище неприємності. Ставтеся до складання регламенту оновлення дуже уважно і не менш уважно стежте за його дотриманням. Цей пункт належить до поняття «дисципліна».
-
Завжди краще тримати систему із актуальною версією ПЗ. Причому актуальна – не та, яка має більшу числову позначку, а саме з пізнішою датою виходу.
Наприклад, IBM для своїх систем зберігання даних тримає в актуальному стані щонайменше два релізи ПЗ. На момент написання цієї статті – це 8.2 та 8.3. Оновлення 8.2 виходять раніше. За невеликою затримкою зазвичай виходить аналогічне оновлення для 8.3.
Реліз 8.3 має низку функціональних переваг, наприклад, можливість розширення MDisk (у режимі DRAID) додаванням одного або більше нових дисків (така можливість з'явилася починаючи з версії 8.3.1). Це досить базовий функціонал, але у 8.2 такої можливості, на жаль, немає.
-
Якщо оновитися з яких-небудь причин немає можливості, то для версій ПЗ Spectrum Virtualize, попередніх версіям 8.2.1.9 і 8.3.1.0 (де описаний вище баг актуальний), для зниження ризику його появи технічна підтримка IBM рекомендує обмежити продуктивність системи на рівні як це показано на малюнку нижче (знімок зроблений у русифікованому варіанті GUI). Значення 10000 IOPS показано для прикладу та підбирається згідно з характеристиками вашої системи.
Обмеження продуктивності СГД IBM
-
Необхідно правильно розраховувати навантаження на системи зберігання та не допускати навантаження. Для цього можна скористатися або сайзером IBM (якщо є до нього доступ), або партнерами, або сторонніми ресурсами. Обов'язково у своїй розуміти профіль навантаження систему зберігання, т.к. продуктивність в МБ/с та IOPS сильно відрізняється залежно як мінімум від наступних параметрів:
-
тип операції: читання або запис,
-
розмір блоку операції,
-
відсоткове співвідношення операцій читання та запису у загальному потоці введення-виведення.
Також, на швидкість виконання операцій впливає, як зчитуються блоки даних: послідовно або у випадковому порядку. Під час виконання кількох операцій доступу до даних за програмі є поняття залежних операцій. Це також бажано враховувати. Все це допоможе побачити сукупність даних з лічильників продуктивності ОС, системи зберігання, серверів/гіпервізорів, а також розуміння особливостей роботи додатків, СУБД та інших «споживачів» дискових ресурсів.
-
-
І насамкінець, обов'язково мати резервні копії в актуальному та робочому стані. Розклад резервного копіювання потрібно налаштовувати виходячи з прийнятних для бізнесу значень RPO і періодично обов'язково перевіряти цілісність резервних копій (досить багато виробників програмного забезпечення для резервного копіювання реалізували у своїх продуктах автоматизовану перевірку) для забезпечення прийнятного значення RTO.
Дякуємо, що дочитали до кінця.
Готові відповісти на ваші запитання та зауваження у коментарях. Також, в якому ми проводимо регулярні акції (знижки на IaaS та розіграші промокодів до 100% на VPS), пишемо цікаві новини та анонсуємо нові статті у блозі Хабра.
Джерело: habr.com