Администраторы платформы виртуализации VMware vSphere в рамках ежедневной рутины занимаются процессами обновлений виртуальной инфраструктуры и ее компонентов путем накатывания патчей или проведения апгрейдов (в том числе наиболее сложных - на новые мажорные версии). Наиболее удобный способ делать это - использовать решение vSphere Lifecycle Manager (vLCM), который автоматизирует этот процесс. Это следующее поколение продукта vSphere Update Manager (VUM), который ранее использовался для планирования и накатывания обновлений...
Напомним, что в конце прошлого года в решении 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 можно получить по этой ссылке.
В этом выпуске было объявлено о расширении плагин-ориентированного фреймворка для поддержки облачных ресурсов 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.
Распределенная архитектура 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.
С будущим крупным выпуском 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.
RSS
