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

Сучасні мережі і дата-центри бадьоро крокують до повної і тотальної програмно-визначається схемою, коли фактично неважливо, яке залізо ви напихаете всередину, все буде на софті. У стільникових операторів це почалося з того, що їм не хотілося ставити по 20 антен на будинок (у них вузли переконфигурируются, змінюють частоти та параметри просто оновленням конфига), а в дата-центрах спочатку з віртуалізації серверів, яка тепер мастхев, а потім продовжилося і віртуалізацією сховищ.

Але повернемося до Росії 2015 року. Нижче я покажу, як «з підручних засобів» (x86 машин і будь-яких «хранилок») заощадити грошей, підвищити надійність і вирішити ще ряд типових для сисадмінів середнього і великого бізнесу завдань.


На цій схемі видно обидві архітектури, про яких піде мова. SDS — два червоних контролера в центрі з будь-яким бекэндом, від внутрішніх дисків до FC полиць і хмар. І віртуальний SAN, на схемі Hyper-converged storage.

Найголовніше:
  • Вам плювати, що за залізо коштує: диски SSD, зоопарк виробників, старі і нові моделі… — все це віддається оркестирующему софту, і він призводить це до тієї віртуальної архітектури, яка вам потрібна у підсумку. Грубо кажучи, об'єднує в один том або дозволяє нарізати як вам зручно.
  • Вам плювати, які інтерфейси у цих систем. SDS побудується зверху.
  • Вам плювати, які функції ваші хранилки могли, а які не могли (знову ж, тепер вони можуть те, що треба: вирішує софт зверху).
Заодно розглянемо кілька типових задач з конкретним залізом і цінами.

Кому це треба і навіщо

Фактично SDS-софт для зберігання даних створює керуючий сервер (або кластер), до якого підключаються різні типи сховищ: дискові полиці, диски і оперативну пам'ять серверів (в якості кеша), PCI-SSD, SSD-полиці, а також окремі «шафи» систем зберігання даних різного типу та моделей від різних вендорів і з різними дисками і протоколами підключення.



З цього моменту все це простір стає загальним. Але при цьому розуміє, що «швидкі» дані треба зберігати там-то, а повільні архівні — взагалі воооон там. Ви ж як сисадмін, грубо кажучи, перестаєте думати категоріями «RAID-група на СГД», а починаєте мислити такими поняттями, як «є набір даних, треба розмістити їх в профілі ШВИДКІ». Зрозуміло, погодившись з майстром або преднастроив, що цей профіль ШВИДКІ знаходиться на таких дисках таких СГД.

Це ж ЗА використовує RAM серверів (контролерів віртуальної СГД) в якості кеша. Тобто звичайна x86 ОЗУ, до 1TB розміром, чз кеш і читає і пише, плюс є плюшки типу превентивного читання, угруповання блоків, багатопоточності і реально цікава Random Wrire Accelerator (але про це нижче).

найчастіші застосування такі:
  • Коли допитливий розум і/або сумний досвід призвели до розуміння, що без чесної синхронної реплікації між СГД не обійтися.
  • Банальний дефіцит продуктивності і бюджету одночасно.
  • Накопичилося багато сховищ. Великий парк, точніше, зоопарк: немає єдиного стандарту, змінюється протокол, і взагалі іноді з'являється відчуття, що треба все робити з нуля. Не треба, достатньо віртуалізації. Той же зоопарк, але на боці хостів (купа різних ОС і два, а то і три різних гіпервізора). І бажання або частіше необхідність використовувати одночасно iSCSI і FC. Або при використанні класичної СГД — в цьому випадку також можна використовувати безліч ОС.
  • Хочеться використати старе залізо, щоб не викидати його. Як правило, навіть сервера 8-річної давності цілком справляються з ролями нод — швидкість оперативної пам'яті з тих пір змінилася несильно, а більшого й не треба, вузьке місце зазвичай — мережу.
  • У вас багато випадкового запису чи потрібно писати багато потоків відразу. Випадковий запис перетворюється в послідовну, якщо використовувати кеш і його фічі. Можна використовувати навіть стару, зовсім стару систему зберігання даних в якості швидкої «файлопомойки» для офісу.


