После 16 месяцев разработки сообществом виртуализации Xen выпущен первый релиз платформы для организации облачных вычислений Xen Cloud Platform 1.0.

Новая версия Xen Cloud Platform 1.0 доступна для загрузки на сайте проекта Xen. Данный пакет возможно использовать для организации "облачных" инфраструктур на базе площадок сервис-провайдеров (аренда виртуальных машин - IaaS), а также для создании внутренних облаков в крупных организациях. То есть, данный пакет - это не только гипервизор Xen, но и средства управления облачной инфраструктурой, а также средства для организации взаимодействия между облаками.

Данное ПО можно дорабатывать под собственные нужды предприятия, оно распространяется по лицензии GPLv2, сам же код основан на исходниках продукта Citrix XenServer.

После релиза XCP 0.5 с прошлого лета добавились следующие функции:

• Включен гипервизор Xen 3.4.2
• Ядро Linux 2.6.32 privileged domain
• VM Protection and Recovery - настройка мгновенных снимков (снапшотов) по расписанию и архивирование виртуальных машин через функции snapshot или export
• Local host storage caching - локальное кэширование виртуальных машин на дисках хост-сервера для снижения нагрузки на общее хранилище
• Boot from SAN with multipathing support - загрузка хост-серверов Xen из SAN с поддержкой доступа по нескольким путям.
• Improved Linux guest support - обновленные щаблоны Ubuntu, Fedora 13/Red Hat Enterprise Linux (RHEL) 6, RHEL / CentOS / Oracle Enterprise Linux версий от 5.0 до 5.5 с поддержкой шаблона RHEL 5 для развертывания сервисов в облаке.
• Enhanced guest OS support - поддержка гостевых ОС Windows 7 SP1, Windows Server 2008 R2 SP1, Windows Server 2003 и Suse Linux Enterprise Server (SLES) 11 SP1
• Improved MPP RDAC multipathing - отчетность о статусе пути в конфигурации с несоколькими путями к СХД, а также отчетность и возможность срабатывания оповещений (health reporting and alerting) через XAPI.
• Snapshot improvements - улучшен механизм освобождения пространства на хранилище после удаления снапшотов, в т.ч. запущенной виртуальной машины.
• Поддержка драйвера blktap2 вместо blktap1 (улучшена работа с VHD-дисками, их клонирование)
• Поддержка средства управления Citrix XenCenter 5.6 FP1 (тут)
• Поддержка интеграции с платформой Openstack Bexar

Какие функции Xen Cloud Platform были раньше:

• Драйверы Windows PV, сертифицированные Microsoft
• Интерфейс XAPI для управления через Web
• Управление жизненным циклом виртуальных машин: Live snapshots, checkpoint, migration
• Пулы ресурсов: Safe live relocation, auto configuration, DR
• Конфигурация хост-серверов: управление системами хранения, сетевым взаимодействием, электропитанием
• Регистрация событий и нотификация администраторов
• Взаимодействие с ВМ по каналу SSL
• Возможности обновления платформы и накатывания патчей
• Мониторинг производительности
• Поддержка SR-IOV
• Установщик с CDROM и сети
• Полнофункциональное управление через CLI (команды семейства xe) и интерфейс "web services API"
• Поддержка распределенного коммутатора Open vSwitch
• Поддержка средств управления Xen Orchestra, Xen Cloud Control System (XCCS), OpenXenManager, Xen Web Manager и Zentific.

Коллеги, продолжаем нашу с вами совместную дискуссию о решении StarWind Enterprise, которое позволяет создать недорогое отказоустойчивое iSCSI-хранилище для виртуальных машин на серверах виртуализации VMware ESX и Microsoft Hyper-V. Для тех, кто не знает что это такое - пройдемте сюда, сюда и сюда.

Некоторым из вас известно, что только успела выйти версия StarWind Enterprise 5.6 с поддержкой дедупликации, как уже открыто бета-тестирование версии StarWind Enterprise 5.7 (для запроса беты пишите на beta@starwindsoftware.com). Что нового будет в следующей версии:

• Поддержка нескольких маршрутов для канала синхронизации. Теперь не обязательно делать NIC Team между узлами - любой маршрут подходит для передачи данных при синхронизации между нодами. Это увеличивает производительность и надежность, позволяя вам выбрать из большего числа конфигураций сети при проектировании решения по хранению виртуальных машин.
• Оптимизация производительности для сетей 10 GbE и 40 GbE (версии CDP и HA - сравнение изданий тут).
• Управление полосой пропускания канала синхронизации (QoS) - теперь можно регулировать приоритезацию трафика при синхронизации HA-узлов, что позволяет не забивать весь доступный канал и не затормаживать доступ к общему хранилищу.
• Дедупликация с размерами блока от 4кб до 256кб на выбор (вместо 512B сейчас), что позволит увеличить производительность процесса дедупликации до десяти раз, при этом качество ухудшится всего на 10-15% (при сравнении 512 байтовых с 4кб блоками). Кроме того, значительно понизится нагрузка на ЦПУ и 90% уменьшятся требования к объёму ОЗУ.
  

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

• Восстановление партнерского узла на другом сервере в случае если он выпал насовсем (сломался сервер) - без вывода хранилища в offline
• Мониторинг активности узлов (read, write, total bandwidth). С каждом релизом (скорее всего) будут добавляться новые метрики
• Компрессия и архивирование старых логов (5.7?). Комментарий разработчиков: с 5.6 мы выставляем сколько хранить логи, так что хз будет ли именно архивирование.
  
• Снапшоты для HA-дисков (5.8)
• Дисконнект инициатора без удаления таргета в интерфейсе
• Превращение диска из обычного в HA target - без вывода хранилища в offline (далекие планы)
• Расширение диска HA-устройства - без вывода хранилища в offline (далекие планы)
• Изменение способов кэширования и объема RAM под это дело - без вывода хранилища в offline (далекие планы)
• Стэк плагинов - возможность использовать таргетам использовать функционал других плагинов (то есть снепшоты для НА, физ. диски для НА и т.д.)

А что бы вы хотели увидеть нового в StarWind? Кидайте в каменты - разработчики здесь и слушают вас.

Компания VMware выпустила первую версию своего клиента VMware View Client для устройств Apple iPad. Данное ПО доступно для скачивания с сайта iTunes.

Напомним, что VMware View 4.6 позволяет организовать инфраструктуру виртуальных ПК предприятия, где к виртуальным компьютерам можно получать доступ с тонких клиентов, компьютеров с клиентом VMware View Client, через веб-браузер, а теперь еще и через iPad.

Обзорное видео по использованию VMware View Client for iPad:

Есть также небольшое руководство по использованию VMware View Client for iPad: "Using VMware View Client for iPad".

Возможности клиента:

• Поддержка работы с рабочим столом виртуального ПК Windows
• Работа по высокопроизводительному протоколу PCoIP
• Интеграция с релизом VMware View 4.6 (или более поздние версии)
• Сервисы для удобного ввода данных в рамках виртуального ПК (клавиатура, мышь - virtual touchpad, симуляция правого клика, выделение обводкой по окружности, множество "многопальцевых" комбинаций)
• Защита соединений при доступе через сети 3G и WiFi
• System monitor, который включает в себя показатели battery level, CPU usage, memory usage, amount of network traffic, used bandwidth and latency
• Динамическое разрешение экрана при повороте устройства
• Mini app store - магазин виртуализованных приложений VMware ThinApp

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

В VMware View есть OEM-компонент .ThinPrint, отвечающий за универсальную печать в виртуальных ПК. Помимо прочего, он умеет делать так называемый Location Based Printing - то есть монтировать в виртуальный ПК необходимый принтер в зависимости от того, с какого клиента пользователь залогинился в виртуальный ПК. Процедура настройки данного механизма приведена в документе "ThinPrint GPO Configuration for Location-Based Printing".

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

• IP-адресе клиента
• MAC-адресе клиента
• Имени пользователя
• Членстве пользователя в группах
• Имени хоста клиента

Чтобы применить эти правила, вам нужно сначала зарегистрировать библиотеку на VMware View Connection Server. Находится она по следующим путям:

• C:\Program Files\VMware\VMware View\Server\extras\GroupPolicyFiles\ThinPrint\ia32\TPVMGPoACmap.dll (32 bit)
• C:\Program Files\VMware\VMware View\Server\extras\GroupPolicyFiles\ThinPrint\x64\TPVMGPoACmap.dll (64 bit)

Делаем это командой:

regsvr32 <path_to>\TPVMGPoACmap.dll

