Новости Статьи VMware Veeam StarWind Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4880 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru | Ссылка дня: Если у вас тормозит VMware Fusion 11, обновитесь - это поможет

Серьезная проблема с виртуальными машинами с включенной Virtualization-Based Security (VBS) на платформе VMware vSphere.

27/05/2019

Начиная с VMware vSphere 6.7, компания VMware поддерживает технологию защищенной виртуализации Virtualization-Based Security (VBS). Это один из механизмов, который позволяет предоставлять пользователям более защищенные рабочие Windows-среды средствами технологий Device Guard и Credential Guard (последняя предназначена для изоляции пространства хранения учетных записей от потенциальной кражи вредоносным ПО). Эти функции очень важны для защиты, например, таких компонентов инфраструктуры, как серверы Active Directory.

Между тем, с виртуальными машинами, работающими с поддержкой данной технологии, была найдена серьезная проблема - они зависают или выпадают в синий экран смерти (BSOD) при загрузке. Баг проявляется при включенной технологии VBS (на скриншоте vSphere Client на базе HTML5 с Hardware Version 14):

Также этот баг актуален и для включенной поддержки технологии I/O MMU:

Возможность VBS доступна в Microsoft Windows 10/2016/2019, сам же баг стал проявляться, начиная с версии Windows Insider Build 18362. VMware говорит, что проблема находится на стороне Microsoft, но оба вендора совместно работают над выпуском патча для ОС.

Статья базы знаний VMware KB 68043 содержит вопросы, которые позволят вам определить, затрагивает ли вас проблема.

Помимо проверки настроек в интерфейсе vSphere Client, которые вы видите на скриншотах выше, можно использовать вот такой PowerCLI-скрипт для определения машин, которые затрагивает проблема:

Get-View -ViewType VirtualMachine | Where {(($_.Config.Flags.VbsEnabled -eq "True") -or ($_.Config.Flags.VvtdEnabled -eq "True")) -and ($_.Summary.Config.GuestID -like "windows9*")} | Select Name,@{Name=”VBS”; Expression={$_.Config.Flags.VbsEnabled}},@{Name=”IOMMU”; Expression={$_.Config.Flags.VvtdEnabled}}

После того, как вы найдете у себя такие ВМ, то выхода у вас два:

  • Не использовать VBS и I/O MMU для виртуальных машин.
  • Использовать workaround, который приведен в статье KB 68043.

Workaround заключается в следующем:

  • Выключаем машину и отключаем VBS и I/O MMU для нее.
  • Устанавливаем ОС на ВМ или обновляем ее до самых последних апдейтов.
  • Выключаем ВМ, выбираем в настройках "Expose hardware assisted virtualization to guest".
  • Включаем ВМ, в настройках включаем функцию (feature) "Hyper-V" в гостевой ОС, после чего перезагружаем машину.
  • Опять выключаем ВМ и включаем VBS и/или I/O MMU, после чего она уже будет нормально работать.

Помните, что такой Workaround не вечен для свежих установок, например, из образов 1903 & 19H1 DVD/ISO, так как следующее обновление потенциально может вернуть баг, который еще не пофикшен со стороны Microsoft. Имейте это в виду, когда создаете шаблоны виртуальных машин для массового развертывания. Поэтому сначала все обновляем до самой последней версии, потом уже используем Workaround выше.

Кстати, все могло бы быть и хуже) Например, уязвимость Remote Desktop Services vulnerability (CVE-2019-0708), требующая немедленного обновления не затрагивает системы с описанной проблемой выпадения в BSOD. Уязвимость с удаленным рабочим столом актуальна только для систем Windows XP, 7, Windows Server 2003, 2008 (+ R2), а баг с зависанием актуален только для более поздних Windows.

Ждем пока сделают нормальный фикс, и не надо будет плясать с Workaround'ом. А пока можете на всякий случай отключить VBS, если позволяют корпоративные политики.

Новая версия VMware Horizon Migration Tool 3.0 для миграции приложений с Citrix XenApp.

24/05/2019

Об утилите Horizon Migration Tool мы уже несколько раз писали, версия 2.3 которой вышла в марте 2017 года. Спустя более чем два года, компания VMware выпустила обновленную версию Horizon Migration Tool 3.0.2, которая стала доступной на сайте проекта VMware Labs.

Напомним, что средство Horizon Migration Tool предназначено для миграции виртуализованных приложений и десктопов с платформы Citrix XenApp на платформу VMware Horizon View. В процессе миграции одна ферма Citrix XenApp переносится в одну или несколько ферм VMware View.

Давайте посмотрим, что нового появилось за 2 года в данной утилите:

  • Поддержка миграции с платформ Citrix на VMware Horizon 7.2.
  • Добавлена возможность миграции пулов десктопов Citrix PVS на платформу Horizon 7.2.
  • Добавлена возможность миграции пула Citrix Dedicate MCS Desktop Pool на платформу Horizon 7.2 как ручного пула (manual pool), пула связанных клонов (linked-clone pool) или пула мгновенных клонов (instant clone pool).
  • Исправлен баг, когда приложения XenApp с кастомными путями, содержащими пробелы, не мигрировались корректно.

Не так уж и много, но хоть что-то. Скачать VMware Horizon Migration Tool 3.0.2 можно по этой ссылке.

Использование механизма Log Intelligence в облаке VMware Cloud on AWS.

23/05/2019

Мы много писали об облачном решении VMware Cloud on AWS, которое было создано усилиями компаний Amazon и VMware.

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

Log Intelligence полностью интегрирован с облаком VMware Cloud on AWS, охватывает всю линейку продуктов VMware и органично дополняет концепцию управления виртуальным датацентром Software-Defined Datacenter (SDDC).

По умолчанию Log Intelligence собирает и анализирует все логи для основных компонентов (vCenter, ESXi, vSAN). Но также в решении есть функция аудита логов сетевого экрана виртуальной инфраструктуры NSX-T, которую можно подключить отдельно:

Для интеграции с NSX-T нужно будет подключить VMware Cloud on AWS Content Pack, который позволит получить информацию о правилах фаервола, правилах обработки пакетов и прочую важную диагностическую информацию для администраторов:

После развертывания можно будет увидеть все исполняемые в среде NSX-T запросы:

Также можно управлять определениями оповещений (Alert Definitions):

Запросы можно сохранить на собственных или общих дэшбордах, а также включить Alert Definitions для отправки webhook во внешнюю систему или письма по электронной почте администратору.

Вот пример двух запросов, сохраненных на дэшборде:

На домашней странице можно видеть сработавшие алерты в виде таймлайна:

Вот так выглядит оповещение в письме администратору:

А так, например, webhook в мессенжер Slack:

Решение Log Intelligence также может перенаправлять логи в другие приемники для специфического анализа (подробнее тут). Поддерживаются следующие точки назначения:

  • Онпремизная инсталляция vRealize Log Insight
  • Онпремизная инсталляция Syslog Server через TCP или UDP
  • Онпремизная инсталляция Splunk
  • Онпремизная отсылка по умолчанию через Authenticated HTTPs
  • Облачный Splunk Cloud Endpoint
  • Облачный Authenticated endpoint через протокол HTTPs

Для отправки логов в собственное онпремизное облако нужно будет развернуть Cloud Proxy:

Для облачного ничего добавлять не нужно:

События логов можно экспортировать в Raw-формате или в структуре JSON:

В общем, Log Intelligence может оказаться вам очень полезным в облаке VMware Cloud on AWS (или в гибридной среде с собственным датацентром), особенно, если ваша инфраструктура содержит десятки хостов ESXi.

Новое на VMware Labs - Distributed Trust Incident Reporting.

22/05/2019

На сайте проекта VMware Labs появилась новая интересная Open Source утилита - Distributed Trust Incident Reporting. Она предназначена для документирования инцидентов в сфере информационной безопасности, которое часто осуществляется на бумаге или в Excel даже в крупных компаниях. Некоторые системы имеют централизованную базу данных инцидентов с возможностью отслеживания ответных мер, принятых в качестве реакции на инцидент, но только на уровне собственного предприятия.

Текущие подходы по мнению VMware обладают рядом недостатков:

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

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

Утилита Distributed Trust Incident Reporting позволяет:

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

Работает это все на базе контейнеров Docker, а технологическую платформу фиксирования инцидентов предоставляют решения VMware blockchain или Ethereum blockchain.

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

Проект Distributed Trust Incident Reporting доступен для скачивания из репозитория GitHub.

Как перейти с обычного VMware Site Recovery Manager под Windows на виртуальный модуль с Photon OS (Virtual Appliance).

21/05/2019

