Модель приобретения на основе виртуальных ядер (База данных SQL Azure)

Область применения: База данных SQL Azure

• База данных SQL Azure
• Управляемый экземпляр SQL Azure

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

Обзор

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

В модели приобретения по числу виртуальных ядер стоимость зависят от выбора и использования:

• Уровень служб
• Конфигурация оборудования
• Вычислительные ресурсы (число виртуальных ядер и объем памяти)
• Зарезервированное хранилище базы данных
• Фактическое хранилище резервных копий

Важно!

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

Модель приобретения виртуальных ядер, используемая Azure SQL Database, предоставляет несколько преимуществ по сравнению с моделью приобретения на основе DTU.

• Более высокие лимиты вычислительной мощности, памяти, операций ввода-вывода и хранилища.
• Выбор конфигурации оборудования для лучшего соответствия требованиям рабочей нагрузки к вычислениям и памяти.
• Скидки на Преимущество гибридного использования Azure (AHB).
• Более прозрачные сведения об оборудовании, обеспечивающем вычисления, что упрощает планирование миграции из локальных развертываний.
• Цены на зарезервированные экземпляры доступны только для модели приобретения на основе виртуальных ядер.
• Более высокая точность масштабирования благодаря наличию нескольких объемов вычислительных ресурсов.

Сведения о выборе между моделями приобретения виртуальных ядер и DTU см. в разделе Различия между моделями приобретения на основе виртуальных ядер и DTU.

Вычисления

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

Подведение итогов.

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

Независимо от уровня вычислений, три дополнительные вторичные реплики с высоким уровнем доступности автоматически выделяются на уровне служб критически важный для бизнеса для обеспечения высокой устойчивости к сбоям и быстрой отработки отказа. Это делает стоимость примерно в 2,7 раза выше, чем на общего назначения уровне служб. Аналогичным образом, более высокая стоимость хранилища на ГБ на уровне служб критически важный для бизнеса отражает более высокие ограничения операций ввода-вывода и меньшую задержку локального хранилища SSD.

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

Хранилище данных и журналов

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

• Объем вычислительных ресурсов поддерживает настраиваемый максимальный размер данных (размер по умолчанию — 32 ГБ).
• При настройке максимального размера данных для файлов журнала автоматически добавляются дополнительные 30 процентов оплачиваемой емкости хранилища.
• При использовании уровня служб "Общего назначения" tempdb использует локальное хранилище SSD, а затраты на хранилище входят в стоимость виртуального ядра.
• При использовании уровня служб "Критически важный для бизнеса" tempdb использует локальное хранилище SSD как для данных, так и для файлов журналов, а затраты на хранилище tempdb входят в стоимость виртуального ядра.
• На уровнях общего назначения и критически важный для бизнеса плата взимается за максимальный размер хранилища, настроенный для базы данных или эластичного пула.
• Для Базы данных SQL можно выбрать любой максимальный размер данных в диапазоне от 1 ГБ до максимального поддерживаемого размера хранилища с шагом в 1 ГБ.

К гипермасштабированию относятся следующие рекомендации по хранилищу:

• Максимальный размер хранилища данных составляет 100 ТБ и не настраивается.
• Плата взимается только за выделенное хранилище данных, но не за максимальное хранилище данных.
• Плата за хранение журналов не взимается.
• tempdb использует локальное хранилище SSD, и его стоимость включается в цену виртуальных ядер. Чтобы отслеживать текущий выделенный и используемый размер хранилища данных в Базе данных SQL, используйте метрики Azure Monitor allocated_data_storage и storage соответственно.

Чтобы отслеживать текущий выделенный и используемый размер хранилища отдельных файлов данных и журналов в базе данных с помощью T-SQL, используйте представление sys.database_files и функцию FILEPROPERTY(... , 'SpaceUsed' ).

Совет

Иногда требуется сжать базу данных, чтобы освободить неиспользуемое пространство. Дополнительные сведения см. в статье об управлении файловым пространством в Базе данных SQL Azure.

