Экспорт (0) Печать
Развернуть все
Развернуть Свернуть

Высокий уровень доступности и аварийное восстановление для SQL Server в виртуальных машинах Azure

Обновлено: Июнь 2014 г.

Виртуальные машины Microsoft Azure с SQL Server позволяют сокращать затраты при реализации системы высокого уровня доступности и аварийного восстановления баз данных (HADR). Большинство решений SQL Server HADR поддерживаются в виртуальных машинах Azure и как исключительно Azure, и как гибридные решения. В решении только с Azure вся система HADR работает в Azure. В гибридной конфигурации часть системы работает в Azure, а другая часть — локально в вашей организации. Гибкость среды Azure позволяет перемещать ресурсы полностью или частично в Azure для удовлетворения требований к бюджету и требований HADR ваших систем баз данных SQL Server.

Вы должны сами убедиться, что СУБД обладает возможностями HADR, необходимыми по соглашению об уровне обслуживания (SLA). Azure предоставляет механизмы обеспечения высокого уровня доступности, такие как восстановление облачных служб и обнаружение восстановления после сбоя виртуальной машины, но само по себе это не гарантирует соблюдения SLA. Эти механизмы гарантируют высокий уровень доступности VM, но не обеспечивают высокую доступность SQL Server внутри VM. В экземпляре SQL Server может возникнуть ошибка, в то время как VM будет исправна и доступна в сети. Кроме того, даже механизмы высокого уровня доступности, предоставляемые Azure, не защищают от простоев VM из-за таких событий, как восстановление после программного или аппаратного сбоя или обновление операционной системы.

Кроме того, избыточное географическое хранилище (GRS) в Azure, которое реализуется с помощью георепликации, может не быть адекватным решением для аварийного восстановления ваших баз данных. Поскольку георепликация отправляет данные асинхронно, последние обновления могут быть потеряны в случае сбоя. Более подробную информацию о ограничениях георепликации см. в разделе Георепликация не поддерживается для файлов данных и журналов на разных дисках.

Технологии SQL Server HADR, поддерживаемые в Azure:

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

Вы можете реализовать решение высокого уровня доступности для баз данных SQL Server в Azure с помощью групп доступности AlwaysOn или зеркального отображения базы данных.

 

Технология Примеры архитектуры

Группы доступности AlwaysOn

Для обеспечения высокого уровня доступности все реплики доступности выполняются на виртуальных машинах Azure в одном регионе. Вам необходимо настроить контроллер домена в дополнение к виртуальным машинам SQL Server, так как для отказоустойчивой кластеризации Windows Server (WSFC) требуется домен Active Directory.

Дополнительные сведения см. в Учебник. Группы доступности AlwaysOn в Azure (графический интерфейс пользователя).

Зеркальное отображение базы данных

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

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

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

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

 

Технология Примеры архитектуры

Группы доступности AlwaysOn

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

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

Зеркальное отображение базы данных

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

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

Резервное копирование и восстановление с помощью службы хранилищ больших двоичных объектов Azure

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

Дополнительные сведения см. в Резервное копирование и восстановление для SQL Server в виртуальных машинах Azure.

Вы можете реализовать решение аварийного восстановления для баз данных SQL Server в гибридной ИТ-среде с использованием групп доступности AlwaysOn, зеркального отображения базы данных, доставки журналов и резервного копирования и восстановления с помощью хранилища больших двоичных объектов Azure.

 

Технология Примеры архитектуры

Группы доступности AlwaysOn

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

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

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

Дополнительные сведения см. в Tutorial: AlwaysOn Availability Groups in Hybrid IT.

Зеркальное отображение базы данных

  • Один участник выполняется в VM Azure, а другой выполняется локально для аварийного восстановления между сайтами с использованием сертификатов сервера. Партнеры не обязательно должны находиться в одном домене Active Directory, VPN-подключение не требуется.



    Дополнительные сведения см. в Учебник. Зеркальное отображение базы данных для аварийного восстановления в Hybrid IT.

  • Один участник выполняется в VM Azure, а другой выполняется локально в том же домене Active Directory для аварийного восстановления между сайтами. Требуется VPN-подключение между виртуальной сетью Azure и локальной сетью.

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

Доставка журналов

Один сервер работает в VM Azure, а другой выполняется локально для аварийного восстановления между сайтами. Доставка журналов зависит от общего доступа к файлам Windows, поэтому VPN-соединение между виртуальной сетью Azure и локальной сетью не требуется.

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

