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

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

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

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

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

Предлагаются две модели архитектуры высокого уровня доступности.

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

База данных SQL и управляемый экземпляр SQL выполняются в новейшей стабильной версии ядра СУБД SQL Server и операционной системы Windows, при этом большинство пользователей не заметят, что обновления выполняются непрерывно.

Доступность уровня служб категорий "Базовый", "Стандартный" и "Общего назначения" с локальной избыточностью

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

Разделение уровней вычисления и хранения

Стандартная модель доступности предусматривает два уровня, описанных ниже.

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

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

Доступность с избыточностью в пределах зоны для уровня служб общего назначения

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

Конфигурация с избыточностью между зонами для уровня общего назначения состоит из двух уровней:

  • Уровень данных с отслеживанием состояния, где файлы базы данных (.mdf/.ldf) хранятся в ZRS (хранилище, избыточное в пределах зоны). При использовании ZRS файлы данных и журналов синхронно копируются в три физически изолированные зоны доступности Azure.
  • Уровень вычислений без отслеживания состояния, который запускает процесс sqlservr.exe и содержит только временные и кэшированные данные, такие как TempDB, шаблоны базы данных на подключенном SSD, а также кэш планов, буферный пул и пул columnstore в памяти. Этим узлом без отслеживания состояния управляет платформа Azure Service Fabric, которая инициализирует sqlservr.exe, контролирует работоспособность узла и, при необходимости, выполняет переход на другой ресурс. Для бессерверных и подготовленных между зонами баз данных общего назначения узлы с запасной емкостью легко доступны в других Зоны доступности для отработки отказа.

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

Конфигурация с избыточностью между зонами для общего назначения

Важно!

Для общего назначения уровень конфигурации, избыточной между зонами, является общедоступной в следующих регионах: Западная Европа, Северная Европа, Западная часть США 2 и Центральная Франция. Эта возможность доступна в предварительной версии в следующих регионах: восточная часть США, Восточная часть США 2, Юго-Восточная Азия, Восточная Австралия, Восточная Япония и южная часть Соединенного Королевства.

Примечание

Конфигурация с избыточностью между зонами не поддерживается для Управляемых экземпляров SQL. В Базе данных SQL эта возможность доступна только в том случае, если выбрано оборудование 5-го поколения.

Доступность уровня служб категорий "Премиум" и "Критически важный для бизнеса" с локальной избыточностью

Уровни служб "Премиум" и "критически важный для бизнеса" используют модель доступности категории "Премиум", которая объединяет вычислительные ресурсы (процесс sqlservr.exe) и хранилище (локально подключенный SSD) на одном узле. Высокий уровень доступности достигается путем репликации вычислений и хранилища на дополнительные узлы с созданием кластера из трех-четырех узлов.

Кластер узлов ядра СУБД

Файлы базы данных (.mdf/.ldf) помещаются в подключенное хранилище SSD, чтобы обеспечить очень низкую задержку операций ввода-вывода для рабочей нагрузки. Высокий уровень доступности реализуется с помощью технологии, аналогичной группам доступности Always On SQL Server. В кластер входит одна первичная реплика, доступная для операций чтения и записи клиентов, а также до трех вторичных реплик (вычисления и хранение), содержащих копии данных. Основной узел постоянно передает изменения на вторичные узлы в определенном порядке и гарантирует сохранение данных по крайней мере на одной вторичной реплике перед фиксацией каждой транзакции. Этот процесс гарантирует, что при аварийном завершении работы основного узла по какой-либо причине всегда существует полностью синхронизированный узел для отработки отказа. Отработку отказа инициирует Azure Service Fabric. После того как вторичная реплика станет новым основным узлом, создается другая вторичная реплика, чтобы обеспечить наличие достаточного количества узлов кластера (набор кворума). По завершении отработки отказа подключения Azure SQL автоматически перенаправляются на новый основной узел.

Как дополнительное преимущество, модель доступности категории "Премиум" имеет возможность перенаправлять подключения Azure SQL только для чтения на одну из вторичных реплик. Эта функция с названием Горизонтальное увеличение масштаба для чтения без дополнительной платы обеспечивает 100 % дополнительной емкости вычислительных ресурсов, чтобы выгрузить операции только для чтения, например аналитические рабочие нагрузки, из первичной реплики.

Доступность уровня служб категорий "Премиум" и "Критически важный для бизнеса" с избыточностью

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

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

Важно!

Эта функция недоступна в управляемом экземпляре SQL. Если для Базы данных SQL используется уровень служб "Критически важный для бизнеса", конфигурация с избыточностью между зонами будет доступна только при выборе оборудования 5-го поколения. Актуальные сведения о том, в каких регионах поддерживаются базы данных с избыточностью между зонами, см. в разделе Поддержка служб по регионам.

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

