Конспект адміна: корпоративні SAN і найголовніше в роботі архітектора

<img src=«habrastorage.org/files/f3c/9ca/a21/f3c9caa216cf414f8968b95aae90231c.jpg» alt=«image» alt text"/>
У минулій статті я розповів про основні поняття SAN на прикладі невеликих інсталяцій. Сьогодні копнемо глибше і розберемося з побудовою мереж зберігання для великої організації. Зрозуміло, одна коротка стаття ніяк не замінить об'ємні праці Brocade і HP, але хоча б допоможе зорієнтуватися і вибрати правильний курс при проектуванні.
При побудові великих мереж зберігання основним головним болем стає архітектура рішення, а зовсім не типи оптики і виробники комутаторів. Вузлів-споживачів значно більше і багато хто з них критичні для бізнесу, тому використовувати просту схему "підключив кілька серверів до сховища безпосередньо, так і всі" не вийде.
Пара слів про топологіях і надійності
Якщо дещо спростити, то "велика" мережа SAN відрізняється від маленької тільки надійність і, меншою мірою, продуктивністю. Базові технології та протоколи аналогічні тим, що застосовуються в мережах з декількох серверів. Як правило, окремі мережі SAN називають фабриками – в одній організації може вільно перебувати з десяток фабрик.
В інфраструктурі рівня Enterprise балом як і раніше правлять протокол Fibre Channel і оптичні лінії. Останні роки активну експансію ведуть конвергентні рішення, але про них я розповім трохи пізніше.
Під спойлером заховані основні топології SAN, щоб трохи освіжити знання
  • Каскад. Найгірша топологія, яка іноді застосовується з невеликим кількість вузлів.
    <img src=«habrastorage.org/files/114/939/4d9/1149394d918c47c0a31e39657f9ca36a.png» alt=«image» alt text"/>
    Пристрої послідовно підключені один до одного, що дає більше точок відмови і збільшення навантаження при масштабуванні. Приватним випадком каскаду можна назвати з'єднання точка-точка, коли СГД підключається безпосередньо до сервера.
  • Кільце. Той же каскад, але кінцевий комутатор з'єднаний з першим. Надійність і продуктивність більше, адже протокол FSPF (Fabric Shortest Path First) допоможе вибрати найкоротший маршрут. Однак, працездатність такої мережі часто порушується в процесі масштабування і не гарантується при обриві декількох лінків.
    <img src=«habrastorage.org/files/fc4/f42/fea/fc4f42fead6b4ec0ab32522c26df2854.png» alt=«image» alt text"/>
  • Повний граф (full mesh), де кожен комутатор з'єднаний з кожним. Така топологія має високу відмовостійкість і продуктивністю, але вартість рішень і можливості масштабування залишають бажати кращого.
    <img src=«habrastorage.org/files/6b2/447/1f4/6b24471f4b424673960797da1b4988c7.png» alt=«image» alt text"/>
    Граф зручно використовувати для зв'язку прикордонних комутаторів декількох майданчиків.
  • Ядро-периферія (core-edge). На практиці використовується найчастіше і по своїй суті аналогічна звичної мережевої топології "зоря".
    <img src=«habrastorage.org/files/6e4/0ff/455/6e40ff455fa1470caf191482ccf48a31.png» alt=«image» alt text"/>
    У центрі розміщуються кілька комутаторів (ядро мережі), до них підключаються периферійні комутатори з кінцевими пристроями. Рішення виходить резервний, продуктивним і добре масштабованим.

Основною схемою побудови SAN в більшості випадків є Core-Edge, з кількома зарезервованими комутаторами в центрі. Рекомендую використовувати в першу чергу її, а всяку екзотику зберегти для нетипових випадків. До речі, кільце, незважаючи на свою моральну зношеність, активно використовується всередині систем зберігання для з'єднання дисків з контролерами.
Якщо вам вже доводилося будувати кластер якоїсь системи, то з поняттям єдиної точки відмови вже знайомі.
Пам'ятка, на всякий випадокЄдина точка відмови – це будь-який компонент системи, чий вихід з ладу порушує працездатність всієї системи найрадикальнішим чином. Таким компонентом може бути не зарезервоване мережеве з'єднання, єдиний контролер у системі зберігання або комутатор SAN.
Основна робота проектувальника мережі зберігання полягає в тому, щоб побудувати мережу без єдиної точки відмови, в якій оптимально поєднуються масштабованість і вартість. У якості відправної точки вибирають побудова двох незалежних фабрик для підстраховки один одного. Називається таке рішення "резервована фабрика", і всі її вузли підключаються одночасно до двох фабрикам з використанням технології Multipath.
Якщо щось трапляється з будь-яким важливим вузлом одній з фабрик, то обмін даними відбувається через її дублера, без будь-яких негативних наслідків. Зрозуміло, при побудові треба закласти в кожну фабрику деякий запас продуктивності, як правило дворазовий. Якщо цього не зробити, то при аварії може помітно просісти продуктивність будь-яких використовують SAN сервісів.
Ще один момент, який варто враховувати, називається SAN Oversubscription.
<img src=«habrastorage.org/files/f02/86a/43a/f0286a43ab6e4eeca5d4100efbb12b0c.jpg» alt=«image» alt text"/>
Цей труднопереводимый термін передбачає наступну ситуацію:
  • У вас є кілька відносно-повільних споживачів і обмежене число портів на комутаторі.
  • Логічно, що ви вирішуєте повісити їх на один порт з допомогою послідовного сполуки, на зразок того ж каскаду. Як варіації на тему: підключення декількох клієнтів з каналами 8 Гб до окремих портів комутатора; а сам комутатор підключений до мережі сховищ недостатньо швидким лінком.
  • Якщо швидкість порту, до якого підключені всі ці пристрої, не дозволяє одночасно обслужити всіх без просідання швидкості, то з високою ймовірністю у вас будуть проблеми. Закон Мерфі ніхто не відміняв.
тобто, при ситуації Oversubscription в канал намагається пролізти більше трафіку, ніж може осилити цей канал. Зрозуміло, виникають черги на вході і падає продуктивність конкретних додатків. Щоб такого не відбувалося, завжди залишайте запас пропускної здатності "тунелів" між фабриками і уникайте підключення клієнтів до одного порту комутатора.
Вибір обладнання для мереж FC
Як це зазвичай буває, переваги тому чи іншому виробникові – питання ідеологічний. Але є кілька відомих гравців на ринку SAN, чиї системи ви зустрінете у великій мережі з більшою ймовірністю:
  • Мережеві адаптери QLoqic, комутатори і маршрутизатори SAN від Brocade, HP і Cisco.
  • Системи зберігання HP, NetApp, IBM. Зрозуміло, список не повний.
Незважаючи на те, що сервіси FC можуть похвалитися високою стандартизацією і довгою історією, як і раніше діє золоте правило проектувальника: строй мережу на устаткуванні одного виробника. Тобто, все, що забезпечує зв'язок клієнта і сховища, варто придбати у одного виробника. Так ви уникнете проблем сумісності та різноманітних "плаваючих глюків".
Якщо з якихось причин золоте правило у вашій ситуації не застосовується, то обов'язково звіряйтеся з таблицями сумісності від виробників обладнання:
Особисто я тільки два рази стикався з проблемами сумісності, але кожен раз це було досить неприємно. По одному з випадків не згадаю вже конкретних учасників, але у FC-адаптера стійкового сервера періодично і без всякої причини пропадали обидва оптичних лінка (основний і резервний), доводилося вручну перепідключати. Вирішилося, по-моєму, установкою інших трансиверів. А проблемні трансивери спокійно працювали в іншій мережі однієї з філій компанії.
Про відстані
Якщо ви працюєте на заводі або просто у великому офісному центрі, то актуальним стає питання територіально-розподілених мереж. Банальні кілька поверхів в будівлі можуть вилитися в кілька сотень метрів оптоволокна і доведеться враховувати технологічні особливості:
  • Треба вибирати правильні трансивери для одномодового волокна, так як саме воно підходить для використання на великих відстанях.
  • Якщо мова йде про протягуванні оптики між будівлями (стовпів), то значно дешевше може виявитися мережа Fco на базі звичайного Ethernet на витій парі.
  • Довгі сегменти "темній оптики" (лінк між двома клієнтами, в якому немає активних мережевих пристроїв) можна розділяти на короткі за допомогою тих же комутаторів. До речі, це популярний варіант для побудови оптичної мережі в будівлі: по парі комутаторів на кожному поверсі.
