Вибір дискового масиву

Однією з головних складових системи зберігання даних є дисковий масив. У процесі проектування СГД неминуче виникає питання, який масив вибрати?

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

Наведемо часто зустрічається на практиці, але не претендує на повноту перелік вимог, розбитий по категоріях .

Рисунок 10

Можливість створення PIT — копії даних засобами масиву

Дана функціональність масиву може знадобитися, якщо, наприклад, прийнято проектне рішення про завантаження даних з OLTPзавдання в DSS — задачу засобами масиву. Функція створення PITкопій може бути реалізована різними методами — через «моментальний знімок» (SnapShot) (Мал. 4) або через повне копіювання даних (clone). Різниця між цими методами полягає в тому, що SnapShot економить дисковий простір, оскільки для його створення потрібно всього лише місце для бітової карти і деякого пулу для збереження старих значень змінених блоків. Навпаки, clone вимагає того ж (корисного) обсягу, що і копійований LUN. Однак, якщо вихідний LUN схильний до частих змін, то необхідний для підтримки SnapShot обсяг дискового простору може істотно зрости. Якщо з копією LUN, створеної за допомогою SnapShot вестиметься інтенсивна робота (велике число запитів на введення-виведення), це може знизити продуктивність обміну даними з вихідним LUN. Копія LUN за допомогою SnapShot створюється моментально (звідси і назва — «моментальний знімок»), оскільки процес «копіювання «полягає лише у створенні бітової карти. Для створення clone потрібен певний час, оскільки відбувається повне копіювання блоків даних. У цей момент навантаження по вводу — висновку на копійований LUN істотно зростає. Існують проміжні способи створення PITкопій, коли спочатку створюється SnapShot, а потім він поступово перетворюється на clone. Проектувальник повинен врахувати всі ці.

особливості методів створення PITкопій і у вимогах чітко вказати який метод планується використовувати.

Вимоги до продуктивності. Вимоги по відмово стійкості та надійності. Вимоги по масштабованості

* Дисковий масив повинен забезпечувати продуктивність N IOPS, а агрегована пропускна здатність масиву повинна становити M МБ / с. Як вже зазначалося, отримати такі цифри не просто. Якщо існує прототип системи або вибір дискового масиву здійснюється для модернізації існуючої СГД, то можна провести «натурні «заміри продуктивності та апроксимувати їх для очікуваного зростання навантаження на СГД. Якщо система створюється з «нуля», то можна спробувати отримати ці цифри в якості вимог виробника прикладного ПЗ (що практично не реально) або обраться до виробників масивів, щоб ті провели визначення необхідних параметрів масиву (sizing). Зазвичай виробники мають методики «грубої «оцінки необхідної продуктивності. Але вхідними даними для цих методик, як правило, служать очікуване число транзакцій і їх «вага «(light, medium, heavy), які теж не завжди можна визначити .

Специфічні функції управління кешпам’яттю масиву. Наприклад, до таких функцій відносяться:

можливість закріплення ділянки кешпам’яті за конкретним LUN (може придатися для розміщення в кеш часто використовуваних службових таблиць бази даних);

відключення використання кеш на запис та / або читання для конкретного LUN (може знадобитися для DSS — задач);

забезпечення рівня сервісу у вигляді заданого рівня продуктивності (IOPS) або пропускної здатності (МБ / с) для зазначеного сервера.

Рисунок 11

Можливість створення PITкопій даних для використання їх у системі резервного копіювання. У ряді систем, де обробляються великі обсяги даних (терабайти), а сервіси повинні бути доступні 24×7 при великих навантаженнях, необхідно застосовувати Serverless резервне копіювання. Для цього використовується механізм створення PITкопій засобами дискового масиву.

Вимоги по обслуговуваності.

* Можливість заміни компонентів масиву «на ходу» без зупинки системи. Виконання цієї вимоги важливо для систем, що працюють в режимі 24×7 .

Рисунок 12

Рисунок 13

Класи масивів придумувати не треба, вони вже визначені самим ринком, це: початковий клас (low — end), середній клас (mid — range) і вищий клас (high — end) .Масиви зазначених класів відрізняються, в першу чергу, не кількісними характеристиками, а функціональністю і архітектурою. До функціональності.

low — end масивів можна віднести підтримку різних рівнів RAID і можливість дублювання контролерів (якщо це не JBOD). Від масивів класу mid — range вже потрібна підтримка LUN — masking і створення PITкопій. А в масивах класу high — end на додаток до зазначених можливостям також реалізовані апаратна реплікація, підтримка OS/390 (zOS) та управління якістю сервісу (на рівні продуктивності в IOPS або пропускної здатності в Мбайт / с).

