Служба хранилища: рекомендации по оптимизации производительности SQL Server на виртуальных машинах Azure

Область применения: SQL Server на виртуальной машине Azure

В этой статье приведены рекомендации и рекомендации по оптимизации производительности SQL Server в Azure Виртуальные машины (виртуальная машина).

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

Дополнительные сведения см. в других статьях этой серии: Контрольный список, Размер виртуальной машины, Безопасность, Конфигурация HADR, Сбор базовых показателей.

Контрольный список

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

  • Отслеживайте приложение и определите требования к пропускной способности и задержке хранилища для данных, журналов и tempdb файлов SQL Server перед выбором типа диска.
  • При наличии настройте файлы данных и журналов tempdb на томе D: локальный SSD. Расширение агента IaaS SQL обрабатывает папку и разрешения, необходимые при повторной подготовке.
  • Чтобы оптимизировать производительность хранилища, запланируйте максимально возможное количество некешированных операций ввода-вывода в секунду и используйте кеширование данных в качестве функции производительности при чтении данных, избегая при этом установки ограничения на виртуальные машины и диски.
  • При использовании виртуальных машин SQL Server серии Ebdsv5 или Ebsv5 используйте SSD класса Premium версии 2 для повышения производительности цен. Вы можете развернуть виртуальную машину SQL Server с SSD уровня "Премиум" версии 2 с помощью портал Azure (в настоящее время в предварительной версии).
  • Поместите данные, журналы и tempdb файлы на отдельные диски.
    • Для диска данных используйте диски класса Premium P30 и P40 или меньше , чтобы обеспечить поддержку кэша. При использовании серии виртуальных машин Ebdsv5 используйте SSD класса Premium версии 2 , которая обеспечивает более высокую производительность для рабочих нагрузок, требующих высокой пропускной способности ввода-вывода и ввода-вывода.
    • Для плана диска журнала для емкости и тестирования производительности и затрат при оценке дисков SSD уровня "Премиум" версии 2 или SSD уровня "Премиум" P30 — P80
      • Если требуется задержка в хранилище подмиллисекунда, используйте диски SSD уровня Premium версии 2 или Azure ценовой категории "Ультра" для журнала транзакций.
      • Для развертываний виртуальных машин серии M рекомендуется использовать ускоритель записи с помощью дисков Azure ценовой категории "Ультра".
    • Поместите tempdb на временный диск (временный диск является временным и по умолчанию используется D:\) для большинства рабочих нагрузок SQL Server, которые не являются частью экземпляра отказоустойчивого кластера (FCI) после выбора оптимального размера виртуальной машины.
      • Если для локального диска недостаточно tempdbемкости, рассмотрите возможность изменения размера виртуальной машины. Дополнительные сведения см. в политиках кэширования файлов данных.
    • Для экземпляров отказоустойчивого кластера (FCI) размещается tempdb в общем хранилище.
      • Если рабочая нагрузка FCI сильно зависит от tempdb производительности диска, то в качестве расширенной конфигурации tempdb на локальном эфемерном диске SSD (по умолчанию), который не является частью D:\хранилища FCI. Эта конфигурация нуждается в пользовательском мониторинге и действии, чтобы локальный временный диск SSD (по умолчанию D:\) был доступен все время, так как любые сбои этого диска не активируют действие из FCI.
  • Обеспечьте чередование нескольких дисков данных Azure с помощью дисковых пространств, чтобы увеличить пропускную способность операций ввода-вывода до ограничения для операций ввода-вывода в секунду и пропускной способности целевой виртуальной машины.
  • Задайте кэширование узла только для чтения для дисков файлов данных.
  • Задайте для кэширования узла значение none для дисков файлов журнала.
    • Не следует включать кэширование для чтения и записи на дисках, содержащих файлы данных или журналов SQL Server.
    • Всегда останавливайте службу SQL Server перед изменением настроек кеширования диска.
  • При переносе нескольких разных рабочих нагрузок в облако Azure Elastic SAN может быть экономичным решением для консолидированного хранилища. Однако при использовании Azure Elastic SAN достижение требуемой пропускной способности операций ввода-вывода в секунду или пропускной способности для рабочих нагрузок SQL Server часто требует избыточной емкости. Хотя обычно не подходит для отдельных рабочих нагрузок SQL Server, вы можете достичь экономичного решения при сочетании рабочих нагрузок с низкой производительностью с SQL Server.
  • Для рабочих нагрузок разработки и тестирования, а также для долгосрочного архивирования резервных копий рассмотрите возможность использования стандартного хранилища. Не рекомендуется использовать hdD/SSD уровня "Стандартный" для рабочих нагрузок.
  • Платное ускорение дисков (P1–P20) следует использовать только для небольших рабочих нагрузок разработки или тестирования и систем отделов.
  • Чтобы оптимизировать производительность хранилища, запланируйте максимальное доступное число операций ввода-вывода в секунду и используйте кэширование данных в качестве функции производительности для операций чтения данных, избегая ограничения и регулирования виртуальных машин и дисков.
  • Отформатируйте диск данных с размером единиц размещения 64 КБ для всех файлов данных на этом диске, за исключением временного диска D:\ (размер которого по умолчанию составляет 4 КБ). Виртуальные машины SQL Server, развернутые через Azure Marketplace, поставляются с дисками данных, отформатированными с размером единицы размещения и чередованием для пула носителей, равным 64 КБ.
  • Настройте учетную запись хранения в том же регионе, что и виртуальная машина SQL Server.
  • Отключите геоизбыточное хранилище Azure (георепликацию) и используйте LRS (локально избыточное хранилище) в учетной записи хранения.
  • Включите оценку рекомендаций SQL для выявления возможных проблем с производительностью и оценки того, что виртуальная машина SQL Server настроена для выполнения рекомендаций.
  • Просмотрите и отслеживайте ограничения дисков и виртуальных машин с помощью метрик использования операций ввода-вывода в хранилище.
  • Исключите ФАЙЛЫ SQL Server из антивирусного программного обеспечения, включая файлы данных, файлы журналов и файлы резервной копии.

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

