В предыдущей статье я кратко описал основные новшества XenServer 7.1. Сегодня подробно остановимся на улучшениях седьмой версии XenServer и дополнениям в 7.1. Заинтересовавшихся прошу под кат.


Итак, пройдемся по основным нововведениям седьмого поколения Citrix XenServer:

I. В первую очередь, стоит отметить улучшения, сделанные для оптимизации установки специализированных инструментов виртуализации, которые раньше нужно было ставить самостоятельно. Сейчас их можно устанавливать через встроенный загрузчик обновлений Windows из репозитория данной ОС. Главная проблема с установкой XenTools возникает в ситуации, когда количество виртуальных машин исчисляется сотнями. Обычно это выглядело так: монтируем образ диска с XenTools, запускаем исполняемый файл для установки, Windows перезагружается и завершает установку инструментов виртуализации. Но в ситуации, когда на одном XenServer работает большое количество ВМ или же у нас несколько гипервизоров, установка становится большой проблемой для конечного заказчика (и особенно администратора сети). В XenServer 7 реализован другой вариант: поставленная на гипервизор ОС Windows определяет, где она установлена, скачивает необходимые утилиты для того чтобы управлять операционной системой виртуальной машины с Windows Update. В результате администратору не нужно вручную устанавливать обновления для каждой машины. Однако стоит учесть, что такой вариант справедлив только для Enterprise редакции XenServer.

II. Теперь доступна интеграция гипервизора с Citrix Insight Services, что дает возможность получения анализа существующей инфраструктуры и ошибок, даже если у заказчика нет официального контракта на техническую поддержку Citrix. Insight Services открыт для всех пользователей, включая бесплатные редакции, и если у заказчика возникает необходимость в проверке виртуальной инфраструктуры на наличие ошибок, он может уже на начальном этапе провести диагностику самостоятельно. Используя учётную запись для сайта cis.citrix.com, администратор подключается к службе через XenServer, выбирает в соответствующем меню нужное действие и сервер отправляет журналы на анализ в Citrix. После разбора логов клиенту по электронной почте приходит ссылка на доступ к детальному отчёту – в каком состоянии находится инфраструктура, что с точки зрения Citrix рекомендуется исправить или установить дополнительно. В качестве примера – в прошлом году на тестировании у одного из заказчиков было выявлено, что на 3 серверах установлены три разных версии firmware, в одной из которых содержалась критическая ошибка, проявляющаяся как раз в работе с любой виртуальной инфраструктурой, о чём честно предупреждал сайт производителя оборудования. Также выяснилось, что на всех трех серверах XenServer были установлены разные версии сборки, набор обновлений также отличался. Фактически с помощью Citrix Insight Services удалось устранить большую часть проблем с виртуальной инфраструктурой.



Можно настроить систему на периодический сбор журналов действий. Например, раз в две недели (причем администратор может указать, что он считает допустимым отправить на анализ, а что нет) в автоматизированном режиме эти журналы будут отправляться на анализ, после чего администратор получит рекомендации по устранению тех или иных ошибок и общей настройке системы. Если администратор не хочет все это «пускать на самотек» в автоматизированном режиме, он снимает галочку в соответствующем меню. При этом все равно есть возможность из меню XenCenter, не выгружая логи автоматически, пройдя по меню выбрать необходимые журналы действий или другую информацию, которую нужно отправить на анализ и загрузить данные на Citrix Insight Services. Если же у заказчика есть платная редакция с саппортом, то достаточно указать номер кейса и к этому кейсу будут подгружены соответствующие логи (чтобы саппорту не пришлось просить удаленного подключения к инфраструктуре, а администратору решать вопросы с предоставлением удалённого доступа).

III. В седьмой версии XenServer был существенно изменен состав и размер разделов. В предыдущих версиях гипервизора все журналы действий лежали на dom0-разделе, что могло приводить к проблемам при большом количестве собираемой журналами информации. Сейчас для них выделен отдельный раздел, что снижает риск «фриза» системы, когда в нештатной ситуации журналы начинают забивать раздел dom0. Также был увеличен размер разделов primary и backup. Для того чтобы развернуть инфраструктуру гипервизора XenServer 7 теперь требуется, как минимум, 42 ГБ свободного места на жестком диске сервера. Но надо понимать, что это не размер дистрибутива, а размер дисковой емкости под разделы, с помощью которых система управляется. Сейчас раскладка выглядит так: 1 ГБ на swap, 4 ГБ для хранения журналов, 18 ГБ на основной и 18 ГБ на резервный разделы, 0,5 ГБ для UEFI, если загрузка осуществляется с его помощью. На тех машинах, где стоит UEFI, поддерживается загрузка через него, но эта возможность появляется только для тех установок, которые ставятся «с нуля». То есть если имеется старый сервер с установленным XenServer 6.5, а в сервере есть UEFI, то для того чтобы задействовать возможность загрузки с UEFI нужно полностью переустановить гипервизор XenServer, а не проводить процедуру обновления.

