Компания VMware стремительными темпами развивает свое средство для управления виртуальной инфраструктурой vSphere через браузер на базе технологии HTML5 - VMware HTML5 Web Client. Напомним, что недавно было окончательно объявлено, что следующая версия VMware vSphere не будет иметь "толстого" клиента vSphere Client, сделанного на C#, а старый и тормозной Web Client заменят новым и, возможно, быстро работающем (хотя многие очень сомневаются в этом).
Давайте посмотрим, что нового VMware добавила в последних версиях своего тонкого клиента к vCenter:
Открытие консоли ВМ из контекстного меню действий.
Миграция виртуальной машины в объект "виртуальный сервис" (vApp).
Добавление отдельного хоста ESXi в датацентр или папку Hosts.
Менеджер снапшотов теперь имеет древовидное представление с подробной информацией о каждом снапшоте. Пока еще менеджер снапшотов работает в режиме Read Only. При этом можно откатиться на любой выбранный снапшот.
Выбор спецификации для кастомизации в мастере клонирования ВМ, а также возможность фильтра по гостевым ОС.
Просмотр сообщений об ошибках для случаев, когда ВМ не может включиться в DRS-кластере.
Для кластера VMware HA можно просматривать информацию об ответных действиях в случае сбоя.
Возможность просмотра порт-групп для виртуальных коммутаторов.
Было исправлено несколько серьезных ошибок.
Подробнее о новых обновлениях VMware HTML5 Web Client 1.6 и 1.7, а также загрузить последнюю актуальную версию клиента vSphere можно по этой ссылке.
Компания VMware давненько не выпускала обновления своего главного средства для управления облачной инфраструктурой VMware vSphere. Но в самом конце мая вышел долгожданный апдейт - VMware vCloud Director 8.1. Напомним, что vCloud Director - это продукт, предназначенный для сервис-провайдеров, которые продают ресурсы публичного облака по моделям IaaS/SaaS (рапространяется по программе vCloud Air Network Program).
Основная идея новой версии vCloud Director - это полная поддержка средства сетевой виртуализации корпоративной инфраструктуры VMware NSX, а также нововведения в интерфейсе, которые ранее были доступны только через API-вызовы.
Посмотрим на полный список новых возможностей VMware vCloud Director 8.1:
Expanded UI Access to Features - поддержка функций, ранее доступных только через API, в консоли vCloud Director Web Console.
Virtual Machine Affinity Rules - теперь через vCloud Director Web Console или через vCloud API можно задавать правила раздельного/совместного существования виртуальных машин на хостах ESXi (Affinity Rules).
Object Extensibility - эта новая фича заключается в том, что теперь можно использовать расширения object extensions, представляющие собой внешние приложения, которые дополняют или перекрывают логику vCloud Director для комплексных операций, таких как, например, развертывание виртуальных сервисов vApp.
Advanced Virtual Machine Properties and Host Configurations - если ваш сервис-провайдер включил поддержку кастомных конфигураций ESXi-хостов, то можно использовать метаданные объектов vCenter для виртуальных машин, которые могут быть использованы, например, для корректного плейсмента ВМ на хостах.
VDC Permissions - администраторы облака, отвечающие за конкретных клиентов, могут ограничить доступ к VDC отдельным пользователям или группам.
Tenant throttling - администратор может ограничить объем ресурсов, который потребляет организация или пользователь. Это позволяет убедиться в том, что пользователь не выест все ресурсы в условиях нескольких одновременно запущенных долгосрочных операций.
Unattended Installation - теперь установка возможна в автоматическом режиме с помощью заранее подготовленного сценария.
Expanded Hardware Version and Guest OS support - теперь поддерживается обновленная версия виртуального железа Hardware Version 11, а также гостевые ОС Windows 10.
Полная поддержка последней версии VMware NSX - теперь уже решение VMware vShied Manager не поддерживается, а пользователям vCD предлагается мигрировать на платформу NSX.
Обновиться на vCloud Director 8.1 можно только с версии 8.0 или придется ставить его заново. Скачать решение vCD можно по этой ссылке.
На сайте проекта VMware Labs появилась еще одна полезная утилита для траблшутинга инфраструктуры виртуальных ПК VMware Horizon View. Средство VMware Logon Monitor позволяет собирать необходимую для решения проблем и поддержки информацию с рабочих ПК пользователей во время их логина в свои десктопы.
По умолчанию Logon Monitor собирает следующие метрики:
Время логина
Время старта сессии
Время последней синхронизации профиля
Время загрузки командной оболочки (shell load)
Инициализация механизма Windows Folder Redirection
Инициализация групповых политик
Время старта процессов Windows
Время начала исполнения скрипта групповых политик
Время начала исполнения сценариев PowerShell
Использование памяти
Сопоставляя данные отметки времени, администратор инфраструктуры Horizon View может понять, на каком именно этапе возникает проблема, вызывающая задержку при начале работы пользователя со своим десктопом и приложениями. В качестве настольных ОС поддерживаются Windows 7 и Windows 10, в комментариях пишут также, что Windows 8.1 x64 не поддерживается.
В ближайшее время также ожидается поддержка утилиты VMware Logon Monitor такими продуктами VMware, как Horizon Agent, Horizon Persona Management и механизмом App Volumes.
После установки Logon Monitor не требует никакой конфигурации, однако предоставляет очень гибкий механизм по управлению процессом логирования. Его описание вы можете найти вот в этом документе.
Скачать VMware Logon Monitor можно по этой ссылке.
На прошедшей на днях конференции Citrix Synergy 2016 компания Citrix сделала немало интересных анонсов, например, объявила о выпуске новой версии платформы виртуализации XenServer 7.
Помимо этого, Citrix анонсировала также и решения для автоматизации операций датацентра, в частности продукты Update и Smart Scale, которые предназначены для управления жизненным циклом виртуальных ПК и приложений в рамках единого облачного интерфейса Lifecycle Management.
Первое решение - это Update Service, оно предназначено для обновления компонентов решения XenApp. Решение Update предназначено для облачных окружений (как частных облаков, так и публичных), в которых необходимо поддерживать единый уровень обновлений программного обеспечения. Перед обновлением решение Update позволяет снять снапшот конфигурации текущей версии XenApp, чтобы потом в случае неудачного апдейта откатиться, например, с версии XenApp 7.8 обратно к XenApp 6.x.
Также поддерживается сценарий миграции с продукта для малого бизнеса Citrix VDI-in-a-box (VIAB) на полноценную версию XenDesktop, если предприятие готово расширять свою инфраструктуру.
Второй продукт - это Smart Scale Service, он позволяет масштабировать ресурсы инфраструктуры в зависимости от ее нагрузки. То есть, в 9 утра, когда пользователи приходят на работу, ресурсов под XenApp выделяется больше, а в 18-00, когда нагрузка спадает, ненужные мощности освобождаются. Все это управляется автоматически, без участия администраторов.
Citrix утверждает, что это решение позволяет экономить до 100 тысяч долларов в год для 1000 пользователей предприятия, работающих на XenApp.
Citrix Smart Scale отслеживает такие метрики, как capacity utilization, active sessions, session login, expiry times и многие другие для того, чтобы понять текущую рабочую нагрузку и автоматически выделить под нее ресурсы или освободить их.
Все это выглядит достаточно просто в интерфейсе:
Попробовать сервисы Update и Smart Scale в облаке Citrix можно уже сегодня. Для этого нужно зарегистрироваться по этой ссылке.
О том, как облачные технологии решают проблемы документооборота и меняют подход к его организации, рассказал Антон Аникин — генеральный директор компании «Андок», известной своими решениями по управлению процессами, документами и поручениями на базе системы электронного документооборота (СЭД) DocsVision.
О компании и уникальности облачных услуг
Компания «Андок» — сертифицированный партнер «ДоксВижн» — предлагает решение собственной разработки в рамках услуги СЭД DocsVision доступной в модели SaaS. Решение прошло тестирование сотрудниками «ДоксВижн» и доступно из каталога вендора. Для максимальной безопасности и надежности данных клиентов виртуальная инфраструктура услуги по аренде DocsVision размещена в облаке «ИТ-ГРАД» (IaaS), на базе ЦОД DataSpace уровня Tier III.
Среди компаний, имеющих в своей производственной среде виртуальную инфраструктуру VMware vSphere или Microsoft Hyper-V, многие применяют для защиты виртуальных сред средство vGate R2 от компании "Код безопасности", позволяющее безопасно настроить инфраструктуру согласно различным требованиям с помощью наборов политик, разграничить доступ администраторов, а также защититься от несанкционированного доступа к виртуальным ресурсам.
Новая версия vGate R2 3.0, прежде всего, отличается расширенными возможностями работы в распределенных инфраструктурах и изменением схемы лицензирования. В результате заказчики vGate смогут получить функционал продукта, в наибольшей степени отвечающий целям и задачам организации. Обновленная версия vGate (vGate R2 и vGate-S R2, релиз 3.0) поддерживает расширенный набор инструментов работы с платформами виртуализации VMware vSphere и Microsoft Hyper-V.
Ниже приведены основные нововведения новой версии vGate 3.0:
В vGate 3.0 реализована полнофункциональная работа на платформе VMware vSphere 6. В качестве сервера управления инфраструктурой виртуализации теперь может выступать vCenter Server Appliance (VCSA), а управление ESXi-хостами может осуществляться посредством ESXi Embedded Host Client.
Обновленный продукт осуществляет поддержку управления инфраструктурой на базе Microsoft Hyper-V через System Center Virtual Machine Manager, а управление кластерами Hyper-V реализовано через Failover Cluster Manager.
Для быстрой настройки привилегий пользователей используется ролевая модель доступа. При создании учетной записи можно ограничить доступ по типам объектов, предоставив его, например, только к виртуальным машинам или сетевым объектам.
У продукта появился ряд новых функций для работы в Enterprise-инфраструктурах. Например, реализована поддержка режима горячего резервирования и автопереключение сервера авторизации (High-Availability cluster). В случае потери работоспособности основного сервера в автоматическом режиме происходят переключение на резервный сервер, замена IP-адреса и оповещение администратора.
Обновленная версия продукта позволяет работать с несколькими площадками виртуализации одновременно (этот функционал доступен только в Enterprise-редакции продукта - он будет очень полезен в крупных инфраструктурах). Механизм подключения агента аутентификации к нескольким серверам авторизации vGate дает возможность взаимодействовать со всей территориально распределенной виртуальной инфраструктурой. Построение леса серверов авторизации позволяет устанавливать групповые политики безопасности, а поддержка функции Cross vCenter vMotion обеспечивает в случае аварий миграцию виртуальных машин между серверами с сохранением политик безопасности.
Помимо этого, в vGate версии 3.0 обновлены наборы политик безопасности, обеспечивающие соответствие приказам ФСТЭК России №17 и №21, стандартам СТО БР ИББС, PCI DSS и другие.
Новые версии vGate R2 и vGate-S R2 применимы для защиты конфиденциальной информации и государственной тайны. Продукты прошли инспекционный контроль ФСТЭК России в подтверждение выданных ранее сертификатов соответствия от 28.03.2011 № 2308 и от 12.07.2011 № 2383.
vGate 3.0 можно приобрести в одной из двух редакций: Standard или Enterprise (для которой доступны все функции работы в крупных инфраструктурах). Ниже приведены основные отличия этих изданий:
Получить дополнительную информацию о технических особенностях vGate и направить запрос на получение демо-ключа можно по e-mail: vgateinfo@securitycode.ru. Более подробная информация о решении представлена на странице продукта vGate R2.
Некоторое время назад мы писали про технологическое превью новой версии платформы виртуализации Citrix XenServer "Dundee" Tech Preview 3, а на днях было объявлено о выходе финальной версии Citrix XenServer 7, построенной на ядре Xen 4.6.
Давайте посмотрим на новые возможности XenServer 7:
1. Интеграция с технологиями Microsoft.
Как и всегда, XenServer от Citrix предоставляет новые возможности в этом плане:
Установка драйверов устройств ввода/вывода через Центр обновления Windows. XenServer поддерживает до 1000 ВМ на хосте, поэтому обновление драйверов Windows VM I/O drivers было проблемой до настоящего момента. Теперь же все это можно делать в автоматическом режиме.
Поддержка SMB-хранилищ в качестве общего хранилища (репозитория) для ВМ на XenServer.
Поддержка контейнеров Docker для Windows Server 2016. Ранее Docker поддерживался только для ОС Linux, но теперь добавили и поддержку Windows.
Новый Management Pack для Microsoft System Center Operations Manager (SCOM). Также напомним, что недавно мы писали о Citrix Connector 3.1 for Microsoft SCCM, который теперь поддерживается и работает.
Улучшенная поддержка Active Directory, что позволяет использовать более сложные конфигурации лесов доменов, а также само взаимодействие с каталогом AD работает быстрее.
2. Улучшенная архитектура безопасности платформы.
Совместно с компанией Bitdefender, Citrix разработала интерфейс XenServer Direct Inspect APIs, который позволяет использовать стороннее ПО для защиты гипервизора и виртуальных машин за счет технологии hypervisor memory introspection (HVMI).
На каждый хост ставится отдельный виртуальный модуль в виде ВМ - privileged security appliance (SVA), который контролирует входящий и исходящий поток к виртуальной машине, работая через доступ напрямую к гипервизору.
Ну а Bitdefender - это первый партнер Citrix, который обеспечивает защиту от сетевых угроз. Решение находится пока в стадии Tech Preview.
3. Средства мониторинга собственного состояния (Health Check).
В XenServer 7 была добавлена функциональность самодиагностики в виде Server Status Reports - отчетов, оповещающих о состоянии хост-серверов. Эти отчеты отсылаются на компонент Citrix Insight Services (CIS), который анализирует состояние многих серверов и сигнализирует о неисправностях.
4. Улучшения масштабируемости и производительности.
Здесь можно отметить следующие моменты:
Поддержка до 5 ТБ оперативной памяти на хосте.
Поддержка до 1,5 ТБ оперативной памяти виртуальной машины.
Поддерживает до 288 физических процессоров.
Поддержка до 32 виртуальных процессоров виртуальных машин (vCPU).
Поддержка до 255 VBD (Virtual Block Device) для виртуальной машины на базе технологии Citrix AppDisks.
Поддержка до 4096 VBD (Virtual Block Device) на хост-сервер.
5. Управление хост-серверами XenServer.
Во-первых, появилась возможность запустить SSH-сессию прямо из клиента XenServer:
Во-вторых, средство XenServer Conversion Manager было обновлено и теперь поддерживает пакетную конверсию физических систем на базе последних релизов Windows (включая Windows 10). Также можно переносить виртуальные машины на базе VMware vSphere 6 на XenServer.
В-третьих, расширенная поддержка средств масштабирования позволяет добавлять новые узлы к существующим пулам ресурсов, независимо от типа процессора (при условии, что они одного и того же производителя). Теперь виртуальные машины могут легко мигрировать между пулами.
6. Поддержка ускорения графики средствами Intel GVT Virtual GPU для Windows.
Вильям Лам написал интересный пост об изменении приветственного экрана физической консоли VMware ESXi. Некоторые из вас знают, что внешний вид DCUI-консоли ESXi можно менять в файле /etc/vmware/welcome.
Но руками залезать в него не нужно, вместо этого можно использовать расширенную настройку ESXi Advanced Setting, которая называется Annotations.WelcomeMessage. Ее можно изменить с помощью сценария PowerCLI / PowerShell.
Часто администраторам нужно узнать, на каком из хостов находится виртуальная машина, например, это сервер vCenter, который выключен по тем или иным причинам. В этом случае поможет вывод имен виртуальных машин прямо в физическую DCUI консоль сервера ESXi, к которой можно получить доступ напрямую с сервера или по SSH.
Ниже приведен PowerCLI-скрипта для описанного сценария, в котором все просто и понятно относительно того, как устанавливается рассмотренная выше расширенная настройка для вывода количества и списка виртуальных машин:
Конечно же, если у вас много виртуальных машин на хосте, то они просто не влезут на приветственный экран ESXi, но 15 виртуальных машин у Вильяма влезли без проблем:
Кстати, если вы хотите вывести только включенные виртуальные машины, то вы можете просто добавить фильтр:
-Filter @{"Runtime.PowerState" = "PoweredOn"}
в конце строчки, где используется командлет Get-View.
В крупных компаниях, где виртуальная инфраструктура является основой всего ИТ, иногда используется продукт VMware NSX для виртуализации и агрегации сетей виртуальных (на базе vSphere) и физических сред. Напомним, что с 3 мая этот продукт также стал доступен в трех изданиях, что позволит приобретать его и небольшим компаниям в базовом издании Standard.
Многие из вас используют решение для резервного копирования виртуальных сред - Veeam Backup and Replication, о котором мы часто пишем. Многие, да не все. Те некоторые из вас, кто еще сомневается, подойдет ли это решение для вашей виртуальной инфраструктуры, могут покликать интерактивное демо консоли продукта, где представлены все его основные возможности:
Чтобы начать самостоятельно изучать функциональность консоли, просто выберите одну из понравившихся возможностей, например, кликнем на Verified Protection и выберем функцию SureBackup, которая позволяет убеждаться в том, что резервные копии, которые вы сделали, могут быть восстановлены в производственной среде:
Здесь мы видим, что нам подсвечивают, куда кликать, чтобы мы могли пройти весь процесс по шагам, не задумываясь, куда нужно идти для выполнения задачи.
Ходим по шагам мастера создания задачи New SureBackup Job и смотрим попутно на возможные настройки и интеграции:
Самое интересное в бэкапе - это восстановление. Например, в разделе High Speed Recovery можно увидеть, как восстанавливаются отдельные файлы виртуальных машин с гостевой ОС Linux:
Какие-то фичи показывают из восьмой версии Veeam Backup and Replication, а какие-то из девятой (с обновленной и более современной консолью продукта). Например, вот мастер восстановления объектов для Oracle:
В общем, очень полезная штука, чтобы понять, какие возможности на деле предоставляет продукт Veeam B&R. Кликайте!
Компания StarWind Software, выпускающая лучший продукт Virtual SAN для создания отказоустойчивых хранилищ под виртуализацию VMware и Microsoft, выпустила интересный документ "StarWind Storage Appliance Overview".
StarWind Storage Appliance - это готовый к развертыванию инфраструктуры хранилищ для гипервизоров VMware ESXi и Microsoft Hyper-V программно-аппаратный комплекс, который можно просто масштабировать по емкости путем приобретения новых узлов, при этом обеспечивается отказоустойчивость всей подсистемы хранения:
Более подробно о таких функциях StarWind Storage Appliance, как файловая система Log-Structured File System (LSFS), серверное кэширование, дедупликация, компрессия данных при передаче, асинхронная репликация и многое другое, вы можете прочитать в документе, а также по этой ссылке.
Зачастую в тестовом окружении вам нужно создать несколько томов VMFS (например, для тестирования технологии Storage DRS и создания кластера хранилищ), но диск на машине только один. В этом случае можно вручную нарезать этот диск на разделы и отформатировать их в тома VMFS 5, которые будут использоваться в качестве виртуальных хранилищ.
Для этих целей можно использовать 2 утилиты, входящие в состав VMware ESXi 6 - PartedUtil и vmkfstools. Помните, что метод, изложенный ниже, не поддерживается для производственных систем. Используйте его только в тестовом окружении!
Итак, заходим на хост ESXi, напрямую или по SSH. Сначала нужно найти имя устройства. Для этого можно воспользоваться командой:
fdisk –l
Либо для подробной информации можно взять следующую:
esxcli storage core path list
В качастве вывода мы получим что-то вроде этого:
sata.vmhba34-sata.0:0-t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288
UID: sata.vmhba34-sata.0:0-t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288
Runtime Name: vmhba34:C0:T0:L0
Device: t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288
Device Display Name: Local ATA Disk (t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288)
Adapter: vmhba34
Channel: 0
Target: 0
LUN: 0
Plugin: NMP
State: active
Transport: sata
Adapter Identifier: sata.vmhba34
Target Identifier: sata.0:0
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
Maximum IO Size: 33553920
Можно сделать это и из vSphere Client:
Далее получаем таблицу разделов следующей командой (имя диска берем из поля Device):
Диск этот пуст, и мы получим примерно такой вывод:
msdos
29185 255 63 468862128
Например, вы хотите создать на этом диске 5 разделов (LUN) по 10 ГБ каждый. При размере сектора 512 байт, размер каждого такого диска будет 20971519 секторов. При этом первые 2048 секторов диска надо пропустить, чтобы оставить место под GPT-таблицу и выровнять разделы по лучшим практикам (под 512-байтные секторы).
Получаем следующий план разбиения разделов с номерами начальных и конечных секторов:
Аналогичные действия нужно будет проделать и с оставшимися четырьмя датасторами, после чего они станут видны в клиенте vSphere. Более подробно о процедуре изложено в KB 1009829.
Компания VMware на днях распространила официальную информацию о том, что клиент vSphere Client, написанный на C#, не будет выпущен для следующей версии платформы vSphere (вероятно, седьмой). Вместо него будут использоваться средства управления на базе двух следующих веб-платформ:
VMware vSphere HTML5 Web Client для управления инфраструктурой виртуализации через VMware vCenter (о нем мы писали вот тут). Он построен на базе технологии HTML5 и полностью заменяет собой функционал тонкого клиента VMware vSphere Web Client, который сейчас работает на основе тормозной технологии Adobe Flex (он же Flash). Он включает в себя консоли Platform Services Controller UI и vCenter Server Appliance Management UI.
Причины окончательного перехода на тонкие клиенты со стороны VMware очевидны - трудно поддерживать и тонкий, и толстый клиенты в рамках одного набора функционала, который у VMware очень и очень широкий. Многие из вас помнят, как VMware долгое время не могла включить Update Manager в состав Web Client, так как функционал там достаточно сложные. Ну и плюс к этому все больше пользователей управляют сервисами vCenter с маков, а также мобильных устройств - планшетов и телефонов, где полноценного толстого клиента просто нет. Ожидается, что тонкий клиент HTML5 будет поддерживать также и мобилки (на данный момент эта поддержка сильно ограничена).
Самое интересное в этом то, что прямо сейчас VMware не имеет релизной версии HTML5 Web Client, а только некий продукт, находящийся в статусе Technical Preview на сайте проекта VMware Labs (который, однако, весьма часто обновляется и поддерживается). Обещают, что в новой версии платформы клиент на базе HTML5 будет уже полностью готов, и переход на него пройдет безболезненно, но мы-то с вами знаем, что это не так. Новые пользователи обязательно выступят "тестировщиками" первой версии продукта. Кроме того, каков бы ни был тонкий клиент на HTML5, он все равно не будет работать так быстро, как C#-клиент, к которому привыкли многие пользователи.
Как раз вокруг этого и развернулась нешуточная дискуссия вот в этом посте, где недовольные администраторы жалуются на поведение VMware. В частности, среди минусов приводится неунифицированная среда Host Client и HTML5 Client, возможные проблемы совместимости в разных версиях браузеров, замороченность и сложность пользовательского интерфейса Web Client и прочее. И они правы - проблемы неизбежны. Например, у меня вечером обновился Google Chrome, а утром я узнал, что управление виртуальными машинами у меня в корпоративной инфраструктуре из 1000 хостов не работает.
На сайте проекта VMware Labs появилось интересное средство - VMware GOLD vApp STIG Assessment and Remediation Tool (START), которое представлет собой Docker-контейнер, способный обследовать любую удаленную Linux-систему по протоколу Security Content Automation Protocol (SCAP) в реализации OpenSCAP и исправить найденные уязвимости согласно стандарту STIG (Security Technical Implementation Guide).
На базе преконфигуренных шаблонов утилита START может обнаруживать уязвимости в других системах, после чего к ним можно применять различные действия средствами Ansible. Вы также можете видеть результаты обследования и исправления систем (assessment reports, remediation reports и hardening reports). Отчеты имеют метку времени и детали о каждой машине для быстрой идентификации системы. Кроме того, можно проверить последние полученные отчеты на различия в соответствии, а также можно указать произвольные xml-файлы отчетов для сравнения.
При проверке соответствия системы возможны два действия с найденными проблемами: remediation и hardening. Различие между ними в том, что при remediation фиксы накладываются только для тех пунктов, где найдено несоответствие системы определенной в шаблоне конфигурации, а при hardening накладываются все фиксы, независимо от текущего состояния системы.
VMware выпустила большую серию обучающих видеороликов, разъясняющих подробности работы утилиты START:
Если вы часто заходите на хост-серверы VMware ESXi по SSH, то вам может оказаться полезным плагин sshAutoConnect для vCenter, который позволяет добавить соответствующий пункт в контекстное меню vSphere Client для хостов ESXi.
Плагин sshAutoConnect состоит из двух файлов - xml, который определяет конфигурацию плагина, и, собственно, dll-библиотека с плагином. Инсталляция плагина проста - нужно положить эти два файла в отдельную папку в папке плагинов vCenter по адресу:
sshAutoConnect соединяется с хостами ESXi по логину и паролю, указанному в секции <default>, но если в разделе <custom_servers> есть логин и проль для конкретного хоста - будут использованы эти данные. Пароли тут записаны в виде base64, о том, как их получать написано вот тут.
Ну и загрузить плагин sshAutoConnect вместе с исходным кодом можно с репозитория на GitHub по этой ссылке.
Какое-то время назад мы писали о том, что технология дедупликации страниц памяти Transparent Page Sharing (TPS) с приходом больших страниц памяти становится ненужной (а в последних версиях vSphere и вовсе она отключена). Но это не значит, что сейчас TPS нигде не используется совсем - ведь большие страницы, при условии недостатка ресурсов памяти на хост-сервере, гипервизор ESXi может разламывать на маленькие, после чего дедуплицировать их.
Между тем, в последних релизах VMware vSphere, включая ESXi 6.0, появилась более гранулярная модель управления механизмом TPS, который можно задействовать для отдельных групп виртуальных машин (например, серверы обрабатывающие одни и те же данные, где вероятность дубликатов страниц высока). Называется этот механизм Salting (хэширование с солью).
Как известно, TPS производит хэширование страниц памяти виртуальных машин, после чего происходит сравнение хэшей на предмет их совпадения. Если они совпадают, то начинается побитовое сравнение этих страниц памяти, чтобы исключить ложное срабатывание дедупликации страниц (потому что, как известно, у двух разных исходных строчек теоретически может быть один хэш).
Если страницы полностью совпадают - вносятся изменения в таблицу страниц памяти, где для второй копии ставится просто ссылка на первую, а физически вторая копия страницы уничтожается.
При любой попытке записи в такую страницу со стороны виртуальной машины - мгновенно создается ее физическая копия с помощью механизма copy-on-write (CoW), и она уже перестает быть шаренной (каждая машина начинает использовать свою копию).
Так вот в последних версиях VMware vSphere механизм TPS работает не так просто. По умолчанию используется Salting, а в качестве этой самой соли используется UDID виртуальной машины, который всегда уникален для данного сервера vCenter. То есть перед снятием хэша со страницы памяти происходит добавление соли к исходным данным, а поскольку соль одинакова только для конкретной ВМ, то и дедупликация страниц со стороны TPS происходит только на уровне отдельной виртуальной машины (Intra-VM TPS).
Механизм Salting используется по умолчанию, начиная со следующих версий гипервизоров:
ESXi 5.0 Patch ESXi500-201502001
ESXi 5.1 Update 3
ESXi 5.5, Patch ESXi550-201501001
ESXi 6.0
Управлять этим механизмом можно из расширенных настроек хоста VMware ESXi (Advanced Settings, раздел Mem). По умолчанию используется расширенная настройка Mem.ShareForceSalting в значении 2. Это означает, что salting включен и работает Intra-VM TPS.
Если же мы поставим эту настройку в значение 0, как на рисунке выше, то соль перестанет добавляться к хэшу при работе алгоритма TPS, а значит он будет работать для всех виртуальных машин на хосте (Inter-VM TPS).
Ну и, как становится понятным, TPS можно включить для отдельной группы виртуальных машин на хосте ESXi, для чего нужно использовать одинаковую соль для этих виртуальных машин. Для этого в расширенных настройках виртуальной машины нужно добавить параметр sched.mem.pshare.salt с одинаковым значением у всех нужных вам ВМ (это также можно сделать и в vmx-файле).
В этом случае значением настройки Mem.ShareForceSalting должно быть 1 или 2 (разницы тут особой нет, кроме того, что если у вас используется значение 1, то при отсутствии соли включится Inter-VM sharing).
Ну и в таблице ниже приведем различия в работе алгоритма TPS для различных значений Mem.ShareForceSalting и в зависимости от заполненности sched.mem.pshare.salt для виртуальных машин.
Значение Mem. ShareForceSalting (настройка уровня хоста)
Значение sched.mem.pshare.salt (настройка уровня ВМ)
vc.uuid (свойство ВМ)
Значение соли в настройках ВМ
TPS между виртуальными машинами (Inter-VM)
TPS внутри каждой из ВМ (Intra-VM)
0
Игнорируется
Игнорируется
0
Да, между всеми машинами на хосте
Да
1
Установлено
Игнорируется
Используется sched.mem.pshare.salt
Только между ВМ с одинаковой солью
Да
1
Не установлено
Игнорируется
0
Да, между всеми машинами на хосте
Да
2
Установлено
Игнорируется
sched.mem.pshare.salt
Только между ВМ с одинаковой солью
Да
2
(по умолчанию)
Не установлено (по умолчанию)
Используется
Используется vc.uuid
No inter-VM TPS
Да
2
Не установлено
Отсутствует по какой-либо причине
Используется случайный номер для каждой ВМ
No inter-VM TPS
Да
Для более детальной информации вы можете обратиться к статье KB 2097593.
Синхронная репликация Microsoft Storage Replica работает так:
1. Приложение записывает данные.
2. Записываются данные журнала (логи) и данные уходят на резервную площадку.
3. На удаленной площадке также записываются логи.
4. С резервной площадки приходит подтверждение записи данных.
5. Для приложения запись данных считается подтвержденной.
Для асинхронной репликации процесс можно представить следующим образом:
1. Приложение записывает данные.
2. Записываются данные журнала (логи).
3. Для приложения запись данных считается подтвержденной.
4. Данные уходят на резервную площадку.
5. На удаленной площадке также записываются логи.
6. С резервной площадки приходит подтверждение записи данных.
Ну и сотрудники StartWind во главе с Антоном решили протестировать Microsoft Storage Replica в рамках четырех различных сценариев. По ссылкам ниже вы можете почитать о результатах этого тестирования:
Компания Citrix в 2014 году выпустила средство интеграции решений XenApp/XenDesktop со средством управления конфигурациями Microsoft SCCM, которое называлось Citrix Connector 7.5 for System Center Configuration Manager. Однако в последующих релизах SCCM компания Microsoft изменила объектную модель в продукте, вследствие чего коннектор Citrix престал работать.
На днях Citrix выпустила Citrix Connector 3.1 for Microsoft SCCM, который возвращает возможности интеграции с SCCM последних версий и приносит новые возможности для управления корпоративной инфраструктурой. Коннектор от Citrix позволяет публиковать приложения прямо из консоли ConfigMgr на Storefront и Receiver через XenApp, а также развертывать пакеты виртуальных приложения App-V на XenApp.
Новый коннектор поддерживает следующие вещи в плане интеграции с SCCM:
System Center Configuration Manager 1511 и более поздние версии (ConfigMgr 2012 SP1, R2 и R2 SP1 также поддерживаются).
Поддержка продукта XenDesktop 7.6, 7.7 и 7.8.
Также коннектор добавляет несколько следующих новых возможностей:
Синхронизация каталогов машин и delivery groups XenDesktop в окружение ConfigMgr.
Развертывание софта на все типы каталогов XenApp и XenDesktop (PVS, MCS, физические машины и прочее).
Поддержка MSI и приложений App-V.
Отчетность об успешно/неуспешно развернутых приложениях.
Публикация приложений из консоли ConfigMgr на Storefront и Receiver через XenApp.
Развертыание HDX-совместимых приложений на компьютеру, которые уже находятся под управлением SCCM.
Параллельная работа совместно с XenApp 6.5 Connector.
Почти все из вас, кто делает резервные копии виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V, делают это с помощью продукта Veeam Backup and Replication. Многие администраторы задаются вопросом - а сколько конкретно места нужно на диске для хранения резервных копий и точек восстановления в соответствии с настроенной политикой резервного копирования (тип бэкапа, частота и число этих Restore Points).
Вот тут вот выложили простой, но очень полезный калькулятор/симулятор необходимой дисковой емкости, которую вам потребуется заложить под хранение резервных копий Veeam Backup and Replication. В качестве исходных данных принимаются следующие параметры инфраструктуры и задач резервного копирования (backup jobs):
Тип резервного копирования (инкрементальное/полное).
Объем данных виртуальных машин.
Число хранимых точек восстановления.
Оценка изменения данных за период между бэкапами в процентах.
Коэффициент компрессии полного или инкрементального бэкапа.
Частота резервного копирования.
Также можно симулировать рост данных исходных ВМ в процентах на нужное количество лет.
Как вы видите, для инкрементальных бэкапов можно задать дни и месяцы, когда нужно делать полный бэкап виртуальных машин. Кроме того, в верхней части есть уже готовые шаблоны настроенных политик резервного копирования:
Результатом симуляции будет следующий расчет с привязкой датам при создании файлов vbk и vib определенного размера (обратите внимание, что нужно также закладывать емкость на различные рабочие операции на хранилище):
На прошлой неделе компания VMware обновила не только клиент для управления хостами VMware ESXi Embedded Host Client до версии 8, но и выпустила обновление нового тонкого клиента для управления виртуальной инфраструктурой vSphere HTML5 Web Client 1.4. Напомним, что в конце апреля мы уже писали про новые возможности версии HTML5 Web Client 1.2, а ниже рассмотрим новые возможности сразу двух версий - 1.3 и 1.4, которые были выпущены с очень небольшим интервалом совсем недавно.
Итак, что нового в vSphere HTML5 Web Client 1.3/1.4:
Теперь при создании виртуальной машины можно выбрать кластер хранилищ (datastore cluster) в качестве хранилища ВМ (но пока нельзя отключить DRS).
Возможность загрузить файл на Datastore ([Datastore] -> Manage -> Files). При этом не требуется Client Integration Plugin.
Виртуальные машины теперь можно мигрировать между пулами ресурсов (Resource Pools).
Лучше стало работать добавление устройств к виртуальной машине - теперь есть единое меню.
Имена файлов самого виртуального модуля теперь отражают версии клиента (OVA и RPM).
В Inventory теперь больше информации о виртуальных сервисах vApps.
Появилась возможность редактирования настроек SCSI-контроллера.
Появилась возможность горячего удаления CD/DVD-приводов.
Также было исправлено несколько серьезных багов, список которых приведен вот тут.
Скачать последнюю версию vSphere HTML5 Web Client 1.4 можно по этой ссылке.
Компания StarWind Software, производитель лучшего решения для создания программных iSCSI-хранилищ под виртуализацию, весьма часто проводит практические вебинары, посвященные отдельным аспектам настройки своего продукта. Некоторое время назад сотрудники компании рассказывали о том, как обновить Virtual SAN без простоя инфраструктуры, а также о настройке решения StarWind VTL. В этот раз речь пойдет о правильной настройке сетевых интерфейсов Virtual SAN для доступа к хранилищам по протоколу iSCSI (инициатор и таргет), а также необходимой конфигурации сетевых интерфейсов на хосте хранения.
Мы уже много писали про клиент для управления хост-серверами VMware ESXi Embedded Host Client, который поставляется в виде виртуального модуля, доступного на сайте проекта VMware Labs. Начиная с версии VMware vSphere 6.0 Update 2, он вошел в стандартную поставку ESXi (клиент седьмой версии). Но сам Embedded Host Client продолжает также развиваться и как отдельный проект. На днях было выпущено обновление - VMware ESXi Embedded Host Client v8.
Посмотрим на основной список новых возможностей Host Client:
Основное
Таблицы (гриды) теперь с фильтрами/поиском и подсветкой по паттерну поиска.
Большинство таблиц поддерживает контекстное меню по правой кнопке для колонок.
Автоисправление конфигурации прокси, когда обнаруживаются конфликты путей.
Исправления приветственной страницы: нет ошибки JSON Parse error, поддержка директив {ignore}{/ignore} и {accept}Message beside checkbox{/accept} (для того, чтобы заставить пользователя принять условия показываемого при логине сообщения). Делается это в файле /etc/vmware/welcome.
Улучшения отображения интерфейса в разделе производительность: поиск/фильтры, улучшенное отображение линий и т.п.
Хост ESXi
Поддержка опций VSAN maintenance mode.
Фиксы багов Advanced Configuration.
Улучшенное отображение аппаратных сенсоров.
Виртуальные машины
Добавление звуковых контроллеров в ВМ.
Улучшенная валидация при добавлении последовательных портов.
Улучшенный интерфейс для Advanced Settings виртуальной машины.
Пофикшены некоторые проблемы при редактировании настроек ВМ на ESXi 5.0.
Поддержка добавления/удаления пробрасываемых USB-устройств (passthrough). На данный момент это доступно только для включенных машин.
В раздел мониторинга производительности были добавлены подразделы Disk и Network.
Теперь можно импортировать OVA любого размера + мастер стал удобнее и быстрее.
Больше функций по отсылке комбинаций клавиш в гостевую ОС (Ctrl-c, например).
Доступ к меню действий, когда консоль находится в полноэкранном режиме.
Возможность загрузки VMRC-консоли напрямую с хоста ESXi.
Пофикшен баг с отображением представления VM summary, которое запрашивало пароль.
Пофикшен баг при изменении масштаба консоли.
Поддержка португальской клавиатуры.
Отображение полной информации об IP-конфигурации ВМ в summary.
Хранилища
Поддержка конфигурации software iSCSI: Enable/disable, Authentication settings, Advanced configuration, Add/remove port bindings, Add/remove static targets, Add/remove dynamic targets.
Отображение статуса устройства (включая условия ошибок iSCSI) теперь более очевидно - она на иконке в таблице устройств.
Сеть
Возможность изменения MTU для интерфейса VMkernel.
Улучшенная работа с правилами фаервола.
Пофикшен баг с редактированием интерфейсов VMkernel для ESXi 5.5.
Скачать VMware ESXi Embedded Host Client v8 можно по этой ссылке.
Некоторые из вас слышали о продукте VMware NSX, которые представляет собой платформу для виртуализации сетей виртуальных (на базе vSphere) и физических сред, которая ранее была доступна только для крупных предприятий ввиду своей высокой цены.
С 3 мая компания VMware решила изменить этот подход, представив решение NSX в трех изданиях - Standard, Advanced и Enterprise. Теперь и небольшие компании смогут использовать издание Standard за меньшую цену и постепенно расти до издания Enteprise, если возникнет потребность в большем функционале платформы.
Все три издания лицензируются по физическим процессорам серверов (чтобы соответствовать изданиям VMware Virtual SAN), однако издание Advanced лицензируется также и по пользователям, чтобы NSX было удобно применять в VDI-средах.
В целом издания VMware NSX можно описать так:
Standard - это базовые возможности распределенной коммутации и маршрутизации, которые подходят для совместного использования с vSphere Standard. Вы сможете создавать сети VXLAN в виртуальной инфраструктуре и соединять их с физической сетью предприятия с помощью NSX Edge, но остальные интересные возможности NSX будут недоступны, так как Distributed Firewalling и балансировка нагрузки. Также доступна интеграция с OpenStack через API.
Advanced - это уже более интересное издание, здесь уже есть интеграция с Active Directory и такие компоненты, как Edge load balancing и Distributed Firewall. Но здесь еще нет возможностей VPN и поддержки нескольких сайтов со своими vCenter. Это издание подойдет большинству пользователей, у которых есть только один датацентр. Также его удобно использовать для создания сетевой платформы инфраструктуры виртуальных ПК.
Enterprise - это полнофункциональное издание для большой сетевой инфраструктуры, а также предприятий с несколькими ЦОД, в которых присутствует несколько серверов vCenter, объединенных между собой. Тут также присутствуют функции распределенной балансировки (пока только в режиме Tech Preview).
Приведем ниже полное сравнение возможностей изданий VMware NSX 6.2, а краткое доступно вот тут.
NSX for vSphere 6.2
Возможность
Standard
Advanced
Enterprise
Hypervisors supported
ESXi 5.5
ESXi 6.0
vCenter 5.5
vCenter 6.0
Cross vCenter Networking & Security
Controller Architecture
NSX Controller
Universal Controller for X-VC
Optimized ARP Learning, BCAST supression
Switching
Encapsulation Format
VXLAN
Replication Mode for VXLAN
Multicast
Hybrid
Unicast
Overlay to VLAN bridging
SW Bridge (ESXi-based)
Hardware VTEP (OVSDB) with L2 Bridging
Universal Distributed Logical Switching (X-VC)
Multiple VTEP Support
Routing
Distributed Routing (IPv4 Only)
Distributed Routing - Static
Distributed Routing - Dynamic Routing with BGP
Distributed Routing - Dynamic Routing with OSPF
Equal Cost Multi-Pathing with Distributed Routing
Universal Distributed Logical Router (X-VC)
Dynamic Routing without Control VM (Static Only)
Active-standby Router Control VM
Edge Routing (N-S)
Edge Routing Static - IPv4
Edge Routing Static - IPv6
Dynamic Routing with NSX Edge (BGP) IPv4
Dynamic Routing with NSX Edge (OSPFv2) IPv4
Equal Cost Multi-Pathing with NSX Edge
Egress Routing Optimization in X-VC
DHCP Relay
Active-Standby NSX Edge Routing
VLAN Trunk (sub-interface) support
VXLAN Trunk (sub-interface) support
Per Interface RPF check on NSX Edge
Services
NAT Support
NAT Support for NSX Edge
Source NAT
Destination NAT
Stateless NAT
ALG Support for NAT
DDI
DHCP Server
DHCP Relay
DNS Relay
VPN
IPSEC VPN
SSL VPN
L2 VPN (L2 extension with SSL VPN)
802.1Q Trunks over L2 VPN
Security
Firewall - General
Single UI for Firewall Rule Enforcement - NS+ EW
Spoofguard
Firewall Logging
Rule Export
Auto-save & Rollback of Firewall rules
Granular Sections of Firewall rule table
Distributed Firewall
DFW - L2, L3 Rules
DFW - vCenter Object Based Rules
Identity Firewall Rules (AD Integration)
IPFix Support for DFW
Context-based control of FW enforcement
(applied to objects)
Компания VMware выпустила весьма полезный документ "VMware Virtual SAN 6.2
Network Design Guide", в котором приведены конкретные рекомендации по настройке и конфигурации сети при организации отказоустойчивых кластеров хранилищ.
Посмотрим, какие интересные моменты есть в документе. Например, рассматривается следующая архитектура построения кластера Virtual SAN (это Leaf-Spine архитектура):
В такой сети показатель переподписки (oversubscription) между стойками равен 4:1 (от хостов идет 16 линков по 10 Гбит к свичу, от которого идет 4 линка по 10 Гбит к Spine-коммутатору). В этом случае, если предположить, что на хостах 10 ТБ емкости, из которых 6 ТБ занимают данные виртуальных машин, и вдруг возникнет необходимость операции rebuild для кластера (при FTT=1), то при использовании 3/4 пропускной способности канала (то есть 30 Гбит/с) операция займет 26 минут. Если же объем данных на хосте увеличить до 12 ТБ, а канал уменьшить до 10 Гбит/с, то rebuild займет 156 минут. Мораль такова - нельзя перебарщивать с переподпиской, а также нужно обеспечить широкий канал между узлами кластера.
Еще из рекомендаций в документе:
Отключите Flow Control на физическом оборудовании, у Virtual SAN есть свой механизм контроля перегрузки канала.
Используйте vSphere Distributed Switch (VDS) совместно с Virtual SAN.
Настройте Load Based Teaming (LBT), который балансирует нагрузку, в зависимости от загрузки физического адаптера (похоже на Virtual Port ID, только привязка к порту пересматривается каждые 30 секунд).
Если используете несколько кластеров Virtual SAN - помещайте трафик каждого из них в отдельный VLAN.
Если в датацентре используются большие кадры jumbo frames - используйте их в кластере Virtual SAN, но если не используются - то отдельно включать их не надо.
Включите Cisco Discovery Protocol (CDP) и Link Layer Discovery
Protocol (LLDP) в режимах и приема, и передачи.
В документе присутствует еще несколько интересных рекомендаций, прочитать которые будет особенно интересно администраторам крупных инфраструктур и больших кластеров Virtual SAN.
Интересный пост написал Duncan Epping о растянутом кластере (Stretched Cluster) Virtual SAN и обработке события изоляции площадки механизмами HA и VSAN. Изложим тут его вкратце.
Как вы знаете, растянутый кластер Virtual SAN состоит из трех компонентов - две площадки с хранилищами VSAN и виртуальными машинами и одна площадка, выступающая как "свидетель" (Witness) и необходимая для принятия решения о том, какая площадка выпала из внешнего мира (то есть с ней нет связи), а какая способна продолжать поддерживать работу виртуальных машин (как в плане хранения, так и в плане исполнения на вычислительных ресурсах хостов).
Таким образом, обычно схема растянутого кластера выглядит так:
Теперь, допустим, на основной площадке (Site 1) произошла авария - и хосты ESXi с виртуальными машинами стали частично или полностью недоступны. При этом теряется ее связь как со второй площадкой (Site 2), так и с компонентом Witness на третьей площадке.
В этом случае происходит следующее:
Хосты площадки Site 1 имеют связь между собой, события внутренней изоляции не происходит, поэтому HA не реагирует на ситуацию.
Однако кластер Virtual SAN понимает, что площадка Site 1 изолирована от Site 2 и Witness (нет кворума), а значит и от внешнего мира, поэтому принимает решение выключить виртуальные машины. Это поведение можно изменить, установив расширенную настройку VSAN.AutoTerminateGhostVm в значение 0 (но делать это не рекомендуется).
На второй площадке (Site 2) происходят выборы нового Master-узла в кластере VMware HA. Этот узел сверяется со списком protectedlist (в нем пока нет машин из Site 1), добавляет новые ВМ туда и берет на себя владение машинами с первого узла, так как теперь есть кворум у второй площадки. Что такое кворум? Это 2 компонента из трех (большинство) в растянутом кластере - сама эта площадка и компонент Witness (они видят связь друг с другом). Таким образом, VMware HA на второй площадке начинает восстановление виртуальных машин первого сайта.
Как VMware HA убеждается, что на первой площадке эти машины выключены? Да никак - просто по дизайну заложено, что кластер Virtual SAN в случае изоляции площадки Site 1 потушит все ее виртуальные машины, поэтому владение этими машинами перейдет ко второй площадке.
Ну и, конечно же, тут нельзя не порекомендовать интереснейший документ VMware vSphere 6.x HA Deepdive, в котором есть все ответы на подобные вопросы.
Как многим из вас известно, компания StarWind делает лучшее в отрасли решение Virtual SAN для создания программных отказоустойчивых хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V. А поскольку этот продукт находится на самом нижнем уровне и обеспечивает хранение виртуальных машин, важно, чтобы операции с ним, такие как обновление или реконфигурация, проходили прозрачно для виртуальных машин, без простоя виртуальной инфраструктуры.
Как многие из вас знают, в последней версии решения VMware Horizon 7 появился механизм аутентификации True SSO. Эта штука связывает средство единой аутентификации VMware Identity Manager с решением VMware Horizon 7 для решения задач одноразовой аутентификации пользователя различными методами (пароль, смарт-карта и т.п.), чтобы после этого он получал доступ к своему виртуальному ПК и приложениям без дополнительной аутентификации в Active Directory.
Задача эта важна, поскольку, например, VMware Horizon View используется в медицинских учереждениях, а там важно, чтобы врач получал мгновенный доступ к своему ПК, который может быть виртуальным. С помощью True SSO он теперь может просто приложить смарт-карту, после чего получит доступ к своим виртуальным ресурсам, на которые даны разрешения в инфраструктуре VMware View.
VMware Identity Manager Standard включен в издания VMware Horizon 7 Advanced и Enterprise, поэтому вы сразу можете приступать к работе через механизм True SSO. Суть работы этого механизма такова - сначала пользователь авторизуется через принятый в компании метод авторизации. Это может быть один из следующих (то, что поддерживает Identity Manager):
RSA SecurID
Kerberos
RADIUS authentication
RSA Adaptive Authentication
Сторонние провайдеры аутентификации, например, биометрические системы.
Далее пользователь уже может запустить любой десктоп или hosted-приложение уже без необходимости ввода своих паролей в Active Directory или какой-либо другой аутентификации. True SSO использует механизм SAML (Security Assertion Markup Language) для того чтобы передать User Principal Name (например, jdoe@example.com) к службе аутентификации, чтобы получить доступ к учетной записи AD. Затем Horizon 7 генерирует краткосрочные сертификаты для логина в гостевую ОС Windows виртуального ПК.
Преимущества этого метода таковы:
Отделение процесса аутентификации от непосредственно доступа к виртуальному ПК и приложениям (пользователь точно знает, что аутентифицироваться он будет лишь однажды - как подошел к компьютеру).
Повышенная безопасность - весь обмен идет на базе сертификатов, и пароли не гуляют по датацентру.
Поддержка большого набора методов аутентификации, приведенных выше. Если мы захотим поменять используемый метод - это не затронет инфраструктуру в целом.
Вот как работает True SSO:
1. Пользователь аутентифицируется в VMware Identify Manager одним из способов описанных выше. После этого пользователь выбирает десктоп или приложение из доступных ему, которое он хочет запустить, в консоли VMware Identity Manager.
2. Запускается Horizon Client под учетными данными пользователя, а его креды перенаправляются на View Connection Server.
3. View Connection Server валидирует идентификацию пользователя в Identify Manager путем отсылки SAML-запроса.
4. За счет использования службы Enrollment Service, Horizon 7 просит службу Microsoft Certificate Authority (CA) сгенерировать временный сертификат от имени пользователя.
5. Horizon 7 показывает этот сертификат ОС Windows виртуального ПК.
6. Windows аутентифицирует через этот сертификат пользователя в службе Active Directory.
7. Пользователь логинится в Windows-десктоп или приложение, а удаленная сессия обслуживается через Horizon Client.
Для работы механизма True SSO вам понадобится отдельная служба Enrollment Service, которая может быть развернута на машине с ОС Windows Server 2008 R2 или Windows Server 2012 R2 (4 ГБ оперативной памяти будет достаточно). Сам True SSO поддерживается для всех клиентских Windows-систем, а также протоколов доступа к виртуальным ПК, включая Blast Extreme и HTML Access.
Компания ИТ-ГРАД приглашает Вас принять участие в бесплатном тренинге, посвященном технологиям Veeam и NetApp для обеспечения непрерывности бизнеса.
Основные вопросы, которые будут затронуты на мероприятии:
Backup составляет чрезвычайно важную часть плана обеспечения непрерывности бизнеса в любой организации, но требует больших ресурсов. Как оптимизировать затраты и организовать безотказную работу компании?
Как с помощью уникальных технологий NetApp можно обеспечить отсутствие простоев и эффективное перемещение продуктивных данных между облаками?
На мероприятии вы узнаете:
Об организации высокой доступности и защите данных средствами СХД NetApp
Об увеличении скорости бэкапа и восстановления данных при совместной работе Veeam и NetApp
О преимуществах хранения бэкапа в облаке провайдера.
Кроме того, увидите техническую демонстрацию резервного копирования в облако провайдера.
Дата и время: 18 мая 2016г.,
10.00 - 14.00 Место: Holiday Inn - Simonovsky, Зал Крутицкий, Москва, ул. Симоновский Вал, 2
На днях компания Veeam Software, известная своим лучшим в отрасли продуктом для защиты и мониторинга виртуальных сред Veeam Availability Suite (о котором мы писали вот тут), анонсировала обновление своего решения - Veeam Availability Suite 9.5.
Традиционно, Veeam будет постепенно раскрывать подробности о новых возможностях Availability Suite, а пока представлена была только первая фича - интеграция с аппаратными хранилищами Nimble Storage.
В рамках данной интеграции будут доступны 3 ключевые возможности:
Backup from Storage Snapshots - возможность создавать резервные копии виртуальных машин путем снятия аппаратных снапшотов хранилища (средствами технологии native snapshot scheduling engine), а также оркестрация операций репликации ВМ на резервном хранилище.
Veeam Explorer for Storage Snapshots - восстановление виртуальных машин из снапшотов хранилищ или реплицированных копий, а также восстановление отдельных объектов (файлов, объектов приложений, таких как письма Exchange).
On-Demand Sandbox for Storage Snapshots - возможность использовать аппаратную интеграцию для создания изолированных окружений, например, для целей тестирования восстановления резервных копий.
Для того, чтобы получить преимущества Advanced Storage Integration для Veeam Backup and Replication, который является частью Availability Suite, нужно иметь Nimble Operating System версии 2.3 или более поздней, гипервизор vSphere 4.1, 5.x или 6.0, а также Veeam Backup & Replication 9.5.
Больше подробностей об интеграции Veeam Availability Suite и Nimble Storage вы найдете в блоге Veeam. А следить за новостями по продукту Veeam Availability Suite 9.5 можно вот тут.
Ну и еще одна новость от Veeam - открыта регистрация на VeeamON Forum 2016, который пройдет 26 мая в Москве. Это главное мероприятие компании Veeam в России за целый год, поэтому если продукты компании вам интересны - обязательно посетите его.
Известно точно, что выступит - Дэниэл Фрид, старший вице-президент по продажам и маркетингу Veeam. Будут выступления заказчиков, спонсоров. В прошлом году это были HPE, NetApp, Microsoft, Cisco. Будут специальный гость (возможно это президент компании - Ратмир Тимашев) и, конечно же, вечеринка. Приходите!