Архитектура с высоким уровнем доступности и избыточностью в пределах зоны

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

В настоящее время архитектура уровня служб "Гипермасштабирование", описанная в статье Архитектура распределенных функций, доступна только для Базы данных SQL Microsoft Azure, но не для управляемого экземпляра SQL.

Функциональная архитектура уровня служб

Модель доступности в "Гипермасштабировании" содержит четыре уровня, которые описаны ниже.

  • Уровень вычислений без отслеживания состояния, который запускает процесс sqlservr.exe и содержит только временные и кэшированные данные, такие как неохватывающий кэш RBPEX, TempDB, шаблоны базы данных и прочее на подключенном SSD, а также кэш планов, буферный пул и пул columnstore в памяти. Этот уровень без отслеживания состояния содержит основную реплику вычислений и, при необходимости, некоторое количество вторичных реплик, которые можно использовать в качестве целевых объектов отработки отказа.
  • Уровень хранилища без отслеживания состояния, сформированный серверами страниц. Этот уровень представляет собой распределенную подсистему хранилища для процессов sqlservr.exe, выполняющихся в репликах вычислений. Каждый сервер страниц содержит только временные и кэшированные данные, например охватывающий кэш RBPEX на подключенном SSD и страницы данных, кэшированные в памяти. На каждом сервере страниц имеется парный сервер страниц в конфигурации "активный-активный" для обеспечения балансировки нагрузки, избыточности и высокого уровня доступности.
  • Уровень хранения журнала транзакций с отслеживанием состояния представлен отдельным вычислительным узлом, на котором выполняется процесс службы журнала и к которому подключена целевая зона журнала транзакций и долгосрочное хранилище для журнала транзакций. Целевая зона и долгосрочное хранилище используют службу хранилища Microsoft Azure, которая обеспечивает избыточность и доступность для журнала транзакций, гарантируя устойчивость данных о зафиксированных транзакциях.
  • Уровень хранилища данных с отслеживанием состояния с файлами базы данных (.mdf/.ndf), которые хранятся в службе хранилища Microsoft Azure и обновляются серверами страниц. Этот уровень применяет функции доступности и избыточности данных службы хранилища Microsoft Azure. Это гарантирует сохранение каждой страницы в файле данных даже в случаях аварийного завершения процессов на других уровнях архитектуры "Гипермасштабирование" или сбоя вычислительных узлов.

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

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

Доступность избыточности между зонами служб с гипермасштабированием

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

Необходимо учитывать следующие ограничения.

  • Конфигурация с избыточностью между зонами может быть указана только при создании базы данных. Этот параметр нельзя изменить после подготовки ресурса к работе. Используйте копирование базы данных, восстановление на момент времени или создайте геореплику, чтобы обновить конфигурацию избыточности между зонами для существующей базы данных гипермасштабирования. При использовании одного из этих вариантов обновления, если целевая база данных находится в регионе, отличном от региона источника или если избыточность хранилища резервных копий базы данных у целевой базы данных отличается от базы данных-источника, операция копирования будет охватывать все данные.
  • Поддерживается только оборудование 5-го поколения.
  • Именованные реплики в настоящее время не поддерживаются.
  • Избыточность между зонами сейчас не может быть указана при переносе существующей базы данных с другого уровня служб Базы данных SQL Azure на уровень служб "Гипермасштабирование".

Важно!

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

Создание базы данных гипермасштабирования с избыточностью между зонами

Используйте Azure PowerShell или Azure CLI, чтобы создать базу данных гипермасштабирования с избыточностью между зонами. Убедитесь, что у вас установлена последняя версия API, чтобы обеспечить поддержку последних изменений.

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

Чтобы включить избыточность зоны с помощью Azure PowerShell, используйте следующую команду:

New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01" `
    -Edition "Hyperscale" -HighAvailabilityReplicaCount 1 -ZoneRedundant -BackupStorageRedundancy Zone -RequestedServiceObjectiveName HS_Gen5_2'

Создание базы данных гипермасштабирования с избыточностью между зонами путем создания геореплики

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

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

Чтобы создать базу данных с избыточностью между зонами с помощью Azure PowerShell, используйте следующий пример команды:

New-AzSqlDatabaseSecondary -ResourceGroupName "myResourceGroup" -ServerName $sourceserver -DatabaseName "databaseName" -PartnerResourceGroupName "myPartnerResourceGroup" -PartnerServerName $targetserver -PartnerDatabaseName "zoneRedundantCopyOfMySampleDatabase” -ZoneRedundant -BackupStorageRedundancy Zone -HighAvailabilityReplicaCount 1

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

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

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