Хранилище резервных копий

Хранилище для резервных копий базы данных выделяется для поддержки восстановления на определенный момент времени (PITR) и долгосрочного хранения (LTR) База данных SQL. Это отдельное хранилище, не связанное с хранилищем файлов данных и журналов, и оплачивается оно отдельно.

• PITR: на уровнях "Общего назначения" и "Критически важный для бизнеса" резервные копии отдельных баз данных автоматически копируются в хранилище Azure. Размер этого хранилища динамически увеличивается по мере создания новых резервных копий. В хранилище помещаются полные разностные резервные копии и копии журналов транзакций. Потребление хранилища зависит от скорости изменения базы данных и настроенного периода хранения резервных копий. Для каждой базы данных можно настроить отдельный период хранения в диапазоне от 1 до 35 дней для База данных SQL. Объем хранилища резервных копий, равный настроенному максимальному размеру данных, предоставляется без дополнительной оплаты.
• LTR: вы также можете настроить долгосрочное хранение полных резервных копий на срок до 10 лет. Если вы включите политику долгосрочно хранения, резервные копии будут автоматически сохраняться в хранилище BLOB-объектов Azure, но вы можете контролировать частоту их копирования. Чтобы выполнять требования к соответствию, вы можете выбрать разные периоды хранения для резервных копий, создаваемых еженедельно, ежемесячно или ежегодно. Выбранная конфигурация определяет, какой объем хранилища будет использоваться для резервных копий с долгосрочным хранением. Дополнительные сведения см. в разделе Долгосрочное хранение резервных копий.

Сведения о хранилище резервных копий в режиме "Гипермасштабирование" см. в статье Автоматическое резервное копирование для баз данных с гипермасштабированием.

Уровни службы

Модель приобретения на основе виртуальных ядер предоставляет следующие уровни служб: "общего назначения", "критически важный для бизнеса" и "Гипермасштабирование". Уровень служб обычно определяет тип и производительность хранилища, высокий уровень доступности и варианты аварийного восстановления, а также доступность некоторых функций, таких как In-Memory OLTP.

