Немного о дизайне VDI. Часть 9. Сетевая подсистема

Продолжаем говорить о дизайне VDI. Предыдущие части доступны по ссылкам.
Часть 1. Введение
Часть 2. Постановка задачи
Часть 3. Верхнеуровневая архитектура
Часть 4. Подсистема VMware Horizon
Часть 5. Подсистема виртуализации
Часть 6. Лицензирование VDI
Часть 7. Виртуальные машины
Часть 8. Подсистема хранения

9.1 Требования к производительности сети

При грамотном подходе и планировании сетевая подсистема внутри ЦОД, как правило, не является проблемным местом, чего не скажешь о "последней миле", которая может приводить к изрядным головным болям у архитектора и сотрудников поддержки (и пользователей).

При планировании VDI следует обратить внимание на то, какие требования предъявляют и какую нагрузку создают следующие типы трафика:

• Трафик, который генерирую виртуальные десктопы при работе с приложениями.
• Трафик при подключении пользователей к своим виртуальным десктопам.
• Служебные трафик, необходимый для функционирования VDI инфраструктуры.

В сценариях VDI виртуальные десктопы и серверы приложений находятся достаточно "близко" друг от друга, трафик передается внутри ЦОД по высокоскоростной сети. В этом и заключается одно из главных отличий VDI от физических рабочих станций. Централизация позволяет снизить нагрузку на канал передачи данных от пользовательских рабочих места до ЦОД. Пользователи могут заметить повышение производительности в работе приложений, в качестве примера можно рассмотреть вариант с открытием и сохранением больших документов, которые раньше передавались по сети 100 Мбит/с или 1 Гбит/с на физическую рабочую станцию, а теперь передаются на виртуальный десктоп, подключенный к сети 10 Гбит/с. Однако, несмотря на локализацию внутри ЦОД, трафик приложений все-равно следует учитывать при сайзинге количества и типа сетевых интерфейсов серверов виртуализации.

Трафик протоколов удаленного доступа (PCoIP, Blast или RDP) также следует учитывать при планировании конфигурации серверов и коммутаторов, однако большее влияние он оказывает на WAN-каналы передачи данных при организации подключения пользователей из удаленных филиалов или из Интернет. Каналы с недостаточной пропускной способностью, большими потерями и высокими задержками будут напрямую влиять на качество изображения, скорость отрисовки и время отклика протоколов удаленного доступа, а следовательно, и на удовлетворенность пользователей от работы с виртуальным десктопом.

Нагрузка, создаваемая при подключении к виртуальным десктопам, зависит от используемого протокола, количества и разрешения мониторов, настроек качества изображения и частоты обновления. В среднем, для типового пользователя Knowledge Worker утилизация составляет 150-200 Кбит/с. Просмотр изображений и видео, работа с 3D графикой увеличивает требования к каналу.

При сайзинге требуемой полосы пропускания для протокола PCoIP следует воспользоваться рекомендациями из PCoIP Session Planning Administrators' Guide (https://www.teradici.com/web-help/TER1105004/Sess-Plan_Admn-Gd.pdf) и Horizon 7 Architecture Planning (https://docs.vmware.com/en/VMware-Horizon-7/7.5/horizon-architecture-planning.pdf).

В тестовой среде или пилотной инсталляции основные метрики производительности протокола удаленного доступа и утилизация канала могут быть получены при помощи счетчиков Perfmon, или из журналов PCoIP или Blast. Также можно воспользоваться ПО vRealize Operations for Horizon, позволяющим централизованно собирать статистику о работе протоколов удаленного доступа с виртуальных десктопов.

Служебный трафик может составлять значительную часть от всего сетевого трафика, генерируемого VDI инфраструктурой. К служебному трафику можно отнести трафик vSAN, трафик Fault Tolerance, трафик репликации данных в СУБД Microsoft SQL или файловых серверов DFS-R, vCenter Server, установленном в HA режиме, репликации ВМ средствами vSphere Replication, трафик системы резервного копирования. Fault Tolerance или All-Flash vSAN могут накладывать дополнительные ограничения на минимальную скорость подключения (не менее 10 Гбит/с).

9.2 Планирование адресного пространства

Разделение адресного пространства на несколько подсетей может быть продиктовано желанием уменьшить широковещательный домен или отделить трафик виртуальных десктопов от служебных ВМ из-за требований безопасности.