Обзор

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

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

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

Совет

Подготовка виртуальной машины SQL Server с помощью портал Azure поможет вам в процессе настройки хранилища и реализует большинство рекомендаций по хранению, таких как создание отдельных пулов носителей для файлов данных и журналов, назначение tempdb на D:\ диск и включение оптимальной политики кэширования. Дополнительные сведения о подготовке и настройке хранилища см. в разделе Конфигурация хранилища виртуальной машины SQL.

Типы дисков виртуальной машины

Вы можете выбирать уровень производительности для своих дисков. Типы управляемых дисков, доступные в качестве базового хранилища (перечисленные при повышении производительности), — это жесткие диски уровня "Стандартный" (HDD), твердотельные накопители (SSD) уровня "Стандартный", "Премиум", SSD версии 2 и "Ультра".

Для жестких дисков уровня "Стандартный", "Стандартный" и "Премиум" производительность диска увеличивается с размером диска, сгруппированного по меткам дисков уровня "Премиум", таким как P1 с 4 ГиБ пространства и 120 операций ввода-вывода в секунду на P80 с 32 ТиБ хранилища и 20 000 операций ввода-вывода в секунду. Хранилище категории "Премиум" поддерживает кеш хранилища, который помогает повысить производительность операций чтения и записи для некоторых рабочих нагрузок. Дополнительные сведения см. в статье Обзор управляемых дисков.

Производительность SSD уровня "Премиум" версии 2 и "Ультра" может быть изменена независимо от размера диска. Дополнительные сведения см. в статье "Производительность диска "Ультра" и производительность SSD уровня "Премиум" версии 2.

Существует также три основных роли дисков, которые следует учитывать для SQL Server на виртуальной машине Azure — диск ОС, временный диск и диски данных. Тщательно выбирайте, что должно храниться на диске операционной системы (C:\) и временном диске (D:\).

Диск операционной системы.

