Новости Статьи VMware Veeam StarWind vStack Microsoft Nakivo Citrix Symantec События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Все самое нужное о виртуализации и облаках

Более 6180 заметок о VMware, AWS, Azure, Veeam, Kubernetes и других

VM Guru | Ссылка дня: Какие есть версии и номера билдов VMware vCenter, ESXi, Tools и Connection Server?

VMware vSphere 8 Update 3 Core Storage - что нового?


Вчера мы писали о новых возможностях последнего пакета обновлений VMware vSphere 8.0 Update 3, а сегодня расскажем что нового появилось в плане основных функций хранилищ (Core Storage).

Каждое обновление vSphere 8 добавляет множество возможностей для повышения масштабируемости, устойчивости и производительности. В vSphere 8 Update 3 продолжили улучшать и дорабатывать технологию vVols, добавляя новые функции.

Продолжая основной инженерный фокус на vVols и NVMe-oF, VMware также обеспечивает их поддержку в VMware Cloud Foundation. Некоторые функции включают дополнительную поддержку кластеризации MS WSFC на vVols и NVMe-oF, улучшения по возврату свободного пространства (Space Reclamation), а также оптимизации для VMFS и NFS.

Ключевые улучшения

  • Поддержка растянутых кластеров хранилищ (Stretched Clusters) для vVols
  • Новая спецификация vVols VASA 6
  • Кластеризация VMDK для NVMe/TCP
  • Ограничение максимального количества хостов, выполняющих Unmap
  • Поддержка NFS 4.1 Port Binding и nConnect
  • Дополнительная поддержка CNS/CSI для vSAN

vVols

Поддержка растянутого кластера хранилища vVols на SCSI

Растянутый кластер хранения vVols (vVols-SSC) был одной из самых запрашиваемых функций для vVols в течение многих лет, особенно в Европе. В vSphere 8 U3 добавлена поддержка растянутого хранилища vVols только на SCSI (FC или iSCSI). Первоначально Pure Storage, который был партнером по дизайну этой функции, будет поддерживать vVols-SSC, но многие из партнеров VMware по хранению также активно работают над добавлением данной поддержки.

Почему это заняло так много времени?

Одна из причин, почему реализация vVols-SSC заняла столько времени, заключается в дополнительных улучшениях, необходимых для защиты компонентов виртуальных машин (VMCP). Когда используется растянутое хранилище, необходимо наличие процесса для обработки событий хранения, таких как Permanent Device Loss (PDL) или All Paths Down (APD). VMCP — это функция высокой доступности (HA) vSphere, которая обнаруживает сбои хранения виртуальных машин и обеспечивает автоматическое восстановление затронутых виртуальных машин.

Сценарии отказа и восстановления

  • Контейнер/datastore vVols становится недоступным. Контейнер/datastore vVols становится недоступным, если либо все пути данных (к PE), либо все пути управления (доступ к VP, предоставляющим этот контейнер) становятся недоступными, либо если все пути VASA Provider, сообщающие о растянутом контейнере, отмечают его как UNAVAILABLE (новое состояние, которое VP может сообщить для растянутых контейнеров).
  • PE контейнера vVols может стать недоступным. Если PE для контейнера переходит в состояние PDL, то контейнер также переходит в состояние PDL. В этот момент VMCP будет отвечать за остановку виртуальных машин на затронутых хостах и их перезапуск на других хостах, где контейнер доступен.
  • Контейнер или PE vVols становится доступным снова или восстанавливается подключение к VP. Контейнер вернется в доступное состояние из состояния APD, как только хотя бы один VP и один PE станут доступны снова. Контейнер вернется в доступное состояние из состояния PDL только после того, как все виртуальные машины, использующие контейнеры, будут выключены, и все клиенты, имеющие открытые файловые дескрипторы к хранилищу данных vVols, закроют их.

Поведение растянутого контейнера/хранилища данных довольно похоже на VMFS, и выход из состояния PDL требует уничтожения PE, что может произойти только после освобождения всех vVols, связанных с PE. Точно так же, как VMFS (или устройство PSA) не может выйти из состояния PDL, пока все клиенты тома VMFS (или устройства PSA) не закроют свои дескрипторы.

Требования

  • Хранилище SCSI (FC или iSCSI)
  • Макс. время отклика между хостами vSphere — 11 мс
  • Макс. время отклика массива хранения — 11 мс
  • Выделенная пропускная способность сети vSphere vMotion — 250 Мбит/с
  • Один vCenter (vCenter HA не поддерживается с vVols)
  • Контроль ввода-вывода хранения не поддерживается на datastore с включенным vVol-SSC

Дополнительная поддержка UNMAP

Начиная с vSphere 8.0 U1, config-vvol теперь создается с 255 ГБ VMFS vVol вместо 4 ГБ. Это добавило необходимость в возврате свободного пространства в config-vvol. В 8.0 U3 VMware добавила поддержку как ручного (CLI), так и автоматического UNMAP для config-vvol для SCSI и NVMe.

Это гарантирует, что при записи и удалении данных в config-vvol обеспечивается оптимизация пространства для новых записей. Начиная с vSphere 8.0 U3, также поддерживается команда Unmap для хранилищ данных NVMe-oF, а поддержка UNMAP для томов SCSI была добавлена в предыдущем релизе.

Возврат пространства в хранилищах виртуальных томов vSphere описан тут.

Кликните на картинку, чтобы посмотреть анимацию:

Поддержка кластеризации приложений на NVMe-oF vVols

В vSphere 8.0 U3 VMware расширила поддержку общих дисков MS WSFC до NVMe/TCP и NVMe/FC на основе vVols. Также добавили поддержку виртуального NVMe (vNVME) контроллера для гостевых кластерных решений, таких как MS WSFC.

Эти функции были ограничены SCSI на vVols для MS WSFC, но Oracle RAC multi-writer поддерживал как SCSI, так и NVMe-oF. В vSphere 8.0 U3 расширили поддержку общих дисков MS WSFC до vVols на базе NVMe/TCP и NVMe/FC. Также была добавлена поддержка виртуального NVMe (vNVME) контроллера виртуальной машины в качестве фронтенда для кластерных решений, таких как MS WSFC. Обратите внимание, что контроллер vNVMe в качестве фронтенда для MS WSFC в настоящее время поддерживается только с NVMe в качестве бэкенда.

Обновление отчетности по аутентификации хостов для VASA Provider

Иногда при настройке Storage Provider для vVols некоторые хосты могут не пройти аутентификацию, и это может быть сложно диагностировать. В версии 8.0 U3 VMware добавила возможность для vCenter уведомлять пользователей о сбоях аутентификации конкретных хостов с VASA провайдером и предоставили механизм для повторной аутентификации хостов в интерфейсе vCenter. Это упрощает обнаружение и решение проблем аутентификации Storage Provider.

Гранулярность хостов Storage Provider для vVols

С выходом vSphere 8 U3 была добавлена дополнительная информация о хостах для Storage Provider vVols и сертификатах. Это предоставляет клиентам и службе поддержки дополнительные детали о vVols при устранении неполадок.

NVMe-oF

Поддержка NVMe резервирования для кластерного VMDK с NVMe/TCP

В vSphere 8.0 U3 была расширена поддержка гостевой кластеризации до NVMe/TCP (первоначально поддерживалась только NVMe/FC). Это предоставляет клиентам больше возможностей при использовании NVMe-oF и желании перенести приложения для гостевой кластеризации, такие как MS WSFC и Oracle RAC, на хранилища данных NVMe-oF.

Поддержка NVMe Cross Namespace Copy

В предыдущих версиях функция VAAI, аппаратно ускоренное копирование (XCOPY), поддерживалась для SCSI, но не для NVMe-oF. Это означало, что копирование между пространствами имен NVMe использовало ресурсы хоста для передачи данных. С выпуском vSphere 8.0 U3 теперь доступна функция Cross Namespace Copy для NVMe-oF для поддерживаемых массивов. Применение здесь такое же, как и для SCSI XCOPY между логическими единицами/пространствами имен. Передачи данных, такие как копирование/клонирование дисков или виртуальных машин, теперь могут работать значительно быстрее. Эта возможность переносит функции передачи данных на массив, что, в свою очередь, снижает нагрузку на хост.

Кликните на картинку, чтобы посмотреть анимацию:

VMFS

Сокращение времени на расширение EZT дисков на VMFS

В vSphere 8.0 U3 был реализован новый API для VMFS, чтобы ускорить расширение блоков на диске VMFS, пока диск используется. Этот API может работать до 10 раз быстрее, чем существующие методы, при использовании горячего расширения диска EZT на VMFS.

Виртуальные диски на VMFS имеют тип аллокации, который определяет, как резервируется основное хранилище: Thin (тонкое), Lazy Zeroed Thick (толстое с занулением по мере обращения) или Eager Zeroed Thick (толстое с предварительным занулением). EZT обычно выбирается на VMFS для повышения производительности во время выполнения, поскольку все блоки полностью выделяются и зануляются при создании диска. Если пользователь ранее выбрал тонкое выделение диска и хотел преобразовать его в EZT, этот процесс был медленным. Новый API позволяет значительно это ускорить.

Кликните на картинку для просмотра анимации:

Ограничение количества хостов vSphere, отправляющих UNMAP на VMFS datastore

В vSphere 8.0 U2 VMware добавила возможность ограничить скорость UNMAP до 10 МБ/с с 25 МБ/с. Это предназначено для клиентов с высоким уровнем изменений или массовыми отключениями питания, чтобы помочь уменьшить влияние возврата пространства на массив.

Кликните на картинку для просмотра анимации:

По умолчанию все хосты в кластере, до 128 хостов, могут отправлять UNMAP. В версии 8.0 U3 добавлен новый параметр для расширенного возврата пространства, называемый Reclaim Max Hosts. Этот параметр может быть установлен в значение от 1 до 128 и является настройкой для каждого хранилища данных. Чтобы изменить эту настройку, используйте ESXCLI. Алгоритм работает таким образом, что после установки нового значения количество хостов, отправляющих UNMAP одновременно, ограничивается этим числом. Например, если установить максимальное значение 10, в кластере из 50 хостов только 10 будут отправлять UNMAP на хранилище данных одновременно. Если другие хосты нуждаются в возврате пространства, то, как только один из 10 завершит операцию, слот освободится для следующего хоста.

См. статью Space Reclamation on vSphere VMFS Datastores.

Пример использования : esxcli storage vmfs reclaim config set -l <Datastore> -n <number_of_hosts>

Вот пример изменения максимального числа хостов, отправляющих UNMAP одновременно:

 

PSA

Поддержка уведомлений о производительности Fabric (FPIN, ошибки связи, перегрузка)

VMware добавила поддержку Fabric Performance Impact Notification (FPIN) в vSphere 8.0 U3. С помощью FPIN слой инфраструктуры vSphere теперь может обрабатывать уведомления от SAN-коммутаторов или целевых хранилищ о падении производительности каналов SAN, чтобы использовать исправные пути к устройствам хранения. Он может уведомлять хосты о перегрузке каналов и ошибках. FPIN — это отраслевой стандарт, который предоставляет средства для уведомления устройств о проблемах с соединением.

Вы можете использовать команду esxcli storage FPIN info set -e= <true/false>, чтобы активировать или деактивировать уведомления FPIN.

Кликните на картинку, чтобы посмотреть анимацию:

NFS

Привязка порта NFS v4.1 к vmk

Эта функция добавляет возможность байндинга соединения NFS v4.1 к определенному vmknic для обеспечения изоляции пути. При использовании многопутевой конфигурации можно задать несколько vmknic. Это обеспечивает изоляцию пути и помогает повысить безопасность, направляя трафик NFS через указанную подсеть/VLAN и гарантируя, что трафик NFS не использует сеть управления или другие vmknic. Поддержка NFS v3 была добавлена еще в vSphere 8.0 U1. В настоящее время эта функция поддерживается только с использованием интерфейса esxcli и может использоваться совместно с nConnect.

См. статью "Настройка привязки VMkernel для хранилища данных NFS 4.1 на хосте ESXi".

Поддержка nConnect для NFS v4.1

Начиная с версии 8.0 U3, добавлена поддержка nConnect для хранилищ данных NFS v4.1. nConnect предоставляет несколько соединений, используя один IP-адрес в сессии, таким образом расширяя функциональность агрегации сессий для этого IP. С этой функцией многопутевая конфигурация и nConnect могут сосуществовать. Клиенты могут настроить хранилища данных с несколькими IP-адресами для одного сервера, а также с несколькими соединениями с одним IP-адресом. В настоящее время максимальное количество соединений ограничено 8, значение по умолчанию — 1. Текущие версии реализаций vSphere NFSv4.1 создают одно соединение TCP/IP от каждого хоста к каждому хранилищу данных. Возможность добавления нескольких соединений на IP может значительно увеличить производительность.

При добавлении нового хранилища данных NFSv4.1, количество соединений можно указать во время монтирования, используя команду:

esxcli storage nfs41 add -H <host> -v <volume-label> -s <remote_share> -c <number_of_connections>

Максимальное количество соединений на сессию по умолчанию ограничено "4", однако его можно увеличить до "8" с помощью продвинутого параметра NFS:

esxcfg-advcfg -s 8 /NFS41/MaxNConnectConns
esxcfg-advcfg -g /NFS41/MaxNConnectConns

Общее количество соединений, используемых для всех смонтированных хранилищ данных NFSv4.1, ограничено 256.

Для существующего хранилища данных NFSv4.1, количество соединений можно увеличить или уменьшить во время выполнения, используя следующую команду:

esxcli storage nfs41 param set -v <volume-label> -c <number_of_connections>

Это не влияет на многопутевую конфигурацию. NFSv4.1 nConnect и многопутевые соединения могут сосуществовать. Количество соединений создается для каждого из многопутевых IP.

esxcli storage nfs41 add -H <IP1,IP2> -v <volume-label> -s <remote_share> -c <number_of_connections>

Кликните на картинку, чтобы посмотреть анимацию:

CNS/CSI

Поддержка 250 файловых томов для vSAN ESA

В настоящее время CNS поддерживает только 100 файловых томов. В vSphere 8.0 U3 этот лимит увеличен до 250 томов. Это поможет масштабированию для клиентов, которым требуется больше файловых хранилищ для постоянных томов (PVs) или постоянных запросов томов (PVCs) в Kubernetes (K8s).

Поддержка файловых томов в топологии HCI Mesh в одном vCenter

Добавлена поддержка файловых томов в топологии HCI Mesh в пределах одного vCenter.

Поддержка CNS на TKGs на растянутом кластере vSAN

Появилась поддержка растянутого кластера vSAN для TKGs для обеспечения высокой доступности.

Миграция PV между несвязанными datastore в одном VC

Возможность перемещать постоянный том (PV), как присоединённый, так и отсоединённый, с одного vSAN на другой vSAN, где нет общего хоста. Примером этого может быть перемещение рабочей нагрузки Kubernetes (K8s) из кластера vSAN OSA в кластер vSAN ESA.

Поддержка CNS на vSAN Max

Появилась поддержка развертывания CSI томов для vSAN Max при использовании vSphere Container Storage Plug-in.


Таги: VMware, vSphere, Storage, Update, VVols, ESXi, VMFS, NFS

Новые возможности VMware Cloud Director Object Storage Extension 3.0


Продолжаем рассказывать о возможностях решения VMware Cloud Director Object Storage Extension, которое предназначено для поддержки хранилищ S3 в инфраструктуре сервис-провайдеров, которые работают на базе VMware Cloud Director. О версии 2.1.1 этого продукта мы писали вот тут, а сегодня расскажем про версию Cloud Director Object Storage Extension 3.0, которая вышла недавно.

В этом выпуске VMware продолжает улучшать свои облачные инфраструктурные решения Cloud Director, предоставляя провайдерам больше гибкости, улучшенной доступности, масштабируемости и эффективности. Давайте подробно рассмотрим, что нового в этом релизе.

1. Установка VMware Cloud Director Add-on

Ключевым нововведением в версии 3.0 является упрощенный процесс установки VMware Cloud Director Object Storage Extension. Эта функция расширила доступность решения для провайдеров, поскольку администраторы теперь могут удобно устанавливать, обновлять и удалять расширения напрямую из пользовательского интерфейса аддонов VMware Cloud Director. Облачные провайдеры могут обеспечить более плавную работу с задачами в результате этого обновления.

Будучи установленным в качестве аддона решение работает как контейнерное приложение в среде Kubernetes. Облачные провайдеры могут развертывать расширение на мультиоблачный кластер Tanzu Kubernetes Grid или на кластер Kubernetes, соответствующий стандартам CNCF, за пределами VMware Cloud Director. Это улучшение предлагает гибкость и простую интеграцию с различными конфигурациями инфраструктуры, расширяя возможности развертывания для облачных провайдеров. Кроме того, интеграция с Tanzu Kubernetes Grid приносит дополнительные преимущества, например оптимизированную работу через стандартные пакеты, такие как Contour для балансировки нагрузки сервиса, Cert-manager для управления сертификатами TLS и метрики сервиса Grafana.

2. Конфигурация развертывания Day-2 через пользовательский интерфейс

Администраторы облачных провайдеров теперь имеют расширенное управление конфигурацией объектного хранилища напрямую из портала провайдера VMware Cloud Director. Задачи, такие как установка количества реплик, управление сертификатами TLS, подключение к базам данных, настройка платформ хранения и другие, могут быть запущены через пользовательский интерфейс. Эти улучшения пользовательского интерфейса упрощают процесс конфигурации, делая его более интуитивным и эффективным для администраторов.

3. Интеграция VMware Cloud Director с решениями для данных

Версия 3.0 представляет интуитивную интеграцию с экземплярами VMware Postgres из Solutions organization, что позволяет администраторам провайдера назначать их в качестве базы данных для Object Storage Extension. Эта интеграция упрощает задачи управления базами данных и повышает общую эффективность продукта.

4. Накатываемые обновления

С установкой дополнений, расширение объектного хранилища Cloud Director теперь поддерживает постепенные обновления, гарантируя, что изменения конфигурации автоматически проверяются и применяются. Администраторы облачных провайдеров могут легко масштабировать расширение вверх или вниз напрямую из портала провайдера Cloud Director, что является еще одной функцией, улучшающей операционную гибкость.

5. Улучшения для S3 и OSIS

Версия 3.0 принесла значительные улучшения в плане поддержки S3, включая возможность возврата ARN для арендаторов и улучшенный пользовательский опыт для защиты кластера Kubernetes. Кроме того, интерфейс Object Storage Interoperability Services (OSIS) был улучшен для адаптации к различным поставщикам хранилищ, что улучшило совместимость и взаимодействие.

6. Обновленная матрица поддержки

Версия 3.0 вводит обновленную матрицу поддержки, сертифицируя новые версии продуктов, включая VMware Cloud Director, VMware Cloud Director Container Service Extension и различные платформы хранения. Это обеспечивает совместимость и надежность для провайдеров, использующих облачные инфраструктурные решения VMware.

Ознакомьтесь с Release Notes и страницей документации, чтобы получить глубокое понимание новых функций, процесса обновления и ограничений. Вы можете обновиться напрямую до Cloud Director Object Storage Extension 3.0 с версий 2.X. Подробнее об этом рассказано тут.


Таги: VMware, Cloud, Storage, Enterprise, Update

Тестирование производительности рабочих нагрузок Oracle на платформе VMware vSAN ESA


Продолжаем рассказывать о производительности решения vSAN Express Storage Architecture (ESA), где реализовано высокопроизводительное кодирование RAID 5/6 с исправлением ошибок. Клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, которые также эффективны с точки зрения использования пространства, при этом соблюдается высокий уровень производительности. Все это достигается с использованием технологии RAID-6 на базе новой журналируемой файловой системы и формата объектов.

Компания VMware провела тестирование работы баз данных Oracle в среде vSAN ESA и опубликовала некоторые результаты.

Тестовый стенд

Тестовая площадка представляла собой кластер из 8 узлов vSAN 8 Express Storage Architecture (ESA) со следующими настройками:

  • Версия vCenter 8.0.2 сборка 22385739
  • 8 серверов Lenovo ThinkAgile VX7531 Node, 2 сокета, 28 ядер на сокет, Intel Xeon Gold 6348 CPU @ 2.60GHz, 1TB RAM
  • VMware ESXi 8.0.2, сборка 22380479 с vSAN ESA (все хранилища - NVMe)
  • Oracle 21.13 Grid Infrastructure, ASM Storage и Linux udev (размер блока базы данных 8k)
  • OEL UEK 8.9

Детали кластера vSAN Express Storage Architecture (ESA) "env175" показаны ниже. Кластер ESA состоит из 8 серверов Lenovo ThinkAgile VX7531, как показано на картинке:

Каждый сервер Lenovo ThinkAgile VX7531 имеет 2 сокета, 28 ядер на сокет, Intel Xeon Gold 6348 CPU на частоте 2.60GHz и 1TB RAM:


Каждый сервер Lenovo ThinkAgile VX7531 имеет 6 внутренних накопителей NVMe, таким образом каждый сервер дает 6 внутренних устройств NVMe в качестве емкости датастора vSAN ESA:

Информация о сервере ThinkAgile VX7531 "env175-node1.pse.lab" в части деталей HBA и внутренних устройств NVMe:

Политики хранения кластера vSAN Express Storage Architecture (ESA) показаны на картинке ниже.

Базовая политика Oracle "Oracle ESA – FTT0 – NoRAID" была создана только для получения эталонных метрик для сравнения, кроме того, настоящая производственная нагрузка никогда не настраивается с FTT=0 (количество допустимых отказов) и без RAID (то есть без защиты).

  • Oracle ESA – FTT0 – NoRAID
  • Oracle ESA – FTT1 – R5
  • Oracle ESA – FTT2 – R6

Детали виртуальной машины "Oracle21C-OL8-DB_ESA" показаны на картинке ниже.

Виртуальная машина имеет 28 vCPU, 256 ГБ RAM. Один экземпляр базы данных "ORA21C" был создан с опцией multi-tenant на базе инфраструктуры Oracle Grid (ASM). Версия базы данных - 21.13 на операционной системе OEL UEK 8.9.

Oracle ASM использовалась как платформа хранения данных с Linux udev для обеспечения персистентности устройств. Oracle SGA и PGA были установлены на 64G и 10G соответственно. Также были соблюдены все лучшие практики платформы Oracle на VMware.

Виртуальная машина "Oracle21C-OL8-DB_ESA" имеет 4 контроллера vNVMe для дополнительной производительности:

58 устройств хранения привязаны к ВМ "Oracle21C-OL8-DB_ESA", они показаны ниже:

  • NVME 0:0 – 80G для OS (/)
  • NVME 0:1 – 80G для Oracle Grid и бинарников RDBMS
  • NVME 0:2 – 100G для GRID_DG
  • NVME 0:3 – 200G для DATA_DG
  • NVME 0:4 – 200G для DATA_DG
  • NVME 0:5 – NVME 0:12 – 8 дисков vmdk, каждый 25 ГБ – REDO_DG
  • NVME 1:0 – 1:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG
  • NVME 2:0 – 2:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG
  • NVME 3:0 – 3:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG

Детали тестов разных политик хранения vmdk для ВМ "Oracle21C-OL8-Customer" показаны ниже:

  • Тест 1 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT0 – NoRAID"
  • Тест 2 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT1 – R5"
  • Тест 3 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT2 – R6"

Детали группы дисков Oracle ASM показаны ниже:

Тестовый сценарий

Результаты ниже являются тестовым сценарием, демонстрирующим преимущества производительности использования vSAN 8 vSAN Express Storage Architecture (ESA) для бизнес-критичных производственных нагрузок Oracle.

Генератор нагрузки SLOB был запущен против 2 TB табличного пространства SLOB с 3 различными политиками хранения.

  • Oracle ESA – FTT0 – NoRAID
  • Oracle ESA – FTT1 – R5
  • Oracle ESA – FTT2 – R6

В качестве генератора нагрузки для этого эксперимента был выбран SLOB 2.5.4.0 с следующими установленными параметрами SLOB:

UPDATE_PCT=30
RUN_TIME=300
SCALE=25G
WORK_UNIT=1024

Для имитации модели нагрузки с многосхемной работой использовались несколько схем SLOB, и количество потоков на схему было установлено в 20.

Размер рабочего блока был установлен в 1024 для максимизации объема ввода-вывода без перегрузки REDO для изучения различий в показателях производительности между 3 различными политиками хранения на vSAN ESA.

В VMware провели несколько прогонов SLOB для вышеупомянутого кейса и сравнили метрики Oracle, как показано в таблице ниже.

Напомним, что базовая политика Oracle "Oracle ESA – FTT0 – NoRAID" была создана ИСКЛЮЧИТЕЛЬНО для получения базовых метрик для сравнения, так как настоящая производственная нагрузка никогда не настраивается с FTT=0 и без RAID.

Мы видим, что метрики базы данных с новым высокопроизводительным кодированием RAID 5/6 архитектуры vSAN Express Storage Architecture (ESA) сопоставимы с базовыми показателями при использовании без RAID.

Как было сказано ранее, клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, а также эффективность с точки зрения использования пространства.

Углубляясь в профили нагрузки основных баз данных, мы видим схожие метрики баз данных для исполнений запросов (SQL), транзакций, чтения/записи в IOPS и чтения/записи в МБ/сек как для прогонов политик хранения "Oracle ESA – FTT1 – R5", так и для "Oracle ESA – FTT2 – R6", а именно:

  • Выполнение запросов (SQL) в секунду и транзакции в секунду сопоставимы для всех трех прогонов
  • Запросы на чтение IO в секунду и запросы на запись IO в секунду сопоставимы для всех трех прогонов
  • Чтение IO (МБ) в секунду и запись IO (МБ) в секунду сопоставимы для всех трех прогонов

Углубляясь в изучение основных событий ожидания (wait events) базы данных, мы видим схожие события ожидания базы данных с похожими временами ожидания (wait times) для прогонов политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6".

Рассматривая статистику GOS, мы также можем видеть сопоставимые показатели производительности для запусков политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6":

В итоге нам удалось получить сопоставимые показатели производительности как с общей точки зрения базы данных, так и с точки зрения GOS для прогонов политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6".


Таги: VMware, vSAN, Oracle, Performance, ESXi, Storage, VMDK, ESA

Преимущества VMware vSAN Max для корпоративных сред


Продолжаем рассказывать о решении VMware vSAN Max, которое было анонсировано в рамках конференции VMware Explore 2023 в августе прошлого года.

Решение vSAN Max, работающее на архитектуре vSAN Express Storage - это новое предложение в семействе vSAN, которое позволяет получить модель развертывания на базе подписки для отдельных хранилищ, объединяющих петабайты информации на платформе vSphere. Используя vSAN Max в рамках отдельных или растянутых кластеров, пользователи могут масштабировать хранилище независимо от вычислительных мощностей для повышения уровня гибкости при поддержке всех своих рабочих нагрузок. Новое предложение vSAN Max лицензируется отдельно от существующих версий vSAN.

VMware vSAN Max показывает значительный прогресс в гиперконвергентной инфраструктуре (HCI) и решает проблемы хранения данных, с которыми администраторы сталкиваются в современном цифровом мире. Построенный на архитектуре хранилища Express Storage Architecture (ESA) от VMware, vSAN Max предлагает дизагрегированное HCI-решение для хранения данных в масштабах петабайт. Оно обеспечивает беспрецедентный уровень масштабируемости, гибкости и экономичности хранения для ИТ-инфраструктур.

Проблемы современных хранилищ данных

1. Масштабируемость и гибкость

Современные предприятия полагаются на разнообразные приложения, каждое из которых имеет уникальные потребности в ресурсах. Широкий спектр приложений и их разные требования к масштабированию добавляют сложности, создавая необходимость в инфраструктуре, которая была бы способна быстро расти и адаптироваться к меняющимся требованиям.

2. Управление затратами

Балансировка высокой производительности с экономией затрат крайне важна, поскольку бизнесы стремятся оптимизировать расходы на ИТ, не жертвуя качеством, особенно для критичных приложений.

3. Требования к производительности

Растущая сложность и объем рабочих нагрузок с большим объемом данных требуют гибкой инфраструктуры, способной эффективно поддерживать критичные массивные приложения.

4. Простота и эффективность

Управление изолированной ИТ-инфраструктурой может затруднить операционную эффективность, что создает необходимость в более простых решениях для управления виртуальной средой.

VMware vSAN Max: решение для современных вызовов в ИТ

VMware vSAN Max разработан для успешного преодоления этих вызовов, предлагая решение HCI с изолированными хранилищами, которое позволяет независимо масштабировать ресурсы хранения от ресурсов вычислений. Он позволяет бизнесам быстро адаптироваться к изменяющимся потребностям, гарантируя, что возможности хранения точно соответствуют спросу на эти ресурсы. Эта адаптивность поддерживает динамические рабочие нагрузки и рост, значительно улучшая гибкость и масштабируемость ИТ-инфраструктуры.

Преимущества VMware vSAN Max:

  • Эластичное и независимое масштабирование ресурсов хранения

vSAN Max позволяет пользователям динамически корректировать объем хранения в соответствии с изменяющимся спросом на ресурсы. Он поддерживает расширение ресурсов хранения HCI, позволяя масштабировать до более чем 8.5 петабайт в пределах кластера. Каждый узел vSAN Max может поддерживать до 360 ТБ на хост, достигая плотности хранения до 7 раз выше, чем у традиционных узлов HCI.

  • Снижение стоимости владения

vSAN Max предлагает снижение общей стоимости владения до 30% для критически важных приложений благодаря оптимизированной эффективности работы с ресурсами и максимальному использованию оборудования.

  • Исключительная производительность

Построенный на основе vSAN ESA, vSAN Max оснащен для управления огромными объемами данных и удовлетворения строгих требований к производительности и надежности. Он может обеспечивать до 3.6 миллионов операций ввода-вывода в секунду (IOPS) на кластер хранения, обеспечивая плавную работу приложений с высокими требованиями к хранилищу.

  • Упрощенное администрирование

vSAN Max нативно интегрируется с гипервизором VMware vSphere, предоставляя единый опыт управления через vSphere Client. Он включает отдельные разделы интерфейса пользователя для развертывания и мониторинга, тем самым уменьшая зависимость от нескольких консолей управления и упрощая административные задачи.

 

VMware vSAN улучшает возможности хранения VMware vSphere и VMware Cloud Foundation с введением vSAN Max как опциональной модели разделенного развертывания HCI. vSAN Max повышает эффективность управления виртуальными машинами с высокой нагрузкой на подсистему хранения в среде HCI, позволяя независимо масштабировать хранилище. Эта оптимизация использования ресурсов не только снижает затраты, но и обеспечивает уровень масштабируемости, гибкости и производительности, отвечающий требованиям современных бизнесов.

Основные технические подробности о vSAN Max рассмотрены в видео ниже:

Больше интересного о VMware vSAN Max вы можете найти по следующим ссылкам:


Таги: VMware, vSAN, Max, Enterprise, Storage

Хранилища Principal и Supplemental в решении VMware Cloud Foundation 5.1


VMware Cloud Foundation (VCF) — это решение для частного облака от Broadcom, основанное на виртуализации вычислений, сетевых функций и хранилищ, предоставляющее клиентам возможность реализации модели облачной операционной системы на онпремизных площадках клиентов (более подробно об этом тут, тут и тут). Оно предлагает такие преимущества, как простота развертывания и управление жизненным циклом с использованием предварительно проверенного списка ПО (Bill of Materials, BOM), который тщательно тестируется на совместимость.

Хранение данных (критически важная часть частного облака) поддерживается в двух категориях: Основное (Principal) и Дополнительное (Supplemental).

Основное хранилище (Principal Storage)

Основное хранилище настраивается при создании нового домена рабочей нагрузки (Workload Domain) или кластера в консоли SDDC Manager. После создания тип основного хранилища для кластера изменить нельзя. Однако Workload Domain может включать несколько кластеров с собственными типами основного хранилища.

Основные варианты хранения данных (principal storage) включают:

  • vSAN
  • vVols
  • NFSv3
  • VMFS на FC-хранилищах

Следует отметить, что vSAN является единственно поддерживаемым типом основного хранилища для всех кластеров в управляющем домене (Management Domain). vSAN требуется для управляющего домена, поскольку он предсказуем с точки зрения производительности. vSAN предоставляет высокопроизводительное решение для хранения данных Enterprise-уровня для SDDC. Использование vSAN исключает внешние зависимости и облегчает использование средств автоматизации для инициализации управляющего домена VCF. Во время первоначальной установки VCF Cloud Builder инициализирует все основные компоненты центра обработки данных, определяемые программно - такие как vSphere, NSX и vSAN, на минимально необходимом количестве хостов. Этот процесс первоначального запуска в среднем занимает около двух часов.

Дополнительное хранилище (Supplemental storage)

Supplemental storage предоставляет дополнительную емкость кластеру и рекомендуется для данных Tier-2 или Tier-3, таких как библиотеки контента vSphere, шаблоны виртуальных машин, резервные копии, образы ISO и т. д. Дополнительное хранилище требует ручной настройки, не интегрировано и не отображается в SDDC Manager.

Доступные варианты таких хранилищ включают vSAN, vVols, VMFS на FC или iSCSI, NFSv3 или v4.1, а также NVMe-FC или NVMe-TCP.

Роль vSAN ESA

Начиная с версии 5.1, vSAN поддерживает как OSA (оригинальная архитектура хранения), так и ESA (экспресс архитектура хранения). vSAN ESA оптимизирован для использования с высокопроизводительными устройствами хранения нового поколения на базе NVMe, чтобы обеспечить еще более высокие уровни производительности для требовательных рабочих нагрузок, таких как OLTP и генеративный AI. Broadcom рекомендует использовать vSAN ESA в качестве основного хранилища для всех доменов рабочих нагрузок, чтобы получить все преимущества управления и обслуживания полностью программно-определенного стека.

