Як розробники сиділи в Петербурзі і тихо їли гриби, а потім написали ОС для систем зберігання даних



В кінці 2008 року на тоді ще невелику петербуржскую компанію вийшов один західний медіахолдинг приблизно так:
— Це ви там упоролись по хардкору і пристосували SSE-інструкції для реалізації коду Ріда-Соломона?
— Так, тільки ми не…
— Та мені пофіг. Хочете замовлення?

Проблема була в тому, що відеомонтаж вимагав адовой продуктивності, і тоді використовувалися RAID-5 масиви. Чим більше дисків в RAID-5 — тим вище була ймовірність відмови прямо під час монтажу (для 12 дисків — 6%, а для 36 дисків — вже 17-18%). Дроп диска при монтажі неприпустимий: навіть якщо диск падає в хайэндовой СГД, швидкість різко деградує. Медиахолдигу набридло з криком битися головою об стіну кожен раз, і тому хтось порадив їм похмурого російського генія.

Багато пізніше, коли наші співвітчизники підросли, виникла друга цікава задача — Silent Data Corruption. Це такий тип помилок зберігання, коли на млинці одночасно змінюється і біт в основних даних, і контрольний біт. Якщо мова про відео або фотографії — в цілому, ніхто навіть не помітить. А якщо мова про медичні дані, то це стає діагностичною проблемою. Так з'явився спеціальний продукт під цей ринок.

Нижче — історія того, що вони робили, трохи математики і результат — ОС для highload-СГД. Серйозно, перша російська ОС, доведена до розуму і випущена. Хоч і для СГД.

Медіахолдинг

Історія почалася в 2008-2009 як проект для американського замовника. Потрібно розробити таку систему, яка забезпечувала б високу продуктивність і при цьому коштувала б менше кластера з готових хайэндовых СГД. У холдингу було багато стандартного заліза за типом Амазон-ферм — x86-архітектура, типові полиці з дисками. Передбачалося, що «ці російські» зможуть написати такий керуючий софт, який буде поєднувати пристрої в кластери і забезпечувати тим самим надійність.

Проблема, звичайно, в тому, що RAID-6 вимагав дуже великої обчислювальної потужності для роботи з многочленами, що було непростим завданням для x86 CPU. Саме тому виробники СГД використовували і використовують свої варіанти і поставляють в результаті стійку як свого роду «чорний ящик».

Але повернемося на 2009 рік. Основним завданням на початку проекту було швидке декодування даних. Взагалі, високою продуктивністю декодування компанія RAIDIX (так стали звати наших героїв набагато пізніше) займалася завжди.

Друга задача — щоб при виході з ладу диска не просаживалась швидкість читання-запису. Третя задача трохи схожа на другу — боротися з проблемами помилок на HDD, які відбуваються невідомо коли і на якому носії. Фактично, відкрилося нове поле роботи — виявлення прихованих дефектів даних на читання і їх виправлення.

Ці проблеми були актуальними тоді тільки для великих, дуже великих сховищ і реально швидких даних. За великим рахунком, архітектура «звичайних» СГД влаштовувала всіх, крім тих, хто постійно використовував реально великі обсяги даних на читання-запис (а не працював 80% часу з «гарячим» набором даних, що становлять 5-10% СУБД).

Тоді не було як таких стандартів end-to-end data protection (точніше, не було нормальної реалізації), так і зараз вони підтримуються не всіма дисками і контроллерми.

Рішення перших завдань

Розпочався проект. Андрій Рюрикович Федоров — математик і засновник компанії, почав з оптимізації відновлення даних, використовуючи типову архітектуру процесорів Intel. Якраз тоді перша проектна група знайшла простий, але реально дієвий підхід до векторизації множення на примітивний елемент поля Галу. При використанні SSE-регістрів одночасно множаться 128 елементів поля на x за кілька XOR. А як ви знаєте, множення будь-яких поліномів в кінцевих полях можна звести до множення на примітивний елемент за рахунок факторизації множення. Взагалі було безліч ідей з використанням розширених можливостей процесорів Intel.

Коли стало зрозуміло, що ідеї, в цілому, мають успіх, але потрібно написання продукту рівня ОС для роботи на самому низькому рівні, спочатку був виділений департамент, а потім була заснована окрема компанія RAIDIX.

