Когда хост XenServer установлен, он может управляться непосредственно через доступ безопасной оболочки (SSH, Secure SHell) к интерфейсу командной строки (CLI). Кроме того, XenServer может также управляться с применением XenCenter, графического интерфейса на базе Windows для визуализации и видеотерминального доступа к одному или более хостов (Рисунок 2-2).

 

Рисунок 2-2 Управление XenServer через командную строку или графически

XenCenter предоставляет богатый пользовательский опыт для управления множеством хостов XenServer, пулами ресурсов, а также инфраструктурой виртуальных машин связанных с ними. В то время как прочие инструменты с открытым исходным кодом и выпускаемые на коммерческой основе существуют для управления XenServer, XenCenter специально разрабатывается параллельно с каждой редакцией XenServer. XenCenter принимает пользовательские полномочия и затем взаимодействует с XenServer применяя XenAPI.

XenCenter разрабатывается обратно совместимым с наследуемыми версиями XenServer, что означает, что практический опыт всегда используется в самых последних доступных XenCenter. Если вам необходима определённая версия XenCenter, которая поставляется с программным обеспечением XenServer установленым на данном хосте, вы можете получить её открыв веб- браузер и введя IP адрес вашего хоста XenServer.

Процессы ядра XenServer являются тем, что отличает XenServer от прочих дистрибутивов на основе Xen, или от прочих возможно существующих реализаций dom0. Каждый из последующих процессов либо реализует ключевую функцию XenServer, ответственную за его масштабируемость, или является критически важным для его безопасности.

XAPI является интерфейсом инструментального стека ядра и раскрывает API управления Xen. Он отвечает за координацию всей работы по всему окружению XenServer и взаимодействует напрямую с большинством критичных компонентов.

XAPI также отвечает на запросы HTTP по порту 80 для предоставления доступа к выгрузке установщика XenCenter.

Относящиеся к XAPI данные журнала могут быть найдены либо в /var/log/xensource.log, либо в /var/log/audit.log. Эти журналы в особенности существенны, когда инструменты администрирования, такие как XenCenter, применяют XAPI для управления инфраструктурой XenServer.

	Документация XAPI
	XAPI и его API, а также API управления Xen документированы на сайте http://xapi-project.github.io/.

xhad является демоном высокой доступности (HA, High Availability) XenServer. Он автоматически запускается если хост XenServer находится в пуле, в котором включена высокая доступность (HA). Этот процесс отвечает за всю активность задающих тактов (heartbeat) и обмен информацией задающих тактов с прочими серверами- участниками для определения того, какой из хостов определённо отказал согласно отказу таймера сторожевого устройства (watchdog) и последующему ограждению (fencing) хоста. {Прим. пер.: подробнее об ограждении см. в наших переводах статьи pve.proxmox.com/wiki/Fencing и Главы 5 Построение кластеров высокой доступности Linux для профи. Сандер ван Вуг, Apress, 2014}.

	Высокая доступность
	Настоятельно рекомендуется чтобы развёртывание XenServer, применяющее HA, имело по крайней мере три хоста XenServer в пределах настроек пула. Хотя и возможно разрешить HA с двумя хостами, приоритеность задающих тактов будет определяться на основе единственного идентификатора хоста XenServer.

Поскольку XAPI является критическим компонентом работы, xhad выполняется как сторожевое устройство (watchdog) XAPI при включённом HA. Если выясняется, что XAPI отказал, xhad перезапустит его. HA всегда должен настраиваться командами XAPI, а получающиеся в результате настройки сохраняются на каждом хосте в /etc/xensource/xhad.conf.

Существенные для xhad данные журнала могут быть найдены в /var/log/xha.log.

Демон операций Xen, xenopsd (Xen Operations daemon), ответственен за управление жизнедеятельностью гостевой ВМ при предоставлении разделения между процессами управления (XAPI) и виртуализации (Xen). Как только гостевая ВМ создаётся или запускается, порождается процесс xenopsd: он отвечает за управление задачами нижнего уровня для этой гостевой ВМ, такие как манипуляция ресурсами и сбор статистики использования ресурса для dom0.

Существенные для xenopsd данные журнала могут быть найдены в /var/log/xensource.log.

