Наверняка не всем из вас знаком ресурс virten.net — технический портал, посвящённый информации, новостям, руководствам и инструментам для работы с продуктами VMware и виртуализацией. Сайт предлагает полезные ресурсы как для ИТ-специалистов, так и для энтузиастов виртуализации, включая обзоры версий, документацию, таблицы сравнений и практические руководства.

Там можно найти:

• Новости и статьи о продуктах VMware (релизы, обновления, сравнения версий, технические обзоры).
• Полезные разделы по VMware vSphere, ESX, vCenter и другим продуктам, включая истории релизов, конфигурационные лимиты и различия между версиями.
• Практические инструменты и утилиты, такие как декодеры SCSI-кодов, RSS-трекер релизов (vTracker), помощь по OVF/PowerShell, события vCenter и JSON-репозиторий полезных данных.

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

VMware Product Release Tracker (vTracker)

Эта страница содержит список продуктов, выпущенных компанией VMware. vTracker автоматически обновляется, когда на сайте vmware.com становятся доступны для загрузки новые продукты (GA — общедоступный релиз). Если вы хотите получать уведомления о выходе новых продуктов VMware, подпишитесь на RSS-ленту. Вы также можете использовать экспорт в формате JSON для создания собственного инструмента. Не стесняйтесь оставлять там комментарии, если у вас есть предложения по новым функциям.

• vTracker RSS Feed
• vTracker JSON Export
• vTracker CSV Export
• vTracker Table

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

VMware ESXi Release and Build Number History

В этом разделе представлен полный перечень релизов флагманского гипервизора VMware ESX (ранее ESXi). Все версии, выделенные жирным шрифтом, доступны для загрузки. Все патчи указаны под своими официальными названиями релизов, датой выхода и номером билда. Обратите внимание, что гипервизор ESXi доступен начиная с версии 3.5.

Если вы столкнулись с какими-либо проблемами при работе с этим сайтом или заметили отсутствие сборок, пожалуйста, свяжитесь с автором.

VMware vCenter Release and Build Number History

По аналогии с гипервизором ESX/ESXi, на этой странице доступны даты релизов и номера билдов для средства управления VMware vCenter:

Такой же список релизов есть на сайте и для VMware NSX.

PowerShell OVF Helper

Эта страница представляет собой коллекцию заранее настроенных фрагментов PowerShell-скриптов для развертывания OVF/OVA. Идея заключается в ускорении процесса развертывания, если вам необходимо устанавливать несколько виртуальных модулей, выполнять повторное развертывание из-за неверных входных данных или сохранить файл в качестве справочного примера для будущих установок.

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

VMware ESXi SCSI Sense Code Decoder

Ошибки или предупреждения SCSI в логах и интерфейсе ESX отображаются с использованием 6 кодов состояния. Эта страница преобразует эти коды, полученные от хостов ESX, в понятную для человека информацию о состоянии подсистемы хранения. В системном журнале vmkernel.log на хостах ESXi версии 5.x или 6.0 вы можете увидеть записи, подобные приведённым ниже. На странице декодера вы можете ввести нужные числа в форму и получить пояснения по сообщениям SCSI:

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

Кодирование с восстановлением (erasure coding) играет важную роль в хранении данных устойчивым, но при этом эффективным с точки зрения занимаемого пространства способом. Этот пост поможет лучше понять, как erasure coding реализовано в VMware vSAN, чем оно отличается от подходов, применяемых в традиционных системах хранения, и как корректно интерпретировать возможности erasure code в контексте доступности данных.

Назначение Erasure Coding

Основная ответственность любой системы хранения — вернуть запрошенный бит данных. Чтобы делать это надежно, системе хранения необходимо сохранять данные устойчивым способом. Простейшая форма устойчивости данных достигается посредством нескольких копий или «зеркал», которые позволяют поддерживать доступность при возникновении отказа в системе хранения, например при выходе из строя диска в массиве хранения или хоста в распределённой системе хранения, такой как vSAN. Одна из проблем этого подхода — высокая стоимость хранения: полные копии данных занимают много места. Одна дополнительная копия удваивает объём, две — утраивают.

Erasure codes позволяют хранить данные устойчиво, но гораздо более эффективно с точки зрения пространства, чем традиционное зеркалирование. Вместо хранения копий данные распределяются по нескольким локациям — каждая из которых может считаться точкой отказа (например, диск или хост в распределённой системе, такой как vSAN). Фрагменты данных формируют «полосу» (stripe), к которой добавляются фрагменты четности, создаваемые при записи данных. Данные четности получаются в результате математических вычислений. Если какой-либо фрагмент данных отсутствует, система может прочитать доступные части полосы и вычислить недостающий фрагмент, используя четность. Таким образом, она может либо выполнить исходный запрос чтения «на лету», либо реконструировать отсутствующие данные в новое место. Тип erasure code определяет, может ли он выдержать потерю одного, двух или более фрагментов при сохранении доступности данных.

Erasure codes обеспечивают существенную экономию пространства по сравнению с традиционным зеркальным хранением. Экономия зависит от характеристик конкретного типа erasure code — например, сколько отказов он способен выдержать и по скольким локациям распределяются данные.

Erasure codes бывают разных типов. Их обычно обозначают количеством фрагментов данных и количеством фрагментов четности. Например, обозначение 6+3 или 6,3 означает, что полоса состоит из 6 (k) фрагментов данных и 3 (m) фрагментов четности, всего 9 (n) фрагментов. Такой тип erasure code может выдержать отказ любых трёх фрагментов, сохранив доступность данных. Он обеспечивает такую устойчивость при всего лишь 50% дополнительного расхода пространства.

Но erasure codes не лишены недостатков. Операции ввода-вывода становятся более сложными: одна операция записи может преобразовываться в несколько операций чтения и записи, что называют «усилением ввода-вывода» (I/O amplification). Это может замедлять обработку в системе хранения, а также увеличивать нагрузку на CPU и требовать больше полосы пропускания. Однако при правильной реализации erasure codes могут сочетать устойчивость с высокой производительностью. Например, инновационная архитектура vSAN ESA устраняет типичные проблемы производительности erasure codes, и RAID-6 в ESA может обеспечивать такую же или даже лучшую производительность, чем RAID-1.

Хранение данных в vSAN и в традиционном массиве хранения

Прежде чем сравнивать erasure codes в vSAN и традиционных системах хранения, рассмотрим, как vSAN хранит данные по сравнению с классическим массивом.

Хранилища часто предоставляют большой пул ресурсов в виде LUN. В контексте vSphere он форматируется как datastore с VMware VMFS, где располагаются несколько виртуальных машин. Команды SCSI передаются от ВМ через хосты vSphere в систему хранения. Такой datastore на массиве охватывает большое количество устройств хранения в его корпусе, что означает не только широкую логическую границу (кластерная файловая система с множеством ВМ), но и большую физическую границу (несколько дисков). Как и многие другие файловые системы, такая кластерная ФС должна оставаться целостной, со всеми метаданными и данными, доступными в полном объёме.

vSAN использует совершенно иной подход. Вместо классической файловой системы с большой логической областью данных, распределённой по всем хостам, vSAN оперирует малой логической областью данных для каждого объекта. Примерами могут служить диски VMDK виртуальной машины, постоянный том для контейнера или файловый ресурс, предоставленный службами файлов vSAN. Именно это делает vSAN аналогичным объектному хранилищу, даже несмотря на то, что фактически это блочное хранилище с использованием SCSI-семантики или файловой семантики в случае файловых сервисов. Для дополнительной информации об объектах и компонентах vSAN см. пост «vSAN Objects and Components Revisited».

Такой подход обеспечивает vSAN целый ряд технических преимуществ по сравнению с монолитной кластерной файловой системой в традиционном массиве хранения. Erasure codes применяются к объектам независимо и более гранулярно. Это позволяет заказчикам проектировать кластеры vSAN так, как они считают нужным — будь то стандартный односайтовый кластер, кластер с доменами отказа для отказоустойчивости на уровне стоек или растянутый кластер (stretched cluster). Кроме того, такой подход позволяет vSAN масштабироваться способами, недоступными при традиционных архитектурных решениях.

Сравнение erasure coding в vSAN и традиционных системах хранения

Имея базовое понимание того, как традиционные массивы и vSAN предоставляют ресурсы хранения, рассмотрим, чем их подходы к erasure coding отличаются. В этих сравнениях предполагается наличие одновременных отказов, поскольку многие системы хранения способны справляться с единичными отказами в течение некоторого времени.

Массив хранения (Storage Array)

В данном примере традиционный массив использует erasure code конфигурации 22+3 для одного LUN (k=22, m=3, n=25).

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

• Относительно низкие накладные расходы по ёмкости. Дополнительная ёмкость, потребляемая данными четности для поддержания доступности при сбоях в доменах отказа (устройствах хранения), составляет около 14%. Такого низкого уровня удаётся достичь благодаря распределению данных по очень большому числу устройств хранения.
• Относительно высокий уровень отказоустойчивости (3). Любые три устройства хранения могут выйти из строя, и том останется доступным. Но, как отмечено ниже, это только часть картины.

Компромиссы:

• Относительно большой «радиус поражения». Если число отказов превысит то, на которое рассчитан массив, зона воздействия будет очень большой. В некоторых случаях может пострадать весь массив.
• Защита только от отказов устройств хранения. Erasure coding в массивах защищает только от отказов самих накопителей. Массивы могут испытывать серьёзную деградацию производительности и доступности при других типах отказов, например, межсоединений (interconnects), контроллеров хранения и некорректных обновлениях прошивок. Ни один erasure code не может обеспечить доступность данных, если выйдёт из строя больше контроллеров, чем массив способен выдержать.
• Относительно высокий эффект на производительность во время или после отказов. Отказы при больших значениях k и m могут требовать очень много ресурсов на восстановление и быть более подвержены высоким значениям tail latency.
• Относительно большое количество потенциальных точек отказа на одну четность. Соотношение 8,33:1 отражает высокий показатель потенциальных точек отказа относительно количества битов четности, обеспечивающих доступность. Высокое соотношение указывает на более высокую хрупкость.

Последний пункт является чрезвычайно важным. Erasure codes нельзя оценивать только по заявленному уровню устойчивости (m), но необходимо учитывать сопоставление заявленной устойчивости с количеством потенциальных точек отказа, которые она прикрывает (n). Это обеспечивает более корректный подход к пониманию вероятностной надёжности системы хранения.

vSAN

В этом примере предположим, что у нас есть кластер vSAN из 24 хостов, и объект данных ВМ настроен на использование RAID-6 erasure code ы (k=4, m=2, n=6).

Важно отметить, что компоненты, формирующие объект vSAN при использовании RAID-6, будут содержать как фрагменты данных, так и фрагменты четности. Как описывает Христос Караманолис в статье "The Use of Erasure Coding in vSAN" (vSAN OSA, примерно 2018 год), vSAN не создаёт отдельные компоненты четности.

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

• Относительно небольшой «радиус поражения». Если кластер переживает более двух одновременных отказов хостов, это затронет лишь некоторые объекты, но не выведет из строя весь datastore.
• Защита от широкого спектра типов отказов. Erasure coding в vSAN учитывает отказы отдельных устройств хранения, хостов и отказы заранее определённых доменов (например, стоек).
• Относительно низкое влияние на производительность во время или после отказа. Небольшие значения k уменьшают вычислительные затраты при восстановлении.
• Относительно малое число потенциальных точек отказа на единицу четности. Соотношение 3:1 указывает на малое количество возможных точек отказа по сравнению с числом битов четности, обеспечивающих доступность.

Компромиссы:

• Низкая абсолютная устойчивость объекта к отказам (2). У vSAN RAID-6 (4+2) заявленная устойчивость меньше. Однако важно помнить: граница отказа — это объект, а не весь кластер, количество потенциальных точек отказа на четность существенно ниже.
• Относительно более высокие накладные расходы. Дополнительная ёмкость, потребляемая битами четности для поддержания доступности при отказе домена (хоста), составляет 50%.

