Мы уже писали о возомжностях новой версии Veeam Availability Suite v9, включающей в себя продукты Veeam Backup and Replication 9 и Veeam ONE 9.

Напомним возможности девятой версии флагманского продукта Veeam, о которых мы писали ранее:

• Veeam Explorer для Oracle - поддержка восстановления объектов БД в Veeam Availability Suite v9. Плюс улучшения всех эксплореров
• Интеграция с технологией EMC Storage Snapshots
• Veeam Cloud Connect с возможностью репликации
• Прямой доступ к хранилищам NFS

В этой заметке мы расскажем еще об одной важной новой функции пакета продуктов - Scale-out Backup Repository. Ранее пользователи Veeam Backup and Replication использовали различные устройства для бэкап-репозиториев, чтобы хранить резервные копии виртуальных машин. Это могли быть локальные диски серверов, файловые хранилища, разделы на СХД и многое другое. Так как инфраструктура растет постепенно и, зачастую, неоднородно, в итоге у администраторов оказывался примерно вот такой наборчик бэкап-репозиториев:

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

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

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

Эта ситуация давно волновала администраторов, и в новой версии Veeam Availability Suite v9 представлена функция Scale-out Backup Repository, которая позволяет объединить все репозитории в один мета-объект (global pool), который можно задавать в качестве целевого хранилища бэкапов. Для расширения такого пула потребуется лишь добавить экстент (extent), который повысит совокупную емкость глобального репозитория. Удобно и не надо перераспределять целевые хранилища, чтобы найти свободное место под новые бэкапы.

Таким образом, можно использовать единственную задачу резервного копирования всех нужных вам машин, указав в качестве целевого этот глобальный репозиторий. При этом глобальный репозиторий можно наращивать хранилищами любого типа - локальные диски серверов, сетевые хранилища и даже, например, дедуплицирующие физические или виртуальные модули (dedup appliances) - все это для Veeam Backup and Replication будет поддерживаться и работать.

При добавлении экстента можно указать, принимает ли он полные бэкапы (full backups), инкрементальные бэкапы (incremental backups) или оба типа. Например, для инкрементальных бэкапов можно использовать быстрые all-flash хранилища, а для полных бэкапов можно применять dedup appliance в качестве целевого хранилища резервных копий, где они будут лежать в дедуплицированном виде. Возможности для фантазии тут безграничны.

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

Более подробно об этом всем написано в блоге Veeam.

Компания VMware еще в августе выпустила полезный технический документ VMware Site Recovery Manager 6.1 Technical Overview, в котором описываются основные возможности средства для создания катастрофоустойчивых инфраструктур VMware SRM 6.1.

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

• варианты использования решения SRM
• основные топологии при построении архитектуры (active/active, active/passive и т.д.)
• развертывание и настройка продукта
• возможности механизма репликации
• сведения о настройке Protection Groups
• настройка и использование планов аварийного восстановления (Recovery Plans)
• рабочие процессы по тестированию аварийного восстановления, собственно аварийному восстановлению (Failover), а также возврату рабочей инфраструктуры с резервной на основную (Failback)

Бывает так, что на виртуальной или физической машине заканчивается свободное место на диске, где расположена база данных для VMware vCenter. Чаще всего причина проста - когда-то давно кто-то не рассчитал размер выделенного дискового пространства для сервера, где установлен vCenter и SQL Server Express.

В этом случае в логах (в SQL Event Log Viewer и SQL Log) будут такие ошибки:

Could not allocate space for object ‘dbo.VPX_EVENT_ARG’.’PK_VPX_EVENT_ARG’ in database ‘VIM_VCDB’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

CREATE DATABASE or ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 4096 MB per database.

Could not allocate space for object 'dbo.VE_event_historical'.'PK__VE_event_histori__00551192' in database 'ViewEvent' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files tothe filegroup, or setting autogrowth on for existing files in the filegroup.

Решение в данном случае простое - нужно выполнить операцию по очистке старых данных из БД SQL Server (Shrink Database). Делается это в SQL Management Studio - нужно выбрать базу данных и выполнить Tasks -> Shrink -> Database:

Смотрим, что получится и нажимаем Ok:

Также в KB 1025914 вы найдете более детальную информацию о том, как почистить базы данных Microsoft SQL Server и Oracle. Там же есть и скрипты очистки БД:

Завтра, 20 октября, компания Код Безопасности проведет бесплатный вебинар по продукту vGate R2, который предназначен для защиты виртуальной инфраструктуры VMware vSphere и Microsoft Hyper-V от несанкционированного доступа, а также для ее безопасной настройки средствами политик.

Тема вебинара - "Защита виртуальных инфраструктур: комбинация встроенных механизмов платформы виртуализации и сторонних средств". Мероприятие проведет Иван Колегов, системный аналитик компании «Код Безопасности». На вебинаре будет рассказано о защите виртуальных инфраструктур с помощью встроенных механизмов платформы виртуализации и сторонних средств.

Время и дата проведения: 20 октября в 11:00 по московскому времени.

Регистрируйтесь!

Мы часто пишем о проблемах вложенной виртуализации (nested virtualization), которая представляет собой способ запустить виртуальные машины на гипервизоре, который сам установлен в виртуальной машине. На платформе VMware ESXi эта проблема давно решена, и там nested virtualization работает уже давно, мало того - для виртуального ESXi есть даже свои VMware Tools.

Как мы недавно писали, решения для вложенной виртуализации на платформе Microsoft Hyper-V не было. При попытке запустить виртуальную машину на виртуальном хосте Hyper-V администраторы получали вот такую ошибку:

VM failed to start. Failed to start the virtual machine because one of the Hyper-V components is not running.

Все это происходило из-за того, что Microsoft не хотела предоставлять виртуальным машинам средства эмуляции техник аппаратной виртуализации Intel VT и AMD-V. Стандартная схема виртуализации Hyper-V выглядела так:

Virtualization Extensions передавались только гипервизору хостовой ОС, но не гостевой ОС виртуальной машины. А без этих расширений виртуальные машины в гостевой ОС запущены быть не могли.

В Windows 10 Build 10565 (этот превью-билд можно скачать по этой ссылке для x64 и по этой для x86) компания Microsoft, наконец-то, решила поменять ситуацию: теперь Virtualization Extensions передаются в гостевую ОС:

Соответственно, это позволит запустить вложенные виртуальные машины на хосте, который сам является виртуальной машиной с гостевой ОС Windows и включенной ролью Hyper-V.

На данный момент работает это только с Intel VT, но по идее к релизу Windows Server 2016 должно заработать и для AMD-V.

Сфера применения вложенных виртуальных машин не такая уж и узкая. Сейчас видится 2 основных направления:

• Виртуальные тестовые лаборатории, где развертываются виртуальные серверы Hyper-V и строятся модели работающих виртуальных инфраструктур в рамках одного физического компьютера.
• Использование контейнеризованных приложений (например, на движке Docker) в виртуальных машинах на виртуальных хостах Hyper-V. Более подробно о Windows Server Containers можно почитать вот тут. Немногим ранее мы писали об аналогичной архитектуре на базе VMware vSphere, анонсированной на VMware VMworld 2015.

Надо отметить, что для вложенных виртуальных машин не поддерживаются следующие операции (как минимум):

• Dynamic Memory
• Горячее изменение памяти работающей ВМ
• Снапшоты
• Live Migration
• Операции save/restore

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

Для того, чтобы вложенная виртуализация заработала, нужно:

1. Использовать Windows 10 Build 10565. Windows Server 2016 Technical Preview 3 (TPv3) и Windows 10 GA - не подойдут, так как в них возможности Nested Virtualization нет.

2. Включить Mac Spoofing на сетевом адаптере виртуального хоста Hyper-V, так как виртуальный коммутатор хостового Hyper-V будет видеть несколько MAC-адресов с этого виртуального адаптера.

3. В Windows 10 нужно отключить фичу Virtualization Based Security (VBS), которая предотвращает трансляцию Virtualization Extensions в виртуальные машины.

4. Предусмотреть память под сам гостевой гипервизор и под все запущенные виртуальные машины. Память для гипервизора можно рассчитать так:

Теперь для того чтобы включить Nested Virtualization, выполните следующий сценарий PowerShell (в нем и VBS отключается, и Mac Spoofing включается):

Invoke-WebRequest https://raw.githubusercontent.com/Microsoft/Virtualization-Documentation/master/hyperv-tools/Nested/Enable-NestedVm.ps1 -OutFile ~/Enable-NestedVm.ps1

~/Enable-NestedVm.ps1 -VmName <VmName>

Далее создайте виртуальную машину на базе Windows 10 Build 10565, и включите в ней Mac Spoofing (если вы не сделали это в скрипте). Сделать это можно через настройки ВМ или следующей командой PowerShell:

Set-VMNetworkAdapter -VMName <VMName> -MacAddressSpoofing on

Ну а дальше просто запускайте виртуальную машину на виртуальном хосте Hyper-V:

20 октября компания StarWind, производитель решения номер 1 - StarWind Virtual SAN, предназначенного для создания отказоустойчивой инфраструктуры хранилищ под виртуальные машины VMware vSphere и Microsoft Hyper-V, проводит интересный вебинар "VMware and Fault-Tolerance: Why Are 3 Nodes Better Than 2 for Hyper-Converged Architecture?".

Мероприятие пройдет 20 октября в 22-00 по московскому времени.

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

Зарегистрируйтесь!

После выхода новой версии платформы VMware vSphere 6 перед многими администраторами встал вопрос об обновлении различных компонентов виртуальной инфраструктуры. На крупных предприятиях, как правило, используется не только платформа VMware ESXi и сервисы управления vCenter, но и различные корпоративные продукты, такие как VMware Horizon View для инфраструктуры виртуальных ПК или VMware vRealize Operations (vROPs) для мониторинга и решения проблем.

Вот в какой правильной последовательности нужно обновлять решения VMware (если у нескольких продуктов очередь одна - их можно обновлять в любой последовательности):

О проведении операций по обновлению компонентов решений VMware более подробно рассказано в статье KB 2109760. Там же приведены примеры сценариев обновления, если у вас есть определенный набор продуктов.

Кстати, помните, что после обновления на VMware vSphere 6.0 вы не сможете использовать продукт VMware Storage Appliance, который больше не поддерживается.

Если вы хотите узнать совместимость различных продуктов для виртуальной инфраструктуры, воспользуйтесь ресурсом VMware Product Interoperability Matrixes.

На проходящей сейчас в Барселоне конференции VMworld Europe 2015 компания VMware раскрыла окончательные подробности технологии vSphere Integrated Containers (VIC), которая позволяет работать с инфраструктурой виртуализованных приложений Docker на базе существующей виртуальной инфраструктуры VMware vSphere.

Начнем обзор технологии VIC вот с этого видео, в котором показано, как поднять nginx на Photon OS:

Ключевым понятием инфраструктуры контейнеров является VCH - Virtual Container Host. На самом деле это не хост, а виртуальный объект, состоящий из ресурсов ресурсного пула (Resource Pool) VMware vSphere или кластера хостов ESXi целиком. Это позволяет создавать контейнеры в нескольких доменах в рамках одного или нескольких VCH (например, Production, Staging и Test).

Каждый VCH обслуживает собственный кэш образов, которые загружаются из публичного хаба Docker или из частных репозиториев. Файловые системы ВМ в контейнерах размещаются в виртуальных дисках VMDK, которые уже лежат на обычных VMFS-хранилищах.

Само управление инфраструктурой VIC происходит через плагин к vSphere Web Client. Также есть интерфейс командной строки и PowerCLI. Вот, например, процесс создания VCH:

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

Photon Controller использует механизм VMFork (сейчас эта технология называется VMware Instant Clone и доступна в vSphere 6) для создания мгновенных экземпляров виртуальных машин на базе Photon OS (за менее, чем 1 секунду) с нужным приложением по запросу от пользователя.

То есть, на базе Photon OS развертывается новая машина через VMFork, а в ней уже тянется контейнер из нужного репозитория.

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

Также для контейнеров мапятся стандартные команды, которые доступны для виртуальных машин (Power Off / Power On). Например, если мы выключим виртуальный контейнер, это будет означать, что виртуальную машину с контейнером на борту мы удалили.

vSphere Integrated Containers на данный момент находятся в статусе Technology Preview, об их доступности будет сообщено дополнительно.

Возможно не все из вас в курсе, что есть такая полезная и бесплатная утилита как vSphere Configuration Backup, которая позволяет просто и через GUI настроить резервное копирование и восстановление конфигурации серверов VMware ESXi и баз данных SQL.

Возможности утилиты:

• Автоматическое резервное копирование конфигов серверов ESXi 4, 5 и 6 (протестировано vSphere 4.1, 5.0, 5.1, 5.5, 6).
• Резервное копирование любой локальной базы данных и ее конфигурации.
• Управление точками восстановления и удаление устаревших бэкапов (только для бэкапов ESXi).
• Для всего бэкапа конфига ESXi создается только один файл.
• В имени архива бэкапа указан номер билда ESXi.
• Сжимает резервные копии конфигурации ESXi для экономии места на диске.
• Не требует установки.
• Шифрует пароли.
• Конфигурируется из GUI через Configuration Manager.exe.

Как пользоваться vSphere Configuration Backup:

• Запускаем "Configuration manager.exe" для настройки параметров.
• Добавляем хосты ESXi (добавлять vCenter нельзя).
• Выбираем БД SQL Server для резервного копирования.
• Устанавливаем папку для бэкапов и политику хранения резервных копий (сколько хранить и когда удалять).
• Создаем таску планировщика для запуска "ESXi Configuration Backup.exe".

Скачать vSphere Configuration Backup можно по этой ссылке.

Для тех из вас, кто не читает ИТ-новости, спешим рассказать о том, что компания Dell (непубличная компания, между прочим) приобрела компанию EMC вместе со всеми ее активами, а значит и компанией VMware (у EMC 80% акций VMware). Сумма сделки составила 67 000 000 000 долларов (крупнейшая ИТ-сделка M&A за всю историю). В результате поглощения будет образована объединенная под брэндом Dell компания с годовым оборотом 90 миллиардов долларов. Поглощение планируется завершить до февраля 2017 года.

Акции EMC были оценены в $33,15 за штуку. Dell заплатит $24,05 за акцию наличными, а также и предоставит акционерам EMC специальный пакет акций, цена которых привязана к стоимости части принадлежащих EMC акций VMware. Майкл Делл уже заявил, что «Объединение EMC и Dell образует мощный генератор корпоративных решений». Открытое письмо Майкла можно почитать по этой ссылке.

Картинка в стиле "спасибо за игру":

Несмотря на то, что EMC еще может принять предложение одного из участников рынка (штраф от разрыва соглашения с Dell будет минимальным), вряд ли кто-то предложит более выгодные условия, чем Dell (да и мало у кого есть столько кэша, разве что у Cisco). Кстати, пишут, что Dell одолжила у Microsoft $2 млрд., чтобы финализировать сделку.

Интересно, останется ли EMC как брэнд или уйдет из жизни, как это произошло с Sun Microsystems? Открытым также остается вопрос о том, что будет с некоторыми продуктами и инициативами VMware, например, с публичным облаком vCloud Air, поскольку Dell очень тесно сотрудничает с Microsoft в плане облачных вычислений, в частности работает над Microsoft Azure Pack. Не зря же Microsoft одолжила деньги на эту покупку:)

Также возникают такие вопросы: что станет с инициативой EMC и Cisco под брэндом VCE? Что насчет недавно анонсированного партнерства Dell и Nutanix и конкурирующей с ним архитектуры VMware EVO:SDDC? 

На данный момент предполагается, что VMware останется независимой публичной компанией (по принципу laissez-faire). Стоимость её акций после анонса сделки почти не изменилась - акции торгуются на уровне $78,65 (плюс-минус 10% - это нормальная волатильность в таких случаях).

Кстати, на фоне анонса этой сделки компания VMware опубликовала предварительные финансовые итоги третьего квартала 2015 года. По сравнению с прошлым годом VMware увеличила выручку на 10%, которая теперь составила $1,672 млрд. долларов. На фоне падения интереса к технологиям виртуализации результат весьма и весьма неплохой.

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

Раньше это приходилось выполнять путем загрузки из какого-нибудь Linux LiveCD, которому презентован данный том, и там удалять его данные и разделы. А в VMware vSphere 6 Update 1 появился более простой способ - теперь эта процедура доступна из графического интерфейса vSphere Web Client в разделе Manage->Storage Adapters:

Теперь просто выбираем нужный адаптер подсистемы хранения и нажимаем Erase для удаления логических томов устройства (будут удалены все логические тома данного устройства):

Теперь можно использовать этот локальный диск по другому назначению, например, отдать кластеру VSAN.

Ну и также отметим, что в следующей версии утилиты ESXi Embedded Host Client компания VMware сделает возможность не только удаления таблицы разделов, но и добавит средства их редактирования:

Многие из вас в курсе, что решение StarWind Virtual SAN обеспечивает лучшую в отрасли защиту виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V за счет создания стабильно работающего отказоустойчивого кластера хранилищ. Напомним, что о новых возможностях последней версии продукта StarWind Virtual SAN v8 можно прочитать здесь.

Компания StarWind часто подает решение Virtual SAN на соискание различных премий, и этот год - не исключение. Совсем недавно решение Virtual SAN было выбрано финалистом премии SVC Award. Напомним, что год назад этот продукт занял второе место в рамках этой награды.

В этом году ваш голос просто обязан привести StarWind к победе! Голосуйте за StarWind Virtual SAN:

Проголосовать можно до 13 ноября. Искренне желаем нашим коллегам в этом году взять первую премию!

Мы часто рассказываем о решении vGate R2 от компании Код Безопасности, предназначенном для защиты виртуальной инфраструктуры VMware vSphere и Microsoft Hyper-V от несанкционированного доступа, а также для ее безопасной настройки средствами политик.

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

Компания «Код Безопасности», российский разработчик программных и аппаратных средств защиты, сообщает о реализации проекта по внедрению средства защиты vGate в центре обработки данных (ЦОД) «Электронного правительства» Ленинградской области.

Заказчиком проекта выступил Комитет по телекоммуникациям и информатизации Ленинградской области; работы по внедрению продукта осуществлялись при участии специалистов ГКУ ЛО «Оператор электронного правительства». Поставка средства защиты информации vGate была реализована партнером «Кода Безопасности» в Северо-Западном федеральном округе – Группой компаний SuperWave.

Центр обработки данных правительства Ленинградской области представляет собой виртуализированный кластер, построенный на современной платформе VMware vSphere. В ЦОДе функционируют различные информационные системы исполнительных органов государственной власти Ленобласти, в том числе портал государственных и муниципальных услуг, система обеспечения деятельности региональных МФЦ, бухгалтерские и учетные системы, системы ЭДО, базы данных CRM-систем и пр. В этих государственных информационных системах хранятся и обрабатываются персональные данные и другая конфиденциальная информация. vGate R2 обеспечивает сертифицированную защиту этой информации и позволяет привести виртуальную инфраструктуру в соответствие требованиям приказов ФСТЭК России № 17 и № 21 и подготовить систему к прохождению аттестации.

«Перед началом проекта был сформирован список основных требований к системе защиты ЦОДа правительства Ленинградской области. Мы искали решение, которое сертифицировано по требованиям ФСТЭК России, поддерживает работу с платформой VMware, реализует защиту исключительно программными средствами, имеет развитый функционал и различные механизмы обеспечения безопасности в виртуальной инфраструктуре. vGate оказался единственным решением, удовлетворяющим всем нашим требованиям» – рассказал директор ГКУ ЛО «ОЭП», Кораблев Михаил Анатольевич.

Более подробно узнать о продукте vGate R2 и скачать его актуальную версию можно по этой ссылке.

Компания «ИТ-ГРАД», первый VMware IaaS-провайдер на территории СНГ, открывает свое представительство в Алматы. Вслед за открытием Казахстанского офиса запланирован запуск облачного центра обработки данных, отвечающего международным стандартам надежности и требованиям законодательства Казахстана. Облачный дата-центр позволит разместить в облаке бизнес-приложения, воспользоваться облачным резервным копированием и другими услугами «ИТ-ГРАДа».