Ідей було багато, для опрацювання та перевірки були знайдені співробітники університету СПБДУ. Почалася робота на стику науки і технології — спроби створення нових алгоритмів. Наприклад, дуже багато працювали з обігом матриць (це алгоритмічно складне завдання, але дуже важлива для декодування). Колупали Ріда-Соломона, пробували збільшити розмірність поля двох до шістнадцятої, двох у двісті п'ятдесят шостого ступеня, шукали швидкі способи виявлення Silent Data Corruption. Проводили досліди до прототипів на асемблері, оцінювали алгоритмічну складність кожного варіанту. В більшості своїй досліди давали негативний результат, але приблизно на 30-40 спроб одна була позитивною по продуктивності. Наприклад, те ж збільшення розмірності поля довелося прибрати — в теорії це було чудово, але на практиці викликало погіршення декодування, тому що сильно збільшувався cache miss (непопадання в кеш).

Далі йшла планомірна робота по розширенню RAID 7.N. Перевіряли, що буде при збільшенні кількості дисків, розбиття на диск і так далі. Intel додав набір інструкцій AES для безпеки, серед яких виявилася дуже зручна інструкція для множення поліномів (pclmulqdq). Думали, що її можна використовувати для коду — але після перевірки переваг в порівнянні з вже наявною продуктивністю не знайшли.

Компанія виросла до 60 осіб, які займаються виключно питаннями зберігання даних.

Паралельно почали працювати над відмовостійкої конфігурацією. Спочатку передбачалося, що відмовостійкий кластер буде на базі відкритого ПЗ. Зіткнулися з тим, що якість коду та його універсальність були недостатніми для вирішення конкретних практичних завдань. У цей час стали з'являтися нові проблеми: наприклад, при падінні інтерфейсу традиційно на контролері проходили перевибори і перемикання майстра. Це в сукупності займало астрономічний час — до хвилини-двох. Потрібна нова система хостів: почали присвоювати кожному очки сесії (чим більше відкритих сесій — тим більше очок), а нові хости робили discover. У третьому поколінні виявилося, що навіть при синхронній реплікації із-за особливостей реалізації і заліза, сесія на одному контролері могла з'явитися раніше, ніж на іншому — і виникав небажаний хендовер з перемиканням. Знадобилося четверте покоління — свій власний кластер-менеджер саме на роботу СГД, в якому відмови хост-інтерфейсів і бекэнд інтерфейсів оброблялося правильно, з урахуванням усіх особливостей апаратного забезпечення. Знадобилося дуже істотно доробити на низькому рівні, але результат вартий того — зараз пара секунд на перемикання максимум, плюс Active-Active став куди більш правильним. Додалося автоконфігурірованія кошиків з дисками.

Зрештою зробили дуже хорошу оптимізація SATA з переходом на RAID 7.3 — підтримка відновлення даних без втрати продуктивності.

Реалізація

Використовується рішення це вендорами СГД, а також власниками великих сховищ із США, Китаю і Кореї. Друга категорія — непотоковые завдання інтеграторів, найчастіше медіа, суперкомп'ютери, охорона здоров'я. Під час Олімпійських ігор кінцевим споживачем була студія спортивного мовлення «Панорама», вони як раз робили картинку з олімпіади. Є користувачі RAIDIX в Німеччині, Індії, Єгипті, Росії, США.

Вийшло ось що:


На одному контролері: звичайне x86 залізо + ОС = швидке і дуже, дуже дешеве сховище.


Два контролера: виходить система з резервуванням (але дорожче).

Важлива фішка — часткове відновлення томи. Є по три контрольні суми на кожен страйп:



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

Друга річ — реалізований механізм попереджуючої реконструкції, виключає з процесу до двох (RAID 6) або до трьох (RAID 7.3) дисків, швидкість читання з яких нижче, ніж в інших. Коли швидше відновити, ніж прочитати — природно, використовується перший варіант.

Працює це так: K стрипів виходить K-N, необхідне для складання ділянки даних. Якщо дані цілі, читання інших стрипів зупиняється.

Це означає, що в RAID 7.3 маючи 24 диска при 3 відмовах — 12 Гб/с на ядро (4 ядра) — швидкість відновлення перевищує швидкість читання бекапа і навіть звернення до RAM — незважаючи на випадання диска, читання зберігається.

Наступна проблема низького рівня — спроба виконати читання битого ділянки. Навіть на ентерпрайз-системах затримка може скласти 8 секунд — напевно ви бачили такі «підвисання» HDD-СГД. З урахуванням цього алгоритму неотдача даних з трьох дисків з 24 означає просто уповільнення читання на кілька мілісекунд.