Несмотря на то, что RAID-6 в vSAN защищает от 2 отказов (в отличие от 3), он остаётся чрезвычайно надёжным благодаря небольшому количеству потенциальных точек отказа: всего 6 против 25. Это обеспечивает vSAN RAID-6 (4+2) техническое преимущество перед схемой хранения массива 22+3, если сравнивать надёжность с точки зрения вероятностей отказов.

Для vSAN использование erasure code с малым значением n обеспечивает гораздо большую гибкость в построении кластеров под самые разные сценарии. Например, RAID-6 (4+2) можно использовать минимум на 6 хостах. Для erasure code 22+3 теоретически потребовалось бы не менее 25 хостов в одном кластере.

Развязка размера кластера и доступности

RAID-6 в vSAN всегда остаётся схемой 4+2, независимо от размера кластера. Когда к объекту применяется политика хранения FTT=2 с RAID-6, это означает, что объект может выдержать два одновременных отказа хостов, на которых находятся его компоненты.

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

vSAN рассматривает такие уцелевшие хосты как кандидатов для размещения реконструируемых компонентов, чтобы вернуть объекту заданный уровень устойчивости.

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

Для дополнительной информации о доступности и механизмах обработки отказов в vSAN см. документ "vSAN Availability Technologies" на VMware Resource Center.

Итог

Erasure coding — это мощная технология, позволяющая хранить данные очень устойчиво и при этом эффективно использовать пространство. Но не все erasure codes одинаково полезны.

vSAN использует такие схемы erasure coding, которые обеспечивают оптимальный баланс устойчивости, гибкости и эффективности использования пространства в распределённой среде. В сочетании с дополнительными механизмами оптимизации пространства — такими как сжатие данных в vSAN и глобальная дедупликация в ESA (в составе VCF 9.0), хранилище vSAN становится ещё более производительным, ёмким и надёжным, чем когда-либо.

В постах ранее мы подчеркивали ценность, которую NVMe Memory Tiering приносит клиентам Broadcom, и то, как это стимулирует ее внедрение. Кто же не хочет сократить свои расходы примерно на 40% просто благодаря переходу на VMware Cloud Foundation 9? Мы также затронули предварительные требования и оборудование в части 1, а архитектуру — в Части 2; так что теперь поговорим о правильном масштабировании вашей среды, чтобы вы могли максимально эффективно использовать свои вложения и одновременно снизить затраты.

Правильное масштабирование для NVMe Memory Tiering касается главным образом оборудования, но здесь есть два возможных подхода: развёртывания greenfield и brownfield.

Начнем с brownfield — внедрения Memory Tiering на существующей инфраструктуре. Вы пришли к осознанию, что VCF 9 — действительно интегрированный продукт, и решили развернуть его, но только что узнали о Memory Tiering. Не волнуйтесь, вы всё ещё можете внедрить NVMe Memory Tiering после развертывания VCF 9. Прочитав части 1 и 2, вы узнали о важности классов производительности и выносливости NVMe, а также о требовании 50% активной памяти. Это означает, что нам нужно рассматривать NVMe-устройство как минимум такого же размера, что и DRAM, поскольку мы удвоим объём доступной памяти. То есть, если каждый хост имеет 1 ТБ DRAM, у нас также должно быть минимум 1 ТБ NVMe. Вроде бы просто. Однако мы можем взять NVMe и покрупнее — и всё равно это будет дешевле, чем покупка дополнительных DIMM. Сейчас объясним.

VMware не случайно транслирует мысль: «покупайте NVMe-устройство как минимум такого же размера, что и DRAM», поскольку по умолчанию они используют соотношение DRAM:NVMe равное 1:1 — половина памяти приходится на DRAM, а половина на NVMe. Однако существуют рабочие нагрузки, которые не слишком активны с точки зрения использования памяти — например, некоторые VDI-нагрузки. Если у вас есть рабочие нагрузки с 10% активной памяти на постоянной основе, вы можете действительно воспользоваться расширенными возможностями NVMe Memory Tiering.

Соотношение 1:1 выбрано по следующей причине: большинство нагрузок хорошо укладывается в такие пропорции. Но это отношение DRAM:NVMe является параметром расширенной конфигурации, который можно изменить — вплоть до 1:4, то есть до 400% дополнительной памяти. Поэтому для рабочих нагрузок с очень низкой активностью памяти соотношение 1:4 может максимизировать вашу выгоду. Как это влияет на стратегию масштабирования?

Отлично, что вы спросили) Поскольку DRAM:NVMe может меняться так же, как меняется активность памяти ваших рабочих нагрузок, это нужно учитывать уже на этапе закупки NVMe-устройств. Вернувшись к предыдущему примеру хоста с 1 ТБ DRAM, вы, например, решили, что 1 ТБ NVMe — разумный минимум, но при нагрузках с очень низкой активной памятью этот 1 ТБ может быть недостаточно выгодным. В таком случае NVMe на 4 ТБ позволит использовать соотношение 1:4 и увеличить объём доступной памяти на 400%. Именно поэтому так важно изучить активную память ваших рабочих нагрузок перед покупкой NVMe-устройств.

Еще один аспект, влияющий на масштабирование, — размер раздела (partition). Когда мы создаём раздел на NVMe перед настройкой NVMe Memory Tiering, мы вводим команду, но обычно не указываем размер вручную — он автоматически создаётся равным размеру диска, но максимум до 4 ТБ. Объём NVMe, который будет использоваться для Memory Tiering, — это комбинация размера раздела NVMe, объёма DRAM и заданного отношения DRAM:NVMe. Допустим, мы хотим максимизировать выгоду и «застраховать» оборудование на будущее, купив 4 ТБ SED NVMe, хотя на хосте всего 1 ТБ DRAM. После настройки вариантами по умолчанию размер раздела составит 4 ТБ (это максимальный поддерживаемый размер), но для Memory Tiering будет использован лишь 1 ТБ NVMe, поскольку используется соотношение 1:1. Если нагрузка изменится или мы поменяем соотношение на, скажем, 1:2, то размер раздела останется прежним (пересоздавать не требуется), но теперь мы будем использовать 2 ТБ NVMe вместо 1 ТБ — просто изменив коэффициент соотношения. Важно понимать, что не рекомендуется менять это соотношение без надлежащего анализа и уверенности, что активная память рабочих нагрузок вписывается в доступный объём DRAM.

Итак, при определении размера NVMe учитывайте максимальный поддерживаемый размер раздела (4 ТБ) и соотношения, которые можно настроить в зависимости от активной памяти ваших рабочих нагрузок. Это не только вопрос стоимости, но и вопрос масштабируемости. Имейте в виду, что даже при использовании крупных NVMe-устройств вы всё равно сэкономите значительную сумму по сравнению с использованием только DRAM.

Теперь давайте поговорим о вариантах развертывания greenfield, когда вы заранее знаете о Memory Tiering и вам нужно закупить серверы — вы можете сразу учесть эту функцию как параметр в расчете стоимости. Те же принципы, что и для brownfield-развертываний, применимы и здесь, но если вы планируете развернуть VCF, логично тщательно изучить, как NVMe Memory Tiering может существенно снизить стоимость покупки серверов. Как уже говорилось, крайне важно убедиться, что ваши рабочие нагрузки подходят для Memory Tiering (большинство подходят), но проверку провести необходимо.

После исследования вы можете принимать решения по оборудованию на основе квалификации рабочих нагрузок. Допустим, все ваши рабочие нагрузки подходят для Memory Tiering, и большинство из них используют около 30% активной памяти. В таком случае всё ещё рекомендуется придерживаться консервативного подхода и масштабировать систему с использованием стандартного соотношения DRAM:NVMe 1:1. То есть, если вам нужно 1 ТБ памяти на хост, вы можете уменьшить объем DRAM до 512 ГБ и добавить 512 ГБ NVMe — это даст вам требуемый общий объем памяти, и вы уверены (благодаря исследованию), что активная память ваших нагрузок всегда уместится в DRAM. Кроме того, количество NVMe-устройств на хост и RAID-контроллер — это отдельное решение, которое не влияет на доступный объем NVMe, поскольку в любом случае необходимо предоставить одно логическое устройство, будет ли это один независимый NVMe или 2+ устройства в RAID-конфигурации. Однако это решение влияет на стоимость и отказоустойчивость.

С другой стороны, вы можете оставить исходный объем DRAM в 1 ТБ и добавить еще 1 ТБ памяти через Memory Tiering. Это позволит использовать более плотные серверы, сократив общее количество серверов, необходимых для размещения ваших нагрузок. В этом случае экономия достигается за счет меньшего количества оборудования и компонентов, а также сокращения затрат на охлаждение и энергопотребление.

В заключение, при определении размеров необходимо учитывать все переменные: объем DRAM, размер NVMe-устройств, размер раздела и соотношение DRAM:NVMe. Помимо этих параметров, для greenfield-развертываний следует проводить более глубокий анализ — именно здесь можно добиться дополнительной экономии, покупая DRAM только для активной памяти, а не для всего пула, как мы делали годами. Говоря о факторах и планировании, стоит также учитывать совместимость Memory Tiering с vSAN — это будет рассмотрено в следующей части серии.

Новый документ: vSAN File Services - An overview of vSAN File Services in VMware Cloud Foundation 9.0

Компания VMware выпустила новый документ о файловых службах отказоустойчивой архитектуры хранения "vSAN File Services - An overview of vSAN File Services in VMware Cloud Foundation 9.0".

Что такое vSAN File Services

• vSAN File Services — это встроенная в vSAN опциональная функция, которая позволяет организовать файловые расшаренные ресурсы (файловые шары) прямо «поверх» кластера vSAN. То есть, вместо покупки отдельного NAS-массива или развертывания виртуальных машин-файловых серверов, можно просто включить эту службу на уровне кластера.
• После включения vSAN File Services становится возможным предоставить SMB-шары (для Windows-систем) и/или NFS-экспорты (для Linux-систем и cloud-native приложений) прямо из vSAN.

Основные возможности и сильные стороны

Вот ключевые функции и плюсы vSAN File Services:

Когда / кому это может быть особенно полезно

vSAN File Services может быть выгоден для:

• Организаций, которые уже используют vSAN и хотят минимизировать аппаратное разнообразие — делать и виртуальные машины, и файловые шары на одной платформе.
• Виртуальных сред (от средних до крупных), где нужно предоставить множество файловых шар для пользователей, виртуальных машин, контейнеров, облачных приложений.
• Сценариев с контейнерами / cloud-native приложениями, где требуется RWX (Read-Write-Many) хранилище, общие папки, persistent volumes — все это дают NFS-шары от vSAN.
• Удалённых офисов, филиалов, edge / branch-site, где нет смысла ставить отдельное файловое хранилище.
• Случаев, когда хочется централизованного управления, мониторинга, политики хранения и квот — чтобы всё хранилище было в рамках одного vSAN-кластера.

Ограничения и моменты, на которые нужно обратить внимание

Нужно учитывать следующие моменты при планировании использования:

• Требуется выделить отдельные IP-адреса для контейнеров, которые предоставляют шары, плюс требуется настройка сети (promiscuous mode, forged transmits).
• Нельзя использовать одну и ту же шару одновременно и как SMB, и как NFS.
• vSAN File Services не предназначен для создания NFS датасторов, на которые будут смонтированы хосты ESXi и запускаться виртуальные машины — только файловые шары для сервисов/гостевых систем.
• Если требуется репликация содержимого файловых шар — её нужно организовывать вручную (например, средствами операционной системы или приложений), так как vSAN File Services не предлагает встроенной гео-репликации.
• При кастомной и сложной сетевой архитектуре (например, stretched-кластер) — рекомендуется внимательно проектировать размещение контейнеров, IP-адресов, маршрутизации и правил site-affinity.

Технические выводы для администратора vSAN