Дополнительные сведения см. в Учебник. Доставка журналов для аварийного восстановления в Hybrid IT.

Резервное копирование и восстановление с помощью службы хранилищ больших двоичных объектов Azure

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

Дополнительные сведения см. в Резервное копирование и восстановление для SQL Server в виртуальных машинах Azure.

Рабочие характеристики VM, хранилища и сети Azure отличаются от локальной, невиртуализированной ИТ-инфраструктуры. Для успешной реализации HADR-решения для SQL Server в Azure необходимо понимать эти различия и разработать решение в соответствии с ними.

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

Несовместимая с RFC служба DHCP в Azure может привести к ошибке создания некоторых конфигураций кластера WSFC из-за того, что сетевое имя кластера назначено повторяющемуся IP-адресу (такому же IP-адресу, что и для одного из узлов кластера). Это может стать проблемой при реализации групп доступности AlwaysOn, которые зависят от WSFC.

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

  1. Кластер подключается к сети, затем NODE1 запрашивает динамически назначаемый IP-адрес для сетевого имени кластера.

  2. DHCP-служба предоставляет только собственный IP-адрес NODE1, поскольку служба DHCP распознает, что запрос поступает от NODE1.

  3. Windows обнаруживает, что повторяющийся адрес назначен NODE1 и сетевому имени кластера, а кластерной группе по умолчанию не удается подключиться к сети.

  4. Кластерная группа по умолчанию перемещается в узел NODE2, который обрабатывает IP-адрес NODE1 как IP-адрес кластера и переводит кластерную группу по умолчанию в оперативный режим в сети.

  5. Когда NODE2 пытается установить соединение с NODE1, пакеты, направляемые на NODE1, никогда не покидают NODE2, поскольку IP-адрес NODE1 разрешается в адрес NODE2. NODE2 не может установить подключение к NODE1, теряет кворум и отключает кластер.

  6. В то же время NODE1 может отправлять пакеты на NODE2, но NODE2 не может ответить. NODE1 теряет кворум и отключает кластер.

Этого можно избежать, если назначить неиспользуемый статический IP-адрес, например локальный IP-адрес, такой как 169.254.1.1, для сетевого имени кластера, чтобы перевести это сетевое имя кластера в оперативный режим. Чтобы упростить этот процесс, ознакомьтесь с разделом Настройка кластера отработки отказа в Azure для групп доступности AlwaysOn.

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

Прослушиватели групп доступности поддерживаются в VM Azure на основе Windows Server 2008 R2, Windows Server 2012 и Windows Server 2012 R2. Эта поддержка возможна при включении на VM в Azure, являющихся узлами группы доступности, конечных точек балансировки нагрузки в режиме direct server return (DSR). Необходимо следовать специальным шагам конфигурации для прослушивателей в Azure для работы как с клиентскими приложениями в Azure, так и с локальными. Инструкции по настройке прослушивателя см. в разделе Учебник. Конфигурация прослушивателя для групп доступности AlwaysOn.

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

  • одна первичная реплика и одна вторичная реплика;

  • вторичная реплика настроена как недоступная для чтения (параметру Вторичная доступная для чтения задано значение Нет).

Далее приведен пример строки подключения клиента, которая соответствует этой подобной зеркальному отображению базы данных конфигурации с использованием ADO.NET или SQL Server Native Client:

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

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

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

Георепликация на дисках Azure не поддерживает возможность хранения файлов данных и файлов журналов одной базы данных на разных дисках. GRS реплицирует изменения на каждом диске независимо и асинхронно. Этот механизм обеспечивает единый порядок записи на одном диске в геореплицированной копии, но не для геореплицированных копий нескольких дисков. Если настроить базу данных для хранения файла данных и файла журнала на разных дисках, восстановленные после сбоя диски могут содержать более позднюю копию файла данных, чем файла журнала, что нарушит упреждающее протоколирование SQL Server и повредит свойства ACID транзакций. Если вы не можете отключить георепликацию в учетной записи хранения, следует хранить все файлы данных и журналов для базы данных на одном диске. Если из-за размера базы данных необходимо использовать несколько дисков, потребуется развернуть одно из решений аварийного восстановления, перечисленных выше, для обеспечения избыточности данных.

См. также

Корпорация Майкрософт проводит интернет-опрос, чтобы выяснить ваше мнение о веб-сайте MSDN. Если вы желаете принять участие в этом интернет-опросе, он будет отображен при закрытии веб-сайта MSDN.

Вы хотите принять участие?
Показ:
© 2014 Microsoft