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

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

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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

• Сведения о региональной доступности см. в разделе доступность функции избыточности зоны общего назначения по регионам для базы данных SQL Azure.
• Для повышения отказоустойчивости между зонами, возможность выбора периода обслуживания, отличного от стандартного, в настоящее время доступна в некоторых регионах. Для получения дополнительной информации см. раздел «Доступность окна обслуживания по регионам для базы данных Azure SQL».
• Конфигурация с избыточностью между зонами доступна только в базе данных SQL при выборе оборудования стандартной серии (Gen5).
• Избыточность между зонами недоступна для уровней служб "Базовый" и "Стандартный" в модели приобретения DTU.

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

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

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

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

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

Уровень услуг «Гипермасштабируемость»

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

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

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

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

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

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

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

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

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

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

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

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

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

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 см. в контрольном списке HA/DR.

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

Заключение

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

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

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

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