Продолжаем цикл статей, посвящённых учёту ресурсов облака Селектел.

Процессорное время и память обсуждалась в прошлом году, теперь подошла очередь дисков.

С диском связаны три ресурса, каждый из которых учитывается отдельно:

1. хранение дисков
2. объём прочитанного/записанного
3. и количество дисковых операций

Перед тем, как мы обсудим все три ресурса, нужно ещё объяснить одну интересную особенность устройства виртуальных машин — раздельность учёта ресурсов.

Устройство виртуальной машины

Процессорное время (то есть процессор) и оперативная память, о которых мы говорили ранее — это неотъемлемые ресурсы виртуальной машины. Если их нет — нет и самой виртуальной машины. Но можно (хотя и сложно) представить себе виртуальную машину без дисков и/или без сетевых интерфейсов. Кроме того, одни и те же диски можно подключать к разным виртуальным машинам. Таким образом возникает вопрос: а как учитывать диски, которые были сначала у одной машины, потом у другой, а сейчас вообще лежат не подключенными?

Наша ранняя модель учёта подразумевала, что все эти ресурсы относятся на счёт той виртуальной машины, к которой подключены. Но это вызывало массу неоднозначностей, и мы от этой модели отказались, вернувшись к модели, используемой в Xen Cloud Platform. На картинке упрощённая версия этой модели. Синим показано то, что принадлежит пользователю, зелёным — имена объектов, у которых осуществляется учёт.

Продолжаем подробный разбор того, как учитываются ресурсы.

Перед тем, как мы обсудим, как учитывается память, сначала посмотрим, как эта память виртуальной машине выделяется, и что такое вообще «память виртуальной машины».

Реальная память виртуальных машин

Гипервизор Xen, являющийся основой XCP, являющийся основой облака Селектел, контролирует несколько аспектов работы виртуальных машин. Из интересующих нас с точки зрения учёта — процессор и память. Процессор мы обсудили, теперь очередь оперативной памяти.

С точки зрения Xen'а выделение памяти домену (виртуальной машине) означает, что домен имеет право писать в указанную страницу памяти. Попытка домена записать в запрещённую для него страницу памяти вызовет исключительную ситуацию и с большой вероятностью прекращение работы домена, так что ядро гостевой системы тщательно следит за тем, чтобы не выйти за пределы разрешённой памяти (ровно так же, если программа попытается обратиться к несуществующей странице памяти, то ядро программу аварийно завершит или вызовет обработчик ошибок). В любом случае, виртуальной машине разрешено использовать только ту память, которую ей разрешили использовать. Таким образом, Xen всегда точно знает, сколько страниц памяти выделено той или иной виртуальной машине. (Да, минимальная градация учёта памяти — это 4кб кусочек памяти, называющийся «страница»). Я опущу раздел, связанный с трансляциями адресов, поскольку это одна из самых… м… затруднительных областей. Если вкратце — пририсуйте к обычной схеме трансляции виртуальной памяти на i386 ещё две таблицы дескрипторов — получится примерно оно.

Когда домен создаётся (то есть виртуальная машина стартует), программа под названием domain_builder говорит Xen'у, сколько страниц нужно выделить домену. Эту же информацию сообщают ядру гостевой системы, чтобы оно знало, сколько ей памяти выделено.

Внутри виртуальной машины запущен modd (memory on demand dæmon), который посредством xenstore (специфичный для зена метод взаимодействия между доменами) сообщает управляющему сервису о том, в каком состоянии находится память домена. В реальности это просто запись содержимого /proc/meminfo, не более. Сервер смотрит на настройки виртуальной машины и решает, сколько памяти нужно добавить или убрать. И отдаёт команду на изменение памяти.

И вот тут начинается самое интересное. В Xen'е существует понятие передача страниц памяти. Это, в буквальном смысле, означает «взять страницу памяти от одного домена и передать другому». Соответственно, когда отдаётся команда на отдачу/приём памяти, Xen забирает у гостевой системы память, или отдаёт ей эту память. В силу общей (полезной) параноидальности Xen'а, все отдаваемые из домена страницы предварительно обнуляются (чтобы случайно не отдать ценные данные посторонним соседям по виртуализации).

После запуска я получил много вопросов о том, как именно учитываются ресурсы в облаке. Некоторые интуитивно понимают, что такое «час процессорного времени» но есть и те, кто хочет подробного объяснения. Поскольку в общем анонсе подробные объяснения заняли бы много места, я вынес его в отдельный топик. Заодно, такой формат позволит более подробно описать, как Зен и виртуальные машины взаимодействуют. Уровень этого текста научно-популярный, то есть я не буду вдаваться в дебри кольцевых буферов, маскировки событий, «кредитного планировщика» и т.д., вместо этого я попробую рассказать относительно человеческим языком о том, как гипервизор управляет гостевыми машинами.


Что такое «процессорное время»? Сначала мы его хотели назвать более привычным «машинное время», благо, такой термин использовался во времена мейнфреймов, когда идея разделения машинного времени только-только зародилась, но вовремя остановились. Машинное время тех лет подразумевало все ресурсы, которые использовались машиной, а в нашем случае речь идёт именно о процессоре, так как каждый ограниченный ресурс учитывается раздельно.

Итак, что такое «процессорное время» и как может оказаться, что у одной виртуальной машины его насчитывается 4 часа в сутки, а у другой накручивает 30 «часов» за часов десять?

