Непрерывность бизнес-процессов и HADR для SQL Server на виртуальных машинах Azure

Применимо к:SQL Server на виртуальной машине Azure

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

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

В этой статье проводится сравнение решений для обеспечения непрерывности бизнес-процессов, доступных для SQL Server на виртуальных машинах Azure.

Обзор

Необходимо убедиться в том, что система баз данных поддерживает возможности HADR, оговоренные в соглашении об уровне обслуживания (SLA). Тот факт, что Azure обеспечивает механизмы высокого уровня доступности, такие как восстановление облачных служб и обнаружение восстановления после сбоя для виртуальных машин, сам по себе не гарантирует возможности выполнения условий SLA. Несмотря на то, что эти механизмы способствуют защите высокой доступности виртуальной машины, они не защищают доступность SQL Server, работающего в рамках виртуальной машины.

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

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

Примечание.

Теперь решение экземпляра отказоустойчивого кластера и группы доступности можно перенести на SQL Server в Виртуальных машинах Azure с помощью службы "Миграция Azure", используя метод lift-and-shift.

Архитектуры развертывания

Azure поддерживает указанные ниже технологии SQL Server для обеспечения непрерывности бизнес-процессов.

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

Только в Azure: решения высокого уровня доступности

Решение для обеспечения высокого уровня доступности SQL Server можно реализовать на уровне базы данных с помощью групп доступности Always On. Его можно также создать на уровне экземпляров с помощью экземпляров отказоустойчивого кластера Always On. Для дополнительной защиты можно создать избыточность на обоих уровнях путем создания групп доступности для экземпляров отказоустойчивого кластера.

Технология Примеры архитектур
Группы доступности Реплики доступности, выполняемые на виртуальных машинах Azure в одном регионе, обеспечивают высокий уровень доступности. Необходимо настроить виртуальную машину контроллера домена, так как для отказоустойчивой кластеризации Windows требуется домен Active Directory.

Для повышения уровней избыточности и доступности виртуальные машины Azure можно развернуть в разных зонах доступности, как описано в обзоре групп доступности. Diagram that shows the
Чтобы приступить к работе, ознакомьтесь с руководством по группе доступности.
Экземпляры отказоустойчивого кластера Экземпляры отказоустойчивого кластера поддерживаются на виртуальных машинах SQL Server. Поскольку для компонента FCI требуется общее хранилище, для работы с SQL Server на виртуальных машинах Azure будут применяться пять решений, описанных ниже.

– Использование общих дисков Azure для Windows Server 2019. Общие управляемые диски — это продукт Azure, позволяющий одновременное подключение управляемого диска к нескольким виртуальным машинам. Виртуальные машины в кластере могут выполнять чтение или запись на подключенный диск в соответствии с резервированием, выбранным кластеризованным приложением, с помощью постоянного резервирования SCSI (SCSI PR). SCSI PR — это стандартное отраслевое решение для хранения данных, используемое приложениями, работающими в локальных сетях хранения данных (SAN). Включение SCSI PR на управляемом диске позволяет перенести эти приложения в Azure "как есть".

— Использование локальных дисковых пространств (S2D) для предоставления программной виртуальной SAN для Windows Server 2016 и более поздних версий.

– Использование файлового ресурса категории "Премиум" для Windows Server 2012 и более поздних версий. Файловые ресурсы категории "Премиум" — это ресурсы на основе SSD со стабильно низким значением задержки, которые полностью поддерживаются для использования с FCI.

– Использование хранилища, поддерживаемого партнерским решением для кластеризации. Конкретный пример, в котором используется SIOS DataKeeper, см. в записи блога Отказоустойчивая кластеризация и SIOS DataKeeper.

– Использование общего блочного хранилища для удаленного целевого объекта iSCSI с помощью Azure ExpressRoute. Например, решение NetApp Private Storage (NPS) предоставляет цели iSCSI через ExpressRoute с Equinix для виртуальных машин Azure.

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

Чтобы приступить к работе, подготовьте виртуальную машину для FCI

Только в Azure: решения аварийного восстановления

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

Технология Примеры архитектур
Группы доступности Реплики доступности, выполняемые в нескольких центрах обработки данных на виртуальных машинах Azure для аварийного восстановления. Это межрегиональное решение способствует в обеспечении при полном отключении сайта.
Diagram that shows two regions with a
В пределах региона все реплики должны находиться в одной облачной службе и одной виртуальной сети. Поскольку каждый регион будет иметь отдельную виртуальную сеть, для этих решений требуется межсетевое подключение. Дополнительные сведения см. в статье Настройка межсетевого подключения с помощью портала Microsoft Azure. Подробные инструкции см. в статье Настройка группы доступности AlwaysOn Microsoft SQL Server в разных регионах Azure.
Зеркальное отображение базы данных Основной, зеркальный и другие серверы, выполняемые в разных центрах обработки данных для аварийного восстановления. Необходимо выполнить их развертывание с использованием сертификатов сервера.
Diagram that shows the Principal in one region connected to the Mirror in another region with High Performance.
Резервное копирование и восстановление с помощью хранилища BLOB-объектов Резервные копии рабочих баз данных создаются напрямую в хранилище BLOB-объектов в другом центре обработки данных для обеспечения аварийного восстановления.
Diagram that shows a Database in one region backing up to Blob Storage in another region.
Дополнительные сведения см. в статье Резервное копирование и восстановление для SQL Server на виртуальных машинах Azure.
Репликация и отработка отказа SQL Server в Azure с помощью службы Azure Site Recovery Рабочий экземпляр SQL Server в одном из центров обработки данных Azure реплицируется непосредственно в службу хранилища Microsoft Azure в другом центре обработки данных Azure в целях аварийного восстановления.
Diagram that shows a Database in one Azure datacenter using ASR Replication for disaster recovery in another datacenter.
Дополнительные сведения см. в разделе Защита SQL Server с помощью аварийного восстановления SQL Server и Azure Site Recovery.