vSAN также обновляется и патчится через LCM (Lifecycle Manager) в SDDC Manager. Обновление и патчинг хранилищ, отличных от vSAN, является ручной задачей и не входит в процедуры управления жизненным циклом, реализованные в SDDC Manager. Для обеспечения поддержки, само хранилище и его HBA необходимо проверять на соответствие VMware Compatibility Guide, когда vSAN не используется.

vSAN использует движок Storage Policy-Based Management (SPBM), который позволяет управлять политиками хранения на уровне виртуальных машин, а не на уровне всего хранилища (datastore). С помощью этого механизма вы можете управлять всеми хранилищами инфраструктуры VCF. Если у вас большая инфраструктура, то необходимо использовать программные средства автоматизации, так как вручную управлять LUN и виртуальными томами и их возможностями очень проблематично в большом масштабе.

Также на эту тему есть интересная статья: "Why vSAN and vVols are Best for VMware Cloud Foundation".

Выводы

vSAN является рекомендуемым решением для хранения данных рабочих нагрузок по вышеупомянутым причинам. Однако VMware понимает, что среды разных клиентов не идентичны, и единый для всех подход не работает. Именно поэтому VCF поддерживает разнообразие типов основного и дополнительного хранилища. Эта гибкость с другими вариантами хранения предоставляет клиентам свободу выбора и позволяет VCF удовлетворить разнообразные потребности производственных сред клиентов.

Важно понимать широкий спектр требований, таких как производительность, доступность, емкость, ожидаемый рост и инвестиции в существующую инфраструктуру. В этой связи для получения дополнительной информации о VMware Cloud Foundation и требованиях к хранилищу, пожалуйста, обратитесь к следующим ресурсам:


Таги: VMware, VCF, Cloud, Storage, SDDC, Enterprise

Улучшенное отображение информации о емкостях VMware Cloud Foundation 5.1 и VMware vSAN 8 Update 2


VMware Cloud Foundation 5.1 и vSAN 8 Update 2 вносят новые улучшения в архитектуру хранения данных vSAN Express Storage Architecture (ESA), которые помогают лучше понять потребление емкости в кластерах.

Часто задаваемые вопросы администраторов

Когда речь идет о хранении данных, основные вопросы, которые задают себе архитекторы центров обработки данных - это "сколько емкости хранения я купил?", "сколько я использую?" и "сколько у меня осталось?". Хотя ответы кажутся очевидными, системы хранения данных часто полагаются на множество способов обеспечения надежности данных и часто используют возможности повышения эффективности использования пространства, что иногда может затруднить ответы на эти вопросы.

Стек хранения данных ESA обрабатывает и хранит данные иначе, чем Original Storage Architecture (OSA). В результате, его накладные расходы на хранение метаданных, файловых систем и необходимая емкость для обеспечения надежности хранения основных данных на случай сбоя также отличаются. Недавние улучшения в vSAN 8 U2 и VMware Cloud Foundation 5.1 включают изменения в пользовательском интерфейсе, которые позволяют лучше учитывать эти накладные расходы. Эти улучшения упрощают понимание потребления емкости. Давайте посмотрим, что изменилось и рассмотрим пример использования емкости хранения для ESA.

Пример потребления храненилищ в ESA

