Когда мы создавали облако, одной из сложных задач было написание биллинга. Мы решили пойти по пути максимального разделения компонент и ослабления связей (weak linking). Благодаря этому весь процесс делится на несколько независимых компонент: сбор информации о потреблении ресурсов компонентами виртуальной машины, хранение этой информации, списание средств со счёта клиентов, хранение истории списания средств (где-то рядом с историей пополнения и выписанными бумажными счет-фактурами и т.д.).

Как можно заметить, есть два больших этапа: сбор информации о потреблении (на этом этапе ещё нет никаких денег, а есть байты, секунды, запросы) и процесс превращения их в деньги (а так же всё с этим связанное — списание, хранение истории).

Вот тизер — недельный график суммарных списаний денег с клиентов:

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

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

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

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

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

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

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

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

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

Итак, месяц с момента начала работы. (Рекламу мы начали несколько позже, но первые клиенты появились как раз месяц назад), появилась возможность посмотреть на первые цифры.

Примерно 47% заказанных клиентами виртуальных машин выключены владельцами. Величина меняется от 38% вечернее время до 58% в ночное.

При анализе статистики я разделил клиентов на две группы — одни реально используют машину в работе, другие — нет (вероятнее всего, это те, кто пришёл «посмотреть»).

Среди реально использующихся самая «дорогая» машина обошлась клиенту в 1138 рублей за месяц, распределение расходов было следующим:

Ресурс	количество	Сумма
Машинное время	158.94 часа	158.94 руб
Оперативная память	304.01 Гб *ч	152 руб
Диск: запросов на чтение	92.016 млн. шт.	276.04 руб.
Диск: запросов на запись	12.641 млн. шт.	37.92 руб.
Диск: прочитанный объём	2167.308 Гб	216.73 руб.
Диск: записанный объём	269.513 Гб	26.95 руб.
Хранение диска	22.110 Тб * час	110.55 руб.
Сеть: получено	54.187 Гб	10.83 руб.
Сеть: отправлено	148.426 Гб	148.42 руб.

Эта машина работает с настройками Debian Squeeze (32), автоматически регулируемая память от 256 до 2048 Мб, диск 30Гб. Судя по загрузке, которую я могу видеть снаружи, вполне себе так работает, процессор показывает загрузку, прыгающую от 10 до 60%, диски шуршат, сеть активна.

Самая дешёвая машина среди «активных» съела примерно 200 рублей (апроксимируем, так как эта машина работает только три недели).

Среди простаивающих машин цифры куда меньше (при примерно таких же настройках). Самая дешёвая машина (видимо, клиент потестил, выключил и решил оставить «на всякий случай») обошлась клиенту в 15 рублей — её выключили в первый день и с тех пор считается там только хранение дисков. Самая дорогая — в 170 рублей (клиент зачем-то сделал диск на 200Гб и периодически включает/выключает. Бэкапы?).

Обещанное этим летом облако Селектела, в котором оплачиваются только потреблённые ресурсы, наконец-то, готово.

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

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

                                                                              (на графике по оси абсцисс логарифмическая шкала)

В ходе обсуждения анонса арендуемых серверов на базе атомов по 1500р возник вопрос, насколько атом более медленный, чем остальные платформы.

Вопрос оказался интересным. Вот результаты тестов. В качестве теста использовался sysbench (он есть во многих дистрибутивах Линукса, в т.ч. в Ubuntu и Squeeze).