Гибридная ИТ-среда: решения аварийного восстановления

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

Технология Примеры архитектур
Группы доступности Некоторые реплики доступности, выполняемые на виртуальных машинах Azure, и другие реплики, которые выполняются локально для аварийного восстановления на нескольких сайтах. Рабочий сайт может размещаться локально или в центре обработки данных Azure.
Diagram of Availability groups.
Так как все реплики доступности должны находиться в одном отказоустойчивом кластере, он должен охватывать обе сети (отказоустойчивый кластер с несколькими подсетями). Для этой конфигурации требуется установить VPN-подключение между сетью Azure и локальной сетью.

Для успешного аварийного восстановления баз данных также следует установить реплику контроллера домена на сайте аварийного восстановления. Чтобы приступить к работе, ознакомьтесь сруководством по группе доступности.
Зеркальное отображение базы данных Один участник выполняется на виртуальной машине Azure, а другой — локально для межсайтового аварийного восстановления с использованием сертификатов сервера. Участники не обязательно должны находиться в одном домене Active Directory. Кроме того, не требуется VPN-подключение.
Diagram of Database mirroring.
В другом сценарии зеркального отображения базы данных один участник выполняется на виртуальной машине Azure, а другой — локально в том же домене Active Directory для межсайтового аварийного восстановления. Требуется VPN-подключение между виртуальной сетью Azure и локальной сетью.

Для успешного аварийного восстановления баз данных также следует установить реплику контроллера домена на сайте аварийного восстановления.
Доставка журналов Один сервер запущен на виртуальной машине Azure, а другой — в локальной сети для межсайтового аварийного восстановления. Доставка журналов зависит от общего доступа к файлам Windows, поэтому требуется VPN-подключение между виртуальной сетью Azure и локальной сетью.
Diagram of Log shipping.
Для успешного аварийного восстановления баз данных также следует установить реплику контроллера домена на сайте аварийного восстановления.
Резервное копирование и восстановление с помощью хранилища BLOB-объектов Резервное копирование локальных рабочих баз данных выполняется непосредственно в хранилище BLOB-объектов для аварийного восстановления.
Diagram of Backup and restore.
Дополнительные сведения см. в статье Резервное копирование и восстановление для SQL Server на виртуальных машинах Azure.
Репликация и отработка отказа SQL Server в Azure с помощью службы Azure Site Recovery Репликация рабочего экземпляра SQL Server выполняется непосредственно в службу хранилища Microsoft Azure в целях аварийного восстановления.
Diagram of Replicate using Azure Site Recovery.
Дополнительные сведения см. в разделе Защита SQL Server с помощью аварийного восстановления SQL Server и Azure Site Recovery.

Бесплатная реплика аварийного восстановления в Azure

Если вы участвуете в программе Software Assurance, можно реализовать планы гибридного аварийного восстановления (DR) с использованием SQL Server без дополнительных затрат на лицензирование экземпляра пассивного аварийного восстановления. Вы также можете использовать бесплатные реплика аварийного восстановления с оплатой по мере использования, если все реплика размещены в Azure.

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

Diagram of two free passives when everything in Azure.

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

Diagram of three free passives when environment is hybrid with one primary on-premises replica.

Дополнительные сведения см. на странице с условиями лицензирования продукта.

Чтобы активировать это преимущество, перейдите в раздел Ресурс виртуальной машины SQL Server. Выберите "Настроить" в разделе Параметры, а затем выберите параметр "Высокий уровень доступности и аварийного восстановления" в разделе "Лицензия SQL Server". Установите флажок, чтобы подтвердить использование виртуальной машины SQL Server в качестве пассивной реплики, затем выберите Применить, чтобы сохранить эти параметры. Когда все три реплика размещаются в Azure, клиенты с оплатой по мере использования также имеют право использовать тип лицензии HA/DR.

Diagram about configuring a disaster recovery replica in Azure.

Важные соображения в отношении HADR для SQL Server в Azure

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

Узлы с высоким уровнем доступности в группе доступности

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

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

Узлы с высоким уровнем доступности в зоне доступности

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

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

Задержки сети в гибридной ИТ-среде

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

См. рекомендации по конфигурации HADR для параметров кластера и HADR, которые могут помочь в работе с облачной средой.

Поддержка георепликации

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

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

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

Выберите лучшее решение для обеспечения непрерывности бизнес-процессов — группа доступности или экземпляр отказоустойчивого кластера. После этого ознакомьтесь с рекомендациями по настройке среды для обеспечения высокого уровня доступности и аварийного восстановления.