xcp-rrdd является демоном, который разработан для приёма и подстановки данных карусельным (round-robin) образом, которые хранятся в циклической (round-robin) базе данных. Этот демон получает метрики от xenopsd в зависимости от используемого гостевой ВМ ресурса. Примерами подобных статистик являются дисковые IOPS, загрузка ЦПУ, а также использование сетевых ресурсов. Когда применяется технология NVIDIA GRID GPU или сквозного пропуска (pass-through) vGPU, также собираются метрики и для этих рабочих нагрузок. Данная информация в последствии распространяется назад к администратору - по запросу, например, из XenCenter - для просмотра как текущей производительности так и исторических данных о ней для гостевых ВМ.

Существенные для xcp-rrdd данные могут быть найдены в обоих журналах /var/log/xcp-rrdd-plugins.log и /var/log/xensource.log.

Этот демон за мониторинг и отчёты по сетевым интерфейсам XenServer, например для сетевой среды с виртуальными мостами.

SM является менеджером хранения (storage manager) и отвечает за отображение поддерживаемых решений хранений в XAPI в качестве репозиториев хранения, подключения виртуальных устройств хранения к репозиторям хранения, а также для обработки операций хранения подобных миграции хранилищ и снимков.

Существенные для менеджера хранения данные журнала могут быть найдены в /var/log/SMlog.

perfmon является демоном, который отслеживает производительность и статистики dom0.

mpathalert отправляет уведомления XenServer или другому интерфейсу управления, опрашивающему сообщения для XAPI когда возникают задачи хранения относящиеся ко множеству путей. Это полезный инструмент для определения проблем сетевой среды для определённых типов систем хранения, а также предотвращать единые точки отказа, например, когда один путь упал и не возвращается назад в рабочее состояние.

Существенные для mpathalert данные журнала могут быть найдены в /var/log/daemon.log и /var/log/messages.

Демон snapwatchd отвечает за вызов , мониторинг и ведение журналов для процессов, связанных со снимками ВМ. Информация, подобная состоянию виртуального диска поддерживается синхронной, позволяя XAPI отслеживать любые изменения для диска гостевой ВМ или связанных снимков.

Существенные для snapwatchd данные журнала могут быть найдены в /var/log/SMlog.

stunnel, или безопасный туннель (secure tunnel), применяется для шифрования различных форм обмена между действительными или виртуальными точками с применением Open SSL. Соединения клиента с гостевыми ВМ, например, такие как vncterm доступ через XenCenter, усиливает stunnel чтобы гарантировать, что такие типы сеансов сохраняются раздельными и безопасными.

Существенные для stunnel данные могут быть найдены в журналах /var/log/secure и /var/log/xensource.log.

Запись и регистрация активности на основе консоли, включая гостевые и управляющие консоли, обрабатываеются xenconsoled.

Существенные для xenconsoled данные могут быть найдены в журналах /var/log/xen/ и /var/log/daemon.log.

Демон xenstored является базой данных, которая расположена на dom0. Он предоставляет операции нижнего уровня, такие как виртуалная память, совместно применяемая память, а также интерфейсы XenBus для общих операций ввода/ вывода. XenBus предоставляет абстрактную шину устройства, аналогичную PCI, которая делает возможным взаимодействие между гостевыми ВМ и dom0. Драйверы устройств взаимодейтсвуют с базой данных настроек xenstored для выполнения действий устройства, таких как "poweroff" "reboot" являющихся результатом работы ВМ.

Существенные для xenstored данные могут быть найдены в журналах /var/log/xenstored-access.log и /var/log/xensource.log.

squeezed является процессом dom0, ответственным за управление динамической памятью в XenServer. XAPI вызывает squeezed чтобы определить, может ли быть запущена гостевая ВМ. И наоборот, squeezed отвечает за взаимодействие с каждой выполняемой гостевой ВМ чтобы гарантировать ей достаточный объём памяти, а также может возвращать память хоста, XenServer, который должен потенциально столкнуться с перерасходом памяти хоста.

Существенные для squeezed данные могут быть найдены в журналах /var/log/xensource.log и /var/log/xenstored-access.log, а также, в зависимости от версии XenServer, /var/log/squeezed.log .

В процессе запуска dom0 использует сценарии init и XAPI для подтверждения своей настройки. Это гарантирует, что XenServer может вернуться к известному правильному состоянию настройки с последующим после выхода из строя хоста, например, после перезагрузки или восстановления из- за потери электропитания. Если файлы настроек Linux изменялись администратором вручную, для XAPI не будет необычным переписаать эти изменения данными из своей базы данных настроек.

	Изменение критически важных файлов настройки
	В данном разделе книги файлы и каталоги приводятся исключительно для целей администрирования. Если не предписано иное, не модифицируйте и не изменяйте эти каталоги и/ или их содержимое.

