Мы обещали — мы делаем. Видео с training course, которое проходило в Санкт-Петербурге в конце июля 2011 года.

Условия от NCC: курс предназначен только для LIR, таким образом, если вы не являетесь сотрудником организации, имеющей статус Local Internet Registry, то вы не имеете права просматривать это видео.

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

dd if=/dev/xvdb of=/dev/null bs=1M count=1000         
1048576000 bytes (1.0 GB) copied, 1.29269 s, 811 MB/s  

dd if=/dev/zero of=/dev/xvdb  bs=1k  count=1000
10240000 bytes (10 MB) copied, 24.3481 s, 421 kB/s

Обескураживающие цифры, правда? При этом если повторить эксперимент, то скорость чтения упадёт, а скорость записи вырастет до положенных 60-150Мб/с.

Причина этого — в copy-on-write режиме работы блочных устройств, обслуживаемых blktap в Xen Cloud Platform.

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

Архитектура

У нас разделены аккаунтинг и биллинг, или, на бюрократическом языке, система автоматического учёта и система автоматического расчёта.

Система автоматического учёта (аккаунтинг) считает, сколько какой компонент виртуальной машины потребил ресурсов. А кому эта виртуальная машина принадлежит, какие деньги брать и т.д. — это не его головная боль. Более того, он даже про слово «облако» ничего не знает.

Работает он очень близко к гипервизору. Например, значения процессорного времени и памяти читаются напрямую из гипервизора, а счётчики дисков и трафика — из счётчиков производительности блочных (сетевых) устройств в dom0.

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

Новости одной строкой:

• поддержка скроллинга в консоли облачных машин
• снятие лимитов памяти в шаблонах
• флаг 'запретить операции' для виртуальных машин

Консоль

Скроллинг

Мы добавили историю вывода на экран. Теперь, «уползший» с экрана текст доступен некоторое время для просмотра. Перемещаться по истории можно кнопками Shft-PgUp, Shift-PgDown. Размер буфера выбран так, чтобы на загрузившейся машине можно было увидеть сообщения до перезагрузки. В дальнейшем появятся ещё дополнения к этой истории. Традиционно, реализация этого функционала — в нашем репозитории на гитхабе. На картинке — история загрузки машины. Виден вывод машины до перезагрузки и первые шаги новой загрузки.


Кстати, раз мы заговорили о консоли, вот несколько интересных возможностей консоли, о которых, возможно, не все знают.

Alt-SysRq

Новость вкратце: С 1 августа мы меняем цены. Значительные изменения: цена исходящего трафика уменьшается с 1 рубля за Гб до 64 копеек за Гб, дисковые операции повышаются с 3 рублей за миллион до 5 рублей за миллион. Остальные цены меняются незначительно, объяснение «зачем» ниже. Кроме того, мы переводим официальные цены с величины «цены за час» на «цену за секунду». Официальные цены приведены в конце статьи, в таблице ниже они даются с дробными копейками и в расчёте «за час» для возможности сравнения со старыми ценами.

Ресурс	Старые цены	Новые цены
Процессорное время	1 рубль за час	↓ 90 копеек за час
Оперативная память	50 копеек за Гб*ч	↑ 57,6 копейки за час
Дисковые операции	3 рубля за миллион	↑ 5 рублей за миллион
Прочитанные/записанные данные	10 копеек за Гб	10 копеек за Гб
Хранение данных	5 рублей за Тб*ч	↓ 4.5 рубля за Тб*ч
Входящий трафик	20 копеек за Гб	↓ 16 копеек за Гб
Исходящий трафик	1 рубль за Гб	↓ 64 копейки за Гб

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

IOPS'ы дороже, трафик дешевле

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

Снижение цены трафика — шаг навстречу крупным клиентам, для которых расходы на исходящий трафик иногда достигают 50% от общих расходов.

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

В этот раз мы публикуем библиотеку сериализации в JSON типов данных Erlang, авторства si14 под BSD 2-clause license. Те проекты, для которых написана эта библиотека, ещё не готовы (ждите анонсов к осени), но библиотека уже стала вполне самостоятельной и может применяться в множестве других случаев. Традиционно, рассчитываем на кооперацию в совершенствовании, с интересом услышим о применении в других проектах.

В дебри Erlang'а

В отличие от многих динамических языков, в Erlang'е есть опциональные аннотации типов для функций и record'ов. На текущий момент они используются минимум 3 утилитами: edoc (формирует документацию из исходников; пример получаемой документации можно увидеть, например, здесь), что более важно, dialyzer (анализирует существующую информацию о типах и сообщает об ошибках несоответствия типов, в том числе несоответствия декларируемого и выведенного типов) и PropEr (система автоматической генерации тестов на основании информации о типах и декларативно задаваемых свойств функций). Использование этих деклараций стало правилом хорошего тона, поэтому почти все качественные проекты на Erlang'е имеют их. Нельзя ли использовать информацию о типах где-либо ещё?