Але все ж основним критерієм, за яким можна віднести масив до одного з класів mid — range або high — end, є архітектура. Багато виробників заявляють, що mid — range масиви мають модульну архітектуру, а high — end масиви — монолітну. Це не зовсім вірно. Модульна або монолітна «архітектура» говорить про конструктив масиву — збирається з окремих блоків або шаф. Насправді архітектуру всіх mid — range масивів (і багатьох low — end) можна характеризувати як «двухконтроллерную із загальною шиною » .

Для high — end масивів характерна коммутируемая або матрична архітектура (1) (рис.13). Очевидно, що в даній архітектурі немає «вузьких місць», тоді як в mid — range архітектурі вузькими місцями є: контролер, оскільки кожен контролер обслуговує свої RAIDгрупи (набір дисків, на яких реалізовано один рівень RAID), шина між контролерами, обмежене число FCAL петель до дисків, розташування дисків RAIDгрупи «вздовж «однієї петлі FCAL. У high — end масивах RAIDгрупи розташовуються «впоперек» FCAL петель.

Наприклад, в high — end масивах Hitachi RAID — група складається з 4 -х або восьми дисків, де кожен диск підключається до двох різних петель від двох різних дисків контролерів. Така конфігурація дозволяє виконувати операції запису-читання з усіх дисків RAIDгрупи паралельно, чого не можна домогтися в mid — range масивах, коли диски однієї RAIDгрупи розташовані вздовж однієї петлі і доступ до них здійснюється по черзі.

(1) Іноді ще для high — end масивів говорять про «cache — centric «архітектуру, підкреслюючи тим самим, що центральною ланкою є кешпам’ять, до якої мають доступ усі контролери масиву, тоді як в mid — range масивах кешпам’ять жорстко прив’язана до певного контролеру .

Зазначені відмінності в архітектурі призводять до втрати продуктивності при масштабування mid — range масивів, чого не спостерігається у high — end масивів при додаванні нових дисків. Хоча сучасні mid — range масиви мають високі характеристики масштабованості: дозволяють встановлювати до двохтрьох сотень дисків, розподіляючи їх по декількох FCAL петель, а також нарощувати кешпам’ять до 8 ГБ, все ж «вузьким місцем» залишається їх архітектура, яка є обмежувачем масштабованості .

Якщо дотримуватися зазначеної класифікації, то тільки масиви HDS сімейства 9900 і масиви EMC сімейства Symmetrix можна віднести до класу high — end .

Рисунок 13. Коммутаційна архітектура high-end масиву на прикладі HDS Lightning 9900V.

Масиви HP EVA і IBM ESS 800 (Shark), які позиціонуються виробниками як high — end масиви, мають архітектуру, типову для mid — range масивів .

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

Цей пул вже, в свою чергу, «нарізається «на логічні (віртуальні) диски (LogicalUnitNumber — LUN), які «видно» серверам як фізичні. Насправді подібну організацію дискової пам’яті давно вже дозволяє створювати менеджер томів VERITAS VolumeManager. Даний тип віртуалізації отримав назву «host — based «віртуалізація .Практично всі сучасні дискові масиви виконують функцію створення з наборів фізичних дисків логічних дисків (LUN), що отримала назву «diskarray — based «віртуалізація. Це легко визначити на підставі того факту, що ряд масивів підтримують число LUNs більше, ніж фізичних дисків, як, наприклад, в недавно анонсованому масиві SunStorEdge 3510. Питання полягає в тому, наскільки це зручно. Адміністратори воліють мати можливість керувати фізичним розміщенням файлів даних СУБД ORACLE по фізичних дискам для досягнення оптимальної продуктивності та відмовостійкості. Налаштування СУБД під оптимальну продуктивність може стати проблематичною, якщо контролер дискового масиву не дозволяє управляти розміщенням RAIDгруп на конкретних дисках.

Крім зазначених двох типів віртуалізації - «host — based «і «diskarray — based », існує ще один тип — «SAN — based ». У цьому типі віртуалізації приховування від серверів фізичного розташування даних здійснюється або за допомогою спеціальних пристроїв, розташованих між FCкомутаторами SAN («in — band «віртуалізація), або засобами самих FCкомутаторів, що зчитують інформацію про конфігурацію віртуального дискового простору з зовнішнього пристрою («out — off — band «віртуалізація) .В даний час продуктів «SAN — based «віртуалізації на ринку мало і говорити про їх промисловому впровадженні поки не доводиться. Можливо, потреба в цьому типі віртуалізації з’явиться тоді, коли обсяги даних підприємств зростуть настільки, що для їх оперативного зберігання не вистачатиме кількох high — end дискових масивів .