Недавно мы писали об анонсе Project Monterey на прошедшей конференции VMworld Online 2020. Это переработка архитектуры VCF таким образом, чтобы появилась родная интеграция новых аппаратных возможностей и программных компонентов. Например, новая аппаратная технология SmartNIC позволяет обеспечить высокую производительность, безопасность по модели zero-trust и простую эксплуатацию в среде VCF. Но на этом новости не закончились.
На днях VMware выпустила еще одно важное средство на сайте проекта VMware Labs - модуль ESXi-Arm. Это, по-сути, издание VMware ESXi для компьютеров с 64-битными процессорами архитектуры ARM. Пока, конечно же, в режиме технологического превью, созданного в целях сбора обратной связи от пользователей.
История проекта такова - группа инженеров внутри VMware решила портировать ESXi с архитектуры x86 на ARM, после чего энтузиасты внутри компании поддерживали согласование нововведений в гипервизоре в рамках платформы x86 с версией для ARM. Теперь эта версия ESXi считается доведенной до ума, и она была выпущена публично:
На данный момент в экспериментальном режиме было протестировано следующее оборудование:
Вы также можете управлять таким ESXi на архитектуре ARM с помощью обычного VMware vCenter 7.0 или более поздней версии.
Скачать VMware ESXi для ARM в виде загрузочного ISO-образа можно по этой ссылке. Документация доступна там же, правильный документ надо выбрать из комбобокса:
Также вот небольшое обзорное видео об установке ESXi на компьютер Raspberry Pi от Вильяма Лама:
Как вы все знаете, на прошлой неделе прошла главная конференция по виртуализации этого странного года - VMworld 2020 Online. Несмотря на то, что она прошла онлайн, было сделано немало интересных объявлений, а перед самой конференцией были анонсированы главные обновления продуктовой линейки. Одним из них был скорый выпуск новой версии платформы VMware vSphere 7 Update 1, который и состоялся:
На днях также появилась возможность скачать новые версии нескольких продуктов, помимо vSphere 7 U1. Давайте посмотрим, какие именно решения были выпущены:
Как вы знаете, на прошлой неделе компания VMware провела первую в истории онлайн-конференцию VMworld 2020 Online. Основные анонсы новых версий продуктов былисделаны еще до конференции, а VMware рассказывала, в основном, о новых технологиях и будущих продуктах для виртуального датацентра.
Одним из таких анонсов стала новость о разработке решения Project Monterey.
По заявлению VMware, Monterey - это продолжение развития технологии Project Pacific для контейнеров на базе виртуальной инфраструктуры, только с аппаратной точки зрения для инфраструктуры VMware Cloud Foundaton (VCF).
Потребности современных приложений, многие из которых работают в контейнерах, рождают повышенные требования к оборудованию, а особенно к ресурсам процессора. Также с каждым годом все больше ужесточаются требования к безопасности и изоляции систем.
Поэтому вендоры аппаратного обеспечения пытаются сделать высвобождение некоторых функций CPU, передав их соответствующим компонентам сервера (модуль vGPU, сетевая карта с поддержкой offload-функций и т.п.), максимально изолировав их в рамках необходимостей. Но вся эта новая аппаратная архитектура не будет хорошо работать без изменений в программной платформе.
Project Monterey - это и есть переработка архитектуры VCF таким образом, чтобы появилась родная интеграция новых аппаратных возможностей и программных компонентов. Например, новая аппаратная технология SmartNIC позволяет обеспечить высокую производительность, безопасность по модели zero-trust и простую эксплуатацию в среде VCF.
Также за счет технологии SmartNIC инфраструктура VCF будет поддерживать операционные системы и приложения, исполняемые на "голом железе" (то есть без гипервизора). В данном решении будет три основных момента:
Поддержка перенесения сложных сетевых функций на аппаратный уровень, что увеличит пропускную способность и уменьшит задержки (latency).
Унифицированные операции для всех приложений, включая bare-metal операционные системы.
Модель безопасности Zero-trust security - обеспечение изоляции приложений без падения производительности.
Вот так будет выглядеть сетевой адаптер сервера, поставляемый в партнерстве с вендорами оборудования:
Таким образом, это сетевая карта с обычным CPU, который занимается решением задач производительности и безопасности. Она будет состоять из следующих компонентов:
Стандартный процессор общего назначения (general-purpose CPU) - позволяет исполнять часть кода прямо на сетевом адаптере (сервисы сети и хранилищ), что существенно увеличивает производительность (за счет уменьшения пути для операций ввода-вывода) и экономии циклов CPU сервера.
Унифицированный процесс управления CPU сетевой карты, который предоставляет отдельный рабочий процесс, доступный из Lifecycle Manager.
Возможность предоставления виртуальных устройств - SmartNIC может шарить на PCI-шине несколько виртуальных устройств, которые будут показываться гостевым ОС отдельными карточками.
Часть стандартной функциональности сервера и его CPU теперь переезжает на сетевую карту SmartNIC в рамках инфраструктуры VCF:
Тут есть следующие интересные моменты:
ESXi on SmartNIC - да, теперь гипервизор будет работать на сетевой карте! Для этого VMware и делала порт ESXi для ARM-процессоров (помните анонсы 2018 года?), которые в основном и будут использоваться для устройств SmartNIC.
2 экземпляра ESXi на одном сервере - один на обычном CPU, а второй - на SmartNIC. Управлять ими можно как единым функциональным блоком, так и каждым гипервизором по отдельности.
Сервисы сети и доступа к хранилищам - за счет этих сервисов повышается быстродействие и разгружается основной процессор сервера.
SmartNIC ESXi теперь будет уметь управлять хостом ESXi, что упростит процедуры обслуживания жизненного цикла с помощью LCM.
Двойной контроль - если основной гипервизор скомпрометирован, то отдельный SmartNIC ESXi будет продолжать предоставлять сервисы защиты, что улучшает защищенность инфраструктуры.
Управление bare-metal операционными системами теперь будет происходить со стороны карточек SmartNIC, которые существенно упростят управление единой инфраструктурой датацентра.
Теперь архитектура VCF будет позволять шарить ресурсы SmartNIC и для сервисов на других серверах. Это открывает очень широкие возможности по построению кластеров, где ресурсы приложениям доступны из общего пула:
Все это будет поддерживать кластеры Kubernetes и решение VCF with Tanzu, что расширит сферу применения SmartNIC для крупных инфраструктур, где ресурсы и сервисы необходимо выделять по требованию, а не планировать конфигурации серверов под конкретные приложения. Конечно же, все будет управляться не только через консоли, но и через API.
В итоге, вариантами использования SmartNIC станут:
Сетевая производительность (передача сетевых функций на уровень адаптера) и безопасность (например, отдельный L4-7 фаервол на уровне сетевой карты).
Улучшение сервисов датацентра - например, с помощью Project Monterey можно будет использовать offloaded-сервисы доступа к хранилищам, сжатие и т.п., что повысит производительность без создания единого домена отказа и падения производительности. Это повысит гибкость использования решения и даст возможность применения таких сервисов, как dynamic storage profiles (для управления емкостями и операциями ввода-вывода, IOPS) и удаленный доступ к хранилищам по требованию.
Управление системами bare-metal - для тех, кто мечтал о единой консоли vSphere для физических и виртуальных систем.
Также все это сможет работать в гибридных облаках, как работают сейчас инфраструктуры VCF.
На данный момент главными аппаратными партнерами VMware в части технологии SmartNIC являются компании NVIDIA, Pensando и Intel. С точки зрения производителей серверов, первыми партнерами станут Dell Technologies, HPE и Lenovo. Этот список будет со временем расширен.
На прошедшем VMworld 2020 Online проекту Monterey были посвящены следующие сессии, которые вы можете найти тут:
Как многие из вас знают, в последние пару лет очень сильно увеличилось число и масштаб атак, связанных с уязвимостями в аппаратном обеспечении. Наибольшую известность получили уязвимости Meltdown и Spectre, которые были обнаружены в процессорах Intel.
Самый неприятный момент, связанный с подобного рода уязвимостями - это то, что поскольку они связаны с аппаратной частью процессоров на самом низком уровне, то, во-первых, ее сложнее исправить и доставить конечным пользователям, а, во-вторых, неправильное обновление, закрывающее эти дырки, может вызвать различные побочные эффекты.
Так, например, было с производительностью серверов VMware ESXi, когда производители ОС совместно с Intel выпустили соответствующие обновления, а VMware выпустила закрывающий уязвимость патч. Сам патч тогда пришлось отозвать и ждать нового, а ведь это потраченного время администраторов, время пользователей и время, в течение которого существует угроза безопасности инфраструктуры предприятия.
Поэтому производители процессоров, совместно с вендорами платформ виртуализации, сейчас уделяют этому моменту особое внимание. Конечно же, в этом направлении работает и AMD, которая активно внедряет следующие технологии:
Secure Encrypted Virtualization (SEV) - первая версия технологии, анонсированная в 2016 году. Она позволяет изолировать виртуальные машины от гипервизора, со стороны которого может быть угроза безопасности при его компрометации. Если гипервизор попытается считать память гостевой ОС, он увидит только зашифрованные данные.
SEV-ES (Encrypted State) - вторая версия технологии, представленная в 2017 году. Она дополняет защиту памяти гостевой ОС шифрованием регистров CPU гостевой ОС. Таким образом, гипервизор не может видеть регистры процессора, активно используемые виртуальной машиной.
SEV-SNP (Secure Nested Paging) - следующее поколение технологии, которое было анонсировано в этом году. Оно добавляет функции аппаратной безопасности для контроля над интеграцией памяти гостевых ОС, что защищает от таких атак, как data replay, memory re-mapping и других (подробнее тут и на картинке ниже).
В недавнем обновлении платформы виртуализации VMware vSphere 7 Update 1 появилась поддержка технологии SEV-ES (Encrypted State), которая должна еще больше защитить от потенциальных уязвимостей, связанных с доступом к данным в рамках процессора. Работает это на процессорах AMD EPYX 7xx2 CPU
или более поздних и требует VM Virtual Hardware версии 18, которое появилось в Update 1.
Надо начать с того, что у VMware уже есть защита памяти и данных гостевой ОС на уровне платформы (а в самих ОС тоже есть средства защиты памяти и процессора), но, само собой, эти механизмы на надежны на 100%, потому что ключевой компонент платформы - гипервизор, обладает очень широкими полномочиями (в виду необходимости), и при его компрометации ничего особо не поможет. Поэтому самое разумное - это поддержать подход изоляции ВМ от гипервизора на аппаратном уровне. Он, кстати, называется Trusted Execution Environment (TEE).
Подход AMD заключается в том, что они добавляют специальный Secure Processor, маленький сопроцессор, интегрированный в основной чип CPU, который является основой безопасности и поддерживает операции шифрования, в том числе и для SEV-ES.
Первое поколение EPYC CPU поддерживало хранение только 15 ключей шифрования, но следующее поколение уже поддерживает более 500. Один из таких ключей используется для гипервизора, а остальные - для гостевых систем.
Для чего вообще нужно защищать регистры процессора гостевых систем? Очень просто - когда виртуальная машина переключает контекст исполнения (меняет процессор), гипервизор получает ресурсы CPU обратно, вместе с содержимым регистров. А в них может храниться много "полезного" для злоумышленника - например, ключи для расшифровки дисков гостевой системы.
Работает механизм ключей так - гостевая ОС запрашивает у процессора с поддержкой SEV ключ шифрования для памяти, а SEV-ES расширяет его и на регистры процессора тоже, после чего гостевая ОС может безопасно использовать память и регистры, не беспокоясь что гипервизор или другие ВМ, изолированные в рамках процессов VMX, считают их содержимое. Очевидно, что гостевая ОС тоже должна поддерживать реализацию SEV-ES (поэтому надо читать соответствующую документацию к ним, чтобы узнать о поддержке).
Самым большим минусом использования технологии SEV-ES является невозможность поддержки таких техник, как vMotion, Memory Snapshots, Guest Integrity, Hot Add, Suspend & Resume, Fault Tolerance и горячих клонов - ведь для их реализации гипервизор должен иметь прямой доступ к памяти гостевых систем. В то же время надо отметить, что это не ограничение от AMD, которая заявляет, что SEV поддерживает live migration и прочее, а ограничение реализации от VMware.
В большинстве производственных окружений невозможность применения этих технологий будет ограничивать использование SEV-ES только системами, требующих наивысшего уровня защищенности.
С другой стороны, например, недавно вышедшее решение vSphere with Tanzu не использует vMotion для машин с контейнерами виртуализованных приложений - они просто выключаются на одном хосте и включаются на другом, то есть здесь есть перспективы применения SEV-ES.
Также использованием технологии SEV-ES можно управлять в пакетном режиме сразу для нескольких тысяч виртуальных машин через интерфейс PowerCLI, что особенно актуально для контейнеров Tanzu. На данный момент VMware еще не опубликовала официальный референс по командлетам для SEV-ES, ждем.
Ну и недавно VMware выпустила интересное видео, рассказывающее о первой имплементации технологии SEV-ES в платформе VMware vSphere 7 Update 1:
Как итог можно отметить, что пока такие технологии, как Secure Encrypted Virtualization имеют достаточно узкое применение ввиду их ограничений. Однако это лишь первые шаги, которые производители процессоров делают совместно с вендорами платформ виртуализации, чтобы защитить ИТ-среду предприятия он новой волны атак на программно-аппаратную инфраструктуру датацентра. Дальше все это будет развиваться, будет и поддержка AMD SEV-SNP, что уже будет существенно уменьшать поверхность возможных атак.
Как вы знаете, у компании VMware есть клиент для управления отдельными хостами VMware ESXi, который называется VMware ESXi Embedded Host Client. Последний раз обновлялся он в феврале прошлого года, и VMware не уделяет ему никакого внимания.
Между тем, VMware рассказала о том, что в ближайшем будущем эта недоработка будет исправлена. Дело в том, что интерфейс существующего хост-клиента построен на базе фреймворка Angular JS web framework, последний стабильный релиз которого 1.7 вошел в фазу long term support 30 июня 2018 года. Начиная с 1 января 2022 года, Angular JS больше не будет поддерживаться со стороны Google.
Последующие релизы фреймворка (Angular 4 и более поздние) не будут совместимы с Angular JS. Соответственно, VMware пора уходить с технологии, которая скоро устареет. Поэтому Host Client переедет с технологии Angular JS на последнюю версию Angular web framework (сейчас это Angular 9).
Вместе с этим произойдет и удаление компонентов, которые зависят от Angular JS, а также апдейт основного графического фреймворка Clarity на третью версию.
Собственно, это та причина, по которой VMware не обновляет текущий ESXi Host Client. Этот клиент больше не будет получать новых возможностей, но будет получать некоторые текущие обновления.
А вот новый клиент выйдет уже как Single host managing UI (он же ESXi UI) во второй половине 2021 года.
Для старого клиента будут предоставляться только следующие обновления:
Только доступность самых критичных блоков функциональности и обеспечение апдейтов безопасности
Поддержка текущих рабочих процессов, для которых нет альтернативы
Решение проблем с производительностью
Все прочие проблемы, которые могут привести к оттоку пользователей клиента
Новый ESXi UI будет являться частью ESXi Client и будет построен на базе Clarity 3 в его составе. Соответственно все процессы управления отдельным хостом ESXi будут аналогично таковым в рамках кластера под управлением vCenter.
VMware выпустит этот клиент как только сможет реализовать там все основные рабочие процессы и операции жизненного цикла текущего Host Client, включая развертывание ВМ, конфигурацию, мониторинг, решение проблем и обновление. Это займет время, поэтому нам и ждать полноценной версии где-то год.
Но первую версию нового клиента с базовой функциональностью нам обещают уже в первом квартале следующего года.
Основной фишкой первого пакета обновления седьмой версии vSphere стал, конечно же, финальный выпуск платформы VMware vSphere with VMware Tanzu, объединяющей миры виртуальных машин и контейнеризованных приложений в рамках инфраструктуры предприятия.
Вот небольшой обзор платформы VMware vSphere with Tanzu, о первых объявлениях компонентов которой мы уже писали тут и тут (а о текущей версии рассказано в блоге VMware):
Нововведения vSphere 7 U1 разбиты на 3 блока:
Инфраструктура для разработчиков (контейнеры)
Продолжение масштабирования возможностей платформы
Упрощение операций администраторов
Итак, давайте посмотрим, что нового в VMware vSphere 7 Update 1:
1. Инфраструктура для разработчиков
Здесь VMware добавила следующие важные возможности:
Служба Tanzu Kubernetes Grid (TKG) - о ней мы упоминали вот тут. Она позволяет администраторам развертывать Kubernetes-окружения и управлять их составляющими с помощью решения для кластеров Tanzu Kubernetes. Делается это теперь за минуты вместо часов. Также TKG идет в соответствии с политиками upstream Kubernetes, что позволяет сделать процесс миграции максимально бесшовным.
Bring Your Own Networking - пользователи могут выбирать, какой сетевой стек использовать для кластеров Tanzu Kubernetes. Можно использовать традиционную инфраструктуру на базе vSphere Distributed Switch (vDS) для конфигурации, мониторинга и администрирования виртуальных машин и кластеров Kubernetes. Новый Networking for Tanzu Kubernetes clusters позволяет использовать и решения VMware NSX. Также можно использовать Antrea для максимальной производительности внутренней сети для сервисов Tanzu Kubernetes Grid.
Bring Your Own Load Balancer - можно выбирать тип балансировки L4 для кластеров Tanzu Kubernetes. Первым партнером VMware стало решение HAProxy в формате виртуального модуля OVA.
Application-focused management - теперь пользователи могут применять vCenter не только для управления виртуальными машинами, но и для обслуживания, мониторинга и траблшутинга инфраструктуры контейнеров, включая приложения и неймспейсы (подход application focused management).
2. Продолжение масштабирования возможностей платформы
В этой категории нужно отметить следующие возможности:
Monster VMs - для пользователей решений SAP HANA, Epic Operational Databases, InterSystems Cache и IRIS компания VMware позволяет масштабировать виртуальные машин до 24 ТБ памяти и до 768 виртуальных процессоров (vCPU). То есть все ресурсы хоста могут быть предоставлены виртуальной машине, требующей их большое количество. Это было сделано за счет улучшения планировщика ESXi, а также логики ко-шедулинга для больших ВМ.
Cluster scale enhancements - теперь в vSphere 7 U1 кластер может содержать до 96 хостов! Это на 50% больше значения в релизе vSphere 7 (64 штуки):
3. Упрощение операций администраторов
vSphere Lifecycle Manager - теперь vLCM поддерживает и хосты vSAN, и конфигурацию сетевого стека NSX-T. В vSphere 7 Update 1 решение vLCM также мониторит соответствие образов непрерывно, что позволяет вовремя запустить процесс обновления (remediation).
vSphere Ideas - эта функциональность позволяет пользователям запросить возможности vSphere следующих версий прямо из интерфейса vSphere Client, отслеживать статус своих запросов, видеть запросы других пользователей и голосовать за них. Не факт, конечно, что к вам прислушаются, но общую обстановку по тому, что хотят администраторы, вы будете видеть.
vCenter Connect - теперь пользователи могут управлять своими виртуальными ресурсами VMware Cloud on AWS или в других облаках на базе vCenter из единого интерфейса.
Доступность для загрузки VMware vSphere 7 Update 1 ожидается в рамках или после конференции VMworld Online 2020. Следите за нашими обновлениями!
Коллега с virten.net написал замечательную статью об использовании сетевых адаптеров USB на хостах VMware ESXi, основные моменты которой мы приведем ниже.
Напомним, что подключить сетевые адаптеры USB на хостах ESXi можно с помощью драйвера USB Network Native Driver for ESXi, о котором мы не так давно писали вот тут. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.
Еще один вариант использования таких адаптеров - когда у вас (например, на тестовом сервере) есть всего один гигабитный порт, а вам нужно тестировать технологии и продукты, где нужно несколько высокоскоростных соединений.
Итак, после того, как вы скачаете драйвер, его установка делается одной командой:
С помощью PowerShell можно создать кастомизированный образ ESXi с уже вшитым драйвером сетевого USB-адаптера. Просто раскомментируйте строчку с нужной версией драйвера:
# ESXi 7.0 Image with USB NIC Fling 1.6:
$baseProfile = "ESXi-7.0.0-15843807-standard" # See https://www.virten.net/vmware/vmware-esxi-image-profiles/ for available Image Profiles
$usbFling = "ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip" # Uncomment for ESXi 7.0
#$usbFling = "ESXi670-VMKUSB-NIC-FLING-39203948-offline_bundle-16780994.zip" # Uncomment for ESXi 6.7
#$usbFling = "ESXi650-VMKUSB-NIC-FLING-39176435-offline_bundle-16775917.zip" # Uncomment for ESXi 6.5
При установке VMware ESXi на хост, где есть только USB сетевые адаптеры, процесс может зависнуть на 81%. В этом случае почитайте вот эту статью.
Кстати, ваши USB-адаптеры лучше всего пометить наклейками. Автор предлагает указать имя хоста ESXi, MAC-адрес адаптера и его номер vusbX:
Номер виртуального vusbX не сохраняется при перезагрузках. Начиная с версии драйвера 1.6 можно закрепить MAC-адрес за нужным vusbX. Сначала найдем наш адаптер:
# esxcli network nic list |grep vusb |awk '{print $1, $8}'
vusb0 00:23:54:8c:43:45
vusb1 a0:ce:c8:cd:3d:5d
Затем сделаем статический маппинг адаптеров с использованием модуля vmkusb_nic_fling:
# esxcli system module parameters set -p "vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d" -m vmkusb_nic_fling
В данной команде нужно перечислить все адаптеры через пробел (если вы вызываете ее второй раз, то нужно переуказать каждый из адаптеров, иначе маппинг сбросится).
Далее нужно проверить маппинги с помощью команды:
# esxcli system module parameters list -m vmkusb_nic_fling
Name Type Value Description
-------------------------- ------ ----------------- -----------
usbCdromPassthroughEnabled int Enable USB CDROM device for USB passtrough: 0 No, 1 Yes
vusb0_mac string 00:23:54:8c:43:45 persist vusb0 MAC Address: xx:xx:xx:xx:xx:xx
vusb1_mac string a0:ce:c8:cd:3d:5d persist vusb1 MAC Address: xx:xx:xx:xx:xx:xx
vusb2_mac string persist vusb2 MAC Address: xx:xx:xx:xx:xx:xx
vusb3_mac string persist vusb3 MAC Address: xx:xx:xx:xx:xx:xx
vusb4_mac string persist vusb4 MAC Address: xx:xx:xx:xx:xx:xx
vusb5_mac string persist vusb5 MAC Address: xx:xx:xx:xx:xx:xx
vusb6_mac string persist vusb6 MAC Address: xx:xx:xx:xx:xx:xx
vusb7_mac string persist vusb7 MAC Address: xx:xx:xx:xx:xx:xx
Если вы хотите сделать текущий маппинг постоянным, то используйте команду:
# esxcli system module parameters set -p "$(esxcli network nic list |grep vusb |awk '{print $1 "_mac=" $8}' | awk 1 ORS=' ')" -m vmkusb_nic_fling
Также статические маппинги можно сделать и через PowerCLI. Выводим адаптеры:
PS> Get-VMHostNetworkAdapter -VMHost esx2.virten.lab -Physical -Name vusb* |select Name,Mac
Name Mac
---- ---
vusb0 00:23:54:8c:43:45
vusb1 a0:ce:c8:cd:3d:5d
Далее проводим операцию vMotion виртуальной машины между хостами ESXi. Результат таков:
Очевидно, кросс-соединение на адаптерах 2.5G рулит.
Проверка совместимости
Не все сетевые адаптеры USB поддерживаются нативным драйвером. Их актуальный список всегда можно найти вот тут. Вот эти адаптеры точно работают:
Адаптеры доступны в форм-факторах USB-A и USB-C. Между ними есть переходники.
Если вам нужно высокоскоростное соединение (multi-gigabit) между несколькими хостами, можно посмотреть на следующие коммутаторы:
MikroTik CRS305-1G-4S+IN ($130 USD) - 4 порта
MikroTik CRS309-1G-8S+IN ($260 USD) - 8 портов
Netgear MS510TX ($260 USD) - 10 портов
TRENDnet TEG-30102WS ($450 USD) - 10 портов
Самое быстрое и дешевое соединение между двумя хостами ESXi - соединить адаптеры патч-кордом напрямую:
Проверяйте параметр MTU size, когда включаете Jumbo Frames
Если вы меняете размер MTU на виртуальном коммутаторе, он принудительно меняется на всех подключенных к нему физических сетевых адаптерах. Имейте в виду, что эти адаптеры должны поддерживать выставляемый MTU size.
Посмотреть размер MTU можно следующей командой:
[root@esx4:~] esxcfg-nics -l
Name PCI Driver Link Speed Duplex MAC Address MTU Description
vmnic0 0000:00:1f.6 ne1000 Up 1000Mbps Full 00:1f:c6:9c:47:13 1500 Intel Corporation Ethernet Connection (2) I219-LM
vusb0 Pseudo uether Up 1000Mbps Full 00:24:9b:1a:bd:18 1600 ASIX Elec. Corp. AX88179
vusb1 Pseudo uether Up 1000Mbps Full 00:24:9b:1a:bd:19 1500 ASIX Elec. Corp. AX88179
В данном примере MTU size настроен как 1600, что подходит для адаптеров (и работает для сети NSX-T). Если же вы поставите его в 9000, то увидите в vmkernel.log ошибки для dvSwitch о том, что такой размер не поддерживается устройством:
2020-07-19T16:10:42.344Z cpu6:524356)WARNING: vmkusb: Set MTU 9000 is not supported: Failure
2020-07-19T16:10:42.344Z cpu6:524356)WARNING: Uplink: 16632: Failed to set MTU to 9000 on vusb0
Если вы хотите проверить корректность вашего MTU size, то можно использовать команду ping с размером пакета MTU-28 байт (8 байт на заголовок ICMP и 20 байт на заголовок IP). Таким образом, для MTU size 1600 используйте число 1572:
[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1572 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1572 data bytes
1580 bytes from 192.168.225.10: icmp_seq=0 ttl=64 time=0.680 ms
[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1573 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1573 data bytes
sendto() failed (Message too long)
На сайте проекта VMware Labs на этой неделе появилось несколько обновлений полезных утилит, о новых возможностях которых мы рассказываем ниже:
1. Новая версия OS Optimization Tool b1171
Последний раз эту утилиту обновляли в начале августа этого года (b1170). Напомним, что она предназначена для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач.
Что интересного в этом обновлении:
Пункт Disable Passive Polling больше не выбран по умолчанию (некоторые приложения думали, что отсутствует интернет соединение).
Новая настройка - использовать графический драйвер WDDM для подключений через Remote Desktop.
Новая функция поиска по оптимизациям, чтобы найти отдельные объекты. Это доступно на вкладках Optimize и My Templates.
Добавлен сплиттер для расширения зоны дерева слева в разделе My Templates.
Новые контролы для управления поиском Cortana и поведением окошка поиска в таскбаре.
Новая опция для указания аккаунта администратора, чтобы выполнять операции после отработавшего SysPrep (по умолчанию это текущий пользователь, который добавляется в группу Администраторы).
Исправлено много ошибок.
Скачать VMware OS Optimization Tool b1171 можно по этой ссылке.
2. Обновление USB Network Native Driver for ESXi 1.6
В прошлый раз апдейт этого средства (версия 1.5) выходил в апреле этого года. Напомним, что это набор драйверов для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.
Что появилось нового:
Добавлена поддержка устройств Aquantia и Trendnet AQC111U (0xe05a:0x20f4).
Добавлена поддержка Realtek RTL8153 (0x045e:0x07c6).
Поддержка Realtek RTL8156 (0x0bda:0x8156).
Поддержка постоянных маппингов MAC-адресов VMkernel на USB NIC.
Упрощенное сохранения состояния USB NIC.
Решена проблема со скоростью соединения для чипсетов RTL8153.
Это последний релиз, поддерживающий ESXi 6.5.
Теперь таблица поддерживаемых чипсетов и адаптеров выглядит так:
3. Новая версия App Volumes Migration Utility 1.0.4
Эта штука позволяет смигрировать старые объекты AppStacks, в которых распространялись приложения в VMware App Volumes 2.18, на новый формат VMware App Volumes 4.0, который реализует концепцию приложений и пакетов. Подробно мы писали об этой утилите вот тут.
Обновление 1.0.4 небольшое - тут появилась только пара исправлений ошибок. Скачать апдейт можно по этой ссылке.
На днях компания VMware обновила пару продуктов линейки серверной платформы, выпустив обновления компонентов vSphere 6.7 Update 3:
Давайте посмотрим, что нового появилось в vCenter и ESXi:
vCenter 6.7 Update 3j
Поддержка SMTP-аутентификации в виртуальном модуле vCenter Server Appliance для отсылки алертов и алармов по почте в защищенном режиме. Можно также использовать и анонимный режим.
Еженедельное оповещение о приближении устаревания сертификатов для служб vCenter Single Sign-On Security Token Service (STS). Напоминалки начинаются за 90 дней и появляются каждую неделю.
Через Managed Object Browser можно сделать hard stop виртуальной машины на случай, если это невозможно сделать из гостевой ОС. Формат вызова такой: https://10.100.200.300/mob/?moid=vm-518&method=terminate
Обновления базовой операционной системы Photon OS.
В основном, этот релиз содержит исправления ошибок, среди которых есть и критические ошибки, приводившие к падению хоста ESXi. Полный список фиксов доступен в тут.
VMware Tools 11.1.5
В основном, этот релиз содержит исправления ошибок, полный список фиксов доступен тут. Также обновился openssl до версии 1.0.2v. Пакеты VMware Tools для Windows подписаны сертификатами Microsoft на базе SHA-2.
Небольшое обновление ESXi 6.5 Update 3 PO5
В основном, этот релиз содержит исправления ошибок, полный список фиксов доступен тут.
Скачать VMware vSphere 6.7 Update 3 и обновленный vCenter 6.7 Update 3j можно по этой ссылке.
Не все администраторы знают, что при апгрейде VMware ESXi на более новую мажорную версию есть возможность сохранить предыдущую конфигурацию гипервизора для возможности отката в случае неудачного обновления. Такая возможность, например, есть при апгрейде ESXi 6.5 на версию 6.7.
Для этого нужно во время установки выбрать пункт "Upgrade ESXi, preserver VMFS datastore". Под датастором тут имеется в виду, что на нем сохранится предыдущая установка ESXi:
Кстати, как видно из скриншота, можно сделать и свежую установку ESXi с возможностью отката к предыдущей версии.
Итак, вы сделали апгрейд ESXi, но что-то пошло не так. Например, ваше железо больше не поддерживается (к примеру, CPU), и вам надо сделать откат к прошлой версии ESXi. Для этого во время загрузки вам нужно нажать комбинацию клавиш Shift + <R>:
После этого можно будет выбрать предыдущую версию ESXi и заменить ей новую установку, полностью откатившись к прошлому гипервизору и его настройкам:
Также можно делать бэкап и восстановление конфигурации VMware ESXi - об этом рассказано в KB 2042141.
Многие администраторы платформы VMware vSphere после выхода седьмой версии продукта обнаружили, что ESXi 7.0 больше не хочет устанавливаться на старом оборудовании. Так происходит с каждой версией VMware vSphere - старые драйверы убирают, новые добавляют - это нормальный цикл жизни и развития продуктов. Например, больше не поддерживаются следующие процессоры:
Intel Family 6, Model = 2C (Westmere-EP)
Intel Family 6, Model = 2F (Westmere-EX)
Однако для тех, кому очень надо, компания VMware оставила небольшую возможность все-таки установить ESXi 7.0 на старом железе со старыми процессорами, но без каких-либо гарантий по работоспособности и поддержке (то есть, статус у этого режима - unsupported). В частности, коллеги написали статью об установке vSphere 7 на сервер IBM M3 X3550 Series.
Для начала решили ставить ESXi на USB-диск, так как RAID-контроллер сервера больше не поддерживается со стороны ESXi 7:
Далее при загрузке установщика ESXi с CD-ROM или ISO нужно нажать комбинацию клавиш Shift + <O> (это буква, а не ноль), после чего появится приглашение ко вводу. Надо ввести вот такую строчку в дополняемую строку:
allowLegacyCPU=true
Далее для установки выбрали USB-диск и начали установку ESXi на него:
После того, как ESXi установится на ваш сервер, вам нужно будет снова нажать Shift + <O> и повторно вбить указанный выше параметр при первом запуске:
Теперь нужно сделать так, чтобы данный параметр добавлялся при каждой загрузке ESXi. Сначала включим сервисы командной строки ESXi и удаленного доступа по SSH. Для этого нужно запустить службы TSM и TSM-SSH на хосте ESXi:
Далее подключаемся к ESXi по SSH и с помощью следующей команды находим файл конфигурации загрузки:
find / -name "boot.cfg
Далее добавляем в него параметр allowLegacyCPU=true в разделе kernelopt:
Два загрузочных модуля ESXi находятся в директориях /bootbank и /altbootbank. На всякий случай надо поменять boot.cfg в обеих директориях.
С помощью команды cat выведите содержимое отредактированных файлов, чтобы убедиться, что параметры загрузки у вас будут сохраняться:
Ну и, собственно, сам сервер ESXi 7.0.0, нормально работающий на сервере IBM x3550 M3:
Бонусом шутка про редактор vi, которым редактировался файл boot.cfg:
Мы уже очень много писали о нововведениях VMware vSphere 7, но все еще есть о чем рассказывать. Не так давно мы говорили об улучшениях горячей миграции виртуальных машин vMotion в ESXi 7 (и тут), а сегодня посмотрим, как был улучшен механизм горячей миграции хранилищ Storage vMotion.
При миграциях SVMotion используется техника Fast Suspend and Resume (FSR), которая очень близка к vMotion, но не идентична ему. При горячей миграции хранилища ВМ происходит создание теневой копии этой машины на том же хосте ESXi, куда подцепляются новые хранилища или устройства, после чего происходит копирование метаданных памяти и состояния устройств от исходной ВМ к целевой. В этот момент машина "замирает" примерно на 1 секунду, а затем происходит включение уже целевой ВМ, а исходная ВМ выключается и удаляется:
Такая же методика применяется и для механизма Hot Add / Remove, который позволяет добавлять и удалять устройства виртуальной машины "на горячую" без необходимости ее выключения. Для выключенной ВМ добавление и удаление устройств - это лишь изменения в конфигурационном файле VMX.
Сам процесс FSR в целом работал довольно неплохо для небольших виртуальных машин, а прерывание работы ВМ укладывалось, как правило, в одну секунду. Но для больших машин (Monster VM) процесс копирования метеданных памяти мог занять продолжительное время.
Во время приостановки ВМ происходит копирование блоков памяти Page Frames (PFrames), представляющих собой маппинги между виртуальной памятью машины и физическими адресами Machine Page Numbers (MPN).
Эти блоки и нужно скопировать во время паузы FSR:
До VMware vSphere 7 во время копирования метаданных памяти использовался только один vCPU машины, в то время как остальные процессоры ВМ ждали окончания процесса и простаивали:
Очевидно, что для больших машин с большим объемом памяти и числом vCPU процесс работал неоптимально. В VMware vSphere 7 для копирования блоков PFrame используются все vCPU. Метаданные памяти разделяются на сегменты, и за копирование каждого сегмента отвечает свой виртуальный процессор. Сам процесс копирования происходит в параллельном режиме, что существенно экономит время на копирование:
Для обычных ВМ это улучшение вряд ли получится почувствовать на практике, но если вы используете Monster VMs, то эффект от обновленного FSR можно будет заметить. Например, VMware взяла машину с 1 ТБ памяти и 48 vCPU, которую перемещала под нагрузкой с помощью Storage vMotion. Так вот время переключения со старым FSR составило 7.7 секунды, а с новым - около 0.5 секунды для VMware vSphere 7:
Мы много писали о возможностях новой версии платформы VMware vSphere 7 (например, тут и тут), но нововведений там столько, что это не уместить и в десять статей. Сегодня мы поговорим об изменениях в структуре разделов
(Partition Layout), которые произошли в VMware ESXi 7.
Первое, что надо отметить, что до vSphere 7 разделы были фиксированного объема, а их нумерация была статической, что ограничивало возможности по управлению ими, например, в плане поддержки больших модулей, функций отладки и стороннего ПО.
Поэтому в vSphere 7 были увеличены размеры загрузочных областей, а системные разделы, которые стали расширяемыми, были консолидированы в один большой раздел.
В VMware vSphere 6.x структура разделов выглядела следующим образом:
Как мы видим, размеры разделов были фиксированы, кроме раздела Scratch и опционального VMFS datastore. Они зависят от типа загрузочного диска (boot media) и его емкости.
В VMware vSphere 7 произошла консолидация системных разделов в область ESX-OSData:
Теперь в ESXi 7 есть следующие 4 раздела:
System boot - хранит boot loader и модули EFI. Формат: FAT16.
Boot-banks (2 штуки)
- системное пространство для хранения загрузочных модулей ESXi. Формат: FAT16.
ESX-OSData - унифицированное хранилище дополнительных модулей, которые не необходимы для загрузки. К ним относятся средства конфигурации и сохранения состояния, а также системные виртуальные машины. Формат: VMFS-L. Для этой области нужно использовать долговременные хранилища на базе надежных устройств.
Как вы видите, ESX-OSData разделен на две части: ROM-data и RAM-data. Часто записываемые данные, например, логи, трассировка томов VMFS и vSAN EPD, глобальные трассировки, горячие базы данных - хранятся в RAM-data. В области ROM-data хранятся нечасто используемые данные, например, ISO-образы VMware Tools, конфигурации, а также дампы core dumps.
В зависимости от размера устройства, куда устанавливается ESXi, меняется и размер всех областей, кроме system boot:
Если размер устройства больше 128 ГБ, то ESXi 7 автоматически создает VMFS-тома.
Когда вы используете для запуска ESXi устройства USB или карточки SD, то раздел ESX-OSData создается на долговременном хранилище, таком как HDD или SSD. Когда HDD/SSD недоступны, то ESX-OSData будет создан на USB-устройстве, но он будет содержать только ROM-data, при этом RAM-data будет храниться на RAM-диске (и не сохранять состояние при перезагрузках).
Для подсистем ESXi, которым требуется доступ к содержимому разделов, используются символьные ссылки, например, /bootbank и /altbootbank. А по адресу /var/core лежат дампы core dumps:
В VMware vSphere Client можно посмотреть информацию о разделах на вкладке Partition Details:
Ту же самую информацию можно получить и через интерфейс командной строки ESXi (команда vdf):
Обратите внимание, что соответствующие разделы смонтированы в BOOTBANK1 и 2, а также OSDATA-xxx.
Кстати, вы видите, что OSDATA имеет тип файловой системы Virtual Flash File System (VFFS). Когда OSDATA размещается на устройствах SDD или NVMe, тома VMFS-L помечаются как VFSS.
ESXi поддерживает множество устройств USB/SD, локальных дисков HDD/SSD, устройств NVMe, а также загрузку с тома SAN LUN. Чтобы установить ESXi 7 вам нужно выполнить следующие требования:
Boot media размером минимум 8 ГБ для устройств USB или SD
32 ГБ для других типов устройств, таких как жесткие диски, SSD или NVMe
Boot device не может быть расшарен между хостами ESXi
Если вы используете для установки ESXi такие хранилища, как M.2 или другие не-USB девайсы, учитывайте, что такие устройства могут быстро износиться и выйти из строя, например, если вы используете хранилища VMFS на этих устройствах. Поэтому удалите тома VMFS с таких устройств, если они были созданы установщиком по умолчанию.
Как вы знаете, компания VMware выпустила платформу VMware vSphere 7 в начале апреля этого года после громкого анонса месяцем ранее. В конце апреля VMware опубликовала интересную новость с результатами исследования среди пользователей, которые тестировали бета-версию vSphere 7 и потом прошли опрос, где одним из вопросов был "Почему бы вы хотели обновиться?". Собственно, вот его результаты...
Компания VMware выпустила на днях обновление одного из самых главных своих документов - "Performance Best Practices for VMware vSphere 7.0". Мы не зря в заголовке назвали это книгой, так как данный документ представляет собой всеобъемлющее руководство, где рассматриваются все аспекты поддержания и повышения производительности новой версии платформы VMware vSphere 7.0 и виртуальных машин в контексте ее основных возможностей.
На 96 листах очень подробно описаны лучшие практики для администраторов платформы и гостевых ОС:
Вот все корневые разделы этого руководства:
Persistent memory (PMem), including using PMem with NUMA and vNUMA
Getting the best performance from NVMe and NVME-oF storage
AMD EPYC processor NUMA settings
Distributed Resource Scheduler (DRS) 2.0
Automatic space reclamation (UNMAP)
Host-Wide performance tuning (aka, “dense mode”)
Power management settings
Hardware-assisted virtualization
Storage hardware considerations
Network hardware considerations
Memory page sharing
Getting the best performance from iSCSI and NFS storage
Для администраторов больших инфраструктур, активно внедряющих новые технологии (например, хранилища с Persistent Memory или DRS 2.0), появилось много всего нового и интересного, поэтому с книжкой нужно хотя бы ознакомиться по диагонали, останавливаясь на новых функциях ESXi 7 и vCenter 7.
Скачать PDF-версию "Performance Best Practices for VMware vSphere 7.0" можно по этой ссылке.
Компания VMware объявила о том что продляет поддержку (General Support) для платформы VMware vSphere версии 6.7 до 15 октября 2022 года. Напомним, что ранее эта поддержка была заявлена до 15 ноября 2021 года. Таким образом, срок действия поддержки General Support был продлен на 11 месяцев.
General Support Phase - эта фаза начинается после выпуска мажорного релиза (GA) и длится довольно долгое время. В этот период пользователи, купившие официальную поддержку VMware (а не купить ее нельзя), получают апдейты и апгрейды, багофиксы и исправления безопасности, а также техническое сопровождение в соответствии с Terms and Conditions.
Дата наступления EoTG (End of Technical Guidance) останется неизменной - это 15 ноября 2023 года. В рамках этой фазы, которая начинается с момента окончания General Support, предоставляются инструкции через портал самообслуживания, а по телефону звонки уже не принимаются. В этой фазе можно открыть кейс в техподдержке онлайн, но только для поддерживаемых конфигураций. В этой фазе VMware не оказывает поддержки, касающейся оборудования, обновлений ОС, патчей безопасности или багофиксов (если о другом не объявлено дополнительно). Предполагается, что в этой фазе пользователи используют стабильные версии ПО и конфигураций при нормальных (не повышенных) нагрузках.
Более подробно о сроках поддержки и Technical Guidance для продуктов VMware можно прочитать в документе "VMware Lifecycle Product Matrix".
Как все уже знают, в новой версии платформы виртуализации VMware vSphere 7 средство обновления виртуальной инфраструктуры VMware Update Manager (VUM) уступило место новому продукту - VMware Lifecycle Manager.
Ранее администраторы vSphere использовали VUM для обновлений серверов ESXi и драйверов, а утилиты от производителей серверов - для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager.
На сайте buildvirtual.net появился обзор процесса апгрейда хост-серверов ESXi на версию 7.0, который мы приводим ниже, чтобы дать понимание того, что сам процесс, в плане накатывания апгрейда, от VUM почти ничем не отличается.
Итак, сначала надо импортировать ISO-образ в Lifecycle Manager. Запускаем его в vSphere Client и переходим в раздел Imported ISOs:
Нажимаем Import ISO и указываем ISO-образ ESXi 7.0, который скачали с сайта VMware:
После этого данный образ появится в списке:
Затем надо создать бейслайн с этим образом. Нажимаем ссылку New Baseline, где далее указываем тип содержимого Upgrade:
Выбираем образ, который мы хотим привязать к бейслайну:
После этого созданный бейслайн нужно привязать к хостам или кластеру. Для этого выбираем пункт Attach Baseline or Baseline Group:
После успешной привязки к кластеру, жмем кнопку Check Compliance, которая запускает проверку соответствия хостов заданному бейслайну. В итоге мы увидим, например, что 4 хоста находятся в статусе non-compliant, то есть им можно накатить апгрейд (в данном случае - с версии 6.7 на 7.0):
Перед запуском апгрейда нужно выполнить Remediation Pre-Check, чтобы проверить, что в кластере нет препятствий для апгрейда хостов на седьмую версию.
Если ничего критичного не нашлось, жмем на кнопку Remediate:
Это, собственно, запустит сам процесс апгрейда. Вам нужно будет лишь согласиться с EULA и запустить процедуру обновления. После успешного апгрейда будет показано, что все хосты были обновлены:
В консоли вы увидите, что ESXi 7.0 установлен:
То же самое будет и в vSphere Client:
Как видно из описаний шагов, процесс апгрейда с помощью Lifecycle Manager практически ничем не отличается от оного с помощью Update Manager.
Вильям Лам написал интересную заметку о том, как пробросить USB-клавиатуру или мышь хоста ESXi (они называются USB HID Devices) в гостевую ОС виртуальной машины на VMware vSphere.
Такое может понадобиться, например, когда требуется пробросить в конкретную ВМ отдельную пару USB-устройств ввода (клавиатура+мышь), помимо выделенного устройства vGPU. Также некоторые другие устройства (например, датчики температуры) также притворяются HID-девайсами. Хост ESXi в этом случае по умолчанию не считает необходимым подцеплять такие устройства никуда.
Это поведение можно изменить, добавив следующие параметры в VMX-файл виртуальной машины (или ее Advanced Settings):
Вторая вещь, которая вам может понадобиться - это проброс USB-устройств Chip Card Interface Devices (CCID) в виртуальную машину (например, ридер смарт-карт). Для этого в VMX нужно добавить следующие строчки:
Frank Denneman обратил внимание на одну интересную новую функцию VMware vSphere 7 - возможность миграции vMotion для виртуальных машин с привязанными ISO-образами.
Как знают администраторы vSphere, часто приходится привязывать ISO-образ к консоли виртуальной машины, чтобы установить какое-то ПО. Нередко этот ISO находится на локальном хранилище машины администратора:
В таком случае, при попытке миграции vMotion данной виртуальной машины выдается ошибка о невозможности выполнения операции в связи с привязанным и активным локальным ISO к виртуальному устройству CD/DVD:
Усугубляется это еще и тем, что такие машины исключаются из миграций DRS, а также не могут быть смигрированы автоматически при переводе хоста ESXi в режим обслуживания (Maintenance mode). Как это обычно бывает, администратор узнает об этом в самом конце, минут через 10 после начала операции по переводу на обслуживание - и агрится от такой ситуации.
Поэтому в VMware vSphere 7 такое поведение пофиксили: теперь при миграции vMotion
виртуальное устройство с локальным файлом отсоединяется от исходной машины по команде процесса VMX, все операции с ним буферизуются, далее происходит миграция машины на другой хост, подцепление к нему виртуального устройства с вашим ISO и накатывание буфера.
После переключения машины на другой хост ESXi, VMRC-консоль показывает подключение вашего локального ISO уже к целевой машине:
Казалось бы, мелочь, но иногда может сэкономить немного времени администратора. Для работы этой фичи нужно, чтобы оба хоста VMware ESXi были седьмой версии или выше.
На сайте проекта VMware Labs появилась очередная полезная штука - виртуальный демо-модуль Demo Appliance for Tanzu Kubernetes Grid, с помощью которого администраторы платформ vSphere и Kubernetes могут протестировать инфраструктуру контейнеризованных приложений в виртуальных машинах.
В состав модуля входят все необходимые компоненты для того, чтобы пользователи могли научиться работе с кластерами Tanzu Kubernetes Grid (TKG) в облаке VMware Cloud on AWS, либо в инфраструктуре vSphere 6.7 Update 3. Это решение можно использовать только в образовательных целях или в рамках тестирования, для производственной среды оно не предназначено.
С помощью данного виртуального модуля за менее чем 30 минут можно развернуть инфраструктуру Kubernetes, имея только SSH-клиент и веб браузер. Работает это следующим образом:
Возможности решения TKG Demo Appliance:
Быстрое развертывания кластеров TKG в облаке или онпремизной инфраструктуре vSphere.
Онлайн-библиотека vSphere Content Library для синхронизации всех связей решения TKG Demo Appliance.
Пошаговое интерактивное руководство по развертыванию и использованию.
Предзагруженный реестр Harbor со всеми необходимыми компонентами TKG и демо-контейнерами.
Поддержка изолированных окружений (Air-Gapped) и окружений без интернета.
Примеры демо-приложений, включая Persistent Volume и приложение K8s 3-Tier Application с балансировщиком нагрузки.
Простой доступ к кластерам и их отладка с помощью Octant.
Еще в версии VMware vSphere 6.7 появилась интересная новая возможность платформы виртуализации - перезагрузка гипервизора без рестарта всего хоста ESXi. Очевидно, что главное преимущество такого подхода - уменьшенное время на загрузку серверов, некоторые из которых грузятся ну ооочень долго.
Ведь для некоторых обновлений и патчей необязательно аппаратно перезагружать хост и реинициализировать все его оборудование, что происходит при стандартной загрузке (процесс power-on self-test, POST). Достаточно лишь перезагрузить программную часть платформы.
Возможность быстрой перезагрузки ESXi Quick Boot может быть использована компонентами vSphere Update Manager или vSphere Lifecycle Manager (vLCM).
Надо отметить, что функции Quick Boot доступны не для всех серверов. Более подробная информация по этому поводу приведена в KB 52477, а вот ссылки на страницы вендоров серверного оборудования, где можно узнать детали поддержки этой технологии:
Для корректной работы Quick Boot есть и некоторые ограничения. Если вы используете vSphere 6.7, то Quick Boot не будет работать, если у вас включен TPM, есть устройства passthru, а также загружены драйверы vmklinux. Для версии vSphere 7.0 ограничением является только включенный TPM.
Для проверки хоста ESXi на совместимость с Quick Boot нужно выполнить следующую команду в консоли (она выведет полный список факторов, препятствующих использованию быстрой загрузки, таких как драйверы, оборудование и т.п.):
/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py
Включить быструю загрузку можно в настройках Update Manager или Lifecycle Manager через vSphere Client или Web Client (этот клиент доступен только для vSphere 6.7):
Не так давно мы писали о той функциональности, которой уже нет в VMware vSphere 7, а также о том, какие фичи находятся в состоянии Deprecated. Это значит, что они пока еще есть в текущем релизе, но уже точно будут отсутствовать в следующей версии платформы. Одной из таких фич стала аутентификация Integrated Windows Authentication (IWA), она же "встроенная проверка подлинности Windows".
IWA - это механизм, который позволяет аутентифицироваться через встроенную аутентификацию ОС в сервисах сервера vCenter, который подключен к домену Microsoft Windows Active Directory (AD).
Депрекация этого механизма в vSphere 7 означает, что вы все еще можете смигрировать настройки IWA при апгрейде vCenter, а также развернуть его с нуля. После этого IWA позволит пользователям аутентифицироваться на vCenter.
Почему поддержка IWA уходит из vSphere? Ответ прост - раньше vCenter работал на платформе Windows как приложение для этой ОС с соответствующими возможностями доступа к ее функциям и сервисам AD, теперь же это виртуальный модуль (vCenter Server Appliance), который работает на базе Linux (а точнее Photon OS) и не может быть нативной частью домена.
Какие альтернативные способы можно использовать для аутентификации в домене AD:
С использованием LDAP. Контроллеры домена предоставляют сервисы LDAP, которые может использовать vCenter.
С использованием нового механизма Identity Federation (появился в версии vSphere 7). Эту возможность можно применять для соединения vCenter к Active Directory Federation Services (ADFS) с использованием протоколов OAUTH2 и OIDC.
VMware также объясняет, что присоединение vCenter к инфраструктурам, которые зависят от этого vCenter, может потенциально создать проблемы зависимостей: контроллер домена зависит от включенного в него vCenter как виртуальная машина, а vCenter зависит от домена как его член.
Еще одна причина депрекации IWA - "политическая". Некоторые крупные организации имеют очень строгие правила для администраторов по заведению новых систем в домен и обслуживанию его жизненного цикла. Нередка ситуация, когда администраторы vSphere, которые имеют право включать vCenter в домен, получают бан аккаунта от безопасников, которые отключают его за неактивность.
Аналогичный подход к депрекации IWA компания VMware сделала и для серверов ESXi - они будут поддерживать взаимодействие с доменом на тех же условиях, что и vCenter. Правами доступа к хост-серверам ESXi можно управлять через стандартный механизм Role-Based Access Controls (RBAC) на сервере vCenter.
Поэтому по совокупности причин было решено отказаться от IWA в пользу более гибкого механизма LDAP/LDAPS.
Кстати, если вы видите в логе контроллера домена событие Event 2889 при использовании IWA, то обратитесь к статье KB 78644.
Чтобы переключиться на новый способ аутентификации нужно вывести серверы из домена по старой схеме и включить интеграцию по новой. Вот, например, видео о том, как смигрировать аутентификацию с LDAP на более защищенный протокол LDAPS:
Перед переходом всей инфраструктуры на новый способ аутентификации нужно обязательно протестировать сам метод в тестовой инфраструктуре. Ну а когда будете делать перевод продакшена, не забудьте сделать снапшот сервера vCenter - если что на него можно будет откатиться с сохранением старых настроек.
Таги: VMware, vSphere, Security, vCenter, ESXi, Microsoft
Недавно компания VMware выпустила интересный документ, объясняющий иногда возникающие проблемы с производительностью операций чтения с NFS-хранилищ для серверов VMware ESXi версий 6.x и 7.x. В документе "ESXi NFS Read Performance: TCP Interaction between Slow Start and Delayed Acknowledgement" рассматривается ситуация с эффектом Slow Start и Delayed Acknowledgement.
Этот эффект возникает в некоторых сценариях с низким процентом потери пакетов (packet loss), когда используется fast retransmit на передатчике и selective acknowledgement (SACK) на приемнике. Для некоторых реализаций стека TCP/IP в случаях, когда передатчик входит в состояние slow start при включенной отложенной квитанции приема пакетов (delayed ACK), квитанция о приеме первого сегмента slow start может быть отложена на время до 100 миллисекунд. Этого оказывается достаточно, чтобы снизить последовательную скорость чтения с NFS-хранилища на величину до 35% (при этом потери пакетов не будут превышать 0.02%).
Более подробно механика возникновения этого эффекта описана в документе. Там же рассказывается и метод борьбы с этим: если вы подозреваете, что у вас подобная проблема, надо просто отключить ESXi NFS Client Delayed ACK и посмотреть, стало ли лучше. Для этого в консоли нужно выполнить следующую команду:
esxcli system settings advanced set -o "/SunRPC/SetNoDelayedAck" -i 1
После этого убеждаемся, что настройка установлена:
esxcli system settings advanced list | grep -A10 /SunRPC/SetNoDelayedAck
Более подробно об этом можно также почитать в KB 59548.
После этого нужно снова провести тесты на последовательное чтение. Если не помогло, то лучше вернуть настройку назад, указав в качестве параметра первой команды -i 0.
Более-менее заметные изменения появились только в vCenter 6.7 U3g:
Появился аларм Replication State Change для виртуального модуля vCSA с Embedded Platform Services Controller, который возникает при переходе репликации между инстансами в статус READ_ONLY. При возвращении в статус Normal аларм исчезает.
Теперь можно использовать утилиту sso-config для замены сертификата Security Token Service (STS).
Несколько исправлений ошибок, приведенных в разделе Resolved Issues.
Обновления Photon OS, о которых можно почитать вот тут.
Обновление ESXi 6.7 Update 3 P02 включает в себя только патчи подсистемы безопасности, а также апдейты драйверов устройств. Более подробно об этом написано вот тут. Скачать это обновление можно через Update Manager или вручную с этой страницы (а далее установить с помощью команды esxcli software vib).
Как вы знаете, обновлением виртуальной инфраструктуры в VMware vSphere 7 вместо Update Manager теперь занимается комплексное средство vSphere Lifecycle Manager (vLCM). vLCM можно использовать для применения установочных образов, отслеживания соответствия (compliance) и приведения кластера к нужному уровню обновлений.
Одной из возможностей этого средства является функция проверок на совместимость (Compatibility Checks). Они нужны, например, в случаях, когда вы настроили интеграцию Hardware Support Manager (HSM) для серверов Dell или HP и хотите проверить оборудование развертываемого сервера на совместимость с ESXi. Это так называемые Hardware Compatibility Checks.
Во время проверок можно использовать кастомный образ ESXi с дополнениями Firmware и Drivers Addon для проверки образов от поддерживаемых вендоров на совместимость с имеющимся у вас оборудованием и установленной версией микрокода. Вот так в vLCM выглядит проверка соответствия для образов ESXi:
На этом скриншоте видно, что текущий уровень компонентов хоста ESXi не соответствует желаемым параметрам в плане версий Firmware аппаратных компонентов. В этом случае есть опция Remediate (кнопка вверху слева), которая позволяет привести хосты ESXi в соответствие, обновив микрокод аппаратных компонентов средствами Hardware Support Manager - и все это прямо из клиента vSphere Client, без сторонних консолей.
vLCM предоставляет также функции автоматической проверки (HCL Automatic Checks), с помощью которых можно автоматически и систематически искать несоответствия уровня firmware на хостах ESXi и сверять их с актуальной онлайн-базой VMware Compatibility Guide (VCG, он же Hardware Compatibility Guide - HCL).
Если вы зайдете в раздел Cluster > Updates, то увидите результат работы автоматического тестирования на совместимость с необходимыми деталями. Пока это доступно только для контроллеров хранилищ vSAN (storage controllers), что является критически важной точкой виртуальной инфраструктуры с точки зрения обновлений (стабильность, производительность).
На скриншоте ниже показаны результаты проверки совместимости в кластере для адаптера Dell HBA330. В данном случае видно, что на всех хостах установлена одинаковая и последняя версия firmware, что и является правильной конфигурацией:
По ссылке "View in HCL" вы сможете увидеть, что данный адаптер с данной версией микрокода действительно поддерживается со стороны VMware vSphere и vSAN.
Если вы на своем Mac решили установить VMware ESXi 7 в виртуальной машине на флешке, то с настройками по умолчанию этого сделать не получится - USB-устройство не обнаружится установщиком и не будет видно в разделе настроек USB & Bluetooth виртуальной машины.
Eric Sloof написал, что перед развертыванием ESXi, чтобы установщик увидел USB-диск, нужно перевести USB Compatibility в режим совместимости с USB 3.0:
После этого можно будет выбрать ваш USB-диск для установки ESXi 7.0:
В начале апреля компания VMware обновила свой основной фреймворк для управления виртуальной инфраструктурой с помощью командных сценариев PowerShell до версии PowerCLI 12.0. Напомним, что прошлая версия PowerCLI 11.5 вышла осенью прошлого года.
Давайте посмотрим, что нового появилось в двенадцатой версии фреймворка:
Добавлены командлеты для управления хостовой сетью ESXi
Еще в vSphere 6.0 появилась поддержка сетевых стеков хостов ESXi. Она позволяет назначить различные шлюзы для адаптеров VMkernel в целях маршрутизации трафика. Через PowerCLI можно использовать ESXCLI или API для управления этой функциональностью с помощью командлетов Get-VMHostNetworkStack и Set-VMHostNetworkStack. Новый параметр называется "NetworkStack", он был добавлен в командлет New-VMHostNetworkAdapter:
Добавлены командлеты для управления решением HCX
Появились новые командлеты для управления пространствами имен
Командлеты для управления службами Trusted Host Services
Командлеты для управления диском гостевой ОС виртуальных машин (VM Guest Disk management)
Теперь раздел гостевой ОС можно замапить на VMDK-диск (пока только для Windows-систем). Для этого потребуется vSphere 7 и VMware Tools не ниже 11-й версии. Эту возможность можно использовать с помощью командлета Get-VMGuestDisk:
Новые командлеты для управления VMware Cloud on AWS
Новые командлеты для vSAN:
Get-VsanFileServiceDomain
New-VsanFileServiceDomain
Set-VsanFileServiceDomain
Remove-VsanFileServiceDomain
New-VsanFileServiceIpConfig
Get-VsanFileShare
New-VsanFileShare
Set-VsanFileShare
Remove-VsanFileShare
New-VsanFileShareNetworkPermission
Add-VsanFileServiceOvf
Get-VsanFileServiceOvfInfo
Новый модуль для управления службами VMware Cloud Services
Добавлена поддержка vSphere 7.0
Добавлена поддержка vRealize Operations 8.0
Обновлена поддержка модулей License и vROps, а также командлета Open-VMConsoleWindow для использования на различных платформах
Поддержка Move-VM для сетей opaque networks
Добавлена поддержка последних обновлений PowerShell 7.0:
Скачать VMware PowerCLI 12.0 можно по этой ссылке. Полезные ресурсы:
На днях на сайте проекта VMware Labs появилась полезная администраторам vSphere штука - утилита vSphere Replication Capacity Planning, позволяющая определить реальное потребление трафика репликации виртуальными машинами и размер передаваемой дельты данных. Это позволяет планировать сетевую инфраструктуру и принимать решения о выделении канала еще до того, как вы включите репликацию для всех своих виртуальных машин.
Утилита Replication Capacity Planning показывает графики, касающиеся объема передачи сетевого трафика LWD (lightweight delta - изменения с момента последней репликации) во времени, а также метрики по размеру дельты в различных временных масштабах - часы, дни, недели и месяцы.
Также в результате работы этого средства для виртуальной машины будет показано, какой объем вычислительных ресурсов и хранилища под реплики вам потребуется на целевой площадке (без учета актуальной политики хранилищ там):
Решение vSphere Replication Capacity Planning развертывается как виртуальный модуль (Virtual Appliance), для его работы потребуется VMware ESXi 6.0 или более поздней версии. Скачать его можно по этой ссылке. Документация доступна здесь.
При развертывании новой версии платформы VMware vSphere 7 в виртуальной машине (вложенные/nested ESXi) на серверах со старыми процессорами вы можете столкнуться с тем, что ваш CPU не поддерживается со стороны платформы:
В этом случае вы все равно можете установить гипервизор ESXi седьмой версии. Для этого вам надо открыть настройки виртуальной машины:
В разделе CPUID Mask нажать ссылку Advanced и далее вбить в регистре eax для Level 1 следующие значения:
Для процессоров Intel CPU: 0000:0000:0000:0011:0000:0110:1100:0011
Для процессоров AMD CPU: 0000:0000:0110:0000:0000:1111:0001:0000
После этого включайте ВМ, где будет установлен ESXi 7, и проходите до конца установки:
После этого ваш ESXi 7 спокойно загрузится. Затем нужно откатить маскирование функций CPU к исходной чистой конфигурации, удалив значение регистра eax:
Обратите внимание, что такая конфигурация не поддерживается в производственной среде! Поэтому используйте такие виртуальные ESXi 7 только для тестирования и других некритичных задач.
Не все в курсе, но одной из новых возможностей обновленной платформы виртуализации VMware vSphere 7 стала поддержка протокола точной синхронизации времени PTP (Precision Time Protocol) для хост-серверов ESXi и виртуальных машин.
С давних пор для синхронизации времени в виртуальных машинах VMware vSphere использует протокол NTP, который обеспечивает точность синхронизации на уровне миллисекунд. Для большинства систем этого вполне достаточно, но есть и класс систем, где нужна точность на уровне микросекунд при обработке последовательности событий - например, для финансовых приложений, торгующих на бирже, где важен порядок ордеров в стакане.
Abhijeet Deshmukh написал про PTP в vSphere интересную статью, основные моменты которой мы приведем ниже.
Протокол NTP обладает следующими особенностями:
Имеет точность на уровне единиц миллисекунд.
Реализуется полностью программно, как для таймстемпинга приема сигналов точного времени, так и для таймстемпинга пользовательского уровня для передачи событий.
Широко распространен и является индустриальным стандартом синхронизации времени.
Работает несколько десятилетий, дешев, прост и надежен.
Клиенты NTP включены во все компьютеры, серверы и роутеры, а также множество программных продуктов.
Может синхронизировать время от самых разных источников - атомные часы, GPS-ресиверы, а также разные серверы, разбросанные по интернету.
Клиент-серверная архитектура, позволяющая использовать несколько серверов для синхронизации.
Возможности коррекции и отказоустойчивости - клиент может забирать время с нескольких серверов и исключать из них тот, который находится географически далеко и отвечает с задержкой сигнала.
NTP - это юникаст-протокол, который не требует особых правил маршрутизации. Пакеты получает только источник и отправитель.
Для виртуальных машин у NTP есть следующие особенности:
Сервер ESXi имеет встроенную поддержку NTP на уровне стандарта, а также имеет необходимые компоненты для его поддержки в kernel API.
NTP работает на порту 123.
NTP бесшовно работает для клиентов-виртуальных машин, где ОС поддерживают эту интеграцию.
Как правило проблем с NTP не возникает для гостевых ОС, за исключением некоторых ситуаций, когда, например, вы делаете Suspend виртуальной машины.
Виртуализация добавляет дополнительные уровни абстракции (например, vNIC), которые потенциально могут повлиять на часы гостевой ОС и переменные синхронизации.
Давайте теперь посмотрим на особенности протокола PTP (IEEE 1588):
PTP работает на уровне точности в микросекундах, для чего используется механизм Hardware time stamping (это специальные сетевые адаптеры с поддержкой PTP).
PTP, определенный стандартом IEEE 1588-2008, работает за счет обмена сообщениями мастер-часов и слейв-часов.
Вот так это выглядит:
Времена отправки и получения событий Sync и Delay_Request сохраняются как 4 таймстемпа T1-T4.
Сообщения Follow_Up и Delay_Response используются для передачи записанных таймстемпов от мастер-часов к слейв, чтобы осуществить коррекцию времени.
По окончании передачи слейв-часы имеют все 4 таймстемпа. Это позволяет посчитать смещение от мастера и скорректировать слейв-часы по формуле: Offset = (T2 + T3 – T1 – T4) /2
PTP в основном используется для обслуживания финансовых транзакций, передачи на уровне телефонных вышек, подводных систем позиционирования и прочих систем реального времени, где требуется высокая точность времени.
PTP поддерживает отказоустойчивость. Если мастер-часы отказывают, то другой мастер принимает на себя его функции, так как находится в постоянном ожидании. Это реализовано средствами алгоритма Best Master Clock (BMC).
PTP работает как мультикаст, а значит генерирует дополнительный трафик и требует специальные правила для его перенаправления между сегментами сети.
Использует 2 UDP-порта - 319 и 320.
В виртуальной машине для поддержки PTP есть специальное устройство precision clock для получения системного времени хоста.
В рамках одной сети через PTP все ее виртуальные машины получают точное время.
В итоге можно сделать следующие выводы об использовании протоколов NTP и PTP в виртуальной инфраструктуре:
Если у вас нет специальных задач под PTP, то старого доброго NTP вполне достаточно. Он надежный и отказоустойчивый.
Для PTP нужно специальное оборудование, появляется мультикастовый трафик, и требуется изменение сетевых настроек, что вызывает необходимость в дополнительных затратах по настройке инфраструктуры. Очевидно, что развертывать его нужно только в случае появления у приложений в виртуальных машинах требования к точности времени на уровне микросекунд.
RSS
