Распределение ресурсов CPU между VM в облаке Скалакси

    Многие из вас знакомы с Оверсаном по статьям в нашем блоге на Хабре, где мы много рассказывали об архитектуре систем ДЦ Оверсан-Меркурий. Об архитектуре облака Скалакси мы тоже рассказывали, но в основном на профильных конференциях, многие наши доклады и презентации уже устарели и стали неактуальны.

    Мы думаем, что многие из подсистем и архитектурных решений в Скалакси будут вам интересны и решили о них рассказать. Начать именно с темы распределения ресурсов CPU решили потому, что вопрос о гарантированном объеме вычислительных ресурсов всегда на слуху: мы регулярно слышим его от клиентов, просто интересующихся, критиков и блоггеров.

    Чтобы разобраться с распределением ресурсов, придется рассмотреть архитектуру нашей системы виртуализации хотя бы в общих чертах и детально изучить частности. В этой статье я постараюсь объяснить, как работает распределение вычислительной мощности CPU между виртуальными машинами клиентов: сколько времени CPU достается каждой VM и за счет чего это достигается.

    Определения

    Мы в команде Скалакси привыкли к некоторым терминам и определениям, которыми будет пестрить этот текст, поэтому я приведу их список тут:
    • VRT-хост или просто VRT — один хост виртуализации, физический сервер, на котором размещаются виртуальные машины пользователей;
    • VM — виртуальная машина пользователя, она же — виртуальный сервер. В мире классического хостинга очень простая версия этой штуки называется VPS.

    Многие другие определения и термины раскрываются ниже, по ходу подачи материала.

    Общая архитектура Xen

    Рассказ о планировщике CPU в Xen проще всего начать с небольшого вводного описания основных принципов работы Xen гипервизора. Xen — система паравиртуализации, позволяющая на одной физической машине (хосте) запускать несколько гостевых виртуальных машин, которые с помощью Xen получают доступ к ресурсам физической. При этом возможно два варианта запуска гостевой VM — режим паравиртуализации (PV), когда виртуальная машина запускается с модифицированным ядром и знает, что она запущена в Xen, либо машина запускается с любой немодифицированной ОС, при этом для нее запускается специальный процесс, эмулирующий поведение реального железа (qemu-dm), такой режим называется HVM.

    В Xen гостевые виртуальные машины также называются доменами. Существует один привилегированный домен (Dom0), через который происходит управление гипервизором, работа других гостевых машин с I/O, управление другими виртуальными машинами. Гостевые виртуальные машины (DomU) могут быть запущены только после загрузки Dom0.



    В целом, архитектура гипервизора Xen уже много обсуждалась на хабре, распыляться и раскрывать ее в одной статье еще раз — нет смысла.

    Планирование & распределение мощности CPU

    Итак, получается, что у нас есть аппаратный уровень, на котором выполняется гипервизор, поверх которого запущено несколько гостевых виртуальных машин (Dom0 & DomU). У каждой из этих виртуальных машин есть доступ к CPU. Как он организован?

    Каждая виртуальная машина работает с так называемыми виртуальными CPU (vCPU), это виртуализованное представление одного ядра. Количество vCPU назначается каждой виртуальной машине индивидуально либо в ее конфигурации, либо с помощью команды xm vcpu-set. При этом, количество vCPU на каждой виртуальной машине может быть не менее одного и не более количества ядер хоста.



    Задача гипервизора — правильно распределить время физических CPU между vCPU, решением этой задачи занимается компонент, называемый cpu scheduler. В ходе написания этой статьи я нашел информацию о трех существующих планировщиках и описание некоего планировщика, который должен прийти на смену тому, что по-умолчанию используется в Xen сейчас. Но цель этой статьи — рассказать, каким образом это работает у нас в облаке, поэтому я остановлюсь подробно только на одном: credit scheduler.

    Если поискать, то на Хабре можно найти статьи по этой тематике. Поэтому тут мы кратко резюмируем основные принципы планировщика и еще раз разберемся в алгоритме его работы:
    • Планировщик работает с vCPU в качестве объекта в очереди. Xen не занимается планировкой задач внутри VM, он лишь управляет временем выполнения vCPU, а гостевая ОС заботится о работе процессов внутри VM;
    • Виртуальной машине можно ограничить количество vCPU — от одного, до общего числа ядер;
    • Виртуальной машине назначается вес (weight), управляющий приоритетом выделения времени CPU для ее vCPU;
    • Cap — искусственное ограничение максимально выделенного количества времени CPU в процентах от одного физического ядра. 20 — 20% одного ядра, 400 — 4 ядра полностью, 0 — нет ограничения;
    • Dom0 тоже использует эти параметры (и vCPU) и получает процессорное время согласно своим параметрам weight и cap.

    Теперь подробнее об алгоритме:
    • У каждого CPU в Xen есть своя очередь, в которую становятся vCPU. У vCPU в очереди есть уровень кредитов (число) и статус (over / under), который показывает, получило ли виртуальное ядро свою порцию CPU в этом периоде распределения, или еще недополучило;
    • Расчетный период — некий период времени, раз в который внешний тред пересчитывает количество кредитов всех vCPU и меняет их статусы соответственно количеству кредитов (очков);
    • CPU Time slice — период времени (по-умолчанию 30ms), который CPU предоставляется для одного vCPU.



    Отработав один time slice (vCPU заблокировался, ушел в idle, наоборот проснулся), CPU перейдет к следующему vCPU в очереди. При этом, потребляя тайм-слайсы CPU, со счета vCPU списываются очки, если количество очков стало отрицательным, то vCPU получит статус over и займет свое место в очереди. Если в очереди закончились vCPU со статусом under, CPU поищет такие vCPU в очередях других ядер. Если же и там его нет — он будет искать следующий vCPU у себя и других со статусом over, но cap, позволяющим выдать vCPU еще немного времени. Этот подход гарантирует, что даже vCPU с достаточно низким weight получит процессорное время, если CPU системы и других виртуальных машин простаивает, а так же гарантирует, что VM получит свое процессорное время.

    Как это организовано в Скалакси

    В Cкалакси, мы используем Xen-гипервизор, виртуальные машины пользователей запускаются на VRT-хостах. Наша собственная разработка, CloudEngine, выбирает, на каком VRT-хосте запустить машину. Алгоритм выбора подходящего хоста называется аллокатором, но если объяснять по-простому — он на основании кол-ва слотов VM выбирает подходящее для нее по размеру место так, чтобы облако было “правильно” укомплектовано: чтобы потом было где запустить другие виртуальные машины и чтобы виртуальным машинам доставалось побольше ресурсов (абзацем выше мы говорили о том, что если физический хост заполнен не на 100%, то CPU будет выделяться больше гарантированного минимума).

    В dom0 запускается SLES, у которой cap = 0 и weight = 16384. Далее в domU запускаются клиентские VM, засланные CloudEngine, и их вес назначается из расчета одной единицы веса на один мегабайт RAM. Таким образом получается, что суммарный вес domU-машин при полной загрузке VRT-хоста — 32768. То есть даже если хост загружен под завязку, dom0 получит достаточно вычислительных ресурсов, если они вдруг понадобилось, и хост не “захлебнется” под тяжестью domU-машин.

    На самом деле, dom0 почти всегда в idle, поэтому мы можем считать, что CPU распределяется между виртуальными машинами клиентов с некими незначительными потерями на dom0. Франк Кохлер в своей презентации утверждает, что dom0 уже после загрузки в штатном режиме “съедает” до 0,5% CPU.

    Также очень важный момент: CloudEngine раскладывает машины в облако таким образом, чтобы на одном хосте было занято до 50% процентов его ресурсов. Это достигается достаточно просто: мы регламентировано гарантируем, что облако зарезервировано, то есть падение до 50% хостов должно привести к миграции VM на другие хосты и продолжению работы, а это значит, что занята может быть максимум половина облака. А это, в свою очередь, означает, что в идеале — на каждом хосте не более 50% занятых ресурсов: это облегчает масштабирование VM (меньше миграций при масштабировании) и увеличивает долю CPU, достающуюся каждой машине.

    Что дальше

    В этой статье я рассказал, как распределяется CPU между VM в облаке. В следующей я хочу показать, как это работает на практике. Ждите тестов производительности на следующей неделе :) Если вам хочется провести независимый тест — пишите, мы предоставим для этого ресурсы бесплатно.

    Материалы по теме

    Если вам интересно почитать материалы по распределению ресурсов CPU в Xen — ниже те источники, информацию из которых я использовал. Если найдете другие интересные статьи — напишите об этом, пожалуйста, в комментариях.

    Подписывайтесь на наш twitter, мы стараемся искать для вас интересные материалы о виртуализации и облачных вычислениях. И заходите нас потестировать / подать нам идею о нужном вам функционале :)
    Оверсан
    Компания
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 52

      +1
      Ждем тестов!
        +1
        Весьма познавательно, Нат!
        Интересно было бы ещё почитать про обработку прерываний и управление памятью в Xen.

        Отдельное спасибо за ссылки в конце поста.
          0
          Не за что :) Про управление памятью и обработку прерываний — мне самому интересно, но сначала погоняю у нас тесты покажу результаты, а потом уже попробую собрать данных на хорошие статьи по “низкоуровневым” темам.
          –10
          Простите, но Скалакси это не облако, а VM с миграциями.
            +8
            Еще скажите, что Amazon EC2 — не облако, а VPS хостинг.
              –6
              Аналогично, у Вас там не может быть 120 CPU
                +5
                Во-первых, Amazon EC2 — это Amazon Elastic Computing Cloud, термин употребляется с 2007 года и именно эта компания одна из тех, что задали тренд cloud computing в мире.

                Во-вторых, есть стандарт NIST, где все написано, что не было подобных недопониманий. По которому, Amazon EC2, Rackspace Cloud, GoGrid и Скалакси — public clouds.

                В-третьих, 120 CPU легко — поднимите 8 машин. Хотите через панель, хотите через HTTP REST API. Оплата по часам, не хотите — уберите. Это и называют computing cloud.
                  –6
                  Ушел открывать cloud с помощью proxmox :), скоро ждите в «Я пиарюсь»
              +1
              Что облако, а что не облако уже не раз обсуждалось, я разжевывал мат. часть в отдельной статье.
                0
                Простите, но что такое облако?
                Может Вы откроете нам всем секрет или, возможно, Вы придумали свое облако?
                  0
                  Соответственно коммент выше. Мы термины не придумываем, мы пользуемся тем, чем весь мир пользуется.
                    +2
                    вопрос был к equand :-)
                    –7
                    Явно не proxmox или cvirt система. Или VMWare Cloud
                    Когда моя виртуальная машина будет работать как огромный сервер на 4-6 реальных серверах, аггрегируя все мощности в одну огромную доступную машину с распределением и выполнять условия map/reduce равному количеству всех аппаратных систем в клауде, тогда это будет VM cloud, а пока это настроенная виртуалка с миграциями.
                    Минусяторам изучать матчасть не по маркетинговым писулькам, а по реальным данным. На данный момент только SaaS может работать как cloud (распределенное, масштабируемое не только в пределах одной машины и доступное)
                      +5
                      Когда моя виртуальная машина будет работать как огромный сервер на 4-6 реальных серверах…
                      Не путайте гриды с облаками.
                      Минусяторам изучать матчасть не по маркетинговым писулькам, а по реальным данным.
                      Реальные данные на NIST.gov.
                        –3
                        Да, оказывается это маркетинг глобального масштаба. Раньше это называли VDS, когда появилась возможность их перекидывать на другие системы (с migrate и аналогами) стало внезапно Cloud…
                        В таком случае, да, Cloud.
                          +1
                          Один .ua хостер до наступления «попсового» термина Облако пиарил свои услуги «Хостинг в кластере».
                          А вообще да, маркетинг это что-то, 3G инет в Украине похоже толком только у utel'а есть, а всякие операторы кричали что они уже 3g (ага, с CDMA EVDO). Тут совсем недавно новый отжиг, уже 5G оказывается есть (5g.ua)! Это который wi-fi но на частоте 5ГГц…
                          Ох уж этот маркетинг.
                          А по теме Скалази — использую сейчас, нравится, но вот масштабирование ОЗУ вниз как то не очень корректно работает.
                            0
                            А по какой метрик вниз масштабируете, «Используемая память» или «Используемая память без кэшей»?
                              0
                              Используемая память
                                +2
                                В таком случае оно действительно работает не так как ожидается. Потому что кэши в Linux большинстве случаев не сбрасываются самостоятельно. Поставьте на масштабирование вниз метрику без кэшей и все сразу станет ок.
                                  0
                                  Спасибо! Попробую.
                                    0
                                    Собственно не только вверх, но и вниз. Нам похоже надо сделать это дефолтным.
                              +3
                              Масштабировать можно самому через API. Для примера посмотрите мой скрипт: aml.rulezz.ru/download/mg_scale.tgz
                                +1
                                На python2.5 работать будет?
                                headers[«Authorization»] = «Basic YW1s и тд — данные фейковые? :)
                                  +1
                                  Будет, 99%.
                                  Фейковые, разумеется.
                                0
                                Для справки:
                                1. CDMA2000 (1xEV-DO/IS-856 самый настоящий стандарт сети третьего поколения;
                                2. В основе UMTS тоже CDMA.
                                  0
                                  Цитата:
                                  1X EV-DO (только данные) и 1X EV-DV (данные & голос). Именно стандарт 1X EV-DV может считаться полноценным 3G-стандартом.

                                  CDMA2000 1X EV-DO не третее поколение, интересуюсь этой технологией лет 6-7 (вообще CDMA). С момента коммерческого запуска ПиплНэт (рекламаровали себя как 3G) было сказано, что в рекламе 3G это бренд, а не технология. Скажем так 1X EV-DO почти 3G.
                                  UMTS — да, полноценное 3G.
                                  А в википедии и не то напишут…
                                    0
                                    Цитата:
                                    3G включает в себя 5 стандартов семейства IMT-2000 (UMTS/WCDMA, CDMA2000/IMT-MC, TD-CDMA/TD-SCDMA (собственный стандарт Китая), DECT и UWC-136).
                                      0
                                      Пусть та же вика russian-wikipedia.wiki-site.com/c/d/m/CDMA2000_6138.html
                                      Стандарт 1X EV-DV полностью соответствует всем требованиям 3G.

                                      1X EV-DO — полностью не соответствует, потому и наезжали в свое время на рекламу того-же Пипла.
                                        0
                                        Это не отменяет достоинств peoplenet и практического отсутствия видеозвонков в Utel.
                                0
                                на данный момент слово «облако» действительно используют где только можно, тем не менее есть уже устоявшиеся деления на группы о которых можно почитать в статье «API Облачных сервисов» habrahabr.ru/blogs/cloud_computing/109088/
                              +2
                              Вы назвали панели управления, но не как ни технологию.
                              Вот у меня кластерная ФС и кучу хайпервизоров — для меня это клауд.
                              Причем, ВМ могут летать между разными дц без каких либо проблем.
                                0
                                Ссылки на реальную матчасть дадите? Язык изложения не важен.
                                Всё же интересно услышать аргументацию разных мнений.
                            +1
                            Ага, ага, вы так изящно ушли от вопроса о том, КУДА тратит dom0 выделяемый ему процессор, что начинает даже казаться, что это справедливая система распределения процессора.

                            Напомните, как скедулер учитывает, чьи дисковые операции сейчас обрабатывает dom0?
                              +4
                              Дисковые операции учитывает другой шедулер — dm-ioband, который работает в dom0. Причем делает это в соответствии с размером виртуальных машин, так что тут все ок.
                                +1
                                Не, вы не поняли. Я спрашиваю, каким образом скедулер процесса учитывает выделение процессорного времени для дисковых операций в кредите для той domU, для которой эта операция предназначается? (Да, я хорошо знаю слабые места зена).

                                Допустим, у нас есть одна машина, которая только считает, и вторая (равная первой), которая и считает, и по дискам срёт. Процессора на вычисления они получат одинаково, только вот вторая ещё через dom0 себе порцию хапнет в ущерб первой.
                                  +2
                                  Под dom0 для этого обычно выделяют отдельный процессор(ы): wiki.xen.org/xenwiki/XenBestPractices
                                    0
                                    Угу. Одну штуку. А если выделить больше одного, получается быстрее.
                                    0
                                    Не, такого не будет.

                                    Каждая VRT не занимается более чем на 50% конкурентными виртуальными машинами. А вес dom0 равен ровно половине максимально возможного веса физической емкости VRT. Таким образом виртуальные машины не пересекаются с dom0 по процессору в обычном режиме.

                                    domU в нашем алгоритме может пересечесься с dom0 только если это большая domU более чем на половину физического сервера. Но тогда она монопольно использует ресурсы этого сервера и никаких проблем.
                                +1
                                Я правильно понимаю, что чем быстрее vCPU отдаёт управление, тем чаще оно ему будет доставаться?
                                  0
                                  Пока кредиты не исчерпает.
                                    +1
                                    Саш, как я понял, он кредиты отсчитывает именно за время, а не за тайм слайс. То есть если VM чего-то сделала и закрыла слайс раньше положенного — у нее отнимут меньше кредитов, а а значит ей достанется больше слайсов, но суммарное время будет выдано согласно кол-ву кредитов.

                                    Черт, не слишком загнул?
                                      0
                                      Я так и понял. Это собственно есть хорошо.
                                        0
                                        Задача ребят из xen была сделать так, чтобы планировщик успевал расчитывать кредиты корректно с какой-то определенной погрешностью, при этом не создавая больших накладных издержек. Поэтому расчет должен был быть простым как первый русский трактор. Раз в “раунд” обсчитывать заново кредиты основываясь на формуле (она там не сложная, я ее где-то в приложенных материалах видел — умножение и сложение), а затем только вычитать раз в “скачок” — это вполне себе просто и точно.
                                          0
                                          А можно спросить сколько этот раунд длится? И после раунда что происходит, кредиты сбрасываются и раунды независимы или пересчитываются с учётом того, кто сколько съел в предыдущих?
                                          Я к Вам только подключился, разбираюсь. После статьи стало страшно :)
                                          Т.е. у меня есть один маленький процесс ради которого всё затевалось, который ресурсов почти не ест, но должен работать постоянно. Потом смотрю — 16 ядер простаивают, думаю вот здорово, можно будет расчётами подзагрузить. Но если после этого оно будет затыкаться совсем на 15 минут, то это полные вилы, маленький процесс должен работать. Теперь есть ощущение, что нужно скупить почти все ресурсы, чтобы оно простаивало и сжирало деньги, но чтобы получить достаточный weight, чтобы не дай бог не остаться без процессорного времени на пол-часа :(
                                    +2
                                    Не так давно задавал вопрос о CPU в суппорт, сказали что скоро выйдет статья с подробностями. И вот она :)
                                      –6
                                      BUG REPORT for SCALAXY

                                      И вот тот самый школьный учитель информатики стоит на зыбкой поверхности облака СКАЛАКСИ в надежде скорее попробовать это чудо и рассказать своим старшеклассникам как же это круто! Но, что я вижу!?

                                      www.scalaxy.ru/profile/step2
                                      > Шаг 2
                                      > Заполните, пожалуйста, регистрационные данные.

                                      Вы сразу же просите меня указать данные моего паспорта, кем и где он выдан, номер телефона и место проживания. Извините, что а там с этой формальностью об обработке ПЕРСОНАЛЬНЫХ ДАННЫХ? Ее отменили? Почему такая мощная компания проигнорировала это требование? Как говориться в известном анекдоте: вы не виноваты — но осадочек остался.

                                      Радует, что можно пройти это поле без ввода данных — жесткой валидации по формату данных нет.

                                      >Шаг 3
                                      >Прочтите договор оферты и отметье галочкой, если вы с ним согласны

                                      Первое: Тупо орфографическая ошибка в слове: отметьте
                                      Второе: А где сама оферта? На странице регистрации www.scalaxy.ru/profile/step3 ее так и не нашел.

                                      Буду надеяться, что вы не написали в оферте, что я передаю в ваш адрес все свое имущество… СОГЛАСЕН — ставлю галочку!

                                      Здравствуйте ОБЛАКА!

                                        0
                                        Я паспортные данные не заполнял — работаю, необязательный это пункт.
                                          0
                                          Может случиться так, что мы напишем письмо и очень попросим заполнить. Но по-человечески мы понимаем, что людям лень :)
                                          0
                                          Спасибо вам за багрепорт! Но, знаете, багрепорты обычно шлют в специальные, отведенные для этого места: help at scalaxy dot ru, к примеру, или в виде тикета на сайте поддержки.

                                          Нам важны любые отзывы, так что и за этот — спасибо. :)

                                          По закону об оказании телематических услуг мы обязаны хранить ваши паспортные данные. А вот распространять их мы действительно права не имеем. Это закреплено в оферте, разумеется. Саму оферту недавнее время назад нам пришлось убрать с сайта, она требует отдельного согласования. Я приношу за это личные извинения, это не есть хорошо и мы с генеральным директором и юристами сейчас вносим поправки в оферту, чтобы положить ее на место в ближайшее время.

                                          На данный момент вам ни что не мешает не указывать паспортные данные, пользоваться триальными деньгами или оплачивать небольшие суммы денег (никакого минимального размера платежа нет, хоть 10 рублей по смс оплачивайте).

                                          Кстати, на третьем шаге у нас действительно опечатка. Спасибо еще раз, что подметили ее.
                                          +4
                                          Школьный учитель информатики доволен!
                                          Третий рельс установился и запустился за 5 минут.
                                          Подумаю о том, что бы перенести школьный сайт в облако.

                                          Спасибо!
                                            0
                                            Спасибо школьному учителю информатики, если он умеет работать с rails :) Старшеклассникам своим, надеюсь, тоже Ruby преподаете, а не basic?
                                            0
                                            А чем qemu-dm хуже PV, кроме траты ресурсов на специальный процесс, эмулирующий поведение реального железа?

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое