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


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

Область применения: SQL Server на виртуальной машине Azure

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

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

Примечание.

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

Обзор

SQL Server на виртуальных машинах Azure поддерживает следующий тип решений:

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

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

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

Функции обеспечения непрерывности бизнес-процессов

В следующей таблице перечислены функции, доступные только для Azure и гибридные компоненты SQL Server, которые можно использовать для обеспечения высокого уровня доступности (ВЫСОКОЙ доступности), аварийного восстановления (аварийного восстановления) или обоих компонентов (HA/DR):

Эти функции SQL Server поддерживаются для обеспечения непрерывности бизнес-процессов в конфигурации только Azure или гибридной конфигурации. Некоторые из вариантов идеально подходят для обеспечения высокого уровня доступности и аварийного восстановления (ha/DR), высокого уровня доступности (HA), а другие — для аварийного восстановления (аварийного восстановления).

функции SQL Server Вариант обеспечения высокого уровня доступности и аварийного восстановления Сведения
Группы доступности Always On Высокий уровень доступности и аварийное восстановление Обеспечивает защиту уровня базы данных, повышение уровня доступности и аварийное восстановление путем добавления реплик в разные зоны доступности и/или регионы.
Экземпляры отказоустойчивого кластера Always On (FCI) Высокая доступность Использует общее хранилище для обеспечения защиты на уровне экземпляра. Увеличьте защиту как на уровне базы данных, так и на уровне экземпляра, объединяя их с группами доступности.
Доставка журналов Аварийное восстановление Защита уровня базы данных для аварийного восстановления включает отправку резервных копий журналов транзакций с сервера-источника и их восстановление на дополнительный сервер. Требуется общая папка Azure.
Резервное копирование и восстановление SQL Server с помощью хранилища BLOB-объектов Azure Аварийное восстановление Резервные копии рабочей базы данных, хранящиеся в хранилище BLOB-объектов Azure для аварийного восстановления.
Azure Site Recovery Аварийное восстановление Решение аварийного восстановления, которое реплицирует виртуальные машины с первичного сайта на дополнительный сайт.

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

Группы доступности (HADR)

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

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

Чтобы приступить к работе, ознакомьтесь с руководством по группе доступности.

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

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

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

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

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

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

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

Экземпляры отказоустойчивого кластера (HA)

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

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

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

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

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

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

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

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

Доставка журналов (аварийное восстановление)

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

Схема доставки журналов в Azure.

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

Схема доставки журналов.

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

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

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

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

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

Схема резервного копирования и восстановления.

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

Репликация с помощью Azure Site Recovery (DR)

Azure Site Recovery можно использовать как решение аварийного восстановления в Azure, так и в гибридной конфигурации.

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

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

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

Схема репликации с помощью Azure Site Recovery.

Дополнительные сведения см. в разделе Защита SQL Server с помощью аварийного восстановления SQL Server и Azure Site Recovery.

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

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

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

Схема двух бесплатных пассивных элементов, когда все в Azure.

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

Схема трех бесплатных пассивных при гибридной среде с одной первичной локальной репликой.

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

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

Схема настройки реплики аварийного восстановления в 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 транзакций.

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

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

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