Недавно мы писали о новой службе Virtual Machine Service, которая появилась в последней версии VMware vCenter 7 Update 2a, вышедшей несколько дней назад. Через некоторое время компания VMware обновила и свою основную платформу виртуализации до версии ESXi 7 Update 2a, обновив таким образом оба компонента VMware vSphere 7 до Update 2a.
Основным нововведением ESXi 7 Update 2a (он же билд 17867351) является исправление бага с апгрейдом с прошлых версий vSphere. Пользователи, у которых был настроен кастомный бейслайн vSphere Lifecycle Manager (vLCM), после апгрейда получали вот такую ошибку (для билда 17630552 в комплекте Update 2):
Failed to load crypto64.efi
Теперь старый билд Update 2 был убран из репозитория, а все обновления будут уже до версии 2a.
Также в U2a появилось немало нововведений для VMware vSphere with Tanzu:
Supervisor Cluster
Управление ресурсами Kubernetes через Virtual Machine Service. Об этом мы подробно писали тут.
Самостоятельное создание пространств имен со стороны разработчиков (по шаблону, заданному администратором, который определяет лимиты и права доступа).
Tanzu Kubernetes Grid Service for vSphere
Сервер Kubernetes metrics-server включен по умолчанию. Основные параметры узлов и Pod'ов можно смотреть командой kubectl top.
Система обработки webhooks теперь поддерживает dry-run mode. Теперь такие популярные утилиты, как, например, Terraform Kubernetes provider можно интегрировать с Tanzu Kubernetes Grid Service.
Кастомные классы виртуальных машин (Virtual Machine Classes), которые потребляются через службы VM Service. Это позволяет пользователям выделить различные параметры CPU и памяти, которая выделена виртуальным машинам в кластере Tanzu Kubernetes Cluster.
Обновить инфраструктуру на vSphere 7 Update 2a можно следующими командами в консоли:
На сайте проекта VMware Labs вышло обновление VMware ESXi Arm Edition 1.3. Напомним, что эта версия гипервизора VMware предназначена для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). О прошлом релизе этой платформы мы писали вот тут.
Давайте посмотрим, что нового в ESXi для ARM:
Улучшенная аппаратная совместимость (множество исправлений ошибок и улучшений по поддержке железа).
Добавлена экспериментальная поддержка архитектуры Ampere Altra (только для односокетных систем (подробнее тут).
Поддержка ACPI для виртуальных машин.
Поддержка загрузки через NVMe и PVSCSI в EFI.
Добавлен воркэраунд для загрузки с ISO для некоторых ARM-серверов.
Пофикшена проблема с падением современных ОС при работе на системах на базе Neoverse N1.
Улучшен механизм виртуализации контроллера прерываний для гостевых ОС.
Улучшены средства работы с виртуальными PMU.
Улучена поддержка big endian.
Скачать установочный образ VMware ESXi Arm Edition 1.3 можно по этой ссылке. Помните, что апгрейд с предыдущей версии не поддерживается - надо устанавливать заново.
Небольшое обзорное видео установки ESXi Arm Edition:
Многие администраторы VMware vSphere знают, что для серверов ESXi установлен лимит одновременных миграций vMotion (входящих и исходящих) на один хост = 8 штук. Многие интересуются, а почему именно восемь? Ведь если бы увеличить это число, то виртуальные машины с хоста смогут быстрее эвакуироваться во время проведения планового обслуживания и обновления хостов при их переводе в режим обслуживания (maintenance mode).
Для разъяснения этого VMware написала интересную статью, где рассматриваются результаты тестирования миграций vMotion виртуальных машин при разных значениях параметра, ограничивающего число одновременных миграций.
Лимит на vMotion установлен со стороны сервера vCenter. Он считает ограничения следующим образом. Если на хосте 2 физических сетевых карты 40GbE NIC, выделенных под vMotion, то он считает каждую из них как емкость из 8 слотов с точки зрения миграций, а совокупная емкость хоста равна 16 слотам, из которых 2 тратится на каждую операцию vMotion:
В VMware сделали тестирование производительности одновременных миграций vMotion на хостах ESXi в рамках тестового стенда (он описан в статье), где число Concurrent vMotions регулировали с помощью следующего расширенного параметра vCenter:
config.vpxd.ResourceManager.costPerVmotionESX6x
По умолчанию он равен 2, что означает, что из 16 слотов хоста на каждую vMotion будет тратиться пара слотов, а суммарно будет возможно сделать 8 миграций одновременно. Если поставить это значение в 4, то, соответственно, будет выполняться 4 одновременных миграции (16/4=4).
Надо отметить, что настройка этого параметра не поддерживается со стороны VMware, поэтому не удивляйтесь, что если при его изменении у вас что-то пойдет не так.
Таким вот образом, под разными нагрузками на ВМ, проводили тестирование как восьми одновременных миграций:
Так и четырех:
Если миграции стоят в очереди, то для них отображается статус "Resources currently in use by other operation".
Результаты получились следующими (по оси Х изменяли объем оперативной памяти машин):
То есть восемь одновременных миграций с точки зрения эвакуации всех машин с хоста проигрывают рабочему процессу с четырьмя vMotion.
Аналогично возрастало и среднее время миграции:
Если говорить об использовании памяти, то видно что при 4 одновременных миграциях было передано на 10% меньше страниц памяти, что говорит о более эффективном ее использовании:
Для второго теста выбрали утилиту DVD Store, которую использовали для 2 типов соединений - 10 GbE и 100 GbE:
И здесь тоже результаты получились в пользу 4 одновременных миграций. Та же картина была и для 100 GbE-соединения:
Таким образом, получается, что при большом увеличении числа одновременных миграций vMotion на хосте, удельная производительность каждой такой миграции будет падать.
VMware просто сфокусировалась тут на более эффективном использовании канала для каждой из миграций, поэтому число одновременных vMotion имеет уже не такое влияние, как это было раньше. Поэтому данный параметр и не увеличивается в таблице максимумов от релиза к релизу VMware vSphere.
Как вы знаете, при обновлении виртуальной инфраструктуры в части хостов ESXi с помощью vSphere Lifecycle Manager (vLCM), в кластере HA/DRS хост переводится в режим обслуживания (Maintenance mode), который предполагает эвакуацию виртуальных машин на другие серверы с помощью vMotion. После обновления хоста он выводится из режима обслуживания, и виртуальные машины с помощью DRS постепенно возвращаются на него. В зависимости от характера нагрузки этот процесс может занять от нескольких минут до нескольких часов, что не всегда соответствует ожиданиям администраторов.
Второй вариант - потушить виртуальные машины, обновить ESXi, а потом включить его - тоже не подходит, так как приводит к длительным простоям сервисов виртуальных машин (нужно не только время на обновление хоста, но и время на выключение и включение ВМ, либо их небыстрый Suspend на диск).
Поэтому VMware придумала технологию Suspend-to-Memory, которая появилась в VMware vSphere 7 Update 2. Суть ее в том, что при обновлении ESXi его виртуальные машины приостанавливаются, сохраняя свое состояние (Suspend) в оперативной памяти. Очевидно, что в таком состоянии перезагружать хост нельзя, поэтому данная техника используется только совместно с ESXi Quick Boot, которая подразумевает обновление гипервизора без перезагрузки сервера.
Надо отметить, что функции Quick Boot доступны не для всех серверов. Более подробная информация по поддержке этой технологии со стороны серверных систем приведена в KB 52477, а вот ссылки на страницы вендоров серверного оборудования, где можно узнать детали поддержки этой технологии:
По умолчанию настройка кластера Cluster Remediation для виртуальных машин выставлена в значение "Do not change power state" для виртуальных машин, что подразумевает их vMotion на другие серверы, поэтому чтобы использовать Suspend to Memory, надо выставить "Suspend to memory", как на картинке выше.
При использовании такого типа обновления vLCM будет пытаться сделать Suspend виртуальных машин в память, а если этого не получится (например, недостаточно памяти), то он просто не будет переходить в режим обслуживания.
Надо сказать, что Suspend-to-Memory поддерживает vSAN и работает с такими продуктами, как vSphere Tanzu и NSX-T.
Ну и вот небольшое демо того, как это работает:
Таги: VMware, vSphere, Upgrade, Update, ESXi, VMachines, HA, DRS, Memory
Недавно мы писали о новых возможностях обновленной платформы виртуализации VMware vSphere 7 Update 2, а также новой версии средства создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2. Сегодня мы немного подробнее расскажем о новых возможностях инфраструктуры работы с хранилищами (core storage) в новом обновлении vSphere.
Давайте посмотрим, что именно там нового:
1. Увеличение iSCSI Path Limit
Раньше для одного LUN максимально доступны были только 8 путей, но многим пользователям требовалось существенно больше. Используя несколько портов VMKernel или точек назначения, пользователям иногда было нужно 16 или даже 24 пути. Теперь максимум составляет 32 пути на LUN, что должно хватить всем.
2. Поддержка RDM для RHEL HA
Теперь для для работы Red Hat Enterprise HA можно использовать тома RDM на платформе vSphere. В корневых механизмах работы с хранилищами для этого были сделаны некоторые изменения.
3. Улучшения снапшотов VMFS SESparse
При чтении данных для машин со снапшотами существенно увеличилась производительность, так как чтение идет сразу из нужного VMDK, минуя всю цепочку снапшотов при каждом обращении, в отличие от того, как это было сделано раньше. Все это снижает latency на чтение.
4. Поддержка нескольких адаптеров Paravirtual RDMA (PVRDMA)
В vSphere 6.7 была анонсирована поддержка RDMA. Одним из ограничений было то, что для одной виртуальной машины можно было использовать только один адаптер PVRDMA. Теперь этой проблемы больше нет.
5. Улучшения производительности для томов VMFS
Здесь были сделаны улучшения первых операций чтения для тонких дисков. Они особенно проявляются при резервном копировании и восстановлении, операциях копирования данных и Storage vMotion.
6. Улучшения работы с NFS-хранилищами
Теперь не обязательно создавать клон ВМ для использования offload'а операций по созданию снапшотов уровня дискового массива. Теперь можно использовать любые виртуальные машины на базе снапшотов без необходимости создавать redo logs.
7. Поддержка High Performance Plugin FastPath для Fabric Devices
Плагин HPP теперь используется по умолчанию для устройств NVMe. В плагине есть 2 опции - SlowPath для legacy-поведения и новый FastPath для большей производительности, но с некоторыми ограничениями. Подробнее рассказано вот в этой статье.
8. HPP - дефолтный плагин для vSAN
Начиная с vSphere 7 Update 2, HPP теперь дефолтный MPP для всех устройств - SAS/SATA/NVMe (и Fabric Devices, как было сказано выше).
9. Улучшения VOMA
Средство vSphere On-disk Metadata Analyzer (VOMA) используется для нахождения и исправления повреждений метаданных томов, которые влияют на файловую систему и логические тома. Теперь это доступно и для spanned VMFS-томов. Более подробно об этом можно узнать тут.
10. Поддержка бОльших значений Queue Depth для vVols Protocol Endpoints
В некоторых случаях параметр Disk.SchedNumReqOutstanding (DSNRO) не соответствует глубине очереди на vVols Protocol Endpoint (PE) (он же VVolPESNRO). Теперь глубина очереди для PE равна 256 или берется максимальная глубина видимого LUN. Поэтому минимум PE QD выставлен в 256.
11. Создание Config vVol больше, чем на 4 ГБ
Теперь это позволяет партнерам VMware хранить образы для автоматических билдов на томах VVols.
12. Улучшения правил SPBM Multiple Snapshot
Движок Storage Policy Based Management позволяет администратору управлять фичами хранилищ VVols на уровне отдельных виртуальных машин. Теперь в рамках одной политики SPBM можно использовать несколько правил для снапшотов (например, интервалы их создания). Эта фича должна поддерживаться на уровне VASA у соответствующего производителя массива.
13. Поддержка снапшотов для Cloud Native Storage (CNS) на базе First Class Disks
Тома Persistent Volumes (PV) на платформе vSphere создаются как First-Class Disks (FCD). Это независимые диски без привязанных к ним ВМ. Для них теперь есть поддержка снапшотов и их можно делать в количестве до 32 штук. Это позволяет делать снапшоты ваших K8s PV на платформе vSphere Tanzu.
14. Маппинг CNS PV на vVol
В некоторых случаях пользователи хотят видеть, какие тома VVols ассоциированы с томами CNS Persistent Volume (PV). Теперь этот маппинг можно увидеть в интерфейсе CNS.
Вчера мы писали о новых возможностях обновленной платформы виртуализации VMware vSphere 7 Update 2, а сегодня расскажем о вышедшем одновременно с ней обновлении решения для создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2.
Нововведения сосредоточены в следующих областях:
Давайте посмотрим, что именно нового в vSAN 7 U2:
Улучшения масштабируемости
HCI Mesh Compute Clusters
Теперь в дополнение к анонсированной в vSphere 7 Update 1 топологии HCI Mesh для удаленного доступа к хранилищам vSAN появилась технология HCI Mesh Compute Clusters, которая позволяет иметь вычислительный кластер vSphere/vSAN без собственных хранилищ, использующий хранилища удаленных кластеров.
Самое интересное, что эти кластеры не нуждаются в лицензиях vSAN, вы можете использовать обычные лицензии vSphere.
Также такие кластеры vSAN могут использовать политики хранилищ, в рамках которых можно получить такие сервисы, как дедупликацию / компрессию или шифрование Data-at-rest:
Также было увеличено число хостов ESXi, которые могут соединяться с удаленным датастором, до 128.
Небольшое видео о том, как создать HCI Mesh Compute Cluster:
Улучшение файловых служб
Службы vSAN file services теперь поддерживают растянутые (stretched) кластеры и двухузловые конфигурации, что позволяет использовать их для ROBO-сценариев.
Улучшения растянутых кластеров
Растянутые кластеры vSAN теперь обрабатывают не только различные сценарии сбоев, но и условия восстановления, которые были определены механизмом DRS до наступления события отказа. DRS будет сохранять ВМ на той же площадке до того, как данные через inter-site link (ISL) будут полностью синхронизированы после восстановления кластера, после чего начнет перемещать виртуальные машины в соответствии со своими правилами. Это повышает надежность и позволяет не загружать ISL-соединение, пока оно полностью не восстановилось.
Технология vSAN over RDMA
В vSAN 7 Update 2 появилась поддержка технологии RDMA over Converged Ethernet version 2 (RCoEv2). Кластеры автоматически обнаруживают поддержку RDMA, при этом оборудование должно находиться в списке совместимости VMware Hardware Compatibility Guide.
Улучшения производительности
В vSAN 7 U2 была оптимизирована работа с RAID 5/6 в плане использования CPU. Также была улучшена производительность яруса буффера. Это позволяет снизить CPU cost per I/O.
Кроме того, были сделаны оптимизации для процессоров AMD EPYC (см. тут).
Улучшения для задач AI and Developer Ready
Здесь появилось 2 основных улучшения:
S3-совместимое объектное хранилище для задач AI/ML и приложений Cloud Native Apps.
На платформе vSAN Data Persistence platform теперь поддерживаются компоненты Cloudian HyperStore и MinIO Object Storage. Пользователи могут потреблять S3-ресурсы для своих AI/ML нагрузок без необходимости долгой настройки интеграций.
Улучшения Cloud Native Storage в vSphere и vSAN
Теперь Cloud Native Storage лучше поддерживает stateful apps на платформе Kubernetes. Также vSAN предоставляет простые средства для миграции с устаревшего vSphere Cloud Provider (vCP) на Container Storage Interface (CSI). Это позволит иметь персистентные тома Kubernetes на платформе vSphere и расширять их по мере необходимости без прерывания обслуживания.
Улучшения безопасности
Службы vSphere Native Key Provider Services
Это механизм, который позволяет использовать защиту data-at-rest, такую как vSAN Encryption, VM Encryption и vTPM прямо из коробки. Также для двухузловых конфигураций и Edge-топологий можно использовать встроенный KMS-сервис, который работает с поддержкой ESXi Key Persistence.
Средства для изолированных окружений
VMware предоставляет Skyline Health Diagnostics tool, который позволяет самостоятельно определить состояние своего окружения в условиях изоляции от интернета. Он сканирует критические компоненты на проблемы и выдает рекомендации по их устранению со ссылками на статьи базы знаний VMware KB.
Улучшения Data In Transit (DIT) Encryption
Здесь появилась валидация FIPS 140-2 криптографического модуля для DIT-шифрования.
Упрощение операций
Улучшения vLCM
Для vSphere Lifecycle Manager появились следующие улучшения:
vLCM поддерживает системы Hitachi Vantara UCP-HC и Hitachi Advanced Servers, а также серверы Dell 14G, HPE10G и Lenovo ThinkAgile.
При создании кластера можно указать образ существующего хоста ESXi.
Улучшения защиты данных
При сбое и недоступности хранилищ хост ESXi, который понял, что произошла авария, начинает записывать дельта-данные с этого момента не только на хранилище, где хранится активная реплика, но и в дополнительное хранилище, чтобы обеспечить надежность данных, создаваемых во время сбоя. Ранее эта технология применялась для запланированных операций обслуживания.
Поддержка Proactive HA
vSAN 7 Update 2 теперь поддерживает технологию Proactive HA, которая позволяет проактивно смигрировать данные машин на другой хост ESXi.
Улучшения мониторинга
Здесь появились новые метрики и хэлсчеки, которые дают больше видимости в инфраструктуре коммутаторов, к которой подключены хосты vSAN. На физическом уровне появились дополнительные метрики, такие как CRC, carrier errors, transmit и receive errors, pauses. Также для новых метрик были добавлены health alarms, которые предупредят администратора о приближении к пороговым значениям.
Улучшения vSphere Quick Boot
Здесь появилась техника ESXi Suspend-to-Memory, которая позволяет еще проще обновлять хосты ESXi. Она доступна в комбинации с технологией ESXi Quick Boot. Виртуальные машины просто встают на Suspend в памяти ESXi, вместо эвакуации с хоста, а потом ядро гипервизора перезапускается и хост обновляется.
Скачать VMware vSAN 7 Update 2 в составе vSphere 7 Update 2 можно по этой ссылке. Release Notes доступны тут.
Бонус-видео обзора новых фичей от Дункана Эппинга:
Таги: VMware, vSAN, Update, ESXi, vSphere, Storage, HA, DR, VMachines
Компания VMware выпустила большое обновление серверной платформы виртуализации VMware vSphere 7 Update 2, включающее в себя множество новых возможностей и улучшений. Напомним, что прошлый релиз vSphere 7 Update 1 был выпущен в начале сентября прошлого года, так что времени прошло уже немало.
Нововведения второго пакета обновлений сконцентрированы в трех основных областях:
Давайте посмотрим на новые возможности vSphere 7 Update 2 более детально:
1. Инфраструктура AI и Developer Ready
На основе технологий, анонсированных в 2020 году, компании VMware и NVIDIA сделали совместный анонс платформы AI-Ready Enterprise Platform.
NVIDIA объединилась с VMware для виртуализации рабочих AI-нагрузок в VMware vSphere с помощью NVIDIA AI Enterprise. Это позволяет предприятиям разрабатывать широкий спектр решений для работы с искусственным интеллектом, таких, как расширенная диагностика в здравоохранении, умные предприятия для производства и обнаружение мошенничества в финансовых услугах.
NVIDIA предоставляет пользователям уникальный набор утилит и фреймворков для решения AI-задач на платформе VMware vSphere.
Решение AI Enterprise:
Поддерживает последние поколения GPU от NVIDIA в целях достижения максимальной производительности (до 20 раз лучше, чем в прошлом поколении).
Поддерживает NVIDIA GPUDirect RDMA for vGPUs.
Поддерживает разделение NVIDIA multi-instance GPU (MIG), что позволяет обеспечивать горячую миграцию виртуальных машин c vGPU на борту c помощью vMotion.
Посредством Distributed Resource Scheduler (DRS) обеспечивает автоматическую балансировку машин AI-инфраструктуры по хост-серверам.
Также появились и новые возможности в плане поддержки инфраструктуры контейнеров vSphere with Tanzu:
Интегрированная балансировка нагрузки на приложения посредством VMware NSX Advanced Load Balancer Essentials edition с поддержкой HA с использованием автоматизаций Kubernetes-native (подробнее об этом тут).
Сервисный кластер Tanzu Kubernetes Grid и Supervisor-кластер можно обновить до Kubernetes 1.19.
Улучшенная поддержка сторонних репозиториев, что повышает гибкость и безопасность.
2. Инфраструктурные улучшения и безопасность данных
В этой категории появились следующие новые возможности:
Новый vSphere Native Key Provider - механизм, который позволяет использовать защиту data-at-rest, такую как vSAN Encryption, VM Encryption и vTPM прямо из коробки.
Поддержка Confidential Containers для vSphere Pods, которые используют память AMD SEV-ES и CPU data encryption на платформах AMD EPYC.
Механизм ESXi Configuration Encryption, который использует оборудование Trusted Platform Module (TPM) для защиты ключей ESXi на хостах.
Техника ESXi Key Persistence, которая дает возможности для защиты данных data-at-rest на изолированных хостах.
Обновленные рекомендации vSphere Product Audit Guides, а также FIPS validation для сервисов vCenter Server.
3. Упрощение операций
Техника ESXi Suspend-to-Memory, которая позволяет еще проще обновлять хосты ESXi. Она доступна в комбинации с технологией ESXi Quick Boot. Виртуальные машины просто встают на Suspend в памяти ESXi, вместо эвакуации с хоста, а потом ядро гипервизора перезапускается и хост обновляется.
Оптимизации процессоров AMD EPYC CPU, что приводит к улучшению производительности.
Поддержка рабочих нагрузок Persistent Memory (PMEM) со стороны vSphere HA. Это позволяет техникам DRS initial placement и High Availability полноценно работать в кластере.
Новый функционал решения vSphere Lifecycle Manager with Desired Image Seeding, который позволяет автоматизировать обновление микрокода к желаемому состоянию:
Все фичи vSphere Lifecycle Manager теперь доступны для окружений vSphere with Tanzu.
Функция Desired image seeding позволяет реплицировать информацию о желаемой конфигурации с референсного хоста, экономя время администратора на настройку.
Функция vMotion Auto Scaling, которая позволяет автоматически подстраивать производительность в сетях 25, 40 и 100 Гбит.
Уменьшенное I/O latency и jitter для проброшенных напрямую (passthrough) сетевых адаптеров.
Улучшенная поддержка Virtual Trusted Platform Module (vTPM) для гостевых ОС Windows и популярных дистрибутивов Linux.
Улучшения VMware Tools, включая Guest Store - метод для распространения конфигураций и файлов между виртуальными машинами, а также драйверы Precision Clock drivers для службы Windows Time Service.
Команда 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 появилась очередная полезная штука - 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 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
Недавно появилась новость о том, что некое 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 опубликовала полезный 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 NSX-T, в отличие от его vSphere-версии NSX-V, не имеет графического интерфейса для настройки отсылки логов на серверы Syslog.
Graham Smith написал краткую заметку о настройке Syslog для решения VMware NSX-T, включая NSX-T Manager, узлы Edge Nodes и серверы ESXi.
Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware Log Insight. Сначала заходим по SSH на NSX-T Manager и выполняем там следующую команду, указав IP-адрес сервера Log Insight:
MulNSXT01> set logging-server 192.168.10.8 proto udp level info
WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.
На узлах Edge Nodes
также нужно выполнить такую же команду, зайдя по SSH:
DCA-MulNSXT-ESG01> set logging-server 192.168.10.8 proto udp level info
WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.
На серверах ESXi процесс выглядит несколько иначе. Нужно выполнить вот такую последовательность команд:
[root@DCA-MulComp01:~] esxcli network firewall ruleset set -r syslog -e true
[root@DCA-MulComp01:~] esxcli system syslog config set --loghost=udp://192.168.10.8:514
[root@DCA-MulComp01:~] esxcli system syslog reload
[root@DCA-MulComp01:~] esxcli system syslog mark -s "This is a test message"
Первая команда разрешает в фаерволе трафик Syslog, вторая - настраивает сервер адрес сервера, третья - подхватывает настройки, ну а четвертая - отсылает тестовое сообщение, чтобы можно было проверить работоспособность механизма Syslog со стороны Log Insight.
Там это тестовое сообщение можно увидеть в разделе Events:
Чтобы проверить логирование на стороне фаервола, можно создать простое правило с тестовым тэгом:
Далее в Log Insight можно увидеть это событие, поискав по этому тегу:
Чтобы проверить конфигурацию Syslog на стороне сервера ESXi, нужно выполнить следующую команду:
[root@DCA-MulComp01:~] esxcli system syslog config get
Check Certificate Revocation: false
Default Network Retry Timeout: 180
Dropped Log File Rotation Size: 100
Dropped Log File Rotations: 10
Enforce SSLCertificates: true
Local Log Output: /scratch/log
Local Log Output Is Configured: false
Local Log Output Is Persistent: true
Local Logging Default Rotation Size: 1024
Local Logging Default Rotations: 8
Log To Unique Subdirectory: false
Message Queue Drop Mark: 90
Remote Host: udp://192.168.10.8:514
Strict X509Compliance: false
На стороне NSX-T Manager и на узлах Edge Nodes конфигурацию Syslog можно проверить такой командой:
DCA-MulNSXT-ESG01> get logging-servers
Mon Dec 28 2020 UTC 17:37:16.600
192.168.10.8:514 proto udp level info
Многие администраторы виртуальной инфраструктуры VMware vSphere при планировании апгрейда не выясняют важных моментов, касающихся совместимости продуктов и так называемых upgrade paths, то есть поддерживаемых производителем рабочих процессов обновления платформы. В этой статье мы расскажем о том, что нужно выяснить перед апгрейдом...
На днях компания VMware выпустила обновление VMware vSphere 7 Update 1c, в котором появилось довольно много всего нового для минорного апдейта.
Давайте посмотрим, что именно:
Статистики по физическим сетевым адаптерам - добавилось 5 новых параметров (dropRx, dropTx, errorsRx, RxCRCErrors и errorsTx), которые позволяют вам обнаружить сетевые ошибки и предпринять действия по исправлению ситуации.
Параллельное обновление хостов в кластерах, которые находятся под управлением vSphere Lifecycle Manager. Теперь хосты ESXi под управлением vLCM можно одновременно перевести в режим обслуживания и начать их обновление.
Advanced Cross vCenter vMotion - это функциональность виртуального модуля Cross vCenter Workload Migration Utility, который был предназначен для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). Теперь эта штука интегрирована в vSphere Client, где удобно работать с миграциями ВМ между датацентрами (поддерживается и пакетная миграция нескольких ВМ):
Можно подключать сторонние плагины для управления сервисами на платформе vSAN Data Persistence из vSphere Client таким же способом, как вы управляете сервером vCenter.
Улучшения vSAN DOM scrubber (проверка блоков, к которым давно не было обращений).
Улучшения Supervisor Cluster:
Изоляция пространств имен (Supervisor Namespace Isolation) за счет выделенного маршрутизатора T1 Router (кластеры в сети NSX-T используют для этого новую топологию).
Поддержка NSX-T 3.1 для Supervisor Clusters
Удалена поддержка Supervisor Cluster версий 1.16.x.
Улучшения служб Tanzu Kubernetes Grid for vSphere:
Поддержка HTTP/HTTPS Proxy – вновь созданные кластеры Tanzu Kubernetes могут использовать глобальные прокси HTTP/HTTPS для исходящего трафика, а также скачивать образы контейнеров из интернет-репозиториев.
Вновь созданные кластеры Tanzu Kubernetes из коробки интегрированы со службой vSphere Registry Service. Также с этой службой будут интегрированы кластеры, обновленные до новой версии.
Кластеры Tanzu Kubernetes теперь могут монтировать дополнительные тома к виртуальным машинам, что позволяет увеличивать дисковую емкость узлов. Это дает возможность пользователям развертывать большие образы контейнеров, которые больше дефолтного размера в 16 ГБ.
Скачать VMware vSphere 7 Update 1c можно по этой ссылке. Release Notes доступны тут.
Какое-то время назад мы писали о полезном документе "Product Lifecycle Matrix", в котором приведены основные моменты касающиеся жизненного цикла продуктов VMware: дата доступности продукта для загрузки, окончание поддержки, завершение технического сопровождения и дата снятия с продаж.
Наш читатель Ser указал на интересный ресурс - это онлайн-тул Product Lifecycle Matrix, который выводит актуальную информацию из указанного документа в возможностью сортировки и фильтрации по нужным колонкам:
Удобно, что в таблице можно не только искать нужный продукт (кстати, не ищите vSphere, потому что там продукты разделяются на ESXi и vCenter), но и экспортировать полученный табличный вид в PDF или CSV, а также вывести его на печать.
Красным отмечены даты у продуктов, для которых поддержка или техническое сопровождение заканчивается в ближайшие 6 месяцев, а фиолетовым - те, у которых поддержка уже закончилась. Обратите внимание, что также есть отдельная вкладка для неподдерживаемых и устаревших продуктов.
На днях на сайте проекта VMware Labs появилось очередное интересное обновление - новая версия гипервизора VMware ESXi Arm Edition 1.2 для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства).
Напомним, что о версии ESXi Arm Edition 1.1 мы писали вот тут, а здесь также рассказывали об установке этого гипервизора на платформу Raspberry Pi.
Давайте посмотрим, что нового в VMware ESXi Arm Edition 1.2:
Если у хоста нет датасторов, то datastore browsing отключен
Пофикшен отсутствующий параметр context_id для вызовов CPU_ON
Исправлена проблема с контроллером GICv2 (теперь SGI всегда включены и работают как устройства GIC-500)
Поддержка гостевых ОС на базе big-endian
Убраны требования/ограничения на initrd для ВМ без UEFI
В целом, все это технические фиксы - но обновить вашу тестовую лабу не помешает. Новая версия ESXi Arm встает только как свежая установка, обновление прошлых версий не поддерживается. Можно сохранить прошлые тома VMFS, выбрав опцию "Preserve VMFS", но машины надо будет перерегистрировать заново.
Скачать ESXi Arm Edition 1.2 можно по этой ссылке.
Компания VMware пару недель назад объявила о выпуске бета-версии операционной системы Photon OS 4.0 Beta. Напомним, что эта ОС используется сейчас уже во всех виртуальных модулях VMware (Virtual Appliances), которые реализуют различные вспомогательные сервисы. Напомним, что о прошлой версии Photon OS 3.0 мы писали весной прошлого года вот тут.
Давайте посмотрим, что нового появилось среди возможностей обновленной ОС:
1. Ядро реального времени для приложений телекома и vRAN (Virtual Radio Network)
Наступает эра 5G, и VMware сделала в Photon OS 4.0 возможности поддержки телеком-приложений реального времени на уровне ядра (Photon Real Time kernel). Это позволит технологиям vRAN (Virtual Radio Network) использовать возможности ОС Photon при развитии инфраструктуры 5G-операторов.
2. Безопасность
Photon 4.0 получила поддержку таких технологий по обеспечению безопасности, как SELinux, Security Encrypted Virtualization – Encrypted Status и Intel Software Guard Extensions. Обязательная система контроля доступа, прошитая на уровне ядра, позволяет SELinux дать администраторам гранулярный и гибкий доступ к ресурсам. Также Photon OS позволяет из коробки, на уровне политик, обеспечить нужды приложений в изоляции. Также поддерживается SELinux для контейнеров, что было протестировано для docker, containerd и runc.
Поддержка драйверов Intel SGX drivers позволяет приложениям использовать ресурсы CPU для создания "анклавов" - полностью защищенных модулей исполнения, недоступных на аппаратном уровне другим процессам.
3. Оптимизации производительности для решения vSphere with Tanzu
Исторически Photon ОС имела специальный контекст ядра linux-esx, который был специальным образом оптимизирован для работе на платформе VMware ESXi точки зрения производительности и предоставляемых возможностей. В Photon 4.0 то же самое появилось и для контейнерной среды исполнения vSphere with Tanzu, например, уменьшение времени запуска для контейнеров и приложений.
4. Улучшения компонентов ОС
В Photon 4.0 были обновлены более 700 пакетов, включая ключевые компоненты, такие как tdnf, pmd, network config manager и многие другие. Также в релиз включены превью-фичи для, которые ожидаются в финальной версии ОС. Поэтому рекомендуется не использовать бету Photon 4.0 для производственных сред.
Разработка Photon OS очень сильно опирается на участие комьюнити. Поэтому ваши комментарии, предложения и отчеты об ошибках можно добавлять вот тут.
В этом релизе, как в прошлом, ОС распространяется в бинарном предзапакованном формате - загрузочный ISO, предустановленный минимальный OVA-пакет, кастомизированный под VMware, образ Amazon AMI, образ Google GCE, образ Azure VHD, а также образ Raspberry Pi (протестированный для архитектуры ARM64).
Образы Photon OS 4.0 Beta можно скачать по этой ссылке. Публичный репозиторий доступен вот тут.
VMware на днях выпустила патч VMSA-2020-0023, который окончательно закрывает уязвимость CVE-2020-3992, имевшуюся в сервисе OpenSLP хоста ESXi. Эта уязвимость типа Use-After-Free позволяла злоумышленнику, имевшему доступ к 427 порту, получить возможность удаленного исполнения кода (эта уязвимость имела критический статус и CVS score 9.8 из 10).
VMware заявляет, что данные патчи, выпущенные 20 октября, не закрывают уязвимость полностью, поэтому нужно скачивать самые последние версии патчей:
IMPORTANT: The ESXi patches released on October 20, 2020 did not address CVE-2020-3992 completely, see section (3a) Notes for an update.
Вот сами обновления, которые были выпущены:
ESXi 7.0 - ESXi70U1a-17119627. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi_7.0.1-0.0.16850804
ESXi 6.7 - ESXi670-202011301-SG. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi670-202010401-SG
ESXi 6.5 - ESXi650-202011401-SG. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi650-202010401-SG
Воркэраунд, описанный в статье базы знаний KB 76372, все еще актуален. Его суть заключается в полном отключении сервиса SLP с помощью следующих команд:
/etc/init.d/slpd stop
esxcli network firewall ruleset set -r CIMSLP -e 0
chkconfig slpd off
На сайте проекта VMware Labs появилась очередная полезная штука - Storage Performance Tester. С помощью данного средства администраторы VMware vSphere могут в один клик проверить производительность хранилищ в плане IOPS, Latency и циклов CPU на одну операцию ввода-вывода для серверов VMware ESXi.
Эта утилита автоматизирует все шаги, которые необходимо предпринять для тестирования, включая развертывание виртуальных машин, запуск нагрузки по вводу-выводу, а также анализ производительности хранилища. Метрики, полученные в результате тестирования, визуализируются на графиках. Единственная вещь, которую вам нужно сделать - это выполнить соответствующую команду и ждать сгенерированного отчета о производительности хоста ESXi.
Средство создано как для администраторов платформы vSphere, так и для разработчиков, которым требуется решать проблемы производительности в виртуальной инфраструктуре. Также Storage Performance Tester удобно использовать для получения максимальных параметров производительности аппаратного обеспечения, а также программных компонентов (драйверы, настройки vSphere и vSAN).
Для запуска тестовой среды вам понадобятся:
python3
sshpass
2 ГБ свободного места
Linux-окружения (с версией ядра не менее 2.6.31)
Вот небольшое обзорное видео, где можно посмотреть всю процедуру запуска утилиты и, собственно, сам отчет с результатами тестирования:
Скачать Storage Performance Tester можно по этой ссылке.
Недавно на сайте проекта VMware Labs появилось обновление этой платформы до версии 1.1. Эту версию нужно обязательно ставить заново, потому что обновление с версии 1.0 не поддерживется.
Давайте посмотрим, что там появилось нового:
Исправлена критическая ошибка, вызывавшая розовый экран смерти (PSOD) при добавлении к коммутатору VDS (см. тут)
Поддержка аппаратной платформы Arm N1 SDP
Поддержка виртуальных машин на процессорах Neoverse N1 CPU
Улучшения стабильности работы на платформах LS1046A и LX2160A
Исправления ошибок для отображения некорректного использования CPU на vCenter/DRS
Исправление ошибки с аварийным завершением виртуальной машины при полной заполненности хранилища
Исправление ошибки с поддержка устройств non-coherent DMA
Теперь можно ставить гипервизор имея в распоряжении 4% от 4 ГБ памяти вместо 3.125 (критично для некоторых аппаратных платформ)
Улучшения работы с последовательным портом
Обновление документации (больше информации об iSCSI, документы по платформам LS1046ARDB и Arm N1SDP, обновлен список поддерживаемых гостевых ОС)
Скачать VMware ESXi Arm Edition 1.1 можно по этой ссылке. Ну и бонусом несколько видео от Вильяма Лама по использованию этой платформы:
Многие из вас знакомы с одноплатной ARM-архитектурой компьютеров Raspberry Pi, которые позволяют модульно собирать очень крутые штуки для целей тестирования и обучения. Недавно компания VMware выкатила технологическое превью гипервизора ESXi для процессоров ARM (он же ESXi-Arm), которое доступно на сайте VMware Labs.
Конечно же, многие пользователи бросились устанавливать его на компьютеры Raspberry Pi, которые в большом количестве есть у энтузиастов. Оказалось, что поставить туда ESXi весьма простая задача, особенно, если речь идет о Raspberry Pi 4.
2x USB drive (один для записи гипервизора, а второй как installation media)
Кабель USB-C (питание)
Micro HDMI для монитора
Сначала лучше прочитать официальный гайд по продукту, который есть на странице ESXi-Arm сайта VMware Labs. Для старых модификаций Raspberry Pi могут быть нюансы, но с новыми для Windows порядок примерно такой:
Копируем содержимое загрузочной директории на SD-карту
Копируем содержимое архива RPi4_UEFI_Firmware_v1.20.zip с перезаписью поверх существующего содержимого на SD-карту
Если у вас Raspberry Pi на 4 ГБ, открывайте config.txt и добавляйте следующую строчку в конец файла без пробелов: gpu_mem=16
Настраиваем UEFI:
Вставляем SD-карту в Raspberry Pi
Подключаем USB-клавиатуру и монитор по HDMI
Подключаем питание через USB-C
Нажимаем ESC до того, как покажется UEFI menu
Идем в раздел:
Device Manager > Raspberry Pi Configuration > Advanced Configuration
Подсвечиваем опцию Limit RAM to 3GB
Нажимаем Enter и стрелками на клавиатуре выставляем значение DISABLED
По F10 сохраняем конфигурацию
Нажимаем ESC, чтобы выйти на домашнюю страницу
Идем к Continue и нажимаем Enter
Тепреь загружаем установочный образ VMware-VMvisor-Installer-7.0.0-16966451.aarch64.iso по этой ссылке.
Теперь из ISO-образа с помощью UNetbootin надо создать загрузочную флешку:
Далее:
Вставляем установщик на USB-флешке в Raspberry Pi
Нажимаем ESC до того, как покажется UEFI menu
Выбираем USB-флешку первой в порядке загрузки
После начала загрузки ESXi:
Быстро нажимаем SHIFT+O (это буква)
Внизу экрана вбиваем autoPartitionOSDataSize=8192 (это ограничит установку ESXi 8 ГБ, остальное пространство можно будет отдать под датастор для виртуальных машин)
При установке ESXi убедитесь, что указано корректное устройство для установки гипервизора
Вставляем сетевой кабель и убираем флешку
Далее после включения нужно опять пойти в Boot Maintenance Manager > Boot Options > Change Boot Order и выбрать там флешку, куда вы установили ESXi:
После этого ваш ESXi загрузится и получит IP-адрес от DHCP, который лучше заменить на статический. После этого вы можете соединиться с хостом через веб-интерфейс и увидеть, что для остатков пространства на флешке был создан датастор для виртуальных машин.
Суть ее заключается в том, что при удалении снапшота ВМ, по завершении ее резервного копирования, она замирает примерно на 30 секунд, не принимая никакой ввод-вывод. Происходит это на некоторых NFS-хранилищах, в частности HPE SimpliVity. В итоге - приложения, чувствительные ко времени, работают плохо, ну и в целом такое поведение не очень приятно для производственных систем.
Проблема проявилась при использовании платформы VMware vSphere 6.7, текущей версии Veeam Backup and Replication и хранилища HPE SimpliVity, которое поддерживает презентацию томов только в режиме NFS v3.
При этом в такой же комбинации продуктов, но на блочных хранилищах удаление снапшота занимало 1-2 секунды.
После общения с поддержкой нашлись следующие workaround'ы, которые не подошли:
Использовать NFS v4 вместо v3 (доступно не на всех хранилищах)
Использовать другой транспорт (transport mode), например, Direct access или NBD (Network Block Device). Но Direct access доступен не всегда, а NBD - медленный режим.
Можно использовать режим hot-add с виртуальным модулем backup appliance, но тогда он должен быть на каждом хосте (см. KB 201095).
Можно отключить синхронизацию времени с хостом для ВМ с приложениями, которые страдают из-за замирания времени в гостевой ОС. Об этом можно почитать в KB 1189. Но это так себе решение.
На текущий момент получается, что это проблема именно VMware ESXi, см. статью KB 2010953. Также она описана и в базе знаний Veeam - KB 1681 (там же указаны и обходные пути). Таким образом, выходит, что в некоторых случаях ни одно из решений не подходит на 100%.
Недавно мы писали об анонсе 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 были посвящены следующие сессии, которые вы можете найти тут:
RSS
