Уровень служб "Гипермасштабирование"

  • Статья
  • Чтение занимает 15 мин

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

База данных SQL Azure основана на архитектуре ядра СУБД SQL Server, которая соответствует облачной среде, чтобы даже в случае сбоя инфраструктуры обеспечить высокий уровень доступности. Существует три варианта уровня служб в модели приобретения виртуальных ядер для базы данных Azure SQL:

  • Общее назначение
  • Критически важный для бизнеса
  • Уровень "Гипермасштабирование"

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

Примечание

Каковы возможности ценовой категории "Гипермасштабирование"?

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

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

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

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

Дополнительные сведения о размерах вычислительных ресурсов для уровня служб "Гипермасштабирование" см. в разделе Характеристики уровней служб.

Кому рекомендуется использовать уровень служб "Гипермасштабирование"

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

Важно!

Эластичные пулы не поддерживают уровень служб "Гипермасштабирование".

Модель ценообразования для ценовой категории "Гипермасштабирование"

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

  • Подготовленные вычислительные ресурсы:

    Цена за единицу вычислений ценовой категории "Гипермасштабирование" на реплику. Цена Преимущество гибридного использования Azure применяется к высокодоступным и именованным репликам автоматически. Пользователи могут настроить общее количество вторичных реплик с высоким уровнем доступности от 0 до 4 в зависимости от требований к доступности и масштабируемости, а также создать до 30 именованных реплик для поддержки различных рабочих нагрузок чтения с горизонтальным масштабированием.

  • Бессерверные вычисления:

    Выставление счетов за бессерверные вычисления основано на использовании. Дополнительные сведения см. в статье Бессерверные вычисления .

  • Хранилище.

    Указывать максимальный объем данных при настройке базы данных ценовой категории "Гипермасштабирование" не нужно. На уровне служб "Гипермасштабирование" счета за использование хранилища для базы данных выставляются на основе фактического использования. Хранилище автоматически выделяется от 10 ГБ до 100 ТБ и увеличивается с шагом в 10 ГБ при необходимости.

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

Сравнение ограничений по ресурсам

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

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

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

Вычислительные ресурсы

Конфигурация оборудования ЦП Память
4-е поколение - Процессоры Intel® E5-2673 версии 3 (Haswell) с частотой 2,4 ГГц.
— Подготовка до 24 виртуальных ядер (физических)		 7 ГБ на виртуальное ядро.
Подготовка до 168 ГБ.
Серия 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 (Милан)
— Автоматическое вертикальное увеличение масштаба до 40 виртуальных ядер (с поддержкой технологии Hyper-Threading)		 Подготовленные вычисления
5,1 ГБ на виртуальное ядро.
— Подготовка до 625 ГБ

Бессерверные вычисления
Автомасштабирование до 24 ГБ на виртуальное ядро.
— Автоматическое масштабирование до 240 ГБ не более
Серия Premium (предварительная версия) - Процессоры Intel® Xeon Platinum 8307C (Ice Lake), AMD EPYC 7763v (Милан) 5,1 ГБ на виртуальное ядро.
— Подготовка до 128 виртуальных ядер (с поддержкой технологии Hyper-Threading)
Оптимизировано для памяти серии Premium (предварительная версия) - Процессоры Intel® Xeon Platinum 8307C (Ice Lake), AMD EPYC 7763v (Милан) — 10,2 ГБ на виртуальное ядро
— Подготовка до 80 виртуальных ядер (с поддержкой технологии Hyper-Threading)

* В представлении динамического управления 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 (Milan) — как Gen8. Для заданного размера вычислительных ресурсов и конфигурации оборудования ограничения ресурсов одинаковы независимо от типа ЦП. Дополнительные сведения см. в разделе Ограничения ресурсов для отдельных баз данных и эластичных пулов.

Бессерверный режим поддерживается только на оборудовании серии Standard (Gen5).

Важно!

Оборудование 4-го поколения прекращается и недоступно для новых развертываний, как было объявлено 18 декабря 2019 г. Клиенты, использующие оборудование 4-го поколения для базы данных Azure SQL или Управляемый экземпляр SQL Azure, должны перейти на доступное в настоящее время оборудование, например стандартное (5-е поколение), до 31 марта 2023 г. Существующие базы данных 4-го поколения, эластичные пулы и управляемые экземпляры SQL будут автоматически перенесены на эквивалентное оборудование стандартной серии (Gen5).

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

Архитектура распределенных функций

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

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

Архитектура

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

Преимущества масштабирования и производительности

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

Создание и администрирование баз данных с Гипермасштабированием

Вы можете создавать базы данных уровня "Гипермасштабирование" и управлять ими с помощью портал Azure, Transact-SQL, PowerShell и Azure CLI. См. краткое руководство. Создание базы данных с гипермасштабированием.

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

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

Высокий уровень доступности базы данных в варианте развертывания "Гипермасштабирование"

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

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

Резервное копирование и восстановление

