Виртуализация vSphere, Hyper-V, Xen и Red Hat
Более 5540 заметок о виртуализации, виртуальных машинах VMware, Microsoft и Xen, а также Kubernetes
Что нового появилось в VMware Unified Access Gateway 3.4?
VMware UAG представляет собой шлюз для доступа к инфраструктуре Workspace ONE и Horizon. Шлюз используется для безопасного доступа внешних авторизованных пользователей ко внутренним ресурсам рабочей области Workspace ONE, а также виртуальным десктопам и приложениям Horizon.
Напомним, что о прошлой версии Unified Access Gateway 3.3 мы писали вот тут.
Давайте посмотрим, что нового появилось в UAG 3.4:
1. Обеспечение собственной высокой доступности (High Availability).
Как и другие компоненты инфраструктуры VDI, решение UAG теперь поддерживает механизм обеспечения собственной высокой доступности.
Делается это средствами виртуального IP-адреса и Group ID, что позволяет балансировать трафик на порту 443 для более чем 10 тысяч одновременных подключений. Это позволяет снизить операционные затраты на обслуживание таких сервисов, как VMware Horizon 7, Web Reverse Proxy, Per-App Tunnel и VMware Content Gateway.
2. Механизм мониторинга Session Statistic Monitoring для оконечных сервисов.
Теперь с помощью этих функций в административной консоли UAG можно в реальном времени наблюдать за статистиками активных и неактивных сессий, неудачными попытками входа, сессиями протоколов Blast и PCoIP, туннелями и прочими параметрами. Это позволит грамотнее планировать балансировку пользовательских сессий.
3. Режим Cascade Mode для поддержки Horizon 7.
4. Ограничение доступа к службам Amazon Web Services.
Теперь с помощью UAG можно лимитировать доступ к облачным ресурсам AWS в целях разграничения доступа. В этом случае Unified Access Gateway можно импортировать в облако Amazon EC2, зарегистрировать как Amazon Image Machine (AMI) и развернуть с помощью сценария PowerShell.
5. Поддержка custom thumbprints.
Custom thumbprints позволяют использовать разные сертификаты для соединений Blast TCP и VMware Tunnel. Это можно сделать в консоли UAG или через PowerShell INI.
6. Нативная поддержка Horizon 7.
В консоли Horizon Administrator в дэшборде System Health теперь отображаются детали о зарегистрированных модулях VMware Unified Access Gateway для версии 3.4 и более поздних:
Скачать VMware Unified Access Gateway 3.4 можно по этой ссылке.
Вебинары VMC о виртуализации:
Постер VMware vSphere PowerCLI 6.3: 
Постер VMware ESXi 5.1: 
Постер VMware Hands-on Labs 2015: 
Постер VMware Platform Services Controller 6.0: 
Постер VMware vCloud Networking: 
Постер VMware NSX (референсный): 
Постер VMware vCloud SDK: 
Постер VMware vCloud Suite: 
Постер VMware vCenter Server Appliance: 
Порты и соединения VMware vSphere 6:
Порты и соединения VMware Horizon 7: 
Порты и соединения VMware NSX: 
Управление памятью в VMware vSphere 5:
Как работает кластер VMware High Availability: 
Постер VMware vSphere 5.5 ESXTOP (обзорный): 
Постер Veeam Backup & Replication v8 for VMware: 
Постер Microsoft Windows Server 2012 Hyper-V R2: 
Виртуализация vSphere, Hyper-V, Xen и Red Hat
Более 5540 заметок о виртуализации, виртуальных машинах VMware, Microsoft и Xen, а также Kubernetes
Новые возможности VMware Unified Access Gateway (UAG) версии 3.3.
В конце мая компания VMware выпустила обновленную версию продукта VMware Unified Access Gateway (UAG) версии 3.3. Это решение представляет собой шлюз для доступа к инфраструктуре VMware Workspace ONE и VMware Horizon. Шлюз используется для безопасного доступа внешних авторизованных пользователей ко внутренним ресурсам решения Workspace ONE, виртуальным десктопам и приложениям.
Давайте посмотрим, что нового появилось в этом продукте:
1. Поддержка механизма Device Certificate Authentication для обратного прокси-сервера.
Аутентификация на базе сертификатов вместе с поддержкой Web Reverse Proxy используется для защиты внутренних сайтов, таких как SharePoint, Outlook OWA и т.п. при доступе с внешних устройств.
2. Логирование действий администратора.
Теперь все действия пользователя admin записываются в файл audit.log:
Также записываются и операции по скачиванию данного лога.
3. Отсутствие зависимости от Network Protocol Profile.
Раньше на платформе vSphere профиль Network Protocol Profile (NPP) или IP Pool должны были иметь соответствующие сети на стороне UAG с такими же настройками IP, шлюза и т.п. Теперь нет необходимости настраивать все это на стороне vSphere, а вместо этого при развертывании UAG нужно указать маску IPv4, префикс IPv6 и шлюз по умолчанию.
4. Поддержка TLS Port 443 Sharing.
Теперь такие сервисы, как Horizon Blast, туннель для конкретного приложения, Content Gateway и Web reverse proxy идут по одному порту 443. Это минимизирует требования к добавлению новых правил в сетевой экран в DMZ.
5. Одновременная работа с IPv4 и IPv6 (Dual Mode).
С помощью Dual Mode пользователи инфраструктуры VMware Horizon могут использовать смешанный парк устройств, работающих, как с IPv4, так и с IPv6 в рамках одного соединения (например, карточка IPv6 на мобильном устройстве и NIC с IPv4 на Connection Server).
6. Редактирование настроек сетевого адаптера через веб-интерфейс.
В веб-интерфейсе виртуального модуля UAG администратор теперь может задавать IP-настройки сетевого адаптера:
7. Новая операционная система виртуального модуля.
8. Настройки масштаба инфраструктуры.
Теперь при развертывании UAG можно задать одну из двух настроек масштаба:
Скачать VMware Unified Access Gateway 3.3 можно по этой ссылке.
Вебинары VMC о виртуализации:
Постер VMware vSphere PowerCLI 6.3:
Постер VMware ESXi 5.1:
Постер VMware Hands-on Labs 2015:
Постер VMware Platform Services Controller 6.0:
Постер VMware vCloud Networking:
Постер VMware NSX (референсный):
Постер VMware vCloud SDK:
Постер VMware vCloud Suite:
Постер VMware vCenter Server Appliance:
Порты и соединения VMware vSphere 6:
Порты и соединения VMware Horizon 7:
Порты и соединения VMware NSX:
Управление памятью в VMware vSphere 5:
Как работает кластер VMware High Availability:
Постер VMware vSphere 5.5 ESXTOP (обзорный):
Постер Veeam Backup & Replication v8 for VMware:
Постер Microsoft Windows Server 2012 Hyper-V R2:
blog.vmpress.org
Страницы
понедельник, 4 декабря 2017 г.
Немного о дизайне VDI. Часть 10. Организация подключения и безопасность
10.1 Варианты подключения к виртуальным десктопам
Выбор протокола для подключения также влияет на архитектуру VDI. На текущий момент Horizon поддерживает следующие протоколы для подключения к виртуальным десктопам.
| Функции |
При выборе протокола следует учитывать, что поддержка многих функций зависит также от используемого клиентского устройства и версии ОС, установленной на виртуальном десктопе.
Протоколы PCoIP или Blast являются более оптимальным выбором, поскольку помимо более широких функциональных возможностей, обеспечивают лучшее качество изображения, меньшие задержки и утилизацию канала, чем RDP, хотя большую роль здесь играет версия ОС (Windows 10 обеспечивает гораздо лучшие показатели сжатия и качества в сравнении с Windows 7 или Windows 8: https://cloudblogs.microsoft.com/enterprisemobility/2016/01/11/remote-desktop-protocol-rdp-10-avch-264-improvements-in-windows-10-and-windows-server-2016-technical-preview/).
HTML5 клиент может применяться в качестве вспомогательного варианта, в тех случаях, когда пользователь подключается с специализированных клиентских устройств и не имеет возможности установить полнофункциональный клиент Horizon Client. Несмотря на свою «платформонезависимость», ряд функций, такие как аппаратное декодирование и многомониторные конфигурации поддерживаются только для браузера Google Chrome.
Еще один немаловажный показатель – это приспособленность протокола к работе на нестабильных, медленных каналах. Согласно документу Blast Extreme Display Protocol in Horizon 7 (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-horizon-7-view-blast-extreme-display-protocol.pdf) протокол PCoIP способен работать на каналах с потерями пакетов, достигающих 15%, в то время как Blast может «пережить» до 20% потерь.
Последний фактор – это простота публикации протокола на межсетевых экранах. Лидером здесь является RDP, поскольку для его работы при использовании режима туннелирования требуется открыть только один порт – TCP 443. Для Blast помимо TCP 443 требуется открыть TCP 8443 и опционально UDP 8443, хотя в случае использования Unified Access Gateway есть возможность туннелирования трафика только через TCP 443. Для PCoIP помимо TCP 443 требуется открыть доступ по портам TCP 4172 и UDP 4172. В большинстве случаев, когда не работает подключение по PCoIP, и пользователь видит перед собой черный экран, это означает, что администраторы забыли открыть доступ по порту UDP 4172.
10.2 Клиентские устройства
Производительность тонкого клиента напрямую влияет на частоту прорисовки и качество изображения, а, следовательно, на удобство и комфорт работы пользователя. В большинстве случаев производительности процессоров уровня Core i3 или Pentium достаточно для обеспечения работы в большинстве приложений, а вот процессоры Intel Atom или AMD G-series, не говоря уже о процессорах с архитектурой ARM, могут не справиться с обработкой изображения в высоком разрешении с частой перерисовкой экрана (воспроизведение видео, работа графикой, многомониторные конфигурации).
Решить проблему с недостаточно производительными процессорами позволяют тонкие клиенты, поддерживающие VMware Blast. Данный протокол использует кодек H.264 и для декодирования изображения может задействовать графический адаптер клиентского устройства, тем самым снижая нагрузку на процессор и ускоряя процесс обработки изображения, что позволяет обеспечивать приемлемый уровень производительности даже на ТК начального уровня. На текущий момент далеко не все клиенты, поддерживающие VMware Blast, поддерживают аппаратное декодирование (например, ТК Dell Wyse с ОС ThinOS версии 8.4.110 и ниже), кроме того следует помнить о некоторых нюансах работы (http://blog.vmpress.org/2017/05/vmware-blast-h264.html).
Альтернативой ТК с аппаратной поддержкой Blast являются нулевые клиенты на базе процессоров Teradici (TERA2 2321 и 2220). Данные ТК обеспечивают высокий уровень производительности, сопоставимый со стационарными компьютерами, экономичны, просты в настройке и эксплуатации, однако из-за ограничений Teradici OS не поддерживают многие функции Horizon.
Если говорить о функциональных возможностях, то здесь лидерами являются компьютеры с ОС Windows и клиентами Horizon Client. Версии Horizon Client под MAC OS X или Linux не поддерживают проброс сканеров или последовательных портов, а у нулевых клиентов Teradici также отсутствует поддержка протоколов RDP и Blast, функций Flash Redirection, MMR, RTAV, Virtual Printing и пр.
Linux является крайне популярной ОС для установки на тонкие клиенты (у каждого производителя найдется пара-другая моделей ТК с Linux). Некоторые вендоры предоставляют оптимизированную версию ОС Linux, которая может быть установлена на существующие компьютеры, превращая их в ТК. Среди популярных решений можно отметить:
10.3 Удаленный доступ
Один Security Server связывается (pairing) только с одним Connection Server, использование балансировщика между security server и connection server не поддерживается
К одному и тому же Connection Server могут подключаться несколько UAG. При балансировании Connection Server несколько UAG могут подключаться к нескольким Connection Server
USB Redirection
Two-factor Authentication (RSA SecurID или Radius)
Smart-Card Authentification
USB Redirection
USB Redirection
Two-factor Authentication (RSA SecurID или Radius)
Smart-Card Authentification
USB Redirection
• Blast Extreme Sessions – UDP = 1,000
• Blast Extreme Sessions – TCP = 2,000
Основное отличие Security Server от UAG заключается в том, что UAG представляет собой предустановленный виртуальный апплайнс на базе ОС Linux и не требует лицензии Windows.
UAG гораздо проще в установке и настройке, он использует только HTTPS протокол для интеграции с Connection Server и не требует открытия большого кол-ва портов между Security Server и Connection Server.
Security Server поддерживает режим развертывания по схеме 1 к 1, для каждого Connection Server’а создается один парный Security Server, варианты, когда к одному Connection Server’у подключаются два Security Server или, наоборот, когда один Security Server подключается к двум Connection, не поддерживается. Для обеспечения безопасности передаваемых данных между Security Server и Connection Server может быть настроен IPSec.
Использование Security Server’ов на больших инсталляциях связано с определенными ограничениями в случаях, когда вам необходимо сделать разные настройки туннелирования и аутентификации для разных пользователей, подключающихся из внутренних и внешних сетей. Например, вы хотите, чтобы для внутренних пользователей аутентификация по смарт-картам была опциональна и не использовалось туннелирование, а для внешних пользователей использовалось туннелирование и была бы обязательна аутентификация по смарт-картам или SAML аутентификация при интеграции с Identity Manager (…и еще там тэги разные для разных пулов и Connection Server’ов).
Так как данные настройки задаются на парном Connection Server и не могут быть переопределены на Security Server, все варианты комбинаций не получится задать в рамках одного POD’а и обеспечить при этом отказоустойчивость подключений.
UAG поддерживает больше сценариев развертывания по сравнению с Security Server, помимо варианта один Connection Server – один UAG, несколько UAG могут подключаться к одному и тому же Connection Server, или один UAG может подключаться к нескольким Connection Server через балансировщик нагрузки.
Также UAG позволяет настроить проксирование трафика BLAST Extreme через единый порт (TCP 443), в отличие от Security Server, который требует открыть и TCP 443, и TCP 8443. Помимо предоставления доступа к VDI инфраструктуре Horizon, UAG также может использоваться для публикации Identity Manager и AirWatch, и все через один IP адрес.
Решения от сторонних производителей (Citrix и F5) предоставляют функции PCoIP Proxy сервера и могут заменить собой Security Server или UAG. Кроме проксирования PCoIP трафика, сторонние решения также могут осуществлять балансирование нагрузки, выступать в качестве серверов публикации приложений, выполнять SSL Offload и т.д.
Обычно серверы Security Server или UAG размещаются в DMZ сети, однако следует помнить, что клиент устанавливает туннелированное подключение через Security Server/UAG, минуя Connection Server, соответственно, между ними и виртуальными десктопами должна быть настроена маршрутизация трафика и открыт доступ по соответствующим протоколам.
10.4 Балансирование нагрузки
Самым простым в настройке вариантом балансировки является DNS Round Robin. Для каждого IP-адреса сервера Connection Server (или пограничного сервера) создается A-запись с одним и тем же именем (например, vdi.company.local), которое используется клиентами для подключения. При запросе клиентом адреса у DNS сервера, сервер возвращает список IP адресов. Для каждого запроса порядок адресов меняется, таким образом, один клиент подключиться к серверу Connection Server, который в списке адресов находится на первом месте, второй клиент подключится ко второму серверу, и так далее. DNS Round Robin позволяет равномерно распределить входящие подключения по серверам, однако имеет несколько недостатков. Во-первых, DNS Round Robin не выполняет проверку доступности серверов, поэтому при отказе сервера продолжает возвращать список, включающий его IP адрес, что может привести к тому, что клиент предпримет попытку подключиться к нерабочему серверу.
Во-вторых, отсутствие persistence, одному и тому же клиенту, при каждом запросе выдается список, в котором меняется порядок IP-адресов, из-за чего могут возникать различные проблемы с подключением.
В-третьих, при использовании DNS Round Robin не отслеживается количество активных подключений к каждому серверу и уровень его загрузки.
Другой вариант предполагает использование балансировщика сетевой нагрузки: встроенного (Windows Network Load Balancer), либо внешних (Citrix NetScaler, F5 BIG-IP, KEMP Loadmaster, NSX Edge, HAProxy и др.). Среди преимущества использования внешних балансировщиков:
В случае балансирования всего трафика через балансировщик идет не только служебный трафик, но также трафик удаленной сессии PCoIP/Blast. Это приводит к большей нагрузке на балансировщик, а также требует настройки дополнительных правил балансирования для сессионного трафика (по портам TCP/UDP 4172 для PCoIP, и TCP/UDP 8443/443 для Blast, зато позволит упростит публикацию из Интернет, т.к. публичный IP адрес потребуется только для балансировщика. Кроме того, при использовании балансировщика с функциями L7 (application) firewall, такое устройство может использоваться для защиты серверов View от различных сетевых атак.
Если вы планируете балансировать весь траффик, а не только первоначальное подключение по HTTPS, то на балансировщиках требуется включить sticky sessions/affinity, чтобы трафик PCoIP/Blast перенаправлялся на тот же Connection Server, через который было установлено первоначальное соединение.
Еще одна важная функция, которую предоставляют внешние балансировщики, это проверка здоровья балансируемого сервиса (health check). Балансировщик периодически выполняет подключение к балансируемому серверу для проверки его состояния. В случае если проверка завершается неудачно, балансировщик может временно исключить сервер из списка и перенаправлять подключения на оставшиеся серверы. Для HTTPS трафика предпочтительно использовать проверку здоровья на уровне приложения. Например, при публикации Connection Server балансировщик может выполнять проверку здоровья путем выполнения HTTP GET запроса для получения файла иконки сайта («/favicon.ico»). Этот вариант позволит избежать у пользователей проблем с подключением, возникающих при использовании менее строгих вариантов проверки здоровья, например, при помощи ping’а или telnet’а на определенный порт.
Если к VDI инфраструктуре не предъявляются повышенные требования к безопасности, и нет необходимости использования application firewall на балансировщике, то вариант с балансированием только HTTPS является предпочтительным. Для балансирования HTTPS трафика будет достаточно балансировщика начального уровня, это позволит снизить затраты на развертывание (многие балансировщики лицензируются по функциональным возможностям и пиковой полосе пропускания).
10.5 Двухфакторная аутентификация
При интеграции Horizon с VMware Identity Manager и настройке SAML аутентификации может быть задействован механизм True SSO, позволяющий избавиться от необходимости ввода логина и пароля при аутентификации через RSA SecurID на портале Identity Manager.
Принцип работы механизма True SSO основан на генерировании и использовании одноразовых цифровых сертификатов пользователей. В инфраструктуре развертывается дополнительный сервер Horizon Enrollment Server, который отвечает за запрос сертификатов от имени пользователя и передачу сертификата серверу View для дальнейшей аутентификации пользователей.
Интеграция Horizon с RADIUS серверами позволяет обеспечить работу различных механизмов двухфакторной аутентификации, например, JaCarta Authentication Server – аналог RSA SecurID.
При аутентификации при помощи смарт-карт пользователь предоставляет сертификат (первый фактор) и пин-код для доступа к сертификату, хранящемуся на смарт-карте (второй фактор), при этом пользователю не требуется вводить логин и пароль учетной записи при входе на виртуальный десктоп благодаря использованию сквозной аутентификации.
Поскольку двухфакторная аутентификация настраивается на уровне отдельных Connection Server, то для реализации разных способов аутентификации для различных категорий пользователей (например, для обычных и защищенных пользователей) требуется развернуть несколько экземпляров Connection Server и настроить несколько адресов для подключения.