Диск операционной системы — это виртуальный жесткий диск, который может быть использован как загрузочный и подключен в качестве рабочей версии операционной системы. Отмечается как диск C:\. При создании виртуальной машины Azure платформа подключает к ней как минимум один диск в качестве диска операционной системы. Диск C:\ — это место по умолчанию для установки приложений и конфигурации файлов.

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

Временный диск

Многие виртуальные машины Azure содержат другой тип диска, называемый временным диском (помеченным как D:\ диск). В зависимости от серии виртуальных машин и размера емкости этого диска будет отличаться. Временный диск является временным, что означает, что хранилище дисков создается повторно (как и в случае, когда виртуальная машина перезапущена и выделена снова), при перезапуске виртуальной машины или перемещено на другой узел (например, для восстановления службы).

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

Поместите tempdb на локальный временный SSD-диск D:\ для рабочих нагрузок SQL Server, если только использование локального кэша не является проблемой. Если вы используете виртуальную машину, которая не имеет временного диска , рекомендуется разместить tempdb на отдельном изолированном диске или пуле носителей с кэшированием только для чтения. Дополнительные сведения см. в разделе Политики кеширования данных tempdb.

Диски данных

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

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

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

Отформатируйте диск данных с размером единиц размещения 64 КБ для всех файлов данных на этом диске, за исключением временного диска D:\ (размер которого по умолчанию составляет 4 КБ). Виртуальные машины SQL Server, развернутые через Azure Marketplace, поставляются с дисками данных, отформатированными с размером единицы размещения и чередованием для пула носителей, равным 64 КБ.

Примечание.

Также можно разместить файлы базы данных SQL Server непосредственно в хранилище BLOB-объектов Azure или в хранилище SMB, например в общей папке Azure premium, но мы рекомендуем использовать управляемые диски Azure для повышения производительности, надежности и доступности компонентов.

SSD (цен. категория "Премиум") версии 2

При выполнении рабочих нагрузок SQL Server в поддерживаемых регионах следует использовать диски SSD уровня "Премиум" версии 2, если текущие ограничения подходят для вашей среды. В зависимости от конфигурации SSD уровня "Премиум" версии 2 может быть дешевле, чем ssd класса Premium, а также повысить производительность. С помощью SSD уровня "Премиум" версии 2 можно отдельно настроить пропускную способность или операции ввода-вывода в секунду независимо от размера диска. Возможность индивидуально настраивать параметры производительности позволяет повысить экономию затрат и позволяет выполнять скрипт изменений в соответствии с требованиями к производительности в течение ожидаемых или известных периодов необходимости.

Мы рекомендуем использовать SSD уровня "Премиум" версии 2 при использовании серии виртуальных машин Ebdsv5 или Ebsv5, так как это более экономичное решение для этих высокопроизводительных компьютеров пропускной способности ввода-вывода.

Вы можете развернуть виртуальные машины SQL Server с SSD уровня "Премиум" версии 2 с помощью портал Azure (в настоящее время в предварительной версии).

Если вы развертываете виртуальную машину SQL Server с помощью портал Azure и хотите использовать SSD уровня "Премиум" версии 2, вы в настоящее время ограничены виртуальными машинами серии Ebdsv5 или Ebsv5. Однако если вы вручную создадите виртуальную машину с хранилищем SSD уровня "Премиум" версии 2, а затем вручную установите SQL Server на виртуальной машине, можно использовать любую серию виртуальных машин, поддерживающую SSD уровня "Премиум" версии 2. Обязательно зарегистрируйте виртуальную машину SQL Server в расширении агента IaaS SQL, чтобы воспользоваться всеми преимуществами , предоставляемыми расширением.

Azure Elastic SAN

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

Это решение может масштабировать до миллионов операций ввода-вывода в секунду, двузначных ГБ/с пропускной способности и низкой однозначной миллисекундной задержки с встроенной устойчивостью, чтобы свести к минимуму время простоя. Используйте Azure Elastic SAN, если необходимо объединить хранилище, работать с несколькими вычислительными службами или иметь рабочие нагрузки, требующие высокого уровня пропускной способности при управлении хранилищем по пропускной способности сети. Тем не менее, так как для рабочих нагрузок SQL Server часто требуется избыточное количество операций ввода-вывода в секунду, обычно это не подходит для отдельных рабочих нагрузок SQL Server. Объединение других рабочих нагрузок с низкой производительностью с SQL Server может потребоваться для достижения наиболее экономичного решения.

