🥇Балансиране на натоварването в Openstack (Част 2)

В в предишната статия Разказахме за опитите да използваме Watcher и представихме отчет за тестовете. Подобни тестове периодично провеждаме за балансировка и други критични функции на мащабно корпоративно или операторско облако.

Високата сложност на решаваната задача може да изисква няколко статии за описание на нашия проект. Днес публикуваме втората статия от цикъла, посветена на балансировката на виртуални машини в облака.

Няколко термина

Компанията VmWare е въвела утилита DRS (Distributed Resource Scheduler) за балансировка на натоварването в разработената и предлагана от тях среда за виртуализация.

Както пише searchvmware.techtarget.com/definition/VMware-DRS
«VMware DRS (Планировчик на разпределени ресурси) е утилита, която балансира изчислителните натоварвания с наличните ресурси в виртуалната среда. Утилитата е част от пакета за виртуализация, наречен VMware Infrastructure.

С помощта на VMware DRS потребителите определят правила за разпределение на физическите ресурси между виртуални машини (ВМ). Утилитата може да бъде настроена за ръчно или автоматично управление. Ресурсни пулове на VMware могат лесно да бъдат добавяни, премахвани или реорганизирани. При желание ресурсните пулове могат да бъдат изолирани между различни бизнес единици. Ако натоварването на една или няколко виртуални машини рязко се променя, VMware DRS прехвърля виртуалните машини между физическите сървъри. Ако общото натоварване намалява, някои физически сървъри могат временно да бъдат изключени, а натоварването консолидарано.»

Защо е необходима балансировката?

Според нас, DRS е задължителна функция на облака, макар това да не означава, че DRS трябва да се използва винаги и навсякъде. В зависимост от предназначението и нуждите на облака могат да съществуват различни изисквания към DRS и методите за балансировка. Може да има ситуации, в които балансировката не е нужна изобщо. Или дори да е вредна.

За да стане по-ясно къде и за какви клиенти е необходим DRS, нека разгледаме техните цели и задачи. Облата могат да бъдат разделени на публични и частни. Ето основните разлики между тези облаци и целите на клиентите.

Частни облака / Големи корпоративни клиенти
Публични облака / Малък и среден бизнес, хора

Основен критерий и цели на оператора
Предоставяне на надежден сервис или продукт
Намаляване на разходите за услугите в конкурентния пазар

Изисквания към услугата
Надеждност на всички нива и във всички елементи на системата

Гарантирана производителност

Приоритизация на виртуалните машини в няколко категории

Информационна и физическа сигурност на данните

SLA и 24/7 поддръжка
Максимална простота при получаване на услугата

Относително прости услуги

Отговорността за данните лежи върху клиента

Приоритизация на ВМ не е необходима

Информационна сигурност на ниво типични услуги, отговорността е на клиента

Могат да настъпят сривове

Няма SLA, качеството не е гарантирано

Поддръжка по имейл

Резервното копиране не е задължително

Особености на клиента
Многоширок спектър от приложения.

Наследени приложения, наследени в компанията.

Сложни персонализирани архитектури за всеки клиент.

Правила на аффинитет.

Работа на софтуера без прекъсване в режим 7x24.

Средства за резервно копиране "в движение".

Предсказуема циклична натовареност на клиента.
Типични приложения – балансировка на мрежата, 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