• Если вы уже используете vSAN — vSAN File Services даёт возможность расширить функциональность хранения до полноценного файлового — без дополнительного железа и без отдельного файлера.
• Это удобно для унификации: блочное + файловое хранение + облачные/контейнерные нагрузки — всё внутри vSAN.
• Управление и мониторинг централизованы: через vSphere Client/vCenter, с известными инструментами, что снижает операционную сложность.
• Подходит для «гибридных» сценариев: Windows + Linux + контейнеры, централизованные файлы, общие репозитории, home-директории, данные для приложений.
• Можно использовать в небольших и распределённых средах — филиалы, edge, remote-офисы — с минимальным оверхэдом.

В VMware Cloud Foundation (VCF) 9.0 легко упустить из виду относительно новые функции, находящиеся прямо перед глазами. Защита данных в частном облаке в последнее время стала особенно актуальной темой, выходящей далеко за рамки обычных задач восстановления данных. Клиенты ищут практичные стратегии защиты от атак вымогателей и аварийного восстановления с помощью решений, которыми легко управлять в масштабах всей инфраструктуры.

vSAN Data Protection впервые появилась в vSAN 8 U3 как часть VMware Cloud Foundation 5.2. Наиболее часто упускаемый момент — это то, что vSAN Data Protection входит в лицензию VCF!

Почему это важно? Если вы используете vSAN ESA в своей среде VCF, у вас уже есть всё необходимое для локальной защиты рабочих нагрузок с помощью vSAN Data Protection. Это отличный способ дополнить существующие стратегии защиты или создать основу для более комплексной.

Рассмотрим кратко, что может предложить эта локальная защита и как просто и масштабируемо её внедрить.

Простая локальная защита

Как часть лицензии VCF, vSAN Data Protection позволяет использовать снапшоты именно так, как вы всегда хотели. Благодаря встроенному механизму создания снапшотов vSAN ESA, вы можете:

• Легко определять группы ВМ и их расписание защиты и хранения — до 200 снапшотов на ВМ.
• Создавать согласованные по сбоям снапшоты ВМ с минимальным влиянием на производительность.
• Быстро восстанавливать одну или несколько ВМ прямо в vCenter Server через vSphere Client, даже если они были удалены из инвентаря.

Поскольку vSAN Data Protection работает на уровне ВМ, защита и восстановление отдельных VMDK-дисков внутри виртуальной машины пока не поддерживается.

Простое и гибкое восстановление

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

Например, обновление ОС виртуальной машины не удалось или произошла ошибка конфигурации — vSAN Data Protection готова обеспечить быстрое и простое восстановление. Или, допустим, виртуальная машина была случайно удалена из инвентаря. Ранее ни один тип снимков VMware не позволял восстановить снимок удалённой ВМ, но vSAN Data Protection справится и с этим.

Обратите внимание, что восстановление виртуальных машин в демонстрации выше выполняется напрямую в vSphere Client, подключённом к vCenter Server. Не нужно использовать дополнительные приложения, и поскольку процесс основан на уровне ВМ, восстановление интуитивно понятное и безопасное — без сложностей, связанных с восстановлением на основе снимков хранилища (array-based snapshots).

Для клиентов, уже внедривших vSAN Data Protection, такая простота восстановления стала одной из наиболее ценных возможностей решения.

Быстрое и гибкое клонирование

Преимущества автоматизированных снапшотов, создаваемых с помощью vSAN Data Protection, выходят далеко за рамки восстановления данных. С помощью vSAN Data Protection можно легко создавать клоны виртуальных машин из существующих снапшотов. Это чрезвычайно простой и эффективный по использованию пространства способ получить несколько ВМ для различных задач.

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

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

Обратите внимание, что клонированная виртуальная машина, созданная из снапшота в vSAN Data Protection, представляет собой связанную копию (linked clone). Такой клон не может быть впоследствии защищён с помощью групп защиты и снапшотов в рамках vSAN Data Protection. Клон можно добавить в группу защиты, однако при следующем цикле защиты для этой группы появится предупреждение «Protection Group Health», указывающее, что создание снапшота для клонированной ВМ не удалось.

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

С чего начать

Так как функции защиты данных уже включены в вашу лицензию VCF, как приступить к работе? Рассмотрим краткий план.

Установка виртуального модуля для vSAN Data Protection

Для реализации описанных возможностей требуется установка виртуального модуля (Virtual Appliance) — обычно одного на каждый vCenter Server. Этот виртуальный модуль VMware Live Recovery (VLR) обеспечивает работу службы vSAN Data Protection, входящей в состав VCF, и предоставляет локальную защиту данных. Оно управляет процессом создания и координации снимков, но не участвует в передаче данных и не является единой точкой отказа.

Базовые шаги для развертывания и настройки модуля:

1. Загрузите виртуальный модуль для защиты данных с портала Broadcom.
2. Войдите в vSphere Client, подключённый к нужному vCenter Server, и разверните модуль как обычный OVF-шаблон.
3. После установки откройте веб-браузер, укажите IP-адрес модуля и завершите его настройку.

Более подробную информацию можно найти в руководстве «Deploy the VMware Live Recovery Appliance» для VCF 9.0 в TechDocs.

Настройка групп защиты

Защита виртуальных машин осуществляется с помощью групп защиты (protection groups), которые определяют желаемую стратегию защиты ВМ. Вы можете управлять тем, какие ВМ будут защищены, как часто выполняется защита, а также настройками хранения снапшотов.

Группы защиты также позволяют указать, должны ли снапшоты быть неизменяемыми (immutable) — всё это настраивается с помощью простого флажка в интерфейсе.

Неизменяемость гарантирует, что снапшоты не могут быть каким-либо образом изменены или удалены. Эта опция обеспечивает базовую защиту от вредоносных действий и служит основой для более продвинутых механизмов киберустойчивости (cyber resilience).

Давайте посмотрим, насколько просто это реализуется в интерфейсе. Сначала рассмотрим настройку группы защиты в vSphere Client.

Группы защиты начинают выполнять заданные параметры сразу после создания первого снапшота. Это отличный пример принципа «настроил и забыл» (set it and forget it), реализованного в vSAN Data Protection, который обеспечивает простое и интуитивное восстановление одной или нескольких виртуальных машин при необходимости.

Рекомендация: если вы используете динамические шаблоны имен ВМ в группах защиты, убедитесь, что виртуальные машины, созданные из снапшотов в vSAN Data Protection, не попадают под этот шаблон. В противном случае будет сгенерировано предупреждение о состоянии группы защиты (Health Alert), указывающее, что связанный клон не может быть защищён в рамках этой группы.

Расширенные возможности в VCF 9.0

В версии VCF 9.0 vSAN Data Protection получила ряд улучшений, которые сделали её ещё более удобной и функциональной.

Единый виртуальный модуль

Независимо от того, используете ли вы только локальную защиту данных через vSAN Data Protection или расширенные возможности репликации и аварийного восстановления (DR), теперь для этого используется единый виртуальный модуль, доступный для загрузки по ссылке.

Он сокращает потребление ресурсов, упрощает управление и позволяет расширять функциональность для DR и защиты от программ-вымогателей путём простого добавления лицензионного ключа.

Защита ВМ на других кластерах vSAN

Хотя vSAN Data Protection обеспечивает простой способ локальной защиты рабочих нагрузок, новая технология, представленная в VCF 9.0, позволяет реплицировать данные на другой кластер vSAN — механизм, известный как vSAN-to-vSAN replication.

Для использования vSAN-to-vSAN репликации требуется дополнительная лицензия (add-on license). Если она отсутствует, вы по-прежнему можете использовать локальную защиту данных с помощью vSAN Data Protection. Однако эта лицензия предоставляет не только возможность удалённой репликации — она также добавляет инструменты для комплексной защиты данных и оркестрации, помогая выполнять требования по аварийному восстановлению (DR) и кибербезопасности.

Иными словами, все базовые возможности локальной защиты вы можете реализовать с помощью vSAN Data Protection. А когда придёт время расширить защиту для сценариев аварийного восстановления (DR) и восстановления после киберинцидентов (cyber recovery), это можно сделать просто — активировав дополнительные возможности с помощью add-on лицензии.

Для ответов на часто задаваемые вопросы о vSAN Data Protection см. раздел «vSAN Data Protection» в актуальной версии vSAN FAQs.

Итоги

Клиенты VCF, использующие vSAN ESA в составе VCF 5.2 или 9.0, уже обладают невероятно мощным инструментом, встроенным в их решение. vSAN Data Protection обеспечивает возможность локальной защиты рабочих нагрузок без необходимости приобретения дополнительных лицензий.

Современная инфраструктура не прощает простоев. Любая потеря доступности данных — это не только бизнес-риск, но и вопрос репутации.
VMware vSAN, будучи ядром гиперконвергентной архитектуры VMware Cloud Foundation, всегда стремился обеспечивать высокую доступность и устойчивость хранения. Но с появлением Express Storage Architecture (ESA) подход к отказоустойчивости изменился фундаментально.

Документ vSAN Availability Technologies (часть VCF 9.0) описывает, как именно реализована устойчивость на уровне данных, сетей и устройств. Разберём, какие технологии стоят за доступностью vSAN, и почему переход к ESA меняет правила игры.

Архитектура отказоустойчивости: OSA против ESA

OSA — классика, но с ограничениями

Original Storage Architecture (OSA) — традиционный вариант vSAN, основанный на концепции дисковых групп (disk groups):

• Одно кэш-устройство (SSD)
• Несколько накопителей ёмкости (HDD/SSD)

Проблема в том, что выход из строя кеш-диска делает всю группу недоступной. Кроме того, классическая зеркальная защита (RAID-1) неэффективна по ёмкости: чтобы выдержать один отказ, приходится хранить копию 1:1.

ESA — новое поколение хранения

Express Storage Architecture (ESA) ломает эту модель:

• Нет больше disk groups — каждый накопитель независим.
• Используется кодирование erasure coding (RAID-5/RAID-6) как стандарт, без потери производительности.
• Архитектура разделена на performance leg и capacity leg — баланс скорости и надёжности.
• Встроен мониторинг NVMe-износа, зеркалирование метаданных и прогноз отказов устройств.

В результате ESA уменьшает "зону взрыва" при сбое и повышает эффективность хранения до 30–50 %, особенно при политике FTT=2.

Как vSAN обеспечивает доступность данных

Всё в vSAN строится вокруг объектов (диски ВМ, swap, конфигурации). Каждый объект состоит из компонентов, которые распределяются по узлам.
Доступность объекта определяется параметром FTT (Failures To Tolerate) — числом отказов, которые система выдержит без потери данных.

Например:

• FTT=1 (RAID-1) — один отказ хоста или диска.
• FTT=2 (RAID-6) — два отказа одновременно.
• RAID-5/6 обеспечивает ту же устойчивость, но с меньшими затратами ёмкости.

Механизм кворума

Каждый компонент имеет "голос". Объект считается доступным, если более 50 % голосов доступны. Это предотвращает split-brain-ситуации, когда две части кластера считают себя активными.

В сценариях 2-Node или stretched-cluster добавляется witness-компонент — виртуальный "свидетель", решающий, какая часть кластера останется активной.

Домены отказов и географическая устойчивость

vSAN позволяет группировать узлы в домены отказов — например, по стойкам, стойкам или площадкам. Данные и компоненты одной ВМ никогда не размещаются в пределах одного домена, что исключает потерю данных при отказе стойки или сайта.

В растянутом кластере (stretched cluster) домены соответствуют сайтам, а witness appliance располагается в третьей зоне для арбитража.

Рекомендация: проектируйте кластер не по минимуму (3–4 узла), а с запасом. Например, для FTT=2 нужно минимум 6 узлов, но VMware рекомендует 7, чтобы система могла восстановить избыточность без потери устойчивости.

Поведение при сбоях: состояния компонентов

vSAN отслеживает каждое состояние компонентов:

Компоненты в состоянии Absent ждут по умолчанию 60 минут перед восстановлением — чтобы избежать лишнего трафика из-за кратковременных сбоев.
Если восстановление невозможно, создаётся новая копия на другом узле.