Кластер в примере ниже состоит из 8 хостов ESXi, работающих на платформе vSAN 8 U2. Каждый хост оснащен четырьмя устройствами хранения емкостью 1.6 ТБ, обеспечивая чуть менее 6 ТБ на хост или примерно 47 ТБ для кластера. В этом кластере ESA работает около 100 виртуальных машин, каждой из которых назначена специфичная для кластера политика хранения данных по умолчанию с RAID-6 под управлением функции автоматического управления политиками vSAN ESA. Также там включена функция возврата пространства хранилищ TRIM/UNMAP vSAN. Для ясности, в этом кластере не включены механизмы управления емкостью операционного резерва и резерва восстановления хоста (Operation's Reserve и Host Rebuild Reserve). Хотя этот пример использует кластер в варианте развертывания vSAN HCI, результаты будут такими же, как и в кластере, работающем на vSAN Max.

vSAN представляет емкость кластера на странице Summary, которая делится на два раздела. Раздел "Capacity Overview" показывает, сколько доступной емкости используется, а "Usage breakdown" подробно описывает тип данных, в настоящее время хранящихся в кластере.

Представление Capacity Overview

В этом примере пользовательский интерфейс показывает, что кластер предоставляет 46.57 ТБ отформатированной сырой емкости. Маленькая вертикальная линия на графике обзора емкости представляет "порог операций" (operations threshold), который отражает рекомендуемый лимит потребления емкости (в данном случае - 38.27 ТБ), который обеспечивает операционную деятельность vSAN.

Хотя на кластере хранится почти 31 ТБ данных гостевых виртуальных машин, метаданных объектов и снимков, фактически используемая емкость составляет 17.69 ТБ после учета сжатия данных, что экономит 13.70 ТБ. Сжатие данных в ESA гораздо лучше, чем в OSA, но, конечно, коэффициенты сжатия, которых вы достигнете, будут полностью зависеть от типа данных, хранящихся в вашей среде.

Представление Usage breakdown

В разделе "Usage breakdown" подробно описывается распределение данных после сжатия, исключая свободную емкость. Нововведением в vSAN 8 U2 и VMware Cloud Foundation является значение "ESA object overhead" в категории "System usage". Она отображает метаданные, создаваемые в отношении объекта и реплицированных данных. В этом примере оно составляет около 11.96% от хранимых данных. Указанные накладные расходы объекта ESA рассчитываются после сжатия данных, так что чем лучше сжатие, тем меньше необходимо накладных расходов.

Рекомендация: используйте представление "Usage breakdown" только для хорошо заполненных кластеров. Поскольку расчет ведется только по записанным данным, новые кластеры, в которых очень мало или вообще нет виртуальных машин, могут показывать проценты накладных расходов, гораздо выше ожидаемых. Это связано с тем, что в кластере кроме стандартных, глобальных системных накладных расходов, практически нет других данных.

Результат

Этот конкретный пример демонстрирует, что ESA, даже после учета различных накладных расходов, может защищать данные с высоким уровнем устойчивости (FTT=2) таким образом, что практически все накладные расходы на отказоустойчивость и метаданные компенсируются. В этом примере на кластере, который предоставляет около 46 ТБ сырой емкости, было примерно 15 ТБ данных гостевых виртуальных машин, которые после учета накладных расходов и сжатия потребовали около 17,7 ТБ сырого хранилища. Предполагая тот же уровень сжатия для новых данных, можно было бы хранить еще 15 ТБ дополнительных данных в высокоустойчивом виде и оставаться в пределах базового порога операций для кластера в 38.27 ТБ.

По сравнению с OSA, ESA обеспечивает более высокую устойчивость (поскольку большинство клиентов используют менее устойчивый FTT=1 вместо FTT=2 на OSA), гораздо более высокую производительность и улучшенную эффективность использования пространства для снижения затрат. Intel недавно опубликовала материал, который подтверждает это мнение: "Beyond Savings:  How Server Consolidation with VMware vSAN 8 Boosts Performance by more than 7.4x!". И в отличие от традиционного модульного массива хранения, вы получаете полностью распределенную систему хранения, которую можно масштабировать постепенно и экономично, используя ваши любимые серверы.

Оценка требований к хранению данных

Как вы можете применить эти знания при планировании собственной среды? Утилита vSAN ReadyNode Sizer делает все расчеты необходимой емкости за вас. На рисунке ниже показано, что когда введены спецификации серверов и коэффициенты сжатия, чтобы они соответствовали этому кластеру, оценки емкости оказываются очень похожими.


Таги: VMware, vSAN, VCF, Storage, Sizing

Что нового в технологии VMware Cloud Flex Storage на февраль 2024 года?


Почти два года назад мы писали о решении Cloud Flex Storage, которое представляет собой распределенное хранилище и средства управления данными, полностью управляемые со стороны VMware. Это комбинация cloud-native абстракций, реализующих службы хранения для клиентов, которая предоставляет высокопроизводительные сервисы для современных нагрузок.

С помощью VMware Cloud Services Console пользователи могут масштабировать облачные хранилища без необходимости добавления дополнительных хостов и регулировать доступные емкости как вверх, так и вниз, для каждого из работающих приложений. Также здесь работает модель оплаты по мере потребления ресурсов (pay-as-you-go).

Когда VMware впервые представила Cloud Flex Storage на мероприятии VMware Explore 2022, основной целью было предоставить решение для управления данными и облачным хранилищем уровня предприятия. С тех пор компании разных размеров уже внедрили Cloud Flex Storage для легкого масштабирования хранилищ без добавления хостов, что для многих из них привело к значительной экономии средств. Теперь, с улучшениями, которые были представлены недавно, существенно расширен спектр поддерживаемых рабочих нагрузок, включая критически важные задачи. Основные направления развития продукта - это увеличение масштабируемости сервиса и укрепление его устойчивости.

Итак, давайте посмотрим, что нового:

1. Увеличенная масштабируемость: расширение объема облачного хранилища с эластичным ростом

В этом обновлении VMware Cloud Flex Storage теперь предоставляется дизагрегированное хранилище уровня петабайтов на платформе VMware Cloud on AWS. VMware удвоила доступную емкость на одном хранилище с 400 ТБ до 800 ТБ. Кроме того, теперь поддерживаются до 4 хранилищ на одном SDDC, что позволяет клиентам использовать до 3.2 петабайт хранилища в одном SDDC.

2. Повышение устойчивости: обеспечение производительности для критических приложений

Для поддержки более широкого спектра рабочих нагрузок, включая критически важные приложения, VMware существенно улучшила производительность операций чтения на Cloud Flex Storage. Это позволит клиентам VMware Cloud on AWS запускать больший набор приложений с обеспечением постоянной высокой производительности.

За подробностями о нововведениях технологии VMware Cloud Flex Storage вы можете обратиться к этой странице.


Таги: VMware, Cloud, Storage, Enterprise, Performance, Update

Минимальное число хостов VMware vSAN ESA в зависимости от типа RIAD


С выходом обновленной версии VMware vSAN 8 в этом решении появилась новая архитектура гиперконвергентной инфраструктуры Express Storage Architecture (ESA). Она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

Дункан Эппинг в ответ на запрос пользователей решения vSAN ESA сделал интересный пост на тему минимально необходимого числа хостов, которое требуется для поддержания определенного уровня избыточности - RAID-0/1/5/6.

В VMware vSAN 8 Update 1 появился адаптивный алгоритм записи, который существенно уменьшает избыточность записи на RAID-конфигурации. Когда мы рассматриваем, куда записываются данные по умолчанию используя путь записи ESA для объекта, использующего erasure codes для RAID-6, это уменьшает избыточность записи данных с 4,5x (3x для тройного зеркала + 1,5x для полосы RAID-6 4+2 с двойной паритетной проверкой) до всего лишь 1,5x. Это не только сокращает объем вычислений в процессорах, но и уменьшает сетевой трафик. Этот новый адаптивный путь записи приводит к большему объему передачи данных для всех рабочих нагрузок, которые склонны генерировать большие размеры I/O или большое количество ожидающих операций, создавая ситуации, обычно называемые большим количеством необработанных операций ввода-вывода (high outstanding I/O).

Теперь для vSAN ESA на базе RAID-5, в зависимости от размера кластера, могут быть использованы конфигурации 2+1 или 4+1, а конфигурация 3+1 больше не поддерживается. При этом для RAID-1 и RAID-6 в конфигурациях ничего не изменилось.

Ну и, собственно, ниже приведена таблица, которая позволит вам понять, какое минимальное число хостов ESXi нужно использовать для каждой из выбранных конфигураций, и как это сказывается на дополнительных затратах дисковой емкости:


Таги: VMware, vSAN, ESA, Storage, Hardware, Performance, ESXi

Апгрейд версии Disk Format в VMware vSAN 8 Update 2 при апгрейде с Update 1


Mateusz Romaniuk написал отличный пост о том, что делать, когда вы провели апгрейд решения для создания отказоуйстойчивых хранилищ с версии VMware vSAN 8 Update 1 на Update 2.

VMware vSphere 8.0 U2 вносит множество улучшений, исправляет несколько проблем и повышает стабильность. После обновления с vSphere 8.0 U1 на U2 происходят также некоторые изменения в vSAN. Если кластер vSAN работает в производственной инфраструктуре, вам необходимо проапгрейдить версию диска, когда вы используете самую новую версию vSphere.

В итоге у вас должна быть версия 19 для формата дисков кластера vSAN (Disk format version):

Итак, сам процесс обновления:

1. В клиенте vSphere выберите ваш кластер vSAN. Перейдите на вкладку Configure и в разделе vSAN выберите Disk Management. Если вы проверите один из хостов ESXi, работающих на vSAN, вы увидите, что текущая версия диска - 18.0.

2. Запустите процедуру предварительной проверки Pre-Check Upgrade, чтобы убедиться, что формат дисков может быть обновлен:

3. Если все в порядке, то нажимайте кнопку Upgrade:

4. После этого начнется процесс апгрейда формата дисков, продолжительность которого зависит от размера вашей инфраструктуры и количества дисков:

5. После апгрейда вы получите уведомление об успешном завершении, а в разделе Disk Management вы можете выбрать хост ESXi и нажать View Disks:

6. Там в разделе Disk group вы и увидите нужную вам информацию - Disk format version: 19

Ну а вот и сами диски дисковой группы:


Таги: VMware, vSAN, Upgrade, Update, Storage

Скрипт для быстрого изменения SCSI-контроллера виртуальной машины на платформе VMware vSphere


На сайте VMware Developer появился полезный сценарий PowerCLI, который позволяет администратору изменить текущий контроллер SCSI на новый тип для виртуальной машины на платформе VMware vSphere.

Некоторые особенности работы этого сценария:

  • Не проверяет, настроена ли виртуальная машина для 64-битной гостевой ОС (адаптер BusLogic не поддерживается)
  • Ппроверяет, работают ли VMware Tools и выключает виртуальную машину с помощью функции выключения гостевой ОС
  • Возвращает виртуальную машину в предыдущее рабочее состояние
  • Проверяет, было ли уже установлено новое значение контроллера SCSI

Функция Modify-ScsiController вызывается в самом конце скрипта. Вот различные примеры того, как функция может быть использована:

Скачать данный сценарий можно по этой ссылке.


Таги: VMware, PowerCLI, Storage, Hardware, VMachines

Как правильно обслуживать ISL-соединение растянутого кластера VMware vSAN


Дункан Эппинг написал интересную статью про обслуживание межсайтового соединения (ISL) растянутого кластера VMware vSAN. Обычно, если условия позволяют, можно потушить все рабочие нагрузки (ВМ) на обеих площадках, после чего можно выключить кластеры и проводить обслуживание сетевого линка между площадками. Эта процедура описана в KB 2142676.

Но что делать в случае, когда вам нужно, чтобы рабочие нагрузки на одной из площадок продолжили выполняться во время обслуживания ISL?

В VMware vSAN 7 Update 3 появился механизм vSAN Witness Resiliency, который мы подробно описывали в статье "Улучшения VMware vSAN 7.0 Update 3 - пересчет голосов для обеспечения кворума при последовательных отказах". Он позволяет сохранять кворум в кластере и его функционирование при последовательных отказах - сначала одного из датацентров, а потом и компонента Witness.

Этот механизм и можно использовать для обслуживания 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, vSAN, HA, DRS, Stretched, Storage

Интересное видео о производительности архитектуры VMware vSAN Express Storage Architecture (ESA)


Напомним, что в конце прошлого года в решении vSAN 8 появилась новая архитектура гиперконвергентной инфраструктуры Express Storage Architecture (ESA). Она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

С помощью флэш-памяти TLC на основе технологии NVMe, архитектура ESA имеет множество преимуществ со стандартной vSAN Original Storage Architecture (OSA), которая также продолжит поддерживаться для стандартного на текущий момент оборудования (устройства SATA/SAS).

Ранее мы рассказывали об объектах Storage Pools в vSAN ESA, а также о реализации механизмов повышенной производительности в VMware vSAN 8 Update 1. Ну а недавно компания VMware опубликовала интересное видео, в котором рассказывается о производительности vSAN ESA в сравнении с OSA:

Посмотрим на некоторые полезные скриншоты из видео. Улучшения производительности на уровне отдельного VMDK (RAID-6 ESA работает лучше, чем RAID-1 OSA):

Результаты теста SPEC - время отклика при увеличении числа операций в секунду:

Зависимость задержек (latency) от числа снапшотов на хранилище:

Также почитайте, как именно улучшения производительности VMware vSAN 8 Update 1 влияют на разные типы приложений.


Таги: VMware, vSAN, Performance, Storage, ESA, OSA

Улучшения подсистемы работы с хранилищами в VMware vSphere 8 Update 2


Большинство администраторов уже знакомы с новой функциональностью, которая доступна в новой версии платформы виртуализации 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, vSphere, Storage, Update

Какие функции Datastore Sharing/HCI Mesh/vSAN Max поддерживаются для растянутых кластеров?


Недавно мы писали о сайзинге пропускной способности канала для растянутых кластеров VMware vSAN Stretched Clusters, а сегодня поговорим о том, какие технологии и архитектуры поддерживаются для функций Datastore Sharing в данном типе кластеров. Давайте посмотрим на поддержку Datastore Sharing в рамках разных сценариев, для которых работают архитектуры HCI Mesh и vSAN Max.

О поддержке данных возможностей для растянутых кластеров рассказал Дункан Эппинг. В своей заметке он ссылается на раздел vSAN Max and Disaggregated storage страницы часто задаваемых вопросов по vSAN.

Есть несколько потенциальных комбинаций растянутого кластера и перечисленных возможностей, на момент релиза VMware vSAN 8.0 Update 2 поддержка возможностей выглядит следующим образом:

  • Датастор vSAN Stretched Cluster, расшаренный с vSAN Stretched Cluster –> Поддерживается
  • Датастор 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-конфигурация, поэтому шаринг датасторов в этом случае не поддерживается.


Таги: VMware, vSAN, Stretched, Storage, Blogs

Сайзинг пропускной способности соединения между площадками для растянутого кластера vSAN Stretched Cluster


Сегодня мы расскажем о том, как определить пропускную способность сети между площадками при использовании кластеров vSAN HCI и кластеров vSAN Max в конфигурации Stretched Cluster.

В растянутом кластере два домена отказоустойчивости данных содержат один или несколько хостов, а третий домен отказоустойчивости содержит виртуальный модуль Witness для определения доступности сайтов данных. Далее каждый домен отказоустойчивости данных мы будем называть сайтом. Конфигурации растянутого кластера vSAN могут распространяться на разные расстояния, при условии что соблюдаются требования по пропускной способности (bandwidth) и задержке (latency).

Минимально поддерживаемая пропускная способность и latency между сайтами

Пропускная способность, которая требуется между сайтами, в большой степени зависит от объема операций ввода-вывода (I/O), который генерируют рабочие нагрузки, но будут влиять и другие факторы, такие как используемая архитектура (vSAN ESA или OSA), размер кластера и сценарии обработки сбоев. Ниже указаны минимально поддерживаемые значения, но рассчитанные оценки для конкретной инфраструктуры могут привести к требованиям по пропускной способности, превышающим указанные минимумы.

Также вы можете использовать vSAN Sizer в сочетании с руководством по проектированию vSAN, чтобы создать оптимальную конфигурацию для вашего растянутого кластера.

Требования к пропускной способности между сайтами

Приведенные ниже формулы помогут оценить необходимую пропускную способность сети между сайтами. Предполагается, что два сайта данных географически расположены достаточно близко друг к другу, чтобы соответствовать требованиям по задержке.

Понимание активности 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 - это не предположение о том, что вы на самом деле можете увидеть в своей среде.

  1. Преобразуйте это в процент от исходного размера, разделив конечный размер на начальный размер. Это даст, например, результат ".50".
  2. Умножьте окончательное рассчитанное значение из описанной в этой статье формулы на ".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, vSAN, Network, OSA, ESA, Storage

Опубликована референсная архитектура Microsoft SQL Server на платформе VMware vSAN ESA


Microsoft SQL Server долгое время считается золотым стандартом для критически важных рабочих нагрузок баз данных среднего класса. Однако полноценное использование возможностей SQL Server требует соответствующей инфраструктуры.

Партнерство между Lenovo для линейки ThinkAgile VX Series и VMware в рамках технологии vSAN Express Storage Architecture (ESA) позволяет создать передовую гиперконвергентную инфраструктуру (HCI), работающую на новейших аппаратных платформах. Это решение разработано для удовлетворения сложных потребностей современных организаций, ориентированных на данные.

Референсная архитектура Microsoft SQL Server на платформе VMware vSAN ESA посвящена запуску Microsoft SQL Server на VMware vSAN ESA с Lenovo ThinkAgile VX Series.

В VMware vSAN 8 и vSAN ESA произошли значительные изменения, которые включают в себя использование высокопроизводительных NVMe-дисков и новый, быстрый и эффективный путь передачи данных. vSAN ESA обеспечивает эффективность RAID 5/6 с производительностью RAID 1.

Тестирование показало, что 8-узловой кластер vSAN ESA на Lenovo Agile VX Series может обеспечить 720 000 агрегированных IOPS по мере увеличения количества виртуальных машин SQL Server с одной до восьми. Результаты подтверждают последовательную масштабируемость и надежную производительность для рабочих нагрузок.

В документе приведены обширные рекомендации по проектированию и сайзингу, отчеты о проверке решений и лучшие практики для администраторов и владельцев систем на основе Microsoft SQL Server.


Таги: VMware, vSAN, ESA, Storage, Microsoft, SQL, Performance

Поддержка ReadyNode Emulated Configurations для платформы VMware vSAN ESA


С появлением архитектуры vSAN Express Storage Architecture (ESA) в vSAN 8, которая была представлена в августе 2022 года, VMware хотела предоставить простой способ для клиентов развертывать кластеры с соответствующими характеристиками оборудования и сети. Программа vSAN ReadyNode для ESA гарантировала, что клиенты могут приобретать серверы, предварительно настроенные для выполнения конкретных минимальных требований к оборудованию для ESA, предоставляя при этом достаточную гибкость для удовлетворения требований к емкости и производительности среды пользователей.

VMware не только внесла значительные улучшения в ESA в vSAN 8 U1 и vSAN 8 U2, но и улучшила совместимость с оборудованием, предоставляя клиентам и партнерам простой и гибкий путь для создания поддерживаемой конфигурации. Давайте посмотрим, что поддерживается на данный момент.

Гибкость программы ReadyNode

Благодаря расширенной совместимости с устройствами хранения данных с интенсивным чтением и введению новых готовых узлов vSAN-ESA-AF-0 для небольших датацентров и периферийных сред, тип оборудования, совместимый с ESA, становится более гибким. vSAN ReadyNodes могут быть приобретены с использованием простого, единого SKU, но конфигурации, соответствующие vSAN ESA, также могут быть получены путем "эмуляции" конфигурации ReadyNode с использованием отдельных компонентов оборудования от сертифицированных поставщиков ReadyNode.

Это означает, что клиенты могут выбрать платформу сертифицированную по программе ESA ReadyNode от производителя серверов, указанную в VMware Compatibility Guide (VCG) for vSAN ESA, и далее могут создавать конфигурацию сервера с использованием отдельных аппаратных компонентов, как они указаны в данной спецификации ReadyNode, эмулируя реальный узел ReadyNode, приобретенный с использованием единого SKU. Этот подход может помочь клиентам, которые решили не покупать ReadyNode через официальный SKU, но имеют такое же оборудование (или лучше), найденное в желаемой классификации ReadyNode.

Термин «Emulated ReadyNode» просто относится к тому, из каких компонентов был собран готовый узел ReadyNode. Он воспринимается и поддерживается VMware и поставщиками ReadyNode точно так же, как узлы ReadyNodes, приобретенные с использованием единого SKU.

Поддержка таких эмулированных систем ReadyNode предоставляет большую гибкость при закупке оборудования и развертывании серверов, которые могут работать на vSAN ESA. Этот вариант применяется только к оборудованию и платформам, сертифицированным для ESA, а не к стандартному оборудованию серверов от производителей, не входящих в список ReadyNode. Тип подхода "собери сам" доступен только при использовании оригинальной архитектуры хранения vSAN (Original Storage Architecture, OSA).

Ну а в статье KB 90343 рассказано о том, что вы можете и не можете менять в конфигурации узлов для vSAN ESA ReadyNode:


Таги: VMware, vSAN, Hardware, ESA, Storage

Что нового в Core Storage для VMware vSAN 8 Update 2


Недавно мы писали о новых возможностях решения для создания отказоустойчивых кластеров VMware vSAN 8 Update 2, а также о доступности его для загрузки. Также мы подробно рассказывали об одной из главных возможностей - расширении размера общих дисков VMware vSphere в кластерных приложениях на базе томов vVols без остановки системы.

Сегодня мы расскажем еще о некоторых функциях раздела Core Storage, которые появились в VMware vSAN 8 U2:

  • Поддержка расширения диска vVols в режиме онлайн с Oracle RAC

В этом выпуске, помимо MS WSFC, была добавлена поддержка горячего расширения для дисков Oracle RAC, используя режим Multi-writer. Это можно выполнить как на дисках SCSI, так и на дисках NVMe vVols. Кроме того, это также позволяет клиентам переходить с томов RDM на новые хранилища.

  • vVols NVMe миграция в режиме in-band

Поддержка миграции пространств имен NVMe vVol между группами ANA. Эта функциональность обеспечивает эквивалентность примитиву перепривязки SCSI и позволяет администратору хранилища балансировать нагрузки IO между устройствами PE.

  • Автоматическое восстановление из статуса PDL для vVol PEs

Ранее, когда PE переходил в состояние PDL (Physical Device Loss) и затем возвращался, стек PSA должен был перезагрузить устройство (уничтожить и снова обнаружить пути). Это могло произойти только после того, как объекты vVol, использующие PE, были закрыты. С этим релизом, виртуальная машина будет автоматически выключена, когда обнаруживается, что PE, к которому привязаны vVols виртуальной машины, находится в состоянии PDL. Это дополнительно повышает устойчивость и восстановление при определенных сбоях подсистемы хранения.

  • Включение поддержки MPP сторонних производителей для NVMe vVols

Позволяет сторонним политикам многопутевого доступа (MPP) поддерживать NVMe vVols. Это дает возможность партнерам VMware использовать свои клиентские MPP.

  • Поддержка UNMAP для конфигурационного vVol

Начиная с vSphere 8.0 U1, конфигурационные vVols теперь создаются как тонкие диски с максимальным размером 255 ГБ и форматируются в VMFS-6. В этом релизе поддерживается командная строка (esxcli) для работы с командой unmap конфигурационных vVols.


Таги: VMware, vSAN, Storage

Зачем виртуальному модулю VMware vCenter 8 целых 17 виртуальных дисков?


Если вы откроете VMware vSphere Client и посмотрите на список виртуальных дисков, прикрепленных к виртуальному модулю (Virtual Appliance) сервера vCenter, то вы увидите там аж 17 виртуальных дисков VMDK. Многие администраторы удивляются - а не многовато ли это?

Для VMware vSphere 7 список дисков и их назначение указаны в статье базы знаний KB 78515 (их там 16), ну а ниже мы расскажем о семнадцати VMDK для VMware vSphere 8:

Номер VMDK Размер, ГБ Точка монтирования Описание
1 48 /boot Директория, где хранятся образы ядра и конфигурации загрузчика
2 5.5 /tmp Директория для хранения временных файлов, создаваемых или используемых службами vCenter Server
3 25 SWAP Директория, используемая при нехватке памяти в системе для выгрузки на диск
4 25 /storage/core Директория, где хранятся дампы ядра процесса VPXD сервера vCenter
5 10 /storage/log Директория, где vCenter Server и Platform Services Controller хранят все журналы для виртуального окружения
6 10 /storage/db Расположение хранилища базы данных VMware Postgres
7 15 /storage/dblog Расположение журналов базы данных VMware Postgres
8 10 /storage/seat Директория для статистики, событий, алертов и задач (SEAT) для VMware Postgres
9 1 /storage/netdump Репозиторий сборщика Netdump от VMware, в котором хранятся дампы ESXi
10 10 /storage/autodeploy Репозиторий VMware Auto Deploy, который хранит пакеты для stateless-загрузки хостов ESXi
11 10 /storage/imagebuilder Репозиторий VMware Image Builder, который хранит профили образов vSphere, программные репозитории и пакеты VIB, такие как драйверы и обновления.
12 100 /storage/updatemgr Репозиторий VMware Update Manager, где хранятся патчи и обновления для виртуальных машин и хостов ESXi
13 50 /storage/archive Расположение Write-Ahead Logging (WAL) базы данных VMware Postgres
14 10 /storage/vtsdb Репозиторий службы VMware vTSDB, который хранит статистику
15 5 /storage/vtsdblog Репозиторий службы VMware vTSDB, который хранит журналы этой службы
16 100 /storage/lifecycle Стейджинговая директория службы Workload Control Plane или программный депозиторий, в котором хранятся бинарные файлы для установки и обновления/модернизации платформы
17 150 /storage/lvm_snapshot Директория для временного хранения содержимого system root

Много? Много!


Таги: VMware, vCenter, Storage, VMDK

Видео: технический обзор новых возможностей VMware vSAN 8 Update 2


Компания VMware опубликовала интересное техническое видео с обзором всех новых возможностей средства создания отказоустойчивых хранилищ vSAN 8 Update 2, работающих на базе обновленной платформы виртуализации vSphere 8 Update 2.

Видео длится 25 минут и покрывает все технические аспекты новых функций платформы, включая новую архитектуру vSAN Max, о которой рассказывается во всех подробностях.

Напомним также, что ранее VMware опубликовала еще одно полезное видео о новых возможностях vSphere 8 Update 2:

Ну и, конечно, нельзя не напомнить об этой ссылке на хранилище технических статей и документов о платформе VMware vSAN.


Таги: VMware, vSAN, Update, Video, Max, Storage

Расширение размера общих дисков VMware vSphere в кластерных приложениях на базе томов vVols без остановки системы


Многие клиенты VMware используют кластерные приложения, такие как Microsoft WSFS и Oracle RAC, на платформе vSphere. Эти кластерные системы требуют, чтобы диски были общими для всех серверных узлов внутри приложения. Одним из требований к механизму блокировки дисковых ресурсов является использование SCSI3-Persistent Reservations или режим multi-writer.

Пользователи VMware vSphere обычно применяли физический pRDM для кластерных приложений. С выпуском vSphere 6.7 SCSI3-PR были добавлены к vVols, и это вызвало большой интерес со стороны администраторов. RDM не так просты просты в эксплуатации, они требуют ручного выделения и назначения индивидуальных LUN для всех узлов кластера приложения. Это создает большую операционную нагрузку. Также в этом случае ограничены некоторые возможности виртуализации при использовании томов RDM и требуется взаимодействие с администратором хранилища для изменения его размера. Кроме того, вам также следует помечать свои RDM флагом "Perennially Reserved" для сокращения времени загрузки и повторного сканирования хранилищ.

Внедрению технологии vVols мешало отсутствие одной конкретной функции — возможности увеличивать размер общих дисков, когда кластерное приложение работает.

С выпуском VMware vSphere 8.0 Update 2 было устранено последнее преимущество RDM перед vVols. Теперь вы можете увеличивать размер общих дисков (физическое совместное использование шины physical bus sharing или же multi-writer) без необходимости останавливать кластер приложения. Для WSFC первоначально поддерживается SCSI, но для Oracle RAC поддерживаются и SCSI, и NVMeoF (FC, TCP).

Это означает, что клиентам больше не нужно выполнять все ручные операции по выделению RDM LUN для кластерных приложений. Они могут использовать vVols и выделять приложение и ВСЕ диски на стандартном хранилище данных vVols. Это позволяет клиентам значительно упростить развертывание кластерных приложений и снизить сложность их среды. Это также упрощает ежедневные операции администратора хранилища, поскольку администратор виртуальной инфраструктуры теперь может создавать и изменять размер общих дисков прямо из vCenter! Другим преимуществом является то, что vVols не являются традиционными LUN, и время повторного сканирования хранилищ и время загрузки хоста не зависят от количества выделенных vVols, в отличие от RDM, если только они не помечены флагом Perennially Reserved.

Чтобы показать вам, насколько проста операция изменения размера, VMware сделала короткое демо, показывающее процесс увеличения общего диска в активном кластере Microsoft WSFC (кликните на картинку для открытия GIF в новом окне):


Таги: VMware, vSphere, VVol, Storage, RDM

Анонсы VMware Explore 2023: vSAN 8 Update 2 и vSAN Max


Продолжаем рассказ об анонсах новых продуктов и технологий, сделанных на прошедшей в конце августа конференции VMware Explore 2023 в Лас-Вегасе, которая многие годы является главным событием в сфере виртуализации.

На прошлой неделе мы рассказали о новых возможностях обновленной платформы виртуализации VMware vSphere 8 Update 2, а сегодня поговорим о нововведениях решения для создания отказоустойчивых кластеров VMware vSAN 8 Update 2, а также недавно анонсированном решении VMware vSAN Max.

Продолжая свои начинания по поддержке наиболее критически важных рабочих нагрузок клиентов в плане гибкости, производительности и эффективности, VMware представляет vSAN 8 Update 2 и VMware vSAN Max.

Решение vSAN Max, работающее на архитектуре vSAN Express Storage - это новое предложение в семействе vSAN, которое позволит получить модель развертывания на базе подписки для разрозненных хранилищ, объединяющих петабайты информации на платформе vSphere. Используя vSAN Max, пользователи смогут масштабировать хранилище независимо от вычислительных мощностей для повышения уровня гибкости при поддержке всех своих рабочих нагрузок. Новое предложение vSAN Max будет лицензировано отдельно от существующих версий vSAN. vSAN Max будет предлагаться по подписке и, как планируется, будет лицензирован по метрике на тебибайт (TiB, близко к терабайту).

Кроме нового vSAN Max, улучшения в архитектуре vSAN Express Storage обеспечат новые уровни производительности, а новые функции на платформе vSAN улучшат повседневные операции и пользовательский опыт.

1. Объединенное хранилище масштабов петабайтов

Организации сегодня полагаются на множество приложений для ведения бизнеса, каждое из которых имеет уникальные требования к вычислительной мощности, объему хранения и производительности. Все чаще используются передовые аналитические инструменты, приложения ИИ и приложения, созданные изначально для облачных сервисов, в то время как реляционные базы данных и виртуальные рабочие столы по-прежнему остаются востребованными. Растущее разнообразие рабочих нагрузок и их динамика масштабирования создает потребность в гибкой инфраструктуре, которая позволяет этим критически важным приложениям масштабироваться по мере роста потребностей бизнеса.

С введением vSAN Max клиенты получат больший выбор для развертывания vSAN тем способом, который максимально оптимизирует использование ресурсов и снижает затраты. vSAN Max даст уникальную возможность настраивать кластер vSAN для использования в качестве общего хранилища для кластеров vSphere. Он создан на основе vSAN ESA и дает новые преимущества для клиентов, желающих быстро масштабировать хранилище с высокой производительностью и надежностью. vSAN Max предоставит беспрецедентные уровни масштабируемости и экономической эффективности, повышая отдачу при запуске нагрузок с интенсивным использованием хранилища на гиперконвергентной инфраструктуре (HCI), оптимизируя использование ресурсов и снижая TCO до 30%.

Применяя возможности горизонтального и вертикального масштабирования, пользователи будут иметь полную автономию в том, как увеличивать емкость. Узлы vSAN Max будут предлагать до 7 раз больше плотности, чем узлы HCI, и смогут масштабироваться до более чем 8.5 петабайта в кластере. Клиенты не только смогут масштабировать емкость, но и производительность; каждый добавленный узел в кластер vSAN Max увеличит доступную производительность. И поскольку vSAN Max создан на архитектуре vSAN Express Storage, он может вместить огромные наборы данных и соответствовать строгим требованиям к производительности и надежности, предоставляя до 3,6 миллиона IOPS на кластер хранилищ.

Как и всегда с vSAN, пользователи смогут управлять всеми средами - как традиционной моделью HCI, так и разобщенной моделью Max - из единого интерфейса.

2. Платформа высокой производительности

vSAN 8 U2 вводит несколько улучшений основной платформы, которые обеспечивают совершенно новые уровни производительности, долговечности данных и надежности в архитектуре Express Storage.

  • Интегрированные файловые службы (Integrated File Services) для Cloud Native и традиционных рабочих нагрузок

vSAN 8 U2 добавляет файловые сервисы vSAN в архитектуру Express Storage. Клиенты получат преимущества в производительности и эффективности vSAN ESA для своих сред, использующих файловые сервисы vSAN. Все возможности, присутствующие в файловых сервисах vSAN на оригинальной архитектуре хранения (OSA) в предыдущих версиях vSAN, будут расширены для файловых сервисов vSAN на ESA: улучшенная эффективность использования пространства; лучшая производительность; и меньшие домены отказов.

  • Улучшенная производительность для разобщенных сред (Disaggregated Environments)

vSAN 8 U1 представил новый адаптивный путь записи на архитектуре Express Storage с целью улучшения производительности для рабочих нагрузок, которые выполняли большое количество записей с высокой частотой, чтобы записать данные альтернативным, оптимизированным способом. Теперь это улучшение имплементировали в разобщенные топологии vSAN 8 U2 с vSAN Max. Теперь ВМ, работающие в кластере vSphere или vSAN и использующие ресурсы хранения другого кластера vSAN ESA или кластера vSAN Max, также смогут использовать эту возможность.

  • Внедрение преимуществ vSAN ESA для малых дата-центров и Edge-локаций

vSAN 8 U2 вводит два новых улучшения, которые предоставят гораздо больше гибкости для клиентов, заинтересованных в использовании архитектуры ESA. Во-первых, это введение нового профиля ReadyNode — AF-0 ReadyNode, предназначенного для малых дата-центров и периферийных сред (Edge). Благодаря более низким требованиям к оборудованию, таким как 10Gb NICs, это означает, что клиенты смогут получать преимущества vSAN ESA в средах, которые не требуют производительности, предоставляемой более высокими профилями ReadyNode. Во-вторых, это введение поддержки устройств хранения с меньшим ресурсом записи, "Ready-Intensive". Эти устройства с меньшим ресурсом могут использоваться во многих профилях ReadyNode и предложат более выгодную цену для сред, которые, возможно, не имеют приложений с интенсивными операциями ввода/вывода.

3. Улучшенная управляемость

Производительность, устойчивость и гибкость теряют свой смысл, если решение сложно в эксплуатации. vSAN 8 U2 предлагает несколько новых улучшений, которые упростят повседневные операции администраторов, оптимизируют обнаружение проблем и ускорят время их решения.

  • Интеллектуальная стандартная политика упрощает оптимальную конфигурацию

В vSAN 8 U1 появилась новая функция автоматического управления политиками, которая помогает администраторам настраивать свои новые кластеры vSAN ESA с оптимальными уровнями устойчивости и эффективности. В vSAN 8 U2 эта функция стала еще более мощной. При добавлении или удалении хоста из существующего кластера функция автоматического управления политиками будет оценивать, нужно ли корректировать оптимизированную стандартную политику хранения. Если vSAN определяет необходимость изменения, он позволяет изменить затронутую политику хранения одной кнопкой, которая появится в инициированной проверке health-статуса. В этом случае будет переконфигурирована стандартная политика хранения для кластера с новыми оптимизированными настройками политики.

  • Отчетность о мощности кластера стала более понятной

В vSAN 8 U2 улучшена отчетность о накладных расходах на емкость для объектов, расположенных в хранилищах данных. Эта новая категория "ESA object overhead" (накладные расходы объекта ESA), размещенная в разделе "Usage breakdown" capacity-дэшборда кластера, сообщает о накладных расходах, связанных с обработкой и хранением данных через лог-структурированную файловую систему vSAN (vSAN LFS). Это улучшение поможет администраторам точнее определить накладные расходы по потреблению емкости в их системе хранения.

  • Управление устройствами хранения в большом масштабе

Новая возможность prescriptive disk claim в vSAN ESA позволяет администраторам определять стандартизированный результат требований хостов, входящих в кластер, к диску с точки зрения емкости. vSAN затем попытается применить это желаемое состояние ко всем хостам в кластере. Если он не может применить конфигурацию, будет запущено определение состояния здоровья в Skyline Health для vSAN.

  • Улучшенная безопасность через усовершенствованное управление ключами

Поскольку возможности безопасности инфраструктуры продолжают становиться более сложными, vSAN продолжает адаптироваться под поддержку этих новых возможностей. vSAN 8 U2 поддерживает применение серверов KMS, которые используют атрибут "key expiration" для назначения даты истечения ключа шифрования (Key Encryption Key, KEK). Интеграция с Skyline Health для vSAN будет инициировать отчет о состоянии здоровья при приближении сроков истечения ключа, упрощая управление.

  • Интуитивное обнаружение ВМ и дисков, потребляющих больше всего ресурсов.

Представление "Top Contributors", появившееся в vSAN 7 U2, предоставляет простой способ определения ВМ, которые создают наибольший спрос на ресурсы, предоставляемые кластером. В vSAN 8 U2 инструмент стал еще лучше, помогая клиентам находить места с наибольшей производительностью не только в любой момент времени, но и в рамках настраиваемых периодов времени.

Администраторы также теперь смогут перемещать элементы в том же виде производительности — будь то IOPS, пропускная способность или задержка, что позволит им быстро оценить ВМ, создающие наибольшую нагрузку на кластер, и определить, не потребляют ли хосты кластера ресурсы непропорционально. Новое представление значительно упрощает устранение проблем с производительностью.

  • Улучшенное обнаружение узких мест производительности в растянутых кластерах

vSAN I/O Trip Analyzer — это еще один инструмент, улучшенный в vSAN 8 U2, в нем появилась новая возможность проведения анализа рабочих нагрузок, работающих в растянутом кластере. Пользователь легко сможет определить, где в таком кластере происходит основная задержка, а также задержки в других частях стека, которые могут влиять на общую наблюдаемую ВМ задержку.

  • Упрощенная конфигурация для 2-узловых и растянутых кластеров

vSAN 8 U2 упрощает конфигурацию растянутых кластеров и 2-узловых топологий. Администраторы могут помечать трафик vSAN Witness на виртуальном модуле Witness Appliance через настройки конфигурации VMkernel, а также удалять задачу тэгирования трафика Witness через командную строку. Также был увеличен размер Witness Appliance, доступного для vSAN ESA в vSAN 8 U2. В дополнение к размеру "large", клиенты, работающие с этими конфигурациями, также смогут выбрать модуль размера "medium", который потребляет 2 vCPU и 16GB RAM и поддерживает до 500 ВМ.

Решение VMware vSAN 8 Update 2 запланировано к выпуску в третьем квартале этого года. О новых возможностях платформы можно почитать тут, а вот здесь можно узнать про vSAN Max.


Таги: VMware, vSAN, Update, Max, Storage

Как использовать USB-флешки как датасторы на платформе VMware vSphere 8


На сайте проекта virten.net появилось отличное руководство о том, как правильно настроить USB-накопитель (обычную флэшку), подключенный к хосту VMware ESXi 8.0 в качестве датастора, откуда можно запускать виртуальные машины. Для производственной среды этого делать, само собой, не рекомендуется, а вот для тестирования различных возможностей хоста vSphere данная инструкция может оказаться очень полезной.

Итак:

Рекомендации по выбору USB-накопителя

Касательно форм-фактора или типа USB-накопителей нет никаких ограничений. Вы можете использовать маленькие флешки USB, большие жесткие диски USB 3.5" с высокой емкостью или внешние твердотельные накопители на базе USB. Из-за проблем с производительностью и надежностью, не рекомендуется использовать дешевые USB-флешки для хранилищ.

Предварительные условия

Некоторые команды требуют доступа по SSH к хосту ESXi, который можно включить из vSphere Client:

vSphere Client > ESXi Host > Configure > System > Services > SSH > Start

Это же можно сделать из VMware ESXi Host Client:

ESXi Host Client > Host > Manage >  Services > TSM-SSH > Start

После этого вы можете зайти на хост ESXi по SSH с помощью любого клиента, например, PuTTY.

Шаг 1 - отключаем USB Passthrough

Дефолтное поведение хоста ESXi при присоединении USB-накопителя к хосту - дать возможность его проброса в виртуальную машину через механизм USB Passthrough. Поэтому нам нужно отключить этот механизм.

Есть 3 способа это сделать:

  • На базе устройства с помощью команды esxcli passthrough
  • На базе модели с использованием расширенных настроек USB quirks
  • Полностью отключить его для всех устройств, отключив сервис usbarbitrator

1 - Отключаем USB Passthrough на базе устройства

Этот способ основан на параметрах USB Bus и Vendor ID. Эта настройка сохраняется при перезагрузке, но учтите, что она может перестать работать в условиях, когда изменяются идентификаторы Bus ID или Device ID (например, вы воткнете флэшку в другой порт, либо будет присоединено другое устройство на время отсутствия флэшки в порту).

Итак, втыкаем USB-накопитель в хост ESXi и соединяемся с ним по SSH как root. Выводим список USB-устройств командой:

esxcli hardware usb passthrough device list

Для следующей команды вам потребуется записать параметры четырех выделенных колонок в формате Bus#:Dev#:vendorId:productId (например, 1:4:1058:1140).

Отключаем проброс для устройства:

esxcli hardware usb passthrough device disable -d 1:4:1058:1140

После этого перезагружать хост ESXi не требуется.

2 - Отключаем USB Passthrough, используя USB Quirks

Второй вариант отключает USB Passthrough для конкретной модели (сочетание идентификатора производителя и идентификатора продукта) с использованием расширенных настроек USB Quirks.

Вставьте USB-накопитель в ваш ESXi, подключитесь к хосту ESXi с использованием SSH и войдите под root. Далее просмотрите доступные USB-устройства. Первое число - это идентификатор производителя, второе число - идентификатор продукта:

lusb

Для установки USB Quirks нужно указать ID в следующем формате (см. скриншот выше): 0xDeviceID:0xVendorID  (например, 0x1058:0x1140).

Отключите USB passthrough, используя следующую команду:

esxcli system settings advanced set -o /USB/quirks -s 0x1058:0x1140:0:0xffff:UQ_MSC_NO_UNCLAIM

Здесь уже нужно перезагрузить хост ESXi для применения изменений.

3 - Отключаем USB Arbitrator

Перед началом процедуры не втыкаем флэшку в сервер.

Заходим в клиент vSphere Client, идем в ESX > Configure > System > Advanced System Settings и нажимаем Edit... Далее найдем параметр USB.arbitratorAutoStartDisabled и установим его в значение 1:

После этого перезагружаем хост ESXi и уже после этого втыкаем флэшку в сервер.

То же самое можно сделать с помощью CLI-команды через SSH (после нее можно уже втыкать флэшку):

/etc/init.d/usbarbitrator stop

Также можно отключить USB Arbitrator следующей командой, которая будет применена после перезагрузки хоста:

# chkconfig usbarbitrator off

Шаг 2 - создаем VMFS Datastore на флэшке

После того, как вы отключили проброс USB, можно создавать датастор через vSphere Client, кликнув правой кнопкой на хосте ESXi и выбрав Actions > Storage > New Datastore... (в ESXi Host Client это делается в разделе Storage > New Datastore).

Если ваше устройство не отображается в мастере New Datastore, нужно сделать ресканирование хранилищ (опция Rescan Storage по правому клику) и убедиться, что устройство присутствует в списке.

Если и это не помогло, то можно попробовать создать датастор с помощью командной строки. Находим путь к устройству (Device Path в формате mpx.vmhba##). Для этого запускаем команду:

esxcli storage core device list |grep '^mpx' -A3

В выводе команды вы сможете идентифицировать устройство по его размеру:

Если у вас несколько устройств одного размера, то после подключения нужного вам устройства загляните в лог /var/log/vmkernel.log и посмотрите там наличие вот такой записи:

vmkernel: Successfully registered device "mpx.vmhba34:C0:T0:L0" from plugin "NMP" of type 0

Это и есть ваша флэшка. Теперь создаем переменную с этим устройством:

DISK="/vmfs/devices/disks/mpx.vmhba34:C0:T0:L0"

После этого создаем метку для данного устройства:

partedUtil mklabel ${DISK} gpt

Теперь с помощью утилиты partedUtil создадим раздел с идентификатором GUID=AA31E02A400F11DB9590000C2911D1B8:

partedUtil "setptbl" "${DISK}" "gpt" "1 2048 $(eval expr $(partedUtil getptbl ${DISK} | tail -1 | awk '{print $1 " \\* " $2 " \\* " $3}') - 1) AA31E02A400F11DB9590000C2911D1B8 0"

И отформатируем раздел в формат VMFS:

vmkfstools -C vmfs6 -S usbdrive ${DISK}:1

После этого ваш том, созданный на флэшке, появится в списке датасторов хоста.

Для бесплатного резервного копирования виртуальных машин можно использовать скрипт ghettoVCB.

Если вы заметите, что скорость копирования на/с датастора с помощью команд cp, mv или scp очень медленная, то вы можете использовать механизм Storage vMotion или утилиту vmkfstool для копирования данных.

Например, вот так можно склонировать VMDK-диск:

vmkfstools -i <src>.vmdk <dst>.vmdk

Известные проблемы

Когда вы пытаетесь определить диск, дважды проверьте, что вы не перепутали свои накопители. Имя, отображаемое в пользовательском интерфейсе, не меняется, когда меняется идентификатор. Вот пример, где выделенный диск был перенесен на виртуальный адаптер mpx.vmhba33 как новое устройство. Отображаемое имя при этом остается старым - mpx.vmhba32.

Существующие датасторы не монтируются автоматически! То есть, если на вашей флэшке уже есть тома VMFS, то они не будут видны при ее подключении. В этом случае датастор будет offline, а в логе vmkernel.log вы увидите вот такое сообщение:

cpu0:65593)LVM: 11136: Device mpx.vmhba34:C0:T0:L0:1 detected to be a snapshot:

То есть датастор определяется как снапшот. Список снапшотов вы можете вывести командой:

# esxcli storage vmfs snapshot list
583b1a72-ade01532-55f6-f44d30649051
Volume Name: usbflash
VMFS UUID: 583b1a72-ade01532-55f6-f44d30649051
Can mount: true
Reason for un-mountability:
Can resignature: true
Reason for non-resignaturability:
Unresolved Extent Count: 1

В этом случае вы можете смонтировать датастор следующей командой, используя VMFS UUID:

# esxcli storage vmfs snapshot mount -u 583b1a72-ade01532-55f6-f44d30649051

Таги: VMware, USB, VMFS, Storage, Hardware, vSphere, ESXi

Пропуск сканирования/ресканирования LUN, выделенных для кластеров WSFC на томах pRDM в среде VMware vSphere


В некоторых случаях, когда клиенты используют физические тома pRDM в своей среде, время загрузки хоста VMware ESXi или повторное сканирование хранилища может занимать больше времени, чем обычно. Причина этих долгих процессов заключается в том, что каждый LUN, подключенный к хосту, сканируется при загрузке или во время повторного сканирования хранилища. Обычно тома RDM используются для класторов Microsoft WSFC или других кластерных приложений и не используются хостом напрямую. Во время сканирования ESXi пытается прочитать разделы на всех дисках, но не может это сделать для устройств, постоянно зарезервированных WSFC. В связи с этим, загрузка хоста или повторное сканирование устройств хранения может занимать большое время. WSFC использует механизм SCSI-3 Persistent Reservation для контроля блокировки между узлами WSFC, что блокирует возможность чтения их хостами ESXi.

VMware рекомендует внедрять постоянное резервирование (perennial reservation) для всех хостов ESXi, на которых размещаются узлы ВМ, использующие RDM. Для получения более подробной информации посмотрите статью KB1016106.

Итак, возникает вопрос: как можно заставить хост не сканировать эти RDM, тем самым сокращая время загрузки или повторного сканирования?

Существует флаг устройства под названием "Perennially Reserved", который сообщает хосту, что RDM не должен сканироваться, и что устройство используется в другом месте на постоянной основе. До vSphere 7 этот флаг можно было включить только через CLI и для этого требовался UUID (naa.ID).

Команда для установки флага в значение true:

esxcli storage core device setconfig -d <naa.id> --perennially-reserved=true

Установку флага можно проверить командой:

esxcli storage core device list -d <naa.id>

В выводе команды в случае установленного флага будет следующая строка:

Is Perennially Reserved: true

При установке этой опции ее нужно запустить для каждого соответствующего тома RDM, используемого кластером WSFC, и на каждом хосте ESXi с доступом к этому RDM. Вы также можете установить флаг "Perennially Reserved" в профилях хостов.

С выпуском vSphere 7, возможность установки флага "Perennially Reserved" в значение "true" была добавлена в пользовательский интерфейс в разделе устройств хранения. Также было добавлено поле для отображения текущего значения флага "Perennially Reserved".

После выбора RDM для постоянного резервирования, у вас есть возможность отметить устройство как зарезервированное ("Mark as perennially reserved") для текущего хоста или нескольких хостов в кластере. Это устраняет ручной процесс установки опции для каждого хоста через CLI. Также вы все еще можете использовать для этих целей ESXCLI, PowerCLI или профили хостов.

Когда вы нажмете Yes статус резервирования для устройств обновится в интерфейсе:

Теперь для зарезерированных устройств будет доступна опция снятия этого флага ("Unmark as perennially reserved"):

Важное примечание: вы должны использовать флаг "Perennially Reserved" только для RDM или LUN, которые вы не хотите сканировать. LUN стандартных хранилищ ESXi НЕ должны быть помечены этим флагом.

Ну и весь этот процесс можно также увидеть в видео от VMware:


Таги: VMware, vSphere, ESXi, Storage, LUN

Внимание: не используйте режим "Multi-writer" для виртуальных дисков VMDK на платформе vSphere в кластерах Microsoft WSFC


В 2021 году мы писали об использовании дисков VMDK на платформе VMware vSphere в режиме Multi-writer для кластерных решений. Этот режим предназначен для поддержки технологии высокой доступности баз данных Oracle Real Application Clusters (RAC) и для создания систем непрерывной доступности на базе технологии VMware Fault Tolerance, когда требуется использование общего диска в кластерной конфигурации.

В этом случае необходимо, чтобы диски ВМ находились в режиме multi-writer, то есть позволяли производить запись в файл VMDK одновременно с нескольких хостов ESXi (можно также организовать и запись от нескольких ВМ на одном хосте). Этот режим со стороны VMware поддерживается только для некоторых кластерных решений, таких как Oracle RAC, и для технологии Fault Tolerance, у которой техника vLockstep требует одновременного доступа к диску с обоих хостов ESXi.

В статье, на которую мы сослались выше, хоть и неявно, но было указано, что режим "Multi-writer" используется и для кластеров Microsoft Windows Server Failover Clustering (WSFC, ранее они назывались Microsoft Cluster Service, MSCS), однако это была неверная информация - он никогда не поддерживался для кластеров Microsoft.

Мало того, использовать режим "Multi-writer" для WSFC не только не рекомендуется, но и опасно - это может привести к потере данных. Кроме того, возможности поддержки VMware в этом случае будут очень ограничены.

Информация о поддержке "Multi-writer" и общих дисков VMDK

Использование файлов VMDK в качестве общих дисков для виртуальных машин Windows в среде vSphere возможно, но только когда файлы VMDK хранятся в кластеризованном хранилище данных с включенной поддержкой Clustered VMDK, как описано в статье Clustered VMDK support for WSFC, или ниже в этой статье.

Сначала предупреждения и предостережения - прежде чем предпринимать любые из описанных в этой статье шагов, администратору очень важно понять и принять, что VMware не гарантирует, что эти конфигурации не приведут к потере данных или их повреждению.

Итак, какие варианты предлагает VMware, если вы уже используете кластеры WSFC в режиме multi-writer:

  • Переконфигурирование общих дисков на основе файлов VMDK для кластеризованных виртуальных машин Windows, которые были настроены с использованием опции флага multi-writer.
  • Перемещение файлов VMDK в одно или несколько официально поддерживаемых хранилищ данных с поддержкой Clustered VMDK.
  • Представление файлов VMDK обратно виртуальным машинам таким образом, чтобы минимизировать или избежать необходимости перенастройки внутри гостевой операционной системы или на уровне приложений.

VMware настоятельно рекомендует клиентам, выполняющим эти задачи, убедиться в наличии проверенного и повторяемого плана отката в случае сбоя во время выполнения этих операций. Предполагается и ожидается, что у клиентов имеются проверенные резервные копии всех данных и информации о конфигурации всех виртуальных машин, которые будут участвовать в этом процессе переконфигурации.

Как минимум, клиенты должны выполнить (или отметить) следующее перед началом этих процедур:

  • Текущие конфигурации виртуальных машин, особенно:
    • Диски – какие файлы VMDK соответствуют каким томам в гостевой операционной системе.
    • Имена и расположение файлов для КАЖДОГО диска VMDK.
    • Номер SCSI и SCSI ID, к которому подключен КАЖДЫЙ диск. Мы должны присоединить диск к ТОМУ ЖЕ SCSI ID при повторном подключении.
    • В Windows - текущий владелец ресурсов диска (проверить это можно в конфигурации WSFC).
  • Если владение ресурсами WSFC разделено между узлами, ПЕРЕКЛЮЧИТЕ ВСЕ РЕСУРСЫ на один узел. Это упрощает процесс реконфигурации и очень полезно, чтобы избежать путаницы. Выключите все пассивные узлы ПЕРЕД выключением активного узла. После завершения настройки необходимо включить сначала активный узел, а затем остальные узлы.

Переконфигурация кластера WSFC с Multi-Writer на режим Clustered VMDK

Давайте начнем с рассмотрения нашей текущей конфигурации, посмотрим на узлы (кликабельно):

И на диски:

Протестируем WSFC путем переключения ресурсов диска - в данном случае мы выключаем активный узел и наблюдаем, как кластерные ресурсы становятся доступными на пассивном узле. Этот тест очень важен для проверки работоспособности WSFC перед внесением изменений.

Текущая конфигурация общих дисков (отображение распространенной неправильной конфигурации с включенным multi-writer, где общие диски принадлежат выключенной третьей виртуальной машине).

Вот узел WSFC Node-1 и его расшаренные диски (флаг Multi-Writer установлен в Enabled):

Читайте статью далее->


Таги: VMware, Microsoft, WSFC, VMDK, Storage, HA, Bugs

Новое на VMware Labs: Horizon Instant Clone Associated VMs


На сайте проекта VMware Labs появилась очередная новая утилита - Horizon Instant Clone Associated VMs. Это инструмент, разработанный для помощи администраторам в управлении внутренними виртуальными машинами, связанными с их пулами Horizon. С помощью него вы легко можете определить неиспользуемые виртуальные машины и удалить их всего в несколько кликов, а также сэкономить ценное дисковое пространство и навести порядок в виртуальной инфраструктуре.

Инструмент Horizon Instant Clone Associated VMs содержит несколько полезных функций для операций с виртуальными машинами в инфраструктуре Horizon:

  • Генерация отчетов - возможность создания отчетов, которые показывают связь внутренних ВМ Instant Clone с пулами Horizon. Отчеты доступны в форматах HTML и Excel (.xlsx).
  • Удаление неиспользуемых ВМ - утилита позволяет вам определить и быстро удалить неиспользуемые внутренние ВМ. Эта функция может помочь вам освободить дисковое пространство и навести порядок в вашей виртуальной среде.

  • Определение "сиротских" (orphaned) внутренних ВМ - есть возможность определить "сиротские" внутренние ВМ, которые были удалены, но все еще отображаются в окружении vCenter Server. Выполнив пару действий, вы можете удалить эти ВМ и повысить эффективность вашей виртуальной среды.
  • Удаление внутренних ВМ, указанных в текстовом файле - утилита позволяет вам удалить внутренние ВМ, перечисленные в текстовом файле. Эта штука особенно полезна, когда вам нужно быстро и эффективно удалить большое количество ВМ, имена которых известны.

Для работы продукта вам понадобится Windows 10 x64 / Windows Server 2016 или более поздние, PowerShell версии 5.1 и позднее, а также модуль VMware PowerCLI.

Скачать Horizon Instant Clone Associated VMs можно по этой ссылке.


Таги: VMware, Labs, Horizon, VMachines, Storage

Новые возможности VMware vSAN 8 Update 1


На прошлой неделе мы рассказали о новых возможностях обновленной версии платформы VMware vSphere 8 Update 1, а также новых функциях инфраструктуры хранилищ (Core Storage). Сегодня мы поговорим о новой версии vSAN 8 Update 1 - решения для организации отказоустойчивых кластеров хранилищ для виртуальных машин.

В vSAN 8 компания VMware представила архитектуру хранилища vSAN Express Storage Architecture (ESA), сделав весомый вклад в развитие гиперконвергентной инфраструктуры. В первом пакете обновлений vSAN компания VMware продолжает развивать этот продукт, позволяя клиентам использовать современные массивы, которые обеспечивают новый уровень производительности, масштабируемости, надежности и простоты использования.

Обзор основных возможностей vSAN 8 Update 1 вы также можете увидеть в видео ниже (откроется в новом окне):

В vSAN 8 Update 1 продолжают разрабатывать и улучшать обе архитектуры - vSAN OSA и vSAN ESA. Давайте посмотрим, что нового появилось в vSAN U1:

1. Масштабирование распределенных хранилищ

Обработка разделенных ресурсов вычисления и хранения в кластерах улучшена в версии vSAN 8 U1. Клиенты могут масштабироваться новыми способами, совместно используя хранилища данных vSAN с другими кластерами vSAN или только с вычислительными кластерами vSphere в рамках подхода HCI Mesh.

  • Управление распределенными хранилищами HCI Mesh с помощью архитектуры Express Storage

В vSAN 8 U1 архитектура Express Storage Architecture (ESA) позволяет клиентам максимизировать использование ресурсов устройств нового поколения путем предоставления общего доступа к хранилищами в нескольких нерастянутых кластерах для подхода HCI Mesh. Пользователи могут монтировать удаленные хранилища данных vSAN, расположенные в других кластерах vSAN, и использовать кластер vSAN ESA в качестве внешнего хранилища ресурсов для кластера vSphere.

  • Использование внешнего хранилища с помощью растянутых кластеров vSAN для OSA

В vSAN 8 U1 появилась поддержка распределенных хранилищ HCI Mesh при использовании растянутых кластеров vSAN на основе архитектуры хранения vSAN OSA. Теперь пользователи могут масштабировать хранение и вычислительные мощности независимо - в стандартных и растянутых кластерах.

  • Потребление емкостей хранилищ vSAN для разных экземпляров vCenter Server

vSAN 8 U1 также поддерживает распределенные хранилища в разных средах с использованием нескольких серверов vCenter при использовании традиционной архитектуры хранения (OSA).

2. Улучшение платформы

  • Улучшенная производительность с использованием нового адаптивного пути записи

В новом релизе представлен новый адаптивный путь записи, который позволяет рабочим нагрузкам с множеством записей и частопоследовательными записями записывать данные оптимальным способом. Улучшенная потоковая запись на ESA обеспечит увеличение пропускной способности на 25% и снижение задержки для последовательных записей. Это обновление не только повлияет на приложения с преобладающим профилем последовательной записи I/O, но и расширит разнообразие нагрузок, которые работают оптимальным образом на ESA vSAN.

  • Улучшенная производительность для отдельных нагрузок

Чтобы извлечь максимальную пользу из современного оборудования NVMe, в vSAN ESA 8 U1 была оптимизирована обработка I/O для каждого объекта, находящегося на хранилище данных vSAN ESA, повысив производительность на каждый VMDK на 25%. Эти улучшения производительности для отдельных объектов на ESA будут очень эффективны на критически важных виртуальных машинах, включая приложения, такие как реляционные базы данных и нагрузки OLTP.

  • Улучшенная надежность во время сценариев режима обслуживания.

В vSAN 8 U1 для ESA была добавлена еще одна функция, которая присутствует в vSAN OSA: поддержка RAID 5 и RAID 6 erasure coding с функциями дополнительной защиты от потери данных во время плановых операций обслуживания. Эта новая возможность гарантирует, что данные на ESA хранятся с избыточностью в случае неожиданного сбоя хоста в кластере во время режима обслуживания.

  • Улучшения управления датасторами

В vSAN 8 U1 администраторы смогут настраивать размер объектов пространства имен, что позволит им более просто хранить файлы ISO и библиотеки контента.

3. Упрощение управления

При использовании управления хранилищем на основе политик (SPBM), клиенты могут определять возможности хранения с помощью политик и применять их на уровне виртуальных машин. vSAN 8 U1 есть несколько новых улучшений, которые упрощают ежедневные операции администраторов, а также добавляют несколько новых возможностей, чтобы помочь глобальной команде поддержки VMware (GS) быстрее решать проблемы клиентов.

  • Автоматическое управление политиками для Default Storage Policies (ESA)

В vSAN ESA 8 U1 появилась новая, необязательная кластерная политика хранения по умолчанию, которая поможет администраторам работать с кластерами ESA с оптимальной надежностью и эффективностью. В конфигурации на уровне кластера доступен новый переключатель "Auto-Policy Management". При включении этой функции кластера будет создана и назначена эффективная политика хранения по умолчанию на основе размера и типа кластера.

  • Skyline Health Score и исправление конфигурации

В vSAN 8 U1 модуль Skyline UX был переработан и теперь содержит новую панель управления состоянием с упрощенным видом "здоровья" каждого кластера. Новый пользовательский интерфейс поможет ответить на вопросы: "Находится ли мой кластер и обрабатываемые им нагрузки в работоспособном и здоровом состоянии?" и "Насколько серьезно это состояние? Следует ли решить эту проблему?".

С таким четким пониманием потенциальных проблем и действий для их устранения вы можете сократить среднее время до устранения проблем (mean time to resolution, MTTR).

  • Более высокий уровень детализации для улучшенного анализа производительности

Доступный как в Express Storage Architecture, так и в Original Storage Architecture, сервис производительности vSAN 8 U1 теперь включает мониторинг производительности почти в реальном времени, который собирает и отображает показатели производительности каждые 30 секунд.

  • Упрощенный сбор диагностической информации о производительности

В vSAN 8 U1 в I/O Trip Analyzer для виртуальных машин появился новый механизм планировщика. Вы можете запускать диагностику программно, что позволяет собирать больше и лучших данных, что может быть критически важно для выявления временных проблем производительности. Это улучшение идеально подходит для сред, где ВМ имеет повторяющуюся (хоть и кратковременную) проблему с производительностью.

  • Новая интеграция PowerCLI

В vSAN 8 U1 PowerCLI поддерживает множество новых возможностей как для архитектур ESA (Express Storage Architecture), так и OSA (Original Storage Architecture). С помощью этих интеграций клиенты ESA получат простой доступ к своему инвентарю для мониторинга и автоматизации управления своей средой и выделением ресурсов.

4. Функции Cloud Native Storage

Выделенные окружения DevOps увеличивают сложность всего центра обработки данных и увеличивают затраты. Используя существующую среду vSphere для хостинга рабочих нагрузок Kubernetes DevOps, клиенты дополнительно увеличивают ценность и ROI платформы VMware. VMware продолжает фокусироваться на потребностях разработчиков: в vSAN 8 U1 были реализованы новые улучшения производительности, простоты и гибкости для разработчиков, которые используют среду, и для администраторов, ответственных за саму платформу.

  • Поддержка CNS для vSAN ESA

В vSAN 8 U1 мы добавили поддержку Cloud Native Storage (CNS) для vSAN ESA. Клиенты могут получить преимущества производительности vSAN ESA для своих сред DevOps.

  • Поддержка DPp общих виртуальных коммутаторов

vSAN 8 U1 снижает стоимость и сложность инфраструктуры за счет того, что решения DPp (Data Persistence) теперь совместимы с VMware vSphere Distributed Switch. Клиентам нужны только лицензии vSphere+/vSAN+, чтобы использовать платформу Data Persistence — на vSAN OSA или ESA — и запускать приложения, что дает более низкую общую стоимость владения и упрощение операций.

  • Развертывние Thick provisioning для vSAN Direct Configuration

Наконец, в vSAN 8 U1 были доработаны кластеры, работающие в конфигурации vSAN Direct Configuration — это уникальная кластерная конфигурация, настроенная под Cloud Native Workloads. С vSAN 8 U1 постоянные тома могут быть программно выделены разработчиком как "thick" (это определяется в классе хранения).

Более подробно о новых возможностях VMware vSAN 8 Update 1 можно почитать на специальной странице.


Таги: VMware, vSAN, Update, Storage, OSA, ESA, Performance

Новые возможности Core Storage в VMware vSphere 8 Update 1


Недавно мы писали об анонсированных новых возможностях обновленной платформы виртуализации VMware vSphere 8 Update 1, выход которой ожидается в ближайшее время. Параллельно с этим компания VMware объявила и о выпуске новой версии решения VMware vSAN 8 Update 1, предназначенного для создания высокопроизводительных отказоустойчивых хранилищ для виртуальных машин, а также об улучшениях подсистемы хранения Core Storage в обеих платформах.

Недавно компания VMware также выпустила большую техническую статью "What's New with vSphere 8 Core Storage", в которой детально рассмотрены все основные новые функции хранилищ, с которыми работают платформы vSphere и vSAN. Мы решили перевести ее с помощью ChatGPT и дальше немного поправить вручную. Давайте посмотрим, что из этого вышло :)