В случае отказа при грубой проверке настроек на здравый смысл, для обеспечения безопасного режима dom0 загрузится в режим обслуживания (maintenance), а ВМ не будут запущены. Если это произойдёт, потребуется административное вмешательство для разрешения проблемы и приведения хоста назад в рабочее состояние. Такой режим гарантирует рабочеспособную систему и проверяет целостность физического хоста, данных виртуальной машины и связанного хранилища.

XenServer 6.5 применяет в качестве начального загрузчика extlinux: производную проекта Syslinux, специально ориентированную на загрузку ядер, хранимых в файловых системах на основе EXT. Пример 2-1 отображает настройку по умолчанию загрузки такого ядра.

Такой файл настройки предоставляет инструкции на основе соглашения о метках, согласно которому настройка ядра должна быть загружена с дополнительными параметрами после включения электропитания физического оборудования. Метка по умолчанию (или определение ядра) применяемое для загрузки XenServer всегда снабжается флажком под меткой xe.

label xe
   # XenServer
   kernel mboot.c32
   append /boot/xen.gz mem=1024G dom0_max_vcpus=2
   dom0_mem=2048M,max:2048M watchdog_timeout=300
   lowmem_emergency_pool=1M crashkernel=64M@32M
   cpuid_mask_xsave_eax=0 console=vga vga=mode-0x0311
   --- /boot/vmlinuz-2.6-xen root=LABEL=rootenhlwylk ro
   xencons=hvc console=hvc0 console=tty0 quiet vga=785 splash
   --- /boot/initrd-2.6-xen.img
 	   

Дополнительно также предлагаются настройки ядра для доступа последовательной консоли, или xe, а также безопасное ядро, или safe, показанные в Пример 2-2. Доступ к ним может быть выполнен при выполнении последовательности начальной загрузки посредством входа в menu.c32 при получении приглашения на ввод boot: prompt.

label xe-serial
   # XenServer (Serial)
   kernel mboot.c32
   append /boot/xen.gz com1=115200,8n1 console=com1,vga
   mem=1024G dom0_max_vcpus=2 dom0_mem=2048M,max:2048M
   watchdog_timeout=300 lowmem_emergency_pool=1M
   crashkernel=64M@32M cpuid_mask_xsave_eax=0 ---
   /boot/vmlinuz-2.6-xen root=LABEL=root-enhlwylk ro
   console=tty0 xencons=hvc console=hvc0 ---
   /boot/initrd-2.6-xen.img

label safe
   # XenServer in Safe Mode
   kernel mboot.c32
   append /boot/xen.gz nosmp noreboot noirqbalance acpi=off
   noapic mem=1024G dom0_max_vcpus=2 dom0_mem=2048M,max:2048M
   com1=115200,8n1 console=com1,vga ---
   /boot/vmlinuz-2.6-xen nousb root=LABEL=root-enhlwylk ro
   console=tty0 xencons=hvc console=hvc0 ---
   /boot/initrd-2.6-xen.img
 	   

	Изменения Dundee
	Предварительный выпуск XenServer Dundee применяет в качестве загрузчика GRUB2.

Файл hosts заполняется специальным образом таким образом, что определённый процесс dom0 мог разрешить любую из следующих записей в пределах файла hosts:

Приводимая ниже команда позволяет вам просмотр содержимого файла hosts:

# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain
 	   

Файл hostname содержит индивидуальное имя для данного хоста, которое определяется в процессе установки. Этот файл существенен только для управляющего домена пока он не записан в рамках инфраструктуры DNS (Domain Name Service).

В качестве примера hostname может быть xenified01 и храниться в /etc/hostname:

# cat /etc/hostname
xenified01
 	   

Однако, в XenCenter этот хост получает дружественное имя, например, XENHOST1 для целей визуализации, как показано на Рисунке 2-3.

 

Рисунок 2-3 Имя хоста может оставаться тем же самым при отображении дружественного имени в пределах XenCenter