Ориентируясь на высокие требования заказчиков по обеспечению доступности хранимых данных, компания ИТ-ГРАД строит облачную инфраструктуру по принципу отсутствия единой точки отказа. При этом в качестве площадки для размещения выбираются только надежные дата-центры, категории не ниже Tier III в соответствии с требованиями Uptime Institute.

Услуги «ИТ-ГРАДа» пользуются высоким спросом в России и за ее пределами. В Казахстане будут представлены наиболее популярные облачные сервисы. На базе открывающейся облачной площадки заказчики смогут воспользоваться следующими услугами на территории Казахстана:

• Аренда виртуальной инфраструктуры (IaaS) – позволяет заказчику перенести собственные серверы в виртуальный дата-центр в облаке «ИТ-ГРАДа», тем самым снизив затраты на поддержку и обслуживание информационных систем.
• Резервная площадка (DRS) – позволяет организовать площадку для аварийного восстановления ИТ-инфраструктуры заказчика в облачной среде. В первую очередь решение предназначено для компаний с собственной виртуальной инфраструктурой, либо планирующих использовать технологии виртуализации VMware vSphere.
• Резервное копирование в облако (BaaS) — «ИТ-ГРАД» предлагает своим клиентам подключить свою инфраструктуру к облачному корпоративному решению для резервного копирования с возможностью восстановления данных в том числе в облако. Используются продукты и технологии компаний CommVault и Veeam.

Более подробно с услугами компании ИТ-ГРАД можно ознакомиться на этой странице.

Как вы знаете, некоторое время назад компания VMware выпустила обновление платформы виртуализации vSphere 6 Update 1. После его выхода компания Veeam предупредила пользователей, что средство резервного копирования виртуальных машин Veeam Backup & Replication 8.0 пока не поддерживает последнее обновление от VMware. И вот на днях вышел Veeam Backup & Replication 8.0 Update 3 с полной поддержкой vSphere 6 Update 1. Так что большинство пользователей платформы ESXi может смело обновлять свою инфраструктуру.

Посмотрим на все новые возможности последнего обновления Veeam B&R:

Улучшения для Microsoft Windows:

• Поддержка Windows 10 в качестве гостевой ОС (включая обработку приложений - application-aware processing).
• Поддержка установки Veeam Backup & Replication и всех его компонентов на Windows 10.

Улучшения для VMware vSphere:

• Поддержка vSphere 6.0 Update 1.
• Возможность превратить предупреждение "VMware Tools not found" в информационное сообщение. Для этого параметр DisableVMwareToolsNotFoundWarning (REG_DWORD) в реестре нужно установить в значение 1.

Улучшения для Linux:

• Поддержка SSH-шифрования: aes128-ctr, aes192-ctr, aes256-ctr, aes192-cbc и aes256-cbc.

Новое у Veeam Explorer for Microsoft SQL Server:

• Лог транзакций для неподдерживаемых экземпляров SQL Server автоматически игнорируется, чтобы избежать сообщений об ошибке.
• Предпочитаемые сетевые настройки также применяются к задачам бэкапа транзакционного лога.

Новое у Veeam Explorer for SharePoint:

• Поддержка аутентификации ADFS
• Поддержка UPN credentials.

Улучшения SureBackup

• Модуль Proxy appliance теперь отвечает на пинг внутри виртуальной лаборатории (Virtual Lab), чтобы сетевые экраны не блокировали автоматически ее сеть как публичную.

Другое:

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

Скачать Veeam Backup & Replication 8.0 Update 3 можно по этой ссылке (нужно залогиниться).

Несколько лет назад мы писали про политики сложности паролей в VMware vSphere, которые определяют, какой пароль можно установить для пользователей ESXi. Аутентификация на ESXi реализуется с помощью подключаемых модулей аутентификации (Pluggable Authentication Modules, PAM), которые обладают различными возможностями, такими как интеграция с Active Directory, большая устойчивость к подбору пароля и дополнительные возможности (например, задание сложности пароля для различных классов символов).

Разберем сначала структуру политики сложности пароля:

retry=3 min=N0,N1,N2,N3,N4

• retry=3 - допустимое число попыток ввода пароля.
• N0 - минимальная длина пароля, который имеет только символы из класса 1 (это символы букв в нижнем регистре - например, abc).
• N1 - это минимальная длина пароля, который обязательно имеет символы из двух классов (классы 1,2 и 3 - это символы букв в нижнем и верхнем регистре, а также цифры - например, abcABC).
• N2 - пароли, имеющие в составе слова, должны быть длиной не менее 8 символов. Например, vmwareee.
• N3 - это минимальная длина пароля, который обязательно имеет символы из классов 1, 2 и 3 (это буквы в нижнем и верхнем регистрах, а также цифры - например, abcABC123).
• N4 - это минимальная длина пароля, который обязательно имеет символы из классов 1, 2, 3 и 4 (это буквы в нижнем и верхнем регистрах, а также цифры и спецсимволы - например, abcABC123!).

Напомним политики паролей, которые были в VMware ESXi 5.x:

ESXi 5: retry=3 min=8,8,8,7,6

Это значит, что можно было:

• Задать пароль длиной в 8 символов из первого класса, например: thsmypwd
• Задать пароль длиной в 8 символов из первого и второго класса, например: thsmypwD
• Задать пароль из 8 символов, содержащем слово, например: vmwareee
• Задать пароль длиной в 7 символов из первого, второго и третьего класса, например: VMware1
• Задать пароль длиной в 6 символов из первого, второго и третьего класса, например: Vare1!

В VMware ESXi 6 политика сложности пароля была еще усложнена и теперь является такой:

retry=3 min=disabled,disabled,disabled,7,7

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

Но самое интересно, что политики сложности пароля ESXi теперь можно редактировать не в PAM-файлах сервисной консоли, а в расширенных настройках хоста в разделе Security (картинка кликабельна):

То есть, просто меняете параметр Security.PasswordQualityControl и перезагружаете хост ESXi.

Для массового изменения политик сложностей пароля можно использовать следующий PowerCLI-скрипт:

$PasswordPolicy = "retry=3 min=8,8,8,7,6"
$VMHosts = Get-VMHost | Where { $_.ConnectionState -eq "Connected" }
foreach ($VMHost in $VMHosts)
{
$VMHosts | Get-AdvancedSetting -Name "Security.PasswordQualityControl" | Set-AdvancedSetting -Value $PasswordPolicy -Confirm:$false
}

Спустя весьма продолжительное время с момента релиза новой версии платформы vSphere 6.0, компания VMware выпустила обновленную версию статьи базы знаний KB 2131180, в которой приведена схема со всеми портами и соединениями, используемыми в виртуальной инфраструктуре.

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

В конце прошлой недели компания Citrix выпустила обновления для своих флагманских продуктов - Feature Pack 3 for XenApp and XenDesktop 7.6. Напомним, что о новых возможностях новых версий этих решений мы писали вот тут.

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

