HP StoreVirtual - платформа для катастрофостійких рішень для великого та середнього бізнесу

За даними досліджень Gartner, програмно-визначувані системи зберігання (Software-Defined Storage, SDS) потрапляють в топ-тренди ІТ-ринку останні пару років. Найчастіше використовують програмні СЗД або повністю будують на них свою інфраструктуру малий і середній бізнес, а також сервіс-провайдери. При цьому на ринку існує багато розробок таких систем зберігання з різною функціональністю і можливостями масштабування, але особливу увагу заслуговує одна з перших SDS — HP StoreVirtual VSA (Virtual Storage Appliance), раніше відома як LeftHand. Система виконана у вигляді віртуальної машини VSA для гіпервізорів Hyper-V і ESXi. Вона цікава не тільки тим, що за багато років розробки її давно вже можна рекомендувати для корпоративного сегмента, а також і тим, що StoreVirtual доступна ще й у варіанті апаратного виконання. У продуктових середовищах замовників налічується вже більше 12 тис. Віртуальних СЗД HP StoreVirtual VSA.

Ще однією сильною стороною даної СГД є можливість забезпечити катастрофостійкість «з коробки» без додаткових витрат. Саме на цьому (катастрофостійкості) і зосереджено увагу цієї статті.

Модельний ряд НР StoreVirtual включає в себе як апаратно-програмні рішення 4000 серії, так і повністю програмні VSA-продукти (мал. 1).

Мал. 1. Модельний ряд StoreVirtual

Технологія HP StoreVirtual

HP StoreVirtual 4000 - це конвергентная система зберігання даних, яка за рахунок унікальної технології кластеризації може вирішувати задачі невеликого бізнесу з малими обсягами даних і масштабуватися до системи корпоративного рівня з підвищеними вимогами до продуктивності й схоронності даних. Основне застосування цих систем - це віртуалізовані середовища і територіально рознесені інфраструктури, де необхідно забезпечити реплікацію даних між декількома майданчиками одночасно на малих і великих територіях по Ethernet-каналах зв'язку і інтерфейсу iSCSI.

Якщо розглядати системи, подібні StoreVirtual, то ми побачимо, що кожен вузол - це власна СЗД та взаємодія із собі подібними системами відбувається за допомогою технологій синхронної реплікації, для настроювання якої потрібно розглядати кожен вузол як незалежну систему зберігання. А StoreVirtual - це спочатку кластерна система зберігання даних, і кожен вузол - це пул ресурсів, який розширює ємність і продуктивність кластера і відмовостійкість системи в цілому.

Взаємодія вузлів StoreVirtual в кластері відбувається за технологією Network RAID - мережевий RAID. Якщо ми об'єднуємо, наприклад, кілька вузлів у кластер і в ньому створюємо віртуальний диск (LUN) з мережевим RAID 10, то кожен блок даних на цьому диску буде віддзеркалюватись між двома вузлами. Якщо в кластері два вузли і всі віртуальні диски об'єднані в RAID 10, то це, можна сказати, синхронна реплікація між двома вузлами. Відзначимо, що цей приклад є всього лише окремим випадком технології кластеризації StoreVirtual, так як її можливості набагато ширші.

Для серверів кластер зберігання - це єдиний пул ресурсів. Кожен LUN вони бачать по одному Virtual IP і звертаються до нього, як до єдиної системи зберігання, одночасно взаємодіючи з усіма вузлами кластера. При цьому розміщення вузлів StoreVirtual на різних майданчиках ніяк не позначається на роботі серверів.

Один кластер рекомендується розносити не більше ніж між трьома майданчиками (мал. 2). Система StoreVirtual дозволяє рознести вузли кластера і між чотирма майданчиками із збереженням однієї копії даних на кожному майданчику (Network RAID10 + 2), але для цього потрібно забезпечити підвищені вимоги до каналів зв'язку між майданчиками. Оскільки таке рішення потрібно дуже рідко, то в рекомендаціях «Best Practice» воно не вказано, але при цьому можливо і реалізовується.

Мал. 2. Розподілений між двома майданчиками кластер системи зберігання StoreVirtual з шести вузлів, де логічні диски є загальними і розподіленими між усіма майданчиками

В одному кластері можна організовувати різні рівні мережевого RAID для кожного віртуального диска (LUN):

• Network RAID 10 (2-Way Mirror) будується як мінімум на двох StoreVirtual в кластері, кожен блок даних зберігатися на двох вузлах (мал. 3);

Мал. 3. Розміщення блоків даних у середині кластера StoreVirtual з чотирьох вузлів, якщо для логічного диска обраний Network RAID 10

• Network RAID 10 + 1 (3-Way Mirror) - будується як мінімум на трьох StoreVirtual в кластері, кожен блок даних зберігається на трьох вузлах (мал. 4);

Мал. 4. Розміщення блоків даних усередині кластера StoreVirtual з чотирьох вузлів, якщо для логічного диска обраний Network RAID 10 + 1

• Network RAID 10 + 2 (4-Way Mirror) - будується як мінімум на чотирьох StoreVirtual в кластері, кожен блок даних зберігається на чотирьох вузлах (мал. 5);

Мал. 5. Розміщення блоків даних усередині кластера StoreVirtual з чотирьох вузлів, якщо для логічного диска обраний Network RAID 10 + 2

