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

Обзор операций управления в Управляемом экземпляре SQL Azure

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

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

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

Что такое операции управления?

Управление управляемым экземпляром SQL Azure включает следующие операции:

  • Создание: операции, возникающие при первом создании управляемого экземпляра SQL. Это включает создание базовой группы виртуальных машин и развертывание процесса ядра СУБД SQL.
  • Обновление. Операции, возникающие при изменении свойств существующего управляемого экземпляра SQL, таких как масштабирование вычислений или хранилища, изменение уровня служб или обновление конфигурации экземпляра. Обновление часто включает изменение размера группы виртуальных машин, инициализацию данных, а затем отказоустойчивое переключение на новый процесс SQL Database Engine.
  • Удаление. Операции, возникающие при удалении существующего управляемого экземпляра SQL, включая очистку ресурсов, таких как группа виртуальных машин, связанная с экземпляром.

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

Операции управления управляемым экземпляром SQL выполняются с помощью следующих базовых процессов:

  • Операции группы виртуальных машин: операции, связанные с созданием и управлением базовой группой виртуальных машин, включающей управляемый экземпляр SQL. Это включает изменение размера группы виртуальных машин, создание групп виртуальных машин и управление виртуальными машинами в этих группах.
  • Посев: Инициализация и синхронизация данных между процессами ядра SQL Database Engine, обычно для подготовки к переключению на резервную систему.
  • Отказоустойчивость: операции по переносу трафика на другой процесс SQL Database Engine, либо в той же, либо в новой группе виртуальных машин.

Операции группы виртуальных машин

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

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

Подробные сведения об архитектуре виртуального кластера см. в разделе "Архитектура виртуального кластера".

Посев

Посев играет критическую роль в работе Управляемого экземпляра SQL Azure, особенно во время настройки и репликации баз данных. Инициализация — это процесс, который инициализирует и синхронизирует данные во всех процессах SQL Database Engine, представляя собой особенно важную часть управления экземплярами. Хотя это часто самый трудоемкий шаг в продолжительных и успешных операциях, заполнение служит краеугольным камнем в создании здоровой и функциональной среды для управляемого экземпляра SQL.

Для предполагаемой продолжительности операций посева см. продолжительность операций управления.

Процесс посева обычно включает следующие этапы, независимо от уровня предоставляемых услуг:

  • Инициализация: система определяет исходную и целевую базу данных и запускает ряд задач, которые подготавливают процессы ядра СУБД SQL для передачи данных.
  • Передача данных. Фактические пакеты данных передаются из источника в целевой процесс ядра СУБД SQL, который включает полную или частичную копию базы данных в зависимости от сценария.
  • Синхронизация. После завершения первоначальной передачи данных система синхронизирует любые последующие обновления или изменения с помощью репликации блоков журнала транзакций, чтобы обеспечить целостность данных.
  • Проверка и завершение: Процесс завершен, а целевой процесс SQL Server Database Engine проверяется, чтобы подтвердить успешную репликацию и заполнение. Отработка отказа происходит таким образом, чтобы трафик был направлен на новый процесс обработки SQL сервера.

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

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

Зависит от того, будет ли произведена инициализация данных, от конкретного сценария и уровня обслуживания, например:

  • Уровни служб общего назначения и общего назначения следующего поколения:
    • Переход на уровень служб "Критически важный для бизнеса " — данные должны передаваться из удаленного хранилища в локальное хранилище, используемое на уровне служб общего назначения.
    • Включение или отключение избыточности зоны — данные должны быть скопированы в избыточные зоны или из нее.
  • Уровень служб "Критически важный для бизнеса" :
    • Масштабирование хранилища. Так как хранилище физически подключено к локальному компьютеру, каждое изменение хранилища требует создания новой группы виртуальных машин, поэтому данные должны быть переданы с старого компьютера на новый компьютер (на всех 4 репликах).
    • Масштабирование виртуальных ядер. Для каждой операции масштабирования вычислений требуется создать новую группу виртуальных машин, поэтому данные должны быть скопированы с старого компьютера на новый компьютер (на всех 4 репликах).
    • Смена оборудования или временного окна для обслуживания: Если группа виртуальных машин уже существует в подсети с соответствующей конфигурацией, эта группа виртуальных машин изменяется. Если это новая конфигурация, создается новая группа виртуальных машин. Данные должны быть скопированы из старой группы виртуальных машин в новую группу виртуальных машин (на всех 4 репликах).
    • Изменение уровня служб. Данные должны быть скопированы из локального хранилища в удаленное хранилище, используемое на уровне служб общего назначения.
    • Включение или отключение избыточности зоны — данные должны быть скопированы в избыточные зоны или из нее.

Скорость сеяния

Следующие факторы влияют на продолжительность процесса посева:

  • Размер базы данных: для передачи данных и синхронизации между процессами ядра СУБД SQL требуется больше времени.
  • Зависимости сети: пропускная способность сети и задержка могут значительно влиять на скорость заполнения.
  • Операции резервного копирования и восстановления. Текущие операции резервного копирования в исходном процессе ядра СУБД SQL могут повлиять на подготовку данных для отправки в другой процесс ядра СУБД SQL.
  • Рабочая нагрузка экземпляра: нагрузка экземпляра во время заполнения может вызвать дросселирование и значительно продлить процесс.

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

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

Для предполагаемой продолжительности операций посева см. продолжительность операций управления.

Инфраструктура Azure и уведомления

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

Переключение на резервную систему

Отказоустойчивость экземпляра происходит, когда трафик перенаправляется от старого процесса движка базы данных SQL к новому процессу движка базы данных SQL в узлах группы виртуальных машин, которая включает управляемый экземпляр SQL. Переключение на резерв является важной частью большинства операций управления, особенно при обновлении экземпляра. Короткий момент разрывов подключений во время перенаправления трафика в новый процесс SQL Database Engine называется переход на резерв.

Экземпляр недоступен только во время переключения на резерв, когда трафик перенаправляется в новый процесс SQL. На уровне служб "Критически важный для бизнеса " экземпляр недоступен до 20 секунд, в то время как на уровне служб общего назначения экземпляр может быть недоступен до 2 минут. Все операции серверной части, которые выполняются для подготовки к переключению на резерв вследствие операции управления, например повторная инициализация баз данных на уровне Business Critical службы, происходят в фоновом режиме и не влияют на доступность экземпляра.

Различия в архитектуре между уровнями служб подробно описаны в доступности.

Перекрестное влияние операций управления

Операции управления в управляемом экземпляре SQL могут повлиять на операции управления других экземпляров, размещенных в той же подсети:

  • Длительные операции восстановления в виртуальном кластере приостанавливают другие операции в этом виртуальном кластере, такие как операции создания или масштабирования.

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

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

    Пример: Если в одной подсети есть несколько запросов на создание и (или) масштабирование в одной группе виртуальных машин, а один из них инициирует изменение размера группы виртуальных машин, все запросы, отправленные через 5+ минут после первоначального запроса операции, длившегося дольше, чем ожидалось, так как эти запросы должны ожидать завершения изменения размера перед возобновлением.

  • Операции создания и масштабирования, отправленные в 1-минутном окне, выполняются параллельно.

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

Внимание

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

Мониторинг операций управления

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

Отмена операций управления

Сведения об отмене операции управления см. в статье Отмена операций управления управляемым экземпляром SQL Azure.

Связанное содержимое