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

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

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

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

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

Според searchvmware.techtarget.com/definition/VMware-DRS
„VMware DRS (Distributed Resource Scheduler) е помощна програма, която балансира изчислителните натоварвания с наличните ресурси във виртуална среда. Помощната програма е част от пакет за виртуализация, наречен VMware Infrastructure.

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

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

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

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

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

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

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

Гарантирано изпълнение

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

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

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

Сравнително прости услуги

Отговорността за данните е на клиента

Не се изисква приоритизиране на VM

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

Възможно е да има проблеми

Без SLA, качеството не е гарантирано

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

Не е необходимо архивиране

Характеристики на клиента
Много широка гама от приложения.

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

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

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

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

Инструменти за архивиране в движение.

Предвидимо циклично натоварване на клиентите.
Типични приложения – балансиране на мрежи, Apache, WEB, VPN, SQL

Приложението може да спре за известно време

Позволява произволно разпределение на виртуални машини в облака

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

Предвидимо средно статистическо натоварване с голям брой клиенти.

Последици за архитектурата
Геоклъстеризация

Централизирано или разпределено съхранение

Запазен IBS
Локално съхранение на данни в изчислителни възли

Балансиране на целите
Равномерно разпределение на натоварването

Максимална отзивчивост на приложението

Минимално време на забавяне за балансиране

Балансиране само когато е абсолютно необходимо

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

Деактивиране на някои ресурси в случай на ниско натоварване

Спестяване на енергия

Намаляване на разходите за персонал

За себе си правим следните изводи:

За частни облаципредоставено на големи корпоративни клиенти, DRS може да се използва при следните ограничения:

информационна сигурност и отчитане на правилата за афинитет при балансиране;
наличие на достатъчно ресурси в резерв в случай на авария;
данните от виртуалната машина се намират в централизирана или разпределена система за съхранение;
зашеметяващи процедури за администриране, архивиране и балансиране във времето;
балансиране само в рамките на съвкупност от клиентски хостове;
балансиране само когато има силен дисбаланс, най-ефективните и безопасни VM миграции (в края на краищата миграцията може да се провали);
балансиране на относително „тихи“ виртуални машини (миграцията на „шумни“ виртуални машини може да отнеме много дълго време);
балансиране, като се вземе предвид „цената“ - натоварването на системата за съхранение и мрежата (с персонализирани архитектури за големи клиенти);
балансиране, като се вземат предвид индивидуалните поведенчески характеристики на всяка VM;
За предпочитане е балансирането да се извършва в извънработно време (нощ, почивни дни, празници).

За обществени облаципредоставяйки услуги на малки клиенти, DRS може да се използва много по-често, с разширени възможности:

липса на ограничения за информационна сигурност и правила за афинитет;
балансиране в облака;
балансиране по всяко разумно време;
балансиране на всяка VM;
балансиране на „шумни“ виртуални машини (за да не пречат на другите);
данните за виртуалната машина често се намират на локални дискове;
като се вземе предвид средната производителност на системите за съхранение и мрежите (облачната архитектура е унифицирана);
балансиране според общите правила и наличната статистика на поведението на центъра за данни.

Сложност на проблема

Трудността при балансиране е, че DRS трябва да работи с голям брой несигурни фактори:

поведение на потребителите на всяка от информационните системи на клиента;
алгоритми за работа на сървъри на информационни системи;
поведение на СУБД сървъри;
натоварване на изчислителни ресурси, системи за съхранение, мрежа;
взаимодействие на сървърите един с друг в борбата за облачни ресурси.

Натоварването на голям брой сървъри за виртуални приложения и бази данни върху облачни ресурси възниква с течение на времето, последствията могат да се проявят и да се припокриват с непредсказуем ефект за непредсказуемо време. Дори за управление на относително прости процеси (например за управление на двигател, система за отопление на вода у дома), системите за автоматично управление трябва да използват сложни пропорционално-интегрално-диференциращо алгоритми с обратна връзка.

Нашата задача е с много порядъци по-сложна и съществува риск системата да не може да балансира натоварването до установените стойности за разумно време, дори и да няма външни влияния от потребителите.

История на нашите разработки

