Мы уже писали о продукте для виртуализации корпоративных приложений VMware ThinApp (здесь и здесь), который может быть использован как в рамках решения VMware View 4.5 для виртуализации корпоративных ПК предприятия, так и самостоятельно.

Sven Huisman, один из авторов портала virtualfuture.info, сделал интересный документ "How to deploy your ThinApps?", в котором детально описываются варианты развертывания виртуализованных приложений VMware ThinApp в корпоративной среде (пошагово и с инструкциями). Как вы знаете, у ThinApp нет собственного механизма развертывания виртуализованных приложений (централизованное развертывание есть только в консоли VMware View), поэтому этот документ может оказаться весьма полезным:

Константин Введенский, мой старый приятель и по совместительству сотрудник компании StarWind Software, опубликовал интересные заметки по оптимизации работы хранилищ виртуальных машин VMware ESX на базе продукта StarWind Enterprise. Если кто-нибудь из вас все еще не знает как StarWind может помочь вам в создании отказоустойчивых систем хранения по iSCSI для виртуальных машин серверов VMware ESX, то вам сюда, сюда, и, вообще, сюда.

О чем говорят нам эти заметки:

1. iSCSI Initiator на VMware ESX можно использовать в режиме NIC binding (то есть Teaming в настройках vSwitch), или в режиме MPIO (multipathing, в настройках политики путей к хранилищу в категории Storage), но нельзя их использовать одновременно. Еще посмотрите сюда.

2. Если вы используете и хранилища NAS/NFS, и хранилища iSCSI, то нужно использовать NIC Teaming для обоих интерфейсов, а не MPIO.

3. Для типа балансировки IP Hash вы сможете использовать только 1 iSCSI-соединение на хост VMware ESX. Как настраивается тип балансировки IP Hash изложено в KB 100737.

4. По умолчанию время выбора пути в случае отказа на VMware ESX равно 300 секунд. Это время рекомендованное VMware. Вы можете уменьшить или увеличить это время. Его уменьшение ускорит переключение на резерв, но даст нагрузку на процессор ESX (более частый опрос путей), увеличение этого времени снизит нагрузку на CPU, но и увеличит время Failover'а. Настраивается этот параметр в Advanced Settings сервера ESX - он называется Disk.PathEvalTime, и его значение может варьироваться в диапазоне от 30 до 1500. Более подробно в VMware KB 1004378 и еще вот тут посмотрите, например.

5. В виртуальных машинах Windows убедитесь, что параметр Disk\TimeOutValue в реестре равен 60 секундам. Это позволит дисковому устройству не отваливаться раньше времени. Если VMware Tools установлены, то он будет равен 60 секундам после установки, если же нет, то это будет 10 секунд (non-cluster) или 20 секунд (cluster node). Настраивается он вот в этом ключе реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\TimeOutValue

Для Linux все немного не так. Без VMware Tools время TimeOutValue равно 60 секундам, а с ними - 180 секундам. Настраивается TimeOutValue в Linux так:

cat /sys/block/<disk>/device/timeout

Для большинства случаев подойдет значение в 60 секунд.

6. Для достижения лучшей производительности со StarWind Enterprise лучше использовать политику балансировки нагрузки по нескольким путям Round Robin (не активирована по умолчанию, по дефолту стоит политика Fixed). Для этого нужно щелкнуть правой клавишей по устройству iSCSI и нажать "Manage Paths" в vSphere Client.

Эта политика позволяет переключаться между путями каждые 1000 IOPS'ов. Можно уменьшить это значение для оптимизации производительности. Для этого в сервисной консоли ESX / ESXi наберите:

esxcli nmp roundrobin setconfig --device [UUID] --iops 3 --type iops

В данном случае выставлено 3 IOPS'а. UUID девайса можно узнать в категории "Storage adapters" в vSphere Client для сервера ESX. Опросить текущие настройки устройства можно командой сервисной консоли:

esxcli nmp roundrobin getconfig --device [UUID]

Ну и, конечно, помните, что все эти настройки нужно сначала опробовать в тестовой среде и посмотреть на изменения в производительности работы сервера ESX с хранилищем StarWind Enterprise.

Скачать StarWind Enterprise HA можно по этой ссылке, ну а покупают его только здесь.

Компания Oracle объявила о выпуске новой версии настольной платформы виртуализации Oracle VirtualBox 4.0.

Напомним, что VirtualBox 4.0 - это частично бесплатная, открытая платформа виртуализации для настольных ПК, поддерживающая Windows, Linux и Mac OS в качестве хостовых платформ и позволяющая запускать несколько виртуальных машин одновременно на одном компьютере.

Новые возможности VirtualBox 4.0:

• Улучшения в GUI - превью консоли гостевой системы, масштабирование консоли гостевой ОС, панели атрибутов и многое другое в Oracle VM VirtualBox Manager (см. картинку выше)
• Виртуальную машину можно запустить из ярлыка, без необходимости запускать VirtualBox Manager
• Масштабирование консолей виртуальных машин для Linux и Solaris
• Улучшения, направленные на повышение производительности "тяжелых" виртуальных машин с громоздкими приложениями
• Новые настройки виртуальных дисков, улучшающие переносимость виртуальных машин между хостами (все файлы ВМ в одной папке, можно переносить susended-машину и ВМ со снапшотом)
• Поддержка универсального формата Open Virtualization Format Archive (OVA) для виртуальных модулей (Virtual Appliances) - виртуальных машин, распространяемых с предустановленным ПО
• Поддержка более 2 ГБ оперативной памяти гостевой системы для 32-битных хостов
• Поддержка эмуляции чипсета ICH9 с 3-мя PCI-шинами, PCI express и Message Signaled Interrupts (MSI)
• В гостевых системах поддерживается Intel HD Audio (актуально для последних версий Windows)
• Поддержка Hardware offloading for virtual networking - передачи части функций по работе с сетевым окружением на сторону физического сетевого адаптера
• Улучшен контроль ресурсов, потребляемых виртуальной машиной: можно ограничивать CPU и пропускную способность ввода-вывода (I/O)
• Поддержка изменения размера виртуальных дисков VDI и VHD
• Поддержка асинхронного ввода-вывода для iSCSI, дисков VMDK, VHD и образов Parallels Workstation
• Автоматическое обновление Guest Additions (аналог VMware Tools в Workstation)
• Guest Additions поддерживают копирование файлов в гостевую ОС с хоста
• По умолчанию для 64-битных хостов включена поддержка Large Memory Pages
• Возможность расширения функциональности за счет Extension Pack'ов. Например, сама Oracle дает pack, в котором есть поддержка USB 2.0, Remote Display Services и загрузки по сети.
• Последняя но немаловажная возможность - конфигуратор работы сети хоста с сетями виртуальных машин сильно изменился, и теперь есть режим NAT (и правила Port Forwarding). В этом смысле VirtualBox 4.0 приближается к VMware Workstation с его Virtual Network Editor.

Последнее окошко выглядит так:

Скачать Oracle VM VirtualBox 4.0 можно по этой ссылке.

Как обычно, Duncan Epping написал отличный пост об использовании памяти виртуальными машинами на хостах VMware ESX. Постараемся объяснить это на русском языке. Итак, если открыть вкладку Summary в vSphere Client для виртуальной машины, мы увидим вот такую картину:

Здесь есть 2 главных параметра:

• Memory - это то количество оперативной памяти, которое вы выделили виртуальной машине при создании. За это количество гостевая ОС не выйдет при ее использовании. Это же количество памяти вы увидите в гостевой ОС.
• Memory Overhead - это количество памяти, которое может потребоваться гипервизору на поддержание работы виртуальной машины сверх используемой памяти (т.е. расчетные накладные расходы на виртуализацию, но не текущие).

Далее мы видим панель Resources, здесь есть такие показатели:

• Consumed Host Memory - это количество физической памяти хоста ESX, выделенной виртуальной машине. Обычно это значение не больше значения Memory на предыдущей картинке. Но может быть и больше, поскольку Consumed Host Memory включает в себя и Memory Overhead, но не с картинки выше, а реально используемый гипервизором Overhead (о котором будет идти речь ниже). И важный момент - счетчик Consumed для Memory на вкладке "Performance" не включает в себя Overhead.
• Active Guest Memory - это количество памяти, которое по мнению гипервизора VMkernel активно используется гостевой операционной системой. Вычисляется этот параметр на базе статистических показателей. То есть, если ОС не очень активно использует память, то можно ей ее немного подрезать в условиях нехватки ресурсов.

Теперь идем на вкладку "Resource Allocation". Здесь все немного сложнее:

Появляются вот такие показатели:

Для Host Memory (видим, что это 2187 МБ = сконфигурированная память 2048 МБ + Overhead):

• Consumed - это, опять-таки, объем потребляемой виртуальной машиной физической памяти хоста ESX (постоянно меняется). И он включает в себя накладные расходы гипервизора по памяти.
• Overhead Consumption - это текущий объем затрат памяти на поддержание виртуальной машины (здесь 42 МБ в отличие от расчетного в 110 МБ)

А формула такова: Consumed = Private + Overhead Comsumption

Для Guest Memory (2048 МБ сконфигурировано в настройках):

• Private - это объем памяти физически хранимый хостом для виртуальной машины (см. формулу выше).
• Shared - это объем памяти, который отдается другим виртуальным машинам от разницы между сконфигурированным объемом (Configured Memory) и потребляемым (Consumed). Суть в том, что ОС Windows при загрузке очищает всю память виртуальной машины, но потом эти пустые страницы приложениями не используются. Поэтому гипервизор отдает их другим ВМ, пока ВМ, владеющая памятью не потребует их. Эти страницы и есть Shared. Как мы видим, Private + Shared = Guest Memory.
• Swapped - это объем памяти, ушедший в файл подкачки vswp. То есть это не файл подкачки Windows, а файл подкачки в папке с виртуальной машиной. Само собой этот показатель должен быть нулевым или совсем небольшим, поскольку своппинг, который делает ESX (а точнее VMkernel) - это плохо, т.к. он не знает (в отличие от Windows), какие страницы нужно складывать в своп, поэтому кладет все подряд.
• Compressed - это объем памяти, который получен после сжатия страниц с помощью механизма Memory Compression (то есть, хранимый в VM Compression Cache).
• Ballooned - это объем памяти, который забрал balloon-драйвер (vmmemctl), чтобы отдать ее другим нуждающимся виртуальным машинам.
• Unaccessed - это память, к которой гостевая ОС ни разу не обращалась (у Windows - это близко к нулю, так как она обнуляет память при загрузке, у Linux должно быть как-то иначе).
• Active - опять-таки, активно используемая память на основе статистики гипервизора.

На хорошем и производительном хосте VMware ESX метрики Compressed, Ballooned, Unaccessed - должны быть около нуля, так как это означает что машины не борются за ресурсы (то есть не сжимают страницы и не перераспределяют память между собой). Ну и, конечно, если показатель Active маленький, стоит задуматься об урезании памяти (но сначала посмотрите в гостевую ОС, она лучше знает, чем гипервизор, все-таки).

Ну и последняя секция Resource Settings:

• Reservation, Limit, Shares, Configured - смотрим сюда.
• Worst Case Allocation - это сколько будет выделено виртуальной машине при самом плохом раскладе (максимальное использование ресурсов), то есть вся память будет использоваться, да еще и накладные расходы будут (т.е., Configured + максимальный Overhead).
• Overhead Reservation - это сколько зарезервировано памяти под Overhead гипервизором.

Ну и в заключение очень рекомендую документ "The Yin and Yang of Memory Overcommitment in Virtualization" - как раз для VMware vSphere.

Компания VMware снова обновила наборы иконок, картинок и visio-стенсилов для своих продуктов VMware vSphere, View, SRM и других.

Что поменялось:

• Внесены изменения в последнюю версию VMware PowerPoint Icons and Images - 3Q10
• Больше 30 новых стенсилов
• Теперь есть connection points для удобного рисования схем
• Новые элементы, такие как vCloud, VAAI, vShield Edge и другие

Скачать наборы можно отсюда:

• Boxshots (коробки с изображениями продуктов) - Visio
• Icons (иконки различных элементов виртуальной и физической инфраструктуры) - Visio
• Products (Различные продукты и схематичное изображение технологий, удобное для схем) - Visio

Помните, что по условиям EULA эти элементы нельзя изменять.

Компания VMware некоторое время назад объявила об очень интересном проекте VMware Project Horizon, который должен быть очередным интересным событием в мире облачных вычислений. Об этом продукте было рассказано еще на прошедшем VMworld Europe 2010, где даже была небольшая демка:

Что же это такое? По сути, это "магазин приложений" в среде пользовательской инфраструктуры, получаемый путем федерации (объединения) нескольких источников приложений (различные компоненты инфраструктуры - MS, виртуализованные приложения ThinApp в виртуальных ПК VMware View, приложения Citrix XenApp и многое другое). А с точки зрения пользователей - это фронтенд для доступа к своим приложениям с различных устройств (ноутбуки, смартфоны, айпады и т.п.):

Для этого, кстати компания VMware даже купила такую компанию Tricipher, которая делает Sigle Sign-On для пользователей корпоративных SaaS приложений (то есть, это управление идентификацией со стороны корпоративной инфраструктуры у SaaS провайдеров).

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

Все это делается по стандартам и протоколам SAML, ADFS или OpenID, которые поддерживают несколько тысяч провайдеров в сфере SaaS:

Ну и не только SAML можно использовать:

И выглядеть это будет примерно так:

Помните мы писали о замечательном человеке Романе, который делает переводы технических документов NetApp, которые дают много полезной информации не только пользователям СХД этого вендора, но и раскрывают общие принципы использования хранилищ для физической и виртуальной инфраструктуры.

Теперь у нас есть еще один документ на русском языке - "Руководство по наилучшим способам использования систем NetApp с VMware vSphere 4.1".

А вот что есть еще интересного о виртуализации на русском языке (остальное - здесь):

Использование NFS в VMware 
Bikash Roy Choudhury | NetApp | Июль 2010 | TR-3839 
В данном документе рассматриваются потенциальные преимущества использования в инфраструктуре хранения VMware работы по Network File System (NFS) с системы хранения NetApp®.
Скачать .pdf (22 страницы) html

Интеграция NetApp с VMware vStorage API
Robert McDonald | NetApp | Июль 2010 | WP-7106 
Этот документ описывает набор поддерживаемых в NetApp средств VMware® vStorage APIs for Array Integration (VAAI). VAAI это набор API, позволяющих виртуализованной инфраструктуре на базе VMware vSphere™ тесно интегрироваться с системой хранения. 
Скачать .pdf (8 страниц) 

Наилучшие методы использования систем хранения NetApp для решений виртуализации Microsoft Hyper-V
Chaffie McKenna, NetApp | Ravi B, NetApp | Декабрь 2009 | TR-3702-1209 
Этот документ содержит руководство и описание наилучших методов для построения интегрированной архитектуры и внедрения Microsoft Hyper-V с использованием систем хранения NetApp. Технологии NetApp, рассматриваемые в этом руководстве важны для создания эффективного с точки зрения затрат, производительности, гибкости и дружественности к окружающей среде интегрированного решения хранения данных виртуальной серверной инфраструктуры. 
Скачать .pdf (105 страниц)

Руководство по наилучшим способам использования систем NetApp с VMware Virtual Infrastructure 3
M. Vaughn Stewart, Michael Slisinger, Larry Touchette, | NetApp | TR 3428
Перевод Р. Хмелевского
Данный документ рассматривает наилучшие методы решений при внедрении VMware Virtual Infrastructure с использованием системы хранения Network Appliance FAS. Полезные советы, особенности установки и настройки, как на стороне системы хранения, так и на стороне VMware ESX/VI.
Скачать .pdf (76 страниц) 

Мы уже много писали о продукте StarWind Enterprise HA, который позволяет создавать отказоустойчивые хранилища для серверов виртуализации VMware ESX на базе обычных Windows-серверов. Недавно вышла версия StarWind Enterprise HA 5.5, в которой реализован канал Heartbeat для еще большей надежности продукта. В данной статье рассматривается весь процесс создания отказоустойчивого кластера StarWind, который выдерживает отказ одного из узлов, отвечающего за работу с томами VMFS для серверов ESX / ESXi.

Некоторые пользователи VMware vSphere используют режим объединения нескольких серверов VMware vCenter Linked Mode. Этот режим позволяет объединить в интерфейсе vSphere Client несколько датацентров, каждый из которых управляется своим сервером VMware vCenter.

При этом режим vCenter Linked Mode имеет несколько существенных требований к инфраструктуре:

• Обязательно наличие разрешения имен DNS между серверами vCenter и компонентами виртуальной инфраструктуры
• Серверы vCenter могут быть в разных доменах, но между ними обязательные двунаправленные трасты
• Необходимо открыть в фаерволе порты для ADAM
• При соединении серверов vCenter установщик должен запускаться под доменным аккаунтом, имеющим права локального администратора на каждом из серверов
  
• Должна быть настроена синхронизация времени между серверами vCenter, и время не должно отличаться более, чем на 5 минут

Последний пункт и вызывает самые частые нарекания. Пользователи получают вот такую ошибку при попытке объединения:

Error 28039.Setup cannot join vCenter Server to the linked mode group...Check the jointool-0.log for more information

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

Как многие из вас знают, есть такой замечательный продукт StarWind Enterprise, который позволяет создать отказоустойчивый кластер хранилищ для виртуальных машин VMware vSphere. Об этом продукте у нас есть целый раздел, но наиболее полезные страницы - это эта, эта, эта и эта.

Схема организации кластера высокой доступности хранилищ StarWind Enterprise выглядит так:

То есть, каждый из узлов StarWind должен иметь, по крайней мере, 2 сетевых интерфейса - для доступа хост-серверов виртуализации к хранилищу и для синхронизации данных узлов между собой (чтобы работа продолжилась в случае отказа одного из узлов - данные пишутся на узлы синхронно). Но само собой, 2 интерфейса - это очень ненадежно и небыстро. Поэтому лучше делать NIC Teaming и для канала синхронизации (надежность), и для канала работы с хранилищем по iSCSI (скорость). Поэтому, по-хорошему, нужно 4 интерфейса.

Вы уже все, конечно же, скачали версию StarWind Enterprise 5.5 и приступили к ее установке. Где определяются параметры сетевых интерфейсов? Запустим, например, мастер создания виртуального диска, работающего в режиме высокой доступности (High Availability):

Здесь указываются параметры сервера-партнера в кластере высокой доступности. Имя или IP-адрес, который сюда вводится - это и есть интерфейс узла, через который происходит доступ со стороны хост-серверов VMware ESX (то есть то, что на предыдущей картинке сверху). А вот в этом шаге мастера:

В поле "Интерфейс" указывается IP-адрес интерфейса, по которому происходит синхронизация узлов между собой (то, что на первой картинке сбоку). Кроме того, в версии 5.5 появилось новое поле Heartbeat - это интерфейс, через который два узла кластера Heartbeat обмениваются сигналами доступности, чтобы при обрыве канала синхронизации не возникло ситуации Split Brain (понять что это такое вы можете из статьи "Новая возможность StarWind Enterprise HA - устранение ситуации Split Brain"). Вот в поле Heartbeat этот адрес и нужно задавать. Само собой, лучше, если подсеть heartbeat у вас будет отдельная в целях повышения надежности.

Кстати, заметьте, что есть галка "Auto synchronization after failure", которая позволяет в случае отказа одного из узлов, а потом ввод его в строй (например, перезагрузка) автоматически синхронизировать узлы между собой. Раньше это делалось только вручную.

И еще одно - вы уже заметили, что на картинках меню на русском языке. Переключается язык тут:

Мелочь, а приятно.

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

Вчера компании VMware и LG заключили соглашение о партнерстве в области виртуализации для смартфонов под управлением ОС Google Android. Суть инициативы обеих компаний в следующем: дать возможность пользователю разделить окружение с личными приложениями и данными (развлечения, персональная информация) и окружение с корпоративными данными и приложениями (email, доступ к корпоративной инфраструктуре). То есть, основная идея данного начинания - информационная безопасность.

LG and VMware announced this morning a partnership that brings visualization to Android smartphones. The non-nerd premise is this: You've got your standard Android smartphone, with your e-mail, your apps, your phone number. And in a virtual space on the same device, you have another set of apps, corporate e-mail, another phone number — completely sandboxed from your personal stuff, unable to talk to or access its data.

Интересное видео из анонса:

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

Компания Citrix, после многочисленных анонсов, не так давно сделала доступным для скачивания продукт для виртуализации инфраструктуры корпоративных ПК предприятия Citrix XenDesktop 5.0. О некоторых новых возможностях продукта мы уже писали (кроме того, достаточно полный список доступен здесь).

Кстати, есть интересный сайт http://edocs.citrix.com, где уже доступна документация по Citrix XenDesktop 5.0:

• Introduction
• XenDesktop 5 System Requirements
• Planning a XenDesktop Deployment
• Evaluating XenDesktop 5
• Licensing Your Product
• XenDesktop Scalability Guidelines
• Known Issues in XenDesktop 5
• Issues Fixed in XenDesktop 5

Кроме того, есть вот такой наборчик документов:

• How to Enable Persistent CDF Tracing in XenDesktop 5
• Enabling WinRM for Desktop Director
• Citrix XenDesktop 5 - Issues Fixed in This Release
• XenDesktop 5 SDK Cmdlet Help
• Virtual Desktop Agent Configuration
• Web Interface and XML Resiliency in XenDesktop Environments
• How to Enable Controller Service Logging in XenDesktop 5
• XenDesktop 5 SQL Transaction Log Growing Excessively

И да, есть обучающий бесплатный курс по Citrix XenDesktop 5.0 и целая серия познавательных видео. Так что ничего не мешает вам скачать пробную версию Citrix XenDesktop 5.0 прямо сейчас и сравнить его с VMware View 4.5. Тем более, что, говорят, установка стала проще, а интерфейс понятнее.

Отделение технической поддержки компании VMware выпустила интересный документ "VMware View Resolution Paths", который представляет собой ассоциативную карту (Mind Map), позволяющую решать проблемы, возникающие в инфраструктуре виртуальных ПК VMware View 4.5.

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

Вы конечно уже слышали, что вышла новая версия StarWind Enterprise 5.5, предоставляющая еще больше возможностей для создания отказоустойчивых хранилищ iSCSI для хост-серверов виртуализации VMware vSphere / ESX (больше тут, тут и тут).

Создавать iSCSI-хранилища с помощью этого продукта вы можете на любом Windows-сервере, к которому может быть подключено локальное хранилище (свои диски или DAS), либо общее хранилище (Fibre Channel / NFS / iSCSI).

Только вот при установке StarWind Enterprise на Windows Server 2003 вы получите вот такое сообщение:

В Windows Server 2008 этот инициатор уже есть, а вот в Windows 2003 нужно установить Microsoft iSCSI Initiator для StarWind. Для этого переходим по ссылке "Microsoft iSCSI Software Initiator Version 2.08" и устанавливаем его в Windows Server 2003:

после чего перезагружаем сервер.

И да, для тех кто уже имеет инсталляцию StarWind Enterprise HA. Как обновить продукт на версию 5.5:

1. Надо устанавливать версию StarWind 5.5 прямо поверх предыдущей (при этом хранилище для виртуальных машин будет оставаться доступным и прерывания их работы не произойдет).

2. Сначала обновляем первый узел кластера StarWind Enterprise HA.

3. Затем синхронизируем ноды между собой.

4. Обновляем второй узел и снова синхронизируемся.

Очередной обмер причинных мест произошел на конференции TechEd в Берлине. Некто Bernard Tritsch, выступая с презентацией "RDP, RemoteFX, ICA/HDX, EOP and PCoIP – VDI Remoting Protocols Turned Inside Out", показал интересные картинки, где сравниваются различные протоколы доступа к инфраструктуре виртуальных ПК (VDI) в контексте выполнения различных задач:

• Microsoft RDP и Microsoft RDP 7.1 с технологией RemoteFX (ранее известный как Calista)
• Citrix ICA и семейство технологий HDX for XenApp and XenDesktop (ранее известный как PortICA)
• Quest EOP (Experience Optimized Protocol, RDP+)
• VMware/Teradici PCoIP (PC over IP)
• Ericom Blaze (RDP+)
• Red Hat RHEV SPICE (Simple Protocol for Independent Computing Environments, through acquisition of Qumranet)
• HP RGS (Remote Graphics Solution)
• Oracle/Sun ALP (Appliance Link Protocol, Sun Ray)
• Oracle/Sun/Tarantella AIP (Adaptive Internet Protocol)

Собственно, результаты:

Ну а за Teradici не заржавело - и они сразу сделали презентацию, что проблем нет:

Однако из многочисленных (и не особо-то опровергаемых VMware) комментариев в сети видно, что PCoIP пока все-таки проигрывает Citrix HDX. Но! Это всего лишь протокол, а в инфраструктуре VDI - протокол хоть и важен, но это далеко не единственное, что нужно учитывать при выборе решения для виртуализации корпоративных ПК предприятия.

В самом конце августа 2010 года компания VMware объявила о приобретении компании Integrien, занимающейся разработкой решений для выявления проблем производительности виртуальной инфраструктуры. А вот теперь на сайте VMware появилась промо-акция, по условиям которой все покупатели VMware vSphere (кроме серии Essentials) получают бесплатно лицензии на 50 виртуальных машин для продукта Alive VM (и один год поддержки и подписки на обновления, SnS):

Как заявляется на сайте Integrien (который еще не стал частью корпоративного брендинга VMware), Alive VM - это средство для отслеживания работоспособности виртуальной инфраструктуры VMware vSphere, определения проблем производительности и "узких мест", а также аналитики в сфере доступных и необходимых вычислительных ресурсов.

Больше всего это похоже на игру, где нужно двойным кликом убирать шарики одного цвета в ряд (посмотрите, например, видео):

В целом, Alive VM - это такой общий Dashboard, в котором виден виртуальный датацентр VMware vSphere с его объектами (кластеры, виртуальные машины) в которые можно "проваливаться" и смотреть различные характеристики рабочей нагрузки, health-статуса и анализировать, какова загрузка вычислительных ресурсов и нужно ли еще их добавить в датацентр. Также можно видеть как изменилась производительность виртуальной машины вследствие каких-либо причин, и какое изменение конфигурации это вызвало.

Поставляется Alive VM в виде виртуального модуля (Virtual Appliance), также доступна версия для установки на сервер Windows Server. Все действия с фронтендом производятся через веб-интерфейс. Плюс не нужна отдельная база данных.

Условия акции - продукт бесплатно предоставляется для всех пользователей, купивших продукт VMware vSphere, участвующий в акции, в период с 23 ноября 2010 года по 1 марта 2011 года (лицензии на 50 наблюдаемых виртуальных машин).

Скачать Alive VM можно по этой ссылке. Ну а где купить VMware vSphere вы уже знаете.

В очень интересной презентации "Transitioning to ESXi with vSphere 4.1" от Mark'а Monce (которую неплохо бы просмотреть всем администраторам VMware ESX в связи со скорым обязательным переходом VMware на гипервизор ESXi) обнаружились интересные моменты:

1. Если через веб-браузер по https зайти на VMware ESXi по ссылке:

https://<hostname>/host

мы увидим его конфигурационные файлы:

2. Если зайти на VMware ESXi по адресу:

https://<hostname>/host/messages

мы увидим его лог-файлы:

3. А если сходить на ESXi по этому адресу:

https://<hostname>/folder

То мы увидим содержимое VMFS-томов:

Напишите в комментариях, пожалуйста, если что-то из этого не работает.

Компания VMware выпустила 17-страничный документ "Performance of Virtualized SQL Server–Based VMware vCenter Database", где рассматриваются основные аспекты производительности базы данных Microsoft SQL Server для сервера VMware vCenter в виртуальной машине инфраструктуры vSphere.

Результаты:

• Большинство требовательных к ресурсам операций базы MS SQL на виртуальном vCenter по производительности сравнимы с физической инсталляцией.
• SQL Server–based vCenter, управляющий большим количеством хост-серверов ESX и кластеров, вполне может работать в виртуальной машине.
• Базы данных MS SQL в общем случае работают почти без потери производительности в виртуальных машинах на vSphere 4.1.

В решении для виртуализации настольных ПК предприятия VMware View 4.5 доступ к виртуальным компьютерам на серверах VMware ESX происходит с помощью VMware View Client 4.5. У этого клиента есть несколько интересных параметров командной строки, которые можно задавать в свойствах ярлыка wswc.exe, делающих инфраструктуру доступа более гибкой.

Итак параметры командной строки VMware View Client 4.5:

• -desktopName XXX - виртуальный ПК, который автоматически запускает при старте клиентаt 
• -domainName XXX - домен, подставляемый по умолчанию Domain for server login
• -file XXX - файл в котором можно задавать данный настройки Command Line
• -languageId XXX - код языка (LCID), используемый клиентом. Например, 0×409 - это английский. 
• -nonInteractive - пропускать сообщения об ошибках для полностью скриптового старта клиента
• -password XXX - пароль для соединения с сервером View Connection Server  
• -userName XXX - имя пользователя для входа 
• -smartCardPIN XXX - PIN-код для смарт-карт 
• -desktopProtocol XXX - попытка использовать заданный протокол доступа (PCoIP или RDP)
• -desktopLayout XXX - указания размера и способа отображения десктопа (принимаются параметры: fullscreen, multimonitor, windowLarge, windowSmall) 
• -serverURL XXX - URL сервера View Connection Server 
• -logInAsCurrentUser XXX - вход как current user (true или false) 
• -unattended - старт в режиме unattended mode (без взаимодействия с пользователем)
• -connectUSBOnStartup XXX - проброс всех USB в виртуальный ПК при запуске клиента (true или false) 
• -connectUSBOnInsert XXX - проброс устройства USB в виртуальный ПК, когда новое устройство втыкается в рабочую станцию (true или false) 
• -printEnvironmentInfo - вывести информацию о системе 
• -rollback - откат десктопа для Local Mode (нужен параметр -desktopName) 
• -standalone - не поддерживается!: запуск еще одной копии View Client для тестирования 
• -confirmRollback - подтверждение операции rollback для неинтерактивного режима (non-interactive mode) 
• -? - Показ помощи с данными командами

Кроме того, при установке клиента VMware View Client 4.5 можно использовать следующие параметры (например, при запуске файла VMware-viewclient-x86_64-4.5.0-293049.exe):

INSTALLDIR=%ProgramFiles%\VMware, Inc.\VMware View\Client 
VDM_SERVER=<IP-Address> или FQDN-имя 
DESKTOP_SHORTCUT=0 (0=не создавать иконку на рабочем столе, 1=создавать) 
QUICKLAUNCH_SHORTCUT=0 (0=не создавать иконку в панели быстрого запуска, 1=создавать) 
STARTMENU_SHORTCUT=0 (0=не создавать пункт в меню "Пуск", 1=создавать) 
REBOOT="ReallySuppress" (не перезагружать компьютер по окончанию установки)

Кроме этих свойств, можно также выбирать компоненты, которые будут установлены в VMware View Client. Их кодовые названия: Core, MVDI, ThinPrint, TSSO, USB. Само собой, компонент "Core" - обязателен. Можно использовать также ключ ALL для установки всех комонентов.

ADDLOCAL=Core, MVDI, ThinPrint, TSSO, USB или просто ALL

Расшифровка:

Core = ядро 
MVDI = поддержка Local Mode (если есть в дистрибутиве)
ThinPrint = возможность Universal Printing (Print redirection) 
TSSO = Сквозной логин (Single Sign-On) 
USB = Перенаправление USB-устройств (USB Redirection)

Примеры:

VMware-viewclient-x86_64-4.5.0-293049.exe /S /V /qn DESKTOP_SHORTCUT=0 VDM_SERVER={server_name} INSTALLDIR="C:\Program Files\VMware\VMware View\Client" /l C:\Logs \VMware_Client45.log REBOOT=Reallysupress

VMware-viewclient-x86_64-4.5.0-293049.exe /s /v"/qn VDM_SERVER={server_name}ADDLOCAL=All"

VMware-viewclient-x86_64-4.5.0-293049.exe /s /v /qn RebootYesNo="No" REBOOT="ReallySuppress" VDM_SERVER={server_name} ADDLOCAL=Core,TSSO,USB DESKTOP_SHORTCUT=1 STARTMENU_SHORTCUT=1

Для "тихой" (silent) установки пользователю понадобятся права администратора, поэтому надо предусмотреть этот момент (например, через Group Policies).

Внимание: имена параметров чувствительны к регистру!

Сегодня должен быть доступен релиз продукта StarWind Enterprise HA версии 5.5, который позволяет превратить любой Windows-сервер в отказоустойчивое хранилище данных для хост-серверов VMware ESX или Microsoft Hyper-V, работающее по протоколу iSCSI (а значит, не надо вкладывать деньги в дорогостоящие Fibre Channel хранилища). Подробнее о продукте можно прочитать тут, тут, тут, тут и тут (и, вообще, есть для этого специальный раздел на сайте).

Новые возможности StarWind Enterprise HA 5.5:

• High Availability: Добавлена возможность устранения ситуации Split Brain (в случае обрыва канала синхронизации). Теперь в случае отсутствия связи между узлами по сети синхронизации StarWind обрабатывает эту ситуацию с помощью сигналов доступности (Heartbeat) по сети взаимодействия с хост-серверами.
  
  
  
  Если в этой сети обнаруживается, что второй узел доступен, а недоступен только канал синхронизации, то первичный узел кластера StarWind продолжает запись данных виртуальных машин, а вторичный узел отключает всех своих клиентов. Таким образом сохраняется целостность кластера и отсутствует потери данных, а также простои виртуальных машин. Тем не менее, для канала синхронизации все равно лучше использовать несколько сетевых интерфейсов и NIC Teaming.
  
• High Availability: множественные улучшения производительности работы кластера StarWind.
  
• High Availability: поддержка собственной технологии Fast Sync для устройств работающих в режиме кэширования write-back (подробнее здесь). Эта технология позволяет в случае наступления события отказа одного из узлов кластера хранилищ StarWind, а затем его восстановлении (Failback) сделать быструю синхронизацию резервного узла с основным за счет передачи только изменений с момента последнего "живого" состояния основного узла. А вообще методов кэширования в StarWind iSCSI есть два (и они, в зависимости от нагрузки, увеличивают производительность до 30-50%):
  
  
  
• High Availability: Если оба узла кластера хранилища StarWind iSCSI отказали или выпали из сети, и после этого начала работать полная синхронизация этих узлов, то устройства хранения будут доступны хост-серверам ESX или Hyper-V сразу же (до ее окончания). Данные будут записываться на узел, который выбран в качестве источника синхронизации (synchronization source).
• High Availability: Добавлена полная поддержка аутентификации в iSCSI SAN по паролю (CHAP authentication).
• CDP/Snapshots: Доработан механизм работы с дисками с GPT разделами.
• Virtual Tape: Исправлена ошибка, связанная с изменением образа файла virtual tape. Параметры устройства теперь показывают корректное имя файла. Если в устройство не загружено ни одного файла-образа Virtual Tape, то в свойствах отображается "None - Virtual Tape device is not loaded" и нулевой размер файла.
• GUI: Множество добавлений и исправлений в основное средство управления - Management Console.

