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

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

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

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

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

• Новые возможности в SQL Server 2017
• Новые возможности в SQL Server 2019
• Новые возможности SQL Server 2017 на Linux
• Новые возможности SQL Server 2019 на Linux

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

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

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

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

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

Важно!

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

Высокий уровень доступности

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

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

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

Примечание

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

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

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

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

Примечание

Зеркальное отображение базы данных, которое было объявлено нерекомендуемым в SQL Server 2012, недоступно в версии SQL Server для Linux и не запланировано для добавления. Клиентам, все еще использующим эту функцию зеркального отображения, следует спланировать переход на группы доступности, которые заменяют собой указанную функцию.

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

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

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

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

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

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

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

Каждый поддерживаемый дистрибутив Linux предоставляет собственную версию кластерного решения Pacemaker. SQL Server 2017 и 2019 в Linux поддерживает использование Pacemaker. Pacemaker — это открытое решение стека, которое каждый дистрибутив может интегрировать со своим стеком. Хотя дистрибутивы уже содержат Pacemaker, это решение не интегрировано подобно функции отказоустойчивой кластеризации в Windows Server. SQL Server на Linux также поддерживает HPE Serviceguard и DH2i DxEnterprise как кластерное решение.

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

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

• WSFC
• External
• None

Все группы доступности, которым требуется доступность, должны использовать базовый кластер — в SQL Server 2017 и 2019 это WSFC или Pacemaker. Для групп доступности на основе Windows Server, использующих базовый кластер WSFC, тип кластера по умолчанию имеет значение WSFC, поэтому настраивать его не требуется. При создании групп доступности на основе Linux типу кластера нужно присвоить значение "Внешний". Интеграция с Pacemaker и другим типами кластерных решений в Linux настраивается после создания группы доступности, тогда как в кластере WSFC она выполняется во время создания.

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

Важно!

SQL Server 2017 и 2019 не позволяет сменить тип кластера для группы доступности после ее создания. То есть группу доступности нельзя переключить с типа "Нет" на тип "Внешний" или "WSFC", либо наоборот.

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

Приведенный ниже снимок экрана показывает поддержку различных типов кластера в среде SSMS. Требуется версия 17.1 или более поздняя. Этот снимок экрана сделан в версии 17.2.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

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

• Возможны три значения: 0, 1 и 2.
• Это значение соответствует числу вторичных реплик, которые требуется синхронизировать, и влияет на потерю данных, доступность группы доступности и переход на другой ресурс.
• Для кластеров WSFC и типа кластера "Нет" значение по умолчанию равно 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 и более ранних версий.

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

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

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

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

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

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

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

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

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

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

В следующем списке перечислены некоторые различия экземпляров отказоустойчивого кластера в 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, и, как и в случае с группой доступности, все объекты, не зарегистрированные в журнале транзакций, нужно синхронизировать вручную. Кроме того, доставку журналов нужно настраивать для каждой базы данных, тогда как одна группа доступности может содержать несколько баз данных. В отличие от группы доступности или экземпляра отказоустойчивого кластера доставка журналов не имеет абстракции для смены роли. Приложения должны учитывать это. Можно применять различные методики, такие как DNS-псевдоним (CNAME), но у них всегда есть как преимущества, так и недостатки, например время, требуемое DNS для обновления после переключения.

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

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

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

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

Кроме групп доступности с типом кластера "Нет", группе доступности требуется, чтобы все реплики являлись частью одного базового кластера, которым может быть WSFC или Pacemaker. Это означает, что на приведенном выше рисунке кластер WSFC перенесен на два разных центра обработки данных, что усложняет работу. независимо от платформы (Windows Server или Linux). Перенос кластеров на расстояние повышает сложность работы. Появившаяся в SQL Server 2016 распределенная группа доступности позволяет группе доступности охватывать группы доступности, настроенные в разных кластерах. Это позволяет обойти требование по нахождению всех узлов в одном кластере, что значительно упрощает настройку аварийного восстановления. Дополнительные сведения о распределенных группах доступности см. в разделе Распределенные группы доступности.

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

По аналогии с группами доступности доставка журналов позволяет переключиться на другой сервер при применении исправлений.

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

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

Контейнеры с использованием Docker — это новый способ развертывания SQL Server в Windows Server или Linux. Контейнер представляет собой полноценный образ SQL Server, готовый к запуску. Однако пока собственная поддержка кластеризации, а следовательно, и прямой реализации высокой доступности и аварийного восстановления, отсутствует. Сейчас для обеспечения доступности баз данных SQL Server с помощью контейнеров можно использовать функции доставки журналов, а также резервного копирования и восстановления. Хотя можно настроить группу доступности с типом кластера "Нет", как уже отмечалось ранее, это не считается настоящей конфигурацией доступности. Корпорация Майкрософт ищет способы, позволяющие реализовать группы доступности или экземпляры отказоустойчивого кластера с помощью контейнеров.

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

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

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

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

Прежде чем перейти к кроссплатформенности и сценариям взаимодействия, следует указать два обстоятельства:

• Нет таких сценариев, при которых группа доступности или экземпляр отказоустойчивого кластера на основе WSFC напрямую работали бы с группой доступности или экземпляром отказоустойчивого кластера на основе Linux. WSFC невозможно расширить за счет узла Pacemaker, и наоборот.
• Сочетание дистрибутивов Linux не поддерживается для экземпляра отказоустойчивого кластера или группы доступности с типом кластера "Внешний". Все реплики группы доступности в этом случае следует настроить для использования не только того же дистрибутива Linux, но и той же версии. Поддерживаются два способа работы SQL Server с двумя платформами или несколькими дистрибутивами Linux — группы доступности и доставка журналов.

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

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

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

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

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

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

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

Примечание

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

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

В SQL Server 2017 появилась возможность создать решение, работающее почти в реальном времени и доступное только для чтения, с использованием групп доступности, для которых настроен тип кластера "Нет". Если целью является использование групп доступности для доступных для чтения вторичных реплик, а не для обеспечения доступности, такой подход упрощает работу с WSFC или Pacemaker, а также предоставляет преимущества группы доступности при более простом способе развертывания.

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

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

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

Сводка

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

Дальнейшие действия

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

Отказоустойчивые кластеры