В вышедшем на днях обновлении VMware vSphere 7 Update 2a (обновился только vCenter) компания VMware представила службу vSphere Virtual Machine Service (она же VM Service), которая дает разработчикам и администраторам, работающих со средой контейнеров Kubernetes в решении vSphere with Tanzu, возможности по развертыванию виртуальных машин.
Это позволит командам DevOps управлять инфраструктурой виртуальных машин и контейнеров через стандартные Kubernetes API, обеспечивая единый процесс по развертыванию новых служб и доступности инфраструктуры.
Служба VM Service дополняет ранее анонсированные службы Network Service и Storage Service, которые дают возможности по управлению через API сетью и хранилищем, соответственно, в среде vSphere with Tanzu. Вот хороший обзор новых функций VM Service:
Со стороны vSphere служба встроена напрямую в vCenter, она позволяет управлять образами ВМ (VM Images / Content Libraries) и классами ВМ (VM Classes / VM sizing).
Со стороны Kubernetes компонент называется VM Operator, он создает и обслуживает ресурсы Kubernetes Custom Resources (CRs/CRDs), а также общается с компонентом на стороне vSphere.
VM Service даст компаниям следующие преимущества:
Разработчикам в среде Kubernetes больше не требуется создавать заявки на создание ВМ для администраторов.
Администратор может преконфигурировать заданные классы ВМ, доступные разработчикам, задав лимиты их ресурсов, а также обеспечив защиту и изоляцию от продуктивного окружения.
Некоторые приложения в контейнерах, например, могут использовать базу данных, размещенную в ВМ. В этом случае разработчик сможет создать спецификацию такого сервиса в YAML и обслуживать такую структуру самостоятельно.
Open Source природа сервиса позволит дорабатывать и создавать новые службы с учетом потребностей больших команд. Репозиторий компонента VM Operator находится тут.
Более подробно о службе vSphere Virtual Machine Service рассказано в этой статье. Служба VM Service доступна в последнем релизе VMware vSphere 7 Update 2a.
На сайте проекта VMware Labs недавно обновился основной клиент для управления инфраструктурой vSphere - VMware vSphere Client, а через пару дней после этого обновился и мобильный клиент - вышел vSphere Mobile Client версии 2.2. Напомним, что последний раз об этом клиенте мы писали летом прошлого года вот тут.
Давайте посмотрим, что нового появилось в мобильном клиенте, начиная с версии 2.0:
Добавлена поддержка VMware Cloud в части VMware Cloud on AWS, что позволяет получить доступ к облачным серверам через мобильное устройство
Добавлен фильтр по серьезности проблем в разделах Alarm и Events
Добавлена клавиша Windows в виртуальной клавиатуре и для сочетаний клавиш
Улучшена стабильность консоли ВМ при повороте устройства
Добавлена забытая кнопка Back в разделах страниц логина
Обновлены иконки и сплэш-скрины
Теперь на странице деталей ВМ есть навигация по связанным объектам
Страница деталей виртуальной машины грузится быстрее, когда ВМ выключена
Скачать vSphere Mobile Client 2.2 можно по этим ссылкам:
Также не забудьте посмотреть инструкцию о развертывании Notification Service, чтобы включить Push-уведомления на своих устройствах. Его можно развернуть в одном из двух вариантов:
Клиентам новой площадки доступен весь спектр услуг «ИТ-ГРАД». Сервис актуален для компаний, которые используют облачные технологии для цифровизации бизнеса. Для связи между площадками используются выделенные каналы, позволяющие предоставлять заказчикам геораспределенные сервисы.
Облачная среда запущена с использованием высокочастотных процессоров Intel Xeon Gold 6248R с базовой тактовой частотой 3ГГц, а также Intel Xeon Platinum 8268 с частотой 2,9 ГГц. Новые процессоры обеспечивают высокую производительность клиентских приложений, чувствительных к частоте процессора, таких как 1С и SAP.
В качестве платформы виртуализации «ИТ-ГРАД» использует VMware vSphere 7.0. Для управления виртуальной инфраструктурой заказчикам предоставляется персональный портал самообслуживания. Для размещения данных используются системы хранения Huawei Dorado 8000 v6 в состав которых входят быстрые твердотельные накопители с поддержкой технологии NVME. Этот тип дисков подходит для размещения высоконагруженных ERP-систем. Резервное копирование и восстановление данных в облаке осуществляется с помощью системы Veeam Backup & Replication 11.
«Спрос на облачные сервисы растет с каждым годом и «ИТ-ГРАД» увеличивает количество площадок для обеспечения потребностей бизнеса. Linxdatacenter стал нашей пятой облачной площадкой, наряду с дата-центрами в Москве, Санкт-Петербурге и Алматы. Клиенты облака имеют единый высокий уровень сервиса на всех локациях», – прокомментировала генеральный директор «ИТ-ГРАД» Ирина Харченко.
Подробнее о Linxdatacenter:
Linxdatacenter входит в топ-5 провайдеров услуг ЦОД в РФ в 2020 году по версии CNews. Дата-центр в Санкт-Петербурге расположен по адресу: ул. Репищева, д. 20А.
Площадка соответствует уровню надежности TIER III по стандарту TIA-942 и методологии Uptime Institute, подтвержденному сертификатом Uptime Institute Management & Operations Stamp of Approval.
На сайте проекта VMware Labs обновился основной клиент VMware vSphere на базе технологии HTML5 (он же vSphere Client в составе платформы VMware). Напомним, что старый клиент Web Client на базе Adobe Flex ушел в прошлое, и VMware предлагает использовать только новый клиент для управления виртуальной инфраструктурой.
Кстати, VMware vSphere HTML5 Web Client версии 5.0 (build 15670023) - это первое обновление клиента за довольно долгое время. Давайте посмотрим, что там появилось нового:
Обновлена документация (в том числе инструкции, где находятся файлы и сервисы клиента)
Добавлен новый язык для функции Code Capture - теперь записанные во время сессии действия могут транслироваться в код на языке Go.
PowerActions - это новый механизм интеграции PowerCLI и vSphere Client. Теперь в клиенте есть функциональность по запуску отдельных команд и сценариев PowerCLI, а также функции их хранения в библиотеке скриптов. Исполнение кастомных действий скриптов можно привязать к объектам из inventory в клиенте.
Функцию PowerActions надо включать отдельно при развертывании клиента (см. документ PowerActions_documentation_Fling50.pdf).
Базовая операционная система виртуального модуля vSphere Client была заменена на Photon OS, поэтому апгрейд с прошлой версии не поддерживается - придется развертывать все по-новой.
Загрузить новую версию клиента VMware vSphere HTML5 Web Client 5.0 можно по этой ссылке. Инструкции по установке и использованию доступны тут. Также много всего интересного есть в комбо-боксе выбора компонентов загрузки:
Как знают многие администраторы VMware vSphere, у этого вендора есть платформа VMware Customer Connect Learning, которая объединяет различные каналы обучения ИТ-специалистов. На этой платформе вы можете получить доступ к обучающим видео, интерактивным лабораторным работам, руководствам по подготовке к сертификационным экзаменам и материалам инструкторов по продуктам VMware vSphere, vSAN, Horizon, NSX, vRealize Suite и многим другим.
Подписка Customer Connect Learning состоит из трех уровней:
Basic Tier - начальный уровень для операторов, консультантов и специалистов начального уровня. Здесь включены обзорные материалы по продуктам, курсы eLearning и траблшутинга, а также некоторый контент от экспертов.
Premium Tier - это уже полноценная подписка для администраторов и профессионалов по продуктам VMware, которая включает в себя Learning Video Library, тестирование текущих навыков и подготовку к сертификациям.
Enterprise Tier - предложение для компаний и ИТ-департаментов, которое включает в себя комплексный подход к обучению рабочих групп. Здесь есть и on-demand курсы, лабораторные работы hands-on labs, тренинги в виртуальных рабочих классах, трекинг прогресса обучения и многое другое.
Вот небольшая инфографика от VMware по теме подписок на обучение:
Подписка Customer Connect Learning Basic включает в себя:
Более 60 обучающих модулей e-learning
1357 обучающих видео
Материалы для подготовки к экзаменам VMware Certified Technical Associate
Подписка Customer Connect Learning Premium включает в себя:
Более 65 обучающих модулей e-learning
Более 1500 видео в стиле "how-to"
650 видео для подготовки к экзаменам VMware Certified Professional (VCP) и VMware Certified Advanced Professional (VCAP)
Контент для уровня VMware Certified Technical Associate (VCTA)
Цена премиальной подписки Customer Connect Learning Premium Subscription составляет 268,14 евро в год, включая VAT (218 евро без VAT):
Купить Customer Connect Learning Premium Subscription можно здесь. Надо понимать, что премиум-подписка не включает в себя Hands-on Labs, получить их можно только в рамках Enterprise-подписки.
Некоторое время назад мы опубликовали статью о протоколах NTP и PTP, которые отвечают за работу служб точного времени для хоста ESXi и виртуальных машин.
Оказывается, в весеннем обновлении VMware vSphere 7 Update 2 появилась поддержка нового механизма Precision Time for Windows. Раньше для почти всех задач в виртуальных машинах использовалась связка NTP+Active Directory, которая работает отлично в подавляющем большинстве случаев. NTP обеспечивает точность на уровне миллисекунд, а если нужна какая-то большая точность (например, финансовые приложения), то тут можно использовать специальное оборудование с поддержкой PTP (Precision Time Protocol).
VMware решила сделать еще одно улучшение для пользователей, которым требуется повышенная чувствительность служб точного времени. Теперь в vSphere 7 Update 2 есть поддержка Precision Time for Windows - механизма, который улучшает точность синхронизации времени в ОС Windows.
Сервис Windows Time Service (W32Time) - это служба, которая опирается на NTP и предоставляет клиентам ОС информацию о точном времени. В основном она нужна для синхронизации времени между хостами в Active Directory, но уже вышла за рамки этих задач и может быть использована приложениями. Архитектура W32Time построена на базе плагинов, что означает, что DLL-библиотека может быть зарегистрирована как провайдер служб точного времени. Это могут быть как чисто программные решения, так и комплексные системы со специальным оборудованием с поддержкой PTP-протокола.
API-интерфейсы для разработки таких плагинов находятся в открытом доступе, каждый может написать свой собственный. Вот и VMware разработала свой VMware Time Provider (vmwTimeProvider), который поставляется вместе с VMware Tools для ВМ на базе Windows. Он получает время от виртуального устройства Precision Clock (оно появилось еще в vSphere 7.0) и передает его на сторону W32Time по закрытому и быстрому каналу (на базе технологии паравиртуализации), минуя сетевой стек.
vmwTimeProvider - это плагин, работающий в пространстве user-space. По идее такое устройство требовало бы собственный драйвер, но у VMware есть собственный паравиртуализованный интерфейс, который использует преимущества технологии Memory-mapped I/O (MMIO), оптимизированной под операции чтения.
Устройство Precision Clock получает время от ядра гипервизора (VMkernel), одним из источников является устройство HyperClock, поставляющее в ядро системное время. Таким образом, если вы настроите VMkernel и HyperClock на получение времени через Precision Time Protocol (PTP), то устройство Precision Clock будет передавать его в виртуальные машины с большой точностью.
Ну и в завершение надо отметить, что vmwTimeProvider не выбран по умолчанию при установке, так как он не нужен системам без специальных требований к службам времени.
Многие администраторы 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.
Релиз платформы VMware vSphere 6.5 в свое время (а это была осень 2016 года) оказался довольно удачным, поэтому до сих пор довольно большое количество пользователей используют его в производственной среде.
В июне прошлого года VMware объявила о продлении поддержки vSphere 6.7 в связи с пандемией, но кто ж знал, что все настолько поменяется, поэтому о продлении срока поддержки версии 6.5 сообщили только сейчас.
Теперь период general support period для vSphere 6.5 продлен на 11 месяцев до 15 октября 2022 года, что совпадает с аналогичным для vSphere 6.7. До этого момента достижение точки прекращения предоставления полной технической поддержки (EoGS, End of General Support) было намечено на 15 ноября 2021 года. Но окончание технического сопровождения (EoTG, End of Technical Guidance) не изменилось - оно наступит 15 ноября 2023 года.
У VMware нет планов продлевать период Extended Support для vSphere 6.5, поэтому тем, кому это важно, следует смигрировать хотя бы на vSphere 6.7, где расширенная поддержка будет действовать подольше.
Расширение поддержки для vSphere 6.5 будет с некоторыми ограничениями:
Нужно будет использовать vCenter 6.7 для хостов ESXi 6.5, потому что там есть обновленный vSphere Client вместо старого Web Client.
Для хостов на базе vCenter Server Appliance нужно будет обновиться на vCenter Server to 6.7 Update 3 (см. тут подробнее).
vCenter Server for Windows нужно проапгрейдить до vCenter Server to 6.7 Patch 05 или более поздней версии (см. тут).
Если вы не сможете обновить vCenter, то будет допустимо использовать vCenter 6.5, но как-то поддерживать работоспособность Flash-клиента (см. тут).
Аналогично продляются сроки оказания технической поддержки для VMware vSAN 6.5 и 6.6 до тех же дат и с теми же условиями, что и для vSphere: теперь окончание поддержки наступит 15 октября 2022 года, но EoTG также не изменится:
Ограничения расширения поддержки для vSAN остаются теми же, что и для VMware vSphere.
Все, кто хоть раз сталкивался с инфраструктурой виртуальных ПК VMware Horizon, знает, что в этом решении есть 3 способа развертывания виртуальных ПК для нужд различных типов пользователей. Делается это с помощью одного из следующих видов клонов:
Full Clone - полная копия родительской виртуальной машины, абсолютно никак с ней не связанная и действующая как полноценная новая ВМ.
Linked Clone - связанный клон виртуальной машины, создаваемый со стороны View Composer, который использует общее для всех клонов хранилище реплики на чтение, но имеет собственное хранилище для операций записи (дельта-диск или redo log). Память такой ВМ полностью независима от родительской ВМ, которая называется репликой (потому что она получается путем создания дубликата мастер-образа).
Instant Clone - это мгновенный клон работающей виртуальной машины, то есть имеющий с ней не только общее хранилище на чтение, но и общую память, для которой также используется техника copy-on-write. То есть это больше похоже на контейнерную виртуализацию.
Давайте теперь посмотрим на все эти виды клонов в деталях:
Full Clone
Это самый простой и понятный случай. С точки зрения производительности это всегда будет лучший вариант, так как это обычная виртуальная машина. Функциональность тут та же, что и для обычных ВМ. Очевидно, что главный минус - это скорость развертывания такой ВМ под новых пользователей, ведь нужно физически скопировать данные ее виртуальных дисков.
Но есть и еще некоторый минус по сравнению со связанными и мгновенными клонами - это обновления. Так как полные клоны содержат свою копию ОС, то вам нужно обновлять каждую машину, а не только реплику/родительскую ВМ, как в случае с Linked и Instant Сlones.
В целом, тут рассказывать особо больше не о чем, параметры производительности полного клона можно взять за эталон по отношению к остальным видам.
Linked Clone
Связанные клоны появились довольно давно в решении VMware View (тогда Horizon еще не было). Их созданием занимался и продолжает заниматься компонент VMware View Composer, который управляет процессами, связанными с развертыванием пулов виртуальных десктопов.
Суть таких клонов заключается в создании реплики от мастер-образа виртуального ПК, который подготовлен к массовому развертыванию (настроена ОС и установлены приложения). Реплика является родителем для новых виртуальных десктопов в плане их общего хранилища на чтение. Все операции чтения, которые создают клоны, складываются в отдельные дельта-диски за счет технологии copy-on-write, позволяющей при записи операции I/O перемещать ее в отдельный файл отличий от родительского диска.
Это очень удобно - такие десктопы создаются очень быстро (нужно только создать дельта-диски), реплика не должна быть включена и активна (только ее хранилище), а хранилище очень сильно экономится, ведь общие данные (предустановленные приложения и ОС) хранятся только в одном экземпляре. Такая модель идеально подходит для временных ПК - например, для сотрудников кол-центров, которые используют какое-то приложение во время работы (например, CRM), но в остальное время десктоп оказывается не нужен.
В этом случае, в соответствии с политикой пула Linked Clone, виртуальный ПК можно уничтожить после отключения пользователя или оставить висеть до следующего логина, а уничтожать после операции Log off. Что еще тут важно - к такому десктопу можно прицепить persistent-диск, который будет сохранять данные пользователя даже при выключении десктопа.
Недостатки тоже очевидны: инфраструктура связанных клонов опирается на компонент View Composer и зависит от его надежности, а операции записи и чтения работают медленнее, так как при записи данных нужно потратить ресурсы на обработку механизма copy-on-write, а при чтении - найти откуда данные считать - из базового образа или из дельта-дисков пользователей.
Тут надо обязательно отметить, что начиная с VMware Horizon 8 (2006), связанные клоны помечены как Deprecated-функционал, то есть вскоре (а именно, в следующей мажорной версии Horizon) будет произведен переход на мгновенные клоны, о которых рассказано ниже.
Instant Clone
Функция мгновенного клонирования виртуальной машины (ранее известная как технология VMFork) позволяет очень быстро сделать работающую копию запущенной ВМ на платформе VMware vSphere. Что важно, она не зависит от централизованного сервера, а реализована прямо на уровне гипервизора VMware ESXi. Появилась эта возможность в vSphere 6.7 и до сих пор совершенствуется.
Работает мгновенное клонирование так: посредством Memory copy-on-write "на лету" создается клон виртуальной машины (VMX-файл, процесс в памяти), который начинает использовать ту же память (Shared memory) на чтение, что и родительская ВМ. При этом дочерняя ВМ в общую память писать не может, а для записи и чтения собственных данных используется выделенная область памяти. Для дисков аналогично - с использованием технологии Copy-on-write в дельта-диск дочерней ВМ пишутся отличия от базового диска родительской ВМ:
Такой подход больше похож на контейнерную виртуализацию, где в рамках одной общей ОС работает несколько изолированных окружений - и это действительно так, со всеми его плюсами и минусами. Плюсом является экономия дискового пространства и памяти, а также скорость создания такого клона - он не просто быстрее создается, но и сразу включен и готов к использованию. Еще очевидным преимуществом является независимость технологии мгновенных клонов от сервисов View Composer, а значит в этом смысле надежность инфраструктуры таких ПК несколько выше.
Цикл включения нового десктопа для мгновенных клонов гораздо короче:
Минусы здесь те же самые, что и для связанных клонов, только добавляются ограничения по числу дочерних ВМ на одну родительскую, издержки на поддержание сложной системы работы с памятью (что влияет на безопасность и производительность), а также отсутствие поддержки некоторых функций.
Причина падения производительности ввода-вывода проста: у родительской ВМ создается дельта-диск, который используется первым мгновенным клоном, потом базовая ВМ несколько меняется за время до создания следующего - и на момент создания нового мгновенного клона будет использоваться уже следующий дельта-диск и так далее.
Такая схема имеет недостаток в том, что у родительской ВМ плодятся дельта-диски, что приводит к тому, что быстродействие родительской ВМ замедляется, а сама структура за счет увеличения числа дисков существенно усложняется, что потенциально может привести к различного рода сбоям.
Сейчас для связанных клонов недоступны следующие возможности:
Кастомизация машин средствами Sysprep и Quickprep
ОС Windows 8 и 8.1
Функции Persona Management
Тома Virtual Volumes (VVols)
Нативные снапшоты на хранилищах через VAAI (vStorage APIs for Array Integration)
Указание имен компьютеров ВМ вручную (это доступно для связанных клонов в пулах dedicated- или floating-)
Политика питания Remote machine power policy (Always Powered On, Suspend, Power Off) для пула
Привязка постоянных (Persistent) дисков
Несмотря на то, что персистентные диски не работают из коробки для связанных клонов, эту проблему можно решить с помощью продуктов Dynamic Environment Manger DEM , Microsoft FSLogix или VMware App Volumes Writable Volumes.
У компании VMware есть прекрасный документ "Understanding Clones in VMware vSphere 7", где описываются результаты тестирования производительности всех трех типов клонов. Очень интересный whitepaper, давайте взглянем на некоторые выводы в нем содержащиеся.
Первое - это скорость развертывания клонов и тестирование производительности под большой нагрузкой ввода-вывода:
Очевидно, что связанные и мгновенные клоны создаются намного быстрее полных ввиду своей природы. Мгновенные создаются несколько дольше связанных из-за того, что первым нужно время не только на настройку операций copy-on-write с диском, но и с памятью.
А вот правая часть картинки показывает нам, насколько падает производительность подсистемы ввода-вывода при тяжелых нагрузках - для связанных клонов больше, чем в три раза, а для мгновенных - аж в четыре (Hammer DB создает нагрузку еще и на память, которую должен обслуживать механизм мгновенных клонов).
Второй не менее интересный тест - с помощью методики SPECjbb. Тут брали не машины с хранилищем 450 ГБ и тяжелой нагрузкой по вводу-выводу, как в прошлом тесте, а легковесные машины с 16 ГБ диска и нагрузку делали на CPU и память. Результат получился таким:
Первый важный вывод - самое большое время на развертывание связанные и мгновенные клоны тратят в самом начале, уступая для маленьких машин полным клонам, но потом полные клоны долго завершают копирование данных виртуальных дисков.
Второй полезный инсайт - с точки зрения отработки запросов к CPU и памяти (а именно это и меряет SPECjbb) все три типа клонов ведут себя одинаково в пределах статистической погрешности в 5%.
Следующая картинка - влияние на родительскую ВМ. Очевидно, что для полных клонов влияния никакого нет, а вот для связанных и, тем более, мгновенных клонов влияние большое:
И, опять-таки, для памяти и CPU связанных и мгновенных клонов такого влияния практически нет.
Следующая картинка - развертывание полного клона по сети на другой хост ESXi. Для мгновенных клонов такая возможность отсутствует, а для связанных требуется общее хранилище. Мы тут видим, как сильно увеличивается время развертывания полного клона по сети:
При увеличении числа виртуальных машин совокупная производительность по вводу-выводу растет вот так:
При увеличении числа клонов картина для CPU/памяти вполне ожидаемая:
С точки зрения CPU все три вида клонов будут работать одинаково, а вот с точки зрения памяти - мгновенные клоны будут немного помедленнее, так как некоторое количество ресурсов тратится на обслуживание работы механизма работы с памятью.
Что касается времени развертывания разного количества для трех типов клонов, тут тоже все понятно: полные клоны растут линейно, остальные - несущественно.
Итоги
Давайте сведем теперь в простую таблицу все преимущества и недостатки полных, связанных и мгновенных клонов, чтобы это могло помочь вам выбрать нужную схему использования виртуальных ПК:
Преимущества
Недостатки
Full Clone
Быстродействие по вводу-выводу
Нет зависимости от родительской ВМ
Высокая надежность, нет единой точки отказа для нескольких ПК
Возможность удаленного клонирования на любой хост без общего хранилища
Долгое время развертывания и подготовки для пользователя
Отсутствие экономии пространства (каждый десктоп имеет полностью свое хранилище)
Нельзя использовать операции быстрого создания и уничтожения десктопа
Медленный накат обновлений (нужно обновлять каждый десктоп)
Linked Clone
Экономия дискового пространства за счет одной копии данных на чтение
Быстрое создание и уничтожение клона
Быстрый накат обновлений на реплику и обновление существующих и новых десктопов (Rebuild/Refresh)
Падение производительности хранилища из-за снапшотов/дельта-дисков и поиска данных при чтении и записи
Зависят от служб View Composer
Помечены как Deprecated, в будущих релизах будут отсутствовать
Instant Clone
Десктоп создается мгновенно и сразу готов к работе (клон от работающей машины)
Нет зависимости от служб Composer/vCenter
Быстрое обновление ОС
Экономия не только диска, но и памяти
Дополнительный уровень сложности и отказа - не только общий диск, но и память родительской ВМ
Низкая производительность хранилищ по вводу-выводу
Нельзя использовать некоторые возможности платформы
Нельзя использовать persistent-хранилища без дополнительного ПО
Как вы знаете, при обновлении виртуальной инфраструктуры в части хостов 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 выпустила обновленную версию продукта vRealize Orchestrator 8.3 (vRO), который входит в семейство решений vRealize и взаимодействует с такими продуктами, как vRealize Automation и vRealize Suite. Orchestrator предназначен для автоматизации большинства рутинных операций и рабочих процессов в облаке на базе VMware vSphere. О версии Orchestrator 8.1 мы, кстати, писали вот тут.
Давайте посмотрим, что нового VMware добавила в Orchestrator 8.3:
1. Роль Viewer
Теперь с помощью этой роли можно в режиме просмотра получить доступ к объектам и страницам Orchestrator. Пользователь с этой ролью не может создавать, редактировать или запускать рабочие процессы или оперировать с другими объектами, такими как действия, конфигурации, ресурсы, политики и запланированные задачи.
Роль показана в интерфейсе настройки ролей как Orchestrator Viewer:
Для такого пользователя будет доступно только действие Open с объектами:
Также режим просмотра будет и в Scripting Editor:
Эта роль может быть полезна для групп мониторинга и аудита.
2. Места использования и зависимости
Теперь в интерфейса можно узнать, где используется часть рабочего процесса и найти связи с другими элементами:
3. Улучшения юзабилити
Теперь табличные представления можно фильтровать по имени, типу и описанию в дата гридах:
После применения фильтра, можно отсортировать результаты по имени:
И после этого применить еще один фильтр, например, нам нужны только булевые переменные:
Параметр фильтра вписывается во всплывающем окошке прямо в гриде по клику на иконку:
4. Поддержка стандарта Federal Information Processing Standards (FIPS)
Orchestrator 8.3 содержит криптографические модули, которые прошли тестирование по программе NIST FIPS 140-2 Cryptographic Module Validation Program (CMVP). Этот режим (FIPS-mode) можно выбрать только при новой установке, в процессе эксплуатации поменять его на обычный будет нельзя.
Более подробно о новых возможностях VMware vRealize Orchestrator 8.3 рассказано тут и тут. Release notes находятся здесь. Скачать vRO 8.3 можно по этой ссылке.
Компания VMware на днях выпустила обновленную версию инфраструктуры VMware Cloud Foundation (VCF) версии 4.2. Напомним, что это комплексное программное решение, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager. О версии платформы VCF 4.1 мы писали вот тут.
Давайте посмотрим, что нового в VCF 4.2:
Поддержка vSAN HCI Mesh Support - теперь VCF поддерживает технологию HCI Mesh в кластерах vSAN, позволяющую использовать емкости удаленных кластеров.
Поддержка NSX-T Federation - теперь можно объединять несколько доменов рабочей нагрузки в одном представлении с помощью Global Manager.
Статические IP-пулы для сетей NSX-T Host Overlay (TEP) - их можно использовать как альтернативу DHCP.
Поддержка режима lockdown mode на хостах ESXi - их можно включать для доменов рабочей нагрузки через vCenter.
Разное: VCF 4.2 включает в себя проверки валидации паролей, оптимизации производительности API, а также улучшения сообщений об ошибках ESXi.
Интерфейс SDDC Manager включает в себя страницу Release Versions с информацией о новых возможностях продукта VCF, составе инфраструктуры и датах окончания поддержки.
В интерфейсе SDDC Manager и через API можно фильтровать бандлы обновлений по целевым релизам, чтобы удобнее было обновляться только на нужные версии.
Поддержка vRealize Automation для облачного аккаунта. Можно интегрировать SDDC Manager и домены рабочей нагрузки с VMware Cloud Assembly как облачными аккаунтами VCF (подробнее тут).
Поддержка сервисных виртуальных машин с использованием образов vSphere Lifecycle Manager (vLCM). Это позволяет развернуть NSX-T Guest Introspection (GI) и NSX-T Service Insertion (SI) в доменах рабочей нагрузки с использованием vLCM.
Обновлен список продуктов и их версий, входящих в инфраструктуру VCF (из главного - vRealize Suite 8.2, NSX-T 3.1 и последние версии vSphere и Horizon).
Полный список возможностей VMware Cloud Foundation 4.2 приведен в Release Notes. Есть также отдельный документ по версии для VxRail.
На днях компания VMware обновила свой главный документ, касающийся обеспечению безопасности виртуальных сред и самой платформы виртуализации - VMware vSphere 7 Security Configuration Guide. Напомним, что о его прошлой версии осенью прошлого года мы писали вот тут.
Давайте посмотрим, что появилось нового в обновленном SCG для vSphere 7, который традиционно состоит из PDF-файла описания и XLS-файла настроек, рекомендаций и пояснений:
Исправлены ошибки в рекомендациях PowerCLI для аудита виртуальных машин.
Добавлена вкладка "Deprecated" - там теперь будут те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).
Настройка svga.vgaOnly перемещена в Deprecated. Она ограничивает ВМ на использование только VGA-разрешений, а многие современные ОС этого очень не любят (могут даже отключить отображение картинки в этом случае).
Добавлены и обновлены рекомендации по отключению сервисных служб SLP и CIM на сервере ESXi. Эти протоколы часто не используются (их не используют и продукты VMware), поэтому лучше их отключить.
Добавлены рекомендации по изоляции сети. Раньше как-то само собой подразумевалось, что нужно разделять сети управления, vMotion и vSAN, теперь же это формализовано в документе. Там же рекомендовано и физическое разделение сетей.
Добавлена рекомендация по использованию только тех продуктов, старые версии которых еще официально поддерживаются со стороны VMware (например, вы можете выполнить все рекомендации и накатить все обновления, но использовать старый ESXi 5, что по понятным причинам небезопасно).
Добавлено руководство по использованию модулей Trusted Platform Modules 2.0 (TPM).
Снова возвращена рекомендация vm-7.pci-passthrough, касающаяся прямого доступа виртуальных машин к оборудованию, в частности шине PCIe.
Добавлено руководство по отключению интерфейсов DCLI, если вы не используете его на vCenter Server. Также вам не нужно держать SSH постоянно открытым, так как в vSphere широкий и защищенный API, который вы можете использовать в разных фреймворках и утилитах.
Скачать VMware vSphere 7 Security Configuration Guide (как и руководства для других версий vSphere) можно по этой ссылке. Подробнее о документе также можно почитать тут.
Многие администраторы VMware vSphere знают, что для организации кластеров Windows Server Failover Clusters (WSFC) нужен эксклюзивный доступ к LUN, а значит на уровне виртуальной инфраструктуры подходили только RDM-диски. Ранее эти кластеры назывались MSCS, мы писали об их организации в виртуальной среде вот тут.
Такая ситуация была из-за того, что WSFC использует механизм резервация SCSI-3 Persistent Reservations, который координирует доступ к общему дисковому ресурсы. С другой стороны, VMFS использует собственный механизм блокировки LUN, поэтому команды WSFC перехватываются и отменяются, если используются диски VMDK. Поэтому RDM-устройства и использовались как средство маппинга дисков виртуальных машин к физическому устройству LUN.
Оказывается, ситуация поменялась с выпуском VMware vSphere 7, где появился механизм Clustered VMDK. Он позволяет командам SCSI3-PR выполняться и применяться к виртуальному диску VMDK, поэтому вам не нужен отдельный LUN.
К сожалению, все это работает только на хранилищах Fibre Channel.
Чтобы это начать использовать, на уровне датастора надо установить параметр "Clustered VMDK Supported":
Далее нужно понимать следующие условия и ограничения:
Параметр кластера Windows Cluster "QuorumArbitrationTimeMax" должен быть выставлен в значение 60.
LUN за этим датастором должен поддерживать команды ATS SCSI (как правило, это всегда поддерживается).
LUN должен поддерживать резервации типа Write Exclusive All Resgistrants (WEAR).
VMDK-диски должны быть типа Eager Zeroed Thick и виртуальные машины должны быть как минимум в режиме совместимости с vSphere.
Не презентуйте LUN, которые используются как кластерные VMDK, для хостов ESXi версий ниже 7.0.
Не комбинируйте датасторы для clustered и non-clustered VMDK на одном общем кластерном хранилище.
Выделяйте один датастор на один кластер WSFC, не шарьте один датастор между несколькими инстансами кластеров WSFC.
Максимумы конфигураций для таких кластеров WSFC следующие:
Надо помнить еще о следующих ограничениях (более подробно тут):
Конфигурация Cluster in a Box (CIB) не поддерживается. То есть надо настроить правила anti-affinity DRS Rules, чтобы разделить узлы кластера / виртуальные машины по разным хостам ESXi. Если вы попробуете такую ВМ с помощью vMotion переместить, то миграция завершится неудачно.
Горячее расширение VMDK кластерной ВМ не поддерживается.
Не поддерживается Storage vMotion и снапшоты.
VMFS 5 и более ранние версии не поддерживаются.
Таги: VMware, vSphere, WSFC, MSCS, ESXi, VMDK, Storage, Microsoft
На сайте VMware Labs появился интересный инструмент Virtualized High Performance Computing Toolkit, который может оказаться полезен компаниям, использующим VMware vSphere для организации высокопроизводительных вычислений (High Performance Computing, HPC). Такие комплексные вычислительные задачи, как правило, вовлекают параллельные вычисления, аппаратное ускорение (такое как GPU и FPGA), а также используют высокоскоростные каналы, такие как RDMA.
Все это требует определенных конфигураций VMware vSphere, для настройки которых и нужно данное средство. С помощью него, используя vSphere API, можно дать администраторам инструменты по сопровождению задач HPC, таких как клонирование ВМ, настройка Latency Sensitivity, сайзинг виртуальных машин по CPU и памяти и многое другое.
Основные возможности тулкита:
Настройка устройств PCIe в режиме DirectPath I/O, таких как GPGPU, FPGA и RDMA
Простое создание и уничтожение кластеров HPC с помощью файлов конфигураций
Выполнение задач vSphere, таких как клонирование, настройка vCPU, памяти, резерваций, shares, Latency Sensitivity, обычного и распределенного виртуального коммутатора, сетевых адаптеров и конфигураций
Например, клонирование 4 виртуальных машин с заданными кастомизациями CPU и памяти, а также добавлением NVIDIA vGPU с профилем grid_p100-4q выглядит так:
Наш постоянный читатель Сергей обратил внимание на то, что на днях компания VMware выпустила обновление своего главного фреймворка для управления виртуальной инфраструктурой с помощью сценариев - PowerCLI 12.2. Напомним, что о прошлой версии PowerCLI 12.1 осенью прошлого года мы писали вот тут.
Давайте посмотрим, что нового появилось в обновленном PowerCLI 12.2:
1. Поддержка VMware Horizon
Модуль PowerCLI для управления инфраструктурой Horizon теперь поддерживается для macOS и Linux OS.
2. Инфраструктура VMware Cloud
Появилась поддержка одного из самых популярных сервисов для обеспечения катастрофоустойчивости датацентров - DRaaS. Новые командлеты позволяют включать/отключать DRaaS в виртуальном датацентре VMC SDDC, а также добавлять и удалять инстансы SRM (Site Recovery Manager).
Вот так выглядит включение DRaaS:
Управление инстансами SRM происходит с помощью командлетов:
Администраторы VMware vSphere в больших инфраструктурах иногда используют кластеры Windows Server Failover Clusters (WSFC) на базе RDM-дисков, которые доступны для хостов VMware ESXi. Ранее они назывались Microsoft Cluster Service (MSCS). При использовании таких кластеров время загрузки хоста ESXi может вырасти аж до целого часа, если не поставить этим LUN статус Perennially reserved.
Суть проблемы в том, что WSFC ставит SCSI-3 reservations для своих LUN, используемых активным узлом, и если ESXi видит эти тома (то есть они не отмаскированы для него), то он безуспешно пытается получить к ним доступ. Для этого он делает несколько попыток при загрузке, пока не решает перейти к следующим томам. Статус этих операций вы можете увидеть, если нажмете Alt+F12 при загрузке хоста:
Xavier Avrillier написал статью о том, как с помощью esxicli/PowerCLI пометить такие тома как Perennially reserved, чтобы ESXi пропускал их при сканировании (об этом также рассказано в KB 1016106).
Сначала вам надо узнать LUN canonical name устройства. Делается это следующей командой PowerCLI:
Многие администраторы в крупных инфраструктурах сталкиваются с проблемами назначения и обновления лицензий компонентов VMware vSphere - серверов ESXi и vCenter. Это можно сделать в графическом интерфейсе vSphere Client, но когда у вас много хостов, это становится муторным делом, во время которого легко ошибиться или просто устать:) Давайте посмотрим, как можно просто это делать через PowerCLI...
Иногда администратор VMware vSphere задается вопросом о происхождении виртуальной машины - из какой родительской ВМ/шаблона она была клонирована? Вильям Лам разбирает это в своей статье, приведем вкратце его метод определения происхождения ВМ.
Как вы знаете, бывает три типа клонирования виртуальных машин в VMware vSphere:
Full Clone - это полный клон, то есть независимая копия виртуальной машины, у которой нет ничего связанного с родительской ВМ, это просто ее полная копия.
Linked Clone - это копия виртуальной машины, которая имеет общие диски с родительской, доступные на чтение (это экономит пространство и позволяет просто откатываться к родительскому образу). Уникальные данные эта машина хранит в собственных дельта-дисках.
Instant Clone - это независимая копия виртуальной машины, которая начинает исполняться с какого-то момента и отделяется от основной машины. Для этого используются техники in-memory cloning и copy-on-write, которые используются также и для связанных клонов.
Чтобы найти источник клонированной машины, нужно проанализировать события vCenter Server Events. Вот какие они бывают касательно клонов:
VmClonedEvent - появляется, когда происходит создание Full Clone или Linked Clone.
com.vmware.vc.VmInstantClonedEvent - происходит при созданиии Instant Clone.
VmDeployedEvent - вызывается, когда виртуальная машина развертывается из шаблона (vSphere Template или Content Library Template).
На базе анализа этих трех событий в истории vCenter Вильям Лам создал PowerCLI-функцию Get-VMCloneInfo, с помощью которой можно узнать родителя для виртуальной машины, если она была клонирована.
Устанавливаем ее простой командой:
Install-Script VMCloneInfo
На входе эта функция принимает имя ВМ, которую мы хотим проанализировать. Такой вывод мы получим, если машина не была клонирована:
> Get-VMCloneInfo -VMName "SourceVM"
Unable to find any cloning information for SourceVM, VM may not have been cloned or vCenter Events have rolled over
Так будет выглядеть вывод по полному клону:
> Get-VMCloneInfo -VMName "Full-Clone-VM"
Type Source Date User
---- ------ ---- ----
Full SourceVM 1/3/2021 1:13:00 PM VSPHERE.LOCAL\Administrator
Так мы узнаем, что машина является связанным клоном:
> Get-VMCloneInfo -VMName "Linked-Clone-VM"
Type Source Date User
---- ------ ---- ----
Linked SourceVM 1/3/2021 1:13:14 PM VSPHERE.LOCAL\Administrator
Так - что Instant-клоном:
> Get-VMCloneInfo -VMName "Instant-Clone-VM"
Type Source Date User
---- ------ ---- ----
Instant SourceVM2 1/3/2021 1:12:44 PM VSPHERE.LOCAL\Administrator
Вот пример того, что машина была клонирована из шаблона vSphere Template:
> Get-VMCloneInfo -VMName "VMTX-VM"
Type Source Date User
---- ------ ---- ----
Full SourceVMTXTemplate 1/3/2021 2:20:31 PM VSPHERE.LOCAL\Administrator
А вот - что из шаблона Content Library VM Template:
> Get-VMCloneInfo -VMName "VMTemplate-VM"
Type Source Date User
---- ------ ---- ----
Full SourceVMTemplate 1/3/2021 2:23:41 PM VSPHERE.LOCAL\Administrator
Увеличена производительность при создании тэгов и категорий по сравнению с vSphere 6.7 U3.
Производительность вывода тэгов через API улучшилась по сравнению с vSphere 6.7 U3.
Теперь доступна паджинация вывода API, что позволяет упростить и ускорить получение данных.
Для иллюстрации улучшений на рисунке ниже приведена картина задержек (latency) при привязывании 15 тэгов к 5 000 виртуальным машинам в vSphere 6.7 U3 (где время линейно увеличивалось с ростом числа тэгов) и vSphere 7.0 Update 1, где время оставалось практически неизменным.
Скачать отчет VMware vSphere 7.0 U1 Tagging Best Practices можно по этой ссылке.
На сайте virten.net, как обычно, вышла замечательная статья о реальной боли некоторых администраторов VMware vSphere - уменьшении дисков vCenter Server Appliance (vCSA). Так как vCSA работает в виртуальной машине, то иногда возникает необходимость в уменьшении ее дисков в целях простоты перемещения и компактности хранения. Но основная ситуация, когда диски vCSA чрезмерно разрастаются - это апгрейд сервера vCenter - в этом случае его хранилище может увеличиться до 1 ТБ при реально занятом пространстве в 100 ГБ. Тут уже без шринка (shrink) не обойтись.
При апгрейде vCSA установщик смотрит на аллоцированное пространство, а не на занятое, поэтому исходная машина в 416 ГБ может быть преобразована только в целевую ВМ типа Small с 480 ГБ диска:
Метод, описанный ниже, стоит применять только для виртуального модуля vCSA, который вы планируете апгрейдить, поскольку меняется порядок его дисков. Это, в целом, не проблема, но могут возникнуть сложности при взаимодействии с поддержкой VMware, которая может посчитать эту конфигурацию неприемлемой.
Перво-наперво нужно сделать бэкап вашего vCSA или его клон, с которым вы и будете работать. Если что-то не получится, вы просто сможете удалить клон.
Итак, заходим на vCSA по SSH и останавливаем все службы:
# service-control --stop --all
Выбираем файловую систему, для которой будем делать shrink. Например, /storage/seat имеет размер 296 ГБ, но реально используется 67 МБ! Запоминаем файловую систему (/dev/mapper/seat_vg-seat) и точку монтирования хранилища (/storage/seat), которое будем уменьшать.
Также из файловой системы вы можете получить Volume Group (seat_vg) и Logical Volume (seat):
Когда миграция будет закончена, sdh должен остаться пустым (Allocated PE = 0 и нет физических сегментов, только FREE):
# pvdisplay -m /dev/sdh
--- Physical volume ---
PV Name /dev/sdh
VG Name seat_vg
PV Size 300.00 GiB / not usable 7.00 MiB
Allocatable yes
PE Size 8.00 MiB
Total PE 38399
Free PE 38399
Allocated PE 0
PV UUID V7lkDg-Fxyr-qX4x-d3oi-KhNO-XZyT-EHgibI
--- Physical Segments ---
Physical extent 0 to 38398:
FREE
Удаляем sdh из Volume Group:
# vgreduce seat_vg /dev/sdh
Удаляем LVM-метки из sdh:
# pvremove /dev/sdh
Запускаем скрипт autogrow.sh для расширения файловой системы к размеру виртуального диска:
/usr/lib/applmgmt/support/scripts/autogrow.sh
Последний шаг очень важен - удаляем старый диск. Не удалите не тот! Для этого проверяем SCSI ID с помощью lsscsi:
# lsscsi |grep sdh
[2:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh
Мы видим, что SCSI ID [2:0:8:0] нам нужно удалить. Помните, что номер диска не всегда совпадает с SCSI ID. Удалите правильный диск (в данном случае 8), не ошибитесь!
Это все, теперь можно перезагрузить виртуальную машину, после чего в качестве опции апгрейда будет доступен вариант апгрейда на Tiny:
Если вы хотите уменьшить другие разделы, то идентифицируйте соответствующие параметры Logical Volume, Volume Group и Virtual Disk, после чего повторите процедуру.
# lsscsi
[0:0:0:0] cd/dvd NECVMWar VMware IDE CDR00 1.00 /dev/sr0
[2:0:0:0] disk VMware Virtual disk 1.0 /dev/sda
[2:0:1:0] disk VMware Virtual disk 1.0 /dev/sdb
[2:0:2:0] disk VMware Virtual disk 1.0 /dev/sdc
[2:0:3:0] disk VMware Virtual disk 1.0 /dev/sdd
[2:0:4:0] disk VMware Virtual disk 1.0 /dev/sde
[2:0:5:0] disk VMware Virtual disk 1.0 /dev/sdf
[2:0:6:0] disk VMware Virtual disk 1.0 /dev/sdg
[2:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh
[2:0:9:0] disk VMware Virtual disk 1.0 /dev/sdi
[2:0:10:0] disk VMware Virtual disk 1.0 /dev/sdj
[2:0:11:0] disk VMware Virtual disk 1.0 /dev/sdk
[2:0:12:0] disk VMware Virtual disk 1.0 /dev/sdl
[2:0:13:0] disk VMware Virtual disk 1.0 /dev/sdm
Компания VMware опубликовала полезный 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, то как работает развертывание системного хранилища? Подробнее об этом вот тут
Это статья нашего спонсора - сервис-провайдера ИТ-ГРАД, предоставляющего в аренду виртуальные машины из облака по модели IaaS.
Виртуализация оборудования, также известная как серверная виртуализация, представляет собой абстракцию вычислительных ресурсов от программного обеспечения, которое использует эти ресурсы. В статье поговорим об истоках виртуализации и остановимся на ее аппаратной реализации.
В традиционной физической вычислительной среде ПО, такое как операционные системы или корпоративные приложения, имеет прямой доступ к базовому компьютерному оборудованию и компонентам, включая процессор, память, хранилище, некоторые чипсеты драйверы ОС. Ранее это создавало серьезные проблемы в настройке программного обеспечения, а также существенно затрудняло перемещение или переустановку приложений на другое оборудование — например при восстановлении из резервных копий после аварии.
Об истоках виртуализации
Термин «виртуализация» был придуман в конце 1960-х - начале 1970-х годов в ходе исследовательских проектов IBM и MIT в области совместного использования вычислительных ресурсов группами пользователей. Подробнее об этом вы можете почитать в нашем блоге на Хабре: [ССЫЛКИ на IBM/360 и истоки виртуализации].
В настоящее время виртуализация широко распространена в ИТ. В сфере облачных сервисов лидируют продукты компаний VMware, Microsoft, Citrix и Oracle.
Как работает аппаратная виртуализация
Процесс аппаратной виртуализации включает в себя установку гипервизора или диспетчера виртуальных машин (VMM). Именно они создают уровень абстракции между программным обеспечением и непосредственным «железом». После установки гипервизора программное обеспечение полагается на виртуальные представления вычислительных компонентов — то есть, к примеру, на виртуальные CPU вместо физических. К наиболее популярным гипервизорам можно отнести решения VMware vSphere на основе ESXi и Microsoft Hyper-V.
Виртуализированные вычислительные ресурсы объединяются в изолированные «группы», называемые виртуальными машинами (ВМ). На подготовленную ВМ можно установить операционную системы, а затем требуемые приложения. Виртуализированные системы могут иметь сразу несколько виртуальных машин одновременно, при этом каждая виртуальная машина логически изолирована от своих «соседей». Таким образом, если одна из ВМ подвергнется атаке вируса, будет перегружена или взломана, это никак не скажется на других машинах внутри системы.
Виртуализация позволяет бизнесу сократить издержки, связанные с приобретением серверного оборудования. К примеру, вместо покупки 10 разных серверов для размещения 10 приложений, каждому из которых для работы требуется отдельная ОС, достаточно построить виртуализированную систему, которая будет содержать требуемое количество ВМ, в рамках всего одного достаточно мощного сервера.
Поскольку гипервизор устанавливается непосредственно на сервер, а операционные системы и ПО добавляются позже, такой подход часто называют виртуализацией «на голом железе». В последние годы гипервизоры стали самостоятельными узко заточенными ОС. Есть и альтернативный подход, работающий в случае, если вы не можете/не желаете работать с «голым железом» — сперва устанавливается главная операционная система, а уже в ней разворачивается гипервизор и все ВМ. Этот метод часто называют виртуализацией с хост-системой. Сейчас он чаще всего используется для виртуализации контейнеров.
Типы аппаратной виртуализации
Существует несколько типов аппаратной виртуализации. Среди них — полная виртуализация, паравиртуализация и виртуализация с аппаратной поддержкой. Кратко поговорим о каждом из них.
Полная виртуализация полностью имитирует требуемое оборудование для гостевой операционной системы. В итоге получается среда, аналогичная ОС, работающей на отдельном сервере. Использование полной виртуализации позволяет администраторам запускать виртуальные среды любых конфигураций без каких-либо дополнительных аппаратных ухищрений.
Паравиртуализацией называется подход, при котором на ВМ запускается особым образом подготовленная (измененная и/или перекомпилированная) версия гостевой ОС. Иными словами, системные администраторы должны соблюдать исходные требования ОС к железу лишь частично.
Виртуализация с аппаратной поддержкой использует аппаратное обеспечение компьютера в качестве «архитектурной поддержки» для создания полностью виртуализированной ВМ и управления ею. Виртуализация с аппаратной поддержкой была впервые представлена ??IBM в 1972 году с IBM System / 370. Виртуализация с аппаратной поддержкой на сегодняшний день является наиболее распространенной формой виртуализации.
Технология виртуализации дала жизнь популярным сейчас облачным сервисам, таким как:
Интересно, что продукты VMware vSphere и VMware vSAN имеют разные списки совместимости оборудования (HCL - Hardware Compatibility Lists). Ronald de Jong в своем блоге описал ситуацию, когда у него драйвер SCSI-контроллера подошел для vSphere, но не подошел для vSAN.
После установки обновления драйвера для VMware vSphere через VMware Lifecycle Manager он получил вот такие ворнинги для vSAN в vSphere Client:
Драйвер smartpqi (70.4000.0.100-4vmw.701.0.0.17325551) уже подходит для vSphere, но еще не провалидирован для решения vSAN. В этом можно убедиться в списке совместимости для vSAN по этой ссылке, где есть только старый драйвер (3vmw):
Таким образом, нужно провести даунгрейд драйвера, чтобы он подходил и для vSphere, и для vSAN. Сначала идем на Patch Portal и находим там нужное обновление в виде VIB-пакета:
Вот этот драйвер:
После загрузки в консоли ESXi запускаем установщик VIB-пакета командой:
Некоторое время назад мы писали об улучшении технологии горячей миграции vMotion (тут и тут) в последней версии VMware vSphere 7 Update 1. Сегодня мы вкратце расскажем о вариантах переноса рабочих нагрузок в кластер хранилищ VMware vSAN на базе вот этой заметки.
Первое, что вы должны решить - это в каком рабочем процессе вы будете мигрировать виртуальные машины с помощью vMotion: за один шаг (хранилище+сервер) или за два (сначала сервер, потом хранилище).
1. Миграция в два шага (Two-Step Migrations)
При выборе миграции виртуальной машины у нас есть опция изменения либо сервера ESXi машины, либо ее хранилища, либо и того, и другого:
Change compute resource only - это первый шаг миграции для случая, когда не-vSAN хранилище может быть презентовано существующему кластеру vSAN. Также это может быть востребовано в рамках топологии VMware vSAN HCI Mesh, где хранилище монтируется удаленному кластеру vSAN.
Change storage only - это второй шаг миграции, когда машина на хосте ESXi уже находится в кластере vSAN, и мы выполняем перенос ее VMDK уже на собственные хранилища кластера.
Надо сказать, что миграция машин в два шага имеет бОльшую гранулярность, что позволит вам получить промежуточный результат и зафиксировать результат в середине (например, смигрированная на другой хост, но не хранилище машина), что может сэкономить время при повторной попытке миграции в случае каких-то проблем.
2. Миграция в один шаг
Этот способ миграции реализуется, когда вы выбираете опцию Change both compute resource and storage или Cross vCenter Server export. Надо понимать, что процесс этот весьма затратный, и выбирать этот вариант можно, когда у вас есть большой запас по ресурсам и времени для вычислительных ресурсов и ресурсов хранилищ. Ну или когда вы не можете расшарить хранилище между двумя разными кластерами vSphere / vSAN.
Удобство это способа еще и в том, что если у вас есть много времени на миграцию, то можно просто поставить vMotion для нужных нагрузок, и все будет постепенно переезжать без участия администратора.
Также для переноса нагрузок между разными инфраструктурами есть опция Cross vCenter Server export. В обновлении VMware vSphere 7 Update 1c главным нововведением стала интеграция функций миграции Advanced Cross vCenter Server vMotion Capability (ранее это был виртуальный модуль Cross vCenter Workload Migration Utility) в интерфейс vSphere Client. Оно же называется XVM.
Эта функциональность используется для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). При этом не требуется настроенного механизма Enhanced Linked Mode (ELM) или Hybrid Linked Mode (HLM) для серверов vCenter в разных датацентрах.
Если вы решили сделать пакетную миграцию виртуальных машин в vSphere Client, то нужно для кластера или пула ресурсов перейти на вкладку VMs и с шифтом выбрать группу ВМ для миграции, после чего из контекстного меню выбрать Migrate...:
Надо сказать, что машины одной группы можно мигрировать только в одинаковом состоянии (Powered on или Powered off), поэтому удобно отсортировать их по колонке State.
Ну и в заключение - картинка об улучшении технологии vMotion с момента ее появления в 2003 году:
На сайте проекта VMware Labs обновились четыре полезные утилиты, про которые мы уже не раз писали. Давайте посмотрим, что именно в них появилось нового:
1. VMware OS Optimization Tool билд b2001
Про прошлый апдейт этой утилиты мы писали вот тут. Напомним, что это средство предназначено для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач.
Что появилось нового:
Все записи оптимизаций снова добавили в шаблон main user template, теперь можно их тюнинговать вручную.
Исправлены два параметра аппаратных оптимизаций и ускорения, которые ранее настраивались в одной опции.
Во время фазы Optimize оптимизации экспортируются в файл json (%ProgramData%\VMware\OSOT\OptimizedTemplateData.json).
Во время фазы Analyze, если дефолтный файл json существует (то есть образ уже оптимизирован), то он импортируется и используется при выборе оптимизаций с прошлым выбором параметров. Также если выбор дефолтных состояний обязателен, то перед каждым запуском утилиты нужно удалять этот файл.
Файл OptimizedTemplateData.json можно использовать в командной строке с параметром -applyoptimization.
Улучшена работа с параметрами для служб Hyper-V, которые требуются для облачного сервиса Azure.
Скачать VMware OS Optimization Tool можно по этой ссылке.
2. vSphere Software Asset Management Tool версии 1.3
Напомним, что Software Asset Management Tool предназначен для сбора подробной информации об инсталляции VMware vSphere на вашей площадке, касающуюся лицензирования - инвентаря и доступности лицензий.
О прошлой версии этой утилиты мы писали вот тут, а вот что появилось нового в версии 1.3:
Отображение продуктов семейства Tanzu в генерируемых отчетах
Несколько исправлений ошибок
Скачать Software Asset Management Tool 1.3 можно по этой ссылке.
3. DRS Dump Insight версии 2.0
Напомним, что о прошлой версии Dump Insight 1.1 мы писали здесь. Это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS.
Давайте посмотрим, что появилось нового:
Добавлена поддержка дампов vSphere 7.0 и 7.0 Update 1
Доступен выбор нескольких отдельных дампов для анализа из общего списка
Об этой утилите мы писали вот тут. Она позволяет показывать различную информацию об оконечных устройствах на рабочих станциях (Certificate Management, Application Deployment, Profile Management).
Что появилось нового:
Обновлена иконка приложения
Появился мониторинг компонентов VMware Horizon Client, VMware Digital Experience Telemetry и VMware Hub Health services
Скачать Workspace ONE Discovery 1.1 можно по этой ссылке.
RSS