Далее вы увидите новую групповую политику AutoConnect Map Additional Printers for VMware View в Group Policy Editor. Она доступна в ветке Software Settings (сначала создайте новый GPO):

Откройте ее и впишите необходимые параметры политики для печати в зависимости от различных условий (например, MAC-адреса клиента, откуда происходит логин через View Client):

Значения параметров тут достаточно очевидны (например, Client Name - имя хоста, откуда идет доступ с View Client). Здесь важно два момента: укажите точное имя принтера в колонке Printer Name и имя драйвера в колонке Printer Driver (легко ошибиться, берете из виртуального ПК), а также для сетевого принтера не забудьте указать префикс IP_ в колонке IP Port.

Теперь бросьте этот GPO в OU, где у вас лежат ваши виртуальные ПК, к которым вы применяете данную политику печати в зависимости от расположения клиентского устройства. После применения политики, на виртуальном ПК должен появиться ключ реестра:

HKLM\SOFTWARE\Policies\thinprint\PrinterCreateListEx2

Можно также делать все эти вещи по-старинке, с помощью скриптов. Хорошее описание того, как с помощью VBS можно смонтировать сетевые шары можно найти у Barry в статье "VMware View and Location Based Scripts". Вот так, например, с помощью VBS можно получить имя клиентской машины, откуда мы заходим в виртуальный ПК:

Option ExplicitDim WshShell, ClientName, objFSO
Set WshShell = WScript.CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)
ClientName = WshShell.RegRead(“HKCU\Volatile Environment\ViewClient_Machine_Name”)
MsgBox ClientName

Ну а в ветке HKCU\Volatile Environment\ лежит вот что:

Все это можно использовать при написании скриптов.

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

Сегодня мы поговорим о механизме дедупликации данных в StarWind Enterprise iSCSI. Эта функциональность появилась, начиная с версии 5.6. Она позволяет создавать образы виртуальных дисков для хранилищ iSCSI, которые будут содержать только уникальные данные записываемых на них файлов (vmdk, vhd и прочее). Дедупликация работает "на лету", поэтому на хранилище попадают только уникальные блоки:

Объем, занимаемого этим хранилищем, будет расти по мере заполнения его уникальными данными файлов на нем хранящихся. Это позволяет значительно экономить на необходимых дисковых емкостях и понижает совокупную стоимость решения по построению инфраструктуры хранения данных виртуальных машин (c iSCSI она и так весьма небольшая).

Для создания дедуплицированного хранилища нужно выбрать тип диска Advanced Virtual (см типы дисков StarWind) и выбрать его подтип - Deduplicated disk device:

Обратите внимание - сейчас эта возможность экспериментальная (версия StarWind Enterprise 5.6). В следующих релизах она уже будет полностью поддерживаться. Поэтому ее пока используйте только для тестовых или некритичных систем.

Далее создаем новое устройство для виртуального диска, которое определяет максимальный объем хранилища (в нашем случае 5 ГБ):

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

Далее настраиваем параметры кэширования (подробнее в статье о кэшировании в StarWind Enterprise):

Смотрим получившиеся настройки:

И смотрим на получившийся диск в 5 ГБ:

Но реально на хранилище он занимает пока только вот столько:

Добавляем хранилище в vSphere Client:

Видим емкость в 5 ГБ:

Теперь создаем виртуальную машину на этом хранилище с диском в 2 ГБ (этот vmdk-диск указываем как thick, а не thin - то есть он создается сразу файлом в 2 ГБ):

И видим, что общее пространство, занимаемое диском StarWind Enterprise изменилось незначительно (в данном случае я уже был в середине установки Windows 2003 Server в этой виртуальной машине):

То есть в данном случае не просто Thin Provisioning, а полноценная дедупликация данных на лету средствами StarWind Enterprise.

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

Не так давно на сайте проекта VMware Labs (мы о нем уже писали) появился интересный продукт (а точнее Technical Preview) - VMware vCenter XVP Manager and Converter.

На данный момент этот продукт позволяет привязать к средству управления виртуальной инфраструктурой VMware vCenter хост-серверы и виртуальные машины Microsoft Hyper-V. Не секрет, что многие пользователи (особенно в крупных инфраструктурах) используют виртуализацию VMware vSphere и Microsoft Hyper-V одновременно. Например, это может так: VMware vSphere используется для производственной среды, а Hyper-V для тестовых виртуальных машин и малокритичных задач (как вариант - по соображениям экономии).

Так вот VMware vCenter XVP Manager and Converter позволит перенести часть базовых задач по управлению виртуальной средой Hyper-V на сторону vCenter.

Как это работает. После установки vCenter XVP Manager plug-in for vSphere Client в Inventory клиента появляется вкладка Third-Party Hosts, в которой можно добавить хосты Hyper-V:

На данный момент в текущей версии VMware vCenter XVP Manager and Converter доступны следующие функции по управлению хост-серверами и виртуальными машинами Hyper-V:

• Поддержка Microsoft Hyper-V Server 2008, Microsoft Windows Server 2008 (64-bit) с включенной ролью Hyper-V, Microsoft Hyper-V Server 2008 R2, Microsoft Windows Server 2008 R2 с включенной ролью Hyper-V
• Стандартный GUI vCenter Server и привычное Inventory
• Возможность добавления хостов через System Center Virtual Machine Manager (SC VMM)
• Управление питанием виртуальных машин и хостов (перезагрузка, выключение, включение)
• Доступ к физической консоли сервера Hyper-V и консоли виртуальных машин
• Управление виртуальными устройствами виртуальной машины (память, процессоры, диски и т.п.)
• Возможность миграции виртуальных машин Hyper-V на платформу vSphere
• Совместимость с VMware vCenter Server 4.0
• Возможность управления до 50 хостами Hyper-V

Вот пара видеороликов об установке и простейших операциях с VMware vCenter XVP Manager and Converter:

А вот, что можно делать с виртуальной машиной Hyper-V и ее гостевой системой через vSphere Client:

Кроме того, в VMware vCenter XVP Manager and Converter есть возможность конвертации виртуальной машины Hyper-V на сервер VMware ESX / ESXi. Конвертация происходит путем установки агента внутрь виртуальной машины (то есть, по сути виртуальная машина воспринимается как физическая):

Скачать VMware vCenter XVP Manager and Converter можно по этой ссылке.

Компания Veeam Software на днях объявила о выпуске второй версии бесплатного продукта Veeam Business View 2.0. Мы уже писали об этом продукте - он представляет собой плагин для нескольких продуктов Veeam (например Veeam Backup and Replication и Veeam Monitor), с помощью которого можно разбить объекты виртуальной инфраструктуры не так, как нам показывает VMware, а своим собственным образом (например, на основе бизнес-единиц предприятия). Но при этом, это отдельный бесплатный продукт, развертываемый и настраиваемый отдельно.

Veeam Business View 2.0 расширяет возможности организации объектов виртуальной инфраструктуры. Теперь можно создавать представления хостов VMware ESX, кластеров HA/DRS и хранилищ (datastores). При этом создаваемые группы являются динамическими.

Например, вы определяете выражение для категоризации виртуальных машин по числу виртуальных процессоров - 1 vCPU, 2 vCPU, 4 vCPU. Затем Veeam Business View создает группы в соответствии с определенными правилами именования объектов и помещает туда представление виртуальных машин по группам для разных продуктов (например, Veeam Monitor или Reporter).

Еще пример - вы определяете граничные значения заполненности для своих хранилищ: если оно заполнено меньше чем на 70% - делаете группу ""Underutilized", если на 70-90% - группу "Normal", а если больше 90% - "Overutilized". И далее при построении отчетов в Veeam Reporter или мониторинге с помощью Veeam Monitor вы будете оперативно видеть определенные вами группы хранилищ по категориям. При этом все эти категории будут обновляться автоматически при добавлении, удалении или изменении объектов виртуальной инфраструктуры. То есть работает это в стиле "Set and Forget".

Кроме того, в Veeam Business View 2.0 появился расширенный Dashboard, на котором видно, сколько объектов виртуальной инфарструктуры VMware vSphere уже категоризованы. То есть это обзор вашей инфраструктуры с высоты "птичьего полета".

Ну и по-сути, что еще появилось в Veeam Business View 2.0:

• Новые правила определения категорий: не только по географическому принципу или по именам объектов, но и по их свойствам - например, процессоры хост-серверов в мегагерцах.
• Исключения для объектов при категоризации (например, вы не хотите чтобы тестовые машины появлялись в представлениях).
• Интеграция со сторонними приложениями, например, со службой каталога Microsoft Active Directory, куда можно отобразить изменения, сделанные в Veeam Business View 2.0.