Многие устройства хранения предлагают для хоста подобного XenServer возможность усиления множеством путей или каналов ввода/ вывода для целей хранения. XenServer поддерживает настройки хранения которые применяют множество путей. такая поддержка предоставляется средством отображения множества путей устройств (DM-MP, device mapper multipathing), а информация о настройке сохраняется в /etc/multipath.conf. Файл /etc/multipath.conf по умолчанию охватывает широкий диапазон современных устройств хранения, гарантируя, что XenServer хост может применять для хранилища избыточность, отказоустойчивость, а также агрегацию для поддержки решений хранения.

	Не изменяйте multipath.conf не имея руководства
	Хотя dom0 может выглядеть как стандартный дистрибутив CentOS, изменение /etc/multipath.conf в соответствии с примерами Linux, найденными в интернете, может легко неблагоприятно воздействовать на стабильность и производительность системы. Всегда изменяйте /etc/multipath.conf под руководством технической поддержки Citrix или своего производителя аппаратных средств.

Файл resolve.conf содержит записи DNS для XenServer, котрые были определены в процессе установки (обсуждается в Главе 3), а также изменяться в XenCenter или командой XAPI. Хотя этот файл может быть изменён вручную в случае устранения проблемы с разрешением имени, при перезагрузке настройка XAPI перезапишет любые выполненные в этом файле изменения с целью поддержки верных установок сервера DNS, настроенных через XenCenter или при помощи инструмента командной строки xe.

Для содействия соединению использующих технологию на основе iSCSI хранилищ установлен Open-iSCSI. В процессе установки вырабатывается уникальный iSCSI Qualified Name (IQN) для каждого хоста XenServer, и сохраняется, в каждом хосте XenServer, в /etc/iscsi/initiatorname.iscsi.

Когда администратор пытается ограничить функциональность хранилища iSCSI для определённого хоста, его IQN может быть определён в хосте XenServer как это показано в Примере 2-3.

# cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1994-05.com.redhat:dc785c10706
 	   

Вывод предоставляет IQN и может он затем быть добавлен в белый список инициатора на устройстве хранения. Если выполнена переустановка XenServer, это значение будет изменено и все хосты iSCSI потребуют обновления своих белых списков на новое, вырабатываемое случайным образом, IQN.

По линии стандартных соглашений Linux многие файлы "настроек" связаны с Xen, XenServer и прочими процессами ядра XAPI хранимыми здесь. Большая часть этих файлов вырабатывается при установке, обновляясь из инструментов на основе Xen, а также в некоторых случаях создаваемых когда администратор XenServer делает доступной определённую функциональность.

boot_time_cpus

Заполняется при каждой загрузке и содержит иформацию, относящуюся к сокетам физического хоста и числу ядер в сокете. Для пользователей Linux это может показаться аналогичным сбросу cpuinfo, который может быть обнаружен в /proc/ выполняющейся файловой системы. Примере 2-4 отображает команду для просмотра содержимого файла boot_time_cpus. Эта информация не только сохраняется в этом файле, но также известна dom0. И наоборот, база данных XAPI обновляется этой информацией и распространяется в одноранговой сети в которой данный хост является участником пула XenServer.

 

Пример 2-4. Просмотр boot_time_cpus

# cat /etc/xensource/boot_time_cpus
 	   

Чтобы сравнить точность этого файла относительно /proc/ в файловой системе на основе Linux для dom0 (заполняемого при выполнении), исполните команду приведённую в Примере 2-5.

 

Пример 2-5. Проверка информации для ЦПУ и её точности

# diff /etc/xensource/boot_time_cpus /proc/cpuinfo
 	   

В обычном случае вывод должен отсутствовать или, что то же самое, нет разницы между /proc/cpuinfo и /etc/xensource/boot_time_cpus. Поскольку приводимое вырабатывается dom0 после загрузки хоста и начала выполнения ядром Xen своего процесса загрузки, любая разница между этими файлами будет определять существенное нарушение настройки.

 

/etc/xensource/bugtool/

Каталог bugtool имеет несколько подкаталогов и файлов XML, которые определяют сферу, атрибуты и пределы для вывода данных относящихся к встроенному инструментарию XenServer определения ошибок. Эти файлы определяют инструментам максимальный размер вывода и прочие критерии необходимые для дампа ядра при его крахе (или отчётов о состоянии сервера) для доступа, продвижения и хранения данных, необходимых при условиях возникновения ошибок.

 

/etc/xensource/db.conf

Этот файл совместно со слегка более длинной версией с именем db.conf.rio описывает следующую информацию настройки базы данных XenServer:

• Где найти базу данных XAPI

