Обеспечение доступности за счет избыточности — Azure SQL Database

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

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

Overview

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

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

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

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

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

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

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

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

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

Дополнительную информацию о соглашениях об уровне обслуживания для различных уровней служб можно найти в разделе SLA для Azure SQL Database.

Обеспечение доступности за счёт локальной избыточности

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

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

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

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

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

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

• Уровень вычислений без сохранения состояния, который запускает процесс базы данных и содержит только временные и кэшированные данные, такие как базы данных tempdb и model на подключенном SSD, а также кэш плана, буферный пул и пул columnstore в памяти. Этот бестранзакционный узел управляется Azure Service Fabric, который инициализирует ядро базы данных, контролирует работоспособность узла и выполняет переключение на другой узел при необходимости.

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

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

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

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

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

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

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

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

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

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

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

• Уровень хранения журнала транзакций с отслеживанием состояния, формируемый вычислительным узлом, который управляет процессом службы журнала, зоной приземления журнала транзакций и долгосрочным хранилищем для журналов транзакций. Целевая зона и долгосрочное хранилище используют службу хранилища Microsoft Azure, которая обеспечивает избыточность и доступность для журнала транзакций, гарантируя устойчивость данных о зафиксированных транзакциях.

• Уровень хранилища данных с отслеживанием состояния с файлами базы данных (.mdf/.ndf), которые хранятся в службе хранилища Microsoft Azure и обновляются серверами страниц. Этот уровень применяет функции доступности и избыточности данных службы хранилища Microsoft Azure. Это гарантирует сохранение каждой страницы в файле данных даже в случаях аварийного завершения процессов на других уровнях архитектуры "Гипермасштабирование" или сбоя вычислительных узлов.

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

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

Высокая доступность благодаря зональной избыточности

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

Доступность с избыточностью между зонами доступна для баз данных на уровнях критически важные для бизнеса, общего назначения и гипермасштабирования модели приобретения на основе vCore, и только на уровне 'Премиум' модели приобретения на основе DTU, в то время как уровни 'Базовый' и 'Стандартный' не поддерживают избыточность по зонам.

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

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

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

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

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

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

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

Двухзонный регион	Трехзонный регион

• При подготовке вычислений в двух зонах доступности:

  • Резервное копирование и хранилище по-прежнему синхронизируются между тремя зонами доступности в регионе.
  • Хранилище, избыточное между зонами, как всегда, синхронизируется между тремя зонами доступности.

• При подготовке вычислительных ресурсов в трех зонах доступности:

  • Резервное копирование и хранилище синхронизируются между тремя зонами доступности в регионе.

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

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

• Избыточность между зонами недоступна для уровней служб "Базовый" и "Стандартный" в модели приобретения DTU.

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

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

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

Двухзонный регион	Трехзонный регион

• При подготовке вычислений в двух зонах доступности:

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

• При подготовке вычислительных ресурсов в трех зонах доступности:

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

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

• Все регионы Azure, которые поддерживают зоны доступности, поддерживают избыточные базы данных уровня "Премиум" и бизнес-критические.
• Для повышения отказоустойчивости между зонами, возможность выбора периода обслуживания, отличного от стандартного, в настоящее время доступна в некоторых регионах. Для получения дополнительной информации см. раздел «Доступность окна обслуживания по регионам для базы данных Azure SQL».

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

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

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

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

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

Двухзонный регион	Трехзонный регион

• При подготовке вычислений в двух зонах доступности:

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

• При подготовке вычислительных ресурсов в трех зонах доступности:

  • Резервное копирование и хранилище синхронизируются между тремя зонами доступности в регионе.

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

• Все регионы Azure, в которых поддерживается поддержка зон доступности, поддерживают гипермасштабируемую базу данных с избыточностью по зонам.

  • Для оборудования премиум-серии Hyperscale и премиум-серии, оптимизированной для памяти, избыточность по зонам доступна в некоторых регионах. См. доступность гипермасштабной премиум-серии по регионам для базы данных Azure SQLдля получения дополнительной информации.

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

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

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

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

Отказоустойчивость зоны базы данных

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

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

Если ни одна из баз данных на сервере не является зонально-избыточной или при создании пустого сервера, то база данных, связанная с сервером, master не является зонально-избыточной. Чтобы перенести базу данных SQL Azure для использования избыточности зоны, выполните действия, описанные в статье "Миграция базы данных SQL Azure в поддержку зоны доступности".

Чтобы проверить ZoneRedundant свойство master базы данных, используйте Azure PowerShell или Azure CLI или шаги REST API в разделе "Проверка состояния зоны доступности базы данных SQL Azure".

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

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

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

Переключение на резервный узел можно инициировать с помощью PowerShell, REST API или Azure CLI.

Conclusion

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

Следующий шаг

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

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