Що таке Software-defined Data Center і як SDS входять у філософію SDDC

Різниця між програмно-обумовленими інфраструктурами і звичайними «статичними» приблизно такі ж, які трапилися між старими добрими електросхемами на лампах і «новими» на транзисторах. То є досить і досить суттєва, але освоїти це спочатку досить складно. Потрібні нові підходи і нове розуміння архітектури.

Зазначу, що нічого прямо принципово нового в самій концепції Software-defined немає, і базові принципи застосовувалися ще мінімум років 15 тому. Просто називалося це інакше і зустрічалося далеко не скрізь.

У цьому пості ми обговорюємо SDS (Software Defined Storage), мова тільки про СГД, дискові масиви та інші пристрої зберігання, а також їх інтерфейси.

Говорити я буду про технології на базі софта DataCore. Це далеко не єдиний вендор, але він покриває практично всі завдання віртуалізації сховищ даних повністю.

Ось кілька інших вендорів, які вирішують завдання зберігання даних на програмно-визначаються архітектурах:
EMC з їх ScaleIO дозволяє об'єднувати будь-яку кількість x86-серверів з дисковими полицями в єдине швидке сховище. Ось теорія, а от практика відмовостійкої системи для вітчизняних не самих надійних серверів.



Вітчизняна RAIDIX. Ось про них і їх гриби.


Їх архітектура, що замінює для ряду специфічних завдань типу відеомонтажу за 10-20 тисяч доларів СГД вартістю в 80-100 тисяч

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


Сервера у містах 1 і 2 адресуються до СГД в Москві як до своїх дисків «в корпусі» з LAN-швидкостями. При необхідності можна працювати безпосередньо (випадок 3, аварійне відновлення офісу), але це вже означає звичайні затримки сигналу від міста до Москви і назад.

• Крім того, подібні рішення є у Citrix і ряду інших вендорів, але, як правило, вони більш заточені під власні продукти компанії.

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

RED HAT пропонує продукти CEPH або Gluster, але ці начебто на перший погляд красноглазые хлопці підтримали санкції.

У мене найбільший досвід саме з DataCore, тому заздалегідь прошу вибачити (і доповнити), якщо я ненароком омину чиїсь круті функції.

Власне, що треба знати про цю компанію: американці (але не приєдналися до санкцій, оскільки навіть не розміщувалися на біржі), на ринку 18 років, весь цей час пиляють під керівництвом все того ж мужика, що і на самому початку, один-єдиний продукт — софт для побудови СГД — SANsymphony-V, яку я далі буду називати для стислості SSV. Оскільки їх головний інженер, вони угорали за технологіями, але взагалі не думали про маркетинг. В результаті їх як таких ніхто не знав до останнього року, а вони заробляли тим, що вбудовували свої технології в чужі партнерські рішення не під своїм брендом.

Про симфонію

SSV — це софтверное сховище. З боку споживача (хоста) SSV виглядає як звичайне СГД, за фактом — як диск, встромлений прямо в сервер. В нашому випадку на практиці зазвичай це віртуальний багатопортовий диск, дві фізичні копії якого доступні через дві різні ноди DataCore.

Звідси випливають перша базова функція SSV — синхронна реплікація, і велика частина реально використовуваних LUN'ів DataCore — це відмовостійкі диски.

Софт може бути розміщений на будь-якому x86 сервері (майже), в якості ресурсів можуть бути використані майже будь-які блокові пристрої: зовнішні СГД (FC, iSCSI), внутрішні диски (включаючи PCI-SSD), DAS, JBOD, аж до підключених хмарних сховищ. Майже — тому що є вимоги до заліза.

Віртуальні диски SSV може презентувати будь-якому хосту (виключення ОС IBM i5).

Просте застосування (виртуализатор / FC/iSCSI таргет):



І ось цікавіше:



Солодка функціональність

У SSV є цілий набір функцій — кешування, балансування навантаження, Auto-Tiering і Random Write Accelerator.

Почнемо з кешування. Кеш тут — це вся вільна пам'ять сервера, на якому встановлений DC, працює і на запис і читання, максимальний обсяг 1Tb. Ті ж ScaleIO і RAIDIX не використовують оперативку, зате навантажують диски «своїх» серверів або контролерів. Це забезпечує більш швидкий кеш.

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

