Доступность с помощью избыточности — База данных SQL Azure

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

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

Обзор

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

По умолчанию База данных SQL Azure обеспечивает доступность с помощью локальной избыточности, что делает базу данных доступной во время:

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

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

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

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

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

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

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

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

Доступность через локальную избыточность

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

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

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

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

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

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

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

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

Уровень служб уровня "Премиум" модели приобретения на основе DTU и уровня служб критически важный для бизнеса модели приобретения на основе виртуальных ядер использует модель доступности локального хранилища, которая интегрирует вычислительные ресурсы (процесс ядра СУБД) и хранилище (локально подключенное 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, а также tempdb model кэш плана, буферный пул и пул columnstore в памяти. Этим узлом без отслеживания состояния управляет платформа Azure Service Fabric, которая инициализирует sqlservr.exe, контролирует работоспособность узла и, при необходимости, выполняет переход на другой ресурс. Для бессерверных и подготовленных баз данных общего назначения узлы с запасной емкостью легко доступны в других Зоны доступности для отработки отказа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• В настоящее время нет возможности указать избыточность зоны при переносе базы данных в гипермасштабирование с помощью портал 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 не является избыточной между зонами.

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

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

az sql db show --resource-group "myResourceGroup" --server "myServerName" --name master

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

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

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

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

Заключение

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

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

Дополнительные сведения см. в следующих статьях:

• Зоны доступности Azure
• Service Fabric
• Диспетчер трафика Azure
• Обзор обеспечения непрерывности бизнес-процессов с помощью Базы данных SQL Azure