Одна из идей, в рамках которой развивается облако Селектел, является максимальная свобода администратора при работе с облачной машиной. Различия с реальным сервером должны быть минимальны, а все новые функции не должны нарушать ощущения «настоящей» машины.

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

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

Исторически так сложилось, что мы предоставляем в аренду выделенные серверы только фиксированых конфигураций. Из-за этого нам не удавалось удовлетворить требования всех пользователей — за время существования услуги мы получили большое количество запросов «добавить памяти», «добавить SSD», «уменьшить количество дисков», «заменить SATA на SAS» и т.п. Например, кому-то нужны были серверы с большим количеством дисков чтобы хранить на нем резервные копии, а кому-то с большим количеством памяти для баз данных.

Сегодня, мы с радостью готовы предложить вам новую услугу «Выделенные серверы произвольной конфигурации». Теперь вы самостоятельно можете сформировать для себя выделенный сервер, который будет в полной мере отвечать вашим потребностям.

abstract: Этот пост описывает организацию системного диска на машинах в облаке и объясняет, почему именно так.

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

Мотивация

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

Вот проблемы, которые возникают в связи с этим:

• Возможность изменить размер диска и корневой файловой системы
• Возможность создать дополнительные разделы
• Возможность подключить диски от одной машине к другой
• С этого диска надо ещё и загрузиться

Наиболее примитивным решением является

Только-только комания Intel официально начала продажи процессоров E5, как мы запустили услугу аренды серверов с этими процессорами.

В качестве первых конфигураций нами были выбраны следующие процессоры: E5-2603, E5-2620 и E5-2630
Доступные конфигурации:

CPU	RAM	HDD	Цена в месяц
2 x Intel Xeon E5-2603 1.8Ghz	16GB	4 x 1TB SATA	13500 руб.
2 x Intel Xeon E5-2620 2.0Ghz	32GB	4 x 1TB SATA	16500 руб.
2 x Intel Xeon E5-2630 2.3Ghz	64GB	2 x 2TB SATA +2 x 160GB SSD	19500 руб.

Оглавление:

• Обновление консоли
• CentOS 5.8
• Исправление ошибки с подключением дисков

Консоль

После того, как мы запустили консоль прошёл почти год. За этот год хром обновился, сменил версию websockets. И консоль осталась рабочей только в Firefox и Opera, обидев заодно и пользователей Mac, у которых основным браузером является Safari (внутри Safari тот же «движок», что и в Хроме — WebKit). Плюс, консоль была не особо быстрой.

Пришло время исправить эту проблему. Компонент под названием selecon-web (это не безграмотность, это сокращение от Selectel Console) был переписан на haskell, в результате чего у нас значительно снизилось потребление процессора, а у пользователей улучшилась скорость работы консоли. Заметим, скорость фактического вывода осталась прежней (т.к. консоль это всё-таки последовательный порт, скорость вывода у него фиксированная, но ускорилось время открытия консоли и время, за которое буква с порта виртуальной машины оказывалась в браузере у клиента).

Summary: Пост рассказывает о том, что такое снапшоты в облаке, как их использовать, и как они устроены.

Одна из самых заметных новых фич в облаке, появившаяся в этом году — снапшоты. Всё, что мы делаем, делится на три категории — то, что полезно нам (биллинг, сервисные утилиты и т. д.), то, что полезно клиентам, но визуально не заметно (например, СХД, смена версий гипервизора, уже ранее запущенных серверов), и то, что полезно клиентам и визуально заметно — и вот снапшоты как раз из этой третьей категории).

Хочу предупредить, что статья будет очень сложная. Я сначала расскажу про простые вещи — как с этим работать и какая от этого польза, а потом расскажу как это устроено внутри. И если с удобством и понятностью на «пользовательском» уровне мы, я надеюсь, справились, то вот с описанием устройства… Так сказать, мужайтесь или пропускайте.

Как использовать снапшоты?

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

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

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

Облако запустили

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

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

• Новая кластерная СХД
• Обновлённые шаблоны виртуальных машин на LVM, упрощающие изменение размеров диска
• Снапшоты
• Улучшенная производительность панели управления

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


(альтернативная ссылка)

Состоит из одной очень длинной серверной, внутри которой находится длинный холодный коридор (2x40 шкафов). Этим он несколько отличается от устройства остальных ДЦ, где коридоров несколько.



На фотографии видно, как мы экономим тепло холод.

Продолжаем цикл экскурсий по Селектелу. На этот раз — дата-центр «Цветочная». Там же находятся наши офисные помещения (то есть мы).

