В постах ранее мы подчеркивали ценность, которую 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.
DRAM:NVME
DRAM Size
NVMe Partition Size
NVMe Used
1:1
1 TB
4 TB
1 TB
1:2
1 TB
4 TB
2 TB
1:4
1 TB
4 TB
4 TB
Итак, при определении размера 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 — это будет рассмотрено в следующей части серии.
В первой части статей этой серии мы рассмотрели некоторые предварительные требования для NVMe Memory Tiering, такие как оценка рабочих нагрузок, процент активности памяти, ограничения профилей виртуальных машин, предварительные требования и совместимость устройств NVMe.
Кроме того, мы подчеркнули важность внедрения платформы VMware Cloud Foundation (VCF) 9, которая может обеспечить значительное сокращение затрат на память, лучшее использование CPU и более высокую консолидацию виртуальных машин. Но прежде чем полностью развернуть это решение, важно спроектировать его с учётом безопасности, отказоустойчивости и масштабируемости — именно об этом и пойдёт речь в этой статье.
Безопасность
Безопасность памяти не является особенно популярной темой среди администраторов, и это объясняется тем, что память является энергонезависимой. Однако злоумышленники могут использовать память для хранения вредоносной информации на энергонезависимых носителях, чтобы избежать обнаружения — но это уже скорее тема криминалистики. Как только питание отключается, данные в DRAM (энергозависимой памяти) исчезают в течение нескольких минут. Таким образом, с NVMe Memory Tiering мы переносим страницы из энергозависимой памяти (DRAM) на энергонезависимую (NVMe).
Чтобы устранить любые проблемы безопасности, связанные с хранением страниц памяти на устройствах NVMe, VMware разработала несколько решений, которые клиенты могут легко реализовать после первоначальной настройки.
В этом первом выпуске функции Memory Tiering шифрование уже входит в комплект и готово к использованию «из коробки». Фактически, у вас есть возможность включить шифрование на уровне виртуальной машины (для каждой ВМ) или на уровне хоста (для всех ВМ на данном хосте). По умолчанию эта опция не активирована, но её легко добавить в конфигурацию через интерфейс vCenter.
Для шифрования в NVMe Memory Tiering нам не требуется система управления ключами (KMS) или встроенный поставщик ключей (NKP). Вместо этого ключ случайным образом генерируется на уровне ядра каждым хостом с использованием шифрования AES-XTS. Это избавляет от зависимости от внешних поставщиков ключей, поскольку данные, выгруженные в NVMe, актуальны только в течение времени жизни виртуальной машины.
Случайный 256-битный ключ создаётся при включении виртуальной машины, и данные шифруются в момент их выгрузки из DRAM в NVMe, а при обратной загрузке в DRAM для чтения — расшифровываются. Во время миграции виртуальной машины (vMotion) страницы памяти сначала расшифровываются, затем передаются по зашифрованному каналу vMotion на целевой хост, где генерируется новый ключ (целевым хостом) для последующих выгрузок памяти на NVMe.
Этот процесс одинаков как для «шифрования на уровне виртуальной машины», так и для «шифрования на уровне хоста» — единственное различие заключается в том, где именно применяется конфигурация.
Отказоустойчивость
Цель отказоустойчивости — повысить надёжность, сократить время простоя и, конечно, обеспечить спокойствие администратора. В контексте памяти существует несколько методов, некоторые из которых распространены больше других. В большинстве случаев для обеспечения избыточности памяти используют модули с коррекцией ошибок (ECC) и резервные модули памяти. Однако теперь, с появлением NVMe Memory Tiering, необходимо учитывать как DRAM, так и NVMe. Мы не будем подробно останавливаться на методах избыточности для DRAM, а сосредоточимся на NVMe в контексте памяти.
В VVF/VCF 9.0 функция NVMe Memory Tiering поддерживает аппаратную конфигурацию RAID, три-режимный (tri-mode) контроллер и технологию VROC (Virtual RAID on CPU) для обеспечения отказоустойчивости холодных или неактивных страниц памяти. Что касается RAID, мы не ограничиваемся какой-то одной конфигурацией: например, RAID-1 — это хорошее и поддерживаемое решение для обеспечения отказоустойчивости NVMe, но также поддерживаются RAID-5, RAID-10 и другие схемы. Однако такие конфигурации потребуют больше NVMe-устройств и, соответственно, увеличат стоимость.
Говоря о стоимости, стоит учитывать и наличие RAID-контроллеров, если вы планируете использовать RAID для отказоустойчивости. Обеспечение резервирования для холодных страниц — это архитектурное решение, которое должно приниматься с учётом баланса между затратами и операционными издержками. Что для вас важнее — надёжность, стоимость или простота эксплуатации? Также необходимо учитывать совместимость RAID-контроллера с vSAN: vSAN ESA не поддерживает RAID-контроллеры, в то время как vSAN OSA поддерживает, но они должны использоваться раздельно.
Преимущества RAID:
Обеспечивает избыточность для NVMe как устройства памяти
Повышает надёжность
Возможное сокращение времени простоя
Недостатки RAID:
Необходимость RAID-контроллера
Дополнительные расходы
Операционные издержки (настройка, обновление прошивок и драйверов)
Усложнение инфраструктуры
Появление новой точки отказа
Возможные проблемы совместимости с vSAN, если все накопители подключены к одной общей плате (backplane)
Как видно, у аппаратной избыточности есть как плюсы, так и минусы. Следите за обновлениями — в будущем могут появиться новые поддерживаемые методы отказоустойчивости.
Теперь предположим, что вы решили не использовать RAID-контроллер. Что произойдёт, если у вас есть один выделенный накопитель NVMe для Memory Tiering, и он выйдет из строя?
Ранее мы обсуждали, что на NVMe переносятся только «холодные» страницы памяти виртуальных машин по мере необходимости. Это означает, что страницы памяти самого хоста не находятся на NVMe, а также что на накопителе может быть как много, так и мало холодных страниц — всё зависит от нагрузки на DRAM. VMware не выгружает страницы (даже холодные), если в этом нет нужды — зачем расходовать вычислительные ресурсы?
Таким образом, если часть холодных страниц была выгружена на NVMe и накопитель вышел из строя, виртуальные машины, чьи страницы находились там, могут попасть в ситуацию высокой доступности (HA). Мы говорим "могут", потому что это произойдёт только если и когда ВМ запросит эти холодные страницы обратно из NVMe, которые теперь недоступны. Если же ВМ никогда не обратится к этим страницам, она продолжит работать без сбоев.
Иными словами, сценарий отказа зависит от активности в момент сбоя NVMe:
Если на NVMe нет холодных страниц — ничего не произойдёт.
Если есть немного холодных страниц — возможно, несколько ВМ войдут в HA-событие и перейдут на другой хост;
Если все холодные страницы хранились на NVMe — возможно, большинство ВМ окажутся в HA-режиме по мере запроса страниц.
Это не обязательно приведёт к полному отказу всех систем. Некоторые ВМ могут выйти из строя сразу, другие — позже, а третьи — вообще не пострадают. Всё зависит от их активности. Главное — хост ESX продолжит работу, а поведение виртуальных машин будет различаться в зависимости от текущих нагрузок.
Масштабируемость
Масштабируемость памяти — это, пожалуй, один из тех неожиданных факторов, который может обойтись очень дорого. Как известно, память составляет значительную часть (до 80%) общей стоимости нового сервера. В зависимости от подхода к закупке серверов, вы могли выбрать меньшие по объёму модули DIMM, установив их во все слоты — в этом случае у вас нет возможности увеличить объём памяти без полной замены всех модулей, а иногда даже самого сервера.
В также могли выбрать высокоплотные модули DIMM, оставив несколько слотов свободными для будущего роста — это позволяет масштабировать память, но тоже дорого, так как позже придётся докупать совместимые модули (если они ещё доступны). В обоих случаях масштабирование получается дорогим и медленным, особенно учитывая длительные процедуры утверждения бюджета и заказов в компаниях.
Именно здесь NVMe Memory Tiering показывает себя с лучшей стороны — снижая затраты и позволяя быстро увеличить объём памяти. В данном случае масштабирование памяти сводится к покупке хотя бы одного устройства NVMe и включению функции Memory Tiering — и вот у вас уже на 100% больше памяти для ваших хостов. Отличная выгода.
Можно даже «позаимствовать» накопитель из вашего хранилища vSAN, если есть возможность выделить его под Memory Tiering… но об этом чуть позже (делайте это с осторожностью).
В этой части важно понимать ограничения и возможности, чтобы обеспечить надёжность инвестиций в будущем. Мы уже говорили о требованиях к устройствам NVMe по показателям производительности и износостойкости, но что насчёт объёма NVMe-устройств? Об этом мы напишем в следующей части.
Таги: VMware, NVMe, Memory, Tiering, Hardware, Security, HA
На VMware Explore 2025 в Лас-Вегасе было сделано множество анонсов, а также проведены подробные обзоры новых функций и усовершенствований, включённых в VMware Cloud Foundation (VCF) 9, включая популярную функцию NVMe Memory Tiering. Хотя эта функция доступна на уровне вычислительного компонента VCF (платформа vSphere), мы рассматриваем её в контексте всей платформы VCF, учитывая её глубокую интеграцию с другими компонентами, такими как VCF Operations, к которым мы обратимся в дальнейшем.
Memory Tiering — это новая функция, включённая в VMware Cloud Foundation, и она стала одной из основных тем обсуждения в рамках многих сессий на VMware Explore 2025. VMware заметила большой интерес и получила множество отличных вопросов от клиентов по поводу внедрения, сценариев использования и других аспектов. Эта серия статей состоит из нескольких частей, где мы постараемся ответить на наиболее частые вопросы от клиентов, партнёров и внутренних команд.
Предварительные требования и совместимость оборудования
Оценка рабочих нагрузок
Перед включением Memory Tiering крайне важно провести тщательную оценку вашей среды. Начните с анализа рабочих нагрузок в вашем датацентре, уделяя особое внимание использованию памяти. Один из ключевых показателей, на который стоит обратить внимание — активная память рабочей нагрузки.
Чтобы рабочие нагрузки подходили для Memory Tiering, общий объём активной памяти должен составлять не более 50% от ёмкости DRAM. Почему именно 50%?
По умолчанию Memory Tiering предоставляет на 100% больше памяти, то есть удваивает доступный объём. После включения функции половина памяти будет использовать DRAM (Tier 0), а другая половина — NVMe (Tier 1). Таким образом, мы стремимся, чтобы активная память умещалась в DRAM, так как именно он является самым быстрым источником памяти и обеспечивает минимальное время отклика при обращении виртуальных машин к страницам памяти. По сути, это предварительное условие, гарантирующее, что производительность при работе с активной памятью останется стабильной.
Важный момент: при оценке анализируется активность памяти приложений, а не хоста, поскольку в Memory Tiering страницы памяти ВМ переносятся (demote) на NVMe-устройство, когда становятся «холодными» или неактивными, но страницы vmkernel хоста не затрагиваются.
Как узнать объём активной памяти?
Как мы уже отметили, при использовании Memory Tiering только страницы памяти ВМ переносятся на NVMe при бездействии, тогда как системные страницы хоста остаются нетронутыми. Поэтому нам важно определить процент активности памяти рабочих нагрузок.
Это можно сделать через интерфейс vCenter в vSphere Client, перейдя в:
VM > Monitor > Performance > Advanced
Затем измените тип отображения на Memory, и вы увидите метрику Active Memory. Если она не отображается, нажмите Chart Options и выберите Active для отображения.
Обратите внимание, что метрика Active доступна только при выборе периода Real-Time, так как это показатель уровня 1 (Level 1 stat). Активная память измеряется в килобайтах (KB).
Если вы хотите собирать данные об активной памяти за более длительный период, можно сделать следующее: в vCenter Server перейдите в раздел Configure > Edit > Statistics.
Затем измените уровень статистики (Statistics Level) с Level 1 на Level 2 для нужных интервалов.
Делайте это на свой страх и риск, так как объём пространства, занимаемого базой данных, существенно увеличится. В среднем, он может вырасти раза в 3 или даже больше. Поэтому не забудьте вернуть данную настройку обратно по завершении исследования.
Также вы можете использовать другие инструменты, такие как VCF Operations или RVTools, чтобы получить информацию об активной памяти ваших рабочих нагрузок.
RVTools также собирает данные об активности памяти в режиме реального времени, поэтому убедитесь, что вы учитываете возможные пиковые значения и включаете периоды максимальной нагрузки ваших рабочих процессов.
Примечания и ограничения
Для VCF 9.0 технология Memory Tiering пока не подходит для виртуальных машин, чувствительных к задержкам (latency-sensitive VMs), включая:
Высокопроизводительные ВМ (High-performance VMs)
Защищённые ВМ, использующие SEV / SGX / TDX
ВМ с включенным механизмом непрерывной доступности Fault Tolerance
Так называемые "Monster VMs" с объёмом памяти более 1 ТБ.
В смешанных средах рекомендуется выделять отдельные хосты под Memory Tiering или отключать эту функцию на уровне отдельных ВМ. Эти ограничения могут быть сняты в будущем, поэтому стоит следить за обновлениями и расширением совместимости с различными типами нагрузок.
Программные предварительные требования
С точки зрения программного обеспечения, Memory Tiering требует новой версии vSphere, входящей в состав VCF/VVF 9.0. И vCenter, и ESX-хосты должны быть версии 9.0 или выше. Это обеспечивает готовность среды к промышленной эксплуатации, включая улучшения в области надёжности, безопасности (включая шифрование на уровне ВМ и хоста) и осведомлённости о vMotion.
Настройку Memory Tiering можно выполнить:
На уровне хоста или кластера
Через интерфейс vCenter UI
С помощью ESXCLI или PowerCLI
А также с использованием Desired State Configuration для автоматизации и последовательных перезагрузок (rolling reboots).
В VVF и VCF 9.0 необходимо создать раздел (partition) на NVMe-устройстве, который будет использоваться Memory Tiering. На данный момент эта операция выполняется через ESXCLI или PowerCLI (да, это можно автоматизировать с помощью скрипта). Для этого потребуется доступ к терминалу и включённый SSH. Позже мы подробно рассмотрим оба варианта и даже приведём готовый скрипт для автоматического создания разделов на нескольких серверах.
Совместимость NVMe
Аппаратная часть — это основа производительности Memory Tiering. Так как NVMe-накопители используются как один из уровней оперативной памяти, совместимость оборудования критически важна.
VMware рекомендует использовать накопители со следующими характеристиками:
Выносливость (Endurance): класс D или выше (больше или равно 7300 TBW) — для высокой долговечности при множественных циклах записи.
Производительность (Performance): класс F (100 000–349 999 операций записи/сек) или G (350 000+ операций записи/сек) — для эффективной работы механизма tiering.
Некоторые OEM-производители не указывают класс напрямую в спецификациях, а обозначают накопители как read-intensive (чтение) или mixed-use (смешанные нагрузки).
В таких случаях рекомендуется использовать Enterprise Mixed Drives с показателем не менее 3 DWPD (Drive Writes Per Day).
Если вы не знакомы с этим термином: DWPD отражает выносливость SSD и показывает, сколько раз в день накопитель может быть полностью перезаписан на протяжении гарантийного срока (обычно 3–5 лет) без отказов. Например, SSD объёмом 1 ТБ с 1 DWPD способен выдерживать 1 ТБ записей в день на протяжении гарантийного периода.
Чем выше DWPD, тем долговечнее накопитель — что критически важно для таких сценариев, как VMware Memory Tiering, где выполняется большое количество операций записи.
Также рекомендуется воспользоваться Broadcom Compatibility Guide, чтобы проверить, какие накопители соответствуют рекомендованным классам и как они обозначены у конкретных OEM-производителей. Этот шаг настоятельно рекомендуется, так как Memory Tiering может производить большие объёмы чтения и записи на NVMe, и накопители должны быть высокопроизводительными и надёжными.
Хотя Memory Tiering позволяет снизить совокупную стоимость владения (TCO), экономить на накопителях для этой функции категорически не рекомендуется.
Что касается форм-факторов, поддерживается широкий выбор вариантов. Вы можете использовать:
Устройства формата 2.5", если в сервере есть свободные слоты.
Вставляемые модули E3.S.
Или даже устройства формата M.2, если все 2.5" слоты уже заняты.
Наилучший подход — воспользоваться Broadcom Compatibility Guide. После выбора нужных параметров выносливости (Endurance, класс D) и производительности (Performance, класс F или G), вы сможете дополнительно указать форм-фактор и даже параметр DWPD.
Такой способ подбора поможет вам выбрать оптимальный накопитель для вашей среды и быть уверенными, что используемое оборудование полностью соответствует требованиям Memory Tiering.
В числе множества новых возможностей, представленных в VMware Cloud Foundation 9.0, функция многоуровневой памяти (Memory Tiering) стала одной из ключевых в составе VMware vSphere для VCF 9.0. Как и многие другие функции vSphere, Memory Tiering с использованием NVMe снижает совокупную стоимость владения, полностью интегрируется с ESX (да, гипервизор называется снова ESX), а также с VMware vCenter. Она поддерживает гибкие варианты развертывания, предоставляя клиентам множество опций при настройке.
Memory Tiering с NVMe была представлена в составе VCF 9.0, и важно подчеркнуть её ценность для компаний, стремящихся сократить расходы, особенно при закупке оборудования, так как стоимость оперативной памяти составляет значительную часть спецификации аппаратного обеспечения (Bill of Materials, BOM). Функция, позволяющая масштабировать память за счёт использования недорогого оборудования, может существенно повлиять на распределение ИТ-бюджета и приоритетность проектов.
Memory Tiering с NVMe можно настроить через привычный вам интерфейс vCenter UI, с помощью командной строки через ESXCLI, а также через скрипты в PowerCLI. Можно использовать любую из этих опций или их комбинацию для настройки многоуровневой памяти как на уровне хоста, так и на уровне кластера.
Аппаратное обеспечение имеет значение
Перед настройкой функции Memory Tiering крайне важно обратить внимание на рекомендуемое оборудование. И это не просто совет, а настоятельная рекомендация. Поскольку в роли памяти будут использоваться устройства NVMe, важно, чтобы они были не только надёжными, но и демонстрировали высокую производительность при интенсивной нагрузке. Аналогично тому, как вы определяли рекомендуемые устройства для vSAN, здесь также есть требования: NVMe-устройства должны соответствовать классу выносливости D (не менее 7300 TBW) и классу производительности F или выше (не менее 100 000 операций записи в секунду) для использования в составе многоуровневой памяти. VMware рекомендует воспользоваться руководством по совместимости с vSAN, чтобы убедиться, что выбранные устройства соответствуют этим требованиям.
Также важно отметить, что поддерживается множество форм-факторов. Так что если в вашем сервере нет свободных слотов для 2.5-дюймовых накопителей, но есть, например, свободный слот M.2, вы вполне можете использовать его для Memory Tiering.
Создание раздела на NVMe
После того как вы тщательно выбрали рекомендованные NVMe-устройства (кстати, их можно объединить в RAID-конфигурацию для обеспечения отказоустойчивости), следующим шагом будет создание раздела для NVMe-уровня памяти. Если на выбранном устройстве уже существуют какие-либо разделы, их необходимо удалить перед конфигурацией.
Максимальный размер раздела в текущей версии составляет 4 ТБ, однако вы можете использовать и более ёмкое устройство — это позволит «циклически использовать ячейки» и потенциально продлить срок службы NVMe-накопителя. Хотя размер раздела зависит от ёмкости устройства (до 4 ТБ), фактический объём NVMe, задействованный в качестве памяти, рассчитывается на основе объёма DRAM на хосте и заданного соотношения. По умолчанию в VCF 9.0 применяется соотношение DRAM:NVMe как 1:1 — это в четыре раза больше, чем в технологическом превью на vSphere 8.0 Update 3.
Например, если у вас есть хост с 1 ТБ DRAM и NVMe-устройство на 4 ТБ, то будет создан раздел размером 4 ТБ, но использоваться в рамках Memory Tiering будет только 1 ТБ — если, конечно, вы не измените соотношение. Это соотношение настраивается пользователем, однако стоит проявить осторожность: изменение параметра может негативно повлиять на производительность и сильно зависит от характера и активности рабочих нагрузок. Подробнее об этом — далее.
В текущей версии создание раздела выполняется через командную строку ESXCLI на хосте с помощью следующей команды:
esxcli system tierdevice create -d /vmfs/devices/disks/<UID NVMe-устройства>
Пример:
Конфигурация хоста или кластера
После создания раздела tierdevice остаётся последний шаг — настроить хост или кластер. Да, вы можете гибко подойти к конфигурации: настроить один, несколько хостов или весь кластер целиком. В идеале рекомендуется настраивать кластер гомогенно; однако стоит учитывать, что некоторые типы виртуальных машин пока не поддерживаются в режиме NVMe Memory Tiering. К ним относятся:
ВМ с высокими требованиями к производительности и низкой задержке
Защищённые ВМ (SEV, SGX, TDX),
ВМ с непрерывной доступностью (FT)
"Монстр-машины" (1 ТБ памяти, 128 vCPU)
Вложенные ВМ (nested VMs).
Если в одном кластере у вас сочетаются такие ВМ с обычными рабочими нагрузками, которые могут использовать Memory Tiering, вы можете либо выделить отдельные хосты для «особых» ВМ, либо отключить Memory Tiering на уровне конкретных виртуальных машин.
Для включения Memory Tiering на хосте вы можете воспользоваться ESXCLI, PowerCLI или интерфейсом vCenter UI. В ESXCLI команда очень простая:
esxcli system settings kernel set -s MemoryTiering -v TRUE
В vCenter UI это делается путём изменения параметра VMkernel.Boot.memoryTiering на значение TRUE. Обратите внимание на слово BOOT — для применения параметра хост необходимо перезагрузить. Также перед внесением изменений хост нужно перевести в режим обслуживания.
А если вы хотите настроить весь кластер? Что ж, это даже проще. Вы можете воспользоваться функцией Desired State Configuration в vCenter. Всё, что нужно — создать новый черновик с включённой настройкой memory_tiering в разделе vmkernel > options, установив её в значение true. После этого остаётся просто применить этот драфт ко всем хостам в кластере (или только к выбранным хостам).
После применения конфигурации хосты автоматически будут переведены в режим обслуживания и перезагружены поочерёдно, по мере необходимости. И всё — на этом настройка завершена. Теперь вы можете воспользоваться преимуществами:
Лучшего коэффициента консолидации ВМ
Сниженной совокупной стоимости владения
Простой масштабируемости памяти — по значительно более низкой цене
После завершения настройки вы увидите как минимум двукратное увеличение доступной памяти, а также визуальное отображение уровней памяти (memory tiers) в интерфейсе vCenter UI.
Затраты на память по-прежнему остаются одной из самых крупных статей расходов на серверную инфраструктуру, и при этом большая часть дорогой оперативной памяти (DRAM) используется неэффективно. А что, если вы могли бы удвоить плотность виртуальных машин и сократить совокупную стоимость владения до 40%?
С выходом VMware Cloud Foundation 9.0 технология Memory Tiering (многоуровневая организация памяти) делает это возможным. Команда инженеров VMware недавно представила результаты тестирования производительности, которые демонстрируют, как эта технология меняет экономику датацентров. Подробности — в новом исследовании: Memory Tiering Performance in VMware Cloud Foundation 9.0.
Ниже мы расскажем об основных результатах исследования, которые показывают, что Memory Tiering позволила увеличить плотность виртуальных машин в 2 раза при незначительном снижении производительности. Для получения полной информации о принципах работы Memory Tiering и более подробных данных о производительности, ознакомьтесь с полным текстом исследования.
Как Memory Tiering улучшает производительность датацентров и снижает затраты
В VMware Cloud Foundation 9.0 технология Memory Tiering предоставляет виртуальным машинам единое логическое адресное пространство памяти. Однако «под капотом» она управляет двумя уровнями памяти: Tier 0 (DRAM) и Tier 1 (Memory Tiering), в зависимости от активности памяти виртуальной машины. Фактически, система старается держать «горячую» (активную) память в DRAM, а «холодную» (неактивную) — на NVMe.
Со стороны виртуальной машины это выглядит как единое, увеличенное пространство памяти. В фоновом режиме гипервизор ESX динамически управляет размещением страниц памяти между двумя уровнями — DRAM и NVMe — обеспечивая при этом оптимальную производительность.
VMware провела тестирование на различных корпоративных нагрузках, чтобы подтвердить эффективность Memory Tiering. Были использованы серверы на базе процессоров Intel и AMD с различными конфигурациями DRAM. В VMware Cloud Foundation 9.0 по умолчанию используется соотношение DRAM к NVMe 1:1, и во всех тестах применялось именно оно.
Увеличение плотности ВМ в 2 раза, потеря производительности - 5-10% (MySQL, SQL)
Login Enterprise: Производительность виртуальных рабочих столов
Команда VMware использовала Login Enterprise для тестирования производительности VDI (виртуальных рабочих столов) в различных сценариях. Во всех тестах удалось удвоить количество виртуальных машин на хосте ESX при минимальном снижении производительности. Например, в конфигурации из трёх узлов vSAN:
Удвоили количество VDI-сессий, которые могли выполняться на трёхузловом кластере vSAN — с 300 (только DRAM) до 600 (с использованием Memory Tiering).
При этом не было зафиксировано потери производительности по сравнению с аналогичной конфигурацией, использующей только DRAM.
Тест VMmark 3.1, включающий несколько нагрузок, имитирующих работу корпоративных приложений, показал отличные результаты:
Конфигурация с Memory Tiering достигла 6 тайлов против 3 тайлов в конфигурации, использующей только DRAM. Это в 2 раза лучше.
При сравнении конфигураций с 1 ТБ DRAM и с 1 ТБ Memory Tiering, снижение производительности составило всего 5%, несмотря на использование более медленной памяти NVMe в режиме Memory Tiering.
HammerDB и DVD Store: производительность баз данных
Производительность баз данных — один из самых ресурсоёмких тестов для любой инфраструктуры. VMware использовала HammerDB и DVD Store в качестве нагрузок для тестирования SQL Server, Oracle Database и MySQL. С помощью Memory Tiering удалось удвоить количество виртуальных машин при минимальном влиянии на производительность. Например, в тесте Oracle Database с нагрузкой DVD Store были получены следующие результаты:
На хосте ESX с Memory Tiering удалось запустить 8 виртуальных машин против 4 в конфигурации, использующей только DRAM — плотность удвоилась.
При сравнении конфигураций с 1 ТБ DRAM и с 1 ТБ Memory Tiering снижение производительности составило менее 5%.
Мониторинг Memory Tiering на хостах ESX
Для обеспечения высокой производительности при использовании Memory Tiering следует отслеживать два ключевых показателя:
Поддерживайте активную память на уровне 50% или меньше от объёма DRAM — это обеспечит оптимальную производительность.
Следите за задержкой чтения с NVMe-устройства. Наилучшая производительность достигается при задержке менее 200 микросекунд.
Преобразите экономику вашего датацентра
Memory Tiering предлагает новый подход к организации памяти:
До 40% экономии совокупной стоимости владения (TCO) за счёт снижения требований к DRAM.
Прозрачная работа — не требует изменений в приложениях или гостевых операционных системах.
До 2-кратного увеличения плотности виртуальных машин для различных типов нагрузок.
Гибкая инфраструктура, адаптирующаяся к изменяющимся требованиям рабочих нагрузок.
Memory Tiering уже доступна в VMware Cloud Foundation 9. Скачайте полное исследование производительности, чтобы подробнее ознакомиться с методологией тестирования, результатами и рекомендациями по внедрению.
Хотите попробовать Memory Tiering на практике?
Полноценный практический лабораторный курс предоставляет живую среду vSphere 9.0, где вы сможете изучить Memory Tiering и узнать, как использование NVMe-накопителей позволяет расширить и оптимизировать доступную память для хостов ESX.
Многоуровневая память (Memory Tiering) снижает затраты и повышает эффективность использования ресурсов. Эта функция была впервые представлена в виде технологического превью в vSphere 8.0 Update 3 и получила очень положительные отзывы от клиентов. Обратная связь от пользователей касалась в основном устойчивости данных, безопасности и гибкости в конфигурациях хостов и виртуальных машин. С выходом платформы VCF 9.0 все эти вопросы были решены.
Теперь многоуровневая память — это готовое к использованию в производственной среде решение, включающее поддержку DRS и vMotion, повышенную производительность, улучшенное соотношение DRAM:NVMe по умолчанию (1:1), а также множество других улучшений, направленных на повышение надёжности этой функции.
В компании Broadcom было проведено масштабное внутреннее тестирование, которое показало, что использование многоуровневой памяти позволяет сократить совокупную стоимость владения (TCO) до 40% для большинства рабочих нагрузок, а также обеспечивает рост загрузки CPU, позволяя использовать на 25–30% больше ядер под задачи. Меньше затрат — больше ресурсов. Кроме того, лучшая консолидация ВМ может означать меньше серверов или больше ВМ на каждом сервере.
Многоуровневая память обеспечивает все эти и многие другие преимущества, используя NVMe-устройства в качестве второго уровня памяти. Это позволяет увеличить объём доступной памяти до 4 раз, задействуя при этом существующие слоты сервера для недорогих устройств, таких как NVMe. Между предварительной технической версией и готовым к промышленному использованию выпуском с VCF 9.0 существует множество важных отличий. Давайте рассмотрим эти улучшения.
Новые возможности Advanced Memory Tiering
Смешанный кластер
Многоуровневая память (Memory Tiering) может быть настроена на всех хостах в кластере, либо вы можете включить эту функцию только для части хостов. Причины для этого могут быть разными: например, вы хотите протестировать технологию на одном хосте и нескольких ВМ, возможно, только несколько хостов имеют свободные слоты для NVMe-устройств, или вам разрешили приобрести лишь ограниченное количество накопителей. Хорошая новость в том, что поддерживаются все эти и многие другие сценарии — чтобы соответствовать текущим возможностям заказчиков. Вы можете выбрать только часть хостов или активировать эту функцию на всех.
Резервирование
Резервирование всегда является приоритетом при проектировании архитектуры. Как вы знаете, не бывает серьезной производственной среды с одной единственной сетевой картой на сервер. Что касается накопителей, то обеспечить отказоустойчивость можно с помощью конфигурации RAID — именно это и было реализовано. Многоуровневая память может использовать два и более NVMe-устройств в аппаратной RAID-конфигурации для защиты от отказов устройств.
Поддержка DRS
Технология DRS (Distributed Resource Scheduler) существует уже довольно давно, это одна из функций, без которой большинство клиентов уже не могут обходиться. VMware вложила много усилий в то, чтобы сделать алгоритм Memory Tiering «умным» — чтобы он не только анализировал состояние страниц памяти, но и эффективно управлял ими в пределах кластера.
DRAM:NVMe — новое соотношение
В vSphere 8.0 U3 функция Memory Tiering была представлена как технологическое превью. Тогда использовалось соотношение 4:1, то есть на 4 части DRAM приходилась 1 часть NVMe. Это дало увеличение объёма памяти на 25%. Хотя это может показаться незначительным, при сравнении стоимости увеличения объёма памяти на 25% с использованием DRAM и NVMe становится очевидно, насколько это выгодно.
В VCF 9.0, после всех улучшений производительности, изменили соотношение по умолчанию: теперь оно 1:1 — то есть увеличение объема памяти в 2 раза по умолчанию. И это значение можно настраивать в зависимости от нагрузки и потребностей. То есть, если у вас есть хост ESX с 1 ТБ DRAM и вы включаете Memory Tiering, вы можете получить 2 ТБ доступной памяти. Для некоторых сценариев, таких как VDI, возможно соотношение до 1:4 — это позволяет вчетверо увеличить объём памяти при минимальных затратах.
Другие улучшения
В VCF 9.0 было реализовано множество других улучшений функции Memory Tiering. Общие улучшения производительности сделали решение более надёжным, гибким, отказоустойчивым и безопасным. С точки зрения безопасности добавлено шифрование: как на уровне виртуальных машин, так и на уровне хоста. Страницы памяти ВМ теперь могут быть зашифрованы индивидуально для каждой ВМ или сразу для всех машин на хосте — с помощью простой и удобной настройки.
Как начать использовать Advanced Memory Tiering
С чего начать? Как понять, подходят ли ваши рабочие нагрузки для Memory Tiering? Клиентам стоит учитывать следующие факторы при принятии решения о внедрении Memory Tiering:
Активная память
Memory Tiering особенно подходит для клиентов с высоким потреблением (выделено под ВМ более 50%) и низким уровнем активного использования памяти (фактически используемая нагрузками — менее 50% от общего объема DRAM).
Скриншот ниже показывает, как можно отслеживать активную память и объём DRAM с помощью vCenter:
NVMe-устройства
Существуют рекомендации по производительности и ресурсу для поддерживаемых накопителей — в руководстве по совместимости Broadcom (VMware) указано более 1500 одобренных моделей. NVMe-накопители, такие как E3.S, являются модульными и зачастую могут быть установлены в свободные слоты серверов, например, как в Dell PowerEdge, показанном ниже. VMware настоятельно рекомендует клиентам обращаться к руководству по совместимости Broadcom, чтобы обеспечить нужный уровень производительности своих рабочих нагрузок за счёт выбора рекомендованных устройств.
Многоуровневая память Advanced Memory Tiering снижает затраты и одновременно повышает эффективность использования ресурсов, и её будущее выглядит многообещающим. Уже ведётся работа над рядом улучшений, которые обеспечат ещё больший комфорт и дополнительные преимущества. В ближайшие месяцы будет доступно больше информации о технологии Memory Tiering.
Продолжаем рассказывать о технологии ярусной памяти Memory Tiering, которая появилась в VMware vSphere 8 Update 3 (пока в статусе Tech Preview). Вильям Лам написал об интересной возможности использования одного устройства как для NVMe Tiering, так и для датасторов VMFS на платформе VMware vSphere.
На данный момент включение NVMe Tiering требует выделенного устройства NVMe. Для производственных систем это, вероятно, не проблема, так как важно избежать конкуренции за ресурсы ввода-вывода на одном устройстве NVMe. Однако для среды разработки или домашней лаборатории это может быть проблемой из-за ограниченного количества доступных NVMe-устройств.
Оказывается, можно использовать одно устройство NVMe для NVMe Tiering!
Для владельцев систем малого форм-фактора, таких как ASUS NUC, с ограниченным количеством NVMe-устройств, есть такой вариант: вы можете запустить ESXi с USB-устройства, сохранив возможность использовать локальный VMFS-датастор и NVMe Tiering. Таким образом, у вас даже останется свободный слот или два для vSAN OSA или ESA!
Важно: Это решение не поддерживается официально со стороны VMware. Используйте его на свой страх и риск.
Шаг 1 - Убедитесь, что у вас есть пустое устройство NVMe, так как нельзя использовать устройство с существующими разделами. Для идентификации и получения имени SSD-устройства используйте команду vdq -q.
Затем запустите его, как показано на скриншоте ниже:
Примечание: скрипт только генерирует необходимые команды, но вам нужно будет выполнить их вручную. Сохраните их — это избавит вас от необходимости вручную рассчитывать начальные и конечные сектора хранилища.
Пример выполнения сгенерированных команд для конкретной настройки: есть NVMe-устройство объёмом 1 ТБ (913,15 ГБ), из которого выделяется 256 ГБ для NVMe Tiering, а оставшееся пространство будет использовано для VMFS-датастора.
С помощью клиента ESXi Host Client мы можем увидеть два раздела, которые мы только что создали:
Шаг 3 – Включите функцию NVMe Tiering, если она еще не активирована, выполнив следующую команду ESXCLI:
esxcli system settings kernel set -s MemoryTiering -v TRUE
Шаг 4 – Настройте желаемый процент использования NVMe Tiering (от 25 до 400), исходя из конфигурации вашей физической оперативной памяти (DRAM), выполнив следующую команду:
esxcli system settings advanced set -o /Mem/TierNvmePct -i 400
Шаг 5 – Наконец, перезагрузите хост ESXi, чтобы настройки NVMe Tiering вступили в силу. После перезагрузки ваш хост ESXi будет поддерживать использование одного NVMe-устройства как для NVMe Tiering, так и для локального VMFS-датастора, готового для размещения виртуальных машин.
Компания VMware недавно выпустила интересное видео в рамках серии Extreme Performance, где рассматривается, как технологии Memory Tiering могут оптимизировать серверную инфраструктуру, улучшить консолидацию серверов и снизить общую стоимость владения (TCO). Ведущие эксперты, работающие в сфере производительности платформ VMware, делятся новейшими разработками и результатами тестов, которые помогут сделать работу администраторов с серверами более эффективной.
Основные моменты видео:
Что такое Memory Tiering? Memory Tiering — это технология, реализованная в ядре ESXi, которая прозрачно для приложений и гостевых ОС разделяет память на два уровня:
Tier 1: Быстрая память DRAM.
Tier 2: Бюджетные и емкие устройства памяти, такие как NVMe SSD и CXL.
Преимущества Memory Tiering:
Увеличение доступной памяти за счет использования NVMe в качестве памяти второго уровня.
Снижение затрат на память до 50%.
Исключение таких проблем, как ballooning и случайный обмен страницами.
Реальные результаты:
Удвоение плотности виртуальных машин (VMs): на одной хост-машине можно разместить вдвое больше ВМ без заметной потери производительности (<3%).
Оптимизация работы баз данных: для SQL Server и Oracle наблюдалось почти линейное масштабирование с минимальными потерями производительности.
Стабильный пользовательский опыт (VDI): эталонный тест Login VSI показал, что даже при удвоении числа ВМ пользовательский опыт остается на высоком уровне.
Ключевые метрики и рекомендации:
Active memory: один из основных параметров для мониторинга. Оптимальный уровень — около 50% от объема Tier 1 (DRAM).
Использование NVMe: рекомендации по чтению и записи (до 200 мс latency для чтения и 500 мс для записи).
Практические примеры и кейсы:
Клиенты из финансового и медицинского секторов, такие как SS&C Cloud, уже успешно применяют Memory Tiering, чтобы уменьшить затраты на серверы и улучшить их производительность.
Советы по настройке и мониторингу:
Как отслеживать активность NVMe-устройств и состояние памяти через vCenter.
Какие показатели важны для анализа производительности.
Кому будет полезно:
Системным администраторам, DevOps-инженерам и специалистам по виртуализации.
Организациям, которые стремятся сократить затраты на ИТ-инфраструктуру и повысить плотность виртуализации.
Любителям передовых технологий, которые хотят понять, как современные подходы меняют управление памятью в дата-центрах.
Memory Tiering — это прорывная технология, которая уже сегодня позволяет добиться больших результатов в консолидации серверов. Узнайте, как её применить в вашем окружении, и станьте частью следующего поколения производительности серверов.
Таги: VMware, vSphere, Memory, Performance, NVMe, Video
Memory Tiering использует более дешевые устройства в качестве памяти. В Update 3 платформа vSphere использует флэш-устройства PCIe на базе NVMe в качестве второго уровня памяти, что увеличивает доступный объем памяти на хосте ESXi. Memory Tiering через NVMe оптимизирует производительность, распределяя выделение памяти виртуальных машин либо на устройства NVMe, либо на более быструю динамическую оперативную память (DRAM) на хосте. Это позволяет увеличить объем используемой памяти и повысить емкость рабочих нагрузок, одновременно снижая общую стоимость владения (TCO).
Вильям Лам написал интересный пост о выводе информации для NVMe Tiering в VMware vSphere через API. После успешного включения функции NVMe Tiering, которая была введена в vSphere 8.0 Update 3, вы можете найти полезную информацию о конфигурации NVMe Tiering, перейдя к конкретному хосту ESXi, затем выбрав "Configure" -> "Hardware" и в разделе "Memory", как показано на скриншоте ниже.
Здесь довольно много информации, поэтому давайте разберём отдельные элементы, которые полезны с точки зрения NVMe-тиринга, а также конкретные vSphere API, которые можно использовать для получения этой информации.
Memory Tiering Enabled
Поле Memory Tiering указывает, включён ли тиринг памяти на хосте ESXi, и может иметь три возможных значения: "No Tiering" (без тиринга), "Hardware Memory Tiering via Intel Optane" (аппаратный тиринг памяти с помощью технологии Intel Optane) или "Software Memory Tiering via NVMe Tiering" (программный тиринг памяти через NVMe). Мы можем получить значение этого поля, используя свойство "memoryTieringType" в vSphere API, которое имеет три перечисленных значения.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
Поле Tier 0 представляет общий объём физической оперативной памяти (DRAM), доступной на хосте ESXi. Мы можем получить это поле, используя свойство "memoryTierInfo" в vSphere API, которое возвращает массив результатов, содержащий значения как Tier 0, так и Tier 1.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
((Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTierInfo | where {$_.Type -eq "DRAM"}).Size
Tier 1 Memory
Поле Tier 1 представляет общий объём памяти, предоставляемой NVMe-тирингом, которая доступна на хосте ESXi. Мы можем получить это поле, используя свойство "memoryTierInfo" в vSphere API, которое возвращает массив результатов, содержащий значения как Tier 0, так и Tier 1.
Примечание: Можно игнорировать термин "Unmappable" — это просто другой способ обозначения памяти, отличной от DRAM.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
((Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTierInfo | where {$_.Type -eq "NVMe"}).Size
Поле Total представляет общий объём памяти, доступный ESXi при объединении как DRAM, так и памяти NVMe-тиринга, который можно агрегировать, используя размеры Tier 0 и Tier 1 (в байтах).
Устройства NVMe для тиринга
Чтобы понять, какое устройство NVMe настроено для NVMe-тиринга, нужно перейти в раздел "Configure" -> "Storage" -> "Storage Devices", чтобы просмотреть список устройств. В столбце "Datastore" следует искать значение "Consumed for Memory Tiering", как показано на скриншоте ниже. Мы можем получить это поле, используя свойство "usedByMemoryTiering" при энумерации всех устройств хранения.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
Отношение объёма DRAM к NVMe по умолчанию составляет 25% и настраивается с помощью следующего расширенного параметра ESXi под названием "Mem.TierNvmePct". Мы можем получить значение этого поля, используя либо vSphere API ("OptionManager"), либо через ESXCLI.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
Вильям собрал все вышеперечисленные парметры и создал скрипт PowerCLI под названием "get-nvme-tiering-info.ps1", который предоставляет удобное резюме для всех хостов ESXi в рамках конкретного кластера Sphere (вы также можете изменить скрипт, чтобы он запрашивал конкретный хост ESXi). Это может быть полезно для быстрого получения информации о хостах, на которых NVMe-тиринг может быть настроен (или нет).
vSphere Memory Tiering - это очень интересная функция, которую VMware выпустила в качестве технического превью в составе vSphere 8.0 Update 3, чтобы дать своим клиентам возможность оценить механику ранжирования памяти в их тестовых средах. Об этом мы уже немного рассказывали, а сегодня дополним.
По сути, Memory Tiering использует более дешевые устройства в качестве памяти. В vSphere 8.0 Update 3 vSphere использует флэш-устройства PCIe на базе NVMe в качестве второго уровня памяти, что увеличивает доступный объем памяти на хосте ESXi. Memory Tiering через NVMe оптимизирует производительность, распределяя выделение памяти виртуальных машин либо на устройства NVMe, либо на более быструю динамическую оперативную память (DRAM) на хосте. Это позволяет увеличить объем используемой памяти и повысить емкость рабочих нагрузок, одновременно снижая общую стоимость владения (TCO).
Memory Tiering также решает проблемы несоответствия между ядрами процессора и объемом памяти и способствует лучшей консолидации рабочих нагрузок и виртуальных машин.
Memory Tiering настраивается на каждом ESXi в кластере, и все хосты должны работать на vSphere 8.0 U3. По умолчанию соотношение DRAM к NVMe составляет 4:1, но его можно изменить для использования большего количества ресурсов NVMe в качестве памяти.
Для изменения этого соотношения нужно зайти в Host > Manage > System > Advanced settings и поменять там настройку Mem.TierNvmePct. По умолчанию это 25, то есть NVMe занимает 25% от общей оперативной памяти хоста ESXi. Максимальное значение составляет 400, минимальное - 1.
Технические подробности настройки vSphere Memory Tiering описаны в статье базы знаний KB 95944. Там можно скачать документ "Memory Tiering over NVMe Tech Preview", где описываются все аспекты использования данной технологии:
Если же вы хотите посмотреть на работу этой штуки в действии, то можете почитать интересные посты Вильяма Лама:
Недавно Дункан Эппинг выступал с докладом на конференции VMUG в Бельгии, где была тема «Инновации в VMware от Broadcom». В ходе доклада он кратко изложил процесс и различные типы инноваций, а также то, к чему это может привести. Во время сессии он рассмотрел три проекта, а именно vSAN ESA, Distributed Services Engine и проект, над которым сейчас работают, под названием Memory Tiering.
Memory Tiering — это очень интересная концепция, которая впервые была публично представлена на конференции VMware Explore несколько лет назад как потенциальная будущая фича гипервизора. Вы можете задаться вопросом, зачем кому-то захочется ранжировать память, ведь влияние этого процесса на производительность может быть значительным. Существует несколько причин для этого, одна из которых — стоимость памяти. Еще одна проблема, с которой сталкивается индустрия, заключается в том, что емкость (и производительность) памяти не росли такими же темпами, как емкость CPU, что привело к тому, что во многих средах память стала узким местом. Иными словами, дисбаланс между процессором и памятью значительно увеличился. Именно поэтому VMware запустила проект Capitola.
Когда обсуждался проект Capitola, большинство внимания было уделено Intel Optane, и большинство интересующихся знает, что с этим случилось. Некоторые думали, что это также приведет к закрытию проекта Capitola, а также технологий ранжирования и объединения памяти. Но это совершенно не так: VMware продолжает активно работать над проектом и публично обсуждает прогресс, хотя нужно знать, где искать эту информацию. Если вы посмотрите эту сессию, станет ясно, что существует множество усилий, которые позволят клиентам ранжировать память различными способами, одним из которых, конечно, являются различные решения на базе CXL, которые скоро появятся на рынке.
Один из способов — это Memory Tiering с помощью карты ускорителя CXL, по сути, это FPGA, предназначенная исключительно для увеличения емкости памяти, аппаратной разгрузки техник ранжирования памяти и ускорения определенных функций, где память имеет ключевое значение, таких как, например, vMotion. Как упоминалось в сессии SNIA, использование карты ускорителя может привести к сокращению времени миграции на 30%. Такая карта ускорителя также открывает другие возможности, например, memory pooling, чего клиенты просили с тех пор, как в VMware создали концепцию кластера.
Также это открывает возможности совместного использования вычислительных ресурсов между хостами. Только представьте, ваша виртуальная машина может использовать емкость памяти, доступную на другом хосте, без необходимости перемещать саму виртуальную машину. Понятное дело, что это может оказать значительное влияние на производительность.
Именно здесь вступают в игру технологии VMware. На VMworld в 2021 году, когда был представлен проект Capitola, команда VMware также поделилась результатами последних тестов производительности, и было показано, что снижение производительности составило около 10% при использовании 50% оперативной памяти (DRAM) и 50% памяти Optane. Эта демонстрация показывает истинную мощь VMware vSphere, а также техник ранжирования памяти и ускорения (проект Peaberry).
В среднем снижение производительности составило около 10%, при этом примерно 40% виртуальной памяти было доступно через ускоритель Peaberry. Обратите внимание, что tiering полностью прозрачен для приложения, поэтому это работает для всех типов рабочих нагрузок. Важно понимать, что поскольку гипервизор уже отвечает за управление памятью, он знает, какие страницы являются "горячими", а какие "холодными", а это значит, что он может определить, какие страницы можно переместить на другой уровень, сохраняя при этом производительность.
В общем, ждем больше интересной информации от VMware на эту тему!
В своем финансовом отчете за второй квартал этого года компания Intel неожиданно объявила о том, что сворачивает (winding down) разработку технологии оперативной памяти Intel Optane. В свете падения квартальной выручки аж на 22% год к году, Intel просто не может поддерживать все перспективные технологии, требующие больших инвестиций в R&D.
Кстати, AMD во втором квартале этого года почти удвоила выручку (сказался еще эффект включения выручки приобретенной компании Xilinx):
Это оказалось, довольно-таки, неожиданной новостью для компании VMware, которая ориентировалась на поддержку этого типа памяти в своих продуктах, например, планируемом к выпуску решении Project Capitola. В данном продукте будет использоваться так называемая Software-Defined Memory, определяемая в облаке (неважно - публичном или онпремизном) на уровне кластеров VMware vSphere под управлением vCenter.
В Project Capitola вся доступная память серверов виртуализации в кластере агрегируется в единый пул памяти архитектуры non-uniform memory architecture (NUMA) и разбивается на ярусы (tiers), в зависимости от характеристик производительности, которые определяются категорией железа (price /performance points), предоставляющей ресурсы RAM. Все это позволяет динамически выделять память виртуальным машинам в рамках политик, созданных для соответствующих ярусов.
На рынке серверной виртуализации уже довольно давно развивается экосистема оперативной памяти различных уровней - стандартная DRAM, технология SCM (Optane и Z-SSD), модули памяти CXL, память PMEM, а также NVMe. Однако в разработке технологий по виртуализации оперативной памяти компания VMware ориентировалась, в первую очередь, именно на Intel Optane.
Память Intel Optane DC persistent memory (DCPMM она же PMEM) не такая быстрая как DRAM и имеет бОльшие задержки, но они все равно измеряются наносекундами. При этом данная память позволяет иметь ее большой объем на сервере, что существенно повышает плотность ВМ на одном хосте. В конце прошлого года мы писали о производительности этого типа памяти.
Теперь пользователи аппаратных устройств на базе Intel Optane продолжат получать стандартную поддержку Intel до окончания периода End-of-life, а также гарантию, действительную в течение 5 лет. Это касается следующих продуктовых линеек:
PMem 100 series ("Apache Pass")
PMem 200 series ("Barlow Pass")
DC P4800X SSD ("Cold Stream")
DC P5800X ("Alder Stream")
Также сообщается, что Intel продолжит развивать технологию PMem 300 series ("Crow Pass") для четвертого поколения процессоров Intel Xeon Scalable ("Sapphire Rapids").
VMware планирует продолжать поддержку памяти Intel Optane PMem в платформах vSphere 7.x и vSAN, а также будущих релизах этих продуктов. На данный момент память Optane поддерживается в трех режимах:
Обычная оперативная память (Memory mode)
App-Direct mode через механизм vPMem
Как персистентное хранилище через объекты vPMemDisk
VMware также добавила расширенные механизмы по поддержке vMMR в vSphere 7 Update 3 и добавила различные интеграции с механизмом DRS в следующей версии платформы. О технологии vMMR можно прочитать подробнее тут.
Также VMware поддерживает все предыдущие поколения технологии Intel Optane PMem, о чем можно почитать в KB 67645. Ну и VMware будет поддерживать будущее поколение Optane PMem 300, которое Intel, вроде как, не планирует сворачивать.
Ну а что касается Project Capitola, то VMware не будет поддерживать Intel Optane в этом решении, а переключится на технологии памяти стандарта CXL, который, как ожидается, получит большое распространение в отрасли. Посмотрим еще, что на эту тему еще расскажут на предстоящей конференции VMware Explore 2022.
На прошедшей онлайн-конференции VMworld 2021 компания VMware представила много новых интересных инициатив, продуктов и технологий. О некоторых из них мы уже рассказали в наших статьях:
Сегодня же мы поговорим о новом начинании VMware - Project Capitola. На рынке серверной виртуализации уже довольно давно развивается экосистема оперативной памяти различных уровней - стандартная DRAM, технология SCM (Optane и Z-SSD), модули памяти CXL, память PMEM, а также NVMe. По аналогии с сетевой инфраструктурой, где есть решение NSX для виртуализации и агрегации сетей, серверной инфраструктурой (где виртуализацией CPU занимается платформа vSphere) и инфраструктурой виртуализации хранилищ vSAN, компания VMware представила среду агрегации и виртуализации оперативной памяти - Project Capitola.
Это - так называемая Software-Defined Memory, определяемая в облаке (неважно - публичном или онпремизном) на уровне кластеров VMware vSphere под управлением vCenter:
Вся доступная память серверов виртуализации в кластере агрегируется в единый пул памяти архитектуры non-uniform memory architecture (NUMA) и разбивается на ярусы (tiers), в зависимости от характеристик производительности, которые определяются категорией железа (price /performance points), предоставляющей ресурсы RAM.
Все это позволяет динамически выделять память виртуальным машинам в рамках политик, созданных для соответствующих ярусов. Для Capitola обеспечивается поддержка большинства механизмов динамической оптимизации виртуального датацентра, таких как Distributed Resource Scheduler (DRS).
Вводить в эксплуатацию свои решения в рамках проекта Capitola компания VMware будет поэтапно: сначала появится управление памятью на уровне отдельных серверов ESXi, а потом уже на уровне кластера.
Очевидно, что такая технология требует поддержки на аппаратном уровне - и VMware уже заручилась поддержкой некоторых вендоров. В плане производителей памяти будет развиваться сотрудничество с Intel, Micron, Samsung, также будут интеграции с производителями серверов (например, Dell, HPE, Lenovo, Cisco), а также сервис-провайдерами (такими как Equinix).
Главная часть сотрудничества VMware - это взаимодействие с компанией Intel, которая предоставляет такие технологии, как Intel Optane PMem на платформах Intel Xeon.
Для получения подробностей смотрите следующие сессии с прошедшего VMworld 2021 (найти их можно тут):
[MCL2384] Big Memory – An Industry Perspective on Customer Pain Points and Potential Solutions
[MCL1453] Introducing VMware’s Project Capitola: Unbounding the "Memory Bound"
Ну а если вам хочется узнать больше о работе с памятью платформы vSphere в принципе, то есть еще и вот такие сессии:
How vSphere Will Redefine Infrastructure to Run Future Apps in the Multi-Cloud Era [MCL2500]
The Big Memory Transformation [VI2342]
Prepared for the New Memory Technology in Next Year’s Enterprise Servers? [VI2334]
Bring Intel PMem into the Mainstream with Memory Monitoring and Remediation [MCL3014S]
60 Minutes of Non-Uniform Memory Access (NUMA) 3rd Edition [MCL1853]
Chasing Down the Next Bottleneck – Accelerating Your Hybrid Cloud [MCL2857S]
Implementing HA for SAP HANA with PMem on vSphere 7.0U2 [VI2331]
5 Key Elements of an Effective Multi-Cloud Platform for Data and Analytics [MCL1594]
Будем держать вас в курсе о дальнейших анонсах инициативы Project Capitola компании VMware.
На сайте проекта VMware Labs появилось еще одно интересное средство Virtual Machine Desired State Configuration (VMDSC). Администраторам виртуальной инфраструктуры часто приходится менять параметры виртуальной машины, такие как CPU и память, чтобы проводить разного рода тюнинг и оптимизации. Для таких действий требуется перезагрузка виртуальной машины, что вызывает сложности в планировании.
Раньше подход был таким - к нужной дате/времени, согласованному с владельцами систем, происходила перезагрузка машин, которые за некоторое время уже поднимались в желаемой конфигурации (Desired State). Но это рождает довольно сложный административный процесс такого согласования.
Утилита VMDSC использует другой подход - виртуальные машины окажутся в Desired State при следующей перезагрузке гостевой ОС. Это позволяет не договариваться о простое ВМ в определенные периоды, а просто встраивать процесс реконфигурации процессора и памяти в жизненный цикл систем, когда им и так требуется перезагрузка (например, при накатывании обновлений).
Также в VMDSC встроена интеграция с vRealize Operations (vROPs), которая позволяет настраивать параметры ВМ на базе рекомендаций vROPs прямо из консоли этого решения:
Также массовую реконфигурацию ВМ можно проводить для отдельной папки, кластера или пула ресурсов.
Установка и развертывание утилиты состоит из нескольких несложных шагов:
Создаем служебный аккаунт VMDSC vCenter Service Account
Развертываем виртуальный модуль VMDSC в формате OVA
Используем Postman для настройки желаемых конфигураций ВМ (для этого нужно скачать и установить VMDSC Postman Collection)
Настроить интеграцию с vRealize Orchestrator и vRealize Operations
Для работы продукта понадобится vCenter 7 и новее, а также следующие разрешения сервисного аккаунта:
System.Read
System.View
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.PowerOn
VirtualMachine.Interact.Reset
VirtualMachine.Config.CPUCount
VirtualMachine.Config.Memory
VirtualMachine.Config.AdvancedConfig
VirtualMachine.Config.Settings
Sessions.ValidateSession
Ну и небольшое обзорное видео решения VMDSC:
Скачать Virtual Machine Desired State Configuration можно по этой ссылке.
Очередная интересная штука появилась на сайте проекта VMware Labs - утилита NUMA Observer, которая позволяет обнаружить виртуальные машины с перекрытием использования NUMA-узлов на хостах ESXi. При работе с тяжелыми нагрузками, требовательными к Latency, администраторы часто создают affinity-правила по привязке виртуальных машин к NUMA-узлам и ядрам CPU, чтобы они работали быстрее, с наименьшими задержками.
Но после сбоев и неполадок механизм VMware HA, восстанавливающий виртуальные машины на других хостах, может нарушить эту конфигурацию - там могут быть ВМ с уже привязанными NUMA-узлами, в результате чего возникнет перекрытие (overlap), которое полезно своевременно обнаружить.
С помощью NUMA Observer можно не только обнаруживать перекрытия по использованию ядер CPU и NUMA-узлов со стороны виртуальных машин, но и собирать статистики по использованию памяти дальнего узла и недостатке CPU-ресурсов (метрика CPU Ready). После анализа конфигураций и использования ресурсов, утилита генерирует алерты, которые администратор может использовать как исходные данные при настройке новой конфигурации NUMA-узлов.
Скачать NUMA Observer
можно по этой ссылке. После установки сервис доступен через веб-консоль по адресу localhost:8443. Для его работы потребуется Java 8.
На сайте проекта VMware Labs появилась новая версия утилиты Virtual Machine Compute Optimizer 3.0, о которой в последний раз мы писали летом 2019 года. С тех пор вышло несколько обновлений этого средства. Напомним, что VMCO - это PowerShell-сценарий для модуля PowerCLI VMware.VimAutomation.Core, который собирает информацию о хостах ESXi и виртуальных машинах в вашем виртуальном окружении и выдает отчет о том, правильно ли они сконфигурированы с точки зрения процессоров и памяти.
В третьей версии сценария появился рабочий процесс установки/апгрейда всех необходимых модулей - VMCO и PowerCLI. Теперь это единый сценарий, в котором есть мастер, проходящий по всем шагам установки модулей, соединения с vCenter и экспорта результатов.
Также в последних версиях была добавлена опция -simple, которая позволяет отобразить только информацию о виртуальных машинах (без серверов vCenter, кластеров и хостов ESXi), обновлена документация и исправлено много ошибок.
Скачивайте Virtual Machine Compute Optimizer 3.0 и выясняйте, правильно ли у вас настроены vCPU и Memory для виртуальных машин. Надо понимать, что VMCO анализирует вашу инфраструктуру только на базе рекомендаций для оптимальной конфигурации виртуальных машин без учета реальной нагрузки, которая исполняется внутри.
Как вы знаете, при обновлении виртуальной инфраструктуры в части хостов ESXi с помощью vSphere Lifecycle Manager (vLCM), в кластере HA/DRS хост переводится в режим обслуживания (Maintenance mode), который предполагает эвакуацию виртуальных машин на другие серверы с помощью vMotion. После обновления хоста он выводится из режима обслуживания, и виртуальные машины с помощью DRS постепенно возвращаются на него. В зависимости от характера нагрузки этот процесс может занять от нескольких минут до нескольких часов, что не всегда соответствует ожиданиям администраторов.
Второй вариант - потушить виртуальные машины, обновить ESXi, а потом включить его - тоже не подходит, так как приводит к длительным простоям сервисов виртуальных машин (нужно не только время на обновление хоста, но и время на выключение и включение ВМ, либо их небыстрый Suspend на диск).
Поэтому VMware придумала технологию Suspend-to-Memory, которая появилась в VMware vSphere 7 Update 2. Суть ее в том, что при обновлении ESXi его виртуальные машины приостанавливаются, сохраняя свое состояние (Suspend) в оперативной памяти. Очевидно, что в таком состоянии перезагружать хост нельзя, поэтому данная техника используется только совместно с ESXi Quick Boot, которая подразумевает обновление гипервизора без перезагрузки сервера.
Надо отметить, что функции Quick Boot доступны не для всех серверов. Более подробная информация по поддержке этой технологии со стороны серверных систем приведена в KB 52477, а вот ссылки на страницы вендоров серверного оборудования, где можно узнать детали поддержки этой технологии:
По умолчанию настройка кластера Cluster Remediation для виртуальных машин выставлена в значение "Do not change power state" для виртуальных машин, что подразумевает их vMotion на другие серверы, поэтому чтобы использовать Suspend to Memory, надо выставить "Suspend to memory", как на картинке выше.
При использовании такого типа обновления vLCM будет пытаться сделать Suspend виртуальных машин в память, а если этого не получится (например, недостаточно памяти), то он просто не будет переходить в режим обслуживания.
Надо сказать, что Suspend-to-Memory поддерживает vSAN и работает с такими продуктами, как vSphere Tanzu и NSX-T.
Ну и вот небольшое демо того, как это работает:
Таги: VMware, vSphere, Upgrade, Update, ESXi, VMachines, HA, DRS, Memory
Некоторое время назад мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).
Устройства HCA могут коммуницировать с памятью приложений на сервере напрямую. Грубо говоря, если в обычном режиме (TCP) коммуникация по сети происходит так:
То при наличии на обоих хостах HCA, обмен данными будет происходить вот так:
Очевидно, что такая схема не только снижает нагрузку на CPU систем, но и существенно уменьшает задержки (latency) ввиду обхода некоторых компонентов, для прохождения которых данными требуется время.
Поддержка RDMA появилась еще в VMware vSphere 6.5, когда для сетевых адаптеров PCIe с поддержкой этой технологии появилась возможность обмениваться данными памяти для виртуальных машин напрямую через RDMA API. Эта возможность получила название Paravirtual RDMA (PVRDMA).
Работает она только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Метод коммуникации между виртуальными машинами в таком случае выбирается по следующему сценарию:
Если две машины общаются между собой на одном ESXi, то используется техника memory copy для PVRDMA, что не требует наличия HCA-карточки на хосте, но сама коммуникация между ВМ идет напрямую.
Если машины находятся на хостах с HCA-адаптерами, которые подключены как аплинки к VDS, то коммуникация идет через PVRDMA-канал, минуя обработку на CPU хостов, что существенно повышает быстродействие.
Если в коммуникации есть хоть одна ВМ на хосте, где поддержки RDMA на уровне HCA нет, то коммуникация идет через стандартный TCP-туннель.
Начиная с VMware vSphere 7 Update 1, для PVRDMA была добавлена поддержка оконечных устройств с поддержкой RDMA (Native Endpoints), в частности хранилищ. Это позволяет передать хранилищу основной поток управляющих команд и команд доступа к данным от виртуальных машин напрямую, минуя процессоры серверов и ядро операционной системы. К сожалению для таких коммуникаций пока не поддерживается vMotion, но работа в этом направлении идет.
Чтобы у вас работала технология PVRDMA для Native Endpoints:
ESXi должен поддерживать пространство имен PVRDMA. Это значит, что аппаратная платформа должна гарантировать, что физический сетевой ресурс для виртуальной машины может быть выделен с тем же публичным идентификатором, что и был для нее на другом хосте (например, она поменяла размещение за счет vMotion или холодной миграции). Для этого обработка идентификаторов происходит на сетевых карточках, чтобы не было конфликтов в сети.
Гостевая ОС должна поддерживать RDMA namespaces
на уровне ядра (Linux kernel 5.5 и более поздние).
Виртуальная машина должна иметь версию VM Hardware 18
или более позднюю.
За счет PVRDMA для Native Endpoints виртуальные машины могут быстрее налаживать коммуникацию с хранилищами и снижать задержки в сети, что положительно сказывается на производительности как отдельных приложений и виртуальных машин, так и на работе виртуального датацентра в целом.
Напомним, что Intel Optane DC persistent memory (DCPMM) - эта память не такая быстрая как DRAM и имеет бОльшие задержки, но они все равно измеряются наносекундами. При этом данная память позволяет иметь ее большой объем на сервере, что существенно повышает плотность ВМ на одном хосте.
Модули DCPMM изготавливаются под разъем DDR4 и доступны планками по 128, 256 и 512 ГБ. В одной системе может быть до 6 ТБ памяти DCPMM. Платформа VMware vSphere 6.7 EP10 и более поздние версии поддерживают память Intel Optane persistent memory 100 series (она же Intel Optane PMem) со вторым поколением процессоров Intel Xeon Scalable в режимах App Direct и Memory.
В указанном документе рассматривается производительность данной памяти в новом режиме Balanced Profile для конфигурации BIOS, который впервые появился в процессорах Intel этой серии в целях повышения производительности. За счет данного режима производительность памяти увеличилась в 1.75 раза, как показано на картинке по результатам тестов:
В блоге VMware vSphere появилась интересная запись о том, как происходит работа с памятью в гипервизоре VMware ESXi. Приведем ее основные моменты ниже.
Работа виртуальной машины и ее приложений с памятью (RAM) идет через виртуальную память (Virtual Memory), которая транслируется в физическую память сервера (Physical Memory). Память разбита на страницы - это такие блоки, которыми виртуальная память отображается на физическую. Размер этого блока у разных систем бывает разный, но для ESXi стандартный размер страниц равен 4 КБ, а больших страниц - 2 МБ.
Для трансляции виртуальных адресов в физические используется таблица страниц (Page Table), содержащая записи PTE (Page Table Entries):
Записи PTE хранят в себе ссылки на реальные физические адреса и некоторые параметры страницы памяти (подробнее можно почитать здесь). Структуры записей PTE могут быть разного размера - это WORD (16 bits/2 bytes), DWORD (32 bits/4 bytes) и QWORD (64 bits/8 bytes). Они адресуют большие блоки адресов в физической памяти, к примеру, DWORD адресует блок адресов 4 килобайта (например, адреса от 4096 до 8191).
Память читается и передается гостевой системе и приложениям страницами по 4 КБ или 2 МБ - это позволяет читать содержимое ячеек памяти блоками, что существенно ускоряет быстродействие. Естественно, что при таком подходе есть фрагментация памяти - редко когда требуется записать целое число страниц, и часть памяти остается неиспользуемой. При увеличении размера страницы растет и их фрагментация, но увеличивается быстродействие.
Таблицы страниц (а их может быть несколько) управляются программным или аппаратным компонентом Memory Management Unit (MMU). В случае аппаратного MMU гипервизор передает функции по управлению трансляцией ему, а программный MMU реализован на уровне VMM (Virtual Machine Monitor, часть гипервизора ESXi):
Важный компонент MMU - это буфер ассоциативной трансляции (Translation Lookaside Buffer, TLB), который представляет собой кэш для MMU. TLB всегда находится как минимум в физической памяти, а для процессоров он часто реализован на уровне самого CPU, чтобы обращение к нему было максимально быстрым. Поэтому обычно время доступа к TLB на процессоре составляет около 10 наносекунд, в то время, как доступ к физической памяти составляет примерно 100 наносекунд. VMware vSphere поддерживает Hardware MMU Offload, то есть передачу функций управления памятью на сторону MMU физического процессора.
Итак, если от виртуальной машины появился запрос на доступ к виртуальному адресу 0x00004105, то этот адрес разбивается на адрес виртуальной страницы (Virtual page number - 0x0004) и смещение (Offset - 0x105 - область внутри страницы, к которой идет обращение):
Смещение напрямую передается при доступе к физической странице памяти, а вот тэг виртуальной страницы ищется в TLB. В данном случае в TLB есть запись, что соответствующий этому тэгу адрес физической страницы это 0x0007, соответственно трансляция виртуальной страницы в физическую прошла успешно. Это называется TLB Hit, то есть попадание в кэш.
Возможна и другая ситуация - при декомпозиции виртуального адреса получаемый тэг 0x0003 отсутствует в TLB. В этом случае происходит поиск страницы в физической памяти по тэгу (страницу номер 3) и уже ее адрес транслируется (0x006). Далее запись с этим тэгом добавляется в TLB (при этом старые записи из кэша вытесняются, если он заполнен):
Надо отметить, что такая операция вызывает несколько большую задержку (так как приходится искать в глобальной памяти), и такая ситуация называется TLB Miss, то есть промах TLB.
Но это не самая плохая ситуация, так как счет latency все равно идет на наносекунды. Но доступ может быть и гораздо более долгий (миллисекунды и даже секунды) в том случае, если нужная гостевой ОС страница засвопировалась на диск.
Посмотрим на пример:
Виртуальная машина обратилась к виртуальному адресу 0x00000460, для которого есть тэг 0x0000. В физической памяти для этого тэга выделена страница 0, которая означает, что искать эту страницу нужно на диске, куда страница была сброшена ввиду недостатка физической оперативной памяти.
В этом случае страница восстанавливается с диска в оперативную память (вытесняя самую старую по времени обращения страницу), ну и далее происходит трансляция адреса к этой странице. Эта ситуация называется отказ страницы (Page Fault), что приводит к задержкам в операциях приложения, поэтому иногда полезно отслеживать Page Faults отдельных процессов, чтобы понимать причину падения быстродействия при работе с памятью.
Продолжаем рассказывать (пока еще есть что!) о новых продуктах и технологиях, анонсированных на конференции VMworld 2019, которая закончилась уже почти 3 недели назад. Одна из самых интересных и перспективных технологий - это, конечно же, техника VMware Cluster Memory, которая действительно может поменять архитектуру датацентров в будущем.
Об этой технологии хорошо написал Дункан Эппинг. Как известно некоторым из вас, еще 20 лет назад скорость доступа к оперативной памяти серверов была примерно в 1000 раз выше, чем доступ к данным другого хоста по локальной сети. Шли годы, сетевой стек и оборудование улучшались - и в итоге на сегодняшний день доступ по сети всего в 10 раз медленнее, чем локальный доступ к RAM. Достигается это различными способами, в том числе технологией удалённого прямого доступа к памяти (remote direct memory access, RDMA).
Главное в этой эволюции то, что такие вещи как RDMA стали вполне доступными по цене, а значит можно обсуждать новые архитектуры на их основе. Тем более, что одной из основных проблем текущих датацентров стала трудность масштабирования инфраструктуры по памяти - ведь когда на одном из хостов не влезают виртуальные машины по RAM (например, есть машины с очень большим потреблением памяти), нужно увеличивать память и на всех остальных хостах кластера.
Поэтому VMware в рамках сессии VMworld "Big Memory with VMware Cluster Memory" рассказала о том, как можно строить кластеры с помощью так называемых "серверов памяти", которые обеспечивают работу хостов ESXi и их виртуальных машин, которым нужно дополнительное пространство памяти по требованию.
Кстати, еще есть и ограничение по объему DRAM на одном хосте - как правило, это несколькоТБ. Как мы видим на картинке выше, эту проблему можно решить созданием отдельных Memory-серверов в кластере, которые могут раздавать свою память по высокопроизводительной шине RDMA.
Технологии сетевого доступа к памяти будут развиваться, и скоро возможность использования виртуальными машинами страниц памяти с Memory-хостов будет вполне реальна:
Для этого компания VMware разработала отдельный paging-механизм, который позволяет проводить паджинацию страниц на удаленный сервер вместо локального диска, для чего будет необходим локальный кэш. При запросе страницы с удаленного сервера она сначала будет помещаться в локальный кэш для ускорения повторного использования.
Если страницы долгое время остаются невостребованными - они перемещаются обратно на Memory Server. По-сути, эта технология представляет собой оптимизацию механизма паджинации. В то же время, здесь пока существуют следующие проблемы:
Сбои, связанные с доступом к Cluster Memory
Безопасность и сохранность данных
Управление ресурсами в распределенной среде
Увеличение потребления межсерверного канала
Управление жизненным циклом страниц
Производительность механизма в целом
В рамках демо на VMworld 2019 была показана технология Cluster Memory в действии для виртуальной машины, использующей 3 ГБ такой памяти.
Конечно же, самая интересная проблема - это производительность ВМ в таких условиях. VMware сделала некоторые тесты, где были использованы различные соотношения локальной и удаленной памяти. На получившемся графике видна производительность в числе выполненных операций в минуту:
Обратите внимание, и это здесь четко видно, что Cluster Memory всегда работает быстрее, чем локальный SSD-Swap. Второй важный момент тут, что даже при 70% использовании удаленной памяти виртуальная машина, с точки зрения производительности, чувствует себя вполне хорошо.
Понятно, что технология VMware Cluster Memory еще дело будущего, но пока вы можете посмотреть интересную запись упомянутой сессии на VMworld.
Вчера мы писали об ограничениях технологии Persistent Memory в vSphere 6.7, которая еще только изучается пользователями виртуальных инфраструктур на предмет эксплуатации в производственной среде. Преимущество такой памяти - это, конечно же, ее быстродействие и энергонезависимость, что позволяет применять ее в высокопроизводительных вычислениях (High Performance Computing, HPC).
Ну а пока все это изучается, сейчас самое время для проведения всякого рода тестирований.
NVDIMM-N от компаний DELL EMC и HPE. NVDIMM-N - это такой тип устройств DIMM, который содержит модули DRAM и NANDflash на самом DIMM. Данные перемещаются между двумя этими модулями при запуске или выключении машины, а также во время внезапной потери питания (на этот случай есть батарейки на плате). На текущий момент есть модули 16 GB NVDIMM-Ns.
Intel Optane DC persistent memory (DCPMM) - эта память не такая быстрая как DRAM и имеет бОльшие задержки, но они измеряются наносекундами. Модули DCPMM изготавливаются под разъем DDR4 и доступны планками по 128, 256 и 512 ГБ. В одной системе может быть до 6 ТБ памяти DCPMM.
Для тестирования производительности такой памяти были использованы следующие конфигурации тестовой среды:
При тестировании производительности ввода-вывода были сделаны следующие заключения:
Накладные расходы на поддержку PMEM составляют менее 4%.
Конфигурация vPMEM-aware (когда приложение знает о vPMEM устройстве) может дать до 3x и более прироста пропускной способности в смешанном потоке чтения-записи в сравнении с традиционными устройствами vNVMe SSD (они использовались в качестве базового уровня).
Задержки (latency) на уровне приложений для конфигураций vPMEM составили менее 1 микросекунды.
Также тестировалась производительность баз данных Oracle, и там были сделаны такие выводы:
Улучшение на 28% в производительности приложения (количество транзакций HammerDB в минуту) с vPMEM по сравнению с vNVME SSD.
Увеличение 1.25x DB reads, 2.24x DB writes и до 16.6x в числе записей в DB log.
До 66 раз больше уменьшение задержек при выполнении операций в Oracle DB.
В MySQL тоже весьма существенное улучшение производительности:
Для PMEM-aware приложений тоже хорошие результаты:
Ну а остальные детали процесса проведения тестирования производительности устройств PMEM вы найдете в документе VMware.
В августе прошлого года мы сделали статью о новом виде памяти Persistent memory (PMEM) в VMware vSphere, которая находится на уровне между DRAM и Flash SSD с точки зрения производительности:
Надо сказать, что устройства с Persistent Memory (они же, например, девайсы с Intel Optane Memory) уже начинают рассматривать некоторые пользователи для внедрения в своей виртуальной инфраструктуре, поэтому надо помнить об их ограничениях, которые раскрыл Дункан Эппинг.
С точки зрения предоставления памяти PMEM виртуальной машине, на платформе vSphere есть 3 способа:
vPMEMDisk - vSphere представляет PMEM как обычный диск, подключенный к виртуальной машине через контроллер SCSI. В этом случае ничего не нужно менять для гостевой ОС или приложений. В таком режиме работают любые системы, включая старые ОС и приложения.
vPMEM - vSphere представляет PMEM как устройство NVDIMM для виртуальной машины. Большинство последних версий операционных систем (например, Windows Server 2016 и CentOS 7.4) поддерживают устройства NVDIMM и могут предоставлять их приложениям как блочные или байт-адресуемые устройства. Приложения могут использовать vPMEM как устройство хранения через тонкий слой файловой системы direct-access (DAX), либо замапить регион с устройства и получать к нему прямой доступ через байтовую адресацию. Такой режим может быть использован старыми или новыми приложениями, но работающими в новых версиях ОС, при этом версия Virtual Hardware должна быть не ниже 14.
vPMEM-aware - это то же самое, что и vPMEM, но только с дополнительными возможностями приложения понимать, что машина использует такое устройство, и пользоваться его преимуществами.
Если виртуальная машина использует такие устройства, то она имеет очень существенные ограничения, которые на данный момент препятствуют их использованию в производственной среде. Они приведены в документе "vSphere Resource Management Guide" на странице 47 внизу. А именно:
vSphere HA - полностью не поддерживается для машин с включенными vPMEM устройствами, вне зависимости от режима использования.
vSphere DRS - полностью не поддерживается для машин с включенными vPMEM устройствами (машины не включаются в рекомендации и не мигрируют через vMotion), вне зависимости от режима использования.
Миграция vMotion для машин с устройствами vPMEM / vPMEM-aware доступна только на хосты с устройствами PMEM.
Миграция vMotion машин с устройством vPMEMDISK возможна на хост без устройства PMEM.
Будем надеяться, что эта ситуация в будущем изменится.
Таги: VMware, vSphere, Memory, PMEM, Intel, VMachines, HA, DRS
В последней версии платформы виртуализации VMware vSphere 6.7 появилась новая возможность - поддержка Persistent Memory (PMEM). Это новый вид памяти, который покрывает разрыв между оперативной памятью (RAM) и дисковой памятью (Flash/SSD) с точки зрения быстродействия и энергонезависимости.
PMEM имеет 3 ключевые характеристики:
Параметры задержки (latency) и пропускной способности (bandwidth) как у памяти DRAM (то есть примерно в 100 быстрее, чем SSD).
Процессор может использовать стандартные байт-адресуемые инструкции для сохранения данных и их подгрузки.
Сохранение значений в памяти при перезагрузках и неожиданных падениях устройства хранения.
Таким образом, память PMEM находится в следующем положении относительно других видов памяти:
А ее характеристики соотносятся с SSD и DRAM памятью следующим образом:
Такие характеристики памяти очень подойдут для приложений, которым требуется сверхбыстродействие, при этом есть большая необходимость сохранять данные в случае сбоя. Это могут быть, например, высоконагруженные базы данных, системы тяжелой аналитики, приложения реального времени и т.п.
На данный момент vSphere 6.7 поддерживает 2 типа решений PMEM, присутствующих на рынке:
NVDIMM-N от компаний DELL EMC и HPE - это тип устройств DIMM, которые содержат как DRAM, так и модули NAND-flash на одной планке. Данные передаются между двумя модулями при загрузке, выключении или любом событии, связанном с потерей питания. Эти димы поддерживаются питанием с материнской платы на случай отказа. Сейчас обе компании HPE и DELL EMC поставлют модули 16 GB NVDIMM-N.
Модули Scalable PMEM от компании HPE (доступно, например, в серверах DL380 Gen10) - они позволяют комбинировать модули HPE SmartMemory DIMM с устройствами хранения NVMe (интерфейс Non-volatile Memory дисков SSD) и батареями, что позволяет создавать логические устройства хранения NVDIMM. Данные передаются между DIMMs и дисками NVMe. Эта технология может быть использована для создания систем с большим объемом памяти PMEM на борту.
При этом накладные затраты на использование виртуализации с устройствами PMEM не превышают 3%. Вот так выглядят примерные численные характеристики производительности памяти NVMe SSD и NVDIMM-N по сравнению с традиционными дисками:
С точки зрения предоставления памяти PMEM виртуальной машине, есть 2 способа в vSphere 6.7:
vPMEMDisk - vSphere представляет PMEM как обычный диск, подключенный к виртуальной машине через контроллер SCSI. В этом случае ничего не нужно менять для гостевой ОС или приложений. В таком режиме работают любые системы, включая старые ОС и приложения.
vPMEM - vSphere представляет PMEM как устройство NVDIMM для виртуальной машины. Большинство последних версий операционных систем (например, Windows Server 2016 и CentOS 7.4) поддерживают устройства NVDIMM и могут предоставлять их приложениям как блочные или байт-адресуемые устройства. Приложения могут использовать vPMEM как устройство хранения через тонкий слой файловой системы direct-access (DAX), либо замапить регион с устройства и получать к нему прямой доступ через байтовую адресацию. Такой режим может быть использован старыми или новыми приложениями, но работающими в новых версиях ОС, при этом версия Virtual Hardware должна быть не ниже 14.
Вот так это выглядит с точки зрения логики работы:
Если у вас хост VMware ESXi имеет на борту устройства с поддержкой PMEM, вы можете увидеть это в его свойствах в разделе Persistent Memory:
При создании новой виртуальной машины вы сможете выбрать, какое хранилище использовать для нее - стандартное или PMem:
Параметры диска на базе PMEM можно установить в разделе Customize hardware:
Также в свойствах виртуальной машины можно добавить новый жесткий диск в режиме vPMEMDisk:
Если же вы хотите добавить хранилище в режиме vPMEM, то надо указать соответствующий объем использования устройства в разделе New NVDIMM:
Надо отметить, что хранилище PMEM может быть на хосте ESXi только одно и содержит только устройства NVDIMM и виртуальные диски машин (то есть вы не сможете хранить там файлы vmx, log, iso и прочие). Для такого датастора единственное доступное действие - это просмотр статистик (при этом в vSphere Client на базе HTML5 датасторы PMEM вообще не видны). Вывести статистику по устройствам PMEM можно командой:
# esxcli storage filesystem list
Пример результатов вывода:
При включении ВМ, использующей PMEM, создается резервация этого устройства, которая сохраняется вне зависимости от состояния виртуальной машины (включена она или выключена). Резервация очищается при миграции или удалении ВМ.
Что касается миграции ВМ с устройством PMEM, то особенности этой миграции зависят от режима использования машиной устройства. Для миграции между хостами ESXi машины с PMEM включается не только vMotion, но и Storage vMotion, а на целевом хосте должно быть достаточно места для создания резервации от мигрируемой машины. При этом машину с хранилищем в режиме vPMEMDisk можно перенести на хост без устройства PMEM, а вот машину с vPMEM - уже нет.
В самом плохом случае при миграции ВМ с хранилищем NVMe SSD ее простой составит всего полсекунды:
Технологии VMware DRS и DPM (Distributed Power Management) полностью поддерживают память PMEM, при этом механизм DRS никогда не смигрирует машину, использующую PMEM на хосте, на сервер без устройства PMEM.
vPMEM-aware - это использование устройства PMEM гостевой ОС, которая умеет работать с модулем PMEM на хосте через прямой доступ к постоянной памяти устройства.
2. Бенчмарк FIO для пропускной способности (Throughput):
3. Бенчмарк HammerDB для Oracle, тестирование числа операций в секунду:
4. Тест Sysbench для базы данных MySQL, тестирование пропускной способности в транзакциях в секунду:
Еще несколько интересных графиков и тестовых кейсов вы можете найти в документе, ссылка на который приведена выше. Ну а больше технической информации о PMEM вы можете почерпнуть из этого видео:
Документация на тему использования Persistent Memory в VMware vSphere 6.7 доступна тут и тут.
У некоторых пользователей VMware vSphere при обновлении серверов VMware ESXi возникает проблема - при выполнении команды "esxcli software vib update" в ответ возникает ошибка "No space left on device", хотя с дисками все в порядке, и на них много свободного места, в чем можно убедиться с помощью команды df -h.
Например, появляется вот такой вывод при попытке обновления:
[InstallationError]
[Errno 28] No space left on device
vibs = VMware_bootbank_esx-base_6.5.0-1.41.7967591
Please refer to the log file for more details.
В то же время вывод df -h говорит, что места на всех разделах достаточно:
Очень редко причина такого поведения оказывается проста - на хосте не хватает файловых объектов inodes, как описано в KB 1007638. Это объекты файловой системы, которых может быть до 640 тысяч на одном томе VMFS. Их используемое количество зависит от числа файлов в файловой системе в данный момент.
Проверить наличие свободных inodes можно командой stat -f /:
На картинке мы видим, что запас их еще весьма большой - они почти не израсходованы. Как правило, указанного лимита достичь очень и очень сложно, поэтому чаще всего упомянутое выше сообщение об ошибке связано совсем с другим. Но если вы все же достигли этого лимита, решение тут несложное - удалить какое-то число файлов с ESXi.
Например, можно найти лог-файлы и прочие файлы на хосте ESXi размером более 50 МБ, которые находятся НЕ на томах VMFS (чтобы не задеть логи ВМ), можно следующей командой:
find / -path "/vmfs" -prune -o -type f -size +50000k -exec ls -l '{}' \;
По итогу будет сгенерирован список преимущественно локальных файлов, который будет содержать ISO-образы, большие лог-файлы и т.п., которые уже скорее всего не нужны, и их можно удалить (а лучше переместить на какое-нибудь хранилище в целях архивирования). Также рекомендуем почитать KB 1008643, которая как раз посвящена удалению файлов в целях высвобождения объектов inodes.
Между тем, в случае появления приведенной в начале статьи ошибки о недостатке свободного места очень вероятно, что хост ESXi не может аллоцировать достаточно оперативной памяти (RAM) для проведения обновления. В этом случае вам просто надо включить ESXi system swap, который будет размещен на одном из датасторов, куда будут сбрасываться страницы оперативной памяти при недостатке памяти во время обновления.
Сделать это можно, зайдя в раздел Manage > Settings > System Swap, после чего нажав Edit...:
Выберите датастор и нажмите Ok. Также это можно сделать с помощью функционала Host Profiles:
После выбора датастора для системного свопа обновите хост ESXi и перезагрузите его.
Как вы знаете, механизм динамической балансировки нагрузки VMware DRS используется для того, чтобы в условиях неравномерной нагрузки на хост-серверы VMware ESXi выравнивать ее за счет дачи рекомендаций по миграции виртуальных машин средствами vMotion на другие хосты, либо автоматического выполнения этих рекомендаций.
Давайте посмотрим как Distributed Resource Scheduler работает с оперативной памятью. В кластере DRS есть такая настройка "Memory Metric for Load Balancing", которая отключена по умолчанию, и если почитать к ней описание, то становится понятно, что DRS по умолчанию руководствуется параметром Active memory для балансировки.
У машины есть три основных параметра памяти, учитываемых DRS - это Active, Consumed и Configured Memory:
Configured - это память, указанная в настройках виртуальной машины, то есть ее максимальное значение.
Consumed - это память, которая использовалась виртуальной машиной с момента ее загрузки (а вы знаете, что при загрузке операционная система обращается к большему объему памяти, чем затем ее использует).
Active - это активные страницы памяти (RAM), которые сейчас используются гостевой ОС.
На картинке ниже показан пример - у машины 16 ГБ памяти, при этом при загрузке она наинициализировала страниц памяти на 12 ГБ, а активно использует только 5734 МБ.
Для того чтобы подчитывать используемую память, планировщик DRS подсчитывает working set из страниц Active Memory и прибавляет к нему 25% от разницы между Consumed и Active (это называется Idle Consumed Memory) на незапланированные резкие изменения нагрузки - и это число использует в своих вычислениях балансировки кластера:
В данном случае будет использоваться значение 5734+0,25*(12288-5734) = 7372,5 МБ (на картинке 7373 МБ). Кстати, это еще не все - к машине с памятью в 16 ГБ прибавляются накладные расходы (Overhead) в размере 90 МБ, поэтому DRS в своих вычислениях будет использовать значение 7373+90 = 7463 МБ.
Если же включить настройку DRS-кластера, упомянутую выше, то DRS в своих вычислениях будет использовать Consumed Memory и также прибавлять Memory Overhead:
В обновлении vSphere 6.5 update 1d клиент позволяет вам просматривать как метрику Active Memory, так и Consumed Memory.
Вот так выглядит картинка для сбалансированного кластера DRS (рекомендаций и ошибок нет):
Кстати, если вы посмотрите на Active Memory сбалансированного кластера, то там вполне может быть дисбаланс:
В этом нет ничего страшного, так как машины используют менее 20% active memory от памяти хоста, всем памяти хватает, и DRS решает, что балансировать машины в таком случае - это только тратить ресурсы CPU и сети на vMotion.
Переключимся теперь на Consumed memory:
Тут мы видим большой дисбаланс и разница между хостами более 20% от значений Consumed memory на них. Поэтому если мы включим настройку "Memory Metric for Load Balancing", то кластер DRS начнет работу по миграции виртуальных машин между хост-серверами. Итогом будет вот такая картина:
Вывод тут вот какой. Если у вас кластер работает без оверкомита (non-overcommitted) и есть большой запас по RAM на хостах, то, возможно, вам и следует поставить настройку "Memory Metric for Load Balancing", чтобы DRS балансировал хосты по consumed memory, а сами рекомендации по миграциям, например, можно применять в ручном режиме, чтобы контролировать ситуацию.
Автор известного технического блога о платформе VMware vSphere, Frank Denneman, совместно с одним из коллег выпустил весьма интересную книгу "vSphere 6.5 Host Resources Deep Dive".
В рамках 570-страничного талмуда авторы рассказывают все технические детали управления ресурсами на уровне хоста ESXi, такими как память, процессор, стек работы с хранилищами и сетевая архитектура. Довольно много содержимого книги посвящено архитектуре NUMA-узлов и оперативной памяти, механикам работы CPU и ядра VMkernel, а также прочим самым глубоким моментам программных и аппаратных компонентов хоста ESXi.
По уверению авторов книга покрывает, например, следующие технические вопросы:
Оптимизация рабочих нагрузок для систем Non-Uniform Memory Access (NUMA).
Объяснение того, как именно работает механика vSphere Balanced Power Management, чтобы получить преимущества функциональности CPU Turbo Boost.
Как настроить компоненты VMkernel для оптимизации производительности трафика VXLAN и окружений NFV.
В общем, книга очень крутая и мудрая. Скачать ее можно по этой ссылке.
Как вы знаете, VMware vCenter Server Appliance 6.5 (vCSA) постепенно становится главным инструментом управления виртуальной инфраструктурой, но пока еще не так распространился, как vCenter под Windows. В версии vCSA 6.5 произошло увеличение требований к оперативной памяти с 8 ГБ до 10 ГБ, что достаточно много, если говорить о тестовых окружениях, где, например, вы испытываете модуль vCSA.
Поэтому на сайте virten.net появилась небольшая инструкция по тому, как отключить ненужное на сервере vCSA, чтобы он стал потреблять меньше памяти.
В vCSA реализован динамический механизм управления памятью, который позволяет, исходя из текущей конфигурации модуля, производить выделение или урезание памяти его компонентам. С помощью команды cloudvm-ram-size можно посмотреть, сколько каждый компонент потребляет от текущей RAM сервера:
Нюанс здесь таков, что сервисы динамически масштабируются вверх и вниз по потреблению памяти, но нижней планкой всегда является отметка в 10 ГБ. Кстати, значения, до которых могут расти или падать потребления памяти сервисами vCSA, можно узнать в файле /etc/vmware/service-layout.mfx.
В итоге, единственный выход - это отключить ненужные в данный момент сервисы в тестовой среде. Вот эти вот сервисы позволят сэкономить вам 300 МБ памяти (напомним, что речь идет исключительно о небольшой тестовой среде, где они не будут востребованы):
Название сервиса
Размер в МБ
Назначение сервиса
vmware-rbd-watchdog
100
VMware vSphere Auto Deploy Waiter
vmware-mbcs
128
VMware Message Bus Configuration Service
vcha
46
VMware vCenter High Availability
vmware-netdumper
20
VMware vSphere ESXi Dump Collector
Вот эти сервисы можно отключить, если они вам не нужны, и они уже сэкономят больше памяти:
Название сервиса
Размер в МБ
Назначение сервиса
vmware-vsan-health
100
VMware VSAN Health Service
vmware-sps
478
VMware vSphere Profile-Driven Storage Service
vmware-perfcharts
357
VMware Performance Charts
vmware-content-library
473
VMware Content Library Service
vmware-updatemgr
164
VMware Update Manager
vsphere-ui
853
VMware vSphere Client (HTML5)
Обратите внимание, сколько памяти отъедает vSphere Client. Отключать вы его можете спокойно, если пользуетесь vSphere Web Client для управления виртуальной инфраструктурой.
Несколько пояснений к отключаемым сервисам:
VMware vSAN Health Service
Если вы не используете Virtual SAN, эту службу можно спокойно отключать. Об этом, кстати, написано в KB 2145308.
VMware vSphere Profile-Driven Storage Service
Этот сервис нужен только когда вы используете Virtual SAN, Virtual Volumes или другие сценарии управления хранилищем на базе политик.
Соответственно, тоже идет под нож.
VMware Performance Charts
Фича отображения графиков производительности будет отключена, как на картинке ниже, ведь зачем вам отслеживать производительность тестовой системы? В графиках производительности будет выводиться ошибка:
Кстати, графики в режиме Advanced продолжат работать.
VMware Content Library Service
Если вы не будете использовать библиотеку с контентом для VMware vSphere, то ее тоже нужно отключать. Также вы получите предупреждение на вкладке Summary для этого компонента:
VMware Update Manager
Ну и обновления вам, скорее всего, не пригодятся
для тестовой системы. Сам VUM выдаст вот такую ошибку:
VMware vSphere Client (HTML5)
Это самый жирный сервис. Если вы предпочитаете управлять инфраструктурой через Web Client - отключайте HTML5-модуль смело.
Как отключить ненужные сервисы?
Делается это в Administration > Deployment > System Configuration > Services. Там нужно выбрать нужный (а точнее ненужный) вам сервис и нажать "Stop":
Далее необходимо отключить автостарт этой службы в меню Actions > Edit Startup Type:
Ставим его в режим Manual (если нужно будет для каких-то целей - запустите руками):
Таким вот нехитрым образом можно освободить 3 ГБ памяти и продолжать "оптимизировать" ваш vCSA:
Название сервиса
Размер в МБ
Назначение сервиса
vmware-vsan-health
100
VMware VSAN Health Service
vmware-sps
478
VMware vSphere Profile-Driven Storage Service
vmware-perfcharts
357
VMware Performance Charts
vmware-content-library
473
VMware Content Library Service
vmware-updatemgr
164
VMware Update Manager
vsphere-ui
853
VMware vSphere Client (HTML5)
vmware-rbd-watchdog
100
VMware vSphere Auto Deploy Waiter
vmware-mbcs
128
VMware Message Bus Configuration Service
vcha
46
VMware vCenter High Availability
vmware-netdumper
20
VMware vSphere ESXi Dump Collector
TOTAL
2719
Над отключением приведенных служб вы еще можете поработать на свой страх и риск, чтобы еще больше срезать память у vCSA. Но учтите, что с какого момента все начнет тормозить:
Какое-то время назад мы писали о том, что технология дедупликации страниц памяти Transparent Page Sharing (TPS) с приходом больших страниц памяти становится ненужной (а в последних версиях vSphere и вовсе она отключена). Но это не значит, что сейчас TPS нигде не используется совсем - ведь большие страницы, при условии недостатка ресурсов памяти на хост-сервере, гипервизор ESXi может разламывать на маленькие, после чего дедуплицировать их.
Между тем, в последних релизах VMware vSphere, включая ESXi 6.0, появилась более гранулярная модель управления механизмом TPS, который можно задействовать для отдельных групп виртуальных машин (например, серверы обрабатывающие одни и те же данные, где вероятность дубликатов страниц высока). Называется этот механизм Salting (хэширование с солью).
Как известно, TPS производит хэширование страниц памяти виртуальных машин, после чего происходит сравнение хэшей на предмет их совпадения. Если они совпадают, то начинается побитовое сравнение этих страниц памяти, чтобы исключить ложное срабатывание дедупликации страниц (потому что, как известно, у двух разных исходных строчек теоретически может быть один хэш).
Если страницы полностью совпадают - вносятся изменения в таблицу страниц памяти, где для второй копии ставится просто ссылка на первую, а физически вторая копия страницы уничтожается.
При любой попытке записи в такую страницу со стороны виртуальной машины - мгновенно создается ее физическая копия с помощью механизма copy-on-write (CoW), и она уже перестает быть шаренной (каждая машина начинает использовать свою копию).
Так вот в последних версиях VMware vSphere механизм TPS работает не так просто. По умолчанию используется Salting, а в качестве этой самой соли используется UDID виртуальной машины, который всегда уникален для данного сервера vCenter. То есть перед снятием хэша со страницы памяти происходит добавление соли к исходным данным, а поскольку соль одинакова только для конкретной ВМ, то и дедупликация страниц со стороны TPS происходит только на уровне отдельной виртуальной машины (Intra-VM TPS).
Механизм Salting используется по умолчанию, начиная со следующих версий гипервизоров:
ESXi 5.0 Patch ESXi500-201502001
ESXi 5.1 Update 3
ESXi 5.5, Patch ESXi550-201501001
ESXi 6.0
Управлять этим механизмом можно из расширенных настроек хоста VMware ESXi (Advanced Settings, раздел Mem). По умолчанию используется расширенная настройка Mem.ShareForceSalting в значении 2. Это означает, что salting включен и работает Intra-VM TPS.
Если же мы поставим эту настройку в значение 0, как на рисунке выше, то соль перестанет добавляться к хэшу при работе алгоритма TPS, а значит он будет работать для всех виртуальных машин на хосте (Inter-VM TPS).
Ну и, как становится понятным, TPS можно включить для отдельной группы виртуальных машин на хосте ESXi, для чего нужно использовать одинаковую соль для этих виртуальных машин. Для этого в расширенных настройках виртуальной машины нужно добавить параметр sched.mem.pshare.salt с одинаковым значением у всех нужных вам ВМ (это также можно сделать и в vmx-файле).
В этом случае значением настройки Mem.ShareForceSalting должно быть 1 или 2 (разницы тут особой нет, кроме того, что если у вас используется значение 1, то при отсутствии соли включится Inter-VM sharing).
Ну и в таблице ниже приведем различия в работе алгоритма TPS для различных значений Mem.ShareForceSalting и в зависимости от заполненности sched.mem.pshare.salt для виртуальных машин.
Значение Mem. ShareForceSalting (настройка уровня хоста)
Значение sched.mem.pshare.salt (настройка уровня ВМ)
vc.uuid (свойство ВМ)
Значение соли в настройках ВМ
TPS между виртуальными машинами (Inter-VM)
TPS внутри каждой из ВМ (Intra-VM)
0
Игнорируется
Игнорируется
0
Да, между всеми машинами на хосте
Да
1
Установлено
Игнорируется
Используется sched.mem.pshare.salt
Только между ВМ с одинаковой солью
Да
1
Не установлено
Игнорируется
0
Да, между всеми машинами на хосте
Да
2
Установлено
Игнорируется
sched.mem.pshare.salt
Только между ВМ с одинаковой солью
Да
2
(по умолчанию)
Не установлено (по умолчанию)
Используется
Используется vc.uuid
No inter-VM TPS
Да
2
Не установлено
Отсутствует по какой-либо причине
Используется случайный номер для каждой ВМ
No inter-VM TPS
Да
Для более детальной информации вы можете обратиться к статье KB 2097593.
Мы уже немало писали про технологию Transparent Page Sharing (TPS) в VMware vSphere, которая позволяет дедуплицировать страницы оперативной памяти на хост-сервере ESXi при недостатке физической памяти для виртуальных машин. Как мы уже писали тут и тут, в VMware vSphere 5.5 Update 3 и более поздних версиях технология TPS отключена (при дедупликации страниц между машинами), чтобы не нагружать хост понапрасну, поскольку в современных ОС используются большие страницы памяти (Large Memory Pages), вероятность дедупликации которых мала. В то же время, технологию TPS никто из vSphere не убирал, и ее можно в любой момент включить.
Как пишет знаменитый Дункан, В VMware vSphere 5.x есть 4 состояния памяти для хост-сервера относительно параметра minFree:
High (100% от minFree)
Soft (64% от minFree)
Hard (32% от minFree)
Low (16% от minFree)
Эти состояния определяют срабатывание определенных триггеров (об этом ниже). Например, если minFree для вашей конфигурации сервера равно 10 ГБ, то при переходе в состояние, когда занято 6,4 ГБ (Soft), произойдет определенное действие с точки зрения техник оптимизации памяти.
В то же время, триггеры не срабатывают жестко по этим пороговым значениям, а плавно включаются перед ними и плавно выключаются за ними, чтобы не вызвать резких изменений.
Например, при переходе из состояния High в Soft, большие страницы памяти "разламываются" на обычные, чтобы TPS мог их тут же дедуплицировать. Однако, это может сказаться не лучшим образом на производительности - у хоста и так возникает недостаток памяти, а тут еще его нагружают дедупликацией.
Поэтому в VMware vSphere 6.0 ввели новое состояние Clear (100% от minFree), а состояние High переопределили до значения 400% от minFree. Для чего это сделано? А вот для чего.
При недостатке памяти, хостом ESXi используется техника разламывания больших страниц памяти на обычные страницы, которые затем могут быть дедуплицированы с помощью TPS. Это делается затем, чтобы предотвратить свопирование страниц на диск, что является самым тормозным способом освобождения ресурсов. Так вот эта штука начинает активно работать при наличии свободной памяти в промежутке от High (400%) до Clear (100%), чтобы начать работать на еще не испытывающем острого недостатка ресурсов хосте. Но при этом TPS сразу не запускается.
Давайте посмотрим на таблицу:
Состояние памяти (State)
Пороговое значение (% от minFree)
Эффект при переходе в диапазон
High
400%
Большие страницы разламываются на обычные, но TPS не запускается и ждет следующего цикла прохода дедупликации (по умолчанию 60 минут, минимально настраиваемое в расширенном параметре Mem.ShareScanTime время равно 10 минут)
Clear
100%
Разламывание больших страниц и мгновенный запуск TPS
Soft
64%
Включение TPS и техники Memory Ballooning
Hard
32%
Включение TPS, Memory Compression и свопирования на диск
Low
16%
Memory Compression + свопирование на диск + блокировка использования памяти
Это красивое решение - начать разламывать страницы заранее и не нагружать теряющий свободную память хост.
Но все что касается TPS, актуально только тогда, когда TPS включено. По умолчанию же эта техника выключена, а о том, как включить ее, написано вот тут.
RSS