Скачать аддон Veeam Business View 2.0 для своих продуктов Veeam можно по этой ссылке. Документация вот тут.

Ben Armstrong, занимающий позицию Virtualization Program Manager в компании Microsoft, опубликовал несколько статей о том, как работает распределение ресурсов процессора в платформе виртуализации Microsoft Hyper-V R2 (кстати, не так давно вышел RTM-билд SP1 для Windows Server 2008 R2).

Приводим краткую выжимку. В настройках виртуальной машины на сервере Hyper-V вы можете увидеть вот такие опции:

Virtual machine reserve

Эта настройка определяет процентную долю процессорных ресурсов хост-сервера, которые должны быть гарантированы виртуальной машине. Если хост на момент запуска виртуальной машины не может гарантировать эти ресусры - виртуальная машина не запустится. То есть вы можете запустить 5 машин с Virtual machine reserve в 20%, а 6-я уже не запустится. При этом неважно, используют ли эти 5 машин какие-либо ресурсы, или они вовсе простаивают.

Однако, данная настройка имеет значение только когда ощущается нехватка процессорных ресурсов. Если 4 из этих 5 машин используют по 4% процента CPU хост-сервера, а пятая хочет 70% - она их получит, но до того момента, пока остальным не потребуются ресурсы процессора. То есть, настройка Virtual machine reserve гарантирует, что машина будет иметь в своем распоряжении ресурсов не меньше, чем заданный процент ресурсов CPU - в условиях борьбы за ресурсы процессора между машинами хоста.

По умолчанию в качестве Virtual machine reserve стоит настройка 0. Это означает, что вы можете запускать виртуальных машин столько, сколько позволяют физически доступные ресурсы хост-сервера Hyper-V.

Virtual machine limit

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

Эта настройка активна всегда, что означает, что машина никогда не возьмет ресурсов больше чем Virtual machine limit, даже если свободных ресурсов очень много. Поэтому выставлять ее нужно в исключительных случаях, а для контроля ресурсов лучше использовать Virtual machine reserve. Кроме того, надо помнить, что Virtual machine limit применяется сразу к нескольким виртуальным CPU - поэтому, если приложение в виртуальной будет давать нагрузку только на один виртуальный процессор - он будет ограничен 50% доступных для него ресурсов, в то время как остальные будут простаивать.

CPU relative weight

Эта настройка позволяет выставить относительный вес виртуальных процессоров машины относительно других виртуальных машин. CPU relative weight - это просто число в диапазоне от 1 до 10000, которое определяет пропорциональный вес машины относительно других (по умолчанию выставлено 100 для всех). Если для одной из машин поставить значение 200 - то в случае нехватки процессорных ресурсов на хосте Hyper-V она получит в два раза больше ресурсов CPU, чем какая-либо из других. Обратите внимание - настройка начинает работать только в случае нехватки процессорных ресурсов на хосте и не раньше.

Смысл этой настройки - разделение виртуальных машин по категориям приоритета использования ресурсов в случае их нехватки (например, 300 - высокий приоритет, 200 - обычный, 100 - низкий). Так как это все относительные величины - имейте в виду, что здесь нет гарантий точного количества ресурсов CPU, получаемых машиной. И еще один момент - если в вашей виртуальной инфраструктуре Hyper-V работают несколько администраторов, то каждый из них может пользоваться своей классификацией весов. Например, у одного это 100, 200 и 300, а у другого - 500, 1000 и 2000. Если каждый из них для своего хоста установит эти значения, а потом за счет Live Migration какая-либо из машин динамически переместится на другой хост - распределение весов сильно изменится, что может повлиять на работу систем в условиях ограниченности ресурсов CPU хост-сервера.

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

Как вы знаете, в механизме высокой доступности VMware High Availability (HA) есть такая настройка как Isolation Responce, которая определяет, какое событие следует выполнить хосту VMware ESX / ESXi в случае наступления события изоляции для него в кластере (когда он не получает сигналов доступности - Heartbeats - от других хост-серверов).

• Leave powered on
• Power off
• Shutdown

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

• Если наиболее вероятно что хост ESX отвалится от общей сети, но сохранит коммуникацию с системой хранения, то лучше выставить Power off или Shutdown, чтобы он мог погасить виртуальную машину, а остальные хосты перезапустили бы его машину с общего хранилища после очистки локов на томе VMFS или NFS (вот кстати, что происходит при отваливании хранища).
• Если вы думаете, что наиболее вероятно, что выйдет из строя сеть сигналов доступности (например, в ней нет избыточности), а сеть виртуальных машин будет функционировать правильно (там несколько адаптеров) - ставьте Leave powered on.

Но есть еще один момент. Как вам известно, VMware HA тесно интегрирована с технологией VMware Fault Tolerance (непрерывная доступность ВМ, даже в случае выхода физического сервера из строя). Суть интеграции такова - если хост с основной виртуальной машиной выходит из строя, то резервный хост выводит работающую резервную ВМ на себе "из тени" (она становится основной), а VMware HA презапускает копию этой машины на одном из оставшихся хостов, которая становится резервной.

Так вот настройка Isolation Responce не применяется к машинам, защищенным с помощью Fault Tolearance. То есть, если хост VMware ESX с такой машиной становится изолированным, при настройке Power off или Shutdown он такую машину не гасит, а всегда оставляет включенной.

Рекомендация - иметь network redundancy для сети heartbeats. Не должен хост себя чувствовать изолированным, если он весь не сломался.

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

Новые возможности платформы VMware View 4.6:

• Security servers can now accommodate PCoIP connections - долгожданная возможность решения VMware View. Теперь роль Security Server включает компонент PCoIP Secure Gateway, который позволяет туннелировать (или проксировать, как вам нравится) PCoIP-трафик (раньше это было возможно только для трафика RDP). Компонент PCoIP Secure Gateway позволяет получить несколько преимуществ:
  • Трафик PCoIP может ходить по WAN-каналам в датацентр в рамках защищенного соединения для аутентифицировавшихся пользователей.
  • Теперь не требуется VPN-соединения с инфраструктурой датацентра, поскольку PCoIP-соединения идут не напрямую к хостам VMware ESX / ESXi, а могут идти через Security Server.
  • Роль Security server с поддержкой туннелирования PCoIP может быть установлена на Windows Server 2008 R2 с полной поддержкой 64-битной архитектуры.
• Enhanced USB device compatibility - VMware View 4.6 поддерживает перенаправление USB-устройств для синхронизации iPhone и iPad с виртуальными ПК. Этот релиз также включает улучшения для USB-сканнеров и имеет поддержку дополнительных USB-принтеров, которые можно использовать с тонкими клиентами. Для получения полного списка читайте Release Notes для View Client.
• Keyboard mapping improvements - исправлено множество багов и неудобств при использовании клавиатуры с виртуальными ПК. Для получения полного списка исправлений читайте Release Notes для View Client.
• New timeout setting for SSO users - это настройка для функциональности сквозной аутентификации в виртуальных ПК (single-sign-on, SSO). Новая настройка позволяет установить время, в течение которого возможность сквозной аутентификации остается валидной. То есть, если администратор установил время в 10 минут, а пользователь с помощью SSO залогинился на View Connection Server, то если он отойдет от компьютера после того как десктоп станет неактивным на 11 минут, то пользователю потребуется ввести свои учетные данные.
  
• VMware View 4.6 includes more than 160 bug fixes - Множественные исправления ошибок, которые приведены в списке Resolved Issues.
• Experimental support for Microsoft Windows 7 SP1 RC operating systems - экспериментальная поддержка ОС Microsoft Windows 7 SP1 (которая уже есть в релизе, а не в RC) в качестве клиентской ОС.

Скачать пробную версию VMware View 4.6 можно по этой ссылке.

UPD. Появилось видео с обзором удаленного доступа через VMware View Security Server по протоколу PCoIP:

Вы все уже вполне себе знаете, что есть на свете замечательный продукт StarWind Enterprise 5.6, который позволяет создавать отказоустойчивое хранилище для виртуальных машин VMware vSphere / Microsoft Hyper-V на базе технологии iSCSI, что не требует больших вложений и отлично подходит для небольших компаний и филиалов, где дорого и нецелесообразно покупать громоздкие Fibre Channel массивы (да и, вообще, FC вымирает потихоньку, особенно с приходом 10G Ethernet). О StarWind у нас есть специальный раздел, а также рекомендую почитать тут, тут и тут.

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

Во-вторых, в StarWind iSCSI Target есть возможность расширить уже существующее хранилище. Для этого нужно просто нажать правой кнопкой на файл образа виртуального диска и выбрать пункт "Extend Image Size":