Начнём с видео экскурсии (обратите внимание на кнопку HD сверху):

(альтернативная ссылка)

Серверная

Серверная на Цветочной имеет очень высокий потолок. Благодаря этому там находится довольно значительный объём прохладного воздуха. Наш НЗ, так сказать.

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



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

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

В этом цикле статей мы покажем как выглядят наши ДЦ.

Итак, старейший дата-центр Селектела (с которого компания, собственно, и началась), под кодовым названием »Технодом".

Видео

Небольшая видео-экскурсия:

Серверная

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

(картинки кликабельны)


Традиционно, основным форматом, использующимся для размещения серверов, являются 19" (19 дюймов), их высота измеряется в юнитах (вершках, хе-хе). Сервера плотно монтируются один над другим в специальные шкафы с вертикальными направляющими. Шкафы иногда ещё называют «стойкой». В «Технодоме» используются шкафы 42 U размером (внутренние направляющие имеют высоту 42 юнита, плюс чуть-чуть снизу, плюс чуть-чуть сверху, плюс чуть-чуть с боков на стенки и место для кабелей — то есть фактический размер шкафа больше, чем 1.8 метра в высоту и 48 сантиметров в длину). Реальная полезная нагрузка шкафа несколько меньше, так как туда ещё монтируются розетки (тоже 19"). Размеры самого шкафа: высота 2030, ширина 600 мм. Глубина шкафов разная — на выбор 620, 820 и 1020мм.

(под катом — ещё фотографии серверной, оборудования и людей)

Вступление: Ключевым элементом всех тулстеков для Xen является xenstore — сервис, позволяющий иметь «общую БД» для всех доменов на хосте. Давным-давно существует библиотека libxs для доступа к ней из приложений на Си. К ней есть биндинг на питоне (xen.lowlevel.xs), однако, у него есть очень серьёзные проблемы с многопоточной подпиской на события. Нас это не устраивало и для работы нашего сервиса memory on demand была написана библиотека pyxs, которая позволяет иметь очень комфортную работу с xenstore, многопоточные подписки и т.д.

По здравому размышлению было принято решение отдать её людям под LGPL-лицензией.

Примеры использования

Простое чтение и запись:

from pyxs import Client

xs=Client():
xs["/foobar/a"] = "baz"
print xs["/foobar/a"]

Второй важный класс — это Monitor для организации подписки на множественные изменения, ради которого всё писалось:

from pyxs import Monitor

xs=Monitor():
xs.watch("/local/domain/1")
xs.watch("/local/domain/2")
while true:
    print xs.wait()

Нас разбудит каждый раз, когда что-то поменяется в первом ИЛИ втором пути.

Сссылка на гитхабе: github.com/selectel/pyxs
Документация: pyxs.readthedocs.org

Комментарии проектировщика

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

С первого числа мы закрываем возможность установки новых машин. Новых клиентов мы уже прекратили принимать.

Существующие виртуальные машины существующих клиентов будут обслуживаться далее без изменений. Так же просьба не делать «машины про запас» — мы прекратили приём новых клиентов не от добрых обстоятельств.

Причина — мы перешли границы рассчитанных мощностей, а переписывание архитектуры «на ходу» — ужасная практика. В связи с этим решено взять таймаут и перестать гнаться за отделом рекламы (кстати, по этой причине мы и замолкли на Хабре — надеялись чуть снизить поток приходящих). Однако, люди приходили — и доходило до смешного, в одной из долго и тщательно выписываемых компонент мы закладывались на потолок в приблизительно 10к коннектов. Тестирование/исправление (процесс preproduction) затянулся на месяц… И к моменту, когда мы выкатили эту компоненту, оказалось, что она уже «в притык» (6-9к коннектов в секунду). А ведь писали мы её несколько месяцев!

И стало очевидно, что мы просто не справляемся. Решение о прекращении приёма новых клиентов далось не сильно легко (ну вы понимаете, споры в стиле «а с чего вам зарплату платить?» и т.д.), но здравый технический смысл победил здоровую жадн устремлённость к успеху компании.

Сколько займёт переработка? Планируемый срок — около 2-3 месяцев, сколько реально потребуется — не знаю. Во-первых, потому что придётся серьёзно переделывать архитектуру, централизованные БД окончательно будут удалены; децентрализация всего и вся — задача крайне нетривиальная.

Мы обещали — мы делаем. Видео с 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'а не достаточно для того, чтобы посчитать её всю.

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