Виходячи з практики, я б рекомендував використовувати для розподілених сегментів Fco або навіть звичайну TCP/IP мережу. Відмовостійкість і синхронізацію у такому разі можна виконувати на рівні конкретних додатків.
<img src=«habrastorage.org/files/f04/a29/9ca/f04a299caebe47e8be727766999e1b26.jpg» alt=«image» alt text"/>
Яскравий приклад – MS SQL. Зовсім необов'язково будувати 8 Гб оптичну мережу між будівлями в промзоні, щоб забезпечити доступ клієнтів до єдиної бази. Достатньо організувати підключення на рівні термінального сервера або клієнтської частини програми, яка використовує MS SQL (1С, наприклад). Не завжди потрібно вирішувати питання "в лоб" і проектувати складну і дорогу мережу зберігання.
Гиперконвергенция, перезавантаження
5 Років тому на багатьох технологічних конференціях активно просувалася ідея конвергентної інфраструктури. Її підносили як неймовірне нововведення і технологію побудови ЦОД майбутнього, не пояснюючи, у чому суть. А суть дуже проста – універсальний транспорт як для мереж зберігання, так і для звичайних LAN. Тобто, потрібно прокласти лише 1 високопродуктивну мережу, яку можна використовувати як для робота зі сховищами, так і для доступу користувачів до 1С.
Але диявол, як завжди, криється в деталях. Щоб все працювало, потрібно спеціальне мережеве обладнання та конвергентні адаптери у кожного клієнта. Зрозуміло, що ці нововведення коштують досить дорого і в прості робочі станції їх ставити не доцільно. Тому ідея трохи трансформувалася і тепер застосовується тільки в рамках дата-центру.
Взагалі, конвергентність як ідея з'явилася значно раніше, ще в Infiniband. Це високошвидкісна (до 300 Гбіт) шина обміну даними з низькою латентністю. Зрозуміло, рішення на базі Infiniband коштує значно дорожче того ж FC і застосовується тільки в дійсно високопродуктивних кластерів.

Ключовими особливостями Infiniband є підтримка прямого доступу до пам'яті іншого пристрою (RDMA) і TCP\IP, що дозволяє використовувати ці мережі як для SAN, так і для LAN.
<img src=«habrastorage.org/files/9df/6f3/463/9df6f3463e8348ef8bfadc512723627d.jpg» alt=«image» alt text"/>
Конвергентні мережі часто використовуються в блейд-систем, так як відмінно вписуються в ідею набору серверів із загальними ресурсами і мінімумом зовнішніх підключень. Але зараз в моді вже гиперконвергентные системи, де до загальної ідеї віртуалізації мереж додається модульність і більш гнучке масштабування _ кожен вузол в таких рішеннях є програмно-обумовленим. В якості яскравого прикладу можна згадати Cisco ASAv і модуль OpenStack Neutron.
Якщо в комплексних рішеннях звичні дискові масиви ще можуть використовуватися, то в гиперконвергентных системах їх роль визначається програмно для кожного конкретного модуля. Якщо у вас немає якихось особливих вимог до системи зберігання, начебто підтримки специфічної реплікації, то я б радив придивитися до SDS-рішень (Software-Defined Storage).
<img src=«habrastorage.org/files/074/5e0/31b/0745e031b2834a8fa4d9b256e4bcc22d.jpg» alt=«image» alt text"/>
Фактично, це просто сервер з набором дисків і спеціальним. Яскраві приклади: vSAN від VMware і Storage Spaces від Microsoft. В якості апаратної складової можна використовувати щось подібне з дисковою DAS-полицею. Головне, щоб була велика дискова кошик і достатній обсяг оперативної пам'яті.
У SDS часто зустрічається цікава технологія Cache Tiering. Два і більше диска різних швидкостей об'єднуються в один дисковий пул, часто використовувані дані з якого зберігаються на окремих SSD-дисках. Подібний гібрид дозволяє за мінімум грошей отримати продуктивність рівня all-flash масивів, хоча і з деякими застереженнями.
Разом
"чистої класики" поступово йде, і розрив між класичними СГД та рішеннями SDS скорочується. Наприклад, якщо судити по деякими тестів, сховище VMware vSAN відстає від звичайних класичних масивів того ж рівня менш ніж на 10%.
Традиційно, ось невеликий список ресурсів, які колись допомогли мені у вивченні технологій SAN і SDS:
Джерело: Хабрахабр

0 коментарів

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