Конспект адміна: відмінність мікроскопа від молотка при побудові SAN

<img src=«habrastorage.org/files/638/34e/d6a/63834ed6a2b14f7c89788e2f3b66954a.jpg» alt=«image» alt text"/>
Одного разу один з клієнтів компанії-інтегратора, де я працював, попросив оперативно намалювати проект невеликий системи зберігання даних. Як на зло, спеціальний людина по SAN виявився недоступний і завдання доручили мені. На той момент мої знання з СГД зводилися до непробивною ідеї "Fibre Channel – це круто, а iSCSI – не дуже".
Для всіх тих, хто потрапив у схожу ситуацію або трохи цікавиться темою SAN, ми підготували цикл матеріалів у форматі "конспект". Сьогоднішня стаття присвячена технологіям зберігання для невеликих і середніх організацій. Постараюся не чіплятися з теорією і використовувати побільше прикладів.
СГД різні і в міру незвичайні
Якщо інженер не особливо знайомий з мережами зберігання даних (СЗД), то вибір підходящого пристрою часто починається з вивчення ринку в розрізі власних стереотипів. Наприклад, я в свій час зазвичай зупинявся на простих DAS-системах, що дивно доповнювала своєю нелогічністю теза про "крутість" Fibre Channel. Зате DAS був зрозумілим і не вимагав читання довгих посібників адміністратора і занурення в темний світ мереж зберігання.
Якщо в організації просто закінчується місце на загальному мережному диску, то вистачить і недорогого сервера з відносно високою щільністю дисків, як зачепила на майбутнє. З спеціалізованих систем непогано підійде мережеве файлове сховище (NAS), зразок Synology DS414 SLim. На ньому і загальні папки створювати зручно, і права гнучко настроюються, і з Active Directory інтеграція є.
<img src=«habrastorage.org/files/0af/abf/b5b/0afabfb5b6ee4be883c093727208a997.jpg» alt=«image» alt text"/>
Чим мені подобаються сховища Synology, так це зручним інтерфейсом з безліччю плагінів на будь-які сценарії. Але поведінка у них буває досить дивним. Наприклад, у одного замовника був Synology DS411+II. Працював прекрасно до чергового перезавантаження, після якої не включився. Не питайте, як я до цього дійшов, але алгоритм запуску після збою був наступний:

1. Вийняти всі диски, увімкнути, вимкнути пристрій;

2. Увіткнути один диск, увімкнути, вимкнути пристрій;

3. Увіткнути другий диск, увімкнути, вимкнути пристрій;

4. Повторити для третього і четвертого диска. Після установки четвертого диска, пристрій включається і працює.

Спосіб був опублікований на форумі Synology і виявилося, що я не один такий везучий. З тих пір віддаю перевагу невеликі сервери з GNU\Linux на борту, у них хоча б з діагностикою простіше.
Із збірок для NAS можу порекомендувати Openmediavault.
Все ускладнюється коли потрібно наростити дисковий обсяг наявних серверів або з'являються думки про високої доступності. Тут-то і виникає спокуса побудувати повноцінну NAS або впасти в іншу крайність, обмежившись простою дискової полицею DAS.
Пара слів про те, що таке SAN і DAS. Просто освіжити пам'ять.
  • SAN, Storage Area Network – архітектурне рішення для підключення по мережі зовнішніх пристроїв зберігання даних, начебто дискових масивів і стрічкових бібліотек. Причому, підключити на блочному рівні, щоб клієнт працював з ними так само, як зі звичайними локальними дисками. У російськомовній літературі використовується абревіатура СГД (Мережа Зберігання Даних) – не плутайте з Системою Зберігання Даних, яку може вважатися будь-яка дискова полку.

  • Direct Attached Storage (DAS) – зовнішній диск або дисковий масив, підключений безпосередньо до сервера на блочному рівні.

