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

  • Статья

Применимо к:База данных SQL Azure

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

Обзор

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

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

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

Существует три модели архитектуры высокого уровня доступности:

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

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

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

Уровень служб Модель высокой доступности локальная избыточность доступности Доступность с избыточностью между зонами
Общего назначения (виртуальные ядра) Удаленное хранилище Да Да
критически важный для бизнеса (vCore) Локальное хранилище Да Да
Гипермасштабирование (виртуальные ядра) Гипермасштабирование Да Да
Базовый (DTU) Удаленное хранилище Да Нет
Standard (DTU) Удаленное хранилище Да Нет
Премиум (DTU) Локальное хранилище Да Да

Локально избыточность доступности

Локально избыточный уровень доступности основан на хранении базы данных в локально избыточном хранилище (LRS), которое копирует данные три раза в одном центре обработки данных в основном регионе и защищает данные в случае локального сбоя, таких как небольшая сеть или сбой питания. LRS стоит меньше всего и обеспечивает самый низкий уровень избыточности по сравнению с другими вариантами репликации. Если в регионе происходит крупномасштабная катастрофа, например пожар или наводнение, все реплика учетной записи хранения с помощью LRS могут быть потеряны или неустранимы. Таким образом, чтобы обеспечить дополнительную защиту данных при использовании локально избыточного варианта доступности, рекомендуется использовать более устойчивый вариант хранилища для резервных копий базы данных. Это не относится к базам данных гипермасштабирования, где одно и то же хранилище используется как для файлов данных, так и для резервных копий.

Локальная избыточность доступности доступна всем базам данных на всех уровнях служб и целевой точке восстановления (RPO), что указывает, что объем потери данных равен нулю.

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

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

Схема разделения вычислительных ресурсов и хранилища.

Модель доступности удаленного хранилища включает два уровня:

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

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

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

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

Схема кластера узлов ядра СУБД.

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

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

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

Архитектура уровня служб Гипермасштабирования описана в архитектуре распределенных функций.

Схема с функциональной архитектурой гипермасштабирования.

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

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

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

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

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

Доступность с избыточностью между зонами гарантирует, что данные распределяется по трем зонам доступности Azure в основном регионе. Каждая зона доступности — это отдельное физическое расположение с независимым питанием, охлаждением и сетью.

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

Уровень служб "Общего назначения"

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

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

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

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

Схема конфигурации избыточности между зонами для общего назначения.

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

  • Для уровня общего назначения конфигурация с избыточностью между зонами общедоступна в следующих регионах:
    • Северная часть ЮАР (Африка)
    • "Восточная Австралия" (Азиатско-Тихоокеанский регион);
    • (Азиатско-Тихоокеанский регион) Восточная Азия
    • (Азиатско-Тихоокеанский регион) Восточная Япония
    • (Азиатско-Тихоокеанский регион) Республика Корея, центральный регион
    • Юго-Восточная Азия (Азиатско-Тихоокеанский регион)
    • "Центральная Индия" (Азиатско-Тихоокеанский регион);
    • (Азиатско-Тихоокеанский регион) Китай Северная 3
    • (Азиатско-Тихоокеанский регион) Север ОАЭ
    • (Европа) Центральная Франция
    • Центрально-Западная Германия (Европа)
    • (Европа) Италия Север
    • "Северная Европа" (Европа);
    • Восточная Норвегия (Европа)
    • (Европа) Центральная Польша
    • "Западная Европа" (Европа).
    • (Европа) Южная часть Соединенного Королевства
    • Северная Швейцария (Европа)
    • (Европа) Центральная Швеция;
    • (Ближний Восток) Центральная Израиль
    • (Ближний Восток) Центральный Катар
    • (Северная Америка) Центральная Канада;
    • (Северная Америка) Восточная часть США;
    • (Северная Америка) Восточная часть США 2;
    • (Северная Америка) Центрально-южная часть США;
    • (Северная Америка) Западная часть США 2;
    • (Северная Америка) Западная часть США 3;
    • Южная Бразилия (Южная Америка)
  • Для доступности, избыточной между зонами, выбор периода обслуживания, отличного от стандартного, в настоящее время доступен в выборе регионов.
  • Конфигурация с избыточностью между зонами доступна только в База данных SQL при выборе оборудования стандартной серии (5-го поколения).
  • Избыточность между зонами недоступна для уровней служб "Базовый" и "Стандартный" в модели приобретения DTU.

Уровни служб "Премиум" и критически важный для бизнеса

Если для уровня служб "Премиум" или критически важный для бизнеса включена избыточность зоны, реплика помещаются в разные зоны доступности в одном регионе. Чтобы исключить единую точку сбоя, круг управления также дублируется в нескольких зонах в виде трех кругов шлюзов. Маршрутизация в определенное кольцо шлюза контролируется Диспетчер трафика Azure. Так как конфигурация с избыточностью между зонами в уровнях служб Premium или критически важный для бизнеса использует существующие реплика для размещения в разных зонах доступности, вы можете включить ее без дополнительных затрат. Выбрав конфигурацию с избыточностью между зонами, вы можете сделать базы данных premium или критически важный для бизнеса и эластичные пулы устойчивыми к гораздо большему набору сбоев, включая катастрофические сбои центра обработки данных без каких-либо изменений в логике приложения. Вы также можете преобразовать существующие базы данных класса Premium или критически важный для бизнеса или эластичные пулы в конфигурацию, избыточной между зонами.

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

Схема архитектуры высокой доступности, избыточной между зонами.

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

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

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

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

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

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

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

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

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

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

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

  • В настоящее время нет возможности указать избыточность зоны при переносе базы данных в гипермасштабирование с помощью портал Azure. Однако избыточность зоны можно указать с помощью Azure PowerShell, Azure CLI или REST API при переносе существующей базы данных из другого уровня служб База данных SQL Azure в гипермасштабирование. Ниже приведен пример с Помощью Azure CLI:

    az sql db update --resource-group "myRG" --server "myServer" --name "myDB" --edition Hyperscale --zone-redundant true

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

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

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

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

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

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

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

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

Проверка устойчивости приложений к сбоям

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

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

Отработку отказа можно инициировать с помощью 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 Azure предоставляет встроенное решение высокого уровня доступности, которое глубоко интегрировано с платформой Azure. Он зависит от Service Fabric для обнаружения сбоев и восстановления, в хранилище BLOB-объектов Azure для защиты данных и на Зоны доступности для повышения отказоустойчивости. Кроме того, База данных SQL использует технологию группы доступности AlwaysOn из SQL Server для синхронизации данных и отработки отказа. Сочетание этих технологий позволяет приложениям полностью реализовать преимущества смешанной модели хранения и поддерживать наиболее требовательные соглашения об уровне обслуживания.

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