Ступені свободи програмно-визначаємого зберігання

Коріння зберігання яке визначається програмно (SDS) йдуть в віртуалізацію - додавання рівня абстракції між додатками і запам'ятовують. Це дає свободу надання сховища. Сучасному бізнесу потрібні продуктивні рішення, з простим управлінням, стійкі до сторонніх впливів.

Саме це обіцяють постачальники апаратних систем зберігання - високу доступність даних і відповідність навантажень. Але реальність така, що зростання навантажень і обсягів зберігання не уживається з СЗД консервативного дизайну. За характеристикою Асоціації виробників мереж зберігання даних (SNIA), системи зберігання, які визначаються програмно (SDS) відрізняє: автоматизація (спрощене управління), стандартні інтерфейси (API), віртуалізація шляхів даних (до блокових, файлових або об'єктних сховищ), масштабованість (без шкоди для продуктивності) і прозорість (маневр ресурсами). З таким букетом вимог апаратним СЗД не дано задовольнити розважливий бізнес.

Диктатура і вільности SDS

За великим рахунком, всі сучасні системи зберігання можуть бути віднесені до класу SDS - вони зроблені на стандартному серверному обладнанні та відрізняються специфічним програмним шаром. Kaminario, Pure, Tegile, Infinidat та інші поставники нових хвиль, що дає користувачам те, що і старожили ринка СХД - готові коробки. Від гіперконвергентних Nutanix та HPE Simplivity замовник отримує ще більше, ніж зберігання - повну середу виконання додатків. Все досить просто управляється і добре масштабується, своїми наборами будівельних блоків. При цілковитому комфорті для користувача, в цьому немає ні прозорості, ні економіки.

Повна свобода програмної визначенності не існує. Є ступені свободи, визначені «товщиною» складних абстракцій й охоплення завдань. Наприклад, VMware VSAN, Datacore або Microsoft S2D розподіляються у вигляді ПО. Інтегратор залишає їх на серверах, з урахуванням практик і обмежень розробників. Конечний користувач отримує набір серверів, із деякою прозорістю і люфтом по оснащенню. Співтовариство Ceph або ZFS пропонують багато програмного збору для блочного, файлового або об'єктного зберігання. Такі сервери та кластери працюють на типових платформах та компонентах, але не вимагають достатньої кваліфікації для розгортання та співпраці на клієнті.

Попередньо встановлені на серверах SDS-рішення зручні для корпоративного споживача: включай та працюй. Його не влаштовують поставлені обмеження постачальника). Гаразд би справа стосувалася тільки сервісної прив'язки. Мало кому до душі інфраструктура і компонентна залежність від одного постачальника

З іншої сторони, чим більш є вільним користувач у виборі «цеглин» зберігання, тим більше відповідальності лягає на нього самого. Тому виходить, що вибір відповідного SDS, змішується з плоскості лобового порівняння технічних характеристик / ціни у багато векторну оцінку ступенів вільностей.

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

Модульне зберігання

Open-E JovianDSS, програмне забезпечення системного зберігання на Linux / ZFS для створення великих масштабних зберігань - приклад роботи в SDS, коли інтегратор і його клієнти отримують достатню свободу для маневрів - програмними сервісами та варіанти фізичної реалізації. Інструменти коригування помилок, резервного копіювання та аварійного відновлення є в базі. Предметом вибору є протокол і середовище підключення, наповнення серверів, що управляють, комбінації дисків, рівні захисту даних.

Засобами різних кластерних топологій забезпечується безперервність доступу до даних.
У простому випадку, одиниця зберігання під управлінням Open - E JovianDSS - це стандартний сервер х86, із підібраними під навантаження CPU / RAM / SSD / HDD / мережевими адаптерами. Розділення сервера на голову, що управляє, і підключений до неї по SAS стандартний JBOD з дисками дає перспективу модульного розширення.

Під голови зберігання підходять типові 1u-платформы, вони є у всіх виробників серверів. Залежно від навантажень дані розміщуються в JBOD (на HDD) або JBOF (на SSD). Програмна ліцензія складається з двох частин: на вузол і на об'єм зберігання.

Для кластера високої доступності з двох серверів із загальним JBOD докупався другий вузол, ліцензія до нього та High Availability Cluster Feature pack. Відмова одного з вузлів управління не перериває постійний доступ до даних.

Сумніваючись в достатньому збереженні даних одного JBOD (єдина точка відмови), користувач може купити другий такий самий і додаткову ліцензію на об'єм.

HA- кластер дублює (в дзеркалі) диски двох JBOD, безпосередньо підключених до двох вузлів. З використанням MPIO рішення стає ще стійкішим до аварій. Об'єм зберігання розширюється таким, каскадом із JBOD. Стримує розвиток таких схем тільки обмеження SAS на довжину з'єднань 10 метрів (краще - менше).

Для катастрофостійкості зберігання використовують розтягнуті (stretched) кластери зберігання (метрокластеры). Вузли таких систем, що управляють, рознесені по локаціях. Open - E JovianDSS дозволяє синхронізувати дані двох сховищ на майданчиках, пов'язаних по Ethernet, на видаленні до 80 км. Для цього докуповується ліцензія Advanced Metro High Availability Cluster Feature pack.

Кластер працює майже як локальний, з перехресним підключенням JBOD до вузлів по SAS - за тим виключенням, якщо один вузол звертається до дисків безпосередньо, а другий  через Ethernet, з внутрішнім перетворенням протоколу і з невеликими затримками (при налаштуванні стежать, щоб рівень мережевих затримок не перевищував 5 мс). Усі вузли бачать усі диски, "чужі" помічені як Remote Disks.

Стійкість до відмов досягається копіюванням (дзеркалюванням)  локальних і видалених дисків. Такий двовузловий кластер дозволяє балансувати навантаження протоколів SMB, NFS та iSCSI між вузлами, завдяки активним пулам даних на обох. При аварії на одному з них, пули негайно активуються на другому.

Рівні страхового покриття.

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

Припустимо, у нас є дані і їх копія на основному високопродуктивному сховищі.

Карта ризиків і захистів виглядає так:

Упевненості додає купівля додаткового модуля зберігання - ще одного сервера з Open - E JovianDSS.

Карта ризиків "зеленіє", з'являється додатковий рівень страховки даних:

 Високий рівень доступності даних дає комбінація кластерної СХД на основному майданчику, локального сервера резервних копій і сервера резерву на видаленому майданчику. (Як варіант - метро-кластер з рознесеними по майданчиках серверами та даними.)

У такій інфраструктурі "зелена карта" покриває усі розумні риски:

Між розумними і красивими.

Компаніями рухають суперечливі бажання. З одного боку, вони хочуть купувати устаткування і відразу  працювати на ньому, не збираючи виконавчі механізми по шматочках. З іншою, їм все одно доводиться це робити: завдання які виникають, задають нові рівні навантажень. Погляд на зберігання як поступово модернізовану інфраструктуру приводить до логічного виведення: все повинно бути модульним, на стандартних блоках і інтерфейсах. Парирують навантаження заміною або додаванням модулів, а не купівлею нової СХД - неважливо, апаратною або програмно-визначуваною. Даних багато, дані різні, місце знайдеться усім. Був би порядок в головах.