Сеть как основа устойчивости

vSAN — это распределённое хранилище, и его надёжность напрямую зависит от сети.

• Транспорт — TCP/unicast с внутренним протоколом Reliable Datagram Transport (RDT).
• Поддерживается RDMA (RoCE v2) для минимизации задержек.
• Рекомендуется:
  • 2 NIC на каждый хост;
  • Подключение к разным коммутаторам;
  • Active/Standby teaming для vSAN-трафика (предсказуемые пути).

Если часть сети теряет связность, vSAN формирует partition groups и использует кворум, чтобы определить, какая группа "основная". vSAN тесно интегрирован с vSphere HA, что обеспечивает синхронное понимание состояния сети и автоматический рестарт ВМ при отказах.

Ресинхронизация и обслуживание

Resync (восстановление)

Когда хост возвращается в строй или изменяется политика, vSAN ресинхронизирует данные для восстановления FTT-уровня. В ESA ресинхронизация стала интеллектуальной и возобновляемой (resumable) — меньше нагрузка на сеть и диски.

Maintenance Mode

При вводе хоста в обслуживание доступны три режима:

1. Full Data Migration — полная миграция данных (долго, безопасно).
2. Ensure Accessibility — минимальный перенос для сохранения доступности (дефолт).
3. No Data Migration — без переноса (быстро, рискованно).

ESA использует durability components, чтобы временно сохранить данные и ускорить возврат в строй.

Предиктивное обслуживание и мониторинг

VMware внедрила целый ряд механизмов прогнозирования и диагностики:

• Degraded Device Handling (DDH) — анализ деградации накопителей по задержкам и ошибкам до фактического отказа.
• NVMe Endurance Tracking — контроль износа NVMe с предупреждениями в vCenter.
• Low-Level Metadata Resilience — зеркалирование метаданных для защиты от URE-ошибок.
• Proactive Hardware Management — интеграция с OEM-телеметрией и предупреждения через Skyline Health.

Эти механизмы в ESA работают точнее и с меньшими ложными срабатываниями по сравнению с OSA.

Доступность не равно защита данных

VMware подчёркивает разницу между понятиями:

• Availability — локальная устойчивость (хост, диск, сеть).
• Disaster Recovery — восстановление после катастрофы (вторая площадка, репликация, резервное копирование).

vSAN отвечает за первое. Для второго используются VMware SRM, vSphere Replication и внешние DR-решения. Однако комбинация vSAN ESA + stretched cluster уже позволяет реализовать site-level resilience без отдельного DR-инструмента.

Практические рекомендации

1. Используйте ESA при проектировании новых кластеров.
   Современные NVMe-узлы и сети 25 GbE позволяют реализовать отказоустойчивость без потери производительности.
2. Проектируйте с запасом по хостам.
   Один дополнительный узел обеспечит восстановление без снижения FTT-уровня.
3. Настройте отказоустойчивую сеть.
   Два интерфейса, разные коммутаторы, Route Based on Port ID — минимальные требования для надёжного vSAN-трафика.
4. Следите за здоровьем устройств.
   Активируйте DDH и NVMe Endurance Monitoring, используйте Skyline Health для предиктивного анализа.
5. Планируйте обслуживание грамотно.
   Режим Ensure Accessibility — оптимальный баланс между безопасностью и скоростью.

Заключение

VMware vSAN уже давно стал стандартом для гиперконвергентных систем, но именно с Express Storage Architecture он сделал шаг от "устойчивости" к "самоисцеляемости". ESA сочетает erasure coding, предиктивную аналитику и глубокую интеграцию с платформой vSphere, обеспечивая устойчивость, производительность и эффективность хранения. Для архитекторов и инженеров это значит одно: устойчивость теперь проектируется не как надстройка, а как неотъемлемая часть самой архитектуры хранения.

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

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

Однако дедупликация в vSAN для VCF 9.0 — это не просто долгожданная функция в поиске идеального решения для хранения данных. Новый подход использует распределённую архитектуру vSAN и повышает её способность к дедупликации данных по мере роста размера кластера. Кроме того, эта технология отлично сочетается с моделью лицензирования VCF, которая включает хранилище vSAN в состав вашей лицензии.

Благодаря этому глобальная дедупликация vSAN становится более эффективной с точки зрения экономии пространства и значительно доступнее, чем использование VCF с другими решениями для хранения данных. Если рассматривать совокупную стоимость владения (TCO), как описано далее, то использование VCF с vSAN обходится до 34% дешевле, чем VCF с конкурирующим хранилищем в инфраструктуре с 10 000 ядрами. По внутренним оценкам VMware, в этой же модели одна только глобальная дедупликация vSAN может снизить общую стоимость VCF до 4% — что примерно соответствует 10 миллионам долларов! Давайте посмотрим, как особенности глобальной дедупликации vSAN могут помочь сократить расходы на ваше виртуальное частное облако с использованием VCF.

Измерение эффективности

Чтобы правильно понять преимущества дедупликации, необходимо иметь метод оценки её эффективности. Эффективность дедупликации обычно выражается в виде коэффициента, показывающего объём данных до дедупликации и после неё. Чем выше коэффициент, тем больше экономия ёмкости. Такой коэффициент также может отображаться без «:1» — например, вместо «4:1» будет показано «4x».

Хотя коэффициент дедупликации легко понять, к сожалению, системы хранения могут измерять его по-разному. Некоторые показывают эффективность дедупликации только как общий коэффициент «сжатия данных», включая в него такие методы, как сжатие данных, клонирование и выделение пространства под тонкие (thin) тома. Другие могут отображать коэффициенты дедупликации, исключая метаданные и другие накладные расходы, которые не учитываются в измерении. Это важно понимать, если вы сравниваете эффективность дедупликации между системами хранения.

На эффективность дедупликации в системе хранения влияет несколько факторов, включая, но не ограничиваясь:

• Архитектурой системы дедупликации. Системы хранения часто проектируются с учётом компромиссов между эффективностью и затратами, что и определяет разные подходы к дедупликации.
• Размером/гранулярностью дедупликации. Это единица данных, по которой осуществляется поиск дубликатов. Чем меньше гранулярность, тем выше вероятность нахождения совпадений.
• Объёмом данных в пределах домена дедупликации. Обычно, чем больше объём данных, тем выше вероятность, что они будут дедуплицированы с другими данными.
• Сходством данных. Единица данных должна полностью совпадать с другой единицей, прежде чем дедупликация принесёт пользу. Иногда приложения могут использовать шифрование или другие методы, которые снижают возможность дедупликации данных.
• Характеристиками данных и рабочих нагрузок. Данные, создаваемые приложением, могут быть более или менее благоприятны для дедупликации. Например, структурированные данные, такие как OLTP-базы, обычно содержат меньше потенциальных дубликатов, чем неструктурированные данные.

Последние два пункта относятся к рабочим нагрузкам и наборам данных, уникальным для клиента. Именно они часто объясняют, почему одни данные лучше поддаются дедупликации, чем другие. Но при этом архитектура системы хранения играет ключевую роль в эффективности дедупликации. Может ли она выполнять дедупликацию с минимальным вмешательством в рабочие нагрузки? Может ли выполнять её с высокой степенью детализации и в широком домене дедупликации для максимальной эффективности? Глобальная дедупликация vSAN была разработана для обеспечения лучших результатов при минимальном влиянии на рабочие процессы.

Простой внутренний тест продемонстрировал превосходство архитектуры vSAN. На массиве конкурента было создано 50 полных клонов, и столько же — на vSAN. С учётом возможностей дедупликации и сжатия массив показал общий коэффициент сжатия данных 41.3 к 1. vSAN достиг коэффициента 45.27 к 1. Это наглядно демонстрирует впечатляющую эффективность дедупликации vSAN, усиленную сжатием данных для ещё большей экономии. Хотя этот пример не является репрезентативным для показателей дедупликации на произвольных наборах данных, он демонстрирует эффективность дедупликации в vSAN.

Масштабирование ради повышения эффективности

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

Традиционные модульные массивы хранения, как правило, не были изначально спроектированы как распределённые масштабируемые решения. Их домен дедупликации обычно ограничен одним массивом. Когда клиенту необходимо масштабироваться путём добавления ещё одного массива, домен дедупликации разделяется. Это означает, что идентичные данные могут находиться на двух разных массивах, но не могут быть дедуплицированы между ними, поскольку домен дедупликации не увеличивается при добавлении нового хранилища.

Глобальная дедупликация vSAN работает иначе. Она использует преимущества распределённой архитектуры масштабирования vSAN. В кластере vSAN весь кластер является доменом дедупликации, что означает, что по мере добавления новых хостов домен дедупликации автоматически расширяется. Это увеличивает вероятность нахождения повторяющихся данных и обеспечивает рост коэффициента дедупликации.

На рисунке ниже показан этот пример:

• Слева изображён традиционный модульный массив хранения, обеспечивающий коэффициент дедупликации 6:1. Если добавить ещё один массив, каждый из них по отдельности может обеспечить тот же коэффициент 6:1, но система теряет возможность дедуплицировать данные между массивами.
• Справа показан кластер vSAN из 6 хостов, обеспечивающий коэффициент дедупликации 6:1. По мере добавления новых хостов любые данные, размещённые на этих хостах, входят в тот же домен дедупликации, что и исходные 6 хостов. Это означает, что коэффициент дедупликации будет увеличиваться по мере добавления хостов и роста общего объёма данных.

Использование того, что уже есть

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

Модель лицензирования vSAN в составе VCF в сочетании с глобальной дедупликацией vSAN образует выигрышную комбинацию. Каждая лицензия на ядро VCF включает 1 TiB «сырой» ёмкости vSAN. Но благодаря глобальной дедупликации весь объём, который удалось освободить, напрямую работает в вашу пользу!

Например, кластер vSAN из 6 хостов, каждый из которых содержит по 32 ядра, предоставит 192 TiB хранилища vSAN в рамках лицензирования VCF. Если этот кластер обеспечивает коэффициент дедупликации 6:1, то можно хранить почти 1.2 PiB данных, используя только имеющуюся лицензию.

Реальная экономия затрат

Когда хранилище предоставляется как часть лицензии VCF, логично, что затраты на хранение снижаются, поскольку требуется меньше дополнительных покупок. В примере ниже мы сравниваем эффективную цену за 1 ТБ при использовании VCF с конкурентным массивом хранения с дедупликацией для обслуживания рабочих нагрузок уровня Tier-1 и при использовании vSAN с VCF 9.0.

Так как наборы данных представляли собой структурированные данные (SQL), коэффициенты сжатия были весьма скромными. Однако, исходя из модели с 10 000 ядер VCF при предполагаемом уровне загрузки CPU и стоимости лицензирования:

• Эффективная цена за ТБ уже на 14% ниже при использовании только сжатия данных в vSAN.
• А при использовании дедупликации и сжатия в vSAN стоимость хранения (цена за ТБ) становится ниже на 29%.

По собственным оценкам VMware, совокупная стоимость владения (TCO) для VCF может быть снижена до 34%.

Для этого сравнения также рассматривалась среда с 10 000 ядер VCF при предполагаемом уровне загрузки CPU и стоимости лицензирования. Даже с учётом дополнительных расходов на стороннее решение для резервного копирования, стоимость хранения в vSAN оказалась на 13% ниже за каждый терабайт.

Если вы заинтересованы попробовать эту функцию в релизе P01 VCF 9.0, вы можете связаться с Broadcom для получения подробной информации через эту форму. В первую очередь внимание будет уделяться клиентам, которые хотят включить её на односайтовых vSAN HCI или кластерах хранения vSAN размером от 3 до 16 хостов с использованием сетей 25GbE или быстрее. На начальном этапе некоторые топологии, такие как растянутые кластеры, а также некоторые сервисы данных, например, шифрование данных at rest, не будут поддерживаться при использовании этой функции.

Итоги