У цій статті я не буду торкатися програмних реалізацій, начебто Storage Spaces в середовищі Windows, а обмежуся залізними та архітектурними нюансами СГД.
Навіщо окрема мережа зберігання
Почнемо з типових рішень для зберігання даних, які передбачають використання спеціальних мереж і інтерфейсів, так як з ними найбільше питань.
найдешевшим способом організації SAN є інтерфейс Serial Attached SCSI (SAS). Той самий, з допомогою якого підключаються диски в будь-якому сучасному сервері. Використовують SAS і для прямого підключення зовнішнього дискового масиву до сервера.
Для масиву DAS можлива організація відмови підключення до декількох серверів. Робиться це за допомогою Multipath, технології комутації клієнта та СГД за кількома маршрутами. Але більшою популярністю користується поділ дисків між серверами, які вже самостійно збирають з них групи RAID і ділять на тома. Подібна схема називається "Розділяється JBOD".
Для підключення до сервера використовуються адаптери (HBA) під конкретний інтерфейс, які просто дозволяють ОС побачити готові дискові томи.
<img src=«habrastorage.org/files/2a7/727/c9d/2a7727c9df034e8d8bc1f0696d0d5556.jpg» alt=«image» alt text"/>
Варто відзначити, що SAS підтримує три стандарти:
  • SAS-1, зі швидкістю 3 Гб/с на пристрій;
  • SAS-2, зі швидкістю 6 Гб/с;
  • SAS-3, надає вже 12 Гб/с
При плануванні архітектури варто також мати на увазі відмінності в роз'ємах SAS, що часто призводить до плутанини при замовленні кабелів. Найпопулярнішими при підключенні зовнішнього обладнання є SFF-8088 (mini-SAS) і SFF-8644 (mini-SAS HD).
Будучи частностью SCSI, SAS підтримує експандери, що дозволяє підключати до 65 535 пристроїв до одного контролера і порту. Звичайно, цифра скоріше теоретична і не враховує різні накладні витрати. Найчастіше зустрічаються контролери з реальним обмеженням 128 дисків, але масштабувати подібний SAN для двох і більше серверів простими экспандерами вже не так зручно. У якості більш адекватної альтернативи можна використовувати комутатори SAS. По суті, це ті ж експандери, але з підтримкою розподілу ресурсів по серверам, т. н "зонування". Наприклад, для стандарту SAS-2 найбільшою популярністю користується LSI 6160.
<img src=«habrastorage.org/files/f98/699/fa0/f98699fa01ac4636905d0a5aa7980f81.jpg» alt=«image» alt text"/>
З допомогою комутаторів SAS можлива реалізація відмовостійких схем для декількох серверів без єдиної точки відмови.
<img src=«habrastorage.org/files/7f6/1e1/f67/7f61e1f677964fd19865bd67fa1d7243.jpg» alt=«image» alt text"/>
З плюсів використання SAS можна відзначити:
  • Низьку вартість рішення;
  • Високу пропускну здатність – навіть при використанні SAS-2 вийде 24 Гб/с на кожен порт контролера;
  • Низька латентність.
Не обійшлося і без мінусів:
  • Відсутні механізми реплікації засобами дискового масиву;
  • Є обмеження на довжину кабельного сегмента: звичайний мідний SAS-кабель довше 10 м не зустрічається, активний – не більше 25 м. Існують і оптичні кабелі SAS з обмеженням у 100 метрів, але вони відчутно дорожче.
В якості типового рішення для малих і середніх організацій розберемо створення невеликого відмовостійкого кластера віртуальних машин. Під кластер виділимо два вузла з єдиним дисковим масивом. В якості умовного середнього обсягу дискового тому виберемо 1 ТБ.
Зауважу, що програмними рішеннями на зразок StarWind Native SAN можна отримати такий же кластер без окремого дискового масиву, або ж з простими JBOD. Крім того, більшість гіпервізора підтримують в якості сховищ мережеві ресурси NFS або SMB 3.0. Але в програмних реалізаціях більше нюансів і «слабких ланок» з-за більшої складності системи. Та й продуктивність зазвичай нижче.
Для складання такої системи знадобиться:
  • Два сервера;
  • Дисковий масив;
  • HBA для серверів;
  • Сполучні кабелі.