Скачать пробную версию StarWind Enterprise HA 5.5 можно по этой ссылке. Ну а продается StarWind в компании VMC.

Мы уже писали о средстве VMware vCloud Director для управления облачными виртуальными инфраструктурами на базе платформы VMware vSphere. Этот "менеджер менеджеров" позволяет организовать процесс управления виртуальными вычислительными ресурсами таким образом, чтобы ИТ-подразделение компании могло выделять сервисы в виртуальных машинах по запросу, учитывая качество обслуживания различных категорий пользователей, считать потребляемые ресурсы=деньги (для этого есть дополнение - VMware vCenter Chargeback) и контролировать жизненный цикл виртуальных машин (для этого есть надстройка VMware vCenter Request Manager).

Компания Microsoft недавно анонсировала средство управления System Center Virtual Machine Manager (SCVMM) 2012 для платформы Hyper-V, которое в будущем может стать конкурентом VMware vCloud Director. Этот продукт реализует модную нынче концепцию Infrastructure as a Service (IaaS).

Как сообщили в Microsoft, данный продукт находится в стадии Community Technology Preview (CTP), но уже можно говорить о некоторых возможностях которыми будет обладать SCVMM 2012  для управления крупными облачными инфраструктурами:

• SCVMM 2012 будет иметь 2 основных роли: Service Management (управление жизненным циклом виртуальных машин и приложений в них) и Fabric Management (управление конфигурациями вычислительных ресурсов: computing, networking, storage). Это похоже на то, что делает VMware vCloud Director.
• Взаимодействие с системами хранения будет проходить посредством механизма SMI-S (Storage Management Initiative Specification). SCVMM 2010 будет выделять новые LUN на уровне кластера.
• Возможность создания logical networks (абстракция IP подсетей, VLAN'ов и DNS доменов) для внутреннего облака. Эта возможность есть и у VMware.
• Возможность определять и назначать пулы IP-адресов логическим сетям (logical networks), а также пулы MAC-адресов группам хостов.
• Возможность копирования шаблонов виртуальных машин SAN-to-SAN при развертывании сервисов.
• Поддержка модулей Citrix NetScaler в качестве балансировщика нагрузки для создания адресов Virtual Private Addresses (VIPs) и назначения их нужным сервисам.

Все, что пока есть на данный момент, это вот такой скриншот SC VMM 2012:

Говорят, что System Center Virtual Machine Manager 2012 будет доступен во второй половине 2011 года.

Как знают многие администраторы, была раньше у Microsoft такая утилита System Preparation Tool (Sysprep), которая позволяла подготовить ОС Windows в автоматизированному развертыванию. До Windows Vista эта утилита поставлялась отдельно в виде KB, а начиная с Vista - это средство уже встроено в установку Windows. Где может пригодиться Sysprep?

При установке VMware View Composer 2.5 из комплекта VMware View 4.5 у вас могут возникнут следующие 2 вида ошибок:

• VMware View Composer - Unable to open firewal
• VMware View Composer - Unable to close firewal

То есть, если у вас выключен фаервол Windows Server, то будет ошибка "open firewall", а если включен - то "unable to close". При этом вы запускете установку под администратором.

Решение: запустить установку, нажав правой кнопкой мыши на файле установки View Composer и выбрав "Run As Administrator". Парадоксально, но факт - работает.

Есть такая компания VMTurbo - они делают утилиты для виртуальной инфраструктуры VMware vSphere. Кое-что у них получается, кое-что нет, а вот на днях они выпустили 2 новых утилиты: Host Resolver 1.0 и Storage Reporter 1.0. Обе они построены на базе виртуальных модулей (Virtual Appliance) с ОС Novell SUSE Linux как часть пакета VMTurbo Integrated Management Suite для виртуальных сред VMware.

VMTurbo Host Resolver 1.0

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

VMTurbo Storage Reporter 1.0

Эта утилита позволяет проанализировать использование виртуальными машинами систем хранения, понять основные параметры производительности при работе со стораджами (IOPS, Latency) и отслеживать основные их параметры с течением времени (заполненность, снапшоты и прочее). Кроме того, может выдавать рекомендации по необходимости внесения изменений в конфигурации хранилищ (например, расширение).

Кстати, у этих ребят есть и бесплатные утилиты: VMTurbo Monitor и VMTurbo Watchdog.

Как вы знаете, с помощью средства VMware ThinApp, входящего в состав решения для виртуализации настольных ПК VMware View 4.5, можно производить доставку виртуализованных приложений пользователям.

То есть, приложение упаковывается в один exe-файл и развертывается на рабочих станциях пользователей с помощью msi-установщика (см. здесь как это делается с VMware View 4.5). Это очень удобно при массовом развертывании и обслуживании приложений. Помните такой продукт Thinstall, с помощью которого делали предустановленные приложения? Так вот ThinApp - это он и есть, только теперь под брендом VMware.

Но есть и еще один способ доставки приложений с помощью VMware ThinApp - это возможность их запуска пользователями с общей сетевой папки (SMB Share):

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

Однако, когда у нас приложение VMware ThinApp работает постоянно, и множество пользователей его используют - то как же нам его обновить (например, это веб-браузер, упакованный в файл firefox.exe)?

На самом деле есть интересный механизм: вы можете положить в папку с приложением его обновленную версию, но с расширением не *.exe, а *.1 - и все новые подключения будут использовать его!

То есть:

1. Вы упаковываете приложение firefox.exe с помощью VMware ThinApp и кладете его на SMB Share.

2. Создаете на рабочих столах пользователей ярлык, указывающий на \\<server>\<share>\Firefox.exe.

3. Пользователи начинают его использовать - файл firefox.exe залочен.

4. Вы создаете новый пакет с помощью VMware ThinApp, называете его firefox.1

5. Все текующие подключения пользователей используют старый firefox, а вот все новые обращения к firefox.exe - перенаправляются к файлу firefox.1 - и пользователи используют обновленное приложение.

6. Если нужен еще апдейт - делаете пакет, назваете его firefox.2 и т.п.

7. Если нужно откатиться на предыдущую версию - делаете пакет firefox.3, который собран из предыдущей версии приложения.

Если пользователи перестанут использовать firefox.1, начав использовать firefox.2, firefox.1 можно удалить. Но! Никогда не удаляйте firefox.exe, так как на него указывает ярлык приложения на рабочем столе пользователя.

Компания VMware выпустила очень полезный и нужный Performance Best Practices for VMware vSphere 4.1, который нужно прочитать каждому администратору более-менее серьезной виртуальной инфраструктуры серверов ESX. Содержание вполне конкретное:

• Hardware for use with VMware vSphere
• ESX and virtual machines
• Guest operating systems
• Virtual infrastructure management

Например:

To establish a network connection between two virtual machines that reside on the same ESX system, connect both virtual machines to the same virtual switch. If the virtual machines are connected to different virtual switches, traffic will go through wire and incur unnecessary CPU and network overhead

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

В прошлой заметке мы писали о том, какие типы дисков бывают в продукте StarWind Enterprise, позволющем создать отказоустойчивую инфраструктуру хранения данных виртуальных машин серверов VMware ESX или Microsoft Hyper-V.

Сегодня мы посмотрим на мастер создания виртуального диска с поддержкой мгновенных снимков (снапшотов), который будет предоставлять доступ хост-серверам виртуализации по iSCSI. Снапшоты могут оказаться полезными при разработке и тестировании (временные снапшоты хранилищ виртуальных машин), а также для защиты данных от утери или сбоев в виртуальной инфраструктуре.

Для данного типа диска важен параметр Operation Mode, который задает режим его работы. Этот диск в StarWind Enterprise может работать в одном из четырех режимов:

• Growing Image (Thin Provisioning) - образ диска на физическом устройстве будет создан минимального объема (тонкий диск). Для серверов ESX он будет виден как полноценное хранилище указанного объема, а сам файл образа будет расти по мере его наполнения данными. Снапшот хранилища можно сделать только вручную. Для этого из контекстного меню для устройства на iSCSI Target надо выбрать пункт Create Snapshot. Этот режим работы диска подходит для создания снимков хранилища при тестировании каких-нибудь обновлений или глобальных изменений в прикладных системах виртуальных машин.
  
  

  

• Auto-Restored Snapshot - данный тип диска как раз подходит для разработки и тестирования. В таком режиме хранилище виртуальных машин во время одной сессии iSCSI будет изначально работать в режиме снапшота, а при окончании сессии - снапшот откатится к изначальному состоянию. Представьте, например, что вы тестируете связку систем на хранилище, но не хотите вносить изменения в эталонный виртуальный диск. Для такого диска можно задать лимит хранимых снапшотов (опция Limit maximum number of stored snapshots).
• Snapshot and CDP - в таком режиме StarWind будет автоматически создавать снапшоты хранилищ с заданным интервалом времени (опция Snapshot auto creation with interval of (minutes)). Такой тип диска полезен для постоянной защиты данных (Continuous Data Protection, CDP) хранилищ виртуальных машин от их утери или порчи. В случае сбоя можно откатиться к нужному снапшоту.
• Read-Only - такой диск будет доступен только для чтения, и для него нельзя будет создать снапшот. Этот диск подходит для создания хранилищ с какими-нибудь дистрибутивами или шаблонами, куда не потребуется вносить изменения.

Теперь что касается восстановления хранилищ из снапшотов. Пока восстанавливать их из интерфейса StarWind нельзя (как, например, дерево снапшотов в VMware vSphere). Чтобы восстановить хранилище, вам понадобится пересоздать iSCSI Target и указать существующих виртуальный диск снапшота в папке с данным диском. В скором времени нам обещают восстановление снапшотов из GUI продукта StarWind.

Скачать пробную версию ПО StarWind Enteprise HA можно по этой ссылке. Купить StarWind можно в компании VMC.

Мы уже писали о команде esxtop для серверов VMware ESX, которая позволяет отслеживать основные параметры производительности хост-сервера и его виртуальных машин. Duncan Epping недавно добавил еще несколько интересных моментов в свое руководство по работе с утилитой esxtop, некоторые из которых мы сейчас опишем.

Итак:

1. Для того, чтобы использовать пакетный режим работы esxtop (batch mode), нужно использовать ключ -b:

esxtop -b >perf.txt

Это позволит вывести результаты команды esxtop в файл perf.txt. Для задания числа хранимых итераций используйте ключ -n (например, -n 100).

Очень удобно для сбора исторических данных производительности на хосте VMware ESX.

2. Контролируйте счетчик %SYS - он показывает загрузку системных ресурсов хоста (в процентах). Рекомендуется, чтобы он не превышал 20 для системных служб.

3. Для установки частоты обновлений результатов esxtop используйте клавишу <s>, далее задавайте интервал в секундах:

В пакетном режиме этот интервал задается ключом -d (например, -d 2).

4. Для отслеживания метрик конкретной виртуальной машины можно ограничить вывод конкретным GID. Например, чтобы посмотреть ВМ с GID 63, нажмите клавишу <l> (list) и введите этот GID:

5. Чтобы ограничить количество выводимых сущностей, используйте клавишу <#>. Например, можно сделать вывод первых 5:

И сами кнопки в режиме работающей esxtop:

c = cpu  
m = memory  
n = network  
i = interrupts  
d = disk adapter  
u = disk device (включая NFS-девайсы)  
v = disk VM  
y = power states    
V = показывать только виртуальные машины  
e = раскрыть/свернуть статистики CPU для конкретного GID  
k = убить процесс (только для службы техподдержки!)  
l = ограничить вывод конкретным GID (см. выше)  
# = ограничить число сущностей (см. выше)    
2 = подсветка строчки (двигает фокус вниз)  
8 = подсветка строчки (двигает фокус вверх)  
4 = удалить строчку из результатов вывода  
f = добавить/удалить колонки
o = изменить порядок колонок
W = сохранить сделанные изменения в файл конфигурации esxtop
? = помощь для esxtop