Як ми відмовостійкий кластер запускали



Помилки і труднощі, з якими ми зіткнулися, запускаючи власний кластер на базі VMmanager Cloud + Ceph.

Передісторія
До нас в FirstVDS приходять різні люди. Комусь достатньо хостингу на базі CMS, комусь віртуального сервера. Але іноді людина просить продуктивний сервер з підвищеною надійністю, при цьому його не дуже хвилює вартість послуги.

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

Склалося враження, що розподілені системи поступаються в швидкості класичним рішенням. Ми знали про технології InfiniBand, але не були готові тестувати на собі — обладнання-то дороге. Сам комутатор коштує близько 5000$, мережева карта 780$, і ще кабель 100$. Отже, підключення до одного сервера в мережу IB обходиться в 1300$. Задумка отримала продовження завдяки вдалому збігу обставин.

У травні 2014 року наш директор Олексій Чекушкін в черговий раз відправився на конференцію Хостобзор. Це така закрита тусовка, де зустрічаються представники хостингів і діляться досвідом. На конференції Олексій прослухав доповідь про досвід використання InfiniBand, а потім поговорив з доповідачем особисто. Виявилося, що IB відмінно справляється зі своїми завданнями — мережа дійсно працює на швидкості 56 Гбіт/с, а мережеві затримки такі низькі, що непомітні на тлі дискових затримок. Тобто не важливо — чи встановлений диск локально, або комп'ютер звертається до нього по мережі. Саме це і було потрібно для створення розподіленого кластера.

У серпні 2014 купили необхідне обладнання і приступили до збирання.

Перша версія кластера
Хостинг FirstVDS вже 13 років співпрацює з компанією ISPsystem. Використовуємо BILLmanager як білінгової платформи, на клієнтські сервери встановлюємо ISPmanager як панель управління, для управління віртуальними машинами використовуємо VMmanager. За роки співпраці з ISPsystem накопичили великий досвід роботи з продуктами, і жодного разу не засумнівалися в професіоналізмі розробників. Тому вирішили використовувати VMmanager Cloud для побудови кластера. Тим більше, що в специфікаціях заявлена підтримка Ceph — саме його ми хотіли використовувати для зберігання даних.

Стек технологій для побудови кластера високої доступності вийшов таким:
  • VMmanager Cloud — запуск віртуальних машин «в хмарі»
  • Ceph — розподілене мережеве сховище даних
  • InfiniBand — мережа, зв'язок між машинами кластера
VMmanager Cloud фактично підтримував Ceph, але ми були першими, хто спробував у справі. По мірі реалізації проекту виникли ідеї щодо поліпшення продукту — ISPsystem йшли назустріч і допрацьовували VMmanager Cloud «на льоту».

Спеціально для кластера купили:
  • Машини Xeon 2630. Такі машини використовуються для нашого звичайного хостингу віртуальних серверів.
  • Комутатор InfiniBand SX6005 — модель на 12 портів, ми розрахували, що такий буде досить
  • Карти для підключення комп'ютерів до мережі HCA Mellanox InfiniBand
  • Кабелі DAC — для з'єднання складових в мережу
Хостинг високої доступності складається з двох кластерів — кластера зберігання та обчислювального.

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

Кластер зберігання працює під управлінням Ceph і відповідає за зберігання інформації. Кількість реплік одного блоку даних (default size pool) встановили рівне 3 — всі дані зберігаються в трьох копіях. Якщо відключається диск або ціла нода і одна з копій втрачається, Ceph створює робочу копію файлів з двох, що залишилися. Крім цього, у таких випадках система створює відсутні копії файлів на наявному дисковому просторі — цей процес також називається перебалансіровка.

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

Перша версія складалася з 5 серверів, об'єднаних в мережу за допомогою IB. Ceph не підтримував протокол IB на той момент, тому використовували IPoIB. Ceph — многосоставное. Ми використовуємо дві частини: монітор кластера (ceph-mon), і демон сховища (ceph-osd).

Для зберігання на кожен сервер встановлювали 2 диска за 2 Тб і один SSD на 400 Гб для кешування. Така концепція — кешування читання-запису на швидких носіях — підтримується Ceph. Ми вирішили нею скористатися, щоб не підвищувати ціну для кінцевого користувача через SSD-накопичувачів.

У першій версії обидві задачі — обчислення та зберігання — були запущені на одних і тих же ноди.



Спочатку запустили на кластері синтетичні тести: створили VDS-болванки, дивилися, як система буде працювати під навантаженням. Для перевірки зв'язності кластера відключали диски і окремі ноди — дивилися, як кластер буде перерозподіляти навантаження і записані дані.

Після тестів стали запускати на кластері клієнтські VDS. Так ми побачили, як кластер веде себе в «бойовому» режимі.

Система працювала, але продуктивність була нижче очікуваної. Швидкість передачі даних по IB всього 20 Гбіт/сек замість заявлених 56 Гбіт/сек. Грішили на InfiniBand, але пізніше з'ясували, що справа була в іншому. Повільно працювала вся система: дані з віртуальних серверів не встигали записуватися і вставали в чергу. Одні процеси чекали, поки інші процеси дочекаються запису на диск, щоб звільнити процесор. Все це навалювалося як сніжний ком, збільшуючи витрати на виконання обслуговуючих операцій.

Кластер справлявся з завданнями — при виході з ладу дисків або нод, він продовжував функціонувати. Однак, кожна перебалансування перетворювала ситуацію в критичну. При додаванні нового диска згладжували пік навантаження, використовуючи ваги. Вага відповідає за ступінь використання конкретного фізичного носія. Встановлюємо новий диск, ставимо вага 0 — диск не використовується. Після цього збільшуємо вагу поступово, і перебалансування відбувається маленькими порціями. Якщо ж диск виходить з ладу, то ваги не спрацьовують: ~1 Тб реплік треба «розмазати» по залишилися дисків відразу, і Ceph надовго йде в режим запису даних, завантажуючи диски «порожній» роботою.

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

Експериментували з конфігурацією: додавали ноди, диски, оперативну пам'ять. Кожну конфігурацію перевіряли спочатку на синтетичних тестах, потім відкривали справжні виртуалки нових клієнтів. При збільшенні кількості VDS кластер починав працювати нестабільно, і ми переносили клієнтські машини на звичайні ноди. Оскільки такі переноси були плановими і проходили в штатному режимі, то вони не приносили жодних незручностей клієнтам.

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

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

У першій версії одні і ті ж ноди відповідали і за зберігання даних, і за роботу віртуальних машин. Поломка одного фізичного сервера занадто сильно навантажувала систему, так як одночасно запускалася і перебалансування за нодам віртуальних машин, і створення відсутніх реплік даних. Для розподілу навантаження застосували класичну архітектуру:



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

Щоб випробувати нову архітектуру і позбавитися від колишніх недоліків, зібрали тестовий стенд. І тут з'ясувалося цікаве — спеціально куплені для складання першої версії сервери виявилися «паленими». Системна шина всіх серверів працювала повільно. В результаті, всі пристрої, пов'язані з північним і південним мостами — карти IB, підключені PCI-E, диски, пам'ять — також працювали повільно. Це пояснювало більшу частину проблем, з якими ми зіткнулися. В якості проби взяли кілька вільних нод, на яких зазвичай запускаємо клієнтські VDS. По тех. характеристиками вони майже нічим не відрізнялися. Зібрали і запустили кластер на цих машинах, стали проганяти тести. Все літає! І навіть мережу IB видає заявлені 56 Гбіт/сек.

Перед запуском у роботу ми реорганізували запам'ятовуючий пристрій: купили нові сервери на базі Xeon 2630 з великою кількістю дискових кошиків — на виріст. Обзавелися зовнішнім контролером жорстких дисків для більш ефективної роботи дискової підсистеми. У підсумку, на кожній машині кластера зберігання працювали 6 дисків: 4 HDD по 4-8 Тб + 2 SSD по 500 Гб.

У підсумку вся збірка складалася з 12 машин: 3 в кластері сховища і 9 в обчислювальному кластері. Після обкатки тестового стенду у вересні 2015 запустили кластер як окрему послугу — відмовостійкий віртуальний сервер.

Близько 5-ти місяців система чудово працювала, радуючи нас і клієнтів. Так було, поки кількість клієнтів не досяг критичного значення. Місткі диски по 4-8 Тб все-таки вилізли нам боком. При заповненні диска вже наполовину, він перетворювався в пляшкове горлечко — велика кількість файлів, що належать різним VDS, розташовувалися на одному фізичному носії, і йому доводилося обслуговувати велику кількість клієнтів. При виході його з ладу перебалансування теж проходила важко — треба перерозподілити великий обсяг інформації. SSD-кеш в таких умовах погано справлявся зі своїми обов'язками. Рано чи пізно диск кешу переполнялся і давав сигнал — з цього моменту я нічого не кэширую, а тільки записую збережену інформацію на повільний HDD-диск. HDD-диск відчуває в цей час подвійне навантаження — обробляє прямі звернення, які надходять минаючи кеш, і записує збережені в кеші дані. Сховище добре працювало, поки справа не доходила до зміни конфігурації дискової. Випадання диска або додавання нового сильно сповільнювало загальну пропускну здатність сховища.

Третя версія кластера
Біда не приходить одна. 18 лютого 2016 ми зіткнулися з критичним багом Ceph: в процесі скидывания кешу на диск відбувалася некоректна запис блоку даних. Це призводило до відключення процесів ceph-osd всіх дисків, де зберігалися репліки злощасного блоку. Система відразу позбавлялася трьох дисків, а значить і всіх файлів, розміщених на них. Запускався процес перебалансування, але не міг завершитися до кінця — адже з системи пропадали всі три копії як мінімум одного блоку даних (і відповідного файлу), з якого почалася проблема. Консистентним сховища була під загрозою. Ми видаляли вручну помилкові блоки, перезапускали процеси ceph-osd, але це допомагало ненадовго. Помилковий запис повторювалася, балансування починалася знову, і сховище валилося.

