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

scope: начинающие системные администраторы, помощники системных администраторов и т.д. Опытным администраторам, а так же тем, кто имеет вполне конкретную специализацию будет если и интересно, то бесполезно.

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

Какие бывают системные администраторы?

Одна из проблем, которая нас преследует — мы слишком много времени уделяем абстрактным (внутренним) аспектам работы. Прошедшие месяцы мы интенсивно работали — но клиенты практически не видели результатов работы, т.к. переписывались и адаптировались к высоким нагрузкам (в тысячи операций в секунду) внутренние компоненты облака.

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

Реальной работы — два часа в панельке, ещё несколько часов на проверку, что всё работает как положено. Но — не хватало времени и рук. Наконец, нашлось время, сделали.

Как это сделать?

Извините за долгое молчание — много работы, грядут большие обновления. А пока немного о не очень крупном, но весьма заметном для наших клиентов изменении.

Мы отказываемся от размещения модулей ядра на NFS. (И не только модулей, но клиенты заметят именно смену места хранения модулей).

Как это должно было работать

Виртуальные машины клиентов грузятся с использованием наших ядер (то есть код ядра хранится за пределами виртуальной машины). Ядрам нужны модули в процессе работы. /lib/modules подмонтирована по NFS, ядро само определяет из какого каталога грузить какие модули, нам легко их обновлять, клиенту легко получать доступ.

Как это оказалось

Во-первых, NFS-шары монтируются позже инициализации сети (это очевидно) и после монтирования всех остальных строчек в fstab. Ещё круче — в семействе debian/ubuntu они по-умолчанию монтируются асихнронно, так, что получается race condition с запуском rc.local.

Итог: pre-up скрипты на интерфейсах работают не так, как ожидалось, нестандартные файловые системы из fstab не монтируются как положено. Дополнительно, NFS не самый надёжный сервис (особенно с учётом бага #538000), другими словами, неудобно.

Как эту проблему решили

Модули теперь находятся на ISO'шке, подключенной ко всем виртуальным машинам в виде отдельного диска /dev/xvdp. Модули монтируются сразу же после монтирования рута ('/') и позволяют легко выполнять все последующие операции (pre-up скрипты, нестандартные файловые системы и т.д.).

Строчка монтирования (fstab) у всех выглядит одинаково:

/dev/xvdp /lib/modules iso9660 ro 0 0

Кстати, этот диск клиентами не оплачивается.

Сначала немного жёлтого:

Удостоверяющий центр Comodo Internet Security (их корневой сертификат объявлен заслуживающим доверия большинством производителей браузеров) подписало следующие сертификаты для неизвестных мошенников:

* mail.google.com, www.google.com
* login.yahoo.com (3шт)
* login.skype.com
* addons.mozilla.org
* login.live.com

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

Теперь подробнее. Эти сертификаты были выпущены, после чего началась подковёрная буча, производители браузеров (как минимум хром и файрфокс) внесли их в black list (вкомпиленный в код). Для firefox'а это произошло 17ого марта 2011 года, все версии, вышедшие до этого момента будут доверять этим сертификатам (я хотел было написать «подвержены уязвимости», но проблема в том, что это не уязвимость, это распиз… ство Comodo, которому почему-то все вынужены доверять). В теории, должна осуществляться проверка на то, не входит ли сертификат в список отзыва (его туда внесли), однако, на практике, если доступ к этому списку ограничен, то браузеры не выдают внятных предупреждений и доверяют сертификату.

Ссылки:

1) Пресс-релиз comodo: www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
2) Secity Advisory от MS: www.microsoft.com/technet/security/advisory/2524375.mspx
3) Детективная история о том, как обнаружили «странное» в патчах в firefox'е до офицального обнародования результатов беспечности Comodo: blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion
4) О политической составляющей произошедшего: avva.livejournal.com/2321707.html

Свершилось то, о чём так долго говорили в рассылке xen-api — вышла версия 1.0 Xen Cloud Platform.

Ключевые изменения:

• Обновление версии ядра (у зена это всегда очень специфичный топик)
• Поддержка blktap2
• Поддержка Bexar (точнее, наоборот, Bexar поддерживает XCP)
• Поддержка RDAC mulipath на уровне XAPI
• Локальное кеширование данных сетевых хранилищ
• Управляемые автобэкапы машин
• Загрузка хостов с сетевых хранилищ (требуется соответствующий HBA)

От себя добавлю (что заметил нового при ковырянии с RC-версиями):

• Thin provision на LVM (включая iscsiolvm)
• Поддержка pure virtual networks между хостами (маршрутизация трафика через GRE-инкапсуляцию)
• xapi наконец-таки стало устанавливаться как RPM-пакеты, а не как помойка blob-кода в /opt.
• Существенная переработка документации

Запись в блоге Xen'а: blog.xen.org/index.php/2011/03/03/xcp-1-0-released
Ссылка на страницу загрузки: www.xen.org/download/xcp/index_1.0.0.html

В статье разбирается принцип работы xvc0 как с точки зрения domU, так и с точки зрения dom0, а так же описывается, что с этой консолью делают дальше.
Сразу предупреждаю, топик интересен только тем, кто с Xen'ом плотно работает.

Консоль с точки зрения Xen'a

Консоль и XenStore — два устройства в виртуальной машине, которые не анонсируются через XenStore, а пишутся в святую святых — start info page домена. Штатным механизмом для всех остальных устройств является их анонс в XenStore. Понятно, что анонсировать XenStore в XenStore несколько неудобно, так что это устройство «должно быть с самого начала».

Консоль можно было бы поместить в список «обычных» устройств. Но его вынесли в особый класс и сделали «равным XenStore» ради удобства отладки и диагностики. Чем раньше ядро сможет писать на консоль (и мы сможем это читать), тем больше вероятность, что информации на консоли будет достаточно для определения причины поломки.

На самом-самом низком уровне консоль использует кольцевой буфер, причём размером в одну страницу памяти (4кб для i386/x86_64). Этот кольцевой буфер поделен в соотношении 1024/2048, первая половинка используется для ввода (буфер для «нажатых» кнопок), вторая для вывода (символы и esc-коды, которые выводятся на экран).

Один из вопросов, возникающих при создании сервиса (в данном случае не важно, облака или VDS) — это то, как создавать клиентские машины.

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


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

Как всё начиналось...

Когда облако только-только обретало первые черты, возникла задача автоматизации создания виртуальных машин. Разумеется, первым решением, лежащим на поверхности, было «взять и склонировать». Благо, все делов там — одна команда (xe vm-clone). Дальше была необходимость поправить настройки сети, имя хоста и пароль рута. Всей работы — на пол-дня. Ладно, два дня вместе с ловлей блох.

Сделали? Сделали. К счастью, эту версию не увидели даже бета-тестеры.

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

В блоге зена анонсировали переезд нестабильной ветки XCP на github.

Чтобы понять значимость этого события, нужно понять историю Xen Cloud Platform. Компания Xensource, основанная автором Xen'а развивала опенсорсную версию гипервизора и две независимые ветви его «обвязки»: xend и xapi. Xend шёл под свободной лицензией (и входит в состав большинства дистрибутивов), а xapi был «сердцем» платной (и весьма дорогой) платформы для виртуализации XenServer. Через некоторое время покупки Xensource Citrix'ом была опуликована опенсорсная версия xapi (GPL), лёгшая в основу Xen Cloud Platform.

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

И вот, переезд на github с первыми коммитами со стороны не сотрудников цитрикс. Собственно, именно в этот момент XCP становится по-настоящему открытой платформой для построения облачных систем.

Ключевые отличия xapi по сравнению с xend'ом:

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

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

Предыстория

В ходе разворачивания стенда для экспериментов из нескольких идентичных серверов захотелось иметь возможность запускать нужные версии приложения без ручной работы по обновлению кода на куче хостов. Было решено запускать нужные программы с NFS-шары. Приложения были internal use only, одноразовые, причём написанные под конкретную задачу. Шара монтировалась в каталог /opt при загрузке и приложения оттуда запускались с помощью скрипта rc.local. Поскольку речь шла про экспериментальный стенд с очень частым изменением кода, играть в честного разработчика (пакеты, репозиторий, обновления, init.d скрипты) было лениво. Всё происходило под Debian Squeeze.

Шара была прописана в /etc/fstab, запуск нужных тестов — в rc.local. Казалось бы, всё сделано.

