Не поспішайте викидати старі сервери, з них можна зібрати швидку Ethernet-СГД за годину



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

Залізо, в цілому, непогана, просто минулого покоління. Викидати, природно, було шкода. Тоді я й запропонував протестувати ЕМС ScaleIO. Якщо коротко, працює це так:



ScaleIO — це софт, який ставиться на сервери поверх операційної системи. ScaleIO складається з серверної частини, клієнтської частини і нод управління. Дискові ресурси об'єднуються в одну віртуальну однорівневу систему.

Як це працює

Для роботи системи потрібно три керуючих ноди. Вони містять всю інформацію про стан масиву, його компоненти і процеси, які відбуваються. Це свого роду оркестраторы масиву. Для повноцінного функціонування ScaleIO повинна бути жива хоча б одна керуюча нода.

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

Клієнтська частина — це драйвер блочного пристрою вводу-виводу, який представляє розподілений по різних серверів лун у вигляді локального диска. Ось так, наприклад, лун ScaleIO виглядає на ОС Windows:



Вимоги для установки ScaleIO мінімальні:



Процесор
Intel or AMD x86 64-bit
Пам'ять
500 MB RAM для ноди управління
500 MB RAM на кожній ноде даних
50 MB RAM для кожного клієнта
Підтримувані операційні системи
Linux: CentOS 5.5-7.0, Red Hat 5.5-7.0, or SUSE 11 SP1, SP2 та SP3
Windows: 2008 R2, 2012, or 2012 R2
Hypervisors:
· VMware ESXi OS: 5.0, 5.1, or 5.5, managed by vCenter 5.1 or 5.5 only
· Hyper-V
· XenServer 6.1
· RedHat KVM
Зрозуміло, всі дані передаються по мережі Ethernet. Всі операції вводу-виводу і пропускна здатність доступні будь-якому додатку в кластері. Кожен хост пише на багато нод одночасно, а значить, пропускна здатність і кількість операцій вводу\виводу можуть досягати дуже великих значень. Додаткова перевага такого підходу в тому, що ScaleIO не вимагає толстого інтерконекту між нодами. Якщо на сервері стоїть Ethernet 1Gb, рішення підійде для потокової запису, архіву або файлової смітника. Тут же можна запустити тестову середу або розробників. При використанні 10Gb Ethernet і SSD дисків, отримаємо гарне рішення для баз даних. На SAS дисках можна підняти датасторы на VMware. При цьому віртуальні машини можуть працювати на тих же серверах, з яких віддається місце в загальний лун, адже під ESX є і клієнт, і серверна частина. Мені особисто дуже подобається така варіативність.

При великій кількості дисків з теорії ймовірності зростає ризик відмови будь-якого з компонентів. Рішення цікаве: крім RAID-груп на рівні контролерів, використовується дзеркалювання даних з різних серверів. Всі сервери поділяються на fault-сети — набір машинок з великою ймовірністю одночасного відмови. Дані зеркалируются між fault-сетами таким чином, що втрата одного з них не призведе до недоступності даних. В один fault-сет можуть входити сервери, розміщені в одній і тій же стійці, або сервери з різними операційними системами. Останній варіант приємний тим, що можна викочувати патчі на всі машини з Linux або Windows одночасно, не побоюючись падіння кластера з-за помилок операційної системи.



Тести

ScaleIO встановлюється з допомогою installation manager. У нього потрібно завантажити пакети програмного забезпечення для різних операційних систем і csv-файл з бажаним результатом. Я взяв 8 серверів, половину з Windows, половину з SLES. Установка на всі 8 посіла 5 хвилин і кілька натискань на кнопку «Далі».

Ось результат:





Це, до речі, GUI, через який можна керувати масивом. Для любителів консолі, є докладний мануал по cli-командам. Консоль як завжди більш функціональна.

Для тестів все ноди з даними я розділив на 2 Failover сету: з Windows і SLES. Мапим наш перший диск до хосту:



Об'єм диску невеликий, всього 56 Гб. Далі за планом тести на відмовостійкість, а мені не хочеться чекати закінчення ребілда більше 10 хвилин.

Для емуляції навантаження простіше всього використовувати IOmeter. Якщо диск відвалиться хоч на секунду, я про це обов'язково дізнаюся. На жаль, протестувати продуктивність в цьому тесті не вийде: віртуальні сервери, а датастор — EMC CX3. Нормальне обладнання зайнято в продакшне. От побігли перші байти:





