Drs что это такое
Правильное понимание
Словарь терминов Формулы 1 — часть 1
Если вы смотрите Формулу 1 недавно, то ее телетрансляция может показаться большим набором непонятных терминов. «Апекс», «андеркат», «поворачиваемость» — этими и другими терминами легко оперируют комментаторы и эксперты. Предлагаем и вам детальнее разобраться с этими, на первый взгляд, сложными словами.
— DRS («ДРС») («открытое крыло») – регулируемое заднее антикрыло. Этот элемент болида появился в 2011 году, как попытка решить проблему небольшого количества обгонов на трассе. Фактически, это пластина на заднем антикрыле, которую пилоты могут открывать по ходу заезда. Благодаря этому снижается уровень прижимной силы и болид может развивать большую скорость на прямых. В гонке эту систему можно открывать только тем, кто собирается совершить обгон, и только на специально отведенном для этого участке трассы — в «зоне DRS».
— KERS – система рекуперации кинетической энергии, которая накапливает энергию на торможении и отдает ее на прямых.
— Автомобиль безопасности (пейс-кар) – специальный автомобиль, который выезжает на трассу в случаях необходимости. Обычно это происходит, когда движение в обычном режиме гонки может быть небезопасным для кого-то из участников Гран-при: если на трассе находятся обломки, разлито масло, необходимо эвакуировать разбитый болид или в сложных погодных условиях. Автомобиль безопасности возглавляет пелотон, и за ним гонщики вынуждены ехать гораздо медленнее, нежели в обычном режиме. Кроме того, при движении за пейс-каром запрещено обгонять соперников.
— Андеркат — осознанный ранний пит-стоп, благодаря которому получается пройти соперника (за счет стратегии или более свежих шин).
— Апекс – так называемая «вершина поворота» — это часть траектории, в которой болид находится максимально близко к внутренней кромке поворота. Именно с этой точки пилоты начинают свой разгон, поэтому если гонщик проходит апекс, то на выходе из поворота у него будет максимально возможная на данном участке скорость.
— Боксы — гаражи гоночных команд. Это специальные помещения, где проходят все подготовительные и ремонтные работы по ходу гоночного уик-энда.
— Большой шлем – особое достижение, когда один пилот в рамках одного этапа выиграл квалификацию, гонку, показал самый быстрый круг и лидировал от старта до финиша.
— Виртуальный автомобиль безопасности (VSC) – специальный режим на трассе, когда ситуация не достаточна для того, чтобы выпустить реальный автомобиль на трассу. Согласно правилам, в режиме VSC гонщики должны замедлиться приблизительно на 40% и проезжать круг за определенное время. Однако этот темп более быстрый, чем движение за реальным автомобилем безопасности. Обычно режим VSC вводят на пару кругов.
— Гранулирование шин – процесс, происходящий в том случае, когда внутренний каркас еще очень холодный, а внешняя поверхность покрышки уже слишком горячая. Тогда горячие части резины скатываются, в результате чего получаются небольшие «червячки» или гранулы. Приводит к уменьшению сцепления с трассой. Также гранулирование может возникнуть при недостаточной поворачиваемости. В этом случае болид буквально скользит по трассе, в результате чего на покрышках могут появиться гранулы.
— Грязный воздух – воздух за болидом, который создается завихрениями воздушных потоков от корпуса и антикрыльев. Он серьезно мешает следующему сзади автомобилю. Однако в регламенте-2019 попытались уменьшить эту проблему, изменив элементы аэродинамики.
— Закрытый парк – особое правило, по которому механики не имеют права изменять настройки на болиде или производить замену каких-то деталей в период между квалификацией и гонкой. Исключение делается только для тех автомобилей, которые пострадали во время аварии в квалификации, и для тех, на которых были обнаружены неисправные детали. Cогласно правилам закрытого парка, в период между квалификацией и гонкой сломанную деталь можно заменить только на абсолютно идентичную. Если же происходит замена на деталь другой спецификации, то пилот обязан стартовать с пит-лейн.
— Кокпит — открытая кабина гоночного автомобиля.
— Круговой — пилот, уступающий круг другому пилоту. Такому гонщику показывают синий флаг как знак, что он должен пропустить вперед более быстрый автомобиль, который догнал его на круг.
— Маршалы — сотрудники трассы, которые сигнализируют предупреждающими флагами, эвакуируют разбитые болиды, убирают обломки.
— Моторхоум – передвижной офис, который команды возят за собой в европейский период чемпионата. Они обустраиваются прямо на автодроме из трех-семи специальных грузовиков. Внутри таких мобильных офисов находятся комнаты пилотов, кабинет руководителя команды, медицинский кабинет, дополнительные офисы, гостевая зона и другие необходимые помещения.
KERS и DRS
«Формула-1″ — это автоспорт, который развивается на инновационных решениях. В данный момент наиболее обсуждаемыми в «Формуле-1″ являются технологии Kers и DRS.
Система восстановления кинетической энергии (Kers) сохраняет энергию, когда машина тормозит, в специальном аккумуляторе, чтобы затем водитель мог ее использовать в гонке.
Система DRS — система регулирования заднего антикрыла — открывает заднее антикрыло, чтобы увеличить скорость болида на прямой.
Но в таком быстро развивающемся виде спорта как «Формула-1″ любая новая технология должна сначала доказать свою пригодность для того, чтобы окончательно закрепиться в автоспорте. Так было с Kers и DRS.
Хм, знакомиться с миром Формулы 1 сразу в игре очень сложно, поэтому лучше бы посмотреть хотя бы предыдущий сезон.
DRS — Drag Reduction System — система уменьшения сцепления. Подвижная часть заднего антикрыла, которая может быть задействована в определённых участках трассы (на длинных прямых участках), если вы находитесь позади соперника в одной секунде или меньше. Разрешено использовать только в сухую погоду.
KERS — Kinetic energy recovery system — система восстановления энергии в момент торможения. Когда вы тормозите, специальная система подзаряжает аккумуляторы энергией, которую можно потом использовать в течение 6 секунд, чтобы повысить количество лошадиных сил где-то на 80, точно не помню. Использовать эту систему можно в любой момент гонки или квалификации.
Гонщики снова критикуют систему DRS. Но она — лучшее, что есть у «Формулы-1» для обгонов
Просто компенсирует недостатки болида.
После дебюта в «Индикаре» бывший пилот «Ф-1» Маркус Эрикссон вновь поднял давний гоночный спор о технике в лучшей серии в мире — о системе снижения лобового сопротивления или DRS.
«Не уверен в ее пользе, – написал после заезда на «формульной» «Трассе Америк» в американском чемпионате швед. – Одна из самых замечательных вещей, что я увидел в «Индикаре» — отсутствие DRS. Значит, на трассе гораздо больше честных сражений колесо в колесо. Пилоты не ждут зоны открытия крыла, а идут на обгон, когда у них появляется шанс. DRS помогает совершать больше обгонов, но дает ли возможность проводить на трассе честные сражения? Просто знаю, что с точки зрения гонщика нужно быть более агрессивными и стремиться к большему, когда есть шанс бороться в любой точке трассы. Вместо того, чтобы дождаться зоны активации крыла и безопасно с нулевым сопротивлением пройти соперника».
После заявления бывшего гонщика «Заубера» и «Катэрхэма» перед Гран-при Бахрейна выступили уже пилоты «Формулы-1», тоже раскритиковавшие систему снижения лобового сопротивления.
«Наверное, не все хотят видеть обгоны, которые случаются благодаря DRS, – сказал лидер «Ред Булл» Макс Ферстаппен – Я был бы не против отказаться от системы».
«Эта система — костыль, избавляющий нас от скучных гонок, – согласился действующий чемпион «Формулы-1» Льюис Хэмилтон. – Однако что есть — то есть».
«DRS– искусственное устройство и опасная штука, – поделился мнением гонщик «Макларена» Карлос Сайнс. – Если она не закрывается, машина ведет себя совершенно иначе. Это касается и баланса, и поведения на торможении».
Тем не менее, система снижения лобового сопротивления выполняет важную функцию в современных болидах, и отказываться от нее может быть опасно.
Пояснения эксперта
Англоязычный ютуб-канал Chain Bear F1 – один из лучших в интернете по части объяснения сложных правил и принципов работы «Формулы-1» простым языком. За два года активного существования он собрал 200 тысяч подписчиков, а отдельные ролики о разборе обгонов Даниэля Риккардо, эволюции барьеров в «Ф-1» и теории гоночных траекторий собрали под миллион просмотров каждый. С каналом даже начали сотрудничество авторитетные издания Autosport и Motorsport.
Не прошел Chain Bear F1 и мимо темы DRS, объяснив, зачем она нужна и почему с ней пока нельзя рассставаться.
«Куда бы вы ни пошли — на дискотеку, в скейт-парк или парк с аттракционами — везде услышите одну и ту же точку зрения: избавьтесь от DRS. Я понимаю это и вижу все аргументы против: система искусственна, не производит реальных гонок и снижает ценность «настоящих» обгонов, поскольку желающим атаковать с тактической точки зрения безопасней дождаться новой зоны открытия крыла, чем совершать рискованные маневры в других местах треков. Честно говоря, все три пункта содержат идеальную аргументацию. Всем бы хотелось смотреть на «Формулу-1», где машины одинакового уровня смогли бы опережать соперников безо всякой помощи путем прохождения поворотов бок о бок от носа до хвоста. В идеале атаковать, контратаковать и защищаться круг за кругом честно. Это мечта.
Но DRS — это лучшее, что у нас есть. Сейчас.
Главная проблема обгонов в данный момент – «грязный воздух», и мы все еще ждем от «Либерти» и ФИА решения. Если же мы просто уберем DRS, не меняя причины его добавления, у нас не останется почти никаких гонок. Давайте сперва вспомним, что же конкретно делает система снижения лобового сопротивления.
Почему DRS активируется только на прямых, если проблемы заключены в поворотах? Аэродинамические пакеты болидов «Формулы-1» предпочитают работу в чистом нетурбулентном воздухе: так машина генерирует максимальное количество прижимной силы и удерживает задуманный инженерами баланс. А прижимная сила и баланс — ключевые факторы, позволяющие технике проезжать повороты на максимальной скорости.
Если же машина едет сквозь «грязный» воздух, возмущенный другой следующей впереди техникой «Ф-1», то прижимная сила, сгенерированная антикрыльями и другими частями шасси, уменьшается, а баланс становится непредсказуемым.
Большая часть потока, контактирующего с машиной, контролируется передним антикрылом и зоной дефлекторов. Если на них не поступит чистый воздух, эффективность машины уже снизится.
Следовательно, машина в «грязном воздухе» не может ехать в поворотах с задуманной конструкторами скоростью. Вместо этого она постоянно сталкивается с недостаточной или избыточной поворачиваемостью, а также общим недостатком аэродинамического сцепления. Что это значит для гоночных ситуаций? Лидирующая машина в чистом воздухе будет обладать нужным количеством прижимной силы и сможет атаковать поворот с максимально возможной скоростью. Преследователь в «грязном воздухе» потеряет темп в повороте и проиграет время относительно машины впереди.
Также преследователь потеряет еще больше времени из-за снижения скорости на выходе из поворота, так что когда соперники окажутся на прямой — лучшем месте для обгона с помощью слипстрима — машина позади окажется слишком медленной и чересчур отстанет.
Потеря времени в повороте и снижение скорости на выходе — уже двойной штраф для преследователя, хотя мы еще даже не рассматривали негативный эффект «грязного воздуха» для двигателя или охлаждения покрышек.
Так вот, DRS существует для того, чтобы убрать ущерб от «грязного воздуха» на выходе из поворотов. Благодаря системе снижения лобового сопротивления у преследователя появляется шанс наверстать упущенное в поворотах время и сниженную из-за «грязного воздуха» скорость.
Технически DRS не задумывался как «мегапреимущество» для преследователя или как система «нажми для обгона». Им хотели просто поправить гоночный баланс. Для уравнивания ущерба и преимуществ зоны DRS можно изменять, увеличивать или уменьшать в зависимости от участка трека, условий и ситуации. Главный принцип же внедрения системы — вернуть преследователю шанс на борьбу с лидером.
В 2019-м регламент передних антикрыльев болидов изменили, чтобы снизить эффект от «грязного воздуха». С другой стороны, эффективность DRS выросла из-за увеличения размера заднего антикрыла вместе с открывающейся пластиной — тоже в соответствии с поправками в правилах. Теперь разница в лобовом сопротивлении между открытым и закрытым крылом намного больше, чем в предыдущие сезоны.
Таким образом, теоретически после повышения эффективности DRS зоны его активации могли бы сократить или даже убрать их из зон торможения. Посмотрим, как на эту возможность отреагируют в ФИА.
Тем не менее, все равно в данный момент DRS — лучшее решение, которое у нас есть. Вплоть до тех пор, пока регламент не решит проблему «грязного воздуха» окончательно. А это далеко не простая задача. «Формула-1» – не моносерия, а значит, команды имеют право развивать и менять свои машины как угодно в соответствии с правилами. К сожалению, лучшие инженеры мира обнаружили, что лучший способ контроля воздушного потока вокруг их машин — путем создания огромного шлейфа из возмущений и завихрений вокруг.
Они полостью уничтожают «чистый воздух» за «хвостом» машины. Это и есть тот самый «грязный воздух». Правила, снижающие турбулентность потоков, могут быть самыми разными — от введения стандартных антикрыльев и запрета дефлекторов до более глубокой проработки нынешнего регламента относительно параметров и размеров используемых пластин. Проблема же сохранится вплоть до дня внедрения новых правил.
И на данный момент самый простой и дешевый способ компенсации ущерба — это небольшое ускорение на наверстывания потери времени и скорости, предоставляемое DRS.
В фанатской среде гуляют несколько интересных предложений касательно системы снижения лобового сопротивления (конечно, помимо ее полного запрета).
– оставить DRS, но позволить пользоваться ею где и как угодно (автор перевода поддерживает именно ее) — тогда преследователи не получают искусственного внешне преимущества, которое выглядит смешно и нечестно. Тем не менее, она идет вразрез с истинным смыслом существования системы и вызывает некоторое вопросы безопасности в быстрых поворотах вроде туннеля в Монако или 130R на «Сузуке».
– позволять всем машинам использовать DRS в любой точке, но на ограниченный период времени. В теории тоже звучит неплохо — может придать больше тактических противостояний на треке. С другой стороны, у второго предложения нет принципиальных отличий от первого, так что и недостатки те же. Плюс оптимальные стратегии легко рассчитываются с мостика, а пилоты все равно будут активировать систему по большей части именно на прямых.
Я же лично ратую за сокращение зон DRS и смещения их с зон торможения, где это возможно. Лучше переместить их в начало прямых и снабдить машины системами автоматического отключения после пересечения точки деактивации. Тогда преследователь сможет возвращать потерянную скорость почти сразу же, а остаток прямых соперники проедут в условиях равной борьбы прямо до следующего поворота. Тогда и обгоны будут ощущаться как настоящие, поскольку преследователь не будет наращивать дополнительную скорость в процессе движения по всей прямой.
От DRS стоит избавиться только тогда, когда придет время. Это точно произойдет не раньше 2021 года после вступления в силу нового регламента. До тех пор же полный отказ от DRS может привести к потере гонок как таковых».
DRS как средство оптимизации размещения виртуальных машин в облаке Mail.ru Cloud Solutions
Source
Планировщик распределенных ресурсов (Distributed Resource Scheduler, DRS) — необходимый компонент любой виртуализированной среды, за исключением редких случаев с небольшой и ненагруженной инфраструктурой. Основная цель DRS — выровнять нагрузку на хостах, находящихся внутри вычислительного кластера, таким образом, чтобы виртуальные машины (ВМ) и развернутые на них приложения всегда получали ресурсы в нужном объеме и работали с максимальной эффективностью, а количество задействованных физических серверов при этом оставалось минимальным.
В облаке Mail.ru Cloud Solutions используется собственная реализация механизма DRS. Я Артем Карамышев, руководитель команды системного администрирования, расскажу о базовых принципах, на которых строится работа DRS у нас в облаке.
Что такое DRS и для чего нужна балансировка в облаке
Термин DRS был впервые введен компанией VMware по названию одноименной утилиты VMware DRS, предназначенной для балансировки кластера виртуальных машин. Сбалансированным считается такой кластер, в котором хосты равномерно распределены между виртуальными машинами с точки зрения потребления ресурсов и не возникает ситуации, когда, например, один хост используется на 99%, а другой на 30%.
При подключении новой виртуальной машины к кластеру ей, как правило, автоматически выделяется наиболее оптимальный хост, исходя из ее требований к потребляемым ресурсам и состояния кластера в целом. Но время от времени рабочие нагрузки виртуальных машин сильно изменяются, что может приводить к дисбалансу в распределении ресурсов и падению общей производительности. На некоторых хостах может остаться недостаточно ресурсов, в то время как другие будут простаивать. Задача DRS — вовремя обнаруживать такой дисбаланс и, в зависимости от выбранного уровня автоматизации, либо давать рекомендации по переносу ВМ, вызвавших дисбаланс, на менее загруженные хосты, либо выполнять эту миграцию автоматически.
Для поиска наиболее оптимального для каждой ВМ хоста обычно используется специальный автоматически запускаемый алгоритм, учитывающий текущее потребление ресурсов в кластере (память, процессорное время и так далее), а также требования к ресурсам, предъявляемые самой ВМ.
Упрощенная схема работы DRS: при обнаружении дисбаланса в кластере выполняется миграция ВМ на более оптимальные серверы
Для чего необходим DRS? Дело в том, что при отсутствии автоматизированного контроля распределение ВМ между серверами может быть крайне неэффективным. Вот лишь несколько возможных рисков:
Bin Packing Problem. Это риск «неравномерного» заполнения серверов виртуальными машинами и, соответственно, неоправданного увеличения используемых мощностей.
Невозможно заранее предсказать профиль нагрузки внутри виртуальной машины. Поэтому при определении оптимального гипервизора для создания виртуальной машины используются однозначные параметры: количество ядер, тип дисковой подсистемы, индивидуальные особенности флейвора виртуальной машины. В ходе последующей эксплуатации виртуальной машины может оказаться, что конкретно ее профиль нагрузки более (или, напротив, менее) требователен к утилизации процессора и памяти. При отсутствии DRS это крайне тяжело вовремя обнаружить, что приводит к неоптимальному использованию ресурсов.
Bin Packing Problem. Примеры неоптимального и оптимального распределения ВМ по хостам
На практике описанная проблема усложняется еще и тем, что далеко не всегда используемые физические серверы обладают одинаковой емкостью. Для построения кластеров всегда рекомендуется использовать однородное оборудование: это во многом облегчает распределение ресурсов. Но в реальной жизни конфигурации серверов, закупаемых в разное время, могут сильно различаться — по количеству ядер и мощности процессора, объему памяти, дисков и так далее. Условно говоря, в нашем примере capacity всех серверов будет не 1.4, а 1.7, 1.9, 1.5 и так далее. Кроме этого, нельзя допускать полной утилизации ресурсов на сервере: всегда должен оставаться некоторый «запас» — например, в нашем примере не подошли бы сервера с емкостью ресурсов 1. Все это еще больше усложняет ручное планирование.
Несвоевременный перенос на новые серверы в случае исчерпания ресурсов гипервизора. Если первый вид рисков не оказывает существенного влияния на клиентов облака, а лишь приводит к неэффективному использованию провайдером своих мощностей, то второй, напротив, способен существенно замедлить работу пользовательских приложений.
На гипервизоре выделение ресурсов виртуальным машинам происходит, как правило, с переподпиской. На 1 ядро процессора накладывается несколько ядер разных виртуальных машин. Поэтому, если одна из машин исчерпает выделенные ресурсы, это скажется на работе всех ВМ, размещенных на том же ядре.
Использование механизма DRS устраняет описанные риски и приносит провайдеру (а значит, и его клиентам) следующие преимущества:
Почему мы решили разрабатывать свое решение для DRS
Конечно, VMware DRS не единственный подобный продукт на современном IT-рынке. Наиболее известный аналог в мире OpenStack — Watcher. Однако очень часто облачные провайдеры разрабатывают свои решения. Почему так происходит? Причины могут быть разные. Чаще всего — высокая цена платных инструментов, а также недостаточность функционала бесплатных решений и/или обнаруживаемые в них сбои.
В нашем случае все было проще: DRS стал развиваться как часть уже существующей внутренней утилиты по управлению ресурсами OpenStack. Изначально эта утилита была направлена на то, чтобы облегчить работу службы поддержки. В программе можно отследить количество и состояние всех сущностей облака, включая виртуальные машины, гипервизоры, роутеры, диски, файловые хранилища, кластеры K8s, балансировщики нагрузки (Load Balancer As A Service, LBaaS) и многое другое. Утилита позволяет видеть текущее потребление ресурсов серверами и конкретными виртуальными машинами, а также прогнозировать изменение этих показателей в будущем. На основе данных, предоставляемых утилитой, оператор может своевременно видеть проблемы и находить пути их решения.
Так как всех данных, которые утилита уже извлекала для своей работы, было вполне достаточно для реализации DRS, на определенном этапе было принято решение добавить эти функции в утилиту. Это выглядело вполне логичным и обоснованным шагом, хотя сам процесс разработки оказался далеко не простым.
Схема работы DRS в облаке MCS
Схема работы DRS несколько раз менялась, совершенствуясь в ходе тестирования. Сейчас в промышленной эксплуатации находится следующая его форма:
Внутреннее название сервиса — Katana. Его бэкенд, написанный на Python, регулярно извлекает информацию о сущностях облака, используя OpenStack API. Под сущностями понимаются виртуальные машины, гипервизоры, диски и так далее. В выборку попадают только те характеристики, которые можно получить из OpenStack: количество элементов, их конфигурация и так далее. Утилизация ресурсов на этом этапе не извлекается.
Katana — Stateless-приложение, но для хранения своего кэша она использует memcached (MemCache). Отсюда данные впоследствии попадают в UI-утилиты для отображения операторам системы.
Фактически наша утилита представляет собой кэширующий слой для OpenStack. Все данные, которыми она оперирует, — это JSON, полученные из OpenStack и представленные в UI в табличном виде.
Для оптимальной работы алгоритма DRS данных из Openstack недостаточно. Поэтому сбор информации о фактическом использовании ресурсов с виртуальных машин производится с помощью специального сервиса katana-client раз в 10 секунд. Данные берутся из Libvirtd и носят инкрементный характер, так как для их получения используются нарастающие счетчики.
Данных, получаемых с katana-client, очень много, и они не преобразованы в значения per second. Поэтому собранные данные из katana-client передаются во вспомогательный HTTP + API сервис katana-collector.
Katana-collector выполняет расчет утилизации ресурсов в секунду на основе инкрементных данных, полученных из katana-client.
На основе полученных данных принимаются решения о балансировке различных кластеров гипервизоров.
Специальный алгоритм ищет гипервизоры, на которых утилизация процессора либо остаток свободной физической памяти выходят за рамки пороговых значений, указанных в настройках. Например, утилизация составляет 70% или количество физической памяти менее 64 GB. При обнаружении таких гипервизоров их ВМ перемещаются на гипервизоры с допустимым уровнем утилизации и свободной памяти — например, не более 50% и не менее 64 GB.
Для переноса выбираются, разумеется, не все ВМ с исходного гипервизора. Возможны следующие варианты:
На исходном гипервизоре чрезмерное потребление памяти. В этом случае будет выполнена миграция большого количества маленьких виртуальных машин для быстрого освобождения памяти до допустимого значения, заданного конфигурацией.
На исходном гипервизоре повышенная утилизация процессора. При таких условиях будет выполнена миграция наиболее сильно утилизирующих процессор виртуальных машин. Утилизация считается в отношении на 1 ядро, то есть в ситуации 4vCPU/400% (CPU Load) и 16vCPU/400% (CPU Load) будет выбрана виртуалка с 4 ядрами.
На исходном гипервизоре повышенная утилизация и памяти, и процессора. В таком случае для миграции будут выбраны самые небольшие ВМ, наиболее интенсивно использующие процессор. Используемая в алгоритмах функция нормализации построит дерево, которое будет в каждом случае индивидуальным.
Все фигурирующие в расчетах цифры хранятся в конфигурационном файле и при необходимости могут быть изменены. В случае ручной миграции, которая доступна непосредственно из UI утилиты, пороговые значения настраиваются в интерфейсе.
Если алгоритм, лежащий в основе автоматической миграции, находит ВМ, которые следует переместить для более оптимального распределения ресурсов, выполняется миграция с использованием OpenStack API.
Примечание: описание процесса авторизации осталось за пределами изображенной ниже схемы, но фактически пользователь получает всю информацию напрямую из Memcached через Nginx, без использования каких-либо Python-библиотек и так далее. При этом авторизация в утилите организована так, как если бы пользователь работал непосредственно с OpenStack с использованием его токена.
Схема работы DRS в облаке MCS. Базовые компоненты
Must-have-функции DRS и как они реализованы у нас
В хорошем решении DRS, я считаю, должны быть реализованы как минимум 5 основных функций:
Возможность выбора уровня автоматизации (вручную или автоматически). В нашем облаке миграции по умолчанию выполняются автоматически. Тем не менее мы выбираем, в каких кластерах гипервизоров использовать DRS, на основании регулярно проводимого анализа потребления ресурсов, подробно описанного выше. Однако дополнительно существует возможность проверить сбалансированность кластера и выполнить необходимые миграции вручную — непосредственно из самой утилиты.
Перед проведением миграции вручную оператору дается возможность установить произвольные пороговые значения для проверяемых ресурсов — отличные от тех, что берутся из конфигурационного файла при автоматических миграциях. Если в соответствии с введенными настройками будут обнаружены более оптимальные хосты для каких-либо ВМ, это будет указано в рекомендациях, на основании которых можно будет принять решение о необходимости миграций и запустить их.
Гибкая настройка пороговых значений для миграции. В нашей утилите предусмотрена возможность указания порогов для миграции как в ручном, так и в автоматическом режиме.
Ручная миграция может быть выполнена на уровне конкретной ВМ или гипервизора в целом. В первом случае ВМ уже выбрана и остается описать желаемый уровень утилизации ресурсов (CPU, память) на целевых гипервизорах, на которые планируется перенести эту ВМ. Во втором случае дополнительно указывается желаемый уровень утилизации CPU на исходном гипервизоре — для определения ВМ, подлежащих переносу.
Настройки для автоматической миграции указываются в отдельном конфигурационном файле. По своему составу они совпадают с параметрами ручной миграции на уровне гипервизора.
Возможность применения индивидуальных правил к определенным ВМ. Иногда может понадобиться запускать некоторые ВМ только на определенных хостах или держать группу ВМ всегда вместе — например, для соблюдения правил лицензирования или во избежание проблем с переносом ВМ, на которых установлено определенное ПО. Для реализации подобных ограничений у нас предусмотрены следующие функции:
VIP-проекты для исключения определенных ВМ из автоматических миграций. Это специальная отметка, запрещающая автоматический перенос. При необходимости такие ВМ всегда можно перенести вручную, выполнив миграцию на уровне конкретной ВМ или, в случае миграции на уровне гипервизора, указав в параметрах необходимость включения VIP-проектов.
Возможность выбора конкретной кастомной зоны (Availability Zone, AZ) или агрегата для миграции. Под агрегатом у нас понимается группа физических серверов, объединенная для какой-либо цели, например для размещения ресурсоемких приложений конкретного заказчика. По сути, зона доступности — это тот же агрегат, только более высокого уровня. При выполнении миграции вручную есть возможность явно указать зону доступности или агрегат, куда разрешено перемещать выбранные ВМ.
Получение сводки по использованию ЦП и памяти ВМ. Необходимость мониторинга, думаю, очевидна абсолютно для любой информационной системы. DRS в этом плане не исключение. В нашей утилите можно просматривать текущее потребление ресурсов (CPU и RAM) на уровне ВМ, физических серверов и агрегатов серверов.
Кроме этого, мы реализовали график, отображающий динамику потребления ресурсов по всему облаку за последние 365 дней. На графике можно увидеть, сколько в совокупности ресурсов было запрошено в каждый из дней прошедшего года. Это возможно за счет хранения даты создания всех ВМ.
Дополнительно на графике строится прогноз роста запрашиваемых ресурсов в будущем — на основе аппроксимации полиномов третьей степени методом наименьших квадратов. Если вкратце: график, построенный на основе реальных данных, достраивается графиком прогноза — полиномом третьей степени, максимально приближенным к линии, проходящей между всеми точками исходного графика. Ориентируясь на прогноз, можно своевременно предсказывать дальнейший рост облака.
Описанный график (включая прогноз) возможно построить и для других сущностей, не связанных с DRS, но отслеживаемых нашей утилитой: например, спрогнозировать рост количества дисков определенного типа, файловых хранилищ, роутеров, балансировщиков и так далее.
Поддержка «живых» миграций (Live Migration). «Живые» миграции, которые реализованы и у нас, не требуют остановки ВМ. Пользователи продолжают работать с исходным экземпляром ВМ до тех пор, пока ее данные не будут полностью перенесены на новый физический сервер. После копирования последних изменений из оперативной памяти пользователь продолжит работу с той же ВМ, которая фактически будет размещена уже на другом хосте.
Также в нашей утилите есть возможность просмотра состояния всех миграций в режиме реального времени: можно увидеть текущие и завершенные миграции, их статус, сведения о сервере-источнике и сервере-приемнике, о перенесенных ВМ и так далее.
С какими сложностями мы столкнулись
Как я уже говорил, процесс написания собственного DRS-решения был довольно непростым. Необходимо было подобрать наиболее оптимальный алгоритм, учитывающий множество факторов. Опишу некоторые из возникших сложностей и то, как их в конечном счете удалось решить:
Сбор метрик. Так как в самом OpenStack не было механизма получения метрик с гипервизоров и ВМ, пришлось разрабатывать собственные инструменты. Так появился демон katana-client, считывающий нужную нам информацию из Libvirtd. Однако возвращаемые им данные были инкрементными, так как для их получения использовались нарастающие счетчики. Поэтому мы дополнительно разработали компонент katana-collector — для агрегации последних полученных из katana-client значений, расчета дельт между ними и их усреднения. В результате мы стали получать нужную нам величину — утилизацию в секунду.
Выбор наиболее корректных метрик. Перед нами стояла задача максимально корректно определять загруженность гипервизоров. Если с оперативной памятью все было понятно, то утилизацию процессора мы пробовали находить различными способами. Изначально ориентировались на среднюю загрузку процессора (Load Average). Но впоследствии все алгоритмы были переписаны на использование метрики CPU Idle, показывающей процент свободного времени процессоров. В конечном итоге это оказалось более правильной метрикой для оценки ресурсов процессора.
Получение метрик с конкретных ВМ. Наряду с получением метрик по гипервизорам необходимо было получать аналогичную информацию по конкретным ВМ — для принятия решения о том, какие именно ВМ подлежат миграции в случае повышенной утилизации гипервизора. На первых этапах разработки сумма данных, получаемых с ВМ, расходилась с общими данными по гипервизору на 20–30%.
Правильным решением стало собирать информацию не только об утилизации всех «железных» подсистем гипервизора виртуалкой, но и об утилизации непосредственно со стороны клиентских процессов, запущенных в ней. К счастью, Libvirtd такие данные предоставлял. Мы провели ряд тестов, которые на практике подтвердили данную теорию: сумма утилизации всех виртуальных машин наконец стала совпадать с утилизацией всего сервера. Это привело к двум другим важным улучшениям:
В интерфейсе утилиты появилась возможность видеть утилизацию в разрезе конкретных виртуальных машин, а следовательно, быстро определять ВМ с наибольшим потреблением процессора и памяти.
Скорость выборок DRS — в частности, скорость вывода страниц с предлагаемыми для миграции гипервизорами — возросла в 10 раз, так как теперь все данные, участвующие в расчетах, были доступны на момент проведения миграции.
Подбор пороговых значений для автоматических миграций. В ходе тестирования мы неоднократно изменяли граничные значения утилизации ресурсов, используемые в расчетах, пытаясь вывести формулу «идеальной» сбалансированности облака. В качестве нижней границы, сигнализирующей о необходимости миграции, сейчас принято значение метрики CPU Idle 30%, но идеально для нас поддерживать данное значение не менее 50%. За достаточное количество памяти на гипервизоре принято значение 64 GB. Однако при необходимости эти границы всегда можно изменить.
Необходимость обработки ситуаций с нехваткой свободных ресурсов. В основе алгоритма лежит два простых шага: 1) выбор всех виртуальных машин для последующей миграции; 2) выбор подходящих хостов для миграции на них выбранных ранее виртуальных машин. Оптимальность второго шага определяется достаточным количеством свободных ресурсов в облаке. Таким образом, ошибки при выполнении этого шага неизбежны: может возникнуть ситуация, когда подходящие хосты не будут найдены. Алгоритм рассматривает эту ситуацию как штатную (выводя соответствующее уведомление), и это служит хорошим триггером для правильного capacity planning внутри облака.
Вместо заключения
Если вам понравилась статья и было бы интересно почитать ее продолжение с более детальной информацией на тему реализации DRS в облаке (включая код, используемый для загрузки метрик из Libvirtd, и другие технические подробности), пожалуйста, пишите комменты. Спасибо!