Гостевой пост нашего партнера, IaaS-провайдера - компании ИТ-ГРАД. Технология vSAN является одним из элементов гиперконвергентной системы от VMware, которую активно используют облачные провайдеры для создания отказоустойчивой, гибкой и масштабируемой услуги по аренде виртуальной инфраструктуры (IaaS). Но прежде чем приступить к обсуждению данной технологии...
Многие организации хотели бы иметь парк аппаратных "тонких клиентов", которые предоставляют доступ к корпоративной инфраструктуре виртуальных ПК VMware Horizon. Тонкие клиенты позволяют сразу же показать пользователю терминальную сессию к его виртуальному ПК, защищенному корпоративными политиками, без возможности физически иметь доступ к десктопу, его жесткому диску и системным настройкам.
Для тех, у кого нет возможности предоставить пользователям подобные устройства, но есть необходимость в их использовании (в основном, в целях безопасности), компания VMware выпустила утилиту Physical Desktop as a Thin Client на сайте проекта VMware Labs.
Она позволяет превратить обычный компьютер на базе Windows в подобие тонкого клиента - убрать такие элементы, как таскбар, системные опции и прочее, а также запретить запуск сторонних приложений.
После настройки данной утилитой обычного компьютера, пользователь после логина будет видеть окно ввода учетных данных в Horizon View Client, не сможет изменить локальные настройки компьютера и будет работать с ним как с обычным терминалом доступа к удаленному десктопу (при этом нельзя будет переключаться между приложениями). После завершения сессии пользователя в View Client физический десктоп также будет потушен.
Для работы этого продукта потребуется действующая инфраструктура Active Directory с установленным компонентом Group policy management console (GPMC), а также все доменные машины должны иметь доступ к папке \\<domain>\\SYSVOL. Сами эти десктопы управляются через GPO с именем "Thin Client Group Policy".
Детальную информацию о настройке Physical Desktop as a Thin Client можно найти вот в этом документе. Скачать данную утилиту можно по этой ссылке.
Осенью 2017 года мы писали о релизе операционной системы VMware Photon OS 2.0, предназначенной для контейнеров Docker, cloud-native приложений, публичных облачных платформ и инфраструктуры VMware (виртуальные модули).
Оказывается, как справедливо отметили в комментариях, в конце февраля этого года было выпущено обновление VMware Photon OS 3.0. Давайте посмотрим, что там нового:
1. Поддержка архитектуры ARM64.
Теперь Photon OS 3.0 можно запускать на Raspberry Pi 3. Для этого есть предсобранный образ, а также возможность собирать новые образы с помощью image builder.
2. Улучшения установки.
Теперь инсталлятор можно запускать с различных носителей, таких как USB, CDROM и средств kickstart с любого из поддерживаемых устройств хранения.
Driver Development Kit - возможность интегрировать свои кастомные драйверы.
3. Прочие улучшения.
Предсобранные образы для развертывания на облачных платформах Microsoft Azure, Google Compute Engine (GCE), Amazon Elastic Compute Cloud (EC2) и VMware (vSphere, Fusion и Workstation).
Новые версии следующих базовых пакетов ОС:
Linux kernel 4.19
Glibc 2.28
systemd 239
Python3 3.7
Openjdk : 1.8.0.192
Обновление большинства пакетов, доступных из репозитория (около 440 пакетов были обновлены).
Возможность одновременной поддержки пакетов разных версий (например, go-1.9 и go-1.10).
Новые пакеты: EdgeX, Liota, linux-firmware, wpa_supplicant for WLAN, consul, meson и другие.
Также в Photon OS 3.0 теперь доступно 3 размера установки ОС:
Minimal - для IoT-устройств с самыми минимальными базовыми требованиями.
Developer - пакеты для создания, тестирования и развертывания контейнеризованных приложений.
Edge - включает пакеты для создания устройства edge gateway.
Скачать VMware Photon OS 3.0 можно по этой ссылке. Там же доступна и документация.
На днях компания VMware объявила об очередном релизе платформы для создания инфраструктуры виртуальных ПК предприятия - VMware Horizon 7.8.
Давайте посмотрим, что нового в Horizon 7.8 и его компонентах:
1. Новые функции Connection Server.
Консоль Horizon (веб-интерфейс на базе HTML5)
Можно использовать Horizon Console для инициализации архитектуры Cloud Pod, присоединять узлы в рамках функционала федерации, создавать и управлять глобальными правами доступа, сайтами и домашними сайтами.
Можно пересоздавать и восстанавливать связанные клоны с постоянными (persistent) дисками.
Для операций со связанными клонами доступна отмена начавшейся задачи (Cancel task).
Можно создавать автоматические фермы связанных клонов (automated linked-clone farms).
Можно настраивать Horizon Connection Server и аутентификацию пользователей. Также доступна настройка ролевой модели доступа, политик и клиентских сессий.
Можно настраивать ярлыки для опубликованных пулов десктопов и приложений.
Архитектура Cloud Pod
Лимиты топологии архитектуры Horizon 7.8 теперь следующие:
250 000 сессий всего
50 объектов pods
10 000 сессий на pod
15 сайтов
7 экземпляров Connection Server на один pod
Всего 350 экземпляров Connection Server
Опубликованные десктопы и приложения
Для опубликованных десктопов и приложений на хостах RDS теперь поддерживаются объекты Organizational Units (OU).
На RDS-хостах теперь можно использовать статистики CPU, памяти, диска и числа сессий для определения политики балансировки нагрузки для опубликованных десктопов и приложений.
Можно повторно использовать существующие учетные записи компьютеров для развертывания новых пулов мгновенных клонов в домене.
Функции доступа True SSO
После того, как пользователи используют True SSO для логина в десктопы, они могут разлочить десктоп путем повторной аутентификации на портале Workspace ONE с теми же кредами True SSO.
Изменения механизма безопасного доступа к домену
Несколько поменялась механика логина через Horizon Client (подробнее - тут). Сначала пользователь вводит свой полный логин с доменом в текстовое поле (domain\username или username@domain.com), после чего ему показывают селект с выбором домена, либо его может вообще не быть, либо там будет значение *DefaultDomain*. Подробнее об этом написано в настройках Send domain list и Hide domain list в документе VMware Horizon 7.8 Security.
Можно заставить пользователя ввести учетные данные, даже если у него стоит настройка Logon as current user. Более подробно об этом рассказано в документе Horizon 7.8 Administration, где описана настройка Accept logon as current user.
Для более детальной информации о доменных настройках для клиентов Horizon Clients можно обратиться к KB 67424.
Улучшения безопасности аутентификации пользователей, где исправлена проблема CVE-2019-5513, описанная в руководстве VMSA-2019-0003.
2. Новый Horizon Agent.
Теперь можно использовать регулярные выражения при задании правил URL Content Redirection. Смотрите раздел "Regular Expression Rules That URL Content Redirection Supports" в документе Configuring Remote Desktop Features in Horizon 7.
Аутентификация с помощью смарт-карт теперь поддерживается с приложениями UWP, такими как Microsoft Edge, в удаленных десктопах.
Плагин Helpdesk теперь есть в составе установщика Horizon Agent.
Функция VMware Integrated Printing содержит опцию finishing (параметры staple и booklet) для специализированных перенаправляемых принтеров.
Когда администратор включает режим read-only для подключения других пользователей к сессии, основной пользователь может подключить несколько пользователей в режиме просмотра сессии. При этом только основной пользователь может взаимодействовать с элементами управления, а остальные просто смотрят.
3. Новый Horizon Agent for Linux.
Улучшенная поддержка дистрибутивов Linux - теперь добавлены RHEL 7.6 и CentOS 7.6.
Начиная с Horizon HTML Access версии 5.0, функции нескольких мониторов поддерживаются для десктопов Linux.
Horizon 7.8 поддерживает перенаправление смарт-карт для Linux-десктопов с версией RHEL 7.1 и позднее. Эта возможность позволяет авторизоваться пользователю через смарт-карту, подключенную к клиентской системе.
Расширенная поддержка True SSO для Ubuntu 16.04 или 18.04, SLED 12.x SP3, а также SLES 12.x SP3.
Когда администратор включает режим read-only для подключения других пользователей к сессии, основной пользователь может подключить несколько пользователей в режиме просмотра сессии. При этом только основной пользователь может взаимодействовать с элементами управления, а остальные просто смотрят.
Групповая политика URL Content Redirection содержит теперь настройку Url Redirection IP Rules Enabled, которая позволяет настроить IP-адреса и их фильтрацию.
Новый файл шаблона групповой политики VMware Horizon Client Drive Redirection ADMX (vdm_agent_cdr.admx) содержит настройки перенаправления клиентских дисков. Он позволяет настроить букву подключаемого устройства и таймаут для инициализации в Windows Explorer.
Настройка групповой политики Session Collaboration позволяет передать контроль ввода участникам совместной сессии.
Настройки групповой политики VMware Integrated Printing позволяют задать фильтр при перенаправлении клиентского принтера и настроить параметры предварительного просмотра.
5. Horizon 7 Cloud Connector.
Для виртуального модуля Horizon Cloud Connector можно настроить политику устаревания пароля пользователя root.
6. Поддержка VMware Cloud on AWS.
Пул мгновенных клонов поддерживает сетевые сегменты NSX-T.
Полный список возможностей Horizon 7, поддерживаемых в VMware Cloud on AWS, приведен в KB 58539.
7. Обновленная версия User Environment Manager 7.9.0.
Возможности Application blocking и privilege elevation поддерживаются на рабочих станциях, коьторые используют утилиту User Environment Manager SyncTool.
Полный список новых возможностей VMware User Environment Manager 7.9 приведен вот тут.
Летом прошлого года мы писали об обновлении утилиты для сотрудников технической поддержки, работающих с пользователями инфраструктуры VMware Horizon - Horizon Helpdesk Utility версии 1.2. Это решение реализует всю функциональность Helpdesk в HTML5 интерфейсе управления VMware Horizon, но поставляется теперь как отдельное решение с расширенными возможностями.
На днях на сайте проекта VMware Labs вышло существенное обновление этого средства - Horizon Helpdesk Utility 1.3. Давайте посмотрим, что там появилось нового:
Убран вывод списка виртуальных машин из представления сессий.
Улучшенное представление Environment view, которое включает метрики для всей подключенной инфраструктуры:
vSphere
Hosts
Datastores
Удаленные объекты Pods
Events
Проблемные машины
Добавлены повторяющиеся запросы для процедуры logon breakdown, если они были пропущены при первой попытке.
Добавлена поддержка запросов к событиям при logon breakdown.
Добавлен просмотр событий для фермы и пулов десктопов.
Добавлен встроенный поиск пользователей и машин в представлении пулов.
Добавлена функция множественного выбора в представлении пулов и фермы.
Добавлены графики для машин и сессий, а также проблемные машины в разделе Environment overview.
Добавлен pod switcher в Environment overview.
Расширены функции Pod Jumping:
возможность по требованию перейти к нужному pod
возможность перейти к pod, к которому относится выбранная сессия
Добавлена поддержка представления Architecture view для пулов десктопов и фермы.
Добавлена пакетная поддержка пользовательских задач для пулов десктопов и фермы:
Отправление сообщений
Log off
Disconnect
Reset
Restart
Поддержка представления local pod view (он же Environment view).
Добавлена документация (можно выбрать в комбо-боксе загрузки утилиты).
Добавлена поддержка MSI-инсталлятора.
Добавлена колонка start time в представлении пользовательских сессий.
Скачать VMware Horizon Helpdesk Utility 1.3.3.1 можно по этой ссылке.
Мы часто писали о решении VMware vRealize Network Insight (vRNI), которое позволяет системным и сетевым администраторам, а также администраторам информационной безопасности, смотреть за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.
Также с помощью vRNI можно найти 3 типа отклонений для виртуальных машин, работающих непрерывно в виртуальной инфраструктуре:
Outliers - девианты по трафику в рамках группы ВМ по сравнению с остальными членами группы.
Thresholds - машины, которые превысили пороговые значения по трафику или сбросу пакетов.
Top Talkers - самые потребляющие сетевые ресурсы машины в каком-то аспекте мониторинга.
Сегодня мы рассмотрим ситуацию, когда с помощью vRNI можно обнаружить девиантов по трафику (Outliers) в группе виртуальных машин, выполняющих одинаковую функцию. К таким машинам можно отнести, например, веб-серверы, размещенные за балансировщиком и принимающие на себя в среднем одинаковую нагрузку.
Если один из серверов начинает существенно отклоняться (например, отдавать трафика намного больше чем остальные), то это может говорить либо об ошибке в конфигурации балансировщика, либо о каких-то проблемах на этом веб-сервере. Также к таким сервисам можно отнести серверы DNS, Active Directory, кластеры серверов SQL и другие масштабируемые сервисы.
Помимо получения нотификаций о девиантах по SNMP или email, их поведение можно визуализовать на графиках. Это позволит вам сразу понять, какой из серверов ведет себя не как остальные, чтобы сразу приступить в выяснению источника проблемы:
Здесь мы видим, что виртуальная машина cmbu-sc2dc-01 на порту 53 имеет большой поток трафика, гораздо больше, чем остальные, поэтому и попала в категорию "Outliers" на панели справа.
Для мониторинга такого поведения вы можете выбрать один или несколько портов, а также направление трафика (входящий/исходящий), так как есть сервисы, которые в основном принимают данные (например, обработчики), а есть, которые преимущественно отдают (веб-серверы, DNS и т.п.).
Чтобы создать группу Outliers для мониторинга, нужно в консоли vRNI пойти в меню Analytics и там открыть раздел Outliers:
Далее вы увидите список всех настроенных групп Outliers. Там вы увидите, сколько девиантов в каждой группе было обнаружено, какие связанные с ними события произошли, а также информацию о группе (сколько ВМ, их IP и т.п.), также вы увидите, когда были обнаружены эти отклонения.
Для создания новой группы, в правом верхнем углу надо нажать ADD и установить все необходимые настройки:
Здесь они означают следующее:
Имя группы.
Масштаб наблюдения (application tier, NSX Security tag и т.п.).
Для уровня приложения (application tier) нужно выбрать само приложение и его ярус (tier).
Метрика - total traffic (MB, GB и т.п.), число пакетов или сессий, либо объем трафика в секунду.
Направление обнаруживаемого трафика (incoming, outgoing, both).
Направление трафика в датацентре: north-south (интернет-трафик), east-west (внутренний трафик датацентра), либо оба направления.
Порты назначения - можно мониторить все используемые порты, либо выбранные. Но пока есть лимит 20 портов, если он будет превышен, то их надо будет вводить вручную.
Когда все установлено, vRNI сгенерирует превьюшку результатов на графике, включающем в себя настроенные сетевые потоки.
Если превью вас устроило, то просто нажимаете Submit и добавляете новую группу в систему мониторинга.
Как только обнаруживается Outlier, для него создается открытое событие (Event), оно продолжает висеть в открытых, пока отклонение продолжает существовать. Как только все возвращается в норму, событие закрывается, однако остается в архиве, чтобы администратор знал о происходящем.
В общем, vRNI, хотя бы только с этой стороны - полезная штука!
Облачный провайдер «ИТ-ГРАД» повторно подтвердил статус поставщика управляемых сервисов. С обновленным статусом PCI DSS Managed Service Provider компания продолжит оказывать услуги по физическому размещению и аренде оборудования, включая аренду виртуальной инфраструктуры в модели IaaS с возможностью последующего управления и администрирования силами команды провайдера.
Наличие сертификата говорит о том, что облако «ИТ-ГРАД» полностью соответствует требованиям международного стандарта PCI DSS и гарантирует безопасное обращение платежных карт для организаций, использующих облачную площадку провайдера. Это дает право «ИТ-ГРАД» предоставлять услугу PCI DSS хостинга, благодаря которой клиент получает надежную, защищенную среду для обработки карточных данных и полную уверенность в отсутствии рисков финансовых потерь. Вместе с тем поставщик закрывает вопросы физической защиты серверов, администрирования ОС и обеспечивает постоянный контроль за безопасностью всех сегментов облачной ИТ-инфраструктуры.
Многие администраторы VMware vSphere сталкиваются с необходимостью развертывания кастомных образов VMware ESXi, например, от HP или Dell, так как они содержат все необходимые драйверы серверного оборудования.
Но процедура, как правило, такова - сначала администратор развертывает последний доступный образ ESXi Custom ISO, а уже после установки накатывает на него обновления через ESXCLI или Update Manager. Это несколько неудобно, так как зачастую требует перезагрузки уже после окончания основной установки.
Если у вас, например, 1500 хостов ESXi, то дополнительное время которое вы потратите за год на процедуры обновления после основной установки может составить до 42 часов в месяц (при условии, что вы накатываете по каким-то причинам образ ESXi на сервер где-то раз в год). Это, конечно же, очень много, поэтому в таких случаях стоит задуматься об интеграции обновлений в кастомизированный образ ESXi.
На самом деле, делается это достаточно просто с помощью PowerCLI в несколько команд (подробно процесс описан в документе Image Builder Patching):
1. Загружаете патчи в формате zip-бандлов и складываете их в одну папку.
На сайте проекта VMware Labs появилась полезная многим Enterprise-администраторам утилита Workspace One UEM Workload Migration Tool. Она позволяет провести бесшовную миграцию конфигураций приложений и устройств между различными окружениями Workspace One UEM.
Нажатием одной кнопки можно переместить конфигурации среды приемочного тестирования UEM в производственную среду предприятия, без необходимости вводить информацию об исходном и целевом окружении и загрузки файлов. Все это существенно уменьшает время на исполнение цикла ввода обновлений пользовательских окружений в эксплуатацию.
Для успешного выполнения миграции вам потребуется:
Сетевое соединение между двумя площадками.
Компьютер с Windows 10.
2 рабочих окружения Workspace One UEM.
Учетные данные администратора (API credentials) и разрешения (API permissions) для обоих окружений.
Скачать Workspace One UEM Workload Migration Tool можно по этой ссылке.
Очень дельную статью написал Вильям Лам, касающуюся настройки алармов для различных событий в инфраструктуре VMware vSphere. Иногда системному администратору требуется настроить мониторинг каких-либо действий пользователей, которые вызывают генерацию событий в консоли vSphere Client.
Например, вы хотите получать аларм, когда пользователь создает папку (Folder) для виртуального окружения через vSphere Client. Для начала нам понадобится информация, которую мы будем использовать в описании аларма. Для этого мы делаем действие, генерирующее событие, вручную (в данном случае, создаем папку), а после этого идем в раздел Monitor->Tasks, где смотрим описание задачи и связанного с ней события:
Главное здесь для нас - это лейбл "Task: Create folder", по которому мы найдем этот тип событий через PowerCLI, а точнее его Description Id. Открываем консоль PowerCLI и выполняем там вот такую команду, указав лейбл нашего события, найденный в консоли vSphere Client:
Результатом будет Description Id нашего события - это Folder.createFolder:
Далее можно создавать аларм, зная Description Id события. Выбираем тип условия Task event, а также описание в виде Description Id, тип условия end with и сам этот ID - Folder.createFolder:
После создания такого аларма, при каждом создании папки он будет срабатывать, что можно увидеть в разделе Triggered Alarms:
Таким же образом вы можете настроить алармы и для любых других событий, происходящих в инфраструктуре VMware vSphere.
Политика ограничения виртуальных машин по операциям ввода-вывода (IOPS limits storage policy rule) позволяет ограничить виртуальную машину в кластере VMware vSAN в плане потребления ресурсов хранилища. Она применяется для VMDK дисков машин и, как правило, используется в ситуациях, когда нужно изолировать "прожорливого соседа" - то есть виртуальную машину, которая может начать потреблять несоразмерно много ресурсов хранилища по вводу-выводу на хосте ESXi, вызывая большие задержки (latency) у других машин этого хоста. При этом такая машина на данном хосте может быть далеко не самой важной.
Ограничение машины по IOPS имеет некоторые особенности. Размер операции ввода-вывода может варьироваться в диапазоне от 4 КБ до 1 МБ. Это означает, что самая большая операция может быть в 256 больше по объему самой маленькой. Поэтому при применении ограничения по IOPS решение vSAN использует так называемые "взвешенные IOPS", определяемые квантами по 32 КБ (об этом мы писали вот тут). При размере операции до 32 КБ планировщик vSAN считает ее как одну операцию, 32-64 КБ - как две, и так далее.
Это позволяет при визуализации метрик производительности нормализовать поток данных к хранилищу и управлять им при импорте настроек из механизма SIOC, который применяется к виртуальным машинам не в кластере vSAN. Надо отметить, что vSAN имеет собственную механику регуляции I/O и собственный планировщик, поэтому механизм SIOC не применяется к таким хранилищам.
Соответственно, давайте взглянем на графики операций ввода-вывода на вкладке Monitor->vSAN->Performance:
На нижнем графике (Virtual SCSI IOPS) мы видим число реальных операций ввода-вывода, независимо от их размера, а на верхнем - уже нормализованные IOPS и лимиты, применяемые к ВМ.
IOPS limit применяется только ко всему потоку ввода-вывода гостевой ОС машины (то есть ярус хранения, ярус кэширования), но не затрагивает операции с самим диском VMDK и его swap-файлами, например, репликация машины, SVmotion (миграция хранилища), XVmotion (миграция машин без общего хранилища) и клонирование ВМ.
Если машина достигает лимита по IOPS, планировщик vSAN для нее начинает откладывать операции ввода-вывода до завершения транзакции таким образом, чтобы они не превышали заданного лимита по нормализованному числу операций в секунду. Это все приводит к тому, что задержки исполнения данных операций (latency) существенно возрастают, что видно на графике Virtual SCSI Latency:
Здесь мы видим, что при достижении лимита 200 IOPS latency возросла до 580 мс, а при достижении 400 мс - где-то до 230-290 мс. Эти задержки, возникающие на уровне виртуальной машины, проявляют себя также и на уровне всего хоста, кластера и даже приложений, таких как vRealize Operations.
Этот важный фактор надо учитывать, когда вы ищете причину высокой latency, потому что механизм vSAN Performance Service не делает различий, возникли ли задержки из-за проблем с производительностью, или они являются результатом применения IOPS limits.
Интересно также, что применение IOPS limits storage policy rule к одной виртуальной машине может повлиять и на другую ВМ, к которой не применяется этого правила. Например, вы копируете файлы одной ВМ на вторую (и обратно), у которой есть IOPS limit. При достижении этого лимита, очевидно, происходит уменьшение числа IOPS не только у целевой ВМ, но и у источника, так как происходит уменьшение совокупного числа операций ввода-вывода на передачу файлов.
При этом у исходной ВМ в этом случае не будет существенного изменения latency, так как ее операции откладываться не будут (посмотрите на левый и правый графики этой ВМ):
К сожалению, описанные эффекты влияния на производительность ВМ не всегда просто идентифицировать, поэтому нужно всегда осторожно выставлять IOPS limit и всегда четко его документировать в описании конфигурации виртуальной инфраструктуры.
RSS