Новые возможности Feature Pack 3 for XenApp and XenDesktop 7.6:

• Новый Windows Workstation Virtual Delivery Agent (VDA), который упрощает развертывание новых ПК (в том числе, на базе Windows 10), а также их миграцию на Windows 10.
• Citrix Receiver for Windows 10 - новая версия ПО для доступа к опубликованным приложениям XenApp/XenDesktop.
• Новая версия Citrix AppDNA 7.6.5 - средства, упрощающего миграцию на Windows 10 путем виртуализации физически установленных у пользователей приложений.
• Существенные улучшения производительности, в том числе технологии Thinwire, отвечающей за отображение пользовательского окружения на тонких клиентах.
• Улучшенные шаблоны HDX Policy Templates, касающиеся настроек доставки пользователям интерфейса приложений и десктопов. Также доступны новые наборы преконфигурированных шаблонов.
• Улучшения Universal Print Server, который теперь доступен и для Windows Server 2012 R2, а также поддержка клиентов Windows 10.
• Аутентификация по смарт-картам стала работать на 25% быстрее.
• Появилась политика Restrict Access from Jailbroken Devices, позволяющая предотвращать доступ с джейлбрейкнутых устройств.
• Технология HDX MediaStream может проверять соответствие версий Flash на клиенте и сервере во избежание проблем совместимости.
• Улучшенная поддержка планшетов для рисования (Wacom), включая средства для цифровой подписи контента с помощью смарт-карт.

Также вы можете посетить вебинар What’s New in Feature Pack 3, который пройдет 14 октября.

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

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

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

• VMware vExpert

Это одна из первых программ VMware, которая была учреждена для стимулирования блоггеров и активных участников VMware User Group (VMUG). В 2009 я получил первого vExpert и с тех пор получал каждый год. Сначала пришла папочка из кожзама, потом обещали сумку, но она так и не доехала:) Потом они перестали вообще что-то высылать, а сама награда vExpert утратила былую ценность, так как награждать стали всех подряд. Да и как-то она теперь дается не по году, а по полугодиям, что весьма странно - кому это надо?

• Veeam Vanguard

Это награда от компании Veeam Software, выпускающей лучший продукт для резервного копирования и репликации виртуальных машин Veeam Backup and Replication, а также средство номер 1 для мониторинга и управления различными аспектами виртуальной среды Veeam One. Награда эта появилась только в этом году, но список награжденных уже включает в себя 34 профессионала, которые имеют большой опыт работы с продуктами и технологиям Veeam. И программа Veeam Vanguard для меня лично особенно приятна тем, что в этом году я еду в Лас-Вегас на международную конференцию VeeamOn 2015, где будут все самые значимые профессионалы в сфере виртуализации и защиты данных, а также будет множество интересных новостей и анонсов. Мы будем вести оттуда живую текстовую трансляцию!

• Microsoft MVP

Награде MVP (Most Valuable Professional) уже тысяча лет, наверняка многие из вас знают парочку MVP, с которыми пересекались на конференциях. За вклад в сообщество Microsoft ежегодно награждаются сотни специалистов по всему миру в различных сферах, таких как ASP.Net или SQL Server. По теме платформы виртуализации Hyper-V на данный момент 268 специалистов MVP (из России - 3 человека).

• Nutanix Technology Champion (NTC)

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

• EMC Elect

Это ежегодная награда от EMC за вклад в развитие как программных, так и аппаратных решений компании. Вот тут находится полный список награжденных по результатам прошлого года (из знакомых вам - Антон Жбанков). Номинация на 2016 год пока еще не открыта.

• Cisco Champions

Несмотря на то, что компании Cisco тоже сто лет в обед, программа поощрения технических специалистов Cisco Champions была анонсирована только в 2014 году. Вот тут рассказано о том, за что специалисты получают награду, а вот тут находится их список.

• Citrix Technology Professional (CTP)

Наряду с MVP от Microsoft, CTP от Citrix - одна из старейших наград. Вот здесь можно посмотреть текущий список награжденных. Номинация открыта прямо сейчас и до 30 октября, так что если вы популяризуете Citrix XenApp/XenServer/XenDesktop или другие решения Citrix - попытайте счастья с помощью этой формы.

Компания StarWind Software, известная своим лучшим продуктом для созданиях отказоустойчивых хранилищ для VMware vSphere и Microsoft Hyper-V, на отдельном подсайте сделала доступной базу знаний StarWind Knowledge Base.

Статьи KB разбиты по категориям, по всей базе доступен поиск, к каждой статье есть тэги. На данный момент в базе 41 статья, среди которых есть несколько полезных в плане обучения, например, Logical block size или StarWind LSFS FAQ.

Скачать пробную версию продукта StarWind Virtual SAN можно по этой ссылке.

На днях компания VMware объявила о доступности решения Horizon Mirage 5.5, предназначенного для управления образами корпоративных ПК предприятия в рамках инфраструктуры VMware Horizon, включающей в себя также решение для виртуализации настольных ПК VMware Horizon View.

Напомним, что решение VMware Mirage позволяет создать образ рабочей станции пользователя, разделив его на слои (система, приложения, а также данные и настройки пользователя), а потом централизованно управлять такими образами и деплоить их на конечные физические и виртуальные ПК (подробно мы писали об этом тут). О прошлой версии решения VMware Horizon Mirage 5.2 мы рассказывали в этой заметке.

В этом релизе Mirage компания VMware сделала упор на функциях управления образами с минимальным влиянием на рабочие процессы пользователей. Также стали доступны возможности по самостоятельному развертыванию устройств без необходимости доступа к Mirage Management Console. Теперь администраторы филиалов могут развернуть новый ПК со своего устройства через браузер.

Основные новые возможности VMware Horizon Mirage 5.5:

• Интерфейс самообслуживания для локальных администраторов филиалов для развертывания новых лэптопов и ПК. Делается это через встроенный браузер на основе WinPE.
• Администраторы могут определить базовый слой ОС и приложения только для загрузки (на уровне своего филиала), а запустить обновление вручную в часы наименьшей нагрузки.
• Администраторы могут определить ширину полосы пропускания в зависимости от времени суток и дня (рабочий/выходные). Это снижает трафик загрузок образов в пиковые часы.
• Обновление слоев ОС и приложений возможно через интерфейсы Mirage API и Mirage PowerCLI.
• Развертывание на устройства без ОС поддерживает стандарт POSReady 2009.

Улучшения продукта:

• Можно удалять слои Mirage, используя Mirage Web console, даже если слои назначены активным или архивным CVD (centralized virtual desktop).
• Возможность сохранения статической IP и DNS-конфигурации при миграции ОС, развертывании нового ПК или его восстановления.
• При валидации слоя Microsoft Office выводится информация о конфликтующих компонентах.
• Функции управления устройствами, на которых есть McAfee Data Loss Prevention Endpoint (DLP), включая операции миграции, развертывания и восстановления.
• Использование MongoDB для хранения системных данных и маленьких файлов.
• Файлы базы данных MongoDB могут управляться отдельно от томов Mirage.
• Если на диске, где находится MongoDB, осталось мало места - администратор оповещается об этом.

Улучшения Mirage Web Console:

• Через веб-консоль можно редактировать следующие настройки:
  • Просмотр и управление лицензиями
  • Импорт USMT
  • Настройки файлового портала
  • Возможность автосоздания CVD
  • Аутентификация шлюза
• Возможность "провалиться" при просмотре назначения CVD, которые являются частью коллекции или задачи.
• Управление серверами Mirage и Mirage Gateway.

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

Мы уже писали о новой версии решения VMware Virtual SAN 6.1, предназначенной для создания отказоустойчивых хранилищ на платформе VMware vSphere. После того, как издания "hybrid" и "all-flash" были переименованы в "standard" и "advanced" соответственно, у пользователей появилось несколько вопросов о функциональности этих изданий.

Начнем с того, что в целом все осталось как было:

Итак, мы видим, что отличий у изданий Standard и Advanced теперь два:

• Для конфигураций только из SSD-дисков серверов можно использовать только издание Advanced.
• Для "растянутых" кластеров также можно использовать только издание Advanced. Но тут есть нюанс - растянутым кластером можно считать географически разнесенные площадки (на уровне двух разных зданий). Если у вас кластер на уровне стоек в двух серверных или на разных этажах - растянутым он не считается.

Также появилось издание VSAN for ROBO (remote or branch offices). Это издание позволяет использовать решение VSAN компаниям имеющую сеть небольших филиалов, где нет большого числа хостов ESXi. Для такой лицензии можно запустить не более 25 виртуальных машин в рамках филиала и одной ROBO-лицензии.

Здесь кластеры строятся на уровне каждого из филиалов, а witness-компонент (виртуальный модуль, следящий за состоянием кластера) располагается в инфраструктуре центрального офиса. Причем на каждый кластер VSAN нужно по отдельному witness'у. Этот самый witness позволяет построить кластер на базе всего двух узлов, а не трех, так как он следит за ситуацией split brain в кластере. Это позволяет удешевить решение для филиала, использовав для инфраструктуры из 25 машин всего 2 сервера. Более подробно о ROBO-сценарии написано вот тут.

А вот как выглядит настройка ROBO-издания Virtual SAN:

Ну и, само собой, ROBO-сценарии можно реализовывать по своему усмотрению на лицензиях Standard или Advanced.

На прошедшей конференции VMworld 2015 компания VMware анонсировала программно-аппаратную архитектуру VMware EVO SDDC, которая пришла на смену архитектуре EVO:RACK, которая, в свою очередь, была продолжателем подхода EVO:RAIL, о котором мы уже писали вот тут. SDDC - это концепция Software-Defined Data Center, то есть программно определяемый датацентр, где все физические ресурсы виртуализованы, абстрагированы от оборудования (то есть администратор оперирует логическими сущностями) и управляются из одной точки с помощью специализированного программного обеспечения.

Эта архитектура позволяет вендорам аппаратного обеспечения и OEM-партнерам VMware поставлять интегрированные законченные решения для создания виртуальной инфраструктуры в виде готовых к эксплуатации стоек с оборудованием и развернутым на нем программным обеспечением. На данный момент договоры уже подписаны с Dell, VCE и Quanta (они начнут поставки в первой половине 2016 года), другие вендоры также вскоре объявят о сотрудничестве с VMware.

Такой подход позволяет создать новую инфраструктуру или включить дополнительные ресурсы в уже существующую буквально за несколько часов. Ключевым компонентом такой инфраструктуры является средство управления EVO SDDC Manager. Инфраструктура под управлением EVO SDDC Manager является гиперконвергентной (hyper-converged infrastructure, HCI), то есть все ресурсы виртуализованы (серверы, хранилища и сети), находятся под управлением единого средства и управляются из одной точки.

С точки зрения аппаратного обеспечения, типовой базовый блок VMware EVO SDDC включает в себя 8 серверов, пару коммутаторов 10 Gbit Ethernet, один коммутатор управления и пару 40 Gbit spine-коммутаторов с 32 портами для связи между стойками. Все это уже полностью собрано, скоммутировано и настроено.

Полностью настроенный блок EVO SDDC из 24 серверов в максимальной конфигурации позволяет запустить в облаке предприятия или сервис-провайдера IaaS более 1000 виртуальных серверов или более 2000 виртуальных ПК:

А где же система хранения? - спросит вы. А ее тут нет, все хранение виртуальных машин осуществляется на базе локальных дисков серверов, объединенных в единое пространство хранения с помощью решения VMware Virtual SAN.

С точки зрения программного обеспечения, EVO SDDC включает в себя следующие компоненты:

• VMware vSphere
• VMware NSX
• VMware Virtual SAN
• VMware vRealize Operations
• VMware vRealize Log Insight
• VMware vRealize Automation (опционально)
• VMware Horizon Suite (если стойка используется для виртуальных ПК)

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

Вот так выглядит рабочий процесс путешествия стойки от партнера к клиенту и ее ввод в эксплуатацию:

Более подробно об архитектуре VMware EVO SDDC можно узнать из этого документа.

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

Давайте посмотрим, как же технология VVols влияет на процесс резервного копирования виртуальных машин, например, с помощью основного продукта для бэкапа ВМ Veeam Backup and Replication, который полностью поддерживает VVols. Для начала рассмотрим основные способы резервного копирования, которые есть в виртуальной среде:

• Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
• Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
• Резервное копирование по сети SAN (SAN-to-SAN backup) - в этом случае на выделенном сервере (Backup Server) через специальный механизм Virtual Disk API происходит снятие снапшота ВМ без задействования хоста ESXi и бэкап машины на целевое хранилище напрямую в сети SAN без задействования среды Ethernet.

Последний способ - самый быстрый и эффективный, но он требует наличия специальных интерфейсов (vSphere APIs и Virtual Disk Development Kit, VDDK), которые должны присутствовать на выделенном сервере.

К сожалению, для VVols способ резервного копирования по сети SAN еще не поддерживается, так как данный механизм для прямой работы с хранилищами SAN для VVols еще не разработан. Поэтому при работе с VVols придется использовать NBD backup. Однако не расстраивайтесь - большинство компаний именно его и используют для резервного копирования машин на томах VMFS в силу различных причин.

Работа хоста VMware ESXi с томами виртуальной машины VVols выглядит следующим образом:

Для процессинга операций используется Protocol Endpoint (PE), который представляет собой специальный административный LUN на хранилище. PE работает с лунами машин (VVols), которые представлены через secondary LUN ID, а VASA Provider со стороны дискового массива снабжает vCenter информацией о саблунах виртуальных машин, чтобы хост ESXi мог с ними работать через PE.

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