Итак что нового в части Core Storage платформы vSphere 8 Update 1

Одно из главных улучшений - это новая система управления сертификатами. Она упрощает возможность регистрации нескольких vCenter в одном VASA-провайдере. Это положит основу для некоторых будущих возможностей, таких как vVols vMSC. Такж есть и функции, которые касаются масштабируемости и производительности. Поскольку vVols могут масштабироваться гораздо лучше, чем традиционное хранилище, VMware улучшила подсистему хранения, чтобы тома vVols работали на больших масштабах.

1. Развертывание нескольких vCenter для VASA-провайдера без использования самоподписанных сертификатов

Новая спецификация VASA 5 была разработана для улучшения управления сертификатами vVols, что позволяет использовать самоподписанные сертификаты для многовендорных развертываний vCenter. Это решение также решает проблему управления сертификатами в случае, когда независимые развертывания vCenter, работающие с различными механизмами управления сертификатами, работают вместе. Например, один vCenter может использовать сторонний CA, а другой vCenter может использовать сертификат, подписанный VMCA. Такой тип развертывания может быть использован для общего развертывания VASA-провайдера. Эта новая возможность использует механизм Server Name Indication (SNI).

SNI - это расширение протокола Transport Layer Security (TLS), с помощью которого клиент указывает, какое имя хоста он пытается использовать в начале процесса handshake. Это позволяет серверу показывать несколько сертификатов на одном IP-адресе и TCP-порту. Следовательно, это позволяет обслуживать несколько безопасных (HTTPS) веб-сайтов (или других служб через TLS) с одним и тем же IP-адресом, не требуя, чтобы все эти сайты использовали один и тот же сертификат. Это является концептуальным эквивалентом виртуального хостинга на основе имени HTTP/1.1, но только для HTTPS. Также теперь прокси может перенаправлять трафик клиентов на правильный сервер во время хэндшейка TLS/SSL.

