С момента запуска я получил много вопросов о том, как именно учитываются ресурсы в облаке.
Некоторые интуитивно понимают, что такое «процессорный час», но есть и те, кто хочет подробного объяснения.
Поскольку подробные пояснения заняли бы много места в общем анонсе, я вынес их в отдельную тему.
В то же время этот формат позволит нам более подробно описать взаимодействие Zen и виртуальных машин.
Уровень данного текста научно-популярный, то есть я не буду углубляться в дебри кольцевых буферов, маскирования событий, «планировщика кредитов» и т.п.
, вместо этого я попытаюсь рассказать относительно человеческим языком о том, как гипервизор управляет гостевые машины.
Что такое «процессорное время»? Сначала мы хотели назвать это более привычным «машинным временем», благо этот термин использовался еще во времена мэйнфреймов, когда идея разделения машинного времени только зарождалась, но мы вовремя остановились.
Под машинным временем в те годы подразумевались все ресурсы, которые использовала машина, а в нашем случае речь идет именно о процессоре, поскольку каждый ограниченный ресурс учитывается отдельно.
Итак, что же такое «процессорное время» и как может получиться, что у одной виртуальной машины его 4 часа в день, а у другой — 30 «часов» примерно за десять часов? Облако Selectel работает на Xen, а точнее, на Xen Cloud Platform, в которой Xen выступает в качестве гипервизора.
В Xen есть концепция «планировщика домена».
Оставляя в стороне разницу между доменом и виртуальной машиной (домен - это работающая конкретная виртуальная машина, при перезагрузке виртуальной машины получается новый домен, при выключении виртуальной машины домена нет, а машина сам таков), мы можем считать это планировщиком виртуальных машин.
Те, кто знаком с работой современных операционных систем, наверное, уже догадались, что планировщик домена подозрительно похож на планировщик процессов в этих самых современных операционных системах.
Как выглядит виртуальная машина? Происходит какое-то событие: приходит сетевой пакет, срабатывает таймер, сигнал перезагрузки и т. д. Xen дает команду процессору начать выполнение виртуальной машины (точнее, домена, но для целей данного объяснения мы будем считать эти понятия равноценными) .
Ядро виртуальной машины обрабатывает событие, которое ее разбудило.
При необходимости вызывает пользовательские процессы.
Процессы выполняют свою работу и сообщают ядру: «Все, мы закончили».
Ядро разбирается со своими проблемами и точно так же сообщает гипервизору (Xen) — «все, я закончил».
После этого Зен останавливается машинное исполнение.
Она просто буквально ничего не делает. Машина остается в этом состоянии до тех пор, пока не произойдет новое событие.
В современных машинах эти события происходят с огромной скоростью — например, если скачать файл со скоростью 5 Мбит/с, то это (при размере пакета 1500 байт) составляет более 3000 пакетов в секунду.
Каждый пакет — это отдельное прерывание (точнее, в Xen всё хитрее, там несколько вызовов объединены в один, поэтому иногда виртуальная машина оказывается немного быстрее, чем даже на голом железе).
И каждое такое событие – это пробуждение машины.
Но скорость современных процессоров такова, что после каждого такого вызова ядро виртуальной машины и процессы (например, Apache или nginx) успевают поработать и уйти в сон.
Статический вывод на скорости 5 Мбит/с — это очень низкая нагрузка, примерно 1-2% одного ядра процессора, поэтому, несмотря на то, что события происходят с интервалом 300 микросекунд, виртуальная машина обрабатывает за 3-6 микросекунд, а остальные 294- 296 микросекунд успевает сказать гипервизору «Я закончил» и заснуть.
А через микросекунды снова проснуться, поработать и снова заснуть.
Получается, что виртуальная машина большую часть времени просто спит. Именно эти моменты времени, когда виртуальная машина работает, и являются «процессорным временем».
Вдумчивый читатель может спросить — а что, если виртуальная машина не скажет «Я закончила»? Если бы у нас была Windows 3.11, где бы была кооперативная многозадачность , то это привело бы к тому, что остальные не получили бы положенного им времени.
Но в Xen он используется вытесняющая многозадачность — и слишком жадно работающая виртуальная машина будет просто подвешена.
Насильно.
А потом это продолжилось снова.
Обычно такая ситуация возникает при нехватке процессорного времени, и авторы Xen потратили тысячи часов на разработку справедливых планировщиков, которые при перегрузке процессора решают проблему распределения времени так, чтобы все продолжали работать более или менее равномерно.
.
Однако в реальных условиях современного хостинга скорость процессора настолько высока, что процессор является наименее востребованным и самым простаивающим ресурсом и в 99% случаев конкуренции за ресурсы вообще нет. Время процессора — это количество времени, в течение которого работает виртуальная машина.
Если она работала 2 шилл.
в час, то это так.
Если 40 минут значит сорок минут. Время процессора не имеет ничего общего с «реальным» временем на часах.
Поскольку Xen управляет виртуальными машинами, Xen знает с точностью до наносекунды, как долго работает каждая машина.
Это значение мы округляем до микросекунд (чтобы избежать проблемы с int64), а в биллинге записываются только целые секунды (дробная часть накапливается, пока не достигнет секунды).
Деньги за процессорное время списываются, как только оно достигает хотя бы 1 копейки (сейчас это 36 секунд).
Для сравнения, загрузка виртуальной машины занимает примерно 3-6 секунд компьютерного времени, и это самая «дорогая» операция в жизненном цикле домена.
Еще одна важная деталь — многопроцессорность.
Несколько ядер процессора на самом деле являются независимыми процессорами.
И они могут работать параллельно.
Допустим, мы даем 5 Мбит/с нескольким пользователям.
В какой-то момент времени мы должны отправить новый пакет раньше, чем отправим старый (например, прошел интервал в 0,5 микросекунды).
Если бы у нас был один процессор, этот запрос был бы поставлен в очередь и обработан после первого.
Но если процессоров несколько, то запрос будет обработан первым свободным ядром, независимо от уже занятых.
Если нагрузка высокая, то получается, что одновременно работает несколько процессоров.
При этом каждый из них работает, а время процессора суммируется.
Два одновременно загруженных ядра — 2 секунды машинного времени в секунду.
Восемь значит восемь.
Хотя на деле обычно оказывается, что несколько ядер заняты, но не полностью, то есть в какой-то момент работают 2 ядра, в какой-то момент 3, а в какой-то момент ни одно из них не работает. Так что вполне возможно увидеть 10 минут процессорного времени в час на 8-ядерной машине, обслуживающей десятки тысяч клиентов.
Если загрузка машины меньше 100% (то есть она потребляет меньше часа процессорного времени в час), то формально мы могли бы ограничиться одним ядром.
Но помните, что я говорил выше об одновременном обслуживании клиентов? Несколько ядер обеспечивают большую скорость реагирования на запросы, хотя, возможно, одно ядро вполне справится с этим, хотя и за счет увеличения времени ответа на запрос.
Кстати, это ответ на другой вопрос: влияет ли количество ядер на затрачиваемое процессором время? Ответ — нет, если эти ядра простаивают, то время процессора не используется.
А большое количество ядер лишь снижает задержку при обслуживании одновременных запросов от нескольких клиентов.
Ну и после этого немного о том, как нужно понимать понятия «дает время», «делает время».
Процессор представляет собой кремниевую аппаратную часть и глупый.
Все, что может делать процессор, — это выполнять код (и реагировать на прерывания).
А процессор не очень понимает, что такое «домен виртуальной машины», или работающая копия Angry Birds. Таким образом, понятия «домен» и «гипервизор» в некотором смысле являются условностями.
Когда мы говорим «виртуальная машина работала 10 мс», на самом деле мы имеем в виду: «процессор выполнял код виртуальной машины в течение 10 мс».
Когда мы говорим «гипервизор вытеснил виртуальную машину», мы на самом деле имеем в виду «по прерыванию таймера процессор обновил счетчик времени, сохранил контекст процесса и передал управление в место, отличное от того, где его прервал таймер».
Такой перевод объекта (кода) в субъект с возможностью действовать значительно упрощает объяснение – каждая программа имеет алгоритм поведения, и проще сказать, что «программа ведет себя так», вместо того, чтобы говорить «процессор , выполняя программу, делает то и это».
Теперь немного о том, что он ест и сколько ест. В начале статьи приведен график очень нагруженного сервера, поддерживающего астериск с вызовами всей компании, веб-сервера, собирающего статистику с роутеров и т.д. Ниже представлен сайт с примерно 5000 уникальными посетителями в день.
Это относится к вопросу о том, сильно ли современные серверные приложения используют процессор (голубой на графиках — простаивающий процессор).
Теги: #Облачные вычисления #виртуальные машины #виртуальные машины #виртуальные машины #Xen #selectel Cloud #selectel Cloud #selectel Cloud #selectel Cloud #учет ресурсов
-
Квадрокоптеры – С Чего Все Началось?
19 Oct, 24 -
Прочтите Код, Остальное Сделает Компилятор.
19 Oct, 24 -
Бизнес Хочет Личные Данные
19 Oct, 24