Вариант использования	Общего назначения	Уровень "Критически важный для бизнеса"	Гипермасштабирование
Сценарии применения	Большинства рабочих нагрузок. Предлагает бюджетные, сбалансированные и масштабируемые варианты вычислений и хранения.	Обеспечивает максимальную устойчивость бизнес-приложений к сбоям с помощью нескольких вторичных реплик с высоким уровнем доступности и обеспечивает максимальную производительность операций ввода-вывода.	Самые разнообразные рабочие нагрузки, включая рабочие нагрузки с высокомасштабируемым хранилищем и требованиями к масштабированию для чтения. Обеспечивает более высокую устойчивость к сбоям, позволяя настроить несколько вторичных реплика с высоким уровнем доступности.
Объем вычислительных ресурсов	От 2 до 128 виртуальных ядер	От 2 до 128 виртуальных ядер	От 2 до 128 виртуальных ядер1
Тип хранилища	Удаленное хранилище класса Premium (для каждого экземпляра)	Сверхбыстрое локальное хранилище SSD (для каждого экземпляра)	Разъединяемого хранилища с локальным кэшем SSD (для каждого вычислительного реплика)
Размер хранилища1	От 1 ГБ до 4 ТБ	От 1 ГБ до 4 ТБ	от 10 ГБ до 100 ТБ
ОПЕРАЦИЙ ВВОДА-ВЫВОДА	Максимум 16 000 операций ввода-вывода в секунду	8000 операций ввода-вывода в секунду на виртуальное ядро с максимальным количеством операций ввода-вывода в секунду 200 000	327 680 операций ввода-вывода в секунду с максимальным локальным ssd Гипермасштабирование — это многоуровневая архитектура с кэшированием на нескольких уровнях. Эффективное число операций ввода-вывода в секунду зависит от рабочей нагрузки.
Память/виртуальное ядро	5,1 ГБ	5,1 ГБ	5,1 ГБ или 10,2 ГБ4
Резервные копии	Выбор геоизбыточного, избыточного между зонами или локально избыточного хранилища резервных копий, хранение на протяжении 1–35 дней (по умолчанию — 7 дней) Долгосрочное хранение до 10 лет	Выбор геоизбыточного, избыточного между зонами или локально избыточного хранилища резервных копий, хранение на протяжении 1–35 дней (по умолчанию — 7 дней) Долгосрочное хранение до 10 лет	Выбор локально избыточного хранилища (LRS), избыточного между зонами (ZRS) или геоизбыточного хранилища (GRS) Хранение от 1 до 35 дней (по умолчанию 7 дней) 2, при этом доступно до 10 лет долгосрочного хранения 3
Доступность	1 реплика, без реплик чтения и масштабирования, высокий уровень доступности с избыточностью в между зонами	3 реплики, 1 реплика чтения и масштабирования, высокий уровень доступности с избыточностью в между зонами	высокий уровень доступности с избыточностью между зонами (предварительная версия),
Цены и выставление счетов	Оплачиваются: виртуальное ядро, зарезервированное хранилище и хранилище резервных копий. Не оплачиваются операции ввода-вывода в секунду.	Оплачиваются: виртуальное ядро, зарезервированное хранилище и хранилище резервных копий. Не оплачиваются операции ввода-вывода в секунду.	Оплачиваются: виртуальное ядро для каждой реплики и используемое хранилище. Пока не оплачиваются операции ввода-вывода в секунду.
Модели скидок	Зарезервированные экземпляры Преимущество гибридного использования Azure (недоступно в подписках для разработки и тестирования) Подписки для разработки и тестирования категорий Корпоративная и с оплатой по мере использования	Зарезервированные экземпляры Преимущество гибридного использования Azure (недоступно в подписках для разработки и тестирования) Подписки для разработки и тестирования категорий Корпоративная и с оплатой по мере использования	Преимущество гибридного использования Azure (недоступно в подписках для разработки и тестирования) Подписки для разработки и тестирования категорий Корпоративная и с оплатой по мере использования

¹ Эластичные пулы не поддерживаются на уровне служб "Гипермасштабирование".
² Краткосрочное хранение резервных копий в течение 1–35 дней для баз данных уровня "Гипермасштабирование" теперь находится в предварительной версии.
³ Долгосрочное хранение баз данных уровня "Гипермасштабирование" теперь доступно в предварительной версии. ^{Доступно 4} 10,2 ГБ на виртуальное ядро с оптимизированным для памяти оборудованием серии Premium (предварительная версия).

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

Примечание

Дополнительные сведения о Соглашении об уровне обслуживания для Базы данных SQL Azure см. здесь.

Общего назначения

Архитектурная модель для уровня служб "Общего назначения" основана на разделении вычислений и хранилища. Эта модель архитектуры основана на высокой доступности и надежности хранилища BLOB-объектов Azure, которое прозрачно реплицирует файлы базы данных и гарантирует отсутствие потери данных в случае сбоя базовой инфраструктуры.

На следующем рисунке показано четыре узла в стандартной архитектурной модели с разделенными уровнями вычислений и хранения.

В архитектурной модели для уровня служб "Общего назначения" существует два уровня:

• Уровень вычислений без отслеживания состояния, на котором выполняется процесс sqlservr.exe и содержатся только временные и кэшированные данные (например, кэш планов, буферный пул, пул хранения столбцов). Этим узлом без отслеживания состояния управляет платформа Azure Service Fabric, которая инициализирует процесс, контролирует работоспособность узла и при необходимости выполняет переход на другой ресурс.
• Уровень данных с отслеживанием состояния, где файлы базы данных (MDF/LDF) хранятся в хранилище BLOB-объектов Azure. Хранилище BLOB-объектов Azure гарантирует, что ни одна из записей, размещенных в любом файле базы данных, не будет потеряна. Благодаря встроенной доступности и избыточности этого хранилища каждая запись в файле журнала или страница в файле данных будут сохранены даже в случае отказа процесса.