Вернемся к процессу резервного копирования. Как известно, он опирается на механизм работы снапшотов (Snapshots) - перед снятием резервной копии у ВМ делается снапшот, который позволяет перевести базовый диск в Read Only, а изменения писать в дельта-диск снапшота. Далее базовый диск ВМ копируется бэкап-сервером, ну а после того, как базовый диск скопирован, снапшот склеивается с основным диском, возвращая диски машины обратно в консолидированное состояние.

Так это работает для файловой системы VMFS, которая развертывается поверх LUN дискового массива. Сами понимаете, что при интенсивной нагрузке во время резервного копирования (особенно больших виртуальных дисков) с момента снятия снапшота может пройти довольно много времени. Поэтому в дельта-дисках может накопиться много данных, и процесс консолидации снапшота на практике иногда занимает часы!

Для виртуальных томов VVols все работает несколько иначе. Давайте взглянем на видео:

В среде VVols при снятии снапшота базовый диск остается режиме Read/Write (это все делает массив), то есть контекст записи данных никуда не переключается, и изменения пишутся в базовый диск. В снапшоты (это отдельные тома VVol) пишется только информация об изменениях базового диска (какие дисковые блоки были изменены с момента снятия снапшота).

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

Такой рабочий процесс несколько увеличивает время создания снапшота в среде VVols:

Но это всего лишь десятки секунд разницы. А вот время консолидации снапшота по окончанию резервного копирования уменьшается во много раз:

Как следствие, мы имеем уменьшение совокупного времени резервного копирования до 30%:

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

Компании Veeam Software и StarWind Software проведут совместный вебинар "Building a better backup solution", посвященный построению надежной отказоустойчивой инфраструктуры хранилищ и резервного копирования виртуальных машин.

Вебинар пройдет 13 октября в 21-00 по московскому времени. Зарегистрируйтесь бесплатно!

На вебинаре вы узнаете:

• Что такое качественное решение для резервного копирования
• Как эффективно сбалансировать производительность и цену решения
• Каковы сегодня лучшие практики резервного копирования
• Как StarWind и Veeam работают вместе для создания целостного решения для хранения и защиты данных

Регистрация на вебинар.

Интересный пост, касающийся поддержки VMware Tools в смешнном окружении, опубликовали на блогах VMware. Если вы взглянете на папку productLocker в ESXi, то увидите там 2 подпапки /vmtools и /floppies:

Это файлы, относящиеся к пакету VMware Tools, устанавливаемому в гостевые ОС виртуальных машин. Перейдем в папку /vmtools:

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

В папке floppies находятся виртуальные образы дискет, которые могут понадобиться для специфических гостевых ОС при установке драйверов (например, драйвер устройства Paravirtual SCSI):

Интересно, что папка productLocker занимает примерно 150 МБ, что составляет где-то половину от размера установки VMware ESXi. Именно поэтому рекомендуют использовать образ ESXi без VMware Tools ("no-tools") при использовании механизма Auto Deploy для массового развертывания хост-серверов.

Самая соль в том, что версия пакета VMware Tools на каждом хосте разная и зависит от версии VMware ESXi. Например, мы поставили на хосте VMware vSphere 5.5 виртуальную машину и установили в ней тулзы. Консоль vCenter покажет нам, что установлена последняя версия VMware Tools:

Однако если у нас смешанная инфраструктура (то есть, состоит их хостов разных версий), то при перемещении машины на хост с более высокой версией, например, vSphere 5.5 Update 2/3, она будет показана как ВМ с устаревшей версией пакета (VMware Tools: Running (Out-of-Date):

Поэтому возникает некоторая проблема в смешанной среде, которую можно решить очень просто - как правило VMware Tools от хоста с большей версией подходят ко всем предыдущим. Например, тулзы от vSphere 6.0 подойдут ко всем хостам до ESXi 4.0 включительно. vSphere 6 Update 1 выпадает из списка (постепенно поддержка старых версий уходит):

Таким образом, лучше всего распространить тулзы от vSphere 6 на все хосты вашей виртуальной инфраструктуры. Для этого создадим общий для всех хостов датастор SDT и через PowerCLI проверим, что к нему имеет доступ несколько хостов, командой:

Get-Datastore | where {$_.ExtensionData.summary.MultipleHostAccess -eq “true”}

Далее создадим на этом датасторе папку productLocker:

в которую положим VMware Tools от ESXi 6.0:

Далее нужно пойти в раздел:

Manage > Settings > Advanced System Settings > UserVars.ProductLockerLocation

и вбить туда путь к общей папке, в нашем случае такой:

/vmfs/volumes/SDT/productLocker

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

Get-VMhost -Location <cluster name> | Set-VMHostAdvancedConfiguration -Name "UserVars.ProductLockerLocation" -Value "/vmfs/volumes/SDT/productLocker"

Теперь для применения настроек есть два пути: первый - это перезапустить хост ESXi, но если вы этого сделать не можете, то есть и второй путь - выполнить несколько команд по SSH.

Зайдем на хост ESXi через PuTTY и перейдем в папку с /productLocker командой cd. Вы увидите путь к локальной папке с тулзами на хосте, так как это ярлык:

Удалим этот ярлык:

rm /productLocker

После чего создадим новый ярлык на общую папку на томе VMFS с тулзами от vSphere 6.0:

ln -s /vmfs/volumes/SDT/productLocker /productLocker

Посмотрим, что все смонтировалось, командой ls:

Вот таким вот образом можно поддерживать самую последнюю версию VMware Tools в виртуальных машинах, когда в вашей производственной среде используются различные версии VMware ESXi.

Еще в самом конце августа компания VMware выпустила весьма достойный внимания документ "VMware vCenter Server Performance and Best Practices", рассказывающий о лучших практиках по использованию сервера vCenter версии 6 в контексте производительности. Напомним, что ранее мы уже писали про еще один документ о vCenter - "VMware vCenter Server 6.0 Cluster Performance".

Основные моменты документа:

• vCenter Server 6.0 имеет существенно большую производительность, чем предыдущая версия vCenter Server 5.5. Некоторые операции исполняются почти в 2 раза быстрее, а отображение страниц в Web Client работает на 90% быстрее.
• vCenter Server Appliance работает почти так же быстро, как и полноценный vCenter Server для Windows.
• Ресурсы, выделенные для vCenter (CPU, память, диск и полоса пропускания сети) влияют на размер доступного в vCenter окружения и скорость исполнения операций.
• Используя рекомендации из документа и правильно выделяя ресурсы в зависимости от нагрузки, пользователи могут значительно повысить производительность стандартной конфигурации VMware vCenter.

Скачать документ "VMware vCenter Server Performance and Best Practices" можно по этой ссылке.

Компания Citrix на днях сообщила, что известное многим решение Citrix XenClient Enterprise будет снято с производства (End of Life) - и как продукт, и как технология. То есть, развитие этого клиентского гипервизора полностью прекратится 1 октября 2015 года. Напомним, что мы много писали о XenClient, например, здесь, здесь и здесь.

Еще в 2012 году компания Citrix объвила о покупке конкурирующего клиентского гипервизора NxTop вместе с компанией Virtual Computer, на базе технологий которого и был построен Citrix XenClient Enterprise.

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

Продукт Citrix Synchronizer, обеспечивающий доставку рабочих столов и коммуникацию с виртуальными машинами, запущенными в DesktopPlayer, будет продолжать оставаться доступным как часть решения Citrix XenDesktop.

Сама Citrix в дальнейшем сосредоточится на продуктах XenApp и XenDesktop, а также мобильных решениях.

Недавно Cormac Hogan написал интересный пост о том, как нужно настраивать "растянутый" между двумя площадками HA-кластер на платформе VMware vSphere, которая использует отказоустойчивую архитектуру Virtual SAN.

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

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

Откроем настройки кластера HA. Во-первых, он должен быть включен (Turn on vSphere HA), и средства обнаружения сетевых отказов кластера (Host Monitoring) также должны быть включены:

Host Monitoring позволяет хостам кластера обмениваться сигналами доступности (heartbeats) и в случае отказа предпринимать определенные действия с виртуальными машинами отказавшего хоста.

Для того, чтобы виртуальная машина всегда находилась на своей площадке в случае отказа хоста (и использовала локальные копии данных на виртуальных дисках VMDK), нужно создать Affinity Rules, которые определяют правила перезапуска ВМ на определенных группах хостов в рамках соответствующей площадки. При этом эти правила должны быть "Soft" (так называемые should rules), то есть они будут соблюдаться при возможности, но при отказе всей площадки они будут нарушены, чтобы запустить машины на резервном сайте.

Далее переходим к настройке "Host Hardware Monitoring - VM Component Protection":

На данный момент кластер VSAN не поддерживает VMCP (VM Component Protection), поэтому данную настройку надо оставить выключенной. Напомним, что VMCP - это новая функция VMware vSphere 6.0, которая позволяет восстанавливать виртуальные машины на хранилищах, которые попали в состояние All Paths Down (APD) или Permanent Device Loss (PDL). Соответственно, все что касается APD и PDL будет выставлено в Disabled:

Теперь посмотрим на картинку выше - следующей опцией идет Virtual Machine Monitoring - механизм, перезапускающий виртуальную машину в случае отсутствия сигналов от VMware Tools. Ее можно использовать или нет по вашему усмотрению - оба варианта полностью поддерживаются.

На этой же кариинке мы видим настройки Host Isolation и Responce for Host Isolation - это действие, которое будет предпринято в случае, если хост обнаруживает себя изолированным от основной сети управления. Тут VMware однозначно рекомендует выставить действие "Power off and restart VMs", чтобы в случае отделения хоста от основной сети он самостоятельно погасил виртуальные машины, а мастер-хост кластера HA дал команду на ее восстановление на одном из полноценных хостов.

Далее идут настройки Admission Control:

Здесь VMware настоятельно рекомендует использовать Admission Control по простой причине - для растянутых кластеров характерно требование самого высокого уровня доступности (для этого он, как правило, и создается), поэтому логично гарантировать ресурсы для запуска виртуальных машин в случае отказа всей площадки. То есть правильно было бы зарезервировать 50% ресурсов по памяти и процессору. Но можно и не гарантировать прям все 100% ресурсов в случае сбоя, поэтому можно здесь поставить 30-50%, в зависимости от требований и условий работы ваших рабочих нагрузок в виртуальных машинах.

Далее идет настройка Datastore for Heartbeating:

Тут все просто - кластер Virtual SAN не поддерживает использование Datastore for Heartbeating, но такого варианта тут нет :) Поэтому надо выставить вариант "Use datastores only from the secified list" и ничего из списка не выбирать (убедиться, что ничего не выбрано). В этом случае вы получите сообщение "number of vSphere HA heartbeat datastore for this host is 0, which is less than required:2".

Убрать его можно по инструкции в KB 2004739, установив расширенную настройку кластера das.ignoreInsufficientHbDatastore = true.

Далее нужно обязательно установить кое-какие Advanced Options. Так как кластер у нас растянутый, то для обнаружения наступления события изоляции нужно использовать как минимум 2 адреса - по одному на каждой площадке, поэтому расширенная настройка das.usedefaultisolationaddress должна быть установлена в значение false. Ну и нужно добавить IP-адреса хостов, которые будут пинговаться на наступление изоляции хост-серверов VMware ESXi - это настройки das.isolationaddress0 и das.isolationaddress1.

Таким образом мы получаем следующие рекомендуемые настройки растянутого кластера HA совместно с кластером Virtual SAN:

Ну и должны быть добавлены следующие Advanced Settings:

Более подробно об этом всем написано в документе "Virtual SAN 6.1 Stretched Cluster Guide".

Несколько дней назад компания VMware обновила решение Horizon FLEX до версии 1.6. Напомним, что FLEX представляет собой платформу виртуализации для настольных ПК, позволяющую запускать виртуальные ПК локально (как на Mac во Fusion, так и на Windows в Workstation Player), без требования связи с датацентром компании.

Основные фичи новой версии решения - готовность к Apple OS X El Capitan и полная поддержка Windows 10 и Cortana.

Список новых функций VMware Horizon FLEX 1.6:

• Использование последних версий VMware Workstation и VMware Fusion в качестве клиентов.
• Поддержка Microsoft Windows 10: и как хостовой ОС, и как гостевой ОС.
• Поддержка Microsoft DirectX 10 и OpenGL 3.3 для гостевых ОС. Для DirectX обещают прирост производительности до 10 раз, а для OpenGL - "всего лишь" на 65%.
• В виртуальной машине может быть до 16 vCPU, 64 ГБ оперативной памяти, до 8 ТБ дискового пространства и до 2 ГБ видеопамяти.
• Новые машины приостанавливаются и выводятся из suspend'а в 3 раза быстрее, VoIP-звонки через Skype and Lync теперь стали намного лучше.
• Поддержка устройств USB 3.0 для виртуальных машин с Windows 7 (с последним драйвером USB от Intel).
• Возможность добавления инкрементального номера к имени виртуальной машины в Active Directory. Это позволяет пользователю загрузить несколько копий своей виртуальной машины, при этом каждая из них будет присоединена к домену AD. Это особенно полезно для разработчиков.
• Поддержка URL виртуальной машины для назначения прав, что позволяет нескольким группам AD иметь несколько сайтов для загрузки машин.

Обещают, что новая версия полностью готова к Apple OS X El Capitan:

На данный момент попробовать поработать с FLEX в режиме онлайн можно в формате Hands-On Lab по этой ссылке. Скачать VMware Horizon FLEX 1.6 можно здесь.