Обзор операций управления в Управляемом экземпляре SQL Azure
Применимо к:
Управляемый экземпляр SQL Azure
Управляемый экземпляр SQL Azure поддерживает операции управления, которые можно использовать для автоматического развертывания новых управляемых экземпляров и удаления ненужных, а также обновления свойств управляемых экземпляров.
Что такое операции управления?
Все операции управления можно классифицировать следующим образом:
- Развертывание экземпляра (создание нового экземпляра).
- обновление экземпляра (изменение свойств экземпляра, например числа виртуальных ядер или зарезервированной емкости в хранилище);
- Удаление экземпляра
Для поддержки развертываний в виртуальных сетях Azure, а также для обеспечения изоляции и безопасности клиентов Управляемый экземпляр SQL использует виртуальные кластеры. Виртуальный кластер представляет выделенный набор изолированных виртуальных машин, развернутых в подсети виртуальной сети клиента и организованных в группах виртуальных машин. По сути, каждый управляемый экземпляр, развернутый в пустой подсети, приводит к созданию нового виртуального кластера, который создает первую группу виртуальных машин.
Последующие операции управления в управляемых экземплярах могут повлиять на базовые группы виртуальных машин. Изменения, влияющие на базовые группы виртуальных машин, могут повлиять на длительность операций управления, так как развертывание дополнительных виртуальных машин в виртуальном кластере связано с затратами, которые необходимо учитывать при планировании новых развертываний или обновлений существующих управляемых экземпляров.
Быстрая подготовка
Подсети с включенной волной функций ноября 2022 г. могут воспользоваться быстрой подготовкой Управляемый экземпляр SQL, что сокращает время, необходимое для создания первого экземпляра в подсети до 30 минут, в среднем от 45 до 60 минут.
Применяется только быстрая подготовка:
- в первом экземпляре, подготовленном в подсети.
- экземпляры с 4-8 виртуальными ядрами.
- экземпляры, использующие период обслуживания по умолчанию.
- экземпляры, развернутые в подсетях с включенной волной функций ноября 2022 г., которая включает как разработку, так и рабочие подписки.
- экземпляры, которые не являются избыточными по зонам.
Длительность
Длительность операций в виртуальном кластере может быть различной, но обычно она является наибольшей.
В следующей таблице перечислены действия, требующие много времени, которые можно выполнять в ходе операции создания, обновления или удаления. В таблице также приведены значения продолжительности, рассчитанные на основе существующих данных телеметрии служб.
| Этап | Description | Ожидаемая продолжительность |
|---|---|---|
| Создание виртуального кластера (быстрая подготовка)1 | Быстрая подготовка — это синхронный шаг в операциях управления экземплярами, при которых первая группа виртуальных машин мгновенно доступна. | 90% операций завершаются в течение 30 минут |
| Создание виртуального кластера | Создание — это синхронный шаг в операциях управления экземплярами, в ходе которых создается самая первая группа виртуальных машин. | 90% операций выполняются менее чем за 4 часа |
| Изменение размера виртуального кластера (расширение или сжатие) | Добавление новых компьютеров в существующую группу виртуальных машин, удаление неиспользуемых виртуальных машин, добавление или удаление всей группы виртуальных машин. Расширение выполняется синхронно, а сжатие — асинхронно (без какого-либо влияния на длительность операций управления экземпляром). | 90 % расширений кластера с созданием новой группы виртуальных машин завершается менее чем за 4 часа. 90% расширений кластера с расширением существующей группы виртуальных машин завершится в 60 минут. |
| Удаление виртуального кластера | Удаление виртуального кластера активируется при удалении самого последнего экземпляра из подсети. | 90 % операций удаления кластеров завершается через 1,5 часа |
| Начальные файлыбазы данных 2 | Синхронный этап, запускаемый при изменении масштаба вычислительных ресурсов (виртуальных ядер) или хранилища на уровне служб общего назначения, а также изменение уровня служб с "Общего назначения" на "Критически важный для бизнеса" (или наоборот). Длительность этой операции пропорциональна общему размеру базы данных, а также текущей активности базы данных (число активных транзакций). Операция базы данных при обновлении экземпляра может существенно повлиять на общую длительность. | 90 % этих операций выполняется со скоростью 220 ГБ/ч или больше |
1 Быстрая подготовка в настоящее время поддерживается только для первого экземпляра в подсети с 4 или 8 виртуальными ядрами и конфигурацией периода обслуживания по умолчанию.
2 При масштабировании вычислительных ресурсов (виртуальных ядер) или хранилища на уровне служб критически важный для бизнеса или переключении уровня служб с общего назначения на критически важный для бизнеса начальное значение также включает в себя начальную группу доступности AlwaysOn.
Внимание
Увеличение или уменьшение масштаба хранилища на уровне обслуживания "Общего назначения" предполагает обновление метаданных и заполнение ответа на отправленные запросы. Это быстрая операция, которая занимает до 5 минут без простоя и отработки отказа.
Длительные сегменты операций управления
В следующих таблицах перечислены операции и типичная общая длительность в зависимости от категории операции.
Категория: развертывание
| Операция | Длительные сегменты | Ожидаемая продолжительность |
|---|---|---|
| Первый экземпляр в пустой подсети1 | Создание виртуального кластера (быстрая подготовка) | 90% операций заканчиваются в течение 30 минут. |
| Первый экземпляр в пустой подсети | Создание виртуального кластера | 90% операций выполняются менее чем за 4 часа. |
| Первый экземпляр с другим периодом создания оборудования или периода обслуживания в непустой подсети (например, первый экземпляр серии Premium в подсети с экземплярами серии "Стандартный") | Добавление новой группы виртуальных машин в виртуальный кластер2 | 90% операций выполняются менее чем за 4 часа. |
| Создание последующих экземпляров в непустой подсети (второй, третий и т. д. экземпляр) | Изменение размера виртуального кластера | 90% операций заканчиваются в течение 60 минут. |
1 Быстрая подготовка в настоящее время поддерживается только для первого экземпляра в подсети с 4 или 8 виртуальными ядрами и конфигурацией периода обслуживания по умолчанию. 2 Отдельная группа виртуальных машин создается для каждой конфигурации оборудования и периода обслуживания.
Категория (обновление)
| Операция | Длительные сегменты | Ожидаемая продолжительность |
|---|---|---|
| Изменение свойства экземпляра (пароль администратора, имя входа Microsoft Entra, флаг Преимущество гибридного использования Azure) |
Н/П | До 1 минуты. |
| Масштабирование хранилища экземпляров вверх и вниз (общего назначения) |
Без длительного сегмента | 99 % операций завершается в течение 5 минут. |
| Масштабирование хранилища экземпляров вверх и вниз (критически важный для бизнеса) |
— Изменение размера виртуального кластера — Начальное заполнение групп доступности Always On |
90% операций заканчиваются в течение 60 минут и времени, чтобы заполнить все базы данных (220 ГБ/час). |
| Масштабирование хранилища экземпляров вверх и вниз (Общего назначения следующего поколения) |
— создание виртуального кластера или изменение размера группы виртуальных машин — Начальное заполнение групп доступности Always On |
90% операций завершаются менее чем за 4 часа (создание группы виртуальных машин) или 60 минут (изменение размера группы виртуальных машин) + время для заполнения всех баз данных (220 ГБ/час) + отработка отказа и очистка старого экземпляра |
| Масштабирование вычислений экземпляров (виртуальных ядер) вверх и вниз (общего назначения) |
— Изменение размера виртуального кластера | 90% операций заканчиваются в течение 60 минут. |
| Масштабирование вычислений экземпляров (виртуальных ядер) вверх и вниз (критически важный для бизнеса) |
— Изменение размера виртуального кластера — Начальное заполнение групп доступности Always On |
90% операций заканчиваются в течение 60 минут и времени, чтобы заполнить все базы данных (220 ГБ/час). |
| Масштабирование вычислений экземпляров (виртуальных ядер) вверх и вниз (Общего назначения следующего поколения) |
Создание виртуального кластера или изменение размера группы виртуальных машин — Начальное заполнение групп доступности Always On |
90% операций завершаются менее чем за 4 часа (создание группы виртуальных машин) или 60 минут (изменение размера группы виртуальных машин) + время для заполнения всех баз данных (220 ГБ/час) + отработка отказа и очистка старого экземпляра |
| Изменение уровня служб экземпляра (Общего назначения для критически важный для бизнеса и наоборот) |
— Изменение размера виртуального кластера — Начальное заполнение групп доступности Always On |
90% операций заканчиваются в течение 60 минут и времени, чтобы заполнить все базы данных (220 ГБ/час). |
| Изменение уровня служб экземпляра (Общего назначения или критически важный для бизнеса общего назначения следующего поколения и наоборот) |
Создание виртуального кластера или изменение размера группы виртуальных машин — Начальное заполнение групп доступности Always On |
90% операций завершаются менее чем за 4 часа (создание группы виртуальных машин) или 60 минут (изменение размера группы виртуальных машин) + время для заполнения всех баз данных (220 ГБ/час) + отработка отказа и очистка старого экземпляра |
| Изменение периода обслуживания или оборудования экземпляра (общего назначения) |
— размер виртуальногокластера 1 | 90 % операций выполняются менее чем за 4 часа (создание группы виртуальных машин) или 60 минут (изменение размера группы виртуальных машин). |
| Изменение периода обслуживания или оборудования экземпляра (критически важный для бизнеса) |
— размер виртуальногокластера 1 — Начальное заполнение групп доступности Always On |
90 % операций выполняются менее чем за 4 часа (создание группы виртуальных машин) или 60 минут (изменение размера группы виртуальных машин) и время для заполнения всех баз данных (220 ГБ/час). |
| Изменение периода обслуживания или оборудования экземпляра (Общего назначения следующего поколения) |
— создание виртуального кластера или изменение размера группы виртуальных машин — Начальное заполнение групп доступности Always On |
90% операций завершаются менее чем за 4 часа (создание группы виртуальных машин) или 60 минут (изменение размера группы виртуальных машин) + время для заполнения всех баз данных (220 ГБ/час) + отработка отказа и очистка старого экземпляра |
1 Управляемый экземпляр должен быть помещен в группу виртуальных машин с тем же соответствующим периодом оборудования и обслуживания. Если в виртуальном кластере нет такой группы, сначала необходимо создать новую для размещения конфигурации экземпляра.
Категория: Удаление
| Операция | Длительные сегменты | Ожидаемая продолжительность |
|---|---|---|
| Удаление экземпляра, не являющегося последним | Резервное копирование заключительного фрагмента журнала для всех баз данных | 90 % операций длится не более 1 минуты 1. |
| Удаление последнего экземпляра | — резервное копирование хвоста журнала для всех баз данных — Удаление виртуального кластера |
90 % операций завершается в течение 1,5 часа 2. |
1 Если в кластере несколько групп виртуальных машин, удаление последнего экземпляра в группе немедленно активирует удаление группы виртуальных машин асинхронно.
2 Удаление последнего экземпляра в подсети немедленно активирует удаление виртуального кластера синхронно.
Внимание
Как только активируется операция удаления, выставление счетов за Управляемый экземпляр SQL отключается. Длительность операции удаления не повлияет на выставление счетов.
Доступность экземпляра
Управляемый экземпляр SQL доступен во время операций обновления, за исключением короткого простоя, вызванного отработкой отказа, которая выполняется в конце обновления. Благодаря ускоренному восстановлению базы данных этот простой обычно длится до 10 секунд даже в случае прерывания длительных транзакций.
Примечание.
Масштабирование хранилища управляемого экземпляра общего назначения не приведет к сбою при завершении обновления.
Управляемый экземпляр недоступен для клиентских приложений во время операций развертывания и удаления.
Внимание
При выполнении длительных транзакций (импорт данных, задания обработки данных, перестроение индекса и т. д.) не рекомендуется масштабировать вычислительные ресурсы или хранилище Управляемого экземпляра SQL Azure, а также изменять уровень служб. Отработка отказа базы данных в конце операции отменяет все текущие транзакции.
Этапы операций управления
Операции управления состоят из нескольких этапов. С помощью предлагаемого API операций эти этапы можно предоставлять для подмножества операций (развертывание и обновление). Операция развертывания состоит из трех этапов, тогда как операция обновления выполняется за шесть этапов. Дополнительные сведения о длительности операций см. в разделе Длительность. Этапы перечислены в порядке выполнения.
Этапы развертывания управляемого экземпляра
| Имя шага | Описание шага |
|---|---|
| Проверка запроса | Отправленные параметры проверяются. В случае ошибки в конфигурации операция завершится сбоем. |
| Создание виртуального кластера или изменение его размера | В зависимости от состояния виртуального кластера кластер переходит в создание или изменение размера состояния. |
| Запуск нового экземпляра SQL | Процесс SQL запускается на развернутых виртуальных машинах. |
Этапы обновления управляемого экземпляра
| Имя шага | Описание шага |
|---|---|
| Проверка запроса | Отправленные параметры проверяются. В случае ошибки в конфигурации операция завершится сбоем. |
| Создание виртуального кластера или изменение его размера | В зависимости от состояния виртуального кластера кластер переходит в создание или изменение размера состояния. |
| Запуск нового экземпляра SQL | Процесс SQL запускается на развернутых виртуальных машинах. |
| Заполнение начальными значениями файлов базы данных или подключение файлов базы данных | В зависимости от типа операции обновления выполняется либо заполнение базы данных начальными значениями, либо подключение файлов базы данных. |
| Подготовка к отработке отказа и отработка отказа | После заполнения данных начальными значениями или повторного подключения файлов базы данных система подготавливается к отработке отказа. Если все настроено, то выполняется отработка отказа с коротким временем простоя. |
| Очистка старого экземпляра SQL | Удаление старого процесса SQL с виртуальных машин. |
Действия по удалению управляемого экземпляра
| Имя шага | Описание шага |
|---|---|
| Проверка запроса | Отправленные параметры проверяются. В случае ошибки в конфигурации операция завершится сбоем. |
| Очистка экземпляра SQL | Удаление процесса SQL с виртуальных машин. |
| Удаление виртуального кластера | В зависимости от того, является ли удаляемый экземпляр последним в подсети, виртуальный кластер синхронно удаляется на последнем шаге. |
Примечание.
В результате масштабирования экземпляров базовый виртуальный кластер подвергнется процессу освобождения неиспользуемой емкости и возможной дефрагментации емкости. Это может повлиять на экземпляры, не участвующие в операциях создания или масштабирования.
Перекрестное влияние операций управления
Операции управления с управляемым экземпляром могут повлиять на операции управления других экземпляров, размещенных в одной подсети:
Длительные операции восстановления в виртуальном кластере помещают другие операции в ту же группу виртуальных машин на удержание, например операции создания или масштабирования.
Пример. Если существует длительная операция восстановления, а также запрос масштабирования, требующий сжатия группы виртуальных машин, запрос сжатия займет больше времени, пока операция восстановления завершится, прежде чем она сможет продолжить.Следующая операция создания или масштабирования экземпляра помещается на удержание ранее инициированного экземпляра или масштабирования экземпляра, инициирующего изменение размера группы виртуальных машин.
Пример. Если в одной подсети есть несколько запросов на создание и масштабирование в одной группе виртуальных машин, а один из них инициирует изменение размера группы виртуальных машин, все запросы, отправленные через 5 и более минут после первоначального запроса операции, будут длиться дольше, чем ожидалось, так как эти запросы должны ожидать завершения изменения размера перед возобновлением.Операции создания и масштабирования, запрашиваемые в пределах 5-минутного периода, объединяются в пакеты и выполняются параллельно.
Пример: для всех операций, запрашиваемых в пределах 5-минутного периода, будет выполняться только одна операция изменения размера виртуального кластера (отсчитывается с момента выполнения запроса первой операции). Если с момента отправки первого запроса до момента отправки последующего прошло более 5 минут, этот следующий запрос будет выполнен только после изменения размера виртуального кластера.
Внимание
Операции управления, приостановленные из-за выполнения другой операции, будут автоматически возобновлены после выполнения условий для продолжения. Для возобновления временно приостановленных операций управления никаких действий со стороны пользователя не требуется.
Мониторинг операций управления
Сведения о мониторинге выполнения операций управления и их состояния см. в разделе Мониторинг операций управления в Управляемом экземпляре SQL Azure.
Отмена операций управления
Сведения о том, как отменить операцию управления, см. в разделе Отмена операций управления в Управляемом экземпляре SQL Azure.
Следующие шаги
- Сведения о создании первого управляемого экземпляра см. в этом руководстве по началу работы.
- Сведения о функциях и список сравнения см. в статье Сравнение функций: база данных SQL Azure и Управляемый экземпляр Azure SQL.
- Дополнительные сведения о конфигурации виртуальной сети см. в разделе Архитектура подключения к Управляемому экземпляру SQL Azure.
- Дополнительные сведения о группах виртуальных машин и виртуальном кластере см. в разделе "Архитектура виртуального кластера Управляемый экземпляр SQL"
- Сведения о создании управляемого экземпляра и восстановлении базы данных из файла резервной копии см. в разделе Краткое руководство. Создание управляемого экземпляра Управляемого экземпляра SQL.
- Сведения о миграции с помощью Azure Database Migration Service см. в разделе Руководство. Миграция из SQL Server в Управляемый экземпляр базы данных SQL Azure в автономном режиме с помощью DMS.
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по