При рассмотрении размера и производительности виртуальных машин для Azure Elastic SAN важно понимать, что обмен данными хранилища происходит через сеть. Например, размер виртуальной машины E4d_v5 не поддерживает Azure хранилище класса Premium, но хорошо работает с Azure Elastic SAN, так как поддерживает до 12 500 Мбит/с пропускной способности сети. При использовании Azure Elastic SAN с этим размером виртуальной машины необходимо убедиться, что требования к пропускной способности сети и хранилища для рабочей нагрузки соответствуют ограничению пропускной способности сети в 12 500 Мбит/с.

Определите требования к сети и хранилищу перед развертыванием виртуальной машины SQL Server с помощью azure Elastic SAN, а затем тщательно отслеживайте использование сети и хранилища, чтобы убедиться, что выбранная виртуальная машина может разместить рабочую нагрузку. Дополнительные сведения см. в статье о производительности виртуальных машин с помощью томов Elastic SAN и метрик Эластичных SAN.

Внимание

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

Рассмотрите возможность размещения рабочих нагрузок SQL Server в эластичной сети SAN для повышения затрат, так как:

  • Консолидация хранилища и динамическое совместное использование производительности. Обычно для рабочих нагрузок виртуальных машин Azure хранилище дисков подготавливается на каждой виртуальной машине на основе емкости и пиковых требований к производительности для этой виртуальной машины. Эта избыточность доступна при необходимости, но неиспользуемая производительность не может быть предоставлена рабочим нагрузкам на других виртуальных машинах. Эластичная сеть SAN, аналогичная локальной сети SAN, позволяет консолидировать потребности хранилища нескольких рабочих нагрузок SQL и не SQL для повышения экономичности, с возможностью динамического совместного использования подготовленной производительности в томах, подготовленных для этих различных рабочих нагрузок на основе требований ввода-вывода. Например, в регионе "Восточная часть США", например, у вас есть 10 рабочих нагрузок, требующих 2-ТиБ емкости и 10 ТЫСЯЧ операций ввода-вывода в секунду, но в совокупности они не нуждаются в более чем 60 000 операций ввода-вывода в секунду в любое время. Вы можете настроить эластичную SAN с 12 базовыми единицами (1 базовый модуль = $0,08 за ГиБ/месяц), что даст вам 12 ТиБ емкости и необходимые 60K операций ввода-вывода в секунду и 8 единиц емкости (1 единица только емкости = $0,06 за ГиБ/месяц), что дает вам оставшуюся емкость 8-ТиБ при более низкой стоимости. Эта оптимальная конфигурация хранилища обеспечивает более высокую экономичность при обеспечении необходимой производительности (10 КБ операций ввода-вывода в секунду) для каждой из этих рабочих нагрузок. Дополнительные сведения о базовых и емкостях единиц подготовки elastic SAN см. в статье "Планирование эластичной сети SAN Azure" и цен на Azure Elastic SAN . Цены.
  • Для повышения пропускной способности хранилища: развертывания SQL Server на виртуальных машинах Azure иногда требуют чрезмерной подготовки виртуальной машины из-за ограничений пропускной способности диска для этой виртуальной машины. Это можно избежать с помощью elastic SAN, так как вы используете более высокую пропускную способность хранилища по пропускной способности вычислительной сети с помощью протокола iSCSI. Например, виртуальная машина Standard_E32ds_v5 ограничена 51 200 операций ввода-вывода в секунду и 865 МБИТ/с для пропускной способности диска или хранилища, но может достичь не более 2000 МБИТ/с пропускной способности сети. Если требование пропускной способности хранилища для рабочей нагрузки превышает 865 МБИТ/с, вам не придется обновлять виртуальную машину до более крупного номера SKU, так как теперь она может поддерживать до 2000 МБИТ/с с с помощью Elastic SAN.

SSD ценовой категории «Премиум»

