Если вам по каким-либо причинам понадобилось подключить флэшку или другое USB-устройство к VMware ESXi, например, в целях сбора диагностических данных или интеграции сторонних пакетов (или драйверов) в гипервизор, то сделать это можно способом, описанным ниже. Прежде всего отметим, что монтирование USB-хранилищ в консоль ESXi поддерживается только для файловой системы FAT16.
1. Сначала нужно отключить службу USB Arbitrator service, которая отвечает за проброс USB-девайсов в виртуальные машины хост-сервера. Для этого выполняем команду:
# /etc/init.d/usbarbitrator stop
2. Далее подключаем носитель к ESXi и проверяем девайс командой:
# esxcli storage core device list | grep -i usb
или смотрим список смонтированных файловых систем:
# esxcli storage filesystem list
После этого вы можете работать с USB-устройством через папку /vmfs/volumes/NO NAME/. Например, можно установить бандл ESXi с флешки:
Не так давно мы писали о том, что компания Teradici планирует выпустить продукт для доступа пользователей к серверам инфраструктуры предприятия через высокопроизводительный протокол PCoIP и сервисы Microsoft RDS. Изначально это решение носило название Teradici Remote Desktop Services Host (RDSH), теперь же оно звучит проще - Teradici Arch.
Решение Teradici Arch направлено на тех пользователей, кто использует терминальные службы Microsoft для доступа пользователей к приложениям, размещенным на серверах Microsoft Windows Server, которые они по каким-то причинам не хотят (или не могут) переносить в VDI-среду VMware View.
С одной стороны, для VMware этот шаг Teradici очень выгоден - поскольку решение Arch завязано на брокер соединений VMware View Manager (обязательное требование), только VMware сможет предлагать своим клиентам законченное решение как по виртуализации рабочих нагрузок в VDI-среде VMware View, так и для улучшения производительности Legacy-информационных систем, применяющих терминальный доступ на базе Microsoft RDS в Windows Server 2008 и Windows Server 2012 (последний пока не поддерживается).
С другой же стороны, не будем забывать, что компания Teradici не принадлежит VMware, и решение Arch несколько диверсифицирует ее софтово-продуктовый портфель, что может привести к приобретению большей независимости от VMware в будущем и, как следствие, сотрудничеству с Microsoft.
Архитектура решения Teradici Arch такова:
В разрыв канала между софтовыми и железными клиентами ставится виртуальный модуль PCoIP Connection Manager (Virtual Appliance), который и отвечает за обработку соединений пользователей и выступает в качестве защищенного шлюза. Модуль PCoIP Security Gateway позволяет поддерживать безопасное соединение между клиентами и View Connection Server (который находится в DMZ), что не требует наличия стороннего VPN-решения. Компоненты PCoIP Services устанавливаются на Windows-серверы и позволяют полностью избавиться от RDP-протокола, заменив его на PCoIP (то есть, RDP становится недоступным на этих серверах).
Требования продукта Teradici Arch:
Microsoft Windows Server 2008 R2 SP1 x64 с сервисами RDS (работающий в виртуальных машинах на ESXi или на физических серверах)
VMware View Agent 5.1 или более поздней версии
VMware View Connection Server 5.1 или более поздней версии
Установленные VMware Tools, если сервер работает в виртуальной машине
На данный момент заявлена поддержка до 2-х мониторов на публикуемый рабочий стол с разрешением 2560×1600. Поддерживаемые клиенты:
PCoIP Zero Clients
Tera2: firmware version 4.0.3
Tera1: firmware version 4.0.2
VMware View Windows soft client, version 5.2
VMware View Apple OS X soft client, version 1.7
VMware View iOS and Android clients, version 1.7
Поддержка USB-устройств пока ограничена только клавиатурой и мышью.
Продукт Teradici Arch пока доступен только в качестве технологического превью по этой ссылке. Даташит доступен тут.
Как многие помнят, ранее в настройках VMware Tools можно было настраивать синхронизацию времени гостевой ОС со временем хост-сервера VMware ESXi. Доступно это было при двойном клике на иконку VMware Tools в гостевой системе:
Теперь же, начиная с vSphere 5.1, при двойном клике на иконку VMware Tools вы увидите следующее:
То есть тут, по-сути, доступна только информация о версии пакета. Это правильно, так как пользователю виртуальной машины не должно быть доступно никаких действий и настроек, относящихся к слою виртуализации.
Вместо этого, различные настройки, в том числе синхронизации времени, были вынесены в категорию VMware Tools опций виртуальной машины (Virtual Machine –> Edit Settings –> Options –> VMware Tools):
Теперь администраторам VMware vSphere не требуется полномочий в гостевой ОС, чтобы регулировать настройки VMware Tools.
VMware vCenter Support Assistant 5.1 - это бесплатный плагин к VMware vCenter Server, который призван облегчить сбор диагностических данных об инфраструктуре VMware vSphere, а также помочь обратиться в техническую поддержку:
Если вы обращались в техподдержку VMware, то, наверняка, знаете, что это не очень удобный и весьма замороченный процесс. Теперь все это станет проще, поэтому продукт просто необходимо поставить в своей инфраструктуре. Тем более, что это плагин к vCenter, а не виртуальный модуль (Virtual Appliance).
Написана она на PowerCLI человеком по имени Sean Duffy и обновлялась совсем недавно - 29 декабря прошлого года.
Для резервного копирования и восстановления конфигурации VMware ESXi используются командлеты PowerCLI Get-VMHostFirmware и Set-VMHostFirmware. Утилита была протестирована для ESXi 5.0 и 5.1, графический интерфейс позволяет производить резервное копирование на локальный диск компьютера, где она запущена. Убедитесь, кстати, что в вашей инфраструктуре работает служба DNS, так как утилита обращается к хост-серверам по именам.
Из интересных особенностей - возможность восстановить конфигурацию на другой хост ESXi (на скриншоте подчеркнуто красным). В последней версии также добавлена валидация хоста на возможность резервного копирования и восстановления (т.е., что он не находится в maintenance mode и вообще работает).
Скачать ESXi Host Backup & Restore GUI Utility можно по этой ссылке. Для запуска утилиты вам потребуется установленный PowerShell / PowerCLI.
Дмитрий Гачко, генеральный директор компании ИТ-ГРАД, рассказывает об успешном использовании решений VMware для предоставления услуг аутсорсинга ИТ-инфраструктуры (IaaS), а также о будущих планах по предоставлению услуги Desktop-as-a-Service (Daas). Дмитрий говорит о критериях, по которым была выбрана эта платформа, раскрывая основные преимущества, полученные на практике.
ИТ-ГРАД – динамично развивающаяся компания, которая предоставляет услуги функционального ИТ-аутсорсинга. Более подробно об услугах компании можно почитать по этой ссылке.
Компания VMware выпустила очередной постер, посвященный составляющим инфраструктуры VMware vCloud - VMware vCloud Suite Poster.
Постер скорее маркетинговый, чем технический (в отличие от предыдущего), однако позволяет вкратце почитать о назначении и функциональности продуктов семейства vCloud, а также понять взаимосвязь компонентов законченного решения. Постер также может быть хорошим ответом на чей-нибудь вопрос о том, что же у VMware есть для организации облачной инфраструктуры, кроме VMware vSphere?
Напомним также, что все существующие на сегодняшний день постеры компании VMware можно найти по короткой ссылке:
Интересные новости приходят от Дункана: в VMware vSphere 5.0 Update 2 при переименовании виртуальной машины во время миграции Storage vMotion ее VMDK-диски также переименовываются (раньше это не работало - менялось только имя машины). Но это, почему-то, не включено по умолчанию.
Чтобы это заработало нужно добавить расширенную настройку VMware vCenter. Для этого идем в "Administration" -> "vCenter Server Settings" -> "Advanced Settings" и добавляем параметр:
provisioning.relocate.enableRename со значением true
Итак, титаническая работа была проделана - и диски теперь переименовываются. Однако, почему эта настройка не активирована по умолчанию? Непонятно - бажит наверное...
Для VMware vSphere 5.1 эта штука пока не актуальна (только vSphere 5.0 Update 2), но обещают, что скоро она заработает с очередным апдейтом. Кстати, а почему тут только интерфейс добавления расширенных настроек и нет удаления?
Продолжаем рассказывать о решении для создания отказоустойчивой инфраструктуры хранения виртуальных машин для платформы Hyper-V - StarWind Native SAN. Недавно, кстати, мы писали о том, что появилось бесплатное издание StarWind Native SAN for Hyper-V Free edition с функциями отказоустойчивости хранилищ хост-серверов.
На этот раз предлагаем вашему вниманию документ "Virtualization Reality:
Why StarWind Virtual SAN Solutions
Deliver Value When Compared to Microsoft", в котором рассмотрены 5 причин, исходя из которых решение StarWind Native SAN имеет преимущества и ценность по сравнению со встроенными средствами Microsoft Hyper-V, такими как Shared Nothing Live Migration, Hyper-V Replica и механизмом кластеризации через SMB 3.0.
Также в документе, помимо всего прочего, рассмотрены архитектуры Scale-Out File Servers, о которой мы уже писали вот тут, и построение кластеров Microsoft на базе дисковых полок SAS JBOD. Как не трудно догадаться, все это хуже, чем решение StarWind Native SAN.
Как видно из списка, курс покрывает большинство аспектов администрирования VMware View и будет очень полезен начинающим администраторам инфраструктуры виртуальных ПК.
Напомним, что на русском языке доступны также следующие обучающие онлайн-курсы:
Вот ты каждый день ходишь на работу, не опаздываешь, живешь правильно. Крестик на груди. Ершиком в общественном туалете даже иногда пользуешься. Время от времени ездишь в Египет, Тайланд или на Маврикий. Сам понимаешь - кому как. Ребенка вот в правильную школу устроил, английский учит, хоккей там, футбол (когда лед дорогой). Начальство нормуль, жена дает, любовница есть. Каждый год - новая.
Идет все как всегда - ничто не задевает твои чувства. Ну почти...Нет, ну вот ты помнишь, как эти бесстыдные девчонки дрыгались в храме? Че они там делали, че хотели сказать? Зачем? Глупые! Хули, пусть сидят. Если все так будут относиться к вере, то что с ней будет?
Или вон вообще - акция поцелуев. Охренели что ли? В центре Москвы пидорасы лижутся. Телки ладно, но пидорасы. Ну дела! И правильно, что им носы расхерачили. Пусть знают. У тебя же дети, увидят таких - и задумаются, а не стать ли им пидорасами? Если пидорасам все будет позволено, то что это за жизнь такая будет? Везде ж будут одни пидорасы.
А вон эти смешные в Лос-Анжелесе - сделали понедельники вегетарианскими. Дебилы. Мясо надо есть - там все витамины, аминокислоты. Тем более в понедельник. Без мяса будешь дохлый, никчемный. Лузером станешь, и все над тобой будут смеяться. Вон как Толян (улыбаешься, вспомнив Толяна).
В бога надо верить, пидорасов гнобить и мясо есть. А любовница, взятки, "всё в дом", бухло по пятницам и пивной животик - это нормально, так у всех. Так вот ты думаешь. И, может быть, ты даже никогда и не представишь, что ссышь поменять хоть одно слагаемое в этой сложившей твою жизнь формуле.
Оказывается, один из самых частых вопросов по продукту для виртуализации настольных ПК VMware View - это как можно показать PCoIP-сессию пользователя через средство управления vSphere Client (по умолчанию там показывается чистый экран).
Для этого необходимо поменять настройку в шаблоне групповой политики (GPO) pcoip.adm. Находится этот шаблон на View Connection Server в папке:
Нужно запустить Group Policy Management, затем создать или привязать к организационной единице AD пула виртуальных ПК групповую политику. В контекстном меню данной групповой политики выбрать пункт "Edit…". В появившемся окне "Group Policy Management Editor" в контекстном меню пункта "Computer Configuration –> Policies –> Administrative Templates" выбрать пункт "Add/Remove Templates…". В появившемся окне "Add/Remove Templates" нажать на кнопку "Add.." и выбрать файл с ADM-шаблоном "pcoip.adm".
Далее нужно установить Enable для настройки "Enable access to PCoIP session from a vSphere console":
Затем нужно применить политики и презагрузить десктоп VMware View. После этого в vSphere Client в консоли виртуальной машины вы будете наблюдать то же самое, что и для VMware View Client:
Более подробно о настройках шаблона pcoip.adm можно узнать из документации.
Среди предложений облачного провайдера ИТ-ГРАД есть услуга по предоставлению облачной инфраструктуры для Java-разработчиков, реализованной на базе продуктов VMware vFabric. Она включает в себя высокопроизводительный сервер приложений, сервис работы с БД SQL, сервис обмена сообщениями, балансировщики нагрузки и сервис хранения файлов.
Также в составе решения предлагается среда поддержки жизненного цикла разработки приложений – IT-GRAD ALMaaS.
Компания ИТ-ГРАД, также имеет в составе своих предложений специализированное решение для команд разработчиков на базе продуктов семейства Team Foundation Server компании Майкрософт и ресурсов собственного публичного облака.
Решение представляет из себя готовую, выделенную для каждой команды разработчиков площадку, предварительно настроенных продуктов компании Майкрософт, предназначенных для коллективной разработки программного обеспечения. Набор состоит из следующих компонент, которые в зависимости от потребностей могут изменяться в количестве и конфигурации.
Team Foundation Server – средство учета требований, выдачи заданий на разработку и тестирование, учет ошибок и контроль версий исходных кодов.
Среда разработчика – выделенный сервер разработчика, с предустановленным пакетом Visual Studio 2010 (любая редакция на выбор) и Test Manager 2010, предназначенный для удаленной работы разработчиков и тестировщиков, дает возможность отказаться от повышенных требований к персональным компьютерам сотрудников, повысить безопасность работы, унифицировать среду разработчика и сократить время на развертывание рабочих сред для новых сотрудников.
Очень давно мы писали про тип виртуальных дисков Paravirtual SCSI (PVSCSI), который появился в VMware vSphere 4 и был создан для требовательных к ресурсам ввода-вывода нагрузок. На заре своего развития виртуальные диски типа PVSCSI не рекомендовались к использованию в качестве загрузочных, а также имели несколько серьезных багов, но широко тестировались в связи с тем, что показывали большую производительность, чем стандартный LSI SCSI.
Эту статью мы пишем, главным образом, здесь для того, чтобы сказать - уже можно. Виртуальные диски Paravirtual SCSI достаточно стабильно работают в VMware vSphere. В KB 1010398 мы видим матрицу поддержки дисков pvscsi для различных релизов VMware vSphere (обычные и boot-диски):
Guest operating system
Data Disk
Boot Disk
Windows Server 2008 R2 (64-bit only)
ESX/ESXi 4.0 Update 1, ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.0 Update 1, ESX/ESXi 4.1, ESXi 5.0
Windows Server 2008 (32 and 64 bit)
ESX/ESXi 4.X, ESXi 5.0
ESX/ESXi 4.0 Update 1, ESX/ESXi 4.1, ESXi 5.0
Windows Server 2003 (32 and 64 bit)
ESX/ESXi 4.x, ESXi 5.0
ESX/ESXi 4.x, ESXi 5.0
Windows 7 (32 and 64 bit)
ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.1, ESXi 5.0
Windows Vista (32 and 64 bit)
ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.1, ESXi 5.0
Windows XP (32 and 64 bit)
ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.1, ESXi 5.0
Red Hat Enterprise Linux (RHEL) 5 (32 and 64 bit) and all update releases
ESX/ESXi 4.X, ESXi 5.0
Not Supported
RHEL 6 (32 and 64 bit)
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
SUSE Linux Enterprise 11 SP1(32 and 64 bit) and later releases
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
Ubuntu 10.04 (32 and 64 bit) and later releases
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
Distros using Linux version 2.6.33 or later and that include the vmw_pvscsi driver
ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.1, ESXi 5.0
В VMware vSphere/ESXi 5.1 поддерживается все то, что поддерживалось и в предыдущих версиях платформы.
Что же раньше были за баги с PVSCSI? Смотрим, например, в статье тут, отсылающей нас к KB компании Microsoft. Ошибка существовала для ОС Windows Server 2008 R2 и была критической, а устранена была только в VMware vSphere 5.0 Update 1, о чем есть KB 2004578.
Теперь о том, как поставить диск типа PVSCSI в качестве загрузочного для виртуальной машины на ESXi. Выбираем в vSphere Client контроллер типа VMware Paravirtual :
В настройках виртуальной машины добавляем виртуальный floppy-дисковод и указываем образ дискеты с драйвером PVSCSI, который лежит в папке vmimages->floppies (если там ничего нет, идем сюда):
Дальше при выборе диск для установки Windows указываем драйвер с дискеты:
Дальше ставим все как обычно. Если хочется запихнуть драйвер PVSCSI в кастомизированную ISO-шку, то вам сюда. И да, драйвер на образе дискеты от Windows Server 2008 прекрасно работает на Windows Server 2012, который, в свою очередь, работает на VMware vSphere 5.1.
Если вы попробуете импортировать виртуальную машину (или Virtual Appliance), которая была создана для настольных платформ виртуализации (например, VMware Workstation в формате 2gbsparse), в VMware vSphere 5.1 с помощью утилиты vmkfstools, то у вас это не выйдет. Вы получите подобное сообщение:
Failed to open 'VM-name.vmdk': The system cannot find the file specified (25).
Ошибка может быть и такой:
File [VMFS volume]\VM-name.vmdk was not found.
И такой:
Error Stack:
An error was received from the ESX host while powering on VM VM-name
Cannot open the disk '/vmfs/volumes/Datastore/VM-name/VM-name.vmdk' or one of the snapshot disks it depends on.
The system cannot find the file specified.
VMware ESX cannot find the virtual disk '/vmfs/volumes/Datastore/VM-name/VM-name.vmdk'. Verify the path is valid and try again.
Все это из-за одного и того же - в VMware vSphere 5.1 убрали автоматическую загрузку модуля multiextent, который и отвечает как раз за конверсию виртуальных дисков с hosted-платформ VMware в формат VMFS. Чтобы загрузить этот модуль нужно выполнить простую команду:
# vmkload_mod multiextent
Ну а чтобы выгрузить:
# vmkload_mod -u multiextent
Делать это можно смело, так как этот модуль отвечает только за работу с Non-VMFS дисками ВМ.
Так вот для тех из вас, кто решил встать на нелегкий путь сертификации VCAP (экзамены действительно сложные), вышло руководство VCAP5-DCA Study Guide, основанное на официальном Blueprint и насчитывающее 349 страниц (!). В нем, как это часто бывает, много ботвы, но и по существу есть немало полезного.
Для администраторов VMware vSphere в руководстве также найдется много интересного. Руководство снабжено картинками, командами CLI и, что самое нужное при подготовке к экзамену VCAP, отсылками к конкретным документам VMware (и их главам) по каждой теме. Штука местами очень классная - рекомендую.
Компания StarWind Software, производящая продукт номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN & NAS, приглашает на бесплатный вебинар "Increase Operational Efficiency with StarWind!", который проводит Анатолий Вильчинский, системный инженер StarWind Software.
На вебинаре будет рассказано о том, как с помощью решений StarWind можно улучшить эффективность хранения данных виртуальных серверов за счет функций дедупликации, а также функций высокой доступности хранилищ (напомним, что использовать их можно бесплатно).
Вебинар состоится в четверг, 24 января в 19-00 по московскому времени. Регистрируйтесь!
Теперь, на основе статьи Франка, мы обобщим и актуализуем информацию по миграциям vMotion и Storage vMotion в разных контекстах - на уровне хранилищ, сети и хост-серверов VMware ESX.
Как и в прошлой статье, здесь будем пользоваться понятием стоимости миграции в единицах (cost) и максимального значения костов в тех же единицах (max cost), которое отображает предельно допустимое значение. Сумма костов операций vMotion и SVMotion не должна превышать max cost для соответствующего объекта (datastore, NIC и хост ESXi).
Теперь взглянем на таблички (в них есть не только vMotion, но и SVMotion):
Хост ESXi
Operation
Config Key
Cost
vMotion Cost
costPerVmotionESX41
1
Storage vMotion Cost
costPerSVmotionESX41
4
Maximum Cost
maxCostPerEsx41Host
8
Сеть
Operation
Config Key
Cost
vMotion Cost
networkCostPerVmotion
1
Storage vMotion Cost
networkCostPerSVmotion
0
Maximum Cost
maxCostPerNic
2
maxCostPer1GNic
4
maxCostPer10GNic
8
Хранилище (Datastore)
Operation
Config Key
Cost
vMotion Cost
CostPerEsx41Vmotion
1
Storage vMotion Cost
CostPerEsx41SVmotion
16
Maximum Cost
maxCostPerEsx41Ds
128
Читать эти таблички просто - например, для хоста ESXi стоимость миграции vMotion равна 1, а поскольку max cost равно 8, то всего на хост может быть 8 одновременных миграций в конфигурации по умолчанию. Либо допустимы одновременно: 1 миграция SVMotion (4 очка) и 4 штуки vMotion (по одному очку каждая), т.е. суммировать надо по костам: 4+1+1+1+1=8.
Для хранилища (Datastore) также есть ограничения vMotion, поскольку передаются страницы файла подкачки (если он не шаренный между хостами), а также производится передача владения VMX-файлом и другими файлами ВМ на хранилище. Но поскольку влияние это мало, то стоимость vMotion для хранилища всего 1 при максимальной емкости одновременных операций 128 (а вот SVMotion, требующая значительных ресурсов хранилища, "кушает" 16 единиц). Таким образом 1 операция vMotion съест 1 единицу коста, поэтому в этот момент для хранилища будет доступно только 7 миграций SVMotion, т.е. (128-1) div 16 = 7.
Соответственно, редактирование параметра Config Key для соответствующей операции позволяет изменять количество одновременных операций vMotion/SVMotion. Для редактирования параметра Config Key нужно отредактировать конфигурационный файл vpxd.cfg на сервере VMware vCenter, который находится в папке:
Если соответствующей секции нет, то ее можно просто добавить. Уменьшать максимальные косты точно можно, а увеличение работает не всегда. То есть гарантированно вы сможете только уменьшить число одновременных миграций vMotion или SVMotion, а вот увеличить - не факт. Ограничение можно делать двумя способами - повышением обычных костов или понижением максимальных костов.
Теперь самое интересное - это динамический параметр max cost для сетевых адаптеров. Как видно из таблицы, его действующее значение зависит от типа сетевого адаптера на хосте - 1G или 10G. Но, на самом деле, и не только от типа. Точнее - от скорости соединения для трафика vMotion между хостами ESXi, которую обнаруживает VMkernel. Таким образом:
Если VMkernel обнаруживает соединение на скорости 1Gbit/s - Maximum Cost выставляется в значение 4 (это верно и для случая соединения 1G<->10G).
Если VMkernel обнаруживает соединение на скорости 10Gbit/s - Maximum Cost выставляется в значение 8.
Если VMkernel обнаруживает соединение на скорости ниже 1Gbit/s - Maximum Cost выставляется в значение 2.
Таким образом, для адаптера возможны либо 2, либо 4, либо 8 одновременных миграций vMotion, в зависимости от действующей скорости соединения. Операция Storage vMotion, как видно из таблицы, костов сети не кушает.
Если ограничение для сети жестче (например, 4 миграции vMotion), чем ограничение для хоста (8 миграций vMotion) - то для машин этого хоста действует ограничение сети.
Продолжаем рассказывать об услугах сервис-провайдера ИТ-ГРАД - первой в России компании, предоставляющей в аренду виртуальные машины по модели IaaS. В компании понимают, что пользователям виртуальной инфраструктуры инересны комплексные решения, то есть не только размещение своих виртуальных серверов в облаке, но и получение в аренду виртуальных ПК с необходимым набором приложений - Desktop as a Service (DaaS). Особенно это актуально для небольших компаний, которым непросто делать капитальные вложения в инфраструктуру.
По модели DaaS ИТ-ГРАД предлагает в аренду виртуальные рабочие станции (VDI) - полностью готовое к работе («под ключ») стандартизированное виртуальное рабочее место, которое каждый пользователь имеет возможность дополнительно настраивать под свои задачи, т.е. клиент получает доступ не к отдельной программе, а к необходимому для полноценной работы программному комплексу.
Комплексные решения создания виртуальных рабочих мест, предлагаемых ИТ-ГРАД, базируются на решениях VMware View и Citrix XenDesktop.
В услугу включены ресурсы для размещения виртуальных рабочих станций, базовый набор ПО:
ОС Windows,
MS Office,
антивирусное ПО,
архиватор.
Под задачи клиентов базовый набор может быть расширен. Эта услуга рассчитана на компании, где требуется регулярное обновление парка ПК.
Заказать услуги по предоставлению виртуальных ПК в аренду можно по этой ссылке (тестирование бесплатно).
Мы уже писали о калькуляторе VMware View VDI Flash Calculator, который недавно обновился до версии 2.9. На сегодняшний день это калькулятор номер 1 для расчета параметров инфраструктуры виртуальных ПК на базе VMware View (с поддержкой vSphere 5.1 и View 5.1).
Штука это очень крутая и серьезная, описание немалого количества параметров калькулятора и мануал можно найти здесь.
А вот что нового появилось в VMware View VDI Flash Calculator 2.9:
Увеличено число допустимых ВМ на процессор/ядро сервера до 20
Добавлена поддержка экономии операций ввода-вывода с дисковой подсистемой за счет механизма Content Based Read Cache (CBRC Base % IOP). Предполагается экономия на уровне 65% (можно регулировать)
Полная поддержка VMware vSphere / vCenter 5.1
Добавлен фреймворк для поддержки еще нереализованной функциональности VMware View
Добавлена валидация в соответствии с VMware compatibility matrix
Пофикшены баги отображения
Есть также обучающее видео по работе с калькулятором:
В рамках Phase V (они величают свои изыскания "фазами") был опубликован 80-страничный документ "Antivirus impact and best practices on VDI", в котором они сравнивают производительность различных антивирусных решений в инфраструктуре VDI (традиционно рассматривалась платформа VMware View / vSphere).
КДПВ из какого-то исследования (есть в документе):
Поэтому детально сравниваются только 3 антивируса для VDI:
Microsoft
Forefront Endpoint Protection 2010 (Now System Center Endpoint Protection 2012)
McAfee
- Enterprise 8.8.0
- MOVE Multiplatform AV 2.x
- MOVE Agentless AV 2.5
Symantec
- Endpoint Protection 12.1
Странно, что обошли стороной компанию Trend Micro с ее весьма популярным, заточеннымспециально под виртуализацию, решением Deep Security. Ну а нам было бы интересно посмотреть, как ведет себя Касперский в среде VDI. Но чего нет, того нет.
Конечно же, в документе рассмотрены и варианты развертывания, когда антивирусный агент работает за пределами виртуальных машин (за счет механизма VMsafe и EPSEC API):
В конце там много всяких графиков без окончательного вывода о том, что же все-таки лучше. Поэтому смотрите сами.
В прошлой статье про средство резервного копирования и восстановления StarWind Hyper-V Backup Plug-in (опция к StarWind Native SAN for Hyper-V) мы обещали рассказать про такие режимы восстановления как:
Restore in Sandbox - возможность восстановить ВМ без ее влияния на продуктивную работающую копию (восстановление происходит в изолированное виртуальное окружение)
Restore from archive - возможность восстановить ВМ напрямую из архива (в случае крайней необходимости)
Restore in Sandbox
Этот режим нужен тогда, когда требуется восстановить ВМ в изолированное окружение и что-нибудь проверить, например, что все данные внутри остались целостными и приложения работают (т.е. архив пригоден для восстановления). Для этого нужно выбрать пункт "Restore in Sandbox" для резервной копии:
Восстановленная и запущенная виртуальная машина будет полностью изолирована от работающей продуктивной копии за счет собственных настроек сетевого взаимодействия и отдельного хранилища.
Вот так это выглядит в консоли Hyper-V Manager:
Restore from archive
Этот режим можно использовать только в экстренных случаях, когда виртуальная машина должна быть восстановлена безотлагательно. Для этого нужно выбрать пункт "Launch VM from Archive" из контекстного меню хранимой резервной копии.
После этого будет выдано предупреждение:
Чекбокс перед восстановлением заставляют поставить потому, что такой тип восстановления приведет к тому, что все инкременты данной резервной копии будут потеряны (т.е. останется только полная резервная копия последнего состояния), поскольку нужно запустить виртуальную машину, используя образ ВМ из архива.
Поэтому, если есть возможность, следует использовать варианты восстановления "Restore Original VM" или "Restore in Sandbox"
Напомним также, что у StarWind есть плагин для резервного копирования виртуальных машин и на платформе VMware vSphere - VMware Backup Plug-in.
Начиная с версии VMware vSphere 4.0, компания VMware сделала замечательную вещь - все выпускаемые ей в комплекте с платформой виртуализации пакеты VMware Tools обратно совместимы со всеми прошлыми версиями хостов VMware ESXi:
Соответственно, на VMware ESX 4.0 можно использовать VMware Tools от vSphere 5.1, но как сделать это, не обновляя платформу виртуализации? Оказывается есть простой метод, опубликованный на v-front.de и основанный на информации из KB 2004018.
Там будет один или два файла с расширением .vib. Если их два, то тот, что с меньшим номером билда - это тулзы, содержащие только обновления безопасности, а тот, что с большим - включает и эти обновления, и багофиксы. Берем тот, что с большим номером (609), кликаем на нем 2 раза и проваливаемся дальше в архив, где виден репозиторий VMware Tools:
Эти три папки вы уже когда-то видели на Datastore в ESXi (во время установки тулзов). Создаем папку с именем vmware-tools на локальном хранилище ESX / ESXi и заливаем туда три извлеченные из vib'а папки, чтобы получилось вот так:
Теперь нужно настроить хост ESXi для использования данного репозитория VMware Tools. Для этого идем в Advanced Settings хоста ESXi и настраиваем параметр UserVars.ProductLockerLocation, где прописана версия тулзов в формате:
/locker/packages/<ESXi-Version> (ESXi-Version = 5.1.0, 5.0.0, 4.1.0 or 4.0.0)
В нашем случае она выглядит так:
/locker/packages/5.1.0
Меняем ее на путь к репозиторию: /vmfs/volumes/<имя Datastore>/vmware-tools.
После этого нужно перезагрузить хост, и изменения вступят в силу. Если перезагружать ESXi не хочется, то можно в корне файловой системы пересоздать символьную ссылку /productLocker:
Можно также вызвать команды, которые вызываются хостом для пересоздания символьных ссылок:
/sbin/configLocker - для ESX / ESXi 4.x
jumpstart --plugin=libconfigure-locker.so - для ESXi 5.x
Теперь остается только выбрать пункт Install/Upgrade VMware Tools в консоли vSphere Client при подключении к консоли ВМ для обновления компонентов пакета.
Многим интересующимся технологиями виртуализации известна компания Stratus Technologies, занимающаяся вопросами непрерывной доступности виртуальных машин (Fault Tolerance). Ранее продукты этой компании были доступны на платформе Citrix XenServer, где позволяли обеспечивать непрерывную доступность программными методами (продукт everRun от купленной компании Marathon):
Теперь у компании появился программно-аппаратный комплекс Stratus ftServer systems with vSphere 5.1, интегрированный с последней версией платформы виртуализации от VMware. Возможности решения из пресс-релиза:
Обещают аптайм на уровне 99.999%, что соответствует 5.26 минут простоя в год
Один или два 8-ядерных процессора Intel с поддержкой hyper-threading и архитектуры QuickPath
Полная поддержка SMP для построения архитектуры непрерывной доступности (vSMP?)
Встроенные интерфейсы 10Gb Ethernet
Проактивная система мониторинга, предупреждающая о возможных сбоях
Система обнаружения проблем в самом сервере и операционной системе, работающая без прерывания обслуживания виртуальных машин
Минимальный overhead (<5%) на систему виртуализации
Интеграция с VMware HA
Очевидно, что Stratus суетится накануне выхода программного vSMP Fault Tolerance от самой VMware.
Кстати в пресс-релизе по ftServer говорится о полугодовой гарантии на нулевой даунтайм в $50 000, покрывающей не только серверную часть, но и гипервизор (!). Так что торопитесь - возможно, парочка серверов от Stratus достанется вам совершенно бесплатно (учитывая тот набор багов, который мы видим в vSphere 5.1).
На днях компания VMware провела целых два тестирования (тут и тут), целью которых было сравнение производительности виртуальных дисков VMDK и RDM виртуальных машин на платформе VMware vSphere 5.1. Напомним про предыдущие сравнения VMFS и RDM, где основной моралью был тот факт, что оба этих типа виртуальных дисков практически идентичны по производительности, поэтому их следует использовать только в случаях, когда требуется специфическая функциональность (например, кластеры MSCS и большие диски для RDM):
Итак, для первого тестирования использовалась следующая конфигурация:
В качестве нагрузки использовался тест DVD Store для приложения, симулирующего интернет-магазин на платформе mySQL 5.5. Также было задействовано несколько тестовых клиентов для создания реальной нагрузки.
Масштабируемость производительности под нагрузкой (OPM - это orders per minute):
Как видно из результатов, масштабируемость производительности при увеличении числа ВМ почти линейная, а результаты различных типов дисков - идентичны (на самом деле, VMDK показал себя на 1 процент быстрее RDM для 1-й ВМ и чуть медленнее для 4-х ВМ):
Затраты ресурсов CPU на обслуживание операций ввода-вывода также чуть-чуть (на тот же 1%) лучше в пользу VMDK:
Теперь обратимся ко второму исследованию. Там использовалась следующая тестовая конфигурация, выдающая 1 миллион IOPS на тестах:
Hypervisor: vSphere 5.1
Server: HP DL380 Gen8
CPU: Two Intel Xeon E5-2690, HyperThreading disabled
Memory: 256GB
HBAs: Five QLogic QLE2562
Storage: One Violin Memory 6616 Flash Memory Array
VM: Windows Server 2008 R2, 8 vCPUs and 48GB.
Iometer Configuration: Random, 4KB I/O size with 16 workers
Тут уже измерялась производительность в IOPS для виртуальных машин на платформе VMware vSphere 5.1. При этом варьировался размер блока ввода-вывода (I/O Size) и сравнивались VMDK диски в VMFS5 и RDM-тома (нагрузка - случайное чтение):
Здесь уже на тот же самый 1% выигрывает RDM (для тестов на I/O). В тестах на MB/s ситуация в одном тесте оказалась в пользу VMFS. Масштабируемость тут уже показана не совсем линейная, при этом завал кривой начинается после размера блока в 4 Кб (единственный и по умолчанию в vSphere 5.1).
Второй тест - 60% операций чтения и 40% операций записи:
Такой рост производительности на блоке в 4 Кб объясняется просто - массив, примененный в тестировании, использует размер блока 4 Кб.
Вывод обоих тестов - виртуальные диски VMDK и RDM практически идентичны с точки зрения производительности.
Компания Citrix выпустила обновление своего продукта для создания инфраструктуры виртуальных ПК в небольших компаниях Citrix VDI-in-a-Box 5.2. Напомним, что о предыдущей версии этого продукта (5.1) мы уже писали вот тут (а еще раньше - здесь).
Новые возможности решения Citrix VDI-in-a-Box 5.2:
Support for new hypervisor versions - теперь VDI-in-a-Box поддерживает гипервизоры Microsoft Hyper-V Server 2012, XenServer 6.1 и vSphere 5.1.
Citrix Cloud Gateway StoreFront support - пользователи StoreFront могут получать доступ к своим VDI-in-a-Box через Cloud Gateway. StoreFront - это унифицированное хранилище данных и приложений (Win/Web/SaaS), которые могут быть доставлены посредством Citrix на различные устройства.
Microsoft Lync support - пакет Citrix HDX RealTime Optimization Pack for Microsoft Lync позволяет совершать видеозвонки высокой четкости, используя свои виртуальные ПК.
Image export - опубликованные образы ПК могут быть экспортированы для использования в Citrix XenDesktop и других продуктах.
Licensing management through a Citrix license server - для существующих пользователей Citrix, у которых уже есть сервер лицензий от других продуктов компании, теперь есть возможность управления лицензированием VDI-in-Box.
Multiple data stores - пользовательские объекты vDisk могут находиться на разных хранилищах, что позволяет оптимизировать производительность различных категорий данных и приложений.
Windows Server 2012 virtual desktops - поддержка виртуальных ПК с гостевой ОС Windows Server 2012 (но только посредством RDP-соединений).
Automated desktop agent upgrade - после обновления VDI-in-a-Box можно обновить агентов в виртуальных ПК одним кликом.
Citrix Desktop Lock - возможность залочить физический ПК, когда пользователям не требуется локальный компьютер. В результате обычные рабочие станции превращаются в подобия тонких клиентов.
Скачать Citrix VDI-in-a-Box 5.2 можно по этой ссылке. Документ по миграции с предыдущих версий находится тут.
Рост бизнеса компании ИТ-ГРАД по предоставлению в аренду виртуальных машин на платформе VMware vSphere в столице и, как следствие, рост числа сотрудников повлекли за собой необходимость поиска нового, более просторного помещения. Новый офис находится в бизнес-центр «Золотое кольцо», в минуте ходьбы от ст. м.Кожуховская. Телефон остался прежним: +7 (495) 748-05-77.
Точный адрес можно посмотреть в разделе "контакты". Мы всегда рады видеть Вас у нас в гостях! Также в связи с расширением у нас открыты вакансии в Москве.