Некоторые пользователи, применяющие архитектуру VMware HCI Mesh для подключения емкостей удаленных кластеров в архитектуру VMware vSAN Express Storage Architecture (ESA) спрашивают - а можно ли таким образом подключить и емкости кластеров OSA (Original Storage Architecture)?
Напомним, что технология HCI Mesh появилась в VMware vSphere 7 Update 1, она позволяет смонтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов).
Мы уже касались этого вопроса здесь и указали на то, что это на данный момент не поддерживается. Дункан Эппинг вот тут рассказал о том, что это не только не сейчас поддерживается, но и невозможно.
Делов в том, что vSAN HCI Mesh (она же технология Datastore Sharing) использует проприетарный протокол vSAN, который называется Reliable Datagram Transport (RDT). При использовании vSAN OSA применяется другая версия протокола RDT, чем та, что используется в vSAN ESA, и в данный момент эти протоколы несовместимы. В итоге, нельзя использовать vSAN Datastore Sharing для предоставления емкости кластеров OSA в ESA или наоборот.
В будущем планируется исправить эту ситуацию, но в данный момент обходного пути нет.
Продолжаем рассказывать о производительности решения vSAN Express Storage Architecture (ESA), где реализовано высокопроизводительное кодирование RAID 5/6 с исправлением ошибок. Клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, которые также эффективны с точки зрения использования пространства, при этом соблюдается высокий уровень производительности. Все это достигается с использованием технологии RAID-6 на базе новой журналируемой файловой системы и формата объектов.
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", они показаны ниже:
Детали тестов разных политик хранения 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:
Для имитации модели нагрузки с многосхемной работой использовались несколько схем SLOB, и количество потоков на схему было установлено в 20.
Размер рабочего блока был установлен в 1024 для максимизации объема ввода-вывода без перегрузки REDO для изучения различий в показателях производительности между 3 различными политиками хранения на vSAN ESA.
В VMware провели несколько прогонов SLOB для вышеупомянутого кейса и сравнили метрики Oracle, как показано в таблице ниже.
Напомним, что базовая политика Oracle "Oracle ESA – FTT0 – NoRAID" была создана ИСКЛЮЧИТЕЛЬНО для получения базовых метрик для сравнения, так как настоящая производственная нагрузка никогда не настраивается с FTT=0 и без RAID.
Мы видим, что метрики базы данных с новым высокопроизводительным кодированием RAID 5/6 архитектуры vSAN Express Storage Architecture (ESA) сопоставимы с базовыми показателями при использовании без RAID.
Как было сказано ранее, клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, а также эффективность с точки зрения использования пространства.
Углубляясь в профили нагрузки основных баз данных, мы видим схожие метрики баз данных для исполнений запросов (SQL), транзакций, чтения/записи в IOPS и чтения/записи в МБ/сек как для прогонов политик хранения "Oracle ESA – FTT1 – R5", так и для "Oracle ESA – FTT2 – R6", а именно:
Выполнение запросов (SQL) в секунду и транзакции в секунду сопоставимы для всех трех прогонов
Запросы на чтение IO в секунду и запросы на запись IO в секунду сопоставимы для всех трех прогонов
Чтение IO (МБ) в секунду и запись IO (МБ) в секунду сопоставимы для всех трех прогонов
Углубляясь в изучение основных событий ожидания (wait events) базы данных, мы видим схожие события ожидания базы данных с похожими временами ожидания (wait times) для прогонов политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6".
Рассматривая статистику GOS, мы также можем видеть сопоставимые показатели производительности для запусков политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6":
В итоге нам удалось получить сопоставимые показатели производительности как с общей точки зрения базы данных, так и с точки зрения GOS для прогонов политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6".
Таги: VMware, vSAN, Oracle, Performance, ESXi, Storage, VMDK, ESA
С выходом обновленной версии VMware vSAN 8 в этом решении появилась новая архитектура гиперконвергентной инфраструктуры Express Storage Architecture (ESA). Она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.
Дункан Эппинг в ответ на запрос пользователей решения vSAN ESA сделал интересный пост на тему минимально необходимого числа хостов, которое требуется для поддержания определенного уровня избыточности - RAID-0/1/5/6.
В VMware vSAN 8 Update 1 появился адаптивный алгоритм записи, который существенно уменьшает избыточность записи на RAID-конфигурации. Когда мы рассматриваем, куда записываются данные по умолчанию используя путь записи ESA для объекта, использующего erasure codes для RAID-6, это уменьшает избыточность записи данных с 4,5x (3x для тройного зеркала + 1,5x для полосы RAID-6 4+2 с двойной паритетной проверкой) до всего лишь 1,5x. Это не только сокращает объем вычислений в процессорах, но и уменьшает сетевой трафик. Этот новый адаптивный путь записи приводит к большему объему передачи данных для всех рабочих нагрузок, которые склонны генерировать большие размеры I/O или большое количество ожидающих операций, создавая ситуации, обычно называемые большим количеством необработанных операций ввода-вывода (high outstanding I/O).
Теперь для vSAN ESA на базе RAID-5, в зависимости от размера кластера, могут быть использованы конфигурации 2+1 или 4+1, а конфигурация 3+1 больше не поддерживается. При этом для RAID-1 и RAID-6 в конфигурациях ничего не изменилось.
Ну и, собственно, ниже приведена таблица, которая позволит вам понять, какое минимальное число хостов ESXi нужно использовать для каждой из выбранных конфигураций, и как это сказывается на дополнительных затратах дисковой емкости:
Таги: VMware, vSAN, ESA, Storage, Hardware, Performance, ESXi
Напомним, что в конце прошлого года в решении vSAN 8 появилась новая архитектура гиперконвергентной инфраструктуры Express Storage Architecture (ESA). Она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.
С помощью флэш-памяти TLC на основе технологии NVMe, архитектура ESA имеет множество преимуществ со стандартной vSAN Original Storage Architecture (OSA), которая также продолжит поддерживаться для стандартного на текущий момент оборудования (устройства SATA/SAS).
Посмотрим на некоторые полезные скриншоты из видео. Улучшения производительности на уровне отдельного VMDK (RAID-6 ESA работает лучше, чем RAID-1 OSA):
Результаты теста SPEC - время отклика при увеличении числа операций в секунду:
Зависимость задержек (latency) от числа снапшотов на хранилище:
Сегодня мы расскажем о том, как определить пропускную способность сети между площадками при использовании кластеров vSAN HCI и кластеров vSAN Max в конфигурации Stretched Cluster.
В растянутом кластере два домена отказоустойчивости данных содержат один или несколько хостов, а третий домен отказоустойчивости содержит виртуальный модуль Witness для определения доступности сайтов данных. Далее каждый домен отказоустойчивости данных мы будем называть сайтом. Конфигурации растянутого кластера vSAN могут распространяться на разные расстояния, при условии что соблюдаются требования по пропускной способности (bandwidth) и задержке (latency).
Минимально поддерживаемая пропускная способность и latency между сайтами
Пропускная способность, которая требуется между сайтами, в большой степени зависит от объема операций ввода-вывода (I/O), который генерируют рабочие нагрузки, но будут влиять и другие факторы, такие как используемая архитектура (vSAN ESA или OSA), размер кластера и сценарии обработки сбоев. Ниже указаны минимально поддерживаемые значения, но рассчитанные оценки для конкретной инфраструктуры могут привести к требованиям по пропускной способности, превышающим указанные минимумы.
Приведенные ниже формулы помогут оценить необходимую пропускную способность сети между сайтами. Предполагается, что два сайта данных географически расположены достаточно близко друг к другу, чтобы соответствовать требованиям по задержке.
Понимание активности I/O, соотношения чтения и записи и размеров I/O
Рабочие нагрузки состоят из нескольких характеристик. Не только количество активности I/O значительно различается от нагрузки к нагрузке, но чтения и записи часто происходят с разными скоростями и разными размерами I/O. С целью предоставления простой формулы для расчета мы будем использовать следующие переменные для расчета оценочной пропускной способности связи между сайтами для растянутого кластера (ISL):
Скорость I/O всех команд чтения и записи, измеряемая в IOPS
Соотношение чтения/записи (например, 70/30)
Средний размер I/O, измеряемый в KB
Пропускная способность - это измерение на основе скорости, что означает, как много данных передается за определенный период времени. В отличие от измерения неактивных данных, где оно принимает форму байтов, килобайтов и т. д., измерение данных в процессе передачи по сети выражается в битах (b), килобитах (Kb), мегабитах (Mb) или гигабитах (Gb), и период времени - "в секунду" (ps). Обсуждая скорости, мы должны помнить о конвертации байтов в биты.
Давайте используем простой пример, где общий профиль I/O требует 100 000 I/O в секунду (IOPS), в среднем 8 KB каждый, где 70% IOPS - это чтение, и 30% - запись, в растянутой конфигурации. В этом сценарии запись I/O (30 000 IOPS в среднем 8 KB каждый) будет равна 240 000 Kbps или 240 Mbps. Это будет оценкой пропускной способности ISL, необходимой для этого профиля.
Простейший, но потенциально менее точный способ оценки требований к пропускной способности - это просто использовать входные данные, представляющие общие потребности кластера. Если кто-то использует формулу для расчета отдельных рабочих нагрузок в кластере, сумма этих расчетов предоставит результирующие требования к пропускной способности. Возможно, вы захотите выделить гораздо больше минимального рассчитанного количества, так как рабочие нагрузки со временем неизбежно становятся более ресурсоемкими.
Формулы для расчета оценок пропускной способности указаны ниже, они привязаны к используемой архитектуре: vSAN OSA или vSAN ESA. С введением архитектуры vSAN Express Storage (ESA) появляются все новые возможности по обеспечению производительности хранилища на совершенно новом уровне. Поэтому при использовании ESA рекомендуется тщательно отслеживать использование ISL, чтобы убедиться, что есть достаточная пропускная способность, необходимая для того, чтобы рабочие нагрузки не были ограничены со стороны ISL. Для дополнительной информации см. статью: "Использование vSAN ESA в топологии растянутого кластера".
Формулы расчета пропускной способности для vSAN ESA
Трафик репликации от I/O гостевой ВМ - это доминирующий тип трафика, который мы должны учесть при оценке необходимой пропускной способности для трафика межсайтовой связи (ISL). У растянутых кластеров vSAN ESA трафик чтения по умолчанию обслуживается сайтом, на котором находится ВМ. Требуемая пропускная способность между двумя сайтами данных (B) равна пропускной способности записи (Wb) * множитель данных (md) * множитель ресинхронизации (mr) * коэффициент сжатия (CR).
Расчет пропускной способности для ISL, обслуживающего растянутый кластер vSAN с использованием ESA, отличается от формулы, используемой для OSA. vSAN ESA сжимает данные до их репликации между сайтами. В результате ESA уменьшает использование пропускной способности ISL, эффективно увеличивая его возможности для передачи большего количества данных.
Чтобы учесть это в расчете в топологии, использующей ESA, формула учитывает оценочное соотношение сжатия сохраненных данных. Давайте рассмотрим следующий пример, где мы оцениваем экономию в 2 раза благодаря использованию сжатия в vSAN ESA. Мы используем простое значение "2x" (также называемое 2:1 или 50%) для простоты. Фактические коэффициенты сжатия будут зависеть от данных, хранящихся в вашей среде. Пример 2:1 - это не предположение о том, что вы на самом деле можете увидеть в своей среде.
Преобразуйте это в процент от исходного размера, разделив конечный размер на начальный размер. Это даст, например, результат ".50".
Умножьте окончательное рассчитанное значение из описанной в этой статье формулы на ".50".
В результате формула будет выглядеть так:
B = Wb * md * CR * mr * CR
Как отмечалось выше, коэффициенты сжатия часто могут быть представлены разными способами, чтобы выразить экономию места.
Например:
Сжатие, выраженное в соотношении. [начальный размер]:[конечный размер]. Соотношение сжатия 2:1 указывает на то, что данные будут сжаты до половины своего исходного размера.
Сжатие, выраженное в виде множителя экономии. Соотношение сжатия 2x указывает на то, что данные будут сжаты до половины своего исходного размера. Это то, что отображается в представлении ёмкости кластера vSAN.
Сжатие, выраженное в процентах от исходного размера. Значение сжатия 50% (или, .50) указывает на то, что данные будут сжаты до половины своего исходного размера.
Примеры между сайтами (для vSAN ESA)
Рабочая нагрузка 1
С примером рабочей нагрузки в 10 000 записей в секунду на рабочую нагрузку vSAN со средним размером записи 8 KB потребуется 80 МБ/с или 640 Мбит/с пропускной способности. Предположим, что данные имеют коэффициент сжатия 2x.
B = 640 Мбит/с * 1.4 * 1.25 * .50 = 560 Мбит/с.
Учитывая требования к сети vSAN, требуемая пропускная способность составляет 560 Мбит/с.
Рабочая нагрузка 2
В другом примере, 30 000 записей в секунду, 8KB записи, потребуется 240 MB/s или 1 920 Мбит/с пропускной способности. Предположим, что данные имеют коэффициент сжатия 2x.
B = 1,920 Мбит/с * 1.4 * 1.25 * .50 = 1,680 Мбит/с или примерно 1,7 Гбит/с.
Требуемая пропускная способность составляет примерно 1,7 Гбит/с.
Рабочие нагрузки редко состоят только из чтений или записей, и обычно включают общее соотношение чтения к записи для каждого варианта использования. Используя общую ситуацию, когда общий профиль I/O требует 100 000 IOPS, из которых 70% являются записью, а 30% чтением, в растянутой конфигурации, IO записи - это то, на что рассчитана пропускная способность межсайтовой связи. С растянутыми кластерами vSAN, трафик чтения по умолчанию обслуживается сайтом, на котором находится ВМ.
Формулы расчета пропускной способности для vSAN OSA
Как и в растянутых кластерах с использованием ESA, трафик репликации от I/O гостевой ВМ в растянутом кластере с использованием OSA является доминирующим типом трафика, который мы должны учитывать при оценке необходимой пропускной способности для трафика межсайтовой связи (ISL). В растянутых кластерах vSAN OSA трафик чтения по умолчанию обслуживается сайтом, на котором размещена ВМ. Требуемая пропускная способность между двумя данными сайтами (B) равна пропускной способности записи (Wb) * множитель данных (md) * множитель ресинхронизации (mr), или:
B = Wb * md * mr
Множитель данных состоит из накладных расходов на трафик метаданных vSAN и различных связанных операций. VMware рекомендует использовать множитель данных 1.4. Множитель ресинхронизации включен для учета событий ресинхронизации. Рекомендуется выделять пропускную способность по верхней границе требуемой пропускной способности для событий ресинхронизации. Для учета трафика ресинхронизации рекомендуются дополнительные 25%.
Планируйте использование vSAN ESA для всех новых кластеров vSAN. Эта архитектура быстрее и эффективнее, чем vSAN OSA, и, зачастую, уменьшает количество хостов, необходимых для того же объема рабочих нагрузок. Формула для vSAN OSA остается актуальной для тех, у кого уже есть установки vSAN OSA.
Требования к пропускной способности между Witness и сайтом данных
В топологии растянутого кластера хост-машина Witness просто хранит компоненты, состоящие из небольшого объема метаданных, которые помогают определить доступность объектов, хранящихся на сайтах с данными. В результате сетевой трафик, отправляемый на сайт для этой машины, довольно мал по сравнению с трафиком между двумя сайтами с данными через ISL.
Одной из наиболее важных переменных является объем данных, хранящихся на каждом сайте. vSAN хранит данные в виде объектов и компонентов. Она определяет, сколько компонентов нужно для данного объекта, и где они должны быть размещены по всему кластеру, чтобы поддерживать устойчивость данных в соответствии с назначенной политикой хранения.
Архитектура vSAN ESA обычно использует больше компонентов, чем OSA. Это следует учитывать при расчете потенциально необходимой пропускной способности для машины Witness.
Обязательно выберите правильный размер хоста vSAN Witness. При развертывании предлагается четыре размера машины (Tiny, Medium, Large и Extra Large), каждый из которых предназначен для размещения разных размеров сред. Посмотрите статью "Deploying a vSAN Witness Appliance" для получения дополнительной информации.
Формулы расчета пропускной способности Witness для vSAN ESA и OSA
Сетевое взаимодействие сайтов с Witnessn состоит исключительно из метаданных, что делает запросы к сетевым ресурсам Witness гораздо более легковесными, что отражается в поддерживаемых минимальных требованиях к пропускной способности и задержке.
Поскольку формула для оценки необходимой пропускной способности Witness основана на количестве компонентов, ее можно использовать для расчета растянутых кластеров, использующих OSA или ESA. Поскольку ESA обычно использует больше компонентов на объект (возможно, в 2-3 раза больше) по сравнению с OSA, следует учитывать большее количество компонентов на ВМ при использовании архитектуры на базе ESA.
Базовая формула
Требуемая пропускная способность между Witness и каждым сайтом равна ~1138 Б x Количество компонентов / 5с
1138 Б x Кол-во компонентов / 5 секунд
Значение 1138 Б происходит от операций, которые выполняются, когда предпочтительный сайт выходит из строя, и второстепенный сайт берет на себя владение всеми компонентами. Когда основной сайт выходит из строя, второстепенный сайт становится лидером. Witness отправляет обновления новому лидеру, после чего новый лидер отвечает Witness, по мере обновления владения. Требование в 1138 Б для каждого компонента происходит из сочетания полезной нагрузки от Witness к резервному агенту, за которым следуют метаданные, указывающие, что предпочтительный сайт не работает. В случае отказа предпочтительного сайта, связь должна быть достаточно хорошей, чтобы позволить изменение владения кластером, а также владение всеми компонентами в течение 5 секунд.
Примеры пропускной способности Witness к сайту (OSA)
Нагрузка 1
Если ВМ состоит из:
3 объектов
Параметр допустимого числа отказов (FTT=1)
Приблизительно 166 ВМ с этой конфигурацией потребовало бы, чтобы Witness содержал 996 компонентов (166 ВМ * 3 компонента/ВМ * 2 (FTT+1) * 1 (Ширина полосы)). Чтобы успешно удовлетворить требования пропускной способности Witness для общего числа 1 000 компонентов на vSAN, можно использовать следующий расчет:
Преобразование байтов (Б) в биты (б), умножьте на 8:
В = 1138 Б * 8 * 1 000 / 5с = 1 820 800 бит в секунду = 1.82 Мбит/с
VMware рекомендует добавить безопасный запас в 10% и округлить вверх.
B + 10% = 1.82 Мбит/с + 182 Кбит/с = 2.00 Мбит/с
Таким образом, с учетом безопасного запаса в 10%, можно утверждать, что для каждых 1 000 компонентов подходит канал 2 Мбит/с.
Нагрузка 2
Если ВМ состоит из:
3 объектов
FTT=1
Stripe с параметром 2
Приблизительно 1 500 ВМ с этой конфигурацией потребовало бы хранения 18 000 компонентов на Witness. Чтобы успешно удовлетворить требования пропускной способности Witness для 18 000 компонентов на vSAN расчет будет таким:
B = 1138 Б * 8 * 18 000 / 5с = 32 774 400 бит в секунду = 32.78 Мбит/с
B + 10% = 32.78 Мбит/с + 3.28 Мбит/с = 36.05 Мбит/с
Используя общее уравнение 2 Мбит/с на каждые 1 000 компонентов, (NumComp/1000) X 2 Мбит/с, можно увидеть, что 18 000 компонентов действительно требует 36 Мбит/с.
Пропускная способность Witness для конфигураций с 2 узлами (OSA)
Пример удаленного сайта 1
Рассмотрим пример 25 ВМ в конфигурации с 2 узлами, каждая с виртуальным диском 1 ТБ, защищенные при FTT=1 и Stripe Width=1. Каждый vmdk будет состоять из 8 компонентов (vmdk и реплика) и 2 компонентов для пространства имен ВМ и swap-файла. Общее количество компонентов составляет 300 (12/ВМx25ВМ). С 300 компонентами, используя правило (300/1000 x 2 Мбит/с), требуется пропускная способность 600 кбит/с.
Пример удаленного сайта 2
Рассмотрим другой пример 100 ВМ на каждом хосте, с таким же ВМ выше, с виртуальным диском 1 ТБ, FTT=1 и SW=1. Общее количество компонентов составляет 2 400. Используя правило (2 400/1000 x 2 Мбит/с), требуется пропускная способность 4.8 Мбит/с.
Вот так и рассчитывается пропускная способность для разных рабочих нагрузок и конфигураций в среде vSAN. Понимание этих метрик и формул поможет в проектировании и развертывании решений vSAN, которые обеспечивают оптимальную производительность и надежность.
Microsoft SQL Server долгое время считается золотым стандартом для критически важных рабочих нагрузок баз данных среднего класса. Однако полноценное использование возможностей SQL Server требует соответствующей инфраструктуры.
Партнерство между Lenovo для линейки ThinkAgile VX Series и VMware в рамках технологии vSAN Express Storage Architecture (ESA) позволяет создать передовую гиперконвергентную инфраструктуру (HCI), работающую на новейших аппаратных платформах. Это решение разработано для удовлетворения сложных потребностей современных организаций, ориентированных на данные.
В VMware vSAN 8 и vSAN ESA произошли значительные изменения, которые включают в себя использование высокопроизводительных NVMe-дисков и новый, быстрый и эффективный путь передачи данных. vSAN ESA обеспечивает эффективность RAID 5/6 с производительностью RAID 1.
Тестирование показало, что 8-узловой кластер vSAN ESA на Lenovo Agile VX Series может обеспечить 720 000 агрегированных IOPS по мере увеличения количества виртуальных машин SQL Server с одной до восьми. Результаты подтверждают последовательную масштабируемость и надежную производительность для рабочих нагрузок.
В документе приведены обширные рекомендации по проектированию и сайзингу, отчеты о проверке решений и лучшие практики для администраторов и владельцев систем на основе Microsoft SQL Server.
Таги: VMware, vSAN, ESA, Storage, Microsoft, SQL, Performance
С появлением архитектуры vSAN Express Storage Architecture (ESA) в vSAN 8, которая была представлена в августе 2022 года, VMware хотела предоставить простой способ для клиентов развертывать кластеры с соответствующими характеристиками оборудования и сети. Программа vSAN ReadyNode для ESA гарантировала, что клиенты могут приобретать серверы, предварительно настроенные для выполнения конкретных минимальных требований к оборудованию для ESA, предоставляя при этом достаточную гибкость для удовлетворения требований к емкости и производительности среды пользователей.
VMware не только внесла значительные улучшения в ESA в vSAN 8 U1 и vSAN 8 U2, но и улучшила совместимость с оборудованием, предоставляя клиентам и партнерам простой и гибкий путь для создания поддерживаемой конфигурации. Давайте посмотрим, что поддерживается на данный момент.
Гибкость программы ReadyNode
Благодаря расширенной совместимости с устройствами хранения данных с интенсивным чтением и введению новых готовых узлов vSAN-ESA-AF-0 для небольших датацентров и периферийных сред, тип оборудования, совместимый с ESA, становится более гибким. vSAN ReadyNodes могут быть приобретены с использованием простого, единого SKU, но конфигурации, соответствующие vSAN ESA, также могут быть получены путем "эмуляции" конфигурации ReadyNode с использованием отдельных компонентов оборудования от сертифицированных поставщиков ReadyNode.
Это означает, что клиенты могут выбрать платформу сертифицированную по программе ESA ReadyNode от производителя серверов, указанную в VMware Compatibility Guide (VCG) for vSAN ESA, и далее могут создавать конфигурацию сервера с использованием отдельных аппаратных компонентов, как они указаны в данной спецификации ReadyNode, эмулируя реальный узел ReadyNode, приобретенный с использованием единого SKU. Этот подход может помочь клиентам, которые решили не покупать ReadyNode через официальный SKU, но имеют такое же оборудование (или лучше), найденное в желаемой классификации ReadyNode.
Термин «Emulated ReadyNode» просто относится к тому, из каких компонентов был собран готовый узел ReadyNode. Он воспринимается и поддерживается VMware и поставщиками ReadyNode точно так же, как узлы ReadyNodes, приобретенные с использованием единого SKU.
Поддержка таких эмулированных систем ReadyNode предоставляет большую гибкость при закупке оборудования и развертывании серверов, которые могут работать на vSAN ESA. Этот вариант применяется только к оборудованию и платформам, сертифицированным для ESA, а не к стандартному оборудованию серверов от производителей, не входящих в список ReadyNode. Тип подхода "собери сам" доступен только при использовании оригинальной архитектуры хранения vSAN (Original Storage Architecture, OSA).
Ну а в статье KB 90343 рассказано о том, что вы можете и не можете менять в конфигурации узлов для vSAN ESA ReadyNode:
На прошлой неделе мы рассказали о новых возможностях обновленной версии платформы VMware vSphere 8 Update 1, а также новых функциях инфраструктуры хранилищ (Core Storage). Сегодня мы поговорим о новой версии vSAN 8 Update 1 - решения для организации отказоустойчивых кластеров хранилищ для виртуальных машин.
В vSAN 8 компания VMware представила архитектуру хранилища vSAN Express Storage Architecture (ESA), сделав весомый вклад в развитие гиперконвергентной инфраструктуры. В первом пакете обновлений vSAN компания VMware продолжает развивать этот продукт, позволяя клиентам использовать современные массивы, которые обеспечивают новый уровень производительности, масштабируемости, надежности и простоты использования.
Обзор основных возможностей vSAN 8 Update 1 вы также можете увидеть в видео ниже (откроется в новом окне):
В vSAN 8 Update 1 продолжают разрабатывать и улучшать обе архитектуры - vSAN OSA и vSAN ESA. Давайте посмотрим, что нового появилось в vSAN U1:
1. Масштабирование распределенных хранилищ
Обработка разделенных ресурсов вычисления и хранения в кластерах улучшена в версии vSAN 8 U1. Клиенты могут масштабироваться новыми способами, совместно используя хранилища данных vSAN с другими кластерами vSAN или только с вычислительными кластерами vSphere в рамках подхода HCI Mesh.
Управление распределенными хранилищами HCI Mesh с помощью архитектуры Express Storage
В vSAN 8 U1 архитектура Express Storage Architecture (ESA) позволяет клиентам максимизировать использование ресурсов устройств нового поколения путем предоставления общего доступа к хранилищами в нескольких нерастянутых кластерах для подхода HCI Mesh. Пользователи могут монтировать удаленные хранилища данных vSAN, расположенные в других кластерах vSAN, и использовать кластер vSAN ESA в качестве внешнего хранилища ресурсов для кластера vSphere.
Использование внешнего хранилища с помощью растянутых кластеров vSAN для OSA
В vSAN 8 U1 появилась поддержка распределенных хранилищ HCI Mesh при использовании растянутых кластеров vSAN на основе архитектуры хранения vSAN OSA. Теперь пользователи могут масштабировать хранение и вычислительные мощности независимо - в стандартных и растянутых кластерах.
Потребление емкостей хранилищ vSAN для разных экземпляров vCenter Server
vSAN 8 U1 также поддерживает распределенные хранилища в разных средах с использованием нескольких серверов vCenter при использовании традиционной архитектуры хранения (OSA).
2. Улучшение платформы
Улучшенная производительность с использованием нового адаптивного пути записи
В новом релизе представлен новый адаптивный путь записи, который позволяет рабочим нагрузкам с множеством записей и частопоследовательными записями записывать данные оптимальным способом. Улучшенная потоковая запись на ESA обеспечит увеличение пропускной способности на 25% и снижение задержки для последовательных записей. Это обновление не только повлияет на приложения с преобладающим профилем последовательной записи I/O, но и расширит разнообразие нагрузок, которые работают оптимальным образом на ESA vSAN.
Улучшенная производительность для отдельных нагрузок
Чтобы извлечь максимальную пользу из современного оборудования NVMe, в vSAN ESA 8 U1 была оптимизирована обработка I/O для каждого объекта, находящегося на хранилище данных vSAN ESA, повысив производительность на каждый VMDK на 25%. Эти улучшения производительности для отдельных объектов на ESA будут очень эффективны на критически важных виртуальных машинах, включая приложения, такие как реляционные базы данных и нагрузки OLTP.
Улучшенная надежность во время сценариев режима обслуживания.
В vSAN 8 U1 для ESA была добавлена еще одна функция, которая присутствует в vSAN OSA: поддержка RAID 5 и RAID 6 erasure coding с функциями дополнительной защиты от потери данных во время плановых операций обслуживания. Эта новая возможность гарантирует, что данные на ESA хранятся с избыточностью в случае неожиданного сбоя хоста в кластере во время режима обслуживания.
Улучшения управления датасторами
В vSAN 8 U1 администраторы смогут настраивать размер объектов пространства имен, что позволит им более просто хранить файлы ISO и библиотеки контента.
3. Упрощение управления
При использовании управления хранилищем на основе политик (SPBM), клиенты могут определять возможности хранения с помощью политик и применять их на уровне виртуальных машин. vSAN 8 U1 есть несколько новых улучшений, которые упрощают ежедневные операции администраторов, а также добавляют несколько новых возможностей, чтобы помочь глобальной команде поддержки VMware (GS) быстрее решать проблемы клиентов.
Автоматическое управление политиками для Default Storage Policies
(ESA)
В vSAN ESA 8 U1 появилась новая, необязательная кластерная политика хранения по умолчанию, которая поможет администраторам работать с кластерами ESA с оптимальной надежностью и эффективностью. В конфигурации на уровне кластера доступен новый переключатель "Auto-Policy Management". При включении этой функции кластера будет создана и назначена эффективная политика хранения по умолчанию на основе размера и типа кластера.
Skyline Health Score и исправление конфигурации
В vSAN 8 U1 модуль Skyline UX был переработан и теперь содержит новую панель управления состоянием с упрощенным видом "здоровья" каждого кластера. Новый пользовательский интерфейс поможет ответить на вопросы: "Находится ли мой кластер и обрабатываемые им нагрузки в работоспособном и здоровом состоянии?" и "Насколько серьезно это состояние? Следует ли решить эту проблему?".
С таким четким пониманием потенциальных проблем и действий для их устранения вы можете сократить среднее время до устранения проблем (mean time to resolution, MTTR).
Более высокий уровень детализации для улучшенного анализа производительности
Доступный как в Express Storage Architecture, так и в Original Storage Architecture, сервис производительности vSAN 8 U1 теперь включает мониторинг производительности почти в реальном времени, который собирает и отображает показатели производительности каждые 30 секунд.
Упрощенный сбор диагностической информации о производительности
В vSAN 8 U1 в I/O Trip Analyzer для виртуальных машин появился новый механизм планировщика. Вы можете запускать диагностику программно, что позволяет собирать больше и лучших данных, что может быть критически важно для выявления временных проблем производительности. Это улучшение идеально подходит для сред, где ВМ имеет повторяющуюся (хоть и кратковременную) проблему с производительностью.
Новая интеграция PowerCLI
В vSAN 8 U1 PowerCLI поддерживает множество новых возможностей как для архитектур ESA (Express Storage Architecture), так и OSA (Original Storage Architecture). С помощью этих интеграций клиенты ESA получат простой доступ к своему инвентарю для мониторинга и автоматизации управления своей средой и выделением ресурсов.
4. Функции Cloud Native Storage
Выделенные окружения DevOps увеличивают сложность всего центра обработки данных и увеличивают затраты. Используя существующую среду vSphere для хостинга рабочих нагрузок Kubernetes DevOps, клиенты дополнительно увеличивают ценность и ROI платформы VMware. VMware продолжает фокусироваться на потребностях разработчиков: в vSAN 8 U1 были реализованы новые улучшения производительности, простоты и гибкости для разработчиков, которые используют среду, и для администраторов, ответственных за саму платформу.
Поддержка CNS для vSAN ESA
В vSAN 8 U1 мы добавили поддержку Cloud Native Storage (CNS) для vSAN ESA. Клиенты могут получить преимущества производительности vSAN ESA для своих сред DevOps.
Поддержка DPp общих виртуальных коммутаторов
vSAN 8 U1 снижает стоимость и сложность инфраструктуры за счет того, что решения DPp (Data Persistence) теперь совместимы с VMware vSphere Distributed Switch. Клиентам нужны только лицензии vSphere+/vSAN+, чтобы использовать платформу Data Persistence — на vSAN OSA или ESA — и запускать приложения, что дает более низкую общую стоимость владения и упрощение операций.
Развертывние Thick provisioning для vSAN Direct Configuration
Наконец, в vSAN 8 U1 были доработаны кластеры, работающие в конфигурации vSAN Direct Configuration — это уникальная кластерная конфигурация, настроенная под Cloud Native Workloads. С vSAN 8 U1 постоянные тома могут быть программно выделены разработчиком как "thick" (это определяется в классе хранения).
Более подробно о новых возможностях VMware vSAN 8 Update 1 можно почитать на специальной странице.
Таги: VMware, vSAN, Update, Storage, OSA, ESA, Performance
Как знают многие администраторы, у VMware есть список сертифицированных конфигураций оборудования, подходящих под использование продуктов линейки vSAN (а также различных профилей нагрузки, например, VDI), который называется Ready Node.
Также, как вы помните, с релизом новой версии решения для создания отказоустойчивых кластеров хранилищ vSAN 8 компания VMware выпустила и новую архитектуру Express Storage Architecture (ESA). Это архитектура гиперконвергентной инфраструктуры, которая позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.
За счет использования флэш-памяти TLC на основе технологии NVMe, архитектура ESA имеет множество преимуществ по сравнению со стандартной vSAN Original Storage Architecture (OSA), которая также продолжает поддерживаться для стандартного на текущий момент оборудования (устройства SATA/SAS).
С релизом ESA многие администраторы задались вопросом, на каких серверах можно развертывать сервисы этой архитектуры vSAN. С самого начала в списке Ready Node поддерживалось оборудование Dell, HPe и Lenovo, а недавно добавили и серверы Supermicro.
Основная модификация, которая, как правило, интересует пользователей - это "Storage Device" и "Number of Storage Devices", то есть возможность заменять тип накопителей и их количество. Но это не все - в зависимости от типов узлов вы можете менять CPU и память (только в сторону увеличения ресурсов), а также сетевые карты и их количество.
Полный список доступны изменений приведен в KB 90343, но их суть сводится к таблице, представленной ниже (кликните для увеличения):
В той же статье вы найдете и ответы на самые часто возникающие вопросы об узлах Ready Node для Express Storage Architecture.
Дункан Эппинг недавно рассказал о том, как работает сжатие и дедупликация в рамках этой архитектуры. Напомним, что главное отличие ESA от OSA (Original Storage Architecture) заключается в том, что она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения, таких как флэш-память TLC на основе технологии NVMe.
Ключевыми структурными особенностями vSAN 8 ESA является переработанная и запатентованная файловая система (log-structured file system, LFS), новый оптимизированный для записи менеджер объектов (log-structured object manager), а также новый формат дисковых объектов.
Итак, в архитектуре OSA сжатие и дедупликация срабатывают непосредственно до того, как данные сохраняются на диск на каждом из хостов, где они в итоге оказываются. В vSAN ESA сжатие данных (compression) включено по умолчанию и работает все время на самом верхнем уровне архитектуры (до низких уровней слоев vSAN), как показано на диаграмме ниже:
Суть изменения заключается в том, что данные сначала сжимаются, а только потом передаются по сети. Например, вы сжимаете блок 4К до 2К, и далее он отправляется в сеть. Это требует меньше канала, а также меньше ресурсов на шифрование - вам нужно посчитать контрольную сумму для 2К блока вместо 4К.
Сжатие данных происходит только на исходном хосте, а целевой хост отвечает только за их помещение на диски. Это уменьшает совокупное потребление ресурсов и более эффективно расходует пропускную способность сети.
При создании политики хранения на вкладке Storage rules вы можете выбрать один из четырех вариантов сжатия:
No Preference (по умолчанию)
No space efficiency
Compression only
Deduplication and compression
Надо отметить, что дедупликация данных еще не реализована для архитектуры ESA, поэтому вариант Deduplication and compression не актуален на данный момент.
Итак, как мы уже сказали компрессия включена по умолчанию, поэтому она будет работать при выбранных вариантах No Preference и
Compression only. Если вы выберете No space efficiency, то сжатие данных будет отключено.
Дункан создал 3 виртуальных машины и три политики хранения. Машина VM_CompDisabled получила политику "Comp_Disabled", где выбран вариант "No space efficiency".
Пока нет способа в интерфейсе увидеть, включено реально ли сжатие в рамках политики или нет, но вы можете воспользоваться следующей командой, указал UUID объекта из скриншота выше:
cmmds-tool find -t DOM_OBJECT -u <UUID>
Если в выводе команды вы найдете строку ("compressionState" i1), то это значит, что компрессия данных отключена:
Еще один момент - так как компрессия работает на верхнем уровне и не имеет связи с оборудованием и компонентами хостов ESXi, то при изменении политики хранения не происходит переработки уже записанных данных. Просто все новые данные, приходящие на источник, начинают (или прекращают) сжиматься и в этом виде попадают на хранилища.
Таги: VMware, vSAN, ESA, Storage, Compression, VMachines, Blogs
В конце лета этого года компания VMware провела конференцию Explore 2022, где представила новую версию решения для создания отказоустойчивых хранилищ VMware vSAN 8. Главным нововведением обновленной платформы стала архитектура Express Storage Architecture (ESA), которая позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения. Сегодня мы посмотрим, какие улучшения механизма работы снапшотов появились в vSAN, работающем в ESA-варианте.
Еще много лет назад мы писали о том, что снапшоты - это зло, и использовать их нужно с большой осторожностью и при большой необходимости. Например, перед обновлением виртуального аппаратного обеспечения, ОС или критичных приложений можно сделать снапшот, проверить что все в порядке после обновления, а затем удалить его.
Снапшоты, создаваемые для специфических целей администраторов, часто разрастаются в разных ветках, что в итоге приводит к падению производительности виртуальной машины и операционным сложностям при консолидации (например, недостаток места). При этом снапшоты - это вещь нужная для таких процессов, как резервное копирование и автоматизированные рабочие процессы Continuous Integration/Continuous Delivery (CI/CD), Copy Data Management (CDM), а также управление виртуальными ПК VMware Horizon.
Часто в большой инфраструктуре VMware vSphere можно обязательно найти вот такую машину, которая "почему-то тормозит":
Традиционно снапшоты в VMware vSphere строились на базе технологии redo-log (дельта диск отличий от основного VMDK), которая имеет ограничения по масштабируемости и производительности. Снапшоты типа VMFSsparse использовались по умолчанию в файловой системе VMFS5 для дисков менее 2 ТБ и для всех дисков на системах до VMFS5.
VMFSsparse работает поверх VMFS как redo-log, который создается пустым, как только для ВМ создается снапшот, и растет до размера родительского VMDK-диска, накапливая данные. Начиная с VMFS5, для дисков более 2 ТБ и для всех дисков VMFS6 был добавлен формат снапшота VMFS SEsparse. Это эволюционное изменение снапшотов, которое давало улучшения в плане склеивания снапшотов и в отношении их больших цепочек, где ранее происходила потеря производительности.
Также для SEsparse снапшотов было сделано множество улучшений в новых версиях vSphere, например, при чтении данных для машин со снапшотами была существенно увеличена производительность: чтение идет сразу из нужного VMDK, минуя всю цепочку снапшотов при каждом обращении, в отличие от того, как это было сделано раньше. Все это снижает latency на чтение:
Также были сделаны некоторые оптимизации "подмораживания" (stun) при различного рода операциях со снапшотами, а также специфические технологии, такие как Mirror driver, но концептуально суть снапшотов не поменялась. Поэтому VMware продолжала давать рекомендации не хранить их более 48 часов и не создавать длинных цепочек снапшотов, особенно для критичных нагрузок.
Архитектура снапшотов в vSAN базируется на традиционных redo-log снапшотах, которые были доработаны - так появился формат vsanSparse (начиная с vSAN 6). Он использует механизм redirect-on-write и снижает некоторые технические ограничения снапшотов за счет кэширования, но проблемы подмораживания и долгого времени удаления снапшотов остаются.
В новой версии vSAN 8 при использовании архитектуры ESA, снапшоты используются совершенно другим образом, нежели в прошлых версиях платформы. Вместо использования традиционной цепочки базового и дельта-дисков, механизм снапшотов использует lookup table, применяя структуры B-Tree.
Файловая система log structured file system в vSAN ESA позволяет новым операциям записи помещаться в новые сегменты хранилища с их указателями метаданных, интеллектуально размещая их в соответствии с принадлежностью к снапшотам. В этом случае время удаления снапшота снижается более чем в 100 раз по сравнению с прошлыми версиями платформы vSAN.
Также новая архитектура снапшотов снижает и накладные расходы на вычисления и перемещения данных, которые происходят при удалении снапшотов (а это были одни из самых нагружающих инфраструктуру операций). По-сути, когда в vSAN 8 удаляется снапшот, происходит лишь удаление метаданных, а физического перемещения блоков не происходит.
Мало того, пользователь получает подтверждение удаления снапшота сразу же, а удаление данных и метаданных происходит позже, в асинхронном режиме. Новая архитектура снапшотов ESA позволяет использовать практически неограниченное количество снапшотов - однако текущие параметры платформы vSphere ограничивают число снапшотов числом 32 на один объект.
Как знают администраторы VMware vSphere, решения для резервного копирования используют снапшоты через vSphere Storage API (также называемые VADP) для передачи резервных копий на хранилища. Новая функциональность vSAN ESA автоматически заменит старый механизм снапшотов, а пользователи увидят реальный прирост производительности при консолидации снапшотов, а также при работе продуктов VMware SRM и vSphere Replication в кластерах ESA.
Таги: VMware, vSAN, Update, Snapshots, Storage, ESA, Performance