VMware считает, что глобальная дедупликация для vSAN в VCF 9.0 будет не хуже, а скорее всего лучше, чем решения по дедупликации у других поставщиков систем хранения. Учитывая, что клиенты VCF получают 1 TiB сырой ёмкости vSAN на каждое лицензированное ядро VCF, это открывает огромный потенциал: вы можете обеспечить всю необходимую ёмкость хранения, используя только существующее лицензирование, и при этом снизить затраты до минимума.

Недавно мы рассказали об улучшениях и нововведениях платформы VMware Cloud Foundation 9.0, включающей в себя платформу виртуализации VMware vSphere 9.0 и средство создания отказоустойчивой инфраструктуры хранения VMware vSAN 9.0. Посмотрим теперь, что нового эти продукты включают с точки зрения сервисов хранилищ (Core Storage).

Улучшения поддержки хранилищ VCF

Для новых (greenfield) развёртываний VCF теперь поддерживаются хранилища VMFS, Fibre Channel и NFSv3 в качестве основных вариантов хранилища для домена управления. Полную информацию о поддержке хранилищ см. в технической документации VCF 9.

Улучшения NFS

Поддержка TRIM для NFS v3

Существующая поддержка команд TRIM и UNMAP позволяет блочным хранилищам, таким как vSAN и хранилища на базе VMFS, освобождать место после удаления файлов в виртуальной машине или при многократной записи в один и тот же файл. В типичных средах это позволяет освободить до 30% пространства, обеспечивая более эффективное использование ёмкости. С использованием плагина VAAI NFS системы NAS, подключённые через NFSv3, теперь могут выполнять освобождение пространства в VCF 9.

Шифрование данных в процессе передачи для NFS 4.1

Krb5p шифрует трафик NFS при передаче. Шифрование данных «на лету» защищает данные при передаче между хостами и NAS, предотвращая несанкционированный доступ и обеспечивая конфиденциальность информации организации, особенно в случае атак типа «man-in-the-middle». Также будет доступен режим Krb5i, который не выполняет шифрование, но обеспечивает проверку целостности данных, исключая их подмену.

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

Сквозная (End-to-End, E2E) поддержка 4Kn

В версии 9.0 реализована поддержка E2E 4Kn, включающая:

• Фронтэнд — представление виртуальных дисков (VMDK) с сектором 4K для виртуальных машин.
• Бэкэнд — использование SSD-накопителей NVMe с 4Kn для vSAN ESA. OSA не поддерживает 4Kn SSD.
• ESXi также получает поддержку 4Kn SSD с интерфейсом SCSI для локального VMFS и внешних хранилищ.

SEsparse по умолчанию для снимков с NFS и VMFS-5

Исторически, создание снимков (snapshots) имело значительное влияние на производительность ввода-вывода.
Формат Space Efficient Sparse Virtual Disks (SEsparse) был разработан для устранения двух основных проблем формата vmfsSparse:

1. Освобождение пространства при использовании снимков — SEsparse позволяет выполнять более точную и настраиваемую очистку места, что особенно актуально для VDI-сценариев.

2. Задержки чтения и снижение производительности из-за множественных операций чтения при работе со снимками.

Производительность была повышена благодаря использованию вероятностной структуры данных, такой как Bloom Filter, особенно для снимков первого уровня. Также появилась возможность настраивать размер блока (grain size) в SEsparse для соответствия типу используемого хранилища.

SEsparse по умолчанию применяется к VMDK объёмом более 2 ТБ на VMFS5, начиная с vSphere 7 Update 2. В vSphere 9 SEsparse становится форматом по умолчанию для всех VMDK на NFS и VMFS-5, независимо от размера. Это уменьшит задержки и увеличит пропускную способность чтения при работе со снимками. Формат SEsparse теперь также будет использоваться с NFS, если не используется VAAI snapshot offload plugin.

Поддержка спецификации vNVMe 1.4 — команда Write Zeroes

С выходом версии 9.0 поддержка NVMe 1.4 в виртуальном NVMe (vNVMe) позволяет гостевой ОС использовать команду NVMe Write Zeroes — она устанавливает заданный диапазон логических блоков в ноль. Эта команда аналогична SCSI WRITE_SAME, но ограничена только установкой значений в ноль.

Поддержка нескольких соединений на сессию iSCSI (Multiple Connections per Session)

Рекомендуется использовать iSCSI с Multi-path I/O (MPIO) для отказоустойчивого подключения к хостам. Это требует отдельных физических путей для каждого порта VMkernel и отказа от использования failover на базе состояния соединения или агрегацию сетевых интерфейсов (NIC teaming) или Link Aggregation Group (LAG), поскольку такие методы не обеспечивают детерминированный выбор пути.

Проблема: iSCSI традиционно использует одиночное соединение, что делает невозможным распределение трафика при использовании NIC teaming или LAG.

Решение — iSCSI с несколькими соединениями в рамках одной сессии, что позволяет:

1. Использовать несколько каналов, если один порт VMkernel работает в составе LAG с продвинутыми алгоритмами хеширования.

2. Повысить пропускную способность, когда скорость сети превышает возможности массива обрабатывать TCP через один поток соединения.

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

Выведенные из эксплуатации технологии

• Устаревание NPIV

Как VMware предупреждала ранее, технология N-Port ID Virtualization (NPIV) была признана устаревшей и в версии 9.0 больше не поддерживается.

• Устаревание гибридной конфигурации в оригинальной архитектуре хранения vSAN (OSA)

Гибридная конфигурация в vSAN Original Storage Architecture будет удалена в одном из будущих выпусков платформы VCF.

• Устаревание поддержки vSAN over RDMA

Поддержка vSAN поверх RDMA для архитектуры vSAN OSA также будет прекращена в будущем выпуске VCF.

• Устаревание поддержки RVC и зависимых Ruby-компонентов

Начиная с версии VCF 9.0, Ruby vSphere Console (RVC) и её компоненты на базе Ruby (такие как Rbvmomi) в составе vCenter считаются устаревшими. RVC, ранее использовавшаяся технической поддержкой для тестирования и мониторинга систем, уже была признана устаревшей, начиная с vSAN 7.0.

Для задач мониторинга и сопровождения Broadcom рекомендует использовать PowerCLI, DCLI или веб-интерфейс vCenter (UI), поскольку они теперь предоставляют весь функционал, ранее доступный в RVC. RVC и все связанные с ней Ruby-компоненты будут окончательно удалены в одном из будущих выпусков VCF.

Object First — это компания, основанная Ратмиром Тимашевым, одним из легендарных сооснователей Veeam Software. После того как Veeam был продан инвестиционной компании Insight Partners за $5 млрд в 2020 году, Тимашев отошел от операционного управления компанией, но остался в ИТ-индустрии. Его новым проектом стала Object First, цель которой — предложить максимально простое, защищенное и производительное решение для хранения резервных копий, оптимизированное под решения Veeam.

Цели и философия Object First

Object First была создана с четким пониманием болевых точек ИТ-отделов: сложность настройки хранилищ, высокая стоимость масштабируемых решений и растущие угрозы кибератак, в том числе программ-вымогателей. Команда Object First стремится решить эти проблемы с помощью подхода "Secure by Design" и глубокой интеграции с Veeam Backup and Replication.

Что такое Ootbi?

Флагманский продукт Object First называется Ootbi ("Out-of-the-box immutability") — это on-premise объектное хранилище, специально созданное для Veeam. Основные технические особенности Ootbi:

• Готовность к работе "из коробки": решение поставляется в виде готового устройства, не требующего глубокой предварительной настройки.
• Поддержка объектного хранилища S3: Ootbi работает по протоколу S3 и полностью совместим с Veeam Backup & Replication.
• Неизменяемость данных (immutability): встроенная защита от программ-вымогателей (Ransomware). Используются политики WORM (Write Once, Read Many), гарантирующие, что резервные копии не могут быть удалены или изменены в течение заданного периода (даже с административными привилегиями).
• Интеграция с Veeam через Scale-Out Backup Repository (SOBR): Ootbi можно использовать как capacity tier, обеспечивая гибкое и масштабируемое резервное копирование.
• Безопасность и упрощенное администрирование: не требуется root-доступ или отдельные операционные системы. Решение изолировано и минимизирует человеческий фактор.

Аппаратная архитектура

На данный момент Ootbi представляет собой масштабируемую кластерную систему из 2-4 узлов:

• Каждый узел содержит вычислительные ресурсы и локальное хранилище (HDD и SSD для кэширования).
• Используется распределённая файловая система, обеспечивающая отказоустойчивость и высокую доступность.
• Производительность: до 4 ГБ/сек совокупной пропускной способности, до 1 ПБ эффективного объема хранения с учетом дедупликации и компрессии на стороне Veeam.

Преимущества для клиентов

• Минимизация риска потери данных благодаря immutability и встроенной защите.
• Снижение TCO (total cost of ownership) за счет простоты управления и отказа от сложных инфраструктур.
• Быстрое развёртывание: установка и настройка возможна за считанные часы.
• Отсутствие необходимости в публичном облаке, что важно для компаний с повышенными требованиями к безопасности и локализации данных.

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

Начиная с ноября 2024 года, VMware vSphere Foundation (VVF) начала включать 0,25 ТиБ ёмкости vSAN на одно ядро для всех новых лицензий VVF. С выходом обновления vSphere 8.0 U3e это преимущество распространяется и на существующих клиентов — теперь им также доступна ёмкость vSAN из расчёта 0,25 ТиБ (аналог терабайта) на ядро. Это новое право на использование включает дополнительные преимущества, которые повышают ценность vSAN в составе VVF.

Вот как это работает:

Ёмкость vSAN агрегируется по всей инфраструктуре, что позволяет перераспределять неиспользованные ресурсы с кластеров, содержащих только вычислительные узлы, на кластеры с включённым vSAN. Это помогает оптимизировать использование ресурсов в рамках всей инфраструктуры.

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

• Больше никаких ограничений пробной версии: включённые 0,25 ТиБ на ядро теперь полностью предоставлены по лицензии, а не в рамках пробного периода.
• Агрегация ёмкости: объединяйте хранилище между кластерами и используйте его там, где это нужнее всего.
• Упрощённое масштабирование: если требуется больше хранилища, чем предусмотрено по включённой норме — достаточно просто докупить нужный объём сверх этой квоты.

Почему это важно

Благодаря этому обновлению VMware vSphere Foundation становится ещё более привлекательным решением для организаций, стремящихся модернизировать и унифицировать свою ИТ-инфраструктуру. Поддерживая как виртуальные машины, так и контейнеры, vSAN добавляет возможности гиперконвергентной инфраструктуры (HCI) корпоративного уровня. Интеграция вычислений, хранения и управления в единую платформу упрощает операционные процессы, снижает сложность и обеспечивает комплексное решение с встроенной безопасностью и масштабируемостью.

Дополнительная ёмкость vSAN в составе VMware vSphere Foundation значительно повышает ценность платформы — будь то оптимизация частного облака, повышение гибкости разработки или упрощение ИТ-операций. Это даёт больше контроля и гибкости над инфраструктурой, снижая совокупную стоимость владения и минимизируя операционные издержки.

Чтобы начать пользоваться бесплатной лицензией VMware vSAN загрузите патч vSphere 8.0 Update 3e по этой ссылке.

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

Количество хостов в кластере

Количество хостов в кластере VMware vSAN напрямую влияет на масштабируемость, производительность и отказоустойчивость. Минимальные требования тут такие:

• Кластер из 2 хостов — минимальная конфигурация, поддерживаемая внешней witness-машиной для обеспечения кворума. Такая настройка является экономичной, но не обладает продвинутыми функциями и масштабируемостью.
• Кластер из 3 хостов — устраняет необходимость в выделенном witness-узле и обеспечивает базовую избыточность с использованием RAID 1.

Несмотря на эти минимальные требования, VMware рекомендует использовать не менее 4 хостов для производственных сред. Кластер из 4 и более хостов позволяет использовать конфигурации RAID 5 и RAID 6, обеспечивая защиту до двух отказов одновременно (в этом случае потребуется больше 4 хостов ESXi) и поддерживая операции обслуживания отдельных хостов ESXi без потери доступности машин кластера.