Більш того, система запам'ятовує диски з найбільшим часом відгуку і перестає надсилати запити протягом однієї секунди. Це дозволяє знизити навантаження на ресурси системи. Дискам з найбільшим часом відгуку присвоюється статус «повільний» і робиться повідомлення про те, що варто їх замінити.


Скріншоти інтерфейсу

Враховуючи переваги ОС RAIDIX, багато замовники вирішили мігрувати на неї. Тут позначився брак розміру компанії — складно петербурзькому розробнику врахувати всі особливості віддзеркалення СУБД і інших специфічних даних. В останній версії були зроблені великі зрушення в бік плавної міграції, але все одно гладко і рівно як у хайенд-СГД з дзеркальним підключенням Active-Active не вийде, швидше за все буде потрібно відключення.

Деталі

У Росії особисто я бачу можливість отримувати за мінімальні гроші цілком цікаві варіанти СГД. Ми будемо збирати на нормальному стабільному залозі рішення, які будуть ставитися готовими до замовників. Головна перевага, звичайно, рубль Гб/с. Дуже дешево.

Наприклад, ось конфігурація:
  • Сервер HP DL 380p gen8 (Intel Xeon E5-2660v2, 24 Гб пам'яті + контролери LSI SAS HBA 9207-8i).
  • На 2 диска розливаємо ОС RAIDIX 4.2, решта 10 — 2Тб SATA.
  • Зовнішній інтерфейс — 10 Гбіт/с Ethernet.
  • 20 Тб простору, яке можна використовувати.
  • + Ліцензії на 1 рік (включає ТП та оновлення).
  • Ціна на продаж по прайсу: 30 000$.
Полку розширення, підключена за SAS 12 дисками по 2Тб по прайсу — 20 000$. В ціну входить установка ОС. Під дані на дисках з даними сягає 97% місця. LUN необмеженого розміру. Підтримуються Fibre Channel; InfiniBand (FDR, QDR, DDR); iSCSI. Є SMB, NFS, FTP, AFP, є Hot Spare, є ДБЖ, 64 диска в масиві RAID 0/ 6/ 10/ 7.3 (з потрійною парністю). 8 Гб/с на RAID 6. Є QoS. В результаті — оптимальне рішення для постпродашна, зокрема, кольорокорекції і монтажу, для ТБ-мовлення, складання даних з HD-камер. При колекції сайтів можна отримати 150 Гб/с без істотного зниження надійності і навіть під Lustre — це область highload.

Ось по посиланню спека і ще деталі (PDF).

Тести

1. Одноконтроллерная конфігурація. Сервер SuperMicro SSG-6027R-E1R12L 2 юніта. 12 дисків по 4 Тб Sata 3,5". Зовнішній інтерфейс 8Гбит/з FC. 48 Тб неразмеченного простору за 12 000$

2. Двухконтроллерная конфігурація. Сервер SuperServer 6027TR-DTRF, в ньому 2 плати (як блейды). Додаємо полку з 45 дисками по 4 Тб. Зовнішній інтерфейс 8Гбит/з FC. 180 Тб неразмеченного простору за 30 000$.

Конфігурація а — RAID 7.3 на 12 дисків. 36 Тб корисної ємності, 0,33$/Гб.
Конфігурація б — три RAID 7.3 по 15 дисків. 0,166$/Гб











FC 8G Performance
Sequential Read/Write
Operation type
Block Size
4.2.0-166, RAID6, Single (ATTO8×2)
IOps
MBps
Avg Response Time
read
4K
80360,8
329,1
55,8
128K
11946,7
1565,8
54,3
1M
1553,5
1628,9
98,3
write
4K
18910,8
77,4
44,8
128K
9552,2
1252,0
54,9
1M
1555,7
1631,2
100,4
Тут — інші результати.

У цілому

Я дуже радий, що у нас «під боком» раптово знайшовся такий виробник, вирішальний дуже специфічні завдання. Своїх комплектуючих компанія не випускає і інших бізнес-сервісів у них немає, системною інтеграцією займатися теж не планують — так ми і домовилися до співпраці. У підсумку мій відділ тепер займається, зокрема, рішеннями на базі ОС RAIDIX. Перші впровадження у Росії, звісно, підуть суворо разом з виробниками.

Ми обкатали на демо-стенді деякі конфігурації, і, в цілому, задоволені, хоч і знайшли кілька підводних каменів (що нормально для нових версій). Якщо цікаві деталі щодо впровадження — пишіть на atishchenko@croc.ru розповім детальніше, варто чи ні.

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

0 коментарів

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