… И тут я наткнулся на Мистику. Приложения стартовали раз из пяти, причём версия «кривое приложение» была отметена почти сразу — ровно так же иногда не запускались любые другие исполняемые файлы. Причём, с /opt. Из других каталогов отрабатывали нормально. При этом руками rc.local запускаешь — 100% всё хорошо. При загрузке — успешный запуск раз из пяти, или даже реже.

В начале я не воспринимал эту проблему как серьёзную, и пытался её решить нахрапом. Поскольку проблема проявлялась только для /opt я дописал в rc.local команду ls -a1 /opt >/var/log/ls. Как и предполагалось, в /opt на момент выполнения rc.local было только два файла — точка и две точки. Другими словами, NFS-шара не подмонтировалась. Иногда. А иногда подмонтировалась.

Увы, моя вера в человечество оказалась слишком наивной. Когда мы планировали интерфейс облака, предполагалось, что человек не особо вникающий в нюансы, при создании виртуальной машины, оставит настройки по-умолчанию (в частности, автоматически сгенерированный пароль), а человек меняющий настройки, понимает что он делает. Увы, для части клиентов это оказалось не так.

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

Причина? Ну, я думаю, вы догадываетесь. Пароль 323345 — это просто насмешка какая-то. И таких случаев было несколько.

Люди, которые считают, что злые хаккеры их не достанут, потому что «да кому я там нужен» совершенно правы. Никто специально не будет сидеть и подбирать вашу хитрую перестановку из qwerty и 123. Для этого давно созданы специализированные программы, которым, поверьте, глубочайшим образом всё равно, какой изощрённой мыслью вы руководствовались, делая пароль из пяти единиц и одной двойки, размещая двойку именно на третьей позиции (не догадаются же!). Не догадаются. Просто снесут брутфорсом с -цатой попытки. А нужны им не ваши персональные секреты — а ваши ресурсы. Для рассылки спама, перебора пароля к нужным сайтам, для работы в качестве открытого прокси. Для чего ломанная машина с хорошим инетом пригодится всегда найдётся…

Тут живут драконы и нет ментейнеров (вместо эпиграфа)

Очень сжатое боевое описание «что есть псевдо-терминал» и «консоль».

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

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

Как легко понять по кабелю, есть два конца: терминал и то, что ему посылает байтики в кабель.

Когда запускается шелл, то он получает в своё распоряжение виртуальное устройство /dev/tty, которое у каждого процесса своё — это «обратная» часть терминала. Передняя часть в случае кабеля реализуется путти+компьютер, в случае консоли компьютера, специализированным ядерным драйвером (виртуальными консолями). Важно: драйвер эмулирует наличие терминала.

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

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

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

Серию официальных постов в блоге компании про то, как работать с облаком я ещё продолжу, но параллельно мне хочется рассказать про те проблемы, с которыми мы столкнулись во время адаптации Xen Cloud Platform под нашу модель работы облака. Эти посты будут чуток сложнее и предполагают, что читатель хотя бы в общих чертах знает, как работает Xen.

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

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

Выглядит эта информация примерно так (вывод биндинга xencontrol для питона):

{
    'paused': 0, 
    'cpu_time': 1038829778010L, 
    'ssidref': 0, 
    'hvm': 0, 
    'shutdown_reason': 0, 
    'dying': 0, 
    'mem_kb': 262144L, 
    'domid': 3, 
    'max_vcpu_id': 7, 
    'crashed': 0, 
    'running': 0, 
    'maxmem_kb': 943684L, 
    'shutdown': 0, 
    'online_vcpus': 8, 
    'handle': [148, 37, 12, 110, 141, 24, 149, 226, 8, 104, 198, 5, 239, 16, 20, 25], 
    'blocked': 1
}

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

Казалось бы «бери и считай», однако, дьявол кроется в деталях…

Извините за жёлтый заголовок ниже, но именно так звучал вопрос в полемике в ходе обсуждения одной из проблем:

Hyper-threading + Xen = воровство денег у клиентов

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

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

Необычным, наверное, является только то, что учитывается трафик не на третьем (сетевом) уровне, а на втором (канальном). Никакого сакрального смысла выбор уровня не несёт, просто в используемой технологии наиболее точный и простой учёт осуществляется именно по числу байт, переданных на канальном уровне. С технической точки зрения это учёт переданных байтов через 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Гб и периодически включает/выключает. Бэкапы?).

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

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

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