Предыдущая часть определяла терминологию. Теперь перейдём к обстоятельному объяснению «как это устроено». (тем, кому не терпится «взять и запустить» могут сделать с помощью руководств на сайте xen'а).
В этой части: подробнее про пулы и обзор устройства хостов и чуть-чуть о Xen'е.
Весь XCP представляет собой один пул (поддержка нескольких пулов есть в очень отдалённых планах). В принципе, компания может иметь несколько пулов. Если используется разное железо для хостов, то придётся формировать пулы в пределах одинакового железа; в вырожденном случае это означает «один хост — один пул». В такой конфигурации возможность живой миграции отсутствует, а единственной опцией является экспорт/импорт виртуальной машины (медленно и неавтоматически). Соответственно, нужно иметь хотя бы пару одинаковых машин, чтобы получить возможности живой миграции (одинаковых означает «совсем одинаковых», вплоть до степпинга процессора). Чуть раньше возникли вопросы, можно ли в пул собрать разное железо. Официальный ответ: нет. Если очень захотеть, то можно, но все возможно возникшие при этом глюки будут вашими собственными именными граблями.
Каждый хост пула (его устройство обсуждается чуть ниже) имеет полную информацию о состоянии всех машин в пуле (хранит всю базу пула). Выполнять же операции может только один хост, именуемый «мастером пула». Мастер может легко меняться на ходу (без перезагрузки и остановке в работе виртуальных машин), в случае «смерти» мастера его роль может быть перенесена на другой хост силком. Если бывший мастер после этого загрузится, то произойдёт «pool split» — разделение пула на две неравные части, когда бывший мастер считает, что это он мастер, а все остальные подчиняются новому мастеру. Эта проблема легко решается силовой сменой настроек «бывшем мастере».
С мастерами следует играться осторожно, именно из-за игр с тем, кто мастер, я и получил ситуацию "Ghost in the Xen" (когда была запущена виртуальная машина, отсутствующая в списке машин облака). Впрочем, со времён XCP 0.1.1 ситуация немного поменялась, и поведение хостов в отстутствии живого мастера стало более разумным.
Мастер принимает команды и отсылает их слейвам (хосты в пуле, которые не мастера, называются слейвами). Однако, управление пулом можно осуществлять с консоли любого хоста — в этом случае введённые команды просто отправляются на мастера и пользователю показывают результат. Подробнее про управление чуть ниже.
Пул хранит конфигурацию, которая (за некоторыми исключениями) является полностью идентичной для всех хостов. Благодаря этому виртуальная машина может запускаться на любом хосте, хосты неразличимы с точки зрения работы виртуальной машины (именно потому в названии «XCP» фигурирует cloud — платформа позволяет забыть о конкретных машинах и работать просто с множеством эквивалентных кирпичиков).
У хостов всё-таки могут быть особенности на нижележащем уровне, но они тщательно маскируются для вышележащего уровня. Это в основном касается подключения к сети и к хранилищам — PBD и PIF на некоторых хостах могут быть unplugged, то есть не подключенными. Это может быть как административное решение, так и внешняя причина (сломался порт на коммутаторе, iSCSI target отказал в соединении одному из хостов и т.д.). В этом случае происходит следующая ситуация:
Если команда на запуск/миграцию машины отдаётся без указания «где/куда» (просто
Ещё одна интересная особенность — это Load Balancing. Он есть двух типов — родной для XCP и внешний. Родное балансирование нагрузки осуществляется только при включении машины (существует две стратегии поведения: жадная и скромная, жадная запускает машину там, где больше всего ресурсов, а скромная там, где ей хватит ресурсов, то есть старается занимать как можно меньше хостов под выполнение задачи). Внешняя балансировка (обычно с миграцией) отдаётся на откуп пользователю.
Кроме этого, XCP предоставляет механизм DMC (dynamic memory control), механизм, при котором для каждой виртуальной машины задаются границы оперативной памяти, и в случае необходимости XCP может «поджимать» другие машины для предоставления памяти новому соседу. Впрочем, об управлении памятью мы будем говорить много позже.
Полное описание того, как работает виртуализатор Xen'а несколько выходит за рамки планируемого в статьях (если когда-нибудь почувствую себя достаточно гуру в этой области, напишу); пока опишу очень поверхностно как работает сердце XCP — гипервизор Xen. Xen загружается до загрузки ОС и берёт на себя управление процессором, памятью и операциями ввода-вывода. Именно в такой формулировке. В отличие от VMWare, Xen ничего не знает ни о дисковых операциях, ни о сети. Всё, чем он управляет — это прерывания, DMA, память и процессор. Для обеспечения работы с устройствами загружается первая операционная система: (в XCP это CentOS), который получает доступ ко всем физическим устройствам, право командовать гипервизором (именно командовать, она не имеет прямого доступа к другим доменам или памяти гипервизора) и обязанность обслуживать виртуальные устройства для виртуальных машин. Фактически, с точки зрения гипервизора, комаднующая ОС — это всего лишь ещё одна виртуальная машина, не более.
В терминологии Xen запущенная машина называется 'домен'. Важно: уничтожение домена это всего лишь «выключение» виртуальной машины. Иногда домены уничтожаются даже без выключения машины (например, если машина мигрирует с хоста на хост, на принимающем хосте домен создаётся, а на отправляющем — уничтожается).
Командующая ОС называется dom0 (это общепринятый термин и в дальнейшем мы будем использовать только его). Гостевые домены называются domU. В Xen'е есть концепция stubdomain (домены, которым делегирована работа с конкретными железками и предоставление основанных на них виртуальных железок), но в XCP она не используется. Так же, как не используется возможность «пробрасывать» железки в гостевые домены. Всё железо — в dom0. Точка.
Dom0, помимо специально адаптированного ядра, содержит ещё несколько компонент. Это:
Разумеется, кроме этого, есть масса вспомогательного — от yum'а доopenoffice линуксовых компонент для работы с сетью, iscsi, nfs, FC и т.д. Разумеется, среди них ssh-сервер и ntp-сервера.
Кстати, про NTP… Это важнейшая компонента для XCP, поскольку синхронность времени на хостах является жизненно-важным для нормальной миграции машин. Насколько я знаю, эксплуатация XCP без настроенного ntp является крайне чреватой. Источник времени при этом не обязательно иметь «общемировой» — достаточно синхронизироваться с общим источником времени.
При загрузке хоста, загружается Xen, который запускает ядро dom0. Дальнейшая загрузка подробно описана в руководствах по RHEL/CentOS. Все остальные приложения запускаются как обычные демоны. Вся инфраструктура делится на 4 части (это моё личное деление, а не общепринятое):
Теперь о каждой части (кроме первой, надеюсь, центос не вызовет недоумения) подробнее…
Xen'овская часть, хоть и спрятана от пользователя, но всё же присутствует. Есть xenstored, есть набор утилит для работы с XenStore (xenstore-ls, -read, -write, -rm), есть спрятанный в потрохах модуль питона xc, есть xentop и xentrace. Особо о ней думать при нормальной эксплуатации не нужно, вспоминать о ней нужно если вы пилите что-то своё, или если случилось что-то непонятное.
XCP'шная часть — собственно, тема разговора.
xapi предоставляет API, обеспечивает работу http(s) сервера для него, контролирует работу виртуальных машин (в частности, именно xapi осуществляет миграцию), отсылает информацию мастеру и принимает от него команды. Мастер, соответственно, собирает информацию, принимает и отдаёт команды, рассылает изменения по всем хостам. База XCP хранится целиком в памяти, на диск сохраняется её дамп. (Никакие СУБД при этом не используются). xapi написан на OCaml, что любителей ковыряться в исходном тексте может повергать в великое недоумение и растерянность.
Кроме того, каждый xapi на хосте принимает команды от мастера и выполняет их. Это не только команды в отношении виртуальных машин, но и в отношении конфигурации самого хоста — настройки сети, команды перезагрузки/выключения, управление (весьма опосредованное) монтированием блочных устройств и NFS-шар, управление пользователями. Xapi представляет уровень абстракции, позволяющий от терминологии 'eth0 на host-123' перейти к
xapi использует stunnel для организации защищённых соединений между мастером и слейвами и слейвами друг с другом… Так как шифрование — операция не бесплатная, при передаче больших объёмов данных (я пока встречался с этим только при миграции машин, но и там объём передаваемого меньше, чем объём ОЗУ гостевой системы) он может подъедать относительно приличный процент процессора. В принципе, если пул размером этак хостов 10-15, то можно рассчитывать, что xapi+stunnel на мастере будут отъедать почти целиком одно ядро. (Кстати, все dom0 в XCP строго одноядерные). Загрузка слейвов существенно ниже, я больше, чем 25% загрузку xapi создать не смог.
Административная часть представлена сервером консолей (речь о консоли свежеустановленных вируальных машины), примитивной менюшкой на консоли самого хоста (её, если что, можно и через ssh вызывать) и самой мощной системой управления — командной строкой xe. Кроме xe в состав XCP входят ещё пара десятков утилит, каждая из которых применяеся в очень редких случаях. Всё штатное управление идёт через 'xe'.
Особенностью xe является то, что она может работать и не на хосте пула (в частности, есть windows-версия xe). Xe идёт отдельным пакетом, может устанавливаться на любую подходящую машину (хоть на админскую рабочую стацию). Xe подключается к мастеру пула с помощью API и после авторизации позволяет управлять пулом почти так же, как локально.
Помимо консольных утилит есть множество альтернативных вариантов. Это и XenCenter (платная графическая утилита от цитрикса для Windows), и OpenXenManager (кросс-платформенный клон XenCenter на python), и ещё несколько десятков графических оболочек разной степени удобности. Один из соавторов XCP активно пиарит свою версию Xen Cloud Control System, которая поддерживает автоматическую балансировку с миграциями машин (у меня всё руки не доходят посмотреть). Однако, полноценная работа (не вызывающая синдрома WTF) возможна только из командной строки или через API, поскольку любая графическая система вынуждена чуть-чуть упрощать отношения между объектами.
Подробнее об администрировании и API мы будем говорить много позже.
На последок повторю подробнее о том, как соотносятся пулы и хосты.
Хост может относиться к одному и только одному пулу. Если хост один — он сам себе пул. Если хост принимается в «чужой» пул, то он «забывает» о своём пуле и принимает чужой. Мастер, соответственно, никого не забывает, зато принимает чужие хосты, всего лишь добавляя их в данные «своего» пула. Если хост выходит из пула, он достаёт из бэкапа старые данные «своего» пула (внимание: виртуальные машины в таком бэкапе не хранятся, так что считайте, что операция присоединения к пулу и выхода из него деструктивная).
Пул нельзя уничтожить, если выводить из пула машины, то в итоге в пуле останеся один хост, который сам себе мастер. Ему нельзя сказать «убить пул», можно либо принять его в другой пул, либо снести систему.
В следующей части: VBD VDI PBD SR VIF PIF Open vSwitch
В этой части: подробнее про пулы и обзор устройства хостов и чуть-чуть о Xen'е.
Пулы
Весь XCP представляет собой один пул (поддержка нескольких пулов есть в очень отдалённых планах). В принципе, компания может иметь несколько пулов. Если используется разное железо для хостов, то придётся формировать пулы в пределах одинакового железа; в вырожденном случае это означает «один хост — один пул». В такой конфигурации возможность живой миграции отсутствует, а единственной опцией является экспорт/импорт виртуальной машины (медленно и неавтоматически). Соответственно, нужно иметь хотя бы пару одинаковых машин, чтобы получить возможности живой миграции (одинаковых означает «совсем одинаковых», вплоть до степпинга процессора). Чуть раньше возникли вопросы, можно ли в пул собрать разное железо. Официальный ответ: нет. Если очень захотеть, то можно, но все возможно возникшие при этом глюки будут вашими собственными именными граблями.
Каждый хост пула (его устройство обсуждается чуть ниже) имеет полную информацию о состоянии всех машин в пуле (хранит всю базу пула). Выполнять же операции может только один хост, именуемый «мастером пула». Мастер может легко меняться на ходу (без перезагрузки и остановке в работе виртуальных машин), в случае «смерти» мастера его роль может быть перенесена на другой хост силком. Если бывший мастер после этого загрузится, то произойдёт «pool split» — разделение пула на две неравные части, когда бывший мастер считает, что это он мастер, а все остальные подчиняются новому мастеру. Эта проблема легко решается силовой сменой настроек «бывшем мастере».
С мастерами следует играться осторожно, именно из-за игр с тем, кто мастер, я и получил ситуацию "Ghost in the Xen" (когда была запущена виртуальная машина, отсутствующая в списке машин облака). Впрочем, со времён XCP 0.1.1 ситуация немного поменялась, и поведение хостов в отстутствии живого мастера стало более разумным.
Мастер принимает команды и отсылает их слейвам (хосты в пуле, которые не мастера, называются слейвами). Однако, управление пулом можно осуществлять с консоли любого хоста — в этом случае введённые команды просто отправляются на мастера и пользователю показывают результат. Подробнее про управление чуть ниже.
Пул хранит конфигурацию, которая (за некоторыми исключениями) является полностью идентичной для всех хостов. Благодаря этому виртуальная машина может запускаться на любом хосте, хосты неразличимы с точки зрения работы виртуальной машины (именно потому в названии «XCP» фигурирует cloud — платформа позволяет забыть о конкретных машинах и работать просто с множеством эквивалентных кирпичиков).
У хостов всё-таки могут быть особенности на нижележащем уровне, но они тщательно маскируются для вышележащего уровня. Это в основном касается подключения к сети и к хранилищам — PBD и PIF на некоторых хостах могут быть unplugged, то есть не подключенными. Это может быть как административное решение, так и внешняя причина (сломался порт на коммутаторе, iSCSI target отказал в соединении одному из хостов и т.д.). В этом случае происходит следующая ситуация:
Если команда на запуск/миграцию машины отдаётся без указания «где/куда» (просто
xe vm-start, xe host-evacuate), то «неподходящие» хосты игнорируются, а команда отрабатывает с использованием доступых хостов. Если же администратор явно указывает где запускать виртуальную машину, ему могут сказать, что на этом хосте машина не может быть запущена, потому что часть ресурсов хоста не готова. В обычном административном применении нет необходимости указывать точно «где запускать машину» (все машины эквиваленты), так что «полурабочие» хосты не доставляют проблем.Ещё одна интересная особенность — это Load Balancing. Он есть двух типов — родной для XCP и внешний. Родное балансирование нагрузки осуществляется только при включении машины (существует две стратегии поведения: жадная и скромная, жадная запускает машину там, где больше всего ресурсов, а скромная там, где ей хватит ресурсов, то есть старается занимать как можно меньше хостов под выполнение задачи). Внешняя балансировка (обычно с миграцией) отдаётся на откуп пользователю.
Кроме этого, XCP предоставляет механизм DMC (dynamic memory control), механизм, при котором для каждой виртуальной машины задаются границы оперативной памяти, и в случае необходимости XCP может «поджимать» другие машины для предоставления памяти новому соседу. Впрочем, об управлении памятью мы будем говорить много позже.
Устройство хоста
Полное описание того, как работает виртуализатор Xen'а несколько выходит за рамки планируемого в статьях (если когда-нибудь почувствую себя достаточно гуру в этой области, напишу); пока опишу очень поверхностно как работает сердце XCP — гипервизор Xen. Xen загружается до загрузки ОС и берёт на себя управление процессором, памятью и операциями ввода-вывода. Именно в такой формулировке. В отличие от VMWare, Xen ничего не знает ни о дисковых операциях, ни о сети. Всё, чем он управляет — это прерывания, DMA, память и процессор. Для обеспечения работы с устройствами загружается первая операционная система: (в XCP это CentOS), который получает доступ ко всем физическим устройствам, право командовать гипервизором (именно командовать, она не имеет прямого доступа к другим доменам или памяти гипервизора) и обязанность обслуживать виртуальные устройства для виртуальных машин. Фактически, с точки зрения гипервизора, комаднующая ОС — это всего лишь ещё одна виртуальная машина, не более.
В терминологии Xen запущенная машина называется 'домен'. Важно: уничтожение домена это всего лишь «выключение» виртуальной машины. Иногда домены уничтожаются даже без выключения машины (например, если машина мигрирует с хоста на хост, на принимающем хосте домен создаётся, а на отправляющем — уничтожается).
Командующая ОС называется dom0 (это общепринятый термин и в дальнейшем мы будем использовать только его). Гостевые домены называются domU. В Xen'е есть концепция stubdomain (домены, которым делегирована работа с конкретными железками и предоставление основанных на них виртуальных железок), но в XCP она не используется. Так же, как не используется возможность «пробрасывать» железки в гостевые домены. Всё железо — в dom0. Точка.
Dom0, помимо специально адаптированного ядра, содержит ещё несколько компонент. Это:
- xapi — мозг XCP. Основной сервис, командующий гипервизором, осуществляющий миграцию и обрабатывающий вызовы API. xapi в каком-то смысле является аналогом xend в «обычном» зене (в этом и кроется главное архитектурное различие xen'а и XCP).
- обвязка xen по обслуживанию устройств: blktap, xenstore, consoled (мы их обсудим чуть позже)
- open vswitch (аналогично, чуть позже, в кратце — это виртуальный коммутатор для виртуальных сетей).
- squeezed — демон, предоставляющий динамическое регулирование памяти.
- stunnel, обеспечивающий связь между хостами в пуле (я забыл упомянуть, что всё взаимодействие хостов п сети зашифровано? Ну, это как бы подразумевается).
- xsconsole — простенькая ncurses менюшка для управления хостом с помощью меню. Именно он запускается после загрузки хоста
- xe — довольно клёвая консольная утилита с мощным автокомплитом (когда я говорю мощный, я имею в виду действительно мощный), позволяющая сделать с пулом всё, что пул может сделать. Фактически, с небольшим синтаксическим сахаром для удобства работы, полностью покрывает всё XenAPI.
Разумеется, кроме этого, есть масса вспомогательного — от yum'а до
Кстати, про NTP… Это важнейшая компонента для XCP, поскольку синхронность времени на хостах является жизненно-важным для нормальной миграции машин. Насколько я знаю, эксплуатация XCP без настроенного ntp является крайне чреватой. Источник времени при этом не обязательно иметь «общемировой» — достаточно синхронизироваться с общим источником времени.
При загрузке хоста, загружается Xen, который запускает ядро dom0. Дальнейшая загрузка подробно описана в руководствах по RHEL/CentOS. Все остальные приложения запускаются как обычные демоны. Вся инфраструктура делится на 4 части (это моё личное деление, а не общепринятое):
- хост как компьютер (ОС и прикладное ПО)
- Xen и его обвязка
- XCP'шная часть, связанная с работой облака
- административная часть (консольные утилиты, xsconsole, vncterm)
Теперь о каждой части (кроме первой, надеюсь, центос не вызовет недоумения) подробнее…
Xen'овская часть, хоть и спрятана от пользователя, но всё же присутствует. Есть xenstored, есть набор утилит для работы с XenStore (xenstore-ls, -read, -write, -rm), есть спрятанный в потрохах модуль питона xc, есть xentop и xentrace. Особо о ней думать при нормальной эксплуатации не нужно, вспоминать о ней нужно если вы пилите что-то своё, или если случилось что-то непонятное.
XCP'шная часть — собственно, тема разговора.
xapi предоставляет API, обеспечивает работу http(s) сервера для него, контролирует работу виртуальных машин (в частности, именно xapi осуществляет миграцию), отсылает информацию мастеру и принимает от него команды. Мастер, соответственно, собирает информацию, принимает и отдаёт команды, рассылает изменения по всем хостам. База XCP хранится целиком в памяти, на диск сохраняется её дамп. (Никакие СУБД при этом не используются). xapi написан на OCaml, что любителей ковыряться в исходном тексте может повергать в великое недоумение и растерянность.
Кроме того, каждый xapi на хосте принимает команды от мастера и выполняет их. Это не только команды в отношении виртуальных машин, но и в отношении конфигурации самого хоста — настройки сети, команды перезагрузки/выключения, управление (весьма опосредованное) монтированием блочных устройств и NFS-шар, управление пользователями. Xapi представляет уровень абстракции, позволяющий от терминологии 'eth0 на host-123' перейти к
xe pif-param-list uuid=(someuuid), и что самое важное, использовать её с любого хоста, а не с того конкретного, на котором eth0 находится.xapi использует stunnel для организации защищённых соединений между мастером и слейвами и слейвами друг с другом… Так как шифрование — операция не бесплатная, при передаче больших объёмов данных (я пока встречался с этим только при миграции машин, но и там объём передаваемого меньше, чем объём ОЗУ гостевой системы) он может подъедать относительно приличный процент процессора. В принципе, если пул размером этак хостов 10-15, то можно рассчитывать, что xapi+stunnel на мастере будут отъедать почти целиком одно ядро. (Кстати, все dom0 в XCP строго одноядерные). Загрузка слейвов существенно ниже, я больше, чем 25% загрузку xapi создать не смог.
Административная часть представлена сервером консолей (речь о консоли свежеустановленных вируальных машины), примитивной менюшкой на консоли самого хоста (её, если что, можно и через ssh вызывать) и самой мощной системой управления — командной строкой xe. Кроме xe в состав XCP входят ещё пара десятков утилит, каждая из которых применяеся в очень редких случаях. Всё штатное управление идёт через 'xe'.
Особенностью xe является то, что она может работать и не на хосте пула (в частности, есть windows-версия xe). Xe идёт отдельным пакетом, может устанавливаться на любую подходящую машину (хоть на админскую рабочую стацию). Xe подключается к мастеру пула с помощью API и после авторизации позволяет управлять пулом почти так же, как локально.
Помимо консольных утилит есть множество альтернативных вариантов. Это и XenCenter (платная графическая утилита от цитрикса для Windows), и OpenXenManager (кросс-платформенный клон XenCenter на python), и ещё несколько десятков графических оболочек разной степени удобности. Один из соавторов XCP активно пиарит свою версию Xen Cloud Control System, которая поддерживает автоматическую балансировку с миграциями машин (у меня всё руки не доходят посмотреть). Однако, полноценная работа (не вызывающая синдрома WTF) возможна только из командной строки или через API, поскольку любая графическая система вынуждена чуть-чуть упрощать отношения между объектами.
Подробнее об администрировании и API мы будем говорить много позже.
На последок повторю подробнее о том, как соотносятся пулы и хосты.
Хост может относиться к одному и только одному пулу. Если хост один — он сам себе пул. Если хост принимается в «чужой» пул, то он «забывает» о своём пуле и принимает чужой. Мастер, соответственно, никого не забывает, зато принимает чужие хосты, всего лишь добавляя их в данные «своего» пула. Если хост выходит из пула, он достаёт из бэкапа старые данные «своего» пула (внимание: виртуальные машины в таком бэкапе не хранятся, так что считайте, что операция присоединения к пулу и выхода из него деструктивная).
Пул нельзя уничтожить, если выводить из пула машины, то в итоге в пуле останеся один хост, который сам себе мастер. Ему нельзя сказать «убить пул», можно либо принять его в другой пул, либо снести систему.
В следующей части: VBD VDI PBD SR VIF PIF Open vSwitch