Каждый раз, когда обновляется ядро СУБД или операционная система, некоторые компоненты базовой инфраструктуры выдают ошибку, или если в процессе sqlservr.exe обнаруживается критическая проблема, Azure Service Fabric перемещает процесс без отслеживания состояния на другой узел вычислений без отслеживания состояния. Существует набор резервных узлов, на которых можно запустить новую службу вычислений в случае отработки отказа, чтобы свести к минимуму время отработки отказа. Это не влияет на данные на уровне хранилища Azure, а файлы данных и журнала присоединяются к только что инициализированному процессу. Этот процесс гарантирует доступность в течение 99,99 % времени по умолчанию и доступность в течение 99,995 % времени, если включена избыточность между зонами. Это может повлиять на производительность больших рабочих нагрузок, которые находятся в режиме выполнения из-за времени перехода и того факта, что новый узел запускается с холодным кэшем.

Когда нужно выбирать этот уровень служб?

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

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

Модель уровня служб "критически важный для бизнеса" основана на кластере процессов ядра СУБД. Эта модель архитектуры использует кворум узлов ядра СУБД, чтобы свести к минимуму влияние на производительность рабочей нагрузки даже во время обслуживания. Обновления и исправления базовой операционной системы, драйверов и ядра СУБД выполняются прозрачно, с минимальным временем простоя для конечных пользователей.

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

Как процесс ядра СУБД, так и базовые файлы .mdf/.ldf размещаются на одном узле с локально подключенным хранилищем SSD, что обеспечивает низкую задержку рабочей нагрузки. Высокий уровень готовности реализуется с помощью технологии, аналогичной группам доступности Always On SQL Server. Каждая база данных — это кластер узлов базы данных с одной первичной реплика, доступной для рабочих нагрузок клиента, и тремя вторичными репликами, содержащими копии данных. Основной реплика постоянно отправляет изменения во вторичные реплики, чтобы обеспечить доступность данных во вторичных репликах в случае сбоя первичной реплики по какой-либо причине. Отработка отказа выполняется Service Fabric и ядром СУБД: одна вторичная реплика становится первичной, и создается новый реплика-получатель, чтобы обеспечить наличие достаточного количества узлов в кластере. Рабочая нагрузка автоматически перенаправляется на новый основной реплика.

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

Когда нужно выбирать этот уровень служб?

Уровень служб критически важный для бизнеса предназначен для приложений, которым требуются ответы с низкой задержкой из базового хранилища SSD (в среднем 1–2 мс), более быстрое восстановление в случае сбоя базовой инфраструктуры или необходимость отключения отчетов, аналитики и запросов только для чтения на бесплатные читаемые вторичные реплика базы данных-источника.

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

• Требования к низкой задержке ввода-вывода. Рабочие нагрузки, которым требуется постоянно быстрый ответ на уровне хранилища (в среднем 1–2 миллисекунда), должны использовать критически важный для бизнеса уровень.
• Рабочая нагрузка с отчетами и аналитическими запросами, где достаточно одного бесплатного дополнительного реплика только для чтения.
• Повышение устойчивости и более быстрое восстановление после сбоев. В случае сбоя системы база данных на экземпляре-источнике отключается, и одна из вторичных реплик немедленно становится новой базой данных-источником для чтения и записи, готовой к обработке запросов.
• Расширенная защита от повреждений данных. Так как уровень критически важный для бизнеса использует реплики баз данных в фоновом режиме, служба использует автоматическое восстановление страниц, доступное с зеркальным отображением и группами доступности, чтобы предотвратить повреждение данных. Если реплика не может прочитать страницу из-за проблемы с целостностью данных, из другой реплика извлекается свежая копия страницы, заменяющая нечитаемую страницу без потери данных или простоя клиента. Эта функция доступна на уровне общего назначения, если база данных имеет георепликующий реплика.
• Более высокий уровень доступности— уровень критически важный для бизнеса в конфигурации зоны с несколькими зонами доступности обеспечивает устойчивость к зональным сбоям и более высокий уровень доступности.
• Быстрое геовосстановление. Если настроена активная георепликация, уровень "Критически важный для бизнеса" предоставляет гарантированные значения 5 секунд для RPO (целевая точка восстановления) и 30 секунд для RTO (целевое время восстановления) с покрытием 100 % часов развертывания.

