Развертывание Horizon в Решении Azure VMware
Примечание.
В этом документе рассматривается продукт VMware Horizon, ранее известный как Horizon 7. Horizon и Horizon Cloud в Azure — это разные решения, хотя у них есть и общие компоненты. Ключевые преимущества Решение Azure VMware включают как более простой метод изменения размера, так и интеграцию управления частным облаком Центра обработки данных (SDDC) в портал Azure.
VMware Horizon® — это платформа для виртуальных рабочих столов и приложений, которая работает в центре обработки данных и обеспечивает простое и централизованное управление. Она предоставляет виртуальные рабочие столы и приложения на любом устройстве в любом месте. Horizon позволяет создавать и устанавливать через брокер подключения к виртуальным рабочим столам Windows и Linux, приложениям, размещенным на сервере удаленных рабочих столов (RDS), рабочим столам и физическим компьютерам.
Здесь основное внимание уделяется развертыванию Horizon в Решении Azure VMware. Общие сведения о VMware Horizon см. в документации по работе с Horizon:
В Решение Azure VMware Horizon теперь есть два решения инфраструктура виртуальных рабочих столов (VDI) на платформе Azure:
VMware Horizon на Решение Azure VMware
VMware Horizon Cloud (модель рабочего стола как услуга)
Horizon 2006 и более поздних версий в линейке выпусков Horizon 8 поддерживает как локальное развертывание, так и развертывание в Решении Azure VMware. Некоторые из функций Horizon поддерживаются локально, но не поддерживаются в Решении Azure VMware. В экосистеме Horizon поддерживаются также другие продукты. Дополнительные сведения см. в статье о четности и взаимодействии компонентов.
Развертывание Horizon в гибридном облаке
Вы можете развернуть Horizon в гибридной облачной среде с помощью Horizon Cloud Pod Architecture (CPA) для подключения локальных и центров обработки данных Azure. CPA масштабирует развертывание, создает гибридное облако и обеспечивает избыточность для обеспечения непрерывности бизнес-процессов и аварийного восстановления. Дополнительные сведения см. в статье Развертывание существующих сред Horizon 7.
Внимание
CPA не является растянутым развертыванием. В Horizon все модули Pod работают отдельно, а все серверы Connection Server, принадлежащие каждому отдельному модулю Pod, должны находиться в одном расположении и выполняться в одном и том же широковещательном домене с точки зрения сети.
Как и локальные или частные центры обработки данных, вы можете развернуть Horizon в Решение Azure VMware частном облаке. В следующих разделах мы обсудим основные различия в развертывании локальной среды и Решение Azure VMware Horizon.
Частное облако Azure концептуально аналогично VMware SDDC (именно этот термин обычно используется в документации по Horizon). В оставшейся части этого документа оба термина используются как взаимозаменяемые.
Для управление лицензиями на подписки для Horizon в Решении Azure VMware необходим соединитель Horizon Cloud Connector. Соединитель Cloud Connector можно развернуть в виртуальной сети Azure вместе с серверами Horizon Connection Server.
Внимание
Поддержка уровня управления Horizon в Решении Azure VMware пока недоступна. Обязательно скачайте VHD-версию Horizon Cloud Connector.
Роль Администратор облака vCenter Server
Так как Решение Azure VMware является службой SDDC и Azure управляет жизненным циклом SDDC на Решение Azure VMware, модель разрешений vCenter Server на Решение Azure VMware ограничена проектированием.
Клиентам требуется использовать роль Cloud Администратор, которая имеет ограниченный набор разрешений vCenter Server. Продукт Horizon был изменен для работы с ролью администратора облака в Решении Azure VMware, как указано ниже.
Изменена мгновенная подготовка клонов для запуска в Решении Azure VMware.
В Решении Azure VMware для работы с Horizon создана определенная политика vSAN (VMware_Horizon), которая должна быть доступна и использоваться в SDDC, развернутых для Horizon.
При работе в Решении Azure VMware кэш чтения на основе содержимого (CBRC) vSphere, также известный как View Storage Accelerator, отключается.
Внимание
Не следует включать CBRC снова.
Примечание.
Решение Azure VMware автоматически настраивает определенные параметры Horizon при развертывании Horizon 2006 (Horizon 8) и выше в ветви Horizon 8 и выберите Параметр Azure в установщике сервера Horizon Подключение ion Server.
Horizon в архитектуре развертывания Решения Azure VMware
В типичном проекте архитектуры Horizon используется стратегия на основе блоков и модулей Pod. Блок является одним сервером vCenter Server, а несколько блоков объединяются в модуль pod. Модуль Pod в Horizon — это единица организации, определяемая ограничениями масштабируемости Horizon. Каждый модуль Pod Horizon имеет отдельный портал управления, поэтому стандартная методика проектирования заключается в уменьшении числа модулей Pod.
Каждое облако имеет собственную схему сетевого подключения. В сочетании с VMware NSX Решение Azure VMware сетевое подключение предоставляет уникальные требования для развертывания Horizon, отличного от локальной среды.
Каждое Решение Azure VMware частное облако и SDDC может обрабатывать 4000 сеансов настольных компьютеров или приложений, при условии:
трафик рабочей нагрузки соответствует рабочему профилю рабочей роли задачи LoginVSI;
учитывается только трафик протокола, данные пользователя отсутствуют;
для NSX Edge настроен большой масштаб.
Примечание.
Профиль рабочей нагрузки и потребности могут отличаться, поэтому результаты могут разными в зависимости от вашего варианта использования. В контексте рабочей нагрузки объемы томов данных пользователей могут быть меньше предельного масштаба. Определите размер и спланируйте развертывание соответствующим образом. Дополнительные сведения см. в пособии по определению размера в разделе Определение размера узлов Решения Azure VMware для развертываний Horizon.
Учитывая максимальное предельное значение для частного облака Azure и SDDC, мы рекомендуем использовать архитектуру развертывания, в которой серверы Horizon Connection Server и шлюзы VMware Unified Access Gateway (UAG) выполняются в виртуальной сети Azure. Это позволит эффективно преобразовать все частные облака Azure и SDDC в блок. При этом обеспечивается, максимальная масштабируемость Horizon в Решении Azure VMware.
Подключение из Azure виртуальная сеть к частным облакам Azure или SDDCs должно быть настроено с помощью expressRoute Подключение ions (FastPath включено). На следующей схеме показано базовое развертывание модуля Pod в Horizon.
Сетевое подключение для масштабирования Horizon в Решении Azure VMware
В этом разделе приведены общие сведения о сетевой архитектуре, а также распространенные примеры развертывания, которые помогут вам масштабировать Horizon в Решении Azure VMware. Основное внимание уделяется критически важным элементам сети.
Отдельный модуль Pod Horizon в Решении Azure VMware
Отдельный модуль Pod Horizon — это наиболее простой сценарий развертывания, поскольку он предполагает развертывание только одного модуля Pod Horizon в Восточном регионе США. Так как все частные облака и SDDC рассчитаны на обработку 4000 сеансов рабочего стола в каждом, вы развертываете модуль Pod Horizon максимального размера. Можно спланировать развертывание до трех частных облаков или SDDC.
С помощью виртуальных машин инфраструктуры Horizon, развернутых в виртуальной сети Azure, можно получить доступ к модулю 12 000 сеансов на каждый модуль Pod Horizon. Подключение между каждым частным облаком и SDDC к Azure виртуальная сеть — это Подключение ExpressRoute (с поддержкой FastPath). Трафик между частными облаками в восточном и западном регионах не требуется.
В случае этого базового примера развертывания предполагается следующее:
вам не требуется подключать локальный модуль Pod Horizon к этому новому модулю Pod с помощью Cloud Pod Architecture (CPA);
конечные пользователи подключаются к виртуальным рабочим столам через Интернет (а не через локальный центр обработки данных).
Вы подключаете свой контроллер домена AD в виртуальной сети Azure к локальной службе AD через канал VPN или ExpressRoute.
Вариантом этого базового примера может быть развертывание с поддержкой подключения к локальным ресурсам. Например, пользователи получают доступ к рабочим столам и создают трафик приложений виртуальных рабочих столов или подключаются к локальному модулю Pod Horizon с помощью CPA.
На схеме показано, как обеспечивается поддержка подключения к локальным ресурсам. Чтобы подключиться к корпоративной сети к виртуальная сеть Azure, вам потребуется канал ExpressRoute. Необходимо подключить корпоративную сеть к каждому частному облаку и SDDCs с помощью ExpressRoute Global Reach. Это обеспечит подключение из SDDC к каналу ExpressRoute и локальным ресурсам.
Несколько модулей Pod Horizon в Решении Azure VMware в нескольких регионах
Еще один сценарий — масштабирование Horizon на несколько модулей Pod. В этом сценарии выполняется развертывание двух модулей Pod Horizon в двух разных регионах и создание их федерации с помощью CPA. Он похож на конфигурацию сети в предыдущем примере, но с более межрегионными ссылками.
Подключение Azure виртуальная сеть в каждом регионе в частные облака или SDDCs в другом регионе. Это позволит серверам Horizon Connection Server, входящим в федерацию CPA, подключаться ко всем управляемым рабочим столам. Добавление дополнительных частных облаков или SDDC в эту конфигурацию позволит масштабировать ее в совокупности до 24 000 сеансов.
Те же принципы применяются при развертывании двух модулей Pod Horizon в одном регионе. Не забудьте, что второй модуль Pod Horizon следует развернуть в отдельной виртуальной сети Azure. Как и в примере с одним модулем Pod, вы можете подключить корпоративную сеть и локальный модуль Pod к используемому в этом примере развертыванию с несколькими модулями или регионами с помощью ExpressRoute и Global Reach.
Определение размера узлов Решения Azure VMware для развертываний Horizon
Методика определения размера Horizon на узле, работающем в Решении Azure VMware, проще, чем в локальной среде Horizon. Это проще, так как узел Решение Azure VMware стандартизирован. Точное определение размера узла помогает определить количество узлов, необходимых для соблюдения требований VDI. Это главный фактор при определения затрат на рабочий стол.
Таблица определения размера
Конкретные требования к виртуальным ЦП и ОЗУ для виртуальных рабочих столов Horizon зависят от профиля рабочей нагрузки соответствующего клиента. Попросите отдел продаж MSFT и VMware помочь с определением требований к виртуальным ЦП или ОЗУ для ваших виртуальных рабочих столов.
| Виртуальных ЦП на виртуальную машину | Емкость виртуальных ОЗУ на виртуальную машину (ГБ) | Экземпляр | 100 виртуальных машин | 200 виртуальных машин | 300 виртуальных машин | 400 виртуальных машин | 500 виртуальных машин | 600 виртуальных машин | 700 виртуальных машин | 800 виртуальных машин | 900 виртуальных машин | 1000 виртуальных машин | 2000 виртуальных машин | 3000 виртуальных машин | 4000 виртуальных машин | 5000 виртуальных машин | 6000 виртуальных машин | 6400 виртуальных машин |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2 | 3.5 | AVS | 3 | 3 | 4 | 4 | 5 | 6 | 6 | 7 | 8 | 9 | 17 | 25 | 33 | 41 | 49 | 53 |
| 2 | 4 | AVS | 3 | 3 | 4 | 5 | 6 | 6 | 7 | 8 | 9 | 9 | 18 | 26 | 34 | 42 | 51 | 54 |
| 2 | 6 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 12 | 13 | 26 | 38 | 51 | 62 | 75 | 79 |
| 2 | 8 | AVS | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 2 | 12 | AVS | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 2 | 16 | AVS | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
| 4 | 3.5 | AVS | 3 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 22 | 33 | 44 | 55 | 66 | 70 |
| 4 | 4 | AVS | 3 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 22 | 33 | 44 | 55 | 66 | 70 |
| 4 | 6 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 12 | 13 | 26 | 38 | 51 | 62 | 75 | 79 |
| 4 | 8 | AVS | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 4 | 12 | AVS | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 4 | 16 | AVS | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
| 6 | 3.5 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 13 | 14 | 27 | 41 | 54 | 68 | 81 | 86 |
| 6 | 4 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 13 | 14 | 27 | 41 | 54 | 68 | 81 | 86 |
| 6 | 6 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 13 | 14 | 27 | 41 | 54 | 68 | 81 | 86 |
| 6 | 8 | AVS | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 6 | 12 | AVS | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 6 | 16 | AVS | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
| 8 | 3.5 | AVS | 3 | 4 | 6 | 7 | 9 | 10 | 12 | 14 | 15 | 17 | 33 | 49 | 66 | 82 | 98 | 105 |
| 8 | 4 | AVS | 3 | 4 | 6 | 7 | 9 | 10 | 12 | 14 | 15 | 17 | 33 | 49 | 66 | 82 | 98 | 105 |
| 8 | 6 | AVS | 3 | 4 | 6 | 7 | 9 | 10 | 12 | 14 | 15 | 17 | 33 | 49 | 66 | 82 | 98 | 105 |
| 8 | 8 | AVS | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 8 | 12 | AVS | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 8 | 16 | AVS | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
Входные данные для определения размера Horizon
Вот что необходимо собрать для запланированной рабочей нагрузки:
число одновременно выполняемых рабочих столов;
требуемое число виртуальных ЦП на рабочий стол;
требуемая емкость виртуальных ОЗУ на рабочий стол;
требуемая емкость хранилища на рабочий стол.
Как правило, развертывания VDI имеют ограничения по ЦП или ОЗУ, что и определяет размер узла. Рассмотрим следующий пример для рабочей нагрузки типа LoginVSI Knowledge Worker, проверенной с помощью тестирования производительности:
2000 параллельно развернутых рабочих столов;
2 виртуальных ЦП на рабочий стол;
4 ГБ в виртуальном ОЗУ на рабочий стол;
50 ГБ емкости хранилища на рабочий стол.
В этом примере общее число узлов делится на 18, в результате чего плотность виртуальных машин оказывается равной 111.
Внимание
Рабочие нагрузки клиента будут отличаться от тех, которые используются в этом примере для LoginVSI Knowledge Worker. При планировании развертывания для определения конкретного размера и требуемой производительности обратитесь к инженерам по разработке решений VMware EUC. Перед окончательным определением размера узла обязательно запустите собственное тестирование производительности, используя фактическую плановую рабочую нагрузку, и внесите соответствующие корректировки.
Лицензирование Horizon в Решении Azure VMware
На общие затраты на выполнение Horizon в решении Azure VMware влияет четыре компонента.
Стоимость емкости в Решении Azure VMware
Сведения о ценах см. на странице цен на Решение Azure VMware.
Стоимость лицензирования Horizon
С Решением Azure VMware можно использовать две лицензии, каждая из которых может применяться для параллельного пользователя (CCU) или именованного пользователя (NU):
лицензия на подписку Horizon;
лицензия на подписку Horizon Universal.
Лицензию на подписку Horizon стоит использовать, только если в обозримом будущем будет использоваться развертывание Horizon только в Решении Azure VMware, так как ее стоимость более низкая.
При развертывании в Решении Azure VMware и локальной среде выберите лицензию на подписку Horizon Universal на случай использования для аварийного восстановления. Однако она включает лицензию на vSphere для локального развертывания, поэтому ее стоимость выше.
Обратитесь в отдел продаж VMware EUC, чтобы определить стоимость лицензирования Horizon в зависимости от ваших потребностей.
Типы экземпляров Azure
Сведения о размерах виртуальных машин Azure, необходимых для инфраструктуры Horizon, см. в статье Установка Horizon в Решении Azure VMware.
Ссылки
Требования к системе для агента Horizon для Linux
Следующие шаги
Дополнительные сведения о VMware Horizon в Решении Azure VMware см. на странице часто задаваемых вопросов о VMware Horizon.