Як я писав раніше, один fail-сет можна вимкнути. Починається найцікавіше. Приємно знати, що з продуктивом клієнта в екстрених ситуаціях все буде нормально, тому КРОК ми створюємо такі ситуації в нашій лабе. Найкращий спосіб переконати клієнта в надійності рішення для забезпечення високої доступності — вимкнути одну з двох стійок з обладнанням. Тут я роблю те ж саме:





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

Спробуємо включити 3 ноди з чотирьох:



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

Половина готова:



А ось тепер всі:



Дані повністю відновили надмірність. На 4-й ноде зараз нічого немає. Коли я її візьму, почнеться балансування всередині одного Failover set. Те ж саме відбувається і при додавання нових нсд.



Ребаланс даних запустився. Цікаво, що дані копіюються з усіх нод, а не тільки з нод того ж файловер сету. Після закінчення ребаланса на всіх ноди зайнято 14% місця. IOmeter, як і раніше, пише дані.



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

Ціна

Політика ліцензування ScaleIO — оплата тільки через сиру ємність. Самі ліцензії при цьому ніяк не прив'язуються до заліза. Це означає, що можна поставити ScaleIO на найдавніше залізо, а через кілька років замінити його на сучасні сервери без докупки ліцензій. Трохи незвично після стандартної політики ліцензування масивів, коли апгрейдные диски коштують дорожче, ніж ті ж самі диски при первинній покупці.

Прайсова ціна ScaleIO приблизно 1572 доларів за терабайт сирого місця. Знижки обумовлюються окремо (думаю, якщо ви дочитали до цього місця, не треба пояснювати, що таке «прайсова ціна). У ScaleIO є аналоги серед опенсорс-рішень, і у інших виробників. Але у ScaleIO важливий плюс — цілодобова підтримка EMC і величезний досвід впроваджень.

Колеги з EMC стверджують, що можна заощадити до 60% витрат у п'ятирічній перспективі в порівнянні з мидрейнджевой СГД. Це досягається як за рахунок здешевлення ліцензій, так і за рахунок зниження вимог до залозу, а також харчування, охолодження і, відповідно, місцем в дата-центрі. У результаті рішення вийшло цілком «антикризовим». Думаю, в цьому році воно багато кому стане в нагоді.

Що ще можна зробити

  • ScaleIO можна розділити на ізольовані домени (це для хмарних провайдерів).
  • Софт вміє створювати миттєві знімки і обмежувати швидкість клієнтів
  • Дані на ScaleIO можна шифрувати і розкладати по пулам з різною продуктивністю.
  • Лінійне масштабування. З кожним новим хостом збільшується пропускна здатність, продуктивність і обсяг.
  • Failover сети дозволяють втрачати сервери до тих пір, поки є вільне місце для відновлення надлишковості даних.
  • Варіативність. Можна збирати дешеву файлову смітник на SATA-дисках, а можна швидку систему зберігання з SSD-дисками.
  • Цілком замінює мидрейджевые СГД на деяких проектах.
  • Можна використовувати невикористовуване місце на існуючих серверах або подарувати друге життя старим залозу.
З мінусів — потрібна велика кількість портів в мережевих комутаторах і велика кількість ip-адрес.

Типові застосування
  • найочевидніше — для побудови публічного або приватного хмари компанії. Рішення легко розширювати, ноди легко додавати і змінювати.
  • Для віртуалізації інфраструктури. Є ж клієнти для ESX, тому нічого не заважає нам зробити пул ScaleIO (можна навіть на локальних дисках тих же серверів, на яких варто ESX) та покласти на нього віртуальні машини. Таким чином можна забезпечити гарну продуктивність і додаткову відмовостійкість при порівняно невеликих витратах.
  • В конфігурації з SSD і 10G Ethernet, ScaleIO відмінно підійде для середніх і малих баз даних.
  • В конфігурації з ємними SATA-дисками можна зробити дешеве сховище або архів, який, тим не менше, не можна помістити на стрічку.
  • ScaleIO на SAS дисках буде відмінним рішенням для девелоперів і тестувальників.
  • Підходить для деяких завдань відеомонтажу, коли потрібно поєднання швидкості, надійності і невеликий ціни (потрібно тестувати прикладі під конкретику, звичайно).Система може бути використана для зберігання великих файлів начебто стрімінг з HD-камер.


Підсумок

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

Якщо вас зацікавила, є бажання протестувати його під конкретні завдання або просто обговорити — пишіть на rpokruchin@croc.ru. На тестовому залозі можна робити все, як в тому анекдоті про нову фінську бензопилу і сибірських мужиків.

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

0 коментарів

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