2. Новая спецификация vVols VASA 5.0 и некоторые детали функций

Некоторые новые функции, добавленные в vSphere 8 U1:

  • Изоляция контейнеров - работает по-разному для поставщиков VASA от различных производителей. Она позволяет выполнять настройку политики контроля доступа на уровне каждого vCenter, а также дает возможность перемещения контейнеров между выбранными vCenter. Это дает лучшую изоляцию на уровне контейнеров, а VASA Provider может управлять правами доступа для контейнера на уровне каждого vCenter.
  • Аптайм - поддержка оповещений об изменении сертификата в рамках рабочего процесса VASA 5.0, который позволяет обновлять сертификат VMCA в системах с несколькими vCenter. Недействительный или истекший сертификат вызывает простой, также возможно возникновение простоя при попытке регистрации нескольких vCenter с одним VASA Provider. В конфигурации с несколькими vCenter сертификаты теперь можно обновлять без простоя.
  • Улучшенная безопасность для общих сред - эта функция работает по-разному для поставщиков VASA от производителей. Все операции могут быть аутентифицированы в контексте vCenter, и каждый vCenter имеет свой список контроля доступа (ACL). Теперь нет самоподписанных сертификатов в доверенном хранилище. VASA Provider может использоваться в облачной среде, и для этого также есть доступная роль в VASA 5.0.
  • Обратная совместимость - сервер ESXi, который поддерживает VASA 5.0, может решать проблемы с самоподписанными сертификатами и простоями, возникающими в случае проблем. VASA 5.0 остается обратно совместимым и дает возможность контролировать обновление в соответствии с требованиями безопасности. VASA 5.0 может сосуществовать с более ранними версиями, если производитель поддерживает эту опцию.
  • Гетерогенная конфигурация сертификатов - работает по-разному для поставщиков VASA от производителей. Теперь используется только подписанный сертификат VMCA, дополнительный CA не требуется. Это позволяет изолировать доверенный домен vSphere. VASA 5.0 позволяет использовать разные конфигурации для каждого vCenter (например, Self-Managed 3rd Party CA Signed Certificate и VMCA managed Certificate).
  • Не необходимости вмешательства администратора - поддержка многократного развертывания vCenter с использованием VMCA, которая не требует от пользователя установки и управления сертификатами для VP. Служба SMS будет отвечать за предоставление сертификатов. Теперь это работает в режиме Plug and Play с автоматической предоставлением сертификатов, без вмешательства пользователя, при этом не требуется никаких ручных действий для использования VASA Provider с любым vCenter.
  • Комплаенс безопасности - отсутствие самоподписанных сертификатов в доверенных корневых центрах сертификации позволяет решить проблемы соответствия требованиям безопасности. Не-СА сертификаты больше не являются частью хранилища доверенных сертификатов vSphere. VASA 5.0 требует от VASA Provider использовать сертификат, подписанный СА для связи с VASA.

3. Перенос Sidecar vVols в config-vvol вместо другого объекта vVol

Sidecars vVols работали как объекты vVol, что приводило к накладным расходам на операции VASA, такие как bind/unbind. Решения, такие как First Class Disks (FCD), создают большое количество маленьких sidecars, что может ухудшить производительность vVols. Кроме того, поскольку может быть создано множество sidecars, это может учитываться в общем количестве объектов vVol, поддерживаемых на массиве хранения. Чтобы улучшить производительность и масштабируемость, теперь они обрабатываются как файлы на томе config-vvol, где могут выполняться обычные операции с файлами. Не забывайте, что в vSphere 8 был обновлен способ байндига config-vvol. В результате, с новым механизмом config-vvol уменьшается число операций и задержки, что улучшает производительность и масштабируемость.

Для этой функциональности в этом релизе есть несколько ограничений при создании ВМ. Старые виртуальные машины могут работать в новом формате на обновленных до U1 хостах, но сам новый формат не будет работать на старых ESXi. То есть новые созданные ВМ и виртуальные диски не будут поддерживаться на хостах ниже версии ESXi 8 U1.

5. Улучшения Config-vvol, поддержка VMFS6 config-vvol с SCSI vVols (вместо VMFS5)

Ранее Config-vvol, который выступает в качестве каталога для хранилища данных vVols и содержимого VM home, был ограничен размером 4 ГБ. Это не давало возможности использования папок с хранилищем данных vVols в качестве репозиториев ВМ и других объектов. Для преодоления этого ограничения Config-vvol теперь создается как тонкий объект объемом 255 ГБ. Кроме того, вместо VMFS-5 для этих объектов будет использоваться формат VMFS-6. Это позволит размещать файлы sidecar, другие файлы VM и библиотеки контента в Config-vvol.

На изображении ниже показаны Config-vvol разных размеров. Для машины Win10-5 Config-vvol использует исходный формат 4 ГБ, а ВМ Win10-vVol-8u1 использует новый формат Config-vvol объемом 255 ГБ.

6. Добавлена поддержка NVMe-TCP для vVols

В vSphere 8 была добавлена поддержка NVMe-FC для vVols. В vSphere 8 U1 также расширена поддержка NVMe-TCP, что обеспечивает совместное использование NVMeoF и vVols. См. статью vVols with NVMe - A Perfect Match | VMware.

7. Улучшения NVMeoF, PSA, HPP

Инфраструктура поддержки NVMe end-to-end:

Расширение возможностей NVMe дает возможность поддержки полного стека NVMe без какой-либо трансляции команд SCSI в NVMe на любом уровне ESXi. Еще одной важной задачей при поддержке end-to-end NVMe является возможность контроля multipath-плагинов сторонних производителей для управления массивами NVMe.

Теперь с поддержкой GOS протокол NVMe может использоваться для всего пути - от GOS до конечного таргета.

Важным аспектом реализации VMware трансляции хранилищ виртуальных машин является поддержка полной обратной совместимости. VMware реализовала такой механизм, что при любом сочетании виртуальных машин, использующих SCSI или контроллер vNVMe, и целевого устройства, являющегося SCSI или NVMe, можно транслировать путь в стеке хранения. Это дизайн, который позволяет клиентам переходить между SCSI- и NVMe-хранилищами без необходимости изменения контроллера хранилищ для виртуальной машины. Аналогично, если виртуальная машина имеет контроллер SCSI или vNVMe, он будет работать как на SCSI-, так и на NVMeoF-хранилищах.

Упрощенная диаграмма стека хранения выглядит так:

Для получения дополнительной информации о NVMeoF для vSphere, обратитесь к странице ресурсов NVMeoF.

8. Увеличение максимального количества путей для пространств имен NVMe-oF с 8 до 32

Увеличение количества путей улучшает масштабирование в окружениях с несколькими путями к пространствам имен NVMe. Это необходимо в случаях, когда хосты имеют несколько портов и модуль имеет несколько нод, а также несколько портов на одной ноде.

9. Увеличение максимального количества кластеров WSFC на один хост ESXi с 3 до 16

Это позволяет уменьшить количество лицензий Microsoft WSFC, необходимых для увеличения количества кластеров, которые могут работать на одном хосте.

Для получения дополнительной информации о работе Microsoft WSFC на vSphere можно обратиться к следующим ресурсам:

10. Улучшения VMFS - расширенная поддержка XCOPY для копирования содержимого датасторов между различными массивами

ESXi теперь поддерживает расширенные функции XCOPY, что оптимизирует копирование данных между датасторами разных массивов. Это поможет клиентам передать обработку рабочих нагрузок на сторону хранилища. Функция уже доступна в vSphere 8 U1, но по факту миграция данных между массивами должна поддерживаться на стороне хранилища.

11. Реализация NFSv3 vmkPortBinding

Данная функция позволяет привязать соединение NFS для тома к конкретному vmkernel. Это помогает обеспечить безопасность, направляя трафик NFS по выделенной подсети/VLAN, и гарантирует, что трафик NFS не будет использовать mgmt-интерфейс или другие интерфейсы vmkernel.

Предыдущие монтирования NFS не содержат этих значений, хранящихся в config store. Во время обновления, при чтении конфигурации из конфигурационного хранилища, значения vmknic и bindTovmnic, если они есть, будут считаны. Поэтому обновления с предыдущих версий не будут содержать этих значений, так как они являются необязательными.

12. Улучшения VM Swap

Здесь появились следующие улучшения:

  • Увеличена производительность включения/выключения ВМ
  • Увеличена производительность vMotion

Изменения в способе создания/удаления Swap-файлов для томов vVols помогли улучшить производительность включения/выключения, а также производительность vMotion и svMotion.

13. Улучшения Config vVol и сохранение привязки

Здесь были сделаны следующие доработки:

  • Уменьшено время запроса при получении информации о ВМ
  • Добавлено кэширование атрибутов vVol - размер, имя и прочих

Конфигурационный vVol - это место, где хранятся домашние файлы виртуальной машины (vmx, nvram, logs и т. д.) и к нему обычно обращаются только при загрузке или изменении настроек виртуальной машины.

Ранее использовалась так называемая "ленивая отмена связи" (lazy unbind), и происходил unbind конфигурационного vVol, когда он не использовался. В некоторых случаях приложения все же периодически обращались к конфигурационному vVol, что требовало новой операции привязки. Теперь эта связь сохраняется, что уменьшает задержку при доступе к домашним данным виртуальной машины.

14. Поддержка NVMeoF для vVols

vVols были основным направлением развития функциональности хранилищ VMware в последние несколько версий, и для vSphere 8.0 это не исключение. Самое большое обновление в ядре хранения vSphere 8.0 - добавление поддержки vVols в NVMeoF. Изначально поддерживается только FC, но со временем будут работать и другие протоколы, провалидированные и поддерживаемые с помощью vSphere NVMeoF. Теперь есть новая спецификация vVols и VASA/VC-фреймворка - VASA 4.0/vVols 3.0.

Причина добавления поддержки vVols в NVMeoF в том, что многие производители массивов, а также отрасль в целом, переходят на использование или, по крайней мере, добавление поддержки NVMeoF для повышения производительности и пропускной способности. Вследствие этого VMware гарантирует, что технология vVols остается поддерживаемой для последних моделей хранилищ.

Еще одним преимуществом NVMeoF vVols является настройка. При развертывании после регистрации VASA фоновая установка завершается автоматически, вам нужно только создать датастор. Виртуальные эндпоинты (vPE) и соединения управляются со стороны VASA, что упрощает настройку.

Некоторые технические детали этой реализации:

  • ANA Group (Асимметричный доступ к пространству имен)

С NVMeoF реализация vVols немного отличается. С традиционными SCSI vVols хранилищами контейнер является логической группировкой самих объектов vVol. С NVMeoF это варьируется в зависимости от того, как поставщик массива реализует функциональность. В общем и целом, на хранилище группа ANA является группировкой пространств имен vVol. Массив определяет количество групп ANA, каждая из которых имеет уникальный ANAGRPID в подсистеме NVM. Пространства имен выделяются и активны только по запросу BIND к провайдеру VASA (VP). Пространства имен также добавляются в группу ANA при запросе BIND к VP. Пространство имен остается выделенным/активным до тех пор, пока последний хост не отвяжет vVol.

  • vPE (virtual Protocol Endpoint)

Для традиционных vVols на базе SCSI, protocol endpoint (PE) - это физический LUN или том на массиве, который отображается в появляется в разделе устройств хранения на хостах. С NVMeoF больше нет физического PE, PE теперь является логическим объектом, представлением группы ANA, в которой находятся vVols. Фактически, до тех пор, пока ВМ не запущена, vPE не существует. Массив определяет количество групп ANA, каждая из которых имеет уникальный ANAGRPID в подсистеме NVM. Как только ВМ запущена, создается vPE, чтобы хост мог получить доступ к vVols в группе ANA. На диаграмме ниже вы можете увидеть, что vPE указывает на группу ANA на массиве.

  • NS (пространство имен, эквивалент LUN в NVMe)

Каждый тип vVol (Config, Swap, Data, Mem), созданный и использующийся машиной, создает NS, который находится в группе ANA. Это соотношение 1:1 между vVol и NS позволяет вендорам оборудования легко масштабировать объекты vVols. Обычно поставщики поддерживают тысячи, а иногда и сотни тысяч NS. Ограничения NS будут зависеть от модели массива.

На диаграмме вы можете увидеть, что сама виртуальная машина является NS, это будет Config vVol, а диск - это другой NS, Data vVol.

Вы можете узнать больше о технических деталях NVMe-FC и vVols в этой статье блога: "vVols with NVMe - A Perfect Match | VMware".

15. Улучшения NVMeoF

  • Поддержка 256 пространств имен и 2K путей с NVMe-TCP и NVMe-FC

NVMeoF продолжает набирать популярность по очевидным причинам - более высокая производительность и пропускная способность по сравнению с традиционным подключением SCSI или NFS. Многие производители хранилищ также переходят на NVMe-массивы и использование SCSI для доступа к NVMe флэш-накопителям является узким местом и потенциалом для улучшений.

Продолжая работать на этим, VMware увеличила поддерживаемое количество пространств имен и путей как для NVMe-FC, так и для TCP.

  • Расширение reservations для устройств NVMe

Добавлена поддержка команд reservations NVMe для использования таких решений, как WSFC. Это позволит клиентам использовать возможности кластеризованных дисков VMDK средствами Microsoft WSFC с хранилищами данных NVMeoF. Пока поддерживается только протокол FC.

  • Поддержка автообнаружения для NVMe Discovery Service на ESXi

Расширенная поддержка NVMe-oF в ESXi позволяет динамически обнаруживать совместимые со стандартом службы NVMe Discovery Service. ESXi использует службу mDNS/DNS-SD для получения информации, такой как IP-адрес и номер порта активных служб обнаружения NVMe-oF в сети.