• Формат, необходимый для применения, при чтении этой базы данных

• Вменяемая информация относящаяся к использованию сеанса и обоснованности

 

/etc/xensource/installed-repos/

Каталог installed-repos содержит подкаталоги, которые, либо из новой установки, или из обновления, отображают список применявшихся при установке репозиториев для этого хоста. Если установлены дополнительные пакеты, они также будут отображены в installed-repos; а в процессе обновления вы будете уведомлены о присутствии такого дополнительного пакета. Это гарантирует то, что если установка зависит от определённого дополнительного пакета в процессе установки администратор сможет проверить и получить соответствующую замену.

 

/etc/xensource/master.d/

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

	Изменения Dundee
	XenServer Dundee имеет домен управления на базе CentOS 7. CentOS 7 имеет изменённую модель systemd для инициализации. эта модель отличается в основном тем, как выполняются сценарии уровня инициализации. Если у вас установлены агенты управления или пользовательские сценарии, пожалуйста, проверьте их, они могут не работать в среде systemd, поскольку они были сделаны ранее.

 

/etc/xensource/network.conf

Файл network.conf описывает для администратора какой тип сетевой среды коммутации применяется хостом XenServer. Пример 2-6 показывает команду для просмотра этого файла. Существует два синтаксических параметра: bridge или openvswitch. bridge соответствует наследуемому из Linux мосту сетевой среды, в то время как openvswitch соответствует Open Virtual Switch или ovs. Сетевой средой по умолчанию является ovs, применяемая для всех установок начиная с XenServer 6.0, однако, если обновляется более ранняя система, то всё ещё на месте может оказаться мост Linux. Важно отметить, что новая сетевая функциональность будет разрабатываться только для ovs, в то время, как в некоторый момент мост Linux может быть отправлен в оставку.

 

Пример 2-6. Просмотр network.conf

# cat /etc/xensource/network.conf
 	   

Вывод будет либо состоянием "bridge", либо "openvswitch", но это мощная часть информации, которую необходимо иметь - в особенности при диагностике проблем пула XenServer с виртуальной сетевой средой коммутации или если есть вопросы к "лежащей в основе сетевой среде". Более того, существуют некоторые сторонние продукты Citrix, которые могут потребовать чтобы эта виртуальная сетевая среда коммутации была того или другого типа. Если вы определили, что некоторый хост требует необходимости переключения виртуальной сетевой среды коммутации, обеспечьте останов всех гостевых машин (или миграцию на другой хост XenServer) и выполните команду, приведённую в Примере 2-7.

 

Пример 2-7. Изменение основы сетевой среды

# xe-switch-network-backend {bridge | openvswitch}
 	   

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

 

/etc/xensource/pool.conf

Другой ключевой файл для поиска неисправностей, pool.conf применяется в случае, когда хост является изолированным сервером, главой пула (master, инваче: основным, primary), или ведомым (slave, участником пула, предоставляющим отчёты главному XenServer). Этот файл может иметь два значения: master или slave.

Применяя команду cat, как проиллюстрировано в Примере 2-8, можно определить из содержимого pool.conf полагает ли хост XenServer себя участником master или slave.

 

Пример 2-8. Определение роли хоста

# cat /etc/xensource/pool.conf
 	   

Если результат команды master, то хост играет роль главы пула. Если результат команды содержит слово slave, хост является сервером участником, а также предоставляется IP адрес главы (master) пула. При работе в качестве стандартного хоста XenServer (т.е. когда он не является совсем частью пула), обособленный хост будет полагать, что он выполняет роль master.

Этот файл следует изменять вручную только в случае серъёзных разрушений, причём только под руководством команды поддержки XenServer. Примеры подобных разрушений включают:

• Разрешена высокая доступность (HA) в случае, когда она должна быть отключена, например, в случае обслуживания

• Проблемы во взаимодействии в сетевой среде межу участниками пула

• Выход за пределы памяти dom0

• Возбуждаемые латентностью при выборе нового главы (master) пула

• Доступная целиком только для чтения корневая файловая система

• Устаревший или доступный только для чтения файл PID

 

/etc/xensource/ptoken

Файл ptoken применяется для безопасности, наряду с SSL, в пулах XenServer для дополнительной безопасности во взаимодействиях участников пула.

 

/etc/xensource/scripts/

Каталог scripts содержит один или более сценариев уровня инициализации, во многом аналогично каталогу master.d.

 

