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

Непрерывность бизнес-процессов и аварийное восстановление для Управляемый экземпляр SQL с поддержкой Azure Arc

  • Статья

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

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

Архитектура

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

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

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

Схема, показывающая сбой первичной реплики.

Схема, показывающая восстановленное рабочее состояние.

На следующей схеме архитектуры показано, как Управляемый экземпляр SQL с поддержкой Arc можно развернуть в двух отдельных кластерах Kubernetes на двух разных сайтах для аварийного восстановления.

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

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

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

Рекомендации по проектированию

Чтобы оценить влияние Управляемый экземпляр SQL с поддержкой Azure Arc на общую модель BCDR, ознакомьтесь с рекомендациями BCDR для целевых зон в области непрерывности бизнес-процессов и аварийного восстановления. Обратите внимание, что основное внимание уделяется непрерывности бизнес-процессов и аварийному восстановлению только для обеспечения непрерывности бизнес-процессов, но высокий уровень доступности и устойчивость экземпляра также зависит от доступности базовой инфраструктуры Kubernetes.

Восстановление на определенный момент времени

  • Определите целевые объекты для целевой точки восстановления (RPO) и целевой цели времени восстановления (RTO).

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

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

  • Рассмотрим, какой класс хранилища следует использовать для постоянного тома для резервных копий. Инструкции см. в разделе "Дисциплины хранилища" для Управляемый экземпляр SQL с поддержкой Azure Arc.

  • Рассмотрим размер постоянного тома для резервных копий в контексте ожидаемого размера данных и настроенного периода хранения.

  • Рекомендации по хранению см. в дисциплинах хранилища для Управляемый экземпляр SQL с поддержкой Azure Arc.

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

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

  • Рассмотрим дополнительные шаги, необходимые для полного восстановления базы данных, если приложение находится в сети во время процесса восстановления.

  • Рассмотрим дополнительные шаги, необходимые для восстановления базы данных в экземпляре с несколькими репликами, как описано в разделе "Восстановление базы данных в экземпляре с несколькими репликами".

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

Высокая доступность

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

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

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

  • Рассмотрим, сколько реплик ( по три) развертывается на уровне служб критически важный для бизнеса.

  • При развертывании экземпляра на уровне служб критически важный для бизнеса с двумя или более репликами можно настроить вторичные реплики как доступные для чтения. Определите количество вторичных реплик для развертывания на уровне служб критически важный для бизнеса. Сведения об изменении числа см. в разделе "Настройка доступных для чтения вторичных файлов".

  • Решите о приоритете согласованности доступности с помощью количества вторичных реплик, необходимых для фиксации транзакции на уровне служб критически важный для бизнеса с помощью необязательного параметра --sync-secondary-to-commit. Если между репликами возникают проблемы с подключением, основной может не зафиксировать транзакции:

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

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

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

Аварийное восстановление

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

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

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

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

Рекомендации по проектированию

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

Восстановление на определенный момент времени

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

  • Используйте класс хранилища, поддерживающий ReadWriteMany (RWX) для тома резервных копий. Инструкции см. в дисциплинах хранилища для Управляемый экземпляр SQL с поддержкой Azure Arc.

  • Перед началом операции восстановления используйте необязательный параметр --dry-run , чтобы сначала проверить, будет ли операция успешно выполнена. Дополнительные сведения см. в статье "Создание базы данных из точки во времени" с помощью az CLI.

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

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

Высокая доступность

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

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

  • Для повышения доступности используйте LoadBalancer в качестве типа службы при развертывании экземпляра.

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

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

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

  • Сведения о рекомендациях по мониторингу доступности экземпляров см. в статье "Управление и мониторинг для Управляемый экземпляр SQL с поддержкой Azure Arc".

Аварийное восстановление

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

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

  • Создайте процесс запуска вручную и принудительной отработки отказа.

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

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

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

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