Гипермасштабирование

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

Дополнительные сведения см. в статье Уровень служб "Гипермасштабирование" для базы данных Azure SQL.

Когда нужно выбирать этот уровень служб?

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

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

• Обеспечение высокой устойчивости и быстрого восстановления сбоев при управлении затратами путем выбора количества реплик с высоким уровнем доступности от 0 до 4.
• Повышение высокого уровня доступности за счет избыточности между зонами для вычислений и хранения.
• Обеспечение низкой задержки ввода-вывода (в среднем 1–2 миллисекунда) для часто запрашиваемой части базы данных. Для небольших баз данных это может относиться ко всей базе данных.
• Реализуйте широкий спектр сценариев горизонтального увеличения масштаба чтения с помощью именованных реплик.
• Воспользуйтесь преимуществами быстрого масштабирования, не дожидаясь копирования данных в локальное хранилище на новых узлах.
• Наслаждайтесь непрерывным резервным копированием базы данных и быстрым восстановлением.
• Поддержка требований к непрерывности бизнес-процессов с помощью групп отработки отказа и георепликации.

Ограничения ресурсов

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

Конфигурация оборудования

Распространенные конфигурации оборудования в модели виртуальных ядер включают серии Standard (Gen5), Fsv2 и DC. Гипермасштабирование также предоставляет возможность для оборудования, оптимизированного для памяти серии "Премиум" и "Премиум". Конфигурация оборудования определяет ограничения вычислительных ресурсов и памяти и другие характеристики, влияющие на производительность рабочей нагрузки.

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

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

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

Серия Standard (5-е поколение)

• Оборудование серии Standard (5-го поколения) предоставляет сбалансированные вычислительные ресурсы и ресурсы памяти и подходит для большинства рабочих нагрузок баз данных.

Поколение серии Standard (поколение Gen5) доступно во всех общедоступных регионах по всему миру.

Серия "Премиум" с гипермасштабированием

• В вариантах оборудования серии "Премиум" используются новейшие технологии ЦП и памяти от Intel и AMD. Серия "Премиум" повышает производительность вычислений по сравнению с оборудованием серии "Стандартный".

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

• Параметр , оптимизированный для памяти серии "Премиум", в два раза превышает объем памяти по сравнению с серией Premium.

• Дополнительные сведения см. в объявлении блога о серии "Премиум" с гипермасштабированием.

Доступные регионы см. в статье Доступность серии "Гипермасштабирование premium".

Серия Fsv2

• Серия Fsv2 — это оптимизированная для вычислений конфигурация оборудования, обеспечивающая низкую задержку и высокую тактовую частоту ЦП для большинства ресурсоемких рабочих нагрузок. Как и в случае с конфигурациями оборудования серии "Премиум", серия Fsv2 использует новейшие технологии ЦП и памяти от Intel и AMD. Это позволяет клиентам воспользоваться новейшим оборудованием при использовании баз данных и эластичных пулов на общего назначения уровне служб.
• В зависимости от рабочей нагрузки серия Fsv2 может обеспечить большую производительность ЦП на виртуальное ядро, чем оборудование других типов. Например, объем вычислительных ресурсов Fsv2 с 72 виртуальными ядрами может обеспечить более высокую производительность ЦП, чем 80 виртуальных ядер в серии Standard (5-го поколения) при меньших затратах.
• Fsv2 предоставляет меньше памяти и tempdb на виртуальное ядро, чем другое оборудование, поэтому рабочие нагрузки, чувствительные к этим ограничениям, могут работать лучше в стандартной серии (5-го поколения).