Также ESXi отправляет многоадресный DNS-запрос (mDNS), запрашивая информацию от сущностей, предоставляющих службу обнаружения DNS-SD. Если такая сущность активна в сети (на которую был отправлен запрос), она отправит (одноадресный) ответ на хост с запрошенной информацией - IP-адрес и номер порта, где работает служба.

16. Улучшение очистки дискового пространства с помощью Unmap

  • Снижение минимальной скорости очистки до 10 МБ/с

Начиная с vSphere 6.7, была добавлена функция настройки скорости очистки (Unmap) на уровне хранилища данных. С помощью этого улучшения клиенты могут изменять скорость очистки на базе рекомендаций поставщика их массива. Более высокая скорость очистки позволяла многим пользователям быстро вернуть неиспользуемое дисковое пространство. Однако иногда даже при минимальной скорости очистки в 25 МБ/с она может быть слишком высокой и привести к проблемам при одновременной отправке команд Unmap несколькими хостами. Эти проблемы могут усугубляться при увеличении числа хостов на один датастор.

Пример возможной перегрузки: 25 МБ/с * 100 хранилищ данных * 40 хостов ~ 104 ГБ/с

Чтобы помочь клиентам в ситуациях, когда скорость очистки 25 МБ/с может приводить к проблемам, VMware снизила минимальную скорость до 10 МБ/с и сделала ее настраиваемой на уровне датасторов:

При необходимости вы также можете полностью отключить рекламацию пространства для заданного datastore.

  • Очередь планирования отдельных команд Unmap

Отдельная очередь планирования команд Unmap позволяет выделить высокоприоритетные операции ввода-вывода метаданных VMFS и обслуживать их из отдельных очередей планирования, чтобы избежать задержки их исполнения из-за других команд Unmap.

17. Контейнерное хранилище CNS/CSI

Теперь вы можете выбрать политику Thin provisioning (EZT, LZT) через SPBM для CNS/Tanzu.

Цель этого - добавить возможность политик SPBM для механизма создания/изменения правил политик хранения, которые используются для параметров выделения томов. Это также облегчает проверку соответствия правил выделения томов в политиках хранения для SPBM.

  • Операции, поддерживаемые для виртуальных дисков: создание, реконфигурация, клонирование и перемещение.
  • Операции, поддерживаемые для FCD: создание, обновление политики хранения, клонирование и перемещение.

18. Улучшения NFS

Инженеры VMware всегда работают над улучшением надежности доступа к хранилищам. В vSphere 8 были добавлены следующие улучшения NFS, повышающие надежность:

  • Повторные попытки монтирования NFS при сбое
  • Валидация монтирования NFS

Ну как вам работа ChatGPT с правками человека? Читабельно? Напишите в комментариях!


Таги: VMware, Storage, Update, ChatGPT, ESXi, vSAN, vSphere, vCenter

Уже вышел новый релиз Vinchin Backup & Recovery V7.0 - скачайте сейчас!


Совсем недавно вышел новый релиз Vinchin Backup & Recovery V7.0, который уже доступен для скачивания. Сегодня мы поговорим о продуктах и технологиях компании Vinchin для резервного копирования виртуальных машин и обеспечения защиты данных виртуального датацентра. В первой части мы расскажем о кратком обзоре вебинара Vinchin Backup & Recovery V7.0, который прошел 1 марта...


Таги: Vinchin, Backup, Storage, VMware, vSphere, Update

Veeam Backup & Replication v12 уже доступен для скачивания - полный список новых возможностей. Часть 5


Публикуем пятую часть нашего большого рассказа о новых возможностях главного решения для резервного копирования и репликации виртуальных машин компании Veeam - Backup & Replication v12, которое уже доступно для скачивания.

В пятой части мы расскажем об улучшениях бэкап-консоли, новых функциях Enterprise Manager, возможностях установщика, лицензировании и интеграциях с хранилищами в части Primary Storage.

1. Бэкап-консоль

  • Granular operations — теперь можно перезапустить процессинг или выполнить бэкап Active Full для отдельных машин без инициирования этой операции для всех машин в задаче путем клика на соответствующую машину в сессии задачи.
  • Global exclusions list - управление постоянными или временными исключениями стало проще за счет возможности указания мастер-списка машин, которые вы хотите полностью исключить из процессинга, даже если они были добавлены в задачу по ошибке. Диалог Global Exclusions доступен из главного меню, также эти машины имеют выбранную опцию Disable processing на вкладке инвентаря.

  • Detach backups from a job - теперь можно отключить существующие бэкапы от задачи, что влечет за собой начало новой цепочки бэкапов во время следующего запуска полного бэкапа. Отключенные бэкапы будут отображаться в Orphaned-разделе вкладки Backups с последними известными данными об их политике хранения. Если вы хотите избежать этого, то можно использовать функцию Export Backup или создать новый Copy Backup вместо отключения бэкапов.
  • Dashboard redesign - дэшборды Workload и Storage registration были переработаны, чтобы упростить навигацию по растущему объему поддерживаемых платформ, вендорам хранилищ и их моделям, с которыми нативно интегрировано решение Veeam Backup & Replication.
  • Last backup time - теперь в списке машин на вкладке инвентаря отображается дата и время снятия последнего бэкапа.
  • Exported backup retention - если вы выбираете автоматическое удаление экспортированных, скопированных или VeeamZIP бэкапов, то дата удаления будет записана в логе сессии.
  • Repository membership and role - новые колонки в представлении репозитория показывают, является ли он extent member для SOBR, а также тип экстента (Performance, Capacity или Archive).
  • Instant recovery preferences - состояние чекбоксов на последней странице мастера Instant Recovery теперь сохраняется на уровне пользователя, чтобы быстрее выполнять восстановление.
  • Session initiator logging - все сессии Restore and System теперь отображают аккаунт пользователя, который инициировал операцию.
  • History tab improvements - все долгие активные сессии (например, без значения End Time) теперь показаны в верху списка при сортировке по End Time.
  • Update notification improvements - движок оповещения об обновлениях был улучшен, теперь он включает нотификации о кумулятивных патчах.

2. Функции Enterprise Manager

Общие улучшения:

  • Certificate-based authentication — теперь не нужно хранить креды бэкап-администратора для каждого управляемого бэкапа в конфигурационной базе данных. Как только бэкап-сервер регистрируется в Enterprise Manager, для коммуникации будут использоваться автоматически сгенерированные сертификаты.

  • Backup server preferences - теперь запоминается выбор бэкап-серверов на дэшборде и отображается там по умолчанию.
  • Improved email reports - были сделаны различные улучшения в отчете по почте в плане контента и верстки.
  • Export support logs - теперь запрошенные Veeam логи могут быть экспортированы с помощью новой функции Log Export.

Улучшения резервного копирования:

  • CDP for VMware Cloud Director — теперь доступно управление существующими политиками VCD CDP и их репликами в Enterprise Manager.
  • Catalyst Copy jobs - можно управлять задачами HPE StoreOnce Catalyst Copy через Enterprise Manager.
  • Quick backup - операции Quick Backup теперь можно запускать из Enterprise Manager для задач, управляемых агентами Managed-byServer.

  • High priority jobs - теперь можно менять приоритет задач в веб-интерфейсе и видеть наиболее приоритетные задачи в списках.

Улучшения процесса восстановления:

  • Instant VM Recovery - теперь выполнять восстановление машин и файловых шар VMware vSphere, VMware Cloud Director и Microsoft Hyper-V можно делать напрямую из бэкапов и снапшотов хранилищ прямо из веб-интерфейса. Это делает доступным восстановление в рамках операции Migrate to Production.
  • Restore to another location - в дополнение к in-place restores, вы можете проводить полное восстановление виртуальной машины на другой хост или хранилище, а также указывать все остальные параметры размещения.
  • PostgreSQL database restore - теперь можно восстанавливать экземпляры БД point-in-time из application-aware бэкапов серверов PostgreSQL и делегировать эту операцию администраторам БД и операторам техподдержки.

  • VM templates restore - теперь можно искать и восстанавливать шаблоны ВМ.
  • Exchange item-level restore improvements - теперь не нужно постоянной хранить аккаунт AD в БД Enterprise Manager, который является членом групп Domain Administrator или Organization Management. Вместо этого можно использовать его в интерактивном режиме с ограничениями по количеству почтовых ящиков при начале восстановления.
  • Search result sorting - выполнение восстановления на уровне файлов стало проще, так как файлы отсортированы по именам в результатах поиска.

3. Установщик

  • New setup experience - установщик был переработан, основные и важные функции сохранились, но были убраны лишние шаги и ненужные элементы. Теперь не нужно заботиться о предварительных условиях установки - нужно просто выбрать те чекбоксы параметров установки, которые вам доступны.

  • Streamlined upgrade - существенно была улучшена функциональность предварительных проверок для апгрейда, где теперь показываются все обнаруженные проблемы в удобном для использования формате. Теперь в отчете вы можете скопировать все детали найденных проблем и отправить их коллегам для исправления.

4. Лицензирование

Прежде всего надо отметить, что формат лицензий не менялся с 10-й версии продукта, поэтому вам не нужно будет обновлять их, и можно продолжить их использование и для V12.

Veeam Universal License (VUL):

  • Doubled license buffer - пользователи с функцией License auto update теперь могут использовать в два раза больший буфер лицензий, что дает возможность превысить использование лицензии VUL до 20% (или до 20 лицензий, в зависимости от того, что больше). Для этого нужно включить license update check, который должен выполняться хотя бы раз в месяц (то есть, нужно настроить сетевой экран соответствующим образом).

Улучшения Community Edition:

  • Community Edition Now with even more features - обновленный бесплатный продукт Veeam Backup & Replication Community Edition V12 получил еще больше новых возможностей и улучшений, доступных в версии V12. Подробнее об этом тут.
  • Cloud-native backups - решения Veeam Backup for Microsoft Azure, for AWS и for Google Cloud теперь включают издание Community Edition как часть бесплатной лицензии на 10 инстансов. Также доступен апгрейд с Community Edition на Veeam Data Platform Essentials.

5. Улучшения Primary Storage

Общие улучшения:

  • Storage discovery optimizations - логика автоматического ресканирования хранилищ была переработана, чтобы избежать ненужных сканирований, которые влияют на производительность. Вследствие этого было уменьшено количество "тяжелых" операций VMFS rescan, которые теперь случаются только при сборе информации о томах и снапшотах или обновлении томов.

Новая версия Universal Storage API v2:

  • Snapshot replication orchestration - задачи РК теперь могут использовать существующие связи репликации хранилищ для создания реплик на основе storage-based snapshot как дополнительных точек восстановления. Это позволяет снимать резервные копии из массивов secondary storage, чтобы избежать нагрузки на primary storage.
  • Snapshot archiving orchestration - теперь задача РК может управлять offload-операциями снапшотов хранилищ на других типах хранилищ, которые поддерживаются вендором, и отслеживать их как дополнительные точки восстановления.
  • Synchronous replication support - задачи РК могут создавать скоординированные снапшоты хранилищ, которые могут управляться как дополнительные точки восстановления на конфигурациях dual storage, которые служат как один том production volume из нескольких бэкэндов управления. Это предоставляет интеграцию с конфигурациями Active/Active и Active/HotStandby.

Для второй версии API (USAPI V2) пока полностью поддерживаются хранилища Pure Storage, другие вендоры будут добавляться по мере их присоединения к программе.

Хранилища Cisco HyperFlex:

  • Multi-vCenter configuration support - версия V12 использует новый HyperFlex API для VMware vCenter для управления хостами ESXi в окружениях, где есть несколько кластеров HyperFlex под управлением одного или нескольких серверов vCenter.

Хранилища IBM Spectrum Virtualize:

  • Volume replication orchestration - добавлена поддержка репликации снапшотов (например, Global Mirror), а также синхронной репликации (например, Metro Mirror и HyperSwap) для хранилищ типа IBM Spectrum Virtualize. Это добавляет поддержку массивов secondary storage для бэкапа из снапшотов хранилищ и задач snapshot-only.
  • Compressed snapshots support - для томов IBM FlashSystem с поддержкой аппаратного сжатия в модулях IBM FlashCore функция сжатия снапшотов включена и используется по умолчанию.

HPE Nimble and HPE Alletra 5000/6000:

  • Synchronous replication support — в V12 добавлена поддержка синхронной репликации и coordinated snapshots, включая конфигурации с Peer Persistence for application-transparent failover. Это дает поддержку secondary storage для бэкапов из снапшотов хранилищ и задач snapshot-only. Данная функциональность поддерживается для массивов HPE Nimble и HPE Alletra 5000/6000 на базе Nimble OS версии 5.1.4 и более поздних.

NetApp All SAN Array (ASA):

  • NetApp ASA support — в V12 добавлена поддержка NetApp ASA для интеграции со снапшотами хранилищ.

На этом заканчивается список функций для пятой части статьи. В завершающей статье о Veeam Backup & Replication v12 мы расскажем о Secondary storage, бэкапе на ленту, поддержке разных платформ, новых функциях Cloud Connect, а также улучшениях API и REST API для бэкап-серверов.

Скачать пробную версию продукта можно бесплатно по этой ссылке.


Таги: Veeam, Backup, Update, Enterprise, Storage, VMware, vSphere, Microsoft, Hyper-V

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25    >   >>
Интересное:





Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

26/08/2024:  VMware Explore 2024 Лас-Вегас
04/11/2024:  VMware Explore 2024 Барселона

Быстрый переход:
VMware VMachines Offtopic NAKIVO vStack Gartner Veeam Vinchin StarWind Nakivo IT-Grad Cloud Teradici VeeamON VMworld PowerCLI Citrix VSAN GDPR 5nine Hardware Nutanix vSphere RVTools Enterprise Security Code Cisco vGate Microsoft SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud DevOps Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs IDC Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V Explore vSAN Update VCF NSX Aria Tanzu EUC Private AI Avi Broadcom Workstation Community Skyline HCX AI Host Client Chargeback Horizon Labs SASE Workspace ONE Networking Backup Ransomware Tools Performance Lifecycle VCP Network AWS Intel API USB SDDC Fusion Whitepaper SD-WAN Mobile VMUG SRM ARM HCI Converter Photon OS Operations VEBA App Volumes Certification VMConAWS Workspace Imager SplinterDB DRS SAN vMotion Open Source iSCSI Partners HA Monterey Kubernetes V2V vForum Learning vRNI UAG Support Log Insight AMD vCSA NSX-T Graphics NVMe HCIBench SureBackup vCloud Обучение Web Client vExpert OpenStack UEM CPU PKS vROPs Stencils Bug VTL Forum Video Update Manager VVols DR Cache Storage DRS Visio Manager Virtual Appliance PowerShell LSFS Client Datacenter Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Encryption Nested XenDesktop VSA vNetwork SSO VMDK Appliance VUM HoL Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP iOS SC VMM VDP PCoIP RHEV vMA Award Licensing Logs Server Demo vCHS Calculator Бесплатно Beta Exchange MAP ONE DaaS Hybrid Monitoring VPLEX UCS GPU SDK Poster VSPP Receiver VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Documentation Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V KB VirtualCenter NFS ThinPrint Stretched Director ESA Troubleshooting Android Python Upgrade ML Hub Guardrails CLI VCPP Memory Driver Foundation HPC Orchestrator Optimization Bugs SVMotion Diagram Ports SIOC Plugin Helpdesk VIC VDS Migration Air DPM Flex Mac SSH VAAI Heartbeat MSCS Composer
Полезные постеры:

Постер VMware vSphere PowerCLI 10

Постер VMware Cloud Foundation 4 Architecture

Постер VMware vCloud Networking

Постер VMware Cloud on AWS Logical Design Poster for Workload Mobility

Постер Azure VMware Solution Logical Design

Постер Google Cloud VMware Engine Logical Design

Постер Multi-Cloud Application Mobility

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Сравнение Oracle VirtualBox и VMware Workstation.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Работа с дисками виртуальных машин VMware.

Диски RDM (Raw Device Mapping) для виртуальных машин VMware vSphere и серверов ESX.

Подключение локальных SATA-дисков сервера VMware ESXi в качестве хранилищ RDM для виртуальных машин.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Где скачать последнюю версию VMware Tools для виртуальных машин на VMware ESXi.

Как использовать возможности VMware vSphere Management Assistant (vMA).

Как перенести виртуальную машину VirtualBox в VMware Workstation и обратно

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Полезные ресурсы:

Последние 100 утилит VMware Labs

Новые возможности VMware vSphere 8.0 Update 1

Новые возможности VMware vSAN 8.0 Update 1

Новые документы от VMware

Новые технологии и продукты на VMware Explore 2022

Анонсы VMware весной 2021 года

Новые технологии и продукты на VMware VMworld 2021

Новые технологии и продукты на VMware VMworld 2020

Новые технологии и продукты на VMware VMworld Europe 2019

Новые технологии и продукты на VMware VMworld US 2019

Новые технологии и продукты на VMware VMworld 2019

Новые технологии и продукты на VMware VMworld 2018

Новые технологии и продукты на VMware VMworld 2017



Copyright VM Guru 2006 - 2024, Александр Самойленко. Правила перепечатки материалов.
vExpert Badge