JANE

В процессе разработки одного из проектов возникла идея: почему бы не использовать существующую информацию о типах прямо в JS

Новость одной строкой: клиентам стали доступны графики потребления ресурсов виртуальными машинами в облаке.

История создания

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

Несколько скриншотов этой статистики даже появлялось у нас в блоге.

Мы уже почти были готовы опубликовать её для клиентов, как, вдруг, обнаружился прискорбный факт: при буквально нескольких сотнях машин 8-ядерного Xeon'а не достаточно для того, чтобы посчитать её всю.

Причина была в наивной математике. Источники статистики для каждой виртуальной машины:

Как и было обещано, мы выпускаем под LGPL нашу библиотеку эмуляции эмулятора терминала linux, которую мы используем для показа консолей виртуальных машин в облаке. Называется она, соответственно, pyte (PYthon Terminal Emulator).

По нашим собственным оценкам, покрытие «текстового» функционала console_codes приближается к 100% (от 80 до 90%, как подсказывают пессимисты из числа оппортунистов среди разработчиков).

Не реализованы: коды загрузки шрифтов в знакогенератор VGA-адаптера, управление энергосбережением VESA, звуковая сигнализация (коды управления частотой и длительностью звука), управление палитрой, собственные чарсеты; в общем всё то, что не имеет отношения к тексту.