Дисковий масив візьмемо для прикладу HP MSA 2040 з дванадцятьма відсіками під HDD. Для підключення будемо використовувати SAS 3.0 на швидкості 12 Гб/с. Порахуємо першим-ліпшим конфігуратором загальну вартість системи зберігання:
Дискова полку HP MSA 2040 360 250 ₽
Dual Raid Controller 8x12 Gb SAS 554 130 ₽
HDD 600GB SAS 12G x4 230 560 ₽
Кабель mSAS зовнішній 2м x4 41 920 ₽
HP SmartArray P441 8-external channel SAS 12G x2 189 950 ₽
Разом 1 376 810 ₽
А ось і схема підключення:
<img src=«habrastorage.org/files/a09/bd3/6cf/a09bd36cf1c84591873460b7fabc9905.jpg» alt=«image» alt text"/>
Кожен сервер буде з'єднюватись з кожним контролером СГД для Multipathing.
На мій погляд, SAS 3.0 оптимальним, якщо не потрібні розподілені SAN-мережі і не потрібно детальне розмежування прав доступу до СГД. Для невеликої організації так можна досягти відмінного балансу ціни та продуктивності.
Після придбання другого масиву в майбутньому стане можливим з'єднання кожного сервера з контролером кожної дискової полиці, але при зростанні кількості клієнтів це серйозно ускладнить архітектуру. Для більшого числа клієнтів краще придбати один SAS комутатор. Або два, для побудови резервний рішення.
Традиційним вибором для побудови SAN є Fibre Channel (FC) – інтерфейс, що зв'язує вузли мережі по оптичному волокну.
FC підтримує кілька швидкостей: від 1 до 128 Гб/с (стандарт 128GFC вийшов як раз в 2016). В основному використовуються 4GFC, 8GFC і 16GFC.
Істотні відмінності порівняно з SAS-системами виявляються при проектуванні великих SAN:
  • Розширення виробляється не за рахунок експандера, а можливостями топології мережі;
  • Максимальна довжина кабелю при використанні одномодового оптоволокна може досягати 50 км.
У невеликих організаціях зазвичай застосовують структуру з одним комутатором (single-switch), коли один сервер через один комутатор підключається до дискового масиву. Така схема складає основу інших топологій: каскад (cascade), сітка (mesh) і кільце (ring).
Найбільш масштабована і відмовостійкий схема називається "центрально-розподілена" (core-edge). Вона нагадує всім відому мережеву топологію «зірка», але тільки в середині два центральних комутатора, розподіляють трафік по периферійним. Приватним випадком цієї схеми є «комутована архітектура» (switched fabric), без периферійних комутаторів.
При проектуванні варто звернути увагу на різні типи трансиверів. Це спеціальні модулі, які перетворюють цифровий сигнал в оптичний, для чого використовуються світлодіоди або лазерні випромінювачі. Трансивери підтримують різні довжини хвилі і різні оптичні кабелі, що впливає на довжину сегмента.
Є два типи трансіверов:
  • Короткохвильові (Short Wave, SW, SX) – підходять тільки для багатомодових волокон;
  • Довгохвильові (Long Wave, LW, LX), сумісні з многомодовым і одномодовим волокном.
До обом типам кабель підключається роз'ємом LC, а ось SC-роз'єми зустрічаються досить рідко.
<img src=«habrastorage.org/files/b21/1c2/8e0/b211c28e0b2b4e5db76460b8fb06358b.jpg» alt=«image» alt text"/>
Типовий HBA c двома портами FC
При виборі обладнання для SAN не зайвим буде перевірити всі компоненти за таблицями сумісності виробника заліза. Активне мережеве обладнання завжди краще вибирати одного бренду, щоб уникнути проблем сумісності навіть в теорії – це стандартна практика для подібних систем.
До плюсів рішень на FC можна віднести:
  • Можливість побудови територіально розподіленої SAN;
  • Мінімальна латентність;
  • Висока швидкість передачі даних;
  • Можливість реплікації і створення снапшотов силами дискового масиву.