Недавно мы писали о выходе обновленной версии решения для обеспечения катастрофоустойчивости виртуальных датацентров VMware Site Recovery Manager 8.2. Многие пользователи после ее релиза задались вопросом миграции на виртуальный модуль (Virtual Appliance), который построен на базе операционной системы Photon OS и управляется через веб-браузер.

Давайте вкратце рассмотрим этот процесс. В целом процедура миграции выглядит так:

  • Убеждаемся, что ваш SRM на базе Windows обновлен до версии 8.2.
  • Экспортируем конфигурацию и останавливаем SRM на хосте с Windows.
  • Развертываем Site Recovery Manager Virtual Appliance и импортируем туда конфиг.

Пошагово этот процесс будет таким:

1. Логинимся в Site Recovery Manager for Windows, открываем командную строку и переходим в папку %SRM_INSTALL_DIR%\bin.

2. Запускаем следующий скрипт, он потребует ввод пароля администратора:

export-srm-data.bat

3. Экспортированную папку перемещаем на виртуальный модуль SRM.

4. Выключаем машину с SRM для Windows и логинимся как root в SRM VA.

5. Если вы создавали кастомные сертификаты, то их надо положить в папку /etc/ssl/certs (это файлы с расширением .pem). Импортировать сертификаты можно через Site Recovery Manager Appliance Management Interface.

Для изменения прав доступа к сертификатам используйте команду:

chmod a+r <new-root-ca>.pem

Далее выполните:

c_rehash

6. После этого запустите импорт окружения SRM, указав папку, которую вы экспортировали из Windows-окружения:

/opt/vmware/srm/bin/import-srm-data.sh <export_dir>

7. Вас попросят пароль администратора vCenter Single Sign-On, root виртуального модуля, а также пароль от файла, который был задан при экспорте конфигурации.

8. На вкладке Home веб-консоли решения SRM VA выберите импортированную пару сайтов и нажмите Actions > Reconnect. Выберите первый сайт из списка, введите адрес Platform Services Controller сервера SRM на резервной площадке и введите имя пользователя и пароль.

9. Далее вас попросят выбрать сервер vCenter, который нужно настроить и его сервисы, где вы просто нажимаете Next, а потом Finish.

Также весь этот процесс описан вот тут.

Маркетплейс Super Metric Sample Exchange для решения VMware vRealize Operations.

20/05/2019

Недавно мы писали об обновлении продукта для комплексного управления и мониторинга виртуальной инфраструктуры VMware vRealize Operations 7.5. Ранее для этого решения был запущен маркетплейс Dashboard Sample Exchange, где пользователи сообщества vROPs могут публиковать собственные полезные дэшборды (их уже почти 130 штук), которые помогают в ежедневных операциях по управлению платформой VMware vSphere.

Совсем недавно VMware запустила еще один маркетплейс - Super Metric Sample Exchange. В инфраструктуре vROPs суперметрики (super metrics) - это те, которые образованы путем каких-либо комбинаций обычных метрик через математическую формулу (например, какой процент CPU виртуальная машина отъедает от всего хоста ESXi). Для редактирования таких метрик используется super metric editor (подробнее тут):

Чтобы начать работу с маркетплейсом, нужно перейти на сайт vRealize и нажать кнопку View Samples:

В качестве фильтра для языка программирования выберите "vRealize Ops Super Metrics":

Еще один способ найти суперметрики - это пойти на https://code.vmware.com/samples и также выбрать там в фильтре "vRealize Ops Super Metrics":

На выходе будут сэмплы кода для суперметрик (пока их совсем немного):

Можно скачать их в формате JSON, после чего импортировать в разделе vRealize Operations > Administration > Configuration > Super Metrics:

Также вы можете добавлять и собственные суперметрики на маркетплейс. Для этого на картинке выше есть пункт "Export Selected Super Metric". Метрика также будет экспортирована в формате JSON. Для ее загрузки на маркетплейс нужно использовать портал VMware {code}, где вам потребуется завести аккаунт.

Там у вас будет кнопка "Add New Sample":

После этого запустится мастер добавления нового сэмпла, где вы можете выбрать ваш JSON:

Далее нужно добавить максимально понятное и подробное описание созданной вами суперметрики:

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

Бесплатный документ для подготовки к сертификации Veeam - VMCE Study Guide.

17/05/2019

Коллеги Rhys Hammond и Rose Herden выпустили неофициальное бесплатное руководство для подготовки к сертификации VMCE Study Guide (оно было сделано на базе их доклада на VeeamON 2017). Книжку можно скачать бесплатно, если ползунок справа в разделе цены установить на 0 (но можете и пожертвовать сколько-то за скачанный документ, если он вам понравится).

В рецензировании книги принимали участие члены сообщества Veeam Vanguards, которое объединяет технических профессионалов по всему миру, продвигающих технологии Veeam в массы.

Напомним, что компания Veeam Software известна своим главным в отрасли средством для резервного копирования и репликации виртуальных машин Veeam Backup and Replication.

VMCE (Veeam Certified Engineer) - это сертификация для инженеров, которая подтверждает знания и навыки работы с платформой по обеспечению бесперебойного функционирования виртуальных датацентров Veeam Availability Suite V9. Экзамен представляет собой 50 случайных вопросов из базы знаний об этой платформе, для успешной его сдачи нужно ответить правильно на 70% заданий.

Руководство занимает 56 страниц и доступно в форматах PDF и epub. Скачать VMCE Study Guide можно по этой ссылке.

Проверка производительности кластера VMware vSAN с помощью утилиты HCIBench.

16/05/2019

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

HCIBench используется для проведения синтетических тестов кластера хранилищ, когда нагрузка распределяется по нескольким виртуальным машинам на разных хостах ESXi. Генерация операций ввода-вывода происходит одновременно с разных ВМ согласно заранее определенному шаблону нагрузки.

А зачем вообще проводить тестирование кластера vSAN? Тут, как правило, есть следующие причины:

  • Понимание возможностей инфраструктуры хранения и возможность убедиться в том, что в ней нет аномалий.
  • Валидировать дизайн кластера vSAN с точки зрения приемо-сдаточных испытаний (User Acceptance Testing, UAT).
  • Получить референсные значения, с которыми можно будет сверяться при внесении существенных изменений в архитектуру vSAN.
  • Проведение тестов перед внедрением (PoC-проекты).
  • Установление базового уровня пользовательских ожиданий после развертывания приложений.

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

  • Какого наибольшего числа операций ввода-вывода в секунду (IOPS) можно добиться?
  • Какая ожидаемая задержка выполнения операций (latency) при требуемом числе IOPS для рабочей нагрузки?
  • Какая максимальная пропускная способность операций чтения-записи (throughput)?

То есть результаты тестирования держатся на трех китах - IOPS, latency и throughput.

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

IOPS

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

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

Latency

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

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

Throughput

Пропускная способность важна при выполнении больших операций ввода-вывода, а также при различных паттернах чтения записи (последовательный/случайный). Чем больше размер I/O, тем очевидно больше пропускная способность. С точки зрения объема передаваемых данных одна операция I/O размером 256К равна 64 операциям ввода-вывода по 4К, но вот с точки зрения throughput это будут совершенно разные значения, так как займут разное время.

Методология тестирования хорошо описана в документации по HCIBench, а также вот в этой статье на русском языке. Работа с утилитой начинается по ссылке https://<HCIBench IP address>:8443.

Перед началом тестирования можно задать параметры среды - число виртуальных машин для кластера, количество их виртуальных дисков и их размер. Для ленивых есть параметр Easy Run, который позволит автоматически подобрать эту конфигурацию, исходя из размера кластера vSAN и параметров хостов ESXi:

Очень важно при тестировании также задать правильный профиль рабочей нагрузки (4 варианта на картинке выше).

После выполнения теста Easy Run вы получите выходной файл с результатами вроде vdb-8vmdk-100ws-4k-70rdpct-100randompct-4threads-xxxxxxxxxx-res.txt. Из имени файла можно понять использованную тестовую конфигурацию (она также будет в самом файле):

Block size : 4k
Read/Write (%) : 70/30
Random (%) : 100
OIO (per vmdk) : 4

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

Если открыть один их этих файлов, мы увидим детальные параметры производительности различных компонентов среды vSAN:

Полученные параметры можно считать базовым уровнем для тестирования производительности кластера. Теперь нужно увеличивать параллелизм, то есть число тредов Outstanding I/O (OIO), для выжимки оптимальной производительности. Увеличение этого параметра будет увеличивать число IOPS, а также, как следствие, будет расти Latency. Так вы сможете понять, как инфраструктура хранения ведет себя в динамике, реагируя на изменение профиля нагрузки.

