Оптимизация производительности на виртуальных машинах Linux серий Lsv3, Lasv3 и Lsv2

  • Статья

Внимание

Эта статья ссылается на CentOS, дистрибутив Linux, который приближается к состоянию конца жизни (EOL). Обратите внимание на использование и план соответствующим образом. Дополнительные сведения см. в руководстве centOS End Of Life.

Область применения: ✔️ Виртуальные машины Linux ✔️ Универсальные масштабируемые наборы

Виртуальные машины Azure серий Lsv3, Lasv3 и Lsv2 поддерживают разнообразные рабочие нагрузки, требующие высокой скорости ввода-вывода и пропускной способности локального хранилища для самых разных форм применения и отраслей. Серия L идеально подходит для больших данных, баз данных SQL и NoSQL, хранилищ и больших транзакционных баз данных, в том числе Cassandra, MongoDB, Cloudera и Redis.

Несколько сборок доступны на Azure Marketplace по причине работы с партнерами в Linux. Эти сборки оптимизированы для производительности серий Lsv3, Lasv3 и Lsv2. Доступные сборки включают следующие и более поздние версии:

  • Ubuntu 16.04
  • RHEL 8.0 и клоны, включая CentOS, Rocky Linux и Alma Linux
  • Debian 9
  • SUSE Linux 15
  • Oracle Linux 8.0

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

Архитектура микросхем AMD EPYC™

Виртуальные машины серии Lasv3 и Lsv2 используют серверные процессоры AMD EYPC™ на основе микроархитектуры Zen. Платформа AMD разработала Infinity Fabric (IF) для EYPC™ в качестве масштабируемого соединения для своей модели NUMA, которая может использоваться для коммуникаций на кристалле, в пакете и в нескольких пакетах. По сравнению с QPI (Quick-Path Interconnect) и UPI (Ultra-Path Interconnect), которые используются в современных процессорах Intel с монолитным кристаллом, архитектура AMD с маленькими кристаллами и множеством NUMA может повысить производительность, но имеет определенные недостатки. Фактическое влияние ограничений пропускной способности памяти и задержки может различаться в зависимости от типа выполняемых рабочих нагрузок.

Рекомендации по повышению производительности

  • Если вы загружаете настраиваемую гостевую ОС Linux для рабочей нагрузки, функция ускорения сети будет по умолчанию отключена. Если вы планируете включить функцию ускорения сети, для максимальной производительности включите ее во время создания виртуальной машины.
  • Чтобы получить максимальную производительность, запустите несколько заданий с глубиной очереди на устройство.
  • Старайтесь не смешивать команды администрирования NVMe (например, запрос информации NVMe SMART и т. д.) с командами ввода-вывода NVMe во время активных рабочих нагрузок. Устройства NVMe серий Lsv3, Lasv3, и Lsv2 поддерживаются технологией Hyper-V NVMe Direct, которая переключается в режим медленной работы каждый раз, когда команды администрирования NVMe ожидают выполнения. В таких случаях пользователи Lsv3, Lasv3, и Lsv2 могут заметить значительное снижение производительности операций ввода-вывода NVMe.
  • Пользователям Lsv2 не рекомендуется полагаться на сведения NUMA устройства (все 0), полученные от виртуальной машины о дисках данных, чтобы принять решение о сходстве NUMA для приложений. Для повышения производительности рекомендуется распределить рабочие нагрузки между процессорами, если это возможно.
  • Максимальная поддерживаемая глубина очереди в паре очередей ввода-вывода для устройства NVMe на виртуальной машине серий Lsv3, Lasv3 и Lsv2 — 1024. Пользователям Lsv3, Lasv3, и Lsv2 рекомендуется ограничить свои (искусственные) рабочие нагрузки сравнения производительности до глубины 1024 или менее, чтобы избежать запуска события полной очереди, что может снизить производительность.
  • Максимальная производительность достигается, когда операции ввода-вывода выполняются непосредственно на каждом из необработанных устройств NVMe без секционирования, без файловых систем, без конфигурации RAID и т.п. Перед началом тестового сеанса убедитесь, что конфигурация находится в новом/чистом состоянии, выполнив blkdiscard на каждом устройстве NVMe. Чтобы получить наиболее согласованную производительность во время тестирования, рекомендуется предупредить устройства NVMe перед тестированием путем выдачи случайных операций записи на все сетевые подсистемы балансировки нагрузки устройств дважды, как определено в спецификации SNIA Solid State служба хранилища Enterprise Performance Test.

Использование локального хранилища NVMe

Локальное хранилище на диске NVMe 1,92 ТБ на всех виртуальных машинах Lsv3, Lasv3 и Lsv2 является эфемерным. Во время стандартной корректной перезагрузки виртуальной машины данные на локальном диске NVMe сохраняются. Данные не сохраняются в NVMe, если виртуальная машина повторно развернута, освобождена или удалена. Данные не сохраняются в случае неработоспособности виртуальной машины или оборудования, на котором она запущена, по другим причинам. В этом сценарии любые данные на старом узле будут безопасно удалены.

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

Если запланированное событие обслуживания требует повторного создания виртуальной машины на новом узле с пустыми локальными дисками, необходимо повторно синхронизировать данные (при этом любые данные на старом узле также будут безопасно удалены). Этот сценарий происходит потому, что виртуальные машины серий Lsv3, Lasv3 и Lsv2 в настоящее время не поддерживают динамическую миграцию на локальном диске NVMe.

Существует два режима планового обслуживания.

Стандартное обслуживание виртуальной машины, контролируемое клиентом

  • Виртуальная машина перемещается на обновленный узел в течение 30-дневного периода.
  • Данные локального хранилища Lsv3, Lasv3 и Lsv2 могут быть потеряны, поэтому рекомендуется выполнять резервное копирование данных до события.

Автоматическое обслуживание

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

Для всех ближайших событий обслуживания используйте контролируемый процесс, чтобы выбрать наиболее удобное для обновления время. Перед событием создайте резервные копии данных в хранилище класса "Премиум". После события обслуживания можно вернуть данные в обновленное локальное хранилище NVMe на виртуальных машинах Lsv3, Lasv3 и Lsv2.

Ниже перечислены сценарии хранения данных на локальных дисках NVMe:

  • Виртуальная машина работает и работоспособна.
  • Виртуальная машина перезагружается на месте (вами или Azure).
  • Виртуальная машина приостановлена (остановлена без отмены выделения).
  • Большая часть операций планового обслуживания.

Ниже перечислены сценарии безопасного удаления данных для защиты клиента.

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

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

Ниже приведен список вопросов и ответов о данных сериях.

Как начать развертывание виртуальных машин серии L?

Как и для любой другой виртуальной машины, используйте Портал, Azure CLI или PowerShell.

Приводит ли сбой одного диска NVMe к сбою всех виртуальных машин на узле?

Если на узле оборудования обнаружен сбой диска, оборудование не работает. В случае возникновения такой проблемы все виртуальные машины на узле автоматически завершают общение и перемещаются на работоспособный узел. Для виртуальных машин серий Lsv3, Lasv3 и Lsv2 эта проблема означает, что данные клиента на узле со сбоем также безопасно удаляются. Клиенту придется воссоздать данные на новом узле.

Нужно ли изменять параметры blk_mq?

RHEL/CentOS 7.x автоматически использует параметр blk-mq для устройств NVMe. Изменения в конфигурации и параметрах не требуются.

Следующие шаги

См. спецификации для всех виртуальных машин, оптимизированных для производительности хранилища, в Azure.