Возникла у нас следующая задача:

• Есть подготовленный и настроенный в VMware образ виртуальной машины, в нашем конкретном случае FreeBSD 8.1
• Есть виртуальная платформа XCP 1.6 в которой уже крутятся наши виртуальные машинки

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

Это история в двух частях — о новом витке развития automotive. Эта «серия» посвящена собственной разработке EPAM – Aos Connected Vehicle Platform. Алекс Агизим, CTO, Automotive & Embedded Systems, объясняет, чем она отличается от традиционного облачного решения и как дает software-разработчикам доступ в автомобиль. Ознакомиться с первой частью можно здесь.



В первой части я рассказывал, как наши разработки XEN Hypervisor позволяют изолировать сервисную часть автомобильного ПО от safety required software. Это один из барьеров перед широким применением в индустрии. Впервые опенсорсный гипервизор станет полноценным конкурентом закрытым коммерческим решениям.

Но это только первая ступенька. Чтобы вывести автомобильные сервисы на новый уровень, нужно «пустить» в него сервис-компании и разработчиков, далеких от embedded и automotive. Для этого требуется следующий уровень абстракции. Чтобы разработчик пользующийся современными фреймворками в разработке программного обеспечения мог, не переучиваясь, дизайнить свои сервисы для автомобилей.

Возможно, после прочтения вы захотите сказать: «Зачем такие сложности? Я, к примеру, купил Android-планшет для автомобиля, настроил нужные сервисы и вполне счастлив». Это классический инженерный подход, очень поддерживаю. Но давайте посмотрим шире. Автомобильная индустрия с точки зрения software как раз таки давно застряла в классических подходах. Я расскажу, каким ее будущее видим мы и что для этого делаем. А в конце пройдемся по основным сложностям.

Итак.

Вышла новая версия Xen Cloud, версии 0.5. Традиционно для XCP, список новинок и изменений сокрыт во мраке.

На основной странице зена про это ни слова, однако, появилась страница: www.xen.org/products/cloud_source_0.5.html и сообщение от Vern Burke в рассылке.

PS А вот и новый логотипчик XCP:

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

Ядро забирает себе всю свободную память для кеша. Если есть дисковые операции и есть свободная память — кеш будет расти. В случае сервера с единолично пользуемой памятью это благо, однако, если мы говорим о том, что все мегабайты платные, платить за дисковый кеш в 10-20Гб откровенно не хочется.

Я пытался найти возможность ограничить размер дискового кеша для линукса, но всё, что нашёл — это странный патч 2003 года (который, разумеется, в основную ветку не взяли).

Получается, что чем больше гость работает, тем больше его ядро берёт себе памяти от (неограниченного) объёма. Результат — если не ограничивать систему вообще, то она за весьма незначительное время вырастает либо до размера дисковых устройств (спасибо, дискового кеша больше, чем размер диска, не бывает), либо до максимально доступного на платформе объёма памяти. Заметим, что в этих условиях пасуют все технологии — и компрессия памяти, и дедупликация страниц памяти (у каждой ВМ свой кеш). Эта проблема стоит перед любой системой виртуализации. Ниже описываются варианты решения с оглядкой на Xen Cloud Platform.

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

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

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

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

(прошу не ругаться сильно, это размышления перед сном).

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

Протоколы разделили на уровни: физический-канальный, сетевой, транспортный, прикладной. Потом к этой (практически использующейся) модели TCP/IP попытались приделать теоретическую 7-уровневую модель OSI. Не особо прижилось (назовите мне 5 протоколов уровня представления).

Однако, в необходимости отделения перипетий физически-канального уровня и сетевого никто не сомневается. Меняются протоколы, меняется железо, а IP всё тот же…

Примерно то же самое происходит сейчас с вычислительными машинами. Сначала это были универсальные комбайны, которые способны и железо проинициализировать, и графику нарисовать, сервером поработать. Но это дорого. Ярчайший пример — необходимость использовать дискету для установки всё ещё продающегося windows 2003. В 2010 году! Дискету! Почему? Потому, что несчастная ОС вынуждена думать о том, какие у неё там внутри контроллеры и какие у неё там прерывания. И при этом она должна ещё обеспечивать многозадачность, планирование процессорного времени на многопроцессорной системе, планирование дисковых операций и прочие сложные вещи. Ах, да, ещё и права контролировать.

Я продолжаю пристально изучать Xen Cloud Platform и в ходе экспериментов мне удалось создать «призрак»: виртуальную машину, которая (с точки зрения гипервизора) отсутствовала.

Эта виртуальная машина когда-то имела диск, но диск был удалён (и осталась только его кешированная копия в памяти), что, в принципе, не мешало на этот диск писать/читать.

Эта виртуальная машина когда-то имела виртуальный сетевой адаптер, но он был удалён, что в принципе, не мешало отправлять и получать ip-пакеты.

Эта виртуальная машина была — и её не стало. Её не было видно ни на высоком уровне, ни на низком. Её не существовало. Всё осложнялось тем, что я не знал, на каком из серверов облака эта виртуальная работала.

Другими словами, я имел настоящий полноценный призрак. После того, как я перегрузил нужный (лабораторный) сервер, виртуальная машина умерла. Но вопрос остался открытым:

Предыстория

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

Вышла долгожданная версия XCP 1.6

В этой версии:

• live storage (VDI) migration
• live pool migration
• Гипервизор Xen 4
• Open Vswitch 1.4, наконец-таки с поддержкой ipv6
• Официальный антиспуфинг
• Поддержка новых процессоров intel
• Миграция виртуальных машины может осуществляться без гостевых утилит
• Поддержка LACP
• StorageLink для EMC
• Поддержка GPU passthough (доступ к GPU для виртуальных машин)