Чтобы изменить параметр OIO, нужно отключить Easy Run и в профиле рабочей нагрузки нажать Add:

Также для измерения пропускной способности вы можете поэкспериментировать с размером операции ввода-вывода. Современные ОС поддерживают размер I/O в диапазоне 32K - 1 MB, но для тестирования лучше использовать I/O в диапазоне 32K – 256K.

Еще какие моменты надо учитывать при тестировании:

  • Синтетическое тестирование не учитывает, что профиль рабочей нагрузки в кластере в реальной жизни постоянно изменяется точки зрения соотношения операций чтения и записи и их рандомизации в потоке ввода-вывода. Используемая модель - всего лишь аппроксимация.
  • Тесты ориентированы на отслеживание характеристик хранилищ, а не загрузки CPU и памяти хостов ESXi.

Улучшения планировщика side-channel aware scheduler (SCA) в VMware vSphere 6.7 Update 2.

15/05/2019

Некоторое время назад мы писали о новых возможностях недавно вышедшего обновления платформы виртуализации VMware vSphere Platinum 6.7 Update 2. Cреди новых возможностей гипервизора там есть фича "Новые возможности планировщика CPU помогают бороться с уязвимостями типа L1TF".

Оказывается, это довольно серьезное улучшение. Надо сказать, что планировщик гипервизора side-channel aware scheduler (SCA) появился еще в прошлой версии платформы. Он закрывал уязвимость L1TF (L1 Terminal Fault) в процессорах Intel за счет того, что процессы виртуальных машин запускались только в одном треде одного физического ядра. Это позволяло нивелировать вектор атаки данного типа, но приводило к существенному снижению производительности.

Особенно это чувствовалось, когда сервер ESXi был загружен по CPU полностью, и SCA первой версии в этом случае давал до 30% хуже результат, чем без него. Если же сервер был загружен, например, на 75%, то в производительность оставалась примерно той же, но без SCA нагрузка на CPU была существенно ниже.

Обо всем этом подробно описано в документе "Performance of vSphere 6.7 Scheduling Options":

Давайте вкратце посмотрим, о чем там говорится.

Итак, начиная с VMware vSphere 6.7 Update 2, появился обновленный планировщик SCAv2, который был существенно доработан по сравнению со своей предыдущей версией. Он позволяет исполнять контексты vCPU одной машины в разных гипертредах одного физического ядра процессора хоста. В этом случае атаке L1TF не подвержены взаимодействия типа VM/VM и VM/ESXi (чувствительная информация между ними не шарится в общем кэше).

В документе описано 2 типа тестов, которые проводились для планировщиков SCAv1 и SCAv2: работа хоста под максимальной нагрузкой по процессорам и под нагрузкой на уровне 75% от максимальной мощности всех CPU хоста ESXi (reduced load). В качестве базового уровня использовался планировщик без SCA (он же на картинке ниже обозначен как Default):

Если верить графикам, отражающим результаты тестирования различными бенчмарками, то планировщик SCAv2 работает существенно лучше во всех случаях, кроме очень большой (по выделенным ресурсам) виртуальной машины - Monster VM с базой Oracle и 192 vCPU, но такой кейс в реальной жизни случается весьма редко. Так что, в целом, улучшения были проведены весьма существенные (как минимум, на 11% планировщик стал более производительным по результатам тестов).

Помимо документа выше, информация об улучшениях планировщика приведена еще в KB 55806.

Немного азов: через какой интерфейс VMkernel пойдет трафик VMware HA на платформе vSphere?

14/05/2019

Многие из вас, конечно же, прекрасно знают, как работает механизм VMware HA на платформе vSphere. Но для тех из вас, кто подзабыл, Дункан написал пост о том, через какой интерфейс VMkernel идет этот трафик.

Так вот, хартбиты механизма HA пойдут через тот vmk-интерфейс, на котором в vSphere Client отмечена галочка Management, как на картинке:

Надо понимать, что этот пункт, хоть и называется Management, имеет отношение только к HA-трафику. Это означает, что если галочка не отмечена, то через этот интерфейс все равно можно будет подключиться по протоколу SSH, а также присоединить хост ESXi к серверу управления VMware vCenter, используя этот IP-адрес.

Так что Management - это не про управление, а только про HA. Это касается только обычной виртуальной инфраструктуры, а вот в кластере vSAN трафик HA идет по выделенной под vSAN сети автоматически.

Вышел и доступен для скачивания VMware Site Recovery Manager 8.2 - теперь виртуальный модуль без Windows.

13/05/2019

На днях компания VMware выпустила новую версию решения для обеспечения катастрофоустойчивости виртуальных датацентров VMware Site Recovery Manager 8.2. Напомним, что прошлая версия SRM 8.1 вышла довольно давно - аж в апреле прошлого года.

Главное нововведение данного обновления - это отказ от Windows и переход на виртуальный модуль (Virtual Appliance) на базе гостевой ОС Photon. Правда установщик под Windows пока еще доступен, но, скорее всего, его уже не будет в следующих версиях.

Давайте посмотрим, что еще нового появилось в новой версии VMware SRM 8.2:

  • Полная совместимость с платформой виртуализации VMware vSphere 6.7 Update 2.
  • Улучшения интерфейса управления на базе HTML5:
    • Утилита SRM Configuration Import/Export Tool теперь доступна прямо из консоли решения.
    • Теперь можно выбирать цветовые схемы пользовательского интерфейса, включая темную тему, которая показана на скриншоте выше.
    • Отображение информации о емкости на влкадке Protection Groups Datastores.
    • Возможность дать фидбэк в VMware касательно нового интерфейса.
  • Улучшения публичного API:
  • Возможность отсылать логи SRM на удаленный syslog-сервер.
  • Поддержка шифрования сетевого трафика для vSphere Replication 8.2.

Скачать VMware Site Recovery Manager 8.2 (как в виде виртуального модуля, так и в виде установщика для Windows) можно уже сейчас по этой ссылке.

Подробно о дисковых группах VMware vSAN - что это такое и как работает.

08/05/2019

Мы много пишем о решении для организации отказоустойчивых хранилищ на базе хостов ESXi - платформе VMware vSAN. Сегодня мы расскажем о дисковых группах на основе вот этого поста на блогах VMware.

Архитектура vSAN включает в себя два яруса - кэш (cache tier) и пространство постоянного хранения (capacity tier). Такая структура дает возможность достичь максимальной производительности по вводу-выводу, которая абсолютно необходима в кластере хранилищ на базе хостов.

Чтобы управлять отношениями устройств кэша и дисков хранения, решение vSAN использует дисковые группы:

У дисковых групп есть следующие особенности:

  • Каждый хост, который дает емкость кластеру vSAN, должен содержать как минимум одну дисковую группу.
  • Дисковая группа содержит как минимум одно устройство для кэша и от 1 до 7 устройств хранения.
  • Каждый хост ESXi в кластере vSAN может иметь до 5 групп, а каждая группа - до 7 устройств хранения. То есть на хосте может быть до 35 устройств хранения, чего вполне достаточно для подавляющего большинства вариантов использования.
  • Неважно, используете ли вы гибридную конфигурацию (SSD и HDD диски) или All-Flash, устройство кэширования должно быть Flash-устройством.
  • В гибридной конфигурации устройства кэша на 70% используются как кэш на чтение (read cache) и на 30% как кэш на запись (write buffer).
  • В конфигурации All-Flash 100% устройства кэша выделено под write buffer.

Write buffer и capacity tier

В принципе, всем понятно, что гибридная конфигурация хостов ESXi в кластере vSAN более дешевая (HDD стоит меньше SSD), но менее производительная, чем All-Flash. Но когда-то наступит время, и все будет All-Flash (в них, кстати, еще и нет нужды организовывать кэш на чтение, так как все читается с SSD с той же скоростью). Поэтому и выделяется 100% под write buffer.

При этом если операция чтения в All-Flash хосте находит блок в кэше - то он читается именно оттуда, чтобы не искать его в capacity tier. Максимальный размер write buffer на одной дисковой группе хоста ESXi - 600 ГБ. При этом если сам диск более 600 ГБ, то его емкость будет использоваться с пользой (см. комментарий к этой статье).

Для гибридных конфигураций 70% емкости кэша выделяется под кэш на чтение, чтобы быстро получать данные с производительных SSD-устройств, при этом vSAN старается поддерживать коэффициент попадания в кэш на чтение (cache hit rate) на уровне 90%.

Write buffer (он же write-back buffer) подтверждает запись на устройство хранения еще до актуальной записи блоков на сapacity tier. Такой подход дает время и возможность организовать операции записи наиболее эффективно и записать их на сapacity tier уже пачкой и более эффективно. Это дает существенный выигрыш в производительности.

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

Вот сравнительная таблица этих классов (колонка TBW - это terabytes written, то есть перезапись скольких ТБ они переживут):

Помните, что нужно всегда сверяться с VMware Compatibility Guide, когда выбираете устройства PCIe flash, SSD или NVMe.

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

Организация дисковых групп

При планировании хостов ESXi в кластере vSAN можно делать на нем одну или более дисковых групп. Несколько дисковых групп использовать предпочтительнее. Давайте рассмотрим пример:

  • Одна дисковая группа с одним кэшем и 6 устройств хранения в ней.
  • Две дисковых группы с двумя устройствами кэша, в каждой по 3 устройства хранения.

Если в первом случае ломается SSD-устройство кэша, то в офлайн уходит вся дисковая группа из 6 дисков, а во втором случае поломка одного девайса приведет к выходу из строя только трех дисков.

Надо понимать, что этот кейс не имеет прямого отношения к доступности данных виртуальных машин, которая определяется политикой FTT (Failures to tolerate) - о ней мы подробно рассказывали тут, а также политиками хранилищ SPBM. Между тем, размер домена отказа (failure domain) во втором случае меньше, а значит и создает меньше рисков для функционирования кластера. Также восстановление и ребилд данных на три диска займет в два раза меньше времени, чем на шесть.

Кстати, некоторые думают, что в случае отказа дисковой группы, кластер vSAN будет ждать 60 минут (настройка Object Repair Timer) до начала восстановления данных на другие диски согласно политике FTT (ребилд), но это неверно. Если вы посмотрите наш пост тут, то поймете, что 60 минут vSAN ждет в случае APD (All Paths Down - например, временное выпадение из сети), а вот в случае PDL (Physical Device Loss) восстановление данных на другие дисковые группы начнется немедленно.

С точки зрения производительности, иметь 2 дисковые группы также выгоднее, чем одну, особенно если разнести их по разным контроллерам хранилищ (storage controllers). Ну и это более гибко в обслуживании и размещении данных на физических устройствах (например, замена диска во втором примере пройдет быстрее).

Работа операций ввода-вывода (I/O)

Как уже было сказано, в гибридной конфигурации есть кэши на чтение и на запись, а в All-Flash - только на запись:

При этом хост ESXi работает так, чтобы операции чтения с дисков попадали в кэш на чтение в 90% случаев. Остальные 10% операций чтения затрагивают HDD-диски и вытаскивают блоки с них. Но и тут применяются оптимизации - например, одновременно с вытаскиванием запрошенного блока, vSAN подтягивает в кэш еще 1 МБ данных вокруг него, чтобы последовательное чтение проходило быстрее.

Для All-Flash конфигурации кэш на чтение не нужен - все данные вытаскиваются с примерно одинаковой скоростью, зато все 100% кэша используются под write buffer, что дает преимущество в скорости обработки большого входящего потока операций ввода-вывода.

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

Веб-консоль SSH Web Console для хост-серверов в клиенте VMware ESXi Embedded host client.

07/05/2019

Многие администраторы пользуются Putty для соединения с хостами VMware ESXi по протоколу SSH. Между тем, в веб-клиенте ESXi Embedded host client есть способ получить доступ к SSH-консоли прямо в браузере, реализованный на базе технологии HTML5.

Чтобы начать использовать консоль, надо сначала зайти на вкладку Services в разделе Manage и найти службу TSM-SSH:

Ее надо включить и поставить ей опцию запуска вместе с загрузкой хоста (Start and stop with host):

После этого в меню Action хостового веб-клиента надо выбрать пункт SSH Console:

Далее эта консоль загрузится в новой вкладке браузера:

А что нового в VMware vSphere Platinum 6.7 Update 2?

06/05/2019

Все из вас в курсе, что не так давно компания VMware выпустила обновление своей флагманской платформы виртуализации VMware vSphere 6.7 Update 2. Ну и все, наверняка, помнят, что, начиная с VMware vSphere 6.7, появилось издание Platinum, которое включает в себя функциональность продукта AppDefense (также вот тут мы рассказывали о решении VMware Service-Defined Firewall на его основе).

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

Сегодня мы расскажем о том, что нового появилось в vSphere Platinum 6.7 Update 2.

1. Диаграммы обнаружения процессов (Process Burndown Charts).

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

2. Статус репутации сервисов (Process Reputation Status).

Эта диаграмма показывает, какая часть сервисов опознана AppDefense как доверенная, а также сколько еще есть неизвестных сервисов и сервисов, которые не вошли в статус доверенных (Untrusted).

3. Статус проверок целостности (Integrity Check Status).

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

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

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

5. Диаграммы топологии (в статусе Beta).

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

6. Интеграция VMware Tools и AppDefense.

Теперь модули AppDefense поставляются для гостевых ОС вместе с VMware Tools (по аналогии с модулями NSX introspection). Это позволяет также и создавать шаблоны виртуальных машин с уже интегрированными модулями AppDefense.

7. Улучшения vSphere Plugin.

AppDefense Plugin for vSphere Platinum 6.7 Update 2 получил много улучшений в части рабочего процесса по инсталляции в кластере, а также по апгрейду виртуального модуля AppDefense.

8. Прочие улучшения.

Здесь можно отметить следующие:

  • Поддержка новых механизмов современных ОС упрощает использование VBS (Virtualization-Based Security), виртуальных устройств TPMs, шифрования уровня ВМ, безопасной загрузки и других возможностей по обеспечению безопасности. После обновления со старых систем, например Windows Server 2008 R2, эти возможности включатся автоматически.
  • Улучшения Update Manager и Host Profiles в части процесса обновлений хостов ESXi.
  • Новые возможности для аудита и камплаенса - история паролей, лимит по повторному использованию паролей, улучшенный SSO, логирование всех событий vCenter и прочее. События можно отправить в сторонние системы, такие как vRealize Log Insight или другую SIEM-систему.
  • Улучшенный API по замене сертификатов ESXi, также можно сгенерировать запрос на создание сертификата средствами vCenter.
  • Новые возможности планировщика CPU помогают бороться с уязвимостями типа L1TF.

Скачать VMware vSphere Platinum 6.7 Update 2 можно по этой ссылке.

Как обновить информацию от VMware Tools о сетевых настройках гостевой ОС (пригодится для Instant Clone).

03/05/2019

Вильям Лам написал интересную заметку про обновление информации о сетевой идентификации гостевой ОС, которую выдает VMware Tools. Она показывается на вкладке Summary клиента vSphere Client или VMware Workstation:

По умолчанию эта информация обновляется каждые 30 секунд на базе данных, предоставляемых пакетом VMware Tools из гостевой ОС. Однако если вы используете технологию создания мгновенных клонов (Instant Clone) и массово создаете виртуальные машины, то вам может потребоваться увидеть эту информацию пораньше.

Здесь есть 2 пути:

1. Принудительно обновить настройки из гостевой ОС следующими командами:

  • Windows - C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe info update network
  • Linux - /usr/bin/vmware-toolbox-cmd info update network
  • Mac OS - /Library/Application\ Support/VMware\ Tools/vmware-tools-cli info update network

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

Для этого в vmx-файл виртуальной машины нужно добавить следующую строчку (но не факт, что это работает сейчас):

vnet.pollInterval = XX

StarWind Command Center - единая панель управления и мониторинга гиперконвергентной инфраструктурой.

01/05/2019

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

Эти серверы могут исполнять как вычислительную нагрузку для ВМ, так и предоставлять ресурсы хранения. Когда все аспекты инфраструктуры объединяются в единую систему управления, такая инфраструктура называется гиперконвергентной (Hyperconverged Infrastructure, HCI).

Недавно компания StarWind анонсировала HCI-решение Command Center, которое позволит из единого интерфейса осуществлять мониторинг виртуальной среды на базе хранилищ Virtual SAN, а также управлять ею.

Command Center - это веб-интерфейс, построенный на базе технологии HTML5, который дает средства для управления виртуальными машинами и хост-серверами виртуализации, где для каждой из сущностей доступно до 100 различных параметров настройки. Единая панель управления инфраструктуры HCI позволяет выполнять ежедневные операции до 5 раз быстрее по сравнению с использованием нескольких консолей.

С помощью Command Center можно будет не только управлять сущностями виртуальной инфраструктуры, но и контролировать такие процессы, как оркестрация операций, резервное копирование Veeam Backup & Replication и многое другое.

Только 5% функционала Command Center приходится на решение Virtual SAN, остальное - это управление гипервизорами, резервным копированием, инфраструктурой публичных облаков и прочими аспектами. Кстати, Command Center будет поддерживать различные гипервизоры - VMware vSphere, Microsoft Hyper-V, Red Hat KVM и, возможно, другие платформы.

С продуктом можно будет опционально докупить StarWind ProActive Support - она позволит собирать телеметрию с компонентов Command Center и на основе аналитики на стороне StarWind (ML/DL) выявлять причины возникающих проблем.

Скачать StarWind Command Center пока нельзя, но можно запросить демо этого решения.

Для чего нужна настройка Dedicated failover hosts в кластере VMware HA?

30/04/2019

Некоторые администраторы VMware vSphere задаются вопросом, а для чего же нужна опция Dedicated failover hosts при настройке механизма Admission Control в кластере VMware HA:

Очень просто - это так называемые Spare Hosts, то есть запасные и всегда свободные хосты ESXi, которые берут на себя нагрузку по размещению виртуальных машин только в случае сбоев других серверов, обрабатываемых механизмом VMware HA.

Эти хосты в обычной жизни будут простаивать, и, если на них не удастся запустить виртуальные машины в случае сбоя, VMware HA все равно перезапустит эти ВМ на других хостах ESXi. Также эти хосты не будут браться в расчет механизмом VMware DRS, то есть он не будет мигрировать туда виртуальные машины, даже на период обслуживания других хостов (Maintenance mode).

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

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

Оба этих варианта очень маловероятны, поэтому, как правило, настройку Dedicated failover hosts использовать вообще не нужно.

Сколько хостов VMware ESXi нужно для кластера VMware vSAN?

29/04/2019

Если вы только планируете попробовать решение для создания отказоустойчивых кластеров хранилищ VMware vSAN на базе хостов ESXi, то для вас может оказаться полезной вот эта заметка. Приведем ее суть вкратце.

Когда вы планируете кластер vSAN, вам нужно определиться с политикой FTT (Failures to Tolerate) - она определяет, какое количество отказов хостов может пережить кластер хранилищ. Если установлено значение 1 (по умолчанию), то реплика одного VMDK будет размещена на дисках еще одного из хостов кластера.

Также при создании SPBM-политики хранилищ vSAN вы определяете уровень RAID (1, 5 или 6), в который виртуально будут собираться хосты ESXi на уровне дисковых объектов:

Иногда этот уровень RAID также называется FTM (Failure Tolerance Method).

vSAN - это объектное хранилище, где объекты состоят из компонентов. В состав компонентов входят реплики (Replicas - они содержат данные) и Witness (там находятся метаданные, чтобы избежать ситуации split-brain в кластере).

Есть три типа объектов на хранилище vSAN:

  • VM Home (домашняя директория)
  • VM Swap (файлы подкачки)
  • VM Disk (диски с данными)

На хостах ESXi при этом размещаются компоненты для каждого из объектов в соответствии с заданной политикой SPBM:

FTM, то есть способ размещения данных на хостах ESXi, как мы сказали выше, может быть:

  • RAID-1 (Mirroring, то есть зеркалирование объектов на хостах).
  • RAID-5/6 (оно же Erasure Coding - алгоритм кодирования с коррекцией ошибок).

Таким образом, в зависимости от FTT вам понадобится следующее минимальное количество хостов ESXi для RAID-1:

FTT Число реплик Компоненты Witness Минимальное число хостов
0 1 0 1
1 2 1 3
2 3 2 5
3 4 3 7

Для RAID-5/6 вам потребуется вот такое минимальное число хостов ESXi:

FTT Алгоритм Erasure coding Схема избыточности Минимальное число хостов
0 Нет Без избыточности 1
1 RAID-5 3D+1P 4
2 RAID-6 4D+2P 6
3 Не применимо Не применимо Не применимо

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

Новое на VMware Labs - MyVMware CLI.

26/04/2019

На сайте проекта VMware Labs появилось очередное обновление - утилита/интерфейс MyVMware CLI, который позволяет взаимодействовать с порталом My VMware (my.vmware.com) посредством командной строки.

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

С помощью MyVMware CLI можно скачать любой продукт VMware, любой версии, а также загружать различные файлы. Надо понимать, что к возможностям загрузки дистрибутивов с помощью данного средства будут применяться ограничения, действующие для используемого аккаунта My VMware (поэтому выведите список всех доступных продуктов командой vmw-cli list).

MyVMware CLI протестирована и работает на Linux или MacOS. Установить интерфейс можно с помощью NodeJS (через NPM) командой:

npm install vmw-cli --global

Также MyVMware CLI можно развернуть на платформе Docker:

docker run -t --rm -e VMWUSER='<username>' -e VMWPASS='<password>' -v ${PWD}:/files apnex/vmw-cli <cmd>

MyVMware CLI доступен из репозитория GitHub, где вы также можете увидеть примеры использования различных команд по листингу и загрузке продуктов VMware. Более подробно об использовании утилиты можно почитать здесь.

Как восстановить пароль к VMware vRealize Operations Manager 7.0, и что лучше сделать до того, как вы его забыли.

24/04/2019

Некоторые администраторы решения vRealize Operations сталкиваются с трудностями восстановления админского пароля к консоли Operations Manager. В этом случае большинство использует функции сброса пароля root к виртуальному модулю, хотя у Operations Manager 7.0 есть простая процедура password recovery, правда подготовиться к ней нужно заранее.

Просто откройте vRealize Operations Manager Administration и перейдите в раздел Administrator Settings:

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

Как только вы зададите эти настройки, у вас появится опция "Forgot password" на экране логина:

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

Перейдя по ней, вы сможете сразу установить новый пароль, не зная старого.

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

Нативная поддержка кластеров Microsoft SQL Server в среде VMware vSAN (пока только в облаке vCloud on AWS).

23/04/2019

С момента последних обновлений, инфраструктура отказоустойчивых хранилищ VMware vSAN теперь нативно поддерживает кластеры Microsoft SQL Server. На данный момент эта поддержка реализована только в облачной IaaS-инфраструктуре VMware Cloud on AWS версии 1.6, но скоро она появится и в онпремизной инфраструктуре VMware vSphere.

Суть поддержки заключается в том, что теперь облачный vSAN работает с командами SCSI-3 Persistent Reservation (SCSI3-PR), которые обеспечивают доступ к общим дискам на физическом уровне абстракции.

Таким образом, пользователи SQL Server не нуждаются в перепроектировании их Availability Groups, а могут просто перенести свои кластеры БД в облако.

Чтобы построить SQL Server Cluster нужно расшарить общий диск между его узлам таким образом, чтобы каждый из узлов мог управлять устройством на физическом уровне. Этот подход описан в документе о SCSI-3 Persistent Reservation (SCSI3-PR).

Для включения поддержки SCSI3-PR для выбранного виртуального диска машины нужно:

  • Выставить режим диска в Independent – Persistent.
  • Виртуальный диск должен быть привязан к SCSI-контроллеру, для которого параметр SCSI Bus Sharing выставлен в Physical.
  • Для управления устройством Shared Disk и его Persistent Reservations имеет смысл создать отдельную политику хранилищ в целях лучшей управляемости.

На данный момент для такой инфраструктуры поддерживаются кластеры SQL Server Clusters 2012 и более свежие, работающие на платформе Windows Server 2012 и более свежей. С точки зрения лимитов, поддерживается до 8 узлов SQL Server на кластер и до 64 устройств на узел.

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

Вот как создается общий диск с описанными настройками:

Далее такой диск нужно подключить ко всем узлам SQL Server кластера:

Во время настройки, кстати, вам может оказаться полезным документ "Microsoft SQL Server Workloads and VMware Cloud on AWS: Design, Migration, and Configuration".

После того, как диск подцеплен ко всем узлам, можно валидировать кластер, перед тем, как создавать Cluster Management Point:

После завершения создания кластера закончите настройку инфраструктуры SQL Server как обычно.

На каком чипсете материнской платы работают виртуальные машины VMware vSphere?

21/04/2019

Интересный пост Дэвида Пасека про чипсет материнской платы виртуального аппаратного обеспечения виртуальных машин на платформе VMware vSphere. Оказывается, все ВМ, независимо от версии виртуального "железа" (включая Virtual Hardware Version 14 в vSphere 6.7 Update 1), используют одну и ту же виртуальную материнскую плату на базе Intel 440BX, которая в свойствах системы называется "440BX Desktop Reference Platform" (скриншот из гостевой ОС Windows 10):

Примечательно, что этот чипсет был выпущен в апреле 1998 года - в том же году, когда была основана VMware, а через год был выпущен первый продукт компании VMware Workstation. И вот с тех пор чипсет виртуальной материнской платы не менялся! Видимо, незачем вносить туда серьезные изменения, от него ничего особо в работе виртуальной машины не зависит.