• Используйте не менее 4-х хостов для производственной среды, чтобы обеспечить отказоустойчивость и надежность.
• Для критически важных нагрузок добавляйте дополнительные хосты ESXi при росте инфраструктуры и обеспечивайте дополнительную резервную емкость на случай отказов.

Если вы хотите использовать RAID 5/6 в кластере vSAN, то вам нужно принять во внимание требования к количеству хостов ESXi, которые минимально (и рекомендуемо) вам потребуются, чтобы удовлетворять политике FTT (Failures to tolerate):

Домены отказов (Fault Domains)

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

Домен отказов — это логическая группа хостов в кластере vSAN. По умолчанию vSAN рассматривает каждый хост как отдельный домен отказов. Однако в крупных развертываниях администраторы могут вручную настроить домены отказов, чтобы защитить данные от отказов, связанных со стойками или электропитанием.

В больших кластерах сбой всей стойки (или группы хостов) может привести к потере данных, если домены отказов не настроены. Например:

• Без доменов отказов: vSAN может сохранить все реплики объекта на хостах внутри одной стойки, что приведет к риску потери данных в случае выхода стойки из строя.
• С доменами отказов: vSAN распределяет реплики данных между разными стойками, значительно повышая защиту данных.

• Соответствие физической инфраструктуре: создавайте домены отказов на основе стоек, подключений источников питания или сетевого сегментирования.
• Минимальные требования: для обеспечения производственной отказоустойчивости доменов требуется как минимум 3 домена отказов.
• Размер кластера:
  • Для 6-8 хостов — настройте как минимум 3 домена отказов.
  • Для кластеров с 9 и более хостами — используйте 4 и более домена отказов для оптимальной защиты.
• Тестирование и валидация: регулярно проверяйте конфигурацию доменов отказов, чтобы убедиться, что она соответствует политикам vSAN.

Архитектура дисковых групп vSAN OSA

Группы дисков (disk groups) являются строительными блоками хранилища VMware vSAN в архитектуре vSAN OSA. В архитектуре vSAN ESA дисковых групп больше нет (вместо них появился объект Storage Pool).

Дисковые группы vSAN OSA состоят из:

• Яруса кэширования (Caching Tier): нужны для ускорения операций ввода-вывода.
• Яруса емкости (Capacity Tier): хранит постоянные данные виртуальных машин.

Ярус кэширования улучшает производительность чтения и записи. Для кэширования рекомендуется использовать диски NVMe или SSD, особенно в полностью флэш-конфигурациях (All-Flash).

• Выделяйте примерно 10% от общего объема VMDK-дисков машин для яруса кэширования в гибридных конфигурациях vSAN, однако при этом нужно учесть параметр политики FTT. Более подробно об этом написано тут. Для All-Flash конфигураций такой рекомендации нет, размер кэша на запись определяется профилем нагрузки (кэша на чтение там нет).
• Используйте NVMe-диски корпоративного класса для высокопроизводительных нагрузок.

Ярус емкости содержит основную часть данных и критически важен для масштабируемости. Полностью флэш-конфигурации (All-Flash) обеспечивают максимальную производительность, тогда как гибридные конфигурации (hybrid) являются более экономичным решением для менее требовательных нагрузок.

• Используйте полностью флэш-конфигурации для приложений, чувствительных к задержкам (latency).
• Включайте дедупликацию и сжатие данных для оптимизации дискового пространства. При этом учтите требования и характер нагрузки - если у вас write-intensive нагрузка, то включение дедупликации может привести к замедлению работы системы.

Добавление нескольких групп дисков на каждом хосте улучшает отказоустойчивость и производительность.

• Настройте не менее двух групп дисков на хост.
• Равномерно распределяйте рабочие нагрузки между группами дисков, чтобы избежать узких мест.

VMware vSAN и блочные хранилища

Решения для организации блочных хранилищ, такие как Dell PowerStore и Unity, остаются популярными для традиционных ИТ-нагрузок. Вот как они выглядят в сравнении с vSAN:

Сильные и слабые стороны

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

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

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

Преимущества блочного хранилища:

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

Недостатки блочного хранилища:

• Меньшая гибкость по сравнению с гиперконвергентными решениями.
• Более высокая стоимость и сложность при первоначальном развертывании. Однако также нужно учитывать и политику лицензирования Broadcom/VMware, где цена входа также может оказаться высокой (см. комментарий к этой статье).

Развертывание баз данных на VMware vSAN

Базы данных создают сложные паттерны ввода-вывода, требующие низкой задержки (latency) и высокой пропускной способности (throughput). vSAN удовлетворяет этим требованиям за счет кэширования и конфигураций RAID.

Политики хранения (Storage Policies)

Политики хранения vSAN позволяют точно контролировать производительность и доступность баз данных.

Лучшие практики:

• Настройте параметр FTT (Failures to Tolerate) = 2 для критически важных баз данных.
• Используйте RAID 5 или RAID 6 для экономии емкостей при защите данных, если вас устраивает производительность и latency.

Регулярный мониторинг помогает поддерживать оптимальную производительность баз данных. Используйте продукт vRealize Operations для отслеживания таких метрик, как IOPS и latency.

Дункану Эппингу задали интересный вопрос: учитываются ли файлы, хранящиеся на общих хранилищах vSAN с включенным vSAN File Services, в максимальном количестве объектов (max object count)? Поскольку Дункан не обсуждал это в последние несколько лет, он решил сделать краткое напоминание.

С vSAN File Services файлы, которые пользователи хранят в своем файловом хранилище, размещаются внутри объекта vSAN. Сам объект учитывается при подсчёте максимального количества компонентов в кластере, но отдельные файлы в нем - конечно же, нет.

Что касается vSAN File Services, то для каждого созданного файлового хранилища необходимо выбрать политику. Эта политика будет применяться к объекту, который создаётся для файлового хранилища. Каждый объект, как и для дисков виртуальных машин, состоит из одного или нескольких компонентов. Именно эти компоненты и будут учитываться при подсчёте максимального количества компонентов, которое может быть в кластере vSAN.

Для одного узла vSAN ESA максимальное количество компонентов составляет 27 000, а для vSAN OSA – 9 000 компонентов на хост. Имейте в виду, что, например, RAID-1 и RAID-6 используют разное количество компонентов. Однако, как правило, это не должно быть большой проблемой для большинства клиентов, если только у вас не очень большая инфраструктура (или наоборот, небольшая, но вы на пределе возможностей по количеству хранилищ и т. д.).

В видео ниже показана демонстрация, которую Дункан проводил несколько лет назад, где исследуются эти компоненты в интерфейсе vSphere Client и с помощью CLI:

Интересный пост, касающийся использования виртуальных хранилищ NFS (в формате Virtual Appliance) на платформе vSphere и их производительности, опубликовал Marco Baaijen в своем блоге. До недавнего времени он использовал центральное хранилище Synology на основе NFSv3 и две локально подключенные PCI флэш-карты. Однако из-за ограничений драйверов он был вынужден использовать ESXi 6.7 на одном физическом хосте (HP DL380 Gen9). Желание перейти на vSphere 8.0 U3 для изучения mac-learning привело тому, что он больше не мог использовать флэш-накопители в качестве локального хранилища для размещения вложенных виртуальных машин. Поэтому Марко решил использовать эти флэш-накопители на отдельном физическом хосте на базе ESXi 6.7 (HP DL380 G7).

Теперь у нас есть хост ESXi 8 и и хост с версией ESXi 6.7, которые поддерживают работу с этими флэш-картами. Кроме того, мы будем использовать 10-гигабитные сетевые карты (NIC) на обоих хостах, подключив порты напрямую. Марко начал искать бесплатное, удобное и функциональное виртуальное NAS-решение. Рассматривал Unraid (не бесплатный), TrueNAS (нестабильный), OpenFiler/XigmaNAS (не тестировался) и в итоге остановился на OpenMediaVault (с некоторыми плагинами).

И вот тут начинается самое интересное. Как максимально эффективно использовать доступное физическое и виртуальное оборудование? По его мнению, чтение и запись должны происходить одновременно на всех дисках, а трафик — распределяться по всем доступным каналам. Он решил использовать несколько паравиртуальных SCSI-контроллеров и настроить прямой доступ (pass-thru) к портам 10-гигабитных NIC. Всё доступное пространство флэш-накопителей представляется виртуальной машине как жесткий диск и назначается по круговому принципу на доступные SCSI-контроллеры.

В OpenMediaVault мы используем плагин Multiple-device для создания страйпа (striped volume) на всех доступных дисках.

На основе этого мы можем создать файловую систему и общую папку, которые в конечном итоге будут представлены как экспорт NFS (v3/v4.1). После тестирования стало очевидно, что XFS лучше всего подходит для виртуальных нагрузок. Для NFS Марко решил использовать опции async и no_subtree_check, чтобы немного увеличить скорость работы.

Теперь переходим к сетевой части, где автор стремился использовать оба 10-гигабитных порта сетевых карт (X-соединённых между физическими хостами). Для этого он настроил следующее в OpenMediaVault:

С этими настройками серверная часть NFS уже работает. Что касается клиентской стороны, Марко хотел использовать несколько сетевых карт (NIC) и порты vmkernel, желательно на выделенных сетевых стэках (Netstacks). Однако, начиная с ESXi 8.0, VMware решила отказаться от возможности направлять трафик NFS через выделенные сетевые стэки. Ранее для этого необходимо было создать новые стэки и настроить SunRPC для их использования. В ESXi 8.0+ команды SunRPC больше не работают, так как новая реализация проверяет использование только Default Netstack.

Таким образом, остаётся использовать возможности NFS 4.1 для работы с несколькими соединениями (parallel NFS) и выделения трафика для портов vmkernel. Но сначала давайте посмотрим на конфигурацию виртуального коммутатора на стороне NFS-клиента. Как показано на рисунке ниже, мы создали два раздельных пути, каждый из которых использует выделенный vmkernel-порт и собственный физический uplink-NIC.

Первое, что нужно проверить, — это подключение между адресами клиента и сервера. Существуют три способа сделать это: от простого до более детального.

[root@mgmt01:~] esxcli network ip interface list
---
vmk1
   Name: vmk1
   MAC Address: 00:50:56:68:4c:f3
   Enabled: true
   Portset: vSwitch1
   Portgroup: vmk1-NFS
   Netstack Instance: defaultTcpipStack
   VDS Name: N/A
   VDS UUID: N/A
   VDS Port: N/A
   VDS Connection: -1
   Opaque Network ID: N/A
   Opaque Network Type: N/A
   External ID: N/A
   MTU: 9000
   TSO MSS: 65535
   RXDispQueue Size: 4
   Port ID: 134217815

vmk2
   Name: vmk2
   MAC Address: 00:50:56:6f:d0:15
   Enabled: true
   Portset: vSwitch2
   Portgroup: vmk2-NFS
   Netstack Instance: defaultTcpipStack
   VDS Name: N/A
   VDS UUID: N/A
   VDS Port: N/A
   VDS Connection: -1
   Opaque Network ID: N/A
   Opaque Network Type: N/A
   External ID: N/A
   MTU: 9000
   TSO MSS: 65535
   RXDispQueue Size: 4
   Port ID: 167772315

[root@mgmt01:~] esxcli network ip netstack list defaultTcpipStack
   Key: defaultTcpipStack
   Name: defaultTcpipStack
   State: 4660

[root@mgmt01:~] ping 10.10.10.62
PING 10.10.10.62 (10.10.10.62): 56 data bytes
64 bytes from 10.10.10.62: icmp_seq=0 ttl=64 time=0.219 ms
64 bytes from 10.10.10.62: icmp_seq=1 ttl=64 time=0.173 ms
64 bytes from 10.10.10.62: icmp_seq=2 ttl=64 time=0.174 ms

--- 10.10.10.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.173/0.189/0.219 ms