Напружений пошук в інтернеті дав результат — закрита бага в останньому на той момент релізі Ceph Hammer. Наше сховище запущено на попередній версії — Firefly. На щастя, в Ceph діє система бэкпортов: фікси критичних багів додаються в попередні версії, щоб зберегти сумісність при міграції.

Попередила клієнтів про недоступність серверів і приступили до оновлення. Переключилися на інший репозиторій, який залитий фікс баги, виконали yum update, перезапустили процеси Ceph — не допомогло. Помилка повторюється. Локалізували джерело проблеми — запис з кеша в основне сховище — і відключили кешування повністю. Клієнтські сервери заробили, але кожна перебалансування перетворювалася в пекло. Диски не справлялися з обслуговуванням системної балансування та клієнтського читання-запису.

Вирішили проблему кардинально — відмовилися від SSD-кеша і поставили SSD-накопичувачі в якості основних. Тут допомогли ноди з великою кількістю дискових кошиків, завбачливо куплені для кластера зберігання. Замінювали поступово: спочатку додали по чотири SSD залишилися порожні кошики на кожному сервері, а після балансування даних, стали по одному замінювати старі HDD-диски на SSD. Робили за схемою: видалення диска, установка диска, балансування даних, видалення, установка, балансування і так далі по колу, поки в ноди не залишилися тільки SSD. Замінювали на гарячу, оскільки втрата одного накопичувача ніяк не позначається на працездатності кластера зберігання.

Використовували промислові накопичувачі Samsung 810 розміром 1 Тб. Не стали використовувати SSD більшого розміру, щоб не провокувати ситуацію «вузького горлечка», коли на одному фізичному носії розташовується багато даних, і, отже на нього припадає велика кількість звернень.

Таким чином, поступово ми замінили всі накопичувачі на SSD. І настало щастя — кластер став працювати як годинник. Пікові навантажень при виникненні проблем з залізом припинилися, перебалансування відбувається непомітно для клієнтів. Пізніше все-таки довелося ущільнити сховище і замінити диски на 2-терабайтні Samsung 863. Заміна ніяк не позначилася на роботі кластера зберігання.

У такій конфігурації наш відмовостійкий кластер працює і донині. А ім'я йому — Атлант: )

Технічні показники кластера
Порівняння віртуальної машини в кластері (ceph) з віртуальною машиною на звичайній ноде з SSD-накопичувачами (ssd).

Запис:
ceph: bw=393.181 KB/s, iops=3071
 
ssd: bw=70.371 KB/s, iops=549
 

Читання:
ceph: bw=242.129 KB/s, iops=1891
 
ssd: bw=94.626 KB/s, iops=739
 

Кілька днів роботи кластера в графіках:





Перспективи розвитку
Зараз IB-комутатор задублирован звичайним гігабітним Ethernet-комутатором. Це необхідно для того, щоб кластер не втратив зв'язність при виході основного комутатора з ладу. На підхваті варто резервний IB-комутатор, але перемикати на нього вузли кластера доведеться в разі неполадки вручну. Після збою система продовжить працювати з деградацією продуктивності на 5-10 хвилин. Це необхідно для фізичного перемикання на резервний IB-комутатор.

Плануємо повністю задублировать IB-комутатор, щоб при виходу з ладу основного другий миттєво взяв все навантаження на себе. Це не так просто, як здається, необхідно в кожний сервер встановити другу HCA-карту. Не на всіх ноди є додатковий PCI-E, тому деякі доведеться заміняти цілком. Можна поставити одну двухпортовую карту, але таке рішення не рятує від виходу з ладу самої карти.

Також плануємо розвивати кластер в ширину — ноди рано чи пізно заповняться, а для підключення нових нод портів майже не залишилося. Необхідно додати ще один IB-комутатор і з'єднувати з наявним послідовно.

Висновок
Ми використовували для створення кластера підвищеної надійності VMmanager Cloud і Ceph. Ось наші рекомендації, якщо ви вирішите використовувати ці ж технології:
  • Використовуйте LTS-випуски Ceph. Не розраховуйте, що будете накочувати нову версію з кожним релізом. Оновлення — потенційно небезпечна операція для сховища. Перехід на нову версію спричинить зміни в конфігах, і не факт, що сховище запрацює після оновлення. Відстежуйте багфікси — вони бэктрекаются з нових версій у старі.
  • Використовуйте швидкі SSD-накопичувачі в якості основних. Не потрібно використовувати диски великого об'єму. Краще поставити 2 диски по 1 Тб ніж 1 на 2 Тб. Підхід з кешуванням не виправдовує себе. Доведеться сильно заморочити як з налаштуваннями, так і з подальшою підтримкою.
  • Для сховища використовуйте ноди з великою кількістю дискових кошиків. Або будьте готові підключати додаткові ноди у міру розростання кластера.
Джерело: Хабрахабр

0 коментарів

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