Расширим наше хранилище с 10 до 15 ГБ:

Данная операция не повреждает хранилище с виртуальными машинами. После расширения образа виртуального диска с хранилищем VMFS, в VMware vSphere вам нужно будет сделать расширение тома. Выбираем Properties для нашего Datastore:

И нажимаем кнопку Increase:

Выбираем наш том:

И расширяем его:

Хранилище VMFS расширено на 5 ГБ:

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

Как вы знаете в последнем релизе платформы виртуализации VMware vSphere 4.1 было заявлено множество новых возможностей. Одна из них весьма важна с точки зрения производительности в части работы виртуальных машин с системой хранения. Эта технология называется VMware vSphere VAAI, то есть vStorage API for Array Integration.

Итак, что такое VMware vSphere VAAI. Это комплекс технологий компании VMware, разработанный в сотрудничестве с производителями дисковых массивов (потому и API), предназначенный для передачи некоторых операций виртуальных машин по работе с дисками на сторону массива. В этом случае хост-сервер виртуализации VMware ESX / ESXi при выполнении стандартных процедур в среде виртуализации при работе ВМ с дисковой подсистемой просто дает команду массиву (или массивам) сделать определенные действия, при этом сам хост не гонит через себя все те данные и команды, которые он раньше был вынужден прогонять. То есть, это - Hardware Offloading операций с СХД.

Ну а раз это аппаратно-зависимая вещь, то это означает, что сам массив должен в своем Firmware поддерживать vSphere VAAI (у которой еще бывает несколько видов - так называемые "примитивы"). Чтобы узнать поддерживает ли ваш хост VAAI нужно пойти в VMware Hardware Compatibility Guide и поискать свой дисковый массив в категории "Storage/SAN". Там все сделано несколько криво, но нужно искать в Supported Releases следующую сноску:

VAAI primitives "Full Copy", "Block Zeroing" and "Hardware Assisted Locking" are supported with vmw_vaaip_xxx plug-in

xxx - это идентификатор плагина от VMware

Ну и, конечно, ваш хост VMware ESX / ESXi должен быть версии 4.1 или выше. И помните, что на некоторых массивах VAAI по умолчанию выключена, поэтому вам нужно почитать документацию о том, как ее включить. Кроме того, функциональность VMware vSphere VAAI есть только в изданиях VMware vSphere Enterprise и Enterprise Plus (см. сравнение изданий).

Теперь, какие примитивы (то есть типовые операции с СХД) реализует VMware vSphere VAAI:

• Full Copy / Clone Blocks / XCOPY  – функция, позволяющая передать на сторону массива возможности копирования объектов виртуальной инфраструктуры без задействования операций четния-записи со стороны сервера VMware ESX 4.1. Эту функцию также называют Hardware Offloaded Copy и SAN Data Copy Offloading.
• Write Same / Zero Blocks – возможность обнуления больших массивов блоков на дисковых устройствах для быстрого создания дисков vmdk типа eager zero thick.
• Atomic Test and Set (ATS) –возможность защиты метаданных тома VMFS как кластерной файловой системы в ситуациях, когда большое количество хостов ESX имеют разделяемый доступ к одному хранилищу. Также эта функция называется Hardware Assisted Locking.

Давайте рассмотрим как эти компоненты VAAI работают и для чего они нужны.

Full Copy

Используя этот примитив, дисковый массив по команде VMware vSphere осуществляет копирование виртуальной машины (а самое главное для нас копирование диска VMDK) без участия сервера ESX / ESXi и его стека работы с подсистемой хранения (соответственно, не гоняется трафик и не дается нагрузка на CPU). В этом случае гипервизор рассказывает хранилищу, какие блоки занимает виртуальная машина, а оно уже делает все остальное по копированию блоков.

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

Еще один важный аспект применения - операция Storage vMotion, которая требует копирования виртуальных дисков машины.

С vSphere VAAI операции по копированию блоков данных хранилищ виртуальных машин занимают меньше времени (в некоторых случаях оно сокращается на 95%):

Ну а вот такие результаты нам выдает Storage vMotion:

Кроме того, данная технология интегрирована и с функциональностью "тонких" (thin) дисков как самой VMware, так и механизмом Thin Provisioning сторонних вендоров.

Write Same / Zero Blocks

За счет этой технологии сервер VMware ESX / ESXi может дать команду хранилищу обнулить блоки виртуальных дисков типа Eager zeroed thick (см. типы дисков). Эти диски являются самыми безопасными (блоки чистятся при создании) и самыми производительными (при обращении к блоку его не надо обнулять и тратить ресурсы), но занимали очень много времени на их создание. Теперь с техникой VAAI этот процесс сильно ускоряется, что позволяет использовать диски eagerzeroedthick чаще (например, для машин с включенной Fault Tolerance). Напомню, что сейчас по умолчанию в VMware vSphere создаются диски типа Zeroed thick disks.

Теперь одинаковые команды ввода-вывода на сторадж от сервера ESX / ESXi дедуплицируются, а массиву дается команда на повторение одинаковых команд для разных блоков. На эту тему есть отдельное видео:

Atomic Test and Set (ATS) или Hardware Assisted Locking

За счет этой техники vSphere VAAI существенно уменьшается число операций с хранилищем, связанных с блокировкой LUN на системе хранения. Как вы знаете, при работае виртуальных машин возникают конфликты SCSI Reservations, связанные с тем, что некоторые операции вызывают блокировку всего LUN для обновления метаданных тома VMFS. Операций этих много: запуск виртуальной машины (обновляется lock и создаются файлы), развертывание новой ВМ, создание снапшота, миграция vMotion и т.п.

Нехорошо также, что при использовании тонких дисков (например для связанных клонов VMware View) также происходит блокировка LUN при выделении нового блока растущему диску (надо обновлять метаданные - см. тут). Это, прежде всего, приводит к тому, что возникает ограничение на количество размещаемых на LUN виртуальных машин, чтобы конфликтов SCSI Reservations не было слишком много.

Теперь же, за счет VAAI, эти операции передаются на сторону дискового массива, который при необходимости обновить метаданные тома не блокирует весь LUN, а лочит только секторы метаданных, которые требуется обновить. Все это делается массивом безопасно и надежно. Отсюда вытекает уменьшение числа конфликтов SCSI Reservations и ,как следствие, лучшая производительность и увеличения числа ВМ на LUN.

Ограничения VMware vSphere VAAI

Недавно мы писали про Data Mover'ы - это компоненты VMware ESX / ESXi, отвечающие за работу хост-сервера с хранилищами при копировании данных. Поддержкой VAAI заведует компонент fs3dm – hardware offload. Он пока еще молодой, поэтому не поддерживает некоторых сценариев использования. Соответственно все или некоторые техники VAAI у вас не будут работать в следующих случаях:

• Исходный и целевой тома VMFST имеют разные размеры блоков
• Исходный файл лежит на том RDM, а целевое хранилище - это не том RDM 
• Исходный тип диска VMDK - это eagerzeroedthick, а целевой - thin
• Исходный или целевой тип диска VMDK VMDK - один из типов sparse или hosted (не платформа vSphere)
• Исходная виртуальная машина имеет снапшот 
• Блоки хранилища, где лежит виртуальная машина не выровнены (по умолчанию vSphere Client выравнивает блоки автоматически)

Как включить VMware vSphere VAAI

Как уже было сказано выше, со стороны хранилищ VAAI может быть выключена и нужно почитать документацию на СХД. На хостах ESX / ESXi по умолчанию VAAI включена. Проверить это можно, перейдя в Configuration > Advanced Settings и увидев следующие параметры, напротив которых стоят единицы:

• DataMover/HardwareAcceleratedMove (это возможности Full Copy)
• DataMover/HardwareAcceleratedInit (это Zero Block)
• VMFS3/HardwareAcceleratedLocking (это ATS)

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

# esxcfg-advcfg -g /DataMover/HardwareAcceleratedMove
# esxcfg-advcfg -g /DataMover/HardwareAcceleratedInit
# esxcfg-advcfg -g /VMFS3/HardwareAcceleratedLocking

Если ваше хранилище не поддерживает VAAI - ничего страшного, хост ESX / ESXi будет работать софтовыми дедовскими методами.

Как проверить, работает ли vSphere VAAI?

Очень просто, откройте категорию Storage на вкладке Configuration в vSphere Client и посмотрите в последний столбик.

