Премиальное хранилище Azure: Проектирование для высокой производительности

Применимо к: ✔️ Виртуальные машины Linux ✔️ Виртуальные машины Windows ✔️ Гибкие группы масштабирования ✔️ Унифицированные группы масштабирования

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

Хотя мы рассмотрим сценарии производительности для уровня хранилища в этой статье, необходимо оптимизировать уровень приложения. Например, если вы размещаете SharePoint Farm на премиум-хранилище, вы можете использовать примеры SQL Server из этой статьи для оптимизации сервера базы данных. Вы также можете оптимизировать веб-сервер и сервер приложений SharePoint Farm, чтобы получить максимальную производительность.

Эта статья поможет ответить на следующие распространенные вопросы о оптимизации производительности приложений в хранилище класса Premium:

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

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

Прежде чем начать, если вы новичок в премиум-хранилище, сначала прочитайте Выбор типа диска Azure для виртуальных машин IaaS и Цели масштабируемости для учетных записей премиум-хранилища страничных блобов.

Показатели производительности приложения

Мы оцениваем, насколько хорошо приложение работает, используя такие показатели производительности, как:

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

Технические термины для этих показателей производительности — это IOPS (операции ввода-вывода в секунду), пропускная способность и задержка.

В этом разделе мы обсуждаем общие показатели производительности в контексте премиум-хранилища. В разделе Performance application checklist for disks вы узнаете, как измерить эти показатели производительности для вашего приложения. Позже в Оптимизация производительности приложений вы узнаете о факторах, влияющих на эти показатели производительности, и рекомендации по их оптимизации.

IOPS (Операции ввода-вывода в секунду)

IOPS — это количество запросов, которые ваше приложение отправляет на дисковые накопители за одну секунду. Операция ввода/вывода может быть чтением или записью, последовательной или случайной. Приложения обработки транзакций в режиме онлайн (OLTP), такие как сайт интернет-розничной торговли, должны обрабатывать множество одновременных пользовательских запросов немедленно. Запросы пользователей являются транзакциями базы данных, интенсивно использующими операции вставки и обновления, которые приложение должно обрабатывать быстро. По этой причине приложения OLTP требуют очень высокой производительности ввода-вывода операций в секунду (IOPS).

Приложения OLTP обрабатывают миллионы небольших и случайных запросов ввода-вывода. Если у вас есть такое приложение, вам необходимо разработать инфраструктуру приложения для оптимизации под IOPS. Для получения дополнительной информации о факторах, которые следует учитывать для достижения высоких IOPS, см. Оптимизация производительности приложений.

Когда вы подключаете диск премиум-хранилища к вашей высокомасштабируемой виртуальной машине, Azure предоставляет вам гарантированное количество IOPS в соответствии со спецификацией диска. Например, диск P50 предоставляет 7,500 IOPS. Каждый размер ВМ с высокой масштабируемостью также имеет определенный предел IOPS, который он может поддерживать. Например, стандартная виртуальная машина GS5 имеет ограничение в 80,000 IOPS.

Пропускная способность

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

Когда вы подключаете диск премиум-класса к виртуальной машине с высокой масштабируемостью, Azure обеспечивает пропускную способность в соответствии с характеристиками этого диска. Например, диск P50 обеспечивает пропускную способность 250 МБ/сек. Каждый размер высокомасштабируемой виртуальной машины имеет также конкретное ограничение пропускной способности, которое она может поддерживать. Стандартная GS5 ВМ обладает максимальной пропускной способностью 2,000 МБ/сек.

Между пропускной способностью и IOPS существует связь, как показано в следующей формуле.

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

Задержка

Задержка — это время, необходимое приложению для получения единичного запроса, отправки его на диски хранения и отправки ответа клиенту. Задержка является критической мерой производительности приложения в дополнение к IOPS и пропускной способности. Задержка диска хранилища уровня "Премиум" — это время, необходимое для получения сведений о запросе и обратного обмена данными с приложением. Премиум-хранилище обеспечивает стабильно низкую задержку. Премиальные диски разработаны для обеспечения задержки, измеряемой одноцифровыми миллисекундами, для большинства операций ввода-вывода. Если включить ReadOnly кэширование на хосте на премиальных дисках хранения данных, вы можете значительно снизить задержку при чтении. Для получения дополнительной информации о кэшировании диска см. Кэширование диска.

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

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

