🥇Натоварване в 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, качеството не е гарантирано

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

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

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

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

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

Аффинити правила.

Работата на софтуера без прекъсвания в режим 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 и кеша позволяват да се проучва поведението на виртуалните машини и да се подреждат по такъв начин, че "шумните" съседи да не пречат на "тихите" виртуални машини.
Разширяване на набора от параметри (мрежа, SCSI, приоритет на виртуалната машина, разходи за миграция, готовност за миграция).

Итого

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

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

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

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