Бөлісу құралы:


Непрерывность бизнес-процессов и восстановление базы данных — SQL Server

Область применения: SQL Server 2016 (13.x) и более поздних версий

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

Одна из общих задач при развертывании SQL Server заключается в том, чтобы обеспечить доступность всех критически важных экземпляров SQL Server и баз данных в них организации и конечным пользователям согласно их потребностям — хоть исключительно в рабочие часы, хоть круглосуточно. Требуется поддерживать работоспособность бизнеса с минимальными простоями либо вообще без них. Эта концепция также называется непрерывностью бизнес-процессов.

SQL Server 2017 (14.x) представил множество новых функций или улучшений для существующих, некоторые из которых предназначены для доступности. Самым большим дополнением к SQL Server 2017 (14.x) была поддержка SQL Server на Linux дистрибутивов. Полный список новых функций в SQL Server см. в следующих статьях:

В этой статье рассматриваются сценарии доступности в SQL Server 2017 (14.x) и более поздних версиях, а также новые и расширенные функции доступности. К сценариям относятся гибридные, которые смогут охватывать развертывания SQL Server как в Windows Server, так и в Linux, а также те, которые могут увеличить количество доступных для чтения копий базы данных.

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

Сценарии SQL Server с использованием функций доступности

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

  • Высокая доступность
  • Аварийное восстановление
  • Миграции и обновления
  • Горизонтальное масштабирование доступных для чтения копий одной или нескольких баз данных

В следующих разделах рассматриваются соответствующие функции, которые можно использовать для этого конкретного сценария. Здесь не рассматривается одна функция — репликация SQL Server. Хотя она официально не относится к функциям доступности в рамках AlwaysOn, репликацию SQL Server часто применяют для обеспечения избыточности данных при определенных условиях. Репликация слиянием не поддерживается для SQL Server на Linux. Дополнительные сведения см. в статье Репликация SQL Server на Linux.

Внимание

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

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

Важно убедиться, что экземпляры ИЛИ базы данных SQL Server доступны в случае проблемы, локальной для центра обработки данных или одного региона в облаке. В этом разделе описывается, как функции доступности SQL Server могут помочь с этой задачей. Все описанные функции доступны как в Windows Server, так и в Linux.

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

В SQL Server 2012 (11.x) группы доступности (AG) обеспечивают защиту на уровне базы данных, отправляя каждую транзакцию базы данных в другой экземпляр или реплику, содержащую копию этой базы данных в специальном состоянии. Группу доступности можно развернуть в выпусках Standard или Enterprise. Экземпляры, участвующие в группе доступности, могут быть автономными или отказоустойчивым экземплярами кластера (FCIs, описанными в следующем разделе). Так как транзакции отправляются в реплику по мере их выполнения, группы доступности рекомендуются, когда существуют требования к более низкой точке восстановления и целям времени восстановления. Перемещение данных между репликами может быть синхронным или асинхронным с выпуском Enterprise, что позволяет до трех реплик (включая основную) как синхронную. Группа доступности имеет одну полную копию базы данных, которая находится на первичной реплике, а все вторичные реплики не могут получать транзакции непосредственно от конечных пользователей или приложений.

Примечание.

AlwaysOn — это зонтичный термин для функций доступности в SQL Server и охватывает как группы управления доступом, так и ФК. AlwaysOn не является именем функции группы доступности.

Перед SQL Server 2022 (16.x) группы управления доступом предоставляют только уровень базы данных, а не защиту на уровне экземпляра. Все, что не записано в журнале транзакций или настроено в базе данных, необходимо вручную синхронизировать для каждой вторичной реплики. Примерами объектов, которые требуется синхронизировать вручную, являются имена для входа на уровне экземпляра, связанные серверы и задания агента SQL Server.

Начиная с SQL Server 2022 (16.x), вы можете управлять объектами метаданных, включая пользователей, имена входа, разрешения и агент SQL Server задания на уровне группы доступности в дополнение к уровню экземпляра. Дополнительные сведения см. в разделе "Содержащиеся группы доступности".

Группа доступности также имеет другой компонент, называемый прослушивателем, который позволяет приложениям и конечным пользователям подключаться без необходимости знать, какой экземпляр SQL Server размещает основную реплику. Каждая группа доступности будет иметь собственный прослушиватель. Хотя реализации прослушивателя немного отличаются в Windows Server и Linux, функции, которые он предоставляет и как он используется, одинаковы. На схеме ниже показана группа доступности на основе Windows Server, использующая отказоустойчивый кластер Windows Server (WSFC). Базовый кластер на уровне операционной системы для обеспечения доступности требуется как в Linux, так и в Windows Server. В примере показана простая конфигурация с двумя серверами или узлами с WSFC в качестве базового кластера.

Схема простой группы доступности.

Выпуск Standard и Enterprise имеют разные максимумы, когда речь идет о репликах. Группа доступности в выпуске Standard, известная как базовая группа доступности, поддерживает две реплики (одна первичная и одна вторичная) только с одной базой данных в группе доступности. Выпуск Enterprise не только позволяет настроить несколько баз данных в одной группе доступности, но и иметь до девяти общих реплик (один первичный, восемь вторичных). Выпуск Enterprise также предоставляет и другие дополнительные преимущества, такие как доступные для чтения вторичные реплики, возможность создавать резервные копии вторичной реплики и многое другое.

Примечание.

Зеркальное отображение базы данных, которое не рекомендуется использовать в SQL Server 2012 (11.x), недоступно в версии SQL Server linux и не будет добавлено. Клиенты по-прежнему используют зеркальное отображение базы данных должны планировать миграцию в группы доступности, которая является заменой зеркального отображения базы данных.

Когда речь идет о доступности, группы доступности могут предоставлять автоматическую или ручную отработку отказа. Автоматический переход на другой ресурс может произойти, если настроено синхронное перемещение данных, а базы данных в первичной и вторичной репликах находятся в синхронизированном состоянии. Если прослушиватель используется, и приложение использует более позднюю версию платформа .NET Framework (3.5 с обновлением или 4.0 и более поздней), отработка отказа должна обрабатываться с минимальными последствиями для конечных пользователей, если прослушиватель используется. Отработка отказа на вторичную реплику, чтобы сделать ее новой первичной репликой можно настроить автоматически или вручную, и обычно измеряется в секундах.

В приведенном ниже списке перечислены некоторые различия с группами доступности в Windows Server и Linux:

  • Из-за различий в том, как базовый кластер работает в Linux и Windows Server, все отработки отказа (вручную или автоматически) групп доступности выполняются через кластер в Linux. В развертываниях группы доступности на основе Windows Server необходимо выполнить отработку отказа вручную с помощью SQL Server. Автоматический переход на другой ресурс как в Windows Server, так и в Linux осуществляется с помощью базового кластера.
  • Для SQL Server на Linux рекомендуемая конфигурация для групп доступности составляет не менее трех реплик. Это вызвано особенностями работы базового кластера.
  • В Linux общее имя, используемое каждым прослушивателем, определено в DNS, а не в кластере, как в Windows Server.

Начиная с SQL Server 2017 (14.x), существуют некоторые новые возможности и усовершенствования групп доступности.

  • Типы кластера
  • REQUIRED_SECONDARIES_TO_COMMIT
  • Расширенная поддержка координатора распределенных транзакций Майкрософт (DTC) для конфигураций на основе Windows Server
  • Дополнительные сценарии горизонтального увеличения масштаба для баз данных, доступных только для чтения (описываются далее в этой статье)

Типы кластеров группы доступности

Встроенная форма доступности — кластеризация — в Windows Server реализуется посредством функции под названием "отказоустойчивая кластеризация". Он позволяет создавать WSFC для использования с группой доступности или FCI. Интеграция для групп управления доступом и ЦС обеспечивает библиотеки DLL ресурсов с поддержкой кластера, предоставляемые SQL Server.

SQL Server на Linux поддерживает несколько технологий кластеризации. Корпорация Майкрософт поддерживает компоненты SQL Server, а наши партнеры поддерживают соответствующую технологию кластеризации. Например, наряду с Pacemaker, SQL Server на Linux поддерживает HPE Serviceguard и DH2i DxEnterprise в качестве решения кластера.

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

Например, для поддержки Pacemaker для конфигураций группы доступности и FCI, включая такие вещи, как автоматическая отработка отказа, корпорация Майкрософт предоставляет mssql-server-ha пакет, который аналогичен, но не совсем так же, как и библиотеки DLL ресурсов в WSFC, для Pacemaker. Одно из различий между WSFC и Pacemaker заключается в том, что в Pacemaker нет ресурса сетевого имени, который является компонентом, помогающим абстрагировать имя прослушивателя (или экземпляра отказоустойчивого кластера) в кластере WSFC. DNS предоставляет разрешение имен в Linux.

Из-за разницы в стеке кластера необходимо вносить некоторые изменения для групп доступности, так как SQL Server должен обрабатывать некоторые метаданные, которые изначально обрабатываются WSFC. Одним из таких существенных изменений является введение типа кластера для группы доступности. Он хранится в sys.availability_groups cluster_type столбцах и cluster_type_desc столбцах. Существует три типа кластера:

  • WSFC
  • Внешняя.
  • нет

Все группы доступности, требующие высокой доступности, должны использовать базовый кластер, который в случае SQL Server 2017 (14.x) и более поздних версий означает WSFC или агент кластеризации Linux. Для групп AGs на основе Windows Server, использующих базовый WSFC, тип кластера по умолчанию — WSFC и не требуется задавать. Для групп доступности на основе Linux при создании группы доступности тип кластера должен иметь значение External. Интеграция с внешним решением кластера в Linux настраивается после создания группы доступности, в то время как в WSFC она выполняется во время создания.

Тип кластера None можно использовать как с windows Server, так и с группами AGS Linux. Установка типа кластера в None означает, что группе доступности не требуется базовый кластер. Это означает, что SQL Server 2017 (14.x) является первой версией SQL Server для поддержки групп доступности без кластера, но компромисс заключается в том, что эта конфигурация не поддерживается как решение с высоким уровнем доступности.

Внимание

Начиная с SQL Server 2017 (14.x), после его создания нельзя изменить тип кластера для группы доступности. Это означает, что группа доступности не может быть переключена с None на External или WSFC или наоборот.

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

На снимке экрана ниже показана поддержка различных типов кластеров в SQL Server Management Studio (SSMS). Требуется версия 17.1 или более поздняя. Этот снимок экрана сделан в версии 17.2.

Снимок экрана: параметры группы доступности SSMS.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

SQL Server 2016 (13.x) увеличила поддержку синхронных реплик с двух до трех в выпуске Enterprise. Однако если одна вторичная реплика была синхронизирована, а в другой возникала проблема, не существовало способа сообщить первичной реплике, следует ли дожидаться исправления неправильно работающей реплики или продолжить работу. Это означает, что первичная реплика в какой-то момент будет продолжать получать трафик записи, даже если вторичная реплика не будет синхронизирована, что означает, что на вторичной реплике есть потери данных. Начиная с SQL Server 2017 (14.x), вы можете управлять поведением того, что происходит при синхронных репликах.REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT Этот параметр работает следующим образом:

  • Существует три возможных значения: 0, 1и 2
  • Значением является количество вторичных реплик, которые должны быть синхронизированы, что имеет последствия для потери данных, доступности группы доступности и отработки отказа.
  • Для WSFCs и типа кластера None значение по умолчанию равно 0и может быть вручную установлено 1 или 2
  • По умолчанию для типа кластера внешнего типа механизм кластера задает это значение, и его можно переопределить вручную. Для трех синхронных реплик значение по умолчанию будет 1.

В Linux значение REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT для ресурса группы доступности в кластере настроено. В Windows он устанавливается через Transact-SQL.

Значение, которое выше, чем 0 обеспечивает более высокую защиту данных, так как если требуемое количество вторичных реплик недоступно, основной объект не будет доступен до тех пор, пока это не будет разрешено. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT также влияет на поведение отработки отказа, так как автоматическая отработка отказа не может произойти, если правильное количество вторичных реплик не было в правильном состоянии. В Linux значение 0 не разрешает автоматическую отработку отказа, поэтому в Linux при использовании синхронной с автоматической отработкой отказа значение должно быть установлено выше, чем 0 для автоматической отработки отказа. 0 В Windows Server используется поведение в SQL Server 2016 (13.x) и более ранних версиях.

Расширенная поддержка координатора распределенных транзакций Майкрософт

Перед SQL Server 2016 (13.x) единственным способом получения доступности в SQL Server для приложений, требующих распределенных транзакций, которые используют DTC под обложкой, было развертывание FCI. Распределенная транзакция может быть реализована одним из двух способов:

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

SQL Server 2016 (13.x) представила частичную поддержку DTC с группами доступности, которые охватывали последний сценарий. SQL Server 2017 (14.x) завершает историю, поддерживая оба сценария с DTC.

В SQL Server 2017 (14.x) и более поздних версиях поддержка DTC также может быть добавлена в группу доступности после ее создания. В SQL Server 2016 (13.x) поддержка DTC для группы доступности может выполняться только при создании группы доступности.

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

Функция кластерных установок появилась в SQL Server версии 6.5. Экземпляры отказоустойчивого кластера являются проверенным способом обеспечения доступности для всей установки SQL Server, называемой экземпляром. Это означает, что все в экземпляре, включая базы данных, агент SQL Server задания, связанные серверы и т. д., переместится на другой сервер, если базовый сервер столкнулся с проблемой. Для всех интерфейсов FCIs требуется некоторое общее хранилище, даже если оно предоставляется через сеть. Запускать ресурсы отказоустойчивого кластера и владеть ими одновременно может только один узел. На приведенной ниже схеме первый узел кластера владеет FCI, что также означает, что он владеет общими ресурсами хранилища, связанными с ним, обозначаемым сплошной линией хранилища.

Схема экземпляра отказоустойчивого кластера.

После отработки отказа права владения, как показано на схеме ниже.

Схема экземпляра отказоустойчивого кластера после отработки отказа.

Существует нулевая потеря данных с помощью FCI, но базовое общее хранилище является одной точкой сбоя, так как существует одна копия данных. FCI часто объединяются с другим методом доступности, например доставкой группы доступности или журналов, чтобы иметь избыточные копии баз данных. Реализуемый дополнительный метод должен использовать хранилище, физически отделенное от хранилища экземпляров отказоустойчивого кластера. Когда экземпляр отказоустойчивого кластера переходит на другой узел, он останавливается на одном узле и запускается на другом, что схоже с отключением и включением сервера. Экземпляр отказоустойчивого кластера проходит обычную процедуру восстановления, то есть выполняется накат всех требующих того транзакций, а также откат всех незавершенных транзакций. Таким образом, с точки зрения данных база данных согласована со временем сбоя или ручного перехода на другой ресурс, из-за чего потеря данных отсутствует. Базы данных доступны только после завершения восстановления, поэтому время восстановления будет зависеть от многих факторов и, как правило, будет длиннее, чем отработка отказа группы доступности. Компромисс заключается в том, что при отработки отказа группы доступности могут потребоваться дополнительные задачи, необходимые для использования базы данных, например включение задания агент SQL Server.

Как и группа доступности, fcis абстрактно, какой узел базового кластера размещает его. Экземпляр отказоустойчивого кластера всегда сохраняет свое имя. Приложения и пользователи никогда не подключаются к узлам, при этом используется присвоенное экземпляру отказоустойчивого кластера уникальное имя. FCI может участвовать в группе доступности в качестве одного из экземпляров, на котором размещена первичная или вторичная реплика.

В следующем списке перечислены некоторые различия экземпляров отказоустойчивого кластера в Windows Server и в Linux:

  • В Windows Server экземпляр отказоустойчивого кластера является частью процесса установки. Экземпляр отказоустойчивого кластера в Linux настраивается после установки SQL Server.
  • Linux поддерживает всего одну установку SQL Server на узел, поэтому все экземпляры отказоустойчивого кластера будут экземпляром по умолчанию. Windows Server поддерживает до 25 экземпляров отказоустойчивого кластера на кластер WSFC.
  • Общее имя, используемое экземплярами отказоустойчивого кластера в Linux, определено в DNS и должно совпадать с ресурсом, созданным для экземпляра отказоустойчивого кластера.

доставка журналов;

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

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

Пожалуй, главным преимуществом доставки журналов в некотором роде является учет человеческого фактора. Применение журналов транзакций может быть отложено. Таким образом, если кто-либо выполняет, например, инструкцию UPDATE без предложения WHERE, резервирование может не иметь измененной версии, на которую вы могли бы переключиться во время восстановления основной системы. Хотя настроить доставку журналов довольно легко, переключение с основной системы на резервирование, называемое сменой роли, всегда выполняется вручную. Изменение роли инициируется с помощью Transact-SQL и, как группа доступности, все объекты, не захваченные в журнале транзакций, должны быть синхронизированы вручную. Доставка журналов также должна быть настроена для каждой базы данных, в то время как одна группа доступности может содержать несколько баз данных.

В отличие от группы доступности или FCI доставка журналов не имеет абстракции для изменения роли, которые приложения должны иметь возможность обрабатывать. Можно применять различные методики, такие как DNS-псевдоним (CNAME), но у них всегда есть как преимущества, так и недостатки, например время, требуемое DNS для обновления после переключения.

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

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

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

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

Схема группы доступности, охватывающих центры обработки данных.

Вне группы доступности с типом кластера нет, группа доступности требует, чтобы все реплики были частью одного базового кластера, будь то WSFC или внешнее решение кластера. Это означает, что на приведенной выше схеме WSFC растянута для работы в двух разных центрах обработки данных, что повышает сложность. независимо от платформы (Windows Server или Linux). Перенос кластеров на расстояние повышает сложность работы.

Представленная в SQL Server 2016 (13.x), распределенная группа доступности позволяет группе доступности охватывать группы доступности, настроенные в разных кластерах. Распределенные группы доступности отделяют требование, чтобы все узлы участвовали в одном кластере, что упрощает настройку аварийного восстановления. Дополнительные сведения о распределенных группах доступности см. в разделе "Распределенные группы доступности".

Схема распределенной группы доступности.

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

Экземпляры отказоустойчивого кластера можно использовать для аварийного восстановления. Как и в обычной группе доступности, базовый механизм кластера также должен быть расширен ко всем расположениям, что повышает сложность. Существует дополнительное внимание к ФКЗ: общему хранилищу. Те же диски должны быть доступны на первичных и вторичных сайтах. Внешний метод, такой как функциональные возможности, предоставляемые поставщиком хранилища на аппаратном уровне или с помощью реплики хранилища в Windows Server, необходим для обеспечения того, чтобы диски, используемые FCI, существовали в другом месте.

Схема FCI, охватывающего центры обработки данных.

доставка журналов;

Доставка журналов — это один из старейших способов обеспечения аварийного восстановления для баз данных SQL Server. Доставка журналов часто используется с AG и FCIs для обеспечения экономичного и упрощенного аварийного восстановления, где другие варианты могут быть сложными из-за среды, административных навыков или бюджета. По аналогии с доставкой журналов для обеспечения высокой доступности, многие среды задерживают загрузку журнала транзакций для учета человеческого фактора.

Миграции и обновления

При развертывании новых экземпляров или обновлении старых бизнес не может терпеть длительные сбои. В этом разделе описано, как можно использовать функции доступности SQL Server для минимизации простоя при запланированном изменении архитектуры, переключении сервера, смене платформы (например, Windows Server на Linux или наоборот) или применении исправлений.

Примечание.

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

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

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

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

Распределенные группы доступности представляют еще один метод для перехода на новую конфигурацию или обновления SQL Server. Так как распределенная группа доступности поддерживает разные базовые группы доступности в разных архитектурах, например, можно изменить с SQL Server 2016 (13.x), работающих в Windows Server 2012 R2 на SQL Server 2017 (14.x), работающих в Windows Server 2016.

Схема распределенной группы доступности, смешивающей WSFC и Pacemaker.

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

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

Группы управления доступом могут обеспечить минимальное время простоя во время исправления базовой ОС, выполнив отработку отказа первичной на вторичную реплику во время завершения исправления. С точки зрения операционной системы это было бы более распространено на Windows Server, так как часто, но не всегда, обслуживание базовой ОС может потребовать перезагрузки. Исправление Linux иногда требует перезагрузки, но это может быть редко.

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

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

ФКК самостоятельно не могут помочь в традиционной миграции или обновлении; Необходимо настроить доставку группы доступности или журналов для баз данных в FCI и всех остальных объектов, для которых они были зарегистрированы. Однако экземпляры отказоустойчивого кластера под управлением Windows Server по-прежнему остаются распространенным решением, когда требуется установить исправления для серверов Windows Server. Отработка отказа вручную может быть инициирована, что означает краткое сбое вместо того, чтобы экземпляр был недоступен в течение всего времени исправления Windows Server. Экземпляр отказоустойчивого кластера можно обновить на месте до более поздних версий SQL Server. Дополнительные сведения см. в статье Обновление экземпляра отказоустойчивого кластера SQL Server.

доставка журналов;

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

Как и ВГ, доставка журналов может предоставить способ переключиться на другой сервер в случае исправления.

Другие способы развертывания SQL Server и обеспечение доступности

Существует два других способа развернуть SQL Server в Linux: контейнеры и Azure (или другой поставщик общедоступного облака). Как показано в этом документе, общая потребность в доступности наблюдается независимо от способа развертывания SQL Server. Когда дело касается обеспечения высокой доступности SQL Server, два этих метода имеют определенные особенности.

Параметры контейнеров SQL Server и высокого уровня доступности и аварийного восстановления

Развертывание контейнеров SQL Server — это новый способ развертывания SQL Server на Linux. Контейнер представляет собой полноценный образ SQL Server, готовый к запуску.

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

Если вы хотите настроить высокий уровень доступности для контейнеров SQL Server, развернутых на платформах Kubernetes или не kubernetes, можно использовать DH2i DxEnterprise в качестве одного из решений кластеризации, на вершине которых можно настроить группу доступности в режиме высокой доступности. Этот параметр предоставляет целевую точку восстановления (RPO) и целевое время восстановления (RTO), ожидаемое из решения высокого уровня доступности.

Развертывание IaaS под управлением Linux

Виртуальные машины IaaS Linux можно развернуть с помощью SQL Server, установленного с помощью Azure. Как и в случае с локальными установками, поддерживаемая установка требует использования STONITH (снимка другого узла в голове), который является внешним для самого агента кластера. STONITH обеспечивается за счет агентов ограждения доступности. Некоторые дистрибутивы поставляют их как часть платформы, а другие полагаются на внешних поставщиков оборудования и программного обеспечения. Узнайте, какие формы STONITH предоставляет предпочитаемый вами дистрибутив Linux, чтобы поддерживаемое решение можно было развернуть в общедоступном облаке.

Руководства по установке SQL Server на Linux доступны для следующих дистрибутивов:

Масштабирование чтения

С момента их внедрения в SQL Server 2012 (11.x) вторичные реплики имели возможность использовать для запросов только для чтения. Существует два способа, которые можно достичь с помощью группы доступности: разрешая прямой доступ к вторичной и настраивая маршрутизацию только для чтения, которая требует использования прослушивателя. SQL Server 2016 (13.x) представила возможность балансировки нагрузки только для чтения подключений через прослушиватель с помощью алгоритма циклического перебора, что позволяет распространять запросы только для чтения по всем репликам, доступным для чтения.

Примечание.

Доступные для чтения вторичные реплики — это функция только в выпуске Enterprise, и каждому экземпляру, на котором размещена читаемая реплика, потребуется лицензия SQL Server.

В SQL Server 2016 (13.x) впервые появилась масштабируемая копия базы данных с помощью групп AGs. Это позволяет организациям использовать доступные только для чтения копии базы данных не только локально, но и на региональном и глобальном уровне, а также минимизировать объем требуемых изменений конфигурации и сократить объем сетевого трафика и задержку благодаря локальному выполнению запросов. Каждая первичная реплика группы доступности может заполнять две другие группы доступности, даже если она не является полной копией чтения и записи, поэтому каждая распределенная группа доступности может поддерживать до 27 копий данных, доступных для чтения.

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

Начиная с SQL Server 2017 (14.x), можно создать практически в режиме реального времени решение только для чтения с AGS, настроенное с типом кластера None. Если цель заключается в использовании групп доступности для доступных для чтения вторичных реплик и не доступности, это устраняет сложность использования WSFC или внешнего решения кластера в Linux и дает доступные для чтения преимущества группы доступности в более простом методе развертывания.

Главная особенность заключается в том, что из-за отсутствия базового кластера с типом "Нет" настройка маршрутизации только для чтения немного отличается. С точки зрения SQL Server прослушиватель по-прежнему требуется для маршрутизации запросов, даже если нет кластера. Вместо настройки обычного прослушивателя используется IP-адрес или имя первичной реплики. После этого первичная реплика используется для перенаправления запросов только на чтение.

"Горячее" резервирование доставки журналов технически можно настроить для использования в режиме чтения, восстановив базу данных WITH STANDBY. Однако, поскольку журналы транзакций требуют эксклюзивного использования базы данных для восстановления, это означает, что пользователи не могут получить доступ к базе данных во время этого. Это снижает универсальность доставки журналов, особенно если требуется работать с данными почти в реальном времени.

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

Кроссплатформенность и взаимодействие с дистрибутивами Linux

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

Примечание.

Нет сценариев, когда FCI или AG на основе WSFC напрямую будет работать с FCI или AG на основе Linux. WSFC не может быть расширен узлом Pacemaker и наоборот.

Распределенные группы доступности

Распределенные группы доступности предназначены для охвата конфигураций группы доступности, независимо от того, являются ли эти два базовых кластера под AG двумя разными WSFCs, дистрибутивами Linux или одним в WSFC и другой в Linux. Распределенная группа доступности будет основным методом кроссплатформенного решения. Распределенная группа доступности также является основным решением для миграций, таких как преобразование из инфраструктуры SQL Server на основе Windows Server в linux, если это то, что ваша компания хочет сделать. Как отмечалось выше, группы доступности и, особенно распределенные группы доступности, свести к минимуму время, когда приложение будет недоступно для использования. Ниже показан пример распределенной группы доступности, охватывающей WSFC и Pacemaker.

Схема распределенной группы доступности, которая охватывает кластер WSFC и Pacemaker.

Если группа доступности настроена с типом кластера None, она может охватывать Windows Server и Linux, а также несколько дистрибутивов Linux. Так как это не является истинной конфигурацией высокой доступности, она не должна использоваться для критически важных развертываний, но для сценариев масштабирования чтения или миграции и обновления.

доставка журналов;

Так как доставка журналов основана на резервном копировании и восстановлении, никаких различий между базами данных, структурами файлов и т. п. в SQL Server на базе Windows Server и Linux нет. Это означает, что доставку журналов можно настроить между установкой SQL Server под управлением Windows Server и аналогичной установкой в Linux, а также между дистрибутивами Linux. Все остальное остается неизменным. Единственное предупреждение заключается в том, что доставка журналов, как и группа доступности, не может работать, если источник находится на более высокой основной версии SQL Server в целевом объекте, который находится в более низкой версии SQL Server.

Итоги

Экземпляры и базы данных SQL Server 2017 (14.x) и более поздние версии можно сделать высокодоступными с помощью одних и тех же функций в Windows Server и Linux. Кроме стандартных сценариев доступности с локальным высоким уровнем доступности и аварийным восстановлением, с помощью функций доступности в SQL Server можно минимизировать время простоя, связанное с обновлениями и миграциями. Группы управления также могут предоставлять дополнительные копии базы данных в рамках той же архитектуры, чтобы масштабировать доступные для чтения копии. Независимо от того, развертываете ли вы новое решение или рассматриваете обновление, SQL Server имеет необходимую доступность и надежность.

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