Во время фонового копирования нет влияния на задержку записи для большинства типов дисков. Для Premium SSD v2 и Ultra Disks, если диск имеет размер сектора 4K, он испытывает более высокую задержку чтения. Если диск имеет размер сектора 512e, он испытывает более высокую задержку чтения и записи.

Следующие операции плоскости управления могут перемещать диск между расположениями хранилища и вызывать повышенную задержку:

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

Список проверки производительности приложений для дисков

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

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

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

Например, обычная рабочая нагрузка веб-сайта электронной коммерции — это транзакции, которые она обслуживает в течение большинства дней в год. Максимальная нагрузка на веб-сайт приходится на транзакции, которые он обслуживает в праздничные сезоны или во время специальных распродаж. Пиковая нагрузка обычно наблюдается в течение ограниченного периода, но может потребовать, чтобы ваше приложение масштабировалось в два или более раз относительно своей нормальной работы. Узнайте требования для 50-го, 90-го и 99-го перцентилей. Эта информация помогает отфильтровать любые выбросы в требованиях к производительности, и вы можете сосредоточить свои усилия на оптимизации нужных значений.

Контрольный список требований к производительности приложения

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

Счетчики для измерения требований к производительности приложения

Наилучший способ определить требования к производительности вашего приложения — использовать инструменты мониторинга PerfMon, предоставляемые операционной системой сервера. Вы можете использовать PerfMon для Windows и iostat для Linux. Эти инструменты фиксируют счётчики, соответствующие каждой метрике, объяснённой в предыдущем разделе. Вы должны фиксировать значения этих счетчиков, когда ваше приложение работает в нормальном, пиковом и непиковом режимах нагрузки.

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

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

Узнайте больше о iostat и PerfMon.

Оптимизируйте производительность приложения

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

Большинство приложений могут не предоставить вам возможность изменять размер ввода/вывода и глубину очереди напрямую. Например, если вы используете сервер SQL, вы не можете выбрать размер I/O и глубину очереди. SQL Server выбирает оптимальные значения размера I/O и глубины очереди для достижения максимальной производительности. Важно понимать влияние обоих типов факторов на производительность вашего приложения, чтобы вы могли обеспечить соответствующие ресурсы для удовлетворения потребностей в производительности.

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

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

Оптимизируйте IOPS, пропускную способность и задержку с одного взгляда

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

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

Характер запросов ввода-вывода

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

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

Некоторые приложения позволяют изменять размер их ввода/вывода, в то время как другие - нет. Например, SQL Server самостоятельно определяет оптимальный размер I/O и не предоставляет пользователям возможность его изменить. С другой стороны, Oracle предоставляет параметр под названием DB_BLOCK_SIZE, который можно использовать для настройки размера I/O-запросов базы данных.

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

• Приложение OLTP генерирует миллионы маленьких и случайных запросов ввода-вывода. Чтобы обрабатывать такие запросы ввода-вывода, вы должны спроектировать инфраструктуру вашего приложения для получения более высокой производительности IOPS.
• Приложение для хранения данных создаёт крупные и последовательные запросы ввода-вывода. Чтобы обрабатывать эти типы запросов ввода-вывода, необходимо разработать инфраструктуру приложений таким образом, чтобы получить более высокую пропускную способность или производительность.

Если вы используете приложение, которое позволяет изменить размер ввода/вывода (I/O), используйте это практическое правило для размера ввода/вывода в дополнение к другим рекомендациям по производительности.

• Меньший размер I/O для получения большей производительности IOPS. Например, 8 КБ для OLTP-приложения.
• Более крупный размер ввода-вывода для получения более высокой пропускной способности. Например, 1,024 КБ для приложения хранилища данных.

Вот пример того, как вы можете рассчитать IOPS и пропускную способность/ширину канала для вашего приложения.

