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

  • Статья

Применимо к:Управляемый экземпляр SQL Azure

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

Внимание

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

Обзор

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

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

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

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

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

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

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

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

Локально избыточность доступности

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

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

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

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

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

  • Уровень вычислений без отслеживания состояния, который запускает процесс ядра СУБД и содержит только временные и кэшированные данные, такие как tempdbmodel и базы данных на подключенном 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 может размещать разные реплика экземпляра критически важный для бизнеса в разных зонах доступности в одном регионе. Таким же образом вычислительные узлы уровня общего назначения без отслеживания состояния помещаются в другую зону доступности, в то время как хранилище с отслеживанием состояния использует конфигурацию избыточного между зонами хранилища (ZRS).

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

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

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

Схема архитектуры высокой доступности, избыточной между зонами.

При использовании зоны избыточности следует учитывать следующее:

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

Поддерживаемые регионы для экземпляров критически важный для бизнеса

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

Северная и Южная Америка Европа Ближний Восток Африка Азиатско-Тихоокеанский регион
Brazil South Центральная Франция Центральный Катар Северная часть ЮАР Восточная Австралия
Центральная Канада Северная Италия Израиль, центральный регион Центральная Индия
Центральная часть США Центрально-Западная Германия Восточная Япония
Восточная часть США Восточная Норвегия; Республика Корея, центральный регион
Восточная часть США 2 Северная Европа Юго-Восточная Азия
Центрально-южная часть США южная часть Соединенного Королевства Восточная Азия
западная часть США 2 Центральная Швеция
Западная часть США — 3 Северная Швейцария
Центральная Польша

Поддерживаемые регионы для экземпляров общего назначения

Примечание.

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

Северная и Южная Америка Европа Ближний Восток Африка Азиатско-Тихоокеанский регион
Brazil South Центральная Франция Центральный Катар Северная часть ЮАР Восточная Австралия
Восточная часть США Северная Италия Израиль, центральный регион Центральная Индия
Восточная часть США 2 Центрально-Западная Германия Восточная Япония
Центрально-южная часть США Восточная Норвегия; Республика Корея, центральный регион
западная часть США 2 Северная Европа Юго-Восточная Азия
Западная часть США — 3 южная часть Соединенного Королевства Восточная Азия
Центральная Швеция
Северная Швейцария
Центральная Польша

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

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

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

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