Поделиться через

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

  • Статья

Применимо к: База данных SQL Azure

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

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

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

См. подробности об уровнях служб Общего назначения и Критически важного для бизнеса в рамках модели приобретения на основе виртуальных ядер. Для сравнения модели приобретения на основе виртуальных ядер с моделью приобретения на основе DTU см. "Сравнение моделей приобретения на основе виртуальных ядер и DTU" в Azure SQL Database.

Служебный уровень "Гипермасштабирование" в настоящее время доступен только для Azure SQL Database, а не для Azure SQL Managed Instance.

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

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

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

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

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

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

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

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

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

Примечание.

В Azure SQL Database Hyperscale появилось упрощённое ценообразование! Просмотрите новую ценовую категорию для База данных SQL Azure объявления о гипермасштабировании и сведения об изменении цен см. в разделе База данных SQL Azure Гипермасштабирование — более низкие, упрощенные цены!.

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

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

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

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

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

  • Хранение.

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

Дополнительные сведения о ценах на Hyperscale см. в разделе Цены на базу данных Azure SQL.

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

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

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

Схема, на которой показана архитектура гипермасштабирования.

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

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

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

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

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

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

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

Буферный пул, расширение отказоустойчивого буферного пула и непрерывная подготовка

В гипермасштабировании базы данных Azure существует отдельное разделение между вычислительными ресурсами и хранилищем. Хранилище содержит все страницы базы данных в одной базе данных и может быть выделено на нескольких компьютерах по мере роста базы данных. Однако вычислительный узел кэширует только то, что используется в последнее время. Наиболее горячие страницы вычислений хранятся в памяти в структуре, называемой буферным пулом (BP). Он также хранится в локальном SSD, расширении отказоустойчивого буферного пула (RBPEX), поэтому данные можно получить быстрее при перезапуске вычислительного процесса.

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

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

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

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

Примечание.

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

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

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

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

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

Узнайте больше в статье Восстановление гипермасштабной базы данных в другом регионе.

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

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

ㅤ Общего назначения Критически важный для бизнеса Гипермасштабирование
Оптимально для Предлагает варианты бюджетных сбалансированных вычислений и хранилища. Приложения OLTP с высокой скоростью транзакций и низкой задержкой ввода-вывода. Обеспечивает высокую устойчивость к сбоям и быстрое переключение на резервные системы с помощью нескольких горячих резервных реплик. Самый широкий спектр рабочих нагрузок. Размер хранилища автомасштабирования до 128 ТБ, быстрое вертикальное и горизонтальное масштабирование вычислительных ресурсов, быстрое восстановление базы данных.
Объем вычислительных ресурсов 2–128 виртуальных ядер 2–128 виртуальных ядер 2–128 виртуальных ядер (vCores)
Тип хранилища Удаленное хранилище класса Premium (для каждого экземпляра) Сверхбыстрое локальное хранилище SSD (для каждого экземпляра) Отсоединяемое хранилище с локальным кэшем SSD (на реплику вычислений)
Размер хранилища От 1 ГБ до 4 ТБ От 1 ГБ до 4 ТБ 10 ГБ – 128 ТБ
IOPS 320 операций ввода-вывода в секунду на виртуальное ядро с максимальной скоростью 16 000 операций ввода-вывода в секунду 4000 операций ввода-вывода в секунду на виртуальное ядро с максимальным числом 327 680 операций ввода-вывода в секунду 327 680 операций ввода-вывода в секунду с максимальной производительностью локального SSD.
Гиперскейл — это многоуровневая архитектура с кэшированием на нескольких уровнях. Эффективные операции ввода-вывода в секунду зависят от рабочей нагрузки.
Память/виртуальное ядро 5.1 ГБ 5.1 ГБ 5,1 ГБ или 10,2 ГБ
Доступность Одна реплика, чтение без масштабирования, высокая доступность с зональной избыточностью. Три реплики, одно масштабирование чтения, обеспечение высокой доступности с зональной избыточностью Несколько реплик, до четырех увеличенных чтений, зонально-корректируемая высокая доступность.
Резервные копии Выбор локально-избыточного хранилища (LRS), межзонального избыточного хранилища (ZRS) или геоизбыточного хранилища (GRS)
Срок хранения 1–35 дней (семь дней по умолчанию) с доступным сроком хранения до 10 лет		 Выбор локально избыточного хранилища (LRS), зонально избыточного хранилища (ZRS) или геоизбыточного хранилища (GRS)
Срок хранения 1–35 дней (семь дней по умолчанию) с доступным сроком хранения до 10 лет		 Выбор локально избыточного хранилища (LRS), зонально избыточного (ZRS) или геоизбыточного хранилища (GRS)
Срок хранения 1–35 дней (семь дней по умолчанию) с доступным сроком хранения до 10 лет
Цены и выставление счетов Оплачивается виртуальное ядро, резервное хранилище и хранилище резервных копий.
Плата за IOPS не взимается.		 Оплачиваются виртуальное ядро, зарезервированное хранилище и хранилище резервных копий.
Плата за IOPS не взимается.		 Взимается плата за виртуальные ядра для каждой реплики, выделенное хранилище данных и хранилище резервных копий.
Плата за операции ввода-вывода не взимается.
Модели скидок1 Зарезервированные экземпляры
Преимущество гибридного использования Azure 2
Корпоративные и подписки на предложение для разработки и тестирования с оплатой по мере использования		 Зарезервированные экземпляры
Преимущество гибридного использования Azure 2
Корпоративные подписки и подписки на разработку и тестирование с оплатой по мере использования		 Зарезервированные экземпляры
Преимущество гибридного использования Azure 2
Корпоративные и подписки для разработки и тестирования с оплатой по мере использования