Рассмотрим приложение, использующее диск P30. Максимальное количество операций ввода-вывода в секунду и пропускная способность диска P30 составляет 5000 операций ввода-вывода в секунду и 200 МБ/с соответственно. Если вашему приложению требуется максимальное количество IOPS от диска P30, и вы используете меньший размер ввода-вывода, например, 8 КБ, то получаемая пропускная способность составит 40 МБ/с. Если вашему приложению требуется максимальная пропускная способность от диска P30, и вы используете больший размер ввода-вывода, например, 1,024 КБ, то получаемое количество IOPS будет меньше, например, 200 IOPS.

Настройте размер I/O таким образом, чтобы он соответствовал как требованиям IOPS вашего приложения, так и потребностям по пропускной способности. Следующая таблица суммирует различные размеры ввода/вывода и их соответствующие показатели IOPS и пропускной способности для диска P30.

Чтобы получить показатели IOPS и пропускной способности выше максимального значения одного премиального диска хранения, используйте несколько премиальных дисков, объединённых в массив. Например, объедините два диска P30 в RAID-массив, чтобы получить суммарную производительность IOPS в размере 10 000 операций в секунду или суммарную пропускную способность равную 400 МБ/сек. Как объясняется в следующем разделе, необходимо использовать размер виртуальной машины, который поддерживает суммарные показатели IOPS и пропускной способности дисков.

Чтобы увидеть влияние размера ввода/вывода (I/O) на производительность приложения, вы можете запустить инструменты для бенчмаркинга на вашей виртуальной машине и дисках. Создайте несколько испытательных запусков и используйте разные размеры ввода/вывода для каждого запуска, чтобы увидеть эффект. Для дополнительной информации см. статьи о сравнительном анализе в конце этого документа.

Размеры виртуальных машин высокой мощности

Когда вы начинаете проектировать приложение, одной из первых задач является выбор виртуальной машины для размещения вашего приложения. Премиум-хранилище предоставляет крупные виртуальные машины, которые могут запускать приложения, требующие большей вычислительной мощности и высокой производительности локального диска для ввода-вывода. Эти виртуальные машины предоставляют более быстрые процессоры, более высокий коэффициент памяти на ядро и твердотельный накопитель (SSD) для локального диска. Примеры высокопроизводительных виртуальных машин с поддержкой премиум-хранилища — это виртуальные машины серий DS и GS.

Виртуальные машины высокого уровня доступны в различных размерах с разным количеством ядер процессора, памяти, операционной системы и временного диска. Каждый размер виртуальной машины (VM) также имеет максимальное количество дисков данных, которые можно подключить к виртуальной машине (VM). Выбранный размер виртуальной машины влияет на доступную обработку, объем памяти и емкость хранения для вашего приложения. Это также влияет на стоимость вычислений и хранения. Например, следующие характеристики относятся к наибольшему размеру виртуальной машины в серии DS и серии GS.

Чтобы просмотреть полный список всех доступных размеров виртуальных машин Azure, перейдите к Размеры для виртуальных машин в Azure. Выберите размер виртуальной машины (VM), который сможет удовлетворить ваши требования к производительности приложений и масштабироваться в соответствии с ними. Также учитывайте следующие важные соображения при выборе размеров виртуальных машин.

Ограничения масштабирования

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

Например, предположим, что требование к приложению — максимум 4000 IOPS. Чтобы достичь этого уровня, создайте диск P30 на виртуальной машине DS1. Диск P30 может обеспечивать до 5,000 IOPS. Однако DS1 VM ограничена 3,200 IOPS. Производительность приложения ограничена лимитом виртуальной машины в 3,200 IOPS, и производительность ухудшается. Чтобы предотвратить эту ситуацию, выберите размеры ВМ и диска, которые оба соответствуют требованиям приложения.

Стоимость эксплуатации

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

Например, рассмотрим приложение, требующее 16 000 операций ввода-вывода в секунду (IOPS). Чтобы достичь этой производительности, вам нужна виртуальная машина Azure IaaS Standard_D14, которая может выдать максимум 16 000 IOPS, используя 32 стандартных диска с хранилищем объемом 1 ТБ. Каждый стандартный диск хранилища объемом 1 ТБ способен достигать максимум 500 IOPS.

