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

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

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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Next-gen General Purpose — это архитектурное обновление существующего уровня универсального сервиса, которое использует обновлённый удалённый слой хранения данных экземпляра и лог-файлов на Elastic SAN вместо блобов страниц.

Зональная избыточность на уровне обслуживания Next-gen General Purpose в настоящее время доступна в предварительной версии. Предварительная версия также поддерживает гибкую настройку памяти для экземпляров с избыточностью между зонами на оборудовании серии Premium.

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

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

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

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

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

Высокая доступность за счёт избыточности по зонам

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

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

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

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

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

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

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

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

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

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

Зональная избыточность на уровне обслуживания Next-gen General Purpose в настоящее время доступна в предварительной версии. Конфигурация с избыточностью по зонам распределяет компоненты сервиса по зонам доступности и использует обновлённый удалённый уровень хранения Elastic SAN. Предпросмотр поддерживает гибкую память на железе серии Premium, так что можно регулировать память независимо от количества vCore.

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

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

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

Схема архитектуры зонального резервирования на уровне обслуживания Business Critical.

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

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

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

Команда ручного переключения при отказе, описанная в этом разделе, обычно ведёт себя одинаково как в конфигурациях с локальной избыточностью, так и в конфигурациях с избыточностью между зонами. Команда обычно перезапускает процесс SQL только локально и не инициирует переключение на другой узел, хотя есть несколько исключений. Это локальное переключение при отказе отличается от переключения при отказе, которое происходит в группе автоматического переключения при отказе. Однако нет ограничений, которые гарантируют, что новый процесс запускается на одном узле, и он может начинаться на другом узле в той же или в другой зоне доступности. Локальное переключение при отказе можно инициировать с помощью PowerShell, REST API или Azure CLI:

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

Автоматические внутренние тесты подключения

Чтобы обеспечить доступность службы, Управляемый экземпляр SQL Azure выполняет автоматические внутренние тесты подключения для мониторинга надежности службы и ускорения обнаружения проблем. Эти тесты выполняются каждые 10 секунд от внутренних IP-адресов в подсети управляемого экземпляра SQL и имеют незначительное влияние на производительность сети и производительности служб. Один тест проверяет сквозную связность, пытаясь выполнить вход с использованием учетных данных, для которых заранее известно, что вход завершится неудачей (AzureSQLConnectivityChecker), в результате чего в журналах аудита, Extended Events и журналах ошибок SQL формируются ожидаемые записи о неудачных попытках входа. Эти записи являются нормальными и не указывают на проблему безопасности. Дополнительные сведения о том, как определить тестовые подписи в журналах, см. в разделе "Автоматические внутренние тесты подключения".

Заключение

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

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

  • Last updated on