Операции резервного копирования и восстановления для баз данных с гипермасштабированием работают на основе моментальных снимков файлов. Это позволяет выполнять такие операции практически мгновенно. Так как в архитектуре гипермасштабирования резервное копирование и восстановление выполняются на уровне хранилища, значительно сокращается объем необходимых вычислений и нагрузка на реплики вычислительных ресурсов. Дополнительные сведения см. в разделе Резервные копии с Гипермасштабированием и избыточность хранилища.

Аварийное восстановление для баз данных уровня "Гипермасштабирование"

Если необходимо восстановить базу данных уровня "Гипермасштабирование" в базе данных SQL Azure в регионе, отличном от того, на котором она размещена, в рамках операции аварийного восстановления или детализации, перемещения или любой другой причины, основной метод заключается в выполнении географического восстановления базы данных. Геовосстановление доступно только в том случае, если для избыточности хранилища выбрано геоизбыточное хранилище (RA-GRS).

Подробнее см. статью Восстановление базы данных "Гипермасштабирование" в другом регионе.

Известные ограничения

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

Проблема Описание
Краткосрочное хранение резервных копий Краткосрочное хранение резервных копий в течение 1–35 дней для баз данных уровня "Гипермасштабирование" теперь доступно в предварительной версии. Обычную базу данных невозможно восстановить так же, как базу данных уровня "Гипермасштабирование", и наоборот.

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

Для баз данных, которые не имеют права на обратную миграцию, единственным способом перехода с уровня служб "Гипермасштабирование" на уровень служб, отличный от "Гипермасштабирования", является экспорт и импорт с помощью BACPAC-файла или других технологий перемещения данных (массовое копирование, Фабрика данных Azure, Azure Databricks, службы SSIS и т. д.). Экспорт и импорт bacpac из портал Azure, из PowerShell с помощью Командлета New-AzSqlDatabaseExport или New-AzSqlDatabaseImport, из Azure CLI с помощью az sql db export и az sql db import, а также из REST API не поддерживается. Импорт и экспорт BACPAC для баз данных (до 200 ГБ) уровня "Гипермасштабирование" поддерживается с помощью SSMS и SqlPackage версии 18.4 и более поздних. Для больших баз данных экспорт/импорт BACPAC может занять много времени и может завершиться ошибкой по различным причинам.
Эластичные пулы В настоящее время эластичные пулы не поддерживаются с БД уровня "Гипермасштабирование".
Миграция баз данных с помощью объектов In-Memory OLTP Гипермасштабирование поддерживает подмножество In-Memory объектов OLTP, включая оптимизированные для памяти табличные типы, табличные переменные и скомпилированные в собственном коде модули. Однако если в переносимой базе данных присутствуют какие-либо In-Memory объекты OLTP, переход с уровней служб "Премиум" и критически важный для бизнеса на уровень "Гипермасштабирование" не поддерживается. Чтобы перенести такую базу данных на уровень "Гипермасштабирование", все объекты OLTP In-Memory и их зависимости должны быть удалены. После переноса базы данных эти объекты можно создать заново. Устойчивые и неустойчивые таблицы, оптимизированные для памяти, в настоящее время не поддерживаются в гипермасштабировании и должны быть изменены на дисковые таблицы.
Сжатие базы данных DbCC SHRINKDATABASE, DBCC SHRINKFILE или установка AUTO_SHRINK на уровне базы данных, в настоящее время не поддерживаются для баз данных с гипермасштабированием.
Проверка целостности базы данных В настоящее время команда DBCC CHECKDB не поддерживается для баз данных уровня служб "Гипермасштабирование". В качестве обходного решения можно использовать команды DBCC CHECKTABLE ('имя_таблицы') WITH TABLOCK и DBCC CHECKFILEGROUP WITH TABLOCK. Дополнительные сведения об управлении целостностью данных в базе данных SQL Azure см. в статье Целостность данных в базе данных SQL Azure.
Задания обработки эластичных баз данных Использование базы данных уровня "Гипермасштабирование" в качестве базы данных заданий не поддерживается. Но задания обработки эластичных баз данных могут применяться к базам данных уровня "Гипермасштабирование" так же, как и к любой другой Базе данных SQL Azure.
Синхронизация данных Использование базы данных уровня "Гипермасштабирование" в качестве центральной базы данных или базы данных метаданных синхронизации не поддерживается. Однако база данных с уровнем служб "Гипермасштабирование" может быть рядовой базой данных в топологии "Синхронизация данных".
Оборудование уровня служб "Премиум" уровня "Гипермасштабирование" (предварительная версия) Избыточность между зонами в настоящее время не поддерживается для оборудования серии Premium и оптимизированного для памяти оборудования серии Premium.
Оборудование уровня служб "Премиум" уровня "Гипермасштабирование" (предварительная версия) Azure SQL период обслуживания базы данных в настоящее время не поддерживается для серии Premium и оптимизированной для памяти серии Premium.

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

Дополнительные сведения о Гипермасштабировании в Базе данных SQL Azure см. в следующих статьях: