Дункан Эппинг написал интересную статью про обслуживание межсайтового соединения (ISL) растянутого кластера VMware vSAN. Обычно, если условия позволяют, можно потушить все рабочие нагрузки (ВМ) на обеих площадках, после чего можно выключить кластеры и проводить обслуживание сетевого линка между площадками. Эта процедура описана в KB 2142676.
Но что делать в случае, когда вам нужно, чтобы рабочие нагрузки на одной из площадок продолжили выполняться во время обслуживания ISL?
Этот механизм и можно использовать для обслуживания ISL-соединения. Итак, переводим все хосты кластера на сайте 1 в режим обслуживания (Maintenance Mode) или выключаем их. В этом случае в растянутом кластере голоса для компонента Witness будут пересчитаны в течение 3 минут. После этого можно выключить и сам Witness - и это не приведет к падению виртуальных машин на сайте 2.
Итак, как он это проверял. Сначала перевел все хосты сайта 1 в режим обслуживания - и все его виртуальные машины начали переезд на второй сайт.
Затем он проверил RVC-консоль (как мы писали выше) и дождался, пока за пару минут будут пересчитаны голоса. Далее он просто выключил компонент Witness, после чего он убедился, что все ВМ продолжили нормально работать на второй площадке:
После этого можно начинать обслуживание ISL-соединения и работы по улучшению межкластерного соединения.
Для верности можно выполнить команду vsan.vm_object_info в консоли RVC и проверить объекты/экземпляры виртуальных машин на предмет того, что они находятся в статусе "ACTIVE" вместо "ABSENT":
После завершения обслуживания ISL-линка, вы можете включить компонент Witness, после чего включаете обратно хосты сайта 1 и обязательно выполняете ресинхронизацию (resync). После этого механизм VMware DRS в автоматическом режиме сам сбалансирует нагрузки по площадкам, распределив их по ним с помощью vMotion.
На этой неделе компания VMware выпустила небольшое обновление VMware Cloud Director 10.5.1, решения для управления программно-определяемым датацентром сервис-провайдеров, в котором появилось несколько новых возможностей, повышающих удобство администраторов облачной инфраструктуры vSphere.
Давайте посмотрим на новые возможности VCD 10.5.1:
1. Сетевая инфраструктура
В этом релизе было представлено несколько сетевых функций, как новых, так и улучшений существующих, особенно ориентированных на шлюз провайдера, Edge-шлюз и основную сетевую инфраструктуру VCD. Все это направлено на повышение общей функциональности сети, где предлагается множество настраиваемых опций. Эти обновления обещают значительно расширить сетевые возможности, обеспечивая более надежную и универсальную среду для конфигурации и управления. С этими функциями пользователи могут ожидать более продвинутого и эффективного опыта работы с сетью, получая возможность адаптировать конфигурации сети для удовлетворения специфических потребностей и оптимизации производительности.
2. Ядро платформы
В этом обновлении были внесены значительные улучшения в основные функции продукта в части использования и настройки различных функций. Эти нововведения направлены на улучшение опыта работы администраторов провайдеров, администраторов организаций и пользователей VCD в рамках их повседневных операций. Сосредоточив внимание на повышении удобства использования и конфигурируемости, эти обновления обещают оптимизировать ежедневные действия, предлагая более интуитивный и эффективный рабочий процесс. С этими улучшениями пользователи могут ожидать более плавного и удобного опыта работы при выполнении своих обычных задач в рамках платформы.
3. Расширения VMware Cloud Director
Расширения VCD играли ключевую роль в адаптации к разнообразным технологиям и обеспечения бесшовной интеграции решений. В этом релизе появились возможности, которые могут быть предложены как услуги для партнеров VMware. Не только появились новые функции, но и существующие варианты расширяемости также были улучшены для бесшовной интеграции с VCD. Эти улучшения обеспечивают большую совместимость и предоставляют расширенные функции и поддержку, способствуя созданию более надежной и универсальной экосистемы партнеров VMware и пользователей. Этот выпуск направлен на предоставление партнерам передовых возможностей при одновременном улучшении общей масштабируемости для удовлетворения расширяющихся технологических требований.
Полный технический обзор новых возможностей VMware Cloud Director 10.5.1 можно скачать по этой ссылке.
Напомним, что в конце прошлого года в решении vSAN 8 появилась новая архитектура гиперконвергентной инфраструктуры Express Storage Architecture (ESA). Она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.
С помощью флэш-памяти TLC на основе технологии NVMe, архитектура ESA имеет множество преимуществ со стандартной vSAN Original Storage Architecture (OSA), которая также продолжит поддерживаться для стандартного на текущий момент оборудования (устройства SATA/SAS).
Посмотрим на некоторые полезные скриншоты из видео. Улучшения производительности на уровне отдельного VMDK (RAID-6 ESA работает лучше, чем RAID-1 OSA):
Результаты теста SPEC - время отклика при увеличении числа операций в секунду:
Зависимость задержек (latency) от числа снапшотов на хранилище:
Большинство администраторов уже знакомы с новой функциональностью, которая доступна в новой версии платформы виртуализации VMware vSphere 8 Update 2, о которой было объявлено в рамках конференции VMware Explore 2023. Сегодня мы поговорим об улучшених подсистемы работы с хранилищами (Core Storage).
vSphere 8 U2 содержит ряд важных нововведений, и область хранения данных не является исключением. Как вы, вероятно, заметили, VMware в последнее время делает акцент на технологиях vSAN, vVols и NVMeoF, и в этом году особое внимание уделяется vVols. В vSphere 8 было много важных усовершенствований. Например, новые спецификации VASA для vVols, улучшенная производительность и надежность, расширенное управление сертификатами и поддержка NVMeoF - и это лишь некоторые из них.
Хотя в vSphere 8 Update 2 и нет большого количества новых функций хранения, тем не менее, имеются некоторые важные обновления. vVols, NVMeoF, VMFS и NFS получили улучшения и функции, которые оценят многие администраторы.
Улучшения vVols
Расширение Online Shared Disks для vVols
В релизе vSphere 6.7 была добавлена поддержка постоянных резерваций SCSI3-Persistent Reservations для vVols. Эта функция позволяет приложениям для кластеризации контролировать блокировку общих дисков. Примером приложения, требующего SCSI3-PR для общих дисков в кластере, является Microsoft WSFC.
Однако одной из последних функций, которые были у RDM, но не у vVols, была возможность расширять общий диск в онлайн-режиме в некоторых приложениях, таких как Microsoft WSFC. Теперь же и vVols поддерживает горячее расширение общих дисков с использованием постоянных резерваций SCSI3. Это позволяет расширять общие диски без необходимости выключать кластер приложений. Теперь у RDM нет преимуществ перед vVols. Администраторы могут мигрировать свои приложения MS WSFC на vVols и избавиться от RDM. Это значительно упрощает управление виртуальным хранилищем, снижает сложность и при этом сохраняет функции, основанные на массивах.
Кликните на картинку для просмотра анимации этого процесса:
Поддержка онлайн-расширения диска vVols с Oracle RAC
В этом релизе, помимо MS WSFC, была добавлена поддержка горячего расширения и для дисков Oracle RAC с использованием режима Multi-Writer. Для расширения кластерных дисков теперь не требуется простоя. Это можно выполнять как на дисках SCSI, так и NVMe vVols. Это также позволяет клиентам мигрировать с томов RDM.
In-band миграция томов vVols
Теперь доступна поддержка миграции пространств имен NVMe vVol внутри групп ANA. Эта функциональность обеспечивает эквивалентность примитиву перепривязки SCSI и позволяет администратору хранилища балансировать нагрузку ввода-вывода по объектам Protocol Endpoint (PE).
Автоматическое восстановление из состояния PDL для PE vVol
Ранее, когда PE переходил в состояние PDL и затем возвращался, стек PSA должен был перезапустить устройство (уничтожить и снова обнаружить пути). Это могло произойти только после закрытия объектов vVol, использующих PE. В этом релизе, ВМ будут автоматически завершены в случаях, когда мы обнаруживаем, что PE, к которому привязаны vVols ВМ, находится в PDL. Это дополнительно повышает устойчивость и восстановление при определенных типах сбоев подсистемы хранения.
Поддержка 3rd party MPP для NVMe vVols
Позволяет MPP (политике многопутевого доступа) от сторонних разработчиков поддерживать NVMe vVols. Это дает возможность партнерам VMware использовать свою клиентскую политику MPP.
Поддержка UNMAP для конфигурационного vVol
Начиная с vSphere 8.0 U1, конфигурационные vVols теперь создаются как тонкие диски с максимальным размером 255 ГБ и форматируются с использованием VMFS-6. В этом релизе есть поддержка esxcli для выполнения процедуры unmap для конфигурационных vVols.
Улучшения NVMeoF
Поддержка типа контроллера vNVMe для MS WSFC
В vSphere 7 был добавлен новый контроллер виртуальных машин - vNVMe, но изначально он не поддерживался для использования с WSFC. В vSphere 8 была добавлена поддержка кластеризованных приложений на хранилищах данных NVMeoF. В vSphere 8 U2 техническая команда VMware сертифицировала контроллер vNVMe для использования с Microsoft WSFC. Теперь вы можете использовать NVMe с полной поддержкой для приложений WSFC. Изначально это поддерживается только с SCSI vVols.
Поддержка кластеризации Oracle RAC с vVols NVMe (FC, TCP)
Была добавлена поддержка кластеризованных дисков Oracle RAC vVol, размещаемых на бэкенде NVMe. Это включает NVMe-FC vVols и NVMe-TCP vVols.
Включение поддержки vNVMe с Oracle RAC (vVols)
Была добавлена поддержка использования контроллера vNVMe в качестве фронтенда для кластеризации в режиме multi-writer (Oracle RAC).
Улучшения VMFS
Улучшена производительность офлайн-консолидации снапшотов SE Sparse.
Производительность офлайн-консолидации снапшотов SE Sparse в этом релизе улучшена в несколько раз. Это помогает улучшить RPO и RTO для клиентов, использующих офлайн-консолидацию для целей восстановления после сбоев (DR).
Улучшения NFS
Кэш DNLC для NFS4.1
В некоторых средах, использующих NFS4.1, имеются большие хранилища данных с сотнями ВМ, где поиск, включение или вывод списка ВМ могут быть медленнее, чем в NFSv3. Кэш поиска имен каталогов (DNLC) предназначен для уменьшения количества операций NFS LOOKUP за счет кэширования некоторых этих данных. В этом релизе была добавлена поддержка DNLC для NFS4.1. Это принесет пользу операциям, таким как "ls" в каталоге с большим количеством ВМ или файлов в хранилище данных.
nConnect
В vSphere 8.0 U1 появилась поддержка nConnect, которая позволяет добавлять несколько соединений к хранилищу данных NFSv3. Это может помочь снизить задержку и увеличить производительность. В Update 2 появилась поддержка динамического увеличения и уменьшения количества соединений, используемых с nConnect. В настоящее время это настраивается только через esxcli.
При использовании VMware SDDC Manager иногда вам нужно перезапустить неудачно выполненную задачу. Для этого вам просто нужно нажать кнопку "Retry Task" в панели задач. Однако иногда вам нужно изменить входные данные для этой задачи, например, у вас есть опечатка в IP-адресе. Также материалы этой статьи помогут вам понять глубже о том, как устроено исполнение задач в SDDC Manager.
Для начала вам нужно включить доступ к SDDC Manager по API, который, начиная с VCF 5.0, отключен по умолчанию по соображениям безопасности. Вам необходимо его включить, чтобы иметь возможность использовать команду curl.
Войдите в консоль виртуального модуля SDDC Manager по SSH с учетной записью "vcf" и переключитесь на "root‘, используя команду su -
Откройте файл application-prod.conf, который находится в директории /etc/vmware/vcf/domainmanager/
Добавьте следующую строку в конец файла: vcf.vault.http-access=true
Сохраните файл
Перезапустите службу доменного менеджера следующей командой: # systemctl restart domainmanager и подождите несколько минут
Далее переходим к редактированию самой задачи:
1. Войдите в пользовательский интерфейс SDDC Manager, перейдите к неудачно выполненной задаче и скопируйте ID задачи из URL. Смотрите пример на скриншоте ниже. Убедитесь, что вы не скопировали скобку в конце URL.
2. Затем войдите в SDDC Manager по SSH и переключитесь на пользователя "root", используя команду su -.
3. Чтобы изменить параметры входных данных задачи, вам нужно получить спецификацию задачи, выполнив следующую команду:
Для TASK_ID используйте ID, который вы скопировали в самом начале
Для FILENAME выберите имя нового файла, который будет содержать спецификацию JSON для задачи
4. Откройте JSON-файл в папке tmp в текстовом редакторе, внесите необходимые корректировки (например, поменяйте IP-адрес) и сохраните его.
5. Перезапустите задачу с измененным JSON-файлом, используя следующую команду:
# curl -H 'Content-Type:text/plain' -X PUT http://localhost/domainmanager/internal/vault/<TASK_ID> -d @/tmp/<MODIFIED_JSON_FILE>.json
Для ‘TASK_ID‘ используйте тот же ваш ID, а для MODIFIED_JSON_FILE - имя файла, который вы создали.
6. Вернитесь в пользовательский интерфейс SDDC Manager и перезапустите неудачно выполненную задачу, нажав кнопку "Retry Task". Теперь задача должна перезапуститься с новыми значениями.
Не забудьте изменить свойства файла application-prod.conf обратно на исходные, удалив строку vcf.vault.http-access=true и перезапустив службу domainmanager в SDDC Manager.
Недавно компания VMware обновила решение Cloud Director Availability 4.7, которое предназначено для создания резервной инфраструктуры в одном из публичных облаков на основе VMware Cloud Director (так называемая услуга Disaster-Recovery-as-a-Service, DRaaS). Напомним, что о прошлой версии этого продукта мы писали вот тут.
Новый механизм репликации
До настоящего момента VMware Cloud Director Availability использовал независимые (independent) диски при репликации рабочих нагрузок в облака Cloud Director. Однако это не является их изначальным назначением, что может оказать отрицательное влияние на механику репликации в определенных случаях.
Для уменьшения действия этого фактора и дальнейшего улучшения стабильности и оперативности, а также для обеспечения возможности будущих улучшений, введена система отслеживания репликации Replication Tracking VM (RT VM). Она позволяет использовать новый способ репликации виртуальных машин, совместимый с продуктом Cloud Director Availability 4.7, который зарегистрирован в Cloud Director 10.5+.
Запущенные репликации не будут затронуты этим изменением после обновления VMware Cloud Director Availability. Существует опция для их миграции с независимых дисков на RT VM через пользовательский интерфейс VMware Cloud Director Availability.
Все новые репликации будут использовать этот новый механизм размещения.
Выбор политики хранения
VMware Cloud Director Availability 4.7 получил две новые функции, связанные с выбором политики хранения:
Выбор политики хранения для каждого диска
Переназначение политики хранения во время восстановления рабочей нагрузки
Выбор политики для каждого диска
В предыдущих версиях VMware Cloud Director Availability при выборе политики для репликации применялись одни и те же настройки для всех ее дисков. В версии 4.7 вы теперь можете указать политику для каждого диска, сохраняя при этом остальные функции, такие как исключение диска или использование Seed VM.
Эта функция доступна как для облаков Cloud Director, так и для vSphere с одним отличием - для облаков vSphere вы можете выбрать политику хранения и хранилище размещения для каждого диска.
При использовании seed VM репликация будет использовать ее настройки хранилища, и вы не сможете их указать.
Переназначение политики во время восстановления рабочей нагрузки
С учетом оптимизации затрат часто принято использовать медленное, но более дешевое хранилище для данных. Это актуально и для репликаций, где с течением времени может накапливаться большой объем данных.
Однако скорость хранилища может негативно сказаться на производительности рабочей нагрузки при ее переключении в случае сбоя. Чтобы сэкономить клиентам сложный выбор того, где именно пойти на уступки, VMware Cloud Director Availability 4.7 позволяет использовать конкретные настройки хранилища при начальной настройке репликации, а затем выбрать другие настройки при восстановлении реплик.
Эта новая функция доступна как для облаков vSphere, так и для облаков Cloud Director.
Предварительная проверка выполнения планов восстановления
При использовании планов восстановления довольно неприятно достичь определенного этапа их выполнения и обнаружить, что некоторые настройки репликации не настроены, что приводит к неудачному завершению плана. Предварительная проверка выполнения планов восстановления убирает это неудобство и уменьшает время, затрачиваемое на проверку обязательных конфигураций, необходимых Cloud Director Availability для завершения репликации или набора репликаций.
Эти проверки учитывают значительные изменения в инфраструктуре облака, проверяют настройки размещения и наличие недостающих настроек восстановления, а также доступность исходного сайта для случаев миграции.
Эта информация доступна в новой вкладке "Health", которая присутствует в каждом плане восстановления при его выборе. Там вы можете увидеть, когда была проведена последняя проверка, а также доступные действия для устранения обнаруженной проблемы.
Механизм vSphere DR и поддержка миграций Seed VM
В рамках улучшений по обеспечению равенства функций для точек назначения vSphere и Cloud Director, теперь можно выбрать начальную виртуальную машину (Seed VM) при репликации рабочих нагрузок в облака vSphere.
Улучшения для облаков VMware Cloud Director
Появилось несколько новых функций, которые решают проблемы для поставщиков облачных услуг и их клиентов, которые реплицируют рабочие нагрузки в облака назначения Cloud Director:
Передача меток безопасности NSX, связанных с реплицированной виртуальной машиной при инициировании миграции/восстановления между двумя облаками, работающими на VMware Cloud Director 10.3+.
Автовыбор политики сайзинга при cloud-to-cloud - если виртуальной машине назначена политика сайзинга на исходном сайте, и на назначенном сайте существует политика с таким же именем, она будет автоматически выбрана при настройке репликации.
Управление видимостью удаленных облачных сайтов - поставщики облачных услуг могут контролировать, какие партнерские сайты будут видны для каких организаций. Если сайт, на котором активны репликации, скрыт, они будут продолжать отображаться в пользовательском интерфейсе, но невозможно будет создавать новые репликации в/из скрытого сайта.
Управление политиками для направлений репликации - доступные средства управления расширяются еще одной новой опцией для поддержания возможного направления операций репликации для клиента облака. С ее помощью поставщики облачных услуг могут ограничить клиентов в защите рабочих нагрузок, работающих в облаке, только в направлении их собственного датацентра.
Более подробную информацию о VMware Cloud Director Availability 4.7 можно получить по этой ссылке.
Таги: VMware, vSphere, Cloud, Availability, Director, Update, DR
В этом выпуске было объявлено о расширении плагин-ориентированного фреймворка для поддержки облачных ресурсов Azure в рамках шаблонов Aria Automation Templates для развертывания вычислительных мощностей, сетей, дисков, storage-аккаунтов и ресурсов баз данных SQL Azure. Использование элементов шаблонов на основе плагинов позволяет клиентам легко получать доступ к ресурсам публичного облака и их свойствам в точном соответствии с определениями вендора.
В этом релизе Aria Automation поддерживает все три крупнейших облачных провайдера: AWS, GCP и Azure. VMware планирует продолжать поддерживать больше типов ресурсов на основе плагинов в будущих ежемесячных релизах.
Еще одной важной функцией является VMware Aria Automation for Secure Hosts, которая теперь предоставляет действия по предварительному и пост-устранению уязвимостей.
Пользователи теперь могут использовать файлы состояний Salt в файловом менеджере, чтобы указать предварительное состояние перед началом исправления уязвимостей. Кроме того, можно установить необязательное пост-состояние для действий после завершения ремедиации. Это улучшение экономит время администраторам ИТ, автоматизируя задачи по предварительной и пост-ремедиации.
Помимо отмеченных выше новых функций, появились следующие улучшения пользовательского опыта в VMware Aria Automation:
1. Дополнительное предупреждение для Day-2 действия Resize
Теперь действие изменения размера дополнено предупреждением о том, что если функция Hot Add не включена в vCenter, машина будет перезагружена и не будет работать в это время. Когда горячее добавление включено, пользователи могут выбрать, перезагружать ли машину или нет при изменении, причем "не перезагружать" установлено по умолчанию.
2. Поддержка онпремизного SCM (GitLab Enterprise) в VMware Aria Automation SaaS
Эта функция позволяет администраторам настроить GitLab Enterprise как эндпоинт для репозитория. Шаблоны VMware Aria Automation, скрипты Terraform и сервисы ABX могут быть импортированы из GitLab Enterprise. Это расширение сервиса VMware Aria Automation SaaS клиенты могут использовать как в локальных, так и в SaaS-средах.
Теперь поддерживается указание свойств для пакетов OVF/OVA, хранящихся в библиотеке содержимого vCenter, в шаблонах VMware Aria Automation с использованием свойства 'ovfProperties:', доступного в элементе vSphere Machine. Шаблоны OVF/OVA, созданные в кластере vSphere или хранящиеся в библиотеке содержимого vCenter, отображаются в сопоставлениях образов в VMware Aria Automation Assembler.
4. Улучшения плагина Infoblox IPAM
Версия 1.5.1 плагина VMware Infoblox для VMware Aria Automation вносит несколько улучшений, таких как повышение удобства использования, устранение false positives и повышение безопасности за счет использования OpenSSL 3.0.x, Photon 4.x и Python 3.10.11 в качестве среды выполнения ABX. Подробнее об этом тут.
Более подробно о новых возможностях VMware Aria Automation November 2023 вы можете узнать из Release Notes.
Недавно компания VMware выпустила интересное видео, рассказывающее о новой функциональности этой платформы:
Ролик будет полезен всем облачным администраторам, которые следят за новостями о главном средстве обновления компонентов виртуальной инфраструктуры VMware vSphere.
Таги: VMware, vSphere, vLCM, Lifecycle, Update, Video
Администраторы платформы виртуализации VMware vSphere в рамках ежедневной рутины занимаются процессами обновлений виртуальной инфраструктуры и ее компонентов путем накатывания патчей или проведения апгрейдов (в том числе наиболее сложных - на новые мажорные версии). Наиболее удобный способ делать это - использовать решение vSphere Lifecycle Manager (vLCM), который автоматизирует этот процесс. Это следующее поколение продукта vSphere Update Manager (VUM), который ранее использовался для планирования и накатывания обновлений...
Распределенная архитектура vSAN всегда была естественным решением для множества топологий, таких как растянутые кластеры, 2-узловые кластеры и кластеры, использующие домены отказа (fault domains). Но что насчет vSAN Max? Давайте рассмотрим, как vSAN Max может помочь обеспечить централизованное общее хранилище для ваших кластеров vSphere, используя эти альтернативные топологии.
Гибкость распределенного объектного хранилища
Кластер vSAN HCI объединяет вычислительные ресурсы и хранилища на одних и тех же хостах, которые составляют кластер, что обеспечивает простой и мощный способ создания растянутого кластера. Просто разместите хосты vSAN в кластере на двух географических площадках вместе с виртуальным хостом Witness на третьем сайте и настройте кластер как растянутый (stretched). И вычислительные ресурсы, и хранилища распределены по площадкам в единой, согласованной манере, что обеспечивает доступность экземпляров виртуальных машин и их данных в случае частичного или полного сбоя сайта.
Хост Witness не показан ниже для ясности на всех иллюстрациях растянутых кластеров в этом посте.
Рисунок 1. Отказоустойчивость на уровне сайта для виртуальных машин в растянутом кластере vSAN HCI, охватывающем два центра обработки данных.
Данные хранятся отказоустойчиво на разных площадках, что означает наличие двух путей от вычислительных ресурсов к данным. Поскольку вычислительные ресурсы и хранилища объединяются на одних и тех же хостах, которые составляют кластер vSAN, изначально существует архитектура высокой доступности для обоих типов ресурсов и предпочтительного пути данных, что является одной из причин, по которой растянутый кластер vSAN HCI может автоматически учитывать сценарии сбоев и другие стрессовые условия.
Растянутые топологии, использующие разделенные хранилища и вычислительные ресурсы
Концептуально растянутая топология подразумевает, что данные избыточно хранятся в двух определенных доменах отказоустойчивости – обычно (но не всегда) на двух географически разнесенных площадках. Это предположение должно учитываться в такого рода среде при рассмотрении топологий.
Когда вычислительные ресурсы и хранилища отделены друг от друга, они должны понимать характеристики двух сетевых путей от вычислительных ресурсов к избыточным данным. В большинстве случаев один из сетевых путей (межсайтовая связь или ISL) будет медленнее другого. Это называется асимметричной сетевой топологией, как показано на Рисунке 2. Хотя это наиболее распространенная конфигурация для растянутого кластера, она представляет интересную задачу, потому что система должна правильно выбрать оптимальный сетевой путь вместо менее быстрого для лучшей производительности.
Рисунок 2. Асимметричные сетевые топологии для растянутых сред.
Гораздо менее распространенная симметричная сетевая топология показана на рисунке 3. Это представляет собой топологию, где пропускная способность и задержка остаются одинаковыми независимо от выбранного пути данных для выполнения запроса. Такую ситуацию можно увидеть, когда два домена отказа или "сайта", как их определяют, представляют собой просто стойки серверов, расположенные рядом друг с другом и использующие одно и то же сетевое оборудование, что обеспечивает задержку менее 1 мс между клиентским кластером и серверным кластером внутри одного домена отказа или между доменами.
Рисунок 3. Симметричные сетевые топологии для растянутых сред.
Чтобы помочь vSAN Max понять правильный сетевой путь в топологии растянутого кластера, мастер настройки vSAN Max позволит вам выбрать сетевую топологию, соответствующую вашей среде.
vSAN Max, растянутый между географическими сайтами
Кластер vSAN Max может быть настроен как кластер одного сайта или в растянутой конфигурации. vSAN Max может обеспечивать устойчивость данных на уровне сайта, зеркалируя данные между сайтами, и вторичные уровни отказоустойчивости с помощью эффективного для экономии места схемы хранения RAID-6 erasure coding в пределах каждого сайта. Это
обеспечивает высокий уровень отказоустойчивости эффективным способом и гарантирует, что восстановление данных будет выполнено локально в случае отдельного сбоя хоста в пределах сайта.
Рисунок 4 иллюстрирует растянутый кластер vSAN HCI, который подключает хранилище кластера vSAN Max, также растянутого. В этом типе асимметричной конфигурации кластер vSAN HCI и кластер vSAN Max будут поддерживать наибольшую близость сайтов обработки ввода-вывода и данных между клиентским и серверным кластерами.
Рисунок 4. Растянутый кластер vSAN Max обеспечивает устойчивое хранение данных на двух сайтах обработки данных для кластера vSAN HCI, который также является растянутым.
Поддерживаемые клиентские кластеры при использовании vSAN Max в растянутой топологии
Следующая таблица резюмирует типы клиентских кластеров, поддерживаемых при использовании кластера vSAN Max в конфигурации растянутого кластера. Предполагается, что требование к задержке в 1 мс или меньше между клиентским кластером и кластером vSAN Max выполнено, и предполагается, что все клиентские кластеры используют vSphere 8.
Тип клиентского кластера
Тип серверного кластера
Поддерживается?
Заметки
Кластер vSAN HCI (ESA) в конфигурации stretched cluster
Кластер vSAN Max или vSAN HCI (ESA) в конфигурации растянутого кластера
Да
Предоставляет высокую доступность для данных и запущенных виртуальных машин
Кластер vSAN HCI (ESA), когда он находится на одном из сайтов данных, где находится кластер vSAN Max.
Кластер vSAN Max или vSAN HCI (ESA) в конфигурации растянутого кластера
Да
Предоставляет высокую доступность для данных и запущенных виртуальных машин
Растянутый кластер vSphere между двумя сайтами с ассиметричным сетевым соединением
Кластер vSAN Max или vSAN HCI (ESA) в конфигурации растянутого кластера
Нет
Пока не поддерживается
Растянутый кластер vSphere между двумя сайтами с симметричным сетевым соединением
Кластер vSAN Max или vSAN HCI (ESA) в конфигурации растянутого кластера
Да
Поддерживается, встречается редко, так как требуется аналогичные параметры bandwidth и latency между доменами отказа, как и внутри домена
Кластеры vSphere, когда они находятся на одном из сайтов данных, там же, где и кластер vSAN Max
Кластер vSAN Max или vSAN HCI (ESA) в конфигурации растянутого кластера
Да
Предоставляет высокую доступность для данных, но НЕ для запущенных виртуальных машин
Любой клиентский кластер архитектуры vSAN OSA
vSAN Max cluster or vSAN HCI cluster (ESA) в режиме одного сайта или в конфигурации растянутого кластера
Нет
Пока не поддерживается
Как отмечено выше, когда кластер vSAN Max настроен как растянутый с использованием асимметричной сетевой топологии, кластер vSphere, подключающий хранилище данных vSAN Max и растянутый на тех же двух сайтах - в настоящее время не поддерживается. Если требуется отказоустойчивость данных и экземпляров виртуальных машин на уровне сайта, кластер vSAN HCI в качестве клиентского кластера в растянутой конфигурации может быть лучшим вариантом на данный момент. Это обеспечит высокую доступность экземпляров виртуальных машин и обслуживаемых ими данных.
При использовании в конфигурации растянутого кластера кластеры vSAN Max будут иметь те же требования к пропускной способности и задержке сети между сайтами, что и традиционные кластеры vSAN HCI того же размера. Смотрите руководство по размерам пропускной способности растянутых кластеров vSAN для получения дополнительной информации.
Рекомендация. Размер вашей межсайтовой связи (ISL) должен быть основан на требованиях вашей рабочей нагрузки. Учитывая, что кластер vSAN Max может предложить высокопроизводительное хранилище, убедитесь, что ISL может обеспечить необходимую пропускную способность и задержку для ваших рабочих нагрузок. Это означает, что ваша среда может потребовать более 10 Гбит/с пропускной способности, указанной как минимально необходимая для этого типа топологии.
vSAN Max с использованием функции доменов отказа vSAN
vSAN Max также может быть настроен с использованием функции Fault Domains, которая чаще всего используется для обеспечения отказоустойчивости на уровне стоек для больших кластеров. Функция доменов отказа стала гораздо более эффективной с ESA, и поскольку vSAN Max построен на этой архитектуре, он обеспечивает все улучшенные уровни производительности, эффективности и доступности данных, связанные с ESA.
Рисунок 5. vSAN Max обеспечивает устойчивость на уровне стоек с использованием функции доменов отказа.
Будучи настроенной правильно, функция доменов отказа обычно ограничивается большими кластерами. Это связано с тем, что, как показано на рисунке 5 выше, RAID-6 распределяет данные и четность по минимум шести доменам отказоустойчивости, и VMware рекомендует использовать по крайней мере 3 хоста на каждый домен отказа. Для достижения такой же устойчивости на уровне стоек с использованием относительно меньшего кластера можно просто разместить один (и не более одного) хоста в кластере vSAN Max на стойку, не включая функцию доменов отказа, как показано на рисунке 6. В этой конфигурации он обеспечит устойчивость на уровне стоек таким же образом.
Рисунок 6. vSAN Max обеспечивает устойчивость на уровне стоек без использования функции доменов отказа.
Такой тип стратегии изменит способ прохождения трафика vSAN через сетевое оборудование и должен быть частью вашего планирования при проектировании кластера vSAN Max.
Хотя типичная рекомендация VMware - включать опцию "Host Rebuild Reserve" для кластеров vSAN Max, обратите внимание, что эти переключатели не могут быть включены при настройке vSAN Max в растянутой топологии или при использовании функции доменов отказа vSAN.
Таги: VMware, vSAN, Max, Stretched, vSphere, HA, DR
С будущим крупным выпуском vSphere компания VMware планирует ввести режим строгой безопасности для vCenter (strong security mode), отражающий позицию безопасности VMware, который будет рекомендован к применению партнерам и клиентам в их операциях по управлению виртуальной инфраструктурой.
В строгом режиме не поддерживается SHA-1 как функция криптографического хеширования. VMware рекомендует заменить ее более безопасным и поддерживаемым SHA-256. Строгий режим также поддерживает полные SSL-сертификаты в качестве механизма обмена доверием, что может повлиять на некоторые API vSphere, использующие certificate thumbprints в качестве аргументов или как часть ответа API. Такие API могут не поддерживаться при включенном строгом режиме.
Параллельно со строгим режимом будет поддерживаться совместимый режим безопасности (compatible security mode) в целях обратной совместимости. Совместимый режим все еще поддерживает SHA-1 в качестве функции криптографического хеширования и опирается на certificate thumbprints для SSL-сертификатов как на действительный источник доверия. Использование совместимого режима не будет рекомендовано. Переключение между режимами будет происходить через свойство виртуального модуля vCenter Server Appliance. Подробная информация будет предоставлена в документации следующего выпуска vSphere.
Как будут выглядеть апгрейды существующих инфраструктур?
Начиная с грядущего крупного выпуска, все новые развертывания экземпляров vCenter будут настроены с включенным по умолчанию режимом строгой безопасности. При этом будут затронуты все решения партнеров, зависящие от устаревших алгоритмов криптографического хеширования, таких как SHA-1 или MD5. Клиенты смогут переключиться на compatible-режим, но он будет считаться устаревшим и не рекомендоваться VMware.
Обновленные до следующей версии экземпляры vCenter, ранее функционировавшие в уже существующих развертываниях, будут продолжать работать в режиме совместимости, установленном по умолчанию, если клиент не переключился на строгий режим до обновления vCenter. Таким образом, VMware рассчитывает, что клиенты будут применять самые строгие настройки безопасности, доступные в настоящее время. Это изменение повлияет и на плагины vSphere Client, использующие SHA-1 при регистрации в менеджере расширений vSphere. Отказ от адаптации к требованиям режима строгой безопасности vCenter повлечет за собой риск того, что соответствующий плагин vSphere Client станет непригодным для использования.
Влияние на плагины vSphere Client
Переход с SHA-1 на SHA-256
Все партнеры VMware должны иметь в виду, что начиная с предстоящего крупного выпуска, плагины vSphere Client, использующие устаревший стандарт SHA-1, не будут поддерживаться, когда в инфраструктуре клиента включен режим строгой безопасности vSphere. Чтобы решить эту проблему и обеспечить совместимость своих решений, VMware настоятельно советует партнерам убедиться, что версии плагинов vSphere Client, которые они предлагают сейчас, поддерживают SHA-256 в качестве алгоритма шифрования.
Алгоритм SHA-1 находится в состоянии устаревания с момента выпуска vSphere 7.0 Update 1. VMware дала возможность для плагинов vSphere Client регистрироваться в менеджере расширений с использованием SHA-256 в качестве алгоритма хеширования с выпуском vSphere 7.0 Update 3. Как следующий шаг в этом процессе, для предстоящего крупного выпуска vSphere, плагинам необходимо отказаться от использования SHA-1 в качестве функции криптографического хеширования.
Переход от certificate thumbprints к полным SSL-сертификатам
Вместе с миграцией с SHA-1, функции расширений клиента vSphere постепенно переходят к использованию полных SSL-сертификатов для регистрации плагинов. Полная поддержка сертификатов была введена для Client SDK с выпуском vSphere 8.0 Update 2. Выполнение полной проверки SSL-сертификата во время SSL handshake более безопасно, чем проверка отпечатка SSL-сертификата, даже если плагин уже использует отпечаток SSL-сертификата SHA-256.
Чтобы обеспечить совместимость плагинов в обе стороны сейчас партнерам рекомендуется предоставлять свои решения с возможностью регистрации у менеджера расширений клиента vSphere, используя как сертификат, так и отпечаток. Это необходимо, потому что в некоторых средах могут быть экземпляры vCenter, которые не поддерживают сертификаты, и которые могут попытаться загрузить новую версию плагина, зарегистрированную только с сертификатом.
Например, они могут применить certificate thumbprint (используя SHA-256 в качестве алгоритма хеширования) для регистрации с vCenter, работающим на версии 8.0 U1 или ранее, и полный SSL-сертификат для vCenter 8.0 U2 или более поздней версии.
Локальные плагины уходят в прошлое
Плагины vSphere Client, основанные на устаревшей локальной архитектуре плагинов вскоре уже не будут поддерживаться. Локальные плагины были объявлены устаревшими с момента выпуска vSphere 8.0 GA, и их поддержка прекращается со следующим крупным релизом vSphere.
Всем партнерам VMware необходимо предоставить своим клиентам версию плагина, основанную на удаленной архитектуре плагинов, чтобы они могли продолжить использование партнерского решения в следующем релизе vSphere.
Переход на TLS 1.3
Начиная с предстоящего обновления vSphere, VMware будет поддерживать протокол безопасности транспортного уровня TLS версии 1.3 вместе с устаревшим TLS 1.2, который включен по умолчанию. В следующем крупном выпуске TLS 1.2 и TLS 1.3 будут сосуществовать, и конфигурация vCenter по умолчанию будет поддерживать обе версии протокола. Однако в следующем релизе vSphere будет введен настраиваемый режим vCenter, поддерживающий только TLS 1.3.
VMware настоятельно рекомендует партнерам подумать о добавлении поддержки TLS 1.3 в их плагины, чтобы эти решения нормально работали во всех конфигурациях vCenter.
Администраторы виртуальной инфраструктуры VMware vSphere время от времени сталкиваются с проблемой завершения зависших виртуальных машин. Если в клиенте vSphere Client сделать этого не удаются, приходится заходить в сервисную консоль ESXi или в командную строку PowerCLI/PowerShell и проводить там операции по завершению процесса этой ВМ. Сегодня мы расскажем о 5 способах, которыми это можно сделать.
1. С использованием PowerCLI
Stop-VM - это командлет, используемый для завершения работы виртуальной машины. На самом деле он используется для выключения ВМ, но добавление параметра kill приведет к завершению соответствующих процессов ВМ на ESXi, фактически уничтожая ее. Делается это так:
Stop-VM -kill <отображаемое имя ВМ> -Confirm:$false
2. С использованием esxcli
Esxcli - это интерфейс командной строки (CLI), который предоставляет доступ к ряду пространств имен, таких как vm, vsan, network и software, позволяя выполнять задачи, изменять настройки и так далее. Таким образом, если вам нужно завершить работу неотвечающей виртуальной машины с использованием esxcli, можно действовать следующим образом:
Получить список виртуальных машин, размещенных на ESXi:
esxcli vm process list
Красным выделен идентификатор World ID виртуальной машины.
Скопируйте значение World ID и выполните команду:
esxcli vm process kill --type=soft -w=796791
Команда не выдает никакой обратной связи, кроме случаев, когда она не сможет найти виртуальную машину или вы укажете неверный параметр.
Параметр type принимает три значения:
Soft – позволяет процессу VMX завершиться корректно, аналогично команде kill -SIGTERM
Hard – немедленно завершает процесс VMX, аналогично команде kill -9 или kill -SIGKILL
Force – останавливает процесс VMX, когда не работают варианты Soft или Hard
3. С использованием утилиты vim-cmd
Vim-cmd - это еще одна утилита командной строки, очень похожая на esxcli, но с несколько иным синтаксисом. Также она может использоваться для управления ВМ и другими ресурсами. Соответственно, вот как используется vim-cmd для завершения работы ВМ:
1. Выведите все ВМ на текущем подключенном хосте ESXi и запишите vmid (первый столбец) неотвечающей ВМ:
vim-cmd vmsvc/getallvms
2. Получите состояние питания ВМ, используя ее vmid. Этот шаг необязателен, так как вы уже знаете, что с ВМ что-то не так:
vim-cmd vmsvc/power.getstate 36
3. Сначала попробуйте вариант power.shutdown:
vim-cmd vmsvc/power.shutdown 36
4. Если по какой-то причине ВМ не удается выключить, попробуйте использовать вместо этого power.off:
vim-cmd vmsvc/power.off 36
Следующий скриншот демонстрирует пример использования указанных выше команд для завершения работы ВМ.
4. С использованием esxtop
Esxtop - это отличная утилита, которая предоставляет информацию о том, как ESXi использует системные ресурсы. Она может использоваться для устранения неполадок, сбора статистики производительности и многого другого.
Вот как это делается:
Нажмите Shift+v, чтобы изменить представление на виртуальные машины:
Нажмите <f>, чтобы отобразить список полей, затем нажмите <c>. Это добавит столбец с идентификатором Leader World ID (LWID) в представление. Нажмите любую клавишу, чтобы вернуться в главное меню.
Найдите зависшую виртуальную машину в столбце Name и запишите ее LWID.
Нажмите k и введите значение LWID в строке запроса World to kill (WID). Нажмите Enter:
Чтобы быть полностью уверенным, подождите 30 секунд перед тем, как проверить, что виртуальная машина больше не отображается в списке. Если она все еще там, попробуйте снова. В случае неудачи, скорее всего, вам придется перезагрузить хост ESXi.
5. С помощью традиционной команды kill
Это самый грубый метод завершения работы виртуальной машины. Но он документирован на сайте VMware, хотя и немного по-другому. Виртуальная машина представляет собой серию процессов, выполняемых на ESXi. Используя команду ps ниже, можно вывести процессы, связанные, например, с виртуальной машиной под названием Web Server.
ps | grep "Web Server"
Если вы внимательно посмотрите, вы увидите, что значение во втором столбце одинаково для всех процессов. Это значение идентификатора VMX Cartel, которое, хотя и отличается от значения World ID, все же может быть использовано для завершения работы виртуальной машины следующим образом:
kill 797300
Если процессы продолжают работать, попробуйте kill -9 <идентификатор процесса>:
Не так давно мы подробно рассказывали об инициативе Private AI компании VMware, которая позволит создать надежную инфраструктуру для корпоративных систем искусственного интеллекта. Сегодня мы расскажем о новых инициативах VMware и Intel в этой сфере.
Поскольку AI обеспечивает огромный рост производительности и позволяет создавать новые возможности, многие основные функции в типичном бизнесе будут трансформироваться, включая продажи, маркетинг, разработку программного обеспечения, операции с клиентами и обработку документов. Компания McKinsey прогнозирует, что влияние генеративного AI на производительность может добавить около $4.4 триллиона ежегодно к мировой экономике.
Но в основе этого остается конфиденциальность данных предприятий. Поэтому в августе 2023 года на мероприятии VMware Explore в Лас-Вегасе VMware объявила о запуске VMware Private AI и VMware Private AI Foundation с NVIDIA. Ну а на конференции Explore Europe было объявлено о дальнейшем расширении экосистемы VMware Private AI с двумя ключевыми партнерами.
VMware Private AI с Intel дает возможность использования AI для всех организаций
VMware и Intel сотрудничают более 20 лет для обеспечения возможностей следующего поколения - от центров обработки данных до облаков с самым широким портфолио надежных корпоративных решений, позволяющих компаниям двигаться быстрее, внедрять больше инноваций и работать эффективнее.
VMware и Intel помогут предприятиям создавать и развёртывать частные и безопасные модели AI, работающие на основе архитектуры VMware Cloud Foundation, и повысить производительность AI, используя программный пакет Intel AI software suite, процессоры Intel Xeon Scalable четвёртого поколения со встроенными ускорителями и графическими процессорами Intel Max Series.
Давайте рассмотрим, какую ценность предприятия могут ожидать от этого партнёрства.
Обеспечение конфиденциальности и безопасности для моделей AI: архитектурный подход VMware Private AI для AI-сервисов обеспечивает конфиденциальность и контроль корпоративных данных, а также интегрированную безопасность и управление. Это партнёрство поможет предприятиям создать и развернуть частные и безопасные модели AI с интегрированными возможностями безопасности в VCF и его компонентах.
Повышение производительности AI: достижение высокой производительности моделей AI и LLM с использованием интегрированных возможностей, встроенных в VCF, процессоры Intel, аппаратные ускорители и оптимизированное программное обеспечение. Например, vSphere, один из основных компонентов VCF, включает планировщик Distributed Resources Scheduler (DRS), который улучшает управление рабочими нагрузками AI, группируя хосты в кластеры ресурсов для разных приложений и обеспечивая доступ ВМ к необходимому количеству вычислительных ресурсов, предотвращая узкие места на уровне ресурсов и оптимизируя их использование.
Повсеместный доступ к AI: VMware и Intel предоставляют предприятиям полностью проверенный стек ИИ на уже развёрнутых кластерах. Этот стек позволяет предприятиям проводить подготовку данных, машинное обучение, тонкую настройку и оптимизацию вывода, используя процессоры Intel, аппаратные ускорители, программный пакет Intel для AI и VCF в вашей локальной среде.
Архитектура решения
VMware Private AI на базе Intel поддерживает как генеративный AI, так и классические случаи использования AI/ML. Он использует мощность VMware Cloud Foundation и программного пакета Intel для AI, процессоров и аппаратных ускорителей. Эта архитектурная экосистема объединяет VMware, Intel, поставщиков ML Ops (cnvrg.io, Domino Data Labs, DKube, Kubeflow и т.д.), крупных производителей серверов OEM (таких как Dell Technologies, Hewlett Packard Enterprise и Lenovo), и глобальных системных интеграторов, таких как HCL, Kyndryl и Wipro.
Варианты использования
VMware Private AI и сотрудничество с Intel позволяют предприятиям использовать несколько сценариев, безопасно внедряя классические модели AI/ML и большие языковые модели, тонкую настройку и развертывание их в частной корпоративной среде. Вот описание основных случаев использования.
Генерация кода: предприятия могут использовать свои модели без риска потери интеллектуальной собственности или данных и ускорить работу разработчиков, включив генерацию кода.
Опыт решения проблем в контактных центрах: предприятия могут настраивать модели на основе своей внутренней документации и статей базы знаний, включая конфиденциальные данные поддержки, и, в свою очередь, обеспечить более эффективное обслуживание клиентов и поддержку с существенным сокращением человеческого взаимодействия в инцидентах поддержки/обслуживания.
Классическое машинное обучение: классические модели ML используются для различных реальных приложений в таких отраслях, как финансовые услуги, здравоохранение и Life Sciences, розничная торговля, исследования и производство. Популярные случаи использования ML включают персонализированный маркетинг, визуальный контроль качества в производстве, персонализированную медицину и прогнозирование спроса в розничной торговле.
Рекомендательные движки: предприятия могут улучшить взаимодействие с потребителями, предлагая или рекомендуя дополнительные продукты. Это может основываться на различных критериях, включая предыдущие покупки, историю поиска, демографическую информацию и другие факторы.
VMware Private AI с IBM обеспечивает доступ к WatsonX в локальных средах
IBM и VMware работают над VMware Private AI, чтобы позволить предприятиям получить доступ к платформе IBM WatsonX в частных, локальных средах и гибридном облаке для безопасного обучения и тонкой настройки своих моделей с помощью платформы WatsonX. Стратегическое партнерство между IBM и VMware направлено на то, чтобы обеспечить клиентам возможность легко перейти на гибридное облако и модернизировать их критически важные рабочие нагрузки. Теперь, имея возможность выбора времени, места и способа интеграции технологий GenAI с VMware Cloud Foundation, предприятия смогут быстро обучать и развертывать индивидуальные возможности AI в рамках всего предприятия, сохраняя при этом полный контроль и соответствие требованиям к их данным. Благодаря этому партнерству в области AI между VMware и IBM, предприятия получают мощное решение, использующее лучшие инновации от локальных решений VMware в едином стеке, чтобы обеспечить унифицированную среду, интегрированную с данными и возможностями AI, предоставляемыми технологией партнера IBM Cloud.
Получите частные и безопасные модели с VMware Private AI: конфиденциальность и безопасность имеют первостепенное значение для предприятий. Теперь предприятия могут создавать свои частные и безопасные модели AI с VMware Private AI с IBM, используя несколько интегрированных возможностей конфиденциальности, безопасности и микросегментации в VCF.
Развертывание моделей AI/ML в локальной среде и в облаке: это партнерство позволяет предприятиям обучать, проверять, настраивать и развертывать частные и безопасные модели AI/ML как в локальной среде, так и в облаке IBM Cloud.
Выбор между открытыми или проприетарными моделями IBM: это партнерство позволяет предприятиям выбирать большие языковые модели (LLM), предоставляя доступ к открытым моделям от Hugging Face, выбранным IBM, моделям сторонних производителей и серии обученных IBM фундаментальных моделей.
Вот несколько примеров поддерживаемых моделей, доступных на watsonx.ai:
Открытые модели: Llama 2 (70b)
Модели сторонних производителей: StarCoder (15.5b)
Проприетарные модели IBM: Granite (13b)
Архитектура решения
Эта полноценная архитектура, построенная на основе VMware Cloud Foundation, использует Red Hat OpenShift и сочетает в себе возможности платформы IBM WatsonX для Gen AI и классических AI/ML-нагрузок с Enterprise-уровнем безопасности. С помощью этой архитектуры предприятия могут использовать watsonx.ai для доступа к открытым моделям IBM, выбранным из Hugging Face, а также к другим моделям сторонних производителей и серии обученных IBM фундаментальных моделей для поддержки вариантов использования GenAI и для обучения, проверки, настройки и развертывания классических моделей AI/ML.
Варианты использования
VMware Private AI с IBM может обеспечить несколько сценариев использования для предприятий, безопасно активируя настройку больших языковых моделей, тонкую настройку и развертывание их в частной корпоративной среде. В области генерации кода акцент сделан на ускорении продуктивности разработчиков с учетом критически важных вопросов конфиденциальности и интеллектуальной собственности. Кроме того, VMware Private AI в сотрудничестве с IBM представляет значительную возможность улучшить взаимодействие в контактных центрах. Это партнерство обещает улучшение качества контента и обратной связи для клиентов, что приводит к более точным ответам и, в целом, улучшению клиентского опыта. Это партнерство может значительно упростить ИТ-операции, автоматизировав задачи, такие как управление инцидентами, отчетность, управление тикетами и мониторинг, в конечном итоге экономя время и усилия агентов ИТ-операций. Наконец, продвинутые возможности поиска информации, возникшие благодаря этому сотрудничеству, могут повысить продуктивность сотрудников, оптимизируя поиск документов и исследование политик, способствуя более продуктивной рабочей среде.
IBM Consulting предоставляет клиентам экспертизу в решениях, специфичных для VMware и генеративного AI
Ранее в этом году IBM Consulting создала Центр компетенции по генеративному AI и теперь имеет более 1000 консультантов со специализированными знаниями в области генеративного AI, которые работают с глобальными клиентами, чтобы повысить производительность в ИТ-операциях и основных бизнес-процессах, таких как кадровые или маркетинговые, улучшить клиентский опыт и создать новые бизнес-модели.
Это, в сочетании с экспертизой IBM, специфичной для VMware, и сервисными возможностями, поможет ускорить бизнес-трансформации клиентов с использованием корпоративного AI на архитектуре VMware Private AI.
Кроме того, для клиентов, желающих модернизировать и трансформировать свои рабочие нагрузки, IBM Consulting планирует интегрировать услуги IBM WatsonX и VMware Private AI в свой проприетарный IBM Consulting Cloud Accelerator, чтобы помочь ускорить процесс трансформации инфраструктур в облака. После релиза эта интеграция поможет с процессами reverse engineering и генерацией кода, а также с управлением операциями Day-2 и последующими для бесперебойного предоставления услуг управления гибридным облаком от IBM Consulting.
На прошедшей недавно конференции Explore 2023 Europe компания VMware объявила о предстоящем запуске решения VMware Live Recovery, которое обеспечит защиту от программ-вымогателей (Ransomware) и восстановление после катастроф в VMware Cloud через единую консоль.
Платформа VMware Live Recovery разработана, чтобы помочь организациям защищать свои приложения и данные в инфраструктуре VMware от множества угроз разного типа, включая атаки программ-вымогателей, сбои инфраструктуры, человеческие ошибки и многое другое.
VMware Live Recovery будет предоставлять клиентам:
Безопасное восстановление после кибератак - это позволит организациям с уверенностью и быстро восстановиться после атак программ-вымогателей, зашифровавших и заблокировавших данные.
Единая защита - Live Recovery предоставит единую консоль для управления функциями защиты от Ransomware и восстановления после катастроф, упрощая администрирование крупных систем.
Упрощенное использование - продукт предложит гибкую лицензию для различных случаев использования и облачных решений, упрощая для организаций получение необходимой защиты.
VMware Live Recovery будет идеальным решением для администраторов, ответственных за устойчивость инфраструктуры, и команд безопасности, которые также управляют киберугрозами. Это будет важный инструмент для организаций, использующих VMware Cloud для работы своих критически важных приложений.
Что нового в концепции VMware Live Recovery?
VMware Live Recovery будет отличаться от других решений на рынке в ряде аспектов. Во-первых, это будет интегрированное решение, предоставляющее единую защиту от программ-вымогателей и восстановления после катастроф для всей гибридной инфраструктуры. Это означает, что организации смогут управлять своими потребностями в защите в рамках нескольких облаков с помощью единой консоли, упрощая управление и снижая затраты.
Во-вторых, VMware Live Recovery разработан изначально, чтобы помочь организациям безопасно восстанавливаться после атак программ-вымогателей. Для этого будут использоваться многие современные техники, включая неизменяемые снимки, изолированную среду восстановления VMware (isolated recovery environment, IRE) для тестирования и проверки зараженных виртуальных машин, руководство по рабочим процессам и встроенный антивирус нового поколения, а также средства анализа поведения для выявления современных программ-вымогателей.
Наконец, VMware Live Recovery предложит гибкую лицензию по подписке для различных случаев использования и облачных решений. Это упростит для организаций получение необходимой защиты, с возможностью добавления или изменения функциональности в соответствии с изменяющимися потребностями или требованиями бизнеса.
Объединенное решение
VMware Live Recovery объединит два проверенных решения VMware в единую консоль и поддержку организации. Клиенты получат доступ к функциональным возможностям VMware Site Recovery Manager и VMware Cloud Disaster Recovery с восстановлением после атак программ-вымогателей. Кроме того, клиенты могут выбирать между моделями развертывания, сохраняя при этом единую консоль, с гибкостью для изменяющихся бизнес-потребностей и уверенностью в поддержке от единого производителя.
Как VMware Live Recovery может помочь вашей организации?
Решение сможет помочь вашей организации различными способами. Оно обеспечит единую защиту с помощью восстановления после атак программ-вымогателей и восстановления после катастроф в VMware Cloud в одной консоли (Secure Cyber Recovery), которое позволяет уверенно и быстро восстанавливаться после большинства атак на данные. Кроме того, модель Simplified Consumption позволит гибко лицензировать использование сценариях и инфраструктурах.
Более подробная информация о продукте должна появиться в ближайшее время.
В рамках проходившей недавно конференции Explore 2023 Europe компания VMware анонсировала релиз новой версии своего основного фреймворка для управления виртуальной инфраструктурой с помощью сценариев - PowerCLI 13.2. Напомним, что о прошлой версии этого пакета - PowerCLI 13.1 - мы писали вот тут.
Этот релиз предоставляет официальную поддержку VMware Cloud Foundation (VCF) в PowerCLI, а также новые функции для vSphere, vSAN и VMware Cloud.
1. Новые SDK-модули для VCF
VMware Cloud Foundation (VCF) - это интегрированная платформа, объединяющая полный спектр программно-определяемых сервисов в единую систему. По мере того, как все больше клиентов VMware начинают использовать VCF, увеличивается и спрос на автоматизацию через CLI. До сих пор единственным вариантом был модуль PowerVCF с открытым исходным кодом, но с PowerCLI 13.2 было добавлено два официальных модуля VCF – VMware.Sdk.Vcf.CloudBuilder и VMware.Sdk.Vcf.SddcManager. Это SDK-модули, использующие ту же технологию, что и модули PowerCLI SDK для vSphere Automation, NSX, SRM и API vSphere Replication. Как и в случае со всеми SDK-модулями, примеры PowerCLI можно найти непосредственно в документации REST API для VCF.
2. Новые функции управления жизненным циклом vSphere
В PowerCLI 13.2 было добавлено два новых командлета для vLCM:
Export-LcmVMHostDesiredState экспортирует желаемое состояние хоста vSphere Lifecycle Manager
New-OfflineBundle создает автономный пакет, соответствующий требованиям vLCM, на основе введенных данных о хранилищах и спецификации программного обеспечения.
3. Новые функции vSAN
В PowerCLI 13.2 был добавлен новый командлет Get-VsanPerformanceContributor в модуль VMware.VimAutomation.Storage. Он позволяет получить список наиболее значимых объектов, влияющих на производительность vSAN. Также был расширен вывод командлета Get-VsanSpaceUsage за счет свойства EsaObjectOverheadGB, которое предоставляет информацию о дополнительных накладных расходах для объектов vSAN ESA на хранение метаданных и обеспечение высокой производительности.
4. Новые функции VMware Cloud
В PowerCLI 13.2 были расширены командлеты New-VmcSddc и New-VmcSddcCluster за счет добавления поддержки хостов I4I.
5. Обновленные SDK-модули
В PowerCLI 13.2 были обновлены все модули, предоставляющие привязки к API. А именно:
Модули vSphere обновлены до версии vSphere 8.0 Update 2
Модули NSX обновлены до версии NSX 4.1.2
Модули SRM и vSphere Replication обновлены до версии 8.8
Модуль Horizon обновлен до VMware Horizon 8 2306
Скачать последнюю версию фреймворка VMware PowerCLI 13.2 можно по этой ссылке.
На прошедшей недавно конференции Explore 2023 Europe компании VMware и Intel рассказали о своем видении того, как в будущем будет происходить управление и контроль над уязвимостями ниже уровня ОС.
Благодаря расширенному партнерству VMware и Intel, данные телеметрии от процессоров Intel Core позволят решению Workspace ONE Unified Endpoint Management (UEM) собирать данные об уязвимостях ниже уровня операционной системы. Эта новая интеграция сочетает в себе данные на уровне чипа с автоматическим устранением проблем и возможностями отчетности Workspace ONE UEM для повышения безопасности конечных устройств.
Видео старое, но суть объясняет:
Фундаментальные уязвимости
Обеспечение безопасности современных работников является постоянной задачей, так как киберугрозы увеличиваются как в частоте, так и в сложности. На конференции VMware Explore 2023 в Лас-Вегасе команда VMware рассказала о важности принятия комплексного подхода к управлению уязвимостями и его влиянии на безопасность организации. Новая эффективная платформа управления уязвимостями предлагает не только широкий охват платформ ОС, но и глубокое понимание от уровня приложений и ОС до firmware и оборудования. Уязвимости ниже уровня ОС, или фундаментальные уязвимости, особенно опасны, поскольку они остаются незамеченными традиционными сканерами уязвимостей и могут привести к потенциально катастрофическим последствиям.
Управление уязвимостями VMware и Intel
Было анонсировано решение для создания и сбора данных о фундаментальных уязвимостях для компьютеров с Windows с процессорами Intel Core (с технологией Intel vPro или без нее). Благодаря глубокому анализу и знанию различных производителей ПК, Intel обладает уникальной способностью интерпретировать данные конфигурации с конечных устройств и обнаруживать те уязвимости, которые не находятся традиционными сканерами безопасности. Данные сопоставляются с известными фундаментальными уязвимостями и упаковываются в анализы рисков с соответствующим контекстом и деталями для идентификации и последующего устранения.
Этот улучшенный телеметрический подход на самом низком уровне поможет дополнить движок управления уязвимостями и комплаенсом для решения Workspace ONE. Этот продукт будет визуализировать данные активных событий, позволяя клиентам имплементировать более сильную стратегию безопасности конечных устройств, использующую управление уязвимостями как выше, так и ниже уровня ОС. Новые данные об оборудовании не только дадут клиентам большую видимость их парка устройств, но и соберут более богатый контекст для повышения эффективности оценки уязвимостей и их устранения.
Бета-версия Intel Chip to Cloud
Облачная служба Intel Device Health скоро будет доступна в портале программы раннего доступа VMware Anywhere Workspace Early Access.
Если вы уже являетесь участником программы раннего доступа, вы можете выбрать бета-версию Intel Chip to Cloud в своем пользовательском профиле, когда она станет доступной. Бета-программа будет включать возможности анализа уязвимостей вместе с интеграцией Intel vPro Chip to Cloud. Если вы еще не являетесь участником, вы можете зарегистрироваться здесь.
В июне этого года компания VMware представила большое обновление архитектуры VMware Cloud Foundation 5.0 (VCF), в котором был полностью обновлен BOM (bill of materials), а также добавлено множество новых возможностей по управлению гиперконвергентной виртуальной средой. В рамках проходящей сейчас конференции Explore 2023 Europe было представлено очередное обновление VMware Cloud Foundation 5.1.
Давайте посмотрим, что нового появилось в VCF 5.1:
Поддержка VCF для архитектуры vSAN Express Storage (ESA)
В новой версии VCF появилась расширенная поддержка платформ хранения NVMe с поддержкой архитектуры vSAN Express Storage (ESA), которая позволяет клиентам развертывать серверы следующего поколения, обеспечивающие повышенную производительность, большую масштабируемость и улучшенную эффективность. Работая в сочетании с оригинальной архитектурой хранения vSAN (OSA), vSAN ESA представляет собой архитектуру, разработанную для достижения совершенно новых уровней эффективности, масштабируемости и производительности, оптимизированную для использования полного потенциала самого современного оборудования. Подробнее о vSAN ESA вы можете узнать вот тут.
Улучшения в области сетей и безопасности
Релиз VCF 5.1 содержит несколько улучшений, которые упрощают настройку расширенных сетевых функций подсистемы безопасности. Самое значительное изменение — это улучшенные рабочие процессы SDDC Manager, которые позволяют администраторам настраивать новые домены рабочих нагрузок и кластеры с несколькими физическими сетевыми адаптерами и виртуальными распределенными коммутаторами, подготовленными для NSX.
Были внесены и другие улучшения сетевой инфраструктуры, которые дополнительно используют NSX, с упрощенной и соответствующей стандартам топологией для расширенных кластеров, настроенных для vSAN OSA, и возможностью настройки Edge-кластеров без двухуровневой маршрутизации.
Эти улучшения глубокого тюнинга сети позволяют администраторам обеспечивать высокопроизводительные сетевые топологии с повышенной безопасностью, которые могут быть легко масштабированы и управляемы в течение всего жизненного цикла.
Распределенный движок сервисов vSphere для сред VCF
Релиз VCF 5.1 также поддерживает распределенный движок сервисов vSphere (ранее известный как Project Monterey), позволяющий оборудованию специализированной обработки данных (DPU) исполнять задачи, которые традиционно выполнялись гипервизором на процессорах x86. Вынесение туда задач, таких как сетевое взаимодействие и безопасность, на эти программируемые аппаратные ускорители, позволяет повысить общую производительность и поддержку более требовательных к производительности рабочих нагрузок. Первоначальная поддержка позволяет клиентам выгружать стек виртуализации NSX, работающий на хосте, в шину PCIe устройств SmartNIC, улучшая производительность и освобождая циклы процессора. В VCF 5.1 поддерживаются DPU от AMD и NVIDIA.
Улучшения GPU для производительности и масштабируемости
Для поддержки больших рабочих нагрузок генеративного ИИ и LLM (больших языковых моделей), среды, использующие GPU NVIDIA, могут использовать динамический DirectPath I/O (также называемый "passthrough") или конфигурации NVIDIA vGPU. Это поддерживает множество сценариев использования и позволяет обеспечивать максимальную производительность до 16 GPU/vGPU на одну виртуальную машину, что удваивает возможности GPU по сравнению с предыдущими версиями VMware Cloud Foundation. Использование одного или нескольких профилей NVIDIA vGPU на ваших виртуальных машинах обеспечивает большую интеграцию с инфраструктурой VMware за счет поддержки продвинутых возможностей vSphere, таких как vMotion, размещение ВМ с DRS и опций для более эффективной упаковки меньших ВМ с vGPU, в ваши кластеры для освобождения места для более крупных GPU-нагрузок, таких как LLM.
Другие ключевые улучшения, доступные в VMware Cloud Foundation 5.1
Интеграция управления жизненным циклом облачных систем с VMware Aria Suite
Обновления управления жизненным циклом, включая асинхронные предварительные проверки и поддержку образов vSphere Lifecycle Manager в управляющих доменах VCF.
Многочисленные улучшения сетевой инфраструктуры для растянутых кластеров vSAN, кластеров NSX Edge и усовершенствованных рабочих процессов SDDC Manager.
Служба VMware Identity Broker позволяет администраторам подключаться к сторонним/внешним провайдерам идентификации (IDP) для обработки учетных данных и аутентификации (включая многофакторную аутентификацию). Теперь OKTA поддерживается как сторонний брокер в средах VMware Cloud Foundation.
Новый провайдер Terraform для VMware Cloud Foundation, который позволяет использовать инфраструктуру как код для развертывания, управления и обслуживания VMware Cloud Foundation с помощью машиночитаемых файлов определений для достижения заданного состояния.
VMware Cloud Foundation 5.1 теперь доступен для постоянного развертывания, среды на базе подписки будут поддерживаться в VCF 5.1 на более позднем этапе.
Подробнее об инфраструктуре VCF вы можете узнать на странице продукта. Технические ресурсы по платформе доступны тут.
Компания VMware недавно выпустила бюллетень безопасности VMSA-2023-0024, в котором описываются уязвимости CVE-2023-34057 и CVE-2023-34058, обнаруженные в различных версиях пакетов для гостевых ОС VMware Tools.
Надо отметить, что первая уязвимость затрагивает локальное повышение привилегий, а вторая - обход токена безопасности, что является критическими типами дыр в безопасности.
Используя уязвимость CVE-2023-34057, локальный пользователь MacOS может повысить свои привилегии в виртуальной машине до административных (критичность 7.8). Ну а в CVE-2023-34058 рассказывается о том, как можно обойти проверку сигнатуры SAML в токене безопасности (критичность 7.5).
Вот какие версии VMware Tools были затронуты, поэтому если у вас они используются, рекомендуется срочно обновить их:
Более подробно обо всем этом рассказано тут. Проверить версию VMware Tools для всей вашей виртуальной инфраструктуры наиболее удобно с помощью утилиты RVTools.
В руководство добавили различные рекомендации и новые максимальные значения инфраструктуры, касающиеся именно vSphere 8 Update 2 и vSAN 8 Update 2.
Как и всегда, документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:
Hardware for Use with VMware vSphere (страница 11)
ESXi and Virtual Machines (страница 25)
Guest Operating Systems (страница 55)
Virtual Infrastructure Management (страница 67)
Предполагается, что читатель уже в достаточной степени осведомлен о методах управления виртуальной инфраструктурой и ее основных компонентах.
Скачать Performance Best Practices for VMware vSphere 8.0 Update 2 можно по этой ссылке.
В последние годы VMware так много занимается контейнерной виртуализацией средствами Kubernetes и интеграцией этих технологий в единую среду виртуальных машин и контейнеров, что может создаться впечатление, что VMware является чуть ли не главным производителем средств управления данными средами.
На самом деле это не совсем так. Недавно аналитическая компания Gartner, известная своими "магическими квадрантами" в различных категориях программного и аппаратного обеспечения, выпустила отчет Magic Quadrant for Container Management 2023, который публикует компания Red Hat:
Как мы видим, по мнению Gartner, VMware находится в квадранте лидеров, но всего лишь замыкает первую пятерку. Давайте посмотрим, что Gartner пишет о VMware в отчете:
В мае 2022 года Broadcom объявила о намерении приобрести VMware. В период оценки VMware соответствовала критериям включения в этот отчет и продолжала действовать как независимая структура. Gartner предоставит дополнительные данные и исследования по мере поступления информации о приобретении.
VMware является лидером в этом магическом квадранте. Ее портфель Tanzu, включающий предложения по контейнеризации, фокусируется на современных приложениях. География оперирования VMware широка, а ее клиенты варьируются от средних до крупных предприятий. Бизнес-модель VMware развивалась в направлении адаптации управления контейнерами. Теперь она сочетает продукты для виртуализации с решениями для управления современными приложениями, при этом VMware вносит все больший вклад в открытое программное обеспечение.
Сильные стороны
Клиентская база: VMware имеет большую базу установок и обширную экосистему партнеров и альянсов. У нее успешный опыт развития тех решений, которые уже есть у пользователей, что приводит к меньшей необходимости развивать новые операционные навыки.
Продуктовая стратегия: продолжающееся приобретение компаний со стороны VMware демонстрирует ее приверженность современным приложениям (например, Heptio, Pivotal, Bitnami, Saltstack и Octarine). Эти приобретения в сочетании с постоянными внутренними инвестициями в разработку подчеркивают, что она предоставляет возможности для удовлетворения потребностей контейнерных сред.
Гибридные операции: используя свой опыт в гибридной инфраструктуре и операционных инструментах, VMware предлагает сильные возможности управления кластерами на протяжении всего жизненного цикла, включая поддержку для публичных облачных Kubernetes-сервисов, таких как Amazon EKS.
Что заслуживает внимания
Конкурентное трение: VMware построила партнерские отношения с ведущими облачными провайдерами, но управление контейнерами является областью конкурентного перекрытия. Чтобы оставаться конкурентоспособным в эпоху облачных нативных технологий, VMware должна успешно создавать ценность, которая отличает ее от нативных облачных контейнерных сервисов своих партнеров.
Интеграция продуктов и план развития: Tanzu включает в себя возможности управления контейнерами, происходящие из множества внутренних проектов и приобретенных технологий. Клиенты Gartner сталкиваются с некоторой путаницей из-за множества предложений, особенно тех, которые предоставляются как сервис, и беспокойство относительно того, как различные решения интегрированы между собой и с ключевыми компонентами инфраструктуры.
Предстоящее приобретение: предстоящее приобретение VMware компанией Broadcom стало предметом беспокойства для многих клиентов Gartner. Ну а клиенты VMware обеспокоены потенциальным увеличением цен, сокращением инвестиций в продукты или воздействием на соглашения о поддержке.
Скачать отчет Gartner Magic Quadrant for Container Management 2023 можно по этой ссылке.
Еще в 2015 году мы писали о том, что проект VMware Sample Exchange вышел в бета-версии. Это портал, предназначенный для разработчиков средств автоматизации виртуальной инфраструктуры, где они могут скачивать примеры кода на разных языках и для разных платформ под множество компонентов виртуальной среды.
За прошедшие 8 лет этот проект накопил огромное количество различных сценариев и примеров кода как от сотрудников VMware, так и от сообщества разработчиков, которые постоянно добавляют туда новые сэмплы (вы тоже можете это делать).
Если при первоначальном запуске портала там было всего 250 сэмплов, то теперь их стало более двух тысяч, как видно на скиншоте ниже:
Посмотрите, какое огромное количество языков и платформ представлено на портале, одних только дэшбордов для решения vRealize (Aria) Operations - 300 штук!
Примерно столько же представлено и сценариев для автоматизации инфраструктуры средствами PowerShell/PowerCLI, а вот это уже - большая находка.
Есть несколько потенциальных комбинаций растянутого кластера и перечисленных возможностей, на момент релиза VMware vSAN 8.0 Update 2 поддержка возможностей выглядит следующим образом:
Датастор vSAN Stretched Cluster, расшаренный с vSAN Cluster (не stretched) –>Поддерживается
Датастор vSAN Stretched Cluster, расшаренный с Compute Only Cluster (не stretched) –>Поддерживается
Датастор vSAN Stretched Cluster, расшаренный с Compute Only Cluster (stretched, symmetric) –>Поддерживается
Датастор vSAN Stretched Cluster, расшаренный с Compute Only Cluster (stretched, asymmetric) –> Не поддерживается
В чем разница между симметричным и асимметричным растянутым кластером? На следующем изображении, взятом из конфигурации vSAN Stretched Cluster, это лучше всего объяснено:
Если вы используете растянутый кластер vSAN и растянутый Compute Only, то обычно используется Asymmetric-конфигурация, поэтому шаринг датасторов в этом случае не поддерживается.
Сегодня мы расскажем о том, как определить пропускную способность сети между площадками при использовании кластеров vSAN HCI и кластеров vSAN Max в конфигурации Stretched Cluster.
В растянутом кластере два домена отказоустойчивости данных содержат один или несколько хостов, а третий домен отказоустойчивости содержит виртуальный модуль Witness для определения доступности сайтов данных. Далее каждый домен отказоустойчивости данных мы будем называть сайтом. Конфигурации растянутого кластера vSAN могут распространяться на разные расстояния, при условии что соблюдаются требования по пропускной способности (bandwidth) и задержке (latency).
Минимально поддерживаемая пропускная способность и latency между сайтами
Пропускная способность, которая требуется между сайтами, в большой степени зависит от объема операций ввода-вывода (I/O), который генерируют рабочие нагрузки, но будут влиять и другие факторы, такие как используемая архитектура (vSAN ESA или OSA), размер кластера и сценарии обработки сбоев. Ниже указаны минимально поддерживаемые значения, но рассчитанные оценки для конкретной инфраструктуры могут привести к требованиям по пропускной способности, превышающим указанные минимумы.
Приведенные ниже формулы помогут оценить необходимую пропускную способность сети между сайтами. Предполагается, что два сайта данных географически расположены достаточно близко друг к другу, чтобы соответствовать требованиям по задержке.
Понимание активности I/O, соотношения чтения и записи и размеров I/O
Рабочие нагрузки состоят из нескольких характеристик. Не только количество активности I/O значительно различается от нагрузки к нагрузке, но чтения и записи часто происходят с разными скоростями и разными размерами I/O. С целью предоставления простой формулы для расчета мы будем использовать следующие переменные для расчета оценочной пропускной способности связи между сайтами для растянутого кластера (ISL):
Скорость I/O всех команд чтения и записи, измеряемая в IOPS
Соотношение чтения/записи (например, 70/30)
Средний размер I/O, измеряемый в KB
Пропускная способность - это измерение на основе скорости, что означает, как много данных передается за определенный период времени. В отличие от измерения неактивных данных, где оно принимает форму байтов, килобайтов и т. д., измерение данных в процессе передачи по сети выражается в битах (b), килобитах (Kb), мегабитах (Mb) или гигабитах (Gb), и период времени - "в секунду" (ps). Обсуждая скорости, мы должны помнить о конвертации байтов в биты.
Давайте используем простой пример, где общий профиль I/O требует 100 000 I/O в секунду (IOPS), в среднем 8 KB каждый, где 70% IOPS - это чтение, и 30% - запись, в растянутой конфигурации. В этом сценарии запись I/O (30 000 IOPS в среднем 8 KB каждый) будет равна 240 000 Kbps или 240 Mbps. Это будет оценкой пропускной способности ISL, необходимой для этого профиля.
Простейший, но потенциально менее точный способ оценки требований к пропускной способности - это просто использовать входные данные, представляющие общие потребности кластера. Если кто-то использует формулу для расчета отдельных рабочих нагрузок в кластере, сумма этих расчетов предоставит результирующие требования к пропускной способности. Возможно, вы захотите выделить гораздо больше минимального рассчитанного количества, так как рабочие нагрузки со временем неизбежно становятся более ресурсоемкими.
Формулы для расчета оценок пропускной способности указаны ниже, они привязаны к используемой архитектуре: vSAN OSA или vSAN ESA. С введением архитектуры vSAN Express Storage (ESA) появляются все новые возможности по обеспечению производительности хранилища на совершенно новом уровне. Поэтому при использовании ESA рекомендуется тщательно отслеживать использование ISL, чтобы убедиться, что есть достаточная пропускная способность, необходимая для того, чтобы рабочие нагрузки не были ограничены со стороны ISL. Для дополнительной информации см. статью: "Использование vSAN ESA в топологии растянутого кластера".
Формулы расчета пропускной способности для vSAN ESA
Трафик репликации от I/O гостевой ВМ - это доминирующий тип трафика, который мы должны учесть при оценке необходимой пропускной способности для трафика межсайтовой связи (ISL). У растянутых кластеров vSAN ESA трафик чтения по умолчанию обслуживается сайтом, на котором находится ВМ. Требуемая пропускная способность между двумя сайтами данных (B) равна пропускной способности записи (Wb) * множитель данных (md) * множитель ресинхронизации (mr) * коэффициент сжатия (CR).
Расчет пропускной способности для ISL, обслуживающего растянутый кластер vSAN с использованием ESA, отличается от формулы, используемой для OSA. vSAN ESA сжимает данные до их репликации между сайтами. В результате ESA уменьшает использование пропускной способности ISL, эффективно увеличивая его возможности для передачи большего количества данных.
Чтобы учесть это в расчете в топологии, использующей ESA, формула учитывает оценочное соотношение сжатия сохраненных данных. Давайте рассмотрим следующий пример, где мы оцениваем экономию в 2 раза благодаря использованию сжатия в vSAN ESA. Мы используем простое значение "2x" (также называемое 2:1 или 50%) для простоты. Фактические коэффициенты сжатия будут зависеть от данных, хранящихся в вашей среде. Пример 2:1 - это не предположение о том, что вы на самом деле можете увидеть в своей среде.
Преобразуйте это в процент от исходного размера, разделив конечный размер на начальный размер. Это даст, например, результат ".50".
Умножьте окончательное рассчитанное значение из описанной в этой статье формулы на ".50".
В результате формула будет выглядеть так:
B = Wb * md * CR * mr * CR
Как отмечалось выше, коэффициенты сжатия часто могут быть представлены разными способами, чтобы выразить экономию места.
Например:
Сжатие, выраженное в соотношении. [начальный размер]:[конечный размер]. Соотношение сжатия 2:1 указывает на то, что данные будут сжаты до половины своего исходного размера.
Сжатие, выраженное в виде множителя экономии. Соотношение сжатия 2x указывает на то, что данные будут сжаты до половины своего исходного размера. Это то, что отображается в представлении ёмкости кластера vSAN.
Сжатие, выраженное в процентах от исходного размера. Значение сжатия 50% (или, .50) указывает на то, что данные будут сжаты до половины своего исходного размера.
Примеры между сайтами (для vSAN ESA)
Рабочая нагрузка 1
С примером рабочей нагрузки в 10 000 записей в секунду на рабочую нагрузку vSAN со средним размером записи 8 KB потребуется 80 МБ/с или 640 Мбит/с пропускной способности. Предположим, что данные имеют коэффициент сжатия 2x.
B = 640 Мбит/с * 1.4 * 1.25 * .50 = 560 Мбит/с.
Учитывая требования к сети vSAN, требуемая пропускная способность составляет 560 Мбит/с.
Рабочая нагрузка 2
В другом примере, 30 000 записей в секунду, 8KB записи, потребуется 240 MB/s или 1 920 Мбит/с пропускной способности. Предположим, что данные имеют коэффициент сжатия 2x.
B = 1,920 Мбит/с * 1.4 * 1.25 * .50 = 1,680 Мбит/с или примерно 1,7 Гбит/с.
Требуемая пропускная способность составляет примерно 1,7 Гбит/с.
Рабочие нагрузки редко состоят только из чтений или записей, и обычно включают общее соотношение чтения к записи для каждого варианта использования. Используя общую ситуацию, когда общий профиль I/O требует 100 000 IOPS, из которых 70% являются записью, а 30% чтением, в растянутой конфигурации, IO записи - это то, на что рассчитана пропускная способность межсайтовой связи. С растянутыми кластерами vSAN, трафик чтения по умолчанию обслуживается сайтом, на котором находится ВМ.
Формулы расчета пропускной способности для vSAN OSA
Как и в растянутых кластерах с использованием ESA, трафик репликации от I/O гостевой ВМ в растянутом кластере с использованием OSA является доминирующим типом трафика, который мы должны учитывать при оценке необходимой пропускной способности для трафика межсайтовой связи (ISL). В растянутых кластерах vSAN OSA трафик чтения по умолчанию обслуживается сайтом, на котором размещена ВМ. Требуемая пропускная способность между двумя данными сайтами (B) равна пропускной способности записи (Wb) * множитель данных (md) * множитель ресинхронизации (mr), или:
B = Wb * md * mr
Множитель данных состоит из накладных расходов на трафик метаданных vSAN и различных связанных операций. VMware рекомендует использовать множитель данных 1.4. Множитель ресинхронизации включен для учета событий ресинхронизации. Рекомендуется выделять пропускную способность по верхней границе требуемой пропускной способности для событий ресинхронизации. Для учета трафика ресинхронизации рекомендуются дополнительные 25%.
Планируйте использование vSAN ESA для всех новых кластеров vSAN. Эта архитектура быстрее и эффективнее, чем vSAN OSA, и, зачастую, уменьшает количество хостов, необходимых для того же объема рабочих нагрузок. Формула для vSAN OSA остается актуальной для тех, у кого уже есть установки vSAN OSA.
Требования к пропускной способности между Witness и сайтом данных
В топологии растянутого кластера хост-машина Witness просто хранит компоненты, состоящие из небольшого объема метаданных, которые помогают определить доступность объектов, хранящихся на сайтах с данными. В результате сетевой трафик, отправляемый на сайт для этой машины, довольно мал по сравнению с трафиком между двумя сайтами с данными через ISL.
Одной из наиболее важных переменных является объем данных, хранящихся на каждом сайте. vSAN хранит данные в виде объектов и компонентов. Она определяет, сколько компонентов нужно для данного объекта, и где они должны быть размещены по всему кластеру, чтобы поддерживать устойчивость данных в соответствии с назначенной политикой хранения.
Архитектура vSAN ESA обычно использует больше компонентов, чем OSA. Это следует учитывать при расчете потенциально необходимой пропускной способности для машины Witness.
Обязательно выберите правильный размер хоста vSAN Witness. При развертывании предлагается четыре размера машины (Tiny, Medium, Large и Extra Large), каждый из которых предназначен для размещения разных размеров сред. Посмотрите статью "Deploying a vSAN Witness Appliance" для получения дополнительной информации.
Формулы расчета пропускной способности Witness для vSAN ESA и OSA
Сетевое взаимодействие сайтов с Witnessn состоит исключительно из метаданных, что делает запросы к сетевым ресурсам Witness гораздо более легковесными, что отражается в поддерживаемых минимальных требованиях к пропускной способности и задержке.
Поскольку формула для оценки необходимой пропускной способности Witness основана на количестве компонентов, ее можно использовать для расчета растянутых кластеров, использующих OSA или ESA. Поскольку ESA обычно использует больше компонентов на объект (возможно, в 2-3 раза больше) по сравнению с OSA, следует учитывать большее количество компонентов на ВМ при использовании архитектуры на базе ESA.
Базовая формула
Требуемая пропускная способность между Witness и каждым сайтом равна ~1138 Б x Количество компонентов / 5с
1138 Б x Кол-во компонентов / 5 секунд
Значение 1138 Б происходит от операций, которые выполняются, когда предпочтительный сайт выходит из строя, и второстепенный сайт берет на себя владение всеми компонентами. Когда основной сайт выходит из строя, второстепенный сайт становится лидером. Witness отправляет обновления новому лидеру, после чего новый лидер отвечает Witness, по мере обновления владения. Требование в 1138 Б для каждого компонента происходит из сочетания полезной нагрузки от Witness к резервному агенту, за которым следуют метаданные, указывающие, что предпочтительный сайт не работает. В случае отказа предпочтительного сайта, связь должна быть достаточно хорошей, чтобы позволить изменение владения кластером, а также владение всеми компонентами в течение 5 секунд.
Примеры пропускной способности Witness к сайту (OSA)
Нагрузка 1
Если ВМ состоит из:
3 объектов
Параметр допустимого числа отказов (FTT=1)
Приблизительно 166 ВМ с этой конфигурацией потребовало бы, чтобы Witness содержал 996 компонентов (166 ВМ * 3 компонента/ВМ * 2 (FTT+1) * 1 (Ширина полосы)). Чтобы успешно удовлетворить требования пропускной способности Witness для общего числа 1 000 компонентов на vSAN, можно использовать следующий расчет:
Преобразование байтов (Б) в биты (б), умножьте на 8:
В = 1138 Б * 8 * 1 000 / 5с = 1 820 800 бит в секунду = 1.82 Мбит/с
VMware рекомендует добавить безопасный запас в 10% и округлить вверх.
B + 10% = 1.82 Мбит/с + 182 Кбит/с = 2.00 Мбит/с
Таким образом, с учетом безопасного запаса в 10%, можно утверждать, что для каждых 1 000 компонентов подходит канал 2 Мбит/с.
Нагрузка 2
Если ВМ состоит из:
3 объектов
FTT=1
Stripe с параметром 2
Приблизительно 1 500 ВМ с этой конфигурацией потребовало бы хранения 18 000 компонентов на Witness. Чтобы успешно удовлетворить требования пропускной способности Witness для 18 000 компонентов на vSAN расчет будет таким:
B = 1138 Б * 8 * 18 000 / 5с = 32 774 400 бит в секунду = 32.78 Мбит/с
B + 10% = 32.78 Мбит/с + 3.28 Мбит/с = 36.05 Мбит/с
Используя общее уравнение 2 Мбит/с на каждые 1 000 компонентов, (NumComp/1000) X 2 Мбит/с, можно увидеть, что 18 000 компонентов действительно требует 36 Мбит/с.
Пропускная способность Witness для конфигураций с 2 узлами (OSA)
Пример удаленного сайта 1
Рассмотрим пример 25 ВМ в конфигурации с 2 узлами, каждая с виртуальным диском 1 ТБ, защищенные при FTT=1 и Stripe Width=1. Каждый vmdk будет состоять из 8 компонентов (vmdk и реплика) и 2 компонентов для пространства имен ВМ и swap-файла. Общее количество компонентов составляет 300 (12/ВМx25ВМ). С 300 компонентами, используя правило (300/1000 x 2 Мбит/с), требуется пропускная способность 600 кбит/с.
Пример удаленного сайта 2
Рассмотрим другой пример 100 ВМ на каждом хосте, с таким же ВМ выше, с виртуальным диском 1 ТБ, FTT=1 и SW=1. Общее количество компонентов составляет 2 400. Используя правило (2 400/1000 x 2 Мбит/с), требуется пропускная способность 4.8 Мбит/с.
Вот так и рассчитывается пропускная способность для разных рабочих нагрузок и конфигураций в среде vSAN. Понимание этих метрик и формул поможет в проектировании и развертывании решений vSAN, которые обеспечивают оптимальную производительность и надежность.
На днях компания VMware выпустила обновленную версию настольной платформы виртуализации VMware Workstation 17.5. Напомним, что летом мы писали о предварительной версии Workstation Tech Preview 2023 (функции которой и вошли в обновленную версию), а в ноябре прошлого года вышел предыдущий мажорный релиз Workstation 17.
Итак, давайте посмотрим, что нового в этом выпуске:
1. Улучшения безопасности
В этой версии повышена безопасность за счет введения улучшенной схемы шифрования (XTS вместо CBC) для максимальной защиты с уменьшенными накладными расходами на производительность. Подробнее можно узнать в KB 93071.
Этот релиз также решает проблему CVE-2023-34044. Для получения дополнительной информации о данных уязвимостях и их воздействии на продукты VMware, смотрите VMSA-2023-0022.
2. Управление виртуальными машинами с помощью команд VMRUN
Теперь вы можете управлять виртуальными машинами с помощью утилиты командной строки VMRUN в версии Workstation Pro. Вы можете использовать команды для выполнения различных операций в гостевой системе, такие как включение или выключение, создание снимков для резервного копирования данных, управление сетевыми адаптерами, запуск исполняемого файла, управление файлами и директориями, а также процессами, запущенными в ОС, и другие вещи.
3. Импорт и экспорт ВМ с устройством vTPM
Теперь вы можете импортировать или экспортировать виртуальную машину с включенным устройством vTPM с помощью OVF Tool. Вы можете экспортировать виртуальную машину с устройством vTPM в файл OVF, а затем использовать файл OVF для импорта виртуальной машины с vTPM.
4. Управление питанием зашифрованных ВМ с помощью VMREST API
Теперь вы можете включать/выключать, приостанавливать, ставить на паузу, снимать с паузы или получать состояние зашифрованной виртуальной машины с помощью сервиса VMREST API.
5. Обновление версии Virtual Hardware до 21
Поддержка до 256 устройств NVMe: до 4 контроллеров и до 64 устройств на контроллер
Поддержка NVMe 1.3 в следующих гостевых операционных системах:
Microsoft Windows 11
Microsoft Windows Server 2022
Скачать VMware Workstation 17.5 можно по этой ссылке.
24 октября компания VMware выпустила критическое уведомление о безопасности VMSA-2023-0023 (уязвимости CVE-2023-34048 и CVE-2023-34056), в котором рассматриваются обнаруженные и устраненные уязвимости безопасности в vCenter Server, которые присутствуют в продуктах VMware vSphere и Cloud Foundation.
Эти уязвимости связаны с управлением памятью и ее повреждением (Out-of-Bounds Write Vulnerability), которые могут быть использованы для удаленного выполнения кода против служб VMware vCenter Server.
Матрица реагирования на обнаруженную уязвимость для разных версий vCenter выглядит следующим образом:
На конференции Explore 2023 сотрудники VMware подробно рассказали о следующем этапе развития управления Android-устройствами - Android Management API (AMAPI). Недавно бета-версия AMAPI стала доступна для пользователей. Она поддерживает управление Android-устройствами, зарегистрированными в режиме рабочего профиля, который используется для рабочих или личных устройств.
AMAPI - это новый подход к управлению Android-устройствами уровня предприятия. AMAPI является частью Android — он встроен в ОС и разработан Google. Это открывает возможности, которые недоступны в текущем подходе к управлению платформой Android Enterprise, который называется Custom Device Policy Controller (DPC). Примером функции, доступной только в AMAPI, является недавно введенный режим потерянного устройства (Corporate Owned Personally Enabled, COPE). Вот три основных преимущества AMAPI:
Простота: Workspace ONE Unified Endpoint Management (UEM) создает желаемое состояние устройства и передает его AMAPI, который применяет его. Это упрощает процесс поддержки новых функций Android в консоли Workspace ONE UEM.
Нативность: AMAPI является частью Android и обновляется и поддерживается Google. Следовательно, лучшие практики управления устройствами встроены в AMAPI компанией Google, и это общий стек, используемый в экосистеме Android.
Возможности: AMAPI имеет дополнительные средства, чтобы гарантировать, что политики применяются к устройствам. Например, AMAPI может обеспечивать минимальные требования к сложности пароля на личных устройствах.
В чем разница между AMAPI и Custom DPC?
Сегодня Workspace ONE UEM использует подход к Android Enterprise, называемый Custom DPC. С Custom DPC решение Workspace ONE UEM распределяет политики, внутренние приложения и многое другое на Workspace ONE Intelligent Hub, который действует как основное управляющее приложение устройства или рабочего профиля. Intelligent Hub применяет эти ресурсы к устройству и возвращает информацию об устройстве в Workspace ONE UEM.
Публичные приложения — это приложения, опубликованные в управляемом Google Play Store. Для распространения и доставки публичных приложений на устройства Workspace ONE UEM использует Google Play EMM API.
Теперь давайте рассмотрим AMAPI. С AMAPI решение Workspace ONE UEM передает желаемое состояние устройства в AMAPI. Аналогично Custom DPC это определяет, какие публичные приложения AMAPI должен установить на устройство. Workspace ONE также передает, какие управляющие политики — требования к паролям, сертификаты, настройки разрешений для приложений — AMAPI должен применить. В свою очередь, AMAPI передает политики клиенту Android Device Policy (ADP), который применяет их к устройству. В AMAPI именно ADP, встроенный компонент Android, выступает в качестве основного управляющего приложения на устройстве. ADP работает на всех Android-устройствах с GMS на Android 5.1+. Обратите внимание, что Workspace ONE UEM сам определяет минимальные поддерживаемые версии ОС.
Помимо применения управляющих политик, ADP также передает информацию о состоянии устройства в AMAPI, который, в свою очередь, передает эту информацию в Workspace ONE UEM через Google Pub/Sub.
Workspace ONE Intelligent Hub остается ключевым компонентом для управления устройствами. Он обрабатывает распространение сертификатов и внутренних приложений и позволяет использовать уникальные функции, такие как предоставление продуктов и Freestyle Orchestrator. Intelligent Hub также является не только управляющим клиентом. Он предоставляет унифицированный каталог приложений VMware, пакет Mobile Threat Defense SDK, интеграцию с Intelligence для продвинутой аналитики и многое другое. Именно поэтому Intelligent Hub присутствует на всех устройствах, которыми управляются с помощью AMAPI.
AMAPI вносит несколько изменений в опыт работы администратора и конечного пользователя устройства.
В качестве администратора вы увидите два основных обновления в консоли Workspace ONE UEM:
При создании профилей Android теперь вы будете выбирать, создавать ли профили для Custom DPC или для AMAPI.
Теперь вы можете выбрать, будут ли новые устройства, регистрирующиеся в Workspace ONE UEM, управляться с использованием Custom DPC или AMAPI. Это может быть установлено по режиму (Рабочий профиль, COPE или полностью управляемый) и по организационной группе.
В качестве конечного пользователя устройства:
Помимо начала регистрации через Intelligent Hub, теперь вы можете начать регистрацию своих личных устройств, запустив URL регистрации AMAPI. Этот URL регистрации предоставляется администратором UEM и может распространяться через QR-код, текст, электронную почту, внутренний сайт или другими способами.
Когда вы устанавливаете политику, требующую взаимодействия конечного пользователя, AMAPI предпримет действия, чтобы удостовериться, что требования политики соблюдаются. Например, когда вы устанавливаете минимальные требования к паролю устройства через профили, AMAPI приостановит управляемые приложения до тех пор, пока пароль устройства не соответствует требованиям политики. AMAPI также направляет конечного пользователя на установку пароля, соответствующего политике.
AMAPI представляет будущее управления устройствами Android и добавляет много преимуществ, включая уникальные функции. VMware рекомендует организациям ознакомиться с AMAPI и применять его в соответствии с их требованиями.
Управляется ли устройство с помощью Custom DPC или AMAPI, изначально нужно будет решить в момент регистрации устройства. Организации смогут внедрить подход "ограничить и развивать" при использовании AMAPI. Не воздействуя на зарегистрированные устройства, управляемые с помощью Custom DPC, организации могут настроить Workspace ONE UEM для использования AMAPI для регистрации новых устройств. Организации могут включить AMAPI для новых регистраций для отдельных режимов управления (рабочий профиль, COPE или полностью управляемый), а также только для конкретных организационных групп.
В будущем будет предусмотрена поддержка миграции устройств с Custom DPC на AMAPI без необходимости повторной регистрации. Такая миграция будет поддерживаться для всех режимов — рабочего профиля, COPE и полностью управляемого.
Бета-версия AMAPI доступна уже сегодня. На текущий момент она поддерживает управление устройствами в режиме рабочего профиля, который используется для управления личными устройствами пользователей (BYOD). По мере развития бета-версии будет добавлена поддержка режима COPE и, позднее, режима полного управления. Для получения дополнительной информации о различных режимах управления Android Enterprise вы можете посмотреть документ "Operational Tutorial for Managing Android Devices".
Аналогично, поддержка режима рабочего профиля в AMAPI будет доступна в производственных средах в первую очередь, затем последует COPE и, в конце концов, режимы полного управления.
Компания VMware объявила о доступности обновленной версии решения Cloud Provider Lifecycle Manager 1.6 (VCPLCM). Напомним, что этот продукт предназначен для автоматизации рутинных операций жизненного цикла продуктов, для которых можно разрабатывать свои сценарии развертывания, обслуживания и списания систем, что позволяет сотрудникам сервис-провайдеров (VCPP) сосредоточиться на более высокоуровневых операциях. О версии VCPLCM 1.4 мы писали вот тут.
В предыдущей версии (VCPLCM 1.5) VMware добавила автоматическую регистрацию Usage Meter и Interop Reporting, а также улучшения в выполнении задач. В этом релизе представлено несколько нововведений с основным акцентом на:
Улучшении пользовательского опыта
Расширении поддержки продуктов и обслуживания
Давайте кратко рассмотрим, что это такое.
Улучшенный пользовательский опыт
Новая версия предоставляет больше управляющих элементов для пользователя. Появилась новая опция "Administration", которая помогает провайдерам безопасно делегировать и контролировать операции по обслуживанию и управлению соответствующим пользователям, каждый из которых входит под своими учетными данными.
Еще одним большим изменением является внедрение нового пользовательского интерфейса для регистрации продукта, что делает процесс развертывания новых продуктов в VCPLCM проще и быстрее.
Расширенная поддержка продуктов
Теперь пользователи могут регистрировать NSX Advanced Load Balancer в VCPLCM и интегрировать его с VMware Cloud Director и Usage Meter.
Пользователи теперь могут создавать резервные копии данных и обеспечивать эффективное восстановление виртуального модуля VCPLCM, минимизируя потерю данных в случае системных сбоев или серьезных ошибок.
Также появился переключатель «режим обслуживания» для компонентов продукта. Это важное нововведение, поскольку часто при обновлении продукты нужно перезапустить или остановить по разным причинам, например, при накатывании патча на узле. В этих ситуациях узел будет недоступен без уведомления оператора. Этот переключатель будет отмечать узлы как "в режиме обслуживания", чтобы пользователи знали статус продукта / компонента.
Теперь давайте рассмотрим эти функции подробнее:
1. Улучшенный пользовательский опыт
Существенно был улучшен пользовательский интерфейс и значительно упрощены операции, такие как развертывание и регистрация существующего продукта.
Также была добавлена опция, позволяющая пользователям просматривать существующие бинарные файлы в репозитории через пользовательский интерфейс и соответствующим образом развертывать/обновлять продукты.
Теперь нет необходимости заходить через ssh на устройство, чтобы проверить бинарные файлы.
2. Управление доступом на основе ролей
В версии 1.6 был введен доступ на основе ролей, и теперь пользователи могут выполнять следующие действия:
Конфигурация внешних источников аутентификации (LDAP/AD)
Определение и назначение ролей с разрешениями для различных операций
Вход в систему разными пользователями и выполнение задач, назначенных запрашивающим пользователям.
Управление пользователями:
Управление ролями и разрешениями:
3. Операции "Day-2": режим обслуживания для VMware Cloud Director
Теперь пользователи могут включать/выключать режим обслуживания для ячеек VCD.
Это полезно при выполнении любых операций с патчами или технического обслуживания ячеек VCD и для обеспечения бесперебойной работы. С этим усовершенствованным пользовательским интерфейсом можно определить состояние каждой ячейки VCD непосредственно через портал VCPLCM.
4. Резервное копирование и восстановление VCPLCM
Это долгожданная функция, так как VMware получила много запросов касательно функции резервного копирования и восстановления виртуального модуля VCPLCM.
Теперь пользователи могут создавать резервные копии и восстанавливать устройства VCPLCM той же версии, причем файл резервной копии защищен паролем, который пользователи должны задать при создании резервной копии.
Ниже перечислены компоненты, которые можно восстановить с использованием файла резервной копии:
Развернутые/зарегистрированные продукты
Зарегистрированные компоненты инфраструктуры
Последние задачи и журналы
Источники аутентификации, роли и пользователи
Содержимое хранилища (закрытые данные, такие как пароли и ключи)
Сертификаты и ключи для устройства VCP LCM
Однако бинарные файлы продукта внутри папки /cplemrepo виртуального модуля не будут резервно копироваться, и их придется резервно копировать вручную.
Вот так выглядит защита паролем:
Вот так восстановление:
5. Регистрация NSXALB с VCD и Usage Meter
Теперь вы можете регистрировать NSX ALB как компонент инфраструктуры и интегрировать его с VMware Cloud Director и Usage Meter. Эта интеграция может быть выполнена при развертывании VMware Cloud Director и Usage Meter.
6. Улучшения API
REST API VCPLCM обновлен до версии 4
Версии 1, 2 и 3 API по-прежнему доступны, но рекомендуется использовать версию 4
Дополнительные операции API для перезапуска, возобновления работы и отката задач.
Дополнительная операция API для получения полезной нагрузки запроса задачи, создания отчета о совместимости и архивации/чтения уведомлений
CLI и GUI используют v4. Однако CLI также имеет возможность работать со старыми версиями API (необходимо указать их явно)
Обновленная коллекция Postman с соответствующими образцами полезной нагрузки для обеих версий API доступна здесь.
Полный список нововведений VMware Cloud Provider Lifecycle Manager 1.6 приведен в Release Notes.
Сегодня мы поговорим о новой функциональности релиза 2306 (первые две цифры - это год, а оставшиеся - месяц релиза). Давайте посмотрим, что теперь нового в Horizon 8:
1. Гранулированные привилегии RBAC для клиентов, подключенных к облаку
В версиях Horizon 8 до 2306 для доступа к службам управления и мониторинга развертываний Horizon суперадминам требовалось активировать свою SaaS-подписку через Horizon Control Plane. Теперь, начиная с Horizon 2306, появились более детализированные привилегии на основе ролевого управления доступом (RBAC), которые позволяют суперадмину предоставлять гранулированные привилегии не-суперадминам, позволяя им активировать и управлять лицензиями, а также мониторить среду Horizon. Применяя специфические привилегии для админов, эта функция исключает необходимость ролей суперадмина для рутинных задач, при этом обеспечивая более строгую безопасность и гарантируя, что значительные изменения могут вносить только авторизованные сотрудники.
2. Блокировка подключения конечного пользователя, если нет проверки сертификата
Безопасность всегда на первом месте в разработке Horizon. С этой целью мы ввели новый механизм, который может обеспечивать проверку сертификата сервера. Как только настройка сконфигурирована, когда запрос конечного пользователя к десктопу или приложению доходит до connection server, запрос будет иметь уже настроенные параметры клиента, а не настройки, сконфигурированные администратором на сервере.
Управление соединениями определяется на основе конфигурации. Теперь есть три потенциальных действия — «Применить», «Предупредить» и «Игнорировать» — которые администраторы могут использовать для обеспечения более строгих политик проверки сертификатов:
Применить (Enforce): Обязательная проверка сертификата. Если он недействителен, соединение разрывается.
Предупредить (Warn): Пользователь получает предупреждение, ему разрешено подключиться, и событие регистрируется.
Игнорировать (Ignore): Проверка сертификата выполняется, но создается только запись в журнале без уведомления пользователя.
Эта функция обеспечивает баланс между удобством использования и безопасностью, давая администраторам гибкость в определении строгости своего процесса аутентификации.
3. Фиксированный таймер для отмены учетных данных SSO, усиливающий безопасность
Клиенты могут установить фиксированный таймер для отмены учетных данных единого входа (SSO), чтобы гарантировать, что после определенного времени потребуется повторная аутентификация, что дополнительно усиливает безопасность. Администраторы могут устанавливать время сессии для конечных пользователей и гарантировать, что они проходят повторную аутентификацию при запуске новых сессий виртуальных рабочих столов или опубликованных приложений.
4. Настройка сопоставлений сертификатов из консоли
Для тех клиентов, которые используют аутентификацию на основе сертификата, такую как смарт-карты, обновление безопасности Microsoft (KB5014754) запретит слабые сопоставления сертификатов, такие как имя пользователя и электронная почта. Horizon 2306 позволяет настраивать сопоставления сертификатов из консоли Horizon. Эта функция предоставляет три варианта на выбор:
SID, который считается самым надежным и рекомендуется
Пользовательская альтернативная безопасная идентичность, такая как x509serialnumber, x509SKI.
Устаревший вариант, для клиентов, которые не применяли обновление безопасности и продолжают использовать существующие смарт-карты.
5. Режим Instant Clone Smart Provisioning по умолчанию
Теперь Instant Clone Smart Provisioning по умолчанию использует режим Mode B (ВМ создается без родительской ВМ). Режим Mode B совместим со всеми рабочими процессами, такими как vTPM и vGPU. Режим Mode A (ВМ создается с родительской ВМ) выбирается только при использовании устройства vTPM на версии хоста ESXi ранее чем 7.0 обновление 3f. Вы все равно сможете изменить режим предоставления, но делать этого не рекомендуется.
6. Улучшение с авто-отладкой для мгновенных клонов
Автоматический режим отладки позволяет администраторам сохранять внутренние шаблоны ВМ для отладки в случае ошибок при развертывании. Ранее администраторам приходилось устанавливать параметр конфигурации для золотого образа в vCenter, чтобы включить этот режим. С этой функцией администраторы могут включать режим отладки из консоли, который применяется ко всем пулам мгновенных клонов (Instant Clones) в vCenter. Когда режим включен, внутренние шаблоны ВМ сохраняются в отдельной папке в vCenter, и эти ВМ автоматически удаляются, когда этот режим выключен. Рекомендуется включить настройку "Stop Provisioning on Error", чтобы развертывание останавливалось при первой ошибке, и эту конкретную ошибку можно было идентифицировать и отладить.
7. Постоянные диски для мгновенных клонов
Horizon 2306 вновь представляет persistent-диски для выделенных (dedicated) мгновенных клонов, предназначенные для клиентов, которые все еще их используют в Horizon 7. Эта новая функция предоставляет путь миграции для клиентов, которые не могут обновиться до Horizon 8 из-за постоянных дисков. Для получения дополнительной информации о миграции прочтите документ "Руководство по миграции для перехода с Horizon 7.X на Horizon 8".
8. Распределение сессий в архитектуре Cloud Pod
Чтобы помочь архитектуре Cloud Pod Architecture (CPA) равномерно распределять сессии пользователей по ресурсам в рамках глобального назначения, релиз 2306 вводит "Политику распределения нагрузки сессий" (Session Load Distribution Policy). Эта новая настройка позволяет администраторам выбирать методику подсчета сессий для установки политики распределения нагрузки сессий на основе глобального индивидуального назначения. С ее помощью CPA будет справедливо распределять входящие запросы сессий по ресурсам на основе подсчета сессий в отношении к емкости, обеспечивая более сбалансированное распределение по доступным ресурсам. Например, если глобальный entitlement имеет два пула рабочих столов, каждый с емкостью 100 рабочих столов, сессии будут равномерно распределяться по пулам для лучшей производительности рабочих столов и приложений.
Полную информацию обо всех нововведениях и улучшениях Horizon 8 релиз 2306 можно получить из Release Notes. Скачать компоненты решения можно по этой ссылке.
Летом этого года вышла новая версия решения для виртуализации и доставки настольных ПК и приложений VMware Horizon 8 (2306). Сегодня мы расскажем о новых функциях клиентах Horizon Clients, которые работают на разных платформах. О новой функциональности агентов Horizon Agents вы можете узнать в этой статье.
1. Новые возможности клиента Horizon Client for Windows
ОС Windows продолжает развиваться, идя в ногу с эволюцией потребительских потребностей и технологическими изменениями. Ниже приведены новые функции, которые улучшают клиентский опыт в Windows для клиента Horizon 2306:
Поддержка устройств ARM с режимом эмуляции: Windows теперь официально поддерживает устройства ARM, работающие в режиме эмуляции. Эта поддержка эксклюзивна для Windows 11, так как это оптимальная ОС для устройств ARM, повышающая их производительность и удобство использования.
Бесшовное сопряжение Bluetooth: с функциями улучшенной связности пользователи теперь могут сопрягать устройства Bluetooth даже после запуска виртуальной машины. Нет необходимости возвращаться к физическому устройству, устройства можно найти и сопрягать непосредственно в удаленном рабочем столе.
Видимые пароли через GPO. Horizon 2306 представляет новую политику группы для решения проблем со сложными требованиями к паролям. Это позволяет пользователям видеть свой пароль при наборе, что помогает пользователям со комплексными критериями пароля.
Аутентификация WebAuthN (FIDO2) для разрешенных приложений. В контексте FIDO2 в основном акцент делается на поддержку YubiKey. Пользователи перенаправляли YubiKey как USB-устройства для аутентификации в виртуальной машине. Однако перенаправление YubiKey таким образом ограничивает его доступность на конечном устройстве. Признавая необходимость более гладкого пользовательского опыта, особенно для тех, кто использует разнообразные приложения, теперь вызовы WebAuthN перенаправляются из виртуальной машины. WebAuthN используется широким кругом веб-сайтов и многими приложениями Windows. Хотя не все приложения поддерживаются, эта функция упрощает процесс для большинства из них, уменьшая необходимость полного перенаправления YubiKey через перенаправление USB.
2. Новые возможности клиента Horizon Client for Linux
Horizon 2306 предлагает новые улучшения для клиента Linux, обеспечивая большую гибкость и удобство для пользователя. Вот, что тут нового:
Интеграция пакета установки Deb с основными функциями RX. Релиз 2306 представляет опцию пакета установки Deb, которая облегчает управление Linux, особенно если вы используете инструмент управления, предназначенный для глубокого анализа.
Поддержка декодирования AOMedia Video 1 (AV1). Клиент Linux теперь поддерживает кодек AV1, улучшая возможности декодирования для ассоциированных типов файлов.
Ассоциация типов файлов. Функции зеркалирования доступны для пользователей Windows и Mac. Linux теперь позволяет сопоставлять типы файлов с удаленными приложениями. Это обеспечивает более плавный пользовательский опыт при удаленном доступе к различным типам файлов.
TrueSSO разблокировано для клиентов Linux. В средах, использующих TrueSSO, когда виртуальная машина переходит в режим сна, всплывающее окно спрашивает, требует ли виртуальная машина разблокировки сейчас, что запустит поток аутентификации TrueSSO.
Перенаправление диска в nested-режиме. Клиент Linux теперь поддерживает перенаправление диска во вложенном режиме и для Linux, и для Windows. В сценариях с двойным переходом, начиная с Linux или Windows и переходя к виртуальной машине Windows, пользователи могут пересылать свой диск на следующее назначение (то есть, скорее всего, другой интерфейс Windows).
3. Новые возможности клиента Horizon Client for Mac
Последний релиз этого клиента предоставляет функции для улучшения пользовательского опыта и оптимизации рабочих процессов для пользователей, использующих клиенты Mac в 2306. Вот краткий обзор нововведений:
Упрощенное создание снимков экрана в Teams. Теперь есть функция, которая упрощает процесс создания скриншотов в Teams.
Бесшовная интеграция с Zoom и Cisco. На базе того, что было сделано для Windows, пользователи Mac теперь могут размещать плагины Zoom или Webex на UAG. При первом подключении клиент Mac загрузит плагин и получит запрос на установку, который будет доступен впредь.
Изменение файла установки с .dmg на .pkg. Процесс установки для клиента Mac перешел от формата файла .dmg к .pkg. Это изменение вводит единый интерфейс для установки, отходя от предыдущего метода установки путем перетаскивания.
Расширенная информация о Wi-Fi с DEEM. Интегрируя модуль DEEM (управление цифровым опытом сотрудника), пользователи Mac теперь могут собирать данные о силе сигнала Wi-Fi. Эти данные интегрируются с функцией Intelligence, что является значительным шагом для пользователей, использующих Workspace ONE Intelligence для проверки телеметрии, и теперь есть возможность коррекции при необходимости.
Специфичные для производителя функции сканеров. Сканеры, подключенные к Mac, могут предлагать функции, которых нет в спецификациях TWAIN. Обновление 2306 позволяет виртуальной машине захватывать эти настройки и отображать их в интерфейсе сканера в виртуальной машине.
TrueSSO разблокировано для клиента Mac. Аналогично клиенту Windows, пользователи Mac теперь могут повторно активировать аутентификацию TrueSSO, когда виртуальная машина переходит в режим сна, обеспечивая непрерывный доступ и работу.
4. Новые возможности клиента Horizon Client for Chrome
В версии 2306 включены функции, которые улучшают взаимодействие конечного пользователя с использованием клиентов Chrome на виртуальном рабочем столе и улучшают подключение.
Поддержка следующего поколения Horizon Cloud. Horizon Cloud следующего поколения использует обновленный, современный поток аутентификации. В этом релизе все клиенты Horizon теперь полностью интегрированы и поддерживаются на этой платформе, что является значительным шагом вперед.
Предупреждение о плохом соединении. После появления предупреждения о плохом соединении для Windows эта функция была добавлена и для клиента Chrome, и для HTML Access. Теперь пользователи могут быстро получать уведомления о проблемах с подключением, что обеспечивает более плавную работу.
Разделение композитных USB-устройств для перенаправления. 2306 добавляет поддержку композитных USB-устройств. Это особенно полезно для многофункциональных устройств, таких как Nuance PowerMic или клавиатуры, оснащенной считывателем кредитных карт. Такие устройства, хотя и регистрируются как единое USB-устройство, имеют несколько функциональных компонентов. С обновлением до 2306 пользователи могут полностью использовать эти композитные устройства.
Улучшения производительности аудио-видео в реальном времени. Мы интегрировали улучшения производительности для аудио-видео взаимодействий в реальном времени. Используя кодек H.264, возможно сжатие как видео, так и аудио на конечном устройстве.
Летом этого года вышла новая версия решения для виртуализации и доставки настольных ПК и приложений VMware Horizon 8 (2306). Сегодня мы посмотрим детальнее на новую функциональность агентов, которые работают в виртуальных десктопах.
VMware продолжает стремиться к бесшовной совместимости и функциональности на разных платформах, обеспечивая более гладкий пользовательский опыт для всех пользователей.
1. Улучшения для агента Linux
На основе существующей поддержки Rocky на vSphere, Horizon 2306 добавляет поддержку Rocky Linux. Кроме того, была добавлена поддержка записи рабочего стола Horizon для машин Linux, что позволяет администраторам записывать и воспроизводить сессии для устранения проблем, обеспечения соблюдения требований комплаенса и безопасности, а также в целях мониторинга активности пользователей. Также для функции виртуальной интегрированной печати теперь можно добавить водяной знак на первую страницу для целого набора документов.
2. Улучшения в поддержке кодеков Blast
Разрешение функции BSG RX. С Blast Secure Gateway Remote Experience был представлен "список разрешений" для конкретных функций. Некоторые клиенты предоставляют доступ администратора конечным пользователям, поэтому традиционные GPO и настройки реестра могут быть недостаточными. Для улучшенной защиты администраторы теперь могут ограничивать определенные функции на самом UAG, например, перенаправление USB, в случае, если у них есть опасения по поводу безопасности конкретной функции, и таким образом предотвращать потенциально опасные действия от разрешения несанкционированных функций на уровне агента.
Улучшения кодека AV1. Была добавлена поддержка аппаратного кодирования для кодека AV1 на GPU NVIDIA. Кроме того, была расширена поддержка клиентов Linux для использования этого кодека.
Улучшения синхронизации аудио и видео для Mac. После улучшения синхронизации аудио и видео на клиентах Windows эти же улучшения были сделаны и для клиентов Mac.
Поддержка 3D-оборудования для Linux VDI. Теперь те, кто запускает агент Linux на физических рабочих станциях, могут использовать все возможности 3D-ускорения в этих рабочих столах.
Улучшенная поддержка Mac и Linux. VMware добавила всеобъемлющую информацию для ведения журнала, чтобы облегчить устранение неполадок Blast, также уменьшена частота возникновения черных экранов. Это улучшение доступно как для клиентов Mac, так и для Linux.
Высокое разрешение и высокий динамический диапазон для кодека HEVC. Релиз 2306 расширяет поддержку, включая высокое разрешение цветности и высокий динамический диапазон для кодеков HEVC, доступных для клиентов Windows, Mac и Linux. Кроме того, это делает доступным кодирование HEVC 4:4:4 на GPU Intel, обеспечивая более высокую точность цвета при отображении изображений.
3. Оптимизации унифицированных коммуникаций
Вот краткий обзор последних обновлений релиза 2306, которые улучшают опыт совместной удаленной работы:
Одновременная трансляция для улучшенного качества в Microsoft Teams. В прошлом общее качество видео для группового вызова Teams могло ухудшиться, если один из участников присоединился из плохой сети. Теперь с функцией simulcast поток каждого участника независим от сетей других пользователей, подключенных к вызову. Это означает, что качество всей группы больше не будет страдать, что улучшает пользовательский опыт.
Клиент Mac с функцией размытия фона Teams. Теперь конечные пользователи, присоединяющиеся к видеовызову Teams на своих рабочих столах Horizon с MacBook, могут размывать свой фон, обеспечивая полную функциональность при использовании видео в Teams.
Вырезка экрана в Teams для клиента Mac. Теперь клиент Mac поддерживает вырезку экрана или скриншоты. Если вы сталкивались с ситуацией, когда ваш VDI-десктоп работает в полноэкранном режиме с вызовом Teams, это могло создать черное пустое пространство при попытке сделать скриншот в ВМ. Чтобы бороться с этим, снимок экрана будет сделан на конечном устройстве сначала, а затем уже сохранен в ВМ.
Разделение на комнаты в Teams. Теперь конечные пользователи могут создавать отдельные комнаты в Teams, оптимизированные для Horizon.
Реакции в Teams. Конечные пользователи смогут отправлять эмодзи и другие реакции во время вызова Teams.
Полный список новых возможностей VMware Horizon 8 (2306) можно узнать тут. Скачать компоненты решения можно по этой ссылке. Скоро мы расскажем и о других нововведениях платформы.
RSS