Серия Fsv2 поддерживается только для уровня "Общего назначения". Регионы, в которых доступна серия Fsv2, приведены в разделе Серия Fsv2.

Серии DC

• Оборудование серии DC использует процессоры Intel с поддержкой расширений Software Guard Extensions (Intel SGX).
• Серия DC требуется для функции Always Encrypted с безопасными анклавами, которая не поддерживается в других конфигурациях оборудования.
• Серия DC предназначена для рабочих нагрузок, которые обрабатывают конфиденциальные данные и нуждаются в возможностях конфиденциальной обработки запросов, предоставляемых Always Encrypted с безопасными анклавами.
• Оборудование серии DC обеспечивает сбалансированные вычислительные ресурсы и ресурсы памяти.

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

Типы предложений Azure, поддерживаемые серией DC

Для создания баз данных и эластичных пулов на оборудовании серии DC нужна платная подписка с оплатой по мере использования или Соглашением Enterprise (EA). Полный список типов предложений Azure, поддерживаемых серией DC, приведен в разделе Сведения о предложении решения Microsoft Azure.

Выбор конфигурации оборудования

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

Выбор конфигурации оборудования при создании Базы данных SQL или пула

Дополнительные сведения см. в статье Краткое руководство. Создание отдельной базы данных в Базе данных SQL Azure.

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

Выберите нужную конфигурацию оборудования:

Изменение конфигурации оборудования существующей Базы данных SQL или пула

На странице "Обзор" для базы данных щелкните ссылку Ценовая категория.

Для пула на странице Обзор выберите Настроить.

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

Доступность оборудования

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

Серия Standard (5-е поколение)

Поколение серии Standard (поколение Gen5) доступно во всех общедоступных регионах по всему миру.

Серия "Премиум" с гипермасштабированием

Оборудование уровня служб "Гипермасштабирование" (в настоящее время находится в предварительной версии) серии "Премиум" и "Премиум", оптимизированное для памяти, доступно в следующих регионах:

• Восточная Австралия
• Центральная Канада
• Центральная Индия
• Центральная часть США
• Восточная часть США
• восточная часть США 2
• Восточная Япония
• Северная Европа
• Центрально-северная часть США
• Центрально-южная часть США
• южная часть Соединенного Королевства
• Западная Европа
• Западная часть США 1
• западная часть США 2

Серия Fsv2

Серия Fsv2 доступна в следующих регионах:

• Центральная Австралия
• Центральная Австралия 2
• Восточная Австралия
• Юго-Восточная часть Австралии
• Brazil South
• Центральная Канада
• Восточная Азия
• Восточная часть США
• Центральная Франция
• Центральная Индия
• Республика Корея, центральный регион
• Республика Корея, южный регион
• Северная Европа
• Северная часть ЮАР;
• Юго-Восточная Азия
• южная часть Соединенного Королевства
• западная часть Соединенного Королевства
• Западная Европа
• западная часть США 2

Серии DC

Серия DC доступна в следующих регионах:

• Центральная Канада
• Восточная Канада
• Восточная часть США
• Северная Европа
• южная часть Соединенного Королевства
• Западная Европа
• западная часть США

Если вам нужна серия DC в неподдерживаемом регионе, отправьте запрос в службу поддержки. На вкладке Основные используйте следующие значения.

1. В качестве типа проблемы укажите Техническая.
2. Укажите нужную подписку для оборудования. Выберите Далее.
3. В качестве типа службы выберите База данных SQL.
4. В поле Ресурс выберите Общий вопрос.
5. В поле Сводка укажите требуемое доступность оборудования и регион.
6. В качестве типа проблемы выберите Безопасность, конфиденциальность и соответствие требованиям.
7. В качестве подтипа проблемы выберите Always Encrypted.

Вычислительные ресурсы (ЦП и память)

В следующей таблице сравниваются вычислительные ресурсы в разных конфигурациях оборудования и уровнях вычислений:

Конфигурация оборудования	ЦП	Память
Серия Standard (5-е поколение)	Подготовленные вычисления - Intel® E5-2673 v4 (Broadwell) 2,3 ГГц, Intel® SP-8160 (Skylake)*, Intel® 8272CL (Cascade Lake) 2,5 ГГц*, Intel® Xeon Platinum 8307C (Ice Lake)*, AMD EPYC 7763v (Милан) — Подготовка до 128 виртуальных ядер (с поддержкой технологии Hyper-Threading) Бессерверные вычисления - Intel® E5-2673 v4 (Broadwell) 2,3 ГГц, Intel® SP-8160 (Skylake)*, Intel® 8272CL (Cascade Lake) 2,5 ГГц*, Intel Xeon® Platinum 8307C (Ice Lake)*, AMD EPYC 7763v (Милан) — Автоматическое масштабирование до 80 виртуальных ядер (с поддержкой hyper-threaded) — Соотношение памяти к виртуальным ядрам динамически адаптируется к использованию памяти и ЦП в зависимости от нагрузки и может составлять до 24 ГБ на виртуальное ядро. Например, в определенный момент времени для рабочей нагрузки может взиматься плата за 240 ГБ памяти и только 10 виртуальных ядер.	Подготовленные вычисления 5,1 ГБ на виртуальное ядро. — Подготовка до 625 ГБ Бессерверные вычисления Автомасштабирование до 24 ГБ на виртуальное ядро. — Автоматическое масштабирование до максимума 240 ГБ
Серия Fsv2	Процессоры Intel® 8168 (Skylake). Обеспечение постоянной тактовой частоты всех ядер в режиме Turbo Boost 3,4 ГГц и максимальной частоты отдельного ядра в режиме Turbo Boost 3,7 ГГц. — Подготовка до 72 виртуальных ядер (с поддержкой технологии Hyper-Threading)	1,9 ГБ на виртуальное ядро. Подготовка до 136 ГБ.
Серия M	Процессоры Intel® E7-8890 версии 3 с частотой 2,5 ГГц и Intel® 8280M с частотой 2,7 ГГц (Cascade Lake). — Подготовка до 128 виртуальных ядер (с поддержкой технологии Hyper-Threading)	29 ГБ на виртуальное ядро. Подготовка до 3,7 ТБ.
Серии DC	– Процессоры Intel® XEON E-2288G — Расширение Intel Software Guard (Intel SGX) — Подготовка до 8 виртуальных ядер (физических)	4,5 ГБ на виртуальное ядро.

* В представлении динамического управления sys.dm_user_db_resource_governance поколение оборудования для баз данных с использованием процессоров Intel® SP-8160 (Skylake) — как Gen6, поколение оборудования для баз данных, использующих Intel® 8272CL (Cascade Lake) — как Gen7, а поколение оборудования для баз данных, использующих Intel Xeon® Platinum 8307C (Ice Lake) или AMD® EPYC® 7763v (Милан) — как Gen8. Для заданного размера вычислительных ресурсов и конфигурации оборудования ограничения ресурсов одинаковы независимо от типа ЦП (Intel Broadwell, Skylake, Ice Lake, Cascade Lake или AMD Milan).

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

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

Оборудование прошлых поколений

4-е поколение

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

Серия M

Для базы данных Azure SQL оборудование серии M прекращено и недоступно для новых развертываний.

Существующие клиенты должны перейти на другие уровни оборудования до сентября 2023 г.

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

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

• Чтобы приступить к работе, см. статью Создание базы данных SQL на портале Azure.
• Информацию о ценах см. на странице цен на Базу данных SQL Azure.
• Сведения о конкретных доступных размерах вычислительных ресурсов и хранилищ см. в следующих статьях.
  • Ограничения ресурсов на основе виртуальных ядер для Базы данных SQL Azure
  • Ограничения ресурсов на основе виртуальных ядер для Базы данных SQL Azure в пуле