• Оценочная стоимость этой виртуальной машины в месяц составляет $1,570.
• Ежемесячная стоимость 32 стандартных дисков для хранения составляет $1,638.
• Ориентировочная общая ежемесячная стоимость составляет 3 208 $.

Если вы размещали то же приложение в хранилище класса Premium, вам потребуется меньший размер виртуальной машины и меньше дисков хранилища класса Premium, что снижает общую стоимость. Виртуальная машина Standard_DS13 может удовлетворить требования к 16,000 IOPS, используя четыре диска P30. Виртуальная машина DS13 имеет максимальную производительность ввода/вывода (IOPS) 25,600, а каждый диск P30 - максимальную производительность ввода/вывода (IOPS) 5,000. В целом, данная конфигурация может достигать 5,000 x 4 = 20,000 IOPS.

• Ожидаемая стоимость этой виртуальной машины в месяц составляет 1,003 доллара.
• Ежемесячная стоимость четырех премиальных дисков хранения P30 составляет $544.34.
• Оценочная общая ежемесячная стоимость составляет 1 544 доллара.

Следующая таблица суммирует распределение затрат этого сценария для стандартного и премиального хранилища.

дистрибутивы Linux

С использованием премиум-хранилища вы получаете такой же уровень производительности для виртуальных машин (ВМ), работающих на Windows и Linux. Мы поддерживаем множество разновидностей дистрибутивов Linux. Для получения дополнительной информации смотрите дистрибутивы Linux, одобренные в Azure.

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

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

Размеры дисков премиум-хранилища

Хранилище класса "Премиум" предлагает различные размеры, чтобы выбрать наиболее подходящий для ваших потребностей. Размер каждого диска имеет разные ограничения для IOPS, пропускной способности и хранения. Выберите подходящий размер диска с премиальной памятью в зависимости от требований приложения и размера высокопроизводительной виртуальной машины. Следующая таблица показывает размеры дисков и их возможности. В настоящее время размеры P4, P6, P15, P60, P70 и P80 поддерживаются только для управляемых дисков.

*Применяется только к дискам с включенной функцией bursting по требованию.
** Применяется только к дискам с функцией «Performance Plus».

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

Ограничения масштаба (IOPS и пропускная способность)

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

Например, если требование приложения — максимальная пропускная способность в 250 МБ/с, и вы используете виртуальную машину DS4 с одним диском P30, то виртуальная машина DS4 может обеспечить пропускную способность до 256 МБ/с. Однако у одного диска P30 есть ограничение пропускной способности в 200 МБ/сек. Таким образом, приложение ограничено до 200 МБ/сек из-за лимита диска. Чтобы преодолеть это ограничение, добавьте еще один диск данных на виртуальную машину или измените размер дисков на P40 или P50.

Число дисков

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

Помните, что премиум-диски для хранения данных обладают более высокими рабочими характеристиками по сравнению с стандартными дисками для хранения данных. Если вы переносите своё приложение с виртуальной машины Azure IaaS, использующей стандартное хранилище, на премиум-хранилище, вам, вероятно, потребуется меньше премиум-дисков, чтобы достичь той же или более высокой производительности для вашего приложения.

Кэширование дисков

Виртуальные машины высокого масштаба, использующие премиум-хранилище, имеют многоуровневую технологию кэширования под названием BlobCache. BlobCache использует комбинацию оперативной памяти хоста и локального SSD для кэширования. Этот кэш доступен для управляемых дисков Standard HDD, Standard SSD и Premium SSD. По умолчанию этот параметр кэша установлен на ReadWrite для дисков ОС и ReadOnly для дисков данных. Включив кеширование дисков, виртуальные машины с высокой масштабируемостью могут достигать чрезвычайно высоких уровней производительности, превосходящих производительность самих дисков.

Чтобы узнать больше о том, как работает BlobCache, ознакомьтесь с записью в блоге «Внутри Azure premium storage».

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

Вы должны использовать следующие настройки кэша диска для дисков данных:

ReadOnly

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

1. Чтение из кэша, который находится в памяти ВМ и на локальном SSD, происходит быстрее, чем чтение с дискового пространства данных, расположенного на Azure Blob Storage.
2. Хранение не учитывает количество операций чтения, выполненных из кэша, в отношении ввода-вывода диска (IOPS) и пропускной способности. По этой причине ваше приложение может достигать более высоких общих IOPS и пропускной способности.

ЧтениеЗапись

По умолчанию на дисках ОС включено кэширование ReadWrite. Мы недавно добавили поддержку кэширования ReadWrite и на дисках данных. Если вы используете кэширование ReadWrite, у вас должен быть правильный способ записи данных из кэша на постоянные диски. Например, SQL Server самостоятельно обрабатывает запись кешированных данных на постоянные дисковые хранилища. Использование кеша ReadWrite с приложением, которое не обрабатывает сохранение необходимых данных, может привести к потере данных, если виртуальная машина выйдет из строя.

Отсутствует

В настоящее время None поддерживается только для дисков с данными. Это не поддерживается на дисках ОС. Если вы установите None на диске операционной системы, это переопределяет эту настройку и устанавливает её на ReadOnly.

Например, эти рекомендации можно применить к SQL Server, работающему на виртуальных машинах с поддержкой хранилища класса "Премиум", выполнив следующие действия.

1. Настройте кэш ReadOnly на стандартных HDD, стандартных SSD или премиум SSD дисках с управляемыми данными.
   1. Быстрое чтение из кэша снижает время выполнения запросов в SQL Server, потому что страницы данных извлекаются из кэша быстрее, чем напрямую с дисков.
   2. Обслуживание чтения из кэша означает, что дисковые накопители могут обеспечить большую пропускную способность. SQL Server может использовать эту дополнительную пропускную способность для извлечения большего количества страниц данных и других операций, таких как резервное копирование/восстановление, пакетная загрузка и перестроение индексов.
2. Настройте кеш None на премиум-дисках хранения, содержащих журнальные файлы.
   1. Логи содержат главным образом записи операций, поэтому они не получают выгоду от кэша ReadOnly.

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

Для всех Premium SSD или Ultra Disks, вы можете отключить барьеры для файловых систем на диске, чтобы улучшить производительность, если известно, что нет кэшей, которые могут потерять данные. Если кэширование диска Azure установлено на ReadOnly или None, вы можете отключить барьеры. Но если кэширование установлено на ReadWrite, барьеры должны оставаться включенными для обеспечения долговечности записи. Барьеры обычно включены по умолчанию, но вы можете отключить их, воспользовавшись одним из следующих методов в зависимости от типа файловой системы.

• reiserFS: Используйте параметр монтирования barrier=none, чтобы отключить барьеры. Чтобы явно включить барьеры, используйте barrier=flush.
• ext3/ext4: Используйте параметр монтирования barrier=0, чтобы отключить барьеры. Чтобы явно включить барьеры, используйте barrier=1.
• XFS: Используйте параметр монтирования nobarrier, чтобы отключить барьеры. Чтобы явно включить барьеры, используйте barrier. Начиная с версии 4.10 основного ядра Linux, дизайн файловой системы XFS всегда обеспечивает надежность. Отключение барьеров не имеет эффекта, и параметр nobarrier устарел. Однако некоторые дистрибутивы Linux могли перенести изменения в выпуск дистрибутива с более ранней версией ядра. Проверьте у вашего поставщика дистрибутива статус в дистрибутиве и версии, которые вы используете.

Полосность дисков

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

В Windows можно использовать технологию Storage Spaces, чтобы объединять диски в массивы. Необходимо настроить один столбец для каждого диска в пуле. В противном случае общая производительность полосатого тома может быть ниже ожидаемой из-за неравномерного распределения трафика по дискам.

Используя пользовательский интерфейс диспетчера сервера, вы можете установить общее количество колонок до 8 для полосатого тома. Когда вы подключаете более восьми дисков, используйте PowerShell для создания тома. Используя PowerShell, вы можете установить количество столбцов, равное количеству дисков. Например, если в одном наборе чередования 16 дисков, укажите 16 столбцы в параметре NumberOfColumns команды cmdlet PowerShell New-VirtualDisk.

В Linux используйте утилиту MDADM для создания массива на дисках. Для получения инструкций по созданию полосы на дисках в Linux см. Настройка программного RAID в Linux.

Размер полосы

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

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

В зависимости от типа рабочей нагрузки, которую выполняет ваше приложение, выберите подходящий размер полосы. Для случайных небольших запросов ввода/вывода используйте меньший размер полосы. Для больших последовательных запросов ввода-вывода используйте больший размер полосы. Узнайте рекомендации по размеру полосы для приложения, которое вы будете запускать на премиальном хранилище. Для SQL Server настройте размер полосы в 64 КБ для рабочих нагрузок OLTP и 256 КБ для рабочих нагрузок хранилищ данных. Для получения дополнительной информации см. Рекомендации по лучшей производительности для SQL Server на виртуальных машинах Azure.

Многопоточность

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

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

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

Существуют параметры конфигурации, которые вы можете изменить, чтобы повлиять на многопоточность или параллельную обработку в приложении. Например, для SQL Server это max degree of parallelism конфигурация. Эта настройка, называемая MAXDOP, позволяет вам настроить максимальное количество процессоров, которые SQL Server может использовать при параллельной обработке. Вы можете настроить MAXDOP для отдельных запросов или операций с индексами. Эта возможность полезна, когда вы хотите сбалансировать ресурсы вашей системы для критически важного приложения по производительности.

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

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

Длина очереди

Глубина очереди, длина очереди или размер очереди — это количество ожидающих I/O запросов в системе. Значение глубины очереди определяет, сколько операций ввода-вывода ваше приложение может поставить в очередь, которые обрабатывают диски хранения. Это влияет на все три показателя производительности приложения, обсуждаемых в этой статье: IOPS, пропускная способность и задержка.

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

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

Некоторые приложения предоставляют настройки для управления глубиной очереди. Например, настройка MAXDOP в SQL Server, объясненная в предыдущем разделе. MAXDOP – это способ влиять на глубину очереди и многопоточность, хотя он напрямую не изменяет значение глубины очереди в SQL Server.

Высокая глубина очереди

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

Обычно приложение может достичь максимальной пропускной способности с 8 до 16+ необработанных операций ввода-вывода на подключённый диск. Если глубина очереди равна единице, приложение не передает системе достаточное количество операций ввода-вывода, и оно обрабатывает меньший объем за данный период времени. Другими словами, меньшая пропускная способность.

Например, в SQL Server, установив значение MAXDOP для запроса на 4, вы информируете SQL Server, что он может использовать до четырех ядер для выполнения запроса. SQL Server определяет наилучшее значение глубины очереди и количество ядер для выполнения запроса.

Оптимальная глубина очереди

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

Вы не должны настраивать глубину очереди на слишком высокое значение, а на оптимальное, которое может обеспечить достаточное количество IOPS для приложения без влияния на задержки. Например, если задержка приложения должна составлять 1 миллисекунду, глубина очереди, необходимая для достижения 5,000 IOPS, будет QD = 5,000 x 0.001 = 5.

Глубина очереди для полосатого тома

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

Ограничение скорости

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

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

Дальнейшие действия

Если вы хотите протестировать производительность вашего диска, ознакомьтесь со следующими статьями:

• Для Linux: проверка производительности приложения в хранилище дисков Azure
• Для Windows: Провести тест производительности диска

Узнайте больше о доступных типах дисков:

• Для Linux: Выберите тип диска
• Для Windows: Выберите тип диска

Для пользователей SQL Server рекомендуем ознакомиться со статьями о лучших практиках повышения производительности SQL Server.

• Лучшие практики производительности для SQL Server в виртуальных машинах Azure
• Премиум-хранилище Azure обеспечивает наивысшую производительность для SQL Server на виртуальной машине Azure.