В мы расказалі аб спробах выкарыстоўваць 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