/etc/xensouce/xapi-ssl.conf

XenAPI выставляется через порт 433, однако необходима соответствующая аутентификация для выполнения API или запроса к нему. В добавление к аутентификации необходим обмен сертификатом личного (private) ключа для подтверждения источнику защищать дальнейшее взаимодействие к- и от- XenServer через шифрование на основе SSL. Именно здесь принимает участие xapi-ssl.conf, так как он диктует шифр, метод шифрования и место хранения уникального сертификата XenServer.

 

/etc/xensouce/xapi-ssl.pem

xapi-ssl.pem является личным (private) ключом, который вырабатывается при установке /etc/init.d/xapissl, ссылющимся на xapi-ssl.conf для производства уникального файла PEM (Privacy-Enhanced Mail) хоста XenServer. Этот файл является тем, что наряду с двухфакторной аутентификацией, осуществляет обмен между хостами XenServer, инструментами администрирования XenServer и т.п., чтобы обеспечить обратную и прямую безопасную связь с уникальным определённым хостом XenServer.

Замена файла xapi-ssl.pem на подписываемый самостоятельно или подписанный сертификат обсуждается в Главе 12.

 

/etc/ntp.conf

В нашей практике это вероятно наиболее важный из всех файлов настройки, который системный администратор может свободно изменять в любое время. Однако это также связано с тем, что любое решение для виртуализации должно обеспечивать синхронизацию всех гостевых ВМ. Файл настройки протокола сетевого времени (Network Time Protocol) - используемый ntpd - никогда не должен ссылаться на виртуальную машину, а всегда обязан ссылаться на локальную, физическую машину, причём число записей не должно быть более четырёх.

Хотя любое решение виртуализации будет предпринимать все возможные меры по выравниванию дрейфа времени, если часы аппаратных средств испытывают сильное отставание/ убегание по времени, это может влиять на расписания, а также в конечном итоге приводить к отключению гостевых ВМ. Жизненно важно настроить /etc/ntp.conf должным образом, в соответствии с зоной времени с тем, чтобы хост мог соответствующим образом обновлять гостевые ВМ и их внутренние часы. Дополнительно, если хосты XenServer составляют пул, дрейф по времени между хостами должен быть сведён к минимуму, а установки NTP должны быть идентичными у всех участников пула.

 

/var/xapi/

Данный каталог содержит полную базу данных XAPI, которая является ссылкой на используемое оборудование в рамках обособленной установки XenServer или при установке в пуле.

	Информация состояния системы
	В пределах каталога /var/xapi/ файлы содержат информацию состояния и никогда не должны исправляться вручную ни при каких обстоятельствах. В случае изменения может понижаться производительность виртуализации, так как база данных XAPI основывается на совместных оборудовании, объектах и зависимостях для виртуализации гостевых ВМ.

 

/var/patch/ и /var/patch/applied/

Эти два каталога - /var/patch/ и /var/patch/applied/ - чрезвычайно важны, потому что на пару они содержат отпечатки горячих исправлений, заплаток и прочих метаданных поддержки, которые являются существенными для XAPI. Вне зависимости от того, есть ли у вас работающий обособленно или в пуле XenServer, XAPI должен иметь средство, гарантирующее что приводимая ниже последовательность успешно выполняется:

1. Исправления применены к работающему обособленно хосту.

2. Исправления применены ко всем работающем в пуле хостам.

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

Теперь, когда оба каталога содержат файлы с уникальными именами файлов на базе UUID, стоит отметить, что более важным каталогом является /var/patch/applied/, потому что, как это следует из его названия, он содержит минимальный набор изменений, которые должны применяться к хосту.

Этот каталог - /var/patch/applied/ - никогда не следует удалять, так как он используется XAPI для проверки того, нуждаются ли члены пула в их применении, существуют ли новые горячие изменения, доступные для вашего хоста XenServer и тому подобного. Таким образом, удаление этих файлов может привести к некорректному отслеживанию хостом необходимых ему изменений.

 Взаимосвязь объектов XenServer

  Объекты сетевой среды

Исходя из проекции архитектуры, развёртывание XenServer состоит из трёх типов сетевой среды: обмена основного управления, хранения и ВМ. По умолчанию сетевая среда во всех установках XenServer автоматически назначается на первый доступный сетевой интерфейс и этот сетевой интерфейс становится сетевой средой основного управления. Хотя все дополнительные сетевые интерфейсы могут применяться для систем хранения или ВМ, а также могут агрегироваться для избыточности и потенциального повышения пропускной способности, сетевая среда основного управления (primary-management network) является ключевой так как она отвечает за:

• Предоставление доступа администратору через инструменты аутентификации, такие как XenCenter

• Осуществляет поддержку коммуникационных связей между хостами XenServer в пуле

• Договаривается о миграция ВМ в реальном времени

• Раскрывает XAPI для стороннего инструментария

Понимание взаимосвязей между сетевыми объектами XenServer является критически важным для соответствующего определения сетевой топологии при развёртывании XenServer.

	Планирование для множества пулов
	Хотя мы в этой книге сосредоточены на разработке и управлении единственным пулом XenServer, если ваши потребности навязывают вам множество пулов, вам следует учесть это в своём проекте. Это в частности верно для инфраструктуры, которая может совместно использоваться пулами, например, сетевая среда и системы хранения. Подробности по этим предметам вы можете найти в Главе 5.

 

pif

Объект pif обозначает физическое сетевое оборудование, наблюдаемое в рамках dom0. Так как dom0 основывается на CentOS, сетевая среда по умолчанию будет помечена как "eth0" и будет назначена на IP адрес хоста XenServer. Все дополнительные сетевые среды будут представлены в виде "ethX", однако только физические интерфейсы с ролями "управления" или "хранения" будут иметь назначенные IP адреса. Перечень физических сетевых интерфейсов может быть получен в командной строке, как это показано в Примере 2-9.

 

Пример 2-9. Какие интерфейсы настроены на хосте

# xe pif-list params=all
 	   

 

Сетевая среда

Поскольку XenServer обычно размещает много виртуальных машин, которые необходимо соединять с сетевой средой, создаётся виртуальная система коммутации. Каждая система коммутации объединяет мостами все хосты в пуле ресурсов XenServer и реализуется с применением Open Virtual Switch, или ovs. {Прим. пер.: подробнее см. раздел Open vSwitch в нашем переводе книги Изучение построения сетей Docker, Радждип Дуа, Вайбхав Кохли, Сантош Кумар Кондури, Packt Pub., февраль 2016.} Число содержащихся в среде XenServer виртуальных коммутаторов будет изменяться и может быть очень динамичным. Перечень всех сетевых сред может быть получен в командной строке, как это отображено в Примере 2-10.

 

Пример 2-10. Какие сетевые среды настроены для хоста

# xe network-list params=all
 	   

Логическое соединение между network и pif устанавливается в поле PIF-uuids.

 

vif

Каждая ВМ в среде XenServer обычно имеет по крайней мере один подключённый к ней виртуальный NIC. Все такие виртуальные NIC называются vif и подключаются к сетевой среде коммутации. Всем vif XenServer -ом назначаются MAC адреса. Часто сетевые администраторы ищут имеющие идентификатор производителя MAC виртуальные NIC, чтобы впоследствии фильтровать их. Поскольку XenSerer был разработан для обработки количества ВМ, идентификатор производителя универсально администрируемого MAC адреса будет искуственно ограничивать предел построения виртуальных сетей, поэтому XenServer применяет локальное администрирование ВМ во избежание потенциальных противоречий MAC адресов.

Получаемый vif IP адрес устанавливается гостем и взаимодействует с XenServer через интерфейс в инструментах XenServer. Поскольку сетевая среда коммутации реализует виртуальный коммутатор, каждый vif подключается к network, которая в конечном итоге подключается к pif представляющему физический NIC который затем подключается к физическому коммутатору. Перечень виртуальных сетевых интерфейсов может быть найден с применением командной строки, показанной в Примере 2-11.

 

Пример 2-11. Текущая настройка сетевой среды настроены для всех ВМ в пуле

# xe vif-list params=all
 	   

 

Связывание

В качестве необязательного действия, администраторы могут настраивать отказоустойчивые элементы, называемые "bond". Связывание (bonding) NIC, также называемое объединением в группы ("teaming"), является методом, с помощью которого два или более NIC объединяются для создания некоего логического NIC. Дополнительные сведения о связывании можно почерпнуть в разделе Определение топологий сетевой среды. Список всех сгруппированных сетевых сред может быть определён с помощью командной строки показанной в Примере 2-12

 

Пример 2-12. Определение текущей настройки связывания

# xe bond-list params=all
 	   