Зато реализованы все остальные сложные функции, такие, как блокировка регионов экрана для записи, скроллинга, управление режимами переноса строк, правильная обработка атрибутов при различных видов удаления текста и т.д. — всё то, что нужно существующим приложениям, таким как nano, adom (на картинке фрагмент ESC-кодов и получающегося изображения как раз из ADOM'а), vim, emacs, mc, aptitude, dialog, yast2 и т.д. для полноценной отрисовки.

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

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

История создания

RIPE (европейский интернет-регистратор, организация, распределяющая IP-адреса) проводит два обучающих курса в Санкт-Петербурге.

RIPE NCC LIR Training Course

Проходит: 21.07.2011
Место проведения: Санкт-Петербург, в отеле Holiday Inn (адрес см ниже)
Темы:

• The Internet Registry (IR) System
• Exercise: RIPE and the RIPE NCC
• The Policy Development Process
• Exercise: First Day at Work as an LIR Contact
• The RIPE Database
• IPv4 Resources
• Exercise: Making Assignments
• Other Resources: AS Numbers & IPv6
• RIPE NCC Services
• Exercise: Slogan

RIPE NCC IPv6 Training Course

Проходит: 22.07.2011
Место проведения: Санкт-Петербург, в отеле Holiday Inn (там же, адрес ниже)
Темы:

• The Registry System
• IPv4?
• Exercise: Business Case
• IPv6 Basics
• Exercise: Addressing Plan
• Getting it
• Deploying
• Exercise: Deployment Challenges

Расписание и место

Новость одной строкой: теперь клиенты могут изменять параметры MOD из панели управления.

Давным-давно в нашем mod-server'е была реализована возможность управления параметрами выделения памяти. Это было реализовано на уровне самого сервера и параметров базы данных.

… Но этого не было в веб-интерфейсе. Самые настойчивые клиенты просили изменить настройки — и мы их меняли вручную. Глупо, да?

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

Принцип работы Memory-on-Demand

Новость одним абзацем: теперь у всех без исключения наших dedicated серверов (включая Xeon'ы и Atom'ы) есть возможность пользоваться IP-KVM'ом, встроенным в IPMI. Это:

• возможность смотреть консоль (включая графические режимы, биос и т.д.)
• Нажимать всякие хитрые кнопки (Ctrl-Alt-Del, Alt-SysRq, и т.д.) с виртуальной клавиатуры
• возможность подключать ISO как будто это USB-CD, подключенный к серверу
• Аналогично — образы дискет (этим ещё кто-то пользуется?)
• Включать/выключать питание сервера вне зависимости от мнения об этом операционной системы.

История

Бувально в тот момент, когда я (не очень успешно) вычитывал ошибки и опечатки в предыдущем посте, bobry предложил обсудить, как сделать в консоли историю (которая, Shift-PgUp).

Очевидным методом сделать что-то связанное с терминалами — посмотреть, как сделано у других и сделать так же. В процессе изучения этого мы обратили внимание на интересную особенность: некоторые программы, показывая содержимое, восстанавливают экран до запуска приложения (mc, vim, nano, less и т.д.). Кроме того, при их запуске исчезает (в xterm/gnome-terminal) скролл-бар.

Для изучения «каким образом» было решено остановиться на MC, как самом старинном (и не зависящем от ncurses) приложении.

Далее идёт роматичная история о том, как mc делает toggle_panel() с большим количеством цитат из исходного кода.

Заодно, читатель сможет посмотреть, как выглядит процесс «посмотри в исходниках».

            Если посадить тысячу мартышек за тысячу пишущих машинок, то за тысячу лет они напишут эмулятор терминала. — вместо эпиграфа.

Извините фальстарт, это не я, это андроидный смартбук.

Когда мы только запускали облако, первой проблемой было «как нам получить консоль». Штатный механизм XCP поразумевает, что консоль рисуется с помощью VNCTerm, а желающий её увидеть должен сначала пойти в XenAPI, получить там session-id консоли, пойти на порт консоли, передать session-id, получить RFB, завёрнутый в HTTP, развернуть HTTP, вынуть RFB (он же VNC), отдать её локальному рендереру VNC (VNC-клиенту или java-апплету с тем же функционалом). При этом консоль закрывалась (сессия рвалась) при каждой перезагрузке виртуальной машины. Она рвалась даже при миграции виртуальной машины. Другими словами, это была технология, которая подразумевала «глянул одним глазком, починил ssh/iptables и забыл». Неудобно, медленно, сложно. Выкатывать такое в продакт совсем не хотелось.

И я залез в дебри serial-howto, console-howto и ещё несколько ужасных документов, рассказывающих о том, как правильно нужно конфигуриовать прерывания на ISA плате у мультикарт, а так же специфику настройки linux-2.2 для работы с оными. Параллельно изучалось устройство консоли в зене (внимательный читатель мог даже заметить, когда именно я более-менее разобрался в этом вопросе — я писал на хабре краткий обзор того, что происходит с консолью).

После этого пришла мысль: нужно писать своё, потому что готового чужого хорошего нет.

Сначала мы хотели взять хотя бы готовые компоненты и сделать из них своё. Я помню до сих пор ту замечательную схему, в которой мы планировали сохранять в БД вывод anyterm'а, делать двойное туннелирование последовательного порта с использованием UDP… Выглядело это, мягко скажем, неприглядно.

Потом пришла в голову мысль выпилить anyterm. Для этого нужно было посмотреть, как работают терминалки. Это было очень забавно и поучительно (желающие могут изучить исходный текст PuTTY). Главной проблемой в этом изучении было то, что они много рисуют на экран. Прямо в процессе обработки ввода. Отделить специфику DC от, собственно, того, что является консолью, было сложно.

Через некоторое время мы пришли к идее «нам нужен свой эмулятор терминала».
Задача казалась относительно простой, пока мы не прикоснулись к бездне, именуемой «escape-коды и типы терминалов...».

Пишущие машинки

Итак, в начале была пишущая машинка. В какой-то момент возникло желание совместить телеграф с пишущей машинкой. Так возник телетайп
Разумеется, инженерам, создававшим телетайп, не было никакого резона делать все с нуля. Они просто приделали коды к каждой клавише пишущей машинки. После некоторых боёв в стиле MS VS Netscape, был создан стандарт html5 на коды для оных машинок, то бишь телетайпов. Если мне память не изменяет, то это ASCII, где предусмотрены все комбинации клавиш, характерные для американской пишущей машинки. Включая код BELL, который, кстати, должен вовсе не делать BEEP, а делать «дзыньк», ибо у пишущих машинок был именно колокольчик, а не спикер.

Для виртуальных машин в облаке Селектел была добавлена консоль. Она доступна в панели управления во вкладке «консоль».

Вот ключевые отличия от примитивного «вот вам VNCterm, разбирайтесь сами»:

• текстовая консоль — малый трафик
• никаких плагинов (flash/java и т.д.) — работает средствами html/ajax.
• консоль можно смотреть одновременно с нескольких браузеров.
• консоль переживает перезагрузку и миграцию
• консоль можно увидеть на выключенной машине (ввод не работает по понятным причинам — но можно увидеть как машина выключалась).
• Копипейст — выделить мышкой и скопировать, вставка Shift-Ins или Cmd-V для маков.
• Переживает миграцию виртуальной машины без разрывов и неприятностей.
• Автоматическая регуляция скорости работы — при интерактивной работе скорость увеличивается, на простаивающей машине — снижается.
• Практически 100% поддержка linux_console — цвета, скроллинг и т.д. Проверены на работоспособность все основные программы — ncurses-based, mc, vim, emacs, nano, пачка консольных игрушек — adom, nethack, тетрис и т.д. Не поддерживается только экзотика вида «загрузить шрифты», «управление VESA-режимами и т.д.».
• Поддержка большинства комбинаций клавиш (зависит от браузера) — Ctrl-комбинации, Alt-комбинации, функциональные кнопки и т.д.
• Полная поддержка unicode (настолько, насколько его поддерживает ваш браузер), как минмум, псевдографика и русский язык работают без каких-либо проблем.

Чего не сделано:

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

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

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

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

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

Мы отказываемся от размещения модулей ядра на 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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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