• Network RAID 5 (Single Parity) - будується як мінімум на трьох StoreVirtual в кластері, якщо, наприклад, у нас три вузли, то один блок даних пишеться на один вузол, другий блок даних - на другий вузол і парність цих даних - на третій вузол і так далі зі зміщенням на один вузол (мал. 6);

Мал. 6. Розміщення блоків даних усередині кластера StoreVirtual з чотирьох вузлів, якщо для логічного диска обраний Network RAID 5

• Network RAID 6 (Dual Parity) - будується як мінімум на п'яти StoreVirtual в кластері, працює, як Network RAID 5, але при цьому записується два парності для підвищеної відмовостійкості (мал. 7);

Мал. 7. Розміщення блоків даних усередині кластера StoreVirtual з шести вузлів, якщо для логічного диска обраний Network RAID 6

• Network RAID 0 - будується як мінімум на одному StoreVirtual в кластері, кожен блок даних зберігається на одному вузлі, відмовостійкість між вузлами не забезпечується.

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

Щоб уникнути втрати синхронізації майданчиків у разі порушення зв'язку між майданчиками, так званого «split-brain», існує StoreVirtual Failover Manager. Це віртуальна машина, яка розміщується на окремій або логічно відокремленому майданчику і стежить за тим, яка площадка повинна працювати, а яка повинна зупиниться автоматично при втраті каналу.

Вимоги до мережі для побудови одного кластера, разнесенного між майданчиками, наступні:

• рекомендована пропускна здатність для одного вузла - 50 МБ/с, але також потрібно враховувати, що вузли з 25-ма дисками і більше або з дисками SSD вимагають більшу пропускну здатність в залежності від навантаження і додатків;

• латентність - до 2 мс; система може працювати і з більшою латентністю, якщо додатки не вимогливі, але при великих затримках в каналі рекомендується будувати два кластери або більше і переходити на асинхронну реплікацію між кластерами;

• рекомендується використовувати одну підмережу. Якщо ж це нездійсненно, тоді можна використовувати різні підмережі на різних майданчиках. Але на одному майданчику потрібно використовувати одну підмережу.

Якщо відстань між майданчиками велика чи канал зв'язку не задовольняє вимогам, то на основному і резервному майданчиках будується окремий кластер StoreVirtual (мал. 8).

Мал. 8. Схема підключення вузлів StoreVirtual на основному і резервному майданчиках, які рознесені на велику відстань

Між кластерами, а точніше, між віртуальними дисками в кожному кластері, настроюється асинхронна реплікація за принципом Remote Snap. При цьому потрібно враховувати, що RPO і RTO збільшуються залежно від частоти снапшотов (мал. 9).

Мал. 9. Схема асинхронної реплікації з розподіленим на велику відстань логічним диском за допомогою Remote Snap між кластерами StoreVirtual на різних майданчиках для забезпечення катастрофостійкості

Рішення StoreVirtual володіє достатньо простою і зрозумілою консоллю управління, яка дозволяє управляти одночасно всіма сайтами і виділяти ресурси всього за кілька натискань миші.

StoreVirtual найчастіше застосовується для віртуалізованних середовищ з територіально рознесеною інфраструктурою. Наприклад, у випадку кількох корпусів навчального закладу або на території заводу з декількома будівлями СЗД може бути ідеальним вибором як для забезпечення відмовостійкості, так і мінімізації інвестицій, так як при використанні протоколу iSCSI не потрібно додаткового ліцензування.

Висновки

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

Синхронна реплікація вимагає якісні канали зв'язку між майданчиками, зазвичай рознесених на невеликі відстані, затримок не більше ~ 2-5 мс і досить високої смуги пропускання (в залежності від продуктивності). При синхронній реплікації RPO близько до 0, а RTO істотно зменшується. Якщо синхронну реплікацію поєднувати з функціями високої доступності на рівні додатків (HA-кластери для віртуалізації, стійкість до збоїв та ін.), то RTO також можна наблизити до 0.

При асинхронній реплікації вимоги до каналів не такі жорсткі, як при синхронній реплікації. Завдяки цьому асинхронна реплікація, в першу чергу, використовується при катастрофостійкої рішеннях, коли необхідно рознести інфраструктуру між містами, країнами і навіть континентами. Найчастіше використовується технологія асинхронної реплікації за допомогою снапшотов, а точніше, коли передаються тільки змінені дані (дельта) між миттєвими знімками. RPO в такому випадку залежить від частоти снапшотов і часу на їх передачу. Частоту снапшотов підбирають таким чином, щоб у проміжках між знімками канали та інфраструктура дозволяли передати дельту на віддалений майданчик. Максимальне RPO в такому випадку дорівнює часу між снапшотами + час, який йде на передачу дельти. Наприклад, якщо частота знімків становить 15 хвилин і дані (дельта) між знімками передаються на віддалену площадку за проміжок часу до 15 хвилин, то RPO буде в межах 0.

Дані та їх збереження завжди залишається ключовим завданням для ІТ-керівника. Як ми бачимо, виробникам систем зберігання є що запропонувати для вирішення широкого кола завдань. Який саме вид реплікації необхідний для вашого бізнесу, визначається критичністю додатків, що використовуються бізнесом, цінністю даних і економічною складовю їх збереження.