Изучение решения IaaS для обеспечения высокого уровня доступности и аварийного восстановления
Существует множество различных сочетаний вариантов, которые можно развернуть в Azure для IaaS. В этом разделе рассматриваются пять распространенных примеров архитектур высокой доступности и аварийного восстановления (HADR) SQL Server в Azure.
Пример высокой доступности в одном регионе 1. Группы доступности Always On
Если требуется обеспечить только высокий уровень доступности без выполнения аварийного восстановления, следует рассмотреть возможность настройки группы доступности, которая является одним из самых широко используемых методов, применяемых независимо от того, где работает SQL Server. На приведенном ниже рисунке показан пример одной возможной группы доступности в одном регионе.
Почему эта архитектура заслуживает внимания?
Эта архитектура защищает данные за счет размещения их нескольких копий на разных виртуальных машинах.
Она позволяет эффективно использовать правильно заданные целевое время восстановления (RTO) и целевую точку восстановления (RPO) с минимальной потерей данных или вообще без потерь.
Эта архитектура предоставляет простой стандартизированный метод для доступа приложений к первичной и вторичной репликам (в случае, если будут использоваться реплики только для чтения).
Эта архитектура обеспечивает улучшенную доступность во время сценариев установки исправлений.
Она не требует общего хранилища, поэтому избавляет от многих сложностей, связанных с использованием экземпляра отказоустойчивого кластера (FCI).
Пример высокой доступности в одном регионе 2. Экземпляр отказоустойчивого кластера Always On
До появления групп доступности экземпляры отказоустойчивых кластеров были самым популярным способом реализации высокого уровня доступности SQL Server. FCI были разработаны в то время, когда преобладали физические развертывания. В виртуализированной среде экземпляры отказоустойчивых кластеров не обеспечивают защиту в том виде, как это происходит на физическом оборудовании, поскольку проблемы с виртуальными машинами возникают довольно редко. Экземпляры отказоустойчивых кластеров были разработаны для защиты от таких сбоев, как отказы сетевых адаптеров или дисков, которых, скорее всего, не будет в Azure.
Но вместе с тем FCI уместны и в Azure. Они работают и, пока у вас есть правильные ожидания относительно имеющихся и отсутствующих функций, FCI является идеально приемлемым решением. На приведенном ниже рисунке из документации Майкрософт показана общая схема развертывания FCI при использовании локальных дисковых пространств.
Почему эта архитектура заслуживает внимания?
Экземпляры отказоустойчивых кластеров остаются популярным решением для обеспечения доступности.
Общие диски Azure способствуют улучшению функциональности общего хранилища.
Эта архитектура соответствует большинству RTO и RPO для обеспечения высокой доступности (хотя аварийное восстановление не обрабатывается).
Она предоставляет простой стандартизированный метод для доступа приложений к кластеризованному экземпляру SQL Server.
Эта архитектура обеспечивает улучшенную доступность во время сценариев установки исправлений.
Пример аварийного восстановления 1. Гибридная группа доступности Always On или группа доступности Always On с поддержкой нескольких регионов
Если вы используете группы доступности, можно настроить группу доступности в нескольких регионах Azure или в качестве гибридной архитектуры. Это означает, что все узлы, содержащие реплики, входят в один кластер WSFC. При этом предполагается, что существует хорошее сетевое подключение, особенно если это гибридная конфигурация. Одной из важнейших особенностей является наличие ресурса-свидетеля для кластера WSFC. В этой архитектуре требуется, чтобы службы AD DS и DNS были доступны в каждом регионе, и, возможно, в локальной среде, если это гибридное решение. На рисунке ниже показано, что собой представляет одна группа доступности, настроенная в двух расположениях с помощью Windows Server.
Почему эта архитектура заслуживает внимания?
Эта архитектура является проверенным решением. Она ничем не отличается от наличия двух центров обработки данных в топологии группы доступности.
Эта архитектура работает с выпусками SQL Server Standard и Enterprise.
Группы доступности естественным образом обеспечивают избыточность с помощью дополнительных копий данных.
Эта архитектура использует одну функцию, обеспечивающую и высокую доступность, и аварийное восстановление.
Пример аварийного восстановления 2. Распределенная группа доступности
Распределенная группа доступности — это функция выпуска Enterprise, появившаяся в SQL Server 2016. Она отличается от традиционной группы доступности. Вместо одного базового кластера WSFC, где все узлы содержат реплики, входящие в одну группу доступности, как описано в предыдущем примере, распределенная группа доступности состоит из нескольких групп доступности. Первичная реплика, содержащая базу данных для чтения и записи, называется глобальной первичной репликой. Первичная реплика второй группы доступности называется сервером пересылки и обеспечивает синхронизацию вторичных реплик этой группы доступности. По сути, это группа доступности групп доступности.
Эта архитектура упрощает работу, к примеру, с кворумом, так как каждый кластер будет поддерживать свой собственный кворум, что значит, что у него также есть собственный ресурс-свидетель. Распределенная группа доступности будет работать независимо от того, используете ли вы Azure для всех ресурсов или используете гибридную архитектуру.
На рисунке ниже показан пример конфигурации распределенной группы доступности. Есть два кластера WSFC. Представьте, что каждый из них находится в отдельном регионе Azure либо что один находится в локальной среде, а другой — в Azure. У каждого кластера WSFC есть группа доступности с двумя репликами. Глобальная первичная реплика в группе доступности 1 обеспечивает синхронизацию вторичной реплики группы доступности 1 и сервера пересылки, который также является первичной репликой группы доступности 2. Эта реплика обеспечивает синхронизацию вторичной реплики группы доступности 2.
Почему эта архитектура заслуживает внимания?
Эта архитектура отделяет кластер WSFC как единую точку сбоя в случае нарушения взаимодействия всех узлов.
В этой архитектуре одна первичная реплика не синхронизирует все вторичные реплики.
Эта архитектура может обеспечивать восстановление из одного расположения в другое.
Пример аварийного восстановления 3. Доставка журналов
Доставка журналов представляет собой один из самых старых методов HADR для настройки аварийного восстановления для SQL Server. Как описано выше, единицей измерения является резервная копия журналов транзакций. Если переключение на горячее резервирование не запланировано, скорее всего, будут происходить потери данных. Когда речь идет об аварийном восстановлении, всегда лучше допускать возможность потери части данных, даже если она будет минимальной. На приведенном ниже рисунке из документации Майкрософт показан пример топологии доставки журналов.
Почему эта архитектура заслуживает внимания?
Доставка журналов — это проверенная и надежная функция, которая работает более 20 лет.
Она проста в развертывании и администрировании, так как основана на резервном копировании и восстановлении.
Доставка журналов может функционировать в сетях, не обладающих необходимой надежностью.
Доставка журналов выполняет большинство задач RTO и RPO для аварийного восстановления.
Доставка журналов — хороший способ защиты FCI.
Пример аварийного восстановления 4. Azure Site Recovery
Для тех, кто не хочет реализовывать аварийное решение на основе SQL Server, потенциальным вариантом является Azure Site Recovery. Но большинство специалистов по работе с данными предпочитают подход, ориентированный на базы данных, так как в общем случае он будет иметь меньшую RPO.
Приведенное ниже изображение из документации Майкрософт показывает, где в портал Azure необходимо настроить репликацию для Azure Site Recovery.
Почему эта архитектура заслуживает внимания?
Azure Site Recovery может работать не только с SQL Server.
Azure Site Recovery может соответствовать RTO и, возможно, RPO.
Azure Site Recovery предоставляется в составе платформы Azure.