На іншій чаші ваг традиційно лежить вартість.
Системи зберігання з розділу про SAS можна побудувати і на 16GFC, замінивши лише HBA і контролер дискової полиці. Вартість при цьому зросте вже до 1 845 790 ₽.
У своїй практиці я зустрічав у замовника побудований на FC масив DAS, заповненим дисками менш, ніж наполовину. Чому не використовували SAS? Найоригінальніший відповідь був такий: «а що, можна було?».
Пара слів про логічних портах.У більш складної інфраструктури FC стає структурно схожий на TCP\IP. У протоколу також описано рівні, як і у стека TCP\IP, існують маршрутизатори і комутатори, описано навіть "тегування" для ізоляції сегментів на манер VLAN. Крім того, на FC-комутаторах виконуються служби імен і виявлення пристроїв.
Не буду заглиблюватися в тонкощі, адже на тему FC написано вже чимало хороших статей. Зверну увагу лише на те, що при виборі комутаторів і маршрутизаторів для SAN потрібно звертати увагу на логічні типи портів. У різних моделях підтримуються різні поєднання основних типів з таблиці:
Тип Пристрою Назва Опис
N_Port (Node port) Використовується для підключення до комутатора або кінцевого пристрою.
NL_Port (Node Loop port) Порт з підтримкою топології «петля».
Комутатор\
Маршрутизатор
F_Port (Fabric port Для підключення N_Port, «петля» не підтримується.
FL_Port (Fabric Loop port), Порт з підтримкою «петлі».
E_Port (Expansion port Порт для з'єднання комутаторів.
EX_port Порт для з'єднання комутатора і маршрутизатора.
TE_port (Expansion port Trunking) E-port з підтримкою VSAN.
Загальне L_Port (Loop port) Будь-порт з підтримкою петлі (NL_port або FL_port).
G_port (Generic port) Будь незайнятий порт пристрою з авто визначенням.
<img src=«habrastorage.org/files/6ca/873/f0d/6ca873f0d90e46fcb2a82ecf54b30b4b.jpg» alt=«image» alt text"/>
Стаття була б неповною без згадки варіанти побудови SAN InfiniBand. Цей протокол дозволяє досягти високих швидкостей передачі даних, але по вартості виходить далеко за рамки SMB.
Використання звичного Ethernet
Можна обійтися і без вивчення нових видів мереж, використовуючи старий добрий Ethernet.
Популярний протокол для створення SAN в Ethernet-мережах називається Internet Small Computer Systems Interface (iSCSI). Будується він поверх TCP\IP, і головний його плюс в пристойної роботи за звичайною гігабітної мережі. У побуті такі рішення часто називають "безкоштовний SAN". Зрозуміло, гігабіта під серйозні завдання не вистачить, і до ваших послуг мережі 10 Гб/с
До безумовних плюсів можна віднести низьку вартість базового обладнання. Так як iSCSI реалізується програмно, можна встановити відповідні програми на звичайні сервери. Більшість NAS класу SOHO підтримують цей протокол спочатку.
У замовника одного разу гостро постало питання переміщення Exchange 2003 вмираючого сервера. Вирішили віртуалізувати його з мінімальним простоєм. Для цього підняли iSCSI target на тому самому NAS Synology DS411 з першої частини статті і підключили до Exchange. Далі перенесли туди БД і мігрували на MS Virtual Server 2005 c допомогою disk2vhd. Після успішної міграції перенесли базу назад. Пізніше такі операції проводилися при переході з MS Virtual Server на VMware.
Зрозуміло, для побудови SAN на iSCSI, навіть якщо для задач вистачає і гігабітної мережі, не варто "випускати" його загальний LAN. Працювати вона буде, але широкомовні запити та інший службовий трафік неодмінно позначаться на швидкості і створять перешкоди користувачам. Краще побудувати окрему ізольовану мережу зі своїм обладнанням. Або, в крайньому випадку, хоча б виділити підмережа з iSCSI в окремий VLAN. Варто відзначити, що для досягнення максимальної продуктивності таких систем необхідно включати підтримку Jumbo Frames на всьому шляху проходження пакетів.
Якщо гостро стоїть питання економії бюджету та мережеве обладнання 10 Гб в нього не вписується, то можна об'єднувати гігабітні порти за допомогою агрегації каналів (LACP). Так можна отримати недорогі 2-4 Гб/с лінки.
До речі, зовсім правильне iSCSI-рішення на базі 10 Гб мережі, з підтримуючими апаратне прискорення iSCSI мережевими картами та відповідними комутаторами наближається по вартості до FC.
<img src=«habrastorage.org/files/468/2d9/06f/4682d906f04843ba9749c98b90681620.jpg» alt=«image» alt text"/>
Подібна схема мережі можлива завдяки тому, що iSCSI працює поверх TCP\IP.
З цікавих рішень на базі iSCSI можна відзначити роботу тонких клієнтів <a href=«habrahabr.ru/post/144290>без сервера терміналів – замість локальних дисків використовується те iSCSI. Гігабітної мережі цілком достатньо для такої роботи, а реалізувати щось подібне іншими засобами не так просто.
Плюси рішення:
  • Низька вартість;
  • Можливість побудови територіально розподіленої мережі;
  • Простота проектування та обслуговування.
Мінуси:
  • Затримки при зверненні до даних можуть бути істотними, особливо при роботі з пулом віртуальних машин;
  • Підвищена навантаження на процесор, якщо не використовуються спеціальні HBA з апаратною підтримкою iSCSI.
Є і більш "доросла" альтернатива iSCSI. Можна використовувати ту ж мережу Ethernet, але протокол зберігання загорнути безпосередньо в кадри Ethernet, минаючи TCP\IP. Протокол називається Fibre Channel over Ethernet (Fco) для роботи використовує Ethernet 10 Гб. Крім традиційної оптики, можна використовувати спеціальні мідні кабелі або виту пару категорії 6a.
Важлива відмінність від FC в тому, що порт Ethernet можна використовувати спільно з TCP\IP. Для цього потрібні спеціальні мережеві адаптери, так звані Converged Network Adapter (CNA) з підтримкою FC і Fco, хоча є і програмні рішення. Оскільки протокол працює нижче рівня TCP\IP, то простий комутатор не підійде. Крім того, обов'язково повинна бути підтримка Jumbo-Фреймів і Data Center Bridging (DCB, іноді зустрічається Data Center Ethernet). Такі рішення зазвичай коштують дорожче (наприклад, Cisco серії Nexus).
В теорії, Fco можна запустити і в гігабітної мережі без використання DCB, але це досить неординарне рішення, для якого я не зустрічав оповідань про успішні запуски.
Якщо повернутися до нашого маленького, але гордого кластеру віртуалізації, то для нього рішення на 10 Гб/с iSCSI і Fco будуть практично однаковими за вартістю, але у випадку з iSCSI можна використовувати дешеві гігабітні мережі.
Також варто згадати і досить екзотичний протокол ATA over Ethernet (AoE), схожий по своїй роботі з Fco. Дискові масиви з них – рідкість, зазвичай використовуються програмні рішення.
Що в підсумку
Вибір конкретної реалізації системи зберігання вимагає вдумливого вивчення конкретної ситуації. Не варто підключати дисковий масив з допомогою FC просто тому, що "оптика" звучить гордо. Рішення на SAS дасть аналогічну або навіть більшу продуктивність там, де воно архітектурно доречно. Якщо не брати в розрахунок вартість та складності обслуговування, істотною відмінністю між усіма описаними технологіями підключення СГД буде дистанція сполук. Цю думку добре ілюструє один з кадрів презентації SNIA:
<img src=»habrastorage.org/files/c4e/ae6/a8e/c4eae6a8ed93466e82ced1db3067e37c.jpg" alt=«image» alt text"/>
Якщо після прочитання статті хочете детальніше вивчити самобутній світ SAN, можу порекомендувати такі бестселери:
Ми розмірковуємо над публікацією інших статей з серверним технологіям у форматі "лікнеп", тому було б добре отримати від вас зворотній зв'язок у вигляді оцінки цього матеріалу. Якщо якісь теми вам особливо цікаві – обов'язково розкажіть про них у коментарях.
Джерело: Хабрахабр

0 коментарів

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