Кстати, изнутри гостевой ОС виртуальной машины можно поймать модель материнской платы следующей командой:

Get-WMIObject win32_baseboard | Select-Object Product

Это же позволит вам определить, что, например, ваш сценарий или программа работает в ВМ.

В Linux, возможно, сработает эта команда:

# dmidecode | grep -C 3 'Base Board'

Что нового в обновлении архитектуры VMware Cloud Foundation 3.7?

19/04/2019

В конце прошлого года мы писали о серьезном обновлении VMware Cloud Foundation 3.0 - облачной архитектуры VMware, в которую входит большинство основных продуктов для развертывания, исполнения, мониторинга и поддержки виртуальной инфраструктуры в онпремизном датацентре. С тех пор уже успела выйти VCF 3.5, а на днях было выпущено обновление этой архитектуры VMware Cloud Foundation 3.7.

Архитектура VCF включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия, которые желательно развертывать все вместе, но можно какие-то и опустить. Все это находится под управлением решения VMware SDDC Manager.

Давайте посмотрим, что нового появилось в VCF 3.7:

  • Архитектура VMware Cloud Foundation на платформе VxRail

Эта возможность включает в себя средства интегрированного управления жизненным циклом всего решения в рамках аппаратной архитектуры Dell EMC VxRail. Интеграция происходит за счет специального плагина к vCenter, который связывается с VxRail Manager.

  • Автоматизированное развертывание vRealize Suite Lifecycle Manager (vRSLCM)

Теперь vRSLCM можно развернуть независимо от остальных компонентов и рабочих процессов под управлением SDDC Manager (и его теперь можно развернуть в любое время).

Это в будущем позволит просто накатывать обновления vRealize Operations и vRealize Automation через интеграцию между vRSLCM и SDDC Manager.

  • Автоматическое развертывание и управление инфраструктурой виртуальных ПК и приложений Horizon.

Эта возможность позволяет автоматизировать создание, масштабирование и удаление доменов Horizon workload domains через SDDC Manager. Сущность Horizon Domain используется, чтобы накатить инфраструктуру виртуальных десктопов поверх обычных доменов серверной виртуальной инфраструктуры в рамках распределенной архитектуры Horizon PODs.

Далее VI Domains можно конвертировать в VDI Domains:

  • Общий виртуальный модуль Cloud Builder для VMware Validated Design and VMware Cloud Foundation.

Теперь решение Cloud Builder можно использовать для развертывания обеих этих платформ.

Вот какие версии продуктов и решений VMware были включены в VCF 3.7:

Полный список обновлений VCF 3.7 приведен в Release Notes.

Основные рекомендации по исполнению нагрузок Microsoft SQL Server в кластере хранилищ VMware vSAN.

18/04/2019

Недавно мы писали о нативной поддержке Microsoft SQL Server в кластерах хранилищ VMware vSAN, а сегодня раскроем эту тему еще несколько глубже. Недавно VMware опубликовала полезный материал, содержащий основные рекомендации по исполнению нагрузок SQL Server в кластерах хранилищ VMware vSAN.

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

Давайте посмотрим, что это за базовые рекомендации:

1. Общие рекомендации.

  • Включайте дополнительный хост ESXi к результатам сайзинга по схеме n+1 на случай отказа диска, дисковой группы или всего хоста в целом.
  • Имейте хороший запас по пропускной способности сети для трафика vSAN, рекомендуется использовать 10G сеть с выделенной полосой для трафика синхронизации. Для All-Flash vSAN это обязательное требование. И не забывайте о резервировании каналов.
  • Имейте как минимум 2 дисковых группы на хост - это может увеличить полосу пропускания во многих случаях, а также обеспечивает лучшую отказоустойчивость.
  • Службы vSAN на уровне кластера:
    • vSAN Performance service (включен по умолчанию в vSAN 6.7) предоставляет метрики производительности в сторонние системы, такие как vRealize Operations, что позволяет эффективно мониторить и решать проблемы.
    • Вы можете использовать шифрование data at rest (FIPS 140-2 compliant), это не влияет на производительность по IOPS, но дает нагрузку на CPU, поэтому лучше использовать процессоры с поддержкой возможности AES-NI. Для end-to-end шифрования используйте туннели IPSEC. Если нужно зашифровать только отдельную БД, используйте SQL Server native encryption.
    • vSAN 6.7 поддерживает SCSI-3 persistent reservations для общих дисков при использовании SQL Server FCI. Для этого на уровне кластера надо включить службу vSAN iSCSI Target.

Настройте политики SPBM для данных SQL Server:

  • Политика Failures to tolerate (FTT): убедитесь, что выставлено как минимум значение 1, не используйте опцию "No data redundancy".
  • Политика Number of disk stripes per object: используйте значение по умолчанию (1) и подумайте о разделении данных между разными дисками VMDK, привязанными к разным контроллерам vSCSI.
  • Политика IOPS limit per object: vSAN 6.2 и более поздние версии имеют возможности QoS, которые могут ограничить IOPS, потребляемые дисковым объектам. Не используйте эту политику для задач, требовательных к нагрузкам. Эта фича используется, как правило, для операций резервного копирования и восстановления, чтобы предотвратить забитие полосы пропускания этими задачами.

2. Рекомендации для нагрузок Tier-1 (высоконагруженные OLTP-базы).

Как правило, такие нагрузки по вводу-выводу включают запросы с множественным позиционированием точек записи в базе данных, активность по сбросу грязных страниц кэша на диск, а также запись транзакционного лога. Размер операции ввода-вывода небольшой - в диапазоне 8K - 64K. Можно использовать бенчмарки TPC-E для воспроизведения паттернов OLTP-подобных нагрузок.

  • Рассмотрите возможность использования All-flash vSAN.
  • Используйте как минимум диски SAS SSD (а не SATA SSD) - у них больше глубина очереди. Также подумайте о технологии NVMe.
  • Отключайте дедупликацию и компрессию данных, которые включены в vSAN по умолчанию. Лучше использовать компрессию таблиц на уровне базы данных.
  • Для object space reservation установите "Thick provisioning" для всех VMDK с данными SQL Server и логами. Это позволит не натолкнуться на проблему нехватки места при использовании тонких дисков. Также в опциях SQL Server лучше установить настройку Perform maintenance tasks, чтобы инициализировать файлы с данными сразу же. Также выделите сразу место под лог БД, чтобы не натолкнуться на недостаток места в гостевой ОС, либо установите настройку его роста в ГБ, а не в процентах.
  • Не используйте IOPS limit for object.
  • Используйте RAID-1 mirroring и как минимум FTT=1 для для VMDK-дисков с данными и логом.
  • Если вы используете дополнительные методы отказоустойчивости, такие как Always On Availability Groups, то вам может потребоваться увеличить FTT. Делайте это не только с точки зрения доступности, но и с точки зрения производительности. Вы можете комбинировать отказоустойчивость Availability Groups на уровне приложения с отказоустойчивостью на уровне дисковой подсистемы.
  • Если вам требуется доступность SQL между площадками, можно использовать архитектуру растянутых кластеров (vSAN Stretched Cluster).
  • Подумайте о коммутаторах для трафика vSAN. Оптимально использовать кластеры all-NVMe vSAN, тогда операции ввода вывода будут быстро передаваться между дисковыми устройствами без участия физических контроллеров. Также лучше использовать 10G-коммутаторы Enterprise-уровня с большими размерами буфера (non-shared), чтобы обеспечить работу с плотным потоком ввода-вывода.

2. Рекомендации для нагрузок Tier-2 (высоконагруженные OLTP-базы).

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

Для гибридной среды vSAN (микс HDD+SSD) рекомендуется следующее:

  • Используйте несколько дисковых групп для увеличения пропускной способности.
  • Имейте как минимум 10% от емкости данных для пространства кэширования на SSD. Также рекомендуется использовать объем SSD-емкости как минимум в два раза больший, чем рабочий набор данных (working data set).
  • Используйте, по возможности, устройства SAS SSD вместо SATA SSD.

Если вы используете конфигурацию All-flash vSAN, то:

  • Используйте дедупликацию и компрессию, если у приложений нет высоких требований по операциям записи.
  • Если хотите экономить место и не требуется большой производительности, то используйте конфигурацию RAID 5/6 erasure coding, но для транзакционных логов используйте VMDK-диски, размещенные на RAID 1.
  • Для object space reservation установите "Thick provisioning" для всех VMDK с данными SQL Server и логами.

3. Нагрузки типа Data Warehouse и серверов отчетов (Reporting).

Для таких нагрузок характерен большой размер операции ввода-вывода, так как происходит запрос большого объема данных из БД. Критичной метрикой здесь является не IOPS, а пропускная способность (MB/s). Для генерации таких нагрузок могут быть использованы бенчмарки TPC-H.

Тут приводятся следующие рекомендации:

  • Для конфигураций All-flash лучше использовать NVMe SSD для хранилищ данных, это даст хорошую производительность по большим операциям чтения.
  • Для конфигураций All-flash в целях экономии места используйте RAID 5/6 для VMDK с данными БД.
  • Преаллоцируйте пространство для логов SQL Server, чтобы не натолкнуться на проблему нехватки места.
  • Не используйте IOPS limit for object, это может ограничить полосу пропускания.
  • Лучше использовать 10G-коммутаторы Enterprise-уровня с большими размерами буфера (non-shared), чтобы обеспечить работу с плотным потоком ввода-вывода и выдать хорошую пропускную способность.

Как попробовать инфраструктуру VMware в облаке Amazon - VMware Cloud on AWS Evaluation Guide.

17/04/2019

Как вы знаете, уже довольно давно компании Amazon и VMware совместно продвигают публичное облако VMware Cloud on AWS, где можно взять в аренду виртуальные машины. Недавно компания VMware выпустила документ VMware Cloud on AWS Evaluation Guide, который позволит вам понять процедуру развертывания и начать тестирование виртуальной инфраструктуры в облаке VMConAWS.

В документе представлен обзор функциональности платформы, ее основные возможности и основные шаги по ее первоначальной конфигурации. Также рассматривается опциональный вариант сопряжения облачного SDDC (Software-Defined Data Center) и онпремизной виртуальной инфраструктуры с настройкой средств катастрофоустойчивости.

Вы также научитесь строить и конфигурировать сети software defined networks в гибридном облаке, настраивать сетевые экраны, развертывать сервисы DNS, VPN, отчетности и многое другое. Лучше всего использовать данное руководство с функциональностью сервиса Get Started в облаке VMConAWS (оно под него и заточено). Для построения гибридной облачной среды вам потребуется как минимум один хост ESXi на платформе vSphere 6.0 Update 3 или более поздней в своем датацентре.

Необычно и печально то, что сервис VMware Cloud on AWS не предоставляет бесплатного триала (у всех остальных он есть), поэтому нужно быть готовым сразу платить.

Есть еще 3 полезные ссылки, помимо данного Evaluation Guide: FeaturesUse Cases и FAQ. Также всем бесплатно доступна лабораторная работа Hands-On Lab for VMware Cloud on AWS.

Кстати, вот полезный PowerCLI сценарий, который позволит вам скачать документацию по VMware Cloud on AWS, которая публично доступна вот тут:

$url = "https://docs.vmware.com/en/VMware-Cloud-on-AWS/services/vmc-on-aws-networking-security.pdf",
"https://docs.vmware.com/en/VMware-Cloud-on-AWS/services/vmc-aws-operations.pdf", 
"https://docs.vmware.com/en/VMware-Cloud-on-AWS/services/vmc-on-aws-getting-started.pdf", 
"https://docs.vmware.com/en/VMware-Cloud-on-AWS/services/vmc-aws-manage-vms.pdf",
"https://docs.vmware.com/en/VMware-Cloud-on-AWS/services/vmc-aws-manage-data-center.pdf"

$url | ForEach-Object {Invoke-WebRequest -Uri $_ -OutFile ($_ | Split-Path -Leaf)}

Весенняя серия вебинаров от VMware 2019.

16/04/2019

Компания VMware решила вновь заняться просветительской работой в российском сегменте и с марта запустила весеннюю серию вебинаров на русском языке. Но в апреле-мае осталось еще много интересных событий:

Тема вебинара Дата и время
Из администратора инфраструктуры виртуализации в Site Reliability Engineer: vSphere и Kubernetes – сравнение архитектур и почему вместе лучше 18 апреля в 11:00 мск
Виртуальные сети и безопасность для контейнеров на базе NSX Data Center 23 апреля в 11:00 мск
Современные технологии: VMware & Blockchain 25 апреля в 11:00 мск
Построение удаленного рабочего места и управление им 14 мая в 11:00 мск
Что нового в базовой виртуализации ЦОД 16 мая в 11:00 мск
Современная и компактная филиальная инфраструктура из vSphere, vSAN, NSX и VeloCloud 21 мая в 11:00 мск
VMware SD-WAN by VeloCloud: архитектура, основные компоненты, сценарии использования 28 мая в 11:00 мск
VMware Cloud Services (CAS, VMC) 30 мая в 11:00 мск

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

На данный момент уже прошли следующие мероприятия:

Тенденция BYOD: плюсы и ... плюсы 19 марта в 11:00 
Гиперконвергентная инфраструктура как фундамент программно-определяемого ЦОДа 21 марта в 11:00 
Технологии VMware для построения частного облака 26 марта в 11:00 
Безопасность рабочего места 28 марта в 11:00
Виртуальная Облачная Сеть (Virtual Cloud Network). Основные компоненты и сценарии использования 2 апреля в 11:00
Построение удобного, адаптивного и безопасного гибридного облака на платформе VMware Cloud Foundation 4 апреля в 11:00
Мониторинг программного ЦОДа 9 апреля в 11:00
Построение катастрофоустойчивого ЦОД для непрерывной работы вашего бизнеса 11 апреля в 11:00

Регистрация на вебинары находится по этой ссылке. Приходите!

Новые релизы VMware: vRealize Automation 7.6, vRealize Lifecycle Manager 2.1 и vRealize Network Insight 4.1.

15/04/2019

Недавно компания VMware провела серию релизов своих продуктов, главным из которых было обновление платформы виртуализации VMware vSphere 6.7 Update 2. Но помимо этого, VMware обновила еще 3 своих решения из линейки по оптимизации операций датацентров:

  • vRealize Automation 7.6
  • vRealize Lifecycle Manager 2.1
  • vRealize Network Insight 4.1

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

1. vRealize Automation 7.6.

В этом релизе VMware сделала упор на интеграцию архитектуры SDDC с платформой Cloud Management Platform (CMP):

  • Появилась интеграция с решением NSX - пользователи могут теперь настроить одновременно NSX-T и NSX-V для различных кластеров сети на одном сервере vCenter. Также будет добавлена поддержка on-demand private networking.
  • Улучшилось управление рабочими процессами в vRealize Orchestrator - теперь появились такие функции в них, как Design, Run, Content Management и Troubleshooting. Также будет добавлена поддержка нескольких клиентов (multi-tenancy) для пользователей, которые хотят позволить использовать vRO в изолированных окружениях.

Скачать vRealize Automation 7.6 скоро можно будет по этой ссылке.

2. vRealize Lifecycle Manager 2.1.

В этом обновлении было уделено внимание функциям жизненного цикла продуктов в гибридном облаке, особенно в составе пакета решений vRealize Suite. В vRealize Suite Lifecycle Manager появились следующие новые возможности:

  • Установка шаблонов VMware Validated Designs
  • Более гранулярные настройки развертывания
  • Возможность Multi-content capture
  • Управление жизненным циклом продукта VMware Identity Manager.
  • Улучшения пользовательского интерфейса.

Скачать vRealize Lifecycle Manager 2.1 пока нельзя, скоро он будет доступен.

3. vRealize Network Insight 4.1.

Здесь появились следующие новые возможности:

  • Планирование и решение проблем на базе приложений. vRNI 4.1 берет определения приложений из ServiceNow (либо их может задать пользователь с помощью регулярных выражений). Далее эти приложения появляются на соответствующих дэшбордах мониторинга.
  • Возможность мониторинга окружений VMware Enterprise PKS и Kubernetes. В решение vRNI были добавлены функции для управления безопасностью и конфигурации сетевого взаимодействия для приложений на PKS и Kubernetes.
  • Улучшенная видимость происходящих событий в датацентре с точки зрения сети. Теперь на таймлайн изменения конфигураций безопасности и сетевых настроек, включая окружения NSX, были добавлены и метки пользователей (то есть не только, что изменено, но и кто изменил). Также была добавлена поддержка балансировщиков F5 и отслеживание их физического пути трафика.

Скачать vRealize Network Insight 4.1 скоро можно будет по этой ссылке.

Стал доступен Google Cloud Plug-in for VMware vRealize Automation.

12/04/2019

Недавно компания VMware выпустила плагин Google Cloud Plug-in for VMware vRealize Automation, который позволяет реализовать нативную интеграцию публичного облака Google Cloud и решения для автоматизации операций в облаке vRealize Automation.

Это решение является продолжением уже объявленной VMware в июле прошлого года интеграции с облаком Google средствами плагина Google Cloud plug-in for VMware vRealize Orchestrator (vRO). vRO представляет собой встроенный движок vRealize Automation для оркестрации рабочих процессов в облаке, соответственно, плагин для vRealize Automation позволяет настроить управление рабочими процессами в облаке Google Cloud в дополнение к уже имеющимся процедурам автоматизации в онпремизной инфраструктуре.

С момента превью плагина для vRO команда Google Cloud добавила следующие новые возможности и улучшения в плагин:

  • Поддержка новых сервисов: Google Kubernetes Engine, Cloud SQL, Cloud Spanner, Cloud Pub/Sub, Cloud Key Management Service, Cloud Filestore (Beta), IAM Service Accounts.
  • Улучшенные рабочие процессы для работы с облачными ВМ: установка пароля Windows, исполнение SSH-команд, запрос вывода последовательного порта, восстановление из снапшота и другое.

Также для функций плагина к vRO были сделаны следующие улучшения:

  • Поддержка настройки http-прокси при создании соединения.
  • Рабочие процессы для упрощения импорта ресурсов XaaS Custom Resources и описаний архитектуры Blueprints в инфраструктуру vRealize Automation.
  • Дефолтные опции для рабочего процесса по созданию ВМ.
  • Просмотр оценочной стоимости платы за ВМ в месяц.
  • Рабочий процесс для сбора ошибок и написания письма в поддержку.
  • Улучшенная обработка синхронизации соединений для кластеров vRO.
  • Премиальная поддержка для функций Health Check.
  • Доработанная пользовательская документация и шаблоны сценариев vRO.

Обзор функций плагина Google Cloud Plug-in for VMware vRealize Automation представлен в видео ниже:

Информация о плагине доступна в блоге Google и VMware. Скачать его можно по этой ссылке.

Вышел Veeam Backup & Replication Community Edition - вся функциональность издания Standard абсолютно бесплатно.

11/04/2019

Совсем недавно компания Veeam Software сделала широкий жест в отношении пользователей, которые применяют бесплатное решение Veeam Backup Free Edition для резервного копирования своих виртуальных машин. Не так давно мы писали об анонсе бесплатного продукта Veeam Backup & Replication Community Edition, а несколько дней назад он стал доступен для скачивания.

Давайте посмотрим, что представляет собой Veeam B&R Community Edition. Во-первых, обратите внимание, что в названии появилось слово Replication - значит пользователям теперь доступно не только резервное копирование виртуальных машин, но и их репликация. Мало того, Community Edition - это полноценное издание Veeam B&R Standard, но ограниченное возможностью резервного копирования 10 виртуальных машин (либо физических серверов или рабочих станций) в рамках этого издания. И его можно использовать в производственной среде.

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

Теперь все возможности коммерческого издания Standard Edition доступны бесплатно (см. таблицу сравнения возможностей изданий). Можно использовать репликацию, планировать задачи из GUI, а не PowerShell и многое другое.

Вот так удобно и бесплатно можно настроить задачу резервного копирования ВМ:

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

В бесплатное издание включена и функция Application awareness - то есть ваши резервные копии будут консистентными на уровне приложений. Ну а решения Veeam Explorers для приложений Microsoft (Active Directory, Exchange, SQL Server и SharePoint) позволят восстанавливать отдельные объекты из резервных копий напрямую в приложения (например, почтовый ящик Exchange).

С помощью Community Edition вы сможете развернуть Veeam Agents for Microsoft Windows и Linux на серверах и рабочих станциях в целях бэкапа физических систем (правда из 10 разрешенных систем рабочие станции будут потреблять 1 лицензию, а серверы - 3).

Но самое главное - это то, что после исчерпания лимита в 10 виртуальных машин, остальные машины можно будет резервировать с помощью технологии VeeamZIP (то есть, Community Edition не стал хуже с точки зрения ограничений). Это позволит вам создать полную резервную копию виртуальной машины в сжатом формате в виде VBK-файла (инкрементальные копии и физические машины в этом случае не поддерживаются).

Также решения по бэкапу физических систем Veeam Agent for Microsoft Windows и Veeam Agent for Linux можно использовать как отдельные от Community Edition бесплатные продукты. В этом случае у вас просто не будет централизованной консоли, но для нескольких серверов она и не нужна.

Решение для мониторинга, отчетности и решения проблем также получило бесплатную версию - Veeam ONE Community Edition.

Это решение является продолжателем бесплатного продукта Veeam ONE Free Edition, но в нем добавилось несколько существенных возможностей. Главное улучшение тут - это возможность мониторить инфраструктуру Veeam Backup & Replication infrastructure, а также машины с установленными Veeam Agents.

Решение Veeam ONE CE позволит вам получать отчетность об инфраструктуре резервного копирования, включая такие возможности, как отчет по защищенным и незащищенным ВМ (например, после развертывания новой ВМ вы забыли настроить для нее бэкап):

Вот их физические места размещения:

Как и прошлая бесплатная версия Veeam ONE, издание Community Edition может обеспечивать мониторинг любого числа виртуальных машин. Но теперь возможности средства были расширены - стали доступны действия Remediate Actions, позволяющие вам, например, удалить изолированный снапшот или настроить резервное копирование для ВМ:

Также стала доступной для загрузки и бесплатная версия решения Veeam Backup for Microsoft Office 365 Community Edition:

С помощью бесплатной версии можно организовать резервное копирование данных в сервисах Exchange Online и OneDrive for Business для 10 пользователей, а также 1 ТБ данных SharePoint Online.

Скачать бесплатный Veeam Backup & Replication Community Edition можно по этой ссылке. Остальные продукты вы также без труда найдете на сайте Veeam.

Новое на VMware Labs: синхронизация назначения прав доступа App Volumes Entitlement Sync.

10/04/2019

Полтора года назад мы писали о PowerCLI-сценарии, который решает проблему того, что права доступа пользователей (Entitlements) не синхронизированы при резервировании серверов App Volumes Managers и баз данных SQL Server на запасной площадке, что влечет за собой проблемы доступа при переключении в случае сбоя.

При этом данный скрипт не реплицировал данные томов AppStacks, которые можно перенести обычным копированием (также можно автоматизировать этот процесс за счет настройки Storage Groups, как это описано в документе "App Volumes Deployment Considerations").

На днях на сайте проекта VMware Labs появилась GUI-обертка к данному процессу, которая называется App Volumes Entitlement Sync. С помощью нее можно прочитать, сравнить и синхронизировать права доступа к объектам между экземплярами App Volumes на географически разделенных площадках:

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

Перед выполнением синхронизации вам покажут, что именно будет сделано на обеих площадках:

По результатам синхронизации заполняется лог:

Процесс работы с утилитой показан в видео ниже:

Скачать App Volumes Entitlement Sync можно по этой ссылке. Документация доступна тут.

<<   <    1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119    >   >>
Реклама







Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

Быстрый переход:
VMware IT-Grad StarWind Veeam PowerCLI Offtopic Gartner Citrix VSAN GDPR 5nine Hardware VeeamON Nutanix vSphere RVTools Enterprise Security Code Cisco vGate Microsoft Cloud SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Teradici Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter VMachines Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V vSAN vROPs Stencils Labs Bug UEM vRNI VTL Networking Horizon vCSA Tools vCloud Forum iSCSI SRM HCI App Volumes Video Workspace ONE Backup VMUG NSX HA Update Manager VCP VVols Workstation Update DR Cache Storage DRS VMworld Workspace DRS Fusion Lifecycle Visio Log Insight Operations Manager SDDC Virtual Appliance OpenStack PowerShell LSFS Client Datacenter Intel Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Performance Nested AWS XenDesktop VSA vNetwork SSO Host Client VMDK Whitepaper Appliance VUM V2V Support Обучение Web Client Mobile Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers Converter XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP SC VMM Certification VDP Partners PCoIP RHEV vMA Award Network USB Licensing Logs Server Demo vCHS Calculator Бесплатно vExpert Beta SAN Exchange MAP ONE DaaS Monitoring VPLEX UCS SDK Poster VSPP Receiver vMotion VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Documentation Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint SIOC Plugin Memory CLI Helpdesk Troubleshooting VIC Upgrade VDS Migration Director API Android Graphics Diagram Air DPM Flex Mac Open Source SSH VAAI Chargeback Heartbeat MSCS Ports SVMotion Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

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

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

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

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

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

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Сравнение Oracle VirtualBox и VMware Workstation.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Как использовать возможности VMware vSphere Management Assistant (vMA).

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Работа с дисками виртуальных машин VMware.

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2019, Александр Самойленко. Правила перепечатки материалов.