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