Problem
I want to upgrade and migrate my SQL Server failover clusters to SQL Server 2022 running on Windows Server 2022. What is the process for building a Windows Server 2022 Failover Cluster step by step for SQL Server 2022?
Solution
Windows Server 2022, Microsoft’s latest version of its server operating system, has been branded as a “cloud ready” operating system. There are many features introduced in this version that make working with Microsoft Azure a seamless experience, specifically the Azure Extended Network feature. For decades, Windows Server Failover Clustering (WSFC) has become the platform of choice for providing high availability for SQL Server workloads – both for failover clustered instances and Availability Groups.
Listed below are two Windows Server 2022 failover clustering features that I feel are relevant to SQL Server. This is in addition to the features introduced in previous versions of Windows Server. And while there are many features added to Windows Server 2022 Failover Clustering, not all of them are designed with SQL Server in mind.
Clustering Affinity and AntiAffinity
Affinity is a failover clustering rule that establishes a relationship between two or more roles (or resource groups) to keep them together in the same node. AntiAffinity is the opposite, a rule that would keep two or more roles/resource groups in different nodes. While this mostly applies to virtual machines running on a WSFC, particularly VM guest clusters, this has been a long-awaited feature request for SQL Server failover clustered instances (FCI) that take advantage of the Distributed Transaction Coordinator (DTC). In the past, workarounds such as a SQL Server Agent job that moves the clustered DTC in the same node as the FCI were implemented to achieve this goal. Now, it’s a built-in feature.
AutoSites
This feature takes advantage of Active Directory sites and applies to multi-data center, stretched WSFCs. When configuring a WSFC, the setup process will check if an Active Directory site exists for the IP-subnet that the nodes belong to. If there is an existing Active Directory site, the WSFC will automatically create site fault domains and assign the nodes accordingly. If no Active Directory sites exist, the IP-subnets will be evaluated, and, similar to when Active Directory sites exist, site fault domains will be created based on the IP-subnet. While this is a great feature for local high availability and disaster recovery before SQL Server 2016, I no longer recommend a stretched WSFC for SQL Server. There are too many external dependencies that can impact local high availability.
In this series of tips, you will install a SQL Server 2022 failover clustered instance on a Windows Server 2022 failover cluster the traditional way – with Active Directory-joined servers and shared storage. Configuring TCP/IP and joining the servers to your Active Directory domain is beyond the scope of this tip. Consult your systems administrators on how to perform these tasks. It is assumed that the servers that you will add to the WSFC are already joined to an Active Directory domain and that the domain user account that you will use to perform the installation and configuration has local Administrative privileges on all the servers.
Similar to the previous tip, you need to provision your shared storage depending on your requirement. Talk to your storage administrator regarding storage allocation for your SQL Server failover clustered instances. This tip assumes that the underlying shared storage has already been physically attached to all the WSFC nodes and that the hardware meets the requirements defined in the Failover Clustering Hardware Requirements and Storage Options. Managing shared storage requires an understanding of your specific storage product, which is outside the scope of this tip. Consult your storage vendor for more information.
The environment used in this tip is configured with four (4) iSCSI shared storage volumes – SQL_DISK_R, SQL_DISK_S, and SQL_DISK_T allocated for the SQL Server databases and WITNESS for the witness disk.
NOTE: Don’t be alarmed if the WITNESS disk does not have a drive letter. It is not necessary. This frees up another drive letter for use with volumes dedicated to SQL Server databases. It also prevents you from messing around with it. I mean, you won’t be able to do anything with it if you cannot see it in Windows Explorer.
The goal here is to provide shared storage both for capacity and performance. Perform the necessary storage stress tests to make sure that you are getting the appropriate amount of IOPS as promised by your storage vendor. You can use the DiskSpd utility for this purpose.
Adding the Failover Clustering Feature
Before you can create a failover cluster, you must install the Failover Clustering feature on all servers that you want to join in the WSFC. The Failover Clustering feature is not enabled by default.
Add the Failover Clustering feature using the following steps.
Step 1
Open the Server Manager Dashboard and click the Add roles and features link. This will run the Add Roles and Features Wizard.
Step 2
Click through the different dialog boxes until you reach the Select features dialog box. In the Select features dialog box, select the Failover Clustering checkbox.
When prompted with the Add features that are required for Failover Clustering dialog box, click Add Features. Click Next.
Step 3
In the Confirm installation selections dialog box, click Install to confirm the selection and proceed to do the installation. You may need to reboot the server after adding this feature.
Alternatively, you can run the PowerShell command below using the Install-WindowsFeature PowerShell cmdlet to install the Failover Clustering feature.
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementToolsNOTE: Perform these steps on all the servers you intend to join in your WSFC before proceeding to the next section.
Running the Failover Cluster Validation Wizard
Next, you need to run the Failover Cluster Validation Wizard from the Failover Cluster Management console. You can launch the tool from the Server Manager dashboard, under Tools, and select Failover Cluster Manager.
NOTE: These steps can be performed on any servers that will serve as nodes in your WSFC.
Step 1
In the Failover Cluster Management console, under the Management section, click the Validate Configuration link. This will run the Validate a Configuration Wizard.
Step 2
In the Select Servers or a Cluster dialog box, enter the hostnames of the servers that you want to add as nodes in your WSFC. Click Next.
Step 3
In the Testing Options dialog box, accept the default option, Run all tests (recommended), and click Next. This will run all the necessary tests to validate whether the nodes are OK for the WSFC.
Step 4
In the Confirmation dialog box, click Next. This will run all the necessary validation tests.
Step 5
In the Summary dialog box, verify that all the selected checks return successful results. Click the View Report button to open the Failover Cluster Validation Report.
A note on the results: The icons in the Summary dialog box can be confusing. In the past, the Cluster Validation Wizard may report Warning messages pertaining to network and disk configuration issues, missing security updates, incompatible drivers, etc. The general recommendation has always been to resolve all errors and issues that the Cluster Validation Wizard reports before proceeding with the next steps. And it still is.
With Windows Server 2016 and later, the Cluster Validation Wizard checks for Storage Spaces Direct. Despite choosing the Run all tests (recommended) option, the Cluster Validation Wizard will exclude those checks.
Hence, why you will get a Warning message in the cluster validation report despite having all selected default checks return successful results. Having both the Warning (yellow triangle with an exclamation mark) and Successful (green check mark) icons in the same result is confusing indeed. It is what it is.
Another issue that you might encounter involves the warnings regarding signed drivers and software update levels.
You can resolve the warning regarding signed drivers for the Microsoft Remote Display Adapter using the latest Windows Server 2022 installation media or downloading the latest updates from the Windows Update Center. Using the Windows Update Center to download the latest updates also resolves the warning on the software update levels. This assumes that your servers can access the internet. Work with your network administrators on enabling internet access to your servers.
Step 6
To create the WSFC using the servers you’ve just validated, select the Create the cluster now using the validated nodes… checkbox and click Finish.
Alternatively, run the PowerShell command below using the Test-Cluster PowerShell cmdlet to run Failover Cluster Validation.
Test-Cluster -Node TDPRD081, TDPRD082Creating the Windows Server 2022 Failover Cluster (WSFC)
After validating the servers, create the WSFC using the Failover Cluster Manager console. You can launch the tool from the Server Manager dashboard, under Tools, and select Failover Cluster Manager. Alternatively, you can run the Create Cluster Wizard immediately after running the Failover Cluster Validation Wizard. Be sure to check the Create the cluster now using the validated nodes… checkbox.
NOTE: Perform these steps on any servers that will serve as nodes in your WSFC.
Step 1
Within the Failover Cluster Manager console, under the Management section, click the Create Cluster… link. This will run the Create Cluster Wizard.
Step 2
In the Select Servers dialog box, enter the hostnames of the servers that you want to add as nodes of your WSFC. Click Next.
Step 3
In the Access Point for Administering the Cluster dialog box, enter the virtual hostname and IP address you will use to administer the WSFC. Click Next. Note that because the servers are within the same network subnet, only one virtual IP address is needed. This is a typical configuration for local high availability.
Step 4
In the Confirmation dialog box, click Next. This will configure Failover Clustering on both servers that will act as nodes in your WSFC, add the configured shared storage, and add Active Directory and DNS entries for the WSFC virtual server name.
A word of caution before proceeding: Before clicking Next, be sure to coordinate with your Active Directory domain administrators on the appropriate permissions you need to create the computer name object in Active Directory. It will save you a lot of time and headaches troubleshooting if you cannot create a WSFC. Local Administrator permission on the servers that you will use as nodes in your WSFC is not enough. Your Active Directory domain account needs the following permissions in the Computers Organizational Unit. By default, this is where the computer name object that represents the virtual hostname for your WSFC will be created.
- Create Computer objects
- Read All Properties
For additional information, refer to Configuring cluster accounts in Active Directory.
In a more restrictive environment where your Active Directory domain administrators are not allowed to grant you those permissions, you can request them to pre-stage the computer name object in Active Directory. Provide the Steps for prestaging the cluster name account documentation to your Active Directory domain administrators.
Step 5
In the Summary dialog box, verify that the report returns successful results. Click Finish.
Step 6
Verify that the quorum configuration is using Node and Disk Majority – Witness: Cluster Disk n, using the appropriate drive that you configured as the witness disk.
Alternatively, you can run the PowerShell command below using the New-Cluster PowerShell cmdlet to create a new WSFC.
New-Cluster -Name TDPRD080 -Node TDPRD081, TDPRD082 -StaticAddress 172.16.0.80As a best practice, you should rename your shared storage resources before installing SQL Server 2022. This makes it easy to identify what the disks are used for – data, log, backups, etc. – during the installation and later when troubleshooting availability issues. And while you may have renamed the disks using the Disk Management console, you still have to rename them from the point-of-view of the WSFC. The default names of the shared storage will be Cluster Disk n, where n is the number assigned to the disks.
Step 1
Within the Failover Cluster Manager console, under the Storage navigation option, select Disks. This will display all of the shared storage resources added to the WSFC.
Step 2
Right-click one of the shared disks and select Properties. This will open the Properties page for that specific disk.
Step 3
In the Properties page, on the General tab, type the appropriate name for the shared disk in the Name textbox. Click OK.
Do this on all of the shared storage resources available on your WSFC. Make sure the names of the shared disks in the WSFC reflect those you assigned using the Disk Management console.
PowerShell Alternative
Alternatively, you can use the PowerShell script below to identify the clustered disks and their corresponding disk properties. The DiskGuid property of the cluster disk is used to identify the Path property of the physical disk. The Path property of the physical disk is used to identify the DiskPath and DriveLetter properties of the logical partition. The DriveLetter property of the logical partition is used to identify the FileSystemLabel property of the disk volume.
ForEach ($a in (Get-ClusterResource | Where {$_.ResourceType -eq "Physical Disk"} | Get-ClusterParameter -Name DiskGuid))
{
$ClusterDiskGuid=$a.Value.ToString()
$Disk=Get-Disk | where {$_.Path -like "*$ClusterDiskGuid"} | Select DiskNumber, Path
$Partition=Get-Partition | where {$_.DiskPath -like $Disk.Path} | Select DriveLetter, DiskPath
$Volume=Get-Volume | where {$_.DriveLetter -eq $Partition.DriveLetter} | Select FileSystemLabel
"Cluster Disk Name: " + $a.ClusterObject + " , Disk Number: " + $Disk.DiskNumber + " , Drive Letter: " + $Partition.DriveLetter + " , Volume Label: " + $Volume.FileSystemLabel
}
Once you’ve mapped the cluster disks with the corresponding physical disks, you can rename them accordingly using the sample PowerShell commands below, replacing the appropriate values. Note that the disk without the drive letter is the witness disk. Make sure that it is also renamed accordingly.
(Get-ClusterResource -Name "Cluster Disk 1").Name = "SQL_DISK_T"
(Get-ClusterResource -Name "Cluster Disk 2").Name = "WITNESS"
(Get-ClusterResource -Name "Cluster Disk 3").Name = "SQL_DISK_R"
(Get-ClusterResource -Name "Cluster Disk 4").Name = "SQL_DISK_S"Renaming Cluster Network Resources
Similarly, you should rename your cluster network resources before installing SQL Server 2022. And while you may have renamed the network adapters using the Network Connections management console, you still have to rename them from the point-of-view of the WSFC. The default names of the cluster network resources will be Cluster Network n, where n is the number assigned to the cluster network adapter.
Step 1
Within the Failover Cluster Manager console, select the Networks navigation option. This will display all the cluster network resources added to the WSFC.
Step 2
Right-click one of the cluster network adapters and select Properties. This will open the Properties page for that specific cluster network resource.
Step 3
In the Properties page, type the appropriate name for the cluster network resource in the Name textbox. Click OK.
NOTE: The WSFC will automatically detect whether client applications can connect through the specific cluster network resource. This is determined by whether a network adapter has a default gateway and can be identified via network discovery. Thus, it is important to get your network administrators involved in properly assigning the IP address, the subnet mask, and the default gateway values of all the network adapters used on the WSFC nodes before creating the WSFC. An example of this is the network adapter configured for inter-node communication.
Other network adapters also need to be appropriately configured. The network adapter used for iSCSI in the example cluster has the Do not allow cluster network communication on this network option selected.
Update Cluster Network Resources
Do this on all the cluster network resources available on your WSFC.
All available network adapters will be used for inter-node communication, including the network adapter you configure for production network traffic. How the WSFC prioritizes which network adapter is used for private/heartbeat communication traffic is determined by using the cluster network adapter’s Metric property value. You can identify the cluster network adapter’s Metric property value by running the PowerShell command below.
Get-ClusterNetwork | Sort Metric
The cluster network adapter with the lowest Metric property value will be used for private/heartbeat communication (and cluster shared volume if configured). In the example provided, the Heartbeat cluster network adapter will be used for inter-node communication. And since the LAN cluster network adapter has a Role property value of ClusterAndClient, the WSFC will use it if the Heartbeat cluster network adapter becomes unavailable. This is described in more detail in the Configuring Network Prioritization on a Failover Cluster blog post from Microsoft.
PowerShell Alternative
Alternatively, you can use the sample PowerShell script below to identify the clustered network resources and rename them accordingly.
#Display all cluster network resources
Get-ClusterNetworkInterface
#Rename cluster network resources accordingly based on the results of Get-ClusterNetworkInterface
(Get-ClusterNetwork –Name "Cluster Network 1").Name = "LAN"
(Get-ClusterNetwork –Name "Cluster Network 2").Name = "Heartbeat"
(Get-ClusterNetwork –Name "Cluster Network 3").Name = "iSCSI1"
(Get-ClusterNetwork –Name "Cluster Network 4").Name = "iSCSI2"
Congratulations! You now have a working Windows Server 2022 failover cluster. Proceed to validate whether your WSFC is working or not. A simple test to do would be a continuous PING test on the virtual hostname or IP address that you have assigned to your WSFC. Reboot one of the nodes and see how your PING test responds. At this point, you are now ready to install SQL Server 2022.
Summary
In this tip, you’ve:
- Seen some of the new Windows Server 2022 failover clustering features that are relevant to SQL Server workloads,
- Had an idea of how to provision shared storage for your WSFC,
- Added the Failover Clustering feature on all the servers that you intend to join in a WSFC,
- Ran the Failover Cluster Validation Wizard and resolved potential issues before creating the failover cluster,
- Seen how the validation checks for Storage Spaces Direct that can cause a Warning message when running the Failover Cluster Validation Wizard,
- Created the WSFC,
- Renamed the shared storage resources,
- Renamed the cluster network resources, and
- Viewed network prioritization for cluster network adapters.
In the next tip in this series, you will go through the process of installing a SQL Server 2022 failover clustered instance on your WSFC.
Next Steps
- Review the previous tips on Install SQL Server 2008 on a Windows Server 2008 Cluster Part 1, Part 2, Part 3, and Part 4 to see the difference in the setup experience between a SQL Server 2008 FCI on Windows Server 2008 and a SQL Server 2022 FCI on Windows Server 2022.
- Read more on the following topics:
- Installing, Configuring and Managing Windows Server Failover Cluster using PowerShell Part 1
- Validating a Windows Cluster Prior to Installing SQL Server 2014
- New features of Windows Server 2022 Failover Clustering
Время на прочтение4 мин
Количество просмотров115K
Данный топик будет интересен новичкам. Бывалые гуру и все, кто уже знаком с этим вопросом, вряд ли найдут что-то новое и полезное. Всех остальных милости прошу под кат.
Задача, которая стоит перед нами, – обеспечить бесперебойную работу и высокую доступность базы данных в клиент-серверном варианте развертывания.
Тип конфигурации — active/passive.
P.S. Вопросы резервирования узлов не относящихся к MSSQL не рассмотрены.
Этап 1 — Подготовка
Основные требования к аппаратному и программному обеспечению:
- Наличие минимум 2-х узлов(физических/виртуальных), СХД
- MS Windows Server, MS SQL ServerСХД
- СХД
- Доступный iSCSI диск для баз данных
- Доступный iSCSI диск для MSDTC
- Quorum диск
Тестовый стенд:
- Windows Server 2012R2 с ролями AD DS, DNS, DHCP(WS2012R2AD)
- Хранилище iSCSI*
- 2xWindows Server 2012R2(для кластера WS2012R2C1 и WS2012R2C2)
- Windows Server 2012R2 с поднятой службой сервера 1С (WS2012R2AC)
*как вариант можно использовать Роль хранилища на Windows Server 2012R2, софтверное решение от StarWind или реальное сетевое устройство iSCSI
Технически можно обойтись 3 серверами совместив все необходимые роли на домен контроллере, но в полевых условиях так поступать не рекомендуется.
Вначале вводим в домен сервера WS2012R2C1 и WS2012R2C2; на каждом из них устанавливаем роль «Отказоустойчивая кластеризация».
После установки роли, запускаем оснастку «Диспетчер отказоустойчивости кластеров» и переходим в Мастер создания кластеров, где конфигурируем наш отказоустойчивый кластер: создаем Quorum (общий ресурс) и MSDTC(iSCSI).
Этап 2 – Установка MS SQL Server
Важно: все действия необходимо выполнять от имени пользователя с правом заведения новых машин в домен. (Спасибоminamoto за дополнение)
Для установки нам понадобится установочный дистрибутив MS SQL Server. Запусткаем мастер установки и выбераем вариант установки нового экземпляра кластера:
Далее вводим данные вашего лицензионного ключа:
Внимательно читаем и принимаем лицензионное соглашение:
Получаем доступные обновления:
Проходим проверку конфигурации (Warning MSCS пропускаем):
Выбираем вариант целевого назначения установки:
Выбираем компоненты, которые нам необходимы (для поставленной задачи достаточно основных):
Еще одна проверка установочной конфигурации:
Далее — важный этап, выбор сетевого имени для кластера MSSQL (instance ID – оставляем):
Проверка доступного пространства:
После чего — список доступных хранилищ, данных (сконфигурировано на этапе подготовки):
Выбираем диск для расположения баз данных кластера:
Конфигурацию сетевого интерфейса кластера рекомендуется указать адрес вручную:
Указываем данные администратора (можно завести отдельного пользователя для MSSQL):
Еще один важный этап – выбор порядка сортировки (Collation). После инсталляции изменить крайне проблематично:
Параметры аутентификации на сервере (в нашем случае выбран смешанный вариант, хотя безопаснее использовать только доменную аутентификацию):
Выбор директорий хранения общих файлов кластера (в версиях MS SQL Server 2012 и старше TempDB можно хранить на каждой ноде и не выносить в общее хранилище):
Еще пару проверок:
Наконец приступаем к установке (процесс может занять длительное время):
Настройка и установка базовой ноды закончена, о чем нам сообщает «зеленый» рапорт
Этап 3 – добавление второй ноды в кластер MSSQL
Дальше необходимо добавить в кластер вторую ноду, т.к. без нее об отказоустойчивости говорить не приходится.
Настройка и установка намного проще. На втором сервере (ВМ) запускаем мастер установки MS SQL Server:
- Проходим стартовый тест
- Вводим лицензионный ключ:
- Читаем и принимаем лицензионное соглашение:
- Получаем обновления:
- Проходим тесты по выполнению требований для установки ноды (MSCS warning – пропускаем):
Выбираем: в какой кластер добавлять ноду:
Просматриваем и принимаем сетевые настройки экземпляра кластера:
Указываем пользователя и пароль (те же, что и на первом этапе):
Снова тесты и процесс установки:
По завершению мы должны получить следующую картину:
Поздравляю, установка закончена.
Этап 4 – проверка работоспособности
Удостоверимся, что все работает как надо. Для этого перейдем в оснастку «Диспетчер отказоустойчивого кластера»:
На данный момент у нас используется вторая нода(WS2012R2C2) в случае сбоя произойдет переключение на первую ноду(WS2012R2C1).
Попробуем подключиться непосредственно к кластеру сервера MSSQL, для этого нам понадобится любой компьютер в доменной сети с установленной Management Studio MSSQL. При запуске указываем имя нашего кластера и пользователя (либо оставляем доменную авторизацию).
После подключения видим базы которые крутятся в кластере (на скриншоте присутствует отдельно добавленная база, после инсталляции присутствуют только системные).
Данный экземпляр отказоустойчивого кластера полностью готов к использованию с любыми базами данных, например, 1С(для нас ставилась задача развернуть такую конфигурацию для работы именно 1С-ки). Работа с ним ничем не отличается от обычной, но основная особенность — в надежности такого решения.
В тестовых целях рекомендую поиграть с отключением нод и посмотреть как происходит миграция базы между ними; проконтролировать важные для вас параметры, например, сколько по времени будет длиться переключение.
У нас при отказе одной из нод – происходит разрыв соединения с базой и переключение на вторую (время восстановления работоспособности: до минуты).
В полевых условиях для обеспечения надежности всей инфраструктуры необходимо обработать точки отказа: СХД, AD и DNS.
P.S. Удачи в построении отказоустойчивых решений.
Задача: Создать высокодоступное или постоянно доступное хранилище файловых ресурсов общего доступа для Microsoft SQL Server.
Если вам необходимо получить готовый отказоустойчивый кластер MS SQL для работы с 1С, то мы можем предоставить его в рамках услуги аренда сервера 1С. Все настройки будут бесплатно сделаны нашими инженерами.
Тип конфигурации: Active/passive.
Шаг 1 — Подготовка и требования к оборудованию
Основные требования к аппаратному и программному обеспечению:
- Наличие минимум 2-х узлов (аппаратных или виртуальных), Система Хранения Данных
- MS Windows Server, MS SQL Server
- СХД
- iSCSI-диск для баз данных
- iSCSI диск для MSDTC
- Quorum-диск
Тестовый стенд:
- ВМ под управлением ОС: Windows Server 2016 с ролями AD DS, DNS (D54TEST-DC)
- Хранилище iSCSI*
- Две ВМ под управлением ОС: Windows Server 2016 (для кластера D54TEST-SQL1 и D54TEST-SQL2)
- ВМ управлением ОС: Windows Server 2016 с поднятой службой сервера 1С (Для теста не обязательно)
В первую очередь необходимо ввести в домен наши сервера D54TEST-SQL1 и D54TEST-SQL2; На этих серверах нужно поднять роль «Отказоустойчивая кластеризация».
Далее запускаем «Диспетчер отказоустойчивости кластеров» и переходим в «Мастер создания кластеров», где нам необходимо сконфигурировать отказоустойчивый кластер: Создать общий ресурс (Quorum) и MSDTC (iSCSI).
Шаг 2 – Установка MS SQL Server
Рекомендуем выполнять дальнейшие действия от Доменного Администратора
Монтируем и запускаем образ MS SQL Server 2012. Далее выбираем вариант установки нового экземпляра кластера:
Вводим лицензионный ключ и нажимаем далее:
Соглашаемся с лицензионным соглашением:
Загружаем обновление и ждем выполнения установки файлов установки.
Затем проходим тест на правила поддержки конфигурации:
Выбираем роль установки:
Далее выбираем необходимые нам компоненты из списка:
Проходим проверку правил компонентов:
Далее нам необходимо выбрать уникальное сетевое имя для вашего кластера MS SQL Server. Идентификатор экземпляра можно оставить по дефолту:
Проходим проверку требований к свободному месту на диске:
Выбираем сконфигурированный нами ранее список хранилищ данных:
Указываем диск расположения баз данных нашего будущего кластера:
Для конфигурации сетевого интерфейса кластера рекомендуем задавать статический адрес:
Вводим данные доменного администратора (Рекомендуется использовать отдельную учетную запись для MSSQL сервера, но для нашего тестового сервера в этом нет необходимости):
Задаем необходимую директорию хранения общих файлов кластера:
Выбираем необходимый способ авторизации на MSSQL сервере (в нашем случае используется смешанный режим):
Проходим ещё две проверки и наблюдаем за процессом установки:
Наконец приступаем к установке (процесс может занять длительное время):
Конфигурирование первой ноды кластера завершена, о чем свидетельствует данное окно:
Шаг 3 – добавление второй ноды в кластер MSSQL
Для настройки отказоустойчивости нашего кластера нам необходимо добавить вторую ноду.
На втором сервере монтируем, запускаем инсталятор MSSQL и выбираем пункт, который указан в скриншоте:
- Проходим базовое тестирование;
- Внимательно вводим наш лицензионный ключ;
- Принимаем лицензионное соглашение;
- Проходим тесты по выполнению требований для установки второй ноды;
Выбираем в какой кластер добавлять ноду:
Проверяем правильность заполнения сетевых настроек кластера:
Указываем уч.данные пользователя, которые использовали ранее:
Проведение тестирования инсталятором, процесс установки и итоговый результат:
Добавление второй ноды в кластер завершено.
Шаг 4 – Проверка Работоспособности
Необходимо убедиться, что роль отказоустойчивого кластера MSSQL добавлена. Для этого переходим в оснастку «Диспетчер отказоустойчивого кластера»:
На данный момент у нас используется первый сервер кластера (D54TEST-SQL1) в случае сбоя произойдет переключение на вторую ноду (D54TEST-SQL2)
Далее проверим, что сам кластер у нас работает. Для этого подключимся через консоль MSSMS к кластеру сервера MSSQL. При запуске указываем имя нашего нового кластера. Вводим учетные данные (в нашем случае мы используем доменную авторизацию)
Обнаруживаем базы которые крутятся в кластере (Для примера мы создали тестовую базу. После установки чистого кластера на нем будут присутствовать только системные базы данных)
Наша задача реализована – кластер полностью сконфигурирован. Работа с кластерным MSSQL ничем не отличается от обычной. Особенность — в надежности такого решения.
В прошлых статьях по развертыванию SharePoint Server 2019 я также рассказывал, что для отказоустойчивости крайне желательно обеспечить высокую доступность (High Availability) для баз данных на стороне SQL Server. Настройка HA позволяет нам как обеспечить отказоустойчивость, так и быстрое восстановление, если все-таки сбой произошел.
Одна из таких возможностей — группы доступности AlwaysOn, про которые мы сегодня поговорим. Погорим о принципах работы и рассмотрим настройку на примере SQL Server 2019.
Немного про сам SQL Server AlwaysOn
Сам по себе термин SQL Server AlwaysOn несет 2 различных технологии, под каждой из которых подразумевается свой функционал. Конкретно выделяются следующие 2:
1. AlwaysOn FCI — экземпляры отказоустойчивого кластера;
2. AlwaysOn AG — группы доступности.
Ниже приведена таблица с кратким описанием технологий:
| AlwaysOn FCI | AlwaysOn AG |
| Требует общее хранилище | Не требует общего хранилища |
| Обеспечивается отказоустойчивость на уровне экземпляра SQL Server | Обеспечивается отказоустойчивость на уровне баз данных SQL Server |
| Все объекты уровня экземпляра SQL Server синхронизированы | Требуется ручное добавление объектов на вторичные реплики (учетные записи, задания и т.д.) |
| Используется концепция активных/пассивных узлов | Вторичная реплика может быть активной только для чтения |
| Не поддерживается избыточная копия данных (по сути имеется только одна копия базы данных SQL Server) | Каждый узел хранит свою копию базы данных SQL Server, что обеспечивает избыточность |
| Особых требований для модели восстановления не предусмотрено | Все базы данных должны быть переключены в модель восстановления FULL |
В рамках нашей статьи нам нужно будет настроить группы доступности AlwaysOn для наших баз данных SharePoint Server. Выбор AlwaysOn High Availability дает нам следующие возможности:
— Избыточная доступность баз данных, что обеспечит нам доступность баз данных в независимости от того, что произошло с основным узлом (первичной репликой);
— Увеличение быстродействия, что обеспечивает нам некоторое горизонтальное расширение. Например, в случае большой нагрузки на первичную реплику данные могут читаться со вторичной;
— При отказе первичной реплики путем голосования будет выбрана новая реплика, статус которой будет изменен на первичную. Поскольку пользователь (в нашем случае SharePoint Server) изначально обращается по имени слушателя (Listener), то этот переход будет незаметен (пройдет в полностью автоматическом режиме).
Настройка AlwaysOn High Availability
Итак, для настройки AlwaysOn нам потребуется:
1. Настройка отказоустойчивого кластера Windows Server (Windows Server Failover Clustering);
2. Настройка SQL Server для работы с AlwaysOn;
3. Создание группы доступности.
Ниже представлена наглядная схема для общего понимания:
Используемый стенд
Для нашей статьи был собран тестовый стенд со следующим ПО:
ОС — Microsoft Windows Server 2019 Std x64
Дистрибутив СУБД — Microsoft SQL Server 2019
Установка MSSQL Server 2019 в рамках данной статьи не описывается, поскольку предполагается, что мы уже ее установили.
Установка отказоустойчивого кластера Windows Server (Windows Server Failover Clustering)
На этом этапе нам нужно настроить отказоустойчивый кластер Windows Server. Начнем с первого узла:
1. Открывем Server Manager — Manage — Add Roles and Features;
2. В открывшемся Add Roles and Features Wizard нажимаем Next, пока не дойдем до пункта Features;
3. Ставим галку на пункте Failover Clustering и нажимаем Next;
4. Соглашаемся с установкой дополнительных компонентов нажимаем Add Features:
5. В следующем окне будут указаны компоненты, которые будут установлены. Нажимаем Install и ждем окончания установки:
6. После установки вместо кнопки Install будет кнопка Close. Нажимаем ее и завершаем работу мастера. Установку WSFC на первом узле завершили;
7. Идем на второй узел и повторяем там пункты 1 — 6 этого раздела.
Настройка отказоустойчивого кластера Windows Server (Windows Server Failover Clustering)
После того, как службы отказоустойчивого кластера были развернуты на узлах, снова идем на первый:
1. Server Manager — Tools — Failover Cluster Manager. Откроется консоль управления кластером:
2. Справа, в разделе Actions выбираем Validate Configuration. Появится первое окно мастера проверки конфигурации кластера:
3. Нажимаем Next для перехода к выбору серверов:
Здесь нажимаем Browse и выбираем наши серверы через стандартный поиск Active Directory:
Выбираем серверы и нажимаем OK. Наши узлы появятся в списке Selected servers, как показано на рисунке выше. Нажимаем Next;
4. Попадаем на страницу Testing Options, где оставляем выделенный пункт по умолчанию и нажимаем Next;
5. В следующем окне Confirmation будет отображен список наших тестов:
Нажимаем Next;
6. Начнется прохождение тестов. Ожидаем окончания:
7. По окончанию тестирования мы перейдем в окно Summary, где можно посмотреть статус по каждому из отчетов и просмотреть отчет через View Report:
Например, конкретно в моем случае случае было предпупреждение, что у меня используется только одна пара интерфейсов, что является единой точкой отказа. Данный пункт не является блокирующим и в нашем случае мы можем развернуть кластер. Нажимаем Finish;
8. После успешного прохождения тестирования мы снова вернемся в интерфейс из пункта 1. В этом интерфейсе снова идем в раздел Actions и нажимаем Create Cluster. Откроется новый мастер создания кластеров:
9. В появившемся окне нажимаем Next и переходим к разделу Select Servers:
Выбор серверов здесь выполняется так же, как я описывал выше в 3 пункте. Также нажимаем Browse, выбираем серверы, нажимаем ОК. После выбора серверов нажимаем Next;
10. Попадаем в следующее окно Access Point for Administering the Cluster:
В этом окне заполняем следующие данные:
Cluster Name — указываем имя кластера (в нашем случае TestCluster01);
Address — указываем IP — адрес нашего кластера (в нашем случае это 192.168.1.5).
Нажимаем Next;
11. В окне Confirmation проверяем наши настройки, и если все правильно, то нажимаем Next:
12. Ожидаем создания нового кластера:
13. По окончанию создания появится окно Summary с нашими данными по созданному кластеру:
Нажимаем Finish и завершаем работу мастера;
14. Наш кластер создан. И его уже можно увидеть в Failover Cluster Manager.
15. Нажимаем ПКМ на нашем кластере, выбираем More Actions — Configure Cluster Quorum Settings:
16. Откроется Configure Cluster Quorum Wizard. В окне приветствия нажимаем Next:
17. В новом окне выбираем Select the quorum witness:
18. В следующем окне выбираем Configure a file share witness. Нажимаем Next:
19. Указываем имя шары. Имя шары можно как указать/скопировать вручную, так и выбрать через Browse:
Необходимо учитывать, что данная шара уже должна быть создана на целевом сервере/хранилище и на нее должны быть назначены соответствующие права, иначе подключения к шаре не произойдет;
20. В разделе Confirmation проверяем правильность настроек и нажимаем Next и ожидаем создания свидетеля:
21. Если все прошло успешно, то мы увидим окно примерно с таким содержанием. Нажимаем Finish:
22. После завершения работы мастера в основном окне WSFC можем спуститься до раздела Cluster Core Resources и убедиться, что у нас все настроено и работает корректно:
Настройка отказоустойчивого кластера завершена. Переходим к настройке SQL Server.
Настройка SQL Server для работы с AlwaysOn
Для работы групп доступности на стороне SQL Server нам необходимо выполнить следующее:
— Настроить запуск служб SQL Server на доменного пользователя;
— Включить AlwaysOn в настройках SQL Server.
1. Идем по пути Start — Microsoft SQL Server 2019 — SQL Server 2019 Configuration Manager:
2. Выбираем SQL Server Services — находим службу SQL Server (MSSQLServer). Нажимаем на сервисе ПКМ и выбираем Properties:
В разделе аккаунта через Browse меняем пользователя на нашу доменную учетную запись (в нашем случае это domadmin1);
3. Далее, в этом же окне идем на вкладку Always On Availability Groups и ставим галочку Enable Always On Availability Groups:
Нажимаем Apply и перезапускаем сервис (это можно сделать как через SQL Server Configuration Manager так и через Services — кому как удобно). После перезапуска можно идти в Management Studio и продолжать настройку.
Создание группы доступности
После того, как мы включили AlwaysOn на стороне SQL Server, идем дальше и создадим первую группу доступности для нашей базы данных.
1. Открываем SQL Server Management Studio и авторизуемся под нашей учетной записью:
2. После авторизации мы увидим созданные объекты в Object Explorer:
Для этой статьи я создал пустую базу данных AlwaysDB01, которую мы и добавим в группу доступности.
3. В дереве объектов идем в AlwaysOn High Availability — нажимаем ПКМ и выбираем New Availability Group Wizard:
4. Откроется окно мастера настройки групп доступности:
На странице приветствия нажимаем Next;
5. На следующей странице указываем имя группы доступности:
В нашем случае имя AlwaysGr01;
6. В следующем окне выбираем базы данных, которые мы хотим добавить в группу доступности:
В поле Status можно просмотреть — соответствует ли база всем необходимым требованиям. В нашем случае все ОК. Ставим галочку и нажимаем Next;
7. В следующем окне необходимо добавить реплики и выполнить основные настройки:
В разделе Replicas нажимаем Add Replica и добавляем наш второй узел. Выставляем галочки;
В разделе Listener выполняем настройки:
Выбираем Create an availability group listener;
В поле Listener DNS Name указываем имя листенера (в нашем случае AlwaysLsr01);
В поле Port указываем наш порт;
В поле Network Mode оставляем параметр Static IP и задаем сам IP — адрес (в нашем случае задан 192.168.1.9);
Нажимаем Next;
8. В следующем окне выбираем тип синхронизации:
Выбираем Full и указываем общий каталог, доступный обоим репликам. Нажимаем Next;
9. В следующем окне начнется проверка — ожидаем окончания:
Если возникают какие — нибудь ошибки — необходимо их решить и нажать Re-run Validation. Если ошибок не выявлено, нажимаем Next;
10. Проверяем настройки:
И если все хорошо, нажимаем Finish;
11. Начнется процесс создания группы доступности:
Ожидаем окончания работы мастера;
12. После того, как мастер завершит работу, можно проверить, что все работает корректно. Для этого идем в AlwaysOn High Availability — Availability Groups — AlwaysGr01(Primary) (в вашем случае группа может называться по-другому) — Availability Replicas:
Здесь мы видим, что у нас узел SQL01 ожидаемо находится в Primary, а узел SQL02 ожидаемо находится в Secondary. Если мы развернем Availability Databases и Availability Group Listener — то мы увидим соответствующие настроенные базы данных и листенеры.
Также, если открыть на обоих узлах раздел Databases, то мы увидим рядом с именем базы параметр Synchronized — это означает, что наша база находится в группе доступности и синхронизирована.
На данном этапе настройка группы доступности AlwaysOn для базы настроена. Необходимо только перенастроить наш SharePoint Server на обращение к SQL Server через Listener.
Проверка
Выключите сервер SQL01 и автоматически пройзойдет переезд на сервер SQL02. После открытия SQL Server Management Studio SQL01 и SQL02 поменяются местами — SQL01 станет Secondary, а SQL02 станет Primary.
Итог
Мы завершили настройку AlwaysOn. Теперь у нас имеется отказоустойчивость и на уровне баз данных. И эту настройку крайне желательно применять, когда мы строим отказоустойчивую ферму SharePoint Server.
В этой статье мы рассмотрим пошаговую установку и настройку групп доступности Always On в SQL Server в Windows Server 2019, рассмотрим сценарии отработки отказов и ряд других смежных вопросов.
“Always On Availability Groups” или “Группы доступности Always On” это технология для обеспечения высокой доступности в SQL Server. Always On появились в релизе Microsoft SQL Server 2012.
Содержание:
- Особенности групп доступности Always On в SQL Server
- Настройка Windows Server Failover Cluster для Always On
- Настройка Always On в MS SQL Server
- Always On: проверка работы, автоматическая отработка отказа
Особенности групп доступности Always On в SQL Server
Для чего могут использоваться группы доступности SQL Server?
- Высокая доступность MS SQL и автоматическая отработка отказа;
- Балансировка нагрузки select запросов между узлами (вторичные реплики могут быть доступны для чтения);
- Резервное копирование с вторичных реплик;
- Избыточность данных. Каждая реплика хранит копии баз данных группы доступности.
Always On работает на платформе Windows Server Failover Cluster (WSFC). WSFC обеспечивает мониторинг узлов участвующих в группе доступности и может осуществлять автоматическую отработку отказа посредством голосования между узлами. Начиная с MS SQL Server 2017 появилась возможность использовать Always On без WSFC, в том числе на Linux системах. При построении кластера на Linux можно использовать Pacemaker как альтернативу WSFC.
Always On доступен в Standard редакции, но с некоторыми ограничениями:
- Лимит на 2 реплики (основную и вторичную);
- Вторичная реплика не может быть использована для read доступа;
- Вторичная реплика не может быть использована для резервного копирования MS SQL;
- Поддержка только 1 базы данных на группу доступности.
В редакции Enterprise ограничений нет.
Разберемся в терминологии:
- Группу доступности Always ON – это набор реплик и баз данных;
- Реплика – это экземпляр SQL Server находящийся в группе доступности. Реплика может быть основная (primary) и вторичная (secondary). Каждая реплика может содержать одну или более баз данных.
В основе Always On лежит WSFC. Каждый узел группы доступности должен быть членом отказоустойчивого кластера Windows. Каждый экземпляр SQL Server может иметь несколько групп доступности. В каждой группе доступности может быть до 8 вторичных реплик.
При отказе основой реплики, кластер проголосует за новую основную реплику и Always On переведёт одну из вторичных реплик в статус основной. Так как при работе с Always On пользователи соединяются с прослушивателем кластера (или Listener, то есть специальный IP адрес кластера и соответствующее ему DNS имя), то возможность выполнять write запросы полностью восстановится. Прослушиватель также отвечает за балансировку select запросов между вторичными репликами.
Настройка Windows Server Failover Cluster для Always On
Прежде всего нам нужно настроить отказоустойчивый кластер на всех узлах, которые будут участвовать в Always On.
Моя конфигурация:
- 2 виртуальных машины на Hyper-V с Windows Server 2019;
- 2 экземпляра SQL Server 2019 редакции Enterprise;
- Hostname узлов – testnode1 и testnode2. Имя экземпляров node1 и node2.
В Server Manager добавляем роль Failover Clustering, или установите компонент с помощью PowerShell:
Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools
Установка автоматическая, ничего настраивать пока не нужно. После окончания установки запустите оснастку Failover Cluster Manager (FailoverClusters.SnapInHelper.msc).
Создаём новый кластер.
Добавляем имена серверов, которые будут участвовать в кластере.
Дальше мастер предлагает пройти тесты. Не отказываемся, выбираем первый пункт.
Указываем имя кластера, выбираем сеть и IP адрес кластера. Имя кластера автоматически появится в DNS, прописывать его специально не нужно. В моём случае имя кластера – ClusterAG.
Убираем чебокс “Add all eligible storage to the cluster”, так как диски мы сможем добавить позже.
Узлов в кластере всего 2, поэтому необходимо настроить Cluster Quorum. Кворум кластера — это “решающий голос”. Например, если один из узлов кластера становится недоступен, кластеру необходимо определить какие узлы на самом деле доступны и могут видеть друг друга. Кворум нужен для согласованности кластера (Cluster -> More Actions -> Configure Cluster Quorum Settings).
Выберите тип кворума со свидетелем (quorum witness).
Затем выбираем тип свидетеля – сетевая папка (file share witness).
Укажите UNC путь к сетевой папке. Эту директорию нужно создать самостоятельно, и она обязательно должна быть на сервере, который не участвует в кластере.
При настройке кластера вы можете получить ошибку:
There was an error configuring the file share witness. Unable to save property changes for File Share Witness. The system cannot find the file specified.
Скорее всего это значит, что у пользователя из-под которого работает кластер нет прав на эту сетевую папку. По-умолчанию кластер работает из-под локального пользователя. Вы можете дать права на эту папку всем компьютерам кластера, либо сменить аккаунт для службы кластера и раздать права ему.
На этом базовая конфигурация кластера закончена. Убедимся, что DNS кластера прописан и отдаёт правильный IP
Настройка Always On в MS SQL Server
После стандартной установки экземпляра SQL Server вы можете включить и настроить группы доступности Always On. Их нужно включить в SQL Server Configuration Manager в свойствах экземпляра. Как видно на скриншоте, SQL Server уже определил, что он является участником кластера WSFC. Поставьте чекбокс “Enable Always On Availability Groups” и перезагрузите службу экземпляра MSSQL. Выполните те же действия на втором экземпляре.
Совет.. Перед настройкой Always On убедитесь, что службы SQL Server работают не из-под локального аккаунта системы. Рекомендуется использовать Group Managed Service Accounts или обычный доменный аккаунт. В противном случае вы не сможете завершить настройку Always On.
В SQL Server Management Studio щелкните по узлу “Always On High Availability” и запустите мастер настройки группы доступности (New Availability Group Wizard).
Укажите имя группы доступности Always On и выберите опцию “Database Level Health Detection”. С этой опцией Always On сможет определять, когда база данных находится в нездоровом состоянии.
Выберите базы данных SQL Server, которые будут участвовать в группе доступности Always On.
Нажмите “Add Replica…” и подключитесь к второму серверу SQL. Таким образом можно добавить до 8 серверов.
- Initial Role – роль реплики на момент создания группы. Может быть Primary и Secondary;
- Automatic Failover – если база данных станет недоступна, Always On переведёт primary роль на другую реплику. Отмечаем чекбокс;
- Availability Mode – возможно выбрать Synchronous Commit или Asynchronous Commit. При выборе синхронного режима, транзакции, поступающие на primary реплику, будут отправлены на все остальные вторичные реплики с синхронным режимом. Primary реплика завершит транзакцию только после того, как реплики запишут транзакцию на диск. Таким образом исключается возможность потери данных при сбое primary реплики. При асинхронном режиме основная реплика сразу записывает изменения, не дожидаясь ответа от вторичных реплик;
- Readable Secondary – параметр задающий возможность делать select запросы к вторичным репликам. При значении yes, клиенты даже при соединении без ApplicationIntent=readonly смогут получить read-only доступ;
- Required synchronized secondaries to commit – число синхронизированных вторичных реплик для завершения транзакции. Нужно выставлять в зависимости от количества реплик, я поставлю 1. Имейте в виду, что, если вторичных синхронизированных реплик станет меньше указанного числа (например, при аварии), базы данных группы доступности станут недоступны даже для чтения.
Вкладку Endpoints не трогаем.
На вкладке Backup Preferences можно выбрать откуда будут делаться бекапы. Оставляем всё по умолчанию – Prefer Secondary.
Указываем имя слушателя группы доступности (availability group listener), порт и IP адрес.
Вкладку Read-Only Routing оставляем без изменений.
Выбираем каким образом будут синхронизироваться реплики. Я оставляю первый пункт – автоматическую синхронизацию (Automatic seeding).
После этого ваши настройки должны пройти валидацию. Если ошибок нет, нажмите Finish для применения изменений.
В моём случае все тесты прошли успешно, но после установки на шаге Results, мастер сообщил об ошибке при создании слушателя группы доступности. В логах кластера была такая ошибка:
Cluster network name resource failed to create its associated computer object in domain.
Это означает, что у кластера недостаточно прав для создания слушателя. В документации написано, что достаточно дать разрешение на создание объектов типа “компьютер” объекту вашего кластера. Проще всего это сделать через делегирование полномочий в AD (или, быстрый но плохой вариант — временно добавить объект CLUSTERAG$ в группу Domain Admins).
При диагностике проблем с Always ON и низкой производительностью SQL в группе доступности, кроме стандартных средств диагностики SQL Server, нужно внимательно смотреть логи кластера Windows.
Так как группа доступности у меня создалась, а слушатель нет, я добавил его вручную. Вызываем контекстное меню на группе доступности и жмем Add Listener…
Укажите IP адрес, порт и DNS имя слушателя.
Проверьте, что Listener появился во разделе доступных слушателей группы Always On.
На этом базовая настройка группы доступности Always On закончена.
Always On: проверка работы, автоматическая отработка отказа
Посмотрим на панель мониторинга групп доступности (Show Dashboard).
Все OK, группа доступности создана и работает.
Попробуем перевести основную роль на экземпляр node2 в ручном режиме. Щелкните ПКМ по группе доступности и выберите Failover.
Стоит обратить внимание на пункт Failover Readiness. Значение No data loss значит, что потеря данных при переходе исключена.
Соединяемся с node2.
Жмём Finish.
Проверяем, что node2 стал основной репликой в группе доступности (Primary Instance).
Убедимся, что слушатель работает как надо. В SSMS укажите DNS имя слушателе и порт через запятую:
ag1-listener-1,1445
Сделаем простые insert, select и update запросы в нашу базу SQL Server.
Теперь проверим автоматическую отработку отказа основной реплики. Просто завершите процесс sqlservr.exe на TESTNODE2.
Проверяем состояние группы доступности на оставшемся узле – TESTNODE1\NODE1.
Кластер автоматически перевёл статус реплики testnode1\node1 в primary, так как testnode2\node2 стал недоступен.
Проверим состояние слушателя, потому что соединения клиентов будут поступать именно на него.
В моём случае я успешно соединился со слушателем, но при доступе к базе данных появилась ошибка
Unable to access database 'TestDatabase' because it lacks a quorum of nodes for high availability. Try the operation again later.
Эта ошибка возникла из-за параметра “Required synchronized secondaries to commit”. Так как при настройке мы выставляли это значение в 1, Always On не даёт подключиться к базе данных, потому что у нас осталась всего одна primary реплика.
Установим это значение в 0 и попробуем снова.
Включаем testnode2 и проверяем статус группы.
Статус Primary реплики остался у testnode1, а testnode2 стал вторичной репликой. Данные, которые мы меняли на testnode1 при выключенной testnode2 успешно синхронизировались после включения машины.
На этом тестирование закончено. Мы убедились всё работает корректно и при критическом сбое данные останутся доступны для read/write доступа.
Группы доступности Always On достаточно просты в настройке. Если перед вами стоит задача построить отказоустойчивое решение на базе SQL Server, то группы доступности отлично справятся с этой задачей.
С выпуском SQL Server 2017 и SQL Server 2019 в SQL Server Management Studio 18.x появились настройки Always On, которые раньше были доступны только через T-SQL, поэтому рекомендуется пользоваться последней версией SSMS.