Дякуємо Вам за звернення до KM Disti
Ми зв'яжемося з Вами максимально швидко.
Ми зв'яжемося з Вами максимально швидко.
Ми зв'яжемося з Вами максимально швидко.
Пн - Пт 9:00 – 18:00
Сьогодні в IT-інфраструктурі, з повсюдним використанням віртуалізації, системи зберігання даних є ядром, що зберігає всі віртуальні машини. Відмова цього вузла здатний повністю зупинити роботу обчислювального центру. Хоча чимала частина серверного обладнання має відмовостійкість в тій чи іншій формі «за замовчуванням», саме через особливу роль системи збереження в рамках дата-центру до неї висувають підвищені вимоги в плані «живучості».
Найбільш ефективним методом забезпечення відмовостійкості в IT є використання декількох екземплярів обладнання і ПЗ (в найпростішому випадку - дублювання). Звичайно ж систему зберігання даних можна цілком задубліровать. І для disaster recovery саме такий підхід і використовується. Але далеко не всім компаніям таке рішення по кишені. Мова навіть не тільки про подвоєною вартості обладнання, а й про інші витрати по організації подібного рішення і його подальшу підтримку.
Однак можливість дублювання обладнання не скасовує необхідності забезпечити відмовостійкість на рівні компонентів. Зокрема, в системах зберігання застосовується резервування по блокам живлення, модулів охолодження, накопичувачів і, звичайно ж, контролерам. Все це вже давно стало буденністю. Складно знайти систему зберігання даних без використання подібного дизайну. Qsan тут - не виняток. Але поговорити в даній статті ми хочемо про те, що не кидається відразу в очі, і при цьому націлене насамперед на підвищення відмовостійкості системи в цілому.
Дуже часто в системах зберігання з корпусами 2U-3U використовується комбіновані модулі, які об'єднують в собі блоки живлення і вентилятори. З одного боку, це зручно, тому що обслуговувати потрібно тільки один блок. З іншого, якщо вийде з ладу система охолодження, може примусово бути відключений блок живлення, щоб уникнути перегріву. І начебто виникне не сама критична ситуація, але додавати уразливості системі зберігання даних явно не варто.
Охолодження в системах збереження даних Qsan організовано у вигляді окремих модулів з «гарячої» заміною, незалежних від блоків живлення. Власне, в блоках живлення присутні свої вентилятори, призначені для обдування самих БЖ. Модуль охолодження вміщує в себе два незалежних вентилятора, які страхують один одного. Таких модулів в системі зберігання даних два: справа і зліва - для ефективного обдування всіх компонентів. Якщо відбувається відмова одного з вентиляторів, всі інші автоматично збільшують свої обороти з метою компенсувати утворився недолік повітряного потоку. Саме тому несправність вентилятора не тягне за собою небезпеку перегріву всього пристрою
Класична схема підключення полиць розширення до систем збереження має на увазі собою топологію, іменовану каскадом. У цьому випадку відповідні контролери полки і система збереження даних з'єднуються між собою єдиним SAS кабелем. Разом виходить 2 кабелю на двухконтроллерную систему. Якщо потрібно підключити другу, то вона підключається таким же способом до першої полиці. І так далі. Плюсом даної топології є простота реалізації в обладнанні. А мінусом буде деяка вразливість перед раптовим розривом SAS ланцюга через перехресне виходу з ладу несоедіненних між собою контролерів системи збереження і полки або через знеструмлення однієї з полиць розширення в середині ланцюга. Результатом буде втрата доступу до частини накопичувачів і можливий розвал RAID групи, якщо вона «розмазана» за кількома корпусам.
Від перехресного виходу з ладу контролерів у Qsan є захист у вигляді внутрішньої логічного зв'язку контролерів через бекплейн системи збереження данніх. Тобто контролер системи збереження данніх бачить не тільки контролер JBOD, безпосередньо підключений до нього, але і контролер «сусіда» через спеціальний лінк в бекплейне. В результаті, якщо станеться така ситуація і ніхто фізично не буде витягувати SAS кабелі між системи збереження і полицею, то доступ до всіх накопичувачів буде збережений.
Для захисту від розриву SAS ланцюга, наприклад, через знеструмлення полки розширення, зазвичай застосовується інша топологія підключення - зворотний каскад. В цьому випадку система збереження даних підключається відразу до першої та останньої полиці в ланцюзі, отримуючи доступ до накопичувачів як би з двох сторін.
Якщо хочеться сильнішою захисту, то можна будувати конфігурації масштабніше, використовуючи, наприклад, топологію дерева. Або ще ускладнити за рахунок комбінації згаданих топологій. Це можливо завдяки великій кількості SAS роз'ємів на пристроях (2 у кожного контролера системи збереження даних і 5 у кожного контролера JBOD) з автоматичним визначенням режимів роботи вхід / вихід. Головне, щоб сам адміністратор не заплутався. А вже система збереження даних зуміє правильно налаштувати конфігурацію.
Наявність в системі резервних дисків «гарячої» заміни (hot spare) істотно підвищує надійність зберігання інформації. Однак, просто факт виділення подібних дисків ще не означає абсолютного захисту. Справа в тому, що процес відновлення (ребілд) досить трудомісткий і часто тривалий за часом. Трудомісткість виникає через безперервне доступу до основних даних. Тобто система поряд з поточною роботою ще й повинна копіювати дані на новий диск. А тривалість ребілд безпосередньо залежить від ємності накопичувача та його швидкісних характеристик. Оскільки система нічого не знає про реальний зайнятому просторі на дисках, вона в процесі ребілд просто копіює все: блок за блоком.
В результаті відновлення сучасного диска великої місткості в 10 + ТБ при серйозному навантаженні на систему збереження термін може легко скласти тиждень і більше. Також слід мати на увазі той факт, що під час ребілд значно підвищується ймовірність відмови інших накопичувачів через підвищеного навантаження на них. А це вже може становити серйозну небезпеку в разі використання, наприклад, RAID5.
Як вирішення проблеми багато розробників систем збереження перейнялися прискоренням процесу відновлення. Для цього можуть застосовуватися різні підходи, але суть одна - копіювання при ребілд тільки реально зайнятих блоків. Не залишився осторонь від цієї проблеми і Qsan. У системах збереження даних цього вендора при активованої опції Fast Rebuild система веде трекінг використовуваних для запису блоків, тим самим маючи можливість в разі відмови диска копіювати на новий накопичувач тільки їх.
Опція Fast Rebuild не включена за замовчуванням при створенні нових томів, тому що її використання має вплив на продуктивність, особливо при операціях random write, тому що:
Тому не рекомендується використовувати Fast Rebuild для томів, наприклад, з високонавантажених базами даних або в системах відеоспостереження, де том все одно в підсумку буде заповнений на 100%. А ось для файлових або поштових серверів дана опція буде якраз дуже корисна.
Кожен виробник систем збереження данніх має на увазі, що його пристрої надійні. І якщо немає фатальних прорахунків при розробці пристроїв і неймовірною тяги до економії в процесі їх виробництва та тестування, то в цілому можна погодитися з вендором. Однак потрібно розуміти:
При цьому також не варто забувати, що ніяка абсолютна надійність систем збереження не скасовує наявності резервних копій, чітких і прорепетирувати планів по відновленню в разі аварії і оперативної технічної підтримки вендора.
Посилання на джерело: Відмовостійкість в системах збереження даних Qsan/Skilline corporate blog