Используйте диски SSD класса Premium для файлов данных и журналов для рабочих нагрузок SQL Server. Объем операций ввода-вывода в секунду ssd класса Premium и пропускная способность зависят от размера и типа диска.

Для производственных рабочих нагрузок используйте диски P30 и/или P40 для файлов данных SQL Server, чтобы обеспечить кеширование, и диски от P30 до P80 для файлов журнала транзакций SQL Server. Для оптимальной общей стоимости владения начните с P30s (5000 операций ввода-вывода в секунду/200 МБИТ/с) для файлов данных и журналов и выберите только более высокие емкости, если необходимо контролировать количество дисков виртуальной машины. Для разработки и тестирования или небольших систем можно использовать размеры меньше P30, так как они поддерживают кэширование, но они не предлагают зарезервированные цены.

Для рабочих нагрузок OLTP сопоставьте целевое количество операций ввода-вывода в секунду на диск (или пул носителей) с требованиями к производительности, используя рабочие нагрузки во время пиковой нагрузки и счетчики производительности Disk Reads/sec + Disk Writes/sec. Для рабочих нагрузок хранилища данных и отчетов сопоставьте целевую пропускную способность, используя рабочие нагрузки во время пиковой нагрузки и счетчики производительности Disk Read Bytes/sec + Disk Write Bytes/sec.

Используйте дисковые пространства для достижения оптимальной производительности и настройте два пула: один для файлов журнала, а другой — для файлов данных. Если вы не используете чередование дисков, используйте два диска SSD класса Premium, сопоставленные с отдельными дисками, где один диск содержит файл журнала, а другой — данные.

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

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

Масштабирование дисков уровня "Премиум"

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

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

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

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

Дополнительные сведения см. в разделе Уровни производительности для управляемых дисков.

Диск Azure категории "Ультра"

Если требуется время отклика субмиллисекунда с меньшей задержкой, рассмотрите возможность использования диска azure ultra для диска журнала SQL Server или даже диска данных для приложений, которые очень чувствительны к задержке ввода-вывода.

Диск категории "Ультра" можно настроить так, чтобы емкость и количество операций ввода-вывода в секунду масштабировались независимо. Используя диск категории "Ультра", администраторы могут подготовить диск к работе с учетом требований приложения к емкости, количеству операций ввода-вывода в секунду и пропускной способности.

Диск "Ультра" не поддерживается во всех рядах виртуальных машин и имеет другие ограничения, такие как доступность регионов, избыточность и поддержка Azure Backup. Дополнительные сведения и полный список ограничений см. в разделе Использование дисков Azure категории "Ультра".

Жесткие диски и твердотельные накопители категории "Стандартный"

Стандартные жесткие диски и твердотельные накопители имеют разную задержку и полосу пропускания и рекомендуются только в качестве рабочих нагрузок для разработки и тестирования. Рабочие нагрузки должны использовать SSD уровня "Премиум" версии 2 или SSD уровня "Премиум". Если вы используете SSD уровня "Стандартный" (сценарии разработки и тестирования), рекомендуется добавить максимальное количество дисков данных, поддерживаемых размером виртуальной машины, и использовать чередование дисков с дисковые пространства для оптимальной производительности.

Кэширование

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

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

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

Операции чтения и записи в Azure BlobCache (кэшированные операции ввода-вывода в секунду и пропускная способность) не учитываются в некичированных ограничениях операций ввода-вывода в секунду и пропускной способности виртуальной машины.

Примечание.

Кеширование дисков не поддерживается для дисков объемом от 4 ТиБ (P50 и выше). Если к виртуальной машине подключено несколько дисков, то кэширование применяется ко всем дискам, размер которых меньше 4 ТиБ. Дополнительные сведения см. в разделе Кеширование диска.

Некешированная пропускная способность

Максимальное количество операций ввода-вывода в секунду на диск и пропускная способность — максимальное ограничение удаленного хранилища, которое может обрабатывать виртуальная машина. Это ограничение определяется на виртуальной машине и не является ограничением базового хранилища дисков. Это ограничение применяется к операциям ввода-вывода для дисков данных, удаленно подключенных к виртуальной машине, но не к локальным операциям ввода-вывода для временного диска (D:\) или диска ОС.

