Осенью прошлого года мы писали о выходе бета-версии операционной системы VMware Photon OS 4.0 Beta, использующейся в виртуальных модулях VMware (Virtual Appliances), которые реализуют различные вспомогательные сервисы.
На днях вышла финальная версия Photon OS 4.0, давайте посмотрим, что там появилось нового:
Главные улучшения
Ядро реального времени для приложений телекома и vRAN (Virtual Radio Network)
Наступает эра 5G, и VMware сделала в Photon OS 4.0 возможности поддержки телеком-приложений реального времени на уровне ядра (Photon Real Time kernel). Это позволит технологиям vRAN (Virtual Radio Network) использовать возможности ОС Photon при развитии инфраструктуры 5G-операторов. Для этого появился специальный kernel flavor, который называется "linux-rt". Вместе с остальными компонентами (userspace-пакетами) этот режим называется Photon Real Time (RT).
Безопасность
Photon 4.0 получила поддержку таких технологий по обеспечению безопасности, как SELinux, Security Encrypted Virtualization – Encrypted Status и Intel Software Guard Extensions. Обязательная система контроля доступа, прошитая на уровне ядра, позволяет SELinux дать администраторам гранулярный и гибкий доступ к ресурсам. Также Photon OS позволяет из коробки, на уровне политик, обеспечить нужды приложений в изоляции. Также поддерживается SELinux для контейнеров, что было протестировано для docker, containerd и runc.
Поддержка драйверов Intel SGX drivers позволяет приложениям использовать ресурсы CPU для создания "анклавов" - полностью защищенных модулей исполнения, недоступных на аппаратном уровне другим процессам.
Обновленный механизм сетевой конфигурации
Теперь
Photon 4.0 имеет полностью переработанную библиотеку network configuration management library вместо netmgr, которая предоставляет API для большинства задач конфигурации (IP-адреса, маршруты, DNS и прочее). То есть вместо файлов конфигурации можно использовать API.
Оптимизации производительности для решения vSphere with Tanzu
Исторически Photon ОС имела специальный контекст ядра linux-esx, который был специальным образом оптимизирован для работе на платформе VMware ESXi точки зрения производительности и предоставляемых возможностей. В Photon 4.0 то же самое появилось и для контейнерной среды исполнения vSphere with Tanzu, например, уменьшение времени запуска для контейнеров и приложений.
Прочие улучшения
- Поддержка
Raspberry Pi 4
-
Для ARM-архитектуры доступны образы в формате OVA и AMI
- В tdnf добавлена поддержка расширенной конфигурации сервисов безопасности
- Ядро обновлено до версии 5.10
(декабрь 2020)
Установщик и обновления
Поддержка распределенных билдов с использованием Kubernetes
Доступность установщика Photon OS в виде RPM-пакета
Поддержка нескольких дисков в image builder
Поддержка самоподписанных SSL-сертификатов в kickstart-установке из ISO-образа
Для RPM используется механизм zstd по умолчанию
Состав пакета
Готовые образы для облачного развертывания в Microsoft Azure (новое), Google Compute Engine (GCE), Amazon Elastic Compute Cloud (EC2) и продуктах VMware (vSphere, Fusion и Workstation)
Критические обновления следующих пакетов:
Linux kernel 5.10 LTS
Glibc 2.32
systemd 247
Python3 3.9
Openjdk : 1.8.0.265, 11.0.9
Openssl : 1.1.1
Cloud-init: 20.4.1
GCC: 10.2.0
Обновленные версии основных пакетов, доступные в репозиториях
Скачать VMware Photon OS 4.0 в виде OVA-пакета или ISO-образа можно по этой ссылке.
На днях в различных источниках появились сообщения об уязвимости CVE-2021-21972, которая есть в сервисах vCenter, что может привести к удаленному исполнению кода злоумышленником. Уязвимость по степени критичности оценивается на 9.8 из 10 (по шкале Common Vulnerability Scoring System Version 3.0) и имеет полное описание на сайте VMware как VMSA-2021-0002.
Интересно, что примеры реализации эксплоитов для Windows и Linux на базе этой уязвимости появились как минимум в шести разных местах, включая репозитории на GitHub (например, тут, тут и тут).
VMware сразу же выпустила патч к этой уязвимости, который вы можете загрузить по этой ссылке.
После публикации уязвимости начались массовые сканирования серверов vCenter (кстати, не удивительно, что уязвимость нашел русский инженер, вот ее описание):
Уязвимость использует дырку в плагине vRealize Operations, который установлен по умолчанию, для неавторизованной загрузки файлов по порту 443, после чего становится доступным удаленное исполнение кода в операционной системе vCenter со всеми вытекающими.
В общем, всем нужно поскорее накатывать патч, так как любой с доступом к порту 443 сервера vCenter может потенциально получить к нему полный доступ.
Уязвимость CVE-2021-21972 затрагивает версии vCenter Server 6.5, 6.7 и 7.01. Соответственно, вам нужно накатить 6.5 Update 3n, 6.7 Update 3l или 7.0 Update 1c как можно скорее. Если накатить сейчас не можете, то временный workaround описан в KB 82374.
Недавно компания VMware обновила свое решение Hybrid Cloud Extension (HCX), предназначенное для миграции с различных онпремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на базе VMware vCloud. Версия HCX 4.0 предоставляет возможности большего контроля над процессами миграции, минимизации времени простоя, а также упрощении реконфигурации политик безопасности VMware NSX после миграции.
Давайте посмотрим на новые возможности VMware HCX 4.0:
1. Новая система нумерации релизов и обновленные политики жизненного цикла
Теперь систему версий можно просто представить вот так:
Кроме того, изменились политики жизненного цикла VMware N-2 Lifecycle Policy, которые теперь учитывают новую систему версионирования. Каждый минорный и мажорный релиз HCX будет поддерживаться минимум 12 месяцев со дня выхода.
2. Оценка времени миграции
Теперь решение HCX в реальном времени может оценить время, которое вам понадобится на миграцию нагрузок в виртуальных машинах. Используя механику Mobility Groups, платформа HCX позволяет оценить время миграции каждой конкретной ВМ, составив из этих оценок прогноз по времени миграции группы.
Для первичного развертывания механизм Migration Estimation будет поддерживать только метод миграции Bulk Migration, а в будущем появится поддержка методов vMotion и Replication-Assisted.
3. Информация о событиях миграции
Для всех типов миграции (Bulk, vMotion, Replication-Assisted vMotion и OS-Assisted) предоставляется детальная информация об этих событиях. Там показаны данные всех событий, потоков рабочих процессов, также статусы текущих миграций и многое другое:
Такой уровень детализации очень поможет администраторам при решении проблем, связанных с миграцией рабочих нагрузок в облако. Более подробно об этом вы можете узнать из этого видео.
4. Инфоормация о виртуальных модулях Network Extension
HCX 4.0 предоставляет детальную информацию обо всех расширяемых сетях, реализуемых виртуальными модулями Network Extension (NE). Для них можно увидеть такие параметры, как bit rate, bytes transmitted и received, packet rate, packets transferred и received, с интервалом обновления в 1 минуту. Находится это на вкладке Network Extension Details в разделе Connection Statistics.
5. Перевод виртуальных модулей Network Extension в режим In-Service во время обновления
Виртуальные модули NE могут использоваться не только в процессе миграции, но и после него. Для таких ситуаций теперь есть специальный режим In-Service (как режим обслуживания в vSphere), который позволяет апгрейдить виртуальные модули, сокращая потенциальный простой инфраструктуры и минимизировать прерывания процессов.
6. Миграция тэгов NSX Security Tags
Пользователи VMware NSX Distributed Firewall на источнике миграции могут смигрировать тэги NSX Security Tags в инфраструктуру публичного облака. Это работает для методов миграции Bulk Migration, HCX vMotion, HCX Replication-Assisted vMotion (RAV) и cloud-to-cloud mobility migration. Существующие тэги могут быть на базе решений NSX for vSphere и NSX-T.
Демо процесса миграции тэгов можно посмотреть вот тут.
Ну и в завершение - полезные ссылки, включая ссылку на скачивание VMware HCX 4.0:
Команда PowerCLI компании VMware на днях выпустила обновление средства vSphere Desired State Configuration (DSC) версии 2.2. Механизм DSC есть в экосистеме Windows, начиная еще с Windows Server 2012 R2. С помощью него можно мониторить и управлять конфигурациями систем посредством специальных конфигурационных файлов на базе PowerShell, которые имплементируются через движок Local Configuration Manager (LCM), который должен быть на каждом хосте.
У VMware этот механизм работает несколько иначе, в качестве LCM используется прокси-хост, поскольку LCM не запустить ни на vCenter Server Appliance, ни на ESXi:
Так работал механизм до текущего момента, когда пользователям приходилось разворачивать отдельную Windows-машину под LCM. Но теперь появился модуль VMware.PSDesiredStateConfiguration, который предоставляет пользователям набор командлетов, чтобы скомпилировать и исполнить конфигурацию DCS без использования DSC Local Configuration Manager. Это позволяет использовать как Windows, так и Linux-машину в качестве прокси.
При этом пользователям по-прежнему предоставляется возможность использовать как vSphereDSC с движком PowerShell LCM, так и модуль VMware.PSDesiredStateConfiguration.
Давайте посмотрим, что нового появилось в DCS версии 2.2:
1. Новые ресурсы PowerCLI модуля
Вот они:
DatastoreCluster - создание, изменение, апдейт или удаление Datastore cluster
3. Операция Install/Update для модуля VMware vSphereDSC
Установка модуля теперь делается так:
Install-Module -Name VMware.vSphereDSC
Обновление вот так:
Update-Module -Name VMware.vSphereDSC
4. Новый модуль VMware.PSDesiredStateConfiguration
Как было сказано выше, теперь вы можете использовать Windows или Linux-машину без LCM для использования механизма DCS. Установить модуль можно следующей командой:
Новый командлет New-VmwDscConfiguration создает объект VmwDscConfiguration, который содержит информацию о конфигурации. Эту конфигурацию можно задать в ps1-файле и передать ее данному командлету. Например:
С помощью vSphere Node можно указать объект VINode (сервер vCenter или хост ESXi) и применить соответствующую конфигурацию к нужному узлу vSphere. Это дает следующие возможности:
Персистентные сессии
Раньше для каждого подключения каждый ресурс требовал параметров учетной записи для установки сессии VISession. Теперь же если вы используете Vmware.PSDesiredStateConfiguration то можно создать персистентную VISession, которую можно использовать для всех ресурсов DCS.
Не нужны файлы MOF
Поскольку LCM теперь не используется, то и для командлета New-VmwDSCconfiguration они не требуются. Конфигурация может храниться в переменной, либо в ps1-файле.
Скачать VMware vSphere DSC 2.2 можно по этой ссылке.
За последние дни на сайте проекта VMware Labs обновились некоторые полезные утилиты, а также были выпущены две новые - Workspace ONE Access Migration Tool и VCF Powernova.
Workspace ONE Access Migration Tool - это средство, которое позволяет упростить миграцию приложений от одного облачного клиента (tenant) к другому. Это может быть как в онпремизной, так и в SaaS-среде. Также это может быть полезно в целях отзеркаливания приложений одного тенанта к другому.
Возможности данной утилиты по миграции приложений:
Копирование категорий приложений (App Categories)
Миграция веблинков (сторонних IDO)
Создание ссылок на федерированные (federated) приложения и копирование иконок (чтобы для пользователя ничего не менялось после миграции)
Копирование App Assignment в раздел Category mapping
Скачать Workspace ONE Access Migration Tool можно по этой ссылке.
Вторая утилита - это средство VMware Cloud Foundation Powernova, которое позволяет проводить массовые операции по включению/выключению виртуальных машин по всему инвентарю виртуального датацентра VMware Cloud Foundation.
Утилита очень будет полезна в случае обслуживания инфраструктуры, а также при миграции VCF-окружений или необходимости отключить/подключить на время отдельные домены VCF.
Пока данное средство не работает для следующих окружений:
Хосты vXRail
Домены рабочей нагрузки WCP/Tanzu
Вложенные (Nested) хосты ESXi
Скачать VMware Cloud Foundation Powernova можно по этой ссылке.
В понедельник мы писали новой версии решения для автоматизации рабочих процессов VMware vRealize Orchestrator 8.3, а сегодня расскажем еще об одном обновленном продукте семейства vRealize - VMware vRealize Operations 8.3 (vROPs). Напомним, что о прошлой версии vROPs 8.2 мы подробно писали вот тут.
Давайте посмотрим, что нового появилось в апдейте vROPs 8.3, тем более, что там как и всегда - масса новых функций:
1. Cloud Management Assessment (COA)
Эта функция является логическим продолжением vSphere Optimization Assessment (VOA) в vRealize Operations. Теперь COA позволяет расширить эти возможности за пределы vSphere для следующих задач:
Подготовка к миграции на VMware Cloud on AWS
Управление решением VMware Cloud on AWS
Подготовка к миграции на VMware Cloud Foundation
Управление решением VMware Cloud on Foundation
Использование vRealize Cloud Universal
Управление публичным облаком (AWS, Azure и т.п.)
Управление решением Horizon
Для запуска этой утилиты надо нажать "+View More" на странице QuickStart и выбрать VMware vRealize Cloud Management Assessment:
Далее просто выберите нужную подкатегорию:
Дэшборды представляют облачную инфраструктуру в разных разрезах и дают массу полезной информации с объяснениями:
2. Функция Pathfinder
Pathfinder - это коллекция обучающих материалов VMware, которые представлены в виде удобных 10-15 минутных блоков (их более 100 штук).
Также движок Pathfinder напрямую интегрирован в CMA:
3. Поддержка FIPS 140-2
Operations 8.3 содержит криптографические модули, которые прошли тестирование по программе NIST FIPS 140-2 Cryptographic Module Validation Program (CMVP). Этот режим (FIPS-mode) можно выбрать только при новой установке, в процессе эксплуатации поменять его на обычный будет нельзя.
4. Метрики с циклом опроса в 20 секунд
По умолчанию метрики vROPs собираются раз в 5 минут, что обусловлено балансом между массивом хранимых и анализируемых данных и гранулярностью получения информации администратором.
Теперь же данные собираются раз в 20 секунд, а в истории хранятся средние данные раз в 5 минут, но полученные из усреднения этих 20-секундных значений. Подробнее об этом написано в KB 67792.
Иногда бывает так, что и усреднение не дает результата, так как оно сглаживает пиковые всплески, которые неплохо бы увидеть в реальном времени. Для этой цели есть механизм near real-time metric collection, который позволяют хранить точные данные за последние три дня:
Также есть и механизм 20-second peak metrics, который покажет пиковые значения для нужных метрик в 20-секундных интервалах:
5. Функции VMware Cloud on AWS
Теперь появились новые деревья для инвенторя инстансов SDDC, который реализован в объекте VMC World. Эти объекты унифицируют vCenter, vSAN и NSX-T в контексте сущностей VMC Organizations и SDDC.
Новый дэшборд VMC Configuration Maximums позволяет следить за приближением к хард и софт лимитам инфраструктуры. Для этого есть цветовое кодирование и алерты:
Новых алертов на эту тему аж 23 штуки:
Также можно создать VMC Configuration Maximum Report:
Текущие лимиты получаются через VMC API, но не все. Также можно подстроить их в разделе Administration / Configuration / Configuration Files / SolutionConfig / vmc_config_limits (подробнее в KB 81810).
6. Функции vRealize Operations Cloud
С момента последнего релиза стал доступен датацентр во Франкфурте:
vRealize Operations Cloud теперь сертифицирован по стандартам SOC 2, SOC 3 и ISO 27001/17/18.
Также появился новый дэшборд vRealize Operations Billing Usage, где показываются объекты, для которых собираются метрики в вашей инфраструктуре:
Более полный список новых возможностей вы можете найти в Release Notes. Скачать vROPs 8.3 можно по этой ссылке.
Недавно компания VMware выпустила обновленную версию продукта vRealize Orchestrator 8.3 (vRO), который входит в семейство решений vRealize и взаимодействует с такими продуктами, как vRealize Automation и vRealize Suite. Orchestrator предназначен для автоматизации большинства рутинных операций и рабочих процессов в облаке на базе VMware vSphere. О версии Orchestrator 8.1 мы, кстати, писали вот тут.
Давайте посмотрим, что нового VMware добавила в Orchestrator 8.3:
1. Роль Viewer
Теперь с помощью этой роли можно в режиме просмотра получить доступ к объектам и страницам Orchestrator. Пользователь с этой ролью не может создавать, редактировать или запускать рабочие процессы или оперировать с другими объектами, такими как действия, конфигурации, ресурсы, политики и запланированные задачи.
Роль показана в интерфейсе настройки ролей как Orchestrator Viewer:
Для такого пользователя будет доступно только действие Open с объектами:
Также режим просмотра будет и в Scripting Editor:
Эта роль может быть полезна для групп мониторинга и аудита.
2. Места использования и зависимости
Теперь в интерфейса можно узнать, где используется часть рабочего процесса и найти связи с другими элементами:
3. Улучшения юзабилити
Теперь табличные представления можно фильтровать по имени, типу и описанию в дата гридах:
После применения фильтра, можно отсортировать результаты по имени:
И после этого применить еще один фильтр, например, нам нужны только булевые переменные:
Параметр фильтра вписывается во всплывающем окошке прямо в гриде по клику на иконку:
4. Поддержка стандарта Federal Information Processing Standards (FIPS)
Orchestrator 8.3 содержит криптографические модули, которые прошли тестирование по программе NIST FIPS 140-2 Cryptographic Module Validation Program (CMVP). Этот режим (FIPS-mode) можно выбрать только при новой установке, в процессе эксплуатации поменять его на обычный будет нельзя.
Более подробно о новых возможностях VMware vRealize Orchestrator 8.3 рассказано тут и тут. Release notes находятся здесь. Скачать vRO 8.3 можно по этой ссылке.
На сайте проекта VMware Labs появилась очередная полезная штука - Community Networking Driver for ESXi. Этот пакет представляет собой комплект нативных драйверов под ESXi для сетевых адаптеров, подключаемых в разъем PCIe.
Драйверы можно установить для VMware ESXi 7.0 или более поздних версий, а список поддерживаемых устройство выглядит так:
Установить драйвер можно с помощью команды:
esxcli software vib install -d /path/to/the offline bundle zip
После этого нужно обязательно перезагрузить ваш ESXi, до перезагрузки сетевой адаптер работать не будет.
Также если вы хотите использовать драйвер для Intel NUC 11, вам нужно будет встроить его в образ ESXi (Image Profile). Для этого можно использовать графический интерфейс Image Builder в vSphere Client, либо Image Builder CLI на базе PowerCLI.
Скачать пакет драйверов Community Networking Driver for ESXi можно по этой ссылке.
Компания VMware на днях выпустила обновленную версию инфраструктуры VMware Cloud Foundation (VCF) версии 4.2. Напомним, что это комплексное программное решение, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager. О версии платформы VCF 4.1 мы писали вот тут.
Давайте посмотрим, что нового в VCF 4.2:
Поддержка vSAN HCI Mesh Support - теперь VCF поддерживает технологию HCI Mesh в кластерах vSAN, позволяющую использовать емкости удаленных кластеров.
Поддержка NSX-T Federation - теперь можно объединять несколько доменов рабочей нагрузки в одном представлении с помощью Global Manager.
Статические IP-пулы для сетей NSX-T Host Overlay (TEP) - их можно использовать как альтернативу DHCP.
Поддержка режима lockdown mode на хостах ESXi - их можно включать для доменов рабочей нагрузки через vCenter.
Разное: VCF 4.2 включает в себя проверки валидации паролей, оптимизации производительности API, а также улучшения сообщений об ошибках ESXi.
Интерфейс SDDC Manager включает в себя страницу Release Versions с информацией о новых возможностях продукта VCF, составе инфраструктуры и датах окончания поддержки.
В интерфейсе SDDC Manager и через API можно фильтровать бандлы обновлений по целевым релизам, чтобы удобнее было обновляться только на нужные версии.
Поддержка vRealize Automation для облачного аккаунта. Можно интегрировать SDDC Manager и домены рабочей нагрузки с VMware Cloud Assembly как облачными аккаунтами VCF (подробнее тут).
Поддержка сервисных виртуальных машин с использованием образов vSphere Lifecycle Manager (vLCM). Это позволяет развернуть NSX-T Guest Introspection (GI) и NSX-T Service Insertion (SI) в доменах рабочей нагрузки с использованием vLCM.
Обновлен список продуктов и их версий, входящих в инфраструктуру VCF (из главного - vRealize Suite 8.2, NSX-T 3.1 и последние версии vSphere и Horizon).
Полный список возможностей VMware Cloud Foundation 4.2 приведен в Release Notes. Есть также отдельный документ по версии для VxRail.
На днях компания VMware запустила сервис Customer Connect, предназначенный для клиентов компании, которым нужны сервисы для обучения, поддержки инфраструктуры своих продуктов и управления активами, такими как лицензионные ключи, evaluation-версии продуктов и прочее.
Это ребрендинг известного всем сервиса My VMware, который теперь имеет много нового функционала и объединяет различные ресурсы:
Основные задачи, которые призван решать новый портал Customer Connect:
Управлять активами (продукты, лицензии) и данными пользователя
Найти контент для решения проблем или ответ на вопросы о продуктах VMware с мощными функциями поиска
Взаимодействовать с другими пользователями в рамках комьюнити
Вовлекать в программы с экспертами VMware или тренинги с инструкторами в целях прохождения сертификаций
Создавать тикеты в поддержку для оперативного решения проблем
Управлять назначениями прав и командами на уровне заказчика
На портале используются механизмы AI и Machine Learning, чтобы оптимизировать поисковую выдачу и дать нужные инструменты пользователям для скорейшего решения проблем.
В состав обновленного сервиса входят следующие компоненты:
Connect Knowledge - это набор механизмов, который позволяет получить доступ к контенту о продуктах VMware, собранному на различных ресурсах, таких как статьи Knowledge Base, TechZone, документация, блоги и другие.
Connect Communities - это форумы, где можно задать вопрос и следить за дискуссиями вокруг горячих тем.
Connect Learning - это бывший ресурс VMware Learning Zone. Здесь можно записываться и проходить курсы, сдавать экзамены и получать сертификации - все то, что помогает улучшать свой технический профиль и отслеживать прогресс.
Connect Support - тут можно общаться с технической поддержкой и решать проблемы в соответствии с условиями вашей действующей подписки на продукты VMware. Тут же есть и виртуальный ассистент с умными подсказками, содержащими возможные пути решения проблем.
Connect Success - это специальный ресурс для пользователей, купивших подписку VMware Success 360. Она подразумевает персональную заботу об инфраструктуре клиента, где идет постоянный мониторинг ее состояния по методике Health Scorecard. Сотрудники VMware в этом случае заботятся не только о доступности компонентов, но и о производительности и достижении бизнес-показателей. Пока этот сервис не интегрирован в Customer Connect (планируется запустить его во втором квартале этого года).
Специальный сервис App Launcher в Customer Connect позволяет управлять такими компонентами, как:
Загрузки и пробные версии продуктов
Лицензии
Пользователи и разрешения
База знаний VMware
Специальные утилиты (Skyline, Sizing Guidelines и прочие)
Доступ к порталу VMware Customer Connect можно получить по этой ссылке.
На днях компания VMware обновила свой главный документ, касающийся обеспечению безопасности виртуальных сред и самой платформы виртуализации - VMware vSphere 7 Security Configuration Guide. Напомним, что о его прошлой версии осенью прошлого года мы писали вот тут.
Давайте посмотрим, что появилось нового в обновленном SCG для vSphere 7, который традиционно состоит из PDF-файла описания и XLS-файла настроек, рекомендаций и пояснений:
Исправлены ошибки в рекомендациях PowerCLI для аудита виртуальных машин.
Добавлена вкладка "Deprecated" - там теперь будут те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).
Настройка svga.vgaOnly перемещена в Deprecated. Она ограничивает ВМ на использование только VGA-разрешений, а многие современные ОС этого очень не любят (могут даже отключить отображение картинки в этом случае).
Добавлены и обновлены рекомендации по отключению сервисных служб SLP и CIM на сервере ESXi. Эти протоколы часто не используются (их не используют и продукты VMware), поэтому лучше их отключить.
Добавлены рекомендации по изоляции сети. Раньше как-то само собой подразумевалось, что нужно разделять сети управления, vMotion и vSAN, теперь же это формализовано в документе. Там же рекомендовано и физическое разделение сетей.
Добавлена рекомендация по использованию только тех продуктов, старые версии которых еще официально поддерживаются со стороны VMware (например, вы можете выполнить все рекомендации и накатить все обновления, но использовать старый ESXi 5, что по понятным причинам небезопасно).
Добавлено руководство по использованию модулей Trusted Platform Modules 2.0 (TPM).
Снова возвращена рекомендация vm-7.pci-passthrough, касающаяся прямого доступа виртуальных машин к оборудованию, в частности шине PCIe.
Добавлено руководство по отключению интерфейсов DCLI, если вы не используете его на vCenter Server. Также вам не нужно держать SSH постоянно открытым, так как в vSphere широкий и защищенный API, который вы можете использовать в разных фреймворках и утилитах.
Скачать VMware vSphere 7 Security Configuration Guide (как и руководства для других версий vSphere) можно по этой ссылке. Подробнее о документе также можно почитать тут.
Многие администраторы VMware vSphere знают, что для организации кластеров Windows Server Failover Clusters (WSFC) нужен эксклюзивный доступ к LUN, а значит на уровне виртуальной инфраструктуры подходили только RDM-диски. Ранее эти кластеры назывались MSCS, мы писали об их организации в виртуальной среде вот тут.
Такая ситуация была из-за того, что WSFC использует механизм резервация SCSI-3 Persistent Reservations, который координирует доступ к общему дисковому ресурсы. С другой стороны, VMFS использует собственный механизм блокировки LUN, поэтому команды WSFC перехватываются и отменяются, если используются диски VMDK. Поэтому RDM-устройства и использовались как средство маппинга дисков виртуальных машин к физическому устройству LUN.
Оказывается, ситуация поменялась с выпуском VMware vSphere 7, где появился механизм Clustered VMDK. Он позволяет командам SCSI3-PR выполняться и применяться к виртуальному диску VMDK, поэтому вам не нужен отдельный LUN.
К сожалению, все это работает только на хранилищах Fibre Channel.
Чтобы это начать использовать, на уровне датастора надо установить параметр "Clustered VMDK Supported":
Далее нужно понимать следующие условия и ограничения:
Параметр кластера Windows Cluster "QuorumArbitrationTimeMax" должен быть выставлен в значение 60.
LUN за этим датастором должен поддерживать команды ATS SCSI (как правило, это всегда поддерживается).
LUN должен поддерживать резервации типа Write Exclusive All Resgistrants (WEAR).
VMDK-диски должны быть типа Eager Zeroed Thick и виртуальные машины должны быть как минимум в режиме совместимости с vSphere.
Не презентуйте LUN, которые используются как кластерные VMDK, для хостов ESXi версий ниже 7.0.
Не комбинируйте датасторы для clustered и non-clustered VMDK на одном общем кластерном хранилище.
Выделяйте один датастор на один кластер WSFC, не шарьте один датастор между несколькими инстансами кластеров WSFC.
Максимумы конфигураций для таких кластеров WSFC следующие:
Надо помнить еще о следующих ограничениях (более подробно тут):
Конфигурация Cluster in a Box (CIB) не поддерживается. То есть надо настроить правила anti-affinity DRS Rules, чтобы разделить узлы кластера / виртуальные машины по разным хостам ESXi. Если вы попробуете такую ВМ с помощью vMotion переместить, то миграция завершится неудачно.
Горячее расширение VMDK кластерной ВМ не поддерживается.
Не поддерживается Storage vMotion и снапшоты.
VMFS 5 и более ранние версии не поддерживаются.
Таги: VMware, vSphere, WSFC, MSCS, ESXi, VMDK, Storage, Microsoft
На сайте VMware Labs появился интересный инструмент Virtualized High Performance Computing Toolkit, который может оказаться полезен компаниям, использующим VMware vSphere для организации высокопроизводительных вычислений (High Performance Computing, HPC). Такие комплексные вычислительные задачи, как правило, вовлекают параллельные вычисления, аппаратное ускорение (такое как GPU и FPGA), а также используют высокоскоростные каналы, такие как RDMA.
Все это требует определенных конфигураций VMware vSphere, для настройки которых и нужно данное средство. С помощью него, используя vSphere API, можно дать администраторам инструменты по сопровождению задач HPC, таких как клонирование ВМ, настройка Latency Sensitivity, сайзинг виртуальных машин по CPU и памяти и многое другое.
Основные возможности тулкита:
Настройка устройств PCIe в режиме DirectPath I/O, таких как GPGPU, FPGA и RDMA
Простое создание и уничтожение кластеров HPC с помощью файлов конфигураций
Выполнение задач vSphere, таких как клонирование, настройка vCPU, памяти, резерваций, shares, Latency Sensitivity, обычного и распределенного виртуального коммутатора, сетевых адаптеров и конфигураций
Например, клонирование 4 виртуальных машин с заданными кастомизациями CPU и памяти, а также добавлением NVIDIA vGPU с профилем grid_p100-4q выглядит так:
На сайте проекта VMware Labs очередная новая утилита - SDDC Import/Export for VMware Cloud on AWS. С ее помощью можно сохранять конфигурацию виртуального датацентра SDDC в облаке VMConAWS, а также импортировать ее из сохраненной копии.
Иногда пользователи по разным причинам хотять мигрировать из одного SDDC-датацентра в другой. Для миграции виртуальных машин есть решение VMware HCX, а вот для переноса конфигурации среды до текущего момента не было. Теперь же можно сохранить конфигурацию исходного SDDC и развернуть ее на целевом, не тратя много времени на повторную настройку.
Это может вам, например, пригодиться для проведения миграций в следующих случаях:
Миграция с одного на другой SDDC с разным типом железа (например, с i3 на i3en)
Миграция с одного на другой SDDC с VMware-based организации на AWS-based
Миграция с одного на другой SDDC в другом регионе (например, из Дублина в Лондон)
Также есть вот такие полезные юзкейсы:
Сохранение бэкапов конфигураций SDDC
Быстрое развертывание преднастроенного SDDC для тестовых целей
Развертывание конфигурации на DR-площадке в связке с VMware Site Recovery Manager или VMware Cloud Disaster Recovery
Вот небольшое видео о том, как работает утилита:
Скачать SDDC Import/Export for VMware Cloud on AWS можно по этой ссылке.
Наш постоянный читатель Сергей обратил внимание на то, что на днях компания VMware выпустила обновление своего главного фреймворка для управления виртуальной инфраструктурой с помощью сценариев - PowerCLI 12.2. Напомним, что о прошлой версии PowerCLI 12.1 осенью прошлого года мы писали вот тут.
Давайте посмотрим, что нового появилось в обновленном PowerCLI 12.2:
1. Поддержка VMware Horizon
Модуль PowerCLI для управления инфраструктурой Horizon теперь поддерживается для macOS и Linux OS.
2. Инфраструктура VMware Cloud
Появилась поддержка одного из самых популярных сервисов для обеспечения катастрофоустойчивости датацентров - DRaaS. Новые командлеты позволяют включать/отключать DRaaS в виртуальном датацентре VMC SDDC, а также добавлять и удалять инстансы SRM (Site Recovery Manager).
Вот так выглядит включение DRaaS:
Управление инстансами SRM происходит с помощью командлетов:
Компания VMware выпустила обновление продукта vRealize Log Insight 8.3, предназначенного для поиска любых данных в виртуальной инфраструктуре, анализа лог-файлов и визуализации аналитики. О прошлой версии Log Insight 8.2 мы упоминали вот тут.
Давайте посмотрим, что нового появилось в Log Insight 8.3:
1. Поддержка стандарта Federal Information Processing Standard (FIPS) 140-2
В новой версии реализована поддержка стандарта от National Institute of Standards and Technology (NIST), который регулирует использование криптографических модулей в программных продуктах, используемых в государственных организациях.
После того, как вы включите режим FIPS, его нельзя уже будет отключить. После включения потребуется перезагрузка хостов кластера, поэтому он будет переведен в режим обслуживания.
Можно настроить предупреждающее сообщение:
Можно добавить кнопку I agree в конце диалогового окна:
2. Поддержка аутентификации cross-domain group-based authentication для пользователей vIDM
Пользователи продукта для единой аутентификации VMware Identity Manager теперь могут использовать группы из разных доменов Active Directory, между которыми есть траст.
3. Возможность загрузки LI Agent без аутентификации
Агент решения Log Insight (LI Agent) теперь можно скачивать напрямую и через API по ссылке https://<server>/api/v1/agent/install-packages/msi (можно использовать окончание пути для разных форматов /msi, /bin, /deb и /rpm).
Скачать VMware vRealize Log Insight 8.3 можно по этой ссылке.
Недавно появилась новость о том, что некое Ransomware использует уязвимости на хостах с гипервизором VMware ESXi для того, чтобы получить контроль над виртуальными машинами и зашифровать их диски VMDK, после чего злоумышленники просят выкуп у компаний за их расшифровку.
Речь идет об эксплуатации уязвимостей CVE-2019-5544 и CVE-2020-3992, касающихся недоработок протокола Service Location Protocol (SLP) и удаленного исполнения кода в ESXi и VMware Horizon DaaS (десктопы как услуга).
Про уязвимость CVE-2020-3992 мы писали вот тут, на данный момент она полностью пофикшена, но есть немало компаний, где политика обновлений оставляет желать лучшего, и где много непропатченных хостов ESXi используется в производственной среде.
Сообщается, что в атаке, которая произошла в прошлом году, группировка RansomExx (они же Defray777) смогла получить доступ к серверам ESXi инфраструктуры нескольких компаний и зашифровать диски виртуальных машин, которые были доступны этому ESXi. Информация об этом инциденте есть в ветке на Reddit.
По шагам атака выглядела так:
Три пользователя в компании установили троян, который послали по почте.
Атакующие получили привилегии, используя уязвимость CVE-2020-1472. На рабочих станциях стоял антивирус Касперского, который на тот момент не имел сигнатур этого трояна.
Атакующие получили доступ к хостам, которые, в свою очередь, имели доступ к подсети управления ESXi, так как у злоумышленников были админские привилегии в AD.
Без необходимости компрометации vCenter они просто запустили код на ESXi, используя две описанные выше уязвимости.
Это привело к созданию скрипта на питоне, который шифровал диски VMDK. Вот тут приведено более детальное объяснение.
Избежать всего этого было просто - надо было вовремя пропатчить рабочие станции и серверы, ну и конечно не запускать трояны из письма:)
Администраторы VMware vSphere в больших инфраструктурах иногда используют кластеры Windows Server Failover Clusters (WSFC) на базе RDM-дисков, которые доступны для хостов VMware ESXi. Ранее они назывались Microsoft Cluster Service (MSCS). При использовании таких кластеров время загрузки хоста ESXi может вырасти аж до целого часа, если не поставить этим LUN статус Perennially reserved.
Суть проблемы в том, что WSFC ставит SCSI-3 reservations для своих LUN, используемых активным узлом, и если ESXi видит эти тома (то есть они не отмаскированы для него), то он безуспешно пытается получить к ним доступ. Для этого он делает несколько попыток при загрузке, пока не решает перейти к следующим томам. Статус этих операций вы можете увидеть, если нажмете Alt+F12 при загрузке хоста:
Xavier Avrillier написал статью о том, как с помощью esxicli/PowerCLI пометить такие тома как Perennially reserved, чтобы ESXi пропускал их при сканировании (об этом также рассказано в KB 1016106).
Сначала вам надо узнать LUN canonical name устройства. Делается это следующей командой PowerCLI:
Многие администраторы в крупных инфраструктурах сталкиваются с проблемами назначения и обновления лицензий компонентов VMware vSphere - серверов ESXi и vCenter. Это можно сделать в графическом интерфейсе vSphere Client, но когда у вас много хостов, это становится муторным делом, во время которого легко ошибиться или просто устать:) Давайте посмотрим, как можно просто это делать через PowerCLI...
Иногда администратор VMware vSphere задается вопросом о происхождении виртуальной машины - из какой родительской ВМ/шаблона она была клонирована? Вильям Лам разбирает это в своей статье, приведем вкратце его метод определения происхождения ВМ.
Как вы знаете, бывает три типа клонирования виртуальных машин в VMware vSphere:
Full Clone - это полный клон, то есть независимая копия виртуальной машины, у которой нет ничего связанного с родительской ВМ, это просто ее полная копия.
Linked Clone - это копия виртуальной машины, которая имеет общие диски с родительской, доступные на чтение (это экономит пространство и позволяет просто откатываться к родительскому образу). Уникальные данные эта машина хранит в собственных дельта-дисках.
Instant Clone - это независимая копия виртуальной машины, которая начинает исполняться с какого-то момента и отделяется от основной машины. Для этого используются техники in-memory cloning и copy-on-write, которые используются также и для связанных клонов.
Чтобы найти источник клонированной машины, нужно проанализировать события vCenter Server Events. Вот какие они бывают касательно клонов:
VmClonedEvent - появляется, когда происходит создание Full Clone или Linked Clone.
com.vmware.vc.VmInstantClonedEvent - происходит при созданиии Instant Clone.
VmDeployedEvent - вызывается, когда виртуальная машина развертывается из шаблона (vSphere Template или Content Library Template).
На базе анализа этих трех событий в истории vCenter Вильям Лам создал PowerCLI-функцию Get-VMCloneInfo, с помощью которой можно узнать родителя для виртуальной машины, если она была клонирована.
Устанавливаем ее простой командой:
Install-Script VMCloneInfo
На входе эта функция принимает имя ВМ, которую мы хотим проанализировать. Такой вывод мы получим, если машина не была клонирована:
> Get-VMCloneInfo -VMName "SourceVM"
Unable to find any cloning information for SourceVM, VM may not have been cloned or vCenter Events have rolled over
Так будет выглядеть вывод по полному клону:
> Get-VMCloneInfo -VMName "Full-Clone-VM"
Type Source Date User
---- ------ ---- ----
Full SourceVM 1/3/2021 1:13:00 PM VSPHERE.LOCAL\Administrator
Так мы узнаем, что машина является связанным клоном:
> Get-VMCloneInfo -VMName "Linked-Clone-VM"
Type Source Date User
---- ------ ---- ----
Linked SourceVM 1/3/2021 1:13:14 PM VSPHERE.LOCAL\Administrator
Так - что Instant-клоном:
> Get-VMCloneInfo -VMName "Instant-Clone-VM"
Type Source Date User
---- ------ ---- ----
Instant SourceVM2 1/3/2021 1:12:44 PM VSPHERE.LOCAL\Administrator
Вот пример того, что машина была клонирована из шаблона vSphere Template:
> Get-VMCloneInfo -VMName "VMTX-VM"
Type Source Date User
---- ------ ---- ----
Full SourceVMTXTemplate 1/3/2021 2:20:31 PM VSPHERE.LOCAL\Administrator
А вот - что из шаблона Content Library VM Template:
> Get-VMCloneInfo -VMName "VMTemplate-VM"
Type Source Date User
---- ------ ---- ----
Full SourceVMTemplate 1/3/2021 2:23:41 PM VSPHERE.LOCAL\Administrator
Увеличена производительность при создании тэгов и категорий по сравнению с vSphere 6.7 U3.
Производительность вывода тэгов через API улучшилась по сравнению с vSphere 6.7 U3.
Теперь доступна паджинация вывода API, что позволяет упростить и ускорить получение данных.
Для иллюстрации улучшений на рисунке ниже приведена картина задержек (latency) при привязывании 15 тэгов к 5 000 виртуальным машинам в vSphere 6.7 U3 (где время линейно увеличивалось с ростом числа тэгов) и vSphere 7.0 Update 1, где время оставалось практически неизменным.
Скачать отчет VMware vSphere 7.0 U1 Tagging Best Practices можно по этой ссылке.
На сайте проекта VMware Labs обновилась еще одна интересная штука - средство Python Client for VMware Cloud on AWS 1.2, с помощью которого пользователям публичного облака VMware Cloud on AWS можно автоматизировать операции с инфраструктурой виртуального датацентра VMConAWS SDDC.
Это средство представляет собой не клиент для работы с сервером vCenter, а средство удаленного исполнения задач в облаке, таких как создание сетей или настройка групп и правил безопасности на шлюзах Management и Compute Gateways.
Вот небольшой обзор работы утилиты от ее автора Nico Vibert:
Также у него есть подробная статья об использовании этого средства для запуска задач в облачной среде. Список доступных команд Python Client for VMware Cloud on AWS доступен в инструкции.
Вот что нового появилось в версиях 1.2 и 1.1:
Добавлен Dockerfile для построения Docker-образа, в котором будет запускаться PyVMC
На сайте virten.net, как обычно, вышла замечательная статья о реальной боли некоторых администраторов VMware vSphere - уменьшении дисков vCenter Server Appliance (vCSA). Так как vCSA работает в виртуальной машине, то иногда возникает необходимость в уменьшении ее дисков в целях простоты перемещения и компактности хранения. Но основная ситуация, когда диски vCSA чрезмерно разрастаются - это апгрейд сервера vCenter - в этом случае его хранилище может увеличиться до 1 ТБ при реально занятом пространстве в 100 ГБ. Тут уже без шринка (shrink) не обойтись.
При апгрейде vCSA установщик смотрит на аллоцированное пространство, а не на занятое, поэтому исходная машина в 416 ГБ может быть преобразована только в целевую ВМ типа Small с 480 ГБ диска:
Метод, описанный ниже, стоит применять только для виртуального модуля vCSA, который вы планируете апгрейдить, поскольку меняется порядок его дисков. Это, в целом, не проблема, но могут возникнуть сложности при взаимодействии с поддержкой VMware, которая может посчитать эту конфигурацию неприемлемой.
Перво-наперво нужно сделать бэкап вашего vCSA или его клон, с которым вы и будете работать. Если что-то не получится, вы просто сможете удалить клон.
Итак, заходим на vCSA по SSH и останавливаем все службы:
# service-control --stop --all
Выбираем файловую систему, для которой будем делать shrink. Например, /storage/seat имеет размер 296 ГБ, но реально используется 67 МБ! Запоминаем файловую систему (/dev/mapper/seat_vg-seat) и точку монтирования хранилища (/storage/seat), которое будем уменьшать.
Также из файловой системы вы можете получить Volume Group (seat_vg) и Logical Volume (seat):
Когда миграция будет закончена, sdh должен остаться пустым (Allocated PE = 0 и нет физических сегментов, только FREE):
# pvdisplay -m /dev/sdh
--- Physical volume ---
PV Name /dev/sdh
VG Name seat_vg
PV Size 300.00 GiB / not usable 7.00 MiB
Allocatable yes
PE Size 8.00 MiB
Total PE 38399
Free PE 38399
Allocated PE 0
PV UUID V7lkDg-Fxyr-qX4x-d3oi-KhNO-XZyT-EHgibI
--- Physical Segments ---
Physical extent 0 to 38398:
FREE
Удаляем sdh из Volume Group:
# vgreduce seat_vg /dev/sdh
Удаляем LVM-метки из sdh:
# pvremove /dev/sdh
Запускаем скрипт autogrow.sh для расширения файловой системы к размеру виртуального диска:
/usr/lib/applmgmt/support/scripts/autogrow.sh
Последний шаг очень важен - удаляем старый диск. Не удалите не тот! Для этого проверяем SCSI ID с помощью lsscsi:
# lsscsi |grep sdh
[2:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh
Мы видим, что SCSI ID [2:0:8:0] нам нужно удалить. Помните, что номер диска не всегда совпадает с SCSI ID. Удалите правильный диск (в данном случае 8), не ошибитесь!
Это все, теперь можно перезагрузить виртуальную машину, после чего в качестве опции апгрейда будет доступен вариант апгрейда на Tiny:
Если вы хотите уменьшить другие разделы, то идентифицируйте соответствующие параметры Logical Volume, Volume Group и Virtual Disk, после чего повторите процедуру.
# lsscsi
[0:0:0:0] cd/dvd NECVMWar VMware IDE CDR00 1.00 /dev/sr0
[2:0:0:0] disk VMware Virtual disk 1.0 /dev/sda
[2:0:1:0] disk VMware Virtual disk 1.0 /dev/sdb
[2:0:2:0] disk VMware Virtual disk 1.0 /dev/sdc
[2:0:3:0] disk VMware Virtual disk 1.0 /dev/sdd
[2:0:4:0] disk VMware Virtual disk 1.0 /dev/sde
[2:0:5:0] disk VMware Virtual disk 1.0 /dev/sdf
[2:0:6:0] disk VMware Virtual disk 1.0 /dev/sdg
[2:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh
[2:0:9:0] disk VMware Virtual disk 1.0 /dev/sdi
[2:0:10:0] disk VMware Virtual disk 1.0 /dev/sdj
[2:0:11:0] disk VMware Virtual disk 1.0 /dev/sdk
[2:0:12:0] disk VMware Virtual disk 1.0 /dev/sdl
[2:0:13:0] disk VMware Virtual disk 1.0 /dev/sdm
На сайте проекта VMware Labs появилась новая штука - утилита Desktop Container Tools. Она позволяет использовать графический интерфейс управления для vctl (работает как сниппет для VMware Fusion) для контейнерного движка на macOS, где работают кластеры Kubernetes.
Возможности Desktop Container Tools:
Простое управление движком контейнеров vctl через графический интерфейс и тач-бар. Можно настроить виртуальные машины для использования контейнеров без интерфейса командной строки.
Поддержка нескольких языков (пока только английский и китайский).
Полностью бесплатная утилита и, к тому же, легковесная (36 килобайт).
Скачать Desktop Container Tools можно по этой ссылке. Работает на Intel-маках с macOS Catalina или Big Sur. Рекомендуется использовать VMware Fusion 12.1.0 с поддержкой Kubernetes.
Компания VMware опубликовала полезный FAQ, ссылка на который может в любой момент понадобиться администратору VMware vSphere для понимания различных аспектов системного хранилища серверов VMware ESXi.
Давайте посмотрим, на какие вопросы там можно найти ответы:
Что изменилось в системном хранилище ESXi 7 по сравнению с прошлыми версиями? Мы об этом подробно писали тут.
Что случится с разметкой системного хранилища при апгрейде на vSphere 7? Ответ тут и на этой картинке:
Какое хранилище рекомендуется в качестве системного для ESXi?
Что насчет устройств USB/SD? Можно ли использовать SD-карту для системного хранилища? (Спойлер: лучше не надо).
Почему вы можете увидеть ситуацию, что хосты ESXi в "Degraded Mode"?
Что вообще означает Degraded Mode?
Можно ли добавлять локальное хранилище после апгрейда на ESXi 7? (Спойлер: да)
Что делать, если хост в Degraded Mode, а хранилища вообще не видно? (Спойлер: смотреть External Syslog, NetDump Collector или Core Dump Partition)
Если вы используете vSphere AutoDeploy, то как работает развертывание системного хранилища? Подробнее об этом вот тут
На днях компания VMware выпустила обновление виртуального модуля Horizon Cloud Connector 1.9, который позволяет соединить ваш Horizon Connection Server с облачным средством управления VMware Horizon Control Plane для создания гибридной среды виртуализации и доставки настольных ПК и приложений. О том, что нового было в прошлом релизе, можно почитать вот тут.
1. Улучшения интерфейса конфигурации сети
Раньше для настройки возможности автоматического обновления администраторам приходилось указывать все параметры сети (DNS, gateway, маску и IP). Теперь же нужно указать статический IP, который будет временно использован для обновления виртуального модуля. Все остальные параметры подтянутся автоматически из конфигурации Virtual Appliance.
2. Улучшения SSH
Доступ по SSH теперь отключен для пользователей root. Теперь для доступа по SSH есть специальный пользователь "ccadmin". Ему уже можно дать возможность повышения привилегий после логина. Поддерживается аутентификация как по ключу, так и по паре логин-пароль, но лучше использовать первый способ.
Ну и, пользуясь случаем, приведем ссылки на полезные статьи серии "Horizon Cloud Connector Know-How Series":
Компания VMware выпустила обновление средства vRealize Network Insight 6.1. Напомним, что оно предназначено для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений. О прошлой версии vRNI 6.0 мы писали вот тут.
Давайте посмотрим, что нового в vRNI 6.1:
Функции Network Assurance and Verification
Для определения несоответствия native VLAN и native VLAN tagging были добавлены цели (Intents)
Поддержка сетевого экрана Supports Palo Alto Networks (PAN) Firewall в представлении Network Map
Поддержка устройств Juniper в Network Map через утилиту Netconf (SSH не требуется)
Улучшения юзабилити (поиск путей, включая данные о конфигурации)
Аналитика на базе целей (Intent based analytics) - поддержка Link Metering для VMware SD-WAN
Создание цели для отслеживания использования канала (bandwidth) на соединениях (LTE/MPLS), которые находятся на обслуживании у сервис-провайдеров
Проактивные алерты помогают избежать дополнительных затрат за использование канала при превышении лимита провайдера
Поддержка возможности оптимизации или экономии полосы канала по этим соединениям
Intent based analytics для мониторинга использования Edge Uplink
Возможность создания целей для мониторинга использования аплинков на VMware SD-WAN Edges, для того чтобы оптимизировать использования канала, отслеживать проблемы и планировать увеличение емкостей каналов
Поддержка возможности выбора типа аплинка для генерации алертов и нотификаций
Сервисная информация Layer 7 от движка NSX Intelligence
Возможность получить видимость на уровне 7, когда включен движок NSX Intelligence через NSX-T Manager
Улучшенные дэшборды, включая VM, Hosts и Application - там теперь есть информация на уровне 7 OSI
Мониторинг и траблшутинг NSX-T
Алерты можно фильтровать на базе сущностей и конфигураций
Графики метрик для визуализации взаимодействия
Метрики для объектов NSX-T теперь показываются на странице NSX-T Manager Topology
Для маскирования правил сетевого экрана были добавлены события
Метрика Flow retransmit count поменялась на flow retransmit percentage
Функции VMware Cloud on AWS (VMC on AWS)
Поддержка статистик VMC T0 Router Interface, включая Rx Total Bytes, Rx Total Packets, Rx Dropped Packets, Tx Total Bytes, Tx Total Packets и Tx Dropped Packets для соединений Public, Cross-VPC и Direct Connect
Мониторинг и траблшутинг физических устройств
Графики метрик для визуализации взаимодействия
Функции поиска
Альтернативные предложения запросов, когда ничего не найдено
Pinboard
При прикреплении нового фильтра состояние фильтра сохраняется
Возможность прикреплять пустые результаты поиска (могут стать непустыми потом)
Возможность видеть другие пинборды под пользователем с ролью Auditor
Алерты
Определения алертов (раньше это были события) теперь классифицированы по категориям и по-разному организованы в интерфейсе для упрощения управления ими
Определение алерта используется для отсылки к проблеме или изменения условия срабатывания
Улучшения платформы
Поддержка веб-прокси для data sources (SD-WAN, AWS, Azure, ServiceNow, VMC NSX Manager)
Показ информации о машинах Platform и Collector на одной странице (IP, активность, статус и т.п.)
Возможность добавления и обновления data sources
Страница информации обо всех Web Proxies, а также использования ими ресурсов
Страница Infrastructure and Support
Прочие улучшения
VMware vRealize Network Insight Cloud доступен в Австралии
vRealize Suite Lifecycle Manager 8.2 Product Support Pack 1 поддерживает установку vRealize Network Insight 6.1
Скачать VMware vRealize Network Insight 6.1 можно по этой ссылке. Release Notes доступны тут.
Многие администраторы VMware vSAN задаются вопросом - а сколько прослужат диски в кластере хранилищ? Сегодня для vSAN уже имеет смысл использовать только SSD-диски, так как их стоимость уже вполне стала приемлемой для построения All-Flash хранилищ.
Как известно, в кластере vSAN есть 2 типа дисков - Cache (кэширование данных перед записью на постоянное хранение) и Capacity (постоянное хранилище). В первом случае, конечно же, использование ресурса диска идет в разы быстрее, чем для Capacity Tier.
Florian Grehl в своем блоге провел замер использования дисков обоих ярусов в плане записанных гигабайт в сутки в тестовой лаборатории. Вы сами сможете сделать это с помощью его PowerCLI-сценария, а также визуализовав данные в Graphite.
У него получилась вот такая картина:
В день у него получилось:
300 ГБ на диски Caching tier
20 ГБ на диски Capacity tier
Надо понимать, что объем записанных данных на каждый диск зависит от числа дисков в группе, а также развернутого типа RAID и политики FTT.
Когда вы покупаете SSD-диск, гарантия на него идет как на машину: время (обычно 5 лет), либо пробег (а в случае с диском это "TBW" = Terabytes Written, то есть записанный объем в ТБ) - в зависимости от того, что наступит раньше.
Как правило, для Capacity tier ресурс TBW за 5 лет на практике выработать не получится, а вот для Caching tier неплохо бы этот параметр замерить и сопоставить с характеристиками дисков. Например, 300 ГБ в день дает 535 ТБ за 5 лет.
Ну а вот параметры TBW, например, для устройств Samsung:
Вендор
Диск
Емкость
TBW
Гарантия
Samsung
980 PRO NVMe M.2 SSD
250
150
5 лет
Samsung
980 PRO NVMe M.2 SSD
500
300
5 лет
Samsung
980 PRO NVMe M.2 SSD
1000
600
5 лет
Samsung
950 PRO NVMe M.2 SSD
256
200
5 лет
Samsung
950 PRO NVMe M.2 SSD
512
400
5 лет
Samsung
SSD 870 QVO SATA III 2.5 Inch
1000
360
3 года
Samsung
SSD 870 QVO SATA III 2.5 Inch
2000
720
3 года
Samsung
SSD 870 QVO SATA III 2.5 Inch
4000
1440
3 года
Samsung
SSD 870 QVO SATA III 2.5 Inch
8000
2880
3 года
Samsung
970 EVO Plus NVMe M.2 SSD
250
150
5 лет
Samsung
970 EVO Plus NVMe M.2 SSD
500
300
5 лет
Samsung
970 EVO Plus NVMe M.2 SSD
1000
600
5 лет
Samsung
970 EVO Plus NVMe M.2 SSD
2000
1200
5 лет
Samsung
860 QVO SATA III 2.5 Inch SSD
1000
360
3 года
Samsung
860 QVO SATA III 2.5 Inch SSD
2000
720
3 года
Samsung
860 QVO SATA III 2.5 Inch SSD
4000
1440
3 года
Samsung
970 EVO NVMe M.2 SSD
250
150
5 лет
Samsung
970 EVO NVMe M.2 SSD
500
300
5 лет
Samsung
970 EVO NVMe M.2 SSD
1000
600
5 лет
Samsung
970 EVO NVMe M.2 SSD
2000
1200
5 лет
Samsung
970 PRO NVMe M.2 SSD
512
600
5 лет
Samsung
970 PRO NVMe M.2 SSD
1000
1200
5 лет
Samsung
860 EVO SATA III 2.5 Inch SSD
250
150
5 лет
Samsung
860 EVO SATA III 2.5 Inch SSD
500
300
5 лет
Samsung
860 EVO SATA III 2.5 Inch SSD
1000
600
5 лет
Samsung
860 EVO SATA III 2.5 Inch SSD
2000
1200
5 лет
Samsung
860 EVO SATA III 2.5 Inch SSD
4000
2400
5 лет
Samsung
SSD 860 PRO SATA III 2.5 Inch
256
300
5 лет
Samsung
SSD 860 PRO SATA III 2.5 Inch
512
600
5 лет
Samsung
SSD 860 PRO SATA III 2.5 Inch
1000
1200
5 лет
Samsung
SSD 860 PRO SATA III 2.5 Inch
2000
2400
5 лет
Samsung
SSD 860 PRO SATA III 2.5 Inch
4000
4800
5 лет
Samsung
860 EVO SATA III M.2 SSD
250
150
5 лет
Samsung
860 EVO SATA III M.2 SSD
500
300
5 лет
Samsung
860 EVO SATA III M.2 SSD
1000
600
5 лет
Samsung
860 EVO SATA III M.2 SSD
2000
1200
5 лет
Intel
Intel Optane Memory 16GB
16
182.5
5 лет
Intel
Intel Optane Memory M10 16GB
16
365
5 лет
Intel
Intel Optane Memory 32GB
32
182.5
5 лет
Intel
Intel Optane Memory M10 32GB
32
365
5 лет
Intel
Intel Optane SSD 800P 58GB
58
365
5 лет
Intel
Intel Optane SSD 800P 58GB
118
365
5 лет
Intel
Intel® 545s-SSDs
256
144
5 лет
Intel
Intel® 545s-SSDs
512
288
5 лет
Intel
Intel® 545s-SSDs
256
144
5 лет
Intel
Intel® 660p-SSDs
512
100
5 лет
Intel
Intel® 660p-SSDs
1024
200
5 лет
Intel
Intel® 660p-SSDs
2048
400
5 лет
Intel
Intel® 760p-SSDs
128
72
5 лет
Intel
Intel® 760p-SSDs
256
144
5 лет
Intel
Intel® 760p-SSDs
512
288
5 лет
Intel
Intel® 760p-SSDs
1024
576
5 лет
Intel
Intel® 760p-SSDs
2048
576
5 лет
Transcend
PCIe SSD 220S
256
550
5 лет
Transcend
PCIe SSD 220S
512
1100
5 лет
Transcend
PCIe SSD 220S
1000
2200
5 лет
Transcend
PCIe SSD 220S
2000
4400
5 лет
Seagate
IronWolf 510
240
435
5 лет
Seagate
IronWolf 510
480
875
5 лет
Seagate
IronWolf 510
960
1750
5 лет
Seagate
IronWolf 510
1920
3500
5 лет
Как видно из таблицы, некоторые устройства могут прослужить вам значительно меньше 5 лет, в зависимости от интенсивности использования в вашей инфраструктуре и модели устройства.
Интересно, что продукты VMware vSphere и VMware vSAN имеют разные списки совместимости оборудования (HCL - Hardware Compatibility Lists). Ronald de Jong в своем блоге описал ситуацию, когда у него драйвер SCSI-контроллера подошел для vSphere, но не подошел для vSAN.
После установки обновления драйвера для VMware vSphere через VMware Lifecycle Manager он получил вот такие ворнинги для vSAN в vSphere Client:
Драйвер smartpqi (70.4000.0.100-4vmw.701.0.0.17325551) уже подходит для vSphere, но еще не провалидирован для решения vSAN. В этом можно убедиться в списке совместимости для vSAN по этой ссылке, где есть только старый драйвер (3vmw):
Таким образом, нужно провести даунгрейд драйвера, чтобы он подходил и для vSphere, и для vSAN. Сначала идем на Patch Portal и находим там нужное обновление в виде VIB-пакета:
Вот этот драйвер:
После загрузки в консоли ESXi запускаем установщик VIB-пакета командой:
Некоторое время назад мы писали об улучшении технологии горячей миграции vMotion (тут и тут) в последней версии VMware vSphere 7 Update 1. Сегодня мы вкратце расскажем о вариантах переноса рабочих нагрузок в кластер хранилищ VMware vSAN на базе вот этой заметки.
Первое, что вы должны решить - это в каком рабочем процессе вы будете мигрировать виртуальные машины с помощью vMotion: за один шаг (хранилище+сервер) или за два (сначала сервер, потом хранилище).
1. Миграция в два шага (Two-Step Migrations)
При выборе миграции виртуальной машины у нас есть опция изменения либо сервера ESXi машины, либо ее хранилища, либо и того, и другого:
Change compute resource only - это первый шаг миграции для случая, когда не-vSAN хранилище может быть презентовано существующему кластеру vSAN. Также это может быть востребовано в рамках топологии VMware vSAN HCI Mesh, где хранилище монтируется удаленному кластеру vSAN.
Change storage only - это второй шаг миграции, когда машина на хосте ESXi уже находится в кластере vSAN, и мы выполняем перенос ее VMDK уже на собственные хранилища кластера.
Надо сказать, что миграция машин в два шага имеет бОльшую гранулярность, что позволит вам получить промежуточный результат и зафиксировать результат в середине (например, смигрированная на другой хост, но не хранилище машина), что может сэкономить время при повторной попытке миграции в случае каких-то проблем.
2. Миграция в один шаг
Этот способ миграции реализуется, когда вы выбираете опцию Change both compute resource and storage или Cross vCenter Server export. Надо понимать, что процесс этот весьма затратный, и выбирать этот вариант можно, когда у вас есть большой запас по ресурсам и времени для вычислительных ресурсов и ресурсов хранилищ. Ну или когда вы не можете расшарить хранилище между двумя разными кластерами vSphere / vSAN.
Удобство это способа еще и в том, что если у вас есть много времени на миграцию, то можно просто поставить vMotion для нужных нагрузок, и все будет постепенно переезжать без участия администратора.
Также для переноса нагрузок между разными инфраструктурами есть опция Cross vCenter Server export. В обновлении VMware vSphere 7 Update 1c главным нововведением стала интеграция функций миграции Advanced Cross vCenter Server vMotion Capability (ранее это был виртуальный модуль Cross vCenter Workload Migration Utility) в интерфейс vSphere Client. Оно же называется XVM.
Эта функциональность используется для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). При этом не требуется настроенного механизма Enhanced Linked Mode (ELM) или Hybrid Linked Mode (HLM) для серверов vCenter в разных датацентрах.
Если вы решили сделать пакетную миграцию виртуальных машин в vSphere Client, то нужно для кластера или пула ресурсов перейти на вкладку VMs и с шифтом выбрать группу ВМ для миграции, после чего из контекстного меню выбрать Migrate...:
Надо сказать, что машины одной группы можно мигрировать только в одинаковом состоянии (Powered on или Powered off), поэтому удобно отсортировать их по колонке State.
Ну и в заключение - картинка об улучшении технологии vMotion с момента ее появления в 2003 году:
RSS
