Модель покупки на основе виртуальных ядер - Управляемый экземпляр Azure SQL

Область применения: Управляемый экземпляр SQL Azure

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

Обзор

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

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

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

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

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

Вычисления

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

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

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

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

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

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

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

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

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

• Восстановление на определенный момент времени (PITR): потребление хранилища зависит от скорости изменения базы данных и периода хранения, настроенного для резервного копирования. Вы можете настроить отдельный срок хранения для каждой базы данных на период от 1 до 35 дней в SQL Managed Instance. Объем хранилища резервных копий, равный настроенному максимальному размеру данных, предоставляется без дополнительной оплаты.
• Долгосрочное хранение (LTR): у вас есть возможность настроить долгосрочное хранение полных резервных копий до 10 лет. Выбранная конфигурация определяет, какой объем хранилища будет использоваться для резервных копий с долгосрочным хранением.

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

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

Управляемый экземпляр SQL Azure имеет два уровня служб:

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

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

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

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

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

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

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

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

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

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

Общего назначения следующего поколения

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

Уровень служб общего назначения next-gen — это обновление архитектуры существующего уровня служб общего назначения, которое предлагает следующие ключевые характеристики:

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

• Поддержка до 500 баз данных на экземпляр и максимальный размер хранилища размером 32 ТБ

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

• Использует Elastic SAN вместо страничных блобов, что значительно улучшает показатели производительности хранилища.

• 3 бесплатных IOPS на каждый ГБ зарезервированного хранилища

• Масштабируйте ресурсы экземпляра независимо, вручную настраивая виртуальные ядра (vCores), память, хранилище и операции ввода-вывода в секунду (IOPS), например, с помощью REST API для создания или обновления или ползунков на портале Azure.

  

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

Архитектурная модель

Уровень служб общего назначения следующего поколения — это обновление существующего уровня служб общего назначения, использующего обновленный уровень удаленного хранилища для хранения данных экземпляров и файлов журналов в Elastic SAN вместо страничных блобов. Это обновление обеспечивает более быструю задержку хранения, операций ввода-вывода в секунду и пропускную способность, чем существующий уровень служб общего назначения, с повышенными ограничениями на хранение, количеством виртуальных ядер и максимальным числом баз данных. Кроме того, так как квоты производительности совместно используются всем экземпляром, вам больше не нужно изменять размер отдельных файлов для повышения производительности. Базовая стоимость уровня обслуживания общего назначения следующего поколения совпадает с уровнем обслуживания общего назначения, но вы можете использовать ползунки для увеличения производительности ввода-вывода и отношения памяти к виртуальным ядрам, что будет выставлено отдельным счетом.

Уровень служб общего назначения next-gen поддерживает гибкую память, которая позволяет выбрать объем памяти, которую вы хотите выделить для вашего экземпляра. Это значительное улучшение уровня служб общего назначения, которое имеет фиксированное выделение памяти на основе количества выбранных виртуальных ядер. Гибкая память в настоящее время доступна локально избыточным экземплярам на оборудовании серии "Премиум".

Уровень обслуживания общего назначения следующего поколения помогает сократить затраты, предлагая бесплатные операции ввода-вывода в секунду: три операции на каждый гигабайт зарезервированного хранилища. Цена хранилища включает минимальное количество IOPS. Если вы превышаете минимальный предел, плата взимается следующим образом: 1 операция ввода-вывода в секунду = цена на хранилище (по регионам), деленная на три.

Например:

• Если 1 ГБ хранилища стоит 0,115, то 1 IOPS = 0,115/3 = 0,038 за IOPS.
• Экземпляр размером 1024 ГБ бесплатно получает 3072 операций ввода-вывода в секунду. Вы можете увеличить количество операций ввода-вывода в секунду до предела виртуальной машины за дополнительную плату.

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

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

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

• При той же базовой стоимости повышение производительности
• Улучшена задержка, пропускная способность и операции ввода-вывода в секунду
• Больше емкости хранилища
• Больше гибкости для вычислений
• Для одного экземпляра требуется более 100 баз данных
• Требуется более 16 ТБ зарезервированного хранилища

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

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

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

Процесс ядра СУБД SQL Server и базовые файлы MDF и LDF размещаются на одном узле с локально подключенным хранилищем SSD, что обеспечивает малую задержку рабочей нагрузки. Высокий уровень готовности реализуется с помощью технологии, аналогичной группам доступности Always On SQL Server.

Каждый экземпляр — это кластер узлов ядра СУБД, содержащих копии всех баз данных на экземпляре, с основной базой данных, доступной для рабочих нагрузок клиентов, и тремя вторичными базами данных, содержащими копии данных, готовые к переключению на резерв. Основной узел постоянно передает изменения на вторичные узлы, чтобы данные были доступны на вторичных репликах в случае отказа основного узла по какой-либо причине.

Отработку отказа выполняет ядро СУБД SQL Server — одна вторичная реплика становится основным узлом, и создается новая вторичная реплика, чтобы обеспечить достаточное количество узлов в кластере. Рабочая нагрузка автоматически перенаправляется на новый основной узел.

Кроме того, в кластере Business Critical есть встроенная функциональность Read Scale-Out, которая предоставляет бесплатную реплику только для чтения, используемую для выполнения запросов только для чтения (например, отчетов), которые не влияют на производительность рабочей нагрузки на вашей первичной реплике.

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

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

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

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

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

Высокий уровень доступности

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

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

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

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

В динамическом административном представлении sys.dm_user_db_resource_governance поколение оборудования для экземпляров, использующих процессоры Intel® SP-8160 (Skylake), отображается как Gen6, а поколение оборудования для экземпляров, использующих процессоры Intel® 8272CL (Cascade Lake), отображается как Gen7. Процессоры Intel® 8370C (Ice Lake), используемые в премиальной серии и серии, оптимизированной по памяти, отображаются как Gen8. Ограничения ресурсов для всех экземпляров серии Standard (поколение Gen5) одинаковы, независимо от типа процессора (Broadwell, Skylake или Cascade Lake).

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

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

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

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

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

Изменение оборудования существующего Управляемого экземпляра SQL

Set-AzSqlInstance -Name "managedinstance1" -ResourceGroupName "ResourceGroup01" -ComputeGeneration Gen5

az sql mi update -g mygroup -n myinstance --family Gen5

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

Имена SKU

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

Серия Standard (поколение Gen5) и серия Premium

Оборудование серии "Стандартный" (5-го поколения) и "Премиум" доступно во всех общедоступных регионах по всему миру.

Оптимизированное для памяти оборудование ценовой категории "Премиум" находится в предварительной версии и имеет ограниченную региональную доступность. Дополнительные сведения см. в разделе ограничения ресурсов Управляемого экземпляра Azure SQL.

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

• Создание Управляемого экземпляра SQL с помощью портала Azure
• Страница ценообразования для одного экземпляра SQL Managed Instance в Azure
• Страница с ценами на пул управляемых экземпляров SQL Azure
• Ограничения ресурсов на основе виртуальных ядер для управляемого экземпляра SQL Azure