Объем некшированных операций ввода-вывода в секунду и пропускной способности, доступных для виртуальной машины, можно проверить в документации по виртуальной машине.

Например, в документации для серии M указано, что максимальная некешированная пропускная способность для виртуальной машины Standard_M8ms составляет 5000 операций ввода-вывода в секунду и 125 Мбит/с пропускной способности некешированного диска.

Снимок экрана: документация по пропускной способности некэшированных дисков серии M.

Аналогичным образом можно увидеть, что Standard_M32ts поддерживает 20 000 некшированных операций ввода-вывода в секунду и 500 МБИТ/с без кэширования пропускной способности диска. Это ограничение регулируется на уровне виртуальной машины независимо от базового хранилища дисков класса Premium.

Дополнительные сведения см. в разделе Ограничения кешированных и некешированных дисков.

Пропускная способность кешированного и временного хранилища

Максимальное ограничение пропускной способности кэшированного и временного хранилища является отдельным ограничением от некичированного ограничения пропускной способности на виртуальной машине. Azure BlobCache состоит из сочетания памяти случайного доступа узла виртуальной машины и локально подключенного SSD. Временный диск (D:\ диск) на виртуальной машине также размещается на этом локальном SSD.

Верхний предел пропускной способности кешированного и временного хранилища управляет вводом-выводом для локального временного диска (D:\) и Azure BlobCache, только если включено кеширование узла.

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

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

Снимок экрана: поддержка хранилища категории

Ограничения кэша зависят от размера виртуальной машины. Например, Standard_M8ms виртуальная машина поддерживает 10000 кэшированных операций ввода-вывода в секунду и пропускную способность кэшированного диска размером 1000 МБИТ/с с общим размером кэша 793 ГиБ. Аналогичным образом виртуальная машина Standard_M32ts поддерживает 40000 кэшированных операций ввода-вывода в секунду и пропускную способность кэшированного диска размером 400 МБИТ/с с общим размером кэша 3174 ГиБ.

Снимок экрана: документация по пропускной способности кэшированного диска серии M.

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

Политики кеширования файлов данных

Политика кеширования хранилища зависит от типа файлов данных SQL Server, размещенных на диске.

В следующей таблице приводится сводка рекомендуемых политик кеширования в зависимости от типа данных SQL Server.

Диск SQL Server Рекомендация
Диск данных Включите кеширование Read-only для дисков, на которых размещены файлы данных SQL Server.
Чтение из кеша будет выполняться быстрее, чем некешированное чтение с диска данных.
Не кэширование операций ввода-вывода в секунду и пропускная способность, а также кэшированные операции ввода-вывода в секунду и пропускная способность обеспечивают общую производительность, доступную для виртуальной машины, но фактические показатели производительности зависят от способности рабочей нагрузки использовать кэш (коэффициент попадания кэша).
Диск журнала транзакций Установите политику кеширования в значение None для дисков, на которых размещен журнал транзакций. Нет преимущества производительности для кэширования диска журнала транзакций, и на самом деле Read-only Read/Write включение кэширования на диске журнала может снизить производительность операций записи на диске и уменьшить объем кэша, доступного для операций чтения на диске данных.
Диск операционной системы Read/write — политика кеширования по умолчанию для диска ОС.
Не рекомендуется изменять уровень кэширования диска ОС.
tempdb Если tempdb не удается поместить на временный диск D:\ из-за причин емкости, измените размер виртуальной машины, чтобы получить более большой временный диск или поместить tempdb на отдельный диск данных с Read-only настроенным кэшированием.
Кэш виртуальных машин и временный диск используют локальный SSD, поэтому при изменении размера tempdb операций ввода-вывода будут учитываться ограничения кэшированных операций ввода-вывода и пропускной способности виртуальных машин при размещении на эфемерном диске.

Внимание

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

Дополнительные сведения см. в разделе Кеширование диска.

Чередование дисков

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