За да разрешим този проблем, решихме да не започваме от нулата, а да надградим съществуващия опит и започнахме да взаимодействаме със специалисти с опит в тази област. За щастие нашето разбиране за проблема напълно съвпадна.

Етап 1

Използвахме система, базирана на технологията на невронни мрежи и се опитахме да оптимизираме ресурсите си въз основа на нея.

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

Пуснахме системата и наистина започнахме да балансираме. Мащабът на нашия облак не ни позволи да получим оптимистичните резултати, заявени от разработчиците, но беше ясно, че балансирането работи.

В същото време имахме доста сериозни ограничения:

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

Етап 2

Тъй като не бяхме доволни от състоянието на нещата, решихме да променим системата и за да направим това, отговорете основен въпрос – за кого го правим?

Първо – за корпоративни клиенти. Това означава, че имаме нужда от система, която работи бързо, с тези корпоративни ограничения, които само опростяват внедряването.

Втори въпрос – какво имате предвид под думата „незабавно”? В резултат на кратък дебат решихме, че можем да започнем с време за реакция от 5–10 минути, така че краткотрайните пренапрежения да не вкарат системата в резонанс.

Трети въпрос – какъв размер от балансирания брой сървъри да избера?
Този проблем се разреши от само себе си. Обикновено клиентите не правят агрегатите на сървъри много големи и това е в съответствие с препоръките на статията за ограничаване на агрегатите до 30-40 сървъра.

В допълнение, чрез сегментиране на сървърния пул, ние опростяваме задачата на алгоритъма за балансиране.

Четвърти въпрос – доколко една невронна мрежа е подходяща за нас с нейния дълъг процес на обучение и рядко балансиране? Решихме да го изоставим в полза на по-прости оперативни алгоритми, за да получим резултати за секунди.

Може да се намери описание на система, която използва такива алгоритми и нейните недостатъци тук

Внедрихме и пуснахме тази система и получихме обнадеждаващи резултати - сега тя редовно анализира облачното натоварване и дава препоръки за преместване на виртуални машини, които до голяма степен са правилни. Още сега е ясно, че можем да постигнем 10-15% освобождаване на ресурси за нови виртуални машини, като същевременно подобряваме качеството на работа на съществуващите.

Когато се открие дисбаланс в RAM или CPU, системата издава команди към Tionix Scheduler за извършване на миграция на живо на необходимите виртуални машини. Както се вижда от системата за мониторинг, виртуалната машина се мести от един (горен) на друг (долен) хост и освобождава памет на горния хост (маркиран в жълти кръгове), съответно я заема на долния (маркиран в бяло) кръгове).

Сега се опитваме да оценим по-точно ефективността на текущия алгоритъм и се опитваме да намерим възможни грешки в него.

Етап 3

Изглежда, че човек може да се успокои по този въпрос, да изчака доказана ефективност и да затвори темата.
Но ние сме подтикнати да извършим нов етап от следните очевидни възможности за оптимизация

Статистиката напр. тук и тук показва, че дву- и четирипроцесорните системи имат значително по-ниска производителност от еднопроцесорните системи. Това означава, че всички потребители получават значително по-малко изход от CPU, RAM, SSD, LAN, FC, закупени в многопроцесорни системи, в сравнение с еднопроцесорни системи.
Самите планировчици на ресурси може да имат сериозни грешки, ето една от статиите по този въпрос.
Технологиите, предлагани от Intel и AMD за наблюдение на RAM и кеша, позволяват да се изследва поведението на виртуалните машини и да се поставят по такъв начин, че „шумните“ съседи да не пречат на „тихите“ виртуални машини.
Разширяване на набора от параметри (мрежа, система за съхранение, приоритет на виртуалната машина, цена на миграция, нейната готовност за миграция).

Общо

Резултатът от нашата работа за подобряване на алгоритмите за балансиране беше ясното заключение, че с помощта на съвременни алгоритми е възможно да се постигне значителна оптимизация на ресурсите на центъра за данни (25-30%) и в същото време да се подобри качеството на обслужване на клиентите.

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

Ще ви разкажем повече за възможностите на процесорите, планировчиците и балансирането на високо ниво в следващите статии.

Източник: www.habr.com

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