Доступность с помощью локальной и зоны избыточности — Управляемый экземпляр SQL Azure

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

• База данных SQL Azure
• Управляемый экземпляр SQL Azure

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

Внимание

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

Обзор

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

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

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

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

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

Высокий уровень доступности повышает надежность службы, защищая вас от влияния на:

• Зона доступности, которая формирует центр обработки данных

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

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

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

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

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

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

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

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

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

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

Уровень служб общего назначения следующего поколения

Примечание.

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

Общее назначение следующего поколения — это обновление архитектуры до существующего уровня служб общего назначения, использующего обновленный уровень удаленного хранилища, который хранит файлы данных экземпляров и журналов на управляемых дисках вместо страничных BLOB-объектов и поддерживает его локально.

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

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

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

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

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

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

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

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

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

Чтобы приступить к работе с избыточностью зоны для управляемого экземпляра SQL, просмотрите раздел "Настройка избыточности зоны".

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

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

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

Примечание.

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

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

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

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

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

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

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

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

Локальная отработка отказа может быть инициирована с помощью PowerShell, REST API или Azure CLI:

PowerShell	REST API	Azure CLI
Invoke-AzSqlInstanceFailover	Управляемый экземпляр SQL — отработка отказа	az sql mi failover можно использовать для вызова вызова REST API из Azure CLI

Заключение

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

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

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