Контрольный список: рекомендации для SQL Server на виртуальных машинах Azure

ОБЛАСТЬ ПРИМЕНЕНИЯ: SQL Server на виртуальной машине Azure

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

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

Обзор

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

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

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

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

  • Используйте размеры виртуальных машин с 4 или более виртуальными ЦП, например Standard_M8-4ms, E4ds_v4 или DS12_v2 или выше.
  • Используйте размеры виртуальных машин, оптимизированные для операций в памяти, для повышения производительности при выполнении рабочих нагрузок SQL Server.
  • Серии DSv2 11-15, Edsv4, M и Mv2 обеспечивают оптимальное соотношение памяти к виртуальным ядрам, необходимое для рабочих нагрузок OLTP. Обе виртуальные машины серии M обеспечивают наиболее оптимальное соотношение памяти к виртуальным ядрам, необходимое для критически важных рабочих нагрузок, и идеально подходят для рабочих нагрузок хранилища данных.
  • Рекомендуется использовать более высокое соотношение памяти к виртуальным ядрам для критически важных рабочих нагрузок и рабочих нагрузок хранилища данных.
  • Следует использовать образы виртуальных машин Azure из Marketplace, так как параметры SQL Server и хранилища настроены для оптимальной производительности SQL Server.
  • Соберите характеристики производительности целевой рабочей нагрузки и используйте их для определения подходящего размера виртуальной машины для вашего бизнеса.
  • Используйте инструмент Помощник по миграции данныхРекомендация SKU для определения оптимального размера виртуальной машины для имеющейся рабочей нагрузки SQL Server.

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

Память

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

  • Выполните мониторинг приложения и определите требования относительно задержки и пропускной способности хранилища для файлов данных SQL Server, журналов, а также файлов tempdb, прежде чем выбрать тип диска.
  • Чтобы оптимизировать производительность хранилища, запланируйте максимально возможное количество некэшированных операций ввода-вывода в секунду и используйте кэширование данных в качестве функции для повышения производительности при чтении данных, избегая при этом установки ограничения и регулирования виртуальных машин и дисков.
  • Разместите файлы данных, журналов и файлы tempdb на разных дисках.
    • В качестве дисков данных используйте только диски P30 и P40 категории "Премиум", чтобы обеспечить доступность поддержки кеша.
    • Запланируйте емкость для диска журнала и проверьте соотношение производительности и стоимости при оценке дисков P30–P80 категории "Премиум".
      • Если требуется задержка хранилища менее миллисекунды, используйте для журнала транзакций диски Azure категории "Ультра".
      • Для развертываний виртуальных машин серии M рекомендуется использовать Ускоритель записи вместо дисков Azure категории "Ультра".
    • разместите базу данных tempdb на локальном диске с временным SSD (по умолчанию D:\ ) для большинства SQL Server рабочих нагрузок, выбрав оптимальный размер виртуальной машины.
      • Если емкость локального диска недостаточна для tempdb, рассмотрите возможность увеличения размера виртуальной машины. Дополнительные сведения см. в разделе Политики кеширования файлов данных.
  • Разделите несколько дисков данных Azure с помощью дисковых пространств, чтобы увеличить пропускную способность ввода-вывода до границ операций ввода-вывода в секунду и пропускной способности целевой виртуальной машины.
  • Установите для кеширования узлов значение "только для чтения" для дисков с файлами данных.
  • Установите для кеширования узлов значение none для дисков с файлами журнала.
    • Не включайте кеширование чтения и записи на дисках, содержащих файлы SQL Server.
    • Всегда останавливайте работу службы SQL Server перед изменением настроек кеширования диска.
  • Для рабочих нагрузок разработки и тестирования рекомендуется использовать хранилище ценовой категории "Стандартный". Не рекомендуется использовать HDD/SDD (цен. категория "Стандартный") для производственных рабочих нагрузок.
  • Платное ускорение дисков (P1–P20) следует рассматривать только для небольших рабочих нагрузок разработки или тестирования и систем отделов.
  • Подготовьте учетную запись хранения в том же регионе, где размещена виртуальная машина SQL Server.
  • Отключите геоизбыточное хранилище Azure (георепликацию) и используйте LRS (локально избыточное хранилище) в учетной записи хранения.
  • Отформатируйте диск данных с размером единиц размещения 64 КБ для всех файлов данных на этом диске, за исключением временного диска D:\ (размер которого по умолчанию составляет 4 КБ). Виртуальные машины SQL Server, развернутые через Azure Marketplace, поставляются с дисками данных, отформатированными с размером единицы размещения и чередованием для пула носителей, равным 64 КБ.

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

функции SQL Server

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

Azure

Ниже приведен краткий список рекомендаций по конфигурации Azure при выполнении SQL Server на виртуальной машине Azure.

