Среди всех энтерпрайзнутых систем виртуализации 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 обеспечивающих разные аспекты работы системы.
В начале о системных требованиях:
1) Если речь идёт о виртуализации windows (то есть HVM домены), то обязательным условием являются процессоры с поддержкой VT/Pacifica.
2) В случае, если облако планируется более чем с одним сервером, обязательным является использование сетевого хранилища (iscsi или NFS).
3) Хосты (в случае, если их больше одного) должны быть строго одинаковыми — одинаковый степпинг процессора, материнская плата и т.д.
4) Хосты должны находиться в одном канальном сегменте (т.е. быть подключенными через коммутатор, а не через маршрутизатор).
Теперь, собственно, к делу.
(оглавнение)
Хост — сервер, занимающийся виртуализацией.
Пул — объединение одинаковых хостов, позволяющее миграцию.
SR — storage repository — место, где хранятся виртуальные машины (либо локальный винт, либо NFS/ISCSI хранилище). Если быть точным, SR это информация о хранилище. Каждый хост имеет свой PBD (physical block device) осуществляющий подключение хоста к SR. Наличие PBD у SR на каждом хосте — условие для возможности миграции машин.
VDI — virtual disk image, думаю, не требует расшифровки. Может быть либо файлом, либо логическим томом на LVM
VM — виртуальная машина.
VBD — virtual block device — специфичная для XCP конструкция, логическая связь между VDI и блочным устройством внутри виртуальной машины.
network — сеть (точнее, запись о сети). Аналогично SR хосты подключаются к сети с помощью PIF (Physical interface).
VIF — virtual interface — логическая конструкция, связывающая сеть и виртуальную машину. В отличие от VBD, является более «вещественной», её можно увидеть в списке сетевых интерфейсов в тот момент, когда виртуальная машина включена.
vlan — вилан и есть вилан. Если виланы используются, они представляют собой уровень между network и pif (на одном pif может быть несколько виланов, виланы входят в сеть).
Пул — абстракция, объединяющая хосты. У пула есть конфигурация (состояние), которая описывает все (почти все) аспекты конфигурации всего — хостов, пула, сетей, SR'ов, виртуальных машин и т.д. Каждый хост хранит полную реплику состояния, хотя мастером является только один пул. Мастер примерно раз в 15 секунд рассылает изменения по всем ожидающим (это хосты, и, возможно, внешние наблюдатели, использующие XenAPI). Помимо этого, об изменениях конкретных компонент уведомляют «в реальном времени». Мастер может переназначаться на ходу (практически не мешая штатной работе и не оказывая никакого влияния на виртуальные машины). В случае аварии мастера, хосты могут быть переконфигурированы на нового мастера на ходу. Принятие/исключение хоста в пул требует его перезагрузки, кроме того, теряются все виртуальные машины, находившиеся на нём (если машины находились в пуле c несколькими хостами и хранились на внешнем SR, то они останутся доступными для запуска на других хостах пула, если машины хранились локально, они будут уничтожены). Для служебных нужд хосты в пуле можно включать/выключать не выводя их из состава пула (фактически, это просто запрет запускать на них новые машины).
Если хост один, он «сам себе пул». Если хост присоединяется к чужому пулу, то он «забывает» про свой пул и принимает чужой. Хосты в пуле всегда принадлежат одному пулу и ничего не знают о других пулах (т.е. пул всегда один, хоть у него и есть уникальный идентифиатор, но это лишь формальность).
Виртуальные машины бывают двух типов: с аппрататной виртуализацией (HVM) и паравиртуализированные (PV). Паравиртуализированные виртуальные машины всегда предпочтительнее, чем HVM, из-за того, что PV использует специальное ядро, «помогающее» виртуализации и использующее вызовы гипервизора (hypercalls) напрямую, а не через перехват привилегированных инструкций гипервизором (как происходит в HVM). Windows может работать только в HVM-режиме из-за того, что майкрософт не опубликовала код ядра под лицензией, позволяющей адаптировать его для эффективной работы в PV-режиме.
Виртуальная машина в XCP существенно более сложная конструкция, чем домен в обычном зене. Виртуальная машина «существует» даже в выключенном виде. Виртуальная машина имеет массу атрибутов, которые используются для запуска и работы машины (собственно, этот конфиг и есть «виртуальная машина»).
С виртуальной машиной связываются понятия VBD (виртуальное блочное устройство), VIF (виртуальный сетевой адаптер). И диски, и сетевые адаптеры могут быть во множестве (я не тестировал плотно, но 8 шт точно могут быть, а по номерам дозволяется создавать устройства хоть сотнями).
Среди важных особенностей виртуальной машины: квоты памяти, процессора, число разрешённых ядер (от 1 до 16 в текущей конфигурации).
Важная особенность: XCP позволяет изменять количество памяти виртуальной машины на ходу, однако, не позволяет использовать какого-либо рода оверселл (т.е. декларацию виртуальной машине, что памяти больше, чем есть). Максимальное количество памяти, которое можно выделить виртуальным машинам равно виртуальной памяти хоста минус накладные расходы (около 512Мб). Память можно двигать между машинами на ходу, но общее количество нельзя превысить. Каждая машина может иметь свой своп и пользоваться им сколько хочет.
Процессора можно подключать и отключать на ходу (это мухлёж, на самом деле просто разрешаются и/или запрещаются определённые процесссоры к использованию). Не всем программам это нравится (например, atop'у сносит крышу, если процессора тыкаются на ходу). Можно указать квоту виртуальной машины (в процентах машинного времени) и\или приоритет при конкурентном доступе к процессору.
Для особо тонких конфигураций можно выделить виртуальной машине сколько-то ядер (процессоров) в эксклюзивное использование (vcpu pinning).
Сеть — самая сложная область виртуализации. В XCP для реализации виртуальной сети используют open vswitch и технологию open flow. Описание этой технологии сильно за пределами цикла статей, скажу только, что эта технология позволяет вынести «логику» управления коммутатором в виде отдельного приложения. Сеть может быть связана с физическими адаптерами, а может быть чисто виртуальной. К сожалению, чисто виртуальные сети не мигрируют должным образом (для связи между виртуальными машинами, находящимися на разных хостах нужно обязательно использование сети, связанной с коммутатором, хосты соединяющим). Создаваемый виртуальный сетевой адаптер подключается к виртуальной сети. Он может работать как в обычном (unicast) режиме, так и в promiscuous-режиме (слушая весь трафик сети). В принципе, нет ограничений на число сетевых адаптеров виртуальной машины в одной сети. В существующей реализации эта сеть не поддерживает jumbo frames, однако поддерживает offload в управляющий домен подсчёт CRC исходящих фреймов (а при наличии понимающего железа — и обработки TCP-сегментов).
Разумеется, сеть может быть ассоциирована не с физическим адаптером, а с виланом — в этом случае весь трафик сети будет выходить за пределы хоста в транке.
Одной из фундаментальных особенностей XCP является понятие SR — storage repository. SR — это хранилище дисков (VDI) виртуальных машин и ISO'шек (будущих CD-дисков для виртуальных машин). SR бывает двух типов: локальный (ничем не интересен, т.к. по функционалу это обычная локальная шара, раздел диска, каталог и т.д.) и общий (shared). Именно shared SR и является главным инструментом XCP. Облако (точнее, менеджер облака) контролирует, чтобы все хосты имели доступ к SR. Если в облаке с несколько хостов, однократное создание SR автоматически создаст все необходимые коннекторы (PBD — physical block device) для всех хостов и поменяет их конфигурацию так, чтобы хранилище подключалось после перезагрузки автоматически.
Общий SR позволяет осуществлять живую миграцию между машинами, запуск машины на любом (первом попавшемся) хосте, и вообще, является обязательным при эксплуатации в составе облака более одного хоста. В зависимости от SR может предоставляться различная функциональность: copy-on-write, thin provisioning, скоростное клонирование дисков, снапшоты и т.д.
Откровенно, я все типы SR'ов не назову, среди доступных без спец. оборудования — NFS и iSCSI. NFS обладает чуть более экономным использованием дискового пространства, iSCSI быстрее.
PBD — physical Block Device. Абстракция, которой называется метод доступа хоста к месту хранения дисков виртуальных машин (VDI). Это может быть либо NFS-шара, либо iSCSI-шара, либо FC, либо ещё какое-то решение от производителей полок. Главной идеей PBD является универсальность работы PBD вне зависимости от того, на базе чего он сделан (процесс создания и парамеры у каждого типа свои, но после создания все PBD в некоторых рамках предоставляют одно и о же и администрируются едиными средствами). Каждый хост имеет свой PBD для каждого SR, к которому он подключен.
Физический сетевой интерфейс. Служит для соединения хоста с сетью. Чаще всего является реальным сетевым интерфейсом, однако, в случае использования теггированных виланов, является абстракцией, связанной с конкретным виланом. (В этом случае несколько виланов подключаются к одному интерфейсу, а PIF строятся на базе этих виланов). Все PIF'ы входят во внутреннюю сеть хоста, организованную с помощью open vSwitch.
VDI — самая ценная часть виртуальной машины, образ диска (virtual disk image). Располагается он на SR. VDI сам по себе не является свойством виртуальной машины и подключается к ней с помощью VBD (см ниже). VDI бывает нескольких видов, среди которых system (не содержит ценной информации и может корёжиться как угодно) и user (хранящий информацию и подлежащий тщательной охране и заботе). VDI могут образовывать цепочку снапшотов, теоретически уменьшая объём дискового пространства. На практике это не рекомендуется, так как обработка цепочки снижает производительность дисковых операций.
Абстрактное устройство в виртуальной машине. Соединяет диск в виртуальной машине и VDI. С точки зрения внутреннего устройства XCP, VBD — это «драйвер доступа к VDI». Он может быть, его может не быть, на существовании VDI это особо не сказывается. (И, наоборот, VBD без VDI не может существовать). VBD бывает нескольких типов, в частности, он может эмулировать CD-диски (цепляя ISO'шки). При миграции машины VBD пересоздаётся заново, а VDI как лежал на SR, так и остаётся лежать.
Виртуальный сетевой интерфейс, используется для доступа виртуальными машинами в сеть. С точки зрения dom0 vif — ровно такой же интерфейс, как и все остальные, и включается он в тот же виртуальный коммутатор (самих коммутаторов может быть несколько).
С виртуальными машинами связаны метрики — RRD база данных с относительными величинами загрузки по каждому из учитываемых ресурсов (память, диск, процессор, сеть). Метрики отстоят несколько отдельно от всех остальных типов объектов, потому что требуют специального включения (из-за накладных расходов).
(to be continued, далее: миграция, управление памятью, понятие домена, разница между HVM и PV, консоль, подключение ISO, управление процессорами и квотами, дисковые скедулеры, мониторинг, консольные и графические методы управления, API)
Вторая часть (далее)
В этом цикле статей я расскажу о том, как применять 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 обеспечивающих разные аспекты работы системы.
В начале о системных требованиях:
1) Если речь идёт о виртуализации windows (то есть HVM домены), то обязательным условием являются процессоры с поддержкой VT/Pacifica.
2) В случае, если облако планируется более чем с одним сервером, обязательным является использование сетевого хранилища (iscsi или NFS).
3) Хосты (в случае, если их больше одного) должны быть строго одинаковыми — одинаковый степпинг процессора, материнская плата и т.д.
4) Хосты должны находиться в одном канальном сегменте (т.е. быть подключенными через коммутатор, а не через маршрутизатор).
Теперь, собственно, к делу.
Терминология XCP
(оглавнение)
Хост — сервер, занимающийся виртуализацией.
Пул — объединение одинаковых хостов, позволяющее миграцию.
SR — storage repository — место, где хранятся виртуальные машины (либо локальный винт, либо NFS/ISCSI хранилище). Если быть точным, SR это информация о хранилище. Каждый хост имеет свой PBD (physical block device) осуществляющий подключение хоста к SR. Наличие PBD у SR на каждом хосте — условие для возможности миграции машин.
VDI — virtual disk image, думаю, не требует расшифровки. Может быть либо файлом, либо логическим томом на LVM
VM — виртуальная машина.
VBD — virtual block device — специфичная для XCP конструкция, логическая связь между VDI и блочным устройством внутри виртуальной машины.
network — сеть (точнее, запись о сети). Аналогично SR хосты подключаются к сети с помощью PIF (Physical interface).
VIF — virtual interface — логическая конструкция, связывающая сеть и виртуальную машину. В отличие от VBD, является более «вещественной», её можно увидеть в списке сетевых интерфейсов в тот момент, когда виртуальная машина включена.
vlan — вилан и есть вилан. Если виланы используются, они представляют собой уровень между network и pif (на одном pif может быть несколько виланов, виланы входят в сеть).
Пулы
Пул — абстракция, объединяющая хосты. У пула есть конфигурация (состояние), которая описывает все (почти все) аспекты конфигурации всего — хостов, пула, сетей, SR'ов, виртуальных машин и т.д. Каждый хост хранит полную реплику состояния, хотя мастером является только один пул. Мастер примерно раз в 15 секунд рассылает изменения по всем ожидающим (это хосты, и, возможно, внешние наблюдатели, использующие XenAPI). Помимо этого, об изменениях конкретных компонент уведомляют «в реальном времени». Мастер может переназначаться на ходу (практически не мешая штатной работе и не оказывая никакого влияния на виртуальные машины). В случае аварии мастера, хосты могут быть переконфигурированы на нового мастера на ходу. Принятие/исключение хоста в пул требует его перезагрузки, кроме того, теряются все виртуальные машины, находившиеся на нём (если машины находились в пуле c несколькими хостами и хранились на внешнем SR, то они останутся доступными для запуска на других хостах пула, если машины хранились локально, они будут уничтожены). Для служебных нужд хосты в пуле можно включать/выключать не выводя их из состава пула (фактически, это просто запрет запускать на них новые машины).
Если хост один, он «сам себе пул». Если хост присоединяется к чужому пулу, то он «забывает» про свой пул и принимает чужой. Хосты в пуле всегда принадлежат одному пулу и ничего не знают о других пулах (т.е. пул всегда один, хоть у него и есть уникальный идентифиатор, но это лишь формальность).
Виртуальные машины
Виртуальные машины бывают двух типов: с аппрататной виртуализацией (HVM) и паравиртуализированные (PV). Паравиртуализированные виртуальные машины всегда предпочтительнее, чем HVM, из-за того, что PV использует специальное ядро, «помогающее» виртуализации и использующее вызовы гипервизора (hypercalls) напрямую, а не через перехват привилегированных инструкций гипервизором (как происходит в HVM). Windows может работать только в HVM-режиме из-за того, что майкрософт не опубликовала код ядра под лицензией, позволяющей адаптировать его для эффективной работы в PV-режиме.
Виртуальная машина в XCP существенно более сложная конструкция, чем домен в обычном зене. Виртуальная машина «существует» даже в выключенном виде. Виртуальная машина имеет массу атрибутов, которые используются для запуска и работы машины (собственно, этот конфиг и есть «виртуальная машина»).
С виртуальной машиной связываются понятия VBD (виртуальное блочное устройство), VIF (виртуальный сетевой адаптер). И диски, и сетевые адаптеры могут быть во множестве (я не тестировал плотно, но 8 шт точно могут быть, а по номерам дозволяется создавать устройства хоть сотнями).
Среди важных особенностей виртуальной машины: квоты памяти, процессора, число разрешённых ядер (от 1 до 16 в текущей конфигурации).
Важная особенность: XCP позволяет изменять количество памяти виртуальной машины на ходу, однако, не позволяет использовать какого-либо рода оверселл (т.е. декларацию виртуальной машине, что памяти больше, чем есть). Максимальное количество памяти, которое можно выделить виртуальным машинам равно виртуальной памяти хоста минус накладные расходы (около 512Мб). Память можно двигать между машинами на ходу, но общее количество нельзя превысить. Каждая машина может иметь свой своп и пользоваться им сколько хочет.
Процессора можно подключать и отключать на ходу (это мухлёж, на самом деле просто разрешаются и/или запрещаются определённые процесссоры к использованию). Не всем программам это нравится (например, atop'у сносит крышу, если процессора тыкаются на ходу). Можно указать квоту виртуальной машины (в процентах машинного времени) и\или приоритет при конкурентном доступе к процессору.
Для особо тонких конфигураций можно выделить виртуальной машине сколько-то ядер (процессоров) в эксклюзивное использование (vcpu pinning).
Сеть
Сеть — самая сложная область виртуализации. В XCP для реализации виртуальной сети используют open vswitch и технологию open flow. Описание этой технологии сильно за пределами цикла статей, скажу только, что эта технология позволяет вынести «логику» управления коммутатором в виде отдельного приложения. Сеть может быть связана с физическими адаптерами, а может быть чисто виртуальной. К сожалению, чисто виртуальные сети не мигрируют должным образом (для связи между виртуальными машинами, находящимися на разных хостах нужно обязательно использование сети, связанной с коммутатором, хосты соединяющим). Создаваемый виртуальный сетевой адаптер подключается к виртуальной сети. Он может работать как в обычном (unicast) режиме, так и в promiscuous-режиме (слушая весь трафик сети). В принципе, нет ограничений на число сетевых адаптеров виртуальной машины в одной сети. В существующей реализации эта сеть не поддерживает jumbo frames, однако поддерживает offload в управляющий домен подсчёт CRC исходящих фреймов (а при наличии понимающего железа — и обработки TCP-сегментов).
Разумеется, сеть может быть ассоциирована не с физическим адаптером, а с виланом — в этом случае весь трафик сети будет выходить за пределы хоста в транке.
SR
Одной из фундаментальных особенностей XCP является понятие SR — storage repository. SR — это хранилище дисков (VDI) виртуальных машин и ISO'шек (будущих CD-дисков для виртуальных машин). SR бывает двух типов: локальный (ничем не интересен, т.к. по функционалу это обычная локальная шара, раздел диска, каталог и т.д.) и общий (shared). Именно shared SR и является главным инструментом XCP. Облако (точнее, менеджер облака) контролирует, чтобы все хосты имели доступ к SR. Если в облаке с несколько хостов, однократное создание SR автоматически создаст все необходимые коннекторы (PBD — physical block device) для всех хостов и поменяет их конфигурацию так, чтобы хранилище подключалось после перезагрузки автоматически.
Общий SR позволяет осуществлять живую миграцию между машинами, запуск машины на любом (первом попавшемся) хосте, и вообще, является обязательным при эксплуатации в составе облака более одного хоста. В зависимости от SR может предоставляться различная функциональность: copy-on-write, thin provisioning, скоростное клонирование дисков, снапшоты и т.д.
Откровенно, я все типы SR'ов не назову, среди доступных без спец. оборудования — NFS и iSCSI. NFS обладает чуть более экономным использованием дискового пространства, iSCSI быстрее.
PBD
PBD — physical Block Device. Абстракция, которой называется метод доступа хоста к месту хранения дисков виртуальных машин (VDI). Это может быть либо NFS-шара, либо iSCSI-шара, либо FC, либо ещё какое-то решение от производителей полок. Главной идеей PBD является универсальность работы PBD вне зависимости от того, на базе чего он сделан (процесс создания и парамеры у каждого типа свои, но после создания все PBD в некоторых рамках предоставляют одно и о же и администрируются едиными средствами). Каждый хост имеет свой PBD для каждого SR, к которому он подключен.
PIF
Физический сетевой интерфейс. Служит для соединения хоста с сетью. Чаще всего является реальным сетевым интерфейсом, однако, в случае использования теггированных виланов, является абстракцией, связанной с конкретным виланом. (В этом случае несколько виланов подключаются к одному интерфейсу, а PIF строятся на базе этих виланов). Все PIF'ы входят во внутреннюю сеть хоста, организованную с помощью open vSwitch.
VDI
VDI — самая ценная часть виртуальной машины, образ диска (virtual disk image). Располагается он на SR. VDI сам по себе не является свойством виртуальной машины и подключается к ней с помощью VBD (см ниже). VDI бывает нескольких видов, среди которых system (не содержит ценной информации и может корёжиться как угодно) и user (хранящий информацию и подлежащий тщательной охране и заботе). VDI могут образовывать цепочку снапшотов, теоретически уменьшая объём дискового пространства. На практике это не рекомендуется, так как обработка цепочки снижает производительность дисковых операций.
VBD
Абстрактное устройство в виртуальной машине. Соединяет диск в виртуальной машине и VDI. С точки зрения внутреннего устройства XCP, VBD — это «драйвер доступа к VDI». Он может быть, его может не быть, на существовании VDI это особо не сказывается. (И, наоборот, VBD без VDI не может существовать). VBD бывает нескольких типов, в частности, он может эмулировать CD-диски (цепляя ISO'шки). При миграции машины VBD пересоздаётся заново, а VDI как лежал на SR, так и остаётся лежать.
VIF
Виртуальный сетевой интерфейс, используется для доступа виртуальными машинами в сеть. С точки зрения dom0 vif — ровно такой же интерфейс, как и все остальные, и включается он в тот же виртуальный коммутатор (самих коммутаторов может быть несколько).
Метрики
С виртуальными машинами связаны метрики — RRD база данных с относительными величинами загрузки по каждому из учитываемых ресурсов (память, диск, процессор, сеть). Метрики отстоят несколько отдельно от всех остальных типов объектов, потому что требуют специального включения (из-за накладных расходов).
(to be continued, далее: миграция, управление памятью, понятие домена, разница между HVM и PV, консоль, подключение ISO, управление процессорами и квотами, дисковые скедулеры, мониторинг, консольные и графические методы управления, API)
Вторая часть (далее)