Облако Селектел работает под управлением Xen, точнее, Xen Cloud Platform, в котором гипервизором выступает Xen.

В Xen есть понятие «планировщик доменов». Оставляя в стороне разницу между доменом и виртуальной машиной (домен — запущенная конкретная виртуальная машина, когда виртуальная машина перезагружается, получается новый домен, когда виртуальная машина выключена, домена нет, а сама машина — есть), можно считать, что этот планировщик виртуальных машин. Те, кто знаком с работой современных ОС, наверное уже догадались, что планировщик доменов подозрительно похож на планировщик процессов в этих самых современных ОС.

Как выглядит работа виртуальной машины?

Последняя, заключительная статья цикла о том, как считаются ресурсы облака. Предыдущие: процессор, память, диски.

Учёт интернет-трафика, наверное, самая простая тема из всех. Сколько байт на сетевой интерфейс пришло — такой и входящий трафик. Сколько байт ушло — такой и исходящий.

Необычным, наверное, является только то, что учитывается трафик не на третьем (сетевом) уровне, а на втором (канальном). Никакого сакрального смысла выбор уровня не несёт, просто в используемой технологии наиболее точный и простой учёт осуществляется именно по числу байт, переданных на канальном уровне. С технической точки зрения это учёт переданных байтов через VIF (виртуальный сетевой интерфейс машины). Единственным неприятным побочным эффектом является то, что всякий служебный трафик, такой как исходящие бродкасты, ARP и т.д. так же учитывается. Но, с учётом стоимости трафика (10^-6 рубля за килобайт) я с трудом себе представляю, как можно служебным трафиком намотать хотя бы на копейку.

А положительным аспектом (для нас, а в каком-то смысле и для клиента) является то, что если клиент поднимает тяжёлое приложение на втором уровне (l2tp, PPPoE, ATAoE), то оно посчитается так же, как и любой другой L3 протокол, без необходимости «довить» на клиента и принуждать его к прекращению использования неудобного для учёта протокола, не укладывающегося в модель «считать по IP».

Недавно мой знакомый попросил меня ответить на несколько вопросов по продвижению приложений для Android. Мы договорлись, что я напишу пост. За последний год у меня сложилось определенное впечатление о работе на рынке Android Market. С удовольствием поделюсь своим мнением. Надеюсь, что мой опыт будет полезен разработчикам. Буду рад, если пост породит конструктивную дискуссию.

Написание makefile иногда становится головной болью. Однако, если разобраться, все становится на свои места, и написать мощнейший makefile длиной в 40 строк для сколь угодно большого проекта получается быстро и элегантно.

Внимание! Предполагаются базовые знания утилиты GNU make.

Напишем эту алгоритмическую игру [1] так, чтобы извлечь из неё максимальную образовательную пользу в области алгоритмов, языка Javascript, хорошего стиля программ, умения оптимизировать код. Центральным местом обсуждения будет не игра, а код, способы реализации, оптимизация.

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

Недавно проведённый на Хабре опрос [3] показал реальную картину — 20% программистов написали когда-либо её работающую реализацию, а порядка 10% о ней не слышали. Что ж, тем интереснее будет оставшимся 80% узнать, что можно извлечь из реализации игры.

В прошлом году Дед Мороз подарил мне подержанный алюминиевый iPhone и новенький MiniMac. Не сразу, ох не сразу я распробовал эти девайсы и окунулся в яблочный мир. Сначала iPhone вытеснил Нокии, Моторолы и Самсунги. Ах ты, Господи, совсем забыл. Все мобильные девайсы у меня валяются на рабочем месте и не были куплены за кровно заработанные деньги.

Через месяц-другой iPhone стал опасно родным, его акселерометр и идеальный тачскрин заставили перенести в него любимые авторские игрушки.

Демо тут

… Пару лет назад здесь уже был топик на сходную тему, хочу поделиться своими соображениями…

Одной из проблем, возникающих при написании игры, пространство действия которой содержит больше трех пространственных измерений, является визуализация сцены действия, в достаточной мере понятная пользователю, и пригодная для управления как персонажем (или объектом) игры, так и виртуальной камерой, создающей изображение.
Большинство многомерных игр, которые попадались мне в последнее время, были головоломками — аналогами кубика Рубика. Но для разных размерностей головоломки авторам приходилось использовать различные способы визуализации.

Одно время всплыла тема, что в одной из онлайн-игр появилась такая довольно досадная штука, как каптча. Само по себе, отвлекаться от игры для ввода каптчи может обернуться не слишком хорошими последствиями, особенно, если вводишь её не с первого раза, могут и враги насолить. Но не в этом соль. Особенно плоха вещь для тех, кто использует локальных ботов. Те то, маленькие, спотыкаются об каптчу, и за это игра мнгновенно их штрафует потерей юнитов и ресурсов. Неприятная штука, что говорить.

Итак, задача:
Хочется, чтобы каптчу вводить не приходилось. Хоть если играешь сам, хоть если играет за тебя бот, если ты спишь.
Дополнительное условие: 40 часов времени (ибо паника на корабле).
Желательное условие: установочный файл под Windows.
Ещё одно желательное условие: результат должен занимать не более мегабайта.

Посетителям сайта stackoverflow.com был задан вопрос: «Какие программерские термины вы придумали, так чтобы они стали популярны в ваших кругах (то есть вы слышали, что кто-то их повторяет)?

Ниже — вольный перевод самых популярных ответов.