Комментарии 45
вкусно, люблю такие топики. Просто о сложном.
Пригодится, если вдруг облако придётся делать…
наконец-то я осознал, что такое «домен» применительно к виртуализации. Отлично написано.
Там всё хитрее — если вы машину мигрируете, то получается новый домен. Проще всего смотреть с помощью xm list или xl list, там видно, что номер домена меняется при каждой миграции или ребуте.
Кстати, xen гарантирует, что в течение жизни хоста номер домена всегда уникальный (то между перезагрузками хостов один и тот же домен не может в разные моменты времени соответствовать разным виртуальным машинам). У нас на это довольно много логики управления завязано.
Кстати, xen гарантирует, что в течение жизни хоста номер домена всегда уникальный (то между перезагрузками хостов один и тот же домен не может в разные моменты времени соответствовать разным виртуальным машинам). У нас на это довольно много логики управления завязано.
Хм, а у вас нет случайно планов завести дата-центр в Европе, а не в России?
Спасибо за интересную статью. Для полноты картины: откуда вы берете значения этих счетчиков процессорного времени по каждой виртуальной машине? xm выдает эти данные или в /proc какой-то файлик?
Во-первых, в XCP нет этой глючной поделки под названием xm и xend. Сколько я не бодался против окамла, но его стабильность на пару порядков выше, чем у шевелящейся кучи из питона и шелловых скриптов под названием 'xend'. Часть xcp построена на libxl.
Во-вторых, нет, мы не используем xl для аккаунтинга, вместо этого у нас идут hypercalls к гипервизору через низкоуровневую библиотеку. Сам зен возвращает время работы домена (не виртуальной машины!) в наносекундах. Мы учитываем предыдущие показатели (предыдущие домены виртуальной машины), собираем статистику и суммирующие счётчики.
Во-вторых, нет, мы не используем xl для аккаунтинга, вместо этого у нас идут hypercalls к гипервизору через низкоуровневую библиотеку. Сам зен возвращает время работы домена (не виртуальной машины!) в наносекундах. Мы учитываем предыдущие показатели (предыдущие домены виртуальной машины), собираем статистику и суммирующие счётчики.
Учет процессорного времени… в голову сразу лезут аналогии с одной ЭВМ на целый отдел, и графиком загруженности… а вот оно как, круговорот однако!
Честно говоря, я думал это все очевидно… Даже странно, что люди как то об этом не знали.
Правильно ли я понимаю?
1. Облако само может развести на разные ядра несколько параллельных процессов — например, несколько Апачей, отдающих статику разным пользователям.
2. Но какой-то один прожорливый PHP-скрипт (пусть, условно говоря, я конвертирую 10-мегапиксельный TIFF в JPEG) — по-любому будет грузить единственное ядро?
3. А если PHP-скрипт сам ничего не конвертирует, а вызывает конвертер, написанный на C++ с поддержкой многопоточности, как дочерний процесс — тогда распараллеливание тоже будет?
1. Облако само может развести на разные ядра несколько параллельных процессов — например, несколько Апачей, отдающих статику разным пользователям.
2. Но какой-то один прожорливый PHP-скрипт (пусть, условно говоря, я конвертирую 10-мегапиксельный TIFF в JPEG) — по-любому будет грузить единственное ядро?
3. А если PHP-скрипт сам ничего не конвертирует, а вызывает конвертер, написанный на C++ с поддержкой многопоточности, как дочерний процесс — тогда распараллеливание тоже будет?
Облако ничего не знает про апачи. Это проблема ядра гостевой системы (линукса), и по слухам, он это умеет делать.
Поддержка многопоточности — целиком и полностью на совести приложения. Если взять однопоточное приложение, то хоть 200 процов рядом положи, оно будет мурыжить один.
Поддержка многопоточности — целиком и полностью на совести приложения. Если взять однопоточное приложение, то хоть 200 процов рядом положи, оно будет мурыжить один.
Ну что облако не знает слова «Апач», я догадывался. Я просто взаимодействие этого Зена с тем самым Линуксом представляю себе в очень-очень общих чертах :)
Просто в порядке дилетантских рассуждений.
Например, я — Линукс, сижу в среде Зена, но думаю, что он — обычная «железная» машина. Сколько процессоров я вижу? Ну пусть, например, 8. Вот я запускаю внутри себя какие-то процессы, развожу их по процессорам/ядрам. И вдруг Зен решил, что сейчас 3 ядра из 8 (которые я вижу и на которые рассчитываю) целесообразно отдать конкурирующей виртуальной машине (о которой я ни сном ни духом). Что произойдет, если я тоже захочу эти занятые кем-то ядра задействовать? Не наступит ли у меня жестокий когнитивный диссонанс — я же ОС! Я рулю железом, а тут мне вдруг говорят, что ядра заняты.
Хотя скорее всего мне никто ничего не говорит. А просто делают укол наркоза и принудительно кладут спать, чтоб не задавал лишних вопросов.
Просто в порядке дилетантских рассуждений.
Например, я — Линукс, сижу в среде Зена, но думаю, что он — обычная «железная» машина. Сколько процессоров я вижу? Ну пусть, например, 8. Вот я запускаю внутри себя какие-то процессы, развожу их по процессорам/ядрам. И вдруг Зен решил, что сейчас 3 ядра из 8 (которые я вижу и на которые рассчитываю) целесообразно отдать конкурирующей виртуальной машине (о которой я ни сном ни духом). Что произойдет, если я тоже захочу эти занятые кем-то ядра задействовать? Не наступит ли у меня жестокий когнитивный диссонанс — я же ОС! Я рулю железом, а тут мне вдруг говорят, что ядра заняты.
Хотя скорее всего мне никто ничего не говорит. А просто делают укол наркоза и принудительно кладут спать, чтоб не задавал лишних вопросов.
Когнитивный диссонанс не наступит. Зен динамически переназначает vcpu (виртуальные процессоры виртуалки) на pcpu (physical cpu). Грубо говоря, ядро думает, что это процессор №2, а на самом деле минуту назад он был «процессор №1», а сейчас «процессор №8». А вот если нет свободных процессоров для планирования исполнения vcpu, в этом случае наступает состояние «все в очередь и пусть никто не уйдёт обиженным».
Я пока не могу говорить со 100% уверенностью, но мы не планируем загрузку выше 50-70% на хост для обеспечения резерва по пикам.
Кстати, одна, очень важная особенность: если по какой-то причине процессорное время не было выделено виртуалке, то оно не оплачивается. То есть ситуация «лагающих машин» нам в принципе не выгодна, т.к. заработаем мы на ней меньше.
Я пока не могу говорить со 100% уверенностью, но мы не планируем загрузку выше 50-70% на хост для обеспечения резерва по пикам.
Кстати, одна, очень важная особенность: если по какой-то причине процессорное время не было выделено виртуалке, то оно не оплачивается. То есть ситуация «лагающих машин» нам в принципе не выгодна, т.к. заработаем мы на ней меньше.
А что будет со временем на виртуальной машине, если ей долго не передавалось управление? Есть какой-то механизм синхронизации?
М… Что есть «синхронизация времени»? (На самом деле вы затронули огромной сложности вопрос, потому что в зене есть минимум три разных времени — wallclock, TSC и ещё одно, но я с ходу не соображу куда оно и где). wallclock — это грубо говоря, мировое время. Оно в зене берётся из гипервизора, точнее, из dom0. Другими словами, гостевая система не следит за временем, а когда кто-то спрашивает «сколько времени» ему отвечают настоящим текущим временем.
Есть TSC, это счётчик тиков процессора, который некоторые программы используют в качестве таймера. TSC в этом случае просто транслируется на инструкцию процессора, который считает время независимо от операционной системы.
Ядро на самом деле раз сто в секунду дёргает таймер (ставит алерты) для обновления своих счётчиков и управления ресурсами. Между этими событиями гостевая машина «спит». Когда срабатывает таймер, её будят. В этом смысле домены мало отличаются от обычных процессов в обычной ОС.
Есть TSC, это счётчик тиков процессора, который некоторые программы используют в качестве таймера. TSC в этом случае просто транслируется на инструкцию процессора, который считает время независимо от операционной системы.
Ядро на самом деле раз сто в секунду дёргает таймер (ставит алерты) для обновления своих счётчиков и управления ресурсами. Между этими событиями гостевая машина «спит». Когда срабатывает таймер, её будят. В этом смысле домены мало отличаются от обычных процессов в обычной ОС.
Спасибо, понятно.
Т.е. не получится установить на виртуальной машине произвольную дату?
Т.е. не получится установить на виртуальной машине произвольную дату?
Я немного упростил. wallclock используется как счётчик времени. При этом ядро может иметь своё «базовое» время, то есть можно выставить любую дату, которую съест ядро и продолжить с ним работать.
Собственно, вот проверка:
Собственно, вот проверка:
# date 01010101 Fri Jan 1 01:01:00 MSK 2010 root@vm2172:~# date Fri Jan 1 01:01:04 MSK 2010
У вас там в описании услуги «облако» не сказано, какую операционку можно запустить, а регистрироваться только для выяснения ответа на этот вопрос — неохота. В частности, интересует — можно ли Windows? Из вашего образа? Из своего?
Однако, в реальных условиях современного хостинга, скорость работы процессора так высока, что процессор — наименее востребованный и самый простаивающий ресурс и в 99% случаев конкуренции за ресурсы вообще не возникает.
Слова про 99% верны только на ранних этапах жизни хостинга, а в повседневной жизни это не так. Основную массу клиентов стартующего хостинга составляют новорожденные проекты с низкой посещаемостью — просто из-за того, что размещать новый проект проще, чем переносить существующий проект с другого хостинга. Когда хостинг проживет достаточно долго, чтобы на него стали переходить клиенты других хостеров, достаточно будет 3-5 форумов или магазинов с большими базами и парой тысяч уников в сутки, чтобы они съели весь процессор и начали жестко за него конкурировать.
Слова про 99% верны только на ранних этапах жизни хостинга, а в повседневной жизни это не так. Основную массу клиентов стартующего хостинга составляют новорожденные проекты с низкой посещаемостью — просто из-за того, что размещать новый проект проще, чем переносить существующий проект с другого хостинга. Когда хостинг проживет достаточно долго, чтобы на него стали переходить клиенты других хостеров, достаточно будет 3-5 форумов или магазинов с большими базами и парой тысяч уников в сутки, чтобы они съели весь процессор и начали жестко за него конкурировать.
Я очень уверен, что к этому моменту, если не увеличивать размер пула, будут проблемы с памятью и дисковыми операциями. Я не говорю, что процессор невостребован, я говорю, что он самый маловостребованный ресурс в сравнении с остальными.
Кстати, говорю я это не по наблюдению за облаком, а по опыту работы с VDS, где процессоры простаивают.
Кстати, говорю я это не по наблюдению за облаком, а по опыту работы с VDS, где процессоры простаивают.
С памятью и дисками, безусловно, тоже могут быть. Так как для многих задач вычислительная сложность может снижаться увеличением сложности по памяти, к этому часто прибегают и используют memcached и прочие способы промежуточного кэширования. У таких процессора съедаться будет мало, все будет решаться большим потреблением памяти.
А часто бывает и наоборот: самый легкий способ жечь процессор — это не сайты с большой посещаемостью, а CMS, которые при генерации 1 страницы вместо того, чтобы сохранить в скрипте в переменной какое-нибудь значение, посылают сто sql-запросов в таблицы без индексов. Это зло вечное и неискоренимое.
А часто бывает и наоборот: самый легкий способ жечь процессор — это не сайты с большой посещаемостью, а CMS, которые при генерации 1 страницы вместо того, чтобы сохранить в скрипте в переменной какое-нибудь значение, посылают сто sql-запросов в таблицы без индексов. Это зло вечное и неискоренимое.
SQL-запрос без индексов — это ещё и нагрузка на диск или память. Я ж говорю, остальные ресурсы не такие безграничные, как процессор.
PS Если уж образуется такой VIP-клиент, который будет тратить десятки рублей ежедневно на процессор, то ура, ура, у нас не простаивает процессор. Даже если он будет молотить в 8 ядер на нескольких хостах, оставшуюся память спокойно займут те, кому особо процессор не нужен, а credit scheduler обеспечит им отличную производительность.
PS Если уж образуется такой VIP-клиент, который будет тратить десятки рублей ежедневно на процессор, то ура, ура, у нас не простаивает процессор. Даже если он будет молотить в 8 ядер на нескольких хостах, оставшуюся память спокойно займут те, кому особо процессор не нужен, а credit scheduler обеспечит им отличную производительность.
такой вопрос: почему все клауды оперируют паравиртуализацией, но не hvm-доменами? существуют какие-то ограничения, помимо скорости IO, которые, в принципе, тоже фиксятся? pv-домены проще разворачивать и обслуживать?
и еще один: рассматривали ли kvm для этих целей? и если да, то почему не подошел?
и еще один: рассматривали ли kvm для этих целей? и если да, то почему не подошел?
я правильно понимаю что Xen Cloud Platform опенсурс и бесплатна, то есть кто-угодно может поднять тоже самое?
(адский смех) наконец-то кто-то, кроме меня, пройдёт по всем этим граблям!
Да, разумеется. Более того, я сейчас по чуть-чуть начинаю коммитить в рассылку xen-api с некоторыми изменениями XCP, адаптирующими его под провайдерские нужды (т.к. XCP форк XenServer, который традиционно является enterprise-средой).
Да, разумеется. Более того, я сейчас по чуть-чуть начинаю коммитить в рассылку xen-api с некоторыми изменениями XCP, адаптирующими его под провайдерские нужды (т.к. XCP форк XenServer, который традиционно является enterprise-средой).
а у другой накручивает 30 «часов» за часов десять?
Я так понял, это 3 процессора, загруженные весь астрономический час на 100%?
Почему обязательно три? Это могут быть отдельные всплески нагрузки на всех 8 процессорах с простоями в перерыве. В этом универсальность подхода — не имеет значения, как распределяется нагрузка, важно то, сколько фактически времени были заняты процессоры вычислениями «в пользу» виртуальной машины.
Отличная статья, многие вещи стали более прозрачными. Может на вашем вики ещё это публиковать?
И по последнему графику — сайт выполненный на чем? В целом, по нагрузке и времени работы большая разница между платформами?
И по последнему графику — сайт выполненный на чем? В целом, по нагрузке и времени работы большая разница между платформами?
«Всё, я закончило» первый раз в жизни такое читаю :))
А как в данном случае отличается работа высоконагруженного приложения между виртуальной машиной в облаке и обычной машиной в стойке? Т.е. если образно говоря проц загружен и там, и там на 99%, то масштабируемость какая-то есть в облаке? В том случае, если само приложение умеет работать в многопоточной среде конечно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Об учёте процессорного времени в облаке