IV. Один из основных источников затрат при виртуализации десктопов – это хранилище данных. Отсюда объясним рост популярности гиперконвергентных систем, когда снижаются требования к системе хранения данных. В седьмой версии XenServer расширился перечень поддерживаемых протоколов доступа к системам хранения. В дополнение к обычным fibre channel теперь поддерживаются сетевые карты с fibre channel over ethernet от Broadcom, Intel и HP. Также поддерживается загрузка по iSCSI на серверах Cisco UCS, что позволяет использовать бездисковые серверы и свободно подключаться к дисковой полке.



V. Citrix была первой компанией, которая сначала реализовала проброс GPU в виртуальную машину, а после и виртуализацию графических карт NVIDIA GRID. В версии XenServer 7 поддерживается до 128 виртуальных графических карт на один сервер и реализована поддержка виртуальных графических адаптеров (vGPU) для гостевых операционных систем Linux. Также появилась возможность использовать виртуальные графические процессоры без установки графической карты. Это реализуется при использовании серверов с процессорами Intel Broadwell и Skylake с чипсетом C226. В этом случае встроенная графика Intel Iris Pro может быть «разрезана» на семь виртуальных GPU. Плюс решения в том что для многих прикладных продуктов скорость работы графической карты не очень важна, главное чтобы карта в принципе была видна системе. На текущий момент такая возможность есть только у XenServer, но работает это только для однопроцессорных серверов. Преимущества получают офисные и другие приложения Windows, приложения для просмотра CAD-моделей. Стоит отметить, что разделение на виртуальные графические карты возможно и в рамках виртуального десктопа и в терминальном режиме.

VI. Если говорить о безопасности VDI, то на сегодняшний день возможно несколько вариантов защиты. Обычный подход – в виртуальной ОС есть полноценный агент, который работает в непривилегированном режиме и отслеживает изменения в системе. Агент что-то замечает и пытается с этим бороться. Однако если виртуальных машин на сервере несколько десятков или даже сотен, то получается ситуация когда система обслуживает исключительно саму себя. С легким агентом ситуация проще – система работает с внешней виртуальной машиной с которой агент обменивается хэшем. Хотя нагрузка существенно снижается, но не все же не до конца. В XenServer 7.1 реализован безагентский вариант защиты от уязвимостей нулевого дня. Компания Bitdefender вместе с Intel и Citrix разработала и интегрировала с гипервизором отдельную виртуальную машину, которая сканирует память гостевых виртуальных машин. Security Appliance работает на гипервизоре и занимается анализом памяти виртуальных машин самостоятельно. В рамках самой виртуальной ОС никаких агентов не работает. При появлении зловредной активности она блокируется на уровне гипервизора.


Bitdefender Hypervisor Introspection (HVI)

VII. В XenServer 7 реализована поддержка контейнеров не только для Linux, но и для Windows Server 2016. Для ряда разработчиков такая схема весьма востребована, потому что позволяет обеспечить гибкость разработки и модернизации приложений, а также ускорить цикл разработки. В рамках XenCenter существует единый интерфейс управления контейнерами, администратор видит все типы контейнеров и может обеспечивать их рабочие циклы. Если говорить про консоль Docker (поддерживается для Debian 8, Ubuntu 14.04, CoreOS & RHEL/CentOS/OEL 7.x), то доступ к ней также можно получить из XenCenter. То же относиться и к контейнерам Windows Server 2016.

VIII. Были проведены изменения в работе процессов Datapath и Control-Plane в управляющем домене (dom0), поскольку ранее повышенная нагрузка при передаче данных по сети или работе с дисковыми операциями, приводила к тому, что переставали отвечать сервисы управления XenServer. С выходом XenServer 7 эти процессы выделили в отдельную группу (Cgroups), что позволяет им не зависеть от нагрузки, которая создается сетевой и дисковой подсистемой. Это позволило значительно снизить время на загрузку виртуальных машин и повысить надёжность и стабильность работы гипервизора.