При необходимости размещения виртуальных десктопов в нескольких подсетях следует учитывать следующие моменты.

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

Решить эту проблему для Pooled ВМ можно, вручную перемещая ВМ в целевые группы портов, либо используя механизм Multiple Network Labels, позволяющий в настройках пула указать несколько виртуальных сетей (групп портов) и максимальное количество адресов, которые могут быть выделены в каждой сети.

9.3 Выбор виртуального коммутатора

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

• стандартный виртуальный коммутатор (vSS – vNetwork Standard Switch);
• распределенный виртуальный коммутатор (vDS – vNetwork Distributed Switch);
• сторонний виртуальных коммутатор (Third-party Switch).

Из-за прекращений поддержки сторонних коммутаторов в ESXi после версии 6.5 U1, на текущий момент имеет смысл рассматривать выбрить только между vSS и vDS. Различия в функциональных возможностях коммутаторов приведены в таблице.

Функции	vSS	vDS
Поддерживаемые редакции vSphere	Essentials или выше	Enterprise Plus Входит в состав лицензий NSX или VSAN
Требует наличие vCenter Server для настройки	Нет	Да
Шейпинг входящего трафика ВМ (Egress)	Да	Да
Шейпинг исходящего трафика ВМ (Ingress)	Нет	Да
Поддержка агрегации канала / NIC Teaming	Только статическая (для IP Hash)	Статическая и LACP
Варианты балансирования трафика	Port ID MAC Hash IP Hash Failover	Port ID MAC Hash IP Hash Failover Based on NIC Load LACP
Поддержка NetFlow	Нет	Да
Поддержка Port Mirroring (SPAN, RSPAN)	Нет	Да
Встроенный фильтр трафика	Нет	Да
Тегирование трафика QoS	Нет	Да
Поддержка NIOC	Нет	Да
Создание виртуальных логических сетей NSX	Нет	Да
Интеграция с распределенным брандмауэром NSX	Да	Да

Несмотря на зависимость vDS коммутатора от vCenter Server, он предоставляет гораздо больше функциональных возможностей по сравнению со стандартным коммутатором и рекомендуется к использованию в большинстве инсталляций VDI. vSS может использоваться для небольших/тестовых инсталляциях, а также в тех случаях, когда используется vSphere Standard, в которой отсутствует vDS.

ESXi поддерживает следующие алгоритмы балансирования и отказоустойчивости сетевых интерфейсов:

• Load based on Port ID;
• Load based on MAC Hash;
• Load based on IP Hash;
• Failover;
• Load based on NIC Load.

Failover – самый примитивный режим, не обеспечивает балансировку трафика и используется только для отказоустойчивости. Все сетевые интерфейсы ВМ подключаются к первому в списке активному физическому интерфейсу (аплинку), в случае его недоступности – ко второму, и т.д.

Port ID – является типовым режимом, работающим по принципу Round Robin. Сетевые интерфейсы ВМ и VMKernel равномерно распределяются между аплинками в режиме чередования, в зависимости от того, к какому порту виртуального коммутатора они подключены. Например, для двух аплинков первая ВМ будет подключена к первому аплинку, вторая – ко второму аплинку, третья – снова к первому, и т.д.

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

MAC Hash также распределяет виртуальные адаптеры по аплинкам, как и Port ID, однако выбор аплинка выполняется на основании хэша MAC адреса виртуального сетевого интерфейса.

IP Hash динамически выбирает аплинки для отправки пакета в зависимости от IP адреса источника и назначения. Данный алгоритм балансировки требует настройки агрегации сетевых интерфейсов со стороны сетевого коммутатора (Static EtherChannel в терминологии Cisco).

Load based on NIC Load распределяет сетевые адаптеры схожим с Port ID образом за исключением того, что гипервизор отслеживает нагрузку на аплинках, и если нагрузка между аплинками различается более, чем на 70%, то автоматически переключает сетевые интерфейсы ВМ с более загруженного на менее загруженный аплинк.

Отдельно следует сказать про балансирование трафика средствами LACP Aggregation Group (LAG). LAG не являются одним из алгоритмов балансировки, доступны только в связке с распределенным коммутатором, позволяют объединить до 8 физических интерфейсов в LAG и настроить на нем способ балансирования трафика. В vSphere доступно 22 алгоритма балансировки.

9.4 VMware NSX

VMware NSX может применяться в сценариях VDI для решения следующих задач:

• Микросегментация/фильтрация трафика между виртуальными десктопами и служебными ВМ.
• Обеспечения связности между подсетями/маршрутизация трафика средствами гипервизора.
• Интеграция с ПО антивирусной защиты.
• Организация L2 сетей для обеспечения катастрофоустойчивости или для виртуальных инфраструктур, охватывающих несколько площадок (Cross-vCenter NSX).

NSX Distributed Firewall – функция микросегментирования позволяет фильтровать любой трафик отправляемый или получаемый сетевыми интерфейсами ВМ, в том числе, передающийся между ВМ, расположенными в одной подсети и даже запущенные на одном физическом сервере. Данная возможность отличает NSX от классических межсетевых экранов, которые могут фильтровать трафик передаваемые только между разными подсетями. Это позволяет обеспечить передачу трафика, необходимого для работы VDI и приложений, и запретить все остальное сетевое взаимодействие. При создании правил в качестве источника или назначения трафика могут использоваться:

• MAC адрес.
• IP адрес.
• Конкретная ВМ или сетевой адаптер ВМ.
• Группа безопасности, в которую входят ВМ.
• Группа безопасности, в которую входит группа пользователей Active Directory.
• Логическая сеть, группа портов на стандартном или распределенном коммутаторе.
• Кластер или виртуальный ЦОД целиком.

Про группы безопасности следует упомянуть отдельно. Членство в группах может быть статическим – администратор вручную указывает, какие ВМ входят в группу, либо динамическим. NSX может включать ВМ в группу безопасности на основании операционной системы, установленной в ВМ (например, все ВМ, с ОС Windows, все ВМ с ОС Windows XP и т.д.), на основании тэга безопасности, присвоенной ВМ (можно создать тэг "Connection Servers" и назначить его соответствующим ВМ), на основании имени ВМ (все ВМ, имя которых начинается с vdi-desktop) и другие критерии.

Отдельного упоминания заслуживает возможность включить в группу безопасности доменные группы пользователей из Active Directory. В этом случае появится возможность создавать т.н. Identity Based правила, которые будут применяться к ВМ после того, как в них вошли доменные пользователи, которые являются членами определенной доменной группы.
NSX Distributed Logical Router позволяет перенести задачи по маршрутизации трафика виртуальной инфраструктуры с физических маршрутизаторов на гипервизоры.

Функция NSX Guest Introspection поддерживается многими современными антивирусными решениями, и позволяет полностью отказаться от необходимости установки и периодического обновления антивирусного агента внутрь ВМ, либо использовать облегченные версии антивирусных агентов.

Использование L2 логических сетей (Logical Network) на базе VXLAN позволяет связать две площадки и организовать катастрофоустойчивый территориально-распределенный кластер (stretched cluster), либо выполнить развертывание NSX в режиме Cross-vCenter и объединить несколько инсталляций vCenter на разных площадках и обеспечить L2 связность при помощи универсальных логических сетей и универсальных маршрутизаторов.

VMware NSX не входит в состав Horizon, поэтому его требуется приобретать отдельно. Для сценариев VDI возможно лицензирование NSX по физическим процессорам/сокетам серверов виртуализации, либо по количеству запущенных ВМ (NSX for Desktop, данный вариант лицензирования предназначен для сценариев VDI и имеет те же ограничения, что и vSphere for Desktop или vSAN for Desktop).

Из других функций, которые также могут найти применение в сценариях VDI следует отметить балансировщик нагрузки в NSX Edge Services Gateway, который может использоваться для балансировки нагрузки между View Connection Server или Unified Access Gateway, а также VPN (L2 Site-to-Site VPN для организации связности удаленных площадок и SSL VPN – для подключения пользователей).

VMware NSX доступен в нескольких редакциях, до версии 6.4 – это были Standard, Advanced и Enterprise, начиная с версии 6.4 основные редакции (не считая ROBO): Standard, Professional, Advanced и Enterprise Plus (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/nsx/vmware-nsx-datasheet.pdf).

При выборе редакции следует учесть – какие функции требуются от NSX. Так, например, NSX Distributed Firewall доступен в редакции Professional и выше, Identity Based правила и территориально-распределенные инсталляции Cross-vCenter NSX – в Advanced и выше.

Продолжение доступно по ссылкам:

Часть 10. Организация подключения и безопасность
Часть 11. Доступность VDI, Резервное копирование и аварийное восстановление