Конфигурация HADR

Возможности HADR (высокая доступность и аварийное восстановление), такие как группы доступности Always On и экземпляр отказоустойчивого кластера, основываются на технологии отказоустойчивого кластера Windows Server. Изучите современные рекомендации по настройке параметров HADR для работы с облачной средой.

Для кластера Windows примените следующие рекомендации:

  • Измените параметры кластера на менее жесткие, чтобы избежать непредвиденных перерывов в работе из-за временных сбоев сети или обслуживания платформы Azure. Дополнительные сведения см. в разделе Параметры пульса и порога. Для Windows Server 2012 или более поздней версии используйте следующие рекомендованные значения.
    • SameSubnetDelay: 1 секунда;
    • SameSubnetThreshold: 40 пульсов;
    • CrossSubnetDelay: 1 секунда;
    • CrossSubnetThreshold: 40 пульсов.
  • Разместите виртуальные машины в группе доступности или в разных зонах доступности. Дополнительные сведения см. в разделе Параметры доступности виртуальной машины.
  • Используйте одну сетевую карту на узел кластера и одну подсеть.
  • Настройте кворум для голосования в кластере таким образом, чтобы требовалось три голоса или большее нечетное число голосов. Не назначайте голоса регионам аварийного восстановления.
  • Тщательно отслеживайте ограничения ресурсов, чтобы избежать непредвиденных перезапусков или отработки отказа.
    • Используйте последние сборки ОС, драйверов и SQL Server.
    • Оптимизируйте производительность SQL Server на виртуальных машинах Azure. Ознакомьтесь с остальными разделами этой статьи, чтобы получить дополнительные сведения.
    • Сократите или распределите рабочую нагрузку, чтобы не допустить превышения ограничений для ресурсов.
    • Перейдите на виртуальную машину или диск с более высокими значениями ограничений, чтобы избежать их превышения.

Для группы доступности SQL Server или экземпляра отказоустойчивого кластера учитывайте следующие рекомендации:

  • При частом возникновении непредвиденных сбоев следуйте рекомендациям по повышению производительности, приведенным далее в этой статье.
  • Если оптимизация производительности виртуальных машин SQL Server не помогает устранить непредвиденные отработки отказа, можно попробовать ослабить мониторинг группы доступности или экземпляра отказоустойчивого кластера. Но источник проблемы при этом может сохраниться: вы просто скроете внешние проявления и уменьшите вероятность сбоя. Чтобы устранить первопричину, потребуется провести дополнительный анализ. Для Windows Server 2012 или более поздней версии используйте следующие рекомендованные значения:
    • Lease timeout (Время ожидания аренды). Чтобы вычислить максимальное время ожидания аренды, используйте следующую формулу:
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      Начните с 40 секунд. Если вы используете более низкие значения SameSubnetThreshold и SameSubnetDelay, рекомендованные ранее, значение времени ожидания аренды не должно превышать 80 секунд.
    • Максимальное число сбоев за указанный период: можно задать значение 6.
    • Время ожидания Healthcheck: для этого значения можно установить значение 60000 изначально, при необходимости измените.
  • Если для подключения к решению HADR используется имя виртуальной сети (VNN), укажите MultiSubnetFailover = true в строке подключения, даже если кластер включает только одну подсеть.
    • Если клиент не поддерживает MultiSubnetFailover = True, возможно, потребуется задать RegisterAllProvidersIP = 0 и HostRecordTTL = 300, чтобы сократить срок кэширования учетных данных клиента. Но это может привести к увеличению числа запросов к DNS-серверу.
  • Если для подключения к решению HADR используется имя распределенной сети (DNN), учтите следующие требования:
    • Необходимо использовать драйвер клиента, поддерживающий MultiSubnetFailover = True. Этот параметр должен быть указан в строке подключения.
    • Используйте уникальный порт DNN в строке подключения при подключении к прослушивателю DNN для группы доступности.
  • Используйте строку подключения зеркального отображения базы данных для базовой группы доступности, чтобы избежать необходимости в подсистеме балансировки нагрузки или DNN.
  • Проверьте размер сектора VHD перед развертыванием решения для обеспечения высокой доступности, чтобы избежать операций ввода-вывода с неверным выравниванием. Дополнительные сведения см. в статье базы знаний 3009974.

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

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

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

Рекомендации по безопасности см. в статье Вопросы безопасности SQL Server на виртуальных машинах Azure.

Ознакомьтесь с другими статьями, посвященными виртуальным машинам SQL Server, используя руководство с обзором SQL Server на виртуальных машинах с Windows. Если у вас есть вопросы по виртуальным машинам SQL Server, см. раздел часто задаваемых вопросов.