Анархія в системі зберігання: немає майбутнього для SAN

Рік Вановер з Veeam нещодавно запросив мене в якості гостя для свого подкасту спільноти, щоб поговорити про віртуалізацію сховищ і використання стандартних серверних технологій, які трансформують сучасний центр обробки даних.

Послухати подкаст можна тут.

Як завжди, ми з Ріком любимо спілкуватися. Завдяки тому, що я працював у Microsoft як постачальник хмарних технологій, ми трохи поговорили про Windows 2012 R2 Storage Spaces, а також про конвергентні мережеві технології таких постачальників, як Cisco.

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

На початку цього року дописувач ZDNet Робін Гарріс опублікував статтю "

Чому SSD застаріли». Він наводить ряд важливих зауважень, оскільки переважно використовувані технології шин зберігання (SAS і SATA) потребують відчайдушної зміни.

Зрештою, інтерфейси шини SAS і SATA нинішнього покоління є просто еволюційним удосконаленням технологій інтерфейсу SCSI і ATA, які були продовжені десятиліттями раніше.

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

Як стверджує Робін, чи варто промисловості думати про модернізацію нашої основної технології шини/об’єднавчої плати? Чорт, так.

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

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

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

Всередині одного з цих шасі ви маєте об’єднавчі панелі SAS і SATA, інтерфейси структури зберігання, контролери та деяке спеціальне програмне забезпечення, яке виконує розділення лотків для презентації LUN. Більшість цих контролерів працюють на власних версіях UNIX або навіть похідних BSD, які ви ніколи не побачите — постачальники систем зберігання не дають вам доступу до цього, залишаючи вас своїм допоміжним програмним забезпеченням.

Здебільшого фрейм SAN або NAS є для вас чорною скринькою після того, як ви розділили лотки та передали серверу LUN.

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

І коли я маю на увазі гіпермасштаб, я маю на увазі Amazon Web Services, Microsoft Azures і Google Compute Engines у всьому світі.

Ви не думаєте, що цим компаніям вдається знизити ціну за найнижчі хмарні сховища за допомогою EMC та NetApps, чи не так? Звичайно, ні. Вони б розорилися, якби це зробили.

Замість пристроїв SAN і NAS провайдери гіпермасштабування в основному використовують JBOD -- фактично, пули "Просто купа дисків" протягом багатьох років. На відміну від малих і середніх компаній або підприємств, ці гіпермасштабовані хмарні провайдери створили власні архітектури сховищ, використовуючи стандартні частини, JBOD та власний інженерний досвід, щоб знизити витрати на зберігання значно нижче рівня корпоративних відповідники.

Здебільшого «секретний соус» для побудови архітектури зберігання товарів не був стандартизований, і цьому також заважав той факт, що один Головним перешкодам у цьому способі було постійне використання волоконно-канальних HBA для забезпечення кластерної структури зберігання даних, яка все ще була дорогий.

Зі спеціалізованими конвергентними мережами 10Gigabit і 40Gigabit Ethernet RDMA Карти Ethernet і поява SMB 3.0 протокол мережевого зберігання, проте це швидко змінюється.

Концепція досить проста — підключіть кілька «головок» файлового сервера до існуючої комутованої мережі Ethernet і використовуйте кілька JBOD (наприклад, зроблені від DataOn, Dell або Supermicro), заповнений комбінацією SAS 15K і SSD у багаторівневій конфігурації, підключеною до цих головок у кластері SAS формування.

Головки файлового сервера, у свою чергу, підключаються до ваших хостів віртуалізації або фізичних систем, які забезпечують підключення до ваших даних за допомогою SMB 3.0. Стійкість вбудована операційна система, яка сама забезпечує сховище, а не якийсь власний секретний соус, вбудований у контролери всередині сховища, як у випадку SAN або NAS.

У наведеному вище прикладі я використовую Масштабований файловий сервер Microsoft (SoFS), який безкоштовно вбудовується в Windows Server 2012 R2 і також базується на Microsoft Місця для зберігання це програмно-визначене сховище, вбудоване в ОС. Обладнання для зберігання даних, що використовується в цьому сценарії, — це DNS-1660D від DataOn у поєднанні з базовими серверами Dell R820 для монтажу в стійку та Mellanox RDMA картки.

Конфігурація, описана в технічному документі, на який посилається вище, здатна досягати стабільної швидкості понад 1 мільйон IOPS на секунду.

Сама Dell також опублікував власний білий документ про те, як створити SoFS за допомогою його MD1220 PowerVault Масиви JBOD, але, ймовірно, будь-яка комбінація JBOD і типового серверного обладнання x86, що використовує SAS і підключення Ethernet 10 Гбіт/с, дотримуючись цих основних архітектурних вказівок, повинна працювати.

Окрім SoFS і Storage Spaces від Microsoft, існують інші постачальники, які надають подібні архітектури зберігання на основі JBOD, наприклад Нексента (який базується на ZFS Solaris). Для Linux є HA-LVM і GFS/GFS2, який є надається з надбудовою RedHat Resilient Storage.

На сервері Ubuntu еквівалент викликається ClusterStack. Якщо ви шукаєте програмно-визначену архітектуру сховища Linux, дещо більш готову, ви можете перевірити QuantaStor від OSNEXUS.

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

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

Ваша організація вже почала використовувати програмно-визначене сховище за допомогою стандартного обладнання? Переговоріть і дайте мені знати.