Мониторинг виртуальной инфраструктуры критически важен. Часто ИТ-отделы тратят много времени и средств на борьбу с последствиями проблемы, вместо ее своевременного выявления и предотвращения. Как не довести проблему с ресурсами до аварии и простоя? 5nine Manager дает вам полный мониторинг состояния инфраструктуры Hyper-V и контроль критически важных бизнес-данных...
На днях компания VMware обновила свой PowerShell-фреймворк для управления виртуальной инфраструктурой, выпустив PowerCLI 10.2.0. Напомним, что о версии VMware PowerCLI 10.1.1 мы писали вот тут. Это уже четвертый релиз в этом году, самое значимое обновление - PowerCLI 10 - вышло в марте.
На самом деле, нового в PowerCLI 10.2 появилось не так уж и много:
Поддержка обновленной версии решения NSX-T 2.2 в модуле VMware.VimAutomation.Nsxt.
Вывод из эксплуатации модуля VMware.VimAutomation.PCloud (он еще доступен, но будет убран в будущем), ранее он управлял функциями vCloud Air.
Обновление функции Get-VIEvent, которое решает проблему с неожиданной ошибкой "Error in deserializing body of reply message for operation ‘RetrieveProperties’".
Если вам нечем заняться, и нужно как-то разнообразить вялые админские будни, то можно, например, кастомизировать страницу логина в VMware vSphere Client, поставив вместо нее страничку vYetti:
Работает эта штука как в VMware vSphere 6.5, так и в vSphere 6.7. Инструкции по установке здесь.
Как многие уже знают, не так давно VMware выпустила обновленную версию решения для виртуализации и доставки рабочих окружений пользователей VMware Horizon 7.5. Среди новых возможностей клиентов Horizon View была такая фича: "VMware Blast выбирает оптимальный транспорт автоматически (UDP или TCP) для предоставления лучшего качества обслуживания пользователю (ранее нужно было делать это вручную)".
Оказывается, это очень важная штука, и называется она Blast Extreme Network Intelligent Transport (BENIT). Ранее компания VMware анонсировала механизм Blast Extreme Adaptive Transport (BEAT), который позволял переходить на UDP-протокол в сетях с плохим качеством связи, предоставляя пользователю выбор типа соединения:
Blast Extreme автоматически подстраивается под параметры Bandwidth, Latency и Packet Loss в различных сетях и выбирает наиболее эффективный транспорт: TCP или UDP. Работало это так:
Excellent - предназначен для LAN-сетей с хорошим качеством (высокая скорость и низкие потери пакетов). В этом случае используется только TCP протокол - и для управления передачей, и для отправки самих данных.
В случае выбора Poor протокол Blast Extreme использует только UDP для управления передачей и отсылки данных. Это оптимально для WAN-сетей с большими задержками и коэффициентом потерь пакетов 20% и более.
Дефолтный пункт - Typical - это оптимальный выбор для 99% пользователей. В этом случае будет использоваться TCP для управления передачей, а UDP для основной отправки данных, с учетом адаптивного алгоритма. Если по каким-то причинам UDP будет недоступен (например, заблокирован политикой на сетевом экране), то произойдет незаметное для пользователя переключение на TCP.
Далее в версии VMware Horizon 7.3.1 появились отдельные каналы для для USB и CDR внутри протокола Blast. Это позволило инкапсулировать весь трафик в рамках одного протокола, что удобно с точки зрения управления каналом.
Между тем, некоторые недостатки такого механизма еще оставались, особенно при использовании UDP:
UDP часто заблокирован в корпоративной инфраструктуре или сильно зажат по ширине канала.
Маршрутизация на основе политик может вести TCP и UDP трафик через совершенно разные пути.
Некоторым приложениям (например, копированию файлов) гораздо важнее сырая пропускная способность, чем уровень отклика для пользователя, с чем отлично справляется TCP.
При использовании TCP в протоколе Blast нагрузка на CPU является несколько повышенной, если сравнивать с собственными механизмами оптимизации TCP в операционных системах.
Ну и главным недостатком BEAT было то, что условия соединения пользователя могли меняться в процессе работы - проявлялось влияние разных типов трафика, изменение параметров канала и прочее. Ну и сам пользователь не всегда был в курсе, какую политику BEAT нужно выбрать при работе с тем или иным приложением.
Еще одной проблемой является использование мобильных клиентов - протоколы TCP или Adaptive Transport предоставляют надежное соединение только когда постоянно доступно. Но мобильное устройство может переключиться с Wi-Fi на 3G/LTE, при этом, например, копирование файлов в гостевой ОС не должно прерываться.
Этот протокол предоставляет следующие характеристики:
Надежность - гарантия последовательной доставки данных в условиях прерывания сетевого соединения / переключения сетевых адаптеров.
Переключение транспорта для отдельного приложения на основе отклика приложения в сети.
Балансировка нагрузки за счет одновременного использования обоих транспортов для различных приложений, а также за счет выбора конкретного транспорта для определенного класса трафика (например, File Copy).
Так это выглядит наглядно:
Привязка нужного типа протокола происходит динамически на уровне сессии для каждого приложения или типа трафика через компонент мультиплексор.
Давайте посмотрим на некоторые аспекты такого решения:
Надежность
Тут возникает 2 основных проблемы:
Потеря соединения для транспортного протокола, когда данные были отосланы и, возможно, получены получателем, но источник не получил подтверждение этого. Для протокола BENIT это решается повторной отправкой данных только в случае переключения транспорта для приложения.
Эффект Race condition - когда приложение отправило пакет под одному каналу, а потом произошло переключение транспорта, и оно отправило другой пакет по другому каналу, а ответ для них может прийти в обратном порядке. Эта проблема решается механизмом обнаружения и коррекции ошибок.
Переключение транспорта
Для того, чтобы механизм BENIT работал эффективно, нужна возможность смотреть на производительность транспорта для определенных приложений, которая и реализована в протоколе. Решение по переключению может приниматься на основе заранее заданной политики (дефолтно это потери пакетов > 1%, задержка > 50 мс и пропускная способность < 200 Мб/с), либо с помощью интеллектуального алгоритма, который сам понимает необходимость переключения. Статические политики вы можете задать самостоятельно, на основе эмпирических результатов производительности для отдельных приложений или инфраструктуры в целом.
При работе с соединениями BENIT будет периодически тестировать их характеристики и производить необходимые переключения транспорта для приложений. Это снимает с администраторов и пользователей обязанность самостоятельно производить выбор типа соединения.
Кстати, надо понимать, что переключение транспорта происходит независимо на клиенте и на удаленном десктопе, то есть если на клиенте что-то меняется (например, параметры адаптера), то именно там происходит переключение транспорта, а на десктопе все остается как и было.
Аналитика при переключении транспорта
Здесь все работает таким образом: при использовании одного транспорта и несоблюдении параметров политики по его производительности происходит тестирование сгенерированным трафиком другого канала. Если его характеристики оказываются лучше, происходит переключение на другой транспорт. Но это рождает проблему загрузки сети трафиком тестирования.
Поэтому здесь есть механизм обучения - если, например, произошла серия "плохих" переключений с BEAT на TCP и обратно, то BENIT запомнит эту связь и будет поддерживать TCP-соединение, даже если все требования по переключению будут выполнены.
С точки зрения эффективности переключения на другой транспорт, тут тоже есть 2 механизма:
Lazy switching - если одна порция трафика пока еще целиком не послалась через транспорт, то следующая посылается уже через новый канал, при этом на старом еще некоторое время ожидается квитанция о приеме, и если ее не приходит - то сообщение перепосылается уже через новый канал. Это вызывает некоторую задержку времени переключения, но зато эффективно с точки зрения использования канала.
Rollback and switch - в этом случае недопосланное сообщение аннулируется, происходит мгновенное переключение и перепосылка этого сообщения по новому каналу. Это приводит к максимально быстрому переключению, но часть трафика в канале дублируется.
Некоторые результаты тестирования
Вот так выглядят результаты по FPS при просмотре видео на виртуальном десктопе при использовании протоколов TCP и BENIT в условиях различных сетевых соединений:
Network Profile
BENIT
TCP
Blast Extreme Adaptive Transport
10 Mbps, 20% Loss, 200 ms RTT
13.40 fps
00.65 fps
13.38 fps
10 Mbps, 10% Loss, 200 ms RTT
16.52 fps
02.25 fps
16.52 fps
100 Mbps, 0% Loss, 200 ms RTT
27.52 fps
27.53 fps
25.68 fps
200 Mbps, 0% Loss, 200 ms RTT
28.23 fps
28.25 fps
27.92 fps
А вот результаты по копированию файлов через механизм Drive Redirection:
Network Profile
BENIT
TCP
Blast Extreme Adaptive Transport
10 Mbps, 1% Loss, 50 ms RTT
8.32 Mbps
2.38 Mbps
8.32 Mbps
100 Mbps, 0% Loss, 0 ms RTT
98.8 Mbps
98.8 Mbps
91.28 Mbps
Ну и главное - BENIT позволяет сохранить поток копирования файлов при переключении между соединениями Wi-Fi и 3G/LTE на мобильном интернете или при потере сетевого соединения (по умолчанию настроено время ожидания 120 секунд, его можно изменять):
Cormac Hogan, специалист по отказоустойчивым серверным хранилищам на базе хостов VMware vSAN, написал интересный пост о "растянутых кластерах" (vSAN Stretched Clusters). Это кластеры, которые образуют единое пространство хранения между двумя географически разделенными площадками, в котором продолжают работать различные механизмы обеспечения доступности виртуальной инфраструктуры, например, VMware HA (он восстанавливает отдельные ВМ в рамках площадок, а также всю площадку целиком в случае ее сбоя).
Если вы используете виртуальные ПК на базе полных клонов с инфраструктуре VMware Horizon View, то вы можете исполнять их на растянутом кластере в конфигурации Active/Passive в рамках одного View Pod (набора серверов Connection Server):
Это именно Active/Passive конфигурация, которая поддерживает пользовательские соединения только на одной площадке, вторая находится в резерве, а вся инфраструктура десктопов управляется одним набором серверов View Pod, размещенном на основном сайте:
Такая архитектура позволяет поддерживать единое пространство хранения и репликации в рамках растянутого кластера, реплицируемого на уровне дисковых объектов vSAN между площадками, а не виртуальных машин, как в случае с vSphere Replication.
В случае сбоя нужно будет только запустить серверы View Connection Servers, которые будут управлять виртуальными машинами на резервной площадке, находящимися в актуальном состоянии с точки зрения дисков. Обо всем этом отлично написано в Appendix H соответствующего раздела документации.
Надо отметить, что архитектура Active/Active (когда десктопы активно работают на обеих площадках) в решении Horizon View не поддерживается для растянутых кластеров. Причина в том, что группа серверов Connection Servers в рамках одного сайта (Pod) должна иметь отличное соединение по сети LAN, чему нет гарантий в среде растянутого кластера, когда они разместятся на обеих площадках.
При этом ничего не мешает вам использовать Active/Active-конфигурацию не для растянутого кластера, а для двух Pods с разными кластерами vSAN на каждой из площадок в рамках архитектуры Cloud Pod Architecture (CPA).
Ну а если вы используете non-persistent виртуальные десктопы и связанные клоны (Linked Clones) или мгновенные клоны (Instant Clones), то рекомендация VMware тут та же самая - не использовать растянутый кластер vSAN. Потому что, в отличие от полных клонов, данные дисковых объектов могут создаваться и уничтожаться на лету в больших объемах, что пока еще не поддерживается для единого пространства хранения vSAN.
Вместо этого нужно создавать View Pod на каждой из площадок и поддерживать свой кластер vSAN на уровне каждого сайта, как показано на картинке выше.
Ну и еще момент - решение VMware AppVolumes также не поддерживается в растянутых кластерах VMware vSAN.
В начале августа мы писали об утилите Horizon Helpdesk Utility, которая предназначена для сотрудников службы поддержки, работающих с решением VMware Horizon. Это средство реализует всю функциональность Helpdesk в HTML5 интерфейсе управления VMware Horizon, но поставляется теперь как отдельное решение с расширенными возможностями. На днях Horizon Helpdesk Utility обновилась до версии 1.21.
Помимо самого обновления на YouTube появилось обзорное видео этого продукта:
Так как утилиту перезалили на VMware Labs, у нее отсутствует секция Changelog, поэтому нам не получится узнать, что же там появилось нового:) Доверимся авторам. Кстати, надо отметить, что для работы с этим средством вам понадобится версия VMware Horizon не ниже 7.2 и Enterprise-лицензия.
Если вам не нравятся пороговые значения, на которые ориентируется Horizon Helpdesk Utility при отслеживании метрик, вы всегда можете поправить их в файле:
Интересная штука обнаружилась у пользователей, которые сделали апгрейд на VMware vSphere 6.7. Каждые 30 минут служба SNMPD падает и перестает отвечать, перезапуск сервиса на ESXi помогает, но только на 30 минут.
Оказывается это обычный баг, описанный в KB 57245. Просто-напросто SNMP в VMware vSphere 6.7 не работает (причина в механизме реализации потоков - основной thread не завершается, в то время, как дочерний уже вызывается). На данный момент нет способа обхода проблемы.
Инженеры VMware обещают, что эта ошибка будет исправлена до конца года (we are currently investigating what is causing this issue and hope to have a solution out for this issue later this year), но пока пользоваться SNMP невозможно.
Компания SL Tech, основанная в 2006 году, специализируется на создании современных IT-решений для бизнеса и жизни. Являясь частью группы SEALINE, в которую также входит страховой и перестраховочный брокер с одноименным названием, компания занимает лидирующие позиции среди страховых брокеров России. Ставя в приоритет задачи по разработке и управлению портфелем проектов, предназначенных как для потребителей, так и для поставщиков услуг в высокотехнологичных областях, SL Tech уделяет особое внимание современным технологиям. Вот почему сегодня вся инфраструктура компании вынесена в облако надежного провайдера. Как не допустить ошибок при выборе поставщика услуг, на что обратить внимание при тестировании облачной площадки, какие в целом задачи решает облако – ответами на эти и другие вопросы поделились сотрудники SL Tech.
Специфика бизнеса и особенности деятельности компании
Бренд SL Tech известен своими решениями, которые позволяют расширить возможности существующего бизнеса и получить дополнительный доход. Компания не просто разрабатывает продукты, отвечающие современным запросам клиентов и партнеров, но и непосредственно влияет на формирование новых сегментов рынка.
Команда SL Tech состоит из амбициозных людей, профессионалов в своем деле, увлеченных масштабными и неординарными задачами. Одним из ключевых направлений деятельности компании является создание маркетплейсов. Первые проекты были запущены в сфере финтех- и тревел-индустрии, семейства INSTORE. И это не просто разработка очередного онлайн-сервиса, SL Tech строит высокотехнологичный мост – коммуникацию между клиентами и поставщиками. Благодаря верной стратегии управления и четко заданным векторам развития компания осваивает неохваченные сферы и открывает для себя новые горизонты.
Некоторое время назад мы писали о решении Workspace ONE Intelligence, которое предназначено для анализа поведения пользователей и устройств и выдачи рекомендации администраторам ИТ-инфраструктуры по применению тех или иных действий. На вход этого движка подаются данные об использовании устройств, приложений и данных пользователей, затем они агрегируются, анализируются, а потом для администраторов генерируются некоторые рекомендации и правила, которые можно применить для повышения эффективности инфраструктуры виртуальных ПК и приложений.
В качестве исходной информации Workspace ONE Intelligence использует данные из Workspace ONE UEM и продукта Apteligent (технология отслеживания производительности приложений). Специальный компонент Workspace ONE Intelligence Connector позволяет собрать данные из UEM и отправить их в движок отчетности Intelligence (пользователи SaaS-решения Workspace получают функциональность отчетов сразу из облака). С помощью интегрированных дэшбордов и отчетов администратор может принимать важные решения по конфигурации большой инфраструктуры Workspace ONE.
Давайте посмотрим, что интересного есть в отчетах Workspace ONE Intelligence. Каждый пользователь Workspace ONE может получить Intelligence Reports бесплатно на 30 дней и попробовать полную функциональность решения. Для этого нажать кнопку Get started в разделе Intelligence и пройти по шагам мастера:
После того, как вы заполните все необходимые поля для старта нового триала Intelligence, вам станет доступна функциональность отчетов.
Отчеты могут быть построены по приложениям или устройствам в корпоративной инфраструктуре (для устройств можно, например, вывести отчеты только по non-compliant девайсам). Также вы можете настроить генерацию отчетов по времени, чтобы иметь возможность зайти в консоль и сразу же скачать/посмотреть их.
При создании отчета доступен большой выбор включаемых в него колонок:
А вот так выглядит результат отчета по устройствам:
Также вам будут доступны следующие возможности, средствами которых вы сможете получать необходимые рекомендации по конфигурации среды Workspace ONE:
My Dashboard
Security Risk
Apps Dashboard
OS Updates
Patches
Automation
Apteligent
В общем, тем, кто использует решение Workspace ONE, однозначно имеет смысл попробовать возможности Intelligence (особенно в большой инфраструктуре), тем более, что это средство развивается весьма динамично, и практически ежемесячно появляются все новые отчеты и дэшборды.
Не случайно заголовок поста со знаком вопроса. Пользователи инфраструктуры виртуальных ПК VMware Horizon View не раз задумывались о том, как можно отключить сессию пользователя в случае его неактивности на десктопе и затем потушить гостевую ОС и виртуальную машину (или сделать log off). Это нужно делать, прежде всего, в целях безопасности, чтобы брошенные и неактивные виртуальные ПК не висели доступными для взлома, а, во-вторых, по соображениям экономии аппаратных ресурсов, которые обслуживают неактивные сессии.
Как ни странно, у VMware (в отличие от Citrix) такой настройки из коробки нет (по крайней мере, об этом пишут тут). Если обратиться к статье официальной документации "Configuring Settings for Client Sessions", то мы увидим, что из похожего есть только настройка "Forcibly disconnect users". Она определяет время, через которое происходит отключение сессии пользователя после его логина в систему, но нам хотелось бы задать таймаут неактивности, после которого бы происходило отключение.
Похожей настройки нет и в User Environment Manager. Поэтому пользователи самостоятельно ищут выход из положения. Например, вот тут коллега использует встроенную в Windows утилиту для отключения сейссий tsdiscon.exe. Он пытался найти триггер в UEM, который бы запустил tsdiscon.exe и прервал сессию.
Триггеры в UEM можно добавлять в разделе Conditions:
Он попытался использовать триггер Workstation Locked и выполнить команду tsdiscon:
Однако оказалось, что данный триггер срабатывает не когда десктоп лочится со скринсейвером, а когда пользователь шевелит мышку на этом скринсейвере (и после этого сессия отпадает :).
Поэтому пока выход такой - использовать старинную утилиту Idle Monitor (или похожую), которая определяет время простоя (не двигается мышка и не нажимается клавиатура), а по истечении заданного времени исполняет нужную нам команду:
Эту утилиту можно прошить в золотой образ VMware View и запускать с флагом -h (hidden mode).
Но может есть какой-нибудь способ попроще? Никто не в курсе?
Например, если говорить о Windows Server 2016, то здесь было сделано вот какое улучшение. Теперь паравиртуализованный драйвер хранилищ Paravirtual SCSI (pvscsi) можно официально обновлять через службу Windows Update от Microsoft. Это значит, что если у гостевой ОС есть доступ в интернет, он будет автоматически обновляться.
Но если по каким-то причинам этого не происходит, вы всегда можете обновить драйвер pvscsi вручную через Диспетчер устройств, как это показано в демо ниже:
Понятно дело, что поскольку это драйвер стека работы с хранилищем, то он требует перезагрузки, о чем сообщают свойства контроллера:
Но положительный эффект тут в том, что при обновлении гостевой ОС или любом патче, требующем перезагрузки, накатывание нового драйвера произойдет автоматически. То есть здесь работает принцип одной перезагрузки для применения всех изменений.
В демо ниже можно увидеть, как VMware Tools версии 10.2.0 обновляются на 10.3.0 без перезагрузки (пинг к системе не пропадает), при этом в виртуальной машине используются драйверы pvscsi и vmxnet3 (сетевой адаптер). Их обновления будут применены после следующего обновления Windows, требующего перезагрузки:
RSS
