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

  • Статья

Применимо к:SQL Server на виртуальной машине Azure

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

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

Включите Оценку SQL для SQL Server на виртуальных машинах Azure для проверки сервера SQL Server на соответствие рекомендациям (результаты будут отображаться на странице управления виртуальными машинами SQL на портале Azure).

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

Обзор

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

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

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

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

  • Новая серия Ebdsv5 обеспечивает максимально высокое соотношение пропускной способности ввода-вывода и количества виртуальных ядер в Azure, а также соотношение памяти и количества виртуальных ядер, равное 8. Эта серия предлагает наилучшее соотношение цены и качества для рабочих нагрузок SQL Server на виртуальных машинах Azure. Рекомендуется использовать эту серию для большинства рабочих нагрузок SQL Server.
  • Используйте размеры виртуальных машины с 4 или более виртуальными ЦП, например E4ds_v5 или выше.
  • Используйте размеры виртуальных машин, оптимизированные для операций в памяти, для повышения производительности при выполнении рабочих нагрузок SQL Server.
  • Серии Edsv5, M- и Mv2- обеспечивают оптимальное соотношение объема памяти и количества виртуальных ядер, требуемое для рабочих нагрузок OLTP.
  • Виртуальные машины серии M обеспечивают максимально высокое соотношение объема памяти и количества виртуальных ядер в Azure. Рекомендуется использовать эти виртуальные машины для критически важных задач и рабочих нагрузок хранилища данных.
  • Используйте образы Azure Marketplace для развертывания Виртуальные машины SQL Server, так как параметры SQL Server и параметры хранилища настроены для оптимальной производительности.
  • Собирайте характеристики производительности целевой рабочей нагрузки и используйте их для определения подходящего размера виртуальной машины для вашего бизнеса.
  • Используйте средства рекомендаций Помощник по миграции данных и SKU, чтобы найти нужный размер виртуальной машины для существующей рабочей нагрузки SQL Server.
  • Используйте Azure Data Studio для миграции в Azure.

Хранилище

Список проверка в этом разделе описывает рекомендации по хранению sql Server на виртуальных машинах Azure.

  • Отслеживайте приложение и определите требования к пропускной способности и задержке хранилища для данных, журналов и tempdb файлов SQL Server перед выбором типа диска.
  • При наличии настройте файлы данных и журналов tempdbна томе D: локальный SSD. Расширение агента IaaS SQL обрабатывает папку и разрешения, необходимые при повторной подготовке.
  • Чтобы оптимизировать производительность хранилища, запланируйте максимально возможное количество некешированных операций ввода-вывода в секунду и используйте кеширование данных в качестве функции производительности при чтении данных, избегая при этом установки ограничения на виртуальные машины и диски.
  • При использовании виртуальных машин SQL Server серии Ebdsv5 или Ebsv5 используйте SSD класса Premium версии 2 для повышения производительности цен. Вы можете развернуть виртуальную машину SQL Server с SSD уровня "Премиум" версии 2 с помощью портал Azure (в настоящее время в предварительной версии).
  • Рассмотрите возможность использования Azure Elastic SAN для рабочих нагрузок SQL Server для повышения экономичности из-за консолидации хранилища, динамической производительности и возможности повышения пропускной способности хранилища без необходимости обновления виртуальной машины.
  • Поместите данные, журналы и 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 перед изменением настроек кеширования диска.
  • Для рабочих нагрузок разработки и тестирования, а также для долгосрочного архивирования резервных копий рассмотрите возможность использования стандартного хранилища. Не рекомендуется использовать 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 можно зашифровать конфиденциальные данные, защитить виртуальные машины от вирусов и вредоносных программ, защитить сетевой трафик, определить и обнаружить угрозы, удовлетворить требования к соответствию, а также использовать единый метод администрирования и создания отчетов для любых потребностей в безопасности в гибридном облаке.

  • Используйте Microsoft Defender для облака для оценки и принятия мер для повышения уровня безопасности среды данных. Такие возможности, как Azure Advanced Threat Protection (ATP), можно использовать в гибридных рабочих нагрузках для улучшения оценки безопасности и предоставления возможности реагировать на риски. Регистрация виртуальной машины SQL Server с помощью расширений агента IaaS SQL Microsoft Defender для облака оценки в ресурсе виртуальной машины SQL портал Azure.
  • Используйте Microsoft Defender для SQL для обнаружения и устранения потенциальных уязвимостей базы данных, а также обнаружения аномальных действий, которые могут указывать на угрозу для экземпляра SQL Server и уровня базы данных.
  • Оценка уязвимостей — это компонент Microsoft Defender для SQL, который может обнаруживать и помогать устранять потенциальные риски в среде SQL Server. Этот компонент предоставляет сведения о состоянии безопасности и предлагает практические действия для устранения проблем с безопасностью.
  • Используйте конфиденциальные виртуальные машины Azure для усиления защиты используемых данных и неактивных данных от доступа оператора узла. Конфиденциальные виртуальные машины Azure позволяют уверенно хранить конфиденциальные данные в облаке и соответствовать строгим требованиям соответствия.
  • Если вы находитесь в SQL Server 2022, попробуйте использовать проверку подлинности Microsoft Entra для подключения к экземпляру SQL Server.
  • Помощник по Azure анализирует конфигурацию ресурсов и данные телеметрии их использования и рекомендует решения, которые помогут повысить эффективность затрат и производительность, а также уровень доступности и безопасности ресурсов Azure. Используйте помощник по Azure на уровне виртуальной машины, группы ресурсов или подписки, чтобы определить и применить рекомендации по оптимизации развертываний Azure.
  • Используйте Шифрование дисков Azure, если потребности в безопасности и соответствии предусматривают использование сквозного шифрования данных с помощью ключей шифрования, включая шифрование временного (локально подключенного) диска.
  • Управляемые диски шифруются при хранении по умолчанию с помощью Шифрования службы хранилища Azure, и ключи шифрования являются управляемыми Майкрософт ключами, которые хранятся в Azure.
  • См. сравнение параметров шифрования управляемых дисков.
  • Порты управления должны быть закрыты на виртуальных машинах, так как открытые порты удаленного управления подвергают виртуальную машину высокому риску атак через Интернет. Эти атаки используют метод подбора учетных данных для получения доступа к компьютеру от имени администратора.
  • Включите JIT-доступ для виртуальных машин Azure.
  • Используйте Бастион Azure через протокол удаленного рабочего стола (RDP).
  • Заблокируйте порты и разрешите только необходимый трафик приложений с помощью Брандмауэра Azure — управляемого брандмауэра в качестве службы (FaaS), который предоставляет или запрещает доступ к серверу на основе исходного IP-адреса.
  • Используйте группы безопасности сети (NSG) для фильтрации трафика между ресурсами Azure в виртуальной сети Azure.
  • Используйте группы безопасности приложений, чтобы объединять в группы серверы с аналогичными требованиями к фильтрации портов и аналогичными функциями, такими как веб-серверы и серверы баз данных.
  • Для веб-серверов и серверов приложений используйте защиту от распределенных атак типа "отказ в обслуживании" (DDoS) Azure. Атаки DDoS используются для перегрузки и исчерпания сетевых ресурсов, чтобы приложения работали медленнее или стали недоступными. Часто атаки DDoS нацелены на пользовательские интерфейсы. Защита от атак DDoS Azure очищает нежелательный сетевой трафик, прежде чем он повлияет на доступность службы.
  • Используйте расширения виртуальной машины, чтобы помочь устранить вредоносные программы, требуемое состояние, обнаружение угроз, предотвращение и исправление угроз на уровне операционной системы, компьютера и сети:
  • Используйте Политика Azure для создания бизнес-правил, которые можно применить к вашей среде. Политики Azure оценивают ресурсы Azure, сравнивая свойства этих ресурсов с правилами, определенными в формате JSON.
  • Служба Azure Blueprints позволяет облачным архитекторам и центральным ИТ-группам определять воспроизводимый набор ресурсов Azure, который реализует стандарты, шаблоны и требования организации и полностью соответствует им. Решение Azure Blueprints отличается от Политик Azure.

функции SQL Server

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

Azure

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

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

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

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

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

  • По возможности развертывайте виртуальные машины SQL Server в нескольких подсетях, чтобы не использовать Azure Load Balancer или имя распределенной сети (DNN) для маршрутизации трафика к решению HADR.
  • Измените параметры кластера на менее жесткие, чтобы избежать непредвиденных перерывов в работе из-за временных сбоев сети или обслуживания платформы 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 < (2 * SameSubnetThreshold * SameSubnetDelay).
      Начните с 40 секунд. Если вы используете расслабленные SameSubnetThreshold значения, SameSubnetDelay рекомендуемые ранее, не превышает 80 секунд для значения времени ожидания аренды.
    • Max failures in a specified period (Максимальное число сбоев за указанный период). Задайте значение 6.
  • Если для подключения к решению HADR используется имя виртуальной сети (VNN) и Azure Load Balancer, укажите MultiSubnetFailover = true в строке подключения, даже если кластер включает только одну подсеть.
    • Если клиент не поддерживает MultiSubnetFailover = TrueRegisterAllProvidersIP = 0 настройку и HostRecordTTL = 300 кэширование учетных данных клиента в течение более короткой длительности. Но это может привести к увеличению числа запросов к DNS-серверу.
  • Чтобы подключиться к решению HADR с использованием распределенного сетевого имени (DNN), рассмотрим следующее:
    • Необходимо использовать драйвер клиента, поддерживающий MultiSubnetFailover = True. Этот параметр должен быть указан в строке подключения.
    • Используйте уникальный порт DNN в строке подключения при подключении к прослушивателю DNN для группы доступности.
  • Используйте строку подключения зеркального отображения базы данных для базовой группы доступности, чтобы избежать необходимости в подсистеме балансировки нагрузки или DNN.
  • Проверьте размер сектора VHD перед развертыванием решения для обеспечения высокой доступности, чтобы избежать операций ввода-вывода с неверным выравниванием. Дополнительные сведения см. в статье базы знаний 3009974.
  • Если для ядра СУБД SQL Server, прослушивателя группы доступности Always On или пробы работоспособности экземпляра отказоустойчивого кластера настроено использование порта в диапазоне от 49 152 до 65 536 (диапазон динамических портов по умолчанию для TCP/IP), добавьте исключение для каждого порта. Это позволяет предотвратить динамическое назначение другим системам того же порта. В следующем примере создается исключение для порта 59999:
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

Устранение проблем с производительностью

Ниже приведен список ресурсов, которые помогут вам устранить проблемы с производительностью SQL Server.

Связанный контент

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

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