В цьому ж кеші на базі ОЗП серверів працює функція оптимізація рандомно запису, наприклад, під OLTP-навантаження.



Принцип у оптимізатора дуже простий: хост закидає на віртуальний диск випадкові блоки даних (наприклад, SQL), вони потрапляють в кеш (ОЗП), який технологічно вміє писати рандомные блоки швидко за рахунок упорядкування цих блоків в послідовності. Коли набирається достатній масив послідовних даних, вони переносяться на дискову підсистему.

Ще приблизно тут робиться попереджуюче читання, групування блоків, багатопоточність, консолідація блоків, захист від boot/login — шторму, блендер-ефекту. Якщо керуючий софт розуміє, що робить додаток хоста (наприклад, читає VDI-образ за стандартною схемою), то читання може проводитися раніше, ніж хост запросить дані, тому що те ж саме він вичитував останні кілька раз в такій же ситуації. Розумно покласти це в кеш в момент, коли стане зрозуміло, що саме він там робить.

Auto-Tiering — це коли будь-віртуальний диск базується на пулі, в який можуть бути включені різні носії — від PCI-SSD і FC СГД до повільних SATA і навіть зовнішніх хмарних сховищ. Кожному з носіїв присвоюємо рівень від 0 до 14, і софт автоматично перерозподіляє блоки між носіями, в залежності від частоти звернення до блоку. Тобто архівні дані кладуться на SATA і інші повільні носії, а гарячі фрагменти БД, наприклад, на SSD. Причому автоматично і оптимальним чином використовуються всі наявні ресурси, це не ручна обробка напилком.



Оцінка статистики та подальше переміщення блоків відбувається за замовчування раз в 30 секунд, але в разі якщо це не створить затримки для поточних завдань читання і запису. Балансування навантаження присутня у вигляді аналога RAID 0 — striping між фізичними носіями в дисковому пулі, а також як можливість повноцінно використовувати обидві ноди кластера (active-active) як основний, що дозволяє ефективніше навантажити адаптери SAN-мережу.

З допомогою SSV можна, наприклад, організувати метрокластер між СГД, які не підтримують таку можливість або вимагають додаткового дорогого обладнання для цього. І при цьому не втратити (при наявності швидкого каналу між вузлами), а вирости в продуктивності і функціоналі, плюс мати запас по продуктивності.

Архітектура



Архітектур у SSV всього дві.

Перша — SDS, програмно-визначуване сховище. Класична «важка» СГД являє собою, наприклад, фізичну стійку, де є RISC-сервера і SSD-фабрика (або HDD-масиви). Крім, власне, ціни дисків, вартість цієї стійки багато в чому визначається різницею архітектур, дуже важливою для рішень підвищеної надійності (наприклад, банків). Різниця в ціні між x86-й виробом китайських трудівників і схожою за обсягом СГД того ж EMC, HP або іншого вендора становить від порядку до двох при аналогічному наборі дисків. Приблизно половина цієї різниці припадає на архітектуру.

Так от, звичайно ж, можна об'єднати кілька x86-х серверів з дисковими полицями в одну швидку мережу і навчити працювати в якості кластера. Для цього є спеціальне ПЗ, наприклад EMC Vipr. Чи можна побудувати на базі x86-го сервера СГД, забивши його дисками під зав'язку.

SDS — це фактично такий сервер. З тією лише відмінністю, що в 99% випадків на практиці це будуть 2 ноди, а на бэкенде може бути все що завгодно.

Технічно це два x86 сервера. На них стоїть ОС Windows і DataCore SSV, між ними лінки синхронізації (блок) і управління (IP). Ці сервери розміщені між хостом (споживачем) і ресурсами зберігання, наприклад — купою поличок з дисками. Обмеження — повинен бути блоковий доступ і там і там.

Найбільш зрозумілим описом до архітектури буде процедура запису блоку. Віртуальний диск презентовано хосту як звичайне блоковий пристрій. Додаток пише на диск блок, блок потрапляє в ОЗП першого вузла (1), потім по каналу синхронізації записується в ОЗУ другого вузла (2), потім записано (3), записано (4).



Як тільки блок з'являється в двох копіях, додаток отримує підтвердження запису. Конфігурація платформи DC і бекенду залежить тільки від вимог по навантаженню з боку хостів. Як правильно продуктивність системи обмежена ресурсами адаптерів і SAN-мережі.

Друга — це Virtual SAN, тобто віртуальна СГД. DC SSV розміщується у віртуальній машині з Windows Server, в розпорядження DC віддаються ресурси зберігання, підключені до цього хосту (гіпервізору). Це можуть бути як внутрішні диски, так і зовнішні СГД, таких нод буває від 2 до 64 штук в поточній версії. DC дозволяє об'єднати ресурси «під» усіма гіпервізорами і динамічно розподілити цей обсяг.

Фізичних копій кожного блоку також дві, як у попередньої архітектурі. На практиці це найчастіше внутрішні диски сервера. Практика — зібрати відмовостійкий міні-ЦОД без використання зовнішнього сховища: 2-5 нод, які можна додавати при необхідності нових обчислювальних ресурсів або зберігання. Це окремий приклад модного зараз ідеї гиперконвергентной середовища, яка використовується Google, Amazon та іншими.

Простіше кажучи, можна побудувати Enterprise-середу, а можна взяти купу не найнадійнішою і не найшвидшою x86-техніки, забити машини дисками і полетіти захоплювати світ по дрібному прайсу.



Ось що вміє вийшла система:



Дві практичні завдання

Завдання №1. Побудова віртуального SAN. Є три сервера віртуалізації, розміщені в Центрі обробки даних (2 сервера) і Резервному центрі обробки даних (1 сервер).
Необхідно об'єднати у єдиний територіально розподілений кластер віртуалізації VMware vSphere 5.5, обеспечиться реалізацію функцій відмовостійкості і резервного копіювання за допомогою технологій:
• технологія високої доступності VMware High Availability;
• технологія балансування навантаження VMware DRS;
• технологія резервування каналів даних;
• технологія віртуальної мережі зберігання даних.

Забезпечити наступні режими роботи:
1) Штатний режим роботи.
Штатний режим роботи характеризується функціонуванням усіх ВМ у Підсистемі віртуалізації ЦОД і РЦОД.
2) Аварійний режим роботи.
Аварійний режим роботи характеризується таким станом:
а) всі віртуальні машини продовжують працювати в ЦОД (РЦОД) у випадках:
— мережевий ізоляції сервер віртуалізації в межах ЦОД (РЦОД);
— збою віртуальної мережі зберігання даних між ЦОД і РЦОД;
— збою локальної мережі між ЦОД і РЦОД.
б) всі віртуальні машини автоматичного перезапуску на інших вузлах кластера в ЦОД (РЦОД) у випадках:
— збою одного або двох віртуалізації серверів;
— відмови майданчики ЦОД (РЦОД) при катастрофі (збій всіх серверів віртуалізації).
























Характеристики серверного обладнання
Сервер № 1
Сервер
HP DL380e Gen8
2 х процесора
Intel Xeon Processor E5-2640 v2
Об'єм оперативної пам'яті
128 ГБ
10 х НЖМД
HP 300 ГБ 6G SAS 15K 2.5in SC ENT HDD
Мережевий інтерфейс
2* 10Gb, 4*1Gb
Сервер № 2
Сервер
HP DL380e Gen8
2 х процесора
Intel Xeon Processor E5-2650
Об'єм оперативної пам'яті
120 ГБ
8 х НЖМД
HP 300 ГБ 6G SAS 15K 2.5 in SC ENT HDD
Мережевий інтерфейс
2* 10Gb, 4*1Gb
Сервер № 3
Сервер
IBM x3690 X5
2 х процесора
Intel Xeon Processor X7560 8C
Тип оперативної пам'яті
IBM 8GB PC3-8500 CL7 ECC DDR3 1066 MHz LP RDIMM
Об'єм оперативної пам'яті
264
16 х НЖМД
IBM 146 ГБ 6G SAS 15K 2.5 in SFF SLIM HDD
Мережевий інтерфейс
2* 10Gb, 2*1Gb


Рішення:
• Використовувати наявне обладнання для створення підсистеми віртуалізації.
• На базі того ж обладнання і внутрішніх пристроїв зберігання серверів створити віртуальну мережу зберігання даних з функцією синхронної реплікації томів за допомогою програмного забезпечення DataCore.

На кожному сервері віртуалізації розгортається віртуальний сервер — вузол DataCore, до вузлів DataCore додатково підключені віртуальні диски, створені на локальних дискових ресурсах віртуалізації серверів. Дані диски об'єднуються в пули дискових ресурсів, на основі яких створюються дзеркальні віртуальні диски. Диски зеркалируются між двома вузлами DataCore Virtual SAN — таким чином, на пулі дискових ресурсів одного вузла розміщується «оригінал» диска, на другому — «дзеркальна копія». Далі віртуальні диски презентуються віртуалізації серверів (гипервизорам) або віртуальним машинам безпосередньо.

Виходить дешево і сердито (колеги підказують: конкурентне рішення по ціні) і без додаткового заліза. Крім вирішення безпосереднього завдання, мережа зберігання даних отримує масу корисного додаткового функціоналу: підвищення продуктивності, можливість інтеграції з VMware, миттєві знімки для всього обсягу і так далі. При подальшому зростанні потрібно тільки додавати вузли віртуального кластера або апгредить наявні.

Ось схема:



Завдання №2. Уніфікована система зберігання (NAS/SAN).

Все починалося з Windows Failover cluster для файлового сервера. Замовнику необхідно було зробити файлову кулі для зберігання документів — з високою доступністю і резервним копіюванням даних і з майже миттєвим їх відновленням. Було прийнято рішення будувати кластер.

З наявного обладнання у замовника було два сервер Supermicro (до одного з яких приєднано SAS JBOD). Дискового об'єму в двох серверах більш ніж достатньо (близько 10 ТБ на кожен сервер), однак для організації кластера необхідний shared storage. Також планувалося мати резервну копію даних, оскільки одна СГД — це єдина точка відмови, бажано з CDP з покриттям робочого тижня. Дані повинні бути доступні постійно, максимальний час простою — 30 хвилин (і то можуть полетіти голови). Стандартне рішення включало в себе покупку СГД, ще одного сервера для бекапів.

Рішення:
• ЗА DataCore встановлено на кожен сервер.
В архітектурі DataCore, Windows Failover Cluster може бути розгорнутий без використання спільного сховища SAN (використовуючи внутрішні диски серверів) або з використанням DAS, JBOD або зовнішніх СГД з повною реалізацією архітектури — DataCore Unified Storage (SAN & NAS), повною мірою використовуючи можливості Windows Server 2012 і NFS & SMB (CIFS) і надаючи сервіс SAN зовнішнім хостам. Така архітектура і була в підсумку розгорнута, і не використовується під файловий сервер обсяг дисків не був презентований як SAN для ESXi хостів.



Вийшло дуже дешево в порівнянні з традиційними рішеннями, плюс:
  • Відмовостійкість ресурсів зберігання (у тому числі в контексті роботи Windows Failover Cluster). У будь-який момент доступні дві дзеркальні копії даних.
  • Завдяки функціям віртуалізації вже самому Windows Cluster DataCore надає зеркалируемый багатопортовий віртуальний диск, тобто проблема тривалого chkdsk перестає існувати як така.
  • Подальше масштабування системи (наприклад, зростання обсягу даних вимагає підключення додаткового дискового масиву або нарощування обсягу самому сервері) являє собою вкрай простий процес і без зупинки роботи сервісу.
  • Виконання будь-яких технологічних робіт з обслуговування вузлів кластера — без зупинки сервісу файлового доступу.
  • CDP у SANsymphony-V10 вбудована функція і обмежується тільки вільним місцем на дисках.
  • Підвищення продуктивності ресурсів зберігання за рахунок переваг DataCore, а саме — функції Adaptive Caching, коли в якості кеша для підключених систем зберігання, використовується весь вільний об'єм ОЗП серверів, причому кеш працює і на запис і читання, але це важливіше для ESXi хостів, ніж для файлових кулю.


Головний принцип

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

Важливі практичні зауваження саме по Датакоре

  • У другій архітектурі DataCore робить майже те ж саме, що, наприклад, ScaleIO.
  • Якщо у вас є завдання забезпечити зберігання даних філій по Росії, але ви не хочете пов'язувати їх з поточної СГД і не хочете ставити нові СГД у філіях, тобто простий як колода метод. Берете три сервера по 24 диска і отримуєте прийнятний обсяг і прийнятну продуктивність для роботи більшої частини сервісів.
  • Якщо треба упорядкувати зоопарк — дешевше і простіше варіант знайти буде складно. Терміни такі: останній приклад — 8 днів на впровадження. Проектування — ще приблизно тиждень до цього. Наявне обладнання використовували, принципово нового не закуповували. Докупили тільки плашок оперативы в кеш. Ліцензія Датакоры йшла трохи більше тижня, але ми закладаємо дві.
  • Ліцензується DC за обсягом — пачками по 8, 16 ТБ. Ціни без знижок за street price такі (важливо: прайс нижче — умовний, насправді все досить гнучко, ліцензування здійснюється за хостами або ТБ і можна вибирати деякі функції, тому за фактом ціни сильно відрізняються, якщо потрібно розрахувати для вашого кейса — пишіть в лічку):
  • В одній з завдань у нас була організація DMZ-сегмента великої компанії. Для економії зберігання та оптимізація доступу до локального сховища поставили якраз DC. Загальний SAN ядро з DMZ не ділили, тому треба було б купувати СГД і ще одну залізяку типу файрволла з навішеннями для безпечного доступу всередину, або ворушити звивинами. Ми об'єднали 3 хоста віртуалізації в єдиний простір плюс оптимізували доступ. Вийшло дешево і швидко.
  • У ще однієї задачі у нас була оптимізація доступу під SQL. Там ми змогли використати старі повільні сховища. Запис завдяки кешу DC пішла швидше в десятки разів, ніж напряму.
  • Є корисний для деяких ситуацій RAID Striping (можна будувати програмні RAID0 та RAID1, навіть якщо підключений DAS цього не вміє).
  • Гарні звіти — візуальні і статистичні інструменти надання даних про всілякі параметри продуктивності з зазначенням «вузьких» місць.
  • QoS Control дає можливість СУБД і критичним додатком працювати швидше, встановлюючи обмеження на трафік введення/виводу для менш важливих навантажень.
  • Я вирубав вузли на тестах з харчування (в розумних межах, зберігаючи необхідну кількість вузлів для коректного відновлення), але не зміг зловити коррапты. Synchronous Mirroring & Auto Failover — є синхронна реплікація і механізми автоматичного і настроюваного відновлення після збоїв. Функція самолікування дискових пулів така: якщо фізичний диск в пулі виходить з ладу або позначений для заміни, DataCore автоматично відновлює пул на доступних ресурсах. Плюс журнал змін на диску з можливістю відновитися з будь-якого стану чи з якого часу. Планова заміна дисків, природно, робиться без перерви в роботі. Як правило, дані розмазують між іншими инстансами, а потім при появі першої можливості тому «заповзає» і на новий диск. Приблизно за схожим принципом робиться міграція між ЦОДами, тільки «заміна дисків» носить масовий характер.
  • Є Virtual Disk Migration — проста і ефективна міграція даних з фізичних ресурсів у віртуальні і назад. Причому без зупинки додатків.


Підводні камені

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

Другий мінус — потрібна класна кваліфікація з проектування мережі, оскільки саме в неї впирається підсумкова продуктивність системи. Всі вендори VirtualSAN створюють купу питань щодо проектування мережі, правильної смузі пропускання, споруді потоків. При цьому всі вони говорять «думати не треба».

Так от, треба думати, і це нетривіально, тому що треба дуже добре уявляти архітектуру, щоб спроектувати все як треба. Вистрілити собі в ногу — як нема чого робити.

У Датакоры є важлива особливість: кожне рішення проходить експертизу особисто у вендора. Вендор просто не бере на підтримку рішення, поки не пройде як проектне рішення (мережева частина), так і впровадження з подальшою здачею логів тестового запуску. Вони їх дивляться, кажуть «о'кей» — і ось тільки тоді воно приймається на підтримку.

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

Скріни для більшої зрозумілостіУправління всіма нодами йде з центру з однієї консолі або ґуя, тобто можна спростити процедури обслуговування.



Моніторинг процесу:



Тестування резервної копії:





Експорт для білінгу та журналу операцій:



Статистика:




Разом

  • Однозначний блоковий доступ, без «прошарків» типу пропрієтарних файлових систем або файлів віртуальних машин.
  • Файловий доступ, причому одночасно з блоковим.
  • Крос-платформна синхронна реплікація — зі свободою вибору апаратних засобів і протоколів підключення.
  • Ієрархічна структура зберігання з автоматизованим перерозподілом даних за рівнями зберігання. Необхідно також враховувати, що трьох класичних рівнів недостатньо. Необхідно п'ять, а краще десять, щоб додати хмарне сховище.
  • Оптимізація використання ресурсів і управління ресурсами: thin provisioning. централізоване управління і широкий набір інструментів аналітики та звітності. інтеграція з системами управління інфраструктурою (MS SCOM, vCenter і т. д.).
  • Багаторівневий захист даних: Snapshots, Continuous data protection. синхронна реплікація і асинхронна реплікація для побудови катастрофоустойчивого рішення.
  • Інструменти підвищення продуктивності (наприклад, кешування в RAM).


Хто використовує багато років і навіщо

SDS-підхід — це ферми Amazon, дата-центри Google і Facebook, але це дуже далекі від бізнесу речі. Більш практичні приклади такі:
  • Адміністрація Болоньї (великого міста в Італії) містить 50 офісів на 3500 машин і 4300 чоловік. Це музеї, бібліотеки, звичайні офіси управлінь міста, 200 шкіл та інші подібні будівлі. Дуже хотіли взяти і заощадити. Поставили SSV для 60 Oracle-инстансов, 10Тб пошти, 200 віртуальних машин. Нічого не викидали: з'єднали в SSV сховище IBM, NetApp, Nexsan і купу своїх флеш-дисків з серверів.
  • Найбільші вуглевидобувників з Польщі («Богданка») здобули не лише 8,3 мільйона тонн вугілля, але і багато геморою з впровадженням VMware і реплікацією. Подивившись на те, що який зоопарк виходить за класичними схемами, плюнули, розібралися і поставили SSV.
  • Imperial Tobacco з Польщі з 1400 співробітниками зловила оновлення SAP і трохи офігела, тому що пора було масштабуватися. Поставили під цю справу на гальмує вже залозі SSV, з'єднали серверні в будівлі в один кластер (як я вважаю, купили ще пару дешевих серверів, оперативки і іншого для організації контролерів) і знову стали жити як раніше. Плюс прикрилися від ризиків.
  • Шведський паперовий комбінат SCA просто хотів Hyper-V швидше. Поставили 2 ноди SANsymphony-V IBM System x3500 з 10 TB (12 дисків по 900 Гб) на звичайному 10 Гб/с Ethernet'е.
  • Шведські власники онлайн-казино з NetEnt відчули себе майже банком за обсягом операцій і транзакціями. Але до банківських цінників їм було далеко, тому вирішили робити реплікацію дешево і сердито. У них 14 SANsymphony-V нод на HP Proliant, 400 Тб під 1500 віртуальних машин.
  • Коледж Kirkless з Великобританії трохи млів від того, що творили там набігають 20 тисяч студентів в піках. Прикинувши, що ці ж студенти будуть творити через рік-другий, а то й п'ять-шість, вирішили не прив'язуватися до залозу і відразу закладатися на масштабовану архітектуру. Заодно сильно зменшили вартість зберігається гігабайти.


Все, ви дочитали до кінця, видихайте. Я можу ще годинами розповідати про особливості вирішення різних завдань на таких архітектурах, але пост вже вийшов величезним. Тому давайте або перейдемо до питань в коментарях, або ж з задоволенням відповім на ваші питання в пошті albelyaev@croc.ru.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.