Распределение аппаратных ресурсов между гостевыми доменами

За счет минимизации кода XEN, сам гипервизор для работы требует незначительное количество аппаратных ресурсов компьютера. Установленная связка Linux+XEN без подгрузки оконной системы X-window потребляет около 128 MB оперативной памяти, загрузка процессора порядка 1%. С дополнительной сервисной нагрузкой гипервизор может требовать 256 Mb ОЗУ. После установки гипервизора желательно отключение демонов, работа которых не требуется.

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

Все управление гостевыми доменами, а так же самим гипервизором осуществляется из специального управляющего домена "Dom0".

XEN может манипулировать различными аппаратными ресурсами, для передачи этих ресурсов гостевым доменам: количеством ядер CPU, процессорным временем каждого ядра, объемом ОЗУ, PCI, USB, SCSI и прочими ресурсами. Дисковое пространство для использования гостевыми доменами может распределятся, как на уровне файлов, так и на уровне блочных устройств (либо разделов LVM).

Для распределения ресурсов следует посчитать требования к системным ресурсам всех сервисов. Так как в каждом из серверов сегмента виртуализации установлено два мощных шестиядерных CPUIntelXeonX5660 2.8 ГГц (итого 12 ядер), процессорных ресурсов одного сервера хватит, чтобы с запасом удовлетворить рекомендуемые требования всех сервисов ЦОД.

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

По умолчанию, домен 0 (то есть сам гипервизор) получает весь доступный объём оперативной памяти.

Для каждого домена можно выделять требуемое и максимальное количество ОЗУ. Максимум будет выделяться динамически, по требованию самих гостевых доменов.

Оценочные требования к оперативной памяти следующие (реальные требования сильно зависят от нагрузки на сервисы и определяются эмпирически в процессе работы):

WindowsServer 2008 r2 требует (официально) 4GB ОЗУ. С учетом нагрузки можно добавить еще 2GB, итого 12GB для обоих контроллеров.

DHCP, DNS, FTP, SAMBA, NFS - это сервисы очень экономичные в плане системных ресурсов. Каждому из сервисов этих с даже учетом сильной нагрузки достаточно 1 GB ОЗУ, итого 5GB на все эти сервисы.

Загрузка HTTP-сервера Apache обычно зависит от количества посещений сайта. Сайт средней величины требует приблизительно 200 MB на 100 подключений. Определим для Apache 4GB оперативной памяти.

Загрузка терминальных сервисов тоже зависит от количества подключенных пользователей. SSH крайне экономичен в плане системных ресурсов, VNC несколько более требователен. С запасом определим для терминальных сервисов 4GB ОЗУ.

Примечание: требования к системным ресурсам могут значительно меняться в процессе работы сетевых сервисов. Это зависит от задач, количества пользователей и сессий, количества обрабатываемой информации.

Итого, для работы всех сервисов (приблизительно) нужно 25GB оперативной памяти. На каждом сервере из сегмента виртуализации установлено 48GB ОЗУ. Этого с запасом хватит для обеспечения работы всех сервисов, даже в случае размещения на одном гипервизоре.

Объем памяти, который может поддерживать сам XEN ограничивается по сути только аппаратной поддержкой серверов проектируемого ЦОД (компания IBM успешно провела тестирование инсталляции Xen с 1TB ОЗУ).

В случае увеличения требований к памяти одного из сервисов XEN позволяет оперативно добавить необходимое количество ОЗУ из свободной области.

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

На первом гипервизоре будут выполняться следующие серверы, с учетом количества ядер CPU и ОЗУ.

-Windows 2k8r2, первый контроллер домена, N-ядер, 6 GB ОЗУ.

-LinuxCentOS, DHCP-сервер, 1-ядро, 1 GB ОЗУ.

-LinuxCentOS, DNS-сервер, 1-ядро, 1 GB ОЗУ.

-LinuxCentOS, NFS-сервер, 1-ядро, 1 GB ОЗУ.

-LinuxCentOS, Сервер терминального доступа (SSH,VNC) , 2-ядра, 4 GB ОЗУ.

На втором гипервизоре будут выполняться следующие серверы:

-Windows 2k8r2, второй контроллер домена, 2-ядра, 6 GB ОЗУ.

-LinuxCentOS, SAMBA-сервер, 1-ядро, 1 GB ОЗУ.

-LinuxCentOS, HTTP-сервер Apache, N-ядер, 4 GB ОЗУ.

-LinuxCentOS, FTP-сервер, 1-ядро, 1 GB ОЗУ.

"N-ядер" - означает, что гостевой домен получит доступ ко всем оставшимся процессорным ресурсам, независимо от их количества.

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

Гостевые домены могут как монопольно, так и раздельно получать доступ к процессорному ресурсу. Это означает, что 9 виртуальных машин могут работать как на одном ядре, так каждой из этих машин можно выделить собственное количество ядер в монопольное использование.

Для более гибкого распределения системных ресурсов XEN позволяет определять количество процессорного времени и а так же приоритет доступа для каждого домена. Приоритет (cpu_weight) определяется "весом" домена (от 1 до 65535). Значение лимита (cpu_cap) определяется в процентах: 100 это 1 физический процессор, 50 это половина процессора, 400 - 4 процессора и т.д. Важно иметь ввиду, что одному виртуальному процессору не может соответствовать больше чем один реальный процессор.

Настройки процессорного времени и "веса" определим для каждого домена, как настройку по умолчанию (256).

Для каждого гостевого домена можно определять приоритеты ввода/вывода с помощью внешней утилиты "ionice". ionice применяется к процессам виртуальных машин XEN-QEMU (которые можно увидеть командой "ps aux | grep qemu-dm").

XEN позволяет транслировать (пробрасывать) PCI и USB устройства в гостевой домен. Это может быть актуально, например, для взаимодействия виртуализированной ОС с USB-ключем защиты.

Так же существует возможность динамического распределения памяти между доменами XEN. Для этого используется механизм "selfballooning" (с помощью демона xenballoond и специальных balloon-драйверов, устанавливаемых в ОС гостевых доменов.