Среди всех энтерпрайзнутых систем виртуализации 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 обеспечивающих разные аспекты работы системы.
В начале о системных требованиях:
В этом цикле статей я расскажу о том, как применять 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 обеспечивающих разные аспекты работы системы.
В начале о системных требованиях:
При выполнении задач, связанных с виртуализацией процессов вычислений, обработки данных и кластеризации таковых в единый пул, возникает необходимость плановой, либо экстренной миграции (перемещения) процессов и данных на другие физические носители без потерь. Это возможно при параллельной работе виртуального приложения и формирования виртуальных данных, как минимум, в двух независимых физических носителях. Избыточность данного метода обеспечивает минимальные задержки и минимальные потери, но не позволяет оперативно реагировать на массовые отказы системы, полностью исключая потери. Восстановление работоспособности приложения возможно только через некоторое время, которое может критически сказаться на оперативности принятия решения.
