Поделиться через

Надежность в Управляемом экземпляре SQL Azure

Управляемый экземпляр SQL Azure — это полностью управляемая платформа как услуга (PaaS) для управления базами данных. Она обеспечивает почти 100% совместимость функций с SQL Server. Управляемый экземпляр SQL Azure обрабатывает большинство функций управления базами данных, таких как обновление, исправление, резервное копирование и мониторинг без участия пользователя. Он выполняется в последней стабильной версии ядра СУБД SQL Server и исправленной операционной системы с встроенной высокой доступностью.

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

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

Рекомендации по развертыванию в рабочей среде для обеспечения надежности

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

Обзор архитектуры надежности

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

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

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

  • До пяти вторичных реплик (вычисления и хранения), содержащих копии данных.

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

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

Избыточность

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

  • Операции управления, инициированные клиентом, которые приводят к краткому простою

  • Операции обслуживания сервиса

  • Небольшие сети или сбои питания

  • Проблемы и сбои центра обработки данных, связанные со следующими компонентами:

    • Стойка, где работают машины, управляющие вашей службой

    • Физический компьютер, на котором размещена виртуальная машина под управлением ядра СУБД SQL.

    • Виртуальная машина, которая запускает ядро СУБД SQL

  • Проблемы с ядром СУБД SQL

  • Потенциальные незапланированные локализованные сбои

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

Устойчивость к временным сбоям

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

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

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

При исправлении или отработке отказа экземпляра время простоя имеет минимальный эффект при использовании логики повторных попыток в приложении. Вы можете проверить устойчивость приложения к временным сбоям.

Устойчивость к сбоям зоны доступности

Замечание

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

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

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

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

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

Требования

  • Поддержка региона: Избыточность зоны для Управляемого экземпляра SQL поддерживается в выборе регионов. Дополнительные сведения см. в разделе "Поддерживаемые регионы".

  • Избыточность хранилища резервных копий: Чтобы включить зональную избыточность для управляемого экземпляра SQL, задайте избыточность хранилища резервных копий как ZRS или Геозонально-избыточное хранилище (GZRS).

Себестоимость

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

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

Настройка поддержки зоны доступности

В этом разделе объясняется, как настроить поддержку зоны доступности для управляемых экземпляров SQL:

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

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

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

Поведение, когда все зоны работоспособны

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

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

  • Репликация данных между зонами: Файлы базы данных хранятся в службе хранилища Azure с помощью ZRS, который подключен к каждому узлу, который в настоящее время содержит активный процесс ядра СУБД SQL.

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

  • Маршрутизация трафика между зонами: Во время обычных операций запросы направляются в основную реплику управляемого экземпляра SQL.

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

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

Поведение во время сбоя зоны

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

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

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

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

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

  • Ожидаемое время простоя: Во время отработки отказа зоны доступности может потребоваться небольшое время простоя. Время простоя обычно меньше 30 секунд, которое приложение должно терпеть, если оно следует рекомендациям по устойчивости к временным сбоям .

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

Восстановление зоны

Когда зона доступности восстанавливается, управляемый экземпляр SQL работает со Service Fabric для восстановления операций в восстановленной зоне. Никакое вмешательство клиента не требуется.

Тестирование на сбои в зоне

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

Устойчивость к сбоям на уровне региона

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

Группы переключения при отказе

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

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

Политики отработки отказа

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

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

  • Аварийное переключение, управляемое корпорацией Майкрософт: Аварийное переключение, управляемое корпорацией Майкрософт, используется только в исключительных случаях для принудительного переключения.

Это важно

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

Поддержка регионов

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

Себестоимость

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

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

Дополнительную информацию о ценах на Управляемый экземпляр SQL см. в информации о ценах на услуги.

Настройка поддержки нескольких регионов

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

Планирование ресурсов и управление ими

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

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

Поведение, когда все регионы работоспособны

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

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

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

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

  • Репликация данных между регионами: По умолчанию данные реплицируются асинхронно из первичного экземпляра в дополнительный управляемый экземпляр SQL.

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

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

Поведение во время сбоя региона

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

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

    • Политика отработки отказа, управляемая клиентом: Вы несете ответственность за обнаружение сбоя в регионе и активацию отработки отказа или принудительной отработки отказа на дополнительный экземпляр в группе отработки отказа.

      Если вы выполняете переключение на резервный экземпляр, управляемый экземпляр SQL ожидает синхронизации данных с вторичным экземпляром перед выполнением процедуры переключения на резервный экземпляр.

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

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

  • Активные запросы: При возникновении сбоя все обрабатываемые запросы завершаются и должны быть повторно отправлены. Чтобы сделать приложения устойчивыми к этим типам проблем, см. статью "Устойчивость к временным сбоям".

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

  • Ожидаемое время простоя: Во время переключения группы отработки отказа может потребоваться небольшое время простоя. Время простоя обычно меньше 60 секунд.

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

Восстановление региона

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

Проверка сбоев в регионе

Вы можете проверить отработку отказа группы отказоустойчивости.

Тестирование группы аварийного переключения — это только одна часть проведения учений по аварийному восстановлению. Дополнительные сведения см. в разделе "Проведение учений по аварийному восстановлению".

Резервное копирование и восстановление

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

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

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

Репликация резервных копий

При настройке автоматических резервных копий для управляемого экземпляра SQL можно указать способ репликации резервных копий. Резервные копии, настроенные для хранения в ZRS, имеют более высокий уровень устойчивости. Рекомендуется настроить резервные копии для использования одного из следующих типов хранилища:

  • ZRS для обеспечения устойчивости в регионе, если регион имеет зоны доступности

  • GZRS для повышения устойчивости резервных копий между регионами, если регион имеет зоны доступности и связан с другим регионом.

  • GRS, если регион не поддерживает зоны доступности, но имеет парный регион

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

Геовосстановление

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

Если вы используете геовосстановление, необходимо рассмотреть вопрос о том, как сделать резервные копии доступными в дополнительном регионе:

Устойчивость к обслуживанию служб

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

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

Дополнительные сведения см. в разделе "Период обслуживания" в Управляемом экземпляре SQL.

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Для получения дополнительной информации см. Соглашения об уровне обслуживания для онлайн-сервисов.

Для Управляемого экземпляра SQL соглашение об уровне обслуживания применяется только при правильной настройке виртуальной сети Azure, чтобы не препятствовать трафику управления. Эта конфигурация включает размер подсети, группы безопасности сети (NSG), определяемые пользователем маршруты (UDR), конфигурацию DNS и другие ресурсы, влияющие на управление и использование сетевых ресурсов. Дополнительные сведения о требуемой конфигурации сети для управляемого экземпляра SQL см. в разделе "Требования к сети".

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

  • Last updated on