В ми розповіли про спроби використовувати Watcher та подали звіт випробувань. Такі випробування ми періодично проводимо для балансування та інших критичних функцій великої корпоративної або операторської хмари.
Висока складність розв'язуваної задачі, можливо, вимагатиме кількох статей для опису нашого проекту. Сьогодні ми публікуємо другу статтю циклу, присвячену балансуванню віртуальних машин у хмарі.
трохи термінології
Компанія VmWare ввела утиліту DRS (Distributed Resource Scheduler) для балансування навантаження розробленого та пропонованого ними середовища віртуалізації.
Як пише
«VMware DRS (Планувальник розподілених ресурсів) – це утиліта, яка балансує обчислювальні навантаження з доступними ресурсами у віртуальному середовищі. Утиліта є частиною пакету віртуалізації під назвою VMware Infrastructure.
За допомогою VMware DRS користувачі визначають правила розподілу фізичних ресурсів між віртуальними машинами. Утиліта може бути налаштована на ручне або автоматичне керування. Пули ресурсів VMware можуть бути легко додані, видалені чи реорганізовані. За бажанням пули ресурсів можуть бути ізольовані між різними бізнес-одиницями. Якщо робоче навантаження на одну або кілька віртуальних машин різко змінюється, VMware DRS перерозподіляє віртуальні машини між фізичними серверами. Якщо загальне робоче навантаження зменшується, деякі фізичні сервери можуть бути тимчасово відключені, а робоче навантаження консолідоване.»
Навіщо потрібне балансування?
На нашу думку, DRS є обов'язковою функцією хмари, хоча це не означає, що DRS потрібно використовувати завжди та скрізь. Залежно від призначення та потреб хмари можуть існувати різні вимоги до DRS та методів балансування. Можливо, існують ситуації, коли балансування не потрібне зовсім. Або навіть шкідлива.
Щоб було краще зрозуміло, де і для яких клієнтів DRS потрібна, розглянемо цілі та завдання. Хмари можна поділити на публічні та приватні. Ось основні відмінності цих хмар та цілей клієнтів.
Приватні хмари / Великі корпоративні клієнти
Публічні хмари / Середній та малий бізнес, люди
Основний критерій та цілі оператора
Надання надійного сервісу чи продукту
Зниження собівартості сервісів у боротьбі конкурентному ринку
Вимоги до послуги
Надійність на всіх рівнях та у всіх елементах системи
гарантована продуктивність
Пріоритезація віртуальних машин на кілька категорій
Інформаційна та фізична безпека даних
SLA та цілодобова підтримка
Максимальна простота отримання послуги
Відносно прості послуги
Відповідальність за дані лежать на клієнті
Пріоритезація ВМ не потрібна
Інформаційна безпека лише на рівні типових сервісів, відповідальність клієнта
Можуть бути збої
Ні SLA, якість не гарантується
Підтримка поштою
Резервне копіювання не обов'язково
Особливості клієнта
Дуже широкий спектр програм.
Legacy програми, успадковані в компанії.
Складні кастомізовані архітектури кожного клієнта.
Афініті правила.
Робота ПЗ без зупинки в режимі 7х24.
Кошти резервного копіювання «на льоту».
Передбачуване циклічне навантаження клієнта.
Типові програми - балансування мережі, Apache, WEB, VPN, SQL
Можливе зупинення програми на деякий час
Допускається довільний розподіл ВМ у хмарі
Резервне копіювання силами клієнта
Передбачуване за великої кількості клієнтів статистично усереднене навантаження.
Наслідки для архітектури
Геокластеризація
Централізована чи розподілена СГД
Резервована СРК
Локальне зберігання даних на обчислювальних вузлах
Цілі балансування
Рівномірний розподіл навантаження
Максимальна чуйність додатків
Мінімальний час затримки на балансування
Балансування лише у разі явної необхідності
Виведення частини обладнання на профілактичне обслуговування
Зниження собівартості послуги та витрат оператора
Вимкнення частини ресурсів у разі низького навантаження
Економія електроенергії
Зменшення витрат за персонал
Ми для себе робимо такі висновки:
Для приватних хмар, що надаються великим корпоративним замовникам, DRS може застосовуватися з урахуванням обмежень:
- інформаційна безпека та облік афініті-правил при балансуванні;
- наявність у резерві достатнього обсягу ресурсів у разі аварії;
- дані віртуальних машин знаходяться на централізованій або розподіленій СГД;
- рознесення у часі процедур адміністрування, резервного копіювання та балансування;
- балансування лише у межах агрегату хостів клієнта;
- балансування тільки при сильному дисбалансі, найдієвіші та найбезпечніші міграції ВМ (адже міграція може закінчитися невдало);
- балансування щодо "спокійних" віртуальних машин (міграція "шумних" віртуальних машин може йти дуже довго);
- балансування з урахуванням «вартості» - навантаження на СГД та мережу (при кастомізованих архітектурах для великих клієнтів);
- балансування з урахуванням індивідуальних особливостей поведінки кожної ВМ;
- балансування бажано у неробочий час (ніч, вихідні, свята).
Для публічних хмар, що надають послуги невеликим замовникам, DRS може застосовуватися набагато частіше, з розширеними можливостями:
- відсутність обмежень інформаційної безпеки та афініті-правил;
- балансування у межах хмари;
- балансування у будь-який розумний час;
- балансування будь-якого ВМ;
- балансування «шумних» віртуальних машин (щоб не заважати іншим);
- дані віртуальних машин часто перебувають у локальних дисках;
- облік усередненої продуктивності СГД та мережі (архітектура хмари єдина);
- балансування за узагальненими правилами та наявною статистикою поведінки ЦОД.
Складність проблеми
Складність балансування полягає в тому, що DRS має працювати з великою кількістю невизначених факторів:
- поведінка користувачів кожної з інформаційних систем клієнтів;
- алгоритми роботи серверів інформаційних систем;
- поведінка серверів СУБД;
- навантаження на обчислювальні ресурси, СГД, мережу;
- взаємодія серверів між собою у боротьбі за ресурси хмари.
Навантаження великої кількості віртуальних серверів додатків та баз даних на ресурси хмари відбувається у часі, наслідки можуть виявлятися і накладатися один на одного з непередбачуваним ефектом через непередбачуваний час. Навіть для керування щодо простими процесами (наприклад, для керування двигуном, системою водяного опалення будинку) системам автоматичного регулювання необхідно використовувати складні алгоритми із зворотним зв'язком.
Наше завдання на багато порядків складніше, і існує ризик, що система за розумний час не зможе провести балансування навантаження до усталених значень, навіть якщо не виникатиме зовнішні впливи з боку користувачів.
Історія наших розробок
Для вирішення цієї проблеми ми вирішили не починати з нуля, а відштовхуватися від існуючого досвіду, і стали взаємодіяти з досвідченими фахівцями. На щастя, розуміння проблематики в нас повністю збігалося.
етап 1
Ми використовували систему, що базується на технології нейронних мереж, та спробували на її основі оптимізувати наші ресурси.
Інтерес даного етапу полягав у апробуванні нової технології, яке важливість – у застосуванні нестандартного підходи до вирішення завдання, де за інших рівних умов стандартні підходи практично вичерпали себе.
Ми запустили систему, і в нас дійсно пішло балансування. Масштаб нашої хмари не дозволив нам отримати оптимістичні результати, заявлені розробниками, але було видно, що балансування працює.
При цьому ми мали досить серйозні обмеження:
- Для навчання нейронної мережі потрібно, щоб віртуальні машини працювали без істотних змін протягом тижнів або місяців.
- Алгоритм розрахований на оптимізацію на основі аналізу більш ранніх «історичних» даних.
- Для навчання нейронної мережі потрібно досить великий обсяг даних та обчислювальних ресурсів.
- Оптимізацію та балансування можна робити відносно рідко – раз на кілька годин, що явно замало.
етап 2
Оскільки нас не влаштовував стан справ, ми вирішили модифікувати систему, і для цього відповісти на головне питання - Для кого ми її робимо?
Спершу – для корпоративних клієнтів. Отже, нам потрібна система, що працює оперативно, з тими корпоративними обмеженнями, які спрощують реалізацію.
Друге питання - Що розуміти під словом "оперативно"? Внаслідок недовгих дебатів ми вирішили, що можна відштовхуватися від часу реагування 5 – 10 хвилин, щоб короткочасні стрибки не вводили систему в резонанс.
Третє питання - Який розмір балансованої кількості серверів вибирати?
Це питання вирішилося саме собою. Як правило, клієнти не роблять агрегати серверів дуже великими, і це відповідає рекомендаціям статті обмежити агрегати 30-40 серверами.
Крім того, сегментуючи пул серверів, ми спрощуємо завдання алгоритму балансування.
Четверте питання – наскільки нам підходить нейронна мережа з її довгим процесом навчання та рідкісними балансуваннями? Ми вирішили відмовитись від неї на користь більш простих оперативних алгоритмів, щоб отримувати результат за секунди.
З описом системи, яка використовує такі алгоритми та її недоліки, можна ознайомитися
Ми реалізували і запустили цю систему та отримали обнадійливі результати – зараз вона регулярно аналізує навантаження хмари та дає рекомендації щодо переміщення віртуальних машин, які значною мірою є правильними. Навіть зараз видно, що ми можемо досягти 10-15% звільнення ресурсів під нові віртуальні машини з покращенням якості роботи наявних.
При виявленні дисбалансу по RAM чи CPU система дає команди планувальник Тіонікс виконання живої міграції необхідних віртуальних машин. Як видно із системи моніторингу, віртуальна машина переїхала з одного (верхнього) на інший (нижній) хост і звільнила пам'ять на верхньому хості (виділено у жовті кола), зайнявши її відповідно на нижньому (виділено у білі кола).
Зараз ми намагаємося більш точно оцінити ефективність алгоритму, що діє, і намагаємося знайти в ньому можливі помилки.
етап 3
Здавалося б, на цьому можна заспокоїтись, дочекатися доведеної ефективності та закрити тему.
Але нас підштовхують до проведення нового етапу такі явні можливості оптимізації.
- Статистика, наприклад, и показує, що дво- і чотирьох-процесорні системи за своєю продуктивністю суттєво нижчі за однопроцесорні. Отже, всі користувачі отримують від куплених у багатопроцесорних системах CPU, RAM, SSD, LAN, FC значно меншу віддачу порівняно з однопроцесорними.
- Самі планувальники ресурсів можуть працювати із серйозними помилками, на цю тему.
- Пропоновані компаніями Intel та AMD технології для моніторингу RAM та кешу дозволяють вивчати поведінку віртуальних машин та розміщувати їх таким чином, щоб «шумні» сусіди не заважали жити «спокійним» віртуальним машинам.
- Розширення набору параметрів (мережа, СГД, пріоритет віртуальної машини, вартість міграції, її готовність до міграції).
Разом
Результатом нашої роботи з удосконалення алгоритмів балансування став однозначний висновок про те, що за рахунок сучасних алгоритмів можна досягти суттєвої оптимізації ресурсів (25-30%) датацентрів та підвищити при цьому якість обслуговування клієнтів.
Алгоритм, що базується на основі нейронних мереж, є, безумовно, цікавим, але таким, що потребує подальшого розвитку, і з огляду на існуючі обмеження не придатним для вирішення такого роду завдань на обсягах, характерних для приватних хмар. При цьому в публічних хмарах значного розміру алгоритм показав добрі результати.
Докладніше про можливості процесорів, планувальників та високорівневе балансування ми розповімо в наступних статтях.
Джерело: habr.com