В тестах различаются два случая — однопоточная и многопточная нагрузка. Типичная нагрузка на посещаемый веб-сервер — многопоточная. Типичная нагрузка для отдельного однопоточного приложения (например, gzip'а на больших данных) — однопоточная.

Хорошо видно, что атомы существенно проигрывают Core/Xeon процессорам, которые в один поток оказываются в полтора-два раза быстрее, чем атом с двумя ядрами и гипертредингом.

Ещё одно интересное наблюдение — на атоме 32-битный и 64-битный режим показывают себя одинаково, на всех остальных процессорах 64-битная архитектура заметно выигрывает у 32-битной.

В качестве эталонного теста использовался вызов nice -20 sysbench --test=cpu --cpu-max-prime=40000 --num-threads=X run (X — число потоков, от 1 до 16).

Благодаря тому, что Supermicro создала серверные платформы (19", 1U) на базе процессоров Intel Atom, мы смогли создать новый низкий тариф на арендуемые (dedicated) сервера.

Сервер на базе двухъядерного процессора Intel Atom D510 (1,66 ГГц), 2 гигабайта оперативной памяти, 500 гигабайт дискового пространства — за 1500 рублей в месяц.

Сервер с IPMI (и всеми полагающимися в связи с этим плюшками).

Причина, почему атомы в два раза дешевле ближайшей «старшей» платформы (Core 2 Duo, 3000р)?

• Они кушают меньше электричества
• Они меньше греются (меньше нагрузка на кондиционеры, опять же, меньше электричества).
• У них ниже стоимость, а значит, меньше затраты на аммортизацию.

Memory on demand — автоматическое выделение памяти виртуальной машине по необходимости.

Я уже чуть раньше писал об этой идее: Управление памятью гостевой машины в облаке. Тогда это была теория и некоторые наброски с доказательствами, что эта идея сработает.

Сейчас, когда эта технология обрела практическое воплощение, и клиентская и серверная часть готовы и (вроде бы) отлажены, можно поговорить уже не про идею, а про то, как это работает. Как с пользовательской, так и с серверной части. Заодно, поговорим и о том, что получилось не так идеально, как хотелось бы.

Суть технологии memory on demand заключается в предоставлении гостю того количества памяти, которое ему нужно в каждый конкретный момент времени. Изменение объёма памяти происходит автоматически (без необходимости что-то менять в панели управления), на ходу (без перезагрузки) и в очень короткие сроки (порядка секунды и меньше). Если быть точным, выделяется объём памяти, который заняли приложения и ядро гостевой ОС, плюс небольшой объём на кеш.

В ходе отладки облака собралась статистика по потреблению ресурсов инсталляторами различных версий Linux.

Все ОС ставятся полностью автоматом (preseed и kickstart), в минимальной конфигурации с незначительными коррекциями (в частности, openssh-server для дебиана и специальное Xen'овское ядро). Так как собрать статистику «только за установку» не получается, приведена статистика за операцию «установка + первая загрузка».

Установка целиком идёт с репозитория (т.е. сетевой трафик большей частью — это скачивание пакетов).

Показатели:

• процессорное время — реальное время работы процессора. Время установки системы больше, так как во время операций ввода/вывода процессор простаивает. (фактически, это использованные такты процессора, поделенные на частоту)
• потребление памяти — благодаря memory on demand объём выделенной памяти меняется «на лету». Для подсчёта получившегося потребления введена синтетическая величина Гб*ч (1Гб*ч = 1 Гигабайт памяти на 1 час или 512 Мб на 2 часа, или 2Гб на пол-часа)
• Сеть и диск интутитивно понятны. Учитывается как объём, так и количество запросов.

ОС	Процессорное время	Потребление памяти	Запись на диск (Мб, операций)	Чтение с диска (Мб, операций)	Передано в сеть (Мб, пакетов)	Получено из сети (Мб, пакетов)
Debian Lenny i386	2 мин. 39 с	0.065 Гб*ч	1216 Мб, 60657	25 Мб, 3695	1.02 Мб, 19444	130.18 Мб, 91672
Ubuntu Lucid Lynx i386	4 мин. 19 с	0.128 Гб*ч	2324 Мб, 144350	39 Мб, 4430	3.76 Мб, 70887	213 Мб, 154146
Ubuntu Lucid Lynx amd64	3 мин. 39 с	0.563 Гб*ч	2510 Мб, 191514	45 Мб, 4749	4.41 Мб, 83386	214.28 Мб, 155494
Centos 5.4 i386	1 мин 48 с	0.127 Гб*ч	1191 Мб, 153543	137 Мб, 9348	8.65 Мб, 163729	365.39 Мб, 267416
Centos 5.4 amd64	1 мин. 46 с	0.149 Гб*ч	1408 Мб, 185964	139 Мб, 9209	9.01 Мб, 172613	416.75 Мб, 306086

Я не совсем могу объяснить эти результаты (в частности, такая большая разница по времени между ubuntu 32 и 64 бита), однако, центос сильно удивил — время установки у него ощутимо больше, чем у debian, а реальной нагрузки на процессор — меньше.

Пробегал мимо сборочного стола в пятницу, инженеры прикручивали уши к очередной партии оборудования. Не смог удержаться, вот фотографии Extreme Summit X650. Каждый порт — 10Гб. В три раза быстрее SATA2/300, в полтора раза быстрее SATA3/600. Каждый коммутатор в сумме даёт 240 гигабит. Объединяются в стек (фотография кабеля и разъёма под катом).

Два коммутатора дают чуть меньше полутерабита в секунду. SFP'ы ещё не приехали, так что пока там красуются резиновые заглушки. Увы.

Собственно, писать больше нечего, зато можно смотреть (картинки кликабельны).

Сеть дата-центров Selectel объявляет о начале первичного тестирования вычислительного облака (IaaS) на базе Xen Cloud Platform.

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

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

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

В настоящий момент мы поддерживаем два дистрибьютива Linux: Debian и CentOS, поддержка других операционных систем в работе (включая Windows Server).

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

В прошлом топике про СКС меня упрекнули, что нет красивых картинок правильной СКС. Откровенно, мне никогда не удавалось самому сделать красивую серверную, на моей предыдущей работе после меня осталось «гнездо паука» (со стороны СКС, со стороны серверов там более-менее хорошо). С СКС я боролся несколько лет, но так и не одолел. После того, как я перешёл на работу в Селектел и посмотрел на машинный зал, у меня загорелись глаза пофотографировать. Свои ошибки я понял только после того, как посмотрел, как работают монтажники. Всё, стойки, кроме той, что на последней фотографии, оформлял yuhenobi, последнюю Саша Тугов (которого, увы, на хабре нет).

После долгих уговоров начальства, со скрипом, мне таки разрешили пофотографировать.(А, посмотрев на результат, решили перенести в блог компании).

Под катом фотографии из дата-центра Селектела (каждая фотография кликабельна на фулл-сайз) и комментарии.



Обратите внимание: провода перед попаданием в вертикальный толстый пучок, собираются в маленькие жгуты, благодаря этому операция с каждым жгутом может быть выполнена довольно просто: его просто расплести, найти нужный провод, сплести обратно. В данном конкретном случае не планируется провода перекроссировать, так что провода стягиваются очень плотно. Вторая важная вещь, которая достигается за счёт тонких жгутов: до момента, пока жгут не притянут к кабель-органайзеру, он создаёт минимальное сопротивление воздуху (который перегоняется из холодного коридора в горячий вентиляторами стоечных устройств).