Если определено группирование, все элементы настройки "master", "slaves" и "primary-slave" ссылаются на объект pif.

  Объекты GPU

XenServer поддерживает использование графических карт с ВМ. Физическая графическая плата может быть напрямую назначена ВМ; а для определённых чипов NVIDIA и Intel, физическая карта также может быть виртуализирована (использоваться как виртуальное устройство). Это позволяет совместно использовать через виртуальные GPU возможности одной карты.

 

pGPU

Физическое графическое процессорное устройство (pGPU, physical graphical processor unit), является объектом, который представляет собой физическую видео карту, или механизм графики, которая установлена на материнской плате или является устройством PCI в физическом хосте. Пример 2-13 отображает команду получения списка всех pGPU установленных в хосте, а также образец вывода результатов после выполнения этой команды.

Одним из примеров pGPU является набор микросхем VGA на материнской плате, которая используется dom0 и его консолью. Пример 2-14 отображает команду, применяемую для поиска используемого по умолчанию dom0 GPU. Если есть только выделенный графический адаптер или ваш хост имеет лишь ЦПУ со встроенными возможностями GPU, тогда ваш первичный pGPU определённый при загрузке является единственным устройством, которое XenServer может использовать либо в режиме проброса (pass-through), при котором всё GPU назначается ВМ, или в режиме виртуальной графики, при котором некая часть вашего GPU назначается различным ВМ.

 

Пример 2-13. Определение физического GPU установленного для хоста. Результат показывает наличие NVIDIA Quadro

# xe pgpu-list
uuid ( RO)              : 47d8c17d-3ea0-8a76-c58a-cb1d4300a5ec
       vendor-name ( RO): NVIDIA Corporation
       device-name ( RO): G98 [Quadro NVS 295]
    gpu-group-uuid ( RW): 1ac5d1f6-d581-1b14-55f1-54ef6a1954b4
 	   

 

Пример 2-14. Определение GPU используемого dom0 по умолчанию

# lspci | grep "VGA"
 	   

 

gpu-group

Группа GPU это просто коллекция графических механизмов, которые содержатся в пределах отдельной физической графической карты. Если данная графическая карта способна подразделять свои ресурсы на множество объектов GPU, тогда группа GPU будет содержать ссылку на каждый объект, как это показано в Примере 2-15.

 

Пример 2-15. Перечень ресурсов GPU, связанных с физическим графическим адаптером

# xe gpu-group-list
 	   

 

vgpu

vgpu представляет виртуальный графический адаптер определяемый данной графической картой. Команда vgpu-type-list, показанная в Примере 2-16, возвращает три возможных vGPU опции для вашего данного хоста.

 

Пример 2-16. Просмотр типов GPU в пределах хоста XenServer

# xe vgpu-type-list
uuid ( RO)            : ad32125b-e5b6-2894-9d16-1809f032c5bb
     vendor-name ( RO): NVIDIA Corporation
      model-name ( RO): GRID K100
framebuffer-size ( RO): 268435456

uuid ( RO)            : ee22b661-4aa0-e6e6-5876-e316c3ea09fe
     vendor-name ( RO): NVIDIA Corporation
      model-name ( RO): GRID K140Q
framebuffer-size ( RO): 1006632960

uuid ( RO)            : 2025cc3e-c869-ef44-2757-a1994cc77c8e
     vendor-name ( RO):
      model-name ( RO): passthrough
framebuffer-size ( RO): 0
 	   

  Объекты хранения

Исходя из проекции архитектуры, система хранения состоит из двух концепций, представляемых четырьмя различными объектами. Каждый из них уникальным образом определяется и сопровождается в пределах базы данных XAPI и это:

• Репозитории хранения (SR, Storage repositories) являются физическими устройствами, которые содержат виртуальные диски, связываемые с ВМ.

• Физические блочные устройства (PBD, Physical block devices) отображают физический сервер запоминающих устройств для хранения репозитория.

• Интерфейсы виртуального диска (VDI, Virtual disk interfaces) являются виртуальными жёсткими дисками, которые усиливают API управления хранением: сохраняя скрытым тип диска для ВМ, однако соответственным образом обрабатывая транзакции своим гипервизором.

• Виртуальные блочные диски (VBD, Virtual block disks) отображают VDI на виртуальные машины.

Взаимосвязи между этими четырьмя объектами отображены на Рисунке 2-4.

 

Рисунок 2-4 Как хранилища XenServer взаимодействуют друг с другом