[root@mgmt01:~] ping 172.16.0.62
PING 172.16.0.62 (172.16.0.62): 56 data bytes
64 bytes from 172.16.0.62: icmp_seq=0 ttl=64 time=0.155 ms
64 bytes from 172.16.0.62: icmp_seq=1 ttl=64 time=0.141 ms
64 bytes from 172.16.0.62: icmp_seq=2 ttl=64 time=0.187 ms

--- 172.16.0.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.141/0.161/0.187 ms

root@mgmt01:~] vmkping -I vmk1 10.10.10.62
PING 10.10.10.62 (10.10.10.62): 56 data bytes
64 bytes from 10.10.10.62: icmp_seq=0 ttl=64 time=0.141 ms
64 bytes from 10.10.10.62: icmp_seq=1 ttl=64 time=0.981 ms
64 bytes from 10.10.10.62: icmp_seq=2 ttl=64 time=0.183 ms

--- 10.10.10.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.141/0.435/0.981 ms

[root@mgmt01:~] vmkping -I vmk2 172.16.0.62
PING 172.16.0.62 (172.16.0.62): 56 data bytes
64 bytes from 172.16.0.62: icmp_seq=0 ttl=64 time=0.131 ms
64 bytes from 172.16.0.62: icmp_seq=1 ttl=64 time=0.187 ms
64 bytes from 172.16.0.62: icmp_seq=2 ttl=64 time=0.190 ms

--- 172.16.0.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.131/0.169/0.190 ms

[root@mgmt01:~] esxcli network diag ping --netstack defaultTcpipStack -I vmk1 -H 10.10.10.62
   Trace: 
         Received Bytes: 64
         Host: 10.10.10.62
         ICMP Seq: 0
         TTL: 64
         Round-trip Time: 139 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 10.10.10.62
         ICMP Seq: 1
         TTL: 64
         Round-trip Time: 180 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 10.10.10.62
         ICMP Seq: 2
         TTL: 64
         Round-trip Time: 148 us
         Dup: false
         Detail: 
   Summary: 
         Host Addr: 10.10.10.62
         Transmitted: 3
         Received: 3
         Duplicated: 0
         Packet Lost: 0
         Round-trip Min: 139 us
         Round-trip Avg: 155 us
         Round-trip Max: 180 us

[root@mgmt01:~] esxcli network diag ping --netstack defaultTcpipStack -I vmk2 -H 172.16.0.62
   Trace: 
         Received Bytes: 64
         Host: 172.16.0.62
         ICMP Seq: 0
         TTL: 64
         Round-trip Time: 182 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 172.16.0.62
         ICMP Seq: 1
         TTL: 64
         Round-trip Time: 136 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 172.16.0.62
         ICMP Seq: 2
         TTL: 64
         Round-trip Time: 213 us
         Dup: false
         Detail: 
   Summary: 
         Host Addr: 172.16.0.62
         Transmitted: 3
         Received: 3
         Duplicated: 0
         Packet Lost: 0
         Round-trip Min: 136 us
         Round-trip Avg: 177 us
         Round-trip Max: 213 us

С этими положительными результатами мы теперь можем подключить NFS-ресурс, используя несколько подключений на основе vmk, и убедиться, что всё прошло успешно.

[root@mgmt01:~] esxcli storage nfs41 add --connections=8 --host-vmknic=10.10.10.62:vmk1,172.16.0.62:vmk2 --share=/fio-folder --volume-name=fio

[root@mgmt01:~] esxcli storage nfs41 list
Volume Name  Host(s)                  Share        Vmknics    Accessible  Mounted  Connections  Read-Only  Security   isPE  Hardware Acceleration
-----------  -----------------------  -----------  ---------  ----------  -------  -----------  ---------  --------  -----  ---------------------
fio          10.10.10.62,172.16.0.62  /fio-folder  vmk1,vmk2        true     true            8      false  AUTH_SYS  false  Not Supported

[root@mgmt01:~] esxcli storage nfs41 param get -v all
Volume Name  MaxQueueDepth  MaxReadTransferSize  MaxWriteTransferSize  Vmknics    Connections
-----------  -------------  -------------------  --------------------  ---------  -----------
fio             4294967295               261120                261120  vmk1,vmk2            8

Наконец, мы проверяем, что оба подключения действительно используются, доступ к дискам осуществляется равномерно, а производительность соответствует ожиданиям (в данном тесте использовалась миграция одной виртуальной машины с помощью SvMotion). На стороне NAS-сервера Марко установил net-tools и iptraf-ng для создания приведённых ниже скриншотов с данными в реальном времени. Для анализа производительности флэш-дисков на физическом хосте использовался esxtop.

root@openNAS:~# netstat | grep nfs
tcp        0    128 172.16.0.62:nfs         172.16.0.60:623         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:617         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:616         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:621         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:613         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:620         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:610         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:611         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:615         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:619         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:609         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:614         ESTABLISHED
tcp        0      0 172.16.0.62:nfs         172.16.0.60:618         ESTABLISHED
tcp        0      0 172.16.0.62:nfs         172.16.0.60:622         ESTABLISHED
tcp        0      0 172.16.0.62:nfs         172.16.0.60:624         ESTABLISHED
tcp        0      0 10.10.10.62:nfs         10.10.10.60:612         ESTABLISHED

По итогам тестирования NFS на ESXi 8 Марко делает следующие выводы:

• NFSv4.1 превосходит NFSv3 по производительности в 2 раза.
• XFS превосходит EXT4 по производительности в 3 раза (ZFS также был протестирован на TrueNAS и показал отличные результаты при последовательных операциях ввода-вывода).
• Клиент NFSv4.1 в ESXi 8.0+ не может быть привязан к выделенному/отдельному сетевому стэку (Netstack).
• Использование нескольких подключений NFSv4.1 на основе выделенных портов vmkernel работает очень эффективно.
• Виртуальные NAS-устройства демонстрируют хорошую производительность, но не все из них стабильны (проблемы с потерей NFS-томов, сообщения об ухудшении производительности NFS, увеличении задержек ввода-вывода).

Вильям Лам выложил интересный сценарий PowerCLI, который поможет вам получить информацию об использовании хранилищ и накладных расходах vSAN с использованием API.

В интерфейсе vSphere Client вы можете увидеть подробный анализ использования хранилища vSAN, включая различные системные накладные расходы, выбрав конкретный кластер vSAN, а затем перейдя в раздел Monitor->vSAN->Capacity, как показано на скриншоте ниже:

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

Недавно у Вильяма спросили - а как получить информацию о накладных расходах, связанных с дедупликацией и сжатием vSAN, с использованием PowerCLI?

Хотя командлет PowerCLI vSAN Get-VsanSpaceUsage предоставляет множество метрик использования, отображаемых в интерфейсе vSphere, он не раскрывает все свойства.

Тем не менее, мы можем использовать PowerCLI для получения этой информации, используя базовый метод vSAN API, который предоставляет эти данные, в частности querySpaceUsage(). Как видно из документации по API, этот метод возвращает массив объектов типов использования vSAN, которые соответствуют данным, отображаемым в интерфейсе vSphere, с расшифровкой свойства ObjType.

Чтобы продемонстрировать использование этого API, Вильям создал пример PowerCLI-скрипта под названием vsanUsageAndOverheadInfo.ps1, в котором вам нужно просто обновить переменную $vsanCluster, указав имя нужного кластера vSAN.

После подключения к серверу vCenter вы можете просто выполнить этот скрипт, как показано ниже:

./vsanUsageAndOverheadInfo.ps1

Вывод будет выглядеть вот так:

Недавно компания VMware сделала важный анонс относительно компонента балансировщика нагрузки ввода-вывода Storage DRS (SDRS), который включает в себя механизм балансировки нагрузки на основе reservations для SDRS I/O и контроля ввода-вывода Storage I/O Control (SIOC). Все они будут устаревшими в будущих выпусках vSphere. Анонс был сделан в рамках релиза платформы VMware vSphere 8.0 Update 3. Об этом рассказал Дункан Эппинг.

Текущие версии ESXi 8.x и 7.x продолжат поддерживать эту функциональность. Устаревание затронет балансировку нагрузки на основе задержек (latency) для ввода-вывода и балансировку на основе reservations для ввода-вывода между хранилищами в кластере хранилищ Storage DRS. Кроме того, включение SIOC на хранилище и установка reservations и приоритетов с помощью политик хранения SPBM также будут устаревшими. Начальное размещение и балансировка нагрузки Storage DRS на основе хранилищ и настроек политик хранения SPBM для лимитов не будут затронуты.

Для Storage DRS (SDRS) это означает, что функциональность «балансировки по емкости» (capacity balancing) останется доступной, но все, что связано с производительностью, будет недоступно в следующем крупном выпуске платформы. Кроме того, обработка «шумных соседей» (noisy neighbor) через SIOC с использованием приоритетов или, например, reservations ввода-вывода также больше не будет доступна.

Некоторые из вас, возможно, уже заметили, что в интерфейсе на уровне отдельных ВМ исчезла возможность указывать лимит IOPS. Что это значит для лимитов IOPS в целом? Эта функциональность останется доступной через управление на основе политик (SPBM), как и сейчас. Таким образом, если вы задавали лимиты IOPS для каждой ВМ в vSphere 7 отдельно, после обновления до vSphere 8 вам нужно будет использовать настройку через политику SPBM. Опция задания лимитов IOPS через SPBM останется доступной. Несмотря на то, что в интерфейсе она отображается в разделе «SIOC», на самом деле эта настройка применяется через планировщик дисков на уровне каждого хоста.

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

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

VMware недавно заказала исследование Key Workloads and Use Cases for Virtualized Storage у компании Enterprise Strategy Group, чтобы изучить роль гиперконвергентного хранилища, его преимущества и ключевые случаи применения, где оно оказывает значительное влияние. Рекомендации основаны на опросах сотен пользователей гиперконвергентных хранилищ, а также на тысячах реальных внедрений.

Почему хранилище является проблемой

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

Роль гиперконвергентного хранилища

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

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

Ключевые рабочие нагрузки для гиперконвергентного хранилища

VMware vSAN подходит для различных сценариев использования, демонстрируя в них свою гибкость и масштабируемость:

1. Виртуальная инфраструктура рабочих столов (VDI): с увеличением числа удаленных сотрудников виртуальные рабочие столы стали критически важными. Однако VDI требует высокой производительности, линейного масштабирования и технологий для сокращения объема данных, чтобы оптимизировать затраты на хранение. vSAN решает эту задачу, предлагая масштабируемое решение. Его архитектура поддерживает высокую производительность и различные технологии сокращения данных для минимизации требований к объему хранения.

2. Бизнес-критичные приложения: для требовательных приложений баз данных, таких как Oracle, SQL Server и SAP HANA, vSAN обеспечивает высокую производительность и масштабируемость. Архитектура vSAN Express Storage Architecture предоставляет высокую производительность и устойчивость, даже с использованием кодирования ошибок RAID 5/6 для эффективности. vSAN также позволяет независимо масштабировать вычислительные ресурсы и ресурсы хранения, что полезно для рабочих нагрузок OTLP, которые часто растут быстрее по объему хранения, чем по вычислительным требованиям.

3. «Мейнстримные» рабочие нагрузки: веб-серверы, аварийное восстановление и защита данных. Это зрелые и широко используемые приложения, для которых требуется простое в управлении и недорогое хранилище. vSAN упрощает работу с этим хранилищем для разных рабочих нагрузок за счет управления на основе политик и снижает затраты, используя серверы промышленного стандарта для достижения необходимой производительности. Он также упрощает аварийное восстановление, позволяя реплицировать данные между сайтами без дорогостоящего специального оборудования.

4. Рабочие нагрузки на периферии (edge workloads): гиперконвергентные решения для хранилищ обеспечивают масштабируемость, гибкость и повышенную производительность на периферии с меньшими затратами, в компактном формате и, что особенно важно, в упрощенном форм-факторе серверов. Ключевые возможности vSAN включают:

• возможность экономного масштабирования
• поддержку нативного файлового и блочного хранения для уменьшения физического объема
• высокую производительность благодаря поддержке NVMe-based TLC NAND flash для приложений с высокой чувствительностью к задержкам
• централизованное управление всеми удаленными сайтами из одного инструмента

5. Облачные (cloud-native) рабочие нагрузки: гиперконвергентные решения для хранилищ также являются идеальным подходом, поскольку они поддерживают облачные хранилища и автоматизируют выделение хранилища для контейнерных рабочих нагрузок, что позволяет разработчикам получать доступ к необходимому хранилищу по мере необходимости, одновременно позволяя ИТ-администраторам управлять хранилищем как для контейнеров, так и для виртуальных машин на одной платформе.

Заключение

VMware vSAN — это не просто решение для хранения, это краеугольный камень ИТ-модернизации. Благодаря использованию виртуализации vSAN позволяет организациям создать гибкую, масштабируемую и эффективную инфраструктуру хранения, способную справиться с текущими и будущими нагрузками. Независимо от того, хотите ли вы оптимизировать рабочие столы VDI, улучшить производительность баз данных или модернизировать стратегию аварийного восстановления, VMware vSAN предоставляет комплексное решение для удовлетворения потребностей пользователей.

Интересную статью написал Tom Fojta в своем блоге, касающуюся возможного повреждения данных на платформе VMware vSAN 8.0 (включая пакеты обновлений Update 1 и 2). Согласно статье базы знаний KB 367589, такое повреждение может случиться, если в вашей виртуальной машине некоторые приложения используют набор инструкций AVX-512.

Пока известно, что эти инструкции используются СУБД IBM Db2 и SAP HANA (однако и другие приложения могут их потенциально использовать).

Чтобы проверить, есть ли поддержка AVX-512 у вашего процессора, нужно выполнить следующую команду:

cat /proc/cpuinfo |grep avx512

Вывод команды будет примерно таким:

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xsaves arat pku md_clear flush_l1d arch_capabilities

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

Для того, чтобы обнаружить эту поддержку в гостевой ОС Windows, можно запустить утилиту HWiNFO.

Чтобы воспроизвести проблему, можно просто запустить SSH для передачи данных, так как библиотека openssl может использовать инструкции AVX-512:

$ dd if=/dev/zero bs=1M count=1024 | sha256sum -  > sha256sums.zero # one time checksum generation
$ ( while true; rm -f /tmp/zero.$$.img ; do ssh root@localhost "dd if=/dev/zero iflag=fullblock bs=1M count=1024 status=progress" | dd iflag=fullblock bs=1M status=none of=/tmp/zero.$$.img && sha256sum - < /tmp/zero.$$.img | diff -u sha256sums.zero - || exit 1; done )

В итоге проверка контрльной суммы завершится неудачно:

...
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.11915 s, 507 MB/s
1013972992 bytes (1.0 GB, 967 MiB) copied, 2 s, 507 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.09118 s, 513 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2 s, 532 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.01729 s, 532 MB/s
--- sha256sums.zero     2024-10-21 10:44:48.142238490 +0000
+++ -   2024-10-21 10:54:17.289072688 +0000
@@ -1 +1 @@
-49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  -
+4e841c1d34a2a051fab082d10a8105cd34e10c95ee74ce20d280a7c022eaaa53  -

Чтобы решить проблему на уровне процессора (виртуальной машины), нужно отмаскировать некоторые флаги в наборе инструкций CPU. Вы также можете решить проблему и на уровне приложений (для этого обратитесь к KB, указанной выше).

Итак, нужно добавить в Advanced Configuration Parameters виртуальной машины следующие строчки для проблемных инструкций AVX-512:

featMask.vm.cpuid.AVX512F = “Max:0”
featMask.vm.cpuid.AVX512FP16 = “Max:0“

Сделать это можно и через интерфейс vSphere Client или Cloud Director - там нужно создать политику Compute Policy для виртуальных машин (в интерфейсе она называется VM Sizing Policy) с расширенными параметрами:

Недавно компания Veeam представила второй релиз бесплатного решения Veeam Hardened Repository ISO. Первая версия была выпущена еще в июне 2023 года, сейчас вышло ее обновление. Veeam Hardened ISO Repository (VHR) предназначен для облегчения создания защищённого Linux-репозитория для решения Veeam Backup and Replication, так как не каждый администратор имеет достаточный опыт работы с Linux для эффективной защиты операционной системы. Veeam предлагает инструмент, который позволяет сделать это быстро и легко. Скачивание доступно бесплатно, но поскольку это технологическое превью, этот инструмент пока не следует использовать в производственных средах. ISO позволит вам создать безопасный репозиторий с функцией неизменяемости данных (immutability).

Преимущества ISO

• Главное преимущество ISO заключается в том, что вам не нужно выполнять дополнительные настройки или запускать скрипты (система уже защищена благодаря специальному установщику).
• В системе нет пользователя root.
• Благодаря использованию Rocky Linux в качестве основы, вы получаете 10 лет поддержки для ОС.
• После выхода официальной версии вы также получите поддержку от Veeam.
  

Требования

• Оборудование, поддерживаемое RedHat (для развертывания в производственной рекомендуется физический сервер, для лабораторных условий возможна виртуальная машина), сам ISO основан на Rocky Linux.
• Те же требования к CPU и RAM, что и для Linux-репозиториев.
• 2 диска с объёмом не менее 100 ГБ каждый.
• Поддерживается только внутреннее хранилище или напрямую подключаемое хранилище с аппаратным RAID-контроллером и кэшем записи.
• UEFI должен быть активирован.
• Минимальная версия Veeam - V12.2.

Veeam Hardened ISO — это загрузочный ISO-образ, разработанный для упрощения настройки Veeam Hardened Repositories. Этот новый метод доставки устраняет необходимость в глубоком знании Linux, делая его доступным для более широкой аудитории. Развертывая защищённые репозитории через этот ISO, пользователи могут значительно снизить затраты на постоянное управление и повысить безопасность своей инфраструктуры резервного копирования.

Одной из ключевых особенностей Veeam Hardened ISO является возможность создания безопасного и неизменяемого репозитория для резервного копирования. Это означает, что после записи данных в репозиторий их нельзя изменить или удалить, что защищает их от атак программ-вымогателей и других вредоносных действий. Такой уровень безопасности крайне важен в современном мире, где утечки данных и кибератаки становятся всё более частыми.

Вам предоставляется преднастроенная операционная система с автоматически применённым профилем безопасности DISA STIG. Также доступен инструмент настройки защищённого репозитория (Hardened Repository Configurator Tool), который упрощает настройку сети и позволяет изменить такие параметры, как настройки HTTP-прокси, имя хоста, пароль для пользователя vhradmin, временное включение SSH, обновление ОС и компонентов Veeam, сброс защиты от смещения времени, а также выполнять простые действия, такие как вход в систему, перезагрузка или выключение.

Ключевые особенности Veeam Hardened ISO

• Упрощённое развертывание — Veeam Hardened ISO значительно упрощает процесс развертывания, позволяя пользователям настраивать защищённые репозитории без необходимости глубокого знания Linux. Эта простота в использовании гарантирует, что даже пользователи с ограниченными техническими навыками могут воспользоваться передовыми возможностями защиты данных от Veeam.
• Повышенная безопасность — неизменяемость Veeam Hardened Repository гарантирует, что данные резервного копирования остаются защищёнными и не могут быть изменены. Это особенно важно в условиях атак программ-вымогателей, где целостность данных резервного копирования играет ключевую роль.
• Экономическая эффективность — благодаря снижению потребности в постоянном управлении и обслуживании, Veeam Hardened ISO помогает организациям экономить на операционных расходах. Такая эффективность делает решение привлекательным для компаний любого размера.
• Обратная связь сообщества — поскольку Veeam Hardened ISO на данный момент находится в статусе Community Preview, пользователи могут предоставлять обратную связь и вносить свой вклад в его развитие. Такой совместный подход помогает создать продукт, который будет соответствовать потребностям и ожиданиям сообщества Veeam.

Скачать Veeam Hardened Repository ISO можно по этой ссылке. Дефолтный пароль - VHRISO.

Дункан Эппинг написал интересный пост.

Начиная с обновления VMware vSphere 8.0 Update 2, поддержка опции "None - Stretched Cluster" в политике хранения (Storage Policy) для конфигурации vSAN Stretched Cluster была удалена. Причина этого заключается в том, что данная опция часто приводила к ситуациям, когда клиенты ошибочно ее использовали, и при сбое обнаруживали, что некоторые виртуальные машины перестали работать.

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

Поэтому данную опцию было решено убрать.

На конференции VMware Explore 2024, вместе с презентацией новой версии платформы VMware Cloud Foundation 9, Broadcom также объявила о планах разработки следующего поколения VMware vSphere Virtual Volumes (vVols). Следующее поколение vVols будет преследовать три основные цели: обеспечить согласованный и оптимизированный пользовательский опыт на разных платформах хранения, адаптировать vVols для современных масштабируемых задач, таких как рабочие нагрузки AI/ML и развёртывания облачных провайдеров, а также полностью интегрироваться с VMware Cloud Foundation (VCF).

vVols использует управление на основе политик хранилищ (Storage Policy-Based Management, SPBM) для оптимизации операций и минимизации потребности в специализированных навыках для работы с инфраструктурой хранения. vVols устраняет необходимость в ручном предоставлении хранилища, заменяя это описательными политиками на уровне ВМ или VMDK, которые могут быть применены или обновлены через простой рабочий процесс.

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

Планируемые преимущества следующего поколения vVols для клиентов включают:

• Полная интеграция с VMware Cloud Foundation: установка, развертывание и управление хранилищем с VCF, пригодность для использования в качестве основного и дополнительного хранилища для всех доменов рабочих нагрузок.
• Прописанная модель VASA для обеспечения согласованного и оптимизированного пользовательского опыта на всех платформах хранения.
• Поддержка масштабируемых сценариев использования для облаков.
• Обеспечение высокой доступности и развертывания с растянутыми кластерами.
• Бесшовная миграция с платформы vVols без простоев.
• Масштабируемые, неизменяемые снимки (immutable snapshots) как для традиционных, так и для современных приложений.

Для получения дополнительной информации о планируемых нововведениях vSAN и vVols рекомендуем посмотреть записи вот этих сессий VMware Explore 2024:

• VMware’s Vision for Storage and Data Protection in VMware Cloud Foundation [VCFB2086LV]
• What’s New with vSAN and Storage Operations in VMware Cloud Foundation [VCFB2085LV]
• vVols and Stretched Clusters with Pure Storage and VMware [VCFB2397LVS]
• Workload Provisioning And Protection Made Easy With VMware And NetApp [VCFB2433LVS]

Вчера мы писали о новых возможностях последнего пакета обновлений 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 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. Подробнее об этом рассказано тут.

Продолжаем рассказывать о производительности решения 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 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 вы можете найти по следующим ссылкам:

• Какие функции Datastore Sharing/HCI Mesh/vSAN Max поддерживаются для растянутых кластеров?
• Гибкие сетевые топологии растянутых кластеров в решении VMware vSAN Max
• Анонсы VMware Explore 2023: vSAN 8 Update 2 и vSAN Max
• Сайзинг пропускной способности соединения между площадками для растянутого кластера vSAN Stretched Cluster
• ReadyNode Profiles Certified for vSAN Max
• Introducing vSAN Max
• vSAN Frequently Asked Questions (FAQ)
• vSAN Max Configuration

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 Cloud Foundation Resource Center
• vSAN ReadyNode Sizer
• Why vSAN and vVols are Best for VMware Cloud Foundation

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 делает все расчеты необходимой емкости за вас. На рисунке ниже показано, что когда введены спецификации серверов и коэффициенты сжатия, чтобы они соответствовали этому кластеру, оценки емкости оказываются очень похожими.

Почти два года назад мы писали о решении 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 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 нужно использовать для каждой из выбранных конфигураций, и как это сказывается на дополнительных затратах дисковой емкости:

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

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