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

Применимо к:Azure SQL Database

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Хранение.

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

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

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

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

Для получения дополнительной информации, включая полезную схему, см. архитектура Hyperscale.

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

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

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

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

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

Сведения об уровне обслуживания с гипермасштабированием см. в разделе SLA для Azure SQL Database.

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

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

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

Непрерывное прайминг

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

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

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

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

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

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

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

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

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

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

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

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

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

³ В настоящее время параметры виртуальных ядер 160 и 192 являются предварительной версией.

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

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

* Для заданного размера вычислительных ресурсов и аппаратной конфигурации ограничения ресурсов одинаковы независимо от типа ЦП (Intel® Broadwell, Skylake, Ice Lake, Cascade Lake, Emerald Rapids или AMD Milan, Genoa). В динамическом представлении управления sys.dm_user_db_resource_governance создание оборудования для баз данных с помощью:

• Процессоры Intel® SP-8160 (Skylake) отображаются в качестве 6-го поколения
• Intel® 8272CL (Cascade Lake) отображается как Gen7
• Intel® Xeon® Platinum 8370C (Ice Lake) или AMD EPYC™ 7763v (Милан) появляются как Gen8
• AMD EPYC™ 9004 (Genoa) появляются как 9-го поколения или Intel® Xeon® Platinum 8573C (Изумрудные рапидс) появляются как 10-го поколения

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

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

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

Ограничения

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

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

• Часто задаваемые вопросы о гипермасштабировании
• Сравните модели приобретения Azure SQL Database на основе vCore и DTU
• Управление ресурсами в Azure SQL Database
• Ограничения ресурсов для отдельных баз данных с использованием модели приобретения виртуального ядра
• Сравнение функций: Azure SQL Database и Azure SQL Managed Instance
• Архитектура распределенных функций с гипермасштабированием
• Управление базой данных гипермасштабирования