Статус Unknown означает, что хост еще не обращался к операциям, которые поддерживаются VAAI (то есть, это дефолтный статус). Если вы сделаете какую-нибудь операцию с VAAI (например, Copy/Paste виртуального диска больше 4 МБ), то VAAI попробует отработать. Если он отработает успешно - выставится статус Supported, ну а если нет - то Not Supported.

Опросить стораджи можно также из командной строки:

# esxcfg-scsidevs -l | egrep "Display Name:|VAAI Status:"

Вывод будет похожим на это:

Display Name: Local VMware Disk (mpx.vmhba2:C0:T0:L0)
VAAI Status: unsupported
Display Name: Local USB CD-ROM (mpx.vmhba32:C0:T0:L0)
VAAI Status: unknown
Display Name: Local TEAC CD-ROM (mpx.vmhba3:C0:T0:L0)
VAAI Status: unknown
Display Name: DGC Fibre Channel Disk (naa.6006016030801c00f8506073d0d7de11)
VAAI Status: unknown
Display Name: DGC Fibre Channel Disk (naa.6006016030801c00f9506073d0d7de11)
VAAI Status: unknown

Дополнительная информация о vSphere VAAI

Обзорное видео:

Демо от EMC:

Демо от HP:

Демо от NetApp:

Документы:

vStorage APIs for Array Integration FAQ

What's New in VMware vSphere 4.1 — Storage

Уважаемые коллеги, хочу Вам сообщить, что в организационной структуре VMware Россия и страны СНГ произошли значительные изменения. Во-первых, некоторое время назад пост руководителя группы системных инженеров покинул Дмитрий Тихович (который, помимо всего прочего, поддерживал также официальный блог VMware Russia - http://www.vmware-blog.ru/). Теперь Дима работает в компании Citrix (см. его профиль в LinkedIn) в качестве PAM'а (Partner Account Manager).

Кроме того, вчера стало известно, что пост директора VMware Russia/CIS покинул Антон Антич, работавший в VMware более четырех лет (там же он был директором по партнерам и первым человеком, который пришел в российское представительство VMware). Очевидно, что данные перестановки связаны с коренными изменениями в самой компании VMware на уровне высшего руководства (например).

Что Дмитрий, что Антон - очень приятные и умные люди, с которыми было приятно работать по бизнесу VMware, и которые, наверняка, не оставят отрасль виртуализации в своей дальнейшей деятельности. Желаю вам успеха, коллеги!

Update. Из российского представительства также ушел Виталий Суховский, соратник Антона, отвечавший за продажи VMware в России и СНГ.

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

С Праздником!

Как мы уже писали, в VMware vSphere 4.1 появилась технолония Storage IO Control (SIOC, подробности здесь), которая позволяет настраивать приоритеты доступа виртуальных машин к хранилищам не в рамках одного хоста VMware ESX / ESXi, а в рамках всего кластера.

Первый документ "Storage I/O Control Technical Overview and Considerations for Deployment" рассказывает нам о том, как именно работает данная технология:

как ее нужно настраивать:

и какие рекомендации по настройкам Latency можно использовать при борьбе виртуальных машин за ресурсы ввода-вывода, в зависимости от типов хранилищ:

Второй документ называется "Managing Performance Variance of Applications Using Storage I/O Control". Он содержит результаты тестирования SIOC в условиях, когда нужно выделить виртуальную машину как критичную с точки зрения ввода-вывода (отмечена звездочкой). Взяли требовательную к нагрузкам задачу (DVD Store).

Измерили эталонную производительность когда работает только критичная ВМ (левый столбик - принят за единицу, SIOC Off), измерили среднуюю производительность (когда все машины работают параллельно и у каждой Shares установлено в 1000, SIOC Off), а потом стали варьировать Shares для критичной виртуальной машины (при включении SIOC On) смотря на то, как растет ее производительность в рамках кластера:

Видим, что SIOC при распределении приоритета ввода-вывода между хостами работает. В этом же документе есть еще тесты, посмотрите.

Напоминаю, что технология VMware Storage IO Control есть только в издании VMware vSphere Enterprise Plus.

Как вы знаете, для виртуальных хранилищ (datastores) в VMware vSphere есть возможность задавать разные размеры блоков тома VMFS. Также вы, вероятно, знаете, что операция Storage vMotion позволяет перемещать виртуальную машину между хранилищами, превращая ее виртуальный диск из толстого (thick) в тонкий (thin).

Но чтобы это результирующий тонкий диск после Storage vMotion занимал на целевом хранилище только столько пространства, сколько используется внутри гостевой ОС (а не весь заданный при создании), нужно предварительно почистить блоки с помощью, например, утилиты sdelete.

Duncan Epping, известный технический эксперт VMware, обратил внимание на проблему, когда пользователь делает очистку блоков, затем Storage vMotion, а уменьшения диска не происходит. Почему так?

Очень просто, в составе VMware ESX / ESXi есть три типа datamover'ов ("перемещателей"):

• fsdm – это старый datamover, который представляет собой базовую версию компонента. Он работает сквозь все уровни, обозначенные на картинке. Зато он, как всегда, универсален.
• fs3dm – этот datamover появился в vSphere 4.0 и имеет множество оптимизаций. И вот тут данные уже не идут через стек работы с виртуальной машиной. То есть он работает быстрее.
• fs3dm – hardware offload – Этот компонент появился для поддержки технологии VAAI, которая позволяет вынести операции по работе с хранилищами виртуальных машин на сторону массива (hardware offload). Он, естественно, самый быстрый и не создает нагрузку на хост VMware ESX / ESXi.

Так вот основная мысль такова. Когда вы делаете миграцию Storage vMotion виртуальной машины между хранилищами с разными размерами блоков используется старый datamover fsdm, а когда с одинаковыми, то новый fs3dm (в программном или аппаратном варианте). Последний работает быстрее, но не умеет вычищать нулевые блоки на целевом хранилище у виртуального диска VMDK.

А вот старый fsdm, ввиду своей универсальности, это делать умеет. То есть, если нужно вычистить нулевые блоки не перемещайте ВМ между хранилищами с одинаковыми размерами блоков. Так-то вот.

Антон Гостев - менеджер продукта Veeam Backup and Replication 5 (а сейчас еще и директор по Product Management). Мне понравилось, Антон :) Кто придумал, признавайся?

Вы уже все знаете про компанию StarWind Software и ее замечательный продукт StarWind Enterprise 5.6 для создания отказоустойчивых хранилищ для виртуальных машин VMware vSphere и Hyper-V. О нем написано в нашем разделе, но для начала можно почитать тут, тут и тут.

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

Есть еще одна деталь в плане оптимизации быстродействия. Раньше сихронизация между узлами отказоустойчивого хранилища StarWind проходила медленнее, чем в версии 5.6. Это связано с тем, что раньше для всех iSCSI таргетов операции по синхронизации ставились в общую очередь, что вызывало непоследовательную запись данных на дисковые устройства (данные писались в разнобой). Теперь все сделано грамотно - каждый таргет синхронизирует свои данные в своем последовательном потоке, потом приступает к снихронизации второй. Удобно и быстро.

Далее. Тестируйте дедупликацию, пишите о результатах. Версия StarWind Enterprise 5.7 уже не за горами. В недрах девелоперских копей зреют идеи по созданию QoS-приоритетов для канала синхронизации и канала доступа хостов к хранилищам и много чего еще.

Теперь. Все быстренько пошли на сайт Network Computing Awards 2011, выбрали "Vote Now" в левом меню и проголосовали в категории "Storage Product of the year" за StarWind Enterprise. Надо болеть за наших ребят.

Как вы знаете, начиная с VMware vSphere 4.1, компания VMware включила с свою платформу виртуализации API для обеспечения безопасности виртуальных сред под названием EPSec (End Point Security). Совместно с технологией VMware VMsafe этот API должен позволить по-новому обеспечивать антивирусную защиту в виртуальных машинах на VMware ESX / ESXi (см. нашу запись о Trend Micro и Reflex VMC).

Сейчас традиционные антивирусы работают в виртуальных машинах, создавая нагрузку на них. Для виртуальных серверов это не так важно, поскольку их плотность на хост-машинах достаточно невелика. Да и потом, современнные антивирусы типа Symantec или Trend Micro имеют имеют функции случайного запуска, чтобы равномерно распределить нагрузку. Но для виртуальных ПК (например, на базе VMware View) коэффициент консолидации может достигать 50 и даже 100 к одному - и вот тут нужно искать пути оптимизации использования аппаратных ресурсов.

И здесь на помощь приходит VMware VMsafe и EPSec API:

Суть технологии такова - зачем использовать отдельный антивирус в каждой виртуальной машине, если можно сделать сервисную виртуальную машину, содержащую в себе средства сканирования активности виртуальных машин на уровне гипервизора, и тратить ресурсы только на нее. Естественно этот виртуальный модуль (Virtual Appliance) имеет все необходимое для поддержки перемещаемых средствами vMotion/DRS машин.

У компании Trend Micro уже есть продукт DeepSecurity 7.5, который поддерживает эту интересную технологию (Symantec и McAfee тоже скоро подтянутся). VMsafe-net API отвечает за единый фаервол, а EPsec API - за антивирусную деятельность.

Недавно Tolly group сделала его бенчмаркинг, показатели которого были впечатляющими: использование данной технологии позволяет сократить потребление ресурсов от 1.7 до 8.5 раза!

Кстати реализует упомянутые технологии продукт vShield Endpoint, входящий в состав VMware View Premier, о котором мы уже писали:

Посмотрите также вот эту презентацию. И да, вот эту.

Часто разговаривая с заказчиками и пользователями платформ виртуализации от VMware, я вижу, что у многих из них весьма широко применяются снапшоты (snapshots), в том числе для целей "резервного копирования". Эти снапшоты живут долго, их файлы разрастаются и поростают плесенью. Потом инфраструктура начинает тормозить, а пользователи не знают почему. И как это не казалось бы странным - удаление всех снапшотов у всех виртуальных машин решает их проблемы, с которыми они уже свыклись.

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

Начнем с того, когда снапшоты могут помочь (я имею в виду, конечно, руками делаемые снапшоты, а не автоматические, которые делает, например, Veeam Backup).  Снапшоты в VMware vSphere оказываются полезны в очень ограниченных условиях (например, для проверки корректности работы обновления приложения или патча операционной системы). То есть эта та точка сохранения состояния виртуальной машины, к которой можно будет вернуться через небольшой промежуток времени. Ни в коем случае нельзя рассматривать снапшоты как альтернативу резервному копированию основных производственных систем, в силу множества проблем, о которых пойдет речь ниже.

Что плохого в снапшотах виртуальных машин на VMware ESX:

1. Снапшоты неконтролируемо растут (блоками по 16 МБ). Помимо базового диска ВМ фиксированной емкости вы имеете еще один файл отличий виртуального диска, который растет как ему вздумается (предел роста одного снапшота - размер базового диска). Особенно быстро растут снапшоты для ВМ с приложениями с большим количеством транзакций (например, почтовый сервер или сервер СУБД). Со снапшотами вы не имеете контроля над заполненностью хранилищ.

2. Большое количество снапшотов (особенно цепочки, в которых может быть до 32 штук) вызывает тормоза виртуальной машины и хост-сервера ESX (в основном замедляется работа с хранилищем). Проверено на практике. Даже VMware пишет так: "An excessive number of snapshots in a chain or snapshots large in size may cause decreased virtual machine and host performance". В качестве примера можно привести тот факт, что при аллокации блоков снапшота происходит блокировка LUN (в этом режиме он доступен только одному хосту, остальные ждут). Когда снапшот делается - машина подвисает из-за сброса памяти на диск.

3. Снапшоты не поддерживают многие технологии VMware, созданные для автоматизации датацентров. К ним относятся VMware Fault Tolerance, Storage VMotion и другие. Когда одни машинки в чем-то участвуют, а другие не участвуют - это нехорошо в рамках концепции динамической инфраструктуры.

4. Снапшоты вызывают специфические проблемы при операциях с ВМ. Например, расширение диска виртуальной машины со снапшотом приводит к потере данных и непонятками, что дальше с такой машиной делать. Сто раз уже пользователи влипали (вот как вытянуть себя за волосы). Интересно также восстановить из снапшота машину с IP-адресом, который на данный момент уже используется в сети.

5. Со снапшотами бывают баги, а бывает, что они просто "by design" тупят.

6. У снапшотов было плохое поведение при их слиянии, но сейчас исправилось.

Рекомендации по работе со снапшотами:

1. Контролируйте наличие снапшотов у виртуальных машин и их размеры, своевременно удаляйте их совместно с владельцами систем. Делать это можно, например, с помощью RVTools.

2. Не храните снапшоты больше 24-72 часов. Этого времени достаточно, чтобы оттестировать обновление ПО или патч ОС (ну и, конечно, сделать бэкап).

3. На сервере VMware vCenter можно настроить алармы на снапшоты виртуальных машин. Сделайте это. Дрючьте пользователей за необоснованные снапшоты.

4. Не позволяйте делать больше 2-3 снапшотов для виртуальной машины в принципе, если это делается в производственной среде. На своих выделенных для тестирования ресурсах (изолированных) пусть разработчики делают что хотят.

5. Если вы используете ПО для резервного копирования через снапшоты ВМ (например, Veeam Backup), помните, что бывает некоторые невидимые в vSphere Client снапшоты (Helpers) остаются на хранилище. Поглядывайте за машинами из командной строки.

6. Почитайте: KB 1009402, KB 1025279, KB 1015180.

Компания VMware на прошедшей конференции VMware Partner Exchange 2011 (PEX) объяивла о некоторых подробностях касательно следующей версии платформы виртуализации VMware vSphere 5.0.

Сначала новые возможности vSphere 5.0:

• Dynamic Resource Scheduling (DRS) for Storage - эта давно ожидаемая функция платформы виртуализации, которая позволит автоматически выравнивать нагрузку на системы хранения путем динамического перемещения работающих виртуальных машин между хранилищами (сейчас это можно сделать вручную за счет Storage VMotion). Пользователи смогут определять группы Datastor'ов (они зовутся Storage Pods), которые будут использоваться для балансировки по хранилищам на базе их заполненности. Предполагается, что это повысит автоматизацию датацентров. О балансировке нагрузки по производительности хранилищ пока ничего не говорится.
• Host-based replication for Site Recovery Manager - возможность репликации виртуальных машин на уровне хостов а не SAN-хранилищ (как делается сейчас). То есть, поддержка технологии репликации со стороны СХД будет не нужна, репликация будет работать в асинхронном режиме со стороны хост-серверов. По-сути, это аналог репликации виртуальных машин в продукте Veeam Backup and Replication 5, которая сейчас активно используется в производственной среде многими компаниями для защиты данных виртуальных машин и наиболее быстрого восстановления работоспособности сервисов (показатели RTO).
• Network I/O control for Virtual Machines - эта возможность будет позволять резервировать часть канала для приоритетных задач в кластере HA/DRS на случай его перегрузки. Актуально это будет для сетей 10G, где канал шире, а вот физических адаптеров значительно меньше.

Выход VMware vSphere 5.0 запланирован на второе полугодие 2011 года. Но скорее всего пятая версия платформы выйдет до VMworld 2011, который начнется 29 августа.

Также на партнерской сессии были озвучены несколько вещей на будущее (2012 год, после vSphere 5) - фреймворк SLA, который будет позволять пользователям внутренних облаков на базе VMware vSphere определять показатели качества обслуживания для своих приложений ("policy engine"). Также обсуждалась доступность в 2012 году стандартной функциональности long-distance vMotion, которая будет позволять перемещать работающие виртуальные машины на большие расстояния (вместе с Cisco VMware делала эксперименты по перемещению на сотни миль). Сейчас Long Distance vMotion уже поддерживается для некоторых сценариев.

Это позволит воплотить в жизнь концепции Follow the Sun и Follow the Moon для больших корпораций.

P.S. Ну и не забываем о неофициальном списке новых возможностей VMware vSphere 5.0:

• Обновление железа виртуальной машины до версии 8
• Поддержка каждой виртуальной машиной до 32 vCPU
• Поддержка каждой виртуальной машиной до 1 TB ОЗУ
• Поддержка USB 3.0
• Поддержка подключения USB из клиента
• Поддержка Mac OS Server
• VCenter на Linux в виде VA

И да, в vSphere 5.0 будет уже только ESXi без аналога ESX.

Еще в пятницу компания VMware выпустила очередное обновление Update 1 своей платформы виртуализации VMware vSphere 4.1.

Мы уже писали о будущих новых возможностях Update 1, вот теперь их полный список:

Улучшения и новые возможности VMware ESX/ESXi 4.1 Update 1

• Поддержка до 160 логических процессоров хост-сервера
  • Платформа подготовлена к новому процессору Westmere-EX
• Включены дополнительные драйвера устройств:
  • дисковые устройства 3ware и Neterion
• Включена технология Intel Trusted Execution Technology (только для ESXi). Это поддержка модулей Trusted Platform Module (TPM) для доверенной загрузки хост-серверов (поддерживается также коммуникация с vCenter). Почитайте вот эту статью о TPM.
  • Более подробная информация в KB 1033811 
