Компания VMware выпустила отличную книгу об обновлении на последнюю версию платформы виртуализации VMware vSphere 6.5 Upgrade eBook. Эта небольшая книга из 32 страниц рассказывает о планировании и реализации процесса апгрейда на vSphere 6.5 и включает в себя множество таблиц, диаграмм и ссылок на документацию о процессе обновления:

Кстати, книга будет особенна полезна пользователям VMware vSphere 5.5, так как поддержка этой версии прекратится 19 сентября этого года.

В книге процесс апгрейда разбит на три фазы:

• Фаза 1: Pre-upgrade – обозначает фронт работ и требований, которые должны быть выполнены перед началом процедуры апгрейда.
• Фаза 2: Upgrade – описание шагов процесса обновления и иллюстрация их исполнения.
• Фаза 3: Post-Upgrade – валидация результата в соответствии с изначально поставленными целями.

В качестве примера в документе рассматриваются 2 пути обновления:

• vSphere 5.5 на vSphere 6.5
• vSphere 6.0 на vSphere 6.5 Update 1

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

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

Скачать VMware vSphere 6.5 Upgrade eBook можно по этой ссылке.

Продолжаем информировать вас о выпусках обновлений и заплаток уязвимостей Meltdown и Spectre для виртуальной инфраструктуры VMware vSphere. Напомним наши прошлые посты:

• Как отслеживать производительность хостов VMware ESXi после патчей Meltdown и Spectre с помощью VMware vSphere Operations Manager
• Вышел VMware vCenter Server Appliance 6.5 Update 1f - исправлена уязвимость Meltdown и Spectre (частично)
• Производительность хост-серверов VMware ESXi и других платформ после наката патчей для Meltdown и Spectre
• Для VMware vSphere, Workstation и Fusion пофикшена уязвимость Spectre
• Скрипт для проверки виртуальной инфраструктуры VMware vSphere на подверженность уязвимости Spectre

На днях наш читатель Стас прислал новость о том, что VMware выпустила обновления, закрывающие уязвимость Spectre, на этот раз для ключевых компонентов виртуальной инфраструктуры - серверов vCenter и ESXi. Таким образом, согласно VMware Security Advisory VMSA-2018-0004.3, теперь от уязвимости Spectre защищены все основные продукты VMware трех последних поколений:

Начнем с обновлений для vCenter. Тут были выпущены следующие апдейты:

• VMware vCenter Server 5.5 Update 3h (Release notes, скачать)
• VMware vCenter Server 6.0 Update 3e (Release notes, скачать)
• VMware vCenter Server 6.5 Update 1g (Release notes, скачать)

Для серверов VMware ESXi были выпущены следующие патчи:

• ESXi550-201803001 (ESXi550-201803401-BG и ESXi550-201803402-BG)

• ESXi600-201803001 (ESXi600-201803401-BG и ESXi600-201803402-BG)

• ESXi650-201803001 (ESXi650-201803401-BG и ESXi650-201803402-BG)

Чтобы скачать эти обновления для ESXi, нужно пойти VMware Patch Portal и поискать там обновления для соответствующей версии ESXi.

Кроме наката патчей гипервизора VMware ESXi, вам также придется обновить микрокод серверов. Более подробная информация об этом приведена в KB 52085.

Помните, что порядок наката обновлений безопасности таков:

1. Накатываем обновления vCenter.

2. Обновляем ПО гипервизора на серверах VMware ESXi - накатываем апдейты, заканчивающиеся на 01-BG (позволяет гостевым ОС использовать новый механизм speculative-execution control), одновременно с этим обновляем и микрокод серверов (апдейты, заканчивающиеся на 02-BG), которое применяется в процессе загрузки ESXi. Оба патча накатываются в рамках одного профиля.

На сайте nolabnoparty.com появилась отличная статья о том, как нужно выключать и включать кластер отказоустойчивых хранилищ VMware vSAN таким образом, чтобы не повредить данных, и включить его потом без особых проблем. Инструкция может оказаться полезной тем администраторам, которым необходимо остановить кластер vSAN целиком в целях обслуживания оборудования (серверы, коммутаторы, стойка и т.п.).

Выключение кластера vSAN

1. Для начала вам нужно выключить все виртуальные машины, кроме сервера VMware vCenter (неважно, обычный это VC или vCSA):

2. Мигрируем с помощью vMotion сервер vCenter на хост ESXi01 (тот хост, который вы считаете своим первым хостом в виртуальной инфраструктуре):

Также на первый хост ESXi настоятельно рекомендуется перевести контроллер домена Active Directory.

3. Теперь надо убедиться, что в данный момент в кластере vSAN нет процессов ресинхронизации (Resyncing Components). Для этого надо зайти в соответствующий раздел на вкладке Monitor:

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

4. Переводим все хосты VMware ESXi (кроме ESXi01) в режим обслуживания (Maintenance Mode):

В настройках режима обслуживания уберите галку с варианта переместить машины (Move powered-off and suspended virtual machines...), а также выберите вариант не перемещать данные кластера vSAN (No data evacuation):

5. Выключите гостевую ОС виртуальной машины c VMware vCenter. Для этого в контекстном меню vCenter или vCSA выберите пункт Shut Down Guest OS:

После этого у вас, само собой, отпадет соединение с VMware vSphere Web Client:

6. Зайдите на хост ESXi через ESXi Host Client (ссылка https://<ip esxi>/ui) и переведите сервер в режим обслуживания, выбрав из контекстного меню пункт Enter maintenance mode:

Аналогично укажите, что не нужно переносить данные кластера vSAN:

Также это можно сделать следующей командой esxcli в консоли сервера:

# esxcli system maintenanceMode set -e true -m noAction

Включение кластера VMware vSAN

1. Сначала последовательно выводим хосты ESXi из режима обслуживания, начав с первого:

Сделать это также можно командой esxcli:

# esxcli system maintenanceMode set -e false

2. Включаем на хосте ESXi01 сервер vCenter и контроллер домена Active Directory:

3. Идем на вкладку Monitor и там в разделе Health убеждаемся, что все узлы в порядке и кластер vSAN прошел все проверки:

4. Только после этого включаем все виртуальные машины:

За последнее время у компании VMware вышло несколько материалов по продукту для создания отказоустойчивых кластеров хранилищ VMware vSAN 6.6.

Во-первых, вышло хорошее обзорное видео:

Во-вторых, был опубликован полезный технический документ "VMware vSAN 6.6 Technical Overview", где с технической точки зрения рассматриваются возможности vSAN 6.6:

Ну и, в-третих, вышла лабораторная работа (Hands-On Lab) для администраторов - vSAN 6.6 – Getting Started Hands-on Lab, пройдя которую можно узнать основные возможности продукта и обучиться приемам работы с кластерами vSAN:

Многие из вас иногда хотят получить так называемый "Support Bundle", содержащий лог-файлы, диагностическую информацию и метрики производительности, который помогает решать проблемы в инфраструктуры VMware vSphere. В первую очередь, этот бандл нужен для предоставления службе технической поддержки VMware GSS (Global Support Services) информации о конфигурации виртуальной среды, чтобы она могла решать возникающие у клиентов проблемы в рамках обращений (тикетов) в техподдержку.

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

Давайте рассмотрим основные способы получения support bundle как для серверов VMware vCenter (для Windows или виртуального модуля vCenter Server Appliance, vCSA), так и для серверов VMware ESXi. Кстати, надо учитывать, что после экспорта бандла с логами результирующий файл будет размером 30-300 МБ в зависимости от того, что вы туда включите, а также как давно и интенсивно менялась конфигурация виртуальной среды.

Получение Support Bundle для серверов vCenter

Самый простой способ получить саппорт бандл - это выгрузить его с помощью vSphere Web Client. Для этого нужно выбрать сервер vCenter в иерархии инвентори и выбрать пункт Export System Logs (работает как для обычного vCenter, так и для vCSA):

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

Если вы используете vCSA, то можно получить логи через веб-интерфейс. Для этого надо перейти по адресу:

https://<ip vcsa>/appliance/support-bundle

И далее ввести логин и пароль root от виртуального модуля vCSA.

После этого support bundle будет сгенерирован и загружен через ваш браузер.

Кроме этого, есть способ получить логи vCSA из Linux-системы с помощью утилиты curl. Для этого нужно выполнить следующую команду:

curl -k -u root -o support-bundle.tar.gz -O https://<ip vcsa>/applmgmt/support-bundle

После того, как вы скачаете этот бандл, нужно будет разархивировать его командой:

tar -zxvf support-bundle.tar.gz

Также Support Bundle можно получить с помощью PowerCLI. Для этого нужно соединиться с сервером vCenter:

Connect-VIServer -Server HostnameOrIPAddress

И далее использовать следующую команду:

Get-Log -Bundle -DestinationPath c:\Storage\Location\

Более подробная информация об этом приведена в KB 1027932. Там же, кстати, есть информация и о том, как искать в файлах логов с помощью PowerCLI:

Get-VMHost HostNameOrIP | Get-Log LogName | Select -expand Entries | Select-String SearchTerm | More

Здесь SearchTerm - это строка поиска, а LogName - это один из следующих логов:

• hostd
• vpxa
• messages
• vmkernel
• vmksummary
• vmkwarning

Получение Support Bundle для серверов ESXi

По аналогии с получением бандла для сервера VMware vCenter или vCSA, в vSphere Client можно выбрать сервер VMware ESXi и выбрать для него пункт "Export System Logs":

Также можно сгенерировать Support Bundle через тонкий клиент для управления серверами VMware ESXi - Embedded Host Client (он же - просто веб-интерфейс для управления хостами ESXi). Он доступен при соединении с хостом ESXi по ссылке:

https://<ip esxi>/ui

Для генерации саппорт бандла нужно выбрать пункт "Generate support bundle" из контекстного меню хоста:

Помимо этого, его можно сгенерировать и в консоли ESXi. Для этого используется команда vm-support без параметров (подробнее об этом написано в KB 1010705). Чтобы получить Support Bundle нужно в консоли ESXi выполнить следующую команду:

# vm-support

Надо отметить, что у утилиты есть множество разных параметров:

Аналогично получению бандла для vCenter, через PowerCLI можно получить и бандл для хоста ESXi. Соединяемся с хостом, забираем бандл и складываем его в нужную папку:

Get-VMHost HostNameOrIP | Get-Log -Bundle -DestinationPath c:\Storage\Location\

Для тех, кто хочет узнать, что же находится внутри Support Bundle, мы рекомендуем статью "What's Inside an ESXi vm-support Bundle?".

Прошлой весной компания VMware выпустила релиз своего основного документа по обеспечению безопасности виртуальной среды Security Configuration Guide для vSphere 6.5. Напомним, что ранее подобный документ назывался Hardening Guide и был основным руководством для сотрудников отделов ИТ-безопасности по настройке гипервизора ESXi и виртуальных машин.

На днях VMware выпустила финальную версию документа vSphere 6.5 Update 1 Security Configuration Guide, в котором приведены основные конфигурации для обеспечения безопасности уже Update 1, то есть последнего на данный момент мажорного обновления платформы vSphere.

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

• Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
• Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
• Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено администратором необоснованно. 
• Desired value - рекомендуемое значение, оно же и является значением по умолчанию, если это не site specific.

Надо отметить, что от релиза к релизу Security Configuration Guide становится все меньше, так как VMware продвигает идеологию, что платформа становится защищеннее из коробки (Secure By Default). На данный момент осталось всего 68 конфигураций для всей виртуальной среды.

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

• Код vSphere постоянно ревьювится, и некоторые введенные улучшения делают так, что какой-то из описанных гайдлайнов больше не является вектором угрозы. Пример - настройка "disable-intervm-vmci". Сам по себе этот механизм был удален из состава vSphere, а значит ушла и рекомендация по этой настройке.
• Также некоторые гайдлайны ранее были невыполнимыми (например, verify-kernel-modules) - многие пытались писать свои скрипты для верификации каждого модуля VMkernel при загрузке, пока VMware не сделала цифровые подписи VIB-модулей, за счет которых распространяются компоненты vSphere, и механизм Secure Boot.
• Некоторые гайдлайны были написаны для фичей, которые некорректно понимались с точки зрения безопасности. Например, считалось, что настройка VM.disable-hgfs актуальна для vSphere, но оказалось, что она применяется только для Workstation и Fusion и никакой угрозы не несет.

Также поменялись некоторые дефолтные значения для настроек безопасности, которые ранее по умолчанию вообще не имели значений. Например, настройки ниже имеют указанные явно значения TRUE, чтобы не вводить пользователя в заблуждение - типа, а как это работает по умолчанию?

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

Скачать VMware vSphere 6.5 Update 1 Security Configuration Guide можно по этой ссылке.

Еще весной прошлого года мы писали про продукт Veeam Availability Orchestrator, который предназначен для восстановления виртуальной инфраструктуры из реплик Veeam Backup & Replication после аварии или катастрофы на основной площадке предприятия.

По сути, это качественная замена неказистого продукта VMware Site Recovery Manager. Инженеры Veeam хорошо поработали и сделали один из самых интересных и нужных продуктов компании - теперь стратегии Data Protection и Disaster Recovery можно сделать на базе продуктов одного вендора. На днях Veeam Availability Orchestrator стал доступен для загрузки.

Давайте посмотрим на самые интересные возможности этого решения:

1. Документация инфраструктуры катастрофоустойчивости.

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

• Решение содержит 4 полностью кастомизируемых шаблона отчетности для катастрофоустойчивой инфраструктуры в удобном для пользователя формате.
• Возможность соответствия требованиям законодательства и комплаенсу в сфере disaster recovery. Также эти отчеты на регулярной основе не стыдно предоставлять директорам C-level (CEO, CIO и т.п.).
• Автоматическое обновление документации при внесении изменений в виртуальную инфраструктуру - то есть поддержание актуальности данных в отчетах.

2. Тестирование плана восстановления после сбоев.

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

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

3. Исполнение плана аварийного восстановления в случае аварии.

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

Здесь есть вот какие особенности:

• Верификация восстановления на уровне виртуальных машин, приложений и сервисов - например, для Microsoft Exchange, SQL Server и IIS — при фейловере с заранее определенным порядком запуска сервисов.
• Через открытый API процесс восстановления можно интегрировать с другими средствами обеспечения доступности ИТ-инфраструктуры.
• Доступ к средствам планирования и исполнения disaster recovery можно регулировать с помощью ролевой модели доступа (role-based access control, RBAC).

Более подробно о функциях Veeam Availability Orchestrator можно прочитать вот тут. Скачать продукт можно по этой ссылке.

Если вы зайдете на страницу поддерживаемых устройств ввода-вывода (I/O Devices) в списке VMware Hardware Compatibility List (HCL), то в правой колонке увидите там следующие параметры:

• VID (Vendor ID)
• DID (Device ID)
• SVID (Sub-Vendor ID)
• SSID (Sub-Device ID)

Все эти категории там не просто так - это очень удобный способ проверить совместимость вашего устройства ввода-вывода (сетевая карта, HBA-адаптер, SCSI-контроллер, USB-контроллер, и т.п.) с платформой VMware vSphere / ESXi и другими продуктами.

Например, если вы хотите узнать эти параметры для сетевой карты, то можно вывести список PCI-устройств командой vmkchdev, отфильтровав их с помощью grep по свойству vmnic (сетевой адаптер):

vmkchdev -l | grep vmnic

Далее вы увидите подобный вывод:

[dpasek@esx01:~] vmkchdev -l | grep vmnic

0000:02:00.0 14e4:1657 103c:22be vmkernel vmnic0

0000:02:00.1 14e4:1657 103c:22be vmkernel vmnic1

0000:02:00.2 14e4:1657 103c:22be vmkernel vmnic2

0000:02:00.3 14e4:1657 103c:22be vmkernel vmnic3

0000:05:00.0 14e4:168e 103c:339d vmkernel vmnic4

0000:05:00.1 14e4:168e 103c:339d vmkernel vmnic5

0000:88:00.0 14e4:168e 103c:339d vmkernel vmnic6

0000:88:00.1 14e4:168e 103c:339d vmkernel vmnic7

Здесь вот этот участок - 14e4:1657 103c:22be - для адаптера vmnic0 позволяет разложить его на 4 приведенных выше параметра:

• VID = 14e4
• DID = 1657
• SVID = 103c
• SSID = 22be

После этого вы просто вбиваете эти параметры в VMware HCL для I/O-устройств в правую колонку и смотрите, совместима ли данная сетевая карта с данной версией VMware ESXi.

Если вы отфильтруете вывод по строчке vmhba, то можете получить локальные SCSI-контроллеры или HBA-адаптеры, которые также можно проверить аналогичным образом.

Осенью прошлого года компания VMware выпустила девятую версию своего решения для управления виртуальной инфраструктурой сервис-провайдеров vCloud Director 9.0, а на днях это решение обновилось - вышел vCloud Director 9.1, где появилось достаточно много новых возможностей.

Давайте на них посмотрим:

1. Продолжение перехода на технологию HTML5.

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

Тут были сделаны следующие улучшения:

• Плагин Client Integration Plugin (CIP) для управления загрузками, в том числе виртуальных модулей OVF/OVA.

• Портал навигации по нескольким площадкам (виртуальным датацентрам):

• Простые воркфлоу создания виртуальной машины и виртуального сервиса vApp:

2. Поддержка отлельной утилиты VM Remote Console (VMRC) для соединения с консолью ВМ.

Раньше это было проблемой, теперь в контекстном меню ВМ можно скачать VMRC и запустить ее отдельно для доступа к консоли ВМ (нет необходимости в использовании vSphere CIP на HTML5-портале).

3. Интеграция с vRealize Orchestrator.

Теперь через Content или Service Library можно внедрять, настраивать и исполнять основные воркфлоу решения vRealize Orchestrator.

4. Поддержка Python SDK и vCD-CLI.

Теперь в vCloud Director появилось еще больше средств автоматизации на базе Python для операций как клиентов, так и сервис-провайдера. Более подробно об этом можно узнать вот тут.

5. Container Service Extension.

vCloud Director теперь обеспечивает управление жизненным циклом контейнеров кластеров K8s через расширение Container Service Extension (CSE). Узлы кластеров K8s обрабатываются точно так же, как и виртуальные машины. Поэтому теперь процесс управления контейнерами и ВМ единый.

Более подробно об этом можно почитать вот тут.

6. Поддержка запросов SR-IOV / NFV.

Это хорошая новость для клиентов, использующих виртуальные машины с критическими требованиями к низкому значению latency. Также появилась поддержка Large Page VM.

7. FIPS Mode for NSX.

Поддержка FIPS появилась еще в NSX 6.3.0, но теперь интеграция появилась в графическом интерфейсе vCloud Director (на уровне edge gateway).

8. Прочие изменения.

Также администраторам vCD следует учитывать следующие изменения:

• Переход на Cassandra 3.x для механизма метрик.
• Прекращение поддержки Oracle Database (9.1 - это последний релиз, который поддерживает БД Oracle).
• Прекращение поддержки vCloud API 1.5 и 5.1 уже в этом релизе.
• Админский интерфейс все еще построен на базе Flex, переход на HTML5 будет произведен позже (пока на базе этой технологии построены только регистрация vRO и мастер создания content library).
• Совсем скоро выйдут патчи для Usage Meter и vCloud Director Extender, которые позволят поддерживать этот релиз vCD. Следите за обновлениями.

Скачать VMware vCloud Director 9.1 можно по этой ссылке.

Некоторое время назад мы писали о том, что серверная облачная инфраструктура VMware vCloud on AWS является полноценным решением, а VMware vCloud для Azure - поделкой (оказалось, что второе - это решение даже не от VMware). Ну а на днях компания VMware официально анонсировала технологическое превью облачной инфраструктуры виртуальных ПК - Horizon on VMware Cloud on AWS.

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

Давайте посмотрим на основные преимущества данного решения:

1. Поддержка архитектуры Cloud Pod Architecture (CPA).

За счет CPA решение Horizon on VMware Cloud on AWS позволит создать географически распределенную инфраструктуру виртуальных десктопов, представляющую собой комбинацию из онпремизных площадок и облачных сайтов. При этом можно будет использовать преимущества почасового биллинга AWS.

2. Простое расширение инфраструктуры Horizon.

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

3. Application locality.

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

4. Disaster Recovery площадка.

Теперь с помощью облачной площадки Horizon в инфраструктуре AWS можно создать резервный сайт с виртуальными ПК, который возьмет на себя нагрузку в случае массового сбоя или катастрофы. Для бизнесов, где работа пользователей не должна останавливаться ни на секунду - это, зачастую, единственное решение без больших капитальных затрат.

Является ли Horizon on VMware Cloud on AWS решением Desktop-as-a-Service (DaaS)?

В общем смысле не является, так как пользователям придется самостоятельно развертывать компоненты решения VMware Horizon - например, Connection Server, Security Server и прочие составляющие решения. Соответственно, и поддерживать их (обновлять, решать проблемы) придется самостоятельно.

На рисунке ниже как раз показаны 3 модели управления виртуальными десктопами Horizon для тех фичей, которые находятся под контролем пользователя (Horizon on VMware Cloud on AWS - это второе):

На данный момент решение Horizon on VMware Cloud on AWS еще недоступно для пользователей, но в ближайшее время его доступность будет анонсирована, и мы обновим пост.

Год назад мы писали об обновлении утилиты RVTools 3.9.2, в котором появилась поддержка VMware vSphere 6.5. В конце февраля вышло обновление этого средства - RVTools 3.10, где появилась масса новых возможностей. Напомним, что RVTools - это утилита, которая помогает администраторам при выполнении рутинных операций с виртуальной инфраструктурой в различных аспектах.

Давайте посмотрим, что нового в RVTools 3.10:

• RVTools теперь сделана на Visual Studio 2017.
• Фреймворк .Net обновлен до версии 4.6.1
• Новые колонки на вкладке vInfo: настройка latency-sensitivity для ВМ, параметры Change Block Tracking (CBT) и значение disk.EnableUUID.
• Новые колонки на вкладке vDisk: SCSI label, unit number и sharedBus.
• Новые колонки на вкладке vHost: назначенные лицензии, ATS heartbeat, значения ATS locking (0 = disabled, 1 = enabled), короткое имя для Host Power Policy, текущая политика CPU Power Management, поддержка CPU power hardware.
• При экспорте в xlsx добавляется версия RVTools и дата/время в выходной файл.
• Все колонки экспортированного xlsx имеют фильтр.
• Новые строчки в csv-файле теперь заменены на пробелы.
• Если утилита работает из командной строки и возникают проблемы с логином - больше не появляется окошко ввода кредов, вместо этого утилита завершается с кодом -1.
• Добавлен пример сценария PowerShell, который позволяет объединять экспортированные xlsx-файлы.
• Добавлен пример сценария PowerShell, который позволяет экспортировать несколько серверов vCenter в один xlsx.
• Вкладка vDatastore: для датасторов NFS колонка с адресом заполняется полным путем к папке вместе с хостом.
• Новые колонки вкладки vDatastore: имя Datastore Cluster, общая емкость кластера и свободные ресурсы хранилищ.
• Верхняя граница хэлсчека (health check) виртуальных машин увеличена до 9999.
• Вкладка vHealth: новая колонка "message type", которую можно использовать как фильтр в Excel.
• Вкладка vHealth: файлы hbrdisk.RDID теперь не определяются как зомби-файлы.
• Вкладка vHealth: при высокой заполненности хранилища показывается также свободная емкость в мегабайтах.
• Все вкладки: обновление и автообновление учитывают порядок пользовательской сортировки.
• Параметры командной строки export2xls обновились на export2xlsx (старые также работают).
• Пакет Log4net обновлен до версии 2.0.8, Waffle.AD - до версии 1.8.3, NPOI - до версии 2.3.0.
• Ошибка соединения для TLSv1.0 и TLSv1.1 отключена и только для TLSv1.2 включена за счет использования .Net Framework 4.6.1.
• Дефолтная директория теперь поменялась на C:\Program Files (x86)\RobWare\RVTools и не содержит номера версии.

Скачать RVTools 3.9.2 для VMware vSphere 6.5 можно по этой ссылке. Документация доступна тут.

Многие из вас в производственной среде используют виртуальный модуль VMware vCenter Server Appliance (vCSA), представляющий собой готовую виртуальную машину с сервером управления виртуальной инфраструктурой.

Но не все знают, что есть простой способ обновить это средство (о нем мы упоминали вот тут). Для этого идем по адресу:

https://<IP-адрес vCSA>:5480

Где видим страницу логина в интерфейс Appliance Management:

Далее видим текущую версию vCSA в разделе Version и состояние сервера (Health Status):

В левой части выбираем раздел Update и далее пункт "Check Repository" (помните, что для этого на сервере vCSA должен быть интернет):

Далее вы увидите информацию о доступных обновлениях:

Далее выбираем пункт Install updates > Install all updates, чтобы запустить процесс обновления:

После этого сервер VMware vCSA будет обновлен, и можно будет его перезагрузить. Но у вас могут возникнуть проблемы с отображением health-статуса vCSA. Чтобы поправить это, нужно перезапустить все службы vCSA:

service-control –stop –all

service-control –start –all

После обновления убедитесь, что номер версии обновился в консоли Appliance Management (выделено жирным - 6.5.0.14100). Также полезно будет убедиться, что обновился и номер билда (build number) в консоли vSphere Web Client:

На днях компания VMware выпустила мажорное обновление своего основного интерфейса для управления виртуальной инфраструктурой с помощью скриптов - PowerCLI 10.0.0. О предварительных возможностях этого релиза мы уже писали вот тут.

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

1. Настоящая (почти) мульти-платформенность.

Теперь PowerCLI доступен для систем Mac OS и Linux. Единственное требование - у вас должен быть развернут PowerShell Core 6.0.

Установка очень проста:

Install-Module -Name VMware.PowerCLI -Scope CurrentUser

На данный момент для Мака и Linux поддерживаются только следующие модули:

• VMware.VimAutomation.Common
• VMware.VimAutomation.Sdk
• VMware.VimAutomation.Core
• VMware.VimAutomation.Cis.Core
• VMware.VimAutomation.Vds
• VMware.VimAutomation.Storage
• VMware.VimAutomation.StorageUtility

Со временем эта поддержка будет расширена.

2. Изменения обработки сертификатов.

Теперь при соединении с сервером vCenter или ESXi через командлет Connect-VIServer с невалидным сертификатом (например, самоподписанным) PowerCLI выдаст уже не предупреждение, как в прошлых релизах, а ошибку. Чтобы изменить это поведение, вам потребуется использовать командлет Set-PowerCLIConfiguration:

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore

Он принимает следующие значения:

• Fail
• Warn
• Ignore
• Prompt
• Unset

3. Устаревшие и исключенные командлеты.

Теперь в PowerCLI 10 пять командлетов модуля VMware.VimAutomation.Core были исключены:

• Get-VMGuestNetworkInterface
• Set-VMGuestNetworkInterface
• Get-VMGuestRoute
• New-VMGuestRoute
• Remove-VMGuestRoute

Они были заменены командлетом Invoke-VMScript. Вот пример использования этого командлета:

$ipAddr = "192.168.10.25"

$subMask = "255.255.255.0"

$gw = "192.168.10.1"

$netsh = "c:\windows\system32\netsh.exe interface ip set address ""Local Area Connection"" static $ipAddr $subMask $gw 1"

Invoke-VMScript -VM $VM -GuestCredential $creds -ScriptType bat -ScriptText $netsh

Также теперь не актуально свойство "Client", вместо этого предлагается использовать объект ServiceInstance.

Помимо этого в PowerCLI 10 было пофикшено несколько важных багов на базе фидбэка от сообщества разработчиков. Полный список изменений доступен в VMware PowerCLI Change Log. Более детальная информация об обновлении приведена в документах VMware PowerCLI 10.0.0 User’s Guide и VMware PowerCLI 10.0.0 Cmdlet Reference.

Напомним, что апдейт модулей PowerCLI теперь очень простой:

Update-Module VMware.PowerCLI

В этом материале мы расскажем о технологиях, которые компания NetApp — лидер на рынке систем хранения данных и решений для хранения и управления информацией — использует в своих продуктах. Если вы давно хотели систематизировать знания, но не находили время, мы сделали это за вас. Предлагаем вашему вниманию компактный глоссарий терминов и определений NetApp.

ONTAP и пиво — что общего?

Действительно, что может быть общего между операционной системой для СХД и пивом? Оказывается, существует довольно любопытная история происхождения буквосочетания ONTAP. Насколько она правдива — остается загадкой, но на страницах сообщества NetApp однажды появилось следующее: «ONTAP — это своего рода акроним, который сам по себе не имеет никакого смысла, тогда как название Data ONTAP было вдохновлено пивом. Идея заключается в том, что данные должны течь свободно, точно так же, как пиво из крана на барной стойке. К тому же название характеризует то, что люди думают о данных: они должны быть там и тогда, когда в них возникает необходимость, ведь не зря on tap означает «готовый к немедленному потреблению или использованию», олицетворяя то, что всегда находится под рукой».

FlexArray — лучшее средство для упрощения ИТ-операций

Недавно мы писали о решении VMware Workspace ONE, которое построено (в том числе) на базе продуктовой линейки AirWatch. Оно позволяет привести в соответствие корпоративным политикам инфраструктуру клиентских устройств (телефонов, планшетов, настольных ПК).

Так как системы Windows CE и Windows Embedded Handheld 6.5 уже пришли к своему концу в корпоративных средах, то многие организации начинают миграцию на системы Android Enterprise для своих смартфонов и планшетов. Ну а на днях компания VMware объявила о поддержке этой системы в своем решении Workspace ONE для специализированных (purpose-buit) устройств. Это такие устройства, которые выполняют однотипные операции и служат для выполнения специфической задачи. Например, это может быть инвентаризация склада с помощью сканера штрих-кодов или терминал продаж через телефон (mobile point-of-sale - mPOS).

Вот что может дать Android Enterprise для мобильной инфраструктуры предприятия, построенной на базе корпоративных унифицированных устройств:

• Единые средства управления существующим парком специализированных устройств компании (обновления, развертывание приложений).
• Доставка публичных и внутренних сервисов с использованием технологии Google Play Protect (анализ опасного поведения приложений).
• Адаптирование к требованиям рынка и поддержка основных приложений. За исключением iOS, на данный момент платформа Android является единственным решением для предприятий, где конечные пользователи могут использовать все последние приложения для бизнеса.

Поддержка Android Enterprise со стороны VMware Workspace ONE позволит выполнять следующие задачи:

• Развертывание и настройка приложений с учетом политик. Как правило, мобильные устройства находятся физически за пределами компании. Поэтому Workspace ONE позволит настроить VPN через Wi-Fi или LTE-соединения, провести развертывание приложения и поддерживать его в соответствии с заданными правилами. Например, можно настроить обновление приложения только после окончания рабочего дня, и только когда батарея достаточно заряжена.

• Доставка приложений и настройка окружения для пользователя. С помощью Workspace ONE можно настроить окружение специализированного устройства для одного или нескольких приложений таким образом, чтобы пользователю эти настройки были недоступны. Технология AirWatch Launcher позволит настроить устройство, например, в качестве средства для заказа в ресторане на столике посетителя. Также AirWatch поддерживает специфические OEM-сервисы, такие как, например, Zebra Mobility Extensions (Mx).

• Удаленное управление и контроль. Средства Workspace ONE позволяют проводить удаленное решение проблем, что очень актуально для сотрудников работающих "в поле". Например, если что-то не так с устройством водителя грузовика, но у него есть интернет - техподдержка может смотреть на экран устройства и в реальном времени решать проблему приложения, видя то же, что и водитель.

На данный момент поддержка Android Enterprise уже есть для следующих окружений:

• GMS-сертифицированные устройства с Android 5.0 Lollipop и более поздними.
• Решение AirWatch Console 9.2.
• Агенты Android Agent 8.0+ или Zebra Mx Service 3.0+.

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

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

Приведем данный список ниже:

Бизнес-задачи и проблемы

• Какие основные задачи стоят при внедрении?
• Какие проблемы заказчика предполагается решить?

Варианты использования платформы

• Какие варианты использования инфраструктуры VMware предполагает сам заказчик?

Требования/Ограничения/Допущения

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

Риски

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

A. Управление виртуальным датацентром

Решения в области логической архитектуры

• Общий объем объединяемых в пул ресурсов (вычислительные мощности, сети и хранилища).
• Какие сервисы будет предоставлять инфраструктура.
• Необходимый уровень доступности для систем управления платформой виртуализации.
• Интеграция со сторонними решениями: IT Service Management, Infrastructure Management systems, Enterprise services (DNS, LDAP, NTP, PKI, Syslog, SNMP Traps), сбор данных агентами систем различных вендоров.
• Необходимы ли расширенные операции, не предоставляемые из коробки?
• Механизмы защиты рабочих нагрузок гипервизора (vMotion, HA и другое).
• Механизмы балансировки нагрузки на гипервизор (DRS).

Решения в области физической инфраструктуры

• Гипервизор: версии ESXi.
• Нужен ли отдельный кластер управления?
• Серверы vCenter в режиме Standalone или Linked-Mode?
• Версия vCenter Server и тип установки (под Windows или в виде виртуального модуля).
• База данных vCenter Server - встроенная или внешняя?
• Механизмы защиты vCenter Server.
• Дизайн инфраструктуры Platform Services Controller (PSC). Будет ли один домен SSO?
• Нужна ли инфраструктура шифрования (PKI)? Какие требования к SSL?
• Какие компоненты vSphere будут использоваться?
• Нужна ли функциональность Host profiles?
• Вопросы управления обновлениями ESXi, версиями VM Hardware и версиями VMware Tools.
• Интеграция с антивирусами и решениями vShield/NSX.
• Нужен ли пакет vRealize Suite для расширенных операций и управления частным облаком?
• Нужен ли продукт vRealize Orchestrator для управления рабочими процессами операций? Нужен ли PowerCLI для сценариев автоматизации?
• Нужно ли интегрировать виртуальную инфраструктуру с другими средствами управления (Enterprise Management)?
• Automated vendor support mechanisms? How will VMware Skyline be used?
• Нужно ли организовывать интеграцию с системами Service Desk или Change Management?
• Каковы требования к механизмам vSphere HA и vSphere DRS?
• Если будет использоваться HCI (Hyper-Converged Infrastructure), то какие решения будут использоваться для управления, и как это будет совместимо с vSphere?
• Вопросы интеграции со службами DNS и NTP.
• Ролевая модель доступа (Role Based Access Control) и интеграция с LDAP.
• Какой интерфейс vCenter Server будет использоваться для администрирования и ежедневных операций (vSphere Client / Web Client).
• Модель лицензирования vCenter.
• Вопросы лицензирования стороннего ПО в виртуальных машинах (на хост, на виртуальный процессор vCPU и т.п.).

B. Вычислительные ресурсы

Решения в области логической архитектуры

• Традиционная архитектура, технология Server-Side Flash Cache Acceleration, конвергентная или гиперконвергентная инфраструктура (связано с хранилищами).
• Минимальное число хостов в кластере.
• Тип сайзинга хостов в кластерах: вертикальный (Scale Up) или горизонтальный (Scale Out)?
• Гомогенные или гетерогенные узлы?
• Число физических процессоров на хост.
• Резервирование уровня хостов в рамках доменов отказа (Failure Domains).
• Необходимая емкость по CPU.
• Необходимая емкость по RAM.

Решения в области физической инфраструктуры

• Вендор серверов.
• Тип процессоров серверов.
• Фичи CPU: VT-x, Hyper-threading, Turbo Boost, включена ли NUMA?
• Конфигурация серверного оборудования.
• Число сокетов CPU на узел.
• Модель процессора, частота и число ядер.
• Нужен ли GPU?
• Физическое размещение хостов.
• Тип размещения: Single Rack или Multi-Rack с шарингом ресурсов?
• Требования к доступности кластеров.
• Нужно ли обеспечить согласованность доступности хостов с доступностью хранилищ.
• Будущее расширение вычислительных ресурсов.

C. Хранилища

Решения в области логической архитектуры

• Традиционные хранилища, технология Server-Side Flash Cache Acceleration, конвергентная или гиперконвергентная инфраструктура (связано с вычислительными ресурсами).
• Блочные или IP-хранилища?
• Средства автоматизированного управления хранилищами.
• Допустимо ли использование RDM?
• Метод загрузки хоста ESXi - с локального диска (DAS), LUN или PXE.
• Толстые или тонкие диски для виртуальных машин?
• Необходимые ресурсы хранения.
• Репликация хранилищ.

Решения в области физической инфраструктуры

• Вендор систем хранения.
• Расчет используемой емкости хранилищ с учетом пулов хранения, затрат на репликацию и бэкап. Каковы численные требования к емкости и производительности хранилищ?
• Число дисков SSD и HDD в каждой из систем хранения.
• Использование дедупликации, сжатия данных, технологии Erasure Coding и Storage APIs. Нужно ли держать процент хранилищ всегда свободным?
• Какой активный Working Set (рабочий объем данных) необходим?
• Трешхолды для автоматизированного ярусного хранения данных (разнесения по ярусам).
• Использование шифрованных дисков и сервер KMS.
• Сеть хранения данных и ее организация.
• Механизм загрузки хстов ESXi.
• Технологии VM DirectPath I/O и SR-IOV.
• Число датасторов на кластер.
• Будут ли использоваться DRS и SIOC?
• Будут ли применяться VMDK shares на уровне виртуальных дисков?
• Будет ли использоваться технология VAAI?
• Использование VASA и профилей хранилищ (storage profiles).
• Будут ли использоваться синхронные или асинхронные DR-решения?
• Планирование расширения хранилищ.

D. Сетевая инфраструктура

Решения в области логической архитектуры

• Технология Legacy 3-Tier Switch, Collapsed Core или Clos-type Leaf/Spine?
• Кластеризованные физические или отдельные коммутаторы EoR/ToR?
• Растянутые логические VLAN или на уровне стойки?
• Трафик будет функционально разделяться на уровне виртуальных коммутаторов или отдельных VLAN?
• Будут ли использоваться Jumbo Frames?
• Требования Quality of Service (QoS).
• Балансировка нагрузки в сети (Load Balancing).
• Версия протокола IP.
• Соединения Inter-Data Center, включая RTT.
• Требуемая емкость и пропускная способность сети.
• Какие ВМ разрешены - с одним или несколькими vNIC?

Решения в области физической инфраструктуры

• Выбор вендора решения Clos-type Leaf/Spine для больших инсталляций. Либо использование архитектуры Core/Agg/Dist/Access switch.
• Фабрика коммутаторов типа Blocking или non-blocking?
• Если blocking, какое уровень переподписки (over-subscription ratio)?
• Каков путь трафика типа North/South и East/West?
• Где находятся шлюзы Layer 3 для каждой из подсетей?
• Требования к динамической маршрутизации (Dynamic Routing)?
• Нужен ли мультикаст?
• Будут ли использоваться End-to-End Jumbo Frames?
• Интерфейсы хостов ESXi: 1GbE и/или 10GbE? Сколько их будет на каждом хосте?
• Интерфейсы на хостах - LAG или unbonded?
• Слой управления для KVM и iLO/iDRAC/IPMI.
• Производительность физической сети LAN.
• Матрица связности хостов по сети передачи данных.
• Нужно ли Metro Ethernet между датацентрами?
• Использование QoS, Network Control и vSphere Network I/O Control.
• Будет ли использоваться Edge QoS или End-to-End QoS?
• Система vSphere NIOC и User-Defined Network Resource Pools.
• vMotion через несколько физических адаптеров одновременно.
• Использование VLAN Pruning.
• Использование Spanning Tree.
• Технологии VM DirectPath I/O и SR-IOV.
• Будет ли включена TCP Offload?
• Будут ли использованы стандартные vSwitch (VSS) или распределенные Distributed Switch (VDS).
• Разные vSwitches на кластер или общие?
• Использование технологий Teaming и Load Balancing.
• Порты VMkernel.
• Группы портов для виртуальных машин.
• Нужно ли решение VMware NSX-v?
• Планирование расширения сети по числу портов.

E. Защита данных

Решения в области логической архитектуры

• Частота резервного копирования большинства ВМ.
• Настройки бэкапов уровня Application Consistent и Database Consistent.
• Требования ко времени восстановления.
• Физическое разделение актуальных данных и бэкапов.
• Необходимые решения для бэкапа.
• Требования к производительности процесса резервного копирования.

Решения в области физической инфраструктуры

• Будет ли использоваться решение на базе VADP (например, Veeam Backup and Replication).
• Критерии для выбора решения по бэкапу.
• Требования к механизму резервного копирования и восстановления.
• Снапшоты уровня ВМ.
• Нужна ли асинхронная репликация снапшотов ВМ в удаленный кластер или публичное облако.
• Частота резервного копирования.
• Политика хранения резервных копий.
• Выделяемые емкости под хранение бэкапов и производительность процесса.
• Быстрое восстановление средств управления кластером на хосте ESXi.
• Рост объема хранения бэкапов и ресурсы для его обслуживания.

F. Виртуальные машины

Решения в области логической архитектуры

• Стандартные размеры ВМ (по уровням настроек - виртуальный диск, память, сеть, опции).
• Какие механизмы для CPU и RAM будут использоваться (например, Memory Ballooning)?
• Размещение файлов ВМ.
• Стандартизация гостевых ОС.
• Выбор между 64 и 32-битными системами.
• Использование шаблонов.

Решения в области физической инфраструктуры

• Стандартные размеры виртуальных машин и ресурсы для них.
• Планирование виртуальных сервисов vApps и пулов ресурсов.
• Размещение виртуальных машин на общих хранилищах.
• Стандартные настройки виртуальных дисков машин.
• Будут ли использоваться тонкие диски?
• Допустимы ли аппаратные снапшоты на уровне хранилищ или снапшоты vSphere?
• Будет ли включен Changed Block Tracking (CBT)?
• 32/64-битные версии гостевых систем.
• Адаптеры vSCSI.
• Виртуальные сетевые адаптеры vNIC.
• Версия виртуального аппаратного обеспечения (VM Hardware).
• Будут ли установлены VMware Tools и какой версии?
• Прочие стандартные настройки ВМ.
• Какие шаблоны ВМ будут использоваться?
• Настройки репозиториев шаблонов ВМ.
• Предложения по работе виртуальных машин с приложениями уровней Mission-Critical/Business-Critical.

G. Безопасность

Решения в области логической архитектуры

• Зоны и трасты.
• Нужна ли Defence-in-Depth?
• Будет ли решение мультивендоным?
• Физическое разделение сегментов сети.
• Стандарты, которые нужно соблюсти.
• Требования к защите инфраструктуры виртуализации и виртуальным машинам.
• Необходимый объем защиты сетевой инфраструктуры.

Решения в области физической инфраструктуры

• Физическое и виртуальное зонирование сетей.
• Сетевые экраны уровня приложений и уровня сетей.
• Системы IDS и IPS.
• SSL и сети IP-Sec VPN.
• Комплексная защита от сетевых угроз (Unified Threat Management)?
• Выбор вендора в сфере решений ИТ-безопасности.
• Нужно ли решение VMware NSX-v/T?
• Защита конечных устройств и выбор антивирусов.
• Производительность решений для сеNetwork Security Performance?
• Системы Security Information & Event Management (SIEM).
• Будет ли использоваться инфраструктура шифрования (Public Key Infrastructure, PKI)?
• Будет ли использоваться технология vSphere Cluster security? STIG?
• Технологии защиты хоста ESXi.
• Технологии защиты сетевого взаимодействия.
• Технологии защиты хранилищ.
• Технологии защиты резервных копий.
• Технологии защиты виртуальных машин.
• Будет ли будущее расширение инфраструктуры и какие дополнительные средства могут понадобиться?

H. Непрерывность бизнеса / восстановление после аварий (BC/DR)

Решения в области логической архитектуры

• Какие механизмы защиты будут использоваться?
• Ручные или автоматические сценарии восстановления? Регламент ручных действий.
• Политики RPO, RTO, WRT и MTD для приложений различной степени критичности (Mission-Critical, Business-Critical и Non-Critical).
• Как использовать глобальные балансировщики (Global Site Load Balancers).
• Параметры DNS TTL для клиентов.

Решения в области физической инфраструктуры

• Нужны ли решения по катастрофоустойчивости?
• Нужен ли продукт VMware SRM или Veeam Availability Suite?
• Нужно ли решение GSLB?
• Использование внутренних и внешних DNS-серверов.
• Уровень катастрофоустойчивости - нужна ли синхронная репликация на географически удаленные кластеры?
• Репликация на несколько площадок, репликация баз данных и Message Queue clustering/replication.

На днях компания VMware обновила пару своих утилит на сайте проекта VMware Labs, которые могут оказаться вам полезными.

Во-первых, решение VMware vCenter VM Mobility, о котором мы писали вот тут, обновилось до версии 1.5. Напомним, что это средство позволяет через интерфейс командной строки (CLI) перенести машину между серверами vCenter, которые связаны в режиме Linked Mode или размещены независимо друг от друга. Надо отметить, что в режиме Linked Mode и так можно перемещать виртуальную машину между датацентрами, поэтому полезна утилита именно для несоединенных vCenter.

Давайте посмотрим, что нового появилось в версиях vCenter VM Mobility 1.2-1.5:

• Добавлена возможность выбрать папку ВМ в месте назначения, а также storage pod (для механизма storage drs).
• Поддержка соединения на сайте назначения, чтобы не прервалась задача перемещения ВМ.
• Пофикшен баг, когда при миграции нескольких виртуальных машин с одной виртуальной сетью назначения мигрировалась только одна.
• Поддержка передачи пароля в качестве аргумента для автоматизации задач клонирования и перемещения ВМ между датацентрами.

Скачать VMware vCenter VM Mobility 1.5 можно по этой ссылке. Напомним, что утилитой лучше не пользоваться для миграции связанных клонов ВМ (linked clones).

Вторая обновившаяся утилита - это DRS Lens, про которую мы рассказывали вот тут. Она позволяет администраторам виртуальных инфраструктур получить больше информации о работе механизма балансировки нагрузки на хост-серверы VMware vSphere DRS.

На днях вышла версия DRS Lens версии 1.2. Приведем ниже новые возможности утилиты версий 1.1-1.2:

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

Скачать DRS Lens 1.2 можно по этой ссылке.

Некоторые из вас знают, что VMware и другие производители в последнее время борются с уязвимостями Meltdown и Spectre в процессорах Intel, выпуская и отзывая патчи для различных компонентов ИТ-инфраструктуры. Мы писали об этом не так давно в следующих заметках:

• Вышел VMware vCenter Server Appliance 6.5 Update 1f - исправлена уязвимость Meltdown и Spectre (частично)
• Производительность хост-серверов VMware ESXi и других платформ после наката патчей для Meltdown и Spectre
• Для VMware vSphere, Workstation и Fusion пофикшена уязвимость Spectre
• Скрипт для проверки виртуальной инфраструктуры VMware vSphere на подверженность уязвимости Spectre

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

Напомним основные статьи VMware KB, касающиеся исправлений данных уязвимостей:

• https://kb.vmware.com/s/article/52245 
• https://kb.vmware.com/s/article/52337

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

Один из сотрудников VMware опубликовал полезную заметку о том, как с помощью решения vRealize Operations Manager можно отслеживать производительность хостов ESXi в кластерах VMware HA/DRS и на основе этого принимать решения о патчинге тех или иных производственных сред и кластеров.

1. Трекинг версий BIOS и хостов ESXi для каждого сервера с использованием дэшборда Host Configuration.

Этот инструмент нужен, чтобы не забыть пропатчить хост-серверы ESXi:

2. Просмотр информации об использовании виртуальными машинами системных ресурсов.

3. Также надо смотреть на изменения CPU и Memory Usage на уровне кластера с помощью дэшборда Capacity Overview.

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

5. Также если у вас есть 2 кластера, которые выполняют одну функцию в плане рабочих нагрузок - вы можете переместить нагрузки с помощью функции Workload Balance.

6. Возможность перераспределения емкости кластера можно узнать с помощью дэшборда Capacity Reclaimable.

7. Использование кастомных дэшбордов для Meltdown и Spectre.

Это возможно, если у вас издание vRealize Operations Advanced или более высокое, так как оно позволяет создавать кастомные дэшборды. Сотрудники VMware, Iwan Rahabok, Mark Scott и Luciano Gomes, разработали специальные дэшборды, которые сфокусированы на конфигурации, производительности, емкости и утилизации виртуальной инфраструктуры. Скачать все три дэшборда вместе с инструкциями можно по этой ссылке.

Эти следующие три дэшборда:

• Performance Monitoring
• Planning Guest OS Patching
• Tracking vSphere Patching

7.1 Дэшборд Performance Monitoring.

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

7.2 Дэшборд Planning Guest OS Patching.

Этот дэшборд нужен для того, чтобы спланировать патчинг гостевых ОС. Сначала находятся все простаивающее ВМ, апдейт которых не сильно повлияет на функционирование виртуальной инфраструктуры, а в последнюю очередь идет обновление так называемых "heavy hitters" - рабочих лошадок вашего предприятия, апдейт которых должен проводиться с особой осторожностью.

7.3 Дэшборд Tracking vSphere Patching.

Этот дэшборд помогает планировать апгрейд различных версий VMware ESXi, а также версий виртуального аппаратного обеспечения (Virtual Hardware) виртуальных машин. Он решает 2 практические задачи:

• Отслеживание номеров билдов VMware ESXi и прогресса патчинга серверов.
• Отслеживание Virtual Hardware различных ВМ.

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

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

Блогер Ryan Kelly написал интересный пост, в котором он сравнивает оба решения - и выводы явно не в пользу vCloud on Azure. Давайте посмотрим:

1. Управление.

VMware vCloud on AWS - это полноценный vSphere Client, к которому вы привыкли в вашем датацентре. Все те же средства автоматизации операций и скрипты PowerCLI работают в облаке без необходимости их доработки.

VMware on Azure имеет собственную консоль управления, а также свой API, что потребует адаптации ваших решений и сценариев PowerCLI. Таким образом, вам нужно будет поддерживать 2 набора рабочих процессов, при этом персонал должен иметь два набора умений для этого, что обходится дороже и неудобно.

2. Миграция рабочих нагрузок в облако и обратно.

vMotion между онпремизной инфраструктурой и облаком происходит без изменения IP-адреса, используется растянутый кластер под контролем решения NSX. Серверы управления vCenter объединены режимом Linked Mode.

В облаке vCloud on Azure миграция vMotion не поддерживается, нужно копированием переносить виртуальные машины, а IP-адрес в любом случае поменяется при перенесении ВМ в облако (кстати, обратного пути миграции нет):

3. Стоимость решения.

Для VMware vCloud on AWS используется модель Host-based pricing, то есть покупаете нужное количество хостов, а все остальные лицензии (включая хранилища кластера vSAN) уже включены в цену. На хосте вы можете создать сколько угодно и какие угодно виртуальные машины. Подробности в прайс-листе.

Для vCloud on Azure лицензирование идет по инстансам виртуальных машин, а за хранилище надо платить отдельно. Вот прайс-лист.

4. Катастрофоустойчивость на уровне площадок.

vCloud on AWS обеспечивает полную связность площадок, прозрачную для пользователей. С помощью технологии Host based replication образ ВМ реплицируется между облаком и онпремизным сайтом, шарится общий IP-адрес. В случае сбоя на одной из площадок, для восстановления работоспособности сервиса нужно будет только нажать на кнопку.

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

Из описанных пунктов может следовать еще несколько неудобств, но даже перечисленных уже достаточно, чтобы не покупать VMware vCloud on Azure. Непонятно пока, кому такая гибридная инфраструктура подойдет - разве что совсем маленьким компаниям, не собирающимся расти.

Как вы знаете, некоторое время назад были обнаружены серьезные уязвимости в процессорах компании Intel, условно называемые Meltdown и Spectre. Вскоре после их обнаружения многие производители выпустили обновления микрокода оборудования, многие из которых оказались неготовыми к эксплуатации в производственной среде (происходили неожиданные перезагрузки, падала производительность и появлялись другие эффекты).

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

Теперь, наконец, вышло обновление VMware vCenter Server Appliance 6.5 Update 1f, содержащее исправления для серверов управления на базе виртуального модуля с Photon OS на борту, исправляющее следующие дыры в безопасности:

• Bounds-check bypass (уязвимость Spectre-1, CVE-2017-5753)
• Rogue data cache load issues (уязвимость Meltdown, CVE-2017-5754)

Надо отметить, что уязвимость Spectre-2 (Branch target injection - CVE-2017-5715) по-прежнему не исправлена в данном релизе.

Патч VMware vCenter 6.5 Update 1f можно загрузить с VMware Patch Portal (VMware-VCSA-all-6.5.0-7801515.iso):

В процессе апдейта будут обновлены следующие пакеты:

• linux 4.4.110-2
• libgcrypt 1.7.6-3
• c-ares 1.12.0-2
• ncurses 6.0-8
• libtasn1 4.12-1
• wget 1.18-3
• procmail 3.22-4
• rsync 3.1.2-4
• apr 1.5.2-7

Также помимо VMware vCSA патч доступен и для решения vSphere Integrated Containers 1.3.1. На данный момент матрица выхода апдейтов фикса Meltdown и Spectre выглядит весьма удручающе (более подробно - вот тут):

Пропатчить VMware vCSA можно также через GUI из дефолтного репозитория обновлений продукта.

Ну и мы все еще ждем обновления для хостов VMware ESXi, которые до сих пор в статусе "Patch Pending".

Гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего услугу аренды виртуальных машин VMware из облака.

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

BelkaCar — облачный каршеринг нового формата

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

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

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

Tata Motors, облачные порталы и ямы на дорогах

Крупнейшая автомобилестроительная компания Tata Motors и ее «дочки» Jaguar и Land Rover являются активными потребителями облака, поскольку используют облачную площадку в качестве технологической основы. Так, Tata Motors в своей работе ориентируется на специализированные порталы, вынесенные в облако провайдера, которые помогают владельцам автопарков отслеживать транспортные средства в режиме реального времени. Такой подход позволяет сократить сроки реализации инфраструктурных проектов и повысить скорость работы необходимых для бизнеса сервисов... Читать статью далее->>.

Как вы знаете, у компании VMware есть такой продукт Workspace ONE, который позволяет привести в соответствие корпоративным политикам инфраструктуру клиентских устройств (телефонов, планшетов, настольных ПК) с помощью купленной когда-то технологии AirWatch unified endpoint management (UEM). Помимо средств защиты и соблюдения комплаенса, Workspace ONE дает пользователям средства совместной работы и Single Sign-On для приложений, а работодателю - средства контроля над устройствами пользователей (соблюдение комплаенса, то есть корпоративных политик).

На днях команда AirWatch опубликовала заметку о новых возможностях обновленной версии Workspace ONE Mobile Apps Suite. Теперь, как вы видите на картинке выше, в состав Workspace ONE войдут следующие компоненты:

• People Search - это новый компонент, который позволяет получать информацию о людях в вашей организации, включая контактные данные, должность и иерархию подчинения. Очень удобно для тех, кто сидит на митинге и хочет узнать, что за хрены там тоже собрались. Если вы уже имеет в составе решений VMware Indentity Manager, то интегрировать People Search будет очень просто. Данные об организационной структуре будут браться из Active Directory, а какие поля будут видны пользователям - определяет администратор.

• VMware Boxer - это решение для почтовых сервисов Gmail, Exchange, Outlook, Yahoo, Hotmail, iCloud и Office 365 для протоколов IMAP и POP3, которое позволяет объединить все на платформе одного почтового клиента, интегрировав туда поддержку таких приложений, как Dropbox или Box.

Проще говоря, это почтовый Enterprise-клиент. В новой версии VMware Boxer будет улучшен механизм нотификаций для пользователей (нижний блок на скриншоте выше), а также добавлена поддержка IBM Lotus Notes.

• VMware Browser - это компонент для защищенного (без необходимости развертывать VPN) доступа к веб-содержимому корпоративной сети и интернета с возможностью ограничения просматриваемого и загружаемого контента. Теперь с помощью этого защищенного политиками браузера можно переходить по ссылкам из QR-кодов.

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

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

Более подробная информация о решении VMware Workspace ONE изложена на специальном портале.

Компания VMware выпустила обновленную версию документа "Network Ports in VMware Horizon Cloud Service", в котором приведены диаграммы портов и соединений сервиса VMware Horizon Cloud. Данные диаграммы нужны для корректной настройки фаерволов, а также отслеживания сетевых коммуникаций между компонентами (стрелками в документе показаны их направления).

В документе приведены 3 архитектуры VMware Horizon Cloud, которые рассматриваются в различных его разделах:

• Horizon Cloud with Hosted Infrastructure with external connectivity
• Horizon Cloud with Hosted Infrastructure with internal connectivity
• Horizon Cloud on Microsoft Azure

Диаграммы работают в интерактивном режиме, то есть вы можете выбрать интересующий вас компонент (например, протокол Horizon) и "провалиться" глубже для подробного изучения его соединений. Для этого нужно PDF скачать, а не просматривать его в браузере.

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

Также в документе рассматриваются такие продукты, как VMware Identity Manager, VMware App Volumes, VMware ThinApp и другие решения, использующиеся в инфраструктуре Horizon. Соответственно, его можно использовать и как референс при планировании и развертывании онпремизной или облачной инфраструктуры Horizon Cloud.

Скачать документ Network Ports in VMware Horizon Cloud Service можно по этой ссылке. Также посмотрите наш пост "Диаграмма портов и соединений VMware Horizon 7 - обновления".

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

Давайте посмотрим на последние фичи vSphere Client версии 3.34:

• Визуализация топологии виртуальных коммутаторов (см. на скриншоте выше).
• Возможность пакетного создания виртуальных адаптеров VMkernel на распределенной группе портов vDS.
• Действие по привязке лицензи (Assign License) на вкладке License Assets.
• Сообщение об устаревающих лицензиях vCenter.
• Изменение настроек виртуальных сервисов vApp.
• Включение и изменение настроек vApp для его виртуальных машин.
• Перемещение сетей (networks) и распределенных коммутаторов в новые папки типа network в инвентори.
• Пакетная привязка физических сетевых адаптеров к аплинкам в мастере "Add and Manage Hosts" на распределенном коммутаторе.
• Пакетная привязка портов VMkernel к порт-группам "Add and Manage Hosts" на распределенном коммутаторе.
• Отображение дополнительной информации, такой как состояние питания и информации Quiesce/memory для снапшотов виртуальных машин.

Загрузить VMware vSphere Client 3.34 можно по этой ссылке.

Иногда у администраторов VMware vSphere появляется проблема на сервере VMware vCSA (виртуальный модуль vCenter), когда дисковое пространство в разделе /var/log забивается под завязку. Например, если выполнить команду ls, то получим вот такую картину:

vcsa-01:/var/log # ls -lh

total 4.6G

-rw-r----- 1 dnsmasq dnsmasq  17M Feb  4 08:32 dnsmasq.log

-rw-r----- 1 dnsmasq root    844M Jan 28 07:45 dnsmasq.log-20180128

-rw-r----- 1 dnsmasq dnsmasq 3.7G Feb  2 16:19 dnsmasq.log-20180204

Здесь мы видим целых 4,6 ГБ логов! Такая ситуация - не редкость, поэтому иногда нужно поменять настройки заполнения и ротации логов, чтобы раздел не забивался. В данном случае растет лог dnsmasq - кэша сервера DNS и DHCP на сервере vCSA (подробнее тут).

Вот тут мы уже писали о том, как сменить еженедельную ротацию на ежедневную, а теперь немного более подробно посмотрим на проблему. По этому вопросу есть специальная статья VMware KB - "Root partition on the vCenter Server Appliance is full due to dnsmasq.log files".

В качестве решения предлагается отредактировать файл /etc/logrotate.d/dnsmasq до следующего состояния:

/var/log/vmware/dnsmasq.log {

nodateext # добавляем эту строчку

daily # меняем со значения weekly

missingok

notifempty

compress # меняем со значения delaycompress

maxsize 5M # добавляем эту строчку

rotate 5 # добавляем эту строчку

sharedscripts

postrotate

[ ! -f /var/run/dnsmasq.pid ] || kill -USR2 `cat /var/run/dnsmasq.pid`

endscript

create 0640 dnsmasq dnsmasq

}

Кстати, размещение файла логов можно изменить в файле /etc/dnsmasq.conf, для этого надо поменять вот эту строчку:

log-facility=/var/log/vmware/dnsmasq.log

Сам же данный конфигурационный файл рекомендуется сделать таким:

listen-address=127.0.0.1

bind-interfaces

user=dnsmasq

group=dnsmasq

no-negcache

no-hosts

log-queries

log-facility=/var/log/vmware/dnsmasq.log

domain-needed

dns-forward-max=150

cache-size=8192

neg-ttl=3600

После этого перезапускаем сервис dnsmasq:

vcsa-01:~ # service dnsmasq restart

Shutting name service masq caching server

Starting name service masq caching server

Блогер David Pasek опубликовал интересный пост, касающийся ограничения виртуальных машин и их виртуальных дисков по числу операций ввода-вывода. Смысл его в том, что автор, являющийся ярым сторонником обеспечения QoS на уровне виртуальных дисков, настоятельно рекомендует применять ограничения IOPS limit к виртуальным дискам машин, которые потенциально могут выесть много полосы ввода-вывода.

Сейчас ограничивать виртуальные машины по IOPS можно как на уровне виртуальных дисков на томах VMFS/RDM/NFS, так и на уровне томов VVols. Многие системы хранения оперирует понятием логического тома LUN, на котором размещается один том VMFS. Как правило, LUN - это логический том, что значит, что несколько LUN могут размещаться на одной физической группе дисков:

Таким образом, виртуальные машины, потребляющие много IOPS от хранилища (он называет их "noisy neighbor") могут существенно замедлить работу других производственных систем.

Поэтому для таких машин требуется создавать ограничения IOPS limit, которые можно задать для виртуального диска в опциях машин, либо привязать к VMDK диску политику с ограничениями по IOPS.

Например, в vSphere Web Client создаем новую VM Storage Policy с ограничениями IOPS limit for object:

А далее привязываем эту политику к диску VMDK в настройках ВМ:

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

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

Ну и в заключение несколько аспектов данного рода ограничений:

• Команды ввода-вывода (IO) нормализуются к блоку 32 КБ, то есть команда в 128 КБ будет преобразована в 4 IO.
• IOPS limit не влияет на операции SVmotion (миграция хранилища), XVmotion (миграция машин без общего хранилища) и клонирование ВМ.
• IOPS limit применяется только ко вводу-выводу гостевой ОС и не затрагивает операции с самим диском VMDK и его swap-файлами.
• Если у машины несколько лимитов по IOPS для дисков на одном датасторе, то эти лимиты складывают и применяются для всей ВМ на этом датасторе в целом. Если же диски находятся на разных хранилищах, то тут уже действуют правила для каждого из групп дисков.
  • Например, если у каждой из 4 дисков машины на одном датасторе стоит лимит 100 IOPS, то для всей машины будет совокупный лимит 400. То есть, если три VMDK едят по 10 IOPS каждый, то четвертый диск сможет съесть максимум 370 IOPS.
  • А вот для NFS-хранилищ все работает несколько иначе - если у каждого из 4 дисков на одном датасторе стоит лимит 100 IOPS, то сколько бы ни потребляли остальные диски, для каждого из дисков будет применен максимальный лимит 100.
• Полная информация об ограничении ввода-вывода для виртуальных машин приведена в KB 1038241.

Также рекомендуем почитать нашу статью "VMware Storage I/O Control (SIOC) - как это работает на практическом примере".

На днях вышел магический квадрант Gartner Magic Quadrant for Hyperconverged Infrastructure (HCI), отражающий ситуацию на рынке гиперконвергентной инфраструктуры. Это такая инфраструктура, где все ее вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

Компания VMware заняла в этом квадранте место в тройке лидеров (надо отметить, что учитывались не только онпремизные, но и облачные HCI-инициативы), расположившись рядом со своей материнской компанией Dell EMC.

Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:

• полнота видения (completeness of vision)
• способность реализации (ability to execute)

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

• Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
• Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
• Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
• Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.

Кстати, Magic Quadrant по серверной виртуализации больше не публикуется (вы, возможно, заметили, что его не было в 2017 году) - так как Gartner считает этот рынок зрелым, там все и так всем понятно, поэтому никакой аналитической работы проводить не нужно.

Стоит отметить, что попадание в квадрант лидеров для VMware как для поставщика чисто программных решений - большое достижение. Сейчас VMware использует аппаратные решения 15 партнеров, чтобы предлагать HCI-решения пользователям. Пример такой архитектуры - VCE и Vblock. Кстати, Dell EMC, в свою очередь, продвигает решения VxRail и VxRack, в состав которых входит решение для создания кластеров отказоустойчивых хранилищ vSAN.

Кстати, если говорить о серверных HCI-решениях, то VMware уже сейчас поддерживает более 400 моделей серверов (на картинке от мая 2017 года было еще 250 моделей) в рамках программы ReadyNode для построения кластеров vSAN.

Скачать отчет Gartner Magic Quadrant for Hyperconverged Infrastructure (HCI) можно по этой ссылке.

В конце прошлого года VMware сделала доступным для загрузки обновленную версию решения для обеспечения сетевой безопасности VMware vRealize Network Insight 3.6. Напомним, что о версии vRNI 3.5 мы писали осенью прошлого года в рамках анонсов VMworld 2017.

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

• Улучшения в анализе инфраструктуры (Enhanced Visibility):
  • Netflow от физических устройств теперь можно добавить в целях планирования безопасности и решения проблем для приложений, включая физические серверы. Кроме того, пользователи, у которых нет распределенного коммутатора vSphere Distributed Switch (vDS), могут использовать Netflow при проведении аудита виртуальной сети (Virtual Network Assessment).
  • Клиенты, работающие в AWS GovCloud, теперь могут использовать vRNI для планирования безопасности и траблшутинга в AWS окружении.
  • Добавлена поддержка решения Palo Alto Panorama 8, а также коммутаторов Arista и Juniper, что улучшает сбор информации в физической и виртуальной сетевой инфраструктуре.
• Функции быстрого решения проблем:
  • В разделе Flow analytics появилась информация о самых обменивающихся по сети системах, а также об активности новых систем за 24 часа, что позволяет быстрее идентифицировать и решать проблемы.
  • Новый виджет AWS Security Group быстро позволяет находить проблемы в инфраструктуре AWS.
  • Появилась поддержка групп безопасности и правил сетевого экрана решения NSX-T.
• Функции открытой платформы:
  • vRealize Network Insight 3.6 предоставляет публичный API для автоматизации рабочих процессов. Например, рекомендуемые правила сетевого экрана для приложения можно получить через vRNI и далее уже применить через решение NSX и фаерволы AWS.

Скачать VMware vRealize Network Insight 3.6 можно по этой ссылке.

Дункан Эппинг написал интересную заметку о максимальных настройках виртуальных машин, защищенных средствами кластера непрерывной доступности VMware Fault Tolerance.

Некоторые из вас знают, что у Fault Tolerance есть ограничения как по числу одновременно защищенных виртуальных машин на хосте, так и по числу виртуальных процессоров (vCPU) на один хост ESXi. Напомним, что эти ограничения были улучшены в VMware vSphere 6.0, теперь можно с помощью FT защищать машины с четырьмя vCPU, а всего таких машин может быть до четырех штук. Но при этом заявлено, что для FT не может быть более 8 vCPU на хосте (то есть 4 машины по 4 vCPU в каждой поддерживать не получиться).

Но это, оказывается, только в дефолтной конфигурации. Для регулирования этих параметров есть две расширенные настройки (Advanced Settings) кластера HA/DRS:

• das.maxftvmsperhost - максимальное число защищенных ВМ на хост (4).
• das.maxFtVCpusPerHost - максимальное число защищенных vCPU на хост (8).

Они по умолчанию равны значениям, описанным выше, но вы можете выставить свои значения - и это будет работать. Тогда откуда они взялись? Очень просто - инженеры взяли типовые нагрузки, посадили их на адаптер 10G и получили, что хост потянет где-то 8 vCPU для Fault Tolerance (4 машины по 2 vCPU). Это условие выполняется при старте машин пользователем, миграциях vMotion, а также механизмом DRS при расчете рекомендаций.

Но у вас своя инфраструктура (может уже и адаптеры 40 Gbps), поэтому вы можете использовать какие захотите разумные значения. Кстати, если вы поставите значение 0, то кластер VMware DRS будет полностью игнорировать данное требование к числу FT-машин на хост.

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

На днях компания VMware начала тестировать новую версию своего фреймворка для управления виртуальной инфраструктурой и выпустила VMware PowerCLI Beta.

Как вы помните, в конце 2016 года VMware на сайте проекта VMware Labs опубликовала утилиту PowerCLI Core, которая позволяет пользователям применять те же самые командлеты PowerCLI на системах Linux, Mac и Docker, которые ранее были доступны только для Windows.

В новой бета-версии PowerCLI эта утилита будет не нужна, так как теперь PowerCLI будет работать на всех платформах в рамках единого пакета, а из состава продукта для платформ Linux и MacOS уйдет слово "Core". На данный момент эта бета была протестирована на следующих платформах:

• Windows
• CentOS 7 (тестирование еще в процессе)
• Ubuntu 16.04
• MacOS 10.12

В этой бета-версии на все платформы были портированы следующие модули:

• VMware.VimAutomation.Sdk
• VMware.VimAutomation.Common
• VMware.VimAutomation.Core
• VMware.VimAutomation.Vds
• VMware.VimAutomation.Cis.Core
• VMware.VimAutomation.Nsxt
• VMware.VimAutomation.Vmc
• VMware.VimAutomation.Storage
• VMware.VimAutomation.StorageUtil

Для MacOS и Linux вы увидите только перечисленные модули, остальные пока не доступны. Устанавливать их нужно так:

$installOrder = @(  
    "VMware.VimAutomation.Sdk",  
    "VMware.VimAutomation.Common",  
    "VMware.VimAutomation.Cis.Core",  
    "VMware.VimAutomation.Core",  
    "VMware.VimAutomation.License",  
    "VMware.VimAutomation.Vds",  
    "VMware.VimAutomation.Storage",  
    "VMware.VimAutomation.Cloud",  
    "VMware.VimAutomation.vROps",  
    "VMware.VimAutomation.PCloud",  
    "VMware.VimAutomation.Nsxt",  
    "VMware.VimAutomation.vmc"  
)  
$installOrder | %{install-module $_ -AllowPrerelease -repository PSGallery}  

Более подробную информацию о VMware PowerCLI Beta можно получить вот тут. Ну и вам надо знать, что бета работает только на PowerShell Core v6.0.1 (на версии 6.0.0 работать не будет).