Ссылка на новую версию: xen.org/download/xcp/index_1.6.0.html

Среди всех энтерпрайзнутых систем виртуализации XCP единственная бесплатная и свободная. История XCP уходит в XenServer, который хоть и основывался на опенсорсном гипервизоре, но был вполне себе платным софтом. Цирикс опубликовала код XenServer под свободной лицензией и с этих пор XenServer начал плавно превращаться в Xen Cloud Platform.

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

С пользовательской точки зрения основным различием между обычным зеном (в составе большинства ОС) и XCP является процесс установки и количество добработок до запуска в продакт. XCP поставляется в виде ISO'шки с готовой ОС для dom0 (CentOS), адаптированной для обслуживания гипервизора и обеспечения работы хостов в облаке. Xen же обычно идёт в виде hypervisor + utils, подразумевается, что всё остальное человек создаст сам. Ещё некоторым бонусом для тех, кому приходится соприкасаться с продукцией Microsoft, являются подписанные драйвера для Windows (их с некоторыми ухищрениями можно установить и в зене, но в XCP они являются родными).

XCP — относительно своеобразная платформа. Она не «закрыта» в том смысле, как закрыт, например, hyper-v, но идёт в виде готовой ОС, многие аспекты конфигурации которой контролируются средствами платформы, а не ОС. Например, сеть: можно повесить ip-адрес на любой интерфейс ifconfig'ом, но последствия этого будут печальные — следует использовать инструментарий платформы для управления сетями и интерфейсами.

XCP состоит из нескольких компонент: xen, xapi, open vswitch, xe cli, stunnel, sqeezed обеспечивающих разные аспекты работы системы.

В начале о системных требованиях:

Предыдущая часть определяла терминологию. Теперь перейдём к обстоятельному объяснению «как это устроено». (тем, кому не терпится «взять и запустить» могут сделать с помощью руководств на сайте xen'а).

В этой части: подробнее про пулы и обзор устройства хостов и чуть-чуть о Xen'е.

Пулы

Весь XCP представляет собой один пул (поддержка нескольких пулов есть в очень отдалённых планах). В принципе, компания может иметь несколько пулов. Если используется разное железо для хостов, то придётся формировать пулы в пределах одинакового железа; в вырожденном случае это означает «один хост — один пул». В такой конфигурации возможность живой миграции отсутствует, а единственной опцией является экспорт/импорт виртуальной машины (медленно и неавтоматически). Соответственно, нужно иметь хотя бы пару одинаковых машин, чтобы получить возможности живой миграции (одинаковых означает «совсем одинаковых», вплоть до степпинга процессора). Чуть раньше возникли вопросы, можно ли в пул собрать разное железо. Официальный ответ: нет. Если очень захотеть, то можно, но все возможно возникшие при этом глюки будут вашими собственными именными граблями.

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

С мастерами следует играться осторожно, именно из-за игр с тем, кто мастер, я и получил ситуацию "Ghost in the Xen" (когда была запущена виртуальная машина, отсутствующая в списке машин облака). Впрочем, со времён XCP 0.1.1 ситуация немного поменялась, и поведение хостов в отстутствии живого мастера стало более разумным.

Четвёртая часть. Предыдущие части: Первая, вторая, третья.

В этой главе: блочные устройства: физические и виртуальные; образы дисков, хранилища.

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

Прежде чем перейти к фактическому описанию, перечислим свойства дисковых устройств:

• Они хранят информацию.
• У них есть свободное место для будущей информации.
• Они не связаны с конкретным компьютером и могут переключаться между компьютерами.
• Они позволяют записывать, читать информацию.
• Они позволяют стирать старую информацию и записывать новую поверх старой.

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

Для виртуализации эти свойства разделены в две группы: первая, связанна с хранением информации. Вторая — связанна с доступом к месту хранения информации.

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

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

Огромнейшая проблема XenServer, как и Xen Cloud Platform, в очень ограниченном количестве документации. Точнее сказать — в полном её отсутствии для нестандартных ситуаций. В частности нигде в официальных источниках мне не удалось найти инструкции по пробросу блочного устройства непосредственно в виртуальную машину.

Для начала зачем это может понадобиться. Простейший пример — у вас есть сервер без надёжного аппаратного RAID контроллера. Но вы хотите рейд. Без проблем — Linux (и XenServer) содержит великолепнейшую штуку — mdadm. А нужен вам этот RAID для файлопомойки, причём файлопомойка займёт всё доступное место. Смысла городить RAID, а поверх него ещё делать XenServer StorageRepository (SR) с type=lvm, в котором создавать один-единственный диск на весь объём нет. Гораздо лучше создать RAID, и пробросить его блочное устройство непосредственно в виртуальную машину. Так и надёжней — в случае чего вы всегда сможете достать жёсткие диски из сервера и воткнуть их в любую Linux машину, которая тут же увидит все ваши данные.

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

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

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

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

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.

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

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

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

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

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

Свершилось то, о чём так долго говорили в рассылке 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

Недавно и я стал обладателем сервера HP ProLiant MicroServer N36L. То, что на нем будет стоять Citrix XenServer, было решено заранее, тем более положительный опыт установки на этот сервер имеет место быть. Задачу установки немного усложняло то, что я был в отпуске. Дома, кроме буков и пары мышек, больше компьютерной техники нет. А для установки хотелось бы иметь клавиатуру, которую можно было принести с работы, и монитор. Проблема с монитором решилась просто, на телевизоре оказался VGA-разъем, дома нашелся кабель для него. Решил попробовать установить XenServer в автоматическом режиме, наблюдая за установкой по телевизору. Так как на сервере отсутствует оптический привод, устанавливать будем с флэшки.