• Поддержка новых гостевых ОС
  • Добавлены: RHEL 6, RHEL 5.6, SLES 11 SP1 for VMware, Ubuntu 10.10 и Solaris 10 Update 9
• Улучшенная производительность для виртуальных машин, реализующих нагрузки баз данных и терминальные службы. Быстрее теперь работа с дисковой подсистемой и эффективнее расходуется CPU (непонятно, включено ли это в данный релиз).
• Исправления безопасности и различные багофиксы
  • Полный список - в release notes

Улучшения и новые возможности VMware vCenter 4.1 Update 1

• Поддержка кастомизации (через Sysprep) новых ОС:
  • Windows 7 SP1, Windows Server 2008 R2 SP1, RHEL 6, RHEL5.5
• Поддержка новых СУБД для vCenter Server:
  • Microsoft SQL 2008 R2, Microsoft SQL 2005 SP3, Oracle 11g R2, IBM DB2 9.7.2
• Исправления и различные багофиксы
  • Полный список - в release notes

Улучшения и новые возможности VMware vCenter Update Manager 4.1 Update 1

• VMware Update Manager получил новый интерфейс для постконфигурации продукта, включая сам VUM и утилиту VMware Update Manager Download Service (для скачивания обновлений отдельно от VC и VUM). Теперь из GIU можно сбросить пароль для соединения с БД, сконфигурировать настройки Proxy и поменять SSL-сертификаты.
• Исправления безопасности и различные багофиксы

Улучшения и новые возможности VMware vCenter Orchestrator 4.1 Update 1

• Исправления безопасности и различные багофиксы

Скачать VMware vSphere 4.1 Update 1 можно по этой ссылке. Помните, что перед обновлением хост-серверов ESX / ESXi нужно сначала обновить VMware vCenter. И да, помните о багах обновления на Update 1, которые у VMware стали доброй традицией.

Если вы используете пулы типа Linked Clone (на основе базового образа) в решении для виртуализации ПК VMware View 4.5, то знаете, что есть такая операция "Rebalance", которая перераспределяет виртуальные ПК пула по хранилищам VMFS / NFS. Но многие удивятся, как работает эта функция. Например, у вас есть несколько хранилищ различной емкости, и вы делаете Rebalance десктопов.

Получаете вот такую картину:

Слева - то, что вы ожидаете увидеть в результате балансировки, а справа - то, что получается на самом деле. В чем причина?

Все дело в том, что VMware View 4.5 использует для перемещения машин на хранилище параметр "weighted available space". У какого из хранилищ он больше - туда виртуальные машины и переезжают. Что это за параметр:

weighted_available_space = datastore_capacity * overcommit_factor – virtual_usage

Здесь:

datastore_capacity - это общая емкость хранилища VMFS / NFS.

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

overcommit_factor - это настройка для Storage Overcommit, которую вы задавали для Datastore, когда выбирали, какие из них следует использовать для пулов Linked Clone. Там были такие значения:

• None - хранилище не является overcommitted.
• Default - это коэффициент 4 от размера хранилища
• Moderate - это коэффициент 7 от размера хранилища
• Aggressive - это коэффициент 15 от размера хранилища.

Теперь переходим к примеру и формуле. Есть у нас вот такая картинка (см. настройки overcommitment):

Счтиаем weighted available space:

• DS1 - 1000GB (Datastore Size) * 4 (Conservative Overcommitment) – 0 (No VM's deployed) = 4000
• DS2 - 1000GB (Datastore Size) * 4 (Conservative Overcommitment) – ((20GB + 130MB)x5) (5 VM's already deployed) = 3865
• DS3 - 1000GB (Datastore Size) * 7 (Moderate Overcommitment) – ((20GB + 130MB)x5) (5 VM's already deployed) = 6865

Теперь вот вам задачка - что будет в результате Rebalance виртуальных ПК?

По-сути, правило таково: если у вас все хранилища с одинаковым уровнем Storage Overcommitment и одинакового размера, то виртуальные машины будут перемещены на другие хранилища, если там больше свободного места, чем свободного места на текущем хранилище. Ну а если разного размера и одинакового уровня Overcommitment - то ожидайте того, что машины останутся на больших хранилищах. Так-то вот.

И да, никогда не далейте Storage VMotion для виртуальных машин VMware View 4.5 вручную - это не поддерживается со стороны VMware.

Материал написан по мотивам заметки "VMware View 4.5: Rebalance" от Simon Long.

Вчера и сегодня пользователи решения для виртуализации корпоративных ПК предприятия VMware View 4.5 обнаружили неприятную особенность, когда попытались с помощью VMware View Client соединиться с сервером View Connection Server - клиент не коннектится.

Это произошло по причине того, что на Windows 7 вы накатили какой-либо из вот этих патчей: 2482017 или 2467023. Выходов два:

• Не устанавливать эти патчи или откатить их для дальнейшего использования VMware View Client
• Установить обновление VMware View Client, которое можно скачать здесь (просто удалите предыдущую версию клиента через Add/Remove Programs и поставьте эту).

Подробнее в KB 1034262.

Как мы уже писали, в декабре прошлого года вышел релиз-кандидат продукта Veeam nworks Smart Plug-in 5.6, который позволяет организовать ээфективный мониторинг и решение проблем для виртуальной инфраструктуры VMware vSphere. Многие компании уже приобрели решения Microsoft System Center Operations Manager (SCOM) и HP Operations Manager (HP OM), необходимые для мониторинга физической инфраструктуры, так вот Veeam с помощью семейства продуктов nworks позволяет прикрутить к этим продуктам еще и мониторинг инфраструктуры виртуализации VMware. На днях параллельно вышли новые версии обоих продуктов - Veeam nworks Smart Plug-In 5.6 и Veeam nworks Management Pack 5.6.

Veeam nworks Smart Plug-In 5.6 для HP OM теперь имеет следующие новые возможности:

• Поддержка HP Operations Manager для Linux (OML). Теперь портфель nworks включает в себя поддержку всех версий HP OM - для Windows, Unix и Linux.
• Обновленный Enterprise Manager, доступный из консоли Ops Manager, который можно прикрутить как плагин к vSphere Client.
• Ограничение очереди событий vCenter. Это позволя определить число событий vCenter, которые коллектор может получать в течении 30 секунд.
• Новые метрики и события, отслеживания некоторых из которых вы больше нигде не найдете:
  • Мониторинг компрессии памяти VMware vSphere (техника Memory Compression в VMware ESX 4.1)
  • Отслеживание задержек обращения к хранилищам (Disk queue latency) - для определения узких мест в дисковой подсистеме хранения виртуальных машин на томах VMFS
  • Производительность сетевого взаимодействия
  • Мониторинг длительности хранения снапшотов (snapshots) - для нотификации администраторов о потенциальных проблемах
  • Сигнал с датчика вентилятора
  • Новые события, появившиеся в vSphere 4.

• Message Forwarding - теперь сообщения любых типов могут быть разбиты по группам и помещены в соответствующие узлы консоли Operations Manager.
• Улучшенная производительность коллектора и самодиагностики.

Veeam nworks Management Pack 5.6 для Microsoft SCOM теперь имеет следующие новые возможности:

• Новые метрики VMware vSphere 4.1:
  • Memory compression (см. выше)
  • Disk queue latency (см. выше)
  • Потеря пакетов в сетевом взаимодействии
  • Мониторинг длительности хранения снапшотов (см. выше)
  • Новые события vSphere 4
• Улучшенная масштабируемость:
  • Улучшенная производительность при обнаружении хостов с большой плотностью виртуальных машин (например, при VDI-инсталляции в рамках VMware View 4.5)
  • Улучшенная производительность мониторинга состояния оборудования
  • Интеллектуальная группировка виртуальных машин, позволяющая не запутаться в окружениях, где машины постоянно перемещаются с хоста на хост (например, DRS/VMotion)
• Ограничение очереди событий vCenter. Это позволя определить число событий vCenter, которые коллектор может получать в течении 30 секунд.
• Сигнал с датчика вентилятора

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

Скачать Veeam nworks Management Pack 5.6 можно тут, а Veeam nworks Smart Plug-In 5.6 тут.

Кстати, еще одна тема. Недавно компания Veeam получила аж 4 награды от Virtualization Review и SearchServerVirtualization.com:

• Veeam Backup & Replication Gold Award (Products of the Year 2010)
• Veeam One Solution Gold Award (Products of the Year 2010)
• Reader's Choice Award (Veeam Backup and Replication 5)
• Merit Award (Veeam One)

Так что продукты хорошие, покупайте.

Как вы знаете, у компании VMware есть несколько инициатив в сфере облачных вычислений - это семейство технологий vCloud, продукт vCloud Director для создания субоблаков и управления ими, надстройка vCloud Request Manager (портал самообслуживания пользователей облачных виртуальных машин + управление жизненным циклом ВМ) и ветка vCloud Express для создания облачной виртуальной инфраструктуры на площадках провайдеров, предоставляющих в аренду виртуальные машины. Сюда нужно присовокупить еще продукт VMware vCenter Chargeback, который обсчитывает все аспекты затрат на виртуальную инфраструктуру, и множество других продуктов семейства vCenter. Плюс вспомогательные продукты семейства vShield.

Теперь вот появилась новая инициатива - VMware vCloud Connector. По-сути, это механизм соединения облачных инфраструктрур на базе VMware vSphere (но не только).

На практике это будет означать вот что: VMware vCloud Connector - это будет абсолютно бесплатный плагин к VMware vCenter, с помощью которого пользователь своей частной виртуальной инфраструктуры может перемещать свои виртуальные машины в облако, т.е. к провайдеру, который дает виртуальную инфраструктуру в аренду. Происходит это, в том числе, с использованием VMware vCloud API.

При этом виртуальные машины по-прежнему остаются под контролем своего vCenter в vSphere Client:

Кроме того, в составе VMware vCloud Connector будет идти виртуальный модуль (Virtual Appliance), который вы импортируете в свою инфраструктуру VMware vSphere.

Поначалу VMware vCloud Connector, который выйдет уже в конце этого квартала будет поддерживать только двух провайдеров US Bluelock и European Colt, но потом эта инициатива дойдет и до нас.

Почему такая возможность будет полезна вам? Да потому, что у провайдеров облако, а у вас не облако. Облако - это не просто установленная vSphere, но и много чего еще. Например:

• Контроль и мониторинг ресурсов
• Классы сервиса для групп приложений и отдельных клиентов в целом (SLA) с ответственностью за простой
• Контроль жизненного цикла виртуальных машин
• Прозрачная система расчета стоимости ресурсов
• Централизованное обеспечение безопасности на уровне датацентра
• и т.д. и т.п.

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

Если вы читаете virtualization.info (откуда кстати в Gartner ушел Alessandro Perilli), то помните, что какое-то время назад в сети появились некоторые детали о гипервизоре Hyper-V 3.0. Сейчас вот появилась новая информация.

Итак, parent partition в грядущей Windows 8 (или как там ее еще назовут) будет выполнять не полноценную копию операционной системы, а ее мини-версию, которая сейчас идет под рабочим названием MinWin.

Эта ветка Windows, говорят, существует еще со времен Windows Vista и включает в себя ядро ОС, Hardware Abstraction Layer (HAL), комоненты работы с файловой системой и средства работы в сети.

Само собой, эта Windows меньше, чем Windows Server Core edition. Недавно Microsoft зарегистрировала патент на технологию Windows Direct Experience, которая будет позволять запускать некоторые приложения (например, Windows Media Center) в режиме "песочницы" (sandbox), т.е. по-сути в виртуальных машинах, как следует из картинки:

Родительским разделом по имеющейся информации будет рулить Hyper-V 3.0 (или как там его еще назовут), который, по-сути, будет играть роль клиентского гипервизора (который в данный момент есть только у Citrix - XenClient). Также можно будет грузить компьютер только в режиме одной из виртуальных машин. Кроме того, ходят слухи, что все это каким-то образом будет интегрировано с Microsoft App-V, средством виртуализации и доставки приложений конечным пользователям, а также механизмом MED-V.

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

Предлагают и вовсе фантастические вещи: так как гипервизор Hyper-V 3.0 может управлять не только ОС Windows, то компьютер, оснащенный Windows 8 (или как ее там) сможет выполнять и операционную систему Linux в режиме клиентского гипервизора, а пользователь, например, сможет запускать в этом линуксе свои приложения, которых (и такое бывает) нет в Windows. Это же относится и к приложениям, которые работают под устаревшими ОС XP или Vista.

Получается, что мы получим не совсем Windows а уже метаоперационную систему на домашних компьютерах. Это, по крайней мере, очень интересно. Ждем новых подробностей. Дополнительно можно почитать тут.

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

Мы уже писали о новых возможностях StarWind Enterprise 5.6, которые будут доступны для пользователей в самое ближайшее время с выходом новой версии (ожидается к 10 февраля, не забываем кстати про раздел о StarWind на нашем сайте). Но ребята подсуетились и успели добавить еще одну важную и нужную в будущем возможность - блочную дедупликацию виртуальных дисков для хранилищ iSCSI с виртуальными машинами:

Как вы видите, пока данная функциональность отмечена звездочкой, что значит, что возможность дедупликации находится в экспериментальном режиме, и для производственных данных использовать ее не надо. Но для тестирования - вполне. Дедупликация в StarWind iSCSI Target позволит снизить требуемый объем хранилищ для виртуальных машин (а особенно для однотипных нагрузок), что снизит общие затраты на содержание виртуальной инфраструктуры.

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

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

Скачать StarWind Enterprise 5.6 можно будет где-то в районе 10 февраля.

Ricky El-Qasem, автор сайта VirtualizePlanet.com, выпустил интересную бесплатную утилиту для VMware vSphere - vDisk Informer. Эта утилита решает две важные проблемы:

1. Поиск виртуальных машин, дисковое пространство которых используется неэффективно, попросту говоря, много свободного места:

При сканировании виртуальной инфраструктуры можно задавать объем в ГБ или МБ, начиная с которого будут отображаться соответствующие иконки, говорящие нам о том, что можно уменьшить диск виртуальной машины.

2. Вторая функция нужнее - она позволяет определить виртуальные машины, у которых наблюдается проблема некорректного выравнивания блоков дисков VMDK (например, после P2V-миграции). Можно также задавать параметры смещения - 32K или 64K (в зависимости от SAN-массива, где лежат ваши ВМ):

Скачать vDisk Informer можно по этой ссылке. Видео о возможностях здесь.

Как вы знаете, в мире виртуализации есть так называемые виртуальные модули (Virtual Appliances), которые позволяют распространять программное обеспечение в виртуальных машинах, готовых к развертыванию в инфраструктуре клиента. То есть, Virtual Appliance просто импортируется через клиент для управления платформой виртуализации (например, vSphere Client или XenClient), а само приложение работает в недрах этой виртуальной машины, предоставляя свои сервисы по сети, а управление через веб-фронтэнд.

Virtual Appliances распространяют как сами вендоры (например, VMware vSphere Management Assistant или  Citrix XenServer Virtual Machine Performance Utility), так и независимые разработчики программного обеспечения (их продукты, например, можно найти на Virtual Appliance Marketplace).

Есть такая контора DMTF, которая занимается развитием стандартов в области управления ИТ-системами. Она, например, имеет свои спецификации по открытому стандарту распространениия виртуальных модулей OVF, который в будущем должны стать единым стандартом развертывания ПО в виртуальных машинах. В данной инициативе принимали участие компании Dell, HP, IBM, Microsoft, VMware и XenSource (еще до покупки компанией Citrix).

По своей сути стандарт OVF подразумевает кросс-платформенность, но на деле этого нет, так как он весьма скудно описывает сам образ виртуального диска (VMDK, VHD и пр.), уделяя большее внимание метаданным. Но так как каждая платформа виртуализации работает только со своим форматом виртуальных дисков, то есть некоторые проблемы с распространение данного "открытого" формата.

Виртуальный модуль в формате OVF представляет собой набор файлов, куда входят виртуальные диски (например, VMDK) и файл с расширением *.ovf, реализующий открытое описание файлов конфигурации виртуального модуля. Есть также подвид OVF - файл *.ova, который является TAR-архивом файлов OVF-пакета. То есть, ova-файлы идут по одному для каждого виртуального модуля, поэтому их проще распространять. С точки зрения размера и быстродействия OVA/OVF примерно одинаковы:

Когда вы делаете экспорт виртуальной машины из vSphere Client для создания виртуального модуля (Export OVF Template), вам как раз предлагают выбрать нужный формат OVF/OVA:

Так что вот - основная идея такова, что независимые разработчики ПО должны прежде всего ориентироваться на формат OVF / OVA при распространения своего ПО в виртуальных машинах. Но вот что непонятно - почему в VMware vCenter Converter Standalone 4.3 убрали поддержку OVF: "Support for OVF format is discontinued"?