Cgroups позволяет процессам Control-Plane работать когда необходимо

IX. В версии 7.1 применен механизм Live-patching, предлагающий пакетное применение обновлений. Раньше для того чтобы установить любой новый патч на гипервизор, требовалась перезагрузка системы. Live-pаtching, разработанный Citrix и Oracle (для Linux – Red Hat), позволяет при загрузке патча определить насколько он требует изменений, связанных с перезагрузкой и если она не требуется, обновление применяется без прерывания работы гипервизора. Сначала патч (в виде RPM) устанавливается в оперативной памяти и только в случае возможности переносится на диск. Система информирует администратора о том, что нужно перезагрузиться либо можно подождать до завершения работы или плановой перезагрузки. При этом в оперативной памяти изменения системы будут приняты. Если требуется обязательная перезагрузка, администратор получит об этом предупреждение. Пакеты исправлений для XenServer сменили формат – теперь они выпускаются в стандартном формате isо-файлов. Их не нужно отдельно загружать в dom0, просто появляется новое виртуальное дисковое подключение, монтируется iso-файл и происходит обновление соответствующего компонента.

X. Функция кеширования трафика PVS (провижининг сервер) повышает скорость загрузки десктопов на 30% и гарантирует уменьшение сетевого трафика до 98%. Если сейчас виртуальная машина загружается с PVS, то для каждой виртуальной машины осуществляется передача данных, даже если все они загружаются с одного образа. При включении кеширования трафика PVS, после загрузки одной виртуальную машину, эти данные будут закешированы на гипервизоре и теперь при выполнении загрузки следующих виртуальных машин, они будут обращаться к dom0, не нагружая сеть и сервер PVS. В результате если мы запускаем больше одной машины из одного образа, то получаем ощутимый выигрыш за счет снижения нагрузки на сетевую подсистему. Для возможности использования этой функциональности необходимы сервер PVS версии начиная с 7.12 и Open virtual swich, а также XenServer 7.1.


Кеш операций PVS на XenServer

Вот наиболее масштабные и существенно влияющие на работу системы изменения, сделанные в седьмой версии Citrix XenServer. Помимо этого, есть ряд менее значительных нововведений:

• Несмотря на то что и в предыдущих версиях XenServer была реализована возможность миграции между хранилищами, но сложность была в том, что позволялось мигрировать только работающую виртуальную машину. Если машина была выключена, то миграция была невозможна. Сейчас эта ситуация исправлена и ВМ можно перемещать в любом состоянии.
  
  
• Добавлен клиент PuTTY для того чтобы из консоли подключаться к виртуальным машинам. Исполняемый файл PuTTY включен в утилиту установки XenCenter. Кнопка на закладке «Console» запускает клиента PuTTY, который подключится к ВМ или dom0 автоматически.
  
  
• Поддерживаются все новейшие CPU, гипервизор Xen обновлен до версии 4.7, dom0 построен на 64-битном CentOS 7.2.
  
  
• Был переработан раздел, связанный с интеграцией Aсtive Directory. Если ранее гипервизор использовался в инфраструктуре с очень большими группами, которые мы хотели завязать на управление через XenCenter, то система замедлялась из за проверки большого количества токенов безопасности. Сейчас же используется другой провайдер для работы с Active Directory и в результате гарантирована масштабируемость для инфраструктур с миллионами пользователей и десятками тысяч групп, при интеграции с XenCenter.
  
  
• Помимо Microsoft Hyper-V, VMware ESXi и Nutanix Acropolis теперь в гиперконвергентных решениях Nutanix можно использовать Citrix XenServer. На текущий момент Acropolis не имеет возможности работы с виртуальной графикой, не может работать с Bitdefender Hypervisor Introspection, нет возможности работы с кешированием трафика PVS, поэтому если требуются какие-либо из указанных выше функций то рекомендуется использовать XenServer. Однако некоторые функции XenServer не могут быть использованы при интеграции в Nutanix, так как они реализуются функционалом гиперконвергентной системы.

С прошлого года Citrix начал выпускать LTSR-версии продуктов (Long Term Service Release). Заказчик, выбравший LTSR-версию, может быть уверен, что при необходимости эта версия будет поддерживаться в течение 10 лет. XenServer 7.1 как раз является первой LTSR-версией продукта. Ее поддержка закончится в 2022 году, а жизненный цикл завершится в 2027 (EOL).

Задавайте ваши вопросы в комментариях, и я с радостью на них отвечу.