Чтобы создать базу данных с избыточностью между зонами с помощью Azure PowerShell, используйте следующий пример команды:

New-AzSqlDatabaseCopy -ResourceGroupName "myResourceGroup" -ServerName $sourceserver -DatabaseName "databaseName" -CopyResourceGroupName "myCopyResourceGroup" -CopyServerName $copyserver -CopyDatabaseName "zoneRedundantCopyOfMySampleDatabase” -ZoneRedundant -BackupStorageRedundancy Zone 

Доступность избыточности между зонами базы данных Master

В Azure SQL Базе данных сервер — это логическая конструкция, которая выступает в качестве центральной административной точки для коллекции баз данных. На уровне сервера можно администрировать имена входа, проверку подлинности Azure Active Directory, правила брандмауэра, правила аудита, политики обнаружения угроз и группы автоматической отработки отказа. Данные, связанные с некоторыми из этих функций, такими как имена входа и правила брандмауэра, хранятся в базе данных master. Аналогичным образом данные для некоторых динамических административных представлений, например sys.resource_stats, также хранятся в базе данных master.

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

Если ни одна из баз данных на сервере не является избыточной между зонами или при создании пустого сервера, то база данных master, связанная с сервером, не является избыточной между зонами.

Для проверки ZoneRedundant свойства базы данных master можно использовать Azure PowerShell или Azure CLI или REST API:

Используйте следующую команду, чтобы проверить значение свойства ZoneRedundant для базы данных master.

Get-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "myServerName" -DatabaseName "master"

Ускоренное восстановление базы данных (ADR)

Ускоренное восстановление баз данных (ADR) — это новая функция ядра СУБД, которая значительно повышает доступность баз данных, особенно при наличии длительных транзакций. В настоящее время функция ADR доступна для базы данных SQL Azure, Управляемого экземпляра SQL Azure и службы Azure Synapse Analytics.

Тестирование отказоустойчивости приложений

Высокий уровень доступности — это фундаментальная часть Базы данных SQL и платформы Управляемого экземпляра SQL, которая прозрачно работает для приложения базы данных. Однако мы понимаем, что может потребоваться проверить, как операции автоматического перехода на другой ресурс, инициированные во время запланированных или незапланированных событий, повлияют на приложение перед развертыванием его в рабочей среде. Отработку отказа можно запустить вручную путем вызова API-интерфейса для перезапуска базы данных, эластичного пула или управляемого экземпляра. Такой вызов API в бессерверной или подготовленной базе данных или эластичном пуле с уровнем служб "общего назначения" и избыточностью между зонами приведет к перенаправлению клиентских подключений на новый основной сервер в зоне доступности, отличной от зоны доступности старого основного сервера. Таким образом, помимо тестирования того, как отработка отказа влияет на существующие сеансы базы данных, можно также проверить, изменяются ли они вследствие изменений задержки в сети. Поскольку операция перезапуска влияет на режим работы, и большое количество таких операций создает нагрузку на платформу, разрешается выполнять только один вызов отработки отказа каждые 15 минут для каждой базы данных, эластичного пула или управляемого экземпляра.

Отработку отказа можно инициировать с помощью PowerShell, REST API или Azure CLI.

Тип развертывания PowerShell REST API Azure CLI
База данных Invoke-AzSqlDatabaseFailover Отработка отказа базы данных az rest может использоваться для вызова REST API из Azure CLI
Эластичный пул Invoke-AzSqlElasticPoolFailover Отработка отказа эластичного пула az rest может использоваться для вызова REST API из Azure CLI
Базы данных SQL Invoke-AzSqlInstanceFailover Отработка отказа для управляемых экземпляров az sql mi failover может использоваться для вызова REST API из Azure CLI

Важно!

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

Заключение

База данных SQL Azure и Управляемый экземпляр Azure SQL — это встроенное решение с высоким уровнем доступности, тесно интегрированное с платформой Azure. Это решение обращается к возможностям Service Fabric для обнаружения сбоев и восстановления, хранилищу BLOB-объектов Azure для защиты данных, а к зонам доступности для повышения отказоустойчивости (как упоминалось ранее в документе, который еще неприменим к Управляемому экземпляру SQL Azure). Кроме того, База данных SQL Microsoft Azure и Управляемый экземпляр SQL используют технологию групп доступности Always On на основе экземпляра SQL Server для репликации и отработки отказа. Сочетание этих технологий позволяет приложениям полностью реализовывать преимущества смешанной модели хранения и поддерживать Соглашения об уровне обслуживания с наивысшими требованиями.

Дальнейшие шаги