1 Упрощенные условия ценообразования для гипермасштабируемой базы данных SQL вступили в действие в декабре 2023 года. Ознакомьтесь с блогом о ценах на гипермасштабируемые решения для получения более подробной информации.

2 По состоянию на декабрь 2023 г. Преимущество гибридного использования Azure недоступно для новых гипермасштабируемых баз данных и в подписках разработки и тестирования. Существующие базы данных гипермасштабирования с подготовленными вычислительными ресурсами могут продолжать использовать Преимущество гибридного использования Azure для экономии затрат на вычисления до декабря 2026 года. Дополнительные сведения см. в блоге о ценах на гипермасштаб.

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

Настройка оборудования ЦП Память
Серия Standard (5-е поколение) Выделенные вычислительные ресурсы
— Процессоры Intel® E5-2673 v4 (Broadwell) 2,3 ГГц, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 ГГц1, Intel® Xeon® Platinum 8370C (Ice Lake)1, AMD EPYC 7763v (Milan)
— Предоставление до 80 vCores (с технологией Hyper-Threading)

Бессерверные вычисления
— Процессоры Intel® E5-2673 v4 (Broadwell) 2,3 ГГц, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 ГГц1, Intel® Xeon® Platinum 8370C (Ice Lake)1, AMD EPYC 7763v (Milan)
— автомасштабирование до 80 виртуальных ядер (с поддержкой гиперпоточности)
— Соотношение памяти к виртуальным ядрам динамически адаптируется к использованию памяти и процессора по требованию рабочей нагрузки и может достигать 24 ГБ на виртуальное ядро. Например, в определенный момент времени рабочая нагрузка может использоваться и взиматься за 240 ГБ памяти и только 10 виртуальных ядер.		 Выделенные вычислительные ресурсы
5,1 ГБ на виртуальное ядро.
— предоставление до 625 ГБ

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

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

Бессерверные технологии поддерживаются только на оборудовании Standard-series (Gen5).

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

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

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

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

Ограничения

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

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

Для баз данных, перенесенных на уровень службы "Гипермасштабирование" из других уровней службы Azure SQL Database, резервные копии, сделанные до миграции, сохраняются в течение периода хранения резервных копий, настроенного для базы данных-источника, включая политики длительного хранения. Восстановление резервной копии перед миграцией в течение периода хранения резервных копий базы данных поддерживается с помощью командной строки. Эти резервные копии можно восстановить с любым уровнем служб, кроме уровня "Гипермасштабирование".
Миграция баз данных с помощью объектов In-Memory OLTP Поддержка HyperScale охватывает подмножество объектов OLTP In-Memory, включая типы таблиц, оптимизированные для памяти, табличные переменные и модули, скомпилированные в собственном формате. Тем не менее, если в базе данных присутствуют объекты OLTP в оперативной памяти, миграция с уровней служб Premium и Критически важный для бизнеса на Hyperscale не поддерживается. Чтобы перенести такую базу данных на уровень "Гипермасштабирование", все объекты OLTP In-Memory и их зависимости должны быть удалены. После переноса базы данных эти объекты можно создать заново. Устойчивые и нестойкие таблицы, оптимизированные для использования памяти, в настоящее время не поддерживаются в Гипермасштабе и необходимо изменить на табличные данные на диске.
Проверка целостности базы данных В настоящее время команда DBCC CHECKDB не поддерживается для баз данных Hyperscale. DBCC CHECKTABLE ('TableName') WITH TABLOCK и DBCC CHECKFILEGROUP WITH TABLOCK можно использовать в качестве обходного решения. Дополнительные сведения об управлении целостностью данных в базе данных SQL Azure см. в статье Целостность данных в базе данных SQL Azure.
Эластичные задания Использование базы данных гипермасштабирования в качестве базы данных задания не поддерживается. Но задания обработки эластичных баз данных могут применяться к базам данных уровня "Гипермасштабирование" так же, как и к любой другой Базе данных SQL Azure.
Синхронизация данных Использование базы данных Hyperscale в качестве концентратора или базы метаданных синхронизации не поддерживается. Однако гипермасштабируемая база данных может быть участником в топологии синхронизации данных.
Оборудование гипермасштабируемой серии уровня обслуживания "Премиум" Оборудование серии "Премиум" и оборудование, оптимизированное для памяти, не поддерживает бессерверный уровень вычислений.
Доступность в регионах Высокомасштабируемое оборудование уровня "Премиум" и "Премиум", оптимизированное для памяти, доступно в ограниченных регионах Azure. Для получения списка см. раздел Доступность серии Hyperscale premium.

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