Идею для моей очередной функции Get-VMHostBirthday я позаимствовал из статьи известного блогера Магнуса Андерссона (Magnus Andersson), который задался интересным вопросом: «Как узнать дату и время установки хоста ESXi?». Вопрос, как оказалось, не такой уж простой, но решение, предложенное автором, мне показалось чересчур сложным по отношению к цене вопроса.

Компания RightScale, разрабатывающая ПО в сфере универсального управления облачными инфраструктурами, зарелизила ресурс http://cloudcomparison.rightscale.com, на котором можно сравнить основные публичные облачные платформы и изучить их функциональные возможности:

На данный момент на сайте присутствуют только 4 публичных облака: Amazon AWS, Google Cloud Platform, Microsoft Azure и SoftLayer от IBM. Интересно, что с помощью фильтров слева можно узнать, какие гостевые ОС доступны, в каких странах доступен сервис, а также что облако предлагает в плане вычислительных мощностей, хранилищ и сетевых возможностей.

Даже если с практической точки зрения это вам не интересно, все равно прикольно потыкать на галочки фильтров и посмотреть, какая из платформ что умеет. Из того, что я натыкал - AWS вне конкуренции.

Компания VMware на днях выпустила новую версию своего главного средства для P2V-переноса физических серверов в виртуальную среду vCenter Converter Standalone 6.1. Напомним, что о прошлой версии Converter, которая вышла весной прошлого года, мы писали вот тут.

Посмотрим на новые возможности Converter:

• Поддержка новых гостевых ОС для переноса физических систем на базе Windows 10 и Ubuntu 15.
• Возможность офлайн-конвертации виртуальных машин с платформы Microsoft Hyper-V 2012 R2 на Workstation и vSphere.
• Аутентификация на базе ключа по SSH для исходных физических Linux-систем при P2V-миграции.
• Поддержка настольной платформы виртуализации VMware Workstation 12.

Скачать VMware vCenter Converter Standalone 6.1 можно по этой ссылке. Release notes по продукту (включая список поддерживаемых продуктов и гостевых ОС) доступны тут.

Представляем вам гостевой пост от облачного сервиса 1cloud, регулярно рассказывающего на страницах нашего сайта о перспективных технологиях. Одной из наиболее активно обсуждаемых тем уходящего года стала «революция контейнеров» — многие компании внедряют их в свою инфраструктуру, а вендоры создают новые технологии для работы с ними. Недавно мы рассказывали о новых разработках VMware в этой области, а теперь представляем вашему вниманию адаптированный перевод заметки инженера компании о сложностях и мифах, связанных с контейнерами.

Вы стали свидетелями одного из самых крупных сдвигов, произошедших в IT-индустрии. Пятнадцать лет тому назад вы могли себе представить, что буквально одним нажатием кнопки сможете перенести приложение из одной части функционирующего дата-центра в другую, не создав при этом неудобств пользователям?

VMware сделала возможным переход от аппаратного обеспечения к программному, от ручного управления к автоматизации. Используя контейнеры, старую технологию, которую упростили такие компании, как Docker и CoreOS, мы можем мгновенно запустить множество приложений на общем ядре. В ноябре 2015 года в Барселоне прошла конференция Dockercon Europe 2015, посвященная безопасности, пользовательскому интерфейсу, RBAC-авторизации и эксплуатации программного обеспечения в целом. Стоит только упомянуть эти термины, как все внимание крупных организаций тут же обратится на вас.

На конференции искали способы заполнения пропасти между разработчиками (которые любят Docker) и IT-специалистами (у которых есть и другие проблемы, которые нужно решать). Объединить задачи этих групп спеиалистов и пытается VMware, компания тратит много усилий на популяризацию технологии контейнеров. Работа ведется по нескольким фронтам: создаются инструменты и внедряются технологии, способные облегчить этот переход.

Технология контейнеров быстро стала популярной среди разработчиков, поскольку с её помощью можно легко управлять сложными распределенными и переносимыми архитектурами приложений. Именно гибкость, переносимость и простота сделали контейнеры отличным решением для создания новых приложений. Однако с большими возможностями приходит большая ответственность – необходимо решить проблемы управления и эксплуатации, полностью понять новую парадигму разработки. Давайте рассмотрим наиболее частые заблуждения о контейнерной технологии, прежде чем вы продолжите с ней знакомство. Читать статью далее->>

Вчера мы писали про режим воспроизведения, который можно использовать для утилиты esxtop, предназначенной мониторинга производительности хост-серверов VMware ESXi. А сегодня предлагаем вам скачать постер "vSphere 6 ESXTOP quick Overview for Troubleshooting", в котором приведена основная информация для начала работы с esxtop, а также базовые приемы по решению возникающих в виртуальной инфраструктуре проблем с производительностью. Также стоит заглянуть вот в эту и эту заметку на нашем сайте.

Постер можно повесить в админской или серверной, где часто приходится работать с консолью серверов ESXi:

Интересную новость мы обнаружили вот тут. Оказывается утилита esxtop может работать в режиме повтора для визуализации данных о производительности, собранных в определенный период времени (многие администраторы знают это, но далеко не все). Это позволит вам собрать данные о производительности хоста, например, ночью, а в течение рабочего дня проанализировать аномальное поведение виртуальной инфраструктуры VMware vSphere. Называется этот режим replay mode.

Для начала запустите следующую команду для сбора данных на хосте VMware ESXi:

# vm-support -p -d 120 -i 10 -w /vmfs/volumes/your_datastore

Объяснение параметров:

• -p - собирать только данные о производительности is to only gather performance data
• -d - длительность сбора (здесь 120 секунд)
• -i - интервал сбора данных (тут раз в 10 секунд)
• -w - хранилище куда положить выходной файл

Файл по умолчанию создается сжатым, поэтому разжимаем его следующей командой:

# tar -xzf filename.tgz

Запускаем режим воспроизведения данных следующей командой:

# esxtop -R extracted_content_file_name

И вот видим привычный нам вывод esxtop, который будет обновляться с указанным при записи данных интервалом:

Если при запуске esxtop replay mode вы получите ошибку такого вида:

No such file or directory esxtop […] all vm-support snapshots have been used

То просто запустите предварительно скрипт reconstruct.sh, который будет находиться в папке с разархивированным содержимым после отработки tar:

# ./reconstruct.sh

Мы часто пишем о том, что снапшоты в VMware vSphere - это плохо (за исключением случаев, когда они используются для горячего резервного копирования виртуальных машин и временного сохранения конфигурации ВМ перед обновлением).

Однако их использование в крупных инфраструктурах неизбежно. Рано или поздно возникает необходимость удаления/консолидации снапшотов виртуальной машины (кнопка Delete All в Snapshot Manager), а процесс этот достаточно длительный и требовательный к производительности хранилищ, поэтому неплохо бы заранее знать, сколько он займет.

Напомним, что инициирование удаления снапшотов в vSphere Client через функцию Delete All приводит к их удалению из GUI сразу же, но на хранилище процесс идет долгое время. Но если в процесс удаления возникнет ошибка, то файлы снапшотов могут остаться на хранилище. Тогда нужно воспользоваться функцией консолидации снапшотов (пункт контекстного меню Consolidate):

О процессе консолидации снапшотов мы также писали вот тут. Удаление снапшотов (как по кнопке Delete All, так и через функцию Consolidate) называется консолидацией.

Сначала посмотрим, какие факторы влияют на время процесса консолидации снапшотов виртуальной машины:

• Размер дельта-дисков - самый важный параметр, это очевидно. Чем больше данных в дельта-диске, тем дольше их нужно применять к основному (базовому) диску.
• Количество снапшотов (число дельта-файлов) и их размеры. Чем больше снапшотов, тем больше метаданных для анализа перед консолидацией. Кроме того, при нескольких снапшотах консолидация происходит в несколько этапов.
• Производительность подсистемы хранения, включая FC-фабрику, Storage Processor'ы хранилищ, LUN'ы (число дисков в группе, тип RAID и многое другое).
• Тип данных в файлах снапшотов (нули или случайные данные).
• Нагрузка на хост-сервер ESXi при снятии снапшота.
• Нагрузка виртуальной машины на подсистему хранения в процессе консолидации. Например, почтовый сервер, работающий на полную мощность, может очень долго находится в процессе консолидации снапшотов.

Тут надо отметить, что процесс консолидации - это очень требовательный к подсистеме ввода-вывода процесс, поэтому не рекомендуется делать это в рабочие часы, когда производственные виртуальные машины нагружены.

Итак, как можно оценивать производительность процесса консолидации снапшотов:

Смотрим на производительность ввода-вывода хранилища, где находится ВМ со снапшотами.

Для реализации этого способа нужно, чтобы на хранилище осталась только одна тестовая виртуальная машина со снапшотами. С помощью vMotion/Storage vMotion остальные машины можно с него временно убрать.

1. Сначала смотрим размер файлов снапшотов через Datastore Browser или с помощью следующей команды:

ls -lh /vmfs/volumes/DATASTORE_NAME/VM_NAME | grep -E "delta|sparse"

2. Суммируем размер файлов снапшотов и записываем. Далее находим LUN, где размещена наша виртуальная машина, которую мы будем тестировать (подробнее об этом тут).

3. Запускаем команду мониторинга производительности:

# esxtop

4. Нажимаем клавишу <u> для переключения в представление производительности дисковых устройств. Для просмотра полного имени устройства нажмите Shift + L и введите 36.

5. Найдите устройство, на котором размещен датастор с виртуальной машиной и отслеживайте параметры в колонках MBREAD/s и MBWRTN/s в процессе консолидации снапшотов. Для того, чтобы нужное устройство было вверху экрана, можно отсортировать вывод по параметру MBREAD/s (нажмите клавишу R) or MBWRTN/s (нажмите T).

Таким образом, зная ваши параметры производительности чтения/записи, а также размер снапшотов и время консолидации тестового примера - вы сможете оценить время консолидации снапшотов для других виртуальных машин (правда, только примерно того же профиля нагрузки на дисковую подсистему).

Смотрим на производительность конкретного процесса консолидации снапшотов.

Это более тонкий процесс, который можно использовать для оценки времени снапшота путем мониторинга самого процесса vmx, реализующего операции со снапшотом в памяти сервера.

1. Запускаем команду мониторинга производительности:

# esxtop

2. Нажимаем Shift + V, чтобы увидеть только запущенные виртуальные машины.

3. Находим ВМ, на которой идет консолидация.

4. Нажимаем клавишу <e> для раскрытия списка.

5. Вводим Group World ID (это значение в колонке GID).

6. Запоминаем World ID (для ESXi 5.x процесс называется vmx-SnapshotVMX, для ранних версий SnapshotVMXCombiner).

7. Нажимаем <u> для отображения статистики дискового устройства.

8. Нажимаем <e>, чтобы раскрыть список и ввести устройство, на которое пишет процесс консолидации VMX. Что-то вроде naa.xxx.

9. Смотрим за процессом по World ID из пункта 6. Можно сортировать вывод по параметрам MBREAD/s (клавиша R) или MBWRTN/s (клавиша T).

10. Отслеживаем среднее значение в колонке MBWRTN/s.

Это более точный метод оценки и его можно использовать даже при незначительной нагрузке на хранилище от других виртуальных машин.

Очередная функция Get-VMHostFirmwareVersion моего PowerCLI модуля для управления виртуальной инфраструктурой VMware Vi-Module.psm1 поможет вам узнать версию и дату выпуска Firmware ваших серверов ESXi. Для большей гибкости и удобства в использовании, функция написана в виде PowerShell-фильтра.

Не так давно на сайте VMwareArena появилось очередное сравнение VMware vSphere (в издании Enterprise Plus) и Microsoft Hyper-V в Windows Server 2012 R2 Datacenter Edition, которое включает в себя самую актуальную информацию о возможностях обеих платформ.

Мы адаптировали это сравнение в виде таблицы и представляем вашему вниманию ниже:

Подводя итог, скажем, что нужно смотреть не только на состав функций той или иной платформы виртуализации, но и необходимо изучить, как именно эти функции реализованы, так как не всегда реализация какой-то возможности позволит вам использовать ее в производственной среде ввиду различных ограничений. Кроме того, обязательно нужно смотреть, какие функции предоставляются другими продуктами от данного вендора, и способны ли они дополнить отсутствующие возможности (а также сколько это стоит). В общем, как всегда - дьявол в деталях.

Компания VMware выпустила первое после нового года обновление своей серверной платформы виртуализации - VMware vSphere 6.0 Update 1b, включая обновления vCenter и ESXi.

Новых возможностей, конечно же, немного, но все же компоненты vSphere рекомендуется обновить ввиду наличия критичных обновлений подсистемы безопасности.

Что нового в VMware vCenter Server 6.0 Update 1b:

• Поддержка метода обновления URL-based patching с использованием zip-пакета. Подробнее в KB 2142009.
• Пользовательские настройки для Client Integration Plugin или диалогового окна VMware-csd guard в vSphere Web Client могут быть переопределены. Подробнее в KB 2142218.
• vSphere 6.0 Update 1b включает поддержку TLS версий 1.1 и 1.2 для большинства компонентов vSphere без нарушения совместимости с предыдущими версиями. Компоненты которые по-прежнему поддерживают только TLS версии 1.0:
  • vSphere Client
  • Virtual SAN Observer на сервере vCenter Server Appliance (vCSA)
  • Syslog на сервере vCSA
  • Auto Deploy на vCSA
  • Auto Deploy на iPXE
  О поддержке TLS-протоколов можно почитать подробнее в KB 2136185 .
• Утилита certificate manager теперь автоматически вызывает скрипт updateExtensionCertInVC.py для обновления хранилищ сертификатов, которые построены не на базе VMware Endpoint Certificate Store (VECS).
• Множество исправлений ошибок.

Что нового в VMware ESXi 6.0 Update 1b:

• Поддержка TLS версий 1.1 и 1.2 для большинства компонентов без нарушения совместимости с предыдущими версиями.
• Поддержка Advanced Encryption Standard (AES) с длиной ключа 128/256 бит для аутентификации через NFS 4.1 Client.
• Исправления ошибок.

Скачать VMware vCenter Server 6.0 Update 1b и VMware ESXi 6.0 Update 1b можно по этой ссылке.

Это гостевой пост сервис-провайдера 1cloud, предоставляющего услуги облачной аренды виртуальных машин. Ранее они рассказывали о развитии данной технологии в статье о «революции контейнеров» в своем блоге на Хабре.

Шумиха вокруг контейнеров последнего времени поставила один важный вопрос: как эта технология сможет ужиться с традиционными вариантами управления инфраструктурой, и какие угрозы она таит для рынка виртуализации? И даже более конкретный: заменят ли контейнеры виртуальные машины?

На ежегодной конференции в Сан-Франциско, прошедшей на в сентябре 2015 года, VMware дала однозначно понять, что этого не произойдет. Новая платформа управления вводит новый тип виртуализации — для самих контейнеров.

Виртуализация для контейнеров

«В ее основе, по-прежнему, лежит принцип виртуализации», — объясняет вице-президент VMware и технический директор Cloud Native Applications Кит Колберт. Он предпочитает называть Photon «микровизором» с достаточным набором функций для успешной виртуализации, упакованный в удобный для контейнеров формат.

Project Photon состоит из двух ключевых элементов. Photon Machine – оболочка для гипервизора, дублирующая ESX и устанавливаемая напрямую на физические серверы. Она создает виртуальную машину в миниатюре, куда помещаются контейнеры. Пользователь может самостоятельно выбрать гостевую ОС. По умолчанию устанавливается Photon ОС под Linux, которую компания также сделала совместимой с технологией контейнеров.

Второй элемент – это Photon Controller, мультитенантный маршрутизатор, позволяющий управлять одновременно дюжинами, если не тысячами, объектов на Photon Machine. Он следит за тем, чтобы все блоки (кластеры) Photon Machine имели доступ к сети и базам данных, когда это необходимо.

Комбинация этих двух элементов задает шаблон для масштабируемой среды и имеет надстройку для написания API. В теории, IT-операторы могу усовершенствовать Project Photon, и сами разработчики создавать на его базе приложения.

Project Photon способен интегрироваться с открытыми программами. Например, с Docker’ом для поддержки исполнения программы, или с Google Kubernetes и Pivotil’s Cloud Foundry для более качественного управления приложениями. Photon в данном случае выполняет подготовку инфраструктуры, а Kubernetes и CF занимаются развертыванием приложений.

В прошлом году для индивидуальных пользователей платформа стала доступна в качестве бета-версии.

Долгая дорога к контейнерам

Не все пользователи готовы полностью переключиться на контейнерную реализацию. Поэтому VMware для сомневающихся интегрирует поддержку контейнеров с традиционными инструментами управления.

vSphere Integrated Containers – еще один продукт, анонсированный на конференции. Как пояснил Кит Колберт, это идеальный вариант для тех, кто только хочет начать экспериментировать с контейнерами. Для желающих же использовать возможности контейнеров по максимуму он рекомендует переход к Project Photon.

vSphere Integrated Containers представляет собой плагин для vSphere, установленной на достопочтенном ESX компании. «Он делает контейнеры самыми желанными гостями платформы», — уточняет Колберт. При помощи плагина пользователи могут устанавливать контейнеры внутрь виртуальной машины, позволяя управлять ею так же, как и любой другой в пространстве платформы виртуализации.

В текущих условиях, если пользователь решил загрузить контейнеры в vSphere, ему приходится все скопом помещать их в одну единственную виртуальную машину. Таким образом, если что-то случится с одним из контейнеров, повреждения могут получить и все остальные, находящиеся в ВМ. Распределение контейнеров по разным ВМ обеспечивает их сохранность и аккуратное управление платформой.

Аналитик Marko Insights Курт Марко говорит, что новый подход к контейнерной реализации VMware должен облегчить жизнь и самим администраторам платформы. «Работа с контейнерами Photon в формате микро-ВМ схожа с тем, как работают с классом стеков и операторов, — сообщает Марко в своем письме. – Конечно, здесь могут быть потери в производительности, поскольку даже микро-ВМ будут больше перегружены, чем контейнеры, пользующиеся одними ядрами и библиотеками. В самой VMware утверждает, что это проблемой можно пренебречь, но Марко настаивает на независимом анализе издержек работы с контейнерами внутри виртуальных машин.

Не все так быстро

В VMware полны энтузиазма и рассматривают себя в качестве флагмана контейнерной реализации. Но есть несколько моментов, способных этот порыв охладить. Во-первых, вероятно, рынок контейнеров еще к этому не готов.

«Реклама продукта пока обгоняет реальность», — говорит аналитик IDC Эл Гиллен. По его подсчетам, менее десятой доли процента корпоративных приложений сейчас делаются через контейнеры. Может пройти десятилетие, пока рынок переварит эти технологии, и цифра приблизится к 40%.

Во-вторых, VMware никогда не обладала репутацией компании, готовой быть в авангарде разработок открытого программного обеспечения и проектов. Скорее, наоборот. Соучредитель и исполнительный директор Rancher Labs (стартапа, внедрившего свою ОС для контейнеров на VMworld) Шен Льян говорит, что до этого момента контейнерную реализацию продвигали сами разработчики или открытые платформы, наподобие Mesos, Docker и Kubernetes. Он добавил, что не встречал еще ни одного человека, использующего в работе контейнеры, который бы делал это с помощью инструментария VMware.

Аналитик Forrester Дейв Бартолти не удивлен данному обстоятельству. В VMware налажены прочные связи с проектными ИТ-менеджерами, но не с разработчиками, активно использующими контейнеры. Новинки, которые компания представила на VMworld, должны как раз вдохновить первых активно использовать контейнеры в рамках работы с платформой VMware. Остальные вендоры, среди которых Red Hat, Microsoft и IBM, также с удовольствием пользуются этой процедурой. VMware настаивает, что нашла способ примерить виртуальные машины и контейнеры.

Как вы знаете, в новой версии решения VMware Horizon 6.2 для виртуализации настольных ПК компания VMware сделала специальное издание VMware Horizon for Linux, позволяющее создавать инфраструктуру виртуальных десктопов на базе компьютеров с хостовой ОС Linux. Это востребовано в организациях, где такие рабочие станции используются для графического моделирования, сложных расчетов и прочих требовательных к производительности графической подсистемы нагрузок.

Напомним, что еще с версии Horizon 6.2 полностью поддерживались режимы Virtual Shared Graphics Acceleration (vSGA), Virtual Dedicated Graphics Acceleration (vDGA) и NVIDIA GRID vGPU на базе GRID 2.0 для Linux-десктопов:

Совсем недавно компания VMware выпустила VMware Horizon 6.2.1, где в плане поддержки Linux-десктопов появилось еще несколько нужных новых возможностей:

1. Clipboard Redirection (Copy / Paste).

Теперь в Linux-десктопах появилось перенаправление клавиатуры, которое позволяет копировать и вставлять из хостового ПК в виртуальный и обратно текст с форматированием, а также картинки. Естественно, в целях безопасности можно эту функцию отключить в файле конфигурации /etc/vmware/config (см. документ "Setting Up Horizon 6 for Linux Desktops").

2. Single Sign-On.

Теперь в Linux-ПК появилась поддержка SSO, позволяющая пользователю хостового устройства не вводить учетные данные при логине в свой виртуальный ПК Linux, который интегрирован со службами Active Directory через Open LDAP. Эти возможности поддерживаются для Horizon Client под Mac, Windows и Linux. На данный момент функция доступна только для ПК Red Hat Enterprise Linux 6.6 Workstation x86_64 и CentOS 6.6 x86_64.

3. Smart Card Authentication.

Аутентификация через смарт-карты в виртуальном ПК требуется во многих государственных и частных организациях с соответствующими регулирующими процедурами. Для аутентификации поддерживаются карты типа Personal Identity Verification (PIV) и Common Access Cards (CAC) с дистрибутивом Red Hat Enterprise Linux 6.6 Workstation x86_64.

4. Kerberos Authentication

После установки View Agent в виртуальный ПК Linux вы можете выбрать тип аутентификации Kerberos в дополнение к уже имеющейся MD5 digest authentication.

5. Consolidated Client Environment Information

До VMware Horizon 6.2.1 вся информация о пользовательском окружении (имя хоста, IP-адрес и прочее) записывалась в стандартный лог-файл, содержащий отладочную информацию. Это было неудобно, так как файл большой, и выуживать из него нужные данные было тяжело. Теперь для этого есть отдельный файл /var/log/vmware/Environment.txt, который поможет решать проблемы при настройке инфраструктуры виртуальных ПК.

Получить VMware Horizon 6.2.1 for Linux можно двумя способами:

1. Купить лицензию VMware Horizon 6 Enterprise Edition, которая содержит все необходимое для построения VDI-инфраструктуры, в том числе на Linux-платформе.

2. Использовать специализированное издание Horizon 6 for Linux standalone, которое можно скачать по этой ссылке.

Иногда системному администратору VMware vSphere требуется узнать, сколько тот или иной хост ESXi работает с момента последней загрузки (например, требуется проверить, не было ли внеплановых ребутов).

Есть аж целых 5 способов сделать это, каждый из них можно применять в зависимости от ситуации.

1. Самый простой - команда uptime.

Просто заходим на хост ESXi из консоли или по SSH и выполняем команду uptime:

login as: root

  Using keyboard-interactive authentication.

  Password: XXXXXX

The time and date of this login have been sent to the system logs.

VMware offers supported, powerful system administration tools.  Please

  see www.vmware.com/go/sysadmintools for details.
The ESXi Shell can be disabled by an administrative user. See the

  vSphere Security documentation for more information.

  ~ # uptime

  04:26:24 up 00:20:42, load average: 0.01, 0.01, 0.01

2. С помощью команды esxtop.

С помощью утилиты esxtop можно не только отслеживать производительность хоста в различных аспектах, но и узнать его аптайм. Обратите внимание на самую первую строчку вывода:

# esxtop

4. Время запуска хоста из лога vmksummary.log.

Вы можете посмотреть не только время текущего аптайма хоста ESXi, но времена его прошлых запусков в логе vmksummary.log. Для этого выполните следующую команду:

cat /var/log/vmksummary.log |grep booted

2015-06-26T06:25:27Z bootstop: Host has booted

  2015-06-26T06:47:23Z bootstop: Host has booted

  2015-06-26T06:58:19Z bootstop: Host has booted

  2015-06-26T07:05:26Z bootstop: Host has booted

  2015-06-26T07:09:50Z bootstop: Host has booted

  2015-07-08T05:32:17Z bootstop: Host has booted

4. Аптайм в vSphere Client и Web Client.

Если вы хотите вывести аптайм сразу всех виртуальных машин на хосте в VMware vSphere Client, для этого есть специальная колонка в представлении Hosts:

5. Аптайм хостов через PowerCLI.

Конечно же, время работы хоста ESXi можно посмотреть и через интерфейс PowerCLI. Для этого нужно воспользоваться командлетом Get-VMHost:

Get-VMHost | Get-View | select Name, @{N="Uptime"; E={(Get-Date) - $_.Summary.Runtime.BootTime}}|fl

Напомним, что до выполнения этой команды надо соединиться с хостом ESXi или vCenter:

Connect-VIServer -Server XXX.XXX.XXX.XXX -User YYYYYYY -Password ZZZZZZZZ

Недавно известный многим блоггер Frank Denneman выпустил бесплатную книгу "Designing A Storage Performance Platform":

В новой книге Фрэнка на 300 страницах раскрываются следующие моменты, касающиеся производительности подсистемы хранения платформ виртуализации, построенной на базе локальных дисков хост-серверов:

• Новая парадигма построения виртуального датацентра с точки зрения систем хранения
• Архитектура решения FVP
• Ускорение доступа к данным
• Технология непрерывной доступности Fault Tolerance
• Технология Flash
• Техники доступа к памяти
• Настройка кластера решения FVP
• Сетевой дизайн инфраструктуры локальных хранилищ
• Внедрение и пробная версия решения FVP
• Дизайн инфраструктуры хранилищ

Несмотря на то, что книга рассматривает в качестве основного продукта решение FVP от компании PernixData, ее интересно читать и с точки зрения понимания архитектуры и производительности подобных решений.

От лица всего коллектива VM Guru, его авторов и волонтеров, поздравляю наших читателей и партнеров с Новым 2016 годом! В следующем году желаю вам бывать больше с семьей, найти и сохранить любовь, достичь профессиональных успехов и осуществить, по крайней мере, одну большую мечту!

Все вам самого доброго и теплого в новом году! Пусть все невзгоды и плохие люди обойдут вас стороной. Оставайтесь с нами - в следующем году у нас будет много интересного. Спасибо, что читаете нас.

Главный редактор VM Guru, Александр Самойленко.

Компания VMware выпустила интересную инфографику, наглядно представляющую распреление сертифицированных специалистов VMware Certified Professionals (VCP) по регионам мира. 70% стран мира имеют хотя бы одного VCP, а в 46% стран их больше, чем 50 (картинка кликабельна):

Интересно также и то, что 38% VCP имеют более, чем одну сертификацию (видимо, имеется в виду сертификация именно VMware).

Судя по всему, у нас VCP почти столько же, сколько, например, в ЮАР. Это прискорбно - посмотрите на Индию или Австралию, к примеру, и оцените разницу в масштабах.

Какое-то время назад мы писали о технологии доставки приложений пользователям инфраструктуры настольных ПК предприятия - VMware App Volumes (ранее это называлось Cloud Volumes). Суть ее заключается в том, что виртуализованные и готовые к использованию приложения VMware ThinApp доставляются пользователям в виде подключаемых виртуальных дисков к машинам.

Недавно компания VMware выпустила документ "VMware App Volumes Reference Architecture", в котором объясняется работа технологии App Volumes, рассматривается референсная архитектура этого решения, а также проводится тестирование производительности доставляемых таким образом приложений по сравнению с их нативной установкой внутри виртуальных ПК:

Собственно, типовая архитектура решения App Volumes выглядит следующим образом:

Здесь показаны основные компоненты такой инфраструктуры:

• AppStacks - это тома, которые содержат сами установленные приложения и работают в режиме Read Only. Их можно назначить пользователям Active Directory, группам или OU. Один такой диск может быть назначен сразу нескольким виртуальным ПК (по умолчанию доступен всем машинам датацентра).
• Writable Volumes - это персонализированные тома, которые принадлежат пользователям. Они хранят настройки приложений, лицензионную информацию, файлы конфигураций приложений и сами приложения, которые пользователь установил самостоятельно. Один такой диск может быть назначен только одному десктопу, но его можно перемещать между десктопами.
• App Volumes Manager Server - это Windows-сервер, содержащий административную консоль для настройки продукта и управления им.

В качестве референсной архитектуры используется инфраструктура из 2000 виртуальных ПК, запущенных на 18 хостах ESXi инфраструктуры VMware Horizon View:

Для генерации нагрузки использовались различные сценарии пользовательского поведения, создаваемые с помощью средства Login VSI, ставшего уже стандартом де-факто для тестирования VDI-инфраструктур, развернутого на трех хост-серверах.

Здесь описаны 3 варианта тестирования:

• Приложения, нативно установленные в виртуальных ПК.
• Приложения App Volumes, использующие один AppStack, содержащий основные приложения пользователей.
• Приложения App Volumes, распределенные по трем различным AppStack.

Для обоих случаев тестирования App Volumes использовался один Writable Volume. Тут были получены следующие результаты (больше очков - это лучше).

Посмотрим на время логина пользователей при увеличении числа одновременных сессий в референсной архитектуре:

Взглянем на время отклика приложений:

Оценим время запуска приложений:

В целом-то, нельзя сказать, что потери производительности незначительные - они, безусловно, чувствуются. Но радует, что они фиксированы и хорошо масштабируются при увеличении числа одновременных сессий в VDI-инфраструктуре.

Документ очень полезен для оценки потерь производительности с точки зрения User Experience при использовании App Volumes по сравнению с традиционной доставкой приложений. Скачать 50-страничный документ можно скачать по этой ссылке - почитайте, там действительно интересно все изложено.

Если вы посмотрите в документ VSAN Troubleshooting Reference Manual (кстати, очень нужный и полезный), описывающий решение проблем в отказоустойчивом кластере VMware Virtual SAN, то обнаружите там такую расширенную настройку, как VSAN.ClomMaxComponentSizeGB.

Когда кластер VSAN хранит объекты с данными виртуальных дисков машин, он разбивает их на кусочки, растущие по мере наполнения (тонкие диски) до размера, указанного в данном параметре. По умолчанию он равен 255 ГБ, и это значит, что если у вас физические диски дают полезную емкость меньше данного объема (а точнее самый маленький из дисков в группе), то при достижении тонким диском объекта предела физической емкости вы получите вот такое сообщение:

There is no more space for virtual disk XX. You might be able to continue this session by freeing disk space on the relevant volume and clicking retry.

Если, например, у вас физический диск на 200 ГБ, а параметры FTT и SW равны единице, то максимально объект виртуального диска машины вырастет до этого размера и выдаст ошибку. В этом случае имеет смысл выставить настройку VSAN.ClomMaxComponentSizeGB на уровне не более 80% емкости физического диска (то есть, в рассмотренном случае 160 ГБ). Настройку эту нужно будет применить на каждом из хостов кластера Virtual SAN.

Как это сделать (более подробно об этом - в KB 2080503):

1. В vSphere Web Client идем на вкладку Manage и кликаем на Settings.
2. Под категорией System нажимаем Advanced System Settings.
3. Выбираем элемент VSAN.ClomMaxComponentSizeGB и нажимаем иконку Edit.
4. Устанавливаем нужное значение.

Надо отметить, что изменение этой настройки работает только для кластера VSAN без развернутых на нем виртуальных машин. Если же у вас уже продакшен-инфраструктура столкнулась с такими трудностями, то вы можете воспользоваться следующими двумя способами для обхода описанной проблемы:

1. Задать Object Space Reservation в политике хранения (VM Storage Policy) таким образом, чтобы дисковое пространство под объекты резервировалось сразу (на уровне 100%). И тогда VMDK-диски будут аллоцироваться целиком и распределяться по физическим носителям по мере необходимости.

2. Задать параметр Stripe Width в политиках VM Storage Policy таким образом, чтобы объекты VMDK распределялись сразу по нескольким физическим накопителям.

Фишка еще в том, что параметрVSAN.ClomMaxComponentSizeGB не может быть выставлен в значение, меньшее чем 180 ГБ, а значит если у вас носители меньшего размера (например, All-Flash конфигурация с дисками меньше чем 200 ГБ) - придется воспользоваться одним из этих двух способов, чтобы избежать описанной ошибки. Для флеш-дисков 200 ГБ установка значения в 180 ГБ будет ок, несмотря на то, что это уже 90% физической емкости.

Имя компьютера/сервера не всегда является достаточно информативным, например, имя «DC01» скажет вам намного меньше, чем «DC: Сайт Москва - GC, FSMO: Schema, RID, PDC». Поскольку имя компьютера NetBIOS/Hostname имеет ограничения как по длине, так и по набору символов, то для хранения этой дополнительной информации и предназначено поле «Description». Оно существует как для компьютера, т.е. внутри ОС (System Properties)...

Пару месяцев назад мы писали о том, что вышло обновление VMware vSphere 5.5 Update 3, которое полезно для пользователей, еще не перешедших на обновленную версию платформы виртуализации vSphere 6.

Новых возможностей там было немного, поэтому многие проигнорировали этот апдейт - а зря. Там появилось множество улучшений производительности операций в Web Client, о чем у VMware есть отдельная статья. Приведем основную выжимку здесь.

Как вы знаете, в vSphere Web Client 6.0 был сделан шаг вперед в плане улучшения производительности, а сейчас инженеры VMware портировали эти изменения уже на младшую версию vSphere 5.5 U3. При этом, по оценке самой VMware, теперь производительность тонкого клиента в этой версии в некоторых аспектах аналогична оной в vSphere 6.0 Update 1.

Улучшения были сделаны в следующих областях:

• Меню действий и меню по правому клику мыши
• Страницы Related Objects, Summary и Settings
• Мастера выполнения операций (миграция, создание шаблона и т.п.)
• Процесс логина в консоль
• Графики отображения производительности

Для тестирования сделанных улучшений (VMware уверяет, что их было сделано очень много) использовались 2 типа окружения:

• Маленькое – vCenter Server (4 vCPU / 16 GB RAM), 2 хост, 4 ВМ
• Большое – vCenter Server (32 vCPU / 64 GB RAM), 1000 хостов, 15000 ВМ

Посмотрим на время логина в Web Client:

Уменьшилось ровно в 2 раза. Теперь посмотрим на отклик меню действий (оно же вызывается по правой кнопке мыши):

Здесь кое-где и в 3 раза улучшилась ситуация. Для меню виртуальных машин ситуация не сильно улучшилась, так как в этом меню большое количество контекстно-зависимых действий.

Генерация графиков производительности (выбор объектов, ресайз графиков, обновление, выбор элементов для отображения). Здесь очень существенные улучшения, более чем в 2 раза:

Отображение связанных объектов, например, вы выбираете кластер и отображения списка виртуальных машин в нем происходит намного быстрее:

В общем, если вы еще не обновились - причина поставить новую версию Web Client есть.

Для тех из вас, кто использует в производственной среде или тестирует решение VMware NSX для виртуализации сетей своего датацентра, компания VMware подготовила полезный документ "VMware NSX for vSphere Network Virtualization Design Guide", который вышел уже аж в третьей редакции.

Документ представляет собой рефернсный дизайн инфраструктуры виртуализации сетей в датацентре и описывает архитектуру решения NSX на физическом и логическом уровнях.

В новой версии документа появилась следующая информация для сетевых архитекторов:

• сайзинг решения NSX для небольших датацентров
• лучшие практики маршрутизации
• микросегментация и архитектура компонента обеспечения безопасности среды Service Composer

Документ содержит ни много ни мало 167 страниц. Скачать его можно по этой ссылке.

Мы уже не раз писали про веб-консоль управления ESXi Embedded Host Client, которая доступна на сайте проекта VMware Labs как VIB-пакет для вашего сервера ESXi. Вот тут мы писали о возможностях третьей версии, а на днях стал доступен обновленный ESXi Embedded Host Client v4.

Давайте посмотрим на его новые возможности.

Основное:

• Новое меню Tools and links под разделом Help.
• Механизм обновления теперь принимает URL или путь к хранилищу с zip-файлом метаданных, что позволяет обновлять собственно сам сервер ESXi, а не только накатывать VIB-пакеты. Подробнее об этом тут.
• Локализация и интернационализация (французский, испанский, японский, немецкий, китайский и корейский).
• Возможность отключить таймаут сессии (очен удобно, если клиент всегда открыт у вас на вкладке браузера).
• Большое количество исправлений ошибок и мелких улучшений.

Операции с виртуальными машинами:

• Работа со списком виртуальных машин была оптимизирована по производительности.
• Возможность изменять расширенные настройки ВМ (advanced settings).
• Возможность изменять настройки видеоадаптера ВМ.
• Добавление девайса PCI pass-through (и его удаление).
• Поддержка функции SRIOV для сетевых карточек.
• Возможность изменения раскладки клавиатуры в браузере.
• Поддержка комбинаций Cmd+a или Ctrl+a для выделения всех ВМ в списке.
• Поддержка функций Soft-power и Reset для виртуальных машин, если установлены VMware Tools.
  

Операции с хостом:

• Возможность изменять host acceptance level для установки сторонних пакетов.
• Редактирование списка пользователей для исключений режима lockdown mode.
• Изменение настроек системного свопа.

Скачать ESXi Embedded Host Client v4 можно по этой ссылке.

У большинства администраторов хотя бы раз была ситуация, когда управляющий сервер VMware vCenter оказывался недоступен. Как правило, этот сервер работает в виртуальной машине, которая может перемещаться между физическими хостами VMware ESXi.

Если вы знаете, где находится vCenter, то нужно зайти на хост ESXi через веб-консоль Embedded Host Client (который у вас должен быть развернут) и запустить/перезапустить ВМ с управляющим сервером. Если же вы не знаете, где именно ваш vCenter был в последний раз, то вам поможет вот эта статья.

Ну а как же повлияет недоступность vCenter на функционирование вашей виртуальной инфраструктуры? Давайте взглянем на картинку:

Зеленым отмечено то, что продолжает работать - собственно, виртуальные машины на хостах ESXi. Оранжевое - это то, что работает, но с некоторыми ограничениями, а красное - то, что совсем не работает.

Начнем с полностью нерабочих компонентов в случае недоступности vCenter:

• Централизованное управление инфраструктурой (Management) - тут все очевидно, без vCenter ничего работать не будет.
• DRS/Storage DRS - эти сервисы полностью зависят от vCenter, который определяет хосты ESXi и хранилища для миграций, ну и зависят от технологий vMotion/Storage vMotion, которые без vCenter не работают.
• vMotion/SVMotion - они не работают, когда vCenter недоступен, так как нужно одновременно видеть все серверы кластера, проверять кучу различных условий на совместимость, доступность и т.п., что может делать только vCenter.

Теперь перейдем к ограниченно доступным функциям:

• Fault Tolerance - да, даже без vCenter ваши виртуальные машины будут защищены кластером непрерывной доступности. Но вот если один из узлов ESXi откажет, то новый Secondary-узел уже не будет выбран для виртуальной машины, взявшей на себя нагрузку, так как этот функционал опирается на vCenter.
• High Availability (HA) - тут все будет работать, так как настроенный кластер HA функционирует независимо от vCenter, но вот если вы запустите новые ВМ - они уже не будут защищены кластером HA. Кроме того, кластер HA не может быть переконфигурирован без vCenter.
• VMware Distributed Switch (vDS) - распределенный виртуальный коммутатор как объект управления на сервере vCenter работать перестанет, однако сетевая коммуникация между виртуальными машинами будет доступна. Но вот если вам потребуется изменить сетевые настройки виртуальной машины, то уже придется прицеплять ее к обычному Standard Switch, так как вся конфигурация vDS доступна для редактирования только с работающим vCenter.
• Other products - это сторонние продукты VMware, такие как vRealize Operations и прочие. Тут все зависит от самих продуктов - какие-то опираются на сервисы vCenter, какие-то нет. Но, как правило, без vCenter все довольно плохо с управлением сторонними продуктами, поэтому его нужно как можно скорее поднимать.

Для обеспечения доступности vCenter вы можете сделать следующее:

• Защитить ВМ с vCenter технологией HA для рестарта машины на другом хосте ESXi в случае сбоя.
• Использовать кластер непрерывной доступности VMware Fault Tolerance (FT) для сервера vCenter.
• Применять технику кластеризации машин с vCenter, как описано в документе "Setup for Failover Clustering and Microsoft Cluster Service". Это полностью поддерживается, начиная с vCenter 5.5 Update 2.

Как вы знаете, некоторое время назад вышло обновление платформы виртуализации VMware vSphere 6 Update 1, в котором были, в основном, только минорные обновления. Но было и важное - теперь виртуальный модуль VMware vCenter Server Appliance (vCSA) стало возможно обновлять путем монтирования к нему ISO-образа с апдейтом.

Давайте покажем упрощенный процесс обновления через смонтированный образ. Итак, соединимся с хостом vCSA по SSH (если у вас есть отдельный сервер Platform Services Controller, то коннектиться нужно к нему):

Далее скачаем обновление vCenter, в котором есть и обновление vCSA версии 6.0.0 (выберите продукт VC и в разделе VC-6.0.0U1-Appliance скачайте VMware-vCenter-Server-Appliance-6.0.0.10000-3018521-patch-FP.iso):

Здесь надо пояснить, что это за обновления:

• FP (Full patch) - это обновление всех компонентов vCenter, включая полноценные продукты, vCenter, vCSA, VMware Update Manager, PSC и прочее.
• TP (Third party patch) - это обновление только отдельных компонентов vCenter.

Скачиваем патч FP (VMware-vCenter-Server-Appliance-6.0.0.10000-3018521-patch-FP.iso), после чего монтируем этот ISO-образ к виртуальной машине vCSA через vSphere Web Client или Embedded Host Client.

Далее возвращаемся к консоли vCSA:

Смонтировать ISO-образ можно также через PowerCLI с помощью следующих команд:

$iso = "[mgt-ds-nfs] iso/VMware-vCenter-Server-Appliance-6.0.0.10000-3018521-patch-FP.iso"

Get-CDDrive –vm "mgmt01vc01" | Set-CDDrive -IsoPath $iso –Connected $true

Далее выполняем следующую команду, если вы хотите накатить патчи прямо сейчас:

software-packages install --iso --acceptEulas

Либо патчи можно отправить на стейджинг отстаиваться (то есть пока обновить компоненты, но не устанавливать). Сначала выполняем команду отсылки на стейджинг:

software-packages install --iso --acceptEulas

Далее просматриваем содержимое пакетов:

software-packages list --staged

И устанавливаем апдейт со стейджинга:

software-packages install --staged

Если во время обновления на стейджинг или установки обновления возникли проблемы, вы можете просмотреть логи, выполнив следующие команды:

shell.set –enabled True
shell
cd /var/log/vmware/applmgmt/
tail software-packaged.log –n 25

Далее размонтируйте ISO-образ от виртуальной машины или сделайте это через PowerCLI следующей командой:

Get-CDDrive –vm "mgmt01vc01" | Set-CDDrive -NoMedia

Далее перезагрузите виртуальную машину vCSA:

shutdown reboot -r "Updated to vCenter Server 6.0 Update 1"

Теперь откройте веб-консоль vCSA по адресу:

https://<FQDN-or-IP>:5480

И перейдите в раздел Update, где вы можете увидеть актуальную версию продукта:

Кстати, обратите внимание, что возможность проверки обновления в репозитории (Check URL) вернулась, и обновлять vCSA можно прямо отсюда по кнопке "Check Updates".

Многие из вас знают, что в решении VMware Horizon View есть две полезных возможности, касающихся функций печати из виртуального ПК пользователя - это перенаправление принтеров (Printer redirection) и печать на основе местоположения (Location based printing). Об этих функциях подробно рассказано в документе "Virtual Printing Solutions with View in Horizon 6", а мы изложим тут лишь основные сведения, содержащиеся в нем.

Printer redirection

Эта возможность позволяет перенаправить печать из виртуального ПК к локальному устройству пользователя, с которого он работает, и к которому подключен принтер уже физически. Функция поддерживается не только для Windows-машин, но и для ПК с ОС Linux и Mac OS X. Работает эта фича как для обычных компьютеров, так и для тонких клиентов (поддерживается большинство современных принтеров).

При печати пользователь видит принтер хоста не только в диалоге печати приложения, но и в панели управления. При этом не требуется в виртуальном ПК иметь драйвер принтера - достаточно, чтобы он был установлен на хостовом устройстве.

Перенаправление принтеров полезно в следующих случаях:

• в общем случае, когда к физическому ПК пользователя привязан принтер
• когда пользователь работает из дома со своим десктопом и хочет что-то распечатать на домашнем принтере
• работники филиала печатают на локальных принтерах, в то время, как сами десктопы расположены в датацентре центрального офиса

Схема передачи задания на печать для перенаправления принтера выглядит так:

То есть Horizon Client получает данные в формате EMF от виртуального ПК и передает его уже на хостовом устройстве к драйверу принтера.

Location based printing

Эта фича позволяет пользователям виртуальных ПК печатать на тех принтерах, которые находятся географически ближе к нему, чтобы не бегать, например, на другой этаж офисного здания, чтобы забирать распечатанное, когда есть принтеры поблизости. Правила такой печати определяются системным администратором.

Для функции Location based printing задания печати направляются с виртуального ПК напрямую на принтер, а значит нужно, чтобы на виртуальном десктопе был установлен драйвер этого принтера.

Есть 2 типа правил Location based printing:

• IP-based printing - используется IP-адрес принтера для определения правил маппинга принтера к десктопам.
• UNC-based printing - используются пути в формате Universal Naming Convention (UNC) для определения правил маппинга принтеров.

Здесь задание на печать передается в рамках следующего рабочего процесса:

Запрос пользователя с хостового устройства через Horizon Client передается к View Agent, который через взаимодействие с приложением передает задание драйверу принтера в гостевой ОС с учетом правил маппинга принтеров, а дальше уже обработанное задание идет на печать.

В зависимости от способа доступа, поддерживаются методы перенаправления принтеров или печать на основе местоположения:

Очевидно, что в нулевом клиенте и в мобильном девайсе нет хостового драйвера принтера, поэтому там и нет поддержки Printer redirection. Ну и то же самое можно сказать про доступ HTML access через браузер - там тоже поддержка отсутствует.

Надо сказать, что и Printer redirection, и Location based printing поддерживаются для следующих моделей доступа пользователей инфраструктуры VDI:

• Десктопы View
• Десктопы RDSH
• Десктопы Windows Server 2008 R2 и Windows Server 2012 R2
• Приложения Hosted apps

Ну а о том, как настраивать обе техники печати из виртуальных ПК вы можете прочитать в документе.

Мы уже писали о том, что последней версии решения для виртуализации настольных ПК VMware Horizon View 6.2 есть поддержка режима vGPU. Напомним, что это самая прогрессивная технология NVIDIA для поддержки требовательных к производительности графической подсистемы виртуальных десктопов.

Ранее мы уже писали про режимы Soft 3D, vSGA и vDGA, которые можно применять для виртуальных машин, использующих ресурсы графического адаптера на стороне сервера.

Напомним их:

• Soft 3D - рендеринг 3D-картинки без использования адаптера на основе программных техник с использованием памяти сервера.
• vDGA - выделение отдельного графического адаптера (GPU) одной виртуальной машине.
• vSGA - использование общего графического адаптера несколькими виртуальными машинами.

Режим vSGA выглядит вот так:

Здесь графическая карта представляется виртуальной машине как программный видеодрайвер, а графический ввод-вывод обрабатывается через специальный драйвер в гипервизоре - ESXi driver (VIB-пакет). Команды обрабатываются по принципу "first come - first serve".

Режим vDGA выглядит вот так:

Здесь уже физический GPU назначается виртуальной машине через механизм проброса устройств DirectPath I/O. То есть целый графический адаптер потребляется виртуальной машиной, что совсем неэкономно, но очень производительно.

В этом случае специальный драйвер NVIDIA GPU Driver Package устанавливается внутри виртуальной машины, а сам режим полностью поддерживается в релизах Horizon View 5.3.х и 6.х (то есть это давно уже не превью и не экспериментальная технология). Этот режим работает в графических картах K1 и K2, а также и более свежих адаптерах, о которых речь пойдет ниже.

Режим vGPU выглядит вот так:

То есть встроенный в гипервизор NVIDIA vGPU Manager (это тоже драйвер в виде пакета ESXi VIB) осуществляет управление виртуальными графическими адаптерами vGPU, которые прикрепляются к виртуальным машинам в режиме 1:1. В операционной системе виртуальных ПК также устанавливается GRID Software Driver.

Здесь уже вводится понятие профиля vGPU (Certified NVIDIA vGPU Profiles), который определяет типовую рабочую нагрузку и технические параметры десктопа (максимальное разрешение, объем видеопамяти, число пользователей на физический GPU и т.п.).

vGPU можно применять с первой версией технологии GRID 1.0, которая поддерживается для графических карт K1 и K2:

Но если мы говорим о последней версии технологии GRID 2.0, работающей с адаптерами Tesla M60/M6, то там все устроено несколько иначе. Напомним, что адаптеры Tesla M60 предназначены для Rack/Tower серверов с шиной PCIe, а M6 - для блейд-систем различных вендоров.

Технология NVIDIA GRID 2.0 доступна в трех версиях, которые позволяют распределять ресурсы между пользователями:

• «Виртуальный ПК» (Virtual PC)
• «Виртуальная рабочая станция» (Virtual Workstation)
• «Расширенная виртуальная рабочая станция» (Virtual Workstation Extended)

Характеристики данных лицензируемых для адаптеров Tesla изданий представлены ниже:

Тут мы видим, что дело уже не только в аппаратных свойствах графической карточки, но и в лицензируемых фичах для соответствующего варианта использования рабочей нагрузки.

Каждый "experience" лицензируется на определенное число пользователей (одновременные подключения) для определенного уровня виртуальных профилей. Поэтому в инфраструктуре GRID 2.0 добавляется еще два вспомогательных компонента: Licensing Manager и GPU Mode Change Utility (она нужна, чтобы перевести адаптер Tesla M60/M6 из режима compute mode в режим graphics mode для работы с соответствующим типом лицензии виртуальных профилей).

Обратите внимание, что поддержка гостевых ОС Linux заявлена только в последних двух типах лицензий.

На данный момент сертификацию драйверов GRID прошло следующее программное обеспечение сторонних вендоров (подробнее об этом тут):

Спецификации карточек Tesla выглядят на сегодняшний день вот так:

Поддержка также разделена на 2 уровня (также прикрепляется к лицензии):

Руководство по развертыванию NVIDIA GRID можно скачать по этой ссылке, ну а в целом про технологию написано тут.

На сайте проекта VMware Labs, где довольно-таки регулярно появляются различные утилиты для виртуальной инфраструктуры, появилось средство VMware vRealize Operations Docker 1.0 Adapter. Давайте посмотрим, для чего он нужен.

Напомним, что о подходе VMware к контейнеризованным приложениям Docker мы писали вот тут. Вкратце: VMware предлагает на базе Photon OS запускать контейнеры в виртуальных машинах (одна ВМ - одно приложение), а с помощью средств VMFork мгновенно создавать экземпляры таких виртуальных машин по требованию.

Выпущенный на днях Docker Management Pack for vRealize Operations Manager собирает данные о производительности этих контейнеров в вашем окружении Docker, а также предоставляет анализ о возможных трудностях с производительностью. Кроме того, в данном средстве в реальном времени доступна информация об имеющихся проблемах в инфраструктуре Docker (они обозначаются красными квадратиками).

Данный management pack представляет собой плагин к vRealize Operations Manager 6.x. Он отображает взаимосвязи между различными компонентами инфраструктуры Docker (например соотношение между образом и контейнером), а также собирает данные о производительности и свойствах с каждой системы Docker.

Для установки плагина нужно зайти в раздел Administration > Solutions в vRealize Operations Manager и загрузить pak-файл, нажав плюсик:

Скачать VMware vRealize Operations Docker 1.0 Adapter можно по этой ссылке.

Те, из вас, кто пользуется веб-средством vSphere Web Client для управления виртуальной инфраструктурой VMware vSphere, знают, что при логине в окно клиента в самом низу предлагают скачать Client Integration Plugin (CIP):

CIP - это пакет средств от VMware, представляющий собой набор полезных утилит для некоторых административных операций в виртуальной инфраструктуре. Утилиты доступны как для Microsoft Windows, так и для Apple Mac OS X (а скоро будет и поддержка Linux).

Посмотрим на состав этого набора:

• ovftool - это отдельная утилита CLI, которую можно использовать для импорта и экспорта виртуальных модулей (Virtual Appliances) в форматах OVF и OVA.
• Windows Authentication - позволяет использовать аутентификацию SSPI Windows при логине через vSphere Web Client.
• Remote Devices - возможность подключить клиентские устройства (CD-ROM, Floppy, USB и прочие) к виртуальной машине.
• File Upload/Download - это вынесенный в отдельную утилиту Datastore browser для загрузки файлов на виртуальные хранилища.
• Content Library - операции импорта и экспорта для компонента Content Library.
• Client Side Logging/Config - позволяет записывать логи на стороне клиента, а также реализует настройки логирования vSphere Web Client.

Процедура развертывания vSphere Client Integration Plugin выглядит примерно так (видео от версии vSphere 5.5):

Ранее CIP как браузерный плагин использовал модель Netscape Plugin Application Programming Interface (NPAPI), но поскольку в Google Chrome последних версий и прочих браузерах поддержка этой устаревшей модели была окончена, то теперь используется обновленная модель отображения, которая реализована, начиная с Sphere 5.5 Update 3a и vSphere 6.0 Update 1 (поэтому лучше CIP использовать с платформами этих версий или выше).

Более подробно об утилитах CIP рассказано вот тут.

Для тех из вас, кто еще не обновил свою инфраструктуру на последнюю версию VMware vSphere 6, компания VMware приготовила очередной пакет исправлений VMware vSphere 5.5 Update 3b. На самом деле, это просто патч VMware ESXi 5.5 patch ESXi550-201512001, в котором произошли некоторые изменения в плане безопасности, а также исправлены ошибки.

Среди заявленных фич, касающихся security, основная - это отключенный по умолчанию SSL третьей версии (SSLv3). Отключили его (как в клиенте, так и в сервере) потому, что он считается устаревшим, и его поддержка уже не предоставляется в большинстве Enterprise-продуктов (об этом можно почитать в RFC 7568).

Внимание! Обязательно следуйте рекомендованной последовательности обновления продуктов VMware, то есть сначала обновите vCenter до версии 5.5 Update 3b и только потом ESXi 5.5 до версии Update 3b, чтобы избежать проблем с отключением хостов от сервера управления vCenter.

Также помните, что VMware View Composer версии ниже 6.2 не будет работать с хостами ESXi 5.5 Update 3b.

Как вы знаете, у компании VMware есть средство для комплексного мониторинга и решения проблем в виртуальной среде vRealize Operations. Также в решении для создания инфраструктуры виртуальных ПК предприятия VMware Horizon View (еще с версии 6.0) есть поддержка опубликованных приложений на серверах RDS Hosted Apps.

Ну и логично, что у VMware есть решение vRealize Operations for Published Applications, которое поддерживает мониторинг инфраструктуры доставки приложений через механизм RDS Hosted Apps. На днях вышла обновленная версия этого продукта - vRealize Operations for Published Applications 6.2 одновременно с основным релизом Operations 6.2, с поддержкой не только приложений опубликованных, через RDS, но и продуктов Citrix XenApp и XenDesktop.

Основные новые возможности vRealize Operations for Published Applications 6.2:

• Поддержка последних версий Citrix XenDesktop and XenApp 7.6 - функции мониторинга и отчетности теперь доступны для инфраструктуры виртуализации и доставки приложений и десктопов, созданных на данных платформах.
• Application and Usage Reports - готовые шаблоны отчетов, которые позволяют администраторам приложений определить потребление ресурсов приложениями, пиковые нагрузки, параметры сессий пользователей на серверных ресурсах, а также учитывать потребление пользователями лицензий отдельных приложений.
• Proactive User Experience Monitoring - новый дэшборд "User Experience", который постоянно мониторит vCPU, vRAM и vDisk, чтобы с помощью карты heat map оповестить администратора о том, что некоторые пользователи испытывают проблемы при работе с их приложениями.
• Reduced Time to Resolve - новые метрики сессии, которые помогают устранять проблемы: длительность процесса логина, сортировка по времени логина сессий, использование системных ресурсов, а также ICA Round Trip Time для приложений Citrix.
• Windows 10 support - теперь Windows 10 поддерживается для мониторинга, как для VMware Horizon View, так и для решений XenDesktop/XenApp.
• Алерты для Citrix Storefront, PVS Server, Citrix License Server и Citrix Database Server - теперь все эти компоненты поддерживаются в рамках общей процедуры мониторинга доступности компонентов инфраструктры виртуальных ПК и приложений.
• Мониторинг лицензий Citrix License Server - теперь можно учитывать лицензии, считаемые этим продуктом.
• Improved Logon Breakdown metrics to meet SLAs - дэшборд "Session Details" теперь показывает метрику длительность процесса логина для самых тормозных ПК.
• Connection and machine failure data - эта новая метрика мониторит общее число неудачных соединений и стартов машин на ферме Citrix XenDesktop.

Более подробно о новых функциях решения vRealize Operations for Published Applications 6.2 написано в Release Notes. Напомним, что это решение включено в состав продукта vRealize Operations for Horizon, который можно скачать по этой ссылке.

Постер VMware vSphere PowerCLI 10

Постер VMware Cloud Foundation 4 Architecture

Постер VMware vCloud Networking

Постер VMware Cloud on AWS Logical Design Poster for Workload Mobility

Постер Azure VMware Solution Logical Design

Постер Google Cloud VMware Engine Logical Design

Постер Multi-Cloud Application Mobility

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):