Добавьте дополнительные диски данных и используйте чередование дисков для большей пропускной способности. Например, приложение с пропускной способностью 12 000 операций ввода-вывода в секунду и 180 МБ/с может использовать три полосатых диска P30 для доставки пропускной способности 15 000 операций ввода-вывода в секунду и 600 МБ/с.

Сведения о настройке чередования дисков см. в разделе Чередование дисков.

Установка ограничения на использование диска

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

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

Например, если приложению требуется пропускная способность 12 000 операций ввода-вывода в секунду и 180 Мбит/с, можно:

  • Используйте Standard_M32ms, которая имеет максимальную пропускную способность диска без кэширования 20 000 операций ввода-вывода в секунду и 500 МБИТ/с.
  • использовать три диска P30 с чередованием для обеспечения пропускной способности 15 000 операций ввода-вывода в секунду и 600 Мбит/с;
  • Используйте виртуальную машину Standard_M16ms и используйте кэширование узла для использования локального кэша при использовании пропускной способности.

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

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

Примечание.

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

Ускорение записи

Ускорение записи — это функция диска, доступная только для виртуальных машин серии M. Цель ускорения записи — уменьшить задержку ввода-вывода при записи в хранилище Azure категории "Премиум", когда вам нужна задержка ввода-вывода, не превышающая однозначных показателей, из-за критически важных рабочих нагрузок OLTP большого объема или сред хранилищ данных.

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

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

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

SKU виртуальной машины Кол-во дисков Ускорителя записи Число операций ввода-вывода в секунду на диске Ускорителя записи на VM
M416ms_v2, M416s_v2 16 20000
M128ms, M128s 16 20000
M208ms_v2, M208s_v2 8 10000
M64ms, M64ls, M64s 8 10000
M32ms, M32ls, M32ts, M32s 4 5000
M16ms, M16s 2 2500
M8ms, M8s 1 1250

Существует несколько ограничений для использования ускорения записи. Дополнительные сведения см. в разделе Ограничения при использовании Ускорителя записи.

Сравнение с диском Azure ценовой категории "Ультра"

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

По возможности используйте для диска журнала транзакций ускорение записи вместо дисков категории "Ультра". Для виртуальных машин, которые не поддерживают ускорение записи, но требуют низкой задержки в журнале транзакций, используйте диски Azure ultra.

Мониторинг производительности хранилища

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

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

Пропускная способность — это объем данных, отправляемых в базовое хранилище, часто измеряемый в мегабитах в секунду. Измеряйте пропускную способность с помощью счетчиков Монитора производительности: Disk Read Bytes/sec и Disk Write Bytes/sec. Хранилище данных оптимизировано для увеличения пропускной способности за счет количества операций ввода-вывода в секунду. Такие приложения, как хранилища данных для анализа, отчетности, рабочие потоки извлечения, преобразования и загрузки, а также другие целевые объекты бизнес-аналитики, являются примерами приложений хранилища данных.

Размеры единиц ввода-вывода влияют на количество операций ввода-вывода в секунду и пропускную способность: меньшие размеры единиц ввода-вывода приводят к большему количеству операций ввода-вывода в секунду, а большие размеры единиц ввода-вывода обеспечивают более высокую пропускную способность. SQL Server автоматически выбирает оптимальный размер ввода-вывода. Дополнительные сведения см. в разделе Оптимизация операций ввода-вывода в секунду, пропускной способности и задержки для ваших приложений.

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

Примечание.

В настоящее время Azure Monitor не предлагает метрики уровня диска для временных временных дисков (D:\). Процент потребленных VM кэшированных операций ввода-вывода в секунду и процент потребленной VM кэшированной пропускной способности будут отражать общее количество операций ввода-вывода в секунду и пропускную способность от использования временного диска ((D:\)) и кэширования узла.

Мониторинг роста журнала транзакций

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

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

Если необходимо расширить диск, вы можете сделать это на панели хранилища ресурса виртуальных машин SQL, если вы развернули образ SQL Server из Azure Marketplace или на панели дисков для виртуальной машины Azure и самоустановленного SQL Server.

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

Дополнительные сведения см. в других статьях из этой серии материалов с рекомендациями: