Рассмотрение вариантов высокой доступности и аварийного восстановления
Чтобы представить решение для виртуальных машин, сначала необходимо ознакомиться с вариантами доступности для развертываний на основе IaaS.
Инфраструктура как услуга и платформа как услуга
Когда дело доходит до уровня доступности, выбор IaaS или PaaS имеет значение. В подходе "инфраструктура как услуга" (IaaS) вам предоставляется виртуальная машина, что означает наличие операционной системы с установкой SQL Server. Администратор или группа, ответственные за SQL Server, смогут выбрать решение высокой доступности и аварийного восстановлении (HADR) и в значительной мере смогут контролировать то, как это решение будет настроено.
В развертываниях на основе подхода "платформа как услуга" (PaaS), таких как База данных SQL Azure, решения HADR встроены в предоставляемые функции и их часто нужно лишь включить. Набор настраиваемых параметров минимален.
Из-за этих различий выбор IaaS или PaaS может повлиять на финальную архитектуру решения HADR.
Функции HADR SQL Server для виртуальной машины Azure
При использовании IaaS можно использовать функции, предоставляемые SQL Server, чтобы повысить доступность. В некоторых случаях их можно сочетать с функциями уровня Azure, чтобы еще больше повысить доступность.
Функции, доступные в SQL Server, приведены в таблице ниже.
| Имя компонента | Защищает |
|---|---|
| Экземпляр отказоустойчивого кластера (FCI) Always On | Экземпляр |
| Группа доступности Always On | База данных |
| Доставка журналов | База данных |
Экземпляр SQL Server — это полная установка SQL Server (двоичные файлы, все объекты внутри экземпляра, включая такие элементы, как имена входа, задания агента SQL Server и базы данных). Защита на уровне экземпляра означает, что в функции доступности учитывается весь экземпляр.
База данных в SQL Server содержит данные, используемые конечными пользователями и приложениями. Существуют системные базы данных, которые использует SQL Server, а также базы данных, созданные для конечных пользователей и приложений. Экземпляр SQL Server всегда имеет собственные системные базы данных. Защита на уровне базы данных означает, что все, что находится в базе данных или записывается в журнале транзакций для пользователя или базы данных приложения, считается частью функции доступности. Все, что существует вне базы данных или не записывается в рамках журнала транзакций, например задания агента SQL Server и связанные серверы, следует обрабатывать вручную, чтобы гарантировать способность целевого сервера функционировать как первичный при возникновении запланированного или незапланированного события отработки отказа.
Для FCI и групп доступности требуется базовый механизм кластеров. Для развертываний SQL Server под управлением Windows Server это отказоустойчивый кластер Windows Server (WSFC), а для Linux — Pacemaker.
Экземпляры отказоустойчивого кластера AlwaysOn
FCI настраивается при установке SQL Server. Изолированный экземпляр SQL Server не может быть преобразован в FCI. FCI назначается уникальное имя, а также IP-адрес, который отличается от базовых серверов или узлов, участвующих в кластере. Имя и IP-адрес также должны отличаться от таковых базового механизма кластеров. Приложения и конечные пользователи будут использовать уникальное имя FCI для доступа. Эта абстракция позволяет приложениям не знать, где работает экземпляр. Одним из основных различий между FCI на основе Azure и локальным FCI является то, что для Azure требуется внутренняя подсистема балансировки нагрузки (ILB). ILB используется для обеспечения возможности подключения приложений и конечных пользователей к уникальному имени FCI.
При отработке отказа FCI на другой узел кластера, независимо от того, инициируется ли она вручную или происходит из-за проблемы, весь экземпляр перезапускается на другом узле. Это означает, что процесс отработки отказа является полной остановкой и перезапуском SQL Server. Все приложения или конечные пользователи, подключенные к FCI, будут отключены во время отработки отказа, и только приложения, которые могут обрабатывать такое прерывание и восстанавливаться после него, смогут автоматически подключиться обратно.
При запуске на другом узле экземпляр проходит процесс восстановления. FCI будет соответствовать моменту сбоя, поэтому технически не будет потери данных, а для всех транзакций, которым необходим откат, он будет выполнен в процессе восстановления. Как отмечалось выше, так как это защита на уровне экземпляра, все необходимое (имена входа, задания агента SQL Server и т. д.) уже имеется, поэтому работа сможет продолжиться как обычно, как только базы данных будут готовы.
FCI требуется одна копия базы данных, но она также представляет собой единую точку отказа. Для того чтобы другой узел мог получить доступ к базе данных, FCI требует определенного вида общего хранилища. Для архитектур на основе Windows Server его можно предоставить с помощью файлового ресурса Azure уровня "Премиум", iSCSI, общего диска Azure, локальных дисковых пространств (S2D) или поддерживаемого стороннего решения, такого как SIOS DataKeeper. FCI, использующий выпуск Standard SQL Server, может иметь до двух узлов. FCI также требует использования доменных служб Active Directory (AD DS) и службы доменных имен (DNS). Это означает, что AD DS и DNS должны быть реализованы где-то в Azure, чтобы FCI мог работать.
При использовании Windows Server 2016 или более поздней версии FCI может использовать реплику хранилища для создания собственного решения аварийного восстановления без использования других функций, таких как доставка журналов или группы доступности.
Группы доступности AlwaysOn
Группы доступности были введены в выпуске Enterprise SQL Server 2012, а начиная SQL Server 2016 — также и в выпуске Standard. В выпуске Standard группа доступности может содержать одну базу данных, а в выпуске Enterprise — больше одной базы данных. Хотя группы доступности имеют некоторые сходства с FCI, в большинстве аспектов они отличаются.
Крупнейшим различием между FCI и группами доступности является то, что группы доступности обеспечивают защиту на уровне базы данных. Первичная реплика — это экземпляр, участвующий в группе доступности, содержащей базы данных, доступные для чтения и записи. Вторичная реплика — это место, куда база данных-источник отправляет транзакции путем транспортировки журналов, чтобы обеспечить синхронизацию. Перемещение данных между первичной репликой может быть синхронным или асинхронным. Базы данных во всех вторичных репликах находятся в состоянии загрузки. Это означает, что они могут получать транзакции, но не могут быть копией с полной доступностью для записи до тех пор, пока реплика не станет первичной. Группа доступности в выпуске Standard может иметь не более двух реплик (одну первичную, одну вторичную), в то время как выпуск Enterprise поддерживает до девяти (одну первичную, восемь вторичных). Вторичная реплика инициализируется из резервной копии базы данных, либо, начиная с SQL Server 2016, можно использовать функцию автоматического заполнения. Автоматическое заполнение использует транспортный поток журнала для потокового резервного копирования на вторичную реплику каждой базы данных из группы доступности с применением настроенных конечных точек.
Группа доступности предоставляет абстракцию с прослушивателем. Прослушиватель выступает в качестве уникального имени, назначенного FCI, и имеет свое собственное имя и IP-адрес, отличающиеся от любых других (WSFC, Node и т. д.). Прослушиватель также требует ILB и проходит через остановку и запуск. Приложения и конечные пользователи могут использовать прослушиватель для подключения, но в отличие от FCI использование прослушивателя не обязательно. Соединения могут устанавливаться непосредственно с экземпляром. При использовании выпуске Enterprise вторичные реплики в выпуске Enterprise также можно настроить на доступ только для чтения, если есть такая необходимость. Их можно использовать для других функций, таких как проверка согласованности базы данных (DBCC) и резервное копирование.
Группы доступности могут иметь более быструю отработку отказа по сравнению с FCI, что является одной из причин их привлекательности. Хотя группы доступности не требуют общего хранилища, у каждой реплики имеется копия данных, что увеличивает общее количество копий базы данных и общие затраты на хранение. Хранилище является локальным для каждой реплики. Например, если память, занимаемая базами данных в первичной реплике, составляет 1 ТБ, каждая реплика будет занимать столько же. Если имеется пять реплик, это означает, что вам потребуется 5 ТБ места на диске.
Помните, что любой объект, существующий вне базы данных или не записанный в журнале транзакций базы данных, должен создаваться вручную и учитываться в любом другом экземпляре SQL Server на случай, если этот экземпляр потребуется сделать новой первичной репликой. К примерам объектов, за которые вам придется отвечать, относятся задания агента SQL Server, имена входа на уровне экземпляра и связанные серверы. Если вы можете использовать проверку подлинности Windows или использовать автономные базы данных с группами доступности, это упростит доступ.
Многие организации могут столкнуться с проблемами при реализации высокодоступных архитектур. Им может быть достаточно высокого уровня доступности, предоставляемого платформой Azure, или использования решения PaaS, например Управляемого экземпляра SQL Azure. Прежде чем мы рассмотрим решения платформы Azure, необходимо упомянуть еще об одной функции SQL Server — доставке журналов.
доставка журналов;
Доставка журналов существует с первых дней SQL Server. Эта функция основана на резервном копировании, копировании и восстановлении, а также является одним из самых простых методов достижения высокой доступности и аварийного восстановления для SQL Server. Доставка журналов в основном используется для аварийного восстановления, но ее также можно использовать для улучшения локальной доступности.
Доставка журналов, подобно группам доступности, обеспечивает защиту на уровне базы данных. Это означает, что по-прежнему необходимо брать в расчет задания агента SQL Server, связанные серверы, имена входа на уровне экземпляра и т. д. Для доставки журналов не предусмотрена абстракция, поэтому коммутатор на другой сервер, участвующий в доставке журналов, должен допускать изменение имени. Если это невозможно, существуют такие методы, как псевдоним DNS, который можно настроить на сетевом уровне, чтобы попытаться устранить проблемы с изменением имен.
Механизм доставки журналов прост: сначала создайте полную резервную копию исходной базы данных на сервере-источнике, затем восстановите ее в состоянии загрузки (STANDBY или NORECOVERY) на другом экземпляре, который называется сервером-получателем или сервером горячего резервирования. Эта новая копия базы данных называется базой данных — получателем. Автоматизированный процесс, встроенный в SQL Server, автоматически создаст резервную копию журнала транзакций базы данных — источника, скопирует резервную копию на резервный сервер и, наконец, восстановит резервную копию на нем.
Функции HADR SQL Server не являются единственными вариантами повышения доступности IaaS. В Azure есть некоторые функции, которые также следует рассмотреть.